* Re: [PATCH v3 00/17] framebuffer: simple conversions to arch_phys_wc_add()
From: Andy Lutomirski @ 2015-05-05 13:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1429647398-16983-1-git-send-email-mcgrof@do-not-panic.com>
On Mon, May 4, 2015 at 3:33 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> 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. Unfortunately I'm not familiar with x86
> nor mtrr, so I can't really say much about the patches themselves.
>
I'm on vacation and there's no way I'll be able to usefully review
these in the next two weeks. I can describe what's going on in case
it helps:
On x86 there are two ways to get a write-combining MMIO mapping. The
sane way is ioremap_wc, and the ridiculous way is mtrr_add.
ioremap_wc does exactly what it appears to do, whereas mtrr_add acts
on physical addresses, requires power-of-two alignment, and is
unreliable.
On all recent hardware, ioremap_wc works, and mtrr_add is problematic
on all hardware even if it often works. The silly thing is that
mtrr_add pokes at the registers it uses even on hardware with working
ioremap_wc. This causes problems (those resources are a very limited
resource).
The solution I came up with a couple years ago is a new API
arch_phys_wc_add. It is a hint that a physical address range should
be write-combining. On hardware with working ioremap_wc, it's a
no-op. On x86 hardware without working ioremap_wc, it just calls
mtrr_add.
The upshot is that changing mtrr_add with a WC type to
arch_phys_wc_add is OK as long as the driver also uses ioremap_wc or
similar _wc APIs. Once everything has been converted, we can unexport
mtrr_add, which will have all kinds of benefits.
--Andy
^ permalink raw reply
* Von Dr. Christopher Harrison (Bitte antworten)
From: Dr. Christopher Harrison @ 2015-05-05 10:18 UTC (permalink / raw)
To: linux-fbdev
Lieber Freund,
Wie geht es dir heute? Ich hoffe, in Ordnung, ich bin Dr. Christopher Harrison von NothWest London, England. Ich arbeite für Zweig Lloyds Bank London. Ich schreibe Ihnen aus meinem Büro, das aus einem großen immense Vorteil für uns beide sein wird. In meiner Abteilung, dass die Co-Trainer (Großregion London), entdeckte ich eine verlassene Summe von £ 16,5 Millionen Pfund (Sechzehn Millionen fünfhunderttausend Pfund und Pfund Sterling) in einem Konto, das Sie mit einem unserer ausländischen Kunden Späte Herr Ron Bramlage gehört , ein Amerikaner, der in Kansas Staaten lebt, die ein Opfer von einem Hubschrauberabsturz im vergangenen Jahr 8. Juni 2012, in Florida Sumpf ihn und Familienmitglieder zu töten war. Ron war 45 Jahre alt. Auch in der Chopper zum Zeitpunkt des Absturzes war seine Frau Rebecca, 43, und die Kinder des Paares - Brandon, 15; Boston, 13; Beau, 11; und 8-jährige Roxanne - wurden getötet. Der Pilot war auch tot.
Ich suche Ihre Partnerschaft und Zusammenarbeit zur Durchführung dieser Transaktion zusammen, weil der Lloyds Bank schließt einige ihrer Zweigstellen und den Zweig, wo dieser Fonds hinterlegt ist unter denen geschlossen werden, so dass ich möchte, dass wir diesen Fonds zu bekommen, bevor ihre Verschluss. Ich habe Sie kontaktiert, weil ich glaube, Sie werden nicht weglaufen mit eigenen Aktien dieses Fonds, wenn es Ihrem Konto eingeht, und die gemeinsame Nutzung Quote von 60% für mich und 40% für Ihre Zusammenarbeit. Für Sie die Lloyds Bank, um sicherzustellen, Schließen Niederlassungen besuchen Sie diese Seite:
https://uk.news.yahoo.com/lloyds-bank-more-200-branches-close-181000783--finance.html#4KVKdTh
Aufgrund der Sensibilität der Transaktion und die Vertraulichkeit hier, jetzt unsere Bank hat für keine der Verwandten warten zu kommen-up für die Behauptung, aber niemand hat in der Suche die Verwandten für eine lange Zeit jetzt getan, dass ich persönlich nicht erfolgreich waren . Mein lieber Freund, ich suche Ihre Zustimmung an Sie als nächsten Angehörigen / Will Begünstigter des Verstorbenen zu präsentieren, so dass die Erlöse aus diesem Konto bei £ 16,5 Millionen Pfund an Sie gezahlt werden bewertet.
Das wird für mich ausgezahlt oder geteilt in diese Prozentsätze, 60% und 40% zu Ihnen, ich habe alle notwendigen rechtlichen Dokumente, die wir verwendet werden, um diese Behauptung wir machen gesichert. Alles was ich brauche ist es, in Ihrem Namen zu den Dokumenten füllen und legalisiert es in den Hof und die Lloyds Bank hier, um Ihnen zu beweisen, als berechtigten Empfänger, ist Alles, was ich jetzt brauche Ihre ehrliche Zusammenarbeit, Verschwiegenheit und Vertrauen, damit wir sehen, diese Transaktion durch. Ich garantiere Ihnen, dass dies unter einer legitimen Anordnung, die Sie von einem Verstoß gegen das Gesetz hier in England und in Ihrem Land zu schützen wird ausgeführt.
Bitte, bitte senden Sie mir die folgenden: wir haben 7 Tage, um es zu durchlaufen, das ist sehr, sehr URGENT PLEASE.
1. Vollständiger Name: ......................
2. Ihre Telefonnummer: .................
3. Ihre Kontaktadresse: ..................
4. Alter / Geschlecht: ...................
5. Kern Job / Beruf: ..............
Bitte beantworten Sie meine E-Mail hier: harrisondr.christoph_office@yahoo.co.uk
Ich habe euch in Kontakt gebracht, zu glauben, dass Sie nicht weglaufen mit eigenen Aktien dieses Fonds, wenn es Ihrem Konto kommt, hoffe ich, können Sie auf diese vertrauen? Wie Sie wissen, diese Transaktion beinhalten sehr viel Geld. Bitte Standard freundlich zeigen Sie Ihr Interesse, indem sie mich mit Ihren Angaben wie oben, so kann ich Ihnen mehr Informationen darüber, wie die Bank gehen, um diesen Fonds zu Ihnen innerhalb von 5 Bankarbeitstagen übertragen bekommen zu erbringen. Endeavour zu antworten, dass sie nicht länger auf mich gewartet. Ok, mein lieber Freund?
Freundliche Grüße,
Dr. Christopher Harrison
^ permalink raw reply
* Re: [PATCH 4/4] video: fbdev: s3c-fb: Constify platform_device_id
From: Lee Jones @ 2015-05-05 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1430494721-30793-4-git-send-email-k.kozlowski.k@gmail.com>
On Sat, 02 May 2015, Krzysztof Kozlowski wrote:
> 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(-)
Applied, thanks.
> 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,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 3/4] video: fbdev: mxsfb: Constify platform_device_id
From: Lee Jones @ 2015-05-05 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1430494721-30793-3-git-send-email-k.kozlowski.k@gmail.com>
On Sat, 02 May 2015, Krzysztof Kozlowski wrote:
> 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(-)
Applied, thanks.
> 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,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 2/4] video: fbdev: imxfb: Constify platform_device_id
From: Lee Jones @ 2015-05-05 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1430494721-30793-2-git-send-email-k.kozlowski.k@gmail.com>
On Sat, 02 May 2015, Krzysztof Kozlowski wrote:
> 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(-)
Applied, thanks.
> 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,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 1/4] video: backlight: da9052: Constify platform_device_id
From: Lee Jones @ 2015-05-05 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1430494721-30793-1-git-send-email-k.kozlowski.k@gmail.com>
On Sat, 02 May 2015, Krzysztof Kozlowski wrote:
> 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(-)
Applied, thanks.
> 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,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ 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: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
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