07:12 <odalg> I do find it interresting that when doing iperf3 between a rpi4 and a khadas vim3 pro, the rpi uses only a few percent cpu, and way more on iperf3 than ksoftirqd. The khadas vim3 pro uses almost 100% cpu on ksoftirqd, and only little cpu power on iperf3

07:14 <odalg> counting irqs handled in /proc/interrupts, the rpi handles 522k eth0 irqs sending and receiving for 10 secs. The khadas vim3 pro handles 5k eth0 irqs. Each handling must take considerably longer?

08:03 <narmstrong> odalg: indeed, interesting

10:30 <warpme_> guys: i'm playing with 5.5-rc6 kernel on https://androidtvbox.eu/x96-air-is-another-tv-box-powered-by-amlogic-s905x3-soc It boots but seems to have issue with mmc. Boot log: https://pastebin.com/yvs6NX5H Issue seems to be manifesting like this:

10:30 <warpme_> [ 1.993070] blk_update_request: I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

10:30 <warpme_> [ 2.005015] pwm-regulator regulator-vddcpu: Failed to get PWM: -517

10:30 <warpme_> [ 1.995895] VDDAO_3V3_T: supplied by VDDAO_3V3

10:30 <warpme_> [ 2.000240] blk_update_request: I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

10:30 <warpme_> [ 1.997630] Buffer I/O error on dev mmcblk0, logical block 0, async page read

10:30 <warpme_> [ 2.009182] Buffer I/O error on dev mmcblk0, logical block 0, async page read

10:30 <warpme_> [ 2.020072] meson-drm ff900000.vpu: Queued 2 outputs on vpu

10:30 <warpme_> [ 2.028120] blk_update_request: I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

10:30 <warpme_> [ 2.032867] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).

10:30 <warpme_> [ 2.038044] Buffer I/O error on dev mmcblk0, logical block 0, async page read

10:30 <warpme_> [ 2.048188] [drm] No driver support for vblank timestamp query.

10:30 <warpme_> [ 2.054754] mmcblk0: unable to read partition table

10:32 <warpme_> interesting is that box reads ok kernel from mmc fat partition so mmc seems to be working initially. but later stops(?) Maybe other peripherals initialisation breaks mmc?

10:53 <narmstrong> pretty ugly indeed

10:54 <narmstrong> but it's the sdcard here not the emmc

10:54 <narmstrong> [ 1.929222] mmcblk0: mmc0:5048 SD64G 59.7 GiB

10:55 <narmstrong> [ 1.920513] mmc0: new high speed SDXC card at address 5048

10:55 <narmstrong> the regulators must be different from the sei610

10:56 <warpme_> narmstrong: yes. i was referring to mmc not emmc. 64G sd card seems to be recognised as mmc0

10:57 <warpme_> should i understand that mmc0 stops to work after dt loading in getting into live?

11:01 <narmstrong> here it's from linux

11:01 <narmstrong> so seems something goes wrong in linux

11:01 <narmstrong> for the sdcard

11:02 <narmstrong> weird because in the sei610 dt, th sdcard is very basic, no SDR, only HS 50MHz

11:02 <narmstrong> can you try another sdcard :

11:14 <warpme_> hmm: Initially I was with patron 64G EP. Now - with samsung 32g EVO i'm getting "mmc0: error -84 whilst initialising SD card ". Lest see with toshiba 16G...

11:15 <warpme_> hmm: Initially I was with patriot 64G EP. Now - with samsung 32g EVO i'm getting "mmc0: error -84 whilst initialising SD card ". Lest see with toshiba 16G...

11:24 <warpme_> and with toshiba 16G it works.....ough

11:31 <warpme_> btw: all those cards are working ok on my rest of hw (BCM/AML/AW/RK) - so issue seems to be in this particular SM1 hw....

12:56 <repk> narmstrong: regarding the AXG PCIe patchset, do you have any idea on how I can model this MIPI PHY without anyway to test it ? This PHY was overall to fix the PCIe problem I have on AXG, because some registers in the MIPI PHY region are used for that. So my plan was to implement the PCIe part of this MIPI PHY and if someone ever need to get MIPI working he could add the MIPI part in this driver. Was it

12:56 <repk> a bad plan ?

12:58 <narmstrong> I understood, but you can make a stub MIPI phy that only does what you need, not sure it must be a dual MIPI/PCIE phy

12:59 <narmstrong> the only need is to model correctly the bindings by using the right memory and syscon if we want to use it as a real MIPI phy some day

13:09 <repk> Hm ok, but about syscon this v4 was about to remove its usage as discussed here https://lore.kernel.org/patchwork/patch/1171806/#1368828 in order to get the PHY driver generic enough. But if this is not what we want maybe using syscon directly in the PCIe PHY driver as in v3 would be cleaner ?

13:11 <narmstrong> no if we plan to make a true MIPI phy...

13:12 <narmstrong> for a true MIPI phy we will need an hhi syscon because the main MIPI phy registers are out of syscon

13:12 <narmstrong> don't know what to say...

13:13 <narmstrong> the MIPI has 2 PHYs, a PHY controller and a digital physical PHY

13:14 <narmstrong> what you are modeling is the digital physical PHY, handling the physical lines

13:14 <narmstrong> we could split in 2

13:14 <narmstrong> you could model what you have under the hhi node as something like "mipi-digital-phy"

13:15 <narmstrong> in fact

13:16 <narmstrong> it's called "MIPI PHY(Analog)" in the datasheet

13:16 <narmstrong> so rename it as mipi-analog-phy, put it under hhi like you did in the last patchset, make it used by the pcie phy and we're good

13:17 <narmstrong> then we will need to write a mipi-digital-phy to handle the DSI display one time

13:17 <repk> ok good thanks. Still need to add the clocks or will it be in the digital part ?

13:18 <narmstrong> yep it will be in the digital part

13:18 <repk> ok thank you a lot for your help

13:19 <narmstrong> np, thanks for pushing stuff upstream !