On Tuesday 07 June 2011 18:49:02 Chris Metcalf wrote: > > You can probably argue that the tile drivers do fit in here as long as > > they are specific to the hypervisor and not to some SOC specific hardware. > > Can you clarify that? I think you're contrasting something like an ARM > core that was licensed and put in a SoC by some random vendor, and you > could have an endless stream of drivers for that case. The Tilera core > isn't being licensed; it's sold more like an Intel chip with a fixed set of > interfaces available only from Tilera. The particular interface in > question here is SPI, and the core itself knows how to boot the chip over > SPI by finding an SPI ROM and reading the boot stream out of it directly > after power-up. > > So does that match with your model of "drivers/platform/tile"? Maybe we > have a winner! :-) I'm not really against drivers/platform/tile for this, the only potential problem that I see with this is that having more stuff in drivers/platform might lead to having even more other stuff in there that should really go into another place. Obviously, if the device is a raw SPI host, the driver should actually go into drivers/spi/spi_tile.c rather than drivers/platform/tile/spi.c. For the spi flash driver that goes through the hypervisor abstraction, I think drivers/virt/tile would be better than driver/platform/tile, but we should really have a new "abstract flash character driver" subsystem for that. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-console" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
