wm8750 device tree upstream

109 views
Skip to first unread message

Gergely Imreh

unread,
Mar 31, 2015, 5:28:48 AM3/31/15
to vt8500-wm8505...@googlegroups.com
Hi,

I was checking the APC 8750 for a project, and I've noticed that there are changes in the wm8750.dtsi in the vtwm tree that are not upstream, notably the velocity ethernet controller's node (eth0@d8320000). Is it a change that is incompatible with the mainline, or some other reason why it's not merged up? Just wondering, as it would be good if the change was also available elsewhere besides the "testing" branch, which is not stable as you say loud and clear in the github description. :)

Any part that I can possibly help with code testing, cleaning, or something else for upstreaming? Either for this particular device tree, or any other?

Cheers,
   Greg

lautriv

unread,
Mar 31, 2015, 10:33:43 AM3/31/15
to vt8500-wm8505...@googlegroups.com
I wonder about what branch you are actually talking, just checked certain logs and found no
commit for that part nor did i see any dt* for the 8750 containing any ethernet by default.

As far as i know, the vt8505 was the only one using velocity and that was still 100tx due
to cheap external components and the lack of performance, anything above was using
Rhine ( real 100tx but working better ) and it appears the 8880 may have abandonded
internal ethernet at all ( mine has it via USB and tests segfaulted instantly on rhine ) .

If i'm not completely mistaken, your dts should use via rhine with this defaults :

                ethernet@d8004000 {
                        compatible = "via,vt8500-rhine";
                        reg = <0xd8004000 0x100>;
                        interrupts = <10>;
                };

Alexey Charkov

unread,
Mar 31, 2015, 10:47:41 AM3/31/15
to VT8500/WM8505 Linux Kernel


On 31/03/2015 9:33 pm, "lautriv" <lautriv...@gmail.com> wrote:
>
> I wonder about what branch you are actually talking, just checked certain logs and found no
> commit for that part nor did i see any dt* for the 8750 containing any ethernet by default.
>
> As far as i know, the vt8505 was the only one using velocity and that was still 100tx due
> to cheap external components and the lack of performance, anything above was using
> Rhine ( real 100tx but working better ) and it appears the 8880 may have abandonded
> internal ethernet at all ( mine has it via USB and tests segfaulted instantly on rhine ) .

From what I know, velocity is used in wm8505/wm8510, as well as in wm8710/wm8750. All others indeed seem to use rhine (with wm8880 not being particularly clear as to whether or not it still has built-in Ethernet at all).

> If i'm not completely mistaken, your dts should use via rhine with this defaults :
>
>                 ethernet@d8004000 {
>                         compatible = "via,vt8500-rhine";
>                         reg = <0xd8004000 0x100>;
>                         interrupts = <10>;
>                 };
>
>
>
>
> Am Dienstag, 31. März 2015 11:28:48 UTC+2 schrieb Gergely Imreh:
>>
>> Hi,
>>
>> I was checking the APC 8750 for a project, and I've noticed that there are changes in the wm8750.dtsi in the vtwm tree that are not upstream, notably the velocity ethernet controller's node (eth0@d8320000). Is it a change that is incompatible with the mainline, or some other reason why it's not merged up? Just wondering, as it would be good if the change was also available elsewhere besides the "testing" branch, which is not stable as you say loud and clear in the github description. :)

The entry itself should be perfectly compatible with current upstream code. Some renaming might be requested upon submission though (eth0 doesn't sound like the preferred naming convention, as it's Linux specific).

>> Any part that I can possibly help with code testing, cleaning, or something else for upstreaming? Either for this particular device tree, or any other?

With device tree entries someone just needs to properly annotate them as patches and submit for inclusion. I think there is no technical reason not to - it just takes a bit of concentration/effort to do.

There's also a bit of persistence required to annoy the OF maintainers just enough to get them to merge the patches, but not to start hating us all :) Roman submitted SD/MMC entries some time ago, for example, but I'm not really sure if they've ended up upstream yet. They are busy people, after all.

Best,
Alexey

Gergely Imreh

unread,
Apr 1, 2015, 12:28:37 AM4/1/15
to vt8500-wm8505...@googlegroups.com
Looking at the other device trees, "emac: ethernet@d8320000" would be
a possible correct naming. "emac" seem to be the general network
interface name (or "gmac" for the gigabit ethernet connectors on the
boards that have that), and ethernet as self-explanatory descriptor.
Created a patch with this naming and adding this single node to the
upstream device tree wm8750.dtsi, and it seem to work fine.

>
>>> Any part that I can possibly help with code testing, cleaning, or
>>> something else for upstreaming? Either for this particular device tree, or
>>> any other?
>
> With device tree entries someone just needs to properly annotate them as
> patches and submit for inclusion. I think there is no technical reason not
> to - it just takes a bit of concentration/effort to do.

I'll try to create a series of patches and share it here to solicit
feedback. Is that a good next step?

>
> There's also a bit of persistence required to annoy the OF maintainers just
> enough to get them to merge the patches, but not to start hating us all :)
> Roman submitted SD/MMC entries some time ago, for example, but I'm not
> really sure if they've ended up upstream yet. They are busy people, after
> all.

Sounds reasonable, and getting used to it, now waiting for 2 months on
some patches submitted on another project that has a few dozen changes
a day :)

>
> Best,
> Alexey
>

Cheers,
Greg

Alexey Charkov

unread,
Apr 1, 2015, 2:45:10 AM4/1/15
to VT8500/WM8505 Linux Kernel

Yes, that indeed sounds about right.

> Created a patch with this naming and adding this single node to the
> upstream device tree wm8750.dtsi, and it seem to work fine.
>
> >
> >>> Any part that I can possibly help with code testing, cleaning, or
> >>> something else for upstreaming? Either for this particular device tree, or
> >>> any other?
> >
> > With device tree entries someone just needs to properly annotate them as
> > patches and submit for inclusion. I think there is no technical reason not
> > to - it just takes a bit of concentration/effort to do.
>
> I'll try to create a series of patches and share it here to solicit
> feedback. Is that a good next step?

Sounds great, please do!

Best regards,
Alexey

Reply all
Reply to author
Forward
0 new messages