Hey Dave,
A couple of misc fixes/workarounds for some issues that are causing a
lot of pain for people.
Of most interest are the PCI power management and GR init WARs, which
effect a rather significant number of laptop systems that are in use
today.
Ben.
The following changes since commit
Hi Sam,
Thanks for reviews.
The changes were posted by Vara Reddy. Due to some configuration errors,
changes were posted with my E-mail ID. Vara will be addressing comments, and
we will take care of this error with next patchset.
Thanks,
Tanmay
-Original Message-
From: Sam Ravnborg
Hi Jani
On 2020-04-06 02:11, Jani Nikula wrote:
On Fri, 03 Apr 2020, abhin...@codeaurora.org wrote:
Hi Ville
Thanks for the patch.
Our understanding of private_flags was that we can use it within our
drivers to handle vendor specific features.
Hence we do have several features in our
Hi Jani
On 2020-04-06 01:32, Jani Nikula wrote:
On Fri, 03 Apr 2020, abhin...@codeaurora.org wrote:
On 2020-04-03 13:39, Ville Syrjala wrote:
diff --git a/drivers/gpu/drm/drm_modes.c
b/drivers/gpu/drm/drm_modes.c
index fec1c33b3045..e3d5f011f7bd 100644
--- a/drivers/gpu/drm/drm_modes.c
+++
In preparation to virtio header changes, include uaccess.h directly as
this file is using copy to/from user.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
In preparation to virtio header changes, include uaccess.h directly as
this file is using copy to/from user.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
From: Yintian Tao
[ Upstream commit 77bb2f204f1f0a53a602a8fd15816d6826212077 ]
There is one one corner case at dma_fence_signal_locked
which will raise the NULL pointer problem just like below.
->dma_fence_signal
->dma_fence_signal_locked
->test_and_set_bit
here trigger
From: Yintian Tao
[ Upstream commit 3c0fdf3302cb4f186c871684eac5c407a107e480 ]
There is one one corner case at dma_fence_signal_locked
which will raise the NULL pointer problem just like below.
->dma_fence_signal
->dma_fence_signal_locked
->test_and_set_bit
here trigger
On Mon, 2020-04-06 at 21:47 +0200, Sam Ravnborg wrote:
> Lyude Paul wrote a very good intro to vblank here:
> https://lore.kernel.org/dri-devel/faf63d8a9ed23c16af69762f59d0dca6b2bf085f.ca...@redhat.com/T/#mce6480be738160e9d07c5d023e88fd78d7a06d27
>
> Add this to the intro chapter in drm_vblank.c
No functional changes.
Signed-off-by: Lyude Paul
Cc: Sean Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5b205aea58d4..828ca63cc576
Currently we only poll for an ACT up to 30 times, with a busy-wait delay
of 100µs between each attempt - giving us a timeout of 2900µs. While
this might seem sensible, it would appear that in certain scenarios it
can take dramatically longer then that for us to receive an ACT. On one
of the EVGA
Just add a bit more line wrapping, get rid of some extraneous
whitespace, remove an unneeded goto label, and move around some variable
declarations. No functional changes here.
Signed-off-by: Lyude Paul
[this isn't a fix, but it's needed for the fix that comes after this]
Fixes: ad7f8a1f9ced
Although it's not unexpected for drm_dp_check_act_status() to fail due
to DPCD read failures (as the hub may have just been unplugged
suddenly), timeouts are a bit more worrying as they either mean we need
a longer timeout value, or we aren't setting up payload allocations
properly. So, let's
Noticed this while fixing some unrelated issues with NAKs being dropped
- we don't wait nearly long enough to receive ACTs from MST hubs in some
situations. Also, we take the time to refactor this function a bit.
This fixes some ACT timeouts I observed on an EVGA MST hub with i915.
Lyude Paul
On Mon, 2020-04-06 at 15:23 -0400, Sean Paul wrote:
> On Fri, Apr 3, 2020 at 4:08 PM Lyude Paul wrote:
> > Just add a bit more line wrapping, get rid of some extraneous
> > whitespace, remove an unneeded goto label, and move around some variable
> > declarations. No functional changes here.
> >
Hi,
On 4/6/20 9:51 PM, Alex Xu (Hello71) wrote:
Using 314b658 with amdgpu, starting sway and firefox causes "BUG: Bad
rss-counter state" and "BUG: non-zero pgtables_bytes on freeing mm" to
start filling dmesg, and then closing programs causes more BUGs and
hangs, and then everything grinds to a
On 4/6/20 9:51 PM, Alex Xu (Hello71) wrote:
Using 314b658 with amdgpu, starting sway and firefox causes "BUG: Bad
rss-counter state" and "BUG: non-zero pgtables_bytes on freeing mm" to
start filling dmesg, and then closing programs causes more BUGs and
hangs, and then everything grinds to a halt
Hi Pankaj,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20200406]
[cannot apply to v5.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also
Drive-by fix I noticed the other day - drm_dp_mst_has_audio() only ever
made sense back when we still had to validate ports before accessing
them in order to (attempt to) avoid NULL dereferences. Since we have
proper reference counting that guarantees we always can safely access
the MST port,
The only reason for having this cast as void * before was because we
originally needed to use drm_dp_mst_get_port_validated() and friends in
order to (attempt to) safely access MST ports. However, we've since
improved how reference counting works with ports and mstbs such that we
can now rely on
Hi Thomas.
On Mon, Apr 06, 2020 at 03:43:55PM +0200, Thomas Zimmermann wrote:
> Generic fbdev emulation is a DRM client. If possible, it should behave
> like userspace clients. Therefore it should not run before the driver
> registered the new DRM device. If the setup function fails, the driver
>
On Fri, Apr 3, 2020 at 6:23 PM Lyude Paul wrote:
>
> Drive-by fix I noticed the other day - drm_dp_mst_has_audio() only ever
> made sense back when we still had to validate ports before accessing
> them in order to (attempt to) avoid NULL dereferences. Since we have
> proper reference counting
On Fri, Apr 3, 2020 at 4:03 PM Lyude Paul wrote:
>
> It looks like that when we introduced the ability to handle multiple
> down requests at once, we accidentally started dropping NAK replies -
> causing sideband messages which got NAK'd to seemingly timeout and cause
> all sorts of weirdness.
>
On Mon, Apr 6, 2020 at 3:43 PM Lyude Paul wrote:
>
> On Mon, 2020-04-06 at 15:41 -0400, Sean Paul wrote:
> > On Fri, Apr 3, 2020 at 4:08 PM Lyude Paul wrote:
> > > Currently we only poll for an ACT up to 30 times, with a busy-wait delay
> > > of 100µs between each attempt - giving us a timeout
drm_writeback.h included a lot of nice kernel-doc comments.
Wire it up so the header file is included in the kernel-doc
generated documentation.
Added a few simple comments to the two structs so they
get picked up by kernel-doc.
Signed-off-by: Sam Ravnborg
Cc: Laurent Pinchart
Cc: Brian
Lyude - I added a "Co-developed-by: ..."
Can I get your s-o-b on the patch, to document that
you are OK with this to go in.
Needed on top of an r-b.
v2:
- committed acked/reviewed patches
- significantly updated the vbalnk patch based on a lot of good inputs
- updated the writeback patch
Lyude Paul wrote a very good intro to vblank here:
https://lore.kernel.org/dri-devel/faf63d8a9ed23c16af69762f59d0dca6b2bf085f.ca...@redhat.com/T/#mce6480be738160e9d07c5d023e88fd78d7a06d27
Add this to the intro chapter in drm_vblank.c so others
can benefit from it too.
v2:
- Reworded to improve
Document the callbacks:
drm_connector_helper_funcs.prepare_writeback_job
drm_connector_helper_funcs.cleanup_writeback_job
The documentation was pulled from the changelong introducing the
callbacks, originally written by Laurent.
Adding the missing documentation fixes the following
On Mon, Apr 6, 2020 at 3:34 PM Lyude Paul wrote:
>
> While we don't need this function to store an mstb anywhere for UP
> requests since we process them asynchronously, we do need to make sure
> that we don't try to write to **mstb for UP requests otherwise we'll
> cause a NULL pointer deref:
>
>
On Fri, Apr 3, 2020 at 4:08 PM Lyude Paul wrote:
>
> Although it's not unexpected for drm_dp_check_act_status() to fail due
> to DPCD read failures (as the hub may have just been unplugged
> suddenly), timeouts are a bit more worrying as they either mean we need
> a longer timeout value, or we
On Mon, 2020-04-06 at 15:41 -0400, Sean Paul wrote:
> On Fri, Apr 3, 2020 at 4:08 PM Lyude Paul wrote:
> > Currently we only poll for an ACT up to 30 times, with a busy-wait delay
> > of 100µs between each attempt - giving us a timeout of 2900µs. While
> > this might seem sensible, it would
On Fri, Apr 3, 2020 at 4:08 PM Lyude Paul wrote:
>
> Currently we only poll for an ACT up to 30 times, with a busy-wait delay
> of 100µs between each attempt - giving us a timeout of 2900µs. While
> this might seem sensible, it would appear that in certain scenarios it
> can take dramatically
While we don't need this function to store an mstb anywhere for UP
requests since we process them asynchronously, we do need to make sure
that we don't try to write to **mstb for UP requests otherwise we'll
cause a NULL pointer deref:
RIP: 0010:drm_dp_get_one_sb_msg+0x4b/0x460
On Mon, Apr 6, 2020 at 5:40 AM Geert Uytterhoeven wrote:
>
> Hi Laurent,
>
> On Mon, Apr 6, 2020 at 1:09 PM Laurent Pinchart
> wrote:
> > On Mon, Apr 06, 2020 at 10:47:37AM +0200, Geert Uytterhoeven wrote:
> > > On Mon, Apr 6, 2020 at 1:24 AM Laurent Pinchart wrote:
> > > > Convert the Renesas
On Mon, 2020-04-06 at 15:23 -0400, Sean Paul wrote:
> On Fri, Apr 3, 2020 at 4:08 PM Lyude Paul wrote:
> > Just add a bit more line wrapping, get rid of some extraneous
> > whitespace, remove an unneeded goto label, and move around some variable
> > declarations. No functional changes here.
> >
On Fri, Apr 3, 2020 at 4:08 PM Lyude Paul wrote:
>
> Just add a bit more line wrapping, get rid of some extraneous
> whitespace, remove an unneeded goto label, and move around some variable
> declarations. No functional changes here.
>
> Signed-off-by: Lyude Paul
> [this isn't a fix, but it's
On Fri, Apr 3, 2020 at 4:08 PM Lyude Paul wrote:
>
> No functional changes.
>
> Signed-off-by: Lyude Paul
> Cc: Sean Paul
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git
Am 03.04.20 um 15:58 schrieb Daniel Vetter:
> Upcasting using a container_of macro is more typesafe, faster and
> easier for the compiler to optimize.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc:
Hi Pankaj,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20200406]
[cannot apply to v5.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also
On Mon, Apr 6, 2020 at 10:04 AM Michel Dänzer wrote:
>
> On 2020-04-06 6:34 p.m., Rob Clark wrote:
> >
> > The ideal thing would be to be able to click any jobs that we want to
> > run, say "arm64_a630_gles31", and for gitlab to realize that it needs
> > to automatically trigger dependencies of
Generic fbdev emulation is a DRM client. Drivers should invoke the
setup function, but not depend on its success. Hence remove the return
value.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 18 --
include/drm/drm_fb_helper.h | 5 +++--
2 files
Hi Maxime,
On Mon, Apr 06, 2020 at 07:09:15PM +0200, Maxime Ripard wrote:
> On Mon, Apr 06, 2020 at 02:19:27PM +0300, Laurent Pinchart wrote:
> > On Mon, Apr 06, 2020 at 10:00:32AM +0200, Maxime Ripard wrote:
> > > On Mon, Apr 06, 2020 at 02:39:33AM +0300, Laurent Pinchart wrote:
> > > > Convert
Generic fbdev support is a DRM client. Set it up after fully registering
the new DRM device.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
Generic fbdev support is a DRM client. Set it up after registering
the new DRM device. Remove the error checks as the driver's probe
function should not depend on a DRM client's state.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 ++
Generic fbdev support is a DRM client. Set it up after registering
the new DRM device. Remove the error checks as the driver's probe
function should not depend on a DRM client's state.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/vbox_drv.c | 6 ++
1 file changed, 2
Generic fbdev support is a DRM client. Set it up after fully registering
the new DRM device.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Am 03.04.20 um 15:58 schrieb Daniel Vetter:
> Also need to remove the drm_dev_put from the remove hook.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
> ---
>
Remove the error check from the fbdev setup function. The function
will print a warning.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
Generic fbdev support is a DRM client. Set it up after registering
the new DRM device. Remove the error checks as the driver's probe
function should not depend on a DRM client's state.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.c | 3 +++
drivers/gpu/drm/ast/ast_main.c |
Generic fbdev support is a DRM client. Remove the error check as the
driver's probe function should not depend on a DRM client's state.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git
Generic fbdev emulation is a DRM client. If possible, it should behave
like userspace clients. Therefore it should not run before the driver
registered the new DRM device. If the setup function fails, the driver
should not report an error.
This is a follow-up patchset to the discussion at [1]. I
Am 05.04.20 um 12:18 schrieb Noralf Trønnes:
>
>
> Den 03.04.2020 15.57, skrev Daniel Vetter:
>> Also init the fbdev emulation before we register the device, that way
>> we can rely on the auto-cleanup and simplify the probe error code even
>> more.
>>
>> Signed-off-by: Daniel Vetter
>> Cc:
Remove the error check from the fbdev setup function. The driver's
probe function should not depend on a DRM client's state.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_drv.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.c
Hi
Am 03.04.20 um 15:57 schrieb Daniel Vetter:
> We use the baseclass pattern here, so lets to the proper (and more
> typesafe) upcasting.
>
> Signed-off-by: Daniel Vetter
> Cc: Hans de Goede
> ---
> drivers/gpu/drm/vboxvideo/vbox_drv.c | 1 -
> drivers/gpu/drm/vboxvideo/vbox_drv.h | 1 +
Remove the error check from the fbdev setup function. The function
will print a warning.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
https://bugzilla.kernel.org/show_bug.cgi?id=207137
--- Comment #3 from sandy.8...@gmail.com ---
Created attachment 288235
--> https://bugzilla.kernel.org/attachment.cgi?id=288235=edit
GPU VBIOS
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=207137
sandy.8...@gmail.com changed:
What|Removed |Added
CC||sandy.8...@gmail.com
--- Comment
On 2020-04-06 6:34 p.m., Rob Clark wrote:
>
> The ideal thing would be to be able to click any jobs that we want to
> run, say "arm64_a630_gles31", and for gitlab to realize that it needs
> to automatically trigger dependencies of that job (meson-arm64, and
> arm_build+arm_test). But not sure if
Hi, Hsin-Yi:
Hsin-Yi Wang 於 2020年4月6日 週一 下午1:12寫道：
>
> drm device is now probed from mmsys. We need to use mmsys device to get gce
> nodes. Fix following errors:
>
> [0.740068] mediatek-drm mediatek-drm.1.auto: error -2 can't parse
> gce-client-reg property (0)
> [0.748721] mediatek-drm
On Mon, Apr 6, 2020 at 8:43 AM Adam Jackson wrote:
>
> On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
> > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > > For Mesa, we could run CI only when Marge pushes, so that it's a
> > > >
On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
> On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > > pre-merge CI.
> >
> > Thanks for the suggestion! I
W dniu 30.03.2020 o 13:35, Adrian Ratiu pisze:
> Register existence, address/offsets, field layouts, reserved bits and
> so on differ between MIPI-DSI versions and between SoC vendor boards.
> Despite these differences the hw IP and protocols are mostly the same
> so the generic bridge can be
https://bugzilla.kernel.org/show_bug.cgi?id=207137
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=207137
Bug ID: 207137
Summary: AMDGPU incorrectly reports vddgfx voltage for R9 390
Product: Drivers
Version: 2.5
Kernel Version: 5.6
Hardware: All
OS: Linux
Tree:
Hi Adrian,
Due to different ways of work I use different mail client, so forgive me
if there are some misconfugrations.
W dniu 30.03.2020 o 13:35, Adrian Ratiu pisze:
> Hello everyone,
>
> The v5 series is a significantly cleaned up version from v4,
> started by Ezequiel Garcia's suggestion of
On Friday, April 3, 2020 4:23 PM, Adam Jackson wrote:
> On Fri, 2020-04-03 at 15:24 +0300, Pekka Paalanen wrote:
>
> > On Fri, 03 Apr 2020 10:15:21 + Simon Ser cont...@emersion.fr wrote:
> >
> > > Additionally, I've heard Pekka saying that it would be nice to have
> > > constants
> > > for
On Mon, Apr 6, 2020 at 3:38 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter wrote:
> > >
> > > In drm we've added nice drm_device (the main gpu driver thing, which
> > > also represents the userspace
On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote:
> On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter wrote:
> >
> > In drm we've added nice drm_device (the main gpu driver thing, which
> > also represents the userspace interfaces and has everything else
> > dangling off it) init
Hi,
> > > +drivers/gpu/drm/virtio/virtgpu_object.c maintainers
> > > Now we have both mainline and linux-next boot broken (linux-next is
> > > broken for the past 40 days).
> > > No testing of new code happens.
> > >
> > > > virtio_gpu_object_shmem_init
> > > >
On Mon, 2020-04-06 at 13:44 +0300, Andy Shevchenko wrote:
> On Mon, Apr 6, 2020 at 10:46 AM Mauro Carvalho Chehab
> wrote:
> > Em Fri, 3 Apr 2020 21:32:42 +0300
> > Andy Shevchenko escreveu:
> > > On Fri, Apr 3, 2020 at 8:54 PM Joe Perches wrote:
> > > > On Fri, 2020-04-03 at 19:32 +0200, Mauro
On Mon, Apr 6, 2020 at 10:06 AM Gerd Hoffmann wrote:
>
> On Mon, Apr 06, 2020 at 09:07:44AM +0200, Dmitry Vyukov wrote:
> > On Mon, Apr 6, 2020 at 8:46 AM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:ffc1c20c Merge tag
On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter wrote:
>
> In drm we've added nice drm_device (the main gpu driver thing, which
> also represents the userspace interfaces and has everything else
> dangling off it) init functions using devres, devm_drm_dev_init and
> soon devm_drm_dev_alloc (this
On Mon, Apr 6, 2020 at 2:01 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> Thank you for the patch.
>
> On Fri, Apr 03, 2020 at 03:57:46PM +0200, Daniel Vetter wrote:
> > The kerneldoc is only added for this new function. Existing kerneldoc
> > and examples will be udated at the very end, since
Hi Daniel,
Thank you for the patch.
On Fri, Apr 03, 2020 at 03:57:46PM +0200, Daniel Vetter wrote:
> The kerneldoc is only added for this new function. Existing kerneldoc
> and examples will be udated at the very end, since once all drivers
> are converted over to devm_drm_dev_alloc we can
Am 03.04.20 um 15:58 schrieb Daniel Vetter:
> We're mostly there already, just a handful of places that didn't use
> the to_udl container_of cast. To make sure no new appear, don't set
> ->dev_private.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Sean Paul
> Cc: Emil Velikov
>
Hi Laurent,
On Mon, Apr 6, 2020 at 1:09 PM Laurent Pinchart
wrote:
> On Mon, Apr 06, 2020 at 10:47:37AM +0200, Geert Uytterhoeven wrote:
> > On Mon, Apr 6, 2020 at 1:24 AM Laurent Pinchart wrote:
> > > Convert the Renesas R-Car LVDS encoder text binding to YAML.
> > >
> > > Signed-off-by:
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* at places where struct drm_device pointer
can be extracted.
Signed-off-by: Pankaj Bharadiya
---
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Conversion is done with below sementic patch:
@@
identifier func, T;
@@
func(...) {
...
struct intel_crtc *T = ...;
<+...
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/i915_pmu.c | 11 ---
1 file changed, 8 insertions(+), 3
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN*.
Conversion is done with below semantic patch:
@@
identifier func, T;
@@
func(struct intel_runtime_pm *T,...) {
+ struct
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
1 file changed, 2 insertions(+), 1
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON at places where struct drm_device
pointer can be extracted.
Signed-off-by: Pankaj Bharadiya
---
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* at places where struct intel_dp struct
pointer is available.
Conversion is done with below sementic patch:
@@
identifier func,
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* calls.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_ddi.c | 14 --
1 file changed, 8
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON at places where struct drm_device
pointer can be extracted.
Signed-off-by: Pankaj Bharadiya
---
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_overlay.c | 6 +++---
1 file changed, 3
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_frontbuffer.c | 6 --
1 file changed, 4
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* calls.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 16 +---
1 file changed, 9
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON at places where struct i915_power_domains
struct is available.
Conversion is done with below sementic patch:
@@
identifier
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* calls.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_global_state.c | 4 ++--
1 file changed, 2
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Conversion is done with below sementic patch:
@@
identifier func, T;
@@
func(struct intel_digital_port *T,...) {
<+...
Now we have struct drm_device specific drm_WARN* macros which include
device information in the backtrace, so we know what device the
warnings originate from.
This series converts WARN* with drm_WARN* where struct drm_device
pointer can be extracted.
This series is the continuation of:
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 4 ++--
1 file changed, 2
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/icl_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1
Hallo again,
On Mon, Apr 06, 2020 at 02:28:57PM +0300, Laurent Pinchart wrote:
> On Mon, Apr 06, 2020 at 09:57:05AM +0200, Maxime Ripard wrote:
> > On Mon, Apr 06, 2020 at 02:39:31AM +0300, Laurent Pinchart wrote:
> > > diff --git
> > >
Hi Maxime,
On Mon, Apr 06, 2020 at 09:57:05AM +0200, Maxime Ripard wrote:
> On Mon, Apr 06, 2020 at 02:39:31AM +0300, Laurent Pinchart wrote:
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
> >
Hi Maxime,
On Mon, Apr 06, 2020 at 10:00:32AM +0200, Maxime Ripard wrote:
> On Mon, Apr 06, 2020 at 02:39:33AM +0300, Laurent Pinchart wrote:
> > Convert the Rockchip HDMI TX text binding to YAML.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > .../display/rockchip/dw_hdmi-rockchip.txt
Hi Jacopo,
On Mon, Apr 06, 2020 at 08:40:31AM +0200, Jacopo Mondi wrote:
> On Mon, Apr 06, 2020 at 02:23:17AM +0300, Laurent Pinchart wrote:
> > Convert the Thine THC63LVD1024 text binding to YAML.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > .../display/bridge/thine,thc63lvd1024.txt
Hi Geert,
On Mon, Apr 06, 2020 at 10:47:37AM +0200, Geert Uytterhoeven wrote:
> On Mon, Apr 6, 2020 at 1:24 AM Laurent Pinchart wrote:
> > Convert the Renesas R-Car LVDS encoder text binding to YAML.
> >
> > Signed-off-by: Laurent Pinchart
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++
1 - 100 of 139 matches
Mail list logo
