The upstream source uses the driver "brcm,bcm2835-cprman" to do a bunch of configuration, where as the foundation source uses the VC4 subsystem to do some it. The upstream source has a much simpler sound driver which doesn't appear to support audio through HDMI, but the foundation's audio driver's step on the I/O address space of the "brcm,bcm2838-cprman". So if their is only going to be one 64 bit port, then either one or the other has to be chosen.swarren wrote:What does "Some of it has to do with configuration conflicts in the address space." mean, in detail? I don't see how there would be any difference between the 32-bit and 64-bit ports here as far as a standard kernel driver is concerned. Equally, FW-vs-not shouldn't influence anything here either.
Of course, one option would be to port both the foundation source and the upstream source to 64bit. But as it appears that after zeldin's checkin, I've been doing most of the kernel changes and I only have a limited amount of time on my hand. So I can't probably do both.
BTW, without getting too elaborate on this some of this cookie passing scares me as bad design. It might be OK for a low income person that just wants a cheap video game system or someone that want's to tinker with UARTs, but it's not good for embedded or network attached systems. Personally, I would take the runtime performance hit and have mapping tables(either hash or tree based) on both sides of the cookie passes, but that's just my opinion.