20.10.2020 12:18, Mikko Perttunen пишет: >> I'm asking this question because right now there is only one potential >> client for this IOCTL, the VIC. If other clients aren't supposed to be a >> part of the DRM driver, like for example NVDEC which probably should be >> a V4L driver, then DRM driver will have only a single VIC and in this >> case we shouldn't need this IOCTL because DRM and V4L should use generic >> dmabuf API for importing and exporting buffers. > > This IOCTL is required for GR2D/GR3D too, as they need to access memory > as well. This is a different step from import/export -- first you import > or allocate your memory so you have a GEM handle, then you map it to the > channel, which does the IOMMU mapping (if there is an IOMMU). > This doesn't answer my question. I don't have a full picture and for now will remain dubious about this IOCTL, but it should be fine to have it in a form of WIP patches (maybe staging feature) until userspace code and hardware specs will become available. Some more comments: 1. Older Tegra SoCs do not have restrictions which do not allow to group IOMMU as wished by kernel driver. It's fine to have one static mapping per-GEM that can be accessed by all DRM devices, that's why CHANNEL_MAP is questionable. 2. IIUC, the mappings need to be done per-device group/stream and not per-channel_ctx. It looks like nothing stops channel contexts to guess mapping addresses of the other context, isn't it? I'm suggesting that each GEM should have a per-device mapping and the new IOCTL should create these GEM-mappings, instead of the channel_ctx mappings. 3. We shouldn't need channel contexts at all, a single "DRM file" context should be enough to have. 4. The new UAPI need to be separated into several parts in the next revision, one patch for each new feature. The first patches should be the ones that are relevant to the existing userspace code, like support for the waits. Partial mappings should be a separate feature because it's a questionable feature that needs to be proved by a real userspace first. Maybe it would be even better to drop it for the starter, to ease reviewing. Waiting for fences on host1x should be a separate feature. The syncfile support needs to be a separate feature as well because I don't see a use-case for it right now. I'd like to see the DRM_SCHED and syncobj support. I can help you with it if it's out of yours scope for now. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
