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 networking book: a non-standa
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
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:
>> > >
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 mapp
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:
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
> >
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
ll() 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
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
> >
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
>
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
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 vo
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
> n
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
needing io.h for access to helpers.
Cc: Toshi Kani
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "
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
needing io.h for access to helpers.
Cc: Toshi Kani
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "
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, an
From: "Luis R. Rodriguez"
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 availabe
From: "Luis R. Rodriguez"
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 availabe
From: "Luis R. Rodriguez"
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 availabe
From: "Luis R. Rodriguez"
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 availabe
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 wha
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! I'll b
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 at
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 may
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 wha
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! I
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 at
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 may
From: "Luis R. Rodriguez"
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 this fea
From: "Luis R. Rodriguez"
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 r
From: "Luis R. Rodriguez"
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
or false de
From: "Luis R. Rodriguez"
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
or false de
From: "Luis R. Rodriguez"
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 to hel
From: "Luis R. Rodriguez"
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 this fea
From: "Luis R. Rodriguez"
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 r
From: "Luis R. Rodriguez"
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
or false de
From: "Luis R. Rodriguez"
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
or false de
From: "Luis R. Rodriguez"
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 to hel
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
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
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
&
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 ex
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 CodingStyl
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 e
From: "Luis R. Rodriguez"
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
CHECK drive
From: "Luis R. Rodriguez"
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. Driver deve
From: "Luis R. Rodriguez"
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
CHECK drive
From: "Luis R. Rodriguez"
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. Driver deve
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
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
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
From: "Luis R. Rodriguez"
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
Cc: Arnd Bergmann
Cc: Dave Jones
Cc: David Airlie
Cc: Ben Skeggs
Cc: Alan Cox
Cc: Dav
From: "Luis R. Rodriguez"
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/ with the same file
From: "Luis R. Rodriguez"
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.
If the changes on
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
From: "Luis R. Rodriguez"
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 Airlie
Cc: Ben Skeggs
Cc: Al
From: "Luis R. Rodriguez"
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/ with the same file
From: "Luis R. Rodriguez"
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.
If the changes on
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 st
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 st
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
> drivers/net/wi
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
> ?drivers/net/wi
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 as
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 as
64 matches
Mail list logo