Device-tree improvements

This is for any ARMv7 device that we do not officially support.

Re: Device-tree improvements

Postby TheSaint » Wed Feb 13, 2019 8:01 am

summers wrote:OK hopefully the final set of dtb to test

Should I use broken-cd ?
Silly question :) I might try it myself :)

EDIT
Tests completed, Only tinker-s.dtb succeed and also without broken-cd on the u-boot commands.
Attachments
report.7z
(19.62 KiB) Downloaded 6 times
TheSaint
 
Posts: 301
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Wed Feb 13, 2019 10:38 am

@TheSaint - Thanks, So we can conclude that we need to pull both pins before we can start wi-fi and that io-domains must be enabled (set to okay). So thats seems to confirm all needed.

@lgb
1) White space! tell me about it - actually I've not had a problem with my code in the past, just nighmares pasting it into emails or on the web, both replace tabs which is kernel preferred. These days I just use the git commands to send emails with patches, the command line is complicated and a real brain stain, but the patches are ones that the kernel maintainers will accept ...
2) So you mean do:
Code: Select all
    @@ -96,6 +97,15 @@
           startup-delay-us = <100000>;
           vin-supply = <&vcc_io>;
        };
    +
    +   sdio_pwrseq: sdio-pwrseq {
    +      compatible = "mmc-pwrseq-simple";
    +      clocks = <&rk808 RK808_CLKOUT1>;
    +      clock-names = "ext_clock";
    +      pinctrl-names = "default";
    +      pinctrl-0 = <&wifi_enable>;
    +      reset-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_LOW>, <&gpio4 RK_PD4 GPIO_ACTIVE_LOW>;
    +   };
     };
       @@ -415,6 +425,16 @@
              rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
           };
        };
    +
    +      wifi_enable: wifi-enable {
    +         rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>, <4 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
    +      };
    +   };
     };
       

Yes I can see that would make sense, if we knew that at times we only have to pull one pin then maybe keep seperate. But as we have little knowledge of what these pins are connected to, and just guess (e.g. the schematics don't help) - yes might as well merge.
3) disable-wp is in the current mainline device tree - I'll review today as to if we take out- and make sure we get it tested on TheSaints machine. Question is what does write protection mean for a microSD card? It has no switch - so what is the preferred. Guess we need to know this before working out what the tinker board is wired up. And as usual the schematic doesn't help - it doesn't show the connection to the sd Card ...
4) Yes I been thinking about splitting, wi-fi, bluetooth, sdcard. Hassle is all are changes to the same file, so will depend on order applied. Anyway yes I'll split as it makes reviewing easier.
5) I'll try and work out a suitable comment ...
summers
 
Posts: 663
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby summers » Wed Feb 13, 2019 8:51 pm

@TheSaint can you try http://davidjohnsummers.uk/TBSnew4.tar.gz with the suggest from @lgb

@lgb did you mean "disable-wp" in sdio0 or sdmmc ?

Hopefully WiFi will work, Bluetooth won't work, can you also check if you can write to a sd card? And it also has broken-cd set in sdmmc ...

@TheSaint are you happy with a TestedBy: and your email in the patch? That can be read by the world, so if rather not just say so and I'll point people to this place ...
summers
 
Posts: 663
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby lategoodbye » Thu Feb 14, 2019 6:55 am

@lgb did you mean "disable-wp" in sdio0 or sdmmc ?


I meant sdmmc. But i don't believe we have any benefit of this property on sdio0.

Just a note we can't upstream the bluetooth patch as long the realtek bluetooth binding hasn't been accepted.
lategoodbye
 
Posts: 27
Joined: Sat Dec 29, 2018 1:24 am

Re: Device-tree improvements

Postby TheSaint » Thu Feb 14, 2019 7:53 am

summers wrote:@TheSaint can you try

Tried and set it as default for booting :)
Attachments
report4tinker.7z
(12.87 KiB) Downloaded 6 times
TheSaint
 
Posts: 301
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Thu Feb 14, 2019 8:49 am

Do - I just updated the TBSnew4 again, with both disable-wp removed - as neither made any sense!

@TheSaint if you get a chance can you try the no-wp one as well in TBSnew4 ?

I'll check the report in an hour or so ....
summers
 
Posts: 663
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby summers » Thu Feb 14, 2019 10:49 am

@TheSaint To test the disable-wp which was the change made in these device trees:

for sdmmc you will need to insert a sdcard, mount it - and then check /proc/mounts. If you can only mount it read only - then we need the disable-wp flag ...

for the sdio, if the wi-fi comes up and gives you a network connection then we don't need disable-wp

@lgb do you mean the compatible flag for bluetooth?

Problem is that linux currently does not have a driver that can be used on this machine, the official one hci_h5 uses acpi, and acpi is not avaiable on armv7 machine; so this driver can not be used. This means that for the TB(S) no point in specifying a compatible.

Long term, hopefully someone will write a uart h5 for realtek bluetooth driver, that doesn't depend on acpi. At that point you would hope that the acpi realtek stuff would be removed from the hci_h5 driver. and the realtek compatible flat would be added to the new driver.

So this means what to do with the TB(S) device tree. I'm tempered to keep it, a device tree is primarily a hardware description, and with a fair bit of research we have come up with our best understanding for how the TB(S) is wired up. The dts is believed to be correct - that there is no linux kernel that can be used doesn't make the dts invalid. So I'm tempted to submit the bluetooth patch but without a compatible flag in it.

How does this sound?
summers
 
Posts: 663
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby lategoodbye » Thu Feb 14, 2019 9:49 pm

@summers:
A dt-binding is a little bit more than a compatible but yes this is required.

You have a misunderstanding regarding ACPI and Linux. All drivers below the "drivers" directory should be platform independent. The hci_h5 uses ACPI only to identify the hardware. In general you can always compile this driver without ACPI. We "only" need to add the DT parts to the driver. So there is no reason to write a new one.

I suggest to send the wifi patch at first and work at bluetooth in parallel.
lategoodbye
 
Posts: 27
Joined: Sat Dec 29, 2018 1:24 am

Re: Device-tree improvements

Postby TheSaint » Fri Feb 15, 2019 9:38 am

summers wrote:@TheSaint can you try

Tried. Sorry I oversight the second dtb.
I didn't noted much differences between the two. Only some time at the SD insertion had started the error 110. Writing didn't showed any problem.
summers wrote:@TheSaint are you happy with a TestedBy

You might add full,the,saint@gmail,com. But I feel like adding more spam to my mailbox and I also don't check frequently the new incoming.
NOTE substitute commas with dots on my email address.
Attachments
report.7z
(12.24 KiB) Downloaded 7 times
TheSaint
 
Posts: 301
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Fri Feb 15, 2019 12:42 pm

@TheSaint Ta - says we don't need either disable-wp which is what you expect. I'll do the patch for kernel probably tomorrow with this. The mmc error -110 is a bit worrying, google search and may indicate a problem with the sd card?

Re the email, the only way I get spam these days is on an email I post to mail lists - so I always use an email I'm willing to loose. Think whats best is I'll point people to this thread.

@lgb - think its more complicated, I'll explain when I get home ...
summers
 
Posts: 663
Joined: Sat Sep 06, 2014 12:56 pm

PreviousNext

Return to Community Supported

Who is online

Users browsing this forum: No registered users and 0 guests