* Re: [PATCH v4 2/6] x86: document WC MTRR effects on PAT / non-PAT pages
From: Borislav Petkov @ 2015-05-05 7:53 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Ville Syrjälä, luto, Randy Dunlap, Luis R. Rodriguez,
mingo, tglx, hpa, plagnioj, tomi.valkeinen, daniel.vetter,
airlied, dledford, awalls, mst, cocci, linux-kernel, Toshi Kani,
Jonathan Corbet, Dave Hansen, Suresh Siddha, Juergen Gross,
Daniel Vetter, Dave Airlie, Antonino Daplas, Mel Gorman,
Vlastimil Babka, Davidlohr Bueso, linux-fbdev
In-Reply-To: <20150505074634.GL5622@wotan.suse.de>
On Tue, May 05, 2015 at 09:46:34AM +0200, Luis R. Rodriguez wrote:
> If so since they depend on ioremap_uc() should it go through Boris as he's
> taking that in?
Let's slow down a bit first, ok? First let's have all the x86 changes
ready, in and tested. Drivers can convert to them in a following step.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
^ permalink raw reply
* [PATCH v5 2/6] x86: document WC MTRR effects on PAT / non-PAT pages
From: Luis R. Rodriguez @ 2015-05-05 7:53 UTC (permalink / raw)
To: bp
Cc: mingo, tglx, hpa, plagnioj, tomi.valkeinen, linux-fbdev, luto,
mst, syrjala, linux-kernel, Luis R. Rodriguez, Jonathan Corbet,
Dave Hansen, Suresh Siddha, Juergen Gross, Daniel Vetter,
Dave Airlie, Antonino Daplas, Mel Gorman, Vlastimil Babka,
Davidlohr Bueso
From: "Luis R. Rodriguez" <mcgrof@suse.com>
As part of the effort to phase out MTRR use document
write-combining MTRR effects on pages with different
non-PAT page attributes flags and different PAT entry
values. Extend arch_phys_wc_add() documentation to
clarify power of two sizes / boundary requirements as
we phase out mtrr_add() use.
Lastly hint towards ioremap_uc() for corner cases on
device drivers working with devices with mixed regions
where MTRR size requirements would otherwise not
enable write-combining effective memory types.
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ville Syrjälä <syrjala@sci.fi>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Borislav Petkov <bp@suse.de>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
This v5 goes with the documentation fixes proposed by Randy and Boris.
I am only sending the documentation patch with a followup v5 as the other
ones have not received any other negative feedback. Would also like to
hear back from Ville if he's OK with these changes to atyfb.
Documentation/x86/mtrr.txt | 18 +++++++++++++++---
Documentation/x86/pat.txt | 35 ++++++++++++++++++++++++++++++++++-
arch/x86/kernel/cpu/mtrr/main.c | 3 +++
3 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/Documentation/x86/mtrr.txt b/Documentation/x86/mtrr.txt
index cc071dc..860bc3a 100644
--- a/Documentation/x86/mtrr.txt
+++ b/Documentation/x86/mtrr.txt
@@ -1,7 +1,19 @@
MTRR (Memory Type Range Register) control
-3 Jun 1999
-Richard Gooch
-<rgooch@atnf.csiro.au>
+
+Richard Gooch <rgooch@atnf.csiro.au> - 3 Jun 1999
+Luis R. Rodriguez <mcgrof@do-not-panic.com> - April 9, 2015
+
+=======================================+Phasing out MTRR use
+
+MTRR use is replaced on modern x86 hardware with PAT. Over time the only type
+of effective MTRR that is expected to be supported will be for write-combining.
+As MTRR use is phased out device drivers should use arch_phys_wc_add() to make
+MTRR effective on non-PAT systems while a no-op on PAT enabled systems.
+
+For details refer to Documentation/x86/pat.txt.
+
+=======================================
On Intel P6 family processors (Pentium Pro, Pentium II and later)
the Memory Type Range Registers (MTRRs) may be used to control
diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
index cf08c9f..521bd8a 100644
--- a/Documentation/x86/pat.txt
+++ b/Documentation/x86/pat.txt
@@ -34,6 +34,8 @@ ioremap | -- | UC- | UC- |
| | | |
ioremap_cache | -- | WB | WB |
| | | |
+ioremap_uc | -- | UC | UC |
+ | | | |
ioremap_nocache | -- | UC- | UC- |
| | | |
ioremap_wc | -- | -- | WC |
@@ -102,7 +104,38 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
as step 0 above and also track the usage of those pages and use set_memory_wb()
before the page is freed to free pool.
-
+MTRR effects on PAT / non-PAT systems
+-------------------------------------
+
+The following table provides the effects of using write-combining MTRRs when
+using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
+mtrr_add() usage will be phased out in favor of arch_phys_wc_add() which will
+be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
+is made, should already have been ioremapped with WC attributes or PAT entries,
+this can be done by using ioremap_wc() / set_memory_wc(). Devices which
+combine areas of IO memory desired to remain uncacheable with areas where
+write-combining is desirable should consider use of ioremap_uc() followed by
+set_memory_wc() to white-list effective write-combined areas. Such use is
+nevertheless discouraged as the effective memory type is considered
+implementation defined, yet this strategy can be used as last resort on devices
+with size-constrained regions where otherwise MTRR write-combining would
+otherwise not be effective.
+
+----------------------------------------------------------------------
+MTRR Non-PAT PAT Linux ioremap value Effective memory type
+----------------------------------------------------------------------
+ Non-PAT | PAT
+ PAT
+ |PCD
+ ||PWT
+ |||
+WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
+WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
+WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | UC
+WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
+----------------------------------------------------------------------
+
+(*) denotes implementation defined and is discouraged
Notes:
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index c3ea014..2cc64b8 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -546,6 +546,9 @@ EXPORT_SYMBOL(mtrr_del);
* attempts to add a WC MTRR covering size bytes starting at base and
* logs an error if this fails.
*
+ * The called should provide a power of two size on an equivalent
+ * power of two boundary.
+ *
* Drivers must store the return value to pass to mtrr_del_wc_if_needed,
* but drivers should not try to interpret that return value.
*/
--
2.3.2.209.gd67f9d5.dirty
^ permalink raw reply related
* Re: [PATCH v4 2/6] x86: document WC MTRR effects on PAT / non-PAT pages
From: Luis R. Rodriguez @ 2015-05-05 7:46 UTC (permalink / raw)
To: Borislav Petkov, Ville Syrjälä, luto
Cc: Randy Dunlap, Luis R. Rodriguez, mingo, tglx, hpa, plagnioj,
tomi.valkeinen, daniel.vetter, airlied, dledford, awalls, mst,
cocci, linux-kernel, Toshi Kani, Jonathan Corbet, Dave Hansen,
Suresh Siddha, Juergen Gross, Daniel Vetter, Dave Airlie,
Antonino Daplas, Mel Gorman, Vlastimil Babka, Davidlohr Bueso,
linux-fbdev
In-Reply-To: <20150505072214.GA4199@pd.tnic>
On Tue, May 05, 2015 at 09:22:14AM +0200, Borislav Petkov wrote:
> On Tue, May 05, 2015 at 02:45:06AM +0200, Luis R. Rodriguez wrote:
> > Thanks since Boris took this already I'll let him amend unless he wishes for
> > me to send a new version.
>
> Haven't. I'm waiting for v2.
OK thanks, it'll be a v5 actually. I am only resending the documentation patch.
Ville, are you OK with the other atyfb patches that follow up on top of this?
If so since they depend on ioremap_uc() should it go through Boris as he's
taking that in?
Luis
^ permalink raw reply
* Re: [PATCH v4 2/6] x86: document WC MTRR effects on PAT / non-PAT pages
From: Luis R. Rodriguez @ 2015-05-05 7:35 UTC (permalink / raw)
To: Borislav Petkov
Cc: Luis R. Rodriguez, mingo, tglx, hpa, bp, plagnioj, tomi.valkeinen,
daniel.vetter, airlied, dledford, awalls, syrjala, luto, mst,
cocci, linux-kernel, Toshi Kani, Jonathan Corbet, Dave Hansen,
Suresh Siddha, Juergen Gross, Daniel Vetter, Dave Airlie,
Antonino Daplas, Mel Gorman, Vlastimil Babka, Davidlohr Bueso,
linux-fbdev
In-Reply-To: <20150504122303.GD4096@pd.tnic>
On Mon, May 04, 2015 at 02:23:03PM +0200, Borislav Petkov wrote:
> On Wed, Apr 29, 2015 at 02:44:07PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
> > As part of the effort to phase out MTRR use document
> > write-combining MTRR effects on pages with different
> > non-PAT page attributes flags and different PAT entry
> > values. Extend arch_phys_wc_add() documentation to
> > clarify power of two sizes / boundary requirements as
> > we phase out mtrr_add() use.
> >
> > Lastly hint towards ioremap_uc() for corner cases on
> > device drivers working with devices with mixed regions
> > where MTRR size requirements would otherwise not
> > enable write-combining effective memory types.
> >
> > Cc: Toshi Kani <toshi.kani@hp.com>
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Cc: Dave Hansen <dave.hansen@linux.intel.com>
> > Cc: Andy Lutomirski <luto@amacapital.net>
> > Cc: Suresh Siddha <sbsiddha@gmail.com>
> > Cc: Ingo Molnar <mingo@elte.hu>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Juergen Gross <jgross@suse.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Antonino Daplas <adaplas@gmail.com>
> > Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: Ville Syrjälä <syrjala@sci.fi>
> > Cc: Mel Gorman <mgorman@suse.de>
> > Cc: Vlastimil Babka <vbabka@suse.cz>
> > Cc: Borislav Petkov <bp@suse.de>
> > Cc: Davidlohr Bueso <dbueso@suse.de>
> > Cc: linux-fbdev@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> > ---
> > Documentation/x86/mtrr.txt | 18 +++++++++++++++---
> > Documentation/x86/pat.txt | 40 +++++++++++++++++++++++++++++++++++++++-
> > arch/x86/kernel/cpu/mtrr/main.c | 3 +++
> > 3 files changed, 57 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/x86/mtrr.txt b/Documentation/x86/mtrr.txt
> > index cc071dc..a111a6c 100644
> > --- a/Documentation/x86/mtrr.txt
> > +++ b/Documentation/x86/mtrr.txt
> > @@ -1,7 +1,19 @@
> > MTRR (Memory Type Range Register) control
> > -3 Jun 1999
> > -Richard Gooch
> > -<rgooch@atnf.csiro.au>
> > +
> > +Richard Gooch <rgooch@atnf.csiro.au> - 3 Jun 1999
> > +Luis R. Rodriguez <mcgrof@do-not-panic.com> - April 9, 2015
> > +
> > +=======================================> > +Phasing MTRR use
>
> "Phasing out...".
Fixed all, will send another version.
Luis
^ permalink raw reply
* Re: [PATCH v4 2/6] x86: document WC MTRR effects on PAT / non-PAT pages
From: Luis R. Rodriguez @ 2015-05-05 7:31 UTC (permalink / raw)
To: Randy Dunlap
Cc: Luis R. Rodriguez, mingo, tglx, hpa, bp, plagnioj, tomi.valkeinen,
daniel.vetter, airlied, dledford, awalls, syrjala, luto, mst,
cocci, linux-kernel, Toshi Kani, Jonathan Corbet, Dave Hansen,
Suresh Siddha, Juergen Gross, Daniel Vetter, Dave Airlie,
Antonino Daplas, Mel Gorman, Vlastimil Babka, Davidlohr Bueso,
linux-fbdev
In-Reply-To: <5542A628.8050705@infradead.org>
On Thu, Apr 30, 2015 at 03:01:12PM -0700, Randy Dunlap wrote:
> On 04/29/15 14:44, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
>
> > ---
> > Documentation/x86/mtrr.txt | 18 +++++++++++++++---
> > Documentation/x86/pat.txt | 40 +++++++++++++++++++++++++++++++++++++++-
> > arch/x86/kernel/cpu/mtrr/main.c | 3 +++
> > 3 files changed, 57 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
> > index cf08c9f..7e183e3 100644
> > --- a/Documentation/x86/pat.txt
> > +++ b/Documentation/x86/pat.txt
> > @@ -102,7 +104,43 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
> > as step 0 above and also track the usage of those pages and use set_memory_wb()
> > before the page is freed to free pool.
> >
> > -
> > +MTRR effects on PAT / non-PAT systems
> > +-------------------------------------
> > +
> > +The following table provides the effects of using write-combining MTRRs when
> > +using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> > +mtrr_add() usage will be phased in favor of arch_phys_wc_add() which will
> > +be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> > +is made should already have be ioremap'd with write-combining page attributes
> > +or PAT entries, this can be done by using ioremap_wc() / or respective helpers.
> > +Devices which combine areas of IO memory desired to remain uncachable with
>
> I would spell it uncacheable. In kernel Documentation/, grep uncacheable finds
> 14 hits vs. 6 hits for uncachable. No big deal.
Fixed.
> > +areas where write-combining is desirable and are restricted by the size
> > +requirements of MTRRs should consider splitting up their IO memory space
> > +cleanly with ioremap_uc() and ioremap_wc() followed by an arch_phys_wc_add()
> > +encompassing both regions. Such use is nevertheless heavily discouraged as
> > +the effective memory type is considered implementation defined. This strategy
> > +should only be used as last resort on devices with size-contrained regions
>
> size-constrained
Fixed.
> > +where otherwise MTRR write-combining would not be effective.
> > +
> > +Note that you cannot use set_memory_wc() to override / whitelist IO remapped
> > +memory space mapped with ioremap*() calls, set_memory_wc() can only be used
> > +on RAM.
> > +
> > +----------------------------------------------------------------------
> > +MTRR Non-PAT PAT Linux ioremap value Effective memory type
> > +----------------------------------------------------------------------
> > + Non-PAT | PAT
> > + PAT
> > + |PCD
> > + ||PWT
> > + |||
> > +WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
> > +WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
> > +WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | WC
> > +WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
> > +----------------------------------------------------------------------
> > +
> > +(*) denotes implementation defined and is discouraged
> >
> > Notes:
> >
> > diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> > index ea5f363..12abdbe 100644
> > --- a/arch/x86/kernel/cpu/mtrr/main.c
> > +++ b/arch/x86/kernel/cpu/mtrr/main.c
> > @@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
> > * attempts to add a WC MTRR covering size bytes starting at base and
> > * logs an error if this fails.
> > *
> > + * The caller should expect to need to provide a power of two size on an
>
> * The called should provide a power of two size on an equivalent
> * power of two boundary.
Fixed.
Luis
^ permalink raw reply
* Re: [PATCH v4 2/6] x86: document WC MTRR effects on PAT / non-PAT pages
From: Borislav Petkov @ 2015-05-05 7:22 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Randy Dunlap, Luis R. Rodriguez, mingo, tglx, hpa, plagnioj,
tomi.valkeinen, daniel.vetter, airlied, dledford, awalls, syrjala,
luto, mst, cocci, linux-kernel, Toshi Kani, Jonathan Corbet,
Dave Hansen, Suresh Siddha, Juergen Gross, Daniel Vetter,
Dave Airlie, Antonino Daplas, Mel Gorman, Vlastimil Babka,
Davidlohr Bueso, linux-fbdev
In-Reply-To: <20150505004506.GI5622@wotan.suse.de>
On Tue, May 05, 2015 at 02:45:06AM +0200, Luis R. Rodriguez wrote:
> Thanks since Boris took this already I'll let him amend unless he wishes for
> me to send a new version.
Haven't. I'm waiting for v2.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
^ permalink raw reply
* Re: [PATCH v4 2/6] x86: document WC MTRR effects on PAT / non-PAT pages
From: Luis R. Rodriguez @ 2015-05-05 0:45 UTC (permalink / raw)
To: Randy Dunlap
Cc: Luis R. Rodriguez, mingo, tglx, hpa, bp, plagnioj, tomi.valkeinen,
daniel.vetter, airlied, dledford, awalls, syrjala, luto, mst,
cocci, linux-kernel, Toshi Kani, Jonathan Corbet, Dave Hansen,
Suresh Siddha, Juergen Gross, Daniel Vetter, Dave Airlie,
Antonino Daplas, Mel Gorman, Vlastimil Babka, Davidlohr Bueso,
linux-fbdev
In-Reply-To: <5542A628.8050705@infradead.org>
On Thu, Apr 30, 2015 at 03:01:12PM -0700, Randy Dunlap wrote:
> On 04/29/15 14:44, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
> > index cf08c9f..7e183e3 100644
> > --- a/Documentation/x86/pat.txt
> > +++ b/Documentation/x86/pat.txt
> > @@ -102,7 +104,43 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
> > as step 0 above and also track the usage of those pages and use set_memory_wb()
> > before the page is freed to free pool.
> >
> > -
> > +MTRR effects on PAT / non-PAT systems
> > +-------------------------------------
> > +
> > +The following table provides the effects of using write-combining MTRRs when
> > +using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> > +mtrr_add() usage will be phased in favor of arch_phys_wc_add() which will
> > +be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> > +is made should already have be ioremap'd with write-combining page attributes
> > +or PAT entries, this can be done by using ioremap_wc() / or respective helpers.
> > +Devices which combine areas of IO memory desired to remain uncachable with
>
> I would spell it uncacheable. In kernel Documentation/, grep uncacheable finds
> 14 hits vs. 6 hits for uncachable. No big deal.
>
> > +areas where write-combining is desirable and are restricted by the size
> > +requirements of MTRRs should consider splitting up their IO memory space
> > +cleanly with ioremap_uc() and ioremap_wc() followed by an arch_phys_wc_add()
> > +encompassing both regions. Such use is nevertheless heavily discouraged as
> > +the effective memory type is considered implementation defined. This strategy
> > +should only be used as last resort on devices with size-contrained regions
>
> size-constrained
>
> > +where otherwise MTRR write-combining would not be effective.
> > +
> > +Note that you cannot use set_memory_wc() to override / whitelist IO remapped
> > +memory space mapped with ioremap*() calls, set_memory_wc() can only be used
> > +on RAM.
> > +
> > +----------------------------------------------------------------------
> > +MTRR Non-PAT PAT Linux ioremap value Effective memory type
> > +----------------------------------------------------------------------
> > + Non-PAT | PAT
> > + PAT
> > + |PCD
> > + ||PWT
> > + |||
> > +WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
> > +WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
> > +WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | WC
> > +WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
> > +----------------------------------------------------------------------
> > +
> > +(*) denotes implementation defined and is discouraged
> >
> > Notes:
> >
> > diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> > index ea5f363..12abdbe 100644
> > --- a/arch/x86/kernel/cpu/mtrr/main.c
> > +++ b/arch/x86/kernel/cpu/mtrr/main.c
> > @@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
> > * attempts to add a WC MTRR covering size bytes starting at base and
> > * logs an error if this fails.
> > *
> > + * The caller should expect to need to provide a power of two size on an
>
> * The called should provide a power of two size on an equivalent
> * power of two boundary.
>
Thanks since Boris took this already I'll let him amend unless he wishes for
me to send a new version.
Luis
^ permalink raw reply
* Re: [PATCH v3 00/17] framebuffer: simple conversions to arch_phys_wc_add()
From: Luis R. Rodriguez @ 2015-05-05 0:22 UTC (permalink / raw)
To: cocci
In-Reply-To: <55474AFE.5040605@ti.com>
On Mon, May 04, 2015 at 01:33:34PM +0300, Tomi Valkeinen wrote:
> On 29/04/15 22:18, Luis R. Rodriguez wrote:
> > On Tue, Apr 21, 2015 at 1:16 PM, Luis R. Rodriguez
> > <mcgrof@do-not-panic.com> wrote:
> >> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >>
> >> This series addresses simple changes to framebuffer drivers to use
> >> arch_phys_wc_add() and ioremap_wc() as well as fixing gbefb to add
> >> missing mtrr_del() calls. These changes are pretty straight forward.
> >>
> >> Luis R. Rodriguez (17):
> >> video: fbdev: radeonfb: use arch_phys_wc_add() and ioremap_wc()
> >> video: fbdev: gbefb: add missing mtrr_del() calls
> >> video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()
> >> video: fbdev: intelfb: use arch_phys_wc_add() and ioremap_wc()
> >> video: fbdev: matrox: use arch_phys_wc_add() and ioremap_wc()
> >> video: fbdev: neofb: use arch_phys_wc_add() and ioremap_wc()
> >> video: fbdev: nvidia: use arch_phys_wc_add() and ioremap_wc()
> >> video: fbdev: savagefb: use arch_phys_wc_add() and ioremap_wc()
> >> video: fbdev: sisfb: use arch_phys_wc_add() and ioremap_wc()
> >> video: fbdev: aty: use arch_phys_wc_add() and ioremap_wc()
> >> video: fbdev: i810: use arch_phys_wc_add() and ioremap_wc()
> >> video: fbdev: pm2fb: use arch_phys_wc_add() and ioremap_wc()
> >> video: fbdev: pm3fb: use arch_phys_wc_add() and ioremap_wc()
> >> video: fbdev: rivafb: use arch_phys_wc_add() and ioremap_wc()
> >> video: fbdev: tdfxfb: use arch_phys_wc_add() and ioremap_wc()
> >> video: fbdev: atmel_lcdfb: use ioremap_wc() for framebuffer
> >> video: fbdev: geode gxfb: use ioremap_wc() for framebuffer
> >
> > Hey folks, these are all pretty straight forward, can anyone take them?
>
> I can take these to fbdev tree.
That'd be great!
> Unfortunately I'm not familiar with x86
> nor mtrr, so I can't really say much about the patches themselves.
Boris or Andy, I think you guy are more active from the x86 side,
a secondary Reviewed-by on this series other my own SOB would be
appreciated.
Luis
^ permalink raw reply
* [PATCH v4] staging: sm750fb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez @ 2015-05-05 0:15 UTC (permalink / raw)
To: gregkh, sudipm.mukherjee, teddy.wang, devel
Cc: luto, cocci, linux-fbdev, linux-kernel, Luis R. Rodriguez,
Suresh Siddha, Ingo Molnar, Thomas Gleixner, Juergen Gross,
Daniel Vetter, Dave Airlie, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen
From: "Luis R. Rodriguez" <mcgrof@suse.com>
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()")
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Teddy Wang <teddy.wang@siliconmotion.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: devel@driverdev.osuosl.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
drivers/staging/sm750fb/sm750.c | 36 ++++--------------------------------
drivers/staging/sm750fb/sm750.h | 3 ---
drivers/staging/sm750fb/sm750_hw.c | 3 +--
3 files changed, 5 insertions(+), 37 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 3c7ea95..cf57e3e 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -16,9 +16,6 @@
#include<linux/vmalloc.h>
#include<linux/pagemap.h>
#include <linux/console.h>
-#ifdef CONFIG_MTRR
-#include <asm/mtrr.h>
-#endif
#include <asm/fb.h>
#include "sm750.h"
#include "sm750_hw.h"
@@ -47,9 +44,7 @@ typedef int (*PROC_SPEC_INITHW)(struct lynx_share*, struct pci_dev*);
/* common var for all device */
static int g_hwcursor = 1;
static int g_noaccel;
-#ifdef CONFIG_MTRR
static int g_nomtrr;
-#endif
static const char *g_fbmode[] = {NULL, NULL};
static const char *g_def_fbmode = "800x600-16@60";
static char *g_settings = NULL;
@@ -1126,11 +1121,8 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
pr_info("share->revid = %02x\n", share->revid);
share->pdev = pdev;
-#ifdef CONFIG_MTRR
share->mtrr_off = g_nomtrr;
share->mtrr.vram = 0;
- share->mtrr.vram_added = 0;
-#endif
share->accel_off = g_noaccel;
share->dual = g_dualview;
spin_lock_init(&share->slock);
@@ -1158,22 +1150,9 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
goto err_map;
}
-#ifdef CONFIG_MTRR
- if (!share->mtrr_off) {
- pr_info("enable mtrr\n");
- share->mtrr.vram = mtrr_add(share->vidmem_start,
- share->vidmem_size,
- MTRR_TYPE_WRCOMB, 1);
-
- if (share->mtrr.vram < 0) {
- /* don't block driver with the failure of MTRR */
- pr_err("Unable to setup MTRR.\n");
- } else {
- share->mtrr.vram_added = 1;
- pr_info("MTRR added succesfully\n");
- }
- }
-#endif
+ if (!share->mtrr_off)
+ share->mtrr.vram = arch_phys_wc_add(share->vidmem_start,
+ share->vidmem_size);
memset_io(share->pvMem, 0, share->vidmem_size);
@@ -1274,12 +1253,7 @@ static void __exit lynxfb_pci_remove(struct pci_dev *pdev)
/* release frame buffer */
framebuffer_release(info);
}
-#ifdef CONFIG_MTRR
- if (share->mtrr.vram_added)
- mtrr_del(share->mtrr.vram,
- share->vidmem_start,
- share->vidmem_size);
-#endif
+ arch_phys_wc_del(share->mtrr.vram);
iounmap(share->pvReg);
iounmap(share->pvMem);
@@ -1321,10 +1295,8 @@ static int __init lynxfb_setup(char *options)
/* options that mean for any lynx chips are configured here */
if (!strncmp(opt, "noaccel", strlen("noaccel")))
g_noaccel = 1;
-#ifdef CONFIG_MTRR
else if (!strncmp(opt, "nomtrr", strlen("nomtrr")))
g_nomtrr = 1;
-#endif
else if (!strncmp(opt, "dual", strlen("dual")))
g_dualview = 1;
else {
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 0847d2b..5528912 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -51,13 +51,10 @@ struct lynx_share{
struct lynx_accel accel;
int accel_off;
int dual;
-#ifdef CONFIG_MTRR
int mtrr_off;
struct{
int vram;
- int vram_added;
}mtrr;
-#endif
/* all smi graphic adaptor got below attributes */
unsigned long vidmem_start;
unsigned long vidreg_start;
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 9f0d06d..4b77eb1 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -85,8 +85,7 @@ int hw_sm750_map(struct lynx_share* share, struct pci_dev* pdev)
}
#endif
- share->pvMem = ioremap(share->vidmem_start,
- share->vidmem_size);
+ share->pvMem = ioremap_wc(share->vidmem_start, share->vidmem_size);
if(!share->pvMem){
pr_err("Map video memory failed\n");
--
2.3.2.209.gd67f9d5.dirty
^ permalink raw reply related
* Re: [PATCH v3] staging: sm750fb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez @ 2015-05-05 0:14 UTC (permalink / raw)
To: Greg KH
Cc: Luis R. Rodriguez, sudipm.mukherjee, teddy.wang, devel, luto,
cocci, Suresh Siddha, Ingo Molnar, Thomas Gleixner, Juergen Gross,
Daniel Vetter, Dave Airlie, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
linux-kernel
In-Reply-To: <20150503192459.GA19486@kroah.com>
On Sun, May 03, 2015 at 09:24:59PM +0200, Greg KH wrote:
> On Tue, Apr 21, 2015 at 01:12:03PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
> > The same area used for ioremap() is used for the MTRR area.
> > Convert the driver from using the x86 specific MTRR code to
> > the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
> > will avoid MTRR if write-combining is available, in order to
> > take advantage of that also ensure the ioremap'd area is requested
> > as write-combining.
> >
> > There are a few motivations for this:
> >
> > a) Take advantage of PAT when available
> >
> > b) Help bury MTRR code away, MTRR is architecture specific and on
> > x86 its replaced by PAT
> >
> > c) Help with the goal of eventually using _PAGE_CACHE_UC over
> > _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
> > de33c442e titled "x86 PAT: fix performance drop for glx,
> > use UC minus for ioremap(), ioremap_nocache() and
> > pci_mmap_page_range()")
> >
> > The conversion done is expressed by the following Coccinelle
> > SmPL patch, it additionally required manual intervention to
> > address all the #ifdery and removal of redundant things which
> > arch_phys_wc_add() already addresses such as verbose message
> > about when MTRR fails and doing nothing when we didn't get
> > an MTRR.
> >
> > @ mtrr_found @
> > expression index, base, size;
> > @@
> >
> > -index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
> > +index = arch_phys_wc_add(base, size);
> >
> > @ mtrr_rm depends on mtrr_found @
> > expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
> > @@
> >
> > -mtrr_del(index, base, size);
> > +arch_phys_wc_del(index);
> >
> > @ mtrr_rm_zero_arg depends on mtrr_found @
> > expression mtrr_found.index;
> > @@
> >
> > -mtrr_del(index, 0, 0);
> > +arch_phys_wc_del(index);
> >
> > @ mtrr_rm_fb_info depends on mtrr_found @
> > struct fb_info *info;
> > expression mtrr_found.index;
> > @@
> >
> > -mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
> > +arch_phys_wc_del(index);
> >
> > @ ioremap_replace_nocache depends on mtrr_found @
> > struct fb_info *info;
> > expression base, size;
> > @@
> >
> > -info->screen_base = ioremap_nocache(base, size);
> > +info->screen_base = ioremap_wc(base, size);
> >
> > @ ioremap_replace_default depends on mtrr_found @
> > struct fb_info *info;
> > expression base, size;
> > @@
> >
> > -info->screen_base = ioremap(base, size);
> > +info->screen_base = ioremap_wc(base, size);
> >
> > Generated-by: Coccinelle SmPL
> > Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
> > Cc: Teddy Wang <teddy.wang@siliconmotion.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Suresh Siddha <sbsiddha@gmail.com>
> > Cc: Ingo Molnar <mingo@elte.hu>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Juergen Gross <jgross@suse.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Andy Lutomirski <luto@amacapital.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Antonino Daplas <adaplas@gmail.com>
> > Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: devel@driverdev.osuosl.org
> > Cc: linux-fbdev@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> > ---
> > drivers/staging/sm750fb/sm750.c | 36 ++++--------------------------------
> > drivers/staging/sm750fb/sm750.h | 3 ---
> > drivers/staging/sm750fb/sm750_hw.c | 3 +--
> > 3 files changed, 5 insertions(+), 37 deletions(-)
>
> This doesn't apply to my staging-next branch :(
OK I'll resend a v4 now.
Luis
^ permalink raw reply
* Re: [PATCH v4 2/6] x86: document WC MTRR effects on PAT / non-PAT pages
From: Borislav Petkov @ 2015-05-04 12:23 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: mingo, tglx, hpa, bp, plagnioj, tomi.valkeinen, daniel.vetter,
airlied, dledford, awalls, syrjala, luto, mst, cocci,
linux-kernel, Luis R. Rodriguez, Toshi Kani, Jonathan Corbet,
Dave Hansen, Suresh Siddha, Juergen Gross, Daniel Vetter,
Dave Airlie, Antonino Daplas, Mel Gorman, Vlastimil Babka,
Davidlohr Bueso, linux-fbdev
In-Reply-To: <1430343851-967-3-git-send-email-mcgrof@do-not-panic.com>
On Wed, Apr 29, 2015 at 02:44:07PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> As part of the effort to phase out MTRR use document
> write-combining MTRR effects on pages with different
> non-PAT page attributes flags and different PAT entry
> values. Extend arch_phys_wc_add() documentation to
> clarify power of two sizes / boundary requirements as
> we phase out mtrr_add() use.
>
> Lastly hint towards ioremap_uc() for corner cases on
> device drivers working with devices with mixed regions
> where MTRR size requirements would otherwise not
> enable write-combining effective memory types.
>
> Cc: Toshi Kani <toshi.kani@hp.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Suresh Siddha <sbsiddha@gmail.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Antonino Daplas <adaplas@gmail.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Ville Syrjälä <syrjala@sci.fi>
> Cc: Mel Gorman <mgorman@suse.de>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Davidlohr Bueso <dbueso@suse.de>
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
> Documentation/x86/mtrr.txt | 18 +++++++++++++++---
> Documentation/x86/pat.txt | 40 +++++++++++++++++++++++++++++++++++++++-
> arch/x86/kernel/cpu/mtrr/main.c | 3 +++
> 3 files changed, 57 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/x86/mtrr.txt b/Documentation/x86/mtrr.txt
> index cc071dc..a111a6c 100644
> --- a/Documentation/x86/mtrr.txt
> +++ b/Documentation/x86/mtrr.txt
> @@ -1,7 +1,19 @@
> MTRR (Memory Type Range Register) control
> -3 Jun 1999
> -Richard Gooch
> -<rgooch@atnf.csiro.au>
> +
> +Richard Gooch <rgooch@atnf.csiro.au> - 3 Jun 1999
> +Luis R. Rodriguez <mcgrof@do-not-panic.com> - April 9, 2015
> +
> +=======================================> +Phasing MTRR use
"Phasing out...".
> +
> +MTRR use is replaced on modern x86 hardware with PAT. Over time the only type
> +of effective MTRR that is expected to be supported will be for write-combining.
> +As MTRR use is phased out device drivers should use arch_phys_wc_add() to make
> +MTRR effective on non-PAT systems while a no-op on PAT enabled systems.
> +
> +For details refer to Documentation/x86/pat.txt.
> +
> +=======================================>
> On Intel P6 family processors (Pentium Pro, Pentium II and later)
> the Memory Type Range Registers (MTRRs) may be used to control
> diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
> index cf08c9f..7e183e3 100644
> --- a/Documentation/x86/pat.txt
> +++ b/Documentation/x86/pat.txt
> @@ -34,6 +34,8 @@ ioremap | -- | UC- | UC- |
> | | | |
> ioremap_cache | -- | WB | WB |
> | | | |
> +ioremap_uc | -- | UC | UC |
> + | | | |
> ioremap_nocache | -- | UC- | UC- |
> | | | |
> ioremap_wc | -- | -- | WC |
> @@ -102,7 +104,43 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
> as step 0 above and also track the usage of those pages and use set_memory_wb()
> before the page is freed to free pool.
>
> -
> +MTRR effects on PAT / non-PAT systems
> +-------------------------------------
> +
> +The following table provides the effects of using write-combining MTRRs when
> +using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> +mtrr_add() usage will be phased in favor of arch_phys_wc_add() which will
out
> +be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> +is made should already have be ioremap'd with write-combining page attributes
, have been ioremapped with WC attributes...
> +or PAT entries, this can be done by using ioremap_wc() / or respective helpers.
> +Devices which combine areas of IO memory desired to remain uncachable with
> +areas where write-combining is desirable and are restricted by the size
> +requirements of MTRRs should consider splitting up their IO memory space
> +cleanly with ioremap_uc() and ioremap_wc() followed by an arch_phys_wc_add()
> +encompassing both regions. Such use is nevertheless heavily discouraged as
> +the effective memory type is considered implementation defined. This strategy
> +should only be used as last resort on devices with size-contrained regions
> +where otherwise MTRR write-combining would not be effective.
> +
> +Note that you cannot use set_memory_wc() to override / whitelist IO remapped
> +memory space mapped with ioremap*() calls, set_memory_wc() can only be used
> +on RAM.
> +
> +----------------------------------------------------------------------
> +MTRR Non-PAT PAT Linux ioremap value Effective memory type
> +----------------------------------------------------------------------
> + Non-PAT | PAT
> + PAT
> + |PCD
> + ||PWT
> + |||
> +WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
> +WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
> +WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | WC
> +WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
> +----------------------------------------------------------------------
> +
> +(*) denotes implementation defined and is discouraged
>
> Notes:
>
> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> index ea5f363..12abdbe 100644
> --- a/arch/x86/kernel/cpu/mtrr/main.c
> +++ b/arch/x86/kernel/cpu/mtrr/main.c
> @@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
> * attempts to add a WC MTRR covering size bytes starting at base and
> * logs an error if this fails.
> *
> + * The caller should expect to need to provide a power of two size on an
> + * equivalent power of two boundary.
> + *
> * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
> * but drivers should not try to interpret that return value.
> */
> --
> 2.3.2.209.gd67f9d5.dirty
>
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
^ permalink raw reply
* Re: [PATCHv2,RESEND] framebuffer: don't link fb_devio into kernel image unconditionally
From: Tomi Valkeinen @ 2015-05-04 10:52 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 509 bytes --]
On 28/04/15 14:17, Harald Geyer wrote:
> CONFIG_FB_DEFERRED_IO is defined as bool while CONFIG_FB is defined as
> tristate. Currently fb_defio.o is linked into the kernel image even if
> CONFIG_FB=m.
>
> I fix this by updating the Makefile to link fb_defio.o into fb.o and thus
> go into one place with the other core framebuffer code.
>
> Signed-off-by: Harald Geyer <harald@ccbib.org>
> ---
> Resending as I didn't get any reply in six weeks.
>
Thanks, queuing for 4.2 fbdev.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3 00/17] framebuffer: simple conversions to arch_phys_wc_add()
From: Tomi Valkeinen @ 2015-05-04 10:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1429647398-16983-1-git-send-email-mcgrof@do-not-panic.com>
[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]
On 29/04/15 22:18, Luis R. Rodriguez wrote:
> On Tue, Apr 21, 2015 at 1:16 PM, Luis R. Rodriguez
> <mcgrof@do-not-panic.com> wrote:
>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>
>> This series addresses simple changes to framebuffer drivers to use
>> arch_phys_wc_add() and ioremap_wc() as well as fixing gbefb to add
>> missing mtrr_del() calls. These changes are pretty straight forward.
>>
>> Luis R. Rodriguez (17):
>> video: fbdev: radeonfb: use arch_phys_wc_add() and ioremap_wc()
>> video: fbdev: gbefb: add missing mtrr_del() calls
>> video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()
>> video: fbdev: intelfb: use arch_phys_wc_add() and ioremap_wc()
>> video: fbdev: matrox: use arch_phys_wc_add() and ioremap_wc()
>> video: fbdev: neofb: use arch_phys_wc_add() and ioremap_wc()
>> video: fbdev: nvidia: use arch_phys_wc_add() and ioremap_wc()
>> video: fbdev: savagefb: use arch_phys_wc_add() and ioremap_wc()
>> video: fbdev: sisfb: use arch_phys_wc_add() and ioremap_wc()
>> video: fbdev: aty: use arch_phys_wc_add() and ioremap_wc()
>> video: fbdev: i810: use arch_phys_wc_add() and ioremap_wc()
>> video: fbdev: pm2fb: use arch_phys_wc_add() and ioremap_wc()
>> video: fbdev: pm3fb: use arch_phys_wc_add() and ioremap_wc()
>> video: fbdev: rivafb: use arch_phys_wc_add() and ioremap_wc()
>> video: fbdev: tdfxfb: use arch_phys_wc_add() and ioremap_wc()
>> video: fbdev: atmel_lcdfb: use ioremap_wc() for framebuffer
>> video: fbdev: geode gxfb: use ioremap_wc() for framebuffer
>
> Hey folks, these are all pretty straight forward, can anyone take them?
I can take these to fbdev tree. Unfortunately I'm not familiar with x86
nor mtrr, so I can't really say much about the patches themselves.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: Cleaning up a few return statements
From: Sudip Mukherjee @ 2015-05-04 5:55 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150417204416.GA18202@rosebud>
On Sun, May 03, 2015 at 09:25:47PM +0200, Greg KH wrote:
> On Fri, Apr 17, 2015 at 04:44:16PM -0400, Julian Gindi wrote:
> > Signed-off-by: Julian Gindi <juliangindi@gmail.com>
> >
> >
> > --
> > 1.9.1
>
> This breaks the build, showing that you never even tested it :(
sorry Greg, I should have buildtested after Julian has submitted the
patch.
regards
sudip
^ permalink raw reply
* Re: [PATCH v2 2/2] staging: sm750fb: cleanup indentation
From: Greg KH @ 2015-05-03 19:35 UTC (permalink / raw)
To: Charles Rose
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, devel, linux-kernel
In-Reply-To: <1429888256-18890-1-git-send-email-charles.rose.linux@gmail.com>
On Fri, Apr 24, 2015 at 11:10:56AM -0400, Charles Rose wrote:
> This patch fixes indentation errors/warnings reported by checkpatch.pl.
>
> Signed-off-by: Charles Rose <charles.rose.linux@gmail.com>
> ---
> drivers/staging/sm750fb/ddk750_mode.c | 24 ++++++++++++++++--------
> 1 file changed, 16 insertions(+), 8 deletions(-)
Does not apply to my tree :(
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: Cleaning up a few return statements
From: Greg KH @ 2015-05-03 19:25 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150417204416.GA18202@rosebud>
On Fri, Apr 17, 2015 at 04:44:16PM -0400, Julian Gindi wrote:
> Signed-off-by: Julian Gindi <juliangindi@gmail.com>
> ---
> drivers/staging/sm750fb/ddk750_chip.c | 4 +---
> drivers/staging/sm750fb/sm750.c | 6 +-----
> drivers/staging/sm750fb/sm750_hw.c | 5 +----
> 3 files changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_chip.c b/drivers/staging/sm750fb/ddk750_chip.c
> index 7b28328..ac88623 100644
> --- a/drivers/staging/sm750fb/ddk750_chip.c
> +++ b/drivers/staging/sm750fb/ddk750_chip.c
> @@ -499,7 +499,6 @@ pll_value_t *pPLL /* Structure to hold the value to be set in PLL */
> {
> unsigned int M, N, OD, POD = 0, diff, pllClk, odPower, podPower;
> unsigned int bestDiff = 0xffffffff; /* biggest 32 bit unsigned number */
> - unsigned int ret;
> /* Init PLL structure to know states */
> pPLL->M = 0;
> pPLL->N = 0;
> @@ -589,8 +588,7 @@ pll_value_t *pPLL /* Structure to hold the value to be set in PLL */
> //DDKDEBUGPRINT((DISPLAY_LEVEL, "calcPllValue: Input CLK = %dHz, M=%d, N=%d, OD=%d, POD=%d\n", pPLL->inputFreq, pPLL->M, pPLL->N, pPLL->OD, pPLL->POD));
>
> /* Return actual frequency that the PLL can set */
> - ret = calcPLL(pPLL);
> - return ret;
> + return calcPLL(pPLL);
> }
>
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 3c7ea95..e05bb64 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -303,8 +303,6 @@ static int lynxfb_ops_pan_display(struct fb_var_screeninfo *var,
> {
> struct lynxfb_par *par;
> struct lynxfb_crtc *crtc;
> - int ret;
> -
>
> if (!info)
> return -EINVAL;
> @@ -312,9 +310,7 @@ static int lynxfb_ops_pan_display(struct fb_var_screeninfo *var,
> ret = 0;
> par = info->par;
> crtc = &par->crtc;
> - ret = crtc->proc_panDisplay(crtc, var, info);
> -
> - return ret;
> + return crtc->proc_panDisplay(crtc, var, info);
> }
>
> static int lynxfb_ops_set_par(struct fb_info *info)
> diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
> index 9f0d06d..8f2432d 100644
> --- a/drivers/staging/sm750fb/sm750_hw.c
> +++ b/drivers/staging/sm750fb/sm750_hw.c
> @@ -203,10 +203,7 @@ int hw_sm750_inithw(struct lynx_share* share, struct pci_dev * pdev)
>
> resource_size_t hw_sm750_getVMSize(struct lynx_share * share)
> {
> - resource_size_t ret;
> -
> - ret = ddk750_getVMSize();
> - return ret;
> + return ddk750_getVMSize();
> }
>
>
> --
> 1.9.1
This breaks the build, showing that you never even tested it :(
^ permalink raw reply
* Re: [PATCH v3] staging: sm750fb: use arch_phys_wc_add() and ioremap_wc()
From: Greg KH @ 2015-05-03 19:24 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: sudipm.mukherjee, teddy.wang, devel, luto, cocci,
Luis R. Rodriguez, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Dave Airlie, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
linux-kernel
In-Reply-To: <1429647123-16777-1-git-send-email-mcgrof@do-not-panic.com>
On Tue, Apr 21, 2015 at 01:12:03PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> The same area used for ioremap() is used for the MTRR area.
> Convert the driver from using the x86 specific MTRR code to
> the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
> will avoid MTRR if write-combining is available, in order to
> take advantage of that also ensure the ioremap'd area is requested
> as write-combining.
>
> There are a few motivations for this:
>
> a) Take advantage of PAT when available
>
> b) Help bury MTRR code away, MTRR is architecture specific and on
> x86 its replaced by PAT
>
> c) Help with the goal of eventually using _PAGE_CACHE_UC over
> _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
> de33c442e titled "x86 PAT: fix performance drop for glx,
> use UC minus for ioremap(), ioremap_nocache() and
> pci_mmap_page_range()")
>
> The conversion done is expressed by the following Coccinelle
> SmPL patch, it additionally required manual intervention to
> address all the #ifdery and removal of redundant things which
> arch_phys_wc_add() already addresses such as verbose message
> about when MTRR fails and doing nothing when we didn't get
> an MTRR.
>
> @ mtrr_found @
> expression index, base, size;
> @@
>
> -index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
> +index = arch_phys_wc_add(base, size);
>
> @ mtrr_rm depends on mtrr_found @
> expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
> @@
>
> -mtrr_del(index, base, size);
> +arch_phys_wc_del(index);
>
> @ mtrr_rm_zero_arg depends on mtrr_found @
> expression mtrr_found.index;
> @@
>
> -mtrr_del(index, 0, 0);
> +arch_phys_wc_del(index);
>
> @ mtrr_rm_fb_info depends on mtrr_found @
> struct fb_info *info;
> expression mtrr_found.index;
> @@
>
> -mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
> +arch_phys_wc_del(index);
>
> @ ioremap_replace_nocache depends on mtrr_found @
> struct fb_info *info;
> expression base, size;
> @@
>
> -info->screen_base = ioremap_nocache(base, size);
> +info->screen_base = ioremap_wc(base, size);
>
> @ ioremap_replace_default depends on mtrr_found @
> struct fb_info *info;
> expression base, size;
> @@
>
> -info->screen_base = ioremap(base, size);
> +info->screen_base = ioremap_wc(base, size);
>
> Generated-by: Coccinelle SmPL
> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
> Cc: Teddy Wang <teddy.wang@siliconmotion.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Suresh Siddha <sbsiddha@gmail.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Antonino Daplas <adaplas@gmail.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: devel@driverdev.osuosl.org
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
> drivers/staging/sm750fb/sm750.c | 36 ++++--------------------------------
> drivers/staging/sm750fb/sm750.h | 3 ---
> drivers/staging/sm750fb/sm750_hw.c | 3 +--
> 3 files changed, 5 insertions(+), 37 deletions(-)
This doesn't apply to my staging-next branch :(
^ permalink raw reply
* [PATCH 4/4] video: fbdev: s3c-fb: Constify platform_device_id
From: Krzysztof Kozlowski @ 2015-05-01 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1430494721-30793-1-git-send-email-k.kozlowski.k@gmail.com>
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
---
drivers/video/fbdev/s3c-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
index 7e3a05fc47aa..f72dd12456f9 100644
--- a/drivers/video/fbdev/s3c-fb.c
+++ b/drivers/video/fbdev/s3c-fb.c
@@ -1938,7 +1938,7 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
},
};
-static struct platform_device_id s3c_fb_driver_ids[] = {
+static const struct platform_device_id s3c_fb_driver_ids[] = {
{
.name = "s3c-fb",
.driver_data = (unsigned long)&s3c_fb_data_64xx,
--
2.1.4
^ permalink raw reply related
* [PATCH 3/4] video: fbdev: mxsfb: Constify platform_device_id
From: Krzysztof Kozlowski @ 2015-05-01 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1430494721-30793-1-git-send-email-k.kozlowski.k@gmail.com>
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
---
drivers/video/fbdev/mxsfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
index f8ac4a452f26..497971c82bb1 100644
--- a/drivers/video/fbdev/mxsfb.c
+++ b/drivers/video/fbdev/mxsfb.c
@@ -814,7 +814,7 @@ static void mxsfb_free_videomem(struct mxsfb_info *host)
free_pages_exact(fb_info->screen_base, fb_info->fix.smem_len);
}
-static struct platform_device_id mxsfb_devtype[] = {
+static const struct platform_device_id mxsfb_devtype[] = {
{
.name = "imx23-fb",
.driver_data = MXSFB_V3,
--
2.1.4
^ permalink raw reply related
* [PATCH 2/4] video: fbdev: imxfb: Constify platform_device_id
From: Krzysztof Kozlowski @ 2015-05-01 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1430494721-30793-1-git-send-email-k.kozlowski.k@gmail.com>
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
---
drivers/video/fbdev/imxfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index 84d1d29e532c..cee88603efc9 100644
--- a/drivers/video/fbdev/imxfb.c
+++ b/drivers/video/fbdev/imxfb.c
@@ -170,7 +170,7 @@ struct imxfb_info {
struct regulator *lcd_pwr;
};
-static struct platform_device_id imxfb_devtype[] = {
+static const struct platform_device_id imxfb_devtype[] = {
{
.name = "imx1-fb",
.driver_data = IMX1_FB,
--
2.1.4
^ permalink raw reply related
* [PATCH 1/4] video: backlight: da9052: Constify platform_device_id
From: Krzysztof Kozlowski @ 2015-05-01 15:38 UTC (permalink / raw)
To: linux-arm-kernel
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
---
drivers/video/backlight/da9052_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/da9052_bl.c b/drivers/video/backlight/da9052_bl.c
index b1943e7735a1..fd2be417aa64 100644
--- a/drivers/video/backlight/da9052_bl.c
+++ b/drivers/video/backlight/da9052_bl.c
@@ -152,7 +152,7 @@ static int da9052_backlight_remove(struct platform_device *pdev)
return 0;
}
-static struct platform_device_id da9052_wled_ids[] = {
+static const struct platform_device_id da9052_wled_ids[] = {
{
.name = "da9052-wled1",
.driver_data = DA9052_TYPE_WLED1,
--
2.1.4
^ permalink raw reply related
* Re: [RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other
From: Krzysztof Kozlowski @ 2015-05-01 9:14 UTC (permalink / raw)
To: Olof Johansson
Cc: Krzysztof Kozlowski, linux-samsung-soc@vger.kernel.org,
Kevin Hilman, Jingoo Han, Seung-Woo Kim,
linux-fbdev@vger.kernel.org, DRI mailing list,
linux-kernel@vger.kernel.org, Andrzej Hajda, Kyungmin Park,
Kukjin Kim, stable, Javier Martinez Canillas,
linux-arm-kernel@lists.infradead.org, Marek Szyprowski
In-Reply-To: <CAOesGMiA7DCGCg2xgLwu_r_rRYKUjpw2HUePCW5Q9ewU61WbdA@mail.gmail.com>
2015-05-01 1:50 GMT+09:00 Olof Johansson <olof@lixom.net>:
> On Thu, Apr 30, 2015 at 9:40 AM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>> Hello Olof,
>>
>> On 04/30/2015 05:57 PM, Olof Johansson wrote:
>>> On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman <khilman@kernel.org> wrote:
>>>> Krzysztof Kozlowski <k.kozlowski@samsung.com> writes:
>>>>>>>
>>>>>>> This should fix issue reported by Javier [1][2].
>>>>>>>
>>>>>>> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
>>>>>>> especially on other Exynos 5xxx products.
>>>>>>
>>>>>> I hoped to try this on my exynos5 boards, but it doesn't seem to apply
>>>>>> to linux-next or to Linus' master branch.
>>>>>>
>>>>>> Are there some other dependencies here?
>>>>>
>>>>> It is already applied:
>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id\x1c363c7cccf64128087002b0779986ad16aff6dc
>>>>
>>>> Er, yup. That would explain it. ;)
>>>>
>>>> Sorry for the noise,
>>>
>>> Well, noise or not, Exynos is still broken in mainline and was broken
>>> on -next for so long in different ways that bisecting it is a futile
>>> exercise in frustration.
>>>
>>> It doesn't seem to show up with a trivial boot using only ramdisk, but
>>> when booting a real distro from disk, it certainly does.
>>>
>>> For example:
>>>
>>> http://arm-soc.lixom.net/bootlogs/mainline/v4.1-rc1-56-g3d99e3f/pi-arm-exynos_defconfig.html
>>>
>>> Disabling CONFIG_DRM makes it boot reliably.
>>>
>>> Arndale doesn't show it for me, but it also doesn't have working graphics.
>>>
>>
>> Both Exynos5250 and Exynos5420 had similar issues and $subject is the fix
>> for 5250 while 5420 is fixed by my "ARM: dts: Make DP a consumer of DISP1
>> power domain on Exynos5420" patch that was posted a long time ago. I have
>> pinged Kukjin several times about this patch and he said that he will pick
>> it this weekend [0].
>>
>> It is indeed very frustrating how many Exynos patches seems to be falling
>> through the crack, even important fixes like these ones that allow boards
>> to boot again.
>>
>> Kevin suggested that Krzysztof could collect and queue patches [1] to help
>> Kukjin and start acting as a co-maintatiner which I think it's a very good
>> idea and Krzysztof already did for some patches during the 4.1 cycle.
Yes, I did. It turned quite well, most of the patches I collected were
pulled :) .
> Yes, that's a much needed improvement. I suggest starting out by
> collecting critical fixes like these, and we'd be happy to merge them
> directly if going through Kukjin will add latency.
>
> Krzysztof, if you can, make sure you get a PGP key setup and start
> collecting signatures from kernel developers.
Sure, I'll start right away!
^ permalink raw reply
* Re: [PATCH v4 2/5] lib: devres: add pcim_iomap_wc() variants
From: Luis R. Rodriguez @ 2015-05-01 0:20 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Luis R. Rodriguez, mst, plagnioj, tomi.valkeinen, airlied,
daniel.vetter, linux-fbdev, luto, cocci, linux-kernel, Toshi Kani,
Suresh Siddha, Ingo Molnar, Thomas Gleixner, Juergen Gross,
Daniel Vetter, Dave Airlie, Antonino Daplas, Dave Hansen,
Arnd Bergmann, venkatesh.pallipadi, Stefan Bader,
Ville Syrjälä, Mel Gorman, Vlastimil Babka,
Borislav Petkov, Davidlohr Bueso, konrad.wilk, ville.syrjala,
david.vrabel, jbeulich, Roger Pau Monné, xen-devel,
linux-pci
In-Reply-To: <20150430214638.GE7888@google.com>
On Thu, Apr 30, 2015 at 04:46:38PM -0500, Bjorn Helgaas wrote:
> On Thu, Apr 30, 2015 at 07:27:23PM +0200, Luis R. Rodriguez wrote:
> > On Thu, Apr 30, 2015 at 11:26:47AM -0500, Bjorn Helgaas wrote:
>
> > > I don't see users of either pcim_iomap_wc() or pcim_iomap_wc_regions() so
> > > far. Did I miss them, or do you just expect them in the near future?
> >
> > The later, and also I hate seeing folks later add code under EXPORT_SYMBOL()
> > rather than EXPORT_SYMBOL_GPL() so I figure I'd rather do it first. It happened
> > recently in my v1 series, someone beat me to a write-combining export symbol
> > and changed it to EXPORT_SYMBOL(). Feel free to drop this though but I hope
> > no one out there then tries to just add an EXPORT_SYMBOL() later for this...
>
> Why do you want them to be EXPORT_SYMBOL_GPL? I would expect them to be
> exported the same way pcim_iomap(), pcim_iomap_regions(), and ioremap_wc()
> are exported, i.e., with EXPORT_SYMBOL.
>>
> Per Documentation/DocBook/kernel-hacking.tmpl, EXPORT_SYMBOL_GPL "implies
> that the function is considered an internal implementation issue, and not
> really an interface." I don't think these are internal implementation
> issues.
What Documentation/DocBook/kernel-hacking.tmpl states over EXPORT_SYMBOL_GPL()
is old and in no way reflects current trends and reality. For instance, some
folks believe that if some code has EXPORT_SYMBOL() declared that they can use
it on proprietary modules. This is terribly incorrect, quite a few developers
do not in any way stand by this as a "needed" clarification on their code [0].
I'm one of them, but to be even more clear on this I simply *always* use
EXPORT_SYMBOL_GPL() to remove any possible doubt over this on any symbols
that I export. Heck, even tons of driver library code uses EXPORT_SYMBOL_GPL().
[0] https://lkml.org/lkml/2012/4/20/402
Luis
^ permalink raw reply
* Re: [PATCH v4 2/6] x86: document WC MTRR effects on PAT / non-PAT pages
From: Randy Dunlap @ 2015-04-30 22:01 UTC (permalink / raw)
To: Luis R. Rodriguez, mingo, tglx, hpa, bp, plagnioj, tomi.valkeinen,
daniel.vetter, airlied
Cc: dledford, awalls, syrjala, luto, mst, cocci, linux-kernel,
Luis R. Rodriguez, Toshi Kani, Jonathan Corbet, Dave Hansen,
Suresh Siddha, Juergen Gross, Daniel Vetter, Dave Airlie,
Antonino Daplas, Mel Gorman, Vlastimil Babka, Davidlohr Bueso,
linux-fbdev
In-Reply-To: <1430343851-967-3-git-send-email-mcgrof@do-not-panic.com>
On 04/29/15 14:44, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> ---
> Documentation/x86/mtrr.txt | 18 +++++++++++++++---
> Documentation/x86/pat.txt | 40 +++++++++++++++++++++++++++++++++++++++-
> arch/x86/kernel/cpu/mtrr/main.c | 3 +++
> 3 files changed, 57 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
> index cf08c9f..7e183e3 100644
> --- a/Documentation/x86/pat.txt
> +++ b/Documentation/x86/pat.txt
> @@ -102,7 +104,43 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
> as step 0 above and also track the usage of those pages and use set_memory_wb()
> before the page is freed to free pool.
>
> -
> +MTRR effects on PAT / non-PAT systems
> +-------------------------------------
> +
> +The following table provides the effects of using write-combining MTRRs when
> +using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> +mtrr_add() usage will be phased in favor of arch_phys_wc_add() which will
> +be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> +is made should already have be ioremap'd with write-combining page attributes
> +or PAT entries, this can be done by using ioremap_wc() / or respective helpers.
> +Devices which combine areas of IO memory desired to remain uncachable with
I would spell it uncacheable. In kernel Documentation/, grep uncacheable finds
14 hits vs. 6 hits for uncachable. No big deal.
> +areas where write-combining is desirable and are restricted by the size
> +requirements of MTRRs should consider splitting up their IO memory space
> +cleanly with ioremap_uc() and ioremap_wc() followed by an arch_phys_wc_add()
> +encompassing both regions. Such use is nevertheless heavily discouraged as
> +the effective memory type is considered implementation defined. This strategy
> +should only be used as last resort on devices with size-contrained regions
size-constrained
> +where otherwise MTRR write-combining would not be effective.
> +
> +Note that you cannot use set_memory_wc() to override / whitelist IO remapped
> +memory space mapped with ioremap*() calls, set_memory_wc() can only be used
> +on RAM.
> +
> +----------------------------------------------------------------------
> +MTRR Non-PAT PAT Linux ioremap value Effective memory type
> +----------------------------------------------------------------------
> + Non-PAT | PAT
> + PAT
> + |PCD
> + ||PWT
> + |||
> +WC 000 WB _PAGE_CACHE_MODE_WB WC | WC
> +WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC
> +WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | WC
> +WC 011 UC _PAGE_CACHE_MODE_UC UC | UC
> +----------------------------------------------------------------------
> +
> +(*) denotes implementation defined and is discouraged
>
> Notes:
>
> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> index ea5f363..12abdbe 100644
> --- a/arch/x86/kernel/cpu/mtrr/main.c
> +++ b/arch/x86/kernel/cpu/mtrr/main.c
> @@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
> * attempts to add a WC MTRR covering size bytes starting at base and
> * logs an error if this fails.
> *
> + * The caller should expect to need to provide a power of two size on an
* The called should provide a power of two size on an equivalent
* power of two boundary.
> + * equivalent power of two boundary.
> + *
> * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
> * but drivers should not try to interpret that return value.
> */
>
--
~Randy
^ permalink raw reply
* Re: [PATCH v4 2/5] lib: devres: add pcim_iomap_wc() variants
From: Bjorn Helgaas @ 2015-04-30 21:46 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis R. Rodriguez, mst, plagnioj, tomi.valkeinen, airlied,
daniel.vetter, linux-fbdev, luto, cocci, linux-kernel, Toshi Kani,
Suresh Siddha, Ingo Molnar, Thomas Gleixner, Juergen Gross,
Daniel Vetter, Dave Airlie, Antonino Daplas, Dave Hansen,
Arnd Bergmann, venkatesh.pallipadi, Stefan Bader,
Ville Syrjälä, Mel Gorman, Vlastimil Babka,
Borislav Petkov, Davidlohr Bueso, konrad.wilk, ville.syrjala,
david.vrabel, jbeulich, Roger Pau Monné, xen-devel,
linux-pci
In-Reply-To: <20150430172723.GU5622@wotan.suse.de>
On Thu, Apr 30, 2015 at 07:27:23PM +0200, Luis R. Rodriguez wrote:
> On Thu, Apr 30, 2015 at 11:26:47AM -0500, Bjorn Helgaas wrote:
> > I don't see users of either pcim_iomap_wc() or pcim_iomap_wc_regions() so
> > far. Did I miss them, or do you just expect them in the near future?
>
> The later, and also I hate seeing folks later add code under EXPORT_SYMBOL()
> rather than EXPORT_SYMBOL_GPL() so I figure I'd rather do it first. It happened
> recently in my v1 series, someone beat me to a write-combining export symbol
> and changed it to EXPORT_SYMBOL(). Feel free to drop this though but I hope
> no one out there then tries to just add an EXPORT_SYMBOL() later for this...
Why do you want them to be EXPORT_SYMBOL_GPL? I would expect them to be
exported the same way pcim_iomap(), pcim_iomap_regions(), and ioremap_wc()
are exported, i.e., with EXPORT_SYMBOL.
Per Documentation/DocBook/kernel-hacking.tmpl, EXPORT_SYMBOL_GPL "implies
that the function is considered an internal implementation issue, and not
really an interface." I don't think these are internal implementation
issues.
Bjorn
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox