Em Mon, 15 Jul 2019 08:16:54 +0200
Markus Heiser escreveu:
> Hi Mauro,
>
> sorry, I havn't tested your patch, but one question ...
>
> Am 14.07.19 um 17:10 schrieb Mauro Carvalho Chehab:
> > Now that the latex_documents are handled automatically, we can
> > remove those extra conf.py files.
>
kzalloc has already zeroed the memory during the allocation.
So memset is unneeded.
Signed-off-by: Fuqian Huang
---
Changes in v3:
- Fix subject prefix: gpu/drm -> drm/amdgpu
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 2 --
drivers/gpu/drm/amd/powerplay/hwmgr/process_pptabl
https://bugs.freedesktop.org/show_bug.cgi?id=35
Bug ID: 35
Summary: USER ENABLE TO LOGIN
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
URL: https://www.bugzilla.org/docs/2.18/html/quips.html
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 files.
> Divide include files in blocks and sort them within each block.
>
> Signe
Hi Emil.
> > ---
> > The list of cc: was too large to add all recipients to the cover letter.
> > Please find cover letter here:
> > https://lists.freedesktop.org/archives/dri-devel/2019-June/thread.html
> > Search for "drm: drop use of drmp.h in drm-misc"
> >
> Speaking of long CC list, most patc
On 11.07.2019 16:50, Mark Brown wrote:
> On Thu, Jul 11, 2019 at 03:11:56PM +0200, Andrzej Hajda wrote:
>
>> 1. DSI protocol defines actually more than 30 types of transactions[1],
>> but this patchset implements only few of them (dsi generic write/read
>> family). Is it possible to implement multi
Hi Laurent
> >
> > The shmobile driver hasn't seen changes for a long time and I don't have
> > patches queued in my tree for it. If you don't mind taking this patch
> > through drm-misc with the rest of the drmP.h removal series it would be
> > easier for me. Otherwise please let me know and I'll
On Mon, Jul 8, 2019 at 6:05 PM Arnd Bergmann wrote:
> On Mon, Jul 8, 2019 at 4:54 PM Nathan Chancellor
> wrote:
> > On Mon, Jul 08, 2019 at 03:57:06PM +0200, Arnd Bergmann wrote:
> > > A couple of calls to smu_get_current_clk_freq() and smu_force_clk_levels()
> > > pass constants of the wrong ty
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
> enumeration type 'enum smu_clk_type' [-Wenum-conversion]
> ret = s
https://bugzilla.kernel.org/show_bug.cgi?id=204181
Bug ID: 204181
Summary: NULL pointer dereference regression in amdgpu
Product: Drivers
Version: 2.5
Kernel Version: 5.2.1
Hardware: x86-64
OS: Linux
Tree: Mai
https://bugs.freedesktop.org/show_bug.cgi?id=33
Andre Klapper changed:
What|Removed |Added
Component|DRM/amdkfd |Two
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=32
Andre Klapper changed:
What|Removed |Added
CC|mesa-dev@lists.freedesktop. |
|org, sheve...@gmail
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:
> > > https://lists.freedesktop.org/archives/dri-devel/2019-June/thread.html
> > > Search for "drm: drop use of drmp.h in dr
On 2019/07/15, Fuqian Huang wrote:
> kzalloc has already zeroed the memory during the allocation.
> So memset is unneeded.
>
> Signed-off-by: Fuqian Huang
> ---
> Changes in v3:
> - Fix subject prefix: gpu/drm -> drm/amdgpu
>
Reviewed-by: Emil Velikov
-Emil
_
On 2019/07/15, Fuqian Huang wrote:
> In commit 518a2f1925c3
> ("dma-mapping: zero memory returned from dma_alloc_*"),
> dma_alloc_coherent has already zeroed the memory.
> So memset is not needed.
>
> Signed-off-by: Fuqian Huang
> ---
> Changes in v3:
> - Use actual commit rather than the merge
Hi Christoph,
sorry for the delayed response, I was on a two week vacation.
Am 01.07.19 um 10:31 schrieb Christoph Hellwig:
> On Fri, Jun 28, 2019 at 08:05:28AM +, Koenig, Christian wrote:
> [SNIP]
>>> Lets put it in another way. Outside of x86 uncached mappings are the
>>> norm, but there i
https://bugs.freedesktop.org/show_bug.cgi?id=23
Michel Dänzer changed:
What|Removed |Added
Version|git |unspecified
Assignee|mesa-dev
Quoting Koenig, Christian (2019-07-14 08:37:47)
> Am 12.07.19 um 10:03 schrieb Chris Wilson:
> > Since kmalloc() will round up the allocation to the next slab size or
> > page, it will normally return a pointer to a memory block bigger than we
> > asked for. We can query for the actual size of the
Hi Qian,
On 2019/07/12, Qian Cai wrote:
> Maybe one of the non-DRM maintainers (Andrew, Thomas or Greg) who cares a bit
> about SPDX can pick this up. It occurs to me none of DRM maintainers cares
> about
> this as there is no feedback from any of them for months since v1.
>
AFAICT there are a c
On Fri, 2019-07-12 at 00:07 -0300, Rodrigo Siqueira wrote:
> On 07/10, Daniel Vetter wrote:
> > On Mon, Jul 01, 2019 at 12:23:39AM -0300, Rodrigo Siqueira wrote:
> > > This patchset introduces the support for configfs in vkms by
> > > adding a
> > > primary structure for handling the vkms subsystem
Hallo everybody,
after upgrading from a kernel 5.0 to 5.2, i run into a reproducible
regression with a display-port monitor on a Quadro M1000M. I got the
following kernel message :
[ 161.070503] nouveau :01:00.0: 126.016 Gb/s available PCIe
bandwidth, limited by 8 GT/s x16 link at :00:01
Quoting Chris Wilson (2019-07-12 09:03:13)
> Since kmalloc() will round up the allocation to the next slab size or
> page, it will normally return a pointer to a memory block bigger than we
> asked for. We can query for the actual size of the allocated block using
> ksize() and expand our variable
The helper should always be used.
Signed-off-by: Oleg Vasilev
---
drivers/gpu/drm/drm_dp_helper.c | 3 +--
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
inde
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 DVI-
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
https://lists.freede
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
---
drivers/gpu/drm/i915/dis
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 b/drivers/gpu/drm/i915/
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
drivers/gpu/drm/amd/amdgpu/amdgpu_m
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
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
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
> ---
> drivers/gpu/drm/nouveau/nouveau_connector.
[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 understand
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
Maybe
https://bugzilla.kernel.org/show_bug.cgi?id=204181
Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) changed:
What|Removed |Added
CC||nichol
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
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? Ca
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
---
drivers/gpu/drm/drm_ag
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, b
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(-)
diff
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., P
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 a
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 test
https://bugs.freedesktop.org/show_bug.cgi?id=23
--- Comment #2 from Redsandro ---
Created attachment 144790
--> https://bugs.freedesktop.org/attachment.cgi?id=144790&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug.
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.
Fix
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&action=edit
dmesg with "drm=debug=4"
--
You are receiving this mail because:
You are watching th
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&action=edit
kernel build config
--
You are receiving this mail because:
You are watching the ass
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&action=edit
amdgpu parameters
These doesn't seem to change anything about the hang. Although, may
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&action=edit
X.log
amdgpu has TearFree and VariableRefresh (no LCD support though) enabled.
Dual-s
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&action=edit
lsmem
--
You are receiving this mail because:
You are watching the assignee of the b
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&action=edit
lspci -vv
--
You are receiving this mail because:
You are watching the assignee of t
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&action=edit
lspci -t -PP -q -k -v
--
You are receiving this mail because:
You are watching the a
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 applicab
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 t
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 assign
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&action=edit
/proc/interrupts
--
You are receiving this mail because:
You are watching the assig
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: "Enabl
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
>
> drivers/gpu/drm/amd/di
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 Ravnborg
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
> > > -#in
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 relevant
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, applied
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.
> >
> > S
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 file
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 includ
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 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: Gerd
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 r
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 in
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 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:
> > > > https://lists.freedesktop.org/archives/dri
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
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
Statu
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
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 see
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 la
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 apply_to_
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) cha
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
[ 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 some
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).
>
>
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 some
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. R
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 insert
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
+++ b/intel/
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
--- a/inte
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
amdgpu-driver
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?
> >
>
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 Mon
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 branches.
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 also
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 / arg
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 togeth
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
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 kunit_s
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 */
>
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 Yam
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
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
> > +++ b/include/kunit/string-stre
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
1 - 100 of 145 matches
Mail list logo
