Re: [PATCH v2] drm/modes: Apply video parameters with only reflect option

[Maxime Ripard]

Hi Stephan,

On Mon, Jan 13, 2020 at 05:30:39PM +0100, Stephan Gerhold wrote:
> On Mon, Dec 16, 2019 at 07:08:12PM +0100, Stephan Gerhold wrote:
> > On Mon, Dec 16, 2019 at 07:27:25PM +0200, Ville Syrjälä wrote:
> > > On Mon, Dec 16, 2019 at 06:10:17PM +0100, Stephan Gerhold wrote:
> > > > At the moment, video mode parameters like video=540x960,reflect_x,
> > > > (without rotation set) are not taken into account when applying the
> > > > mode in drm_client_modeset.c.
> > >
> > > A rotation value without exactly one rotation angle is illegal.
> > > IMO the code should not generate a value like that in the first
> > > place.
> > >
>
> What do you think about Ville's comment?
> Should we change the command line parser to generate ROTATE_0 when no
> rotate option is specified? This would also require updating a few of
> the test cases.

I agree with him :)

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

[Chris Wilson]

Quoting Daniel Vetter (2020-01-16 06:52:42)
> On Wed, Jan 15, 2020 at 08:52:45PM +, Chris Wilson wrote:
> > Since we may try and flush the cachelines associated with large buffers
> > (an 8K framebuffer is about 128MiB, even before we try HDR), this leads
> > to unacceptably long latencies (when using a voluntary CONFIG_PREEMPT).
> > If we call cond_resched() between each sg chunk, that it about every 128
> > pages, we have a natural break point in which to check if the process
> > needs to be rescheduled. Naturally, this means that drm_clflush_sg() can
> > only be called from process context -- which is true at the moment. The
> > other clflush routines remain usable from atomic context.
> > 
> > Even though flushing large objects takes a demonstrable amount to time
> > to flush all the cachelines, clflush is still preferred over a
> > system-wide wbinvd as the latter has unpredictable latencies affecting
> > the whole system not just the local task.
> > 
> > Reported-by: David Laight 
> > Signed-off-by: Chris Wilson 
> > Cc: David Laight 
> 
> The original bug report is complaining about latencies for SCHED_RT
> threads, on a system that doesn't even use CONFIG_PREEMPT. I'm not sure
> it's terribly valid to cater to that use-case - all the desktop distros
> seem a lot more reasonable. So firmly *shrug* from my side ...

Yeah, I had the same immediate response to the complaint), but otoh we've
inserted cond_resched() before when it looks like may consume entire
jiffies inside a loop. At the very minimum, we should have a
might_sleep() here and a reminder that this can be very slow (remember
byt?).
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/4] drm/simple-kms: Let DRM core send VBLANK events by default

[Thomas Zimmermann]

Hi

Am 16.01.20 um 07:41 schrieb Daniel Vetter:
> On Wed, Jan 15, 2020 at 01:52:26PM +0100, Thomas Zimmermann wrote:
>> In drm_atomic_helper_fake_vblank() the DRM core sends out VBLANK events
>> if struct drm_crtc_state.no_vblank is enabled in the check() callbacks.
>>
>> For drivers that have neither an enable_vblank() callback nor a check()
>> callback, the simple-KMS helpers enable VBLANK generation by default. This
>> simplifies bochs, udl, several tiny drivers, and drivers based upon MIPI
>> DPI helpers. The driver for Xen explicitly disables no_vblank, as it has
>> its own logic for sending these events.
>>
>> Signed-off-by: Thomas Zimmermann 
> 
>> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
>> b/drivers/gpu/drm/drm_simple_kms_helper.c
>> index 15fb516ae2d8..4414c7a5b2ce 100644
>> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
>> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
>> @@ -146,10 +146,21 @@ static int drm_simple_kms_plane_atomic_check(struct 
>> drm_plane *plane,
>>  if (!plane_state->visible)
>>  return 0;
>>  
>> -if (!pipe->funcs || !pipe->funcs->check)
>> -return 0;
>> -
>> -return pipe->funcs->check(pipe, plane_state, crtc_state);
>> +if (pipe->funcs) {
>> +if (pipe->funcs->check)
>> +return pipe->funcs->check(pipe, plane_state,
>> +  crtc_state);
>> +if (pipe->funcs->enable_vblank)
>> +return 0;
>> +}
>> +
>> +/* Drivers without VBLANK support have to fake VBLANK events. As
>> + * there's no check() callback to enable this, set the no_vblank
>> + * field by default.
>> + */
> 
> The ->check callback is right above this comment ... I'm confused.

I guess that comment isn't overly precise. What it means is that
no_vblank would have to be set in check(), but the driver did not
specify a check() function. So it has neither vblank support nor any way
of setting no_vblank. Hence, the simple-kms helper sets no_vblank
automatically.

Maybe something to update for the patchset's v2.

> 
>> +crtc_state->no_vblank = true;
> 
> That's kinda not what I meant with handling this automatically. Instead
> something like this:
> 
> 
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 7cf3cf936547..23d2f51fc1d4 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -149,6 +149,11 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
> drm_crtc *crtc,
>   /* Self refresh should be canceled when a new update is available */
>   state->active = drm_atomic_crtc_effectively_active(state);
>   state->self_refresh_active = false;
> +
> + if (drm_dev_has_vblank(crtc->dev))
> + state->no_vblank = true;
> + else
> + state->no_vblank = false;
>  }
>  EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);

I think the if/else branches are in the wrong order.

But generally speaking, is it really that easy? The xen driver already
has to work around simple-kms's auto-enabling of no_vblank (see patch
4). Maybe this settings interferes with other drivers as well. At least
the calls for sending fake vblanks should be removed from all affected
drivers.

Best regards
Thomas

>  
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 1659b13b178c..32cab3d3c872 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -81,6 +81,12 @@
>   */
>  #define DRM_REDUNDANT_VBLIRQ_THRESH_NS 100
>  
> +/* FIXME roll this out here in this file */
> +bool drm_dev_has_vblank(dev)
> +{
> + return dev->num_crtcs;
> +}
> +
>  static bool
>  drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
> ktime_t *tvblank, bool in_vblank_irq);
> 
> 
> But maybe move the default value to some other/better place in the atomic
> helpers, not sure what the best one is.
> 
> Plus then in the documentation patch also highlight the link between
> crtc_state->no_vblank and drm_dev_has_vblank respectively
> drm_device.num_crtcs.
> 
> That should plug this issue once for all across the board.
> 
> There's still the fun between having the vblank callbacks and the
> drm_vblank setup, but that's a much older can of worms ...
> -Daniel
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

[Daniel Vetter]

On Wed, Jan 15, 2020 at 08:52:45PM +, Chris Wilson wrote:
> Since we may try and flush the cachelines associated with large buffers
> (an 8K framebuffer is about 128MiB, even before we try HDR), this leads
> to unacceptably long latencies (when using a voluntary CONFIG_PREEMPT).
> If we call cond_resched() between each sg chunk, that it about every 128
> pages, we have a natural break point in which to check if the process
> needs to be rescheduled. Naturally, this means that drm_clflush_sg() can
> only be called from process context -- which is true at the moment. The
> other clflush routines remain usable from atomic context.
> 
> Even though flushing large objects takes a demonstrable amount to time
> to flush all the cachelines, clflush is still preferred over a
> system-wide wbinvd as the latter has unpredictable latencies affecting
> the whole system not just the local task.
> 
> Reported-by: David Laight 
> Signed-off-by: Chris Wilson 
> Cc: David Laight 

The original bug report is complaining about latencies for SCHED_RT
threads, on a system that doesn't even use CONFIG_PREEMPT. I'm not sure
it's terribly valid to cater to that use-case - all the desktop distros
seem a lot more reasonable. So firmly *shrug* from my side ...

Patch itself looks correct, just not seeing the point.
-Daniel


> ---
>  drivers/gpu/drm/drm_cache.c | 49 ++---
>  1 file changed, 45 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index 03e01b000f7a..fbd2bb644544 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -112,23 +112,64 @@ drm_clflush_pages(struct page *pages[], unsigned long 
> num_pages)
>  }
>  EXPORT_SYMBOL(drm_clflush_pages);
>  
> +static __always_inline struct sgt_iter {
> + struct scatterlist *sgp;
> + unsigned long pfn;
> + unsigned int curr;
> + unsigned int max;
> +} __sgt_iter(struct scatterlist *sgl) {
> + struct sgt_iter s = { .sgp = sgl };
> +
> + if (s.sgp) {
> + s.max = s.curr = s.sgp->offset;
> + s.max += s.sgp->length;
> + s.pfn = page_to_pfn(sg_page(s.sgp));
> + }
> +
> + return s;
> +}
> +
> +static inline struct scatterlist *__sg_next_resched(struct scatterlist *sg)
> +{
> + if (sg_is_last(sg))
> + return NULL;
> +
> + ++sg;
> + if (unlikely(sg_is_chain(sg))) {
> + sg = sg_chain_ptr(sg);
> + cond_resched();
> + }
> + return sg;
> +}
> +
> +#define for_each_sgt_page(__pp, __iter, __sgt)   
> \
> + for ((__iter) = __sgt_iter((__sgt)->sgl);   \
> +  ((__pp) = (__iter).pfn == 0 ? NULL :   \
> +   pfn_to_page((__iter).pfn + ((__iter).curr >> PAGE_SHIFT))); \
> +  (((__iter).curr += PAGE_SIZE) >= (__iter).max) ?   \
> +  (__iter) = __sgt_iter(__sg_next_resched((__iter).sgp)), 0 : 0)
> +
>  /**
>   * drm_clflush_sg - Flush dcache lines pointing to a scather-gather.
>   * @st: struct sg_table.
>   *
>   * Flush every data cache line entry that points to an address in the
> - * sg.
> + * sg. This may schedule between scatterlist chunks, in order to keep
> + * the system preemption-latency down for large buffers.
>   */
>  void
>  drm_clflush_sg(struct sg_table *st)
>  {
> + might_sleep();
> +
>  #if defined(CONFIG_X86)
>   if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
> - struct sg_page_iter sg_iter;
> + struct sgt_iter sg_iter;
> + struct page *page;
>  
>   mb(); /*CLFLUSH is ordered only by using memory barriers*/
> - for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
> - drm_clflush_page(sg_page_iter_page(&sg_iter));
> + for_each_sgt_page(page, sg_iter, st)
> + drm_clflush_page(page);
>   mb(); /*Make sure that all cache line entry is flushed*/
>  
>   return;
> -- 
> 2.25.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/4] drm/simple-kms: Let DRM core send VBLANK events by default

[Daniel Vetter]

On Wed, Jan 15, 2020 at 01:52:26PM +0100, Thomas Zimmermann wrote:
> In drm_atomic_helper_fake_vblank() the DRM core sends out VBLANK events
> if struct drm_crtc_state.no_vblank is enabled in the check() callbacks.
> 
> For drivers that have neither an enable_vblank() callback nor a check()
> callback, the simple-KMS helpers enable VBLANK generation by default. This
> simplifies bochs, udl, several tiny drivers, and drivers based upon MIPI
> DPI helpers. The driver for Xen explicitly disables no_vblank, as it has
> its own logic for sending these events.
> 
> Signed-off-by: Thomas Zimmermann 

> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 15fb516ae2d8..4414c7a5b2ce 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -146,10 +146,21 @@ static int drm_simple_kms_plane_atomic_check(struct 
> drm_plane *plane,
>   if (!plane_state->visible)
>   return 0;
>  
> - if (!pipe->funcs || !pipe->funcs->check)
> - return 0;
> -
> - return pipe->funcs->check(pipe, plane_state, crtc_state);
> + if (pipe->funcs) {
> + if (pipe->funcs->check)
> + return pipe->funcs->check(pipe, plane_state,
> +   crtc_state);
> + if (pipe->funcs->enable_vblank)
> + return 0;
> + }
> +
> + /* Drivers without VBLANK support have to fake VBLANK events. As
> +  * there's no check() callback to enable this, set the no_vblank
> +  * field by default.
> +  */

The ->check callback is right above this comment ... I'm confused.

> + crtc_state->no_vblank = true;

That's kinda not what I meant with handling this automatically. Instead
something like this:


diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 7cf3cf936547..23d2f51fc1d4 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -149,6 +149,11 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
drm_crtc *crtc,
/* Self refresh should be canceled when a new update is available */
state->active = drm_atomic_crtc_effectively_active(state);
state->self_refresh_active = false;
+
+   if (drm_dev_has_vblank(crtc->dev))
+   state->no_vblank = true;
+   else
+   state->no_vblank = false;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
 
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 1659b13b178c..32cab3d3c872 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -81,6 +81,12 @@
  */
 #define DRM_REDUNDANT_VBLIRQ_THRESH_NS 100
 
+/* FIXME roll this out here in this file */
+bool drm_dev_has_vblank(dev)
+{
+   return dev->num_crtcs;
+}
+
 static bool
 drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
  ktime_t *tvblank, bool in_vblank_irq);


But maybe move the default value to some other/better place in the atomic
helpers, not sure what the best one is.

Plus then in the documentation patch also highlight the link between
crtc_state->no_vblank and drm_dev_has_vblank respectively
drm_device.num_crtcs.

That should plug this issue once for all across the board.

There's still the fun between having the vblank callbacks and the
drm_vblank setup, but that's a much older can of worms ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/trace: Buffer DRM logs in a ringbuffer accessible via debugfs

[Daniel Vetter]

On Tue, Jan 14, 2020 at 12:21:43PM -0500, Sean Paul wrote:
> From: Sean Paul 
> 
> This patch uses a ring_buffer to keep a "flight recorder" (name credit Weston)
> of DRM logs for a specified set of debug categories. The user writes a
> bitmask of debug categories to the "trace_mask" node and can read log
> messages from the "trace" node.
> 
> These nodes currently exist in debugfs under the dri directory. I
> intended on exposing all of this through tracefs originally, but the
> tracefs entry points are not exposed, so there's no way to create
> tracefs files from drivers at the moment. I think it would be a
> worthwhile endeavour, but one requiring more time and conversation to
> ensure the drm traces fit somewhere sensible.

Hm, since the idea is to ship this in production environments debugfs is
out. sysfs is also kinda the wrong thing, so maybe trying to get this
stuffed into tracefs is actually the way to go?
-Daniel

> 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Pekka Paalanen 
> Cc: Rob Clark 
> Cc: Steven Rostedt 
> Cc: Thomas Zimmermann 
> Cc: Ville Syrjälä 
> Signed-off-by: Sean Paul 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20191010204823.195540-1-s...@poorly.run
>  #v1
> Link: 
> https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html #v2
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20191212203301.142437-1-s...@poorly.run
>  #v3
> 
> Changes in v2:
> - Went with a completely different approach:
> https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html
> 
> Changes in v3:
> - Changed commit message to be a bit less RFC-y
> - Make class_drm_category_log an actual trace class
> 
> Changes in v4:
> - Instead of [ab]using trace events and the system trace buffer, use our
>   own ringbuffer
> ---
> ---
>  Documentation/gpu/drm-uapi.rst |   9 +
>  drivers/gpu/drm/Kconfig|   1 +
>  drivers/gpu/drm/Makefile   |   2 +-
>  drivers/gpu/drm/drm_drv.c  |   3 +
>  drivers/gpu/drm/drm_print.c|  80 +--
>  drivers/gpu/drm/drm_trace.c| 376 +
>  include/drm/drm_print.h|  39 
>  7 files changed, 487 insertions(+), 23 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_trace.c
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..089eb6fd3e94 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -312,6 +312,15 @@ Debugfs Support
>  .. kernel-doc:: drivers/gpu/drm/drm_debugfs.c
> :export:
>  
> +DRM Tracing
> +---
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_trace.c
> +   :doc: DRM Tracing
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_trace.c
> +   :internal:
> +
>  Sysfs Support
>  =
>  
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index d0aa6cff2e02..9d8077e87afe 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -14,6 +14,7 @@ menuconfig DRM
>   select I2C
>   select I2C_ALGOBIT
>   select DMA_SHARED_BUFFER
> + select RING_BUFFER
>   select SYNC_FILE
>   help
> Kernel-level support for the Direct Rendering Infrastructure (DRI)
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 6493088a0fdd..88b4674934e6 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -29,7 +29,7 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>  drm-$(CONFIG_OF) += drm_of.o
>  drm-$(CONFIG_AGP) += drm_agpsupport.o
>  drm-$(CONFIG_PCI) += drm_pci.o
> -drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> +drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o drm_trace.o
>  drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>  
>  drm_vram_helper-y := drm_gem_vram_helper.o \
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 7c18a980cd4b..98260b9f8004 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -1114,6 +1114,7 @@ static const struct file_operations drm_stub_fops = {
>  static void drm_core_exit(void)
>  {
>   unregister_chrdev(DRM_MAJOR, "drm");
> + drm_trace_cleanup();
>   debugfs_remove(drm_debugfs_root);
>   drm_sysfs_destroy();
>   idr_destroy(&drm_minors_idr);
> @@ -1135,6 +1136,8 @@ static int __init drm_core_init(void)
>  
>   drm_debugfs_root = debugfs_create_dir("dri", NULL);
>  
> + WARN_ON(drm_trace_init(drm_debugfs_root));
> +
>   ret = register_chrdev(DRM_MAJOR, "drm", &drm_stub_fops);
>   if (ret < 0)
>   goto error;
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 111b932cf2a9..0ac1867937bf 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -262,21 +262,37 @@ void drm_dev_dbg(const struct device *dev, enum 
> drm_debug_category category,
>   struct va_format vaf;
>   va_list args;
>  
> - if (!drm_debug_enabled(category)

linux-next: manual merge of the generic-ioremap tree with the drm-misc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the generic-ioremap tree got a conflict in:

  drivers/video/fbdev/s1d13xxxfb.c

between commit:

  091be7245a03 ("fbdev: s1d13xxxfb: use resource_size")

from the drm-misc tree and commit:

  4bdc0d676a64 ("remove ioremap_nocache and devm_ioremap_nocache")

from the generic-ioremap tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/video/fbdev/s1d13xxxfb.c
index c23defa27036,8048499e398d..
--- a/drivers/video/fbdev/s1d13xxxfb.c
+++ b/drivers/video/fbdev/s1d13xxxfb.c
@@@ -809,8 -809,8 +809,8 @@@ static int s1d13xxxfb_probe(struct plat
  
platform_set_drvdata(pdev, info);
default_par = info->par;
-   default_par->regs = ioremap_nocache(pdev->resource[1].start,
-   resource_size(&pdev->resource[1]));
+   default_par->regs = ioremap(pdev->resource[1].start,
 -  pdev->resource[1].end - pdev->resource[1].start +1);
++  resource_size(&pdev->resource[1]));
if (!default_par->regs) {
printk(KERN_ERR PFX "unable to map registers\n");
ret = -ENOMEM;
@@@ -818,8 -818,9 +818,8 @@@
}
info->pseudo_palette = default_par->pseudo_palette;
  
-   info->screen_base = ioremap_nocache(pdev->resource[0].start,
-   resource_size(&pdev->resource[0]));
+   info->screen_base = ioremap(pdev->resource[0].start,
 -  pdev->resource[0].end - pdev->resource[0].start +1);
 -
++  resource_size(&pdev->resource[0]));
if (!info->screen_base) {
printk(KERN_ERR PFX "unable to map framebuffer\n");
ret = -ENOMEM;


pgpNIGDUA4AdW.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/panfrost: Add the panfrost_gem_mapping concept

[Rob Herring]

On Wed, Jan 15, 2020 at 8:14 PM Rob Herring  wrote:
>
> From: Boris Brezillon 
>
> With the introduction of per-FD address space, the same BO can be mapped
> in different address space if the BO is globally visible (GEM_FLINK)
> and opened in different context or if the dmabuf is self-imported. The
> current implementation does not take case into account, and attaches the
> mapping directly to the panfrost_gem_object.
>
> Let's create a panfrost_gem_mapping struct and allow multiple mappings
> per BO.
>
> The mappings are refcounted which helps solve another problem where
> mappings were torn down (GEM handle closed by userspace) while GPU
> jobs accessing those BOs were still in-flight. Jobs now keep a
> reference on the mappings they use.
>
> v2 (robh):
> - Minor review comment clean-ups from Steven
> - Use list_is_singular helper
> - Just WARN if we add a mapping when madvise state is not WILLNEED.
>   With that, drop the use of object_name_lock.
>
> v3 (robh):
> - Revert returning list iterator in panfrost_gem_mapping_get()

Ignore this one...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm/panfrost: Add the panfrost_gem_mapping concept

[Rob Herring]

From: Boris Brezillon 

With the introduction of per-FD address space, the same BO can be mapped
in different address space if the BO is globally visible (GEM_FLINK)
and opened in different context or if the dmabuf is self-imported. The
current implementation does not take case into account, and attaches the
mapping directly to the panfrost_gem_object.

Let's create a panfrost_gem_mapping struct and allow multiple mappings
per BO.

The mappings are refcounted which helps solve another problem where
mappings were torn down (GEM handle closed by userspace) while GPU
jobs accessing those BOs were still in-flight. Jobs now keep a
reference on the mappings they use.

v2 (robh):
- Minor review comment clean-ups from Steven
- Use list_is_singular helper
- Just WARN if we add a mapping when madvise state is not WILLNEED.
  With that, drop the use of object_name_lock.

v3 (robh):
- Revert returning list iterator in panfrost_gem_mapping_get()

Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation")
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Cc: 
Signed-off-by: Boris Brezillon 
Signed-off-by: Rob Herring 
---
With the actual changes committed this time...

 drivers/gpu/drm/panfrost/panfrost_drv.c   |  91 +++--
 drivers/gpu/drm/panfrost/panfrost_gem.c   | 124 +++---
 drivers/gpu/drm/panfrost/panfrost_gem.h   |  41 +-
 .../gpu/drm/panfrost/panfrost_gem_shrinker.c  |   3 +-
 drivers/gpu/drm/panfrost/panfrost_job.c   |  13 +-
 drivers/gpu/drm/panfrost/panfrost_job.h   |   1 +
 drivers/gpu/drm/panfrost/panfrost_mmu.c   |  61 +
 drivers/gpu/drm/panfrost/panfrost_mmu.h   |   6 +-
 drivers/gpu/drm/panfrost/panfrost_perfcnt.c   |  34 +++--
 9 files changed, 300 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index f61364f7c471..88b431a267af 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -78,8 +78,10 @@ static int panfrost_ioctl_get_param(struct drm_device *ddev, 
void *data, struct
 static int panfrost_ioctl_create_bo(struct drm_device *dev, void *data,
struct drm_file *file)
 {
+   struct panfrost_file_priv *priv = file->driver_priv;
struct panfrost_gem_object *bo;
struct drm_panfrost_create_bo *args = data;
+   struct panfrost_gem_mapping *mapping;
 
if (!args->size || args->pad ||
(args->flags & ~(PANFROST_BO_NOEXEC | PANFROST_BO_HEAP)))
@@ -95,7 +97,14 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev, 
void *data,
if (IS_ERR(bo))
return PTR_ERR(bo);
 
-   args->offset = bo->node.start << PAGE_SHIFT;
+   mapping = panfrost_gem_mapping_get(bo, priv);
+   if (!mapping) {
+   drm_gem_object_put_unlocked(&bo->base.base);
+   return -EINVAL;
+   }
+
+   args->offset = mapping->mmnode.start << PAGE_SHIFT;
+   panfrost_gem_mapping_put(mapping);
 
return 0;
 }
@@ -119,6 +128,11 @@ panfrost_lookup_bos(struct drm_device *dev,
  struct drm_panfrost_submit *args,
  struct panfrost_job *job)
 {
+   struct panfrost_file_priv *priv = file_priv->driver_priv;
+   struct panfrost_gem_object *bo;
+   unsigned int i;
+   int ret;
+
job->bo_count = args->bo_handle_count;
 
if (!job->bo_count)
@@ -130,9 +144,32 @@ panfrost_lookup_bos(struct drm_device *dev,
if (!job->implicit_fences)
return -ENOMEM;
 
-   return drm_gem_objects_lookup(file_priv,
- (void __user 
*)(uintptr_t)args->bo_handles,
- job->bo_count, &job->bos);
+   ret = drm_gem_objects_lookup(file_priv,
+(void __user *)(uintptr_t)args->bo_handles,
+job->bo_count, &job->bos);
+   if (ret)
+   return ret;
+
+   job->mappings = kvmalloc_array(job->bo_count,
+  sizeof(struct panfrost_gem_mapping *),
+  GFP_KERNEL | __GFP_ZERO);
+   if (!job->mappings)
+   return -ENOMEM;
+
+   for (i = 0; i < job->bo_count; i++) {
+   struct panfrost_gem_mapping *mapping;
+
+   bo = to_panfrost_bo(job->bos[i]);
+   mapping = panfrost_gem_mapping_get(bo, priv);
+   if (!mapping) {
+   ret = -EINVAL;
+   break;
+   }
+
+   job->mappings[i] = mapping;
+   }
+
+   return ret;
 }
 
 /**
@@ -320,7 +357,9 @@ static int panfrost_ioctl_mmap_bo(struct drm_device *dev, 
void *data,
 static int panfrost_ioctl_get_bo_offset(struct drm_device *dev, void *data,
struct drm_file *file_priv)
 {
+   struct panfrost_file_priv *priv = file_priv->

[PATCH v9 5/5] drm/panel: support for auo, b101uan08.3 wuxga dsi video mode panel

[Jitao Shi]

Auo,auo,b101uan08.3's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So auo,b101uan08.3 and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.

Signed-off-by: Jitao Shi 
Reviewed-by: Sam Ravnborg 
---
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 78 +++
 1 file changed, 78 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index e77ea577d93a..01faf8597700 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -377,6 +377,53 @@ static const struct panel_init_cmd 
auo_kd101n80_45na_init_cmd[] = {
{},
 };
 
+static const struct panel_init_cmd auo_b101uan08_3_init_cmd[] = {
+   _INIT_DELAY_CMD(24),
+   _INIT_DCS_CMD(0xB0, 0x01),
+   _INIT_DCS_CMD(0xC0, 0x48),
+   _INIT_DCS_CMD(0xC1, 0x48),
+   _INIT_DCS_CMD(0xC2, 0x47),
+   _INIT_DCS_CMD(0xC3, 0x47),
+   _INIT_DCS_CMD(0xC4, 0x46),
+   _INIT_DCS_CMD(0xC5, 0x46),
+   _INIT_DCS_CMD(0xC6, 0x45),
+   _INIT_DCS_CMD(0xC7, 0x45),
+   _INIT_DCS_CMD(0xC8, 0x64),
+   _INIT_DCS_CMD(0xC9, 0x64),
+   _INIT_DCS_CMD(0xCA, 0x4F),
+   _INIT_DCS_CMD(0xCB, 0x4F),
+   _INIT_DCS_CMD(0xCC, 0x40),
+   _INIT_DCS_CMD(0xCD, 0x40),
+   _INIT_DCS_CMD(0xCE, 0x66),
+   _INIT_DCS_CMD(0xCF, 0x66),
+   _INIT_DCS_CMD(0xD0, 0x4F),
+   _INIT_DCS_CMD(0xD1, 0x4F),
+   _INIT_DCS_CMD(0xD2, 0x41),
+   _INIT_DCS_CMD(0xD3, 0x41),
+   _INIT_DCS_CMD(0xD4, 0x48),
+   _INIT_DCS_CMD(0xD5, 0x48),
+   _INIT_DCS_CMD(0xD6, 0x47),
+   _INIT_DCS_CMD(0xD7, 0x47),
+   _INIT_DCS_CMD(0xD8, 0x46),
+   _INIT_DCS_CMD(0xD9, 0x46),
+   _INIT_DCS_CMD(0xDA, 0x45),
+   _INIT_DCS_CMD(0xDB, 0x45),
+   _INIT_DCS_CMD(0xDC, 0x64),
+   _INIT_DCS_CMD(0xDD, 0x64),
+   _INIT_DCS_CMD(0xDE, 0x4F),
+   _INIT_DCS_CMD(0xDF, 0x4F),
+   _INIT_DCS_CMD(0xE0, 0x40),
+   _INIT_DCS_CMD(0xE1, 0x40),
+   _INIT_DCS_CMD(0xE2, 0x66),
+   _INIT_DCS_CMD(0xE3, 0x66),
+   _INIT_DCS_CMD(0xE4, 0x4F),
+   _INIT_DCS_CMD(0xE5, 0x4F),
+   _INIT_DCS_CMD(0xE6, 0x41),
+   _INIT_DCS_CMD(0xE7, 0x41),
+   _INIT_DELAY_CMD(150),
+   {},
+};
+
 static inline struct boe_panel *to_boe_panel(struct drm_panel *panel)
 {
return container_of(panel, struct boe_panel, base);
@@ -621,6 +668,34 @@ static const struct panel_desc boe_tv101wum_n53_desc = {
.init_cmds = boe_init_cmd,
 };
 
+static const struct drm_display_mode auo_b101uan08_3_default_mode = {
+   .clock = 159667,
+   .hdisplay = 1200,
+   .hsync_start = 1200 + 60,
+   .hsync_end = 1200 + 60 + 4,
+   .htotal = 1200 + 60 + 4 + 80,
+   .vdisplay = 1920,
+   .vsync_start = 1920 + 34,
+   .vsync_end = 1920 + 34 + 2,
+   .vtotal = 1920 + 34 + 2 + 24,
+   .vrefresh = 60,
+   .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const struct panel_desc auo_b101uan08_3_desc = {
+   .modes = &auo_b101uan08_3_default_mode,
+   .bpc = 8,
+   .size = {
+   .width_mm = 135,
+   .height_mm = 216,
+   },
+   .lanes = 4,
+   .format = MIPI_DSI_FMT_RGB888,
+   .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+   .init_cmds = auo_b101uan08_3_init_cmd,
+};
+
 static int boe_panel_get_modes(struct drm_panel *panel,
   struct drm_connector *connector)
 {
@@ -756,6 +831,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "boe,tv101wum-n53",
  .data = &boe_tv101wum_n53_desc
},
+   { .compatible = "auo,b101uan08.3",
+ .data = &auo_b101uan08_3_desc
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, boe_of_match);
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v9 3/5] drm/panel: support for auo, kd101n80-45na wuxga dsi video mode panel

[Jitao Shi]

Auo,kd101n80-45na's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So auo,kd101n80-45na and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.

Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/panel/Kconfig |  6 +-
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 64 +--
 2 files changed, 61 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ca727c233a9a..b5413edd625b 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,13 +30,13 @@ config DRM_PANEL_BOE_HIMAX8279D
  the host and has a built-in LED backlight.
 
 config DRM_PANEL_BOE_TV101WUM_NL6
-   tristate "BOE TV101WUM 1200x1920 panel"
+   tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
help
- Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
- DSI Video Mode panel
+ Say Y here if you want to support for BOE TV101WUM and AUO KD101N80
+ 45NA WUXGA PANEL DSI Video Mode panel
 
 config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 51fde588adc1..2160144ca51b 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -34,6 +34,7 @@ struct panel_desc {
enum mipi_dsi_pixel_format format;
const struct panel_init_cmd *init_cmds;
unsigned int lanes;
+   bool discharge_on_disable;
 };
 
 struct boe_panel {
@@ -367,6 +368,15 @@ static const struct panel_init_cmd boe_init_cmd[] = {
{},
 };
 
+static const struct panel_init_cmd auo_kd101n80_45na_init_cmd[] = {
+   _INIT_DELAY_CMD(24),
+   _INIT_DCS_CMD(0x11),
+   _INIT_DELAY_CMD(120),
+   _INIT_DCS_CMD(0x29),
+   _INIT_DELAY_CMD(120),
+   {},
+};
+
 static inline struct boe_panel *to_boe_panel(struct drm_panel *panel)
 {
return container_of(panel, struct boe_panel, base);
@@ -444,12 +454,22 @@ static int boe_panel_unprepare(struct drm_panel *panel)
}
 
msleep(150);
-   gpiod_set_value(boe->enable_gpio, 0);
-   usleep_range(500, 1000);
-   regulator_disable(boe->avee);
-   regulator_disable(boe->avdd);
-   usleep_range(5000, 7000);
-   regulator_disable(boe->pp1800);
+
+   if (boe->desc->discharge_on_disable) {
+   regulator_disable(boe->avee);
+   regulator_disable(boe->avdd);
+   usleep_range(5000, 7000);
+   gpiod_set_value(boe->enable_gpio, 0);
+   usleep_range(5000, 7000);
+   regulator_disable(boe->pp1800);
+   } else {
+   gpiod_set_value(boe->enable_gpio, 0);
+   usleep_range(500, 1000);
+   regulator_disable(boe->avee);
+   regulator_disable(boe->avdd);
+   usleep_range(5000, 7000);
+   regulator_disable(boe->pp1800);
+   }
 
boe->prepared = false;
 
@@ -542,6 +562,35 @@ static const struct panel_desc boe_tv101wum_nl6_desc = {
.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
  MIPI_DSI_MODE_LPM,
.init_cmds = boe_init_cmd,
+   .discharge_on_disable = false,
+};
+
+static const struct drm_display_mode auo_kd101n80_45na_default_mode = {
+   .clock = 157000,
+   .hdisplay = 1200,
+   .hsync_start = 1200 + 80,
+   .hsync_end = 1200 + 80 + 24,
+   .htotal = 1200 + 80 + 24 + 36,
+   .vdisplay = 1920,
+   .vsync_start = 1920 + 16,
+   .vsync_end = 1920 + 16 + 4,
+   .vtotal = 1920 + 16 + 4 + 16,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc auo_kd101n80_45na_desc = {
+   .modes = &auo_kd101n80_45na_default_mode,
+   .bpc = 8,
+   .size = {
+   .width_mm = 135,
+   .height_mm = 216,
+   },
+   .lanes = 4,
+   .format = MIPI_DSI_FMT_RGB888,
+   .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+   .init_cmds = auo_kd101n80_45na_init_cmd,
+   .discharge_on_disable = true,
 };
 
 static int boe_panel_get_modes(struct drm_panel *panel,
@@ -673,6 +722,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "boe,tv101wum-nl6",
  .data = &boe_tv101wum_nl6_desc
},
+   { .compatible = "auo,kd101n80-45na",
+ .data = &auo_kd101n80_45na_desc
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, boe_of_match);
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v9 2/5] drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel

[Jitao Shi]

Add driver for BOE tv101wum-nl6 panel is a 10.1" 1200x1920 panel.

Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 693 ++
 3 files changed, 703 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ae44ac2ec106..ca727c233a9a 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -29,6 +29,15 @@ config DRM_PANEL_BOE_HIMAX8279D
  24 bit RGB per pixel. It provides a MIPI DSI interface to
  the host and has a built-in LED backlight.
 
+config DRM_PANEL_BOE_TV101WUM_NL6
+   tristate "BOE TV101WUM 1200x1920 panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
+ DSI Video Mode panel
+
 config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 7c4d3c581fd4..a659ce403d0e 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
 obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
+obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += 
panel-feiyang-fy07024di26a30d.o
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
new file mode 100644
index ..51fde588adc1
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -0,0 +1,693 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Jitao Shi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+struct panel_desc {
+   const struct drm_display_mode *modes;
+   unsigned int bpc;
+
+   /**
+* @width_mm: width of the panel's active display area
+* @height_mm: height of the panel's active display area
+*/
+   struct {
+   unsigned int width_mm;
+   unsigned int height_mm;
+   } size;
+
+   unsigned long mode_flags;
+   enum mipi_dsi_pixel_format format;
+   const struct panel_init_cmd *init_cmds;
+   unsigned int lanes;
+};
+
+struct boe_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   const struct panel_desc *desc;
+
+   struct regulator *pp1800;
+   struct regulator *avee;
+   struct regulator *avdd;
+   struct gpio_desc *enable_gpio;
+
+   bool prepared;
+};
+
+enum dsi_cmd_type {
+   INIT_DCS_CMD,
+   DELAY_CMD,
+};
+
+struct panel_init_cmd {
+   enum dsi_cmd_type type;
+   size_t len;
+   const char *data;
+};
+
+#define _INIT_DCS_CMD(...) { \
+   .type = INIT_DCS_CMD, \
+   .len = sizeof((char[]){__VA_ARGS__}), \
+   .data = (char[]){__VA_ARGS__} }
+
+#define _INIT_DELAY_CMD(...) { \
+   .type = DELAY_CMD,\
+   .len = sizeof((char[]){__VA_ARGS__}), \
+   .data = (char[]){__VA_ARGS__} }
+
+static const struct panel_init_cmd boe_init_cmd[] = {
+   _INIT_DELAY_CMD(24),
+   _INIT_DCS_CMD(0xB0, 0x05),
+   _INIT_DCS_CMD(0xB1, 0xE5),
+   _INIT_DCS_CMD(0xB3, 0x52),
+   _INIT_DCS_CMD(0xB0, 0x00),
+   _INIT_DCS_CMD(0xB3, 0x88),
+   _INIT_DCS_CMD(0xB0, 0x04),
+   _INIT_DCS_CMD(0xB8, 0x00),
+   _INIT_DCS_CMD(0xB0, 0x00),
+   _INIT_DCS_CMD(0xB6, 0x03),
+   _INIT_DCS_CMD(0xBA, 0x8B),
+   _INIT_DCS_CMD(0xBF, 0x1A),
+   _INIT_DCS_CMD(0xC0, 0x0F),
+   _INIT_DCS_CMD(0xC2, 0x0C),
+   _INIT_DCS_CMD(0xC3, 0x02),
+   _INIT_DCS_CMD(0xC4, 0x0C),
+   _INIT_DCS_CMD(0xC5, 0x02),
+   _INIT_DCS_CMD(0xB0, 0x01),
+   _INIT_DCS_CMD(0xE0, 0x26),
+   _INIT_DCS_CMD(0xE1, 0x26),
+   _INIT_DCS_CMD(0xDC, 0x00),
+   _INIT_DCS_CMD(0xDD, 0x00),
+   _INIT_DCS_CMD(0xCC, 0x26),
+   _INIT_DCS_CMD(0xCD, 0x26),
+   _INIT_DCS_CMD(0xC8, 0x00),
+   _INIT_DCS_CMD(0xC9, 0x00),
+   _INIT_DCS_CMD(0xD2, 0x03),
+   _INIT_DCS_CMD(0xD3, 0x03),
+   _INIT_DCS_CMD(0xE6, 0x04),
+   _INIT_DCS_CMD(0xE7, 0x04),
+   _INIT_DCS_CMD(0xC4, 0x09),
+   _INIT_DCS_CMD(0xC5, 0x09),
+   _INIT_DCS_CMD(0xD8, 0x0A),
+   _INIT_DCS_CMD(0xD9, 0x0A),
+   _INIT_DCS_CMD(0xC2, 0x0B),
+   _INIT_DCS_CMD(0xC3, 0x0B),
+   _INIT_DCS_CMD(0xD6, 0x0C),
+   _INIT_DCS_CMD(0xD7, 0x0C),
+   _INIT_DCS_CMD(0xC0, 0x05),
+   _INIT_DCS_CMD(0xC1, 0x05),
+   _INIT_DCS_C

[PATCH v9 1/5] dt-bindings: display: panel: Add boe tv101wum-n16 panel bindings

[Jitao Shi]

Add documentation for "boe,tv101wum-n16", "auo,kd101n80-45na",
"boe,tv101wum-n53" and "auo,b101uan08.3" panels.

Signed-off-by: Jitao Shi 
Reviewed-by: Sam Ravnborg 
---
 .../display/panel/boe,tv101wum-nl6.yaml   | 81 +++
 1 file changed, 81 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml 
b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
new file mode 100644
index ..cc4e058f5eee
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-nl6.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TV101WUM-NL6 DSI Display Panel
+
+maintainers:
+  - Thierry Reding 
+  - Sam Ravnborg 
+  - Rob Herring 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+enum:
+# BOE TV101WUM-NL6 10.1" WUXGA TFT LCD panel
+  - boe,tv101wum-nl6
+# AUO KD101N80-45NA 10.1" WUXGA TFT LCD panel
+  - auo,kd101n80-45na
+# BOE TV101WUM-N53 10.1" WUXGA TFT LCD panel
+  - boe,tv101wum-n53
+# AUO B101UAN08.3 10.1" WUXGA TFT LCD panel
+  - auo,b101uan08.3
+
+  reg:
+description: the virtual channel number of a DSI peripheral
+
+  enable-gpios:
+description: a GPIO spec for the enable pin
+
+  pp1800-supply:
+description: core voltage supply
+
+  avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+  avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+  backlight:
+description: phandle of the backlight device attached to the panel
+
+  port: true
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+
+additionalProperties: false
+
+examples:
+  - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "boe,tv101wum-nl6";
+reg = <0>;
+enable-gpios = <&pio 45 0>;
+avdd-supply = <&ppvarn_lcd>;
+avee-supply = <&ppvarp_lcd>;
+pp1800-supply = <&pp1800_lcd>;
+backlight = <&backlight_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <&dsi_out>;
+};
+};
+};
+};
+
+...
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v9 4/5] drm/panel: support for boe, tv101wum-n53 wuxga dsi video mode panel

[Jitao Shi]

Boe,tv101wum-n53's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So boe,tv101wum-n53 and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.

Signed-off-by: Jitao Shi 
Reviewed-by: Sam Ravnborg 
---
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 2160144ca51b..e77ea577d93a 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -593,6 +593,34 @@ static const struct panel_desc auo_kd101n80_45na_desc = {
.discharge_on_disable = true,
 };
 
+static const struct drm_display_mode boe_tv101wum_n53_default_mode = {
+   .clock = 159916,
+   .hdisplay = 1200,
+   .hsync_start = 1200 + 80,
+   .hsync_end = 1200 + 80 + 24,
+   .htotal = 1200 + 80 + 24 + 40,
+   .vdisplay = 1920,
+   .vsync_start = 1920 + 20,
+   .vsync_end = 1920 + 20 + 4,
+   .vtotal = 1920 + 20 + 4 + 10,
+   .vrefresh = 60,
+   .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const struct panel_desc boe_tv101wum_n53_desc = {
+   .modes = &boe_tv101wum_n53_default_mode,
+   .bpc = 8,
+   .size = {
+   .width_mm = 135,
+   .height_mm = 216,
+   },
+   .lanes = 4,
+   .format = MIPI_DSI_FMT_RGB888,
+   .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+   .init_cmds = boe_init_cmd,
+};
+
 static int boe_panel_get_modes(struct drm_panel *panel,
   struct drm_connector *connector)
 {
@@ -725,6 +753,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "auo,kd101n80-45na",
  .data = &auo_kd101n80_45na_desc
},
+   { .compatible = "boe,tv101wum-n53",
+ .data = &boe_tv101wum_n53_desc
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, boe_of_match);
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm/panfrost: Add the panfrost_gem_mapping concept

[Rob Herring]

From: Boris Brezillon 

With the introduction of per-FD address space, the same BO can be mapped
in different address space if the BO is globally visible (GEM_FLINK)
and opened in different context or if the dmabuf is self-imported. The
current implementation does not take case into account, and attaches the
mapping directly to the panfrost_gem_object.

Let's create a panfrost_gem_mapping struct and allow multiple mappings
per BO.

The mappings are refcounted which helps solve another problem where
mappings were torn down (GEM handle closed by userspace) while GPU
jobs accessing those BOs were still in-flight. Jobs now keep a
reference on the mappings they use.

v2 (robh):
- Minor review comment clean-ups from Steven
- Use list_is_singular helper
- Just WARN if we add a mapping when madvise state is not WILLNEED.
  With that, drop the use of object_name_lock.

v3 (robh):
- Revert returning list iterator in panfrost_gem_mapping_get()

Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation")
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Cc: 
Signed-off-by: Boris Brezillon 
Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/panfrost/panfrost_drv.c   |  91 +++--
 drivers/gpu/drm/panfrost/panfrost_gem.c   | 123 +++---
 drivers/gpu/drm/panfrost/panfrost_gem.h   |  41 +-
 .../gpu/drm/panfrost/panfrost_gem_shrinker.c  |   3 +-
 drivers/gpu/drm/panfrost/panfrost_job.c   |  13 +-
 drivers/gpu/drm/panfrost/panfrost_job.h   |   1 +
 drivers/gpu/drm/panfrost/panfrost_mmu.c   |  61 +
 drivers/gpu/drm/panfrost/panfrost_mmu.h   |   6 +-
 drivers/gpu/drm/panfrost/panfrost_perfcnt.c   |  34 +++--
 9 files changed, 299 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index f61364f7c471..88b431a267af 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -78,8 +78,10 @@ static int panfrost_ioctl_get_param(struct drm_device *ddev, 
void *data, struct
 static int panfrost_ioctl_create_bo(struct drm_device *dev, void *data,
struct drm_file *file)
 {
+   struct panfrost_file_priv *priv = file->driver_priv;
struct panfrost_gem_object *bo;
struct drm_panfrost_create_bo *args = data;
+   struct panfrost_gem_mapping *mapping;
 
if (!args->size || args->pad ||
(args->flags & ~(PANFROST_BO_NOEXEC | PANFROST_BO_HEAP)))
@@ -95,7 +97,14 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev, 
void *data,
if (IS_ERR(bo))
return PTR_ERR(bo);
 
-   args->offset = bo->node.start << PAGE_SHIFT;
+   mapping = panfrost_gem_mapping_get(bo, priv);
+   if (!mapping) {
+   drm_gem_object_put_unlocked(&bo->base.base);
+   return -EINVAL;
+   }
+
+   args->offset = mapping->mmnode.start << PAGE_SHIFT;
+   panfrost_gem_mapping_put(mapping);
 
return 0;
 }
@@ -119,6 +128,11 @@ panfrost_lookup_bos(struct drm_device *dev,
  struct drm_panfrost_submit *args,
  struct panfrost_job *job)
 {
+   struct panfrost_file_priv *priv = file_priv->driver_priv;
+   struct panfrost_gem_object *bo;
+   unsigned int i;
+   int ret;
+
job->bo_count = args->bo_handle_count;
 
if (!job->bo_count)
@@ -130,9 +144,32 @@ panfrost_lookup_bos(struct drm_device *dev,
if (!job->implicit_fences)
return -ENOMEM;
 
-   return drm_gem_objects_lookup(file_priv,
- (void __user 
*)(uintptr_t)args->bo_handles,
- job->bo_count, &job->bos);
+   ret = drm_gem_objects_lookup(file_priv,
+(void __user *)(uintptr_t)args->bo_handles,
+job->bo_count, &job->bos);
+   if (ret)
+   return ret;
+
+   job->mappings = kvmalloc_array(job->bo_count,
+  sizeof(struct panfrost_gem_mapping *),
+  GFP_KERNEL | __GFP_ZERO);
+   if (!job->mappings)
+   return -ENOMEM;
+
+   for (i = 0; i < job->bo_count; i++) {
+   struct panfrost_gem_mapping *mapping;
+
+   bo = to_panfrost_bo(job->bos[i]);
+   mapping = panfrost_gem_mapping_get(bo, priv);
+   if (!mapping) {
+   ret = -EINVAL;
+   break;
+   }
+
+   job->mappings[i] = mapping;
+   }
+
+   return ret;
 }
 
 /**
@@ -320,7 +357,9 @@ static int panfrost_ioctl_mmap_bo(struct drm_device *dev, 
void *data,
 static int panfrost_ioctl_get_bo_offset(struct drm_device *dev, void *data,
struct drm_file *file_priv)
 {
+   struct panfrost_file_priv *priv = file_priv->driver_priv;
struct drm_panfrost_get_bo_

[PATCH v9 0/5] add driver for "boe, tv101wum-nl6", "boe, tv101wum-n53", "auo, kd101n80-45na" and "auo, b101uan08.3" panels

[Jitao Shi]

Changes since v8:
 - merge the panel documents to one.
 - delay move the drm_panel_of_backlight after drm_panel_init

Changes since v7:
 - base drm-misc-next branch
 - fix document pass dt_binding_check
 - remove backlight from panel driver

Changes since v6:
 - fix boe_panel_init err uninit.
 - adjust the delay of backlight on.

Changes since v5:
 - covert the documents to yaml
 - fine tune boe, tv101wum-n53 panel video timine

Changes since v4:
 - add auo,b101uan08.3 panel for this driver.
 - add boe,tv101wum-n53 panel for this driver.

Changes since v3:
 - remove check enable_gpio.
 - fine tune the auo,kd101n80-45na panel's power on timing.

Changes since v2:
 - correct the panel size
 - remove blank line in Kconfig
 - move auo,kd101n80-45na panel driver in this series.

Changes since v1:
 - update typo nl6 -> n16.
 - update new panel config and makefile are added in alphabetically order.
 - add the panel mode and panel info in driver data.
 - merge auo,kd101n80-45a and boe,tv101wum-nl6 in one driver

Jitao Shi (5):
  dt-bindings: display: panel: Add boe tv101wum-n16 panel bindings
  drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel
  drm/panel: support for auo,kd101n80-45na wuxga dsi video mode panel
  drm/panel: support for boe,tv101wum-n53 wuxga dsi video mode panel
  drm/panel: support for auo,b101uan08.3 wuxga dsi video mode panel

 .../display/panel/boe,tv101wum-nl6.yaml   |  81 ++
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 854 ++
 4 files changed, 945 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
 create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c

-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm/dp_mst: Have DP_Tx send one msg at a time

[Lin, Wayne]

[AMD Public Use]

Appreciate for your time.
Thanks!

> -Original Message-
> From: Lyude Paul 
> Sent: Thursday, January 16, 2020 5:58 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry 
> Subject: Re: [PATCH] drm/dp_mst: Have DP_Tx send one msg at a time
> 
> Reviewed-by: Lyude Paul 
> 
> I will push this to drm-misc-fixes in just a moment, thanks!
> 
> On Mon, 2020-01-13 at 17:36 +0800, Wayne Lin wrote:
> > [Why]
> > Noticed this while testing MST with the 4 ports MST hub from
> > StarTech.com. Sometimes can't light up monitors normally and get the
> > error message as 'sideband msg build failed'.
> >
> > Look into aux transactions, found out that source sometimes will send
> > out another down request before receiving the down reply of the
> > previous down request. On the other hand, in drm_dp_get_one_sb_msg(),
> > current code doesn't handle the interleaved replies case. Hence,
> > source can't build up message completely and can't light up monitors.
> >
> > [How]
> > For good compatibility, enforce source to send out one down request at
> > a time. Add a flag, is_waiting_for_dwn_reply, to determine if the
> > source can send out a down request immediately or not.
> >
> > - Check the flag before calling process_single_down_tx_qlock to send
> > out a msg
> > - Set the flag when successfully send out a down request
> > - Clear the flag when successfully build up a down reply
> > - Clear the flag when find erros during sending out a down request
> > - Clear the flag when find errors during building up a down reply
> > - Clear the flag when timeout occurs during waiting for a down reply
> > - Use drm_dp_mst_kick_tx() to try to send another down request in
> > queue at the end of drm_dp_mst_wait_tx_reply() (attempt to send out
> > messages in queue when errors occur)
> >
> > Cc: Lyude Paul 
> > Signed-off-by: Wayne Lin 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 14 --
> >  include/drm/drm_dp_mst_helper.h   |  6 ++
> >  2 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 4395d5cc0645..3542af15387a 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1195,6 +1195,8 @@ static int drm_dp_mst_wait_tx_reply(struct
> > drm_dp_mst_branch *mstb,
> > txmsg->state == DRM_DP_SIDEBAND_TX_SENT) {
> > mstb->tx_slots[txmsg->seqno] = NULL;
> > }
> > +   mgr->is_waiting_for_dwn_reply = false;
> > +
> > }
> >  out:
> > if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) { @@
> > -1204,6 +1206,7 @@ static int drm_dp_mst_wait_tx_reply(struct
> > drm_dp_mst_branch *mstb,
> > }
> > mutex_unlock(&mgr->qlock);
> >
> > +   drm_dp_mst_kick_tx(mgr);
> > return ret;
> >  }
> >
> > @@ -2770,9 +2773,11 @@ static void process_single_down_tx_qlock(struct
> > drm_dp_mst_topology_mgr *mgr)
> > ret = process_single_tx_qlock(mgr, txmsg, false);
> > if (ret == 1) {
> > /* txmsg is sent it should be in the slots now */
> > +   mgr->is_waiting_for_dwn_reply = true;
> > list_del(&txmsg->next);
> > } else if (ret) {
> > DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
> > +   mgr->is_waiting_for_dwn_reply = false;
> > list_del(&txmsg->next);
> > if (txmsg->seqno != -1)
> > txmsg->dst->tx_slots[txmsg->seqno] = NULL; @@ -2812,7
> +2817,8 @@
> > static void drm_dp_queue_down_tx(struct drm_dp_mst_topology_mgr *mgr,
> > drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> > }
> >
> > -   if (list_is_singular(&mgr->tx_msg_downq))
> > +   if (list_is_singular(&mgr->tx_msg_downq) &&
> > +   !mgr->is_waiting_for_dwn_reply)
> > process_single_down_tx_qlock(mgr);
> > mutex_unlock(&mgr->qlock);
> >  }
> > @@ -3743,6 +3749,7 @@ static int drm_dp_mst_handle_down_rep(struct
> > drm_dp_mst_topology_mgr *mgr)
> > mutex_lock(&mgr->qlock);
> > txmsg->state = DRM_DP_SIDEBAND_TX_RX;
> > mstb->tx_slots[slot] = NULL;
> > +   mgr->is_waiting_for_dwn_reply = false;
> > mutex_unlock(&mgr->qlock);
> >
> > wake_up_all(&mgr->tx_waitq);
> > @@ -3752,6 +3759,9 @@ static int drm_dp_mst_handle_down_rep(struct
> > drm_dp_mst_topology_mgr *mgr)
> >  no_msg:
> > drm_dp_mst_topology_put_mstb(mstb);
> >  clear_down_rep_recv:
> > +   mutex_lock(&mgr->qlock);
> > +   mgr->is_waiting_for_dwn_reply = false;
> > +   mutex_unlock(&mgr->qlock);
> > memset(&mgr->down_rep_recv, 0, sizeof(struct
> > drm_dp_sideband_msg_rx));
> >
> > return 0;
> > @@ -4591,7 +4601,7 @@ static void drm_dp_tx_work(struct work_struct
> *work)
> > struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct
> > drm_dp_mst_topology_mgr, tx_work);
> >
> > mutex

[pull] amdgpu drm-fixes-5.5

[Alex Deucher]

Hi Dave, Daniel,

A couple of small fixes for 5.5.

The following changes since commit 023b3b0e139f54a680202790ba801f61aa43a5c8:

  Merge tag 'drm-intel-fixes-2020-01-09-1' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2020-01-10 11:43:02 
+1000)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.5-2020-01-15

for you to fetch changes up to 3b7c59754cc22760760a84ebddb8e0b1e8dd871b:

  drm/amd/display: Reorder detect_edp_sink_caps before link settings read. 
(2020-01-15 17:54:54 -0500)


amd-drm-fixes-5.5-2020-01-15:
- Update golden settings for renoir
- eDP fix


Aaron Liu (1):
  drm/amdgpu: update goldensetting for renoir

Mario Kleiner (1):
  drm/amd/display: Reorder detect_edp_sink_caps before link settings read.

 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c| 2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 19/21] drm/vkms: Convert to CRTC VBLANK callbacks

[Rodrigo Siqueira]

Hi,

Thanks for the patch, I reviewed and tested it. Everything looks fine
for VKMS.

Reviewed-by: Rodrigo Siqueira 
Tested-by: Rodrigo Siqueira 

On 01/15, Thomas Zimmermann wrote:
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert vkms over.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/vkms/vkms_crtc.c | 9 ++---
>  drivers/gpu/drm/vkms/vkms_drv.c  | 1 -
>  drivers/gpu/drm/vkms/vkms_drv.h  | 4 
>  3 files changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 74f703b8d22a..ac85e17428f8 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -76,10 +76,12 @@ static void vkms_disable_vblank(struct drm_crtc *crtc)
>   hrtimer_cancel(&out->vblank_hrtimer);
>  }
>  
> -bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe,
> -int *max_error, ktime_t *vblank_time,
> -bool in_vblank_irq)
> +static bool vkms_get_vblank_timestamp(struct drm_crtc *crtc,
> +   int *max_error, ktime_t *vblank_time,
> +   bool in_vblank_irq)
>  {
> + struct drm_device *dev = crtc->dev;
> + unsigned int pipe = crtc->index;
>   struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
>   struct vkms_output *output = &vkmsdev->output;
>   struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> @@ -154,6 +156,7 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
>   .atomic_destroy_state   = vkms_atomic_crtc_destroy_state,
>   .enable_vblank  = vkms_enable_vblank,
>   .disable_vblank = vkms_disable_vblank,
> + .get_vblank_timestamp   = vkms_get_vblank_timestamp,
>   .get_crc_sources= vkms_get_crc_sources,
>   .set_crc_source = vkms_set_crc_source,
>   .verify_crc_source  = vkms_verify_crc_source,
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 25bd7519295f..860de052e820 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -103,7 +103,6 @@ static struct drm_driver vkms_driver = {
>   .dumb_create= vkms_dumb_create,
>   .gem_vm_ops = &vkms_gem_vm_ops,
>   .gem_free_object_unlocked = vkms_gem_free_object,
> - .get_vblank_timestamp   = vkms_get_vblank_timestamp,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>   .gem_prime_import_sg_table = vkms_prime_import_sg_table,
>  
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 7d52e24564db..eda04ffba7b1 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -111,10 +111,6 @@ struct vkms_gem_object {
>  int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
>  struct drm_plane *primary, struct drm_plane *cursor);
>  
> -bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int pipe,
> -int *max_error, ktime_t *vblank_time,
> -bool in_vblank_irq);
> -
>  int vkms_output_init(struct vkms_device *vkmsdev, int index);
>  
>  struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev,
> -- 
> 2.24.1
> 

-- 
Rodrigo Siqueira
Software Engineer, Advanced Micro Devices (AMD)
https://siqueira.tech


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/10] drm/vkms: plane_state->fb iff plane_state->crtc

[Rodrigo Siqueira]

Hi Sam,

On 01/15, Sam Ravnborg wrote:
> Hi Rodrigo.
> 
> On Tue, Jan 14, 2020 at 06:50:13PM -0500, Rodrigo Siqueira wrote:
> > On 12/13, Daniel Vetter wrote:
> > > Checking both is one too much, so wrap a WARN_ON around it to stope
> > > the copypasta.
> > > 
> > > Signed-off-by: Daniel Vetter 
> > > Cc: Rodrigo Siqueira 
> > > Cc: Haneen Mohammed 
> > > Cc: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/vkms/vkms_plane.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/vkms/vkms_plane.c 
> > > b/drivers/gpu/drm/vkms/vkms_plane.c
> > > index 5fc8f85aaf3d..6d31265a2ab7 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_plane.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> > > @@ -117,7 +117,7 @@ static int vkms_plane_atomic_check(struct drm_plane 
> > > *plane,
> > >   bool can_position = false;
> > >   int ret;
> > >  
> > > - if (!state->fb | !state->crtc)
> > > + if (!state->fb || WARN_ON(!state->crtc))
> > >   return 0;
> > >  
> > >   crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
> > > -- 
> > > 2.24.0
> > >
> > 
> > Hi,
> > 
> > Sorry, the delay in taking a look at this patch.
> > 
> > I tried to find the whole series for getting the context related to this
> > patch, but I could not find it in my mailbox. Could you shed some light
> > here? Why check fb and crtc is too much? How the WARN_ON fix the issue?
> 
> You can find some background in the first patch:
> https://lists.freedesktop.org/archives/dri-devel/2019-December/248981.html

Thanks for the link.

Reviewed-by: Rodrigo Siqueira 
Tested-by: Rodrigo Siqueira 

Best Regards
 
> Hope this sched enough light on the topic.
> 
>   Sam

-- 
Rodrigo Siqueira
Software Engineer, Advanced Micro Devices (AMD)
https://siqueira.tech


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 1/5] dt-bindings: display: sitronix, st7735r: Convert to DT schema

[Geert Uytterhoeven]

Hi Sam,

On Wed, Jan 15, 2020 at 10:01 PM Sam Ravnborg  wrote:
> On Wed, Jan 15, 2020 at 01:45:44PM +0100, Geert Uytterhoeven wrote:
> > Convert the DT binding documentation for Sitronix ST7735R displays to DT
> > schema.
> >
> > Add a reference to the Adafruit 1.8" LCD while at it.
> >
> > Signed-off-by: Geert Uytterhoeven 
> > ---
>
> > diff --git 
> > a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml 
> > b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
> > new file mode 100644
> > index ..21bccc91f74255e1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
> > @@ -0,0 +1,65 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> Use (GPL-2.0-only OR BSD-2-Clause) for new binding files.

I used GPL-2.0-only, as this is a conversion of an existing binding file,
covered by the default GPL-2.0-only of the Linux kernel source tree.

> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/sitronix,st7735r.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Sitronix ST7735R Display Panels Device Tree Bindings
> > +
> > +maintainers:
> > +  - David Lechner 
> > +
> > +description:
> > +  This binding is for display panels using a Sitronix ST7735R controller in
> > +  SPI mode.
> > +
> > +allOf:
> > +  - $ref: panel/panel-common.yaml#
>
> I am no binding expert so I do not know how to add it.
> But the old binding described that this MUST be a child of spi.
> This is missing here.
>
> Other panels using spi does not have it - so it is probarly OK.

Yeah, I couldn't find any examples of expressing that requirement in yaml.

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/dp_mst: Have DP_Tx send one msg at a time

[Lyude Paul]

Reviewed-by: Lyude Paul 

I will push this to drm-misc-fixes in just a moment, thanks!

On Mon, 2020-01-13 at 17:36 +0800, Wayne Lin wrote:
> [Why]
> Noticed this while testing MST with the 4 ports MST hub from
> StarTech.com. Sometimes can't light up monitors normally and get the
> error message as 'sideband msg build failed'.
> 
> Look into aux transactions, found out that source sometimes will send
> out another down request before receiving the down reply of the
> previous down request. On the other hand, in drm_dp_get_one_sb_msg(),
> current code doesn't handle the interleaved replies case. Hence, source
> can't build up message completely and can't light up monitors.
> 
> [How]
> For good compatibility, enforce source to send out one down request at a
> time. Add a flag, is_waiting_for_dwn_reply, to determine if the source
> can send out a down request immediately or not.
> 
> - Check the flag before calling process_single_down_tx_qlock to send out
> a msg
> - Set the flag when successfully send out a down request
> - Clear the flag when successfully build up a down reply
> - Clear the flag when find erros during sending out a down request
> - Clear the flag when find errors during building up a down reply
> - Clear the flag when timeout occurs during waiting for a down reply
> - Use drm_dp_mst_kick_tx() to try to send another down request in queue
> at the end of drm_dp_mst_wait_tx_reply() (attempt to send out messages
> in queue when errors occur)
> 
> Cc: Lyude Paul 
> Signed-off-by: Wayne Lin 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 14 --
>  include/drm/drm_dp_mst_helper.h   |  6 ++
>  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 4395d5cc0645..3542af15387a 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1195,6 +1195,8 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
>   txmsg->state == DRM_DP_SIDEBAND_TX_SENT) {
>   mstb->tx_slots[txmsg->seqno] = NULL;
>   }
> + mgr->is_waiting_for_dwn_reply = false;
> +
>   }
>  out:
>   if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) {
> @@ -1204,6 +1206,7 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
>   }
>   mutex_unlock(&mgr->qlock);
>  
> + drm_dp_mst_kick_tx(mgr);
>   return ret;
>  }
>  
> @@ -2770,9 +2773,11 @@ static void process_single_down_tx_qlock(struct
> drm_dp_mst_topology_mgr *mgr)
>   ret = process_single_tx_qlock(mgr, txmsg, false);
>   if (ret == 1) {
>   /* txmsg is sent it should be in the slots now */
> + mgr->is_waiting_for_dwn_reply = true;
>   list_del(&txmsg->next);
>   } else if (ret) {
>   DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
> + mgr->is_waiting_for_dwn_reply = false;
>   list_del(&txmsg->next);
>   if (txmsg->seqno != -1)
>   txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> @@ -2812,7 +2817,8 @@ static void drm_dp_queue_down_tx(struct
> drm_dp_mst_topology_mgr *mgr,
>   drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
>   }
>  
> - if (list_is_singular(&mgr->tx_msg_downq))
> + if (list_is_singular(&mgr->tx_msg_downq) &&
> + !mgr->is_waiting_for_dwn_reply)
>   process_single_down_tx_qlock(mgr);
>   mutex_unlock(&mgr->qlock);
>  }
> @@ -3743,6 +3749,7 @@ static int drm_dp_mst_handle_down_rep(struct
> drm_dp_mst_topology_mgr *mgr)
>   mutex_lock(&mgr->qlock);
>   txmsg->state = DRM_DP_SIDEBAND_TX_RX;
>   mstb->tx_slots[slot] = NULL;
> + mgr->is_waiting_for_dwn_reply = false;
>   mutex_unlock(&mgr->qlock);
>  
>   wake_up_all(&mgr->tx_waitq);
> @@ -3752,6 +3759,9 @@ static int drm_dp_mst_handle_down_rep(struct
> drm_dp_mst_topology_mgr *mgr)
>  no_msg:
>   drm_dp_mst_topology_put_mstb(mstb);
>  clear_down_rep_recv:
> + mutex_lock(&mgr->qlock);
> + mgr->is_waiting_for_dwn_reply = false;
> + mutex_unlock(&mgr->qlock);
>   memset(&mgr->down_rep_recv, 0, sizeof(struct drm_dp_sideband_msg_rx));
>  
>   return 0;
> @@ -4591,7 +4601,7 @@ static void drm_dp_tx_work(struct work_struct *work)
>   struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct
> drm_dp_mst_topology_mgr, tx_work);
>  
>   mutex_lock(&mgr->qlock);
> - if (!list_empty(&mgr->tx_msg_downq))
> + if (!list_empty(&mgr->tx_msg_downq) && !mgr->is_waiting_for_dwn_reply)
>   process_single_down_tx_qlock(mgr);
>   mutex_unlock(&mgr->qlock);
>  }
> diff --git a/include/drm/drm_dp_mst_helper.h
> b/include/drm/drm_dp_mst_helper.h
> index 942575de86a0..d0b45468135a 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -610,6 +610,12 @@ struct drm_dp_mst_topology

Re: [PATCH v12 11/22] mm/gup: introduce pin_user_pages*() and FOLL_PIN

[John Hubbard]

On 1/15/20 7:30 AM, Christoph Hellwig wrote:
> On Tue, Jan 07, 2020 at 02:45:47PM -0800, John Hubbard wrote:
>> Introduce pin_user_pages*() variations of get_user_pages*() calls,
>> and also pin_longterm_pages*() variations.
>>
>> For now, these are placeholder calls, until the various call sites
>> are converted to use the correct get_user_pages*() or
>> pin_user_pages*() API.
> 
> What do the pure placeholders buy us?  The API itself looks ok,
> but until it actually is properly implemented it doesn't help at
> all, and we've had all kinds of bad experiences with these sorts
> of stub APIs.
> 

Hi Christoph,

Absolutely agreed, and in fact, after spending some time in this area I 
am getting a much better understanding of just how problematic "this will 
be used soon" APIs really are. However, this is not quite that case.

The following things make this different from a "pure placeholder" API:

1) These APIs are all exercised in the following patches in this series, 
unless I've overlooked one, and

2) The pages are actually tracked in the very next patch that I want to
post. That patch was posted as part of the v11 series [1], but 
Leon Romanovsky reported a problem with it, and so I'm going to add in
the ability to handle larger "pin" refcounts for the huge page cases.

Meanwhile, I wanted to get these long-simmering simpler preparatory
patches submitted, because it's clear that the API is unaffected by the
huge page refcount fix. (That fix will likely use the second struct page of
the compound page, to count up higher.)


[1] https://lore.kernel.org/r/20191216222537.491123-24-jhubb...@nvidia.com  
[PATCH v11 23/25] mm/gup: track FOLL_PIN pages

thanks,
-- 
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 1/8] dt-bindings: display: panel: Add BOE tv101wum-n16 panel bindings

[Sam Ravnborg]

Hi Jitao.

A few comments that I missed in last round.

Please consider to combine the three panels in one binding.
I realise they are almost identical so no need for three binding files.

On Wed, Jan 15, 2020 at 09:59:51PM +0800, Jitao Shi wrote:
> Add documentation for boe tv101wum-n16 panel.
> 
> Signed-off-by: Jitao Shi 
> Reviewed-by: Sam Ravnborg 
> ---
>  .../display/panel/boe,tv101wum-nl6.yaml   | 74 +++
>  1 file changed, 74 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml 
> b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> new file mode 100644
> index ..d38aee22d406
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: GPL-2.0

Please use (GPL-2.0-only OR BSD-2-Clause) for all new bindings.
(Sorry if this was not part of my previous feedback)

Sam

> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-nl6.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: BOE TV101WUM-Nl6 DSI Display Panel
> +
> +maintainers:
> +  - Thierry Reding 
> +  - Sam Ravnborg 

> +  - Rob Herring 
Rob is not a typical maintainer of panel bindings.
The fallback it Thierry and me.

But if you have agreed this with Rob then all is good.


> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +const: boe,tv101wum-nl6
> +
> +  reg:
> +description: the virtual channel number of a DSI peripheral
> +
> +  enable-gpios:
> +description: a GPIO spec for the enable pin
> +
> +  pp1800-supply:
> +description: core voltage supply
> +
> +  avdd-supply:
> +description: phandle of the regulator that provides positive voltage
> +
> +  avee-supply:
> +description: phandle of the regulator that provides negative voltage
> +
> +  backlight:
> +description: phandle of the backlight device attached to the panel
> +
> +  port: true
> +
> +required:
> + - compatible
> + - reg
> + - enable-gpios
> + - pp1800-supply
> + - avdd-supply
> + - avee-supply

> + - backlight
I would be suprised if backlight is a required node.
You could always tie the input to a fixed voltage and then no backlight
node are required.
Please remove from the required list unless you can convince me
otherwise.

Sam

> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +panel@0 {
> +compatible = "boe,tv101wum-nl6";
> +reg = <0>;
> +enable-gpios = <&pio 45 0>;
> +avdd-supply = <&ppvarn_lcd>;
> +avee-supply = <&ppvarp_lcd>;
> +pp1800-supply = <&pp1800_lcd>;
> +backlight = <&backlight_lcd0>;
> +status = "okay";
> +port {
> +panel_in: endpoint {
> +remote-endpoint = <&dsi_out>;
> +};
> +};
> +};
> +};
> +
> +...
> -- 
> 2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v12 04/22] mm: devmap: refactor 1-based refcounting for ZONE_DEVICE pages

[John Hubbard]

On 1/15/20 7:23 AM, Christoph Hellwig wrote:
...
> 
> I'm really not sold on this scheme.  Note that I think it is
> particularly bad, but it also doesn't seem any better than what
> we had before, and it introduced quite a bit more code.
> 

Hi Christoph,

All by itself, yes. But the very next patch (which needs a little 
rework for other reasons, so not included here) needs to reuse some of 
these functions within __unpin_devmap_managed_user_page():

page_is_devmap_managed()
free_devmap_managed_page()

That patch was posted as part of the v11 series [1], and it did this:

+#ifdef CONFIG_DEV_PAGEMAP_OPS
+static bool __unpin_devmap_managed_user_page(struct page *page)
+{
+   int count;
+
+   if (!page_is_devmap_managed(page))
+   return false;
+
+   count = page_ref_sub_return(page, GUP_PIN_COUNTING_BIAS);
+
+   __update_proc_vmstat(page, NR_FOLL_PIN_RETURNED, 1);
+   /*
+* devmap page refcounts are 1-based, rather than 0-based: if
+* refcount is 1, then the page is free and the refcount is
+* stable because nobody holds a reference on the page.
+*/
+   if (count == 1)
+   free_devmap_managed_page(page);
+   else if (!count)
+   __put_page(page);
+
+   return true;
+}
+#else
+static bool __unpin_devmap_managed_user_page(struct page *page)
+{
+   return false;
+}
+#endif /* CONFIG_DEV_PAGEMAP_OPS */
+
+/**
+ * unpin_user_page() - release a dma-pinned page
+ * @page:pointer to page to be released
+ *
+ * Pages that were pinned via pin_user_pages*() must be released via either
+ * unpin_user_page(), or one of the unpin_user_pages*() routines. This is so
+ * that such pages can be separately tracked and uniquely handled. In
+ * particular, interactions with RDMA and filesystems need special handling.
+ */
+void unpin_user_page(struct page *page)
+{
+   page = compound_head(page);
+
+   /*
+* For devmap managed pages we need to catch refcount transition from
+* GUP_PIN_COUNTING_BIAS to 1, when refcount reach one it means the
+* page is free and we need to inform the device driver through
+* callback. See include/linux/memremap.h and HMM for details.
+*/
+   if (__unpin_devmap_managed_user_page(page))
+   return;
+
+   if (page_ref_sub_and_test(page, GUP_PIN_COUNTING_BIAS))
+   __put_page(page);
+
+   __update_proc_vmstat(page, NR_FOLL_PIN_RETURNED, 1);
+}
+EXPORT_SYMBOL(unpin_user_page);


[1] https://lore.kernel.org/r/20191216222537.491123-24-jhubb...@nvidia.com  
[PATCH v11 23/25] mm/gup: track FOLL_PIN pages

thanks,
-- 
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 2/8] drm/panel: support for BOE tv101wum-nl6 wuxga dsi video mode panel

[Sam Ravnborg]

Hi Jitao.

> +
> +static int boe_panel_add(struct boe_panel *boe)
> +{
> + struct device *dev = &boe->dsi->dev;
> + int err;
> +
> + boe->avdd = devm_regulator_get(dev, "avdd");
> + if (IS_ERR(boe->avdd))
> + return PTR_ERR(boe->avdd);
> +
> + boe->avee = devm_regulator_get(dev, "avee");
> + if (IS_ERR(boe->avee))
> + return PTR_ERR(boe->avee);
> +
> + boe->pp1800 = devm_regulator_get(dev, "pp1800");
> + if (IS_ERR(boe->pp1800))
> + return PTR_ERR(boe->pp1800);
> +
> + boe->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
> + if (IS_ERR(boe->enable_gpio)) {
> + dev_err(dev, "cannot get reset-gpios %ld\n",
> + PTR_ERR(boe->enable_gpio));
> + return PTR_ERR(boe->enable_gpio);
> + }
> +
> + gpiod_set_value(boe->enable_gpio, 0);
> +
> + err = drm_panel_of_backlight(&boe->base);
> + if (err)
> + return err;
>From the descrition of drm_panel_of_backlight():

""
drm_panel_of_backlight() must be called after the call to drm_panel_init().
""

Please do as documented.

Sam

> +
> + drm_panel_init(&boe->base, dev, &boe_panel_funcs,
> +DRM_MODE_CONNECTOR_DSI);
> +
> + boe->base.funcs = &boe_panel_funcs;
> + boe->base.dev = &boe->dsi->dev;
> +
> + return drm_panel_add(&boe->base);
> +}
> +
> +static int boe_panel_probe(struct mipi_dsi_device *dsi)
> +{
> + struct boe_panel *boe;
> + int ret;
> + const struct panel_desc *desc;
> +
> + boe = devm_kzalloc(&dsi->dev, sizeof(*boe), GFP_KERNEL);
> + if (!boe)
> + return -ENOMEM;
> +
> + desc = of_device_get_match_data(&dsi->dev);
> + dsi->lanes = desc->lanes;
> + dsi->format = desc->format;
> + dsi->mode_flags = desc->mode_flags;
> + boe->desc = desc;
> + boe->dsi = dsi;
> + ret = boe_panel_add(boe);
> + if (ret < 0)
> + return ret;
> +
> + mipi_dsi_set_drvdata(dsi, boe);
> +
> + ret = mipi_dsi_attach(dsi);
> + if (ret)
> + drm_panel_remove(&boe->base);
> +
> + return ret;
> +}
> +
> +static void boe_panel_shutdown(struct mipi_dsi_device *dsi)
> +{
> + struct boe_panel *boe = mipi_dsi_get_drvdata(dsi);
> +
> + drm_panel_disable(&boe->base);
> + drm_panel_unprepare(&boe->base);
> +}
> +
> +static int boe_panel_remove(struct mipi_dsi_device *dsi)
> +{
> + struct boe_panel *boe = mipi_dsi_get_drvdata(dsi);
> + int ret;
> +
> + boe_panel_shutdown(dsi);
> +
> + ret = mipi_dsi_detach(dsi);
> + if (ret < 0)
> + dev_err(&dsi->dev, "failed to detach from DSI host: %d\n", ret);
> +
> + if (boe->base.dev)
> + drm_panel_remove(&boe->base);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id boe_of_match[] = {
> + { .compatible = "boe,tv101wum-nl6",
> +   .data = &boe_tv101wum_nl6_desc
> + },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, boe_of_match);
> +
> +static struct mipi_dsi_driver boe_panel_driver = {
> + .driver = {
> + .name = "panel-boe-tv101wum-nl6",
> + .of_match_table = boe_of_match,
> + },
> + .probe = boe_panel_probe,
> + .remove = boe_panel_remove,
> + .shutdown = boe_panel_shutdown,
> +};
> +module_mipi_dsi_driver(boe_panel_driver);
> +
> +MODULE_AUTHOR("Jitao Shi ");
> +MODULE_DESCRIPTION("BOE tv101wum-nl6 1200x1920 video mode panel driver");
> +MODULE_LICENSE("GPL v2");
> -- 
> 2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/5] dt-bindings: display: sitronix, st7735r: Add Okaya RH128128T

[Sam Ravnborg]

On Wed, Jan 15, 2020 at 01:45:45PM +0100, Geert Uytterhoeven wrote:
> Document support for the Okaya RH128128T display, which is a 128x128
> 1.44" TFT display driven by a Sitronix ST7715R TFT Controller/Driver.
> It can be found on e.g. the Renesas YRSK-LCD-PMOD extension board, which
> comes with various Renesas development kits (e.g. Renesas Starter Kit+
> for RZ/A1H[1]).
> 
> ST7715R and ST7735R are very similar.  Their major difference is that
> the former is restricted to displays of up to 132x132 pixels, while the
> latter supports displays up to 132x162 pixels.
> 
> [1] 
> https://renesasrulz.com/the_vault/f/archive-forum/4981/upgrading-to-the-renesas-rz-a1h
> 
> Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Sam Ravnborg 

> ---
> v2:
>   - Rebase on top of DT schema conversion,
>   - Add YRSK-LCD-PMOD reference and links.
> ---
>  .../devicetree/bindings/display/sitronix,st7735r.yaml  | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml 
> b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
> index 21bccc91f74255e1..8892d79e6e100b79 100644
> --- a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
> +++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
> @@ -10,8 +10,8 @@ maintainers:
>- David Lechner 
>  
>  description:
> -  This binding is for display panels using a Sitronix ST7735R controller in
> -  SPI mode.
> +  This binding is for display panels using a Sitronix ST7715R or ST7735R
> +  controller in SPI mode.
>  
>  allOf:
>- $ref: panel/panel-common.yaml#
> @@ -25,6 +25,12 @@ properties:
>- enum:
>- jianda,jd-t18003-t01
>- const: sitronix,st7735r
> +  - description:
> +  Okaya 1.44" 128x128 Color TFT LCD (E.g. Renesas YRSK-LCD-PMOD)
> +items:
> +  - enum:
> +  - okaya,rh128128t
> +  - const: sitronix,st7715r
>  
>spi-max-frequency:
>  maximum: 3200
> -- 
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/5] dt-bindings: display: sitronix,st7735r: Convert to DT schema

[Sam Ravnborg]

Hi Geert.

Thanks for doing the conversion to meta-schema.

On Wed, Jan 15, 2020 at 01:45:44PM +0100, Geert Uytterhoeven wrote:
> Convert the DT binding documentation for Sitronix ST7735R displays to DT
> schema.
> 
> Add a reference to the Adafruit 1.8" LCD while at it.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---

> diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml 
> b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
> new file mode 100644
> index ..21bccc91f74255e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
> @@ -0,0 +1,65 @@
> +# SPDX-License-Identifier: GPL-2.0-only
Use (GPL-2.0-only OR BSD-2-Clause) for new binding files.

> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/sitronix,st7735r.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Sitronix ST7735R Display Panels Device Tree Bindings
> +
> +maintainers:
> +  - David Lechner 
> +
> +description:
> +  This binding is for display panels using a Sitronix ST7735R controller in
> +  SPI mode.
> +
> +allOf:
> +  - $ref: panel/panel-common.yaml#

I am no binding expert so I do not know how to add it.
But the old binding described that this MUST be a child of spi.
This is missing here.

Other panels using spi does not have it - so it is probarly OK.

So with the license fixed:
Reviewed-by: Sam Ravnborg 

> +
> +properties:
> +  compatible:
> +oneOf:
> +  - description:
> +  Adafruit 1.8" 160x128 Color TFT LCD (Product ID 358 or 618)
> +items:
> +  - enum:
> +  - jianda,jd-t18003-t01
> +  - const: sitronix,st7735r
> +
> +  spi-max-frequency:
> +maximum: 3200
> +
> +  dc-gpios:
> +maxItems: 1
> +description: Display data/command selection (D/CX)
> +
> +required:
> +  - compatible
> +  - reg
> +  - dc-gpios
> +  - reset-gpios
> +
> +examples:
> +  - |
> +#include 
> +
> +backlight: backlight {
> +compatible = "gpio-backlight";
> +gpios = <&gpio 44 GPIO_ACTIVE_HIGH>;
> +};
> +
> +spi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +display@0{
> +compatible = "jianda,jd-t18003-t01", "sitronix,st7735r";
> +reg = <0>;
> +spi-max-frequency = <3200>;
> +dc-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
> +reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
> +rotation = <270>;
> +};
> +};
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea8262509bdd21ac..3007f83bd504194a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5382,7 +5382,7 @@ M:  David Lechner 
>  T:   git git://anongit.freedesktop.org/drm/drm-misc
>  S:   Maintained
>  F:   drivers/gpu/drm/tiny/st7735r.c
> -F:   Documentation/devicetree/bindings/display/sitronix,st7735r.txt
> +F:   Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
>  
>  DRM DRIVER FOR SONY ACX424AKP PANELS
>  M:   Linus Walleij 
> -- 
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Inject a cond_resched() into long drm_clflush_sg()

[Chris Wilson]

Since we may try and flush the cachelines associated with large buffers
(an 8K framebuffer is about 128MiB, even before we try HDR), this leads
to unacceptably long latencies (when using a voluntary CONFIG_PREEMPT).
If we call cond_resched() between each sg chunk, that it about every 128
pages, we have a natural break point in which to check if the process
needs to be rescheduled. Naturally, this means that drm_clflush_sg() can
only be called from process context -- which is true at the moment. The
other clflush routines remain usable from atomic context.

Even though flushing large objects takes a demonstrable amount to time
to flush all the cachelines, clflush is still preferred over a
system-wide wbinvd as the latter has unpredictable latencies affecting
the whole system not just the local task.

Reported-by: David Laight 
Signed-off-by: Chris Wilson 
Cc: David Laight 
---
 drivers/gpu/drm/drm_cache.c | 49 ++---
 1 file changed, 45 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 03e01b000f7a..fbd2bb644544 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -112,23 +112,64 @@ drm_clflush_pages(struct page *pages[], unsigned long 
num_pages)
 }
 EXPORT_SYMBOL(drm_clflush_pages);
 
+static __always_inline struct sgt_iter {
+   struct scatterlist *sgp;
+   unsigned long pfn;
+   unsigned int curr;
+   unsigned int max;
+} __sgt_iter(struct scatterlist *sgl) {
+   struct sgt_iter s = { .sgp = sgl };
+
+   if (s.sgp) {
+   s.max = s.curr = s.sgp->offset;
+   s.max += s.sgp->length;
+   s.pfn = page_to_pfn(sg_page(s.sgp));
+   }
+
+   return s;
+}
+
+static inline struct scatterlist *__sg_next_resched(struct scatterlist *sg)
+{
+   if (sg_is_last(sg))
+   return NULL;
+
+   ++sg;
+   if (unlikely(sg_is_chain(sg))) {
+   sg = sg_chain_ptr(sg);
+   cond_resched();
+   }
+   return sg;
+}
+
+#define for_each_sgt_page(__pp, __iter, __sgt) \
+   for ((__iter) = __sgt_iter((__sgt)->sgl);   \
+((__pp) = (__iter).pfn == 0 ? NULL :   \
+ pfn_to_page((__iter).pfn + ((__iter).curr >> PAGE_SHIFT))); \
+(((__iter).curr += PAGE_SIZE) >= (__iter).max) ?   \
+(__iter) = __sgt_iter(__sg_next_resched((__iter).sgp)), 0 : 0)
+
 /**
  * drm_clflush_sg - Flush dcache lines pointing to a scather-gather.
  * @st: struct sg_table.
  *
  * Flush every data cache line entry that points to an address in the
- * sg.
+ * sg. This may schedule between scatterlist chunks, in order to keep
+ * the system preemption-latency down for large buffers.
  */
 void
 drm_clflush_sg(struct sg_table *st)
 {
+   might_sleep();
+
 #if defined(CONFIG_X86)
if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
-   struct sg_page_iter sg_iter;
+   struct sgt_iter sg_iter;
+   struct page *page;
 
mb(); /*CLFLUSH is ordered only by using memory barriers*/
-   for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
-   drm_clflush_page(sg_page_iter_page(&sg_iter));
+   for_each_sgt_page(page, sg_iter, st)
+   drm_clflush_page(page);
mb(); /*Make sure that all cache line entry is flushed*/
 
return;
-- 
2.25.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/trace: Buffer DRM logs in a ringbuffer accessible via debugfs

[Sean Paul]

On Wed, Jan 15, 2020 at 05:38:13PM +, Chris Wilson wrote:
> Quoting Sean Paul (2020-01-15 14:21:18)
> > On Wed, Jan 15, 2020 at 02:01:19PM +, Chris Wilson wrote:
> > > Quoting Sean Paul (2020-01-15 13:41:58)
> > > > On Wed, Jan 15, 2020 at 10:36:36AM +, Chris Wilson wrote:
> > > > > Quoting Sean Paul (2020-01-14 17:21:43)
> > > > > > From: Sean Paul 
> > > > > > 
> > > > > > This patch uses a ring_buffer to keep a "flight recorder" (name 
> > > > > > credit Weston)
> > > > > > of DRM logs for a specified set of debug categories. The user 
> > > > > > writes a
> > > > > > bitmask of debug categories to the "trace_mask" node and can read 
> > > > > > log
> > > > > > messages from the "trace" node.
> > > > > > 
> > > > > > These nodes currently exist in debugfs under the dri directory. I
> > > > > > intended on exposing all of this through tracefs originally, but the
> > > > > > tracefs entry points are not exposed, so there's no way to create
> > > > > > tracefs files from drivers at the moment. I think it would be a
> > > > > > worthwhile endeavour, but one requiring more time and conversation 
> > > > > > to
> > > > > > ensure the drm traces fit somewhere sensible.
> > > > > 
> > > > > Fwiw, I have a need for client orientated debug message store, with
> > > > > the primary purpose of figuring out -EINVAL. We need per-client so we 
> > > > > can
> > > > > put sensitive information about the potentially buggy client 
> > > > > behaviour,
> > > > > and of course it needs to be accessible by the non-privileged client.
> > > > > 
> > > > > On the execution side, it's easy to keep track of the client so we 
> > > > > could
> > > > > trace execution flow per client, within reason. And we could do
> > > > > similarly for kms clients.
> > > > 
> > > > Could you build such a thing with drm_trace underpinning it, just put 
> > > > the
> > > > pertinent information in the message?
> > > 
> > > Not as is. The global has to go, and there's no use for debugfs. So we
> > > are just left with a sprintf() around a ring_buffer. I am left in the
> > > same position as just wanting to generalise tracek to take the ringbuffer
> > > as a parameter.
> > > 
> > 
> > Ah, I think I see what you're getting at now. I think it would be 
> > reasonable to
> > split out a drm_trace_buffer from the current code for this purpose. We 
> > could
> > have an interface like:
> > 
> > struct drm_trace_buffer *drm_trace_buffer_init(unsigned int num_pages);
> > int drm_trace_buffer_resize(struct drm_trace_buffer *buf, unsigned int 
> > num_pages);
> > int drm_trace_buffer_printf(struct drm_trace_buffer *buf, const char 
> > *format, ...);
> > int drm_trace_buffer_output(struct seq_file *seq);
> > void drm_trace_buffer_cleanup(struct drm_trace_buffer *buf);
> > 
> > Then to Joonas' point, we could have drm_trace_log which uses this 
> > interface to
> > mirror the logs with a debugfs interface.
> > 
> > Would that work for your purpose?
> 
> The seq_file doesn't marry with the anticipated uAPI, I'll probably need
> a raw file_ops (thinking along the lines of return an fd to userspace,
> that is read ala /dev/kmsg).

Agree, that should have been 

struct file_operations *drm_trace_buffer_file_ops(struct drm_trace_buffer *buf);

or something like that..

> 
> I would be tempted to drop the drm_ and put it straight in lib/

I think if we wanted to share this more broadly, we'd probably look at adding
it in kernel/trace/ and enabling subsystems to add their own traces to tracefs.

Sean


> -Chris

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/trace: Buffer DRM logs in a ringbuffer accessible via debugfs

[Chris Wilson]

Quoting Sean Paul (2020-01-15 14:21:18)
> On Wed, Jan 15, 2020 at 02:01:19PM +, Chris Wilson wrote:
> > Quoting Sean Paul (2020-01-15 13:41:58)
> > > On Wed, Jan 15, 2020 at 10:36:36AM +, Chris Wilson wrote:
> > > > Quoting Sean Paul (2020-01-14 17:21:43)
> > > > > From: Sean Paul 
> > > > > 
> > > > > This patch uses a ring_buffer to keep a "flight recorder" (name 
> > > > > credit Weston)
> > > > > of DRM logs for a specified set of debug categories. The user writes a
> > > > > bitmask of debug categories to the "trace_mask" node and can read log
> > > > > messages from the "trace" node.
> > > > > 
> > > > > These nodes currently exist in debugfs under the dri directory. I
> > > > > intended on exposing all of this through tracefs originally, but the
> > > > > tracefs entry points are not exposed, so there's no way to create
> > > > > tracefs files from drivers at the moment. I think it would be a
> > > > > worthwhile endeavour, but one requiring more time and conversation to
> > > > > ensure the drm traces fit somewhere sensible.
> > > > 
> > > > Fwiw, I have a need for client orientated debug message store, with
> > > > the primary purpose of figuring out -EINVAL. We need per-client so we 
> > > > can
> > > > put sensitive information about the potentially buggy client behaviour,
> > > > and of course it needs to be accessible by the non-privileged client.
> > > > 
> > > > On the execution side, it's easy to keep track of the client so we could
> > > > trace execution flow per client, within reason. And we could do
> > > > similarly for kms clients.
> > > 
> > > Could you build such a thing with drm_trace underpinning it, just put the
> > > pertinent information in the message?
> > 
> > Not as is. The global has to go, and there's no use for debugfs. So we
> > are just left with a sprintf() around a ring_buffer. I am left in the
> > same position as just wanting to generalise tracek to take the ringbuffer
> > as a parameter.
> > 
> 
> Ah, I think I see what you're getting at now. I think it would be reasonable 
> to
> split out a drm_trace_buffer from the current code for this purpose. We could
> have an interface like:
> 
> struct drm_trace_buffer *drm_trace_buffer_init(unsigned int num_pages);
> int drm_trace_buffer_resize(struct drm_trace_buffer *buf, unsigned int 
> num_pages);
> int drm_trace_buffer_printf(struct drm_trace_buffer *buf, const char *format, 
> ...);
> int drm_trace_buffer_output(struct seq_file *seq);
> void drm_trace_buffer_cleanup(struct drm_trace_buffer *buf);
> 
> Then to Joonas' point, we could have drm_trace_log which uses this interface 
> to
> mirror the logs with a debugfs interface.
> 
> Would that work for your purpose?

The seq_file doesn't marry with the anticipated uAPI, I'll probably need
a raw file_ops (thinking along the lines of return an fd to userspace,
that is read ala /dev/kmsg).

I would be tempted to drop the drm_ and put it straight in lib/
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 4/5] drm/tidss: New driver for TI Keystone platform Display SubSystem

[Sam Ravnborg]

Hi Jyri.

> Well, I'll bite the bullet then, and start mangling the code to the
> "strict" format.

While touching the code please consider moving all logging
over to the new drm_{err,warn,info,dbg} functions.
They give the nice "[drm]" marker.
And they are a tad shorter as you do not have to dereference ddev->dev
everywhere.
And you then also gain support for controlling logging using
drm.debug=0, os sysfs too.

See drm_print.h in latest drm_misc_next

With or without this change you can add my:
Acked-by: Sam Ravnborg 

Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] dmaengine: sun4i: Add support for cyclic requests with dedicated DMA

[Maxime Ripard]

On Wed, Jan 15, 2020 at 06:01:37PM +0530, Vinod Koul wrote:
> On 10-01-20, 16:11, Stefan Mavrodiev wrote:
> > Currently the cyclic transfers can be used only with normal DMAs. They
> > can be used by pcm_dmaengine module, which is required for implementing
> > sound with sun4i-hdmi encoder. This is so because the controller can
> > accept audio only from a dedicated DMA.
> >
> > This patch enables them, following the existing style for the
> > scatter/gather type transfers.
>
> I presume you want this to go with drm tree (if not let me know) so:
>
> Acked-by: Vinod Koul 

There's no need for it to go through DRM, it can go through your tree :)

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/23] drm/amdgpu: Convert to struct drm_crtc_helper_funcs.get_scanout_position()

[Alex Deucher]

On Wed, Jan 15, 2020 at 4:41 AM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 13.01.20 um 19:52 schrieb Alex Deucher:
> > On Fri, Jan 10, 2020 at 4:21 AM Thomas Zimmermann  
> > wrote:
> >>
> >> The callback struct drm_driver.get_scanout_position() is deprecated in
> >> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> >> amdgpu over.
> >>
> >
> > I would prefer to just change the signature of
> > amdgpu_display_get_crtc_scanoutpos() to match the new API rather than
> > wrapping it again.
>
> While trying to adapt the siganture, I found that
> amdgpu_display_get_crtc_scanoutpos() requires a flags argument that is
> not mappable to the callback API. That wrapper function is necessary.
>

No worries.  We can clean them up later.  Wrapping is fine.

Alex

> Best regards
> Thomas
>
> >
> > Alex
> >
> >> Signed-off-by: Thomas Zimmermann 
> >> ---
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 12 
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 11 ---
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  5 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  1 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  1 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  1 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  1 +
> >>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  1 +
> >>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 ++-
> >>  9 files changed, 24 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> >> index 4e699071d144..a1e769d4417d 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> >> @@ -914,3 +914,15 @@ int amdgpu_display_crtc_idx_to_irq_type(struct 
> >> amdgpu_device *adev, int crtc)
> >> return AMDGPU_CRTC_IRQ_NONE;
> >> }
> >>  }
> >> +
> >> +bool amdgpu_crtc_get_scanout_position(struct drm_crtc *crtc,
> >> +   bool in_vblank_irq, int *vpos,
> >> +   int *hpos, ktime_t *stime, ktime_t *etime,
> >> +   const struct drm_display_mode *mode)
> >> +{
> >> +   struct drm_device *dev = crtc->dev;
> >> +   unsigned int pipe = crtc->index;
> >> +
> >> +   return amdgpu_display_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> >> + stime, etime, mode);
> >> +}
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> index 3f6f14ce1511..0749285dd1c7 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> @@ -1367,16 +1367,6 @@ int amdgpu_file_to_fpriv(struct file *filp, struct 
> >> amdgpu_fpriv **fpriv)
> >> return 0;
> >>  }
> >>
> >> -static bool
> >> -amdgpu_get_crtc_scanout_position(struct drm_device *dev, unsigned int 
> >> pipe,
> >> -bool in_vblank_irq, int *vpos, int *hpos,
> >> -ktime_t *stime, ktime_t *etime,
> >> -const struct drm_display_mode *mode)
> >> -{
> >> -   return amdgpu_display_get_crtc_scanoutpos(dev, pipe, 0, vpos, hpos,
> >> - stime, etime, mode);
> >> -}
> >> -
> >>  static struct drm_driver kms_driver = {
> >> .driver_features =
> >> DRIVER_USE_AGP | DRIVER_ATOMIC |
> >> @@ -1391,7 +1381,6 @@ static struct drm_driver kms_driver = {
> >> .enable_vblank = amdgpu_enable_vblank_kms,
> >> .disable_vblank = amdgpu_disable_vblank_kms,
> >> .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> >> -   .get_scanout_position = amdgpu_get_crtc_scanout_position,
> >> .irq_handler = amdgpu_irq_handler,
> >> .ioctls = amdgpu_ioctls_kms,
> >> .gem_free_object_unlocked = amdgpu_gem_object_free,
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> >> index eb9975f4decb..37ba07e2feb5 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> >> @@ -612,6 +612,11 @@ void amdgpu_panel_mode_fixup(struct drm_encoder 
> >> *encoder,
> >>  struct drm_display_mode *adjusted_mode);
> >>  int amdgpu_display_crtc_idx_to_irq_type(struct amdgpu_device *adev, int 
> >> crtc);
> >>
> >> +bool amdgpu_crtc_get_scanout_position(struct drm_crtc *crtc,
> >> +   bool in_vblank_irq, int *vpos,
> >> +   int *hpos, ktime_t *stime, ktime_t *etime,
> >> +   const struct drm_display_mode *mode);
> >> +
> >>  /* fbdev layer */
> >>  int amdgpu_fbdev_init(struct amdgpu_device *adev);
> >>  void amdgpu_fbdev_fini(struct amdgpu_device *adev);
> >> diff --git a/drivers/

Re: [PATCH] video: fbdev: nvidia: clean up indentation issues and comment block

[Bartlomiej Zolnierkiewicz]

On 1/13/20 3:46 PM, Colin King wrote:
> From: Colin Ian King 
> 
> There is a hunk of code that is incorrectly indented, clean up the
> indentation and a comment block. Also remove block braces around a
> one line statement on an if condition and add missing spaces after
> if keywords.
> 
> Signed-off-by: Colin Ian King 

Patch queued for v5.6, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/video/fbdev/nvidia/nvidia.c | 41 ++---
>  1 file changed, 20 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/video/fbdev/nvidia/nvidia.c 
> b/drivers/video/fbdev/nvidia/nvidia.c
> index c583c018304d..c24de9107958 100644
> --- a/drivers/video/fbdev/nvidia/nvidia.c
> +++ b/drivers/video/fbdev/nvidia/nvidia.c
> @@ -168,27 +168,26 @@ static int nvidia_panel_tweak(struct nvidia_par *par,
>  {
>   int tweak = 0;
>  
> -   if (par->paneltweak) {
> -tweak = par->paneltweak;
> -   } else {
> -/* begin flat panel hacks */
> -/* This is unfortunate, but some chips need this register
> -   tweaked or else you get artifacts where adjacent pixels are
> -   swapped.  There are no hard rules for what to set here so all
> -   we can do is experiment and apply hacks. */
> -
> -if(((par->Chipset & 0x) == 0x0328) && (state->bpp == 32)) {
> -/* At least one NV34 laptop needs this workaround. */
> -tweak = -1;
> -}
> -
> -if((par->Chipset & 0xfff0) == 0x0310) {
> -tweak = 1;
> -}
> -/* end flat panel hacks */
> -   }
> -
> -   return tweak;
> + if (par->paneltweak) {
> + tweak = par->paneltweak;
> + } else {
> + /* Begin flat panel hacks.
> +  * This is unfortunate, but some chips need this register
> +  * tweaked or else you get artifacts where adjacent pixels are
> +  * swapped.  There are no hard rules for what to set here so all
> +  * we can do is experiment and apply hacks.
> +  */
> + if (((par->Chipset & 0x) == 0x0328) && (state->bpp == 32)) {
> + /* At least one NV34 laptop needs this workaround. */
> + tweak = -1;
> + }
> +
> + if ((par->Chipset & 0xfff0) == 0x0310)
> + tweak = 1;
> + /* end flat panel hacks */
> + }
> +
> + return tweak;
>  }
>  
>  static void nvidia_screen_off(struct nvidia_par *par, int on)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fbdev: remove object duplication in Makefile

[Bartlomiej Zolnierkiewicz]

On 1/6/20 9:13 AM, Masahiro Yamada wrote:
> The objects in $(fb-objs) $(fb-y) $(fb-m) are linked to fb.ko .
> 
> This line adds $(fb-y) to fb-objs, so the objects from $(fb-y) are
> listed twice as the dependency of the module.
> 
> It works because Kbuild trims the duplicated objects from linking,
> but there is no good reason to have this line.
> 
> Signed-off-by: Masahiro Yamada 

Patch queued for v5.6, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
> 
>  drivers/video/fbdev/core/Makefile | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/core/Makefile 
> b/drivers/video/fbdev/core/Makefile
> index 37710316a680..26cbc965497c 100644
> --- a/drivers/video/fbdev/core/Makefile
> +++ b/drivers/video/fbdev/core/Makefile
> @@ -16,7 +16,6 @@ fb-y  += fbcon_rotate.o 
> fbcon_cw.o fbcon_ud.o \
>fbcon_ccw.o
>  endif
>  endif
> -fb-objs   := $(fb-y)
>  
>  obj-$(CONFIG_FB_CFB_FILLRECT)  += cfbfillrect.o
>  obj-$(CONFIG_FB_CFB_COPYAREA)  += cfbcopyarea.o
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 15/20] video: exynos: Rename Exynos to lowercase

[Bartlomiej Zolnierkiewicz]

On 1/4/20 4:21 PM, Krzysztof Kozlowski wrote:
> Fix up inconsistent usage of upper and lowercase letters in "Exynos"
> name.
> 
> "EXYNOS" is not an abbreviation but a regular trademarked name.
> Therefore it should be written with lowercase letters starting with
> capital letter.
> 
> The lowercase "Exynos" name is promoted by its manufacturer Samsung
> Electronics Co., Ltd., in advertisement materials and on website.
> 
> Signed-off-by: Krzysztof Kozlowski 

Patch queued for v5.6, thanks.
 
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  include/video/samsung_fimd.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index b6571c3cfa31..c4a93ce1de48 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -10,7 +10,7 @@
>   *
>   * This is the register set for the fimd and new style framebuffer interface
>   * found from the S3C2443 onwards into the S3C2416, S3C2450, the
> - * S3C64XX series such as the S3C6400 and S3C6410, and EXYNOS series.
> + * S3C64XX series such as the S3C6400 and S3C6410, and Exynos series.
>  */
>  
>  /* VIDCON0 */
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/10] video: fbdev: use resource_size

[Bartlomiej Zolnierkiewicz]

On 1/1/20 6:49 PM, Julia Lawall wrote:
> Use resource_size rather than a verbose computation on
> the end and start fields.
> 
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
> 
> 
> @@ struct resource ptr; @@
> - (ptr.end - ptr.start + 1)
> + resource_size(&ptr)
> 
> 
> Signed-off-by: Julia Lawall 

Patch queued for v5.6 (with patch summary modified slightly to
reflect that this a change for cg14fb fbdev driver), thanks.
 
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/video/fbdev/cg14.c |3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/video/fbdev/cg14.c b/drivers/video/fbdev/cg14.c
> index a620b51cf7d0..6a745eb46ca1 100644
> --- a/drivers/video/fbdev/cg14.c
> +++ b/drivers/video/fbdev/cg14.c
> @@ -509,8 +509,7 @@ static int cg14_probe(struct platform_device *op)
>   if (!par->regs || !par->clut || !par->cursor || !info->screen_base)
>   goto out_unmap_regs;
>  
> - is_8mb = (((op->resource[1].end - op->resource[1].start) + 1) ==
> -   (8 * 1024 * 1024));
> + is_8mb = (resource_size(&op->resource[1]) == (8 * 1024 * 1024));
>  
>   BUILD_BUG_ON(sizeof(par->mmap_map) != sizeof(__cg14_mmap_map));
>   
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/10] fbdev: s1d13xxxfb: use resource_size

[Bartlomiej Zolnierkiewicz]

On 1/1/20 6:49 PM, Julia Lawall wrote:
> Use resource_size rather than a verbose computation on
> the end and start fields.
> 
> The semantic patch that makes these changes is as follows:
> (http://coccinelle.lip6.fr/)
> 
> 
> @@ struct resource ptr; @@
> - (ptr.end - ptr.start + 1)
> + resource_size(&ptr)
> 
> 
> Signed-off-by: Julia Lawall 

Patch queued for v5.6, thanks.
 
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/video/fbdev/s1d13xxxfb.c |   16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/video/fbdev/s1d13xxxfb.c 
> b/drivers/video/fbdev/s1d13xxxfb.c
> index 8048499e398d..eaea8c373753 100644
> --- a/drivers/video/fbdev/s1d13xxxfb.c
> +++ b/drivers/video/fbdev/s1d13xxxfb.c
> @@ -746,9 +746,9 @@ s1d13xxxfb_remove(struct platform_device *pdev)
>   }
>  
>   release_mem_region(pdev->resource[0].start,
> - pdev->resource[0].end - pdev->resource[0].start +1);
> +resource_size(&pdev->resource[0]));
>   release_mem_region(pdev->resource[1].start,
> - pdev->resource[1].end - pdev->resource[1].start +1);
> +resource_size(&pdev->resource[1]));
>   return 0;
>  }
>  
> @@ -788,14 +788,14 @@ static int s1d13xxxfb_probe(struct platform_device 
> *pdev)
>   }
>  
>   if (!request_mem_region(pdev->resource[0].start,
> - pdev->resource[0].end - pdev->resource[0].start +1, "s1d13xxxfb 
> mem")) {
> + resource_size(&pdev->resource[0]), "s1d13xxxfb mem")) {
>   dev_dbg(&pdev->dev, "request_mem_region failed\n");
>   ret = -EBUSY;
>   goto bail;
>   }
>  
>   if (!request_mem_region(pdev->resource[1].start,
> - pdev->resource[1].end - pdev->resource[1].start +1, "s1d13xxxfb 
> regs")) {
> + resource_size(&pdev->resource[1]), "s1d13xxxfb regs")) {
>   dev_dbg(&pdev->dev, "request_mem_region failed\n");
>   ret = -EBUSY;
>   goto bail;
> @@ -810,7 +810,7 @@ static int s1d13xxxfb_probe(struct platform_device *pdev)
>   platform_set_drvdata(pdev, info);
>   default_par = info->par;
>   default_par->regs = ioremap(pdev->resource[1].start,
> - pdev->resource[1].end - pdev->resource[1].start +1);
> + resource_size(&pdev->resource[1]));
>   if (!default_par->regs) {
>   printk(KERN_ERR PFX "unable to map registers\n");
>   ret = -ENOMEM;
> @@ -819,7 +819,7 @@ static int s1d13xxxfb_probe(struct platform_device *pdev)
>   info->pseudo_palette = default_par->pseudo_palette;
>  
>   info->screen_base = ioremap(pdev->resource[0].start,
> - pdev->resource[0].end - pdev->resource[0].start +1);
> + resource_size(&pdev->resource[0]));
>  
>   if (!info->screen_base) {
>   printk(KERN_ERR PFX "unable to map framebuffer\n");
> @@ -857,9 +857,9 @@ static int s1d13xxxfb_probe(struct platform_device *pdev)
>  
>   info->fix = s1d13xxxfb_fix;
>   info->fix.mmio_start = pdev->resource[1].start;
> - info->fix.mmio_len = pdev->resource[1].end - pdev->resource[1].start + 
> 1;
> + info->fix.mmio_len = resource_size(&pdev->resource[1]);
>   info->fix.smem_start = pdev->resource[0].start;
> - info->fix.smem_len = pdev->resource[0].end - pdev->resource[0].start + 
> 1;
> + info->fix.smem_len = resource_size(&pdev->resource[0]);
>  
>   printk(KERN_INFO PFX "regs mapped at 0x%p, fb %d KiB mapped at 0x%p\n",
>  default_par->regs, info->fix.smem_len / 1024, info->screen_base);
> 
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/16] video: sa1100fb: constify copied structure

[Bartlomiej Zolnierkiewicz]

On 1/1/20 8:43 AM, Julia Lawall wrote:
> The monspecs structure is only copied into another structure,
> so make it const.
> 
> The opportunity for this change was found using Coccinelle.
> 
> Signed-off-by: Julia Lawall 

Patch queued for v5.6, thanks.
 
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/video/fbdev/sa1100fb.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c
> index 4680cc3efb81..c77b43dbc256 100644
> --- a/drivers/video/fbdev/sa1100fb.c
> +++ b/drivers/video/fbdev/sa1100fb.c
> @@ -1053,7 +1053,7 @@ static int sa1100fb_map_video_memory(struct 
> sa1100fb_info *fbi)
>  }
>  
>  /* Fake monspecs to fill in fbinfo structure */
> -static struct fb_monspecs monspecs = {
> +static const struct fb_monspecs monspecs = {
>   .hfmin  = 3,
>   .hfmax  = 7,
>   .vfmin  = 50,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fbmem: Adjust indentation in fb_prepare_logo and fb_blank

[Bartlomiej Zolnierkiewicz]

On 12/20/19 7:09 PM, Nick Desaulniers wrote:
> On Tue, Dec 17, 2019 at 7:00 PM Nathan Chancellor
>  wrote:
>>
>> Clang warns:
>>
>> ../drivers/video/fbdev/core/fbmem.c:665:3: warning: misleading
>> indentation; statement is not part of the previous 'else'
>> [-Wmisleading-indentation]
>> if (fb_logo.depth > 4 && depth > 4) {
>> ^
>> ../drivers/video/fbdev/core/fbmem.c:661:2: note: previous statement is
>> here
>> else
>> ^
>> ../drivers/video/fbdev/core/fbmem.c:1075:3: warning: misleading
>> indentation; statement is not part of the previous 'if'
>> [-Wmisleading-indentation]
>> return ret;
>> ^
>> ../drivers/video/fbdev/core/fbmem.c:1072:2: note: previous statement is
>> here
>> if (!ret)
>> ^
>> 2 warnings generated.
>>
>> This warning occurs because there are spaces before the tabs on these
>> lines. Normalize the indentation in these functions so that it is
>> consistent with the Linux kernel coding style and clang no longer warns.
>>
>> Fixes: 1692b37c99d5 ("fbdev: Fix logo if logo depth is less than framebuffer 
>> depth")
>> Link: 
>> https://protect2.fireeye.com/url?k=6092966e-3d083fcd-60931d21-002590f5b904-0ba0d782b5b6272b&u=https://github.com/ClangBuiltLinux/linux/issues/825
>> Signed-off-by: Nathan Chancellor 
> 
> Thanks for the patch!
> Reviewed-by: Nick Desaulniers 

Patch queued for v5.6, thanks.
 
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

>> ---
>>  drivers/video/fbdev/core/fbmem.c | 36 
>>  1 file changed, 18 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/core/fbmem.c 
>> b/drivers/video/fbdev/core/fbmem.c
>> index 0662b61fdb50..bf63cc0e6b65 100644
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -662,20 +662,20 @@ int fb_prepare_logo(struct fb_info *info, int rotate)
>> fb_logo.depth = 1;
>>
>>
>> -   if (fb_logo.depth > 4 && depth > 4) {
>> -   switch (info->fix.visual) {
>> -   case FB_VISUAL_TRUECOLOR:
>> -   fb_logo.needs_truepalette = 1;
>> -   break;
>> -   case FB_VISUAL_DIRECTCOLOR:
>> -   fb_logo.needs_directpalette = 1;
>> -   fb_logo.needs_cmapreset = 1;
>> -   break;
>> -   case FB_VISUAL_PSEUDOCOLOR:
>> -   fb_logo.needs_cmapreset = 1;
>> -   break;
>> -   }
>> -   }
>> +   if (fb_logo.depth > 4 && depth > 4) {
>> +   switch (info->fix.visual) {
>> +   case FB_VISUAL_TRUECOLOR:
>> +   fb_logo.needs_truepalette = 1;
>> +   break;
>> +   case FB_VISUAL_DIRECTCOLOR:
>> +   fb_logo.needs_directpalette = 1;
>> +   fb_logo.needs_cmapreset = 1;
>> +   break;
>> +   case FB_VISUAL_PSEUDOCOLOR:
>> +   fb_logo.needs_cmapreset = 1;
>> +   break;
>> +   }
>> +   }
>>
>> height = fb_logo.logo->height;
>> if (fb_center_logo)
>> @@ -1060,19 +1060,19 @@ fb_blank(struct fb_info *info, int blank)
>> struct fb_event event;
>> int ret = -EINVAL;
>>
>> -   if (blank > FB_BLANK_POWERDOWN)
>> -   blank = FB_BLANK_POWERDOWN;
>> +   if (blank > FB_BLANK_POWERDOWN)
>> +   blank = FB_BLANK_POWERDOWN;
>>
>> event.info = info;
>> event.data = ␣
>>
>> if (info->fbops->fb_blank)
>> -   ret = info->fbops->fb_blank(blank, info);
>> +   ret = info->fbops->fb_blank(blank, info);
>>
>> if (!ret)
>> fb_notifier_call_chain(FB_EVENT_BLANK, &event);
>>
>> -   return ret;
>> +   return ret;
>>  }
>>  EXPORT_SYMBOL(fb_blank);
>>
>> --
>> 2.24.1
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Clang Built Linux" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clang-built-linux+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://protect2.fireeye.com/url?k=d7e70d81-8a7da422-d7e686ce-002590f5b904-15caafb1f7cc41ea&u=https://groups.google.com/d/msgid/clang-built-linux/20191218030025.10064-1-natechancellor%40gmail.com.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fbcon: Adjust indentation in set_con2fb_map

[Bartlomiej Zolnierkiewicz]

On 12/20/19 7:07 PM, Nick Desaulniers wrote:
> On Tue, Dec 17, 2019 at 6:53 PM Nathan Chancellor
>  wrote:
>>
>> Clang warns:
>>
>> ../drivers/video/fbdev/core/fbcon.c:915:3: warning: misleading
>> indentation; statement is not part of the previous 'if'
>> [-Wmisleading-indentation]
>> return err;
>> ^
>> ../drivers/video/fbdev/core/fbcon.c:912:2: note: previous statement is
>> here
>> if (!search_fb_in_map(info_idx))
>> ^
>> 1 warning generated.
>>
>> This warning occurs because there is a space before the tab on this
>> line. This happens on several lines in this function; normalize them
>> so that the indentation is consistent with the Linux kernel coding
>> style and clang no longer warns.
>>
>> This warning was introduced before the beginning of git history so no
>> fixes tab.
>>
>> https://github.com/ClangBuiltLinux/linux/issues/824
>> Signed-off-by: Nathan Chancellor 
> 
> Thanks for the patch!
> Reviewed-by: Nick Desaulniers 

Patch queued for v5.6, thanks.
 
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

>> ---
>>  drivers/video/fbdev/core/fbcon.c | 27 +--
>>  1 file changed, 13 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/core/fbcon.c 
>> b/drivers/video/fbdev/core/fbcon.c
>> index c9235a2f42f8..9d2c43e345a4 100644
>> --- a/drivers/video/fbdev/core/fbcon.c
>> +++ b/drivers/video/fbdev/core/fbcon.c
>> @@ -866,7 +866,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
>> int oldidx = con2fb_map[unit];
>> struct fb_info *info = registered_fb[newidx];
>> struct fb_info *oldinfo = NULL;
>> -   int found, err = 0;
>> +   int found, err = 0;
>>
>> WARN_CONSOLE_UNLOCKED();
>>
>> @@ -888,31 +888,30 @@ static int set_con2fb_map(int unit, int newidx, int 
>> user)
>>
>> con2fb_map[unit] = newidx;
>> if (!err && !found)
>> -   err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
>> -
>> +   err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
>>
>> /*
>>  * If old fb is not mapped to any of the consoles,
>>  * fbcon should release it.
>>  */
>> -   if (!err && oldinfo && !search_fb_in_map(oldidx))
>> -   err = con2fb_release_oldinfo(vc, oldinfo, info, unit, oldidx,
>> -found);
>> +   if (!err && oldinfo && !search_fb_in_map(oldidx))
>> +   err = con2fb_release_oldinfo(vc, oldinfo, info, unit, oldidx,
>> +found);
>>
>> -   if (!err) {
>> -   int show_logo = (fg_console == 0 && !user &&
>> -logo_shown != FBCON_LOGO_DONTSHOW);
>> +   if (!err) {
>> +   int show_logo = (fg_console == 0 && !user &&
>> +logo_shown != FBCON_LOGO_DONTSHOW);
>>
>> -   if (!found)
>> -   fbcon_add_cursor_timer(info);
>> -   con2fb_map_boot[unit] = newidx;
>> -   con2fb_init_display(vc, info, unit, show_logo);
>> +   if (!found)
>> +   fbcon_add_cursor_timer(info);
>> +   con2fb_map_boot[unit] = newidx;
>> +   con2fb_init_display(vc, info, unit, show_logo);
>> }
>>
>> if (!search_fb_in_map(info_idx))
>> info_idx = newidx;
>>
>> -   return err;
>> +   return err;
>>  }
>>
>>  /*
>> --
>> 2.24.1
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Clang Built Linux" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clang-built-linux+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://protect2.fireeye.com/url?k=bb9fa192-e64db737-bb9e2add-0cc47a31bee8-3ce98548f51cd7a2&u=https://groups.google.com/d/msgid/clang-built-linux/20191218025337.35044-1-natechancellor%40gmail.com.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] pxa168fb: fix release function mismatch in probe failure

[Bartlomiej Zolnierkiewicz]

On 12/5/19 5:06 PM, Chuhong Yuan wrote:
> The driver uses kfree() to release the resource allocated by
> framebuffer_alloc(), which does not match.
> Use framebuffer_release() instead to fix it.

For pxa168fb driver framebuffer_release() does only kfree() so
there is no real breakage currently. Lets fix it anyway so it
won't break in the future.

> Fixes: 638772c7553f ("fb: add support of LCD display controller on pxa168/910 
> (base layer)")
> Signed-off-by: Chuhong Yuan 

Patch queued for v5.6, thanks.
 
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/video/fbdev/pxa168fb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/pxa168fb.c b/drivers/video/fbdev/pxa168fb.c
> index 1410f476e135..b9435133b6f3 100644
> --- a/drivers/video/fbdev/pxa168fb.c
> +++ b/drivers/video/fbdev/pxa168fb.c
> @@ -769,7 +769,7 @@ static int pxa168fb_probe(struct platform_device *pdev)
>   dma_free_coherent(fbi->dev, info->fix.smem_len,
>   info->screen_base, fbi->fb_start_dma);
>  failed_free_info:
> - kfree(info);
> + framebuffer_release(info);
>  
>   dev_err(&pdev->dev, "frame buffer device init failed with %d\n", ret);
>   return ret;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] OMAP: DSS2: remove non-zero check on variable r

[Bartlomiej Zolnierkiewicz]

On 12/4/19 4:28 PM, Colin King wrote:
> From: Colin Ian King 
> 
> Variable r is being initialized to zero, so the check of a non-zero
> rv is redundant and can be removed.
> 
> It appears that the previous case statements set r to be -EINVAL
> and the "Fallthrough" comment afterwards suggested it was going
> to fall through to this non-zero check but won't because of the
> break statement. Remove the confusion by removing the Fallthrough
> comment too.
> 
> Addresses-Coverity: ("Logically dead code")
> Fixes: b39a982ddecf ("OMAP: DSS2: omapfb driver")
> Signed-off-by: Colin Ian King 

Patch queued for v5.6, thanks.
 
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c 
> b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
> index 858c2c011d19..a2a2c1b205d9 100644
> --- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
> +++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
> @@ -1154,16 +1154,12 @@ static int _setcolreg(struct fb_info *fbi, u_int 
> regno, u_int red, u_int green,
>  r = fbdev->ctrl->setcolreg(regno, red, green, blue,
>  transp, update_hw_pal);
>  */
> - /* Fallthrough */
>   r = -EINVAL;
>   break;
>   case OMAPFB_COLOR_RGB565:
>   case OMAPFB_COLOR_RGB444:
>   case OMAPFB_COLOR_RGB24P:
>   case OMAPFB_COLOR_RGB24U:
> - if (r != 0)
> - break;
> -
>   if (regno < 16) {
>   u32 pal;
>   pal = ((red >> (16 - var->red.length)) <<
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] video: Fix Kconfig indentation

[Bartlomiej Zolnierkiewicz]

On 11/21/19 5:09 AM, Krzysztof Kozlowski wrote:
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
>   $ sed -e 's/^/\t/' -i */Kconfig
> 
> Signed-off-by: Krzysztof Kozlowski 
> Acked-by: Bartlomiej Zolnierkiewicz 

Patch queued for v5.6, thanks.
 
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
> 
> Changes since v2:
> 1. Add Bartlomiej's ack.
> 
> Changes since v1:
> 1. Fix also 7-space and tab+1 space indentation issues.
> ---
>  drivers/video/Kconfig   |   4 +-
>  drivers/video/backlight/Kconfig |  16 ++---
>  drivers/video/console/Kconfig   | 132 
> 
>  3 files changed, 76 insertions(+), 76 deletions(-)
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 427a993c7f57..74c2f39cec90 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -26,8 +26,8 @@ endmenu
>  source "drivers/video/backlight/Kconfig"
>  
>  config VGASTATE
> -   tristate
> -   default n
> + tristate
> + default n
>  
>  config VIDEOMODE_HELPERS
>   bool
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 403707a3e503..e25fdd8ce3e7 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -9,7 +9,7 @@ menu "Backlight & LCD device support"
>  # LCD
>  #
>  config LCD_CLASS_DEVICE
> -tristate "Lowlevel LCD controls"
> + tristate "Lowlevel LCD controls"
>   help
> This framework adds support for low-level control of LCD.
> Some framebuffer devices connect to platform-specific LCD modules
> @@ -141,10 +141,10 @@ endif # LCD_CLASS_DEVICE
>  # Backlight
>  #
>  config BACKLIGHT_CLASS_DEVICE
> -tristate "Lowlevel Backlight controls"
> + tristate "Lowlevel Backlight controls"
>   help
> This framework adds support for low-level control of the LCD
> -  backlight. This includes support for brightness and power.
> +   backlight. This includes support for brightness and power.
>  
> To have support for your specific LCD panel you will have to
> select the proper drivers which depend on this option.
> @@ -269,11 +269,11 @@ config BACKLIGHT_MAX8925
> WLED output, say Y here to enable this driver.
>  
>  config BACKLIGHT_APPLE
> -   tristate "Apple Backlight Driver"
> -   depends on X86 && ACPI
> -   help
> - If you have an Intel-based Apple say Y to enable a driver for its
> -  backlight.
> + tristate "Apple Backlight Driver"
> + depends on X86 && ACPI
> + help
> +   If you have an Intel-based Apple say Y to enable a driver for its
> +   backlight.
>  
>  config BACKLIGHT_TOSA
>   tristate "Sharp SL-6000 Backlight Driver"
> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
> index c10e17fb9a9a..ed8480d324b1 100644
> --- a/drivers/video/console/Kconfig
> +++ b/drivers/video/console/Kconfig
> @@ -23,26 +23,26 @@ config VGA_CONSOLE
> Say Y.
>  
>  config VGACON_SOFT_SCROLLBACK
> -   bool "Enable Scrollback Buffer in System RAM"
> -   depends on VGA_CONSOLE
> -   default n
> -   help
> - The scrollback buffer of the standard VGA console is located in
> -  the VGA RAM.  The size of this RAM is fixed and is quite small.
> -  If you require a larger scrollback buffer, this can be placed in
> -  System RAM which is dynamically allocated during initialization.
> -  Placing the scrollback buffer in System RAM will slightly slow
> -  down the console.
> -
> -  If you want this feature, say 'Y' here and enter the amount of
> -  RAM to allocate for this buffer.  If unsure, say 'N'.
> + bool "Enable Scrollback Buffer in System RAM"
> + depends on VGA_CONSOLE
> + default n
> + help
> +   The scrollback buffer of the standard VGA console is located in
> +   the VGA RAM.  The size of this RAM is fixed and is quite small.
> +   If you require a larger scrollback buffer, this can be placed in
> +   System RAM which is dynamically allocated during initialization.
> +   Placing the scrollback buffer in System RAM will slightly slow
> +   down the console.
> +
> +   If you want this feature, say 'Y' here and enter the amount of
> +   RAM to allocate for this buffer.  If unsure, say 'N'.
>  
>  config VGACON_SOFT_SCROLLBACK_SIZE
> -   int "Scrollback Buffer Size (in KB)"
> -   depends on VGACON_SOFT_SCROLLBACK
> -   range 1 1024
> -   default "64"
> -   help
> + int "Scrollback Buffer Size (in KB)"
> + depends on VGACON_SOFT_SCROLLBACK
> + range 1 1024
> + default "64"
> + help
> Enter the amount of System RAM to allocate for scrollback
> buffers of VGA consoles. Each 64KB will give you approximately
> 16 80x25 screenfuls of scrollback buffer.
> @@ -84,1

Re: [PATCH] video: ssd1307fb: add the missed regulator_disable

[Bartlomiej Zolnierkiewicz]

On 12/6/19 3:09 PM, Michal Vokáč wrote:
> On 18. 11. 19 12:41, Chuhong Yuan wrote:
>> The driver forgets to disable the regulator in remove like what is done
>> in probe failure.
>> Add the missed call to fix it.
>>
>> Signed-off-by: Chuhong Yuan 
>> ---
>>   drivers/video/fbdev/ssd1307fb.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/video/fbdev/ssd1307fb.c 
>> b/drivers/video/fbdev/ssd1307fb.c
>> index 78ca7ffc40c2..819fbee18dda 100644
>> --- a/drivers/video/fbdev/ssd1307fb.c
>> +++ b/drivers/video/fbdev/ssd1307fb.c
>> @@ -791,6 +791,8 @@ static int ssd1307fb_remove(struct i2c_client *client)
>>   pwm_disable(par->pwm);
>>   pwm_put(par->pwm);
>>   }
> 
> An empty line missing here?
> 
>> +    if (par->vbat_reg)
>> +    regulator_disable(par->vbat_reg);
>>   fb_deferred_io_cleanup(info);
>>   __free_pages(__va(info->fix.smem_start), 
>> get_order(info->fix.smem_len));
>>   framebuffer_release(info);
>>
> 
> I have tested this on imx6dl-yapp4-hydra board with SSD1305 and this fixes
> the following problem when unloading the driver:
> 
> root@imx6qdlsabresd:~# rmmod ssd1307fb
> [  191.792674] [ cut here ]
> [  191.797453] WARNING: CPU: 0 PID: 858 at 
> /mnt/ssd/users/vokac/development/sources/linux-fslc/drivers/regulator/core.c:2047
>  _regulator_put.part.6+0x178/0x180
> [  191.811464] Modules linked in: ssd1307fb(-)
> [  191.815688] CPU: 0 PID: 858 Comm: rmmod Not tainted 
> 5.4.0-next-20191128-5-g121a1da986f1-dirty #14
> [  191.824914] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [  191.831445] Backtrace:
> [  191.833909] [<8010d878>] (dump_backtrace) from [<8010db8c>] 
> (show_stack+0x20/0x24)
> [  191.841490]  r7:0009 r6:60060013 r5: r4:812d96b0
> [  191.847164] [<8010db6c>] (show_stack) from [<80c1fa24>] 
> (dump_stack+0x9c/0xb0)
> [  191.854395] [<80c1f988>] (dump_stack) from [<80126cec>] (__warn+0xec/0x104)
> [  191.861362]  r7:0009 r6:80ff25c0 r5: r4:
> [  191.867029] [<80126c00>] (__warn) from [<80126dbc>] 
> (warn_slowpath_fmt+0xb8/0xc0)
> [  191.874519]  r9:0009 r8:805a2e00 r7:07ff r6:80ff25c0 r5: 
> r4:81206788
> [  191.882274] [<80126d08>] (warn_slowpath_fmt) from [<805a2e00>] 
> (_regulator_put.part.6+0x178/0x180)
> [  191.891239]  r9:ed261200 r8:ed261b00 r7:ed3d9e64 r6:ec413020 r5:81206788 
> r4:ecaaa400
> [  191.898991] [<805a2c88>] (_regulator_put.part.6) from [<805a2e40>] 
> (regulator_put+0x38/0x48)
> [  191.907435]  r9:ed261200 r8:ed261b00 r7:ed3d9e64 r6:ec413020 r5:81206788 
> r4:ecaaa400
> [  191.915190] [<805a2e08>] (regulator_put) from [<805a9540>] 
> (devm_regulator_release+0x1c/0x20)
> [  191.923716]  r5:81206788 r4:0003
> [  191.927303] [<805a9524>] (devm_regulator_release) from [<8065b848>] 
> (release_nodes+0x1c8/0x208)
> [  191.936007] [<8065b680>] (release_nodes) from [<8065b9e0>] 
> (devres_release_all+0x40/0x60)
> [  191.944191]  r10:0081 r9:ed3d8000 r8:80101204 r7:0081 r6:7f00307c 
> r5:ec412c80
> [  191.952023]  r4:ec413020
> [  191.954568] [<8065b9a0>] (devres_release_all) from [<80657244>] 
> (device_release_driver_internal+0x108/0x1b0)
> [  191.964397]  r5:ec412c80 r4:ec413020
> [  191.967981] [<8065713c>] (device_release_driver_internal) from 
> [<80657398>] (driver_detach+0x64/0xb0)
> [  191.977205]  r7:0081 r6:00cfdebc r5:7f00307c r4:ec413020
> [  191.982872] [<80657334>] (driver_detach) from [<80655ce4>] 
> (bus_remove_driver+0x5c/0xb0)
> [  191.990965]  r5:7f003140 r4:7f00307c
> [  191.994549] [<80655c88>] (bus_remove_driver) from [<80657d88>] 
> (driver_unregister+0x38/0x5c)
> [  192.002989]  r5:7f003140 r4:7f00307c
> [  192.006579] [<80657d50>] (driver_unregister) from [<8078290c>] 
> (i2c_del_driver+0x2c/0x30)
> [  192.014759]  r5:7f003140 r4:7f003060
> [  192.018356] [<807828e0>] (i2c_del_driver) from [<7f001754>] 
> (ssd1307fb_driver_exit+0x14/0x8c0 [ssd1307fb])
> [  192.028013]  r5:7f003140 r4:81206788
> [  192.031604] [<7f001740>] (ssd1307fb_driver_exit [ssd1307fb]) from 
> [<801c36b8>] (sys_delete_module+0x138/0x208)
> [  192.041615] [<801c3580>] (sys_delete_module) from [<80101000>] 
> (ret_fast_syscall+0x0/0x54)
> [  192.049882] Exception stack(0xed3d9fa8 to 0xed3d9ff0)
> [  192.054941] 9fa0:   0002 7eb4ac28 00cfdebc 0800 
> 0064 
> [  192.063125] 9fc0: 0002 7eb4ac28  0081 7eb4af0e 00cfde80 
> 7eb4ae0c 0001
> [  192.071306] 9fe0: 76f0ec61 7eb4abe4 0001b403 76f0ec68
> [  192.076363]  r6: r5:7eb4ac28 r4:0002
> [  192.081033] ---[ end trace af216f02771e12a7 ]---
> 
> 
> With this patch the problem disappears. Thanks.
> 
> Tested-by: Michal Vokáč 

Patch queued for v5.6, thanks.
 
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-d

Re: [PATCH] fbdev: s1d13xxxfb: add missed unregister_framebuffer in remove

[Bartlomiej Zolnierkiewicz]

On 11/18/19 9:09 AM, Chuhong Yuan wrote:
> The driver calls register_framebuffer in probe but does not call
> unregister_framebuffer in remove.
> Add the missed call to fix it.
> 
> Signed-off-by: Chuhong Yuan 
> ---
>  drivers/video/fbdev/s1d13xxxfb.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/video/fbdev/s1d13xxxfb.c 
> b/drivers/video/fbdev/s1d13xxxfb.c
> index e04efb567b5c..162003ea6b79 100644
> --- a/drivers/video/fbdev/s1d13xxxfb.c
> +++ b/drivers/video/fbdev/s1d13xxxfb.c
> @@ -729,6 +729,7 @@ s1d13xxxfb_remove(struct platform_device *pdev)
>   struct s1d13xxxfb_par *par = NULL;
>  
>   if (info) {
> + unregister_framebuffer(info);

s1d13xxxfb_remove() is not only called on removal operation but also
by s1d13xxxfb_probe() on register_framebuffer() failure. After above
change the code in s1d13xxxfb_probe() will break. The issue needs to
be fixed in different way, i.e.

- rename existing s1d13xxxfb_remove() to __s1d13xxxfb_remove()

- add s1d13xxxfb_remove() which does unregister_framebuffer() and
  then calls __s1d13xxxfb_remove())

>   par = info->par;
>   if (par && par->regs) {
>   /* disable output & enable powersave */
> 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] dt-bindings: arm: sunxi: add binding for PineTab tablet

[Rob Herring]

On Fri, 10 Jan 2020 23:52:24 +0800, Icenowy Zheng wrote:
> Add the device tree binding for Pine64's PineTab tablet, which uses
> Allwinner A64 SoC.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +
>  1 file changed, 5 insertions(+)
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 4/4] drm/i915/gvt: move public gvt headers out into global include

[Greg KH]

On Thu, Jan 09, 2020 at 07:13:57PM +0200, Julian Stecklina wrote:
> Now that the GVT interface to hypervisors does not depend on i915/GVT
> internals anymore, we can move the headers to the global include/.
> 
> This makes out-of-tree modules for hypervisor integration possible.

What kind of out-of-tree modules do you need/want for this?  And why do
they somehow have to be out of the tree?  We want them in the tree, and
so should you, as it will save you time and money if they are.

Also, as Christoph said, adding exports for functions that are not used
by anything within the kernel tree itself is not ok, that's not how we
work.

thanks,

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] dt-bindings: vendor-prefix: add Shenzhen Feixin Photoelectics Co., Ltd

[Rob Herring]

On Fri, 10 Jan 2020 23:52:21 +0800, Icenowy Zheng wrote:
> Shenzhen Feixin Photoelectics Co., Ltd is a company to provide LCD
> modules.
> 
> Add its vendor prefix.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.

[Bartlomiej Zolnierkiewicz]

On 1/6/20 11:37 PM, Dexuan Cui wrote:
>> From: Michael Kelley 
>> Sent: Monday, December 9, 2019 8:33 AM
>> To: Wei Hu ; b.zolnier...@samsung.com; KY
>> Srinivasan ; Haiyang Zhang ;
>> Stephen Hemminger ; sas...@kernel.org;
>> h...@lst.de; m.szyprow...@samsung.com; mchehab+sams...@kernel.org;
>> s...@ravnborg.org; gre...@linuxfoundation.org;
>> alexandre.bell...@bootlin.com; i...@metux.net; a...@arndb.de;
>> dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org;
>> linux-ker...@vger.kernel.org; linux-hyp...@vger.kernel.org; Dexuan Cui
>> 
>> Cc: kbuild test robot 
>> Subject: RE: [PATCH v4] video: hyperv: hyperv_fb: Use physical memory for
>> fb on HyperV Gen 1 VMs.
>>
>> From: Wei Hu  Sent: Sunday, December 8, 2019 11:58
>> PM
>>>
>>> On Hyper-V, Generation 1 VMs can directly use VM's physical memory for
>>> their framebuffers. This can improve the efficiency of framebuffer and
>>> overall performance for VM. The physical memory assigned to framebuffer
>>> must be contiguous. We use CMA allocator to get contiguous physicial
>>> memory when the framebuffer size is greater than 4MB. For size under
>>> 4MB, we use alloc_pages to achieve this.
>>>
>>> To enable framebuffer memory allocation from CMA, supply a kernel
>>> parameter to give enough space to CMA allocator at boot time. For
>>> example:
>>> cma=130m
>>> This gives 130MB memory to CAM allocator that can be allocated to
>>> framebuffer. If this fails, we fall back to the old way of using
>>> mmio for framebuffer.
>>>
>>> Reported-by: kbuild test robot 
>>> Signed-off-by: Wei Hu 
>>> ---
>>> v2: Incorporated review comments form h...@lst.de, Michael Kelley
>> and
>>> Dexuan Cui
>>> - Use dma_alloc_coherent to allocate large contiguous memory
>>> - Use phys_addr_t for physical addresses
>>> - Corrected a few spelling errors and minor cleanups
>>> - Also tested on 32 bit Ubuntu guest
>>> v3: Fixed a build issue reported by kbuild test robot and incorported
>>> some review comments from Michael Kelley
>>> - Add CMA check to avoid link failure
>>> - Fixed small memory leak introduced by alloc_apertures
>>> - Cleaned up so code
>>> v4: Removed request_pages variable as it is no longer needed
>>>
>>>  drivers/video/fbdev/Kconfig |   1 +
>>>  drivers/video/fbdev/hyperv_fb.c | 182
>> +---
>>>  2 files changed, 144 insertions(+), 39 deletions(-)
>>>
>>
>> Reviewed-by: Michael Kelley 
> 
> Tested-by: Dexuan Cui 
> 
> For a Gen-1 VM running on recent Hyper-V hosts, this patch can greatly 
> reduce the CPU utilization because it avoids the slow data copy from the 
> shadow framebuffer to the MMIO framebuffer, and hence it resolves the
> "blurred screen" issue when we output a lot of characters on the text-mode
> ternimal (e.g. "dmesg").

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 07/21] drm/i915: Convert to CRTC VBLANK callbacks

[Ville Syrjälä]

On Wed, Jan 15, 2020 at 01:16:38PM +0100, Thomas Zimmermann wrote:
> VBLANK callbacks in struct drm_driver are deprecated in favor of their
> equivalents in struct drm_crtc_funcs. Convert i915 over.
> 
> The callback struct drm_driver.get_scanout_position() is deprecated
> in favor of struct drm_crtc_helper_funcs.get_scanout_position().
> i915 doesn't use CRTC helpers. Instead pass i915's implementation of
> get_scanout_position() to DRM core's
> drm_crtc_vblank_helper_get_vblank_timestamp_internal().
> 
> v2:
>   * use DRM's implementation of get_vblank_timestamp()
>   * simplify function names
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c |  7 +++
>  drivers/gpu/drm/i915/i915_drv.c  |  3 ---
>  drivers/gpu/drm/i915/i915_irq.c  | 20 +++-
>  drivers/gpu/drm/i915/i915_irq.h  |  6 ++
>  4 files changed, 24 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 59c375879186..c8f1da845e7d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16336,6 +16336,7 @@ static const struct drm_crtc_funcs bdw_crtc_funcs = {
>   .get_vblank_counter = g4x_get_vblank_counter,
>   .enable_vblank = bdw_enable_vblank,
>   .disable_vblank = bdw_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs ilk_crtc_funcs = {
> @@ -16344,6 +16345,7 @@ static const struct drm_crtc_funcs ilk_crtc_funcs = {
>   .get_vblank_counter = g4x_get_vblank_counter,
>   .enable_vblank = ilk_enable_vblank,
>   .disable_vblank = ilk_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs g4x_crtc_funcs = {
> @@ -16352,6 +16354,7 @@ static const struct drm_crtc_funcs g4x_crtc_funcs = {
>   .get_vblank_counter = g4x_get_vblank_counter,
>   .enable_vblank = i965_enable_vblank,
>   .disable_vblank = i965_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs i965_crtc_funcs = {
> @@ -16360,6 +16363,7 @@ static const struct drm_crtc_funcs i965_crtc_funcs = {
>   .get_vblank_counter = i915_get_vblank_counter,
>   .enable_vblank = i965_enable_vblank,
>   .disable_vblank = i965_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs i915gm_crtc_funcs = {
> @@ -16368,6 +16372,7 @@ static const struct drm_crtc_funcs i915gm_crtc_funcs 
> = {
>   .get_vblank_counter = i915_get_vblank_counter,
>   .enable_vblank = i915gm_enable_vblank,
>   .disable_vblank = i915gm_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs i915_crtc_funcs = {
> @@ -16376,6 +16381,7 @@ static const struct drm_crtc_funcs i915_crtc_funcs = {
>   .get_vblank_counter = i915_get_vblank_counter,
>   .enable_vblank = i8xx_enable_vblank,
>   .disable_vblank = i8xx_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs i8xx_crtc_funcs = {
> @@ -16384,6 +16390,7 @@ static const struct drm_crtc_funcs i8xx_crtc_funcs = {
>   /* no hw vblank counter */
>   .enable_vblank = i8xx_enable_vblank,
>   .disable_vblank = i8xx_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static struct intel_crtc *intel_crtc_alloc(void)
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f7385abdd74b..30b9ba136a81 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2769,9 +2769,6 @@ static struct drm_driver driver = {
>   .gem_prime_export = i915_gem_prime_export,
>   .gem_prime_import = i915_gem_prime_import,
>  
> - .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> - .get_scanout_position = i915_get_crtc_scanoutpos,
> -
>   .dumb_create = i915_gem_dumb_create,
>   .dumb_map_offset = i915_gem_dumb_mmap_offset,
>  
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index afc6aad9bf8c..c39e3ef6e4a2 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -762,13 +762,15 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
> *crtc)
>   return (position + crtc->scanline_offset) % vtotal;
>  }
>  
> -bool i915_get_crtc_scanoutpos(struct drm_device *dev, unsigned int index,
> -   bool in_vblank_irq, int *vpos, int *hpos,
> -   ktime_t *stime, ktime_t *etime,
> -   const struct drm_display_mode *mode)
> +static bool i915_get_crtc_scanoutpos

Re: [PATCH] video: fbdev: arcfb: add missed free_irq

[Bartlomiej Zolnierkiewicz]

On 11/16/19 4:44 PM, Chuhong Yuan wrote:
> The driver forgets to free irq in remove which is requested in
> probe.
> Add the missed call to fix it.
> 
> Signed-off-by: Chuhong Yuan 
> ---
>  drivers/video/fbdev/arcfb.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c
> index a48741aab240..7aed01f001a4 100644
> --- a/drivers/video/fbdev/arcfb.c
> +++ b/drivers/video/fbdev/arcfb.c
> @@ -590,8 +590,11 @@ static int arcfb_probe(struct platform_device *dev)
>  static int arcfb_remove(struct platform_device *dev)
>  {
>   struct fb_info *info = platform_get_drvdata(dev);
> + struct arcfb_par *par = info->par;
>  
>   if (info) {
> + if (irq)
> + free_irq(par->irq, info);
>   unregister_framebuffer(info);

We cannot free IRQ while framebuffer is registered (as we can
deadlock in arcfb_ioctl()).

Also it seems that ordering in the probe function is wrong
(it should not request IRQ or initialize the hardware after
registering framebuffer).

>   vfree((void __force *)info->screen_base);
>   framebuffer_release(info);

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 4/5] drm/tidss: New driver for TI Keystone platform Display SubSystem

[Jyri Sarha]

On 15/01/2020 16:43, Sam Ravnborg wrote:
> Hi Jyri.
> 

>>> ...
 v6: - Check CTM and gamma support from dispc_features when creating crtc
 - Implement CTM support for k2g and fix k3 CTM implementation
 - Remove gamma property persistence and always write color properties
   in a new modeset
>>>
>>> I applied this, just to throw this throgh my build setup.
>>>
>>> checkpatch reported:
>>> total: 0 errors, 45 warnings, 46 checks, 4920 lines checked
>>>
>>> - space after cast
>>> - CamelCase
>>> - Macro argument
>>> - length warnings
>>> - alignment
>>>
>>> I would ignore the line length warnings for the coefficients, but fix the
>>> rest.
>>>
>>
>> You are using --subjective, or are there new warnings turned on since I
>> rebased?
> This was the warnigns that appearted when I did
> cat patches | dim apply
> 
> So the defaults in dim was used - which is:
> -q --emacs --strict --show-types
> 

Oh, I didn't know that dim uses --strict (= subjective). I have used dim
but never for anything this big and all those smaller patches have been
"strict"-clean, since I have not seen any warnings.

Well, I'll bite the bullet then, and start mangling the code to the
"strict" format.

Thanks,
Jyri

> As dim is the tool used when applying patches to drm-misc-next then
> whoever ends up applying the patches will see the same warnigns from
> checkpatch.
> 
> You can find more info on dim here:
> https://drm.pages.freedesktop.org/maintainer-tools/dim.html
> 
> As maintainer of this driver you will need to learn the basics.
> 
> My dim vocabulary are:
> dim apply
> dim fixes
> dim push
> dim update-branches
> dim checkpatch
> 
> dim can do much more, but this is the ones that I use most.
> In your case you would like to use "dim checkpatch HEAD~5"
> 
>   Sam
> 


-- 
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] video: fbdev: vesafb: add missed release_region

[Bartlomiej Zolnierkiewicz]

On 12/5/19 5:07 PM, Chuhong Yuan wrote:
> The driver forgets to free the requested irq in remove and probe
> failure.

This is I/O region not IRQ.

> Add the missed calls to fix it.
> 
> Signed-off-by: Chuhong Yuan 
> ---
> Changes in v2:
>   - Modify commit message.
> 
>  drivers/video/fbdev/vesafb.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
> index d9c08f6c2155..fbb196a8bbf6 100644
> --- a/drivers/video/fbdev/vesafb.c
> +++ b/drivers/video/fbdev/vesafb.c
> @@ -468,6 +468,7 @@ static int vesafb_probe(struct platform_device *dev)
>   fb_info(info, "%s frame buffer device\n", info->fix.id);
>   return 0;
>  err:
> + release_region(0x3c0, 32);

There is one 'goto err;' instance before request_region() which
needs to be taken care of first.

>   arch_phys_wc_del(par->wc_cookie);
>   if (info->screen_base)
>   iounmap(info->screen_base);
> @@ -480,6 +481,7 @@ static int vesafb_remove(struct platform_device *pdev)
>  {
>   struct fb_info *info = platform_get_drvdata(pdev);
>  
> + release_region(0x3c0, 32);
>   unregister_framebuffer(info);

The order of operations on remove should be the reverse of
order of operations on probe.

[ We cannot release I/O region while framebuffer is active. ]

>   framebuffer_release(info);

Please fix the patch and re-submit.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v2 03/21] drm: Add get_vblank_timestamp() to struct drm_crtc_funcs

[Ville Syrjälä]

On Wed, Jan 15, 2020 at 01:16:34PM +0100, Thomas Zimmermann wrote:
> The callback get_vblank_timestamp() is currently located in struct
> drm_driver, but really belongs into struct drm_crtc_funcs. Add an
> equivalent there. Driver will be converted in separate patches.
> 
> The default implementation is drm_calc_vbltimestamp_from_scanoutpos().
> The patch adds drm_crtc_vblank_helper_get_vblank_timestamp(), which is
> an implementation for the CRTC callback.
> 
> v2:
>   * rename helper to drm_crtc_vblank_helper_get_vblank_timestamp()
>   * replace drm_calc_vbltimestamp_from_scanoutpos() with
> drm_crtc_vblank_helper_get_vblank_timestamp() in docs
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_vblank.c | 236 +--
>  include/drm/drm_crtc.h   |  46 -
>  include/drm/drm_modeset_helper_vtables.h |   4 +-
>  include/drm/drm_vblank.h |  26 ++-
>  4 files changed, 292 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index abb085c67d82..1b7af316e6a5 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -333,7 +333,9 @@ u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
>   u64 vblank;
>   unsigned long flags;
>  
> - WARN_ONCE(drm_debug_enabled(DRM_UT_VBL) && 
> !dev->driver->get_vblank_timestamp,
> + WARN_ONCE(drm_debug_enabled(DRM_UT_VBL) &&
> +   !crtc->funcs->get_vblank_timestamp &&
> +   !dev->driver->get_vblank_timestamp,
> "This function requires support for accurate vblank 
> timestamps.");
>  
>   spin_lock_irqsave(&dev->vblank_time_lock, flags);
> @@ -511,9 +513,9 @@ EXPORT_SYMBOL(drm_crtc_vblank_waitqueue);
>   *
>   * Calculate and store various constants which are later needed by vblank and
>   * swap-completion timestamping, e.g, by
> - * drm_calc_vbltimestamp_from_scanoutpos(). They are derived from CRTC's true
> - * scanout timing, so they take things like panel scaling or other 
> adjustments
> - * into account.
> + * drm_crtc_vblank_helper_get_vblank_timestamp(). They are derived from
> + * CRTC's true scanout timing, so they take things like panel scaling or
> + * other adjustments into account.
>   */
>  void drm_calc_timestamping_constants(struct drm_crtc *crtc,
>const struct drm_display_mode *mode)
> @@ -577,8 +579,9 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
>   *
>   * Implements calculation of exact vblank timestamps from given 
> drm_display_mode
>   * timings and current video scanout position of a CRTC. This can be directly
> - * used as the &drm_driver.get_vblank_timestamp implementation of a kms 
> driver
> - * if &drm_crtc_helper_funcs.get_scanout_position is implemented.
> + * used as the &drm_crtc_funcs.get_vblank_timestamp implementation of a kms
> + * driver if &drm_crtc_helper_funcs.get_scanout_position or
> + * &drm_driver.get_scanout_position is implemented.
>   *
>   * The current implementation only handles standard video modes. For double 
> scan
>   * and interlaced modes the driver is supposed to adjust the hardware mode
> @@ -742,15 +745,22 @@ static bool
>  drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
> ktime_t *tvblank, bool in_vblank_irq)
>  {
> + struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
>   bool ret = false;
>  
>   /* Define requested maximum error on timestamps (nanoseconds). */
>   int max_error = (int) drm_timestamp_precision * 1000;
>  
>   /* Query driver if possible and precision timestamping enabled. */
> - if (dev->driver->get_vblank_timestamp && (max_error > 0))
> + if (crtc->funcs->get_vblank_timestamp && (max_error > 0)) {

Could drop the superfluous parens while at it.

Are all drivers utilizing this guaranteed to have the crtc here?

> + struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
> +
> + ret = crtc->funcs->get_vblank_timestamp(crtc, &max_error,
> + tvblank, in_vblank_irq);
> + } else if (dev->driver->get_vblank_timestamp && (max_error > 0)) {
>   ret = dev->driver->get_vblank_timestamp(dev, pipe, &max_error,
>   tvblank, in_vblank_irq);
> + }
>  
>   /* GPU high precision timestamp query unsupported or failed.
>* Return current monotonic/gettimeofday timestamp as best estimate.
> @@ -1059,11 +1069,19 @@ EXPORT_SYMBOL(drm_crtc_vblank_get);
>  
>  static bool __vblank_disable_immediate(struct drm_device *dev, unsigned int 
> pipe)
>  {
> + struct drm_crtc *crtc;
> +
>   if (!dev->vblank_disable_immediate)
>   return false;
> - if (!dev->driver->get_vblank_timestamp)
> - return false;
> - return true;
> +
> + crtc = drm_crtc_from_index(dev, pipe);
> + 

Re: [PATCH v6 4/5] drm/tidss: New driver for TI Keystone platform Display SubSystem

[Sam Ravnborg]

Hi Jyri.

> >>
> > ...
> >> v6: - Check CTM and gamma support from dispc_features when creating crtc
> >> - Implement CTM support for k2g and fix k3 CTM implementation
> >> - Remove gamma property persistence and always write color properties
> >>   in a new modeset
> > 
> > I applied this, just to throw this throgh my build setup.
> > 
> > checkpatch reported:
> > total: 0 errors, 45 warnings, 46 checks, 4920 lines checked
> > 
> > - space after cast
> > - CamelCase
> > - Macro argument
> > - length warnings
> > - alignment
> > 
> > I would ignore the line length warnings for the coefficients, but fix the
> > rest.
> > 
> 
> You are using --subjective, or are there new warnings turned on since I
> rebased?
This was the warnigns that appearted when I did
cat patches | dim apply

So the defaults in dim was used - which is:
-q --emacs --strict --show-types

As dim is the tool used when applying patches to drm-misc-next then
whoever ends up applying the patches will see the same warnigns from
checkpatch.

You can find more info on dim here:
https://drm.pages.freedesktop.org/maintainer-tools/dim.html

As maintainer of this driver you will need to learn the basics.

My dim vocabulary are:
dim apply
dim fixes
dim push
dim update-branches
dim checkpatch

dim can do much more, but this is the ones that I use most.
In your case you would like to use "dim checkpatch HEAD~5"

Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v2 02/21] drm: Evaluate struct drm_device.vblank_disable_immediate on each use

[Ville Syrjälä]

On Wed, Jan 15, 2020 at 01:16:33PM +0100, Thomas Zimmermann wrote:
> VBLANK interrupts can be disabled immediately or with a delay, where the
> latter is the default. The former option can be selected by setting
> get_vblank_timestamp, and enabling vblank_disable_immediate in struct
> drm_device.
> 
> The setup is only evaluated once when DRM initializes VBLANKs. Evaluating
> the settings on each use of vblank_disable_immediate will allow for easy
> integration of CRTC VBLANK functions.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_vblank.c | 31 ++-
>  1 file changed, 14 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 3f1dd54cc8bb..abb085c67d82 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -481,19 +481,6 @@ int drm_vblank_init(struct drm_device *dev, unsigned int 
> num_crtcs)
>  
>   DRM_INFO("Supports vblank timestamp caching Rev 2 (21.10.2013).\n");
>  
> - /* Driver specific high-precision vblank timestamping supported? */
> - if (dev->driver->get_vblank_timestamp)
> - DRM_INFO("Driver supports precise vblank timestamp query.\n");
> - else
> - DRM_INFO("No driver support for vblank timestamp query.\n");
> -
> - /* Must have precise timestamping for reliable vblank instant disable */
> - if (dev->vblank_disable_immediate && 
> !dev->driver->get_vblank_timestamp) {
> - dev->vblank_disable_immediate = false;
> - DRM_INFO("Setting vblank_disable_immediate to false because "
> -  "get_vblank_timestamp == NULL\n");
> - }

Which drivers are so broken they set vblank_disable_immediate to true
without having the vfunc specified? IMO this code should just go away
(or converted to a WARN).

> -
>   return 0;
>  
>  err:
> @@ -1070,6 +1057,15 @@ int drm_crtc_vblank_get(struct drm_crtc *crtc)
>  }
>  EXPORT_SYMBOL(drm_crtc_vblank_get);
>  
> +static bool __vblank_disable_immediate(struct drm_device *dev, unsigned int 
> pipe)
> +{
> + if (!dev->vblank_disable_immediate)
> + return false;
> + if (!dev->driver->get_vblank_timestamp)
> + return false;
> + return true;
> +}
> +
>  static void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
>  {
>   struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> @@ -1086,7 +1082,7 @@ static void drm_vblank_put(struct drm_device *dev, 
> unsigned int pipe)
>   return;
>   else if (drm_vblank_offdelay < 0)
>   vblank_disable_fn(&vblank->disable_timer);
> - else if (!dev->vblank_disable_immediate)
> + else if (__vblank_disable_immediate(dev, pipe))
>   mod_timer(&vblank->disable_timer,
> jiffies + ((drm_vblank_offdelay * HZ)/1000));
>   }
> @@ -1663,7 +1659,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void 
> *data,
>   /* If the counter is currently enabled and accurate, short-circuit
>* queries to return the cached timestamp of the last vblank.
>*/
> - if (dev->vblank_disable_immediate &&
> + if (__vblank_disable_immediate(dev, pipe) &&
>   drm_wait_vblank_is_query(vblwait) &&
>   READ_ONCE(vblank->enabled)) {
>   drm_wait_vblank_reply(dev, pipe, &vblwait->reply);
> @@ -1820,7 +1816,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
> int pipe)
>* been signaled. The disable has to be last (after
>* drm_handle_vblank_events) so that the timestamp is always accurate.
>*/
> - disable_irq = (dev->vblank_disable_immediate &&
> + disable_irq = (__vblank_disable_immediate(dev, pipe) &&
>  drm_vblank_offdelay > 0 &&
>  !atomic_read(&vblank->refcount));
>  
> @@ -1893,7 +1889,8 @@ int drm_crtc_get_sequence_ioctl(struct drm_device *dev, 
> void *data,
>   pipe = drm_crtc_index(crtc);
>  
>   vblank = &dev->vblank[pipe];
> - vblank_enabled = dev->vblank_disable_immediate && 
> READ_ONCE(vblank->enabled);
> + vblank_enabled = __vblank_disable_immediate(dev, pipe) &&
> +  READ_ONCE(vblank->enabled);
>  
>   if (!vblank_enabled) {
>   ret = drm_crtc_vblank_get(crtc);
> -- 
> 2.24.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][next] video: hyperv: hyperv_fb: fix indentation issue

[Bartlomiej Zolnierkiewicz]

On 11/14/19 6:27 PM, Colin King wrote:
> From: Colin Ian King 
> 
> There is a block of statements that are indented
> too deeply, remove the extraneous tabs.
> 
> Signed-off-by: Colin Ian King 

Patch queued for v5.6, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/video/fbdev/hyperv_fb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> index 4cd27e5172a1..5fcf4bdf85ab 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -582,8 +582,8 @@ static int synthvid_get_supported_resolution(struct 
> hv_device *hdev)
>   t = wait_for_completion_timeout(&par->wait, VSP_TIMEOUT);
>   if (!t) {
>   pr_err("Time out on waiting resolution response\n");
> - ret = -ETIMEDOUT;
> - goto out;
> + ret = -ETIMEDOUT;
> + goto out;
>   }
>  
>   if (msg->resolution_resp.resolution_count == 0) {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] fbdev: potential information leak in do_fb_ioctl()

[Bartlomiej Zolnierkiewicz]

On 1/13/20 12:08 PM, Dan Carpenter wrote:
> The "fix" struct has a 2 byte hole after ->ywrapstep and the
> "fix = info->fix;" assignment doesn't necessarily clear it.  It depends
> on the compiler.  The solution is just to replace the assignment with an
> memcpy().
> 
> Fixes: 1f5e31d7e55a ("fbmem: don't call copy_from/to_user() with mutex held")
> Signed-off-by: Dan Carpenter 

Patch queued for v5.6, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
> v2:  Use memcpy()
> 
>  drivers/video/fbdev/core/fbmem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/core/fbmem.c 
> b/drivers/video/fbdev/core/fbmem.c
> index d04554959ea7..bb8d8dbc0461 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1115,7 +1115,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned 
> int cmd,
>   break;
>   case FBIOGET_FSCREENINFO:
>   lock_fb_info(info);
> - fix = info->fix;
> + memcpy(&fix, &info->fix, sizeof(fix));
>   if (info->flags & FBINFO_HIDE_SMEM_START)
>   fix.smem_start = 0;
>   unlock_fb_info(info);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 4/5] drm/tidss: New driver for TI Keystone platform Display SubSystem

[Jyri Sarha]

On 15/01/2020 14:22, Sam Ravnborg wrote:
> Hi Jyri.
> 
> On Wed, Jan 15, 2020 at 01:45:38PM +0200, Jyri Sarha wrote:
>> This patch adds a new DRM driver for Texas Instruments DSS IPs used on
>> Texas Instruments Keystone K2G, AM65x, and J721e SoCs. The new DSS IP is
>> a major change to the older DSS IP versions, which are supported by
>> the omapdrm driver. While on higher level the Keystone DSS resembles
>> the older DSS versions, the registers are completely different and the
>> internal pipelines differ a lot.
>>
>> DSS IP found on K2G is an "ultra-light" version, and has only a single
>> plane and a single output. The K3 DSS IPs are found on AM65x and J721E
>> SoCs. AM65x DSS has two video ports, one full video plane, and another
>> "lite" plane without scaling support. J721E has 4 video ports, 2 video
>> planes and 2 lite planes. AM65x DSS has also an integrated OLDI (LVDS)
>> output.
>>
> ...
>> v6: - Check CTM and gamma support from dispc_features when creating crtc
>> - Implement CTM support for k2g and fix k3 CTM implementation
>> - Remove gamma property persistence and always write color properties
>>   in a new modeset
> 
> I applied this, just to throw this throgh my build setup.
> 
> checkpatch reported:
> total: 0 errors, 45 warnings, 46 checks, 4920 lines checked
> 
> - space after cast
> - CamelCase
> - Macro argument
> - length warnings
> - alignment
> 
> I would ignore the line length warnings for the coefficients, but fix the
> rest.
> 

You are using --subjective, or are there new warnings turned on since I
rebased?

Without it I only see long lines warnings and one "break is not useful
after a goto or return" that I had accidentally added there. We have not
cared too much of the long lines, but that is not a big deal, I'll fix them.

I had checked the subjective warnings too, but there I used some
consideration, if the warning would indicate a real problem.

Should I get rid off all the subjective warnings (apart from the long
lines in the coefficients)?

Best regards,
Jyri

-- 
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 v4] drm/trace: Buffer DRM logs in a ringbuffer accessible via debugfs

[Sean Paul]

On Wed, Jan 15, 2020 at 02:01:19PM +, Chris Wilson wrote:
> Quoting Sean Paul (2020-01-15 13:41:58)
> > On Wed, Jan 15, 2020 at 10:36:36AM +, Chris Wilson wrote:
> > > Quoting Sean Paul (2020-01-14 17:21:43)
> > > > From: Sean Paul 
> > > > 
> > > > This patch uses a ring_buffer to keep a "flight recorder" (name credit 
> > > > Weston)
> > > > of DRM logs for a specified set of debug categories. The user writes a
> > > > bitmask of debug categories to the "trace_mask" node and can read log
> > > > messages from the "trace" node.
> > > > 
> > > > These nodes currently exist in debugfs under the dri directory. I
> > > > intended on exposing all of this through tracefs originally, but the
> > > > tracefs entry points are not exposed, so there's no way to create
> > > > tracefs files from drivers at the moment. I think it would be a
> > > > worthwhile endeavour, but one requiring more time and conversation to
> > > > ensure the drm traces fit somewhere sensible.
> > > 
> > > Fwiw, I have a need for client orientated debug message store, with
> > > the primary purpose of figuring out -EINVAL. We need per-client so we can
> > > put sensitive information about the potentially buggy client behaviour,
> > > and of course it needs to be accessible by the non-privileged client.
> > > 
> > > On the execution side, it's easy to keep track of the client so we could
> > > trace execution flow per client, within reason. And we could do
> > > similarly for kms clients.
> > 
> > Could you build such a thing with drm_trace underpinning it, just put the
> > pertinent information in the message?
> 
> Not as is. The global has to go, and there's no use for debugfs. So we
> are just left with a sprintf() around a ring_buffer. I am left in the
> same position as just wanting to generalise tracek to take the ringbuffer
> as a parameter.
> 

Ah, I think I see what you're getting at now. I think it would be reasonable to
split out a drm_trace_buffer from the current code for this purpose. We could
have an interface like:

struct drm_trace_buffer *drm_trace_buffer_init(unsigned int num_pages);
int drm_trace_buffer_resize(struct drm_trace_buffer *buf, unsigned int 
num_pages);
int drm_trace_buffer_printf(struct drm_trace_buffer *buf, const char *format, 
...);
int drm_trace_buffer_output(struct seq_file *seq);
void drm_trace_buffer_cleanup(struct drm_trace_buffer *buf);

Then to Joonas' point, we could have drm_trace_log which uses this interface to
mirror the logs with a debugfs interface.

Would that work for your purpose?


> > > Just chiming to say, I don't think a duplicate of dmesg hidden inside
> > > debugfs achieves much. But a generic tracek-esque ringbuf would be very
> > > useful -- even if only so we can separate our GEM_TRACE from the global
> > > tracek.
> > 
> > I think that's essentially what we've got, I've just narrowly focused on
> > surfacing debug logs. If drm_trace_printf were exported, replacing
> > GEM_TRACE would be as simple as s/trace_printk/drm_trace_printf/. Initially 
> > I
> > thought exporting it to drivers would be a bad idea, but I'm open to 
> > changing my
> > mind on this as long as drivers are using it responsibly. 
> 
> I definitely can't make the mistake of flooding kms tracing with
> overwhelming execution traces -- we can't go back to mixing kms traces
> with execution traces.

Yeah, I assumed this wouldn't be enabled during normal operation, just for
debugging (as it is used now).

Sean

> -Chris

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Ville Syrjälä]

On Wed, Jan 15, 2020 at 02:34:02PM +0200, Jani Nikula wrote:
> On Fri, 10 Jan 2020, Ville Syrjälä  wrote:
> > On Thu, Jan 09, 2020 at 04:26:19PM -0500, Harry Wentland wrote:
> >> 
> >> 
> >> On 2020-01-09 4:04 p.m., Mario Kleiner wrote:
> >> > On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher  >> > > wrote:
> >> >
> >> > On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
> >> > mailto:mario.kleiner...@gmail.com>>
> >> > wrote:
> >> > >
> >> > > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher
> >> > mailto:alexdeuc...@gmail.com>> wrote:
> >> > >>
> >> > >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> >> > >>  >> > > wrote:
> >> > >> >
> >> > As Harry mentioned in the other thread, won't this only work if the
> >> > display was brought up by the vbios?  In the suspend/resume case,
> >> > won't we just fall back to 2.7Gbps?
> >> >
> >> > Alex
> >> >
> >> >
> >> > Adding Harry to cc...
> >> >
> >> > The code is only executed for eDP. On the Intel side, it seems that
> >> > intel_edp_init_dpcd() gets only called during driver load /
> >> > modesetting init, so not on resume.
> >> >
> >> > On the AMD DC side, dc_link_detect_helper() has this early no-op
> >> > return at the beginning:
> >> >
> >> > if ((link->connector_signal == SIGNAL_TYPE_LVDS ||
> >> >  link->connector_signal == SIGNAL_TYPE_EDP) &&
> >> >  link->local_sink)
> >> >  return true;
> >> >
> >> > So i guess if link->local_sink doesn't get NULL'ed during a
> >> > suspend/resume cycle, then we never reach the setup code that would
> >> > overwrite with non vbios settings?
> >> >
> >> > Sounds reasonable to me, given that eDP panels are usually fixed
> >> > internal panels, nothing that gets hot(un-)plugged?
> >> >
> >> > I can't test, because suspend/resume with the Polaris gpu on the MBP
> >> > 2017 is totally broken atm., just as vgaswitcheroo can't do its job.
> >> > Looks like powering down the gpu works, but powering up doesn't. And
> >> > also modesetting at vgaswitcheroo switch time is no-go, because the
> >> > DDC/AUX lines apparently can't be switched on that Apple gmux, and
> >> > handover of that data seems to be not implemented in current
> >> > vgaswitcheroo. At the moment switching between AMD only or Intel+AMD
> >> > Prime setup is quite a pita...
> >> >
> >> 
> >> I haven't followed the entire discussion on the i915 thread but for the
> >> amdgpu dc patch I would prefer a DPCD quirk to override the reported
> >> link settings with the correct link rate.
> >
> > We could consider adding a standard function for reading the receiver
> > caps and applying the quirk there. I have a feeling that putting it
> > into drm_dp_dpcd_read() would be a bit too low level since it would
> > prevent reading the non-quirked raw data easily.
> 
> Everything about this panel is ugly.
> 
> The panel does not claim to support extended receiver caps. (I have not
> seen whether there is non-zero data at 0x2200. Mario, please provide a
> dump of that DPCD region.)
> 
> The panel does use DPCD_DISPLAY_CONTROL_CAPABLE and reports eDP 1.3 in
> EDP_DPCD_REV.
> 
> eDP 1.3 says only four values are supported in LINK_BW_SET (0x06, 0x0a,
> 0x14, and 0x1e). The same for MAX_LINK_RATE for all DP, and even in the
> extended receiver cap.
> 
> You could perhaps make the case for the interpretation in commit
> 57a1b0893782 ("drm: Make the bw/link rate calculations more forgiving")
> that in eDP 1.4+ you can use arbitrary values in LINK_BW_SET. But I
> think that's a stretch, really. And anyway the panel reports eDP 1.3.
> 
> The panel is consistent in that it does not claim to support link rate
> selection nor does it have anything in SUPPORTED_LINK_RATES which are
> eDP 1.4+ features.
> 
> However, the panel reports 0x0a as the max link rate in MAX_LINK_RATE,
> which exceeds the value 0x0c set in LINK_BW_SET by the firmware.
> 
> Bottom line is, *if* we're going to support this proprietary crap of a
> panel, it *must* be an isolated quirk. I certainly won't take a patch
> generalizing this to any panel out there. But you're going to have to be
> pretty clever to isolate this crap. I'm not sure if quirking a homebrew
> extended receiver cap is going to be enough.

drm_dp_read_receiver_caps()
{
dpcd_read(dpcd);
if (quirk) {
DRM_DEBUG_KMS("blah");
dpcd[MAX_BW] = 0xc;
}
}

intel_dp_sink_rates()
{
...
if (max_bw > rates[i-1])
rates[i++] = max_bw;
}

Would seem more or less OK to me. And doing it this way would also
cover the MyDP 6.75 case automagically.

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vmwgfx: Use VM_PFNMAP instead of VM_MIXEDMAP when possible

[VMware]

From: Thomas Hellstrom 

For shared, and read-only private mappings of graphics memory, use
VM_PFNMAP instead of VM_MIXEDMAP. This means less accounting overhead
when inserting and removing page-table entries. TTM doesn't do this
by default, since there was a performance problem with book-keeping of
write-combined mappings. Since vmwgfx solely uses cached mappings, that's
not a problem and now that the TTM vm has largely been turned into
helpers, we can use VM_PFNMAP on a per-driver basis

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Roland Scheidegger 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index ce288756531b..aa7e50f63b94 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -45,6 +45,10 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
 
vma->vm_ops = &vmw_vm_ops;
 
+   /* Use VM_PFNMAP rather than VM_MIXEDMAP if not a COW mapping */
+   if ((vma->vm_flags & (VM_SHARED | VM_MAYWRITE)) != VM_MAYWRITE)
+   vma->vm_flags = (vma->vm_flags & ~VM_MIXEDMAP) | VM_PFNMAP;
+
return 0;
 }
 
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 0/8] add driver for "boe, tv101wum-nl6", "boe, tv101wum-n53", "auo, kd101n80-45na" and "auo, b101uan08.3" panels

[Jitao Shi]

Changes since v7:
 - base drm-misc-next branch
 - fix document pass dt_binding_check
 - remove backlight from panel driver

Changes since v6:
 - fix boe_panel_init err uninit.
 - adjust the delay of backlight on.

Changes since v5:
 - covert the documents to yaml
 - fine tune boe, tv101wum-n53 panel video timine

Changes since v4:
 - add auo,b101uan08.3 panel for this driver.
 - add boe,tv101wum-n53 panel for this driver.

Changes since v3:
 - remove check enable_gpio.
 - fine tune the auo,kd101n80-45na panel's power on timing.

Changes since v2:
 - correct the panel size
 - remove blank line in Kconfig
 - move auo,kd101n80-45na panel driver in this series.

Changes since v1:
 - update typo nl6 -> n16.
 - update new panel config and makefile are added in alphabetically order.
 - add the panel mode and panel info in driver data.
 - merge auo,kd101n80-45a and boe,tv101wum-nl6 in one driver

Jitao Shi (8):
  dt-bindings: display: panel: Add BOE tv101wum-n16 panel bindings
  drm/panel: support for BOE tv101wum-nl6 wuxga dsi video mode panel
  dt-bindings: display: panel: add auo kd101n80-45na panel bindings
  drm/panel: support for auo,kd101n80-45na wuxga dsi video mode panel
  dt-bindings: display: panel: add boe tv101wum-n53 panel documentation
  drm/panel: support for boe,tv101wum-n53 wuxga dsi video mode panel
  dt-bindings: display: panel: add AUO auo, b101uan08.3 panel
documentation
  drm/panel: support for auo,b101uan08.3 wuxga dsi video mode panel

 .../display/panel/auo,b101uan08.3.yaml|  74 ++
 .../display/panel/auo,kd101n80-45na.yaml  |  74 ++
 .../display/panel/boe,tv101wum-n53.yaml   |  74 ++
 .../display/panel/boe,tv101wum-nl6.yaml   |  74 ++
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 854 ++
 7 files changed, 1160 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
 create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c

-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 7/8] dt-bindings: display: panel: add AUO auo, b101uan08.3 panel documentation

[Jitao Shi]

Add dcumentation for auo,b101uan08.3, which is mipi dsi video panel
and resolution is 1200x1920.

Signed-off-by: Jitao Shi 
---
 .../display/panel/auo,b101uan08.3.yaml| 74 +++
 1 file changed, 74 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml 
b/Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml
new file mode 100644
index ..cafa870120fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,b101uan08.3.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/auo,b101uan08.3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AUO B101UAN08.3 DSI Display Panel
+
+maintainers:
+  - Thierry Reding 
+  - Sam Ravnborg 
+  - Rob Herring 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+const: auo,b101uan08.3
+
+  reg:
+description: the virtual channel number of a DSI peripheral
+
+  enable-gpios:
+description: a GPIO spec for the enable pin
+
+  pp1800-supply:
+description: core voltage supply
+
+  avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+  avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+  backlight:
+description: phandle of the backlight device attached to the panel
+
+  port: true
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+ - backlight
+
+additionalProperties: false
+
+examples:
+  - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "auo,b101uan08.3";
+reg = <0>;
+enable-gpios = <&pio 45 0>;
+avdd-supply = <&ppvarn_lcd>;
+avee-supply = <&ppvarp_lcd>;
+pp1800-supply = <&pp1800_lcd>;
+backlight = <&backlight_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <&dsi_out>;
+};
+};
+};
+};
+
+...
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/trace: Buffer DRM logs in a ringbuffer accessible via debugfs

[Chris Wilson]

Quoting Sean Paul (2020-01-15 13:41:58)
> On Wed, Jan 15, 2020 at 10:36:36AM +, Chris Wilson wrote:
> > Quoting Sean Paul (2020-01-14 17:21:43)
> > > From: Sean Paul 
> > > 
> > > This patch uses a ring_buffer to keep a "flight recorder" (name credit 
> > > Weston)
> > > of DRM logs for a specified set of debug categories. The user writes a
> > > bitmask of debug categories to the "trace_mask" node and can read log
> > > messages from the "trace" node.
> > > 
> > > These nodes currently exist in debugfs under the dri directory. I
> > > intended on exposing all of this through tracefs originally, but the
> > > tracefs entry points are not exposed, so there's no way to create
> > > tracefs files from drivers at the moment. I think it would be a
> > > worthwhile endeavour, but one requiring more time and conversation to
> > > ensure the drm traces fit somewhere sensible.
> > 
> > Fwiw, I have a need for client orientated debug message store, with
> > the primary purpose of figuring out -EINVAL. We need per-client so we can
> > put sensitive information about the potentially buggy client behaviour,
> > and of course it needs to be accessible by the non-privileged client.
> > 
> > On the execution side, it's easy to keep track of the client so we could
> > trace execution flow per client, within reason. And we could do
> > similarly for kms clients.
> 
> Could you build such a thing with drm_trace underpinning it, just put the
> pertinent information in the message?

Not as is. The global has to go, and there's no use for debugfs. So we
are just left with a sprintf() around a ring_buffer. I am left in the
same position as just wanting to generalise tracek to take the ringbuffer
as a parameter.

> > Just chiming to say, I don't think a duplicate of dmesg hidden inside
> > debugfs achieves much. But a generic tracek-esque ringbuf would be very
> > useful -- even if only so we can separate our GEM_TRACE from the global
> > tracek.
> 
> I think that's essentially what we've got, I've just narrowly focused on
> surfacing debug logs. If drm_trace_printf were exported, replacing
> GEM_TRACE would be as simple as s/trace_printk/drm_trace_printf/. Initially I
> thought exporting it to drivers would be a bad idea, but I'm open to changing 
> my
> mind on this as long as drivers are using it responsibly. 

I definitely can't make the mistake of flooding kms tracing with
overwhelming execution traces -- we can't go back to mixing kms traces
with execution traces.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 5/8] dt-bindings: display: panel: add boe tv101wum-n53 panel documentation

[Jitao Shi]

Add dcumentation for boe,tv101wum-n53, which is mipi dsi video panel
and resolution is 1200x1920.

Signed-off-by: Jitao Shi 
---
 .../display/panel/boe,tv101wum-n53.yaml   | 74 +++
 1 file changed, 74 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml 
b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml
new file mode 100644
index ..512ca602998c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-n53.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-n53.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TV101WUM-N53 DSI Display Panel
+
+maintainers:
+  - Thierry Reding 
+  - Sam Ravnborg 
+  - Rob Herring 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+const: boe,tv101wum-n53
+
+  reg:
+description: the virtual channel number of a DSI peripheral
+
+  enable-gpios:
+description: a GPIO spec for the enable pin
+
+  pp1800-supply:
+description: core voltage supply
+
+  avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+  avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+  backlight:
+description: phandle of the backlight device attached to the panel
+
+  port: true
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+ - backlight
+
+additionalProperties: false
+
+examples:
+  - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "boe,tv101wum-n53";
+reg = <0>;
+enable-gpios = <&pio 45 0>;
+avdd-supply = <&ppvarn_lcd>;
+avee-supply = <&ppvarp_lcd>;
+pp1800-supply = <&pp1800_lcd>;
+backlight = <&backlight_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <&dsi_out>;
+};
+};
+};
+};
+
+...
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 4/8] drm/panel: support for auo, kd101n80-45na wuxga dsi video mode panel

[Jitao Shi]

Auo,kd101n80-45na's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So auo,kd101n80-45na and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.

Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/panel/Kconfig |  6 +-
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 64 +--
 2 files changed, 61 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ca727c233a9a..b5413edd625b 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,13 +30,13 @@ config DRM_PANEL_BOE_HIMAX8279D
  the host and has a built-in LED backlight.
 
 config DRM_PANEL_BOE_TV101WUM_NL6
-   tristate "BOE TV101WUM 1200x1920 panel"
+   tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
help
- Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
- DSI Video Mode panel
+ Say Y here if you want to support for BOE TV101WUM and AUO KD101N80
+ 45NA WUXGA PANEL DSI Video Mode panel
 
 config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 793347f51f4b..7f5d064bea69 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -34,6 +34,7 @@ struct panel_desc {
enum mipi_dsi_pixel_format format;
const struct panel_init_cmd *init_cmds;
unsigned int lanes;
+   bool discharge_on_disable;
 };
 
 struct boe_panel {
@@ -367,6 +368,15 @@ static const struct panel_init_cmd boe_init_cmd[] = {
{},
 };
 
+static const struct panel_init_cmd auo_kd101n80_45na_init_cmd[] = {
+   _INIT_DELAY_CMD(24),
+   _INIT_DCS_CMD(0x11),
+   _INIT_DELAY_CMD(120),
+   _INIT_DCS_CMD(0x29),
+   _INIT_DELAY_CMD(120),
+   {},
+};
+
 static inline struct boe_panel *to_boe_panel(struct drm_panel *panel)
 {
return container_of(panel, struct boe_panel, base);
@@ -444,12 +454,22 @@ static int boe_panel_unprepare(struct drm_panel *panel)
}
 
msleep(150);
-   gpiod_set_value(boe->enable_gpio, 0);
-   usleep_range(500, 1000);
-   regulator_disable(boe->avee);
-   regulator_disable(boe->avdd);
-   usleep_range(5000, 7000);
-   regulator_disable(boe->pp1800);
+
+   if (boe->desc->discharge_on_disable) {
+   regulator_disable(boe->avee);
+   regulator_disable(boe->avdd);
+   usleep_range(5000, 7000);
+   gpiod_set_value(boe->enable_gpio, 0);
+   usleep_range(5000, 7000);
+   regulator_disable(boe->pp1800);
+   } else {
+   gpiod_set_value(boe->enable_gpio, 0);
+   usleep_range(500, 1000);
+   regulator_disable(boe->avee);
+   regulator_disable(boe->avdd);
+   usleep_range(5000, 7000);
+   regulator_disable(boe->pp1800);
+   }
 
boe->prepared = false;
 
@@ -542,6 +562,35 @@ static const struct panel_desc boe_tv101wum_nl6_desc = {
.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
  MIPI_DSI_MODE_LPM,
.init_cmds = boe_init_cmd,
+   .discharge_on_disable = false,
+};
+
+static const struct drm_display_mode auo_kd101n80_45na_default_mode = {
+   .clock = 157000,
+   .hdisplay = 1200,
+   .hsync_start = 1200 + 80,
+   .hsync_end = 1200 + 80 + 24,
+   .htotal = 1200 + 80 + 24 + 36,
+   .vdisplay = 1920,
+   .vsync_start = 1920 + 16,
+   .vsync_end = 1920 + 16 + 4,
+   .vtotal = 1920 + 16 + 4 + 16,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc auo_kd101n80_45na_desc = {
+   .modes = &auo_kd101n80_45na_default_mode,
+   .bpc = 8,
+   .size = {
+   .width_mm = 135,
+   .height_mm = 216,
+   },
+   .lanes = 4,
+   .format = MIPI_DSI_FMT_RGB888,
+   .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+   .init_cmds = auo_kd101n80_45na_init_cmd,
+   .discharge_on_disable = true,
 };
 
 static int boe_panel_get_modes(struct drm_panel *panel,
@@ -673,6 +722,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "boe,tv101wum-nl6",
  .data = &boe_tv101wum_nl6_desc
},
+   { .compatible = "auo,kd101n80-45na",
+ .data = &auo_kd101n80_45na_desc
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, boe_of_match);
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 8/8] drm/panel: support for auo, b101uan08.3 wuxga dsi video mode panel

[Jitao Shi]

Auo,auo,b101uan08.3's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So auo,b101uan08.3 and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.

Signed-off-by: Jitao Shi 
Reviewed-by: Sam Ravnborg 
---
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 78 +++
 1 file changed, 78 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 0108bff283c5..51001940eab3 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -377,6 +377,53 @@ static const struct panel_init_cmd 
auo_kd101n80_45na_init_cmd[] = {
{},
 };
 
+static const struct panel_init_cmd auo_b101uan08_3_init_cmd[] = {
+   _INIT_DELAY_CMD(24),
+   _INIT_DCS_CMD(0xB0, 0x01),
+   _INIT_DCS_CMD(0xC0, 0x48),
+   _INIT_DCS_CMD(0xC1, 0x48),
+   _INIT_DCS_CMD(0xC2, 0x47),
+   _INIT_DCS_CMD(0xC3, 0x47),
+   _INIT_DCS_CMD(0xC4, 0x46),
+   _INIT_DCS_CMD(0xC5, 0x46),
+   _INIT_DCS_CMD(0xC6, 0x45),
+   _INIT_DCS_CMD(0xC7, 0x45),
+   _INIT_DCS_CMD(0xC8, 0x64),
+   _INIT_DCS_CMD(0xC9, 0x64),
+   _INIT_DCS_CMD(0xCA, 0x4F),
+   _INIT_DCS_CMD(0xCB, 0x4F),
+   _INIT_DCS_CMD(0xCC, 0x40),
+   _INIT_DCS_CMD(0xCD, 0x40),
+   _INIT_DCS_CMD(0xCE, 0x66),
+   _INIT_DCS_CMD(0xCF, 0x66),
+   _INIT_DCS_CMD(0xD0, 0x4F),
+   _INIT_DCS_CMD(0xD1, 0x4F),
+   _INIT_DCS_CMD(0xD2, 0x41),
+   _INIT_DCS_CMD(0xD3, 0x41),
+   _INIT_DCS_CMD(0xD4, 0x48),
+   _INIT_DCS_CMD(0xD5, 0x48),
+   _INIT_DCS_CMD(0xD6, 0x47),
+   _INIT_DCS_CMD(0xD7, 0x47),
+   _INIT_DCS_CMD(0xD8, 0x46),
+   _INIT_DCS_CMD(0xD9, 0x46),
+   _INIT_DCS_CMD(0xDA, 0x45),
+   _INIT_DCS_CMD(0xDB, 0x45),
+   _INIT_DCS_CMD(0xDC, 0x64),
+   _INIT_DCS_CMD(0xDD, 0x64),
+   _INIT_DCS_CMD(0xDE, 0x4F),
+   _INIT_DCS_CMD(0xDF, 0x4F),
+   _INIT_DCS_CMD(0xE0, 0x40),
+   _INIT_DCS_CMD(0xE1, 0x40),
+   _INIT_DCS_CMD(0xE2, 0x66),
+   _INIT_DCS_CMD(0xE3, 0x66),
+   _INIT_DCS_CMD(0xE4, 0x4F),
+   _INIT_DCS_CMD(0xE5, 0x4F),
+   _INIT_DCS_CMD(0xE6, 0x41),
+   _INIT_DCS_CMD(0xE7, 0x41),
+   _INIT_DELAY_CMD(150),
+   {},
+};
+
 static inline struct boe_panel *to_boe_panel(struct drm_panel *panel)
 {
return container_of(panel, struct boe_panel, base);
@@ -621,6 +668,34 @@ static const struct panel_desc boe_tv101wum_n53_desc = {
.init_cmds = boe_init_cmd,
 };
 
+static const struct drm_display_mode auo_b101uan08_3_default_mode = {
+   .clock = 159667,
+   .hdisplay = 1200,
+   .hsync_start = 1200 + 60,
+   .hsync_end = 1200 + 60 + 4,
+   .htotal = 1200 + 60 + 4 + 80,
+   .vdisplay = 1920,
+   .vsync_start = 1920 + 34,
+   .vsync_end = 1920 + 34 + 2,
+   .vtotal = 1920 + 34 + 2 + 24,
+   .vrefresh = 60,
+   .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const struct panel_desc auo_b101uan08_3_desc = {
+   .modes = &auo_b101uan08_3_default_mode,
+   .bpc = 8,
+   .size = {
+   .width_mm = 135,
+   .height_mm = 216,
+   },
+   .lanes = 4,
+   .format = MIPI_DSI_FMT_RGB888,
+   .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+   .init_cmds = auo_b101uan08_3_init_cmd,
+};
+
 static int boe_panel_get_modes(struct drm_panel *panel,
   struct drm_connector *connector)
 {
@@ -756,6 +831,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "boe,tv101wum-n53",
  .data = &boe_tv101wum_n53_desc
},
+   { .compatible = "auo,b101uan08.3",
+ .data = &auo_b101uan08_3_desc
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, boe_of_match);
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 6/8] drm/panel: support for boe, tv101wum-n53 wuxga dsi video mode panel

[Jitao Shi]

Boe,tv101wum-n53's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So boe,tv101wum-n53 and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.

Signed-off-by: Jitao Shi 
Reviewed-by: Sam Ravnborg 
---
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 7f5d064bea69..0108bff283c5 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -593,6 +593,34 @@ static const struct panel_desc auo_kd101n80_45na_desc = {
.discharge_on_disable = true,
 };
 
+static const struct drm_display_mode boe_tv101wum_n53_default_mode = {
+   .clock = 159916,
+   .hdisplay = 1200,
+   .hsync_start = 1200 + 80,
+   .hsync_end = 1200 + 80 + 24,
+   .htotal = 1200 + 80 + 24 + 40,
+   .vdisplay = 1920,
+   .vsync_start = 1920 + 20,
+   .vsync_end = 1920 + 20 + 4,
+   .vtotal = 1920 + 20 + 4 + 10,
+   .vrefresh = 60,
+   .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const struct panel_desc boe_tv101wum_n53_desc = {
+   .modes = &boe_tv101wum_n53_default_mode,
+   .bpc = 8,
+   .size = {
+   .width_mm = 135,
+   .height_mm = 216,
+   },
+   .lanes = 4,
+   .format = MIPI_DSI_FMT_RGB888,
+   .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+   .init_cmds = boe_init_cmd,
+};
+
 static int boe_panel_get_modes(struct drm_panel *panel,
   struct drm_connector *connector)
 {
@@ -725,6 +753,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "auo,kd101n80-45na",
  .data = &auo_kd101n80_45na_desc
},
+   { .compatible = "boe,tv101wum-n53",
+ .data = &boe_tv101wum_n53_desc
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, boe_of_match);
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 3/8] dt-bindings: display: panel: add auo kd101n80-45na panel bindings

[Jitao Shi]

Add documentation for auo kd101n80-45na panel.

Signed-off-by: Jitao Shi 
Reviewed-by: Sam Ravnborg 
---
 .../display/panel/auo,kd101n80-45na.yaml  | 74 +++
 1 file changed, 74 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml 
b/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml
new file mode 100644
index ..604566832156
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,kd101n80-45na.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/auo,kd101n80-45na.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AUO KD101N80-45NA DSI Display Panel
+
+maintainers:
+  - Thierry Reding 
+  - Sam Ravnborg 
+  - Rob Herring 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+const: auo,kd101n80-45na
+
+  reg:
+description: the virtual channel number of a DSI peripheral
+
+  enable-gpios:
+description: a GPIO spec for the enable pin
+
+  pp1800-supply:
+description: core voltage supply
+
+  avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+  avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+  backlight:
+description: phandle of the backlight device attached to the panel
+
+  port: true
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+ - backlight
+
+additionalProperties: false
+
+examples:
+  - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "auo,kd101n80-45na";
+reg = <0>;
+enable-gpios = <&pio 45 0>;
+avdd-supply = <&ppvarn_lcd>;
+avee-supply = <&ppvarp_lcd>;
+pp1800-supply = <&pp1800_lcd>;
+backlight = <&backlight_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <&dsi_out>;
+};
+};
+};
+};
+
+...
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 2/8] drm/panel: support for BOE tv101wum-nl6 wuxga dsi video mode panel

[Jitao Shi]

Add driver for BOE tv101wum-nl6 panel is a 10.1" 1200x1920 panel.

Signed-off-by: Jitao Shi 
---
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 693 ++
 3 files changed, 703 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ae44ac2ec106..ca727c233a9a 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -29,6 +29,15 @@ config DRM_PANEL_BOE_HIMAX8279D
  24 bit RGB per pixel. It provides a MIPI DSI interface to
  the host and has a built-in LED backlight.
 
+config DRM_PANEL_BOE_TV101WUM_NL6
+   tristate "BOE TV101WUM 1200x1920 panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
+ DSI Video Mode panel
+
 config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 7c4d3c581fd4..a659ce403d0e 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
 obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
+obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += 
panel-feiyang-fy07024di26a30d.o
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
new file mode 100644
index ..793347f51f4b
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -0,0 +1,693 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Jitao Shi 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+struct panel_desc {
+   const struct drm_display_mode *modes;
+   unsigned int bpc;
+
+   /**
+* @width_mm: width of the panel's active display area
+* @height_mm: height of the panel's active display area
+*/
+   struct {
+   unsigned int width_mm;
+   unsigned int height_mm;
+   } size;
+
+   unsigned long mode_flags;
+   enum mipi_dsi_pixel_format format;
+   const struct panel_init_cmd *init_cmds;
+   unsigned int lanes;
+};
+
+struct boe_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   const struct panel_desc *desc;
+
+   struct regulator *pp1800;
+   struct regulator *avee;
+   struct regulator *avdd;
+   struct gpio_desc *enable_gpio;
+
+   bool prepared;
+};
+
+enum dsi_cmd_type {
+   INIT_DCS_CMD,
+   DELAY_CMD,
+};
+
+struct panel_init_cmd {
+   enum dsi_cmd_type type;
+   size_t len;
+   const char *data;
+};
+
+#define _INIT_DCS_CMD(...) { \
+   .type = INIT_DCS_CMD, \
+   .len = sizeof((char[]){__VA_ARGS__}), \
+   .data = (char[]){__VA_ARGS__} }
+
+#define _INIT_DELAY_CMD(...) { \
+   .type = DELAY_CMD,\
+   .len = sizeof((char[]){__VA_ARGS__}), \
+   .data = (char[]){__VA_ARGS__} }
+
+static const struct panel_init_cmd boe_init_cmd[] = {
+   _INIT_DELAY_CMD(24),
+   _INIT_DCS_CMD(0xB0, 0x05),
+   _INIT_DCS_CMD(0xB1, 0xE5),
+   _INIT_DCS_CMD(0xB3, 0x52),
+   _INIT_DCS_CMD(0xB0, 0x00),
+   _INIT_DCS_CMD(0xB3, 0x88),
+   _INIT_DCS_CMD(0xB0, 0x04),
+   _INIT_DCS_CMD(0xB8, 0x00),
+   _INIT_DCS_CMD(0xB0, 0x00),
+   _INIT_DCS_CMD(0xB6, 0x03),
+   _INIT_DCS_CMD(0xBA, 0x8B),
+   _INIT_DCS_CMD(0xBF, 0x1A),
+   _INIT_DCS_CMD(0xC0, 0x0F),
+   _INIT_DCS_CMD(0xC2, 0x0C),
+   _INIT_DCS_CMD(0xC3, 0x02),
+   _INIT_DCS_CMD(0xC4, 0x0C),
+   _INIT_DCS_CMD(0xC5, 0x02),
+   _INIT_DCS_CMD(0xB0, 0x01),
+   _INIT_DCS_CMD(0xE0, 0x26),
+   _INIT_DCS_CMD(0xE1, 0x26),
+   _INIT_DCS_CMD(0xDC, 0x00),
+   _INIT_DCS_CMD(0xDD, 0x00),
+   _INIT_DCS_CMD(0xCC, 0x26),
+   _INIT_DCS_CMD(0xCD, 0x26),
+   _INIT_DCS_CMD(0xC8, 0x00),
+   _INIT_DCS_CMD(0xC9, 0x00),
+   _INIT_DCS_CMD(0xD2, 0x03),
+   _INIT_DCS_CMD(0xD3, 0x03),
+   _INIT_DCS_CMD(0xE6, 0x04),
+   _INIT_DCS_CMD(0xE7, 0x04),
+   _INIT_DCS_CMD(0xC4, 0x09),
+   _INIT_DCS_CMD(0xC5, 0x09),
+   _INIT_DCS_CMD(0xD8, 0x0A),
+   _INIT_DCS_CMD(0xD9, 0x0A),
+   _INIT_DCS_CMD(0xC2, 0x0B),
+   _INIT_DCS_CMD(0xC3, 0x0B),
+   _INIT_DCS_CMD(0xD6, 0x0C),
+   _INIT_DCS_CMD(0xD7, 0x0C),
+   _INIT_DCS_CMD(0xC0, 0x05),
+   _INIT_DCS_CMD(0xC1, 0x05),
+   _INIT_DCS_C

[PATCH v8 1/8] dt-bindings: display: panel: Add BOE tv101wum-n16 panel bindings

[Jitao Shi]

Add documentation for boe tv101wum-n16 panel.

Signed-off-by: Jitao Shi 
Reviewed-by: Sam Ravnborg 
---
 .../display/panel/boe,tv101wum-nl6.yaml   | 74 +++
 1 file changed, 74 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml 
b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
new file mode 100644
index ..d38aee22d406
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-nl6.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TV101WUM-Nl6 DSI Display Panel
+
+maintainers:
+  - Thierry Reding 
+  - Sam Ravnborg 
+  - Rob Herring 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+const: boe,tv101wum-nl6
+
+  reg:
+description: the virtual channel number of a DSI peripheral
+
+  enable-gpios:
+description: a GPIO spec for the enable pin
+
+  pp1800-supply:
+description: core voltage supply
+
+  avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+  avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+  backlight:
+description: phandle of the backlight device attached to the panel
+
+  port: true
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+ - backlight
+
+additionalProperties: false
+
+examples:
+  - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "boe,tv101wum-nl6";
+reg = <0>;
+enable-gpios = <&pio 45 0>;
+avdd-supply = <&ppvarn_lcd>;
+avee-supply = <&ppvarp_lcd>;
+pp1800-supply = <&pp1800_lcd>;
+backlight = <&backlight_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <&dsi_out>;
+};
+};
+};
+};
+
+...
-- 
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/trace: Buffer DRM logs in a ringbuffer accessible via debugfs

[Sean Paul]

On Wed, Jan 15, 2020 at 10:36:36AM +, Chris Wilson wrote:
> Quoting Sean Paul (2020-01-14 17:21:43)
> > From: Sean Paul 
> > 
> > This patch uses a ring_buffer to keep a "flight recorder" (name credit 
> > Weston)
> > of DRM logs for a specified set of debug categories. The user writes a
> > bitmask of debug categories to the "trace_mask" node and can read log
> > messages from the "trace" node.
> > 
> > These nodes currently exist in debugfs under the dri directory. I
> > intended on exposing all of this through tracefs originally, but the
> > tracefs entry points are not exposed, so there's no way to create
> > tracefs files from drivers at the moment. I think it would be a
> > worthwhile endeavour, but one requiring more time and conversation to
> > ensure the drm traces fit somewhere sensible.
> 
> Fwiw, I have a need for client orientated debug message store, with
> the primary purpose of figuring out -EINVAL. We need per-client so we can
> put sensitive information about the potentially buggy client behaviour,
> and of course it needs to be accessible by the non-privileged client.
> 
> On the execution side, it's easy to keep track of the client so we could
> trace execution flow per client, within reason. And we could do
> similarly for kms clients.

Could you build such a thing with drm_trace underpinning it, just put the
pertinent information in the message?

> 
> Just chiming to say, I don't think a duplicate of dmesg hidden inside
> debugfs achieves much. But a generic tracek-esque ringbuf would be very
> useful -- even if only so we can separate our GEM_TRACE from the global
> tracek.

I think that's essentially what we've got, I've just narrowly focused on
surfacing debug logs. If drm_trace_printf were exported, replacing
GEM_TRACE would be as simple as s/trace_printk/drm_trace_printf/. Initially I
thought exporting it to drivers would be a bad idea, but I'm open to changing my
mind on this as long as drivers are using it responsibly. 

Sean

> -Chris

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/trace: Buffer DRM logs in a ringbuffer accessible via debugfs

[Sean Paul]

On Wed, Jan 15, 2020 at 12:28:31PM +0200, Jani Nikula wrote:
> On Tue, 14 Jan 2020, Sean Paul  wrote:
> > From: Sean Paul 
> >
> > This patch uses a ring_buffer to keep a "flight recorder" (name credit 
> > Weston)
> > of DRM logs for a specified set of debug categories. The user writes a
> > bitmask of debug categories to the "trace_mask" node and can read log
> > messages from the "trace" node.
> >
> > These nodes currently exist in debugfs under the dri directory. I
> > intended on exposing all of this through tracefs originally, but the
> > tracefs entry points are not exposed, so there's no way to create
> > tracefs files from drivers at the moment. I think it would be a
> > worthwhile endeavour, but one requiring more time and conversation to
> > ensure the drm traces fit somewhere sensible.
> >
> > Cc: Daniel Vetter 
> > Cc: David Airlie 
> > Cc: Jani Nikula 
> > Cc: Joonas Lahtinen 
> > Cc: Pekka Paalanen 
> > Cc: Rob Clark 
> > Cc: Steven Rostedt 
> > Cc: Thomas Zimmermann 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Sean Paul 
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20191010204823.195540-1-s...@poorly.run
> >  #v1
> > Link: 
> > https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html 
> > #v2
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20191212203301.142437-1-s...@poorly.run
> >  #v3
> >
> > Changes in v2:
> > - Went with a completely different approach:
> > https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html
> >
> > Changes in v3:
> > - Changed commit message to be a bit less RFC-y
> > - Make class_drm_category_log an actual trace class
> >
> > Changes in v4:
> > - Instead of [ab]using trace events and the system trace buffer, use our
> >   own ringbuffer
> > ---
> > ---
> >  Documentation/gpu/drm-uapi.rst |   9 +
> >  drivers/gpu/drm/Kconfig|   1 +
> >  drivers/gpu/drm/Makefile   |   2 +-
> >  drivers/gpu/drm/drm_drv.c  |   3 +
> >  drivers/gpu/drm/drm_print.c|  80 +--
> >  drivers/gpu/drm/drm_trace.c| 376 +
> >  include/drm/drm_print.h|  39 
> >  7 files changed, 487 insertions(+), 23 deletions(-)
> >  create mode 100644 drivers/gpu/drm/drm_trace.c
> >
> > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > index 56fec6ed1ad8..089eb6fd3e94 100644
> > --- a/Documentation/gpu/drm-uapi.rst
> > +++ b/Documentation/gpu/drm-uapi.rst
> > @@ -312,6 +312,15 @@ Debugfs Support
> >  .. kernel-doc:: drivers/gpu/drm/drm_debugfs.c
> > :export:
> >  
> > +DRM Tracing
> > +---
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_trace.c
> > +   :doc: DRM Tracing
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_trace.c
> > +   :internal:
> > +
> >  Sysfs Support
> >  =
> >  
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index d0aa6cff2e02..9d8077e87afe 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -14,6 +14,7 @@ menuconfig DRM
> > select I2C
> > select I2C_ALGOBIT
> > select DMA_SHARED_BUFFER
> > +   select RING_BUFFER
> > select SYNC_FILE
> > help
> >   Kernel-level support for the Direct Rendering Infrastructure (DRI)
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 6493088a0fdd..88b4674934e6 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -29,7 +29,7 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> >  drm-$(CONFIG_OF) += drm_of.o
> >  drm-$(CONFIG_AGP) += drm_agpsupport.o
> >  drm-$(CONFIG_PCI) += drm_pci.o
> > -drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> > +drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o drm_trace.o
> >  drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> >  
> >  drm_vram_helper-y := drm_gem_vram_helper.o \
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 7c18a980cd4b..98260b9f8004 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -1114,6 +1114,7 @@ static const struct file_operations drm_stub_fops = {
> >  static void drm_core_exit(void)
> >  {
> > unregister_chrdev(DRM_MAJOR, "drm");
> > +   drm_trace_cleanup();
> > debugfs_remove(drm_debugfs_root);
> > drm_sysfs_destroy();
> > idr_destroy(&drm_minors_idr);
> > @@ -1135,6 +1136,8 @@ static int __init drm_core_init(void)
> >  
> > drm_debugfs_root = debugfs_create_dir("dri", NULL);
> >  
> > +   WARN_ON(drm_trace_init(drm_debugfs_root));
> > +
> > ret = register_chrdev(DRM_MAJOR, "drm", &drm_stub_fops);
> > if (ret < 0)
> > goto error;
> > diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> > index 111b932cf2a9..0ac1867937bf 100644
> > --- a/drivers/gpu/drm/drm_print.c
> > +++ b/drivers/gpu/drm/drm_print.c
> > @@ -262,21 +262,37 @@ void drm_dev_dbg(const struct device *dev, enum 
> > drm_debug_category category,
> > struct va_format vaf;

Re: [PATCH][RESEND] video: hyperv_fb: Fix hibernation for the deferred IO feature

[Bartlomiej Zolnierkiewicz]

On 1/11/20 5:29 PM, Sasha Levin wrote:
> On Mon, Jan 06, 2020 at 02:41:51PM -0800, Dexuan Cui wrote:
>> fb_deferred_io_work() can access the vmbus ringbuffer by calling
>> fbdefio->deferred_io() -> synthvid_deferred_io() -> synthvid_update().
>>
>> Because the vmbus ringbuffer is inaccessible between hvfb_suspend()
>> and hvfb_resume(), we must cancel info->deferred_work before calling
>> vmbus_close() and then reschedule it after we reopen the channel
>> in hvfb_resume().
>>
>> Fixes: a4ddb11d297e ("video: hyperv: hyperv_fb: Support deferred IO for 
>> Hyper-V frame buffer driver")
>> Fixes: 824946a8b6fb ("video: hyperv_fb: Add the support of hibernation")
>> Signed-off-by: Dexuan Cui 
>> Reviewed-by: Wei Hu 
>> ---
>>
>> This is a RESEND of 
>> https://protect2.fireeye.com/url?k=a9db9902-f41598d1-a9da124d-000babff317b-c1ee475745c278a5&u=https://lkml.org/lkml/2019/11/20/73
>>  .
>>
>> The only change is the addition of Wei's Review-ed-by.
>>
>> Please review.
>>
>> If it looks good, Sasha Levin, can you please pick it up via the
>> hyperv/linux.git tree, as you did last time for this driver?
> 
> Like with the input driver, if the relevant maintainers here are okay
> with this type of patches going through the hyperv tree I'll be happy to
> do it, otherwise I need an explicit ack from them on this patch.

Yes, I'm fine with hyperv_fb driver patches going through hyperv tree.

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/trace: Buffer DRM logs in a ringbuffer accessible via debugfs

[Sean Paul]

On Wed, Jan 15, 2020 at 12:14:50PM +0200, Pekka Paalanen wrote:
> On Tue, 14 Jan 2020 12:21:43 -0500
> Sean Paul  wrote:
> 
> > From: Sean Paul 
> > 
> > This patch uses a ring_buffer to keep a "flight recorder" (name credit 
> > Weston)
> > of DRM logs for a specified set of debug categories. The user writes a
> > bitmask of debug categories to the "trace_mask" node and can read log
> > messages from the "trace" node.
> > 
> > These nodes currently exist in debugfs under the dri directory. I
> > intended on exposing all of this through tracefs originally, but the
> > tracefs entry points are not exposed, so there's no way to create
> > tracefs files from drivers at the moment. I think it would be a
> > worthwhile endeavour, but one requiring more time and conversation to
> > ensure the drm traces fit somewhere sensible.
> > 
> > Cc: Daniel Vetter 
> > Cc: David Airlie 
> > Cc: Jani Nikula 
> > Cc: Joonas Lahtinen 
> > Cc: Pekka Paalanen 
> > Cc: Rob Clark 
> > Cc: Steven Rostedt 
> > Cc: Thomas Zimmermann 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Sean Paul 
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20191010204823.195540-1-s...@poorly.run
> >  #v1
> > Link: 
> > https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html 
> > #v2
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20191212203301.142437-1-s...@poorly.run
> >  #v3
> > 
> > Changes in v2:
> > - Went with a completely different approach:
> > https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html
> > 
> > Changes in v3:
> > - Changed commit message to be a bit less RFC-y
> > - Make class_drm_category_log an actual trace class
> > 
> > Changes in v4:
> > - Instead of [ab]using trace events and the system trace buffer, use our
> >   own ringbuffer
> > ---
> > ---
> >  Documentation/gpu/drm-uapi.rst |   9 +
> >  drivers/gpu/drm/Kconfig|   1 +
> >  drivers/gpu/drm/Makefile   |   2 +-
> >  drivers/gpu/drm/drm_drv.c  |   3 +
> >  drivers/gpu/drm/drm_print.c|  80 +--
> >  drivers/gpu/drm/drm_trace.c| 376 +
> >  include/drm/drm_print.h|  39 
> >  7 files changed, 487 insertions(+), 23 deletions(-)
> >  create mode 100644 drivers/gpu/drm/drm_trace.c
> 
> ...
> 
> > +/**
> > + * DOC: DRM Tracing
> > + *
> > + * *tl;dr* DRM tracing is a lightweight alternative to traditional DRM 
> > debug
> > + * logging.
> > + *
> > + * While DRM logging is quite convenient when reproducing a specific 
> > issue, it
> > + * doesn't help when something goes wrong unexpectedly. There are a couple
> > + * reasons why one does not want to enable DRM logging at all times:
> > + *
> > + * 1. We don't want to overwhelm syslog with drm spam, others have to use 
> > it too
> > + * 2. Console logging is slow
> > + *
> > + * DRM tracing aims to solve both these problems.
> > + *
> > + * To use DRM tracing, write a DRM debug category mask (this is a bitmask 
> > of
> > + * &drm_debug_category values) to the trace_mask file:
> > + * ::
> > + *
> > + *eg: echo 0x106 > /sys/kernel/debug/dri/trace_mask
> > + *
> > + * Once active, all log messages in the specified categories will be 
> > written to
> > + * the DRM trace. Once at capacity, the trace will overwrite old messages 
> > with
> > + * new ones. At any point, one can read the trace file to extract the 
> > previous N
> > + * DRM messages:
> > + * ::
> > + *
> > + *eg: cat /sys/kernel/debug/dri/trace
> > + *
> > + * Considerations
> > + * **
> > + * The contents of the DRM Trace are **not** considered UABI. **DO NOT 
> > depend on
> > + * the values of these traces in your userspace.** These traces are 
> > intended for
> > + * entertainment purposes only. The contents of these logs carry no 
> > warranty,
> > + * expressed or implied.
> > + *
> > + * New traces can not be added to the trace buffer while it is being read. 
> > If
> > + * this proves to be a problem, it can be mitigated by making a copy of the
> > + * buffer on start of read. Since DRM trace is not meant to be continuously
> > + * read, this loss is acceptable.
> > + *
> > + * The timestamps on logs are CPU-local. As such, log messages from 
> > different
> > + * CPUs may have slightly different ideas about time.
> > + *
> > + * Since each CPU has its own buffer, they won't all overflow at the same 
> > rate.
> > + * This means that messages from a particularly active CPU could be dropped
> > + * while an inactive CPU might have much older log messages. So don't be 
> > fooled
> > + * if you seem to be missing log messages when you see a switch between 
> > CPUs in
> > + * the logs.
> > + *
> > + * Internals
> > + * *
> > + * The DRM Tracing functions are intentionally unexported, they are not 
> > meant to
> > + * be used by drivers directly. The reasons are twofold:
> > + *
> > + * 1. All messages going to traces should also go to the console logs. This
> > + *ensures users can choose their loggi

Re: [PATCH] drm/amdgpu: flush the fence on the bo after we individualize

[Christian König]

Am 15.01.20 um 07:26 schrieb Pan, Xinhui:

As we move the ttm_bo_individualize_resv() upwards, we need flush the
copied fence too. Otherwise the driver keeps waiting for fence.

run&Kill kfdtest, then perf top.

   25.53%  [ttm] [k] ttm_bo_delayed_delete
   24.29%  [kernel]  [k] dma_resv_test_signaled_rcu
   19.72%  [kernel]  [k] ww_mutex_lock

Fix: 378e2d5b("drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more")
Signed-off-by: xinhui pan 


That's indeed a rather nice idea. Reviewed-by: Christian König 



I'm going to pick that up for inclusion in drm-misc-next. Please send 
TTM patches also to the dri-devel mailing list in the future.


Christian.


---
  drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 8d91b0428af1..1494aebb8128 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -499,8 +499,10 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
  
  		dma_resv_unlock(bo->base.resv);

}
-   if (bo->base.resv != &bo->base._resv)
+   if (bo->base.resv != &bo->base._resv) {
+   ttm_bo_flush_all_fences(bo);
dma_resv_unlock(&bo->base._resv);
+   }
  
  error:

kref_get(&bo->list_kref);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fbdev: potential information leak in do_fb_ioctl()

[Arnd Bergmann]

On Wed, Jan 15, 2020 at 2:09 PM Bartlomiej Zolnierkiewicz
 wrote:

> > $ git grep -wl register_framebuffer | xargs grep -L framebuffer_alloc
> > Documentation/fb/framebuffer.rst
> > drivers/media/pci/ivtv/ivtvfb.c
> > drivers/media/platform/vivid/vivid-osd.c
> > drivers/video/fbdev/68328fb.c
> > drivers/video/fbdev/acornfb.c
> > drivers/video/fbdev/amba-clcd.c
> > drivers/video/fbdev/atafb.c
> > drivers/video/fbdev/au1100fb.c
> > drivers/video/fbdev/controlfb.c
> > drivers/video/fbdev/core/fbmem.c
> > drivers/video/fbdev/cyber2000fb.c
> > drivers/video/fbdev/fsl-diu-fb.c
> > drivers/video/fbdev/g364fb.c
> > drivers/video/fbdev/goldfishfb.c
> > drivers/video/fbdev/hpfb.c
> > drivers/video/fbdev/macfb.c
> > drivers/video/fbdev/matrox/matroxfb_base.c
> > drivers/video/fbdev/matrox/matroxfb_crtc2.c
> > drivers/video/fbdev/maxinefb.c
> > drivers/video/fbdev/ocfb.c
> > drivers/video/fbdev/pxafb.c
> > drivers/video/fbdev/sa1100fb.c
> > drivers/video/fbdev/stifb.c
> > drivers/video/fbdev/valkyriefb.c
> > drivers/video/fbdev/vermilion/vermilion.c
> > drivers/video/fbdev/vt8500lcdfb.c
> > drivers/video/fbdev/wm8505fb.c
> > drivers/video/fbdev/xilinxfb.c
> >
> > It's possible (even likely, the ones I looked at are fine) that they
> > all correctly
> > zero out the fb_info structure first, but it seems hard to guarantee, so
> > Eric's suggestion would possibly still be the safer choice.
>
> I've audited all above instances and they are all fine. They either
> use the fb_info structure embedded in a driver specific structure
> (which is zeroed out) or (in case of some m68k specific drivers) use
> a static fb_info instance.
>
> Since fbdev is closed for new drivers it should be now fine to use
> the simpler approach (just use memcpy()).

Yes, let's do that then. The complex approach seems more likely
to introduce a bug than one of the existing drivers to stop initializing
the structure correctly.

  Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fbdev: potential information leak in do_fb_ioctl()

[Bartlomiej Zolnierkiewicz]

On 1/13/20 1:49 PM, Arnd Bergmann wrote:
> On Fri, Jan 3, 2020 at 2:09 PM Bartlomiej Zolnierkiewicz
>  wrote:
>> On 10/29/19 8:02 PM, Eric W. Biederman wrote:
>>>
>>> The goal is to avoid memory that has values of the previous users of
>>> that memory region from leaking to userspace.  Which depending on who
>>> the previous user of that memory region is could tell userspace
>>> information about what the kernel is doing that it should not be allowed
>>> to find out.
>>>
>>> I tried to trace through where "info" and thus presumably "info->fix" is
>>> coming from and only made it as far as  register_framebuffer.  Given
>>
>> "info" (and thus "info->fix") comes from framebuffer_alloc() (which is
>> called by fbdev device drivers prior to registering "info" with
>> register_framebuffer()). framebuffer_alloc() does kzalloc() on "info".
>>
>> Therefore shouldn't memcpy() (as suggested by Jeo Perches) be enough?
> 
> Is it guaranteed that all drivers call framebuffer_alloc() rather than
> open-coding it somewhere?
> 
> Here is a list of all files that call register_framebuffer() without first
> calling framebuffer_alloc:
> 
> $ git grep -wl register_framebuffer | xargs grep -L framebuffer_alloc
> Documentation/fb/framebuffer.rst
> drivers/media/pci/ivtv/ivtvfb.c
> drivers/media/platform/vivid/vivid-osd.c
> drivers/video/fbdev/68328fb.c
> drivers/video/fbdev/acornfb.c
> drivers/video/fbdev/amba-clcd.c
> drivers/video/fbdev/atafb.c
> drivers/video/fbdev/au1100fb.c
> drivers/video/fbdev/controlfb.c
> drivers/video/fbdev/core/fbmem.c
> drivers/video/fbdev/cyber2000fb.c
> drivers/video/fbdev/fsl-diu-fb.c
> drivers/video/fbdev/g364fb.c
> drivers/video/fbdev/goldfishfb.c
> drivers/video/fbdev/hpfb.c
> drivers/video/fbdev/macfb.c
> drivers/video/fbdev/matrox/matroxfb_base.c
> drivers/video/fbdev/matrox/matroxfb_crtc2.c
> drivers/video/fbdev/maxinefb.c
> drivers/video/fbdev/ocfb.c
> drivers/video/fbdev/pxafb.c
> drivers/video/fbdev/sa1100fb.c
> drivers/video/fbdev/stifb.c
> drivers/video/fbdev/valkyriefb.c
> drivers/video/fbdev/vermilion/vermilion.c
> drivers/video/fbdev/vt8500lcdfb.c
> drivers/video/fbdev/wm8505fb.c
> drivers/video/fbdev/xilinxfb.c
> 
> It's possible (even likely, the ones I looked at are fine) that they
> all correctly
> zero out the fb_info structure first, but it seems hard to guarantee, so
> Eric's suggestion would possibly still be the safer choice.

I've audited all above instances and they are all fine. They either
use the fb_info structure embedded in a driver specific structure
(which is zeroed out) or (in case of some m68k specific drivers) use
a static fb_info instance.

Since fbdev is closed for new drivers it should be now fine to use
the simpler approach (just use memcpy()).
 
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/4] Use no_vblank property for drivers without VBLANK

[Hans de Goede]

Hi,

On 15-01-2020 13:52, Thomas Zimmermann wrote:

(Resending because I did not cc dri-devel properly.)

Instead of faking VBLANK events by themselves, drivers without VBLANK
support can enable drm_crtc_vblank.no_vblank and let DRM do the rest.
The patchset makes this official and converts over several drivers.

Ast already uses the functionality and just needs a cleanup. Cirrus can
be converted easily by setting the field in the check() callback and
removing the existing VBLANK code. For most other simple-KMS drivers
without enable_vblank() and check(), simple-KMS helpers can enable the
faked VBLANK by default. The only exception is Xen, which comes with
its own VBLANK logic and should rather to disable no_vblank.

v2:
* document functionality (Daniel)
* cleanup ast (Daniel)
* let simple-kms handle no_vblank where possible


Entire series looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans





Thomas Zimmermann (4):
   drm: Document struct drm_crtc_state.no_vblank for faking VBLANK events
   drm/ast: Set struct drm_crtc_state.no_vblank in atomic_check()
   drm/cirrus: Let DRM core send VBLANK events
   drm/simple-kms: Let DRM core send VBLANK events by default

  drivers/gpu/drm/ast/ast_mode.c  |  4 ++--
  drivers/gpu/drm/bochs/bochs_kms.c   |  9 -
  drivers/gpu/drm/cirrus/cirrus.c | 10 ++
  drivers/gpu/drm/drm_atomic_helper.c |  4 +++-
  drivers/gpu/drm/drm_mipi_dbi.c  |  9 -
  drivers/gpu/drm/drm_simple_kms_helper.c | 19 +++
  drivers/gpu/drm/tiny/gm12u320.c |  9 -
  drivers/gpu/drm/tiny/ili9225.c  |  9 -
  drivers/gpu/drm/tiny/repaper.c  |  9 -
  drivers/gpu/drm/tiny/st7586.c   |  9 -
  drivers/gpu/drm/udl/udl_modeset.c   | 11 ---
  drivers/gpu/drm/xen/xen_drm_front_kms.c | 13 +
  include/drm/drm_crtc.h  |  9 +++--
  include/drm/drm_simple_kms_helper.h |  7 +--
  14 files changed, 47 insertions(+), 84 deletions(-)

--
2.24.1



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 resend/trivial] drm/bridge: ti-tfp410: Update drm_connector_init_with_ddc() error message

[Geert Uytterhoeven]

The code was changed to call drm_connector_init_with_ddc() instead of
drm_connector_init(), but the corresponding error message was not
updated.

Fixes: cfb444552926989f ("drm/bridge: ti-tfp410: Provide ddc symlink in 
connector sysfs directory")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Neil Armstrong 
---
v2:
  - Add Reviewed-by.
---
 drivers/gpu/drm/bridge/ti-tfp410.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
b/drivers/gpu/drm/bridge/ti-tfp410.c
index 6f6d6d1e60ae9162..f195a4732e0badac 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -140,7 +140,8 @@ static int tfp410_attach(struct drm_bridge *bridge)
  dvi->connector_type,
  dvi->ddc);
if (ret) {
-   dev_err(dvi->dev, "drm_connector_init() failed: %d\n", ret);
+   dev_err(dvi->dev, "drm_connector_init_with_ddc() failed: %d\n",
+   ret);
return ret;
}
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: TTM or vmwgfx tree? Re: [PATCH v5 0/2] mm, drm/ttm: Fix pte insertion with customized protection

[Christian König]

Am 15.01.20 um 13:45 schrieb Thomas Hellström (VMware):

Hi Christian,

On 1/15/20 1:41 PM, Thomas Hellström (VMware) wrote:

From: Thomas Hellstrom 

The drm/ttm module is using a modified on-stack copy of the
struct vm_area_struct to be able to set a page protection with 
customized

caching. Fix that by adding a vmf_insert_mixed_prot() function similar
to the existing vmf_insert_pfn_prot() for use with drm/ttm.

Patches are acked to be merged through a drm tree.


This small patchset should be ready to be merged now, with acks from 
Andrew.


Do you want to take it through the ttm tree, or should I ask Dave / 
Daniel to pull it separately?


Note that similar to the vmwgfx coherent patches, Linus has indicated 
that he wants separate pull requests for stuff like this that touches mm.


Better ask Dave in this case or merge through drm-misc-next. The later 
is where I push all those little cross driver cleanup patches recently 
and that seems to work fine.


Regards,
Christian.



Thanks,

Thomas




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/4] drm: Document struct drm_crtc_state.no_vblank for faking VBLANK events

[Thomas Zimmermann]

Drivers for CRTC hardware without support for VBLANK interrupts can set
struct drm_crtc_state.no_vblank and let DRM's atomic commit helpers
generate the VBLANK events automatically. Document this in order to make
it official.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
 include/drm/drm_crtc.h  | 9 +++--
 include/drm/drm_simple_kms_helper.h | 7 +--
 3 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 4511c2e07bb9..ce30a37971e4 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2215,7 +2215,9 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_dependencies);
  * when a job is queued, and any change to the pipeline that does not touch the
  * connector is leading to timeouts when calling
  * drm_atomic_helper_wait_for_vblanks() or
- * drm_atomic_helper_wait_for_flip_done().
+ * drm_atomic_helper_wait_for_flip_done(). In addition to writeback
+ * connectors, this function can also fake VBLANK events for CRTCs without
+ * VBLANK interrupt.
  *
  * This is part of the atomic helper support for nonblocking commits, see
  * drm_atomic_helper_setup_commit() for an overview.
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5e9b15a0e8c5..01caf5160596 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -179,7 +179,9 @@ struct drm_crtc_state {
 * In this case the VBLANK event is only generated when a job is queued
 * to the writeback connector, and we want the core to fake VBLANK
 * events when this part of the pipeline hasn't changed but others had
-* or when the CRTC and connectors are being disabled.
+* or when the CRTC and connectors are being disabled. In addition to
+* writeback connectors, this function can also fake VBLANK events for
+* CRTCs without VBLANK interrupt.
 *
 * __drm_atomic_helper_crtc_duplicate_state() will not reset the value
 * from the current state, the CRTC driver is then responsible for
@@ -335,7 +337,10 @@ struct drm_crtc_state {
 *  - Events for disabled CRTCs are not allowed, and drivers can ignore
 *that case.
 *
-* This can be handled by the drm_crtc_send_vblank_event() function,
+* For very simple hardware without VBLANK interrupt, enabling
+* &struct drm_crtc_state.no_vblank makes DRM's atomic commit helpers
+* send the event at an appropriate time. For more complex hardware this
+* can be handled by the drm_crtc_send_vblank_event() function,
 * which the driver should call on the provided event upon completion of
 * the atomic commit. Note that if the driver supports vblank signalling
 * and timestamping the vblank counters and timestamps must agree with
diff --git a/include/drm/drm_simple_kms_helper.h 
b/include/drm/drm_simple_kms_helper.h
index 15afee9cf049..e253ba7bea9d 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -100,8 +100,11 @@ struct drm_simple_display_pipe_funcs {
 * This is the function drivers should submit the
 * &drm_pending_vblank_event from. Using either
 * drm_crtc_arm_vblank_event(), when the driver supports vblank
-* interrupt handling, or drm_crtc_send_vblank_event() directly in case
-* the hardware lacks vblank support entirely.
+* interrupt handling, or drm_crtc_send_vblank_event() for more
+* complex case. In case the hardware lacks vblank support entirely,
+* drivers can set &struct drm_crtc_state.no_vblank in
+* &struct drm_simple_display_pipe_funcs.check and let DRM's
+* atomic helper fake a vblank event.
 */
void (*update)(struct drm_simple_display_pipe *pipe,
   struct drm_plane_state *old_plane_state);
-- 
2.24.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/4] drm/ast: Set struct drm_crtc_state.no_vblank in atomic_check()

[Thomas Zimmermann]

CRTC state properties should be computed in atomic_check(). Do so for
the no_vblank field.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_mode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 34608f0499eb..ef7a0b08cc05 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -800,6 +800,8 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc 
*crtc,
return -EINVAL;
}
 
+   state->no_vblank = true;
+
ast_state = to_ast_crtc_state(state);
 
format = ast_state->format;
@@ -833,8 +835,6 @@ static void ast_crtc_helper_atomic_flush(struct drm_crtc 
*crtc,
struct ast_vbios_mode_info *vbios_mode_info;
struct drm_display_mode *adjusted_mode;
 
-   crtc->state->no_vblank = true;
-
ast_state = to_ast_crtc_state(crtc->state);
 
format = ast_state->format;
-- 
2.24.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/4] drm/simple-kms: Let DRM core send VBLANK events by default

[Thomas Zimmermann]

In drm_atomic_helper_fake_vblank() the DRM core sends out VBLANK events
if struct drm_crtc_state.no_vblank is enabled in the check() callbacks.

For drivers that have neither an enable_vblank() callback nor a check()
callback, the simple-KMS helpers enable VBLANK generation by default. This
simplifies bochs, udl, several tiny drivers, and drivers based upon MIPI
DPI helpers. The driver for Xen explicitly disables no_vblank, as it has
its own logic for sending these events.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/bochs/bochs_kms.c   |  9 -
 drivers/gpu/drm/drm_mipi_dbi.c  |  9 -
 drivers/gpu/drm/drm_simple_kms_helper.c | 19 +++
 drivers/gpu/drm/tiny/gm12u320.c |  9 -
 drivers/gpu/drm/tiny/ili9225.c  |  9 -
 drivers/gpu/drm/tiny/repaper.c  |  9 -
 drivers/gpu/drm/tiny/st7586.c   |  9 -
 drivers/gpu/drm/udl/udl_modeset.c   | 11 ---
 drivers/gpu/drm/xen/xen_drm_front_kms.c | 13 +
 9 files changed, 28 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 3f0006c2470d..ff275faee88d 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "bochs.h"
 
@@ -57,16 +56,8 @@ static void bochs_pipe_update(struct drm_simple_display_pipe 
*pipe,
  struct drm_plane_state *old_state)
 {
struct bochs_device *bochs = pipe->crtc.dev->dev_private;
-   struct drm_crtc *crtc = &pipe->crtc;
 
bochs_plane_update(bochs, pipe->plane.state);
-
-   if (crtc->state->event) {
-   spin_lock_irq(&crtc->dev->event_lock);
-   drm_crtc_send_vblank_event(crtc, crtc->state->event);
-   crtc->state->event = NULL;
-   spin_unlock_irq(&crtc->dev->event_lock);
-   }
 }
 
 static const struct drm_simple_display_pipe_funcs bochs_pipe_funcs = {
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 16bff1be4b8a..13b753cb3f67 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -24,7 +24,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define MIPI_DBI_MAX_SPI_READ_SPEED 200 /* 2MHz */
@@ -299,18 +298,10 @@ void mipi_dbi_pipe_update(struct drm_simple_display_pipe 
*pipe,
  struct drm_plane_state *old_state)
 {
struct drm_plane_state *state = pipe->plane.state;
-   struct drm_crtc *crtc = &pipe->crtc;
struct drm_rect rect;
 
if (drm_atomic_helper_damage_merged(old_state, state, &rect))
mipi_dbi_fb_dirty(state->fb, &rect);
-
-   if (crtc->state->event) {
-   spin_lock_irq(&crtc->dev->event_lock);
-   drm_crtc_send_vblank_event(crtc, crtc->state->event);
-   spin_unlock_irq(&crtc->dev->event_lock);
-   crtc->state->event = NULL;
-   }
 }
 EXPORT_SYMBOL(mipi_dbi_pipe_update);
 
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 15fb516ae2d8..4414c7a5b2ce 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -146,10 +146,21 @@ static int drm_simple_kms_plane_atomic_check(struct 
drm_plane *plane,
if (!plane_state->visible)
return 0;
 
-   if (!pipe->funcs || !pipe->funcs->check)
-   return 0;
-
-   return pipe->funcs->check(pipe, plane_state, crtc_state);
+   if (pipe->funcs) {
+   if (pipe->funcs->check)
+   return pipe->funcs->check(pipe, plane_state,
+ crtc_state);
+   if (pipe->funcs->enable_vblank)
+   return 0;
+   }
+
+   /* Drivers without VBLANK support have to fake VBLANK events. As
+* there's no check() callback to enable this, set the no_vblank
+* field by default.
+*/
+   crtc_state->no_vblank = true;
+
+   return 0;
 }
 
 static void drm_simple_kms_plane_atomic_update(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
index 94fb1f593564..a48173441ae0 100644
--- a/drivers/gpu/drm/tiny/gm12u320.c
+++ b/drivers/gpu/drm/tiny/gm12u320.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 
 static bool eco_mode;
 module_param(eco_mode, bool, 0644);
@@ -610,18 +609,10 @@ static void gm12u320_pipe_update(struct 
drm_simple_display_pipe *pipe,
 struct drm_plane_state *old_state)
 {
struct drm_plane_state *state = pipe->plane.state;
-   struct drm_crtc *crtc = &pipe->crtc;
struct drm_rect rect;
 
if (drm_atomic_helper_damage_merged(old_state, state, &rect))
gm12u320_fb_mark_dirty(pipe->plane.state->fb, &rect);
-

[PATCH v2 3/4] drm/cirrus: Let DRM core send VBLANK events

[Thomas Zimmermann]

In drm_atomic_helper_fake_vblank(), the DRM core sends out VBLANK
events if struct drm_crtc_state.no_vblank is enabled. Replace cirrus'
VBLANK events with the DRM core's functionality.

v2:
* set struct_drm_crtc_state.no_vblank in cirrus_pipe_check()

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/cirrus/cirrus.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
index 248c9f765c45..5ff15e8a2a0a 100644
--- a/drivers/gpu/drm/cirrus/cirrus.c
+++ b/drivers/gpu/drm/cirrus/cirrus.c
@@ -38,7 +38,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #define DRIVER_NAME "cirrus"
 #define DRIVER_DESC "qemu cirrus vga"
@@ -404,6 +403,8 @@ static int cirrus_pipe_check(struct drm_simple_display_pipe 
*pipe,
 {
struct drm_framebuffer *fb = plane_state->fb;
 
+   crtc_state->no_vblank = true;
+
if (!fb)
return 0;
return cirrus_check_size(fb->width, fb->height, fb);
@@ -434,13 +435,6 @@ static void cirrus_pipe_update(struct 
drm_simple_display_pipe *pipe,
 
if (drm_atomic_helper_damage_merged(old_state, state, &rect))
cirrus_fb_blit_rect(pipe->plane.state->fb, &rect);
-
-   if (crtc->state->event) {
-   spin_lock_irq(&crtc->dev->event_lock);
-   drm_crtc_send_vblank_event(crtc, crtc->state->event);
-   crtc->state->event = NULL;
-   spin_unlock_irq(&crtc->dev->event_lock);
-   }
 }
 
 static const struct drm_simple_display_pipe_funcs cirrus_pipe_funcs = {
-- 
2.24.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/4] Use no_vblank property for drivers without VBLANK

[Thomas Zimmermann]

(Resending because I did not cc dri-devel properly.)

Instead of faking VBLANK events by themselves, drivers without VBLANK
support can enable drm_crtc_vblank.no_vblank and let DRM do the rest.
The patchset makes this official and converts over several drivers.

Ast already uses the functionality and just needs a cleanup. Cirrus can
be converted easily by setting the field in the check() callback and
removing the existing VBLANK code. For most other simple-KMS drivers
without enable_vblank() and check(), simple-KMS helpers can enable the
faked VBLANK by default. The only exception is Xen, which comes with
its own VBLANK logic and should rather to disable no_vblank.

v2:
* document functionality (Daniel)
* cleanup ast (Daniel)
* let simple-kms handle no_vblank where possible

Thomas Zimmermann (4):
  drm: Document struct drm_crtc_state.no_vblank for faking VBLANK events
  drm/ast: Set struct drm_crtc_state.no_vblank in atomic_check()
  drm/cirrus: Let DRM core send VBLANK events
  drm/simple-kms: Let DRM core send VBLANK events by default

 drivers/gpu/drm/ast/ast_mode.c  |  4 ++--
 drivers/gpu/drm/bochs/bochs_kms.c   |  9 -
 drivers/gpu/drm/cirrus/cirrus.c | 10 ++
 drivers/gpu/drm/drm_atomic_helper.c |  4 +++-
 drivers/gpu/drm/drm_mipi_dbi.c  |  9 -
 drivers/gpu/drm/drm_simple_kms_helper.c | 19 +++
 drivers/gpu/drm/tiny/gm12u320.c |  9 -
 drivers/gpu/drm/tiny/ili9225.c  |  9 -
 drivers/gpu/drm/tiny/repaper.c  |  9 -
 drivers/gpu/drm/tiny/st7586.c   |  9 -
 drivers/gpu/drm/udl/udl_modeset.c   | 11 ---
 drivers/gpu/drm/xen/xen_drm_front_kms.c | 13 +
 include/drm/drm_crtc.h  |  9 +++--
 include/drm/drm_simple_kms_helper.h |  7 +--
 14 files changed, 47 insertions(+), 84 deletions(-)

--
2.24.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/5] dt-bindings: display: sitronix, st7735r: Add Okaya RH128128T

[Geert Uytterhoeven]

Document support for the Okaya RH128128T display, which is a 128x128
1.44" TFT display driven by a Sitronix ST7715R TFT Controller/Driver.
It can be found on e.g. the Renesas YRSK-LCD-PMOD extension board, which
comes with various Renesas development kits (e.g. Renesas Starter Kit+
for RZ/A1H[1]).

ST7715R and ST7735R are very similar.  Their major difference is that
the former is restricted to displays of up to 132x132 pixels, while the
latter supports displays up to 132x162 pixels.

[1] 
https://renesasrulz.com/the_vault/f/archive-forum/4981/upgrading-to-the-renesas-rz-a1h

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Rebase on top of DT schema conversion,
  - Add YRSK-LCD-PMOD reference and links.
---
 .../devicetree/bindings/display/sitronix,st7735r.yaml  | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml 
b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
index 21bccc91f74255e1..8892d79e6e100b79 100644
--- a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
+++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
@@ -10,8 +10,8 @@ maintainers:
   - David Lechner 
 
 description:
-  This binding is for display panels using a Sitronix ST7735R controller in
-  SPI mode.
+  This binding is for display panels using a Sitronix ST7715R or ST7735R
+  controller in SPI mode.
 
 allOf:
   - $ref: panel/panel-common.yaml#
@@ -25,6 +25,12 @@ properties:
   - enum:
   - jianda,jd-t18003-t01
   - const: sitronix,st7735r
+  - description:
+  Okaya 1.44" 128x128 Color TFT LCD (E.g. Renesas YRSK-LCD-PMOD)
+items:
+  - enum:
+  - okaya,rh128128t
+  - const: sitronix,st7715r
 
   spi-max-frequency:
 maximum: 3200
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/5] drm/mipi_dbi: Add support for display offsets

[Geert Uytterhoeven]

If the resolution of the TFT display is smaller than the maximum
resolution supported by the display controller, the display may be
connected to the driver output arrays with a horizontal and/or vertical
offset, leading to a shifted image.

Add support for specifying these offsets.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Sam Ravnborg 
---
v2:
  - Add Reviewed-by.
---
 drivers/gpu/drm/drm_mipi_dbi.c | 30 --
 include/drm/drm_mipi_dbi.h | 12 
 2 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 16bff1be4b8ac622..27fe81a53c88e338 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -238,6 +238,23 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer 
*fb,
 }
 EXPORT_SYMBOL(mipi_dbi_buf_copy);
 
+static void mipi_dbi_set_window_address(struct mipi_dbi_dev *dbidev,
+   unsigned int xs, unsigned int xe,
+   unsigned int ys, unsigned int ye)
+{
+   struct mipi_dbi *dbi = &dbidev->dbi;
+
+   xs += dbidev->left_offset;
+   xe += dbidev->left_offset;
+   ys += dbidev->top_offset;
+   ye += dbidev->top_offset;
+
+   mipi_dbi_command(dbi, MIPI_DCS_SET_COLUMN_ADDRESS, (xs >> 8) & 0xff,
+xs & 0xff, (xe >> 8) & 0xff, xe & 0xff);
+   mipi_dbi_command(dbi, MIPI_DCS_SET_PAGE_ADDRESS, (ys >> 8) & 0xff,
+ys & 0xff, (ye >> 8) & 0xff, ye & 0xff);
+}
+
 static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, struct drm_rect 
*rect)
 {
struct drm_gem_object *gem = drm_gem_fb_get_obj(fb, 0);
@@ -271,12 +288,8 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, 
struct drm_rect *rect)
tr = cma_obj->vaddr;
}
 
-   mipi_dbi_command(dbi, MIPI_DCS_SET_COLUMN_ADDRESS,
-(rect->x1 >> 8) & 0xff, rect->x1 & 0xff,
-((rect->x2 - 1) >> 8) & 0xff, (rect->x2 - 1) & 0xff);
-   mipi_dbi_command(dbi, MIPI_DCS_SET_PAGE_ADDRESS,
-(rect->y1 >> 8) & 0xff, rect->y1 & 0xff,
-((rect->y2 - 1) >> 8) & 0xff, (rect->y2 - 1) & 0xff);
+   mipi_dbi_set_window_address(dbidev, rect->x1, rect->x2 - 1, rect->y1,
+   rect->y2 - 1);
 
ret = mipi_dbi_command_buf(dbi, MIPI_DCS_WRITE_MEMORY_START, tr,
   width * height * 2);
@@ -366,10 +379,7 @@ static void mipi_dbi_blank(struct mipi_dbi_dev *dbidev)
 
memset(dbidev->tx_buf, 0, len);
 
-   mipi_dbi_command(dbi, MIPI_DCS_SET_COLUMN_ADDRESS, 0, 0,
-((width - 1) >> 8) & 0xFF, (width - 1) & 0xFF);
-   mipi_dbi_command(dbi, MIPI_DCS_SET_PAGE_ADDRESS, 0, 0,
-((height - 1) >> 8) & 0xFF, (height - 1) & 0xFF);
+   mipi_dbi_set_window_address(dbidev, 0, width - 1, 0, height - 1);
mipi_dbi_command_buf(dbi, MIPI_DCS_WRITE_MEMORY_START,
 (u8 *)dbidev->tx_buf, len);
 
diff --git a/include/drm/drm_mipi_dbi.h b/include/drm/drm_mipi_dbi.h
index 67c66f5ee591e80f..33f325f5af2b921f 100644
--- a/include/drm/drm_mipi_dbi.h
+++ b/include/drm/drm_mipi_dbi.h
@@ -109,6 +109,18 @@ struct mipi_dbi_dev {
 */
unsigned int rotation;
 
+   /**
+* @left_offset: Horizontal offset of the display relative to the
+*   controller's driver array
+*/
+   unsigned int left_offset;
+
+   /**
+* @top_offset: Vertical offset of the display relative to the
+*  controller's driver array
+*/
+   unsigned int top_offset;
+
/**
 * @backlight: backlight device (optional)
 */
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

TTM or vmwgfx tree? Re: [PATCH v5 0/2] mm, drm/ttm: Fix pte insertion with customized protection

[VMware]

Hi Christian,

On 1/15/20 1:41 PM, Thomas Hellström (VMware) wrote:

From: Thomas Hellstrom 

The drm/ttm module is using a modified on-stack copy of the
struct vm_area_struct to be able to set a page protection with customized
caching. Fix that by adding a vmf_insert_mixed_prot() function similar
to the existing vmf_insert_pfn_prot() for use with drm/ttm.

Patches are acked to be merged through a drm tree.


This small patchset should be ready to be merged now, with acks from Andrew.

Do you want to take it through the ttm tree, or should I ask Dave / 
Daniel to pull it separately?


Note that similar to the vmwgfx coherent patches, Linus has indicated 
that he wants separate pull requests for stuff like this that touches mm.


Thanks,

Thomas


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/5] dt-bindings: display: sitronix, st7735r: Convert to DT schema

[Geert Uytterhoeven]

Convert the DT binding documentation for Sitronix ST7735R displays to DT
schema.

Add a reference to the Adafruit 1.8" LCD while at it.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - New.
---
 .../bindings/display/sitronix,st7735r.txt | 35 --
 .../bindings/display/sitronix,st7735r.yaml| 65 +++
 MAINTAINERS   |  2 +-
 3 files changed, 66 insertions(+), 36 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7735r.txt
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7735r.yaml

diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.txt 
b/Documentation/devicetree/bindings/display/sitronix,st7735r.txt
deleted file mode 100644
index cd5c7186890a2be7..
--- a/Documentation/devicetree/bindings/display/sitronix,st7735r.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Sitronix ST7735R display panels
-
-This binding is for display panels using a Sitronix ST7735R controller in SPI
-mode.
-
-Required properties:
-- compatible:  "jianda,jd-t18003-t01", "sitronix,st7735r"
-- dc-gpios:Display data/command selection (D/CX)
-- reset-gpios: Reset signal (RSTX)
-
-The node for this driver must be a child node of a SPI controller, hence
-all mandatory properties described in ../spi/spi-bus.txt must be specified.
-
-Optional properties:
-- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
-- backlight:   phandle of the backlight device attached to the panel
-
-Example:
-
-   backlight: backlight {
-   compatible = "gpio-backlight";
-   gpios = <&gpio 44 GPIO_ACTIVE_HIGH>;
-   };
-
-   ...
-
-   display@0{
-   compatible = "jianda,jd-t18003-t01", "sitronix,st7735r";
-   reg = <0>;
-   spi-max-frequency = <3200>;
-   dc-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
-   reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
-   rotation = <270>;
-   backlight = &backlight;
-   };
diff --git a/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml 
b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
new file mode 100644
index ..21bccc91f74255e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sitronix,st7735r.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sitronix ST7735R Display Panels Device Tree Bindings
+
+maintainers:
+  - David Lechner 
+
+description:
+  This binding is for display panels using a Sitronix ST7735R controller in
+  SPI mode.
+
+allOf:
+  - $ref: panel/panel-common.yaml#
+
+properties:
+  compatible:
+oneOf:
+  - description:
+  Adafruit 1.8" 160x128 Color TFT LCD (Product ID 358 or 618)
+items:
+  - enum:
+  - jianda,jd-t18003-t01
+  - const: sitronix,st7735r
+
+  spi-max-frequency:
+maximum: 3200
+
+  dc-gpios:
+maxItems: 1
+description: Display data/command selection (D/CX)
+
+required:
+  - compatible
+  - reg
+  - dc-gpios
+  - reset-gpios
+
+examples:
+  - |
+#include 
+
+backlight: backlight {
+compatible = "gpio-backlight";
+gpios = <&gpio 44 GPIO_ACTIVE_HIGH>;
+};
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+display@0{
+compatible = "jianda,jd-t18003-t01", "sitronix,st7735r";
+reg = <0>;
+spi-max-frequency = <3200>;
+dc-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
+reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
+rotation = <270>;
+};
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index ea8262509bdd21ac..3007f83bd504194a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5382,7 +5382,7 @@ M:David Lechner 
 T: git git://anongit.freedesktop.org/drm/drm-misc
 S: Maintained
 F: drivers/gpu/drm/tiny/st7735r.c
-F: Documentation/devicetree/bindings/display/sitronix,st7735r.txt
+F: Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
 
 DRM DRIVER FOR SONY ACX424AKP PANELS
 M: Linus Walleij 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 5/5] drm: tiny: st7735r: Add support for Okaya RH128128T

[Geert Uytterhoeven]

Add support for the Okaya RH128128T display to the st7735r driver on
DT-enabled systems.

The RH128128T is a 128x128 1.44" TFT display driven by a Sitronix
ST7715R TFT Controller/Driver.  The latter is very similar to the
ST7735R, and can be handled by the existing st7735r driver.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Split in two patches,
  - Update Kconfig help text,
  - Improve file comment header.
---
 drivers/gpu/drm/tiny/Kconfig   | 8 +---
 drivers/gpu/drm/tiny/st7735r.c | 9 -
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index a46ac284dd5e9211..a8664211123e7025 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -85,14 +85,16 @@ config TINYDRM_ST7586
  If M is selected the module will be called st7586.
 
 config TINYDRM_ST7735R
-   tristate "DRM support for Sitronix ST7735R display panels"
+   tristate "DRM support for Sitronix ST7715R/ST7735R display panels"
depends on DRM && SPI
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_MIPI_DBI
select BACKLIGHT_CLASS_DEVICE
help
- DRM driver Sitronix ST7735R with one of the following LCDs:
- * JD-T18003-T01 1.8" 128x160 TFT
+ DRM driver for Sitronix ST7715R/ST7735R with one of the following
+ LCDs:
+ * Jianda JD-T18003-T01 1.8" 128x160 TFT
+ * Okaya RH128128T 1.44" 128x128 TFT
 
  If M is selected the module will be called st7735r.
diff --git a/drivers/gpu/drm/tiny/st7735r.c b/drivers/gpu/drm/tiny/st7735r.c
index a838f237c8d82e3d..32574f1b60716390 100644
--- a/drivers/gpu/drm/tiny/st7735r.c
+++ b/drivers/gpu/drm/tiny/st7735r.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * DRM driver for Sitronix ST7735R panels
+ * DRM driver for display panels connected to a Sitronix ST7715R or ST7735R
+ * display controller in SPI mode.
  *
  * Copyright 2017 David Lechner 
  * Copyright (C) 2019 Glider bvba
@@ -144,6 +145,11 @@ static const struct st7735r_cfg jd_t18003_t01_cfg = {
.write_only = true,
 };
 
+static const struct st7735r_cfg rh128128t_cfg = {
+   .mode   = { DRM_SIMPLE_MODE(128, 128, 25, 26) },
+   .left_offset= 2,
+   .top_offset = 3,
+   .rgb= true,
 };
 
 DEFINE_DRM_GEM_CMA_FOPS(st7735r_fops);
@@ -163,6 +169,7 @@ static struct drm_driver st7735r_driver = {
 
 static const struct of_device_id st7735r_of_match[] = {
{ .compatible = "jianda,jd-t18003-t01", .data = &jd_t18003_t01_cfg },
+   { .compatible = "okaya,rh128128t", .data = &rh128128t_cfg },
{ },
 };
 MODULE_DEVICE_TABLE(of, st7735r_of_match);
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/5] drm: Add support for Okaya RH128128T

[Geert Uytterhoeven]

Hi all,

This patch series adds support for the Okaya RH128128T LCD to the
existing ST7735R driver.  This is a 128x128 1.4" TFT display driven by a
Sitronix ST7715R TFT Controller/Driver.  It is used on e.g. the Renesas
YRSK-LCD-PMOD extension board, which is shipped with Renesas RSK+RZA1
development boards[1], and with several other Renesas starter kits, for
RX, Synergy, and RZ/T1 MCUs and SoCs.

Changes compared to v1[2]:
  - Convert DT bindings to DT schema,
  - Add YRSK-LCD-PMOD reference and links,
  - Add Reviewed-by,
  - Split driver preparation and adding actual support in two separate
patches,
  - Replace st7735r_priv.rgb by a pointer to struct st7735r_cfg,
  - Change prefix of jd_t18003_t01_pipe_enable() and
jd_t18003_t01_pipe_funcs(),
  - Update Kconfig help text,
  - Improve file comment header.

This has been tested using the r7s72100-rskrza1-pmod-spi.dtso and
r7s72100-rskrza1-pmod2-lcd.dtso DT overlays[3].
Note that for using this on RSK+RZA1, there is a dependency on RSPI
cs-gpios support (now in linux-next).
With DT overlays, this also depends on DT overlays[4] and gpio-hog
overlay support[5].

Thanks!

[1] 
https://renesasrulz.com/the_vault/f/archive-forum/4981/upgrading-to-the-renesas-rz-a1h
[1] 
https://lore.kernel.org/dri-devel/20200102141246.370-1-geert+rene...@glider.be/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/renesas-overlays
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/overlays
[5] "[PATCH/RFC 0/2] gpio: of: Add DT overlay support for GPIO hogs"
https://lore.kernel.org/lkml/20191230133852.5890-1-geert+rene...@glider.be/

Geert Uytterhoeven (5):
  dt-bindings: display: sitronix,st7735r: Convert to DT schema
  dt-bindings: display: sitronix,st7735r: Add Okaya RH128128T
  drm/mipi_dbi: Add support for display offsets
  drm: tiny: st7735r: Prepare for adding support for more displays
  drm: tiny: st7735r: Add support for Okaya RH128128T

 .../bindings/display/sitronix,st7735r.txt | 35 -
 .../bindings/display/sitronix,st7735r.yaml| 71 +
 MAINTAINERS   |  2 +-
 drivers/gpu/drm/drm_mipi_dbi.c| 30 +---
 drivers/gpu/drm/tiny/Kconfig  |  8 +-
 drivers/gpu/drm/tiny/st7735r.c| 76 +++
 include/drm/drm_mipi_dbi.h| 12 +++
 7 files changed, 170 insertions(+), 64 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7735r.txt
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7735r.yaml

-- 
2.17.1

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

[PATCH v2 4/5] drm: tiny: st7735r: Prepare for adding support for more displays

[Geert Uytterhoeven]

Currently the st7735r driver supports only a single display panel.
Prepare for adding support for other display panels by factoring out the
display-specific parameters in struct st7735r_cfg.

For now, the following parameters can be configured:
  - Display resolution,
  - Horizontal/vertical display offsets,
  - Read-write versus read-only controllers,
  - RGB versus BGR color component ordering.

Rename jd_t18003_t01_pipe_enable() and jd_t18003_t01_pipe_funcs() to
st7735r_pipe_enable() resp. st7735r_pipe_funcs(), as they are not really
specific to the Jianda JD-T18003-T01 display anymore.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Split off from "drm: tiny: st7735r: Add support for Okaya
RH128128T",
  - Replace st7735r_priv.rgb by a pointer to struct st7735r_cfg,
  - Change prefix of jd_t18003_t01_pipe_enable() and
jd_t18003_t01_pipe_funcs().
---
 drivers/gpu/drm/tiny/st7735r.c | 67 +++---
 1 file changed, 53 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/tiny/st7735r.c b/drivers/gpu/drm/tiny/st7735r.c
index 3f4487c716848cf8..a838f237c8d82e3d 100644
--- a/drivers/gpu/drm/tiny/st7735r.c
+++ b/drivers/gpu/drm/tiny/st7735r.c
@@ -3,6 +3,7 @@
  * DRM driver for Sitronix ST7735R panels
  *
  * Copyright 2017 David Lechner 
+ * Copyright (C) 2019 Glider bvba
  */
 
 #include 
@@ -10,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,12 +39,28 @@
 #define ST7735R_MY BIT(7)
 #define ST7735R_MX BIT(6)
 #define ST7735R_MV BIT(5)
+#define ST7735R_RGBBIT(3)
+
+struct st7735r_cfg {
+   const struct drm_display_mode mode;
+   unsigned int left_offset;
+   unsigned int top_offset;
+   unsigned int write_only:1;
+   unsigned int rgb:1; /* RGB (vs. BGR) */
+};
+
+struct st7735r_priv {
+   struct mipi_dbi_dev dbidev; /* Must be first for .release() */
+   const struct st7735r_cfg *cfg;
+};
 
-static void jd_t18003_t01_pipe_enable(struct drm_simple_display_pipe *pipe,
- struct drm_crtc_state *crtc_state,
- struct drm_plane_state *plane_state)
+static void st7735r_pipe_enable(struct drm_simple_display_pipe *pipe,
+   struct drm_crtc_state *crtc_state,
+   struct drm_plane_state *plane_state)
 {
struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+   struct st7735r_priv *priv = container_of(dbidev, struct st7735r_priv,
+dbidev);
struct mipi_dbi *dbi = &dbidev->dbi;
int ret, idx;
u8 addr_mode;
@@ -87,6 +105,10 @@ static void jd_t18003_t01_pipe_enable(struct 
drm_simple_display_pipe *pipe,
addr_mode = ST7735R_MY | ST7735R_MV;
break;
}
+
+   if (priv->cfg->rgb)
+   addr_mode |= ST7735R_RGB;
+
mipi_dbi_command(dbi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT,
 MIPI_DCS_PIXEL_FMT_16BIT);
@@ -109,15 +131,19 @@ static void jd_t18003_t01_pipe_enable(struct 
drm_simple_display_pipe *pipe,
drm_dev_exit(idx);
 }
 
-static const struct drm_simple_display_pipe_funcs jd_t18003_t01_pipe_funcs = {
-   .enable = jd_t18003_t01_pipe_enable,
+static const struct drm_simple_display_pipe_funcs st7735r_pipe_funcs = {
+   .enable = st7735r_pipe_enable,
.disable= mipi_dbi_pipe_disable,
.update = mipi_dbi_pipe_update,
.prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
 };
 
-static const struct drm_display_mode jd_t18003_t01_mode = {
-   DRM_SIMPLE_MODE(128, 160, 28, 35),
+static const struct st7735r_cfg jd_t18003_t01_cfg = {
+   .mode   = { DRM_SIMPLE_MODE(128, 160, 28, 35) },
+   /* Cannot read from Adafruit 1.8" display via SPI */
+   .write_only = true,
+};
+
 };
 
 DEFINE_DRM_GEM_CMA_FOPS(st7735r_fops);
@@ -136,13 +162,13 @@ static struct drm_driver st7735r_driver = {
 };
 
 static const struct of_device_id st7735r_of_match[] = {
-   { .compatible = "jianda,jd-t18003-t01" },
+   { .compatible = "jianda,jd-t18003-t01", .data = &jd_t18003_t01_cfg },
{ },
 };
 MODULE_DEVICE_TABLE(of, st7735r_of_match);
 
 static const struct spi_device_id st7735r_id[] = {
-   { "jd-t18003-t01", 0 },
+   { "jd-t18003-t01", (uintptr_t)&jd_t18003_t01_cfg },
{ },
 };
 MODULE_DEVICE_TABLE(spi, st7735r_id);
@@ -150,17 +176,26 @@ MODULE_DEVICE_TABLE(spi, st7735r_id);
 static int st7735r_probe(struct spi_device *spi)
 {
struct device *dev = &spi->dev;
+   const struct st7735r_cfg *cfg;
struct mipi_dbi_dev *dbidev;
+   struct st7735r_priv *priv;
struct drm_device *drm;
struct mipi_dbi *dbi;
struct gpio_desc *dc;
u32 rotation = 0;
int ret;
 
-   dbidev = k

[PATCH v5 0/2] mm, drm/ttm: Fix pte insertion with customized protection

[VMware]

From: Thomas Hellstrom 

The drm/ttm module is using a modified on-stack copy of the
struct vm_area_struct to be able to set a page protection with customized
caching. Fix that by adding a vmf_insert_mixed_prot() function similar
to the existing vmf_insert_pfn_prot() for use with drm/ttm.

Patches are acked to be merged through a drm tree.

Changes since v1:
*) Formatting fixes in patch 1
*) Updated commit message of patch 2.
Changes since v2:
*) Moved vmf_insert_mixed_prot() export to patch 2 (Michal Hocko)
*) Documented under which conditions it's safe to use a page protection
   different from struct vm_area_struct::vm_page_prot. (Michal Hocko)
Changes since v3:
*) More documentation regarding under which conditions it's safe to use a
   page protection different from struct vm_area_struct::vm_page_prot. This
   time also in core vm. (Michal Hocko)
Changes since v4:
*) Fixed a typo
*) Added acks.

Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: "Matthew Wilcox (Oracle)" 
Cc: "Kirill A. Shutemov" 
Cc: Ralph Campbell 
Cc: "Jérôme Glisse" 
Cc: "Christian König" 

-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 1/2] mm: Add a vmf_insert_mixed_prot() function

[VMware]

From: Thomas Hellstrom 

The TTM module today uses a hack to be able to set a different page
protection than struct vm_area_struct::vm_page_prot. To be able to do
this properly, add the needed vm functionality as vmf_insert_mixed_prot().

Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: "Matthew Wilcox (Oracle)" 
Cc: "Kirill A. Shutemov" 
Cc: Ralph Campbell 
Cc: "Jérôme Glisse" 
Cc: "Christian König" 
Signed-off-by: Thomas Hellstrom 
Acked-by: Christian König 
Acked-by: Michal Hocko 
Acked-by: Andrew Morton 
---
 include/linux/mm.h   |  2 ++
 include/linux/mm_types.h |  7 ++-
 mm/memory.c  | 43 
 3 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index cc292273e6ba..29575d3c1e47 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2548,6 +2548,8 @@ vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct 
*vma, unsigned long addr,
unsigned long pfn, pgprot_t pgprot);
 vm_fault_t vmf_insert_mixed(struct vm_area_struct *vma, unsigned long addr,
pfn_t pfn);
+vm_fault_t vmf_insert_mixed_prot(struct vm_area_struct *vma, unsigned long 
addr,
+   pfn_t pfn, pgprot_t pgprot);
 vm_fault_t vmf_insert_mixed_mkwrite(struct vm_area_struct *vma,
unsigned long addr, pfn_t pfn);
 int vm_iomap_memory(struct vm_area_struct *vma, phys_addr_t start, unsigned 
long len);
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index fa795284..aff6cdc784e0 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -307,7 +307,12 @@ struct vm_area_struct {
/* Second cache line starts here. */
 
struct mm_struct *vm_mm;/* The address space we belong to. */
-   pgprot_t vm_page_prot;  /* Access permissions of this VMA. */
+
+   /*
+* Access permissions of this VMA.
+* See vmf_insert_mixed_prot() for discussion.
+*/
+   pgprot_t vm_page_prot;
unsigned long vm_flags; /* Flags, see mm.h. */
 
/*
diff --git a/mm/memory.c b/mm/memory.c
index b1ca51a079f2..269a8a871e83 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1646,6 +1646,9 @@ static vm_fault_t insert_pfn(struct vm_area_struct *vma, 
unsigned long addr,
  * vmf_insert_pfn_prot should only be used if using multiple VMAs is
  * impractical.
  *
+ * See vmf_insert_mixed_prot() for a discussion of the implication of using
+ * a value of @pgprot different from that of @vma->vm_page_prot.
+ *
  * Context: Process context.  May allocate using %GFP_KERNEL.
  * Return: vm_fault_t value.
  */
@@ -1719,9 +1722,9 @@ static bool vm_mixed_ok(struct vm_area_struct *vma, pfn_t 
pfn)
 }
 
 static vm_fault_t __vm_insert_mixed(struct vm_area_struct *vma,
-   unsigned long addr, pfn_t pfn, bool mkwrite)
+   unsigned long addr, pfn_t pfn, pgprot_t pgprot,
+   bool mkwrite)
 {
-   pgprot_t pgprot = vma->vm_page_prot;
int err;
 
BUG_ON(!vm_mixed_ok(vma, pfn));
@@ -1764,10 +1767,42 @@ static vm_fault_t __vm_insert_mixed(struct 
vm_area_struct *vma,
return VM_FAULT_NOPAGE;
 }
 
+/**
+ * vmf_insert_mixed_prot - insert single pfn into user vma with specified 
pgprot
+ * @vma: user vma to map to
+ * @addr: target user address of this page
+ * @pfn: source kernel pfn
+ * @pgprot: pgprot flags for the inserted page
+ *
+ * This is exactly like vmf_insert_mixed(), except that it allows drivers to
+ * to override pgprot on a per-page basis.
+ *
+ * Typically this function should be used by drivers to set caching- and
+ * encryption bits different than those of @vma->vm_page_prot, because
+ * the caching- or encryption mode may not be known at mmap() time.
+ * This is ok as long as @vma->vm_page_prot is not used by the core vm
+ * to set caching and encryption bits for those vmas (except for COW pages).
+ * This is ensured by core vm only modifying these page table entries using
+ * functions that don't touch caching- or encryption bits, using pte_modify()
+ * if needed. (See for example mprotect()).
+ * Also when new page-table entries are created, this is only done using the
+ * fault() callback, and never using the value of vma->vm_page_prot,
+ * except for page-table entries that point to anonymous pages as the result
+ * of COW.
+ *
+ * Context: Process context.  May allocate using %GFP_KERNEL.
+ * Return: vm_fault_t value.
+ */
+vm_fault_t vmf_insert_mixed_prot(struct vm_area_struct *vma, unsigned long 
addr,
+pfn_t pfn, pgprot_t pgprot)
+{
+   return __vm_insert_mixed(vma, addr, pfn, pgprot, false);
+}
+
 vm_fault_t vmf_insert_mixed(struct vm_area_struct *vma, unsigned long addr,
pfn_t pfn)
 {
-   return __vm_insert_mixed(vma, addr, pfn, false);
+   return __vm_insert_mixed(vma, addr, pfn, vma->vm_page_prot, false);
 }
 EXPORT_SYMBOL(vmf_insert_mixed);
 
@@ -1779,7 +1814,7 @@ EXPO

[PATCH v5 2/2] mm, drm/ttm: Fix vm page protection handling

[VMware]

From: Thomas Hellstrom 

TTM graphics buffer objects may, transparently to user-space,  move
between IO and system memory. When that happens, all PTEs pointing to the
old location are zapped before the move and then faulted in again if
needed. When that happens, the page protection caching mode- and
encryption bits may change and be different from those of
struct vm_area_struct::vm_page_prot.

We were using an ugly hack to set the page protection correctly.
Fix that and instead export and use vmf_insert_mixed_prot() or use
vmf_insert_pfn_prot().
Also get the default page protection from
struct vm_area_struct::vm_page_prot rather than using vm_get_page_prot().
This way we catch modifications done by the vm system for drivers that
want write-notification.

Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: "Matthew Wilcox (Oracle)" 
Cc: "Kirill A. Shutemov" 
Cc: Ralph Campbell 
Cc: "Jérôme Glisse" 
Cc: "Christian König" 
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Christian König 
Acked-by: Andrew Morton 
---
 drivers/gpu/drm/ttm/ttm_bo_vm.c | 22 +++---
 mm/memory.c |  1 +
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 3e8c3de91ae4..78bfab81cf04 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -173,7 +173,6 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
pgoff_t num_prefault)
 {
struct vm_area_struct *vma = vmf->vma;
-   struct vm_area_struct cvma = *vma;
struct ttm_buffer_object *bo = vma->vm_private_data;
struct ttm_bo_device *bdev = bo->bdev;
unsigned long page_offset;
@@ -244,7 +243,7 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
goto out_io_unlock;
}
 
-   cvma.vm_page_prot = ttm_io_prot(bo->mem.placement, prot);
+   prot = ttm_io_prot(bo->mem.placement, prot);
if (!bo->mem.bus.is_iomem) {
struct ttm_operation_ctx ctx = {
.interruptible = false,
@@ -260,7 +259,7 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
}
} else {
/* Iomem should not be marked encrypted */
-   cvma.vm_page_prot = pgprot_decrypted(cvma.vm_page_prot);
+   prot = pgprot_decrypted(prot);
}
 
/*
@@ -283,11 +282,20 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
pfn = page_to_pfn(page);
}
 
+   /*
+* Note that the value of @prot at this point may differ from
+* the value of @vma->vm_page_prot in the caching- and
+* encryption bits. This is because the exact location of the
+* data may not be known at mmap() time and may also change
+* at arbitrary times while the data is mmap'ed.
+* See vmf_insert_mixed_prot() for a discussion.
+*/
if (vma->vm_flags & VM_MIXEDMAP)
-   ret = vmf_insert_mixed(&cvma, address,
-   __pfn_to_pfn_t(pfn, PFN_DEV));
+   ret = vmf_insert_mixed_prot(vma, address,
+   __pfn_to_pfn_t(pfn, 
PFN_DEV),
+   prot);
else
-   ret = vmf_insert_pfn(&cvma, address, pfn);
+   ret = vmf_insert_pfn_prot(vma, address, pfn, prot);
 
/* Never error on prefaulted PTEs */
if (unlikely((ret & VM_FAULT_ERROR))) {
@@ -319,7 +327,7 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
if (ret)
return ret;
 
-   prot = vm_get_page_prot(vma->vm_flags);
+   prot = vma->vm_page_prot;
ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT);
if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
return ret;
diff --git a/mm/memory.c b/mm/memory.c
index 269a8a871e83..0f262acd1018 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1798,6 +1798,7 @@ vm_fault_t vmf_insert_mixed_prot(struct vm_area_struct 
*vma, unsigned long addr,
 {
return __vm_insert_mixed(vma, addr, pfn, pgprot, false);
 }
+EXPORT_SYMBOL(vmf_insert_mixed_prot);
 
 vm_fault_t vmf_insert_mixed(struct vm_area_struct *vma, unsigned long addr,
pfn_t pfn)
-- 
2.21.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 07/21] drm/i915: Convert to CRTC VBLANK callbacks

[Jani Nikula]

On Wed, 15 Jan 2020, Thomas Zimmermann  wrote:
> VBLANK callbacks in struct drm_driver are deprecated in favor of their
> equivalents in struct drm_crtc_funcs. Convert i915 over.
>
> The callback struct drm_driver.get_scanout_position() is deprecated
> in favor of struct drm_crtc_helper_funcs.get_scanout_position().
> i915 doesn't use CRTC helpers. Instead pass i915's implementation of
> get_scanout_position() to DRM core's
> drm_crtc_vblank_helper_get_vblank_timestamp_internal().
>
> v2:
>   * use DRM's implementation of get_vblank_timestamp()
>   * simplify function names
>
> Signed-off-by: Thomas Zimmermann 

Acked-by: Jani Nikula 

for the approach and for merging through whichever tree makes most
sense, *however* needs detailed review on the whole.

> ---
>  drivers/gpu/drm/i915/display/intel_display.c |  7 +++
>  drivers/gpu/drm/i915/i915_drv.c  |  3 ---
>  drivers/gpu/drm/i915/i915_irq.c  | 20 +++-
>  drivers/gpu/drm/i915/i915_irq.h  |  6 ++
>  4 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 59c375879186..c8f1da845e7d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16336,6 +16336,7 @@ static const struct drm_crtc_funcs bdw_crtc_funcs = {
>   .get_vblank_counter = g4x_get_vblank_counter,
>   .enable_vblank = bdw_enable_vblank,
>   .disable_vblank = bdw_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs ilk_crtc_funcs = {
> @@ -16344,6 +16345,7 @@ static const struct drm_crtc_funcs ilk_crtc_funcs = {
>   .get_vblank_counter = g4x_get_vblank_counter,
>   .enable_vblank = ilk_enable_vblank,
>   .disable_vblank = ilk_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs g4x_crtc_funcs = {
> @@ -16352,6 +16354,7 @@ static const struct drm_crtc_funcs g4x_crtc_funcs = {
>   .get_vblank_counter = g4x_get_vblank_counter,
>   .enable_vblank = i965_enable_vblank,
>   .disable_vblank = i965_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs i965_crtc_funcs = {
> @@ -16360,6 +16363,7 @@ static const struct drm_crtc_funcs i965_crtc_funcs = {
>   .get_vblank_counter = i915_get_vblank_counter,
>   .enable_vblank = i965_enable_vblank,
>   .disable_vblank = i965_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs i915gm_crtc_funcs = {
> @@ -16368,6 +16372,7 @@ static const struct drm_crtc_funcs i915gm_crtc_funcs 
> = {
>   .get_vblank_counter = i915_get_vblank_counter,
>   .enable_vblank = i915gm_enable_vblank,
>   .disable_vblank = i915gm_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs i915_crtc_funcs = {
> @@ -16376,6 +16381,7 @@ static const struct drm_crtc_funcs i915_crtc_funcs = {
>   .get_vblank_counter = i915_get_vblank_counter,
>   .enable_vblank = i8xx_enable_vblank,
>   .disable_vblank = i8xx_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static const struct drm_crtc_funcs i8xx_crtc_funcs = {
> @@ -16384,6 +16390,7 @@ static const struct drm_crtc_funcs i8xx_crtc_funcs = {
>   /* no hw vblank counter */
>   .enable_vblank = i8xx_enable_vblank,
>   .disable_vblank = i8xx_disable_vblank,
> + .get_vblank_timestamp = i915_crtc_get_vblank_timestamp,
>  };
>  
>  static struct intel_crtc *intel_crtc_alloc(void)
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f7385abdd74b..30b9ba136a81 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2769,9 +2769,6 @@ static struct drm_driver driver = {
>   .gem_prime_export = i915_gem_prime_export,
>   .gem_prime_import = i915_gem_prime_import,
>  
> - .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> - .get_scanout_position = i915_get_crtc_scanoutpos,
> -
>   .dumb_create = i915_gem_dumb_create,
>   .dumb_map_offset = i915_gem_dumb_mmap_offset,
>  
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index afc6aad9bf8c..c39e3ef6e4a2 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -762,13 +762,15 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
> *crtc)
>   return (position + crtc->scanline_offset) % vtotal;
>  }
>  
> -bool i915_get_crtc_scanoutpos(struct drm_device *dev, unsigned int index,
> -   bool in_vblank_irq, int *vpos, int *hpos,
> -   ktime_t *stime,