All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: "Luis R. Rodriguez" <mcgrof@suse.com>, bhelgaas@google.com
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	bp@suse.de, arnd@arndb.de, bhelgaas@google.com,
	luto@amacapital.net, akpm@linux-foundation.org,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	tomi.valkeinen@ti.com, mst@redhat.com, toshi.kani@hp.com,
	linux-fbdev@vger.kernel.org, xen-devel@lists.xensource.com,
	benh@kernel.crashing.org
Subject: Re: [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
Date: Tue, 21 Jul 2015 10:52:52 +0200	[thread overview]
Message-ID: <20150721085252.GA15861@gmail.com> (raw)
In-Reply-To: <20150717202923.GC30479@wotan.suse.de>


* Luis R. Rodriguez <mcgrof@suse.com> wrote:

> On Wed, Jul 08, 2015 at 06:54:11PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > 
> > Ingo,
> > 
> > Boris is on vacation, he picked up these patches on his bp#tip-mm tree [0]
> > and they have baked there for a while now. That tree receives 0-day
> > bot testing, but other than that its not clear what other tests were
> > run on these patches. Boris modified the commit logs a bit, and made one
> > optimizaiton to bail early on an PCI ioremap call when it should. These
> > patches have no modifications from what is on Boris' tree and tip-mm branch.
> > 
> > The 0 day build bot did find issues on Boris' tree but those are related
> > to ioremap_uc() (already upstream) and its first use on atyfb (not
> > upstream) -- I will be addressing a fix for that ioremap_uc() issue through
> > another patch series prior to posting the final set for atyfb which makes
> > use of ioremap_uc().
> > 
> > No issues have been found with this series. Benh did note some possible issues
> > with expectations with what is done for write-combining for PowerPC [1] but
> > the issue is a rather general long standing issue with semantics of ioremap --
> > in the case for ioremap_wc() on PowerPC benh notes that writel() will never
> > write-combine as it uses too heavy barriers. Benh notes that although
> > writel_relaxed() today is identical to writel() this can be changed. There are
> > other general semantics issues with ioremap() variant calls -- we seem to have
> > all gotten together to discuss all these issues on a thread where Dan Williams
> > is proposing to "unify ioremap prototypes and macro aliases" [1], folks
> > intersted on these issues or semantic concerns can drop in and chime there.
> > 
> > Let me know if these are OK or if there are any questions.
> > 
> > [0] http://lkml.kernel.org/r/20150625204703.GC4898@pd.tnic
> > [1] http://lkml.kernel.org/r/20150707095012.GQ7021@wotan.suse.de
> 
> Ingo,
> 
> Just a friendly reminder. Let me know if there are any issues or questions.

It would be nice to get an Acked-by from Bjorn for the PCI API bits.

Thanks,

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: "Luis R. Rodriguez" <mcgrof@suse.com>, bhelgaas@google.com
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	bp@suse.de, arnd@arndb.de, luto@amacapital.net,
	akpm@linux-foundation.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, tomi.valkeinen@ti.com,
	mst@redhat.com, toshi.kani@hp.com, linux-fbdev@vger.kernel.org,
	xen-devel@lists.xensource.com, benh@kernel.crashing.org
Subject: Re: [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
Date: Tue, 21 Jul 2015 08:52:52 +0000	[thread overview]
Message-ID: <20150721085252.GA15861@gmail.com> (raw)
In-Reply-To: <20150717202923.GC30479@wotan.suse.de>


* Luis R. Rodriguez <mcgrof@suse.com> wrote:

> On Wed, Jul 08, 2015 at 06:54:11PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > 
> > Ingo,
> > 
> > Boris is on vacation, he picked up these patches on his bp#tip-mm tree [0]
> > and they have baked there for a while now. That tree receives 0-day
> > bot testing, but other than that its not clear what other tests were
> > run on these patches. Boris modified the commit logs a bit, and made one
> > optimizaiton to bail early on an PCI ioremap call when it should. These
> > patches have no modifications from what is on Boris' tree and tip-mm branch.
> > 
> > The 0 day build bot did find issues on Boris' tree but those are related
> > to ioremap_uc() (already upstream) and its first use on atyfb (not
> > upstream) -- I will be addressing a fix for that ioremap_uc() issue through
> > another patch series prior to posting the final set for atyfb which makes
> > use of ioremap_uc().
> > 
> > No issues have been found with this series. Benh did note some possible issues
> > with expectations with what is done for write-combining for PowerPC [1] but
> > the issue is a rather general long standing issue with semantics of ioremap --
> > in the case for ioremap_wc() on PowerPC benh notes that writel() will never
> > write-combine as it uses too heavy barriers. Benh notes that although
> > writel_relaxed() today is identical to writel() this can be changed. There are
> > other general semantics issues with ioremap() variant calls -- we seem to have
> > all gotten together to discuss all these issues on a thread where Dan Williams
> > is proposing to "unify ioremap prototypes and macro aliases" [1], folks
> > intersted on these issues or semantic concerns can drop in and chime there.
> > 
> > Let me know if these are OK or if there are any questions.
> > 
> > [0] http://lkml.kernel.org/r/20150625204703.GC4898@pd.tnic
> > [1] http://lkml.kernel.org/r/20150707095012.GQ7021@wotan.suse.de
> 
> Ingo,
> 
> Just a friendly reminder. Let me know if there are any issues or questions.

It would be nice to get an Acked-by from Bjorn for the PCI API bits.

Thanks,

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	bp@suse.de, arnd@arndb.de, bhelgaas@google.com,
	luto@amacapital.net, akpm@linux-foundation.org,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	tomi.valkeinen@ti.com, mst@redhat.com, toshi.kani@hp.com,
	linux-fbdev@vger.kernel.org, xen-devel@lists.xensource.com,
	benh@kernel.crashing.org
Subject: Re: [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
Date: Tue, 21 Jul 2015 10:52:52 +0200	[thread overview]
Message-ID: <20150721085252.GA15861@gmail.com> (raw)
In-Reply-To: <20150717202923.GC30479@wotan.suse.de>


* Luis R. Rodriguez <mcgrof@suse.com> wrote:

> On Wed, Jul 08, 2015 at 06:54:11PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > 
> > Ingo,
> > 
> > Boris is on vacation, he picked up these patches on his bp#tip-mm tree [0]
> > and they have baked there for a while now. That tree receives 0-day
> > bot testing, but other than that its not clear what other tests were
> > run on these patches. Boris modified the commit logs a bit, and made one
> > optimizaiton to bail early on an PCI ioremap call when it should. These
> > patches have no modifications from what is on Boris' tree and tip-mm branch.
> > 
> > The 0 day build bot did find issues on Boris' tree but those are related
> > to ioremap_uc() (already upstream) and its first use on atyfb (not
> > upstream) -- I will be addressing a fix for that ioremap_uc() issue through
> > another patch series prior to posting the final set for atyfb which makes
> > use of ioremap_uc().
> > 
> > No issues have been found with this series. Benh did note some possible issues
> > with expectations with what is done for write-combining for PowerPC [1] but
> > the issue is a rather general long standing issue with semantics of ioremap --
> > in the case for ioremap_wc() on PowerPC benh notes that writel() will never
> > write-combine as it uses too heavy barriers. Benh notes that although
> > writel_relaxed() today is identical to writel() this can be changed. There are
> > other general semantics issues with ioremap() variant calls -- we seem to have
> > all gotten together to discuss all these issues on a thread where Dan Williams
> > is proposing to "unify ioremap prototypes and macro aliases" [1], folks
> > intersted on these issues or semantic concerns can drop in and chime there.
> > 
> > Let me know if these are OK or if there are any questions.
> > 
> > [0] http://lkml.kernel.org/r/20150625204703.GC4898@pd.tnic
> > [1] http://lkml.kernel.org/r/20150707095012.GQ7021@wotan.suse.de
> 
> Ingo,
> 
> Just a friendly reminder. Let me know if there are any issues or questions.

It would be nice to get an Acked-by from Bjorn for the PCI API bits.

Thanks,

	Ingo

  reply	other threads:[~2015-07-21  8:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-09  1:54 [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar() Luis R. Rodriguez
2015-07-09  1:54 ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 1/8] PCI: Add pci_ioremap_wc_bar() Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 2/8] drivers/video/fbdev/i740fb: Use arch_phys_wc_add() and pci_ioremap_wc_bar() Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 3/8] drivers/video/fbdev/kyrofb: " Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 4/8] drivers/video/fbdev/gxt4500: Use pci_ioremap_wc_bar() to map framebuffer Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 5/8] PCI: Add pci_iomap_wc() variants Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 6/8] drivers/video/fbdev/arkfb.c: Use arch_phys_wc_add() and pci_iomap_wc() Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 7/8] drivers/video/fbdev/s3fb: " Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 8/8] drivers/video/fbdev/vt8623fb: " Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-17 20:29 ` [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar() Luis R. Rodriguez
2015-07-17 20:29   ` Luis R. Rodriguez
2015-07-21  8:52   ` Ingo Molnar [this message]
2015-07-21  8:52     ` Ingo Molnar
2015-07-21  8:52     ` Ingo Molnar
2015-07-21 13:21     ` Bjorn Helgaas
2015-07-21 13:21       ` Bjorn Helgaas
2015-07-22  8:38       ` Ingo Molnar
2015-07-22  8:38         ` Ingo Molnar
2015-07-22 13:43         ` Bjorn Helgaas
2015-07-22 13:43           ` Bjorn Helgaas
2015-08-06 21:45           ` Luis R. Rodriguez
2015-08-06 21:45             ` Luis R. Rodriguez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150721085252.GA15861@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=bp@suse.de \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mcgrof@do-not-panic.com \
    --cc=mcgrof@suse.com \
    --cc=mst@redhat.com \
    --cc=tomi.valkeinen@ti.com \
    --cc=toshi.kani@hp.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.