Hi!
> >Agreed. If I understand you correctly though, your approach is specific
> >to a particular hardware implementation (Zynq) on the user interface layer,
> >which I think is exactly what we should avoid. Obviously, there is
> >always a driver involved that is specific to the IP block you load into
> >an FPGA at runtime, and that is ok. The two parts that I think we
> >should agree on are:
> The approach I am taking is not Zynq specific. The only Zynq
> specific bits will be range checking data from the device tree to
> make sure the user is mapping address space that is used by the FPGA
> and a similar validation of the IRQ numbers. I have not looked at
> the Altera part closely, but I suspect their fpga/processor
> interface may use similar concepts.
So... the arch may be called socfpga, but I don't think we managed to
merge actual fpga parts, yet ;-). In fact, I'm not sure if I actually
seen those... Dinh should know more about status there.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
