The pull request you sent on Tue, 16 Jul 2019 04:37:38 +1000:
> git://anongit.freedesktop.org/drm/drm drm-next-5.3-backmerge-conflicts
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/be8454afc50f43016ca8b6130d9673bdd0bd56ec
Thank you!
--
Deet-doot-dot, I am a bot.
On Tue, 2019-07-16 at 00:04 +0900, Jan Sebastian Götte wrote:
> Commit c440eee1a7a1 ("Staging: fbtft: Switch to the gpio descriptor
> interface") breaks GPIO handling. In several places, checks to only set
> a GPIO if it was configured ended up backwards.
> I have tested this fix. The fixed driver
GPIO probing and reset polarity are broken.
Fix them.
Fixes: c440eee1a7a1 ("Staging: fbtft: Switch to the gpio descriptor interface")
Changes from v2:
- Add fixes tag to "Fix reset assertion when using gpio descriptor"
- Add tested-by / reviewed-by tags
Phil Reid (2):
Staging: fbtft: Fix
On Mon, Jul 15, 2019 at 11:25:29AM +0200, Arnd Bergmann wrote:
> On Thu, Jul 4, 2019 at 7:52 AM Nathan Chancellor
> wrote:
> >
> > clang warns:
> >
> > drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:995:39: warning:
> > implicit conversion from enumeration type 'PPCLK_e' to different
> >
On Mon, Jul 15, 2019 at 11:04 AM Dmitry Torokhov
wrote:
>
> Hi,
>
> On Tue, Jul 02, 2019 at 11:39:56PM -0700, Life is hard, and then you die
> wrote:
> >
> > On Tue, Jul 02, 2019 at 03:50:49PM +0200, Andrzej Hajda wrote:
> > > On 19.04.2019 10:19, Ronald Tschalär wrote:
> > > > commit
On Thu, 2019-07-11 at 16:31 +0800, Phil Reid wrote:
> GPIO probing and reset polarity are broken.
> Fix them.
>
> Fixes: c440eee1a7a1 ("Staging: fbtft: Switch to the gpio descriptor
> interface")
>
> Phil Reid (2):
> Staging: fbtft: Fix probing of gpio descriptor
> Staging: fbtft: Fix reset
On Mon, Jul 15, 2019 at 04:19:26PM +0200, Daniel Vetter wrote:
> > Linus, do you have any advice on how best to handle sharing mm
> > patches? The hmm.git was mildly painful as it sits between quilt on
> > the -mm side and what seems like 'a world of interesting git things'
> > on the DRM side
> kzalloc has already zeroed the memory.
> So the memset is unneeded.
See also a previous patch:
drm/amd/powerplay: Delete a redundant memory setting in
vega20_set_default_od8_setttings()
https://lore.kernel.org/lkml/de3f6a5e-8ac4-bc8e-0d0c-3a4a5db28...@web.de/
kzalloc has already zeroed the memory.
So the memset is unneeded.
Signed-off-by: Fuqian Huang
---
drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
index
Conversion to use gpio descriptors broke all gpio lookups as
devm_gpiod_get_index was converted to use dev->driver->name for
the gpio name lookup. Fix this by using the name param. In
addition gpiod_get post-fixes the -gpios to the name so that
shouldn't be included in the call. However this then
Typically gpiod_set_value calls would assert the reset line and
then release it using the symantics of:
gpiod_set_value(par->gpio.reset, 0);
... delay
gpiod_set_value(par->gpio.reset, 1);
And the gpio binding would specify the polarity.
Prior to conversion to gpiod calls
On Mon, Jul 15, 2019 at 11:38 AM Dave Airlie wrote:
>
> The reason I was waiting for the HMM tree to land, is a single silent
> merge conflict needs to be resolved after merging this as below.
There's more than that there.
For example, the DRM_AMDGPU_USERPTR config has a
depends on
Thanks! This is reviewed-by: Evan Quan
Regards
Evan
> -Original Message-
> From: Nathan Chancellor
> Sent: Monday, July 15, 2019 11:40 PM
> To: Arnd Bergmann
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; Wentland, Harry ;
> Li, Sun peng (Leo) ; Rex Zhu ;
>
On Fri, Jul 12, 2019 at 1:15 PM Maxime Ripard wrote:
>
> On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote:
> > On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard
> > wrote:
> > > > > > There's another issue: if we introduce edp-connector we'll have to
> > > > > > specify power up
https://bugzilla.kernel.org/show_bug.cgi?id=204145
--- Comment #7 from Daniel Kolesa (li...@octaforge.org) ---
Maybe narrow it down first (i.e. find the last release that was good, by
testing 5.1.14 first, and then bisect only history between the last good and
first bad release. We know 5.1.9 is
https://bugzilla.kernel.org/show_bug.cgi?id=204145
Timothy Pearson (tpear...@raptorengineering.com) changed:
What|Removed |Added
CC|
Nishka Dasgupta writes:
> Each iteration of for_each_available_child_of_node puts the previous
> node, but in the case of a break from the middle of the loop there is
> no put, thus causing a memory leak. Hence add an of_node_put before the
> break.
> Issue found with Coccinelle.
Pushed.
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #6 from Timothy Arceri ---
(In reply to rol...@rptd.ch from comment #4)
> I tried compiling from source but it does not work. Seems to have troubles
> with libdrm.
>
> configure: error: Package requirements (libdrm >= 2.4.75
On Mon, Jul 15, 2019 at 3:11 PM Brendan Higgins
wrote:
>
> On Mon, Jul 15, 2019 at 3:04 PM Stephen Boyd wrote:
> >
> > Quoting Brendan Higgins (2019-07-15 14:11:50)
> > > On Mon, Jul 15, 2019 at 1:43 PM Stephen Boyd wrote:
> > > >
> > > > I also wonder if it would be better to just have a big
On Mon, Jul 15, 2019 at 1:07 PM Linus Torvalds
wrote:
>
> The mm_walk struct is indeed a bit similar, and is in fact a bit
> problematic exactly because it mixes function pointers with non-const
> data.
This made me look at how nasty that would be to fix.
Not too bad.
The attached patch does
Quoting Brendan Higgins (2019-07-12 01:17:30)
> diff --git a/include/kunit/kunit-stream.h b/include/kunit/kunit-stream.h
> new file mode 100644
> index 0..a7b53eabf6be4
> --- /dev/null
> +++ b/include/kunit/kunit-stream.h
> @@ -0,0 +1,81 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
>
On Mon, Jul 15, 2019 at 3:04 PM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-07-15 14:11:50)
> > On Mon, Jul 15, 2019 at 1:43 PM Stephen Boyd wrote:
> > >
> > > I also wonder if it would be better to just have a big slop buffer of a
> > > 4K page or something so that we almost never
Quoting Brendan Higgins (2019-07-15 14:11:50)
> On Mon, Jul 15, 2019 at 1:43 PM Stephen Boyd wrote:
> >
> > I also wonder if it would be better to just have a big slop buffer of a
> > 4K page or something so that we almost never have to allocate anything
> > with a string_stream and we can just
On Mon, Jul 15, 2019 at 1:10 PM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-07-12 01:17:27)
> > Add core facilities for defining unit tests; this provides a common way
> > to define test cases, functions that execute code which is under test
> > and determine whether the code under test
On Mon, Jul 15, 2019 at 1:43 PM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-07-12 01:17:29)
> > diff --git a/include/kunit/string-stream.h b/include/kunit/string-stream.h
> > new file mode 100644
> > index 0..0552a05781afe
> > --- /dev/null
> > +++
Quoting Brendan Higgins (2019-07-15 13:30:22)
> On Mon, Jul 15, 2019 at 1:24 PM Stephen Boyd wrote:
> >
> > Quoting Brendan Higgins (2019-07-12 01:17:28)
> > > diff --git a/kunit/test.c b/kunit/test.c
> > > index 571e4c65deb5c..f165c9d8e10b0 100644
>
> > One solution would be to piggyback on all
Quoting Brendan Higgins (2019-07-12 01:17:32)
> KUnit is a new unit testing framework for the kernel and when used is
> built into the kernel as a part of it. Add KUnit to the root Kconfig and
> Makefile to allow it to be actually built.
>
> Signed-off-by: Brendan Higgins
> Acked-by: Masahiro
Quoting Brendan Higgins (2019-07-12 01:17:29)
> diff --git a/include/kunit/string-stream.h b/include/kunit/string-stream.h
> new file mode 100644
> index 0..0552a05781afe
> --- /dev/null
> +++ b/include/kunit/string-stream.h
> @@ -0,0 +1,49 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
On Mon, Jul 15, 2019 at 1:24 PM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-07-12 01:17:28)
> > diff --git a/kunit/test.c b/kunit/test.c
> > index 571e4c65deb5c..f165c9d8e10b0 100644
> > --- a/kunit/test.c
> > +++ b/kunit/test.c
> > @@ -171,6 +175,96 @@ int kunit_run_tests(struct
Quoting Brendan Higgins (2019-07-12 01:17:28)
> diff --git a/kunit/test.c b/kunit/test.c
> index 571e4c65deb5c..f165c9d8e10b0 100644
> --- a/kunit/test.c
> +++ b/kunit/test.c
> @@ -171,6 +175,96 @@ int kunit_run_tests(struct kunit_suite *suite)
> return 0;
> }
>
> +struct kunit_resource
Quoting Brendan Higgins (2019-07-12 01:17:27)
> Add core facilities for defining unit tests; this provides a common way
> to define test cases, functions that execute code which is under test
> and determine whether the code under test behaves as expected; this also
> provides a way to group
On Mon, Jul 15, 2019 at 12:36 PM Thomas Hellström (VMware)
wrote:
>
> - I've never had any kernel code more reviewed than this.
Hmm. It may have been reviewed, but that wasn't visible in the commits
themselves, so when I look at the pull request, I don't see that.
> - The combined callback /
Hi, All.
On 7/15/19 8:00 PM, Linus Torvalds wrote:
On Mon, Jul 15, 2019 at 10:37 AM Linus Torvalds
wrote:
I'm not pulling this. Why did you merge it into your tree, when
apparently you were aware of how questionable it is judging by the drm
pull request.
Looking at some of the fallout, I
On Mon, Jul 15, 2019 at 12:17 PM Jason Gunthorpe wrote:
>
> About the only thing I could concretely suggest for working with -mm
> is if there was some way the -mm quilt patches could participate in
> 'git merge' resolution at your level.
Andrew did make noises about having multiple git
On Mon, Jul 15, 2019 at 11:16:11AM -0700, Linus Torvalds wrote:
> [ Ugh, I have three different threads about the drm pull because of
> the subject / html confusion. So now I'm replying in separate threads
> and I'm hoping the people involved have better threading than gmail
> does ;/ ]
>
> On
https://bugs.freedesktop.org/show_bug.cgi?id=106447
--- Comment #18 from richard ---
Hello ,
i don't know if this is the correct place to state this,
but i have a Desktop PC running
Ubuntu 16.04
and i noticed too that the system won't resume from suspend after installation
of
On Mon, Jul 15, 2019 at 11:16 AM Linus Torvalds
wrote:
>
> On Mon, Jul 15, 2019 at 5:29 AM Jason Gunthorpe wrote:
> >
> > The 'hmm' tree is something I ran to try and help workflow issues like
> > this, as it could be merged to DRM as a topic branch - maybe consider
> > this flow in future?
> >
From: Rodrigo Vivi
Add the PCI ID import for EHL.
Cc: Rodrigo Vivi
Signed-off-by: James Ausmus
Signed-off-by: Lucas De Marchi
---
intel/intel_chipset.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
index 157c2c7d..f6e37ee7 100644
---
From: Rodrigo Vivi
Cc: Rodrigo Vivi
Signed-off-by: Lucas De Marchi
---
intel/intel_chipset.c | 1 +
intel/intel_chipset.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
index 5aa4a2f2..157c2c7d 100644
--- a/intel/intel_chipset.c
+++
Straight copy from the kernel file, aligned with drm-intel-next-queued
commit cb823ed9915b ("drm/i915/gt: Use intel_gt as the primary object
for handling resets")
Signed-off-by: Lucas De Marchi
---
intel/i915_pciids.h | 194
1 file changed, 141
On Mon, Jul 15, 2019 at 11:29 AM Dave Airlie wrote:
>
> Not that I want to defend that code, but the mm patch that conflicts
> already shows that removing the token is fine as nobody needs or
> requires it. So the fixup patch in my tree was just a bridge to that patch,
> which reduces conflicts.
On Tue, 16 Jul 2019 at 04:00, Linus Torvalds
wrote:
>
> On Mon, Jul 15, 2019 at 10:37 AM Linus Torvalds
> wrote:
> >
> > I'm not pulling this. Why did you merge it into your tree, when
> > apparently you were aware of how questionable it is judging by the drm
> > pull request.
>
> Looking at
On Tue, 16 Jul 2019 at 03:38, Linus Torvalds
wrote:
>
> On Mon, Jul 15, 2019 at 12:08 AM Dave Airlie wrote:
> >
> > VMware had some mm helpers go in via my tree (looking back I'm not
> > sure Thomas really secured enough acks on these, but I'm going with it
> > for now until I get push back).
>
[ Ugh, I have three different threads about the drm pull because of
the subject / html confusion. So now I'm replying in separate threads
and I'm hoping the people involved have better threading than gmail
does ;/ ]
On Mon, Jul 15, 2019 at 5:29 AM Jason Gunthorpe wrote:
>
> The 'hmm' tree is
On Mon, Jul 15, 2019 at 7:57 PM Jason Gunthorpe wrote:
>
> On Mon, Jul 15, 2019 at 07:53:06PM +0200, Daniel Vetter wrote:
>
> > > So, I'll put it on a topic and send you two a note next week to decide
> > > if you want to merge it or not. I'm really unclear how nouveau's and
> > > AMD's patchflow
Hi,
On Tue, Jul 02, 2019 at 11:39:56PM -0700, Life is hard, and then you die wrote:
>
> On Tue, Jul 02, 2019 at 03:50:49PM +0200, Andrzej Hajda wrote:
> > On 19.04.2019 10:19, Ronald Tschalär wrote:
> > > commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency
> > > of RC_CORE)
On Mon, Jul 15, 2019 at 10:37 AM Linus Torvalds
wrote:
>
> I'm not pulling this. Why did you merge it into your tree, when
> apparently you were aware of how questionable it is judging by the drm
> pull request.
Looking at some of the fallout, I also see that you then added that
"adjust
On Mon, Jul 15, 2019 at 07:53:06PM +0200, Daniel Vetter wrote:
> > So, I'll put it on a topic and send you two a note next week to decide
> > if you want to merge it or not. I'm really unclear how nouveau's and
> > AMD's patchflow works..
>
> DRM is 2-level for pretty much everything. First it
On Mon, Jul 15, 2019 at 5:04 PM Jason Gunthorpe wrote:
>
> On Mon, Jul 15, 2019 at 04:19:26PM +0200, Daniel Vetter wrote:
>
> > > Linus, do you have any advice on how best to handle sharing mm
> > > patches? The hmm.git was mildly painful as it sits between quilt on
> > > the -mm side and what
On Mon, Jul 15, 2019 at 12:08 AM Dave Airlie wrote:
>
> VMware had some mm helpers go in via my tree (looking back I'm not
> sure Thomas really secured enough acks on these, but I'm going with it
> for now until I get push back).
Yeah, this is the kind of completely unacceptable stuff that I was
https://bugs.freedesktop.org/show_bug.cgi?id=39
Bug ID: 39
Summary: linux 5.2: rare NULL pointer dereference when SteamVR
idles
Product: DRI
Version: DRI git
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=22
--- Comment #4 from Chí-Thanh Christopher Nguyễn ---
Same symptoms here after upgrading from Linux 5.1 to 5.2 on Dell Latitude 5495,
Ryzen Pro 2700U. Graphical corruption, and/or the GUI will stop responding.
Magic SysRq is needed to reboot the
On Mon, Jul 15, 2019 at 11:34:51AM +0100, Emil Velikov wrote:
> On 2019/07/15, Sam Ravnborg wrote:
> > Hi Emil.
> >
> > > > ---
> > > > The list of cc: was too large to add all recipients to the cover letter.
> > > > Please find cover letter here:
> > > >
On Sun, Jun 30, 2019 at 09:34:49AM +0200, Thomas Zimmermann wrote:
> Acked-by: Thomas Zimmermann
Thanks, applied.
sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Jul 01, 2019 at 08:39:08AM +0200, Gerd Hoffmann wrote:
> On Sun, Jun 30, 2019 at 08:19:20AM +0200, Sam Ravnborg wrote:
> > Drop use of the deprecated drmP.h header file.
> > Made bochs.h self-contained and then fixed
> > fallout in remaining files.
> > Several unused includes was dropped
On Tue, Jul 02, 2019 at 03:35:52PM +0200, Daniel Vetter wrote:
> On Sun, Jun 30, 2019 at 08:19:19AM +0200, Sam Ravnborg wrote:
> > The macro DRM_VRAM_MM_FILE_OPERATIONS referencs
> > functions declared in other header files.
> > Include these header files so this header files
> > pulls in what it
On Mon, Jul 01, 2019 at 08:38:56AM +0200, Gerd Hoffmann wrote:
> On Sun, Jun 30, 2019 at 08:19:16AM +0200, Sam Ravnborg wrote:
> > Drop use of the deprecated drmP.h header file.
> > Fix fallout by adding missing include files.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: David Airlie
> > Cc:
On Sun, Jun 30, 2019 at 12:08:26PM +, Koenig, Christian wrote:
> Am 30.06.19 um 08:19 schrieb Sam Ravnborg:
> > Drop use of the deprecated drmP.h header file.
> > Fix fallout.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Alex Deucher
> > Cc: Andrey
On Tue, Jul 09, 2019 at 12:00:20PM -0300, Rodrigo Siqueira wrote:
> On Sun, Jun 30, 2019 at 3:19 AM Sam Ravnborg wrote:
> >
> > Drop use of the deprecated drmP.h header.
> > Replace it with the necessary includes in the individual .c files.
> > The header files was self-contained, and extra
On Mon, Jul 15, 2019 at 10:15:37AM +0200, Boris Brezillon wrote:
> On Sun, 30 Jun 2019 08:19:03 +0200
> Sam Ravnborg wrote:
>
> > Drop use of the deprecated header drmP.h.
> > Make header file self-contained, with only the required set
> > of include files.
> > And fixed fallout in remaining
On Fri, Jul 05, 2019 at 10:46:50PM +0200, Stefan Agner wrote:
> On 2019-06-30 08:18, Sam Ravnborg wrote:
> > Drop use of the deprecated drmP.h header file.
> > Fix fallout.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: Stefan Agner
> > Cc: Alison Wang
>
> Acked-by: Stefan Agner
Thanks,
On Mon, Jul 01, 2019 at 08:38:43AM +0200, Gerd Hoffmann wrote:
> On Sun, Jun 30, 2019 at 08:18:58AM +0200, Sam Ravnborg wrote:
> > Drop use of the deprecated drmP.h header file.
> > While touching the files divided includes in blocks,
> > and when needed sort the blocks.
> > Fix fallout.
> >
> >
On Fri, Jul 05, 2019 at 10:47:30PM +0200, Stefan Agner wrote:
> On 2019-06-30 08:18, Sam Ravnborg wrote:
> > Drop use of the deprecated drmP.h header file.
> >
> > While touching the list of include files divided them
> > in blocks and sort them within each block.
> > Fixed fallout in the
On Mon, Jul 01, 2019 at 08:05:24AM +0200, Sam Ravnborg wrote:
> Hi Oleksandr
>
> > > --- a/drivers/gpu/drm/xen/xen_drm_front.h
> > > +++ b/drivers/gpu/drm/xen/xen_drm_front.h
> > > @@ -11,13 +11,19 @@
> > > #ifndef __XEN_DRM_FRONT_H_
> > > #define __XEN_DRM_FRONT_H_
> > > -#include
> > >
On Thu, Jul 04, 2019 at 09:32:10AM +0200, Linus Walleij wrote:
> On Sun, Jun 30, 2019 at 8:19 AM Sam Ravnborg wrote:
>
> > Drop use of the deprecated header drmP.h.
> >
> > Fix so header file became self-contained,
> > and then fixed fallout in the other files.
> >
> > Signed-off-by: Sam
On Mon, Jul 15, 2019 at 3:57 AM Fuqian Huang wrote:
>
> kzalloc has already zeroed the memory during the allocation.
> So memset is unneeded.
>
> Signed-off-by: Fuqian Huang
Applied. thanks!
Alex
> ---
> Changes in v3:
> - Fix subject prefix: gpu/drm -> drm/amdgpu
>
>
On Fri, Jul 12, 2019 at 5:41 AM Arnd Bergmann wrote:
>
> It is annoying to have #warnings that trigger in randconfig
> builds like
>
> drivers/gpu/drm/amd/amdgpu/soc15.c:653:3: error: "Enable CONFIG_DRM_AMD_DC
> for display support on SOC15."
> drivers/gpu/drm/amd/amdgpu/nv.c:400:3: error:
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #11 from Sergey Kondakov (virtuous...@gmail.com) ---
Created attachment 283709
--> https://bugzilla.kernel.org/attachment.cgi?id=283709=edit
/proc/interrupts
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #10 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
Thanks for all the logs.
I meant drm.debug=4 actually, the drm=debug=4 was a typo on my part - sorry!
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #9 from Sergey Kondakov (virtuous...@gmail.com) ---
(In reply to Nicholas Kazlauskas from comment #1)
> Do you mind posting an dmesg log with drm=debug=4 as part of your boot
> parameters?
>
> An xorg log would be good too if
On Fri, Jul 12, 2019 at 6:58 PM Russell King - ARM Linux admin
wrote:
>
> On Fri, Jul 12, 2019 at 06:04:39PM +0800, Cheng-Yi Chiang wrote:
> > Add an op in hdmi_codec_ops so codec driver can register callback
> > function to handle plug event.
> >
> > Driver in DRM can use this callback function
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #8 from Sergey Kondakov (virtuous...@gmail.com) ---
Created attachment 283707
--> https://bugzilla.kernel.org/attachment.cgi?id=283707=edit
lspci -t -PP -q -k -v
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #7 from Sergey Kondakov (virtuous...@gmail.com) ---
Created attachment 283705
--> https://bugzilla.kernel.org/attachment.cgi?id=283705=edit
lspci -vv
--
You are receiving this mail because:
You are watching the assignee of the
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #6 from Sergey Kondakov (virtuous...@gmail.com) ---
Created attachment 283703
--> https://bugzilla.kernel.org/attachment.cgi?id=283703=edit
lsmem
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #5 from Sergey Kondakov (virtuous...@gmail.com) ---
Created attachment 283701
--> https://bugzilla.kernel.org/attachment.cgi?id=283701=edit
X.log
amdgpu has TearFree and VariableRefresh (no LCD support though) enabled.
Dual-screen
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #4 from Sergey Kondakov (virtuous...@gmail.com) ---
Created attachment 283699
--> https://bugzilla.kernel.org/attachment.cgi?id=283699=edit
amdgpu parameters
These doesn't seem to change anything about the hang. Although, maybe
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #2 from Sergey Kondakov (virtuous...@gmail.com) ---
Created attachment 283695
--> https://bugzilla.kernel.org/attachment.cgi?id=283695=edit
dmesg with "drm=debug=4"
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #3 from Sergey Kondakov (virtuous...@gmail.com) ---
Created attachment 283697
--> https://bugzilla.kernel.org/attachment.cgi?id=283697=edit
kernel build config
--
You are receiving this mail because:
You are watching the assignee
Commit c440eee1a7a1 ("Staging: fbtft: Switch to the gpio descriptor
interface") breaks GPIO handling. In several places, checks to only set
a GPIO if it was configured ended up backwards.
I have tested this fix. The fixed driver works with a ili9486
display connected to a raspberry pi via SPI.
https://bugs.freedesktop.org/show_bug.cgi?id=23
--- Comment #2 from Redsandro ---
Created attachment 144790
--> https://bugs.freedesktop.org/attachment.cgi?id=144790=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the
Coincidentially, I've worked on the exact same issue this weekend. I can
confirm this change is necessary, and with this and the other two patches from
Phil Reid the driver works again. The same mistake occurred in several other
locations, though. I'll send a patch fixing all of them.
I've
I have tested these changes on an ili9486-based display connected through SPI
to a raspberry pi and can confirm they work in combination with another patch
I'll send shortly.
Regards, Jan
On July 11, 2019, 8:31 a.m., Phil Reid wrote:
> Conversion to use gpio descriptors broke all gpio lookups
I have tested these changes on an ili9486-based display connected through SPI
to a raspberry pi and can confirm they work in combination with another patch
I'll send shortly. I only had to fix the reset pin polarity in the device tree
overlay I used.
Regards, Jan
On July 11, 2019, 8:31 a.m.,
We actually want to set the gpio pin if it's avilable, not the other way
around.
Fixes: c440eee1a7a1 ("Staging: fbtft: Switch to the gpio descriptor interface")
Signed-off-by: Nicolas Saenz Julienne
---
drivers/staging/fbtft/fbtft-bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Mon, Jul 15, 2019 at 2:29 PM Jason Gunthorpe wrote:
>
> [urk, html email.. forgive the mess]
>
> On Mon, Jul 15, 2019 at 04:59:39PM +1000, Dave Airlie wrote:
>
> > VMware had some mm helpers go in via my tree (looking back I'm
> > not sure Thomas really secured enough acks on these,
The opening comment mark "/**" is reserved for kernel-doc comments, so
it will generate warnings for comments that are not kernel-doc with
"make W=1". For example,
drivers/gpu/drm/drm_memory.c:2: warning: Cannot understand * \file
drm_memory.c
Signed-off-by: Qian Cai
---
Am 15.07.19 um 14:50 schrieb Christoph Hellwig:
> On Mon, Jul 15, 2019 at 10:41:14AM +, Koenig, Christian wrote:
> [SNIP]
> that are DMA coherent. Adding a DMA_ATTR_UNCACHED would be mostly
> trivial, we just need to define proper semantics for it.
Sounds good. Can you do this?
Hi Jason,
On Mon, 15 Jul 2019 12:29:28 + Jason Gunthorpe wrote:
>
> On Mon, Jul 15, 2019 at 04:59:39PM +1000, Dave Airlie wrote:
>
> > going with it for now until I get push back). They conflicted
> > with one of the mm cleanups in the hmm tree, I've pushed a
> > patch to the
https://bugzilla.kernel.org/show_bug.cgi?id=204181
Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=107694
--- Comment #11 from dmainma...@gmail.com ---
Seems like in Windows the problem is solved with AMD Catalyst Control Center by
turning on 'Surface Format Optimization' option.
https://steamcommunity.com/sharedfiles/filedetails/?id=313663882
[urk, html email.. forgive the mess]
On Mon, Jul 15, 2019 at 04:59:39PM +1000, Dave Airlie wrote:
> VMware had some mm helpers go in via my tree (looking back I'm
> not sure Thomas really secured enough acks on these, but I'm
I saw those patches, honestly I couldn't entirely
Hi Oleg,
On 2019/07/15, Oleg Vasilev wrote:
> Since DP-specific information is stored in driver's structures, every
> driver needs to implement subconnector property by itself.
>
> Signed-off-by: Oleg Vasilev
> Cc: nouv...@lists.freedesktop.org
> ---
>
Am 02.07.19 um 19:15 schrieb Emil Velikov:
On Fri, 14 Jun 2019 at 19:02, Koenig, Christian
wrote:
Am 14.06.19 um 19:33 schrieb Emil Velikov:
From: Emil Velikov
Currently the AMDGPU_CTX_PRIORITY_* defines are used in both
drm_amdgpu_ctx_in::priority and drm_amdgpu_sched_in::priority.
Extend
On 7/6/19 8:41 PM, Shobhit Kukreti wrote:
> Fix RB2D_DC_BUSY and HORZ_AUTO_RATIO_INC defines to use "U" cast to
> avoid shifting signed 32 bit values by 31 bit problem. This is not a
> problem for gcc built kernel.
>
> However, the header file being a public api, other compilers may not
> handle
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
Signed-off-by: Oleg Vasilev
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 12
Unfortunately, I don't have any nvidia hardware to test a patch. As of amd, it
seems that current DP implementation in drm-tip is corrupted with an unrelated
DP aux issue.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
Signed-off-by: Oleg Vasilev
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +
drivers/gpu/drm/nouveau/nouveau_dp.c
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
Signed-off-by: Oleg Vasilev
Cc: intel-...@lists.freedesktop.org
v2: updates to match previous commit changes
Signed-off-by: Oleg Vasilev
---
DP_MAX_DOWNSTREAM_PORTS=0x10 is a vendor-independent constant.
Signed-off-by: Oleg Vasilev
---
drivers/gpu/drm/i915/intel_drv.h | 2 --
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
Currently, downstream port type is only reported in debugfs. This
information should be considered important since it reflects the actual
physical connector type. Some userspace (e.g. window compositors)
may want to show this info to a user.
The 'subconnector' property is already utilized for
1 - 100 of 129 matches
Mail list logo
