https://bugzilla.kernel.org/show_bug.cgi?id=206299
--- Comment #10 from Frédéric Pierret (frederic.epi...@orange.fr) ---
Last piece of information, aach time I'm trying to reproduce the freeze and
thanks to the fix, I can see a second information in kernel log:
[ 814.207723] nouveau :26:00.0
The goal of this series is to get the displays based on ilitek,ili9486
working.
Ozzmaker, Piscreen and waveshare,rpi-lcd-35 are such displays.
v2 changes:
* Changing file from txt to yaml format
* removed ilitek,ili9486 from compatible string
* assignment of dbi_command before registration
* made
This adds support fot ilitek,ili9486 based displays with shift register
in front of controller.
Ozzmaker,Piscreen and Waveshare,rpi-lcd-35 are such displays.
Signed-off-by: Kamlesh Gurudasani
---
v2 changes:
* assignment of dbi_command before registration
* made dc and reset gpio compulsory
* ty
Add vendor prefix for OzzMaker [1] and Waveshare Electronics [2]
Both are display manufacturers
[1] https://ozzmaker.com/about/
[2] https://www.waveshare.com/contact_us
Signed-off-by: Kamlesh Gurudasani
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 4
1 file changed, 4 inser
Convert etnaviv bindings to yaml format.
Signed-off-by: Benjamin Gaignard
---
.../bindings/display/etnaviv/etnaviv-drm.txt | 36 ---
.../bindings/display/etnaviv/etnaviv-drm.yaml | 72 ++
2 files changed, 72 insertions(+), 36 deletions(-)
delete mode 10064
Convert etnaviv bindings to yaml format.
Signed-off-by: Benjamin Gaignard
---
.../bindings/display/etnaviv/etnaviv-drm.txt | 36 ---
.../devicetree/bindings/gpu/vivante,gc.yaml| 72 ++
2 files changed, 72 insertions(+), 36 deletions(-)
delete mode 10064
The goal of this series is to get the displays based on ilitek,ili9486
working.
Ozzmaker, Piscreen and waveshare,rpi-lcd-35 are such displays.
v2 changes:
* Changing file from txt to yaml format
* removed ilitek,ili9486 from compatible string
* assignment of dbi_command before registration
* made
Hi,
We are developing a custom board, in which we are using the rk3399 soc.
We have LVDS displays, and use TI SN65dsi84 bridge as a mipi-lvds bridge.
The bridge demands the DSI data lanes be in LP-11 state (stop state). We
developed support for the bridge as a DRM bridge module. It gets called
On 1/27/20 1:59 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 27.01.20 um 10:53 schrieb Oleksandr Andrushchenko:
>> Sorry for jumping in late
>>
>> On 1/23/20 11:21 AM, Thomas Zimmermann wrote:
>>> The atomic helpers automatically send out fake VBLANK events if no
>>> vblanking has been initialized. T
On Fri, Jan 24, 2020 at 4:11 PM Guenter Roeck wrote:
>
> On Fri, Dec 20, 2019 at 12:03:53PM -0800, Rajat Jain wrote:
> > Certain laptops now come with panels that have integrated privacy
> > screens on them. This patch adds support for such panels by adding
> > a privacy-screen property to the int
Sorry for jumping in late
On 1/23/20 11:21 AM, Thomas Zimmermann wrote:
> The atomic helpers automatically send out fake VBLANK events if no
> vblanking has been initialized. This would apply to xen, but xen has
> its own vblank logic. To avoid interfering with the atomic helpers,
> disable automa
This binding is for the tft displays based on ilitek,ili9486.
ozzmaker,piscreen and waveshare,rpi-lcd-35 are such displays
Signed-off-by: Kamlesh Gurudasani
---
v2 changes:
* Changing file from txt to yaml format
* removed ilitek,ili9486 from compatible string
v3 changes:
* no changes
---
.../
This adds support fot ilitek,ili9486 based displays with shift register
in front of controller.
Ozzmaker,Piscreen and Waveshare,rpi-lcd-35 are such displays.
Signed-off-by: Kamlesh Gurudasani
---
v2 changes:
* assignment of dbi_command before registration
* made dc and reset gpio compulsory
* ty
Add vendor prefix for OzzMaker [1] and Waveshare Electronics [2]
Both are display manufacturers
[1] https://ozzmaker.com/about/
[2] https://www.waveshare.com/contact_us
Signed-off-by: Kamlesh Gurudasani
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 4
1 file changed, 4 inser
On Fri, Jan 24, 2020 at 07:18:12PM +0100, Sam Ravnborg wrote:
> On Fri, Jan 24, 2020 at 07:31:34PM +0200, Andy Shevchenko wrote:
> > On Fri, Jan 24, 2020 at 05:42:33PM +0100, Sam Ravnborg wrote:
> > > On Wed, Jan 22, 2020 at 12:54:00PM +0200, Andy Shevchenko wrote:
> > > > There is one OF call in t
On Mon, Jan 27, 2020 at 09:14:19AM +0100, Paul Kocialkowski wrote:
> Hi Jernej,
>
> On Sun 26 Jan 20, 07:59, Jernej Skrabec wrote:
> > This reverts commit 9db9c0cf5895e4ddde2814360cae7bea9282edd2.
> >
> > Setting mode_config.allow_fb_modifiers manually is completely
> > unnecessary. It is set autom
Quoting Abhinav Kumar (2020-01-23 14:40:45)
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 99769d6..148bfa4 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4199,6 +4200,57 @@ static void fixup_detailed_cea_mode_clock(struct
> drm_d
This binding is for the tft displays based on ilitek,ili9486.
ozzmaker,piscreen and waveshare,rpi-lcd-35 are such displays
Signed-off-by: Kamlesh Gurudasani
---
v2 changes:
* Changing file from txt to yaml format
* removed ilitek,ili9486 from compatible string
v3 changes:
* no changes
v4 chang
Le mer. 8 janv. 2020 à 10:41, Benjamin Gaignard
a écrit :
>
> Le mar. 7 janv. 2020 à 18:05, Rob Herring a écrit :
> >
> > On Tue, Jan 7, 2020 at 9:44 AM Benjamin Gaignard
> > wrote:
> > >
> > > Le jeu. 2 janv. 2020 à 11:17, Sam Ravnborg a écrit :
> > > >
> > > > To complement panel-simple.yaml,
Hi Rob,
On 27/01/2020 20.49, Rob Herring wrote:
> On Mon, Jan 27, 2020 at 12:56:33PM +0200, Peter Ujfalusi wrote:
>> TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.
>>
>> Signed-off-by: Peter Ujfalusi
>> ---
>> .../display/bridge/toshiba,tc358768.yaml | 158 ++
>> 1
Hi Flora,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f9a0b7ad3447d7766dda9923e63a5f4d0be7ce47
commit: c53ae0e01db63d1b142681add947781668e3319c [2027/2713] drm/amdkcl: drop
kcl_dma_fence_set_error
config: i386-allyesconfig (attach
On 27.01.2020 17:18, Mika Penttilä wrote:
> Hi,
>
> We are developing a custom board, in which we are using the rk3399 soc.
> We have LVDS displays, and use TI SN65dsi84 bridge as a mipi-lvds bridge.
> The bridge demands the DSI data lanes be in LP-11 state (stop state). We
> developed support fo
Instead check for master status, in case we've raced.
This is the last exception to the general rule that we restore fbcon
only when there's no master active. Compositors are supposed to drop
their master status before they switch to a different console back to
text mode (or just switch to text mo
We want to only take the BKL on crap drivers, but to know whether
we have a crap driver we first need to look it up. Split this shuffle
out from the main BKL-disabling patch, for more clarity.
Since the minors are refcounted drm_minor_acquire is purely internal
and this does not have a driver visi
Kinda time to get this sorted. The locking around this really is not
nice.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 6 ++
include/drm/drm_drv.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7c18a980
This catches the majority of drivers (unfortunately not if we take
users into account, because all the big drivers have at least a
lastclose hook).
With the prep patches out of the way all drm state is fully protected
and either prevents or can deal with the races from dropping the BKL
around open
Quoting Daniel Vetter (2020-01-28 10:45:58)
> Kinda time to get this sorted. The locking around this really is not
> nice.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 6 ++
> include/drm/drm_drv.h | 3 +++
> 2 files changed, 9 insertions(+)
>
> diff --git a/driv
Quoting Daniel Vetter (2020-01-28 10:46:00)
> We want to only take the BKL on crap drivers, but to know whether
> we have a crap driver we first need to look it up. Split this shuffle
> out from the main BKL-disabling patch, for more clarity.
>
> Since the minors are refcounted drm_minor_acquire i
Quoting Daniel Vetter (2020-01-28 10:46:01)
> This catches the majority of drivers (unfortunately not if we take
> users into account, because all the big drivers have at least a
> lastclose hook).
Yeah, that lastclose for switching back to fbcon, and ensuring that
switch is started before the nex
Quoting Chris Wilson (2020-01-28 10:47:59)
> Quoting Daniel Vetter (2020-01-28 10:45:58)
> > Kinda time to get this sorted. The locking around this really is not
> > nice.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_drv.c | 6 ++
> > include/drm/drm_drv.h | 3 +++
Hi Laurent,
On 24/01/2020 05:54, Laurent Pinchart wrote:
+struct drm_connector *drm_bridge_connector_init(struct drm_device *drm,
+ struct drm_encoder *encoder)
+{
+ struct drm_bridge_connector *bridge_connector;
+ struct drm_connector *
From: Colin Ian King
There is a spelling mistake on the struct field name link_integiry_check,
fix this by renaming it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h | 2 +-
.../gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c| 8
..
On Mon, Jan 27, 2020 at 05:30:42PM -0500, Alex Deucher wrote:
> On Fri, Jan 24, 2020 at 3:03 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > After much head scratching I managed to convince myself that
> > for_each_displayid_db() has already done the bounds checks for
> > the DispID
On Mon, Jan 27, 2020 at 05:38:15PM -0500, Alex Deucher wrote:
> On Fri, Jan 24, 2020 at 3:03 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Let's try to make a lot more stuff const in the edid parser.
> >
> > The "downside" is that we can no longer mangle the EDID in the
> > middle
Den 28.01.2020 11.45, skrev Daniel Vetter:
> Instead check for master status, in case we've raced.
>
> This is the last exception to the general rule that we restore fbcon
> only when there's no master active. Compositors are supposed to drop
> their master status before they switch to a differe
This reverts commit 172a216ff334ad869b0d74188a70763e4167fd9e.
Guido Günther reported issues with this patch that broke existing
user space. Let's revert it for now and fix it properly later on.
Link: https://patchwork.kernel.org/patch/11291089/
https://lore.kernel.org/lkml/20200121114553.2667556-
On Fri, Jan 24, 2020 at 9:56 AM Guido Günther wrote:
> On Wed, Jan 22, 2020 at 10:35:53AM +, Russell King - ARM Linux admin
> wrote:
> > On Wed, Jan 22, 2020 at 11:30:34AM +0100, Guido Günther wrote:
> > I think it would probably be better for the kernel to print a
> > warning once when noti
On 22/01/2020 12:57, Wambui Karuga wrote:
First pass of conversion to the new struct drm_based device logging
macros in the drm/i915/gem directory. This conversion was achieved using
the following coccinelle script that transforms based on the existence
of a straightforward struct drm_i915_priv
On Wed, Jan 22, 2020 at 11:31:22AM +0200, Imre Deak wrote:
> Platforms without a HW detiler doesn't support the get_tiling IOCTL.
> Fix the drm_intel_bo_gem_create_from_* functions assuming the default
> no-tiling, no-swizzling setting for the GEM buffer in this case.
>
> v2:
> - Add the missing g
Hi
Am 28.01.20 um 11:45 schrieb Daniel Vetter:
> Kinda time to get this sorted. The locking around this really is not
> nice.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 6 ++
> include/drm/drm_drv.h | 3 +++
> 2 files changed, 9 insertions(+)
>
> diff --git a/
On Tue, 28 Jan 2020, Tvrtko Ursulin wrote:
>> -DRM_DEBUG(
>> +drm_dbg(&T->drm,
>
> This changes DRM_UT_CORE to DRM_UT_DRIVER so our typical drm.debug=0xe
> becomes much more spammy.
This is what I've instructed Wambui to do in i915. It's my mistake that
I haven't requested this to be pointed out
Add the bus-width property to describe the input bus format.
v10:
* Add changelog to the commit message
* Add Rob's R-b
v8 -> v9:
* No changes
v7:
* Rebase on top of lvds-codec changes
* Drop the data-mapping property
v4 -> v6:
* Not part of the series
v3:
* New patch
Signed-off-by: Boris Bre
This is needed to pass a bridge state to all atomic hooks, if we don't
do that, the core can't duplicate/create bridge states.
v10:
* Add changelog to the commit message
v9:
* Add Neil's R-b
* Move earlier in the series
v8:
* No changes
v7:
* New patch
Signed-off-by: Boris Brezillon
Reviewed-
Hello,
This patch series aims at adding support for runtime bus-format
negotiation between all elements of the
'encoder -> bridges -> connector/display' section of the pipeline.
In order to support that, we need drm bridges to fully take part in the
atomic state validation process, which requires
This is needed to pass a bridge state to all atomic hooks, if we don't
do that, the core can't duplicate/create bridge states.
v10:
* Add changelog to the commit message
v9:
* Add Neil's R-b
* Move earlier in the series
v8:
* No changes
v7:
* New patch
Signed-off-by: Boris Brezillon
Reviewed-
One of the last remaining objects to not have its atomic state.
This is being motivated by our attempt to support runtime bus-format
negotiation between elements of the bridge chain.
This patch just paves the road for such a feature by adding a new
drm_bridge_state object inheriting from drm_priva
The lt089ac29000 panel is an LVDS panel, not a DPI one. Fix the
definition to reflect this fact.
v10:
* Add changelog to the commit message
v8 -> v9:
* No changes
v7:
* New patch
Signed-off-by: Boris Brezillon
Suggested-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges, an encoder and a bridge,
So that bridge drivers have a way to check/reject an atomic operation.
The drm_atomic_bridge_chain_check() (which is just a wrapper around
the ->atomic_check() hook) is called in place of
drm_bridge_chain_mode_fixup() (when ->atomic_check() is not implemented,
the core falls back on ->mode_fixup(),
This way the drm_bridge_funcs interface is consistent with the rest of
the subsystem.
The drivers implementing those hooks are patched too.
v10:
* Add changelog to the commit message
v8 -> v9:
* No changes
v7:
* Adjust things to the bridge_state changes
v6:
* Also fixed rcar-du/rcar_lvds.c sam
The current definition does not represent the exact display pipeline we
have on the board: the LVDS panel is actually connected through a
parallel -> LVDS bridge. Let's fix that so the driver can select the
proper bus format on the CRTC end.
Signed-off-by: Boris Brezillon
---
v2 -> v10:
* No chan
So that the previous bridge element in the chain knows which input
format the panel bridge expects.
v10:
* Add changelog to the commit message
v8 -> v9:
* No changes
v7:
* Set atomic state hooks explicitly
v4 -> v6:
* Not part of the series
v3:
* Adjust things to match the new bus-format negot
Now that bridges can expose the bus format/flags they expect, we can
use those instead of the relying on the display_info provided by the
connector (which is only valid if the encoder is directly connected
to bridge element driving the panel/display).
We also explicitly expose the bus formats supp
Some DPI -> LVDS encoders might support several input bus width. Add a
DT property to describe the bus width used on a specific design.
v10:
* Add changelog to the commit message
v8 -> v9:
* No changes
v7:
* Fix a use-after-release problem
* Get rid of the data-mapping parsing
* Use kmalloc inst
On Fri, Dec 13, 2019 at 08:53:30PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Fri, Dec 13, 2019 at 06:26:05PM +0100, Daniel Vetter wrote:
> > Checking both is one too much, so wrap a WARN_ON around it to stope
> > the copypasta.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Sam Ravnborg
> >
On Tue, Jan 28, 2020 at 02:41:06PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 28.01.20 um 11:45 schrieb Daniel Vetter:
> > Kinda time to get this sorted. The locking around this really is not
> > nice.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_drv.c | 6 ++
> > i
On Tue, Jan 28, 2020 at 12:52:05PM +0100, Noralf Trønnes wrote:
>
>
> Den 28.01.2020 11.45, skrev Daniel Vetter:
> > Instead check for master status, in case we've raced.
> >
> > This is the last exception to the general rule that we restore fbcon
> > only when there's no master active. Composit
On 28/01/2020 13:48, Jani Nikula wrote:
On Tue, 28 Jan 2020, Tvrtko Ursulin wrote:
-DRM_DEBUG(
+drm_dbg(&T->drm,
This changes DRM_UT_CORE to DRM_UT_DRIVER so our typical drm.debug=0xe
becomes much more spammy.
This is what I've instructed Wambui to do in i915. It's my mistake that
I haven
On 1/28/20 1:49 PM, Petr Mladek wrote:
> On Tue 2020-01-28 18:23:46, anon anon wrote:
>> Dear Linux kernel developers,
>>
>> I found the crash "KASAN: slab-out-of-bounds Write in vgacon_scroll"
>> when running syzkaller, hope it's unknown:
>>
>> Linux version: Linux v4.17-rc4 (75bc37fefc44)
>> Br
On Tue, Jan 28, 2020 at 11:00:32AM +, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-01-28 10:46:01)
> > This catches the majority of drivers (unfortunately not if we take
> > users into account, because all the big drivers have at least a
> > lastclose hook).
>
> Yeah, that lastclose for s
On Tue, Jan 28, 2020 at 10:47:59AM +, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-01-28 10:45:58)
> > Kinda time to get this sorted. The locking around this really is not
> > nice.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_drv.c | 6 ++
> > include/drm/dr
On Mon, Jan 27, 2020 at 07:42:27PM +0100, Thomas Zimmermann wrote:
> Hi Emil
>
> Am 27.01.20 um 19:12 schrieb Emil Velikov:
> > Hi Thomas,
> >
> > On Thu, 23 Jan 2020 at 09:21, Thomas Zimmermann wrote:
> >
> >> @@ -174,12 +174,22 @@ struct drm_crtc_state {
> >> * @no_vblank:
> >>
On Fri, Jan 24, 2020 at 10:02:24PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> CEA-861 says :
> "d = offset for the byte following the reserved data block.
> If no data is provided in the reserved data block, then d=4.
> If no DTDs are provided, then d=0."
>
> So let's not look for D
On 1/21/20 6:53 AM, Gerd Hoffmann wrote:
> Hi,
>
>>> open. Which can result in drm driver not being able to grab resources
>>> (and fail initialization) because the firmware framebuffer still holds
>>> them. Reportedly plymouth can trigger this.
>>
>> Could you please describe issue some mor
On Mon, Jan 27, 2020 at 02:29:53PM -0800, Doug Anderson wrote:
> Hi,
>
> On Mon, Jan 27, 2020 at 1:30 AM Sharat Masetty
> wrote:
> >
> > This patch adds the required dt nodes and properties
> > to enabled A618 GPU.
> >
> > Signed-off-by: Sharat Masetty
> > ---
> > arch/arm64/boot/dts/qcom/sc71
On Thu, Aug 22, 2019 at 2:20 PM Ville Syrjälä
wrote:
>
> On Wed, Aug 21, 2019 at 10:38:35PM +0200, Daniel Vetter wrote:
> > Oops.
> >
> > Fixes: 9edbf1fa600a ("drm: Add API for capturing frame CRCs")
> > Cc: Tomeu Vizoso
> > Cc: Emil Velikov
> > Cc: Benjamin Gaignard
> > Signed-off-by: Daniel V
https://bugzilla.kernel.org/show_bug.cgi?id=58981
James Dietrich (jdiet...@fastmail.fm) changed:
What|Removed |Added
Summary|[BUISECTED] boot failure|[BISECTED] boot fai
Per at least one tester this is enough magic to recover the regression
introduced for some people (but not all) in
commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin
Date: Tue Jul 4 12:36:57 2017 +0200
drm/fb-helper: factor out pseudo-palette
which for radeon had the side
On Tue, Jan 28, 2020 at 04:17:58PM +0100, Daniel Vetter wrote:
> On Fri, Jan 24, 2020 at 10:02:24PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > CEA-861 says :
> > "d = offset for the byte following the reserved data block.
> > If no data is provided in the reserved data block, th
On Tue, Jan 28, 2020 at 5:15 PM Ville Syrjälä
wrote:
>
> On Tue, Jan 28, 2020 at 04:17:58PM +0100, Daniel Vetter wrote:
> > On Fri, Jan 24, 2020 at 10:02:24PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > CEA-861 says :
> > > "d = offset for the byte following the reserved dat
On Tue, Jan 28, 2020 at 05:18:34PM +0100, Daniel Vetter wrote:
> On Tue, Jan 28, 2020 at 5:15 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Jan 28, 2020 at 04:17:58PM +0100, Daniel Vetter wrote:
> > > On Fri, Jan 24, 2020 at 10:02:24PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
>
On Mon, Jan 20, 2020 at 11:00 AM Gerd Hoffmann wrote:
>
> Problem: do_unregister_framebuffer() might return before the device is
> fully cleaned up, due to userspace having a file handle for /dev/fb0
> open. Which can result in drm driver not being able to grab resources
> (and fail initializatio
On Tue, Jan 28, 2020 at 5:39 PM Daniel Vetter wrote:
>
> On Mon, Jan 20, 2020 at 11:00 AM Gerd Hoffmann wrote:
> >
> > Problem: do_unregister_framebuffer() might return before the device is
> > fully cleaned up, due to userspace having a file handle for /dev/fb0
> > open. Which can result in drm
Hi Benjamin,
On 1/28/20 1:31 PM, Benjamin GAIGNARD wrote:
>
> On 1/28/20 1:06 PM, Maxime Ripard wrote:
>> Hi Benjamin,
>>
>> On Tue, Jan 28, 2020 at 09:20:13AM +0100, Benjamin Gaignard wrote:
>>> Convert etnaviv bindings to yaml format.
>>>
>>> Signed-off-by: Benjamin Gaignard
>>> ---
>>>..
On Tue, Jan 28, 2020 at 5:44 PM Daniel Vetter wrote:
>
> On Tue, Jan 28, 2020 at 5:39 PM Daniel Vetter wrote:
> >
> > On Mon, Jan 20, 2020 at 11:00 AM Gerd Hoffmann wrote:
> > >
> > > Problem: do_unregister_framebuffer() might return before the device is
> > > fully cleaned up, due to userspace
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automati
Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
include device information in the backtrace, so we know what device
the warnings originate from.
Similar to this, add new struct drm_device based drm_WARN* macros. These
macros include device information in the backtrace, so we
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automati
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automati
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automati
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automati
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automati
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automati
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automati
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.
The conversion was done automatica
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automati
Quoting Jani Nikula (2020-01-28 13:48:10)
> On Tue, 28 Jan 2020, Tvrtko Ursulin wrote:
> >> -DRM_DEBUG(
> >> +drm_dbg(&T->drm,
> >
> > This changes DRM_UT_CORE to DRM_UT_DRIVER so our typical drm.debug=0xe
> > becomes much more spammy.
>
> This is what I've instructed Wambui to do in i915. It's
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automati
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automati
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automati
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.
The conversion was done automatica
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.
The conversion was done automati
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was
On Tue, Jan 28, 2020 at 6:31 AM Benjamin GAIGNARD
wrote:
>
>
> On 1/28/20 1:06 PM, Maxime Ripard wrote:
> > Hi Benjamin,
> >
> > On Tue, Jan 28, 2020 at 09:20:13AM +0100, Benjamin Gaignard wrote:
> >> Convert etnaviv bindings to yaml format.
> >>
> >> Signed-off-by: Benjamin Gaignard
> >> ---
> >
Hi,
On Tue, Jan 28, 2020 at 07:06:57PM +0530, Harigovindan P wrote:
> Adding dsi controller and phy entries for idp dt.
>
> Signed-off-by: Harigovindan P
> ---
> arch/arm64/boot/dts/qcom/sc7180-idp.dts | 56
> +
> 1 file changed, 56 insertions(+)
>
> diff --git
1 - 100 of 116 matches
Mail list logo
