From: Luis R. Rodriguez mcg...@suse.com
The same area used for MTRR is used for the ioremap() 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
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
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
From: Luis R. Rodriguez mcg...@suse.com
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
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations
From: Luis R. Rodriguez mcg...@suse.com
Ideally on systems using PAT we can expect a swift
transition away from MTRR. There can be a few exceptions
to this, one is where device drivers are known to exist
on PATs with errata, another situation is observed on
old device drivers where devices had
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr
From: Luis R. Rodriguez mcg...@suse.com
No other video driver uses MTRR types except for MTRR_TYPE_WRCOMB,
the other MTRR types were implemented and supported here but with
no real good reason. The ioremap() APIs are architecture agnostic and
at least on x86 PAT is a new design that extends MTRRs
From: Luis R. Rodriguez mcg...@suse.com
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
From: Luis R. Rodriguez mcg...@suse.com
There area few users of mtrr_type_lookup(), including PAT.
Note that PAT can be in theory enabled without MTRR fully
kicking in, such is the case with Xen.
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh
From: Luis R. Rodriguez mcg...@suse.com
This has no functional changes, it just adjusts
the ioremap() call for the framebuffer to use
the same values we later use for the framebuffer,
this will make it easier to review the next change.
The size of the framebuffer varies but since this is
for PCI
From: Luis R. Rodriguez mcg...@suse.com
If and when this gets enabled the driver should address
using ioremap_wc() on the same area, that could require
a bit of work as it would mean a split with two ioremap'd
areas. Annotate this.
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha
From: Luis R. Rodriguez mcg...@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
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
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
From: Luis R. Rodriguez mcg...@suse.com
When a system has PAT support enabled you don't need to be
using MTRRs. Andy had added arch_phys_wc_add() long ago to
help with this but not all drivers were converted over. We
have to take care to only convert drivers where we know that
the proper
From: Luis R. Rodriguez mcg...@suse.com
This allows drivers to take advantage of write-combining
when possible. Ideally we'd have pci_read_bases() just
peg an IORESOURCE_WC flag for us but where exactly
video devices memory lie varies *largely* and at times things
are mixed with MMIO registers
From: Luis R. Rodriguez mcg...@suse.com
Although this driver gives the framebuffer layer a different
size for the framebuffer it uses the entire aperture PCI BAR
size for the MTRR. Since the framebuffer is included in that
range and MTRR was used on the entire PCI BAR WC will have
been preferred
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same ioremap()'d area for the MTRR.
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
From: Luis R. Rodriguez mcg...@suse.com
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
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
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
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap_wc(), if
anything it just uses a smaller size in case MTRR reservation fails.
ioremap_wc() API is already used to take advantage of architecture
write-combining when available.
Convert the driver
From: Luis R. Rodriguez mcg...@suse.com
The MTRR added was never being deleted.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel
From: Luis R. Rodriguez mcg...@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
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
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
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advanate of PAT when available. This
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache
From: Luis R. Rodriguez mcg...@suse.com
This driver sadly does not have the MMIO registers and WC
desired areas (PIO buffers in this case) properly split up
and addressing a split is considerable work, as such this
such requires using the __arch_phys_wc_add() call to
ensure write combining
From: Luis R. Rodriguez mcg...@suse.com
There is only one user but since we're going to bury
MTRR next out of access to drivers expose this last
piece of API to drivers in a general fashion only
needing io.h for access to helpers.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh
From: Luis R. Rodriguez mcg...@suse.com
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
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
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
From: Luis R. Rodriguez mcg...@suse.com
It is possible to enable CONFIG_MTRR and up with it
disabled at run time and yet CONFIG_X86_PAT continues
to kick through fully functionally. This can happen
for instance on Xen where MTRR is not supported but
PAT is, this can happen now on Linux
From: Luis R. Rodriguez mcg...@suse.com
The atyfb driver uses an MTRR work around since some
cards use the same PCI BAR for the framebuffer and MMIO.
In such cards the last page is used for MMIO, the rest for
the framebuffer, so on those cards we ioremap() the MMIO
page alone, then again ioremap
From: Luis R. Rodriguez mcg...@suse.com
This driver already makes use of ioremap_wc() on PIO buffers,
so convert it to use arch_phys_wc_add().
Cc: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Cc: Dennis Dalessandro dennis.dalessan...@intel.com
Cc: Mike Marciniszyn mike.marcinis
From: Luis R. Rodriguez mcg...@suse.com
Sadly this driver requires a bit of work in order
to use ioremap_wc() on the range currently used
for MTRR write-combining. We'd need to ensure two
ioremap() calls are done. Annotate this.
Cc: Andy Lutomirski l...@amacapital.net
Cc: Andy Walls awa
From: Luis R. Rodriguez mcg...@suse.com
This driver already uses ioremap_wc() on the same range
so when write-combining is available that will be used
instead.
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip
From: Luis R. Rodriguez mcg...@suse.com
This driver never removed the MTRRs. Fix that.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR and ioremap().
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
From: Luis R. Rodriguez mcg...@suse.com
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
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
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
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
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
From: Luis R. Rodriguez mcg...@suse.com
The crusade to replace mtrr_add() with architecture agnostic
arch_phys_wc_add() is complete, this will ensure write-combining
implementations (PAT on x86) is taken advantage instead of using
MTRR. With the crusade done now, hide direct MTRR access
From: Luis R. Rodriguez mcg...@suse.com
We have devm_ioremap_nocache() but no devm_ioremap_wc()
so add that. This will be used later.
Cc: Suresh Siddha suresh.b.sid...@intel.com
Cc: Venkatesh Pallipadi venkatesh.pallip...@intel.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t
From: Luis R. Rodriguez mcg...@suse.com
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
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
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
From: Luis R. Rodriguez mcg...@suse.com
This driver uses the same area for MTRR as for the ioremap().
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
From: Luis R. Rodriguez mcg...@suse.com
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations
On Tue, Mar 10, 2015 at 05:58:27PM -0700, David Rientjes wrote:
On Tue, 10 Mar 2015, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
These were here mostly to help as wrappers for PCI_MSI
under certain UP 32-bit build scenarios, now that PCI_MSI
properly selects what
From: Luis R. Rodriguez mcg...@suse.com
There is no need for UP APIC Kconfig entries given x86 is not
in a state of flux for 32-bit and the options really don't
have major impact on kernel size or performance. Things can
also be expressed very clearly in a more simplified way, doing
that also
On Tue, Mar 10, 2015 at 05:49:10PM -0700, David Rientjes wrote:
On Tue, 10 Mar 2015, Luis R. Rodriguez wrote:
diff --git a/Documentation/PCI/MSI-HOWTO.txt
b/Documentation/PCI/MSI-HOWTO.txt
index 0d920d5..7306d2c 100644
--- a/Documentation/PCI/MSI-HOWTO.txt
+++ b/Documentation/PCI/MSI
From: Luis R. Rodriguez mcg...@suse.com
X86_UP_APIC is used for two reasons on 32-bit systems:
1) set a series of dependencies under which we would like
to express we want X86_LOCAL_APIC enabled
2) under the above conditions if PCI_MSI is enabled always
force X86_LOCAL_APIC to be enabled
3
From: Luis R. Rodriguez mcg...@suse.com
X86_UP_IOAPIC is a way so that 32-bit UP systems can enable
X86_IOAPIC. X86_UP_IOAPIC is only as a visible user option if
you are on a 32-bit system but have X86_UP_APIC enabled. X86_UP_APIC
will be enabled by force if you have PCI_MSI on 32-bit systems
now
On Fri, Mar 06, 2015 at 11:02:50AM -0500, Konrad Rzeszutek Wilk wrote:
On Wed, Mar 04, 2015 at 05:47:03PM -0800, Luis R. Rodriguez wrote:
On Wed, Mar 4, 2015 at 6:36 AM, Andrey Ryabinin a.ryabi...@samsung.com
wrote:
On 03/03/2015 07:02 PM, Konrad Rzeszutek Wilk wrote:
If it is like
On Thu, Mar 12, 2015 at 01:19:14AM +, Bryan O'Donoghue wrote:
On 11/03/15 23:10, Luis R. Rodriguez wrote:
ACK the concept - the logic to compile up APIC support is circuitous
to say the least.
It took me a while to grok this and indeed the goal was to make it
much simpler to read
On Thu, Mar 12, 2015 at 02:42:01AM -0600, Jan Beulich wrote:
On 12.03.15 at 00:10, mcg...@do-not-panic.com wrote:
config X86_LOCAL_APIC
def_bool y
- depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC ||
PCI_MSI
+ depends on X86_64 || SMP || X86_32_NON_STANDARD ||
On Wed, Mar 11, 2015 at 10:36:41PM -0700, David Rientjes wrote:
On Wed, 11 Mar 2015, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
X86_UP_IOAPIC is a way so that 32-bit UP systems can enable
X86_IOAPIC. X86_UP_IOAPIC is only as a visible user option if
you
From: Luis R. Rodriguez mcg...@suse.com
There's quite a bit of Kconfig entries related to X86_LOCAL_APIC
and X86_IO_APIC, and all for 32-bit purposes. Since 32-bit isn't in
a magical state of flux we now *should* know when to enable or disable
APIC stuff for these systems. Through history we've
From: Luis R. Rodriguez mcg...@suse.com
Commit 38a1dfda by Bryan O'Donoghue fixed a build issue
when PCI_MSI support is enabled on non-SMP X86_32 systems,
this was done by introducing a new Kconfig entry,
X86_UP_APIC_MSI, with the only purpose of selecting
X86_UP_APIC under certain conditions
From: Luis R. Rodriguez mcg...@suse.com
These were here mostly to help as wrappers for PCI_MSI
under certain UP 32-bit build scenarios, now that PCI_MSI
properly selects what it needs and when it needs it these
Kconfig options are now only enabling users reduce the size
of 32-bit kernels
On Fri, Mar 20, 2015 at 04:49:51PM -0700, Andy Lutomirski wrote:
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
We have devm_ioremap_nocache() but no devm_ioremap_wc()
so add that. This will be used later.
Cc
On Wed, Mar 25, 2015 at 04:03:46PM -0400, Konrad Rzeszutek Wilk wrote:
On Fri, Mar 20, 2015 at 04:17:54PM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advanate of PAT when available. This
s/advanate/advantage/
Amended.
should help
On Fri, Mar 20, 2015 at 04:50:32PM -0700, Andy Lutomirski wrote:
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets drivers take advanate of PAT when available. This
should help with the transition
On Mon, Feb 23, 2015 at 9:09 AM, David Vrabel david.vra...@citrix.com wrote:
On 23/02/15 16:01, Boris Ostrovsky wrote:
Commit 1e02ce4cccdc (x86: Store a per-cpu shadow copy of CR4)
introduced CR4 shadows.
These shadows are initialized in early boot code. The commit missed
initialization for
On Tue, Mar 3, 2015 at 2:06 AM, David Vrabel david.vra...@citrix.com wrote:
On 03/03/15 09:40, Luis R. Rodriguez wrote:
Andrey,
I believe that on Xen we should disable kasan, would like confirmation
Why? This is the first of heard of this.
Andrey chimed in here confirming this.
from
On Tue, Mar 03, 2015 at 09:27:34AM -0500, Boris Ostrovsky wrote:
On 03/03/2015 12:35 AM, Luis R. Rodriguez wrote:
On Mon, Feb 23, 2015 at 9:09 AM, David Vrabel david.vra...@citrix.com
wrote:
On 23/02/15 16:01, Boris Ostrovsky wrote:
Commit 1e02ce4cccdc (x86: Store a per-cpu shadow copy
From: Luis R. Rodriguez mcg...@suse.com
The enabler / disabler is pretty simple, just use the
provided wrappers, this lets us easily relate the variable
to the associated Kconfig entry.
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Tony Lindgren t...@atomide.com
Cc: linux-kernel
On Wed, Mar 4, 2015 at 6:36 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote:
On 03/03/2015 07:02 PM, Konrad Rzeszutek Wilk wrote:
If it is like that - then just using what had to be implemented
for the stack protection as a template ought to pave most of the
work?
Probably. I think I could
From: Luis R. Rodriguez mcg...@suse.com
Replace #ifdef eyesore with IS_ENABLED() use.
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Tony Lindgren t...@atomide.com
Cc: linux-kernel@vger.kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h
From: Luis R. Rodriguez mcg...@suse.com
While reviewing DIRECT_GBPAGES I noticed some inconsistancies
on when its cached enable variable is set and when in reality
its full feature is enabled. There's also some code simplification
possible by simply using Kconfig, so decided to take advantage
From: Luis R. Rodriguez mcg...@suse.com
direct_gbpages can be force enabled as an early parameter
but not really have taken effect when DEBUG_PAGEALLOC
or KMEMCHECK is enabled. You can also enable direct_gbpages
right now if you have an x86_64 architecture but your CPU
doesn't really have support
From: Luis R. Rodriguez mcg...@suse.com
At times all you need is a kconfig variable to enable a feature,
by default but you may want to also enable / disable it through
a kernel parameter. In such cases the parameter routines to turn
the thing on / off are really simple. Just use a wrapper
Andrey,
I believe that on Xen we should disable kasan, would like confirmation
from someone on xen-devel though. Here's the thing though -- if true
-- I'd like to do it *properly*, where *properly* means addressing a
bit of architecture. A simple Kconfig slap seems rather reactive. I'd
like to
On Wed, Feb 25, 2015 at 12:49 PM, David Rientjes rient...@google.com wrote:
Woohoo, so does this mean that Luis's series will finally be merged into a
tree somewhere? It's been a lengthy wait to try to get this merged.
David Rientjes (as I'm also Cc'ing David Vrabel),
I am reworking Xen's
On Wed, Feb 25, 2015 at 1:19 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Wed, Feb 25, 2015 at 01:11:04PM -0800, David Rientjes wrote:
On Wed, 25 Feb 2015, Luis R. Rodriguez wrote:
I am reworking Xen's kconfig stuff right now, so perhaps what is best
is for this series
On Fri, Feb 20, 2015 at 7:02 AM, Jonathan Bither jonbit...@gmail.com wrote:
On 02/19/2015 08:03 PM, valdis.kletni...@vt.edu wrote:
On Fri, 20 Feb 2015 01:53:44 +0100, Luis R. Rodriguez said:
Wider community:
anyone aware of any *need* in the kernel to know whether one is indoor
On Fri, Mar 27, 2015 at 12:58:02PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 12:53 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Mar 20, 2015 at 04:48:46PM -0700, Andy Lutomirski wrote:
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote
On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty
On Fri, Mar 27, 2015 at 12:43:55PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 12:38 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez wrote:
diff --git a/drivers
On Fri, Mar 20, 2015 at 04:52:18PM -0700, Andy Lutomirski wrote:
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video
On Fri, Mar 27, 2015 at 10:37:04AM +0200, Ville Syrjälä wrote:
On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
On Fri, Mar 20, 2015 at 04:48:46PM -0700, Andy Lutomirski wrote:
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
Ideally on systems using PAT we can expect a swift
transition away from MTRR. There can be a few
On Sat, Mar 21, 2015 at 04:08:00PM +0900, Hyong-Youb Kim wrote:
On Fri, Mar 20, 2015 at 04:18:11PM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This driver already uses ioremap_wc() on the same range
so when write-combining is available that will be used
On Wed, Mar 25, 2015 at 04:07:43PM -0400, Konrad Rzeszutek Wilk wrote:
On Fri, Mar 20, 2015 at 04:17:55PM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This allows drivers to take advantage of write-combining
when possible. Ideally we'd have pci_read_bases
On Fri, Mar 27, 2015 at 02:23:16PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 1:30 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Mar 27, 2015 at 12:58:02PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 12:53 PM, Luis R. Rodriguez mcg...@suse.com
wrote:
On Fri
On Fri, Mar 27, 2015 at 02:21:34PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 1:12 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Mar 20, 2015 at 04:52:18PM -0700, Andy Lutomirski wrote:
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote
On Fri, Mar 27, 2015 at 04:10:03PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 4:04 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Mar 27, 2015 at 02:23:16PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 1:30 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Mar
On Wed, Mar 25, 2015 at 03:59:41PM -0400, Konrad Rzeszutek Wilk wrote:
On Fri, Mar 20, 2015 at 04:17:52PM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
It is possible to enable CONFIG_MTRR and up with it
disabled at run time and yet CONFIG_X86_PAT continues
On Mon, Mar 23, 2015 at 12:20:47PM -0500, Bjorn Helgaas wrote:
Hi Luis,
This seems OK to me,
Great.
but I'm curious about a few things.
On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
This allows drivers
On Fri, Mar 27, 2015 at 02:40:17PM -0600, Toshi Kani wrote:
On Fri, 2015-03-20 at 16:17 -0700, Luis R. Rodriguez wrote:
:
@@ -734,6 +742,7 @@ void __init mtrr_bp_init(void)
}
if (mtrr_if) {
+ mtrr_enabled = true;
set_num_var_ranges
On Fri, Mar 27, 2015 at 03:02:10PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 2:56 PM, Ville Syrjälä syrj...@sci.fi wrote:
On Fri, Mar 27, 2015 at 08:57:59PM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015 at 12:43:55PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015
On Fri, Mar 27, 2015 at 11:56:55PM +0200, Ville Syrjälä wrote:
On Fri, Mar 27, 2015 at 08:57:59PM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015 at 12:43:55PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 12:38 PM, Luis R. Rodriguez mcg...@suse.com
wrote:
On Sat, Mar 21
On Tue, Jan 13, 2015 at 11:13 AM, Julien Grall julien.gr...@linaro.org wrote:
Stefano had some comments on this patch. See:
http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01531.html
I see now sorry about that, will address and respin.
Luis
--
To unsubscribe from this list:
On Thu, Dec 18, 2014 at 02:23:14PM -0500, Konrad Rzeszutek Wilk wrote:
index 000..b5a3e98
--- /dev/null
+++ b/drivers/xen/preempt.c
@@ -0,0 +1,17 @@
+/*
+ * Preemptible hypercalls
+ *
+ * Copyright (C) 2014 Citrix Systems RD ltd.
+ *
+ * This source code is free software;
On Tue, Jan 27, 2015 at 12:00 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Jan 23, 2015 at 03:19:25PM +, Stefano Stabellini wrote:
On Fri, 23 Jan 2015, Luis R. Rodriguez wrote:
On Wed, Jan 14, 2015 at 11:33:45AM -0800, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg
On Tue, Jan 27, 2015 at 10:06:44AM +, David Vrabel wrote:
On 27/01/15 08:35, Jan Beulich wrote:
On 27.01.15 at 02:51, mcg...@do-not-panic.com wrote:
Even if David told you this would be acceptable, I have to question
an abstract model of fixing issues on only 64-bit kernels - this
On Sat, Mar 28, 2015 at 02:23:34PM +0200, Ville Syrjälä wrote:
On Sat, Mar 28, 2015 at 01:28:18AM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015 at 03:02:10PM -0700, Andy Lutomirski wrote:
On Fri, Mar 27, 2015 at 2:56 PM, Ville Syrjälä syrj...@sci.fi wrote:
On Fri, Mar 27, 2015
On Thu, Apr 2, 2015 at 1:13 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Thu, Mar 26, 2015 at 6:35 PM, Luis R. Rodriguez mcg...@suse.com wrote:
I'll rephrase this to:
---
It is possible to enable CONFIG_MTRR and up with it
disabled at run time and yet CONFIG_X86_PAT continues
On Wed, Apr 01, 2015 at 05:04:08PM -0700, Andy Lutomirski wrote:
On Wed, Apr 1, 2015 at 4:52 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Sat, Mar 28, 2015 at 02:23:34PM +0200, Ville Syrjälä wrote:
On Sat, Mar 28, 2015 at 01:28:18AM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015
On Thu, Apr 2, 2015 at 3:09 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Thu, Apr 2, 2015 at 4:02 PM, Luis R. Rodriguez mcg...@suse.com wrote:
---
It is possible to enable CONFIG_MTRR and CONFIG_X86_PAT
and end up with a system with MTRR functionality disabled
PAT functionality enabled
On Sat, Mar 28, 2015 at 12:56:30AM +0100, Luis R. Rodriguez wrote:
On Fri, Mar 27, 2015 at 02:40:17PM -0600, Toshi Kani wrote:
On Fri, 2015-03-20 at 16:17 -0700, Luis R. Rodriguez wrote:
:
@@ -734,6 +742,7 @@ void __init mtrr_bp_init(void)
}
if (mtrr_if
On Thu, Apr 02, 2015 at 03:21:22PM -0500, Bjorn Helgaas wrote:
On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
Ideally on systems using PAT we can expect a swift
transition away from MTRR. There can be a few
701 - 800 of 6292 matches
Mail list logo
