From: Andreas Färber <afaerber@suse.de> Date: 2017-01-08 13:31:17
Andreas Färber (4):
Documentation: devicetree: Add vendor prefix for AsiaRF
Documentation: devicetree: arm: mediatek: Add Geek Force board
ARM: dts: mt7623: Add Geek Force config
MAINTAINERS: Extend ARM/Mediatek SoC support section
Documentation/devicetree/bindings/arm/mediatek.txt | 3 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
MAINTAINERS | 2 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/mt7623-geekforce.dts | 77 ++++++++++++++++++++++
5 files changed, 84 insertions(+)
create mode 100644 arch/arm/boot/dts/mt7623-geekforce.dts
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Acked-by: Rob Herring <redacted>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: John Crispin <john@phrozen.org> Date: 2017-01-10 07:00:24
On 08/01/2017 14:30, Andreas Färber wrote:
Andreas Färber (4):
Documentation: devicetree: Add vendor prefix for AsiaRF
Documentation: devicetree: arm: mediatek: Add Geek Force board
ARM: dts: mt7623: Add Geek Force config
MAINTAINERS: Extend ARM/Mediatek SoC support section
Hi,
i need to NAK this series. the asiarf board is nothing more than the
official MTK EVB with AsiaRF written on it. this board is already
supported by linux (arch/arm/boot/dts/mt7623-evb.dts) please extend the
EVB dts file nstead of adding a duplicate and letting the original bitrot.
John
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Andreas Färber <afaerber@suse.de> Date: 2017-01-10 09:48:52
Hi,
Am 10.01.2017 um 08:00 schrieb John Crispin:
On 08/01/2017 14:30, Andreas Färber wrote:
quoted
Andreas Färber (4):
Documentation: devicetree: Add vendor prefix for AsiaRF
Documentation: devicetree: arm: mediatek: Add Geek Force board
ARM: dts: mt7623: Add Geek Force config
MAINTAINERS: Extend ARM/Mediatek SoC support section
Hi,
i need to NAK this series. the asiarf board is nothing more than the
official MTK EVB with AsiaRF written on it. this board is already
supported by linux (arch/arm/boot/dts/mt7623-evb.dts) please extend the
EVB dts file nstead of adding a duplicate and letting the original bitrot.
Well, I disagree.
First of all I'm not letting "the original" bitrot, because I have
nothing to do with that .dts! If anyone is to blame for letting it
bitrot since February 2016, pick your own nose:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/mt7623-evb.dts
Second, I have no Mediatek documentation or even picture to identify any
similarities between my board and that Mediatek EVB, so no, I can't hack
on the -evb.dts file. I wrote my .dts from scratch, not even having
access to /proc/device-tree on its 3.10 kernel for comparison.
Third, by your argumentation we shouldn't be adding, e.g., Odroid .dts
files either because they were based on a Samsung SMDK, or .dts files
for Amlogic TV boxes because they're almost identical to reference
designs, etc.
Users need to know which .dts file to choose, so having a sane .dts
filename is warranted. Depending on how similar they are, one could
either #include the -evb.dts or factor out a shared .dtsi, but that
takes us back to the previous point of hardly anyone having access to
EVB information to identify such a subset. Therefore duplicating trivial
nodes is the method of choice for all practical purposes - mt7623.dtsi
is getting reused just fine.
Comparing our two .dts files, mine has two more UART nodes enabled, the
U-Boot bootloader's baudrate set to actually get serial output, a
different board compatible string for identification, and I chose the
new dual-licensing header that is being requested for new DT files.
For lack of schematics I figured out UART1 by testing - continuity tests
for GND, console=ttySx,115200n8 and trial-and-error for RX/TX. Obviously
I can't do that for a board I don't have access to.
UART2 and UART0 pins were clear, but only UART2 was obvious from ttyMT2.
Do you actually have access to a Geek Force board yourself, or what are
you basing your claims on? Mine looks different from the Indiegogo
picture and thus has different identification from that on
https://wikidevi.com/wiki/AsiaRF_WS2977 (WS3301, MT7623N RFB_V10).
If you confirm the EVB's baudrate I can happily send that part your way.
I've seen 921600 on the Helio X20 96board for instance.
Also, none of what you've said justifies NAK'ing patch 4/4, which
applies to any mt7* and arm64 .dts, including yours.
While we're at it, I noticed that mainline has a "mediatek,mt7623-eth"
network driver but no corresponding .dtsi node. Talk about bitrot...
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
From: John Crispin <john@phrozen.org> Date: 2017-01-10 10:18:58
(resend, hit the wrong reply button)
On 10/01/2017 10:48, Andreas Färber wrote:
Hi,
Am 10.01.2017 um 08:00 schrieb John Crispin:
quoted
On 08/01/2017 14:30, Andreas Färber wrote:
quoted
Andreas Färber (4):
Documentation: devicetree: Add vendor prefix for AsiaRF
Documentation: devicetree: arm: mediatek: Add Geek Force board
ARM: dts: mt7623: Add Geek Force config
MAINTAINERS: Extend ARM/Mediatek SoC support section
Hi,
i need to NAK this series. the asiarf board is nothing more than the
official MTK EVB with AsiaRF written on it. this board is already
supported by linux (arch/arm/boot/dts/mt7623-evb.dts) please extend the
EVB dts file nstead of adding a duplicate and letting the original
bitrot.
Well, I disagree.
reading the rest of the email you seem to be quite agro about this.
First of all I'm not letting "the original" bitrot, because I have
nothing to do with that .dts! If anyone is to blame for letting it
bitrot since February 2016, pick your own nose:
Second, I have no Mediatek documentation or even picture to identify any
similarities between my board and that Mediatek EVB, so no, I can't hack
on the -evb.dts file. I wrote my .dts from scratch, not even having
access to /proc/device-tree on its 3.10 kernel for comparison.
ok, that info is most likely under NDA
Third, by your argumentation we shouldn't be adding, e.g., Odroid .dts
files either because they were based on a Samsung SMDK, or .dts files
for Amlogic TV boxes because they're almost identical to reference
designs, etc.
Users need to know which .dts file to choose, so having a sane .dts
filename is warranted. Depending on how similar they are, one could
either #include the -evb.dts or factor out a shared .dtsi, but that
takes us back to the previous point of hardly anyone having access to
EVB information to identify such a subset. Therefore duplicating trivial
nodes is the method of choice for all practical purposes - mt7623.dtsi
is getting reused just fine.
in that case add a dtsi file for the EVB and include it in your geek
board.dts and only update the compat string.
Comparing our two .dts files, mine has two more UART nodes enabled, the
U-Boot bootloader's baudrate set to actually get serial output, a
different board compatible string for identification, and I chose the
new dual-licensing header that is being requested for new DT files.
1) at the time we adde this the uart support was not ready
2) the bootloader i am using is a custom built one hence the random baudrate
3) you can just updae the license if you want to, no problem
For lack of schematics I figured out UART1 by testing - continuity tests
for GND, console=ttySx,115200n8 and trial-and-error for RX/TX. Obviously
I can't do that for a board I don't have access to.
UART2 and UART0 pins were clear, but only UART2 was obvious from ttyMT2.
you do have the EVB directly in front of you
Do you actually have access to a Geek Force board yourself, or what are
you basing your claims on? Mine looks different from the Indiegogo
picture and thus has different identification from that on
https://wikidevi.com/wiki/AsiaRF_WS2977 (WS3301, MT7623N RFB_V10).
i dont need the geek board as i have the EVB and they are identical
according to MTK
If you confirm the EVB's baudrate I can happily send that part your way.
I've seen 921600 on the Helio X20 96board for instance.
see above
Also, none of what you've said justifies NAK'ing patch 4/4, which
applies to any mt7* and arm64 .dts, including yours.
agreed, i never even mentioned 4/4
While we're at it, I noticed that mainline has a "mediatek,mt7623-eth"
network driver but no corresponding .dtsi node. Talk about bitrot...
the idea is that we work together to make thins optimal. this is not a
you or is right. this is about the FOSS peer review process. please dont
be so agro.
to me it seems suboptimal to support 2 dts files for the same board.
John
Regards,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: John Crispin <john@phrozen.org> Date: 2017-01-12 08:23:27
Hi Andreas,
had a look last night why the ethernet dtsi was not added and it
obviously was not added as we were waiting for the clk-mt2701 to be
merged. the ethernet dtsi will have phandles pointing at the clk nodes
which did not exist at the time. same is true for the PWM code.
i sat down last night and worked out what pending patches i still have
for mt7623 and out of the ~80 required to get v4.4 working i only need
around 10 for v4.10-rc1.
i started to rebase these patches last night and will have time to test
them tomorrow or early next week. as the pwrap node alone is around 200
lines of devicetree we need to figure out a way to add this to the dts
files without duplicating it. i'll try to post a series early next week
that we can then discuss and rebase your geekboard patches on.
John
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Andreas Färber <afaerber@suse.de> Date: 2017-01-16 19:32:09
Am 10.01.2017 um 11:18 schrieb John Crispin:
On 10/01/2017 10:48, Andreas Färber wrote:
quoted
Am 10.01.2017 um 08:00 schrieb John Crispin:
quoted
On 08/01/2017 14:30, Andreas Färber wrote:
quoted
Andreas Färber (4):
Documentation: devicetree: Add vendor prefix for AsiaRF
Documentation: devicetree: arm: mediatek: Add Geek Force board
ARM: dts: mt7623: Add Geek Force config
MAINTAINERS: Extend ARM/Mediatek SoC support section
Hi,
i need to NAK this series. the asiarf board is nothing more than the
official MTK EVB with AsiaRF written on it. this board is already
supported by linux (arch/arm/boot/dts/mt7623-evb.dts) please extend the
EVB dts file nstead of adding a duplicate and letting the original
bitrot.
quoted
Well, I disagree.
reading the rest of the email you seem to be quite agro about this.
Please re-read your reply above and my comments and reconsider your
attitude when replying in the future. It's not about whether these
patches go in or not, it's about your wording. And that continues with
aggressively throwing around the term "agro" in two mails already. I
don't see anything aggressive or angry in my original cover letter that
would've prompted your reply and can only interpret that as your own
frustration with your mt7623 progress. Instead you should've taken the
time to explain a bit better what you really meant, then we could've
spared or shortened this lengthy discussion and have a v2 already.
quoted
First of all I'm not letting "the original" bitrot, because I have
nothing to do with that .dts! If anyone is to blame for letting it
bitrot since February 2016, pick your own nose:
Don't blame _me_ for "bitrot" of a file _you_ added almost a year ago
that did not see any updates since.
Nothing wrong with you not working on something, just don't blame me for
it then, especially when I don't (knowingly) have that hardware and have
never come in touch with it before. I am new to linux-mediatek and had
checked LAKML in vein for any mt7623 patches before sending mine.
[snip]
quoted
Third, by your argumentation we shouldn't be adding, e.g., Odroid .dts
files either because they were based on a Samsung SMDK, or .dts files
for Amlogic TV boxes because they're almost identical to reference
designs, etc.
Users need to know which .dts file to choose, so having a sane .dts
filename is warranted. Depending on how similar they are, one could
either #include the -evb.dts or factor out a shared .dtsi, but that
takes us back to the previous point of hardly anyone having access to
EVB information to identify such a subset. Therefore duplicating trivial
nodes is the method of choice for all practical purposes - mt7623.dtsi
is getting reused just fine.
in that case add a dtsi file for the EVB and include it in your geek
board.dts and only update the compat string.
The question that I am not in a position to answer is: Are those two
boards identical or just very similar? Paul in CC can hopefully clarify
this when he is back. Matthias as maintainer has also remained silent.
quoted
Comparing our two .dts files, mine has two more UART nodes enabled, the
U-Boot bootloader's baudrate set to actually get serial output, a
different board compatible string for identification, and I chose the
new dual-licensing header that is being requested for new DT files.
1) at the time we adde this the uart support was not ready
2) the bootloader i am using is a custom built one hence the random baudrate
Well, did the _original_ bootloader use 115200? In that case we could
update -evb.dts with it, and you could still override it via console=
for your custom build.
Or maybe having source access you could even contribute to mainline
U-Boot, so we can all work on the same codebase? I read a BPi-R2 is
coming up with mt7623, so booting without appended .dtb and uImage will
come in handy for more people than just EVB owners and Geek Force
backers. I'd happily contribute to making bootefi command work.
3) you can just updae the license if you want to, no problem
OK, will gladly look into the feasibility.
quoted
For lack of schematics I figured out UART1 by testing - continuity tests
for GND, console=ttySx,115200n8 and trial-and-error for RX/TX. Obviously
I can't do that for a board I don't have access to.
UART2 and UART0 pins were clear, but only UART2 was obvious from ttyMT2.
you do have the EVB directly in front of you
quoted
Do you actually have access to a Geek Force board yourself, or what are
you basing your claims on? Mine looks different from the Indiegogo
picture and thus has different identification from that on
https://wikidevi.com/wiki/AsiaRF_WS2977 (WS3301, MT7623N RFB_V10).
i dont need the geek board as i have the EVB and they are identical
according to MTK
quoted
If you confirm the EVB's baudrate I can happily send that part your way.
I've seen 921600 on the Helio X20 96board for instance.
see above
So... 4) add my UART nodes to your -evb.dts? Any nitpicks on the actual
patch 3/4?
quoted
Also, none of what you've said justifies NAK'ing patch 4/4, which
applies to any mt7* and arm64 .dts, including yours.
agreed, i never even mentioned 4/4
You replied to the cover letter 0/4 "i need to NAK this series" - and
series includes all four patches. Therefore my frustration with your
hip-shot reply. If you haven't read the patch, don't NAK it!
In fact still no one replied to it at all, even now that you're aware of
its existence.
quoted
While we're at it, I noticed that mainline has a "mediatek,mt7623-eth"
network driver but no corresponding .dtsi node. Talk about bitrot...
the idea is that we work together to make thins optimal. this is not a
you or is right. this is about the FOSS peer review process. please dont
be so agro.
See above, please reconsider your tone. Peer review is no excuse for
rude and destructive behavior towards contributors you don't know.
Had you looked at the lists and codebase you would know that I am not
new to FOSS.
And please stop writing "agro", it sounds like some pothead making a
peace sign; not helpful among professional software developers.
Taking the time to start your sentences with a capital letter would also
be a respectful gesture.
to me it seems suboptimal to support 2 dts files for the same board.
If it is the identical board, then we are in violent agreement. I just
find all your replies to me offensive so far, I don't know you and thus
have no reason to trust your unsubstantiated claims about my board.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Andreas Färber <afaerber@suse.de> Date: 2017-01-16 20:24:09
Hi John,
Am 12.01.2017 um 09:23 schrieb John Crispin:
had a look last night why the ethernet dtsi was not added and it
obviously was not added as we were waiting for the clk-mt2701 to be
merged. the ethernet dtsi will have phandles pointing at the clk nodes
which did not exist at the time. same is true for the PWM code.
i sat down last night and worked out what pending patches i still have
for mt7623 and out of the ~80 required to get v4.4 working i only need
around 10 for v4.10-rc1.
i started to rebase these patches last night and will have time to test
them tomorrow or early next week. as the pwrap node alone is around 200
lines of devicetree we need to figure out a way to add this to the dts
files without duplicating it. i'll try to post a series early next week
that we can then discuss and rebase your geekboard patches on.
Sounds like a plan. Many thanks!
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel