On 02 5月 22 19:04:13, Thierry Reding wrote: > On Fri, Apr 29, 2022 at 11:28:10AM +0800, Cai Huoqing wrote: > > On 28 4月 22 18:56:07, Mikko Perttunen wrote: > > > On 4/28/22 17:10, Thierry Reding wrote: > > > > On Tue, Apr 26, 2022 at 02:07:57PM +0800, Cai Huoqing wrote: > > > > > The NVIDIA Deep Learning Accelerator (NVDLA) is an open source IP > > > > > which is integrated into NVIDIA Jetson AGX Xavier, > > > > > so add driver support for this accelerator." > > > > > > > > Hi, > > > > > > > > nice to see this work going on. For subsequent revisions, can you please > > > > also Cc the Tegra mailing list (linux-tegra@xxxxxxxxxxxxxxx) as well as > > > > the Tegra platform maintainers (that's Jon Hunter and myself). This will > > > > make sure that more people with an interest in this will see your work. > > > > Not everyone follows dri-devel, linaro-mm-sig or linux-media. > > > > > > > > Thanks, > > > > Thierry > > > > > > From a quick glance it looks like this driver pokes DLA hardware directly > > > which is not the intended programming model on Tegra hardware (there are > > > Falcon microcontrollers that offload task scheduling and synchronization > > > from the CPU). The hardware is also behind the Host1x bus so a simple > > > platform device is not sufficient. > > > > > > Was this driver developed against some platform with OpenDLA hardware (i.e. > > > not Tegra)? > > > > > > If so, we'd need to verify if the hardware matches the hardware in Tegra194. > > > Also, this driver may not be ideal for Tegra platforms since we would lack > > > the hardware scheduling and synchronization facilities. It is likely > > > necessary to have separate drivers for OpenDLA and Tegra's DLA integration. > > > > > > Thanks, > > > Mikko > > > > > Tegra DLA seems to work with a slave coprocessor, the host driver just > > impelement message queue, share buffer, notification... The hardware > > detail of DLA maybe in the slave driver(not linux OS?). > > > > Sure, This driver just support for the SOCs or FPGAs that OPENDLA > > inside. I will change this kind of description "integrated into NVIDIA Jetson AGX Xavier" > > this driver dont support for Tegra directly. > > Yes, I think it would be good to make it clear that this is not going to > work with the Tegra instantiations so that people don't get confused. > > I think it would be ideal, though, if we could reuse as much of this > driver as possible to work with other instantiations. The only reference > to OpenDLA that I can find and which seems somehow relevant to this is > here: > > https://github.com/SCLUO/ITRI-OpenDLA Hi, thanks for your reply. the hardware code here, https://github.com/caihuoq/nvdla-hw or https://github.com/nvdla/hw which includes cmodel, RTL. I also make a docker image to run cmodel simulator(based on qemu) https://github.com/caihuoq/nvdla_docker It can be used to check this driver. Thanks, Cai > > Is that the version that you're using? Or is the version that you're > using at least compatible with that one? Apart from that and the Tegra > instantiations, are you aware of any other derivatives that we need to > account for? I'm worried that this might fragment to the point where it > becomes unmaintainable in upstream Linux. > > Even if this doesn't concern the Tegra instantiation, I think most of my > other comments remain valid. Things like global variables will get in > the way of multiple FPGA instantiations as well, for example. > > You will also need to provide the device tree bindings for the > particular instantiation that you're working on. Typically this would be > identified by a vendor-specific compatible string for your particular > board, but if it stems from a "canonical" FPGA mapping, matching on that > compatible string might also be an option. In either case, when you send > out the DT bindings, please include the devicetree@xxxxxxxxxxxxxxx > mailing list so that they can be properly reviewed. > > Thierry
