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

[Luis R. Rodriguez]

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-standard footnote there
> > with [*] instead of a number causes it to break PDF building.
> > 
> > So, I took some spare time to address some warnings all over
> > the tree, and moved a few text documents to a book. 
> 
> OK, I've applied the ones that seem to make sense for me to take now.
> There's comments on the firmware one, 

I'll fold in the fixes for the firmware API which do apply to my queue.

  Luis
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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 be reliable
Mar 16 18:28:59 olga kernel: WARNING: CPU: 5 PID: 74 at 
../drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 
nvkm_dp_enable+0xbe/0x140 [nouveau]
Mar 16 18:28:59 olga kernel: Modules linked in: ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 
nf_nat nf_conntrack libcrc32c iptable_filter ip
Mar 16 18:28:59 olga kernel:  i2c_algo_bit drm_kms_helper syscopyarea 
sysfillrect sysimgblt fb_sys_fops xhci_hcd ehci_hcd sr_mod ttm cdrom usbcore 
ata_generic drm wmi button sg dm_multipath 
Mar 16 18:28:59 olga kernel: CPU: 5 PID: 74 Comm: kworker/5:1 Not tainted 
4.15.8-1-default #1
Mar 16 18:28:59 olga kernel: Hardware name: Dell Inc. Precision T3610/09M8Y8, 
BIOS A03 09/05/2013
Mar 16 18:28:59 olga kernel: Workqueue: events nvkm_notify_work [nouveau]
Mar 16 18:28:59 olga kernel: RIP: 0010:nvkm_dp_enable+0xbe/0x140 [nouveau]
Mar 16 18:28:59 olga kernel: RSP: 0018:bad4c1c27e30 EFLAGS: 00010287
Mar 16 18:28:59 olga kernel: RAX:  RBX: 92daf85fbc00 RCX: 
bad4c1c27e37
Mar 16 18:28:59 olga kernel: RDX: bad4c300e4e4 RSI: bad4c300e4e4 RDI: 
0100900f
Mar 16 18:28:59 olga kernel: RBP: 92daf85ae000 R08: 92daf85fbd11 R09: 
bad4c1c27e37
Mar 16 18:28:59 olga kernel: R10:  R11:  R12: 
92dc1a594620
Mar 16 18:28:59 olga kernel: R13: 92daf8831b40 R14: 092dc2fd6860 R15: 
92d94581cc00
Mar 16 18:28:59 olga kernel: FS:  () 
GS:92dc2fd4() knlGS:
Mar 16 18:28:59 olga kernel: CS:  0010 DS:  ES:  CR0: 80050033
Mar 16 18:28:59 olga kernel: CR2: 01895000 CR3: 00033800a004 CR4: 
001626e0
Mar 16 18:28:59 olga kernel: Call Trace:
Mar 16 18:28:59 olga kernel:  nvkm_dp_hpd+0x113/0x120 [nouveau]
Mar 16 18:28:59 olga kernel:  nvkm_notify_work+0x1e/0x70 [nouveau]
Mar 16 18:28:59 olga kernel:  process_one_work+0x1d1/0x400
Mar 16 18:28:59 olga kernel:  worker_thread+0x2b/0x3d0
Mar 16 18:28:59 olga kernel:  ? process_one_work+0x400/0x400
Mar 16 18:28:59 olga kernel:  kthread+0x113/0x130
Mar 16 18:28:59 olga kernel:  ? kthread_create_worker_on_cpu+0x50/0x50
Mar 16 18:28:59 olga kernel:  ret_from_fork+0x3a/0x50
Mar 16 18:28:59 olga kernel: Code: 4c 8d 4c 24 07 4c 8d 83 11 01 00 00 31 c9 ba 
09 00 00 00 be 01 00 00 00 48 89 ef e8 cd 31 fd ff 85 c0 75 75 80 7c 24 07 10 
74 02 <0f> 0b 48 89 ef e8 c8 2f 
Mar 16 18:28:59 olga kernel: ---[ end trace 86032f0cbd15 ]---

  Luis
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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 Fri, May 27, 2016 at 3:18 AM, Luis R. Rodriguez > > > kernel.org> wrote:
>> > > > To get KFD support in radeon we need the following
>> > > > initialization to happen in this order, their
>> > > > respective driver file that has its init routine
>> > > > listed next to it:
>> > > >
>> > > > 0. AMD IOMMUv1:arch/x86/kernel/pci-dma.c
>> > > > 1. AMD IOMMUv2:drivers/iommu/amd_iommu_v2.c
>> > > > 2. AMD KFD:drivers/gpu/drm/amd/amdkfd/kfd_module.c
>> > > > 3. AMD Radeon: drivers/gpu/drm/radeon/radeon_drv.c
>> > > >
>> > > > Order is rather implicit, but these drivers can currently
>> > > > only do so much given the amount of leg room available.
>> > > > Below are the respective init routines and how they are
>> > > > initialized:
>> > > >
>> > > > arch/x86/kernel/pci-dma.c   
>> > > > rootfs_initcall(pci_iommu_init);
>> > > > drivers/iommu/amd_iommu_v2.cmodule_init(amd_iommu_v2_init);
>> > > > drivers/gpu/drm/amd/amdkfd/kfd_module.c module_init(kfd_module_init);
>> > > > drivers/gpu/drm/radeon/radeon_drv.c module_init(radeon_init);
>> > > >
>> > > > When a driver is built-in module_init() folds to use
>> > > > device_initcall(), and we have the following possible
>> > > > orders:
>> > > >
>> > > > #define pure_initcall(fn)__define_initcall(fn, 0)
>> > > > #define core_initcall(fn)__define_initcall(fn, 1)
>> > > > #define postcore_initcall(fn)__define_initcall(fn, 2)
>> > > > #define arch_initcall(fn)__define_initcall(fn, 3)
>> > > > #define subsys_initcall(fn)  __define_initcall(fn, 4)
>> > > > #define fs_initcall(fn)  __define_initcall(fn, 5)
>> > > > -
>> > > > #define rootfs_initcall(fn)  __define_initcall(fn, rootfs)
>> > > > #define device_initcall(fn)  __define_initcall(fn, 6)
>> > > > #define late_initcall(fn)__define_initcall(fn, 7)
>> > > >
>> > > > Since we start off from rootfs_initcall(), it gives us 3 more
>> > > > levels of leg room to play with for order semantics, this isn't
>> > > > enough to address all required levels of dependencies, this
>> > > > is specially true given that AMD-KFD needs to be loaded before
>> > > > the radeon driver -- -but this it not enforced by symbols.
>> > > > If the AMD-KFD driver is not loaded prior to the radeon driver
>> > > > because otherwise the radeon driver will not initialize the
>> > > > AMD-KFD driver and you get no KFD functionality in userspace.
>> > > >
>> > > > Commit 1bacc894c227fad8a7 ("drivers: Move iommu/ before gpu/ in
>> > > > Makefile") works around some of the possibe races between
>> > > > the AMD IOMMU v2 and GPU drivers by changing the link order.
>> > > > This is fragile, however its the bets we can do, given that
>> > > > making the GPU drivers use late_initcall() would also implicate
>> > > > a similar race between them. That possible race is fortunatley
>> > > > addressed given that the drm Makefile currently has amdkfd
>> > > > linked prior to radeon:
>> > > >
>> > > > drivers/gpu/drm/Makefile
>> > > > ...
>> > > > obj-$(CONFIG_HSA_AMD) += amd/amdkfd/
>> > > > obj-$(CONFIG_DRM_RADEON)+= radeon/
>> > > > ...
>> > > >
>> > > > Changing amdkfd and radeon to late_initcall() 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: Lu

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

[Luis R. Rodriguez]

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 mappings. It happens that the drm drivers for a number
> of gpus relied on this being broken. Currently the driver only inserted
> VRAM mappings into the tracking table when they came from the kernel,
> and userspace mappings never landed in the table. This led to a regression
> where all the mapping end up as UC instead of WC now.

Eek.

> I've considered a number of solutions but since this needs to be fixed
> in fixes and not next, and some of the solutions were going to introduce
> overhead that hadn't been there before I didn't consider them viable at
> this stage. These mainly concerned hooking into the TTM io reserve APIs,
> but these API have a bunch of fast paths I didn't want to unwind to add
> this to.
> 
> The solution I've decided on is to add a new API like the arch_phys_wc
> APIs (these would have worked but wc_del didn't take a range), and
> use them from the drivers to add a WC compatible mapping to the table
> for all VRAM on those GPUs. This means we can then create userspace
> mapping that won't get degraded to UC.

Is anything on a driver to be able to tell when this is actually needed ?
How will driver developers know? Can you add a bit of documentation to
the API? If its transitive towards a secondary solution indicating so
would help driver developers.

  Luis

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

[Luis R. Rodriguez]

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:
> > > > To get KFD support in radeon we need the following
> > > > initialization to happen in this order, their
> > > > respective driver file that has its init routine
> > > > listed next to it:
> > > >
> > > > 0. AMD IOMMUv1:arch/x86/kernel/pci-dma.c
> > > > 1. AMD IOMMUv2:drivers/iommu/amd_iommu_v2.c
> > > > 2. AMD KFD:drivers/gpu/drm/amd/amdkfd/kfd_module.c
> > > > 3. AMD Radeon: drivers/gpu/drm/radeon/radeon_drv.c
> > > >
> > > > Order is rather implicit, but these drivers can currently
> > > > only do so much given the amount of leg room available.
> > > > Below are the respective init routines and how they are
> > > > initialized:
> > > >
> > > > arch/x86/kernel/pci-dma.c   rootfs_initcall(pci_iommu_init);
> > > > drivers/iommu/amd_iommu_v2.cmodule_init(amd_iommu_v2_init);
> > > > drivers/gpu/drm/amd/amdkfd/kfd_module.c module_init(kfd_module_init);
> > > > drivers/gpu/drm/radeon/radeon_drv.c module_init(radeon_init);
> > > >
> > > > When a driver is built-in module_init() folds to use
> > > > device_initcall(), and we have the following possible
> > > > orders:
> > > >
> > > > #define pure_initcall(fn)__define_initcall(fn, 0)
> > > > #define core_initcall(fn)__define_initcall(fn, 1)
> > > > #define postcore_initcall(fn)__define_initcall(fn, 2)
> > > > #define arch_initcall(fn)__define_initcall(fn, 3)
> > > > #define subsys_initcall(fn)  __define_initcall(fn, 4)
> > > > #define fs_initcall(fn)  __define_initcall(fn, 5)
> > > > -
> > > > #define rootfs_initcall(fn)  __define_initcall(fn, rootfs)
> > > > #define device_initcall(fn)  __define_initcall(fn, 6)
> > > > #define late_initcall(fn)__define_initcall(fn, 7)
> > > >
> > > > Since we start off from rootfs_initcall(), it gives us 3 more
> > > > levels of leg room to play with for order semantics, this isn't
> > > > enough to address all required levels of dependencies, this
> > > > is specially true given that AMD-KFD needs to be loaded before
> > > > the radeon driver -- -but this it not enforced by symbols.
> > > > If the AMD-KFD driver is not loaded prior to the radeon driver
> > > > because otherwise the radeon driver will not initialize the
> > > > AMD-KFD driver and you get no KFD functionality in userspace.
> > > >
> > > > Commit 1bacc894c227fad8a7 ("drivers: Move iommu/ before gpu/ in
> > > > Makefile") works around some of the possibe races between
> > > > the AMD IOMMU v2 and GPU drivers by changing the link order.
> > > > This is fragile, however its the bets we can do, given that
> > > > making the GPU drivers use late_initcall() would also implicate
> > > > a similar race between them. That possible race is fortunatley
> > > > addressed given that the drm Makefile currently has amdkfd
> > > > linked prior to radeon:
> > > >
> > > > drivers/gpu/drm/Makefile
> > > > ...
> > > > obj-$(CONFIG_HSA_AMD) += amd/amdkfd/
> > > > obj-$(CONFIG_DRM_RADEON)+= radeon/
> > > > ...
> > > >
> > > > Changing amdkfd and radeon to late_initcall() 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, the changes to drivers/Makefile are just
> > > > for the sake of forcing the possible race to occur,
> > > > if this works well the actual [PATCH] submission will
> > > > skip those changes as its pointless to remove those
> > > > work ar

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

[Luis R. Rodriguez]

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
> > --- a/drivers/gpu/drm/radeon/radeon_drv.c
> > +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> > @@ -609,7 +609,7 @@ static void __exit radeon_exit(void)
> > radeon_unregister_atpx_handler();
> >  }
> >
> > -module_init(radeon_init);
> > +late_initcall(radeon_init);
> >  module_exit(radeon_exit);
> 
> Need to modify also amdgpu module_init

Thanks, so other than considering the first two hunks are only for testing 
purposes
(a proper [PATCH] will drop these hunks on the Makefile), you're suggestng this
then, is that right?:

---
 drivers/Makefile| 6 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_module.c | 2 +-
 drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
 4 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 0b6f3d60193d..0fbe3982041f 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -50,10 +50,7 @@ obj-$(CONFIG_RESET_CONTROLLER)   += reset/
 obj-y  += tty/
 obj-y  += char/

-# iommu/ comes before gpu as gpu are using iommu controllers
-obj-$(CONFIG_IOMMU_SUPPORT)+= iommu/
-
-# gpu/ comes after char for AGP vs DRM startup and after iommu
+# gpu/ comes after char for AGP vs DRM startup
 obj-y  += gpu/

 obj-$(CONFIG_CONNECTOR)+= connector/
@@ -147,6 +144,7 @@ obj-y   += clk/

 obj-$(CONFIG_MAILBOX)  += mailbox/
 obj-$(CONFIG_HWSPINLOCK)   += hwspinlock/
+obj-$(CONFIG_IOMMU_SUPPORT)+= iommu/
 obj-$(CONFIG_REMOTEPROC)   += remoteproc/
 obj-$(CONFIG_RPMSG)+= rpmsg/

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 1dab5f2b725b..1ca448f2b4d2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -589,7 +589,7 @@ static void __exit amdgpu_exit(void)
amdgpu_sync_fini();
 }

-module_init(amdgpu_init);
+late_initcall(amdgpu_init);
 module_exit(amdgpu_exit);

 MODULE_AUTHOR(DRIVER_AUTHOR);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
index 850a5623661f..3d1dab8a31c7 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
@@ -141,7 +141,7 @@ static void __exit kfd_module_exit(void)
dev_info(kfd_device, "Removed module\n");
 }

-module_init(kfd_module_init);
+late_initcall(kfd_module_init);
 module_exit(kfd_module_exit);

 MODULE_AUTHOR(KFD_DRIVER_AUTHOR);
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index b55aa740171f..1fa1b7f3a89c 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -609,7 +609,7 @@ static void __exit radeon_exit(void)
radeon_unregister_atpx_handler();
 }

-module_init(radeon_init);
+late_initcall(radeon_init);
 module_exit(radeon_exit);

 MODULE_AUTHOR(DRIVER_AUTHOR);
-- 
2.8.2


> I tested this on Kaveri, and amdkfd is working. For amdkfd that's
> fine, but IMO that's not enough testing for radeon/amdgpu. I would
> like to hear AMD's developers take on this.

Sure. Hopefully the above extensions suffice. In the future we should be able
to also replace the radeon amdkfd -EPROBE_DEFER kludge and the implicit
sensitivity in Makefiles over GPU drivers and IOMMUs, but a bit more work is
needed before that happens.

  Luis

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

[Luis R. Rodriguez]

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 init routine
> > listed next to it:
> >
> > 0. AMD IOMMUv1:arch/x86/kernel/pci-dma.c
> > 1. AMD IOMMUv2:drivers/iommu/amd_iommu_v2.c
> > 2. AMD KFD:drivers/gpu/drm/amd/amdkfd/kfd_module.c
> > 3. AMD Radeon: drivers/gpu/drm/radeon/radeon_drv.c
> >
> > Order is rather implicit, but these drivers can currently
> > only do so much given the amount of leg room available.
> > Below are the respective init routines and how they are
> > initialized:
> >
> > arch/x86/kernel/pci-dma.c   rootfs_initcall(pci_iommu_init);
> > drivers/iommu/amd_iommu_v2.cmodule_init(amd_iommu_v2_init);
> > drivers/gpu/drm/amd/amdkfd/kfd_module.c module_init(kfd_module_init);
> > drivers/gpu/drm/radeon/radeon_drv.c module_init(radeon_init);
> >
> > When a driver is built-in module_init() folds to use
> > device_initcall(), and we have the following possible
> > orders:
> >
> > #define pure_initcall(fn)__define_initcall(fn, 0)
> > #define core_initcall(fn)__define_initcall(fn, 1)
> > #define postcore_initcall(fn)__define_initcall(fn, 2)
> > #define arch_initcall(fn)__define_initcall(fn, 3)
> > #define subsys_initcall(fn)  __define_initcall(fn, 4)
> > #define fs_initcall(fn)  __define_initcall(fn, 5)
> > -
> > #define rootfs_initcall(fn)  __define_initcall(fn, rootfs)
> > #define device_initcall(fn)  __define_initcall(fn, 6)
> > #define late_initcall(fn)__define_initcall(fn, 7)
> >
> > Since we start off from rootfs_initcall(), it gives us 3 more
> > levels of leg room to play with for order semantics, this isn't
> > enough to address all required levels of dependencies, this
> > is specially true given that AMD-KFD needs to be loaded before
> > the radeon driver -- -but this it not enforced by symbols.
> > If the AMD-KFD driver is not loaded prior to the radeon driver
> > because otherwise the radeon driver will not initialize the
> > AMD-KFD driver and you get no KFD functionality in userspace.
> >
> > Commit 1bacc894c227fad8a7 ("drivers: Move iommu/ before gpu/ in
> > Makefile") works around some of the possibe races between
> > the AMD IOMMU v2 and GPU drivers by changing the link order.
> > This is fragile, however its the bets we can do, given that
> > making the GPU drivers use late_initcall() would also implicate
> > a similar race between them. That possible race is fortunatley
> > addressed given that the drm Makefile currently has amdkfd
> > linked prior to radeon:
> >
> > drivers/gpu/drm/Makefile
> > ...
> > obj-$(CONFIG_HSA_AMD) += amd/amdkfd/
> > obj-$(CONFIG_DRM_RADEON)+= radeon/
> > ...
> >
> > Changing amdkfd and radeon to late_initcall() 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, the changes to drivers/Makefile are just
> > for the sake of forcing the possible race to occur,
> > if this works well the actual [PATCH] submission will
> > skip those changes as its pointless to remove those
> > work arounds as it stands, due to the limited nature
> > of the levels available for addressing requirements.
> >
> > Also, if you are aware of further dependency hell
> > things like these -- please do let me know as I am
> > interested in looking at addressing them.
> 
> This should be fixed with -EDEFER_PROBE instead. Frobbing initcall
> levels should then just be done as an optimization to avoid too much
> reprobing.

radeon already uses -EDEFER_PROBE but it assumes that amdkfd *is* loaded first,
and only if it is already loaded can it count on getting -EDEFER_PROBE. The
radeon driver will deffer probe *iff* kgd2kfd_init() returns -EDEFER_PROBE,
which only happens when amdkfd_init_completed is no longer present. If radeon
gets linked first though the symbol fetch for kgd2kfd_init() will make it as
not-present though. So the current heuristic used does not address proper lin

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

[Luis R. Rodriguez]

To get KFD support in radeon we need the following
initialization to happen in this order, their
respective driver file that has its init routine
listed next to it:

0. AMD IOMMUv1:arch/x86/kernel/pci-dma.c
1. AMD IOMMUv2:drivers/iommu/amd_iommu_v2.c
2. AMD KFD:drivers/gpu/drm/amd/amdkfd/kfd_module.c
3. AMD Radeon: drivers/gpu/drm/radeon/radeon_drv.c

Order is rather implicit, but these drivers can currently
only do so much given the amount of leg room available.
Below are the respective init routines and how they are
initialized:

arch/x86/kernel/pci-dma.c   rootfs_initcall(pci_iommu_init);
drivers/iommu/amd_iommu_v2.cmodule_init(amd_iommu_v2_init);
drivers/gpu/drm/amd/amdkfd/kfd_module.c module_init(kfd_module_init);
drivers/gpu/drm/radeon/radeon_drv.c module_init(radeon_init);

When a driver is built-in module_init() folds to use
device_initcall(), and we have the following possible
orders:

#define pure_initcall(fn)__define_initcall(fn, 0)
#define core_initcall(fn)__define_initcall(fn, 1)
#define postcore_initcall(fn)__define_initcall(fn, 2)
#define arch_initcall(fn)__define_initcall(fn, 3)
#define subsys_initcall(fn)  __define_initcall(fn, 4)
#define fs_initcall(fn)  __define_initcall(fn, 5)
-
#define rootfs_initcall(fn)  __define_initcall(fn, rootfs)
#define device_initcall(fn)  __define_initcall(fn, 6)
#define late_initcall(fn)__define_initcall(fn, 7)

Since we start off from rootfs_initcall(), it gives us 3 more
levels of leg room to play with for order semantics, this isn't
enough to address all required levels of dependencies, this
is specially true given that AMD-KFD needs to be loaded before
the radeon driver -- -but this it not enforced by symbols.
If the AMD-KFD driver is not loaded prior to the radeon driver
because otherwise the radeon driver will not initialize the
AMD-KFD driver and you get no KFD functionality in userspace.

Commit 1bacc894c227fad8a7 ("drivers: Move iommu/ before gpu/ in
Makefile") works around some of the possibe races between
the AMD IOMMU v2 and GPU drivers by changing the link order.
This is fragile, however its the bets we can do, given that
making the GPU drivers use late_initcall() would also implicate
a similar race between them. That possible race is fortunatley
addressed given that the drm Makefile currently has amdkfd
linked prior to radeon:

drivers/gpu/drm/Makefile
...
obj-$(CONFIG_HSA_AMD) += amd/amdkfd/
obj-$(CONFIG_DRM_RADEON)+= radeon/
...

Changing amdkfd and radeon to late_initcall() 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, the changes to drivers/Makefile are just
for the sake of forcing the possible race to occur,
if this works well the actual [PATCH] submission will
skip those changes as its pointless to remove those
work arounds as it stands, due to the limited nature
of the levels available for addressing requirements.

Also, if you are aware of further dependency hell
things like these -- please do let me know as I am
interested in looking at addressing them.

 drivers/Makefile| 6 ++
 drivers/gpu/drm/amd/amdkfd/kfd_module.c | 2 +-
 drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 0b6f3d60193d..0fbe3982041f 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -50,10 +50,7 @@ obj-$(CONFIG_RESET_CONTROLLER)   += reset/
 obj-y  += tty/
 obj-y  += char/

-# iommu/ comes before gpu as gpu are using iommu controllers
-obj-$(CONFIG_IOMMU_SUPPORT)+= iommu/
-
-# gpu/ comes after char for AGP vs DRM startup and after iommu
+# gpu/ comes after char for AGP vs DRM startup
 obj-y  += gpu/

 obj-$(CONFIG_CONNECTOR)+= connector/
@@ -147,6 +144,7 @@ obj-y   += clk/

 obj-$(CONFIG_MAILBOX)  += mailbox/
 obj-$(CONFIG_HWSPINLOCK)   += hwspinlock/
+obj-$(CONFIG_IOMMU_SUPPORT)+= iommu/
 obj-$(CONFIG_REMOTEPROC)   += remoteproc/
 obj-$(CONFIG_RPMSG)+= rpmsg/

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
index 850a5623661f..3d1dab8a31c7 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
@@ -141,7 +141,7 @@ static void __exit kfd_module_exit(void)
dev_info(kfd_device, "Removed module\n");
 }

-module_init(kfd_module_init);
+late_initcall(kfd_module_init);
 module_exit(kfd_module_exit);

 MODULE_AUTHOR(KFD_

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

[Luis R. Rodriguez]

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
> > for their ioremap'd areas it might make sense instead to let the
> > internal framebuffer (register_framebuffer()) optionally manage the
> > ioremap_wc() for drivers, given that this is pretty generic stuff.
> 
> All that legacy fbdev stuff is just for legacy support, and I prefer to
> have that as dumb as possible. There's been some discussion even around
> lifting the "kick out firmware fb driver" out of fbdev, since we'd need it
> to have a simple drm driver for e.g. uefi.
> 
> But I definitely don't want a legacy horror show like fbdev to
> automagically take care of device mappings for drivers.

Makes sense, it also still begs the question if more modern APIs
could manage the ioremap for you. Evidence shows people get
sloppy and if things were done internally with helpers it may
be easier to later make adjustments.

  Luis

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

[Luis R. Rodriguez]

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
> > > can be used for remapping multiple pages. Extend the helper so that
> > > future callers can use it for larger ranges.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > 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.freedesktop.org
> > > Cc: dri-devel at lists.freedesktop.org
> > > Cc: netdev at vger.kernel.org
> > > Cc: linux-rdma at vger.kernel.org
> > > Cc: linux-kernel at vger.kernel.org
> > 
> > We have 2 callers today, in the future, can you envision
> > this API getting more options? If so, in order to avoid the
> > pain of collateral evolutions I can suggest a descriptor
> > being passed with the required settings / options. This lets
> > you evolve the API without needing to go in and modify
> > old users. If you choose not to that's fine too, just
> > figured I'd chime in with that as I've seen the pain
> > with other APIs, and I'm putting an end to the needless
> > set of collateral evolutions this way.
> 
> Do you have a good example in mind? I've one more patch to try and take
> advantage of the io-mapping (that may or not be such a good idea in
> practice) but I may as well see if I can make io_mapping more useful
> when I do.

Sure, here's my current version of the revamp of the firmware API
to a more flexible API, which lets us compartamentalize the
usermode helper, and through the new API avoids the issues with further
future collateral evolutions. It is still being baked, I'm fine tuning
the SmPL to folks automatically do conversion if they want:

https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux.git/log/?h=20160417-sysdata-api-v1

It also has a test driver (which I'd also recommend if you can pull off).
It would be kind of hard to do something like a lib/io-mapping_test.c
given there is no real device to ioremap -- _but_ perhaps regular
RAM can be used for fake a device MMIO. I am not sure if its even
possible... but if so it would not only be useful for something
like your API but also for testing ioremap() and friends, and
any possible aliasing bombs we may want to vet for. It also hints
how we may in the future be able to automatically write test drivers
for APIs for us through inference, but that needs a lot of more love
to make it tangible.

  Luis

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

[Luis R. Rodriguez]

On Wed, Apr 20, 2016 at 07:42:13PM +0100, Chris Wilson wrote:
> The ioremap() hidden behind the io_mapping_map_wc() convenience helper
> can be used for remapping multiple pages. Extend the helper so that
> future callers can use it for larger ranges.
> 
> Signed-off-by: Chris Wilson 
> 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.freedesktop.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: netdev at vger.kernel.org
> Cc: linux-rdma at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org

We have 2 callers today, in the future, can you envision
this API getting more options? If so, in order to avoid the
pain of collateral evolutions I can suggest a descriptor
being passed with the required settings / options. This lets
you evolve the API without needing to go in and modify
old users. If you choose not to that's fine too, just
figured I'd chime in with that as I've seen the pain
with other APIs, and I'm putting an end to the needless
set of collateral evolutions this way.

Other than that possible API optimization:

Reviewed-by: Luis R. Rodriguez 

  Luis

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

[Luis R. Rodriguez]

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 void i915_gem_object_finish_gtt(struct 
> drm_i915_gem_object *obj)
>   old_write_domain);
>  }
>  
> +static void __i915_vma_iounmap(struct i915_vma *vma)
> +{
> + if (vma->iomap == NULL)
> + return;
> +
> + io_mapping_unmap(vma->iomap);

The NULL check could just be done by io_mapping_unmap() then you
can avoid this in other drivers too.

> + vma->iomap = NULL;

You added accounting here, by simple int and inc / dec'ing it.
I cannot confirm if it is correctly avoiding races, can you
confirm?

Also you added accounting for the custom vma pinning thing and do
GEM_BUG_ON(vma->pin_count == 0); when you unpin one instance but *you do not*
do something like GEM_BUG_ON(vma->pin_count != 0); when you do the final full
iounmap. That seems rather sloppy.

iomapping stuff has its own custom data structure, why not just use that data
structure instead of the struct i915_vma and generalize this ? Drivers can
be buggy and best if we avoid custom driver accounting and just do it in a neat
generic fashion.

Then other drivers could use this too.

> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 79ac202f3870..93f54a10042f 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -244,22 +245,23 @@ static int intelfb_create(struct drm_fb_helper *helper,
>   info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
>   info->fbops = _ops;
>  
> + vma = i915_gem_obj_to_ggtt(obj);
> +
>   /* setup aperture base/size for vesafb takeover */
>   info->apertures->ranges[0].base = dev->mode_config.fb_base;
>   info->apertures->ranges[0].size = ggtt->mappable_end;
>  
> - info->fix.smem_start = dev->mode_config.fb_base + 
> i915_gem_obj_ggtt_offset(obj);
> - info->fix.smem_len = size;
> + info->fix.smem_start = dev->mode_config.fb_base + vma->node.start;
> + info->fix.smem_len = vma->node.size;
>  
> - info->screen_base =
> - ioremap_wc(ggtt->mappable_base + i915_gem_obj_ggtt_offset(obj),
> -size);
> - if (!info->screen_base) {
> + vaddr = i915_vma_pin_iomap(vma);
> + if (IS_ERR(vaddr)) {
>   DRM_ERROR("Failed to remap framebuffer into virtual memory\n");
> - ret = -ENOSPC;
> + ret = PTR_ERR(vaddr);
>   goto out_destroy_fbi;
>   }
> - info->screen_size = size;
> + info->screen_base = vaddr;
> + info->screen_size = vma->node.size;

some framebuffer drivers tend to use a generic start address of
iinfo->fix.smem_start and a length of info->fix.smem_len, this
driver sets the smem_start above, but its different than what
gets ioremap for a start address:

+   ptr = io_mapping_map_wc(i915_vm_to_ggtt(vma->vm)->mappable,
+   vma->node.start,
+   vma->node.size);

fix.smem_start is :


> + info->fix.smem_start = dev->mode_config.fb_base + vma->node.start;

The smem_len matches though. Can you clarify if its correct for
the io_mapping_map_wc() should not be using info->fix.smem_start
(which is dev->mode_config.fb_base + vma->node.start)?

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
for their ioremap'd areas it might make sense instead to let the
internal framebuffer (register_framebuffer()) optionally manage the
ioremap_wc() for drivers, given that this is pretty generic stuff.

  Luis

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

[Luis R. Rodriguez]

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
> needing io.h for access to helpers.
> 
> Cc: Toshi Kani 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Will Deacon 
> Cc: Thierry Reding 
> Cc: Andrew Morton 
> Cc: Dave Hansen 
> Cc: Greg Kroah-Hartman 
> Cc: Catalin Marinas 
> Cc: Abhilash Kesavan 
> Cc: Matthias Brugger 
> Cc: Cristian Stoica 
> Cc: dri-devel at lists.freedesktop.org
> Cc: Suresh Siddha 
> Cc: Linus Torvalds 
> Cc: Juergen Gross 
> Cc: Daniel Vetter 
> Cc: Andy Lutomirski 
> Cc: Dave Airlie 
> Cc: Antonino Daplas 
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: Tomi Valkeinen 
> Cc: Ville Syrjälä 
> Cc: Mel Gorman 
> Cc: Vlastimil Babka 
> Cc: Borislav Petkov 
> Cc: Davidlohr Bueso 
> Cc: x86 at kernel.org
> Cc: linux-fbdev at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Luis R. Rodriguez 
> ---
>  arch/x86/include/asm/io.h   |  3 +++
>  arch/x86/include/asm/mtrr.h |  5 -
>  arch/x86/kernel/cpu/mtrr/main.c |  6 +++---
>  drivers/gpu/drm/drm_ioctl.c | 14 +-
>  include/linux/io.h  |  6 ++
>  5 files changed, 13 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index 4afc05f..a2b9740 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -339,6 +339,9 @@ extern bool xen_biovec_phys_mergeable(const struct 
> bio_vec *vec1,
>  #define IO_SPACE_LIMIT 0x
>  
>  #ifdef CONFIG_MTRR
> +extern int __must_check arch_phys_wc_index(int handle);
> +#define arch_phys_wc_index arch_phys_wc_index
> +
>  extern int __must_check arch_phys_wc_add(unsigned long base,
>unsigned long size);
>  extern void arch_phys_wc_del(int handle);
> diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
> index da8dff1..27e3dc0 100644
> --- a/arch/x86/include/asm/mtrr.h
> +++ b/arch/x86/include/asm/mtrr.h
> @@ -48,7 +48,6 @@ extern void mtrr_aps_init(void);
>  extern void mtrr_bp_restore(void);
>  extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
>  extern int amd_special_default_mtrr(void);
> -extern int phys_wc_to_mtrr_index(int handle);
>  #  else
>  static inline u8 mtrr_type_lookup(u64 addr, u64 end, u8 *uniform)
>  {
> @@ -85,10 +84,6 @@ static inline int mtrr_trim_uncached_memory(unsigned long 
> end_pfn)
>  static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
>  {
>  }
> -static inline int phys_wc_to_mtrr_index(int handle)
> -{
> - return -1;
> -}
>  
>  #define mtrr_ap_init() do {} while (0)
>  #define mtrr_bp_init() do {} while (0)
> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> index 12abdbe..d8c106c 100644
> --- a/arch/x86/kernel/cpu/mtrr/main.c
> +++ b/arch/x86/kernel/cpu/mtrr/main.c
> @@ -580,7 +580,7 @@ void arch_phys_wc_del(int handle)
>  EXPORT_SYMBOL(arch_phys_wc_del);
>  
>  /*
> - * phys_wc_to_mtrr_index - translates arch_phys_wc_add's return value
> + * arch_phys_wc_index - translates arch_phys_wc_add's return value
>   * @handle: Return value from arch_phys_wc_add
>   *
>   * This will turn the return value from arch_phys_wc_add into an mtrr
> @@ -590,14 +590,14 @@ EXPORT_SYMBOL(arch_phys_wc_del);
>   * in printk line.  Alas there is an illegitimate use in some ancient
>   * drm ioctls.
>   */
> -int phys_wc_to_mtrr_index(int handle)
> +int arch_phys_wc_index(int handle)
>  {
>   if (handle < MTRR_TO_PHYS_WC_OFFSET)
>   return -1;
>   else
>   return handle - MTRR_TO_PHYS_WC_OFFSET;
>  }
> -EXPORT_SYMBOL_GPL(phys_wc_to_mtrr_index);
> +EXPORT_SYMBOL_GPL(arch_phys_wc_index);
>  
>  /*
>   * HACK ALERT!
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 266dcd6..0a95782 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -36,9 +36,6 @@
>  
>  #include 
>  #include 
> -#ifdef CONFIG_X86
> -#include 
> -#endif
>  
>  static int drm_version(struct drm_device *dev, void *data,
>  struct drm_file *file_priv);
> @@ -197,16 +194,7 @@ static int drm_getmap(struct drm_device *dev, void *data,
>   map->type = r_list->map->type;
>   map->flags = r_list->map->flags;
>   map->handle = (void *)(unsigned long) r_list->user_token;
> -
> -#ifdef C

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

[Luis R. Rodriguez]

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: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Will Deacon 
Cc: Thierry Reding 
Cc: Andrew Morton 
Cc: Dave Hansen 
Cc: Greg Kroah-Hartman 
Cc: Catalin Marinas 
Cc: Abhilash Kesavan 
Cc: Matthias Brugger 
Cc: Cristian Stoica 
Cc: dri-devel at lists.freedesktop.org
Cc: Suresh Siddha 
Cc: Linus Torvalds 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: Ville Syrjälä 
Cc: Mel Gorman 
Cc: Vlastimil Babka 
Cc: Borislav Petkov 
Cc: Davidlohr Bueso 
Cc: x86 at kernel.org
Cc: linux-fbdev at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---

This v4 adds a missing #endif.

 arch/x86/include/asm/io.h   |  3 +++
 arch/x86/include/asm/mtrr.h |  5 -
 arch/x86/kernel/cpu/mtrr/main.c |  6 +++---
 drivers/gpu/drm/drm_ioctl.c | 14 +-
 include/linux/io.h  |  7 +++
 5 files changed, 14 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 4afc05f..a2b9740 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -339,6 +339,9 @@ extern bool xen_biovec_phys_mergeable(const struct bio_vec 
*vec1,
 #define IO_SPACE_LIMIT 0x

 #ifdef CONFIG_MTRR
+extern int __must_check arch_phys_wc_index(int handle);
+#define arch_phys_wc_index arch_phys_wc_index
+
 extern int __must_check arch_phys_wc_add(unsigned long base,
 unsigned long size);
 extern void arch_phys_wc_del(int handle);
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index da8dff1..27e3dc0 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -48,7 +48,6 @@ extern void mtrr_aps_init(void);
 extern void mtrr_bp_restore(void);
 extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
 extern int amd_special_default_mtrr(void);
-extern int phys_wc_to_mtrr_index(int handle);
 #  else
 static inline u8 mtrr_type_lookup(u64 addr, u64 end, u8 *uniform)
 {
@@ -85,10 +84,6 @@ static inline int mtrr_trim_uncached_memory(unsigned long 
end_pfn)
 static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
 {
 }
-static inline int phys_wc_to_mtrr_index(int handle)
-{
-   return -1;
-}

 #define mtrr_ap_init() do {} while (0)
 #define mtrr_bp_init() do {} while (0)
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 12abdbe..d8c106c 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -580,7 +580,7 @@ void arch_phys_wc_del(int handle)
 EXPORT_SYMBOL(arch_phys_wc_del);

 /*
- * phys_wc_to_mtrr_index - translates arch_phys_wc_add's return value
+ * arch_phys_wc_index - translates arch_phys_wc_add's return value
  * @handle: Return value from arch_phys_wc_add
  *
  * This will turn the return value from arch_phys_wc_add into an mtrr
@@ -590,14 +590,14 @@ EXPORT_SYMBOL(arch_phys_wc_del);
  * in printk line.  Alas there is an illegitimate use in some ancient
  * drm ioctls.
  */
-int phys_wc_to_mtrr_index(int handle)
+int arch_phys_wc_index(int handle)
 {
if (handle < MTRR_TO_PHYS_WC_OFFSET)
return -1;
else
return handle - MTRR_TO_PHYS_WC_OFFSET;
 }
-EXPORT_SYMBOL_GPL(phys_wc_to_mtrr_index);
+EXPORT_SYMBOL_GPL(arch_phys_wc_index);

 /*
  * HACK ALERT!
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 266dcd6..0a95782 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -36,9 +36,6 @@

 #include 
 #include 
-#ifdef CONFIG_X86
-#include 
-#endif

 static int drm_version(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
@@ -197,16 +194,7 @@ static int drm_getmap(struct drm_device *dev, void *data,
map->type = r_list->map->type;
map->flags = r_list->map->flags;
map->handle = (void *)(unsigned long) r_list->user_token;
-
-#ifdef CONFIG_X86
-   /*
-* There appears to be exactly one user of the mtrr index: dritest.
-* It's easy enough to keep it working on non-PAT systems.
-*/
-   map->mtrr = phys_wc_to_mtrr_index(r_list->map->mtrr);
-#else
-   map->mtrr = -1;
-#endif
+   map->mtrr = arch_phys_wc_index(r_list->map->mtrr);

mutex_unlock(>struct_mutex);

diff --git a/include/linux/io.h b/include/linux/io.h
index 986f2bf..04cce4d 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -111,6 +111,13 @@ static inline void arch_phys_wc_del(int handle)
 }

 #define arch_phys_wc_add arch_phys_wc_add
+#ifndef arch_phys_wc

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

[Luis R. Rodriguez]

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: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Will Deacon 
Cc: Thierry Reding 
Cc: Andrew Morton 
Cc: Dave Hansen 
Cc: Greg Kroah-Hartman 
Cc: Catalin Marinas 
Cc: Abhilash Kesavan 
Cc: Matthias Brugger 
Cc: Cristian Stoica 
Cc: dri-devel at lists.freedesktop.org
Cc: Suresh Siddha 
Cc: Linus Torvalds 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: Ville Syrjälä 
Cc: Mel Gorman 
Cc: Vlastimil Babka 
Cc: Borislav Petkov 
Cc: Davidlohr Bueso 
Cc: x86 at kernel.org
Cc: linux-fbdev at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---
 arch/x86/include/asm/io.h   |  3 +++
 arch/x86/include/asm/mtrr.h |  5 -
 arch/x86/kernel/cpu/mtrr/main.c |  6 +++---
 drivers/gpu/drm/drm_ioctl.c | 14 +-
 include/linux/io.h  |  6 ++
 5 files changed, 13 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 4afc05f..a2b9740 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -339,6 +339,9 @@ extern bool xen_biovec_phys_mergeable(const struct bio_vec 
*vec1,
 #define IO_SPACE_LIMIT 0x

 #ifdef CONFIG_MTRR
+extern int __must_check arch_phys_wc_index(int handle);
+#define arch_phys_wc_index arch_phys_wc_index
+
 extern int __must_check arch_phys_wc_add(unsigned long base,
 unsigned long size);
 extern void arch_phys_wc_del(int handle);
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index da8dff1..27e3dc0 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -48,7 +48,6 @@ extern void mtrr_aps_init(void);
 extern void mtrr_bp_restore(void);
 extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
 extern int amd_special_default_mtrr(void);
-extern int phys_wc_to_mtrr_index(int handle);
 #  else
 static inline u8 mtrr_type_lookup(u64 addr, u64 end, u8 *uniform)
 {
@@ -85,10 +84,6 @@ static inline int mtrr_trim_uncached_memory(unsigned long 
end_pfn)
 static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
 {
 }
-static inline int phys_wc_to_mtrr_index(int handle)
-{
-   return -1;
-}

 #define mtrr_ap_init() do {} while (0)
 #define mtrr_bp_init() do {} while (0)
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 12abdbe..d8c106c 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -580,7 +580,7 @@ void arch_phys_wc_del(int handle)
 EXPORT_SYMBOL(arch_phys_wc_del);

 /*
- * phys_wc_to_mtrr_index - translates arch_phys_wc_add's return value
+ * arch_phys_wc_index - translates arch_phys_wc_add's return value
  * @handle: Return value from arch_phys_wc_add
  *
  * This will turn the return value from arch_phys_wc_add into an mtrr
@@ -590,14 +590,14 @@ EXPORT_SYMBOL(arch_phys_wc_del);
  * in printk line.  Alas there is an illegitimate use in some ancient
  * drm ioctls.
  */
-int phys_wc_to_mtrr_index(int handle)
+int arch_phys_wc_index(int handle)
 {
if (handle < MTRR_TO_PHYS_WC_OFFSET)
return -1;
else
return handle - MTRR_TO_PHYS_WC_OFFSET;
 }
-EXPORT_SYMBOL_GPL(phys_wc_to_mtrr_index);
+EXPORT_SYMBOL_GPL(arch_phys_wc_index);

 /*
  * HACK ALERT!
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 266dcd6..0a95782 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -36,9 +36,6 @@

 #include 
 #include 
-#ifdef CONFIG_X86
-#include 
-#endif

 static int drm_version(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
@@ -197,16 +194,7 @@ static int drm_getmap(struct drm_device *dev, void *data,
map->type = r_list->map->type;
map->flags = r_list->map->flags;
map->handle = (void *)(unsigned long) r_list->user_token;
-
-#ifdef CONFIG_X86
-   /*
-* There appears to be exactly one user of the mtrr index: dritest.
-* It's easy enough to keep it working on non-PAT systems.
-*/
-   map->mtrr = phys_wc_to_mtrr_index(r_list->map->mtrr);
-#else
-   map->mtrr = -1;
-#endif
+   map->mtrr = arch_phys_wc_index(r_list->map->mtrr);

mutex_unlock(>struct_mutex);

diff --git a/include/linux/io.h b/include/linux/io.h
index 986f2bf..6e29acf 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -111,6 +111,12 @@ static inline void arch_phys_wc_del(int handle)
 }

 #define arch_phys_wc_add arch_phys_wc_add
+#ifndef arch_phys_wc_index
+static inline int arch_p

[PATCH 00/22] Add and use pci_zalloc_consistent

[Luis R. Rodriguez]

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, any chance you can paste in the SmPL? Also any chance
we can get this added to a make coccicheck so that maintainers
moving forward can use that to ensure that no new code is
added that uses the old school API?

  Luis

[PATCH 08/14] backports: backport ww_mutex support

[Luis R. Rodriguez]

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 availabe
if you to have DEBUG_MUTEXES and DEBUG_LOCK_ALLOC disabled.

Given that ww mutex is required for DRM this also means we must
update the kconfig for DRM and require you to also not be able to build
DRM if you have either of these options enabled. Support for
DEBUG_MUTEXES and DEBUG_LOCK_ALLOC can be added later by anyone
daring. This uses the new dependencies file kconfig language
extension to specify the backport feature build restrictions
for DRM.

Part of the ww mutex addition to the kernel required modifying
the fast path mutex locking scheme by requiring you to deal
with the slow path alternatives on your own (refer to a41b56ef).
The reason for this change was that the mutex fastpath implementation
assumed your slowpath alternative can only be passed one argument
and the addition of ww mutexes requires dealing with the slow
path with a context passed.

It'd be painful to backport all asm for an optimized fastpath
implementation so we penalize the backport ww mutex fast path
by using the generic atomic_dec_return().

To backport a clean our own mutex_lock_common() with the least
amount of changes against upstream commits 2bd2c92c and 41fcb9f2
also needed to be backported. Commit 2bd2c92c dealt with adding
support for queue mutex spinners with an MCS lock, since this
cannot be backported for older kernels we provide empty inlines.
Commit 41fcb9f2 just removed SCHED_FEAT_OWNER_SPIN as it was an
early hack, the only thing required to backport this commit was
to provide an alternative declaration for mutex_spin_on_owner()
as it was declared non-inline for older kernels.

Finally c5491ea7 required backporting schedule_preempt_disabled()
as well but that just consisted of carrying over the original
implementation. Since its not exported we need to reimplement
it to make it available to our internal core ww mutex port.

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains 040a0a371
v3.11-rc1~147^2~5

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains a41b56ef
v3.11-rc1~147^2~6

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains 2bd2c92c
v3.10-rc1~200^2~3

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains 41fcb9f2
v3.10-rc1~200^2~5

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains c5491ea7
v3.4-rc1~3^2~27

commit 040a0a37100563754bb1fee6ff6427420bcfa609
Author: Maarten Lankhorst 
Date:   Mon Jun 24 10:30:04 2013 +0200

mutex: Add support for wound/wait style locks

Wound/wait mutexes are used when other multiple lock
acquisitions of a similar type can be done in an arbitrary
order. The deadlock handling used here is called wait/wound in
the RDBMS literature: The older tasks waits until it can acquire
the contended lock. The younger tasks needs to back off and drop
all the locks it is currently holding, i.e. the younger task is
wounded.

For full documentation please read Documentation/ww-mutex-design.txt.

References: https://lwn.net/Articles/548909/
Signed-off-by: Maarten Lankhorst 
Acked-by: Daniel Vetter 
Acked-by: Rob Clark 
Acked-by: Peter Zijlstra 
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Cc: rostedt at goodmis.org
Cc: daniel at ffwll.ch
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/51C8038C.9000106 at canonical.com
Signed-off-by: Ingo Molnar 

commit a41b56efa70e060f650aeb54740aaf52044a1ead
Author: Maarten Lankhorst 
Date:   Thu Jun 20 13:31:05 2013 +0200

arch: Make __mutex_fastpath_lock_retval return whether fastpath succeeded 
or not

This will allow me to call functions that have multiple
arguments if fastpath fails. This is required to support ticket
mutexes, because they need to be able to pass an extra argument
to the fail function.

Originally I duplicated the functions, by adding
__mutex_fastpath_lock_retval_arg. This ended up being just a
duplication of the existing function, so a way to test if
fastpath was called ended up being better.

This also cleaned up the reservation mutex patch some by being
able to call an atomic_set instead of atomic_xchg, and making it
easier to detect if the wrong unlock function was previously
used.

Signed-off-by: Maarten Lankhorst 
Acked-by: Peter Zijlstra 
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Cc: robclark at gmail.com
Cc: rostedt at goodmis.org
Cc: daniel at ffwll.ch
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Thomas Gleixner 
Link: http://l

[PATCH 08/14] backports: backport ww_mutex support

[Luis R. Rodriguez]

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 availabe
if you to have DEBUG_MUTEXES and DEBUG_LOCK_ALLOC disabled.

Given that ww mutex is required for DRM this also means we must
update the kconfig for DRM and require you to also not be able to build
DRM if you have either of these options enabled. Support for
DEBUG_MUTEXES and DEBUG_LOCK_ALLOC can be added later by anyone
daring. This uses the new dependencies file kconfig language
extension to specify the backport feature build restrictions
for DRM.

Part of the ww mutex addition to the kernel required modifying
the fast path mutex locking scheme by requiring you to deal
with the slow path alternatives on your own (refer to a41b56ef).
The reason for this change was that the mutex fastpath implementation
assumed your slowpath alternative can only be passed one argument
and the addition of ww mutexes requires dealing with the slow
path with a context passed.

It'd be painful to backport all asm for an optimized fastpath
implementation so we penalize the backport ww mutex fast path
by using the generic atomic_dec_return().

To backport a clean our own mutex_lock_common() with the least
amount of changes against upstream commits 2bd2c92c and 41fcb9f2
also needed to be backported. Commit 2bd2c92c dealt with adding
support for queue mutex spinners with an MCS lock, since this
cannot be backported for older kernels we provide empty inlines.
Commit 41fcb9f2 just removed SCHED_FEAT_OWNER_SPIN as it was an
early hack, the only thing required to backport this commit was
to provide an alternative declaration for mutex_spin_on_owner()
as it was declared non-inline for older kernels.

Finally c5491ea7 required backporting schedule_preempt_disabled()
as well but that just consisted of carrying over the original
implementation. Since its not exported we need to reimplement
it to make it available to our internal core ww mutex port.

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains 040a0a371
v3.11-rc1~147^2~5

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains a41b56ef
v3.11-rc1~147^2~6

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains 2bd2c92c
v3.10-rc1~200^2~3

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains 41fcb9f2
v3.10-rc1~200^2~5

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains c5491ea7
v3.4-rc1~3^2~27

commit 040a0a37100563754bb1fee6ff6427420bcfa609
Author: Maarten Lankhorst maarten.lankho...@canonical.com
Date:   Mon Jun 24 10:30:04 2013 +0200

mutex: Add support for wound/wait style locks

Wound/wait mutexes are used when other multiple lock
acquisitions of a similar type can be done in an arbitrary
order. The deadlock handling used here is called wait/wound in
the RDBMS literature: The older tasks waits until it can acquire
the contended lock. The younger tasks needs to back off and drop
all the locks it is currently holding, i.e. the younger task is
wounded.

For full documentation please read Documentation/ww-mutex-design.txt.

References: https://lwn.net/Articles/548909/
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
Acked-by: Rob Clark robdcl...@gmail.com
Acked-by: Peter Zijlstra a.p.zijls...@chello.nl
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: rost...@goodmis.org
Cc: dan...@ffwll.ch
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Link: http://lkml.kernel.org/r/51c8038c.9000...@canonical.com
Signed-off-by: Ingo Molnar mi...@kernel.org

commit a41b56efa70e060f650aeb54740aaf52044a1ead
Author: Maarten Lankhorst maarten.lankho...@canonical.com
Date:   Thu Jun 20 13:31:05 2013 +0200

arch: Make __mutex_fastpath_lock_retval return whether fastpath succeeded 
or not

This will allow me to call functions that have multiple
arguments if fastpath fails. This is required to support ticket
mutexes, because they need to be able to pass an extra argument
to the fail function.

Originally I duplicated the functions, by adding
__mutex_fastpath_lock_retval_arg. This ended up being just a
duplication of the existing function, so a way to test if
fastpath was called ended up being better.

This also cleaned up the reservation mutex patch some by being
able to call an atomic_set instead of atomic_xchg, and making it
easier to detect if the wrong unlock function was previously
used.

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Acked-by: Peter Zijlstra a.p.zijls...@chello.nl
Cc: dri-devel

[RFC 7/9] backports: backport ww_mutex support

[Luis R. Rodriguez]

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 availabe
if you to have DEBUG_MUTEXES and DEBUG_LOCK_ALLOC disabled. Given
that ww mutex is required for DRM this also means we must update
the kconfig for DRM and require you to also not be able to build
DRM if you have either of these options enabled. Support for
DEBUG_MUTEXES and DEBUG_LOCK_ALLOC can be added later by anyone
daring.

Part of the ww mutex addition to the kernel required modifying
the fast path mutex locking scheme by requiring you to deal
with the slow path alternatives on your own (refer to a41b56ef).
The reason for this change was that the mutex fastpath implementation
assumed your slowpath alternative can only be passed one argument
and the addition of ww mutexes requires dealing with the slow
path with a context passed.

It'd be painful to backport all asm for an optimized fastpath
implementation so we penalize the backport ww mutex fast path
by using the generic atomic_dec_return().

To backport a clean our own mutex_lock_common() with the least
amount of changes against upstream commits 2bd2c92c and 41fcb9f2
also needed to be backported. Commit 2bd2c92c dealt with adding
support for queue mutex spinners with an MCS lock, since this
cannot be backported for older kernels we provide empty inlines.
Commit 41fcb9f2 just removed SCHED_FEAT_OWNER_SPIN as it was an
early hack, the only thing required to backport this commit was
to provide an alternative declaration for mutex_spin_on_owner()
as it was declared non-inline for older kernels.

Finally c5491ea7 required backporting schedule_preempt_disabled()
as well but that just consisted of carrying over the original
implementation. Since its not exported we need to reimplement
it to make it available to our internal core ww mutex port.

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains 040a0a371
v3.11-rc1~147^2~5

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains a41b56ef
v3.11-rc1~147^2~6

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains 2bd2c92c
v3.10-rc1~200^2~3

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains 41fcb9f2
v3.10-rc1~200^2~5

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains c5491ea7
v3.4-rc1~3^2~27

commit 040a0a37100563754bb1fee6ff6427420bcfa609
Author: Maarten Lankhorst maarten.lankho...@canonical.com
Date:   Mon Jun 24 10:30:04 2013 +0200

mutex: Add support for wound/wait style locks

Wound/wait mutexes are used when other multiple lock
acquisitions of a similar type can be done in an arbitrary
order. The deadlock handling used here is called wait/wound in
the RDBMS literature: The older tasks waits until it can acquire
the contended lock. The younger tasks needs to back off and drop
all the locks it is currently holding, i.e. the younger task is
wounded.

For full documentation please read Documentation/ww-mutex-design.txt.

References: https://lwn.net/Articles/548909/
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
Acked-by: Rob Clark robdcl...@gmail.com
Acked-by: Peter Zijlstra a.p.zijls...@chello.nl
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: rost...@goodmis.org
Cc: dan...@ffwll.ch
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Link: http://lkml.kernel.org/r/51c8038c.9000...@canonical.com
Signed-off-by: Ingo Molnar mi...@kernel.org

commit a41b56efa70e060f650aeb54740aaf52044a1ead
Author: Maarten Lankhorst maarten.lankho...@canonical.com
Date:   Thu Jun 20 13:31:05 2013 +0200

arch: Make __mutex_fastpath_lock_retval return whether fastpath succeeded 
or not

This will allow me to call functions that have multiple
arguments if fastpath fails. This is required to support ticket
mutexes, because they need to be able to pass an extra argument
to the fail function.

Originally I duplicated the functions, by adding
__mutex_fastpath_lock_retval_arg. This ended up being just a
duplication of the existing function, so a way to test if
fastpath was called ended up being better.

This also cleaned up the reservation mutex patch some by being
able to call an atomic_set instead of atomic_xchg, and making it
easier to detect if the wrong unlock function was previously
used.

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Acked-by: Peter Zijlstra a.p.zijls...@chello.nl
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: robcl...@gmail.com
Cc: rost...@goodmis.org
Cc

[RFC 7/9] backports: backport ww_mutex support

[Luis R. Rodriguez]

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 availabe
if you to have DEBUG_MUTEXES and DEBUG_LOCK_ALLOC disabled. Given
that ww mutex is required for DRM this also means we must update
the kconfig for DRM and require you to also not be able to build
DRM if you have either of these options enabled. Support for
DEBUG_MUTEXES and DEBUG_LOCK_ALLOC can be added later by anyone
daring.

Part of the ww mutex addition to the kernel required modifying
the fast path mutex locking scheme by requiring you to deal
with the slow path alternatives on your own (refer to a41b56ef).
The reason for this change was that the mutex fastpath implementation
assumed your slowpath alternative can only be passed one argument
and the addition of ww mutexes requires dealing with the slow
path with a context passed.

It'd be painful to backport all asm for an optimized fastpath
implementation so we penalize the backport ww mutex fast path
by using the generic atomic_dec_return().

To backport a clean our own mutex_lock_common() with the least
amount of changes against upstream commits 2bd2c92c and 41fcb9f2
also needed to be backported. Commit 2bd2c92c dealt with adding
support for queue mutex spinners with an MCS lock, since this
cannot be backported for older kernels we provide empty inlines.
Commit 41fcb9f2 just removed SCHED_FEAT_OWNER_SPIN as it was an
early hack, the only thing required to backport this commit was
to provide an alternative declaration for mutex_spin_on_owner()
as it was declared non-inline for older kernels.

Finally c5491ea7 required backporting schedule_preempt_disabled()
as well but that just consisted of carrying over the original
implementation. Since its not exported we need to reimplement
it to make it available to our internal core ww mutex port.

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains 040a0a371
v3.11-rc1~147^2~5

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains a41b56ef
v3.11-rc1~147^2~6

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains 2bd2c92c
v3.10-rc1~200^2~3

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains 41fcb9f2
v3.10-rc1~200^2~5

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains c5491ea7
v3.4-rc1~3^2~27

commit 040a0a37100563754bb1fee6ff6427420bcfa609
Author: Maarten Lankhorst 
Date:   Mon Jun 24 10:30:04 2013 +0200

mutex: Add support for wound/wait style locks

Wound/wait mutexes are used when other multiple lock
acquisitions of a similar type can be done in an arbitrary
order. The deadlock handling used here is called wait/wound in
the RDBMS literature: The older tasks waits until it can acquire
the contended lock. The younger tasks needs to back off and drop
all the locks it is currently holding, i.e. the younger task is
wounded.

For full documentation please read Documentation/ww-mutex-design.txt.

References: https://lwn.net/Articles/548909/
Signed-off-by: Maarten Lankhorst 
Acked-by: Daniel Vetter 
Acked-by: Rob Clark 
Acked-by: Peter Zijlstra 
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Cc: rostedt at goodmis.org
Cc: daniel at ffwll.ch
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/51C8038C.9000106 at canonical.com
Signed-off-by: Ingo Molnar 

commit a41b56efa70e060f650aeb54740aaf52044a1ead
Author: Maarten Lankhorst 
Date:   Thu Jun 20 13:31:05 2013 +0200

arch: Make __mutex_fastpath_lock_retval return whether fastpath succeeded 
or not

This will allow me to call functions that have multiple
arguments if fastpath fails. This is required to support ticket
mutexes, because they need to be able to pass an extra argument
to the fail function.

Originally I duplicated the functions, by adding
__mutex_fastpath_lock_retval_arg. This ended up being just a
duplication of the existing function, so a way to test if
fastpath was called ended up being better.

This also cleaned up the reservation mutex patch some by being
able to call an atomic_set instead of atomic_xchg, and making it
easier to detect if the wrong unlock function was previously
used.

Signed-off-by: Maarten Lankhorst 
Acked-by: Peter Zijlstra 
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Cc: robclark at gmail.com
Cc: rostedt at goodmis.org
Cc: daniel at ffwll.ch
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20130620113105.4001.83929.stgit at patser
Signed-off-by: Ingo Molnar 

commit 2bd2c92cf07cc4a373bf316c

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

[Luis R. Rodriguez]

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 may be a way to get SmPL to do this for us...

 @@
 type of info  *info;
 @@

 -  info-skip_vt_switch = true;
 +  fb_enable_skip_vt_switch(info);

 for whatever the type of info is.

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 there would be a similar rule for the false case?

Nope, see that's the proactive strategy taken by the static inline and
hence the patch. compat would have a static inline for both cases, and
for the false case it'd be a no-op. If accepted upstream though then
we would not need any changes for this collateral evolution. However
*spotting* these collateral evolutions and giving you SmPL for them as
a proactive strategy might be good given that if these type of patches
are indeed welcomed upstream we'd then be able to address these as
secondary steps. If they are not accepted then indeed we'd use them to
backport that collateral evolution through both compat (adds the
static inlines) and compat-drivers (the SmPL).

  Luis
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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 there would be a similar rule for the false case?

 Nope, see that's the proactive strategy taken by the static inline and
 hence the patch. compat would have a static inline for both cases, and
 for the false case it'd be a no-op. If accepted upstream though then
 we would not need any changes for this collateral evolution. However
 *spotting* these collateral evolutions and giving you SmPL for them as
 a proactive strategy might be good given that if these type of patches
 are indeed welcomed upstream we'd then be able to address these as
 secondary steps. If they are not accepted then indeed we'd use them to
 backport that collateral evolution through both compat (adds the
 static inlines) and compat-drivers (the SmPL).

 Probably I am missing something, since I haven't looked at the code in
 detail, bu wouldn't it be nicer to have a function call for the false
 case, if there is a function call for the true case?

Yes, and indeed we have that, its the same function call, in the
negative case its a no-op, in the newer kernels it wraps to modifying
the element as in the original code.

 In looking at the
 code, one could wonder why things are not done in a parallel way.

Not sure I get this.

  Luis
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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 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 there would be a similar rule for the false case?
 
  Nope, see that's the proactive strategy taken by the static inline and
  hence the patch. compat would have a static inline for both cases, and
  for the false case it'd be a no-op. If accepted upstream though then
  we would not need any changes for this collateral evolution. However
  *spotting* these collateral evolutions and giving you SmPL for them as
  a proactive strategy might be good given that if these type of patches
  are indeed welcomed upstream we'd then be able to address these as
  secondary steps. If they are not accepted then indeed we'd use them to
  backport that collateral evolution through both compat (adds the
  static inlines) and compat-drivers (the SmPL).
 
  Probably I am missing something, since I haven't looked at the code in
  detail, bu wouldn't it be nicer to have a function call for the false
  case, if there is a function call for the true case?

 Yes, and indeed we have that, its the same function call, in the
 negative case its a no-op, in the newer kernels it wraps to modifying
 the element as in the original code.

  In looking at the
  code, one could wonder why things are not done in a parallel way.

 Not sure I get this.

 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 what you mean! I thought about this -- and yes I
decided to not add a bool false setting for the structure field given
that the assumption is this would not be something dynamic, and data
structure would be kzalloc()'d so by default they are 0.

  Luis
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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 get what you mean! I thought about this -- and yes I
 decided to not add a bool false setting for the structure field given
 that the assumption is this would not be something dynamic, and data
 structure would be kzalloc()'d so by default they are 0.

 What do you do about the test, though?

Return the value.

  Luis
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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 what you mean! I thought about this -- and yes I
>> decided to not add a bool false setting for the structure field given
>> that the assumption is this would not be something dynamic, and data
>> structure would be kzalloc()'d so by default they are 0.
>
> What do you do about the test, though?

Return the value.

  Luis

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

[Luis R. Rodriguez]

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 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 there would be a similar rule for the false case?
>> >>
>> >> Nope, see that's the proactive strategy taken by the static inline and
>> >> hence the patch. compat would have a static inline for both cases, and
>> >> for the false case it'd be a no-op. If accepted upstream though then
>> >> we would not need any changes for this collateral evolution. However
>> >> *spotting* these collateral evolutions and giving you SmPL for them as
>> >> a proactive strategy might be good given that if these type of patches
>> >> are indeed welcomed upstream we'd then be able to address these as
>> >> secondary steps. If they are not accepted then indeed we'd use them to
>> >> backport that collateral evolution through both compat (adds the
>> >> static inlines) and compat-drivers (the SmPL).
>> >
>> > Probably I am missing something, since I haven't looked at the code in
>> > detail, bu wouldn't it be nicer to have a function call for the false
>> > case, if there is a function call for the true case?
>>
>> Yes, and indeed we have that, its the same function call, in the
>> negative case its a no-op, in the newer kernels it wraps to modifying
>> the element as in the original code.
>>
>> > In looking at the
>> > code, one could wonder why things are not done in a parallel way.
>>
>> Not sure I get this.
>
> 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 what you mean! I thought about this -- and yes I
decided to not add a bool false setting for the structure field given
that the assumption is this would not be something dynamic, and data
structure would be kzalloc()'d so by default they are 0.

  Luis

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

[Luis R. Rodriguez]

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 all!
>>
>> > Then I guess there would be a similar rule for the false case?
>>
>> Nope, see that's the proactive strategy taken by the static inline and
>> hence the patch. compat would have a static inline for both cases, and
>> for the false case it'd be a no-op. If accepted upstream though then
>> we would not need any changes for this collateral evolution. However
>> *spotting* these collateral evolutions and giving you SmPL for them as
>> a proactive strategy might be good given that if these type of patches
>> are indeed welcomed upstream we'd then be able to address these as
>> secondary steps. If they are not accepted then indeed we'd use them to
>> backport that collateral evolution through both compat (adds the
>> static inlines) and compat-drivers (the SmPL).
>
> Probably I am missing something, since I haven't looked at the code in
> detail, bu wouldn't it be nicer to have a function call for the false
> case, if there is a function call for the true case?

Yes, and indeed we have that, its the same function call, in the
negative case its a no-op, in the newer kernels it wraps to modifying
the element as in the original code.

> In looking at the
> code, one could wonder why things are not done in a parallel way.

Not sure I get this.

  Luis

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

[Luis R. Rodriguez]

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 be a way to get SmPL to do this for us...
>
> @@
> type of info  *info;
> @@
>
> -  info->skip_vt_switch = true;
> +  fb_enable_skip_vt_switch(info);
>
> for whatever the type of info is.

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 there would be a similar rule for the false case?

Nope, see that's the proactive strategy taken by the static inline and
hence the patch. compat would have a static inline for both cases, and
for the false case it'd be a no-op. If accepted upstream though then
we would not need any changes for this collateral evolution. However
*spotting* these collateral evolutions and giving you SmPL for them as
a proactive strategy might be good given that if these type of patches
are indeed welcomed upstream we'd then be able to address these as
secondary steps. If they are not accepted then indeed we'd use them to
backport that collateral evolution through both compat (adds the
static inlines) and compat-drivers (the SmPL).

  Luis

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

[Luis R. Rodriguez]

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 this feature to be backported with 0 delta
   required on the upstream drivers, we'd just require
   the static inline to do a no-op.

1) may be worth while considering, 2) is a new consideration
I'm trying to get others to evaluate to help with automatically
backporting the Linux kernel. This is the first time I am
aware someone argues for it.

Cc: cocci at systeme.lip6.fr
Cc: backports at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Julia Lawall 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Rafael J. Wysocki 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/gpu/drm/i915/intel_fb.c |2 +-
 drivers/video/fbmem.c   |2 +-
 include/linux/fb.h  |   10 ++
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 8d81c929..c0f306c 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -151,7 +151,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
info->screen_size = size;

/* This driver doesn't need a VT switch to restore the mode on resume */
-   info->skip_vt_switch = true;
+   fb_enable_skip_vt_switch(info);

drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
drm_fb_helper_fill_var(info, >helper, sizes->fb_width, 
sizes->fb_height);
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index ccd44b0..daffadc 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1645,7 +1645,7 @@ static int do_register_framebuffer(struct fb_info 
*fb_info)
if (!fb_info->modelist.prev || !fb_info->modelist.next)
INIT_LIST_HEAD(_info->modelist);

-   if (fb_info->skip_vt_switch)
+   if (fb_skip_vt_switch_isset(fb_info))
pm_vt_switch_required(fb_info->dev, false);
else
pm_vt_switch_required(fb_info->dev, true);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index d49c60f..d534966 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -505,6 +505,16 @@ struct fb_info {
bool skip_vt_switch; /* no VT switch on suspend/resume required */
 };

+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+   info->skip_vt_switch = true;
+}
+
+static inline bool fb_skip_vt_switch_isset(struct fb_info *info)
+{
+   return info->skip_vt_switch;
+}
+
 static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
struct apertures_struct *a = kzalloc(sizeof(struct apertures_struct)
+ max_num * sizeof(struct aperture), GFP_KERNEL);
-- 
1.7.10.4

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

[Luis R. Rodriguez]

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 rid of all these static inline replacements for
this data structure element CE.

Cc: cocci at systeme.lip6.fr
Cc: backports at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Julia Lawall 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Rafael J. Wysocki 
Signed-off-by: Luis R. Rodriguez 
---
 .../drm/0001-fb-info-vt_switch.patch   |   25 
 1 file changed, 4 insertions(+), 21 deletions(-)

diff --git a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch 
b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
index cdced87..39b13d1 100644
--- a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
+++ b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
@@ -8,23 +8,7 @@ pm_vt_switch_unregister() would not have been made.
 This patch cannot be broken down further so I'm pegging
 this as the first one with 4 digits under the DRM folder
 for collateral evolutions. This reflects its as atomic as
-is possible. As we'll see on the next commit, these type
-of collateral evolutions can best be backported not by
-keeping ifdef's as below but instead by using a wrapper
-caller, to help reduce with the amount of lines of code
-we need. If a static inline is added upstream for these
-changes, then no code is required for backporting, at all,
-we'd just implement the static inline later upstream as
-a no-op.
-
-The tradeoffs to consider for this is if we can live with
-these practices upstream, we may be able to support full
-subsystems only with a compat module, and no need for
-patches. This also means less code and likely less bugs
-on the distribution front when backporting is required.
-At least IMHO this may be worthy to consider at least to
-support kernels listed as supported on kernel.org. We could
-just leave the ifdef hell to older unsupported kernels.
+is possible.

 Relevant commits below, starting with the first one that
 added this new collateral evolution.
@@ -60,14 +44,13 @@ Date:   Tue Mar 26 09:25:45 2013 -0700

 --- a/drivers/gpu/drm/i915/intel_fb.c
 +++ b/drivers/gpu/drm/i915/intel_fb.c
-@@ -150,8 +150,10 @@ static int intelfb_create(struct drm_fb_
+@@ -150,8 +150,8 @@ static int intelfb_create(struct drm_fb_
}
info->screen_size = size;

-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,10,0))
/* This driver doesn't need a VT switch to restore the mode on resume */
-   info->skip_vt_switch = true;
-+#endif
+-  info->skip_vt_switch = true;
++  fb_enable_skip_vt_switch(info);

drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
drm_fb_helper_fill_var(info, >helper, sizes->fb_width, 
sizes->fb_height);
-- 
1.7.10.4

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

[Luis R. Rodriguez]

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
or false depending on this new flag and later
pm_vt_switch_unregister() would not have been made.

compat-drivers was backporting this using #ifdef's but by
integrating a static inline we'd reduce the number of lines
to backport to just 1 line replacement. This would be something
like:

  -   info->skip_vt_switch = true;
  +   fb_enable_skip_vt_switch(info);

For kernels >= 3.10 we'd set the attribute as we do upstream,
for older kernels this would be a no-op.

If this static inline would have been added upstream it would
have meant this collateral evolution would require just adding
a no-op static inline to backport, and no changes as the above
example hunk for every driver that requires the change.

If this static inline ends up upstream *now* it means we do *not*
require the type of hunk above for every driver that requires
the change.

All the code would be left intact !

This is a linux-next 'data structure element collateral evolution'.

Cc: cocci at systeme.lip6.fr
Cc: backports at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Julia Lawall 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Rafael J. Wysocki 
Signed-off-by: Luis R. Rodriguez 
---
 include/linux/compat-3.10.h |   41 +
 1 file changed, 41 insertions(+)

diff --git a/include/linux/compat-3.10.h b/include/linux/compat-3.10.h
index 69ddc11..9abfc4b 100644
--- a/include/linux/compat-3.10.h
+++ b/include/linux/compat-3.10.h
@@ -7,6 +7,7 @@

 #include 
 #include 
+#include 

 #define sg_page_iter_page LINUX_BACKPORT(sg_page_iter_page)
 /**
@@ -29,6 +30,46 @@ static inline dma_addr_t sg_page_iter_dma_address(struct 
sg_page_iter *piter)
return sg_dma_address(piter->sg) + (piter->sg_pgoffset << PAGE_SHIFT);
 }

+/*
+ * This is a linux-next data structure element collateral evolution,
+ * we use a wrapper to avoid #ifdef hell to backport it. This allows
+ * us to use a simple fb_info_skip_vt_switch() replacement for when
+ * the new data structure element is used. If coccinelle SmPL grammar
+ * could be used to express the transformation for us on compat-drivers
+ * it means we'd need to express it only once. If the structure element
+ * collateral evolution were to be used *at development* time and we'd
+ * have a way to express the inverse through SmPL we'd be able to
+ * backport this collateral evolution automatically for any new driver
+ * that used it. We'd use coccinelle to look for it and do the
+ * transformations for us based on the original commit (maybe SmPL
+ * would be listed on the commit log.
+ *
+ * We may need the LINUX_BACKPORT() call that adds the backport_
+ * prefix for older kernels than 3.10 if distros decide to
+ * add this same static inline themselves (although unlikely).
+ */
+#define fb_enable_skip_vt_switch LINUX_BACKPORT(fb_enable_skip_vt_switch)
+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+}
+
+#else /* kernel is >= 3.10 */
+/*
+ * We'd delete this upstream ever got this, we use our
+ * backport_ prefix with LINUX_BACKPORT() so that if this
+ * does get upstream we would not have to add another ifdef
+ * here for the kernels in between v3.10.. up to the point
+ * the routine would have gotten added, we'd just delete this
+ * #else condition completely. If we didn't have this and
+ * say 3.12 added the static inline upstream, we'd have a
+ * clash on the backport for 3.12 as the routine would
+ * already be defined *but* we'd need it for 3.11.
+ */
+#define fb_enable_skip_vt_switch LINUX_BACKPORT(fb_enable_skip_vt_switch)
+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+   info->skip_vt_switch = true;
+}
 #endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(3,10,0)) */

 #endif /* LINUX_3_10_COMPAT_H */
-- 
1.7.10.4

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

[Luis R. Rodriguez]

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
or false depending on this new flag and later
pm_vt_switch_unregister() would not have been made.

This patch cannot be broken down further so I'm pegging
this as the first one with 4 digits under the DRM folder
for collateral evolutions. This reflects its as atomic as
is possible. As we'll see on the next commit, these type
of collateral evolutions can best be backported not by
keeping ifdef's as below but instead by using a wrapper
caller, to help reduce with the amount of lines of code
we need. If a static inline is added upstream for these
changes, then no code is required for backporting, at all,
we'd just implement the static inline later upstream as
a no-op.

The tradeoffs to consider for this is if we can live with
these practices upstream, we may be able to support full
subsystems only with a compat module, and no need for
patches. This also means less code and likely less bugs
on the distribution front when backporting is required.
At least IMHO this may be worthy to consider at least to
support kernels listed as supported on kernel.org. We could
just leave the ifdef hell to older unsupported kernels.

Relevant commits below, starting with the first one that
added this new collateral evolution.

commit 3cf2667b9f8b2c2fe298a427deb399e52321da6b
Author: Jesse Barnes 
Date:   Mon Feb 4 13:37:21 2013 +

fb: add support for drivers not needing VT switch at suspend/resume time

Use the new PM routines to indicate whether we need to VT switch at suspend
and resume time.  When a new driver is bound, set its flag accordingly,
and when unbound, remove it from the PM's console tracking list.

Signed-off-by: Jesse Barnes 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Daniel Vetter 

commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
Author: Jesse Barnes 
Date:   Tue Mar 26 09:25:45 2013 -0700

drm/i915: enable VT switchless resume v3

With the other bits in place, we can do this safely.

v2: disable backlight on suspend to prevent premature enablement on resume
v3: disable CRTCs on suspend to allow RTD3 (Kristen)

Signed-off-by: Jesse Barnes 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Daniel Vetter 

Cc: cocci at systeme.lip6.fr
Cc: backports at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Julia Lawall 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Rafael J. Wysocki 
Signed-off-by: Luis R. Rodriguez 
---
 .../drm/0001-fb-info-vt_switch.patch   |   73 
 1 file changed, 73 insertions(+)
 create mode 100644 
patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch

diff --git a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch 
b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
new file mode 100644
index 000..cdced87
--- /dev/null
+++ b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
@@ -0,0 +1,73 @@
+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 depending on this new flag and later
+pm_vt_switch_unregister() would not have been made.
+
+This patch cannot be broken down further so I'm pegging
+this as the first one with 4 digits under the DRM folder
+for collateral evolutions. This reflects its as atomic as
+is possible. As we'll see on the next commit, these type
+of collateral evolutions can best be backported not by
+keeping ifdef's as below but instead by using a wrapper
+caller, to help reduce with the amount of lines of code
+we need. If a static inline is added upstream for these
+changes, then no code is required for backporting, at all,
+we'd just implement the static inline later upstream as
+a no-op.
+
+The tradeoffs to consider for this is if we can live with
+these practices upstream, we may be able to support full
+subsystems only with a compat module, and no need for
+patches. This also means less code and likely less bugs
+on the distribution front when backporting is required.
+At least IMHO this may be worthy to consider at least to
+support kernels listed as supported on kernel.org. We could
+just leave the ifdef hell to older unsupported kernels.
+
+Relevant commits below, starting with the first one that
+added this new collateral evolution.
+
+commit 3cf2667b9f8b2c2fe298a427deb399e52321da6b
+Author: Jesse Barnes 
+Date:   Mon Feb 4 13:37:21 2013 +
+
+fb: add support for drivers not needing VT switch at suspend/resume time
+
+Use the new PM routines to indicate whether we need to VT s

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

[Luis R. Rodriguez]

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 to help with the automatic juice was
simply quilt refresh to help with hunk offsets, later it consisted of
writing cleaner diffs, then compartamentalizing shared differences into a
compat backport module [2].

Recently I looked into Coccinelle SmPL to help push for collateral evolutions
on the Linux kernel to be written when possible with SmPL [3] given that, as
discussed with Julia, the very inverse of the grammar may allow us to backport
that collateral evolution on older kernels. I'm still experimenting with that,
but another benefit of studying INRIA's Coccinelle work is that the concept
of collateral evolutions is now formalized and as I've studied their work
I'm realizing we have different categories for collateral evolutions. From
what I've experienced through the backport work, data structure changes are
the more difficult collateral evolutions to backport. Instead of updates on
our compat module these require manual diffs... One strategy to simplify
backporting these data structure changes however was to replace the uses of
the new elements on the data structure with static inlines and requiring
the heavy changes to be implementd on a helper. That is, we actually simplfied
the backport by changing the form of the collateral evolution.

The new commit by Jesse that extended the fb_info with a skip_vt_switch
element is the simplest example of a data structure expansion. We'd backport
this by adding a static inline to compat so that new kernels muck with the
new element and for older kernels this would be a no-op. This reduces the
size of the backport and unclutters the required patch with #idefs, and
insteads leaves only a replacement of the usage of the new elements with
a static inline, this however would still be required on our end:

-  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 be a way to get SmPL to do this for us...

However... if the static inline makes it upstream it means 0 changes are
required for *any* driver!

I've been reluctant to request a change upstream because of these side
backport benefits but due to this case's simplcity I figured I'd shoot
this out for review now.

A more elaborate example would be the netdev_attach_ops() which is not
yet upstream. This exands to this simple inline for new kernels:

static inline void netdev_attach_ops(struct net_device *dev,
   const struct net_device_ops *ops)
{   
dev->netdev_ops = ops;  
} 

For older kernels this expands to:

void netdev_attach_ops(struct net_device *dev,  
   const struct net_device_ops *ops)
{   
dev->open = ops->ndo_open;  
dev->init = ops->ndo_init;  
dev->stop = ops->ndo_stop;  
dev->hard_start_xmit = ops->ndo_start_xmit; 
dev->change_rx_flags = ops->ndo_change_rx_flags;
dev->set_multicast_list = ops->ndo_set_multicast_list;  
dev->validate_addr = ops->ndo_validate_addr;
dev->do_ioctl = ops->ndo_do_ioctl;  
dev->set_config = ops->ndo_set_config;  
dev->change_mtu = ops->ndo_change_mtu;  
dev->set_mac_address = ops->ndo_set_mac_address;
dev->tx_timeout = ops->ndo_tx_timeout;  
if (ops->ndo_get_stats) 
dev->get_stats = ops->ndo_get_stats;
dev->vlan_rx_register = ops->ndo_vlan_rx_register;  
dev->vlan_rx_add_vid = ops->ndo_vlan_rx_add_vid;
dev->vlan_rx_kill_vid = ops->ndo_vlan_rx_kill_vid;  
#ifdef CONFIG_NET_POLL_CONTROLLER   
dev->poll_controller = ops->ndo_poll_controller;
#en

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

[Luis R. Rodriguez]

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 to help with the automatic juice was
simply quilt refresh to help with hunk offsets, later it consisted of
writing cleaner diffs, then compartamentalizing shared differences into a
compat backport module [2].

Recently I looked into Coccinelle SmPL to help push for collateral evolutions
on the Linux kernel to be written when possible with SmPL [3] given that, as
discussed with Julia, the very inverse of the grammar may allow us to backport
that collateral evolution on older kernels. I'm still experimenting with that,
but another benefit of studying INRIA's Coccinelle work is that the concept
of collateral evolutions is now formalized and as I've studied their work
I'm realizing we have different categories for collateral evolutions. From
what I've experienced through the backport work, data structure changes are
the more difficult collateral evolutions to backport. Instead of updates on
our compat module these require manual diffs... One strategy to simplify
backporting these data structure changes however was to replace the uses of
the new elements on the data structure with static inlines and requiring
the heavy changes to be implementd on a helper. That is, we actually simplfied
the backport by changing the form of the collateral evolution.

The new commit by Jesse that extended the fb_info with a skip_vt_switch
element is the simplest example of a data structure expansion. We'd backport
this by adding a static inline to compat so that new kernels muck with the
new element and for older kernels this would be a no-op. This reduces the
size of the backport and unclutters the required patch with #idefs, and
insteads leaves only a replacement of the usage of the new elements with
a static inline, this however would still be required on our end:

-  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 be a way to get SmPL to do this for us...

However... if the static inline makes it upstream it means 0 changes are
required for *any* driver!

I've been reluctant to request a change upstream because of these side
backport benefits but due to this case's simplcity I figured I'd shoot
this out for review now.

A more elaborate example would be the netdev_attach_ops() which is not
yet upstream. This exands to this simple inline for new kernels:

static inline void netdev_attach_ops(struct net_device *dev,
   const struct net_device_ops *ops)
{   
dev-netdev_ops = ops;  
} 

For older kernels this expands to:

void netdev_attach_ops(struct net_device *dev,  
   const struct net_device_ops *ops)
{   
dev-open = ops-ndo_open;  
dev-init = ops-ndo_init;  
dev-stop = ops-ndo_stop;  
dev-hard_start_xmit = ops-ndo_start_xmit; 
dev-change_rx_flags = ops-ndo_change_rx_flags;
dev-set_multicast_list = ops-ndo_set_multicast_list;  
dev-validate_addr = ops-ndo_validate_addr;
dev-do_ioctl = ops-ndo_do_ioctl;  
dev-set_config = ops-ndo_set_config;  
dev-change_mtu = ops-ndo_change_mtu;  
dev-set_mac_address = ops-ndo_set_mac_address;
dev-tx_timeout = ops-ndo_tx_timeout;  
if (ops-ndo_get_stats) 
dev-get_stats = ops-ndo_get_stats;
dev-vlan_rx_register = ops-ndo_vlan_rx_register;  
dev-vlan_rx_add_vid = ops-ndo_vlan_rx_add_vid;
dev-vlan_rx_kill_vid = ops-ndo_vlan_rx_kill_vid;  
#ifdef CONFIG_NET_POLL_CONTROLLER   
dev-poll_controller = ops-ndo_poll_controller;
#endif  

#if (LINUX_VERSION_CODE

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

[Luis R. Rodriguez]

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
or false depending on this new flag and later
pm_vt_switch_unregister() would not have been made.

This patch cannot be broken down further so I'm pegging
this as the first one with 4 digits under the DRM folder
for collateral evolutions. This reflects its as atomic as
is possible. As we'll see on the next commit, these type
of collateral evolutions can best be backported not by
keeping ifdef's as below but instead by using a wrapper
caller, to help reduce with the amount of lines of code
we need. If a static inline is added upstream for these
changes, then no code is required for backporting, at all,
we'd just implement the static inline later upstream as
a no-op.

The tradeoffs to consider for this is if we can live with
these practices upstream, we may be able to support full
subsystems only with a compat module, and no need for
patches. This also means less code and likely less bugs
on the distribution front when backporting is required.
At least IMHO this may be worthy to consider at least to
support kernels listed as supported on kernel.org. We could
just leave the ifdef hell to older unsupported kernels.

Relevant commits below, starting with the first one that
added this new collateral evolution.

commit 3cf2667b9f8b2c2fe298a427deb399e52321da6b
Author: Jesse Barnes jbar...@virtuousgeek.org
Date:   Mon Feb 4 13:37:21 2013 +

fb: add support for drivers not needing VT switch at suspend/resume time

Use the new PM routines to indicate whether we need to VT switch at suspend
and resume time.  When a new driver is bound, set its flag accordingly,
and when unbound, remove it from the PM's console tracking list.

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
Author: Jesse Barnes jbar...@virtuousgeek.org
Date:   Tue Mar 26 09:25:45 2013 -0700

drm/i915: enable VT switchless resume v3

With the other bits in place, we can do this safely.

v2: disable backlight on suspend to prevent premature enablement on resume
v3: disable CRTCs on suspend to allow RTD3 (Kristen)

Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Cc: co...@systeme.lip6.fr
Cc: backpo...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Julia Lawall julia.law...@lip6.fr
Cc: Rodrigo Vivi rodrigo.v...@gmail.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
 .../drm/0001-fb-info-vt_switch.patch   |   73 
 1 file changed, 73 insertions(+)
 create mode 100644 
patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch

diff --git a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch 
b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
new file mode 100644
index 000..cdced87
--- /dev/null
+++ b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
@@ -0,0 +1,73 @@
+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 depending on this new flag and later
+pm_vt_switch_unregister() would not have been made.
+
+This patch cannot be broken down further so I'm pegging
+this as the first one with 4 digits under the DRM folder
+for collateral evolutions. This reflects its as atomic as
+is possible. As we'll see on the next commit, these type
+of collateral evolutions can best be backported not by
+keeping ifdef's as below but instead by using a wrapper
+caller, to help reduce with the amount of lines of code
+we need. If a static inline is added upstream for these
+changes, then no code is required for backporting, at all,
+we'd just implement the static inline later upstream as
+a no-op.
+
+The tradeoffs to consider for this is if we can live with
+these practices upstream, we may be able to support full
+subsystems only with a compat module, and no need for
+patches. This also means less code and likely less bugs
+on the distribution front when backporting is required.
+At least IMHO this may be worthy to consider at least to
+support kernels listed as supported on kernel.org. We could
+just leave the ifdef hell to older unsupported kernels.
+
+Relevant commits below, starting with the first one that
+added

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

[Luis R. Rodriguez]

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
or false depending on this new flag and later
pm_vt_switch_unregister() would not have been made.

compat-drivers was backporting this using #ifdef's but by
integrating a static inline we'd reduce the number of lines
to backport to just 1 line replacement. This would be something
like:

  -   info-skip_vt_switch = true;
  +   fb_enable_skip_vt_switch(info);

For kernels = 3.10 we'd set the attribute as we do upstream,
for older kernels this would be a no-op.

If this static inline would have been added upstream it would
have meant this collateral evolution would require just adding
a no-op static inline to backport, and no changes as the above
example hunk for every driver that requires the change.

If this static inline ends up upstream *now* it means we do *not*
require the type of hunk above for every driver that requires
the change.

All the code would be left intact !

This is a linux-next 'data structure element collateral evolution'.

Cc: co...@systeme.lip6.fr
Cc: backpo...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Julia Lawall julia.law...@lip6.fr
Cc: Rodrigo Vivi rodrigo.v...@gmail.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
 include/linux/compat-3.10.h |   41 +
 1 file changed, 41 insertions(+)

diff --git a/include/linux/compat-3.10.h b/include/linux/compat-3.10.h
index 69ddc11..9abfc4b 100644
--- a/include/linux/compat-3.10.h
+++ b/include/linux/compat-3.10.h
@@ -7,6 +7,7 @@
 
 #include linux/scatterlist.h
 #include linux/mm.h
+#include linux/fb.h
 
 #define sg_page_iter_page LINUX_BACKPORT(sg_page_iter_page)
 /**
@@ -29,6 +30,46 @@ static inline dma_addr_t sg_page_iter_dma_address(struct 
sg_page_iter *piter)
return sg_dma_address(piter-sg) + (piter-sg_pgoffset  PAGE_SHIFT);
 }
 
+/*
+ * This is a linux-next data structure element collateral evolution,
+ * we use a wrapper to avoid #ifdef hell to backport it. This allows
+ * us to use a simple fb_info_skip_vt_switch() replacement for when
+ * the new data structure element is used. If coccinelle SmPL grammar
+ * could be used to express the transformation for us on compat-drivers
+ * it means we'd need to express it only once. If the structure element
+ * collateral evolution were to be used *at development* time and we'd
+ * have a way to express the inverse through SmPL we'd be able to
+ * backport this collateral evolution automatically for any new driver
+ * that used it. We'd use coccinelle to look for it and do the
+ * transformations for us based on the original commit (maybe SmPL
+ * would be listed on the commit log.
+ *
+ * We may need the LINUX_BACKPORT() call that adds the backport_
+ * prefix for older kernels than 3.10 if distros decide to
+ * add this same static inline themselves (although unlikely).
+ */
+#define fb_enable_skip_vt_switch LINUX_BACKPORT(fb_enable_skip_vt_switch)
+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+}
+
+#else /* kernel is = 3.10 */
+/*
+ * We'd delete this upstream ever got this, we use our
+ * backport_ prefix with LINUX_BACKPORT() so that if this
+ * does get upstream we would not have to add another ifdef
+ * here for the kernels in between v3.10.. up to the point
+ * the routine would have gotten added, we'd just delete this
+ * #else condition completely. If we didn't have this and
+ * say 3.12 added the static inline upstream, we'd have a
+ * clash on the backport for 3.12 as the routine would
+ * already be defined *but* we'd need it for 3.11.
+ */
+#define fb_enable_skip_vt_switch LINUX_BACKPORT(fb_enable_skip_vt_switch)
+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+   info-skip_vt_switch = true;
+}
 #endif /* (LINUX_VERSION_CODE  KERNEL_VERSION(3,10,0)) */
 
 #endif /* LINUX_3_10_COMPAT_H */
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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 rid of all these static inline replacements for
this data structure element CE.

Cc: co...@systeme.lip6.fr
Cc: backpo...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Julia Lawall julia.law...@lip6.fr
Cc: Rodrigo Vivi rodrigo.v...@gmail.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
 .../drm/0001-fb-info-vt_switch.patch   |   25 
 1 file changed, 4 insertions(+), 21 deletions(-)

diff --git a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch 
b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
index cdced87..39b13d1 100644
--- a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
+++ b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
@@ -8,23 +8,7 @@ pm_vt_switch_unregister() would not have been made.
 This patch cannot be broken down further so I'm pegging
 this as the first one with 4 digits under the DRM folder
 for collateral evolutions. This reflects its as atomic as
-is possible. As we'll see on the next commit, these type
-of collateral evolutions can best be backported not by
-keeping ifdef's as below but instead by using a wrapper
-caller, to help reduce with the amount of lines of code
-we need. If a static inline is added upstream for these
-changes, then no code is required for backporting, at all,
-we'd just implement the static inline later upstream as
-a no-op.
-
-The tradeoffs to consider for this is if we can live with
-these practices upstream, we may be able to support full
-subsystems only with a compat module, and no need for
-patches. This also means less code and likely less bugs
-on the distribution front when backporting is required.
-At least IMHO this may be worthy to consider at least to
-support kernels listed as supported on kernel.org. We could
-just leave the ifdef hell to older unsupported kernels.
+is possible.
 
 Relevant commits below, starting with the first one that
 added this new collateral evolution.
@@ -60,14 +44,13 @@ Date:   Tue Mar 26 09:25:45 2013 -0700
 
 --- a/drivers/gpu/drm/i915/intel_fb.c
 +++ b/drivers/gpu/drm/i915/intel_fb.c
-@@ -150,8 +150,10 @@ static int intelfb_create(struct drm_fb_
+@@ -150,8 +150,8 @@ static int intelfb_create(struct drm_fb_
}
info-screen_size = size;
  
-+#if (LINUX_VERSION_CODE = KERNEL_VERSION(3,10,0))
/* This driver doesn't need a VT switch to restore the mode on resume */
-   info-skip_vt_switch = true;
-+#endif
+-  info-skip_vt_switch = true;
++  fb_enable_skip_vt_switch(info);
  
drm_fb_helper_fill_fix(info, fb-pitches[0], fb-depth);
drm_fb_helper_fill_var(info, ifbdev-helper, sizes-fb_width, 
sizes-fb_height);
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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 this feature to be backported with 0 delta
   required on the upstream drivers, we'd just require
   the static inline to do a no-op.

1) may be worth while considering, 2) is a new consideration
I'm trying to get others to evaluate to help with automatically
backporting the Linux kernel. This is the first time I am
aware someone argues for it.

Cc: co...@systeme.lip6.fr
Cc: backpo...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Julia Lawall julia.law...@lip6.fr
Cc: Rodrigo Vivi rodrigo.v...@gmail.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
 drivers/gpu/drm/i915/intel_fb.c |2 +-
 drivers/video/fbmem.c   |2 +-
 include/linux/fb.h  |   10 ++
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 8d81c929..c0f306c 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -151,7 +151,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
info-screen_size = size;
 
/* This driver doesn't need a VT switch to restore the mode on resume */
-   info-skip_vt_switch = true;
+   fb_enable_skip_vt_switch(info);
 
drm_fb_helper_fill_fix(info, fb-pitches[0], fb-depth);
drm_fb_helper_fill_var(info, ifbdev-helper, sizes-fb_width, 
sizes-fb_height);
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index ccd44b0..daffadc 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1645,7 +1645,7 @@ static int do_register_framebuffer(struct fb_info 
*fb_info)
if (!fb_info-modelist.prev || !fb_info-modelist.next)
INIT_LIST_HEAD(fb_info-modelist);
 
-   if (fb_info-skip_vt_switch)
+   if (fb_skip_vt_switch_isset(fb_info))
pm_vt_switch_required(fb_info-dev, false);
else
pm_vt_switch_required(fb_info-dev, true);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index d49c60f..d534966 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -505,6 +505,16 @@ struct fb_info {
bool skip_vt_switch; /* no VT switch on suspend/resume required */
 };
 
+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+   info-skip_vt_switch = true;
+}
+
+static inline bool fb_skip_vt_switch_isset(struct fb_info *info)
+{
+   return info-skip_vt_switch;
+}
+
 static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
struct apertures_struct *a = kzalloc(sizeof(struct apertures_struct)
+ max_num * sizeof(struct aperture), GFP_KERNEL);
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

compat-drivers based on v3.8.3

[Luis R. Rodriguez]

Greg has blessed Linux v3.8.3 so we get to backport drivers for this
release for usage on older kernels through compat-drivers, you can
either visit the v3.8.3 release page [0] or the temporary release page
[1]. This release has been test compiled against vanilla Linux kernel
releases v2.6.24 - v3.7. Below I provide the ChangeLog for this
release for the changes made to compat and compat-drivers, for the
full ChangeLog that includes Linux kernel changes you can refer to the
upstream full ChangeLog [2].

We have 5 type of releases based on v3.8.3, there is a vanilla release
and then 4 releases which incorporate additional patches from sources
on their way to get upstream to the Linux kernel. The additional
releases are designed to ensure we prioritize Linux upstream
development but at the same time allow OEMs / users / mothers to get
releases with additional patches vendors deem important for
functionality, we simply categorize where those patches are on their
way upstream to the Linux kernel. For more information on this see the
additional-patches documentation on the backports wiki [3].

Thanks to everyone who has contributed to this release!

[0] https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8.3/
[1] http://drvbp1.linux-foundation.org/~mcgrof/rel-html/compat-drivers/
[2] 
https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8.3/ChangeLog-3.8.3-2
[3] 
https://backports.wiki.kernel.org/index.php/Documentation/compat-drivers/additional-patches


ChangeLog for compat-drivers-v3.8.3-2 based on linux-3.8.3


This is the ChangeLog for the Linux kernel project compat-drivers.
It provides a backport of a few Linux kernel subsystems down to
older kernels:

  * 802.11
  * Bluetooth
  * Ethernet
  * DRM

For more details refer to the home pages:

https://backports.wiki.kernel.org

The compat-drivers project consists of code from three projects:

  * The Linux kernel: linux-stable.git
  * Compat-wirelesS: compat-drivers.git
  * Compat: compat.git

The compat-drivers stable releases incorporates code from from
each of these git trees for the respective upstream Linux kernel
stable release. A branch called linux-3.x.y exists for each
stable release. Below we provide the ChangeLog of changes from
the previous branched release to the new branched release.

Release: linux-3.8


Updates from the compat.git project:


git shortlog linux-3.7.y..linux-3.8.y

Felix Fietkau (1):
  compat: fix compile errors when assembly is built into modules

Hauke Mehrtens (21):
  compat: update list of kernel headers
  compat: add USB_SUBCLASS_VENDOR_SPEC
  compat: make compat load without CONFIG_CPU_FREQ
  compat: add eth_zero_addr()
  compat: add kref_get_unless_zero()
  compat: move config_enabled to compat-3.4.h
  compat: fix compiler warning in nla_get_s64()
  compat: export platform_device_register_data()
  compat: fix warning of missing struct netdev_queue
  compat: add missing return value to netif_set_real_num_tx_queues
  compat: add simple_write_to_buffer
  compat: add ETHTOOL_FWVERS_LEN
  compat: fix warning in usb_autopm_get_interface_no_{resume,suspend}
  compat: do not access default_ethtool_ops
  compat: ckmake: make return code 2 is error
  compat: ckmake: remove lots of warning spam for the log
  compat: ckmake: do not start all build at the same time
  compat: add efi_enabled()
  compat: netdev_set_default_ethtool_ops() is not in kernel 3.7.5
  compat: check if efi_enabled() was already backported
  compat: deactivate netdev_set_default_ethtool_ops() for some 3.7 kernels

Johannes Berg (1):
  compat: backport unsigned netlink attribute accessors

Luis R. Rodriguez (42):
  compat: fix libc dependency on bin/get-compat-kernels
  compat: fix typo in bin/get-compat-kernels
  compat: run ckmake with num cpu threads
  compat: fix get-compat-kernels for libc issue again
  compat: change count to 4 for glibc kernel fix
  compat: add gpio header for kernels older than 2.6.24
  compat: backport ethtool_rxfh_indir_default()
  compat: backport ethtool to mii advertisment conversion helpers
  compat: backport BQL helpers
  compat: define NETIF_F_RXCSUM
  compat: fix addition of NETIF_F_RXCSUM
  compat: backport PCI MSI-X entry definitions
  compat: backport alloc_etherdev_mqs()
  compat: backport definition of PCI_MSIX_ENTRY_CTRL_MASKBIT
  compat: backport PTR_RET()
  compat: backport netif_set_real_num_tx_queues()
  compat: backport netif_set_real_num_rx_queues()
  compat: rename MDIO exported symbols
  compat: backplane mode negotiation ethtool definitions
  compat: backport napi_gro_receive()
  compat: generate CONFIG_COMPAT_KERNEL_3_8
  compat: backport

compat-drivers based on v3.8.3

[Luis R. Rodriguez]

Greg has blessed Linux v3.8.3 so we get to backport drivers for this
release for usage on older kernels through compat-drivers, you can
either visit the v3.8.3 release page [0] or the temporary release page
[1]. This release has been test compiled against vanilla Linux kernel
releases v2.6.24 - v3.7. Below I provide the ChangeLog for this
release for the changes made to compat and compat-drivers, for the
full ChangeLog that includes Linux kernel changes you can refer to the
upstream full ChangeLog [2].

We have 5 type of releases based on v3.8.3, there is a vanilla release
and then 4 releases which incorporate additional patches from sources
on their way to get upstream to the Linux kernel. The additional
releases are designed to ensure we prioritize Linux upstream
development but at the same time allow OEMs / users / mothers to get
releases with additional patches vendors deem important for
functionality, we simply categorize where those patches are on their
way upstream to the Linux kernel. For more information on this see the
additional-patches documentation on the backports wiki [3].

Thanks to everyone who has contributed to this release!

[0] https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8.3/
[1] http://drvbp1.linux-foundation.org/~mcgrof/rel-html/compat-drivers/
[2] 
https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8.3/ChangeLog-3.8.3-2
[3] 
https://backports.wiki.kernel.org/index.php/Documentation/compat-drivers/additional-patches


ChangeLog for compat-drivers-v3.8.3-2 based on linux-3.8.3


This is the ChangeLog for the Linux kernel project compat-drivers.
It provides a backport of a few Linux kernel subsystems down to
older kernels:

  * 802.11
  * Bluetooth
  * Ethernet
  * DRM

For more details refer to the home pages:

https://backports.wiki.kernel.org

The compat-drivers project consists of code from three projects:

  * The Linux kernel: linux-stable.git
  * Compat-wirelesS: compat-drivers.git
  * Compat: compat.git

The compat-drivers stable releases incorporates code from from
each of these git trees for the respective upstream Linux kernel
stable release. A branch called linux-3.x.y exists for each
stable release. Below we provide the ChangeLog of changes from
the previous branched release to the new branched release.

Release: linux-3.8


Updates from the compat.git project:


git shortlog linux-3.7.y..linux-3.8.y

Felix Fietkau (1):
  compat: fix compile errors when assembly is built into modules

Hauke Mehrtens (21):
  compat: update list of kernel headers
  compat: add USB_SUBCLASS_VENDOR_SPEC
  compat: make compat load without CONFIG_CPU_FREQ
  compat: add eth_zero_addr()
  compat: add kref_get_unless_zero()
  compat: move config_enabled to compat-3.4.h
  compat: fix compiler warning in nla_get_s64()
  compat: export platform_device_register_data()
  compat: fix warning of missing struct netdev_queue
  compat: add missing return value to netif_set_real_num_tx_queues
  compat: add simple_write_to_buffer
  compat: add ETHTOOL_FWVERS_LEN
  compat: fix warning in usb_autopm_get_interface_no_{resume,suspend}
  compat: do not access default_ethtool_ops
  compat: ckmake: make return code 2 is error
  compat: ckmake: remove lots of warning spam for the log
  compat: ckmake: do not start all build at the same time
  compat: add efi_enabled()
  compat: netdev_set_default_ethtool_ops() is not in kernel 3.7.5
  compat: check if efi_enabled() was already backported
  compat: deactivate netdev_set_default_ethtool_ops() for some 3.7 kernels

Johannes Berg (1):
  compat: backport unsigned netlink attribute accessors

Luis R. Rodriguez (42):
  compat: fix libc dependency on bin/get-compat-kernels
  compat: fix typo in bin/get-compat-kernels
  compat: run ckmake with num cpu threads
  compat: fix get-compat-kernels for libc issue again
  compat: change count to 4 for glibc kernel fix
  compat: add gpio header for kernels older than 2.6.24
  compat: backport ethtool_rxfh_indir_default()
  compat: backport ethtool to mii advertisment conversion helpers
  compat: backport BQL helpers
  compat: define NETIF_F_RXCSUM
  compat: fix addition of NETIF_F_RXCSUM
  compat: backport PCI MSI-X entry definitions
  compat: backport alloc_etherdev_mqs()
  compat: backport definition of PCI_MSIX_ENTRY_CTRL_MASKBIT
  compat: backport PTR_RET()
  compat: backport netif_set_real_num_tx_queues()
  compat: backport netif_set_real_num_rx_queues()
  compat: rename MDIO exported symbols
  compat: backplane mode negotiation ethtool definitions
  compat: backport napi_gro_receive()
  compat: generate CONFIG_COMPAT_KERNEL_3_8
  compat: backport

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

[Luis R. Rodriguez]

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
>> (chapter 5 Typedefs) is spending a number of lines explaining why.
>>
>> So is spinlock_t an exception to this rule simply because the kernel
>> uses spinlock_t all over the place.
>
> Yes.

Let me provide a better explanation. In practice drivers should not be
creating their own typedefs given that generally the reasons to create
them do not exist for drivers. The kernel may provide their own though
for reasons explained in CodingStyle and in such cases the drivers
should use these supplied typedefs.

  Luis

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

[Luis R. Rodriguez]

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 exception to this rule simply because the kernel
> uses spinlock_t all over the place.

Yes.

  Luis

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

[Luis R. Rodriguez]

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 spinlock_t an exception to this rule simply because the kernel
 uses spinlock_t all over the place.

Yes.

  Luis
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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 CodingStyle
 (chapter 5 Typedefs) is spending a number of lines explaining why.

 So is spinlock_t an exception to this rule simply because the kernel
 uses spinlock_t all over the place.

 Yes.

Let me provide a better explanation. In practice drivers should not be
creating their own typedefs given that generally the reasons to create
them do not exist for drivers. The kernel may provide their own though
for reasons explained in CodingStyle and in such cases the drivers
should use these supplied typedefs.

  Luis
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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
  CHECK   drivers/gpu/drm/i915/i915_irq.c
  CC [M]  drivers/gpu/drm/i915/i915_irq.o
  CHECK   drivers/gpu/drm/i915/i915_debugfs.c
drivers/gpu/drm/i915/i915_debugfs.c:558:31: warning: dereference of noderef 
expression
drivers/gpu/drm/i915/i915_debugfs.c:558:39: warning: dereference of noderef 
expression
drivers/gpu/drm/i915/i915_debugfs.c:558:51: warning: dereference of noderef 
expression
drivers/gpu/drm/i915/i915_debugfs.c:558:63: warning: dereference of noderef 
expression
  CC [M]  drivers/gpu/drm/i915/i915_debugfs.o
  CHECK   drivers/gpu/drm/i915/i915_suspend.c
  CC [M]  drivers/gpu/drm/i915/i915_suspend.o
  CHECK   drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/i915/i915_gem.c:3703:14: warning: incorrect type in assignment 
(different base types)
drivers/gpu/drm/i915/i915_gem.c:3703:14:expected unsigned int [unsigned] 
[usertype] mask
drivers/gpu/drm/i915/i915_gem.c:3703:14:got restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3706:22: warning: invalid assignment: &=
drivers/gpu/drm/i915/i915_gem.c:3706:22:left side has type unsigned int
drivers/gpu/drm/i915/i915_gem.c:3706:22:right side has type restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3707:22: warning: invalid assignment: |=
drivers/gpu/drm/i915/i915_gem.c:3707:22:left side has type unsigned int
drivers/gpu/drm/i915/i915_gem.c:3707:22:right side has type restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3711:39: warning: incorrect type in argument 2 
(different base types)
drivers/gpu/drm/i915/i915_gem.c:3711:39:expected restricted gfp_t 
[usertype] mask
drivers/gpu/drm/i915/i915_gem.c:3711:39:got unsigned int [unsigned] 
[usertype] mask
  CC [M]  drivers/gpu/drm/i915/i915_gem.o
  CHECK   drivers/gpu/drm/i915/i915_gem_context.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_context.o
  CHECK   drivers/gpu/drm/i915/i915_gem_debug.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_debug.o
  CHECK   drivers/gpu/drm/i915/i915_gem_evict.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_evict.o
  CHECK   drivers/gpu/drm/i915/i915_gem_execbuffer.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_execbuffer.o
  CHECK   drivers/gpu/drm/i915/i915_gem_gtt.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_gtt.o
  CHECK   drivers/gpu/drm/i915/i915_gem_stolen.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_stolen.o
  CHECK   drivers/gpu/drm/i915/i915_gem_tiling.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_tiling.o
  CHECK   drivers/gpu/drm/i915/i915_sysfs.c
  CC [M]  drivers/gpu/drm/i915/i915_sysfs.o
  CHECK   drivers/gpu/drm/i915/i915_trace_points.c
  CC [M]  drivers/gpu/drm/i915/i915_trace_points.o
  CHECK   drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_display.c:1736:9: warning: mixing different enum 
types
drivers/gpu/drm/i915/intel_display.c:1736:9: int enum transcoder  versus
drivers/gpu/drm/i915/intel_display.c:1736:9: int enum pipe
drivers/gpu/drm/i915/intel_display.c:3659:48: warning: mixing different enum 
types
drivers/gpu/drm/i915/intel_display.c:3659:48: int enum pipe  versus
drivers/gpu/drm/i915/intel_display.c:3659:48: int enum transcoder
  CC [M]  drivers/gpu/drm/i915/intel_display.o
  CHECK   drivers/gpu/drm/i915/intel_crt.c
  CC [M]  drivers/gpu/drm/i915/intel_crt.o
  CHECK   drivers/gpu/drm/i915/intel_lvds.c
  CC [M]  drivers/gpu/drm/i915/intel_lvds.o
  CHECK   drivers/gpu/drm/i915/intel_bios.c
drivers/gpu/drm/i915/intel_bios.c:706:60: warning: incorrect type in 
initializer (different address spaces)
drivers/gpu/drm/i915/intel_bios.c:706:60:expected struct vbt_header *vbt
drivers/gpu/drm/i915/intel_bios.c:706:60:got void [noderef] *vbt
drivers/gpu/drm/i915/intel_bios.c:726:42: warning: incorrect type in argument 1 
(different address spaces)
drivers/gpu/drm/i915/intel_bios.c:726:42:expected void const *
drivers/gpu/drm/i915/intel_bios.c:726:42:got unsigned char [noderef] 
[usertype] *
drivers/gpu/drm/i915/intel_bios.c:727:40: warning: cast removes address space 
of expression
drivers/gpu/drm/i915/intel_bios.c:738:24: warning: cast removes address space 
of expression
  CC [M]  drivers/gpu/drm/i915/intel_bios.o
  CHECK   drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_ddi.c:87:6: warning: symbol 
'intel_prepare_ddi_buffers' was not declared. Should it be static?
drivers/gpu/drm/i915/intel_ddi.c:1036:34: warning: mixing different enum types
drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum pipe  versus
drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum transcoder
  CC [M]  drivers/gpu/drm/i915/intel_ddi.o
drivers/gpu/drm/i915/intel_ddi.c: In function ?intel_ddi_setup_hw_pll_state?:
drivers/gpu/drm/i915/intel_ddi.c:1129:2: warning: ?port? may be used 
uninitialized in th

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

[Luis R. Rodriguez]

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. Driver developers
may want to look at the compile error output / sparse
error report supplied in each commit log, in particular
brcmfmac and i915, there are quite a few things that
are not related to this change that the developers
can clean up / fix.

Luis R. Rodriguez (6):
  ux500: convert struct spinlock to spinlock_t
  i915: convert struct spinlock to spinlock_t
  s5p-fimc: convert struct spinlock to spinlock_t
  s5p-jpeg: convert struct spinlock to spinlock_t
  brcmfmac: convert struct spinlock to spinlock_t
  ie6xx_wdt: convert struct spinlock to spinlock_t

 drivers/crypto/ux500/cryp/cryp.h   |4 ++--
 drivers/crypto/ux500/hash/hash_alg.h   |4 ++--
 drivers/gpu/drm/i915/i915_drv.h|4 ++--
 drivers/media/platform/s5p-fimc/mipi-csis.c|2 +-
 drivers/media/platform/s5p-jpeg/jpeg-core.h|2 +-
 drivers/net/wireless/brcm80211/brcmfmac/fweh.h |2 +-
 drivers/watchdog/ie6xx_wdt.c   |2 +-
 7 files changed, 10 insertions(+), 10 deletions(-)

-- 
1.7.10.4

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

[Luis R. Rodriguez]

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. Driver developers
may want to look at the compile error output / sparse
error report supplied in each commit log, in particular
brcmfmac and i915, there are quite a few things that
are not related to this change that the developers
can clean up / fix.

Luis R. Rodriguez (6):
  ux500: convert struct spinlock to spinlock_t
  i915: convert struct spinlock to spinlock_t
  s5p-fimc: convert struct spinlock to spinlock_t
  s5p-jpeg: convert struct spinlock to spinlock_t
  brcmfmac: convert struct spinlock to spinlock_t
  ie6xx_wdt: convert struct spinlock to spinlock_t

 drivers/crypto/ux500/cryp/cryp.h   |4 ++--
 drivers/crypto/ux500/hash/hash_alg.h   |4 ++--
 drivers/gpu/drm/i915/i915_drv.h|4 ++--
 drivers/media/platform/s5p-fimc/mipi-csis.c|2 +-
 drivers/media/platform/s5p-jpeg/jpeg-core.h|2 +-
 drivers/net/wireless/brcm80211/brcmfmac/fweh.h |2 +-
 drivers/watchdog/ie6xx_wdt.c   |2 +-
 7 files changed, 10 insertions(+), 10 deletions(-)

-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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
  CHECK   drivers/gpu/drm/i915/i915_irq.c
  CC [M]  drivers/gpu/drm/i915/i915_irq.o
  CHECK   drivers/gpu/drm/i915/i915_debugfs.c
drivers/gpu/drm/i915/i915_debugfs.c:558:31: warning: dereference of noderef 
expression
drivers/gpu/drm/i915/i915_debugfs.c:558:39: warning: dereference of noderef 
expression
drivers/gpu/drm/i915/i915_debugfs.c:558:51: warning: dereference of noderef 
expression
drivers/gpu/drm/i915/i915_debugfs.c:558:63: warning: dereference of noderef 
expression
  CC [M]  drivers/gpu/drm/i915/i915_debugfs.o
  CHECK   drivers/gpu/drm/i915/i915_suspend.c
  CC [M]  drivers/gpu/drm/i915/i915_suspend.o
  CHECK   drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/i915/i915_gem.c:3703:14: warning: incorrect type in assignment 
(different base types)
drivers/gpu/drm/i915/i915_gem.c:3703:14:expected unsigned int [unsigned] 
[usertype] mask
drivers/gpu/drm/i915/i915_gem.c:3703:14:got restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3706:22: warning: invalid assignment: =
drivers/gpu/drm/i915/i915_gem.c:3706:22:left side has type unsigned int
drivers/gpu/drm/i915/i915_gem.c:3706:22:right side has type restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3707:22: warning: invalid assignment: |=
drivers/gpu/drm/i915/i915_gem.c:3707:22:left side has type unsigned int
drivers/gpu/drm/i915/i915_gem.c:3707:22:right side has type restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3711:39: warning: incorrect type in argument 2 
(different base types)
drivers/gpu/drm/i915/i915_gem.c:3711:39:expected restricted gfp_t 
[usertype] mask
drivers/gpu/drm/i915/i915_gem.c:3711:39:got unsigned int [unsigned] 
[usertype] mask
  CC [M]  drivers/gpu/drm/i915/i915_gem.o
  CHECK   drivers/gpu/drm/i915/i915_gem_context.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_context.o
  CHECK   drivers/gpu/drm/i915/i915_gem_debug.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_debug.o
  CHECK   drivers/gpu/drm/i915/i915_gem_evict.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_evict.o
  CHECK   drivers/gpu/drm/i915/i915_gem_execbuffer.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_execbuffer.o
  CHECK   drivers/gpu/drm/i915/i915_gem_gtt.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_gtt.o
  CHECK   drivers/gpu/drm/i915/i915_gem_stolen.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_stolen.o
  CHECK   drivers/gpu/drm/i915/i915_gem_tiling.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_tiling.o
  CHECK   drivers/gpu/drm/i915/i915_sysfs.c
  CC [M]  drivers/gpu/drm/i915/i915_sysfs.o
  CHECK   drivers/gpu/drm/i915/i915_trace_points.c
  CC [M]  drivers/gpu/drm/i915/i915_trace_points.o
  CHECK   drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_display.c:1736:9: warning: mixing different enum 
types
drivers/gpu/drm/i915/intel_display.c:1736:9: int enum transcoder  versus
drivers/gpu/drm/i915/intel_display.c:1736:9: int enum pipe
drivers/gpu/drm/i915/intel_display.c:3659:48: warning: mixing different enum 
types
drivers/gpu/drm/i915/intel_display.c:3659:48: int enum pipe  versus
drivers/gpu/drm/i915/intel_display.c:3659:48: int enum transcoder
  CC [M]  drivers/gpu/drm/i915/intel_display.o
  CHECK   drivers/gpu/drm/i915/intel_crt.c
  CC [M]  drivers/gpu/drm/i915/intel_crt.o
  CHECK   drivers/gpu/drm/i915/intel_lvds.c
  CC [M]  drivers/gpu/drm/i915/intel_lvds.o
  CHECK   drivers/gpu/drm/i915/intel_bios.c
drivers/gpu/drm/i915/intel_bios.c:706:60: warning: incorrect type in 
initializer (different address spaces)
drivers/gpu/drm/i915/intel_bios.c:706:60:expected struct vbt_header *vbt
drivers/gpu/drm/i915/intel_bios.c:706:60:got void [noderef] asn:2*vbt
drivers/gpu/drm/i915/intel_bios.c:726:42: warning: incorrect type in argument 1 
(different address spaces)
drivers/gpu/drm/i915/intel_bios.c:726:42:expected void const *noident
drivers/gpu/drm/i915/intel_bios.c:726:42:got unsigned char [noderef] 
[usertype] asn:2*
drivers/gpu/drm/i915/intel_bios.c:727:40: warning: cast removes address space 
of expression
drivers/gpu/drm/i915/intel_bios.c:738:24: warning: cast removes address space 
of expression
  CC [M]  drivers/gpu/drm/i915/intel_bios.o
  CHECK   drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_ddi.c:87:6: warning: symbol 
'intel_prepare_ddi_buffers' was not declared. Should it be static?
drivers/gpu/drm/i915/intel_ddi.c:1036:34: warning: mixing different enum types
drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum pipe  versus
drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum transcoder
  CC [M]  drivers/gpu/drm/i915/intel_ddi.o
drivers/gpu/drm/i915/intel_ddi.c: In function ‘intel_ddi_setup_hw_pll_state’:
drivers/gpu/drm/i915/intel_ddi.c:1129:2: warning: ‘port’ may be used 
uninitialized

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

[Luis R. Rodriguez]

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:
>> >> 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 name. When
>> >> one file was split into two files the kernel header
>> >> includes the uapi header and a UAPI prefix was added to
>> >> the uapi header for its header guard. When there was no
>> >> kernel API content found the uapi header file was the
>> >> only one that was kept and the original guard for the
>> >> header file was kept. In this particular case the
>> >> original users of this header file were not modified
>> >> and the uapi header file is expected to be picked up
>> >> by path.
>> >>
>> >> This may work well at compilation on the kernel but when
>> >> backporting this creates a few complexities.
>> >
>> > Could you please provide more details about those complexities ?
>>
>> Sure, the backported DRM code is as-is code from linux-next. The
>> header search path includes a copy of a few select header files from
>> linux-next, the rest are part of the compat [0] project to help with
>> backporting and the last set are from your own kernel. In this
>> particular case the UAPI effort pushed into include/uapi/drm a few
>> files which are now no longer present in the old include/drm/ location
>> when there was no respective kernel-only APIs exposed. For DRM code
>> that did not use the new uapi/drm/ path for old header includes this
>> means that upon backporting the older kernel's header file would be
>> used obviously leading to a series of compilation failures. By being
>> explicit about the path, as was done with a few other header files, we
>> can suck out DRM code intact from the kernel to be compilable for
>> older kernels. As of the v3.7-rc1 the compat-drivers project [1] will
>> be providing DRM modules. The new UAPI changes broke compilation on
>> compat-drivers when compiling DRM code so to fix this we either patch
>> code taken from the Linux kernel as I have done, force inclusion of a
>> few specific headers files, or use include_next tricks. It turns out
>> that forcing inclusion of -I$(M)/include/uapi as a path search prior
>> to your own kernel's at compilation time did not help.
>
> Shouldn't that be added as a search path *after* include/linux/ instead of
> before ?

Ah, therein lies the issue. If backporting no, if backporting you
should seek first for your current directory's include/drm/ dir and
then uapi, and then only later the older kernel's paths:

NOSTDINC_FLAGS := \
-I$(M)/include/ \
-I$(M)/include/drm \
-I$(M)/include/uapi \
-include $(M)/include/linux/compat-2.6.h \
$(CFLAGS)

>> The include_next trick can work as well but that'd mean synching the UAPI
>> files regularly into compat. I'd much prefer to have code intact when
>> possible when backporting so the option I stuck with then was to patch
>> the code directly and then as part of compat-drivers to always copy
>> that day's linux-next UAPI headers into the current directory for
>> compilation. I see no other driver code using the uapi path explicitly
>> though, is that by design?
>
> As far as I understand that's by design, yes. Kernel code isn't expected to
> reference uapi/ headers directly.

Did the design consider the case where no respective kernel API header
file would ever exist?

>> Would it be wrong to be explicit about using a UAPI header alone if no
>> kernel API files exist?
>
> I personally don't really like including such "features" in a mainline just
> for backporting,

Sort of ditto. I haven't yet made a strong case for one particular
situation where this would help (but I will in the long run, see
blog), but this example should not be considered one. The patch itself
should be considered in terms of its merit for clarifying usage and
assumptions of uapi. The fact that I came up with it due to issues
when backporting is only secondary.

> especially when they go against the spirit of the
> architecture (the uapi/ split design principles in this case).

The patches, pull request, a

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

[Luis R. Rodriguez]

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 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/ with the same file name. When
  one file was split into two files the kernel header
  includes the uapi header and a UAPI prefix was added to
  the uapi header for its header guard. When there was no
  kernel API content found the uapi header file was the
  only one that was kept and the original guard for the
  header file was kept. In this particular case the
  original users of this header file were not modified
  and the uapi header file is expected to be picked up
  by path.
 
  This may work well at compilation on the kernel but when
  backporting this creates a few complexities.
 
  Could you please provide more details about those complexities ?

 Sure, the backported DRM code is as-is code from linux-next. The
 header search path includes a copy of a few select header files from
 linux-next, the rest are part of the compat [0] project to help with
 backporting and the last set are from your own kernel. In this
 particular case the UAPI effort pushed into include/uapi/drm a few
 files which are now no longer present in the old include/drm/ location
 when there was no respective kernel-only APIs exposed. For DRM code
 that did not use the new uapi/drm/ path for old header includes this
 means that upon backporting the older kernel's header file would be
 used obviously leading to a series of compilation failures. By being
 explicit about the path, as was done with a few other header files, we
 can suck out DRM code intact from the kernel to be compilable for
 older kernels. As of the v3.7-rc1 the compat-drivers project [1] will
 be providing DRM modules. The new UAPI changes broke compilation on
 compat-drivers when compiling DRM code so to fix this we either patch
 code taken from the Linux kernel as I have done, force inclusion of a
 few specific headers files, or use include_next tricks. It turns out
 that forcing inclusion of -I$(M)/include/uapi as a path search prior
 to your own kernel's at compilation time did not help.

 Shouldn't that be added as a search path *after* include/linux/ instead of
 before ?

Ah, therein lies the issue. If backporting no, if backporting you
should seek first for your current directory's include/drm/ dir and
then uapi, and then only later the older kernel's paths:

NOSTDINC_FLAGS := \
-I$(M)/include/ \
-I$(M)/include/drm \
-I$(M)/include/uapi \
-include $(M)/include/linux/compat-2.6.h \
$(CFLAGS)

 The include_next trick can work as well but that'd mean synching the UAPI
 files regularly into compat. I'd much prefer to have code intact when
 possible when backporting so the option I stuck with then was to patch
 the code directly and then as part of compat-drivers to always copy
 that day's linux-next UAPI headers into the current directory for
 compilation. I see no other driver code using the uapi path explicitly
 though, is that by design?

 As far as I understand that's by design, yes. Kernel code isn't expected to
 reference uapi/ headers directly.

Did the design consider the case where no respective kernel API header
file would ever exist?

 Would it be wrong to be explicit about using a UAPI header alone if no
 kernel API files exist?

 I personally don't really like including such features in a mainline just
 for backporting,

Sort of ditto. I haven't yet made a strong case for one particular
situation where this would help (but I will in the long run, see
blog), but this example should not be considered one. The patch itself
should be considered in terms of its merit for clarifying usage and
assumptions of uapi. The fact that I came up with it due to issues
when backporting is only secondary.

 especially when they go against the spirit of the
 architecture (the uapi/ split design principles in this case).

The patches, pull request, and even lwn article did not cover the
intent on architecture so if it was the design objective I'd like to
know how that is determined. From the looks of it, this as all
scripted and I do wonder if the case where no kernel API header file
existed was taken into consideration.

 The way we're
 dealing with this in the V4L backport tree
 (http://git.linuxtv.org/media_build.git) is to play with Makefiles, include
 compatibility headers and, if nothing else can work, maintain backport patches
 for mainline code.

Thanks for the heads up, I can certainly keep these patches as
external but when if I see something

[PATCH 0/2] uapi: two minor changes

[Luis R. Rodriguez]

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.

If the changes on the first patch make sense perhaps similar
changes can be done for the other subsystem in similar cases.
In those cases the now kernel API header file no longer exists
so even if userspace were using the files the only way to pick
the header up would have been to provide the new uapi path.

[0] http://lwn.net/Articles/507794/
[1] https://backports.wiki.kernel.org

Luis R. Rodriguez (2):
  uapi: update includes for drm content when no kernel API exists
  uapi: remove trailing spaces

 drivers/gpu/drm/drm_crtc.c|2 +-
 drivers/gpu/drm/nouveau/nv04_cursor.c |2 +-
 drivers/staging/omapdrm/omap_crtc.c   |2 +-
 include/drm/drmP.h|4 ++--
 include/drm/drm_crtc.h|4 ++--
 include/uapi/asm-generic/siginfo.h|4 ++--
 include/uapi/asm-generic/statfs.h |4 ++--
 include/uapi/drm/drm.h|2 +-
 include/uapi/drm/radeon_drm.h |2 +-
 9 files changed, 13 insertions(+), 13 deletions(-)

-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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/ with the same file name. When
one file was split into two files the kernel header
includes the uapi header and a UAPI prefix was added to
the uapi header for its header guard. When there was no
kernel API content found the uapi header file was the
only one that was kept and the original guard for the
header file was kept. In this particular case the
original users of this header file were not modified
and the uapi header file is expected to be picked up
by path.

This may work well at compilation on the kernel but when
backporting this creates a few complexities. To help with
backporting [0] lets be explicit about the new uapi path
when there is no respective kernel API header file. For
more details on the UAPI changes see the lwn article on
this [1].

[0] https://backports.wiki.kernel.org
[1] http://lwn.net/Articles/507794/

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: David Airlie airl...@linux.ie
Cc: Ben Skeggs bske...@redhat.com
Cc: Alan Cox a...@lxorguk.ukuu.org.uk
Cc: David Howells dhowe...@redhat.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Alex Deucher alexander.deuc...@amd.com
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
 drivers/gpu/drm/drm_crtc.c|2 +-
 drivers/gpu/drm/nouveau/nv04_cursor.c |2 +-
 drivers/staging/omapdrm/omap_crtc.c   |2 +-
 include/drm/drmP.h|4 ++--
 include/drm/drm_crtc.h|4 ++--
 include/uapi/drm/drm.h|2 +-
 6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ef1b221..6486e89 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -35,7 +35,7 @@
 #include drm/drmP.h
 #include drm/drm_crtc.h
 #include drm/drm_edid.h
-#include drm/drm_fourcc.h
+#include uapi/drm/drm_fourcc.h
 
 /* Avoid boilerplate.  I'm tired of typing. */
 #define DRM_ENUM_NAME_FN(fnname, list) \
diff --git a/drivers/gpu/drm/nouveau/nv04_cursor.c 
b/drivers/gpu/drm/nouveau/nv04_cursor.c
index fe86f0d..7af590f 100644
--- a/drivers/gpu/drm/nouveau/nv04_cursor.c
+++ b/drivers/gpu/drm/nouveau/nv04_cursor.c
@@ -1,5 +1,5 @@
 #include drm/drmP.h
-#include drm/drm_mode.h
+#include uapi/drm/drm_mode.h
 #include nouveau_drm.h
 #include nouveau_reg.h
 #include nouveau_crtc.h
diff --git a/drivers/staging/omapdrm/omap_crtc.c 
b/drivers/staging/omapdrm/omap_crtc.c
index 732f2ad..029c9ec 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -19,7 +19,7 @@
 
 #include omap_drv.h
 
-#include drm_mode.h
+#include uapi/drm/drm_mode.h
 #include drm_crtc.h
 #include drm_crtc_helper.h
 
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..9030369 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -72,8 +72,8 @@
 #include linux/workqueue.h
 #include linux/poll.h
 #include asm/pgalloc.h
-#include drm/drm.h
-#include drm/drm_sarea.h
+#include uapi/drm/drm.h
+#include uapi/drm/drm_sarea.h
 
 #include linux/idr.h
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3fa18b7..1012503 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -30,9 +30,9 @@
 #include linux/types.h
 #include linux/idr.h
 #include linux/fb.h
-#include drm/drm_mode.h
 
-#include drm/drm_fourcc.h
+#include uapi/drm/drm_mode.h
+#include uapi/drm/drm_fourcc.h
 
 struct drm_device;
 struct drm_mode_set;
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 1e3481e..51ee504 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -628,7 +628,7 @@ struct drm_prime_handle {
__s32 fd;
 };
 
-#include drm/drm_mode.h
+#include uapi/drm/drm_mode.h
 
 #define DRM_IOCTL_BASE 'd'
 #define DRM_IO(nr) _IO(DRM_IOCTL_BASE,nr)
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] uapi: remove trailing spaces

[Luis R. Rodriguez]

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: David Airlie airl...@linux.ie
Cc: Ben Skeggs bske...@redhat.com
Cc: Alan Cox a...@lxorguk.ukuu.org.uk
Cc: David Howells dhowe...@redhat.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Alex Deucher alexander.deuc...@amd.com
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org 
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
 include/uapi/asm-generic/siginfo.h |4 ++--
 include/uapi/asm-generic/statfs.h  |4 ++--
 include/uapi/drm/radeon_drm.h  |2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/uapi/asm-generic/siginfo.h 
b/include/uapi/asm-generic/siginfo.h
index ba5be7f..34b941ce6 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -252,8 +252,8 @@ typedef struct siginfo {
 
 /*
  * sigevent definitions
- * 
- * It seems likely that SIGEV_THREAD will have to be handled from 
+ *
+ * It seems likely that SIGEV_THREAD will have to be handled from
  * userspace, libpthread transmuting it to SIGEV_SIGNAL, which the
  * thread manager then catches and does the appropriate nonsense.
  * However, everything is written out here so as to not get lost.
diff --git a/include/uapi/asm-generic/statfs.h 
b/include/uapi/asm-generic/statfs.h
index 0999647..0d79b2f 100644
--- a/include/uapi/asm-generic/statfs.h
+++ b/include/uapi/asm-generic/statfs.h
@@ -36,7 +36,7 @@ struct statfs {
 
 /*
  * ARM needs to avoid the 32-bit padding at the end, for consistency
- * between EABI and OABI 
+ * between EABI and OABI
  */
 #ifndef ARCH_PACK_STATFS64
 #define ARCH_PACK_STATFS64
@@ -57,7 +57,7 @@ struct statfs64 {
__statfs_word f_spare[4];
 } ARCH_PACK_STATFS64;
 
-/* 
+/*
  * IA64 and x86_64 need to avoid the 32-bit padding at the end,
  * to be compatible with the i386 ABI
  */
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 4766c0f..48b0db3 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -229,7 +229,7 @@ typedef union {
 #  define R300_WAIT_3D 0x2
 /* these two defines are DOING IT WRONG - however
  * we have userspace which relies on using these.
- * The wait interface is backwards compat new 
+ * The wait interface is backwards compat new
  * code should use the NEW_WAIT defines below
  * THESE ARE NOT BIT FIELDS
  */
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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 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 name. When
 one file was split into two files the kernel header
 includes the uapi header and a UAPI prefix was added to
 the uapi header for its header guard. When there was no
 kernel API content found the uapi header file was the
 only one that was kept and the original guard for the
 header file was kept. In this particular case the
 original users of this header file were not modified
 and the uapi header file is expected to be picked up
 by path.

 This may work well at compilation on the kernel but when
 backporting this creates a few complexities.

 Could you please provide more details about those complexities ?

Sure, the backported DRM code is as-is code from linux-next. The
header search path includes a copy of a few select header files from
linux-next, the rest are part of the compat [0] project to help with
backporting and the last set are from your own kernel. In this
particular case the UAPI effort pushed into include/uapi/drm a few
files which are now no longer present in the old include/drm/ location
when there was no respective kernel-only APIs exposed. For DRM code
that did not use the new uapi/drm/ path for old header includes this
means that upon backporting the older kernel's header file would be
used obviously leading to a series of compilation failures. By being
explicit about the path, as was done with a few other header files, we
can suck out DRM code intact from the kernel to be compilable for
older kernels. As of the v3.7-rc1 the compat-drivers project [1] will
be providing DRM modules. The new UAPI changes broke compilation on
compat-drivers when compiling DRM code so to fix this we either patch
code taken from the Linux kernel as I have done, force inclusion of a
few specific headers files, or use include_next tricks. It turns out
that forcing inclusion of -I$(M)/include/uapi as a path search prior
to your own kernel's at compilation time did not help. The
include_next trick can work as well but that'd mean synching the UAPI
files regularly into compat. I'd much prefer to have code intact when
possible when backporting so the option I stuck with then was to patch
the code directly and then as part of compat-drivers to always copy
that day's linux-next UAPI headers into the current directory for
compilation. I see no other driver code using the uapi path explicitly
though, is that by design? Would it be wrong to be explicit about
using a UAPI header alone if no kernel API files exist?

[0] https://backports.wiki.kernel.org/index.php/Documentation/compat
[1] https://backports.wiki.kernel.org/

  Luis
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Luis R. Rodriguez]

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 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 name. When
>> one file was split into two files the kernel header
>> includes the uapi header and a UAPI prefix was added to
>> the uapi header for its header guard. When there was no
>> kernel API content found the uapi header file was the
>> only one that was kept and the original guard for the
>> header file was kept. In this particular case the
>> original users of this header file were not modified
>> and the uapi header file is expected to be picked up
>> by path.
>>
>> This may work well at compilation on the kernel but when
>> backporting this creates a few complexities.
>
> Could you please provide more details about those complexities ?

Sure, the backported DRM code is as-is code from linux-next. The
header search path includes a copy of a few select header files from
linux-next, the rest are part of the compat [0] project to help with
backporting and the last set are from your own kernel. In this
particular case the UAPI effort pushed into include/uapi/drm a few
files which are now no longer present in the old include/drm/ location
when there was no respective kernel-only APIs exposed. For DRM code
that did not use the new uapi/drm/ path for old header includes this
means that upon backporting the older kernel's header file would be
used obviously leading to a series of compilation failures. By being
explicit about the path, as was done with a few other header files, we
can suck out DRM code intact from the kernel to be compilable for
older kernels. As of the v3.7-rc1 the compat-drivers project [1] will
be providing DRM modules. The new UAPI changes broke compilation on
compat-drivers when compiling DRM code so to fix this we either patch
code taken from the Linux kernel as I have done, force inclusion of a
few specific headers files, or use include_next tricks. It turns out
that forcing inclusion of -I$(M)/include/uapi as a path search prior
to your own kernel's at compilation time did not help. The
include_next trick can work as well but that'd mean synching the UAPI
files regularly into compat. I'd much prefer to have code intact when
possible when backporting so the option I stuck with then was to patch
the code directly and then as part of compat-drivers to always copy
that day's linux-next UAPI headers into the current directory for
compilation. I see no other driver code using the uapi path explicitly
though, is that by design? Would it be wrong to be explicit about
using a UAPI header alone if no kernel API files exist?

[0] https://backports.wiki.kernel.org/index.php/Documentation/compat
[1] https://backports.wiki.kernel.org/

  Luis

[PATCH 2/2] uapi: remove trailing spaces

[Luis R. Rodriguez]

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 Airlie 
Cc: Ben Skeggs 
Cc: Alan Cox 
Cc: David Howells 
Cc: Thomas Gleixner 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Alex Deucher 
Cc: Paul E. McKenney 
Cc: Greg Kroah-Hartman  
Cc: Laurent Pinchart 
Signed-off-by: Luis R. Rodriguez 
---
 include/uapi/asm-generic/siginfo.h |4 ++--
 include/uapi/asm-generic/statfs.h  |4 ++--
 include/uapi/drm/radeon_drm.h  |2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/uapi/asm-generic/siginfo.h 
b/include/uapi/asm-generic/siginfo.h
index ba5be7f..34b941ce6 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -252,8 +252,8 @@ typedef struct siginfo {

 /*
  * sigevent definitions
- * 
- * It seems likely that SIGEV_THREAD will have to be handled from 
+ *
+ * It seems likely that SIGEV_THREAD will have to be handled from
  * userspace, libpthread transmuting it to SIGEV_SIGNAL, which the
  * thread manager then catches and does the appropriate nonsense.
  * However, everything is written out here so as to not get lost.
diff --git a/include/uapi/asm-generic/statfs.h 
b/include/uapi/asm-generic/statfs.h
index 0999647..0d79b2f 100644
--- a/include/uapi/asm-generic/statfs.h
+++ b/include/uapi/asm-generic/statfs.h
@@ -36,7 +36,7 @@ struct statfs {

 /*
  * ARM needs to avoid the 32-bit padding at the end, for consistency
- * between EABI and OABI 
+ * between EABI and OABI
  */
 #ifndef ARCH_PACK_STATFS64
 #define ARCH_PACK_STATFS64
@@ -57,7 +57,7 @@ struct statfs64 {
__statfs_word f_spare[4];
 } ARCH_PACK_STATFS64;

-/* 
+/*
  * IA64 and x86_64 need to avoid the 32-bit padding at the end,
  * to be compatible with the i386 ABI
  */
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 4766c0f..48b0db3 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -229,7 +229,7 @@ typedef union {
 #  define R300_WAIT_3D 0x2
 /* these two defines are DOING IT WRONG - however
  * we have userspace which relies on using these.
- * The wait interface is backwards compat new 
+ * The wait interface is backwards compat new
  * code should use the NEW_WAIT defines below
  * THESE ARE NOT BIT FIELDS
  */
-- 
1.7.10.4

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

[Luis R. Rodriguez]

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/ with the same file name. When
one file was split into two files the kernel header
includes the uapi header and a UAPI prefix was added to
the uapi header for its header guard. When there was no
kernel API content found the uapi header file was the
only one that was kept and the original guard for the
header file was kept. In this particular case the
original users of this header file were not modified
and the uapi header file is expected to be picked up
by path.

This may work well at compilation on the kernel but when
backporting this creates a few complexities. To help with
backporting [0] lets be explicit about the new uapi path
when there is no respective kernel API header file. For
more details on the UAPI changes see the lwn article on
this [1].

[0] https://backports.wiki.kernel.org
[1] http://lwn.net/Articles/507794/

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: Alan Cox 
Cc: David Howells 
Cc: Thomas Gleixner 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Alex Deucher 
Cc: Paul E. McKenney 
Cc: Greg Kroah-Hartman 
Cc: Laurent Pinchart 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/gpu/drm/drm_crtc.c|2 +-
 drivers/gpu/drm/nouveau/nv04_cursor.c |2 +-
 drivers/staging/omapdrm/omap_crtc.c   |2 +-
 include/drm/drmP.h|4 ++--
 include/drm/drm_crtc.h|4 ++--
 include/uapi/drm/drm.h|2 +-
 6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ef1b221..6486e89 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -35,7 +35,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 

 /* Avoid boilerplate.  I'm tired of typing. */
 #define DRM_ENUM_NAME_FN(fnname, list) \
diff --git a/drivers/gpu/drm/nouveau/nv04_cursor.c 
b/drivers/gpu/drm/nouveau/nv04_cursor.c
index fe86f0d..7af590f 100644
--- a/drivers/gpu/drm/nouveau/nv04_cursor.c
+++ b/drivers/gpu/drm/nouveau/nv04_cursor.c
@@ -1,5 +1,5 @@
 #include 
-#include 
+#include 
 #include "nouveau_drm.h"
 #include "nouveau_reg.h"
 #include "nouveau_crtc.h"
diff --git a/drivers/staging/omapdrm/omap_crtc.c 
b/drivers/staging/omapdrm/omap_crtc.c
index 732f2ad..029c9ec 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -19,7 +19,7 @@

 #include "omap_drv.h"

-#include "drm_mode.h"
+#include 
 #include "drm_crtc.h"
 #include "drm_crtc_helper.h"

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..9030369 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -72,8 +72,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 

 #include 

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3fa18b7..1012503 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -30,9 +30,9 @@
 #include 
 #include 
 #include 
-#include 

-#include 
+#include 
+#include 

 struct drm_device;
 struct drm_mode_set;
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 1e3481e..51ee504 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -628,7 +628,7 @@ struct drm_prime_handle {
__s32 fd;
 };

-#include 
+#include 

 #define DRM_IOCTL_BASE 'd'
 #define DRM_IO(nr) _IO(DRM_IOCTL_BASE,nr)
-- 
1.7.10.4

[PATCH 0/2] uapi: two minor changes

[Luis R. Rodriguez]

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.

If the changes on the first patch make sense perhaps similar
changes can be done for the other subsystem in similar cases.
In those cases the now kernel API header file no longer exists
so even if userspace were using the files the only way to pick
the header up would have been to provide the new uapi path.

[0] http://lwn.net/Articles/507794/
[1] https://backports.wiki.kernel.org

Luis R. Rodriguez (2):
  uapi: update includes for drm content when no kernel API exists
  uapi: remove trailing spaces

 drivers/gpu/drm/drm_crtc.c|2 +-
 drivers/gpu/drm/nouveau/nv04_cursor.c |2 +-
 drivers/staging/omapdrm/omap_crtc.c   |2 +-
 include/drm/drmP.h|4 ++--
 include/drm/drm_crtc.h|4 ++--
 include/uapi/asm-generic/siginfo.h|4 ++--
 include/uapi/asm-generic/statfs.h |4 ++--
 include/uapi/drm/drm.h|2 +-
 include/uapi/drm/radeon_drm.h |2 +-
 9 files changed, 13 insertions(+), 13 deletions(-)

-- 
1.7.10.4

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

[Luis R. Rodriguez]

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 stuck
 with older kernels (Currently all of the popular and maintained drm
 drivers except i915 (there's an i2c think that I couldn't backport
 yet) from linux-next can be built against kernels down to 3.0).

 The tree is on github. I've set up a shiny github pages for it:
  http://ozancaglayan.github.com/compat-drm/

Great job!

Given that the compat module is shared, and a quite a bit of other
code / style is shared, and I'd love to see us start to formalize
documenting collateral evolutions on the kernel in one place I'd like
to propose to you merging this into compat-wirless and we then rename
the project to compat-drivers, with you maintaining the drm
components. This also gives us an already established quick outlet for
redistribution as well. What do you think?

Some comments:

In the patches/ directory if you can add a description on the top of
each patch explaining *why* that collateral evolution was not
backportable through compat it would help. It sets the standard for
others introducing similar types of patches.

For patches/00-vga_switcheroo_client_ops.patch:

I wonder if you may be able to get rid of this patch. The attached
patch is an RFC patch for compat.git which explains how I'm thinking
this may be possible, I don't have time to test it but let me know
what you think.

Great work though!

  Luis


vga_switcheroo_client_ops.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Lf_driver_backport] [ANN] compat-drm tree

[Luis R. Rodriguez]

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 stuff to people stuck
> with older kernels (Currently all of the popular and maintained drm
> drivers except i915 (there's an i2c think that I couldn't backport
> yet) from linux-next can be built against kernels down to 3.0).
>
> The tree is on github. I've set up a shiny github pages for it:
> ?http://ozancaglayan.github.com/compat-drm/

Great job!

Given that the compat module is shared, and a quite a bit of other
code / style is shared, and I'd love to see us start to formalize
documenting collateral evolutions on the kernel in one place I'd like
to propose to you merging this into compat-wirless and we then rename
the project to compat-drivers, with you maintaining the drm
components. This also gives us an already established quick outlet for
redistribution as well. What do you think?

Some comments:

In the patches/ directory if you can add a description on the top of
each patch explaining *why* that collateral evolution was not
backportable through compat it would help. It sets the standard for
others introducing similar types of patches.

For patches/00-vga_switcheroo_client_ops.patch:

I wonder if you may be able to get rid of this patch. The attached
patch is an RFC patch for compat.git which explains how I'm thinking
this may be possible, I don't have time to test it but let me know
what you think.

Great work though!

  Luis
-- next part --
A non-text attachment was scrubbed...
Name: vga_switcheroo_client_ops.patch
Type: application/octet-stream
Size: 3393 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120628/091a7df7/attachment.obj>

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

[Luis R. Rodriguez]

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/wireless/ath/debug.c: Use printf extension %pV
> ?drivers/net/wireless/b43/main.c: Use printf extension %pV
> ?drivers/net/wireless/b43legacy/main.c: Use printf extension %pV
> ?fs/gfs2/glock.c: Use printf extension %pV
> ?fs/nilfs2/super.c: Use printf extension %pV
> ?fs/quota/dquot.c: Use printf extension %pV
> ?net/sunrpc/svc.c: Use printf extension %pV
>
> ?drivers/gpu/drm/drm_stub.c ? ? ? ? ? ?| ? 14 +++--
> ?drivers/isdn/mISDN/layer1.c ? ? ? ? ? | ? 10 +--
> ?drivers/isdn/mISDN/layer2.c ? ? ? ? ? | ? 12 ++--
> ?drivers/isdn/mISDN/tei.c ? ? ? ? ? ? ?| ? 23 +++
> ?drivers/net/wireless/ath/debug.c ? ? ?| ? ?9 +-
> ?drivers/net/wireless/b43/main.c ? ? ? | ? 48 
> ?drivers/net/wireless/b43legacy/main.c | ? 47 
> ?fs/gfs2/glock.c ? ? ? ? ? ? ? ? ? ? ? | ? ?9 +-
> ?fs/nilfs2/super.c ? ? ? ? ? ? ? ? ? ? | ? 23 +++-
> ?fs/quota/dquot.c ? ? ? ? ? ? ? ? ? ? ?| ? 12 +---
> ?net/sunrpc/svc.c ? ? ? ? ? ? ? ? ? ? ?| ? 12 +---
> ?11 files changed, 161 insertions(+), 58 deletions(-)

When was this added upstream BTW? I ask for backport considerations.

  Luis

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

[Luis R. Rodriguez]

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
  drivers/net/wireless/ath/debug.c: Use printf extension %pV
  drivers/net/wireless/b43/main.c: Use printf extension %pV
  drivers/net/wireless/b43legacy/main.c: Use printf extension %pV
  fs/gfs2/glock.c: Use printf extension %pV
  fs/nilfs2/super.c: Use printf extension %pV
  fs/quota/dquot.c: Use printf extension %pV
  net/sunrpc/svc.c: Use printf extension %pV

  drivers/gpu/drm/drm_stub.c            |   14 +++--
  drivers/isdn/mISDN/layer1.c           |   10 +--
  drivers/isdn/mISDN/layer2.c           |   12 ++--
  drivers/isdn/mISDN/tei.c              |   23 +++
  drivers/net/wireless/ath/debug.c      |    9 +-
  drivers/net/wireless/b43/main.c       |   48 
  drivers/net/wireless/b43legacy/main.c |   47 
  fs/gfs2/glock.c                       |    9 +-
  fs/nilfs2/super.c                     |   23 +++-
  fs/quota/dquot.c                      |   12 +---
  net/sunrpc/svc.c                      |   12 +---
  11 files changed, 161 insertions(+), 58 deletions(-)

When was this added upstream BTW? I ask for backport considerations.

  Luis
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/15] change default_llseek action

[Luis R. Rodriguez]

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 your subsystem tree as a participant of linux-next.  As
 you may know, this is not a judgment of your code.  The purpose of
 linux-next is for integration testing and to lower the impact of
 conflicts between subsystems in the next merge window.

 You will need to ensure that the patches/commits in your tree/series have
 been:
     * submitted under GPL v2 (or later) and include the Contributor's
        Signed-off-by,

I should note this should say the code should be GPL-compatible, it
doesn't need to be GPLv2 (or later). Furthermore the contributors of
the subsystem respect the individual licenses of the files through the
Developers Certificate of Origin, which tells the developers what the
meaning of Signed-off-by means.

  Luis
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/15] change default_llseek action

[Luis R. Rodriguez]

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 a participant of linux-next. ?As
> you may know, this is not a judgment of your code. ?The purpose of
> linux-next is for integration testing and to lower the impact of
> conflicts between subsystems in the next merge window.
>
> You will need to ensure that the patches/commits in your tree/series have
> been:
> ? ? * submitted under GPL v2 (or later) and include the Contributor's
> ? ? ? ?Signed-off-by,

I should note this should say the code should be GPL-compatible, it
doesn't need to be GPLv2 (or later). Furthermore the contributors of
the subsystem respect the individual licenses of the files through the
Developers Certificate of Origin, which tells the developers what the
meaning of Signed-off-by means.

  Luis