[ 1.887991] sdhci_msm 7824900.sdhci: No vreg data found for vdd
[ 1.888021] sdhci_msm 7824900.sdhci: No vreg data found for vdd-io
[ 1.892743] sdhci_msm 7824900.sdhci: Parsing Pinctrl failed with -19, falling back on GPIO lib
They all seem to be generated by the sdhci-msm2.c code and that driver seems to suffers from bit-rot.
Well, if you want to push forward: a "very nice" thing to do would be to get it working with the sdhci-msm.c driver. This will probably involve making patches (and putting in some effort in trying to upstream them too).
That said, I know that dealing with QCA is anything but fun.
But keep in mind, I don't have a unit with emmc... "so what do i know", right?!
Yeah, I would really like to get it working with the upstream driver since that will make everybody's life easier and its really making no sense that QCA sent a patch upstream to add sdhci node to the dk04.1.dtsi.
My C skills are not really driver level so if everything works I will try to get it merged in this state.
If it does not get accepted I will still use it for my own home AP since stock firmware tends to crash every 12 or so hours and wireless radio stops working
True, it doesn't show up on the console unless you mess with the debug level or replace dev_dbg with dev_info/warn/err. dev_dbg can show up in dmesg too (as long as the dynamic debug stuff doesn't disable it).
As for the sdhci-msm. The upstream driver does have some code for it in place. Maybe it was just related to the dts? I looked at the older dts definition again. Maybe it's just the clocks?
(Not sure, what to do with the regulator though. That said, u-boot might already sets it up properly, so you could get away with it as long as you don't touch it).
Hm,I will test out the upstream driver and try couple of combinations with the DTS definition.
I think it is mainly crashing due to hc_ir and pwr_irq.
Bootloader does not set the regulator as the GPL source also has regulator node.
Qualcomm attempted to push upstream patch to add sdhci node to qcom-ipq4019-ap.dk04.1.dtsi
And their definition is surely not working. https://patchwork.kernel.org/patch/8748561/
New errors this time:
sdhci_msm 7824900.sdhci: Peripheral clk setup failed (-2)
sdhci_msm: probe of 7824900.sdhci failed with error -2
I think that that is due to clock naming in the node
And now some now errors:
[ 1.758189] sdhci: Secure Digital Host Controller Interface driver
[ 1.762496] sdhci: Copyright(c) Pierre Ossman
[ 1.769064] sdhci-pltfm: SDHCI platform and OF driver helper
[ 1.779300] sdhci_msm 7824900.sdhci: Got CD GPIO
[ 1.780586] sdhci_msm 7824900.sdhci: TCXO clk not present (-2)
[ 1.784521] sdhci_msm 7824900.sdhci: core clock boost failed
[ 1.832999] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.833219] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.865668] mmc0: SDHCI controller on 7824900.sdhci [7824900.sdhci] using ADMA 64-bit
[ 1.871679] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.875282] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.882324] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.884092] NET: Registered protocol family 10
[ 1.885919] Segment Routing with IPv6
[ 1.886031] NET: Registered protocol family 17
[ 1.886525] 8021q: 802.1Q VLAN Support v1.8
[ 1.886571] Registering SWP/SWPB emulation handler
[ 1.892041] hctosys: unable to open rtc dev�[ 1.917079] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.917144] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.925407] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.936386] Freeing unused kernel memory: 10240K
[ 1.945241] init: Console is alive
[ 1.945451] init: - watchdog -
[ 1.953155] mmc0: error -110 whilst initialising MMC card
Those are after changing clock names to following per bindings
clock-names = “core”, “iface”;
I suspect that we now I am missing advertising speed rates as qcom,bus and qcom,rates are not in the upstream driver.
Yeah, can confirm that for whatever reason this happens alot. As I wrote above: the NAND was also not working. But we managed to get hold of QCA back then and they were able to fix it.
Weird, isn't the Orbi's kernel image stored on the emmc? If so, how can u-boot manage to load the kernel from the emmc without initializing the sdhci + regulator?
As for the "easy" fixes:
At least this should be fixed with the clocks + clock-name definition above. At least it wasn't showing them anymore in my bootlog.
[ 5.389582] sdhci-pltfm: SDHCI platform and OF driver helper
[ 5.397116] sdhci_msm 7824900.sdhci: Host Version: 0x4202 Vendor Version 0x42
[ 5.399772] sdhci_msm 7824900.sdhci: MCI Version: 0x10000042, major: 0x0001, minor: 0x42
[ 5.410294] sdhci_msm 7824900.sdhci: mmc0: clock=0 uhs=0 ctrl_2=0x0
[ 5.459569] mmc0: Failed to set clock at rate 400000 at timing 0
[ 5.459926] sdhci_msm 7824900.sdhci: mmc0: clock=400000 uhs=0 ctrl_2=0x0
Ok,added the xo clock and that error is gone.
As for the core boost I already had maximum frequency at 192 Mhz and the same error is present.
sdhci_msm 7824900.sdhci: card claims to support voltages below defined range is a weird error as I advertised the same speed and voltage as John did,but just in a upstream property.
Yes,bootloader has to set it.
I can try without the regulator but I doubt that it will change anything
[ 1.758504] sdhci: Secure Digital Host Controller Interface driver
[ 1.762832] sdhci: Copyright(c) Pierre Ossman
[ 1.768986] sdhci-pltfm: SDHCI platform and OF driver helper
[ 1.773963] sdhci_msm 7824900.sdhci: core clock boost failed
[ 1.823720] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.824041] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.853984] mmc0: SDHCI controller on 7824900.sdhci [7824900.sdhci] using ADMA 64-bit
[ 1.859788] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.863628] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.869425] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.873544] sdhci_msm 7824900.sdhci: card claims to support voltages below defined range
[ 1.879170] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.887534] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.896909] mmc0: Failed to set clock at rate 400000 at timing 0
[ 1.904853] NET: Registered protocol family 10
[ 1.906335] Segment Routing with IPv6
[ 1.909324] NET: Registered protocol family 17
[ 1.913417] 8021q: 802.1Q VLAN Support v1.8
[ 1.917354] Registering SWP/SWPB emulation handler
[ 1.925560] mmc0: error -110 whilst initialising MMC card
Yeah, sadly setting the max-frequency = <1920000000>; won't do it. The sdhci's core/host.c parses the property and just sets host->f_max.
However, the sdhci-msm.c driver does not do anything with the value. Instead tries INT_MAX:
which is why it fails.
if this was wired up correctly it could(but doesn't have to) look like:
ret = clk_set_rate(clk, host->mmc->f_max);
or (this will retain compatibility in case the max-frequency property wasn't set).
ret = clk_set_rate(clk, host->mmc->f_max ? : INT_MAX);
(or a longer version that might be preferred by the maintainers)
ret = clk_set_rate(clk, (host->mmc->f_max > 0) ? host->mmc->f_max : INT_MAX);
If you look in John's emmc the driver does it like this:
u32 max_clk;
[...]
np = pdev->dev.of_node;
if (of_property_read_u32(np, "qcom,max_clk", &max_clk))
max_clk = sdhci_msm_get_min_clock(host);
/* Set to the maximum supported clock frequency */
ret = clk_set_rate(msm_host->clk, max_clk);
And yes, this is a bug/problem in the upstream driver. The question is: is this the deal breaker or not.
I would need some actual ipq40xx hardware with a emmc to look into this. All I can say from afar is: It might need some sort of vqmmc supply property. If you have John's regulator patched in and dts definition around, you could try to
add the
vqmmc-supply = <&vccq_sd0>;
property to sdhci node. Maybe it helps, maybe not.
Edit:
Another possibility for the regulators would be to define a dummy-regulator via the fixed-regulator binding and set it to whatever you need. (this will work as long as something has setup the regulator hardware correctly and the driver does not need to change it).
I dont think that anybody actually tested it on a working hardware
Even they were arguing that max-frequency is needed as only MSM8947Pro actually supports 400MHz clock.
Dummy regulator could work since the voltage is known,but I want to make this really generic.
We are really close now.
Update:
GCC not really liking your proposals.
I tried simply removing the boost part of the code but the errors:
mmc0: Failed to set clock at rate 400000 at timing 0
and
sdhci_msm 7824900.sdhci: card claims to support voltages below defined range
are still present.
Tried couple of ways to migrate both places where INT_MAX was used to passed f_max property.
But GCC is not really liking anything
This are common errors:
drivers/mmc/host/sdhci-msm.c: In function 'sdhci_msm_probe':
drivers/mmc/host/sdhci-msm.c:1154:33: error: 'f_max' undeclared (first use in this function); did you mean '__max'?
ret = clk_set_rate(host->mmc, f_max);
^~~~~
__max
drivers/mmc/host/sdhci-msm.c:1154:33: note: each undeclared identifier is reported only once for each function it appears in
drivers/mmc/host/sdhci-msm.c:1154:22: error: passing argument 1 of 'clk_set_rate' from incompatible pointer type [-Werror=incompatible-pointer-types]
ret = clk_set_rate(host->mmc, f_max);
^~~~
In file included from drivers/mmc/host/sdhci-pltfm.h:14:0,
from drivers/mmc/host/sdhci-msm.c:25:
./include/linux/clk.h:473:5: note: expected 'struct clk *' but argument is of type 'struct mmc_host *'
int clk_set_rate(struct clk *clk, unsigned long rate);
^~~~~~~~~~~~
drivers/mmc/host/sdhci-msm.c:1193:21: error: 'clk' undeclared (first use in this function)
ret = clk_set_rate(clk, host->mmc->f_max);
It suggest using clk and after using clk error is that clk is not declared
You were looking at the current driver,that one is in much better shape as a lot of power_irq and other issues have been fixed.
I tried backporting the driver from 4.16.8 but there are couple of critical errors during compilation which are caused most likely by something I forgot to backport.
Even fixing all clock settings manually to 192MHz still caused the same card below defined error and there is no attempt to load the card.
I didn't see that you have updated the old post as well. Sorry!
Was this mangled (i.e. do you read the post over email or did you visit the forum?), was this a c&p error? Because it doesn't look like the versions I posted in post #32. (or is somebody/something editing my posts? )
or did try to apply same line to the other locations as well?
It was only meant as a drop-in replacement for
(and it assumed that you had the max-frequency property set to 192 Mhz).
I don't know, it happens from time to time that something else (like in the clk framework) got changed in the process it silently broke the driver... and nobody noticed and nobody cared.
Now, you could try to contact the mailing-list. But since it looks like the driver is
maintained by linux-arm-msm group, I don't have much hope that they listen, you can try but ...
Anyway, you might as well not bother with upstream (since it starts to become a big waste of time) and just stick with the driver John provided. Maybe someone sends me a sample or somebody else figures out what needs to be done.
I dont read replies in email.
I tried the versions you posted and posted that error caused by them is:
In file included from drivers/mmc/host/sdhci-pltfm.h:14:0,
from drivers/mmc/host/sdhci-msm.c:25:
./include/linux/clk.h:473:5: note: expected ‘struct clk *’ but argument is of type ‘struct mmc_host *’
int clk_set_rate(struct clk *clk, unsigned long rate);
^~~~~~~~~~~~
drivers/mmc/host/sdhci-msm.c:1193:21: error: ‘clk’ undeclared (first use in this function)
ret = clk_set_rate(clk, host->mmc->f_max);
I gave up today on the upstream driver as manually setting all clocks to 192MHz removes all of errors besides:
sdhci_msm 7824900.sdhci: card claims to support voltages below defined range
And that is where the driver stops.
It most likely got broken in the process and nobody noticed as it is rarely used in never kernel versions as both Android and other distros use old kernel versions or non upstreamed sdhci-msm drivers.
Now I am patching in the driver for TLC59208F I2C LED driver used in Orbi Pro from the GPL.
It is really badly written with lots of errors,they even wrote deafult instead of default.
I dont know how GCC even compiles that for stock.
GCC7.3 was throving a lot of errors related to suspend,resume and shutdown functions so for now I just commented those out.
I2C bus is registered but i2cdetect cant scan it,so I am looking at that now.
Without the driver we cant stop the LED ring from constantly flashing.
Well,after registering it under I2C device is registered and driver is loaded.
Gotta figure out how to use the driver as Netgear made sure to only include the binary blob as led control app
Hm, this reminds me of the Netgear WNDR4700... Even back then, Netgear was having a go at random i2c-chips. This must be a Netgear specialty .
The WNDR4700 has a fan-controller chip TC654 and a lm87-compatible temperature sensor. The Netgear Firmware uses a userspace shell script (i2cset and i2cget) which polls the temperature sensor and sets the PWM of the fan-controller. However this was no good since the linux kernel has a much better way to do it: thermal-zones binding in the DeviceTree.
But this required support for both chips. The lm87-compatible chip had a fully working driver that was ready to go. But there was no driver for the tc654 controller. I searched for a driver for a bit... But in the end I just grabbed the PDF from the vendors site and wrote a driver for the tc654 controller:
I ended up not upstreaming the tc654 since by the time linux 4.14 rolled around, the kernel had a driver for the tc65x that only needed the new thermal_ interface support
As for your tlc59208f driver... It looks like this driver only has exposes a private/non-led-subsystem sysfs interface . Maybe you are lucky this time and can
adapt the existing driver from the tcl59108 to your tcl59208:
Yeah,looks like Netgear just loves using stuff with no driver support.
TLC59108 wont be easy to add support for TLC59208F since F designates I2C.
There is even TLC59108F and those are not supported as everything is different.
Their driver probed and registered itself as a driver for TLC59208F.
Just gotta figure out how to interact with it.
I think that there is gonna be some editing of the driver.
Also,I gotta figure out a way either how to package the custom firmware to get it accepted in WEB UI because I dont think that DniImage with suffice.
Bootloader loads the Fit and dtb configuration from the second partition and then uses that dtb to boot the kernel.
I gotta figure out a way to generate Fit tree separately
@robimarko
Oh, from what I know Moritz ( = he had a RBR50) exclusively used the firmware recovery mechanism to flash the generated factory.img and he reported is was working for him.
(or is somebody/something editing my posts? 
)
...
.
. Maybe you are lucky this time and can