On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
> No, as Timur found, the driver is correct and it intentionally
sets the 32-bit mask, and that is guaranteed to work on all sane
hardware. Don't change the driver but find a better platform for
your workload, or talk to the people that are
On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:
> On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
> > No, as Timur found, the driver is correct and it intentionally
> > sets the 32-bit mask, and that is guaranteed to work on all sane
> > hardware. Don't change the driver but find a better
On 11/10/2015 10:47 AM, Arnd Bergmann wrote:
What BenH was worried about here is that the driver sets different masks
for streaming and coherent mappings, which is indeed a worry that
could hit us on ARM as well, but I suppose we'll have to deal with
that in platform code.
Setting both masks to
On Tuesday 10 November 2015 11:00:59 Timur Tabi wrote:
> On 11/10/2015 10:47 AM, Arnd Bergmann wrote:
> > What BenH was worried about here is that the driver sets different masks
> > for streaming and coherent mappings, which is indeed a worry that
> > could hit us on ARM as well, but I suppose
On 11/10/2015 1:27 PM, James Bottomley wrote:
On Tue, 2015-11-10 at 12:19 -0500, Sinan Kaya wrote:
On 11/10/2015 11:47 AM, Arnd Bergmann wrote:
On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:
On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
From the email thread, it looks like this was
On Tue, 2015-11-10 at 12:19 -0500, Sinan Kaya wrote:
> On 11/10/2015 11:47 AM, Arnd Bergmann wrote:
> > On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:
> >> On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
> >> From the email thread, it looks like this was introduced to support
> >> some
On 11/10/2015 11:47 AM, Arnd Bergmann wrote:
On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:
On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
> No, as Timur found, the driver is correct and it intentionally
sets the 32-bit mask, and that is guaranteed to work on all sane
hardware. Don't
On Tue, 2015-11-10 at 14:14 -0500, Sinan Kaya wrote:
>
> On 11/10/2015 1:27 PM, James Bottomley wrote:
> > On Tue, 2015-11-10 at 12:19 -0500, Sinan Kaya wrote:
> >> On 11/10/2015 11:47 AM, Arnd Bergmann wrote:
> >>> On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:
> On 11/10/2015 3:38
On Tue, 2015-11-10 at 14:56 -0500, Sinan Kaya wrote:
>
> On 11/10/2015 2:43 PM, James Bottomley wrote:
> > The Issue, as stated by LSI is
> >
> > Initially set the consistent DMA mask to 32 bit and then change
> > it
> > to 64 bit mask after allocating RDPQ pools by
On 11/10/2015 3:05 PM, James Bottomley wrote:
OK, you don't seem to be understanding the problem: the Altix isn't a
LSI card, it was a SGI platform.
Got it.
It was the platform where we first
discovered the issue that a lot of storage cards didn't work because it
by default had no memory
On 11/10/2015 2:43 PM, James Bottomley wrote:
The Issue, as stated by LSI is
Initially set the consistent DMA mask to 32 bit and then change
it
to 64 bit mask after allocating RDPQ pools by calling the
function
_base_change_consistent_dma_mask.
On Tuesday 10 November 2015 12:19:33 Sinan Kaya wrote:
> On 11/10/2015 11:47 AM, Arnd Bergmann wrote:
> > On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:
> >> On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
> >> > No, as Timur found, the driver is correct and it intentionally
> >>> sets the
On Tue, 2015-11-10 at 15:26 -0500, Sinan Kaya wrote:
>
> On 11/10/2015 3:05 PM, James Bottomley wrote:
> > OK, you don't seem to be understanding the problem: the Altix isn't a
> > LSI card, it was a SGI platform.
>
> Got it.
>
> > It was the platform where we first
> > discovered the issue
On 11/10/2015 01:13 PM, Arnd Bergmann wrote:
If the mask is 64-bit by default on ARM64, that is a bug that we need
to fix urgently. Can you verify this?
I think the mask is 0 by default, because there's no code in ARM64 that
actually sets the mask.
Take a look at arch_setup_pdev_archdata()
On 11/10/2015 2:56 PM, Arnd Bergmann wrote:
The ACPI IORT table declares whether you enable IOMMU for a particular
>device or not. The placement of IOMMU HW is system specific. The IORT
>table gives the IOMMU HW topology to the operating system.
This sounds odd. Clearly you need to specify
On 11/10/2015 03:54 PM, Arnd Bergmann wrote:
In our drivers for 32-bit devices, we have to explicitly set the DMA
mask to 32-bits in order to get any DMA working.
Do you mean PCI devices or platform devices?
Platform.
Maybe the parent bus is lacking a dma-ranges property?
All of this
On Tuesday 10 November 2015 15:58:19 Sinan Kaya wrote:
>
> On 11/10/2015 2:56 PM, Arnd Bergmann wrote:
> >> The ACPI IORT table declares whether you enable IOMMU for a particular
> >> >device or not. The placement of IOMMU HW is system specific. The IORT
> >> >table gives the IOMMU HW topology to
On Tuesday 10 November 2015 15:59:18 Timur Tabi wrote:
> On 11/10/2015 03:54 PM, Arnd Bergmann wrote:
>
> >> In our drivers for 32-bit devices, we have to explicitly set the DMA
> >> mask to 32-bits in order to get any DMA working.
> >
> > Do you mean PCI devices or platform devices?
>
>
On 11/9/2015 2:09 AM, Hannes Reinecke wrote:
On 11/09/2015 02:57 AM, Sinan Kaya wrote:
Current code gives up when 32 bit DMA is not supported.
This problem has been observed on systems without any
memory below 4 gig.
This patch tests 64 bit support before bailing out to find
a working
On 11/9/2015 3:59 AM, Arnd Bergmann wrote:
On Monday 09 November 2015 08:09:39 Hannes Reinecke wrote:
On 11/09/2015 02:57 AM, Sinan Kaya wrote:
Current code gives up when 32 bit DMA is not supported.
This problem has been observed on systems without any
memory below 4 gig.
This patch tests
On Monday 09 November 2015 08:09:39 Hannes Reinecke wrote:
> On 11/09/2015 02:57 AM, Sinan Kaya wrote:
> > Current code gives up when 32 bit DMA is not supported.
> > This problem has been observed on systems without any
> > memory below 4 gig.
> >
> > This patch tests 64 bit support before
On 11/09/2015 05:22 PM, Sinan Kaya wrote:
if (ioc->dma_mask)
consistent_dma_mask = DMA_BIT_MASK(64);
else
consistent_dma_mask = DMA_BIT_MASK(32); <-- why here?
So this change is from this patch:
http://permalink.gmane.org/gmane.linux.kernel/1759343
Note that this was
Current code gives up when 32 bit DMA is not supported.
This problem has been observed on systems without any
memory below 4 gig.
This patch tests 64 bit support before bailing out to find
a working combination.
Signed-off-by: Sinan Kaya
---
On 11/09/2015 02:57 AM, Sinan Kaya wrote:
> Current code gives up when 32 bit DMA is not supported.
> This problem has been observed on systems without any
> memory below 4 gig.
>
> This patch tests 64 bit support before bailing out to find
> a working combination.
>
That feels decidedly odd.
24 matches
Mail list logo