drm/virtio: Ensure lmem objects are used for dGPU backing CRTC #98
Conversation
sysopenci
added
Valid commit message
Pending Developer Approval
sysopenci
requested review from
dyang23,
feijiang1,
gkdeepa,
JeevakaPrabu,
kaushlen,
sgnanase,
shyjumon-n,
xyzhao2018,
xzhan34 and
yaoxinshi-intel
| #define I915_AG_DMABUF_ATTACHMENT_CURRENT_VERSION (1) | ||
| #define I915_AG_DMABUF_ATTACHMENT_LMEM (1lu << 0) | ||
|
|
||
| struct i915_ag_dmabuf_attachment_priv { |
There was a problem hiding this comment.
please help add some description for the purpose of this new structure
There was a problem hiding this comment.
- This definition in multiple places is easy to cause issues due to out of sync in different place.
- dirty work to make things work , please explore a solution in drm and dma-buf framework level to achieve the goal.
There was a problem hiding this comment.
- This definition in multiple places is easy to cause issues due to out of sync in different place.
This is the reason why I added the version field to the shared structure. This ensures that any modifications to the structure require an increment of the version number, allowing both components to adhere to the same protocol consistently.
- dirty work to make things work , please explore a solution in drm and dma-buf framework level to achieve the goal.
Then modification to the DMA-BUF framework is inevitable. Actually, I've explored to solve this in the framework level. For example, we can add a bool member in the dmabuf attachment to indicate residence of the buffer, or more generally, add a shared_priv field to facilitate sharing metadata between the importer and exporter.
However, I believe this feature is too specific to our drivers to warrant such changes at the framework level. The fields we would introduce, in either approach, would hold significance only for our particular use case, making them an unnecessary generalization and potential overdesign. For this reason, I ultimately decided against exposing our implementation at the framework level.
There was a problem hiding this comment.
I don't think make a framework change is an overdesign even this is a specific for intel platform for a specific use case. for example, if we switch to use xe driver, this solution can't work at all. we need to change this code again to deal with xe driver case.
sysopenci
removed request for
JeevakaPrabu,
sgnanase,
gkdeepa,
shyjumon-n,
dyang23,
xyzhao2018,
yaoxinshi-intel,
kaushlen and
xzhan34
sysopenci
requested review from
dyang23,
feijiang1,
gkdeepa,
JeevakaPrabu,
kaushlen,
sgnanase,
shyjumon-n,
xyzhao2018,
xzhan34 and
yaoxinshi-intel
|
FAILURE: Android CI has completed Engineering Build for this issue.Please check the linked Tracked-On issue/Android CI Web for more details. |
sysopenci
added
Engineering Build Failed
and removed
Engineering Build Not Started
|
SUCCESS: Android CI has completed Engineering Build for this issue.Please check the linked Tracked-On issue/Android CI Web for more details. |
sysopenci
added
Engineering Build Successful
sysopenci
removed request for
dyang23,
gkdeepa,
JeevakaPrabu,
kaushlen,
sgnanase,
shyjumon-n and
yaoxinshi-intel
|
Android CI has started MERGE Build for this pr ,Please check the linked Tracked-On issue/Android CI Web for more details. |
sysopenci
merged commit 45751b1
into
projectceladon:celadon/u/mr0/master
|
Android CI has completed MERGE Build for this pr, build is SUCCESS. Please check the linked Tracked-On issue/Android CI Web for more details. For Binaries: /cactus-absp-or-local/celadon_umr0_master-merge/424 |
Use atomic check hook to ensure the framebuffers we are going to set satisfy the requirement for dGPU.