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

2020-07-12 Thread Stephen Rothwell
Hi all,

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

  drivers/video/fbdev/core/fbcon.c

between commit:

  fcf918b96662 ("fbcon: Use array3_size() helper in scr_memcpyw()")

from the drm-misc tree and commit:

  28bc24fc46f9 ("vc: separate state")

from the tty 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/core/fbcon.c
index af9f5ab96f74,86fe41b1deb8..
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@@ -676,8 -676,8 +676,8 @@@ static void fbcon_prepare_logo(struct v
q = (unsigned short *) (vc->vc_origin +
vc->vc_size_row *
rows);
 -  scr_memcpyw(q, save, logo_lines * new_cols * 2);
 +  scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2));
-   vc->vc_y += logo_lines;
+   vc->state.y += logo_lines;
vc->vc_pos += logo_lines * vc->vc_size_row;
kfree(save);
}


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


Re: [git pull] drm for 5.8-rc1

2020-07-12 Thread Dave Airlie
How are we going with a fix for this regression I can commit?

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


Re: [PATCH 04/25] drm/vkms: Annotate vblank timer

2020-07-12 Thread Rodrigo Siqueira
Hi,

Everything looks fine to me, I just noticed that the amdgpu patches did
not apply smoothly, however it was trivial to fix the issues.

Reviewed-by: Rodrigo Siqueira 

Melissa,
Since you are using vkms regularly, could you test this patch and review
it? Remember to add your Tested-by when you finish.

Thanks

On 07/07, Daniel Vetter wrote:
> This is needed to signal the fences from page flips, annotate it
> accordingly. We need to annotate entire timer callback since if we get
> stuck anywhere in there, then the timer stops, and hence fences stop.
> Just annotating the top part that does the vblank handling isn't
> enough.
> 
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: Chris Wilson 
> Cc: Maarten Lankhorst 
> Cc: Christian König 
> Signed-off-by: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: Haneen Mohammed 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/vkms/vkms_crtc.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index ac85e17428f8..a53a40848a72 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -1,5 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -14,7 +16,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
> hrtimer *timer)
>   struct drm_crtc *crtc = >crtc;
>   struct vkms_crtc_state *state;
>   u64 ret_overrun;
> - bool ret;
> + bool ret, fence_cookie;
> +
> + fence_cookie = dma_fence_begin_signalling();
>  
>   ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
> output->period_ns);
> @@ -49,6 +53,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
> hrtimer *timer)
>   DRM_DEBUG_DRIVER("Composer worker already queued\n");
>   }
>  
> + dma_fence_end_signalling(fence_cookie);
> +
>   return HRTIMER_RESTART;
>  }
>  
> -- 
> 2.27.0
> 

-- 
Rodrigo Siqueira
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] drm/vkms: change the max cursor width/height

2020-07-12 Thread Rodrigo Siqueira
Applied to drm-misc-next.

Thanks

On 07/12, Rodrigo Siqueira wrote:
> Hi Melissa,
> 
> First of all, thanks a lot for your patch! This is a nice change since
> it increases the code coverage.
> 
> Reviewed-by: Rodrigo Siqueira 
> 
> On 07/10, Melissa Wen wrote:
> > This change expands the coverage for the IGT kms_cursor_crc test, where
> > the size varies between 64 and 512 for a square cursor. With this, in
> > addition to the cursor 64x64, this patch enables the test of cursors with
> > sizes: 128x128, 256x256, and 512x512.
> > 
> > Signed-off-by: Melissa Wen 
> > ---
> >  drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c 
> > b/drivers/gpu/drm/vkms/vkms_drv.c
> > index 1e8b2169d834..57a8a397d5e8 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > @@ -133,6 +133,8 @@ static int vkms_modeset_init(struct vkms_device 
> > *vkmsdev)
> > dev->mode_config.min_height = YRES_MIN;
> > dev->mode_config.max_width = XRES_MAX;
> > dev->mode_config.max_height = YRES_MAX;
> > +   dev->mode_config.cursor_width = 512;
> > +   dev->mode_config.cursor_height = 512;
> > dev->mode_config.preferred_depth = 24;
> > dev->mode_config.helper_private = _mode_config_helpers;
> >  
> > -- 
> > 2.27.0
> > 
> 
> -- 
> Rodrigo Siqueira
> https://siqueira.tech



-- 
Rodrigo Siqueira
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] drm/vkms: change the max cursor width/height

2020-07-12 Thread Rodrigo Siqueira
Hi Melissa,

First of all, thanks a lot for your patch! This is a nice change since
it increases the code coverage.

Reviewed-by: Rodrigo Siqueira 

On 07/10, Melissa Wen wrote:
> This change expands the coverage for the IGT kms_cursor_crc test, where
> the size varies between 64 and 512 for a square cursor. With this, in
> addition to the cursor 64x64, this patch enables the test of cursors with
> sizes: 128x128, 256x256, and 512x512.
> 
> Signed-off-by: Melissa Wen 
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 1e8b2169d834..57a8a397d5e8 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -133,6 +133,8 @@ static int vkms_modeset_init(struct vkms_device *vkmsdev)
>   dev->mode_config.min_height = YRES_MIN;
>   dev->mode_config.max_width = XRES_MAX;
>   dev->mode_config.max_height = YRES_MAX;
> + dev->mode_config.cursor_width = 512;
> + dev->mode_config.cursor_height = 512;
>   dev->mode_config.preferred_depth = 24;
>   dev->mode_config.helper_private = _mode_config_helpers;
>  
> -- 
> 2.27.0
> 

-- 
Rodrigo Siqueira
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 0/4] drm: core: Convert logging to drm_* functions.

2020-07-12 Thread Joe Perches
On Mon, 2020-07-13 at 00:24 +0530, Suraj Upadhyay wrote:
> On Sat, Jul 11, 2020 at 11:16:33AM -0700, Joe Perches wrote:
[]
> > Perhaps change the __drm_printk macro to not
> > dereference the drm argument when NULL.
> > 
> > A trivial but perhaps inefficient way might be
> > used like:
> > 
> > drm_(NULL, fmt, ...)
[]
> > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
[]
> > @@ -395,8 +395,8 @@ void drm_dev_dbg(const struct device *dev, enum 
> > drm_debug_category category,
> >  
> >  /* Helper for struct drm_device based logging. */
> >  #define __drm_printk(drm, level, type, fmt, ...)   \
> > -   dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
> > -
> > +   dev_##level##type((drm) ? (drm)->dev : NULL, "[drm] " fmt,  \
> > + ##__VA_ARGS__)
> >  
> >  #define drm_info(drm, fmt, ...)\
> > __drm_printk((drm), info,, fmt, ##__VA_ARGS__)
> > 
> 
> Hi Joe,
>   Thanks for your input.
> But I don't think that this change would be a good idea as we are
> supposed to find or make a substitute of WARN_* macros which
> take a `condition` as an argument and check for its truth.
> And I guess passing a NULL to dev_ would cause a format warning.
> 
> Also, the WARN_* macros are doing their job fine, and passing a NULL
> value everytime you want to warn about a certain condition at a
> particular line, doesn't seem good to me.
> 
> Thus, I think that WARN_* macros should be untouched.

So do I but the suggestion was not about WARN macros
only about drm_ macros and possibly unnecessary
conversions to dev_ when a drm_device context
is unavailable.

Also, you don't have to guess, the code is there for
you to inspect.

dev_ when a NULL is used as the first argument
emits "(NULL device *)" instead of dev_driver_string(dev)
and dev_name(dev).

See: drivers/base/core.c::__dev_printk()


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


Re: [PATCH] drm/panel: panel-simple: validate panel description

2020-07-12 Thread Laurent Pinchart
Hi Sam,

On Sun, Jul 12, 2020 at 12:58:19PM +0200, Sam Ravnborg wrote:
> On Sun, Jul 12, 2020 at 01:56:16AM +0300, Laurent Pinchart wrote:
> > Hi Sam,
> > 
> > (CC'ing Daniel)
> > 
> > Thank you for the patch.
> > 
> > On Sat, Jul 11, 2020 at 11:47:26AM +0200, Sam Ravnborg wrote:
> > > Warn is we detect a panel with missing descriptions.
> > 
> > s/is/if/
> > 
> > > This is inpsired by a similar patch by Laurent that introduced checks
> > > for LVDS panels - this extends the checks to the reminaing type of
> > 
> > s/reminaing type/remaining types/
> > 
> > > connectors.
> > > 
> > > This is known to fail for some of the existing panels but added
> > > despite this as we need help from people using the panels to
> > > add the missing info.
> > > The checks are not complete but will catch the most common mistakes.
> > > The checks at the same time serves as documentation for the minimum
> > > required description for a panel.
> > > 
> > > Signed-off-by: Sam Ravnborg 
> > > Cc: Laurent Pinchart 
> > > Cc: Thierry Reding 
> > > Cc: Sam Ravnborg 
> > > ---
> > > 
> > > This is my attempt on the validation described in the previous mail.
> > > The assignment of default connector_type will then be a follow-up patch
> > > to this.
> > > 
> > >   Sam
> > > 
> > >  drivers/gpu/drm/panel/panel-simple.c | 32 ++--
> > >  1 file changed, 30 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> > > b/drivers/gpu/drm/panel/panel-simple.c
> > > index 2aff93accad5..025a7ccdfcb3 100644
> > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > @@ -549,8 +549,12 @@ static int panel_simple_probe(struct device *dev, 
> > > const struct panel_desc *desc)
> > >   panel_simple_parse_panel_timing_node(dev, panel, );
> > >   }
> > >  
> > > - if (desc->connector_type == DRM_MODE_CONNECTOR_LVDS) {
> > > - /* Catch common mistakes for LVDS panels. */
> > > + /* Catch common mistakes for panels. */
> > > + switch (desc->connector_type) {
> > > + case 0:
> > > + WARN(desc->connector_type == 0, "specify missing 
> > > connector_type\n");
> > > + break;
> > > + case DRM_MODE_CONNECTOR_LVDS:
> > >   WARN_ON(desc->bus_flags &
> > >   ~(DRM_BUS_FLAG_DE_LOW |
> > > DRM_BUS_FLAG_DE_HIGH |
> > > @@ -564,6 +568,30 @@ static int panel_simple_probe(struct device *dev, 
> > > const struct panel_desc *desc)
> > >   WARN_ON((desc->bus_format == MEDIA_BUS_FMT_RGB888_1X7X4_SPWG ||
> > >desc->bus_format == MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA) 
> > > &&
> > >   desc->bpc != 8);
> > > + break;
> > > + case DRM_MODE_CONNECTOR_eDP:
> > > + WARN_ON(desc->bus_format == 0);
> > > + WARN_ON(desc->bpc != 6 && desc->bpc != 8);
> > > + break;
> > > + case DRM_MODE_CONNECTOR_DSI:
> > > + WARN_ON(desc->bpc != 6 && desc->bpc != 8);
> > > + break;
> > > + case DRM_MODE_CONNECTOR_DPI:
> > > + WARN_ON(desc->bus_flags &
> > > + ~(DRM_BUS_FLAG_DE_LOW |
> > > +   DRM_BUS_FLAG_DE_HIGH |
> > > +   DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE |
> > > +   DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
> > > +   DRM_BUS_FLAG_DATA_MSB_TO_LSB |
> > > +   DRM_BUS_FLAG_DATA_LSB_TO_MSB |
> > > +   DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE |
> > > +   DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE));
> > > + WARN_ON(desc->bus_format == 0);
> > > + WARN_ON(desc->bpc != 6 && desc->bpc != 8);
> > > + break;
> > > + default:
> > > + WARN(true, "panel has unknown connector_type: %d\n", 
> > > desc->connector_type);
> > > + break;
> > >   }
> > 
> > The checks look sane to me. For LVDS we've added the WARN_ON after
> > checking all LVDS panels [1], so the warning will only get displayed for
> > new panel drivers. For other types of panel, this will cause lots of
> > WARN_ON to trigger. On one hand it gets the issues noticed, which should
> > help fixing them, but on the other hand it will also scare lots of users
> > and developers. I'm not sure if we should downgrade that to a dev_warn()
> > for some time until we get at least the majority of the issues fixed.
> > Daniel, any opinion ?
> 
> We should be noisy, but not too noisy.
> dev_warn() is fine, maybe only dev_info()?
> 
> Unless I get other feedback I will convert to dev_info() in the
> next version of the patch.
> Fixing all panels before we add the checks, is not feasible.
> Access to datasheet is not easy/possible for many panels.

And that's the whole point of adding the warning, trying to get the
people who have access to the panels to help fixing the problem.

I think a dev_warn() would be a good compromise, the missing info can
have adverse consequences, so a warning seems appropriate.

> > [1] Actually not 

Re: [PATCH] drm/bridge: sil_sii8620: initialize return of sii8620_readb

2020-07-12 Thread Laurent Pinchart
Hi Tom,

Thank you for the patch.

On Sun, Jul 12, 2020 at 08:24:53AM -0700, t...@redhat.com wrote:
> From: Tom Rix 
> 
> clang static analysis flags this error
> 
> sil-sii8620.c:184:2: warning: Undefined or garbage value
>   returned to caller [core.uninitialized.UndefReturn]
> return ret;
> ^~
> 
> sii8620_readb calls sii8620_read_buf.
> sii8620_read_buf can return without setting its output
> pararmeter 'ret'.
> 
> So initialize ret.
> 
> Fixes: ce6e153f414a ("drm/bridge: add Silicon Image SiI8620 driver")
> 
> Signed-off-by: Tom Rix 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 3540e4931383..da933d477e5f 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -178,7 +178,7 @@ static void sii8620_read_buf(struct sii8620 *ctx, u16 
> addr, u8 *buf, int len)
>  
>  static u8 sii8620_readb(struct sii8620 *ctx, u16 addr)
>  {
> - u8 ret;
> + u8 ret = 0;
>  
>   sii8620_read_buf(ctx, addr, , 1);
>   return ret;

-- 
Regards,

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


[PATCH] drm/bridge: sil_sii8620: initialize return of sii8620_readb

2020-07-12 Thread trix
From: Tom Rix 

clang static analysis flags this error

sil-sii8620.c:184:2: warning: Undefined or garbage value
  returned to caller [core.uninitialized.UndefReturn]
return ret;
^~

sii8620_readb calls sii8620_read_buf.
sii8620_read_buf can return without setting its output
pararmeter 'ret'.

So initialize ret.

Fixes: ce6e153f414a ("drm/bridge: add Silicon Image SiI8620 driver")

Signed-off-by: Tom Rix 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 3540e4931383..da933d477e5f 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -178,7 +178,7 @@ static void sii8620_read_buf(struct sii8620 *ctx, u16 addr, 
u8 *buf, int len)
 
 static u8 sii8620_readb(struct sii8620 *ctx, u16 addr)
 {
-   u8 ret;
+   u8 ret = 0;
 
sii8620_read_buf(ctx, addr, , 1);
return ret;
-- 
2.18.1

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


Re: [PATCH] drm/panel: panel-simple: validate panel description

2020-07-12 Thread Sam Ravnborg
Hi Laurent.

On Sun, Jul 12, 2020 at 01:56:16AM +0300, Laurent Pinchart wrote:
> Hi Sam,
> 
> (CC'ing Daniel)
> 
> Thank you for the patch.
> 
> On Sat, Jul 11, 2020 at 11:47:26AM +0200, Sam Ravnborg wrote:
> > Warn is we detect a panel with missing descriptions.
> 
> s/is/if/
> 
> > This is inpsired by a similar patch by Laurent that introduced checks
> > for LVDS panels - this extends the checks to the reminaing type of
> 
> s/reminaing type/remaining types/
> 
> > connectors.
> > 
> > This is known to fail for some of the existing panels but added
> > despite this as we need help from people using the panels to
> > add the missing info.
> > The checks are not complete but will catch the most common mistakes.
> > The checks at the same time serves as documentation for the minimum
> > required description for a panel.
> > 
> > Signed-off-by: Sam Ravnborg 
> > Cc: Laurent Pinchart 
> > Cc: Thierry Reding 
> > Cc: Sam Ravnborg 
> > ---
> > 
> > This is my attempt on the validation described in the previous mail.
> > The assignment of default connector_type will then be a follow-up patch
> > to this.
> > 
> > Sam
> > 
> >  drivers/gpu/drm/panel/panel-simple.c | 32 ++--
> >  1 file changed, 30 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 2aff93accad5..025a7ccdfcb3 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -549,8 +549,12 @@ static int panel_simple_probe(struct device *dev, 
> > const struct panel_desc *desc)
> > panel_simple_parse_panel_timing_node(dev, panel, );
> > }
> >  
> > -   if (desc->connector_type == DRM_MODE_CONNECTOR_LVDS) {
> > -   /* Catch common mistakes for LVDS panels. */
> > +   /* Catch common mistakes for panels. */
> > +   switch (desc->connector_type) {
> > +   case 0:
> > +   WARN(desc->connector_type == 0, "specify missing 
> > connector_type\n");
> > +   break;
> > +   case DRM_MODE_CONNECTOR_LVDS:
> > WARN_ON(desc->bus_flags &
> > ~(DRM_BUS_FLAG_DE_LOW |
> >   DRM_BUS_FLAG_DE_HIGH |
> > @@ -564,6 +568,30 @@ static int panel_simple_probe(struct device *dev, 
> > const struct panel_desc *desc)
> > WARN_ON((desc->bus_format == MEDIA_BUS_FMT_RGB888_1X7X4_SPWG ||
> >  desc->bus_format == MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA) 
> > &&
> > desc->bpc != 8);
> > +   break;
> > +   case DRM_MODE_CONNECTOR_eDP:
> > +   WARN_ON(desc->bus_format == 0);
> > +   WARN_ON(desc->bpc != 6 && desc->bpc != 8);
> > +   break;
> > +   case DRM_MODE_CONNECTOR_DSI:
> > +   WARN_ON(desc->bpc != 6 && desc->bpc != 8);
> > +   break;
> > +   case DRM_MODE_CONNECTOR_DPI:
> > +   WARN_ON(desc->bus_flags &
> > +   ~(DRM_BUS_FLAG_DE_LOW |
> > + DRM_BUS_FLAG_DE_HIGH |
> > + DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE |
> > + DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
> > + DRM_BUS_FLAG_DATA_MSB_TO_LSB |
> > + DRM_BUS_FLAG_DATA_LSB_TO_MSB |
> > + DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE |
> > + DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE));
> > +   WARN_ON(desc->bus_format == 0);
> > +   WARN_ON(desc->bpc != 6 && desc->bpc != 8);
> > +   break;
> > +   default:
> > +   WARN(true, "panel has unknown connector_type: %d\n", 
> > desc->connector_type);
> > +   break;
> > }
> 
> The checks look sane to me. For LVDS we've added the WARN_ON after
> checking all LVDS panels [1], so the warning will only get displayed for
> new panel drivers. For other types of panel, this will cause lots of
> WARN_ON to trigger. On one hand it gets the issues noticed, which should
> help fixing them, but on the other hand it will also scare lots of users
> and developers. I'm not sure if we should downgrade that to a dev_warn()
> for some time until we get at least the majority of the issues fixed.
> Daniel, any opinion ?

We should be noisy, but not too noisy.
dev_warn() is fine, maybe only dev_info()?

Unless I get other feedback I will convert to dev_info() in the
next version of the patch.
Fixing all panels before we add the checks, is not feasible.
Access to datasheet is not easy/possible for many panels.

Sam


> 
> [1] Actually not quite, I've just sent "[PATCH] drm: panel: simple: Fix
> bpc for LG LB070WV8 panel" to fix one bpc issue.
> 
> > drm_panel_init(>base, dev, _simple_funcs,
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list

Re: [PATCH] drm: panel: simple: Fix bpc for LG LB070WV8 panel

2020-07-12 Thread Sam Ravnborg
On Sun, Jul 12, 2020 at 01:53:17AM +0300, Laurent Pinchart wrote:
> The LG LB070WV8 panel incorrectly reports a 16 bits per component value,
> while the panel uses 8 bits per component. Fix it.
> 
> Fixes: dd0150026901 ("drm/panel: simple: Add support for LG LB070WV8 800x480 
> 7" panel")
> Signed-off-by: Laurent Pinchart 

Applied to drm-misc-next.
Considered if this was -fixes material but the checks was only recently
introduced. So I assume the display drivers using this panel do not yet use
bpc. So it ended up in -next and not -fixes.

Sam

> ---
>  drivers/gpu/drm/panel/panel-simple.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 3a35f74d6cb7..dfb62821932a 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2365,7 +2365,7 @@ static const struct drm_display_mode lg_lb070wv8_mode = 
> {
>  static const struct panel_desc lg_lb070wv8 = {
>   .modes = _lb070wv8_mode,
>   .num_modes = 1,
> - .bpc = 16,
> + .bpc = 8,
>   .size = {
>   .width = 151,
>   .height = 91,
> -- 
> Regards,
> 
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

2020-07-12 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #61 from Christopher Snowhill (kod...@gmail.com) ---
It may be worth noting that I also haven't experienced this crash lately, and
one of the things I did recently was update my motherboard BIOS, which included
an update from AGESA 1.0.0.4 release 2, to 1.0.0.6am4.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 208333] Black screen with Kernel 5.8 rc1/2/3/4 with Nvidia Gtx 760 driver nouveau

2020-07-12 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208333

--- Comment #6 from Roberto Guerrini (robyguerr...@yahoo.it) ---
Il giorno lun, 06/07/2020 alle 05.10 +, bugzilla-
dae...@bugzilla.kernel.org ha scritto:
> https://bugzilla.kernel.org/show_bug.cgi?id=208333
> 
> Ilia Mirkin (imir...@alum.mit.edu) changed:
> 
>What|Removed |Added
> ---
> -
>  CC||imir...@alum.mit.edu
> 
> --- Comment #3 from Ilia Mirkin (imir...@alum.mit.edu) ---
> Has nouveau ever worked with this board? Can you get dmesg from a
> failing boot?
> 
> Unfortunately without logs, it's a bit hard to tell what's going on.
> Chances
> are the machine is fine, so you should be able to ssh in and get
> them. Or
> perhaps you can acquire logs from a previous boot, depending on your
> logging
> system.
> 

Basically I saw where the loading stops ... it stops at "Gnome Display
Manager" 
Gdm.service

Bye

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 208333] Black screen with Kernel 5.8 rc1/2/3/4 with Nvidia Gtx 760 driver nouveau

2020-07-12 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208333

--- Comment #5 from Roberto Guerrini (robyguerr...@yahoo.it) ---
Basically I saw where the loading stops ... it stops at "Started Gnome Display
Manager"
Gdm.service

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel