[PATCH 0/2] Armada 8040 MachiatoBin and DB improvements

[PATCH 0/2] Armada 8040 MachiatoBin and DB improvements

[Marcin Wojtas]

Hi,

This very short series apply improvements to two Armada 8040 boards,
adding missing 'chosen' node for MachiatoBin and some of the interfaces
hitherto not present in device trees, but yet supported in the kernel.

I'm looking forward to any comments or remarks.

Best regards,
Marcin

Marcin Wojtas (2):
  arm64: marvell: dts: fill MachiatoBin board description
  arm64: marvell: dts: add second 1G port on the Armada 8040 DB

 arch/arm64/boot/dts/marvell/armada-8040-db.dts    | 16 +++++++++++
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 34 +++++++++++++++++++++++
 2 files changed, 50 insertions(+)

-- 
1.8.3.1

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Marcin Wojtas]

This patch adds following improvements to Armada 8040
MachiatoBin:
 * Add 'chosen' node with stdout-path assignment
 * Enable 1G sgmii port
 * Enable SDHCI controllers on AP and CP HW blocks

Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 34 +++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
index f7bb0cc..19d395b 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -51,6 +51,10 @@
 	compatible = "marvell,armada8040-mcbin", "marvell,armada8040",
 			"marvell,armada-ap806-quad", "marvell,armada-ap806";
 
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
 	memory at 00000000 {
 		device_type = "memory";
 		reg = <0x0 0x0 0x0 0x80000000>;
@@ -136,3 +140,33 @@
 	usb-phy = <&usb3h0_phy>;
 	status = "okay";
 };
+
+&cpm_mdio {
+	phy0: ethernet-phy at 0 {
+		reg = <0>;
+	};
+};
+
+&cps_ethernet {
+	status = "okay";
+};
+
+&cps_eth1 {
+	status = "okay";
+	phy = <&phy0>;
+	phy-mode = "sgmii";
+};
+
+&ap_sdhci0 {
+	status = "okay";
+	bus-width = <8>;
+	no-1-8-v;
+	non-removable;
+};
+
+&cpm_sdhci0 {
+	status = "okay";
+	bus-width = <4>;
+	no-1-8-v;
+	non-removable;
+};
-- 
1.8.3.1

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Russell King - ARM Linux]

On Tue, May 16, 2017 at 01:28:32AM +0200, Marcin Wojtas wrote:
> This patch adds following improvements to Armada 8040
> MachiatoBin:
>  * Add 'chosen' node with stdout-path assignment
>  * Enable 1G sgmii port
>  * Enable SDHCI controllers on AP and CP HW blocks
> 
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>

Please check my repository at:

	git://git.armlinux.org.uk/~rmk/linux-arm.git mcbin

I'm currently in the big post-merge window rebase, but that branch has
almost complete support for the board, including work in progress for
upgrading phylib for 10G support.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Marcin Wojtas]

Hi Russel,

2017-05-16 1:28 GMT+02:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
>
> On Tue, May 16, 2017 at 01:28:32AM +0200, Marcin Wojtas wrote:
> > This patch adds following improvements to Armada 8040
> > MachiatoBin:
> >  * Add 'chosen' node with stdout-path assignment
> >  * Enable 1G sgmii port
> >  * Enable SDHCI controllers on AP and CP HW blocks
> >
> > Signed-off-by: Marcin Wojtas <mw@semihalf.com>
>
> Please check my repository at:
>
>         git://git.armlinux.org.uk/~rmk/linux-arm.git mcbin
>
> I'm currently in the big post-merge window rebase, but that branch has
> almost complete support for the board, including work in progress for
> upgrading phylib for 10G support.
>

I do not intend to interfere your work at all. I took a look on your
branch, and my patch does not seem to be really colliding with it. The
board is starting to get really popular and a lot has been happening
around it recently - missing bits like 'chosen' node or the interfaces
is pretty annoying. Therefore I think, the earlier such things get
merged into the tree, the better (we can also enable &cpm_pcie0, just
tested it), since with current kernel it's no-cost, quick DT update.

I have no problem if you insist to use your own DT patches - if so
could you possibly submit them, so that there may be still some chance
that they reach v4.12? I can see some significant work ahead on your
branch (e.g. transition from out-of-tree network driver to mvpp2), so
better not be blocked by this.

Best regards,
Marcin

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Russell King - ARM Linux]

On Tue, May 16, 2017 at 11:27:19AM +0200, Marcin Wojtas wrote:
> I do not intend to interfere your work at all. I took a look on your
> branch, and my patch does not seem to be really colliding with it.

I can't see how you can say that when the branch contains support for
SDHCI and ethernet.  It obviously will collide, since it conflicts with
the changes I have.

> The board is starting to get really popular and a lot has been happening
> around it recently - missing bits like 'chosen' node or the interfaces
> is pretty annoying.

Given that features like SDHCI and basic ethernet support have only just
been merged during the merge window, how about giving those who are
supporting the platform some time to organise their trees and get patches
out there, rather than cutting across those who have put considerable
effort into the platform already, or working with those who have.

The whole Armada 8k support is all very new, and there's still lots of
fundamental bits that are missing - pinmux and gpio are the two biggest
ones.

I've already put effort into cleaning up the mvebu pinmux code (already
merged) so that we can cleanly merge the pinmux support, but both of
these are a sticking point with free-electrons - they have a view on
how it should be represented in DT which does not fit with the current
orion-gpio usage, nor with the "system controller" being in drivers/clk.

The code which I have in my tree is correct for the Armada 8k hardware
(which has some weirdness about which gpios on each CP110 appear to the
external world - some are used for inter-CP110 communication and must
not be exposed) so any additional work should be based on the code in
my tree.

I have no solution for the sticking point at present, and this is an
area that's worth additional effort to resolve.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Thomas Petazzoni]

Hello,

On Tue, 16 May 2017 10:50:27 +0100, Russell King - ARM Linux wrote:

> I can't see how you can say that when the branch contains support for
> SDHCI and ethernet.  It obviously will collide, since it conflicts with
> the changes I have.

Correct, but Marcin has submitted patches, and you haven't.

> > The board is starting to get really popular and a lot has been happening
> > around it recently - missing bits like 'chosen' node or the interfaces
> > is pretty annoying.  
> 
> Given that features like SDHCI and basic ethernet support have only just
> been merged during the merge window, how about giving those who are
> supporting the platform some time to organise their trees and get patches
> out there, rather than cutting across those who have put considerable
> effort into the platform already, or working with those who have.

I believe if you say that, it's because you don't know how much work
Marcin is doing behind the scenes on supporting Marvell platforms, and
not only at the Linux kernel level.

And it's difficult to buy your argument here, because Marcin is
*precisely* supporting the platform by sending useful patches.

> The whole Armada 8k support is all very new, and there's still lots of
> fundamental bits that are missing - pinmux and gpio are the two biggest
> ones.
> 
> I've already put effort into cleaning up the mvebu pinmux code (already
> merged) so that we can cleanly merge the pinmux support, but both of
> these are a sticking point with free-electrons - they have a view on
> how it should be represented in DT which does not fit with the current
> orion-gpio usage, nor with the "system controller" being in drivers/clk.

Gr?gory Clement has been working on this, and he has a patch series
almost ready to submission.

> The code which I have in my tree is correct for the Armada 8k hardware
> (which has some weirdness about which gpios on each CP110 appear to the
> external world - some are used for inter-CP110 communication and must
> not be exposed) so any additional work should be based on the code in
> my tree.

No, there is no rule like this in the kernel community. Whatever is in
your private tree does not matter. Until it gets submitted, it doesn't
exist, and nobody is forced to base its work on top of your
unknown/private trees.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Russell King - ARM Linux]

On Tue, May 16, 2017 at 11:55:35AM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Tue, 16 May 2017 10:50:27 +0100, Russell King - ARM Linux wrote:
> 
> > I can't see how you can say that when the branch contains support for
> > SDHCI and ethernet.  It obviously will collide, since it conflicts with
> > the changes I have.
> 
> Correct, but Marcin has submitted patches, and you haven't.

As I said, give me a friggin chance.  You know full well that I've been
working on this, working with you and submitting patches.

> > > The board is starting to get really popular and a lot has been happening
> > > around it recently - missing bits like 'chosen' node or the interfaces
> > > is pretty annoying.  
> > 
> > Given that features like SDHCI and basic ethernet support have only just
> > been merged during the merge window, how about giving those who are
> > supporting the platform some time to organise their trees and get patches
> > out there, rather than cutting across those who have put considerable
> > effort into the platform already, or working with those who have.
> 
> I believe if you say that, it's because you don't know how much work
> Marcin is doing behind the scenes on supporting Marvell platforms, and
> not only at the Linux kernel level.

Maybe Marcin doesn't know how much work I'm doing supporting this board?

> > The whole Armada 8k support is all very new, and there's still lots of
> > fundamental bits that are missing - pinmux and gpio are the two biggest
> > ones.
> > 
> > I've already put effort into cleaning up the mvebu pinmux code (already
> > merged) so that we can cleanly merge the pinmux support, but both of
> > these are a sticking point with free-electrons - they have a view on
> > how it should be represented in DT which does not fit with the current
> > orion-gpio usage, nor with the "system controller" being in drivers/clk.
> 
> Gr?gory Clement has been working on this, and he has a patch series
> almost ready to submission.

You've seen my patches, because I've sent them to you in the past.

> > The code which I have in my tree is correct for the Armada 8k hardware
> > (which has some weirdness about which gpios on each CP110 appear to the
> > external world - some are used for inter-CP110 communication and must
> > not be exposed) so any additional work should be based on the code in
> > my tree.
> 
> No, there is no rule like this in the kernel community. Whatever is in
> your private tree does not matter. Until it gets submitted, it doesn't
> exist, and nobody is forced to base its work on top of your
> unknown/private trees.

It _has_ been submitted - a few months ago - so you're talking rubbish
here.  You just need to check your mailbox.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Thomas Petazzoni]

Hello,

On Tue, 16 May 2017 11:02:37 +0100, Russell King - ARM Linux wrote:

> > Correct, but Marcin has submitted patches, and you haven't.  
> 
> As I said, give me a friggin chance.  You know full well that I've been
> working on this, working with you and submitting patches.

Correct. But Marcin patches are small and easy, they are ready today,
and they bring useful benefits for users. You're trying to provide a
full blown solution, which ultimately is good, but in the mean time it
would be good to enable the features that already work today.

> > I believe if you say that, it's because you don't know how much work
> > Marcin is doing behind the scenes on supporting Marvell platforms, and
> > not only at the Linux kernel level.  
> 
> Maybe Marcin doesn't know how much work I'm doing supporting this board?

Marcin also knows you're doing some work on this board.

> > Gr?gory Clement has been working on this, and he has a patch series
> > almost ready to submission.  
> 
> You've seen my patches, because I've sent them to you in the past.
> 
> > > The code which I have in my tree is correct for the Armada 8k hardware
> > > (which has some weirdness about which gpios on each CP110 appear to the
> > > external world - some are used for inter-CP110 communication and must
> > > not be exposed) so any additional work should be based on the code in
> > > my tree.  
> > 
> > No, there is no rule like this in the kernel community. Whatever is in
> > your private tree does not matter. Until it gets submitted, it doesn't
> > exist, and nobody is forced to base its work on top of your
> > unknown/private trees.  
> 
> It _has_ been submitted - a few months ago - so you're talking rubbish
> here.  You just need to check your mailbox.

Could you please avoid insults? It doesn't bring any benefit.

And in addition, you're deforming reality. The reality is:

 - The patches you posted are related to pinmux/gpio support. This is
   one thing.

 - The patches posted by Marcin do not touch anything pinmux/gpio
   related.

Therefore, there is no reason to not merge Marcin patches, because they
do not conflict with anything you have already posted. If Marcin
patches were complicated and causing severe conflicts with what you
already have, I would definitely understand your arguments. But here,
Marcin patches are simply and easy DT patches, rebasing on top of them
and fixing the minor conflicts will be trivial.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Russell King - ARM Linux]

On Tue, May 16, 2017 at 01:52:17PM +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Tue, 16 May 2017 11:02:37 +0100, Russell King - ARM Linux wrote:
> 
> > > Correct, but Marcin has submitted patches, and you haven't.  
> > 
> > As I said, give me a friggin chance.  You know full well that I've been
> > working on this, working with you and submitting patches.
> 
> Correct. But Marcin patches are small and easy, they are ready today,
> and they bring useful benefits for users. You're trying to provide a
> full blown solution, which ultimately is good, but in the mean time it
> would be good to enable the features that already work today.

Unfortunately, they don't all work - see my other email.  The SD slot
is non-functional with the latest sdhci-xenon driver.  The previous
revision worked fine.

> > > I believe if you say that, it's because you don't know how much work
> > > Marcin is doing behind the scenes on supporting Marvell platforms, and
> > > not only at the Linux kernel level.  
> > 
> > Maybe Marcin doesn't know how much work I'm doing supporting this board?
> 
> Marcin also knows you're doing some work on this board.

Right, so this is all one way.  It would have been nice to have had a
heads-up or something, which would have aided co-operation instead of
confrontation.

> > It _has_ been submitted - a few months ago - so you're talking rubbish
> > here.  You just need to check your mailbox.
> 
> Could you please avoid insults? It doesn't bring any benefit.
> 
> And in addition, you're deforming reality. The reality is:
> 
>  - The patches you posted are related to pinmux/gpio support. This is
>    one thing.

The point you replied to was about pinmux/gpio, not about Marcin's patch.
So you trying to twist this back to Marcin's patches is unhelpful.
Stop being a problem.

> Therefore, there is no reason to not merge Marcin patches, because they
> do not conflict with anything you have already posted.

Except that the SD slot is broken.

Anyone can produce and post untested patches, but that's not really
the point of kernel development.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Marcin Wojtas]

Russel,

2017-05-16 14:13 GMT+02:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
> On Tue, May 16, 2017 at 01:52:17PM +0200, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Tue, 16 May 2017 11:02:37 +0100, Russell King - ARM Linux wrote:
>>
>> > > Correct, but Marcin has submitted patches, and you haven't.
>> >
>> > As I said, give me a friggin chance.  You know full well that I've been
>> > working on this, working with you and submitting patches.
>>
>> Correct. But Marcin patches are small and easy, they are ready today,
>> and they bring useful benefits for users. You're trying to provide a
>> full blown solution, which ultimately is good, but in the mean time it
>> would be good to enable the features that already work today.
>
> Unfortunately, they don't all work - see my other email.  The SD slot
> is non-functional with the latest sdhci-xenon driver.  The previous
> revision worked fine.
>
>> > > I believe if you say that, it's because you don't know how much work
>> > > Marcin is doing behind the scenes on supporting Marvell platforms, and
>> > > not only at the Linux kernel level.
>> >
>> > Maybe Marcin doesn't know how much work I'm doing supporting this board?
>>
>> Marcin also knows you're doing some work on this board.
>
> Right, so this is all one way.  It would have been nice to have had a
> heads-up or something, which would have aided co-operation instead of
> confrontation.
>
>> > It _has_ been submitted - a few months ago - so you're talking rubbish
>> > here.  You just need to check your mailbox.
>>
>> Could you please avoid insults? It doesn't bring any benefit.
>>
>> And in addition, you're deforming reality. The reality is:
>>
>>  - The patches you posted are related to pinmux/gpio support. This is
>>    one thing.
>
> The point you replied to was about pinmux/gpio, not about Marcin's patch.
> So you trying to twist this back to Marcin's patches is unhelpful.
> Stop being a problem.
>
>> Therefore, there is no reason to not merge Marcin patches, because they
>> do not conflict with anything you have already posted.
>
> Except that the SD slot is broken.
>

Rechecked, on my board - copied 100MB file back and forth to and from
SD card and it works properly, so indeed that may be some regression
in the latest version of the driver, but apparently not for all cards.

>
> Anyone can produce and post untested patches, but that's not really
> the point of kernel development.

Thanks for the lesson. I won't confront you any further with any more patches.

Best regards,
Marcin

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Russell King - ARM Linux]

On Tue, May 16, 2017 at 02:44:48PM +0200, Marcin Wojtas wrote:
> Russel,
> 
> 2017-05-16 14:13 GMT+02:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
> > On Tue, May 16, 2017 at 01:52:17PM +0200, Thomas Petazzoni wrote:
> >> Hello,
> >>
> >> On Tue, 16 May 2017 11:02:37 +0100, Russell King - ARM Linux wrote:
> >>
> >> > > Correct, but Marcin has submitted patches, and you haven't.
> >> >
> >> > As I said, give me a friggin chance.  You know full well that I've been
> >> > working on this, working with you and submitting patches.
> >>
> >> Correct. But Marcin patches are small and easy, they are ready today,
> >> and they bring useful benefits for users. You're trying to provide a
> >> full blown solution, which ultimately is good, but in the mean time it
> >> would be good to enable the features that already work today.
> >
> > Unfortunately, they don't all work - see my other email.  The SD slot
> > is non-functional with the latest sdhci-xenon driver.  The previous
> > revision worked fine.
> >
> >> > > I believe if you say that, it's because you don't know how much work
> >> > > Marcin is doing behind the scenes on supporting Marvell platforms, and
> >> > > not only at the Linux kernel level.
> >> >
> >> > Maybe Marcin doesn't know how much work I'm doing supporting this board?
> >>
> >> Marcin also knows you're doing some work on this board.
> >
> > Right, so this is all one way.  It would have been nice to have had a
> > heads-up or something, which would have aided co-operation instead of
> > confrontation.
> >
> >> > It _has_ been submitted - a few months ago - so you're talking rubbish
> >> > here.  You just need to check your mailbox.
> >>
> >> Could you please avoid insults? It doesn't bring any benefit.
> >>
> >> And in addition, you're deforming reality. The reality is:
> >>
> >>  - The patches you posted are related to pinmux/gpio support. This is
> >>    one thing.
> >
> > The point you replied to was about pinmux/gpio, not about Marcin's patch.
> > So you trying to twist this back to Marcin's patches is unhelpful.
> > Stop being a problem.
> >
> >> Therefore, there is no reason to not merge Marcin patches, because they
> >> do not conflict with anything you have already posted.
> >
> > Except that the SD slot is broken.
> >
> 
> Rechecked, on my board - copied 100MB file back and forth to and from
> SD card and it works properly, so indeed that may be some regression
> in the latest version of the driver, but apparently not for all cards.

It doesn't seem to be "not for all cards" - if I boot without a card in
the slot, I still get the kernel message spew.  Turns out to be a merge
error, which I hadn't realised due to the pressure of this thread.

However, since I have a patch which adds SDHCI support with the comments
that Tom has against yours already fixed (which is a trivial subset of
my patch adding SDHCI with pinmux support) I'm about to send that.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Russell King - ARM Linux]

On Tue, May 16, 2017 at 11:27:19AM +0200, Marcin Wojtas wrote:
> I do not intend to interfere your work at all. I took a look on your
> branch, and my patch does not seem to be really colliding with it. The
> board is starting to get really popular and a lot has been happening
> around it recently - missing bits like 'chosen' node or the interfaces
> is pretty annoying.

Can you describe what the problem is with the missing "chosen" node?

It seems that command line arguments get passed into the kernel here
just fine without it:

Kernel command line: console=ttyS0,115200 panic=5 rootdelay=4 root=/dev/sda3 libata.force=3.0G

for a kernel built with:

CONFIG_CMDLINE=""

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Marcin Wojtas]

2017-05-16 13:16 GMT+02:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
> On Tue, May 16, 2017 at 11:27:19AM +0200, Marcin Wojtas wrote:
>> I do not intend to interfere your work at all. I took a look on your
>> branch, and my patch does not seem to be really colliding with it. The
>> board is starting to get really popular and a lot has been happening
>> around it recently - missing bits like 'chosen' node or the interfaces
>> is pretty annoying.
>
> Can you describe what the problem is with the missing "chosen" node?
>
> It seems that command line arguments get passed into the kernel here
> just fine without it:
>
> Kernel command line: console=ttyS0,115200 panic=5 rootdelay=4 root=/dev/sda3 libata.force=3.0G
>
> for a kernel built with:
>
> CONFIG_CMDLINE=""
>

It will be very useful e.g. for UEFI boot.

Marcin

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Russell King - ARM Linux]

On Tue, May 16, 2017 at 01:28:32AM +0200, Marcin Wojtas wrote:
> +&cpm_sdhci0 {
> +	status = "okay";
> +	bus-width = <4>;
> +	no-1-8-v;
> +	non-removable;
> +};

Testing the latest free-electrons sdhci driver (that was merged in 4.12-rc1)
_fails_ on mcbin, with it spewing:

mmc1: Timeout waiting for hardware cmd interrupt.
mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
mmc1: sdhci: Sys addr:  0x00000000 | Version:  0x00000002
mmc1: sdhci: Blk size:  0x00000000 | Blk cnt:  0x00000000
mmc1: sdhci: Argument:  0x00000000 | Trn mode: 0x00000000
mmc1: sdhci: Present:   0x01ff0000 | Host ctl: 0x00000001
mmc1: sdhci: Power:     0x0000000f | Blk gap:  0x00000000
mmc1: sdhci: Wake-up:   0x00000000 | Clock:    0x00003947
mmc1: sdhci: Timeout:   0x00000000 | Int stat: 0x00018000
mmc1: sdhci: Int enab:  0x00ff0003 | Sig enab: 0x00ff0003
mmc1: sdhci: AC12 err:  0x00000000 | Slot int: 0x00000001
mmc1: sdhci: Caps:      0x35ee0099 | Caps_1:   0x0000af77
mmc1: sdhci: Cmd:       0x00000000 | Max curr: 0x00000000
mmc1: sdhci: Resp[0]:   0x00000000 | Resp[1]:  0x00000000
mmc1: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
mmc1: sdhci: Host ctl2: 0x00000000
mmc1: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x0000000000000000
mmc1: sdhci: ============================================

It doesn't matter if I use my DT or your DT fragment above.  This used
to work fine with the previous revision of the sdhci-xenon driver.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Thomas Petazzoni]

Hello,

On Tue, 16 May 2017 01:28:32 +0200, Marcin Wojtas wrote:

> +&cps_eth1 {
> +	status = "okay";
> +	phy = <&phy0>;
> +	phy-mode = "sgmii";
> +};

It would be nice to indicate which connector is that, like is done in
the rest of this Device Tree file.

> +&ap_sdhci0 {
> +	status = "okay";
> +	bus-width = <8>;
> +	no-1-8-v;
> +	non-removable;
> +};
> +
> +&cpm_sdhci0 {
> +	status = "okay";
> +	bus-width = <4>;
> +	no-1-8-v;
> +	non-removable;
> +};

Same comment. Also, are they both really non-removable? I have a uSD
card connector on my MacchiatoBin board. It isn't covered by those new
entries ?

Also, fix the wording of MacchiatoBin in your commit title/commit log.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

[Russell King - ARM Linux]

On Tue, May 16, 2017 at 02:34:46PM +0200, Thomas Petazzoni wrote:
> > +&ap_sdhci0 {
> > +	status = "okay";
> > +	bus-width = <8>;
> > +	no-1-8-v;
> > +	non-removable;
> > +};
> > +
> > +&cpm_sdhci0 {
> > +	status = "okay";
> > +	bus-width = <4>;
> > +	no-1-8-v;
> > +	non-removable;
> > +};
> 
> Same comment. Also, are they both really non-removable? I have a uSD
> card connector on my MacchiatoBin board. It isn't covered by those new
> entries ?

ap_sdhci is the emmc.  cpm_sdhci is the SD slot.

Had Marcin looked at my tree, or you wait for me to post a mainline
version of my "arm64: dts: marvell: mcbin: add sdhci" patch, you'd
get an entry containing the correct description for the SD slot,
including support for the card detect signal.

However, the SD slot is rather moot at the moment, because sdhci-xenon
appears to be currently broken and non-functional, as I've already
reported.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 2/2] arm64: marvell: dts: add second 1G port on the Armada 8040 DB

[Marcin Wojtas]

Armada 8040 DB is equipped with 4 (2x 10G SFI + 2x 1G RGMII)
ethernet ports of which only one was hitherto enabled.
Because currently mvpp2 driver is capable of supporting only
1G RGMII/SGMII, enable second port from CP slave HW block.

Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
 arch/arm64/boot/dts/marvell/armada-8040-db.dts | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
index dc0d084..3cde649 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
@@ -169,6 +169,22 @@
 	status = "okay";
 };
 
+&cps_mdio {
+	phy0: ethernet-phy at 0 {
+		reg = <0>;
+	};
+};
+
+&cps_ethernet {
+	status = "okay";
+};
+
+&cps_eth1 {
+	status = "okay";
+	phy = <&phy0>;
+	phy-mode = "rgmii-id";
+};
+
 &ap_sdhci0 {
 	status = "okay";
 	bus-width = <4>;
-- 
1.8.3.1

[PATCH 2/2] arm64: marvell: dts: add second 1G port on the Armada 8040 DB

[Gregory CLEMENT]

Hi Marcin,
 
 On mar., mai 16 2017, Marcin Wojtas <mw@semihalf.com> wrote:

> Armada 8040 DB is equipped with 4 (2x 10G SFI + 2x 1G RGMII)
> ethernet ports of which only one was hitherto enabled.
> Because currently mvpp2 driver is capable of supporting only
> 1G RGMII/SGMII, enable second port from CP slave HW block.
>

Applied on mvebu/dt64

Thanks,

Gregory

> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> ---
>  arch/arm64/boot/dts/marvell/armada-8040-db.dts | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
> index dc0d084..3cde649 100644
> --- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
> @@ -169,6 +169,22 @@
>  	status = "okay";
>  };
>  
> +&cps_mdio {
> +	phy0: ethernet-phy at 0 {
> +		reg = <0>;
> +	};
> +};
> +
> +&cps_ethernet {
> +	status = "okay";
> +};
> +
> +&cps_eth1 {
> +	status = "okay";
> +	phy = <&phy0>;
> +	phy-mode = "rgmii-id";
> +};
> +
>  &ap_sdhci0 {
>  	status = "okay";
>  	bus-width = <4>;
> -- 
> 1.8.3.1
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com