From: "Luis R. Rodriguez"
Current documentation over use case for EXPORT_SYMBOL_GPL()
only acknowledges functions which are "an internal implementation
issue, and not really an interface". In practice these days
though we have some maintainers taking on preference
On Thu, May 28, 2015 at 01:09:23PM -0600, Jonathan Corbet wrote:
> On Thu, 28 May 2015 11:56:01 -0700
> "Luis R. Rodriguez" wrote:
>
> > +Some maintainers and developers may however have a preference to
> > +require EXPORT_SYMBOL_GPL() when adding any new A
From: "Luis R. Rodriguez"
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 advanta
On Thu, May 28, 2015 at 09:07:49PM +0100, Al Viro wrote:
> On Thu, May 28, 2015 at 11:56:01AM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > Current documentation over use case for EXPORT_SYMBOL_GPL()
> > only acknowledges functions
On Thu, May 21, 2015 at 11:32 AM, Luis R. Rodriguez wrote:
> On Thu, May 21, 2015 at 04:20:27PM +0800, Michal Marek wrote:
>> Dne 21.5.2015 v 02:53 Luis R. Rodriguez napsal(a):
>> > From: "Luis R. Rodriguez"
>> >
>> > Michal Marek, Xen folks
On Thu, May 28, 2015 at 10:56:19PM +0100, Al Viro wrote:
> On Thu, May 28, 2015 at 11:17:36PM +0200, Luis R. Rodriguez wrote:
> > > ... while some of us consider that as pointless posturing and will refuse
> > > to merge such exports regardless.
> >
> >
From: "Luis R. Rodriguez"
Tomi,
Upon integration onto your tree of the series, "[PATCH v3 00/17] framebuffer:
simple conversions to arch_phys_wc_add()" the 0 day build bot found a
compilation issue on the gbefb driver. I had test compiled drivers with
allyesconfig and allmod
From: "Luis R. Rodriguez"
This driver never removed the MTRRs. Fix that.
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Jingoo Han
Cc: Daniel Vetter
Cc: Masanari Iida
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Andy Lutomirski
Cc: Dave Airlie
Cc: Antonino Daplas
Cc: Jean-Christoph
From: "Luis R. Rodriguez"
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 req
On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez wrote:
> On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
>> On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
>> > On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
>> > >
On Tue, May 19, 2015 at 1:22 PM, Luis R. Rodriguez
wrote:
> This v2 just changes "licence" to "license" as requested by Arend.
Please let me know if there is anything else needed.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
From: "Luis R. Rodriguez"
The recent fix to use kstrdup_const() failed to add a
kfree upon failure of name allocation...
Cc: Ming Lei
Cc: Seth Forshee
Cc: Kyle McMartin
Cc: Greg Kroah-Hartman
Signed-off-by: Luis R. Rodriguez
---
Sorry about that..
drivers/base/firmware_c
Me and Julia are working on a paper which evaluates use of Coccinelle
on backports, a preliminary draft of such paper can be found on github
[0]. We are making some tweaks to this, one of which is covering the
uses of Linux backports [1] in the industry, for this we'd like to try
to get feedback as
On Mon, Jun 08, 2015 at 09:57:12PM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 08 Jun 2015 17:20:19 -0700
> "Luis R. Rodriguez" escreveu:
>
> > From: "Luis R. Rodriguez"
> >
> > Mauro,
> >
> > since the ivtv patch is already acke
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
I
From: "Luis R. Rodriguez"
Mauro,
since the ivtv patch is already acked by the driver maintainer
and depends on an x86 symbol that went through Boris' tree are you
OK in it going through Boris' tree?
Boris,
provided the outcome of the above maintainer's preference for
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
I
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: D
On Thu, Jun 11, 2015 at 10:49:59AM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Mauro,
>
> since the ivtv patch is already acked by the driver maintainer
> and depends on an x86 symbol that went through Boris' tree are you
> OK in it going
From: "Luis R. Rodriguez"
Boris,
the following patches make use of the newly exported pat_enabled()
which went in through your tree. All driver and respective subsystem
maintainers have Acked these patches and are OK for them to go in through
your tree. Please let me know if there any
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
I
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: D
The series to bury direct MTRR use is almost all in and on its way to
v4.2. As the pending series continue slowly to be merged I wanted to
take the time to reiterate the justification for these changes in
hopes it may help those still reviewing some of these patches which
are pending and to help do
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
I
On Thu, Jun 11, 2015 at 05:23:16PM -0600, Toshi Kani wrote:
> On Thu, 2015-06-11 at 13:36 -0700, Luis R. Rodriguez wrote:
> :
> > Pending RIP MTRR patches
> >
> >
> > There are a few pending series so I wanted to provide a status update
>
On Tue, Jun 2, 2015 at 11:33 AM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> This is needed the following modules:
>
> "Linux Kernel Dump Test Tool Module"
> CONFIG_LKDTMdrivers/misc/lkdtm.c
>
> Since:
> mcgrof@ergon ~/li
On Thu, May 28, 2015 at 5:48 PM, Luis R. Rodriguez wrote:
> On Tue, May 19, 2015 at 1:22 PM, Luis R. Rodriguez
> wrote:
>> This v2 just changes "licence" to "license" as requested by Arend.
>
> Please let me know if there is anything else needed.
On Tue, Jun 9, 2015 at 6:44 AM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Jun 08, 2015 at 04:35:35PM -0700, Luis R. Rodriguez wrote:
>> On Thu, May 28, 2015 at 2:50 PM, Luis R. Rodriguez
>> wrote:
>> > On Thu, May 21, 2015 at 11:32 AM, Luis R. Rodriguez
>> > wro
On Fri, Jun 12, 2015 at 12:04:14PM +0300, Tomi Valkeinen wrote:
>
>
> On 04/06/15 19:44, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > This driver uses the same area for MTRR as for the ioremap_wc(), if
> > anything it just uses a
On Thu, May 28, 2015 at 5:36 PM, Luis R. Rodriguez
wrote:
> On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez wrote:
>> On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
>>> On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
>>> > On T
On Mon, Jun 8, 2015 at 4:43 PM, Luis R. Rodriguez wrote:
> On Wed, Jun 3, 2015 at 4:50 PM, Luis R. Rodriguez wrote:
>> Ville,
>>
>> the x86 patches are in and on their way to the next version of Linux.
>> Can I trouble you for your review of the atyfb driver cha
From: "Luis R. Rodriguez"
dma_alloc_writecombine()'s call and return value check is tangled in all
in one call. Detangle both calls as we're used to.
Signed-off-by: Luis R. Rodriguez
---
drivers/dma/iop-adma.c | 9 +
1 file changed, 5 insertions(+), 4 deleti
On Mon, Jun 22, 2015 at 09:06:41AM +0200, Borislav Petkov wrote:
> On Mon, Jun 22, 2015 at 03:01:38AM +0200, Luis R. Rodriguez wrote:
> > We can certainly replace the WARN() with pr_warn(), I don't see
> > how its confusing though as its a run time real issue. Either
> >
From: "Luis R. Rodriguez"
Mauro, Doug,
The 0-day robot found using WARN() on built-in kernels confusing. Upon
further thought pr_warn() is better and will likely also not confuse
humans too.
Boris, provided maintainers Ack, please consider these patches.
These depend on pat_enabled(
From: "Luis R. Rodriguez"
On built-in kernels this will always splat. Fix that.
Reported-by: Fengguang Wu [0-day test robot]
Signed-off-by: Luis R. Rodriguez
---
drivers/infiniband/hw/ipath/ipath_driver.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
From: "Luis R. Rodriguez"
On built-in kernels this will always splat. Fix that.
Reported-by: Fengguang Wu [0-day test robot]
Signed-off-by: Luis R. Rodriguez
---
drivers/media/pci/ivtv/ivtvfb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/medi
On Tue, Jun 23, 2015 at 12:39 AM, Ingo Molnar wrote:
> Same observation as for the other patch: please only warn if the hardware is
> present and the driver tries to activate. No need to annoy others.
Will fix, and respin.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-
On Wed, Jun 24, 2015 at 08:42:23AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > PCI BARs tell us whether prefetching is safe, but they don't say anything
> &g
From: "Luis R. Rodriguez"
The 0-day robot found that the notpat requirement warning was
being triggered on the ivtv driver on the module init path,
that will always trigger on built-in devices. We want that warning
to trigger only if real hardware is found so this moves the ivtv
w
From: "Luis R. Rodriguez"
WARN() may confuse users, fix that. ipath_init_one() is part the
device's probe so this would only be triggered if a corresponding
device was found.
Signed-off-by: Luis R. Rodriguez
---
drivers/infiniband/hw/ipath/ipath_driver.c | 6 --
1
From: "Luis R. Rodriguez"
On built-in kernels this warning will always splat as this is part
of the module init. Fix that by shifting the PAT requirement check
out under the code that does the "quasi-probe" for the device. This
device driver relies on an existing driver to
On Wed, Jun 24, 2015 at 3:05 PM, Benjamin Herrenschmidt
wrote:
> On Wed, 2015-06-24 at 18:38 +0200, Luis R. Rodriguez wrote:
>> On Wed, Jun 24, 2015 at 08:42:23AM +1000, Benjamin Herrenschmidt wrote:
>> > On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
>> >
On Tue, Jun 16, 2015 at 12:40 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> dma_alloc_writecombine()'s call and return value check is tangled in all
> in one call. Detangle both calls as we're used to.
>
> Signed-off-by: Luis R. Rodriguez
On Thu, Jun 25, 2015 at 09:38:01AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2015-06-24 at 15:29 -0700, Luis R. Rodriguez wrote:
>
> > Nope but at least what made me squint at this being a possible
> > "feature" was that in practice when reviewing all of th
On Wed, Jun 24, 2015 at 5:52 PM, Benjamin Herrenschmidt
wrote:
> On Thu, 2015-06-25 at 02:08 +0200, Luis R. Rodriguez wrote:
>>
>> OK thanks I'll proceed with these patches then.
>>
>> > As for user mappings,
>>
>> Which APIs were you considering i
From: "Luis R. Rodriguez"
Boris,
This patchset is part of the long haul of series that addresses removal of
direct use of MTRR and transforms drivers over to use PAT interfaces when
available [0]. Other than this series there is only one more pending series for
that effort, the other
On Fri, Jun 19, 2015 at 3:22 PM, Luis R. Rodriguez wrote:
> Tomi, Dave, Andy,
>
> Its' been one month now since posting the last unmodified version
> (other than commit log) of this series [0] and no word or follow up
> from Ville. The merge window is closing in and other th
From: "Luis R. Rodriguez"
This lets drivers take advantage 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() (de33c4
From: "Luis R. Rodriguez"
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 req
From: "Luis R. Rodriguez"
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 req
From: "Luis R. Rodriguez"
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 for this:
a)
From: "Luis R. Rodriguez"
PCI BARs tell us whether prefetching is safe, but they don't say anything
about write combining (WC). WC changes ordering rules and allows writes to
be collapsed, so it's not safe in general to use it on a prefetchable
region.
Add pci_iomap_wc() an
From: "Luis R. Rodriguez"
Andrew,
Forgive me for the TL;DR, I'm afraid I need to be crystal clear on this
patchset as its the most complex in the entire series. The skinny is that this
patchset addresses a complex work around with APIs now merged upstream going in
for v
From: "Luis R. Rodriguez"
Now that we have pci_iomap_wc() add the respective
devres helpers. These go unexported for now but
note that should they later be exported this
must go with EXPORT_SYMBOL_GPL().
Cc: Toshi Kani
Cc: Andy Lutomirski
Cc: Suresh Siddha
Cc: Ingo Molnar
From: "Luis R. Rodriguez"
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 PC
From: "Luis R. Rodriguez"
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 req
From: "Luis R. Rodriguez"
Replace a WC MTRR call followed by a UC MTRR "hole" call
with a single WC MTRR call and use strong UC to protect
the MMIO region and account for the device's architecture
and MTRR size requirements.
The atyfb driver relies on two overlappi
From: "Luis R. Rodriguez"
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 advanta
From: "Luis R. Rodriguez"
This driver uses strong UC for the MMIO region, and ioremap_wc()
for the framebuffer to whitelist for the WC MTRR what can be changed
to WC. On PAT systems we don't need the MTRR call so just use
arch_phys_wc_add() there, this lets us remove all those if
From: "Luis R. Rodriguez"
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 advanta
On Thu, Jun 04, 2015 at 10:20:23AM +0530, Sreekanth Reddy wrote:
> Hi Luis,
>
> Sorry for delay in response. Actually I was looking for the history of
> this section of code but I couldn't find it. Anyway this is dead code
> and we are fine with removing this dead code.
>
> James,
>
> Please con
On Fri, Jun 05, 2015 at 05:17:08PM +0530, Sreekanth Reddy wrote:
> On Thu, Jun 4, 2015 at 11:11 PM, Luis R. Rodriguez wrote:
> > On Thu, Jun 04, 2015 at 10:20:23AM +0530, Sreekanth Reddy wrote:
> >> Hi Luis,
> >>
> >> Sorry for delay in response. Actua
On Tue, Jun 2, 2015 at 11:42 AM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> All the ia64 pvops code is now dead code since both
> xen and kvm support have been ripped out [0] [1]. Just
> that no one had troubled to rip this stuff out. The only
> useful r
On Thu, May 28, 2015 at 2:50 PM, Luis R. Rodriguez
wrote:
> On Thu, May 21, 2015 at 11:32 AM, Luis R. Rodriguez wrote:
>> On Thu, May 21, 2015 at 04:20:27PM +0800, Michal Marek wrote:
>>> Dne 21.5.2015 v 02:53 Luis R. Rodriguez napsal(a):
>>> > From: "Luis R. R
On Wed, Jun 3, 2015 at 4:50 PM, Luis R. Rodriguez wrote:
> Ville,
>
> the x86 patches are in and on their way to the next version of Linux.
> Can I trouble you for your review of the atyfb driver changes?
Hey Ville, just a friendly *poke*.
Luis
--
To unsubscribe from this list: s
From: "Luis R. Rodriguez"
Mauro,
since the ivtv patch is already acked by the driver maintainer
and depends on an x86 symbol that went through Boris' tree are you
OK in it going through Boris' tree?
Boris,
provided the outcome of the above maintainer's preference for
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
I
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: D
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
I
On Mon, Jun 01, 2015 at 01:36:23PM -0600, Toshi Kani wrote:
> This patchset adds support of Write-Through (WT) mapping on x86.
> The study below shows that using WT mapping may be useful for
> non-volatile memory.
>
> http://www.hpl.hp.com/techreports/2012/HPL-2012-236.pdf
>
> The patchset consis
From: "Luis R. Rodriguez"
This is needed the following modules:
"Linux Kernel Dump Test Tool Module"
CONFIG_LKDTMdrivers/misc/lkdtm.c
Since:
mcgrof@ergon ~/linux-next (git::master)$ git describe --contains aac416fc38cdf
v3.15-rc1~141^2~84
CONFIG_STI_CONSOL
From: "Luis R. Rodriguez"
This is needed the following modules:
"Linux Kernel Dump Test Tool Module"
CONFIG_LKDTMdrivers/misc/lkdtm.c
Since:
mcgrof@ergon ~/linux-next (git::master)$ git describe --contains aac416fc38cdf
v3.15-rc1~141^2~84
CONFIG_STI_CONSOL
From: "Luis R. Rodriguez"
All the ia64 pvops code is now dead code since both
xen and kvm support have been ripped out [0] [1]. Just
that no one had troubled to rip this stuff out. The only
useful remaining pieces were the old pvops docs but that
was recently also generalized and move
On Tue, Jun 02, 2015 at 12:46:48PM -0600, Toshi Kani wrote:
> On Tue, 2015-06-02 at 18:21 +0200, Luis R. Rodriguez wrote:
> > On Mon, Jun 01, 2015 at 01:36:23PM -0600, Toshi Kani wrote:
> > > This patchset adds support of Write-Through (WT) mapping on x86.
> > > The stud
On Tue, Jun 02, 2015 at 12:50:09PM -0700, Andy Lutomirski wrote:
> On Tue, Jun 2, 2015 at 12:43 PM, Luis R. Rodriguez wrote:
> > On Tue, Jun 02, 2015 at 12:46:48PM -0600, Toshi Kani wrote:
> >> On Tue, 2015-06-02 at 18:21 +0200, Luis R. Rodriguez wrote:
> >> > On M
On Fri, May 29, 2015 at 1:23 PM, Luis R. Rodriguez wrote:
> On Wed, Apr 29, 2015 at 12:50 PM, Luis R. Rodriguez wrote:
>> On Tue, Apr 21, 2015 at 1:46 PM, Luis R. Rodriguez
>> wrote:
>>> From: "Luis R. Rodriguez"
>>>
>>> If and when this
On Wed, Apr 29, 2015 at 2:44 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> This series addresses one commend fix on the table for mtrr_add()
> effect on the PAT case when UC- is used. Other than that it is
> the same as v4.
>
> Luis R. Rodrigu
On Wed, Jun 3, 2015 at 10:55 PM, Tomi Valkeinen wrote:
>
>
> On 20/05/15 22:46, Luis R. Rodriguez wrote:
>> On Wed, May 20, 2015 at 12:52:14PM +0300, Tomi Valkeinen wrote:
>
>>> Hmm, this looks a bit odd... You're removing the pseudo_palette, and
>>> us
From: "Luis R. Rodriguez"
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 MTR
From: "Luis R. Rodriguez"
The MTRR added was never being deleted, in order to store the
MTRR cookie we need to make use of the private info->par so we
create a struct for this. This driver was already using the extra
space typically used for info->par for the info->pseudo_pale
From: "Luis R. Rodriguez"
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
From: "Luis R. Rodriguez"
Tomi,
This v4 fixes the issue of the use of the old use of
info->par for the pseudo_palette and our need to extend
it for the MTRR cookie by extending our proposed new
struct vesafb_par with the pseudo_palette and later
pointing info->pseudo_palette
On Thu, May 28, 2015 at 10:00:09PM -0700, Christoph Hellwig wrote:
> On Fri, May 29, 2015 at 01:10:44AM +0200, Luis R. Rodriguez wrote:
> > Great, thanks. This seems to be in alignment with those who have all along
> > said
> > they've used EXPORT_SYMBOL() to mean what
On Fri, May 29, 2015 at 10:36 AM, Theodore Ts'o wrote:
> On Fri, May 29, 2015 at 05:01:00PM +0200, Richard Weinberger wrote:
>> On Fri, May 29, 2015 at 4:53 PM, Enrico Weigelt, metux IT consult
>> wrote:
>> > Am 29.05.2015 um 04:54 schrieb Luis R. Rodriguez:
Just
On Thu, May 28, 2015 at 10:57 PM, Tomi Valkeinen wrote:
>
>
> On 29/05/15 03:36, Luis R. Rodriguez wrote:
>> On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez wrote:
>>> On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
>>>> On Fri, May
On Wed, Apr 29, 2015 at 12:50 PM, Luis R. Rodriguez wrote:
> On Tue, Apr 21, 2015 at 1:46 PM, Luis R. Rodriguez
> wrote:
>> From: "Luis R. Rodriguez"
>>
>> If and when this gets enabled the driver could should split
>> up IO memory space properly and tha
On Fri, May 29, 2015 at 08:48:46AM +0300, Tomi Valkeinen wrote:
>
>
> On 29/05/15 03:30, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > Tomi,
> >
> > Upon integration onto your tree of the series, "[PATCH v3 00/17]
>
From: "Luis R. Rodriguez"
Tomi,
this v5 series goes with the patch 3/17 titled "video: fbdev: gbefb:
use arch_phys_wc_add() and devm_ioremap_wc()" with a change from
dma_free_coherent() to dma_free_writecombine() for the area now allocated
with dma_alloc_writecombine(). T
From: "Luis R. Rodriguez"
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 req
On Fri, May 29, 2015 at 08:41:44AM +0200, Ingo Molnar wrote:
>
> * Luis R. Rodriguez wrote:
>
> > + gbe_mem = devm_ioremap_wc(&p_dev->dev, gbe_mem_phys,
> > + gbe_mem_size);
>
> > + gbe_mem = dma_
On Mon, Jun 1, 2015 at 1:53 AM, Ingo Molnar wrote:
>
> * Luis R. Rodriguez wrote:
>
>> On Fri, May 29, 2015 at 08:41:44AM +0200, Ingo Molnar wrote:
>> >
>> > * Luis R. Rodriguez wrote:
>> >
>> > > +
From: "Luis R. Rodriguez"
If and when this gets enabled the driver could should split
up IO memory space properly and that is quite a bit of work.
Just remove the uncommented dead MTRR code then.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help
On Wed, Jun 10, 2015 at 3:11 PM, Tony Luck wrote:
> On Tue, Jun 2, 2015 at 11:42 AM, Luis R. Rodriguez
> wrote:
>> From: "Luis R. Rodriguez"
>>
>> All the ia64 pvops code is now dead code since both
>> xen and kvm support have been ripped out [0] [1].
On Tue, Jun 16, 2015 at 3:20 PM, Bjorn Helgaas wrote:
> On Tue, Jun 16, 2015 at 2:16 PM, Luis R. Rodriguez
> wrote:
>> On Thu, May 28, 2015 at 5:36 PM, Luis R. Rodriguez
>> wrote:
>>> On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez wrote:
>>>> On Tue,
From: "Luis R. Rodriguez"
Arnd,
After a long-winded conversation with Bjorn over use of
EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL() he's noted he'd
be OK if this goes through you as an alternative. This series
goes unmodified from the last posted v6 series, I am just
repo
From: "Luis R. Rodriguez"
This lets drivers take advantage 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() (de33c4
From: "Luis R. Rodriguez"
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 req
From: "Luis R. Rodriguez"
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 req
From: "Luis R. Rodriguez"
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 for this:
a)
On Tue, Jun 16, 2015 at 12:31 PM, Luis R. Rodriguez wrote:
> On Mon, Jun 8, 2015 at 4:43 PM, Luis R. Rodriguez wrote:
>> On Wed, Jun 3, 2015 at 4:50 PM, Luis R. Rodriguez wrote:
>>> Ville,
>>>
>>> the x86 patches are in and on their way to the next version
701 - 800 of 3151 matches
Mail list logo
