Hi
On Mon, 16 Jul 2012, Tony Lindgren wrote:
> Hmm well it seems that we should apply this fix into arm-soc next/cleanup
> branch if that's where the mismerge happened? It seems the same mismerge
> is there even without 16e5e2c4?
The arm-soc next/cleanup copy of mach-omap2/clockdomains3xxx_data.c is
correct. The problem that my patch was designed to fix doesn't exist in
that version of the file (868c157df9721675c19729eed2c96bac6c3f1d01).
> You patch applies into arm-soc next/cleanup with fuzz:
>
> patching file arch/arm/mach-omap2/clockdomain.c
> patching file arch/arm/mach-omap2/clockdomain.h
> Hunk #1 succeeded at 82 (offset -4 lines).
> patching file arch/arm/mach-omap2/clockdomains3xxx_data.c
> Hunk #1 succeeded at 347 with fuzz 2 (offset -107 lines).
>
> So that's why I'm wondering if it needs some changes.
OK, I understand why you're asking.
I went back and researched it. The patch that I sent is only needed
because the conflict resolution in merge commit
3dd50d0545bd5a8ad83d4339f07935cd3e883271 ("Merge tag
'omap-cleanup-for-v3.6' into tmp-merge") adds &mpu_3xxx_clkdm back into
the clockdomains_common list. The previous commit on that file
16e5e2c471ab889f838bfe1c44032d0481c115e1 removed &mpu_3xxx_clkdm from the
common list, because the AM35xx chips needed to use a different MPU
clockdomain structure from the OMAP3xxx chips.
Or, put differently: Before 16e5e2c471ab889f838bfe1c44032d0481c115e1, it
was correct to have &mpu_3xxx_clkdm in the common list. That's
what's in arm-soc next/cleanup and that data is correct.
After 16e5e2c471ab889f838bfe1c44032d0481c115e1, it's incorrect to have
&mpu_3xxx_clkdm in the common list.
Hope this isn't even more confusing :-)
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
