[PATCH V4 2/3] powerpc/swiotlb: Enable at early stage and disable if not necessary

Li Yang leoli at freescale.com
Sat Aug 4 00:42:24 EST 2012


On Fri, Aug 3, 2012 at 8:38 PM, Kumar Gala <galak at kernel.crashing.org> wrote:
>
> On Aug 2, 2012, at 9:21 PM, Jia Hongtao-B38951 wrote:
>
>>>
>>> -----Original Message-----
>>> From: Kumar Gala [mailto:galak at kernel.crashing.org]
>>> Sent: Thursday, August 02, 2012 8:55 PM
>>> To: Jia Hongtao-B38951
>>> Cc: linuxppc-dev at lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
>>> Subject: Re: [PATCH V4 2/3] powerpc/swiotlb: Enable at early stage and
>>> disable if not necessary
>>>
>>>
>>> On Aug 2, 2012, at 6:42 AM, Jia Hongtao wrote:
>>>
>>>> Remove the dependency on PCI initialization for SWIOTLB initialization.
>>>> So that PCI can be initialized at proper time.
>>>>
>>>> SWIOTLB is partly determined by PCI inbound/outbound map which is
>>> assigned
>>>> in PCI initialization. But swiotlb_init() should be done at the stage
>>> of
>>>> mem_init() which is much earlier than PCI initialization. So we reserve
>>> the
>>>> memory for SWIOTLB first and free it if not necessary.
>>>>
>>>> All boards are converted to fit this change.
>>>>
>>>> Signed-off-by: Jia Hongtao <B38951 at freescale.com>
>>>> Signed-off-by: Li Yang <leoli at freescale.com>
>>>> ---
>>>
>>> This doesn't seem like it addresses our issue w/regards to not being able
>>> to map all of memory from PCI.
>>
>> PCI init will determine ppc_swiotlb_enable due to PCI map. swiotlb_late_init
>> will handle all swiotlb things depend on the result of pci init.
>
> Think about the case that we have 4095M of memory & 1G of PCI memory mapped space.  The old code would enable swiotlb for this case since we would NOT be able to DMA to all 4095M of memory.  The patch does not handle this case correctly.

The patch can handle it.  The ppc_swiotlb_enable is still being set in
 fsl_pci_init() if there is 1G of PCI memory mapped space.  It is
after next patch that the ppc_swiotlb_enable is being set in the PCI
probe() routine.

Leo


More information about the Linuxppc-dev mailing list