Re: [PATCH v5 0/3] Add "link bpc" DRM property

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Apr 01, 2026 at 01:25:31PM +0100, Daniel Stone wrote:
> On Wed, 1 Apr 2026 at 13:11, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > I think the idea of some kind of feedback properties in the atomic
> > commit has come up before, but no one has ever tried to implement them.
> 
> Yeah, if you're looking for context on these, the last place I
> remember it coming up was wanting to know which other objects would
> potentially be dragged into a commit. For example, on ye olde (?)
> Intel platforms, if programming a different mode is actually
> stop-the-world where all other CRTCs get affected by a CDCLK change,
> being able to know that those other CRTCs would be affected before it
> happens, rather than random -EBUSY after the fact.

For the success cases I think it should be pretty straightforward
to just walk the props in the commit again after the atomic check
and write back all the feedback values from the computed state.

I think adding this for error cases would be much harder. We'd have to
somehow make sure the value(s) we write back to userspace are at least
somewhat valid even though the state check may have failed half way
through.

Although that specific -EBUSY you mention I think is checked after
the actual atomic check, so it would work there. Assuming we'd have
a place for eg. the affected crtcs bitmask in the ioctl structure...

And speaking of which, if you'll permit me to go off on another
tangent, I have occasionally pondered introducing per-device
properties. We could introduce a new object type for the whole
device, and add a new enumeration thing to find it. Then per-device
properties could be added to atomic commits exactly like any other
properties. My original idea was to use this for some kind of
device wide "power vs. performance" knob, but it could also be
used for this affected crtcs bitmask feedback.

-- 
Ville Syrjälä
Intel