09:02 < wsa> welcome to today's IO meeting
09:02 < wsa> the reports
09:02 < wsa> A - what have I done since last time
09:02 < wsa> ------------------------------------
09:02 < wsa> Geert
09:02 < wsa> : Fixed another st1232 touchscreen regression on armadillo800eva, sent out Falcon I2C EEPROM support v2
09:02 < wsa> Niklas
09:02 < wsa> : upstreamed thermal support for V3U
09:02 < wsa> Shimoda-san
09:02 < wsa> : added mmc aliases to board DTS files, added CAN support for M3-W+, and reviewed plus tested Wolfram's SDHI patches
09:02 < wsa> Ulrich
09:02 < wsa> : investigated selective turning off of RAVB hardware RX checksumming on arrival of VLAN-tagged packets, found that it was already fixed upstream and BSP probably carried an unneeded patch
09:02 < wsa> Wolfram
09:02 < wsa> : upported fix for CMT and verified Niklas' timer results, upstreamed V3U support for CMT and TMU, reviewed Geert's V3U patches, reviewed periject patches, updated and sent out new versions of using hard reset for SDHI, sent out patches to restore SDHI bus width after reset, sent out patches to allow a custom irq mask for SDHI, helped Bosch with their DA9063 I2C problem,
09:02 < wsa>  handled a syzkaller report and improved the I2C core, picked up logic analyzer work again
09:02 < wsa> B - what I want to do until next time
09:02 < wsa> -------------------------------------
09:02 < wsa> Shimoda-san
09:02 < wsa> : wants to continue to investigate SDHI driver issues, collect more information about R-Car Gen3e, and to continue to improve R-Car S4 Ethernet driver
09:02 < wsa> Ulrich
09:02 < wsa> : wants to investigate issue with SDHI clock being left on after the card has been removed
09:02 < wsa> Wolfram
09:02 < wsa> : wants to update the irq mask handling for SDHI further, continue "logic analyzer via isolated CPU" work, continue with extended RECV_LEN and its R-Car support
09:02 < wsa> C - problems I currently have
09:02 < wsa> -----------------------------
09:02 < wsa> Shimoda-san
09:02 < wsa> : wonder about the "SDnCKCR setting for HS200 #297087" issue where we thought about handling SDHn as a seperate clock
09:02 < wsa> Wolfram
09:02 < wsa> : thinks RPM for SDHI still behaves strange. Even when removing an SD card, the clock stays enabled. I started debugging why but had to give up due to other commitments. Uli said he could have a look but not before next month.
09:03 < wsa> shimoday: I added your testing and reviewing of my SDHI patches to a) That was surely work, too :)
09:03 < wsa> shimoday: about the issue #297087...
09:04 < wsa> we have an action item for it, yet I wanted to start working on it only after the other issues have been solved
09:05 < wsa> otherwise we might be changing too much at the same time which would make regression hunting harder
09:05 < geertu> wsa: Looks like the SDHI clock is sometimes active after s2ram, too.
09:05 < wsa> other issues = hard reset, bus width restoring, better irq masks...
09:05 < wsa> geertu: only sometimes?
09:05 < geertu> wsa: I didn't look deeper into it
09:06 < marex> one might expect TFA to set the clock to the same thing, always
09:06 < marex> if thats on RCar3 anyway
09:06 < wsa> but we got most of the other items solved meanwhile, so this is the good news
09:07 < wsa> the bad news is that I need to do some I2C work, too, after fixing the irq masks
09:07 < shimoday> wsa: i agree with you about #297087
09:07 < wsa> however, this task is quite seperate from the other SDHI tasks
09:07 < wsa> so it doesn't have to be me who does it
09:08 < wsa> it is more working with clocks than working with SDHI
09:08 < wsa> is anyone interested / has free base time?
09:09 < wsa> short desc: we currently handle two clocks (SDn and SDHn) as one, but we want to refactor them into two clocks
09:10 < wsa> marex: what about disabling L1 on PCIe? do you have time for that BTW?
09:10 < wsa> ok, seems that everyone is busy enough. (surprise! ;))
09:10 < marex> wsa: no, was busy with digging in the A/B switching
09:11 < wsa> let me know if things change
09:11 < marex> and then upporting ATF patches using that ^
09:11 < wsa> shimoday: I am aware of the issue but it looks like it needs to wait a little
09:11 < wsa> :(
09:12 < wsa> marex: okay, and you probably still are busy enough with that in the next time?
09:12 < shimoday> wsa: i got it. thanks!
09:13 < marex> wsa: I still want to finish the WDT support there and there are ATF patches to upport left, so yes, but I didn't forget about it
09:13 < wsa> marex: okay, thanks for the heads up!
09:14 < wsa> a similar problem with our limited resources is the SDHI RPM issue I mentioned
09:15 < wsa> uli__ volunteered to have a look but has no time before next month
09:15 < marex> the A/B switching was something I needed for bootloader testing for a while, except I finally found a way to implement it
09:15 < wsa> it is not super urgent but, yeah, this delays, too
09:15 < neg> I would like to offer help, but I'm saturated until next meeting with VIN on V3U
09:16 < wsa> neg: thanks anyway :)
09:17 < wsa> any topics from your side?
09:19 < shimoday> nothing from my side
09:19 < wsa> uli__: I guess the lesson learnt from the RAVB task is to check the test case first :)
09:19 < uli__> indeed
09:19 < wsa> but thanks for closing the ticket anyhow; now we now it is properly solved upstream
09:20 < uli__> np
09:20 < wsa> okay, if there is nothing else, we can have a break or move to core?
09:20 < wsa> I guess the UIO discussion is MM?
09:21 < kbingham> UIO is core isn't it ?
09:21 < kbingham> That's applicable to all components...
09:21 < geertu> ;-)
09:21 < wsa> kbingham: another reason to switch to core now ;)
09:21 < kbingham> :)
09:22 < geertu> Shall we move on to "core" early?
09:22 < wsa> kbingham: where are your LED patches BTW? I can't see them in patchwork? /me blind?
09:22 < wsa> geertu: I'd say so