On 26.06.2012 22:38, Stephen Warren wrote: > I would assume this can safely be inferred from the compatible value; > nvidia,tegra20-host1x v.s. nvidia,tegra30-host1x, and so there's no > need to represent this in DT. I would assume (and it's certainly just > an assumption) that there are numerous other small details that are > different between the two SoCs, and so the driver will need to have > some table mapping from compatible value to various information > anyway. Terje, can you confirm/deny this (and hopefully use your > knowledge of any future chips to guide the decision without giving > anything away)? I'll now discuss what is going in our internal driver, which will be visible in our public git tree at some point. Regarding just host1x, I have just parameterized per SoC the following properties in the driver: * number of sync points * number of channels * number of wait bases * number of mlocks In addition to this, per SoC we parameterize the mapping of sync points to channels, the names of sync points (for debugging purposes) and whether sync point is stream managed or client managed. For host1x and other devices, we have parameters indicating ability to power gate, idle times before clock gating and power gating, power domain ids (also used for resetting), associated clocks and some other stuff. In the driver parameters we have function pointers for context management and clock scaling. Of these, possibility to power gate, power domain ids, number of resources are hardware properties, and rest are more of less agreements on how software uses the resources. Context management is in the borderline - each SoC has its own sequence to save and restore a context for 3D and MPE. We will also have different register layouts for host1x in different SoCs and I have recently made nvhost ready for that. Everything else except the register layout and the context management could be encoded into device trees. The remaining things will ensure that we will need to have some SoC specific code in the driver. Terje -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
