<hays>
narmstrong: did you ever figure out that N2L issue with the emmc controller not initializing? i still have a while loop basically in my boot code to try over and over again :)
doppo has quit [Remote host closed the connection]
buzzmarshall has quit [Quit: Konversation terminated!]
JohnnyonFlame has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #linux-amlogic
vagrantc has quit [Quit: leaving]
naoki has joined #linux-amlogic
<narmstrong>
hays: Nop sorry can you describe the problem ?
cottsay has quit [Quit: TTFN]
cottsay has joined #linux-amlogic
ldevulder has joined #linux-amlogic
marc|gonzalez has joined #linux-amlogic
<marc|gonzalez>
Hello everyone :)
<marc|gonzalez>
I've been playing with an X2 board and its WiFi module (connected over SDIO). I see very high CPU usage when running full tilt.
<marc|gonzalez>
Does anyone have an X3 or X4 board? Does anyone have a board with PCIe WiFi?
Daanct12 has joined #linux-amlogic
JohnnyonFlame has quit [Ping timeout: 268 seconds]
naoki has quit [Quit: naoki]
<narmstrong>
I never saw an amlogic device with PCIe WiFi so far, even less with a bradcom module, I have a BPI-CM4 (a311d) with a miniPCIe slot so if I find a cheal broadcom module I can test
<xdarklight>
marc|gonzalez: I have an X96 Air which comes with an S905X3 (SM1) SoC and a Realtek RTL8822CS SDIO wifi (+ Bluetooth) module
<xdarklight>
marc|gonzalez: in RX direction I can get ~20 Mbit/s, in the TX direction I can get upwards of 100 Mbit/s
<xdarklight>
marc|gonzalez: I never cared about CPU usage though, I can check that later
<marc|gonzalez>
xdarklight: Mbit? With the vendor kernel I see 25-30 MB/s (~220 Mbps) RX ... weird
<marc|gonzalez>
narmstrong: we're considering buying a PCIe-based X4 for evaluation
<narmstrong>
marc|gonzalez: beware X4 has no mainline support
<marc|gonzalez>
narmstrong: erf :'(
<marc|gonzalez>
Is it very different?
<narmstrong>
yes and no
<marc|gonzalez>
Actually, I have one on my desk, I'll try booting with an X2 DTS
<marc|gonzalez>
X3 is SM1?
<narmstrong>
it won't work
<narmstrong>
yes X3 is SM1, and it's supported
<narmstrong>
X4 clock arch is totally different
<marc|gonzalez>
erf erf :'(
<marc|gonzalez>
Is anyone actively mainlining the X4?
<marc|gonzalez>
Amlogic perhaps...
<marc|gonzalez>
phh: as you mentioned, no mainline support for X4 at this stage
<xdarklight>
marc|gonzalez: I have to be fair: 100 Mbit/s in the TX direction is awesome for me as it's with the upstream rtw88 driver that I'm getting ready for SDIO support (but of course I don't have any datasheets so I have to read the Realtek vendor driver - which is... let's say a tough task)
<marc|gonzalez>
xdarklight: erf I've been there trying to reverse from vendor driver. Terrible experience :(
<marc|gonzalez>
SoC vendors are stupid for withholding register map documentation
<marc|gonzalez>
narmstrong: khilman: is Martin on IRC?
<marc|gonzalez>
he suggested I move the PMU node inside the dmc node, but the dmc node spans 0xff638000-0xff638400, yet the pmu node hits in base+0xc00
<xdarklight>
marc|gonzalez: if you mean Martin Blumenstingl: that's me ;)
<marc|gonzalez>
ooooh :)
<marc|gonzalez>
Yes I meant you :)
<xdarklight>
let me look up that thread so I can see what I suggested ;)
<marc|gonzalez>
I'm going to lunch, I'll have to open the datasheet to see WTF is at base+0xc00
<marc|gonzalez>
I'm not even sure the driver maps that part
<xdarklight>
marc|gonzalez: enjoy lunch :-)
<xdarklight>
marc|gonzalez: I just looked it up in the public A311 datasheet - according to that the DMC region covers 0xFF638000 to 0xFF639FFF. so I guess we need yet another patch to fix the upper limit of the &dmc node first, then it will be fine to have any 0xc00 offset inside &dmc
f_[xmpp] has quit [Ping timeout: 265 seconds]
<rockosov>
marc|gonzalez: It's always big adventure to read Amlogic chip documentation. Register bank base addresses value miss is normal situation...
<rockosov>
Is S905X4 located in s4 SoC family like S905Y4? If yes, clock driver is under development by Amlogic (you can follow up it in linux-amlogic mailing list). It's very similar to a1 clock driver, but has more clock gates.
<rockosov>
marc|gonzalez: About high CPU usage. Did you check top/perf sched or anything else?
gis has quit [Ping timeout: 250 seconds]
f_ has joined #linux-amlogic
<marc|gonzalez>
rockosov: I identified the problem with top, then actually ran perf for a 1GB transfer in nohlt/cpufreq=performance mode to have complete view
<marc|gonzalez>
simpleperf on the android vendor kernel actually, need to try with perf on mainline kernel today
<rockosov>
marc|gonzalez: ah, okay. simpleperf/inferno is perfect tool, showing many things over whole system. Also Perfetto can be used for such goals (https://perfetto.dev/). If your test is not depending on userspace workload, you can bringup small buildroot environment based on the vendor kernel or use vendor buildroot environment, run perf inside it. And of course, it's possible to bringup vanilla
<rockosov>
perf in the AOSP, but this is long activity.
<marc|gonzalez>
rockosov: narmstrong told me high CPU load is expected when bursting over SDIO :(
<marc|gonzalez>
even moreso on the X2 which has a HW defect that needs to be worked around using a scratch buffer
<rockosov>
marc|gonzalez: AFAIR, there was one workaround inside mainline meson SDIO implementation, burst count is limited to one.
<marc|gonzalez>
amlogic,dram-access-quirk ?
gis has joined #linux-amlogic
<marc|gonzalez>
xdarklight: I don't understand the binding for the PMU. all compatibles define .dmc_nr = 1, and thus ioremap only the first area. The second area is documented nowhere in the datasheet
f_ has quit [Quit: Lost terminal]
<xdarklight>
marc|gonzalez: the second area is the PLL, see ddr_pmu_parse_dt
<xdarklight>
marc|gonzalez: I believe the PLL is a separate IP block and likely should get a separate driver. but let's do things one at a time
<marc|gonzalez>
Do you see 0xff638c00 documented in your data sheet?
<marc|gonzalez>
I have 0 matches in my PDF
<marc|gonzalez>
But OK, I'm not touching that.
<marc|gonzalez>
dmc_g12_get_freq_quick() does read 0xff638c00, nasty
<xdarklight>
marc|gonzalez: I also have 0 matches but I think that's a "bug" in the datasheet. basically it should be the base offset for AM_DDR_PLL_CNTL0
<marc|gonzalez>
Ooooh that makes a whole lotta sense!
<marc|gonzalez>
I did note that typo and wondered what the correct base was!
<marc|gonzalez>
I think you solved that mystery
<xdarklight>
marc|gonzalez: yep, that dmc_g12_get_freq_quick() is also far from being great... if we model it as clock driver then we can just re-use existing code for the frequency calculation... see drivers/clk/meson/meson8-ddr.c and drivers/clk/meson/clk-pll.c if you're curious
<marc|gonzalez>
dmc_g12_get_freq_quick() sucks the switch leaves od_div unassigned
<marc|gonzalez>
not unassigned, value 0xfff
<marc|gonzalez>
also note that the datasheet mentions the bit assignments, but not the bit semantics
<xdarklight>
not a big surprise ;-)
<marc|gonzalez>
When I worked at Sigma Designs, I had a big foam bat, and I would smack the HW devs when they didn't document the registers
<marc|gonzalez>
I think the world needs more foam bats
<marc|gonzalez>
xdarklight: do you know the difference between reg and ranges in a simple-bus node in DT?
<xdarklight>
marc|gonzalez: yep, ranges is used for translation of the child node's addresses. if you omit ranges then the child nodes are translated with the *parent* busses address. or in other words: ranges makes it so that a child node's offset of 0 is translated to the actual start of the simple-bus
<xdarklight>
marc|gonzalez: rule of thumb is: keep reg and ranges in sync
<marc|gonzalez>
Rule of programming: whenever we have to duplicate an information, something is not right
<marc|gonzalez>
I would have expected identity map for a simple-bus node
<marc|gonzalez>
thus no need to dupe the reg prop in the ranges prop
<xdarklight>
marc|gonzalez: it's not fully duplicated: the first part of ranges is a chip-select - but (luckily) that's always 0x0 in our case. see https://elinux.org/Device_Tree_Usage#Ranges_.28Address_Translation.29 for some more advanced examples
<xdarklight>
so effectively for us you are right: it's duplicated in our case. but ranges has to support more advanced use-cases. not sure if one could have implemented some kind of fallback though
<marc|gonzalez>
but do we actually need the reg property on dmc: bus@38000 ? There's no compatible, so no one uses that I think?
<xdarklight>
yes, because if you say bus@38000 that means this bus has a unit address - and that means it needs a "reg" property - of 0x38000
<xdarklight>
it's ranges that's optional. let's go with the canvas example inside &dmc: right now canvas has an unit-address of 0x48. if we omit the ranges property of the bus then the unit-address becomes 0x38048
<xdarklight>
(the unit address of canvas that is)
<marc|gonzalez>
that I understand (I think)
<marc|gonzalez>
but why do we need to name the bus? Is it just because different platforms use a reference to it to define their compatible prop?
<xdarklight>
you mean why we need to have the bus at all in our .dts?
<marc|gonzalez>
well I suppose that's one way to frame the question. I mean the DMC area is clearly not a bus
<marc|gonzalez>
it's just an area for various related things thrown together
<xdarklight>
my approach for this so far has been: if the IP blocks inside are independent (meaning: we can clearly see that the different IPs have independent ranges inside that "memory region") then I'm calling it a bus. otherwise it's some kind of device (let's say &usb2_phy0). but there may be better explanations from the device-tree maintainers
<marc|gonzalez>
xdarklight: I'm chatting with robher on #armlinux right now
ldevulder_ has joined #linux-amlogic
ldevulder_ has quit [Remote host closed the connection]
Daanct12 has quit [Quit: WeeChat 3.8]
ldevulder has quit [Ping timeout: 246 seconds]
ldevulder has joined #linux-amlogic
<hays>
narmstrong: probably will take a bit because it was all just in #u-boot and I don't have a good record so probably can't give a useful report. but a while back i reported that emmc was giving an error on boot some/most of the time and I thought you were able to reproduce it. you suggested i mess with the timing of the initialization pulse sent to the controller, which I did and it seemed to have no effect. I'll get the device plugged in so i can
<hays>
give a better report.
vagrantc has joined #linux-amlogic
JohnnyonFlame has joined #linux-amlogic
jacobk has joined #linux-amlogic
<narmstrong>
marc|gonzalez: the « simple-bus » DT concept doesn’t necessarily match a real bus, mainly because it’s often hard, but groups memory zones to ease description, but ultimately we could have a flat DT with all nodes under /soc
<narmstrong>
Thx for the fix, don’t hesitate sending other fixes of weird stuff you encounter
<marc|gonzalez>
narmstrong: xdarklight: I sent the two patches that fix the DMC conflict :)
<marc|gonzalez>
I need to run perf on mainline/X2 and simpleperf on vendor/X4