09:03 < wsa> so, let's start the IO meeting 09:03 < wsa> hi Magnus! 09:04 < damm> hi wsa! 09:04 < wsa> first of all, if someone of JapaPERI could tell Morimoto-san all the best wishes for his well-being from the IO group, this would be very kind and awesome! 09:04 < Marex> +1 09:05 < kbingham> Morning all! 09:05 < wsa> okay, here are the status updates: 09:05 < wsa> A - what have I done since last time 09:05 < wsa> ------------------------------------ 09:05 < wsa> Geert 09:05 < wsa> : enabled (H)SCIF on R-Car M3-W+, developed a test to check SCIF status/data 09:05 < wsa> ordering and tested various variants, DT binding doc conversion to 09:05 < wsa> json-schema: sh-sci, rspi, cmt, tmu 09:05 < wsa> Shimoda-san 09:05 < wsa> : discussed with internal Renesas members about supporting eMMC v5.1 features 09:05 < wsa> for R-Car Gen4, reviewed PCIe endpoint support 09:05 < wsa> Ulrich 09:05 < wsa> : looked into issue with WDT clock still being disabled even though it is 09:05 < wsa> declared as ignore-unused 09:05 < wsa> Wolfram 09:05 < wsa> : had a look at the series about blocked I2C devices, sent out the last chunk 09:05 < wsa> of I2C API conversion patches, updated and sent "best TAP if all are good" 09:05 < wsa> for SDHI, worked on upporting BSP patch to avoid BAD_TAPs with SDHI, 09:05 < wsa> refactored FW parsing of i2c timings, reviewed patches for i2c core, 09:05 < wsa> assisted MM guys with virtual I2C devices and busses 09:05 < wsa> B - what I want to do until next time 09:05 < wsa> ------------------------------------- 09:05 < wsa> Geert 09:05 < wsa> : wants to follow up json-schema conversions, and check for more RSPI 09:05 < wsa> improvements 09:05 < wsa> Niklas 09:05 < wsa> : wants to keep looking what is missing upstream for thermal drivers 09:05 < wsa> Shimoda-san 09:05 < wsa> : wants to add more device nodes to R8A7796, continue to read the Ethernet HW 09:05 < wsa> IP document, test SDHI TAP patches from Wolfram, continue to collect 09:05 < wsa> information about "R-Car Gen4" hardware IPs, update renesas_sdhi_sys_dmac 09:05 < wsa> patches 09:05 < wsa> Ulrich 09:05 < wsa> : wants to post new ignore-unused clock series, implement xfer_atomic callback 09:05 < wsa> for i2c drivers 09:05 < wsa> Wolfram 09:05 < wsa> : wants to get the series about blocked I2C devices in DT applied, send out 09:05 < wsa> the SDHI patch to avoid bad TAPs, test Ulf's MMC core patches 09:06 < wsa> feel free to ask or comment if things are unclear 09:07 < wsa> other than that, I'd like to check if my assumptions about your load match reality 09:07 < wsa> geertu: some IO tasks once in a while, but otherwise busy enough with core work? 09:08 < wsa> Marex: busy enough with U-Boot and ATF stuff? 09:08 < Marex> wsa: pretty much, why ? 09:09 < wsa> neg: busy with MM stuff plus some love for the thermal drivers? :) 09:09 < Marex> wsa: U-Boot release is just around the corner 09:09 < neg> yes ;-) 09:09 < geertu> wsa: I pick up what comes in ;-) 09:09 < wsa> Marex: just want to make sure no one is running out of tasks without me noticing 09:09 < Marex> wsa: I think I'm good 09:10 < wsa> Marex: BTW can you resend this PCIe patch from ex-ARM guy Andrew? It is still not in -next, maybe a resend helps 09:11 < Marex> wsa: I have another PCIe patch to which I got no reply too 09:11 < Marex> wsa: seems PCIe subsystem is like that 09:11 < wsa> shimoda: probably overloaded with tasks :) 09:12 < wsa> Marex: it won't hurt much. And maybe [PATCH] looks better than [RFC] 09:12 < wsa> uli_: I think you have enough tasks for now? 09:12 < shimoda> wsa: yes, but I'm OK :) 09:13 < wsa> wsa: you won't be bored, right? 09:13 < uli_> wsa: for now i'm ok 09:13 < wsa> wsa: sadly not :D 09:13 < geertu> The merge window is open, so some people may not review patches 09:14 < wsa> okay, thanks guys. Seems my assumptions haven't been far off... 09:14 < Marex> wsa: sure, just telling you how things are over there 09:14 < wsa> Marex: yeah, I noticed meanwhile that PCIe is even slower than I2C ;) 09:15 < wsa> One question about M3-W+: if this patch is upstream ("dt-bindings: mmc: renesas_sdhi: Document r8a77961 support"), does it mean eMMC access has been tested? 09:16 < wsa> and M3-W+ is ES3.0 not ES1.3? (why can't i memorize this??) 09:17 < wsa> geertu: ? 09:17 < geertu> wsa: Yes, accessing eMMC on M3-W+ works 09:18 < geertu> i.e. I could read from it 09:19 < patersonc> wsa: and M3-W+ is v3.0 09:19 < geertu> Got a Tested-by from erosca, too 09:21 < wsa> thanks. I need to upport more SDHI quirk handling, so I need to take care about ES versions 09:22 < geertu> wsa: Feel free to do more extensive testing on the board in Magnus' farm 09:22 < wsa> geertu: this is likely to happen 09:22 < wsa> so, this is it from my side 09:22 < wsa> anything from yours? 09:23 < wsa> especially shimoda or damm? 09:23 < shimoda> nothing from my side 09:23 < kbingham> wsa, geertu, I wondered if you have any further comment on https://lore.kernel.org/lkml/20190710193918.31135-1-kieran.bingham+renesas@ideasonboard.com/ ... (Extending file2alias to simplify i2c device table entries when mixed with both an OF and I2C table?) ... I think the discussion headed towards a macro called I2C_OF_MODULE_DEVICE_TABLE() to simplify things. Any thoughts? Should I just 'do it'? 09:24 < damm> same here 09:24 < kbingham> (question is mostly targeted at Woflram, as Yamada-san suggested that any change there would go through wsa's tree :-) ) 09:25 < wsa> Is it hard to do? Usually it is easier to talk about code 09:25 < kbingham> I don't think it's hard, my question is mostly about policy I think :) 09:26 < wsa> I'd need to dive into that topic again otherwise to make useful comments :) 09:26 < kbingham> Ok :) 09:27 < kbingham> I'll try and prepare a v2 update then :) 09:27 < wsa> good, looking forward to it 09:28 < kbingham> Ok that's all from me then :P) 09:28 < wsa> last order for IO, then you have to move to the core-pub 09:28 < geertu> the pub is closed 09:28 < geertu> (except in Sweden?) 09:29 < wsa> then thanks for this meeting!