I'll reply to the rest later, but here some initial comments. On 24.11.2012 21:04, Thierry Reding wrote: > The usual way to do this is to adapt downstream kernels to upstream > changes, not the other way around. Yep, we're doing both ways - leveraging downstream and upstream code. > Some more documentation about host1x would certainly be very welcome. If > you write something up, maybe you can push to get it included in the TRM > as well. The host1x chapter in the TRM is a bit sketchy and something > more like a programming guide would be really useful. Got it. I hope user space code would help here, as it would be a definite explanation of how the thing is supposed to be used. > Funny enough, the chapter about the 2D engine says that it is merely > there to document the registers and explicitly not as a programming > guide because it is expected that NVIDIA supplied drivers will always be > used. I had a good laugh when I read that. =) Ouch. :-) > The benefit is that smaller changes that add a single particular feature > are a lot easier to review and verify. Yep, I'm working on this. I think I found a way. > But that's precisely my point. If the hardware is called host1x, why not > call the driver host1x as well. We do the same for all other hardware > blocks. The I2C controller driver is named i2c-tegra just as the RTC > driver is named rtc-tegra. Why should the driver for host1x not be named > host1x? Ok, I got it. 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
