On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you think the time is right to just remove the iPath driver?
With PAT now
On Wed, Apr 22, 2015 at 10:17:55AM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you think the
On Wed, Apr 22, 2015 at 8:23 AM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you think the time is right to just remove the iPath driver?
With PAT now
On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you think the time is right to just remove the iPath driver?
With PAT now
On Wed, Apr 22, 2015 at 8:54 AM, Luis R. Rodriguez mcg...@suse.com wrote:
On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you
On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you think the time is right to just remove the iPath driver?
With PAT now being default the driver effectively won't work
with write-combining on
On Wed, Apr 22, 2015 at 09:53:03AM -0700, Andy Lutomirski wrote:
On Wed, Apr 22, 2015 at 8:23 AM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you think
On Wed, 2015-04-22 at 10:17 -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you think the time is
On Wed, Apr 22, 2015 at 02:53:11PM -0400, Doug Ledford wrote:
On Wed, 2015-04-22 at 10:17 -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 01:39:07AM
On Wed, 2015-04-22 at 21:05 +0200, Luis R. Rodriguez wrote:
I'd also love to remove the driver if it turns out there are actually
no users. qib substantially replaces it except for a few very old
cards.
To be precise, the split is that ipath powers the old HTX bus cards that
only
On Wed, Apr 22, 2015 at 12:10 PM, Doug Ledford dledf...@redhat.com wrote:
On Wed, 2015-04-22 at 21:05 +0200, Luis R. Rodriguez wrote:
I'd also love to remove the driver if it turns out there are actually
no users. qib substantially replaces it except for a few very old
cards.
To be
On Wed, Apr 22, 2015 at 02:53:11PM -0400, Doug Ledford wrote:
To be precise, the split is that ipath powers the old HTX bus cards that
only work in AMD systems, qib is all PCI-e cards. I still have a few
HTX cards, but I no longer have any systems with HTX slots, so we
haven't even used this
On Wed, 2015-04-22 at 14:46 -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 02:53:11PM -0400, Doug Ledford wrote:
To be precise, the split is that ipath powers the old HTX bus cards that
only work in AMD systems, qib is all PCI-e cards. I still have a few
HTX cards, but I no longer
On Wed, Apr 15, 2015 at 05:58:14PM -0700, Andy Lutomirski wrote:
On Wed, Apr 15, 2015 at 4:59 PM, Andy Walls awa...@md.metrocast.net wrote:
On Wed, 2015-04-15 at 16:42 -0700, Andy Lutomirski wrote:
On Wed, Apr 15, 2015 at 3:38 PM, Andy Walls awa...@md.metrocast.net
wrote:
IMO the
On Tue, Apr 21, 2015 at 3:08 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Tue, Apr 21, 2015 at 3:02 PM, Luis R. Rodriguez mcg...@suse.com wrote:
Andy, can we live without MTRR support on this driver for future kernels?
This
would only leave ipath as the only offending driver.
Sorry to be
On Tue, Apr 21, 2015 at 3:02 PM, Luis R. Rodriguez mcg...@suse.com wrote:
Andy, can we live without MTRR support on this driver for future kernels? This
would only leave ipath as the only offending driver.
Sorry to be clear, can we live with removal of write-combining on this driver?
Luis
--
On Wed, Apr 15, 2015 at 01:42:47PM -0700, Andy Lutomirski wrote:
On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez mcg...@suse.com wrote:
c) ivtv: the driver does not have the PCI space mapped out separately, and
in fact it actually does not do the math for the framebuffer, instead it
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you think the time is right to just remove the iPath driver?
With PAT now being default the driver effectively won't work
with write-combining on modern kernels. Even if systems are old
they likely had PAT support,
On Wed, Apr 22, 2015 at 12:46:01AM +0200, Luis R. Rodriguez wrote:
are talking about annotating the qib driver as known to be broken without
PAT
and since the ipath driver needs considerable work to be ported to
use PAT (the
This only seems to be true for one of the chips that driver
On Tue, Apr 21, 2015 at 04:57:32PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 12:46:01AM +0200, Luis R. Rodriguez wrote:
are talking about annotating the qib driver as known to be broken without
PAT
and since the ipath driver needs considerable work to be ported to
use PAT
On Tue, Apr 21, 2015 at 06:51:26PM -0400, Andy Walls wrote:
Sorry for the top post; mobile work email account.
Luis,
You do the changes to remove MTTR and point me to your dev repo and branch.
Also point me to the new functions/primitives I'll need.
There is nothing new actually needed
On Wed, Apr 15, 2015 at 09:07:37PM -0400, Andy Walls wrote:
On Thu, 2015-04-16 at 01:58 +0200, Luis R. Rodriguez wrote:
Hey Andy, thanks for your review, adding Hyong-Youb Kim for review of the
full range ioremap_wc() idea below.
On Wed, Apr 15, 2015 at 06:38:51PM -0400, Andy Walls
On Thu, Apr 16, 2015 at 08:54:26PM +0200, Luis R. Rodriguez wrote:
Without WC, descriptors would end up as multiple 4B or 8B MWr packets
to the NIC, which has a pretty big performance impact on this
particular NIC.
How big are the descriptors?
Some are 64B (a batch of eight 8B
On Thu, Apr 16, 2015 at 01:18:37PM +0900, Hyong-Youb Kim wrote:
On Thu, Apr 16, 2015 at 01:58:16AM +0200, Luis R. Rodriguez wrote:
An alternative... is to just ioremap_wc() the entire region, including
MMIO registers for these old devices. I see one ethernet driver that does
this,
On Apr 15, 2015 6:54 PM, Andy Walls awa...@md.metrocast.net wrote:
On Wed, 2015-04-15 at 17:58 -0700, Andy Lutomirski wrote:
On Wed, Apr 15, 2015 at 4:59 PM, Andy Walls awa...@md.metrocast.net wrote:
On Wed, 2015-04-15 at 16:42 -0700, Andy Lutomirski wrote:
On Wed, Apr 15, 2015 at 3:38
On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez mcg...@suse.com wrote:
c) ivtv: the driver does not have the PCI space mapped out separately, and
in fact it actually does not do the math for the framebuffer, instead it lets
the device's own CPU do that and assume where its at, see
On 04/15/2015 01:42 PM, Andy Lutomirski wrote:
I disagree. We should try to NACK any new code that can't function
without MTRRs.
(Plus, ARM is growing in popularity in the server space, and ARM quite
sensibly doesn't have MTRRs.)
NOT SPEAKING FOR INTEL HERE
Yes. People need to
On Wed, Apr 15, 2015 at 3:50 PM, Andy Walls awa...@md.metrocast.net wrote:
On Wed, 2015-04-15 at 13:42 -0700, Andy Lutomirski wrote:
On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez mcg...@suse.com wrote:
c) ivtv: the driver does not have the PCI space mapped out separately, and
in fact
Hi All,
On Mon, 2015-04-13 at 19:49 +0200, Luis R. Rodriguez wrote:
[snip]
I only saw a few drivers using overlapping ioremap*()
calls though on my MTRR review and they are all old devices so likely mostly
used on non-PAT systems, but there might be other corner cases elsewhere.
Lets
On Wed, 2015-04-15 at 13:42 -0700, Andy Lutomirski wrote:
On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez mcg...@suse.com wrote:
c) ivtv: the driver does not have the PCI space mapped out separately, and
in fact it actually does not do the math for the framebuffer, instead it
lets
On Wed, Apr 15, 2015 at 3:38 PM, Andy Walls awa...@md.metrocast.net wrote:
Hi All,
On Mon, 2015-04-13 at 19:49 +0200, Luis R. Rodriguez wrote:
[snip]
I only saw a few drivers using overlapping ioremap*()
calls though on my MTRR review and they are all old devices so likely mostly
used on
Hey Andy, thanks for your review, adding Hyong-Youb Kim for review of the
full range ioremap_wc() idea below.
On Wed, Apr 15, 2015 at 06:38:51PM -0400, Andy Walls wrote:
Hi All,
On Mon, 2015-04-13 at 19:49 +0200, Luis R. Rodriguez wrote:
From the beginning it seems only framebuffer
On Wed, Apr 15, 2015 at 01:42:47PM -0700, Andy Lutomirski wrote:
On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez mcg...@suse.com wrote:
c) ivtv: the driver does not have the PCI space mapped out separately, and
in fact it actually does not do the math for the framebuffer, instead it
On Thu, Apr 16, 2015 at 01:58:16AM +0200, Luis R. Rodriguez wrote:
An alternative... is to just ioremap_wc() the entire region, including
MMIO registers for these old devices. I see one ethernet driver that does
this, myri10ge, and am curious how and why they ended up deciding this
and if
On Thu, 2015-04-16 at 01:58 +0200, Luis R. Rodriguez wrote:
Hey Andy, thanks for your review, adding Hyong-Youb Kim for review of the
full range ioremap_wc() idea below.
On Wed, Apr 15, 2015 at 06:38:51PM -0400, Andy Walls wrote:
Hi All,
On Mon, 2015-04-13 at 19:49 +0200, Luis R.
On Wed, Apr 15, 2015 at 4:59 PM, Andy Walls awa...@md.metrocast.net wrote:
On Wed, 2015-04-15 at 16:42 -0700, Andy Lutomirski wrote:
On Wed, Apr 15, 2015 at 3:38 PM, Andy Walls awa...@md.metrocast.net wrote:
IMO the right solution would be to avoid ioremapping the whole bar at
startup.
On Wed, 2015-04-15 at 16:52 -0700, Andy Lutomirski wrote:
On Wed, Apr 15, 2015 at 3:50 PM, Andy Walls awa...@md.metrocast.net wrote:
On Wed, 2015-04-15 at 13:42 -0700, Andy Lutomirski wrote:
On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez mcg...@suse.com
wrote:
c) ivtv: the driver
On Wed, 2015-04-15 at 17:58 -0700, Andy Lutomirski wrote:
On Wed, Apr 15, 2015 at 4:59 PM, Andy Walls awa...@md.metrocast.net wrote:
On Wed, 2015-04-15 at 16:42 -0700, Andy Lutomirski wrote:
On Wed, Apr 15, 2015 at 3:38 PM, Andy Walls awa...@md.metrocast.net
wrote:
IMO the right
On Wed, 2015-04-15 at 16:42 -0700, Andy Lutomirski wrote:
On Wed, Apr 15, 2015 at 3:38 PM, Andy Walls awa...@md.metrocast.net wrote:
IMO the right solution would be to avoid ioremapping the whole bar at
startup. Instead ioremap pieces once the driver learns what they are.
This wouldn't
Cc'ing a few others as we ended up talking about the cruxes of my
unposted v2 series as I confirmed that set_memor_wc() would not work
as an alternative to my originally proposed __arch_phys_wc_add() to
force MTRR as a last resort on a few set of last remaining drivers.
This also discusses
40 matches
Mail list logo
