[-- Attachment #1: Type: text/plain, Size: 1052 bytes --] Hi all, Today's linux-next merge of the tegra tree got a conflict in arch/arm/mach-tegra/board-dt-tegra20.c between commit 1d5cc604f42f ("ARM: remove mach .handle_irq for GIC users") from the arm-soc tree and commit ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from the tegra tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au diff --cc arch/arm/mach-tegra/board-dt-tegra20.c index 5ed81bab,171ba3c..0000000 --- a/arch/arm/mach-tegra/board-dt-tegra20.c +++ b/arch/arm/mach-tegra/board-dt-tegra20.c @@@ -200,7 -203,8 +201,7 @@@ DT_MACHINE_START(TEGRA_DT, "nVidia Tegr .smp = smp_ops(tegra_smp_ops), .init_early = tegra20_init_early, .init_irq = tegra_dt_init_irq, - .init_time = tegra_init_timer, - .handle_irq = gic_handle_irq, + .init_time = clocksource_of_init, .init_machine = tegra_dt_init, .init_late = tegra_dt_init_late, .restart = tegra_assert_system_reset, [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --] Hi All, On Wed, 16 Jan 2013 14:10:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Today's linux-next merge of the tegra tree got a conflict in > arch/arm/mach-tegra/board-dt-tegra20.c between commit 1d5cc604f42f ("ARM: > remove mach .handle_irq for GIC users") from the arm-soc tree and commit > ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from > the tegra tree. This also affected arch/arm/mach-tegra/board-dt-tegra30.c. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au diff --cc arch/arm/mach-tegra/board-dt-tegra30.c index 12dc2dd,cfe5fc0..0000000 --- a/arch/arm/mach-tegra/board-dt-tegra30.c +++ b/arch/arm/mach-tegra/board-dt-tegra30.c @@@ -111,7 -113,8 +112,7 @@@ DT_MACHINE_START(TEGRA30_DT, "NVIDIA Te .map_io = tegra_map_common_io, .init_early = tegra30_init_early, .init_irq = tegra_dt_init_irq, - .init_time = tegra_init_timer, - .handle_irq = gic_handle_irq, + .init_time = clocksource_of_init, .init_machine = tegra30_dt_init, .init_late = tegra_init_late, .restart = tegra_assert_system_reset, [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 997 bytes --] Hi all, Today's linux-next merge of the tegra tree got a conflict in drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500: Move timer code to drivers/clocksource") from the arm-soc tree and commit ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from the tegra tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au diff --cc drivers/clocksource/Makefile index 440449c,b5cc507..0000000 --- a/drivers/clocksource/Makefile +++ b/drivers/clocksource/Makefile @@@ -17,6 -17,6 +17,7 @@@ obj-$(CONFIG_CLKSRC_DBX500_PRCMU) += cl obj-$(CONFIG_ARMADA_370_XP_TIMER) += time-armada-370-xp.o obj-$(CONFIG_ARCH_BCM2835) += bcm2835_timer.o obj-$(CONFIG_SUNXI_TIMER) += sunxi_timer.o +obj-$(CONFIG_VT8500_TIMER) += vt8500_timer.o + obj-$(CONFIG_ARCH_TEGRA) += tegra20_timer.o obj-$(CONFIG_CLKSRC_ARM_GENERIC) += arm_generic.o [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
On Wed, 2013-01-16 at 14:14 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tegra tree got a conflict in
> drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500:
> Move timer code to drivers/clocksource") from the arm-soc tree and commit
> ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from
> the tegra tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
I don't know about everyone else, but I feel the preference should be to
keep things alphabetized where possible to help avoid with merge
conflicts later on. This is always a problem when we start tacking
things on the end of lists.
I realise this Kconfig is not alphabetized anyway, but it's never too
early to start on the 'right' path.
Regards
Tony P
On 01/15/2013 08:49 PM, Tony Prisk wrote:
> On Wed, 2013-01-16 at 14:14 +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the tegra tree got a conflict in
>> drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500:
>> Move timer code to drivers/clocksource") from the arm-soc tree and commit
>> ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from
>> the tegra tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>>
>
> I don't know about everyone else, but I feel the preference should be to
> keep things alphabetized where possible to help avoid with merge
> conflicts later on. This is always a problem when we start tacking
> things on the end of lists.
>
> I realise this Kconfig is not alphabetized anyway, but it's never too
> early to start on the 'right' path.
Sounds like a good idea, but the issue is: When to do the initial sort
so it doesn't conflict with all the adds in a kernel cycle... Post and
immediately commit a new patch near the end of the merge window?
On Tue, 2013-01-15 at 21:32 -0700, Stephen Warren wrote:
> On 01/15/2013 08:49 PM, Tony Prisk wrote:
> > On Wed, 2013-01-16 at 14:14 +1100, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Today's linux-next merge of the tegra tree got a conflict in
> >> drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500:
> >> Move timer code to drivers/clocksource") from the arm-soc tree and commit
> >> ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from
> >> the tegra tree.
> >>
> >> I fixed it up (see below) and can carry the fix as necessary (no action
> >> is required).
> >>
> >
> > I don't know about everyone else, but I feel the preference should be to
> > keep things alphabetized where possible to help avoid with merge
> > conflicts later on. This is always a problem when we start tacking
> > things on the end of lists.
> >
> > I realise this Kconfig is not alphabetized anyway, but it's never too
> > early to start on the 'right' path.
>
> Sounds like a good idea, but the issue is: When to do the initial sort
> so it doesn't conflict with all the adds in a kernel cycle... Post and
> immediately commit a new patch near the end of the merge window?
Given that the maintainer can quite safely do the patch (sorry
maintainers), I don't see any reason why it couldn't be done at the
point where they stop accepting patches for the merge-window. Once the
patches are stopped, sort the list in one last patch.
It makes sense to get it done in this window if possible as the Kconfig
will only get bigger as time goes on, making sorting it more time
consuming.
Regards
Tony P
Hi,
On Tue, Jan 15, 2013 at 8:52 PM, Tony Prisk <linux@prisktech.co.nz> wrote:
> On Tue, 2013-01-15 at 21:32 -0700, Stephen Warren wrote:
>> On 01/15/2013 08:49 PM, Tony Prisk wrote:
>> > On Wed, 2013-01-16 at 14:14 +1100, Stephen Rothwell wrote:
>> >> Hi all,
>> >>
>> >> Today's linux-next merge of the tegra tree got a conflict in
>> >> drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500:
>> >> Move timer code to drivers/clocksource") from the arm-soc tree and commit
>> >> ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from
>> >> the tegra tree.
>> >>
>> >> I fixed it up (see below) and can carry the fix as necessary (no action
>> >> is required).
>> >>
>> >
>> > I don't know about everyone else, but I feel the preference should be to
>> > keep things alphabetized where possible to help avoid with merge
>> > conflicts later on. This is always a problem when we start tacking
>> > things on the end of lists.
>> >
>> > I realise this Kconfig is not alphabetized anyway, but it's never too
>> > early to start on the 'right' path.
>>
>> Sounds like a good idea, but the issue is: When to do the initial sort
>> so it doesn't conflict with all the adds in a kernel cycle... Post and
>> immediately commit a new patch near the end of the merge window?
>
> Given that the maintainer can quite safely do the patch (sorry
> maintainers), I don't see any reason why it couldn't be done at the
> point where they stop accepting patches for the merge-window. Once the
> patches are stopped, sort the list in one last patch.
>
> It makes sense to get it done in this window if possible as the Kconfig
> will only get bigger as time goes on, making sorting it more time
> consuming.
Actually, Russell wen through and reordered these not long ago, if I
remember correctly. The current ordering is the same as in the
structure definition, and should be kept that way.
-Olof
On 01/16/2013 09:27 AM, Olof Johansson wrote: > Hi, > > On Tue, Jan 15, 2013 at 8:52 PM, Tony Prisk <linux@prisktech.co.nz> wrote: >> On Tue, 2013-01-15 at 21:32 -0700, Stephen Warren wrote: >>> On 01/15/2013 08:49 PM, Tony Prisk wrote: >>>> On Wed, 2013-01-16 at 14:14 +1100, Stephen Rothwell wrote: >>>>> Hi all, >>>>> >>>>> Today's linux-next merge of the tegra tree got a conflict in >>>>> drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500: >>>>> Move timer code to drivers/clocksource") from the arm-soc tree and commit >>>>> ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from >>>>> the tegra tree. >>>>> >>>>> I fixed it up (see below) and can carry the fix as necessary (no action >>>>> is required). >>>>> >>>> >>>> I don't know about everyone else, but I feel the preference should be to >>>> keep things alphabetized where possible to help avoid with merge >>>> conflicts later on. This is always a problem when we start tacking >>>> things on the end of lists. >>>> >>>> I realise this Kconfig is not alphabetized anyway, but it's never too >>>> early to start on the 'right' path. >>> >>> Sounds like a good idea, but the issue is: When to do the initial sort >>> so it doesn't conflict with all the adds in a kernel cycle... Post and >>> immediately commit a new patch near the end of the merge window? >> >> Given that the maintainer can quite safely do the patch (sorry >> maintainers), I don't see any reason why it couldn't be done at the >> point where they stop accepting patches for the merge-window. Once the >> patches are stopped, sort the list in one last patch. That only works well if the one maintainer is the only person taking patches for the drivers/clocksource tree. It might be true that the "one maintainer" here ends up being arm-soc in this kernel cycle though? >> It makes sense to get it done in this window if possible as the Kconfig >> will only get bigger as time goes on, making sorting it more time >> consuming. > > Actually, Russell wen through and reordered these not long ago, if I > remember correctly. The current ordering is the same as in the > structure definition, and should be kept that way. I think this is talking about Makefile entries rather than struct definitions?
On Wed, Jan 16, 2013 at 9:08 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 01/16/2013 09:27 AM, Olof Johansson wrote: >> Hi, >> >> On Tue, Jan 15, 2013 at 8:52 PM, Tony Prisk <linux@prisktech.co.nz> wrote: >>> On Tue, 2013-01-15 at 21:32 -0700, Stephen Warren wrote: >>>> On 01/15/2013 08:49 PM, Tony Prisk wrote: >>>>> On Wed, 2013-01-16 at 14:14 +1100, Stephen Rothwell wrote: >>>>>> Hi all, >>>>>> >>>>>> Today's linux-next merge of the tegra tree got a conflict in >>>>>> drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500: >>>>>> Move timer code to drivers/clocksource") from the arm-soc tree and commit >>>>>> ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from >>>>>> the tegra tree. >>>>>> >>>>>> I fixed it up (see below) and can carry the fix as necessary (no action >>>>>> is required). >>>>>> >>>>> >>>>> I don't know about everyone else, but I feel the preference should be to >>>>> keep things alphabetized where possible to help avoid with merge >>>>> conflicts later on. This is always a problem when we start tacking >>>>> things on the end of lists. >>>>> >>>>> I realise this Kconfig is not alphabetized anyway, but it's never too >>>>> early to start on the 'right' path. >>>> >>>> Sounds like a good idea, but the issue is: When to do the initial sort >>>> so it doesn't conflict with all the adds in a kernel cycle... Post and >>>> immediately commit a new patch near the end of the merge window? >>> >>> Given that the maintainer can quite safely do the patch (sorry >>> maintainers), I don't see any reason why it couldn't be done at the >>> point where they stop accepting patches for the merge-window. Once the >>> patches are stopped, sort the list in one last patch. > > That only works well if the one maintainer is the only person taking > patches for the drivers/clocksource tree. It might be true that the "one > maintainer" here ends up being arm-soc in this kernel cycle though? I'll send a patch to Linus at the end of the merge window, no need to do it through a merge -- that way it's trivial for him to fixup a merge conflict (and he can refuse to take it if he feels it's silly). >>> It makes sense to get it done in this window if possible as the Kconfig >>> will only get bigger as time goes on, making sorting it more time >>> consuming. >> >> Actually, Russell wen through and reordered these not long ago, if I >> remember correctly. The current ordering is the same as in the >> structure definition, and should be kept that way. > > I think this is talking about Makefile entries rather than struct > definitions? Ah, yes, they should be sorted. But definitely not right now since it'll just make things worse. -Olof
[-- Attachment #1: Type: text/plain, Size: 1324 bytes --] Hi all, Today's linux-next merge of the tegra tree got a conflict in arch/arm/mach-tegra/common.c between commit 0529e315bbda ("ARM: use common irqchip_init for GIC init") from the arm-soc tree and commit 567f70da22d2 ("ARM: tegra: migrate to new clock code") from the tegra tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au diff --cc arch/arm/mach-tegra/common.c index 3599959,87dd69c..0000000 --- a/arch/arm/mach-tegra/common.c +++ b/arch/arm/mach-tegra/common.c @@@ -21,9 -21,11 +21,10 @@@ #include <linux/io.h> #include <linux/clk.h> #include <linux/delay.h> -#include <linux/of_irq.h> +#include <linux/irqchip.h> + #include <linux/clk/tegra.h> #include <asm/hardware/cache-l2x0.h> -#include <asm/hardware/gic.h> #include <mach/powergate.h> @@@ -56,10 -58,16 +57,11 @@@ u32 tegra_uart_config[4] = }; #ifdef CONFIG_OF -static const struct of_device_id tegra_dt_irq_match[] __initconst = { - { .compatible = "arm,cortex-a9-gic", .data = gic_of_init }, - { } -}; - void __init tegra_dt_init_irq(void) { + tegra_clocks_init(); tegra_init_irq(); - of_irq_init(tegra_dt_irq_match); + irqchip_init(); } #endif [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1012 bytes --] Hi all, Today's linux-next merge of the tegra tree got a conflict in arch/arm/mach-tegra/platsmp.c between commit 520f7bd73354 ("irqchip: Move ARM gic.h to include/linux/irqchip/arm-gic.h") from the arm-soc tree and commit 4c6e1ff5b5fe ("ARM: tegra: move tegra_cpu_car.h to linux/clk/tegra.h") from the tegra tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au diff --cc arch/arm/mach-tegra/platsmp.c index 18d7290,3ec7fc4..0000000 --- a/arch/arm/mach-tegra/platsmp.c +++ b/arch/arm/mach-tegra/platsmp.c @@@ -18,11 -18,13 +18,13 @@@ #include <linux/jiffies.h> #include <linux/smp.h> #include <linux/io.h> +#include <linux/irqchip/arm-gic.h> + #include <linux/clk/tegra.h> #include <asm/cacheflush.h> -#include <asm/hardware/gic.h> #include <asm/mach-types.h> #include <asm/smp_scu.h> + #include <asm/smp_plat.h> #include <mach/powergate.h> [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --] Hi all, Today's linux-next merge of the tegra tree got a conflict in arch/arm/mach-tegra/common.c between commit 0529e315bbda ("ARM: use common irqchip_init for GIC init") from the arm-soc tree and commits 61fd290d213e ("ARM: tegra: migrate to new clock code") and 5c541b884c09 ("ARM: tegra: Add initial support for Tegra114 SoC") from the tegra tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au diff --cc arch/arm/mach-tegra/common.c index 3599959,2f13513..0000000 --- a/arch/arm/mach-tegra/common.c +++ b/arch/arm/mach-tegra/common.c @@@ -21,9 -21,11 +21,10 @@@ #include <linux/io.h> #include <linux/clk.h> #include <linux/delay.h> -#include <linux/of_irq.h> +#include <linux/irqchip.h> + #include <linux/clk/tegra.h> #include <asm/hardware/cache-l2x0.h> -#include <asm/hardware/gic.h> #include <mach/powergate.h> @@@ -56,10 -58,17 +57,11 @@@ u32 tegra_uart_config[4] = }; #ifdef CONFIG_OF -static const struct of_device_id tegra_dt_irq_match[] __initconst = { - { .compatible = "arm,cortex-a15-gic", .data = gic_of_init }, - { .compatible = "arm,cortex-a9-gic", .data = gic_of_init }, - { } -}; - void __init tegra_dt_init_irq(void) { + tegra_clocks_init(); tegra_init_irq(); - of_irq_init(tegra_dt_irq_match); + irqchip_init(); } #endif [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1835 bytes --] Hi all, Today's linux-next merge of the tegra tree got a conflict in arch/arm/mach-tegra/platsmp.c between commits b1cffebf1029 ("ARM: GIC: remove direct use of gic_raise_softirq") and 520f7bd73354 ("irqchip: Move ARM gic.h to include/linux/irqchip/arm-gic.h") from the arm-soc tree and commits 89572c77cdff ("ARM: tegra: move tegra_cpu_car.h to linux/clk/tegra.h") and a8a6930157e0 ("ARM: tegra: Use DT /cpu node to detect number of CPU core") from the tegra tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au diff --cc arch/arm/mach-tegra/platsmp.c index 18d7290,2ff68a4..0000000 --- a/arch/arm/mach-tegra/platsmp.c +++ b/arch/arm/mach-tegra/platsmp.c @@@ -18,11 -18,13 +18,13 @@@ #include <linux/jiffies.h> #include <linux/smp.h> #include <linux/io.h> +#include <linux/irqchip/arm-gic.h> + #include <linux/clk/tegra.h> #include <asm/cacheflush.h> -#include <asm/hardware/gic.h> #include <asm/mach-types.h> #include <asm/smp_scu.h> + #include <asm/smp_plat.h> #include <mach/powergate.h> @@@ -143,22 -176,9 +176,8 @@@ done return status; } - /* - * Initialise the CPU possible map early - this describes the CPUs - * which may be present or become present in the system. - */ static void __init tegra_smp_init_cpus(void) { - unsigned int i, ncores = scu_get_core_count(scu_base); - - if (ncores > nr_cpu_ids) { - pr_warn("SMP: %u cores greater than maximum (%u), clipping\n", - ncores, nr_cpu_ids); - ncores = nr_cpu_ids; - } - - for (i = 0; i < ncores; i++) - set_cpu_possible(i, true); - set_smp_cross_call(gic_raise_softirq); } static void __init tegra_smp_prepare_cpus(unsigned int max_cpus) [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1.1: Type: text/plain, Size: 1836 bytes --] Hi all, Today's linux-next merge of the tegra tree got a conflict in drivers/clocksource/tegra20_timer.c between commit 1d16cfb3aeba ("clocksource: tegra20: use the device_node pointer passed to init") from the arm-soc tree and commit 6f88fb8af6c6 ("clocksource: tegra: move to of_clk_get") from the tegra tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au diff --cc drivers/clocksource/tegra20_timer.c index 2e4d8a6,bc4b8ad..0000000 --- a/drivers/clocksource/tegra20_timer.c +++ b/drivers/clocksource/tegra20_timer.c @@@ -218,34 -259,12 +218,34 @@@ static void __init tegra20_init_timer(s tegra_clockevent.irq = tegra_timer_irq.irq; clockevents_config_and_register(&tegra_clockevent, 1000000, 0x1, 0x1fffffff); -#ifdef CONFIG_HAVE_ARM_TWD - twd_local_timer_of_register(); -#endif +} +CLOCKSOURCE_OF_DECLARE(tegra20_timer, "nvidia,tegra20-timer", tegra20_init_timer); + +static void __init tegra20_init_rtc(struct device_node *np) +{ + struct clk *clk; + + rtc_base = of_iomap(np, 0); + if (!rtc_base) { + pr_err("Can't map RTC registers"); + BUG(); + } + + /* + * rtc registers are used by read_persistent_clock, keep the rtc clock + * enabled + */ - clk = clk_get_sys("rtc-tegra", NULL); ++ clk = of_clk_get(np, 0); + if (IS_ERR(clk)) + pr_warn("Unable to get rtc-tegra clock\n"); + else + clk_prepare_enable(clk); + + of_node_put(np); + register_persistent_clock(NULL, tegra_read_persistent_clock); } -CLOCKSOURCE_OF_DECLARE(tegra20, "nvidia,tegra20-timer", tegra20_init_timer); +CLOCKSOURCE_OF_DECLARE(tegra20_rtc, "nvidia,tegra20-rtc", tegra20_init_rtc); #ifdef CONFIG_PM static u32 usec_config; [-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 03/17/2013 10:31 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tegra tree got a conflict in
> drivers/clocksource/tegra20_timer.c between commit 1d16cfb3aeba
> ("clocksource: tegra20: use the device_node pointer passed to
> init") from the arm-soc tree and commit 6f88fb8af6c6 ("clocksource:
> tegra: move to of_clk_get") from the tegra tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no
> action is required).
Thanks. This resolution looks fine.
Arnd/Olof, do you want me to rebase the Tegra branch onto some arm-soc
branch to resolve this conflict, or are you happy to simply resolve it
as below when pulling the Tegra branches into arm-soc for 3.10?
On Monday 18 March 2013, Stephen Warren wrote:
> On 03/17/2013 10:31 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the tegra tree got a conflict in
> > drivers/clocksource/tegra20_timer.c between commit 1d16cfb3aeba
> > ("clocksource: tegra20: use the device_node pointer passed to
> > init") from the arm-soc tree and commit 6f88fb8af6c6 ("clocksource:
> > tegra: move to of_clk_get") from the tegra tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary (no
> > action is required).
>
> Thanks. This resolution looks fine.
>
> Arnd/Olof, do you want me to rebase the Tegra branch onto some arm-soc
> branch to resolve this conflict, or are you happy to simply resolve it
> as below when pulling the Tegra branches into arm-soc for 3.10?
No need to rebase. We can resolve this by merging the clksrc/cleanup
into your branch when we pull it, or you can merge it yourself.
Arnd
[-- Attachment #1: Type: text/plain, Size: 828 bytes --] Hi all, Today's linux-next merge of the tegra tree got a conflict in arch/arm64/configs/defconfig between commit e324654294907a4 ("ARM: use "depends on" for SoC configs instead of "if" after prompt") from the arm-soc tree and commit 099a6644f5be4 ("soc/tegra: Provide per-SoC Kconfig symbols") from the tegra tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). diff --cc arch/arm/mach-tegra/Kconfig index a90f3556017f,6f7bec07cda6..000000000000 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@@ -1,6 -1,5 +1,6 @@@ - menuconfig ARCH_TEGRA + config ARCH_TEGRA - bool "NVIDIA Tegra" if ARCH_MULTI_V7 + bool "NVIDIA Tegra" + depends on ARCH_MULTI_V7 select ARCH_REQUIRE_GPIOLIB select ARCH_SUPPORTS_TRUSTED_FOUNDATIONS select ARM_AMBA [-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --] Hi all, Today's linux-next merge of the tegra tree got a conflict in: arch/arm64/configs/defconfig between commit: 39bab7bfb7d9 ("arm64: configs: Remove useless UEVENT_HELPER_PATH") from the arm-soc tree and commit: 01d6fb565b4a ("arm64: defconfig: Add Tegra194 PCIe driver") from the tegra tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc arch/arm64/configs/defconfig index 3fb84219817a,6a9dc67bbfac..000000000000 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@@ -192,6 -191,8 +192,7 @@@ CONFIG_PCIE_QCOM= CONFIG_PCIE_ARMADA_8K=y CONFIG_PCIE_KIRIN=y CONFIG_PCIE_HISI_STB=y + CONFIG_PCIE_TEGRA194=m -CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_HISILICON_LPC=y [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1328 bytes --] Hi all, Today's linux-next merge of the tegra tree got conflicts in: drivers/phy/tegra/Kconfig drivers/phy/tegra/xusb.c between commits: 5a00c7c7604f ("phy: tegra: xusb: Add usb-role-switch support") 23babe30fb45 ("phy: tegra: xusb: Add usb-phy support") d74ce0954cb2 ("phy: tegra: xusb: Add support to get companion USB 3 port") 58e7bd08b569 ("phy: tegra: xusb: Add Tegra194 support") from the arm-soc tree and commit: f67213cee2b3 ("phy: tegra: xusb: Add usb-role-switch support") e8f7d2f409a1 ("phy: tegra: xusb: Add usb-phy support") 5a40fc4b934c ("phy: tegra: xusb: Add support to get companion USB 3 port") 1ef535c6ba8e ("phy: tegra: xusb: Add Tegra194 support") from the tegra tree. These are slightly different patches (the latter has been rebased). Also there are further commits affecting these files in the tegra tree. I fixed it up (I just used the version from the tegra tree) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2180 bytes --] On Fri, Mar 27, 2020 at 09:27:41AM +1100, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the tegra tree got conflicts in: > > drivers/phy/tegra/Kconfig > drivers/phy/tegra/xusb.c > > between commits: > > 5a00c7c7604f ("phy: tegra: xusb: Add usb-role-switch support") > 23babe30fb45 ("phy: tegra: xusb: Add usb-phy support") > d74ce0954cb2 ("phy: tegra: xusb: Add support to get companion USB 3 port") > 58e7bd08b569 ("phy: tegra: xusb: Add Tegra194 support") > > from the arm-soc tree and commit: > > f67213cee2b3 ("phy: tegra: xusb: Add usb-role-switch support") > e8f7d2f409a1 ("phy: tegra: xusb: Add usb-phy support") > 5a40fc4b934c ("phy: tegra: xusb: Add support to get companion USB 3 port") > 1ef535c6ba8e ("phy: tegra: xusb: Add Tegra194 support") > > from the tegra tree. > > These are slightly different patches (the latter has been rebased). > Also there are further commits affecting these files in the tegra tree. > > I fixed it up (I just used the version from the tegra tree) and can > carry the fix as necessary. This is now fixed as far as linux-next is > concerned, but any non trivial conflicts should be mentioned to your > upstream maintainer when your tree is submitted for merging. You may > also want to consider cooperating with the maintainer of the conflicting > tree to minimise any particularly complex conflicts. Olof, Arnd, There was a bit of back and forth on this because there happened to be a conflict with the USB tree. I tried to clarify this as replies to the PR request: http://patchwork.ozlabs.org/patch/1254523/ But I suspect you may have missed those replies. The bottom line is, there is a v2 of the pull request that has the patches that are now in the Tegra tree. That's already part of a PR that went in through the USB tree as a dependency to resolve the conflict. So as a result there should be no need for ARM SoC to carry that PR. But if you still want to merge it, please pull v2, which is here: git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.7-phy-v2 Sorry for the confusion, Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
On Fri, Mar 27, 2020 at 2:18 PM Thierry Reding <treding@nvidia.com> wrote:
> On Fri, Mar 27, 2020 at 09:27:41AM +1100, Stephen Rothwell wrote:
> > I fixed it up (I just used the version from the tegra tree) and can
> > carry the fix as necessary. This is now fixed as far as linux-next is
> > concerned, but any non trivial conflicts should be mentioned to your
> > upstream maintainer when your tree is submitted for merging. You may
> > also want to consider cooperating with the maintainer of the conflicting
> > tree to minimise any particularly complex conflicts.
>
> Olof, Arnd,
>
> There was a bit of back and forth on this because there happened to be a
> conflict with the USB tree. I tried to clarify this as replies to the PR
> request:
>
> http://patchwork.ozlabs.org/patch/1254523/
>
> But I suspect you may have missed those replies. The bottom line is,
> there is a v2 of the pull request that has the patches that are now in
> the Tegra tree. That's already part of a PR that went in through the USB
> tree as a dependency to resolve the conflict.
>
> So as a result there should be no need for ARM SoC to carry that PR. But
> if you still want to merge it, please pull v2, which is here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.7-phy-v2
>
It was almost at the top of the branch, so I ended up just taking it out now, it
should be gone from the soc tree by tomorrow.
I think I managed to skip it as you asked on my first pass, but then failed to
reread the message when I went through the remaining entries in patchwork.
Clearly my tooling still needs a bit of improvement.
Arnd
[-- Attachment #1: Type: text/plain, Size: 1418 bytes --] Hi all, Today's linux-next merge of the tegra tree got a conflict in: arch/arm/configs/tegra_defconfig between commit: 67c70aa86f8b ("arm/arm64: defconfig: Update configs to use the new CROS_EC options") from the arm-soc tree and commit: 3a3cb021b038 ("ARM: tegra_defconfig: Enable options useful for Nexus 7 and Acer A500") from the tegra tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc arch/arm/configs/tegra_defconfig index 8688c715ccde,729069b6d34c..000000000000 --- a/arch/arm/configs/tegra_defconfig +++ b/arch/arm/configs/tegra_defconfig @@@ -145,10 -164,15 +164,15 @@@ CONFIG_CHARGER_SMB347= CONFIG_CHARGER_TPS65090=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_LM95245=y + CONFIG_THERMAL=y + CONFIG_THERMAL_STATISTICS=y + CONFIG_CPU_THERMAL=y CONFIG_WATCHDOG=y + CONFIG_MAX77620_WATCHDOG=y CONFIG_TEGRA_WATCHDOG=y CONFIG_MFD_AS3722=y -CONFIG_MFD_CROS_EC=y +CONFIG_MFD_CROS_EC_DEV=y + CONFIG_MFD_MAX77620=y CONFIG_MFD_MAX8907=y CONFIG_MFD_STMPE=y CONFIG_MFD_PALMAS=y [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]