[PATCH 01/33] clk_ops: change round_rate() to return unsigned long

[Bryan O'Donoghue]

Right now it is not possible to return a value larger than LONG_MAX on 32
bit systems. You can pass a rate of ULONG_MAX but can't return anything
past LONG_MAX due to the fact both the rounded_rate and negative error
codes are represented in the return value of round_rate().

Most implementations either return zero on error or don't return error
codes at all. A minority of implementations do return a negative number -
typically -EINVAL or -ENODEV.

At the higher level then callers of round_rate() typically and rightly
check for a value of <= 0.

It is possible then to convert round_rate() to an unsigned long return
value and change error code indication for the minority from -ERRORCODE to
a simple 0.

This patch is the first step in making it possible to scale round_rate past
LONG_MAX, later patches will change the previously mentioned minority of
round_rate() implementations to return zero only on error if those
implementations currently return a negative error number. Implementations
that do not return an error code of < 0 will be left as-is.

Signed-off-by: Bryan O'Donoghue 
Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc: linux-o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-...@vger.kernel.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: patc...@opensource.cirrus.com
Cc: uclinux-h8-de...@lists.sourceforge.jp
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: freedr...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c|  4 ++--
 arch/arm/mach-omap2/clock2xxx.h |  4 ++--
 arch/arm/mach-vexpress/spc.c|  4 ++--
 arch/mips/alchemy/common/clock.c|  2 +-
 drivers/clk/at91/clk-audio-pll.c| 10 ++
 drivers/clk/at91/clk-h32mx.c|  5 +++--
 drivers/clk/at91/clk-peripheral.c   |  6 +++---
 drivers/clk/at91/clk-pll.c  |  2 +-
 drivers/clk/at91/clk-plldiv.c   |  5 +++--
 drivers/clk/at91/clk-smd.c  |  5 +++--
 drivers/clk/at91/clk-usb.c  |  5 +++--
 drivers/clk/axs10x/i2s_pll_clock.c  |  4 ++--
 drivers/clk/axs10x/pll_clock.c  |  5 +++--
 drivers/clk/bcm/clk-bcm2835.c   | 11 ++-
 drivers/clk/bcm/clk-iproc-asiu.c|  5 +++--
 drivers/clk/bcm/clk-iproc-pll.c |  8 
 drivers/clk/clk-axi-clkgen.c|  5 +++--
 drivers/clk/clk-cdce706.c   | 15 +--
 drivers/clk/clk-cdce925.c   | 15 +--
 drivers/clk/clk-composite.c |  5 +++--
 drivers/clk/clk-cs2000-cp.c |  4 ++--
 drivers/clk/clk-divider.c   |  5 +++--
 drivers/clk/clk-fixed-factor.c  |  5 +++--
 drivers/clk/clk-fractional-divider.c|  4 ++--
 drivers/clk/clk-gemini.c|  5 +++--
 drivers/clk/clk-highbank.c  | 10 ++
 drivers/clk/clk-hsdk-pll.c  |  4 ++--
 drivers/clk/clk-multiplier.c|  5 +++--
 drivers/clk/clk-scpi.c  |  8 
 drivers/clk/clk-si514.c |  4 ++--
 drivers/clk/clk-si5351.c| 15 +--
 drivers/clk/clk-si570.c |  4 ++--
 drivers/clk/clk-stm32f4.c   | 15 +--
 drivers/clk/clk-u300.c  |  4 ++--
 drivers/clk/clk-versaclock5.c   | 12 ++--
 drivers/clk/clk-vt8500.c|  9 +
 drivers/clk/clk-wm831x.c|  5 +++--
 drivers/clk/clk-xgene.c |  9 +
 drivers/clk/h8300/clk-h8s2678.c |  4 ++--
 drivers/clk/hisilicon/clk-hi6220-stub.c |  5 +++--
 drivers/clk/hisilicon/clkdivider-hi6220.c   |  5 +++--
 drivers/clk/imx/clk-busy.c  |  5 +++--
 drivers/clk/imx/clk-cpu.c   |  4 ++--
 drivers/clk/imx/clk-fixup-div.c |  5 +++--
 drivers/clk/imx/clk-pfd.c   |  4 ++--
 drivers/clk/imx/clk-pllv2.c |  4 ++--
 drivers/clk/imx/clk-pllv3.c | 19 +++
 drivers/clk/ingenic/cgu.c   |  4 ++--
 drivers/clk/ingenic/jz4780-cgu.c|  5 +++--
 drivers/clk/mediatek/clk-pll.c  |  4 ++--
 

Re: [Nouveau] [PATCH] drm/nouveau/hwmon: Uninitialized variables in sysfs

[Pierre Moreau]

Ping: this can still be an issue today as kstrtol() & co haven’t changed their
possible return value since the patch was written.

On 2017-07-22 — 14:13, Pierre Moreau wrote:
> Reviewed-by: Pierre Moreau 
> 
> On 2017-07-17 — 11:17, Dan Carpenter wrote:
> > kstrtol() and friends can return -EINVAL or -ERANGE.  We have to test
> > for both, otherwise the value is possibly uninitialized.  Also in some
> > of these files we accidentally return "count" on error instead of a
> > negative error code.
> > 
> > Signed-off-by: Dan Carpenter 
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
> > b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> > index 7c965648df80..5e75af91c446 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> > @@ -68,9 +68,11 @@ nouveau_hwmon_set_temp1_auto_point1_temp(struct device 
> > *d,
> > struct nouveau_drm *drm = nouveau_drm(dev);
> > struct nvkm_therm *therm = nvxx_therm(>client.device);
> > long value;
> > +   int ret;
> >  
> > -   if (kstrtol(buf, 10, ) == -EINVAL)
> > -   return count;
> > +   ret = kstrtol(buf, 10, );
> > +   if (ret)
> > +   return ret;
> >  
> > therm->attr_set(therm, NVKM_THERM_ATTR_THRS_FAN_BOOST,
> > value / 1000);
> > @@ -101,9 +103,11 @@ nouveau_hwmon_set_temp1_auto_point1_temp_hyst(struct 
> > device *d,
> > struct nouveau_drm *drm = nouveau_drm(dev);
> > struct nvkm_therm *therm = nvxx_therm(>client.device);
> > long value;
> > +   int ret;
> >  
> > -   if (kstrtol(buf, 10, ) == -EINVAL)
> > -   return count;
> > +   ret = kstrtol(buf, 10, );
> > +   if (ret)
> > +   return ret;
> >  
> > therm->attr_set(therm, NVKM_THERM_ATTR_THRS_FAN_BOOST_HYST,
> > value / 1000);
> > @@ -156,8 +160,9 @@ nouveau_hwmon_set_pwm1_min(struct device *d, struct 
> > device_attribute *a,
> > long value;
> > int ret;
> >  
> > -   if (kstrtol(buf, 10, ) == -EINVAL)
> > -   return -EINVAL;
> > +   ret = kstrtol(buf, 10, );
> > +   if (ret)
> > +   return ret;
> >  
> > ret = therm->attr_set(therm, NVKM_THERM_ATTR_FAN_MIN_DUTY, value);
> > if (ret < 0)
> > @@ -179,8 +184,9 @@ nouveau_hwmon_set_pwm1_max(struct device *d, struct 
> > device_attribute *a,
> > long value;
> > int ret;
> >  
> > -   if (kstrtol(buf, 10, ) == -EINVAL)
> > -   return -EINVAL;
> > +   ret = kstrtol(buf, 10, );
> > +   if (ret)
> > +   return ret;
> >  
> > ret = therm->attr_set(therm, NVKM_THERM_ATTR_FAN_MAX_DUTY, value);
> > if (ret < 0)
> > ___
> > Nouveau mailing list
> > nouv...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau



> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau



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

Re: [Nouveau] drm/nouveau: Remove no longer needed local ACPI_VIDEO_NOTIFY_PROBE define

[Pierre Moreau]

Ping

On 2017-07-22 — 13:54, Pierre Moreau wrote:
> Reviewed-by: Pierre Moreau 
> 
> On 2017-06-21 — 15:19, Hans de Goede wrote:
> > Hi,
> > 
> > On 26-05-17 09:35, Hans De Goede wrote:
> > > The local #define of ACPI_VIDEO_NOTIFY_PROBE was only added temporarily
> > > to avoid a dependency between the acpi and nouveau trees while merging.
> > > 
> > > This is now properly defined in acpi/video.h and the local #define can
> > > be dropped.
> > > 
> > > Signed-off-by: Hans de Goede 
> > 
> > ping, what is the status of this patch ?
> > 
> > Regards,
> > 
> > Hans
> > 
> > 
> > > ---
> > >   drivers/gpu/drm/nouveau/nouveau_display.c | 9 -
> > >   1 file changed, 9 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> > > b/drivers/gpu/drm/nouveau/nouveau_display.c
> > > index 549763f5e17d..70de2079b2cc 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> > > @@ -369,15 +369,6 @@ nouveau_display_hpd_work(struct work_struct *work)
> > >   #ifdef CONFIG_ACPI
> > > -/*
> > > - * Hans de Goede: This define belongs in acpi/video.h, I've submitted a 
> > > patch
> > > - * to the acpi subsys to move it there from drivers/acpi/acpi_video.c .
> > > - * This should be dropped once that is merged.
> > > - */
> > > -#ifndef ACPI_VIDEO_NOTIFY_PROBE
> > > -#define ACPI_VIDEO_NOTIFY_PROBE  0x81
> > > -#endif
> > > -
> > >   static int
> > >   nouveau_display_acpi_ntfy(struct notifier_block *nb, unsigned long val,
> > > void *data)
> > > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel



> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau



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

[Bug 198221] nouveau DRM driver scheduling invalid work

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198221

--- Comment #5 from Petr Vandrovec (p...@vandrovec.name) ---
Yes, it fixes the crash. I am not sure what impact have holding lock for longer
time, but I didn't notice anything bad.

-- 
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 198221] nouveau DRM driver scheduling invalid work

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198221

Pierre Moreau (pierre.mor...@free.fr) changed:

   What|Removed |Added

 CC||pierre.mor...@free.fr

--- Comment #4 from Pierre Moreau (pierre.mor...@free.fr) ---
Hello,

This should be fixed by
https://github.com/skeggsb/nouveau/commit/b372d7330c41be5b751187821ab81d91295c847d.
Could you please confirm whether it does fix it for you?

-- 
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 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104412

--- Comment #5 from dwagner  ---
(My above referenced commit ID was valid for an older version of the
amd-staging-drm-next git branch - to find the same commit in the kernel git
branch you use, search for "drm/amd/display: Block 6Ghz timing if SBIOS set
HDMI_6G_en to 0" in the output of "git log". Reverting this patch still solves
the problem for me.)

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

[Bug 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104412

--- Comment #4 from dwagner  ---
You might experience the same issue as I did, read
https://bugs.freedesktop.org/show_bug.cgi?id=102820 for details.

The bottom line of which is: Unless you revert commit
ebbf7337e2daacacef3e01114e6be68a2a4f11b4 the amdgpu driver will look at one bit
of the GPU BIOS ROM and determine from the value in there that your GPU is
unworthy of enabling HDMI 2.0 modes exceeding a pixel clock of 300MHz - even if
those modes work perfectly fine with both your GPU and your display, also under
different operating systems.

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

Re: GPF with kernel 4.15-rc1, and display locks up

[Jani Nikula]

On Mon, 27 Nov 2017, Mike Keehan  wrote:
> I am getting a General Protection Fault on 4.15-rc1, and the X11 screen
> locks up.

Catching up with some old mails... Is this still an issue? Please file a
bug at [1].

BR,
Jani.


[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel


>
>
> Nov 27 10:16:37 babelfish kernel: Call Trace:
> Nov 27 10:16:37 babelfish kernel:  ?
> __i915_gem_object_flush_for_display+0x13/0x40 [i915]
> Nov 27 10:16:37 babelfish kernel:
> i915_gem_object_wait_priority+0xb2/0x170 [i915]
> Nov 27 10:16:37 babelfish kernel:  intel_prepare_plane_fb+0x16e/0x2e0
> [i915]
> Nov 27 10:16:37 babelfish kernel:
> drm_atomic_helper_prepare_planes+0x4c/0xd0
> Nov 27 10:16:37 babelfish kernel:  intel_atomic_commit+0xa3/0x280 [i915]
> Nov 27 10:16:37 babelfish kernel:  drm_atomic_helper_page_flip+0x7c/0x90
> Nov 27 10:16:37 babelfish kernel:  drm_mode_page_flip_ioctl+0x4c2/0x530
> Nov 27 10:16:37 babelfish kernel:  ? drm_mode_cursor2_ioctl+0x10/0x10
> Nov 27 10:16:37 babelfish kernel:  drm_ioctl_kernel+0x59/0xb0
> Nov 27 10:16:37 babelfish kernel:  drm_ioctl+0x2cb/0x380
> Nov 27 10:16:37 babelfish kernel:  ? drm_mode_cursor2_ioctl+0x10/0x10
> Nov 27 10:16:37 babelfish kernel:  ? vfs_writev+0xb9/0x110
> Nov 27 10:16:37 babelfish kernel:  do_vfs_ioctl+0xa1/0x610
> Nov 27 10:16:37 babelfish kernel:  SyS_ioctl+0x74/0x80
> Nov 27 10:16:37 babelfish kernel:  entry_SYSCALL_64_fastpath+0x13/0x6c
>
> I have attached the full GPF trace.
>
> (Haven't tried to login with ssh yet.)
>
> Mike.
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104143] r600/sb: clobbers gl_Position -> gl_FragCoord

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104143

Gert Wollny  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #11 from Gert Wollny  ---
Fixed with commit 6c268ea79af80a65a89a23854bdbe8bc1e99ab23

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

Re: [0/5] video-SMSC UFX: Adjustments for five function implementations

[SF Markus Elfring]

>>   Delete an error message for a failed memory allocation in two functions
> 
> This patch removes the information about the device for which the allocation 
> fails.

Should a Linux allocation failure report be sufficient here?


>>   Less checks in ufx_usb_probe() after error detection
> 
> This patch depends on the earlier patch (which is not being merged)

Partly, yes.


> so please re-base it if you want it to be applied.

Would you dare to pick another change possibility up from a patch hunk?


>>   Adjust three checks for null pointers
> 
> This patch contains unrelated change ({} braces addition) which should be 
> dropped.

I presented such an update approach so that warnings from the script 
“checkpatch.pl”
will be fixed together.

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

Re: [PATCH 0/5] video-SMSC UFX: Adjustments for five function implementations

[Bartlomiej Zolnierkiewicz]

On Saturday, November 25, 2017 09:42:57 PM SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 25 Nov 2017 21:38:42 +0100
> 
> A few update suggestions were taken into account
> from static source code analysis.
> 
> Markus Elfring (5):
>   Delete an error message for a failed memory allocation in two functions

This patch removes the information about the device for which the allocation
fails.

>   Less checks in ufx_usb_probe() after error detection

This patch depends on the earlier patch (which is not being merged) so please
re-base it if you want it to be applied.

>   Return an error code only as a constant in ufx_realloc_framebuffer()

ditto

>   Improve a size determination in two functions

Patch queued for 4.16, thanks.

>   Adjust three checks for null pointers

This patch contains unrelated change ({} braces addition) which should be
dropped.

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

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

Re: [0/2] video: ssd1307fb: Adjustments for ssd1307fb_probe()

[SF Markus Elfring]

>>   Delete an error message for a failed memory allocation
> 
> This patch removes the information about the device for which the allocation 
> fails.

How do you think about to take another look if a Linux allocation failure report
could be sufficient in this use case?


>>   Improve a size determination
> 
> This patch depends on the earlier patch (which is not being merged)

Partly, yes.


> so please re-base it if you want it to be applied.

Would you dare to reduce any context lines for this update step so that
such a small adjustment will still work?

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

Re: [PATCH 0/2] video: ssd1307fb: Adjustments for ssd1307fb_probe()

[Bartlomiej Zolnierkiewicz]

On Saturday, November 25, 2017 05:04:02 PM SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 25 Nov 2017 16:56:46 +0100
> 
> Two update suggestions were taken into account
> from static source code analysis.
> 
> Markus Elfring (2):
>   Delete an error message for a failed memory allocation

This patch removes the information about the device for which the allocation
fails.

>   Improve a size determination

This patch depends on the earlier patch (which is not being merged) so please
re-base it if you want it to be applied.

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

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

Re: [0/4] video-UDLFB: Adjustments for five function implementations

[SF Markus Elfring]

>>   Delete an error message for a failed memory allocation in two functions
> 
> This patch removes the information about the device for which the allocation 
> fails.

* Do you find a Linux allocation failure report insufficient in this use case?

* Are you looking for any more clarification?


>>   Improve a size determination in dlfb_alloc_urb_list()
> 
> Patch queued for 4.16, thanks.

Thanks for your acceptance of other change possibilities.

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

Re: [PATCH] video/fbdev/stifb: Delete an error message for a failed memory allocation in stifb_init_fb()

[Bartlomiej Zolnierkiewicz]

On Friday, November 24, 2017 10:30:34 PM Rolf Eike Beer wrote:
> Markus Elfring wrote:
> > From: Markus Elfring 
> > Date: Fri, 24 Nov 2017 22:22:06 +0100
> > 
> > Omit an extra message for a memory allocation failure in this function.
> > 
> > This issue was detected by using the Coccinelle software.
> > 
> > Signed-off-by: Markus Elfring 
> > ---
> >  drivers/video/fbdev/stifb.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
> > index 6ded5c198998..fe217a2f7d21 100644
> > --- a/drivers/video/fbdev/stifb.c
> > +++ b/drivers/video/fbdev/stifb.c
> > @@ -1126,10 +1126,8 @@ static int __init stifb_init_fb(struct sti_struct
> > *sti, int bpp_pref) int bpp, xres, yres;
> > 
> > fb = kzalloc(sizeof(*fb), GFP_ATOMIC);
> > -   if (!fb) {
> > -   printk(KERN_ERR "stifb: Could not allocate stifb structure\n");
> > +   if (!fb)
> > return -ENODEV;
> > -   }
> > 
> > info = >info;
> 
> This should be -ENOMEM.

Markus, please fix this issue first (before doing cleanups).

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

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

Re: [PATCH 0/4] video-UDLFB: Adjustments for five function implementations

[Bartlomiej Zolnierkiewicz]

On Friday, November 24, 2017 09:48:14 PM SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 24 Nov 2017 21:45:54 +0100
> 
> A few update suggestions were taken into account
> from static source code analysis.
> 
> Markus Elfring (4):
>   Delete an error message for a failed memory allocation in two functions

This patch removes the information about the device for which the allocation
fails.

>   Return an error code only as a constant in dlfb_realloc_framebuffer()

This patch depends on the earlier patch (which is not being merged) so please
re-base it if you want it to be applied.

>   Improve a size determination in dlfb_alloc_urb_list()

Patch queued for 4.16, thanks.

>   Delete an unnecessary return statement in two functions

Patch queued for 4.16, thanks.
 
>  drivers/video/fbdev/udlfb.c | 23 +--
>  1 file changed, 5 insertions(+), 18 deletions(-)

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

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

Re: [PATCH] video/fbdev/vt8500lcdfb: Delete an error message for a failed memory allocation in vt8500lcd_probe()

[Bartlomiej Zolnierkiewicz]

On Friday, November 24, 2017 08:53:02 PM SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 24 Nov 2017 20:42:08 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/video/fbdev/vt8500lcdfb.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/vt8500lcdfb.c 
> b/drivers/video/fbdev/vt8500lcdfb.c
> index 1a1176bf0906..5c5cd2923041 100644
> --- a/drivers/video/fbdev/vt8500lcdfb.c
> +++ b/drivers/video/fbdev/vt8500lcdfb.c
> @@ -289,10 +289,8 @@ static int vt8500lcd_probe(struct platform_device *pdev)
>  
>   fbi = devm_kzalloc(>dev, sizeof(struct vt8500lcd_info)
>   + sizeof(u32) * 16, GFP_KERNEL);
> - if (!fbi) {
> - dev_err(>dev, "Failed to initialize framebuffer 
> device\n");
> + if (!fbi)
>   return -ENOMEM;
> - }
>  

This removes the information about the device for which the allocation
fails (but as there can be only one vt8500lcdfb device in the system this
change is okay).

Patch queued for 4.16, thanks.

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

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

Re: [PATCH] video/fbdev/wm8505fb: Delete an error message for a failed memory allocation in wm8505fb_probe()

[Bartlomiej Zolnierkiewicz]

On Friday, November 24, 2017 08:30:04 PM SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 24 Nov 2017 20:22:10 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/video/fbdev/wm8505fb.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/video/fbdev/wm8505fb.c
> index 253ffe9baab2..8f0d5379861d 100644
> --- a/drivers/video/fbdev/wm8505fb.c
> +++ b/drivers/video/fbdev/wm8505fb.c
> @@ -276,10 +276,8 @@ static int wm8505fb_probe(struct platform_device *pdev)
>  
>   fbi = devm_kzalloc(>dev, sizeof(struct wm8505fb_info) +
>   sizeof(u32) * 16, GFP_KERNEL);
> - if (!fbi) {
> - dev_err(>dev, "Failed to initialize framebuffer 
> device\n");
> + if (!fbi)
>   return -ENOMEM;
> - }

This removes the information about the device for which the allocation
fails (but as there can be only one wm8505fb device in the system this
change is okay).

Patch queued for 4.16, thanks.

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

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

Re: [PATCH] video: fbdev: remove redundant self assignment of 'height'

[Bartlomiej Zolnierkiewicz]

On Thursday, November 23, 2017 10:55:53 AM Colin King wrote:
> From: Colin Ian King 
> 
> The assignment of height to itself is redundant and can be removed.
> Detected with Coccinelle.
> 
> Signed-off-by: Colin Ian King 

Patch queued for 4.16, thanks.

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

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

Re: [PATCH] video: fbdev: atmel_lcdfb: fix display-timings lookup

[Bartlomiej Zolnierkiewicz]

On Monday, November 13, 2017 11:27:19 AM Johan Hovold wrote:
> Fix child-node lookup during probe, which ended up searching the whole
> device tree depth-first starting at the parent rather than just matching
> on its children.
> 
> To make things worse, the parent display node was also prematurely
> freed.
> 
> Note that the display and timings node references are never put after a
> successful dt-initialisation so the nodes would leak on later probe
> deferrals and on driver unbind.
> 
> Fixes: b985172b328a ("video: atmel_lcdfb: add device tree suport")
> Cc: stable  # 3.13
> Cc: Jean-Christophe PLAGNIOL-VILLARD 
> Signed-off-by: Johan Hovold 

Patch queued for 4.16, thanks.

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

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

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Jani Nikula]

On Tue, 19 Dec 2017, Daniel Vetter  wrote:
> On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote:
>> Dear fbdev and fbcon developers,
>> 
>> Thank you very much for your input for the first patch series.
>> 
>> I've included your feedback into this second roll, and kindly ask for
>> your opinion on the new patch series.
>
> Ok I've realized that my assumptions about why you need this aren't
> holding up.
>
> So from reading these patches it sounded like you want an in-kernel boot
> splash because that would be on the display faster than a userspace one
> like plymouth. That's the only reasons I can see for this (if there's
> another good justification, please bring it up).
>
> I only know of very embedded setups (tv top boxes, in vehicle
> entertainment) where that kind of "time to first image" really matters,
> and those systems:
> - have a real hw kms driver
> - don't have fbcon or fbdev emulation enabled (except for some closed
>   source stacks that are a bit slow to adapt to the new world, and we
>   don't care about those in gfx).
>
> But from discussions it sounds like you very much want to use this on
> servers, which makes 0 sense to me. On a server something like plymouth
> should do a perfectly reasonable job.
>
> So, why exactly do we need this?

Okay, I'll take another step back from the implementation and most of
the discussion here, and look at what *I* would like to see on screen
when I have my user hat on and my kernel developer hat securely stowed
away.

I think the first issue is the boot manager (e.g. grub) messing up
whatever the BIOS or GOP or whatever drew. If I don't touch any buttons,
I'd prefer the Lenovo or VAIO or NUC or whatever logo stay there. IIRC
some BIOSes let you set up your own splash if you like, though that's
not really relevant for me. So already the boot manager takeover is a
problem.

The next issue is the framebuffer driver takeover. It's not unlike the
above, just one step further. If you like your grub image to stay there,
let it stay there. (Or, if the boot manager was nice enough to not mess
up the screen, let the BIOS image stay there.) All the way to KMS and
userspace.

IMHO the user friendly experience is already gone by the time we reach
any kernel/userspace bootsplash. We want our command-line tools to STFU
if they don't have anything interesting to say. As a user, 99.99+% of
the time I don't care what grub or dmesg have to say.

Of course, with the kernel developer hat on, I want all of the clues
every time in case something goes wrong. But this shouldn't have to be
mutually exclusive.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 97909] X-Plane 10 crashes with SIGSEGV on radeonsi

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97909

Thomas Rohloff  changed:

   What|Removed |Added

 CC||v10la...@myway.de

--- Comment #9 from Thomas Rohloff  ---
(In reply to Nicolai Hähnle from comment #5)
> Okay, so I could reproduce this after all with the web demo.
> 
> There is a bug in X-Plane and also questionable behaviour of the driver. The
> bug in X-Plane is that it uses GL_AMD_pinned_memory with a size that is not
> a multiple of a page; as per the spec, the driver is allowed to reject that,
> and we do (apparently unlike the closed source driver...). X-Plane doesn't
> check this error condition, and continues rendering, hence the crash, which
> would also happen with a simple sequence of:
> 
>   glGenBuffers(1, );
>   glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, bo);
>   glDrawElements(...);
> 
> Somewhat surprisingly, the OpenGL spec never states that a draw call that
> goes outside the element/index buffer should flag a GL_INVALID_OPERATION.
> There is also no mention of this in the GL_ARB_robust_buffer_access_behavior
> extension, which is surprising.
> 
> The patch you provide may or may not go in the right direction - I'm not
> sure. If we want to check that, we should do it in api_validate.c, but I'm
> not convinced that we should. Meanwhile, that check wouldn't properly fix
> the issue in X-Plane. To work around the bug in X-Plane, you need to run
> with:
> 
> MESA_EXTENSION_OVERRIDE=-GL_AMD_pinned_memory ./X-Plane-x86_64 --force_run
> 
> which will work with an unmodified driver.

I opened a bug report at X-Plane and will inform you in case they reply.

BTW: Should I open a new bug report for the r600 bug (see below) ?

Here the message I wrote to the X-Plane devs:

Subject: Bug report: Wrog usage of GL_AMD_pinned_memory leads to undefined
result on Mesa drivers

From= v10la...@myway.de
IP= [SNIPPED]
Product= XPlane
Version= 11.11
OS= Linux
Summary= Wrog usage of GL_AMD_pinned_memory leads to undefined behavior on Mesa
drivers
Description= "The bug in X-Plane is that it uses GL_AMD_pinned_memory with a
size that is not a multiple of a page; as per the spec, the driver is allowed
to reject that, and we do (apparently unlike the closed source driver...).
X-Plane doesn't check this error condition, and continues rendering, hence the
crash" - Source: https://bugs.freedesktop.org/show_bug.cgi?id=97909#c5

Similar things as described in the linked bug report are happening on other
Mesa drivers, too. For example see this stacktrace from r600:

[ 1930.559125] general protection fault:  [#1] PREEMPT SMP
[ 1930.559980] Modules linked in: snd_seq_midi snd_usb_audio snd_hwdep
snd_usbmidi_lib snd_rawmidi vboxpci(O) vboxnetadp(O) vboxnetflt(O) nfsd
vboxdrv(O)
[ 1930.560867] CPU: 2 PID: 646 Comm: kworker/2:2 Tainted: G   O   
4.13.0 #9
[ 1930.561771] Hardware name: To be filled by O.E.M. To be filled by
O.E.M./SABERTOOTH 990FX R2.0, BIOS 2901 05/04/2016
[ 1930.562657] Workqueue: events radeon_mn_destroy
[ 1930.563588] task: a246244e5b00 task.stack: a5f0409a
[ 1930.564509] RIP: 0010:__mutex_lock.isra.1+0x82/0x518
[ 1930.565425] RSP: 0018:a5f0409a3d60 EFLAGS: 00010282
[ 1930.566312] RAX: 80015e292268 RBX: a2435d99c228 RCX:
80015e29226f
[ 1930.567238] RDX: 80015e29226f RSI: a246244e5b00 RDI:
b2a04c10
[ 1930.568174] RBP: a5f0409a3df0 R08: a2435d99c200 R09:
00010027
[ 1930.569124] R10: a5f0409a3e10 R11: a2462c079ac0 R12:
a2463ec9c400
[ 1930.570037] R13: a2435d99f9e8 R14: a2463ec98300 R15:
0002
[ 1930.570982] FS:  () GS:a2463ec8()
knlGS:
[ 1930.571938] CS:  0010 DS:  ES:  CR0: 80050033
[ 1930.572894] CR2: 00ed7000 CR3: 0003c8c51000 CR4:
000406e0
[ 1930.573857] Call Trace:
[ 1930.574783]  ? __slab_free.isra.68+0x7a/0x210
[ 1930.575744]  ? __slab_free.isra.68+0x7a/0x210
[ 1930.576698]  ? radeon_mn_destroy+0x3a/0x188
[ 1930.577650]  ? radeon_mn_destroy+0x3a/0x188
[ 1930.578577]  ? process_one_work+0x151/0x2d0
[ 1930.579515]  ? worker_thread+0x1f0/0x380
[ 1930.580450]  ? kthread+0xf2/0x128
[ 1930.581381]  ? process_one_work+0x2d0/0x2d0
[ 1930.582309]  ? kthread_create_on_node+0x40/0x40
[ 1930.583195]  ? ret_from_fork+0x22/0x30
[ 1930.584100] Code: 85 c0 0f 84 31 02 00 00 65 48 8b 04 25 80 c2 00 00 48 8b
00 a8 08 75 23 e8 dc be 72 ff 49 8b 45 00 48 83 e0 f8 0f 84 3e 02 00 00 <8b> 58
60 e8 ee be 72 ff 85 db 0f 85 33 02 00 00 65 48 8b 04 25 
[ 1930.585083] RIP: __mutex_lock.isra.1+0x82/0x518 RSP: a5f0409a3d60
[ 1930.592739] ---[ end trace 397a922d2c74a9bd ]---
[ 1932.388592] sched: RT throttling activated
[ 1935.978694] note: kworker/2:2[646] exited with preempt_count 1 
Steps= Run X-Plane 11 on Linux with Mesa drivers.

-- 
You are 

[PATCH] drm/vc4: Move IRQ enable to PM path

[Stefan Schake]

We were calling enable_irq on bind, where it was already enabled previously
by the IRQ helper. Additionally, dev->irq is not set correctly until after
postinstall and so was always zero here, triggering a warning in 4.15.
Fix both by moving the enable to the power management resume path, where we
know there was a previous disable invocation during suspend.

Fixes: 253696ccd613 ("drm/vc4: Account for interrupts in flight")
Signed-off-by: Stefan Schake 
---
I tested replacing the enable/disable dance with just synchronize_irq,
but that only made the original kernel OOPS more sporadic.

 drivers/gpu/drm/vc4/vc4_irq.c | 3 ---
 drivers/gpu/drm/vc4/vc4_v3d.c | 3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
index 26eddbb..3dd62d7 100644
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -209,9 +209,6 @@
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);
 
-   /* Undo the effects of a previous vc4_irq_uninstall. */
-   enable_irq(dev->irq);
-
/* Enable both the render done and out of memory interrupts. */
V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS);
 
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index 622cd43..493f392b 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -327,6 +327,9 @@ static int vc4_v3d_runtime_resume(struct device *dev)
return ret;
 
vc4_v3d_init_hw(vc4->dev);
+
+   /* We disabled the IRQ as part of vc4_irq_uninstall in suspend. */
+   enable_irq(vc4->dev->irq);
vc4_irq_postinstall(vc4->dev);
 
return 0;
-- 
1.9.1

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

[Bug 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104412

--- Comment #3 from S.H.  ---
Sorry, pressed the send button too early.

For anyone willing to help, here's my system:
- kernel-4.15-rc5
- xf86-video-amdgpu-1.4.0
- xorg-server-1.19.6
- Sapphire RX 460
- iiyama G-Master GB2888UHSU 

If you need any further information/testing/answers please don't hesitate to
contact me.

Thank you

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

[Bug 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104412

--- Comment #2 from S.H.  ---
Added drm parts of dmesg and Xorg.0.log file.

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

[Bug 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104412

--- Comment #1 from S.H.  ---
Created attachment 136446
  --> https://bugs.freedesktop.org/attachment.cgi?id=136446=edit
Xorg.0.log

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

[Bug 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104412

Bug ID: 104412
   Summary: RX 460 HDMI 4k 60fps not working, DisplayPort is.
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: an...@aikq.org

Created attachment 136445
  --> https://bugs.freedesktop.org/attachment.cgi?id=136445=edit
drm grep of dmesg

As far as I understand with the release of kernel-4.15-rc 4k 60Hz over HDMI
should be supported with amdgpu and RX-460.
I can't get it to work. 
Displayport works fine.
HDMI Port and cabling tested with Windows and XBOX One X, both use 60Hz over
HDMI, only my linux box refuses to use 60Hz.

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

Re: [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv

[Tomeu Vizoso]

On 26 December 2017 at 19:19, Matt Roper  wrote:
> On Wed, Dec 20, 2017 at 10:59:57AM +0100, Daniel Vetter wrote:
>> On Tue, Dec 19, 2017 at 03:27:31PM -0800, Dongwon Kim wrote:
>> > I forgot to include this brief information about this patch series.
>> >
>> > This patch series contains the implementation of a new device driver,
>> > hyper_dmabuf, which provides a method for DMA-BUF sharing across
>> > different OSes running on the same virtual OS platform powered by
>> > a hypervisor.
>> >
>> > Detailed information about this driver is described in a high-level doc
>> > added by the second patch of the series.
>> >
>> > [RFC PATCH 02/60] hyper_dmabuf: added a doc for hyper_dmabuf sharing
>> >
>> > I am attaching 'Overview' section here as a summary.
>> >
>> > --
>> > Section 1. Overview
>> > --
>> >
>> > Hyper_DMABUF driver is a Linux device driver running on multiple Virtual
>> > achines (VMs), which expands DMA-BUF sharing capability to the VM 
>> > environment
>> > where multiple different OS instances need to share same physical data 
>> > without
>> > data-copy across VMs.
>> >
>> > To share a DMA_BUF across VMs, an instance of the Hyper_DMABUF drv on the
>> > exporting VM (so called, “exporter”) imports a local DMA_BUF from the 
>> > original
>> > producer of the buffer, then re-exports it with an unique ID, 
>> > hyper_dmabuf_id
>> > for the buffer to the importing VM (so called, “importer”).
>> >
>> > Another instance of the Hyper_DMABUF driver on importer registers
>> > a hyper_dmabuf_id together with reference information for the shared 
>> > physical
>> > pages associated with the DMA_BUF to its database when the export happens.
>> >
>> > The actual mapping of the DMA_BUF on the importer’s side is done by
>> > the Hyper_DMABUF driver when user space issues the IOCTL command to access
>> > the shared DMA_BUF. The Hyper_DMABUF driver works as both an importing and
>> > exporting driver as is, that is, no special configuration is required.
>> > Consequently, only a single module per VM is needed to enable cross-VM 
>> > DMA_BUF
>> > exchange.
>>
>> So I know that most dma-buf implementations (especially lots of importers
>> in drivers/gpu) break this, but fundamentally only the original exporter
>> is allowed to know about the underlying pages. There's various scenarios
>> where a dma-buf isn't backed by anything like a struct page.
>>
>> So your first step of noodling the underlying struct page out from the
>> dma-buf is kinda breaking the abstraction, and I think it's not a good
>> idea to have that. Especially not for sharing across VMs.
>>
>> I think a better design would be if hyper-dmabuf would be the dma-buf
>> exporter in both of the VMs, and you'd import it everywhere you want to in
>> some gpu/video/whatever driver in the VMs. That way hyper-dmabuf is always
>> in control of the pages, and a lot of the troubling forwarding you
>> currently need to do disappears.
>
> I think one of the main driving use cases here is for a "local" graphics
> compositor inside the VM to accept client buffers from unmodified
> applications and then pass those buffers along to a "global" compositor
> running in the service domain.  This would allow the global compositor
> to composite applications running in different virtual machines (and
> possibly running under different operating systems).
>
> If we require that hyper-dmabuf always be the exporter, that complicates
> things a little bit since a buffer allocated via regular interfaces (GEM
> ioctls or whatever) wouldn't be directly transferrable to the global
> compositor.  For graphics use cases like this, we could probably hide a
> lot of the details by modifying/replacing the EGL implementation that
> handles the details of buffer allocation.  However if we have
> applications that are themselves just passing along externally-allocated
> buffers (e.g., images from a camera device), we'd probably need to
> modify those applications and/or the drivers they get their content
> from.

There's also non-GPU-rendering clients that pass SHM buffers to the compositor.

For now, a Wayland proxy in the guest is copying the client-provided
buffers to virtio-gpu resources at the appropriate times, which also
need to be copied once more to host memory. Would be great to reduce
the number of copies that that implies.

For more on this effort:

https://patchwork.kernel.org/patch/10134603/

Regards,

Tomeu

>
> Matt
>
>>
>> 2nd thing: This seems very much related to what's happening around gvt and
>> allowing at least the host (in a kvm based VM environment) to be able to
>> access some of the dma-buf (or well, framebuffers in general) that the
>> client is using. Adding some mailing lists for that.
>> -Daniel
>>
>> >
>> > 

[PATCH 4.15] drm/amd/display: call set csc_default if enable adjustment is false

[Daniel Drake]

From: Yue Hin Lau 

Signed-off-by: Yue Hin Lau 
Reviewed-by: Eric Bernstein 
Acked-by: Harry Wentland 
Signed-off-by: Alex Deucher 
[dr...@endlessm.com: backport to 4.15]
Signed-off-by: Daniel Drake 
---
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h  | 2 +-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c   | 6 ++
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 ++
 drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h   | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

Testing Acer Aspire TC-380 engineering sample (Raven Ridge), the display
comes up with an excessively green tint. This patch (from amd-staging-drm-next)
solves the issue. Can it be included in Linux 4.15?

diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h
index a9782b1aba47..34daf895f848 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h
@@ -1360,7 +1360,7 @@ void dpp1_cm_set_output_csc_adjustment(
 
 void dpp1_cm_set_output_csc_default(
struct dpp *dpp_base,
-   const struct default_adjustment *default_adjust);
+   enum dc_color_space colorspace);
 
 void dpp1_cm_set_gamut_remap(
struct dpp *dpp,
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c
index 40627c244bf5..ed1216b53465 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c
@@ -225,14 +225,13 @@ void dpp1_cm_set_gamut_remap(
 
 void dpp1_cm_set_output_csc_default(
struct dpp *dpp_base,
-   const struct default_adjustment *default_adjust)
+   enum dc_color_space colorspace)
 {
 
struct dcn10_dpp *dpp = TO_DCN10_DPP(dpp_base);
uint32_t ocsc_mode = 0;
 
-   if (default_adjust != NULL) {
-   switch (default_adjust->out_color_space) {
+   switch (colorspace) {
case COLOR_SPACE_SRGB:
case COLOR_SPACE_2020_RGB_FULLRANGE:
ocsc_mode = 0;
@@ -253,7 +252,6 @@ void dpp1_cm_set_output_csc_default(
case COLOR_SPACE_UNKNOWN:
default:
break;
-   }
}
 
REG_SET(CM_OCSC_CONTROL, 0, CM_OCSC_MODE, ocsc_mode);
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
index 961ad5c3b454..05dc01e54531 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
@@ -2097,6 +2097,8 @@ static void program_csc_matrix(struct pipe_ctx *pipe_ctx,
tbl_entry.color_space = color_space;
//tbl_entry.regval = matrix;

pipe_ctx->plane_res.dpp->funcs->opp_set_csc_adjustment(pipe_ctx->plane_res.dpp, 
_entry);
+   } else {
+   
pipe_ctx->plane_res.dpp->funcs->opp_set_csc_default(pipe_ctx->plane_res.dpp, 
colorspace);
}
 }
 static bool is_lower_pipe_tree_visible(struct pipe_ctx *pipe_ctx)
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h 
b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
index 83a68460edcd..9420dfb94d39 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
@@ -64,7 +64,7 @@ struct dpp_funcs {
 
void (*opp_set_csc_default)(
struct dpp *dpp,
-   const struct default_adjustment *default_adjust);
+   enum dc_color_space colorspace);
 
void (*opp_set_csc_adjustment)(
struct dpp *dpp,
-- 
2.14.1

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

Re: [git pull] drm fixes for 4.15-rc6

[Jani Nikula]

On Thu, 28 Dec 2017, Randy Dunlap  wrote:
> It would be good to get this documentation build error patch
> merged into 4.15.  Daniel Vetter says that he merged (applied) it.
>
> [PATCH] documentation/gpu/i915: fix docs build error after file rename
>   https://marc.info/?l=linux-kernel=151234419425847=2

Hi Randy, didn't look too closely but I presume our scripts tripped over
the Fixes: tag that's split to two lines in that patch. I'll pick it up
for our next fixes batch.

Btw your documentation efforts haven't gone unnoticed, much appreciated.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 00/11] Allwinner H3/H5/A64(DE2) SimpleFB support

[Chen-Yu Tsai]

On Fri, Dec 22, 2017 at 8:22 PM, Icenowy Zheng  wrote:
> This patchset adds support for the SimpleFB on Allwinner SoCs with
> "Display Engine 2.0".
>
> PATCH 1 to PATCH 3 are DE2 CCU fixes for H3/H5 SoCs.
>
> PATCH 4 adds the pipeline strings for DE2 SimpleFB.
>
> PATCH 5 to 7 adds necessary device tree nodes (DE2 CCU and SimpleFB)
> for H3/H5 SoCs.
>
> PATCH 8 to 11 are for Allwinner A64 SoC to enable SimpleFB.
>
> Icenowy Zheng (11):
>   dt-bindings: fix the binding of Allwinner DE2 CCU of A83T and H3
>   clk: sunxi-ng: add support for Allwinner H3 DE2 CCU
>   clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU
>   dt-bindings: simplefb-sunxi: add pipelines for DE2
>   ARM: sun8i: h3/h5: add DE2 CCU device node for H3
>   arm64: allwinner: h5: add compatible string for DE2 CCU

Applied the first six patches. There is no guarantee they will make
it into 4.16.

ChenYu

>   ARM: sunxi: h3/h5: add simplefb nodes
>   dt-bindings: add binding for A64 DE2 CCU SRAM
>   clk: sunxi-ng: add support for Allwinner A64 DE2 CCU
>   arm64: allwinner: a64: add DE2 CCU for A64 SoC
>   arm64: allwinner: a64: add simplefb for A64 SoC
>
>  .../devicetree/bindings/clock/sun8i-de2.txt| 10 ++-
>  .../bindings/display/simple-framebuffer-sunxi.txt  |  4 +
>  arch/arm/boot/dts/sun8i-h3.dtsi|  4 +
>  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 43 +++
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  | 65 +
>  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi   |  4 +
>  drivers/clk/sunxi-ng/ccu-sun8i-de2.c   | 85 
> +++---
>  7 files changed, 202 insertions(+), 13 deletions(-)
>
> --
> 2.14.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 07/11] ARM: sunxi: h3/h5: add simplefb nodes

[Chen-Yu Tsai]

On Fri, Dec 22, 2017 at 8:22 PM, Icenowy Zheng  wrote:
> The H3/H5 SoCs have a HDMI output and a TV Composite output.
>
> Add simplefb nodes for these outputs.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 29 +
>  1 file changed, 29 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
> b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> index fcb909658cf0..31478c03790d 100644
> --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> @@ -53,6 +53,35 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> +   chosen {
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges;
> +
> +   framebuffer-hdmi {
> +   compatible = "allwinner,simple-framebuffer",
> +"simple-framebuffer";
> +   allwinner,pipeline = "mixer0-lcd0-hdmi";
> +   clocks = <_clocks CLK_BUS_MIXER0>,
> +< CLK_BUS_TCON0>, < CLK_BUS_HDMI>,

Are the bus clocks necessary? It's not like simplefb is going to access
any of the control registers.

> +<_clocks CLK_MIXER0>,
> +< CLK_TCON0>, < CLK_HDMI>,
> +< CLK_HDMI_DDC>;

Is the DDC clock necessary? There's no usage of DDC with simplefb.

ChenYu

> +   status = "disabled";
> +   };
> +
> +   framebuffer-tve {
> +   compatible = "allwinner,simple-framebuffer",
> +"simple-framebuffer";
> +   allwinner,pipeline = "mixer1-lcd1-tve";
> +   clocks = <_clocks CLK_BUS_MIXER1>,
> +< CLK_BUS_TCON1>, < CLK_BUS_TVE>,
> +<_clocks CLK_MIXER1>,
> +< CLK_TVE>;
> +   status = "disabled";
> +   };
> +   };
> +
> clocks {
> #address-cells = <1>;
> #size-cells = <1>;
> --
> 2.14.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] ARM: dts: Add support for emtrion emCON-MX6 series

[Alexandre Belloni]

On 26/12/2017 at 11:16:34 -0600, Rob Herring wrote:
> On Fri, Dec 22, 2017 at 4:56 AM, Alexandre Belloni
>  wrote:
> > + Philippe
> >
> > On 22/12/2017 at 11:43:33 +0100, Andreas Färber wrote:
> >> >> I'll change it for v3 of this patch however it will end up like this:
> >> >> //SPDX-License...
> >> >
> >> > That should be /* SPDX-License */, // is for c files.
> >>
> >> Got any reference for that? Since we're using the C preprocessor before
> >> feeding them to dtc, we can use the same // style for both, builds fine.
> >>
> >> Only for my private DT overlay files that I use directly with dtc I
> >> couldn't adopt that style.
> 
> We are well past the point of being able to build most dts files with just 
> dtc.
> 
> > The doc states:
> >
> > If a specific tool cannot handle the standard comment style, then the
> > appropriate comment mechanism which the tool accepts shall be used. This
> > is the reason for having the "/\* \*/" style comment in C header
> > files.
> >
> > I interpreted that as dtc doesn't handle // comments, use /**/
> 
> It's been so long, I'd forgotten that. Perhaps we should fix dtc to
> handle // comments.
> 

The would probably be the best solution so we get a somewhat consistent
style before people start moving the existing SDPX identifiers to the
top of their dtsi/dts files.

> >
> > But I agree it also states:
> > .dts{i}:  // SPDX-License-Identifier: 
> 
> Or we could still change this. The guidelines aren't merged yet.
> 
> Rob

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: use raw buffer printk specifier

[Andy Shevchenko]

On Thu, 2017-12-21 at 12:04 +0200, Dmitry Rozhkov wrote:
> printk format strings accepting a single subsequent argument
> are shorter thus easier to read.
> 
> Instead of having format strings accepting 3 different arguments
> pointing to first 3 bytes of the same buffer rewrite the format
> string to accept only one argument - the buffer - with "%3ph"
> specifier.
> 

+Cc maintainers

> Signed-off-by: Dmitry Rozhkov 
> Suggested-by: Andy Shevchenko 
> ---
>  drivers/gpu/drm/radeon/radeon_dp_mst.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
> b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> index 183b4b482138..ca2bcfb32935 100644
> --- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
> +++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> @@ -718,7 +718,7 @@ radeon_dp_mst_check_status(struct radeon_connector
> *radeon_connector)
>  DP_SINK_COUNT_ESI, esi, 8);
>  go_again:
>   if (dret == 8) {
> - DRM_DEBUG_KMS("got esi %02x %02x %02x\n",
> esi[0], esi[1], esi[2]);
> + DRM_DEBUG_KMS("got esi %3ph\n", esi);
>   ret = drm_dp_mst_hpd_irq(_connector-
> >mst_mgr, esi, );
>  
>   if (handled) {
> @@ -733,7 +733,7 @@ radeon_dp_mst_check_status(struct radeon_connector
> *radeon_connector)
>   dret =
> drm_dp_dpcd_read(_connector->ddc_bus->aux,
>   DP_SINK_COUNT
> _ESI, esi, 8);
>   if (dret == 8) {
> - DRM_DEBUG_KMS("got esi2 %02x
> %02x %02x\n", esi[0], esi[1], esi[2]);
> + DRM_DEBUG_KMS("got esi2
> %3ph\n", esi);
>   goto go_again;
>   }
>   } else

-- 
Andy Shevchenko 
Intel Finland Oy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes for 4.15-rc6

[Randy Dunlap]

On 12/28/2017 07:18 PM, Dave Airlie wrote:
> Hi Linus,
> 
> Just dequeuing some fixes, I'm on holidays next week again, but I
> think things should be fine.
> 
> Dave.

Hi,

It would be good to get this documentation build error patch
merged into 4.15.  Daniel Vetter says that he merged (applied) it.

[PATCH] documentation/gpu/i915: fix docs build error after file rename
  https://marc.info/?l=linux-kernel=151234419425847=2


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

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[Miguel Angel Vico]

(Adding dri-devel back, and trying to respond to some comments from
the different forks)

James Jones wrote:

> Your worst case analysis above isn't far off from our HW, give or take
> some bits and axes here and there.  We've started an internal discussion
> about how to lay out all the bits we need.  It's hard to even enumerate
> them all without having a complete understanding of what capability sets
> are going to include, a fully-optimized implementation of the mechanism
> on our HW, and lot's of test scenarios though.  

(thanks James for most of the info below)

To elaborate a bit, if we want to share an allocation across GPUs for 3D
rendering, it seems we would need 12 bits to express our
swizzling/tiling memory layouts for fermi+. In addition to that,
maxwell uses 3 more bits for this, and we need an extra bit to identify
pre-fermi representations.

We also need one bit to differentiate between Tegra and desktop, and
another one to indicate whether the layout is otherwise linear.

Then things like whether compression is used (one more bit), and we can
probably get by with 3 bits for the type of compression if we are
creative. However, it'd be way easier to just track arch + page kind,
which would be like 32 bits on its own.

Whether Z-culling and/or zero-bandwidth-clears are used may be another 3
bits.

If device-local properties are included, we might need a couple more
bits for caching.

We may also need to express locality information, which may take at
least another 2 or 3 bits.

If we want to share array textures too, you also need to pass the array
pitch. Is it supposed to be encoded in a modifier too? That's 64 bits on
its own.

So yes, as James mentioned, with some effort, we could technically fit
our current allocation parameters in a modifier, but I'm still not
convinced this is as future proof as it could be as our hardware grows
in capabilities.


Daniel Stone wrote:

> So I reflexively
> get a bit itchy when I see the kernel being used to transit magic
> blobs of data which are supplied by userspace, and only interpreted by
> different userspace. Having tiling formats hidden away means that
> we've had real-world bugs in AMD hardware, where we end up displaying
> garbage because we cannot generically reason about the buffer
> attributes.  

I'm a bit confused. Can't modifiers be specified by vendors and only
interpreted by drivers? My understanding was that modifiers could
actually be treated as opaque 64-bit data, in which case they would
qualify as "magic blobs of data". Otherwise, it seems this wouldn't be
scalable. What am I missing?


Daniel Vetter wrote:

> I think in the interim figuring out how to expose kms capabilities
> better (and necessarily standardizing at least some of them which
> matter at the compositor level, like size limits of framebuffers)
> feels like the place to push the ecosystem forward. In some way
> Miguel's proposal looks a bit backwards, since it adds the pitch
> capabilities to addfb, but at addfb time you've allocated everything
> already, so way too late to fix things up. With modifiers we've added
> a very simple per-plane property to list which modifiers can be
> combined with which pixel formats. Tiny start, but obviously very far
> from all that we'll need.  

Not sure whether I might be misunderstanding your statement, but one of
the allocator main features is negotiation of nearly optimal allocation
parameters given a set of uses on different devices/engines by the
capability merge operation. A client should have queried what every
device/engine is capable of for the given uses, find the optimal set of
capabilities, and use it for allocating a buffer. At the moment these
parameters are given to KMS, they are expected to be good. If they
aren't, the client didn't do things right.


Rob Clark wrote:

> It does seem like, if possible, starting out with modifiers for now at
> the kernel interface would make life easier, vs trying to reinvent
> both kernel and userspace APIs at the same time.  Userspace APIs are
> easier to change or throw away.  Presumably by the time we get to the
> point of changing kernel uabi, we are already using, and pretty happy
> with, serialized liballoc data over the wire in userspace so it is
> only a matter of changing the kernel interface.  

I guess we can indeed start with modifiers for now, if that's what it
takes to get the allocator mechanisms rolling. However, it seems to me
that we won't be able to encode the same type of information included
in capability sets with modifiers in all cases. For instance, if we end
up encoding usage transition information in capability sets, how that
would translate to modifiers?

I assume display doesn't really care about a lot of the data capability
sets may encode, but is it correct to think of modifiers as things only
display needs? If we are to treat modifiers as a first-class citizen, I
would expect to use them beyond that.


Kristian Kristensen wrote:

> I agree and let me 

Re: [PATCH v3 09/11] clk: sunxi-ng: add support for Allwinner A64 DE2 CCU

[Chen-Yu Tsai]

On Fri, Dec 22, 2017 at 8:22 PM, Icenowy Zheng  wrote:
> Allwinner A64's DE2 needs to claim a section of SRAM (SRAM C) to work.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 32 
>  1 file changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c 
> b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
> index 468d1abaf0ee..38b029b7bb5a 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "ccu_common.h"
>  #include "ccu_div.h"
> @@ -196,6 +197,11 @@ static const struct sunxi_ccu_desc 
> sun8i_v3s_de2_clk_desc = {
> .num_resets = ARRAY_SIZE(sun8i_a83t_de2_resets),
>  };
>
> +static bool sunxi_de2_clk_has_sram(const struct device_node *node)
> +{
> +   return of_device_is_compatible(node, "allwinner,sun50i-a64-de2-clk");

Having to maintain a separate list is not a great idea. Please consider
adding a de2 ccu specific structure that embeds a struct sunxi_ccu_desc,
and also includes whatever special quirks flags this needs.

ChenYu

> +}
> +
>  static int sunxi_de2_clk_probe(struct platform_device *pdev)
>  {
> struct resource *res;
> @@ -239,11 +245,20 @@ static int sunxi_de2_clk_probe(struct platform_device 
> *pdev)
> return ret;
> }
>
> +   if (sunxi_de2_clk_has_sram(pdev->dev.of_node)) {
> +   ret = sunxi_sram_claim(>dev);
> +   if (ret) {
> +   dev_err(>dev,
> +   "Error couldn't map SRAM to device\n");
> +   return ret;
> +   }
> +   }
> +
> /* The clocks need to be enabled for us to access the registers */
> ret = clk_prepare_enable(bus_clk);
> if (ret) {
> dev_err(>dev, "Couldn't enable bus clk: %d\n", ret);
> -   return ret;
> +   goto err_release_sram;
> }
>
> ret = clk_prepare_enable(mod_clk);
> @@ -272,6 +287,10 @@ static int sunxi_de2_clk_probe(struct platform_device 
> *pdev)
> clk_disable_unprepare(mod_clk);
>  err_disable_bus_clk:
> clk_disable_unprepare(bus_clk);
> +err_release_sram:
> +   if (sunxi_de2_clk_has_sram(pdev->dev.of_node))
> +   sunxi_sram_release(>dev);
> +
> return ret;
>  }
>
> @@ -288,17 +307,14 @@ static const struct of_device_id sunxi_de2_clk_ids[] = {
> .compatible = "allwinner,sun8i-v3s-de2-clk",
> .data = _v3s_de2_clk_desc,
> },
> +   {
> +   .compatible = "allwinner,sun50i-a64-de2-clk",
> +   .data = _a64_de2_clk_desc,
> +   },
> {
> .compatible = "allwinner,sun50i-h5-de2-clk",
> .data = _a64_de2_clk_desc,
> },
> -   /*
> -* The Allwinner A64 SoC needs some bit to be poke in syscon to make
> -* DE2 really working.
> -* So there's currently no A64 compatible here.
> -* H5 shares the same reset line with A64, so here H5 is using the
> -* clock description of A64.
> -*/
> { }
>  };
>
> --
> 2.14.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel