Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1642123 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board  description Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-05-16 01:30 +0200
    Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description Marcin Wojtas <mw@semihalf.com> - 2017-05-16 11:30 +0200
      Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board  description Thomas Petazzoni <thomas.petazzoni@free-electrons.com> - 2017-05-16 12:00 +0200
        Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board  description Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-05-16 12:10 +0200
          Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board  description Thomas Petazzoni <thomas.petazzoni@free-electrons.com> - 2017-05-16 14:00 +0200
            Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board  description Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-05-16 14:20 +0200
              Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description Marcin Wojtas <mw@semihalf.com> - 2017-05-16 14:50 +0200
                Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board  description Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-05-16 15:50 +0200
      Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board  description Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-05-16 12:00 +0200
      Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board  description Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-05-16 13:20 +0200
        Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description Marcin Wojtas <mw@semihalf.com> - 2017-05-16 13:40 +0200

#1642123 — Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

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.

[toc] | [next] | [standalone]

#1642343 — Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

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

[toc] | [prev] | [next] | [standalone]

#1642376

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

[toc] | [prev] | [next] | [standalone]

#1642382

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.

[toc] | [prev] | [next] | [standalone]

#1642466

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

[toc] | [prev] | [next] | [standalone]

#1642475

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.

[toc] | [prev] | [next] | [standalone]

#1642537 — Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

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

[toc] | [prev] | [next] | [standalone]

#1642570

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.

[toc] | [prev] | [next] | [standalone]

#1642378

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.

[toc] | [prev] | [next] | [standalone]

#1642424

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.

[toc] | [prev] | [next] | [standalone]

#1642439 — Re: [PATCH 1/2] arm64: marvell: dts: fill MachiatoBin board description

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web