Re: [PATCH v6 RESED 1/2] dma: replace zone_dma_bits by zone_dma_limit
Hi Marek,
On Tue, Aug 27 2024, Marek Szyprowski wrote:
> On 27.08.2024 06:52, Baruch Siach wrote:
>> Hi Marek,
>>
>> Thanks for your report.
>>
>> On Mon, Aug 26 2024, Marek Szyprowski wrote:
>>> On 11.08.2024 09:09, Baruch Siach wrote:
>>>> From: Catalin Marinas
>>>>
>>>> Hardware DMA limit might not be power of 2. When RAM range starts above
>>>> 0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
>>>> can not encode this limit.
>>>>
>>>> Use plain address for DMA zone limit.
>>>>
>>>> Since DMA zone can now potentially span beyond 4GB physical limit of
>>>> DMA32, make sure to use DMA zone for GFP_DMA32 allocations in that case.
>>>>
>>>> Signed-off-by: Catalin Marinas
>>>> Co-developed-by: Baruch Siach
>>>> Signed-off-by: Baruch Siach
>>>> ---
>>> This patch landed recently in linux-next as commit ba0fb44aed47
>>> ("dma-mapping: replace zone_dma_bits by zone_dma_limit"). During my
>>> tests I found that it introduces the following warning on ARM64/Rockchip
>>> based Odroid M1 board (arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts):
>> Does this warning go away if you revert both 3be9b846896d and ba0fb44aed47?
>
> Yes, linux-next with above mentioned commits reverted works fine.
>
>
>> Upstream rockchip DTs have no dma-ranges property. Is that the case for
>> your platform as well?
>>
>> Can you share kernel report of DMA zones and swiotlb? On my platform I get:
>>
>> [0.00] Zone ranges:
>> [0.00] DMA [mem 0x0008-0x00083fff]
>> [0.00] DMA32empty
>> [0.00] Normal [mem 0x00084000-0x000f]
>> ...
>> [0.00] software IO TLB: area num 8.
>> [0.00] software IO TLB: mapped [mem
>> 0x00083be38000-0x00083fe38000] (64MB)
>>
>> What do you get at your end?
>
> On ba0fb44aed47 I got:
>
> [ 0.00] NUMA: No NUMA configuration found
> [ 0.00] NUMA: Faking a node at [mem
> 0x0020-0x0001]
> [ 0.00] NUMA: NODE_DATA [mem 0x1ff7a0600-0x1ff7a2fff]
> [ 0.00] Zone ranges:
> [ 0.00] DMA [mem 0x0020-0x0001]
> [ 0.00] DMA32 empty
> [ 0.00] Normal empty
> [ 0.00] Movable zone start for each node
> [ 0.00] Early memory node ranges
> [ 0.00] node 0: [mem 0x0020-0x083f]
> [ 0.00] node 0: [mem 0x0940-0xefff]
> [ 0.00] node 0: [mem 0x0001f000-0x0001]
> [ 0.00] Initmem setup node 0 [mem
> 0x0020-0x0001]
> [ 0.00] On node 0, zone DMA: 512 pages in unavailable ranges
> [ 0.00] On node 0, zone DMA: 4096 pages in unavailable ranges
> [ 0.00] cma: Reserved 96 MiB at 0x0001f000 on node -1
>
> ...
>
> [ 0.00] software IO TLB: SWIOTLB bounce buffer size adjusted to 3MB
> [ 0.00] software IO TLB: area num 4.
> [ 0.00] software IO TLB: mapped [mem
> 0x0001fac0-0x0001fb00] (4MB)
>
> On the fa3c109a6d30 (parent commit of the $subject) I got:
>
> [ 0.00] NUMA: No NUMA configuration found
> [ 0.00] NUMA: Faking a node at [mem
> 0x0020-0x0001]
> [ 0.00] NUMA: NODE_DATA [mem 0x1ff7a0600-0x1ff7a2fff]
> [ 0.00] Zone ranges:
> [ 0.00] DMA [mem 0x0020-0x]
> [ 0.00] DMA32 empty
> [ 0.00] Normal [mem 0x0001-0x0001]
> [ 0.00] Movable zone start for each node
> [ 0.00] Early memory node ranges
> [ 0.00] node 0: [mem 0x0020-0x083f]
> [ 0.00] node 0: [mem 0x0940-0xefff]
> [ 0.00] node 0: [mem 0x0001f000-0x0001]
> [ 0.00] Initmem setup node 0 [mem
> 0x0020-0x0001]
> [ 0.00] On node 0, zone DMA: 512 pages in unavailable ranges
> [ 0.00] On node 0, zone DMA: 4096 pages in unavailable ranges
> [ 0.00] cma: Reserved 96 MiB at 0xea00 on node -1
>
> ...
>
> [ 0.00] software IO TLB: area num 4.
> [ 0.00] software IO TLB: mapped [mem
> 0xe600-0xea00] (64MB)
>
> It looks that for some reasons $subject patch changes the default zone
> and swiotlb configuration.
Does this fix the issue?
diff --git a/arch/
Re: [PATCH v6 RESED 1/2] dma: replace zone_dma_bits by zone_dma_limit
Hi Marek,
Thanks for your report.
On Mon, Aug 26 2024, Marek Szyprowski wrote:
> On 11.08.2024 09:09, Baruch Siach wrote:
>> From: Catalin Marinas
>>
>> Hardware DMA limit might not be power of 2. When RAM range starts above
>> 0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
>> can not encode this limit.
>>
>> Use plain address for DMA zone limit.
>>
>> Since DMA zone can now potentially span beyond 4GB physical limit of
>> DMA32, make sure to use DMA zone for GFP_DMA32 allocations in that case.
>>
>> Signed-off-by: Catalin Marinas
>> Co-developed-by: Baruch Siach
>> Signed-off-by: Baruch Siach
>> ---
>
> This patch landed recently in linux-next as commit ba0fb44aed47
> ("dma-mapping: replace zone_dma_bits by zone_dma_limit"). During my
> tests I found that it introduces the following warning on ARM64/Rockchip
> based Odroid M1 board (arch/arm64/boot/dts/rockchip/rk3568-odroid-m1.dts):
Does this warning go away if you revert both 3be9b846896d and ba0fb44aed47?
Upstream rockchip DTs have no dma-ranges property. Is that the case for
your platform as well?
Can you share kernel report of DMA zones and swiotlb? On my platform I get:
[0.00] Zone ranges:
[0.00] DMA [mem 0x0008-0x00083fff]
[0.00] DMA32empty
[0.00] Normal [mem 0x00084000-0x000f]
...
[0.00] software IO TLB: area num 8.
[0.00] software IO TLB: mapped [mem
0x00083be38000-0x00083fe38000] (64MB)
What do you get at your end?
> [ cut here ]
> dwmmc_rockchip fe2b.mmc: swiotlb addr 0x0001faf0+4096
> overflow (mask , bus limit 0).
> WARNING: CPU: 3 PID: 1 at kernel/dma/swiotlb.c:1594 swiotlb_map+0x2f0/0x308
> Modules linked in:
> CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc4+ #15278
> Hardware name: Hardkernel ODROID-M1 (DT)
> pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : swiotlb_map+0x2f0/0x308
> lr : swiotlb_map+0x2f0/0x308
> ...
> Call trace:
> swiotlb_map+0x2f0/0x308
> dma_direct_map_sg+0x9c/0x2e4
> __dma_map_sg_attrs+0x28/0x94
> dma_map_sg_attrs+0x10/0x24
> dw_mci_pre_dma_transfer+0xb8/0xf4
> dw_mci_pre_req+0x50/0x68
> mmc_blk_mq_issue_rq+0x3e0/0x964
> mmc_mq_queue_rq+0x118/0x2b4
> blk_mq_dispatch_rq_list+0x21c/0x714
> __blk_mq_sched_dispatch_requests+0x490/0x58c
> blk_mq_sched_dispatch_requests+0x30/0x6c
> blk_mq_run_hw_queue+0x284/0x40c
> blk_mq_flush_plug_list.part.0+0x190/0x974
> blk_mq_flush_plug_list+0x1c/0x2c
> __blk_flush_plug+0xe4/0x140
> blk_finish_plug+0x38/0x4c
> __ext4_get_inode_loc+0x22c/0x654
> __ext4_get_inode_loc_noinmem+0x40/0xa8
> __ext4_iget+0x154/0xcc0
> ext4_get_journal_inode+0x30/0x110
> ext4_load_and_init_journal+0x9c/0xaf0
> ext4_fill_super+0x1fec/0x2d90
> get_tree_bdev+0x140/0x1d8
> ext4_get_tree+0x18/0x24
> vfs_get_tree+0x28/0xe8
> path_mount+0x3e8/0xb7c
> init_mount+0x68/0xac
> do_mount_root+0x108/0x1dc
> mount_root_generic+0x100/0x330
> mount_root+0x160/0x2d0
> initrd_load+0x1f0/0x2a0
> prepare_namespace+0x4c/0x29c
> kernel_init_freeable+0x4b4/0x50c
> kernel_init+0x20/0x1d8
> ret_from_fork+0x10/0x20
> irq event stamp: 1305682
> hardirqs last enabled at (1305681): []
> console_unlock+0x124/0x130
> hardirqs last disabled at (1305682): [] el1_dbg+0x24/0x8c
> softirqs last enabled at (1305678): []
> handle_softirqs+0x4cc/0x4e4
> softirqs last disabled at (1305665): []
> __do_softirq+0x14/0x20
> ---[ end trace ]---
>
> This "bus limit 0" seems to be a bit suspicious to me as well as the
> fact that swiotlb is used for the MMC DMA. I will investigate this
> further tomorrow. The board boots fine though.
Looking at the code I guess that bus_dma_limit set to 0 means no bus
limit. But dma_mask for your device indicates 32-bit device limit. This
can't work with address above 4GB. For some reason DMA code tries to
allocate from higher address. This is most likely the reason
dma_capable() returns false.
Thanks,
baruch
>> arch/arm64/mm/init.c | 30 +++---
>> arch/powerpc/mm/mem.c | 5 -
>> arch/s390/mm/init.c| 2 +-
>> include/linux/dma-direct.h | 2 +-
>> kernel/dma/direct.c| 6 +++---
>> kernel/dma/pool.c | 4 ++--
>> kernel/dma/swiotlb.c | 6 +++---
>> 7 files changed, 29 insertions(+), 26 deletions(-)
>>
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 9b5ab6818f7f..c45e2152ca9e 100644
>> --- a/arch/arm64/mm/init.c
>>
[PATCH v6 RESED 2/2] arm64: support DMA zone above 4GB
From: Catalin Marinas
Commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation") made arm64 DMA/DMA32 zones span the entire
RAM when RAM starts above 32-bits. This breaks hardware with DMA area
that start above 32-bits. But the commit log says that "we haven't
noticed any such hardware". It turns out that such hardware does exist.
One such platform has RAM starting at 32GB with an internal bus that has
the following DMA limits:
#address-cells = <2>;
#size-cells = <2>;
dma-ranges = <0x00 0xc000 0x08 0x 0x00 0x4000>;
That is, devices under this bus see 1GB of DMA range between 3GB-4GB in
their address space. This range is mapped to CPU memory at 32GB-33GB.
With current code DMA allocations for devices under this bus are not
limited to DMA area, leading to run-time allocation failure.
This commit reinstates DMA zone at the bottom of RAM. The result is DMA
zone that properly reflects the hardware constraints as follows:
[0.00] Zone ranges:
[0.00] DMA [mem 0x0008-0x00083fff]
[0.00] DMA32empty
[0.00] Normal [mem 0x00084000-0x000b]
Signed-off-by: Catalin Marinas
[baruch: split off the original patch]
Signed-off-by: Baruch Siach
---
arch/arm64/mm/init.c | 12
1 file changed, 12 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index c45e2152ca9e..bfb10969cbf0 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -114,20 +114,8 @@ static void __init arch_reserve_crashkernel(void)
low_size, high);
}
-/*
- * Return the maximum physical address for a zone given its limit.
- * If DRAM starts above 32-bit, expand the zone to the maximum
- * available memory, otherwise cap it at 32-bit.
- */
static phys_addr_t __init max_zone_phys(phys_addr_t zone_limit)
{
- phys_addr_t phys_start = memblock_start_of_DRAM();
-
- if (phys_start > U32_MAX)
- zone_limit = PHYS_ADDR_MAX;
- else if (phys_start > zone_limit)
- zone_limit = U32_MAX;
-
return min(zone_limit, memblock_end_of_DRAM() - 1) + 1;
}
--
2.43.0
[PATCH v6 RESED 1/2] dma: replace zone_dma_bits by zone_dma_limit
From: Catalin Marinas
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
can not encode this limit.
Use plain address for DMA zone limit.
Since DMA zone can now potentially span beyond 4GB physical limit of
DMA32, make sure to use DMA zone for GFP_DMA32 allocations in that case.
Signed-off-by: Catalin Marinas
Co-developed-by: Baruch Siach
Signed-off-by: Baruch Siach
---
arch/arm64/mm/init.c | 30 +++---
arch/powerpc/mm/mem.c | 5 -
arch/s390/mm/init.c| 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c| 6 +++---
kernel/dma/pool.c | 4 ++--
kernel/dma/swiotlb.c | 6 +++---
7 files changed, 29 insertions(+), 26 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9b5ab6818f7f..c45e2152ca9e 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -115,35 +115,35 @@ static void __init arch_reserve_crashkernel(void)
}
/*
- * Return the maximum physical address for a zone accessible by the given bits
- * limit. If DRAM starts above 32-bit, expand the zone to the maximum
+ * Return the maximum physical address for a zone given its limit.
+ * If DRAM starts above 32-bit, expand the zone to the maximum
* available memory, otherwise cap it at 32-bit.
*/
-static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
+static phys_addr_t __init max_zone_phys(phys_addr_t zone_limit)
{
- phys_addr_t zone_mask = DMA_BIT_MASK(zone_bits);
phys_addr_t phys_start = memblock_start_of_DRAM();
if (phys_start > U32_MAX)
- zone_mask = PHYS_ADDR_MAX;
- else if (phys_start > zone_mask)
- zone_mask = U32_MAX;
+ zone_limit = PHYS_ADDR_MAX;
+ else if (phys_start > zone_limit)
+ zone_limit = U32_MAX;
- return min(zone_mask, memblock_end_of_DRAM() - 1) + 1;
+ return min(zone_limit, memblock_end_of_DRAM() - 1) + 1;
}
static void __init zone_sizes_init(void)
{
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
- unsigned int __maybe_unused acpi_zone_dma_bits;
- unsigned int __maybe_unused dt_zone_dma_bits;
- phys_addr_t __maybe_unused dma32_phys_limit = max_zone_phys(32);
+ phys_addr_t __maybe_unused acpi_zone_dma_limit;
+ phys_addr_t __maybe_unused dt_zone_dma_limit;
+ phys_addr_t __maybe_unused dma32_phys_limit =
+ max_zone_phys(DMA_BIT_MASK(32));
#ifdef CONFIG_ZONE_DMA
- acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address());
- dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
- zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits);
- arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
+ acpi_zone_dma_limit = acpi_iort_dma_get_max_cpu_address();
+ dt_zone_dma_limit = of_dma_get_max_cpu_address(NULL);
+ zone_dma_limit = min(dt_zone_dma_limit, acpi_zone_dma_limit);
+ arm64_dma_phys_limit = max_zone_phys(zone_dma_limit);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
#endif
#ifdef CONFIG_ZONE_DMA32
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index d325217ab201..05b7f702b3f7 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -216,7 +216,7 @@ static int __init mark_nonram_nosave(void)
* everything else. GFP_DMA32 page allocations automatically fall back to
* ZONE_DMA.
*
- * By using 31-bit unconditionally, we can exploit zone_dma_bits to inform the
+ * By using 31-bit unconditionally, we can exploit zone_dma_limit to inform the
* generic DMA mapping code. 32-bit only devices (if not handled by an IOMMU
* anyway) will take a first dip into ZONE_NORMAL and get otherwise served by
* ZONE_DMA.
@@ -230,6 +230,7 @@ void __init paging_init(void)
{
unsigned long long total_ram = memblock_phys_mem_size();
phys_addr_t top_of_ram = memblock_end_of_DRAM();
+ int zone_dma_bits;
#ifdef CONFIG_HIGHMEM
unsigned long v = __fix_to_virt(FIX_KMAP_END);
@@ -256,6 +257,8 @@ void __init paging_init(void)
else
zone_dma_bits = 31;
+ zone_dma_limit = DMA_BIT_MASK(zone_dma_bits);
+
#ifdef CONFIG_ZONE_DMA
max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
1UL << (zone_dma_bits - PAGE_SHIFT));
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index ddcd39ef4346..91fc2b91adfc 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -97,7 +97,7 @@ void __init paging_init(void)
vmem_map_init();
sparse_init();
- zone_dma_bits = 31;
+ zone_dma_limit = DMA_BIT_MASK(31);
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
max_zone_pfns[ZONE_DMA] = virt_to_pfn(MAX_DMA_ADDRESS);
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
diff --git a/include/linux/dma-direct.h b/in
[PATCH v6 RESED 0/2] dma: support DMA zone starting above 4GB
[ Resend series with correct Cc list. Sorry for the spam. ]
DMA zones code assumes that DMA lower limit is zero. When there is no RAM
below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire
RAM[0].
My target platform has RAM starting at 32GB. Devices with 30-bit DMA mask are
mapped to 1GB at the bottom of RAM, between 32GB - 33GB. DMA zone over the
entire RAM breaks DMA allocation for these devices.
In response to a previous RFC hack[1] Catalin Marinas suggested to add a
separate offset value as base address for the DMA zone, and then refined the
suggestion to use start of RAM[3]. This series attempts to implement that
suggestion.
With this series applied, the DMA zone covers the right RAM range for my
platform.
v6:
* Drop the first patch; existing logic is just fine
* Modify powerpc code to avoid off by one issue
v5:
* Test the correct kernel
* Add missing patch that actually makes DMA zone work
* Extend the treatment of zone_dma_limit > DMA_BIT_MASK(32)
* Use max() to make the code somewhat more readable
* Change zone_dma_limit type to u64 to match DMA_BIT_MASK()
v4:
* Drop last patch. zone_dma_limit includes RAM base address.
* Adjust DMA zone selection in swiotlb as well.
* Don't change max_zone_phys() behaviour
* Update code to fallback to DMA zone when zone_dma_limit > DMA_BIT_MASK(32)
v3:
* Rebase on v6.11-rc1.
* Drop zone_dma_base. Use memblock_start_of_DRAM() instead.
* Drop DT patches. Low DMA range limit no longer needed.
* Add patch to improve dma_direct_optimal_gfp_mask() heuristics as Catalin
suggested.
RFC v2:
* Add patch from Catalin[2] changing zone_dma_bits to zone_dma_limit to
simplify subsequent patches
* Test on real hardware
RFC v1: https://lore.kernel.org/all/cover.1703683642.git.bar...@tkos.co.il/
[0] See commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation")
[1]
https://lore.kernel.org/all/9af8a19c3398e7dc09cfc1fbafed98d795d9f83e.1699464622.git.bar...@tkos.co.il/
[2] https://lore.kernel.org/all/zz2hnhjv3gdzu...@arm.com/
[3] https://lore.kernel.org/all/znh-vu2iz9q2k...@arm.com/
Catalin Marinas (2):
dma: replace zone_dma_bits by zone_dma_limit
arm64: support DMA zone above 4GB
arch/arm64/mm/init.c | 32 ++--
arch/powerpc/mm/mem.c | 5 -
arch/s390/mm/init.c| 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c| 6 +++---
kernel/dma/pool.c | 4 ++--
kernel/dma/swiotlb.c | 6 +++---
7 files changed, 24 insertions(+), 33 deletions(-)
base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b
--
2.43.0
[PATCH v6 0/2] dma: support DMA zone starting above 4GB
From: Baruch Siach
DMA zones code assumes that DMA lower limit is zero. When there is no RAM
below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire
RAM[0].
My target platform has RAM starting at 32GB. Devices with 30-bit DMA mask are
mapped to 1GB at the bottom of RAM, between 32GB - 33GB. DMA zone over the
entire RAM breaks DMA allocation for these devices.
In response to a previous RFC hack[1] Catalin Marinas suggested to add a
separate offset value as base address for the DMA zone, and then refined the
suggestion to use start of RAM[3]. This series attempts to implement that
suggestion.
With this series applied, the DMA zone covers the right RAM range for my
platform.
v6:
* Drop the first patch; existing logic is just fine
* Modify powerpc code to avoid off by one issue
v5:
* Test the correct kernel
* Add missing patch that actually makes DMA zone work
* Extend the treatment of zone_dma_limit > DMA_BIT_MASK(32)
* Use max() to make the code somewhat more readable
* Change zone_dma_limit type to u64 to match DMA_BIT_MASK()
v4:
* Drop last patch. zone_dma_limit includes RAM base address.
* Adjust DMA zone selection in swiotlb as well.
* Don't change max_zone_phys() behaviour
* Update code to fallback to DMA zone when zone_dma_limit > DMA_BIT_MASK(32)
v3:
* Rebase on v6.11-rc1.
* Drop zone_dma_base. Use memblock_start_of_DRAM() instead.
* Drop DT patches. Low DMA range limit no longer needed.
* Add patch to improve dma_direct_optimal_gfp_mask() heuristics as Catalin
suggested.
RFC v2:
* Add patch from Catalin[2] changing zone_dma_bits to zone_dma_limit to
simplify subsequent patches
* Test on real hardware
RFC v1: https://lore.kernel.org/all/cover.1703683642.git.bar...@tkos.co.il/
[0] See commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation")
[1]
https://lore.kernel.org/all/9af8a19c3398e7dc09cfc1fbafed98d795d9f83e.1699464622.git.bar...@tkos.co.il/
[2] https://lore.kernel.org/all/zz2hnhjv3gdzu...@arm.com/
[3] https://lore.kernel.org/all/znh-vu2iz9q2k...@arm.com/
Catalin Marinas (2):
dma: replace zone_dma_bits by zone_dma_limit
arm64: support DMA zone above 4GB
arch/arm64/mm/init.c | 32 ++--
arch/powerpc/mm/mem.c | 5 -
arch/s390/mm/init.c| 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c| 6 +++---
kernel/dma/pool.c | 4 ++--
kernel/dma/swiotlb.c | 6 +++---
7 files changed, 24 insertions(+), 33 deletions(-)
base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b
--
2.43.0
[PATCH v5 0/3] dma: support DMA zone starting above 4GB
DMA zones code assumes that DMA lower limit is zero. When there is no RAM
below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire
RAM[0].
My target platform has RAM starting at 32GB. Devices with 30-bit DMA mask are
mapped to 1GB at the bottom of RAM, between 32GB - 33GB. DMA zone over the
entire RAM breaks DMA allocation for these devices.
In response to a previous RFC hack[1] Catalin Marinas suggested to add a
separate offset value as base address for the DMA zone, and then refined the
suggestion to use start of RAM[3]. This series attempts to implement that
suggestion.
With this series applied, the DMA zone covers the right RAM range for my
platform.
v5:
* Test the correct kernel
* Add missing patch that actually makes DMA zone work
* Extend the treatment of zone_dma_limit > DMA_BIT_MASK(32)
* Use max() to make the code somewhat more readable
* Change zone_dma_limit type to u64 to match DMA_BIT_MASK()
v4:
* Drop last patch. zone_dma_limit includes RAM base address.
* Adjust DMA zone selection in swiotlb as well.
* Don't change max_zone_phys() behaviour
* Update code to fallback to DMA zone when zone_dma_limit > DMA_BIT_MASK(32)
v3:
* Rebase on v6.11-rc1.
* Drop zone_dma_base. Use memblock_start_of_DRAM() instead.
* Drop DT patches. Low DMA range limit no longer needed.
* Add patch to improve dma_direct_optimal_gfp_mask() heuristics as Catalin
suggested.
RFC v2:
* Add patch from Catalin[2] changing zone_dma_bits to zone_dma_limit to
simplify subsequent patches
* Test on real hardware
RFC v1: https://lore.kernel.org/all/cover.1703683642.git.bar...@tkos.co.il/
[0] See commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation")
[1]
https://lore.kernel.org/all/9af8a19c3398e7dc09cfc1fbafed98d795d9f83e.1699464622.git.bar...@tkos.co.il/
[2] https://lore.kernel.org/all/zz2hnhjv3gdzu...@arm.com/
[3] https://lore.kernel.org/all/znh-vu2iz9q2k...@arm.com/
Baruch Siach (1):
dma: improve DMA zone selection
Catalin Marinas (2):
dma: replace zone_dma_bits by zone_dma_limit
arm64: support DMA zone above 4GB
arch/arm64/mm/init.c | 32 ++--
arch/powerpc/mm/mem.c | 9 -
arch/s390/mm/init.c| 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c| 10 +-
kernel/dma/pool.c | 4 ++--
kernel/dma/swiotlb.c | 8
7 files changed, 27 insertions(+), 40 deletions(-)
base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b
--
2.43.0
[PATCH v5 3/3] arm64: support DMA zone above 4GB
From: Catalin Marinas
Commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation") made arm64 DMA/DMA32 zones span the entire
RAM when RAM starts above 32-bits. This breaks hardware with DMA area
that start above 32-bits. But the commit log says that "we haven't
noticed any such hardware". It turns out that such hardware does exist.
One such platform has RAM starting at 32GB with an internal bus that has
the following DMA limits:
#address-cells = <2>;
#size-cells = <2>;
dma-ranges = <0x00 0xc000 0x08 0x 0x00 0x4000>;
That is, devices under this bus see 1GB of DMA range between 3GB-4GB in
their address space. This range is mapped to CPU memory at 32GB-33GB.
With current code DMA allocations for devices under this bus are not
limited to DMA area, leading to run-time allocation failure.
This commit reinstates DMA zone at the bottom of RAM. The result is DMA
zone that properly reflects the hardware constraints as follows:
[0.00] Zone ranges:
[0.00] DMA [mem 0x0008-0x00083fff]
[0.00] DMA32empty
[0.00] Normal [mem 0x00084000-0x000b]
Signed-off-by: Catalin Marinas
[baruch: split off the original patch]
Signed-off-by: Baruch Siach
---
arch/arm64/mm/init.c | 12
1 file changed, 12 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index c45e2152ca9e..bfb10969cbf0 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -114,20 +114,8 @@ static void __init arch_reserve_crashkernel(void)
low_size, high);
}
-/*
- * Return the maximum physical address for a zone given its limit.
- * If DRAM starts above 32-bit, expand the zone to the maximum
- * available memory, otherwise cap it at 32-bit.
- */
static phys_addr_t __init max_zone_phys(phys_addr_t zone_limit)
{
- phys_addr_t phys_start = memblock_start_of_DRAM();
-
- if (phys_start > U32_MAX)
- zone_limit = PHYS_ADDR_MAX;
- else if (phys_start > zone_limit)
- zone_limit = U32_MAX;
-
return min(zone_limit, memblock_end_of_DRAM() - 1) + 1;
}
--
2.43.0
[PATCH v5 1/3] dma: improve DMA zone selection
When device DMA limit does not fit in DMA32 zone it should use DMA zone,
even when DMA zone is stricter than needed.
Same goes for devices that can't allocate from the entire normal zone.
Limit to DMA32 in that case.
Reported-by: Catalin Marinas
Reviewed-by: Catalin Marinas
Signed-off-by: Baruch Siach
---
kernel/dma/direct.c | 6 +++---
kernel/dma/swiotlb.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 4480a3cd92e0..3b4be4ca3b08 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -4,7 +4,7 @@
*
* DMA operations that map physical memory directly without using an IOMMU.
*/
-#include /* for max_pfn */
+#include
#include
#include
#include
@@ -59,9 +59,9 @@ static gfp_t dma_direct_optimal_gfp_mask(struct device *dev,
u64 *phys_limit)
* zones.
*/
*phys_limit = dma_to_phys(dev, dma_limit);
- if (*phys_limit <= DMA_BIT_MASK(zone_dma_bits))
+ if (*phys_limit < DMA_BIT_MASK(32))
return GFP_DMA;
- if (*phys_limit <= DMA_BIT_MASK(32))
+ if (*phys_limit < memblock_end_of_DRAM())
return GFP_DMA32;
return 0;
}
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index df68d29740a0..043b0ecd3e8d 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -629,9 +629,9 @@ static struct page *swiotlb_alloc_tlb(struct device *dev,
size_t bytes,
}
gfp &= ~GFP_ZONEMASK;
- if (phys_limit <= DMA_BIT_MASK(zone_dma_bits))
+ if (phys_limit < DMA_BIT_MASK(32))
gfp |= __GFP_DMA;
- else if (phys_limit <= DMA_BIT_MASK(32))
+ else if (phys_limit < memblock_end_of_DRAM())
gfp |= __GFP_DMA32;
while (IS_ERR(page = alloc_dma_pages(gfp, bytes, phys_limit))) {
--
2.43.0
[PATCH v5 2/3] dma: replace zone_dma_bits by zone_dma_limit
From: Catalin Marinas
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
can not encode this limit.
Use plain address for DMA zone limit.
Since DMA zone can now potentially span beyond 4GB physical limit of
DMA32, make sure to use DMA zone for GFP_DMA32 allocations in that case.
Signed-off-by: Catalin Marinas
Co-developed-by: Baruch Siach
Signed-off-by: Baruch Siach
---
arch/arm64/mm/init.c | 30 +++---
arch/powerpc/mm/mem.c | 9 -
arch/s390/mm/init.c| 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c| 4 ++--
kernel/dma/pool.c | 4 ++--
kernel/dma/swiotlb.c | 4 ++--
7 files changed, 27 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9b5ab6818f7f..c45e2152ca9e 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -115,35 +115,35 @@ static void __init arch_reserve_crashkernel(void)
}
/*
- * Return the maximum physical address for a zone accessible by the given bits
- * limit. If DRAM starts above 32-bit, expand the zone to the maximum
+ * Return the maximum physical address for a zone given its limit.
+ * If DRAM starts above 32-bit, expand the zone to the maximum
* available memory, otherwise cap it at 32-bit.
*/
-static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
+static phys_addr_t __init max_zone_phys(phys_addr_t zone_limit)
{
- phys_addr_t zone_mask = DMA_BIT_MASK(zone_bits);
phys_addr_t phys_start = memblock_start_of_DRAM();
if (phys_start > U32_MAX)
- zone_mask = PHYS_ADDR_MAX;
- else if (phys_start > zone_mask)
- zone_mask = U32_MAX;
+ zone_limit = PHYS_ADDR_MAX;
+ else if (phys_start > zone_limit)
+ zone_limit = U32_MAX;
- return min(zone_mask, memblock_end_of_DRAM() - 1) + 1;
+ return min(zone_limit, memblock_end_of_DRAM() - 1) + 1;
}
static void __init zone_sizes_init(void)
{
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
- unsigned int __maybe_unused acpi_zone_dma_bits;
- unsigned int __maybe_unused dt_zone_dma_bits;
- phys_addr_t __maybe_unused dma32_phys_limit = max_zone_phys(32);
+ phys_addr_t __maybe_unused acpi_zone_dma_limit;
+ phys_addr_t __maybe_unused dt_zone_dma_limit;
+ phys_addr_t __maybe_unused dma32_phys_limit =
+ max_zone_phys(DMA_BIT_MASK(32));
#ifdef CONFIG_ZONE_DMA
- acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address());
- dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
- zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits);
- arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
+ acpi_zone_dma_limit = acpi_iort_dma_get_max_cpu_address();
+ dt_zone_dma_limit = of_dma_get_max_cpu_address(NULL);
+ zone_dma_limit = min(dt_zone_dma_limit, acpi_zone_dma_limit);
+ arm64_dma_phys_limit = max_zone_phys(zone_dma_limit);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
#endif
#ifdef CONFIG_ZONE_DMA32
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index d325217ab201..342c006cc1b8 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -216,7 +216,7 @@ static int __init mark_nonram_nosave(void)
* everything else. GFP_DMA32 page allocations automatically fall back to
* ZONE_DMA.
*
- * By using 31-bit unconditionally, we can exploit zone_dma_bits to inform the
+ * By using 31-bit unconditionally, we can exploit zone_dma_limit to inform the
* generic DMA mapping code. 32-bit only devices (if not handled by an IOMMU
* anyway) will take a first dip into ZONE_NORMAL and get otherwise served by
* ZONE_DMA.
@@ -252,13 +252,12 @@ void __init paging_init(void)
* powerbooks.
*/
if (IS_ENABLED(CONFIG_PPC32))
- zone_dma_bits = 30;
+ zone_dma_limit = DMA_BIT_MASK(30);
else
- zone_dma_bits = 31;
+ zone_dma_limit = DMA_BIT_MASK(31);
#ifdef CONFIG_ZONE_DMA
- max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
- 1UL << (zone_dma_bits - PAGE_SHIFT));
+ max_zone_pfns[ZONE_DMA] = min(max_low_pfn, zone_dma_limit >>
PAGE_SHIFT);
#endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
#ifdef CONFIG_HIGHMEM
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index ddcd39ef4346..91fc2b91adfc 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -97,7 +97,7 @@ void __init paging_init(void)
vmem_map_init();
sparse_init();
- zone_dma_bits = 31;
+ zone_dma_limit = DMA_BIT_MASK(31);
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
max_zone_pfns[ZONE_DMA] = virt_to_pfn(MAX_DMA_ADDRESS);
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
[PATCH v4 1/2] dma: improve DMA zone selection
When device DMA limit does not fit in DMA32 zone it should use DMA zone,
even when DMA zone is stricter than needed.
Same goes for devices that can't allocate from the entire normal zone.
Limit to DMA32 in that case.
Reported-by: Catalin Marinas
Signed-off-by: Baruch Siach
---
kernel/dma/direct.c | 6 +++---
kernel/dma/swiotlb.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 4480a3cd92e0..3b4be4ca3b08 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -4,7 +4,7 @@
*
* DMA operations that map physical memory directly without using an IOMMU.
*/
-#include /* for max_pfn */
+#include
#include
#include
#include
@@ -59,9 +59,9 @@ static gfp_t dma_direct_optimal_gfp_mask(struct device *dev,
u64 *phys_limit)
* zones.
*/
*phys_limit = dma_to_phys(dev, dma_limit);
- if (*phys_limit <= DMA_BIT_MASK(zone_dma_bits))
+ if (*phys_limit < DMA_BIT_MASK(32))
return GFP_DMA;
- if (*phys_limit <= DMA_BIT_MASK(32))
+ if (*phys_limit < memblock_end_of_DRAM())
return GFP_DMA32;
return 0;
}
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index df68d29740a0..043b0ecd3e8d 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -629,9 +629,9 @@ static struct page *swiotlb_alloc_tlb(struct device *dev,
size_t bytes,
}
gfp &= ~GFP_ZONEMASK;
- if (phys_limit <= DMA_BIT_MASK(zone_dma_bits))
+ if (phys_limit < DMA_BIT_MASK(32))
gfp |= __GFP_DMA;
- else if (phys_limit <= DMA_BIT_MASK(32))
+ else if (phys_limit < memblock_end_of_DRAM())
gfp |= __GFP_DMA32;
while (IS_ERR(page = alloc_dma_pages(gfp, bytes, phys_limit))) {
--
2.43.0
[PATCH v4 0/2] dma: support DMA zone starting above 4GB
DMA zones code assumes that DMA lower limit is zero. When there is no RAM
below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire
RAM[0].
My target platform has RAM starting at 32GB. Devices with 30-bit DMA mask are
mapped to 1GB at the bottom of RAM, between 32GB - 33GB. DMA zone over the
entire RAM breaks DMA allocation for these devices.
In response to a previous RFC hack[1] Catalin Marinas suggested to add a
separate offset value as base address for the DMA zone, and then refined the
suggestion to use start of RAM[3]. This series attempts to implement that
suggestion.
With this series applied, the DMA zone covers the right RAM range for my
platform.
v4:
* Drop last patch. zone_dma_limit includes RAM base address.
* Adjust DMA zone selection in swiotlb as well.
* Don't change max_zone_phys() behaviour
* Update code to fallback to DMA zone when zone_dma_limit > DMA_BIT_MASK(32)
v3:
* Rebase on v6.11-rc1.
* Drop zone_dma_base. Use memblock_start_of_DRAM() instead.
* Drop DT patches. Low DMA range limit no longer needed.
* Add patch to improve dma_direct_optimal_gfp_mask() heuristics as Catalin
suggested.
RFC v2:
* Add patch from Catalin[2] changing zone_dma_bits to zone_dma_limit to
simplify subsequent patches
* Test on real hardware
RFC v1: https://lore.kernel.org/all/cover.1703683642.git.bar...@tkos.co.il/
[0] See commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation")
[1]
https://lore.kernel.org/all/9af8a19c3398e7dc09cfc1fbafed98d795d9f83e.1699464622.git.bar...@tkos.co.il/
[2] https://lore.kernel.org/all/zz2hnhjv3gdzu...@arm.com/
[3] https://lore.kernel.org/all/znh-vu2iz9q2k...@arm.com/
Baruch Siach (1):
dma: improve DMA zone selection
Catalin Marinas (1):
dma: replace zone_dma_bits by zone_dma_limit
arch/arm64/mm/init.c | 30 +++---
arch/powerpc/mm/mem.c | 9 -
arch/s390/mm/init.c| 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c| 10 +-
kernel/dma/pool.c | 5 +++--
kernel/dma/swiotlb.c | 6 +++---
7 files changed, 32 insertions(+), 32 deletions(-)
base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b
--
2.43.0
[PATCH v4 2/2] dma: replace zone_dma_bits by zone_dma_limit
From: Catalin Marinas
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
can not encode this limit.
Use direct phys_addr_t limit address for DMA zone limit.
Current code using zone_dma_bits assume that all address range below
limit is suitable for DMA. For some existing platforms this assumption
is not correct. DMA range might have non zero lower limit.
Commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation") made arm64 DMA/DMA32 zones span the entire
RAM when RAM starts above 32-bits. This breaks hardware with DMA area
that start above 32-bits. But the commit log says that "we haven't
noticed any such hardware". It turns out that such hardware does exist.
One such platform has RAM starting at 32GB with an internal bus that has
the following DMA limits:
#address-cells = <2>;
#size-cells = <2>;
dma-ranges = <0x00 0xc000 0x08 0x 0x00 0x4000>;
That is, devices under this bus see 1GB of DMA range between 3GB-4GB in
their address space. This range is mapped to CPU memory at 32GB-33GB.
With current code DMA allocations for devices under this bus are not
limited to DMA area, leading to run-time allocation failure.
With the move to zone_dma_limit DMA allocation for constrained devices
becomes possible.
The result is DMA zone that properly reflects the hardware constraints
as follows:
[0.00] Zone ranges:
[0.00] DMA [mem 0x0008-0x00083fff]
[0.00] DMA32empty
[0.00] Normal [mem 0x00084000-0x000b]
Signed-off-by: Catalin Marinas
Co-developed-by: Baruch Siach
Signed-off-by: Baruch Siach
---
arch/arm64/mm/init.c | 30 +++---
arch/powerpc/mm/mem.c | 9 -
arch/s390/mm/init.c| 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c| 4 ++--
kernel/dma/pool.c | 5 +++--
kernel/dma/swiotlb.c | 2 +-
7 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9b5ab6818f7f..c45e2152ca9e 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -115,35 +115,35 @@ static void __init arch_reserve_crashkernel(void)
}
/*
- * Return the maximum physical address for a zone accessible by the given bits
- * limit. If DRAM starts above 32-bit, expand the zone to the maximum
+ * Return the maximum physical address for a zone given its limit.
+ * If DRAM starts above 32-bit, expand the zone to the maximum
* available memory, otherwise cap it at 32-bit.
*/
-static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
+static phys_addr_t __init max_zone_phys(phys_addr_t zone_limit)
{
- phys_addr_t zone_mask = DMA_BIT_MASK(zone_bits);
phys_addr_t phys_start = memblock_start_of_DRAM();
if (phys_start > U32_MAX)
- zone_mask = PHYS_ADDR_MAX;
- else if (phys_start > zone_mask)
- zone_mask = U32_MAX;
+ zone_limit = PHYS_ADDR_MAX;
+ else if (phys_start > zone_limit)
+ zone_limit = U32_MAX;
- return min(zone_mask, memblock_end_of_DRAM() - 1) + 1;
+ return min(zone_limit, memblock_end_of_DRAM() - 1) + 1;
}
static void __init zone_sizes_init(void)
{
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
- unsigned int __maybe_unused acpi_zone_dma_bits;
- unsigned int __maybe_unused dt_zone_dma_bits;
- phys_addr_t __maybe_unused dma32_phys_limit = max_zone_phys(32);
+ phys_addr_t __maybe_unused acpi_zone_dma_limit;
+ phys_addr_t __maybe_unused dt_zone_dma_limit;
+ phys_addr_t __maybe_unused dma32_phys_limit =
+ max_zone_phys(DMA_BIT_MASK(32));
#ifdef CONFIG_ZONE_DMA
- acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address());
- dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
- zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits);
- arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
+ acpi_zone_dma_limit = acpi_iort_dma_get_max_cpu_address();
+ dt_zone_dma_limit = of_dma_get_max_cpu_address(NULL);
+ zone_dma_limit = min(dt_zone_dma_limit, acpi_zone_dma_limit);
+ arm64_dma_phys_limit = max_zone_phys(zone_dma_limit);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
#endif
#ifdef CONFIG_ZONE_DMA32
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index d325217ab201..342c006cc1b8 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -216,7 +216,7 @@ static int __init mark_nonram_nosave(void)
* everything else. GFP_DMA32 page allocations automatically fall back to
* ZONE_DMA.
*
- * By using 31-bit unconditionally, we can exploit zone_dma_bits to inform the
+ * By using 31-bit unconditionally, we can exploit zone_dma_l
[PATCH v3 0/3] dma: support DMA zone starting above 4GB
DMA zones code assumes that DMA lower limit is zero. When there is no RAM
below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire
RAM[0].
My target platform has RAM starting at 32GB. Devices with 30-bit DMA mask are
mapped to 1GB at the bottom of RAM, between 32GB - 33GB. DMA zone over the
entire RAM breaks DMA allocation for these devices.
In response to a previous RFC hack[1] Catalin Marinas suggested to add a
separate offset value as base address for the DMA zone, and then refined the
suggestion to use start of RAM[3]. This RFC series attempts to implement that
suggestion.
With this series applied, the DMA zone covers the right RAM range for my
platform.
v3:
* Rebase on v6.11-rc1.
* Drop zone_dma_base. Use memblock_start_of_DRAM() instead.
* Drop DT patches. Low DMA range limit no longer needed.
* Add patch to improve dma_direct_optimal_gfp_mask() heuristics as Catalin
suggested.
RFC v2:
* Add patch from Catalin[2] changing zone_dma_bits to zone_dma_limit to
simplify subsequent patches
* Test on real hardware
RFC v1: https://lore.kernel.org/all/cover.1703683642.git.bar...@tkos.co.il/
[0] See commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation")
[1]
https://lore.kernel.org/all/9af8a19c3398e7dc09cfc1fbafed98d795d9f83e.1699464622.git.bar...@tkos.co.il/
[2] https://lore.kernel.org/all/zz2hnhjv3gdzu...@arm.com/
[3] https://lore.kernel.org/all/znh-vu2iz9q2k...@arm.com/
Baruch Siach (2):
dma-mapping: improve DMA zone selection
dma-direct: use RAM start to offset zone_dma_limit
Catalin Marinas (1):
dma-mapping: replace zone_dma_bits by zone_dma_limit
arch/arm64/mm/init.c | 34 +-
arch/powerpc/mm/mem.c | 9 -
arch/s390/mm/init.c| 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c| 15 ---
kernel/dma/pool.c | 3 ++-
kernel/dma/swiotlb.c | 4 ++--
7 files changed, 31 insertions(+), 38 deletions(-)
--
2.43.0
[PATCH v3 1/3] dma-mapping: improve DMA zone selection
When device DMA limit does not fit in DMA32 zone it should use DMA zone, even when DMA zone is stricter than needed. Same goes for devices that can't allocate from the entire normal zone. Limit to DMA32 in that case. Reported-by: Catalin Marinas Signed-off-by: Baruch Siach --- kernel/dma/direct.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 4480a3cd92e0..3b4be4ca3b08 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -4,7 +4,7 @@ * * DMA operations that map physical memory directly without using an IOMMU. */ -#include /* for max_pfn */ +#include #include #include #include @@ -59,9 +59,9 @@ static gfp_t dma_direct_optimal_gfp_mask(struct device *dev, u64 *phys_limit) * zones. */ *phys_limit = dma_to_phys(dev, dma_limit); - if (*phys_limit <= DMA_BIT_MASK(zone_dma_bits)) + if (*phys_limit < DMA_BIT_MASK(32)) return GFP_DMA; - if (*phys_limit <= DMA_BIT_MASK(32)) + if (*phys_limit < memblock_end_of_DRAM()) return GFP_DMA32; return 0; } -- 2.43.0
[PATCH v3 3/3] dma-direct: use RAM start to offset zone_dma_limit
Current code using zone_dma_limit assume that all address range below
limit is suitable for DMA. For some existing platforms this assumption
is not correct. DMA range might have non zero lower limit.
Commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation") made DMA/DMA32 zones span the entire RAM
when RAM starts above 32-bits. This breaks hardware with DMA area that
start above 32-bits. But the commit log says that "we haven't noticed
any such hardware". It turns out that such hardware does exist.
One such platform has RAM starting at 32GB with an internal bus that has
the following DMA limits:
#address-cells = <2>;
#size-cells = <2>;
dma-ranges = <0x00 0xc000 0x08 0x 0x00 0x4000>;
Devices under this bus can see 1GB of DMA range between 3GB-4GB in each
device address space. This range is mapped to CPU memory at 32GB-33GB.
With current code DMA allocations for devices under this bus are not
limited to DMA area, leading to run-time allocation failure.
Add start of RAM address to zone_dma_limit to make DMA allocation for
constrained devices possible.
The result is DMA zone that properly reflects the hardware constraints
as follows:
[0.00] Zone ranges:
[0.00] DMA [mem 0x0008-0x00083fff]
[0.00] DMA32empty
[0.00] Normal [mem 0x00084000-0x000b]
Rename the dma_direct_supported() local 'min_mask' variable to better
describe its use as limit.
Suggested-by: Catalin Marinas
Signed-off-by: Baruch Siach
---
kernel/dma/direct.c | 7 ---
kernel/dma/pool.c| 3 ++-
kernel/dma/swiotlb.c | 4 ++--
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 3dbc0b89d6fb..bd7972d3b101 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -563,7 +563,7 @@ int dma_direct_mmap(struct device *dev, struct
vm_area_struct *vma,
int dma_direct_supported(struct device *dev, u64 mask)
{
- u64 min_mask = (max_pfn - 1) << PAGE_SHIFT;
+ u64 min_limit = (max_pfn - 1) << PAGE_SHIFT;
/*
* Because 32-bit DMA masks are so common we expect every architecture
@@ -580,8 +580,9 @@ int dma_direct_supported(struct device *dev, u64 mask)
* part of the check.
*/
if (IS_ENABLED(CONFIG_ZONE_DMA))
- min_mask = min_t(u64, min_mask, zone_dma_limit);
- return mask >= phys_to_dma_unencrypted(dev, min_mask);
+ min_limit = min_t(u64, min_limit,
+ memblock_start_of_DRAM() + zone_dma_limit);
+ return mask >= phys_to_dma_unencrypted(dev, min_limit);
}
/*
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index 410a7b40e496..ded3d841c88c 100644
--- a/kernel/dma/pool.c
+++ b/kernel/dma/pool.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
static struct gen_pool *atomic_pool_dma __ro_after_init;
static unsigned long pool_size_dma;
@@ -70,7 +71,7 @@ static bool cma_in_zone(gfp_t gfp)
/* CMA can't cross zone boundaries, see cma_activate_area() */
end = cma_get_base(cma) + size - 1;
if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA))
- return end <= zone_dma_limit;
+ return end <= memblock_start_of_DRAM() + zone_dma_limit;
if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp & GFP_DMA32))
return end <= DMA_BIT_MASK(32);
return true;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index dfd83e5ee0b3..2813eeb8b375 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -450,7 +450,7 @@ int swiotlb_init_late(size_t size, gfp_t gfp_mask,
if (!remap)
io_tlb_default_mem.can_grow = true;
if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp_mask & __GFP_DMA))
- io_tlb_default_mem.phys_limit = zone_dma_limit;
+ io_tlb_default_mem.phys_limit = memblock_start_of_DRAM() +
zone_dma_limit;
else if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp_mask & __GFP_DMA32))
io_tlb_default_mem.phys_limit = DMA_BIT_MASK(32);
else
@@ -629,7 +629,7 @@ static struct page *swiotlb_alloc_tlb(struct device *dev,
size_t bytes,
}
gfp &= ~GFP_ZONEMASK;
- if (phys_limit <= zone_dma_limit)
+ if (phys_limit <= memblock_start_of_DRAM() + zone_dma_limit)
gfp |= __GFP_DMA;
else if (phys_limit <= DMA_BIT_MASK(32))
gfp |= __GFP_DMA32;
--
2.43.0
[PATCH v3 2/3] dma-mapping: replace zone_dma_bits by zone_dma_limit
From: Catalin Marinas
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
can not encode this limit.
Use direct phys_addr_t limit address for DMA zone limit.
Signed-off-by: Catalin Marinas
Signed-off-by: Baruch Siach
---
arch/arm64/mm/init.c | 34 +-
arch/powerpc/mm/mem.c | 9 -
arch/s390/mm/init.c| 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c| 4 ++--
kernel/dma/pool.c | 2 +-
kernel/dma/swiotlb.c | 4 ++--
7 files changed, 24 insertions(+), 33 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9b5ab6818f7f..870fd967c610 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -114,36 +114,28 @@ static void __init arch_reserve_crashkernel(void)
low_size, high);
}
-/*
- * Return the maximum physical address for a zone accessible by the given bits
- * limit. If DRAM starts above 32-bit, expand the zone to the maximum
- * available memory, otherwise cap it at 32-bit.
- */
-static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
+static phys_addr_t __init max_zone_phys(phys_addr_t zone_limit)
{
- phys_addr_t zone_mask = DMA_BIT_MASK(zone_bits);
- phys_addr_t phys_start = memblock_start_of_DRAM();
-
- if (phys_start > U32_MAX)
- zone_mask = PHYS_ADDR_MAX;
- else if (phys_start > zone_mask)
- zone_mask = U32_MAX;
+ /* We have RAM in low 32-bit area, keep DMA zone there */
+ if (memblock_start_of_DRAM() < U32_MAX)
+ zone_limit = min(U32_MAX, zone_limit);
- return min(zone_mask, memblock_end_of_DRAM() - 1) + 1;
+ return min(zone_limit, memblock_end_of_DRAM() - 1) + 1;
}
static void __init zone_sizes_init(void)
{
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
- unsigned int __maybe_unused acpi_zone_dma_bits;
- unsigned int __maybe_unused dt_zone_dma_bits;
- phys_addr_t __maybe_unused dma32_phys_limit = max_zone_phys(32);
+ phys_addr_t __maybe_unused acpi_zone_dma_limit;
+ phys_addr_t __maybe_unused dt_zone_dma_limit;
+ phys_addr_t __maybe_unused dma32_phys_limit =
+ max_zone_phys(DMA_BIT_MASK(32));
#ifdef CONFIG_ZONE_DMA
- acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address());
- dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
- zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits);
- arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
+ acpi_zone_dma_limit = acpi_iort_dma_get_max_cpu_address();
+ dt_zone_dma_limit = of_dma_get_max_cpu_address(NULL);
+ zone_dma_limit = min(dt_zone_dma_limit, acpi_zone_dma_limit);
+ arm64_dma_phys_limit = max_zone_phys(zone_dma_limit);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
#endif
#ifdef CONFIG_ZONE_DMA32
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index d325217ab201..342c006cc1b8 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -216,7 +216,7 @@ static int __init mark_nonram_nosave(void)
* everything else. GFP_DMA32 page allocations automatically fall back to
* ZONE_DMA.
*
- * By using 31-bit unconditionally, we can exploit zone_dma_bits to inform the
+ * By using 31-bit unconditionally, we can exploit zone_dma_limit to inform the
* generic DMA mapping code. 32-bit only devices (if not handled by an IOMMU
* anyway) will take a first dip into ZONE_NORMAL and get otherwise served by
* ZONE_DMA.
@@ -252,13 +252,12 @@ void __init paging_init(void)
* powerbooks.
*/
if (IS_ENABLED(CONFIG_PPC32))
- zone_dma_bits = 30;
+ zone_dma_limit = DMA_BIT_MASK(30);
else
- zone_dma_bits = 31;
+ zone_dma_limit = DMA_BIT_MASK(31);
#ifdef CONFIG_ZONE_DMA
- max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
- 1UL << (zone_dma_bits - PAGE_SHIFT));
+ max_zone_pfns[ZONE_DMA] = min(max_low_pfn, zone_dma_limit >>
PAGE_SHIFT);
#endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
#ifdef CONFIG_HIGHMEM
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index ddcd39ef4346..91fc2b91adfc 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -97,7 +97,7 @@ void __init paging_init(void)
vmem_map_init();
sparse_init();
- zone_dma_bits = 31;
+ zone_dma_limit = DMA_BIT_MASK(31);
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
max_zone_pfns[ZONE_DMA] = virt_to_pfn(MAX_DMA_ADDRESS);
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index edbe13d00776..98b7d8015043 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -12
Re: [PATCH RFC v2 2/5] of: get dma area lower limit
Hi Catalin,
On Tue, Jun 18 2024, Catalin Marinas wrote:
> On Tue, Apr 09, 2024 at 09:17:55AM +0300, Baruch Siach wrote:
>> of_dma_get_max_cpu_address() returns the highest CPU address that
>> devices can use for DMA. The implicit assumption is that all CPU
>> addresses below that limit are suitable for DMA. However the
>> 'dma-ranges' property this code uses also encodes a lower limit for DMA
>> that is potentially non zero.
>>
>> Rename to of_dma_get_cpu_limits(), and extend to retrieve also the lower
>> limit for the same 'dma-ranges' property describing the high limit.
>
> I don't understand the reason for the lower limit. The way the Linux
> zones work is that ZONE_DMA always starts from the start of the RAM. It
> doesn't matter whether it's 0 or not, you'd not allocate below the start
> of RAM anyway. If you have a device that cannot use the bottom of the
> RAM, it is pretty broken and not supported by Linux.
I won't argue with that assertion. My target system RAM happens to start
at that the lower end of devices DMA zone, so I'm fine with skipping
this patch.
Just curious. What is the inherent limitation that prevents Linux from
supporting DMA zone with lower limit above RAM start?
Thanks,
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[PATCH RFC v2 5/5] arm64: mm: take DMA zone offset into account
Commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation") made DMA/DMA32 zones span the entire RAM
when RAM starts above 32-bits. This breaks hardware with DMA area that
start above 32-bits. But the commit log says that "we haven't noticed
any such hardware". It turns out that such hardware does exist.
One such platform has RAM starting at 32GB with an internal bus that has
the following DMA limits:
#address-cells = <2>;
#size-cells = <2>;
dma-ranges = <0x00 0xc000 0x08 0x 0x00 0x4000>;
Devices under this bus can see 1GB of DMA range between 3GB-4GB in each
device address space. This range is mapped to CPU memory at 32GB-33GB.
With current code DMA allocations for devices under this bus are not
limited to DMA area, leading to run-time allocation failure.
Modify 'zone_dma_bits' calculation (via dt_zone_dma_bits) to only cover
the actual DMA area starting at 'zone_dma_off'. Use the newly introduced
'min' parameter of of_dma_get_cpu_limits() to set 'zone_dma_off'.
DMA32 zone is useless in this configuration, so make its limit the same
as the DMA zone when the lower DMA limit is higher than 32-bits.
The result is DMA zone that properly reflects the hardware constraints
as follows:
[0.00] Zone ranges:
[0.00] DMA [mem 0x0008-0x00083fff]
[0.00] DMA32empty
[0.00] Normal [mem 0x00084000-0x000b]
Suggested-by: Catalin Marinas
Signed-off-by: Baruch Siach
---
arch/arm64/mm/init.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 77e942ca578b..cd283ae0178d 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -128,9 +128,11 @@ static void __init zone_sizes_init(void)
#ifdef CONFIG_ZONE_DMA
acpi_zone_dma_limit = acpi_iort_dma_get_max_cpu_address();
- of_dma_get_cpu_limits(NULL, &dt_zone_dma_limit, NULL);
+ of_dma_get_cpu_limits(NULL, &dt_zone_dma_limit, &zone_dma_base);
zone_dma_limit = min(dt_zone_dma_limit, acpi_zone_dma_limit);
arm64_dma_phys_limit = max_zone_phys(zone_dma_limit);
+ if (zone_dma_base > U32_MAX)
+ dma32_phys_limit = arm64_dma_phys_limit;
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
#endif
#ifdef CONFIG_ZONE_DMA32
--
2.43.0
[PATCH RFC v2 1/5] dma-mapping: replace zone_dma_bits by zone_dma_limit
From: Catalin Marinas
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
can not encode this limit.
Use direct phys_addr_t limit address for DMA zone limit.
Following commits will add explicit base address to DMA zone.
---
Catalin,
This is taken almost verbatim from your email:
https://lore.kernel.org/all/zz2hnhjv3gdzu...@arm.com/
Would you provide your sign-off?
Thanks,
baruch
---
arch/arm64/mm/init.c | 32 ++--
arch/powerpc/mm/mem.c | 9 -
arch/s390/mm/init.c| 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c| 6 +++---
kernel/dma/pool.c | 2 +-
kernel/dma/swiotlb.c | 4 ++--
7 files changed, 22 insertions(+), 35 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 03efd86dce0a..00508c69ca9e 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -113,36 +113,24 @@ static void __init arch_reserve_crashkernel(void)
low_size, high);
}
-/*
- * Return the maximum physical address for a zone accessible by the given bits
- * limit. If DRAM starts above 32-bit, expand the zone to the maximum
- * available memory, otherwise cap it at 32-bit.
- */
-static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
+static phys_addr_t __init max_zone_phys(phys_addr_t zone_limit)
{
- phys_addr_t zone_mask = DMA_BIT_MASK(zone_bits);
- phys_addr_t phys_start = memblock_start_of_DRAM();
-
- if (phys_start > U32_MAX)
- zone_mask = PHYS_ADDR_MAX;
- else if (phys_start > zone_mask)
- zone_mask = U32_MAX;
-
- return min(zone_mask, memblock_end_of_DRAM() - 1) + 1;
+ return min(zone_limit, memblock_end_of_DRAM() - 1) + 1;
}
static void __init zone_sizes_init(void)
{
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
- unsigned int __maybe_unused acpi_zone_dma_bits;
- unsigned int __maybe_unused dt_zone_dma_bits;
- phys_addr_t __maybe_unused dma32_phys_limit = max_zone_phys(32);
+ phys_addr_t __maybe_unused acpi_zone_dma_limit;
+ phys_addr_t __maybe_unused dt_zone_dma_limit;
+ phys_addr_t __maybe_unused dma32_phys_limit =
+ max_zone_phys(DMA_BIT_MASK(32));
#ifdef CONFIG_ZONE_DMA
- acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address());
- dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
- zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits);
- arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
+ acpi_zone_dma_limit = acpi_iort_dma_get_max_cpu_address();
+ dt_zone_dma_limit = of_dma_get_max_cpu_address(NULL);
+ zone_dma_limit = min(dt_zone_dma_limit, acpi_zone_dma_limit);
+ arm64_dma_phys_limit = max_zone_phys(zone_dma_limit);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
#endif
#ifdef CONFIG_ZONE_DMA32
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 3a440004b97d..4d6f575fd354 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -214,7 +214,7 @@ static int __init mark_nonram_nosave(void)
* everything else. GFP_DMA32 page allocations automatically fall back to
* ZONE_DMA.
*
- * By using 31-bit unconditionally, we can exploit zone_dma_bits to inform the
+ * By using 31-bit unconditionally, we can exploit zone_dma_limit to inform the
* generic DMA mapping code. 32-bit only devices (if not handled by an IOMMU
* anyway) will take a first dip into ZONE_NORMAL and get otherwise served by
* ZONE_DMA.
@@ -250,13 +250,12 @@ void __init paging_init(void)
* powerbooks.
*/
if (IS_ENABLED(CONFIG_PPC32))
- zone_dma_bits = 30;
+ zone_dma_limit = DMA_BIT_MASK(30);
else
- zone_dma_bits = 31;
+ zone_dma_limit = DMA_BIT_MASK(31);
#ifdef CONFIG_ZONE_DMA
- max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
- 1UL << (zone_dma_bits - PAGE_SHIFT));
+ max_zone_pfns[ZONE_DMA] = min(max_low_pfn, zone_dma_limit >>
PAGE_SHIFT);
#endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
#ifdef CONFIG_HIGHMEM
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index f6391442c0c2..5feaa60933b7 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -95,7 +95,7 @@ void __init paging_init(void)
vmem_map_init();
sparse_init();
- zone_dma_bits = 31;
+ zone_dma_limit = DMA_BIT_MASK(31);
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
max_zone_pfns[ZONE_DMA] = virt_to_pfn(MAX_DMA_ADDRESS);
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 3eb3589ff43e..7cf76f1d3239 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -12,7 +12,7 @@
#include
#includ
[PATCH RFC v2 2/5] of: get dma area lower limit
of_dma_get_max_cpu_address() returns the highest CPU address that
devices can use for DMA. The implicit assumption is that all CPU
addresses below that limit are suitable for DMA. However the
'dma-ranges' property this code uses also encodes a lower limit for DMA
that is potentially non zero.
Rename to of_dma_get_cpu_limits(), and extend to retrieve also the lower
limit for the same 'dma-ranges' property describing the high limit.
Update callers of of_dma_get_max_cpu_address(). No functional change
intended.
Signed-off-by: Baruch Siach
---
arch/arm64/mm/init.c | 2 +-
drivers/of/address.c | 38 +++---
drivers/of/unittest.c | 8
include/linux/of.h| 11 ---
4 files changed, 40 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 00508c69ca9e..77e942ca578b 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -128,7 +128,7 @@ static void __init zone_sizes_init(void)
#ifdef CONFIG_ZONE_DMA
acpi_zone_dma_limit = acpi_iort_dma_get_max_cpu_address();
- dt_zone_dma_limit = of_dma_get_max_cpu_address(NULL);
+ of_dma_get_cpu_limits(NULL, &dt_zone_dma_limit, NULL);
zone_dma_limit = min(dt_zone_dma_limit, acpi_zone_dma_limit);
arm64_dma_phys_limit = max_zone_phys(zone_dma_limit);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
diff --git a/drivers/of/address.c b/drivers/of/address.c
index ae46a3605904..ac009b3bb63b 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -964,21 +964,25 @@ int of_dma_get_range(struct device_node *np, const struct
bus_dma_region **map)
#endif /* CONFIG_HAS_DMA */
/**
- * of_dma_get_max_cpu_address - Gets highest CPU address suitable for DMA
+ * of_dma_get_cpu_limits - Gets highest CPU address suitable for DMA
* @np: The node to start searching from or NULL to start from the root
+ * @max: Pointer to high address limit or NULL if not needed
+ * @min: Pointer to low address limit or NULL if not needed
*
* Gets the highest CPU physical address that is addressable by all DMA masters
- * in the sub-tree pointed by np, or the whole tree if NULL is passed. If no
- * DMA constrained device is found, it returns PHYS_ADDR_MAX.
+ * in the sub-tree pointed by np, or the whole tree if @np in NULL. If no
+ * DMA constrained device is found, @*max is PHYS_ADDR_MAX, and @*low is 0.
*/
-phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
+void __init of_dma_get_cpu_limits(struct device_node *np,
+ phys_addr_t *max, phys_addr_t *min)
{
phys_addr_t max_cpu_addr = PHYS_ADDR_MAX;
struct of_range_parser parser;
- phys_addr_t subtree_max_addr;
+ phys_addr_t min_cpu_addr = 0;
struct device_node *child;
struct of_range range;
const __be32 *ranges;
+ u64 cpu_start = 0;
u64 cpu_end = 0;
int len;
@@ -988,21 +992,33 @@ phys_addr_t __init of_dma_get_max_cpu_address(struct
device_node *np)
ranges = of_get_property(np, "dma-ranges", &len);
if (ranges && len) {
of_dma_range_parser_init(&parser, np);
- for_each_of_range(&parser, &range)
- if (range.cpu_addr + range.size > cpu_end)
+ for_each_of_range(&parser, &range) {
+ if (range.cpu_addr + range.size > cpu_end) {
cpu_end = range.cpu_addr + range.size - 1;
+ cpu_start = range.cpu_addr;
+ }
+ }
- if (max_cpu_addr > cpu_end)
+ if (max_cpu_addr > cpu_end) {
max_cpu_addr = cpu_end;
+ min_cpu_addr = cpu_start;
+ }
}
for_each_available_child_of_node(np, child) {
- subtree_max_addr = of_dma_get_max_cpu_address(child);
- if (max_cpu_addr > subtree_max_addr)
+ phys_addr_t subtree_max_addr, subtree_min_addr;
+
+ of_dma_get_cpu_limits(child, &subtree_max_addr,
&subtree_min_addr);
+ if (max_cpu_addr > subtree_max_addr) {
max_cpu_addr = subtree_max_addr;
+ min_cpu_addr = subtree_min_addr;
+ }
}
- return max_cpu_addr;
+ if (max)
+ *max = max_cpu_addr;
+ if (min)
+ *min = min_cpu_addr;
}
/**
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 6b5c36b6a758..2d632d4ec5b1 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -921,7 +921,7 @@ static void __init of_unittest_changeset(void)
#endif
}
-static void __init of_unittest_dma_get_max_cpu_address(void)
+static void __init of_unittest_dma_get_cpu_limits(void)
{
struct device_node *np;
phys_addr
[PATCH RFC v2 3/5] of: unittest: add test for of_dma_get_cpu_limits() 'min' param
Verify that of_dma_get_cpu_limits() sets this new parameter to the
expected result.
Signed-off-by: Baruch Siach
---
drivers/of/unittest.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 2d632d4ec5b1..8fabb445a62a 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -924,7 +924,7 @@ static void __init of_unittest_changeset(void)
static void __init of_unittest_dma_get_cpu_limits(void)
{
struct device_node *np;
- phys_addr_t cpu_addr;
+ phys_addr_t cpu_addr_max, cpu_addr_min;
if (!IS_ENABLED(CONFIG_OF_ADDRESS))
return;
@@ -935,10 +935,13 @@ static void __init of_unittest_dma_get_cpu_limits(void)
return;
}
- of_dma_get_cpu_limits(np, &cpu_addr, NULL);
- unittest(cpu_addr == 0x4fff,
-"of_dma_get_cpu_limits: wrong CPU addr %pad (expecting %x)\n",
-&cpu_addr, 0x4fff);
+ of_dma_get_cpu_limits(np, &cpu_addr_max, &cpu_addr_min);
+ unittest(cpu_addr_max == 0x4fff,
+"of_dma_get_cpu_limits: wrong CPU max addr %pad (expecting
%x)\n",
+&cpu_addr_max, 0x4fff);
+ unittest(cpu_addr_min == 0x4000,
+"of_dma_get_cpu_limits: wrong CPU min addr %pad (expecting
%x)\n",
+&cpu_addr_min, 0x4000);
}
static void __init of_unittest_dma_ranges_one(const char *path,
--
2.43.0
[PATCH RFC v2 4/5] dma-direct: add base offset to zone_dma_bits
Current code using zone_dma_bits assume that all addresses range in the
bits mask are suitable for DMA. For some existing platforms this
assumption is not correct. DMA range might have non zero lower limit.
Add 'zone_dma_base' for platform code to set base address for DMA zone.
Rename the dma_direct_supported() local 'min_mask' variable to better
describe its use as limit.
Suggested-by: Catalin Marinas
Signed-off-by: Baruch Siach
---
include/linux/dma-direct.h | 1 +
kernel/dma/direct.c| 9 +
kernel/dma/pool.c | 2 +-
kernel/dma/swiotlb.c | 4 ++--
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 7cf76f1d3239..dd0330cbef81 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -13,6 +13,7 @@
#include
extern phys_addr_t zone_dma_limit;
+extern phys_addr_t zone_dma_base;
/*
* Record the mapping of CPU physical to DMA addresses for a given region.
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 3b2ebcd4f576..92bb241645d6 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -21,6 +21,7 @@
* override the variable below for dma-direct to work properly.
*/
phys_addr_t zone_dma_limit __ro_after_init = DMA_BIT_MASK(24);
+phys_addr_t zone_dma_base __ro_after_init;
static inline dma_addr_t phys_to_dma_direct(struct device *dev,
phys_addr_t phys)
@@ -59,7 +60,7 @@ static gfp_t dma_direct_optimal_gfp_mask(struct device *dev,
u64 *phys_limit)
* zones.
*/
*phys_limit = dma_to_phys(dev, dma_limit);
- if (*phys_limit <= zone_dma_limit)
+ if (*phys_limit <= zone_dma_base + zone_dma_limit)
return GFP_DMA;
if (*phys_limit <= DMA_BIT_MASK(32))
return GFP_DMA32;
@@ -567,7 +568,7 @@ int dma_direct_mmap(struct device *dev, struct
vm_area_struct *vma,
int dma_direct_supported(struct device *dev, u64 mask)
{
- u64 min_mask = (max_pfn - 1) << PAGE_SHIFT;
+ u64 min_limit = (max_pfn - 1) << PAGE_SHIFT;
/*
* Because 32-bit DMA masks are so common we expect every architecture
@@ -584,8 +585,8 @@ int dma_direct_supported(struct device *dev, u64 mask)
* part of the check.
*/
if (IS_ENABLED(CONFIG_ZONE_DMA))
- min_mask = min_t(u64, min_mask, zone_dma_limit);
- return mask >= phys_to_dma_unencrypted(dev, min_mask);
+ min_limit = min_t(u64, min_limit, zone_dma_base +
zone_dma_limit);
+ return mask >= phys_to_dma_unencrypted(dev, min_limit);
}
/*
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index 410a7b40e496..61a86f3d83ae 100644
--- a/kernel/dma/pool.c
+++ b/kernel/dma/pool.c
@@ -70,7 +70,7 @@ static bool cma_in_zone(gfp_t gfp)
/* CMA can't cross zone boundaries, see cma_activate_area() */
end = cma_get_base(cma) + size - 1;
if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA))
- return end <= zone_dma_limit;
+ return end <= zone_dma_base + zone_dma_limit;
if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp & GFP_DMA32))
return end <= DMA_BIT_MASK(32);
return true;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 96d6eee7d215..814052df07c5 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -446,7 +446,7 @@ int swiotlb_init_late(size_t size, gfp_t gfp_mask,
if (!remap)
io_tlb_default_mem.can_grow = true;
if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp_mask & __GFP_DMA))
- io_tlb_default_mem.phys_limit = zone_dma_limit;
+ io_tlb_default_mem.phys_limit = zone_dma_base + zone_dma_limit;
else if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp_mask & __GFP_DMA32))
io_tlb_default_mem.phys_limit = DMA_BIT_MASK(32);
else
@@ -625,7 +625,7 @@ static struct page *swiotlb_alloc_tlb(struct device *dev,
size_t bytes,
}
gfp &= ~GFP_ZONEMASK;
- if (phys_limit <= zone_dma_limit)
+ if (phys_limit <= zone_dma_base + zone_dma_limit)
gfp |= __GFP_DMA;
else if (phys_limit <= DMA_BIT_MASK(32))
gfp |= __GFP_DMA32;
--
2.43.0
[PATCH RFC v2 0/5] arm64: support DMA zone starting above 4GB
DMA zones code assumes that DMA lower limit is zero. When there is no RAM
below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire
RAM[0].
The platform I have has RAM starting at 32GB. Devices with 30-bit DMA mask are
mapped to 1GB at the bottom of RAM, between 32GB - 33GB. A DMA zone over the
entire RAM breaks DMA allocation for these devices.
In response to a previous RFC hack[1] Catalin Marinas suggested to add a
separate offset value as base address for the DMA zone. This RFC series
attempts to implement that suggestion.
With this series applied, the DMA zone covers the right RAM range for my
platform.
RFC v2:
* Add patch from Catalin[2] changing zone_dma_bits to zone_dma_limit to
simplify subsequent patches
* Test on real hardware
RFC v1: https://lore.kernel.org/all/cover.1703683642.git.bar...@tkos.co.il/
[0] See commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation")
[1]
https://lore.kernel.org/all/9af8a19c3398e7dc09cfc1fbafed98d795d9f83e.1699464622.git.bar...@tkos.co.il/
[2] https://lore.kernel.org/all/zz2hnhjv3gdzu...@arm.com/
Baruch Siach (4):
of: get dma area lower limit
of: unittest: add test for of_dma_get_cpu_limits() 'min' param
dma-direct: add base offset to zone_dma_bits
arm64: mm: take DMA zone offset into account
Catalin Marinas (1):
dma-mapping: replace zone_dma_bits by zone_dma_limit
arch/arm64/mm/init.c | 34 --
arch/powerpc/mm/mem.c | 9 -
arch/s390/mm/init.c| 2 +-
drivers/of/address.c | 38 +++---
drivers/of/unittest.c | 17 ++---
include/linux/dma-direct.h | 3 ++-
include/linux/of.h | 11 ---
kernel/dma/direct.c| 11 ++-
kernel/dma/pool.c | 2 +-
kernel/dma/swiotlb.c | 4 ++--
10 files changed, 73 insertions(+), 58 deletions(-)
--
2.43.0
Re: [PATCH v3] watchdog: add SPDX identifiers for watchdog subsystem
Hi Marcus,
On Wed, Feb 21, 2018 at 01:27:34PM +0100, Marcus Folkesson wrote:
> - Add SPDX identifier
> - Remove boiler plate license text
> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
> license
>
> Signed-off-by: Marcus Folkesson
> Acked-by: Adam Thomson
> Acked-by: Charles Keepax
> Acked-by: Mans Rullgard
> Acked-by: Matthias Brugger
> Acked-by: Michal Simek
> Acked-by: Neil Armstrong
> Acked-by: Nicolas Ferre
> Acked-by: Thierry Reding
> Reviewed-by: Eric Anholt
[...]
> diff --git a/drivers/watchdog/digicolor_wdt.c
> b/drivers/watchdog/digicolor_wdt.c
> index 5e4ef93caa02..a9e11df155b8 100644
> --- a/drivers/watchdog/digicolor_wdt.c
> +++ b/drivers/watchdog/digicolor_wdt.c
> @@ -1,12 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0+
> /*
> * Watchdog driver for Conexant Digicolor
> *
> * Copyright (C) 2015 Paradox Innovation Ltd.
> *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License as published by the
> - * Free Software Foundation; either version 2 of the License, or (at your
> - * option) any later version.
> */
For digicolor_wdt.c:
Acked-by: Baruch Siach
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
Re: [PATCH 1/9] mm: Hardened usercopy
Hi Kees,
On Thu, Jul 07, 2016 at 01:25:21PM -0400, Kees Cook wrote:
> On Thu, Jul 7, 2016 at 1:37 AM, Baruch Siach wrote:
> > On Wed, Jul 06, 2016 at 03:25:20PM -0700, Kees Cook wrote:
> >> +#ifdef CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR
> >
> > Should be CONFIG_HARDENED_USERCOPY to match the slab/slub implementation
> > condition.
> >
> >> +const char *__check_heap_object(const void *ptr, unsigned long n,
> >> + struct page *page);
> >> +#else
> >> +static inline const char *__check_heap_object(const void *ptr,
> >> + unsigned long n,
> >> + struct page *page)
> >> +{
> >> + return NULL;
> >> +}
> >> +#endif
>
> Hmm, I think what I have is correct: if the allocator supports the
> heap object checking, it defines __check_heap_object as existing via
> CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR. If usercopy checking is done
> at all is controlled by CONFIG_HARDENED_USERCOPY.
>
> I.e. you can have the other usercopy checks even if your allocator
> doesn't support object size checking.
Right. I missed the fact that usercopy.c build also depends on
CONFIG_HARDENED_USERCOPY. Sorry for the noise.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9] mm: Hardened usercopy
Hi Kees,
On Wed, Jul 06, 2016 at 03:25:20PM -0700, Kees Cook wrote:
> +#ifdef CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR
Should be CONFIG_HARDENED_USERCOPY to match the slab/slub implementation
condition.
> +const char *__check_heap_object(const void *ptr, unsigned long n,
> + struct page *page);
> +#else
> +static inline const char *__check_heap_object(const void *ptr,
> + unsigned long n,
> + struct page *page)
> +{
> + return NULL;
> +}
> +#endif
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi: add "spi-lsb-first" to devicetree
Hi Zhao Qiang,
On Tue, Apr 01, 2014 at 03:55:31PM +0800, Zhao Qiang wrote:
> add optional property devicetree for SPI slave nodes
> into devicetree so that LSB mode can be enabled by devicetree.
>
> Signed-off-by: Zhao Qiang
> ---
> Documentation/devicetree/bindings/spi/spi-bus.txt | 4
> drivers/spi/spi.c | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt
> b/Documentation/devicetree/bindings/spi/spi-bus.txt
> index e5a4d1b..fdd9f15 100644
> --- a/Documentation/devicetree/bindings/spi/spi-bus.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
> @@ -55,11 +55,15 @@ contain the following properties.
> chip select active high
> - spi-3wire - (optional) Empty property indicating device requires
> 3-wire mode.
> +- spi-lsb-first - (optional) Empty property indicating device requires
> + LSB first mode.
> - spi-tx-bus-width - (optional) The bus width(number of data wires) that
>used for MOSI. Defaults to 1 if not present.
> - spi-rx-bus-width - (optional) The bus width(number of data wires) that
>used for MISO. Defaults to 1 if not present.
>
> +- spi-rx-bus-width - (optional) The bus width(number of data wires) that
> + used for MISO. Defaults to 1 if not present.
Is this part intentionally here? It is not mentioned in the commit log, and
seems to merit a separate patch.
baruch
> Some SPI controllers and devices support Dual and Quad SPI transfer mode.
> It allows data in SPI system transfered in 2 wires(DUAL) or 4 wires(QUAD).
> Now the value that spi-tx-bus-width and spi-rx-bus-width can receive is
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 23756b0..0a20a90 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1050,6 +1050,8 @@ static void of_register_spi_devices(struct spi_master
> *master)
> spi->mode |= SPI_CS_HIGH;
> if (of_find_property(nc, "spi-3wire", NULL))
> spi->mode |= SPI_3WIRE;
> + if (of_find_property(nc, "spi-lsb-first", NULL))
> + spi->mode |= SPI_LSB_FIRST;
>
> /* Device DUAL/QUAD mode */
> if (!of_property_read_u32(nc, "spi-tx-bus-width", &value)) {
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUG] irq_dispose_mapping after irq request failure
Hi Michael,
On Mon, Feb 11, 2013 at 05:19:49PM +1100, Michael Ellerman wrote:
> On Mon, Feb 11, 2013 at 07:31:00AM +0200, Baruch Siach wrote:
[...]
> > mpc85xx_pci_err_probe: Unable to requiest irq 16 for MPC85xx PCI err
> While you're there, can you fix the typo :)
The patch fixing it is already queued at
http://git.kernel.org/?p=linux/kernel/git/bp/bp.git;a=commitdiff;h=e7d2c215e56dc9fa0a01e26f2acfc3d73c889ba3.
Thanks for your details explanation. I'll now try to figure out what's wrong
with my device tree.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[BUG] irq_dispose_mapping after irq request failure
Hi lkml,
The drivers/edac/mpc85xx_edac.c driver contains the following (abbreviated)
code snippet it its .probe:
res = devm_request_irq(&op->dev, pdata->irq,
mpc85xx_pci_isr, IRQF_DISABLED,
"[EDAC] PCI err", pci);
if (res < 0) {
irq_dispose_mapping(pdata->irq);
goto err2;
}
Now, since the requested irq is already in use, and IRQF_SHARED is not set,
devm_request_irq errors() out, which is OK. Less OK is the
irq_dispose_mapping() call, which gives me this:
EDAC PCI1: Giving out device to module 'MPC85xx_edac' controller
'mpc85xx_pci_err': DEV 'ffe0a000.pcie' (INTERRUPT)
genirq: Flags mismatch irq 16. 0020 ([EDAC] PCI err) vs. 0020 ([EDAC]
PCI err)
mpc85xx_pci_err_probe: Unable to requiest irq 16 for MPC85xx PCI err
remove_proc_entry: removing non-empty directory 'irq/16', leaking at least
'[EDAC] PCI err'
[ cut here ]
WARNING: at fs/proc/generic.c:842
NIP: c00cd00c LR: c00cd00c CTR: c000c5e4
REGS: cf039b80 TRAP: 0700 Not tainted (3.8.0-rc7-2-g37ddebf)
MSR: 00029000 CR: 42042422 XER:
TASK = cf034000[1] 'swapper' THREAD: cf038000
GPR00: c00cd00c cf039c30 cf034000 005b 005c 005c c04b7dde 435d2050
GPR08: 43492065 c04a9a44 cf039bf0 22042424 c00025d0
GPR16: c042fe78
GPR24: c04c3f90 cf05294c 00100100 00200200 cf039c78 cf052900
NIP [c00cd00c] remove_proc_entry+0x190/0x1bc
LR [c00cd00c] remove_proc_entry+0x190/0x1bc
Call Trace:
[cf039c30] [c00cd00c] remove_proc_entry+0x190/0x1bc (unreliable)
[cf039c70] [c0058c64] unregister_irq_proc+0x6c/0x74
[cf039c90] [c0054530] free_desc+0x34/0x68
[cf039cb0] [c00545f0] irq_free_descs+0x44/0x88
[cf039cd0] [c00585c8] irq_dispose_mapping+0x68/0x70
[cf039ce0] [c0222650] mpc85xx_pci_err_probe+0x2a8/0x308
[cf039d20] [c0014f8c] fsl_pci_probe+0x74/0x80
[cf039d30] [c01a9c48] platform_drv_probe+0x20/0x30
[cf039d40] [c01a88c4] driver_probe_device+0xcc/0x1f4
[cf039d60] [c01a7288] bus_for_each_drv+0x60/0x9c
[cf039d90] [c01a85ac] device_attach+0x78/0x90
[cf039db0] [c01a7430] bus_probe_device+0x34/0x9c
[cf039dd0] [c01a55c4] device_add+0x410/0x580
[cf039e10] [c022eef4] of_device_add+0x40/0x50
[cf039e20] [c022f550] of_platform_device_create_pdata+0x6c/0x8c
[cf039e40] [c022f658] of_platform_bus_create+0xe8/0x178
[cf039e90] [c022f7a0] of_platform_bus_probe+0xac/0xdc
[cf039eb0] [c0415488] mpc85xx_common_publish_devices+0x20/0x30
[cf039ec0] [c0415578]
__machine_initcall_p1020_rdb_mpc85xx_common_publish_devices+0x2c/0x3c
[cf039ed0] [c040e83c] do_one_initcall+0xdc/0x1b4
[cf039f00] [c040ea24] kernel_init_freeable+0x110/0x1a8
[cf039f30] [c00025e8] kernel_init+0x18/0xf8
[cf039f40] [c000b868] ret_from_kernel_thread+0x64/0x6c
Instruction dump:
2f87 41be0030 80bf002c 3c80c033 3c60c03e 38846be0 38840260 38a50055
38df0055 38e70055 38631770 48260331 <0fe0> 7fe3fb78 4bfffb41 4818
---[ end trace 9af370ce0e147530 ]---
So, is irq_dispose_mapping() the right thing to do when irq request fails?
A simple grep shows that irq_dispose_mapping() calls are mostly limited to
powerpc code. Is there a reason for that?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: fix build when CONFIG_BOOKE_WDT is enabled
Commit ae3a197e (Disintegrate asm/system.h for PowerPC) broke build of assembly files when CONFIG_BOOKE_WDT is enabled as follows: AS arch/powerpc/lib/string.o /home/baruch/git/stable/arch/powerpc/include/asm/reg_booke.h: Assembler messages: /home/baruch/git/stable/arch/powerpc/include/asm/reg_booke.h:19: Error: Unrecognized opcode: `extern' /home/baruch/git/stable/arch/powerpc/include/asm/reg_booke.h:20: Error: Unrecognized opcode: `extern' Since setup_32.c is the only user of the booke_wdt configuration variables, move the declarations there. Cc: David Howells Signed-off-by: Baruch Siach --- arch/powerpc/include/asm/reg_booke.h |5 - arch/powerpc/kernel/setup_32.c |5 + 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h index b86faa9..8a97aa7 100644 --- a/arch/powerpc/include/asm/reg_booke.h +++ b/arch/powerpc/include/asm/reg_booke.h @@ -15,11 +15,6 @@ #ifndef __ASM_POWERPC_REG_BOOKE_H__ #define __ASM_POWERPC_REG_BOOKE_H__ -#ifdef CONFIG_BOOKE_WDT -extern u32 booke_wdt_enabled; -extern u32 booke_wdt_period; -#endif /* CONFIG_BOOKE_WDT */ - /* Machine State Register (MSR) Fields */ #define MSR_GS (1<<28) /* Guest state */ #define MSR_UCLE (1<<26) /* User-mode cache lock enable */ diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c index 9825f29..a9b8be5 100644 --- a/arch/powerpc/kernel/setup_32.c +++ b/arch/powerpc/kernel/setup_32.c @@ -61,6 +61,11 @@ unsigned long vgacon_remap_base; EXPORT_SYMBOL(vgacon_remap_base); #endif +#ifdef CONFIG_BOOKE_WDT +extern u32 booke_wdt_enabled; +extern u32 booke_wdt_period; +#endif /* CONFIG_BOOKE_WDT */ + /* * These are used in binfmt_elf.c to put aux entries on the stack * for each elf executable being started. -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] of/mdio: fix fixed link bus name
Since 9e6c643b (phy/fixed: use an unique MDIO bus name) the name of the fixed PHY bus is "fixed-0". Teach of_phy_connect_fixed_link() the new name. Tested on a P1020RDB PowerPC system. Signed-off-by: Baruch Siach --- drivers/of/of_mdio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c index 980c079..483c0ad 100644 --- a/drivers/of/of_mdio.c +++ b/drivers/of/of_mdio.c @@ -182,7 +182,7 @@ struct phy_device *of_phy_connect_fixed_link(struct net_device *dev, if (!phy_id || sz < sizeof(*phy_id)) return NULL; - sprintf(bus_id, PHY_ID_FMT, "0", be32_to_cpu(phy_id[0])); + sprintf(bus_id, PHY_ID_FMT, "fixed-0", be32_to_cpu(phy_id[0])); phy = phy_connect(dev, bus_id, hndlr, 0, iface); return IS_ERR(phy) ? NULL : phy; -- 1.7.9 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: fsl_pq_mdio: fix non tbi phy access
Hi Andy,
On Tue, Nov 15, 2011 at 09:06:03AM -0600, Andy Fleming wrote:
> On Nov 14, 2011, at 11:17 PM, Baruch Siach wrote:
> > On Mon, Nov 14, 2011 at 09:04:47PM +, Fleming Andy-AFLEMING wrote:
[snip]
> >> And looking at the p1010si.dtsi, I see that it's automatically there for
> >> you.
> >>
> >> How were you breaking?
> >
> > Adding linuxppc to Cc.
> >
> > My board is P1011 based, the single core version of P1020, not P1010. In
> > p1020si.dtsi I see no tbi node. In p1020rdb.dts I see a tbi node but only
> > for
> > mdio@25000, not mdio@24000, which is what I'm using.
> >
> > Am I missing something?
>
> Well, that's a bug. In truth, the silicon dtsi trees should not have tbi
> nodes, as that's highly machine-specific. The p1020rdb is apparently relying
> on the old behavior, which is broken, and due to the fact that the first
> ethernet interface doesn't *use* the TBI PHY.
>
> You should add this to your board tree:
>
> mdio@24000 {
>
> tbi0: tbi-phy@11 {
> reg = <0x11>;
> device_type = "tbi-phy";
> };
> };
>
> And add the PHYs you use, as well as set reg (and the value after the "@")
> to something that makes sense for your board.
Thanks for your detailed explanation and prompt response. I've added a tbi
node, dropped my patch, and now my board works as expected.
> I am going to go right now, and add tbi nodes for all of the Freescale
> platforms. I will also modify the fsl_pq_mdio code to be more explicit about
> its reason for failure.
Please Cc me on these.
Thanks,
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: fsl_pq_mdio: fix non tbi phy access
Hi Andy,
On Mon, Nov 14, 2011 at 09:04:47PM +, Fleming Andy-AFLEMING wrote:
> Well, this got applied quickly, so I guess I can't NAK, but this requires
> discussion.
>
> On Nov 14, 2011, at 0:22, "Baruch Siach" wrote:
>
> > Since 952c5ca1 (fsl_pq_mdio: Clean up tbi address configuration) .probe
> > returns
> > -EBUSY when the "tbi-phy" node is missing. Fix this.
>
> It returns an error because it finds no tbi node. Because without the tbi
> node, there is no way for the driver to determine which address to set.
>
> Your solution is to ignore the error, and hope. That's a broken approach.
> The real solution for a p1010 should be to have a tbi node in the dts.
Can you elaborate a bit on why this approach is broken? The PHY used to work
for me until 952c5ca1, and with this applied.
> And looking at the p1010si.dtsi, I see that it's automatically there for
> you.
>
> How were you breaking?
Adding linuxppc to Cc.
My board is P1011 based, the single core version of P1020, not P1010. In
p1020si.dtsi I see no tbi node. In p1020rdb.dts I see a tbi node but only for
mdio@25000, not mdio@24000, which is what I'm using.
Am I missing something?
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4] powerpc: 85xx: separate e500 from e500mc
CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus breaking clear_pages(), probably others too. This patch adds a new "Processor Type" entry for e500mc, and makes e500 systems depend on PPC_E500_V1_V2. Cc: Kumar Gala Signed-off-by: Baruch Siach --- Changes from v3: * Rebase on 3.2-rc1 (add P3060_QDS) Changes from v2: * s/CONFIG_PPC_E500/CONFIG_PPC_E500_V1_V2/ as suggested by Scott Wood Changes from v1: * Rebase on 3.1-rc1 * Remove the list of processor families from the PPC_E500 and PPC_E500MC options description. The P20xx can be either e500v2 or e500mc. arch/powerpc/platforms/85xx/Kconfig| 14 +- arch/powerpc/platforms/Kconfig.cputype | 27 +++ 2 files changed, 24 insertions(+), 17 deletions(-) diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index 45023e2..cfa2bc9 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -13,6 +13,8 @@ if FSL_SOC_BOOKE if PPC32 +if PPC_E500_V1_V2 + config MPC8540_ADS bool "Freescale MPC8540 ADS" select DEFAULT_UIMAGE @@ -171,10 +173,13 @@ config SBC8560 help This option enables support for the Wind River SBC8560 board +endif # PPC_E500_V1_V2 + +if PPC_E500MC + config P2041_RDB bool "Freescale P2041 RDB" select DEFAULT_UIMAGE - select PPC_E500MC select PHYS_64BIT select SWIOTLB select ARCH_REQUIRE_GPIOLIB @@ -187,7 +192,6 @@ config P2041_RDB config P3041_DS bool "Freescale P3041 DS" select DEFAULT_UIMAGE - select PPC_E500MC select PHYS_64BIT select SWIOTLB select ARCH_REQUIRE_GPIOLIB @@ -200,7 +204,6 @@ config P3041_DS config P3060_QDS bool "Freescale P3060 QDS" select DEFAULT_UIMAGE - select PPC_E500MC select PHYS_64BIT select SWIOTLB select MPC8xxx_GPIO @@ -212,7 +215,6 @@ config P3060_QDS config P4080_DS bool "Freescale P4080 DS" select DEFAULT_UIMAGE - select PPC_E500MC select PHYS_64BIT select SWIOTLB select ARCH_REQUIRE_GPIOLIB @@ -222,13 +224,15 @@ config P4080_DS help This option enables support for the P4080 DS board +endif # PPC_E500MC + endif # PPC32 config P5020_DS bool "Freescale P5020 DS" + depends on PPC_E500MC select DEFAULT_UIMAGE select E500 - select PPC_E500MC select PHYS_64BIT select SWIOTLB select ARCH_REQUIRE_GPIOLIB diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index fbecae0..e08d1e3 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -10,13 +10,13 @@ choice prompt "Processor Type" depends on PPC32 help - There are five families of 32 bit PowerPC chips supported. + There are six families of 32 bit PowerPC chips supported. The most common ones are the desktop and server CPUs (601, 603, 604, 740, 750, 74xx) CPUs from Freescale and IBM, with their embedded 512x/52xx/82xx/83xx/86xx counterparts. - The other embeeded parts, namely 4xx, 8xx, e200 (55xx) and e500 - (85xx) each form a family of their own that is not compatible - with the others. + The other embedded parts, namely 4xx, 8xx, e200 (55xx), e500 + (85xx), and e500mc each form a family of their own that is not + compatible with the others. If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx. @@ -24,10 +24,15 @@ config PPC_BOOK3S_32 bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx" select PPC_FPU -config PPC_85xx - bool "Freescale 85xx" +config PPC_E500_V1_V2 + bool "Freescale e500v1/e500v2" + select PPC_85xx select E500 +config PPC_E500MC + bool "Freescale e500mc/e5500" + select PPC_85xx + config PPC_8xx bool "Freescale 8xx" select FSL_SOC @@ -129,15 +134,13 @@ config TUNE_CELL config 8xx bool -config E500 +config PPC_85xx + bool select FSL_EMB_PERFMON select PPC_FSL_BOOK3E - bool -config PPC_E500MC - bool "e500mc Support" - select PPC_FPU - depends on E500 +config E500 + bool config PPC_FPU bool -- 1.7.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] net: fsl_pq_mdio: fix oops when using uninitialized mutex
The get_phy_id() routine (called via fsl_pq_mdio_find_free()) tries to acquire
the mdio_lock mutex which is only initialized when of_mdiobus_register() gets
called later. This causes the following oops:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc02eda74
Oops: Kernel access of bad area, sig: 11 [#1]
P1020 RDB
NIP: c02eda74 LR: c01b3aa4 CTR: 0007
REGS: cf039d70 TRAP: 0300 Not tainted (3.2.0-rc1-4-gdc9d867-dirty)
MSR: 00029000 CR: 24024028 XER:
DEAR: , ESR: 0080
TASK = cf034000[1] 'swapper' THREAD: cf038000
GPR00: cf039e28 cf039e20 cf034000 cf368228 0020 0002 ffeb02ad 00d0
GPR08: 1083 d108 cf039e90 100ae780
GPR16: c900 0012 0fff 00ffa000 0015 0001 c047
GPR24: c03b4e89 d1072030 cf034000 0020 cf36822c cf368228
NIP [c02eda74] __mutex_lock_slowpath+0x30/0xb0
LR [c01b3aa4] mdiobus_read+0x38/0x68
Call Trace:
[cf039e20] [ffeb] 0xffeb (unreliable)
[cf039e50] [c01b3aa4] mdiobus_read+0x38/0x68
[cf039e70] [c01b2af0] get_phy_id+0x24/0x70
[cf039e90] [c01b4128] fsl_pq_mdio_probe+0x364/0x414
[cf039ec0] [c0195050] platform_drv_probe+0x20/0x30
[cf039ed0] [c0193a70] driver_probe_device+0xc8/0x170
[cf039ef0] [c0193b88] __driver_attach+0x70/0x98
[cf039f10] [c019294c] bus_for_each_dev+0x60/0x90
[cf039f40] [c0193cc8] driver_attach+0x24/0x34
[cf039f50] [c0192f88] bus_add_driver+0xbc/0x230
[cf039f70] [c0194594] driver_register+0xb8/0x13c
[cf039f90] [c0195b40] platform_driver_register+0x6c/0x7c
[cf039fa0] [c03e433c] fsl_pq_mdio_init+0x18/0x28
[cf039fb0] [c03ce824] do_one_initcall+0xdc/0x1b4
[cf039fe0] [c03ce984] kernel_init+0x88/0x118
[cf039ff0] [c000bd5c] kernel_thread+0x4c/0x68
Instruction dump:
9421ffd0 7c0802a6 81230008 bf61001c 3bc30004 7c7f1b78 90010034 38010008
7c5c1378 90030008 93c10008 9121000c
3800 90410010 7d201828
Fix this by moving the of_mdiobus_register() call earlier.
Cc: Andy Fleming
Signed-off-by: Baruch Siach
---
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
index 52f4e8a..e17fd2f 100644
--- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
+++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
@@ -385,6 +385,13 @@ static int fsl_pq_mdio_probe(struct platform_device *ofdev)
tbiaddr = *prop;
}
+ err = of_mdiobus_register(new_bus, np);
+ if (err) {
+ printk (KERN_ERR "%s: Cannot register as MDIO bus\n",
+ new_bus->name);
+ goto err_free_irqs;
+ }
+
if (tbiaddr == -1) {
out_be32(tbipa, 0);
@@ -403,13 +410,6 @@ static int fsl_pq_mdio_probe(struct platform_device *ofdev)
out_be32(tbipa, tbiaddr);
- err = of_mdiobus_register(new_bus, np);
- if (err) {
- printk (KERN_ERR "%s: Cannot register as MDIO bus\n",
- new_bus->name);
- goto err_free_irqs;
- }
-
return 0;
err_free_irqs:
--
1.7.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc: 85xx: separate e500 from e500mc
Hi Kumar,
On Wed, Aug 10, 2011 at 08:21:18AM +0300, Baruch Siach wrote:
> CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
> breaking clear_pages(), probably others too.
>
> This patch adds a new "Processor Type" entry for e500mc, and makes e500
> systems
> depend on PPC_E500_V1_V2.
Ping.
Any chance of merging this for 3.2?
baruch
> Cc: Kumar Gala
> Signed-off-by: Baruch Siach
> ---
>
> Changes from v2:
>
> * s/CONFIG_PPC_E500/CONFIG_PPC_E500_V1_V2/ to avoid confusion as
> noted by Scott Wood
>
> Changes from v1:
>
> * Rebase on 3.1-rc1
>
> * Remove the list of processor families from the PPC_E500 and
> PPC_E500MC options description. The P20xx can be either e500v2 or
> e500mc.
>
> arch/powerpc/platforms/85xx/Kconfig| 13 +
> arch/powerpc/platforms/Kconfig.cputype | 27 +++
> 2 files changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/Kconfig
> b/arch/powerpc/platforms/85xx/Kconfig
> index 498534c..00d4720 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -13,6 +13,8 @@ if FSL_SOC_BOOKE
>
> if PPC32
>
> +if PPC_E500_V1_V2
> +
> config MPC8540_ADS
> bool "Freescale MPC8540 ADS"
> select DEFAULT_UIMAGE
> @@ -171,10 +173,13 @@ config SBC8560
> help
> This option enables support for the Wind River SBC8560 board
>
> +endif # PPC_E500_V1_V2
> +
> +if PPC_E500MC
> +
> config P2040_RDB
> bool "Freescale P2040 RDB"
> select DEFAULT_UIMAGE
> - select PPC_E500MC
> select PHYS_64BIT
> select SWIOTLB
> select MPC8xxx_GPIO
> @@ -186,7 +191,6 @@ config P2040_RDB
> config P3041_DS
> bool "Freescale P3041 DS"
> select DEFAULT_UIMAGE
> - select PPC_E500MC
> select PHYS_64BIT
> select SWIOTLB
> select MPC8xxx_GPIO
> @@ -198,7 +202,6 @@ config P3041_DS
> config P4080_DS
> bool "Freescale P4080 DS"
> select DEFAULT_UIMAGE
> - select PPC_E500MC
> select PHYS_64BIT
> select SWIOTLB
> select MPC8xxx_GPIO
> @@ -207,13 +210,15 @@ config P4080_DS
> help
> This option enables support for the P4080 DS board
>
> +endif # PPC_E500MC
> +
> endif # PPC32
>
> config P5020_DS
> bool "Freescale P5020 DS"
> + depends on PPC_E500MC
> select DEFAULT_UIMAGE
> select E500
> - select PPC_E500MC
> select PHYS_64BIT
> select SWIOTLB
> select MPC8xxx_GPIO
> diff --git a/arch/powerpc/platforms/Kconfig.cputype
> b/arch/powerpc/platforms/Kconfig.cputype
> index e06e395..e6cb00c 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -10,13 +10,13 @@ choice
> prompt "Processor Type"
> depends on PPC32
> help
> - There are five families of 32 bit PowerPC chips supported.
> + There are six families of 32 bit PowerPC chips supported.
> The most common ones are the desktop and server CPUs (601, 603,
> 604, 740, 750, 74xx) CPUs from Freescale and IBM, with their
> embedded 512x/52xx/82xx/83xx/86xx counterparts.
> - The other embeeded parts, namely 4xx, 8xx, e200 (55xx) and e500
> - (85xx) each form a family of their own that is not compatible
> - with the others.
> + The other embeeded parts, namely 4xx, 8xx, e200 (55xx), e500
> + (85xx), and e500mc each form a family of their own that is not
> + compatible with the others.
>
> If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx.
>
> @@ -24,10 +24,15 @@ config PPC_BOOK3S_32
> bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx"
> select PPC_FPU
>
> -config PPC_85xx
> - bool "Freescale 85xx"
> +config PPC_E500_V1_V2
> + bool "Freescale e500v1/e500v2"
> + select PPC_85xx
> select E500
>
> +config PPC_E500MC
> + bool "Freescale e500mc/e5500"
> + select PPC_85xx
> +
> config PPC_8xx
> bool "Freescale 8xx"
> select FSL_SOC
> @@ -128,15 +133,13 @@ config TUNE_CELL
> config 8xx
> bool
>
> -config E500
> +config PPC_85xx
> + bool
> select FSL_EMB_PERFMON
> select PPC_FSL_BOOK3E
> - bool
>
> -config PPC_E500MC
> - bool "e500mc Support"
> - select PPC_FPU
> - depends on E500
> +config E500
> + bool
>
> config PPC_FPU
> bool
> --
> 1.7.5.4
>
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] powerpc: 85xx: separate e500 from e500mc
CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus breaking clear_pages(), probably others too. This patch adds a new "Processor Type" entry for e500mc, and makes e500 systems depend on PPC_E500_V1_V2. Cc: Kumar Gala Signed-off-by: Baruch Siach --- Changes from v2: * s/CONFIG_PPC_E500/CONFIG_PPC_E500_V1_V2/ to avoid confusion as noted by Scott Wood Changes from v1: * Rebase on 3.1-rc1 * Remove the list of processor families from the PPC_E500 and PPC_E500MC options description. The P20xx can be either e500v2 or e500mc. arch/powerpc/platforms/85xx/Kconfig| 13 + arch/powerpc/platforms/Kconfig.cputype | 27 +++ 2 files changed, 24 insertions(+), 16 deletions(-) diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index 498534c..00d4720 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -13,6 +13,8 @@ if FSL_SOC_BOOKE if PPC32 +if PPC_E500_V1_V2 + config MPC8540_ADS bool "Freescale MPC8540 ADS" select DEFAULT_UIMAGE @@ -171,10 +173,13 @@ config SBC8560 help This option enables support for the Wind River SBC8560 board +endif # PPC_E500_V1_V2 + +if PPC_E500MC + config P2040_RDB bool "Freescale P2040 RDB" select DEFAULT_UIMAGE - select PPC_E500MC select PHYS_64BIT select SWIOTLB select MPC8xxx_GPIO @@ -186,7 +191,6 @@ config P2040_RDB config P3041_DS bool "Freescale P3041 DS" select DEFAULT_UIMAGE - select PPC_E500MC select PHYS_64BIT select SWIOTLB select MPC8xxx_GPIO @@ -198,7 +202,6 @@ config P3041_DS config P4080_DS bool "Freescale P4080 DS" select DEFAULT_UIMAGE - select PPC_E500MC select PHYS_64BIT select SWIOTLB select MPC8xxx_GPIO @@ -207,13 +210,15 @@ config P4080_DS help This option enables support for the P4080 DS board +endif # PPC_E500MC + endif # PPC32 config P5020_DS bool "Freescale P5020 DS" + depends on PPC_E500MC select DEFAULT_UIMAGE select E500 - select PPC_E500MC select PHYS_64BIT select SWIOTLB select MPC8xxx_GPIO diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index e06e395..e6cb00c 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -10,13 +10,13 @@ choice prompt "Processor Type" depends on PPC32 help - There are five families of 32 bit PowerPC chips supported. + There are six families of 32 bit PowerPC chips supported. The most common ones are the desktop and server CPUs (601, 603, 604, 740, 750, 74xx) CPUs from Freescale and IBM, with their embedded 512x/52xx/82xx/83xx/86xx counterparts. - The other embeeded parts, namely 4xx, 8xx, e200 (55xx) and e500 - (85xx) each form a family of their own that is not compatible - with the others. + The other embeeded parts, namely 4xx, 8xx, e200 (55xx), e500 + (85xx), and e500mc each form a family of their own that is not + compatible with the others. If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx. @@ -24,10 +24,15 @@ config PPC_BOOK3S_32 bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx" select PPC_FPU -config PPC_85xx - bool "Freescale 85xx" +config PPC_E500_V1_V2 + bool "Freescale e500v1/e500v2" + select PPC_85xx select E500 +config PPC_E500MC + bool "Freescale e500mc/e5500" + select PPC_85xx + config PPC_8xx bool "Freescale 8xx" select FSL_SOC @@ -128,15 +133,13 @@ config TUNE_CELL config 8xx bool -config E500 +config PPC_85xx + bool select FSL_EMB_PERFMON select PPC_FSL_BOOK3E - bool -config PPC_E500MC - bool "e500mc Support" - select PPC_FPU - depends on E500 +config E500 + bool config PPC_FPU bool -- 1.7.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: 85xx: separate e500 from e500mc
Hi Scott,
On Mon, Aug 08, 2011 at 02:42:52PM -0500, Scott Wood wrote:
> On 08/08/2011 04:07 AM, Baruch Siach wrote:
> > CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6,
> > thus
> > breaking clear_pages(), probably others too.
> >
> > This patch adds a new "Processor Type" entry for e500mc, and makes e500
> > systems
> > depend on PPC_E500.
>
> I can see confusion coming from having CONFIG_E500 and CONFIG_PPC_E500...
I agree.
> Maybe CONFIG_PPC_E500V1_2? Or CONFIG_PPC_E500V2, with a note in the
> kconfig help that it supports e500v1 as well.
I'll go for CONFIG_PPC_E500_V1_V2. A revised patch is on the way.
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc: 85xx: separate e500 from e500mc
CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus breaking clear_pages(), probably others too. This patch adds a new "Processor Type" entry for e500mc, and makes e500 systems depend on PPC_E500. Cc: Kumar Gala Signed-off-by: Baruch Siach --- Changes from v1: * Rebase on 3.1-rc1 * Remove the list of processor families from the PPC_E500 and PPC_E500MC options description. The P20xx can be either e500v2 or e500mc. arch/powerpc/platforms/85xx/Kconfig| 13 + arch/powerpc/platforms/Kconfig.cputype | 27 +++ 2 files changed, 24 insertions(+), 16 deletions(-) diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index 498534c..0132b21 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -13,6 +13,8 @@ if FSL_SOC_BOOKE if PPC32 +if PPC_E500 + config MPC8540_ADS bool "Freescale MPC8540 ADS" select DEFAULT_UIMAGE @@ -171,10 +173,13 @@ config SBC8560 help This option enables support for the Wind River SBC8560 board +endif # PPC_E500 + +if PPC_E500MC + config P2040_RDB bool "Freescale P2040 RDB" select DEFAULT_UIMAGE - select PPC_E500MC select PHYS_64BIT select SWIOTLB select MPC8xxx_GPIO @@ -186,7 +191,6 @@ config P2040_RDB config P3041_DS bool "Freescale P3041 DS" select DEFAULT_UIMAGE - select PPC_E500MC select PHYS_64BIT select SWIOTLB select MPC8xxx_GPIO @@ -198,7 +202,6 @@ config P3041_DS config P4080_DS bool "Freescale P4080 DS" select DEFAULT_UIMAGE - select PPC_E500MC select PHYS_64BIT select SWIOTLB select MPC8xxx_GPIO @@ -207,13 +210,15 @@ config P4080_DS help This option enables support for the P4080 DS board +endif # PPC_E500MC + endif # PPC32 config P5020_DS bool "Freescale P5020 DS" + depends on PPC_E500MC select DEFAULT_UIMAGE select E500 - select PPC_E500MC select PHYS_64BIT select SWIOTLB select MPC8xxx_GPIO diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index e06e395..8f9bd9f 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -10,13 +10,13 @@ choice prompt "Processor Type" depends on PPC32 help - There are five families of 32 bit PowerPC chips supported. + There are six families of 32 bit PowerPC chips supported. The most common ones are the desktop and server CPUs (601, 603, 604, 740, 750, 74xx) CPUs from Freescale and IBM, with their embedded 512x/52xx/82xx/83xx/86xx counterparts. - The other embeeded parts, namely 4xx, 8xx, e200 (55xx) and e500 - (85xx) each form a family of their own that is not compatible - with the others. + The other embeeded parts, namely 4xx, 8xx, e200 (55xx), e500 + (85xx), and e500mc each form a family of their own that is not + compatible with the others. If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx. @@ -24,10 +24,15 @@ config PPC_BOOK3S_32 bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx" select PPC_FPU -config PPC_85xx - bool "Freescale 85xx" +config PPC_E500 + bool "Freescale e500v1/e500v2" + select PPC_85xx select E500 +config PPC_E500MC + bool "Freescale e500mc/e5500" + select PPC_85xx + config PPC_8xx bool "Freescale 8xx" select FSL_SOC @@ -128,15 +133,13 @@ config TUNE_CELL config 8xx bool -config E500 +config PPC_85xx + bool select FSL_EMB_PERFMON select PPC_FSL_BOOK3E - bool -config PPC_E500MC - bool "e500mc Support" - select PPC_FPU - depends on E500 +config E500 + bool config PPC_FPU bool -- 1.7.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: 85xx: separate e500 from e500mc
CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus breaking clear_pages(), probably others too. This patch adds a new "Processor Type" entry for e500mc, and makes e500 systems depend on PPC_E500. Cc: Kumar Gala Signed-off-by: Baruch Siach --- Sending again with the correct list address. Sorry for the noise. arch/powerpc/platforms/85xx/Kconfig| 12 +--- arch/powerpc/platforms/Kconfig.cputype | 27 +++ 2 files changed, 24 insertions(+), 15 deletions(-) diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index b6976e1..9530fca 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -13,6 +13,8 @@ if FSL_SOC_BOOKE if PPC32 +if PPC_E500 + config MPC8540_ADS bool "Freescale MPC8540 ADS" select DEFAULT_UIMAGE @@ -155,10 +157,13 @@ config SBC8560 help This option enables support for the Wind River SBC8560 board +endif # PPC_E500 + +if PPC_E500MC + config P3041_DS bool "Freescale P3041 DS" select DEFAULT_UIMAGE - select PPC_E500MC select PHYS_64BIT select SWIOTLB select MPC8xxx_GPIO @@ -169,7 +174,6 @@ config P3041_DS config P4080_DS bool "Freescale P4080 DS" select DEFAULT_UIMAGE - select PPC_E500MC select PHYS_64BIT select SWIOTLB select MPC8xxx_GPIO @@ -177,13 +181,15 @@ config P4080_DS help This option enables support for the P4080 DS board +endif # PPC_E500MC + endif # PPC32 config P5020_DS bool "Freescale P5020 DS" + depends on PPC_E500MC select DEFAULT_UIMAGE select E500 - select PPC_E500MC select PHYS_64BIT select SWIOTLB select MPC8xxx_GPIO diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index 2165b65..71e3cfb 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -11,13 +11,13 @@ choice prompt "Processor Type" depends on PPC32 help - There are five families of 32 bit PowerPC chips supported. + There are six families of 32 bit PowerPC chips supported. The most common ones are the desktop and server CPUs (601, 603, 604, 740, 750, 74xx) CPUs from Freescale and IBM, with their embedded 512x/52xx/82xx/83xx/86xx counterparts. - The other embeeded parts, namely 4xx, 8xx, e200 (55xx) and e500 - (85xx) each form a family of their own that is not compatible - with the others. + The other embeeded parts, namely 4xx, 8xx, e200 (55xx), e500 + (85xx), and e500mc each form a family of their own that is not + compatible with the others. If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx. @@ -25,10 +25,15 @@ config PPC_BOOK3S_32 bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx" select PPC_FPU -config PPC_85xx - bool "Freescale 85xx" +config PPC_E500 + bool "Freescale e500v1/e500v2 (85xx, P10xx, P20xx)" + select PPC_85xx select E500 +config PPC_E500MC + bool "Freescale e500mc/e5500 (P30xx, P40xx, P50xx)" + select PPC_85xx + config PPC_8xx bool "Freescale 8xx" select FSL_SOC @@ -128,15 +133,13 @@ config TUNE_CELL config 8xx bool -config E500 +config PPC_85xx + bool select FSL_EMB_PERFMON select PPC_FSL_BOOK3E - bool -config PPC_E500MC - bool "e500mc Support" - select PPC_FPU - depends on E500 +config E500 + bool config PPC_FPU bool -- 1.7.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] powerpc: 85xx: Make e500/e500v2 depend on !E500MC
Hi Timur,
On Thu, Jul 28, 2011 at 03:02:21PM -0500, Timur Tabi wrote:
> wrote:
> > On Sun, Jun 19, 2011 at 11:56 PM, Baruch Siach wrote:
> >> CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6,
> >> thus
> >> breaking clear_pages(), probably others too.
> >>
> >> Cc: Kumar Gala
> >> Signed-off-by: Baruch Siach
> >> ---
> >> Is this the right approach?
> >
> > It doesn't work for me.
>
> I also get this error if I try to build corenet32_smp_defconfig:
>
> arch/powerpc/platforms/Kconfig.cputype:136:error: recursive dependency
> detected!
> arch/powerpc/platforms/Kconfig.cputype:136: symbol PPC_E500MC is selected by
> P2040_RDB
> arch/powerpc/platforms/85xx/Kconfig:176: symbol P2040_RDB depends on
> PPC_E500MC
Thanks for reporting. Where can I get this corenet32_smp_defconfig for
testing?
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] powerpc: 85xx: Make e500/e500v2 depend on !E500MC
Hi Scott,
On Thu, Jul 28, 2011 at 03:20:33PM -0500, Scott Wood wrote:
> On Thu, 28 Jul 2011 19:56:53 +
> Tabi Timur-B04825 wrote:
>
> > On Sun, Jun 19, 2011 at 11:56 PM, Baruch Siach wrote:
> > > CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6,
> > > thus
> > > breaking clear_pages(), probably others too.
> > >
> > > Cc: Kumar Gala
> > > Signed-off-by: Baruch Siach
> > > ---
> > > Is this the right approach?
> >
> > It doesn't work for me.
> >
> > I need something that if an e500v2 platform (e.g. the P1022DS) is
> > selected, then I won't be able to select any e500mc platforms (e.g.
> > P4080DS). And if I don't select any e500v2 platforms, then I will be
> > able to select an e500mc platform. This patch doesn't seem to do
> > that.
> >
> > It might be necessary to split the entire menu into two parts, one for
> > e500v2 parts and one for e500mc parts.
>
> How about making the "Processor Type" entry be either E500 or E500MC, both
> of which select PPC_85xx?
Thanks for the tip. A patch along these lines follows.
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] powerpc: 85xx: Make e500/e500v2 depend on !E500MC
Hi Tabi,
On Thu, Jul 28, 2011 at 07:56:53PM +, Tabi Timur-B04825 wrote:
> On Sun, Jun 19, 2011 at 11:56 PM, Baruch Siach wrote:
> > CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6,
> > thus
> > breaking clear_pages(), probably others too.
> >
> > Cc: Kumar Gala
> > Signed-off-by: Baruch Siach
> > ---
> > Is this the right approach?
>
> It doesn't work for me.
>
> I need something that if an e500v2 platform (e.g. the P1022DS) is
> selected, then I won't be able to select any e500mc platforms (e.g.
> P4080DS). And if I don't select any e500v2 platforms, then I will be
> able to select an e500mc platform. This patch doesn't seem to do
> that.
The source of the trouble seems to be the user selectable CONFIG_PPC_E500MC
with the misleading "e500mc Support" description. I'll try to post something
better next week.
> It might be necessary to split the entire menu into two parts, one for
> e500v2 parts and one for e500mc parts.
baurch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] powerpc: 85xx: Make e500/e500v2 depend on !E500MC
Hi Kumar,
On Mon, Jun 20, 2011 at 07:56:10AM +0300, Baruch Siach wrote:
> CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
> breaking clear_pages(), probably others too.
Ping?
Ack/Nack?
baruch
> Cc: Kumar Gala
> Signed-off-by: Baruch Siach
> ---
> Is this the right approach?
>
> arch/powerpc/platforms/85xx/Kconfig |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/Kconfig
> b/arch/powerpc/platforms/85xx/Kconfig
> index b6976e1..5b8546d 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -13,6 +13,8 @@ if FSL_SOC_BOOKE
>
> if PPC32
>
> +if !PPC_E500MC
> +
> config MPC8540_ADS
> bool "Freescale MPC8540 ADS"
> select DEFAULT_UIMAGE
> @@ -155,6 +157,8 @@ config SBC8560
> help
> This option enables support for the Wind River SBC8560 board
>
> +endif # !PPC_E500MC
> +
> config P3041_DS
> bool "Freescale P3041 DS"
> select DEFAULT_UIMAGE
> --
> 1.7.5.3
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC PATCH] powerpc: 85xx: Make e500/e500v2 depend on !E500MC
CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus breaking clear_pages(), probably others too. Cc: Kumar Gala Signed-off-by: Baruch Siach --- Is this the right approach? arch/powerpc/platforms/85xx/Kconfig |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index b6976e1..5b8546d 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -13,6 +13,8 @@ if FSL_SOC_BOOKE if PPC32 +if !PPC_E500MC + config MPC8540_ADS bool "Freescale MPC8540 ADS" select DEFAULT_UIMAGE @@ -155,6 +157,8 @@ config SBC8560 help This option enables support for the Wind River SBC8560 board +endif # !PPC_E500MC + config P3041_DS bool "Freescale P3041 DS" select DEFAULT_UIMAGE -- 1.7.5.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] MAINTAINERS: add arch/powerpc/platforms/85xx/ to the 85xx entry
Cc: Kumar Gala Signed-off-by: Baruch Siach --- MAINTAINERS |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index e50fc6e..8294613 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3904,6 +3904,7 @@ W:http://www.penguinppc.org/ L: linuxppc-dev@lists.ozlabs.org S: Maintained F: arch/powerpc/platforms/83xx/ +F: arch/powerpc/platforms/85xx/ LINUX FOR POWERPC PA SEMI PWRFICIENT M: Olof Johansson -- 1.7.5.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [spi-devel-general] Questions in spi_mpc83xx.c
Hi Mark,
On Thu, Jul 09, 2009 at 02:16:48PM -0400, Mark Bishop wrote:
> I haven't seen this before - the '##' in the function name. This is ANCII C?
Of course. See pp. 90-91 in "The C Programming Language" second edition.
>
> #define MPC83XX_SPI_TX_BUF(type) \
> u32 mpc83xx_spi_tx_buf_##type(struct mpc83xx_spi *mpc83xx_spi)\
> { \
> u32 data; \
>
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
