Re: [PATCH 3/4] dma-fence: Refactor signaling for manual invocation
Am 12.08.19 um 16:53 schrieb Chris Wilson: > Quoting Koenig, Christian (2019-08-12 15:50:59) >> Am 12.08.19 um 16:43 schrieb Chris Wilson: >>> Quoting Koenig, Christian (2019-08-12 15:34:32) Am 10.08.19 um 17:34 schrieb Chris Wilson: > Move the duplicated code within dma-fence.c into the header for wider > reuse. In the process apply a small micro-optimisation to only prune the > fence->cb_list once rather than use list_del on every entry. > > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin > --- > drivers/dma-buf/Makefile| 10 +- > drivers/dma-buf/dma-fence-trace.c | 28 +++ > drivers/dma-buf/dma-fence.c | 33 +-- > drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 32 +-- > include/linux/dma-fence-impl.h | 83 +++ > include/linux/dma-fence-types.h | 258 > include/linux/dma-fence.h | 228 + Mhm, I don't really see the value in creating more header files. Especially I'm pretty sure that the types should stay in dma-fence.h >>> iirc, when I included the trace.h from dma-fence.h or dma-fence-impl.h >>> without separating the types, amdgpu failed to compile (which is more >>> than likely to be simply due to be first drm in the list to compile). >> Ah, but why do you want to include trace.h in a header in the first place? >> >> That's usually not something I would recommend either. > The problem is that we do emit a tracepoint as part of the sequence I > want to put into the reusable chunk of code. Ok, we are going in circles here. Why do you want to reuse the code then? Christian. > -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111390] [CI][SHARDS] igt@kms_* - dmesg-warn - KSV list failed to become ready (-110)
https://bugs.freedesktop.org/show_bug.cgi?id=111390 Bug ID: 111390 Summary: [CI][SHARDS] igt@kms_* - dmesg-warn - KSV list failed to become ready (-110) Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: martin.pe...@free.fr It seems like we are attempting to use HDCP in tests that do not need content protection: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5128/shard-apl7/igt@kms_pl...@plane-position-hole-dpms-pipe-b-planes.html <7> [1747.235381] [drm:intel_hdcp_auth [i915]] KSV list failed to become ready (-110) <7> [1747.235601] [drm:_intel_hdcp_enable [i915]] HDCP Auth failure (-110) <7> [1747.235754] [drm:_intel_hdcp_disable [i915]] [DP-1:100] HDCP is being disabled... <7> [1747.238782] [drm:_intel_hdcp_disable [i915]] HDCP is disabled Please make sure HDCP is disabled in KMS tests which are not content-protection related. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111390] [CI][SHARDS] igt@kms_* - dmesg-warn - KSV list failed to become ready (-110)
https://bugs.freedesktop.org/show_bug.cgi?id=111390 Martin Peres changed: What|Removed |Added Whiteboard||ReadyForDev Assignee|dri-devel@lists.freedesktop |ramalinga...@intel.com |.org| Priority|medium |high -- 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 26/60] drm/omap: Detach from panels at remove time
On 07/07/2019 21:19, Laurent Pinchart wrote: The omapdrm driver attaches to panels with drm_panel_attach() at probe time but never calls drm_panel_detach(). Fix it. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/omapdrm/omap_drv.c | 24 +++- 1 file changed, 19 insertions(+), 5 deletions(-) drm_panel_detach() is called in omap_disconnect_pipelines(). Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 27/60] drm/omap: Simplify HDMI mode and infoframe configuration
On 07/07/2019 21:19, Laurent Pinchart wrote: Remove the omap_connector_get_hdmi_mode() function as the HDMI mode can be accessed directly from the connector's display info. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/omapdrm/omap_connector.c | 11 --- drivers/gpu/drm/omapdrm/omap_connector.h | 1 - drivers/gpu/drm/omapdrm/omap_encoder.c | 4 +--- 3 files changed, 1 insertion(+), 15 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH] drm/xen-front: Make structure fb_funcs constant
On 8/13/19 9:27 AM, Nishka Dasgupta wrote:
Static structure fb_funcs, of type drm_framebuffer_funcs, is used only
when it is passed to drm_gem_fb_create_with_funcs() as its last
argument. drm_gem_fb_create_with_funcs does not modify its lst argument
(fb_funcs) and hence fb_funcs is never modified. Therefore make fb_funcs
constant to protect it from further modification.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index c2955d375394..4a984f4e 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -45,7 +45,7 @@ static void fb_destroy(struct drm_framebuffer *fb)
drm_gem_fb_destroy(fb);
}
-static struct drm_framebuffer_funcs fb_funcs = {
+static const struct drm_framebuffer_funcs fb_funcs = {
.destroy = fb_destroy,
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 28/60] drm/omap: Factor out display type to connector type conversion
On 07/07/2019 21:19, Laurent Pinchart wrote:
Move the code that computes the DRM connector type for the
omapdss_device display type to a new omapdss_device_connector_type()
function for later reuse.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c | 23 +++
drivers/gpu/drm/omapdrm/dss/omapdss.h| 1 +
drivers/gpu/drm/omapdrm/omap_connector.c | 19 +--
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/base.c
b/drivers/gpu/drm/omapdrm/dss/base.c
index a1970b9db6ab..cae5687822e2 100644
--- a/drivers/gpu/drm/omapdrm/dss/base.c
+++ b/drivers/gpu/drm/omapdrm/dss/base.c
@@ -285,6 +285,29 @@ void omapdss_device_post_disable(struct omap_dss_device
*dssdev)
}
EXPORT_SYMBOL_GPL(omapdss_device_post_disable);
+unsigned int omapdss_device_connector_type(enum omap_display_type type)
+{
+ switch (type) {
+ case OMAP_DISPLAY_TYPE_HDMI:
+ return DRM_MODE_CONNECTOR_HDMIA;
+ case OMAP_DISPLAY_TYPE_DVI:
+ return DRM_MODE_CONNECTOR_DVID;
+ case OMAP_DISPLAY_TYPE_DSI:
+ return DRM_MODE_CONNECTOR_DSI;
+ case OMAP_DISPLAY_TYPE_DPI:
+ case OMAP_DISPLAY_TYPE_DBI:
+ return DRM_MODE_CONNECTOR_DPI;
+ case OMAP_DISPLAY_TYPE_VENC:
+ /* TODO: This could also be composite */
+ return DRM_MODE_CONNECTOR_SVIDEO;
+ case OMAP_DISPLAY_TYPE_SDI:
+ return DRM_MODE_CONNECTOR_LVDS;
+ default:
+ return DRM_MODE_CONNECTOR_Unknown;
+ }
+}
+EXPORT_SYMBOL_GPL(omapdss_device_connector_type);
Why do we need to export this? In the end enum omap_display_type should
go away or be private to omapdrm, right?
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 29/60] drm/omap: Use the drm_panel_bridge API
On 07/07/2019 21:19, Laurent Pinchart wrote: Replace the manual panel handling code by a drm_panel_bridge. This simplifies the driver and allows all components in the display pipeline to be treated as bridges, paving the way to generic connector handling. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/omapdrm/dss/base.c | 12 - drivers/gpu/drm/omapdrm/dss/output.c | 33 +--- drivers/gpu/drm/omapdrm/omap_connector.c | 9 --- drivers/gpu/drm/omapdrm/omap_drv.c | 13 -- drivers/gpu/drm/omapdrm/omap_encoder.c | 13 -- 5 files changed, 34 insertions(+), 46 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 30/60] drm/omap: dss: Fix output next device lookup in DT
On 07/07/2019 21:19, Laurent Pinchart wrote: The DSS core looks up the next device connected to an output by traversing the OF graph. It currently hardcodes the local port number to 0, which breaks any output with a different port number (SDI on OMAP3 and any DPI output but the first one). Fix this by repurposing the currently unused of_ports bitmask in omap_dss_device with an of_port output port number, and use it to traverse the OF graph. Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 31/60] drm/omap: Add infrastructure to support drm_bridge local to DSS outputs
On 07/07/2019 21:19, Laurent Pinchart wrote: In order to support drm_bridge-based pipeline, the internal HDMI encoders will need to expose the EDID read operation through the drm_bridge API, and thus to expose a drm_bridge instance corresponding to the encoder. The HDMI encoders are however handled as omap_dss_device instances, which conflicts with this requirement. In order to move forward with the drm_bridge transition, add support for creating drm_bridge instances local to DSS outputs. If a local bridge is passed to the omapdss_device_init_output() function, it is used as the first bridge in the chain, and the omap_dss_device.next_bridge field is set to the next bridge for the use of the internal encoders' bridges. Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 32/60] drm/omap: dss: Make omap_dss_device_ops optional
On 07/07/2019 21:19, Laurent Pinchart wrote: As part of the move to drm_bridge ops for some of the internal encoders will be removed. Make them optional in the driver to ease the transition. I don't seem to be able to decipher the first sentence. Is there a word or two missing from it? Other than that: Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 09/18] kunit: test: add support for test abort
On Mon, Aug 12, 2019 at 10:56 PM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-08-12 21:57:55)
> > On Mon, Aug 12, 2019 at 9:22 PM Stephen Boyd wrote:
> > >
> > > Quoting Brendan Higgins (2019-08-12 11:24:12)
> > > > diff --git a/include/kunit/test.h b/include/kunit/test.h
> > > > index 2625bcfeb19ac..93381f841e09f 100644
> > > > --- a/include/kunit/test.h
> > > > +++ b/include/kunit/test.h
> > > > @@ -176,6 +178,11 @@ struct kunit {
> > > > */
> > > > bool success; /* Read only after test_case finishes! */
> > > > spinlock_t lock; /* Gaurds all mutable test state. */
> > > > + /*
> > > > +* death_test may be both set and unset from multiple threads
> > > > in a test
> > > > +* case.
> > > > +*/
> > > > + bool death_test; /* Protected by lock. */
> > > > /*
> > > > * Because resources is a list that may be updated multiple
> > > > times (with
> > > > * new resources) from any thread associated with a test case,
> > > > we must
> > > > @@ -184,6 +191,13 @@ struct kunit {
> > > > struct list_head resources; /* Protected by lock. */
> > > > };
> > > >
> > > > +static inline void kunit_set_death_test(struct kunit *test, bool
> > > > death_test)
> > > > +{
> > > > + spin_lock(&test->lock);
> > > > + test->death_test = death_test;
> > > > + spin_unlock(&test->lock);
> > > > +}
> > >
> > > These getters and setters are using spinlocks again. It doesn't make any
> > > sense. It probably needs a rework like was done for the other bool
> > > member, success.
> >
> > No, this is intentional. death_test can transition from false to true
> > and then back to false within the same test. Maybe that deserves a
> > comment?
>
> Yes. How does it transition from true to false again?
The purpose is to tell try_catch that it was expected for the test to
bail out. Given the default implementation there is no way for this to
happen aside from abort() being called, but in some implementations it
is possible to implement a fault catcher which allows a test suite to
recover from an unexpected failure.
Maybe it would be best to drop this until I add one of those
alternative implementations.
> Either way, having a spinlock around a read/write API doesn't make sense
> because it just makes sure that two writes don't overlap, but otherwise
> does nothing to keep things synchronized. For example a set to true
> after a set to false when the two calls to set true or false aren't
> synchronized means they can happen in any order. So I don't see how it
> needs a spinlock. The lock needs to be one level higher.
There shouldn't be any cases where one thread is trying to set it
while another is trying to unset it. The thing I am worried about here
is making sure all the cores see the write, and making sure no reads
or writes get reordered before it. So I guess I just want a fence. So
I take it I should probably have is a WRITE_ONCE here and READ_ONCE in
the getter?
> >
> > > > +
> > > > void kunit_init_test(struct kunit *test, const char *name);
> > > >
> > > > int kunit_run_tests(struct kunit_suite *suite);
> > > > diff --git a/include/kunit/try-catch.h b/include/kunit/try-catch.h
> > > > new file mode 100644
> > > > index 0..8a414a9af0b64
> > > > --- /dev/null
> > > > +++ b/include/kunit/try-catch.h
> [...]
> > > > +
> > > > +/*
> > > > + * struct kunit_try_catch - provides a generic way to run code which
> > > > might fail.
> > > > + * @context: used to pass user data to the try and catch functions.
> > > > + *
> > > > + * kunit_try_catch provides a generic, architecture independent way to
> > > > execute
> > > > + * an arbitrary function of type kunit_try_catch_func_t which may bail
> > > > out by
> > > > + * calling kunit_try_catch_throw(). If kunit_try_catch_throw() is
> > > > called, @try
> > > > + * is stopped at the site of invocation and @catch is catch is called.
> > > > + *
> > > > + * struct kunit_try_catch provides a generic interface for the
> > > > functionality
> > > > + * needed to implement kunit->abort() which in turn is needed for
> > > > implementing
> > > > + * assertions. Assertions allow stating a precondition for a test
> > > > simplifying
> > > > + * how test cases are written and presented.
> > > > + *
> > > > + * Assertions are like expectations, except they abort (call
> > > > + * kunit_try_catch_throw()) when the specified condition is not met.
> > > > This is
> > > > + * useful when you look at a test case as a logical statement about
> > > > some piece
> > > > + * of code, where assertions are the premises for the test case, and
> > > > the
> > > > + * conclusion is a set of predicates, rather expectations, that must
> > > > all be
> > > > + * true. If your premises are violated, it does not makes sense to
> > > > continue.
> > > > + */
> > > > +struct kunit_try_catch {
> > > > + /* private: internal use only. */
> > > > + struct kunit *test;
Re: [PATCH 33/60] drm/omap: hdmi: Allocate EDID in the .read_edid() operation
On 07/07/2019 21:19, Laurent Pinchart wrote:
Bring the omapdss-specific .read_edid() operation in sync with the
drm_bridge .get_edid() operation to ease code reuse.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 34
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 22 ++-
drivers/gpu/drm/omapdrm/dss/omapdss.h| 2 +-
drivers/gpu/drm/omapdrm/omap_connector.c | 12 +++--
4 files changed, 43 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index 0a0bda7f686f..f0586108b41e 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -416,31 +416,43 @@ static void hdmi_disconnect(struct omap_dss_device *src,
omapdss_device_disconnect(dst, dst->next);
}
-static int hdmi_read_edid(struct omap_dss_device *dssdev,
- u8 *edid, int len)
+static struct edid *hdmi_read_edid(struct omap_dss_device *dssdev)
{
struct omap_hdmi *hdmi = dssdev_to_hdmi(dssdev);
bool need_enable;
+ u8 *edid;
int r;
+ edid = kzalloc(512, GFP_KERNEL);
512 bytes is enough for everyone? =)
Maybe still keep it as a define for clarity?
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 10/18] kunit: test: add tests for kunit test abort
On Mon, Aug 12, 2019 at 10:57 PM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-08-12 22:06:04)
> > On Mon, Aug 12, 2019 at 9:24 PM Stephen Boyd wrote:
> > >
> > > Quoting Brendan Higgins (2019-08-12 11:24:13)
> > > > +
> > > > +static int kunit_try_catch_test_init(struct kunit *test)
> > > > +{
> > > > + struct kunit_try_catch_test_context *ctx;
> > > > +
> > > > + ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
> > >
> > > Can this fail? Should return -ENOMEM in that case?
> >
> > Yes, I should do that.
>
> Looks like it's asserted to not be an error. If it's pushed into the API
> then there's nothing to do here, and you can have my reviewed-by on this
> patch.
>
> Reviewed-by: Stephen Boyd
Cool, thanks!
Re: [PATCH] drm/vboxvideo: Make structure vbox_fb_helper_funcs constant
Hi,
On 13-08-19 08:25, Nishka Dasgupta wrote:
The static structure vbox_fb_helper_funcs, of type drm_fb_helper_funcs,
is used only when it is passed as the third argument to
drm_fb_helper_fbdev_setup(), which does not modify it. Hence make it
constant to protect it from unintended modifications.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
Thank you for the patch, this looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/vboxvideo/vbox_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index 02537ab9cc08..2b57ea3195f2 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -32,7 +32,7 @@ static const struct pci_device_id pciidlist[] = {
};
MODULE_DEVICE_TABLE(pci, pciidlist);
-static struct drm_fb_helper_funcs vbox_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs vbox_fb_helper_funcs = {
.fb_probe = vboxfb_create,
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 12/18] kunit: test: add tests for KUnit managed resources
On Mon, Aug 12, 2019 at 9:31 PM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-08-12 11:24:15)
> > +
> > +static int kunit_resource_test_init(struct kunit *test)
> > +{
> > + struct kunit_test_resource_context *ctx =
> > + kzalloc(sizeof(*ctx), GFP_KERNEL);
> > +
> > + if (!ctx)
> > + return -ENOMEM;
>
> Should this use the test assertion logic to make sure that it's not
> failing allocations during init?
Yep. Will fix.
> BTW, maybe kunit allocation APIs should
> fail the test if they fail to allocate in general. Unless we're unit
> testing failure to allocate problems.
Yeah, I thought about that. I wasn't sure how people would feel about
it, and I thought it would be a pain to tease out all the issues
arising from aborting in different contexts when someone might not
expect it.
I am thinking later we can have kunit_kmalloc_or_abort variants? And
then we can punt this issue to a later time?
> > +
> > + test->priv = ctx;
> > +
> > + kunit_init_test(&ctx->test, "test_test_context");
> > +
> > + return 0;
RE: [PATCH] drm/scheduler: use job count instead of peek
Reviewed-by: monk@amd.com
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Christian König
Sent: Friday, August 9, 2019 11:31 PM
To: Grodzovsky, Andrey ;
dri-devel@lists.freedesktop.org; Liu, Monk ; Deng, Emily
Subject: [PATCH] drm/scheduler: use job count instead of peek
The spsc_queue_peek function is accessing queue->head which belongs to the
consumer thread and shouldn't be accessed by the producer
This is fixing a rare race condition when destroying entities.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 35ddbec1375a..671c90f34ede 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -95,7 +95,7 @@ static bool drm_sched_entity_is_idle(struct drm_sched_entity
*entity)
rmb(); /* for list_empty to work without lock */
if (list_empty(&entity->list) ||
- spsc_queue_peek(&entity->job_queue) == NULL)
+ spsc_queue_count(&entity->job_queue) == 0)
return true;
return false;
@@ -281,7 +281,7 @@ void drm_sched_entity_fini(struct drm_sched_entity *entity)
/* Consumption of existing IBs wasn't completed. Forcefully
* remove them here.
*/
- if (spsc_queue_peek(&entity->job_queue)) {
+ if (spsc_queue_count(&entity->job_queue)) {
if (sched) {
/* Park the kernel for a moment to make sure it isn't
processing
* our enity.
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 14/18] kunit: defconfig: add defconfigs for building KUnit tests
On Mon, Aug 12, 2019 at 9:39 PM Stephen Boyd wrote: > > Quoting Brendan Higgins (2019-08-12 11:24:17) > > diff --git a/arch/um/configs/kunit_defconfig > > b/arch/um/configs/kunit_defconfig > > new file mode 100644 > > index 0..bfe49689038f1 > > --- /dev/null > > +++ b/arch/um/configs/kunit_defconfig > > @@ -0,0 +1,8 @@ > > +CONFIG_OF=y > > +CONFIG_OF_UNITTEST=y > > +CONFIG_OF_OVERLAY=y > > +CONFIG_I2C=y > > +CONFIG_I2C_MUX=y > > +CONFIG_KUNIT=y > > +CONFIG_KUNIT_TEST=y > > +CONFIG_KUNIT_EXAMPLE_TEST=y > > diff --git a/tools/testing/kunit/configs/all_tests.config > > b/tools/testing/kunit/configs/all_tests.config > > new file mode 100644 > > index 0..bfe49689038f1 > > --- /dev/null > > +++ b/tools/testing/kunit/configs/all_tests.config > > @@ -0,0 +1,8 @@ > > +CONFIG_OF=y > > +CONFIG_OF_UNITTEST=y > > +CONFIG_OF_OVERLAY=y > > +CONFIG_I2C=y > > +CONFIG_I2C_MUX=y > > Are these above config options necessary? I don't think they're part of > the patch series anymore so it looks odd to enable the OF unittests and > i2c configs. Oh whoops, I forgot that we dropped the OF_UNITTEST from this patchset. Will fix. > > +CONFIG_KUNIT=y > > +CONFIG_KUNIT_TEST=y > > +CONFIG_KUNIT_EXAMPLE_TEST=y ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] arm64: imx8mq: add imx8mq iomux-gpr field defines
On Fri, Aug 9, 2019 at 6:24 PM Guido Günther wrote: > > This adds all the gpr registers and the define needed for selecting > the input source in the imx-nwl drm bridge. > > Signed-off-by: Guido Günther > + > +#define IOMUXC_GPR00x00 > +#define IOMUXC_GPR10x04 > +#define IOMUXC_GPR20x08 > +#define IOMUXC_GPR30x0c > +#define IOMUXC_GPR40x10 > +#define IOMUXC_GPR50x14 > +#define IOMUXC_GPR60x18 > +#define IOMUXC_GPR70x1c (more of the same) huh? > +/* i.MX8Mq iomux gpr register field defines */ > +#define IMX8MQ_GPR13_MIPI_MUX_SEL BIT(2) I think this define should probably be local to the pinctrl driver, to ensure that no other drivers fiddle with the registers manually. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111122] 2500U: Graphics corruption on kernel 5.2
https://bugs.freedesktop.org/show_bug.cgi?id=22 --- Comment #16 from Pierre-Eric Pelloux-Prayer --- (In reply to Brian Schott from comment #13) > (In reply to Pierre-Eric Pelloux-Prayer from comment #12) > > Does using "AMD_DEBUG=nodcc" Mesa environment variable help? > > It does. Exporting that in my ~/.profile makes the desktop usable. > Let's focus on this issue first. Can you paste the output of: "AMD_DEBUG=info glxgears" please? And would you be able to test other versions of Mesa to see if your issue could be bisected (if it happens to be a Mesa problem)? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110886] After S3 resume, kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:57:crtc-0] flip_done timed out
https://bugs.freedesktop.org/show_bug.cgi?id=110886 --- Comment #6 from Kai-Heng Feng --- Created attachment 145044 --> https://bugs.freedesktop.org/attachment.cgi?id=145044&action=edit failed log when iommu is disabled. -- 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 1/2] drm/virtio: cleanup queue functions
Make the queue functions return void, none of
the call sites checks the return value.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 41 ++---
1 file changed, 14 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 7ac20490e1b4..ca91e83ffaef 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -252,8 +252,8 @@ void virtio_gpu_dequeue_cursor_func(struct work_struct
*work)
wake_up(&vgdev->cursorq.ack_queue);
}
-static int virtio_gpu_queue_ctrl_buffer_locked(struct virtio_gpu_device *vgdev,
- struct virtio_gpu_vbuffer *vbuf)
+static void virtio_gpu_queue_ctrl_buffer_locked(struct virtio_gpu_device
*vgdev,
+ struct virtio_gpu_vbuffer *vbuf)
__releases(&vgdev->ctrlq.qlock)
__acquires(&vgdev->ctrlq.qlock)
{
@@ -263,7 +263,7 @@ static int virtio_gpu_queue_ctrl_buffer_locked(struct
virtio_gpu_device *vgdev,
int ret;
if (!vgdev->vqs_ready)
- return -ENODEV;
+ return;
sg_init_one(&vcmd, vbuf->buf, vbuf->size);
sgs[outcnt + incnt] = &vcmd;
@@ -294,30 +294,22 @@ static int virtio_gpu_queue_ctrl_buffer_locked(struct
virtio_gpu_device *vgdev,
virtqueue_kick(vq);
}
-
- if (!ret)
- ret = vq->num_free;
- return ret;
}
-static int virtio_gpu_queue_ctrl_buffer(struct virtio_gpu_device *vgdev,
- struct virtio_gpu_vbuffer *vbuf)
+static void virtio_gpu_queue_ctrl_buffer(struct virtio_gpu_device *vgdev,
+struct virtio_gpu_vbuffer *vbuf)
{
- int rc;
-
spin_lock(&vgdev->ctrlq.qlock);
- rc = virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf);
+ virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf);
spin_unlock(&vgdev->ctrlq.qlock);
- return rc;
}
-static int virtio_gpu_queue_fenced_ctrl_buffer(struct virtio_gpu_device *vgdev,
- struct virtio_gpu_vbuffer *vbuf,
- struct virtio_gpu_ctrl_hdr *hdr,
- struct virtio_gpu_fence *fence)
+static void virtio_gpu_queue_fenced_ctrl_buffer(struct virtio_gpu_device
*vgdev,
+ struct virtio_gpu_vbuffer *vbuf,
+ struct virtio_gpu_ctrl_hdr *hdr,
+ struct virtio_gpu_fence *fence)
{
struct virtqueue *vq = vgdev->ctrlq.vq;
- int rc;
again:
spin_lock(&vgdev->ctrlq.qlock);
@@ -338,13 +330,12 @@ static int virtio_gpu_queue_fenced_ctrl_buffer(struct
virtio_gpu_device *vgdev,
if (fence)
virtio_gpu_fence_emit(vgdev, hdr, fence);
- rc = virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf);
+ virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf);
spin_unlock(&vgdev->ctrlq.qlock);
- return rc;
}
-static int virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
- struct virtio_gpu_vbuffer *vbuf)
+static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_vbuffer *vbuf)
{
struct virtqueue *vq = vgdev->cursorq.vq;
struct scatterlist *sgs[1], ccmd;
@@ -352,7 +343,7 @@ static int virtio_gpu_queue_cursor(struct virtio_gpu_device
*vgdev,
int outcnt;
if (!vgdev->vqs_ready)
- return -ENODEV;
+ return;
sg_init_one(&ccmd, vbuf->buf, vbuf->size);
sgs[0] = &ccmd;
@@ -374,10 +365,6 @@ static int virtio_gpu_queue_cursor(struct
virtio_gpu_device *vgdev,
}
spin_unlock(&vgdev->cursorq.qlock);
-
- if (!ret)
- ret = vq->num_free;
- return ret;
}
/* just create gem objects for userspace and long lived objects,
--
2.18.1
[PATCH 0/2] drm/virtio: notify virtqueues without holding spinlock
Gerd Hoffmann (2): drm/virtio: cleanup queue functions drm/virtio: notify virtqueues without holding spinlock drivers/gpu/drm/virtio/virtgpu_vq.c | 54 ++--- 1 file changed, 27 insertions(+), 27 deletions(-) -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/virtio: notify virtqueues without holding spinlock
Split virtqueue_kick() call into virtqueue_kick_prepare(), which
requires serialization, and virtqueue_notify(), which does not. Move
the virtqueue_notify() call out of the critical section protected by the
queue lock. This avoids triggering a vmexit while holding the lock and
thereby fixes a rather bad spinlock contention.
Suggested-by: Chia-I Wu
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index ca91e83ffaef..e41c96143342 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -252,7 +252,7 @@ void virtio_gpu_dequeue_cursor_func(struct work_struct
*work)
wake_up(&vgdev->cursorq.ack_queue);
}
-static void virtio_gpu_queue_ctrl_buffer_locked(struct virtio_gpu_device
*vgdev,
+static bool virtio_gpu_queue_ctrl_buffer_locked(struct virtio_gpu_device
*vgdev,
struct virtio_gpu_vbuffer *vbuf)
__releases(&vgdev->ctrlq.qlock)
__acquires(&vgdev->ctrlq.qlock)
@@ -260,10 +260,11 @@ static void virtio_gpu_queue_ctrl_buffer_locked(struct
virtio_gpu_device *vgdev,
struct virtqueue *vq = vgdev->ctrlq.vq;
struct scatterlist *sgs[3], vcmd, vout, vresp;
int outcnt = 0, incnt = 0;
+ bool notify = false;
int ret;
if (!vgdev->vqs_ready)
- return;
+ return notify;
sg_init_one(&vcmd, vbuf->buf, vbuf->size);
sgs[outcnt + incnt] = &vcmd;
@@ -292,16 +293,21 @@ static void virtio_gpu_queue_ctrl_buffer_locked(struct
virtio_gpu_device *vgdev,
trace_virtio_gpu_cmd_queue(vq,
(struct virtio_gpu_ctrl_hdr *)vbuf->buf);
- virtqueue_kick(vq);
+ notify = virtqueue_kick_prepare(vq);
}
+ return notify;
}
static void virtio_gpu_queue_ctrl_buffer(struct virtio_gpu_device *vgdev,
struct virtio_gpu_vbuffer *vbuf)
{
+ bool notify;
+
spin_lock(&vgdev->ctrlq.qlock);
- virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf);
+ notify = virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf);
spin_unlock(&vgdev->ctrlq.qlock);
+ if (notify)
+ virtqueue_notify(vgdev->ctrlq.vq);
}
static void virtio_gpu_queue_fenced_ctrl_buffer(struct virtio_gpu_device
*vgdev,
@@ -310,6 +316,7 @@ static void virtio_gpu_queue_fenced_ctrl_buffer(struct
virtio_gpu_device *vgdev,
struct virtio_gpu_fence *fence)
{
struct virtqueue *vq = vgdev->ctrlq.vq;
+ bool notify;
again:
spin_lock(&vgdev->ctrlq.qlock);
@@ -330,8 +337,10 @@ static void virtio_gpu_queue_fenced_ctrl_buffer(struct
virtio_gpu_device *vgdev,
if (fence)
virtio_gpu_fence_emit(vgdev, hdr, fence);
- virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf);
+ notify = virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf);
spin_unlock(&vgdev->ctrlq.qlock);
+ if (notify)
+ virtqueue_notify(vgdev->ctrlq.vq);
}
static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
@@ -339,6 +348,7 @@ static void virtio_gpu_queue_cursor(struct
virtio_gpu_device *vgdev,
{
struct virtqueue *vq = vgdev->cursorq.vq;
struct scatterlist *sgs[1], ccmd;
+ bool notify;
int ret;
int outcnt;
@@ -361,10 +371,13 @@ static void virtio_gpu_queue_cursor(struct
virtio_gpu_device *vgdev,
trace_virtio_gpu_cmd_queue(vq,
(struct virtio_gpu_ctrl_hdr *)vbuf->buf);
- virtqueue_kick(vq);
+ notify = virtqueue_kick_prepare(vq);
}
spin_unlock(&vgdev->cursorq.qlock);
+
+ if (notify)
+ virtqueue_notify(vq);
}
/* just create gem objects for userspace and long lived objects,
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] dma-fence: Refactor signaling for manual invocation
Quoting Koenig, Christian (2019-08-13 07:59:28) > Am 12.08.19 um 16:53 schrieb Chris Wilson: > > Quoting Koenig, Christian (2019-08-12 15:50:59) > >> Am 12.08.19 um 16:43 schrieb Chris Wilson: > >>> Quoting Koenig, Christian (2019-08-12 15:34:32) > Am 10.08.19 um 17:34 schrieb Chris Wilson: > > Move the duplicated code within dma-fence.c into the header for wider > > reuse. In the process apply a small micro-optimisation to only prune the > > fence->cb_list once rather than use list_del on every entry. > > > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > --- > > drivers/dma-buf/Makefile| 10 +- > > drivers/dma-buf/dma-fence-trace.c | 28 +++ > > drivers/dma-buf/dma-fence.c | 33 +-- > > drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 32 +-- > > include/linux/dma-fence-impl.h | 83 +++ > > include/linux/dma-fence-types.h | 258 > > > > include/linux/dma-fence.h | 228 + > Mhm, I don't really see the value in creating more header files. > > Especially I'm pretty sure that the types should stay in dma-fence.h > >>> iirc, when I included the trace.h from dma-fence.h or dma-fence-impl.h > >>> without separating the types, amdgpu failed to compile (which is more > >>> than likely to be simply due to be first drm in the list to compile). > >> Ah, but why do you want to include trace.h in a header in the first place? > >> > >> That's usually not something I would recommend either. > > The problem is that we do emit a tracepoint as part of the sequence I > > want to put into the reusable chunk of code. > > Ok, we are going in circles here. Why do you want to reuse the code then? I am reusing the code to avoid fun and games with signal-vs-free. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110886] After S3 resume, kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:57:crtc-0] flip_done timed out
https://bugs.freedesktop.org/show_bug.cgi?id=110886
--- Comment #7 from Kai-Heng Feng ---
I also tried disabling GFXOFF but the same issue still happens:
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index a24beaa4fb01..62a8394b1f5f 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -173,6 +173,7 @@ int hwmgr_early_init(struct pp_hwmgr *hwmgr)
case AMDGPU_FAMILY_RV:
switch (hwmgr->chip_id) {
case CHIP_RAVEN:
+ hwmgr->feature_mask &= ~PP_GFXOFF_MASK;
hwmgr->od_enabled = false;
hwmgr->smumgr_funcs = &smu10_smu_funcs;
smu10_init_function_pointers(hwmgr);
--
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 10/11] mfd: Drop obsolete JZ4740 driver
Hi Lee, On 8/12/19 10:16 AM, Lee Jones wrote: > On Thu, 25 Jul 2019, Paul Cercueil wrote: > >> It has been replaced with the ingenic-iio driver for the ADC. >> >> Signed-off-by: Paul Cercueil >> Tested-by: Artur Rojek >> --- >> drivers/mfd/Kconfig | 9 -- >> drivers/mfd/Makefile | 1 - >> drivers/mfd/jz4740-adc.c | 324 --- >> 3 files changed, 334 deletions(-) >> delete mode 100644 drivers/mfd/jz4740-adc.c > > Applied, thanks. It seems the replacement is done in "MIPS: qi_lb60: Migrate to devicetree" which is not yet merged. Probably easier if this patch goes thru the MIPS tree as part of the "JZ4740 SoC cleanup" series. Regards, Phil.
Re: [PATCH 3/4] dma-fence: Refactor signaling for manual invocation
Am 13.08.19 um 10:25 schrieb Chris Wilson: > Quoting Koenig, Christian (2019-08-13 07:59:28) >> Am 12.08.19 um 16:53 schrieb Chris Wilson: >>> Quoting Koenig, Christian (2019-08-12 15:50:59) Am 12.08.19 um 16:43 schrieb Chris Wilson: > Quoting Koenig, Christian (2019-08-12 15:34:32) >> Am 10.08.19 um 17:34 schrieb Chris Wilson: >>> Move the duplicated code within dma-fence.c into the header for wider >>> reuse. In the process apply a small micro-optimisation to only prune the >>> fence->cb_list once rather than use list_del on every entry. >>> >>> Signed-off-by: Chris Wilson >>> Cc: Tvrtko Ursulin >>> --- >>> drivers/dma-buf/Makefile| 10 +- >>> drivers/dma-buf/dma-fence-trace.c | 28 +++ >>> drivers/dma-buf/dma-fence.c | 33 +-- >>> drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 32 +-- >>> include/linux/dma-fence-impl.h | 83 +++ >>> include/linux/dma-fence-types.h | 258 >>> >>> include/linux/dma-fence.h | 228 + >> Mhm, I don't really see the value in creating more header files. >> >> Especially I'm pretty sure that the types should stay in dma-fence.h > iirc, when I included the trace.h from dma-fence.h or dma-fence-impl.h > without separating the types, amdgpu failed to compile (which is more > than likely to be simply due to be first drm in the list to compile). Ah, but why do you want to include trace.h in a header in the first place? That's usually not something I would recommend either. >>> The problem is that we do emit a tracepoint as part of the sequence I >>> want to put into the reusable chunk of code. >> Ok, we are going in circles here. Why do you want to reuse the code then? > I am reusing the code to avoid fun and games with signal-vs-free. Yeah, but that doesn't seems to be valid. See the dma_fence should more or less be a contained object and you now expose quite a bit of the internal functionality inside a headers. And creating headers which when included make other drivers fail to compile sounds like a rather bad idea to me. Please explain the background a bit more. Thanks, Christian. > -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/virtio: use virtio_max_dma_size
We must make sure our scatterlist segments are not too big, otherwise we might see swiotlb failures (happens with sev, also reproducable with swiotlb=force). Suggested-by: Laszlo Ersek Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_object.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index b2da31310d24..3d86e4b3de58 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -204,6 +204,7 @@ int virtio_gpu_object_get_sg_table(struct virtio_gpu_device *qdev, .interruptible = false, .no_wait_gpu = false }; + unsigned max_segment; /* wtf swapping */ if (bo->pages) @@ -215,8 +216,13 @@ int virtio_gpu_object_get_sg_table(struct virtio_gpu_device *qdev, if (!bo->pages) goto out; - ret = sg_alloc_table_from_pages(bo->pages, pages, nr_pages, 0, - nr_pages << PAGE_SHIFT, GFP_KERNEL); + max_segment = virtio_max_dma_size(qdev->vdev); + max_segment &= PAGE_MASK; + if (max_segment > SCATTERLIST_MAX_SEGMENT) + max_segment = SCATTERLIST_MAX_SEGMENT; + ret = __sg_alloc_table_from_pages(bo->pages, pages, nr_pages, 0, + nr_pages << PAGE_SHIFT, + max_segment, GFP_KERNEL); if (ret) goto out; return 0; -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] drm/virtio: use virtio_max_dma_size
We must make sure our scatterlist segments are not too big, otherwise we might see swiotlb failures (happens with sev, also reproducable with swiotlb=force). Suggested-by: Laszlo Ersek Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_object.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index b2da31310d24..09b526518f5a 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -204,6 +204,7 @@ int virtio_gpu_object_get_sg_table(struct virtio_gpu_device *qdev, .interruptible = false, .no_wait_gpu = false }; + size_t max_segment; /* wtf swapping */ if (bo->pages) @@ -215,8 +216,13 @@ int virtio_gpu_object_get_sg_table(struct virtio_gpu_device *qdev, if (!bo->pages) goto out; - ret = sg_alloc_table_from_pages(bo->pages, pages, nr_pages, 0, - nr_pages << PAGE_SHIFT, GFP_KERNEL); + max_segment = virtio_max_dma_size(qdev->vdev); + max_segment &= PAGE_MASK; + if (max_segment > SCATTERLIST_MAX_SEGMENT) + max_segment = SCATTERLIST_MAX_SEGMENT; + ret = __sg_alloc_table_from_pages(bo->pages, pages, nr_pages, 0, + nr_pages << PAGE_SHIFT, + max_segment, GFP_KERNEL); if (ret) goto out; return 0; -- 2.18.1
Re: [PATCH v12 03/18] kunit: test: add string_stream a std::stream like string builder
On Mon, Aug 12, 2019 at 10:30 PM Stephen Boyd wrote: > > Quoting Brendan Higgins (2019-08-12 22:02:59) > > On Mon, Aug 12, 2019 at 9:56 PM Stephen Boyd wrote: > > > > > > Quoting Brendan Higgins (2019-08-12 17:41:05) > > > > On Mon, Aug 12, 2019 at 4:59 PM Stephen Boyd wrote: > > > > > > > > > > > kunit_resource_destroy (respective equivalents to devm_kfree, and > > > > > > devres_destroy) and use kunit_kfree here? > > > > > > > > > > > > > > > > Yes, or drop the API entirely? Does anything need this functionality? > > > > > > > > Drop the kunit_resource API? I would strongly prefer not to. > > > > > > No. I mean this API, string_stream_clear(). Does anything use it? > > > > Oh, right. No. > > > > However, now that I added the kunit_resource_destroy, I thought it > > might be good to free the string_stream after I use it in each call to > > kunit_assert->format(...) in which case I will be using this logic. > > > > So I think the right thing to do is to expose string_stream_destroy so > > kunit_do_assert can clean up when it's done, and then demote > > string_stream_clear to static. Sound good? > > Ok, sure. I don't really see how clearing it explicitly when the > assertion prints vs. never allocating it to begin with is really any > different. Maybe I've missed something though. It's for the case that we *do* print something out. Once we are doing printing, we don't want the fragments anymore.
Re: [PATCH v12 03/18] kunit: test: add string_stream a std::stream like string builder
On Tue, Aug 13, 2019 at 2:04 AM Brendan Higgins wrote: > > On Mon, Aug 12, 2019 at 10:30 PM Stephen Boyd wrote: > > > > Quoting Brendan Higgins (2019-08-12 22:02:59) > > > On Mon, Aug 12, 2019 at 9:56 PM Stephen Boyd wrote: > > > > > > > > Quoting Brendan Higgins (2019-08-12 17:41:05) > > > > > On Mon, Aug 12, 2019 at 4:59 PM Stephen Boyd wrote: > > > > > > > > > > > > > kunit_resource_destroy (respective equivalents to devm_kfree, and > > > > > > > devres_destroy) and use kunit_kfree here? > > > > > > > > > > > > > > > > > > > Yes, or drop the API entirely? Does anything need this > > > > > > functionality? > > > > > > > > > > Drop the kunit_resource API? I would strongly prefer not to. > > > > > > > > No. I mean this API, string_stream_clear(). Does anything use it? > > > > > > Oh, right. No. > > > > > > However, now that I added the kunit_resource_destroy, I thought it > > > might be good to free the string_stream after I use it in each call to > > > kunit_assert->format(...) in which case I will be using this logic. > > > > > > So I think the right thing to do is to expose string_stream_destroy so > > > kunit_do_assert can clean up when it's done, and then demote > > > string_stream_clear to static. Sound good? > > > > Ok, sure. I don't really see how clearing it explicitly when the > > assertion prints vs. never allocating it to begin with is really any > > different. Maybe I've missed something though. > > It's for the case that we *do* print something out. Once we are doing > printing, we don't want the fragments anymore. Oops, sorry fat fingered: s/doing/done ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: ipaq_micro: Make structure micro_bl_props constant
On Tue, Aug 13, 2019 at 02:28:55PM +0530, Nishka Dasgupta wrote:
> Static structure micro_bl_props, having type backlight_properties, is
> used only once, when it is passed as the last argument to function
> devm_backlight_device_register(). devm_backlight_device_register() is
> defined with its last parameter being declared constant. Hence make
> micro_bl_props itself constant as well.
> Issue found with Coccinelle.
Did you do any review to see if this pattern occurs in other backlight
drivers (it looks to me like the same pattern appears in
rave-sp-backlight.c... do the tools bring that one out as well).
Daniel.
>
> Signed-off-by: Nishka Dasgupta
> ---
> drivers/video/backlight/ipaq_micro_bl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/ipaq_micro_bl.c
> b/drivers/video/backlight/ipaq_micro_bl.c
> index 1123f67c12b3..85b16cc82878 100644
> --- a/drivers/video/backlight/ipaq_micro_bl.c
> +++ b/drivers/video/backlight/ipaq_micro_bl.c
> @@ -44,7 +44,7 @@ static const struct backlight_ops micro_bl_ops = {
> .update_status = micro_bl_update_status,
> };
>
> -static struct backlight_properties micro_bl_props = {
> +static const struct backlight_properties micro_bl_props = {
> .type = BACKLIGHT_RAW,
> .max_brightness = 255,
> .power = FB_BLANK_UNBLANK,
> --
> 2.19.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: dumb-vga-dac: Fix dereferencing -ENODEV DDC channel
If the VGA connector has no DDC channel, an error pointer will be
dereferenced, e.g. on Salvator-XS:
Unable to handle kernel NULL pointer dereference at virtual address
017d
...
Call trace:
sysfs_do_create_link_sd.isra.0+0x40/0x108
sysfs_create_link+0x20/0x40
drm_sysfs_connector_add+0xa8/0xc8
drm_connector_register.part.3+0x54/0xb0
drm_connector_register_all+0xb0/0xd0
drm_modeset_register_all+0x54/0x88
drm_dev_register+0x18c/0x1d8
rcar_du_probe+0xe4/0x150
...
This happens because vga->ddc either contains a valid DDC channel
pointer, or -ENODEV, and drm_connector_init_with_ddc() expects a valid
DDC channel pointer, or NULL.
Fix this by resetting vga->ddc to NULL in case of -ENODEV, and replacing
the existing error checks by non-NULL checks.
This is similar to what the HDMI connector driver does.
Fixes: a4f9087e85de141e ("drm/bridge: dumb-vga-dac: Provide ddc symlink in
connector sysfs directory")
Signed-off-by: Geert Uytterhoeven
---
An alternative would be to check if vga->ddc contains an error pointer,
and calling drm_connector_init() instead of
drm_connector_init_with_ddc(), like before.
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index 8ef6539ae78a6eb3..7aa789c358829b05 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -42,7 +42,7 @@ static int dumb_vga_get_modes(struct drm_connector *connector)
struct edid *edid;
int ret;
- if (IS_ERR(vga->ddc))
+ if (!vga->ddc)
goto fallback;
edid = drm_get_edid(connector, vga->ddc);
@@ -84,7 +84,7 @@ dumb_vga_connector_detect(struct drm_connector *connector,
bool force)
* wire the DDC pins, or the I2C bus might not be working at
* all.
*/
- if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
+ if (vga->ddc && drm_probe_ddc(vga->ddc))
return connector_status_connected;
return connector_status_unknown;
@@ -197,6 +197,7 @@ static int dumb_vga_probe(struct platform_device *pdev)
if (PTR_ERR(vga->ddc) == -ENODEV) {
dev_dbg(&pdev->dev,
"No i2c bus specified. Disabling EDID
readout\n");
+ vga->ddc = NULL;
} else {
dev_err(&pdev->dev, "Couldn't retrieve i2c bus\n");
return PTR_ERR(vga->ddc);
@@ -218,7 +219,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
drm_bridge_remove(&vga->bridge);
- if (!IS_ERR(vga->ddc))
+ if (vga->ddc)
i2c_put_adapter(vga->ddc);
return 0;
--
2.17.1
Re: [PATCH v2 1/4] drm/i2c/tda998x: drop use of drmP.h
On Sun, Aug 04, 2019 at 11:41:29AM +0200, Sam Ravnborg wrote: > Drop use of the deprecated drmP.h header file. > Fix fallout. > > Signed-off-by: Sam Ravnborg > Cc: Russell King > Cc: David Airlie > Cc: Daniel Vetter > --- > drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/tegra: drop use of drmP.h
On Sun, Aug 04, 2019 at 11:41:30AM +0200, Sam Ravnborg wrote: > Drop use of the deprecated drmP.h header file. > > For all touched files divide include files into blocks, > and sort them within the blocks. > Fix fallout. > > Signed-off-by: Sam Ravnborg > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: linux-te...@vger.kernel.org > --- > drivers/gpu/drm/tegra/dc.c| 13 + > drivers/gpu/drm/tegra/dpaux.c | 5 +++-- > drivers/gpu/drm/tegra/drm.c | 8 > drivers/gpu/drm/tegra/drm.h | 3 +-- > drivers/gpu/drm/tegra/dsi.c | 8 +--- > drivers/gpu/drm/tegra/fb.c| 6 -- > drivers/gpu/drm/tegra/gem.c | 3 +++ > drivers/gpu/drm/tegra/gem.h | 1 - > drivers/gpu/drm/tegra/gr2d.c | 1 + > drivers/gpu/drm/tegra/hdmi.c | 5 + > drivers/gpu/drm/tegra/hub.c | 3 ++- > drivers/gpu/drm/tegra/hub.h | 1 - > drivers/gpu/drm/tegra/plane.c | 1 + > drivers/gpu/drm/tegra/sor.c | 3 +++ > drivers/gpu/drm/tegra/vic.c | 1 + > 15 files changed, 46 insertions(+), 16 deletions(-) Reviewed-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/armada: drop use of drmP.h
On Sun, Aug 04, 2019 at 11:41:31AM +0200, Sam Ravnborg wrote: > Drop use of the deprecated drmP.h header file. > While touching the list of include files group them and sort them. > Fix fallout from the header file removal. > > Signed-off-by: Sam Ravnborg > Cc: Russell King > Cc: David Airlie > Cc: Daniel Vetter > --- > drivers/gpu/drm/armada/armada_crtc.c| 10 +++--- > drivers/gpu/drm/armada/armada_debugfs.c | 8 ++-- > drivers/gpu/drm/armada/armada_drm.h | 5 - > drivers/gpu/drm/armada/armada_drv.c | 8 > drivers/gpu/drm/armada/armada_fb.c | 3 +++ > drivers/gpu/drm/armada/armada_fbdev.c | 3 +++ > drivers/gpu/drm/armada/armada_gem.c | 7 ++- > drivers/gpu/drm/armada/armada_overlay.c | 8 +--- > drivers/gpu/drm/armada/armada_plane.c | 4 +++- > drivers/gpu/drm/armada/armada_trace.h | 5 - > 10 files changed, 49 insertions(+), 12 deletions(-) Reviewed-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/4] drm/arm: drop use of drmP.h
On Sun, Aug 04, 2019 at 11:41:32AM +0200, Sam Ravnborg wrote: > Drop use of the deprecated drmP.h header file. > > While touching the list of include files divide them > into blocks and sort within each block. > Fix fallout. > > Signed-off-by: Sam Ravnborg > Cc: Liviu Dudau > Cc: Brian Starkey > Cc: David Airlie > Cc: Daniel Vetter > Cc: mal...@foss.arm.com > --- > drivers/gpu/drm/arm/hdlcd_crtc.c| 12 +++- > drivers/gpu/drm/arm/hdlcd_drv.c | 7 ++- > drivers/gpu/drm/arm/malidp_crtc.c | 11 +++ > drivers/gpu/drm/arm/malidp_drv.c| 8 +--- > drivers/gpu/drm/arm/malidp_drv.h| 7 --- > drivers/gpu/drm/arm/malidp_hw.c | 7 ++- > drivers/gpu/drm/arm/malidp_mw.c | 5 +++-- > drivers/gpu/drm/arm/malidp_planes.c | 4 +++- > 8 files changed, 41 insertions(+), 20 deletions(-) Reviewed-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: dw-hdmi: move cec PA invalidation to dw_hdmi_setup_rx_sense()
When testing CEC on the AML-S905X-CC board I noticed that the CEC physical
address was not invalidated when the HDMI cable was unplugged. Some more
digging showed that meson uses meson_dw_hdmi.c to handle the HPD.
Both dw_hdmi_irq() and dw_hdmi_top_thread_irq() (in meson_dw_hdmi.c) call
the dw_hdmi_setup_rx_sense() function. So move the code to invalidate the
CEC physical address to that function, so that it is independent of where
the HPD interrupt happens.
Tested with both a AML-S905X-CC and a Khadas VIM2 board.
Signed-off-by: Hans Verkuil
---
Note: an alternative would be to make a new dw-hdmi function such as
dw_hdmi_cec_phys_addr_invalidate() that is called from meson_dw_hdmi.c.
I decided not to do that since this patch is minimally invasive, but
that can obviously be changed if that approach is preferred.
---
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index c5a854af54f8..e899b31e1432 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2329,6 +2329,13 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool
hpd, bool rx_sense)
dw_hdmi_update_power(hdmi);
dw_hdmi_update_phy_mask(hdmi);
}
+ if (!hpd && !rx_sense) {
+ struct cec_notifier *notifier = READ_ONCE(hdmi->cec_notifier);
+
+ if (notifier)
+ cec_notifier_phys_addr_invalidate(notifier);
+ }
+
mutex_unlock(&hdmi->mutex);
}
EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
@@ -2369,14 +2376,6 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
dw_hdmi_setup_rx_sense(hdmi,
phy_stat & HDMI_PHY_HPD,
phy_stat & HDMI_PHY_RX_SENSE);
-
- if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) {
- struct cec_notifier *notifier;
-
- notifier = READ_ONCE(hdmi->cec_notifier);
- if (notifier)
- cec_notifier_phys_addr_invalidate(notifier);
- }
}
if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
Re: [PATCH v6 19/24] drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory
Hi Günter,
On Thu, Aug 8, 2019 at 5:42 AM Guenter Roeck wrote:
> On Fri, Jul 26, 2019 at 07:23:13PM +0200, Andrzej Pietrasiewicz wrote:
> > Use the ddc pointer provided by the generic connector.
> >
> > Signed-off-by: Andrzej Pietrasiewicz
> > Reviewed-by: Neil Armstrong
>
> This patch results in a crash when running qemu:versatilepb.
>
> Unable to handle kernel NULL pointer dereference at virtual address 00c5
> pgd = (ptrval)
> [00c5] *pgd=
> Internal error: Oops: 5 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 5.3.0-rc1+ #1
> Hardware name: ARM-Versatile (Device Tree Support)
> PC is at sysfs_do_create_link_sd+0x38/0xd8
> LR is at sysfs_do_create_link_sd+0x38/0xd8
> [] (sysfs_do_create_link_sd) from []
> (drm_connector_register.part.1+0x40/0xa0)
> [] (drm_connector_register.part.1) from []
> (drm_connector_register_all+0x90/0xb8)
> [] (drm_connector_register_all) from []
> (drm_modeset_register_all+0x44/0x6c)
> [] (drm_modeset_register_all) from []
> (drm_dev_register+0x15c/0x1c0)
> [] (drm_dev_register) from []
> (pl111_amba_probe+0x2e0/0x4ac)
> [] (pl111_amba_probe) from [] (amba_probe+0x9c/0x118)
Seeing the same thing on Salvator-XS, due to vga->ddc being -ENODEV.
> # first bad commit: [a4f9087e85de141e4e6d21ac2c583ae096cc9aba] drm/bridge:
> dumb-vga-dac: Provide ddc symlink in connector sysfs directory
Fix sent
https://lore.kernel.org/lkml/20190813093046.4976-1-geert+rene...@glider.be/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: dw-hdmi: move cec PA invalidation to dw_hdmi_setup_rx_sense()
CC Dariusz as well, since this issue was discovered when testing his
CEC patches.
Regards,
Hans
On 8/13/19 11:32 AM, Hans Verkuil wrote:
> When testing CEC on the AML-S905X-CC board I noticed that the CEC physical
> address was not invalidated when the HDMI cable was unplugged. Some more
> digging showed that meson uses meson_dw_hdmi.c to handle the HPD.
>
> Both dw_hdmi_irq() and dw_hdmi_top_thread_irq() (in meson_dw_hdmi.c) call
> the dw_hdmi_setup_rx_sense() function. So move the code to invalidate the
> CEC physical address to that function, so that it is independent of where
> the HPD interrupt happens.
>
> Tested with both a AML-S905X-CC and a Khadas VIM2 board.
>
> Signed-off-by: Hans Verkuil
> ---
> Note: an alternative would be to make a new dw-hdmi function such as
> dw_hdmi_cec_phys_addr_invalidate() that is called from meson_dw_hdmi.c.
> I decided not to do that since this patch is minimally invasive, but
> that can obviously be changed if that approach is preferred.
> ---
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index c5a854af54f8..e899b31e1432 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2329,6 +2329,13 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool
> hpd, bool rx_sense)
> dw_hdmi_update_power(hdmi);
> dw_hdmi_update_phy_mask(hdmi);
> }
> + if (!hpd && !rx_sense) {
> + struct cec_notifier *notifier = READ_ONCE(hdmi->cec_notifier);
> +
> + if (notifier)
> + cec_notifier_phys_addr_invalidate(notifier);
> + }
> +
> mutex_unlock(&hdmi->mutex);
> }
> EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
> @@ -2369,14 +2376,6 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> dw_hdmi_setup_rx_sense(hdmi,
> phy_stat & HDMI_PHY_HPD,
> phy_stat & HDMI_PHY_RX_SENSE);
> -
> - if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) {
> - struct cec_notifier *notifier;
> -
> - notifier = READ_ONCE(hdmi->cec_notifier);
> - if (notifier)
> - cec_notifier_phys_addr_invalidate(notifier);
> - }
> }
>
> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
>
Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
Hi Thomas, On Mon, Aug 12, 2019 at 03:25:45PM +0800, Feng Tang wrote: > Hi Thomas, > > On Fri, Aug 09, 2019 at 04:12:29PM +0800, Rong Chen wrote: > > Hi, > > > > >>Actually we run the benchmark as a background process, do we need to > > >>disable the cursor and test again? > > >There's a worker thread that updates the display from the shadow buffer. > > >The blinking cursor periodically triggers the worker thread, but the > > >actual update is just the size of one character. > > > > > >The point of the test without output is to see if the regression comes > > >from the buffer update (i.e., the memcpy from shadow buffer to VRAM), or > > >from the worker thread. If the regression goes away after disabling the > > >blinking cursor, then the worker thread is the problem. If it already > > >goes away if there's simply no output from the test, the screen update > > >is the problem. On my machine I have to disable the blinking cursor, so > > >I think the worker causes the performance drop. > > > > We disabled redirecting stdout/stderr to /dev/kmsg, and the regression is > > gone. > > > > commit: > > f1f8555dfb9 drm/bochs: Use shadow buffer for bochs framebuffer console > > 90f479ae51a drm/mgag200: Replace struct mga_fbdev with generic framebuffer > > emulation > > > > f1f8555dfb9a70a2 90f479ae51afa45efab97afdde testcase/testparams/testbox > > -- --- > > %stddev change %stddev > > \ | \ > > 43785 44481 > > vm-scalability/300s-8T-anon-cow-seq-hugetlb/lkp-knm01 > > 43785 44481 GEO-MEAN vm-scalability.median > > Till now, from Rong's tests: > 1. Disabling cursor blinking doesn't cure the regression. > 2. Disabling printint test results to console can workaround the > regression. > > Also if we set the perfer_shadown to 0, the regression is also > gone. We also did some further break down for the time consumed by the new code. The drm_fb_helper_dirty_work() calls sequentially 1. drm_client_buffer_vmap (290 us) 2. drm_fb_helper_dirty_blit_real (19240 us) 3. helper->fb->funcs->dirty()---> NULL for mgag200 driver 4. drm_client_buffer_vunmap (215 us) The average run time is listed after the function names. From it, we can see drm_fb_helper_dirty_blit_real() takes too long time (about 20ms for each run). I guess this is the root cause of this regression, as the original code doesn't use this dirty worker. As said in last email, setting the prefer_shadow to 0 can avoid the regrssion. Could it be an option? Thanks, Feng > > --- a/drivers/gpu/drm/mgag200/mgag200_main.c > +++ b/drivers/gpu/drm/mgag200/mgag200_main.c > @@ -167,7 +167,7 @@ int mgag200_driver_load(struct drm_device *dev, unsigned > long flags) > dev->mode_config.preferred_depth = 16; > else > dev->mode_config.preferred_depth = 32; > - dev->mode_config.prefer_shadow = 1; > + dev->mode_config.prefer_shadow = 0; > > And from the perf data, one obvious difference is good case don't > call drm_fb_helper_dirty_work(), while bad case calls. > > Thanks, > Feng > > > Best Regards, > > Rong Chen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7,01/16] drm: Add Enhanced Gamma LUT precision structure
On Fri, Mar 29, 2019 at 01:45:59AM +0530, Uma Shankar wrote:
> Existing LUT precision structure is having only 16 bit
> precision. This is not enough for upcoming enhanced hardwares
> and advance usecases like HDR processing. Hence added a new
> structure with 32 bit precision values. Also added the code,
> for extracting the same from values passed from userspace.
>
> v4: Rebase
>
> v5: Relocated the helper function to drm_color_mgmt.c. Declared
> the same in a header file (Alexandru Gheorghe)
>
> v6: Enhanced gamma lut structure to take U32.32 format as input.
> This is needed for HDR usecase which require higher precision.
>
> v7: Addressed Maarten's review comments and fixed the calculation.
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Alexandru Gheorghe
Hi Uma
When can we merge these plane color-mgmt support into upstream ?
or can we merge the DRM-CORE part patches firstly?
thanks
james
> ---
> drivers/gpu/drm/drm_color_mgmt.c | 20
> include/drm/drm_color_mgmt.h | 1 +
> include/uapi/drm/drm_mode.h | 15 +++
> 3 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index d5d34d0..79ff874 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -128,6 +128,26 @@ uint32_t drm_color_lut_extract(uint32_t user_input,
> uint32_t bit_precision)
> }
> EXPORT_SYMBOL(drm_color_lut_extract);
>
> +/*
> + * Added to accommodate enhanced LUT precision.
> + * Max LUT precision is 32 bits.
> + */
> +u64 drm_color_lut_extract_ext(u64 user_input, u32 bit_precision)
> +{
> + u64 val = user_input & 0x;
> + u32 max = 0x >> (32 - bit_precision);
> +
> + /* Round only if we're not using full precision. */
> + if (bit_precision < 32) {
> + val += 1UL << (32 - bit_precision - 1);
> + val >>= 32 - bit_precision;
> + }
> +
> + return ((user_input & 0x) |
> + clamp_val(val, 0, max));
> +}
> +EXPORT_SYMBOL(drm_color_lut_extract_ext);
> +
> /**
> * drm_crtc_enable_color_mgmt - enable color management properties
> * @crtc: DRM CRTC
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index d1c662d..c9d2746 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -30,6 +30,7 @@
> struct drm_plane;
>
> uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
> +u64 drm_color_lut_extract_ext(u64 user_input, u32 bit_precision);
>
> void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> uint degamma_lut_size,
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 09d7296..ca81410 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -629,6 +629,21 @@ struct drm_color_lut {
> __u16 reserved;
> };
>
> +/*
> + * Creating 64 bit palette entries for better data
> + * precision. This will be required for HDR and
> + * similar color processing usecases.
> + */
> +struct drm_color_lut_ext {
> + /*
> + * Data is U32.32 fixed point format.
> + */
> + __u64 red;
> + __u64 green;
> + __u64 blue;
> + __u64 reserved;
> +};
> +
> #define DRM_MODE_PAGE_FLIP_EVENT 0x01
> #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
> #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tilcdc: plane: Make structure tilcdc_plane_funcs constant
On 13/08/2019 12:05, Nishka Dasgupta wrote:
> The static structure tilcdc_plane_funcs, of type drm_plane_funcs, is
> used only when passed the fourth argument to drm_plane_init(); however,
> this fourth parameter is declared as const in the function definition.
> Hence make tilcdc_plane_funcs constant as well.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta
Thanks, I'll pick this up.
BR,
Jyri
> ---
> drivers/gpu/drm/tilcdc/tilcdc_plane.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> index 8c2776acdf99..bfd5dccca709 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> @@ -13,7 +13,7 @@
>
> #include "tilcdc_drv.h"
>
> -static struct drm_plane_funcs tilcdc_plane_funcs = {
> +static const struct drm_plane_funcs tilcdc_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> .destroy= drm_plane_cleanup,
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/komeda: Introduce komeda_color_manager/state
Hi James,
On Tuesday, 13 August 2019 05:56:07 BST james qian wang (Arm Technology China)
wrote:
> Many komeda component support color management like layer and IPS, so
> komeda_color_manager/state are introduced to manager gamma, csc and degamma
> together for easily share it to multiple componpent.
>
> And for komeda_color_manager which:
> - convert drm 3d gamma lut to komeda specific gamma coeffs
> - gamma table management and hide the HW difference for komeda-CORE
>
> Signed-off-by: James Qian Wang (Arm Technology China)
>
> ---
> .../arm/display/komeda/komeda_color_mgmt.c| 126 ++
> .../arm/display/komeda/komeda_color_mgmt.h| 32 -
> 2 files changed, 156 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> index 9d14a92dbb17..bf2388d641b9 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> @@ -4,7 +4,9 @@
> * Author: James.Qian.Wang
> *
> */
> +#include
>
> +#include "malidp_utils.h"
> #include "komeda_color_mgmt.h"
>
> /* 10bit precision YUV2RGB matrix */
> @@ -65,3 +67,127 @@ const s32 *komeda_select_yuv2rgb_coeffs(u32
> color_encoding, u32 color_range)
>
> return coeffs;
> }
> +
> +struct gamma_curve_sector {
> + u32 boundary_start;
> + u32 num_of_segments;
> + u32 segment_width;
> +};
> +
> +struct gamma_curve_segment {
> + u32 start;
> + u32 end;
> +};
> +
> +static struct gamma_curve_sector sector_tbl[] = {
> + { 0,4, 4 },
> + { 16, 4, 4 },
> + { 32, 4, 8 },
> + { 64, 4, 16 },
> + { 128, 4, 32 },
> + { 256, 4, 64 },
> + { 512, 16, 32 },
> + { 1024, 24, 128 },
> +};
> +
> +static struct gamma_curve_sector igamma_sector_tbl[] = {
> + {0, 64, 64},
> +};
> +
> +static void
> +drm_lut_to_coeffs(struct drm_property_blob *lut_blob, u32 *coeffs,
> + struct gamma_curve_sector *sector_tbl, u32 num_sectors)
> +{
> + struct drm_color_lut *lut;
> + u32 i, j, in, num = 0;
> +
> + if (!lut_blob)
> + return;
> +
> + lut = lut_blob->data;
> +
> + for (i = 0; i < num_sectors; i++) {
> + for (j = 0; j < sector_tbl[i].num_of_segments; j++) {
> + in = sector_tbl[i].boundary_start +
> + j * sector_tbl[i].segment_width;
> +
> + coeffs[num++] = drm_color_lut_extract(lut[in].red,
> + KOMEDA_COLOR_PRECISION);
> + }
> + }
> +
> + coeffs[num] = BIT(KOMEDA_COLOR_PRECISION);
> +}
> +
> +void drm_lut_to_igamma_coeffs(struct drm_property_blob *lut_blob, u32
> *coeffs)
> +{
> + drm_lut_to_coeffs(lut_blob, coeffs,
> + igamma_sector_tbl, ARRAY_SIZE(igamma_sector_tbl));
> +}
> +
> +void drm_lut_to_fgamma_coeffs(struct drm_property_blob *lut_blob, u32
> *coeffs)
> +{
> + drm_lut_to_coeffs(lut_blob, coeffs,
> + sector_tbl, ARRAY_SIZE(sector_tbl));
> +}
> +
> +void drm_ctm_to_coeffs(struct drm_property_blob *ctm_blob, u32 *coeffs)
> +{
> + struct drm_color_ctm *ctm;
> + u32 i;
> +
> + if (!ctm_blob)
> + return;
> +
> + ctm = ctm_blob->data;
> +
> + for (i = 0; i < KOMEDA_N_CTM_COEFFS; ++i) {
> + /* Convert from S31.32 to Q3.12. */
> + s64 v = ctm->matrix[i];
> +
> + coeffs[i] = clamp_val(v, 1 - (1LL << 34), (1LL << 34) - 1) >>
> 20;
CTM matrix values are S31.32, i.e. sign-magnitude, so clamp_val won't
give you the right result for negative coeffs. See
malidp_crtc_atomic_check_ctm for the sign-mag -> 2's complement
conversion.
> + }
> +}
> +
> +void komeda_color_duplicate_state(struct komeda_color_state *new,
> + struct komeda_color_state *old)
[bikeshed] not really a _duplicate_state if all it does is refcounts.
kmemdup here and return a pointer (with ERR_PTR on fail), or memcpy if
you want to keep the signature?
> +{
> + new->igamma = komeda_coeffs_get(old->igamma);
> + new->fgamma = komeda_coeffs_get(old->fgamma);
> +}
> +
> +void komeda_color_cleanup_state(struct komeda_color_state *color_st)
> +{
> + komeda_coeffs_put(color_st->igamma);
> + komeda_coeffs_put(color_st->fgamma);
> +}
> +
> +int komeda_color_validate(struct komeda_color_manager *mgr,
> + struct komeda_color_state *st,
> + struct drm_property_blob *igamma_blob,
> + struct drm_property_blob *fgamma_blob)
> +{
> + u32 coeffs[KOMEDA_N_GAMMA_COEFFS];
> +
> + komeda_color_cleanup_state(st);
> +
> + if (igamma_blob) {
> + drm_lut_to_igamma_coeffs(igamma_blob, coeffs);
> + st->igamma = komeda_coeffs_request(mgr->igamma_mgr, coeffs);
> + if (!st->igamma) {
> +
[PATCH] video: hyperv: hyperv_fb: Obtain screen resolution from Hyper-V host
Beginning from Windows 10 RS5+, VM screen resolution is obtained from host.
The "video=hyperv_fb" boot time option is not needed, but still can be
used to overwrite the VM resolution. The VM resolution on the host could be
set by executing the powershell "set-vmvideo" command.
Signed-off-by: Iouri Tarassov
Signed-off-by: Wei Hu
---
drivers/video/fbdev/hyperv_fb.c | 136 +---
1 file changed, 125 insertions(+), 11 deletions(-)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 00f5bdcc6c6f..1042f3311fa2 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -23,6 +23,14 @@
*
* Portrait orientation is also supported:
* For example: video=hyperv_fb:864x1152
+ *
+ * When a Windows 10 RS5+ host is used, the virtual machine screen
+ * resolution is obtained from the host. The "video=hyperv_fb" option is
+ * not needed, but still can be used to overwrite the VM resolution. The
+ * VM resolution on the host could be set by executing the powershell
+ * "set-vmvideo" command. For example
+ * set-vmvideo -vmname name -horizontalresolution:1920 \
+ * -verticalresolution:1200 -resolutiontype single
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -44,6 +52,7 @@
#define SYNTHVID_VERSION(major, minor) ((minor) << 16 | (major))
#define SYNTHVID_VERSION_WIN7 SYNTHVID_VERSION(3, 0)
#define SYNTHVID_VERSION_WIN8 SYNTHVID_VERSION(3, 2)
+#define SYNTHVID_VERSION_WIN10 SYNTHVID_VERSION(3, 5)
#define SYNTHVID_DEPTH_WIN7 16
#define SYNTHVID_DEPTH_WIN8 32
@@ -82,16 +91,25 @@ enum synthvid_msg_type {
SYNTHVID_POINTER_SHAPE = 8,
SYNTHVID_FEATURE_CHANGE = 9,
SYNTHVID_DIRT = 10,
+ SYNTHVID_RESOLUTION_REQUEST = 13,
+ SYNTHVID_RESOLUTION_RESPONSE= 14,
- SYNTHVID_MAX= 11
+ SYNTHVID_MAX= 15
};
+#defineSYNTHVID_EDID_BLOCK_SIZE128
+#defineSYNTHVID_MAX_RESOLUTION_COUNT 64
+
+struct hvd_screen_info {
+ u16 width;
+ u16 height;
+} __packed;
+
struct synthvid_msg_hdr {
u32 type;
u32 size; /* size of this header + payload after this field*/
} __packed;
-
struct synthvid_version_req {
u32 version;
} __packed;
@@ -102,6 +120,18 @@ struct synthvid_version_resp {
u8 max_video_outputs;
} __packed;
+struct synthvid_supported_resolution_req {
+ u8 maximum_resolution_count;
+} __packed;
+
+struct synthvid_supported_resolution_resp {
+ u8 edid_block[SYNTHVID_EDID_BLOCK_SIZE];
+ u8 resolution_count;
+ u8 default_resolution_index;
+ u8 is_standard;
+ struct hvd_screen_info supported_resolution[1];
+} __packed;
+
struct synthvid_vram_location {
u64 user_ctx;
u8 is_vram_gpa_specified;
@@ -187,6 +217,8 @@ struct synthvid_msg {
struct synthvid_pointer_shape ptr_shape;
struct synthvid_feature_change feature_chg;
struct synthvid_dirt dirt;
+ struct synthvid_supported_resolution_req resolution_req;
+ struct synthvid_supported_resolution_resp resolution_resp;
};
} __packed;
@@ -224,6 +256,8 @@ struct hvfb_par {
static uint screen_width = HVFB_WIDTH;
static uint screen_height = HVFB_HEIGHT;
+static uint screen_width_max = HVFB_WIDTH;
+static uint screen_height_max = HVFB_HEIGHT;
static uint screen_depth;
static uint screen_fb_size;
@@ -354,6 +388,7 @@ static void synthvid_recv_sub(struct hv_device *hdev)
/* Complete the wait event */
if (msg->vid_hdr.type == SYNTHVID_VERSION_RESPONSE ||
+ msg->vid_hdr.type == SYNTHVID_RESOLUTION_RESPONSE ||
msg->vid_hdr.type == SYNTHVID_VRAM_LOCATION_ACK) {
memcpy(par->init_buf, msg, MAX_VMBUS_PKT_SIZE);
complete(&par->wait);
@@ -428,6 +463,64 @@ static int synthvid_negotiate_ver(struct hv_device *hdev,
u32 ver)
}
par->synthvid_version = ver;
+ pr_info("Synthvid Version major %d, minor %d\n",
+ ver & 0x, (ver & 0x) >> 16);
+
+out:
+ return ret;
+}
+
+/* Get current resolution from the host */
+static int synthvid_get_supported_resolution(struct hv_device *hdev)
+{
+ struct fb_info *info = hv_get_drvdata(hdev);
+ struct hvfb_par *par = info->par;
+ struct synthvid_msg *msg = (struct synthvid_msg *)par->init_buf;
+ int ret = 0;
+ unsigned long t;
+ u8 index;
+ int i;
+
+ memset(msg, 0, sizeof(struct synthvid_msg));
+ msg->vid_hdr.type = SYNTHVID_RESOLUTION_REQUEST;
+ msg->vid_hdr.size = sizeof(struct synthvid_msg_hdr) +
+ sizeof(struct synthvid_supported_resolution_req);
+
+ msg->resolution_req.maximum_resolution_count =
+ SYNTHVID_MAX_RESOLUTION_COUNT;
+ synthvid_send(hdev, msg);
+
+ t = wait_for_complet
Re: [PATCH 10/11] mfd: Drop obsolete JZ4740 driver
Hi Philippe, Le mar. 13 août 2019 à 10:44, Philippe =?iso-8859-1?q?Mathieu-Daud=E9?= a écrit : Hi Lee, On 8/12/19 10:16 AM, Lee Jones wrote: On Thu, 25 Jul 2019, Paul Cercueil wrote: It has been replaced with the ingenic-iio driver for the ADC. Signed-off-by: Paul Cercueil Tested-by: Artur Rojek --- drivers/mfd/Kconfig | 9 -- drivers/mfd/Makefile | 1 - drivers/mfd/jz4740-adc.c | 324 --- 3 files changed, 334 deletions(-) delete mode 100644 drivers/mfd/jz4740-adc.c Applied, thanks. It seems the replacement is done in "MIPS: qi_lb60: Migrate to devicetree" which is not yet merged. It's merged in the MIPS tree, though, so it'll blend together just fine in linux-next. Probably easier if this patch goes thru the MIPS tree as part of the "JZ4740 SoC cleanup" series. Regards, Phil.
Re: [PATCH v2 4/4] drm/komeda: Enable Layer color management for komeda
Hi James,
On Tuesday, 13 August 2019 05:56:19 BST james qian wang (Arm Technology China)
wrote:
> - D71 has 3 global layer gamma table which can be used for all layers as
> gamma lookup table, no matter inverse or forward.
> - Add komeda_color_manager/state to layer/layer_state for describe the
> color caps for the specific layer which will be initialized in
> d71_layer_init, and for D71 only layer with L_INFO_CM (color mgmt) bit
> can support forward gamma, and CSC.
> - Update komeda-CORE code to validate and convert the plane color state to
> komeda_color_state.
> - Enable plane color mgmt according to layer komeda_color_manager
>
> This patch depends on:
> - https://patchwork.freedesktop.org/series/30876/
>
> Signed-off-by: James Qian Wang (Arm Technology China)
>
> ---
> .../arm/display/komeda/d71/d71_component.c| 64 +++
> .../gpu/drm/arm/display/komeda/d71/d71_dev.c | 5 +-
> .../gpu/drm/arm/display/komeda/d71/d71_dev.h | 2 +
> .../drm/arm/display/komeda/komeda_pipeline.h | 4 +-
> .../display/komeda/komeda_pipeline_state.c| 53 ++-
> .../gpu/drm/arm/display/komeda/komeda_plane.c | 12
> .../arm/display/komeda/komeda_private_obj.c | 4 ++
> 7 files changed, 139 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> index 55a8cc94808a..c9c40a36e4d2 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -189,6 +189,46 @@ static void d71_layer_update_fb(struct komeda_component
> *c,
> malidp_write32(reg, LAYER_FMT, kfb->format_caps->hw_id);
> }
>
> +static u32 d71_layer_update_color(struct drm_plane_state *st,
> + u32 __iomem *reg,
> + struct komeda_color_state *color_st,
> + u32 *mask)
> +{
> + struct komeda_coeffs_table *igamma = color_st->igamma;
> + struct komeda_coeffs_table *fgamma = color_st->fgamma;
> + u32 ctrl = 0, v = 0;
> +
> + if (!st->color_mgmt_changed)
> + return 0;
> +
> + *mask |= L_IT | L_R2R | L_FT;
> +
> + if (igamma) {
> + komeda_coeffs_update(igamma);
> + ctrl |= L_IT;
> + v = L_ITSEL(igamma->hw_id);
> + }
> +
> + if (st->ctm) {
> + u32 ctm_coeffs[KOMEDA_N_CTM_COEFFS];
> +
> + drm_ctm_to_coeffs(st->ctm, ctm_coeffs);
> + malidp_write_group(reg, LAYER_RGB_RGB_COEFF0,
> +ARRAY_SIZE(ctm_coeffs),
> +ctm_coeffs);
> + ctrl |= L_R2R; /* enable RGB2RGB conversion */
> + }
> +
> + if (fgamma) {
> + komeda_coeffs_update(fgamma);
> + ctrl |= L_FT;
> + v |= L_FTSEL(fgamma->hw_id);
> + }
> +
> + malidp_write32(reg, LAYER_LT_COEFFTAB, v);
> + return ctrl;
> +}
> +
> static void d71_layer_disable(struct komeda_component *c)
> {
> malidp_write32_mask(c->reg, BLK_CONTROL, L_EN, 0);
> @@ -261,6 +301,8 @@ static void d71_layer_update(struct komeda_component *c,
>
> malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
>
> + ctrl |= d71_layer_update_color(plane_st, reg, &st->color_st,
> &ctrl_mask);
> +
> if (kfb->is_va)
> ctrl |= L_TBU_EN;
> malidp_write32_mask(reg, BLK_CONTROL, ctrl_mask, ctrl);
> @@ -365,6 +407,12 @@ static int d71_layer_init(struct d71_dev *d71,
> else
> layer->layer_type = KOMEDA_FMT_SIMPLE_LAYER;
>
> + layer->color_mgr.igamma_mgr = d71->glb_lt_mgr;
> + if (layer_info & L_INFO_CM) {
> + layer->color_mgr.has_ctm = true;
> + layer->color_mgr.fgamma_mgr = d71->glb_lt_mgr;
> + }
> +
> set_range(&layer->hsize_in, 4, d71->max_line_size);
> set_range(&layer->vsize_in, 4, d71->max_vsize);
>
> @@ -1140,6 +1188,21 @@ static int d71_timing_ctrlr_init(struct d71_dev *d71,
> return 0;
> }
>
> +static void d71_gamma_update(struct komeda_coeffs_table *table)
> +{
> + malidp_write_group(table->reg, GLB_LT_COEFF_DATA,
> +GLB_LT_COEFF_NUM, table->coeffs);
> +}
> +
> +static int d71_lt_coeff_init(struct d71_dev *d71,
> + struct block_header *blk, u32 __iomem *reg)
> +{
> + struct komeda_coeffs_manager *mgr = d71->glb_lt_mgr;
> + int hw_id = BLOCK_INFO_TYPE_ID(blk->block_info);
> +
> + return komeda_coeffs_add(mgr, hw_id, reg, d71_gamma_update);
> +}
> +
> int d71_probe_block(struct d71_dev *d71,
> struct block_header *blk, u32 __iomem *reg)
> {
> @@ -1202,6 +1265,7 @@ int d71_probe_block(struct d71_dev *d71,
> break;
>
> case D71_BLK_TYPE_GLB_LT_COEFF:
> + err = d71_lt_coeff_init(d71, blk, reg);
> break;
>
> case D71_BLK_TYP
Re: [PATCH v2 2/3] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
Hi Rob,
thanks for having a look!
On Fri, Aug 09, 2019 at 02:41:03PM -0600, Rob Herring wrote:
> On Fri, Aug 9, 2019 at 10:24 AM Guido Günther wrote:
> >
> > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
> >
> > Signed-off-by: Guido Günther
> > ---
> > .../bindings/display/bridge/nwl-dsi.yaml | 155 ++
> > 1 file changed, 155 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> > b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> > new file mode 100644
> > index ..5ed8bc4a4d18
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> > @@ -0,0 +1,155 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/imx-nwl-dsi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Northwest Logic MIPI-DSI on imx SoCs
> > +
> > +maintainers:
> > + - Guido Gúnther
> > + - Robert Chiras
> > +
> > +description: |
> > + NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi
> > bridge for
> > + the SOCs NWL MIPI-DSI host controller.
> > +
> > +properties:
> > + compatible:
> > +oneOf:
> > + - items:
> > +- const: fsl,imx8mq-nwl-dsi
>
> Don't need oneOf nor items here for a single possible value:
I wanted to prepare for adding other SoCs so there's less diff noise
(other imx8 SoCs will be rather simple) but let's go with 'const' for
now then.
> compatible:
> const: fsl,imx8mq-nwl-dsi
>
> Or go ahead and add other compatibles because the 'if' below seems to
> indicate you'll have more.
> > + reg:
> > +maxItems: 1
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > + clocks:
> > +items:
> > + - description: DSI core clock
> > + - description: RX_ESC clock (used in escape mode)
> > + - description: TX_ESC clock (used in escape mode)
> > + - description: PHY_REF clock
> > +
> > + clock-names:
> > +items:
> > + - const: core
> > + - const: rx_esc
> > + - const: tx_esc
> > + - const: phy_ref
> > +
> > + phys:
> > +maxItems: 1
> > +description:
> > + A phandle to the phy module representing the DPHY
> > +
> > + phy-names:
> > +items:
> > + - const: dphy
> > +
> > + power-domains:
> > +maxItems: 1
> > +description:
> > + A phandle to the power domain
> > +
> > + resets:
> > +maxItems: 4
> > +description:
> > + A phandle to the reset controller
>
> Sounds like 4 phandles... This should look similar to 'clocks'.
Added them individually, will be soc specific too later on.
>
> > +
> > + reset-names:
> > +items:
> > + - const: byte
> > + - const: dpi
> > + - const: esc
> > + - const: pclk
> > +
> > + mux-sel:
>
> Needs a vendor prefix and will need a $ref to the type.
Made that fsl,mux-sel. This require me to add '$ref:
/schemas/types.yaml#definitions/phandle' as well which
I hope is correct.
> > +maxItems: 1
> > +description:
> > + A phandle to the MUX register set
> > +
> > + port:
> > +type: object
> > +description:
> > + A input put or output port node.
> > +
> > + ports:
> > +type: object
> > +description:
> > + A node containing DSI input & output port nodes with endpoint
> > + definitions as documented in
> > + Documentation/devicetree/bindings/graph.txt.
>
> You need to define what port@0 and port@1 are.
Added.
>
> > +
> > +patternProperties:
> > + "^panel@[0-9]+$": true
> > +
> > +allOf:
> > + - if:
> > + properties:
> > +compatible:
> > + contains:
> > +enum:
> > + - fsl,imx8mq-nwl-dsi
>
> This conditional isn't needed until you have more than one compatible.
Again intended for other upcoming SoCs but dropped for now.
> > + required:
> > +- resets
> > +- reset-names
> > +- mux-sel
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > + - clock-names
> > + - phys
> > + - phy-names
>
> ports should be required.
Added.
> > +
> > +examples:
> > + - |
> > +
> > + mipi_dsi: mipi_dsi@30a0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "fsl,imx8mq-nwl-dsi";
> > + reg = <0x30A0 0x300>;
> > + clocks = <&clk 163>, <&clk 244>, <&clk 245>, <&clk 164>;
> > + clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
> > + interrupts = <0 34 4>;
> > + power-domains = <&pgc_mipi>;
> > + resets = <&src 0>, <&src 1>, <&src 2>, <&src 3>;
> > + reset-names = "byte", "dpi", "esc", "pclk";
> > + mux-sel = <&iomuxc_gpr>;
> > + phys = <&dphy>;
> > + p
Re: [PATCH v2 1/3] arm64: imx8mq: add imx8mq iomux-gpr field defines
Hi Arnd, On Tue, Aug 13, 2019 at 10:08:44AM +0200, Arnd Bergmann wrote: > On Fri, Aug 9, 2019 at 6:24 PM Guido Günther wrote: > > > > This adds all the gpr registers and the define needed for selecting > > the input source in the imx-nwl drm bridge. > > > > Signed-off-by: Guido Günther > > + > > +#define IOMUXC_GPR00x00 > > +#define IOMUXC_GPR10x04 > > +#define IOMUXC_GPR20x08 > > +#define IOMUXC_GPR30x0c > > +#define IOMUXC_GPR40x10 > > +#define IOMUXC_GPR50x14 > > +#define IOMUXC_GPR60x18 > > +#define IOMUXC_GPR70x1c > (more of the same) > > huh? These are the names from the imx8MQ reference manual (general purpose registers, they lump together all sorts of things), it's the same on imx6/imx7): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/mfd/syscon/imx7-iomuxc-gpr.h > > +/* i.MX8Mq iomux gpr register field defines */ > > +#define IMX8MQ_GPR13_MIPI_MUX_SEL BIT(2) > > I think this define should probably be local to the pinctrl driver, to > ensure that no other drivers fiddle with the registers manually. The purpose of these bits is for a driver to fiddle with them to select the input source. Similar on imx7 it's already used for e.g. the phy refclk in the pci controller: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pci-imx6.c#n638 The GPRs are not about pad configuration but gather all sorts of things (section 8.2.4 of the imx8mq reference manual): pcie setup, dsi related bits so I don't think this should be done via a pinctrl driver. Should we handle that differently than on imx6/7? Cheers, -- Guido
Re: [PATCH] drm/bridge: dw-hdmi: move cec PA invalidation to dw_hdmi_setup_rx_sense()
As an alternative I have a patch [1] to submit that moves
cec_notifier_phys_addr_invalidate() call
from dw_hdmi_irq() to dw_hdmi_connector_detect() in order to address an issue
with
stale CEC phys addr and stale EDID/ELD data after TV or AVR uses a 100ms HPD
pulse
to signal EDID has changed, full patchset at [2].
At the moment CEC phys address is invalidated directly at HPD, leaving the
address as invalid
after a 100ms HPD pulse, phys address may later be restored to a valid phys
address when
get_modes() is called by drm core.
Should I wait on your and related patches to be merged before submitting my
series?
[1]
https://github.com/Kwiboo/linux-rockchip/commit/2f4f99c82983e70952668c21f1c56a0241bd75f2
[2]
https://github.com/Kwiboo/linux-rockchip/compare/next-20190813...next-20190813-cec-eld
Regards,
Jonas
On 2019-08-13 11:34, Hans Verkuil wrote:
> CC Dariusz as well, since this issue was discovered when testing his
> CEC patches.
>
> Regards,
>
> Hans
>
> On 8/13/19 11:32 AM, Hans Verkuil wrote:
>> When testing CEC on the AML-S905X-CC board I noticed that the CEC physical
>> address was not invalidated when the HDMI cable was unplugged. Some more
>> digging showed that meson uses meson_dw_hdmi.c to handle the HPD.
>>
>> Both dw_hdmi_irq() and dw_hdmi_top_thread_irq() (in meson_dw_hdmi.c) call
>> the dw_hdmi_setup_rx_sense() function. So move the code to invalidate the
>> CEC physical address to that function, so that it is independent of where
>> the HPD interrupt happens.
>>
>> Tested with both a AML-S905X-CC and a Khadas VIM2 board.
>>
>> Signed-off-by: Hans Verkuil
>> ---
>> Note: an alternative would be to make a new dw-hdmi function such as
>> dw_hdmi_cec_phys_addr_invalidate() that is called from meson_dw_hdmi.c.
>> I decided not to do that since this patch is minimally invasive, but
>> that can obviously be changed if that approach is preferred.
>> ---
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index c5a854af54f8..e899b31e1432 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -2329,6 +2329,13 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi,
>> bool hpd, bool rx_sense)
>> dw_hdmi_update_power(hdmi);
>> dw_hdmi_update_phy_mask(hdmi);
>> }
>> +if (!hpd && !rx_sense) {
>> +struct cec_notifier *notifier = READ_ONCE(hdmi->cec_notifier);
>> +
>> +if (notifier)
>> +cec_notifier_phys_addr_invalidate(notifier);
>> +}
>> +
>> mutex_unlock(&hdmi->mutex);
>> }
>> EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
>> @@ -2369,14 +2376,6 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>> dw_hdmi_setup_rx_sense(hdmi,
>> phy_stat & HDMI_PHY_HPD,
>> phy_stat & HDMI_PHY_RX_SENSE);
>> -
>> -if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) {
>> -struct cec_notifier *notifier;
>> -
>> -notifier = READ_ONCE(hdmi->cec_notifier);
>> -if (notifier)
>> -cec_notifier_phys_addr_invalidate(notifier);
>> -}
>> }
>>
>> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/10] Improvements and fixes for mxsfb DRM driver
Hi Robert, On Wed, Jun 26, 2019 at 04:32:08PM +0300, Robert Chiras wrote: > This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM > and 8QXP). Following, are the new features added and fixes from this > patch-set: There was some feedback on various patches, do you intend to pick that up again? That would be cool since there's some overlapping work popping up already e.g. in https://patchwork.freedesktop.org/series/64595/ showing up and it's the base for the tiny https://patchwork.freedesktop.org/series/64300/ Cheers, -- Guido
Re: [PATCH 10/11] mfd: Drop obsolete JZ4740 driver
On Tue, 13 Aug 2019, Paul Cercueil wrote: > Hi Philippe, > > > Le mar. 13 août 2019 à 10:44, Philippe =?iso-8859-1?q?Mathieu-Daud=E9?= > a écrit : > > Hi Lee, > > > > On 8/12/19 10:16 AM, Lee Jones wrote: > > > On Thu, 25 Jul 2019, Paul Cercueil wrote: > > > > > > > It has been replaced with the ingenic-iio driver for the ADC. > > > > > > > > Signed-off-by: Paul Cercueil > > > > Tested-by: Artur Rojek > > > > --- > > > > drivers/mfd/Kconfig | 9 -- > > > > drivers/mfd/Makefile | 1 - > > > > drivers/mfd/jz4740-adc.c | 324 > > > > --- > > > > 3 files changed, 334 deletions(-) > > > > delete mode 100644 drivers/mfd/jz4740-adc.c > > > > > > Applied, thanks. > > > > It seems the replacement is done in "MIPS: qi_lb60: Migrate to > > devicetree" which is not yet merged. > > It's merged in the MIPS tree, though, so it'll blend together just > fine in linux-next. Wonderful. Thanks Paul. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH] drm/amdgpu/powerplay: fix spelling mistake "unsuported" -> "unsupported"
From: Colin Ian King
There is a spelling mistake in a pr_err error message. Fix it. Also
add a space after a comma to clean up a checkpatch warning.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
index 8bbcf034799c..d324bd28934d 100644
--- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
@@ -288,7 +288,7 @@ static int smu_v11_0_check_fw_version(struct smu_context
*smu)
smu->smc_if_version = SMU11_DRIVER_IF_VERSION_NV14;
break;
default:
- pr_err("smu unsuported asic type:%d.\n",smu->adev->asic_type);
+ pr_err("smu unsupported asic type:%d.\n", smu->adev->asic_type);
smu->smc_if_version = SMU11_DRIVER_IF_VERSION_INV;
break;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/powerplay: fix spelling mistake "unsuported" -> "unsupported"
[drm-next]
On 13/08/2019 11:33, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a pr_err error message. Fix it. Also
> add a space after a comma to clean up a checkpatch warning.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> index 8bbcf034799c..d324bd28934d 100644
> --- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> +++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> @@ -288,7 +288,7 @@ static int smu_v11_0_check_fw_version(struct smu_context
> *smu)
> smu->smc_if_version = SMU11_DRIVER_IF_VERSION_NV14;
> break;
> default:
> - pr_err("smu unsuported asic type:%d.\n",smu->adev->asic_type);
> + pr_err("smu unsupported asic type:%d.\n", smu->adev->asic_type);
> smu->smc_if_version = SMU11_DRIVER_IF_VERSION_INV;
> break;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EXT] Re: [PATCH 00/10] Improvements and fixes for mxsfb DRM driver
On Ma, 2019-08-13 at 12:23 +0200, Guido Günther wrote: > Hi Robert, > On Wed, Jun 26, 2019 at 04:32:08PM +0300, Robert Chiras wrote: > > > > This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like > > 8MQ, 8MM > > and 8QXP). Following, are the new features added and fixes from > > this > > patch-set: > There was some feedback on various patches, do you intend to pick > that > up again? That would be cool since there's some overlapping work > popping > up already e.g. in > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fpatchwork.freedesktop.org%2Fseries%2F64595%2F&data=02%7C01%7Crob > ert.chiras%40nxp.com%7C6ca6724a656b41912f0408d71fd83da0%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C637012885918631196&sdata=b3CrbNu% > 2FcsWBOA%2BcaQLX%2BrlrK7%2Fhf2%2F1vZS3eQGN7aM%3D&reserved=0 > > showing up and it's the base for the tiny > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fpatchwork.freedesktop.org%2Fseries%2F64300%2F&data=02%7C01%7Crob > ert.chiras%40nxp.com%7C6ca6724a656b41912f0408d71fd83da0%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C637012885918641196&sdata=h6KLVnSx > xBwvK%2FvPF9zt4DQR6WnF1pyQSwKBTO4rQTg%3D&reserved=0 > > Cheers, > -- Guido Hi Guido, Yes, I plan to submit a next revision, but first I wanted to try it with your patch-set for the nwl-dsi driver. Thanks for the heads-up. Best regards, Robert
[PATCH] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
Without deferred IO support, hyperv_fb driver informs the host to refresh
the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
is screen update or not. This patch supports defered IO for screens in
graphic mode and also enables the framme buffer on-demand refresh. The
highest refresh rate is still set at 20Hz.
Due to limitation on Hyper-V host, we keep a shadow copy of frame buffer
in the guest. This means one more copy of the dirty rectangle inside
guest when doing the on-demand refresh. This can be optimized in the
future with help from host. For now the host performance gain from deferred
IO outweighs the shadow copy impact in the guest.
Signed-off-by: Wei Hu
---
drivers/video/fbdev/Kconfig | 1 +
drivers/video/fbdev/hyperv_fb.c | 217 +---
2 files changed, 198 insertions(+), 20 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 1b2f5f31fb6f..e781f89a1824 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2241,6 +2241,7 @@ config FB_HYPERV
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select FB_DEFERRED_IO
help
This framebuffer driver supports Microsoft Hyper-V Synthetic Video.
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 1042f3311fa2..85198a6ea8e7 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -233,6 +233,7 @@ struct synthvid_msg {
#define RING_BUFSIZE (256 * 1024)
#define VSP_TIMEOUT (10 * HZ)
#define HVFB_UPDATE_DELAY (HZ / 20)
+#define HVFB_ONDEMAND_THROTTLE (HZ / 20)
struct hvfb_par {
struct fb_info *info;
@@ -252,6 +253,17 @@ struct hvfb_par {
bool synchronous_fb;
struct notifier_block hvfb_panic_nb;
+
+ /* Memory for deferred IO and frame buffer itself */
+ unsigned char *dio_vp;
+ unsigned char *mmio_vp;
+ unsigned long mmio_pp;
+ spinlock_t docopy_lock; /* Lock to protect memory copy */
+
+ /* Dirty rectangle, protected by delayed_refresh_lock */
+ int x1, y1, x2, y2;
+ bool delayed_refresh;
+ spinlock_t delayed_refresh_lock;
};
static uint screen_width = HVFB_WIDTH;
@@ -260,6 +272,7 @@ static uint screen_width_max = HVFB_WIDTH;
static uint screen_height_max = HVFB_HEIGHT;
static uint screen_depth;
static uint screen_fb_size;
+static uint dio_fb_size; /* FB size for deferred IO */
/* Send message to Hyper-V host */
static inline int synthvid_send(struct hv_device *hdev,
@@ -346,28 +359,88 @@ static int synthvid_send_ptr(struct hv_device *hdev)
}
/* Send updated screen area (dirty rectangle) location to host */
-static int synthvid_update(struct fb_info *info)
+static int
+synthvid_update(struct fb_info *info, int x1, int y1, int x2, int y2)
{
struct hv_device *hdev = device_to_hv_device(info->device);
struct synthvid_msg msg;
memset(&msg, 0, sizeof(struct synthvid_msg));
+ if (x2 == INT_MAX)
+ x2 = info->var.xres;
+ if (y2 == INT_MAX)
+ y2 = info->var.yres;
msg.vid_hdr.type = SYNTHVID_DIRT;
msg.vid_hdr.size = sizeof(struct synthvid_msg_hdr) +
sizeof(struct synthvid_dirt);
msg.dirt.video_output = 0;
msg.dirt.dirt_count = 1;
- msg.dirt.rect[0].x1 = 0;
- msg.dirt.rect[0].y1 = 0;
- msg.dirt.rect[0].x2 = info->var.xres;
- msg.dirt.rect[0].y2 = info->var.yres;
+ msg.dirt.rect[0].x1 = (x1 < 0 || x1 > x2) ? 0 : x1;
+ msg.dirt.rect[0].y1 = (y2 < 0 || y1 > y2) ? 0 : y1;
+ msg.dirt.rect[0].x2 =
+ (x2 < x1 || x2 > info->var.xres) ? info->var.xres : x2;
+ msg.dirt.rect[0].y2 =
+ (y2 < y1 || y2 > info->var.yres) ? info->var.yres : y2;
synthvid_send(hdev, &msg);
return 0;
}
+static void hvfb_docopy(struct hvfb_par *par,
+ unsigned long offset,
+ unsigned long size)
+{
+ if (!par || !par->mmio_vp || !par->dio_vp || !par->fb_ready ||
+ size == 0 || offset >= dio_fb_size)
+ return;
+
+ if (offset + size > dio_fb_size)
+ size = dio_fb_size - offset;
+
+ memcpy(par->mmio_vp + offset, par->dio_vp + offset, size);
+}
+
+/* Deferred IO callback */
+static void synthvid_deferred_io(struct fb_info *p,
+struct list_head *pagelist)
+{
+ struct hvfb_par *par = p->par;
+ struct page *page;
+ unsigned long start, end;
+ int y1, y2, miny, maxy;
+ unsigned long flags;
+
+ miny = INT_MAX;
+ maxy = 0;
+
+ list_for_each_entry(page, pagelist, lru) {
+ start = page->index << PAGE_SHIFT;
+ end = start + PAGE_SIZE - 1;
+ y1 = start / p->fix.line_length;
+ y2 = end / p->fix.line_length;
+ if (y2 > p-
Re: [PATCH] drm/bridge: dw-hdmi: move cec PA invalidation to dw_hdmi_setup_rx_sense()
Hi Jonas,
On 8/13/19 12:18 PM, Jonas Karlman wrote:
> As an alternative I have a patch [1] to submit that moves
> cec_notifier_phys_addr_invalidate() call
> from dw_hdmi_irq() to dw_hdmi_connector_detect() in order to address an issue
> with
> stale CEC phys addr and stale EDID/ELD data after TV or AVR uses a 100ms HPD
> pulse
> to signal EDID has changed, full patchset at [2].
>
> At the moment CEC phys address is invalidated directly at HPD, leaving the
> address as invalid
> after a 100ms HPD pulse, phys address may later be restored to a valid phys
> address when
> get_modes() is called by drm core.
>
> Should I wait on your and related patches to be merged before submitting my
> series?
Let me test your patch on my meson device and see if it solves this issue as
well.
I'll get back to you later today.
Regards,
Hans
>
> [1]
> https://github.com/Kwiboo/linux-rockchip/commit/2f4f99c82983e70952668c21f1c56a0241bd75f2
> [2]
> https://github.com/Kwiboo/linux-rockchip/compare/next-20190813...next-20190813-cec-eld
>
> Regards,
> Jonas
>
> On 2019-08-13 11:34, Hans Verkuil wrote:
>> CC Dariusz as well, since this issue was discovered when testing his
>> CEC patches.
>>
>> Regards,
>>
>> Hans
>>
>> On 8/13/19 11:32 AM, Hans Verkuil wrote:
>>> When testing CEC on the AML-S905X-CC board I noticed that the CEC physical
>>> address was not invalidated when the HDMI cable was unplugged. Some more
>>> digging showed that meson uses meson_dw_hdmi.c to handle the HPD.
>>>
>>> Both dw_hdmi_irq() and dw_hdmi_top_thread_irq() (in meson_dw_hdmi.c) call
>>> the dw_hdmi_setup_rx_sense() function. So move the code to invalidate the
>>> CEC physical address to that function, so that it is independent of where
>>> the HPD interrupt happens.
>>>
>>> Tested with both a AML-S905X-CC and a Khadas VIM2 board.
>>>
>>> Signed-off-by: Hans Verkuil
>>> ---
>>> Note: an alternative would be to make a new dw-hdmi function such as
>>> dw_hdmi_cec_phys_addr_invalidate() that is called from meson_dw_hdmi.c.
>>> I decided not to do that since this patch is minimally invasive, but
>>> that can obviously be changed if that approach is preferred.
>>> ---
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> index c5a854af54f8..e899b31e1432 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -2329,6 +2329,13 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi,
>>> bool hpd, bool rx_sense)
>>> dw_hdmi_update_power(hdmi);
>>> dw_hdmi_update_phy_mask(hdmi);
>>> }
>>> + if (!hpd && !rx_sense) {
>>> + struct cec_notifier *notifier = READ_ONCE(hdmi->cec_notifier);
>>> +
>>> + if (notifier)
>>> + cec_notifier_phys_addr_invalidate(notifier);
>>> + }
>>> +
>>> mutex_unlock(&hdmi->mutex);
>>> }
>>> EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
>>> @@ -2369,14 +2376,6 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>>> dw_hdmi_setup_rx_sense(hdmi,
>>>phy_stat & HDMI_PHY_HPD,
>>>phy_stat & HDMI_PHY_RX_SENSE);
>>> -
>>> - if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) {
>>> - struct cec_notifier *notifier;
>>> -
>>> - notifier = READ_ONCE(hdmi->cec_notifier);
>>> - if (notifier)
>>> - cec_notifier_phys_addr_invalidate(notifier);
>>> - }
>>> }
>>>
>>> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
>>>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Re: [PATCH v2] i2c: replace i2c_new_secondary_device with an ERR_PTR variant
On 8/9/19 5:40 PM, Wolfram Sang wrote:
> In the general move to have i2c_new_*_device functions which return
> ERR_PTR instead of NULL, this patch converts i2c_new_secondary_device().
>
> There are only few users, so this patch converts the I2C core and all
> users in one go. The function gets renamed to i2c_new_ancillary_device()
> so out-of-tree users will get a build failure to understand they need to
> adapt their error checking code.
>
> Signed-off-by: Wolfram Sang
> Reviewed-by: Kieran Bingham #
> adv748x
> Reviewed-by: Laurent Pinchart # adv7511
For adv7604:
Reviewed-by: Hans Verkuil
Thanks!
Hans
> ---
>
> Changes since v1:
>
> * adv7604: use a local variable for error handling
> * adv7604: simplify unregistering dummy clients because I2C core helper
>is NULL ptr aware
> * added tags for adv748x and adv7511
>
> Thanks Kieran and Laurent!
>
>
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 18
> drivers/i2c/i2c-core-base.c | 10 -
> drivers/media/i2c/adv748x/adv748x-core.c | 6 +++---
> drivers/media/i2c/adv7604.c | 22 +++-
> include/linux/i2c.h | 2 +-
> 5 files changed, 30 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index f6d2681f6927..9e13e466e72c 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -981,10 +981,10 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)
> {
> int ret;
>
> - adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec",
> + adv->i2c_cec = i2c_new_ancillary_device(adv->i2c_main, "cec",
> ADV7511_CEC_I2C_ADDR_DEFAULT);
> - if (!adv->i2c_cec)
> - return -EINVAL;
> + if (IS_ERR(adv->i2c_cec))
> + return PTR_ERR(adv->i2c_cec);
> i2c_set_clientdata(adv->i2c_cec, adv);
>
> adv->regmap_cec = devm_regmap_init_i2c(adv->i2c_cec,
> @@ -1165,20 +1165,20 @@ static int adv7511_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id)
>
> adv7511_packet_disable(adv7511, 0x);
>
> - adv7511->i2c_edid = i2c_new_secondary_device(i2c, "edid",
> + adv7511->i2c_edid = i2c_new_ancillary_device(i2c, "edid",
> ADV7511_EDID_I2C_ADDR_DEFAULT);
> - if (!adv7511->i2c_edid) {
> - ret = -EINVAL;
> + if (IS_ERR(adv7511->i2c_edid)) {
> + ret = PTR_ERR(adv7511->i2c_edid);
> goto uninit_regulators;
> }
>
> regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
>adv7511->i2c_edid->addr << 1);
>
> - adv7511->i2c_packet = i2c_new_secondary_device(i2c, "packet",
> + adv7511->i2c_packet = i2c_new_ancillary_device(i2c, "packet",
> ADV7511_PACKET_I2C_ADDR_DEFAULT);
> - if (!adv7511->i2c_packet) {
> - ret = -EINVAL;
> + if (IS_ERR(adv7511->i2c_packet)) {
> + ret = PTR_ERR(adv7511->i2c_packet);
> goto err_i2c_unregister_edid;
> }
>
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index f26ed495d384..76cb91e064b8 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -966,7 +966,7 @@ struct i2c_client *devm_i2c_new_dummy_device(struct
> device *dev,
> EXPORT_SYMBOL_GPL(devm_i2c_new_dummy_device);
>
> /**
> - * i2c_new_secondary_device - Helper to get the instantiated secondary
> address
> + * i2c_new_ancillary_device - Helper to get the instantiated secondary
> address
> * and create the associated device
> * @client: Handle to the primary client
> * @name: Handle to specify which secondary address to get
> @@ -985,9 +985,9 @@ EXPORT_SYMBOL_GPL(devm_i2c_new_dummy_device);
> * cell whose "reg-names" value matches the slave name.
> *
> * This returns the new i2c client, which should be saved for later use with
> - * i2c_unregister_device(); or NULL to indicate an error.
> + * i2c_unregister_device(); or an ERR_PTR to describe the error.
> */
> -struct i2c_client *i2c_new_secondary_device(struct i2c_client *client,
> +struct i2c_client *i2c_new_ancillary_device(struct i2c_client *client,
> const char *name,
> u16 default_addr)
> {
> @@ -1002,9 +1002,9 @@ struct i2c_client *i2c_new_secondary_device(struct
> i2c_client *client,
> }
>
> dev_dbg(&client->adapter->dev, "Address for %s : 0x%x\n", name, addr);
> - return i2c_new_dummy(client->adapter, addr);
> + return i2c_new_dummy_device(client->adapter, addr);
> }
> -EXPORT_SYMBOL_GPL(i2c_new_secondary_device);
> +EXPORT_SYMBOL_GPL(i2c_new_ancillary_device);
>
> /*
[PATCH v6 1/8] drm/i915/intel_hdmi: use cec_notifier_conn_(un)register
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill in
the cec_connector_info.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
Tested-by: Hans Verkuil
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index b1ca8e5bdb56d..9fcf2c58c29c5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2752,8 +2752,9 @@ intel_hdmi_connector_register(struct drm_connector
*connector)
static void intel_hdmi_destroy(struct drm_connector *connector)
{
- if (intel_attached_hdmi(connector)->cec_notifier)
- cec_notifier_put(intel_attached_hdmi(connector)->cec_notifier);
+ struct cec_notifier *n = intel_attached_hdmi(connector)->cec_notifier;
+
+ cec_notifier_conn_unregister(n);
intel_connector_destroy(connector);
}
@@ -3068,6 +3069,7 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
enum port port = intel_encoder->port;
+ struct cec_connector_info conn_info;
DRM_DEBUG_KMS("Adding HDMI connector on port %c\n",
port_name(port));
@@ -3120,8 +3122,11 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
}
- intel_hdmi->cec_notifier = cec_notifier_get_conn(dev->dev,
-port_identifier(port));
+ cec_fill_conn_info_from_drm(&conn_info, connector);
+
+ intel_hdmi->cec_notifier =
+ cec_notifier_conn_register(dev->dev, port_identifier(port),
+ &conn_info);
if (!intel_hdmi->cec_notifier)
DRM_DEBUG_KMS("CEC notifier get failed\n");
}
--
2.23.0.rc1.153.gdeed80330f-goog
[PATCH v6 2/8] dw-hdmi-cec: use cec_notifier_cec_adap_(un)register
Use the new cec_notifier_cec_adap_(un)register() functions to
(un)register the notifier for the CEC adapter.
Also adds CEC_CAP_CONNECTOR_INFO capability to the adapter.
Changes since v3:
- add CEC_CAP_CONNECTOR_INFO to cec_allocate_adapter,
- replace CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT |
CEC_CAP_RC | CEC_CAP_PASSTHROUGH with CEC_CAP_DEFAULTS.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
Tested-by: Hans Verkuil
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
index 0f949978d3fcd..ac1e001d08829 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
@@ -256,8 +256,8 @@ static int dw_hdmi_cec_probe(struct platform_device *pdev)
dw_hdmi_write(cec, 0, HDMI_CEC_POLARITY);
cec->adap = cec_allocate_adapter(&dw_hdmi_cec_ops, cec, "dw_hdmi",
-CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT |
-CEC_CAP_RC | CEC_CAP_PASSTHROUGH,
+CEC_CAP_DEFAULTS |
+CEC_CAP_CONNECTOR_INFO,
CEC_MAX_LOG_ADDRS);
if (IS_ERR(cec->adap))
return PTR_ERR(cec->adap);
@@ -278,13 +278,14 @@ static int dw_hdmi_cec_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
- cec->notify = cec_notifier_get(pdev->dev.parent);
+ cec->notify = cec_notifier_cec_adap_register(pdev->dev.parent,
+NULL, cec->adap);
if (!cec->notify)
return -ENOMEM;
ret = cec_register_adapter(cec->adap, pdev->dev.parent);
if (ret < 0) {
- cec_notifier_put(cec->notify);
+ cec_notifier_cec_adap_unregister(cec->notify);
return ret;
}
@@ -294,8 +295,6 @@ static int dw_hdmi_cec_probe(struct platform_device *pdev)
*/
devm_remove_action(&pdev->dev, dw_hdmi_cec_del, cec);
- cec_register_cec_notifier(cec->adap, cec->notify);
-
return 0;
}
@@ -303,8 +302,8 @@ static int dw_hdmi_cec_remove(struct platform_device *pdev)
{
struct dw_hdmi_cec *cec = platform_get_drvdata(pdev);
+ cec_notifier_cec_adap_unregister(cec->notify);
cec_unregister_adapter(cec->adap);
- cec_notifier_put(cec->notify);
return 0;
}
--
2.23.0.rc1.153.gdeed80330f-goog
[PATCH v6 3/8] tda9950: use cec_notifier_cec_adap_(un)register
Use the new cec_notifier_cec_adap_(un)register() functions to
(un)register the notifier for the CEC adapter.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
Tested-by: Hans Verkuil
---
drivers/gpu/drm/i2c/tda9950.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
index 8039fc0d83db4..a5a75bdeb7a5f 100644
--- a/drivers/gpu/drm/i2c/tda9950.c
+++ b/drivers/gpu/drm/i2c/tda9950.c
@@ -420,7 +420,8 @@ static int tda9950_probe(struct i2c_client *client,
priv->hdmi = glue->parent;
priv->adap = cec_allocate_adapter(&tda9950_cec_ops, priv, "tda9950",
- CEC_CAP_DEFAULTS,
+ CEC_CAP_DEFAULTS |
+ CEC_CAP_CONNECTOR_INFO,
CEC_MAX_LOG_ADDRS);
if (IS_ERR(priv->adap))
return PTR_ERR(priv->adap);
@@ -457,13 +458,14 @@ static int tda9950_probe(struct i2c_client *client,
if (ret < 0)
return ret;
- priv->notify = cec_notifier_get(priv->hdmi);
+ priv->notify = cec_notifier_cec_adap_register(priv->hdmi, NULL,
+ priv->adap);
if (!priv->notify)
return -ENOMEM;
ret = cec_register_adapter(priv->adap, priv->hdmi);
if (ret < 0) {
- cec_notifier_put(priv->notify);
+ cec_notifier_cec_adap_unregister(priv->notify);
return ret;
}
@@ -473,8 +475,6 @@ static int tda9950_probe(struct i2c_client *client,
*/
devm_remove_action(dev, tda9950_cec_del, priv);
- cec_register_cec_notifier(priv->adap, priv->notify);
-
return 0;
}
@@ -482,8 +482,8 @@ static int tda9950_remove(struct i2c_client *client)
{
struct tda9950_priv *priv = i2c_get_clientdata(client);
+ cec_notifier_cec_adap_unregister(priv->notify);
cec_unregister_adapter(priv->adap);
- cec_notifier_put(priv->notify);
return 0;
}
--
2.23.0.rc1.153.gdeed80330f-goog
[PATCH v6 0/8] drm: cec: convert DRM drivers to the new notifier API
This series updates DRM drivers to use new CEC notifier API. Only first two patches were tested on the actual hardware. Changes since v5: Fixed a warning about a missing comment for a new member of drm_dp_aux_cec struct. Sending to a wider audience, including maintainers of respective drivers. Changes since v4: Addressing review comments. Changes since v3: Updated adapter flags in dw-hdmi-cec. Changes since v2: Include all DRM patches from "cec: improve notifier support, add connector info connector info" series. Changes since v1: Those patches delay creation of notifiers until respective connectors are constructed. It seems that those patches, for a couple of drivers, by adding the delay, introduce a race between notifiers' creation and the IRQs handling threads - at least I don't see anything obvious in there that would explicitly forbid such races to occur. v2 adds a write barrier to make sure IRQ threads see the notifier once it is created (replacing the WRITE_ONCE I put in v1). The best thing to do here, I believe, would be not to have any synchronization and make sure that an IRQ only gets enabled after the notifier is created. Dariusz Marcinkiewicz (8): drm/i915/intel_hdmi: use cec_notifier_conn_(un)register dw-hdmi-cec: use cec_notifier_cec_adap_(un)register tda9950: use cec_notifier_cec_adap_(un)register drm: tda998x: use cec_notifier_conn_(un)register drm: sti: use cec_notifier_conn_(un)register drm: tegra: use cec_notifier_conn_(un)register drm: dw-hdmi: use cec_notifier_conn_(un)register drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 13 --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 36 +++ drivers/gpu/drm/exynos/exynos_hdmi.c | 31 +--- drivers/gpu/drm/i2c/tda9950.c | 12 +++ drivers/gpu/drm/i2c/tda998x_drv.c | 33 +++-- drivers/gpu/drm/i915/display/intel_hdmi.c | 13 --- drivers/gpu/drm/sti/sti_hdmi.c| 19 ++ drivers/gpu/drm/tegra/output.c| 28 +++ 8 files changed, 117 insertions(+), 68 deletions(-) -- 2.23.0.rc1.153.gdeed80330f-goog
[PATCH v6 4/8] drm: tda998x: use cec_notifier_conn_(un)register
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill
in the cec_connector_info.
Changes since v2:
- cec_notifier_phys_addr_invalidate where appropriate,
- don't check for NULL notifier before calling
cec_notifier_conn_unregister.
Changes since v1:
Add memory barrier to make sure that the notifier
becomes visible to the irq thread once it is
fully constructed.
Signed-off-by: Dariusz Marcinkiewicz
Tested-by: Hans Verkuil
---
drivers/gpu/drm/i2c/tda998x_drv.c | 33 +--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 61e042918a7fc..19a63ee1b3f53 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -804,9 +804,14 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data)
if (lvl & CEC_RXSHPDLEV_HPD) {
tda998x_edid_delay_start(priv);
} else {
+ struct cec_notifier *notify;
+
schedule_work(&priv->detect_work);
- cec_notifier_set_phys_addr(priv->cec_notify,
- CEC_PHYS_ADDR_INVALID);
+
+ notify = READ_ONCE(priv->cec_notify);
+ if (notify)
+ cec_notifier_phys_addr_invalidate(
+ notify);
}
handled = true;
@@ -1331,6 +1336,8 @@ static int tda998x_connector_init(struct tda998x_priv
*priv,
struct drm_device *drm)
{
struct drm_connector *connector = &priv->connector;
+ struct cec_connector_info conn_info;
+ struct cec_notifier *notifier;
int ret;
connector->interlace_allowed = 1;
@@ -1347,6 +1354,19 @@ static int tda998x_connector_init(struct tda998x_priv
*priv,
if (ret)
return ret;
+ cec_fill_conn_info_from_drm(&conn_info, connector);
+
+ notifier = cec_notifier_conn_register(priv->cec_glue.parent,
+ NULL, &conn_info);
+ if (!notifier)
+ return -ENOMEM;
+ /*
+* Make sure that tda998x_irq_thread does see the notifier
+* when it fully constructed.
+*/
+ smp_wmb();
+ priv->cec_notify = notifier;
+
drm_connector_attach_encoder(&priv->connector,
priv->bridge.encoder);
@@ -1790,8 +1810,7 @@ static void tda998x_destroy(struct device *dev)
i2c_unregister_device(priv->cec);
- if (priv->cec_notify)
- cec_notifier_put(priv->cec_notify);
+ cec_notifier_conn_unregister(priv->cec_notify);
}
static int tda998x_create(struct device *dev)
@@ -1916,12 +1935,6 @@ static int tda998x_create(struct device *dev)
cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD);
}
- priv->cec_notify = cec_notifier_get(dev);
- if (!priv->cec_notify) {
- ret = -ENOMEM;
- goto fail;
- }
-
priv->cec_glue.parent = dev;
priv->cec_glue.data = priv;
priv->cec_glue.init = tda998x_cec_hook_init;
--
2.23.0.rc1.153.gdeed80330f-goog
[PATCH v6 5/8] drm: sti: use cec_notifier_conn_(un)register
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill
in the cec_connector_info.
Changes since v2:
Don't invalidate physical address before unregistering the
notifier.
Signed-off-by: Dariusz Marcinkiewicz
---
drivers/gpu/drm/sti/sti_hdmi.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 9862c322f0c4a..bd15902b825ad 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1256,6 +1256,7 @@ static int sti_hdmi_bind(struct device *dev, struct
device *master, void *data)
struct drm_device *drm_dev = data;
struct drm_encoder *encoder;
struct sti_hdmi_connector *connector;
+ struct cec_connector_info conn_info;
struct drm_connector *drm_connector;
struct drm_bridge *bridge;
int err;
@@ -1318,6 +1319,14 @@ static int sti_hdmi_bind(struct device *dev, struct
device *master, void *data)
goto err_sysfs;
}
+ cec_fill_conn_info_from_drm(&conn_info, drm_connector);
+ hdmi->notifier = cec_notifier_conn_register(&hdmi->dev, NULL,
+ &conn_info);
+ if (!hdmi->notifier) {
+ hdmi->drm_connector = NULL;
+ return -ENOMEM;
+ }
+
/* Enable default interrupts */
hdmi_write(hdmi, HDMI_DEFAULT_INT, HDMI_INT_EN);
@@ -1331,6 +1340,9 @@ static int sti_hdmi_bind(struct device *dev, struct
device *master, void *data)
static void sti_hdmi_unbind(struct device *dev,
struct device *master, void *data)
{
+ struct sti_hdmi *hdmi = dev_get_drvdata(dev);
+
+ cec_notifier_conn_unregister(hdmi->notifier);
}
static const struct component_ops sti_hdmi_ops = {
@@ -1436,10 +1448,6 @@ static int sti_hdmi_probe(struct platform_device *pdev)
goto release_adapter;
}
- hdmi->notifier = cec_notifier_get(&pdev->dev);
- if (!hdmi->notifier)
- goto release_adapter;
-
hdmi->reset = devm_reset_control_get(dev, "hdmi");
/* Take hdmi out of reset */
if (!IS_ERR(hdmi->reset))
@@ -1459,14 +1467,11 @@ static int sti_hdmi_remove(struct platform_device *pdev)
{
struct sti_hdmi *hdmi = dev_get_drvdata(&pdev->dev);
- cec_notifier_set_phys_addr(hdmi->notifier, CEC_PHYS_ADDR_INVALID);
-
i2c_put_adapter(hdmi->ddc_adapt);
if (hdmi->audio_pdev)
platform_device_unregister(hdmi->audio_pdev);
component_del(&pdev->dev, &sti_hdmi_ops);
- cec_notifier_put(hdmi->notifier);
return 0;
}
--
2.23.0.rc1.153.gdeed80330f-goog
[PATCH v6 7/8] drm: dw-hdmi: use cec_notifier_conn_(un)register
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill in
the cec_connector_info.
Changes since v4:
- typo fix
Changes since v2:
- removed unnecessary NULL check before a call to
cec_notifier_conn_unregister,
- use cec_notifier_phys_addr_invalidate to invalidate physical
address.
Changes since v1:
Add memory barrier to make sure that the notifier
becomes visible to the irq thread once it is fully
constructed.
Signed-off-by: Dariusz Marcinkiewicz
Tested-by: Hans Verkuil
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 36 ++-
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 83b94b66e464e..c00184700bb9d 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2194,6 +2194,8 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
*bridge)
struct dw_hdmi *hdmi = bridge->driver_private;
struct drm_encoder *encoder = bridge->encoder;
struct drm_connector *connector = &hdmi->connector;
+ struct cec_connector_info conn_info;
+ struct cec_notifier *notifier;
connector->interlace_allowed = 1;
connector->polled = DRM_CONNECTOR_POLL_HPD;
@@ -2207,6 +2209,18 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
*bridge)
drm_connector_attach_encoder(connector, encoder);
+ cec_fill_conn_info_from_drm(&conn_info, connector);
+
+ notifier = cec_notifier_conn_register(hdmi->dev, NULL, &conn_info);
+ if (!notifier)
+ return -ENOMEM;
+ /*
+* Make sure that dw_hdmi_irq thread does see the notifier
+* when it fully constructed.
+*/
+ smp_wmb();
+ hdmi->cec_notifier = notifier;
+
return 0;
}
@@ -2373,9 +2387,13 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
phy_stat & HDMI_PHY_HPD,
phy_stat & HDMI_PHY_RX_SENSE);
- if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
- cec_notifier_set_phys_addr(hdmi->cec_notifier,
- CEC_PHYS_ADDR_INVALID);
+ if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) {
+ struct cec_notifier *notifier;
+
+ notifier = READ_ONCE(hdmi->cec_notifier);
+ if (notifier)
+ cec_notifier_phys_addr_invalidate(notifier);
+ }
}
if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
@@ -2693,12 +2711,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (ret)
goto err_iahb;
- hdmi->cec_notifier = cec_notifier_get(dev);
- if (!hdmi->cec_notifier) {
- ret = -ENOMEM;
- goto err_iahb;
- }
-
/*
* To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
* N and cts values before enabling phy
@@ -2796,9 +2808,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
hdmi->ddc = NULL;
}
- if (hdmi->cec_notifier)
- cec_notifier_put(hdmi->cec_notifier);
-
clk_disable_unprepare(hdmi->iahb_clk);
if (hdmi->cec_clk)
clk_disable_unprepare(hdmi->cec_clk);
@@ -2820,8 +2829,7 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
/* Disable all interrupts */
hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
- if (hdmi->cec_notifier)
- cec_notifier_put(hdmi->cec_notifier);
+ cec_notifier_conn_unregister(hdmi->cec_notifier);
clk_disable_unprepare(hdmi->iahb_clk);
clk_disable_unprepare(hdmi->isfr_clk);
--
2.23.0.rc1.153.gdeed80330f-goog
[PATCH v6 6/8] drm: tegra: use cec_notifier_conn_(un)register
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill in
the cec_connector_info.
Changes since v4:
- only create a CEC notifier for HDMI connectors
Signed-off-by: Dariusz Marcinkiewicz
Tested-by: Hans Verkuil
---
drivers/gpu/drm/tegra/output.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index bdcaa4c7168cf..34373734ff689 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -70,6 +70,11 @@ tegra_output_connector_detect(struct drm_connector
*connector, bool force)
void tegra_output_connector_destroy(struct drm_connector *connector)
{
+ struct tegra_output *output = connector_to_output(connector);
+
+ if (output->cec)
+ cec_notifier_conn_unregister(output->cec);
+
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
}
@@ -163,18 +168,11 @@ int tegra_output_probe(struct tegra_output *output)
disable_irq(output->hpd_irq);
}
- output->cec = cec_notifier_get(output->dev);
- if (!output->cec)
- return -ENOMEM;
-
return 0;
}
void tegra_output_remove(struct tegra_output *output)
{
- if (output->cec)
- cec_notifier_put(output->cec);
-
if (output->hpd_gpio)
free_irq(output->hpd_irq, output);
@@ -184,6 +182,7 @@ void tegra_output_remove(struct tegra_output *output)
int tegra_output_init(struct drm_device *drm, struct tegra_output *output)
{
+ int connector_type;
int err;
if (output->panel) {
@@ -199,6 +198,21 @@ int tegra_output_init(struct drm_device *drm, struct
tegra_output *output)
if (output->hpd_gpio)
enable_irq(output->hpd_irq);
+ connector_type = output->connector.connector_type;
+ /*
+* Create a CEC notifier for HDMI connector.
+*/
+ if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
+ connector_type == DRM_MODE_CONNECTOR_HDMIB) {
+ struct cec_connector_info conn_info;
+
+ cec_fill_conn_info_from_drm(&conn_info, &output->connector);
+ output->cec = cec_notifier_conn_register(output->dev, NULL,
+&conn_info);
+ if (!output->cec)
+ return -ENOMEM;
+ }
+
return 0;
}
--
2.23.0.rc1.153.gdeed80330f-goog
[PATCH v6 8/8] drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill in
the cec_connector_info.
Changes since v2:
- removed unnecessary call to invalidate phys address before
deregistering the notifier,
- use cec_notifier_phys_addr_invalidate instead of setting
invalid address on a notifier.
Signed-off-by: Dariusz Marcinkiewicz
Tested-by: Hans Verkuil
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 31
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index bc1565f1822ab..d532b468d9af5 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -852,6 +852,10 @@ static enum drm_connector_status hdmi_detect(struct
drm_connector *connector,
static void hdmi_connector_destroy(struct drm_connector *connector)
{
+ struct hdmi_context *hdata = connector_to_hdmi(connector);
+
+ cec_notifier_conn_unregister(hdata->notifier);
+
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
}
@@ -935,6 +939,7 @@ static int hdmi_create_connector(struct drm_encoder
*encoder)
{
struct hdmi_context *hdata = encoder_to_hdmi(encoder);
struct drm_connector *connector = &hdata->connector;
+ struct cec_connector_info conn_info;
int ret;
connector->interlace_allowed = true;
@@ -957,6 +962,15 @@ static int hdmi_create_connector(struct drm_encoder
*encoder)
DRM_DEV_ERROR(hdata->dev, "Failed to attach bridge\n");
}
+ cec_fill_conn_info_from_drm(&conn_info, connector);
+
+ hdata->notifier = cec_notifier_conn_register(hdata->dev, NULL,
+&conn_info);
+ if (hdata->notifier == NULL) {
+ ret = -ENOMEM;
+ DRM_DEV_ERROR(hdata->dev, "Failed to allocate CEC notifier\n");
+ }
+
return ret;
}
@@ -1528,8 +1542,8 @@ static void hdmi_disable(struct drm_encoder *encoder)
*/
mutex_unlock(&hdata->mutex);
cancel_delayed_work(&hdata->hotplug_work);
- cec_notifier_set_phys_addr(hdata->notifier,
- CEC_PHYS_ADDR_INVALID);
+ if (hdata->notifier)
+ cec_notifier_phys_addr_invalidate(hdata->notifier);
return;
}
@@ -2006,12 +2020,6 @@ static int hdmi_probe(struct platform_device *pdev)
}
}
- hdata->notifier = cec_notifier_get(&pdev->dev);
- if (hdata->notifier == NULL) {
- ret = -ENOMEM;
- goto err_hdmiphy;
- }
-
pm_runtime_enable(dev);
audio_infoframe = &hdata->audio.infoframe;
@@ -2023,7 +2031,7 @@ static int hdmi_probe(struct platform_device *pdev)
ret = hdmi_register_audio_device(hdata);
if (ret)
- goto err_notifier_put;
+ goto err_runtime_disable;
ret = component_add(&pdev->dev, &hdmi_component_ops);
if (ret)
@@ -2034,8 +2042,7 @@ static int hdmi_probe(struct platform_device *pdev)
err_unregister_audio:
platform_device_unregister(hdata->audio.pdev);
-err_notifier_put:
- cec_notifier_put(hdata->notifier);
+err_runtime_disable:
pm_runtime_disable(dev);
err_hdmiphy:
@@ -2054,12 +2061,10 @@ static int hdmi_remove(struct platform_device *pdev)
struct hdmi_context *hdata = platform_get_drvdata(pdev);
cancel_delayed_work_sync(&hdata->hotplug_work);
- cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
component_del(&pdev->dev, &hdmi_component_ops);
platform_device_unregister(hdata->audio.pdev);
- cec_notifier_put(hdata->notifier);
pm_runtime_disable(&pdev->dev);
if (!IS_ERR(hdata->reg_hdmi_en))
--
2.23.0.rc1.153.gdeed80330f-goog
[PATCH] drm/komeda: Clean warning 'komeda_component_add' might be a candidate for 'gnu_printf'
komeda/komeda_pipeline.c: In function 'komeda_component_add': komeda/komeda_pipeline.c:212:3: warning: function 'komeda_component_add' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format] vsnprintf(c->name, sizeof(c->name), name_fmt, args); ^ Signed-off-by: james qian wang (Arm Technology China) --- drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h index a90bcbb3cb23..14b683164544 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h @@ -480,6 +480,7 @@ void komeda_pipeline_dump_register(struct komeda_pipeline *pipe, struct seq_file *sf); /* component APIs */ +extern __printf(10, 11) struct komeda_component * komeda_component_add(struct komeda_pipeline *pipe, size_t comp_sz, u32 id, u32 hw_id, -- 2.20.1
Re: [PATCH v2 1/3] arm64: imx8mq: add imx8mq iomux-gpr field defines
On Tue, Aug 13, 2019 at 12:10 PM Guido Günther wrote: > On Tue, Aug 13, 2019 at 10:08:44AM +0200, Arnd Bergmann wrote: > > On Fri, Aug 9, 2019 at 6:24 PM Guido Günther wrote: > > > > > > This adds all the gpr registers and the define needed for selecting > > > the input source in the imx-nwl drm bridge. > > > > > > Signed-off-by: Guido Günther > > > + > > > +#define IOMUXC_GPR00x00 > > > +#define IOMUXC_GPR10x04 > > > +#define IOMUXC_GPR20x08 > > > +#define IOMUXC_GPR30x0c > > > +#define IOMUXC_GPR40x10 > > > +#define IOMUXC_GPR50x14 > > > +#define IOMUXC_GPR60x18 > > > +#define IOMUXC_GPR70x1c > > (more of the same) > > > > huh? > > These are the names from the imx8MQ reference manual (general purpose > registers, they lump together all sorts of things), it's the same on > imx6/imx7): > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/mfd/syscon/imx7-iomuxc-gpr.h > > > > +/* i.MX8Mq iomux gpr register field defines */ > > > +#define IMX8MQ_GPR13_MIPI_MUX_SEL BIT(2) > > > > I think this define should probably be local to the pinctrl driver, to > > ensure that no other drivers fiddle with the registers manually. > > The purpose of these bits is for a driver to fiddle with them to select > the input source. Similar on imx7 it's already used for e.g. the phy > refclk in the pci controller: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pci-imx6.c#n638 That one should likely use either the clk interface or the phy interface instead. > The GPRs are not about pad configuration but gather all sorts of things > (section 8.2.4 of the imx8mq reference manual): pcie setup, dsi related > bits so I don't think this should be done via a pinctrl > driver. Should we handle that differently than on imx6/7? It would be nice to fix the existing code as well, but for the moment, I only think we should not add more of that. Generally speaking, we can use syscon to do random things that don't have a subsystem of their own, but we should not use it to do things that have an existing driver framework like pinctrl, clock, reset, phy etc. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/8] drm: tda998x: use cec_notifier_conn_(un)register
On Tue, Aug 13, 2019 at 01:02:36PM +0200, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_conn_(un)register() functions to
> (un)register the notifier for the HDMI connector, and fill
> in the cec_connector_info.
>
> Changes since v2:
> - cec_notifier_phys_addr_invalidate where appropriate,
> - don't check for NULL notifier before calling
> cec_notifier_conn_unregister.
> Changes since v1:
> Add memory barrier to make sure that the notifier
> becomes visible to the irq thread once it is
> fully constructed.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Tested-by: Hans Verkuil
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 33 +--
> 1 file changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 61e042918a7fc..19a63ee1b3f53 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -804,9 +804,14 @@ static irqreturn_t tda998x_irq_thread(int irq, void
> *data)
> if (lvl & CEC_RXSHPDLEV_HPD) {
> tda998x_edid_delay_start(priv);
> } else {
> + struct cec_notifier *notify;
> +
> schedule_work(&priv->detect_work);
> - cec_notifier_set_phys_addr(priv->cec_notify,
> -CEC_PHYS_ADDR_INVALID);
> +
> + notify = READ_ONCE(priv->cec_notify);
> + if (notify)
> + cec_notifier_phys_addr_invalidate(
> + notify);
> }
>
> handled = true;
> @@ -1331,6 +1336,8 @@ static int tda998x_connector_init(struct tda998x_priv
> *priv,
> struct drm_device *drm)
> {
> struct drm_connector *connector = &priv->connector;
> + struct cec_connector_info conn_info;
> + struct cec_notifier *notifier;
> int ret;
>
> connector->interlace_allowed = 1;
> @@ -1347,6 +1354,19 @@ static int tda998x_connector_init(struct tda998x_priv
> *priv,
> if (ret)
> return ret;
>
> + cec_fill_conn_info_from_drm(&conn_info, connector);
> +
> + notifier = cec_notifier_conn_register(priv->cec_glue.parent,
> + NULL, &conn_info);
> + if (!notifier)
> + return -ENOMEM;
> + /*
> + * Make sure that tda998x_irq_thread does see the notifier
> + * when it fully constructed.
> + */
> + smp_wmb();
> + priv->cec_notify = notifier;
To nitpick, this comment and the following code do not go together.
I think what you actually mean is:
* Make sure that tda998x_irq_thread sees the notifier
* only after it is fully constructed.
> +
> drm_connector_attach_encoder(&priv->connector,
>priv->bridge.encoder);
>
> @@ -1790,8 +1810,7 @@ static void tda998x_destroy(struct device *dev)
>
> i2c_unregister_device(priv->cec);
>
> - if (priv->cec_notify)
> - cec_notifier_put(priv->cec_notify);
> + cec_notifier_conn_unregister(priv->cec_notify);
This also doesn't make sense: tda998x_destroy() is the opposite of
tda998x_create(). However, tda998x_connector_destroy() is the
opposite of tda998x_connector_create().
By moving the CEC creation code into tda998x_connector_create(), you
are creating the possibility for the following sequence to mess up
CEC and leak:
tda998x_create()
tda998x_connector_create()
tda998x_connector_destroy()
tda998x_connector_create()
tda998x_connector_destroy()
tda998x_destroy()
Anything you create in tda998x_connector_create() must be cleaned up
by tda998x_connector_destroy().
> }
>
> static int tda998x_create(struct device *dev)
> @@ -1916,12 +1935,6 @@ static int tda998x_create(struct device *dev)
> cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD);
> }
>
> - priv->cec_notify = cec_notifier_get(dev);
> - if (!priv->cec_notify) {
> - ret = -ENOMEM;
> - goto fail;
> - }
> -
> priv->cec_glue.parent = dev;
> priv->cec_glue.data = priv;
> priv->cec_glue.init = tda998x_cec_hook_init;
> --
> 2.23.0.rc1.153.gdeed80330f-goog
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH] drm/bridge: dw-hdmi: move cec PA invalidation to dw_hdmi_setup_rx_sense()
On 8/13/19 12:18 PM, Jonas Karlman wrote:
> As an alternative I have a patch [1] to submit that moves
> cec_notifier_phys_addr_invalidate() call
> from dw_hdmi_irq() to dw_hdmi_connector_detect() in order to address an issue
> with
> stale CEC phys addr and stale EDID/ELD data after TV or AVR uses a 100ms HPD
> pulse
> to signal EDID has changed, full patchset at [2].
>
> At the moment CEC phys address is invalidated directly at HPD, leaving the
> address as invalid
> after a 100ms HPD pulse, phys address may later be restored to a valid phys
> address when
> get_modes() is called by drm core.
>
> Should I wait on your and related patches to be merged before submitting my
> series?
Your patch fixes this issue as well, so just ignore my patch and submit your
series.
Please CC me when you post your series.
Regards,
Hans
>
> [1]
> https://github.com/Kwiboo/linux-rockchip/commit/2f4f99c82983e70952668c21f1c56a0241bd75f2
> [2]
> https://github.com/Kwiboo/linux-rockchip/compare/next-20190813...next-20190813-cec-eld
>
> Regards,
> Jonas
>
> On 2019-08-13 11:34, Hans Verkuil wrote:
>> CC Dariusz as well, since this issue was discovered when testing his
>> CEC patches.
>>
>> Regards,
>>
>> Hans
>>
>> On 8/13/19 11:32 AM, Hans Verkuil wrote:
>>> When testing CEC on the AML-S905X-CC board I noticed that the CEC physical
>>> address was not invalidated when the HDMI cable was unplugged. Some more
>>> digging showed that meson uses meson_dw_hdmi.c to handle the HPD.
>>>
>>> Both dw_hdmi_irq() and dw_hdmi_top_thread_irq() (in meson_dw_hdmi.c) call
>>> the dw_hdmi_setup_rx_sense() function. So move the code to invalidate the
>>> CEC physical address to that function, so that it is independent of where
>>> the HPD interrupt happens.
>>>
>>> Tested with both a AML-S905X-CC and a Khadas VIM2 board.
>>>
>>> Signed-off-by: Hans Verkuil
>>> ---
>>> Note: an alternative would be to make a new dw-hdmi function such as
>>> dw_hdmi_cec_phys_addr_invalidate() that is called from meson_dw_hdmi.c.
>>> I decided not to do that since this patch is minimally invasive, but
>>> that can obviously be changed if that approach is preferred.
>>> ---
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> index c5a854af54f8..e899b31e1432 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -2329,6 +2329,13 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi,
>>> bool hpd, bool rx_sense)
>>> dw_hdmi_update_power(hdmi);
>>> dw_hdmi_update_phy_mask(hdmi);
>>> }
>>> + if (!hpd && !rx_sense) {
>>> + struct cec_notifier *notifier = READ_ONCE(hdmi->cec_notifier);
>>> +
>>> + if (notifier)
>>> + cec_notifier_phys_addr_invalidate(notifier);
>>> + }
>>> +
>>> mutex_unlock(&hdmi->mutex);
>>> }
>>> EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
>>> @@ -2369,14 +2376,6 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>>> dw_hdmi_setup_rx_sense(hdmi,
>>>phy_stat & HDMI_PHY_HPD,
>>>phy_stat & HDMI_PHY_RX_SENSE);
>>> -
>>> - if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) {
>>> - struct cec_notifier *notifier;
>>> -
>>> - notifier = READ_ONCE(hdmi->cec_notifier);
>>> - if (notifier)
>>> - cec_notifier_phys_addr_invalidate(notifier);
>>> - }
>>> }
>>>
>>> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
>>>
>
Re: [PATCH v6 3/8] tda9950: use cec_notifier_cec_adap_(un)register
On Tue, Aug 13, 2019 at 01:02:35PM +0200, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_cec_adap_(un)register() functions to
> (un)register the notifier for the CEC adapter.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Signed-off-by: Hans Verkuil
> Tested-by: Hans Verkuil
> ---
> drivers/gpu/drm/i2c/tda9950.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
> index 8039fc0d83db4..a5a75bdeb7a5f 100644
> --- a/drivers/gpu/drm/i2c/tda9950.c
> +++ b/drivers/gpu/drm/i2c/tda9950.c
> @@ -420,7 +420,8 @@ static int tda9950_probe(struct i2c_client *client,
> priv->hdmi = glue->parent;
>
> priv->adap = cec_allocate_adapter(&tda9950_cec_ops, priv, "tda9950",
> - CEC_CAP_DEFAULTS,
> + CEC_CAP_DEFAULTS |
> + CEC_CAP_CONNECTOR_INFO,
> CEC_MAX_LOG_ADDRS);
> if (IS_ERR(priv->adap))
> return PTR_ERR(priv->adap);
> @@ -457,13 +458,14 @@ static int tda9950_probe(struct i2c_client *client,
> if (ret < 0)
> return ret;
>
> - priv->notify = cec_notifier_get(priv->hdmi);
> + priv->notify = cec_notifier_cec_adap_register(priv->hdmi, NULL,
> + priv->adap);
> if (!priv->notify)
> return -ENOMEM;
>
> ret = cec_register_adapter(priv->adap, priv->hdmi);
> if (ret < 0) {
> - cec_notifier_put(priv->notify);
> + cec_notifier_cec_adap_unregister(priv->notify);
> return ret;
> }
>
> @@ -473,8 +475,6 @@ static int tda9950_probe(struct i2c_client *client,
>*/
> devm_remove_action(dev, tda9950_cec_del, priv);
>
> - cec_register_cec_notifier(priv->adap, priv->notify);
> -
> return 0;
> }
>
> @@ -482,8 +482,8 @@ static int tda9950_remove(struct i2c_client *client)
> {
> struct tda9950_priv *priv = i2c_get_clientdata(client);
>
> + cec_notifier_cec_adap_unregister(priv->notify);
> cec_unregister_adapter(priv->adap);
> - cec_notifier_put(priv->notify);
It looks weird to have an unexpectedly different ordering of
unregistration from the registration path - normally, unregistration
is the reverse order of initialisation.
In the initialisation path, it seems that we register the notifier
and _then_ the adapter. Here, we unregister the notifier and then
the adapter rather than what would normally be expected. Why is
this? I suspect there will be drivers created that do this the
"normal" way round, so if this is a requirement, it needs to be made
plainly obvious.
>
> return 0;
> }
> --
> 2.23.0.rc1.153.gdeed80330f-goog
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH v6 7/8] drm: dw-hdmi: use cec_notifier_conn_(un)register
On 8/13/19 1:02 PM, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_conn_(un)register() functions to
> (un)register the notifier for the HDMI connector, and fill in
> the cec_connector_info.
>
> Changes since v4:
> - typo fix
> Changes since v2:
> - removed unnecessary NULL check before a call to
> cec_notifier_conn_unregister,
> - use cec_notifier_phys_addr_invalidate to invalidate physical
> address.
> Changes since v1:
> Add memory barrier to make sure that the notifier
> becomes visible to the irq thread once it is fully
> constructed.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Tested-by: Hans Verkuil
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 36 ++-
> 1 file changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 83b94b66e464e..c00184700bb9d 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2194,6 +2194,8 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
> *bridge)
> struct dw_hdmi *hdmi = bridge->driver_private;
> struct drm_encoder *encoder = bridge->encoder;
> struct drm_connector *connector = &hdmi->connector;
> + struct cec_connector_info conn_info;
> + struct cec_notifier *notifier;
>
> connector->interlace_allowed = 1;
> connector->polled = DRM_CONNECTOR_POLL_HPD;
> @@ -2207,6 +2209,18 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
> *bridge)
>
> drm_connector_attach_encoder(connector, encoder);
>
> + cec_fill_conn_info_from_drm(&conn_info, connector);
> +
> + notifier = cec_notifier_conn_register(hdmi->dev, NULL, &conn_info);
> + if (!notifier)
> + return -ENOMEM;
> + /*
> + * Make sure that dw_hdmi_irq thread does see the notifier
> + * when it fully constructed.
> + */
> + smp_wmb();
> + hdmi->cec_notifier = notifier;
> +
> return 0;
> }
>
> @@ -2373,9 +2387,13 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> phy_stat & HDMI_PHY_HPD,
> phy_stat & HDMI_PHY_RX_SENSE);
>
> - if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
> - cec_notifier_set_phys_addr(hdmi->cec_notifier,
> -CEC_PHYS_ADDR_INVALID);
> + if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) {
> + struct cec_notifier *notifier;
> +
> + notifier = READ_ONCE(hdmi->cec_notifier);
> + if (notifier)
> + cec_notifier_phys_addr_invalidate(notifier);
> + }
> }
>
> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
> @@ -2693,12 +2711,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
> if (ret)
> goto err_iahb;
>
> - hdmi->cec_notifier = cec_notifier_get(dev);
> - if (!hdmi->cec_notifier) {
> - ret = -ENOMEM;
> - goto err_iahb;
> - }
> -
> /*
>* To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
>* N and cts values before enabling phy
> @@ -2796,9 +2808,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
> hdmi->ddc = NULL;
> }
>
> - if (hdmi->cec_notifier)
> - cec_notifier_put(hdmi->cec_notifier);
> -
> clk_disable_unprepare(hdmi->iahb_clk);
> if (hdmi->cec_clk)
> clk_disable_unprepare(hdmi->cec_clk);
> @@ -2820,8 +2829,7 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
> /* Disable all interrupts */
> hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
>
> - if (hdmi->cec_notifier)
> - cec_notifier_put(hdmi->cec_notifier);
> + cec_notifier_conn_unregister(hdmi->cec_notifier);
Russell's review caused me to take another look at this series, and it made
wonder if cec_notifier_conn_unregister() shouldn't be called from bridge_detach?
Regards,
Hans
>
> clk_disable_unprepare(hdmi->iahb_clk);
> clk_disable_unprepare(hdmi->isfr_clk);
>
Re: [PATCH] drm/bridge: dw-hdmi: move cec PA invalidation to dw_hdmi_setup_rx_sense()
On 2019-08-13 13:27, Hans Verkuil wrote:
> On 8/13/19 12:18 PM, Jonas Karlman wrote:
>> As an alternative I have a patch [1] to submit that moves
>> cec_notifier_phys_addr_invalidate() call
>> from dw_hdmi_irq() to dw_hdmi_connector_detect() in order to address an
>> issue with
>> stale CEC phys addr and stale EDID/ELD data after TV or AVR uses a 100ms HPD
>> pulse
>> to signal EDID has changed, full patchset at [2].
>>
>> At the moment CEC phys address is invalidated directly at HPD, leaving the
>> address as invalid
>> after a 100ms HPD pulse, phys address may later be restored to a valid phys
>> address when
>> get_modes() is called by drm core.
>>
>> Should I wait on your and related patches to be merged before submitting my
>> series?
> Your patch fixes this issue as well, so just ignore my patch and submit your
> series.
> Please CC me when you post your series.
Thanks for testing, I will include you in CC when I submit my series later
today or tomorrow.
Regards,
Jonas
>
> Regards,
>
> Hans
>
>> [1]
>> https://github.com/Kwiboo/linux-rockchip/commit/2f4f99c82983e70952668c21f1c56a0241bd75f2
>> [2]
>> https://github.com/Kwiboo/linux-rockchip/compare/next-20190813...next-20190813-cec-eld
>>
>> Regards,
>> Jonas
>>
>> On 2019-08-13 11:34, Hans Verkuil wrote:
>>> CC Dariusz as well, since this issue was discovered when testing his
>>> CEC patches.
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>> On 8/13/19 11:32 AM, Hans Verkuil wrote:
>>>> When testing CEC on the AML-S905X-CC board I noticed that the CEC physical
>>>> address was not invalidated when the HDMI cable was unplugged. Some more
>>>> digging showed that meson uses meson_dw_hdmi.c to handle the HPD.
>>>>
>>>> Both dw_hdmi_irq() and dw_hdmi_top_thread_irq() (in meson_dw_hdmi.c) call
>>>> the dw_hdmi_setup_rx_sense() function. So move the code to invalidate the
>>>> CEC physical address to that function, so that it is independent of where
>>>> the HPD interrupt happens.
>>>>
>>>> Tested with both a AML-S905X-CC and a Khadas VIM2 board.
>>>>
>>>> Signed-off-by: Hans Verkuil
>>>> ---
>>>> Note: an alternative would be to make a new dw-hdmi function such as
>>>> dw_hdmi_cec_phys_addr_invalidate() that is called from meson_dw_hdmi.c.
>>>> I decided not to do that since this patch is minimally invasive, but
>>>> that can obviously be changed if that approach is preferred.
>>>> ---
>>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>> index c5a854af54f8..e899b31e1432 100644
>>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>>> @@ -2329,6 +2329,13 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi,
>>>> bool hpd, bool rx_sense)
>>>>dw_hdmi_update_power(hdmi);
>>>>dw_hdmi_update_phy_mask(hdmi);
>>>>}
>>>> + if (!hpd && !rx_sense) {
>>>> + struct cec_notifier *notifier = READ_ONCE(hdmi->cec_notifier);
>>>> +
>>>> + if (notifier)
>>>> + cec_notifier_phys_addr_invalidate(notifier);
>>>> + }
>>>> +
>>>>mutex_unlock(&hdmi->mutex);
>>>> }
>>>> EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
>>>> @@ -2369,14 +2376,6 @@ static irqreturn_t dw_hdmi_irq(int irq, void
>>>> *dev_id)
>>>>dw_hdmi_setup_rx_sense(hdmi,
>>>> phy_stat & HDMI_PHY_HPD,
>>>> phy_stat & HDMI_PHY_RX_SENSE);
>>>> -
>>>> - if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) {
>>>> - struct cec_notifier *notifier;
>>>> -
>>>> - notifier = READ_ONCE(hdmi->cec_notifier);
>>>> - if (notifier)
>>>> - cec_notifier_phys_addr_invalidate(notifier);
>>>> - }
>>>>}
>>>>
>>>>if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
>>>>
Re: [PATCH] drm/bridge: dw-hdmi: move cec PA invalidation to dw_hdmi_setup_rx_sense()
On 8/13/19 11:32 AM, Hans Verkuil wrote:
> When testing CEC on the AML-S905X-CC board I noticed that the CEC physical
> address was not invalidated when the HDMI cable was unplugged. Some more
> digging showed that meson uses meson_dw_hdmi.c to handle the HPD.
>
> Both dw_hdmi_irq() and dw_hdmi_top_thread_irq() (in meson_dw_hdmi.c) call
> the dw_hdmi_setup_rx_sense() function. So move the code to invalidate the
> CEC physical address to that function, so that it is independent of where
> the HPD interrupt happens.
>
> Tested with both a AML-S905X-CC and a Khadas VIM2 board.
>
> Signed-off-by: Hans Verkuil
Please disregard this patch, Jonas Karlman will post a different series
which will fix this in a different way.
Regards,
Hans
> ---
> Note: an alternative would be to make a new dw-hdmi function such as
> dw_hdmi_cec_phys_addr_invalidate() that is called from meson_dw_hdmi.c.
> I decided not to do that since this patch is minimally invasive, but
> that can obviously be changed if that approach is preferred.
> ---
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index c5a854af54f8..e899b31e1432 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2329,6 +2329,13 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool
> hpd, bool rx_sense)
> dw_hdmi_update_power(hdmi);
> dw_hdmi_update_phy_mask(hdmi);
> }
> + if (!hpd && !rx_sense) {
> + struct cec_notifier *notifier = READ_ONCE(hdmi->cec_notifier);
> +
> + if (notifier)
> + cec_notifier_phys_addr_invalidate(notifier);
> + }
> +
> mutex_unlock(&hdmi->mutex);
> }
> EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
> @@ -2369,14 +2376,6 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> dw_hdmi_setup_rx_sense(hdmi,
> phy_stat & HDMI_PHY_HPD,
> phy_stat & HDMI_PHY_RX_SENSE);
> -
> - if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) {
> - struct cec_notifier *notifier;
> -
> - notifier = READ_ONCE(hdmi->cec_notifier);
> - if (notifier)
> - cec_notifier_phys_addr_invalidate(notifier);
> - }
> }
>
> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
>
Re: [PATCH v6 3/8] tda9950: use cec_notifier_cec_adap_(un)register
On 8/13/19 1:32 PM, Russell King - ARM Linux admin wrote:
> On Tue, Aug 13, 2019 at 01:02:35PM +0200, Dariusz Marcinkiewicz wrote:
>> Use the new cec_notifier_cec_adap_(un)register() functions to
>> (un)register the notifier for the CEC adapter.
>>
>> Signed-off-by: Dariusz Marcinkiewicz
>> Signed-off-by: Hans Verkuil
>> Tested-by: Hans Verkuil
>> ---
>> drivers/gpu/drm/i2c/tda9950.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
>> index 8039fc0d83db4..a5a75bdeb7a5f 100644
>> --- a/drivers/gpu/drm/i2c/tda9950.c
>> +++ b/drivers/gpu/drm/i2c/tda9950.c
>> @@ -420,7 +420,8 @@ static int tda9950_probe(struct i2c_client *client,
>> priv->hdmi = glue->parent;
>>
>> priv->adap = cec_allocate_adapter(&tda9950_cec_ops, priv, "tda9950",
>> - CEC_CAP_DEFAULTS,
>> + CEC_CAP_DEFAULTS |
>> + CEC_CAP_CONNECTOR_INFO,
>>CEC_MAX_LOG_ADDRS);
>> if (IS_ERR(priv->adap))
>> return PTR_ERR(priv->adap);
>> @@ -457,13 +458,14 @@ static int tda9950_probe(struct i2c_client *client,
>> if (ret < 0)
>> return ret;
>>
>> -priv->notify = cec_notifier_get(priv->hdmi);
>> +priv->notify = cec_notifier_cec_adap_register(priv->hdmi, NULL,
>> + priv->adap);
>> if (!priv->notify)
>> return -ENOMEM;
>>
>> ret = cec_register_adapter(priv->adap, priv->hdmi);
>> if (ret < 0) {
>> -cec_notifier_put(priv->notify);
>> +cec_notifier_cec_adap_unregister(priv->notify);
>> return ret;
>> }
>>
>> @@ -473,8 +475,6 @@ static int tda9950_probe(struct i2c_client *client,
>> */
>> devm_remove_action(dev, tda9950_cec_del, priv);
>>
>> -cec_register_cec_notifier(priv->adap, priv->notify);
>> -
>> return 0;
>> }
>>
>> @@ -482,8 +482,8 @@ static int tda9950_remove(struct i2c_client *client)
>> {
>> struct tda9950_priv *priv = i2c_get_clientdata(client);
>>
>> +cec_notifier_cec_adap_unregister(priv->notify);
>> cec_unregister_adapter(priv->adap);
>> -cec_notifier_put(priv->notify);
>
> It looks weird to have an unexpectedly different ordering of
> unregistration from the registration path - normally, unregistration
> is the reverse order of initialisation.
>
> In the initialisation path, it seems that we register the notifier
> and _then_ the adapter. Here, we unregister the notifier and then
> the adapter rather than what would normally be expected. Why is
> this? I suspect there will be drivers created that do this the
> "normal" way round, so if this is a requirement, it needs to be made
> plainly obvious.
It's not a requirement, it just feels better to do it in this order
since cec_unregister_adapter will in general also delete the adapter
(unless an application keeps the cec device open).
So the order is actually: allocate_adapter, then register notifier
and: unregister notifier, then unregister (and typically delete) adapter
Regards,
Hans
>
>>
>> return 0;
>> }
>> --
>> 2.23.0.rc1.153.gdeed80330f-goog
>>
>>
>
Re: [PATCH] drm/bridge: dw-hdmi: move cec PA invalidation to dw_hdmi_setup_rx_sense()
Hi Hans,
On 13/08/2019 13:43, Hans Verkuil wrote:
> On 8/13/19 11:32 AM, Hans Verkuil wrote:
>> When testing CEC on the AML-S905X-CC board I noticed that the CEC physical
>> address was not invalidated when the HDMI cable was unplugged. Some more
>> digging showed that meson uses meson_dw_hdmi.c to handle the HPD.
>>
>> Both dw_hdmi_irq() and dw_hdmi_top_thread_irq() (in meson_dw_hdmi.c) call
>> the dw_hdmi_setup_rx_sense() function. So move the code to invalidate the
>> CEC physical address to that function, so that it is independent of where
>> the HPD interrupt happens.
>>
>> Tested with both a AML-S905X-CC and a Khadas VIM2 board.
>>
>> Signed-off-by: Hans Verkuil
>
> Please disregard this patch, Jonas Karlman will post a different series
> which will fix this in a different way.
Noted, thanks.
Neil
>
> Regards,
>
> Hans
>
>> ---
>> Note: an alternative would be to make a new dw-hdmi function such as
>> dw_hdmi_cec_phys_addr_invalidate() that is called from meson_dw_hdmi.c.
>> I decided not to do that since this patch is minimally invasive, but
>> that can obviously be changed if that approach is preferred.
>> ---
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index c5a854af54f8..e899b31e1432 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -2329,6 +2329,13 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi,
>> bool hpd, bool rx_sense)
>> dw_hdmi_update_power(hdmi);
>> dw_hdmi_update_phy_mask(hdmi);
>> }
>> +if (!hpd && !rx_sense) {
>> +struct cec_notifier *notifier = READ_ONCE(hdmi->cec_notifier);
>> +
>> +if (notifier)
>> +cec_notifier_phys_addr_invalidate(notifier);
>> +}
>> +
>> mutex_unlock(&hdmi->mutex);
>> }
>> EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
>> @@ -2369,14 +2376,6 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>> dw_hdmi_setup_rx_sense(hdmi,
>> phy_stat & HDMI_PHY_HPD,
>> phy_stat & HDMI_PHY_RX_SENSE);
>> -
>> -if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) {
>> -struct cec_notifier *notifier;
>> -
>> -notifier = READ_ONCE(hdmi->cec_notifier);
>> -if (notifier)
>> -cec_notifier_phys_addr_invalidate(notifier);
>> -}
>> }
>>
>> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
>>
>
[PATCH resend] video: backlight: Drop default m for {LCD,BACKLIGHT_CLASS_DEVICE}
When running "make oldconfig" on a .config where
CONFIG_BACKLIGHT_LCD_SUPPORT is not set, two new config options
("Lowlevel LCD controls" and "Lowlevel Backlight controls") appear, both
defaulting to "m".
Drop the "default m", as options should default to disabled, and because
several driver config options already select LCD_CLASS_DEVICE or
BACKLIGHT_CLASS_DEVICE when needed.
Fixes: 8c5dc8d9f19c7992 ("video: backlight: Remove useless
BACKLIGHT_LCD_SUPPORT kernel symbol")
Signed-off-by: Geert Uytterhoeven
---
drivers/video/backlight/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 8b081d61773e21eb..40676be2e46aae61 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -10,7 +10,6 @@ menu "Backlight & LCD device support"
#
config LCD_CLASS_DEVICE
tristate "Lowlevel LCD controls"
- default m
help
This framework adds support for low-level control of LCD.
Some framebuffer devices connect to platform-specific LCD modules
@@ -143,7 +142,6 @@ endif # LCD_CLASS_DEVICE
#
config BACKLIGHT_CLASS_DEVICE
tristate "Lowlevel Backlight controls"
- default m
help
This framework adds support for low-level control of the LCD
backlight. This includes support for brightness and power.
--
2.17.1
Re: [PATCH] drm/bridge: dumb-vga-dac: Fix dereferencing -ENODEV DDC channel
Hi,
On 13/08/2019 11:30, Geert Uytterhoeven wrote:
> If the VGA connector has no DDC channel, an error pointer will be
> dereferenced, e.g. on Salvator-XS:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 017d
> ...
> Call trace:
> sysfs_do_create_link_sd.isra.0+0x40/0x108
> sysfs_create_link+0x20/0x40
> drm_sysfs_connector_add+0xa8/0xc8
> drm_connector_register.part.3+0x54/0xb0
> drm_connector_register_all+0xb0/0xd0
> drm_modeset_register_all+0x54/0x88
> drm_dev_register+0x18c/0x1d8
> rcar_du_probe+0xe4/0x150
> ...
>
> This happens because vga->ddc either contains a valid DDC channel
> pointer, or -ENODEV, and drm_connector_init_with_ddc() expects a valid
> DDC channel pointer, or NULL.
>
> Fix this by resetting vga->ddc to NULL in case of -ENODEV, and replacing
> the existing error checks by non-NULL checks.
> This is similar to what the HDMI connector driver does.
>
> Fixes: a4f9087e85de141e ("drm/bridge: dumb-vga-dac: Provide ddc symlink in
> connector sysfs directory")
> Signed-off-by: Geert Uytterhoeven
> ---
> An alternative would be to check if vga->ddc contains an error pointer,
> and calling drm_connector_init() instead of
> drm_connector_init_with_ddc(), like before.
> ---
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index 8ef6539ae78a6eb3..7aa789c358829b05 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -42,7 +42,7 @@ static int dumb_vga_get_modes(struct drm_connector
> *connector)
> struct edid *edid;
> int ret;
>
> - if (IS_ERR(vga->ddc))
> + if (!vga->ddc)
> goto fallback;
>
> edid = drm_get_edid(connector, vga->ddc);
> @@ -84,7 +84,7 @@ dumb_vga_connector_detect(struct drm_connector *connector,
> bool force)
>* wire the DDC pins, or the I2C bus might not be working at
>* all.
>*/
> - if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
> + if (vga->ddc && drm_probe_ddc(vga->ddc))
> return connector_status_connected;
>
> return connector_status_unknown;
> @@ -197,6 +197,7 @@ static int dumb_vga_probe(struct platform_device *pdev)
> if (PTR_ERR(vga->ddc) == -ENODEV) {
> dev_dbg(&pdev->dev,
> "No i2c bus specified. Disabling EDID
> readout\n");
> + vga->ddc = NULL;
> } else {
> dev_err(&pdev->dev, "Couldn't retrieve i2c bus\n");
> return PTR_ERR(vga->ddc);
> @@ -218,7 +219,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
>
> drm_bridge_remove(&vga->bridge);
>
> - if (!IS_ERR(vga->ddc))
> + if (vga->ddc)
> i2c_put_adapter(vga->ddc);
>
> return 0;
>
Looks sane,
Reviewed-by: Neil Armstrong
Guenter, can you confirm it also fixes qemu:versatilepb ?
Neil
Re: [PATCH 02/26] drm/dp_mst: Destroy mstbs from destroy_connector_work
On Wed, Jul 17, 2019 at 09:42:25PM -0400, Lyude Paul wrote:
> Currently we remove MST branch devices from the in-memory topology
> immediately when their topology refcount reaches 0. This works just fine
> at the moment, but since we're about to add suspend/resume reprobing for
> MST topologies we're going to need to be able to travel through the
> topology and drop topology refs on branch devices while holding
> mgr->mutex. Since we currently can't do this due to the circular locking
> dependencies that would incur, move all of the actual work for
> drm_dp_destroy_mst_branch_device() into drm_dp_destroy_connector_work()
> so we can drop topology refs on MSTBs in any locking context.
Would be good to point at where exactly the problem is here, maybe also
mentioned the exact future patch that causes the problem. I did go look
around a bit, but didn't spot it.
>
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 121 +-
> include/drm/drm_dp_mst_helper.h | 10 +++
> 2 files changed, 90 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 998081b9b205..d7c3d9233834 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1108,34 +1108,17 @@ static void drm_dp_destroy_mst_branch_device(struct
> kref *kref)
> struct drm_dp_mst_branch *mstb =
> container_of(kref, struct drm_dp_mst_branch, topology_kref);
> struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
> - struct drm_dp_mst_port *port, *tmp;
> - bool wake_tx = false;
> -
> - mutex_lock(&mgr->lock);
> - list_for_each_entry_safe(port, tmp, &mstb->ports, next) {
> - list_del(&port->next);
> - drm_dp_mst_topology_put_port(port);
> - }
> - mutex_unlock(&mgr->lock);
> -
> - /* drop any tx slots msg */
> - mutex_lock(&mstb->mgr->qlock);
> - if (mstb->tx_slots[0]) {
> - mstb->tx_slots[0]->state = DRM_DP_SIDEBAND_TX_TIMEOUT;
> - mstb->tx_slots[0] = NULL;
> - wake_tx = true;
> - }
> - if (mstb->tx_slots[1]) {
> - mstb->tx_slots[1]->state = DRM_DP_SIDEBAND_TX_TIMEOUT;
> - mstb->tx_slots[1] = NULL;
> - wake_tx = true;
> - }
> - mutex_unlock(&mstb->mgr->qlock);
>
> - if (wake_tx)
> - wake_up_all(&mstb->mgr->tx_waitq);
> + INIT_LIST_HEAD(&mstb->destroy_next);
>
> - drm_dp_mst_put_mstb_malloc(mstb);
> + /*
> + * This can get called under mgr->mutex, so we need to perform the
> + * actual destruction of the mstb in another worker
> + */
> + mutex_lock(&mgr->destroy_connector_lock);
> + list_add(&mstb->destroy_next, &mgr->destroy_branch_device_list);
> + mutex_unlock(&mgr->destroy_connector_lock);
> + schedule_work(&mgr->destroy_connector_work);
> }
>
> /**
> @@ -3618,10 +3601,56 @@ static void drm_dp_tx_work(struct work_struct *work)
> mutex_unlock(&mgr->qlock);
> }
>
> +static inline void
> +drm_dp_finish_destroy_port(struct drm_dp_mst_port *port)
Bikeshed: I'd call this _delayed_destroy, I think that makes a bit clearer
why there's 2 stages to destroying stuff.
> +{
> + INIT_LIST_HEAD(&port->next);
> +
> + port->mgr->cbs->destroy_connector(port->mgr, port->connector);
> +
> + drm_dp_port_teardown_pdt(port, port->pdt);
> + port->pdt = DP_PEER_DEVICE_NONE;
> +
> + drm_dp_mst_put_port_malloc(port);
> +}
> +
> +static inline void
> +drm_dp_finish_destroy_mst_branch_device(struct drm_dp_mst_branch *mstb)
> +{
> + struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
> + struct drm_dp_mst_port *port, *tmp;
> + bool wake_tx = false;
> +
> + mutex_lock(&mgr->lock);
> + list_for_each_entry_safe(port, tmp, &mstb->ports, next) {
> + list_del(&port->next);
> + drm_dp_mst_topology_put_port(port);
> + }
> + mutex_unlock(&mgr->lock);
> +
> + /* drop any tx slots msg */
> + mutex_lock(&mstb->mgr->qlock);
> + if (mstb->tx_slots[0]) {
> + mstb->tx_slots[0]->state = DRM_DP_SIDEBAND_TX_TIMEOUT;
> + mstb->tx_slots[0] = NULL;
> + wake_tx = true;
> + }
> + if (mstb->tx_slots[1]) {
> + mstb->tx_slots[1]->state = DRM_DP_SIDEBAND_TX_TIMEOUT;
> + mstb->tx_slots[1] = NULL;
> + wake_tx = true;
> + }
> + mutex_unlock(&mstb->mgr->qlock);
> +
> + if (wake_tx)
> + wake_up_all(&mstb->mgr->tx_waitq);
> +
> + drm_dp_mst_put_mstb_malloc(mstb);
> +}
> +
> static void drm_dp_destroy_connector_work(struct work_struct *work)
> {
> struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct
> drm_dp_mst_topology_mgr, destroy_connector_work);
> - struct drm_dp_mst_port *port;
> bool send_hotplug =
Re: [PATCH 03/26] drm/dp_mst: Move test_calc_pbn_mode() into an actual selftest
On Wed, Jul 17, 2019 at 09:42:26PM -0400, Lyude Paul wrote:
> Yes, apparently we've been testing this for every single driver load for
> quite a long time now. At least that means our PBN calculation is solid!
>
> Anyway, introduce self tests for MST and move this into there.
>
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Signed-off-by: Lyude Paul
More official unit tests, yay!
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 27 --
> drivers/gpu/drm/selftests/Makefile| 2 +-
> .../gpu/drm/selftests/drm_modeset_selftests.h | 1 +
> .../drm/selftests/test-drm_dp_mst_helper.c| 36 +++
> .../drm/selftests/test-drm_modeset_common.h | 1 +
> 5 files changed, 39 insertions(+), 28 deletions(-)
> create mode 100644 drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index d7c3d9233834..9e382117896d 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -45,7 +45,6 @@
> */
> static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr,
> char *buf);
> -static int test_calc_pbn_mode(void);
>
> static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
>
> @@ -3439,30 +3438,6 @@ int drm_dp_calc_pbn_mode(int clock, int bpp)
> }
> EXPORT_SYMBOL(drm_dp_calc_pbn_mode);
>
> -static int test_calc_pbn_mode(void)
> -{
> - int ret;
> - ret = drm_dp_calc_pbn_mode(154000, 30);
> - if (ret != 689) {
> - DRM_ERROR("PBN calculation test failed - clock %d, bpp %d,
> expected PBN %d, actual PBN %d.\n",
> - 154000, 30, 689, ret);
> - return -EINVAL;
> - }
> - ret = drm_dp_calc_pbn_mode(234000, 30);
> - if (ret != 1047) {
> - DRM_ERROR("PBN calculation test failed - clock %d, bpp %d,
> expected PBN %d, actual PBN %d.\n",
> - 234000, 30, 1047, ret);
> - return -EINVAL;
> - }
> - ret = drm_dp_calc_pbn_mode(297000, 24);
> - if (ret != 1063) {
> - DRM_ERROR("PBN calculation test failed - clock %d, bpp %d,
> expected PBN %d, actual PBN %d.\n",
> - 297000, 24, 1063, ret);
> - return -EINVAL;
> - }
> - return 0;
> -}
> -
> /* we want to kick the TX after we've ack the up/down IRQs. */
> static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr)
> {
> @@ -3898,8 +3873,6 @@ int drm_dp_mst_topology_mgr_init(struct
> drm_dp_mst_topology_mgr *mgr,
> if (!mgr->proposed_vcpis)
> return -ENOMEM;
> set_bit(0, &mgr->payload_mask);
> - if (test_calc_pbn_mode() < 0)
> - DRM_ERROR("MST PBN self-test failed\n");
>
> mst_state = kzalloc(sizeof(*mst_state), GFP_KERNEL);
> if (mst_state == NULL)
> diff --git a/drivers/gpu/drm/selftests/Makefile
> b/drivers/gpu/drm/selftests/Makefile
> index aae88f8a016c..d2137342b371 100644
> --- a/drivers/gpu/drm/selftests/Makefile
> +++ b/drivers/gpu/drm/selftests/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
> test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
>test-drm_format.o test-drm_framebuffer.o \
> - test-drm_damage_helper.o
> + test-drm_damage_helper.o test-drm_dp_mst_helper.o
>
> obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
> test-drm_cmdline_parser.o
> diff --git a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
> b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
> index 464753746013..dec3ee3ec96f 100644
> --- a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
> +++ b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
> @@ -32,3 +32,4 @@ selftest(damage_iter_damage_one_intersect,
> igt_damage_iter_damage_one_intersect)
> selftest(damage_iter_damage_one_outside, igt_damage_iter_damage_one_outside)
> selftest(damage_iter_damage_src_moved, igt_damage_iter_damage_src_moved)
> selftest(damage_iter_damage_not_visible, igt_damage_iter_damage_not_visible)
> +selftest(dp_mst_calc_pbn_mode, igt_dp_mst_calc_pbn_mode)
> diff --git a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> new file mode 100644
> index ..51b2486ec917
> --- /dev/null
> +++ b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Test cases for for the DRM DP MST helpers
> + */
> +
> +#define pr_fmt(fmt) "drm_dp_mst_helper: " fmt
> +
> +#include
> +#include
> +
> +#include "test-drm_modeset_common.h"
> +
> +int igt_dp_mst_calc_pbn_mode(void *ignored)
> +{
> + int pbn, i;
> + const struct {
> + int rate;
> + int bpp;
> + i
Re: [PATCH 04/26] drm/print: Add drm_err_printer()
On Wed, Jul 17, 2019 at 09:42:27PM -0400, Lyude Paul wrote:
> A simple convienence function that returns a drm_printer which prints
> using pr_err()
>
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_print.c | 6 ++
> include/drm/drm_print.h | 17 +
> 2 files changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index a17c8a14dba4..6112be358769 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -147,6 +147,12 @@ void __drm_printfn_debug(struct drm_printer *p, struct
> va_format *vaf)
> }
> EXPORT_SYMBOL(__drm_printfn_debug);
>
> +void __drm_printfn_err(struct drm_printer *p, struct va_format *vaf)
> +{
> + pr_err("%s %pV", p->prefix, vaf);
DRM printing is a huge bikeshad (or tire fire?). We can't call DRM_ERROR,
but for consistency mabye emulate the layout?
Either way: Reviewed-by: Daniel Vetter
> +}
> +EXPORT_SYMBOL(__drm_printfn_err);
> +
> /**
> * drm_puts - print a const string to a &drm_printer stream
> * @p: the &drm printer
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index a5d6f2f3e430..112165d3195d 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -83,6 +83,7 @@ void __drm_printfn_seq_file(struct drm_printer *p, struct
> va_format *vaf);
> void __drm_puts_seq_file(struct drm_printer *p, const char *str);
> void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
> void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf);
> +void __drm_printfn_err(struct drm_printer *p, struct va_format *vaf);
>
> __printf(2, 3)
> void drm_printf(struct drm_printer *p, const char *f, ...);
> @@ -227,6 +228,22 @@ static inline struct drm_printer drm_debug_printer(const
> char *prefix)
> return p;
> }
>
> +/**
> + * drm_err_printer - construct a &drm_printer that outputs to pr_err()
> + * @prefix: debug output prefix
> + *
> + * RETURNS:
> + * The &drm_printer object
> + */
> +static inline struct drm_printer drm_err_printer(const char *prefix)
> +{
> + struct drm_printer p = {
> + .printfn = __drm_printfn_err,
> + .prefix = prefix
> + };
> + return p;
> +}
> +
> /*
> * The following categories are defined:
> *
> --
> 2.21.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #94 from Tom B --- Reverting d1a3e239a6016f2bb42a91696056e223982e8538 didn't fix it for me. But that commit may give some insight because it is related to uclk which is the first error we get. I also tried globally increasing usec_timeout as it's used in a few places (patch below). This makes the PC take about a minute to boot up, so clearly the GPU is in an invalid state before these timeouts are hit and then each subsequent call to smum_send_msg_to_smc_with_parameter causes a delay because each call times out. Whatever happens, puts the card into a state that it can't recover from. The next step is to try to find where vega20_set_uclk_to_highest_dpm_level is called from and see what happens just before the call to this function. diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index f4ac632a87b2..9b878c74b17e 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -2418,7 +2418,7 @@ int amdgpu_device_init(struct amdgpu_device *adev, adev->pdev = pdev; adev->flags = flags; adev->asic_type = flags & AMD_ASIC_MASK; - adev->usec_timeout = AMDGPU_MAX_USEC_TIMEOUT; + adev->usec_timeout = AMDGPU_MAX_USEC_TIMEOUT*10; if (amdgpu_emu_mode == 1) adev->usec_timeout *= 2; adev->gmc.gart_size = 512 * 1024 * 1024; diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c index a7e8340baf90..a6b2bc4277ef 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c @@ -84,7 +84,7 @@ int hwmgr_early_init(struct pp_hwmgr *hwmgr) if (!hwmgr) return -EINVAL; - hwmgr->usec_timeout = AMD_MAX_USEC_TIMEOUT; + hwmgr->usec_timeout = AMD_MAX_USEC_TIMEOUT*10; hwmgr->pp_table_version = PP_TABLE_V1; hwmgr->dpm_level = AMD_DPM_FORCED_LEVEL_AUTO; hwmgr->request_dpm_level = AMD_DPM_FORCED_LEVEL_AUTO; -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panfrost: Remove completed features still in TODO
On 02/08/2019 21:57, Rob Herring wrote: > There's a few features the driver supports which we forgot to remove, so > remove them now. > > Cc: Tomeu Vizoso > Cc: Boris Brezillon > Signed-off-by: Rob Herring > --- > drivers/gpu/drm/panfrost/TODO | 9 - > 1 file changed, 9 deletions(-) > > diff --git a/drivers/gpu/drm/panfrost/TODO b/drivers/gpu/drm/panfrost/TODO > index c2e44add37d8..2ac972a3469c 100644 > --- a/drivers/gpu/drm/panfrost/TODO > +++ b/drivers/gpu/drm/panfrost/TODO > @@ -1,15 +1,9 @@ > -- Thermal support. > - > - Bifrost support: >- DT bindings (Neil, WIP) The bifrostr bindings are upstream, but not in YAML, you should move and transform this line into : - DT bindings in YAML schema Neil >- MMU page table format and address space setup >- Bifrost specific feature and issue handling >- Coherent DMA support > > -- Support for 2MB pages. The io-pgtable code already supports this. Finishing > - support involves either copying or adapting the iommu API to handle passing > - aligned addresses and sizes to the io-pgtable code. > - > - Per FD address space support. The h/w supports multiple addresses spaces. >The hard part is handling when more address spaces are needed than what >the h/w provides. > @@ -22,6 +16,3 @@ > > - Compute job support. So called 'compute only' jobs need to be plumbed up to >userspace. > - > -- Performance counter support. (Boris) > - > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/9] dt-bindings: display: panel: Add bindings for NEC NL8048HL11 panel
Hi Rob,
On Mon, Aug 12, 2019 at 01:18:39PM -0600, Rob Herring wrote:
> On Sat, Aug 10, 2019 at 5:10 PM Laurent Pinchart wrote:
> >
> > The NEC NL8048HL11 is a 10.4cm WVGA (800x480) panel with a 24-bit RGB
> > parallel data interface and an SPI control interface.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > Changes since v1:
> >
> > - Convert to YAML
> > ---
> > .../display/panel/nec,nl8048hl11.yaml | 49 +++
> > 1 file changed, 49 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
> > b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
> > new file mode 100644
> > index ..cc3d40975828
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
> > @@ -0,0 +1,49 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/nec,nl8048hl11.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NEC NL8048HL11 4.1" WVGA TFT LCD panel
> > +
> > +description:
> > + The NEC NL8048HL11 is a 4.1" WVGA TFT LCD panel with a 24-bit RGB
> > parallel
> > + data interface and an SPI control interface.
> > +
> > +maintainers:
> > + - Laurent Pinchart
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +const: nec,nl8048hl11
> > +
> > + label: true
> > + reset-gpios: true
> > + port: true
> > +
> > +required:
> > + - compatible
> > + - reset-gpios
> > + - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
>
> Your example will fail on 'make dt_binding_check'...
I wasn't aware of this. I've now read writing-schema.md and will make
sure to submit bindings that pass the checks. I'll address the issues
your pointed out below for the next version.
> > + - |
> > +lcd_panel: panel {
>
> SPI devices have to have a minimal SPI controller parent. Primarily
> just #size-cells and #address-cells are needed.
>
> 'reg' is missing here too.
>
> > + compatible = "nec,nl8048hl11";
> > + spi-max-frequency = <1000>;
>
> This needs to be listed in properties ideally with some constraints.
>
> > +
> > + reset-gpios = <&gpio7 7 GPIO_ACTIVE_LOW>;
>
> And GPIO_ACTIVE_LOW. You have to add includes you need.
>
> > +
> > + port {
> > +lcd_in: endpoint {
> > + remote-endpoint = <&dpi_out>;
> > +};
> > + };
> > +};
> > +
> > +...
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/9] drm/panel: Add driver for the NEC NL8048HL11 panel
Hi Sam,
On Sun, Aug 11, 2019 at 07:10:05PM +0200, Sam Ravnborg wrote:
> On Sun, Aug 11, 2019 at 02:10:44AM +0300, Laurent Pinchart wrote:
> > This panel is used on the Zoom2/3/3630 SDP boards.
> >
> > The code is based on the omapdrm-specific panel-nec-nl8048hl11 driver
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > Changes since v1:
> >
> > - Mention boards using the panel in Kconfig
> > - Renamed nl8048_device to nl8048_panel
> > - Comments updates
> > - Store width_mm and height_mm in drm_display_mode
> > - Use drm_panel_disable() in .remove() handler
> > ---
> > drivers/gpu/drm/panel/Kconfig| 8 +
> > drivers/gpu/drm/panel/Makefile | 1 +
> > drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 247 +++
> > 3 files changed, 256 insertions(+)
> > create mode 100644 drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
> >
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index 87cdc330672b..d28133c6aa0a 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -119,6 +119,14 @@ config DRM_PANEL_LG_LG4573
> > Say Y here if you want to enable support for LG4573 RGB panel.
> > To compile this driver as a module, choose M here.
> >
> > +config DRM_PANEL_NEC_NL8048HL11
> > + tristate "NEC NL8048HL11 RGB panel"
> > + depends on GPIOLIB && OF && SPI
> > + help
> > + Say Y here if you want to enable support for the NEC NL8048HL11 RGB
> > + panel (found on the Zoom2/3/3630 SDP boards). To compile this driver
> > + as a module, choose M here.
> > +
> > config DRM_PANEL_NOVATEK_NT39016
> > tristate "Novatek NT39016 RGB/SPI panel"
> > depends on OF && SPI
> > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > index 9bc6f3c5bf96..8052f9a7ad60 100644
> > --- a/drivers/gpu/drm/panel/Makefile
> > +++ b/drivers/gpu/drm/panel/Makefile
> > @@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) +=
> > panel-jdi-lt070me05000.o
> > obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) +=
> > panel-kingdisplay-kd097d04.o
> > obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
> > obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> > +obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
> > obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
> > obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) +=
> > panel-olimex-lcd-olinuxino.o
> > obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
> > diff --git a/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
> > b/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
> > new file mode 100644
> > index ..7c1b77a0b024
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
> > @@ -0,0 +1,247 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * NEC NL8048HL11 Panel Driver
> > + *
> > + * Copyright (C) 2019 Texas Instruments Incorporated
> > + *
> > + * Based on the omapdrm-specific panel-nec-nl8048hl11 driver
> > + *
> > + * Copyright (C) 2010 Texas Instruments Incorporated
> > + * Author: Erik Gilling
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +struct nl8048_panel {
> > + struct drm_panel panel;
> > +
> > + struct spi_device *spi;
> > + struct gpio_desc *reset_gpio;
> > +};
> > +
> > +#define to_nl8048_device(p) container_of(p, struct nl8048_panel, panel)
> > +
> > +static int nl8048_write(struct nl8048_panel *lcd, unsigned char addr,
> > + unsigned char value)
> > +{
> > + u8 data[4] = { value, 0x01, addr, 0x00 };
> > + int ret;
> > +
> > + ret = spi_write(lcd->spi, data, sizeof(data));
> > + if (ret)
> > + dev_err(&lcd->spi->dev, "SPI write to %u failed: %d\n",
> > + addr, ret);
> > +
> > + return ret;
> > +}
> > +
> > +static int nl8048_init(struct nl8048_panel *lcd)
> > +{
> > + static const struct {
> > + unsigned char addr;
> > + unsigned char data;
> > + } nl8048_init_seq[] = {
> > + { 3, 0x01 }, { 0, 0x00 }, { 1, 0x01 }, { 4, 0x00 },
> > + { 5, 0x14 }, { 6, 0x24 }, { 16, 0xd7 }, { 17, 0x00 },
> > + { 18, 0x00 }, { 19, 0x55 }, { 20, 0x01 }, { 21, 0x70 },
> > + { 22, 0x1e }, { 23, 0x25 }, { 24, 0x25 }, { 25, 0x02 },
> > + { 26, 0x02 }, { 27, 0xa0 }, { 32, 0x2f }, { 33, 0x0f },
> > + { 34, 0x0f }, { 35, 0x0f }, { 36, 0x0f }, { 37, 0x0f },
> > + { 38, 0x0f }, { 39, 0x00 }, { 40, 0x02 }, { 41, 0x02 },
> > + { 42, 0x02 }, { 43, 0x0f }, { 44, 0x0f }, { 45, 0x0f },
> > + { 46, 0x0f }, { 47, 0x0f }, { 48, 0x0f }, { 49, 0x0f },
> > + { 50, 0x00 }, { 51, 0x02 }, { 52, 0x02 }, { 53, 0x02 },
> > + { 80, 0x0c }, { 83, 0x42 }, { 84, 0x42 }, { 85, 0x41 },
> > + { 86, 0x
Re: [PATCH resend] video: backlight: Drop default m for {LCD,BACKLIGHT_CLASS_DEVICE}
On Tue, Aug 13, 2019 at 01:58:53PM +0200, Geert Uytterhoeven wrote:
> When running "make oldconfig" on a .config where
> CONFIG_BACKLIGHT_LCD_SUPPORT is not set, two new config options
> ("Lowlevel LCD controls" and "Lowlevel Backlight controls") appear, both
> defaulting to "m".
>
> Drop the "default m", as options should default to disabled, and because
> several driver config options already select LCD_CLASS_DEVICE or
> BACKLIGHT_CLASS_DEVICE when needed.
>
> Fixes: 8c5dc8d9f19c7992 ("video: backlight: Remove useless
> BACKLIGHT_LCD_SUPPORT kernel symbol")
> Signed-off-by: Geert Uytterhoeven
Acked-by: Daniel Thompson
> ---
> drivers/video/backlight/Kconfig | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 8b081d61773e21eb..40676be2e46aae61 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -10,7 +10,6 @@ menu "Backlight & LCD device support"
> #
> config LCD_CLASS_DEVICE
> tristate "Lowlevel LCD controls"
> - default m
> help
> This framework adds support for low-level control of LCD.
> Some framebuffer devices connect to platform-specific LCD modules
> @@ -143,7 +142,6 @@ endif # LCD_CLASS_DEVICE
> #
> config BACKLIGHT_CLASS_DEVICE
> tristate "Lowlevel Backlight controls"
> - default m
> help
> This framework adds support for low-level control of the LCD
>backlight. This includes support for brightness and power.
> --
> 2.17.1
>
Re: [PATCH 09/16] fbdev: remove w90x900/nuc900 platform drivers
On 8/9/19 10:27 PM, Arnd Bergmann wrote:
> The ARM w90x900 platform is getting removed, so this driver is obsolete.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Bartlomiej Zolnierkiewicz
BTW there is a very minor issue with internal bisectability of
this patch series (non-issue in reality because it affects only
configs with ARCH_W90X900=y and such are now gone, just FYI):
arch/arm/mach-w90x900/dev.c (which stays in tree until patch #16
("ARM: remove w90x900 platform") uses include/linux/platform_data/
files removed in patches #7 (spi), #9 (fbdev) and #10 (keyboard).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> drivers/video/fbdev/Kconfig | 14 -
> drivers/video/fbdev/Makefile | 1 -
> drivers/video/fbdev/nuc900fb.c | 760 ---
> drivers/video/fbdev/nuc900fb.h | 51 --
> include/Kbuild | 1 -
> include/linux/platform_data/video-nuc900fb.h | 79 --
> 6 files changed, 906 deletions(-)
> delete mode 100644 drivers/video/fbdev/nuc900fb.c
> delete mode 100644 drivers/video/fbdev/nuc900fb.h
> delete mode 100644 include/linux/platform_data/video-nuc900fb.h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/9] DRM panel drivers for omapdrm
Hello everybody, This patch series adds DT bindings and drivers for 6 panels used by omapdrm. They are meant to replace the corresponding omapdrm-specific drivers from drivers/gpu/drm/omapdrm/displays/ that will be removed in a subsequent patch series, once the omapdrm driver switches fully to the drm_panel API. There's nothing very special here. The first three patches add DT vendor prefixes and DT bindings. The last six patches add new panel drivers. Please see individual patches for changelogs. Sam, I believe I've taken all your and Rob's comments into account. The DT example now compiles (make dt_binding_check rules !). The patches are based on top of drm-misc-next and can be found at git://linuxtv.org/pinchartl/media.git omapdrm/panels Laurent Pinchart (9): dt-bindings: Add vendor prefix for LG Display dt-bindings: Add legacy 'toppoly' vendor prefix dt-bindings: display: panel: Add bindings for NEC NL8048HL11 panel drm/panel: Add driver for the LG Philips LB035Q02 panel drm/panel: Add driver for the NEC NL8048HL11 panel drm/panel: Add driver for the Sharp LS037V7DW01 panel drm/panel: Add driver for the Sony ACX565AKM panel drm/panel: Add driver for the Toppoly TD028TTEC1 panel drm/panel: Add driver for the Toppoly TD043MTEA1 panel .../display/panel/nec,nl8048hl11.yaml | 62 ++ .../devicetree/bindings/vendor-prefixes.yaml | 5 + drivers/gpu/drm/panel/Kconfig | 46 ++ drivers/gpu/drm/panel/Makefile| 6 + drivers/gpu/drm/panel/panel-lg-lb035q02.c | 237 ++ drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 248 +++ .../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 226 ++ drivers/gpu/drm/panel/panel-sony-acx565akm.c | 694 ++ drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 382 ++ drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 509 + 10 files changed, 2415 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml create mode 100644 drivers/gpu/drm/panel/panel-lg-lb035q02.c create mode 100644 drivers/gpu/drm/panel/panel-nec-nl8048hl11.c create mode 100644 drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c create mode 100644 drivers/gpu/drm/panel/panel-sony-acx565akm.c create mode 100644 drivers/gpu/drm/panel/panel-tpo-td028ttec1.c create mode 100644 drivers/gpu/drm/panel/panel-tpo-td043mtea1.c -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/9] dt-bindings: Add vendor prefix for LG Display
LG Display is an LCD display manufacturer. Originally formed as a joint venture by LG Electronics and Philips Electronics, it was formerly known as LG.Philips LCD, hence the DT vendor prefix lgphilips (which is already in active use in the kernel). More information is available at https://en.wikipedia.org/wiki/LG_Display. Signed-off-by: Laurent Pinchart Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 6992ffab..5efddbff2430 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -511,6 +511,8 @@ patternProperties: description: Lenovo Group Ltd. "^lg,.*": description: LG Corporation + "^lgphilips,.*": +description: LG Display "^libretech,.*": description: Shenzhen Libre Technology Co., Ltd "^licheepi,.*": -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/9] drm/panel: Add driver for the LG Philips LB035Q02 panel
This panel is used on the Gumstix Overo Palo35.
The code is based on the omapdrm-specific panel-lgphilips-lb035q02
driver.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sam Ravnborg
---
Changes since v1:
- Comments updates
- Store width_mm and height_mm in drm_display_mode
- Use drm_panel_disable() in .remove() handler
---
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-lg-lb035q02.c | 237 ++
3 files changed, 246 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-lg-lb035q02.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index eaecd40cc32e..87cdc330672b 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -103,6 +103,14 @@ config DRM_PANEL_SAMSUNG_LD9040
depends on OF && SPI
select VIDEOMODE_HELPERS
+config DRM_PANEL_LG_LB035Q02
+ tristate "LG LB035Q024573 RGB panel"
+ depends on GPIOLIB && OF && SPI
+ help
+ Say Y here if you want to enable support for the LB035Q02 RGB panel
+ (found on the Gumstix Overo Palo35 board). To compile this driver as
+ a module, choose M here.
+
config DRM_PANEL_LG_LG4573
tristate "LG4573 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 62dae45f8f74..9bc6f3c5bf96 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) +=
panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
+obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
diff --git a/drivers/gpu/drm/panel/panel-lg-lb035q02.c
b/drivers/gpu/drm/panel/panel-lg-lb035q02.c
new file mode 100644
index ..694489fb91b2
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-lg-lb035q02.c
@@ -0,0 +1,237 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * LG.Philips LB035Q02 LCD Panel Driver
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated
+ *
+ * Based on the omapdrm-specific panel-lgphilips-lb035q02 driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated
+ * Author: Tomi Valkeinen
+ *
+ * Based on a driver by: Steve Sakoman
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+struct lb035q02_device {
+ struct drm_panel panel;
+
+ struct spi_device *spi;
+ struct gpio_desc *enable_gpio;
+};
+
+#define to_lb035q02_device(p) container_of(p, struct lb035q02_device, panel)
+
+static int lb035q02_write(struct lb035q02_device *lcd, u16 reg, u16 val)
+{
+ struct spi_message msg;
+ struct spi_transfer index_xfer = {
+ .len= 3,
+ .cs_change = 1,
+ };
+ struct spi_transfer value_xfer = {
+ .len= 3,
+ };
+ u8 buffer[16];
+
+ spi_message_init(&msg);
+
+ /* register index */
+ buffer[0] = 0x70;
+ buffer[1] = 0x00;
+ buffer[2] = reg & 0x7f;
+ index_xfer.tx_buf = buffer;
+ spi_message_add_tail(&index_xfer, &msg);
+
+ /* register value */
+ buffer[4] = 0x72;
+ buffer[5] = val >> 8;
+ buffer[6] = val;
+ value_xfer.tx_buf = buffer + 4;
+ spi_message_add_tail(&value_xfer, &msg);
+
+ return spi_sync(lcd->spi, &msg);
+}
+
+static int lb035q02_init(struct lb035q02_device *lcd)
+{
+ /* Init sequence from page 28 of the lb035q02 spec. */
+ static const struct {
+ u16 index;
+ u16 value;
+ } init_data[] = {
+ { 0x01, 0x6300 },
+ { 0x02, 0x0200 },
+ { 0x03, 0x0177 },
+ { 0x04, 0x04c7 },
+ { 0x05, 0xffc0 },
+ { 0x06, 0xe806 },
+ { 0x0a, 0x4008 },
+ { 0x0b, 0x },
+ { 0x0d, 0x0030 },
+ { 0x0e, 0x2800 },
+ { 0x0f, 0x },
+ { 0x16, 0x9f80 },
+ { 0x17, 0x0a0f },
+ { 0x1e, 0x00c1 },
+ { 0x30, 0x0300 },
+ { 0x31, 0x0007 },
+ { 0x32, 0x },
+ { 0x33, 0x },
+ { 0x34, 0x0707 },
+ { 0x35, 0x0004 },
+ { 0x36, 0x0302 },
+ { 0x37, 0x0202 },
+ { 0x3a, 0x0a0d },
+ { 0x3b, 0x0806 },
+ };
+
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(init_data); ++i) {
+ ret = lb035q02_write(lcd, init_data[i].i
[PATCH v3 7/9] drm/panel: Add driver for the Sony ACX565AKM panel
This panel is used on the Nokia N900.
The code is based on the omapdrm-specific panel-sony-acx565akm driver.
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Call drm_panel_unprepare() in .remove() handler
Changes since v1:
- Mention boards using the panel in Kconfig
- Renamed acx565akm_device to acx565akm_panel
- Comments updates
- Store width_mm and height_mm in drm_display_mode
- Use drm_panel_disable() in .remove() handler
---
drivers/gpu/drm/panel/Kconfig| 8 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-sony-acx565akm.c | 694 +++
3 files changed, 703 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-sony-acx565akm.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 8d9a8cdb704e..b05649b3118a 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -316,6 +316,14 @@ 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_SONY_ACX565AKM
+ tristate "Sony ACX565AKM panel"
+ depends on GPIOLIB && OF && SPI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Sony ACX565AKM
+ 800x600 3.5" panel (found on the Nokia N900).
+
config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 14d1c49ef3ab..28cf2332fd06 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -33,5 +33,6 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) +=
panel-sharp-ls037v7dw01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
new file mode 100644
index ..c8c82163e24d
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
@@ -0,0 +1,694 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Sony ACX565AKM LCD Panel driver
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated
+ *
+ * Based on the omapdrm-specific panel-sony-acx565akm driver
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ * Author: Imre Deak
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define CTRL_DISP_BRIGHTNESS_CTRL_ON (1 << 5)
+#define CTRL_DISP_AMBIENT_LIGHT_CTRL_ON(1 << 4)
+#define CTRL_DISP_BACKLIGHT_ON (1 << 2)
+#define CTRL_DISP_AUTO_BRIGHTNESS_ON (1 << 1)
+
+#define MIPID_CMD_WRITE_CABC 0x55
+#define MIPID_CMD_READ_CABC0x56
+
+#define MIPID_VER_LPH8923 3
+#define MIPID_VER_LS041Y3 4
+#define MIPID_VER_L4F00311 8
+#define MIPID_VER_ACX565AKM9
+
+struct acx565akm_panel {
+ struct drm_panel panel;
+
+ struct spi_device *spi;
+ struct gpio_desc *reset_gpio;
+ struct backlight_device *backlight;
+
+ struct mutex mutex;
+
+ const char *name;
+ u8 display_id[3];
+ int model;
+ int revision;
+ bool has_bc;
+ bool has_cabc;
+
+ bool enabled;
+ unsigned int cabc_mode;
+ /*
+* Next value of jiffies when we can issue the next sleep in/out
+* command.
+*/
+ unsigned long hw_guard_end;
+ unsigned long hw_guard_wait;/* max guard time in jiffies */
+};
+
+#define to_acx565akm_device(p) container_of(p, struct acx565akm_panel, panel)
+
+static void acx565akm_transfer(struct acx565akm_panel *lcd, int cmd,
+ const u8 *wbuf, int wlen, u8 *rbuf, int rlen)
+{
+ struct spi_message m;
+ struct spi_transfer *x, xfer[5];
+ int ret;
+
+ spi_message_init(&m);
+
+ memset(xfer, 0, sizeof(xfer));
+ x = &xfer[0];
+
+ cmd &= 0xff;
+ x->tx_buf = &cmd;
+ x->bits_per_word = 9;
+ x->len = 2;
+
+ if (rlen > 1 && wlen == 0) {
+ /*
+* Between the command and the response data there is a
+* dummy clock cycle. Add an extra bit after the command
+* word to account for this.
+*/
+ x->bits_per_word = 10;
+ cmd <<= 1;
+ }
+ spi_message_add_tail(x, &m);
+
+ if (wlen) {
+ x++;
+ x->tx_buf = wbuf;
+ x-
[PATCH v3 9/9] drm/panel: Add driver for the Toppoly TD043MTEA1 panel
This panel is used on the OMAP3 Pandora.
The code is based on the omapdrm-specific panel-tpo-td043mtea1 driver.
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Call drm_panel_disable() in .remove() handler
Changes since v1:
- Mention boards using the panel in Kconfig
- Renamed td043mtea1_device to td043mtea1_panel
- Fixed typo in Toppoly name
- Comments updates
- Store width_mm and height_mm in drm_display_mode
- Use drm_panel_unprepare() in .remove() handler
- Replace enable/disable with prepare/unprepare
---
drivers/gpu/drm/panel/Kconfig| 7 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 509 +++
3 files changed, 517 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index c2689420d2dd..f152bc4eeb53 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -332,6 +332,13 @@ config DRM_PANEL_TPO_TD028TTEC1
Say Y here if you want to enable support for TPO TD028TTEC1 480x640
2.8" panel (found on the OpenMoko Neo FreeRunner and Neo 1973).
+config DRM_PANEL_TPO_TD043MTEA1
+ tristate "Toppoly (TPO) TD043MTEA1 panel driver"
+ depends on GPIOLIB && OF && REGULATOR && SPI
+ help
+ Say Y here if you want to enable support for TPO TD043MTEA1 800x480
+ 4.3" panel (found on the OMAP3 Pandora board).
+
config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 27b776737ad3..b6cd39fe0f20 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -35,5 +35,6 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) +=
panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
+obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
diff --git a/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
b/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
new file mode 100644
index ..71824a334af7
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
@@ -0,0 +1,509 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Toppoly TD043MTEA1 Panel Driver
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated
+ *
+ * Based on the omapdrm-specific panel-tpo-td043mtea1 driver
+ *
+ * Author: Gražvydas Ignotas
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define TPO_R02_MODE(x)((x) & 7)
+#define TPO_R02_MODE_800x480 7
+#define TPO_R02_NCLK_RISINGBIT(3)
+#define TPO_R02_HSYNC_HIGH BIT(4)
+#define TPO_R02_VSYNC_HIGH BIT(5)
+
+#define TPO_R03_NSTANDBY BIT(0)
+#define TPO_R03_EN_CP_CLK BIT(1)
+#define TPO_R03_EN_VGL_PUMPBIT(2)
+#define TPO_R03_EN_PWM BIT(3)
+#define TPO_R03_DRIVING_CAP_100BIT(4)
+#define TPO_R03_EN_PRE_CHARGE BIT(6)
+#define TPO_R03_SOFTWARE_CTL BIT(7)
+
+#define TPO_R04_NFLIP_HBIT(0)
+#define TPO_R04_NFLIP_VBIT(1)
+#define TPO_R04_CP_CLK_FREQ_1H BIT(2)
+#define TPO_R04_VGL_FREQ_1HBIT(4)
+
+#define TPO_R03_VAL_NORMAL \
+ (TPO_R03_NSTANDBY | TPO_R03_EN_CP_CLK | TPO_R03_EN_VGL_PUMP | \
+TPO_R03_EN_PWM | TPO_R03_DRIVING_CAP_100 | TPO_R03_EN_PRE_CHARGE | \
+TPO_R03_SOFTWARE_CTL)
+
+#define TPO_R03_VAL_STANDBY \
+ (TPO_R03_DRIVING_CAP_100 | TPO_R03_EN_PRE_CHARGE | \
+TPO_R03_SOFTWARE_CTL)
+
+static const u16 td043mtea1_def_gamma[12] = {
+ 105, 315, 381, 431, 490, 537, 579, 686, 780, 837, 880, 1023
+};
+
+struct td043mtea1_panel {
+ struct drm_panel panel;
+
+ struct spi_device *spi;
+ struct regulator *vcc_reg;
+ struct gpio_desc *reset_gpio;
+
+ unsigned int mode;
+ u16 gamma[12];
+ bool vmirror;
+ bool powered_on;
+ bool spi_suspended;
+ bool power_on_resume;
+};
+
+#define to_td043mtea1_device(p) container_of(p, struct td043mtea1_panel, panel)
+
+/*
-
+ * Hardware Access
+ */
+
+static int td043mtea1_write(struct td043mtea1_panel *lcd, u8 addr, u8 value)
+{
+ struct spi_message msg;
+ struct spi_transfer xfer;
+ u16 data;
+ int ret;
+
+ spi_message_init(&msg);
+
+ memset(&xfer, 0, sizeof(xfer));
+
+ data = ((u16)addr << 10) | (1 << 8) | value;
+ xfer.tx_buf = &data;
+ xfer.bits_per_word = 16;
+
[PATCH v3 2/9] dt-bindings: Add legacy 'toppoly' vendor prefix
The 'toppoly' vendor prefix is in use and refers to TPO, whose DT vendor prefix is already defined as 'tpo'. Add 'toppoly' as an alternative and document it as legacy. Signed-off-by: Laurent Pinchart Reviewed-by: Rob Herring --- Changes since v1: - Mark the prefix as deprecated --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 5efddbff2430..29dcc6f8a64a 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -935,6 +935,9 @@ patternProperties: description: Tecon Microprocessor Technologies, LLC. "^topeet,.*": description: Topeet + "^toppoly,.*": +description: TPO (deprecated, use tpo) +deprecated: true "^toradex,.*": description: Toradex AG "^toshiba,.*": -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 8/9] drm/panel: Add driver for the Toppoly TD028TTEC1 panel
This panel is used on the OpenMoko Neo FreeRunner and Neo 1973. The code is based on the omapdrm-specific panel-tpo-td028ttec1 driver. Signed-off-by: Laurent Pinchart --- Changes since v2: - Call drm_panel_unprepare() in .remove() handler Changes since v1: - Mention boards using the panel in Kconfig - Renamed td028ttec1_device to td028ttec1_panel - Comments updates - Removed unneeded ret check - Store width_mm and height_mm in drm_display_mode - Use drm_panel_disable() in .remove() handler --- drivers/gpu/drm/panel/Kconfig| 8 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 382 +++ 3 files changed, 391 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-tpo-td028ttec1.c diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index b05649b3118a..c2689420d2dd 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -324,6 +324,14 @@ config DRM_PANEL_SONY_ACX565AKM Say Y here if you want to enable support for the Sony ACX565AKM 800x600 3.5" panel (found on the Nokia N900). +config DRM_PANEL_TPO_TD028TTEC1 + tristate "Toppoly (TPO) TD028TTEC1 panel driver" + depends on OF && SPI + depends on BACKLIGHT_CLASS_DEVICE + help + Say Y here if you want to enable support for TPO TD028TTEC1 480x640 + 2.8" panel (found on the OpenMoko Neo FreeRunner and Neo 1973). + config DRM_PANEL_TPO_TPG110 tristate "TPO TPG 800x400 panel" depends on OF && SPI && GPIOLIB diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index 28cf2332fd06..27b776737ad3 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -34,5 +34,6 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o +obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o diff --git a/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c b/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c new file mode 100644 index ..dd69fac9808f --- /dev/null +++ b/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c @@ -0,0 +1,382 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Toppoly TD028TTEC1 Panel Driver + * + * Copyright (C) 2019 Texas Instruments Incorporated + * + * Based on the omapdrm-specific panel-tpo-td028ttec1 driver + * + * Copyright (C) 2008 Nokia Corporation + * Author: Tomi Valkeinen + * + * Neo 1973 code (jbt6k74.c): + * Copyright (C) 2006-2007 OpenMoko, Inc. + * Author: Harald Welte + * + * Ported and adapted from Neo 1973 U-Boot by: + * H. Nikolaus Schaller + */ + +#include +#include +#include +#include + +#include +#include +#include + +#define JBT_COMMAND0x000 +#define JBT_DATA 0x100 + +#define JBT_REG_SLEEP_IN 0x10 +#define JBT_REG_SLEEP_OUT 0x11 + +#define JBT_REG_DISPLAY_OFF0x28 +#define JBT_REG_DISPLAY_ON 0x29 + +#define JBT_REG_RGB_FORMAT 0x3a +#define JBT_REG_QUAD_RATE 0x3b + +#define JBT_REG_POWER_ON_OFF 0xb0 +#define JBT_REG_BOOSTER_OP 0xb1 +#define JBT_REG_BOOSTER_MODE 0xb2 +#define JBT_REG_BOOSTER_FREQ 0xb3 +#define JBT_REG_OPAMP_SYSCLK 0xb4 +#define JBT_REG_VSC_VOLTAGE0xb5 +#define JBT_REG_VCOM_VOLTAGE 0xb6 +#define JBT_REG_EXT_DISPL 0xb7 +#define JBT_REG_OUTPUT_CONTROL 0xb8 +#define JBT_REG_DCCLK_DCEV 0xb9 +#define JBT_REG_DISPLAY_MODE1 0xba +#define JBT_REG_DISPLAY_MODE2 0xbb +#define JBT_REG_DISPLAY_MODE 0xbc +#define JBT_REG_ASW_SLEW 0xbd +#define JBT_REG_DUMMY_DISPLAY 0xbe +#define JBT_REG_DRIVE_SYSTEM 0xbf + +#define JBT_REG_SLEEP_OUT_FR_A 0xc0 +#define JBT_REG_SLEEP_OUT_FR_B 0xc1 +#define JBT_REG_SLEEP_OUT_FR_C 0xc2 +#define JBT_REG_SLEEP_IN_LCCNT_D 0xc3 +#define JBT_REG_SLEEP_IN_LCCNT_E 0xc4 +#define JBT_REG_SLEEP_IN_LCCNT_F 0xc5 +#define JBT_REG_SLEEP_IN_LCCNT_G 0xc6 + +#define JBT_REG_GAMMA1_FINE_1 0xc7 +#define JBT_REG_GAMMA1_FINE_2 0xc8 +#define JBT_REG_GAMMA1_INCLINATION 0xc9 +#define JBT_REG_GAMMA1_BLUE_OFFSET 0xca + +#define JBT_REG_BLANK_CONTROL 0xcf +#define JBT_REG_BLANK_TH_TV0xd0 +#define JBT_REG_CKV_ON_OFF 0xd1 +#define JBT_REG_CKV_1_20xd2 +#define JBT_REG_OEV_TIMING 0xd3 +#define JBT_REG_ASW_TIMING_1 0xd4 +#define JBT_REG_ASW_TIMING_2 0xd5 + +#define JBT_REG_HCL
[PATCH v3 3/9] dt-bindings: display: panel: Add bindings for NEC NL8048HL11 panel
The NEC NL8048HL11 is a 10.4cm WVGA (800x480) panel with a 24-bit RGB
parallel data interface and an SPI control interface.
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Add reg and spi-max-frequency properties
- Make the example pass the checks
Changes since v1:
- Convert to YAML
---
.../display/panel/nec,nl8048hl11.yaml | 62 +++
1 file changed, 62 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
new file mode 100644
index ..aa788eaa2f71
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/nec,nl8048hl11.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NEC NL8048HL11 4.1" WVGA TFT LCD panel
+
+description:
+ The NEC NL8048HL11 is a 4.1" WVGA TFT LCD panel with a 24-bit RGB parallel
+ data interface and an SPI control interface.
+
+maintainers:
+ - Laurent Pinchart
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: nec,nl8048hl11
+
+ label: true
+ port: true
+ reg: true
+ reset-gpios: true
+
+ spi-max-frequency:
+maximum: 1000
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+spi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lcd_panel: panel@0 {
+compatible = "nec,nl8048hl11";
+reg = <0>;
+spi-max-frequency = <1000>;
+
+reset-gpios = <&gpio7 7 GPIO_ACTIVE_LOW>;
+
+port {
+ lcd_in: endpoint {
+remote-endpoint = <&dpi_out>;
+ };
+};
+ };
+};
+
+...
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/9] drm/panel: Add driver for the Sharp LS037V7DW01 panel
This panel is used on the TI SDP3430 board.
The code is based on the omapdrm-specific panel-sharp-ls037v7dw01
driver.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Mention boards using the panel in Kconfig
- Renamed ls037v7dw01_device to ls037v7dw01_panel
- Renamed vcc to vdd
- Comments updates
- Store width_mm and height_mm in drm_display_mode
- Use drm_panel_disable() in .remove() handler
- Use devm_gpiod_get() where applicable
- Remove NULL-check on vdd
- Order Kconfig entries alphabetically
---
drivers/gpu/drm/panel/Kconfig | 7 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 226 ++
3 files changed, 234 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d28133c6aa0a..8d9a8cdb704e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -282,6 +282,13 @@ config DRM_PANEL_SHARP_LQ101R1SX01
To compile this driver as a module, choose M here: the module
will be called panel-sharp-lq101r1sx01.
+config DRM_PANEL_SHARP_LS037V7DW01
+ tristate "Sharp LS037V7DW01 VGA LCD panel"
+ depends on GPIOLIB && OF && REGULATOR
+ help
+ Say Y here if you want to enable support for Sharp LS037V7DW01 VGA
+ (480x640) LCD panel (found on the TI SDP3430 board).
+
config DRM_PANEL_SHARP_LS043T1LE01
tristate "Sharp LS043T1LE01 qHD video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8052f9a7ad60..14d1c49ef3ab 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63M0) +=
panel-samsung-s6e63m0.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
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_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
new file mode 100644
index ..2aaea507cc1f
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
@@ -0,0 +1,226 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Sharp LS037V7DW01 LCD Panel Driver
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated
+ *
+ * Based on the omapdrm-specific panel-sharp-ls037v7dw01 driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated
+ * Author: Tomi Valkeinen
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+struct ls037v7dw01_panel {
+ struct drm_panel panel;
+ struct platform_device *pdev;
+
+ struct regulator *vdd;
+ struct gpio_desc *resb_gpio;/* low = reset active min 20 us */
+ struct gpio_desc *ini_gpio; /* high = power on */
+ struct gpio_desc *mo_gpio; /* low = 480x640, high = 240x320 */
+ struct gpio_desc *lr_gpio; /* high = conventional horizontal
scanning */
+ struct gpio_desc *ud_gpio; /* high = conventional vertical
scanning */
+};
+
+#define to_ls037v7dw01_device(p) \
+ container_of(p, struct ls037v7dw01_panel, panel)
+
+static int ls037v7dw01_disable(struct drm_panel *panel)
+{
+ struct ls037v7dw01_panel *lcd = to_ls037v7dw01_device(panel);
+
+ gpiod_set_value_cansleep(lcd->ini_gpio, 0);
+ gpiod_set_value_cansleep(lcd->resb_gpio, 0);
+
+ /* Wait at least 5 vsyncs after disabling the LCD. */
+ msleep(100);
+
+ return 0;
+}
+
+static int ls037v7dw01_unprepare(struct drm_panel *panel)
+{
+ struct ls037v7dw01_panel *lcd = to_ls037v7dw01_device(panel);
+
+ regulator_disable(lcd->vdd);
+ return 0;
+}
+
+static int ls037v7dw01_prepare(struct drm_panel *panel)
+{
+ struct ls037v7dw01_panel *lcd = to_ls037v7dw01_device(panel);
+ int ret;
+
+ ret = regulator_enable(lcd->vdd);
+ if (ret < 0)
+ dev_err(&lcd->pdev->dev, "%s: failed to enable regulator\n",
+ __func__);
+
+ return ret;
+}
+
+static int ls037v7dw01_enable(struct drm_panel *panel)
+{
+ struct ls037v7dw01_panel *lcd = to_ls037v7dw01_device(panel);
+
+ /* Wait couple of vsyncs before enabling the LCD. */
+ msleep(50);
+
+ gpiod_set_value_cansleep(lcd->resb_gpio, 1);
+ gpiod_set_value_cansleep(lcd->ini_gpio, 1);
+
+ return 0;
+}
+
+static const struct drm_display_mode ls037v7dw01_mode = {
+ .clock = 19200,
+ .hdisplay = 480,
+ .hsync_start = 480 + 1,
+ .hsy
[PATCH v3 5/9] drm/panel: Add driver for the NEC NL8048HL11 panel
This panel is used on the Zoom2/3/3630 SDP boards.
The code is based on the omapdrm-specific panel-nec-nl8048hl11 driver
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Call drm_panel_unprepare() in .remove() handler
Changes since v1:
- Mention boards using the panel in Kconfig
- Renamed nl8048_device to nl8048_panel
- Comments updates
- Store width_mm and height_mm in drm_display_mode
- Use drm_panel_disable() in .remove() handler
---
drivers/gpu/drm/panel/Kconfig| 8 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 248 +++
3 files changed, 257 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 87cdc330672b..d28133c6aa0a 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -119,6 +119,14 @@ config DRM_PANEL_LG_LG4573
Say Y here if you want to enable support for LG4573 RGB panel.
To compile this driver as a module, choose M here.
+config DRM_PANEL_NEC_NL8048HL11
+ tristate "NEC NL8048HL11 RGB panel"
+ depends on GPIOLIB && OF && SPI
+ help
+ Say Y here if you want to enable support for the NEC NL8048HL11 RGB
+ panel (found on the Zoom2/3/3630 SDP boards). To compile this driver
+ as a module, choose M here.
+
config DRM_PANEL_NOVATEK_NT39016
tristate "Novatek NT39016 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 9bc6f3c5bf96..8052f9a7ad60 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) +=
panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
+obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
diff --git a/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
b/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
new file mode 100644
index ..21bae2d0a23a
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-nec-nl8048hl11.c
@@ -0,0 +1,248 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * NEC NL8048HL11 Panel Driver
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated
+ *
+ * Based on the omapdrm-specific panel-nec-nl8048hl11 driver
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated
+ * Author: Erik Gilling
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+struct nl8048_panel {
+ struct drm_panel panel;
+
+ struct spi_device *spi;
+ struct gpio_desc *reset_gpio;
+};
+
+#define to_nl8048_device(p) container_of(p, struct nl8048_panel, panel)
+
+static int nl8048_write(struct nl8048_panel *lcd, unsigned char addr,
+ unsigned char value)
+{
+ u8 data[4] = { value, 0x01, addr, 0x00 };
+ int ret;
+
+ ret = spi_write(lcd->spi, data, sizeof(data));
+ if (ret)
+ dev_err(&lcd->spi->dev, "SPI write to %u failed: %d\n",
+ addr, ret);
+
+ return ret;
+}
+
+static int nl8048_init(struct nl8048_panel *lcd)
+{
+ static const struct {
+ unsigned char addr;
+ unsigned char data;
+ } nl8048_init_seq[] = {
+ { 3, 0x01 }, { 0, 0x00 }, { 1, 0x01 }, { 4, 0x00 },
+ { 5, 0x14 }, { 6, 0x24 }, { 16, 0xd7 }, { 17, 0x00 },
+ { 18, 0x00 }, { 19, 0x55 }, { 20, 0x01 }, { 21, 0x70 },
+ { 22, 0x1e }, { 23, 0x25 }, { 24, 0x25 }, { 25, 0x02 },
+ { 26, 0x02 }, { 27, 0xa0 }, { 32, 0x2f }, { 33, 0x0f },
+ { 34, 0x0f }, { 35, 0x0f }, { 36, 0x0f }, { 37, 0x0f },
+ { 38, 0x0f }, { 39, 0x00 }, { 40, 0x02 }, { 41, 0x02 },
+ { 42, 0x02 }, { 43, 0x0f }, { 44, 0x0f }, { 45, 0x0f },
+ { 46, 0x0f }, { 47, 0x0f }, { 48, 0x0f }, { 49, 0x0f },
+ { 50, 0x00 }, { 51, 0x02 }, { 52, 0x02 }, { 53, 0x02 },
+ { 80, 0x0c }, { 83, 0x42 }, { 84, 0x42 }, { 85, 0x41 },
+ { 86, 0x14 }, { 89, 0x88 }, { 90, 0x01 }, { 91, 0x00 },
+ { 92, 0x02 }, { 93, 0x0c }, { 94, 0x1c }, { 95, 0x27 },
+ { 98, 0x49 }, { 99, 0x27 }, { 102, 0x76 }, { 103, 0x27 },
+ { 112, 0x01 }, { 113, 0x0e }, { 114, 0x02 }, { 115, 0x0c },
+ { 118, 0x0c }, { 121, 0x30 }, { 130, 0x00 }, { 131, 0x00 },
+ { 132, 0xfc }, { 134, 0x00 }, { 136, 0x00 }, { 1
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #95 from Tom B --- So here's something interesting. In 5.0.13 there is no function vega20_display_config_changed. This function issues smu_send_smc_msg_with_param(smu, SMU_MSG_NumOfDisplays, 0); In fact, in 5.0.13 there is no reference at all to SMU_MSG_NumOfDisplays anywhere in the amdgpu driver. Which means, the way that the number of displays is configured is changed in 5.0.13, or done with a hardcoded value instead of a constant. -- 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
