linux-next: manual merge of the bitmap tree with the devfreq tree

linux-next: manual merge of the bitmap tree with the devfreq tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

Hi all,

Today's linux-next merge of the bitmap tree got a conflict in:

  drivers/devfreq/event/rockchip-dfi.c

between commit:

  7d9e29ed3f8e ("PM / devfreq: rockchip-dfi: add support for LPDDR5")

from the devfreq tree and commit:

  414054a0bc1f ("PM / devfreq: rockchip-dfi: switch to FIELD_PREP_WM16 macro")

from the bitmap tree.

I have no idea how to fix this up, so I dropped the changes from the
bitmap tree for today.  Someone should supply me with the appropriate
resolution.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the bitmap tree with the devfreq tree

[Nicolas Frattaroli]

On Monday, 8 September 2025 09:51:35 Central European Summer Time Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the bitmap tree got a conflict in:
> 
>   drivers/devfreq/event/rockchip-dfi.c
> 
> between commit:
> 
>   7d9e29ed3f8e ("PM / devfreq: rockchip-dfi: add support for LPDDR5")
> 
> from the devfreq tree and commit:
> 
>   414054a0bc1f ("PM / devfreq: rockchip-dfi: switch to FIELD_PREP_WM16 macro")
> 
> from the bitmap tree.

Yeah, basically both of these were by me and landed at the same time
through different trees; they were developed at different times and
the reviews just happened to conclude at the same moment. The reason
why they go through different trees is that the bitmap changes are
part of a large refactor across several drivers to make them use a
shared macro instead of reinventing their own, whereas the devfreq
side of the changes is functional changes to add LPDDR5 support and
also fix the cycle count on RK3588.

> 
> I have no idea how to fix this up, so I dropped the changes from the
> bitmap tree for today.  Someone should supply me with the appropriate
> resolution.
> 

Dropping the bitmap tree changes of this driver is fine by me. I can
send a rebased patch of that for the next merge window to do the move
from the driver's own macro to the shared macro. The functional
change in the devfreq tree is more important to get in.

Kind regards,
Nicolas Frattaroli

Re: linux-next: manual merge of the bitmap tree with the devfreq tree

[Chanwoo Choi]

Hi Nicolas,

On Mon, Sep 8, 2025 at 8:26 PM Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> On Monday, 8 September 2025 09:51:35 Central European Summer Time Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the bitmap tree got a conflict in:
> >
> >   drivers/devfreq/event/rockchip-dfi.c
> >
> > between commit:
> >
> >   7d9e29ed3f8e ("PM / devfreq: rockchip-dfi: add support for LPDDR5")
> >
> > from the devfreq tree and commit:
> >
> >   414054a0bc1f ("PM / devfreq: rockchip-dfi: switch to FIELD_PREP_WM16 macro")
> >
> > from the bitmap tree.
>
> Yeah, basically both of these were by me and landed at the same time
> through different trees; they were developed at different times and
> the reviews just happened to conclude at the same moment. The reason
> why they go through different trees is that the bitmap changes are
> part of a large refactor across several drivers to make them use a
> shared macro instead of reinventing their own, whereas the devfreq
> side of the changes is functional changes to add LPDDR5 support and
> also fix the cycle count on RK3588.
>
> >
> > I have no idea how to fix this up, so I dropped the changes from the
> > bitmap tree for today.  Someone should supply me with the appropriate
> > resolution.
> >
>
> Dropping the bitmap tree changes of this driver is fine by me. I can
> send a rebased patch of that for the next merge window to do the move
> from the driver's own macro to the shared macro. The functional
> change in the devfreq tree is more important to get in.

I think that you need to ask to drop your patch[1] on bitmap tree.
[1] 414054a0bc1f ("PM / devfreq: rockchip-dfi: switch to FIELD_PREP_WM16 macro")

Before fixing this merge conflict, I'll drop the patches related to patch[2].
[2] 7d9e29ed3f8e ("PM / devfreq: rockchip-dfi: add support for LPDDR5")

After resolving the merge conflict, I'll apply them again.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: linux-next: manual merge of the bitmap tree with the devfreq tree

[Yury Norov]

> > Dropping the bitmap tree changes of this driver is fine by me. I can
> > send a rebased patch of that for the next merge window to do the move
> > from the driver's own macro to the shared macro. The functional
> > change in the devfreq tree is more important to get in.
> 
> I think that you need to ask to drop your patch[1] on bitmap tree.
> [1] 414054a0bc1f ("PM / devfreq: rockchip-dfi: switch to FIELD_PREP_WM16 macro")

So I did.

Nicolas, please make sure resending the dropped patch
rebased shortly after merge window closing. I'd like to schedule it
for -rc2. 

Thanks,
Yury

> Before fixing this merge conflict, I'll drop the patches related to patch[2].
> [2] 7d9e29ed3f8e ("PM / devfreq: rockchip-dfi: add support for LPDDR5")
> 
> After resolving the merge conflict, I'll apply them again.
> 
> -- 
> Best Regards,
> Chanwoo Choi
> Samsung Electronics
> 

Re: linux-next: manual merge of the bitmap tree with the devfreq tree

[Nicolas Frattaroli]

On Tuesday, 9 September 2025 18:46:27 Central European Summer Time Yury Norov wrote:
> > > Dropping the bitmap tree changes of this driver is fine by me. I can
> > > send a rebased patch of that for the next merge window to do the move
> > > from the driver's own macro to the shared macro. The functional
> > > change in the devfreq tree is more important to get in.
> > 
> > I think that you need to ask to drop your patch[1] on bitmap tree.
> > [1] 414054a0bc1f ("PM / devfreq: rockchip-dfi: switch to FIELD_PREP_WM16 macro")
> 
> So I did.

Thanks! Chanwoo Choi, could you pick the DFI LPDDR5 change again
on your side?

> 
> Nicolas, please make sure resending the dropped patch
> rebased shortly after merge window closing. I'd like to schedule it
> for -rc2.

Will do. Thank you!

Kind regards,
Nicolas Frattaroli

> 
> Thanks,
> Yury
> 
> > Before fixing this merge conflict, I'll drop the patches related to patch[2].
> > [2] 7d9e29ed3f8e ("PM / devfreq: rockchip-dfi: add support for LPDDR5")
> > 
> > After resolving the merge conflict, I'll apply them again.
> > 
> 

Re: linux-next: manual merge of the bitmap tree with the devfreq tree

[Chanwoo Choi]

Hi,

On Wed, Sep 10, 2025 at 2:42 AM Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> On Tuesday, 9 September 2025 18:46:27 Central European Summer Time Yury Norov wrote:
> > > > Dropping the bitmap tree changes of this driver is fine by me. I can
> > > > send a rebased patch of that for the next merge window to do the move
> > > > from the driver's own macro to the shared macro. The functional
> > > > change in the devfreq tree is more important to get in.
> > >
> > > I think that you need to ask to drop your patch[1] on bitmap tree.
> > > [1] 414054a0bc1f ("PM / devfreq: rockchip-dfi: switch to FIELD_PREP_WM16 macro")
> >
> > So I did.
>
> Thanks! Chanwoo Choi, could you pick the DFI LPDDR5 change again
> on your side?

I applied again. Thanks.

>
> >
> > Nicolas, please make sure resending the dropped patch
> > rebased shortly after merge window closing. I'd like to schedule it
> > for -rc2.
>
> Will do. Thank you!
>
> Kind regards,
> Nicolas Frattaroli
>
> >
> > Thanks,
> > Yury
> >
> > > Before fixing this merge conflict, I'll drop the patches related to patch[2].
> > > [2] 7d9e29ed3f8e ("PM / devfreq: rockchip-dfi: add support for LPDDR5")
> > >
> > > After resolving the merge conflict, I'll apply them again.
> > >
> >
>
>
>
>


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics