On Wed, 2017-06-07 at 11:39 -0700, Wesley Terpstra wrote:
> It was a while ago that I debugged this. I already reported this bug
> to Benjamin Herrenschmidt (now in CC), and I believe he has a patch of
> his own to fix the same issue.
>
> As I understand it, of_core_init sets up
On Wed, 2017-06-07 at 11:39 -0700, Wesley Terpstra wrote:
> It was a while ago that I debugged this. I already reported this bug
> to Benjamin Herrenschmidt (now in CC), and I believe he has a patch of
> his own to fix the same issue.
>
> As I understand it, of_core_init sets up
On Wed, 2017-06-07 at 07:45 +0200, Greg Kroah-Hartman wrote:
> On Wed, Jun 07, 2017 at 09:04:41AM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2017-06-06 at 21:30 +0200, Greg Kroah-Hartman wrote:
> > > >
> > > > static struct device_attribute vio_dev_att
On Wed, 2017-06-07 at 07:45 +0200, Greg Kroah-Hartman wrote:
> On Wed, Jun 07, 2017 at 09:04:41AM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2017-06-06 at 21:30 +0200, Greg Kroah-Hartman wrote:
> > > >
> > > > static struct device_attribute vio_dev_att
On Tue, 2017-06-06 at 21:30 +0200, Greg Kroah-Hartman wrote:
> >
> > static struct device_attribute vio_dev_attrs[] = {
> > __ATTR_RO(name),
> > @@ -1573,6 +1576,13 @@ static struct device_attribute vio_dev_attrs[] = {
> > __ATTR_RO(modalias),
> > __ATTR_NULL
> > };
> >
On Tue, 2017-06-06 at 21:30 +0200, Greg Kroah-Hartman wrote:
> >
> > static struct device_attribute vio_dev_attrs[] = {
> > __ATTR_RO(name),
> > @@ -1573,6 +1576,13 @@ static struct device_attribute vio_dev_attrs[] = {
> > __ATTR_RO(modalias),
> > __ATTR_NULL
> > };
> >
On Mon, 2017-06-05 at 20:21 +1000, Michael Ellerman wrote:
> On Thu, 2017-03-16 at 08:55:45 UTC, Christophe Leroy wrote:
> > It often happens to have simultaneous interrupts, for instance
> > when having double Ethernet attachment. With the current
> > implementation, we suffer the cost of kernel
On Mon, 2017-06-05 at 20:21 +1000, Michael Ellerman wrote:
> On Thu, 2017-03-16 at 08:55:45 UTC, Christophe Leroy wrote:
> > It often happens to have simultaneous interrupts, for instance
> > when having double Ethernet attachment. With the current
> > implementation, we suffer the cost of kernel
On Fri, 2017-06-02 at 11:39 +0200, Christophe LEROY wrote:
> The difference between get_user() and __get_user() is that get_user()
> performs an access_ok() in addition.
>
> Doesn't access_ok() only checks whether addr is below TASK_SIZE to
> ensure it is a valid user address ?
Do you have a
On Fri, 2017-06-02 at 11:39 +0200, Christophe LEROY wrote:
> The difference between get_user() and __get_user() is that get_user()
> performs an access_ok() in addition.
>
> Doesn't access_ok() only checks whether addr is below TASK_SIZE to
> ensure it is a valid user address ?
Do you have a
On Fri, 2017-06-02 at 01:46 -0700, Brendan Higgins wrote:
> Added slave support for Aspeed I2C controller. Supports fourteen busses
> present in AST24XX and AST25XX BMC SoCs by Aspeed.
(Not an issue for merging)
Have you looked at a "mode" by which you implement just enough of the
slave support
On Fri, 2017-06-02 at 01:46 -0700, Brendan Higgins wrote:
> Added slave support for Aspeed I2C controller. Supports fourteen busses
> present in AST24XX and AST25XX BMC SoCs by Aspeed.
(Not an issue for merging)
Have you looked at a "mode" by which you implement just enough of the
slave support
On Fri, 2017-06-02 at 02:29 -0700, Brendan Higgins wrote:
> > That way you avoid the above lock which is racy, slave activity could
> > get in there and trigger an error interrupt clobbering cmd_err for
> > example no ? Or am I missing something...
>
> The slave handler does not touch these
On Fri, 2017-06-02 at 02:29 -0700, Brendan Higgins wrote:
> > That way you avoid the above lock which is racy, slave activity could
> > get in there and trigger an error interrupt clobbering cmd_err for
> > example no ? Or am I missing something...
>
> The slave handler does not touch these
On Fri, 2017-06-02 at 01:46 -0700, Brendan Higgins wrote:
> Added initial master support for Aspeed I2C controller. Supports
> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>
> Signed-off-by: Brendan Higgins <brendanhigg...@google.com>
Reviewed-by: Benjami
On Fri, 2017-06-02 at 01:46 -0700, Brendan Higgins wrote:
> Added initial master support for Aspeed I2C controller. Supports
> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>
> Signed-off-by: Brendan Higgins
Reviewed-by: Benjamin Herrenschmidt
---
On Wed, 2017-05-24 at 23:49 -0700, Brendan Higgins wrote:
> Added initial master support for Aspeed I2C controller. Supports
> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
Hi Brendan !
It's getting there :-) I have a few comments mostly about some corner
cases below.
On Wed, 2017-05-24 at 23:49 -0700, Brendan Higgins wrote:
> Added initial master support for Aspeed I2C controller. Supports
> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
Hi Brendan !
It's getting there :-) I have a few comments mostly about some corner
cases below.
On Tue, 2017-05-23 at 14:55 +0200, Arnd Bergmann wrote:
> > +
> > +#include
>
> I would recommend providing your own {read,write}{b,w,l,q}{,_relaxed}
> helpers using inline assembly, to prevent the compiler for breaking
> up accesses into byte accesses.
>
> Also, most architectures require to
On Tue, 2017-05-23 at 14:55 +0200, Arnd Bergmann wrote:
> > +
> > +#include
>
> I would recommend providing your own {read,write}{b,w,l,q}{,_relaxed}
> helpers using inline assembly, to prevent the compiler for breaking
> up accesses into byte accesses.
>
> Also, most architectures require to
On Mon, 2017-05-22 at 22:16 -0700, Olof Johansson wrote:
> The same is true for some other drivers. Actually, I wonder if it
> might be just as easy to implement a sbi backend for hvc -- see
> hvc_udbg.c for an example where, on power, you have a simple get/put
> char hypervisor call in a very
On Mon, 2017-05-22 at 22:16 -0700, Olof Johansson wrote:
> The same is true for some other drivers. Actually, I wonder if it
> might be just as easy to implement a sbi backend for hvc -- see
> hvc_udbg.c for an example where, on power, you have a simple get/put
> char hypervisor call in a very
On Mon, 2017-05-22 at 12:06 -0700, John Stultz wrote:
> So, long ago I talked w/ Paul Mackerras about the ppc vdso code, as
> ppc has some other legacy "userspace time" code that has to be
> maintained as well (I believe there's not code page, just data page
> that userspace pulls directly from).
On Mon, 2017-05-22 at 12:06 -0700, John Stultz wrote:
> So, long ago I talked w/ Paul Mackerras about the ppc vdso code, as
> ppc has some other legacy "userspace time" code that has to be
> maintained as well (I believe there's not code page, just data page
> that userspace pulls directly from).
On Mon, 2017-05-15 at 16:07 +0300, Ivan Mikhaylov wrote:
> +#ifdef CONFIG_FSP2
> + /*
> + * Prevent a kernel panic caused by unintentionally clearing TCR
> + * watchdog bits. At this point in the kernel boot, the watchdog has
> + * already been enabled by u-boot. The
On Mon, 2017-05-15 at 16:07 +0300, Ivan Mikhaylov wrote:
> +#ifdef CONFIG_FSP2
> + /*
> + * Prevent a kernel panic caused by unintentionally clearing TCR
> + * watchdog bits. At this point in the kernel boot, the watchdog has
> + * already been enabled by u-boot. The
On Fri, 2017-05-12 at 13:37 -0400, David Miller wrote:
> > Right now it is larger, but what I suggested is to add a new optimized
> > routine just for this case, which would do STBI for 64-bytes but
> > without membar (do membar at the end of memmap_init_zone() and
> > deferred_init_memmap()
> >
On Fri, 2017-05-12 at 13:37 -0400, David Miller wrote:
> > Right now it is larger, but what I suggested is to add a new optimized
> > routine just for this case, which would do STBI for 64-bytes but
> > without membar (do membar at the end of memmap_init_zone() and
> > deferred_init_memmap()
> >
On Mon, 2017-05-08 at 16:28 -0700, Brendan Higgins wrote:
>
> I am curious what everyone thinks about this. It seemed that, earlier
> on, people did not like me disabling multi-master mode, but I think
> that it would make bus recovery not work as well. Given that, I think
> it makes the most
On Mon, 2017-05-08 at 16:28 -0700, Brendan Higgins wrote:
>
> I am curious what everyone thinks about this. It seemed that, earlier
> on, people did not like me disabling multi-master mode, but I think
> that it would make bus recovery not work as well. Given that, I think
> it makes the most
On Sat, 2017-05-06 at 01:50 +0300, Alexey Khoroshilov wrote:
> Could you please clarify if iounmap(NULL) safe or not.
> I guess it would be less errorprone if the answer is architecture independent.
I think it's supposed to be and we should fix ppc.
Cheers,
Ben.
On Sat, 2017-05-06 at 01:50 +0300, Alexey Khoroshilov wrote:
> Could you please clarify if iounmap(NULL) safe or not.
> I guess it would be less errorprone if the answer is architecture independent.
I think it's supposed to be and we should fix ppc.
Cheers,
Ben.
On Fri, 2017-05-05 at 15:52 +0200, Michal Suchánek wrote:
>
> So you have an e-mail message from one of the authors of the code.
> Andy Polyakov wrote most of the code but there are probably other
> contributors who never gave explicit consent for using their code
> outside of OpenSSL.
The only
On Fri, 2017-05-05 at 15:52 +0200, Michal Suchánek wrote:
>
> So you have an e-mail message from one of the authors of the code.
> Andy Polyakov wrote most of the code but there are probably other
> contributors who never gave explicit consent for using their code
> outside of OpenSSL.
The only
e, as the host may be using this
> bit to configure serial output modes, which is independent of whether
> the devices has been opened by BMC userspace.
>
> Signed-off-by: Jeremy Kerr <j...@ozlabs.org>
> Signed-off-by: Joel Stanley <j...@jms.id.au>
> Acked-by: Rob Herring
using this
> bit to configure serial output modes, which is independent of whether
> the devices has been opened by BMC userspace.
>
> Signed-off-by: Jeremy Kerr
> Signed-off-by: Joel Stanley
> Acked-by: Rob Herring
Reviewed-by: Benjamin Herrenschmidt
> ---
> v4:
&g
fy the sender by reply e-mail and immediately
> delete the e-mail and any attachments without copying or disclosing
> the contents. Thank you.
>
>
> -----Original Message-
> From: Brendan Higgins [mailto:brendanhigg...@google.com]
> Sent: Tuesday, April 25, 2017 4:32 PM
> To: B
fy the sender by reply e-mail and immediately
> delete the e-mail and any attachments without copying or disclosing
> the contents. Thank you.
>
>
> -----Original Message-
> From: Brendan Higgins [mailto:brendanhigg...@google.com]
> Sent: Tuesday, April 25, 2017 4:32 PM
&g
On Mon, 2017-04-24 at 11:18 -0700, Brendan Higgins wrote:
> +static int __aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus,
> + struct platform_device *pdev)
> +{
Minor nit ... I'm really not fan of those underscores.
We use __ functions in some cases in the kernel
On Mon, 2017-04-24 at 11:18 -0700, Brendan Higgins wrote:
> +static int __aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus,
> + struct platform_device *pdev)
> +{
Minor nit ... I'm really not fan of those underscores.
We use __ functions in some cases in the kernel
On Mon, 2017-04-24 at 11:56 -0700, Brendan Higgins wrote:
> > > +struct aspeed_i2c_bus {
> > > + struct i2c_adapter adap;
> > > + struct device *dev;
> > > + void __iomem*base;
> > > + /* Synchronizes I/O mem access to base. */
> >
On Mon, 2017-04-24 at 11:56 -0700, Brendan Higgins wrote:
> > > +struct aspeed_i2c_bus {
> > > + struct i2c_adapter adap;
> > > + struct device *dev;
> > > + void __iomem*base;
> > > + /* Synchronizes I/O mem access to base. */
> >
On Mon, 2017-04-24 at 10:25 -0700, Sukadev Bhattiprolu wrote:
> which maybe due to this :-) Should I change to pgprot_noncached() for
> the MMIO writes?
Just use normal ioremap().
> > requires being mapped cachable. Ask Aneesh for a cleaner way of
> > doing it too while at it.
On Mon, 2017-04-24 at 10:25 -0700, Sukadev Bhattiprolu wrote:
> which maybe due to this :-) Should I change to pgprot_noncached() for
> the MMIO writes?
Just use normal ioremap().
> > requires being mapped cachable. Ask Aneesh for a cleaner way of
> > doing it too while at it.
On Thu, 2017-03-30 at 22:13 -0700, Sukadev Bhattiprolu wrote:
> +static void *map_mmio_region(char *name, uint64_t start, int len)
> +{
> + void *map;
> +
> + if (!request_mem_region(start, len, name)) {
> + pr_devel("%s(): request_mem_region(0x%llx, %d) failed\n",
> +
On Thu, 2017-03-30 at 22:13 -0700, Sukadev Bhattiprolu wrote:
> +static void *map_mmio_region(char *name, uint64_t start, int len)
> +{
> + void *map;
> +
> + if (!request_mem_region(start, len, name)) {
> + pr_devel("%s(): request_mem_region(0x%llx, %d) failed\n",
> +
On Thu, 2017-03-30 at 22:13 -0700, Sukadev Bhattiprolu wrote:
>
> + p = of_get_property(dn, "vas-id", NULL);
> + if (!p) {
> + pr_err("VAS: NULL vas-id? %p\n", p);
> + return -ENODEV;
> + }
> +
> + vinst->vas_id = of_read_number(p, 1);
On Thu, 2017-03-30 at 22:13 -0700, Sukadev Bhattiprolu wrote:
>
> + p = of_get_property(dn, "vas-id", NULL);
> + if (!p) {
> + pr_err("VAS: NULL vas-id? %p\n", p);
> + return -ENODEV;
> + }
> +
> + vinst->vas_id = of_read_number(p, 1);
On Thu, 2017-03-30 at 22:13 -0700, Sukadev Bhattiprolu wrote:
> +config VAS
> + tristate "IBM Virtual Accelerator Switchboard (VAS)"
CONFIG_IBM_VAS or PPC_VAS ... too high risk of collision otherwise
Ben.
On Thu, 2017-03-30 at 22:13 -0700, Sukadev Bhattiprolu wrote:
> +config VAS
> + tristate "IBM Virtual Accelerator Switchboard (VAS)"
CONFIG_IBM_VAS or PPC_VAS ... too high risk of collision otherwise
Ben.
On Tue, 2017-04-18 at 16:24 -0600, Jason Gunthorpe wrote:
> Basically, all this list processing is a huge overhead compared to
> just putting a helper call in the existing sg iteration loop of the
> actual op. Particularly if the actual op is a no-op like no-mmu x86
> would use.
Yes, I'm leaning
On Tue, 2017-04-18 at 16:24 -0600, Jason Gunthorpe wrote:
> Basically, all this list processing is a huge overhead compared to
> just putting a helper call in the existing sg iteration loop of the
> actual op. Particularly if the actual op is a no-op like no-mmu x86
> would use.
Yes, I'm leaning
On Tue, 2017-04-18 at 17:21 -0600, Jason Gunthorpe wrote:
> Splitting the sgl is different from iommu batching.
>
> As an example, an O_DIRECT write of 1 MB with a single 4K P2P page in
> the middle.
>
> The optimum behavior is to allocate a 1MB-4K iommu range and fill it
> with the CPU memory.
On Tue, 2017-04-18 at 17:21 -0600, Jason Gunthorpe wrote:
> Splitting the sgl is different from iommu batching.
>
> As an example, an O_DIRECT write of 1 MB with a single 4K P2P page in
> the middle.
>
> The optimum behavior is to allocate a 1MB-4K iommu range and fill it
> with the CPU memory.
On Tue, 2017-04-18 at 15:22 -0600, Jason Gunthorpe wrote:
> On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote:
> > > I think this opens an even bigger can of worms..
> >
> > No, I don't think it does. You'd only shim when the target page is
> > backed by a device, not host memory, and
On Tue, 2017-04-18 at 15:22 -0600, Jason Gunthorpe wrote:
> On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote:
> > > I think this opens an even bigger can of worms..
> >
> > No, I don't think it does. You'd only shim when the target page is
> > backed by a device, not host memory, and
On Tue, 2017-04-18 at 15:03 -0600, Jason Gunthorpe wrote:
> I don't follow, when does get_dma_ops() return a p2p aware provider?
> It has no way to know if the DMA is going to involve p2p, get_dma_ops
> is called with the device initiating the DMA.
>
> So you'd always return the P2P shim on a
On Tue, 2017-04-18 at 15:03 -0600, Jason Gunthorpe wrote:
> I don't follow, when does get_dma_ops() return a p2p aware provider?
> It has no way to know if the DMA is going to involve p2p, get_dma_ops
> is called with the device initiating the DMA.
>
> So you'd always return the P2P shim on a
On Tue, 2017-04-18 at 14:48 -0600, Logan Gunthorpe wrote:
> > ...and that dma_map goes through get_dma_ops(), so I don't see the conflict?
>
> The main conflict is in dma_map_sg which only does get_dma_ops once but
> the sg may contain memory of different types.
We can handle that in our
On Tue, 2017-04-18 at 14:48 -0600, Logan Gunthorpe wrote:
> > ...and that dma_map goes through get_dma_ops(), so I don't see the conflict?
>
> The main conflict is in dma_map_sg which only does get_dma_ops once but
> the sg may contain memory of different types.
We can handle that in our
On Tue, 2017-04-18 at 12:00 -0600, Jason Gunthorpe wrote:
> - All platforms can succeed if the PCI devices are under the same
> 'segment', but where segments begin is somewhat platform specific
> knowledge. (this is 'same switch' idea Logan has talked about)
We also need to be careful whether
On Tue, 2017-04-18 at 12:00 -0600, Jason Gunthorpe wrote:
> - All platforms can succeed if the PCI devices are under the same
> 'segment', but where segments begin is somewhat platform specific
> knowledge. (this is 'same switch' idea Logan has talked about)
We also need to be careful whether
On Tue, 2017-04-18 at 10:27 -0700, Dan Williams wrote:
> > FWIW, RDMA probably wouldn't want to use a p2mem device either, we
> > already have APIs that map BAR memory to user space, and would like to
> > keep using them. A 'enable P2P for bar' helper function sounds better
> > to me.
>
> ...and
On Tue, 2017-04-18 at 10:27 -0700, Dan Williams wrote:
> > FWIW, RDMA probably wouldn't want to use a p2mem device either, we
> > already have APIs that map BAR memory to user space, and would like to
> > keep using them. A 'enable P2P for bar' helper function sounds better
> > to me.
>
> ...and
On Mon, 2017-04-17 at 23:43 -0600, Logan Gunthorpe wrote:
>
> On 17/04/17 03:11 PM, Benjamin Herrenschmidt wrote:
> > Is it ? Again, you create a "concept" the user may have no idea about,
> > "p2pmem memory". So now any kind of memory buffer on a device
On Mon, 2017-04-17 at 23:43 -0600, Logan Gunthorpe wrote:
>
> On 17/04/17 03:11 PM, Benjamin Herrenschmidt wrote:
> > Is it ? Again, you create a "concept" the user may have no idea about,
> > "p2pmem memory". So now any kind of memory buffer on a device
On Mon, 2017-04-17 at 10:52 -0600, Logan Gunthorpe wrote:
>
> On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote:
> > But is it ? For example take a GPU, does it, in your scheme, need an
> > additional "p2pmem" child ? Why can't the GPU driver just use some
> > h
On Mon, 2017-04-17 at 10:52 -0600, Logan Gunthorpe wrote:
>
> On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote:
> > But is it ? For example take a GPU, does it, in your scheme, need an
> > additional "p2pmem" child ? Why can't the GPU driver just use some
> > h
On Sun, 2017-04-16 at 23:13 -0600, Logan Gunthorpe wrote:
>
> >
> > I'm still not 100% why do you need a "p2mem device" mind you ...
>
> Well, you don't "need" it but it is a design choice that I think makes a
> lot of sense for the following reasons:
>
> 1) p2pmem is in fact a device on the
On Sun, 2017-04-16 at 23:13 -0600, Logan Gunthorpe wrote:
>
> >
> > I'm still not 100% why do you need a "p2mem device" mind you ...
>
> Well, you don't "need" it but it is a design choice that I think makes a
> lot of sense for the following reasons:
>
> 1) p2pmem is in fact a device on the
On Sun, 2017-04-16 at 10:34 -0600, Logan Gunthorpe wrote:
>
> On 16/04/17 09:53 AM, Dan Williams wrote:
> > ZONE_DEVICE allows you to redirect via get_dev_pagemap() to retrieve
> > context about the physical address in question. I'm thinking you can
> > hang bus address translation data off of
On Sun, 2017-04-16 at 10:34 -0600, Logan Gunthorpe wrote:
>
> On 16/04/17 09:53 AM, Dan Williams wrote:
> > ZONE_DEVICE allows you to redirect via get_dev_pagemap() to retrieve
> > context about the physical address in question. I'm thinking you can
> > hang bus address translation data off of
On Sun, 2017-04-16 at 10:47 -0600, Logan Gunthorpe wrote:
> > I think you need to give other archs a chance to support this with a
> > design that considers the offset case as a first class citizen rather
> > than an afterthought.
>
> I'll consider this. Given the fact I can use your existing
>
On Sun, 2017-04-16 at 10:47 -0600, Logan Gunthorpe wrote:
> > I think you need to give other archs a chance to support this with a
> > design that considers the offset case as a first class citizen rather
> > than an afterthought.
>
> I'll consider this. Given the fact I can use your existing
>
On Sun, 2017-04-16 at 08:53 -0700, Dan Williams wrote:
> > Just thinking out loud ... I don't have a firm idea or a design. But
> > peer to peer is definitely a problem we need to tackle generically, the
> > demand for it keeps coming up.
>
> ZONE_DEVICE allows you to redirect via
On Sun, 2017-04-16 at 08:53 -0700, Dan Williams wrote:
> > Just thinking out loud ... I don't have a firm idea or a design. But
> > peer to peer is definitely a problem we need to tackle generically, the
> > demand for it keeps coming up.
>
> ZONE_DEVICE allows you to redirect via
On Sun, 2017-04-16 at 08:44 -0700, Dan Williams wrote:
> The difference is that there was nothing fundamental in the core
> design of pmem + DAX that prevented other archs from growing pmem
> support.
Indeed. In fact we have work in progress support for pmem on power
using experimental HW.
> THP
On Sun, 2017-04-16 at 08:44 -0700, Dan Williams wrote:
> The difference is that there was nothing fundamental in the core
> design of pmem + DAX that prevented other archs from growing pmem
> support.
Indeed. In fact we have work in progress support for pmem on power
using experimental HW.
> THP
On Sat, 2017-04-15 at 15:09 -0700, Dan Williams wrote:
> I'm wondering, since this is limited to support behind a single
> switch, if you could have a software-iommu hanging off that switch
> device object that knows how to catch and translate the non-zero
> offset bus address case. We have
On Sat, 2017-04-15 at 15:09 -0700, Dan Williams wrote:
> I'm wondering, since this is limited to support behind a single
> switch, if you could have a software-iommu hanging off that switch
> device object that knows how to catch and translate the non-zero
> offset bus address case. We have
On Sat, 2017-04-15 at 11:41 -0600, Logan Gunthorpe wrote:
> Thanks, Benjamin, for the summary of some of the issues.
>
> On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote
> > So I assume the p2p code provides a way to address that too via special
> > dma_ops ? Or wrappers ?
On Sat, 2017-04-15 at 11:41 -0600, Logan Gunthorpe wrote:
> Thanks, Benjamin, for the summary of some of the issues.
>
> On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote
> > So I assume the p2p code provides a way to address that too via special
> > dma_ops ? Or wrappers ?
On Fri, 2017-04-14 at 14:04 -0500, Bjorn Helgaas wrote:
> I'm a little hesitant about excluding offset support, so I'd like to
> hear more about this.
>
> Is the issue related to PCI BARs that are not completely addressable
> by the CPU? If so, that sounds like a first-class issue that should
>
On Fri, 2017-04-14 at 14:04 -0500, Bjorn Helgaas wrote:
> I'm a little hesitant about excluding offset support, so I'd like to
> hear more about this.
>
> Is the issue related to PCI BARs that are not completely addressable
> by the CPU? If so, that sounds like a first-class issue that should
>
On Thu, 2017-04-13 at 22:40 -0600, Logan Gunthorpe wrote:
>
> On 13/04/17 10:16 PM, Jason Gunthorpe wrote:
> > I'd suggest just detecting if there is any translation in bus
> > addresses anywhere and just hard disabling P2P on such systems.
>
> That's a fantastic suggestion. It simplifies things
On Thu, 2017-04-13 at 22:40 -0600, Logan Gunthorpe wrote:
>
> On 13/04/17 10:16 PM, Jason Gunthorpe wrote:
> > I'd suggest just detecting if there is any translation in bus
> > addresses anywhere and just hard disabling P2P on such systems.
>
> That's a fantastic suggestion. It simplifies things
On Fri, 2017-04-14 at 21:37 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2017-04-13 at 22:40 -0600, Logan Gunthorpe wrote:
> >
> > On 13/04/17 10:16 PM, Jason Gunthorpe wrote:
> > > I'd suggest just detecting if there is any translation in bus
> > > addresses
On Fri, 2017-04-14 at 21:37 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2017-04-13 at 22:40 -0600, Logan Gunthorpe wrote:
> >
> > On 13/04/17 10:16 PM, Jason Gunthorpe wrote:
> > > I'd suggest just detecting if there is any translation in bus
> > > addresses
On Thu, 2017-04-13 at 22:16 -0600, Jason Gunthorpe wrote:
> > Any caller of pci_add_resource_offset() uses CPU addresses different from
> > the PCI bus addresses (unless the offset is zero, of course). All ACPI
> > platforms also support this translation (see "translation_offset"), though
> > in
On Thu, 2017-04-13 at 22:16 -0600, Jason Gunthorpe wrote:
> > Any caller of pci_add_resource_offset() uses CPU addresses different from
> > the PCI bus addresses (unless the offset is zero, of course). All ACPI
> > platforms also support this translation (see "translation_offset"), though
> > in
On Thu, 2017-04-13 at 15:22 -0600, Logan Gunthorpe wrote:
>
> On 12/04/17 03:55 PM, Benjamin Herrenschmidt wrote:
> > Look at pcibios_resource_to_bus() and pcibios_bus_to_resource(). They
> > will perform the conversion between the struct resource content (CPU
> > physical
On Thu, 2017-04-13 at 15:22 -0600, Logan Gunthorpe wrote:
>
> On 12/04/17 03:55 PM, Benjamin Herrenschmidt wrote:
> > Look at pcibios_resource_to_bus() and pcibios_bus_to_resource(). They
> > will perform the conversion between the struct resource content (CPU
> > physical
On Thu, 2017-04-13 at 09:28 +0530, Aneesh Kumar K.V wrote:
> > #endif
> > mtctr r12
> > bctrl
> > +/*
> > + * cur_cpu_spec->cpu_restore would restore LPCR to a
> > + * sane value that is set at early boot time,
> > + * thereby clearing LPCR_UPRT.
> > + * LPCR_UPRT is required if
On Thu, 2017-04-13 at 09:28 +0530, Aneesh Kumar K.V wrote:
> > #endif
> > mtctr r12
> > bctrl
> > +/*
> > + * cur_cpu_spec->cpu_restore would restore LPCR to a
> > + * sane value that is set at early boot time,
> > + * thereby clearing LPCR_UPRT.
> > + * LPCR_UPRT is required if
On Wed, 2017-04-12 at 11:09 -0600, Logan Gunthorpe wrote:
>
> > Do you handle funky address translation too ? IE. the fact that the PCI
> > addresses aren't the same as the CPU physical addresses for a BAR ?
>
> No, we use the CPU physical address of the BAR. If it's not mapped that
> way we
On Wed, 2017-04-12 at 11:09 -0600, Logan Gunthorpe wrote:
>
> > Do you handle funky address translation too ? IE. the fact that the PCI
> > addresses aren't the same as the CPU physical addresses for a BAR ?
>
> No, we use the CPU physical address of the BAR. If it's not mapped that
> way we
On Thu, 2017-03-30 at 16:12 -0600, Logan Gunthorpe wrote:
> Hello,
>
> As discussed at LSF/MM we'd like to present our work to enable
> copy offload support in NVMe fabrics RDMA targets. We'd appreciate
> some review and feedback from the community on our direction.
> This series is not intended
On Thu, 2017-03-30 at 16:12 -0600, Logan Gunthorpe wrote:
> Hello,
>
> As discussed at LSF/MM we'd like to present our work to enable
> copy offload support in NVMe fabrics RDMA targets. We'd appreciate
> some review and feedback from the community on our direction.
> This series is not intended
On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote:
> Ok, point taken. BTW, may I ask you guys to have a look into this
> please ?
>
> https://lkml.org/lkml/2017/4/6/743
>
> It is a side effect of this thread (v2), not sure why
> on powerpc has to include .
Not sure how we ended up
On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote:
> Ok, point taken. BTW, may I ask you guys to have a look into this
> please ?
>
> https://lkml.org/lkml/2017/4/6/743
>
> It is a side effect of this thread (v2), not sure why
> on powerpc has to include .
Not sure how we ended up
801 - 900 of 5350 matches
Mail list logo