from:"Luis R. Rodriguez"

On Mon, Jun 22, 2015 at 09:06:41AM +0200, Borislav Petkov wrote:
 On Mon, Jun 22, 2015 at 03:01:38AM +0200, Luis R. Rodriguez wrote:
  We can certainly replace the WARN() with pr_warn(), I don't see
  how its confusing though as its a run time real issue. Either
  way whatever you recommend is fine by me.
 
 Yeah, it confused the 0day robot at least. :-)
 
 But maybe because it cannot really read. But I've experienced cases
 where people don't read too, see *a* splat and raise the alarm. So yeah,
 I think a simple pr_warn would be much better.

OK I'll submit a follow up fix and say the robot reported it :)

 Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in

[PATCH 1/2] x86/mm/pat, drivers/infiniband/ipath: replace WARN() with pr_warn()

From: Luis R. Rodriguez mcg...@suse.com

On built-in kernels this will always splat. Fix that.

Reported-by: Fengguang Wu fengguang...@intel.com [0-day test robot]
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/infiniband/hw/ipath/ipath_driver.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/ipath/ipath_driver.c 
b/drivers/infiniband/hw/ipath/ipath_driver.c
index 2d7e503..871dbe5 100644
--- a/drivers/infiniband/hw/ipath/ipath_driver.c
+++ b/drivers/infiniband/hw/ipath/ipath_driver.c
@@ -31,6 +31,8 @@
  * SOFTWARE.
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME :  fmt
+
 #include linux/sched.h
 #include linux/spinlock.h
 #include linux/idr.h
@@ -399,8 +401,8 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
u32 bar0 = 0, bar1 = 0;
 
 #ifdef CONFIG_X86_64
-   if (WARN(pat_enabled(),
-ipath needs PAT disabled, boot with nopat kernel 
parameter\n)) {
+   if (pat_enabled()) {
+   pr_warn(ipath needs PAT disabled, boot with nopat kernel 
parameter\n);
ret = -ENODEV;
goto bail;
}
-- 
2.3.2.209.gd67f9d5.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-media in

[PATCH 0/2] x86/mm/pat: don't use WARN for nopat requirement

From: Luis R. Rodriguez mcg...@suse.com

Mauro, Doug,

The 0-day robot found using WARN() on built-in kernels confusing. Upon
further thought pr_warn() is better and will likely also not confuse
humans too.

Boris, provided maintainers Ack, please consider these patches.

These depend on pat_enabled() exported symbol which went in through
the x86 tree, so I suppose this also needs to go through there. This
is an example issue of cross-tree collateral evolution follow ups,
one reason why I punted the a RFD and proposal for a linux-oven [0].
In that regard I suppose follow ups like these would need to go through
that tree as well.

[0] http://lkml.kernel.org/r/20150619231255.gc7...@garbanzo.do-not-panic.com

Luis R. Rodriguez (2):
  x86/mm/pat, drivers/infiniband/ipath: replace WARN() with pr_warn()
  x86/mm/pat, drivers/media/ivtv: replace WARN() with pr_warn()

 drivers/infiniband/hw/ipath/ipath_driver.c | 6 --
 drivers/media/pci/ivtv/ivtvfb.c| 6 --
 2 files changed, 8 insertions(+), 4 deletions(-)

-- 
2.3.2.209.gd67f9d5.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-media in

[PATCH 2/2] x86/mm/pat, drivers/media/ivtv: replace WARN() with pr_warn()

From: Luis R. Rodriguez mcg...@suse.com

On built-in kernels this will always splat. Fix that.

Reported-by: Fengguang Wu fengguang...@intel.com [0-day test robot]
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/media/pci/ivtv/ivtvfb.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 4cb365d..6f0c364 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -38,6 +38,8 @@
 Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME :  fmt
+
 #include linux/module.h
 #include linux/kernel.h
 #include linux/fb.h
@@ -1266,8 +1268,8 @@ static int __init ivtvfb_init(void)
int err;
 
 #ifdef CONFIG_X86_64
-   if (WARN(pat_enabled(),
-ivtvfb needs PAT disabled, boot with nopat kernel 
parameter\n)) {
+   if (pat_enabled()) {
+   pr_warn(ivtvfb needs PAT disabled, boot with nopat kernel 
parameter\n);
return -ENODEV;
}
 #endif
-- 
2.3.2.209.gd67f9d5.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-media in

Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()

2015-06-21 Thread Luis R. Rodriguez

On Sun, Jun 21, 2015 at 10:41:20PM +0200, Borislav Petkov wrote:
 On Sun, Jun 21, 2015 at 10:23:48PM +0200, Luis R. Rodriguez wrote:
  Nope, well the driver requires huge amounts of work to work with PAT,
  that work will likely never be done, so hence the warning. Its our
  compromise as only 2 drivers will live on Linux like this and they are
  both old and rare.
 
 Hmm, so wasn't the possibility discussed to fail loading 

It will fail load.

 instead and
 issue a single-line pr_warn() when PAT is enabled? 

During review no one opposed the idea of having the warn
as its a load thing, not a compile thing, and a user
that does not get their driver loaded should know why,
otherwise its not clear.

 Those big WARN() splats will only confuse people...

We can certainly replace the WARN() with pr_warn(), I don't see
how its confusing though as its a run time real issue. Either
way whatever you recommend is fine by me.

 Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in

Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()

2015-06-21 Thread Luis R. Rodriguez

On Sat, Jun 20, 2015 at 01:08:44PM +0200, Borislav Petkov wrote:
 On Sat, Jun 20, 2015 at 03:17:56PM +0800, Fengguang Wu wrote:
  Greetings,
  
  0day kernel testing robot got the below dmesg and the first bad commit is
  
  git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
  
  commit 1bf1735b478008c30acaff18ec6f4a3ff211c28a
  Author: Luis R. Rodriguez mcg...@suse.com
  AuthorDate: Mon Jun 15 10:28:16 2015 +0200
  Commit: Ingo Molnar mi...@kernel.org
  CommitDate: Thu Jun 18 11:23:41 2015 +0200
  
  x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add() and require PAT 
  disabled
 
 ...
 
  [   12.956506] ivtv: Start initialization, version 1.4.3
  [   12.958238] ivtv: End initialization
  [   12.959438] [ cut here ]
  [   12.974076] WARNING: CPU: 0 PID: 1 at 
  drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init+0x32/0xa3()
  [   12.978017] ivtvfb needs PAT disabled, boot with nopat kernel parameter
 
 Warning says it all. You need to boot with nopat. Apparently, those
 devices are very seldom now and users should boot with nopat.

Indeed.

 Luis, what is the plan, is this driver supposed to be converted to
 reserve_memtype(..., _PAGE_CACHE_MODE_WC, ...) at some point?

Nope, well the driver requires huge amounts of work to work with PAT,
that work will likely never be done, so hence the warning. Its our
compromise as only 2 drivers will live on Linux like this and they are
both old and rare.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in

Re: [PATCH v6 0/3] linux: address broken PAT drivers

On Mon, Jun 08, 2015 at 09:57:12PM -0300, Mauro Carvalho Chehab wrote:
 Em Mon, 08 Jun 2015 17:20:19 -0700
 Luis R. Rodriguez mcg...@do-not-panic.com escreveu:
 
  From: Luis R. Rodriguez mcg...@suse.com
  
  Mauro,
  
  since the ivtv patch is already acked by the driver maintainer
  and depends on an x86 symbol that went through Boris' tree are you
  OK in it going through Boris' tree?
 
 Sure. I just find a minor issues there. After they got solved, feel
 free to submit to Boris with my ack.

OK thanks, I just fixed that, will send now to Boris.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 1/3] ivtv: use arch_phys_wc_add() and require PAT disabled

From: Luis R. Rodriguez mcg...@suse.com

We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.

In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.

This is a worthy comprmise given that the hardware is
really rare these days, and perhaps only some lost souls
in some third world country are expected to be using this
feature of the device driver.

Acked-by: Andy Walls awa...@md.metrocast.net
Cc: Andy Walls awa...@md.metrocast.net
Cc: Doug Ledford dledf...@redhat.com
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Mel Gorman mgor...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Borislav Petkov b...@suse.de
Cc: Davidlohr Bueso dbu...@suse.de
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/media/pci/ivtv/Kconfig  |  3 +++
 drivers/media/pci/ivtv/ivtvfb.c | 58 -
 2 files changed, 26 insertions(+), 35 deletions(-)

diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index dd6ee57e..b2a7f88 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
  This is used in the Hauppauge PVR-350 card. There is a driver
  homepage at http://www.ivtvdriver.org.
 
+ If you have this hardware you will need to boot with PAT disabled
+ on your x86 systems, use the nopat kernel parameter.
+
  To compile this driver as a module, choose M here: the
  module will be called ivtvfb.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..7685ae3 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,8 +44,8 @@
 #include linux/ivtvfb.h
 #include linux/slab.h
 
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
 #endif
 
 #include ivtv-driver.h
@@ -155,12 +155,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
 
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+   int wc_cookie;
 
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
 static int ivtvfb_init_io(struct ivtv *itv)
 {
struct osd_info *oi = itv-osd_info;
+   /* Find the largest power of two that maps the whole buffer */
+   int size_shift = 31;
 
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1132,29 +1133,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
 
-#ifdef CONFIG_MTRR
-   {
-   /* Find the largest power of two that maps the whole buffer */
-   int size_shift = 31;
-
-   while (!(oi-video_buffer_size  (1  size_shift))) {
-   size_shift--;
-   }
-   size_shift++;
-   oi-fb_start_aligned_physaddr = oi-video_pbase  ~((1  
size_shift) - 1);
-   oi-fb_end_aligned_physaddr = oi-video_pbase + 
oi-video_buffer_size;
-   oi-fb_end_aligned_physaddr += (1  size_shift) - 1;
-   oi-fb_end_aligned_physaddr = ~((1  size_shift) - 1);
-   if (mtrr_add(oi-fb_start_aligned_physaddr,
-   oi-fb_end_aligned_physaddr - 
oi-fb_start_aligned_physaddr

[PATCH v6 0/3] linux: address broken PAT drivers

From: Luis R. Rodriguez mcg...@suse.com

Mauro,

since the ivtv patch is already acked by the driver maintainer
and depends on an x86 symbol that went through Boris' tree are you
OK in it going through Boris' tree?

Boris,

provided the outcome of the above maintainer's preference for you
to merge these please consider these patches for your tree. The
maintainer path is the only thing pending for the 1 ivtv patch.
The Infiniband subsystem maintainer, Doug, already provided his
ACK for the ipath driver and for this to go through you.

Luis R. Rodriguez (3):
  ivtv: use arch_phys_wc_add() and require PAT disabled
  IB/ipath: add counting for MTRR
  IB/ipath: use arch_phys_wc_add() and require PAT disabled

 drivers/infiniband/hw/ipath/Kconfig   |  3 ++
 drivers/infiniband/hw/ipath/ipath_driver.c| 18 ++---
 drivers/infiniband/hw/ipath/ipath_kernel.h|  4 +-
 drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 43 +---
 drivers/media/pci/ivtv/Kconfig|  3 ++
 drivers/media/pci/ivtv/ivtvfb.c   | 58 +++
 6 files changed, 52 insertions(+), 77 deletions(-)

-- 
2.3.2.209.gd67f9d5.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 3/3] IB/ipath: use arch_phys_wc_add() and require PAT disabled

From: Luis R. Rodriguez mcg...@suse.com

We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.

In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.

This is a worthy compromise given that the ipath device
driver powers the old HTX bus cards that only work in
AMD systems, while the newer IB/qib device driver
powers all PCI-e cards. The ipath device driver is
obsolete, hardware hard to find and because of this
this its a reasonable compromise to make to require
users of ipath to boot with nopat.

Acked-by: Doug Ledford dledf...@redhat.com
Cc: Doug Ledford dledf...@redhat.com
Cc: Andy Walls awa...@md.metrocast.net
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Sean Hefty sean.he...@intel.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Cc: Mike Marciniszyn mike.marcinis...@intel.com
Cc: Roland Dreier rol...@purestorage.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Mel Gorman mgor...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Borislav Petkov b...@suse.de
Cc: Davidlohr Bueso dbu...@suse.de
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/infiniband/hw/ipath/Kconfig   |  3 ++
 drivers/infiniband/hw/ipath/ipath_driver.c| 18 +++
 drivers/infiniband/hw/ipath/ipath_kernel.h|  4 +--
 drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 43 ++-
 4 files changed, 26 insertions(+), 42 deletions(-)

diff --git a/drivers/infiniband/hw/ipath/Kconfig 
b/drivers/infiniband/hw/ipath/Kconfig
index 1d9bb11..8fe54ff 100644
--- a/drivers/infiniband/hw/ipath/Kconfig
+++ b/drivers/infiniband/hw/ipath/Kconfig
@@ -9,3 +9,6 @@ config INFINIBAND_IPATH
as IP-over-InfiniBand as well as with userspace applications
(in conjunction with InfiniBand userspace access).
For QLogic PCIe QLE based cards, use the QIB driver instead.
+
+   If you have this hardware you will need to boot with PAT disabled
+   on your x86-64 systems, use the nopat kernel parameter.
diff --git a/drivers/infiniband/hw/ipath/ipath_driver.c 
b/drivers/infiniband/hw/ipath/ipath_driver.c
index bd0caed..441cfe5 100644
--- a/drivers/infiniband/hw/ipath/ipath_driver.c
+++ b/drivers/infiniband/hw/ipath/ipath_driver.c
@@ -42,6 +42,9 @@
 #include linux/bitmap.h
 #include linux/slab.h
 #include linux/module.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
+#endif
 
 #include ipath_kernel.h
 #include ipath_verbs.h
@@ -395,6 +398,14 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
unsigned long long addr;
u32 bar0 = 0, bar1 = 0;
 
+#ifdef CONFIG_X86_64
+   if (WARN(pat_enabled(),
+ipath needs PAT disabled, boot with nopat kernel 
parameter\n)) {
+   ret = EINVAL;
+   goto bail;
+   }
+#endif
+
dd = ipath_alloc_devdata(pdev);
if (IS_ERR(dd)) {
ret = PTR_ERR(dd);
@@ -542,6 +553,7 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
dd-ipath_kregbase = __ioremap(addr, len,
(_PAGE_NO_CACHE|_PAGE_WRITETHRU));
 #else
+   /* XXX: split this properly to enable on PAT */
dd-ipath_kregbase = ioremap_nocache(addr, len);
 #endif
 
@@ -587,12 +599,8 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
 
ret = ipath_enable_wc(dd);
 
-   if (ret) {
-   ipath_dev_err(dd, Write combining not enabled 
- (err %d): performance may be poor\n,
- -ret);
+   if (ret)
ret = 0;
-   }
 
ipath_verify_pioperf

[PATCH v6 2/3] IB/ipath: add counting for MTRR

From: Luis R. Rodriguez mcg...@suse.com

There is no good reason not to, we eventually delete it as well.

Cc: Toshi Kani toshi.k...@hp.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c 
b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
index 4ad0b93..70c1f3a 100644
--- a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
+++ b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
@@ -127,7 +127,7 @@ int ipath_enable_wc(struct ipath_devdata *dd)
   (addr %llx, len=0x%llx)\n,
   (unsigned long long) pioaddr,
   (unsigned long long) piolen);
-   cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
+   cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
if (cookie  0) {
{
dev_info(dd-pcidev-dev,
-- 
2.3.2.209.gd67f9d5.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/3] linux: address broken PAT drivers

On Thu, Jun 11, 2015 at 10:49:59AM -0700, Luis R. Rodriguez wrote:
 From: Luis R. Rodriguez mcg...@suse.com
 
 Mauro,
 
 since the ivtv patch is already acked by the driver maintainer
 and depends on an x86 symbol that went through Boris' tree are you
 OK in it going through Boris' tree?

Sorry I resent v6 by mistake, will send the v7 with the fix you requested.

 Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 3/3] IB/ipath: use arch_phys_wc_add() and require PAT disabled

From: Luis R. Rodriguez mcg...@suse.com

We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.

In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.

This is a worthy compromise given that the ipath device
driver powers the old HTX bus cards that only work in
AMD systems, while the newer IB/qib device driver
powers all PCI-e cards. The ipath device driver is
obsolete, hardware hard to find and because of this
this its a reasonable compromise to make to require
users of ipath to boot with nopat.

Acked-by: Doug Ledford dledf...@redhat.com
Cc: Doug Ledford dledf...@redhat.com
Cc: Andy Walls awa...@md.metrocast.net
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Sean Hefty sean.he...@intel.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Cc: Mike Marciniszyn mike.marcinis...@intel.com
Cc: Roland Dreier rol...@purestorage.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/infiniband/hw/ipath/Kconfig   |  3 ++
 drivers/infiniband/hw/ipath/ipath_driver.c| 18 +++
 drivers/infiniband/hw/ipath/ipath_kernel.h|  4 +--
 drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 43 ++-
 4 files changed, 26 insertions(+), 42 deletions(-)

diff --git a/drivers/infiniband/hw/ipath/Kconfig 
b/drivers/infiniband/hw/ipath/Kconfig
index 1d9bb11..8fe54ff 100644
--- a/drivers/infiniband/hw/ipath/Kconfig
+++ b/drivers/infiniband/hw/ipath/Kconfig
@@ -9,3 +9,6 @@ config INFINIBAND_IPATH
as IP-over-InfiniBand as well as with userspace applications
(in conjunction with InfiniBand userspace access).
For QLogic PCIe QLE based cards, use the QIB driver instead.
+
+   If you have this hardware you will need to boot with PAT disabled
+   on your x86-64 systems, use the nopat kernel parameter.
diff --git a/drivers/infiniband/hw/ipath/ipath_driver.c 
b/drivers/infiniband/hw/ipath/ipath_driver.c
index bd0caed..2d7e503 100644
--- a/drivers/infiniband/hw/ipath/ipath_driver.c
+++ b/drivers/infiniband/hw/ipath/ipath_driver.c
@@ -42,6 +42,9 @@
 #include linux/bitmap.h
 #include linux/slab.h
 #include linux/module.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
+#endif
 
 #include ipath_kernel.h
 #include ipath_verbs.h
@@ -395,6 +398,14 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
unsigned long long addr;
u32 bar0 = 0, bar1 = 0;
 
+#ifdef CONFIG_X86_64
+   if (WARN(pat_enabled(),
+ipath needs PAT disabled, boot with nopat kernel 
parameter\n)) {
+   ret = -ENODEV;
+   goto bail;
+   }
+#endif
+
dd = ipath_alloc_devdata(pdev);
if (IS_ERR(dd)) {
ret = PTR_ERR(dd);
@@ -542,6 +553,7 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
dd-ipath_kregbase = __ioremap(addr, len,
(_PAGE_NO_CACHE|_PAGE_WRITETHRU));
 #else
+   /* XXX: split this properly to enable on PAT */
dd-ipath_kregbase = ioremap_nocache(addr, len);
 #endif
 
@@ -587,12 +599,8 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
 
ret = ipath_enable_wc(dd);
 
-   if (ret) {
-   ipath_dev_err(dd, Write combining not enabled 
- (err %d): performance may be poor\n,
- -ret);
+   if (ret)
ret = 0;
-   }
 
ipath_verify_pioperf(dd);
 
diff --git a/drivers/infiniband/hw/ipath/ipath_kernel.h 
b/drivers/infiniband/hw/ipath/ipath_kernel.h
index e08db70..f0f9471 100644
--- a/drivers

[PATCH v7 0/3] linux: address broken PAT drivers

From: Luis R. Rodriguez mcg...@suse.com

Boris,

the following patches make use of the newly exported pat_enabled()
which went in through your tree. All driver and respective subsystem
maintainers have Acked these patches and are OK for them to go in through
your tree. Please let me know if there any issues or questions.

This v7 series goes with the return value fixed to be negative, this
was spotted by Mauro on the ivtv driver, I also spotted this then on
the ipath driver so fixed that there too in this series. The v7 also
goes with a small change on language on the Kconfig for the ivtv as
requested by Mauro. The v7 also goes with a small change on language
on the Kconfig for the ivtv as requested by Mauro.

Luis R. Rodriguez (3):
  ivtv: use arch_phys_wc_add() and require PAT disabled
  IB/ipath: add counting for MTRR
  IB/ipath: use arch_phys_wc_add() and require PAT disabled

 drivers/infiniband/hw/ipath/Kconfig   |  3 ++
 drivers/infiniband/hw/ipath/ipath_driver.c| 18 ++---
 drivers/infiniband/hw/ipath/ipath_kernel.h|  4 +-
 drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 43 +---
 drivers/media/pci/ivtv/Kconfig|  3 ++
 drivers/media/pci/ivtv/ivtvfb.c   | 58 +++
 6 files changed, 52 insertions(+), 77 deletions(-)

-- 
2.3.2.209.gd67f9d5.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 1/3] ivtv: use arch_phys_wc_add() and require PAT disabled

From: Luis R. Rodriguez mcg...@suse.com

We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.

In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.

This is a worthy compromise given that the hardware is
really rare these days, and perhaps only some lost souls
in some third world country are expected to be using this
feature of the device driver.

Acked-by: Andy Walls awa...@md.metrocast.net
Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Andy Walls awa...@md.metrocast.net
Cc: Doug Ledford dledf...@redhat.com
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Borislav Petkov b...@suse.de
Cc: konrad.w...@oracle.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-media@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/media/pci/ivtv/Kconfig  |  3 +++
 drivers/media/pci/ivtv/ivtvfb.c | 58 -
 2 files changed, 26 insertions(+), 35 deletions(-)

diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index dd6ee57e..6e5867c 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
  This is used in the Hauppauge PVR-350 card. There is a driver
  homepage at http://www.ivtvdriver.org.
 
+ In order to use this module, you will need to boot with PAT disabled
+ on x86 systems, using the nopat kernel parameter.
+
  To compile this driver as a module, choose M here: the
  module will be called ivtvfb.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..4cb365d 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,8 +44,8 @@
 #include linux/ivtvfb.h
 #include linux/slab.h
 
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
 #endif
 
 #include ivtv-driver.h
@@ -155,12 +155,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
 
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+   int wc_cookie;
 
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
 static int ivtvfb_init_io(struct ivtv *itv)
 {
struct osd_info *oi = itv-osd_info;
+   /* Find the largest power of two that maps the whole buffer */
+   int size_shift = 31;
 
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1132,29 +1133,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
 
-#ifdef CONFIG_MTRR
-   {
-   /* Find the largest power of two that maps the whole buffer */
-   int size_shift = 31;
-
-   while (!(oi-video_buffer_size  (1  size_shift))) {
-   size_shift--;
-   }
-   size_shift++;
-   oi-fb_start_aligned_physaddr = oi-video_pbase  ~((1  
size_shift) - 1);
-   oi-fb_end_aligned_physaddr = oi-video_pbase + 
oi-video_buffer_size;
-   oi-fb_end_aligned_physaddr += (1  size_shift) - 1;
-   oi-fb_end_aligned_physaddr = ~((1  size_shift) - 1);
-   if (mtrr_add(oi-fb_start_aligned_physaddr,
-   oi-fb_end_aligned_physaddr - 
oi-fb_start_aligned_physaddr,
-MTRR_TYPE_WRCOMB, 1)  0) {
-   IVTVFB_INFO(disabled mttr\n);
-   oi-fb_start_aligned_physaddr = 0;
-   oi-fb_end_aligned_physaddr = 0

[PATCH v7 2/3] IB/ipath: add counting for MTRR

From: Luis R. Rodriguez mcg...@suse.com

There is no good reason not to, we eventually delete it as well.

Cc: Toshi Kani toshi.k...@hp.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c 
b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
index 4ad0b93..70c1f3a 100644
--- a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
+++ b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
@@ -127,7 +127,7 @@ int ipath_enable_wc(struct ipath_devdata *dd)
   (addr %llx, len=0x%llx)\n,
   (unsigned long long) pioaddr,
   (unsigned long long) piolen);
-   cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
+   cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
if (cookie  0) {
{
dev_info(dd-pcidev-dev,
-- 
2.3.2.209.gd67f9d5.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RIP MTRR - status update for upcoming v4.2

The series to bury direct MTRR use is almost all in and on its way to
v4.2. As the pending series continue slowly to be merged I wanted to
take the time to reiterate the justification for these changes in
hopes it may help those still reviewing some of these patches which
are pending and to help document all these changes. There are also
some series which depend on symbols now exported through some other
subsystem trees so coordination is needed there. In those cases we
have the option there to sit and wait for the exported symbols to
trickle in through v4.2 and later on v4.3 finalize the changes, or to
let some of the depending changes to in through other subsystem trees.
I don't consider the coordination required difficult to handle so
would prefer to see the changes in for v4.2 to be able to put a nail
on the MTRR coffin sooner rather than later and to also help get more
testing out of this sooner rather than later. PAT is known to have
errata for some CPUs so hearing reports of issues with PAT would be
very valuable. I'll let maintainers decide on how that trickles
through. To help with all this towards the end I provide a status of
all the pending patches to get this work completed.

Justification
=

We want to bury direct use of MTRR code because:

a) MTRR is x86 specific, this means all existing MTRR code is #idef'd
out. PAT support for x86 was implemented using architecture agnostic
APIs, this enables other architectures to provide support for a
similar write-combining feature, and removes the nasty #idef eyesores.
MTRR should be seen as a first step temporary architectural evolution
to what PAT eventually became on x86.

b) We have a long term goal to change the default behavior of
ioremap_nocache() and pci_mmap_page_range() to use PAT strong UC,
right now we cannot do this, but after all drivers are converted (all
these series I've been posting) we expect to be able to make the
change. Making a change to strong UC on these two calls can only
happen after a period of time of having Linux bake with all these
changes merged and in place. How many kernels we will want Linux baked
with all these transformations to arch_phys before making a change to
ioremap_nocache() and pci_mmap_page_range() is up to x86 folks. There
are other gains possible with this but I welcome others to chime in
here with what gains we can expect from this.

c) MTRR acts on physical addresses and requires power-of-two
alignment, on both the base used and size, this limits the flexibility
for MTRR use. For a good example of its limitations refer to the
patches which change the atyfb driver from using MTRR to PAT.

d) MTRR is known to be unreliable, it can at times not work even on
modern systems.

e) There is a limit to how many MTRRs you can use on a system. If
using a large number of devices with MTRR support you will quickly run
out of MTRRs. This is why originally Andy Lutomirski ended up adding
the arch_phys_wc_add() API, in order to take advantage of PAT which is
*not* bound to the same limitations as MTRRs are.

f) PAT has been available for quite a long time, since Pentium III
(circa 1999) and newer, but having PAT enabled does not restrict use
of MTRR and because of this some systems may end up then combining
MTRR and PAT. I do not believe this wasn't an original highly expected
wide use situation, it technically should work to combine both but
there might be issues with interactions between both, exactly what
issues can exist or have existed remains quite unclear as MTRR in and
of itself has been known to be unreliable anyway. If possible its best
to just be binary about this and only use MTRR if and only if
necessary because of the other issues known with MTRR.

g) Linux has support for Xen PV domains using PAT, this was introduced
by Juergen via v3.19 via commit 47591df50512 (xen: Support Xen
pv-domains using PAT). Since MTRR is old we don't want to add MTRR
support into Xen on Linux, instead since Linux now supports PV domains
with PAT we can take full advantage of write combining for PV domains
on Xen provided all Linux drivers are converted to use PAT properly.a
framebuffer folks's ACK

Review of the changes


Most of the series has consisted of driver transformations using
Coccinelle SmPL patches to transform existing code which access MTRR
APIs directly to the architecture agnostic write-combining calls.
Other patches extend bus subsystems to make available new
write-combining architecture agnostic APIs. Other patches have
consisted of extending architecture agnostic APIs to help work around
old MTRR hacks -- this was perhaps the hardest task and took quite a
bit of time and review as it required review of implications of all
combinatorial possibilities with MTRR and PAT, which also got
documented as part of the series. In the end it was also determined
some drivers required substantial work to be able to work properly
with PAT, the atyfb driver is an example driver which had the homework

Re: RIP MTRR - status update for upcoming v4.2

On Thu, Jun 11, 2015 at 05:23:16PM -0600, Toshi Kani wrote:
 On Thu, 2015-06-11 at 13:36 -0700, Luis R. Rodriguez wrote:
  :
  Pending RIP MTRR patches
  
  
  There are a few pending series so I wanted to provide a status update
  on those series.
  
  mtrr: bury MTRR - unexport mtrr_add() and mtrr_del()
  
  This is the nail on the MTRR coffin, it will prevent future direct
  access to MTRR code. This will not be posted until all of the below
  patches are in and merged. A possible next step here might be to
  consider separating PAT code from MTRR code and making PAT a first
  class citizen, enabling distributions to disable MTRR code in the
  future. I thought this was possible but for some reason I recently
  thought that there was one possible issue to make this happen. I
  suppose we won't know unless we try, unless of course someone already
  knows, Toshi?
 
 There are two usages on MTRRs:
  1) MTRR entries set by firmware
  2) MTRR entries set by OS drivers
 
 We can obsolete 2), but we have no control over 1).  As UEFI firmwares
 also set this up, this usage will continue to stay.  So, we should not
 get rid of the MTRR code that looks up the MTRR entries, while we have
 no need to modify them.
 
 Such MTRR entries provide safe guard to /dev/mem, which allows
 privileged user to access a range that may require UC mapping while
 the /dev/mem driver blindly maps it with WB.  MTRRs converts WB to UC in
 such a case.
 
 UEFI memory table has memory attribute, which describes cache types
 supported in physical memory ranges.  However, this information gets
 lost when it it is converted to e820 table.

Is there no way to modify CPU capability bits upon boot and kick UEFI
to re-evaluate ? In such UEFI cases what happens for instance when
Xen is used which does not support MTRR?

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 3/3] IB/ipath: use arch_phys_wc_add() and require PAT disabled

From: Luis R. Rodriguez mcg...@suse.com

We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.

In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.

This is a worthy compromise given that the ipath device
driver powers the old HTX bus cards that only work in
AMD systems, while the newer IB/qib device driver
powers all PCI-e cards. The ipath device driver is
obsolete, hardware hard to find and because of this
this its a reasonable compromise to make to require
users of ipath to boot with nopat.

Acked-by: Doug Ledford dledf...@redhat.com
Cc: Doug Ledford dledf...@redhat.com
Cc: Andy Walls awa...@md.metrocast.net
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Sean Hefty sean.he...@intel.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Cc: Mike Marciniszyn mike.marcinis...@intel.com
Cc: Roland Dreier rol...@purestorage.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Mel Gorman mgor...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Borislav Petkov b...@suse.de
Cc: Davidlohr Bueso dbu...@suse.de
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/infiniband/hw/ipath/Kconfig   |  3 ++
 drivers/infiniband/hw/ipath/ipath_driver.c| 18 +++
 drivers/infiniband/hw/ipath/ipath_kernel.h|  4 +--
 drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 43 ++-
 4 files changed, 26 insertions(+), 42 deletions(-)

diff --git a/drivers/infiniband/hw/ipath/Kconfig 
b/drivers/infiniband/hw/ipath/Kconfig
index 1d9bb11..8fe54ff 100644
--- a/drivers/infiniband/hw/ipath/Kconfig
+++ b/drivers/infiniband/hw/ipath/Kconfig
@@ -9,3 +9,6 @@ config INFINIBAND_IPATH
as IP-over-InfiniBand as well as with userspace applications
(in conjunction with InfiniBand userspace access).
For QLogic PCIe QLE based cards, use the QIB driver instead.
+
+   If you have this hardware you will need to boot with PAT disabled
+   on your x86-64 systems, use the nopat kernel parameter.
diff --git a/drivers/infiniband/hw/ipath/ipath_driver.c 
b/drivers/infiniband/hw/ipath/ipath_driver.c
index bd0caed..441cfe5 100644
--- a/drivers/infiniband/hw/ipath/ipath_driver.c
+++ b/drivers/infiniband/hw/ipath/ipath_driver.c
@@ -42,6 +42,9 @@
 #include linux/bitmap.h
 #include linux/slab.h
 #include linux/module.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
+#endif
 
 #include ipath_kernel.h
 #include ipath_verbs.h
@@ -395,6 +398,14 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
unsigned long long addr;
u32 bar0 = 0, bar1 = 0;
 
+#ifdef CONFIG_X86_64
+   if (WARN(pat_enabled(),
+ipath needs PAT disabled, boot with nopat kernel 
parameter\n)) {
+   ret = EINVAL;
+   goto bail;
+   }
+#endif
+
dd = ipath_alloc_devdata(pdev);
if (IS_ERR(dd)) {
ret = PTR_ERR(dd);
@@ -542,6 +553,7 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
dd-ipath_kregbase = __ioremap(addr, len,
(_PAGE_NO_CACHE|_PAGE_WRITETHRU));
 #else
+   /* XXX: split this properly to enable on PAT */
dd-ipath_kregbase = ioremap_nocache(addr, len);
 #endif
 
@@ -587,12 +599,8 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
 
ret = ipath_enable_wc(dd);
 
-   if (ret) {
-   ipath_dev_err(dd, Write combining not enabled 
- (err %d): performance may be poor\n,
- -ret);
+   if (ret)
ret = 0;
-   }
 
ipath_verify_pioperf

[PATCH v6 2/3] IB/ipath: add counting for MTRR

From: Luis R. Rodriguez mcg...@suse.com

There is no good reason not to, we eventually delete it as well.

Cc: Toshi Kani toshi.k...@hp.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c 
b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
index 4ad0b93..70c1f3a 100644
--- a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
+++ b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
@@ -127,7 +127,7 @@ int ipath_enable_wc(struct ipath_devdata *dd)
   (addr %llx, len=0x%llx)\n,
   (unsigned long long) pioaddr,
   (unsigned long long) piolen);
-   cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
+   cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
if (cookie  0) {
{
dev_info(dd-pcidev-dev,
-- 
2.3.2.209.gd67f9d5.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 0/3] linux: address broken PAT drivers

From: Luis R. Rodriguez mcg...@suse.com

Mauro,

since the ivtv patch is already acked by the driver maintainer
and depends on an x86 symbol that went through Boris' tree are you
OK in it going through Boris' tree?

Boris,

provided the outcome of the above maintainer's preference for you
to merge these please consider these patches for your tree. The
maintainer path is the only thing pending for the 1 ivtv patch.
The Infiniband subsystem maintainer, Doug, already provided his
ACK for the ipath driver and for this to go through you.

Luis R. Rodriguez (3):
  ivtv: use arch_phys_wc_add() and require PAT disabled
  IB/ipath: add counting for MTRR
  IB/ipath: use arch_phys_wc_add() and require PAT disabled

 drivers/infiniband/hw/ipath/Kconfig   |  3 ++
 drivers/infiniband/hw/ipath/ipath_driver.c| 18 ++---
 drivers/infiniband/hw/ipath/ipath_kernel.h|  4 +-
 drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 43 +---
 drivers/media/pci/ivtv/Kconfig|  3 ++
 drivers/media/pci/ivtv/ivtvfb.c   | 58 +++
 6 files changed, 52 insertions(+), 77 deletions(-)

-- 
2.3.2.209.gd67f9d5.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 1/3] ivtv: use arch_phys_wc_add() and require PAT disabled

From: Luis R. Rodriguez mcg...@suse.com

We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.

In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.

This is a worthy comprmise given that the hardware is
really rare these days, and perhaps only some lost souls
in some third world country are expected to be using this
feature of the device driver.

Acked-by: Andy Walls awa...@md.metrocast.net
Cc: Andy Walls awa...@md.metrocast.net
Cc: Doug Ledford dledf...@redhat.com
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Mel Gorman mgor...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Borislav Petkov b...@suse.de
Cc: Davidlohr Bueso dbu...@suse.de
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/media/pci/ivtv/Kconfig  |  3 +++
 drivers/media/pci/ivtv/ivtvfb.c | 58 -
 2 files changed, 26 insertions(+), 35 deletions(-)

diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index dd6ee57e..b2a7f88 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
  This is used in the Hauppauge PVR-350 card. There is a driver
  homepage at http://www.ivtvdriver.org.
 
+ If you have this hardware you will need to boot with PAT disabled
+ on your x86 systems, use the nopat kernel parameter.
+
  To compile this driver as a module, choose M here: the
  module will be called ivtvfb.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..7685ae3 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,8 +44,8 @@
 #include linux/ivtvfb.h
 #include linux/slab.h
 
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
 #endif
 
 #include ivtv-driver.h
@@ -155,12 +155,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
 
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+   int wc_cookie;
 
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
 static int ivtvfb_init_io(struct ivtv *itv)
 {
struct osd_info *oi = itv-osd_info;
+   /* Find the largest power of two that maps the whole buffer */
+   int size_shift = 31;
 
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1132,29 +1133,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
 
-#ifdef CONFIG_MTRR
-   {
-   /* Find the largest power of two that maps the whole buffer */
-   int size_shift = 31;
-
-   while (!(oi-video_buffer_size  (1  size_shift))) {
-   size_shift--;
-   }
-   size_shift++;
-   oi-fb_start_aligned_physaddr = oi-video_pbase  ~((1  
size_shift) - 1);
-   oi-fb_end_aligned_physaddr = oi-video_pbase + 
oi-video_buffer_size;
-   oi-fb_end_aligned_physaddr += (1  size_shift) - 1;
-   oi-fb_end_aligned_physaddr = ~((1  size_shift) - 1);
-   if (mtrr_add(oi-fb_start_aligned_physaddr,
-   oi-fb_end_aligned_physaddr - 
oi-fb_start_aligned_physaddr

[PATCH v5 4/6] ivtv: use arch_phys_wc_add() and require PAT disabled

2015-04-30 Thread Luis R. Rodriguez

From: Luis R. Rodriguez mcg...@suse.com

We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.

In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.

This is a worthy comprmise given that the hardware is
really rare these days, and perhaps only some lost souls
in some third world country are expected to be using this
feature of the device driver.

Acked-by: Andy Walls awa...@md.metrocast.net
Cc: Andy Walls awa...@md.metrocast.net
Cc: Doug Ledford dledf...@redhat.com
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Mel Gorman mgor...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Borislav Petkov b...@suse.de
Cc: Davidlohr Bueso dbu...@suse.de
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/media/pci/ivtv/Kconfig  |  3 +++
 drivers/media/pci/ivtv/ivtvfb.c | 58 -
 2 files changed, 26 insertions(+), 35 deletions(-)

diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index dd6ee57e..b2a7f88 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
  This is used in the Hauppauge PVR-350 card. There is a driver
  homepage at http://www.ivtvdriver.org.
 
+ If you have this hardware you will need to boot with PAT disabled
+ on your x86 systems, use the nopat kernel parameter.
+
  To compile this driver as a module, choose M here: the
  module will be called ivtvfb.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..7685ae3 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,8 +44,8 @@
 #include linux/ivtvfb.h
 #include linux/slab.h
 
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
 #endif
 
 #include ivtv-driver.h
@@ -155,12 +155,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
 
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+   int wc_cookie;
 
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
 static int ivtvfb_init_io(struct ivtv *itv)
 {
struct osd_info *oi = itv-osd_info;
+   /* Find the largest power of two that maps the whole buffer */
+   int size_shift = 31;
 
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1132,29 +1133,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
 
-#ifdef CONFIG_MTRR
-   {
-   /* Find the largest power of two that maps the whole buffer */
-   int size_shift = 31;
-
-   while (!(oi-video_buffer_size  (1  size_shift))) {
-   size_shift--;
-   }
-   size_shift++;
-   oi-fb_start_aligned_physaddr = oi-video_pbase  ~((1  
size_shift) - 1);
-   oi-fb_end_aligned_physaddr = oi-video_pbase + 
oi-video_buffer_size;
-   oi-fb_end_aligned_physaddr += (1  size_shift) - 1;
-   oi-fb_end_aligned_physaddr = ~((1  size_shift) - 1);
-   if (mtrr_add(oi-fb_start_aligned_physaddr,
-   oi-fb_end_aligned_physaddr - 
oi-fb_start_aligned_physaddr

[PATCH v4 6/8] ivtv: use arch_phys_wc_add() and require PAT disabled

2015-04-29 Thread Luis R. Rodriguez

From: Luis R. Rodriguez mcg...@suse.com

We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.

In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.

This is a worthy comprmise given that the hardware is
really rare these days, and perhaps only some lost souls
in some third world country are expected to be using this
feature of the device driver.

Acked-by: Andy Walls awa...@md.metrocast.net
Cc: Andy Walls awa...@md.metrocast.net
Cc: Doug Ledford dledf...@redhat.com
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Mel Gorman mgor...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Borislav Petkov b...@suse.de
Cc: Davidlohr Bueso dbu...@suse.de
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/media/pci/ivtv/Kconfig  |  3 +++
 drivers/media/pci/ivtv/ivtvfb.c | 58 -
 2 files changed, 26 insertions(+), 35 deletions(-)

diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index dd6ee57e..b2a7f88 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
  This is used in the Hauppauge PVR-350 card. There is a driver
  homepage at http://www.ivtvdriver.org.
 
+ If you have this hardware you will need to boot with PAT disabled
+ on your x86 systems, use the nopat kernel parameter.
+
  To compile this driver as a module, choose M here: the
  module will be called ivtvfb.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..7685ae3 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,8 +44,8 @@
 #include linux/ivtvfb.h
 #include linux/slab.h
 
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
 #endif
 
 #include ivtv-driver.h
@@ -155,12 +155,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
 
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+   int wc_cookie;
 
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
 static int ivtvfb_init_io(struct ivtv *itv)
 {
struct osd_info *oi = itv-osd_info;
+   /* Find the largest power of two that maps the whole buffer */
+   int size_shift = 31;
 
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1132,29 +1133,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
 
-#ifdef CONFIG_MTRR
-   {
-   /* Find the largest power of two that maps the whole buffer */
-   int size_shift = 31;
-
-   while (!(oi-video_buffer_size  (1  size_shift))) {
-   size_shift--;
-   }
-   size_shift++;
-   oi-fb_start_aligned_physaddr = oi-video_pbase  ~((1  
size_shift) - 1);
-   oi-fb_end_aligned_physaddr = oi-video_pbase + 
oi-video_buffer_size;
-   oi-fb_end_aligned_physaddr += (1  size_shift) - 1;
-   oi-fb_end_aligned_physaddr = ~((1  size_shift) - 1);
-   if (mtrr_add(oi-fb_start_aligned_physaddr,
-   oi-fb_end_aligned_physaddr - 
oi-fb_start_aligned_physaddr

[PATCH v2] ivtv: use arch_phys_wc_add() and require PAT disabled

2015-04-27 Thread Luis R. Rodriguez

From: Luis R. Rodriguez mcg...@suse.com

We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.

In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.

This is a worthy comprmise given that the hardware is
really rare these days, and perhaps only some lost souls
in some third world country are expected to be using this
feature of the device driver.

Cc: Andy Walls awa...@md.metrocast.net
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Mel Gorman mgor...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Borislav Petkov b...@suse.de
Cc: Davidlohr Bueso dbu...@suse.de
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---

This v2 moves the PAT bail out error check on to ivtvfb_init()
as per Andy's request. It also removes some comment about TODO
items for PAT.

 drivers/media/pci/ivtv/Kconfig  |  3 +++
 drivers/media/pci/ivtv/ivtvfb.c | 58 -
 2 files changed, 26 insertions(+), 35 deletions(-)

diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index dd6ee57e..b2a7f88 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
  This is used in the Hauppauge PVR-350 card. There is a driver
  homepage at http://www.ivtvdriver.org.
 
+ If you have this hardware you will need to boot with PAT disabled
+ on your x86 systems, use the nopat kernel parameter.
+
  To compile this driver as a module, choose M here: the
  module will be called ivtvfb.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..8761e3e 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,8 +44,8 @@
 #include linux/ivtvfb.h
 #include linux/slab.h
 
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
 #endif
 
 #include ivtv-driver.h
@@ -155,12 +155,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
 
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+   int wc_cookie;
 
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
 static int ivtvfb_init_io(struct ivtv *itv)
 {
struct osd_info *oi = itv-osd_info;
+   /* Find the largest power of two that maps the whole buffer */
+   int size_shift = 31;
 
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1132,29 +1133,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
 
-#ifdef CONFIG_MTRR
-   {
-   /* Find the largest power of two that maps the whole buffer */
-   int size_shift = 31;
-
-   while (!(oi-video_buffer_size  (1  size_shift))) {
-   size_shift--;
-   }
-   size_shift++;
-   oi-fb_start_aligned_physaddr = oi-video_pbase  ~((1  
size_shift) - 1);
-   oi-fb_end_aligned_physaddr = oi-video_pbase + 
oi-video_buffer_size;
-   oi-fb_end_aligned_physaddr += (1  size_shift) - 1;
-   oi-fb_end_aligned_physaddr = ~((1  size_shift) - 1);
-   if (mtrr_add(oi-fb_start_aligned_physaddr,
-   oi-fb_end_aligned_physaddr - 
oi

Re: [PATCH] [media] ivtv: use arch_phys_wc_add() and require PAT disabled

2015-04-27 Thread Luis R. Rodriguez

On Sat, Apr 25, 2015 at 07:12:05AM -0400, Andy Walls wrote:
 Hi Luis,
 
 Sorry for the late reply.
 
 Thank you for the patch! See my comments below:
 
 On Wed, 2015-04-22 at 12:33 -0700, Luis R. Rodriguez wrote:
  From: Luis R. Rodriguez mcg...@suse.com
  
  We are burrying direct access to MTRR code support on
  x86 in order to take advantage of PAT. In the future we
  also want to make the default behaviour of ioremap_nocache()
  to use strong UC, use of mtrr_add() on those systems
  would make write-combining void.
  
  In order to help both enable us to later make strong
  UC default and in order to phase out direct MTRR access
  code port the driver over to arch_phys_wc_add() and
  annotate that the device driver requires systems to
  boot with PAT disabled, with the nopat kernel parameter.
  
  This is a worthy comprmise given that the hardware is
  really rare these days,
 
 I'm OK with the compromise solution.  It makes sense.

OK great!

  diff --git a/drivers/media/pci/ivtv/ivtvfb.c 
  b/drivers/media/pci/ivtv/ivtvfb.c
  index 9ff1230..552408b 100644
  --- a/drivers/media/pci/ivtv/ivtvfb.c
  +++ b/drivers/media/pci/ivtv/ivtvfb.c
  @@ -1120,6 +1121,7 @@ static int ivtvfb_init_io(struct ivtv *itv)
  oi-video_buffer_size = 1704960;
   
  oi-video_pbase = itv-base_addr + IVTV_DECODER_OFFSET + 
  oi-video_rbase;
  +   /* XXX: split this for PAT */
 
 Please remove this comment. 

Done.

  @@ -1190,6 +1172,13 @@ static int ivtvfb_init_card(struct ivtv *itv)
   {
  int rc;
   
  +#ifdef CONFIG_X86_64
  +   if (WARN(pat_enabled,
 
 This check might be better placed in ivtvfb_init().  This check is going
 to have the same result for every PVR-350 card in the system that is
 found by ivtvfb.

OK moved!

  +ivtv needs PAT disabled, boot with nopat kernel 
  parameter\n)) {
 
 This needs to read ivtvfb needs [...] to avoid user confusion with the
 main ivtv driver module.

OK!

 This change is the only one I really care about.  Then I can give my
 Ack.

OK!

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Wed, Apr 22, 2015 at 10:17:55AM -0600, Jason Gunthorpe wrote:
 On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
  On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
   On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
 Mike, do you think the time is right to just remove the iPath driver?

With PAT now being default the driver effectively won't work
with write-combining on modern kernels. Even if systems are old
they likely had PAT support, when upgrading kernels PAT will work
but write-combing won't on ipath.
   
   Sorry, do you mean the driver already doesn't get WC? Or do you mean
   after some more pending patches are applied?
  
  No, you have to consider the system used and the effects of calls used
  on the driver in light of this table:
 
 So, just to be clear:
 
 At some point Linux started setting the PAT bits during
 ioremap_nocache, which overrides MTRR, and at that point the driver
 became broken on all PAT capable systems?

No, PAT code lacked quite a bit of love, and Juergen and some others have
been giving it some love and now we expect PAT to be enabled by default on
more systems. When and and on what systemes and as of what commits? Not
sure, there's quite a bit of PAT work but hoping Juergen might fill
in the details, CC'd.

 Not only that, but we've only just noticed it now, and no user ever
 complained?

No, well this is all recent, so we expect more PAT enabled systems now.

 So that means either no users exist, or all users are on non-PAT
 systems?

PAT was not being enabled before on most systems, it will now be on
most systems, for some systems there may be some errata that needs to
be addressed for PAT.

 This driver only works on x86-64 systems. Are there any x86-64 systems
 that are not PAT capable? 

Not that I know of, but I've heard of some PAT errata systems, and
that may need some attention.

 IIRC even the first Opteron had PAT, but my
 memory is fuzzy from back then :|
 
  Another option in order to enable this type of checks at run time
  and still be able to build the driver on standard distributions and
  just prevent if from loading on PAT systems is to have some code in
  place which would prevent the driver from loading if PAT was
  enabled, this would enable folks to disable PAT via a kernel command
  line option, and if that was used then the driver probe would
  complete.
 
 This seems like a reasonble option to me. At the very least we might
 learn if anyone is still using these cards.

OK great.

 I'd also love to remove the driver if it turns out there are actually
 no users. qib substantially replaces it except for a few very old
 cards.
 
 Mike?

By replacing do you mean same hardware? BTW below are the changes
which I describe above which would prevent both ipath and ivtv
to load on PAT enabled systems. I think its a reasonable compromise.
If this is OK I can proceed with a split of the patches and move 
on with the last series that burries MTRR.

Andy Walls, please review too.

  Luis

diff --git a/drivers/infiniband/hw/ipath/ipath_driver.c 
b/drivers/infiniband/hw/ipath/ipath_driver.c
index bd0caed..3ef592c 100644
--- a/drivers/infiniband/hw/ipath/ipath_driver.c
+++ b/drivers/infiniband/hw/ipath/ipath_driver.c
@@ -42,6 +42,9 @@
 #include linux/bitmap.h
 #include linux/slab.h
 #include linux/module.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
+#endif
 
 #include ipath_kernel.h
 #include ipath_verbs.h
@@ -395,6 +398,14 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
unsigned long long addr;
u32 bar0 = 0, bar1 = 0;
 
+#ifdef CONFIG_X86_64
+   if (WARN(pat_enabled,
+ipath needs PAT disabled, boot with nopat kernel 
parameter\n)) {
+   ret = EINVAL;
+   goto bail;
+   }
+#endif
+
dd = ipath_alloc_devdata(pdev);
if (IS_ERR(dd)) {
ret = PTR_ERR(dd);
@@ -542,6 +553,7 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
dd-ipath_kregbase = __ioremap(addr, len,
(_PAGE_NO_CACHE|_PAGE_WRITETHRU));
 #else
+   /* XXX: split this properly to enable on PAT */
dd-ipath_kregbase = ioremap_nocache(addr, len);
 #endif
 
@@ -587,12 +599,8 @@ static int ipath_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
 
ret = ipath_enable_wc(dd);
 
-   if (ret) {
-   ipath_dev_err(dd, Write combining not enabled 
- (err %d): performance may be poor\n,
- -ret);
+   if (ret)
ret = 0;
-   }
 
ipath_verify_pioperf(dd);
 
diff --git a/drivers/infiniband/hw/ipath/ipath_kernel.h 
b/drivers/infiniband/hw/ipath/ipath_kernel.h
index e08db70..f0f9471 100644
--- a/drivers/infiniband/hw/ipath/ipath_kernel.h
+++ b/drivers/infiniband/hw/ipath/ipath_kernel.h
@@ -463,9 +463,7 @@ struct ipath_devdata

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
 On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
  On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you think the time is right to just remove the iPath driver?
   
   With PAT now being default the driver effectively won't work
   with write-combining on modern kernels. Even if systems are old
   they likely had PAT support, when upgrading kernels PAT will work
   but write-combing won't on ipath.
  
  Sorry, do you mean the driver already doesn't get WC? Or do you mean
  after some more pending patches are applied?
 
 No, you have to consider the system used and the effects of calls used
 on the driver in light of this table:
 
 --
 MTRR Non-PAT   PATLinux ioremap valueEffective memory type
 --
   Non-PAT |  PAT
  PAT
  |PCD
  ||PWT
  |||
 WC   000  WB  _PAGE_CACHE_MODE_WBWC   |   WC
 WC   001  WC  _PAGE_CACHE_MODE_WCWC*  |   WC
 WC   010  UC- _PAGE_CACHE_MODE_UC_MINUS  WC*  |   UC
 WC   011  UC  _PAGE_CACHE_MODE_UCUC   |   UC
 --
 
 (*) denotes implementation defined and is discouraged
 
 ioremap_nocache() will use _PAGE_CACHE_MODE_UC_MINUS by default today,
 in the future we want to flip the switch and make _PAGE_CACHE_MODE_UC
 the default. When that flip occurs it will mean ipath cannot get
 write-combining on both non-PAT and PAT systems. Now that is for
 the future, lets review the current situation for ipath.
 
 For PAT capable systems if mtrr_add() is used today on a Linux system on a
 region mapped with ioremap_nocache() that will mean you effectively nullify 
 the
 mtrr_add() effect as the combinatorial effect above yields an effective memory
 type of UC.  For PAT systems you want to use ioremap_wc() on the region in
 which you need write-combining followed by arch_phys_wc_add() which will 
 *only*
 call mtrr_add() *iff* PAT was not enabled. This also means we need to split
 the ioremap'd areas so that the area that is using ioremap_nocache() can never
 get write-combining (_PAGE_CACHE_MODE_UC). The ipath driver needs the regions
 split just as was done for the qib driver.
 
 Now we could just say that leaving things as-is is a non-issue if you are OK
 with non-write-combining effects being the default behaviour left on the ipath
 driver for PAT systems. In that case we can just use arch_phys_wc_add() on the
 driver and while it won't trigger the mtrr_add() on PAT systems it sill won't
 have any effect. We just typically don't want to see use of ioremap_nocache()
 paired with arch_phys_wc_add(), grammatically the correct thing to do is pair
 ioremap_wc() areas with a arch_phys_wc_add() to make the write-combining 
 effects
 on non-PAT systems. If the ipath driver is not going to get he work required
 to split the regions though perhaps we can live with a corner case driver that
 annotates PAT must be disabled on the systems that use it and convert it to
 arch_phys_wc_add() to just help with phasing out of direct use of mtrr_add().
 With this strategy if and when ipath driver gets a split done it would gain WC
 on both PAT and non-PAT.

Folks, after some thought I do believe the above temporary strategy would
avoid issues and would not have to stir people up to go and make code
changes. We can use the same strategy for both ivtv and ipath:

  * Annotate via Kconfig for the driver that it depends on !X86_PAT
that will ensure that PAT systems won't use it, and convert it
to use arch_phys_wc_add() to help phase out direct access to mtrr_add()

This would be correct given that the current situation on the driver
makes write-combining non-effective on PAT systems, we in fact gain
avoiding these type of use-cases, and annotate this as a big TODO item
for folks who do want it for PAT systems.

Thoughts?

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Wed, Apr 22, 2015 at 8:54 AM, Luis R. Rodriguez mcg...@suse.com wrote:
 On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
 On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
  On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you think the time is right to just remove the iPath driver?
  
   With PAT now being default the driver effectively won't work
   with write-combining on modern kernels. Even if systems are old
   they likely had PAT support, when upgrading kernels PAT will work
   but write-combing won't on ipath.
 
  Sorry, do you mean the driver already doesn't get WC? Or do you mean
  after some more pending patches are applied?

 No, you have to consider the system used and the effects of calls used
 on the driver in light of this table:

 --
 MTRR Non-PAT   PATLinux ioremap valueEffective memory type
 --
   Non-PAT |  PAT
  PAT
  |PCD
  ||PWT
  |||
 WC   000  WB  _PAGE_CACHE_MODE_WBWC   |   WC
 WC   001  WC  _PAGE_CACHE_MODE_WCWC*  |   WC
 WC   010  UC- _PAGE_CACHE_MODE_UC_MINUS  WC*  |   UC
 WC   011  UC  _PAGE_CACHE_MODE_UCUC   |   UC
 --

 (*) denotes implementation defined and is discouraged

 ioremap_nocache() will use _PAGE_CACHE_MODE_UC_MINUS by default today,
 in the future we want to flip the switch and make _PAGE_CACHE_MODE_UC
 the default. When that flip occurs it will mean ipath cannot get
 write-combining on both non-PAT and PAT systems. Now that is for
 the future, lets review the current situation for ipath.

 For PAT capable systems if mtrr_add() is used today on a Linux system on a
 region mapped with ioremap_nocache() that will mean you effectively nullify 
 the
 mtrr_add() effect as the combinatorial effect above yields an effective 
 memory
 type of UC.  For PAT systems you want to use ioremap_wc() on the region in
 which you need write-combining followed by arch_phys_wc_add() which will 
 *only*
 call mtrr_add() *iff* PAT was not enabled. This also means we need to split
 the ioremap'd areas so that the area that is using ioremap_nocache() can 
 never
 get write-combining (_PAGE_CACHE_MODE_UC). The ipath driver needs the regions
 split just as was done for the qib driver.

 Now we could just say that leaving things as-is is a non-issue if you are OK
 with non-write-combining effects being the default behaviour left on the 
 ipath
 driver for PAT systems. In that case we can just use arch_phys_wc_add() on 
 the
 driver and while it won't trigger the mtrr_add() on PAT systems it sill won't
 have any effect. We just typically don't want to see use of ioremap_nocache()
 paired with arch_phys_wc_add(), grammatically the correct thing to do is pair
 ioremap_wc() areas with a arch_phys_wc_add() to make the write-combining 
 effects
 on non-PAT systems. If the ipath driver is not going to get he work required
 to split the regions though perhaps we can live with a corner case driver 
 that
 annotates PAT must be disabled on the systems that use it and convert it to
 arch_phys_wc_add() to just help with phasing out of direct use of mtrr_add().
 With this strategy if and when ipath driver gets a split done it would gain 
 WC
 on both PAT and non-PAT.

 Folks, after some thought I do believe the above temporary strategy would
 avoid issues and would not have to stir people up to go and make code
 changes. We can use the same strategy for both ivtv and ipath:

   * Annotate via Kconfig for the driver that it depends on !X86_PAT
 that will ensure that PAT systems won't use it, and convert it
 to use arch_phys_wc_add() to help phase out direct access to mtrr_add()

 This would be correct given that the current situation on the driver
 makes write-combining non-effective on PAT systems, we in fact gain
 avoiding these type of use-cases, and annotate this as a big TODO item
 for folks who do want it for PAT systems.

 Thoughts?

Another option in order to enable this type of checks at run time and
still be able to build the driver on standard distributions and just
prevent if from loading on PAT systems is to have some code in place
which would prevent the driver from loading if PAT was enabled, this
would enable folks to disable PAT via a kernel command line option,
and if that was used then the driver probe would complete.

 Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
 On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
   Mike, do you think the time is right to just remove the iPath driver?
  
  With PAT now being default the driver effectively won't work
  with write-combining on modern kernels. Even if systems are old
  they likely had PAT support, when upgrading kernels PAT will work
  but write-combing won't on ipath.
 
 Sorry, do you mean the driver already doesn't get WC? Or do you mean
 after some more pending patches are applied?

No, you have to consider the system used and the effects of calls used
on the driver in light of this table:

--
MTRR Non-PAT   PATLinux ioremap valueEffective memory type
--
  Non-PAT |  PAT
 PAT
 |PCD
 ||PWT
 |||
WC   000  WB  _PAGE_CACHE_MODE_WBWC   |   WC
WC   001  WC  _PAGE_CACHE_MODE_WCWC*  |   WC
WC   010  UC- _PAGE_CACHE_MODE_UC_MINUS  WC*  |   UC
WC   011  UC  _PAGE_CACHE_MODE_UCUC   |   UC
--

(*) denotes implementation defined and is discouraged

ioremap_nocache() will use _PAGE_CACHE_MODE_UC_MINUS by default today,
in the future we want to flip the switch and make _PAGE_CACHE_MODE_UC
the default. When that flip occurs it will mean ipath cannot get
write-combining on both non-PAT and PAT systems. Now that is for
the future, lets review the current situation for ipath.

For PAT capable systems if mtrr_add() is used today on a Linux system on a
region mapped with ioremap_nocache() that will mean you effectively nullify the
mtrr_add() effect as the combinatorial effect above yields an effective memory
type of UC.  For PAT systems you want to use ioremap_wc() on the region in
which you need write-combining followed by arch_phys_wc_add() which will *only*
call mtrr_add() *iff* PAT was not enabled. This also means we need to split
the ioremap'd areas so that the area that is using ioremap_nocache() can never
get write-combining (_PAGE_CACHE_MODE_UC). The ipath driver needs the regions
split just as was done for the qib driver.

Now we could just say that leaving things as-is is a non-issue if you are OK
with non-write-combining effects being the default behaviour left on the ipath
driver for PAT systems. In that case we can just use arch_phys_wc_add() on the
driver and while it won't trigger the mtrr_add() on PAT systems it sill won't
have any effect. We just typically don't want to see use of ioremap_nocache()
paired with arch_phys_wc_add(), grammatically the correct thing to do is pair
ioremap_wc() areas with a arch_phys_wc_add() to make the write-combining effects
on non-PAT systems. If the ipath driver is not going to get he work required
to split the regions though perhaps we can live with a corner case driver that
annotates PAT must be disabled on the systems that use it and convert it to
arch_phys_wc_add() to just help with phasing out of direct use of mtrr_add().
With this strategy if and when ipath driver gets a split done it would gain WC
on both PAT and non-PAT.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Wed, Apr 22, 2015 at 09:53:03AM -0700, Andy Lutomirski wrote:
On Wed, Apr 22, 2015 at 8:23 AM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you think the time is right to just remove the iPath driver?

With PAT now being default the driver effectively won't work
with write-combining on modern kernels. Even if systems are old
they likely had PAT support, when upgrading kernels PAT will work
but write-combing won't on ipath.

Sorry, do you mean the driver already doesn't get WC? Or do you mean
after some more pending patches are applied?

No, you have to consider the system used and the effects of calls used
on the driver in light of this table:

--
MTRR Non-PAT PATLinux ioremap valueEffective memory type
--
Non-PAT | PAT
PAT
|PCD
||PWT
|||
WC 000 WB _PAGE_CACHE_MODE_WBWC | WC
WC 001 WC _PAGE_CACHE_MODE_WCWC* | WC
WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | UC
WC 011 UC _PAGE_CACHE_MODE_UCUC | UC
--

(*) denotes implementation defined and is discouraged

ioremap_nocache() will use _PAGE_CACHE_MODE_UC_MINUS by default today,
in the future we want to flip the switch and make _PAGE_CACHE_MODE_UC
the default. When that flip occurs it will mean ipath cannot get
write-combining on both non-PAT and PAT systems. Now that is for
the future, lets review the current situation for ipath.

For PAT capable systems if mtrr_add() is used today on a Linux system on a
region mapped with ioremap_nocache() that will mean you effectively nullify
the
mtrr_add() effect as the combinatorial effect above yields an effective
memory
type of UC.

Are you sure?

Well lets double check.

I thought that ioremap_nocache currently is UC-,

It is.

so mtrr_add + ioremap_nocache gets WC even on PAT systems.

https://www-ssl.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf

As per Intel SDM 11.5.2.2 Selecting Memory Types for Pentium
III and More Recent Processor Families the ffect of a WC MTRR
for a region with a PAT entry value of UC will be UC. The effect
of a WC MTRR on a region with a PAT entry UC- will be WC. The
effect of a WC MTRR on a regoin with PAT entry WC is WC.

And indeed as per table 11-7 mtrr WC on PAT UC- yields WC. So ineed the above
table needs adjustment for this. So for PAT systems write-combing would be
effective with mtrr_add(), but once strong UC (_PAGE_CACHE_MODE_UC) is used by
default for ioremap_nocache() what I mentioned will be true. Furhtermore if we
switch the drivers to use arch_phys_wc_add() then for sure write-combining will
also not be effective.

Jason, Andy, is the change still a reasonable compromise? We'd just be asking
users to boot with noat for users for ipath, ivtv until the drivers gets proper
PAT support with a split.

There are two motivations for this:

* help move to strong UC as default
* bury MTRR

Going forward, when mtrr_add is gone, this will change, of course.

Indeed.

Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Wed, Apr 22, 2015 at 02:53:11PM -0400, Doug Ledford wrote:
 On Wed, 2015-04-22 at 10:17 -0600, Jason Gunthorpe wrote:
  On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
   On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
  Mike, do you think the time is right to just remove the iPath 
  driver?
 
 With PAT now being default the driver effectively won't work
 with write-combining on modern kernels. Even if systems are old
 they likely had PAT support, when upgrading kernels PAT will work
 but write-combing won't on ipath.

Sorry, do you mean the driver already doesn't get WC? Or do you mean
after some more pending patches are applied?
   
   No, you have to consider the system used and the effects of calls used
   on the driver in light of this table:
  
  So, just to be clear:
  
  At some point Linux started setting the PAT bits during
  ioremap_nocache, which overrides MTRR, and at that point the driver
  became broken on all PAT capable systems?
  
  Not only that, but we've only just noticed it now, and no user ever
  complained?
  
  So that means either no users exist, or all users are on non-PAT
  systems?
  
  This driver only works on x86-64 systems. Are there any x86-64 systems
  that are not PAT capable? IIRC even the first Opteron had PAT, but my
  memory is fuzzy from back then :|
  
   Another option in order to enable this type of checks at run time
   and still be able to build the driver on standard distributions and
   just prevent if from loading on PAT systems is to have some code in
   place which would prevent the driver from loading if PAT was
   enabled, this would enable folks to disable PAT via a kernel command
   line option, and if that was used then the driver probe would
   complete.
  
  This seems like a reasonble option to me. At the very least we might
  learn if anyone is still using these cards.
  
  I'd also love to remove the driver if it turns out there are actually
  no users. qib substantially replaces it except for a few very old
  cards.
 
 To be precise, the split is that ipath powers the old HTX bus cards that
 only work in AMD systems,

Do those systems have PAT support? CAn anyone check if PAT is enabled
if booted on a recent kernel?


 Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] ivtv: use arch_phys_wc_add() and require PAT disabled

From: Luis R. Rodriguez mcg...@suse.com

We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.

In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.

This is a worthy comprmise given that the hardware is
really rare these days, and perhaps only some lost souls
in some third world country are expected to be using this
feature of the device driver.

Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Andy Walls awa...@md.metrocast.net
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Mel Gorman mgor...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Borislav Petkov b...@suse.de
Cc: Davidlohr Bueso dbu...@suse.de
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/media/pci/ivtv/Kconfig  |  3 +++
 drivers/media/pci/ivtv/ivtvfb.c | 59 +
 2 files changed, 27 insertions(+), 35 deletions(-)

diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index dd6ee57e..b2a7f88 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
  This is used in the Hauppauge PVR-350 card. There is a driver
  homepage at http://www.ivtvdriver.org.
 
+ If you have this hardware you will need to boot with PAT disabled
+ on your x86 systems, use the nopat kernel parameter.
+
  To compile this driver as a module, choose M here: the
  module will be called ivtvfb.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..552408b 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,8 +44,8 @@
 #include linux/ivtvfb.h
 #include linux/slab.h
 
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
 #endif
 
 #include ivtv-driver.h
@@ -155,12 +155,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
 
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+   int wc_cookie;
 
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
 static int ivtvfb_init_io(struct ivtv *itv)
 {
struct osd_info *oi = itv-osd_info;
+   /* Find the largest power of two that maps the whole buffer */
+   int size_shift = 31;
 
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1120,6 +1121,7 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_buffer_size = 1704960;
 
oi-video_pbase = itv-base_addr + IVTV_DECODER_OFFSET + 
oi-video_rbase;
+   /* XXX: split this for PAT */
oi-video_vbase = itv-dec_mem + oi-video_rbase;
 
if (!oi-video_vbase) {
@@ -1132,29 +1134,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
 
-#ifdef CONFIG_MTRR
-   {
-   /* Find the largest power of two that maps the whole buffer */
-   int size_shift = 31;
-
-   while (!(oi-video_buffer_size  (1  size_shift))) {
-   size_shift--;
-   }
-   size_shift++;
-   oi-fb_start_aligned_physaddr = oi-video_pbase  ~((1  
size_shift) - 1);
-   oi-fb_end_aligned_physaddr = oi-video_pbase + 
oi-video_buffer_size;
-   oi-fb_end_aligned_physaddr += (1  size_shift) - 1;
-   oi

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Wed, Apr 22, 2015 at 12:10 PM, Doug Ledford dledf...@redhat.com wrote:
 On Wed, 2015-04-22 at 21:05 +0200, Luis R. Rodriguez wrote:

   I'd also love to remove the driver if it turns out there are actually
   no users. qib substantially replaces it except for a few very old
   cards.
 
  To be precise, the split is that ipath powers the old HTX bus cards that
  only work in AMD systems,

 Do those systems have PAT support? CAn anyone check if PAT is enabled
 if booted on a recent kernel?

 I don't have one of these systems any more.  The *only* one I ever had
 was a monster IBM box...I can't even find a reference to it any more.

Um, yeah if its so rare then I think the compromise proposed might
make sense, specially since folks were even *considering* seriously
removing this device driver. I'll send some patches to propose the
strategy explained to require booting with pat disabled.

 Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Wed, Apr 15, 2015 at 05:58:14PM -0700, Andy Lutomirski wrote:
 On Wed, Apr 15, 2015 at 4:59 PM, Andy Walls awa...@md.metrocast.net wrote:
  On Wed, 2015-04-15 at 16:42 -0700, Andy Lutomirski wrote:
  On Wed, Apr 15, 2015 at 3:38 PM, Andy Walls awa...@md.metrocast.net 
  wrote:
 
  
 
  IMO the right solution would be to avoid ioremapping the whole bar at
  startup.  Instead ioremap pieces once the driver learns what they are.
  This wouldn't have any of these problems -- you'd ioremap() register
  regions and you'd ioremap_wc() the framebuffer once you find it.  If
  there are regions of unknown purpose, just don't map them all.
 
  Would this be feasible?
 
  Feasible? Maybe.
 
  Worth the time and effort for end-of-life, convential PCI hardware so I
  can have an optimally performing X display on a Standard Def Analog TV
  screen?   Nope. I don't have that level of nostalgia.
 
 
 The point is actually to let us unexport or delete mtrr_add.  We can
 either severely regress performance on ivtv on PAT-capable hardware if
 we naively switch it to arch_phys_wc_add or we can do something else.
 The something else remains to be determined.

Back to square one: I can't come up with anything not too instrusive
or that dotes not requires substantial amount of work as an alternative to
removing MTRR completely right now (with the long term goal of also
making strong UC default) and its because of 2 device drivers:

  * ivtv: firmware API is poo and device is legacy, no one cares
  * ipath: driver needs a clean split and work is considerable,
maintainers have not been responsive, do they care?

What do we want to do with these drivers? Let us be straight shooters,
if we are serious about having a performance regression on the drivers
for the sake of removing MTRR why not just seriously discuss removal
of these drivers. This way we can remain sane, upkeep a policy to
never even consider overlapping ioremap*() calls, and have a clean
expected strategy we can expect for new drivers.

I'm going to split up my patches now into 4 series:

1) things which are straight forward in converting drivers over
   to arch_phys_wc_add() and ioremap_wc(). These are subsystem
   wide though, so just a heads up, my hope is that each subsystem
   maintainer can take their own series unless someone else is
   comfortable in taking this in for x86

2) a few helpers in the like of ioremap_wc() needed for other drivers.
   These are straight forward but since they depend on x86 / core
   helpers it would be nice for them to go I guess through x86 folks.
   What maintainer is up to take these?

3) MTRR run time changes

4) corner cases - TBD - lets discuss here what we want to do with
   ivtv and ipath. I will however remove fusion's mtrr code use
   as its all commented out.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Tue, Apr 21, 2015 at 3:02 PM, Luis R. Rodriguez mcg...@suse.com wrote:
 Andy, can we live without MTRR support on this driver for future kernels? This
 would only leave ipath as the only offending driver.

Sorry to be clear, can we live with removal of write-combining on this driver?

 Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Wed, Apr 15, 2015 at 01:42:47PM -0700, Andy Lutomirski wrote:
 On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez mcg...@suse.com wrote:
 
  c) ivtv: the driver does not have the PCI space mapped out separately, and
  in fact it actually does not do the math for the framebuffer, instead it 
  lets
  the device's own CPU do that and assume where its at, see
  ivtvfb_get_framebuffer() and CX2341X_OSD_GET_FRAMEBUFFER, it has a get
  but not a setter. Its not clear if the firmware would make a split easy.
  We'd need ioremap_ucminus() here too and __arch_phys_wc_add().
 
 
 IMO this should be conceptually easy to split.  Once we get the
 framebuffer address, just unmap it (or don't prematurely map it) and
 then ioremap the thing.

Side note to ipath driver folks: as reviewed with Andy Walls, the
ivtv driver cannot easily be ported to use PAT so we are evaluating
simply removing write-combing from that driver on future kernels.

 
  From the beginning it seems only framebuffer devices used MTRR/WC, lately it
  seems infiniband drivers also find good use for for it for PIO TX buffers to
  blast some sort of data, in the future I would not be surprised if other
  devices found use for it.
 
 IMO the Infiniband maintainers should fix their code.  Especially in
 the server space, there aren't that many MTRRs to go around.  I wrote
 arch_phys_wc_add in the first place because my server *ran out of
 MTRRs*.
 
 Hey, IB people: can you fix your drivers to use arch_phys_wc_add
 (which is permitted to be a no-op) along with ioremap_wc?  Your users

ipath driver maintainers:

The ipath driver is one of two drivers left to convert over to
arch_phys_wc_add(). MTRR use is being deprecated, and its use is actually
highly discouraged now that we have proper PAT implemenation on Linux. Since we
are talking about annotating the qib driver as known to be broken without PAT
and since the ipath driver needs considerable work to be ported to use PAT (the
userspace register is just one area) I wanted to review if we can just remove
MTRR use on the ipath driver and annotate write-combining with PAT as a TODO
item.

This would help a lot in our journey to bury MTRR use.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Tue, Apr 21, 2015 at 04:57:32PM -0600, Jason Gunthorpe wrote:
 On Wed, Apr 22, 2015 at 12:46:01AM +0200, Luis R. Rodriguez wrote:
 
  are talking about annotating the qib driver as known to be broken without 
  PAT
  and since the ipath driver needs considerable work to be ported to
  use PAT (the
 
 This only seems to be true for one of the chips that driver supports,
 not all possibilities.
 
  userspace register is just one area) I wanted to review if we can just 
  remove
  MTRR use on the ipath driver and annotate write-combining with PAT as a TODO
  item.
 
 AFAIK, dropping MTRR support will completely break the performance to
 the point the driver is unusable. If we drop MTRR we may as well
 remove the driver.

To be clear, the arch_phys_wc_add() API will be a no-op when PAT is
enabled on a system. Although some folks think PAT is new, its not,
its just that our implementation on Linux lacked a bit of push, recent
changes however make PAT support complete and that means now we'll have
PAT enabled on systems that likely didn't before on recent kernels.

There are other important motivations to use PAT:

 * Xen won't work with MTRR, having a unified PAT enabled kernel
   will ensure that when Xen is used write-combinging will take
   effect

 * Long term we want to make strong UC the default to ioremap() on
   x86, right now its not, its UC-, we need to convert all drivers
   that want write-combining over to use ioremap_wc() for their
   specific area, and it must not overlap. There are issues with
   using mtrr_add() on regions marked as UC-, since its the default
   this  means that mtrr_add() use on ioramp'd areas on PAT systems
   will actually make write-combining *void*. Refer to this table
   for combinatorial effects for non-PAT / PAT of wc MTRR:

   https://marc.info/?l=linux-kernelm=142964809710517w=1

So as the train of PAT enablement moves forward it means systems
that have PAT enabled now might not have write-combining effective.
In order to get the best of both worlds, non-PAT and PAT systems
we must design drivers cleanly for the non-writecombining and
write-combining areas. This mean using ioremap_nocache() for MMIO
and ioremap_wc() *only* for the desired, write-combining area,
followed by arch_phys_wc_add().

 Mike, do you think the time is right to just remove the iPath driver?

With PAT now being default the driver effectively won't work
with write-combining on modern kernels. Even if systems are old
they likely had PAT support, when upgrading kernels PAT will work
but write-combing won't on ipath.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Tue, Apr 21, 2015 at 06:51:26PM -0400, Andy Walls wrote:
 Sorry for the top post; mobile work email account.
 
 Luis,
 
 You do the changes to remove MTTR and point me to your dev repo and branch.
 Also point me to the new functions/primitives I'll need.

There is nothing new actually needed for ivtv, unless of course
the ivtv driver is bounded to use a large MTRR that includes
the non-framebuffer region, if so then the ioremap_uc() would
be needed, and you can just cherry pick that patch:

https://marc.info/?l=linux-kernelm=142964809110516w=1

I'll bounce that patch to you as well. Might help reading this
patch too:

https://marc.info/?l=linux-kernelm=142964809710517w=1

If your write-combining area is not restricted by size constraints
so that it also include the non-framebuffer areas then you can just
do a simple conversion of the driver to use ioremap_wc() on the
framebuffer followed by arch_phys_wc_add().

An example driver that required changes to split this with size
contraints is atyfb, here are the changes for it:

https://marc.info/?l=linux-kernelm=142964818810539w=1
https://marc.info/?l=linux-kernelm=142964813610531w=1
https://marc.info/?l=linux-kernelm=142964811010524w=1
https://marc.info/?l=linux-kernelm=142964814810532w=1

If you are not constrained by MTRR's limitation on size then
a simple trivial driver conversion is sufficient. For example:

https://marc.info/?l=linux-kernelm=142964744610286w=1

I should also note that we are strivoing to also not use overlapping ioremap()
calls as we want to avoid that mess. Overlapping iroemap() calls with different
types could in theory work but its best we just design clean drivers and avoid
this.

As per Andy Lutomirski, what we'd need done on ivtv likely is
for it to ioremap() for an initial bring up of the device, then
infer the framebuffer offset, and only when that is being used
then iounmap and then ioremap() again split areas on the driver,
one with ioremap.

 I'll do the changes to add write-combining back into ivtv and ivtvfb, test
 them with my hardware and push them to my linuxtv.org git repo.

Great! The above sounded like a complexity you did not wish to
take on, but if you're up for the change, that'd be awesome!

 I know there is at least one English speaking user in India using ivtv with
 old PVR hardware, and probably folks in less developed places also using it.

If the above is too much work for that few amount of users I'd hope
we can just have them use older kernels, for the sake of sane APIs and
clean driver architecture.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

On Wed, Apr 15, 2015 at 09:07:37PM -0400, Andy Walls wrote:
 On Thu, 2015-04-16 at 01:58 +0200, Luis R. Rodriguez wrote:
  Hey Andy, thanks for your review,  adding Hyong-Youb Kim for  review of the
  full range ioremap_wc() idea below.
  
  On Wed, Apr 15, 2015 at 06:38:51PM -0400, Andy Walls wrote:
   Hi All,
   
   On Mon, 2015-04-13 at 19:49 +0200, Luis R. Rodriguez wrote:
From the beginning it seems only framebuffer devices used MTRR/WC,
   [snip]
 The ivtv device is a good example of the worst type of
situations and these days. So perhap __arch_phys_wc_add() and a
ioremap_ucminus() might be something more than transient unless 
hardware folks
get a good memo or already know how to just Do The Right Thing (TM).
   
   Just to reiterate a subtle point, use of the ivtvfb is *optional*.  A
   user may or may not load it.  When the user does load the ivtvfb driver,
   the ivtv driver has already been initialized and may have functions of
   the card already in use by userspace.
  
  I suspected this and its why I note that a rewrite to address a clean
  split with separate ioremap seems rather difficult in this case.
  
   Hopefully no one is trying to use the OSD as framebuffer and the video
   decoder/output engine for video display at the same time. 
  
  Worst case concern I have also is the implications of having overlapping
  ioremap() calls (as proposed in my last reply) for different memory types
  and having the different virtual memory addresse used by different parts
  of the driver. Its not clear to me what the hardware implications of this
  are.
  
But the video
   decoder/output device nodes may already be open for performing ioctl()
   functions so unmapping the decoder IO space out from under them, when
   loading the ivtvfb driver module, might not be a good thing. 
  
  Using overlapping ioremap() calls with different memory types would address
  this concern provided hardware won't barf both on the device and CPU. 
  Hardware
  folks could provide feedback or an ivtvfb user could test the patch supplied
  on both non-PAT and PAT systems. Even so, who knows,  this might work on 
  some
  systems while not on others, only hardware folks would know.
 
 The CX2341[56] firmware+hardware has a track record for being really
 picky about sytem hardware.  It's primary symptoms are for the DMA
 engine or Mailbox protocol to get hung up.  So yeah, it could barf
 easily on some users.
 
  An alternative... is to just ioremap_wc() the entire region, including
  MMIO registers for these old devices.
 
 That's my thought; as long as implementing PCI write then read can force
 writes to be posted and that setting that many pages as WC doesn't cause
 some sort of PAT resource exhaustion. (I know very little about PAT).

So upon review that strategy won't work well unless we implemnt some
sort of of hack on the driver. That's also quite a bit of work.

Andy, can we live without MTRR support on this driver for future kernels? This
would only leave ipath as the only offending driver.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

2015-04-16 Thread Luis R. Rodriguez

On Thu, Apr 16, 2015 at 01:18:37PM +0900, Hyong-Youb Kim wrote:
 On Thu, Apr 16, 2015 at 01:58:16AM +0200, Luis R. Rodriguez wrote:
  
  An alternative... is to just ioremap_wc() the entire region, including
  MMIO registers for these old devices. I see one ethernet driver that does
  this, myri10ge, and am curious how and why they ended up deciding this
  and if they have run into any issues. I wonder if this is a reasonable
  comrpomise for these 2 remaining corner cases.
  
 
 For myri10ge, it a performance thing.  Descriptor rings are in NIC
 memory BAR0, not in host memory.  Say, to send a packet, the driver
 writes the send descriptor to the ioremap'd NIC memory.  It is a
 multi-word descriptor.  So, to send it as one PCIE MWr transaction,
 the driver maps the whole BAR0 as WC and does copy descriptor; wmb.

Interesting, so you burst write multi-word descriptor writes using
write-combining here for the Ethernet device.

 Without WC, descriptors would end up as multiple 4B or 8B MWr packets
 to the NIC, which has a pretty big performance impact on this
 particular NIC.

How big are the descriptors?

 Most registers that do not want WC are actually in BAR2, which is not
 mapped as WC.  For registers that are in BAR0, we do write to the
 register; wmb.  If we want to wait till the NIC has seen the write,
 we do write; wmb; read.

Interesting, thanks, yeah using this as a work around to the problem sounds
plausible however it still would require likely making just as many changes to
the ivtv and ipath driver as to just do a proper split. I do wonder however if
this sort of work around can be generalized somehow though so that others could
use, if this sort of thing is going to become prevalent. If so then this would
serve two purposes: work around for the corner cases of MTRR use on Linux and
also these sorts of device constraints.

In order to determine if this is likely to be generally useful could you 
elaborate
a bit more about the detals of the performance issues of not bursting writes
for the descriptor on this device.

Even if that is done a conversion over to this work around seems it may require
device specific nitpicks. For instance I note in myri10ge_submit_req() for
small writes you just do a reverse write and do the first set last, then
finally the last 32 bits are rewritten, I guess to trigger something?

 This approach has worked for this device for many years.  I cannot say
 whether it works for other devices, though.

I think it should but the more interesting question would be exactly
*why* it was needed for this device, who determined that, and why?

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

2015-04-15 Thread Luis R. Rodriguez

Hey Andy, thanks for your review,  adding Hyong-Youb Kim for  review of the
full range ioremap_wc() idea below.

On Wed, Apr 15, 2015 at 06:38:51PM -0400, Andy Walls wrote:
 Hi All,
 
 On Mon, 2015-04-13 at 19:49 +0200, Luis R. Rodriguez wrote:
  From the beginning it seems only framebuffer devices used MTRR/WC,
 [snip]
   The ivtv device is a good example of the worst type of
  situations and these days. So perhap __arch_phys_wc_add() and a
  ioremap_ucminus() might be something more than transient unless hardware 
  folks
  get a good memo or already know how to just Do The Right Thing (TM).
 
 Just to reiterate a subtle point, use of the ivtvfb is *optional*.  A
 user may or may not load it.  When the user does load the ivtvfb driver,
 the ivtv driver has already been initialized and may have functions of
 the card already in use by userspace.

I suspected this and its why I note that a rewrite to address a clean
split with separate ioremap seems rather difficult in this case.

 Hopefully no one is trying to use the OSD as framebuffer and the video
 decoder/output engine for video display at the same time. 

Worst case concern I have also is the implications of having overlapping
ioremap() calls (as proposed in my last reply) for different memory types
and having the different virtual memory addresse used by different parts
of the driver. Its not clear to me what the hardware implications of this
are.

  But the video
 decoder/output device nodes may already be open for performing ioctl()
 functions so unmapping the decoder IO space out from under them, when
 loading the ivtvfb driver module, might not be a good thing. 

Using overlapping ioremap() calls with different memory types would address
this concern provided hardware won't barf both on the device and CPU. Hardware
folks could provide feedback or an ivtvfb user could test the patch supplied
on both non-PAT and PAT systems. Even so, who knows,  this might work on some
systems while not on others, only hardware folks would know.

An alternative... is to just ioremap_wc() the entire region, including
MMIO registers for these old devices. I see one ethernet driver that does
this, myri10ge, and am curious how and why they ended up deciding this
and if they have run into any issues. I wonder if this is a reasonable
comrpomise for these 2 remaining corner cases.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

2015-04-15 Thread Luis R. Rodriguez

On Wed, Apr 15, 2015 at 01:42:47PM -0700, Andy Lutomirski wrote:
 On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez mcg...@suse.com wrote:
 
  c) ivtv: the driver does not have the PCI space mapped out separately, and
  in fact it actually does not do the math for the framebuffer, instead it 
  lets
  the device's own CPU do that and assume where its at, see
  ivtvfb_get_framebuffer() and CX2341X_OSD_GET_FRAMEBUFFER, it has a get
  but not a setter. Its not clear if the firmware would make a split easy.
  We'd need ioremap_ucminus() here too and __arch_phys_wc_add().
 
 
 IMO this should be conceptually easy to split.  Once we get the
 framebuffer address, just unmap it (or don't prematurely map it) and
 then ioremap the thing.

The driver has split code for handling framebuffer devices, the framebuffer
base address will also vary depending on the type of device it has, for
some its on the encoder, for others its on the decoder. We'd have to account
for the removal of the framebuffer on either of those regions, and would also
need some vetting that the driver doesn't use areas beyond that for MMIO.
Using the trick you suggest though we could overlap ioremap calls and if that
truly works on PAT and non-PAT adding a new ioremap_wc() could do the trick,
I'd appreciate a Tested-by or Acked-by to be done with this. Mauro, any chance
we can get a tested-by of ivtvfb for both non-PAT and PAT systems with this:

diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..1838738 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,10 +44,6 @@
 #include linux/ivtvfb.h
 #include linux/slab.h
 
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
 #include ivtv-driver.h
 #include ivtv-cards.h
 #include ivtv-i2c.h
@@ -155,12 +151,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
 
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+   int wc_cookie;
 
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1094,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
 static int ivtvfb_init_io(struct ivtv *itv)
 {
struct osd_info *oi = itv-osd_info;
+   /* Find the largest power of two that maps the whole buffer */
+   int size_shift = 31;
 
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1120,7 +1117,7 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_buffer_size = 1704960;
 
oi-video_pbase = itv-base_addr + IVTV_DECODER_OFFSET + 
oi-video_rbase;
-   oi-video_vbase = itv-dec_mem + oi-video_rbase;
+   oi-video_vbase = ioremap_wc(oi-video_pbase, oi-video_buffer_size);
 
if (!oi-video_vbase) {
IVTVFB_ERR(abort, video memory 0x%x @ 0x%lx isn't mapped!\n,
@@ -1132,29 +1129,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
 
-#ifdef CONFIG_MTRR
-   {
-   /* Find the largest power of two that maps the whole buffer */
-   int size_shift = 31;
-
-   while (!(oi-video_buffer_size  (1  size_shift))) {
-   size_shift--;
-   }
-   size_shift++;
-   oi-fb_start_aligned_physaddr = oi-video_pbase  ~((1  
size_shift) - 1);
-   oi-fb_end_aligned_physaddr = oi-video_pbase + 
oi-video_buffer_size;
-   oi-fb_end_aligned_physaddr += (1  size_shift) - 1;
-   oi-fb_end_aligned_physaddr = ~((1  size_shift) - 1);
-   if (mtrr_add(oi-fb_start_aligned_physaddr,
-   oi-fb_end_aligned_physaddr - 
oi-fb_start_aligned_physaddr,
-MTRR_TYPE_WRCOMB, 1)  0) {
-   IVTVFB_INFO(disabled mttr\n);
-   oi-fb_start_aligned_physaddr = 0;
-   oi-fb_end_aligned_physaddr = 0;
-   }
-   }
-#endif
-
+   while (!(oi-video_buffer_size  (1  size_shift)))
+   size_shift--;
+   size_shift++;
+   oi-fb_start_aligned_physaddr = oi-video_pbase  ~((1  size_shift) - 
1);
+   oi-fb_end_aligned_physaddr = oi-video_pbase + oi-video_buffer_size;
+   oi-fb_end_aligned_physaddr += (1  size_shift) - 1;
+   oi-fb_end_aligned_physaddr = ~((1  size_shift) - 1);
+   oi-wc_cookie = arch_phys_wc_add(oi-fb_start_aligned_physaddr,
+oi-fb_end_aligned_physaddr -
+oi-fb_start_aligned_physaddr);
/* Blank the entire osd. */
memset_io(oi-video_vbase, 0, oi-video_buffer_size);
 
@@ -1172,14 +1156,8 @@ static void ivtvfb_release_buffers (struct ivtv *itv

Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR

2015-04-13 Thread Luis R. Rodriguez

Cc'ing a few others as we ended up talking about the cruxes of my
unposted v2 series as I confirmed that set_memor_wc() would not work
as an alternative to my originally proposed __arch_phys_wc_add() to
force MTRR as a last resort on a few set of last remaining drivers.
This also discusses overlapping ioremap() calls and what we'd need
for a default shift from UC- to strong UC.

On Fri, Apr 10, 2015 at 11:25:22PM -0700, Andy Lutomirski wrote:
 On Apr 10, 2015 6:29 PM, Luis R. Rodriguez mcg...@suse.com wrote:
 
  On Fri, Apr 10, 2015 at 02:22:51PM -0700, Andy Lutomirski wrote:
   On Fri, Apr 10, 2015 at 1:58 PM, Toshi Kani toshi.k...@hp.com wrote:
On Fri, 2015-04-10 at 23:05 +0200, Luis R. Rodriguez wrote:
On Fri, Apr 10, 2015 at 01:49:39PM -0600, Toshi Kani wrote:
 On Fri, 2015-04-10 at 12:34 -0700, Luis R. Rodriguez wrote:
  On Fri, Apr 10, 2015 at 12:14 PM, Andy Lutomirski 
  l...@amacapital.net wrote:
   On Fri, Apr 10, 2015 at 10:17 AM, Luis R. Rodriguez 
   mcg...@suse.com wrote:
  
   Andy, I'm ready to post a v2 series based on review of the 
   first iteration of
   the bury-MTRR series however I ran into a snag in vetting for 
   the ioremap_uc()
   followed by a set_memory_wc() strategy as a measure to both 
   avoid when possible
   overlapping ioremap*() calls and/or to avoid the power of 2 
   MTRR size
   implications on having to use multiple MTRRs.
  
   I tested the strategy by just making my thinkpad's i915 driver 
   use iremap_uc()
   which I add, and then use set_memory_wc(). To start off with I 
   should note
   set_memory_*() helpers are x86 specific right now, this is not 
   a problem for
   the series but its worth noting as we're replacing MTRR 
   strategies which
   are x86 specific, but I am having issues getting 
   set_memory_wc() take effect
   on my intel graphics card.
  
   I've reviewed if this is OK in code and I see no issues other 
   than set_memory_*()
   helpers seem to be desirable for RAM, not IO memory, so was 
   wondering if we need
   to add other helpers which can address IO memory or if this 
   should work? The diff
   for the drivers is below, the actual commit for adding 
   ioremap_uc() folllows
   with its commit log. Feedback / review on both is welcome as 
   well as if you
   could help me figure out why this test-patch for i915 fails.
  
   I think they should work for IO memory, but I'm not really an 
   authority here.
  
   Adding some people who have looked at the code recently.
 
  I was avoiding reviewing the cpa code but since this failed I just 
  had
  to review it and I see nothing prevent it from being used on IO 
  memory
  but -- memtype_rb_check_conflict() does prevent an overlap to be 
  set
  on an *existing range* -- and since ioremap_uc() was used earlier 
  the
  first reserve_memtype() with _PAGE_CACHE_MODE_WC by 
  set_memory_wc() I
  believe should fail then. Please correct me if I'm wrong, I don't 
  see
  the conflicting memory types print though, so not sure if it was
  because of that.
 
  I only started looking at this though but shouldn't this also mean 
  we
  can't use overlapping ioremap() calls too? I thought that worked,
  because at least some drivers are using that strategy.

 set_memory_*() does not work with I/O memory ranges with the 
 following
 reasons:

 1. __pa(addr) returns a fake address since there is no direct map.
 2. reserve_memtype() tracks regular memory and I/O memory 
 differently.
 For regular memory, set_memory_*() can modify WB with a new type 
 since
 reserve_memtype() does not track WB.  For I/O memory, 
 reserve_memtype()
 detects a conflict when a given type is different from a tracked 
 type.
   
Interesting, but I also just realized I had messed up my test patch 
too,
I checked for (!ret) instead of (ret). This works now.
   
  diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
  b/drivers/gpu/drm/i915/i915_gem_gtt.c
  index dccdc8a..dd9501b 100644
  --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
  +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
  @@ -1958,12 +1958,22 @@ static int ggtt_probe_common(struct 
  drm_device *dev,
  gtt_phys_addr = pci_resource_start(dev-pdev, 0) +
  (pci_resource_len(dev-pdev, 0) / 2);
 
  -   dev_priv-gtt.gsm = ioremap_wc(gtt_phys_addr, gtt_size);
  +   dev_priv-gtt.gsm = ioremap_uc(gtt_phys_addr, gtt_size);
  if (!dev_priv-gtt.gsm) {
  DRM_ERROR(Failed to map the gtt page table\n);
  return -ENOMEM;
  }
 
  +   printk(mcgrof:set_memory_wc() ggtt_probe_common()\n

[PATCH v1 15/47] [media] media: ivtv: use __arch_phys_wc_add()

2015-03-20 Thread Luis R. Rodriguez

From: Luis R. Rodriguez mcg...@suse.com

Sadly this driver requires a bit of work in order
to use ioremap_wc() on the range currently used
for MTRR write-combining. We'd need to ensure two
ioremap() calls are done. Annotate this.

Cc: Andy Lutomirski l...@amacapital.net
Cc: Andy Walls awa...@md.metrocast.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: venkatesh.pallip...@intel.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/media/pci/ivtv/ivtvfb.c | 51 +++--
 1 file changed, 14 insertions(+), 37 deletions(-)

diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..ceefa6f 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,10 +44,6 @@
 #include linux/ivtvfb.h
 #include linux/slab.h
 
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
-#endif
-
 #include ivtv-driver.h
 #include ivtv-cards.h
 #include ivtv-i2c.h
@@ -155,12 +151,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
 
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+   int wc_cookie;
 
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1094,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
 static int ivtvfb_init_io(struct ivtv *itv)
 {
struct osd_info *oi = itv-osd_info;
+   /* Find the largest power of two that maps the whole buffer */
+   int size_shift = 31;
 
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1132,29 +1129,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
 
-#ifdef CONFIG_MTRR
-   {
-   /* Find the largest power of two that maps the whole buffer */
-   int size_shift = 31;
-
-   while (!(oi-video_buffer_size  (1  size_shift))) {
-   size_shift--;
-   }
-   size_shift++;
-   oi-fb_start_aligned_physaddr = oi-video_pbase  ~((1  
size_shift) - 1);
-   oi-fb_end_aligned_physaddr = oi-video_pbase + 
oi-video_buffer_size;
-   oi-fb_end_aligned_physaddr += (1  size_shift) - 1;
-   oi-fb_end_aligned_physaddr = ~((1  size_shift) - 1);
-   if (mtrr_add(oi-fb_start_aligned_physaddr,
-   oi-fb_end_aligned_physaddr - 
oi-fb_start_aligned_physaddr,
-MTRR_TYPE_WRCOMB, 1)  0) {
-   IVTVFB_INFO(disabled mttr\n);
-   oi-fb_start_aligned_physaddr = 0;
-   oi-fb_end_aligned_physaddr = 0;
-   }
-   }
-#endif
-
+   while (!(oi-video_buffer_size  (1  size_shift)))
+   size_shift--;
+   size_shift++;
+   oi-fb_start_aligned_physaddr = oi-video_pbase  ~((1  size_shift) - 
1);
+   oi-fb_end_aligned_physaddr = oi-video_pbase + oi-video_buffer_size;
+   oi-fb_end_aligned_physaddr += (1  size_shift) - 1;
+   oi-fb_end_aligned_physaddr = ~((1  size_shift) - 1);
+   oi-wc_cookie = __arch_phys_wc_add(oi-fb_start_aligned_physaddr,
+  oi-fb_end_aligned_physaddr -
+  oi-fb_start_aligned_physaddr);
/* Blank the entire osd. */
memset_io(oi-video_vbase, 0, oi-video_buffer_size);
 
@@ -1172,14 +1156,7 @@ static void ivtvfb_release_buffers (struct ivtv *itv)
 
/* Release pseudo palette */
kfree(oi-ivtvfb_info.pseudo_palette);
-
-#ifdef CONFIG_MTRR
-   if (oi-fb_end_aligned_physaddr) {
-   mtrr_del(-1, oi-fb_start_aligned_physaddr,
-   oi-fb_end_aligned_physaddr - 
oi-fb_start_aligned_physaddr);
-   }
-#endif
-
+   arch_phys_wc_del(oi-wc_cookie);
kfree(oi

[ANN] Kernel integration now merged on backports

2014-11-18 Thread Luis R. Rodriguez

Full kernel integration is now merged as part of Linux
backports-20141114. I've written a bit about it [0] [1], what we need
now are users and developer to give this a good spin as we wind down
for the v3.19 release, which will be the first release that will
support kernel integration down to any kernel = 3.0 -- for now you
can use the backports-20141114 tag which uses as base supported
drivers from next-20141114. What this will mean is that you can opt in
to integrate any device driver we support from any future backports
release into any of = 3.0 kernel with full kconfig support, enabling
you to build everything as built-in. For all this you won't be using
the packaged releases [2], instead you'll use the git tree directly as
documented.

[0] 
http://www.do-not-panic.com/2014/11/automating-backport-kernel-integration.html
[1] https://backports.wiki.kernel.org/index.php/Documentation/integration
[2] https://backports.wiki.kernel.org/index.php/Documentation/packaging

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: randconfig build error with next-20140829, in drivers/media/usb/dvb-usb/technisat-usb2.c

2014-08-30 Thread Luis R. Rodriguez

On Fri, Aug 29, 2014 at 09:19:42AM -0700, Jim Davis wrote:
 Building with the attached random configuration file,
 
   LD  init/built-in.o
 drivers/built-in.o: In function `technisat_usb2_set_voltage':
 technisat-usb2.c:(.text+0x3b4919): undefined reference to `stv090x_set_gpio'
 make: *** [vmlinux] Error 1

This is because MEDIA_SUBDRV_AUTOSELECT is designed to let you
pick and choose, technically we should just have:

diff --git a/drivers/media/usb/dvb-usb/Kconfig 
b/drivers/media/usb/dvb-usb/Kconfig
index c5d9566..5a4e82e 100644
--- a/drivers/media/usb/dvb-usb/Kconfig
+++ b/drivers/media/usb/dvb-usb/Kconfig
@@ -313,7 +313,7 @@ config DVB_USB_AZ6027
 config DVB_USB_TECHNISAT_USB2
tristate Technisat DVB-S/S2 USB2.0 support
depends on DVB_USB
-   select DVB_STV090x if MEDIA_SUBDRV_AUTOSELECT
+   select DVB_STV090x
select DVB_STV6110x if MEDIA_SUBDRV_AUTOSELECT
help
  Say Y here to support the Technisat USB2 DVB-S/S2 device

and that would fix the issue you saw but then again if we do that
we might as well also do the same for DVB_STV6110x and a slew of
different Kconfig entries on that file.

Someone needs to make a judgement call and either fix all these
Kconfig entries or document that MEDIA_SUBDRV_AUTOSELECT will
let you shoot yourself in the foot at build time. Then what
I recommend in the meantime is simply to not trust randomconfig
builds unless you are always enabling MEDIA_SUBDRV_AUTOSELECT.

I think its fair to expect for 'make randomconfig' to give you
a configuration that lets you build things without issue so
I see this more of an issue with MEDIA_SUBDRV_AUTOSELECT and
this sloppy embedded craze.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Removal of regulator framework

2014-07-23 Thread Luis R. Rodriguez

On Sat, Jul 19, 2014 at 9:19 AM, Hauke Mehrtens ha...@hauke-m.de wrote:
 Maintaining the regulator drivers in backports costs some time and I do
 not need them. Is anybody using the regulator drivers from backports? I
 would like to remove them.

That came simply from collateral of backporting media drivers,
eventually I started running into device drivers that used the
regulator framework. Since we have tons of media drivers perhaps the
more sensible thing to do is to white list a set of media divers that
people actually care and then we just nuke both regulator and media
drivers that no one cares for. For that though I'd like to ask media
folks.

Here's a list of media drivers I know SUSE does support, in case that
helps. Right now backports carries all of drivers/media though.

drivers/media/common/btcx-risc  # some
code shared by bttv and cx88xx drivers
drivers/media/common/cx2341x
drivers/media/common/saa7146/saa7146
drivers/media/common/saa7146/saa7146_vv
drivers/media/common/tveeprom
drivers/media/i2c/adv7170   #
Analog Devices ADV7170 video encoder driver
drivers/media/i2c/adv7175   #
Analog Devices ADV7175 video encoder driver
drivers/media/i2c/bt819 #
Brooktree-819 video decoder driver
drivers/media/i2c/bt856 #
Brooktree-856A video encoder driver
drivers/media/i2c/cs5345
drivers/media/i2c/cs53l32a  #
cs53l32a (Adaptec AVC-2010 and AVC-2410) i2c ivtv driver
drivers/media/i2c/cx25840/cx25840   #
Conexant CX25840 audio/video decoder driver
drivers/media/i2c/ir-kbd-i2c#
input driver for i2c IR remote controls
drivers/media/i2c/ks0127
drivers/media/i2c/m52790
drivers/media/i2c/msp3400   #
device driver for msp34xx TV sound processor
drivers/media/i2c/saa6588   #
Philips SAA6588 RDS decoder
drivers/media/i2c/saa7110   #
Philips SAA7110 video decoder driver
drivers/media/i2c/saa7115   #
Philips SAA7111/13/14/15/18 video decoder driver
drivers/media/i2c/saa7127   #
Philips SAA7127/SAA7129 video encoder driver
drivers/media/i2c/saa717x
drivers/media/i2c/saa7185   #
Philips SAA7185 video encoder driver
drivers/media/i2c/tda7432   # bttv
driver for the tda7432 audio processor chip
drivers/media/i2c/tda9840
drivers/media/i2c/tea6415c
drivers/media/i2c/tea6420
drivers/media/i2c/tvaudio   #
device driver for various i2c TV sound decoder / audiomux chips
drivers/media/i2c/tvp5150   #
Texas Instruments TVP5150A(M) video decoder driver
drivers/media/i2c/upd64031a
drivers/media/i2c/upd64083
drivers/media/i2c/vp27smpx
drivers/media/i2c/vpx3220   #
vpx3220a/vpx3216b/vpx3214c video encoder driver
drivers/media/i2c/wm8739
drivers/media/i2c/wm8775
drivers/media/pci/bt8xx/bttv
drivers/media/pci/cx88/cx88-alsa
drivers/media/pci/cx88/cx88-blackbird
drivers/media/pci/cx88/cx8800
drivers/media/pci/cx88/cx8802
drivers/media/pci/cx88/cx88xx
drivers/media/pci/ivtv/ivtv
drivers/media/pci/ivtv/ivtvfb
drivers/media/pci/meye/meye
drivers/media/pci/saa7134/saa6752hs #
device driver for saa6752hs MPEG2 encoder
drivers/media/pci/saa7134/saa7134
drivers/media/pci/saa7134/saa7134-alsa
drivers/media/pci/saa7134/saa7134-empress
drivers/media/pci/saa7146/hexium_gemini
drivers/media/pci/saa7146/hexium_orion
drivers/media/pci/saa7146/mxb   #
video4linux-2 driver for the Siemens-Nixdorf 'Multimedia eXtension
board'
drivers/media/pci/zoran/videocodec  #
Intermediate API module for video codecs
drivers/media/pci/zoran/zr36016
drivers/media/pci/zoran/zr36050
drivers/media/pci/zoran/zr36060
drivers/media/pci/zoran/zr36067
drivers/media/platform/vivi
drivers/media/radio/dsbr100
drivers/media/radio/radio-maxiradio #
Radio driver for the Guillemot Maxi Radio FM2000 radio.
drivers/media/radio/si470x/radio-usb-si470x

Re: Removal of regulator framework

2014-07-23 Thread Luis R. Rodriguez

On Wed, Jul 23, 2014 at 10:57 AM, Mauro Carvalho Chehab
m.che...@samsung.com wrote:
 Em Wed, 23 Jul 2014 10:13:28 -0700
 Luis R. Rodriguez mcg...@do-not-panic.com escreveu:

 On Sat, Jul 19, 2014 at 9:19 AM, Hauke Mehrtens ha...@hauke-m.de wrote:
  Maintaining the regulator drivers in backports costs some time and I do
  not need them. Is anybody using the regulator drivers from backports? I
  would like to remove them.

 That came simply from collateral of backporting media drivers,
 eventually I started running into device drivers that used the
 regulator framework. Since we have tons of media drivers perhaps the
 more sensible thing to do is to white list a set of media divers that
 people actually care and then we just nuke both regulator and media
 drivers that no one cares for. For that though I'd like to ask media
 folks.

 Hi Luis,

 The drivers that currently use regulators are mostly the ones at
 drivers/media/platform, plus the corresponding I2C drivers for their
 webcam sensors, under drivers/media/i2c.

 I think that there's one exception though: em28xx. This driver can use
 some sensor drivers, as it supports a few webcams. This is one of
 the most used USB media driver, as there are lots of USB supported
 on it, supporting 4 types of devices on it: analog TV, capture card,
 digital TV and webcam.

 The webcam part of em28xx is not that relevant, as there are very few
 models using it. However, currently, it is not possible to just
 disable webcam support. It shouldn't be hard to make webcam support
 optional on it, as it has already sub-drivers for V4L2, DVB, ALSA and
 remote controller. One additional driver for webcam, that could be
 disabled at the backport tree shouldn't be hard to do. If you want it,
 patches are welcome.

Thanks for the details Mauro, are you aware of current or future uses
of backports for media at this point? Adding media drivers was more of
an experiment to see how hard or easy it would be to add a new
unrelated subsystem, we carry it now and as collateral also carry some
regulator drivers but its not clear the value in terms of users, so
hence Hauke's question of removal of the regulator drivers. It'd be
good to limit the drivers we carry to what folks actually use and care
about.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Removal of regulator framework

2014-07-23 Thread Luis R. Rodriguez

On Wed, Jul 23, 2014 at 11:56 AM, Hauke Mehrtens ha...@hauke-m.de wrote:
 carrying some regularity drivers which are needed for some specific
 media driver does not look like a big problem. The current problem from
 my side is that we carry all regularity drivers by default and that
 causes some problems. Many of these driver are used only on one specific
 SoC product line and uses their often changing interface, so they break
 often.

 When all the regulator drivers are only needed for the media driver I
 would add just add the driver which are actually used by a shipped media
 driver and nothing more.

Makes sense. I'm suggesting we can trim even more by only keeping
media drivers we really should care for and its dependencies. We need
a white list then, do we want to start off with perhaps the list I
posted? Media folks, is there anything else we should carry that would
help the media folks?

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/22] Add and use pci_zalloc_consistent

2014-06-23 Thread 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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] media: make drivers use their own namespace

Couple of changes to help with backports, both to help with ensuring
drivers use their own namespace.

Luis R. Rodriguez (2):
  technisat-usb2: rename led enums to be specific to driver
  bt8xx: make driver routines fit into its own namespcae

 drivers/media/pci/bt8xx/dst.c  | 20 ++--
 drivers/media/usb/dvb-usb/technisat-usb2.c | 28 ++--
 2 files changed, 24 insertions(+), 24 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] technisat-usb2: rename led enums to be specific to driver

From: Luis R. Rodriguez mcg...@suse.com

The current names clash with include/linux/leds.h namespace,
although there is no compile issue currently this does affect
backports. Drivers should also try to avoid generic namespaces
for things like this.

Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Felipe Pena felipe...@gmail.com
Cc: Michael Krufky mkru...@linuxtv.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/media/usb/dvb-usb/technisat-usb2.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/technisat-usb2.c 
b/drivers/media/usb/dvb-usb/technisat-usb2.c
index 98d24ae..d947e03 100644
--- a/drivers/media/usb/dvb-usb/technisat-usb2.c
+++ b/drivers/media/usb/dvb-usb/technisat-usb2.c
@@ -214,10 +214,10 @@ static void technisat_usb2_frontend_reset(struct 
usb_device *udev)
 
 /* LED control */
 enum technisat_usb2_led_state {
-   LED_OFF,
-   LED_BLINK,
-   LED_ON,
-   LED_UNDEFINED
+   TECH_LED_OFF,
+   TECH_LED_BLINK,
+   TECH_LED_ON,
+   TECH_LED_UNDEFINED
 };
 
 static int technisat_usb2_set_led(struct dvb_usb_device *d, int red, enum 
technisat_usb2_led_state state)
@@ -229,14 +229,14 @@ static int technisat_usb2_set_led(struct dvb_usb_device 
*d, int red, enum techni
0
};
 
-   if (disable_led_control  state != LED_OFF)
+   if (disable_led_control  state != TECH_LED_OFF)
return 0;
 
switch (state) {
-   case LED_ON:
+   case TECH_LED_ON:
led[1] = 0x82;
break;
-   case LED_BLINK:
+   case TECH_LED_BLINK:
led[1] = 0x82;
if (red) {
led[2] = 0x02;
@@ -251,7 +251,7 @@ static int technisat_usb2_set_led(struct dvb_usb_device *d, 
int red, enum techni
break;
 
default:
-   case LED_OFF:
+   case TECH_LED_OFF:
led[1] = 0x80;
break;
}
@@ -310,11 +310,11 @@ static void technisat_usb2_green_led_control(struct 
work_struct *work)
goto schedule;
 
if (ber  1000)
-   technisat_usb2_set_led(state-dev, 0, 
LED_BLINK);
+   technisat_usb2_set_led(state-dev, 0, 
TECH_LED_BLINK);
else
-   technisat_usb2_set_led(state-dev, 0, LED_ON);
+   technisat_usb2_set_led(state-dev, 0, 
TECH_LED_ON);
} else
-   technisat_usb2_set_led(state-dev, 0, LED_OFF);
+   technisat_usb2_set_led(state-dev, 0, TECH_LED_OFF);
}
 
 schedule:
@@ -365,9 +365,9 @@ static int technisat_usb2_power_ctrl(struct dvb_usb_device 
*d, int level)
return 0;
 
/* green led is turned off in any case - will be turned on when tuning 
*/
-   technisat_usb2_set_led(d, 0, LED_OFF);
+   technisat_usb2_set_led(d, 0, TECH_LED_OFF);
/* red led is turned on all the time */
-   technisat_usb2_set_led(d, 1, LED_ON);
+   technisat_usb2_set_led(d, 1, TECH_LED_ON);
return 0;
 }
 
@@ -667,7 +667,7 @@ static int technisat_usb2_rc_query(struct dvb_usb_device *d)
return 0;
 
if (!disable_led_control)
-   technisat_usb2_set_led(d, 1, LED_BLINK);
+   technisat_usb2_set_led(d, 1, TECH_LED_BLINK);
 
return 0;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] bt8xx: make driver routines fit into its own namespcae

From: Luis R. Rodriguez mcg...@suse.com

There is a few conflicts with older symbols on older kernels so we
have to patch this driver when backporting. Instead just make these
routines specific to the driver.

Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: linux-media@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/media/pci/bt8xx/dst.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/media/pci/bt8xx/dst.c b/drivers/media/pci/bt8xx/dst.c
index 430b3eb..f2261df 100644
--- a/drivers/media/pci/bt8xx/dst.c
+++ b/drivers/media/pci/bt8xx/dst.c
@@ -1544,7 +1544,7 @@ static int dst_send_burst(struct dvb_frontend *fe, 
fe_sec_mini_cmd_t minicmd)
 }
 
 
-static int dst_init(struct dvb_frontend *fe)
+static int bt8xx_dst_init(struct dvb_frontend *fe)
 {
struct dst_state *state = fe-demodulator_priv;
 
@@ -1707,7 +1707,7 @@ static int dst_get_frontend(struct dvb_frontend *fe)
return 0;
 }
 
-static void dst_release(struct dvb_frontend *fe)
+static void bt8xx_dst_release(struct dvb_frontend *fe)
 {
struct dst_state *state = fe-demodulator_priv;
if (state-dst_ca) {
@@ -1776,8 +1776,8 @@ static struct dvb_frontend_ops dst_dvbt_ops = {
FE_CAN_GUARD_INTERVAL_AUTO
},
 
-   .release = dst_release,
-   .init = dst_init,
+   .release = bt8xx_dst_release,
+   .init = bt8xx_dst_init,
.tune = dst_tune_frontend,
.set_frontend = dst_set_frontend,
.get_frontend = dst_get_frontend,
@@ -1801,8 +1801,8 @@ static struct dvb_frontend_ops dst_dvbs_ops = {
.caps = FE_CAN_FEC_AUTO | FE_CAN_QPSK
},
 
-   .release = dst_release,
-   .init = dst_init,
+   .release = bt8xx_dst_release,
+   .init = bt8xx_dst_init,
.tune = dst_tune_frontend,
.set_frontend = dst_set_frontend,
.get_frontend = dst_get_frontend,
@@ -1834,8 +1834,8 @@ static struct dvb_frontend_ops dst_dvbc_ops = {
FE_CAN_QAM_256
},
 
-   .release = dst_release,
-   .init = dst_init,
+   .release = bt8xx_dst_release,
+   .init = bt8xx_dst_init,
.tune = dst_tune_frontend,
.set_frontend = dst_set_frontend,
.get_frontend = dst_get_frontend,
@@ -1857,8 +1857,8 @@ static struct dvb_frontend_ops dst_atsc_ops = {
.caps = FE_CAN_FEC_AUTO | FE_CAN_QAM_AUTO | FE_CAN_QAM_64 | 
FE_CAN_QAM_256 | FE_CAN_8VSB
},
 
-   .release = dst_release,
-   .init = dst_init,
+   .release = bt8xx_dst_release,
+   .init = bt8xx_dst_init,
.tune = dst_tune_frontend,
.set_frontend = dst_set_frontend,
.get_frontend = dst_get_frontend,
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

3 linux-next based backports releases

3 new linux backports release are now available based on linux-next
tags next-20140320 [0] next-20140411 [1] and next-20140417 [2]. This
should mean that we can keep things in synch now almost daily, and
drivers can be tested with the latest code as-is on linux-next. We've
shaved off kernel support for kernels older than 3.0 in order to help
scale the project. We've also have added 2 new SmPL patches to help
backports backport two pain in the ass collateral evolutions
automatically. Please note that the patches/ directory is now all
tidied up -- folks interested in playing with SmPL can try to help by
seeing if they can use SmPL grammer to formalize a collateral
evolution backport. We have a bit of examples now. For more details
please refer to the wiki [3] or git tree.

[0] 
http://www.kernel.org/pub/linux/kernel/projects/backports/2014/03/20/backports-20140320.tar.xz
[1] 
https://www.kernel.org/pub/linux/kernel/projects/backports/2014/04/11/backports-20140411.tar.xz
[2] 
https://www.kernel.org/pub/linux/kernel/projects/backports/2014/04/17/backports-20140417.tar.xz
[3] http://backports.wiki.kernel.org

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANNOUNCE] backports-3.14-1 released

  backports: refresh on next-20140131
  backports: add led_trigger_blink{_oneshot}()
  backports: remove bluetooth HIDP transport-driver functions
  backports: add compat_put_timespec()
  backports: update sch_fq_codel_core.c
  backports: update test kernel versions
  backports: refresh patches on next-20140207
  backports: REGULATOR_S5M8767 depends on kernel 3.15
  backports: add ipv6_addr_hash()
  backports: add ETH_P_TEB and ETH_P_8021AD
  backports: copy cordic from kernel
  backports: copy sch_codel.c from kernel
  backports: copy sch_fq_codel.c from kernel
  backports: fix indenting
  backports: add atomic64_set()
  backports: add VHCI_MINOR
  backports: add snd_card_new()
  backports: add pci_enable_msi_range()
  backports: add pci_enable_msix_range()
  backports: add devm_kstrdup()
  backports: add of_property_count_u32_elems()
  backports: add of_property_read_u32_index()
  backports: add NLA_S{9,16,32,64}
  backports: remove usage of net_device member qdisc_tx_busylock
  backports: refresh patches on next-20140221

Ido Yariv (1):
  backports: backport ACPI_HANDLE(dev)

Johannes Berg (9):
  ckmake: sort kernel releases properly
  backports: backport hex2bin()
  gentree: combine spatches (unless using --gitdebug)
  backports: backport multicast list handling in iwlwifi mvm
  backports: backport power efficient workqueues
  backports: make BACKPORT_BUILD_LEDS depend on LEDS_CLASS=n
  backports: conditionally access net/ieee802154/ with make
  backports: fix compilation with CONFIG_OF
  backports: add crypto/ccm backport

Luis R. Rodriguez (25):
  backports: backport ktime_to_ms()
  backports: backport getrawmonotonic() with 
do_posix_clock_monotonic_gettime()
  backports: refresh patches for next-20131206
  backports: add Python based backports-update-manager
  backports: convert the 62-usb_driver_lpm patch series to SmPL
  backports: convert 11-dev-pm-ops patch series to SmPL
  backports: refresh patches for next-20131206 a second time
  backports: backport MPLS support
  backports: make WL1251_SPI depend on = 3.5
  backports: bump kernel reqs for WL1251_SDIO and WLCORE_SDIO
  backports: bump drivers dependency that require I2C bus classes
  backports: define ETH_P_80221
  backports: backport definition of struct frag_queue
  backports: backport skb_unclone()
  backports: backport frag helper functions for mem limit tracking
  backports: backport inet_frag_maybe_warn_overflow()
  backports: add threaded Coccinelle spatch support
  backports: use --ignore-removal for git add
  backports: add git diff support to lib/bpgit.py
  backports: add support for testing only a single Coccinelle SmPL patch
  backports: add Coccinelle SmPL profiling support to gentree.py
  Revert backports: backport MPLS support
  backports: remove bluetooth HIDP backport
  backports: bump bluetooth backport to require = 2.6.39
  backports: refresh patches for v3.14

Stefan Assmann (12):
  backports: igb fixes for linux-3.13
  backports: igb fixes for linux-3.12
  backports: igb fixes for linux-3.9
  backports: igb fixes for linux-3.8
  backports: igb fixes for linux-3.7
  backports: igb fixes for linux-3.6
  backports: igb fixes for linux-3.5
  backports: igb fixes for linux-3.4
  backports: igb fixes for linux-3.3
  backports: igb fixes for linux-3.2
  backports: igb fixes for linux-3.1
  backports: enable igb and add defconfig

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANNOUNCE] backports-3.15-rc1 is released

Linux backports [0] backports-v3.15-rc1 is out [1]. Please
go test and see if you can and break things or if see if
we've broken anything so far before a final release in
sync with Linus' releases. As usual development only happens
on the master branch, we'll then carry fixes onto the stable
branch. It just so happens that today's master branch is
exactly as we have it on the linux-3.15.y branch.

[0] https://backports.wiki.kernel.org/
[1] 
https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.15-rc1/backports-3.15-rc1-1.tar.xz

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rtl28xxu: do not hard depend on staging SDR module

2014-04-09 Thread Luis R. Rodriguez

On Wed, Apr 9, 2014 at 9:14 AM, Antti Palosaari cr...@iki.fi wrote:
 +extern struct dvb_frontend *rtl2832_sdr_attach(struct dvb_frontend *fe,
 +   struct i2c_adapter *i2c, const struct rtl2832_config *cfg,
 +   struct v4l2_subdev *sd);


Thanks for the patch! Joe has been going on a crusade to remove
externs as they are not needed, if we can avoid adding new ones
that'll prevent another followp cleanup patch.

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 1/2] rtl28xxu: do not hard depend on staging SDR module

2014-04-09 Thread Luis R. Rodriguez

On Wed, Apr 9, 2014 at 2:32 PM, Antti Palosaari cr...@iki.fi wrote:
 +extern struct dvb_frontend *rtl2832_sdr_attach(struct dvb_frontend *fe,
 +   struct i2c_adapter *i2c, const struct rtl2832_config *cfg,
 +   struct v4l2_subdev *sd);

extern

  Luis
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/7] backports: add media subsystem drivers

2013-04-13 Thread Luis R. Rodriguez

From: Luis R. Rodriguez mcg...@do-not-panic.com

This adds backport support for all media subsystem
drivers. This is enabled only for = 3.2. Some media
drivers rely on the new probe deferrral mechanism
(-EPROBE_DEFER see commit d1c3414c), those are only
enabled for kernels = 3.4. Some media drivers only
depend on the regulatory but since we only support
backporting the regulatory on kernels = 3.4 we only
enable those media drivers for = 3.4.

This backports 433 media drivers.

1   2.6.24  [  OK  ]
2   2.6.25  [  OK  ]
3   2.6.26  [  OK  ]
4   2.6.27  [  OK  ]
5   2.6.28  [  OK  ]
6   2.6.29  [  OK  ]
7   2.6.30  [  OK  ]
8   2.6.31  [  OK  ]
9   2.6.32  [  OK  ]
10  2.6.33  [  OK  ]
11  2.6.34  [  OK  ]
12  2.6.35  [  OK  ]
13  2.6.36  [  OK  ]
14  2.6.37  [  OK  ]
15  2.6.38  [  OK  ]
16  2.6.39  [  OK  ]
17  3.0.65  [  OK  ]
18  3.1.10  [  OK  ]
19  3.2.38  [  OK  ]
20  3.3.8   [  OK  ]
21  3.4.32  [  OK  ]
22  3.5.7   [  OK  ]
23  3.6.11  [  OK  ]
24  3.7.9   [  OK  ]
25  3.8.0   [  OK  ]
26  3.9-rc1 [  OK  ]

real39m35.615s
user1068m47.428s
sys 155m55.657s

Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
 backport/.blacklist.map|1 +
 backport/Kconfig   |1 +
 backport/Makefile.kernel   |1 +
 backport/defconfigs/media  |  506 
 copy-list  |   17 +
 dependencies   |   44 ++
 .../collateral-evolutions/media/0001-pr_fmt.patch  |  493 +++
 .../media/0002-dma_mmap_coherent-revert.patch  |   58 +++
 .../media/0003-technisat-usb2-led-rename.patch |   83 
 9 files changed, 1204 insertions(+)
 create mode 100644 backport/defconfigs/media
 create mode 100644 patches/collateral-evolutions/media/0001-pr_fmt.patch
 create mode 100644 
patches/collateral-evolutions/media/0002-dma_mmap_coherent-revert.patch
 create mode 100644 
patches/collateral-evolutions/media/0003-technisat-usb2-led-rename.patch

diff --git a/backport/.blacklist.map b/backport/.blacklist.map
index dd58203..c1bdcfc 100644
--- a/backport/.blacklist.map
+++ b/backport/.blacklist.map
@@ -8,3 +8,4 @@
 # new-driver   old-driver
 iwlwifiiwlagn
 iwl4965iwlagn
+videodev   v4l2-compat-ioctl32
diff --git a/backport/Kconfig b/backport/Kconfig
index 6088bfe..2c75cd8 100644
--- a/backport/Kconfig
+++ b/backport/Kconfig
@@ -40,3 +40,4 @@ source drivers/gpu/drm/Kconfig
 source net/nfc/Kconfig
 
 source drivers/regulator/Kconfig
+source drivers/media/Kconfig
diff --git a/backport/Makefile.kernel b/backport/Makefile.kernel
index 2741cc9..27b44da 100644
--- a/backport/Makefile.kernel
+++ b/backport/Makefile.kernel
@@ -32,3 +32,4 @@ obj-$(CPTCFG_DRM) += drivers/gpu/drm/
 obj-$(CPTCFG_NFC) += net/nfc/
 obj-$(CPTCFG_NFC) += drivers/nfc/
 obj-$(CPTCFG_REGULATOR) += drivers/regulator/
+obj-$(CPTCFG_MEDIA_SUPPORT) += drivers/media/
diff --git a/backport/defconfigs/media b/backport/defconfigs/media
new file mode 100644
index 000..cbaf99f
--- /dev/null
+++ b/backport/defconfigs/media
@@ -0,0 +1,506 @@
+CPTCFG_DVB_A8293=y
+CPTCFG_DVB_AF9013=y
+CPTCFG_DVB_AF9033=y
+CPTCFG_DVB_ATBM8830=y
+CPTCFG_DVB_AU8522=y
+CPTCFG_DVB_AU8522_DTV=y
+CPTCFG_DVB_AU8522_V4L=y
+CPTCFG_DVB_AV7110=y
+CPTCFG_DVB_B2C2_FLEXCOP=y
+CPTCFG_DVB_B2C2_FLEXCOP_PCI=y
+CPTCFG_DVB_B2C2_FLEXCOP_USB=y
+CPTCFG_DVB_BCM3510=y
+CPTCFG_DVB_BT8XX=y
+CPTCFG_DVB_BUDGET=y
+CPTCFG_DVB_BUDGET_AV=y
+CPTCFG_DVB_BUDGET_CI=y
+CPTCFG_DVB_BUDGET_CORE=y
+CPTCFG_DVB_BUDGET_PATCH=y
+CPTCFG_DVB_CORE=y
+CPTCFG_DVB_CX22700=y
+CPTCFG_DVB_CX22702=y
+CPTCFG_DVB_CX24110=y
+CPTCFG_DVB_CX24116=y
+CPTCFG_DVB_CX24123=y
+CPTCFG_DVB_CXD2820R=y
+CPTCFG_DVB_DDBRIDGE=y
+CPTCFG_DVB_DIB3000MB=y
+CPTCFG_DVB_DIB3000MC=y
+CPTCFG_DVB_DIB7000M=y
+CPTCFG_DVB_DIB7000P=y
+CPTCFG_DVB_DIB8000=y
+CPTCFG_DVB_DIB9000=y
+CPTCFG_DVB_DM1105=y
+CPTCFG_DVB_DRXD=y
+CPTCFG_DVB_DRXK=y
+CPTCFG_DVB_DS3000=y
+CPTCFG_DVB_DUMMY_FE=y
+CPTCFG_DVB_EC100=y
+CPTCFG_DVB_FIREDTV=y
+CPTCFG_DVB_FIREDTV_INPUT=y
+CPTCFG_DVB_HD29L2=y
+CPTCFG_DVB_HOPPER=y
+CPTCFG_DVB_ISL6405=y
+CPTCFG_DVB_ISL6421=y
+CPTCFG_DVB_ISL6423=y
+CPTCFG_DVB_IT913X_FE=y
+CPTCFG_DVB_IX2505V=y
+CPTCFG_DVB_L64781=y
+CPTCFG_DVB_LG2160=y
+CPTCFG_DVB_LGDT3305=y
+CPTCFG_DVB_LGDT330X=y
+CPTCFG_DVB_LGS8GL5=y
+CPTCFG_DVB_LGS8GXX=y
+CPTCFG_DVB_LNBP21=y
+CPTCFG_DVB_LNBP22=y
+CPTCFG_DVB_M88RS2000=y
+CPTCFG_DVB_MANTIS=y
+CPTCFG_DVB_MB86A16=y
+CPTCFG_DVB_MB86A20S=y
+CPTCFG_DVB_MT312=y
+CPTCFG_DVB_MT352=y

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

2012-11-30 Thread 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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2012-11-30 Thread 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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/6] ie6xx_wdt: convert struct spinlock to spinlock_t

From: Luis R. Rodriguez mcg...@do-not-panic.com

spinlock_t should always be used.

  CHECK   drivers/watchdog/ie6xx_wdt.c
  CC [M]  drivers/watchdog/ie6xx_wdt.o
  Building modules, stage 2.
  MODPOST 43 modules
  LD [M]  drivers/watchdog/ie6xx_wdt.ko

Cc: Alexander Stein alexander.st...@systec-electronic.com
Reported-by: Hauke Mehrtens ha...@hauke-m.de
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
 drivers/watchdog/ie6xx_wdt.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/ie6xx_wdt.c b/drivers/watchdog/ie6xx_wdt.c
index e24ef6a..f2d6573 100644
--- a/drivers/watchdog/ie6xx_wdt.c
+++ b/drivers/watchdog/ie6xx_wdt.c
@@ -82,7 +82,7 @@ MODULE_PARM_DESC(resetmode,
 
 static struct {
unsigned short sch_wdtba;
-   struct spinlock unlock_sequence;
+   spinlock_t unlock_sequence;
 #ifdef CONFIG_DEBUG_FS
struct dentry *debugfs;
 #endif
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/6] brcmfmac: convert struct spinlock to spinlock_t

From: Luis R. Rodriguez mcg...@do-not-panic.com

spinlock_t should always be used.

  LD  drivers/net/wireless/brcm80211/built-in.o
  CHECK   drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.o
  CHECK   drivers/net/wireless/brcm80211/brcmfmac/fwil.c
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/fwil.o
  CHECK   drivers/net/wireless/brcm80211/brcmfmac/fweh.c
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/fweh.o
  CHECK   drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.c
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.o
  CHECK   drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/dhd_common.o
  CHECK   drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.o
  CHECK   drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.o
  CHECK   drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.o
  CHECK   drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.o
  CHECK   drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.o
  CHECK   drivers/net/wireless/brcm80211/brcmfmac/usb.c
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/usb.o
  CHECK   drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.c
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.o
  LD [M]  drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.o
  LD  drivers/net/wireless/brcm80211/brcmsmac/built-in.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c:1311:6: warning: context 
imbalance in 'brcms_down' - unexpected unlock
drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c:1598:6: warning: context 
imbalance in 'brcms_rfkill_set_hw_state' - unexpected unlock
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.c
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/ampdu.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/antsel.c
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/antsel.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/channel.c
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/channel.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/main.c
drivers/net/wireless/brcm80211/brcmsmac/main.c:6246:36: warning: Initializer 
entry defined twice
drivers/net/wireless/brcm80211/brcmsmac/main.c:6246:43:   also defined here
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/main.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/phy_shim.c
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy_shim.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/pmu.c
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/pmu.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/rate.c
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/rate.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/stf.c
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/stf.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/aiutils.c
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/aiutils.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c:3313:46: warning: cast 
truncates bits from constant value (7fff becomes 7fff)
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:17688:47: warning: cast 
truncates bits from constant value (7fff becomes 7fff)
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:18187:53: warning: cast 
truncates bits from constant value (3fff becomes 3fff)
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:21160:36: warning: cast 
truncates bits from constant value (3fff becomes 3fff)
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:23321:35: warning: cast 
truncates bits from constant value (7fff becomes 7fff)
drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:28343:44: warning: cast 
truncates bits from constant value (1fff becomes 1fff)
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.c
  CC [M]  drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.o
  CHECK   drivers/net/wireless/brcm80211/brcmsmac/phy/phy_qmath.c
  CC [M

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

From: Luis R. Rodriguez mcg...@do-not-panic.com

spinlock_t should always be used.

  LD  drivers/gpu/drm/i915/built-in.o
  CHECK   drivers/gpu/drm/i915/i915_drv.c
  CC [M]  drivers/gpu/drm/i915/i915_drv.o
  CHECK   drivers/gpu/drm/i915/i915_dma.c
  CC [M]  drivers/gpu/drm/i915/i915_dma.o
  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 3/6] s5p-fimc: convert struct spinlock to spinlock_t

From: Luis R. Rodriguez mcg...@do-not-panic.com

spinlock_t should always be used.

Could not get this to build with allmodconfig:

mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1 
M=drivers/media/platform/s5p-fimc/

  WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
   is missing; modules will have no dependencies and modversions.

  LD  drivers/media/platform/s5p-fimc/built-in.o
  Building modules, stage 2.
  MODPOST 0 modules

Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media@vger.kernel.org
Reported-by: Hauke Mehrtens ha...@hauke-m.de
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
 drivers/media/platform/s5p-fimc/mipi-csis.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-fimc/mipi-csis.c 
b/drivers/media/platform/s5p-fimc/mipi-csis.c
index 4c961b1..86c8775 100644
--- a/drivers/media/platform/s5p-fimc/mipi-csis.c
+++ b/drivers/media/platform/s5p-fimc/mipi-csis.c
@@ -187,7 +187,7 @@ struct csis_state {
const struct csis_pix_format *csis_fmt;
struct v4l2_mbus_framefmt format;
 
-   struct spinlock slock;
+   spinlock_t slock;
struct csis_pktbuf pkt_buf;
struct s5pcsis_event events[S5PCSIS_NUM_EVENTS];
 };
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/6] s5p-jpeg: convert struct spinlock to spinlock_t

From: Luis R. Rodriguez mcg...@do-not-panic.com

spinlock_t should always be used.

Could not get this to build with allmodconfig:

mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1 
M=drivers/media/platform/s5p-jpeg

  WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
   is missing; modules will have no dependencies and modversions.

  Building modules, stage 2.
  MODPOST 0 modules

Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media@vger.kernel.org
Reported-by: Hauke Mehrtens ha...@hauke-m.de
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
 drivers/media/platform/s5p-jpeg/jpeg-core.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.h 
b/drivers/media/platform/s5p-jpeg/jpeg-core.h
index 022b9b9..8a4013e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.h
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.h
@@ -62,7 +62,7 @@
  */
 struct s5p_jpeg {
struct mutexlock;
-   struct spinlock slock;
+   spinlock_t  slock;
 
struct v4l2_device  v4l2_dev;
struct video_device *vfd_encoder;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

From: Luis R. Rodriguez mcg...@do-not-panic.com

Turns out a few drivers have strayed away from using the
spinlock_t typedef and decided to use struct spinlock
directly. This series converts these drivers to use
spinlock_t. Each change has been compile tested with
allmodconfig and sparse checked. 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

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/6] ux500: convert struct spinlock to spinlock_t