On Tue, 16 Sep 2025 10:58:40 +0200 Nicolas Frattaroli <nicolas.frattar...@collabora.com> wrote:
> On Tuesday, 16 September 2025 06:21:10 Central European Summer Time Chia-I Wu > wrote: > > On Mon, Sep 15, 2025 at 10:52 AM Conor Dooley <co...@kernel.org> wrote: > > > > > > On Mon, Sep 15, 2025 at 06:51:16PM +0100, Conor Dooley wrote: > > > > Acked-by: Conor Dooley <conor.doo...@microchip.com> > > > > > > Hmm, actually there seems to be a more complete binding proposed here: > > > https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250912-mt8196-gpufreq-v2-1-779a8a372...@collabora.com/ > > > > > Right. I tried to add the compatible to the binding (this patch) > > before adding it to the driver (next patch). > > > > If this patch is not a prerequisite for the driver change, I can drop > > this. Or perhaps there is a better way? > > > > Depends on what you want to do with the driver change; I could pull it > into my patch series (I need it as a prerequisite now anyway, as v3 > will get rid of the clocks for MT8196 in the binding, which means it > needs to have a flag for this in the soc_data struct you've added) > > I think that would be the easiest solution so that we don't step on > each other's toes, as long as you think the driver change is > basically in its final form right now and does not need major > revisions you'd still like to make yourself without having to > coordinate submission through me. > > Or, the most roundabout option: I split the bindings I submitted > into a separate series, and then we can both declare them as deps > for our driver changes. That might thoroughly confuse maintainers > though. But then you can declare a dep on the bindings series and > I can declare a dep on the bindings series and your patch. The simplest option is probably to merge this series in drm-misc-next and rebase your GPUEB changes on drm-misc-next.
