Re: [PATCH 00/18] Fix some build warnings/errors with Sphinx

On Tue, May 08, 2018 at 10:13:42AM -0600, Jonathan Corbet wrote: > On Mon, 7 May 2018 06:35:36 -0300 > Mauro Carvalho Chehab wrote: > > > I decided to give a try with Sphinx last stable version > > (1.17.4), and noticed several issues. The worse one was > > with the

WARNING: CPU: 5 PID: 74 at ../drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 nvkm_dp_enable+0xbe/0x140 [nouveau]

I have been getting the following splat for while now, guess its time to report, this is on 4.15.8-1-default (OpenSUSE Tumbleweed). I could try a more up to date kernel if we think this can be fixed. Mar 16 16:48:18 olga kernel: kvm: SMP vm created on host with unstable TSC; guest TSC will not

[RFT v3] drm: use late_initcall() for amdkfd and radeon

On Wed, Jun 1, 2016 at 2:11 PM, Luis R. Rodriguez wrote: > On Tue, May 31, 2016 at 09:04:53PM +0200, Daniel Vetter wrote: >> On Tue, May 31, 2016 at 06:58:34PM +0200, Luis R. Rodriguez wrote: >> > On Sun, May 29, 2016 at 08:27:07PM +0200, Daniel Vetter wrote: >> > >

[PATCH 1/2] x86/io: add interface to reserve io memtype for a resource range. (v1.1)

On Mon, Oct 24, 2016 at 04:31:45PM +1000, Dave Airlie wrote: > A recent change to the mm code in: > 87744ab3832b83ba71b931f86f9cfdb000d07da5 > mm: fix cache mode tracking in vm_insert_mixed() > > started enforcing checking the memory type against the registered list for > amixed pfn insertion

[RFT v3] drm: use late_initcall() for amdkfd and radeon

On Tue, May 31, 2016 at 09:04:53PM +0200, Daniel Vetter wrote: > On Tue, May 31, 2016 at 06:58:34PM +0200, Luis R. Rodriguez wrote: > > On Sun, May 29, 2016 at 08:27:07PM +0200, Daniel Vetter wrote: > > > On Fri, May 27, 2016 at 3:18 AM, Luis R. Rodriguez > > > wrote:

[RFT v3] drm: use late_initcall() for amdkfd and radeon

On Sun, May 29, 2016 at 05:49:17PM +0300, Oded Gabbay wrote: > On Fri, May 27, 2016 at 4:18 AM, Luis R. Rodriguez > wrote: > > diff --git a/drivers/gpu/drm/radeon/radeon_drv.c > > b/drivers/gpu/drm/radeon/radeon_drv.c > > index b55aa740171f..1fa1b7f3a89c 100644 > >

[RFT v3] drm: use late_initcall() for amdkfd and radeon

On Sun, May 29, 2016 at 08:27:07PM +0200, Daniel Vetter wrote: > On Fri, May 27, 2016 at 3:18 AM, Luis R. Rodriguez > wrote: > > To get KFD support in radeon we need the following > > initialization to happen in this order, their > > respective driver file that has its

[RFT v3] drm: use late_initcall() for amdkfd and radeon

() however is still the right call in orde to annotate explicitly a delayed dependency requirement between the GPU drivers and the IOMMUs. We can't address the fragile nature of the link order right now, but in the future that might be possible. Signed-off-by: Luis R. Rodriguez --- Please note, t

[Intel-gfx] [PATCH 4/4] drm/i915: Move ioremap_wc tracking onto VMA

On Wed, Apr 20, 2016 at 01:17:30PM +0200, Daniel Vetter wrote: > On Wed, Apr 20, 2016 at 11:10:54AM +0200, Luis R. Rodriguez wrote: > > Reason I ask is since I noticed a while ago a lot of drivers > > were using info->fix.smem_start and info->fix.smem_len consistently > >

[PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map_wc()

On Wed, Apr 20, 2016 at 08:14:32PM +0100, Chris Wilson wrote: > On Wed, Apr 20, 2016 at 08:58:44PM +0200, Luis R. Rodriguez wrote: > > On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote: > > > The ioremap() hidden behind the io_mapping_map_wc() convenience helper

[PATCH 02/19] io-mapping: Specify mapping size for io_mapping_map_wc()

n > Cc: Tvrtko Ursulin > Cc: Daniel Vetter > Cc: Jani Nikula > Cc: David Airlie > Cc: Yishai Hadas > Cc: Dan Williams > Cc: Ingo Molnar > Cc: "Peter Zijlstra (Intel)" > Cc: David Hildenbrand > Cc: Luis R. Rodriguez > Cc: intel-gfx at lists.fre

[PATCH 4/4] drm/i915: Move ioremap_wc tracking onto VMA

On Tue, Apr 19, 2016 at 01:33:58PM +0100, Chris Wilson wrote: > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 6ce2c31b9a81..9ef47329e8ae 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3346,6 +3346,15 @@ static

[PATCH v3] mtrr: avoid ifdef'ery with phys_wc_to_mtrr_index()

On Tue, Apr 21, 2015 at 01:42:51PM -0700, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > There is only one user but since we're going to bury > MTRR next out of access to drivers expose this last > piece of API to drivers in a general fashion only > needin

[PATCH v4] mtrr: avoid ifdef'ery with phys_wc_to_mtrr_index()

From: "Luis R. Rodriguez" <mcg...@suse.com> There is only one user but since we're going to bury MTRR next out of access to drivers expose this last piece of API to drivers in a general fashion only needing io.h for access to helpers. Cc: Toshi Kani Cc: Thomas Gleixner Cc: Ing

[PATCH v3] mtrr: avoid ifdef'ery with phys_wc_to_mtrr_index()

From: "Luis R. Rodriguez" <mcg...@suse.com> There is only one user but since we're going to bury MTRR next out of access to drivers expose this last piece of API to drivers in a general fashion only needing io.h for access to helpers. Cc: Toshi Kani Cc: Thomas Gleixner Cc: Ing

[PATCH 00/22] Add and use pci_zalloc_consistent

On Mon, Jun 23, 2014 at 06:41:28AM -0700, Joe Perches wrote: > Adding the helper reduces object code size as well as overall > source size line count. > > It's also consistent with all the various zalloc mechanisms > in the kernel. > > Done with a simple cocci script and some typing. Awesome,

[PATCH 08/14] backports: backport ww_mutex support

From: "Luis R. Rodriguez" <mcg...@do-not-panic.com> This backports the kernel's wound/wait style locks 040a0a371, using the linux-stable v3.11-rc2 as a base for development. Given the complexity to support debugging mutexes this backport implementation is simplified by only mak

[PATCH 08/14] backports: backport ww_mutex support

From: Luis R. Rodriguez mcg...@do-not-panic.com This backports the kernel's wound/wait style locks 040a0a371, using the linux-stable v3.11-rc2 as a base for development. Given the complexity to support debugging mutexes this backport implementation is simplified by only making this feature

[RFC 7/9] backports: backport ww_mutex support

From: Luis R. Rodriguez mcg...@do-not-panic.com This backports the kernel's wound/wait style locks 040a0a371, using the linux-stable v3.11-rc2 as a base for development. Given the complexity to support debugging mutexes this backport implementation is simplified by only making this feature

[RFC 7/9] backports: backport ww_mutex support

From: "Luis R. Rodriguez" <mcg...@do-not-panic.com> This backports the kernel's wound/wait style locks 040a0a371, using the linux-stable v3.11-rc2 as a base for development. Given the complexity to support debugging mutexes this backport implementation is simplified by only mak

Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, Mar 28, 2013 at 9:19 AM, Julia Lawall julia.law...@lip6.fr wrote: On Thu, 28 Mar 2013, Jesse Barnes wrote: - info-skip_vt_switch = true; + fb_enable_skip_vt_switch(info); So we'd then have to just add this static inline change for each new driver... There

Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall julia.law...@lip6.fr wrote: On Thu, 28 Mar 2013, Luis R. Rodriguez wrote: Thanks Julia! I'll be sure to try to add this to compat-drivers if the upstream fb patch is not accepted. If it is accepted we would not need this at all! Then I guess

Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, Mar 28, 2013 at 3:29 PM, Julia Lawall julia.law...@lip6.fr wrote: On Thu, 28 Mar 2013, Luis R. Rodriguez wrote: On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall julia.law...@lip6.fr wrote: On Thu, 28 Mar 2013, Luis R. Rodriguez wrote: Thanks Julia! I'll be sure to try to add

Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, Mar 28, 2013 at 11:21 PM, Julia Lawall julia.law...@lip6.fr wrote: I looked in today's linux-next, and there seems to be only one initialization of this field, to true, and one test of this field. So perhaps the case for setting the field to false just isn't needed. Oh sorry now I

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, Mar 28, 2013 at 11:21 PM, Julia Lawall wrote: >> > I looked in today's linux-next, and there seems to be only one >> > initialization of this field, to true, and one test of this field. So >> > perhaps the case for setting the field to false just isn't needed. >> >> Oh sorry now I get

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, Mar 28, 2013 at 3:29 PM, Julia Lawall wrote: > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote: > >> On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall >> wrote: >> > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote: >> >> >> >> Thanks Julia

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall wrote: > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote: >> >> Thanks Julia! I'll be sure to try to add this to compat-drivers if the >> upstream fb patch is not accepted. If it is accepted we would not need >> this a

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, Mar 28, 2013 at 9:19 AM, Julia Lawall wrote: > On Thu, 28 Mar 2013, Jesse Barnes wrote: >> > - info->skip_vt_switch = true; >> > + fb_enable_skip_vt_switch(info); >> > >> > So we'd then have to just add this static inline change for each new >> > driver... >> > There

[PATCH 4/4] fb: add helpers to enable and test for the skip_vt_switch

From: "Luis R. Rodriguez" <mcg...@do-not-panic.com> This adds helpers to enable and test for the skip_vt_switch. This gets us two things: 1) It allows us to require less collateral evolutions should we need changes on the fb_info data structure later (perhaps a bitmap f

[PATCH 3/4] compat-drivers: simplify backport fb_info->skip_vt_switch CE

From: "Luis R. Rodriguez" <mcg...@do-not-panic.com> The collateral evolution (CE) on the fb_info data structure that added the skip_vt_switch element can be simplified further by replacing the #ifdef hell with a static inline. Furthermore, if the static inline is added upstream

[PATCH 2/4] compat: backport fb_info->skip_vt_switch using a static inline

From: "Luis R. Rodriguez" <mcg...@do-not-panic.com> Commit 3cf2667 as of next-20130301 extended the struct fb_info with a skip_vt_switch to allow drivers to skip the VT switch at suspend/resume time. For older kernels we can skip this as all this switch does is call pm_vt

[PATCH 1/4] compat-drivers: backport fb_info->skip_vt_switch using ifdefs

From: "Luis R. Rodriguez" <mcg...@do-not-panic.com> Commit 3cf2667 as of next-20130301 extended the struct fb_info with a skip_vt_switch to allow drivers to skip the VT switch at suspend/resume time. For older kernels we can skip this as all this switch does is call pm_vt

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

From: "Luis R. Rodriguez" <mcg...@do-not-panic.com> I maintain the the compat-drivers project [0] which aims at backporting the Linux kernel drivers down to older kernels, automatically [1]. Thanks to Ozan Caglayan as a GSoC project we now backport DRM drivers. The initial fram

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

From: Luis R. Rodriguez mcg...@do-not-panic.com I maintain the the compat-drivers project [0] which aims at backporting the Linux kernel drivers down to older kernels, automatically [1]. Thanks to Ozan Caglayan as a GSoC project we now backport DRM drivers. The initial framework we had set up

[PATCH 1/4] compat-drivers: backport fb_info-skip_vt_switch using ifdefs

From: Luis R. Rodriguez mcg...@do-not-panic.com Commit 3cf2667 as of next-20130301 extended the struct fb_info with a skip_vt_switch to allow drivers to skip the VT switch at suspend/resume time. For older kernels we can skip this as all this switch does is call pm_vt_switch_required() with true

[PATCH 2/4] compat: backport fb_info-skip_vt_switch using a static inline

From: Luis R. Rodriguez mcg...@do-not-panic.com Commit 3cf2667 as of next-20130301 extended the struct fb_info with a skip_vt_switch to allow drivers to skip the VT switch at suspend/resume time. For older kernels we can skip this as all this switch does is call pm_vt_switch_required() with true

[PATCH 3/4] compat-drivers: simplify backport fb_info-skip_vt_switch CE

From: Luis R. Rodriguez mcg...@do-not-panic.com The collateral evolution (CE) on the fb_info data structure that added the skip_vt_switch element can be simplified further by replacing the #ifdef hell with a static inline. Furthermore, if the static inline is added upstream it'd mean we can get

[PATCH 4/4] fb: add helpers to enable and test for the skip_vt_switch

From: Luis R. Rodriguez mcg...@do-not-panic.com This adds helpers to enable and test for the skip_vt_switch. This gets us two things: 1) It allows us to require less collateral evolutions should we need changes on the fb_info data structure later (perhaps a bitmap flag). 2) Allows

compat-drivers based on v3.8.3

patches compat-drivers: move disable_drm compat-drivers: refresh patches Luis R. Rodriguez (69): compat-drivers: fix sed for gen-release.sh compat-drivers: add support for uploading stable releases compat-drivers: add / to target stable release end dir compat

compat-drivers based on v3.8.3

esh patches compat-drivers: move disable_drm compat-drivers: refresh patches Luis R. Rodriguez (69): compat-drivers: fix sed for gen-release.sh compat-drivers: add support for uploading stable releases compat-drivers: add / to target stable release end dir com

[PATCH 0/6] drivers: convert struct spinlock to spinlock_t

On Fri, Nov 30, 2012 at 11:18 AM, Luis R. Rodriguez wrote: > On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel > wrote: >> So what is the rationale here. During mainlining our drivers we had to >> remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle >

[PATCH 0/6] drivers: convert struct spinlock to spinlock_t

On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel wrote: > So what is the rationale here. During mainlining our drivers we had to > remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle > (chapter 5 Typedefs) is spending a number of lines explaining why. > > So is spinlock_t an

Re: [PATCH 0/6] drivers: convert struct spinlock to spinlock_t

On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel ar...@broadcom.com wrote: So what is the rationale here. During mainlining our drivers we had to remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle (chapter 5 Typedefs) is spending a number of lines explaining why. So is

Re: [PATCH 0/6] drivers: convert struct spinlock to spinlock_t

On Fri, Nov 30, 2012 at 11:18 AM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel ar...@broadcom.com wrote: So what is the rationale here. During mainlining our drivers we had to remove all uses of 'typedef struct foo foo_t;'. The Linux

[PATCH 2/6] i915: convert struct spinlock to spinlock_t

From: "Luis R. Rodriguez" <mcg...@do-not-panic.com> spinlock_t should always be used. LD drivers/gpu/drm/i915/built-in.o CHECK drivers/gpu/drm/i915/i915_drv.c CC [M] drivers/gpu/drm/i915/i915_drv.o CHECK drivers/gpu/drm/i915/i915_dma.c CC [M] drivers/gpu/drm

[PATCH 0/6] drivers: convert struct spinlock to spinlock_t

From: "Luis R. Rodriguez" <mcg...@do-not-panic.com> Turns out a few drivers have strayed away from using the spinlock_t typedef and decided to use struct spinlock directly. This series converts these drivers to use spinlock_t. Each change has been compile tested with allmodc

[PATCH 0/6] drivers: convert struct spinlock to spinlock_t

From: Luis R. Rodriguez mcg...@do-not-panic.com Turns out a few drivers have strayed away from using the spinlock_t typedef and decided to use struct spinlock directly. This series converts these drivers to use spinlock_t. Each change has been compile tested with allmodconfig and sparse checked

[PATCH 2/6] i915: convert struct spinlock to spinlock_t

From: Luis R. Rodriguez mcg...@do-not-panic.com spinlock_t should always be used. LD drivers/gpu/drm/i915/built-in.o CHECK drivers/gpu/drm/i915/i915_drv.c CC [M] drivers/gpu/drm/i915/i915_drv.o CHECK drivers/gpu/drm/i915/i915_dma.c CC [M] drivers/gpu/drm/i915/i915_dma.o

[PATCH 1/2] uapi: update includes for drm content when no kernel API exists

On Tue, Oct 16, 2012 at 5:34 AM, Laurent Pinchart wrote: > Hi Luis, > > On Saturday 13 October 2012 10:00:42 Luis R. Rodriguez wrote: >> On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart wrote: >> > On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote: >&g

Re: [PATCH 1/2] uapi: update includes for drm content when no kernel API exists

On Tue, Oct 16, 2012 at 5:34 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Luis, On Saturday 13 October 2012 10:00:42 Luis R. Rodriguez wrote: On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart wrote: On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote: From: Luis

[PATCH 0/2] uapi: two minor changes

From: Luis R. Rodriguez mcg...@do-not-panic.com Here are a few minor updates to the UAPI changes [0]. The first one is to help with the backport effort [1], the second one is simply space cosmetic change to address my eyes bleeding while reviewing the changes on next-20121012 with git

[PATCH 1/2] uapi: update includes for drm content when no kernel API exists

From: Luis R. Rodriguez mcg...@do-not-panic.com The UAPI changes split kernel API and userspace API content onto two separate header files. The userspace API drm content was moved to include/uapi/drm/ with the same file name while kernel specific API content was kept under include/drm

[PATCH 2/2] uapi: remove trailing spaces

From: Luis R. Rodriguez mcg...@do-not-panic.com No functional changes. Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: de...@driverdev.osuosl.org Cc: backpo...@vger.kernel.org Cc: Rob Clark r...@ti.com Cc: Arnd Bergmann a...@arndb.de Cc: Dave Jones da...@redhat.com Cc

Re: [PATCH 1/2] uapi: update includes for drm content when no kernel API exists

On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Luis, On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@do-not-panic.com The UAPI changes split kernel API and userspace API content onto two separate

[PATCH 1/2] uapi: update includes for drm content when no kernel API exists

On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart wrote: > Hi Luis, > > On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote: >> From: "Luis R. Rodriguez" >> >> The UAPI changes split kernel API and userspace API >> content onto two separate hea

[PATCH 2/2] uapi: remove trailing spaces

From: "Luis R. Rodriguez" <mcg...@do-not-panic.com> No functional changes. Cc: dri-devel at lists.freedesktop.org Cc: linux-kernel at vger.kernel.org Cc: devel at driverdev.osuosl.org Cc: backports at vger.kernel.org Cc: Rob Clark Cc: Arnd Bergmann Cc: Dave Jones Cc: David

[PATCH 1/2] uapi: update includes for drm content when no kernel API exists

From: "Luis R. Rodriguez" <mcg...@do-not-panic.com> The UAPI changes split kernel API and userspace API content onto two separate header files. The userspace API drm content was moved to include/uapi/drm/ with the same file name while kernel specific API content was kept u

[PATCH 0/2] uapi: two minor changes

From: "Luis R. Rodriguez" <mcg...@do-not-panic.com> Here are a few minor updates to the UAPI changes [0]. The first one is to help with the backport effort [1], the second one is simply space cosmetic change to address my eyes bleeding while reviewing the changes on next-2

Re: [Lf_driver_backport] [ANN] compat-drm tree

On Wed, Jun 27, 2012 at 3:27 PM, Ozan Çağlayan ozan...@gmail.com wrote: Hi, I'm maintaining a compat-drm tree (based on compat.git) as part of my GSoC project with Linux Foundation, under the mentorship of Luis R. Rodriguez. The aim of the tree is to offer the latest DRM stuff to people

[Lf_driver_backport] [ANN] compat-drm tree

On Wed, Jun 27, 2012 at 3:27 PM, Ozan ?a?layan wrote: > Hi, > > I'm maintaining a compat-drm tree (based on compat.git) as part of my > GSoC project with Linux Foundation, under the mentorship of Luis R. > Rodriguez. > > The aim of the tree is to offer the latest DRM

[PATCH 0/9] treewide: convert vprintk uses to %pV

On Tue, Nov 9, 2010 at 4:35 PM, Joe Perches wrote: > Multiple secessive calls to printk can be interleaved. > Avoid this possible interleaving by using %pV > > Joe Perches (9): > ?drivers/gpu/drm/drm_stub.c: Use printf extension %pV > ?drivers/isdn/mISDN: Use printf extension %pV >

Re: [PATCH 0/9] treewide: convert vprintk uses to %pV

On Tue, Nov 9, 2010 at 4:35 PM, Joe Perches j...@perches.com wrote: Multiple secessive calls to printk can be interleaved. Avoid this possible interleaving by using %pV Joe Perches (9):  drivers/gpu/drm/drm_stub.c: Use printf extension %pV  drivers/isdn/mISDN: Use printf extension %pV  

Re: [PATCH 00/15] change default_llseek action

On Wed, Sep 15, 2010 at 2:39 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi Arnd, On Tue, 14 Sep 2010 22:22:28 +0200 Arnd Bergmann a...@arndb.de wrote: Stephen, please add git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git llseek Added from today. Thanks for adding

[PATCH 00/15] change default_llseek action

On Wed, Sep 15, 2010 at 2:39 AM, Stephen Rothwell wrote: > Hi Arnd, > > On Tue, 14 Sep 2010 22:22:28 +0200 Arnd Bergmann wrote: >> >> Stephen, please add >> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git llseek > > Added from today. > > Thanks for adding your subsystem tree