Re: Archs using generic PCI controller drivers vs. resource policy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2019-07-02 at 23:24 +1000, Greg Ungerer wrote:
> > So far I've counted arm, arm64 (DT, not ACPI) and nios2. Any other
> > ?
> 
> For the m68k platforms which support PCI (which is only some of
> the more modern ColdFire variants) they expect PCI resources to
> be assigned by Linux. There is no boot firmware that will do that
> before kernel startup.
> 
> The PCI root driver complex is already in the arch area though
> (arch/m68k/coldfire/pci.c) so that is essentially what you
> want to achieve right?

Thanks !

So no I'm not trying to move controllers to arch. It makes sense to
have controllers live in generic code when those controller are IP
blocks from mobs like DesignWare that various SoC vendors chose to
integrate, regardless of the CPU architecture.

The issue is more about the resource allocation policy. I want to move
that *out* of the host controller drivers. That policy essentially
depends on whether a given platform/board trusts its firmware or not,
so it's fundamentally arch specific.

There are various reason which I can elaborate if you want wy some
platforms actually need to trust the firmware, at least partially.

Most embedded platforms don't give a damn and are happy for Linux to
reassign everything.

Cheers,
Ben.




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux