[PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway

David Woodhouse dwmw2 at infradead.org
Mon Aug 3 23:14:04 EST 2009


On Sun, 2009-08-02 at 17:50 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2009-08-01 at 10:00 +0100, David Woodhouse wrote:
> > I'm not sure. Losing 16MiB on a machine which only has 512MiB anyway
> > doesn't seem ideal, and we'll want to make the no-iommu code DTRT
> > _anyway_, surely?
> >
> > So we might as well let the DART keep its existing logic (which is
> > only
> > to bother if we have more than 1GiB of RAM; 
> 
> Ah right, so when do we enable the DART ? Above 1G ? I though it was
> above 2G but we may well have moved that down to 1G just for b43 indeed.

void __init alloc_dart_table(void)
{
        /* Only reserve DART space if machine has more than 1GB of RAM
         * or if requested with iommu=on on cmdline.
         *
         * 1GB of RAM is picked as limit because some default devices
         * (i.e. Airport Extreme) have 30 bit address range limits.
         */

        if (iommu_is_off)
                return;

        if (!iommu_force_on && lmb_end_of_DRAM() <= 0x40000000ull)
                return;


> I definitely agree on the fix to the mask so it only compares to the
> available RAM. I'll check that in when I'm back from the snow fields 
> on tuesday :-)

I see one potential failure mode with this. You need:
 - No IOMMU
 - Crappy devices
 - Hotpluggable memory
 - Boot with only "low" memory, and allow a pci_set_dma_mask() to
   succeed because you don't have that much memory anyway.
 - Hotplug some "high" memory that the crappy device can't reach.

Do we care about that scenario? I think we might be able to "fix" it by
setting the memory_limit when we allow pci_set_dma_mask() to succeed?
That will effectively prevent the addition of memory that our crappy
device can't reach, won't it?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



More information about the Linuxppc-dev mailing list