[PATCH v4 3/5] drm/dp: make dp_get_lane_status usable from outside of the core
From: Quentin Schulz
dp_get_lane_status is pretty generic and can be used for other means,
so let's make it "public".
This adds drm_dp_get_lane_status to the header file and add the appropriate
EXPORT_SYMBOL for it so that it can be used by other drivers, be they compiled
built-in or as modules.
Signed-off-by: Quentin Schulz
Signed-off-by: Damian Kos
---
drivers/gpu/drm/drm_dp_helper.c | 9 +
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 735ebde5c2f0..169db52f92f5 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -48,14 +48,15 @@ static u8 dp_link_status(const u8
link_status[DP_LINK_STATUS_SIZE], int r)
return link_status[r - DP_LANE0_1_STATUS];
}
-static u8 dp_get_lane_status(const u8 link_status[DP_LINK_STATUS_SIZE],
-int lane)
+u8 drm_dp_get_lane_status(const u8 link_status[DP_LINK_STATUS_SIZE],
+ int lane)
{
int i = DP_LANE0_1_STATUS + (lane >> 1);
int s = (lane & 1) * 4;
u8 l = dp_link_status(link_status, i);
return (l >> s) & 0xf;
}
+EXPORT_SYMBOL(drm_dp_get_lane_status);
bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane_count)
@@ -69,7 +70,7 @@ bool drm_dp_channel_eq_ok(const u8
link_status[DP_LINK_STATUS_SIZE],
if ((lane_align & DP_INTERLANE_ALIGN_DONE) == 0)
return false;
for (lane = 0; lane < lane_count; lane++) {
- lane_status = dp_get_lane_status(link_status, lane);
+ lane_status = drm_dp_get_lane_status(link_status, lane);
if ((lane_status & DP_CHANNEL_EQ_BITS) != DP_CHANNEL_EQ_BITS)
return false;
}
@@ -84,7 +85,7 @@ bool drm_dp_clock_recovery_ok(const u8
link_status[DP_LINK_STATUS_SIZE],
u8 lane_status;
for (lane = 0; lane < lane_count; lane++) {
- lane_status = dp_get_lane_status(link_status, lane);
+ lane_status = drm_dp_get_lane_status(link_status, lane);
if ((lane_status & DP_LANE_CR_DONE) == 0)
return false;
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 698082a02b97..973d2fda9654 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -952,6 +952,8 @@
#define DP_MST_LOGICAL_PORT_0 8
#define DP_LINK_STATUS_SIZE 6
+
+u8 drm_dp_get_lane_status(const u8 link_status[DP_LINK_STATUS_SIZE], int lane);
bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
int lane_count);
bool drm_dp_clock_recovery_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/5] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings
From: Quentin Schulz
Document the bindings used for the Cadence MHDP DPI/DP bridge.
Signed-off-by: Quentin Schulz
Signed-off-by: Damian Kos
---
.../bindings/display/bridge/cdns,mhdp.txt | 43 +++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
new file mode 100644
index ..f8334c520b98
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
@@ -0,0 +1,43 @@
+Cadence MHDP bridge
+==
+
+The Cadence MHDP bridge is a DPI to DP bridge.
+
+Required properties:
+- compatible: should be "cdns,mhdp8546",
+- reg: physical base address and length of the controller's registers,
+- clocks: DP bridge clock, it's used by the IP to know how to translate
+ a number of clock cycles into a time (which is used to comply
+ with DP standard timings and delays),
+
+Required subnodes:
+- ports: Ports as described in Documentation/devictree/bindings/graph.txt
+ Port 0 - input port representing the DP bridge input
+ Port 1 - output port representing the DP bridge output
+
+Example:
+
+ mhdp: dp-bridge@f0fb00 {
+ compatible = "cdns,mhdp8546";
+ reg = <0xf0 0xfb00 0x0 0x100>;
+ clocks = <_clock>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dp_bridge_input: endpoint {
+ remote-endpoint = <_dpi_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dp_bridge_output: endpoint {
+ remote-endpoint =
<_dp_connector_input>;
+ };
+ };
+ };
+ };
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v4 1/2] drm: Add generic colorkey properties for display planes
On 8/14/18 1:38 PM, Daniel Vetter wrote:
On Tue, Aug 14, 2018 at 12:48:08PM +0300, Laurent Pinchart wrote:
Hi Dmitry,
Thank you for the patch.
On Tuesday, 7 August 2018 20:22:01 EEST Dmitry Osipenko wrote:
From: Laurent Pinchart
Color keying is the action of replacing pixels matching a given color
(or range of colors) with transparent pixels in an overlay when
performing blitting. Depending on the hardware capabilities, the
matching pixel can either become fully transparent or gain adjustment
of the pixels component values.
Color keying is found in a large number of devices whose capabilities
often differ, but they still have enough common features in range to
standardize color key properties. This commit adds new generic DRM plane
properties related to the color keying, providing initial color keying
support.
Signed-off-by: Laurent Pinchart
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_atomic.c | 20 +
drivers/gpu/drm/drm_blend.c | 150 +++
include/drm/drm_blend.h | 3 +
include/drm/drm_plane.h | 91 +
4 files changed, 264 insertions(+)
[snip]
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index a16a74d7e15e..13c61dd0d9b7 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -107,6 +107,11 @@
*planes. Without this property the primary plane is always below the
cursor *plane, and ordering between all other planes is undefined.
*
+ * colorkey:
+ * Color keying is set up with drm_plane_create_colorkey_properties().
+ * It adds support for actions like replacing a range of colors with a
+ * transparent color in the plane. Color keying is disabled by default.
+ *
* Note that all the property extensions described here apply either to the
* plane or the CRTC (e.g. for the background color, which currently is not
* exposed and assumed to be black).
@@ -448,3 +453,148 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
return 0;
}
EXPORT_SYMBOL(drm_atomic_normalize_zpos);
+
+static const char * const plane_colorkey_mode_name[] = {
+ [DRM_PLANE_COLORKEY_MODE_DISABLED] = "disabled",
+ [DRM_PLANE_COLORKEY_MODE_TRANSPARENT] = "transparent",
+};
+
+/**
+ * drm_plane_create_colorkey_properties - create colorkey properties
+ * @plane: drm plane
+ * @supported_modes: bitmask of supported color keying modes
+ *
+ * This function creates the generic color keying properties and attaches
them
+ * to the @plane to enable color keying control for blending operations.
+ *
+ * Glossary:
+ *
+ * Destination plane:
+ * Plane to which color keying properties are applied, this planes takes
+ * the effect of color keying operation. The effect is determined by a
+ * given color keying mode.
+ *
+ * Source plane:
+ * Pixels of this plane are the source for color key matching operation.
+ *
+ * Color keying is controlled by these properties:
+ *
+ * colorkey.plane_mask:
+ * The mask property specifies which planes participate in color key
+ * matching process, these planes are the color key sources.
+ *
+ * Drivers return an error from their plane atomic check if plane can't be
+ * handled.
This seems fragile to me. We don't document how userspace determines which
planes need to be specified here, and we don't document what happens if a
plane underneath the destination plane is not specified in the mask. More
precise documentation is needed if we want to use such a property.
It also seems quite complex. Is an explicit plane mask really the best option
? What's the reason why planes couldn't be handled ? How do drivers determine
that ?
General comment: This is why we need the reference userspace. I also
think that any feature throwing up so many tricky questions should come
with a full set of igt testcases.
At best I can write couple simple tests, simply because Tegra can't do more than
that.
Since the reference userspace cannot
answer how the new uapi should work in all corner-cases (failures and
stuff like that).
Okay.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU
On 8/16/18 8:23 PM, Robin Murphy wrote:
On 15/08/18 20:56, Dmitry Osipenko wrote:
On Friday, 3 August 2018 18:43:41 MSK Robin Murphy wrote:
On 02/08/18 19:24, Dmitry Osipenko wrote:
On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote:
On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
On 27/07/18 15:10, Dmitry Osipenko wrote:
On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:
On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote:
On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:
The proposed solution adds a new option to the base device driver
structure that allows device drivers to explicitly convey to the
drivers
core that the implicit IOMMU backing for devices must not happen.
Why is IOMMU mapping a problem for the Tegra GPU driver?
If we add something like this then it should not be the choice of
the
device driver, but of the user and/or the firmware.
Agreed, and it would still need somebody to configure an identity
domain
so
that transactions aren't aborted immediately. We currently allow the
identity domain to be used by default via a command-line option, so I
guess
we'd need a way for firmware to request that on a per-device basis.
The IOMMU mapping itself is not a problem, the problem is the
management
of
the IOMMU. For Tegra we don't want anything to intrude into the IOMMU
activities because:
1) GPU HW require additional configuration for the IOMMU usage and
dumb
mapping of the allocations simply doesn't work.
Generally, that's already handled by the DRM drivers allocating
their own unmanaged domains. The only problem we really need to
solve in that regard is that currently the device DMA ops don't get
updated when moving away from the managed domain. That's been OK for
the VFIO case where the device is bound to a different driver which
we know won't make any explicit DMA API calls, but for the more
general case of IOMMU-aware drivers we could certainly do with a bit
of cooperation between the IOMMU API, DMA API, and arch code to
update the DMA ops dynamically to cope with intermediate subsystems
making DMA API calls on behalf of devices they don't know the
intimate details of.
2) Older Tegra generations have a limited resource and capabilities in
regards to IOMMU usage, allocating IOMMU domain per-device is just
impossible for example.
3) HW performs context switches and so particular allocations have to
be
assigned to a particular contexts IOMMU domain.
I understand Qualcomm SoCs have a similar thing too, and AFAICS that
case just doesn't fit into the current API model at all. We need the
IOMMU driver to somehow know about the specific details of which
devices have magic associations with specific contexts, and we
almost certainly need a more expressive interface than
iommu_domain_alloc() to have any hope of reliable results.
This is correct for Qualcomm GPUs - The GPU hardware context switching
requires a specific context and there are some restrictions around
secure contexts as well.
We don't really care if the DMA attaches to a context just as long as it
doesn't attach to the one(s) we care about. Perhaps a "valid context"
mask
would work in from the DT or the device struct to give the subsystems a
clue as to which domains they were allowed to use. I recognize that
there
isn't a one-size-fits-all solution to this problem so I'm open to
different
ideas.
Designating whether implicit IOMMU backing is appropriate for a device
via
device-tree property sounds a bit awkward because that will be a kinda
software description (of a custom Linux driver model), while device-tree
is
supposed to describe HW.
What about to grant IOMMU drivers with ability to decide whether the
implicit backing for a device is appropriate? Like this:
bool implicit_iommu_for_dma_is_allowed(struct device *dev)
{
const struct iommu_ops *ops = dev->bus->iommu_ops;
struct iommu_group *group;
group = iommu_group_get(dev);
if (!group)
return NULL;
iommu_group_put(group);
if (!ops->implicit_iommu_for_dma_is_allowed)
return true;
return ops->implicit_iommu_for_dma_is_allowed(dev);
}
Then arch_setup_dma_ops() could have a clue whether implicit IOMMU
backing
for a device is appropriate.
Guys, does it sound good to you or maybe you have something else on your
mind? Even if it's not an ideal solution, it fixes the immediate problem
and should be good enough for the starter.
To me that looks like a step ion the wrong direction that won't help at
all in actually addressing the underlying issues.
If the GPU driver wants to explicitly control IOMMU mappings instead of
relying on the IOMMU_DOMAIN_DMA abstraction, then it should use its own
unmanaged domain. At that point it shouldn't matter if a DMA ops domain
was allocated, since the GPU device will no longer be attached to it.
It is not obvious to me what solution you are proposing..
Are you
[PATCH v4 0/5] drm: add support for Cadence MHDP DPI/DP bridge.
Hello!
This is the series of patches that will add support for the Cadence's DPI/DP
bridge. Please note that this is a preliminary version of the driver and there
will be more patches in the future with updates, fixes and improvements.
Please keep that in mind when looking at FIXME/TODO/XXX comments.
Initially, MHDP driver was developed as a DRM bridge driver and was planed to
be placed in drivers/gpu/drm/bridge/mhdp.c. However, there was already
a driver for Cadence's DP controller developed by RockChip, but that driver
uses the different DRM framework and looks like a part of a bigger system.
Both controllers (including firmware) are quite different internally
(MST/FEC/DSC support, link training done by driver, additional commands, IRQ's
etc.) but they have similar register map, except for Framer/Streamer (which is
noticeably different), so they appear similar.
The following patches contain:
- Moving common code to drivers/gpu/drm/bridge/cdns-mhdp-common.* and
modifying it a bit (mostly new prefixes for functions and data types) so it
can be used by two, higher level, drivers.
- Modifying existing RockChip's DP driver to use the common code after changes
made to it (use the new cdns_mhdp_device structure and new function names).
- Modifying DRM helpers a bit. Some are required for new driver, some are
updates from DP 1.2 to 1.3 or 1.4.
- Adding documentation for device tree bindings.
- Adding preliminary Cadence DPI/DP bridge driver.
Some of the things that will be added later on include (but are not limited
to):
- Support for Cadence SD0801 PHY (PHY's driver should be on the way by now)
- MST support
- DSC support
- FEC support
- HDCP support
Changes in v2:
- Added actual description of what the patch contains, what is it for and
what's going on here in general.
- New structure. Now we have one common low level driver + two high level
drivers - one for RockChip with minimum changes and one, more general, for
Cadence.
- Dropped some changes made to DRM helpers.
- Updated the device tree bindings document.
Changes in v3:
- Corrected dt-bindings document
- Enabled some clocks at startup (since FW doesn't do that anymore).
- Changed Firmware file name to match the file on Linux Firmware repo.
- Added SST audio support
- Made common functions (in cdns-mhdp-common.*) public.
Changes in v4:
- Fixed Kconfig in drm/rockchip
- Fixed Signed-offs
- dp_link_status() is no longer public since it's used only in drm_dp_helper.c
- Replaced EXTRA_CFLAGS with ccflags-y in drm/rockchip Makefile
Damian Kos (1):
drm/rockchip: prepare common code for cdns and rk dpi/dp driver
Quentin Schulz (4):
drm/dp: fix link probing for devices supporting DP 1.4+
drm/dp: make dp_get_lane_status usable from outside of the core
dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings
drm: bridge: add support for Cadence MHDP DPI/DP bridge
.../bindings/display/bridge/cdns,mhdp.txt | 43 +
drivers/gpu/drm/bridge/Kconfig|9 +
drivers/gpu/drm/bridge/Makefile |3 +
drivers/gpu/drm/bridge/cdns-mhdp-common.c | 1108 ++
.../cdns-mhdp-common.h} | 135 +-
drivers/gpu/drm/bridge/cdns-mhdp.c| 1308 +
drivers/gpu/drm/drm_dp_helper.c | 39 +-
drivers/gpu/drm/rockchip/Kconfig |4 +-
drivers/gpu/drm/rockchip/Makefile |4 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c| 234 +--
drivers/gpu/drm/rockchip/cdn-dp-core.h| 42 +-
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 969
include/drm/drm_dp_helper.h |2 +
13 files changed, 2750 insertions(+), 1150 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp.txt
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-common.c
rename drivers/gpu/drm/{rockchip/cdn-dp-reg.h => bridge/cdns-mhdp-common.h}
(81%)
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.c
delete mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 3/6] drm: add support of syncobj timeline point wait v2
> -Original Message-
> From: amd-gfx On Behalf Of
> Christian K?nig
> Sent: Thursday, September 20, 2018 7:11 PM
> To: Zhou, David(ChunMing) ; dri-
> de...@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Subject: Re: [PATCH 3/6] drm: add support of syncobj timeline point wait v2
>
> Am 20.09.2018 um 13:03 schrieb Chunming Zhou:
> > points array is one-to-one match with syncobjs array.
> > v2:
> > add seperate ioctl for timeline point wait, otherwise break uapi.
> >
> > Signed-off-by: Chunming Zhou
> > ---
> > drivers/gpu/drm/drm_internal.h | 2 +
> > drivers/gpu/drm/drm_ioctl.c| 2 +
> > drivers/gpu/drm/drm_syncobj.c | 99
> +-
> > include/uapi/drm/drm.h | 14 +
> > 4 files changed, 103 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_internal.h
> > b/drivers/gpu/drm/drm_internal.h index 0c4eb4a9ab31..566d44e3c782
> > 100644
> > --- a/drivers/gpu/drm/drm_internal.h
> > +++ b/drivers/gpu/drm/drm_internal.h
> > @@ -183,6 +183,8 @@ int drm_syncobj_fd_to_handle_ioctl(struct
> drm_device *dev, void *data,
> >struct drm_file *file_private);
> > int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
> >struct drm_file *file_private);
> > +int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
> > + struct drm_file *file_private);
> > int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
> > struct drm_file *file_private);
> > int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
> > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > index 6b4a633b4240..c0891614f516 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -669,6 +669,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
> > DRM_UNLOCKED|DRM_RENDER_ALLOW),
> > DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT,
> drm_syncobj_wait_ioctl,
> > DRM_UNLOCKED|DRM_RENDER_ALLOW),
> > + DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT,
> drm_syncobj_timeline_wait_ioctl,
> > + DRM_UNLOCKED|DRM_RENDER_ALLOW),
> > DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET,
> drm_syncobj_reset_ioctl,
> > DRM_UNLOCKED|DRM_RENDER_ALLOW),
> > DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL,
> drm_syncobj_signal_ioctl,
> > diff --git a/drivers/gpu/drm/drm_syncobj.c
> > b/drivers/gpu/drm/drm_syncobj.c index 67472bd77c83..a43de0e4616c
> > 100644
> > --- a/drivers/gpu/drm/drm_syncobj.c
> > +++ b/drivers/gpu/drm/drm_syncobj.c
> > @@ -126,13 +126,14 @@ static void
> drm_syncobj_add_callback_locked(struct drm_syncobj *syncobj,
> > }
> >
> > static int drm_syncobj_fence_get_or_add_callback(struct drm_syncobj
> > *syncobj,
> > +u64 point,
> > struct dma_fence **fence,
> > struct drm_syncobj_cb *cb,
> > drm_syncobj_func_t func)
> > {
> > int ret;
> >
> > - ret = drm_syncobj_search_fence(syncobj, 0, 0, fence);
> > + ret = drm_syncobj_search_fence(syncobj, point, 0, fence);
> > if (!ret)
> > return 1;
> >
> > @@ -143,7 +144,7 @@ static int
> drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
> > */
> > if (!list_empty(>signal_pt_list)) {
> > spin_unlock(>lock);
> > - drm_syncobj_search_fence(syncobj, 0, 0, fence);
> > + drm_syncobj_search_fence(syncobj, point, 0, fence);
> > if (*fence)
> > return 1;
> > spin_lock(>lock);
> > @@ -358,7 +359,9 @@ void drm_syncobj_replace_fence(struct
> drm_syncobj *syncobj,
> > spin_lock(>lock);
> > list_for_each_entry_safe(cur, tmp, >cb_list, node)
> {
> > list_del_init(>node);
> > + spin_unlock(>lock);
> > cur->func(syncobj, cur);
> > + spin_lock(>lock);
>
> That looks fishy to me. Why do we need to unlock
Cb func will call _search_fence, which will need to grab the lock, otherwise
deadlock.
>and who guarantees that
> tmp is still valid when we grab the lock again?
Sorry for that, quickly fix deadlock and forget to care that when debug.
How about splice to a tmp list, and then list_for _xxx without lock?
Any other comment on patch series and libdrm patches? That one comment
increases a patch set version seems be overcommit.
Thanks,
David Zhou
>
> Apart from that can't see anything obvious wrong, but I certainly need to
> take a closer look.
>
> Christian.
>
> > }
> > spin_unlock(>lock);
> > }
> > @@ -856,6 +859,7 @@ struct syncobj_wait_entry {
> > struct dma_fence *fence;
> > struct dma_fence_cb fence_cb;
> > struct
Re: [PATCH libdrm] intel: annotate the intel genx helpers as private
2018-09-20 7:18 GMT+08:00 Lucas De Marchi :
> On Wed, Sep 19, 2018 at 03:47:48PM +0800, Chih-Wei Huang wrote:
>> 2018-09-14 2:23 GMT+08:00 Lucas De Marchi :
>> > +Chris
>> >>
>> >> That's because drm_gralloc use the IS_GEN9 macro
>> >> (and other IS_GEN{n} macros) directly.
>> >>
>> >> Since IS_GEN{n} are public APIs, I don't see
>> >
>> >
>> > IS_GEN() is *not* public API and should not be. It's an internal macro.
>> >
>> > DESTDIR=/tmp/inst ninja -C build install
>> > grep -r IS_GEN /tmp/inst/
>> > Binary file /tmp/inst/usr/local/lib64/libdrm_intel.so.1.0.0 matches
>> >
>> > [ same thing when using autotools ]
>> >
>> > Grepping https://android.googlesource.com/platform/external/drm_gralloc/ I
>> > see IS_GEN* is being used, but I don't see where it's getting it from,
>> > unless it's using private headers... Let's see by grepping it:
>> >
>> > $ git grep intel_chipset
>> > gralloc_drm_intel.c:#include "intel_chipset.h" /* for platform detection
>> > macros */
>> >
>> > oh. You're a using a private header :(. How many places and libraries will
>> > we need to update to support different platforms? This is crazy.
>> > AFAICS it only uses that to get the max_stride for each platform... this
>> > info should be coming from somewhere else. Chris, any idea here?
>>
>> Hmm... There is no private declaration in this header.
>
> ???
>
>> Why is it private?
>
> All headers are private unless they are exported/installed. Android does
> things a little differently by incorporating libdrm inside this drm_gralloc.
>
>> If so, what is the correct way to get the gen of Intel's GPU?
>> Or the userspace should not know it?
>
> libdrm *is* userspace.
Sorry.
I meant an app which uses libdrm.
Shouldn't the app know the gen?
One interesting I just found.
I noticed Mesa has its own intel_chipset.h
which defines the IS_GEN3 macro.
(~src/mesa/drivers/dri/i915/intel_chipset.h)
So... to get the gen, I need to write my own header?
Or just copy libdrm's header?
> Better question: why do you need to know the gen? Can
> this be decided in another way by using a properly exported function from
> libdrm?
OK. That's another question.
The simple answer is I don't know.
That code is not written by me.
The code was written by some Google and Intel engineers.
So Intel engineer didn't think that header is private,
at least at that time he wrote the code...
> If you only want to hack it to work again, just link with the static library
> since you are already incorporating the library, as Chris suggested. If you
> want to do it right you may need to look into your library to see why it
> is doing that.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 7/7] drm/rockchip: dsi: add dual mipi support
On 20.09.2018 13:20, Heiko Stuebner wrote:
> Hi Andrzej,
>
> Am Montag, 27. August 2018, 13:34:07 CEST schrieb Andrzej Hajda:
>> On 21.08.2018 16:05, Heiko Stuebner wrote:
>>> Add the Rockchip-sepcific dual-dsi setup and hook it into the VOP as well.
>>> As described in the general dual-dsi devicetree binding, the panel should
>>> define two input ports and point each of them to one of the used dsi-
>>> controllers, as well as declare one of them as clock-master.
>>> This is used to determine the dual-dsi state and get access to both
>>> controller instances.
>>>
>>> Signed-off-by: Heiko Stuebner
>>> v4:
>>> add component directly in probe when adding empty dsi slave controller
>>> v5:
>>> use driver-internal mechanism to find dual dsi slave
>>> ---
>>> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 105 ++
>>> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
>>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 +
>>> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 4 +
>>> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
>>> 5 files changed, 114 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
>>> b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
>>> index b3aae8439aa3..e4aee2ccbf4d 100644
>>> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
>>> @@ -218,6 +218,10 @@ struct dw_mipi_dsi_rockchip {
>>> struct clk *grf_clk;
>>> struct clk *phy_cfg_clk;
>>>
>>> + /* dual-channel */
>>> + bool is_slave;
>>> + struct dw_mipi_dsi_rockchip *slave;
>>> +
>>> unsigned int lane_mbps; /* per lane */
>>> u16 input_div;
>>> u16 feedback_div;
>>> @@ -226,6 +230,7 @@ struct dw_mipi_dsi_rockchip {
>>> struct dw_mipi_dsi *dmd;
>>> const struct rockchip_dw_dsi_chip_data *cdata;
>>> struct dw_mipi_dsi_plat_data pdata;
>>> + int devcnt;
>>> };
>>>
>>> struct dphy_pll_parameter_map {
>>> @@ -602,6 +607,8 @@ dw_mipi_dsi_encoder_atomic_check(struct drm_encoder
>>> *encoder,
>>> }
>>>
>>> s->output_type = DRM_MODE_CONNECTOR_DSI;
>>> + if (dsi->slave)
>>> + s->output_flags = ROCKCHIP_OUTPUT_DSI_DUAL;
>>>
>>> return 0;
>>> }
>>> @@ -617,6 +624,8 @@ static void dw_mipi_dsi_encoder_enable(struct
>>> drm_encoder *encoder)
>>> return;
>>>
>>> pm_runtime_get_sync(dsi->dev);
>>> + if (dsi->slave)
>>> + pm_runtime_get_sync(dsi->slave->dev);
>>>
>>> /*
>>> * For the RK3399, the clk of grf must be enabled before writing grf
>>> @@ -630,6 +639,8 @@ static void dw_mipi_dsi_encoder_enable(struct
>>> drm_encoder *encoder)
>>> }
>>>
>>> dw_mipi_dsi_rockchip_config(dsi, mux);
>>> + if (dsi->slave)
>>> + dw_mipi_dsi_rockchip_config(dsi->slave, mux);
>>>
>>> clk_disable_unprepare(dsi->grf_clk);
>>> }
>>> @@ -638,6 +649,8 @@ static void dw_mipi_dsi_encoder_disable(struct
>>> drm_encoder *encoder)
>>> {
>>> struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
>>>
>>> + if (dsi->slave)
>>> + pm_runtime_put(dsi->slave->dev);
>>> pm_runtime_put(dsi->dev);
>>> }
>>>
>>> @@ -673,14 +686,76 @@ static int rockchip_dsi_drm_create_encoder(struct
>>> dw_mipi_dsi_rockchip *dsi,
>>> return 0;
>>> }
>>>
>>> +static int dw_mipi_dsi_rockchip_match_second(struct device *dev, void
>>> *data)
>>> +{
>>> + struct dw_mipi_dsi_rockchip *dsi = data;
>>> + struct drm_bridge *bridge1, *bridge2;
>>> + struct drm_panel *panel1, *panel2;
>>> + int ret;
>>> +
>>> + if (dsi->dev->of_node == dev->of_node)
>>> + return 0;
>>> +
>>> + ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0,
>>> + , );
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
>>> + , );
>>> + if (ret)
>>> + return ret;
>>> +
>>> + return (panel1 == panel2) && (bridge1 == bridge2);
>>> +}
>>> +
>>> static int dw_mipi_dsi_rockchip_bind(struct device *dev,
>>> struct device *master,
>>> void *data)
>>> {
>>> struct dw_mipi_dsi_rockchip *dsi = dev_get_drvdata(dev);
>>> struct drm_device *drm_dev = data;
>>> + struct device *second;
>>> + bool master1, master2;
>>> int ret;
>>>
>>> + second = driver_find_device(dsi->dev->driver, NULL, dsi,
>>> + dw_mipi_dsi_rockchip_match_second);
>> This function performs get_device on the matched device, so you should
>> probably call somewhere put_device to make the counter balanced.
>> I hope second device is somehow guarded by component framework from
>> being unbound in unexpected moments (ie. when in use by master).
> Thanks for that catch, I'll add the put_device.
>
>
>>> + if (IS_ERR(second))
>>> + return PTR_ERR(second);
>>> +
>>> + if (second) {
>>>
Re: [PATCH v3 01/12] drm/mediatek: add refcount for DPI power on/off
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> After the kernel 4.4, the DRM disable flow was changed, if DPI was
> disableed before CRTC, it will cause warning message as following:
>
> [ cut here ]
> WARNING: CPU: 0 PID: 1339 at
> ../../linux/linux-4.4.24-mtk/drivers/gpu/drm/drm_irq.c:1326
> drm_wait_one_vblank+0x188/0x18c()
> vblank wait timed out on crtc 0
> Modules linked in: bridge mt8521p_ir_shim(O) i2c_eeprom(O) mtk_m4(O)
> fuse_ctrl(O) virtual_block(O) caamkeys(PO) chk(PO) amperctl(O) ledctl(O)
> apple_auth(PO) micctl(O) sensors(PO) lla(O) sdd(PO) ice40_fpga(O) psmon(O)
> event_queue(PO) utils(O) blackbox(O)
> CPU: 0 PID: 1339 Comm: kworker/0:1 Tainted: PW O4.4.24 #1
> Hardware name: Mediatek Cortex-A7 (Device Tree)
> Workqueue: events drm_mode_rmfb_work_fn
> [] (unwind_backtrace) from [] (show_stack+0x20/0x24)
> [] (show_stack) from [] (dump_stack+0x98/0xac)
> [] (dump_stack) from [] (warn_slowpath_common+0x94/0xc4)
> [] (warn_slowpath_common) from []
> (warn_slowpath_fmt+0x40/0x48)
> [] (warn_slowpath_fmt) from []
> (drm_wait_one_vblank+0x188/0x18c)
> [] (drm_wait_one_vblank) from []
> (drm_crtc_wait_one_vblank+0x28/0x2c)
> [] (drm_crtc_wait_one_vblank) from []
> (mtk_drm_crtc_disable+0x78/0x240)
> [] (mtk_drm_crtc_disable) from []
> (drm_atomic_helper_commit_modeset_disables+0x128/0x3b8)
> [] (drm_atomic_helper_commit_modeset_disables) from []
> (mtk_atomic_complete+0x74/0xb4)
> [] (mtk_atomic_complete) from []
> (mtk_atomic_commit+0x68/0x98)
> [] (mtk_atomic_commit) from []
> (drm_atomic_commit+0x54/0x74)
> [] (drm_atomic_commit) from []
> (drm_atomic_helper_set_config+0x7c/0xa0)
> [] (drm_atomic_helper_set_config) from []
> (drm_mode_set_config_internal+0x68/0xe4)
> [] (drm_mode_set_config_internal) from []
> (drm_framebuffer_remove+0xe4/0x120)
> [] (drm_framebuffer_remove) from []
> (drm_mode_rmfb_work_fn+0x48/0x58)
> [] (drm_mode_rmfb_work_fn) from []
> (process_one_work+0x154/0x50c)
> [] (process_one_work) from [] (worker_thread+0x284/0x568)
> [] (worker_thread) from [] (kthread+0xec/0x104)
> [] (kthread) from [] (ret_from_fork+0x14/0x3c)
> ---[ end trace 12ae5358e992abd5 ]---
>
> so, we add refcount for DPI power on/off to protect the flow.
>
> Signed-off-by: Bibby Hsieh
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 6c0ea39d5739..d9373e67d328 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -77,6 +77,7 @@ struct mtk_dpi {
> enum mtk_dpi_out_bit_num bit_num;
> enum mtk_dpi_out_channel_swap channel_swap;
> bool power_sta;
> + int refcount;
> u8 power_ctl;
> };
>
> @@ -369,6 +370,12 @@ static void mtk_dpi_config_color_format(struct mtk_dpi
> *dpi,
>
> static void mtk_dpi_power_off(struct mtk_dpi *dpi, enum mtk_dpi_power_ctl
> pctl)
> {
> + if (WARN_ON(dpi->refcount == 0))
> + return;
> +
> + if (--dpi->refcount != 0)
> + return;
> +
> dpi->power_ctl &= ~pctl;
>
> if ((dpi->power_ctl & DPI_POWER_START) ||
> @@ -388,14 +395,17 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum
> mtk_dpi_power_ctl pctl)
> {
> int ret;
>
> + if (++dpi->refcount != 1)
> + return 0;
> +
> dpi->power_ctl |= pctl;
>
> if (!(dpi->power_ctl & DPI_POWER_START) &&
> !(dpi->power_ctl & DPI_POWER_ENABLE))
> - return 0;
> + goto err_refcount;
>
> if (dpi->power_sta)
> - return 0;
> + goto err_refcount;
I think dpi->power_ctl and dpi->power_sta is something like reference
count. mtk_dpi_start() and mtk_dpi_stop() is called by crtc. If the
error message happen without this patch, I think there is a bug in
dpi->power_ctl and dpi->power_sta. I think you should fix the bug of
dpi->power_ctl and dpi->power_sta, or just replace it with your
reference count mechanism.
Regards,
CK
>
> ret = clk_prepare_enable(dpi->engine_clk);
> if (ret) {
> @@ -417,6 +427,8 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum
> mtk_dpi_power_ctl pctl)
> clk_disable_unprepare(dpi->engine_clk);
> err_eng:
> dpi->power_ctl &= ~pctl;
> +err_refcount:
> + dpi->refcount--;
> return ret;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v4 1/2] drm: Add generic colorkey properties for display planes
On 8/16/18 2:42 PM, Maarten Lankhorst wrote: Op 08-08-18 om 16:30 schreef Dmitry Osipenko: On Wednesday, 8 August 2018 11:16:09 MSK Russell King - ARM Linux wrote: On Tue, Aug 07, 2018 at 08:22:01PM +0300, Dmitry Osipenko wrote: + * Glossary: + * + * Destination plane: + * Plane to which color keying properties are applied, this planes takes + * the effect of color keying operation. The effect is determined by a + * given color keying mode. + * + * Source plane: + * Pixels of this plane are the source for color key matching operation. ... + /** +* @DRM_PLANE_COLORKEY_MODE_TRANSPARENT: +* +* Destination plane pixels are completely transparent in areas +* where pixels of a source plane are matching a given color key +* range, in other cases pixels of a destination plane are unaffected. +* In areas where two or more source planes overlap, the topmost +* plane takes precedence. +*/ This seems confusing to me. What you seem to be saying is that the "destination" plane would be the one which is (eg0 the graphic plane, and the "source" plane would be the the plane containing (eg) the video. You seem to be saying that the colorkey matches the video and determines whether the pixels in the graphic plane are opaque or transparent. Your example is correct. With the "plane_mask" property we can specify any plane as the "source" for color key, so it can been either a video plane or graphic plane and even both at the same time. I'm not sure we should specify plane mask from userspace. It looks like a quite flexible approach. Do you have any other suggestions? Can't we make major loops? How do you want to handle those? It's up to a specific driver to accept the mask or reject it. You could make a loop if HW allows to do that, I don't see what's the problem. Surely that is the wrong way round - in video overlay, you want to colorkey match the contents of the graphic plane to determine which pixels from the video plane to overlay. The "transparent" mode makes the color-matched pixels to become transparent, you want the inversion effect and hence that should be called something like a "transparent-inverted" mode. Maarten Lankhorst was asking for that mode in his comment to v3, I'm leaving for somebody else to add that mode later since there is no real use for it on Tegra right now. I would like it to be described and included, so I can convert the existing intel_sprite_set_colorkey_ioctl to atomic. Okay, I can add it. Though probably better to call that mode "opaque" rather than "transparent-inverted". Then again, could transparent-inverted also be handled by setting transparent on the primary? If HW allows to do that, then yes. So in your case the graphic plane will be the "source" plane (specified via the colorkey.plane_mask property), video plane will be the "destination" plane (plane to which the colorkey properties are applied) and the colorkey.mode will be "transparent-inverted". Pixels of the "source" plane are being matched and "destination" plane takes the effect of color keying operation, i.e. the color-matched pixels of graphic plane leave the video plane pixels unaffected and the unmatched pixels make the video plane pixels transparent. If it's the other way around (source is the graphic, destination is the video) it makes less sense to use the "source" and "destination" terms, I can't see how you could describe a plane that is being overlaid on top of another plane as a "destination". Tegra has a bit annoying limitations in regard to a reduced plane blending functionality when color keying is enabled. I found that the best variant to work around the limitations is to move the graphic plane on top of the video plane and to make the graphic plane to match itself. I.e. the matched pixels of graphic plane become transparent and hence poked by video plane. I guess the terminology has come from a thought about using a GPU to physically do the colorkeying when combining two planes - if the GPU were to write to the "destination" plane, then this would be the wrong way around. For starters, taking the above example, the video plane may well be smaller than the graphic plane. If it's the other way around, that has other problems, like destroying the colorkey in the graphic plane when writing the video plane's contents to it. It all depends on a use-case scenario. It won't be easy for userspace to generalize the usage of color keying, at best the color keying interface could be generalized and then userspace may choose the best fitting variant based on available HW capabilities. There's TEST_ONLY for a reason, though I guess it makes generic color keying slightly more invovled for userspace. :) It is also quite involved for kernel to present a non-standard feature as something generic, pleasing everyone in the same time. ___ dri-devel
[PATCH v4 5/5] drm: bridge: add support for Cadence MHDP DPI/DP bridge
From: Quentin Schulz
This adds basic support for Cadence MHDP DPI to DP bridge.
Basically, it takes a DPI stream as input and output it encoded in DP
format. It's missing proper HPD, HDCP and currently supports only
SST mode.
Changes made in the low level driver (cdn-dp-reg.*):
- moved it to from drivers/gpu/drm/rockchip to
drivers/gpu/drm/bridge/cdns-mhdp-common.*
- functions for sending/receiving commands are now public
- added functions for reading registers and link training
adjustment
Changes made in RK's driver (cdn-dp-core.*):
- Moved audio_info and audio_pdev fields from cdn_dp_device to
cdns_mhdp_device structure.
Signed-off-by: Quentin Schulz
Signed-off-by: Damian Kos
---
drivers/gpu/drm/bridge/Kconfig|9 +
drivers/gpu/drm/bridge/Makefile |3 +
.../cdns-mhdp-common.c} | 137 +-
.../cdns-mhdp-common.h} | 21 +-
drivers/gpu/drm/bridge/cdns-mhdp.c| 1308 +
drivers/gpu/drm/rockchip/Kconfig |4 +-
drivers/gpu/drm/rockchip/Makefile |4 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c| 16 +-
drivers/gpu/drm/rockchip/cdn-dp-core.h|4 +-
9 files changed, 1486 insertions(+), 20 deletions(-)
rename drivers/gpu/drm/{rockchip/cdn-dp-reg.c => bridge/cdns-mhdp-common.c}
(87%)
rename drivers/gpu/drm/{rockchip/cdn-dp-reg.h => bridge/cdns-mhdp-common.h}
(95%)
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 9eeb8ef0b174..90a4810a8c96 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -35,6 +35,15 @@ config DRM_CDNS_DSI
Support Cadence DPI to DSI bridge. This is an internal
bridge and is meant to be directly embedded in a SoC.
+config DRM_CDNS_MHDP
+ tristate "Cadence DPI/DP bridge"
+ select DRM_KMS_HELPER
+ select DRM_PANEL_BRIDGE
+ depends on OF
+ help
+ Support Cadence DPI to DP bridge. This is an internal
+ bridge and is meant to be directly embedded in a SoC.
+
config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf5a6f8..e802fdb85750 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -16,4 +16,7 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-$(CONFIG_DRM_CDNS_MHDP) += mhdp8546.o
obj-y += synopsys/
+
+mhdp8546-objs := cdns-mhdp-common.o cdns-mhdp.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
similarity index 87%
rename from drivers/gpu/drm/rockchip/cdn-dp-reg.c
rename to drivers/gpu/drm/bridge/cdns-mhdp-common.c
index c1a76e6fff88..88cb248b9de4 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
@@ -19,8 +19,10 @@
#include
#include
-#include "cdn-dp-core.h"
-#include "cdn-dp-reg.h"
+#include
+#include
+
+#include "cdns-mhdp-common.h"
#define CDNS_DP_SPDIF_CLK 2
#define FW_ALIVE_TIMEOUT_US100
@@ -33,6 +35,7 @@ void cdns_mhdp_set_fw_clk(struct cdns_mhdp_device *mhdp,
unsigned long clk)
{
writel(clk / 100, mhdp->regs + SW_CLK_H);
}
+EXPORT_SYMBOL(cdns_mhdp_set_fw_clk);
void cdns_mhdp_clock_reset(struct cdns_mhdp_device *mhdp)
{
@@ -82,6 +85,7 @@ void cdns_mhdp_clock_reset(struct cdns_mhdp_device *mhdp)
/* enable Mailbox and PIF interrupt */
writel(0, mhdp->regs + APB_INT_MASK);
}
+EXPORT_SYMBOL(cdns_mhdp_clock_reset);
static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
{
@@ -189,7 +193,56 @@ static int cdns_mhdp_mailbox_send(struct cdns_mhdp_device
*mhdp, u8 module_id,
return 0;
}
-static int cdns_mhdp_reg_write(struct cdns_mhdp_device *mhdp, u16 addr, u32
val)
+int cdns_mhdp_reg_read(struct cdns_mhdp_device *mhdp, u32 addr, u32 *value)
+{
+ u8 msg[4], resp[8];
+ int ret;
+
+ if (addr == 0) {
+ ret = -EINVAL;
+ goto err_reg_read;
+ }
+
+ msg[0] = (u8)(addr >> 24);
+ msg[1] = (u8)(addr >> 16);
+ msg[2] = (u8)(addr >> 8);
+ msg[3] = (u8)addr;
+
+ ret = cdns_mhdp_mailbox_send(mhdp, MB_MODULE_ID_GENERAL,
+GENERAL_REGISTER_READ,
+sizeof(msg), msg);
+ if (ret)
+ goto err_reg_read;
+
+ ret = cdns_mhdp_mailbox_validate_receive(mhdp, MB_MODULE_ID_GENERAL,
+GENERAL_REGISTER_READ,
+sizeof(resp));
+ if (ret)
+ goto err_reg_read;
+
+ ret =
[PATCH v4 1/5] drm/rockchip: prepare common code for cdns and rk dpi/dp driver
- Extracted common fields from cdn_dp_device to a new cdns_mhdp_device
structure which will be used by two separate drivers later on.
- Moved some datatypes (audio_format, audio_info, vic_pxl_encoding_format,
video_info) from cdn-dp-core.c to cdn-dp-reg.h.
- Changed prefixes from cdn_dp to cdns_mhdp
cdn -> cdns to match the other Cadence's drivers
dp -> mhdp to distinguish it from a "just a DP" as the IP underneath
this registers map can be a HDMI (which is internally different,
but the interface for commands, events is pretty much the same).
- Modified cdn-dp-core.c to use the new driver structure and new function
names.
Signed-off-by: Damian Kos
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 220 +++--
drivers/gpu/drm/rockchip/cdn-dp-core.h | 40 +--
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 428 +
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 114 +--
4 files changed, 431 insertions(+), 371 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 8ad0d773dc33..bf7e206326f0 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -31,11 +31,10 @@
#include
#include "cdn-dp-core.h"
-#include "cdn-dp-reg.h"
#include "rockchip_drm_vop.h"
#define connector_to_dp(c) \
- container_of(c, struct cdn_dp_device, connector)
+ container_of(c, struct cdn_dp_device, mhdp.connector)
#define encoder_to_dp(c) \
container_of(c, struct cdn_dp_device, encoder)
@@ -70,17 +69,18 @@ MODULE_DEVICE_TABLE(of, cdn_dp_dt_ids);
static int cdn_dp_grf_write(struct cdn_dp_device *dp,
unsigned int reg, unsigned int val)
{
+ struct device *dev = dp->mhdp.dev;
int ret;
ret = clk_prepare_enable(dp->grf_clk);
if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to prepare_enable grf clock\n");
+ DRM_DEV_ERROR(dev, "Failed to prepare_enable grf clock\n");
return ret;
}
ret = regmap_write(dp->grf, reg, val);
if (ret) {
- DRM_DEV_ERROR(dp->dev, "Could not write to GRF: %d\n", ret);
+ DRM_DEV_ERROR(dev, "Could not write to GRF: %d\n", ret);
return ret;
}
@@ -91,24 +91,25 @@ static int cdn_dp_grf_write(struct cdn_dp_device *dp,
static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
{
+ struct device *dev = dp->mhdp.dev;
int ret;
unsigned long rate;
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "cannot enable dp pclk %d\n", ret);
+ DRM_DEV_ERROR(dev, "cannot enable dp pclk %d\n", ret);
goto err_pclk;
}
ret = clk_prepare_enable(dp->core_clk);
if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "cannot enable core_clk %d\n", ret);
+ DRM_DEV_ERROR(dev, "cannot enable core_clk %d\n", ret);
goto err_core_clk;
}
- ret = pm_runtime_get_sync(dp->dev);
+ ret = pm_runtime_get_sync(dev);
if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "cannot get pm runtime %d\n", ret);
+ DRM_DEV_ERROR(dev, "cannot get pm runtime %d\n", ret);
goto err_pm_runtime_get;
}
@@ -121,18 +122,18 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
rate = clk_get_rate(dp->core_clk);
if (!rate) {
- DRM_DEV_ERROR(dp->dev, "get clk rate failed\n");
+ DRM_DEV_ERROR(dev, "get clk rate failed\n");
ret = -EINVAL;
goto err_set_rate;
}
- cdn_dp_set_fw_clk(dp, rate);
- cdn_dp_clock_reset(dp);
+ cdns_mhdp_set_fw_clk(>mhdp, rate);
+ cdns_mhdp_clock_reset(>mhdp);
return 0;
err_set_rate:
- pm_runtime_put(dp->dev);
+ pm_runtime_put(dev);
err_pm_runtime_get:
clk_disable_unprepare(dp->core_clk);
err_core_clk:
@@ -143,7 +144,7 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
static void cdn_dp_clk_disable(struct cdn_dp_device *dp)
{
- pm_runtime_put_sync(dp->dev);
+ pm_runtime_put_sync(dp->mhdp.dev);
clk_disable_unprepare(dp->pclk);
clk_disable_unprepare(dp->core_clk);
}
@@ -176,7 +177,7 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp,
u8 *sink_count)
u8 value;
*sink_count = 0;
- ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, , 1);
+ ret = cdns_mhdp_dpcd_read(>mhdp, DP_SINK_COUNT, , 1);
if (ret)
return ret;
@@ -200,12 +201,13 @@ static struct cdn_dp_port *cdn_dp_connected_port(struct
cdn_dp_device *dp)
static bool cdn_dp_check_sink_connection(struct cdn_dp_device *dp)
{
+ struct device *dev = dp->mhdp.dev;
unsigned long timeout = jiffies + msecs_to_jiffies(CDN_DPCD_TIMEOUT_MS);
struct
Re: [PATCH v7 1/2] drm/panel: Add support for Truly NT35597 panel driver
On Wed 19 Sep 19:55 PDT 2018, Abhinav Kumar wrote:
> +static int truly_nt35597_probe(struct mipi_dsi_device *dsi)
> +{
[..]
> + dsi1 = of_graph_get_remote_node(dsi->dev.of_node, 1, -1);
> + if (!dsi1) {
> + DRM_DEV_ERROR(dev,
> + "failed to get remote node for dsi1_device\n");
> + ret = -ENODEV;
> + goto err_get_remote;
> + }
> +
> + dsi1_host = of_find_mipi_dsi_host_by_node(dsi1);
> + if (!dsi1_host) {
> + DRM_DEV_ERROR(dev, "failed to find dsi host\n");
> + ret = -EPROBE_DEFER;
> + goto err_host;
> + }
> +
> + of_node_put(dsi1);
> +
> + /* register the second DSI device */
> + dsi1_device = mipi_dsi_device_register_full(dsi1_host, );
> + if (IS_ERR(dsi1_device)) {
[..]
> + goto err_dsi_device;
[..]
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev,
> + "dsi attach failed i = %d\n", i);
> + goto err_dsi_attach;
> + }
> + }
> +
> + return 0;
> +
> +err_dsi_attach:
> + drm_panel_remove(>panel);
> +err_panel_add:
> + mipi_dsi_device_unregister(dsi1_device);
> +err_dsi_device:
> +err_host:
> + of_node_put(dsi1);
dsi1 is already put if we came here through err_dsi_device et al.
You don't need to reference dsi1 beyond the call to
of_find_mipi_dsi_host_by_node() to put it before checking the dsi1_host.
> +err_get_remote:
> + return ret;
> +}
Regards,
Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: sis: Remove unnecessary parentheses and commented code
Clang warns when multiple pairs of parentheses are used for a single
conditional statement.
drivers/video/fbdev/sis/init301.c:851:42: warning: equality comparison
with extraneous parentheses [-Wparentheses-equality]
} else if((SiS_Pr->SiS_IF_DEF_LVDS == 1) /* ||
^~~~
drivers/video/fbdev/sis/init301.c:851:42: note: remove extraneous
parentheses around the comparison to silence this warning
} else if((SiS_Pr->SiS_IF_DEF_LVDS == 1) /* ||
~^ ~
drivers/video/fbdev/sis/init301.c:851:42: note: use '=' to turn this
equality comparison into an assignment
} else if((SiS_Pr->SiS_IF_DEF_LVDS == 1) /* ||
^~
=
1 warning generated.
Remove the parentheses and while we're at it, clean up the commented
code, which has been here since the beginning of git history.
Link: https://github.com/ClangBuiltLinux/linux/issues/118
Signed-off-by: Nathan Chancellor
---
drivers/video/fbdev/sis/init301.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/sis/init301.c
b/drivers/video/fbdev/sis/init301.c
index 27a2b72e50e8..a8fb41f1a258 100644
--- a/drivers/video/fbdev/sis/init301.c
+++ b/drivers/video/fbdev/sis/init301.c
@@ -848,9 +848,7 @@ SiS_PanelDelay(struct SiS_Private *SiS_Pr, unsigned short
DelayTime)
SiS_DDC2Delay(SiS_Pr, 0x4000);
}
- } else if((SiS_Pr->SiS_IF_DEF_LVDS == 1) /* ||
-(SiS_Pr->SiS_CustomT == CUT_COMPAQ1280) ||
-(SiS_Pr->SiS_CustomT == CUT_CLEVO1400) */ ) { /* 315
series, LVDS; Special */
+ } else if (SiS_Pr->SiS_IF_DEF_LVDS == 1) { /* 315
series, LVDS; Special */
if(SiS_Pr->SiS_IF_DEF_CH70xx == 0) {
PanelID = SiS_GetReg(SiS_Pr->SiS_P3d4,0x36);
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Bug report: HiBMC crash
Hi John,
Thank you for reporting bug.
I am now using 4.18.7. I haven't found this issue yet.
I will try linux-next and figure out what's wrong with it.
Thanks,
Xinliang
On 2018/9/20 19:23, John Garry wrote:
On 20/09/2018 11:04, John Garry wrote:
Hi,
I am seeing this crash below on linux-next (20 Sept).
This is on an arm64 D05 board, which includes the HiBMC device. D06 was
also crashing for what looked like same reason. I am using standard
defconfig, except DRM and DRM_HISI_HIBMC are built-in.
Is this a known issue? I tested v4.19-rc3 and it had no such crash.
The origin seems to be here, where pointer info is not checked for NULL
for safety:
static int framebuffer_check(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *r)
{
...
/* now let the driver pick its own format info */
info = drm_get_format_info(dev, r);
...
for (i = 0; i < info->num_planes; i++) {
unsigned int width = fb_plane_width(r->width, info, i);
unsigned int height = fb_plane_height(r->height, info, i);
unsigned int cpp = info->cpp[i];
Upon closer inspection the crash is actually from hibmc probe error
handling path, specifically
hibmc_fbdev_destroy()->drm_framebuffer_put() is called with fb holding
the error value from hibmc_framebuffer_init(), as shown:
static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
{
...
hi_fbdev->fb = hibmc_framebuffer_init(priv->dev, _cmd, gobj);
if (IS_ERR(hi_fbdev->fb)) {
ret = PTR_ERR(hi_fbdev->fb);
*** hi_fbdev->fb holds error code ***
DRM_ERROR("failed to initialize framebuffer: %d\n", ret);
goto out_release_fbi;
}
static void hibmc_fbdev_destroy(struct hibmc_fbdev *fbdev)
{
struct hibmc_framebuffer *gfb = fbdev->fb;
struct drm_fb_helper *fbh = >helper;
drm_fb_helper_unregister_fbi(fbh);
drm_fb_helper_fini(fbh);
**>fb holds error code, not pointer ***
if (gfb)
drm_framebuffer_put(>fb);
}
This change fixes the crash for me:
hi_fbdev->fb = hibmc_framebuffer_init(priv->dev, _cmd, gobj);
if (IS_ERR(hi_fbdev->fb)) {
ret = PTR_ERR(hi_fbdev->fb);
+hi_fbdev->fb = NULL;
DRM_ERROR("failed to initialize framebuffer: %d\n", ret);
goto out_release_fbi;
}
Why we're hitting the error path at all, I don't know.
And, having said all that, the code I pointed out in
framebuffer_check() still does not seem safe for same reason I
mentioned originally.
John
John
[9.220446] pci 0007:90:00.0: can't derive routing for PCI INT A
[9.226517] hibmc-drm 0007:91:00.0: PCI INT A: no GSI
[9.231847] [TTM] Zone kernel: Available graphics memory:
16297696 kiB
[9.238536] [TTM] Zone dma32: Available graphics memory: 2097152
kiB
[9.245133] [TTM] Initializing pool allocator
[9.249536] [TTM] Initializing DMA pool allocator
[9.254340] [drm] Supports vblank timestamp caching Rev 2
(21.10.2013).
[9.261026] [drm] No driver support for vblank timestamp query.
[9.272431] WARNING: CPU: 16 PID: 293 at
drivers/gpu/drm/drm_fourcc.c:221 drm_format_info.part.1+0x0/0x8
[9.282014] Modules linked in:
[9.285095] CPU: 16 PID: 293 Comm: kworker/16:1 Not tainted
4.19.0-rc4-next-20180920-1-g9b0012c #322
[9.294677] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon
D05 IT21 Nemo 2.0 RC0 04/18/2018
[9.303915] Workqueue: events work_for_cpu_fn
[9.308314] pstate: 6005 (nZCv daif -PAN -UAO)
[9.313150] pc : drm_format_info.part.1+0x0/0x8
[9.317724] lr : drm_get_format_info+0x90/0x98
[9.322208] sp : 0af1baf0
[9.325549] x29: 0af1baf0 x28:
[9.330915] x27: 0af1bcb0 x26: 8017d3018800
[9.336279] x25: 8017d28a0018 x24: 8017d2f80018
[9.341644] x23: 8017d3018670 x22: 0af1bbf0
[9.347009] x21: 8017d3018a70 x20: 0af1bbf0
[9.352373] x19: 0af1bbf0 x18:
[9.357737] x17: x16:
[9.363102] x15: 092296c8 x14: 09074000
[9.368466] x13: x12:
[9.373831] x11: 8017fbffe008 x10: 8017db9307e8
[9.379195] x9 : x8 : 8017b517c800
[9.384560] x7 : x6 : 003f
[9.389924] x5 : 0040 x4 :
[9.395289] x3 : 08d04000 x2 : 56555941
[9.400654] x1 : 08d04f70 x0 : 0044
[9.406019] Call trace:
[9.408483] drm_format_info.part.1+0x0/0x8
[9.412705] drm_helper_mode_fill_fb_struct+0x20/0x80
[9.417807] hibmc_framebuffer_init+0x48/0xd0
[9.422204] hibmc_drm_fb_create+0x1ec/0x3c8
[9.426513] __drm_fb_helper_initial_config_and_unlock+0x1cc/0x418
[9.432756] drm_fb_helper_initial_config+0x3c/0x48
[9.437681] hibmc_fbdev_init+0xb4/0x198
[9.441638]
Bug report: HiBMC crash
Hi,
I am seeing this crash below on linux-next (20 Sept).
This is on an arm64 D05 board, which includes the HiBMC device. D06 was
also crashing for what looked like same reason. I am using standard
defconfig, except DRM and DRM_HISI_HIBMC are built-in.
Is this a known issue? I tested v4.19-rc3 and it had no such crash.
The origin seems to be here, where pointer info is not checked for NULL
for safety:
static int framebuffer_check(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *r)
{
...
/* now let the driver pick its own format info */
info = drm_get_format_info(dev, r);
...
for (i = 0; i < info->num_planes; i++) {
unsigned int width = fb_plane_width(r->width, info, i);
unsigned int height = fb_plane_height(r->height, info, i);
unsigned int cpp = info->cpp[i];
John
[9.220446] pci 0007:90:00.0: can't derive routing for PCI INT A
[9.226517] hibmc-drm 0007:91:00.0: PCI INT A: no GSI
[9.231847] [TTM] Zone kernel: Available graphics memory: 16297696 kiB
[9.238536] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[9.245133] [TTM] Initializing pool allocator
[9.249536] [TTM] Initializing DMA pool allocator
[9.254340] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[9.261026] [drm] No driver support for vblank timestamp query.
[9.272431] WARNING: CPU: 16 PID: 293 at
drivers/gpu/drm/drm_fourcc.c:221 drm_format_info.part.1+0x0/0x8
[9.282014] Modules linked in:
[9.285095] CPU: 16 PID: 293 Comm: kworker/16:1 Not tainted
4.19.0-rc4-next-20180920-1-g9b0012c #322
[9.294677] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon
D05 IT21 Nemo 2.0 RC0 04/18/2018
[9.303915] Workqueue: events work_for_cpu_fn
[9.308314] pstate: 6005 (nZCv daif -PAN -UAO)
[9.313150] pc : drm_format_info.part.1+0x0/0x8
[9.317724] lr : drm_get_format_info+0x90/0x98
[9.322208] sp : 0af1baf0
[9.325549] x29: 0af1baf0 x28:
[9.330915] x27: 0af1bcb0 x26: 8017d3018800
[9.336279] x25: 8017d28a0018 x24: 8017d2f80018
[9.341644] x23: 8017d3018670 x22: 0af1bbf0
[9.347009] x21: 8017d3018a70 x20: 0af1bbf0
[9.352373] x19: 0af1bbf0 x18:
[9.357737] x17: x16:
[9.363102] x15: 092296c8 x14: 09074000
[9.368466] x13: x12:
[9.373831] x11: 8017fbffe008 x10: 8017db9307e8
[9.379195] x9 : x8 : 8017b517c800
[9.384560] x7 : x6 : 003f
[9.389924] x5 : 0040 x4 :
[9.395289] x3 : 08d04000 x2 : 56555941
[9.400654] x1 : 08d04f70 x0 : 0044
[9.406019] Call trace:
[9.408483] drm_format_info.part.1+0x0/0x8
[9.412705] drm_helper_mode_fill_fb_struct+0x20/0x80
[9.417807] hibmc_framebuffer_init+0x48/0xd0
[9.422204] hibmc_drm_fb_create+0x1ec/0x3c8
[9.426513] __drm_fb_helper_initial_config_and_unlock+0x1cc/0x418
[9.432756] drm_fb_helper_initial_config+0x3c/0x48
[9.437681] hibmc_fbdev_init+0xb4/0x198
[9.441638] hibmc_pci_probe+0x2f4/0x3c8
[9.445598] local_pci_probe+0x3c/0xb0
[9.449379] work_for_cpu_fn+0x18/0x28
[9.453161] process_one_work+0x1e0/0x318
[9.457207] worker_thread+0x228/0x450
[9.460988] kthread+0x128/0x130
[9.464244] ret_from_fork+0x10/0x18
[9.467850] ---[ end trace 2695ffa0af5be373 ]---
[9.472525] WARNING: CPU: 16 PID: 293 at
drivers/gpu/drm/drm_framebuffer.c:730 drm_framebuffer_init+0x18/0x110
[9.482634] Modules linked in:
[9.485714] CPU: 16 PID: 293 Comm: kworker/16:1 Tainted: GW
4.19.0-rc4-next-20180920-1-g9b0012c #322
[9.496702] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon
D05 IT21 Nemo 2.0 RC0 04/18/2018
[9.505936] Workqueue: events work_for_cpu_fn
[9.510333] pstate: 6005 (nZCv daif -PAN -UAO)
[9.515170] pc : drm_framebuffer_init+0x18/0x110
[9.519831] lr : hibmc_framebuffer_init+0x60/0xd0
[9.524578] sp : 0af1baf0
[9.527920] x29: 0af1baf0 x28:
[9.533284] x27: 0af1bcb0 x26: 8017d3018800
[9.538649] x25: 8017d28a0018 x24: 8017d2f80018
[9.544014] x23: 8017d3018670 x22: 0af1bbf0
[9.549378] x21: 8017d3018a70 x20: 8017d242
[9.554743] x19: 8017b517c700 x18:
[9.560108] x17: x16:
[9.565472] x15: 092296c8 x14: 09074000
[9.570837] x13: x12:
[9.576201] x11: 8017fbffe008 x10: 8017db9307e8
[9.581566] x9 : x8 : 8017b517c800
[9.586930] x7 : x6 : 003f
[9.592295] x5 : 0040 x4 :
[
[PATCH v4 2/5] drm/dp: fix link probing for devices supporting DP 1.4+
From: Quentin Schulz
DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
"true capabilities" of DPRX device.
Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
might falsely return lower capabilities to "avoid interoperability
issues with some of the existing DP Source devices that malfunction
when they discover the higher capabilities within those three
registers.".
Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was reserved
and read 0 so it's safe to check against it even if DP revision is
<1.4
Signed-off-by: Quentin Schulz
Signed-off-by: Damian Kos
---
drivers/gpu/drm/drm_dp_helper.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 8c6b9fd89f8a..735ebde5c2f0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -370,10 +370,38 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
drm_dp_link *link)
{
u8 values[3];
int err;
+ unsigned int addr;
memset(link, 0, sizeof(*link));
- err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
+ /*
+* DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
+* DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
+* DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
+* DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
+* DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
+* "true capabilities" of DPRX device.
+*
+* Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
+* might falsely return lower capabilities to "avoid interoperability
+* issues with some of the existing DP Source devices that malfunction
+* when they discover the higher capabilities within those three
+* registers.".
+*
+* Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was
reserved
+* and read 0 so it's safe to check against it even if DP revision is
+* <1.4
+*/
+ err = drm_dp_dpcd_readb(aux, DP_TRAINING_AUX_RD_INTERVAL, values);
+ if (err < 0)
+ return err;
+
+ if (values[0] & DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT)
+ addr = DP_DP13_DPCD_REV;
+ else
+ addr = DP_DPCD_REV;
+
+ err = drm_dp_dpcd_read(aux, addr, values, sizeof(values));
if (err < 0)
return err;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND 0/5] drm/mxsfb: Fix runtime PM for unpowering lcdif block
On Mon, 2018-09-17 at 16:37 -0700, Stefan Agner wrote: > On 17.09.2018 12:16, Sean Paul wrote: > > On Mon, Sep 17, 2018 at 04:42:10PM +0300, Leonard Crestez wrote: > > > Adding lcdif nodes to a power domain currently doesn't work, it results > > > in black/corrupted screens or hangs. While the driver does enable > > > runtime pm it does not deal correctly with the block being unpowered. > > > > > > All patches in this series have review tags from a while ago and I > > > tested them again on top of next-20180913. No changes > > > > > > This series stalled so I reached out to Marek on IRC and he was > > > surprised to be listed as maintainer > > > > Hopefully not too surprised since Marek added themself to MAINTAINERS when > > adding the driver :-) > > There have been some confusion about the DRM development processes > around the mxsfb already in the past. > > > I suppose we should probably move this to drm-misc since it qualifies as a > > "small driver" and needs a home. Looking through git history shows the last > > mxsfb-specific change was back in 02/17. Everything else has been drm-wide > > refactors. Thoughts? > > > > Marek/Leonard: Care to sign up to be listed as a reviewers? > > drm-misc seems to make sense. I volunteer to be listed as reviewer or > co-maintainer. This gets +1 from me, you were very helpful during review. Next would be for one of the drm-misc maintainers to post a change for the MAINTAINER file and also merge my series? -- Regards, Leonard ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v4 1/2] drm: Add generic colorkey properties for display planes
Hello Laurent,
Sorry for the late response.
On 8/14/18 12:48 PM, Laurent Pinchart wrote:
Hi Dmitry,
Thank you for the patch. > On Tuesday, 7 August 2018 20:22:01 EEST Dmitry
Osipenko wrote:
From: Laurent Pinchart
Color keying is the action of replacing pixels matching a given color
(or range of colors) with transparent pixels in an overlay when
performing blitting. Depending on the hardware capabilities, the
matching pixel can either become fully transparent or gain adjustment
of the pixels component values.
Color keying is found in a large number of devices whose capabilities
often differ, but they still have enough common features in range to
standardize color key properties. This commit adds new generic DRM plane
properties related to the color keying, providing initial color keying
support.
Signed-off-by: Laurent Pinchart
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_atomic.c | 20 +
drivers/gpu/drm/drm_blend.c | 150 +++
include/drm/drm_blend.h | 3 +
include/drm/drm_plane.h | 91 +
4 files changed, 264 insertions(+)
[snip]
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index a16a74d7e15e..13c61dd0d9b7 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -107,6 +107,11 @@
* planes. Without this property the primary plane is always below the
cursor *plane, and ordering between all other planes is undefined.
*
+ * colorkey:
+ * Color keying is set up with drm_plane_create_colorkey_properties().
+ * It adds support for actions like replacing a range of colors with a
+ * transparent color in the plane. Color keying is disabled by default.
+ *
* Note that all the property extensions described here apply either to the
* plane or the CRTC (e.g. for the background color, which currently is not
* exposed and assumed to be black).
@@ -448,3 +453,148 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
return 0;
}
EXPORT_SYMBOL(drm_atomic_normalize_zpos);
+
+static const char * const plane_colorkey_mode_name[] = {
+ [DRM_PLANE_COLORKEY_MODE_DISABLED] = "disabled",
+ [DRM_PLANE_COLORKEY_MODE_TRANSPARENT] = "transparent",
+};
+
+/**
+ * drm_plane_create_colorkey_properties - create colorkey properties
+ * @plane: drm plane
+ * @supported_modes: bitmask of supported color keying modes
+ *
+ * This function creates the generic color keying properties and attaches
them
+ * to the @plane to enable color keying control for blending operations.
+ *
+ * Glossary:
+ *
+ * Destination plane:
+ * Plane to which color keying properties are applied, this planes takes
+ * the effect of color keying operation. The effect is determined by a
+ * given color keying mode.
+ *
+ * Source plane:
+ * Pixels of this plane are the source for color key matching operation.
+ *
+ * Color keying is controlled by these properties:
+ *
+ * colorkey.plane_mask:
+ * The mask property specifies which planes participate in color key
+ * matching process, these planes are the color key sources.
+ *
+ * Drivers return an error from their plane atomic check if plane can't be
+ * handled.
This seems fragile to me. We don't document how userspace determines which
planes need to be specified here, and we don't document what happens if a
plane underneath the destination plane is not specified in the mask. More
precise documentation is needed if we want to use such a property.
I'll add couple more words.
It also seems quite complex. Is an explicit plane mask really the best option
? What's the reason why planes couldn't be handled ? How do drivers determine
that ?
The reasons for that property:
1) HW limitations. IIUC, some of the Intel HW has a limitation such that only a
subset of planes could participate in the color keying. That should be also the
case for Tegra and others.
Drivers know all available HW capabilities, hence they know exactly what could
be handled.
2) Flexibility. This gives userspace more variants of how color keying could be
performed.
Whether it's the best option is questionable, I don't have better ideas for now.
+ * colorkey.mode:
+ * The mode is an enumerated property that controls how color keying
+ * operates.
A link to the drm_plane_colorkey_mode enum documentation would be useful.
Okay.
+ * colorkey.mask:
+ * This property specifies the pixel components mask. Unmasked pixel
+ * components are not participating in the matching. This mask value is
+ * applied to colorkey.min / max values. The mask value is given in a
+ * 64-bit integer in ARGB16161616 format, where A is the alpha value and
+ * R, G and B correspond to the color components. Drivers shall convert
+ * ARGB16161616 value into appropriate format within planes atomic check.
+ *
+ * Drivers return an error from their plane atomic check if mask can't be
+ * handled.
+
Re: Bug report: HiBMC crash
On 20/09/2018 11:04, John Garry wrote:
Hi,
I am seeing this crash below on linux-next (20 Sept).
This is on an arm64 D05 board, which includes the HiBMC device. D06 was
also crashing for what looked like same reason. I am using standard
defconfig, except DRM and DRM_HISI_HIBMC are built-in.
Is this a known issue? I tested v4.19-rc3 and it had no such crash.
The origin seems to be here, where pointer info is not checked for NULL
for safety:
static int framebuffer_check(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *r)
{
...
/* now let the driver pick its own format info */
info = drm_get_format_info(dev, r);
...
for (i = 0; i < info->num_planes; i++) {
unsigned int width = fb_plane_width(r->width, info, i);
unsigned int height = fb_plane_height(r->height, info, i);
unsigned int cpp = info->cpp[i];
Upon closer inspection the crash is actually from hibmc probe error
handling path, specifically hibmc_fbdev_destroy()->drm_framebuffer_put()
is called with fb holding the error value from hibmc_framebuffer_init(),
as shown:
static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
{
...
hi_fbdev->fb = hibmc_framebuffer_init(priv->dev, _cmd, gobj);
if (IS_ERR(hi_fbdev->fb)) {
ret = PTR_ERR(hi_fbdev->fb);
*** hi_fbdev->fb holds error code ***
DRM_ERROR("failed to initialize framebuffer: %d\n", ret);
goto out_release_fbi;
}
static void hibmc_fbdev_destroy(struct hibmc_fbdev *fbdev)
{
struct hibmc_framebuffer *gfb = fbdev->fb;
struct drm_fb_helper *fbh = >helper;
drm_fb_helper_unregister_fbi(fbh);
drm_fb_helper_fini(fbh);
** >fb holds error code, not pointer ***
if (gfb)
drm_framebuffer_put(>fb);
}
This change fixes the crash for me:
hi_fbdev->fb = hibmc_framebuffer_init(priv->dev, _cmd, gobj);
if (IS_ERR(hi_fbdev->fb)) {
ret = PTR_ERR(hi_fbdev->fb);
+ hi_fbdev->fb = NULL;
DRM_ERROR("failed to initialize framebuffer: %d\n", ret);
goto out_release_fbi;
}
Why we're hitting the error path at all, I don't know.
And, having said all that, the code I pointed out in framebuffer_check()
still does not seem safe for same reason I mentioned originally.
John
John
[9.220446] pci 0007:90:00.0: can't derive routing for PCI INT A
[9.226517] hibmc-drm 0007:91:00.0: PCI INT A: no GSI
[9.231847] [TTM] Zone kernel: Available graphics memory: 16297696 kiB
[9.238536] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[9.245133] [TTM] Initializing pool allocator
[9.249536] [TTM] Initializing DMA pool allocator
[9.254340] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[9.261026] [drm] No driver support for vblank timestamp query.
[9.272431] WARNING: CPU: 16 PID: 293 at
drivers/gpu/drm/drm_fourcc.c:221 drm_format_info.part.1+0x0/0x8
[9.282014] Modules linked in:
[9.285095] CPU: 16 PID: 293 Comm: kworker/16:1 Not tainted
4.19.0-rc4-next-20180920-1-g9b0012c #322
[9.294677] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon
D05 IT21 Nemo 2.0 RC0 04/18/2018
[9.303915] Workqueue: events work_for_cpu_fn
[9.308314] pstate: 6005 (nZCv daif -PAN -UAO)
[9.313150] pc : drm_format_info.part.1+0x0/0x8
[9.317724] lr : drm_get_format_info+0x90/0x98
[9.322208] sp : 0af1baf0
[9.325549] x29: 0af1baf0 x28:
[9.330915] x27: 0af1bcb0 x26: 8017d3018800
[9.336279] x25: 8017d28a0018 x24: 8017d2f80018
[9.341644] x23: 8017d3018670 x22: 0af1bbf0
[9.347009] x21: 8017d3018a70 x20: 0af1bbf0
[9.352373] x19: 0af1bbf0 x18:
[9.357737] x17: x16:
[9.363102] x15: 092296c8 x14: 09074000
[9.368466] x13: x12:
[9.373831] x11: 8017fbffe008 x10: 8017db9307e8
[9.379195] x9 : x8 : 8017b517c800
[9.384560] x7 : x6 : 003f
[9.389924] x5 : 0040 x4 :
[9.395289] x3 : 08d04000 x2 : 56555941
[9.400654] x1 : 08d04f70 x0 : 0044
[9.406019] Call trace:
[9.408483] drm_format_info.part.1+0x0/0x8
[9.412705] drm_helper_mode_fill_fb_struct+0x20/0x80
[9.417807] hibmc_framebuffer_init+0x48/0xd0
[9.422204] hibmc_drm_fb_create+0x1ec/0x3c8
[9.426513] __drm_fb_helper_initial_config_and_unlock+0x1cc/0x418
[9.432756] drm_fb_helper_initial_config+0x3c/0x48
[9.437681] hibmc_fbdev_init+0xb4/0x198
[9.441638] hibmc_pci_probe+0x2f4/0x3c8
[9.445598] local_pci_probe+0x3c/0xb0
[9.449379]
Re: [BUG] i915 HDMI connector status is connected after disconnection
On Wed, Sep 19, 2018 at 8:08 PM, Jani Nikula wrote:
> On Wed, 19 Sep 2018, Chris Chiu wrote:
>> I tried to add a slight delay in the hotplug work as follows
>>
>> --- a/drivers/gpu/drm/i915/intel_hotplug.c
>> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
>> @@ -378,6 +378,8 @@ static void do_i915_hotplug_check(struct work_struct
>> *work,
>>
>> spin_unlock_irq(_priv->irq_lock);
>>
>> + msleep(100);
>> +
>> drm_connector_list_iter_begin(dev, _iter);
>> drm_for_each_connector_iter(connector, _iter) {
>> intel_connector = to_intel_connector(connector);
>>
>> It does work in most cases, but still fail to update the status if I
>> unplug the HDMI
>> cable very slow. I basically pull the HDMI cable in loose connected
>> state first, and
>> hold in that state ~1 second, totally unplug after that. The status in
>> sysfs will report
>> connected as it used to. There was no problem when I tried the patch
>> https://bugs.freedesktop.org/show_bug.cgi?id=107125#c8
>>
>> I'll try to modify this patch a little bit and send upstream for
>> discussion later. Please
>> advise if any. Thanks.
>
> Please let's not add excessive msleeps in work functions.
>
> My idea was more along the lines of making the hotplug function run in a
> delayed work. After a chat with Ville, below is what I came up with.
>
> Please let me know how it works. Feel free to toy with the
> delay. However, 1-2 seconds or more seems too much.
>
> BR,
> Jani.
>
Thanks to the patch. It works in most cases on my problematic laptops.
After lots
of experiments, ex. pull the cable out with different paces, range
delay from 300 to
800 msec, it makes no significant difference for a longer delay. So
300 msec is good
enough for most cases. It at least updates the status correctly with a
visible quick
display blink when disconnecting HDMI. And compared to other machines which have
no such problem, the HDMI cable slow pull out also result in the same
problem. I'll
say the test result is OK for me. Thanks.
Chris
>
>
> From 72515b3e856171e52e96bb74796774f595a7f418 Mon Sep 17 00:00:00 2001
> From: Jani Nikula
> Date: Tue, 18 Sep 2018 13:12:34 +0300
> Subject: [PATCH] drm/i915: delay hotplug scheduling
> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> Cc: Jani Nikula
>
> On some systems we get the hotplug irq on unplug before the DDC pins
> have been disconnected, resulting in connector status remaining
> connected. Since previous attempts at using hotplug live status before
> DDC have failed, the only viable option is to reduce the window for
> mistakes. Delay the hotplug processing.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_hotplug.c | 15 ++-
> 2 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7d4daa7412f1..27f579abddae 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -286,7 +286,7 @@ enum hpd_pin {
> #define HPD_STORM_DEFAULT_THRESHOLD 5
>
> struct i915_hotplug {
> - struct work_struct hotplug_work;
> + struct delayed_work hotplug_work;
>
> struct {
> unsigned long last_jiffies;
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 648a13c6043c..3af64daa5cfc 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -110,6 +110,8 @@ enum hpd_pin intel_hpd_pin_default(struct
> drm_i915_private *dev_priv,
> }
> }
>
> +#define HOTPLUG_DELAY_MS 300
> +
> #define HPD_STORM_DETECT_PERIOD1000
> #define HPD_STORM_REENABLE_DELAY (2 * 60 * 1000)
>
> @@ -319,7 +321,8 @@ static void i915_digport_work_func(struct work_struct
> *work)
> spin_lock_irq(_priv->irq_lock);
> dev_priv->hotplug.event_bits |= old_bits;
> spin_unlock_irq(_priv->irq_lock);
> - schedule_work(_priv->hotplug.hotplug_work);
> + schedule_delayed_work(_priv->hotplug.hotplug_work,
> + msecs_to_jiffies(HOTPLUG_DELAY_MS));
> }
> }
>
> @@ -329,7 +332,7 @@ static void i915_digport_work_func(struct work_struct
> *work)
> static void i915_hotplug_work_func(struct work_struct *work)
> {
> struct drm_i915_private *dev_priv =
> - container_of(work, struct drm_i915_private,
> hotplug.hotplug_work);
> + container_of(work, struct drm_i915_private,
> hotplug.hotplug_work.work);
> struct drm_device *dev = _priv->drm;
> struct intel_connector *intel_connector;
> struct intel_encoder *intel_encoder;
> @@ -466,7 +469,8 @@ void intel_hpd_irq_handler(struct drm_i915_private
> *dev_priv,
> if (queue_dig)
> queue_work(dev_priv->hotplug.dp_wq,
>
Re: [PATCH v3 0/3] ARM: OMAP1: ams-delta: Complete driver gpiod migration
* Janusz Krzysztofik [180919 18:13]: > On Monday, September 10, 2018 12:56:02 AM CEST Janusz Krzysztofik wrote: > > > > This is a follow up of initial submission of a series consisted of > > 6 changes, 3 of which have been already applied or reworkeed. > > > > > > Janusz Krzysztofik (3): > > video: fbdev: omapfb: lcd_ams_delta: use GPIO lookup table > > mtd: rawnand: ams-delta: use GPIO lookup table > > Hi Tony, > > Please ignore this patch. It may no longer be possible to merged it cleanly > with nand/next tree. I'll exclude it from the series, rebase on top of nand/ > next and submit via linux-mtd. OK sounds good to me. > That shouldn't affect the two remaining patches of the series which should > still apply and merge cleanly, but I can resend them renumbered if you wish. Up to the mtd and fb folks as far as I'm concerned :) Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/12] drm/mediatek: move hardware register to node data
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> The address of register DPI_H_FRE_CON is different in different IC.
> Using of_node data to find this address.
>
Reviewed-by: CK Hu
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 19 ---
> drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 1 -
> 2 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index d9373e67d328..74a32833bde1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -72,6 +73,7 @@ struct mtk_dpi {
> struct clk *tvd_clk;
> int irq;
> struct drm_display_mode mode;
> + const struct mtk_dpi_conf *conf;
> enum mtk_dpi_out_color_format color_format;
> enum mtk_dpi_out_yc_map yc_map;
> enum mtk_dpi_out_bit_num bit_num;
> @@ -117,6 +119,10 @@ struct mtk_dpi_yc_limit {
> u16 c_bottom;
> };
>
> +struct mtk_dpi_conf {
> + u32 reg_h_fre_con;
> +};
> +
> static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
> {
> u32 tmp = readl(dpi->regs + offset) & ~mask;
> @@ -342,7 +348,7 @@ static void mtk_dpi_config_swap_input(struct mtk_dpi
> *dpi, bool enable)
>
> static void mtk_dpi_config_2n_h_fre(struct mtk_dpi *dpi)
> {
> - mtk_dpi_mask(dpi, DPI_H_FRE_CON, H_FRE_2N, H_FRE_2N);
> + mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, H_FRE_2N, H_FRE_2N);
> }
>
> static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
> @@ -668,6 +674,10 @@ static const struct component_ops mtk_dpi_component_ops
> = {
> .unbind = mtk_dpi_unbind,
> };
>
> +static const struct mtk_dpi_conf mt8173_conf = {
> + .reg_h_fre_con = 0xe0,
> +};
> +
> static int mtk_dpi_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -682,6 +692,7 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> dpi->dev = dev;
> + dpi->conf = (struct mtk_dpi_conf *)of_device_get_match_data(dev);
>
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> dpi->regs = devm_ioremap_resource(dev, mem);
> @@ -761,8 +772,10 @@ static int mtk_dpi_remove(struct platform_device *pdev)
> }
>
> static const struct of_device_id mtk_dpi_of_ids[] = {
> - { .compatible = "mediatek,mt8173-dpi", },
> - {}
> + { .compatible = "mediatek,mt8173-dpi",
> + .data = _conf,
> + },
> + { },
> };
>
> struct platform_driver mtk_dpi_driver = {
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi_regs.h
> b/drivers/gpu/drm/mediatek/mtk_dpi_regs.h
> index 4b6ad4751a31..040444d7718d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi_regs.h
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi_regs.h
> @@ -223,6 +223,5 @@
> #define ESAV_CODE2 (0xFFF << 0)
> #define ESAV_CODE3_MSB BIT(16)
>
> -#define DPI_H_FRE_CON0xE0
> #define H_FRE_2N BIT(25)
> #endif /* __MTK_DPI_REGS_H */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 4.19-rc5
On Fri, Sep 21, 2018 at 10:06:58AM +1000, Dave Airlie wrote: > Hey Greg, > > Looks like a pretty run of the mill set of fixes for this stage, > > core: fix debugfs for atomic, fix the check for atomic for > non-modesetting drivers > amdgpu: adds a new PCI id, some kfd fixes and a sdma fix > i915: a bunch of GVT fixes. > vc4: scaling fix > vmwgfx: modesetting fixes and a old buffer eviction fix > udl: framebuffer destruction fix > sun4i: disable on R40 fix until next kernel > pl111: NULL termination on table fix Now pulled, thanks. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/5] drm/dp: fix link probing for devices supporting DP 1.4+
Thanks for the patch. Verified with the DP 1.4 spec and looks good to me.
Also look at the related patch that makes use of the correct extended
capabilities:
https://patchwork.freedesktop.org/patch/249400/
Reviewed-by: Manasi Navare
Manasi
On Thu, Sep 20, 2018 at 03:54:37PM +0100, Damian Kos wrote:
> From: Quentin Schulz
>
> DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
> DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
> DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
> DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
> DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
> "true capabilities" of DPRX device.
>
> Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
> might falsely return lower capabilities to "avoid interoperability
> issues with some of the existing DP Source devices that malfunction
> when they discover the higher capabilities within those three
> registers.".
>
> Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was reserved
> and read 0 so it's safe to check against it even if DP revision is
> <1.4
>
> Signed-off-by: Quentin Schulz
> Signed-off-by: Damian Kos
> ---
> drivers/gpu/drm/drm_dp_helper.c | 30 +-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 8c6b9fd89f8a..735ebde5c2f0 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -370,10 +370,38 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
> drm_dp_link *link)
> {
> u8 values[3];
> int err;
> + unsigned int addr;
>
> memset(link, 0, sizeof(*link));
>
> - err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
> + /*
> + * DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
> + * DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
> + * DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
> + * DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
> + * DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
> + * "true capabilities" of DPRX device.
> + *
> + * Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
> + * might falsely return lower capabilities to "avoid interoperability
> + * issues with some of the existing DP Source devices that malfunction
> + * when they discover the higher capabilities within those three
> + * registers.".
> + *
> + * Before DP 1.4, DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit was
> reserved
> + * and read 0 so it's safe to check against it even if DP revision is
> + * <1.4
> + */
> + err = drm_dp_dpcd_readb(aux, DP_TRAINING_AUX_RD_INTERVAL, values);
> + if (err < 0)
> + return err;
> +
> + if (values[0] & DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT)
> + addr = DP_DP13_DPCD_REV;
> + else
> + addr = DP_DPCD_REV;
> +
> + err = drm_dp_dpcd_read(aux, addr, values, sizeof(values));
> if (err < 0)
> return err;
>
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] drm: add support of syncobj timeline point wait v2
Am 21.09.2018 um 09:15 schrieb Zhou, David(ChunMing):
-Original Message-
From: amd-gfx On Behalf Of
Christian K?nig
Sent: Thursday, September 20, 2018 7:11 PM
To: Zhou, David(ChunMing) ; dri-
de...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Subject: Re: [PATCH 3/6] drm: add support of syncobj timeline point wait v2
Am 20.09.2018 um 13:03 schrieb Chunming Zhou:
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 99
+-
include/uapi/drm/drm.h | 14 +
4 files changed, 103 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h
b/drivers/gpu/drm/drm_internal.h index 0c4eb4a9ab31..566d44e3c782
100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -183,6 +183,8 @@ int drm_syncobj_fd_to_handle_ioctl(struct
drm_device *dev, void *data,
struct drm_file *file_private);
int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 6b4a633b4240..c0891614f516 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -669,6 +669,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT,
drm_syncobj_wait_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT,
drm_syncobj_timeline_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET,
drm_syncobj_reset_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL,
drm_syncobj_signal_ioctl,
diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c index 67472bd77c83..a43de0e4616c
100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -126,13 +126,14 @@ static void
drm_syncobj_add_callback_locked(struct drm_syncobj *syncobj,
}
static int drm_syncobj_fence_get_or_add_callback(struct drm_syncobj
*syncobj,
+u64 point,
struct dma_fence **fence,
struct drm_syncobj_cb *cb,
drm_syncobj_func_t func)
{
int ret;
- ret = drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ ret = drm_syncobj_search_fence(syncobj, point, 0, fence);
if (!ret)
return 1;
@@ -143,7 +144,7 @@ static int
drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
*/
if (!list_empty(>signal_pt_list)) {
spin_unlock(>lock);
- drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ drm_syncobj_search_fence(syncobj, point, 0, fence);
if (*fence)
return 1;
spin_lock(>lock);
@@ -358,7 +359,9 @@ void drm_syncobj_replace_fence(struct
drm_syncobj *syncobj,
spin_lock(>lock);
list_for_each_entry_safe(cur, tmp, >cb_list, node)
{
list_del_init(>node);
+ spin_unlock(>lock);
cur->func(syncobj, cur);
+ spin_lock(>lock);
That looks fishy to me. Why do we need to unlock
Cb func will call _search_fence, which will need to grab the lock, otherwise
deadlock.
and who guarantees that
tmp is still valid when we grab the lock again?
Sorry for that, quickly fix deadlock and forget to care that when debug.
How about splice to a tmp list, and then list_for _xxx without lock?
Yeah, that should work. Alternative is to use something like "while
(!list_empty()) { e = list_first_entry(); list_del(e)". But either
way should work.
Any other comment on patch series and libdrm patches? That one comment
increases a patch set version seems be overcommit.
On a first glance that stuff looked good, but give me till monday for
that. I'm currently in the middle of debugging issues.
Thanks,
Christian.
Thanks,
David Zhou
Apart from that can't see anything obvious wrong, but I certainly need to
take a closer look.
Christian.
}
Re: [PATCH libdrm 3/3] radeon: add missing drm_public exports
On 2018-09-20 8:31 p.m., Eric Engestrom wrote:
> On Thursday, 2018-09-20 18:21:41 +0100, Eric Engestrom wrote:
>> On Thursday, 2018-09-20 18:09:41 +0200, Michel Dänzer wrote:
>>> On 2018-09-20 5:58 p.m., Eric Engestrom wrote:
Fixes: 9f45264815eff6ebeba3 "radeon: annotate public functions"
Cc: Lucas De Marchi
Cc: Mark Janes
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108006
Signed-off-by: Eric Engestrom
---
radeon/radeon_bo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/radeon/radeon_bo.c b/radeon/radeon_bo.c
index cd06c26ee152d68f893d..91929532d5bf6e0daca8 100644
--- a/radeon/radeon_bo.c
+++ b/radeon/radeon_bo.c
@@ -67,13 +67,13 @@ drm_public struct radeon_bo *radeon_bo_unref(struct
radeon_bo *bo)
return boi->bom->funcs->bo_unref(boi);
}
-int radeon_bo_map(struct radeon_bo *bo, int write)
+drm_public int radeon_bo_map(struct radeon_bo *bo, int write)
{
struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
return boi->bom->funcs->bo_map(boi, write);
}
-int radeon_bo_unmap(struct radeon_bo *bo)
+drm_public int radeon_bo_unmap(struct radeon_bo *bo)
{
struct radeon_bo_int *boi = (struct radeon_bo_int *)bo;
return boi->bom->funcs->bo_unmap(boi);
>>>
>>> Reviewed-by: Michel Dänzer
>>> Tested-by: Michel Dänzer
>>
>> Thanks!
>>
>> radeon_cs_space_check was also missing, but my grep didn't catch it
>> because radeon_cs_space_check_with_bo matched my weak grep skills...
>>
>> I added drm_public to it too, can I still apply your tags, or do you
>> want a v2?
>
> I ended up pushing it with your r-b and t-b, because I'm going home and
> would rather not have left it like that too long :)
Good catch and good call, thanks again.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/18] video/hdmi: Constify infoframe passed to the log functions
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The log functions don't modify the passed in infoframe so make it const.
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
Acked-by: Hans Verkuil
Thanks,
Hans
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 22 +++---
> include/linux/hdmi.h | 2 +-
> 2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index b5d491014b0b..53e7ee2c83fc 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -471,7 +471,7 @@ static const char *hdmi_infoframe_type_get_name(enum
> hdmi_infoframe_type type)
>
> static void hdmi_infoframe_log_header(const char *level,
> struct device *dev,
> - struct hdmi_any_infoframe *frame)
> + const struct hdmi_any_infoframe *frame)
> {
> hdmi_log("HDMI infoframe: %s, version %u, length %u\n",
> hdmi_infoframe_type_get_name(frame->type),
> @@ -673,10 +673,10 @@ hdmi_content_type_get_name(enum hdmi_content_type
> content_type)
> */
> static void hdmi_avi_infoframe_log(const char *level,
> struct device *dev,
> -struct hdmi_avi_infoframe *frame)
> +const struct hdmi_avi_infoframe *frame)
> {
> hdmi_infoframe_log_header(level, dev,
> - (struct hdmi_any_infoframe *)frame);
> + (const struct hdmi_any_infoframe *)frame);
>
> hdmi_log("colorspace: %s\n",
> hdmi_colorspace_get_name(frame->colorspace));
> @@ -750,12 +750,12 @@ static const char *hdmi_spd_sdi_get_name(enum
> hdmi_spd_sdi sdi)
> */
> static void hdmi_spd_infoframe_log(const char *level,
> struct device *dev,
> -struct hdmi_spd_infoframe *frame)
> +const struct hdmi_spd_infoframe *frame)
> {
> u8 buf[17];
>
> hdmi_infoframe_log_header(level, dev,
> - (struct hdmi_any_infoframe *)frame);
> + (const struct hdmi_any_infoframe *)frame);
>
> memset(buf, 0, sizeof(buf));
>
> @@ -886,10 +886,10 @@ hdmi_audio_coding_type_ext_get_name(enum
> hdmi_audio_coding_type_ext ctx)
> */
> static void hdmi_audio_infoframe_log(const char *level,
>struct device *dev,
> - struct hdmi_audio_infoframe *frame)
> + const struct hdmi_audio_infoframe *frame)
> {
> hdmi_infoframe_log_header(level, dev,
> - (struct hdmi_any_infoframe *)frame);
> + (const struct hdmi_any_infoframe *)frame);
>
> if (frame->channels)
> hdmi_log("channels: %u\n", frame->channels - 1);
> @@ -949,12 +949,12 @@ hdmi_3d_structure_get_name(enum hdmi_3d_structure
> s3d_struct)
> static void
> hdmi_vendor_any_infoframe_log(const char *level,
> struct device *dev,
> - union hdmi_vendor_any_infoframe *frame)
> + const union hdmi_vendor_any_infoframe *frame)
> {
> - struct hdmi_vendor_infoframe *hvf = >hdmi;
> + const struct hdmi_vendor_infoframe *hvf = >hdmi;
>
> hdmi_infoframe_log_header(level, dev,
> - (struct hdmi_any_infoframe *)frame);
> + (const struct hdmi_any_infoframe *)frame);
>
> if (frame->any.oui != HDMI_IEEE_OUI) {
> hdmi_log("not a HDMI vendor infoframe\n");
> @@ -984,7 +984,7 @@ hdmi_vendor_any_infoframe_log(const char *level,
> */
> void hdmi_infoframe_log(const char *level,
> struct device *dev,
> - union hdmi_infoframe *frame)
> + const union hdmi_infoframe *frame)
> {
> switch (frame->any.type) {
> case HDMI_INFOFRAME_TYPE_AVI:
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index a577d4ae2570..bce1abb1fe57 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -335,6 +335,6 @@ hdmi_infoframe_pack(union hdmi_infoframe *frame, void
> *buffer, size_t size);
> int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
> const void *buffer, size_t size);
> void hdmi_infoframe_log(const char *level, struct device *dev,
> - union hdmi_infoframe *frame);
> + const union hdmi_infoframe *frame);
>
> #endif /* _DRM_HDMI_H */
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/18] video/hdmi: Pass buffer size to infoframe unpack functions
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make sure the infoframe unpack functions don't end up examining
> stack garbage or oopsing, let's pass in the size of the buffer.
>
> v2: Convert tda1997x.c as well (kbuild test robot)
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
Acked-by: Hans Verkuil
Thanks,
Hans
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/media/i2c/adv7511.c | 2 +-
> drivers/media/i2c/adv7604.c | 2 +-
> drivers/media/i2c/adv7842.c | 2 +-
> drivers/media/i2c/tc358743.c | 2 +-
> drivers/media/i2c/tda1997x.c | 4 ++--
> drivers/video/hdmi.c | 51
>
> include/linux/hdmi.h | 2 +-
> 7 files changed, 44 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
> index 55c2ea0720d9..b85b181bbb6c 100644
> --- a/drivers/media/i2c/adv7511.c
> +++ b/drivers/media/i2c/adv7511.c
> @@ -550,7 +550,7 @@ static void log_infoframe(struct v4l2_subdev *sd, const
> struct adv7511_cfg_read_
> buffer[3] = 0;
> buffer[3] = hdmi_infoframe_checksum(buffer, len + 4);
>
> - if (hdmi_infoframe_unpack(, buffer) < 0) {
> + if (hdmi_infoframe_unpack(, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__,
> cri->desc);
> return;
> }
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index 668be2bca57a..2e7a28dbad4e 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -2418,7 +2418,7 @@ static int adv76xx_read_infoframe(struct v4l2_subdev
> *sd, int index,
> buffer[i + 3] = infoframe_read(sd,
> adv76xx_cri[index].payload_addr + i);
>
> - if (hdmi_infoframe_unpack(frame, buffer) < 0) {
> + if (hdmi_infoframe_unpack(frame, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__,
>adv76xx_cri[index].desc);
> return -ENOENT;
> diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
> index 4f8fbdd00e35..2cfd03f929b2 100644
> --- a/drivers/media/i2c/adv7842.c
> +++ b/drivers/media/i2c/adv7842.c
> @@ -2563,7 +2563,7 @@ static void log_infoframe(struct v4l2_subdev *sd,
> struct adv7842_cfg_read_infofr
> for (i = 0; i < len; i++)
> buffer[i + 3] = infoframe_read(sd, cri->payload_addr + i);
>
> - if (hdmi_infoframe_unpack(, buffer) < 0) {
> + if (hdmi_infoframe_unpack(, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__,
> cri->desc);
> return;
> }
> diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
> index 44c41933415a..519bf92508d5 100644
> --- a/drivers/media/i2c/tc358743.c
> +++ b/drivers/media/i2c/tc358743.c
> @@ -444,7 +444,7 @@ static void print_avi_infoframe(struct v4l2_subdev *sd)
>
> i2c_rd(sd, PK_AVI_0HEAD, buffer, HDMI_INFOFRAME_SIZE(AVI));
>
> - if (hdmi_infoframe_unpack(, buffer) < 0) {
> + if (hdmi_infoframe_unpack(, buffer, sizeof(buffer)) < 0) {
> v4l2_err(sd, "%s: unpack of AVI infoframe failed\n", __func__);
> return;
> }
> diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
> index d114ac5243ec..195a1fc74ee8 100644
> --- a/drivers/media/i2c/tda1997x.c
> +++ b/drivers/media/i2c/tda1997x.c
> @@ -1253,7 +1253,7 @@ tda1997x_parse_infoframe(struct tda1997x_state *state,
> u16 addr)
>
> /* read data */
> len = io_readn(sd, addr, sizeof(buffer), buffer);
> - err = hdmi_infoframe_unpack(, buffer);
> + err = hdmi_infoframe_unpack(, buffer, sizeof(buffer));
> if (err) {
> v4l_err(state->client,
> "failed parsing %d byte infoframe: 0x%04x/0x%02x\n",
> @@ -1928,7 +1928,7 @@ static int tda1997x_log_infoframe(struct v4l2_subdev
> *sd, int addr)
> /* read data */
> len = io_readn(sd, addr, sizeof(buffer), buffer);
> v4l2_dbg(1, debug, sd, "infoframe: addr=%d len=%d\n", addr, len);
> - err = hdmi_infoframe_unpack(, buffer);
> + err = hdmi_infoframe_unpack(, buffer, sizeof(buffer));
> if (err) {
> v4l_err(state->client,
> "failed parsing %d byte infoframe: 0x%04x/0x%02x\n",
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 65b915ea4936..b5d491014b0b 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -1005,8 +1005,9 @@ EXPORT_SYMBOL(hdmi_infoframe_log);
>
> /**
> * hdmi_avi_infoframe_unpack() - unpack binary buffer to a HDMI AVI infoframe
> - * @buffer: source buffer
> * @frame: HDMI AVI infoframe
> + * @buffer: source buffer
> + * @size: size of buffer
> *
> * Unpacks the information contained in binary @buffer into a structured
> *
Re: [PATCH] drm: fix use of freed memory in drm_mode_setcrtc
On Mon, Sep 17, 2018 at 02:00:54PM +0300, Tomi Valkeinen wrote: > drm_mode_setcrtc() retries modesetting in case one of the functions it > calls returns -EDEADLK. connector_set, mode and fb are freed before > retrying, but they are not set to NULL. This can cause > drm_mode_setcrtc() to use those variables. > > For example: On the first try __drm_mode_set_config_internal() returns > -EDEADLK. connector_set, mode and fb are freed. Next retry starts, and > drm_modeset_lock_all_ctx() returns -EDEADLK, and we jump to 'out'. The > code will happily try to release all three again. > > This leads to crashes of different kinds, depending on the sequence the > EDEADLKs happen. > > Fix this by setting the three variables to NULL at the start of the > retry loop. > > Signed-off-by: Tomi Valkeinen > Cc: sta...@vger.kernel.org > --- > drivers/gpu/drm/drm_crtc.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 2f6c877299e4..2ad14593fb23 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -570,9 +570,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data, > struct drm_mode_crtc *crtc_req = data; > struct drm_crtc *crtc; > struct drm_plane *plane; > - struct drm_connector **connector_set = NULL, *connector; > - struct drm_framebuffer *fb = NULL; > - struct drm_display_mode *mode = NULL; > + struct drm_connector **connector_set, *connector; > + struct drm_framebuffer *fb; > + struct drm_display_mode *mode; > struct drm_mode_set set; > uint32_t __user *set_connectors_ptr; > struct drm_modeset_acquire_ctx ctx; > @@ -601,6 +601,10 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data, > mutex_lock(>dev->mode_config.mutex); > drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE); > retry: > + connector_set = NULL; > + fb = NULL; > + mode = NULL; Bit a bikeshed, but I'd reset the pointers right after we release/free them, in the out: block. Avoids accidental leaking. But it's fine either way. And I agree with Ville, I don't think we need a cc: stable here. Reviewed-by: Daniel Vetter > + > ret = drm_modeset_lock_all_ctx(crtc->dev, ); > if (ret) > goto out; > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/probe_helper: Don't bother probing when connectors are forced off
On Mon, Sep 17, 2018 at 05:12:04PM -0400, Lyude Paul wrote:
> On Mon, 2018-09-17 at 21:16 +0300, Ville Syrjälä wrote:
> > On Mon, Sep 17, 2018 at 02:10:02PM -0400, Lyude Paul wrote:
> > > On Mon, 2018-09-17 at 20:55 +0300, Ville Syrjälä wrote:
> > > > On Mon, Sep 17, 2018 at 01:43:44PM -0400, Lyude Paul wrote:
> > > > > Userspace asked them to be forced off, so why would we care about
> > > > > what a
> > > > > probe tells us?
> > > >
> > > > I believe there should be force checks in the callers already.
> > > > Or are we missing some?
> > >
> > > JFYI, what triggered me to send this patch are these error messages that
> > > come
> > > from nouveau when a hotplug happens on a port that we've forced off:
> > >
> > > [ 1903.918104] nouveau :01:00.0: DRM: DDC responded, but no EDID for
> > > DP-
> > > 2
> > > [ 1903.918123] [drm:drm_helper_hpd_irq_event [drm_kms_helper]]
> > > [CONNECTOR:61:DP-2] status updated from disconnected to disconnected
> > >
> > > That being said; I'm sure there are probably some checks missing, but I
> > > don't
> > > really see the purpose in calling the driver's probe functions at all if
> > > they're
> > > just supposed to return the status we forced.
> >
> > Digging through my cobweb ridden local git repository I found this:
> >
> > commit bbd17813a7c7d0210c619365707044d0fb29e3f0
> > Author: Ville Syrjälä
> > Date: Mon Jun 10 15:28:55 2013 +0300
> >
> > drm: Ignore forced connectors in drm_helper_hpd_irq_event()
> >
> > drm_helper_hpd_irq_event() calls the connector's .detect() function
> > even for forced connectors. If the returned status doesn't match the
> > forced status, we will send the hotplug event, causing userspace to
> > re-probe all the connectors. Eventually we should end up back where
> > we started when drm_helper_probe_single_connector_modes() overwrites
> > the connector status with the forced status.
> >
> > We can avoid all that pointles work if we just skip forced connectors
> > in drm_helper_hpd_irq_event().
> >
> > Signed-off-by: Ville Syrjälä
> >
> > diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> > b/drivers/gpu/drm/drm_crtc_helper.c
> > index ed1334e27c33..4fc2ad76c107 100644
> > --- a/drivers/gpu/drm/drm_crtc_helper.c
> > +++ b/drivers/gpu/drm/drm_crtc_helper.c
> > @@ -1086,6 +1086,10 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
> > mutex_lock(>mode_config.mutex);
> > list_for_each_entry(connector, >mode_config.connector_list, head) {
> >
> > + /* Ignore forced connectors. */
> > + if (connector->force)
> > + continue;
> > +
> > /* Only handle HPD capable connectors. */
> > if (!(connector->polled & DRM_CONNECTOR_POLL_HPD))
> > continue;
> >
> >
> > I guess I never sent it out.
>
> Ahhh, to be honest though this patch isn't really enough.
> drm_helper_hpd_irq_event() isn't going to be used by all drivers (I may remove
> some usage of it in nouveau in the near future, even) so I still think it
> would
> be a better idea to just add this into drm_helper_probe_detect() and
> drm_helper_probe_detect_ctx() so everything gets covered
Atm all connector->force handling is outside of drm_helper_probe_detect. I
guess we could try to push (some) of it into this helper, if that's
useful. There seems to be some duplication already. But adding a redundant
check like you do here feels a bit funky. Maybe makes more sense in
context of the nouveau stuff you're working on?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/2] drm: Fix syncobj handing of schedule() returning 0
Quoting Daniel Vetter (2018-09-21 10:15:41) > On Tue, Sep 18, 2018 at 11:07:20AM +0100, Chris Wilson wrote: > > After schedule() returns 0, we must do one last check of COND to > > determine the reason for the wakeup with 0 jiffies remaining before > > reporting the timeout -- otherwise we may lose the signal due to > > scheduler delays. > > Ah classic! > > Reviewed-by: Daniel Vetter Indeed, thanks for the reviews, pushed to drm-misc-next. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 09/12] drm/mediatek: add hdmi driver for MT2701 and MT7623
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> This patch adds hdmi dirver suppot for both MT2701 and MT7623.
> And also support other (existing or future) chips that use
> the same binding and driver.
>
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/Makefile | 3 +-
> drivers/gpu/drm/mediatek/mtk_hdmi.c| 9 +-
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 3 +
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 2 +
> drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 234
> +
> 5 files changed, 248 insertions(+), 3 deletions(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index 61cf0d2ab28a..82ae49c64221 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -19,7 +19,8 @@ obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
> mediatek-drm-hdmi-objs := mtk_cec.o \
> mtk_hdmi.o \
> mtk_hdmi_ddc.o \
> + mtk_mt2701_hdmi_phy.o \
> mtk_mt8173_hdmi_phy.o \
> mtk_hdmi_phy.o
>
> -obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> \ No newline at end of file
> +obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index d62e685cec73..11e3644da79a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -241,8 +241,13 @@ static void mtk_hdmi_hw_make_reg_writable(struct
> mtk_hdmi *hdmi, bool enable)
>* The ARM trusted firmware provides an API for the HDMI driver to set
>* this control bit to enable HDMI output in supervisor mode.
>*/
> - arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904, 0x8000,
> - 0, 0, 0, 0, 0, );
> + if (hdmi_phy->conf && hdmi_phy->conf->tz_disabled)
> + regmap_update_bits(hdmi->sys_regmap,
> +hdmi->sys_offset + HDMI_SYS_CFG20,
> +0x80008005, enable ? 0x8005 : 0x8000);
> + else
> + arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904,
> + 0x8000, 0, 0, 0, 0, 0, );
>
> regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
> HDMI_PCLK_FREE_RUN, enable ? HDMI_PCLK_FREE_RUN : 0);
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> index d2dc50db1feb..52d314deacdc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> @@ -192,6 +192,9 @@ static int mtk_hdmi_phy_probe(struct platform_device
> *pdev)
> }
>
> static const struct of_device_id mtk_hdmi_phy_match[] = {
> + { .compatible = "mediatek,mt2701-hdmi-phy",
> + .data = _hdmi_phy_2701_conf,
> + },
> { .compatible = "mediatek,mt8173-hdmi-phy",
> .data = _hdmi_phy_8173_conf,
> },
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> index e346fe319621..a6577c8fdf83 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> @@ -20,6 +20,7 @@
> struct mtk_hdmi_phy;
>
> struct mtk_hdmi_phy_conf {
> + bool tz_disabled;
> const struct clk_ops *hdmi_phy_clk_ops;
> void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
> void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
> @@ -50,5 +51,6 @@ struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
>
> extern struct platform_driver mtk_hdmi_phy_driver;
> extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
> +extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf;
>
> #endif /* _MTK_HDMI_PHY_H */
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> new file mode 100644
> index ..41f5dcc24c4e
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -0,0 +1,234 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Chunhui Dai
> + */
> +
> +#include "mtk_hdmi_phy.h"
> +
> +#define HDMI_CON00x00
> +#define RG_HDMITX_DRV_IBIAS 0
> +#define RG_HDMITX_DRV_IBIAS_MASK (0x3f << 0)
> +#define RG_HDMITX_EN_SER 12
> +#define RG_HDMITX_EN_SER_MASK(0x0f << 12)
> +#define RG_HDMITX_EN_SLDO16
> +#define RG_HDMITX_EN_SLDO_MASK (0x0f << 16)
> +#define RG_HDMITX_EN_PRED20
> +#define RG_HDMITX_EN_PRED_MASK (0x0f << 20)
> +#define RG_HDMITX_EN_IMP 24
> +#define RG_HDMITX_EN_IMP_MASK(0x0f << 24)
> +#define
Re: [PATCH 04/18] video/hdmi: Constify infoframe passed to the pack functions
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's make the infoframe pack functions usable with a const infoframe
> structure. This allows us to precompute the infoframe earlier, and still
> pack it later when we're no longer allowed to modify the structure.
> So now we end up with a _check()+_pack_only() or _pack() functions
> depending on whether you want to precompute the infoframes or not.
> The names aren't greate but I was lazy and didn't want to change all the
greate -> great
> drivers.
>
> v2: Deal with exynos churn
> Actually export the new funcs
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 425
> +++
> include/linux/hdmi.h | 19 ++-
> 2 files changed, 416 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 53e7ee2c83fc..9507f668a569 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -68,8 +68,36 @@ int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe
> *frame)
> }
> EXPORT_SYMBOL(hdmi_avi_infoframe_init);
>
> +static int hdmi_avi_infoframe_check_only(const struct hdmi_avi_infoframe
> *frame)
> +{
> + if (frame->type != HDMI_INFOFRAME_TYPE_AVI ||
> + frame->version != 2 ||
> + frame->length != HDMI_AVI_INFOFRAME_SIZE)
> + return -EINVAL;
> +
> + if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> /**
> - * hdmi_avi_infoframe_pack() - write HDMI AVI infoframe to binary buffer
> + * hdmi_avi_infoframe_check() - Check and check a HDMI AVI infoframe
"Check and check"? This is repeated elsewhere as well (clearly copy-and-paste).
> + * @frame: HDMI AVI infoframe
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_avi_infoframe_check(struct hdmi_avi_infoframe *frame)
> +{
> + return hdmi_avi_infoframe_check_only(frame);
> +}
> +EXPORT_SYMBOL(hdmi_avi_infoframe_check);
> +
> +/**
> + * hdmi_avi_infoframe_pack_only() - write HDMI AVI infoframe to binary buffer
> * @frame: HDMI AVI infoframe
> * @buffer: destination buffer
> * @size: size of buffer
> @@ -82,20 +110,22 @@ EXPORT_SYMBOL(hdmi_avi_infoframe_init);
> * Returns the number of bytes packed into the binary buffer or a negative
> * error code on failure.
> */
> -ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame, void
> *buffer,
> - size_t size)
> +ssize_t hdmi_avi_infoframe_pack_only(const struct hdmi_avi_infoframe *frame,
> + void *buffer, size_t size)
> {
> u8 *ptr = buffer;
> size_t length;
> + int ret;
> +
> + ret = hdmi_avi_infoframe_check_only(frame);
> + if (ret)
> + return ret;
>
> length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
>
> if (size < length)
> return -ENOSPC;
>
> - if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
> - return -EINVAL;
> -
> memset(buffer, 0, size);
>
> ptr[0] = frame->type;
> @@ -152,6 +182,36 @@ ssize_t hdmi_avi_infoframe_pack(struct
> hdmi_avi_infoframe *frame, void *buffer,
>
> return length;
> }
> +EXPORT_SYMBOL(hdmi_avi_infoframe_pack_only);
> +
> +/**
> + * hdmi_avi_infoframe_pack() - Check and check a HDMI AVI infoframe,
> + * and write it to binary buffer
> + * @frame: HDMI AVI infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields, after which packs the information
which packs -> which it packs
Ditto elsewhere.
> + * contained in the @frame structure into a binary representation that
> + * can be written into the corresponding controller registers. Also
Also -> This function also
Ditto elsewhere.
> + * computes the checksum as required by section 5.3.5 of the HDMI 1.4
> + * specification.
> + *
> + * Returns the number of bytes packed into the binary buffer or a negative
> + * error code on failure.
> + */
> +ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame,
> + void *buffer, size_t size)
> +{
> + int ret;
> +
> + ret = hdmi_avi_infoframe_check(frame);
> + if (ret)
> + return ret;
> +
> + return hdmi_avi_infoframe_pack_only(frame, buffer, size);
> +}
> EXPORT_SYMBOL(hdmi_avi_infoframe_pack);
>
> /**
> @@ -178,8 +238,33 @@ int hdmi_spd_infoframe_init(struct hdmi_spd_infoframe
> *frame,
> }
> EXPORT_SYMBOL(hdmi_spd_infoframe_init);
>
> +static int hdmi_spd_infoframe_check_only(const struct hdmi_spd_infoframe
> *frame)
> +{
> + if
Re: [PATCH v4 5/5] drm: bridge: add support for Cadence MHDP DPI/DP bridge
Hi Damian, Am Donnerstag, 20. September 2018, 16:54:40 CEST schrieb Damian Kos: > From: Quentin Schulz > > This adds basic support for Cadence MHDP DPI to DP bridge. > > Basically, it takes a DPI stream as input and output it encoded in DP > format. It's missing proper HPD, HDCP and currently supports only > SST mode. > > Changes made in the low level driver (cdn-dp-reg.*): > - moved it to from drivers/gpu/drm/rockchip to > drivers/gpu/drm/bridge/cdns-mhdp-common.* > - functions for sending/receiving commands are now public > - added functions for reading registers and link training > adjustment > > Changes made in RK's driver (cdn-dp-core.*): > - Moved audio_info and audio_pdev fields from cdn_dp_device to > cdns_mhdp_device structure. > > Signed-off-by: Quentin Schulz > Signed-off-by: Damian Kos [...] > diff --git a/drivers/gpu/drm/rockchip/Kconfig > b/drivers/gpu/drm/rockchip/Kconfig > index 0ccc76217ee4..129b0529f3e1 100644 > --- a/drivers/gpu/drm/rockchip/Kconfig > +++ b/drivers/gpu/drm/rockchip/Kconfig > @@ -27,7 +27,9 @@ config ROCKCHIP_ANALOGIX_DP > > config ROCKCHIP_CDN_DP > bool "Rockchip cdn DP" > - depends on EXTCON=y || (EXTCON=m && DRM_ROCKCHIP=m) > + depends on DRM_ROCKCHIP=m Sorry, I wasn't fast enough in my reply to you mail to catch that before your v4, but I don't think this is necessary. Instead I do guess, the select below should do the right thing by making EXTCON=y if DRM_ROCKCHIP=y. Somewhat clumsily verified by making EXTCON=m in my defconfig and seeing get changed to y upon build, which I guess comes from a different "select" in the config. > + select EXTCON > + select DRM_CDNS_MHDP > help > This selects support for Rockchip SoC specific extensions > for the cdn DP driver. If you want to enable Dp on > diff --git a/drivers/gpu/drm/rockchip/Makefile > b/drivers/gpu/drm/rockchip/Makefile > index a314e2109e76..16ba61ffca39 100644 > --- a/drivers/gpu/drm/rockchip/Makefile > +++ b/drivers/gpu/drm/rockchip/Makefile > @@ -3,13 +3,15 @@ > # Makefile for the drm device driver. This driver provides support for the > # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. > > +ccflags-y += -I$(src)/../bridge hmm, instead of adding an include path, the shared header should probably just live in /include/drm/bridge/... in the kernel source? Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We'll be wanting to send more than just infoframes over HDMI. So add an
> enum for other packet types.
>
> TODO: Maybe just include the infoframe types in the packet type enum
> and get rid of the infoframe type enum?
I think that's better, IMHO. With a comment that the types starting with
0x81 are defined in CTA-861-G.
It's really the same byte that is being checked, so having two enums is
a bit misleading. The main difference is really which standard defines
the packet types.
Regards,
Hans
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> include/linux/hdmi.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index c76b50a48e48..80521d9591a1 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -27,6 +27,21 @@
> #include
> #include
>
> +enum hdmi_packet_type {
> + HDMI_PACKET_TYPE_NULL = 0x00,
> + HDMI_PACKET_TYPE_AUDIO_CLOCK_REGEN = 0x01,
> + HDMI_PACKET_TYPE_AUDIO_SAMPLE = 0x02,
> + HDMI_PACKET_TYPE_GENERAL_CONTROL = 0x03,
> + HDMI_PACKET_TYPE_AUDIO_CP = 0x04,
> + HDMI_PACKET_TYPE_ISRC1 = 0x05,
> + HDMI_PACKET_TYPE_ISRC2 = 0x06,
> + HDMI_PACKET_TYPE_ONE_BIT_AUDIO_SAMPLE = 0x07,
> + HDMI_PACKET_TYPE_DST_AUDIO = 0x08,
> + HDMI_PACKET_TYPE_HBR_AUDIO_STREAM = 0x09,
> + HDMI_PACKET_TYPE_GAMUT_METADATA = 0x0a,
> + /* + enum hdmi_infoframe_type */
> +};
> +
> enum hdmi_infoframe_type {
> HDMI_INFOFRAME_TYPE_VENDOR = 0x81,
> HDMI_INFOFRAME_TYPE_AVI = 0x82,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3] drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not support KMS
On Tue, Sep 18, 2018 at 09:02:04PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 10:48:09AM -0700, José Roberto de Souza wrote:
> > All DRM_CLIENT capabilities are tied to KMS support, so returning
> > -EOPNOTSUPP when KMS is not supported.
> >
> > v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
> > in uapi) instead of -ENOTSUPP
> >
> > v3: adding comments about the feature requirement about capabilities
> >
> > Cc: Chris Wilson
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/drm_ioctl.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > index 60dfbfae6a02..94bd872d56c4 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -306,6 +306,12 @@ drm_setclientcap(struct drm_device *dev, void *data,
> > struct drm_file *file_priv)
> > {
> > struct drm_set_client_cap *req = data;
> >
> > + /* No render-only settable capabilities for now */
> > +
> > + /* Below caps that only works with KMS drivers */
>
> That doesn't seem quite English.
Looks close enough to me, so applied. Ime if you want to polish English,
it's best to just suggest a different wording, but then we don't have a
whole lot of professional English editors around here :-)
Thanks for the patch.
-Daniel
>
> > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > + return -EOPNOTSUPP;
> > +
> > switch (req->capability) {
> > case DRM_CLIENT_CAP_STEREO_3D:
> > if (req->value > 1)
> > --
> > 2.19.0
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/12] drm/mediatek: convert dpi driver to use drm_of_find_panel_or_bridge
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> Convert dpi driver to use drm_of_find_panel_or_bridge.
> This changes some error messages to debug messages (in the graph core).
> Graph connections are often "no connects" depending on the particular
> board, so we want to avoid spurious messages. Plus the kernel is not a
> DT validator.
> related links:
> [1] https://lkml.org/lkml/2017/2/3/716
> [2] https://lkml.org/lkml/2017/2/3/719
>
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 18 --
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 022ccec49cea..7a4868a0afec 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -697,7 +698,6 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> struct device *dev = >dev;
> struct mtk_dpi *dpi;
> struct resource *mem;
> - struct device_node *bridge_node;
> int comp_id;
> int ret;
>
> @@ -743,16 +743,14 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - bridge_node = of_graph_get_remote_node(dev->of_node, 0, 0);
> - if (!bridge_node)
> - return -ENODEV;
> -
> - dev_info(dev, "Found bridge node: %pOF\n", bridge_node);
> -
> - dpi->bridge = of_drm_find_bridge(bridge_node);
> - of_node_put(bridge_node);
> - if (!dpi->bridge)
> + ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
> + NULL, >bridge);
> + if (ret) {
> + dev_err(dev, "Failed to find panel or bridge: %d\n", ret);
> return -EPROBE_DEFER;
I've traced into drm_of_find_panel_or_bridge(), it may return -ENODEV
when device tree has error, why do you treat this error to
-EPROBE_DEFER? I think you may modify this as
if (ret)
return ret;
Regards,
CK
> + }
> +
> + dev_info(dev, "Found bridge node: %pOF\n", dpi->bridge->of_node);
>
> comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
> if (comp_id < 0) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 04/12] drm/mediatek: add clock factor for different IC
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> different IC has different clock designed in HDMI, the factor for
> calculate clock should be different. Usinng the data in of_node
> to find this factor.
>
Reviewed-by: CK Hu
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 24 +++-
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 1e7369e0d91c..022ccec49cea 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -120,6 +120,7 @@ struct mtk_dpi_yc_limit {
> };
>
> struct mtk_dpi_conf {
> + unsigned int (*cal_factor)(int clock);
> u32 reg_h_fre_con;
> bool edge_sel_en;
> };
> @@ -460,15 +461,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
> unsigned int factor;
>
> /* let pll_rate can fix the valid range of tvdpll (1G~2GHz) */
> -
> - if (mode->clock <= 27000)
> - factor = 3 << 4;
> - else if (mode->clock <= 84000)
> - factor = 3 << 3;
> - else if (mode->clock <= 167000)
> - factor = 3 << 2;
> - else
> - factor = 3 << 1;
> + factor = dpi->conf->cal_factor(mode->clock);
> drm_display_mode_to_videomode(mode, );
> pll_rate = vm.pixelclock * factor;
>
> @@ -682,7 +675,20 @@ static const struct component_ops mtk_dpi_component_ops
> = {
> .unbind = mtk_dpi_unbind,
> };
>
> +static unsigned int mt8173_calculate_factor(int clock)
> +{
> + if (clock <= 27000)
> + return 3 << 4;
> + else if (clock <= 84000)
> + return 3 << 3;
> + else if (clock <= 167000)
> + return 3 << 2;
> + else
> + return 3 << 1;
> +}
> +
> static const struct mtk_dpi_conf mt8173_conf = {
> + .cal_factor = mt8173_calculate_factor,
> .reg_h_fre_con = 0xe0,
> };
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: set i915 driver probe to asynchronous
On Wed, Sep 19, 2018 at 03:37:12PM +0800, ning.a.zh...@intel.com wrote:
> From: Zhang Ning
>
> when i915 is built in module, and system has built-in display, eg. eDP,
> i915 will detect and active it during driver probe. it will take long
> time.
>
> set i915 driver probe to asynchrous can save kernel initial time.
>
> Signed-off-by: Zhang Ning
Last time around this was proposed there was a very long discussion around
how this breaks the sound driver. Was this resolved? Definitely needs to
add this context to the commit message, and all people involved back then
added to the Cc: list. Searching for PROBE_PREFER_ASYNCHRONOUS in the
archives should dig it all up.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 6a4d1388ad2d..0f57d71d0abb 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -738,6 +738,7 @@ static struct pci_driver i915_pci_driver = {
> .probe = i915_pci_probe,
> .remove = i915_pci_remove,
> .driver.pm = _pm_ops,
> + .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
> };
>
> static int __init i915_init(void)
> --
> 2.18.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/5] drm: move native byte order quirk to new drm_mode_legacy_fb_format2 function
On Wed, Sep 19, 2018 at 01:12:48PM +0200, Gerd Hoffmann wrote:
> Turns out we need the pixel format fixup not only for the addfb ioctl,
> but also for fbdev emulation code.
>
> Ideally we would place it in drm_mode_legacy_fb_format(). That would
> create alot of churn though, and most drivers don't care because they
> never ever run on a big endian platform. So add a new
> drm_mode_legacy_fb_format2() function instead.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_fourcc.h | 2 ++
> drivers/gpu/drm/drm_fourcc.c | 28
> drivers/gpu/drm/drm_framebuffer.c | 15 +++
> 3 files changed, 33 insertions(+), 12 deletions(-)
>
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index fac831c401..4b82bb6576 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -88,6 +88,8 @@ const struct drm_format_info *
> drm_get_format_info(struct drm_device *dev,
> const struct drm_mode_fb_cmd2 *mode_cmd);
> uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
> +uint32_t drm_mode_legacy_fb_format2(uint32_t bpp, uint32_t depth,
> + bool native);
> int drm_format_num_planes(uint32_t format);
> int drm_format_plane_cpp(uint32_t format, int plane);
> int drm_format_horz_chroma_subsampling(uint32_t format);
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index be1d6aaef6..1c1aaa8b23 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -96,6 +96,34 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t
> depth)
> EXPORT_SYMBOL(drm_mode_legacy_fb_format);
>
> /**
> + * drm_mode_legacy_fb_format2 - compute drm fourcc code from legacy
> description
> + * @bpp: bits per pixels
> + * @depth: bit depth per pixel
> + * @native: use host native byte order
> + *
> + * Computes a drm fourcc pixel format code for the given @bpp/@depth values.
> + * Useful in fbdev emulation code, since that deals in those values.
> + */
> +uint32_t drm_mode_legacy_fb_format2(uint32_t bpp, uint32_t depth,
> + bool native)
A _2 function is a bit meh imo. What about legacy_fb_format_native()
instead, which unconditionally gives you the native format, and then
pulling the if (native) out?
Or slightly more future proof (given that we have the nouveau hack too):
drm_device_legacy_fb_format(drm_device *dev, bpp, depth);
to make it clear that this is the device-specific conversion function.
-Daniel
> +{
> + uint32_t fmt = drm_mode_legacy_fb_format(bpp, depth);
> +
> + if (native) {
> + if (fmt == DRM_FORMAT_XRGB)
> + fmt = DRM_FORMAT_HOST_XRGB;
> + if (fmt == DRM_FORMAT_ARGB)
> + fmt = DRM_FORMAT_HOST_ARGB;
> + if (fmt == DRM_FORMAT_RGB565)
> + fmt = DRM_FORMAT_HOST_RGB565;
> + if (fmt == DRM_FORMAT_XRGB1555)
> + fmt = DRM_FORMAT_HOST_XRGB1555;
> + }
> + return fmt;
> +}
> +EXPORT_SYMBOL(drm_mode_legacy_fb_format2);
> +
> +/**
> * drm_get_format_name - fill a string with a drm fourcc format's name
> * @format: format to compute name of
> * @buf: caller-supplied buffer
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index 1ee3d6b442..f72e3dffc7 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -111,12 +111,14 @@ int drm_mode_addfb(struct drm_device *dev, struct
> drm_mode_fb_cmd *or,
> struct drm_file *file_priv)
> {
> struct drm_mode_fb_cmd2 r = {};
> + bool native = dev->mode_config.quirk_addfb_prefer_host_byte_order;
> int ret;
>
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> return -EOPNOTSUPP;
>
> - r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
> + r.pixel_format = drm_mode_legacy_fb_format2(or->bpp, or->depth,
> + native);
> if (r.pixel_format == DRM_FORMAT_INVALID) {
> DRM_DEBUG("bad {bpp:%d, depth:%d}\n", or->bpp, or->depth);
> return -EINVAL;
> @@ -133,17 +135,6 @@ int drm_mode_addfb(struct drm_device *dev, struct
> drm_mode_fb_cmd *or,
> r.pixel_format == DRM_FORMAT_XRGB2101010)
> r.pixel_format = DRM_FORMAT_XBGR2101010;
>
> - if (dev->mode_config.quirk_addfb_prefer_host_byte_order) {
> - if (r.pixel_format == DRM_FORMAT_XRGB)
> - r.pixel_format = DRM_FORMAT_HOST_XRGB;
> - if (r.pixel_format == DRM_FORMAT_ARGB)
> - r.pixel_format = DRM_FORMAT_HOST_ARGB;
> - if (r.pixel_format == DRM_FORMAT_RGB565)
> - r.pixel_format = DRM_FORMAT_HOST_RGB565;
> - if (r.pixel_format == DRM_FORMAT_XRGB1555)
> -
Re: [PATCH v3 06/12] drm/mediatek: add dpi driver for mt2701 and mt7623
Hi, Bibby:
On Fri, 2018-09-21 at 11:28 +0800, Bibby Hsieh wrote:
> From: chunhui dai
>
> This patch adds dpi dirver suppot for both mt2701 and mt7623.
> And also support other (existing or future) chips that use
> the same binding and driver.
>
Reviewed-by: CK Hu
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 21 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
> 2 files changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 7a4868a0afec..a9d8231a0a9e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -688,11 +688,29 @@ static unsigned int mt8173_calculate_factor(int clock)
> return 3 << 1;
> }
>
> +static unsigned int mt2701_calculate_factor(int clock)
> +{
> + if (clock <= 64000)
> + return 16;
> + else if (clock <= 128000)
> + return 8;
> + else if (clock <= 256000)
> + return 4;
> + else
> + return 2;
> +}
> +
> static const struct mtk_dpi_conf mt8173_conf = {
> .cal_factor = mt8173_calculate_factor,
> .reg_h_fre_con = 0xe0,
> };
>
> +static const struct mtk_dpi_conf mt2701_conf = {
> + .cal_factor = mt2701_calculate_factor,
> + .reg_h_fre_con = 0xb0,
> + .edge_sel_en = true,
> +};
> +
> static int mtk_dpi_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -784,6 +802,9 @@ static int mtk_dpi_remove(struct platform_device *pdev)
> }
>
> static const struct of_device_id mtk_dpi_of_ids[] = {
> + { .compatible = "mediatek,mt2701-dpi",
> + .data = _conf,
> + },
> { .compatible = "mediatek,mt8173-dpi",
> .data = _conf,
> },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 39721119713b..d961112fa2f5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -424,6 +424,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> .data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt8173-dsi",
> .data = (void *)MTK_DSI },
> + { .compatible = "mediatek,mt2701-dpi",
> + .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt8173-dpi",
> .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt2701-disp-mutex",
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=104602 --- Comment #10 from Jason Playne --- (In reply to Timothy Arceri from comment #9) > I'm not sure why yet but both the black triangles and the incorrect > rendering behind the chinese emperor on the loading screen go away when I > run the trace on the NIR backend. > > Until we figure out what is going on here you can try running the game with > the following environment variable: > > R600_DEBUG=nir Can confirm! The initial red+black triangles in the game seem to have disappeared using the nir backend. (I may be a little excited!) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/18] video/hdmi: Handle the MPEG Source infoframe
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add the code to deal with the MPEG source infoframe.
>
> Blindly typed from the spec, and totally untested.
I'm not sure this patch should be added at all. The CTA-861-G spec (section 6.7)
says that the implementation of this infoframe is not recommended due to
unresolved
issues.
I don't think I've ever seen it either.
It obviously doesn't hurt to have this code, but I prefer to wait until there
are devices that actively set/use this infoframe.
Regards,
Hans
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 229
> +++
> include/linux/hdmi.h | 27 ++
> 2 files changed, 256 insertions(+)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 9507f668a569..3d24c7746c51 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -706,6 +706,131 @@ hdmi_vendor_any_infoframe_pack(union
> hdmi_vendor_any_infoframe *frame,
> return hdmi_vendor_any_infoframe_pack_only(frame, buffer, size);
> }
>
> +/**
> + * hdmi_mpeg_source_infoframe_init() - initialize an HDMI MPEG Source
> infoframe
> + * @frame: HDMI MPEG Source infoframe
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_mpeg_source_infoframe_init(struct hdmi_mpeg_source_infoframe *frame)
> +{
> + memset(frame, 0, sizeof(*frame));
> +
> + frame->type = HDMI_INFOFRAME_TYPE_MPEG_SOURCE;
> + frame->version = 1;
> + frame->length = HDMI_MPEG_SOURCE_INFOFRAME_SIZE;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_init);
> +
> +static int hdmi_mpeg_source_infoframe_check_only(const struct
> hdmi_mpeg_source_infoframe *frame)
> +{
> + if (frame->type != HDMI_INFOFRAME_TYPE_MPEG_SOURCE ||
> + frame->version != 1 ||
> + frame->length != HDMI_MPEG_SOURCE_INFOFRAME_SIZE)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +/**
> + * hdmi_mpeg_source_infoframe_check() - Check and check a HDMI MPEG Source
> infoframe
> + * @frame: HDMI MPEG Source infoframe
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_mpeg_source_infoframe_check(struct hdmi_mpeg_source_infoframe
> *frame)
> +{
> + return hdmi_mpeg_source_infoframe_check_only(frame);
> +}
> +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_check);
> +
> +/**
> + * hdmi_mpeg_source_infoframe_pack_only() - write HDMI MPEG Source infoframe
> to binary buffer
> + * @frame: HDMI MPEG Source infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Packs the information contained in the @frame structure into a binary
> + * representation that can be written into the corresponding controller
> + * registers. Also computes the checksum as required by section 5.3.5 of
> + * the HDMI 1.4 specification.
> + *
> + * Returns the number of bytes packed into the binary buffer or a negative
> + * error code on failure.
> + */
> +ssize_t hdmi_mpeg_source_infoframe_pack_only(const struct
> hdmi_mpeg_source_infoframe *frame,
> + void *buffer, size_t size)
> +{
> + u8 *ptr = buffer;
> + size_t length;
> + int ret;
> +
> + ret = hdmi_mpeg_source_infoframe_check_only(frame);
> + if (ret)
> + return ret;
> +
> + length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> +
> + if (size < length)
> + return -ENOSPC;
> +
> + memset(buffer, 0, size);
> +
> + ptr[0] = frame->type;
> + ptr[1] = frame->version;
> + ptr[2] = frame->length;
> + ptr[3] = 0; /* checksum */
> +
> + /* start infoframe payload */
> + ptr += HDMI_INFOFRAME_HEADER_SIZE;
> +
> + ptr[0] = frame->mpeg_bit_rate >> 0;
> + ptr[1] = frame->mpeg_bit_rate >> 8;
> + ptr[2] = frame->mpeg_bit_rate >> 16;
> + ptr[3] = frame->mpeg_bit_rate >> 24;
> + ptr[4] = (frame->field_repeat << 4) | frame->mpeg_frame;
> +
> + hdmi_infoframe_set_checksum(buffer, length);
> +
> + return length;
> +}
> +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack_only);
> +
> +/**
> + * hdmi_mpeg_source_infoframe_pack() - Check and check a HDMI MPEG Source
> infoframe,
> + * and write it to binary buffer
> + * @frame: HDMI MPEG Source infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields, after which packs the information
> + * contained in the @frame structure into a binary representation that
> + * can be written into the corresponding controller registers. Also
> + * computes the checksum as required by section 5.3.5 of the HDMI 1.4
> + *
Re: [PATCH -next] drm/vkms: Fix possible memory leak in _vkms_get_crc()
On Sat, Sep 15, 2018 at 01:53:19AM +, Wei Yongjun wrote:
> 'vaddr_out' is malloced in _vkms_get_crc() and should be freed before
> leaving from the error handling cases, otherwise it will cause memory
> leak.
>
> Fixes: db7f419c06d7 ("drm/vkms: Compute CRC with Cursor Plane")
> Signed-off-by: Wei Yongjun
Applied, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/vkms/vkms_crc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index 0a27456..9d9e814 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -125,6 +125,7 @@ static uint32_t _vkms_get_crc(struct vkms_crc_data
> *primary_crc,
> mutex_lock(_obj->pages_lock);
> if (WARN_ON(!vkms_obj->vaddr)) {
> mutex_unlock(_obj->pages_lock);
> + kfree(vaddr_out);
> return crc;
> }
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Use default dma_fence hooks where possible for null syncobj
On Tue, Sep 18, 2018 at 11:07:19AM +0100, Chris Wilson wrote:
> Both the .enable_signaling and .release of the null syncobj fence
> can be replaced by the default callbacks for a small reduction in code
> size.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_syncobj.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 497729202bfe..e254f97fed7d 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -66,20 +66,9 @@ static const char *drm_syncobj_stub_fence_get_name(struct
> dma_fence *fence)
> return "syncobjstub";
> }
>
> -static bool drm_syncobj_stub_fence_enable_signaling(struct dma_fence *fence)
> -{
> -return !dma_fence_is_signaled(fence);
> -}
> -
> -static void drm_syncobj_stub_fence_release(struct dma_fence *f)
> -{
> - kfree(f);
> -}
> static const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
> .get_driver_name = drm_syncobj_stub_fence_get_name,
> .get_timeline_name = drm_syncobj_stub_fence_get_name,
> - .enable_signaling = drm_syncobj_stub_fence_enable_signaling,
> - .release = drm_syncobj_stub_fence_release,
> };
>
>
> --
> 2.19.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/fourcc: rename Intel modifiers to follow the naming convention
On Tue, Sep 18, 2018 at 06:21:59PM +0100, Eric Engestrom wrote:
> All the other vendors use the format
> DRM_FORMAT_MOD_{SAMSUNG,QCOM,VIVANTE,NVIDIA,BROADCOM,ARM}_* for their
> modifiers, except Intel.
>
> Suggested-by: Gerd Hoffmann
> Signed-off-by: Eric Engestrom
I think it'd be good to add why you want this (easier to parse in tooling,
or something like that was what you said on irc). With that addressed,
Reviewed-by: Daniel Vetter on both patches.
Probably best if you get i915 maintainers to merge both through drm-intel.
-Daniel
> ---
> include/uapi/drm/drm_fourcc.h | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 139632b871816f9e3dad..170a562223387687592a 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -271,7 +271,8 @@ extern "C" {
> * sharing. It exists since on a given platform it does uniquely identify the
> * layout in a simple way for i915-specific userspace.
> */
> -#define I915_FORMAT_MOD_X_TILED fourcc_mod_code(INTEL, 1)
> +#define DRM_FORMAT_MOD_INTEL_X_TILED fourcc_mod_code(INTEL, 1)
> +#define I915_FORMAT_MOD_X_TILED DRM_FORMAT_MOD_INTEL_X_TILED
>
> /*
> * Intel Y-tiling layout
> @@ -286,7 +287,8 @@ extern "C" {
> * sharing. It exists since on a given platform it does uniquely identify the
> * layout in a simple way for i915-specific userspace.
> */
> -#define I915_FORMAT_MOD_Y_TILED fourcc_mod_code(INTEL, 2)
> +#define DRM_FORMAT_MOD_INTEL_Y_TILED fourcc_mod_code(INTEL, 2)
> +#define I915_FORMAT_MOD_Y_TILED DRM_FORMAT_MOD_INTEL_Y_TILED
>
> /*
> * Intel Yf-tiling layout
> @@ -301,7 +303,8 @@ extern "C" {
> * 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the
> width
> * in pixel depends on the pixel depth.
> */
> -#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
> +#define DRM_FORMAT_MOD_INTEL_Yf_TILED fourcc_mod_code(INTEL, 3)
> +#define I915_FORMAT_MOD_Yf_TILED DRM_FORMAT_MOD_INTEL_Yf_TILED
>
> /*
> * Intel color control surface (CCS) for render compression
> @@ -320,8 +323,10 @@ extern "C" {
> * But that fact is not relevant unless the memory is accessed
> * directly.
> */
> -#define I915_FORMAT_MOD_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
> -#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
> +#define DRM_FORMAT_MOD_INTEL_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
> +#define I915_FORMAT_MOD_Y_TILED_CCS DRM_FORMAT_MOD_INTEL_Y_TILED_CCS
> +#define DRM_FORMAT_MOD_INTEL_Yf_TILED_CCSfourcc_mod_code(INTEL, 5)
> +#define I915_FORMAT_MOD_Yf_TILED_CCS DRM_FORMAT_MOD_INTEL_Yf_TILED_CCS
>
> /*
> * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
> --
> Cheers,
> Eric
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/tegra: dc: Do not register DC without primary plane
From: Thierry Reding
Tegra194 contains a fourth display controller that does not own any
windows. Therefore, we cannot currently assign a primary plane to it
which causes KMS to eventually crash. Do not register the display
controller if it owns no windows to work around this.
Note that we still have to enable and probe the display controller
because for some reason all display controllers need to be powered
(and/or clocked) before any registers can be accessed in any of the
display controllers.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 965088afcfad..7e36ca204cbb 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1988,6 +1988,28 @@ static int tegra_dc_init(struct host1x_client *client)
struct drm_plane *cursor = NULL;
int err;
+ /*
+* XXX do not register DCs with no window groups because we cannot
+* assign a primary plane to them, which in turn will cause KMS to
+* crash.
+*/
+ if (dc->soc->wgrps) {
+ bool has_wgrps = false;
+ unsigned int i;
+
+ for (i = 0; i < dc->soc->num_wgrps; i++) {
+ const struct tegra_windowgroup_soc *wgrp =
>soc->wgrps[i];
+
+ if (wgrp->dc == dc->pipe && wgrp->num_windows > 0) {
+ has_wgrps = true;
+ break;
+ }
+ }
+
+ if (!has_wgrps)
+ return 0;
+ }
+
dc->syncpt = host1x_syncpt_request(client, flags);
if (!dc->syncpt)
dev_warn(dc->dev, "failed to allocate syncpoint\n");
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/tegra: dpaux: Add Tegra194 support
From: Thierry Reding
The DPAUX controller found on Tegra194 is almost identical to its
predecessor from Tegra186.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dpaux.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index d84e81ff36ad..b96817b0130d 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -639,6 +639,7 @@ static const struct dev_pm_ops tegra_dpaux_pm_ops = {
};
static const struct of_device_id tegra_dpaux_of_match[] = {
+ { .compatible = "nvidia,tegra194-dpaux", },
{ .compatible = "nvidia,tegra186-dpaux", },
{ .compatible = "nvidia,tegra210-dpaux", },
{ .compatible = "nvidia,tegra124-dpaux", },
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/tegra: dc: Add Tegra194 support
From: Thierry Reding
The display controllers found on Tegra194 are almost identical to those
found on Tegra186.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.c | 51 +
drivers/gpu/drm/tegra/dc.h | 2 +-
drivers/gpu/drm/tegra/drm.c | 1 +
3 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 7e36ca204cbb..f80e82e16475 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2256,8 +2256,59 @@ static const struct tegra_dc_soc_info
tegra186_dc_soc_info = {
.num_wgrps = ARRAY_SIZE(tegra186_dc_wgrps),
};
+static const struct tegra_windowgroup_soc tegra194_dc_wgrps[] = {
+ {
+ .index = 0,
+ .dc = 0,
+ .windows = (const unsigned int[]) { 0 },
+ .num_windows = 1,
+ }, {
+ .index = 1,
+ .dc = 1,
+ .windows = (const unsigned int[]) { 1 },
+ .num_windows = 1,
+ }, {
+ .index = 2,
+ .dc = 1,
+ .windows = (const unsigned int[]) { 2 },
+ .num_windows = 1,
+ }, {
+ .index = 3,
+ .dc = 2,
+ .windows = (const unsigned int[]) { 3 },
+ .num_windows = 1,
+ }, {
+ .index = 4,
+ .dc = 2,
+ .windows = (const unsigned int[]) { 4 },
+ .num_windows = 1,
+ }, {
+ .index = 5,
+ .dc = 2,
+ .windows = (const unsigned int[]) { 5 },
+ .num_windows = 1,
+ },
+};
+
+static const struct tegra_dc_soc_info tegra194_dc_soc_info = {
+ .supports_background_color = true,
+ .supports_interlacing = true,
+ .supports_cursor = true,
+ .supports_block_linear = true,
+ .has_legacy_blending = false,
+ .pitch_align = 64,
+ .has_powergate = false,
+ .coupled_pm = false,
+ .has_nvdisplay = true,
+ .wgrps = tegra194_dc_wgrps,
+ .num_wgrps = ARRAY_SIZE(tegra194_dc_wgrps),
+};
+
static const struct of_device_id tegra_dc_of_match[] = {
{
+ .compatible = "nvidia,tegra194-dc",
+ .data = _dc_soc_info,
+ }, {
.compatible = "nvidia,tegra186-dc",
.data = _dc_soc_info,
}, {
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index e96f582ca692..1256dfb6b2f5 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -300,7 +300,7 @@ int tegra_dc_rgb_exit(struct tegra_dc *dc);
#define SOR1_TIMING_CYA(1 << 27)
#define CURSOR_ENABLE (1 << 16)
-#define SOR_ENABLE(x) (1 << (25 + (x)))
+#define SOR_ENABLE(x) (1 << (25 + (((x) > 1) ? ((x) + 1) : (x
#define DC_DISP_DISP_MEM_HIGH_PRIORITY 0x403
#define CURSOR_THRESHOLD(x) (((x) & 0x03) << 24)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index b31dcf5c9524..395b048447b2 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1276,6 +1276,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra186-sor1", },
{ .compatible = "nvidia,tegra186-vic", },
{ .compatible = "nvidia,tegra194-display", },
+ { .compatible = "nvidia,tegra194-dc", },
{ /* sentinel */ }
};
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/tegra: sor: Add Tegra194 support
From: Thierry Reding
The SOR implemented in Tegra194 is subtly different from its predecessor
found in Tegra186. Most notably some registers have been moved around so
it is no longer compatible.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 1 +
drivers/gpu/drm/tegra/sor.c | 110
2 files changed, 111 insertions(+)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 395b048447b2..67a7cffe89fc 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1277,6 +1277,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra186-vic", },
{ .compatible = "nvidia,tegra194-display", },
{ .compatible = "nvidia,tegra194-dc", },
+ { .compatible = "nvidia,tegra194-sor", },
{ /* sentinel */ }
};
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index d7fe9f15def1..b129da2e5afd 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -282,6 +282,85 @@ static const struct tegra_sor_hdmi_settings
tegra186_sor_hdmi_defaults[] = {
}
};
+static const struct tegra_sor_hdmi_settings tegra194_sor_hdmi_defaults[] = {
+ {
+ .frequency = 5400,
+ .vcocap = 0,
+ .filter = 5,
+ .ichpmp = 5,
+ .loadadj = 3,
+ .tmds_termadj = 0xf,
+ .tx_pu_value = 0,
+ .bg_temp_coef = 3,
+ .bg_vref_level = 8,
+ .avdd10_level = 4,
+ .avdd14_level = 4,
+ .sparepll = 0x54,
+ .drive_current = { 0x3a, 0x3a, 0x3a, 0x33 },
+ .preemphasis = { 0x00, 0x00, 0x00, 0x00 },
+ }, {
+ .frequency = 7500,
+ .vcocap = 1,
+ .filter = 5,
+ .ichpmp = 5,
+ .loadadj = 3,
+ .tmds_termadj = 0xf,
+ .tx_pu_value = 0,
+ .bg_temp_coef = 3,
+ .bg_vref_level = 8,
+ .avdd10_level = 4,
+ .avdd14_level = 4,
+ .sparepll = 0x44,
+ .drive_current = { 0x3a, 0x3a, 0x3a, 0x33 },
+ .preemphasis = { 0x00, 0x00, 0x00, 0x00 },
+ }, {
+ .frequency = 15000,
+ .vcocap = 3,
+ .filter = 5,
+ .ichpmp = 5,
+ .loadadj = 3,
+ .tmds_termadj = 15,
+ .tx_pu_value = 0x66 /* 0 */,
+ .bg_temp_coef = 3,
+ .bg_vref_level = 8,
+ .avdd10_level = 4,
+ .avdd14_level = 4,
+ .sparepll = 0x00, /* 0x34 */
+ .drive_current = { 0x3a, 0x3a, 0x3a, 0x37 },
+ .preemphasis = { 0x00, 0x00, 0x00, 0x00 },
+ }, {
+ .frequency = 3,
+ .vcocap = 3,
+ .filter = 5,
+ .ichpmp = 5,
+ .loadadj = 3,
+ .tmds_termadj = 15,
+ .tx_pu_value = 64,
+ .bg_temp_coef = 3,
+ .bg_vref_level = 8,
+ .avdd10_level = 4,
+ .avdd14_level = 4,
+ .sparepll = 0x34,
+ .drive_current = { 0x3d, 0x3d, 0x3d, 0x33 },
+ .preemphasis = { 0x00, 0x00, 0x00, 0x00 },
+ }, {
+ .frequency = 6,
+ .vcocap = 3,
+ .filter = 5,
+ .ichpmp = 5,
+ .loadadj = 3,
+ .tmds_termadj = 12,
+ .tx_pu_value = 96,
+ .bg_temp_coef = 3,
+ .bg_vref_level = 8,
+ .avdd10_level = 4,
+ .avdd14_level = 4,
+ .sparepll = 0x34,
+ .drive_current = { 0x3d, 0x3d, 0x3d, 0x33 },
+ .preemphasis = { 0x00, 0x00, 0x00, 0x00 },
+ }
+};
+
struct tegra_sor_regs {
unsigned int head_state0;
unsigned int head_state1;
@@ -2894,7 +2973,38 @@ static const struct tegra_sor_soc tegra186_sor1 = {
.xbar_cfg = tegra124_sor_xbar_cfg,
};
+static const struct tegra_sor_regs tegra194_sor_regs = {
+ .head_state0 = 0x151,
+ .head_state1 = 0x155,
+ .head_state2 = 0x159,
+ .head_state3 = 0x15d,
+ .head_state4 = 0x161,
+ .head_state5 = 0x165,
+ .pll0 = 0x169,
+ .pll1 = 0x16a,
+ .pll2 = 0x16b,
+ .pll3 = 0x16c,
+ .dp_padctl0 = 0x16e,
+ .dp_padctl2 = 0x16f,
+};
+
+static const struct tegra_sor_soc tegra194_sor = {
+ .supports_edp = true,
+ .supports_lvds = false,
+ .supports_hdmi = true,
+ .supports_dp = true,
+
+ .regs = _sor_regs,
+ .has_nvdisplay = true,
+
+ .num_settings = ARRAY_SIZE(tegra194_sor_hdmi_defaults),
+ .settings = tegra194_sor_hdmi_defaults,
+
+ .xbar_cfg = tegra210_sor_xbar_cfg,
+};
+
static const struct
[PATCH 2/5] drm/tegra: hub: Add Tegra194 support
From: Thierry Reding
The display hub integrated into Tegra194 is almost identical to the one
found on Tegra186. However, it doesn't support DSC (display stream
compression) so it isn't fully compatible.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 1 +
drivers/gpu/drm/tegra/hub.c | 19 +++
drivers/gpu/drm/tegra/hub.h | 1 +
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index b424bc911b95..b31dcf5c9524 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1275,6 +1275,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra186-sor", },
{ .compatible = "nvidia,tegra186-sor1", },
{ .compatible = "nvidia,tegra186-vic", },
+ { .compatible = "nvidia,tegra194-display", },
{ /* sentinel */ }
};
diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 8f4fcbb515fb..6112d9042979 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -758,10 +758,12 @@ static int tegra_display_hub_probe(struct platform_device
*pdev)
return err;
}
- hub->clk_dsc = devm_clk_get(>dev, "dsc");
- if (IS_ERR(hub->clk_dsc)) {
- err = PTR_ERR(hub->clk_dsc);
- return err;
+ if (hub->soc->supports_dsc) {
+ hub->clk_dsc = devm_clk_get(>dev, "dsc");
+ if (IS_ERR(hub->clk_dsc)) {
+ err = PTR_ERR(hub->clk_dsc);
+ return err;
+ }
}
hub->clk_hub = devm_clk_get(>dev, "hub");
@@ -890,10 +892,19 @@ static const struct dev_pm_ops tegra_display_hub_pm_ops =
{
static const struct tegra_display_hub_soc tegra186_display_hub = {
.num_wgrps = 6,
+ .supports_dsc = true,
+};
+
+static const struct tegra_display_hub_soc tegra194_display_hub = {
+ .num_wgrps = 6,
+ .supports_dsc = false,
};
static const struct of_device_id tegra_display_hub_of_match[] = {
{
+ .compatible = "nvidia,tegra194-display",
+ .data = _display_hub
+ }, {
.compatible = "nvidia,tegra186-display",
.data = _display_hub
}, {
diff --git a/drivers/gpu/drm/tegra/hub.h b/drivers/gpu/drm/tegra/hub.h
index 85b8bf41a395..6696a85fc1f2 100644
--- a/drivers/gpu/drm/tegra/hub.h
+++ b/drivers/gpu/drm/tegra/hub.h
@@ -38,6 +38,7 @@ to_tegra_shared_plane(struct drm_plane *plane)
struct tegra_display_hub_soc {
unsigned int num_wgrps;
+ bool supports_dsc;
};
struct tegra_display_hub {
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/18] video/hdmi: Constify 'buffer' to the unpack functions
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The unpack functions just read from the passed in buffer,
> so make it const.
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
Acked-by: Hans Verkuil
Thanks!
Hans
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 23 ---
> include/linux/hdmi.h | 3 ++-
> 2 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 38716eb50408..65b915ea4936 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -31,7 +31,7 @@
>
> #define hdmi_log(fmt, ...) dev_printk(level, dev, fmt, ##__VA_ARGS__)
>
> -static u8 hdmi_infoframe_checksum(u8 *ptr, size_t size)
> +static u8 hdmi_infoframe_checksum(const u8 *ptr, size_t size)
> {
> u8 csum = 0;
> size_t i;
> @@ -1016,9 +1016,9 @@ EXPORT_SYMBOL(hdmi_infoframe_log);
> * Returns 0 on success or a negative error code on failure.
> */
> static int hdmi_avi_infoframe_unpack(struct hdmi_avi_infoframe *frame,
> - void *buffer)
> + const void *buffer)
> {
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
> int ret;
>
> if (ptr[0] != HDMI_INFOFRAME_TYPE_AVI ||
> @@ -1079,9 +1079,9 @@ static int hdmi_avi_infoframe_unpack(struct
> hdmi_avi_infoframe *frame,
> * Returns 0 on success or a negative error code on failure.
> */
> static int hdmi_spd_infoframe_unpack(struct hdmi_spd_infoframe *frame,
> - void *buffer)
> + const void *buffer)
> {
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
> int ret;
>
> if (ptr[0] != HDMI_INFOFRAME_TYPE_SPD ||
> @@ -1117,9 +1117,9 @@ static int hdmi_spd_infoframe_unpack(struct
> hdmi_spd_infoframe *frame,
> * Returns 0 on success or a negative error code on failure.
> */
> static int hdmi_audio_infoframe_unpack(struct hdmi_audio_infoframe *frame,
> -void *buffer)
> +const void *buffer)
> {
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
> int ret;
>
> if (ptr[0] != HDMI_INFOFRAME_TYPE_AUDIO ||
> @@ -1163,9 +1163,9 @@ static int hdmi_audio_infoframe_unpack(struct
> hdmi_audio_infoframe *frame,
> */
> static int
> hdmi_vendor_any_infoframe_unpack(union hdmi_vendor_any_infoframe *frame,
> - void *buffer)
> + const void *buffer)
> {
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
> size_t length;
> int ret;
> u8 hdmi_video_format;
> @@ -1234,10 +1234,11 @@ hdmi_vendor_any_infoframe_unpack(union
> hdmi_vendor_any_infoframe *frame,
> *
> * Returns 0 on success or a negative error code on failure.
> */
> -int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer)
> +int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
> + const void *buffer)
> {
> int ret;
> - u8 *ptr = buffer;
> + const u8 *ptr = buffer;
>
> switch (ptr[0]) {
> case HDMI_INFOFRAME_TYPE_AVI:
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index d271ff23984f..d3816170c062 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -332,7 +332,8 @@ union hdmi_infoframe {
>
> ssize_t
> hdmi_infoframe_pack(union hdmi_infoframe *frame, void *buffer, size_t size);
> -int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer);
> +int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
> + const void *buffer);
> void hdmi_infoframe_log(const char *level, struct device *dev,
> union hdmi_infoframe *frame);
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/18] video/hdmi: Handle the NTSC VBI infoframe
On 09/20/18 20:51, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add the code to deal with the NTSC VBI infoframe.
>
> I decided against parsing the PES_data_field and just leave
> it as an opaque blob, just dumping it out as hex in the log.
>
> Blindly typed from the spec, and totally untested.
Do we have any driver that uses this? I would prefer to wait until someone
actually need this.
Regards,
Hans
>
> Cc: Thierry Reding
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
> ---
> drivers/video/hdmi.c | 208
> +++
> include/linux/hdmi.h | 18 +
> 2 files changed, 226 insertions(+)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 3d24c7746c51..3c320d69fa0a 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -831,6 +831,139 @@ ssize_t hdmi_mpeg_source_infoframe_pack(struct
> hdmi_mpeg_source_infoframe *frame
> }
> EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack);
>
> +/**
> + * hdmi_ntsc_vbi_infoframe_init() - initialize an HDMI NTSC VBI infoframe
> + * @frame: HDMI NTSC VBI infoframe
> + * @pes_data_field: ANSI/SCTE 127 PES_data_field
> + * @length: ANSI/SCTE 127 PES_data_field length
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_ntsc_vbi_infoframe_init(struct hdmi_ntsc_vbi_infoframe *frame,
> + const void *pes_data_field,
> + size_t length)
> +{
> + if (length < 1 || length > 27)
> + return -EINVAL;
> +
> + memset(frame, 0, sizeof(*frame));
> +
> + frame->type = HDMI_INFOFRAME_TYPE_NTSC_VBI;
> + frame->version = 1;
> + frame->length = length;
> +
> + memcpy(frame->pes_data_field, pes_data_field, length);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_init);
> +
> +static int hdmi_ntsc_vbi_infoframe_check_only(const struct
> hdmi_ntsc_vbi_infoframe *frame)
> +{
> + if (frame->type != HDMI_INFOFRAME_TYPE_NTSC_VBI ||
> + frame->version != 1 ||
> + frame->length < 1 || frame->length > 27)
> + return -EINVAL;
> +
> + if (frame->pes_data_field[0] != 0x99)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +/**
> + * hdmi_ntsc_vbi_infoframe_check() - Check and check a HDMI NTSC VBI
> infoframe
> + * @frame: HDMI NTSC VBI infoframe
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_ntsc_vbi_infoframe_check(struct hdmi_ntsc_vbi_infoframe *frame)
> +{
> + return hdmi_ntsc_vbi_infoframe_check_only(frame);
> +}
> +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_check);
> +
> +/**
> + * hdmi_ntsc_vbi_infoframe_pack_only() - write HDMI NTSC VBI infoframe to
> binary buffer
> + * @frame: HDMI NTSC VBI infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Packs the information contained in the @frame structure into a binary
> + * representation that can be written into the corresponding controller
> + * registers. Also computes the checksum as required by section 5.3.5 of
> + * the HDMI 1.4 specification.
> + *
> + * Returns the number of bytes packed into the binary buffer or a negative
> + * error code on failure.
> + */
> +ssize_t hdmi_ntsc_vbi_infoframe_pack_only(const struct
> hdmi_ntsc_vbi_infoframe *frame,
> + void *buffer, size_t size)
> +{
> + u8 *ptr = buffer;
> + size_t length;
> + int ret;
> +
> + ret = hdmi_ntsc_vbi_infoframe_check_only(frame);
> + if (ret)
> + return ret;
> +
> + length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> +
> + if (size < length)
> + return -ENOSPC;
> +
> + memset(buffer, 0, size);
> +
> + ptr[0] = frame->type;
> + ptr[1] = frame->version;
> + ptr[2] = frame->length;
> + ptr[3] = 0; /* checksum */
> +
> + /* start infoframe payload */
> + ptr += HDMI_INFOFRAME_HEADER_SIZE;
> +
> + memcpy(ptr, frame->pes_data_field, frame->length);
> +
> + hdmi_infoframe_set_checksum(buffer, length);
> +
> + return length;
> +}
> +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_pack_only);
> +
> +/**
> + * hdmi_ntsc_vbi_infoframe_pack() - Check and check a HDMI NTSC VBI
> infoframe,
> + * and write it to binary buffer
> + * @frame: HDMI NTSC VBI infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Validates that the infoframe is consistent and updates derived fields
> + * (eg. length) based on other fields, after which packs the information
> + * contained in the @frame structure into a binary representation that
> + * can be written into the corresponding controller registers. Also
> + * computes the checksum as required by section 5.3.5 of the HDMI 1.4
> + * specification.
Re: [PATCH v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
Hi Simon,
On Friday, 21 September 2018 10:16:44 EEST Simon Horman wrote:
> On Wed, Sep 19, 2018 at 04:11:36PM +0300, Laurent Pinchart wrote:
> > On Wednesday, 19 September 2018 11:35:07 EEST Simon Horman wrote:
> >> On Mon, Sep 17, 2018 at 11:59:32AM +0300, Laurent Pinchart wrote:
> >>> On Monday, 17 September 2018 11:54:04 EEST Laurent Pinchart wrote:
> On Monday, 17 September 2018 11:47:15 EEST Laurent Pinchart wrote:
> > On Monday, 17 September 2018 11:14:20 EEST Simon Horman wrote:
> >> On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote:
> >>> On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> The R8A77990 (E3) platform has one RGB output and two LVDS
> outputs connected to the DU. Add the DT nodes for the DU, LVDS
> encoders and supporting VSP and FCP.
>
> Signed-off-by: Laurent Pinchart
>
> Tested-by: Jacopo Mondi
> ---
>
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 +
> 1 file changed, 167 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index
> abb14af76c0e..600074ca3ee5 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> >
> > [snip]
> >
> +lvds0: lvds-encoder@feb9 {
> +compatible = "renesas,r8a77990-lvds";
> +reg = <0 0xfeb9 0 0x20>;
> +clocks = < CPG_MOD 727>;
> +power-domains = < R8A77990_PD_ALWAYS_ON>;
> +resets = < 727>;
> +status = "disabled";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +lvds0_in: endpoint {
> +remote-endpoint =
> <_out_lvds0>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +lvds0_out: endpoint {
> +};
> +};
> +};
> +};
> +
> +lvds1: lvds-encoder@feb90100 {
> +compatible = "renesas,r8a77990-lvds";
> +reg = <0 0xfeb90100 0 0x20>;
> +clocks = < CPG_MOD 727>;
> +power-domains = < R8A77990_PD_ALWAYS_ON>;
> +resets = < 726>;
> >>
> >> Also, is the missmatch between the index for the clock and reset
> >> intentional?
> >
> > It is. According to the datasheet, the two LVDS encoders have
> > different module stop bits, but share the same reset (lovely
> > hardware design, it will be fun to support that in the driver :-S).
>
> Sorry, I got it wrong. it's bit 725 that is shared between the two
> LVDS encoders, to reset the two LVDS PLLs together. The encoders
> themselves still have independent reset bits. I'll fix this.
> >>>
> >>> And of course it's the clock you were commenting on, not the reset.
> >>> *sigh*
> >>>
> >>> According to the datasheets the two LVDS encoders share one MSTP.
> >>> Whether that's a mistake in the documentation or not I can't tell yet,
> >>> as I have only tested LVDS0.
> >>
> >> Could we follow-up with the HW team?
> >> I'm not opposed to taking the patch with this portion as-is
> >> but it would be good to clarify this somehow.
> >
> > I tried setting the clock to MSTP 726, and I then get vblank interrupt
> > timeouts. Furthermore I've now tested the LVDS1 output with a display
> > panel, and while I still can't get the backlight to work, the panel
> > displays the correct image with MSTP 727. I thus conclude that the above
> > is correct.
>
> Thanks for the follow-up, that sounds reasonable to me.
>
> Am I correct in thinking a v3 of this patchset is on its way regardless?
Yes, you're correct.
> +status = "disabled";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +
Re: [PATCH] drm: rcar-du: Revert "drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying the logic"
On Mon, Sep 17, 2018 at 01:25:49PM +0100, Alexandru-Cosmin Gheorghe wrote:
> Hi Kieran,
>
> On Mon, Sep 17, 2018 at 11:56:23AM +0100, Kieran Bingham wrote:
> > Hi Alexandru,
> >
> > On 17/09/18 10:10, Alexandru-Cosmin Gheorghe wrote:
> > > Hi Kieran,
> > >
> > > Sorry for that and thanks for getting to the bottom of it.
> >
> > No worries,
> >
> >
> > > On Fri, Sep 14, 2018 at 11:28:05PM +0100, Kieran Bingham wrote:
> > >> Hi Laurent,
> > >>
> > >> I've looked through a bit further to try to understand this issue and I
> > >> think I have identified a possible/probable cause.
> > >>
> > >> Before commit 161ad653d6c9, we *always* set the plane->state->alpha as
> > >> DRM_BLEND_ALPHA_OPAQUE. (0x)
> > >>
> > >> After this commit, the __drm_atomic_helper_plane_reset() call will only
> > >> set state->alpha to 0x if the alpha_property is set:
> > >>
> > >> if (plane->alpha_property)
> > >> state->alpha = plane->alpha_property->values[1];
> > >>
> > >> Then the state->alpha value is always referenced in
> > >> rcar_du_vsp_plane_setup() and passed to the VSP for that layer.
> > >>
> > >>
> > >> We can see in rcar_du_planes_init(), that all OVERLAY planes are
> > >> configured to have this propery with a call to
> > >> drm_plane_create_alpha_property(>plane); however - the PRIMARY
> > >> plane is skipped over before setting this.
> > >>
> > >>
> > >> I believe I recall seeing that the kms-test-planeposition.py
> > >> successfully showed other planes which were not the back one (I'm now
> > >> going from hazy memory of this afternoon - but I am fairly sure I saw
> > >> this)
> > >>
> > >>
> > >> This implies that the primary planes are being incorrectly configured -
> > >> but the overlay planes are still functioning as expected.
> > >>
> > >> So I believe we could move the call to create the alpha property:
> > >> drm_plane_create_alpha_property(>plane);
> > >>
> > >> to occur before the if (type == DRM_PLANE_TYPE_PRIMARY) continue;
> > >> statement.
> > >>
> > >
> > > I don't see any reson why the primary plane shouldn't advertise an
> > > alpha as well.
> >
> >
> > OK - so I think we perhaps should make sure that we enable alpha for our
> > primary plane in rcar-du.
> >
> >
> > >> It may or may not make sense to have alpha blending support on the
> > >> PRIMARY plane. At the risk of sounding silly - can we have anything else
> > >> behind the PRIMARY plane ? (I doubt this, I don't think we have any
> > >> extra layers hiding anywhere)
> > >
> > > I think the same question could apply to situations where PRIMARY is
> > > disabled and you have just one OVERLAY plane enabled.
> > >
> > >>
> > >> Otherwise, I think we would need to intercept the configuration of the
> > >> alpha blending and make sure that all PRIMARY planes are configured to
> > >> be fully opaque in our layers. I think this is happening in
> > >> rcar_du_vsp_plane_setup().
> > >>
> > >> But rather than put in a conditional in there, I think I'd rather just
> > >> initialise the plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE in our
> > >> rcar_du_vsp_plane_reset() call and be done with it.
> > >
> > > I think you could do more and just go in
> > > __drm_atomic_helper_plane_reset and always initializes plane->alpha
> > > with DRM_BLEND_ALPHA_OPAQUE, this way nobody else hits this problem.
> >
> > I think this sounds like a good thing too.
> >
> > Is DRM_BLEND_ALPHA_OPAQUE a suitable initial value for all of the other
> > users of the helper ?
> >
> > I suspect the answer is yes, but I'll try to do a bit of digging through
> > the other drivers tomorrow.
> >
>
> Yes, but it doesn't hurt for another pair of eyes to have a look.
Just hard-code init alpha to OPAQUE is imo the correct fix. The current is
not matching the general style we use for state parameters at all, and I
don't see a reason why it's different. The comment is what the code should
actually do I think.
-Daniel
>
> > I presume we could then just remove the conditional check and always
> > initialise to OPAQUE ...
> >
> > Or otherwise perhaps maybe initialising as an 'else' if no alpha
> > property is provided.
> >
> > --
> > Regards
> >
> > Kieran
> >
> >
> >
> >
> >
> >
> > >>
> > >> Anyway - just some musings and thoughts at this stage, we can
> > >> investigate in more detail next week.
> > >>
> > >> --
> > >> Regards
> > >>
> > >> Kieran
> > >>
> > >>
> > >> On 14/09/18 21:09, Kieran Bingham wrote:
> > >>> Commit: 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
> > >>> instead of copying the logic") causes a regression in the R-Car DU
> > >>> display driver, and prevents any output from being displayed.
> > >>>
> > >>> The display appears to function correctly but only a black screen is
> > >>> ever visible.
> > >>>
> > >>> Revert the commit.
> > >>>
> > >>> Signed-off-by: Kieran Bingham
> > >>>
> > >>> ---
> > >>>
> > >>> Looking through the code, the reason for this issue isn't particularly
> > >>>
Re: [Intel-gfx] [PATCH 2/2] drm: Fix syncobj handing of schedule() returning 0
On Tue, Sep 18, 2018 at 11:07:20AM +0100, Chris Wilson wrote:
> After schedule() returns 0, we must do one last check of COND to
> determine the reason for the wakeup with 0 jiffies remaining before
> reporting the timeout -- otherwise we may lose the signal due to
> scheduler delays.
Ah classic!
Reviewed-by: Daniel Vetter
> References: https://bugs.freedesktop.org/show_bug.cgi?id=106690
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/drm_syncobj.c | 41 +--
> 1 file changed, 15 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index e254f97fed7d..5bcb3ef9b256 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -672,7 +672,6 @@ static signed long drm_syncobj_array_wait_timeout(struct
> drm_syncobj **syncobjs,
> {
> struct syncobj_wait_entry *entries;
> struct dma_fence *fence;
> - signed long ret;
> uint32_t signaled_count, i;
>
> entries = kcalloc(count, sizeof(*entries), GFP_KERNEL);
> @@ -692,7 +691,7 @@ static signed long drm_syncobj_array_wait_timeout(struct
> drm_syncobj **syncobjs,
> if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) {
> continue;
> } else {
> - ret = -EINVAL;
> + timeout = -EINVAL;
> goto cleanup_entries;
> }
> }
> @@ -704,12 +703,6 @@ static signed long drm_syncobj_array_wait_timeout(struct
> drm_syncobj **syncobjs,
> }
> }
>
> - /* Initialize ret to the max of timeout and 1. That way, the
> - * default return value indicates a successful wait and not a
> - * timeout.
> - */
> - ret = max_t(signed long, timeout, 1);
> -
> if (signaled_count == count ||
> (signaled_count > 0 &&
>!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL)))
> @@ -760,18 +753,17 @@ static signed long
> drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
> goto done_waiting;
>
> if (timeout == 0) {
> - /* If we are doing a 0 timeout wait and we got
> - * here, then we just timed out.
> - */
> - ret = 0;
> + timeout = -ETIME;
> goto done_waiting;
> }
>
> - ret = schedule_timeout(ret);
> + if (signal_pending(current)) {
> + timeout = -ERESTARTSYS;
> + goto done_waiting;
> + }
>
> - if (ret > 0 && signal_pending(current))
> - ret = -ERESTARTSYS;
> - } while (ret > 0);
> + timeout = schedule_timeout(timeout);
> + } while (1);
>
> done_waiting:
> __set_current_state(TASK_RUNNING);
> @@ -788,7 +780,7 @@ static signed long drm_syncobj_array_wait_timeout(struct
> drm_syncobj **syncobjs,
> }
> kfree(entries);
>
> - return ret;
> + return timeout;
> }
>
> /**
> @@ -829,19 +821,16 @@ static int drm_syncobj_array_wait(struct drm_device
> *dev,
> struct drm_syncobj **syncobjs)
> {
> signed long timeout = drm_timeout_abs_to_jiffies(wait->timeout_nsec);
> - signed long ret = 0;
> uint32_t first = ~0;
>
> - ret = drm_syncobj_array_wait_timeout(syncobjs,
> - wait->count_handles,
> - wait->flags,
> - timeout, );
> - if (ret < 0)
> - return ret;
> + timeout = drm_syncobj_array_wait_timeout(syncobjs,
> + wait->count_handles,
> + wait->flags,
> + timeout, );
> + if (timeout < 0)
> + return timeout;
>
> wait->first_signaled = first;
> - if (ret == 0)
> - return -ETIME;
> return 0;
> }
>
> --
> 2.19.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/5] drm: more byteorder fixes
On Wed, Sep 19, 2018 at 01:12:47PM +0200, Gerd Hoffmann wrote: > Fix fbdev emulation. > Fix bochs-drm and virtio-gpu drivers. > > Gerd Hoffmann (5): > drm: move native byte order quirk to new drm_mode_legacy_fb_format2 > function > drm: use drm_mode_legacy_fb_format2 in drm_gem_fbdev_fb_create > drm/bochs: fix DRM_FORMAT_* handling for big endian machines. > drm/bochs: support changing byteorder at mode set time > drm/virtio: fix DRM_FORMAT_* handling Aside from the "naming is hard" nit, series looks good. With the naming figured out somehow, Acked-by: Daniel Vetter on the entire series. -Daniel > > drivers/gpu/drm/bochs/bochs.h| 4 +- > include/drm/drm_fourcc.h | 2 + > drivers/gpu/drm/bochs/bochs_fbdev.c | 18 ++-- > drivers/gpu/drm/bochs/bochs_hw.c | 64 > ++-- > drivers/gpu/drm/bochs/bochs_kms.c| 40 - > drivers/gpu/drm/drm_fourcc.c | 28 > drivers/gpu/drm/drm_framebuffer.c| 15 ++- > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 ++- > drivers/gpu/drm/virtio/virtgpu_display.c | 5 +++ > drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +- > drivers/gpu/drm/virtio/virtgpu_gem.c | 7 ++- > drivers/gpu/drm/virtio/virtgpu_plane.c | 54 +-- > 12 files changed, 155 insertions(+), 90 deletions(-) > > -- > 2.9.3 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: simplify DMA mapping
Hi Andrzej,
On 2018-09-21 10:58, Andrzej Hajda wrote:
> Moving DMA mapping creation to drm_iommu_attach_device allows to avoid
> looping through all components and maintaining DMA device flags.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 50 +++
> drivers/gpu/drm/exynos/exynos_drm_iommu.c | 13 +-
I like simplification, but this one is a bit too invasive. It breaks
Exynos DRM when IOMMU support is disabled (dma_dev won't be set in such
case).
> 2 files changed, 17 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index b599f74692e5..c83437d8a595 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -197,8 +197,7 @@ struct exynos_drm_driver_info {
>
> #define DRM_COMPONENT_DRIVERBIT(0) /* supports component framework
> */
> #define DRM_VIRTUAL_DEVICE BIT(1) /* create virtual platform device */
> -#define DRM_DMA_DEVICE BIT(2) /* can be used for dma
> allocations */
> -#define DRM_FIMC_DEVICE BIT(3) /* devices shared with V4L2
> subsystem */
> +#define DRM_FIMC_DEVICE BIT(2) /* devices shared with V4L2
> subsystem */
>
> #define DRV_PTR(drv, cond) (IS_ENABLED(cond) ? : NULL)
>
> @@ -209,16 +208,16 @@ struct exynos_drm_driver_info {
> static struct exynos_drm_driver_info exynos_drm_drivers[] = {
> {
> DRV_PTR(fimd_driver, CONFIG_DRM_EXYNOS_FIMD),
> - DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
> + DRM_COMPONENT_DRIVER
> }, {
> DRV_PTR(exynos5433_decon_driver, CONFIG_DRM_EXYNOS5433_DECON),
> - DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
> + DRM_COMPONENT_DRIVER
> }, {
> DRV_PTR(decon_driver, CONFIG_DRM_EXYNOS7_DECON),
> - DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
> + DRM_COMPONENT_DRIVER
> }, {
> DRV_PTR(mixer_driver, CONFIG_DRM_EXYNOS_MIXER),
> - DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
> + DRM_COMPONENT_DRIVER
> }, {
> DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
> DRM_COMPONENT_DRIVER
> @@ -289,27 +288,6 @@ static struct component_match
> *exynos_drm_match_add(struct device *dev)
> return match ?: ERR_PTR(-ENODEV);
> }
>
> -static struct device *exynos_drm_get_dma_device(void)
> -{
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(exynos_drm_drivers); ++i) {
> - struct exynos_drm_driver_info *info = _drm_drivers[i];
> - struct device *dev;
> -
> - if (!info->driver || !(info->flags & DRM_DMA_DEVICE))
> - continue;
> -
> - while ((dev = bus_find_device(_bus_type, NULL,
> - >driver->driver,
> - (void *)platform_bus_type.match))) {
> - put_device(dev);
> - return dev;
> - }
> - }
> - return NULL;
> -}
> -
> static int exynos_drm_bind(struct device *dev)
> {
> struct exynos_drm_private *private;
> @@ -334,23 +312,6 @@ static int exynos_drm_bind(struct device *dev)
> dev_set_drvdata(dev, drm);
> drm->dev_private = (void *)private;
>
> - /* the first real CRTC device is used for all dma mapping operations */
> - private->dma_dev = exynos_drm_get_dma_device();
> - if (!private->dma_dev) {
> - DRM_ERROR("no device found for DMA mapping operations.\n");
> - ret = -ENODEV;
> - goto err_free_private;
> - }
> - DRM_INFO("Exynos DRM: using %s device for DMA mapping operations\n",
> - dev_name(private->dma_dev));
> -
> - /* create common IOMMU mapping for all devices attached to Exynos DRM */
> - ret = drm_create_iommu_mapping(drm);
> - if (ret < 0) {
> - DRM_ERROR("failed to create iommu mapping.\n");
> - goto err_free_private;
> - }
> -
> drm_mode_config_init(drm);
>
> exynos_drm_mode_config_init(drm);
> @@ -408,7 +369,6 @@ static int exynos_drm_bind(struct device *dev)
> err_mode_config_cleanup:
> drm_mode_config_cleanup(drm);
> drm_release_iommu_mapping(drm);
> -err_free_private:
> kfree(private);
> err_free_drm:
> drm_dev_put(drm);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> index 0f373702414e..bb8b800a9fba 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> @@ -75,7 +75,18 @@ int drm_iommu_attach_device(struct drm_device *drm_dev,
> struct exynos_drm_private *priv = drm_dev->dev_private;
> int ret;
>
> - if (get_dma_ops(priv->dma_dev) != get_dma_ops(subdrv_dev)) {
> + if (!priv->dma_dev) {
> +
Re: [PATCH v8 1/2] drm/panel: Add support for Truly NT35597 panel driver
On Thu, Sep 20, 2018 at 03:52:36PM -0700, Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
>
> Add support for Truly NT35597 panel driver used
> in MSM reference platforms.
>
> This panel driver supports both single DSI and dual DSI
> modes.
>
> However, this patch series adds support only for
> dual DSI mode.
>
> Changes in v8:
> - Remove video mode config and headers
> - Remove unused macros
> - Try to avoid multi-lines wherever possible
> - Fix comments locations and make it concise
> - Fix return points in probe function
Thanks for revising!
Reviewed-by: Sean Paul
>
> Signed-off-by: Archit Taneja
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/panel/Kconfig | 7 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-truly-nt35597.c | 676
>
> 3 files changed, 684 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 6020c30..073ffa0 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -186,4 +186,11 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>
> +config DRM_PANEL_TRULY_NT35597_WQXGA
> + tristate "Truly WQXGA"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + help
> + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
> DSI
> + Video Mode panel
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 5ccaaa9..80fd19f 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
> panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
> b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> new file mode 100644
> index 000..c9e09e2
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> @@ -0,0 +1,676 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static const char * const regulator_names[] = {
> + "vdda",
> + "vdispp",
> + "vdispn",
> +};
> +
> +static unsigned long const regulator_enable_loads[] = {
> + 62000,
> + 10,
> + 10,
> +};
> +
> +static unsigned long const regulator_disable_loads[] = {
> + 80,
> + 100,
> + 100,
> +};
> +
> +struct nt35597_config {
> + u32 width_mm;
> + u32 height_mm;
> + const char *panel_name;
> + const void *panel_on_cmds;
> + u32 num_on_cmds;
> + const struct drm_display_mode *dm;
> +};
> +
> +struct truly_nt35597 {
> + struct device *dev;
> + struct drm_panel panel;
> +
> + struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
> +
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *mode_gpio;
> +
> + struct backlight_device *backlight;
> +
> + struct mipi_dsi_device *dsi[2];
> +
> + const struct nt35597_config *config;
> + bool prepared;
> + bool enabled;
> +};
> +
> +static inline struct truly_nt35597 *panel_to_ctx(struct drm_panel *panel)
> +{
> + return container_of(panel, struct truly_nt35597, panel);
> +}
> +
> +struct cmd_set {
> + u8 commands[4];
> + u8 size;
> +};
> +
> +static struct cmd_set qcom_2k_panel_magic_cmds[] = {
> + /* CMD2_P0 */
> + { { 0xff, 0x20 }, 2 },
> + { { 0xfb, 0x01 }, 2 },
> + { { 0x00, 0x01 }, 2 },
> + { { 0x01, 0x55 }, 2 },
> + { { 0x02, 0x45 }, 2 },
> + { { 0x05, 0x40 }, 2 },
> + { { 0x06, 0x19 }, 2 },
> + { { 0x07, 0x1e }, 2 },
> + { { 0x0b, 0x73 }, 2 },
> + { { 0x0c, 0x73 }, 2 },
> + { { 0x0e, 0xb0 }, 2 },
> + { { 0x0f, 0xae }, 2 },
> + { { 0x11, 0xb8 }, 2 },
> + { { 0x13, 0x00 }, 2 },
> + { { 0x58, 0x80 }, 2 },
> + { { 0x59, 0x01 }, 2 },
> + { { 0x5a, 0x00 }, 2 },
> + { { 0x5b, 0x01 }, 2 },
> + { { 0x5c, 0x80 }, 2 },
> + { { 0x5d, 0x81 }, 2 },
> + { { 0x5e, 0x00 }, 2 },
> + { { 0x5f, 0x01 }, 2 },
> + { { 0x72, 0x11 }, 2 },
> + { { 0x68, 0x03 }, 2 },
> + /* CMD2_P4 */
> + { { 0xFF, 0x24 }, 2 },
> + { { 0xFB, 0x01 }, 2 },
> + { { 0x00, 0x1C }, 2 },
> + { { 0x01, 0x0B }, 2 },
> + { { 0x02, 0x0C }, 2 },
> + { { 0x03, 0x01 }, 2 },
> + { { 0x04, 0x0F }, 2 },
> + { { 0x05, 0x10 }, 2 },
> + { { 0x06, 0x10 },
[PATCH v2] drm/exynos: simplify DMA mapping
Moving DMA mapping creation to drm_iommu_attach_device allows to avoid
looping through all components and maintaining DMA device flags.
v2: take care of configurations without IOMMU
Signed-off-by: Andrzej Hajda
---
Hi Inki,
In the 2nd version I took care of non-iommu case, thanks to Marek.
Regards
Andrzej
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 71 +++
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 +
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_scaler.c| 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
11 files changed, 37 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 94529aa82339..b0d80e17ab85 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -578,7 +578,7 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
decon_clear_channels(ctx->crtc);
- return drm_iommu_attach_device(drm_dev, dev);
+ return exynos_drm_register_dma(drm_dev, dev);
}
static void decon_unbind(struct device *dev, struct device *master, void *data)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 88cbd000eb09..e78978eea5cb 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -133,7 +133,7 @@ static int decon_ctx_initialize(struct decon_context *ctx,
decon_clear_channels(ctx->crtc);
- return drm_iommu_attach_device(drm_dev, ctx->dev);
+ return exynos_drm_register_dma(drm_dev, ctx->dev);
}
static void decon_ctx_remove(struct decon_context *ctx)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b599f74692e5..bc20fb1b26e1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -45,6 +45,27 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 1
+int exynos_drm_register_dma(struct drm_device *drm, struct device *dev)
+{
+ struct exynos_drm_private *priv = drm->dev_private;
+ int ret;
+
+ if (!priv->dma_dev) {
+ priv->dma_dev = dev;
+ DRM_INFO("Exynos DRM: using %s device for DMA mapping
operations\n",
+dev_name(dev));
+ /* create common IOMMU mapping for all Exynos DRM devices */
+ ret = drm_create_iommu_mapping(drm);
+ if (ret < 0) {
+ priv->dma_dev = NULL;
+ DRM_ERROR("failed to create iommu mapping.\n");
+ return -EINVAL;
+ }
+ }
+
+ return drm_iommu_attach_device(drm, dev);
+}
+
static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
{
struct drm_exynos_file_private *file_priv;
@@ -197,8 +218,7 @@ struct exynos_drm_driver_info {
#define DRM_COMPONENT_DRIVER BIT(0) /* supports component framework */
#define DRM_VIRTUAL_DEVICE BIT(1) /* create virtual platform device */
-#define DRM_DMA_DEVICE BIT(2) /* can be used for dma allocations */
-#define DRM_FIMC_DEVICEBIT(3) /* devices shared with V4L2
subsystem */
+#define DRM_FIMC_DEVICEBIT(2) /* devices shared with V4L2
subsystem */
#define DRV_PTR(drv, cond) (IS_ENABLED(cond) ? : NULL)
@@ -209,16 +229,16 @@ struct exynos_drm_driver_info {
static struct exynos_drm_driver_info exynos_drm_drivers[] = {
{
DRV_PTR(fimd_driver, CONFIG_DRM_EXYNOS_FIMD),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(exynos5433_decon_driver, CONFIG_DRM_EXYNOS5433_DECON),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(decon_driver, CONFIG_DRM_EXYNOS7_DECON),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(mixer_driver, CONFIG_DRM_EXYNOS_MIXER),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
DRM_COMPONENT_DRIVER
@@ -289,27 +309,6 @@ static struct component_match *exynos_drm_match_add(struct
device *dev)
return match ?: ERR_PTR(-ENODEV);
}
-static struct device *exynos_drm_get_dma_device(void)
-{
- int i;
-
- for (i = 0; i <
[GIT PULL] mali-dp fixes
Hi Dave, I have managed to push the fixes to the public tree without sending the pull request until today when I did a clean checkout of drm-fixes and realised my mistake. I've now rebased the tree on your latest drm-fixes branch. At your convenience, please pull these two patches. Many thanks, Liviu The following changes since commit 4fcb7f8be829d21bcbb24eef2204fb6b34ed1f80: Merge branch 'drm-fixes-4.19' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2018-09-21 09:52:27 +1000) are available in the Git repository at: git://linux-arm.org/linux-ld.git for-upstream/malidp-fixes for you to fetch changes up to 89578d04b52c872aef6b1257b5f6caf6bcc35abe: drm/malidp: Fix writeback in NV12 (2018-09-21 10:55:00 +0100) Alexandru Gheorghe (2): drm: mali-dp: Call drm_crtc_vblank_reset on device init drm/malidp: Fix writeback in NV12 drivers/gpu/drm/arm/malidp_drv.c | 1 + drivers/gpu/drm/arm/malidp_hw.c | 25 +++-- drivers/gpu/drm/arm/malidp_hw.h | 3 ++- drivers/gpu/drm/arm/malidp_mw.c | 25 + drivers/gpu/drm/arm/malidp_regs.h | 2 ++ 5 files changed, 49 insertions(+), 7 deletions(-) -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/2] dt-bindings: Add Truly NT35597 panel driver bindings
On Thu, Sep 20, 2018 at 03:52:37PM -0700, Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
>
> Add the device tree bindings for Truly NT35597 panel driver.
> This panel driver supports both single DSI and dual DSI.
>
> However, this patch series supports only dual DSI.
>
> Changes in v8:
> - None
>
> Signed-off-by: Abhinav Kumar
Cc: robh...@kernel.org
> ---
> .../devicetree/bindings/display/truly,nt35597.txt | 60
> ++
> 1 file changed, 60 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/truly,nt35597.txt
>
> diff --git a/Documentation/devicetree/bindings/display/truly,nt35597.txt
> b/Documentation/devicetree/bindings/display/truly,nt35597.txt
> new file mode 100644
> index 000..46b29eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/truly,nt35597.txt
> @@ -0,0 +1,60 @@
> +Truly model NT35597 DSI display driver
> +
> +The Truly NT35597 is a generic display driver, currently only configured
> +for use in the 2K display on the Qualcomm SDM845.
> +
> +Required properties:
> +- compatible: should be "truly,nt35597-2K-display"
> +- vdda-supply: phandle of the regulator that provides the supply voltage
> + Power IC supply
> +- vdispp-supply: phandle of the regulator that provides the supply voltage
> + for positive LCD bias
> +- vdispn-supply: phandle of the regulator that provides the supply voltage
> + for negative LCD bias
> +- reset-gpios: phandle of gpio for reset line
> + This should be 8mA, gpio can be configured using mux, pinctrl,
> pinctrl-names
> + (active low)
> +- mode-gpios: phandle of the gpio for choosing the mode of the display
> + for single DSI or Dual DSI
> + (active high)
> + This should be low for dual DSI and high for single DSI mode
> +- ports: This device has two video ports driven by two DSIs. Their
> connections
> + are modelled using the OF graph bindings specified in
> + Documentation/devicetree/bindings/graph.txt.
> + - port@0: DSI input port driven by master DSI
> + - port@1: DSI input port driven by secondary DSI
> +
> +Example:
> +
> + dsi@ae94000 {
> + panel@0 {
> + compatible = "truly,nt35597-2K-display";
> + reg = <0>;
> + vdda-supply = <_l14>;
> + vdispp-supply = <_regulator>;
> + vdispn-supply = <_regulator>;
> + pinctrl-names = "default", "suspend";
> + pinctrl-0 = <_dsi_active>;
> + pinctrl-1 = <_dsi_suspend>;
> +
> + reset-gpios = < 6 GPIO_ACTIVE_LOW>;
> + mode-gpios = < 52 GPIO_ACTIVE_HIGH>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + panel0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + panel1_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> + };
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107956] [CI][SHARDS] igt@kms_busy@extended_*_render-[abc] - dmesg-warn - Asynchronous wait on fence i915:kms_busy\[\d+\]/0:1 timed out \(hint:intel_atomic_commit_ready
https://bugs.freedesktop.org/show_bug.cgi?id=107956 --- Comment #4 from Martin Peres --- https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_114/fi-ilk-650/igt@kms_b...@extended-pageflip-hang-newfb-render-b.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_113/fi-byt-clapper/igt@kms_b...@extended-pageflip-hang-newfb-render-b.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_114/fi-byt-n2820/igt@kms_b...@extended-pageflip-hang-newfb-render-a.html [618.939579] Asynchronous wait on fence i915:rcs0:9599 timed out (hint:intel_atomic_commit_ready+0x0/0x4c [i915]) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/2] dt-bindings: Add Truly NT35597 panel driver bindings
On Thu, Sep 20, 2018 at 03:52:37PM -0700, Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
JFYI, this is going to munge your Author name. This can be fixed up when the
patch is applied, so probably not worth a v9.
Reviewed-by: Sean Paul
>
> Add the device tree bindings for Truly NT35597 panel driver.
> This panel driver supports both single DSI and dual DSI.
>
> However, this patch series supports only dual DSI.
>
> Changes in v8:
> - None
>
> Signed-off-by: Abhinav Kumar
> ---
> .../devicetree/bindings/display/truly,nt35597.txt | 60
> ++
> 1 file changed, 60 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/truly,nt35597.txt
>
> diff --git a/Documentation/devicetree/bindings/display/truly,nt35597.txt
> b/Documentation/devicetree/bindings/display/truly,nt35597.txt
> new file mode 100644
> index 000..46b29eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/truly,nt35597.txt
> @@ -0,0 +1,60 @@
> +Truly model NT35597 DSI display driver
> +
> +The Truly NT35597 is a generic display driver, currently only configured
> +for use in the 2K display on the Qualcomm SDM845.
> +
> +Required properties:
> +- compatible: should be "truly,nt35597-2K-display"
> +- vdda-supply: phandle of the regulator that provides the supply voltage
> + Power IC supply
> +- vdispp-supply: phandle of the regulator that provides the supply voltage
> + for positive LCD bias
> +- vdispn-supply: phandle of the regulator that provides the supply voltage
> + for negative LCD bias
> +- reset-gpios: phandle of gpio for reset line
> + This should be 8mA, gpio can be configured using mux, pinctrl,
> pinctrl-names
> + (active low)
> +- mode-gpios: phandle of the gpio for choosing the mode of the display
> + for single DSI or Dual DSI
> + (active high)
> + This should be low for dual DSI and high for single DSI mode
> +- ports: This device has two video ports driven by two DSIs. Their
> connections
> + are modelled using the OF graph bindings specified in
> + Documentation/devicetree/bindings/graph.txt.
> + - port@0: DSI input port driven by master DSI
> + - port@1: DSI input port driven by secondary DSI
> +
> +Example:
> +
> + dsi@ae94000 {
> + panel@0 {
> + compatible = "truly,nt35597-2K-display";
> + reg = <0>;
> + vdda-supply = <_l14>;
> + vdispp-supply = <_regulator>;
> + vdispn-supply = <_regulator>;
> + pinctrl-names = "default", "suspend";
> + pinctrl-0 = <_dsi_active>;
> + pinctrl-1 = <_dsi_suspend>;
> +
> + reset-gpios = < 6 GPIO_ACTIVE_LOW>;
> + mode-gpios = < 52 GPIO_ACTIVE_HIGH>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + panel0_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + panel1_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> + };
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=104602 --- Comment #11 from Jason Playne --- (In reply to Jason Playne from comment #10) > (In reply to Timothy Arceri from comment #9) > > I'm not sure why yet but both the black triangles and the incorrect > > rendering behind the chinese emperor on the loading screen go away when I > > run the trace on the NIR backend. > > > > Until we figure out what is going on here you can try running the game with > > the following environment variable: > > > > R600_DEBUG=nir > > Can confirm! The initial red+black triangles in the game seem to have > disappeared using the nir backend. > > (I may be a little excited!) After a couple of hours of game time, I have not seen the triangles. nir solves the problem Thanks Timothy! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/2] drm/panel: Add support for Truly NT35597 panel driver
On Thu, Sep 20, 2018 at 03:52:36PM -0700, Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
>
> Add support for Truly NT35597 panel driver used
> in MSM reference platforms.
>
> This panel driver supports both single DSI and dual DSI
> modes.
>
> However, this patch series adds support only for
> dual DSI mode.
>
> Changes in v8:
> - Remove video mode config and headers
> - Remove unused macros
> - Try to avoid multi-lines wherever possible
> - Fix comments locations and make it concise
> - Fix return points in probe function
>
> Signed-off-by: Archit Taneja
> Signed-off-by: Abhinav Kumar
Adding Cc: robh...@kernel.org so Rob sees it in his patchwork queue.
Sean
> ---
> drivers/gpu/drm/panel/Kconfig | 7 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-truly-nt35597.c | 676
>
> 3 files changed, 684 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 6020c30..073ffa0 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -186,4 +186,11 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>
> +config DRM_PANEL_TRULY_NT35597_WQXGA
> + tristate "Truly WQXGA"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + help
> + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
> DSI
> + Video Mode panel
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 5ccaaa9..80fd19f 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
> panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
> b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> new file mode 100644
> index 000..c9e09e2
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> @@ -0,0 +1,676 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static const char * const regulator_names[] = {
> + "vdda",
> + "vdispp",
> + "vdispn",
> +};
> +
> +static unsigned long const regulator_enable_loads[] = {
> + 62000,
> + 10,
> + 10,
> +};
> +
> +static unsigned long const regulator_disable_loads[] = {
> + 80,
> + 100,
> + 100,
> +};
> +
> +struct nt35597_config {
> + u32 width_mm;
> + u32 height_mm;
> + const char *panel_name;
> + const void *panel_on_cmds;
> + u32 num_on_cmds;
> + const struct drm_display_mode *dm;
> +};
> +
> +struct truly_nt35597 {
> + struct device *dev;
> + struct drm_panel panel;
> +
> + struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
> +
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *mode_gpio;
> +
> + struct backlight_device *backlight;
> +
> + struct mipi_dsi_device *dsi[2];
> +
> + const struct nt35597_config *config;
> + bool prepared;
> + bool enabled;
> +};
> +
> +static inline struct truly_nt35597 *panel_to_ctx(struct drm_panel *panel)
> +{
> + return container_of(panel, struct truly_nt35597, panel);
> +}
> +
> +struct cmd_set {
> + u8 commands[4];
> + u8 size;
> +};
> +
> +static struct cmd_set qcom_2k_panel_magic_cmds[] = {
> + /* CMD2_P0 */
> + { { 0xff, 0x20 }, 2 },
> + { { 0xfb, 0x01 }, 2 },
> + { { 0x00, 0x01 }, 2 },
> + { { 0x01, 0x55 }, 2 },
> + { { 0x02, 0x45 }, 2 },
> + { { 0x05, 0x40 }, 2 },
> + { { 0x06, 0x19 }, 2 },
> + { { 0x07, 0x1e }, 2 },
> + { { 0x0b, 0x73 }, 2 },
> + { { 0x0c, 0x73 }, 2 },
> + { { 0x0e, 0xb0 }, 2 },
> + { { 0x0f, 0xae }, 2 },
> + { { 0x11, 0xb8 }, 2 },
> + { { 0x13, 0x00 }, 2 },
> + { { 0x58, 0x80 }, 2 },
> + { { 0x59, 0x01 }, 2 },
> + { { 0x5a, 0x00 }, 2 },
> + { { 0x5b, 0x01 }, 2 },
> + { { 0x5c, 0x80 }, 2 },
> + { { 0x5d, 0x81 }, 2 },
> + { { 0x5e, 0x00 }, 2 },
> + { { 0x5f, 0x01 }, 2 },
> + { { 0x72, 0x11 }, 2 },
> + { { 0x68, 0x03 }, 2 },
> + /* CMD2_P4 */
> + { { 0xFF, 0x24 }, 2 },
> + { { 0xFB, 0x01 }, 2 },
> + { { 0x00, 0x1C }, 2 },
> + { { 0x01, 0x0B }, 2 },
> + { { 0x02, 0x0C }, 2 },
> + { { 0x03, 0x01 }, 2 },
> + { { 0x04, 0x0F }, 2 },
> + { { 0x05, 0x10 }, 2
Re: [PATCH 2/3] drm/exynos: scaler: Add support for tiled formats
Hi Inki,
On 2018-09-21 05:20, Inki Dae wrote:
> There are several warnings,
> WARNING: line over 80 characters
> #276: FILE: drivers/gpu/drm/exynos/exynos_drm_scaler.c:182:
> + struct drm_exynos_ipp_task_rect *src_pos, const struct scaler_format
> *fmt)
>
> WARNING: line over 80 characters
> #297: FILE: drivers/gpu/drm/exynos/exynos_drm_scaler.c:363:
> + const struct scaler_format *src_fmt =
> scaler_get_format(task->src.buf.fourcc);
>
> WARNING: line over 80 characters
> #301: FILE: drivers/gpu/drm/exynos/exynos_drm_scaler.c:366:
> + const struct scaler_format *dst_fmt =
> scaler_get_format(task->dst.buf.fourcc);
>
> total: 0 errors, 3 warnings, 192 lines checked
>
>
> And comment below.
>
>
> On 2018년 08월 10일 22:29, Marek Szyprowski wrote:
>> From: Andrzej Pietrasiewicz
>>
>> Add support for 16x16 tiled formats: NV12/NV21, YUYV and YUV420.
>>
>> Signed-off-by: Andrzej Pietrasiewicz
>> Signed-off-by: Marek Szyprowski
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 133 -
>> 1 file changed, 75 insertions(+), 58 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
>> b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
>> index 0ddb6eec7b11..8e761ef63eac 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
>> @@ -49,56 +49,46 @@ struct scaler_context {
>> const struct scaler_data*scaler_data;
>> };
>>
>> -static u32 scaler_get_format(u32 drm_fmt)
>> +struct scaler_format {
>> +u32 drm_fmt;
>> +u32 internal_fmt;
>> +u32 chroma_tile_w;
>> +u32 chroma_tile_h;
>> +};
>> +
>> +static const struct scaler_format scaler_formats[] = {
>> +{ DRM_FORMAT_NV12, SCALER_YUV420_2P_UV, 8, 8 },
>> +{ DRM_FORMAT_NV21, SCALER_YUV420_2P_VU, 8, 8 },
>> +{ DRM_FORMAT_YUV420, SCALER_YUV420_3P, 8, 8 },
>> +{ DRM_FORMAT_YUYV, SCALER_YUV422_1P_YUYV, 16, 16 },
>> +{ DRM_FORMAT_UYVY, SCALER_YUV422_1P_UYVY, 16, 16 },
>> +{ DRM_FORMAT_YVYU, SCALER_YUV422_1P_YVYU, 16, 16 },
>> +{ DRM_FORMAT_NV16, SCALER_YUV422_2P_UV, 8, 16 },
>> +{ DRM_FORMAT_NV61, SCALER_YUV422_2P_VU, 8, 16 },
>> +{ DRM_FORMAT_YUV422, SCALER_YUV422_3P, 8, 16 },
>> +{ DRM_FORMAT_NV24, SCALER_YUV444_2P_UV, 16, 16 },
>> +{ DRM_FORMAT_NV42, SCALER_YUV444_2P_VU, 16, 16 },
>> +{ DRM_FORMAT_YUV444, SCALER_YUV444_3P, 16, 16 },
>> +{ DRM_FORMAT_RGB565, SCALER_RGB_565, 0, 0 },
>> +{ DRM_FORMAT_XRGB1555, SCALER_ARGB1555, 0, 0 },
>> +{ DRM_FORMAT_ARGB1555, SCALER_ARGB1555, 0, 0 },
>> +{ DRM_FORMAT_XRGB, SCALER_ARGB, 0, 0 },
>> +{ DRM_FORMAT_ARGB, SCALER_ARGB, 0, 0 },
>> +{ DRM_FORMAT_XRGB, SCALER_ARGB, 0, 0 },
>> +{ DRM_FORMAT_ARGB, SCALER_ARGB, 0, 0 },
>> +{ DRM_FORMAT_RGBX, SCALER_RGBA, 0, 0 },
>> +{ DRM_FORMAT_RGBA, SCALER_RGBA, 0, 0 },
>> +};
>> +
>> +static const struct scaler_format *scaler_get_format(u32 drm_fmt)
>> {
>> -switch (drm_fmt) {
>> -case DRM_FORMAT_NV12:
>> -return SCALER_YUV420_2P_UV;
>> -case DRM_FORMAT_NV21:
>> -return SCALER_YUV420_2P_VU;
>> -case DRM_FORMAT_YUV420:
>> -return SCALER_YUV420_3P;
>> -case DRM_FORMAT_YUYV:
>> -return SCALER_YUV422_1P_YUYV;
>> -case DRM_FORMAT_UYVY:
>> -return SCALER_YUV422_1P_UYVY;
>> -case DRM_FORMAT_YVYU:
>> -return SCALER_YUV422_1P_YVYU;
>> -case DRM_FORMAT_NV16:
>> -return SCALER_YUV422_2P_UV;
>> -case DRM_FORMAT_NV61:
>> -return SCALER_YUV422_2P_VU;
>> -case DRM_FORMAT_YUV422:
>> -return SCALER_YUV422_3P;
>> -case DRM_FORMAT_NV24:
>> -return SCALER_YUV444_2P_UV;
>> -case DRM_FORMAT_NV42:
>> -return SCALER_YUV444_2P_VU;
>> -case DRM_FORMAT_YUV444:
>> -return SCALER_YUV444_3P;
>> -case DRM_FORMAT_RGB565:
>> -return SCALER_RGB_565;
>> -case DRM_FORMAT_XRGB1555:
>> -return SCALER_ARGB1555;
>> -case DRM_FORMAT_ARGB1555:
>> -return SCALER_ARGB1555;
>> -case DRM_FORMAT_XRGB:
>> -return SCALER_ARGB;
>> -case DRM_FORMAT_ARGB:
>> -return SCALER_ARGB;
>> -case DRM_FORMAT_XRGB:
>> -return SCALER_ARGB;
>> -case DRM_FORMAT_ARGB:
>> -return SCALER_ARGB;
>> -case DRM_FORMAT_RGBX:
>> -return SCALER_RGBA;
>> -case DRM_FORMAT_RGBA:
>> -return SCALER_RGBA;
>> -default:
>> -break;
>> -}
>> +int i;
>>
>> -return 0;
>> +for (i = 0; i < ARRAY_SIZE(scaler_formats); i++)
>> +if (scaler_formats[i].drm_fmt == drm_fmt)
>> +return _formats[i];
>> +
>> +return NULL;
>> }
>>
>> static inline int scaler_reset(struct scaler_context *scaler)
>> @@ -152,11 +142,11 @@ static inline void
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Wed, Sep 19, 2018 at 01:57:00PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 02:10:17PM -0700, Manasi Navare wrote:
> > On Tue, Sep 18, 2018 at 10:46:46PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> > > > On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > > > > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > > > > Thanks Imre for your review comments. Please find the comments
> > > > > > below:
> > > > > >
> > > > > > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > > > > > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > > > > > > On Icelake, a separate power well PG2 is created for
> > > > > > > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > > > > > > display power domain for Power well 2.
> > > > > > > >
> > > > > > > > Cc: Rodrigo Vivi
> > > > > > > > Cc: Imre Deak
> > > > > > > > Signed-off-by: Manasi Navare
> > > > > > > > ---
> > > > > > > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > > > > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > > > > > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > b/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > > > > > > POWER_DOMAIN_MODESET,
> > > > > > > > POWER_DOMAIN_GT_IRQ,
> > > > > > > > POWER_DOMAIN_INIT,
> > > > > > > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> > > > > > >
> > > > > > > This is better named VDSC_PIPE_A. The other pipes have also VDSC
> > > > > > > functionality which could be on separate power wells in the
> > > > > > > future.
> > > > > > >
> > > > > >
> > > > > > Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on Pipe
> > > > > > A
> > > > > > will use this VDSC power well.
> > > > > > I will change this in the next revision.
> > > > >
> > > > > Isn't the VDSC in the transcoder for now though? And I guess it's
> > > > > moving to the pipe later?
> > > >
> > > > VDSC engine is attached to the eDP/DSI transcoders and this gets used
> > > > for eDP/DSI VDSC on Pipe A.
> > >
> > > And what happens when I want to use pipe B instead?
> >
> > DP VDSC on Pipe B uses the VDSC engine on Pipe B. Same for Pipe C
>
> There are no VDSCs in pipe B or C. There are VDSCs in transcoder B
> and C. But that's not the same thing at all. The mux is between the
> pipe and transcoder.
>
As per the display overview for Gen 11, the VDSC engine is present on Pipe B
And C.
But for Pipe A only, it uses VDSC engine attached to transcoder eDP/DSI.
> > Can we have a situation where eDP uses Pipe B?
>
> Sure. 'xrandr --output eDP --crtc 1', or whatever.
>
I guess even in this case, if its eDP/DSI, it will still use the VDSC engine
on transcoder eDP so will need to enable this power well 2.
Manasi
> > Because in case of VDSC
> > in case of eDP, it will always use the VDSC on transcoder eDP which will
> > require this power well.
> >
> > Manasi
> >
> > >
> > > > So we could call it VDSC_PIPE_A since VDSC on Pipe A for eDP/DSI
> > > > will use this power well. But may be we should add a comment that
> > > > this is only for eDP/DSI on Pipe A since ICL does not support
> > > > VDSC on DP on Pipe A
> > > >
> > > > What do you think?
> > > >
> > > > Manasi
> > > >
> > > > >
> > > > > If we call it PIPE_A then it's going to a bit confusing when we
> > > > > use it with pipe B or C. Needs at least clear comments in the code
> > > > > why we're doing something that looks like nonsense of the first
> > > > > glance.
> > > > >
> > > > > --
> > > > > Ville Syrjälä
> > > > > Intel
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: simplify DMA mapping
Moving DMA mapping creation to drm_iommu_attach_device allows to avoid
looping through all components and maintaining DMA device flags.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 50 +++
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 13 +-
2 files changed, 17 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b599f74692e5..c83437d8a595 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -197,8 +197,7 @@ struct exynos_drm_driver_info {
#define DRM_COMPONENT_DRIVER BIT(0) /* supports component framework */
#define DRM_VIRTUAL_DEVICE BIT(1) /* create virtual platform device */
-#define DRM_DMA_DEVICE BIT(2) /* can be used for dma allocations */
-#define DRM_FIMC_DEVICEBIT(3) /* devices shared with V4L2
subsystem */
+#define DRM_FIMC_DEVICEBIT(2) /* devices shared with V4L2
subsystem */
#define DRV_PTR(drv, cond) (IS_ENABLED(cond) ? : NULL)
@@ -209,16 +208,16 @@ struct exynos_drm_driver_info {
static struct exynos_drm_driver_info exynos_drm_drivers[] = {
{
DRV_PTR(fimd_driver, CONFIG_DRM_EXYNOS_FIMD),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(exynos5433_decon_driver, CONFIG_DRM_EXYNOS5433_DECON),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(decon_driver, CONFIG_DRM_EXYNOS7_DECON),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(mixer_driver, CONFIG_DRM_EXYNOS_MIXER),
- DRM_COMPONENT_DRIVER | DRM_DMA_DEVICE
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
DRM_COMPONENT_DRIVER
@@ -289,27 +288,6 @@ static struct component_match *exynos_drm_match_add(struct
device *dev)
return match ?: ERR_PTR(-ENODEV);
}
-static struct device *exynos_drm_get_dma_device(void)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(exynos_drm_drivers); ++i) {
- struct exynos_drm_driver_info *info = _drm_drivers[i];
- struct device *dev;
-
- if (!info->driver || !(info->flags & DRM_DMA_DEVICE))
- continue;
-
- while ((dev = bus_find_device(_bus_type, NULL,
- >driver->driver,
- (void *)platform_bus_type.match))) {
- put_device(dev);
- return dev;
- }
- }
- return NULL;
-}
-
static int exynos_drm_bind(struct device *dev)
{
struct exynos_drm_private *private;
@@ -334,23 +312,6 @@ static int exynos_drm_bind(struct device *dev)
dev_set_drvdata(dev, drm);
drm->dev_private = (void *)private;
- /* the first real CRTC device is used for all dma mapping operations */
- private->dma_dev = exynos_drm_get_dma_device();
- if (!private->dma_dev) {
- DRM_ERROR("no device found for DMA mapping operations.\n");
- ret = -ENODEV;
- goto err_free_private;
- }
- DRM_INFO("Exynos DRM: using %s device for DMA mapping operations\n",
-dev_name(private->dma_dev));
-
- /* create common IOMMU mapping for all devices attached to Exynos DRM */
- ret = drm_create_iommu_mapping(drm);
- if (ret < 0) {
- DRM_ERROR("failed to create iommu mapping.\n");
- goto err_free_private;
- }
-
drm_mode_config_init(drm);
exynos_drm_mode_config_init(drm);
@@ -408,7 +369,6 @@ static int exynos_drm_bind(struct device *dev)
err_mode_config_cleanup:
drm_mode_config_cleanup(drm);
drm_release_iommu_mapping(drm);
-err_free_private:
kfree(private);
err_free_drm:
drm_dev_put(drm);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
index 0f373702414e..bb8b800a9fba 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
@@ -75,7 +75,18 @@ int drm_iommu_attach_device(struct drm_device *drm_dev,
struct exynos_drm_private *priv = drm_dev->dev_private;
int ret;
- if (get_dma_ops(priv->dma_dev) != get_dma_ops(subdrv_dev)) {
+ if (!priv->dma_dev) {
+ priv->dma_dev = subdrv_dev;
+ DRM_INFO("Exynos DRM: using %s device for DMA mapping
operations\n",
+dev_name(subdrv_dev));
+ /* create common IOMMU mapping for all Exynos DRM devices */
+ ret = drm_create_iommu_mapping(drm_dev);
+ if (ret < 0) {
+
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Leave intel_conn->mst_port set, use mst_port_gone instead
On Tue, Sep 18, 2018 at 07:06:19PM -0400, Lyude Paul wrote:
> Currently we set intel_connector->mst_port to NULL to signify that the
> MST port has been removed from the system so that we can prevent further
> action on the port such as connector probes, mode probing, etc.
> However, we're going to need access to intel_connector->mst_port in
> order to fixup ->best_encoder() so that it can always return the correct
> encoder for an MST port to prevent legacy DPMS prop changes from
> failing. This should be safe, so instead keep intel_connector->mst_port
> always set and instead add intel_connector->mst_port_gone in order to
> signify whether or not the connector has disappeared from the system.
>
> Signed-off-by: Lyude Paul
> Cc: sta...@vger.kernel.org
Hm, how exactly do legacy DPMS setprop blow up here? Or at least I can't
come up with a scenario that's specific to legacy props, atomic should be
equally affected. By the time we land in this code, the core code already
remapping it to be purely an atomic update.
Another thought: Should we handle at least some of this in the probe
helpers? I.e. once you unplugged a drm_connector, it always shows
disconnected and mode list is gone, instead of duplicating this over all
drivers. We could just check connector->registered.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/intel_dp_mst.c | 14 +++---
> drivers/gpu/drm/i915/intel_drv.h| 1 +
> 2 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 4ecd65375603..fcb9b87b9339 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -311,9 +311,8 @@ static int intel_dp_mst_get_ddc_modes(struct
> drm_connector *connector)
> struct edid *edid;
> int ret;
>
> - if (!intel_dp) {
> + if (intel_connector->mst_port_gone)
> return intel_connector_update_modes(connector, NULL);
> - }
>
> edid = drm_dp_mst_get_edid(connector, _dp->mst_mgr,
> intel_connector->port);
> ret = intel_connector_update_modes(connector, edid);
> @@ -328,9 +327,10 @@ intel_dp_mst_detect(struct drm_connector *connector,
> bool force)
> struct intel_connector *intel_connector = to_intel_connector(connector);
> struct intel_dp *intel_dp = intel_connector->mst_port;
>
> - if (!intel_dp)
> + if (intel_connector->mst_port_gone)
> return connector_status_disconnected;
> - return drm_dp_mst_detect_port(connector, _dp->mst_mgr,
> intel_connector->port);
> + return drm_dp_mst_detect_port(connector, _dp->mst_mgr,
> + intel_connector->port);
> }
>
> static void
> @@ -370,7 +370,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
> int bpp = 24; /* MST uses fixed bpp */
> int max_rate, mode_rate, max_lanes, max_link_clock;
>
> - if (!intel_dp)
> + if (intel_connector->mst_port_gone)
> return MODE_ERROR;
>
> if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> @@ -402,7 +402,7 @@ static struct drm_encoder
> *intel_mst_atomic_best_encoder(struct drm_connector *c
> struct intel_dp *intel_dp = intel_connector->mst_port;
> struct intel_crtc *crtc = to_intel_crtc(state->crtc);
>
> - if (!intel_dp)
> + if (intel_connector->mst_port_gone)
> return NULL;
> return _dp->mst_encoders[crtc->pipe]->base.base;
> }
> @@ -514,7 +514,7 @@ static void intel_dp_destroy_mst_connector(struct
> drm_dp_mst_topology_mgr *mgr,
> connector);
> /* prevent race with the check in ->detect */
> drm_modeset_lock(>dev->mode_config.connection_mutex, NULL);
> - intel_connector->mst_port = NULL;
> + intel_connector->mst_port_gone = true;
> drm_modeset_unlock(>dev->mode_config.connection_mutex);
>
> drm_connector_put(connector);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 8fc61e96754f..87ce772ae7f8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -409,6 +409,7 @@ struct intel_connector {
> void *port; /* store this opaque as its illegal to dereference it */
>
> struct intel_dp *mst_port;
> + bool mst_port_gone;
>
> /* Work struct to schedule a uevent on link train failure */
> struct work_struct modeset_retry_work;
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/18] drm/i915: Pass intel_encoder to infoframe functions
On Fri, Sep 21, 2018 at 03:59:06PM +0200, Daniel Vetter wrote:
> On Thu, Sep 20, 2018 at 09:51:36PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make life simpler by passing around intel_encoder instead of
> > drm_encoder.
> >
> > @r1@
> > identifier F =~ "infoframe";
> > identifier I, M;
> > @@
> > F(
> > - struct drm_encoder *I
> > + struct intel_encoder *I
> > , ...)
> > {
> > <...
> > (
> > - I->M
> > + I->base.M
> > |
> > - I
> > + >base
> > )
> > ...>
> > }
> >
> > @r2@
> > identifier F =~ "infoframe";
> > identifier I;
> > type T, ST;
> > @@
> > ST {
> > ...
> > T (*F)(
> > - struct drm_encoder *I
> > + struct intel_encoder *encoder
> >, ...);
> > ...
> > };
> >
> > @@
> > identifier r1.F;
> > expression E;
> > @@
> > F(
> > - E
> > + to_intel_encoder(E)
> > ,...)
> >
> > @@
> > identifier r2.F;
> > expression E, X;
> > @@
> > (
> > X.F(
> > - E
> > + to_intel_encoder(E)
> > ,...)
> > |
> > X->F(
> > -E
> > +to_intel_encoder(E)
> > ,...)
> > )
> >
> > @@
> > expression E;
> > @@
> > (
> > - to_intel_encoder(>base)
> > + E
> > |
> > - to_intel_encoder(>base.base)
> > + >base
> > )
> >
> > @@
> > identifier D, M;
> > expression E;
> > @@
> > D = enc_to_dig_port(>base)
> > <...
> > (
> > - D->base.M
> > + E->M
> > |
> > - >base
> > + E
> > )
> > ...>
> >
> > @@
> > identifier D;
> > expression E;
> > type T;
> > @@
> > - T D = enc_to_dig_port(E);
> > ... when != D
>
> Someone knows a lot more cocci than I do, impressive. How do you figure
> this stuff out? Read the source?
A combination of reading the docs, looking at other cocci scripts,
cursing, and lost hair. And every time I repeat the process
because I've forgotten what I learned last time around.
>
> Also seems to have some manual fixups below, so I just looked at the diff.
> That looks fine.
I might have accidentally tweaked things when I rebased this. Should
have re-run the cocci script actually. Would be nice if git rebase
did that for you automagically.
I just re-ran spatch and that highlighted five occurances of the
following manual change I had made "accidentally" while rebasing:
++<<< HEAD
+ struct drm_device *dev = encoder->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
++===
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
++>>> 8cdf27dd7e50... drm/i915: Pass intel_encoder to infoframe functions
Nothing else had been tweaked apparently.
>
> Acked-by: Daniel Vetter
Thanks.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107607] Problems with MST display (REG_WAIT takes a while or times out)
https://bugs.freedesktop.org/show_bug.cgi?id=107607 --- Comment #4 from Paul Menzel --- (In reply to Jerry Zuo from comment #3) > Hi Paul, can you please explain what you did by "when switching the inputs > of the monitor (two systems are connected)"? The monitor has several inputs. Over the OSD (on-screen display) you can tell the monitor what input signal it should display (or the monitor auto-senses it itself). Hopefully, that makes sense. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/18] video/hdmi: Handle the MPEG Source infoframe
From: Ville Syrjälä
Add the code to deal with the MPEG source infoframe.
Blindly typed from the spec, and totally untested.
v2: Rebase
Cc: Thierry Reding
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c | 229 +++
include/linux/hdmi.h | 27 ++
2 files changed, 256 insertions(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 08d94ab00467..6f39b9ae56b9 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -706,6 +706,131 @@ hdmi_vendor_any_infoframe_pack(union
hdmi_vendor_any_infoframe *frame,
return hdmi_vendor_any_infoframe_pack_only(frame, buffer, size);
}
+/**
+ * hdmi_mpeg_source_infoframe_init() - initialize an HDMI MPEG Source infoframe
+ * @frame: HDMI MPEG Source infoframe
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_mpeg_source_infoframe_init(struct hdmi_mpeg_source_infoframe *frame)
+{
+ memset(frame, 0, sizeof(*frame));
+
+ frame->type = HDMI_INFOFRAME_TYPE_MPEG_SOURCE;
+ frame->version = 1;
+ frame->length = HDMI_MPEG_SOURCE_INFOFRAME_SIZE;
+
+ return 0;
+}
+EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_init);
+
+static int hdmi_mpeg_source_infoframe_check_only(const struct
hdmi_mpeg_source_infoframe *frame)
+{
+ if (frame->type != HDMI_INFOFRAME_TYPE_MPEG_SOURCE ||
+ frame->version != 1 ||
+ frame->length != HDMI_MPEG_SOURCE_INFOFRAME_SIZE)
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
+ * hdmi_mpeg_source_infoframe_check() - check a HDMI MPEG Source infoframe
+ * @frame: HDMI MPEG Source infoframe
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_mpeg_source_infoframe_check(struct hdmi_mpeg_source_infoframe *frame)
+{
+ return hdmi_mpeg_source_infoframe_check_only(frame);
+}
+EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_check);
+
+/**
+ * hdmi_mpeg_source_infoframe_pack_only() - write HDMI MPEG Source infoframe
to binary buffer
+ * @frame: HDMI MPEG Source infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Packs the information contained in the @frame structure into a binary
+ * representation that can be written into the corresponding controller
+ * registers. Also computes the checksum as required by section 5.3.5 of
+ * the HDMI 1.4 specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_mpeg_source_infoframe_pack_only(const struct
hdmi_mpeg_source_infoframe *frame,
+void *buffer, size_t size)
+{
+ u8 *ptr = buffer;
+ size_t length;
+ int ret;
+
+ ret = hdmi_mpeg_source_infoframe_check_only(frame);
+ if (ret)
+ return ret;
+
+ length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(buffer, 0, size);
+
+ ptr[0] = frame->type;
+ ptr[1] = frame->version;
+ ptr[2] = frame->length;
+ ptr[3] = 0; /* checksum */
+
+ /* start infoframe payload */
+ ptr += HDMI_INFOFRAME_HEADER_SIZE;
+
+ ptr[0] = frame->mpeg_bit_rate >> 0;
+ ptr[1] = frame->mpeg_bit_rate >> 8;
+ ptr[2] = frame->mpeg_bit_rate >> 16;
+ ptr[3] = frame->mpeg_bit_rate >> 24;
+ ptr[4] = (frame->field_repeat << 4) | frame->mpeg_frame;
+
+ hdmi_infoframe_set_checksum(buffer, length);
+
+ return length;
+}
+EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack_only);
+
+/**
+ * hdmi_mpeg_source_infoframe_pack() - check a HDMI MPEG Source infoframe,
+ * and write it to binary buffer
+ * @frame: HDMI MPEG Source infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields, after which packs the information
+ * contained in the @frame structure into a binary representation that
+ * can be written into the corresponding controller registers. This function
+ * also computes the checksum as required by section 5.3.5 of the HDMI 1.4
+ * specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_mpeg_source_infoframe_pack(struct hdmi_mpeg_source_infoframe
*frame,
+ void *buffer, size_t size)
+{
+ int ret;
+
+ ret = hdmi_mpeg_source_infoframe_check(frame);
+ if (ret)
+ return ret;
+
+ return hdmi_mpeg_source_infoframe_pack_only(frame, buffer, size);
+}
+EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack);
+
/**
* hdmi_infoframe_check() - check a HDMI infoframe
* @frame: HDMI infoframe
@@
Re: [PATCH v7 2/2] dt-bindings: Add Truly NT35597 panel driver bindings
On Wed, Sep 19, 2018 at 7:55 PM Abhinav Kumar wrote: > From: "abhin...@codeaurora.org" > > Add the device tree bindings for Truly NT35597 panel driver. > This panel driver supports both single DSI and dual DSI. > > However, this patch series supports only dual DSI. > > Changes in v7: > - Change the compatible string to indicate only the > panel driver string and the resolution > - Indicate reset GPIO is ACTIVE_LOW This works for me. Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] meson: honor -Detnaviv=auto
We support that value so it should work as expected. This does not make
'auto' the default since the API is still marked as experimental.
---
meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 75c7bdff..8001a9cc 100644
--- a/meson.build
+++ b/meson.build
@@ -142,11 +142,11 @@ endif
with_etnaviv = false
_etnaviv = get_option('etnaviv')
-if _etnaviv == 'true'
+if _etnaviv != 'false'
if not with_atomics
error('libdrm_etnaviv requires atomics.')
endif
- with_etnaviv = true
+ with_etnaviv = _etnaviv == 'true' or ['arm',
'aarch64'].contains(host_machine.cpu_family())
endif
with_exynos = get_option('exynos') == 'true'
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/arm/malidp: Validate rotations for compressed/uncompressed framebuffers for each layer
From: Ayan Kumar Halder
Add support for compressed framebuffers that are described using
the framebuffer's modifier field. Mali DP uses the rotation memory for
the decompressor of the format, so we need to check for space when
the modifiers are present.
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Brian Starkey
[re-worded commit, rebased, cleaned up duplicated checks for
RGB888 and BGR888 and removed additional parameter for
rotmem_required function hook]
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 28 -
drivers/gpu/drm/arm/malidp_hw.c | 38 -
drivers/gpu/drm/arm/malidp_hw.h | 7 ++
drivers/gpu/drm/arm/malidp_planes.c | 19 +++
4 files changed, 53 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index ef44202fb43f8..e1b72782848c3 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -348,19 +348,20 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
/*
* check if there is enough rotation memory available for planes
-* that need 90° and 270° rotation. Each plane has set its required
-* memory size in the ->plane_check() callback, here we only make
-* sure that the sums are less that the total usable memory.
+* that need 90° and 270° rotion or planes that are compressed.
+* Each plane has set its required memory size in the ->plane_check()
+* callback, here we only make sure that the sums are less that the
+* total usable memory.
*
* The rotation memory allocation algorithm (for each plane):
-* a. If no more rotated planes exist, all remaining rotate
-* memory in the bank is available for use by the plane.
-* b. If other rotated planes exist, and plane's layer ID is
-* DE_VIDEO1, it can use all the memory from first bank if
-* secondary rotation memory bank is available, otherwise it can
+* a. If no more rotated or compressed planes exist, all remaining
+* rotate memory in the bank is available for use by the plane.
+* b. If other rotated or compressed planes exist, and plane's
+* layer ID is DE_VIDEO1, it can use all the memory from first bank
+* if secondary rotation memory bank is available, otherwise it can
* use up to half the bank's memory.
-* c. If other rotated planes exist, and plane's layer ID is not
-* DE_VIDEO1, it can use half of the available memory
+* c. If other rotated or compressed planes exist, and plane's layer ID
+* is not DE_VIDEO1, it can use half of the available memory.
*
* Note: this algorithm assumes that the order in which the planes are
* checked always has DE_VIDEO1 plane first in the list if it is
@@ -372,7 +373,9 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
/* first count the number of rotated planes */
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
- if (pstate->rotation & MALIDP_ROTATED_MASK)
+ struct drm_framebuffer *fb = pstate->fb;
+
+ if ((pstate->rotation & MALIDP_ROTATED_MASK) || fb->modifier)
rotated_planes++;
}
@@ -388,8 +391,9 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
struct malidp_plane *mp = to_malidp_plane(plane);
struct malidp_plane_state *ms = to_malidp_plane_state(pstate);
+ struct drm_framebuffer *fb = pstate->fb;
- if (pstate->rotation & MALIDP_ROTATED_MASK) {
+ if ((pstate->rotation & MALIDP_ROTATED_MASK) || fb->modifier) {
/* process current plane */
rotated_planes--;
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index b33000634a4ee..5549092e6c36a 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -85,41 +85,43 @@ static const struct malidp_format_id malidp550_de_formats[]
= {
static const struct malidp_layer malidp500_layers[] = {
/* id, base address, fb pointer address base, stride offset,
- yuv2rgb matrix offset, mmu control register offset */
+ yuv2rgb matrix offset, mmu control register offset,
rotation_features */
{ DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0 },
+ MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY },
{ DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0 },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
{
Re: [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types
On Fri, Sep 21, 2018 at 04:12:36PM +0200, Hans Verkuil wrote:
> On 09/21/18 16:01, Ville Syrjälä wrote:
> > On Fri, Sep 21, 2018 at 10:41:46AM +0200, Hans Verkuil wrote:
> >> On 09/20/18 20:51, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> We'll be wanting to send more than just infoframes over HDMI. So add an
> >>> enum for other packet types.
> >>>
> >>> TODO: Maybe just include the infoframe types in the packet type enum
> >>> and get rid of the infoframe type enum?
> >>
> >> I think that's better, IMHO. With a comment that the types starting with
> >> 0x81 are defined in CTA-861-G.
> >>
> >> It's really the same byte that is being checked, so having two enums is
> >> a bit misleading. The main difference is really which standard defines
> >> the packet types.
> >
> > Right. The only slight annoyance is that we'll get a bunch of warnings
> > from the compiler if we don't handle all the enum valus in the switch
> > statements. If we want to avoid that I guess I could limit this
> > to just the null, gcp and gamut metadata packets initially and try to
> > write some actual code for them. Those three are the only ones we
> > care about in i915 at the moment.
>
> Note that I don't have a terribly strong opinion on this, so if using
> one enum instead of two causes more problems than it is worth, then
> that's fine with me as well.
>
> But you asked, and given a choice with all other things being equal,
> then one enum has my preference.
I do agree that it would seem nicer.
But I'm a bit busy with other things at the moment so I might want
to leave it like this for now and revisit the topic in the
hopefully-not-too-distant future.
>
> Regards,
>
> Hans
>
> >
> >>
> >> Regards,
> >>
> >>Hans
> >>
> >>>
> >>> Cc: Thierry Reding
> >>> Cc: Hans Verkuil
> >>> Cc: linux-me...@vger.kernel.org
> >>> Signed-off-by: Ville Syrjälä
> >>> ---
> >>> include/linux/hdmi.h | 15 +++
> >>> 1 file changed, 15 insertions(+)
> >>>
> >>> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> >>> index c76b50a48e48..80521d9591a1 100644
> >>> --- a/include/linux/hdmi.h
> >>> +++ b/include/linux/hdmi.h
> >>> @@ -27,6 +27,21 @@
> >>> #include
> >>> #include
> >>>
> >>> +enum hdmi_packet_type {
> >>> + HDMI_PACKET_TYPE_NULL = 0x00,
> >>> + HDMI_PACKET_TYPE_AUDIO_CLOCK_REGEN = 0x01,
> >>> + HDMI_PACKET_TYPE_AUDIO_SAMPLE = 0x02,
> >>> + HDMI_PACKET_TYPE_GENERAL_CONTROL = 0x03,
> >>> + HDMI_PACKET_TYPE_AUDIO_CP = 0x04,
> >>> + HDMI_PACKET_TYPE_ISRC1 = 0x05,
> >>> + HDMI_PACKET_TYPE_ISRC2 = 0x06,
> >>> + HDMI_PACKET_TYPE_ONE_BIT_AUDIO_SAMPLE = 0x07,
> >>> + HDMI_PACKET_TYPE_DST_AUDIO = 0x08,
> >>> + HDMI_PACKET_TYPE_HBR_AUDIO_STREAM = 0x09,
> >>> + HDMI_PACKET_TYPE_GAMUT_METADATA = 0x0a,
> >>> + /* + enum hdmi_infoframe_type */
> >>> +};
> >>> +
> >>> enum hdmi_infoframe_type {
> >>> HDMI_INFOFRAME_TYPE_VENDOR = 0x81,
> >>> HDMI_INFOFRAME_TYPE_AVI = 0x82,
> >>>
> >
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/18] video/hdmi: Handle the NTSC VBI infoframe
From: Ville Syrjälä
Add the code to deal with the NTSC VBI infoframe.
I decided against parsing the PES_data_field and just leave
it as an opaque blob, just dumping it out as hex in the log.
Blindly typed from the spec, and totally untested.
v2: Rebase
Cc: Thierry Reding
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c | 208 +++
include/linux/hdmi.h | 18 +
2 files changed, 226 insertions(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 6f39b9ae56b9..b14202fc5854 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -831,6 +831,139 @@ ssize_t hdmi_mpeg_source_infoframe_pack(struct
hdmi_mpeg_source_infoframe *frame
}
EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack);
+/**
+ * hdmi_ntsc_vbi_infoframe_init() - initialize an HDMI NTSC VBI infoframe
+ * @frame: HDMI NTSC VBI infoframe
+ * @pes_data_field: ANSI/SCTE 127 PES_data_field
+ * @length: ANSI/SCTE 127 PES_data_field length
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_ntsc_vbi_infoframe_init(struct hdmi_ntsc_vbi_infoframe *frame,
+const void *pes_data_field,
+size_t length)
+{
+ if (length < 1 || length > 27)
+ return -EINVAL;
+
+ memset(frame, 0, sizeof(*frame));
+
+ frame->type = HDMI_INFOFRAME_TYPE_NTSC_VBI;
+ frame->version = 1;
+ frame->length = length;
+
+ memcpy(frame->pes_data_field, pes_data_field, length);
+
+ return 0;
+}
+EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_init);
+
+static int hdmi_ntsc_vbi_infoframe_check_only(const struct
hdmi_ntsc_vbi_infoframe *frame)
+{
+ if (frame->type != HDMI_INFOFRAME_TYPE_NTSC_VBI ||
+ frame->version != 1 ||
+ frame->length < 1 || frame->length > 27)
+ return -EINVAL;
+
+ if (frame->pes_data_field[0] != 0x99)
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
+ * hdmi_ntsc_vbi_infoframe_check() - Check and check a HDMI NTSC VBI infoframe
+ * @frame: HDMI NTSC VBI infoframe
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_ntsc_vbi_infoframe_check(struct hdmi_ntsc_vbi_infoframe *frame)
+{
+ return hdmi_ntsc_vbi_infoframe_check_only(frame);
+}
+EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_check);
+
+/**
+ * hdmi_ntsc_vbi_infoframe_pack_only() - write HDMI NTSC VBI infoframe to
binary buffer
+ * @frame: HDMI NTSC VBI infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Packs the information contained in the @frame structure into a binary
+ * representation that can be written into the corresponding controller
+ * registers. Also computes the checksum as required by section 5.3.5 of
+ * the HDMI 1.4 specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_ntsc_vbi_infoframe_pack_only(const struct hdmi_ntsc_vbi_infoframe
*frame,
+ void *buffer, size_t size)
+{
+ u8 *ptr = buffer;
+ size_t length;
+ int ret;
+
+ ret = hdmi_ntsc_vbi_infoframe_check_only(frame);
+ if (ret)
+ return ret;
+
+ length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(buffer, 0, size);
+
+ ptr[0] = frame->type;
+ ptr[1] = frame->version;
+ ptr[2] = frame->length;
+ ptr[3] = 0; /* checksum */
+
+ /* start infoframe payload */
+ ptr += HDMI_INFOFRAME_HEADER_SIZE;
+
+ memcpy(ptr, frame->pes_data_field, frame->length);
+
+ hdmi_infoframe_set_checksum(buffer, length);
+
+ return length;
+}
+EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_pack_only);
+
+/**
+ * hdmi_ntsc_vbi_infoframe_pack() - check a HDMI NTSC VBI infoframe,
+ * and write it to binary buffer
+ * @frame: HDMI NTSC VBI infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields, after which packs the information
+ * contained in the @frame structure into a binary representation that
+ * can be written into the corresponding controller registers. This function
+ * also computes the checksum as required by section 5.3.5 of the HDMI 1.4
+ * specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_ntsc_vbi_infoframe_pack(struct hdmi_ntsc_vbi_infoframe *frame,
+void *buffer, size_t size)
+{
+ int ret;
+
+ ret = hdmi_ntsc_vbi_infoframe_check(frame);
+ if (ret)
+ return
Re: [PATCH 06/18] video/hdmi: Handle the MPEG Source infoframe
On Fri, Sep 21, 2018 at 10:28:09AM +0200, Hans Verkuil wrote:
> On 09/20/18 20:51, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add the code to deal with the MPEG source infoframe.
> >
> > Blindly typed from the spec, and totally untested.
>
> I'm not sure this patch should be added at all. The CTA-861-G spec (section
> 6.7)
> says that the implementation of this infoframe is not recommended due to
> unresolved
> issues.
>
> I don't think I've ever seen it either.
>
> It obviously doesn't hurt to have this code, but I prefer to wait until there
> are devices that actively set/use this infoframe.
Sure. I'm totally fine with leaving it out. Just figured I'd send it out
in case anyone has some use for it.
>
> Regards,
>
> Hans
>
> >
> > Cc: Thierry Reding
> > Cc: Hans Verkuil
> > Cc: linux-me...@vger.kernel.org
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/video/hdmi.c | 229
> > +++
> > include/linux/hdmi.h | 27 ++
> > 2 files changed, 256 insertions(+)
> >
> > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > index 9507f668a569..3d24c7746c51 100644
> > --- a/drivers/video/hdmi.c
> > +++ b/drivers/video/hdmi.c
> > @@ -706,6 +706,131 @@ hdmi_vendor_any_infoframe_pack(union
> > hdmi_vendor_any_infoframe *frame,
> > return hdmi_vendor_any_infoframe_pack_only(frame, buffer, size);
> > }
> >
> > +/**
> > + * hdmi_mpeg_source_infoframe_init() - initialize an HDMI MPEG Source
> > infoframe
> > + * @frame: HDMI MPEG Source infoframe
> > + *
> > + * Returns 0 on success or a negative error code on failure.
> > + */
> > +int hdmi_mpeg_source_infoframe_init(struct hdmi_mpeg_source_infoframe
> > *frame)
> > +{
> > + memset(frame, 0, sizeof(*frame));
> > +
> > + frame->type = HDMI_INFOFRAME_TYPE_MPEG_SOURCE;
> > + frame->version = 1;
> > + frame->length = HDMI_MPEG_SOURCE_INFOFRAME_SIZE;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_init);
> > +
> > +static int hdmi_mpeg_source_infoframe_check_only(const struct
> > hdmi_mpeg_source_infoframe *frame)
> > +{
> > + if (frame->type != HDMI_INFOFRAME_TYPE_MPEG_SOURCE ||
> > + frame->version != 1 ||
> > + frame->length != HDMI_MPEG_SOURCE_INFOFRAME_SIZE)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * hdmi_mpeg_source_infoframe_check() - Check and check a HDMI MPEG Source
> > infoframe
> > + * @frame: HDMI MPEG Source infoframe
> > + *
> > + * Validates that the infoframe is consistent and updates derived fields
> > + * (eg. length) based on other fields.
> > + *
> > + * Returns 0 on success or a negative error code on failure.
> > + */
> > +int hdmi_mpeg_source_infoframe_check(struct hdmi_mpeg_source_infoframe
> > *frame)
> > +{
> > + return hdmi_mpeg_source_infoframe_check_only(frame);
> > +}
> > +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_check);
> > +
> > +/**
> > + * hdmi_mpeg_source_infoframe_pack_only() - write HDMI MPEG Source
> > infoframe to binary buffer
> > + * @frame: HDMI MPEG Source infoframe
> > + * @buffer: destination buffer
> > + * @size: size of buffer
> > + *
> > + * Packs the information contained in the @frame structure into a binary
> > + * representation that can be written into the corresponding controller
> > + * registers. Also computes the checksum as required by section 5.3.5 of
> > + * the HDMI 1.4 specification.
> > + *
> > + * Returns the number of bytes packed into the binary buffer or a negative
> > + * error code on failure.
> > + */
> > +ssize_t hdmi_mpeg_source_infoframe_pack_only(const struct
> > hdmi_mpeg_source_infoframe *frame,
> > +void *buffer, size_t size)
> > +{
> > + u8 *ptr = buffer;
> > + size_t length;
> > + int ret;
> > +
> > + ret = hdmi_mpeg_source_infoframe_check_only(frame);
> > + if (ret)
> > + return ret;
> > +
> > + length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> > +
> > + if (size < length)
> > + return -ENOSPC;
> > +
> > + memset(buffer, 0, size);
> > +
> > + ptr[0] = frame->type;
> > + ptr[1] = frame->version;
> > + ptr[2] = frame->length;
> > + ptr[3] = 0; /* checksum */
> > +
> > + /* start infoframe payload */
> > + ptr += HDMI_INFOFRAME_HEADER_SIZE;
> > +
> > + ptr[0] = frame->mpeg_bit_rate >> 0;
> > + ptr[1] = frame->mpeg_bit_rate >> 8;
> > + ptr[2] = frame->mpeg_bit_rate >> 16;
> > + ptr[3] = frame->mpeg_bit_rate >> 24;
> > + ptr[4] = (frame->field_repeat << 4) | frame->mpeg_frame;
> > +
> > + hdmi_infoframe_set_checksum(buffer, length);
> > +
> > + return length;
> > +}
> > +EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack_only);
> > +
> > +/**
> > + * hdmi_mpeg_source_infoframe_pack() - Check and check a HDMI MPEG Source
> > infoframe,
> > + * and write it to binary buffer
> > + * @frame: HDMI MPEG Source infoframe
> > + * @buffer: destination buffer
> > + *
Re: [Intel-gfx] [PATCH 08/18] drm/i915: Use memmove() for punching the hole into infoframes
On Thu, Sep 20, 2018 at 09:51:35PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Replace the hand rolled memmove() with the real thing. > > Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_hdmi.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index a2dab0b6bde6..3b56ab253171 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -457,9 +457,7 @@ static void intel_write_infoframe(struct drm_encoder > *encoder, > return; > > /* Insert the 'hole' (see big comment above) at position 3 */ > - buffer[0] = buffer[1]; > - buffer[1] = buffer[2]; > - buffer[2] = buffer[3]; > + memmove([0], [1], 3); > buffer[3] = 0; > len++; > > -- > 2.16.4 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types
On Fri, Sep 21, 2018 at 10:41:46AM +0200, Hans Verkuil wrote:
> On 09/20/18 20:51, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We'll be wanting to send more than just infoframes over HDMI. So add an
> > enum for other packet types.
> >
> > TODO: Maybe just include the infoframe types in the packet type enum
> > and get rid of the infoframe type enum?
>
> I think that's better, IMHO. With a comment that the types starting with
> 0x81 are defined in CTA-861-G.
>
> It's really the same byte that is being checked, so having two enums is
> a bit misleading. The main difference is really which standard defines
> the packet types.
Right. The only slight annoyance is that we'll get a bunch of warnings
from the compiler if we don't handle all the enum valus in the switch
statements. If we want to avoid that I guess I could limit this
to just the null, gcp and gamut metadata packets initially and try to
write some actual code for them. Those three are the only ones we
care about in i915 at the moment.
>
> Regards,
>
> Hans
>
> >
> > Cc: Thierry Reding
> > Cc: Hans Verkuil
> > Cc: linux-me...@vger.kernel.org
> > Signed-off-by: Ville Syrjälä
> > ---
> > include/linux/hdmi.h | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> > index c76b50a48e48..80521d9591a1 100644
> > --- a/include/linux/hdmi.h
> > +++ b/include/linux/hdmi.h
> > @@ -27,6 +27,21 @@
> > #include
> > #include
> >
> > +enum hdmi_packet_type {
> > + HDMI_PACKET_TYPE_NULL = 0x00,
> > + HDMI_PACKET_TYPE_AUDIO_CLOCK_REGEN = 0x01,
> > + HDMI_PACKET_TYPE_AUDIO_SAMPLE = 0x02,
> > + HDMI_PACKET_TYPE_GENERAL_CONTROL = 0x03,
> > + HDMI_PACKET_TYPE_AUDIO_CP = 0x04,
> > + HDMI_PACKET_TYPE_ISRC1 = 0x05,
> > + HDMI_PACKET_TYPE_ISRC2 = 0x06,
> > + HDMI_PACKET_TYPE_ONE_BIT_AUDIO_SAMPLE = 0x07,
> > + HDMI_PACKET_TYPE_DST_AUDIO = 0x08,
> > + HDMI_PACKET_TYPE_HBR_AUDIO_STREAM = 0x09,
> > + HDMI_PACKET_TYPE_GAMUT_METADATA = 0x0a,
> > + /* + enum hdmi_infoframe_type */
> > +};
> > +
> > enum hdmi_infoframe_type {
> > HDMI_INFOFRAME_TYPE_VENDOR = 0x81,
> > HDMI_INFOFRAME_TYPE_AVI = 0x82,
> >
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 5/5] drm: bridge: add support for Cadence MHDP DPI/DP bridge
On Thu, Sep 20, 2018 at 03:54:40PM +0100, Damian Kos wrote:
> From: Quentin Schulz
>
> This adds basic support for Cadence MHDP DPI to DP bridge.
>
> Basically, it takes a DPI stream as input and output it encoded in DP
> format. It's missing proper HPD, HDCP and currently supports only
> SST mode.
>
> Changes made in the low level driver (cdn-dp-reg.*):
> - moved it to from drivers/gpu/drm/rockchip to
> drivers/gpu/drm/bridge/cdns-mhdp-common.*
> - functions for sending/receiving commands are now public
> - added functions for reading registers and link training
> adjustment
>
> Changes made in RK's driver (cdn-dp-core.*):
> - Moved audio_info and audio_pdev fields from cdn_dp_device to
> cdns_mhdp_device structure.
>
> Signed-off-by: Quentin Schulz
> Signed-off-by: Damian Kos
> ---
> drivers/gpu/drm/bridge/Kconfig|9 +
> drivers/gpu/drm/bridge/Makefile |3 +
> .../cdns-mhdp-common.c} | 137 +-
> .../cdns-mhdp-common.h} | 21 +-
> drivers/gpu/drm/bridge/cdns-mhdp.c| 1308 +
> drivers/gpu/drm/rockchip/Kconfig |4 +-
> drivers/gpu/drm/rockchip/Makefile |4 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c| 16 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.h|4 +-
> 9 files changed, 1486 insertions(+), 20 deletions(-)
> rename drivers/gpu/drm/{rockchip/cdn-dp-reg.c => bridge/cdns-mhdp-common.c}
> (87%)
> rename drivers/gpu/drm/{rockchip/cdn-dp-reg.h => bridge/cdns-mhdp-common.h}
> (95%)
> create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 9eeb8ef0b174..90a4810a8c96 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -35,6 +35,15 @@ config DRM_CDNS_DSI
> Support Cadence DPI to DSI bridge. This is an internal
> bridge and is meant to be directly embedded in a SoC.
>
> +config DRM_CDNS_MHDP
> + tristate "Cadence DPI/DP bridge"
> + select DRM_KMS_HELPER
> + select DRM_PANEL_BRIDGE
> + depends on OF
> + help
> + Support Cadence DPI to DP bridge. This is an internal
> + bridge and is meant to be directly embedded in a SoC.
> +
> config DRM_DUMB_VGA_DAC
> tristate "Dumb VGA DAC Bridge support"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf5a6f8..e802fdb85750 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -16,4 +16,7 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> +obj-$(CONFIG_DRM_CDNS_MHDP) += mhdp8546.o
> obj-y += synopsys/
> +
> +mhdp8546-objs := cdns-mhdp-common.o cdns-mhdp.o
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
> similarity index 87%
> rename from drivers/gpu/drm/rockchip/cdn-dp-reg.c
> rename to drivers/gpu/drm/bridge/cdns-mhdp-common.c
> index c1a76e6fff88..88cb248b9de4 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> +++ b/drivers/gpu/drm/bridge/cdns-mhdp-common.c
> @@ -19,8 +19,10 @@
> #include
> #include
>
> -#include "cdn-dp-core.h"
> -#include "cdn-dp-reg.h"
> +#include
> +#include
> +
> +#include "cdns-mhdp-common.h"
>
> #define CDNS_DP_SPDIF_CLK2
> #define FW_ALIVE_TIMEOUT_US 100
> @@ -33,6 +35,7 @@ void cdns_mhdp_set_fw_clk(struct cdns_mhdp_device *mhdp,
> unsigned long clk)
> {
> writel(clk / 100, mhdp->regs + SW_CLK_H);
> }
> +EXPORT_SYMBOL(cdns_mhdp_set_fw_clk);
>
> void cdns_mhdp_clock_reset(struct cdns_mhdp_device *mhdp)
> {
> @@ -82,6 +85,7 @@ void cdns_mhdp_clock_reset(struct cdns_mhdp_device *mhdp)
> /* enable Mailbox and PIF interrupt */
> writel(0, mhdp->regs + APB_INT_MASK);
> }
> +EXPORT_SYMBOL(cdns_mhdp_clock_reset);
>
> static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
> {
> @@ -189,7 +193,56 @@ static int cdns_mhdp_mailbox_send(struct
> cdns_mhdp_device *mhdp, u8 module_id,
> return 0;
> }
>
> -static int cdns_mhdp_reg_write(struct cdns_mhdp_device *mhdp, u16 addr, u32
> val)
> +int cdns_mhdp_reg_read(struct cdns_mhdp_device *mhdp, u32 addr, u32 *value)
> +{
> + u8 msg[4], resp[8];
> + int ret;
> +
> + if (addr == 0) {
> + ret = -EINVAL;
> + goto err_reg_read;
> + }
> +
> + msg[0] = (u8)(addr >> 24);
> + msg[1] = (u8)(addr >> 16);
> + msg[2] = (u8)(addr >> 8);
> + msg[3] = (u8)addr;
> +
> + ret = cdns_mhdp_mailbox_send(mhdp, MB_MODULE_ID_GENERAL,
> + GENERAL_REGISTER_READ,
> + sizeof(msg), msg);
> + if (ret)
> + goto err_reg_read;
> +
> + ret =
Re: [PATCH] drm/fb_helper: Allow leaking fbdev smem_start
Hi, On Thu, Sep 20, 2018 at 03:04:12PM +0200, Neil Armstrong wrote: > Since "drm/fb: Stop leaking physical address", the default behaviour of > the DRM fbdev emulation is to set the smem_base to 0 and pass the new > FBINFO_HIDE_SMEM_START flag. > > The main reason is to avoid leaking physical addresse to user-space, and > it follows a general move over the kernel code to avoid user-space to > manipulate physical addresses and then use some other mechanisms like > dma-buf to transfer physical buffer handles over multiple subsystems. > > But, a lot of devices depends on closed sources binaries to enable > OpenGL hardware acceleration that uses this smem_start value to > pass physical addresses to out-of-tree modules in order to render > into these physical adresses. These should use dma-buf buffers allocated > from the DRM display device instead and stop relying on fbdev overallocation > to gather DMA memory (some HW vendors delivers GBM and Wayland capable > binaries, but older unsupported devices won't have these new binaries > and are doomed until an Open Source solution like Lima finalizes). > > Since these devices heavily depends on this kind of software and because > the smem_start population was available for years, it's a breakage to > stop leaking smem_start without any alternative solutions. > > This patch adds a Kconfig depending on the EXPERT config and an unsafe > kernel module parameter tainting the kernel when enabled. > > A clear comment and Kconfig help text was added to clarify why and when > this patch should be reverted, but in the meantime it's a necessary > feature to keep. > > Cc: Dave Airlie > Cc: Daniel Vetter > Cc: Bartlomiej Zolnierkiewicz > Cc: Noralf Trønnes > Cc: Maxime Ripard > Cc: Eric Anholt > Cc: Lucas Stach > Cc: Rob Clark > Cc: Ben Skeggs > Cc: Christian König > Signed-off-by: Neil Armstrong > --- > drivers/gpu/drm/Kconfig | 15 +++ > drivers/gpu/drm/drm_fb_helper.c | 33 +++-- > 2 files changed, 46 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 8871b3f..b07c298 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -110,6 +110,21 @@ config DRM_FBDEV_OVERALLOC > is 100. Typical values for double buffering will be 200, > triple buffering 300. > > +config DRM_FBDEV_LEAK_PHYS_SMEM > + bool "Shamelessly allow leaking of fbdev physical address (DANGEROUS)" > + depends on DRM_FBDEV_EMULATION && EXPERT > + default n > + help > + In order to keep user-space compatibility, we want in certain > + use-cases to keep leaking the fbdev physical address to the > + user-space program handling the fbdev buffer. > + This option is a shame and should be removed as soon as possible > + and be considered as a broken and legacy behaviour from a modern > + fbdev device driver. > + > + If in doubt, say "N" or spread the word to your closed source > + library vendor. > + > config DRM_LOAD_EDID_FIRMWARE > bool "Allow to specify an EDID data set instead of probing for it" > depends on DRM > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index bf2190c..a354944 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -56,6 +56,25 @@ MODULE_PARM_DESC(drm_fbdev_overalloc, >"Overallocation of the fbdev buffer (%) [default=" >__MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]"); > > +/* > + * In order to keep user-space compatibility, we want in certain use-cases > + * to keep leaking the fbdev physical address to the user-space program > + * handling the fbdev buffer. > + * This is a bad habit essentially kept into closed source opengl driver > + * that should really be moved into open-source upstream projects instead > + * of using legacy physical addresses in user space to communicate with > + * other out-of-tree kernel modules. > + * > + * This module_param *should* be removed as soon as possible and be > + * considered as a broken and legacy behaviour from a modern fbdev device. > + */ > +#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM) > +static bool drm_leak_fbdev_smem = false; > +module_param_unsafe(drm_leak_fbdev_smem, bool, 0600); > +MODULE_PARM_DESC(fbdev_emulation, > + "Allow unsafe leaking fbdev physical smem address > [default=false]"); > +#endif > + > static LIST_HEAD(kernel_fb_helper_list); > static DEFINE_MUTEX(kernel_fb_helper_lock); > > @@ -2673,8 +2692,12 @@ __drm_fb_helper_initial_config_and_unlock(struct > drm_fb_helper *fb_helper, > > info = fb_helper->fbdev; > info->var.pixclock = 0; > - /* don't leak any physical addresses to userspace */ > - info->flags |= FBINFO_HIDE_SMEM_START; > + /* Shamelessly allow physical address leaking to userspace */ > +#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM) > +
Re: [PATCH 02/10] phy: Add configuration interface
On Wed, Sep 19, 2018 at 02:14:36PM +0200, Maxime Ripard wrote: > > I'm sorry but I'm not convinced a consumer driver should have all the > > details > > that are added in phy_configure_opts_mipi_dphy. > > If it can convince you, here is the parameters that are needed by all > the MIPI-DSI drivers currently in Linux to configure their PHY: > > - cdns-dsi (drivers/gpu/drm/bridge/cdns-dsi.c) > - hs_clk_rate > - lanes > - videomode > > - kirin (drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c) > - hs_exit > - hs_prepare > - hs_trail > - hs_zero > - lpx > - ta_get > - ta_go > - wakeup > > - msm (drivers/gpu/drm/msm/dsi/*) > - clk_post > - clk_pre > - clk_prepare > - clk_trail > - clk_zero > - hs_clk_rate > - hs_exit > - hs_prepare > - hs_trail > - hs_zero > - lp_clk_rate > - ta_get > - ta_go > - ta_sure > > - mtk (drivers/gpu/drm/mediatek/mtk_dsi.c) > - hs_clk_rate > - hs_exit > - hs_prepare > - hs_trail > - hs_zero > - lpx > > - sun4i (drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c) > - clk_post > - clk_pre > - clk_prepare > - clk_zero > - hs_prepare > - hs_trail > - lanes > - lp_clk_rate > > - tegra (drivers/gpu/drm/tegra/dsi.c) > - clk_post > - clk_pre > - clk_prepare > - clk_trail > - clk_zero > - hs_exit > - hs_prepare > - hs_trail > - hs_zero > - lpx > - ta_get > - ta_go > - ta_sure > > - vc4 (drivers/gpu/drm/vc4/vc4_dsi.c) > - hs_clk_rate > - lanes > > Now, for MIPI-CSI receivers: > > - marvell-ccic (drivers/media/platform/marvell-ccic/mcam-core.c) > - clk_term_en > - clk_settle > - d_term_en > - hs_settle > - lp_clk_rate > > - omap4iss (drivers/staging/media/omap4iss/iss_csiphy.c) > - clk_miss > - clk_settle > - clk_term > - hs_settle > - hs_term > - lanes > > - rcar-vin (drivers/media/platform/rcar-vin/rcar-csi2.c) > - hs_clk_rate > - lanes > > - ti-vpe (drivers/media/platform/ti-vpe/cal.c) > - clk_term_en > - d_term_en > - hs_settle > - hs_term > > So the timings expressed in the structure are the set of all the ones > currently used in the tree by DSI and CSI drivers. I would consider > that a good proof that it would be useful. > > Note that at least cdns-dsi, exynos4-is > (drivers/media/platform/exynos4-is/mipi-csis.c), kirin, sun4i, msm, > mtk, omap4iss, plus the v4l2 drivers cdns-csi2tx and cdns-csi2rx I > want to convert, have already either a driver for their DPHY using the > phy framework plus a configuration function, or a design very similar > that could be migrated to such an API. There's also a patch set currently being submitted that uses a phy driver + custom functions: https://lore.kernel.org/patchwork/cover/988959/ Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/6] drm/virtio: fix DRM_FORMAT_* handling
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little
endian, so using a different mapping on bigendian machines is wrong.
It's there because of broken drm_mode_addfb() behavior. So with
drm_mode_addfb() being fixed we can fix this too.
While wading through the code I've noticed we have a little issue in
virtio: We attach a format to the bo when it is created
(DRM_IOCTL_MODE_CREATE_DUMB), not when we map it as framebuffer
(DRM_IOCTL_MODE_ADDFB). Easy way out: Support a single format only.
Pick DRM_FORMAT_HOST_XRGB, it is the only one actually used in
practice. Drop unused mappings in virtio_gpu_translate_format().
With this patch applied both ADDFB and ADDFB2 ioctls work correctly in
the virtio-gpu.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_display.c | 5 +++
drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_gem.c | 7 +++--
drivers/gpu/drm/virtio/virtgpu_plane.c | 54 ++--
4 files changed, 13 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 0379d68976..8f8fed471e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -307,6 +307,10 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
struct virtio_gpu_framebuffer *virtio_gpu_fb;
int ret;
+ if (mode_cmd->pixel_format != DRM_FORMAT_HOST_XRGB &&
+ mode_cmd->pixel_format != DRM_FORMAT_HOST_ARGB)
+ return ERR_PTR(-ENOENT);
+
/* lookup object associated with res handle */
obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
if (!obj)
@@ -355,6 +359,7 @@ int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev)
int i;
drm_mode_config_init(vgdev->ddev);
+ vgdev->ddev->mode_config.quirk_addfb_prefer_host_byte_order = true;
vgdev->ddev->mode_config.funcs = _gpu_mode_funcs;
vgdev->ddev->mode_config.helper_private = _mode_config_helpers;
diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c
b/drivers/gpu/drm/virtio/virtgpu_fb.c
index b9678c4082..abc4ec4c62 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -226,7 +226,7 @@ static int virtio_gpufb_create(struct drm_fb_helper *helper,
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
mode_cmd.pitches[0] = mode_cmd.width * 4;
- mode_cmd.pixel_format = drm_mode_legacy_fb_format(32, 24);
+ mode_cmd.pixel_format = DRM_FORMAT_HOST_XRGB;
format = virtio_gpu_translate_format(mode_cmd.pixel_format);
if (format == 0)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 0f2768eaca..82c817f37c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -90,7 +90,10 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
uint32_t resid;
uint32_t format;
- pitch = args->width * ((args->bpp + 1) / 8);
+ if (args->bpp != 32)
+ return -EINVAL;
+
+ pitch = args->width * 4;
args->size = pitch * args->height;
args->size = ALIGN(args->size, PAGE_SIZE);
@@ -99,7 +102,7 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
if (ret)
goto fail;
- format = virtio_gpu_translate_format(DRM_FORMAT_XRGB);
+ format = virtio_gpu_translate_format(DRM_FORMAT_HOST_XRGB);
virtio_gpu_resource_id_get(vgdev, );
virtio_gpu_cmd_create_resource(vgdev, resid, format,
args->width, args->height);
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 88f2fb8c61..a84ff56507 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -28,22 +28,11 @@
#include
static const uint32_t virtio_gpu_formats[] = {
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_BGRX,
- DRM_FORMAT_BGRA,
- DRM_FORMAT_RGBX,
- DRM_FORMAT_RGBA,
- DRM_FORMAT_XBGR,
- DRM_FORMAT_ABGR,
+ DRM_FORMAT_HOST_XRGB,
};
static const uint32_t virtio_gpu_cursor_formats[] = {
-#ifdef __BIG_ENDIAN
- DRM_FORMAT_BGRA,
-#else
- DRM_FORMAT_ARGB,
-#endif
+ DRM_FORMAT_HOST_ARGB,
};
uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc)
@@ -51,32 +40,6 @@
[PATCH v4 3/6] drm/bochs: fix DRM_FORMAT_* handling for big endian machines.
Use DRM_FORMAT_HOST_XRGB, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Create our own plane and use drm_crtc_init_with_planes() instead of
depending on the default created by drm_crtc_init(). That way the plane
format list is correct on bigendian machines.
Also re-add the framebuffer format check dropped by "df2052cc92 bochs:
convert to drm_fb_helper_fbdev_setup/teardown".
With this patch applied both ADDFB and ADDFB2 ioctls work correctly in
the bochs-drm.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_fbdev.c | 17 +
drivers/gpu/drm/bochs/bochs_kms.c | 34 +-
2 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 8f4d6c052f..c46fdae44e 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -63,9 +63,8 @@ static int bochsfb_create(struct drm_fb_helper *helper,
mode_cmd.width = sizes->surface_width;
mode_cmd.height = sizes->surface_height;
- mode_cmd.pitches[0] = mode_cmd.width * ((sizes->surface_bpp + 7) / 8);
- mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
- sizes->surface_depth);
+ mode_cmd.pitches[0] = sizes->surface_width * 4;
+ mode_cmd.pixel_format = DRM_FORMAT_HOST_XRGB;
size = mode_cmd.pitches[0] * mode_cmd.height;
/* alloc, pin & map bo */
@@ -137,8 +136,18 @@ static const struct drm_fb_helper_funcs
bochs_fb_helper_funcs = {
.fb_probe = bochsfb_create,
};
+static struct drm_framebuffer *
+bochs_gem_fb_create(struct drm_device *dev, struct drm_file *file,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ if (mode_cmd->pixel_format != DRM_FORMAT_HOST_XRGB)
+ return ERR_PTR(-EINVAL);
+
+ return drm_gem_fb_create(dev, file, mode_cmd);
+}
+
const struct drm_mode_config_funcs bochs_mode_funcs = {
- .fb_create = drm_gem_fb_create,
+ .fb_create = bochs_gem_fb_create,
};
int bochs_fbdev_init(struct bochs_device *bochs)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index ea9a43d31b..f3fdaf9456 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -126,12 +126,43 @@ static const struct drm_crtc_helper_funcs
bochs_helper_funcs = {
.commit = bochs_crtc_commit,
};
+static const uint32_t bochs_formats[] = {
+ DRM_FORMAT_HOST_XRGB,
+};
+
+static struct drm_plane *bochs_primary_plane(struct drm_device *dev)
+{
+ struct drm_plane *primary;
+ int ret;
+
+ primary = kzalloc(sizeof(*primary), GFP_KERNEL);
+ if (primary == NULL) {
+ DRM_DEBUG_KMS("Failed to allocate primary plane\n");
+ return NULL;
+ }
+
+ ret = drm_universal_plane_init(dev, primary, 0,
+ _primary_helper_funcs,
+ bochs_formats,
+ ARRAY_SIZE(bochs_formats),
+ NULL,
+ DRM_PLANE_TYPE_PRIMARY, NULL);
+ if (ret) {
+ kfree(primary);
+ primary = NULL;
+ }
+
+ return primary;
+}
+
static void bochs_crtc_init(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
struct drm_crtc *crtc = >crtc;
+ struct drm_plane *primary = bochs_primary_plane(dev);
- drm_crtc_init(dev, crtc, _crtc_funcs);
+ drm_crtc_init_with_planes(dev, crtc, primary, NULL,
+ _crtc_funcs, NULL);
drm_crtc_helper_add(crtc, _helper_funcs);
}
@@ -250,6 +281,7 @@ int bochs_kms_init(struct bochs_device *bochs)
bochs->dev->mode_config.fb_base = bochs->fb_base;
bochs->dev->mode_config.preferred_depth = 24;
bochs->dev->mode_config.prefer_shadow = 0;
+ bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
bochs->dev->mode_config.funcs = _mode_funcs;
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/6] drm: use drm_driver_legacy_fb_format in drm_gem_fbdev_fb_create
Creating framebuffers for fbdev emulation should use the correct format code too, so switch drm_gem_fbdev_fb_create() over to use the new drm_driver_legacy_fb_format() function. Signed-off-by: Gerd Hoffmann Acked-by: Daniel Vetter --- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c b/drivers/gpu/drm/drm_gem_framebuffer_helper.c index 7607f9cd6f..ded7a379ac 100644 --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c @@ -316,8 +316,8 @@ drm_gem_fbdev_fb_create(struct drm_device *dev, if (pitch_align) mode_cmd.pitches[0] = roundup(mode_cmd.pitches[0], pitch_align); - mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, - sizes->surface_depth); + mode_cmd.pixel_format = drm_driver_legacy_fb_format(dev, sizes->surface_bpp, + sizes->surface_depth); if (obj->size < mode_cmd.pitches[0] * mode_cmd.height) return ERR_PTR(-EINVAL); -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/6] drm: move native byte order quirk to new drm_driver_legacy_fb_format function
Turns out we need the pixel format fixup not only for the addfb ioctl,
but also for fbdev emulation code.
Ideally we would place it in drm_mode_legacy_fb_format(). That would
create alot of churn though, and most drivers don't care because they
never ever run on a big endian platform. So add a new
drm_driver_legacy_fb_format() function instead which looks at the
mode_config->quirk_addfb_prefer_host_byte_order flag.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
include/drm/drm_fourcc.h | 2 ++
drivers/gpu/drm/drm_fourcc.c | 30 ++
drivers/gpu/drm/drm_framebuffer.c | 13 +
3 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index fac831c401..865ef60c17 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -88,6 +88,8 @@ const struct drm_format_info *
drm_get_format_info(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd);
uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
+uint32_t drm_driver_legacy_fb_format(struct drm_device *dev,
+uint32_t bpp, uint32_t depth);
int drm_format_num_planes(uint32_t format);
int drm_format_plane_cpp(uint32_t format, int plane);
int drm_format_horz_chroma_subsampling(uint32_t format);
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index be1d6aaef6..7c6d3922ed 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -96,6 +96,36 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t
depth)
EXPORT_SYMBOL(drm_mode_legacy_fb_format);
/**
+ * drm_driver_legacy_fb_format - compute drm fourcc code from legacy
description
+ * @bpp: bits per pixels
+ * @depth: bit depth per pixel
+ * @native: use host native byte order
+ *
+ * Computes a drm fourcc pixel format code for the given @bpp/@depth values.
+ * Unlike drm_mode_legacy_fb_format() this looks at the drivers mode_config,
+ * and depending on the quirk_addfb_prefer_host_byte_order flag it returns
+ * little endian byte order or host byte order framebuffer formats.
+ */
+uint32_t drm_driver_legacy_fb_format(struct drm_device *dev,
+uint32_t bpp, uint32_t depth)
+{
+ uint32_t fmt = drm_mode_legacy_fb_format(bpp, depth);
+
+ if (dev->mode_config.quirk_addfb_prefer_host_byte_order) {
+ if (fmt == DRM_FORMAT_XRGB)
+ fmt = DRM_FORMAT_HOST_XRGB;
+ if (fmt == DRM_FORMAT_ARGB)
+ fmt = DRM_FORMAT_HOST_ARGB;
+ if (fmt == DRM_FORMAT_RGB565)
+ fmt = DRM_FORMAT_HOST_RGB565;
+ if (fmt == DRM_FORMAT_XRGB1555)
+ fmt = DRM_FORMAT_HOST_XRGB1555;
+ }
+ return fmt;
+}
+EXPORT_SYMBOL(drm_driver_legacy_fb_format);
+
+/**
* drm_get_format_name - fill a string with a drm fourcc format's name
* @format: format to compute name of
* @buf: caller-supplied buffer
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 1ee3d6b442..1e2126101c 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -116,7 +116,7 @@ int drm_mode_addfb(struct drm_device *dev, struct
drm_mode_fb_cmd *or,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
- r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
+ r.pixel_format = drm_driver_legacy_fb_format(dev, or->bpp, or->depth);
if (r.pixel_format == DRM_FORMAT_INVALID) {
DRM_DEBUG("bad {bpp:%d, depth:%d}\n", or->bpp, or->depth);
return -EINVAL;
@@ -133,17 +133,6 @@ int drm_mode_addfb(struct drm_device *dev, struct
drm_mode_fb_cmd *or,
r.pixel_format == DRM_FORMAT_XRGB2101010)
r.pixel_format = DRM_FORMAT_XBGR2101010;
- if (dev->mode_config.quirk_addfb_prefer_host_byte_order) {
- if (r.pixel_format == DRM_FORMAT_XRGB)
- r.pixel_format = DRM_FORMAT_HOST_XRGB;
- if (r.pixel_format == DRM_FORMAT_ARGB)
- r.pixel_format = DRM_FORMAT_HOST_ARGB;
- if (r.pixel_format == DRM_FORMAT_RGB565)
- r.pixel_format = DRM_FORMAT_HOST_RGB565;
- if (r.pixel_format == DRM_FORMAT_XRGB1555)
- r.pixel_format = DRM_FORMAT_HOST_XRGB1555;
- }
-
ret = drm_mode_addfb2(dev, , file_priv);
if (ret)
return ret;
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/6] drm/bochs: support changing byteorder at mode set time
Add bochs_hw_set_*_endian() helper functions, to set the framebuffer
byteorder at mode set time. Support both DRM_FORMAT_XRGB and
DRM_FORMAT_BGRX framebuffer formats, no matter what the native
machine byte order is.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs.h | 4 ++-
drivers/gpu/drm/bochs/bochs_fbdev.c | 3 +-
drivers/gpu/drm/bochs/bochs_hw.c| 64 +
drivers/gpu/drm/bochs/bochs_kms.c | 8 +++--
4 files changed, 61 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index b4f6bb5219..e7a69077e4 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -58,6 +58,7 @@ struct bochs_device {
void __iomem *fb_map;
unsigned long fb_base;
unsigned long fb_size;
+ unsigned long qext_size;
/* mode */
u16 xres;
@@ -121,7 +122,8 @@ int bochs_hw_init(struct drm_device *dev);
void bochs_hw_fini(struct drm_device *dev);
void bochs_hw_setmode(struct bochs_device *bochs,
- struct drm_display_mode *mode);
+ struct drm_display_mode *mode,
+ const struct drm_format_info *format);
void bochs_hw_setbase(struct bochs_device *bochs,
int x, int y, u64 addr);
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index c46fdae44e..dd3c7df267 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -140,7 +140,8 @@ static struct drm_framebuffer *
bochs_gem_fb_create(struct drm_device *dev, struct drm_file *file,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- if (mode_cmd->pixel_format != DRM_FORMAT_HOST_XRGB)
+ if (mode_cmd->pixel_format != DRM_FORMAT_XRGB &&
+ mode_cmd->pixel_format != DRM_FORMAT_BGRX)
return ERR_PTR(-EINVAL);
return drm_gem_fb_create(dev, file, mode_cmd);
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index 16e4f1cacc..cacff73a64 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -47,11 +47,33 @@ static void bochs_dispi_write(struct bochs_device *bochs,
u16 reg, u16 val)
}
}
+static void bochs_hw_set_big_endian(struct bochs_device *bochs)
+{
+ if (bochs->qext_size < 8)
+ return;
+
+ writel(0xbebebebe, bochs->mmio + 0x604);
+}
+
+static void bochs_hw_set_little_endian(struct bochs_device *bochs)
+{
+ if (bochs->qext_size < 8)
+ return;
+
+ writel(0x1e1e1e1e, bochs->mmio + 0x604);
+}
+
+#ifdef __BIG_ENDIAN
+#define bochs_hw_set_native_endian(_b) bochs_hw_set_big_endian(_b)
+#else
+#define bochs_hw_set_native_endian(_b) bochs_hw_set_little_endian(_b)
+#endif
+
int bochs_hw_init(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
struct pci_dev *pdev = dev->pdev;
- unsigned long addr, size, mem, ioaddr, iosize, qext_size;
+ unsigned long addr, size, mem, ioaddr, iosize;
u16 id;
if (pdev->resource[2].flags & IORESOURCE_MEM) {
@@ -117,19 +139,14 @@ int bochs_hw_init(struct drm_device *dev)
ioaddr);
if (bochs->mmio && pdev->revision >= 2) {
- qext_size = readl(bochs->mmio + 0x600);
- if (qext_size < 4 || qext_size > iosize)
+ bochs->qext_size = readl(bochs->mmio + 0x600);
+ if (bochs->qext_size < 4 || bochs->qext_size > iosize) {
+ bochs->qext_size = 0;
goto noext;
- DRM_DEBUG("Found qemu ext regs, size %ld\n", qext_size);
- if (qext_size >= 8) {
-#ifdef __BIG_ENDIAN
- writel(0xbebebebe, bochs->mmio + 0x604);
-#else
- writel(0x1e1e1e1e, bochs->mmio + 0x604);
-#endif
- DRM_DEBUG(" qext endian: 0x%x\n",
- readl(bochs->mmio + 0x604));
}
+ DRM_DEBUG("Found qemu ext regs, size %ld\n",
+ bochs->qext_size);
+ bochs_hw_set_native_endian(bochs);
}
noext:
@@ -150,7 +167,8 @@ void bochs_hw_fini(struct drm_device *dev)
}
void bochs_hw_setmode(struct bochs_device *bochs,
- struct drm_display_mode *mode)
+ struct drm_display_mode *mode,
+ const struct drm_format_info *format)
{
bochs->xres = mode->hdisplay;
bochs->yres = mode->vdisplay;
@@ -158,8 +176,12 @@ void bochs_hw_setmode(struct bochs_device *bochs,
bochs->stride = mode->hdisplay * (bochs->bpp / 8);
bochs->yres_virtual = bochs->fb_size / bochs->stride;
- DRM_DEBUG_DRIVER("%dx%d @ %d bpp, vy %d\n",
+ DRM_DEBUG_DRIVER("%dx%d @ %d bpp, format %c%c%c%c, vy %d\n",
[PATCH v4 6/6] drm: move quirk_addfb_prefer_xbgr_30bpp handling to drm_driver_legacy_fb_format too
Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/drm_fourcc.c | 5 + drivers/gpu/drm/drm_framebuffer.c | 4 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c index 7c6d3922ed..90a1c846fc 100644 --- a/drivers/gpu/drm/drm_fourcc.c +++ b/drivers/gpu/drm/drm_fourcc.c @@ -121,6 +121,11 @@ uint32_t drm_driver_legacy_fb_format(struct drm_device *dev, if (fmt == DRM_FORMAT_XRGB1555) fmt = DRM_FORMAT_HOST_XRGB1555; } + + if (dev->mode_config.quirk_addfb_prefer_xbgr_30bpp && + fmt == DRM_FORMAT_XRGB2101010) + fmt = DRM_FORMAT_XBGR2101010; + return fmt; } EXPORT_SYMBOL(drm_driver_legacy_fb_format); diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index 1e2126101c..3bf729d0aa 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -129,10 +129,6 @@ int drm_mode_addfb(struct drm_device *dev, struct drm_mode_fb_cmd *or, r.pitches[0] = or->pitch; r.handles[0] = or->handle; - if (dev->mode_config.quirk_addfb_prefer_xbgr_30bpp && - r.pixel_format == DRM_FORMAT_XRGB2101010) - r.pixel_format = DRM_FORMAT_XBGR2101010; - ret = drm_mode_addfb2(dev, , file_priv); if (ret) return ret; -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Fri, Sep 21, 2018 at 01:34:00AM -0700, Manasi Navare wrote:
> On Wed, Sep 19, 2018 at 01:57:00PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 18, 2018 at 02:10:17PM -0700, Manasi Navare wrote:
> > > On Tue, Sep 18, 2018 at 10:46:46PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> > > > > On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > > > > > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > > > > > Thanks Imre for your review comments. Please find the comments
> > > > > > > below:
> > > > > > >
> > > > > > > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > > > > > > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > > > > > > > On Icelake, a separate power well PG2 is created for
> > > > > > > > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > > > > > > > display power domain for Power well 2.
> > > > > > > > >
> > > > > > > > > Cc: Rodrigo Vivi
> > > > > > > > > Cc: Imre Deak
> > > > > > > > > Signed-off-by: Manasi Navare
> > > > > > > > > ---
> > > > > > > > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > > > > > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > > > > > > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > > b/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > > > > > > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > > > > > > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > > > > > > > POWER_DOMAIN_MODESET,
> > > > > > > > > POWER_DOMAIN_GT_IRQ,
> > > > > > > > > POWER_DOMAIN_INIT,
> > > > > > > > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> > > > > > > >
> > > > > > > > This is better named VDSC_PIPE_A. The other pipes have also VDSC
> > > > > > > > functionality which could be on separate power wells in the
> > > > > > > > future.
> > > > > > > >
> > > > > > >
> > > > > > > Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on
> > > > > > > Pipe A
> > > > > > > will use this VDSC power well.
> > > > > > > I will change this in the next revision.
> > > > > >
> > > > > > Isn't the VDSC in the transcoder for now though? And I guess it's
> > > > > > moving to the pipe later?
> > > > >
> > > > > VDSC engine is attached to the eDP/DSI transcoders and this gets used
> > > > > for eDP/DSI VDSC on Pipe A.
> > > >
> > > > And what happens when I want to use pipe B instead?
> > >
> > > DP VDSC on Pipe B uses the VDSC engine on Pipe B. Same for Pipe C
> >
> > There are no VDSCs in pipe B or C. There are VDSCs in transcoder B
> > and C. But that's not the same thing at all. The mux is between the
> > pipe and transcoder.
> >
>
> As per the display overview for Gen 11, the VDSC engine is present on Pipe B
> And C.
On transcoder B and C, not pipe B and C.
> But for Pipe A only, it uses VDSC engine attached to transcoder eDP/DSI.
>
> > > Can we have a situation where eDP uses Pipe B?
> >
> > Sure. 'xrandr --output eDP --crtc 1', or whatever.
> >
>
> I guess even in this case, if its eDP/DSI, it will still use the VDSC engine
> on transcoder eDP so will need to enable this power well 2.
>
> Manasi
>
> > > Because in case of VDSC
> > > in case of eDP, it will always use the VDSC on transcoder eDP which will
> > > require this power well.
> > >
> > > Manasi
> > >
> > > >
> > > > > So we could call it VDSC_PIPE_A since VDSC on Pipe A for eDP/DSI
> > > > > will use this power well. But may be we should add a comment that
> > > > > this is only for eDP/DSI on Pipe A since ICL does not support
> > > > > VDSC on DP on Pipe A
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Manasi
> > > > >
> > > > > >
> > > > > > If we call it PIPE_A then it's going to a bit confusing when we
> > > > > > use it with pipe B or C. Needs at least clear comments in the code
> > > > > > why we're doing something that looks like nonsense of the first
> > > > > > glance.
> > > > > >
> > > > > > --
> > > > > > Ville Syrjälä
> > > > > > Intel
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/6] drm: more byteorder fixes
Fix fbdev emulation. Fix bochs-drm and virtio-gpu drivers. Gerd Hoffmann (6): drm: move native byte order quirk to new drm_driver_legacy_fb_format function drm: use drm_driver_legacy_fb_format in drm_gem_fbdev_fb_create drm/bochs: fix DRM_FORMAT_* handling for big endian machines. drm/bochs: support changing byteorder at mode set time drm/virtio: fix DRM_FORMAT_* handling drm: move quirk_addfb_prefer_xbgr_30bpp handling to drm_driver_legacy_fb_format too drivers/gpu/drm/bochs/bochs.h| 4 +- include/drm/drm_fourcc.h | 2 + drivers/gpu/drm/bochs/bochs_fbdev.c | 18 ++-- drivers/gpu/drm/bochs/bochs_hw.c | 64 ++-- drivers/gpu/drm/bochs/bochs_kms.c| 40 - drivers/gpu/drm/drm_fourcc.c | 35 +++ drivers/gpu/drm/drm_framebuffer.c| 17 +--- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 +- drivers/gpu/drm/virtio/virtgpu_display.c | 5 +++ drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +- drivers/gpu/drm/virtio/virtgpu_gem.c | 7 ++- drivers/gpu/drm/virtio/virtgpu_plane.c | 54 +-- 12 files changed, 158 insertions(+), 94 deletions(-) -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/18] drm/i915: Pass intel_encoder to infoframe functions
On Thu, Sep 20, 2018 at 09:51:36PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make life simpler by passing around intel_encoder instead of
> drm_encoder.
>
> @r1@
> identifier F =~ "infoframe";
> identifier I, M;
> @@
> F(
> - struct drm_encoder *I
> + struct intel_encoder *I
> , ...)
> {
> <...
> (
> - I->M
> + I->base.M
> |
> - I
> + >base
> )
> ...>
> }
>
> @r2@
> identifier F =~ "infoframe";
> identifier I;
> type T, ST;
> @@
> ST {
> ...
> T (*F)(
> -struct drm_encoder *I
> +struct intel_encoder *encoder
> , ...);
> ...
> };
>
> @@
> identifier r1.F;
> expression E;
> @@
> F(
> - E
> + to_intel_encoder(E)
> ,...)
>
> @@
> identifier r2.F;
> expression E, X;
> @@
> (
> X.F(
> - E
> + to_intel_encoder(E)
> ,...)
> |
> X->F(
> -E
> +to_intel_encoder(E)
> ,...)
> )
>
> @@
> expression E;
> @@
> (
> - to_intel_encoder(>base)
> + E
> |
> - to_intel_encoder(>base.base)
> + >base
> )
>
> @@
> identifier D, M;
> expression E;
> @@
> D = enc_to_dig_port(>base)
> <...
> (
> - D->base.M
> + E->M
> |
> - >base
> + E
> )
> ...>
>
> @@
> identifier D;
> expression E;
> type T;
> @@
> - T D = enc_to_dig_port(E);
> ... when != D
Someone knows a lot more cocci than I do, impressive. How do you figure
this stuff out? Read the source?
Also seems to have some manual fixups below, so I just looked at the diff.
That looks fine.
Acked-by: Daniel Vetter
I'll trust the compiler more here :-)
Cheers, Daniel
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 6 +-
> drivers/gpu/drm/i915/intel_drv.h | 6 +-
> drivers/gpu/drm/i915/intel_hdmi.c | 129
> +++---
> drivers/gpu/drm/i915/intel_psr.c | 3 +-
> 4 files changed, 71 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b6910c8b4e08..086e3f940586 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2947,7 +2947,7 @@ static void intel_ddi_pre_enable_hdmi(struct
> intel_encoder *encoder,
>
> intel_ddi_enable_pipe_clock(crtc_state);
>
> - intel_dig_port->set_infoframes(>base,
> + intel_dig_port->set_infoframes(encoder,
> crtc_state->has_infoframe,
> crtc_state, conn_state);
> }
> @@ -3046,7 +3046,7 @@ static void intel_ddi_post_disable_hdmi(struct
> intel_encoder *encoder,
> struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> struct intel_hdmi *intel_hdmi = _port->hdmi;
>
> - dig_port->set_infoframes(>base, false,
> + dig_port->set_infoframes(encoder, false,
>old_crtc_state, old_conn_state);
>
> intel_ddi_disable_pipe_clock(old_crtc_state);
> @@ -3390,7 +3390,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
> pipe_config->has_hdmi_sink = true;
> intel_dig_port = enc_to_dig_port(>base);
>
> - if (intel_dig_port->infoframe_enabled(>base,
> pipe_config))
> + if (intel_dig_port->infoframe_enabled(encoder, pipe_config))
> pipe_config->has_infoframe = true;
>
> if ((temp & TRANS_DDI_HDMI_SCRAMBLING_MASK) ==
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index bf1c38728a59..e0f3a79fc75e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1173,15 +1173,15 @@ struct intel_digital_port {
> enum intel_display_power_domain ddi_io_power_domain;
> enum tc_port_type tc_type;
>
> - void (*write_infoframe)(struct drm_encoder *encoder,
> + void (*write_infoframe)(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state,
> unsigned int type,
> const void *frame, ssize_t len);
> - void (*set_infoframes)(struct drm_encoder *encoder,
> + void (*set_infoframes)(struct intel_encoder *encoder,
> bool enable,
> const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state);
> - bool (*infoframe_enabled)(struct drm_encoder *encoder,
> + bool (*infoframe_enabled)(struct intel_encoder *encoder,
> const struct intel_crtc_state *pipe_config);
> };
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 3b56ab253171..454f570275e9 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -148,14 +148,13 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
> }
> }
>
> -static void g4x_write_infoframe(struct drm_encoder *encoder,
> +static void g4x_write_infoframe(struct intel_encoder *encoder,
>
Re: [Intel-gfx] [PATCH 10/18] drm/i915: Add the missing HDMI gamut metadata packet stuff
On Thu, Sep 20, 2018 at 09:51:37PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We have definitions and low level code for everything except the gamut
> metadata HDMI packet. Add the missing bits.
>
> Signed-off-by: Ville Syrjälä
Online Bspec seems to have dropped pre-cpt/snb stuff, but I found some old
copies
still :-)
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4 +++-
> drivers/gpu/drm/i915/intel_hdmi.c | 12
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4948b352bf4c..c07fd394ca1d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4577,6 +4577,7 @@ enum {
> #define VIDEO_DIP_ENABLE_SPD (8 << 21)
> #define VIDEO_DIP_SELECT_AVI (0 << 19)
> #define VIDEO_DIP_SELECT_VENDOR(1 << 19)
> +#define VIDEO_DIP_SELECT_GAMUT (2 << 19)
> #define VIDEO_DIP_SELECT_SPD (3 << 19)
> #define VIDEO_DIP_SELECT_MASK (3 << 19)
> #define VIDEO_DIP_FREQ_ONCE(0 << 16)
> @@ -7948,10 +7949,11 @@ enum {
> #define _ICL_VIDEO_DIP_PPS_ECC_B 0x613D4
>
> #define HSW_TVIDEO_DIP_CTL(trans)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_CTL_A)
> +#define HSW_TVIDEO_DIP_GCP(trans)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_GCP_A)
> #define HSW_TVIDEO_DIP_AVI_DATA(trans, i)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_AVI_DATA_A + (i) * 4)
> #define HSW_TVIDEO_DIP_VS_DATA(trans, i) _MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_VS_DATA_A + (i) * 4)
> #define HSW_TVIDEO_DIP_SPD_DATA(trans, i)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_SPD_DATA_A + (i) * 4)
> -#define HSW_TVIDEO_DIP_GCP(trans)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_GCP_A)
> +#define HSW_TVIDEO_DIP_GMP_DATA(trans, i)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_GMP_DATA_A + (i) * 4)
> #define HSW_TVIDEO_DIP_VSC_DATA(trans, i)_MMIO_TRANS2(trans,
> _HSW_VIDEO_DIP_VSC_DATA_A + (i) * 4)
> #define ICL_VIDEO_DIP_PPS_DATA(trans, i) _MMIO_TRANS2(trans,
> _ICL_VIDEO_DIP_PPS_DATA_A + (i) * 4)
> #define ICL_VIDEO_DIP_PPS_ECC(trans, i) _MMIO_TRANS2(trans,
> _ICL_VIDEO_DIP_PPS_ECC_A + (i) * 4)
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 454f570275e9..c3c2a638d062 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -83,6 +83,8 @@ static struct intel_hdmi *intel_attached_hdmi(struct
> drm_connector *connector)
> static u32 g4x_infoframe_index(unsigned int type)
> {
> switch (type) {
> + case HDMI_PACKET_TYPE_GAMUT_METADATA:
> + return VIDEO_DIP_SELECT_GAMUT;
> case HDMI_INFOFRAME_TYPE_AVI:
> return VIDEO_DIP_SELECT_AVI;
> case HDMI_INFOFRAME_TYPE_SPD:
> @@ -98,6 +100,10 @@ static u32 g4x_infoframe_index(unsigned int type)
> static u32 g4x_infoframe_enable(unsigned int type)
> {
> switch (type) {
> + case HDMI_PACKET_TYPE_GENERAL_CONTROL:
> + return VIDEO_DIP_ENABLE_GCP;
> + case HDMI_PACKET_TYPE_GAMUT_METADATA:
> + return VIDEO_DIP_ENABLE_GAMUT;
> case HDMI_INFOFRAME_TYPE_AVI:
> return VIDEO_DIP_ENABLE_AVI;
> case HDMI_INFOFRAME_TYPE_SPD:
> @@ -113,6 +119,10 @@ static u32 g4x_infoframe_enable(unsigned int type)
> static u32 hsw_infoframe_enable(unsigned int type)
> {
> switch (type) {
> + case HDMI_PACKET_TYPE_GENERAL_CONTROL:
> + return VIDEO_DIP_ENABLE_GCP_HSW;
> + case HDMI_PACKET_TYPE_GAMUT_METADATA:
> + return VIDEO_DIP_ENABLE_GMP_HSW;
> case DP_SDP_VSC:
> return VIDEO_DIP_ENABLE_VSC_HSW;
> case HDMI_INFOFRAME_TYPE_AVI:
> @@ -134,6 +144,8 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
>int i)
> {
> switch (type) {
> + case HDMI_PACKET_TYPE_GAMUT_METADATA:
> + return HSW_TVIDEO_DIP_GMP_DATA(cpu_transcoder, i);
> case DP_SDP_VSC:
> return HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, i);
> case HDMI_INFOFRAME_TYPE_AVI:
> --
> 2.16.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Bug report: HiBMC crash
Quoting John Garry (2018-09-21 09:11:19)
> On 21/09/2018 06:49, Liuxinliang (Matthew Liu) wrote:
> > Hi John,
> > Thank you for reporting bug.
> > I am now using 4.18.7. I haven't found this issue yet.
> > I will try linux-next and figure out what's wrong with it.
> >
> > Thanks,
> > Xinliang
> >
> >
>
> As mentioned in internal mail, the issue may be that the surface
> depth/bpp we were using the in the driver was previously invalid, but
> code has since been added in v4.19 to reject this. Specifically it looks
> like this patch:
>
> commit 70109354fed232dfce8fb2c7cadf635acbe03e19
> Author: Chris Wilson
> Date: Wed Sep 5 16:31:16 2018 +0100
>
> drm: Reject unknown legacy bpp and depth for drm_mode_addfb ioctl
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
index b92595c477ef..f3e7f41e6781 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
@@ -71,7 +71,6 @@ static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
DRM_DEBUG_DRIVER("surface width(%d), height(%d) and bpp(%d)\n",
sizes->surface_width, sizes->surface_height,
sizes->surface_bpp);
- sizes->surface_depth = 32;
bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
@@ -192,7 +191,6 @@ int hibmc_fbdev_init(struct hibmc_drm_private *priv)
return -ENOMEM;
}
- priv->fbdev = hifbdev;
drm_fb_helper_prepare(priv->dev, >helper,
_fbdev_helper_funcs);
@@ -246,6 +244,7 @@ int hibmc_fbdev_init(struct hibmc_drm_private *priv)
fix->ypanstep, fix->ywrapstep, fix->line_length,
fix->accel, fix->capabilities);
+ priv->fbdev = hifbdev;
return 0;
fini:
Apply chunks 2&3 first to confirm they fix the GPF.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/18] video/hdmi: Constify infoframe passed to the pack functions
From: Ville Syrjälä
Let's make the infoframe pack functions usable with a const infoframe
structure. This allows us to precompute the infoframe earlier, and still
pack it later when we're no longer allowed to modify the structure.
So now we end up with a _check()+_pack_only() or _pack() functions
depending on whether you want to precompute the infoframes or not.
The names aren't great but I was lazy and didn't want to change all the
drivers.
v2: Deal with exynos churn
Actually export the new funcs
v3: Fix various documentation fails (Hans)
Cc: Thierry Reding
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c | 425 +++
include/linux/hdmi.h | 19 ++-
2 files changed, 416 insertions(+), 28 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 53e7ee2c83fc..08d94ab00467 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -68,8 +68,36 @@ int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe *frame)
}
EXPORT_SYMBOL(hdmi_avi_infoframe_init);
+static int hdmi_avi_infoframe_check_only(const struct hdmi_avi_infoframe
*frame)
+{
+ if (frame->type != HDMI_INFOFRAME_TYPE_AVI ||
+ frame->version != 2 ||
+ frame->length != HDMI_AVI_INFOFRAME_SIZE)
+ return -EINVAL;
+
+ if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
+ return -EINVAL;
+
+ return 0;
+}
+
/**
- * hdmi_avi_infoframe_pack() - write HDMI AVI infoframe to binary buffer
+ * hdmi_avi_infoframe_check() - check a HDMI AVI infoframe
+ * @frame: HDMI AVI infoframe
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_avi_infoframe_check(struct hdmi_avi_infoframe *frame)
+{
+ return hdmi_avi_infoframe_check_only(frame);
+}
+EXPORT_SYMBOL(hdmi_avi_infoframe_check);
+
+/**
+ * hdmi_avi_infoframe_pack_only() - write HDMI AVI infoframe to binary buffer
* @frame: HDMI AVI infoframe
* @buffer: destination buffer
* @size: size of buffer
@@ -82,20 +110,22 @@ EXPORT_SYMBOL(hdmi_avi_infoframe_init);
* Returns the number of bytes packed into the binary buffer or a negative
* error code on failure.
*/
-ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame, void *buffer,
- size_t size)
+ssize_t hdmi_avi_infoframe_pack_only(const struct hdmi_avi_infoframe *frame,
+void *buffer, size_t size)
{
u8 *ptr = buffer;
size_t length;
+ int ret;
+
+ ret = hdmi_avi_infoframe_check_only(frame);
+ if (ret)
+ return ret;
length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
if (size < length)
return -ENOSPC;
- if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
- return -EINVAL;
-
memset(buffer, 0, size);
ptr[0] = frame->type;
@@ -152,6 +182,36 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe
*frame, void *buffer,
return length;
}
+EXPORT_SYMBOL(hdmi_avi_infoframe_pack_only);
+
+/**
+ * hdmi_avi_infoframe_pack() - check a HDMI AVI infoframe,
+ * and write it to binary buffer
+ * @frame: HDMI AVI infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Validates that the infoframe is consistent and updates derived fields
+ * (eg. length) based on other fields, after which it packs the information
+ * contained in the @frame structure into a binary representation that
+ * can be written into the corresponding controller registers. This function
+ * also computes the checksum as required by section 5.3.5 of the HDMI 1.4
+ * specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame,
+ void *buffer, size_t size)
+{
+ int ret;
+
+ ret = hdmi_avi_infoframe_check(frame);
+ if (ret)
+ return ret;
+
+ return hdmi_avi_infoframe_pack_only(frame, buffer, size);
+}
EXPORT_SYMBOL(hdmi_avi_infoframe_pack);
/**
@@ -178,8 +238,33 @@ int hdmi_spd_infoframe_init(struct hdmi_spd_infoframe
*frame,
}
EXPORT_SYMBOL(hdmi_spd_infoframe_init);
+static int hdmi_spd_infoframe_check_only(const struct hdmi_spd_infoframe
*frame)
+{
+ if (frame->type != HDMI_INFOFRAME_TYPE_SPD ||
+ frame->version != 1 ||
+ frame->length != HDMI_SPD_INFOFRAME_SIZE)
+ return -EINVAL;
+
+ return 0;
+}
+
/**
- * hdmi_spd_infoframe_pack() - write HDMI SPD infoframe to binary buffer
+ * hdmi_spd_infoframe_check() - check a HDMI SPD infoframe
+ * @frame: HDMI SPD infoframe
+ *
+ * Validates that the infoframe is consistent and updates derived
Re: [PATCH 04/18] video/hdmi: Constify infoframe passed to the pack functions
On Fri, Sep 21, 2018 at 10:24:25AM +0200, Hans Verkuil wrote:
> On 09/20/18 20:51, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's make the infoframe pack functions usable with a const infoframe
> > structure. This allows us to precompute the infoframe earlier, and still
> > pack it later when we're no longer allowed to modify the structure.
> > So now we end up with a _check()+_pack_only() or _pack() functions
> > depending on whether you want to precompute the infoframes or not.
> > The names aren't greate but I was lazy and didn't want to change all the
>
> greate -> great
Thanks for reading through it. Fixed up all the crap you spotted.
>
> > drivers.
> >
> > v2: Deal with exynos churn
> > Actually export the new funcs
> >
> > Cc: Thierry Reding
> > Cc: Hans Verkuil
> > Cc: linux-me...@vger.kernel.org
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/video/hdmi.c | 425
> > +++
> > include/linux/hdmi.h | 19 ++-
> > 2 files changed, 416 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > index 53e7ee2c83fc..9507f668a569 100644
> > --- a/drivers/video/hdmi.c
> > +++ b/drivers/video/hdmi.c
> > @@ -68,8 +68,36 @@ int hdmi_avi_infoframe_init(struct hdmi_avi_infoframe
> > *frame)
> > }
> > EXPORT_SYMBOL(hdmi_avi_infoframe_init);
> >
> > +static int hdmi_avi_infoframe_check_only(const struct hdmi_avi_infoframe
> > *frame)
> > +{
> > + if (frame->type != HDMI_INFOFRAME_TYPE_AVI ||
> > + frame->version != 2 ||
> > + frame->length != HDMI_AVI_INFOFRAME_SIZE)
> > + return -EINVAL;
> > +
> > + if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > /**
> > - * hdmi_avi_infoframe_pack() - write HDMI AVI infoframe to binary buffer
> > + * hdmi_avi_infoframe_check() - Check and check a HDMI AVI infoframe
>
> "Check and check"? This is repeated elsewhere as well (clearly
> copy-and-paste).
>
> > + * @frame: HDMI AVI infoframe
> > + *
> > + * Validates that the infoframe is consistent and updates derived fields
> > + * (eg. length) based on other fields.
> > + *
> > + * Returns 0 on success or a negative error code on failure.
> > + */
> > +int hdmi_avi_infoframe_check(struct hdmi_avi_infoframe *frame)
> > +{
> > + return hdmi_avi_infoframe_check_only(frame);
> > +}
> > +EXPORT_SYMBOL(hdmi_avi_infoframe_check);
> > +
> > +/**
> > + * hdmi_avi_infoframe_pack_only() - write HDMI AVI infoframe to binary
> > buffer
> > * @frame: HDMI AVI infoframe
> > * @buffer: destination buffer
> > * @size: size of buffer
> > @@ -82,20 +110,22 @@ EXPORT_SYMBOL(hdmi_avi_infoframe_init);
> > * Returns the number of bytes packed into the binary buffer or a negative
> > * error code on failure.
> > */
> > -ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame, void
> > *buffer,
> > - size_t size)
> > +ssize_t hdmi_avi_infoframe_pack_only(const struct hdmi_avi_infoframe
> > *frame,
> > +void *buffer, size_t size)
> > {
> > u8 *ptr = buffer;
> > size_t length;
> > + int ret;
> > +
> > + ret = hdmi_avi_infoframe_check_only(frame);
> > + if (ret)
> > + return ret;
> >
> > length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> >
> > if (size < length)
> > return -ENOSPC;
> >
> > - if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
> > - return -EINVAL;
> > -
> > memset(buffer, 0, size);
> >
> > ptr[0] = frame->type;
> > @@ -152,6 +182,36 @@ ssize_t hdmi_avi_infoframe_pack(struct
> > hdmi_avi_infoframe *frame, void *buffer,
> >
> > return length;
> > }
> > +EXPORT_SYMBOL(hdmi_avi_infoframe_pack_only);
> > +
> > +/**
> > + * hdmi_avi_infoframe_pack() - Check and check a HDMI AVI infoframe,
> > + * and write it to binary buffer
> > + * @frame: HDMI AVI infoframe
> > + * @buffer: destination buffer
> > + * @size: size of buffer
> > + *
> > + * Validates that the infoframe is consistent and updates derived fields
> > + * (eg. length) based on other fields, after which packs the information
>
> which packs -> which it packs
>
> Ditto elsewhere.
>
> > + * contained in the @frame structure into a binary representation that
> > + * can be written into the corresponding controller registers. Also
>
> Also -> This function also
>
> Ditto elsewhere.
>
> > + * computes the checksum as required by section 5.3.5 of the HDMI 1.4
> > + * specification.
> > + *
> > + * Returns the number of bytes packed into the binary buffer or a negative
> > + * error code on failure.
> > + */
> > +ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame,
> > + void *buffer, size_t size)
> > +{
> > + int ret;
> > +
> > + ret = hdmi_avi_infoframe_check(frame);
> > + if (ret)
> > + return ret;
> >
Re: [PATCH 07/18] video/hdmi: Handle the NTSC VBI infoframe
On Fri, Sep 21, 2018 at 10:30:16AM +0200, Hans Verkuil wrote:
> On 09/20/18 20:51, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add the code to deal with the NTSC VBI infoframe.
> >
> > I decided against parsing the PES_data_field and just leave
> > it as an opaque blob, just dumping it out as hex in the log.
> >
> > Blindly typed from the spec, and totally untested.
>
> Do we have any driver that uses this? I would prefer to wait until someone
> actually need this.
No users that I know of. So totally fine with me to leave it out.
>
> Regards,
>
> Hans
>
> >
> > Cc: Thierry Reding
> > Cc: Hans Verkuil
> > Cc: linux-me...@vger.kernel.org
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/video/hdmi.c | 208
> > +++
> > include/linux/hdmi.h | 18 +
> > 2 files changed, 226 insertions(+)
> >
> > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > index 3d24c7746c51..3c320d69fa0a 100644
> > --- a/drivers/video/hdmi.c
> > +++ b/drivers/video/hdmi.c
> > @@ -831,6 +831,139 @@ ssize_t hdmi_mpeg_source_infoframe_pack(struct
> > hdmi_mpeg_source_infoframe *frame
> > }
> > EXPORT_SYMBOL(hdmi_mpeg_source_infoframe_pack);
> >
> > +/**
> > + * hdmi_ntsc_vbi_infoframe_init() - initialize an HDMI NTSC VBI infoframe
> > + * @frame: HDMI NTSC VBI infoframe
> > + * @pes_data_field: ANSI/SCTE 127 PES_data_field
> > + * @length: ANSI/SCTE 127 PES_data_field length
> > + *
> > + * Returns 0 on success or a negative error code on failure.
> > + */
> > +int hdmi_ntsc_vbi_infoframe_init(struct hdmi_ntsc_vbi_infoframe *frame,
> > +const void *pes_data_field,
> > +size_t length)
> > +{
> > + if (length < 1 || length > 27)
> > + return -EINVAL;
> > +
> > + memset(frame, 0, sizeof(*frame));
> > +
> > + frame->type = HDMI_INFOFRAME_TYPE_NTSC_VBI;
> > + frame->version = 1;
> > + frame->length = length;
> > +
> > + memcpy(frame->pes_data_field, pes_data_field, length);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_init);
> > +
> > +static int hdmi_ntsc_vbi_infoframe_check_only(const struct
> > hdmi_ntsc_vbi_infoframe *frame)
> > +{
> > + if (frame->type != HDMI_INFOFRAME_TYPE_NTSC_VBI ||
> > + frame->version != 1 ||
> > + frame->length < 1 || frame->length > 27)
> > + return -EINVAL;
> > +
> > + if (frame->pes_data_field[0] != 0x99)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * hdmi_ntsc_vbi_infoframe_check() - Check and check a HDMI NTSC VBI
> > infoframe
> > + * @frame: HDMI NTSC VBI infoframe
> > + *
> > + * Validates that the infoframe is consistent and updates derived fields
> > + * (eg. length) based on other fields.
> > + *
> > + * Returns 0 on success or a negative error code on failure.
> > + */
> > +int hdmi_ntsc_vbi_infoframe_check(struct hdmi_ntsc_vbi_infoframe *frame)
> > +{
> > + return hdmi_ntsc_vbi_infoframe_check_only(frame);
> > +}
> > +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_check);
> > +
> > +/**
> > + * hdmi_ntsc_vbi_infoframe_pack_only() - write HDMI NTSC VBI infoframe to
> > binary buffer
> > + * @frame: HDMI NTSC VBI infoframe
> > + * @buffer: destination buffer
> > + * @size: size of buffer
> > + *
> > + * Packs the information contained in the @frame structure into a binary
> > + * representation that can be written into the corresponding controller
> > + * registers. Also computes the checksum as required by section 5.3.5 of
> > + * the HDMI 1.4 specification.
> > + *
> > + * Returns the number of bytes packed into the binary buffer or a negative
> > + * error code on failure.
> > + */
> > +ssize_t hdmi_ntsc_vbi_infoframe_pack_only(const struct
> > hdmi_ntsc_vbi_infoframe *frame,
> > + void *buffer, size_t size)
> > +{
> > + u8 *ptr = buffer;
> > + size_t length;
> > + int ret;
> > +
> > + ret = hdmi_ntsc_vbi_infoframe_check_only(frame);
> > + if (ret)
> > + return ret;
> > +
> > + length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> > +
> > + if (size < length)
> > + return -ENOSPC;
> > +
> > + memset(buffer, 0, size);
> > +
> > + ptr[0] = frame->type;
> > + ptr[1] = frame->version;
> > + ptr[2] = frame->length;
> > + ptr[3] = 0; /* checksum */
> > +
> > + /* start infoframe payload */
> > + ptr += HDMI_INFOFRAME_HEADER_SIZE;
> > +
> > + memcpy(ptr, frame->pes_data_field, frame->length);
> > +
> > + hdmi_infoframe_set_checksum(buffer, length);
> > +
> > + return length;
> > +}
> > +EXPORT_SYMBOL(hdmi_ntsc_vbi_infoframe_pack_only);
> > +
> > +/**
> > + * hdmi_ntsc_vbi_infoframe_pack() - Check and check a HDMI NTSC VBI
> > infoframe,
> > + * and write it to binary buffer
> > + * @frame: HDMI NTSC VBI infoframe
> > + * @buffer: destination buffer
> > + * @size: size of buffer
> > + *
> > + * Validates that the
Re: [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types
On 09/21/18 16:01, Ville Syrjälä wrote:
> On Fri, Sep 21, 2018 at 10:41:46AM +0200, Hans Verkuil wrote:
>> On 09/20/18 20:51, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> We'll be wanting to send more than just infoframes over HDMI. So add an
>>> enum for other packet types.
>>>
>>> TODO: Maybe just include the infoframe types in the packet type enum
>>> and get rid of the infoframe type enum?
>>
>> I think that's better, IMHO. With a comment that the types starting with
>> 0x81 are defined in CTA-861-G.
>>
>> It's really the same byte that is being checked, so having two enums is
>> a bit misleading. The main difference is really which standard defines
>> the packet types.
>
> Right. The only slight annoyance is that we'll get a bunch of warnings
> from the compiler if we don't handle all the enum valus in the switch
> statements. If we want to avoid that I guess I could limit this
> to just the null, gcp and gamut metadata packets initially and try to
> write some actual code for them. Those three are the only ones we
> care about in i915 at the moment.
Note that I don't have a terribly strong opinion on this, so if using
one enum instead of two causes more problems than it is worth, then
that's fine with me as well.
But you asked, and given a choice with all other things being equal,
then one enum has my preference.
Regards,
Hans
>
>>
>> Regards,
>>
>> Hans
>>
>>>
>>> Cc: Thierry Reding
>>> Cc: Hans Verkuil
>>> Cc: linux-me...@vger.kernel.org
>>> Signed-off-by: Ville Syrjälä
>>> ---
>>> include/linux/hdmi.h | 15 +++
>>> 1 file changed, 15 insertions(+)
>>>
>>> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
>>> index c76b50a48e48..80521d9591a1 100644
>>> --- a/include/linux/hdmi.h
>>> +++ b/include/linux/hdmi.h
>>> @@ -27,6 +27,21 @@
>>> #include
>>> #include
>>>
>>> +enum hdmi_packet_type {
>>> + HDMI_PACKET_TYPE_NULL = 0x00,
>>> + HDMI_PACKET_TYPE_AUDIO_CLOCK_REGEN = 0x01,
>>> + HDMI_PACKET_TYPE_AUDIO_SAMPLE = 0x02,
>>> + HDMI_PACKET_TYPE_GENERAL_CONTROL = 0x03,
>>> + HDMI_PACKET_TYPE_AUDIO_CP = 0x04,
>>> + HDMI_PACKET_TYPE_ISRC1 = 0x05,
>>> + HDMI_PACKET_TYPE_ISRC2 = 0x06,
>>> + HDMI_PACKET_TYPE_ONE_BIT_AUDIO_SAMPLE = 0x07,
>>> + HDMI_PACKET_TYPE_DST_AUDIO = 0x08,
>>> + HDMI_PACKET_TYPE_HBR_AUDIO_STREAM = 0x09,
>>> + HDMI_PACKET_TYPE_GAMUT_METADATA = 0x0a,
>>> + /* + enum hdmi_infoframe_type */
>>> +};
>>> +
>>> enum hdmi_infoframe_type {
>>> HDMI_INFOFRAME_TYPE_VENDOR = 0x81,
>>> HDMI_INFOFRAME_TYPE_AVI = 0x82,
>>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
