linux-next: manual merge of the arm-soc tree with the staging tree

linux-next: manual merge of the arm-soc tree with the staging tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/at91sam9g20.dtsi between commit 7cb2e629a240 ("ARM:
AT91: Add ADC driver to the at91sam9g20 dtsi") from the staging tree and
commit 5b6089cb6f28 ("ARM: at91: add at91sam9260 DT support") from the
arm-soc tree.

So, I didn't know what to do with this, so I used the arm-soc version of
this file (effectively throwing away the staging tree change).  Hints,
anyone?
-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120516/c5138872/attachment.sig>

linux-next: manual merge of the arm-soc tree with the staging tree

[Arnd Bergmann]

On Wednesday 16 May 2012, Stephen Rothwell wrote:
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/boot/dts/at91sam9g20.dtsi between commit 7cb2e629a240 ("ARM:
> AT91: Add ADC driver to the at91sam9g20 dtsi") from the staging tree and
> commit 5b6089cb6f28 ("ARM: at91: add at91sam9260 DT support") from the
> arm-soc tree.
> 
> So, I didn't know what to do with this, so I used the arm-soc version of
> this file (effectively throwing away the staging tree change).  Hints,
> anyone?

I suspect the addition of the adc node should just go into the
at91sam9260.dtsi file.

	Arnd

linux-next: manual merge of the arm-soc tree with the staging tree

[Greg KH]

On Wed, May 16, 2012 at 10:54:15AM +0000, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Stephen Rothwell wrote:
> > Today's linux-next merge of the arm-soc tree got a conflict in
> > arch/arm/boot/dts/at91sam9g20.dtsi between commit 7cb2e629a240 ("ARM:
> > AT91: Add ADC driver to the at91sam9g20 dtsi") from the staging tree and
> > commit 5b6089cb6f28 ("ARM: at91: add at91sam9260 DT support") from the
> > arm-soc tree.
> > 
> > So, I didn't know what to do with this, so I used the arm-soc version of
> > this file (effectively throwing away the staging tree change).  Hints,
> > anyone?
> 
> I suspect the addition of the adc node should just go into the
> at91sam9260.dtsi file.

So does that mean that the staging tree version is correct?  Or that
someone needs to send me a fixup patch here?

confused,

greg k-h

linux-next: manual merge of the arm-soc tree with the staging tree

[Arnd Bergmann]

On Wednesday 16 May 2012, Greg KH wrote:
> On Wed, May 16, 2012 at 10:54:15AM +0000, Arnd Bergmann wrote:
> > On Wednesday 16 May 2012, Stephen Rothwell wrote:
> > > Today's linux-next merge of the arm-soc tree got a conflict in
> > > arch/arm/boot/dts/at91sam9g20.dtsi between commit 7cb2e629a240 ("ARM:
> > > AT91: Add ADC driver to the at91sam9g20 dtsi") from the staging tree and
> > > commit 5b6089cb6f28 ("ARM: at91: add at91sam9260 DT support") from the
> > > arm-soc tree.
> > > 
> > > So, I didn't know what to do with this, so I used the arm-soc version of
> > > this file (effectively throwing away the staging tree change).  Hints,
> > > anyone?
> > 
> > I suspect the addition of the adc node should just go into the
> > at91sam9260.dtsi file.
> 
> So does that mean that the staging tree version is correct?  Or that
> someone needs to send me a fixup patch here?

The staging tree version adds contents to at91sam9g20.dtsi, and the context
gets moved to at91sam9260.dtsi in arm-soc. If we want to resolve it now,
I think the best way is to add the change to at91sam9260.dtsi in arm-soc
and let you drop that part in staging. There are no hard dependencies
since this is new code and it the driver is still correct without the
change, it simply won't find the device.

	Arnd

linux-next: manual merge of the arm-soc tree with the staging tree

[Greg KH]

On Wed, May 16, 2012 at 01:03:34PM +0000, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Greg KH wrote:
> > On Wed, May 16, 2012 at 10:54:15AM +0000, Arnd Bergmann wrote:
> > > On Wednesday 16 May 2012, Stephen Rothwell wrote:
> > > > Today's linux-next merge of the arm-soc tree got a conflict in
> > > > arch/arm/boot/dts/at91sam9g20.dtsi between commit 7cb2e629a240 ("ARM:
> > > > AT91: Add ADC driver to the at91sam9g20 dtsi") from the staging tree and
> > > > commit 5b6089cb6f28 ("ARM: at91: add at91sam9260 DT support") from the
> > > > arm-soc tree.
> > > > 
> > > > So, I didn't know what to do with this, so I used the arm-soc version of
> > > > this file (effectively throwing away the staging tree change).  Hints,
> > > > anyone?
> > > 
> > > I suspect the addition of the adc node should just go into the
> > > at91sam9260.dtsi file.
> > 
> > So does that mean that the staging tree version is correct?  Or that
> > someone needs to send me a fixup patch here?
> 
> The staging tree version adds contents to at91sam9g20.dtsi, and the context
> gets moved to at91sam9260.dtsi in arm-soc. If we want to resolve it now,
> I think the best way is to add the change to at91sam9260.dtsi in arm-soc
> and let you drop that part in staging. There are no hard dependencies
> since this is new code and it the driver is still correct without the
> change, it simply won't find the device.

Ok, so if we leave it as-is for now, we can resolve it after 3.5-rc1 is
out and we see what branch ended up "winning"?  :)

greg k-h

linux-next: manual merge of the arm-soc tree with the staging tree

[Arnd Bergmann]

On Wednesday 16 May 2012, Greg KH wrote:
> On Wed, May 16, 2012 at 01:03:34PM +0000, Arnd Bergmann wrote:
> > The staging tree version adds contents to at91sam9g20.dtsi, and the context
> > gets moved to at91sam9260.dtsi in arm-soc. If we want to resolve it now,
> > I think the best way is to add the change to at91sam9260.dtsi in arm-soc
> > and let you drop that part in staging. There are no hard dependencies
> > since this is new code and it the driver is still correct without the
> > change, it simply won't find the device.
> 
> Ok, so if we leave it as-is for now, we can resolve it after 3.5-rc1 is
> out and we see what branch ended up "winning"?  :)

Yes, works for me.

	Arnd

linux-next: manual merge of the arm-soc tree with the staging tree

[Nicolas Ferre]

On 05/16/2012 12:54 PM, Arnd Bergmann :
> On Wednesday 16 May 2012, Stephen Rothwell wrote:
>> Today's linux-next merge of the arm-soc tree got a conflict in
>> arch/arm/boot/dts/at91sam9g20.dtsi between commit 7cb2e629a240 ("ARM:
>> AT91: Add ADC driver to the at91sam9g20 dtsi") from the staging tree and
>> commit 5b6089cb6f28 ("ARM: at91: add at91sam9260 DT support") from the
>> arm-soc tree.
>>
>> So, I didn't know what to do with this, so I used the arm-soc version of
>> this file (effectively throwing away the staging tree change).  Hints,
>> anyone?
> 
> I suspect the addition of the adc node should just go into the
> at91sam9260.dtsi file.

Well, not so sure...

Hi all,

I am on the subject till this morning to figure out if the parameters
are SoC dependent. It seems that the ADC is the same between those two
platforms but the technology is different: I have to figure out the
details internally.

I will give you a patch on top of arm-soc soon. It will replace the one
in staging-next: does it sound good to you?

Bye,
-- 
Nicolas Ferre

linux-next: manual merge of the arm-soc tree with the staging tree

[Arnd Bergmann]

On Wednesday 16 May 2012, Nicolas Ferre wrote:
> I am on the subject till this morning to figure out if the parameters
> are SoC dependent. It seems that the ADC is the same between those two
> platforms but the technology is different: I have to figure out the
> details internally.
> 
> I will give you a patch on top of arm-soc soon. It will replace the one
> in staging-next: does it sound good to you?

Ok, good.

	Arnd

[PATCH] ARM: at91: Add ADC driver to at91sam9260/at91sam9g20 dtsi files

[Nicolas Ferre]

Now that the bulk of at91sam9g20-related nodes are located in at91sam9260.dtsi,
we have to re-create the path to this ADC node for SoC specific parts.

Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
 arch/arm/boot/dts/at91sam9260.dtsi |   35 +++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/at91sam9g20.dtsi |    8 ++++++++
 2 files changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index f4605ff..f449efc 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -197,6 +197,41 @@
 				interrupts = <10 4>;
 				status = "disabled";
 			};
+
+			adc0: adc at fffe0000 {
+				compatible = "atmel,at91sam9260-adc";
+				reg = <0xfffe0000 0x100>;
+				interrupts = <5 4>;
+				atmel,adc-use-external-triggers;
+				atmel,adc-channels-used = <0xf>;
+				atmel,adc-vref = <3300>;
+				atmel,adc-num-channels = <4>;
+				atmel,adc-startup-time = <15>;
+				atmel,adc-channel-base = <0x30>;
+				atmel,adc-drdy-mask = <0x10000>;
+				atmel,adc-status-register = <0x1c>;
+				atmel,adc-trigger-register = <0x04>;
+
+				trigger at 0 {
+					trigger-name = "timer-counter-0";
+					trigger-value = <0x1>;
+				};
+				trigger at 1 {
+					trigger-name = "timer-counter-1";
+					trigger-value = <0x3>;
+				};
+
+				trigger at 2 {
+					trigger-name = "timer-counter-2";
+					trigger-value = <0x5>;
+				};
+
+				trigger at 3 {
+					trigger-name = "external";
+					trigger-value = <0x13>;
+					trigger-external;
+				};
+			};
 		};
 
 		nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi b/arch/arm/boot/dts/at91sam9g20.dtsi
index 0eb1a75..2a1d1ca 100644
--- a/arch/arm/boot/dts/at91sam9g20.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20.dtsi
@@ -15,4 +15,12 @@
 	memory {
 		reg = <0x20000000 0x08000000>;
 	};
+
+	ahb {
+		apb {
+			adc0: adc at fffe0000 {
+				atmel,adc-startup-time = <40>;
+			};
+		};
+	};
 };
-- 
1.7.10

[PATCH] ARM: at91: Add ADC driver to at91sam9260/at91sam9g20 dtsi files

[Arnd Bergmann]

On Wednesday 16 May 2012, Nicolas Ferre wrote:
> Now that the bulk of at91sam9g20-related nodes are located in at91sam9260.dtsi,
> we have to re-create the path to this ADC node for SoC specific parts.
> 
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>

Should we apply this patch in arm-soc so that Greg can drop the hunk that
no longer applies?

	Arnd

[PATCH] ARM: at91: Add ADC driver to at91sam9260/at91sam9g20 dtsi files

[Greg KH]

On Wed, May 16, 2012 at 06:50:54PM +0000, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Nicolas Ferre wrote:
> > Now that the bulk of at91sam9g20-related nodes are located in at91sam9260.dtsi,
> > we have to re-create the path to this ADC node for SoC specific parts.
> > 
> > Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> 
> Should we apply this patch in arm-soc so that Greg can drop the hunk that
> no longer applies?

It's not a "no longer applies", it's a "this does not merge".  The patch
is in my tree, unless you want me to revert it, it's going to stay there
until it goes to Linus.

thanks,

greg k-h

[PATCH] ARM: at91: Add ADC driver to at91sam9260/at91sam9g20 dtsi files

[Stephen Rothwell]

Hi all,

On Thu, 17 May 2012 08:06:01 -0700 Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, May 16, 2012 at 06:50:54PM +0000, Arnd Bergmann wrote:
> > On Wednesday 16 May 2012, Nicolas Ferre wrote:
> > > Now that the bulk of at91sam9g20-related nodes are located in at91sam9260.dtsi,
> > > we have to re-create the path to this ADC node for SoC specific parts.
> > > 
> > > Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> > 
> > Should we apply this patch in arm-soc so that Greg can drop the hunk that
> > no longer applies?
> 
> It's not a "no longer applies", it's a "this does not merge".  The patch
> is in my tree, unless you want me to revert it, it's going to stay there
> until it goes to Linus.

Just apply the patch to the arm-soc tree - then the merge resolution
becomes "use the arm-soc version".   There is no need for Greg to revert
the other patch.

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120518/210f51f5/attachment.sig>

[PATCH] ARM: at91: Add ADC driver to at91sam9260/at91sam9g20 dtsi files

[Arnd Bergmann]

On Thursday 17 May 2012, Stephen Rothwell wrote:
> On Thu, 17 May 2012 08:06:01 -0700 Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, May 16, 2012 at 06:50:54PM +0000, Arnd Bergmann wrote:
> > > On Wednesday 16 May 2012, Nicolas Ferre wrote:
> > > > Now that the bulk of at91sam9g20-related nodes are located in at91sam9260.dtsi,
> > > > we have to re-create the path to this ADC node for SoC specific parts.
> > > > 
> > > > Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> > > 
> > > Should we apply this patch in arm-soc so that Greg can drop the hunk that
> > > no longer applies?
> > 
> > It's not a "no longer applies", it's a "this does not merge".  The patch
> > is in my tree, unless you want me to revert it, it's going to stay there
> > until it goes to Linus.
> 
> Just apply the patch to the arm-soc tree - then the merge resolution
> becomes "use the arm-soc version".   There is no need for Greg to revert
> the other patch.
> 

Yes, good point.

I've applied the patch on the at91/dt branch now.

	Arnd

[PATCH] ARM: at91: Add ADC driver to at91sam9260/at91sam9g20 dtsi files

[Nicolas Ferre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/18/2012 12:44 AM, Stephen Rothwell :
> Hi all,
> 
> On Thu, 17 May 2012 08:06:01 -0700 Greg KH
> <gregkh@linuxfoundation.org> wrote:
>> 
>> On Wed, May 16, 2012 at 06:50:54PM +0000, Arnd Bergmann wrote:
>>> On Wednesday 16 May 2012, Nicolas Ferre wrote:
>>>> Now that the bulk of at91sam9g20-related nodes are located in
>>>> at91sam9260.dtsi, we have to re-create the path to this ADC
>>>> node for SoC specific parts.
>>>> 
>>>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>>> 
>>> Should we apply this patch in arm-soc so that Greg can drop the
>>> hunk that no longer applies?
>> 
>> It's not a "no longer applies", it's a "this does not merge".
>> The patch is in my tree, unless you want me to revert it, it's
>> going to stay there until it goes to Linus.
> 
> Just apply the patch to the arm-soc tree - then the merge
> resolution becomes "use the arm-soc version".   There is no need
> for Greg to revert the other patch.

Hi Stephen,

After checking the current status of
arch/arm/boot/dts/at91sam9g20.dtsi in linux-next, it seems the merge
resolution has not produced a good result:

The "adc0" node, should only look like:

ahb {
        apb {
                adc0: adc at fffe0000 {
                        atmel,adc-startup-time = <40>;
                };
        };
};

without the redundant code carried by the staging git tree. In short,
the arm-soc version is the proper one.

Thanks for your help, best regards,
- -- 
Nicolas Ferre
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPuhR7AAoJEAf03oE53VmQW4wH/0lqpqrTujJ/dQ0z5Ku7Xde3
EKKJm51AIlIadOXiteYH6cw34ISm68cXZWpkbKh3UKiCcJGSJi4VjCrkcJ//CwUL
B4bZD3A6Y8zLQ+TaQbjMnfzKq2dOBRQ1M1dNoQXwPe83vjV85T4hoKco7LBhGhUI
l//0aWrcefH9sQynAYRhNE0M6hlfr/Edlia0zHlkVYqE2K5ALxaH6lki2EUzxvJC
l8qydZ9lum37ebnot09WB2qhIlkRApb50sYbQG4nMwlC3jSblXrPelQvChWLo/yi
JOPOF7Lcj9fnJmeVGlQknobilgWmRnuVQUbqBG4NjDx71k5WiEywF6ymBa8TJnA=
=rnQu
-----END PGP SIGNATURE-----

[PATCH] ARM: at91: Add ADC driver to at91sam9260/at91sam9g20 dtsi files

[Stephen Rothwell]

Hi Nicolas,

On Mon, 21 May 2012 12:10:11 +0200 Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>
> After checking the current status of
> arch/arm/boot/dts/at91sam9g20.dtsi in linux-next, it seems the merge
> resolution has not produced a good result:
> 
> The "adc0" node, should only look like:
> 
> ahb {
>         apb {
>                 adc0: adc at fffe0000 {
>                         atmel,adc-startup-time = <40>;
>                 };
>         };
> };
> 
> without the redundant code carried by the staging git tree. In short,
> the arm-soc version is the proper one.

Rats!  That was an automatic merge resolution and I didn't even notice,
sorry.  I will fix it up today in linux-next, but someone needs to
remember to tell Linus when the second if these two trees is merged.

I will apply the following as a merge fixup patch after merging the
arm-soc tree (which comes later in my sequence):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 22 May 2012 09:17:31 +1000
Subject: [PATCH] ARM:at91: merge fixup for dtsi file

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/boot/dts/at91sam9g20.dtsi |   35 -----------------------------------
 1 file changed, 35 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi b/arch/arm/boot/dts/at91sam9g20.dtsi
index 06ca15b..2a1d1ca 100644
--- a/arch/arm/boot/dts/at91sam9g20.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20.dtsi
@@ -21,41 +21,6 @@
 			adc0: adc at fffe0000 {
 				atmel,adc-startup-time = <40>;
 			};
-
-			adc0: adc at fffe0000 {
-				compatible = "atmel,at91sam9260-adc";
-				reg = <0xfffe0000 0x100>;
-				interrupts = <5 4>;
-				atmel,adc-use-external-triggers;
-				atmel,adc-channels-used = <0xf>;
-				atmel,adc-vref = <3300>;
-				atmel,adc-num-channels = <4>;
-				atmel,adc-startup-time = <10>;
-				atmel,adc-channel-base = <0x30>;
-				atmel,adc-drdy-mask = <0x10000>;
-				atmel,adc-status-register = <0x1c>;
-				atmel,adc-trigger-register = <0x04>;
-
-				trigger at 0 {
-					trigger-name = "timer-counter-0";
-					trigger-value = <0x1>;
-				};
-				trigger at 1 {
-					trigger-name = "timer-counter-1";
-					trigger-value = <0x3>;
-				};
-
-				trigger at 2 {
-					trigger-name = "timer-counter-2";
-					trigger-value = <0x5>;
-				};
-
-				trigger at 3 {
-					trigger-name = "external";
-					trigger-value = <0x13>;
-					trigger-external;
-				};
-			};
 		};
 	};
 };
-- 
1.7.10.280.gaa39

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120522/23e7fd0b/attachment.sig>