| Message ID | 1494890913-8360-2-git-send-email-mw@semihalf.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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
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.
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
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.
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.
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=""
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
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
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.
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
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.
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
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.
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@00000000 { device_type = "memory"; reg = <0x0 0x0 0x0 0x80000000>; @@ -136,3 +140,33 @@ usb-phy = <&usb3h0_phy>; status = "okay"; }; + +&cpm_mdio { + phy0: ethernet-phy@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; +};
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(+)