diff options
Diffstat (limited to 'wiki')
40 files changed, 3144 insertions, 3 deletions
diff --git a/wiki/Chat_log/20191219-mm-chatlog b/wiki/Chat_log/20191219-mm-chatlog new file mode 100644 index 0000000..c95fbf7 --- /dev/null +++ b/wiki/Chat_log/20191219-mm-chatlog @@ -0,0 +1,99 @@ +10:00 < pinchartl> welcome to the multimedia meeting +10:00 < pinchartl> topic 1: status updates +10:00 < pinchartl> * Jacopo +10:00 < pinchartl> Since last meeting: +10:00 < pinchartl> - RDACM21 bringup +10:00 < pinchartl> [RFC 00/11] GMSL: Initial RDACM21 support +10:00 < pinchartl> - max9286 v6 review and discussions +10:00 < pinchartl> - VIN BT/TB review +10:00 < pinchartl> - Miscellaneous linux-media patch review +10:00 < pinchartl> Until next meeting: +10:00 < pinchartl> - RDACM21 support +10:00 < pinchartl> Issues and blockers: None +10:00 < pinchartl> jmondi: any comment ? +10:01 < jmondi> not really :) +10:01 < pinchartl> thanks :-) +10:01 < pinchartl> next is Kieran, who told me today he wouldn't be able to join but would report by e-mail +10:01 < pinchartl> and who seemed to have forgotten to report by e-mail... +10:02 < pinchartl> kbingham[m]: eagerly waiting for your report :-) +10:02 < pinchartl> * Laurent +10:02 < pinchartl> Since last meeting: +10:02 < pinchartl> - Reviewed and merged Fabrizio's LVDS work +10:02 < pinchartl> - Fixed an issue in the CMM series +10:02 < pinchartl> - Sent pull request for CMM, LVDS dual link pixel order configuration +10:02 < pinchartl> and R8A7798 support for the DU +10:02 < pinchartl> - Tested VGA output on Draak +10:02 < pinchartl> - Lots of patch review +10:02 < pinchartl> Until next meeting: +10:02 < pinchartl> - Holidays +10:02 < pinchartl> - Resurect other pending patch series, with DU group rework being the +10:02 < pinchartl> first target +10:02 < pinchartl> Issues and Blockers: None +10:02 < pinchartl> any question ? +10:03 < pinchartl> * Morimoto-san +10:03 < pinchartl> Since last meeting: +10:03 < pinchartl> - Posting ALSA SoC framework cleanup patches +10:03 < pinchartl> Until next meeting: +10:03 < pinchartl> - Keep posting ALSA patches +10:03 < pinchartl> Issues and Blockers: None +10:03 < pinchartl> morimoto: I didn't include your secret task for the christmas season in the report, due to NDA +10:03 < pinchartl> but we all appreciate your hard work +10:04 < morimoto> thanks :) +10:04 < pinchartl> any other comment ? +10:04 < morimoto> no comment for it +10:04 < morimoto> you are nice NDA keeper :) +10:05 < pinchartl> thank you :-) +10:05 < pinchartl> * Niklas +10:05 < pinchartl> Since last meeting: +10:05 < pinchartl> - [PATCH v2] rcar-vin: Use correct pixel format when aligning format +10:05 < pinchartl> - [PATCH v2 1/2] rcar-vin: Handle special pixel formats in a switch +10:05 < pinchartl> - [PATCH v2 2/2] rcar-vin: Limit NV12 availability to supported VIN +10:05 < pinchartl> channels only +10:05 < pinchartl> - [PATCH] yavta: Fix usage documentation for --field option +10:05 < pinchartl> - [PATCH v3 0/2] rcar-vin: Support V4L2_FIELD_SEQ_{TB,BT} +10:05 < pinchartl> Until next meeting: +10:05 < pinchartl> - Christmas holidays +10:05 < pinchartl> Will work in a reduced mode until early January. Is available via mail +10:05 < pinchartl> and IRC with increased response times. +10:05 < pinchartl> (Niklas couldn't join but reported by e-mail instead) +10:06 < pinchartl> and that's it, unless my recent server issues caused me to miss any e-mail +10:06 < pinchartl> any quesiton or comment ? +10:07 < pinchartl> ok +10:07 < jmondi> not really from me +10:07 < pinchartl> any discussion topic ? +10:07 < jmondi> morimoto: is the ebisu thing resolved ? +10:08 < pinchartl> jmondi: have you had a chance to test the VGA output on Ebisu ? :-) +10:08 < jmondi> no it was planned for today +10:09 < jmondi> but morimoto-san said BSP team clarified +10:09 < pinchartl> ah I missed that +10:09 < morimoto> jmondi: yes. sorry for our noise +10:10 < morimoto> it was BSP team fault +10:10 < jmondi> morimoto: no worries +10:10 < jmondi> and thanks for being about to create a new year, one more time +10:10 < pinchartl> no worries, I'd rather have that than a real issue :-) +10:10 < morimoto> jmondi: no worries +10:11 < pinchartl> this may have been discussed while I was trying to solve my server issues +10:11 < pinchartl> do we have any plan to meet around FOSDEM ? +10:12 < jmondi> not being discussed +10:12 < jmondi> I'll be there and welcome meetings +10:13 < pinchartl> I will be there on Sunday, and available the week after FOSDEM +10:13 < pinchartl> let's discuss this over e-mail separately then +10:14 < pinchartl> last topic: time for the next meeting ? +10:14 < pinchartl> three weeks from now, on the 9th of January ? +10:15 < jmondi> wolfram was wondering if that's too close to holiday +10:15 < jmondi> I think that should be handled by email as well, to involve him ? +10:15 < pinchartl> ok +10:16 < pinchartl> geertu: do you plan to handle this as part of the core report ? +10:16 < kbingham[m]> pinchartl i sent the report at 7am? +10:16 < kbingham[m]> Didn't it get through? +10:16 < pinchartl> it's mentioned as TBD there, so let's discuss it there :-) +10:17 < pinchartl> kbingham[m]: it didn't I'm afraid +10:17 < pinchartl> it could be related to the recent server issues +10:17 < pinchartl> would you be able to resent it ? +10:17 < pinchartl> it can wait until later if you're not in front of your computer +10:18 < pinchartl> if there are no other discussion topics for today I propose adjourning this meeting +10:18 < pinchartl> does anyone second ? +10:20 < jmondi> I do :) +10:20 < jmondi> thanks everyone, and enjoy you holiday (if any :P ) +10:20 < pinchartl> meeting adjourned +10:20 < pinchartl> thank you all for attending diff --git a/wiki/Chat_log/20200227-mm-chatlog b/wiki/Chat_log/20200227-mm-chatlog new file mode 100644 index 0000000..92ffdc8 --- /dev/null +++ b/wiki/Chat_log/20200227-mm-chatlog @@ -0,0 +1,107 @@ +09:40 < pinchartl> welcome to the multimedia meeting +09:40 < pinchartl> topic 1. Status updates +09:41 < pinchartl> * Jacopo +09:41 < pinchartl> Since last meeting: +09:41 < pinchartl> - RDACM21 camera driver +09:41 < pinchartl> - support max9286 v7 upstreaming +09:41 < pinchartl> - Support BSP team 8camera tests +09:41 < pinchartl> Until next meeting: +09:41 < pinchartl> - Validate RDACM21 with 4 cameras +09:41 < pinchartl> Thanks to Kieran that setup can now be accessed remotely. +09:41 < pinchartl> - Send rdacm20 + max9271 + rdacm21(?) for inclusion +09:41 < pinchartl> Issues and blockers: None +09:41 < pinchartl> jmondi: any comment ? +09:42 < pinchartl> I assume not :-) +09:42 < pinchartl> * Kieran +09:42 < pinchartl> Since last meeting: +09:42 < pinchartl> - Fixups to MAX9286 +09:42 < pinchartl> - GMSL MAX9286 v7 posted (and chased/got an external review!) +09:42 < pinchartl> - Supporting Jacopo with RDCAM21 +09:42 < pinchartl> - Misc patch review +09:42 < pinchartl> Until next meeting: +09:42 < pinchartl> - Process max9286 review comments +09:42 < pinchartl> Only reasonably minor comments left to deal with, will post v8. +09:42 < pinchartl> Issues and blockers: None +09:43 < pinchartl> kbingham: any comment ? +09:43 < kbingham> pinchartl, nope +09:43 < jmondi> pinchartl: sorry, missed the notification, no comments sorry +09:44 < pinchartl> jmondi: no worries +09:44 < pinchartl> kbingham: thanks +09:44 < pinchartl> * Laurent +09:44 < pinchartl> Since last meeting: +09:44 < pinchartl> - Trip to FOSDEM +09:44 < pinchartl> - Multimedia meeting @Brussels with Jacopo and Niklas +09:44 < pinchartl> Discussions focussed on GMSL and upstreaming plans. The MAX9286 driver +09:44 < pinchartl> and the camera drivers will go upstream without waiting for multiplexed +09:44 < pinchartl> streams support in V4L2. +09:44 < pinchartl> - V4L2 multiplexed streams resurection +09:44 < pinchartl> Started resurecting the last version of the patch series to support +09:44 < pinchartl> multiplexed streams, targetting CSI-2 for GMSL. +09:44 < pinchartl> - Constify drm_driver +09:44 < pinchartl> Make it possible to declare the drm_driver structure as const, enhancing +09:44 < pinchartl> security. +09:44 < pinchartl> - Patch review +09:44 < pinchartl> Until next meeting: +09:44 < pinchartl> - Rebase, brush up and resend the V4L2 multiplexed streams proposal +09:44 < pinchartl> - Continue DU group rework +09:44 < pinchartl> Issues and Blockers: None +09:44 < pinchartl> any question ? +09:46 < moriperi> Could you enjoy FOSDEM ? +09:46 < pinchartl> a little bit +09:46 < pinchartl> I've actually spent most of my time in meetings +09:46 < pinchartl> but had a chance to meet Magnus, and then to have a nice group dinner, it was nice :-) +09:47 < moriperi> Hehe :) nice to know +09:47 < pinchartl> of course the biggest problem was that we all missed you and Shimoda-san +09:47 < moriperi> Yeah, that was not so good for us, too +09:48 < moriperi> BTW, Thank you Jacopo and Kieran for Camera support +09:48 < moriperi> s/support/hard work/ +09:48 < jmondi> moriperi: I really hope we can get all 4 cameras workgin easily +09:48 < jmondi> moriperi: thank you for interfacing with BSP team +09:49 < moriperi> No Problem. Thank you for your help. +09:49 < pinchartl> speaking of you :-) +09:49 < pinchartl> * Morimoto-san +09:49 < pinchartl> Since last meeting: +09:49 < pinchartl> - Continue to post patches for ALSA SoC +09:49 < pinchartl> The patches caused some issues on non-Renesas-platform. Back-and-forth +09:49 < pinchartl> discussions ongoing. +09:49 < pinchartl> Until next meeting: +09:49 < pinchartl> - Continue to post patches to ALSA ML +09:49 < pinchartl> v5.7-rcX will have big change on ALSA SoC, patches will need to be +09:49 < pinchartl> rebased. +09:49 < pinchartl> Issues and Blockers: CoViD-19 +09:49 < pinchartl> any comment ? +09:50 < moriperi> No. Thanks +09:50 < moriperi> I know CoViD-19 is now working at Europe, too, right ? +09:50 < moriperi> Are you guys all OK ? +09:50 < kbingham> jmondi knows the most about CoViD I think :) +09:51 * jmondi says hello from coronaItaly +09:51 < pinchartl> yes, it has been ported to the European market, successfully tested, and mass deployment is in progress +09:51 < moriperi> Hehe :) +09:51 < pinchartl> the return on investment seems dubious to me, but what do I know about business strategies ? :-) +09:52 < kbingham> Italians seem quite fond of it ... perhaps they have the right business model. +09:52 < jmondi> nothing is really happening, it's a seasona flu, but they're taking mass testing, so yeah, seems like a pandemy is going on +09:52 < jmondi> there's are 5 million people with season flu at the moment +09:52 < jmondi> and 300 with covid-19 +09:52 < jmondi> :) +09:52 < moriperi> Please really really take care +09:53 < pinchartl> people are starting to wear face masks in Europe, but they don't have the experience level of Japan, they don't know that the main purpose of the mask is to protect others, not yourself +09:54 < jmondi> ^ this is something really "funny"... peple wear masks not to get infected +09:54 < pinchartl> * Niklas +09:54 < pinchartl> Since last meeting: +09:54 < pinchartl> - Discussed V4L2 multiplexed streams with MM team at FOSDEM +09:54 < pinchartl> Until next meeting: +09:54 < pinchartl> - Post v4 of V4L2_CAP_IO_MC +09:54 < pinchartl> Issues and blockers: None +09:54 < pinchartl> neg: any comment ? +09:54 < neg> I will focus more on MM in the upcoming weeks +09:55 < neg> Other than that no comment +09:55 < pinchartl> thank you +09:55 < pinchartl> any additional comment or question from anyone ? +09:56 < neg> not from me +09:57 < pinchartl> ok +09:57 < pinchartl> any discussion topic ? +09:58 < pinchartl> short meeting then, I like that :-) +09:58 < pinchartl> I propose adjourning the meeting. does anyone second ? +09:59 < jmondi> seconded +09:59 < geertu> next meeting? +09:59 < pinchartl> meeting adjourned, thank you everybody for attending diff --git a/wiki/Chat_log/20200319-core-chatlog b/wiki/Chat_log/20200319-core-chatlog new file mode 100644 index 0000000..701ead2 --- /dev/null +++ b/wiki/Chat_log/20200319-core-chatlog @@ -0,0 +1,106 @@ +09:22 < geertu> Welcome to today's Core Group Chat Meeting! +09:22 < geertu> Agenda: +09:22 < geertu> 1. Status Updates +09:22 < geertu> 2. Discussion Topics +09:23 < geertu> Topic 1. Status updates +09:23 < geertu> A) What have we done since last time: +09:23 < geertu> Marek worked on OpenOCD (patch resync), U-Boot (SDHI performance, +09:23 < geertu> Blanche and SMC911x DM conversion), and Linux (PCIe suspend). +09:23 < geertu> Shimoda-san submmited rcar-usb2-clock-sel patches, and discussed the +09:23 < geertu> plan for the R-Car V3U bootloader. +09:23 < geertu> Ulrich sent v2 of the ignore-unused clock series, and reviewed patches. +09:23 < geertu> Geert converted the CPG/MSSR DT bindings to json-schema, upported +09:23 < geertu> CPUIdle for R-Car M3-N and E3, sent a second batch of pull requests for +09:23 < geertu> v5.7, and reworked the GPIO Aggregator. +09:24 < geertu> B) What we plan to do till next time: +09:24 < geertu> Marek plans to continue SMC911x work in U-Boot for Blanche. +09:24 < geertu> Shimoda-san plans to convert DT binding docs to json-schema, and will +09:24 < geertu> continue internal discussions about BL31 code for R-Car V3U. +09:24 < geertu> Geert will post v6 of the GPIO Aggregator, and hopes to resume QEMU GPIO +09:24 < geertu> virtualization. +09:25 < geertu> C) Problems we have currently: +09:25 < geertu> Shimoda-san regrets not being able to share the R-Car V3U Hardware +09:25 < geertu> User's manual. +09:25 < geertu> Covid-19 has reached EuroPeri space. +09:25 < geertu> ---EOL--- +09:25 < geertu> Anything I missed? +09:26 < geertu> shimoda22: What is ICUMXA? +09:27 < shimoda22> This is a CPU core which R-Car V3H has (section 68A) +09:27 < shimoda22> IICU, this is RH850 CPU core so that we don't have any free compiler.. +09:29 < geertu> Thx, forgot to search in the datasheet ;-) Google didn't really know +09:29 < geertu> RH850 is different from V850? +09:31 < shimoda22> perhaps same. V850 is NEC and RH850 is Renesas +09:32 < uli_> there's a surprisingly long wikipedia article on that: https://en.wikipedia.org/wiki/V850, including a section on "ancient prom writers" :) +09:32 < geertu> yep +09:32 < geertu> and gcc has v850 support +09:33 < Marex> Variant(s) V850 Family, +09:33 < Marex> RH850 Family +09:33 < Marex> well ... +09:34 < shimoda22> Oh, I didn't know gcc supports RH850. +09:35 < geertu> perhaps not the latest variant +09:35 < geertu> And it might have been removed in recent gcc versions +09:35 < wsa> Marex: I don't see this patch in next "[RFC] PCI: rcar: Fix incorrect programming of OB windows" although you reviewed it. Could you give a ping? +09:36 < geertu> At least gcc-9.1.0 still has v850-specific options +09:36 < geertu> Now, is that of any help? ;-) +09:39 < shimoda22> I don't know :) especially, the hardware manual doesn't say ICUMXA is related to RH850. +09:40 < Marex> wsa: sure, although I suspect that if Lorenzo took forever to review patches before this current mess, he would just ignore patches by now +09:41 < shimoda22> about pci, i reviewed other patches about pcie endpoint support. +09:41 < wsa> Marex: I see. Well, might be worth pointing out that the patch is not RFC anymore +09:42 < wsa> shimoda22: yes, great! I just updated this task in periject :) +09:42 < Marex> wsa: what surprises me more is that the original author is literally sitting with Lorenzo in the same office +09:42 < Marex> oh well +09:43 < Marex> wsa: I guess that unit of ARM is a mess +09:43 < wsa> well, then pinging Andrew might make more sense? ;) +09:44 < Marex> wsa: um, that's the author of the patch, you already asked me to ping him again +09:44 < kbingham> wsa, Is that Andrew Murray? +09:44 < kbingham> wsa, Andrew Murray left ARM. +09:44 < wsa> Marex: Initially, I was aiming for the maintainer, but if the author sits next to him, the latter might make more sense... +09:45 < wsa> ... that is, unless he left the company +09:45 < wsa> kbingham: where to? +09:45 < Marex> kbingham: didn't he join like a few months ago ? +09:46 < Marex> morimoto: btw thank you for the hint to buy instant ramen, I bought a large-ish crate +09:46 < morimoto> Hehe :) no worry +09:46 < kbingham> wsa, He took some external contract or something. +09:47 < kbingham> wsa, I can hire him if you (or rather Renesas) want me to get him to work directly on Renesas :-) +09:48 < wsa> kbingham: does he have any experience in I2C dynamic address assignment? :D +09:48 < kbingham> Marex, Well techincally he 're-joined' ... I don't know why he didn't want to stay there. Maybe he preferred being independent. +09:49 < kbingham> wsa, I think he's more experienced in PCI topics :) But I'm sure he's done I2C work too :) +09:49 < geertu> Topic 2. Discussion Topics +09:50 < geertu> Any other topics to discuss? +09:50 < wsa> kbingham: it is basically the same anyhow +09:50 < kbingham> wsa, :-D +09:50 < wsa> uli_: any idea why my testing of ignore-unused clocks fail? +09:51 < geertu> wsa: Because the clock was not enabled in the first place at all? +09:51 < wsa> geertu: I started it in U-Boot +09:51 < wsa> If I don't hack the code to bail out and forbid the kernel to ping the watchdog, it will reboot +09:52 < geertu> wsa: OK. +09:53 < geertu> Looking at drivers/clk/clk.c, CLK_IGNORE_UNUSED just prevents disabling the clock. +09:53 < wsa> that's what we want +09:53 < wsa> IIUC +09:53 < geertu> But only in the clk_disable_unused late_initcall +09:54 < geertu> it can still be disabled elsewhere +09:54 < geertu> I.e. manually, or through Runtime PM? +09:54 < geertu> WDT probe fails -> detached from PM Domain -> clock disabled? +09:54 < uli_> what i have checked is whether it will be temporarily disabled when the probing is deferred +09:54 < uli_> and that works +09:54 < wsa> yup +09:54 < wsa> uli_: ok +09:55 < geertu> works == not temporarily disabled? +09:55 < uli_> yes +09:57 < geertu> Looks like cpg_mstp_clock_endisable() needs some debug code to track what happens to the WDT clock +09:57 < patersonc> wsa: geertu: Fabrizio left us in December. But in a twist of fate he's actually going to be re-joining us b/April. Huzzah! +09:58 < wsa> uli_: can you do that? +09:58 < uli_> sure +09:58 < patersonc> But this time he'll have a @renesas.com email address instead of a @bp.renesas.com address :) +09:58 < wsa> uli_: thanks! +09:58 < wsa> patersonc: leaving and rejoining is a thing these days? :) +09:59 < patersonc> wsa: It's a long complicated story! +09:59 < geertu> patersonc: Great! Looking forward to seeing a patch for .mailmap +09:59 < geertu> wsa: I'll rejoin public life in 5 weeks or so (or not) +10:00 < wsa> patersonc: anyway, glad he will be back! +10:00 < wsa> geertu: isn't it more like public life will rejoin us? +10:00 < patersonc> Same here +10:01 < geertu> Let's finish the Core meetinng with this great news. Unless someone has something to add? +10:02 < patersonc> Sorry to interrupt! +10:02 < geertu> patersonc: np, we like positive news +10:03 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20200319-io-chatlog b/wiki/Chat_log/20200319-io-chatlog new file mode 100644 index 0000000..88e43c7 --- /dev/null +++ b/wiki/Chat_log/20200319-io-chatlog @@ -0,0 +1,71 @@ +09:04 < wsa> So, let's start the IO meeting +09:04 < wsa> welcome everyone +09:04 < shimoda> hello +09:04 < wsa> here are the status updates: +09:05 < wsa> Status updates +09:05 < wsa> ============== +09:05 < wsa> A - what have I done since last time +09:05 < wsa> ------------------------------------ +09:05 < wsa> Geert +09:05 < wsa> : converted various DT binding docs to json-schema, added R-Car M3-W+ Thermal +09:05 < wsa> support, implementeed active-high chipselect support for RSPI, enabled PWM +09:05 < wsa> and TPU on R-Car M2-W, and exercised MSIOF with quad YRSK-LCD-PMOD +09:05 < wsa> Marek +09:05 < wsa> : submitted PCIe suspend patch +09:05 < wsa> Niklas +09:05 < wsa> : fixed some issues in the thermal drivers, converted the binding docs to json, +09:05 < wsa> and took over maintainership +09:05 < wsa> Shimoda-san +09:05 < wsa> : continued to learn the new Ethernet HW IP specification/concept, and reviewed +09:05 < wsa> PCIe endpoint support for RZ/G2E +09:05 < wsa> Ulrich +09:05 < wsa> : sent clock patches to allow watchdog handover from bootloader +09:05 < wsa> Wolfram +09:05 < wsa> : resent series about blocked I2C devices in DT, simplified TAP selection and +09:05 < wsa> refactored and upported "best TAP if all are good" patches for SDHI, updated +09:05 < wsa> and resent I2C API changes and finally prepared the last chunk of it, +09:05 < wsa> reviewed and tested Ulrich's "ignore-unused-clocks" patches +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 look 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 USB related nodes for R8A77961, continue to read the Ethernet +09:05 < wsa> HW IP document and design the driver implementation, continue to collect +09:05 < wsa> information about "R-Car Gen4" hardware IPs, and update renesas_sdhi_sys_dmac +09:05 < wsa> patches if possible +09:05 < wsa> Wolfram +09:05 < wsa> : wants to get the series about blocked I2C devices in DT applied, upport BSP +09:05 < wsa> patch to avoid BAD_TAPs with SDHI, send out the last chunk of I2C API +09:05 < wsa> conversion patches, and test Ulf's recent MMC core patches +09:05 < wsa> please let me know if you think it needs corrections +09:06 < wsa> BTW when sending out patches, the mail to Fabrizio bounced. He left? +09:08 < geertu> wsa: Yes, Fabrizio left at the end of the 2019 +09:08 < wsa> shimoda: I guess with the home office situation, there is no news from the HW team about the manual calibration issue for SDHI? +09:09 < wsa> geertu: where to? is this known? +09:10 < geertu> patersonc: ^ +09:10 < wsa> and now for the number game: "R-Car H3 Ver3.0" does this have a new name/number meanwhile? +09:10 < shimoda> wsa: I don't know. So, I'll ask BSP team or the HW team. +09:10 < wsa> shimoda: Thanks! +09:12 < kbingham> wsa, does Ver3.0 mean ES3.0? (I.e. is ver==es) ? +09:12 < wsa> geertu: We still have this "2cycle-delay" patch for H3-ES3.0-SPI in a task. But as it seems we can't get HW for years now, I think it makes sense to abandon the task and revive it iff we get HW? +09:13 < geertu> wsa: I agree +09:14 < wsa> cool +09:16 -!- shimoda19 [7cd216c3@KD124210022195.ppp-bb.dion.ne.jp] has joined #periperi +09:16 -!- shimoda19 [7cd216c3@KD124210022195.ppp-bb.dion.ne.jp] has quit Remote host closed the connection +09:16 < wsa> uli_: I will write you later with a potential task for you (SDHI related) +09:16 < uli_> ok +09:16 < wsa> other than that, any questions from your side? +09:17 -!- shimoda22 [7cd216c3@KD124210022195.ppp-bb.dion.ne.jp] has joined #periperi +09:17 < geertu> kbingham: Yes, VerX.Y = ESX.Y = WSX.Y (AFAIK) +09:18 < kbingham> geertu, ack. Thanks for clarification +09:18 < shimoda22> sorry, for noise. I don't know why "shimoda" is remained... +09:18 -!- shimoda [d2a0fca9@210.160.252.169] has quit Ping timeout: 240 seconds +09:19 < wsa> well, it seems this was it for today already? +09:19 < wsa> well, geertu, then have an early start :) +09:20 < neg> I have nothing more, thank you +09:21 < wsa> geertu: ready? +09:22 < geertu> yep diff --git a/wiki/Chat_log/20200319-mm-chatlog b/wiki/Chat_log/20200319-mm-chatlog new file mode 100644 index 0000000..a0e485b --- /dev/null +++ b/wiki/Chat_log/20200319-mm-chatlog @@ -0,0 +1,150 @@ +10:04 < pinchartl> welcome to the multimedia meeting +10:04 < pinchartl> Topic 1. Status Check for the Multimedia Tasks +10:05 < pinchartl> * Jacopo +10:05 < pinchartl> Since last meeting: +10:05 < pinchartl> - V4L2 subdev bus configuration API +10:05 < pinchartl> Extend the V4L2 framework to provide an operation to configure bus +10:05 < pinchartl> parameters to allow CSI-2 data lane negotiation between ADV748x and +10:05 < pinchartl> R-Car CSI-2. +10:05 < pinchartl> -[PATCH 0/4] v4l2-subdev: Introduce get_mbus_format pad op +10:05 < pinchartl> - MAX9286 parameter configuration options +10:05 < pinchartl> - [PATCH 0/5] media: i2c: max9286: Add configuration properties +10:05 < pinchartl> - Patch review and discussion +10:05 < pinchartl> - [PATCH] media: v4l2-async: Accept endpoints and devices for fwnode matching +10:05 < pinchartl> - [PATCH v7 2/2] media: i2c: Add MAX9286 driver +10:05 < pinchartl> - [periperi] kernel v5.4 VIN multi camera +10:05 < pinchartl> - [PATCH] [RFC] media: rcar-vin: don't wait for stop state on clock lane during start of CSI2 +10:05 < pinchartl> Until next meeting: TBD +10:05 < pinchartl> Issues and blockers: None +10:05 < pinchartl> jmondi: any comment ? +10:05 < jmondi> that I forgot point B) :) +10:05 < pinchartl> I was wondering about it :-) +10:06 < pinchartl> so what do you plan to do until next meeting ? +10:06 < jmondi> - defined max9286 negotiation parameters including new use cases (eg Xilinx using max96705) +10:06 < jmondi> - conitnue pushing get_mbus_config() to support adv748x-rcar-csi2 date lane negotiation +10:07 < jmondi> sorry, I left those points out :/ +10:07 < jmondi> nothing more to add +10:07 < pinchartl> no worries +10:07 < pinchartl> * Kieran +10:07 < pinchartl> Since last meeting: +10:07 < pinchartl> - MAX9286/GMSL ongoing development (and support with Jacopo) +10:07 < pinchartl> - Async matching developments and review +10:07 < pinchartl> Driven by both the MAX9286 posting, and then Laurent's version driven by +10:07 < pinchartl> the RZ/G1. +10:07 < pinchartl> - FCP Max segment size bug fix +10:07 < pinchartl> No segment size is set, and the core defaults to SZ_64K. +10:07 < pinchartl> - Patch review +10:07 < pinchartl> Until next meeting: TBD +10:07 < pinchartl> Issues and blockers: None +10:07 < pinchartl> kbingham: any comment ? +10:08 < kbingham> TBD? Did I also leave it blank? +10:08 < pinchartl> as far as I can tell... +10:09 < kbingham> # Until next meeting +10:09 < kbingham> - Continue to push towards some integration of MAX9286, along with Jacopo +10:09 < pinchartl> ah no you didn't +10:09 < pinchartl> I was just too tired :-S +10:09 < pinchartl> sorry +10:10 < pinchartl> thank you +10:10 < pinchartl> * Laurent +10:10 < pinchartl> Since last meeting: +10:10 < pinchartl> - Fix V4L2 async endpoint match +10:10 < pinchartl> Sent a new fix for the incompatibility between V4L2 subdevs and bridges. +10:10 < pinchartl> Feedback has been provided, a new version is needed, with minor changes. +10:10 < pinchartl> - V4L2_CAP_IO_MC + VIDIOC_ENUM_FMT +10:10 < pinchartl> Extended Niklas' V4L2_CAP_IO_MC series with an extension for the +10:10 < pinchartl> VIDIOC_ENUM_FMT API to bridge the MC and V4L2 APIs. +10:10 < pinchartl> - V4L2 multiplexed streams +10:10 < pinchartl> Continued work on V4L2 multiplexed streams, splitting out media bus +10:10 < pinchartl> configuration that Jacopo has now handled as a separate patch series. +10:10 < pinchartl> - Patch review +10:10 < pinchartl> The most notable reviewed topics include +10:10 < pinchartl> - DRM bus format negotiation +10:10 < pinchartl> - adv748x HDMI audio clock +10:10 < pinchartl> - Geert's PWM +10:10 < pinchartl> - Niklas' V4L2_CAP_IO_MC and MC graph completion +10:10 < pinchartl> - Prabhakar's OV5645 +10:10 < pinchartl> Until next meeting: +10:10 < pinchartl> - Complete and send the V4L2 multiplexed streams proposal +10:10 < pinchartl> - Continue DU group rework +10:10 < pinchartl> Issues and Blockers: No contract for Q2 yet +10:10 < pinchartl> any question ? +10:11 < patersonc> Not a question, but thanks all for your reviews of Prabhakar's patches +10:11 < pinchartl> patersonc: you're welcome +10:11 < pinchartl> * Morimoto-san +10:11 < pinchartl> Since last meeting: +10:11 < pinchartl> - Keep posting ALSA SoC patches +10:11 < pinchartl> Feedback was provided, and bugs were found. +10:11 < pinchartl> - Started not go to Renesas Office +10:11 < pinchartl> Until next meeting: +10:11 < pinchartl> - Keep posting ALSA SoC patches +10:11 < pinchartl> Issues and Blockers: Our health +10:11 < pinchartl> morimoto: any comment ? +10:12 < morimoto> pinchartl: I ordered Q2 SoW, so you will be happy soon +10:12 < morimoto> I also wokrd for yaml base Doc, but no responce from ML +10:12 < morimoto> And, that's it. thanks +10:12 < pinchartl> morimoto: \p/ +10:12 < pinchartl> thank you +10:13 < pinchartl> I'll add the yaml work to the report, thank you +10:13 < pinchartl> * Niklas +10:13 < pinchartl> Since last meeting: +10:13 < pinchartl> - [PATCH v3] dt-bindings: rcar-vin: Convert bindings to json-schema +10:13 < pinchartl> - [PATCH v4 0/3] v4l2-dev/ioctl: Add V4L2_CAP_IO_MC +10:13 < pinchartl> - [PATCH] vimc: Report a colorspace +10:13 < pinchartl> - [PATCH v5 0/4] v4l2-dev/ioctl: Add V4L2_CAP_IO_MC +10:13 < pinchartl> - [PATCH 0/2] v4l2-compliance: add tests for V4L2_CAP_IO_MC +10:13 < pinchartl> - [RFC 0/5] media-device: Report if graph is complete or not +10:13 < pinchartl> - [PATCH 0/2] v4l-utils: media-ctl: Print media graph completes if available +10:13 < pinchartl> - R-Car VIN and CSI-2 have started to get 3rd party contributions! +10:13 < pinchartl> Tested, reviewed and tried to guide the effort. +10:13 < pinchartl> Until next meeting: +10:13 < pinchartl> - Keep reviewing new iterations of VIN related patches +10:13 < pinchartl> - If their is time look at Laurent's v4l2-async patch series +10:13 < pinchartl> Issues and blockers: None +10:13 < pinchartl> neg: any comment ? +10:14 < neg> I will also try to look at ENUM_FMT for next meeting +10:14 < neg> other than that, no comment +10:15 < pinchartl> thank you +10:15 < pinchartl> any question or comment from anybody else ? +10:16 < neg> I'm happy to see we are all collaboratively attacking V4L2 core ;-) +10:16 < jmondi> I still have that weird issue on RDACM21 to clarify with BSP team +10:16 < jmondi> but as long as the situation is the current one I don't think there can be any progress +10:17 < pinchartl> if they can't test it due to lack of hardware access, indeed +10:17 < jmondi> as most people is not at the office so access to hardware is limited +10:17 < jmondi> yep +10:17 < morimoto> jmondi: thank you for helping them +10:17 < jmondi> morimoto: thank you for your support +10:17 < jmondi> passing messages between us and BSP team is not fun I guess +10:18 < pinchartl> maybe someone should go to the office wearing this http://ideasonboard.org/corona-in-finland.jpg to recover the hardware +10:18 < pinchartl> (the picture was taken in Finland) +10:18 < morimoto> wow, it is you ? +10:18 < neg> morimoto: haha +10:18 < jmondi> ahaha +10:19 < jmondi> that's how Laurent dresses up when he has to review our patches +10:19 < kbingham> hahah +10:19 < morimoto> :) +10:19 < pinchartl> I don't own such a pretty mask, no :-) +10:19 < patersonc> There's a video I've seen of someone in a dinosaur suit in tescos +10:20 < geertu> How do you get the food out of the bags without contaminating it? +10:21 < wsa> next meeting on April, 9th? +10:21 < pinchartl> patersonc: that I wish will continue to happen after the epidemic, it's fun :-) +10:21 < pinchartl> wsa: I was going to ask +10:21 < pinchartl> Europe will have switched to DST +10:21 < patersonc> pinchartl: Stocks of the suits are probably low though +10:21 < jmondi> yeah! we can enjoy more time outside in the ligt +10:21 < jmondi> ah, no +10:21 < pinchartl> should we thus move the meeting forward by one hour, or would our Japanese friends prefer meeting an hour earlier ? +10:21 < jmondi> :( +10:22 < geertu> jmondi: Do you have a garden? Here enjoying time in your garden is still allowed +10:23 < jmondi> I have a balcony, it really helps :) +10:23 < geertu> pinchartl: Usually we let our Japanese friends meet earlier +10:23 < shimoda22> pinchartl: an hour earlier sounds good to me :) +10:23 < pinchartl> shimoda22: I suspected it would :-) +10:24 < pinchartl> let's do that then +10:24 < pinchartl> any discussion topic for multimedia ? +10:24 < neg> None from me +10:24 < kbingham> None here currently. +10:25 < pinchartl> I then propose adjourning the meeting. does anyone second ? +10:26 < neg> second +10:26 < morimoto> 2nd +10:26 < jmondi> yup yup +10:27 < pinchartl> meeting adjourned diff --git a/wiki/Chat_log/20200409-core-chatlog b/wiki/Chat_log/20200409-core-chatlog new file mode 100644 index 0000000..78340dc --- /dev/null +++ b/wiki/Chat_log/20200409-core-chatlog @@ -0,0 +1,91 @@ +09:31 < geertu> Welcome to today's Core Group Chat Meeting! +09:31 < geertu> Agenda: +09:31 < geertu> 1. Status Updates +09:31 < geertu> 2. Discussion Topics +09:31 < geertu> Topic 1. Status updates +09:31 < geertu> A) What have we done since last time: +09:31 < geertu> Marek worked on U-Boot (SMC911x DM conversion, pre-release testing, SH +09:31 < geertu> ether PHY, DTS sync, defconfig naming, EHCI fix), and ATF (test with +09:31 < geertu> latest U-Boot). +09:31 < geertu> Shimoda-san reported an nfsroot issue, and investigated R-Car V3U SYSC +09:31 < geertu> differences. +09:31 < geertu> Ulrich looked into the WDT clock being disabled issue. +09:31 < geertu> Geert posted v6 of the GPIO Aggregator, investigatd an nfsroot +09:31 < geertu> regression, and resumed QEMU GPIO virtualization. +09:32 < geertu> B) What we plan to do till next time: +09:32 < geertu> Marek wonders about Gen2 Wheat U-Boot support, +09:32 < geertu> Shimoda-san plans to convert DT binding docs to json-schema, and +09:32 < geertu> continue internal discussions about BL31 code for R-Car V3U. +09:32 < geertu> Ulrich plans to post a new ignore-unused clock series. +09:32 < geertu> Geert plans to do more DT binding doc conversions, and will continue +09:32 < geertu> QEMU GPIO virtualization. +09:33 < geertu> C) Problems we have currently: +09:33 < geertu> Covid-19 is still active, and Morimoto-san is ill (hopefully not related). +09:33 < geertu> ---EOT--- +09:33 < geertu> Anything I missed? +09:34 < geertu> Topic 2. Discussion Topics +09:36 < geertu> Anything to discuss? +09:37 < shimoda> nothing from my side +09:37 < damm> same here +09:38 < damm> how to support morimoto-san perhaps? +09:38 < damm> maybe i should buy some booze for him? +09:38 < neg> I think so +09:39 < damm> so he can drown his sorrows and/or enjoy the effort +09:39 < geertu> damm: booze to be combined with medication? +09:39 < damm> unfortunately i don't have any homebrew equipment at hand +09:39 < damm> booze _is_ the medication +09:39 < damm> =) +09:40 < jmondi> for sure it's an effective disinfectant +09:40 < damm> anyone knows what kind of stuff he would like? +09:40 < wsa> swedish bitters? +09:41 < Marex> damm: booze as in neck-santizer against covid ? +09:41 < jmondi> is he at home or hospital ? I'm not sure nurses will be happy about you bringing booze there as a present :) +09:41 < damm> i suppose if it is strong enough it is multipurpose +09:41 < wsa> he really likes local recpies :) +09:41 < neg> wsa: bäska droppar it is love +09:42 < shimoda> jmondi: i think he is in his family's home +09:42 < damm> i ordered some amaro for myself. but it might not be strong enough +09:43 < wsa> interesting, there is now swedish wikipedia article about swedish bitters :D +09:43 < wsa> (at least it is not linked) +09:43 < damm> lets see if i can find baska droppar on amazon.co.jp +09:43 < damm> as alternative, any other suggestion? +09:44 < damm> a big bottle of tabasco? +09:44 < damm> does anyone remember the color, was it red or green in spain? +09:44 < kbingham> ^ +1 :) +09:44 < wsa> red +09:44 < wsa> +1 BTW :D +09:45 < damm> ok i'll see what i can find +09:45 < damm> thanks for the suggestions! +09:45 < damm> that's it from my side +09:45 < jmondi> ahah, +1 for the tasbasco +09:45 < jmondi> "just for the bloody mary" +09:45 < wsa> neg: maybe you have an alternative now in case there is no white-lemon chocolate in Sweden anymore ;) +09:47 < neg> wsa: I have not found an alternative for that yet I'm afraid +09:48 < wsa> no bäska droppar in Sweden anymore? +09:50 < jmondi> can I have 5 minutes before the MM meeting ? +09:50 < neg> sorry I meant to the white-lemon chocolate. I'm sure there are still bäska droppar left in Sweden, who else would buy such stuff ;-) +09:50 < kbingham> jmondi, You could potentially have 10 :) +09:50 < jmondi> it's supposed to start at 10, so I have 10 :) +09:50 < jmondi> kbingham: ineded :) +09:51 < geertu> Let's stretch the commercial break until the MM meeting... +09:51 < geertu> Any other items I should stockpile in my NBC bunker? +09:51 < Marex> damm: do you happen to have V2H Wheat in your remote lab ? +09:51 < Marex> geertu: NBC ? Obviously more TP rolls +09:52 < geertu> Marex: periject$ git grep wheat farm-magnus -- farm/magnus/ssh_config +09:52 < geertu> Marex: yeah, port 9207 +09:53 < Marex> geertu: is that where it's tracked now, ok +09:54 < geertu> Marex: well, that was an RFC, but I pushed it out to a branch +09:54 < Marex> geertu: nope, can't connect +09:54 < Marex> I guess I need to have my key added +09:54 < damm> i'll see if i can fix it up, please wait +09:54 < Marex> damm: thank you +09:56 < wsa> BTW, next meeting in 3 weeks? April, 30th? +09:57 < geertu> Fine for me +09:57 < neg> me too +09:57 < Marex> assuming the utilities still work by then, sure +09:58 < shimoda> i'm afraid apr 30th will be in a vacation in Japan +09:58 < geertu> may 7th? +09:58 < shimoda> so, how about May, 7th? +09:59 < wsa> works for me +10:00 < Marex> shimoda: golden week, right ? +10:00 < geertu> Thanks for joining, and have a nice continued and safe day! diff --git a/wiki/Chat_log/20200409-io-chatlog b/wiki/Chat_log/20200409-io-chatlog new file mode 100644 index 0000000..0b513c6 --- /dev/null +++ b/wiki/Chat_log/20200409-io-chatlog @@ -0,0 +1,96 @@ +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! diff --git a/wiki/Chat_log/20200514-core-chatlog b/wiki/Chat_log/20200514-core-chatlog new file mode 100644 index 0000000..3f31c36 --- /dev/null +++ b/wiki/Chat_log/20200514-core-chatlog @@ -0,0 +1,66 @@ +09:32 < geertu> Welcome to today's Core Group Chat Meeting! +09:32 < geertu> Agenda: +09:32 < geertu> 1. Status Updates +09:32 < geertu> 2. Discussion Topics +09:32 < geertu> Topic 1. Status updates +09:32 < geertu> A) What have we done since last time: +09:32 < geertu> Marek worked on ATF (DT memory node fix), Linux (PCIe suspend/resume +09:32 < geertu> fixes), OpTeeOS (memory node passing), U-Boot (DM conversion, bug fixes, +09:32 < geertu> CI, memory node passing, module clocks), and QEMU (Tulip ethernet fix). +09:32 < geertu> Morimoto-san enjoyed Golden Week (I'm sure there are others, too ;-). +09:32 < geertu> Shimoda-san submitted DT binding doc conversions ({rcar,usb}-dmac, +09:32 < geertu> ipmmu) and fixes for IOMMU device node names. +09:32 < geertu> Ulricht sent v3 of the never-disable-WDT-clock series. +09:32 < geertu> Geert did more DT binding doc conversions (clocks, gpio, intc-irqpin, +09:32 < geertu> sh-pfc), leading to more DTS fixes, +09:32 < geertu> posted GPIO Aggregator v7 and QEMU GPIO virtualization v2, sent pull +09:32 < geertu> requests for v5.8, and reviewed lots of RZ/G1H patches. +09:33 < geertu> B) What we plan to do till next time: +09:33 < geertu> Marek plans to do more U-Boot ethernet cleanups and DM conversions. +09:33 < geertu> Morimoto-san plans to try to solve the Renesas inside issue. +09:33 < geertu> Shimoda-san plans to continue internal discussions about BL31 code for +09:33 < geertu> R-Car V3U. +09:33 < geertu> Geert plans to do more DT binding doc conversions, and will continue +09:33 < geertu> QEMU GPIO virtualization. +09:33 < geertu> C) Problems we have currently: +09:33 < geertu> Covid-19 is still active. +09:33 < geertu> ---EOT--- +09:34 < geertu> morimoto: Is it related to https://upload.wikimedia.org/wikipedia/commons/4/44/Intel_Inside_Logo.svg ? +09:34 < morimoto> Yeah, maybe :) +09:36 < geertu> uli__: I start to wonder if we should just add the RWDT clocks to crit_mod_clks[]? +09:37 < uli__> but then they'll be up even if the wdt is not used. not sure how common either use case is, though +09:37 < geertu> While renesas-cpg-mssr.h says: /* Critical Module Clocks that should not be disabled */ +09:37 < geertu> clk-provider.h says: /* do not gate, ever */ +09:37 < geertu> uli__: You mean if the kernel is started with the RWDT clock disabled? +09:38 < uli__> yes +09:39 < geertu> uli__: Set CLK_IS_CRITICAL if enabled at cpg-mssr driver init? +09:39 < uli__> hmm... +09:39 < uli__> i guess that would be an option +09:40 < geertu> It would avoid messing with cpg_mstp_clock_endisable() +09:41 < geertu> I guess that rule could even be applied to crit_mod_clks[], so you don't need a second array +09:42 < geertu> (the kernel will never be entered with INTC-AP disabled) +09:44 < geertu> Topic 2. Discussion Topics +09:44 < geertu> Anything to discuss? +09:48 < geertu> How are the cherry blossoms? +09:48 < damm> blown by the wind in northen japan i believe +09:48 -!- shimoda [~shimoda@KD124210022195.ppp-bb.dion.ne.jp] has quit [Ping timeout: 260 seconds] +09:48 < geertu> Mine is no longer blossoming, too late in the year already +09:52 < geertu> OK, let's finish... slowly... for pinchartl to take over... +09:52 < wsa> maybe time to discuss the next meeting? +09:52 < wsa> June, 11th? +09:53 < wsa> i think quad-weekly is kind of okay for now? +09:53 < pinchartl> works for me +09:53 -!- shimoda [~shimoda@KD124210022195.ppp-bb.dion.ne.jp] has joined #periperi +09:54 < geertu> pinchartl: me too +09:54 < geertu> if the JP side agrees? +09:54 < morimoto> it is OK for me +09:55 < shimoda> sorry my laptop disconnected wifi. what is now talking about? +09:55 < Marex> 09:48 -!- shimoda [~shimoda@KD124210022195.ppp-bb.dion.ne.jp] has quit [Ping timeout: 260 seconds] +09:55 < Marex> 09:48 < geertu> Mine is no longer blossoming, too late in the year already +09:55 < Marex> 09:52 < geertu> OK, let's finish... slowly... for pinchartl to take over... +09:55 < Marex> 09:52 < wsa> maybe time to discuss the next meeting? +09:55 < Marex> 09:52 < wsa> June, 11th? +09:55 < Marex> 09:53 < wsa> i think quad-weekly is kind of okay for now? +09:56 < Marex> 09:53 < pinchartl> works for me +09:56 < shimoda> Marex: thanks! June, 11th is OK for me too +09:58 < geertu> OK, so thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20200514-io-chatlog b/wiki/Chat_log/20200514-io-chatlog new file mode 100644 index 0000000..5af33ab --- /dev/null +++ b/wiki/Chat_log/20200514-io-chatlog @@ -0,0 +1,88 @@ +09:04 < wsa> welcome back, morimoto-san! +09:04 < wsa> so, here are the status updates +09:04 < wsa> Status updates +09:04 < wsa> ============== +09:04 < wsa> A - what have I done since last time +09:04 < wsa> ------------------------------------ +09:04 < wsa> Geert +09:04 < wsa> : did DT binding doc conversion to json-schema for CMT, OSTM, TMU, WDT, and fixed the DMA boundary mask for SATA +09:04 < wsa> Marek +09:04 < wsa> : fixed bugs in R-Car PCIe suspend/resume path +09:04 < wsa> Niklas +09:04 < wsa> : did DT binding doc conversion to json-schema for Thermal, also a cleanup for the thermal driver +09:04 < wsa> Shimoda-san +09:04 < wsa> : submitted patches to enable PWM and PCIE on R8A77961, reviewed PCIe endpoint support +09:04 < wsa> Ulrich +09:04 < wsa> : sent a new version of the never-disable-WDT-clock series, and worked on atomic_xfer support for i2c-sh_mobile +09:04 < wsa> Wolfram +09:04 < wsa> : upported SDHI patch to avoid bad TAPs with HS400, debugged an SDHI clock imbalance regression found by Geert and sent a fix and another clock related improvement, pushed the final changes of I2C API conversion, guided a bit of discussions about blocked I2C devices and refactored the documentation for generic I2C bindings as a preparation, minor changes to SDHI, CSI2, DRM, I2C, +09:04 < wsa> reviewed upstream changes to the i2c-slave interface +09:04 < wsa> B - what I want to do until next time +09:04 < wsa> ------------------------------------- +09:04 < wsa> Geert +09:04 < wsa> : wants to do more DT binding doc conversions to json-schema, and check for RSPI improvements +09:04 < wsa> Shimoda-san +09:04 < wsa> : wants to check a BSP team's report about dma map/unmap unbalance in the error path of the SDHI driver, continue to collect information about "R-Car Gen4" hardware IPs, continue to make a plan how to implement the Gen4 Ethernet HW IP driver, and update renesas_sdhi_sys_dmac patches if possible +09:04 < wsa> Ulrich +09:04 < wsa> : wants to finish i2c-sh_mobile and implement i2c-rcar atomic_xfer support +09:04 < wsa> Wolfram +09:04 < wsa> : wants to debug OOPSes when NON_REMOVABLE workaround for SDHI is removed, get the series about blocked I2C devices in DT applied, review Ulrich's new WDT clock patches +09:04 < morimoto> geertu: thanks. Yes, Now I'm OK +09:05 < wsa> C - problems I currently have +09:05 < wsa> ----------------------------- +09:05 < wsa> everyone +09:05 < wsa> : covid19 restrictions everywhere +09:05 < wsa> questions I have +09:06 < wsa> uli__: was it possible to kind of reuse the non-atomic xfer function for the atomic one? Or does it need a seperate function? +09:06 < uli__> for sh_mobile, it's possible to reuse what is there +09:06 < uli__> rcar is a bit more convoluted, i still have to look into that +09:06 < wsa> shimoda: I forgot, "update renesas_sdhi_sys_dmac patches if possible", what kind of issue is fixed by these patches? +09:07 < wsa> uli__: well, still, a good start for sh_mobile then. Good news! +09:08 < wsa> shimoda: also looking forward to the new DMA imbalance thing for SDHI ;) +09:08 < shimoda> wsa: this is related to performance problem. but, today, i don't have any compline from a reporter. so, we can postpone I think :) +09:09 < wsa> shimoda: okay +09:09 < shimoda> wsa: yes, i got this imbalance report on 12th May, but this report is in Japanese. I cannot forward it to EuroPeri now... +09:10 < wsa> After the clk and RPM updates to the SDHI driver (posted yesterday), I know get interesting OOPSes when I try to revert the NON_REMOVABLE workaround we still have in the driver +09:10 < wsa> s/know/now/ +09:10 < wsa> which is nice because I always suspected them to be RPM related +09:11 < geertu> wsa: you mean they might be DMA related? +09:11 < wsa> geertu: DMA? +09:12 < geertu> wsa: ^ DMA imbalance +09:12 < shimoda> imbalance issue seems to be possible to happen. but, there is difficult to reproduce, i guess. +09:12 < wsa> nope, the DMA imbalance seems to be in the error path of probe +09:12 < geertu> wsa: I agree it's good to have a reliable reproducer +09:13 < wsa> yeah, I will have a close look the next days +09:14 < wsa> i think this is it from my side... +09:14 < wsa> anything to discuss on your side? +09:14 < wsa> like people volunteering to do more DT binding conversions? ;) +09:15 < neg> :-) +09:15 < geertu> wsa: I'll give your SDHI patches a try on the other platforms +09:15 < wsa> geertu: much appreciated, thanks! +09:15 < geertu> The _noidle one looks like a nice catch +09:16 < geertu> wsa: Just wondering, why do you still need renesas_sdhi_clk_{en,di}sable()? +09:16 < wsa> yes, well hidden within all these RPM calls +09:16 < wsa> the TMIO core calls it +09:17 < shimoda> ah, btw, do you know whether ethernet driver causes tx watchdog timeout? +09:17 < shimoda> s/whether/how to cause/ +09:17 < geertu> wsa: Let me rephrase: why didn't you make renesas_sdhi_clk_{en,di}sable() empty? +09:18 < shimoda> https://marc.info/?l=linux-renesas-soc&m=158641874314353&w=2 +09:18 < geertu> shimoda: Doesn't that mean the packet couldn't be sent, e.g. due to bad cable, or corrupted TX ring buffer? +09:19 < wsa> geertu: I don't get what you mean. It is needed when the TMIO core calls suspend/resume +09:20 < wsa> geertu: both runtime and system +09:20 < geertu> wsa: Shouldn't RPM take care of the actual clocks? +09:20 < geertu> shimoda: That email doesn't mention tx watchdog timeout, is it related? +09:21 < wsa> shimoda: maybe we can ask him how he got this panic? +09:23 < wsa> geertu: the RPM stuff for TMIO is from 2011. So, I don't know if all drivers using the TMIO core have their clocks managed via RPM +09:23 < shimoda> geertu: ravb e6800000.ethernet ethernet: transmit timed out, status 00000000, resetting... is related to tx watchdog timeout +09:25 < geertu> shimoda: thx, missed that. I believe last time I wrote an Ethernet driver, it still included "watchdog" in the error message ;-) +09:25 < shimoda> wsa: you're right. but, renesas internal support team also got this report internaly. But, they doesn't have such information.. +09:25 < geertu> wsa: But renesas_sdhi_clk_{en,di}sable() is not core mmio, so we can do whatever we want in that function +09:26 < geertu> incl. not touching clocks directly +09:26 < wsa> I can check +09:26 < shimoda> anyway, ask how to reproduce is better. +09:26 < shimoda> thanks! +09:27 < wsa> shimoda: let's hope he can provide an answer then +09:27 < wsa> okay, I guess this was it for today? +09:27 < wsa> last call +09:28 < wsa> so, thank you for the meeting today! +09:28 < wsa> and have a nice continued day diff --git a/wiki/Chat_log/20200611-core-chatlog b/wiki/Chat_log/20200611-core-chatlog new file mode 100644 index 0000000..5d62837 --- /dev/null +++ b/wiki/Chat_log/20200611-core-chatlog @@ -0,0 +1,102 @@ +09:28 < geertu> Welcome to today's Core Group Chat Meeting! +09:28 < geertu> Agenda: +09:28 < geertu> 1. Status Updates +09:28 < geertu> 2. Discussion Topics +09:28 < geertu> Topic 1. Status updates +09:28 < geertu> A) What have we done since last time: +09:28 < geertu> Marek converted the U-Boot PCNET and EEPRO100 drivers to DM, added CI +09:28 < geertu> tests for them, and synced the U-Boot Gen2 MSTP tables. +09:28 < geertu> Morimoto-san worked on Renesas inside Paper Work, and updated his local +09:28 < geertu> machine. +09:28 < geertu> Shimoda-san submitted DT binding doc conversions ({rcar,usb}-dmac, +09:28 < geertu> ipmmu) and fixes for IOMMU device node names. +09:28 < geertu> Geert did more DT binding doc conversions (bsc, em,gio, rza1-irqc, cpg), +09:28 < geertu> leading to more DTS and dt-schema fixes, reviewed lots of RZ/G1H +09:28 < geertu> patches, and started looking into implementing QEMU gpiodev support as +09:28 < geertu> an interface. +09:29 < geertu> B) What we plan to do till next time: +09:29 < geertu> Marek plans to convert the U-Boot dc2114x driver to DM and add CI tests +09:29 < geertu> for it, and prepare for the 2020.07 release. +09:29 < geertu> Shimoda-san plans to convert the iommu doc to json-schema, and add +09:29 < geertu> r8a77961 support. +09:29 < geertu> Geert plans to refactor the GPIO Aggregator parsing, do more DT binding +09:29 < geertu> doc conversions, and will continue QEMU GPIO virtualization. +09:29 < geertu> C) Problems we have currently: +09:29 < geertu> Geert is struggling with describing multi-level sh-pfc subnodes in +09:29 < geertu> json-schema. +09:30 < geertu> ---EOL--- +09:30 < geertu> Anything I missed? +09:31 < geertu> Topic 2. Discussion Topics +09:31 < geertu> Please shoot your topics +09:32 < kbingham> pm_runtime_put_idle() +09:32 * kbingham ducks. +09:32 < geertu> kbingham: I'm waiting for Rafael to chime in ;-) +09:32 < kbingham> that topic is horrrrrrible. +09:33 < wsa> what's the context? +09:33 < kbingham> They're basically saying "Sure - thaat would be the right way to do it ... but I don't want to fix everything" +09:33 < wsa> I know it from SDHI :/ +09:34 < geertu> wsa: The question is: what is the right pm_runtime_*() call to make when pm_runtime_get_sync() failed +09:34 < Marex> kbingham: did I miss something ? there was a patch for PCI too +09:34 < geertu> I've seen pm_runtime_put(), pm_runtime_put_idle(), pm_runtime_idle(), pm_runtime_put_noidle(), ... +09:35 < kbingham> when pm_runtime_get_sync() fails, it doesn't leave the system in the same state as when the function was entered. i.e. it takes a refcount unconiditionally. +09:35 < kbingham> how to clean up if it fails is a ... seemingly horrible mess. +09:35 < wsa> and why does it increment the refcnt? +09:35 < kbingham> And no one wants to fix the function to clean itself up - becasue tehre are also lots of code paths which rely on the get_sync() incrementing, because they later decrement. +09:36 < kbingham> Which is ... stupid ... +09:36 < kbingham> because if the get_sync() fails, then surely you cant rely on the code between the get and the put to work anyway! +09:37 < wsa> yes, without knowing details, it seems right to me to fix the function itself +09:37 < wsa> even if it is a lot of work +09:37 < kbingham> I'm scared to reply to the thread fearing what I'd get dragged into - but I'm surprised that no one else has said "Ugh ... that's wrong?" +09:38 < wsa> maybe everone is scared? +09:38 < wsa> i have patches for this in my I2C inbox but I was really wondering about them +09:38 < wsa> it just feels wrong +09:38 < geertu> wsa: http://lore.kernel.org/r/5127441.yGvM1JjtLk@kreacher +09:38 < wsa> but I wanted to tackle it after I completed the merge window +09:39 < kbingham> I'm going to have to add linux-pm to my lists aren't I :S +09:39 < kbingham> at least it's easy to pull in with nntp support on lore. +09:40 < geertu> pinchartl: So you think we should always handle pm_runtime_get_sync() failures? +09:40 < shimoda> oops, about pm_runtime_get_sync(), i also got such a patch for rcar-pci, and i had submitted my R-b... Should I recall? +09:40 * geertu admits not having looked in all its failure modes +09:41 < kbingham> shimoda, techincally the patch is probably 'right' currently ... it's just the wrong way to do the real fixes. +09:41 < geertu> shimoda: The bad thing is that these patches are sent out by copycats who don't know what they're changing. +09:41 < kbingham> yup... looks like a big batch conversion finding matches with cocci +09:41 < kbingham> which implies that the 'lot of work to fix the other paths' is ... just the same route - and thus entirely feasible ;-) +09:42 < wsa> well, we could use coccinelle the same way to convert most of the drivers relying on the refcnt being increased +09:42 < kbingham> precisely ;-) +09:42 < wsa> I wonder if there is a reason why incrementing the refcnt makes sense +09:43 < wsa> I will start another thread right away and ask Rafael; I will CC renesas-soc +09:43 < kbingham> oops hit the wrong option, and now downloading 136475 headers from linux-pm :-( +09:43 < wsa> yay, another item for my B) list +09:44 < kbingham> Ok - so I think that finalises my discussion point ... +09:44 < kbingham> Anything else? +09:46 < wsa> next meeting? +09:47 < geertu> Thursday, July 9? +09:47 < wsa> I am very likely on holiday then, and the week after +09:48 < wsa> July, 2nd? +09:49 < shimoda> July, 2nd is OK to me +09:49 < geertu> That's during ELC-NA ;-) +09:49 < wsa> i see +09:49 < geertu> However, I can handle +09:50 < geertu> As everything is virtual these days +09:50 < morimoto> geertu: Do you join ELC-NA ? +09:50 < geertu> morimoto: Yes I will +09:50 < morimoto> Is it by-F2F or by-net ? +09:50 < geertu> Pay 750 USD less, and avoid ESTA/TSA, so why not? ;-) +09:50 < geertu> morimoto: by-net, 50 USD only +09:51 < pinchartl> geertu: I'm not sure we shoudl always handle them +09:51 < morimoto> OK, nice to know :) +09:51 < pinchartl> it was a real question, I don't know if there could be valid cases where the call fails +09:51 < Marex> morimoto: you can always hang around this irc and socialize with everyone , for $0 +09:51 < wsa> I won't have internet during my holidays, so I'd like some wrap-up before I leave +09:52 < morimoto> Marex: hehe $0 is nice :) +09:52 < morimoto> Marex: without T-shot :( +09:53 < wsa> so, if it does not collide too much with ELC, I'd like the July, 2nd +09:53 < morimoto> s/T-shot/T-shirt +09:53 < geertu> wsa: Are you allowed to move to no-Internet zones with covid-19 still around? +09:54 < morimoto> July 2nd is OK for me, too +09:54 * geertu thought t-shot was right, in a comment for Marex ;-) +09:56 < wsa> geertu: we go canoeing, so we won't see much people (hopefully!) :) +09:57 < geertu> Any other topics? +09:58 < geertu> July 2nd it will be? +09:59 < Marex> sounds good +09:59 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20200611-io-chatlog b/wiki/Chat_log/20200611-io-chatlog new file mode 100644 index 0000000..18a5def --- /dev/null +++ b/wiki/Chat_log/20200611-io-chatlog @@ -0,0 +1,94 @@ +09:03 < wsa> welcome to the IO meeting +09:03 < wsa> collected status updates +09:03 < wsa> Status updates +09:03 < wsa> ============== +09:03 < wsa> A - what have I done since last time +09:03 < wsa> ------------------------------------ +09:03 < wsa> Geert +09:03 < wsa> : DT binding doc conversion to json-schema for em,uart, em,sti, mtu2, and tmu (updated), rtc-sh (updated), SDHI Runtime PM testing/investigation, fixed (worked around) RAVB regression due to Micrel PHY using internal delays now, RSPI/QSPI bit rate improvements +09:03 < wsa> Niklas +09:03 < wsa> : did clean ups for both thermal drivers +09:03 < wsa> Shimoda-san +09:03 < wsa> : Checked a BSP team's report about an SDHI DMA map/unmap unbalance and sent a fix, checked a RAVB driver patch from Bosch and submitted a patch, upported a thermal patch from BSP, reviewed SDHI driver's patches from Wolfram +09:03 < wsa> Ulrich +09:03 < wsa> : sent atomic transfers implementation for i2c-sh_mobile +09:03 < wsa> Wolfram +09:03 < wsa> : reviewed and tested RPM and clk_imbalance updates for SDHI, removed manual clock handling from renesas_sdhi_core, reworked and sent out series 'fix stalled SCC' and 'implement manual, calibration' for SDHI, sent out cleanup patches for I2C core, and I2C slave eeprom, review patches for IIC, I2C core, and r8a7742 +09:03 < wsa> B - what I want to do until next time +09:03 < wsa> ------------------------------------- +09:03 < wsa> Geert +09:03 < wsa> : wants to implement explicit internal delay setting from DT for RAVB, DT binding doc conversion to json-schema +09:03 < wsa> Shimoda-san +09:03 < wsa> : wants to continue investigating how to avoid mmc suspend/resume issue, ping Cogent about RAVB driver patch, convert usb-xhci, rcar-pci and sdhi dt docs to json-schema +09:03 < wsa> Ulrich +09:03 < wsa> : wants to implement atomic transfers implementation for i2c-rcar +09:03 < wsa> Wolfram +09:03 < wsa> : wants to resend series 'fix stalled SCC' and 'implement manual calibration' for SDHI, remove final bits of i2c_new_device API, new version of the series about blocked I2C devices in DT, review Ulrich's atomic_xfer patches for IIC +09:03 < wsa> C - problems I currently have +09:03 < wsa> ----------------------------- +09:03 < wsa> Shimoda-san +09:03 < wsa> : wonders if any driver should not call cma_alloc() in system resume state? +09:04 < wsa> uli__, geertu: the 'never-disable' series for WDT clocks is still under review? +09:05 < geertu> wsa: My suggestion from last meeting was to mark the RWDT clock with CLK_IS_CRITICAL if it's already enabled. +09:05 < wsa> uli__: and I am looking forward to test the atomic_xfer patch :) +09:05 < wsa> geertu: ah, right, I remember +09:06 < wsa> I think uli__ agreed? +09:06 < uli__> i think i did. +09:06 < uli__> didn't make it to my todo list for some reason... +09:06 < wsa> uli__: can you work on that before atomic_xfer for i2c-rcar? +09:07 < uli__> sure +09:07 < wsa> great, thanks +09:07 < wsa> so, there is also the cma_alloc question from shimoda-san +09:08 < wsa> shimoda: i am not much into the RAVB driver, it frees the CMA memory when the system suspends? +09:09 < shimoda> shimoda: yes if user will not use wake-on-LAN +09:09 < wsa> i'd think you don't need to free CMA memory until shutdown, but maybe I am naive here... +09:09 < wsa> how much is it BTW? +09:09 < geertu> I'm thinking the same +09:10 < geertu> shimoda: BTW, who from Cogent are you expecting feedback from? +09:10 < wsa> sergei +09:10 < wsa> probably +09:10 < Marex> wsa: no longer with cogent, no ? +09:10 < geertu> Cogent is under restructuring, and (at last) Sergei has been laid off. +09:10 < wsa> really? +09:10 < wsa> wowo +09:10 < Marex> sadly seems that way +09:10 < geertu> FWIW, Sergei always worked on ravb/sh_eth in his spare time +09:11 < shimoda> ah, this cma thing is for BSP and our customer (bosch). because critical issue happen on BSP only +09:11 < geertu> s/at last/at least/ +09:11 < wsa> shimoda: so, this issue is not present upstream? +09:11 < shimoda> about other patch (fix race condition on ravb driver), I expect Sergei reviews my patch. +09:12 < wsa> phew, let's see if sergei still wants to donate time for the ethernet drivers +09:12 < geertu> wsa: Probablt the issue was upstream, but fixed in the mean time. BSP is at v5.4 now, old BSp was v4.14. +09:12 < shimoda> wsa: you're correct. because the DMA API calls other alloc function if cma_alloc() failed +09:13 < shimoda> geertu: oops, I didn't know that. +09:14 < wsa> well, as long as sergei is still listed as maintainer +09:15 < wsa> shimoda: so, do you still need input on the cma issue? +09:15 < wsa> are there other questions/issues? +09:16 < geertu> wsa: Do you have plans to convert the i2c bindings to json-schema? +09:17 < wsa> nope +09:17 < wsa> too much other stuff to do +09:17 < wsa> is it high priority? +09:18 < shimoda> I don't have any question/issues for now. i wanted to feedback if some one knew +09:18 < shimoda> wsa: ^ +09:18 * geertu just notices dt-schema/yaml-bindings/schemas/i2c/i2c-controller.yaml +09:19 < wsa> i am not an expert with CMA (maybe the MM guys can add) but as I said I wonder why you won't keep the memory until shutdown +09:19 * kbingham needs an i2c-mux schema too :-S +09:19 < wsa> geertu: i think rob was working on tha +09:19 < wsa> that +09:20 < geertu> wsa: I was mainly waiting for the i2c maintainer to write the core i2c controller schema iunder Documentation/devicetree/bindings/i2c/, but apparently that exists in dt-schema already +09:20 < shimoda> wsa: i don't know why. But, there is good point to fix the issue I think. Thank you for your feedback! +09:21 < wsa> noob question: where is dt-schema/yaml-bindings/schemas/i2c/i2c-controller.yaml +09:21 < wsa> ? +09:21 < geertu> https://github.com/devicetree-org/dt-schema.git +09:22 < geertu> For e.g. SPI, spi-controller.yaml is in Documentation/devicetree/bindings/spi/, not in dt-schema +09:22 < wsa> github? well, ok... +09:23 < wsa> so, this is the OS independent DT bindings repo? +09:23 < wsa> and linux should pull it in? +09:23 < kbingham> I don't think linux pulls it in - the dt-validator uses it ? +09:23 < wsa> no, it's the tool +09:23 < geertu> You need the dt-schema repo to run make dt_bindings_check and/or dtbs_check +09:24 < wsa> anyhow, I recall Rob saying he had an issue to tackle for a proper i2c-controller.yaml +09:25 < wsa> ok, i think this was it? +09:26 < wsa> then, let's move to the core issues :) +09:26 < wsa> geertu: enjoy! +09:26 < wsa> thanks for this meeting and your work, everyone! diff --git a/wiki/Chat_log/20200702-core-chatlog b/wiki/Chat_log/20200702-core-chatlog new file mode 100644 index 0000000..ede979a --- /dev/null +++ b/wiki/Chat_log/20200702-core-chatlog @@ -0,0 +1,107 @@ +09:41 < geertu> Welcome to today's Core Group Chat Meeting! +09:41 < geertu> Agenda: +09:41 < geertu> 1. Status Updates +09:41 < geertu> 2. Discussion Topics +09:41 < geertu> Topic 1. Status updates +09:41 < geertu> A) What have we done since last time: +09:41 < geertu> Marked updated the U-Boot dc2114x driver in preparation for DM +09:41 < geertu> conversion, and researched BootROM/IPL A/B copy switching for +09:41 < geertu> reboot-into-recovery-ATF. +09:41 < geertu> Niklas udated his Gen3 boards with upstream firmware. +09:41 < geertu> Shimoda-san submitted patches to set the usb-dmac tx_result +09:41 < geertu> parameters, and add R-Car M3-W+ IPMMU support. +09:41 < geertu> Ulricht sent v3 of the RWDT critical clock series. +09:41 < geertu> Geert did more DT binding doc conversions (rza2-pinctrl), refactored +09:41 < geertu> GPIO Aggregator parsing to use bitmap_parselist(), investigated s2ram +09:41 < geertu> wake-up regression in v5.8-rc1, reviewed RZ/G2 patches, attended ELC-NA, +09:41 < geertu> and researched QEMU gpiodev support. +09:42 < geertu> B) What we plan to do till next time: +09:42 < geertu> Marek plans to continue working on IPL A/B copy switching. +09:42 < geertu> Shimoda-san plans to convert the usb2-clock doc to json-schema. +09:42 < geertu> Geert plans to do more DT binding doc conversions, and continue QEMU +09:42 < geertu> GPIO virtualization. +09:42 < geertu> C) Problems we have currently: +09:42 < geertu> Geert is struggling with describing multi-level sh-pfc subnodes in +09:42 < geertu> json-schema, and untangling the QEMU OO framework. +09:42 < geertu> ---E--- +09:42 < geertu> Anything I missed? +09:42 < kbingham> geertu, DTB location issues ? +09:43 < wsa> what is QEMU OO? +09:43 < wsa> object oriented +09:43 < wsa> ? +09:43 < geertu> yep +09:43 < geertu> kbingham: 0x50000000/0x58000000 works for me +09:43 < geertu> i.e.: +09:43 < geertu> tftpboot 0x50000000 h3-salvator-xs/Image +09:43 < kbingham> geertu, Did you work out /why/ the DTB location is no longer valid? or just find new addresses that work. +09:43 < geertu> tftpboot 0x58000000 h3-salvator-xs/r8a77951-salvator-xs.dtb +09:43 < geertu> booti 0x50000000 - 0x58000000 +09:44 < kbingham> I have a new address that works currently (though not the same as those ones) +09:44 < geertu> kbingham: Haven't looked into the U-Boot sources +09:44 < geertu> I had hoped The Expert(MV^WTM) would chime in +09:44 < wsa> according to neg, 0x50000000 and 0x58000000 is approved by Marek, right? +09:44 < geertu> Niklas confirmed the DTB overwrite happens with latest U-Boot, too +09:44 < kbingham> Ok, I think I've seen in a few bootlogs, that the 'failing' address was quite commonly shared, so it's likely everyone was using the same location. +09:45 < kbingham> So can we take these new addresses as the new 'official' locations? +09:45 < geertu> kbingham: Yeah, I documented that address on the elinux wiki, so everyone uses it ;-) +09:45 < kbingham> geertu, Aha thanks, Sorry I haven't seen the elinux update. +09:45 < wsa> geertu: thanks! I was about to suggest a wiki page :) +09:46 < wsa> shimoda: I have a question about sharing new binary firmware... +09:46 < geertu> Still, would be interesting to know why the DTB is overwritten. Might be an off-by-something factor bug in the copy parameters +09:46 < wsa> you said that you are not allowed to send the binaries but we should build them ourselves with yocto +09:46 < geertu> kbingham: Haven't updated the wiki for the new addresses yetr +09:46 < Marex> geertu: isnt the kernel using the 2 MiB below it for something ? +09:46 < kbingham> geertu, Yes, and still very odd that it started happening due to some difference in the kernel update... +09:46 < Marex> geertu: stack for decompressor maybe ? +09:47 < kbingham> geertu, OH ... I see... sorry - the OLD address is documented at the wiki ;-) +09:47 < geertu> Marex: arm64 doesn't decompress, AFAIK +09:47 < wsa> shimoda: can we put the "ourselves built" firmware into some internal repository? do we still have osdg? +09:48 < shimoda> wsa: yes. this is my side problem. pre-built binaries are stored renesas internal storage server. But, since i'm working from home, I could not access the server. +09:49 < wsa> shimoda: ah, so it is a technical problem and not a legal problem? +09:49 < shimoda> wsa: we can use osdg server until end of this year... +09:49 < shimoda> wsa: yes, it's technical problem. +09:49 < wsa> geertu: the init section exploded with 5.8-rc1, around 1.5 meg larger +09:50 < wsa> shimoda: ok, this makes it a bit easier then :) +09:50 < morimoto> shimoda: do you mean Redmine ? +09:51 < shimoda> morimoto: both osdr Redmine and osdg Gitlab (will be closed) +09:51 < wsa> so, we need to move the periject repo +09:51 < morimoto> shimoda: if so, Redmine part is now under git +09:52 < shimoda> morimoto: yes, under git of osdg :) +09:52 < shimoda> so, we need to move the osdg to somewhere +09:52 < morimoto> I don't remember, I created private project under Github ? +09:52 < morimoto> OK, thanks +09:53 < Marex> geertu: then maybe its the bss section as wsa mentioned ? or stack ... +09:54 < geertu> Marex: does "booti" have subcommands like "bootm"? The former doesn't seem to be documented in the U-Boot documentation on denx.de +09:54 < Marex> geertu: subcommands for what ? +09:54 < wsa> shimoda, morimoto: do you work from home all the time now? +09:54 < geertu> Marex: booti subcommands +09:55 < geertu> Marex: You have bootm start / loados / ... +09:55 < morimoto> wsa: yes +09:55 < Marex> geertu: iirc booti calls the same code as bootm, except for a bit of aarch64 setup, so that should work +09:55 < geertu> Marex: Have you read my email with my overwriting findings ("[periperi] ERROR: Did not find a cmdline Flattened Device Tree")? +09:56 < shimoda> wsa: yes. also, renesas employees can choose office or home from this Aug. +09:56 < geertu> ok, will investigate again +09:56 < geertu> to find out in which part it is overwritten +09:56 < wsa> shimoda: ah, from August +09:57 < morimoto> wsa: because of that, I need to work by small windows note PC... +09:57 < Marex> geertu: OK +09:57 < geertu> Marex: Note that an arm64 Image does not include bss +09:57 < wsa> morimoto: windows?? +09:57 < geertu> The error is from U-Boot, i.e. before it attempts to start the kernel +09:57 < morimoto> wsa: yes, modern windows10 :) +09:58 < wsa> I heard git and windows is a troublesome combination +09:58 < damm> i've been asked to use microsoft teams too +09:58 < damm> for conferencing purpose +09:58 < damm> very exciting +09:59 < morimoto> wsa: I'm using WSL(= windows subsystem Linux) and/or SSH to Renesas machine +09:59 < wsa> damm: i had to install this here, too. For remote schooling the kids +09:59 < neg> morimoto: small windows, small problems? +09:59 < wsa> the linux client worked surprisingly well +09:59 < shimoda> wsa: same here (use windows 10). but i also use a server which installed Linux at the office via ssh. +09:59 < morimoto> neg: small windows, big problems which I can't kill :) +09:59 < wsa> poor JapaPERI! +10:00 < geertu> wsa: Yep, Teams and Office 365 in the browser for school +10:00 < wsa> they turned to jitsi later +10:00 < geertu> Anything else to discuss? +10:00 < morimoto> wsa: yes we are (ToT) +10:01 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20200702-io-chatlog b/wiki/Chat_log/20200702-io-chatlog new file mode 100644 index 0000000..8f7beaf --- /dev/null +++ b/wiki/Chat_log/20200702-io-chatlog @@ -0,0 +1,123 @@ +09:03 < wsa> welcome everyone to todays meeting +09:03 < wsa> here are the collected status updates +09:03 < wsa> Status updates +09:03 < wsa> ============== +09:03 < wsa> A - what have I done since last time +09:03 < wsa> ------------------------------------ +09:03 < wsa> Geert +09:03 < wsa> : implemented explicit internal delay setting from DT for ravb, DT binding doc conversion to json-schema: ravb +09:03 < wsa> Shimoda-san +09:03 < wsa> : converted XHCI binding docs to YAML, fixed undefined temperature if negative for Thermal, and sent various series to fix mmc_suspend() with PSCI +09:03 < wsa> Ulrich +09:03 < wsa> : sent new series to handle WDT handover from bootloader which got merged, sent new series implementing atomic transfers for IIC +09:03 < wsa> Wolfram +09:03 < wsa> : removed final bits of i2c_new_device API and removed the old API so API conversion is now finished, reviewed slave implementation for SMBusHostNotify, and added the support for i2c-rcar, fixed various corner cases in the slave implemetation of i2c-rcar, wrote a new slave-backend to test rare I2C/SMBus features which usually need specific devices, tried to get an answer to the RPM +09:03 < wsa> refcounting issue, reviewed Uli's atomic transfer patch for IIC, minor treewide cleanup patches sent out while working on all of the above +09:03 < wsa> B - what I want to do until next time +09:03 < wsa> ------------------------------------- +09:03 < wsa> Geert +09:03 < wsa> : wants to implement generic bindings for Ethernet MAC explicit internal delay setting +09:03 < wsa> Niklas +09:03 < wsa> : wants to eet up with Wolfram and flash Gen3 boards, and do the yearly test with SDIO-WIFI on Koelsch +09:03 < wsa> Shimoda-san +09:03 < wsa> : wants to keep working on mmc_suspend() with PSCI, discuss with Cogent about RAVB driver patch, convert usb-xhci, rcar-pci and sdhi DT docs to json-schema +09:03 < wsa> Ulrich +09:03 < wsa> : wants to sent new series implementing atomic transfers for IIC and I2C +09:03 < wsa> Wolfram +09:03 < wsa> : wants to meet with Niklas and fix Gen3 boards together, have two weeks of holidays, add SMBusAlert and I2C_M_RECV_LEN to both, the slave-testunit and the i2c-rcar driver, resend series 'fix stalled SCC' and 'implement manual calibration' for SDHI, review Shimoda-san's DMA unmapping series for SDHI +09:03 < wsa> C - problems I currently have +09:03 < wsa> ----------------------------- +09:03 < wsa> Shimoda-san +09:03 < wsa> : wonders whether the mmc_suspend() improvement is really needed because we cannot avoid accidentally power off of eMMC around system suspend anyway +09:03 < wsa> Wolfram +09:03 < wsa> : asks how to ensure that atomic xfers on IIC have their clock enabled that late, and couldn't use Gen3 boards for a while so he had to switch to work which could be tested on Gen2 +09:04 < wsa> shimoda: I assume with the RAVB patch you mentioned is about the "stop queues on timeout" issue? +09:05 < wsa> geertu: you mentioned that you'd apply Uli's RWDT clock patches but I don't see them in -next yet +09:05 < shimoda> wsa: yes +09:05 < geertu> wsa: They're in clk-renesas. Haven't sent a pull request to mturquette yet +09:06 < wsa> geertu: ah, they don't go directly into next from your branch? +09:06 * geertu doublechecks +09:06 < geertu> wsa: No they don't. Same with sh-pfc. +09:06 < wsa> shimoda: ok, thanks. will update that information +09:06 < shimoda> wsa: thanks! +09:07 < wsa> about the RPM get_sync ref-counting issue: +09:07 < geertu> shimoda: I assume s/Cogent/Sergei/? +09:07 < shimoda> geertu: yes +09:08 < wsa> I confirmed that always increasing the ref-count is intended behaviour. I have not confirmed yet, that it may be a better fix to simply remove the error checking instead of adding a put_noidle everywhere +09:08 < wsa> but from the last discussion, I thought for R-Car this is true? +09:09 < geertu> wsa: Yes, Rafael confirmed not checking is fine for us +09:09 < wsa> ok, nice to know +09:10 < wsa> so, i will ask people sending in such patches if they checked that removing the check may be the better solution +09:10 < geertu> https://lore.kernel.org/r/CAJZ5v0i87NGcy9+kxubScdPDyByr8ypQWcGgBFn+V-wDd69BHQ@mail.gmail.com +09:11 < geertu> "It is the right thing to do in the majority of cases." +09:11 < geertu> Now, there's still the bunch of "fixers" that will try to add error paths (and pm_runtime_put_*() calls) everywhere +09:12 < wsa> maybe we should add another function annotation: __must_not_check ;) +09:13 < wsa> at least, I now have a proper answer for them +09:13 < geertu> ;-) +09:14 < wsa> so, I have another topic but wanted to ask you guys first if there are questions regarding the status updates or in general? +09:14 < neg> wsa: is not __must_not_check equal to returning void :-) +09:15 < wsa> shimoda: I will seriously try to review the DMA unbalance patches before my holidays +09:15 < geertu> wsa: For atomic transfers, it's not just the clock, but also the power domain +09:15 < wsa> neg: you got it! +09:16 < wsa> geertu: yes, this was my remaining question +09:17 < shimoda> wsa: thanks! +09:17 < geertu> It seems some modules on R-Car Gen2 are "forgiving" when accessing them with the module clock disabled (i2c, rwdt) +09:17 < wsa> atomic_xfer happen very late, so clocks and power domains may be off already. and we can't use the calls to enable them anymore, right? +09:17 < geertu> Yes, pm_runtime_get_sync() may sleep +09:18 < geertu> We might set GENPD_FLAG_IRQ_SAFE for our domains +09:19 < wsa> but on what condition? +09:19 * kbingham discovers http://sweng.the-davies.net/Home/rustys-api-design-manifesto :-) +09:19 < geertu> kbingham: Yeah, pm_runtime_get_sync() is at -1 ;-) +09:19 < kbingham> geertu, That's the thread I found it from ;-) +09:20 < pinchartl> did Rafael provide any answer regarding whether pm_runtime_get_sync() should be fixed ? +09:20 < wsa> I thought it was -4 +09:20 < geertu> there's also dev.power.irq_safe +09:21 < wsa> sometimes -7 :> +09:21 < geertu> pinchartl: Not to us. But according to the commit message for the initial clock fix, he doesn't intend to fix it. +09:22 < wsa> pinchartl: AFAIU it was expected to be the common case to NOT check the retval +09:22 < geertu> Correction: it's not in the commit message +09:22 < pinchartl> I don't see why we should fix it in drivers if he can't be bothered to fix it in runtime PM +09:22 < wsa> and it was intended that simple get/put-pairs without error checking simply should work +09:23 < geertu> https://lore.kernel.org/linux-pm/CAJZ5v0j+bsHaQcxK41yph8eRpMZ3DoerqA7uwS2B8De41Jwi7Q@mail.gmail.com/ +09:23 < geertu> "I'd rather update the buggy callers than the ones that are OK. +09:23 < geertu> " +09:23 < geertu> But of course the "fixers" take (only) care of the latter +09:23 < pinchartl> wsa: amazing API design... +09:23 < wsa> pinchartl: ack +09:24 < pinchartl> ok, so I'll reject all patches that add error checks, easy +09:24 < wsa> my impression was that Rafael kind of regrets it today, but looks like "too late" +09:24 < geertu> it starts with a function that cannot fail. +09:24 < geertu> Then someone thinks it should not return void, but return an errorn code. +09:24 < geertu> Then all callers "must" be fixed +09:25 < geertu> wsa: indeed +09:25 < geertu> So the safe way is to always return an error code. At the expense of people checking for an error that cannot happen. +09:26 < geertu> The real bad thing here is that pm_runtime_get_sync() doesn't undo the refcounting on "failure" +09:26 < wsa> yep +09:27 < wsa> that is so counter-intuitive +09:28 < kbingham> I'm sure it could be fixed with some coccinelle and an intern ;-) +09:28 < wsa> I doubt coccinelle can find the few cases where an error code is useful +09:29 < wsa> geertu: about the atomic transfer issue +09:29 < wsa> does it mean PMIC drivers need to set the irq_safe flag? +09:30 < geertu> That flag would be for the PM domain +09:31 < geertu> oh, you mean dev.power.irq_safe +09:31 < wsa> whatever works, actually. but it should be the PMIC driver requesting the change, or? +09:31 < wsa> to save the DT description +09:32 < geertu> dev.power.irq_safe means "it is safe to run the ->runtime_suspend(), ->runtime_resume() +09:32 < geertu> and ->runtime_idle() callbacks for the given device in atomic context with +09:32 < geertu> interrupts disabled" +09:32 < geertu> but the doc for the flag says: +09:33 < geertu> "indicates that the callbacks will be invoked with the spinlock held and interrupts disabled", which is something different +09:33 < geertu> "is safe if" vs. "will" +09:34 < geertu> So if we mark all underlying infrastructure (PM Domain, i2c driver, pmic driver) irq_safe, we still have the might_sleep() call in pm_runtime_get_sync() +09:35 < geertu> My gut feeling says the only safe way to support this, is for the PMIC driver (which knows it's can be used to restart the system), to tell the i2c core that the i2c driver must stay awake for that. +09:35 < geertu> s/it's/it/ +09:36 < wsa> can't we the PMIC driver just disable RPM for itself? +09:36 < wsa> and then this should propagate to all parents? +09:36 < geertu> That might work actually. +09:36 < geertu> Alternaively, is there something like an early restart notifier? +09:37 < geertu> Then the PMIC could wake up the i2c driver in that notifier, which would avoid the need for keeping the i2c driver awake all the time +09:38 < wsa> uli_: can you check these two options? +09:39 < wsa> other than that, last call for questions / comments +09:40 < uli_> i will check it out +09:40 < wsa> uli_: thanks! +09:40 < wsa> then I guess we can switch to the core meeting diff --git a/wiki/Chat_log/20200806-core-chatlog b/wiki/Chat_log/20200806-core-chatlog new file mode 100644 index 0000000..28e4d93 --- /dev/null +++ b/wiki/Chat_log/20200806-core-chatlog @@ -0,0 +1,147 @@ +09:34 < marex> morimoto: shimoda: hi, I was curious, is there some extra documentation for the bootrom ? esp. the IPL A/B switching mechanism ? I recall the security LCS stuff in TFA implements some calls into bootrom, so maybe there is some list of bootrom functions you can call from your own system software ? is there some internal renesas documentation for that ? +09:35 < marex> I mean, there must be some way to push the bootrom to boot the IPL Bcopy, right ? +09:35 < geertu> marex: Sounds like Core? +09:35 < wsa> then, let's switch over to core. Zebax adapters fit there, too, if we want to keep the topic ;) +09:35 < wsa> geertu: have fun! +09:36 < geertu> wsa: Na, Samtec is I/O ;-) +09:36 < geertu> Welcome to today's Core Group Chat Meeting! +09:36 < geertu> +09:36 < geertu> Agenda: +09:36 < geertu> 1. Status Updates +09:36 < geertu> 2. Discussion Topics +09:37 < geertu> Topic 1. Status updates +09:37 < geertu> A) What have we done since last time: +09:37 < geertu> Marek worked on U-Boot (late driver teardown and SH4 fixes). +09:37 < geertu> Morimoto-san is considering a remote-access-system for COVID-19. +09:37 < geertu> Ulricht figured out i2c/wdt ordering for system restart. +09:37 < geertu> Geert attended ELC-NA, Reviewed RZ/G2 patches, investigated QEMU GPIO +09:37 < geertu> virtualization review suggestions, sent pull requests for v5.9, and +09:37 < geertu> enjoyed Summer Holidays. +09:37 < geertu> B) What we plan to do till next time: +09:37 < geertu> Marek plans to upstream CI test hooks for SH4 QEMU. +09:37 < geertu> Shimoda-san plans to convert the usb2-clock doc to json-schema, and +09:37 < geertu> start R-Car V3U initial support. +09:37 < geertu> Ulrich plans to follow-up i2c-sh_mobile atomic transfer work, and +09:37 < geertu> implement the same for i2c-rcar. +09:37 < geertu> Geert plans to do more DT binding doc conversions, and continue QEMU +09:37 < geertu> GPIO virtualization. +09:37 < geertu> (oops, looks like I included some I/O work) +09:38 < geertu> C) Problems we have currently: +09:38 < geertu> Geert is struggling with describing multi-level sh-pfc subnodes in +09:38 < geertu> json-schema, and discovered the QEMU GPIO virtualization review +09:38 < geertu> suggestions turned out to be unfeasible. +09:39 < geertu> ----EOT--- +09:39 < geertu> Anything I missed? +09:39 < geertu> morimoto: I'm looking forward to anything easing remote control of boards. +09:39 < morimoto> Yes, same here +09:39 < morimoto> but it is under discussion +09:39 < morimoto> now. no guarantee yet +09:40 < morimoto> marex: I have no idea. shimoda: do you know that ? +09:40 < geertu> You're aware Salvator-XS and Ebisu already provide all required signals for power/reset control on EXIO-D? +09:40 < morimoto> geertu: thank you for your help about v5.x booting +09:40 < geertu> Cfr. https://elinux.org/R-Car/Boards/Salvator-XS#Remote_Control +09:41 < geertu> You still need something to control main power, and provide the signals, so perhaps that's what "GPIO power/reset control" will be about on future boards? +09:41 < geertu> morimoto: You're welcome. The ability to boot boards is critical ;-) +09:42 < geertu> Topic 2. Discussion Topics +09:43 < geertu> A) IPL A/B switching +09:43 < geertu> marex: ^ ;-) +09:43 < marex> geertu: maybe if you could easily test your IPL before doing actual update, and with the ability to fall back to known working version by plain reboot ... +09:43 < marex> geertu: ... then people would finally ditch their old IPL and old U-Boot :-) +09:44 < geertu> marex: If only it supported H3 ES1.x... +09:44 < marex> geertu: and that easy test might be for example by being able to easily boot a B-copy of IPL ... +09:44 < shimoda> marex: As I wrote an email, IPL A/B feature is in secure boot +09:44 < shimoda> so, I don't think we can use IPL A/B in normal boot +09:44 < morimoto> geertu: we are considering for next new M4 board +09:44 < geertu> morimoto: BTW, what's M4? +09:44 < geertu> A, R-Car M4-something? +09:45 < marex> shimoda: isn't there some function call you can do to the bootrom, which would tell it to load the initial SA0 certificate from different location for example ? +09:45 < wsa> GeM4 +09:45 < wsa> ? +09:45 < marex> shimoda: or , patch the existing SA0 certificate in OCRAM at 0xe6300400 with the B-copy flag and then make bootrom start loading from that, without reloading the certificate ? +09:46 < morimoto> geertu: R-Car Gen4 M4-x board. +09:46 < marex> shimoda: there is https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/renesas/rcar/rom/rom_api.c +09:46 < geertu> morimoto: Cool! +09:46 < marex> shimoda: and that is some function call API to the bootrom itself +09:47 < marex> shimoda: so there clearly are some functions exported from the bootrom, and I wonder if maybe, there is a function which allows me to do the above :-) +09:47 < geertu> marex: Oh, that code does support H3 ES1.x +09:47 < marex> shimoda: in fact, is there a documentation which describes those bootrom functions ? +09:47 < wsa> morimoto: Cool, in deed! First time I hear about Gen4 becoming real +09:47 < marex> geertu: upstream ATF doesnt support H3 ES1.x, nor does upstream U-Boot +09:50 < morimoto> wsa: geertu: morimoto is the man who can fulfill your dreams +09:50 < marex> morimoto: do you still plan to run ATF-UBoot-Linux on that ? +09:51 < neg> marex: haha :-) +09:51 < neg> s/marex/morimoto/ about the fulfillment of dreams +09:52 < shimoda> marex: sorry, I don't understand what should i do about IPL A/B +09:52 < morimoto> neg: :) +09:52 < marex> shimoda: so, look at that rom_api.c code first +09:52 < wsa> morimoto: but it means a lot of paperwork for you again... :/ +09:52 < marex> shimoda: it seems that this allows ATF to call bootrom functions +09:52 < morimoto> marex: maybe, but not sure detail +09:52 < marex> shimoda: hence, there is likely a list of all such callable bootrom functions somewhere in renesas +09:53 < morimoto> wsa: yes :( +09:53 < marex> shimoda: and I wonder, can you share that list / document ? +09:53 < kbingham> marex, if ATF does support H3ES1.x (as listed in that table) does that mean I can update the firmwares/uboot on this gmsl board? or is uboot a hard blocker. +09:54 < marex> shimoda: and if not, can you look into that document and tell me whether there might be a function which allows me to skip reloading the SA0 certificate from HF and continue using the one in DBSC4 SystemRAM 0xe6300400 address instead , after reboot ? +09:54 < marex> kbingham: 07:47 < marex> geertu: upstream ATF doesnt support H3 ES1.x, nor does upstream U-Boot +09:54 < kbingham> marex, <geertu> marex: Oh, that code does support H3 ES1.x +09:55 < marex> kbingham: so if it was added and tested, you could +09:55 < kbingham> my question is given ATF has tables for H3ES1, does that mean there is a chance uboot will work, or it will need development. +09:55 < morimoto> \me I need to quit soon for next Renesas meeting +09:56 < marex> kbingham: its untested, so backup your HF and test it if you want :) +09:56 * morimoto n? +09:56 * morimoto I need to quit soon for next Renesas meeting +09:56 < wsa> then, next meeting? +09:56 < marex> morimoto: good bye :( +09:56 < wsa> Aug, 27th? +09:57 < geertu> I was just going to aak: 3 or 4 weeks? +09:57 < geertu> s/aak/ask/ +09:57 < kbingham> 27th is listed as Linux Plumbers (virtual) in my calendar +09:57 < morimoto> marex: I will miss you... +09:57 < marex> awwwww +09:57 < kbingham> morimoto, you can't go ... I didn't get to tell you that GMSL is headed upstream yet though ;-) +09:57 < kbingham> hehe +09:57 < wsa> Is Sep, 3rd better? It is fine for me +09:57 < geertu> both a re fine for me. +09:57 < geertu> Plumbers is in the afternoon/evening, right? +09:58 < kbingham> morimoto, Well, ok so I've told you now so you can go if you need ;D +09:59 < wsa> morimoto, shimoda: any preference for the next meeting? +09:59 < morimoto> kbingham: nice to know :) +10:00 < geertu> wsa: let's decide by email, as pinchartl isn't here +10:00 < morimoto> wsa: 27th Aug, 3rd Sep, both are OK for me +10:00 < wsa> geertu: good idea +10:00 < wsa> morimoto: so, enjoy your meetings! +10:00 < wsa> ;) +10:00 < geertu> Anything else to discuss? +10:00 < morimoto> wsa: thanks, and bye +10:00 < morimoto> exit +10:00 < shimoda> marex: now I understood a bit :) Renesas BSP doesn't have rom_api.c, but Baylibre submitted it. So, Renesas has a document which can share to someone for secure boot. OK, I'll ask a person in Renesas later. +10:00 < morimoto> oops +10:01 -!- morimoto [~user@FL1-119-240-85-188.iba.mesh.ad.jp] has left #periperi ["ERC (IRC client for Emacs 26.3)"] +10:02 < marex> shimoda: thank you, really appreciated :) +10:02 < geertu> Thanks for joining, and have a nice continued day! +10:02 < shimoda> perhaps, next meeting at 27th? +10:02 < shimoda> or, 3rd, Sep? +10:02 < marex> shimoda: see, the thing is, if I could do reboot-into-B-copy, I could also do easy-ish ATF CI testing without weird instrumentation around the boards +10:02 < shimoda> by the way, I used 2 laptop PCs, I can join both this meeting and Renesas internal meeting :) +10:03 < geertu> shimoda: smart ;-) +10:03 < shimoda> geertu: :) +10:03 < kbingham> geertu, Just digging for timezone of plumbers. Has it been announced? My registration just says "Timezone: TBD" +10:03 < geertu> Who takes the mic for MM? kbingham? +10:03 < shimoda> marex: I understood your expectation. thanks! +10:04 * kbingham fumbles in the air ready to catch. +10:04 < geertu> kbingham: It was originally planned to be held in US, right? +10:04 < geertu> ELC-NA was in NA timezone +10:04 < kbingham> geertu, I think there was a vote for preferred timezone of the virtual event, so they were going to make a decision on that. +10:04 < marex> shimoda: besides, we are lagging behind even NXP in this department +10:04 < kbingham> But I didn't see the decision results yet. +10:05 < marex> shimoda: NXP iMX can do this A/B copy update since iMX5x, which is like 10 years old now, we should improve +10:06 < shimoda> marex: thanks for sharing information about iMX +10:06 < geertu> marex: We have old SoCs. Arnd was wondering about us upstreaming "new" SoCs like RZ/G2H containing 2015-era CA57 ;-) +10:06 < marex> geertu: iMX51 is CA8 +10:07 < marex> shimoda: sure +10:08 < kbingham> Ok, so are we ready to head through to the mm room ? +10:08 < marex> shimoda: its also not any secret or secure feature, its all there in the datasheet, which btw is publicly available +10:08 < marex> kbingham: yep, I stop here +10:08 * kbingham waits to grab mic from geertu +10:09 < kbingham> or maybe I'll just shout without the mic ;-) +10:09 < geertu> kbingham: mic diff --git a/wiki/Chat_log/20200806-io-chatlog b/wiki/Chat_log/20200806-io-chatlog new file mode 100644 index 0000000..3273dec --- /dev/null +++ b/wiki/Chat_log/20200806-io-chatlog @@ -0,0 +1,108 @@ +09:03 < wsa> but now for the IO meeting +09:03 < wsa> hey shimoda-san, glad you could make it +09:03 < marex> wsa: run the crappy software in qemu and use usbmon ? +09:04 < wsa> marex: http://shop.sysmocom.de/products/openvizsla-v3-dot-2-usb-protocol-analyzer-pcba +09:04 < wsa> it's open HW, I always wanted to have it, but seems I need some reason ;) +09:04 < marex> wsa: what for ? you can use plain software +09:04 < wsa> not all the time +09:05 < marex> wsa: those few times I needed bus analyzer, I used beagle and it was good enough +09:05 < marex> wsa: USB is usually slightly broken, I don't feel like having to fix usually slightly broken debug tool too :) +09:06 * wsa prefers openHW over QEMU solutions, might be taste +09:06 < wsa> but now for the status updates! +09:06 < wsa> Status updates +09:06 < wsa> ============== +09:06 < wsa> A - what have I done since last time +09:06 < wsa> ------------------------------------ +09:06 < wsa> Geert +09:06 < wsa> : posted generic bindings for Ethernet MAC explicit internal delay setting as implemented by RAVB, fixed boot crash in pci-rcar-gen2 +09:06 < wsa> Shimoda-san +09:06 < wsa> : added DT support for eMMC needing full power cycle in suspend, converted the SDHI binding docs to YAML, fixed the USB PHY driver to handle DEBUG_SHIRQ, and fixed a re-initialization failure in the RAVB driver +09:06 < wsa> Ulrich +09:06 < wsa> : found a way to make sure the i2c controller is awake before triggering atomic transfers +09:06 < wsa> Wolfram +09:06 < wsa> : discussed and sent out binding to activate emulated SMBus features for I2C, reviewed the HostNotify I2C implementation and updated the usage of it in i2c-rcar, made bugfixes for I2C slave (race when unregistering, timeout problems with Gen2, better sanity checks in the core), reviewed proposal to increase I2C_M_RECV_LEN limit from 32 to 255 and added I2C_M_RECV_LEN to +09:06 < wsa> i2c-rcar, bugfixed the i2c slave testunit and added a I2C_M_RECV_LEN test, guided and reviewed generic initialization of i2c bus recover via GPIO/pinctrl, tested that the DEBUG_SHIRQ issue is gone, made patches to update its documentation +09:06 < wsa> B - what I want to do until next time +09:06 < wsa> ------------------------------------- +09:06 < wsa> Geert +09:06 < wsa> : wants to test PCIe suspend/resume after arrival of Intel PCIe Ethernet card +09:06 < wsa> Niklas +09:06 < wsa> : wants to do the yearly test with SDIO-WIFI on Koelsch +09:06 < wsa> Shimoda-san +09:06 < wsa> : wants to convert rcar-pci dt doc to json-schema, fix usbhs issue for u_serial driver +09:06 < wsa> Ulrich +09:06 < wsa> : wants to send next version of atomic transfers for IIC, and implement the same for I2C +09:06 < wsa> Wolfram +09:06 < wsa> : wants to activate generic I2C recovery for i2c-sh_mobile, upstream SMBus emulation binding and core HostNotify support and R-Car support for it, upstream I2C slave testunit, guide increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support for it, fix all the flaws I found while developing the above, resend series 'fix stalled SCC' and 'implement manual calibration' for SDHI +09:06 < wsa> C - problems I currently have +09:06 < wsa> ----------------------------- +09:06 < wsa> Ulrich +09:06 < wsa> : wonders where to add the reboot notifier handling, in the driver or in the watchdog core +09:06 < wsa> Wolfram +09:06 < wsa> : has a second Zebax adapter which has a pin not working and wonders how the others are doing +09:07 < wsa> comments? +09:07 < wsa> we will talk about uli__'s question shortly +09:07 < wsa> (shortly? I meant "in a bit") +09:08 -!- morimoto [~user@FL1-119-240-85-188.iba.mesh.ad.jp] has joined #periperi +09:08 < wsa> from my side, it was nice that a few people tackled I2C issues which were also relevant for Renesas +09:08 < wsa> so, I could delegate some work to them and just guide them +09:09 < wsa> although it needed discussions, too +09:09 < wsa> however, this explains the heavy shift to I2C related work the last weeks +09:09 < wsa> shimoda: I will do an SDHI week next week to catch up with pending patches +09:10 < shimoda> wsa: i got it. thanks! JFYI, I will have a vacation from tomorrow to 16th +09:11 < shimoda> ah, just I got a report from BSP team about SDHI driver +09:11 < shimoda> so, I'll send an email to you today :) +09:12 < wsa> shimoda: thanks +09:14 < wsa> uli__: I wondered if you could add a helper function to the core (which still must be called from the driver) +09:14 < geertu> wsa: uli__ : or a flag, like spi_controller.auto_runtime_pm +09:15 < wsa> so, it is still not fully like "the core handles PM" but more like "there is code in the core reducing boilerplate if I want this feature" +09:15 < wsa> geertu: this will save converting the drivers, but still one would need to add generic PM handling to the core, right? +09:16 < geertu> wsa: yes +09:16 < geertu> Not much to do there, right? +09:16 < geertu> Start, Stop, Reboot? +09:17 < geertu> Adding 3 pm_runtime_*() calls if auto_runtime_pm is set? +09:17 < geertu> Or am I missing something? +09:18 < uli__> i must admit that i haven't looked in detail into what exactly those WDT drivers are doing in terms of PM, but that should be all I guess +09:18 < wsa> There are 4 WDT drivers using RPM +09:18 < wsa> 2 of them are from Renesas :) +09:19 < geertu> We are the RPM heroes ;-) +09:19 < wsa> just from grepping, it looks like OMAP does a bit more complicated things with RPM +09:21 < uli__> it still seems to me that the drivers that don't do runtime PM should do it, too. either i'm missing something, or it just "happens to work" for everyone +09:21 < wsa> i think it boils down if uli__ has the time and initiative to add this to the WDT core +09:21 < wsa> it would be nice to have, of course +09:23 < uli__> my gut feeling tells me to try getting it in the DA9063 driver first, and only do the WDT core if there are objections... +09:23 < geertu> That's always a valid approach. +09:24 < geertu> 1. Implement feature in one or more drivers +09:24 < geertu> 2. Move it to the core +09:24 < geertu> 3. Profit! +09:24 < wsa> Fine with me, too +09:24 < geertu> You could ponder step 2 in step 1 +09:25 < uli__> then i'll do that +09:25 < uli__> thanks for the advice +09:25 < wsa> sure thing, uli__ :) +09:25 < wsa> are there other questions or topics? +09:26 < wsa> has someone else experienced Zebax problems? Like Pin33 does not work anymore, but the rest does? +09:26 < geertu> It's the adapter, and not the board? +09:27 < geertu> IIRC, these are rated for less than 100 insertions, which I find a bit low. +09:28 < wsa> it is the adapter, another one works +09:28 < wsa> geertu: in deed :( +09:29 < wsa> I measured the adapter and the signal of my multimeter goes through. Very weird! +09:29 < wsa> But if you don't have problems, lucky you :) +09:29 < geertu> Probably a sloght displacement of the contact +09:29 < geertu> So far no problems (holds wood) +09:30 < uli__> which adapter are we talking about? +09:31 < wsa> uli__: The ones you dislike so much that you made your own one :) +09:31 < uli__> aren't there two kinds with different pin pitches? +09:31 < wsa> Samtec-to-breakout +09:32 < wsa> anyhow, I think this was it for the IO meeting +09:32 < wsa> uli__: yes, there are +09:33 < uli__> so which is the one that broke? +09:33 < wsa> uli__: I only have the "wide" pitch +09:33 < wsa> I'd like to have a narrow one somehow, but was irritated by the one losing a pin now +09:33 < geertu> That's 0.8 mm, right? +09:34 < wsa> yes +09:34 < marex> morimoto: shimoda: hi, I was curious, is there some extra documentation for the bootrom ? esp. the IPL A/B switching mechanism ? I recall the security LCS stuff in TFA implements some calls into bootrom, so maybe there is some list of bootrom functions you can call from your own system software ? is there some internal renesas documentation for that ? +09:35 < marex> I mean, there must be some way to push the bootrom to boot the IPL Bcopy, right ? +09:35 < geertu> marex: Sounds like Core? +09:35 < wsa> then, let's switch over to core. Zebax adapters fit there, too, if we want to keep the topic ;) +09:35 < wsa> geertu: have fun! diff --git a/wiki/Chat_log/20200903-core-chatlog b/wiki/Chat_log/20200903-core-chatlog new file mode 100644 index 0000000..cb355af --- /dev/null +++ b/wiki/Chat_log/20200903-core-chatlog @@ -0,0 +1,137 @@ +09:31 < geertu> Welcome to today's Core Group Chat Meeting! +09:31 < marex> wsa: nope +09:31 < geertu> wsa: No (new) family duties for you? +09:31 < wsa> (and I am not thinking of the sushi, honestly) +09:31 < geertu> Agenda: +09:31 < geertu> 1. Status Updates +09:31 < geertu> 2. Discussion Topics +09:31 < geertu> Topic 1. Status updates +09:32 < wsa> geertu: sure, but I can still go away for 2 weeks once in a while +09:32 < geertu> A) What have we done since last time: +09:32 < geertu> Marek work on SH4 QEMU test hooks for U-Boot, multiple mem node parsing +09:32 < geertu> for OpteeOS, and added basic R-Car Gen3 support to QEMU. +09:32 < geertu> Morimoto-san posted menu Kconfig patches. +09:32 < geertu> Shimoda-san started to develop initial support for R-Car V3U. +09:32 < geertu> Geert attended LPC, converted pinctrl bindings to json-schema, worked on +09:32 < geertu> head.S for RZ/A2, and kdump, and reviewed RZ/G patches. +09:32 < geertu> B) What we plan to do till next time: +09:32 < geertu> Marek plans to continue on QEMU. +09:32 < geertu> Shimoda-san plans to continue initial support for R-Car V3U, convert the +09:32 < geertu> usb2-clock doc to json-schema, and ping the hardware manual team about +09:32 < geertu> sharing the R-Car V3U manual. +09:32 < geertu> Geert plans to review more RZ/G patches, send pull request for v5.10, +09:32 < geertu> rename drivers/pinctrl/sh-pfc/, and perhaps continue QEMU GPIO +09:32 < geertu> virtualization. +09:33 < geertu> C) Problems we have currently: +09:33 < geertu> Geert suffers from failures in kernels booted through kexec. +09:33 < geertu> --EOT-- +09:33 < geertu> Anything I missed? +09:34 < marex> geertu: the gen3 qemu is still local and WIP +09:34 < geertu> Initial R-Car V3U support can be in v5.10, if it is posted and reviewed in time (i.e, during the next 2 weeks) +09:35 < wsa> no offence, but what do we need Gen3-QEMU for? +09:35 < marex> wsa: same as sh4 qemu, CI +09:35 < marex> wsa: and figuring out whether the bootrom can do switching between two copies of IPL somehow as a byproduct (for CI again) +09:36 < marex> wsa: SH4 U-Boot is tested in QEMU on every push to the repository +09:36 < geertu> Topic 2. Discussion Topics +09:36 < wsa> so, it is basically on CPU core level? I mean, you won't recode all of the IPs present, or? +09:37 < marex> wsa: I will model some subset of them +09:37 < marex> wsa: well, there is another upside in that you can track IO accesses and possibly detect writes to bits which you shouldn't be writing, like in PFC/clock +09:37 < wsa> yes, that's for sure +09:38 < geertu> Especially writes done by the boot ROM... +09:38 < marex> ... to registers which are undocumented ... +09:38 < wsa> I just wondered becuase Gen3 is, you know, HUGE +09:39 < marex> wsa: TFA/U-Boot doesn't use a large part of that, and Linux can also be reduced +09:39 < wsa> but I see the values you pointed out +09:39 < wsa> OK, I have a disucssion point +09:39 < wsa> pinctrl switching to GPIO +09:40 < wsa> major pain or small addition? :) +09:40 < geertu> wsa: I think that'll be rather a major pain, as it involves pinctrl core. +09:41 < geertu> Basically we need support for obtaining the GPIO corresponding to a function pin? +09:41 < geertu> Shimoda-san had a try at that a while ago +09:42 < wsa> Hmm, when I looked at other SoCs implementing bus recovery I had the impression they could do it using pinctrl. Am I wrong? +09:43 < geertu> wsa: Do you have a pointer to an example? +09:43 < marex> git grep pinctrl-1 +09:43 < damm> going back from pinctrl to GPIO? +09:43 < damm> full circle if so +09:44 < wsa> geertu: I am already checking +09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts- i2c1: i2c@fc028000 { +09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts- dmas = <0>, <0>; +09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts- pinctrl-names = "default", "gpio"; +09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts- pinctrl-0 = <&pinctrl_i2c1_default>; +09:44 < marex> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts: pinctrl-1 = <&pinctrl_i2c1_gpio>; +09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi-&i2c1 { +09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi- clock-frequency = <100000>; +09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi- pinctrl-names = "default", "gpio"; +09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi- pinctrl-0 = <&pinctrl_i2c1>; +09:44 < marex> arch/arm/boot/dts/imx6qdl-ts7970.dtsi: pinctrl-1 = <&pinctrl_i2c1_gpio>; +09:45 < wsa> [PATCH 0/4] i2c: core: add generic GPIO bus recovery +09:45 < damm> ah ok thanks for clarifying +09:46 < marex> wsa: so yep, the solution should be to call pinctrl_set_state() or whatever that is called now , pick the pinctrl-1 , do recovery, then pick pinctrl-0 +09:46 < geertu> These allow to specify GPIO in a DT pinctrl node +09:46 < geertu> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts +09:46 < geertu> pinmux = <PIN_PD21__TWD0> vs <PIN_PD21__GPIO> +09:47 < geertu> Do we need support for function = "gpio" in sh-pfc? +09:47 < wsa> marex: and this doesn't work for us +09:47 < geertu> Or teach the pinctrl core to do function -> gpio setup? +09:47 < marex> wsa: why ? +09:47 < geertu> The core already knows how to do the reverse +09:48 < wsa> marex: because we don't have 'function = "gpio"' +09:48 < marex> ah +09:49 < marex> wsa: shouldn't we ? +09:49 < geertu> Having it in the core means that we don't have to describe a second pinctrl state in DT +09:49 < geertu> The latter is basically superfluous, as the kernel already knows the mapping +09:49 < wsa> marex: this is what we are discussing now :) +09:50 < marex> wsa: it would make the behavior in-line with the other platforms at least +09:50 < wsa> geertu: but not all pins can be switched to a GPIO, won't that make it more difficult? +09:51 < wsa> Like IIC0 can't be switched to GPIO on Gen3 +09:51 < geertu> wsa: function would return -EINVAL? +09:51 < damm> may i propose that in case a user tries to swith a non-valid function to GPIO then instead of returning error we can just return a random GPIO? =) +09:52 < geertu> If the pin can't switch to GPIO, that can't be described in DT neither +09:52 < marex> geertu: it can, you can write invalid DT, but then -EINVAL is the way to go +09:53 < geertu> wsa: So all of that patch series has already been applied? Doh, just wanted to reply the kernel already knows the ampping... +09:53 < wsa> geertu: so, what would you suggest? pinctrl_unset_stete() will bring back GPIO? +09:53 * geertu kicks marex and damm +09:54 < wsa> damm: it should return the CAN connection to your car +09:54 < marex> wsa: well that sounds like a hack :) +09:54 < marex> (unset_state -> gpio) +09:55 < geertu> wsa: Hmm. The extra pinctrl state is superfluous, IMHO, but you still need to know which of the 2 GPIOs is SCL and which is SDA +09:55 < marex> geertu: for that you have the {scl,sda}-gpios in the DT ? +09:55 < geertu> For PWM it's simpler: just one pin ;-) +09:56 < geertu> marex: yes +09:56 < marex> but not for the pinmux if it's separate, hah +09:56 < wsa> geertu: that binding is also still needed to stay generic. you could have two other gpios wired to the bus just for recovery +09:56 < geertu> wsa: Good point. +09:56 < geertu> So sh-pfc needs support for 'function = "gpio"' it is? +09:57 < damm> this reminds me of uart flow control signals as gpio? +09:57 < damm> and the software gpio cs for msiof +09:57 < wsa> damm: and the zero-duty-cycle-GPIO for PWM +09:57 < geertu> Now, how does rwquest_gpio() work if the pin is considered busy by pinctrl? +09:58 < geertu> s/rwquest/requst/ +09:58 < wsa> -EBUSY +09:58 < geertu> Indeed, so does it really work? +09:59 < wsa> That's what I got when I tried the GPIO bus recovery with IIC on Lager +09:59 < geertu> So you have to undo the pinctrl state manually, and request the GPIO afterwards? No pinctrl-1 needed? +10:00 < wsa> that could work +10:00 < geertu> Later, unrequest GPIO + pinctrl enable again? +10:00 < wsa> this is what I meant above with "pinctrl_unset_state()" +10:00 < geertu> How does it work for the other people? No -EBUSY? +10:01 < wsa> they switch the state to GPIO +10:02 < geertu> Yeah, but the pin is still busy, according to pinctrl? Or they don't track busy/idle state? +10:03 < geertu> The pinctrl driver treats PIN_PD21__TWD0 vs PIN_PD21__GPIO the same, i.e. just as a value to write to a register +10:03 < geertu> cfr. RZ/A1 and RZ/A2 +10:03 < geertu> wsa: Tried your genmai? +10:04 < wsa> jmondi has the Genmai meanwhile +10:04 < jmondi> wsa: do I ? :) +10:04 < geertu> Or the peach ;) +10:04 < jmondi> didn't I give it back to you ? I'll check +10:04 < wsa> jmondi: I hope so! :D +10:04 < geertu> Remote genmai @ Magnus? +10:05 < jmondi> geertu: I use the peach for RZ/A1 +10:05 < jmondi> do you guys need any testing ? +10:05 < damm> i can probably find such a board somewhere +10:05 < geertu> Anyway, we're running late, violating MM space +10:05 < geertu> Let's take it to the ML? +10:05 < geertu> Anything else to discuss? +10:05 < wsa> jmondi: did you? If not, it would be nice to get it back because it is interesting for i2c slave development +10:06 < wsa> geertu: ack, let's take it to ML +10:07 < geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20200903-io-chatlog b/wiki/Chat_log/20200903-io-chatlog new file mode 100644 index 0000000..0acacb9 --- /dev/null +++ b/wiki/Chat_log/20200903-io-chatlog @@ -0,0 +1,123 @@ +09:03 < wsa> OK, let's get started with the IO meeting +09:03 < wsa> welcome everyone, hope you are fine +09:03 < wsa> here are the collected status updates +09:03 < wsa> Status updates +09:03 < wsa> ============== +09:03 < wsa> A - what have I done since last time +09:03 < wsa> ------------------------------------ +09:03 < wsa> Geert +09:03 < wsa> : did regression tests for SCIF with SH4 based hardware, fixed a few other issues on the way, tested suspend/resume with PCIe and investigated the problems, reposted RSPI bit rate improvements, posted v3 of generic bindings for Ethernet MAC explicit internal delay setting, implemented by RAVB, posted a revert for linkwatch after some more investigation +09:03 < wsa> Niklas +09:03 < wsa> : unsuccessfully tested SDIO WiFi with Koelsch on Gen2. Probably because of a too long cable. He will try a shorter one. +09:03 < wsa> Shimoda-san +09:03 < wsa> : sent a patch fixing the suspend handling of the USB serial gadget, reviewed and tested Wolfram's SDHI patches about the stalled SCC and the reset refactoring and the card reset after IP reset, also reviewed lots of bindings for r8a774...- SoCs as well as USB bindings +09:03 < wsa> Ulrich +09:03 < wsa> : sent "watchdog: da9063: wake up parent ahead of reboot" to enable late atomic transfers with IIC +09:03 < wsa> Wolfram +09:03 < wsa> : refactored SDHI driver to use 'reset' and 'hw_reset' as intended by the MMC subsystem, sent out a fix to reset the card after the IP core was reset (needs follow up), finally was able to reproduce and inject the stalled SCC case, reworked series 'fix stalled SCC' and 'implement manual calibration' for SDHI and sent out, tried to add bus recovery to the IIC module based on +09:03 < wsa> generic pinctrl bus recovery, refactored timeout handling in the I2C driver, both for bus recovery and when resetting the IP core, sent patch to correctly handle FNA bit of the I2C module, updated i2ctransfer to support I2C_M_RECV_LEN, sent minor fixes along the way all over the place +09:03 < wsa> B - what I want to do until next time +09:03 < wsa> ------------------------------------- +09:03 < wsa> Shimoda-san +09:03 < wsa> : wants to convert rcar-pci dt doc to json-schema, and ping the serial gadget patch I have submitted +09:03 < wsa> Ulrich +09:03 < wsa> : wants to address feedback for "watchdog: da9063: wake up parent ahead of reboot", and implement atomic transfers for i2c-rcar +09:03 < wsa> Wolfram +09:03 < wsa> : wants to upstream SMBus emulation binding, core HostNotify support, and R-Car support for HostNotify, upstream I2C slave testunit, guide the increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support for it +09:03 < wsa> C - problems I currently have +09:03 < wsa> ----------------------------- +09:03 < wsa> Geert +09:03 < wsa> : wonders how to avoid PCIe s2ram crash on R-Car Gen2 +09:03 < wsa> Wolfram +09:03 < wsa> : found out that adding bus recovery to IIC not possible at the moment because we cannot switch to/from GPIO state using pinctrl_set_state(). Might be a task for the core group because PWM could use it, too, for zero duty-cycles. However, for IIC it is low priority because bus recovery is mostly useful on Gen2. Another issue is that there is no response from Rob about the SMBus emulation binding +09:04 < wsa> If you have questions or comments, please fire away +09:04 < wsa> I'll start with asking geertu a one-line summary for the PCIe crash? Is there something in the s2ram which gets lost during suspend? +09:05 < marex> I was about to ask the same +09:05 < geertu> wsa: marex: It's the same issue as on R-Car Gen3. +09:05 < geertu> But on arm64, it was fixed in ATF (by marex-san) +09:05 < marex> geertu: thats on RZ then ? +09:06 < geertu> marex: No, R-Car Gen2 (koelsch). But RZ/G1 should be affected, too. +09:06 < marex> ah sigh +09:07 < geertu> https://github.com/ARM-software/arm-trusted-firmware/commit/0969397f295621aa26b3d14b76dd397d22be58bf +09:07 < geertu> On arm32, we need to hook up something into the exception handling in Linux? +09:07 < marex> geertu: so is linux able to get the fault and fix it up ? +09:07 < geertu> marex: Currently not +09:08 < marex> geertu: I suspect you might just need to do as iMX6 does +09:08 < marex> geertu: that one did generate some faults when PCIe went nuts too +09:08 < marex> geertu: and there both U-Boot and Linux hooked the fault handler +09:09 < wsa> geertu: what is missing for Linux? +09:09 < marex> wsa: the same workaround as in TFA apparently +09:09 < geertu> marex: Sounds like a good job for the PCI DRIVER FOR RENESAS R-CAR maintainer? ;-) +09:09 < marex> wsa: except implemented via the fault hooks +09:10 < marex> wsa: that is , IFF , the gen2 generates such a fault instead of locking up +09:10 < marex> needs to be checked +09:10 < geertu> marex: It generates such a fault +09:11 < wsa> ok, that's sounds doable? I understood Geert's comment that way that Linux is missing some prerequisite to handle it +09:11 < marex> wsa: nope +09:11 < wsa> So, on Gen3, why did we chose the ATF way instead of pure Linux? +09:11 < marex> wsa: the stuff should be all there +09:11 < marex> wsa: because on Gen3, you get a fault in EL3 +09:11 < geertu> Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 +09:12 < wsa> ok +09:12 < geertu> (that line is from M2-W) +09:12 < marex> geertu: hold on, I need some coffee first +09:13 < wsa> ok, I'll wait for Marex to get some coffee and _then_ ask him if he is interested in tackling it ;) +09:14 < wsa> shimoda: thanks for the quick testing of my SDHI patches +09:14 < wsa> I really hope we have no more stalled SCC problems anymore +09:15 < shimoda> wsa: you're welcome! i'll review manual calib patches later +09:15 < wsa> Though, the fact that it stalled when switching the divider was interesting, but as said, I don't fully get it from the documentation I have +09:15 < wsa> shimoda: Awesome, thanks! +09:16 < marex> geertu: drivers/pci/controller/dwc/pci-imx6.c +09:16 < marex> 1300 hook_fault_code(8, imx6q_pcie_abort_handler, SIGBUS, 0, +09:16 < marex> 1301 "external abort on non-linefetch"); +09:16 < marex> look ^ +09:16 < marex> so we'll need similar "workaround" +09:18 < wsa> geertu: the 77961-io todo mentions adding cmt and sh-msiof. Is there a chance to get this added via remote access? Didn't damm have some SPI device to connect or am I remembering wrong? +09:18 < geertu> wsa: No SPI devices, AFAIK +09:18 < wsa> uli___: seems that Guenter missed that there is no RPM that late, or? +09:19 < wsa> geertu: ah, okay. well, you would have known if there are any ;) +09:19 < damm> i don't mind hooking up stuff if needed +09:19 < geertu> wsa: I think he doesn't know much about RPM in general +09:20 < uli___> wsa: just needs a little explaining, I guess +09:20 < wsa> damm: that's great! next one will be the CAN devices ;) +09:20 < geertu> damm: Perhaps just a wire? Then we can do SPI loopback tests +09:20 < wsa> damm: so, get your car close to the lab +09:20 < damm> great! I need an extension cable to be able to reach all the way to the car =) +09:20 < wsa> :) +09:21 < damm> send me an email with details please +09:21 < damm> if you do it today EU time then I can finish it this week +09:21 < damm> otherwise it will have to wait for a couple of weeks +09:22 < wsa> magnus is going to okinawa? +09:22 < damm> just leaving the remote access location for a while +09:23 < marex> damm: would you still be able to reinstate and/or install ssh keys ? +09:23 < damm> yeah that i can do remotely +09:23 < geertu> marex: As you're mostly familiar with the PCIe issue, can you please handle it? +09:23 < damm> cables are more difficult =) +09:24 < wsa> marex: that would be great, in deed +09:24 < marex> yeah +09:24 < wsa> awesome, thanks! +09:25 < wsa> this is all from my side, any question left? +09:26 < wsa> not the case +09:26 < wsa> geertu: ready for core? +09:26 < geertu> wsa: But but... it's not yet hh:30? +09:27 < wsa> IO group is in HS400 mode +09:27 < geertu> please retune now ;-) +09:27 < wsa> uh oh +09:28 < moriperi> wsa: 1 thing from me +09:28 < marex> geertu: downshift to MMC52 is hard, dont torture them +09:28 < wsa> geertu triggerd a halted system again, great! ;) +09:28 < wsa> moriperi: what is it? +09:28 < moriperi> Now BSP team is tring to enable I2C on V3U board, but has timeout error. +09:28 < moriperi> But, it started works if some delay was added, they said. +09:28 < moriperi> 1 concern is that V3U is *almost* same as previous SoC, but in my understanding, previous SoC needed some workaround. +09:29 < moriperi> If V3U was fixed around I2C, workaround might be not needed anymore. +09:29 < moriperi> Now BSP team is investigating / confirming. +09:29 < moriperi> So nothing to do today, but just information for you. +09:29 < wsa> OK +09:29 < moriperi> We will ask something to you if V3U board was ready +09:30 < moriperi> that's all from me, thanks +09:30 < wsa> I'll just wait +09:30 < wsa> I can't recall any workaround or additional delay from the top of my head, but we will see... +09:30 < marex> real shame there's no OSSJ this year, we could've done V3U peripericon and bring it all up +09:30 < geertu> marex: virtual peripericon? +09:30 < geertu> Time to launch core? diff --git a/wiki/Chat_log/20200903-mm-chatlog b/wiki/Chat_log/20200903-mm-chatlog new file mode 100644 index 0000000..13a4f02 --- /dev/null +++ b/wiki/Chat_log/20200903-mm-chatlog @@ -0,0 +1,255 @@ +<pinchartl> welcome to the multimedia group meeting +<jmondi> pinchartl: hello [17:05] +<pinchartl> Topic 1. Status Check for the Multimedia Tasks +<pinchartl> * Jacopo +<pinchartl> Since last meeting: +<pinchartl> - Linux Plumbers Conference +<pinchartl> - DT bindings image sensor conversion +<pinchartl> Converted mt9v111, imx214, ov5670 and ov772x +<pinchartl> - max9286 format configuration +<pinchartl> To prepare for upstreaming support for RDACM21, the max9286 driver +<pinchartl> has to be adapted to support different receivers. +<pinchartl> [PATCH 0/4] media: i2c: max9286: Use remote endpoint image format +<pinchartl> The series was not exactly apreciated, so a different solution is +<pinchartl> required. +<pinchartl> - Patch review +<pinchartl> Reviewed Prabhakar'd ov772x and ov5640 patches for Renesas G1H dev +<pinchartl> boards. +<pinchartl> Until next meeting: +<pinchartl> - Re-think how to handle formats for max9286 +<pinchartl> - Resume GMSL reverse channel configuration discussion +<pinchartl> - Re-send dt-bindings now that we have clarified how to handle +<pinchartl> endpoints +<pinchartl> Issues and blockers: None +<pinchartl> jmondi: you can go first :-) any comment ? +<jmondi> not really, I think I need to re-look at format handlin on max9286 + [17:06] +<jmondi> but no comment on the current status update thanks +<pinchartl> ok, thanks +<pinchartl> regarding format handling, would you like to discuss during this + meeting, or do you need to look at it first ? [17:07] +<jmondi> pinchartl: if we have 5 minutes at the end, let's discuss it +<pinchartl> ok, I'll add it to the discussion points +<jmondi> it shouldn't be long after all, I just need to convince you and + Sakari... it's gonna be like 5 minutes, right ? =) [17:08] +<pinchartl> * Kieran +<pinchartl> Since last meeting: +<pinchartl> - Linux Plumbers Conference +<pinchartl> - Patch review +<pinchartl> - GMSL reviews/fixups +<pinchartl> - ADV748x audio input +<pinchartl> Failed to successfully capture anything. Responded to author, not + sure +<pinchartl> if the test procedure is wrong or if the problem lies elsewhere. +<pinchartl> Until next meeting: +<pinchartl> - Aim to finish/resolve the ADV748x audio tests +<pinchartl> - Work towards DT integration/overlays for GMSL +<pinchartl> - Look at V4L2 Multiplex streams topics for GMSL +<pinchartl> Issues and blockers: None +<pinchartl> Kieran asked to be excused as he's stuck babysitting today +<pinchartl> * Laurent +<pinchartl> Since last meeting: +<pinchartl> - Linux Plumbers Conference +<pinchartl> Participated (among other topics) in the dmabuf heaps and + userspace +<pinchartl> buffer allocation library discussions. +<pinchartl> - DISCOM CRC calculation tool +<pinchartl> Implemented a tool to calculate the CRC of an image using the same +<pinchartl> algorithm as the DISCOM, and integrated it in the DU test + suite. This +<pinchartl> exposed a crash in the DU driver, developed and posted a fix. +<pinchartl> - V4L2 async subdev allocation fixes +<pinchartl> Posted fixes for V4L2 async subdev allocation in the various + Renesas +<pinchartl> V4L2 drivers. The fix for VIN has been superseded by patches from +<pinchartl> Niklas. The fix for DRIF is pending testing from the Renesas UK + team. [17:09] +<pinchartl> - Patch review +<pinchartl> Among other things, Renesas UK has provided the schematics for the + iWave +<pinchartl> board, which unblocked review of the DT integration. +<pinchartl> Until next meeting: +<pinchartl> - Follow-up on pending patch series +<pinchartl> Get pending patches merged, pinging maintainers where needed. +<pinchartl> - Help with debugging the DU + CMM suspend/resume crash if needed +<pinchartl> - Move forward with the V4L2 multiplexed streams proposal +<pinchartl> Issues and Blockers: None +<pinchartl> any question ? +<moriperi> Thank you for DISCOM tool +<pinchartl> you're welcome [17:10] +<pinchartl> * Morimoto-san +<pinchartl> Since last meeting: +<pinchartl> - Post Renesas menu Kconfig patch +<pinchartl> v3 may be needed. +<pinchartl> - Continue posting ALSA SoC cleanup patches +<pinchartl> - Complex connection handling in ALSA SoC +<pinchartl> Current ALSA SoC has 2 generic sound card (= glue for SoC / Codec) +<pinchartl> driver, and one of them is for OF-graph. Current ALSA SoC + maintainer is +<pinchartl> recommending to use it. But unfortunately, it can't handle complex +<pinchartl> connection for now. But in these days, at least 2 vendors want to + use +<pinchartl> complex connections by using this generic driver. One of them has + posted +<pinchartl> *hack* patches. Thus I started to think about *non-hack* expansion + for +<pinchartl> it. +<pinchartl> Until next meeting: +<pinchartl> - Create dummy test driver to develop complex connection handling +<pinchartl> - Continue posting ALSA SoC cleanup patches +<pinchartl> Issues and Blockers: None +<pinchartl> moriperi: any comment ? +<moriperi> thanks. no comment, but have question. later this. [17:11] +<pinchartl> ok +<pinchartl> * Niklas +<pinchartl> Since last meeting: +<pinchartl> - [PATCH 0/2] v4l: async: Switch to endpoint node matching +<pinchartl> - [PATCH 0/2] rcar-vin: Fix issues with partial probed media + graphs +<pinchartl> - Summer vacation, back in office Monday the 7th +<pinchartl> Until next meeting: +<pinchartl> - Post second round of improvements for VIN and V4L2 lifetime + issues +<pinchartl> - Backlog cleaning +<pinchartl> Issues and blockers: None +<pinchartl> Niklas asked to be excuse as he's travelling back to Germany +<pinchartl> Topic 2. Discussions +<pinchartl> moriperi: you said you have a question for later. I think later + could be now :-) [17:12] +<moriperi> jacopo first is oK +<pinchartl> ok :-) +<pinchartl> MAX9286 format handlign then +<pinchartl> jmondi: ? +<jmondi> yup [17:13] +<jmondi> well, I think the deser should reflect the remote's format, you and + Sakari think not +<jmondi> I think it boils down to that, right ? :) +<pinchartl> pretty much :-) [17:14] +<pinchartl> the design idea behind MC drivers is that format propagation + should be handled by userspace +<pinchartl> for multiplexed streams, we may do otherwise +<pinchartl> but the GMSL link isn't multiplexed, it carries a single stream + [17:15] +<jmondi> I don't see it being related to multiplexed, but more specifically on + what the de-serializer does +<jmondi> you can say it's not different from any other bridge + $protocol-to-csi2 +<pinchartl> correct [17:16] +<jmondi> I see +<pinchartl> and if you look at a parallel to CSI-2 chips, they don't fetch the + remote format on the parallel sink +<pinchartl> userspace propagates the format on the parallel side +<jmondi> and indeed format can be set on the sink pads +<jmondi> so it's maybe better handled by updating the vin-test scripts [17:17] +<jmondi> parsing the remote format and apply it on the deser sink pads +<pinchartl> media-ctl will do it for you [17:18] +<pinchartl> if you set the format on a source pad that has a connected link, + it will automatically set it on the remote sink pad +<jmondi> across links ? [17:19] +<jmondi> I never noticed that :/ +<pinchartl> yes, across links +<jmondi> good to know, now I should check why it doesn't happen then +<jmondi> anyway, let's defer to userspace +<pinchartl> ok [17:20] +<jmondi> thanks, moriperi please go ahead then +<pinchartl> another discussion point, DU + CMM suspend/resume crash +<jmondi> ah +<jmondi> I'm at "please rest (for now)" [17:21] +<pinchartl> moriperi: you mentioned in an e-mail that you would check with the + customer whether we need to look into this +<jmondi> any update ? +<pinchartl> do you have any update on that ? +<moriperi> no update if my memroy was correct [17:22] +<pinchartl> should we still wait ? I'd like to raise the issue with the PM + core developers, as I think the problem would be fixed if they + didn't forcefully PM-runtime-resume devices needlessly at system + suspend +<geertu> The person from Renesas EU who contacted me regards this issue, had + told me he pinged Eugeniu. [17:24] +<geertu> But so far no response from Eugeniu, AFAIK +<pinchartl> I propose initiating the PM discussion, as these matters may take + time +<moriperi> I don't remember detail, but DU also has bind/unbind issue ? + [17:25] +<pinchartl> is that a separate issue ? +<moriperi> oops ? please ignore, my fault maybe [17:26] +<pinchartl> it could just be me misremembering it :-) +<pinchartl> jmondi: does it ring a bell ? [17:27] +<jmondi> bind/unbind not really :( [17:28] +<moriperi> So is it my turn ? +<pinchartl> yes :-) +<jmondi> moriperi: please go ahead! +<moriperi> Thanks +<moriperi> About OF-graph +<moriperi> I know we can use "ports" for "port" groups +<moriperi> ports - port - endpoint +<moriperi> port - endpoint +<moriperi> ... +<moriperi> But now, I want to have sub-groups, like this +<moriperi> ports - port - endpoint +<moriperi> - port - endpoint +<moriperi> +<moriperi> - ports - port - endpoint <= [17:29] +<moriperi> - port - endpoint <= +<moriperi> I think OF-graph doesn't support it, right ? +<pinchartl> correct +<moriperi> Do you know someone who has same issue/idea ? +<pinchartl> not really, no +<pinchartl> what do you want to use that for ? +<moriperi> now I nama it as port3, port4. +<moriperi> s/nama/name [17:30] +<moriperi> port3, and port4 are separate device, but want to use in the same + time as same interface +<moriperi> thus we want to group [17:31] +<pinchartl> I don't know of anyone who would have tried to do that +<pinchartl> maybe the best option would be to post an RFC to explain the + problem and the proposed solution ? +<pinchartl> it would be helpful if it explained the hardware architecture and + gave a corresponding DT example [17:32] +<moriperi> Yes maybe. Or I already have other idea. but in that, the graph + will be very huge :( +<moriperi> but it is ok for now, not a big-deal. thanks [17:33] +<moriperi> pinchartl: ahhh, about bind/unbind, it was for VIN, not for DU + [17:34] +<pinchartl> you're welcome. I'd be happy to help if I can, please just let me + know :-) +<moriperi> sorry for my noise +<pinchartl> yes, for VIN we clearly had issues +<pinchartl> no worries +<pinchartl> any other discussion point for today ? +<moriperi> not from me [17:35] +<jmondi> pinchartl: one last thing +<jmondi> i2c sensor yaml :) (I know..) +<wsa> next meeting on October, 1st? +<jmondi> we decided to defer to of-graph.yaml ports/endpoint/remote-endpoint +<jmondi> but what if I have endpoint properties to document ? +<pinchartl> in that case you should have the endpoints in your bindings + [17:36] +<pinchartl> it's only for the case where nothing else needs to be documented + that you can drop them +<pinchartl> basically, of-graph.yaml will take care of the schema for + ports/port/endpoint/remote-endpoint [17:37] +<pinchartl> so it doesn't have to be duplicated everywhere +<pinchartl> but the rest needs to be handled manually +<pinchartl> any question still about this ? [17:39] +<jmondi> on +<jmondi> no +<jmondi> just wanted to make sure so next iteration is ok +<jmondi> thanks for the answer +<pinchartl> you're welcome [17:41] +<pinchartl> any other discussion topic ? +<wsa> next meeting on October, 1st? +<pinchartl> :-) +<pinchartl> works for me +<geertu> #metoo [17:42] +<shimoda> works for me +<pinchartl> I propose adjourning the multimedia meeting +<pinchartl> does anyone second ? +<wsa> good, then it is decided [17:43] +<geertu> third? +<jmondi> seconded! [17:44] +<pinchartl> meeting adjourned. thank you all for attending [17:45] +<pinchartl> have a nice day +<jmondi> thank you all +<damm> thanks guys [17:46] +<shimoda> thanks! [17:47] diff --git a/wiki/Chat_log/20201001-core-chatlog b/wiki/Chat_log/20201001-core-chatlog new file mode 100644 index 0000000..8cf40d0 --- /dev/null +++ b/wiki/Chat_log/20201001-core-chatlog @@ -0,0 +1,157 @@ +09:31 < shimoda> marex: i'd like to support u-boot for v3u at least. but, if so, we cannot support PSCI. So, perhaps, we also should support atf? Or, u-boot only is enough? +09:31 < wsa> it is "best effort" for now as I understood it +09:32 < marex> shimoda: we can do both +09:32 < shimoda> ah, i also got boards datasheets. +09:32 < geertu> Note that upstream won't accept arm64 SMP support that does not use PSCI +09:32 < marex> shimoda: isnt v3u booting via tfa/uboot anyway ? +09:32 < shimoda> moriperi: could we share boards datasheets to europeri members? +09:32 < wsa> no PSCI? we need a proper reboot, then +09:33 < marex> geertu: you mean ARM Linux people won't accept a system which does not run ARM BSD-licensed firmware +09:33 < marex> geertu: sounds to me like there is incentive on both sides to force that BSD-licensed firmware onto you +09:34 < marex> wsa: PSCI isnt only about reboot, but also about bringing up secondary CPU cores +09:34 < marex> wsa: and I would highly recommend keeping it at that +09:34 < wsa> marex: yes, but that is stuff for core ;) +09:34 < shimoda> marex: v3u will boot from "ICUMXA" cpu core. and the cpu kicks cortex-A cpu0 +09:34 < marex> wsa: anything beyond that, like power domains ... uuuurgh +09:34 < geertu> marex: PSCI is just a spec, so you can provide your own inmplementation? +09:34 < wsa> why is there no PSCI on v3u? +09:34 < marex> geertu: and the "only up to date implementation" is by whom ? +09:35 < marex> geertu: U-Boot implements only PSCI 0.2 I think, and on Gen3 the TFA already installs the handlers +09:35 < marex> wsa: there likely is ? +09:35 < moriperi> shimoda: I think I already did +09:35 < marex> shimoda: is it using the CR7 loader ? +09:36 < marex> shimoda: was that why you asked me about it some time ago ? +09:36 < marex> shimoda: or is that something else entirely ? +09:37 < wsa> seems we already switched to core +09:37 < wsa> is there something left to discuss for IO +09:37 < wsa> ? +09:37 < geertu> wsa: Shall we make that official? +09:37 < geertu> Next meeting? +09:38 < wsa> okay, then, this time a on-the-fly-mic-takeover, geertu have fun! +09:38 < geertu> Oct 29? (conflicts with KVM Forum, anyone who cares?) +09:38 < wsa> Oct, 29th? +09:39 < kbingham> Not much else after ELCE I guess ;-) +09:39 < shimoda> marex: CR7 loader is used on V3H. But, it seems local code. So, i'm thinking we should not use it on V3U because it's difficult to maintain such local code by ourselve. +09:40 < shimoda> i will take a day off at oct 29... +09:40 < kbingham> (seems marex is in the promo background for elce : https://events.linuxfoundation.org/embedded-linux-conference-europe/) +09:40 < moriperi> shimoda: oops, not shared ? +09:41 < marex> shimoda: then I need to read up on ICUMXA :) +09:41 < geertu> v850? +09:41 < geertu> Welcome to today's Core Group Chat Meeting! +09:41 < wsa> Nov, 5th is also fine for me +09:42 < geertu> nov 5 is fine forme +09:42 < marex> kbingham: michal simek (xilinx) is on the left side, same row, black shirt with some "blah code blah" writing on it +09:42 < geertu> Note that EU wil have switched to Winter Time by then +09:42 < geertu> marex: And he fancies the camera person? +09:43 < marex> geertu: heh +09:43 < geertu> Agenda: +09:43 < geertu> 1. Status Updates +09:43 < geertu> 2. Discussion Topics +09:43 < geertu> Topic 1. Status updates +09:43 < geertu> A) What have we done since last time: +09:43 < geertu> Kieran got local patchwork bot instances to run. +09:43 < geertu> Marek fixed parsing multiple memory nodes in U-Boot and OpTee-OS, +09:43 < geertu> assisted Renesas UK with RZ/G2 U-Boot support, and investigated and +09:43 < geertu> fixed PCIe L1 link state recovery on R-Car Gen2. +09:43 < geertu> Morimoto-san tried to control ULCB power/reset by GPIO. +09:43 < geertu> Niklas posted VIN stf8 PFC patches. +09:43 < geertu> Shimoda-san submitted R-Car V3U initial support and got the +09:43 < geertu> corresponding SoC and board manuals. +09:43 < geertu> Geert reviewed RZ/G and R-Car V3U patches, consolidated renesas-pinctrl, +09:43 < geertu> and sent the second batch of pull requests for v5.10. +09:44 < geertu> B) What we plan to do till next time: +09:44 < geertu> Marek plans to continue helping with RZ/G2 U-Boot patch review, and +09:44 < geertu> submit v3 of the PCIe L1 link state recovery patch. +09:44 < geertu> Morimoto-san plans to try to control power/reset on the Salvator-XS and +09:44 < geertu> Kingfisher boards. +09:44 < geertu> Niklas plans to post v2 of the VIN stf8 PFC patchset. +09:44 < geertu> Shimoda-san plans to correct more information about R-Car Gen3e, and may +09:44 < geertu> work on more support for R-ar V3U. +09:44 < geertu> Geert plans to develop v10 of obtaining the start of physical memory +09:44 < geertu> from DTB, and attend and present at virtual ELC-E. +09:45 < geertu> C) Problems we have currently: +09:45 < geertu> Marek wonders if we can tell RZ/G2 apart from R-Car Gen3. +09:45 < geertu> ---EOT--- +09:45 < geertu> Anything I missed? +09:46 < geertu> moriperi: Please have a look at +09:46 < geertu> https://elinux.org/R-Car/Boards/Salvator-XS#Remote_Control +09:46 < geertu> Note that you can change power switch behavior (Salvator-X(S) defaults +09:46 < geertu> to Level, ULCB to Pulse), by changing the resistors (R413/R424) that +09:46 < geertu> control the PMIC's RSTBMODE configuration. +09:46 < geertu> With KingFisher attached, it's different, as ULCB is powered from +09:46 < geertu> KingFisher, IIRC. +09:46 < geertu> Topic 2. Discussion Topics +09:46 < marex> geertu: well, Marek also wonders about the V3U boot process +09:46 < marex> geertu: with ULCB you can use cpld-control too +09:48 < moriperi> geertu: thanks +09:51 < geertu> So Topic 1. R-Car V3U already started +09:51 < geertu> No PSCI +09:51 < marex> geertu: thats just weird +09:51 < geertu> Booted from ICUMXA +09:51 < marex> well, what is running on the ICUMXA, some custom preloader or what ? +09:51 < marex> and then it starts -- what -- on the cortexA ? +09:52 < marex> geertu: have you seen the V3U booting ? +09:53 < shimoda> marex: yes, custom preloader is running on the ICUMXA. and, perhaps the preloader will not be in public +09:53 < shimoda> marex: and it starts u-boot on the cortexA +09:53 < geertu> According to Ch. 19 ("Boot"), it can boot from Cortex-R52 or ICUMXA +09:53 < marex> shimoda: please dont do that, you are gonna turn it into unpopular horribleness like the imx8q* and its SCFW +09:54 < marex> shimoda: that is also a huge blob without public sources and there isn't much joy about that +09:56 < shimoda> marex: hmm, renesas plans such boot sequence on R-Car Gen4 SoCs too... +09:56 < marex> shimoda: is there any specific problem in opening the ICUMXA code ? +09:57 < marex> shimoda: so anyway, it starts u-boot on the cortexA, and then U-Boot runs in EL3 , and U-Boot starts Linux ? +09:57 < marex> shimoda: so no TFA involved ? +09:58 < marex> shimoda: to bring up the secondary cores, U-Boot does implement enough of the PSCI API, so if we can avoid ATF here, good +09:58 < shimoda> marex: the boot sequence is correct. but, as you said, we need PSCI somewhere fore reboot, SMP and so on +09:58 < marex> shimoda: so why no ATF this time ? +09:59 < geertu> marex: So what's the problem with PSCI? Reboot only? +09:59 < marex> geertu: Linux on aarch64 uses PSCI to bring up secondary cores +09:59 < marex> geertu: reboot is kinda secondary +09:59 < marex> as in, reboot is "extra" +09:59 < shimoda> marex: i don't know why renesas will not open ICUMXA code in public. +09:59 < geertu> marex: marex said "to bring up the secondary cores, U-Boot does implement enough of the PSCI API" +10:00 < geertu> So? +10:00 < marex> geertu: yeah, so, you can have U-Boot behave as the PSCI firmware counterpart and bring the secondary cores up +10:00 < shimoda> marex: i think it's just renesas internal software resource problem. on Gen3, IPL team develops ATF. But, now IPL team develops ICUMXA loader. +10:01 < shimoda> Linux BSP team develops uboot on both Gen3 and V3U. +10:01 < marex> shimoda: yikes :) +10:02 -!- moriperi [~user@relprex1.renesas.com] has quit [Read error: Connection reset by peer] +10:02 < geertu> bummer, parental control has offlined moriperi? +10:02 < shimoda> marex: :) +10:02 < marex> shimoda: but I guess, if you look at it, the V3M/V3H CR7 loader was some sort of pre-ICUMXA loader +10:02 < marex> shimoda: so things were headed in that direction anyway +10:02 < marex> for a longer time no less +10:03 < marex> except V3M/V3H also have ATF port +10:03 -!- moriperi [~user@relprex1.renesas.com] has joined #periperi +10:03 < marex> so either there will be ATF port similar to those V3H (which is a bit of a thin shim sandwiched between the CR7 loader and U-Boot), or its really only gonna be U-Boot +10:04 < marex> maybe thats what should be double-checked +10:04 < marex> I would prefer the later of course +10:04 < marex> then we can add the PSCI callbacks to U-Boot , drop EL and boot Linux , without ATF, that would be nice +10:04 * pinchartl wonders how many (pre-/early-)boot loader stages a platform really need +10:05 < kbingham> pinchartl, It's turtles all the way down ... no wait - that'ssomething else ;-) +10:05 < marex> pinchartl: more than we have, just look at intel +10:05 < marex> kbingham: nice +10:06 < wsa> pinchartl: I think this correlates exactly to the number which SoC generation it is +10:06 * geertu thinks Super-H and RISC-V early stages are missing +10:07 < marex> shimoda: so, maybe we still need to flesh the boot process out ? :) +10:07 -!- kbingham[m] [kbinghamma@gateway/shell/matrix.org/x-tqvvdwyhjxnfmmxl] has joined #periperi +10:09 < shimoda> marex: sorry i could not understand "flesh" +10:09 < geertu> sort out +10:09 < marex> shimoda: flesh == meat +10:09 < marex> shimoda: what you are made of +10:09 < marex> shimoda: flesh out == sort out +10:10 < wsa> I also didn't know this expression +10:10 < shimoda> marex: ah, i got it. yes, i think so :) +10:10 < marex> geertu: would that translate as 肉-out ? :-) +10:12 < geertu> Anything else to discuss? +10:12 < marex> shimoda: can you check about the PSCI and ATF internally please ? +10:12 < marex> shimoda: it would be good to confirm, otherwise, well, we can start adding the PSCI bits into U-Boot unless renesas did already +10:12 < marex> shimoda: or how else do you test the secondary core bringup ? +10:13 < shimoda> marex: for now, bsp team and i don't test the secondary core bringup. +10:14 < marex> shimoda: oh, ok +10:16 < geertu> I think it's time to pass the torch^Wmic to MM +10:16 < geertu> Thanks for joining, and have a nice continued day! +10:16 < geertu> pinchartl: mic +10:16 < marex> shimoda: I am now looking at the U-Boot port for V3U, there isn't much, that's real cool :) +10:16 < marex> ttyl, stay healthy +10:17 < geertu> marex: where is the U-Boot port? +10:17 < marex> geertu: https://github.com/renesas-rcar/u-boot.git diff --git a/wiki/Chat_log/20201001-io-chatlog b/wiki/Chat_log/20201001-io-chatlog new file mode 100644 index 0000000..dc6588b --- /dev/null +++ b/wiki/Chat_log/20201001-io-chatlog @@ -0,0 +1,110 @@ +09:06 < wsa> welcome to the IO meeting! +09:06 < wsa> here are the status updates: +09:06 < wsa> Status updates +09:06 < wsa> ============== +09:06 < wsa> A - what have I done since last time +09:06 < wsa> ------------------------------------ +09:06 < wsa> Geert +09:06 < wsa> : posted next version of binding for Ethernet MAC explicit internal delay setting, investigated ravb s2ram regression, investigated MSIOF CS deassert delay, verified R-Car E3 MSIOF DMA erratum, tested R-Car Gen2 PCIe s2ram fix +09:06 < wsa> Marek +09:06 < wsa> :investigate L1 link state recovery with PCIe on Gen2, sent patches +09:06 < wsa> Shimoda-san +09:06 < wsa> : forwarded and assisted with various SDHI problems from the BSP team, resent fix for Ethernet PHYs, worked to fix a DMA issue with the SATA driver +09:06 < wsa> Ulrich +09:06 < wsa> : sent new revisions of IIC atomic transfer patches, discussed the DA9063 PM patches for the WDT with maintainer, reviewed patches +09:06 < wsa> Wolfram +09:06 < wsa> : upstreamed SMBus emulation binding and core HostNotify support, updated and upstreamed R-Car support for HostNotify and I2C slave testunit, resent patch to support WDT handover from bootloader, removed unused SDHI stp_ck handling from Gen3 CPG, created series to handle TAP_EN on SDHI reset including some more SDHI cleanups, reviewed some SDHI patches coming from upstream, sent +09:06 < wsa> improvements to MMC core on and SDHI the way, started debugging a regression when re-inserting SD cards +09:06 < wsa> B - what I want to do until next time +09:06 < wsa> ------------------------------------- +09:06 < wsa> Marek +09:06 < wsa> : wants to subit new patch for L1 link state recovery with PCIe on Gen2 +09:06 < wsa> Shimoda-san +09:06 < wsa> : wants to convert rcar-pci dt doc to json-schema, correct information about R-Car Gen3e, do more R-Car V3U support +09:06 < wsa> Ulrich +09:06 < wsa> : wants to implement atomic transfers for i2c-rcar +09:06 < wsa> Wolfram +09:06 < wsa> : wants to fix the SD card re-insertion regression, send out the SDHI TAP_EN series after that, retest and apply Uli's IIC patch for atomic transfers, work on further SDHI issues (max_busy_timeout) which Shimoda-san reported, guide increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support +09:07 < wsa> Skipping C) because nobody has problems ;) +09:07 < wsa> geertu: did the investigations (s2ram and MSIOF CS) result in something? +09:08 < wsa> geertu: and did you verify the DMA errata exists or it has been fixed properly? +09:08 < geertu> wsa: ravb regression cause was reverted +09:08 < geertu> wsa: msiof investigation was to be relayed back to customer +09:09 < geertu> 77972b55fb9d35d4 ("Revert "ravb: Fixed to be able to unload modules"") +09:11 < wsa> geertu: so, Ashizuka-san from Fujitsu needs to work on a better patch then +09:11 < wsa> ? +09:12 < geertu> wsa: The reverted patch was a temporary fix anyway +09:12 < geertu> Davem hinted to a proper solution in https://lore.kernel.org/linux-renesas-soc/20200820.165244.540878641387937530.davem@davemloft.net/ +09:12 < wsa> uli__: I thought I already replied to Guenter as well (increasing the pressure) but I overlooked it in my draft folder. +09:12 < wsa> uli__: will send it out later +09:12 < geertu> That is a solution for the MDIO subsystem +09:13 < wsa> geertu: that is a real homework for Fujitsu then :) +09:14 < uli__> ok, thx +09:14 < geertu> wsa: Indeed (no response from Fujitsu so far, was his/her's first patch) +09:16 < wsa> okay, other questions/comments from your side? +09:16 < wsa> JapaPERI? +09:16 < marex> wsa: btw you did the SCIF rework recently , didnt you +09:16 < marex> wsa: did you test break/sysrq ? +09:16 < marex> (meta-f in minicom) +09:16 < wsa> shimoda: I will work on the SDHI issues one after the other +09:17 < shimoda> wsa: i got it. thanks! +09:17 < wsa> marex: I can't recall when I touched SCIF the last time +09:17 < marex> wsa: might've been someone else then +09:17 < geertu> marex: Do we need https://patchwork.kernel.org/project/linux-renesas-soc/list/?q=sh-sci&series=&submitter=&state=&archive= ? +09:17 < wsa> marex: I think it was uli__ who did the last bigger changes there? And geertu taking care of the occasional fixes? +09:18 < uli__> i didn't do anything recently, though +09:18 < marex> geertu: isnt that for earlycon only ? +09:18 < wsa> shimoda: and no worries, just bring them up. SDHI is nasty one, we all know that :) +09:19 < wsa> uli__: yes, it was not really "recently" +09:19 < wsa> marex: why the question +09:19 < wsa> ? +09:19 < geertu> marex: Oh, the second one is obsolete since dc9a325426f1113e ("tty/serial: Migrate sh-sci to use has_sysrq") +09:19 < marex> geertu: uli__: there was something like a timeout when you send sysrq(break)-B to reboot the machine +09:20 < geertu> "Unfortunately magic SysRq only works if CONFIG_SERIAL_SH_SCI_DMA=n. +09:20 < geertu> " +09:20 < shimoda> wsa: :) +09:20 < marex> geertu: maybe something to improve then ? +09:22 < geertu> marex: Actually all new people who enter the team are supposed to work a bit on SCIF (no joke, look at "git log"!). Have you served your time already? ;-) +09:22 < marex> geertu: does uboot and qemu count ? +09:23 < wsa> okay, now that sounds like an action item +09:23 < wsa> "make SysRq work with DMA=y" +09:24 < geertu> I think you can't detect BREAK when using DMA +09:24 < geertu> same for parity errors +09:25 < wsa> shimoda: about v3u, when you say that an IP core needs just "// DT-only" updates: did you check datasheets already or is it your guess based on other information you have so far? +09:26 < wsa> geertu: I wonder if other IP cores can do that +09:26 < wsa> geertu: seems like this needs investigation first? +09:27 < shimoda> wsa: it's my guess based +09:28 < marex> shimoda: are there any plans to push out sources for the bootloaders items, tfa, uboot ? +09:28 < wsa> shimoda: ok, so, the first task is exactly that, to check datasheets +09:28 < wsa> our V3U datasheet is from July 2020 +09:31 < geertu> but we still lack the board documentation, to check what we can test? +09:31 < shimoda> marex: i'd like to support u-boot for v3u at least. but, if so, we cannot support PSCI. So, perhaps, we also should support atf? Or, u-boot only is enough? +09:31 < wsa> it is "best effort" for now as I understood it +09:32 < marex> shimoda: we can do both +09:32 < shimoda> ah, i also got boards datasheets. +09:32 < geertu> Note that upstream won't accept arm64 SMP support that does not use PSCI +09:32 < marex> shimoda: isnt v3u booting via tfa/uboot anyway ? +09:32 < shimoda> moriperi: could we share boards datasheets to europeri members? +09:32 < wsa> no PSCI? we need a proper reboot, then +09:33 < marex> geertu: you mean ARM Linux people won't accept a system which does not run ARM BSD-licensed firmware +09:33 < marex> geertu: sounds to me like there is incentive on both sides to force that BSD-licensed firmware onto you +09:34 < marex> wsa: PSCI isnt only about reboot, but also about bringing up secondary CPU cores +09:34 < marex> wsa: and I would highly recommend keeping it at that +09:34 < wsa> marex: yes, but that is stuff for core ;) +09:34 < shimoda> marex: v3u will boot from "ICUMXA" cpu core. and the cpu kicks cortex-A cpu0 +09:34 < marex> wsa: anything beyond that, like power domains ... uuuurgh +09:34 < geertu> marex: PSCI is just a spec, so you can provide your own inmplementation? +09:34 < wsa> why is there no PSCI on v3u? +09:34 < marex> geertu: and the "only up to date implementation" is by whom ? +09:35 < marex> geertu: U-Boot implements only PSCI 0.2 I think, and on Gen3 the TFA already installs the handlers +09:35 < marex> wsa: there likely is ? +09:35 < moriperi> shimoda: I think I already did +09:35 < marex> shimoda: is it using the CR7 loader ? +09:36 < marex> shimoda: was that why you asked me about it some time ago ? +09:36 < marex> shimoda: or is that something else entirely ? +09:37 < wsa> seems we already switched to core +09:37 < wsa> is there something left to discuss for IO +09:37 < wsa> ? +09:37 < geertu> wsa: Shall we make that official? +09:37 < geertu> Next meeting? +09:38 < wsa> okay, then, this time a on-the-fly-mic-takeover, geertu have fun! diff --git a/wiki/Chat_log/20201105-core-chatlog b/wiki/Chat_log/20201105-core-chatlog new file mode 100644 index 0000000..fcdf4d9 --- /dev/null +++ b/wiki/Chat_log/20201105-core-chatlog @@ -0,0 +1,125 @@ +09:41 <@geertu> Welcome to today's Core Group Chat Meeting! +09:41 <@geertu> Agenda: +09:41 <@geertu> 1. Status Updates +09:41 <@geertu> 2. Discussion Topics +09:41 <@geertu> Topic 1. Status updates +09:41 < damm> geertu: when you have time, please let me know which zip file to + look at +09:41 -!- Irssi: Pasting 11 lines to #periperi-ng. Press Ctrl-K if you wish to + do this or Ctrl-C to cancel. +09:41 <@geertu> A) What have we done since last time: +09:41 <@geertu> Marek worked on U-Boot (DM remove late, helping Renesas UK with + RZ/G2) +09:41 <@geertu> and Linux (PCI L1 link state recovery on Gen2, 32-bit PCI MSI + address +09:41 <@geertu> allocation). +09:41 <@geertu> Morimoto-san worked on the Renesas remote access system and on +09:41 <@geertu> V3U-Falcon initialization. +09:41 <@geertu> Shimoda-san submitted the rcar-usb2-clock-sel json-schema + conversion. +09:41 <@geertu> Ulricht worked on V3U PFC support and reviewed patches. +09:41 <@geertu> Geert worked on merge window regressions, +09:41 <@geertu> R-Car V3U GPIO support, GPIO and PFC cleanups and improvements, + and +09:41 <@geertu> attended and presented at virtual ELC-E. +09:42 -!- Irssi: Pasting 10 lines to #periperi-ng. Press Ctrl-K if you wish to + do this or Ctrl-C to cancel. +09:42 <@geertu> B) What we plan to do till next time: +09:42 <@geertu> Marek plans to continue helping with RZ/G2 U-Boot patch review. +09:42 <@geertu> Morimoto-san plans to do paperwork for V3U shipping. +09:42 <@geertu> Niklas plans to post v2 of the VIN stf8 PFC patchset. +09:42 <@geertu> Shimoda-san plans to collect more information about R-Car + Gen3e, and +09:42 <@geertu> want to add BD9574 support for Ebisu-4D board, depending on + hardware +09:42 <@geertu> availability. +09:42 <@geertu> Ulrich plans to send V3U PFC support. +09:42 <@geertu> Geert plans to test GPIO on R-Car V3U, send pull requests for + v5.11, and +09:42 <@geertu> develop v10 of obtaining the start of physical memory from DTB. +09:44 <@geertu> C) Problems we have currently: +09:44 <@geertu> Morimoto-san needs to remind board shipping process. +09:44 <@geertu> Geert is subject to partial lockdown. +09:44 <@geertu> ---EOT--- +09:44 <@geertu> Anything I missed +09:44 <@geertu> ? +09:44 < damm> geertu: never mind, falcon schematics are included in gen3 bundle +09:44 < jmondi> geertu: CPG clocks for CSI-2/VINs +09:44 <@geertu> marex: What is " DM remove late U-Boot patch,add test.py test"? +09:45 < marex> geertu: the thing which allows u-boot to tear down SDHI first, + clock second, instead of the other way around +09:45 <@geertu> jmondi: sorry, thx +09:45 < marex> geertu: unlike linux, the dm is simple and doesnt have real + dependency tracking between drivers +09:46 < marex> geertu: well and test.py test for that code is the test which + runs on every git push +09:46 <@geertu> marex: Sounds better than Linux, where the DM is complex, and + doesnt have real dependency tracking between drivers +09:46 < marex> geertu: linux has some, uboot has none +09:46 < jmondi> geertu: no worries +09:48 <@geertu> shimoda: IIUIC, our Ebisu-4D still has BD9571? +09:49 < morimoto> shimoda: thank you the V3U picture. I will add it to PeriJect + V3U-Falcon page. +09:50 < shimoda> geertu: yes. However, according to board team, latest Ebisu-4D + has BD9574. +09:50 <@geertu> damm: They forgot to solder the CAN connectors (CN1) +09:51 <@geertu> and GPIO CN (CN4), next to it +09:51 <@geertu> CN5/6 are populated, though +09:52 < marex> shimoda: so there is now Ebisu-4D-NG with BD9574 +09:52 < marex> shimoda: and Ebisu-4D-TOS with BD9571 +09:52 < damm> @geertu: on Falcon breakout let me know if you need me to solder + =) +09:52 < shimoda> marex: yes. +09:53 <@geertu> damm: How are your soldering skills? ;-) +09:53 < marex> the bd9571 has a product ID register, so we might be able to + avoid DT hackery and discern the chip that way instead +09:54 < shimoda> geertu: sorry, the pictures may be old, especially, the board + doesn't have AVB0 connector :) +09:54 <@geertu> marex: Yes +09:54 <@geertu> shimoda: OK. +09:54 <@geertu> Topic 2. Discussion Topics +09:55 < damm> geertu: let me know which connector you are interested in and i + will let you know +09:55 < marex> shimoda: is there 9574 datasheet available yet ? :) +09:56 < damm> geertu: when i was in my 20's i did solder lqfp +09:57 < pinchartl> geertu: discussion topic: moving to #periperi-ng permanently + ? +09:57 < shimoda> marex: i could get the datasheet, but i could not get to allow + permission to share the datasheet for now... +09:57 < pinchartl> I've kicked Conny40 +09:58 < pinchartl> but we have mturquette and ltds lurking too +09:59 < marex> shimoda: OK +09:59 < shimoda> so, i intend to submit a patch from me +09:59 < shimoda> if i got a board +09:59 < marex> shimoda: sounds good +09:59 <@geertu> damm: Do mturquette and ltds still have a need to use #periperi? +10:01 <@geertu> pinchartl: You're op, so you can make #periperi invite only? +10:03 < damm> @geert: i don't think so +10:03 < pinchartl> I can, but kicking mturquette and ltds isn't a very nice move +10:03 <@geertu> We can ask, politely? +10:03 < damm> agreed +10:03 < pinchartl> we should either ask them to leave, or move silently to a + different channel +10:04 < wsa> I vote for asking +10:04 < wsa> we can still leave if there is no response +10:05 < pinchartl> wsa: fine with me. wanna ask ? :-) +10:06 < pinchartl> geertu: I've just given you full permission to manage + #periperi through chanserv +10:07 <@geertu> pinchartl: thx +10:07 <@geertu> I'll ask them +10:07 <@geertu> Anything else for Core to discuss? +10:07 <@geertu> Next meeting? +10:08 < wsa> pinchartl: sure +10:08 <@geertu> Nov 26th? Dec 3th? +10:08 < wsa> Dec 03 is in the middle of virtual OSSJ +10:08 <@geertu> The latter coincides with OSS-JP (anyone plans to (virt)attend?) +10:09 < morimoto> geertu: I will +10:09 <@geertu> JP timezone, a bit hard for EU +10:09 < shimoda> geertu: i will attend +10:09 <@geertu> morimoto: shimoda: Enjoy! +10:09 < morimoto> thx +10:09 < wsa> maybe 26th to update ourselves with V3U? +10:10 <@geertu> Yeah, good reason to not wait too long +10:10 < shimoda> +1 +10:11 <@geertu> OK, 26th it'll be +10:11 <@geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20201105-io-chatlog b/wiki/Chat_log/20201105-io-chatlog new file mode 100644 index 0000000..e1b397f --- /dev/null +++ b/wiki/Chat_log/20201105-io-chatlog @@ -0,0 +1,129 @@ +09:05 < wsa> so, welcome to this IO meeting +09:05 < wsa> I hope you are all healthy! +09:05 < morimoto> Thanks +09:05 < neg> So does this mean we will decommission #periperi and move here? +09:05 < wsa> first status updates, then questions +09:06 < wsa> neg: i'd think only for meetings? +09:06 < wsa> Status updates +09:06 < wsa> ============== +09:06 < wsa> A - what have I done since last time +09:06 < wsa> ------------------------------------ +09:06 < wsa> Geert +09:06 < wsa> : enabled and tested MSIOF on R-Car M3-W+ and marked i2c-sh_mobile adapter suspended during suspend +09:06 < wsa> Marek +09:06 < wsa> : sent V2 of L1 link state recovery for Gen2 PCIe, sent a patch allocating PCI MSI address in 32bit space +09:06 < wsa> Niklas +09:06 < wsa> : did initial experimentation with CMT and TMU timers +09:06 < wsa> Shimoda-san +09:06 < wsa> : converted PCI host binding to JSON, improved power off notification in the MMC core, developed R-Car S4 Ethernet driver for Linux +09:06 < wsa> Wolfram +09:06 < wsa> : enjoyed two weeks of holiday and attended virtual ELCE, researched V3U differences of IO devices, created and discussed tasks for V3U enablement, fixed SD card re-insertion regression and other issues reported by Shimoda-san, debugged another stalled SCC issue when reading EXT_CSD occasionally fails on his H3 ES2.0, retested and applied Uli's IIC patch for atomic transfers, sent +09:06 < wsa> RFC to fix scheduling while atomic in WDT driver +09:06 < wsa> B - what I want to do until next time +09:06 < wsa> ------------------------------------- +09:06 < wsa> Geert +09:06 < wsa> : wants to enable and test MSIOF on R-Car V3U +09:06 < wsa> Shimoda-san +09:06 < wsa> : wants to collect more information about R-Car Gen3e, continue to develop R-Car S4 Ethernet driver +09:06 < wsa> Wolfram +09:06 < wsa> : wants to enable and test V3U IO devices, send out the SDHI TAP_EN series after all known issues are fixed, work on further SDHI issues (max_busy_timeout), guide increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support for it, resend WDT patch to fix scheduling while atomic +09:06 < wsa> C - problems I currently have +09:06 < wsa> ----------------------------- +09:06 < wsa> None +09:07 < wsa> so, geert just answered my question what "S4" is in this mail a minute ago +09:08 < wsa> shimoda: I still wonder what "Gen3e" is? also, new SoCs? +09:08 <@geertu> wsa: Nah, Google did +09:08 < wsa> neg: in your B) section, shouldn't there be timers as well? ;) +09:08 < neg> wsa: Yes it should ;-) +09:09 < shimoda> wsa: like RZ/G2 SoCs, just re-modeling SoCs of R-Car Gen3 +09:09 < wsa> uli___: do you still work on atomic patches for i2c-rcar? or is your base time all eaten up? +09:10 < wsa> shimoda: so, except for new DTS files, not much enablement expected? +09:10 < shimoda> it's improving bussiness area, but technical area especiialy linux / dt seems to be complex... +09:10 -!- kbingham [~kbingham@core.do.nakedgeek.co.uk] has joined #periperi-ng +09:10 < uli___> wsa: yes, it's still on the list. i basically left that aside while the sh variety is still in progress. since that has been merged now, i'll go ahead with rcar +09:11 <@geertu> shimoda: basically it extends the RZ/G2 CPU operating points to the R-Car Gen3 range? +09:11 < wsa> shimoda: okay, let's wait until you have more information +09:11 -!- jmondi [~jmondi@250.ip-164-132-57.eu] has joined #periperi-ng +09:11 < shimoda> wsa: in theory of device tree bindings, if we have a new SoC part number, we have to make new bindings +09:11 < wsa> uli___: great, thanks! +09:12 < wsa> shimoda: yes. although most IP cores have a generic "gen3" binding, or? So, we mainly need to update to bindings documentation and not so much the drivers +09:12 < shimoda> @geertu: yes, V3H and V3M are out-of-scope of Gen3e +09:13 < wsa> so, that's it from my side for the status infos... +09:13 < wsa> the big question I have is obviously about V3U in Magnus' lab :) +09:14 < shimoda> wsa: you're right. however, Gen3e plans overclock. So, we may need to modify cpg driver for Gen3e +09:14 < wsa> any news on that? +09:14 < wsa> shimoda: ah, okay. +09:15 < damm> did someone say Falcon? +09:15 < morimoto> V3U is now under paper work process for shipping :) +09:15 < shimoda> wsa: ah, I got information from magnus-san about v3u remote lab, but I don't try yet +09:15 < wsa> morimoto, the export paper work warrior strikes back! +09:16 < damm> I suspect it is broken because it does not make any sound +09:16 < morimoto> wsa: :) +09:17 < damm> just power switch relays clicking +09:17 <@geertu> damm: is the fan an add-on board? +09:17 < wsa> damm: no LEDs? +09:18 < morimoto> geertu: very big FAN is added +09:18 <@geertu> damm: Do you need to talk to the RL78 to power it on? +09:19 < marex> computer, turn on the falcon ... unable to comply ? +09:19 < damm> everything seems fine what i can tell +09:20 < kbingham> marex, don't forget to use 'sudo' +09:20 < damm> i got a list of users from Renesas side +09:20 < damm> so the ssh permissions are already adjusted +09:20 < damm> exactly how to time share it is a different question +09:21 < wsa> morimoto: https://thumbs.dreamstime.com/z/superhero-long-cloak-mask-business-character-vector-illustration-guy-holds-hands-large-paper-piles-superhero-long-180946696.jpg +09:22 <@geertu> wsa: Please don't demotivate morimoto-san, or we'll never get boards ;-) +09:22 < damm> morimoto-san and shimoda-san, may I disclose the port number? +09:22 < wsa> well, once the upstream kernel runs, first thing would be PFC? +09:22 < wsa> geertu: morimoto is hero, he will manage +09:22 < morimoto> wsa: yeah, superhero :) +09:23 <@geertu> wsa: right, he is supermanager, and will superhero ;-) +09:24 <@geertu> wsa: and GPIO? Both are a bit tied together +09:24 < shimoda> damm: yes, please +09:24 < wsa> geertu: sure +09:24 < damm> 9018 +09:24 < shimoda> now I'm trying to use the remote Falcon board +09:25 <@geertu> damm: What happened to the Alix on that port? +09:25 < wsa> from IO side, I will wait with testing until you give me a go with initial PFC and GPIO +09:26 < morimoto> If you have chance to access "physical" Falcon access, some information abiout V3U from me is that 1) CPU FAN will start works if the degree was over 90. 2) USB debug serial will indicate 2 ttyUSBx. +09:26 < shimoda> and, my kernel image could run on the v3u. magnus-san, thank you very much for your support! +09:26 < wsa> damm: did you also get breakout connectors? so we can wire some lines together on EXIOx? +09:27 <@geertu> shimoda: Great! +09:28 < marex> I guess I'll let the kernel people do their business first, then start on the bootloader work on falcon ? +09:28 < marex> meanwhile, there is plenty of rzg2 patches coming in for review ... heh +09:28 < morimoto> I had updated PeriJect for Falcon +09:29 -!- pinchartl [~laurent@perceval.ideasonboard.com] has joined #periperi-ng +09:30 < shimoda> marex: i intend to ship a board to you in Q4. so you are able to develop a boot loader on physical board +09:30 < marex> shimoda: ooooh, thank you +09:31 <@geertu> wsa: Aren't the EXIOx connectors used to connect the different parts of the Falcon board stack? +09:32 < wsa> but can't we wire them if there is no further stack? +09:32 <@geertu> We do have GPIO CN and the MSIOF[12] PIN HEADERs +09:32 < damm> sorry guys no breakout connectors +09:32 < damm> there are some pins exposed to regular pin headers +09:32 <@geertu> damm: Can you wire MSIOF1 RXD to TXD (CN5 pin 5 to 6)? These are 2.54mm headers, according to the schematics +09:34 <@geertu> GPIO CN is 1.27mm +09:34 <@geertu> damm: BTW, do you have a picture of the Falcon? +09:35 < wsa> are there other IO related questions? +09:35 < wsa> otherwise I suggest to move to core +09:35 < marex> wsa: well, PCI +09:35 < damm> Falcon is a bit confusing because CPU board and break out board use same CN names +09:36 < damm> for different purposes +09:36 <@geertu> damm: I meant on the Breakout board +09:36 < damm> CN5 on the break out board - let me try to find it +09:36 <@geertu> CN6 is fine, too (that's MSIOF2) +09:36 < wsa> marex: shoot +09:36 < damm> yeah I can do it right away if you need to +09:37 < marex> wsa: just curious what the news are +09:37 <@geertu> damm: It's not urgent. +09:37 < wsa> marex: you mean PCI on V3U? +09:37 < marex> yep +09:37 < shimoda> geertu: i have pictures board team took. I'll send to periperi ML +09:38 < wsa> marex: I haven't heard anything new, so I still consider it broken +09:38 <@geertu> shimoda: thank you +09:38 < wsa> maybe JapaPERI knows more? +09:39 < shimoda> wsa: marex: hardware team prepared workaround and BSP team is trying to implement it. But, I don't know the current status +09:39 < shimoda> I'll ask BSP team later +09:39 < damm> where can i find the pin out of CN5 and CN6? I've browsed the board docs and information is quite sparse +09:39 < marex> shimoda: nice +09:39 <@geertu> damm: R-CARV3U_BREAKOUTBOARD_REV100.pdf p9 +09:40 < wsa> then, let's move to core? +09:40 <@geertu> fine for me diff --git a/wiki/Chat_log/20201126-core-chatlog b/wiki/Chat_log/20201126-core-chatlog new file mode 100644 index 0000000..ca239c4 --- /dev/null +++ b/wiki/Chat_log/20201126-core-chatlog @@ -0,0 +1,111 @@ +09:43 <@geertu> Welcome to today's Core Group Chat Meeting! +09:43 <@geertu> Agenda: +09:43 <@geertu> 1. Status Updates +09:43 <@geertu> 2. Discussion Topics +09:43 <@geertu> Topic 1. Status updates +09:44 <@geertu> A) What have we done since last time: +09:44 <@geertu> Marek worked on U-Boot (late clock drivers removal) and TFA (BL31 +09:44 <@geertu> logging fix). +09:44 <@geertu> Morimoto-san continued V3U-Falcon shipping paper work. +09:44 <@geertu> Niklas posted VIN "g8" pin control patches. +09:44 <@geertu> Shimoda-san submitted the rcar-usb2-clock-sel json-schema conversion. +09:44 <@geertu> Ulrich finished porting V3U pin control from the BSP. +09:44 <@geertu> Geert tested GPIO on R-Car V3U, fixed R and OSC clocks on R-Car V3U, +09:44 <@geertu> removed static I/O mappings from mach-shmobile, sent first batch of pull +09:44 <@geertu> requests for v5.11, and studied the early ARM compressed boot flow, +09:44 <@geertu> fixing large kernels on Koelsch. +09:44 <@geertu> B) What we plan to do till next time: +09:44 <@geertu> Marek is considering to revisit the U-Boot PSCI implementation. +09:44 <@geertu> Morimoto-san plans to continue doing V3U-Falcon paperwork, and do +09:44 <@geertu> Renesas work. +09:44 <@geertu> Shimoda-san plans to collect more information about R-Car Gen3e, +09:44 <@geertu> add BD9574 support for Ebisu-4D board (depending on hardware +09:44 <@geertu> availability), and attend OSSJ + ALS2020. +09:44 <@geertu> Ulrich plans to post V3U pin control support. +09:44 <@geertu> Geert plans to send the second batch of pull requests for v5.11, +09:44 <@geertu> complete R-Car V3U gpio-pinctrl integration, and develop v10 of +09:44 <@geertu> obtaining the start of physical memory from DTB. +09:44 <@geertu> C) Problems we have currently: +09:44 <@geertu> None. +09:45 <@geertu> ---EOT--- +09:45 <@geertu> Anything I missed? +09:45 <@geertu> Looks like we're on track regarding R-Car v3U support? +09:46 < wsa> uli__: when do you plan to post the PFC driver? +09:46 < uli__> i'll try to do it today. tomorrow at the latest. +09:48 <@geertu> shimoday: Given you already did preparatory work for V3U SYS-DMAC in July 2019, do you plan to upstream support for it? +09:48 <@geertu> uli__: thx! +09:49 < wsa> uli__: cool! +09:50 < shimoday> @geertu: i don't have any plan for now. +09:51 <@geertu> shimoday: OK. So we'll have to tackle it once we have some I/O devices working that can make use of it. +09:51 <@geertu> Topic 2. Discussion Topics +09:51 <@geertu> A) KVM/Qemu situation. +09:51 < shimoday> @geertu: yes. thanks! +09:51 <@geertu> Morimoto-san reported that Munakata-san wants to know the KVM/Qemu situation. +09:52 < moriperi> Yes. it seems KVM/Qemu is/will important +09:52 < moriperi> for TOYOTA and/or Android +09:52 < moriperi> So he want to know plan and/or your opinion +09:52 <@geertu> The initial work we did, and which is documented on the elinux wiki, was basically an investigation and prototyping phase. +09:52 <@geertu> No confidential information was "opened". +09:53 < moriperi> OK +09:53 <@geertu> AFAIK, we have no further plans. +09:53 <@geertu> Before we reply to Morimoto-san's email, I think it would be good to have an ida of the planned use cases and expectations from Renesas. +09:53 <@geertu> s/ida/idea/ +09:54 <@geertu> Looks like the request is mostly tiggered by what Google wants to do on Android? +09:54 < moriperi> I'm not good at KVM, but he said that virt I/O, virt Video (?), virt Sound (?) virt USB (?), etc, etc will be needed. +09:55 < moriperi> for Android, he said. +09:55 < moriperi> and TOYOTA is having interresting about it. +09:55 <@geertu> https://lwn.net/Articles/836693/ KVM for Android +09:56 < moriperi> Renesas side have not concrete idea/plann so far. +09:56 < moriperi> That is the reason why he want to know your side opinition. +09:56 < shimoday> moriperi: virt USB means usb gadget? or host? perhaps gadget for android? +09:56 <@geertu> I may be mistaken, but I think all of this virt I/O, virt Video, virt Sound, and virt USB is platform-independent? +09:57 < wsa> yes, but it needs to be done +09:57 <@geertu> wsa: "it"? +09:57 < wsa> some people sent virt-io for I2C patches just the last weeks +09:58 < wsa> probably because of exactly the effort morimoto-san mentions +09:58 <@geertu> wsa: Yeah, if you see weird things appearing these days, it's usually triggered by some Google Android push +09:59 < damm> i wonder if the next logical step after GPIO virtualization would be UART? +10:00 < damm> with whatever in-kernel UART consumer interface it might be possible to arrange something not too ugly looking? +10:00 <@geertu> damm: Doesn't that exist already? Serial console, disk, and net were the first I/O devices supported +10:00 < wsa> so, I guess something to tell Munakata-san is that we generally favor KVM over Xen? +10:00 < damm> sure, but we are talking both guest-virtio side and host backing driver too? +10:00 < wsa> and he would probably like to see KVM running on R-Car? +10:00 <@geertu> Now, this "KVM for Android" seems to be the inverse of what people usually do: they want to protect the guest against the host, not vice vera +10:01 < damm> i'm wondering if host backing side can be connected to physical uart +10:01 <@geertu> damm: (1st hit) https://stackoverflow.com/questions/39373236/redirect-multiple-uarts-in-qemu +10:03 <@geertu> KVM already works on R-Car Gen3 (like on other arm64 SoCs) +10:03 < damm> with uarts and QEMU a lot of magic is possible. but i wonder if actual hardware configuration settings will be propagated to the physical port +10:04 < damm> it is just speculation from my side though +10:04 <@geertu> damm: I think so, as the QEMU invocation does not specify e.g. baud +10:04 < damm> on my remote access system i use socat with the host side pty +10:04 < damm> which does not work with hardware settings +10:05 < damm> but physical device might work better +10:05 < damm> anyway +10:05 < damm> nice to see renewed interest in KVM +10:06 <@geertu> I don't think it makes much sense to start talking about "how long" and "cost" if the goal is unclear +10:06 < moriperi> geertu: Yes, indeed. +10:06 < moriperi> So, as 1st I will ask to Munakata-san about Renesas side plan. +10:06 < moriperi> Is it OK for you ? +10:07 <@geertu> Given Google's focus on GKI and making as much as possible platform-independent... +10:07 < damm> if needed we can try to bridge the gap and make use case proposals +10:07 < moriperi> Maybe Renesas will think about 202X budget for it. +10:08 <@geertu> moriperi: That's a valid point. So we need as many wild ideas as possible, to secure budget? ;-) +10:08 < damm> how about gRPC over virtIO uart to a coprocessor? +10:09 < moriperi> geertu: sounds nice :) +10:09 < moriperi> (joke) +10:09 < moriperi> 1 things he said was that Laurent indicated virt Video related things at elinux. +10:10 < moriperi> He and TOYOTA had interested about it. +10:10 <@geertu> I'm indeed not familiar with video virtualization +10:10 < moriperi> Maybe we need more ping-pong about it over email :) +10:11 <@geertu> moriperi: Please let laurent recover from 100 to 200% ;) +10:12 < moriperi> :) +10:12 < pinchartl> I don't plan to go back to an unsustainable schedule :-) +10:12 <@geertu> Anything else to discuss? +10:12 <@geertu> Next meeting? +10:12 <@geertu> In 3 weeks, is Dec 17. 4 weeks is Dec 24 (Xmas eve) +10:13 < wsa> 17th +10:13 <@geertu> So Dec 17 might be better, also considering Jinzai reporting schedule? +10:14 < wsa> xmas eve is a good reason for 17th, too ;) +10:14 < shimoday> 17th is ok to me +10:14 <@geertu> OK +10:14 <@geertu> Thanks for joining, and have a nice continued day! diff --git a/wiki/Chat_log/20201126-io-chatlog b/wiki/Chat_log/20201126-io-chatlog new file mode 100644 index 0000000..69049e5 --- /dev/null +++ b/wiki/Chat_log/20201126-io-chatlog @@ -0,0 +1,94 @@ +09:05 < wsa> welcome to the IO meeting +09:05 < wsa> hope you are all well (again) +09:05 < wsa> here are the status updates +09:05 < wsa> Status updates +09:05 < wsa> ============== +09:05 < wsa> A - what have I done since last time +09:05 < wsa> ------------------------------------ +09:05 < wsa> Geert +09:05 < wsa> : enabled and tested MSIOF on R-Car V3U with manual pinctrl +09:05 < wsa> Niklas +09:05 < wsa> : had an initial look at Thermal support for V3U +09:05 < wsa> Shimoda-san +09:05 < wsa> : investigated the issues of the SDHI driver with Wolfram, and additionally sent patches to clean up resources in the SDHI driver, discussed using MMC aliases in DT, resent SCIF bindings for V3U, and discussed sending a power off notification in the MMC core +09:05 < wsa> Wolfram +09:05 < wsa> : worked on a lot of SDHI related issues: sent series to remove the hw_reset workaround by properly resetting the SCC which fixes the SD card insertion regression, sent series to reset SCC only when available, updated the "refactor SCC reset" series, sent cleanup series made possible by the previous refactoring, upported BSP patch to clear stale IRQs on errors, sent out series +09:05 < wsa> for proper max_busy_timeout handling, worked on a patch for resetting via reset controller, discussed how to handle SDHn clocks better nad how to handle data timeouts +09:05 < wsa> B - what I want to do until next time +09:05 < wsa> ------------------------------------- +09:05 < wsa> Geert +09:05 < wsa> : wants to retest MSIOF when R-Car V3U pinctrl driver is posted +09:05 < wsa> Niklas +09:05 < wsa> : wants to test if V3U thermal can be supported with existing driver with small changes in polling mode, and work on the additional task about timers +09:05 < wsa> Shimoda-san +09:05 < wsa> : wants to collect more information about R-Car Gen3e, continue to develop R-Car S4 Ethernet driver, continue to investigate SDHI driver's issues, add some pages about eMMC (block merging and PARTUUID) to the elinux wiki +09:05 < wsa> Ulrich +09:05 < wsa> : wants to implement atomic transfers for I2C +09:05 < wsa> Wolfram +09:05 < wsa> : wants to keep working on the open SDHI tickets, enable and test V3U IO devices, guide increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support for it, resend WDT patch to fix scheduling while atomic, start with isolated CPUs as logic analyzers +09:06 < wsa> C - problems I currently have +09:06 < wsa> ----------------------------- +09:06 < wsa> Geert +09:06 < wsa> : notes that MSIOF external loopback test fails on R-Car V3U/Falcon, and got no feedback on an IIC patch for the suspended state +09:06 < wsa> geertu: reading A) and C) I didn't really get if MSIOF testing was a success or not? +09:07 < wsa> geertu: and sorry for the i2c-sh_mobile delay. I plan to have a non-SDHI week next week +09:08 <@geertu> wsa: it worked in the sense that the driver didn't complain (e.g no hardware timeout), but the received data over loopback was wrong +09:08 < wsa> marex: lorenzo responded to your PCIe patch. IIRC he asked an outdated question, or? +09:08 < wsa> geertu: and the idea is to wait for the PFC driver to see if it works then? +09:09 < marex> wsa: I still need to read that email +09:09 <@geertu> wsa: Indeed. I may have overlooked something in my manual pinctrl config +09:09 <@geertu> marex: We want it as a fix for v5.9^Wv5.10, no? +09:09 < wsa> marex: ok +09:09 < marex> geertu: it -- the pcie 32bit thing ? +09:10 < wsa> geertu: ok, makes sense +09:10 < wsa> shimoday: I'd like to recap the open SDHI issues, so we know if we are aligned +09:11 < shimoday> wsa: i got it. may i recap open SDHI issues on an email later? +09:12 < wsa> there is the SDHn discussion, where Geert made an interesting suggestion. However, IIUC you implemented an clock framework abuse because it is simpler? +09:12 < wsa> you = you / or the BSP team +09:13 < wsa> and then, there is the open issue of resetting via the reset controller; we have a prototype but are waiting for feedback from the HW team +09:14 < shimoday> wsa: about SDHn, yes, bsp team tried it because it seems easy than Geert-san's suggestion +09:15 < wsa> I hope the "max_busy_timeout" issue is solved with my latest series; we could honor "cmd->busy_timeout" from the MMC core, but this is an additional optimization, something like the cherry on top. Not urgent +09:15 < shimoday> wsa: about reset controller for SDHI, I'm asking hw team but I got any feedback yet +09:16 < shimoday> wsa: about max_busy_timeout, I'm testing it and seems OK +09:16 < wsa> and then, we need to take care of data timeout; I still have to dive into your last email again, but it seems more refactoring of the BSP patch is needed +09:17 < wsa> these are the open issues I have on my list, if you have more, please tell :) +09:18 < shimoday> wsa: about data timeout, yes, i also think we need more refactoring to follow both mmc_test #15 and SDHI manual (retuning) +09:19 < wsa> shimoday: but are you okay that we try Geert's suggestion for upstream (SDHn clock) +09:19 < wsa> ? +09:20 < shimoday> wsa: i have one more thing from bsp team, but I don't ask you yet :) +09:20 < shimoday> bsp team said the mmc performance on v5.4 is lower than v4.14. +09:21 < shimoday> i tried to investiagte this a little, but I'm not sure this is really sdhi driver issue or not +09:22 < shimoday> so, I'll investigate this by myself (sorry, I should report this on today's report) +09:22 < wsa> shimoday: yes, it is hard to say if it is SDHI or MMC core +09:22 < wsa> without specific testing +09:23 < wsa> is it significant? +09:24 < shimoday> wsa: perhaps, it's significant because I guess customer will ask Renesas about this after provided the v5.4 base BSP +09:25 < wsa> yeah, it is important, that is for sure +09:25 < wsa> I mean is the performance loss like 50% or more like 5% or 0.5%? +09:26 < shimoday> according to bsp team report, on v4.14 = 240MB/s (read), on v5.4 = 173MB/s (read) +09:27 < shimoday> if we use IPMMU, on v4.14 = 270MB/s, on v5.4 = 240MB/s +09:27 < shimoday> so, BSP team is worries about non-IPMMU speed +09:28 < wsa> 240 -> 173, that is significant +09:28 <@geertu> sounds like some bounce-buffering is involved if the IPMMU is not used +09:28 < wsa> I'll check why I never noticed sth like that +09:29 < wsa> are there any other questions from you guys? +09:29 < marex> wsa: 173 is HS200, 240 is HS400 ... +09:29 < marex> wsa: so likely HS400 calibration failed +09:29 < shimoday> wsa: thanks! +09:30 < wsa> marex: interestig pointer +09:30 < wsa> thanks! +09:30 <@geertu> marex: Hmm, IPMMU or not should not impact HS400 calib +09:30 < shimoday> marex: i'm sorry, my report "on v4.14" and "on v5.4" are BSPs +09:31 < shimoday> v4.14 means rcar-3.9.x, v5.4 means rcar-4.1.0.rc1 +09:31 < shimoday> so, bsp team use HS400 on these kernel versions i think +09:34 < wsa> okay, let's see if I can reproduce the results +09:34 < marex> shimoday: the thing is, if you do sustained block read in HS200, the bus tops at ~170 MiB/s, for HS400 the bus tops at 350 MiB/s , but the card does at 240 MiB/s +09:35 < marex> so the numbers provided would indicate HS400 mode problem +09:35 < marex> probably cat /sys/kernel/debug/mmc*/ios would give you some input quickly +09:36 < marex> geertu: the IPMMU difference is likely due to the buffers being above 32bit boundary, with IPMMU they dont have to be copied back and forth +09:37 <@geertu> marex: yeah, bounce buffers. but v5.4+ipmmu does should hs400 speeds +09:37 <@geertu> s/should/show/ +09:39 < marex> geertu: aha, thats a valid point +09:42 < shimoday> marex: thanks. I think so about these speeds. i'll check the ios later +09:42 < wsa> okay +09:42 < wsa> shall we move to core then? diff --git a/wiki/Chat_log/20201217-core-chatlog b/wiki/Chat_log/20201217-core-chatlog new file mode 100644 index 0000000..908f00e --- /dev/null +++ b/wiki/Chat_log/20201217-core-chatlog @@ -0,0 +1,114 @@ +09:30 < geertu> Welcome to today's Core Group Chat Meeting! +09:30 < geertu> Agenda: +09:30 < geertu> 1. Status Updates +09:30 < geertu> 2. Discussion Topics +09:30 < geertu> Topic 1. Status updates +09:30 < geertu> A) What have we done since last time: +09:30 < geertu> Marek worked on Linux (PCIe L1 link state and 32bit MSI fixes) and OpTee +09:30 < geertu> (CPU core count auto-detection, DRAM layout passing). +09:30 < geertu> Morimoto-san continued V3U-Falcon shipping paper work. +09:30 < geertu> Niklas submitted R-Car Gen3 TMU and V3U thermal clock patches. +09:30 < geertu> Shimoda-san attended OSSJ and ALS2020, and submitted BD9574MWF support. +09:30 < geertu> Ulrich worked on PFC for R-Car V3U version 2. +09:30 < geertu> Geert sent the second batch of pull requests for v5.11, reviewed the +09:30 < geertu> R-Car V3U pinctrl driver, worked on obtaining the start of physical +09:30 < geertu> memory from DTB, and fixed CMT1 on APE6-EVM. +09:31 < geertu> B) What we plan to do till next time: +09:31 < geertu> Marek plans to work on Linux (PCIe follow-up) and OpTee (updates). +09:31 < geertu> Morimoto-san plans to enjoy vacation, and suffer paperwork. +09:31 < geertu> Niklas plans to enjoy vacation. +09:31 < geertu> Shimoda-sa plans to enjoy vacation, collect more information about R-Car +09:31 < geertu> Gen3e, and continue BD9574 work. +09:31 < geertu> Ulrich plans to finish PFC for R-Car V3U version 2. +09:31 < geertu> Geert plans to enjoy holidays, repost R-Car V3U gpio, upport R-Car V3U +09:31 < geertu> SYS-DMAC support, and finish obtaining the start of physical memory from +09:31 < geertu> DTB. +09:31 < geertu> C) Problems we have currently: +09:31 < geertu> Morimoto-san is looking for socially-accepted ways to improve paperwork +09:31 < geertu> progress. +09:31 < geertu> Shimoda-san is worried about not getting further Gen3e information. +09:31 < geertu> Ulrich is suffering from conflicts in the R-Car V3U PFC documentation. +09:32 < geertu> ---EOT--- +09:32 < geertu> Anything I missed? +09:32 < geertu> s/-sa/-san/ +09:32 < geertu> Topic 2. Discussion Topics +09:33 < wsa> status of the PFC driver? +09:33 < geertu> Do we already know what causes the QSPI ROM breakage? +09:33 < wsa> V3U PFC +09:33 < geertu> It seems to work, if I add my own pfc node. +09:33 < geertu> uli__: ? +09:34 < uli__> working on it, there are numerous little issues, but should all be sorted out soon +09:34 < wsa> i'd like to start with V3U IO testing soon, so if there was a branch/patches to pull in, I'd be thankful +09:36 < uli__> probably before christmas for version 2 +09:36 < uli__> but v1 is rumored to work reasonably well :) +09:37 < wsa> uli__: ok, then i'll use this one and see how it goes... +09:37 < wsa> uli__: when (== which daytime) do you use the board mostly? +09:37 < shimoday> geertu: according to investigating team, +09:37 < uli__> wsa: late afternoon, i guess +09:38 < shimoday> qspi will be written as protect mode into one time program register +09:38 < shimoday> also will be write wrong data into sector 0 or like that by linux kernel +09:38 < shimoday> if linux uses both qspi and mmc driver, the issue happened. +09:39 < shimoday> but, we use either qspi or mmc, the issue didn't happen +09:39 < shimoday> this is the current report from the team i heard +09:40 < shimoday> we don't know why using both qspi and mmc causes this issue yet though +09:40 < geertu> shimoday: OK, so the upstream kernel is fine ;-) +09:40 < shimoday> geertu: yes :) +09:41 < moriperi> shimoday: 1st written is by uboot, 2nd is linux, correct ? +09:41 < wsa> uli__: will fit nicely. I think it will be morning hours and early afternoon for me +09:41 < moriperi> s/uboot/non linux/ +09:41 < geertu> wsa: uli__: And we have the channel falcon lock... +09:42 < wsa> sure +09:42 < shimoday> moriperi: sorry, what is "1st written"? +09:43 < moriperi> Oops, 100% linux issue ? +09:43 < wsa> but good scheduling helps lock contention :) +09:43 < moriperi> I thought uboot vs linux mismatch +09:44 < shimoday> moriperi: linux causes this issue, yes. but, we don't know the root cause. (SW or SoC or Board) +09:45 < moriperi> OK, I see. thanks +09:45 < moriperi> uboot and/or IPL is not related ? +09:46 < shimoday> moriperi: from the report, we don't know whether these are related for now :) +09:47 < moriperi> OK. my understanding is that it happen on *latest* BSP. and we are using *old* BSP base uboot/IPL. +09:47 < damm> using SCIF D/L mode should always work right? +09:47 < damm> independently of fried on-board memory fsck-up +09:48 < shimoday> damm: i think so +09:48 < shimoday> even if qspi is protected by one time program register, we can modify the register after power on +09:49 < damm> not so fun if soldered storage has fuses blown though +09:49 < damm> but if otp can be overriden then no biggie +09:49 < marex> shimoday: by otp, dont you rather mean "non-volatile register" ? :) +09:51 < shimoday> marex: you're correct. it seems non-volatile register. +09:52 < damm> good. then i guess the potential issue can be fixed somehow at least. +09:53 < geertu> moriperi: Since you say we are bot using the latest BSP, rcar-4.1.0.rc4 is not the latest BSP? Or what do you mean? +09:53 < geertu> s/bot/not/ +09:53 < geertu> Which version should we not boot on Falcon? +09:53 < moriperi> let me check +09:55 < moriperi> NG: BSP v4.1.0-rc1 +09:56 < moriperi> OK: BSP v4.0.1-rc1 +09:56 < moriperi> we are using v4.0.1-rc1 +09:56 < geertu> which is v5.4-based +09:56 < geertu> while the bad one is v5.4.72-based +09:56 < moriperi> Magnus's current one, and I'm trying to ship one +09:57 < shimoday> according to the bsp report, v4.1.0.rc3 is also OK because it disables QSPI by dts +09:58 < moriperi> BSP v4.1.0-rc1 = v5.4.72 +09:58 < moriperi> BSP v4.0.1-rc1 = v5.4.0 +10:00 < geertu> OK +10:00 < geertu> Anything else to discuss? +10:00 < marex> is there any documentation for the rcar3 TRNG in CCREE ? +10:00 < marex> it would be useful to have an RNG in optee, so we can enable ASLR +10:01 < kbingham> I have a maybe core question about V3U: I've seen reference to V3U-AD is that the part / soc name ? +10:02 < kbingham> "Figure 32.24 shows node value of all sub modules implemented in all VSPs of R-Car V3U-AD" +10:04 < pinchartl> another question, when should the next meeting take place ? +10:05 < geertu> Jan 14? +10:05 < geertu> or is that too early? +10:05 < wsa> sounds good to me +10:06 < shimoday> sounds good to me +10:06 < moriperi> sounds good to me, but maybe noting to report :) +10:06 < shimoday> marex: i checked a documentation roughly, but i could not find TRNG +10:06 < shimoday> marex: so, i'll ask charge of person later +10:06 < marex> shimoday: I know, that's why I'm asking ; geertu suggested its part of the cryptocell +10:07 < marex> shimoday: thank you +10:07 < wsa> moriperi: maybe you get a shotgun for XMas, then you can report something +10:07 < geertu> marex: s/cryptocell/Secure Engine/ +10:07 < moriperi> wsa: :) +10:07 < geertu> cryptocell \in Secure Engine +10:08 < geertu> Thanks for joining, and have a nice continued day! +10:08 < shimoday> marex: ah, "a documentation" meant internal secret secure engine manual :) +10:08 < shimoday> not hardware manual diff --git a/wiki/Chat_log/20201217-io-chatlog b/wiki/Chat_log/20201217-io-chatlog new file mode 100644 index 0000000..3074335 --- /dev/null +++ b/wiki/Chat_log/20201217-io-chatlog @@ -0,0 +1,113 @@ +09:02 < wsa> So, let's start the meeting +09:02 < wsa> welcome :) +09:02 < wsa> here are the status updates +09:03 < wsa> Status updates +09:03 < wsa> ============== +09:03 < wsa> A - what have I done since last time +09:03 < wsa> ------------------------------------ +09:03 < wsa> Geert +09:03 < wsa> : retested MSIOF on Falcon with R-Car V3U pinctrl enabled +09:03 < wsa> Marek +09:03 < wsa> : dealt with feedback from PCIe maintainers on L1 link state fix for Gen2 and 32bit PCIe MSI fix +09:03 < wsa> Niklas +09:03 < wsa> : sent patches to fix locking problems with timers, added CMT and TMU binding descriptions and DTS updates for all Gen3 SoC which were missing it, added thermal support for V3U +09:03 < wsa> Shimoda-san +09:03 < wsa> : attended OSSJ and ALS2020, added pages about eMMC to eLinux, investigated SDHI driver issues with Wolfram (max_busy_timeout, low performance than v4.14 BSP, data timeout, incorrect clock setting on M3 v1.x + HS200, hang when CMD0), sent out patches for SDHI pre_req and post_req +09:03 < wsa> Ulrich +09:03 < wsa> : worked on atomic transfers for R-Car I2C +09:03 < wsa> Wolfram +09:03 < wsa> : worked on isolated CPUs as logic analyzers (kernel + userspace), sent out minor GPIO cleanup patches found on the way, worked with Shimoda-san on SDHI max_busy_timeouts, data timeout handling, and pre/post-req support +09:03 < wsa> B - what I want to do until next time +09:03 < wsa> ------------------------------------- +09:03 < wsa> Geert +09:03 < wsa> : wants to advertise MSIOF min/max speed limits to SPI core, and use MSIOF as a testbed for R-Car V3U SYS-DMAC +09:03 < wsa> Marek +09:03 < wsa> : wants to continue dealing with the PCIe maintainers +09:03 < wsa> Niklas +09:03 < wsa> : wants to figure out numbering of TSC nodes on V3U, wants to take a well-deserved vacation +09:03 < wsa> Shimoda-san +09:03 < wsa> : wants to take a well-deserved vacation, collect more information about R-Car Gen3e, continue to investigate SDHI driver issues, continue to develop R-Car S4 Ethernet driver +09:03 < wsa> Ulrich +09:03 < wsa> : wants to finish atomic transfers for R-Car I2C +09:03 < wsa> Wolfram +09:03 < wsa> : wants to enable and test V3U IO devices, improve logic analyzer, try to enable WAIT_WHILE_BUSY for SDHI, resend WDT patch to fix scheduling while atomic +09:03 < wsa> C - problems I currently have +09:03 < wsa> ----------------------------- +09:03 < wsa> Shimoda-san +09:03 < wsa> : could not retrieve further Gen3e information for now +09:03 < wsa> Wolfram +09:03 < wsa> : is not happy with the performance of the logic analyzer yet (1 channel at 100kHz) +09:04 < wsa> shimoday: I am happy we fixed the CMD0 problem, but which one was that and which patch did fix it? :D +09:04 < wsa> Other than that, we also have the WAIT_WHILE_BUSY topic which is a optimization, though, not a bugfix +09:05 < neg> morning all, sorry I'm a few min late +09:05 < wsa> shimoday, moriperi: was there noteworthy stuff happening at OSSJ? +09:05 < wsa> hi neg! +09:05 < wsa> neg: you had fun with the timers? +09:06 < wsa> neg: about the thermal V3U counting problem: can't you describe it in YAML similar to the interrupt difference? +09:06 < shimoday> wsa: remove hw_reset caused this issue and call ->reset could be fixed, i think :) +09:07 < wsa> shimoday: ah, this one +09:08 < shimoday> wsa: yes about WAIT_WHILE_BUSY +09:08 < neg> I think V3U and YAML is solvable, I think the fault is between datasheet and keyboard ;-) +09:08 < shimoday> wsa: about OSSJ, I didn't think big news happen at OSSJ. +09:08 < wsa> geertu: what is the conclusion of MSIOF and V3U: 300kHz is the max speed due to HW design? +09:08 < shimoday> moriperi: what do you think? +09:09 < geertu> wsa: I don't think it's hardware design. Looks like a property of the external loopback +09:09 < geertu> E.g. long jumper wires. +09:10 < geertu> When looking at the received data at higher speeds, signal transitions may be slightly offset, or missing. +09:11 < wsa> marex: could you give a short summary of the PCIe discussions? The detail level is quite high... +09:11 < geertu> wsa: BTW, you mae sure GPIO chatter prevention is turned of for your logic analyzer? +09:12 < geertu> s/mae/made/, s/of/off/ +09:12 < wsa> neg: timers are done or is there still something to be done +09:12 < marex> wsa: well, after 2 or so months, pcie maintainers woke up and started reviewing the bugfixes +09:13 < neg> wsa: I still need to enable and test timers on V3U +09:13 < wsa> geertu: I had a glimpse and saw no support for chatter prevention in the driver. And the default was 'off', so I didn't investigate further +09:13 < geertu> wsa: You better verify it's really off when the boot loader hands off the system to Linux (cfr. the APE6-EVM CMT1 issue) +09:13 < wsa> geertu: IIRC chatter prevention was only for a few pins anyhow and the ones I used were not affected +09:13 < marex> wsa: the 32bit MSI bugfix is being commented on mostly by Lorenzo, where Lorenzo is trying to change the logic and remove the allocation of page altogether +09:14 < marex> wsa: so far, the argument there was something about LPAE, but when I asked further, the argument was apparently incorrect +09:14 < wsa> geertu: ok, thanks, will do +09:14 < marex> wsa: so now it seems the original patch is gonna work both on LPAE and non-LPAE system all the same, but Lorenzo is still trying to push against the simple bugfix +09:15 < neg> wsa: And the key bugfix patch for deadlocks have had no traction upstream, so I need to repost it as separate patch with $scary subject in Jan once people are back ;-) +09:15 * wsa likes "$scary subject" +09:16 < wsa> marex: sounds like he has no technical reason? +09:16 < wsa> uli__: you saw the diff for the i2c-rcar testcase? +09:16 < marex> wsa: seems like a matter of taste right now +09:17 < uli__> wsa: yes, thanks. that's what i was looking for +09:17 < wsa> marex: I see. So, he asks for an alternative without suggesting one? +09:18 < marex> wsa: as for the L1 link state, there is feedback from Bjorn, he is pointing out some edge cases where this might fail, and Lorenzo is asking whether there might be concurency problem +09:18 < wsa> uli__: I tested it quickly and it gave me the OOPS you wanted ;) +09:18 < uli__> excellent, i guess :) +09:19 < wsa> shimoday: which pages did you add to eLinux, BTWE? +09:19 < wsa> BTW +09:19 < marex> wsa: the alternative Lorenzo is trying to push is "pick an address", but that would require more intrusive change, which I think isn't what we want for stable backport +09:19 < marex> wsa: could be done in a separate patch too +09:19 < shimoday> https://elinux.org/R-Car/Merging-MMC-block-requests +09:20 < shimoday> https://elinux.org/R-Car/Use-MMC-block-as-rootfs-on-v5-10 +09:20 < shimoday> wsa: these pages +09:20 < shimoday> about mmc block order +09:21 < shimoday> about second one, i saw Linus torvals and MMC maintainer talked this topic once +09:21 < shimoday> but, i didn't follow a conclusion +09:21 < wsa> marex: okay, i think with backporting to stable you have a good argument. let's hope he will accept that. I can definately second you on this one. +09:21 < wsa> marex: thanks for the summary! +09:21 < geertu> shimoday: BTW, there's been more discussion, and it looks like mmc aliases will be accepted by Ulf +09:21 < wsa> Linus is interested in MMC? +09:22 < marex> wsa: sure +09:22 < shimoday> let me find a lkml url +09:22 < geertu> https://lore.kernel.org/linux-arm-kernel/CAK8P3a2Habmz95y+J+-4NiT5SGYhO_Fia-SHhapX-3NYRbEMmw@mail.gmail.com/ +09:22 < wsa> ah, because of consistent numbering +09:22 -!- damm [~damm@l193216.ppp.asahi-net.or.jp] has joined #periperi +09:23 < wsa> hi Magnus! +09:23 < geertu> damm: You're late because you were measuring the very long length of the jumper wire? ;) +09:23 < wsa> geertu: I thought he was connecting the CAN interface to his car? +09:23 < wsa> shimoday: thanks for the links! +09:24 < shimoday> https://lkml.org/lkml/2020/11/27/739 +09:24 < marex> shimoday: do you know 'part uuid' u-boot command ? You can use that to determine partition UUID in U-Boot and then pass that to Linux as root=PARTUUID= argument +09:25 < wsa> so, any more questions from your side? +09:25 < shimoday> geertu: oh, i got it. i'll resend a patch later +09:26 < damm> hi guys sorry for being late =) +09:26 < shimoday> marex: i didn't know that. thanks! +09:27 < marex> shimoday: I hope it helps +09:27 < wsa> okay, looks like no more questions +09:27 < wsa> then we can switch to core? +09:27 < wsa> geertu: ready? +09:28 < wsa> thanks for your work, everyone! diff --git a/wiki/E3_Ebisu.wiki b/wiki/E3_Ebisu.wiki index ca1f5fa..e017bce 100644 --- a/wiki/E3_Ebisu.wiki +++ b/wiki/E3_Ebisu.wiki @@ -1,5 +1,35 @@ h1. E3 Ebisu +h2. HW settings + + | SW3 | ON | | + | SW31 | ON | | + | SW10 | for update | xxxx 0000 | + | | for use | xxxx 1100 (HyperFlash = 80MHz, stable) | + | | | xxxx 1101 (HyperFlash = 150MHz, aggressive) | + +h2. File List + +| bootparam_sa0-4d.srec | 0x000000 | Loader(Boot parameter) | +| bl2-ebisu-4d.srec | 0x040000 | Loader | +| cert_header_sa6-4d.srec | 0x180000 | Loader(Certification) | +| bl31-ebisu-4d.srec | 0x1C0000 | ARM Trusted Firmware | +| tee-ebisu.srec | 0x200000 | OP-Tee | +| u-boot-elf-ebisu-4d.srec | 0x640000 | U-Boot | + +h2. Flash command + +./do_xls2.expect /dev/ttyUSB1 AArch64_Gen3_E3-4D_Scif_MiniMon_V5.03A.mot table.txt + +h2. Boot command + +| tftpboot 0x48080000 ebisu/Image | +| tftpboot 0x58000000 ebisu/r8a77990-ebisu.dtb | +| booti 0x48080000 - 0x58000000 | + h1. Files +"do_xls2.expect":../../wiki/E3_Ebisu/do_xls2.expect +"table.txt":../../wiki/E3_Ebisu/table.txt +"tar.bz2: Ebisu-4D v2019-06-21":../../wiki/E3_Ebisu/ebisu-20190621_G3Yv3.21.00.03_G3Yv215_PT4.tar.bz2 "zip: E3 Ebisu 1GiB v2018-03-02/":../../wiki/E3_Ebisu/e3_ebisu_2018-03-02-for-ddr-1GiB.zip diff --git a/wiki/E3_Ebisu/ebisu-20190621_G3Yv3.21.00.03_G3Yv215_PT4.tar.bz2 b/wiki/E3_Ebisu/ebisu-20190621_G3Yv3.21.00.03_G3Yv215_PT4.tar.bz2 Binary files differnew file mode 100644 index 0000000..ce222b3 --- /dev/null +++ b/wiki/E3_Ebisu/ebisu-20190621_G3Yv3.21.00.03_G3Yv215_PT4.tar.bz2 diff --git a/wiki/H3_Salvator-X.wiki b/wiki/H3_Salvator-X.wiki index 282958d..c7048e3 100644 --- a/wiki/H3_Salvator-X.wiki +++ b/wiki/H3_Salvator-X.wiki @@ -118,10 +118,12 @@ see above| h2. Release Note +* "Yocto Startup Guide v4.1.0":../../wiki/H3_Salvator-XS/RENESAS_RCH3M3M3NE3_YoctoStartupGuide_UME_v4.1.0.pdf * "Yocto Release Note":../../wiki/H3_Salvator-X/RENESAS_RCH3M3_YoctoReleaseNote_E_v2.23.0.pdf * "IPL Release Note":../../wiki/H3_Salvator-X/RENESAS_RCH3M3_IPL_ReleaseNote_E_v1.0.16.pdf h1. Files +"tar: H3_Salvator-X-v410":../../wiki/H3_Salvator-XS/H3_Salvator-X-v410.tar.bz2 "zip: Gen3 MiniMonitor v3.03":../../wiki/H3_Salvator-X/Gen3_MiniMonitor_V3.03-20180208.zip "mot: Gen3 H3/M3 MiniMon v3.03":../../wiki/H3_Salvator-X/AArch64_Gen3_H3_M3_Scif_MiniMon_V3.03.mot diff --git a/wiki/H3_Salvator-XS.wiki b/wiki/H3_Salvator-XS.wiki new file mode 100644 index 0000000..d395624 --- /dev/null +++ b/wiki/H3_Salvator-XS.wiki @@ -0,0 +1,10 @@ +h1. H3 Salvator-XS + +h2. Update FirmWare + +See "Yocto Startup Guide v4.1.0 21page":../../wiki/H3_Salvator-XS/RENESAS_RCH3M3M3NE3_YoctoStartupGuide_UME_v4.1.0.pdf#page=26 + +h1. Files + +"tar: H3_Salvator-X-v410":../../wiki/H3_Salvator-XS/H3_Salvator-X-v410.tar.bz2 +"pdf: Yocto Startup Guide v4.1.0":../../wiki/H3_Salvator-XS/RENESAS_RCH3M3M3NE3_YoctoStartupGuide_UME_v4.1.0.pdf diff --git a/wiki/H3_Salvator-XS/H3_Salvator-X-v410.tar.bz2 b/wiki/H3_Salvator-XS/H3_Salvator-X-v410.tar.bz2 Binary files differnew file mode 100644 index 0000000..4670ef7 --- /dev/null +++ b/wiki/H3_Salvator-XS/H3_Salvator-X-v410.tar.bz2 diff --git a/wiki/H3_Salvator-XS/RENESAS_RCH3M3M3NE3_YoctoStartupGuide_UME_v4.1.0.pdf b/wiki/H3_Salvator-XS/RENESAS_RCH3M3M3NE3_YoctoStartupGuide_UME_v4.1.0.pdf Binary files differnew file mode 100644 index 0000000..fed452a --- /dev/null +++ b/wiki/H3_Salvator-XS/RENESAS_RCH3M3M3NE3_YoctoStartupGuide_UME_v4.1.0.pdf diff --git a/wiki/Hardware.wiki b/wiki/Hardware.wiki index d3dff58..1eb813f 100644 --- a/wiki/Hardware.wiki +++ b/wiki/Hardware.wiki @@ -34,13 +34,14 @@ h3. Renesas board |_. [[D3 Draak]] | | O | | | | O | | | | |_. [[E3 Ebisu]] | O | | | | O | | | O | O | |_. [[H3 Salvator-X]] | O | O | O | | O | O | O | | | -|_. H3 Salvator-XS | O | O | O | O | O | | O | | O | +|_. [[H3 Salvator-XS]] | O | O | O | O | O | | O | | O | |_. [[H3 ULCB]] | | O | | | | | | | O | |_. [[M3W Salvator-X]] | O | O | O | O | O | O | O | O | O | -|_. M3N Salvator-XS | O | O | O | O | O | O | O | O | O | -|_. M3 ULCB | | | | | | | | O | O | +|_. [[M3N Salvator-XS]] | O | O | O | O | O | O | O | O | O | +|_. [[M3 ULCB]] | | | | | | | | O | O | |_. [[V3H]] | | | | | | | | | | |_. [[V3M Eagle]] | | | O | | | | O | | | +|_. [[V3U Falcon]] | | | | | | | | | | h3. Expansion board diff --git a/wiki/M3N_Salvator-XS.wiki b/wiki/M3N_Salvator-XS.wiki new file mode 100644 index 0000000..ff3e672 --- /dev/null +++ b/wiki/M3N_Salvator-XS.wiki @@ -0,0 +1,10 @@ +h1. M3N Salvator-XS + +h2. Update FirmWare + +See "Yocto Startup Guide v4.1.0 21page":../../wiki/H3_Salvator-XS/RENESAS_RCH3M3M3NE3_YoctoStartupGuide_UME_v4.1.0.pdf#page=26 + +h1. Files + +"tar: M3N_Salvator-X-v410":../../wiki/M3N_Salvator-XS/M3N_Salvator-X-v410.tar.bz2 +"pdf: Yocto Startup Guide v4.1.0":../../wiki/H3_Salvator-XS/RENESAS_RCH3M3M3NE3_YoctoStartupGuide_UME_v4.1.0.pdf diff --git a/wiki/M3N_Salvator-XS/M3N_Salvator-X-v410.tar.bz2 b/wiki/M3N_Salvator-XS/M3N_Salvator-X-v410.tar.bz2 Binary files differnew file mode 100644 index 0000000..2636547 --- /dev/null +++ b/wiki/M3N_Salvator-XS/M3N_Salvator-X-v410.tar.bz2 diff --git a/wiki/M3_ULCB.wiki b/wiki/M3_ULCB.wiki new file mode 100644 index 0000000..44cba3d --- /dev/null +++ b/wiki/M3_ULCB.wiki @@ -0,0 +1,42 @@ +h1. M3 ULCB + +h2. Update FirmWare + +See here +https://elinux.org/R-Car/Boards/M3SK#Flashing_firmware + +h2. Sample + +<pre> +R-Car Gen3 Sample Loader V5.13 2019.07.24 + For Salvator , Kriek , and StarterKit.(R-CarH3/R-CarM3) + Board Judge : Used Board-ID + DDR_Init : boardcnf[7] Salvator / Starter Kit (H3SIP_VER2.0-1rank) + INITIAL SETTING : Starter Kit Premier / R-Car H3 ES3.0 + CPU / BOOT MODE : AArch64 CA57-CPU0 / CA57 Boot Mode (MD15:AArch64) + DRAM : LPDDR4 DDR3200 + DEVICE : QSPI Flash(S25FS128) at 40MHz DMA + BOOT : Normal Boot + BACKUP : DDR Cold Boot + jump to 0xE6330000 + +R-Car Gen3 MiniMonitor V5.13 2019.07.24 + Work Memory : SystemRAM + Board Judge : Used Board-ID + Board Name : Starter Kit Premier + Product Code : R-Car H3 ES3.0 + +>xls2 +===== Qspi/HyperFlash writing of Gen3 Board Command ============= +Load Program to Spiflash +Writes to any of SPI address. +Please select,FlashMemory. + 1 : QspiFlash (U5 : S25FS128S) + 2 : QspiFlash Board (CN2: S25FL512S) + 3 : HyperFlash (SiP internal) + Select (1-3)> +</pre> + +h1. Files + +"zip: m3sk-yocto410.zip":../../wiki/M3_ULCB/m3sk-yocto410.zip diff --git a/wiki/M3_ULCB/m3sk-yocto410.zip b/wiki/M3_ULCB/m3sk-yocto410.zip Binary files differnew file mode 100644 index 0000000..0d0ce59 --- /dev/null +++ b/wiki/M3_ULCB/m3sk-yocto410.zip diff --git a/wiki/V3U_Falcon.wiki b/wiki/V3U_Falcon.wiki new file mode 100644 index 0000000..c15aa03 --- /dev/null +++ b/wiki/V3U_Falcon.wiki @@ -0,0 +1,23 @@ +h1. V3U Falcon + +h1. Serial + +Your PC will find *2 x ttyUSB* when you connect to V3U-Falcon + +<pre> +> dmesg| tail +[1563508.385481] usb 3-5: SerialNumber: 000001 +[1563508.389100] ftdi_sio 3-5:1.0: FTDI USB Serial Device converter detected +[1563508.389186] usb 3-5: Detected FT2232H +[1563508.389507] usb 3-5: FTDI USB Serial Device converter now attached to ttyUSB1 +[1563508.390942] ftdi_sio 3-5:1.1: FTDI USB Serial Device converter detected +[1563508.391028] usb 3-5: Detected FT2232H +[1563508.391306] usb 3-5: FTDI USB Serial Device converter now attached to ttyUSB2 +</pre> + +Here, your PC found *ttyUSB1* and *ttyUSB2*. use *ttyUSB1* for minicon. + +h1. Files + +"tar.bz2: V3U Falcon IPL+UBoot 2020.01":../../wiki/V3U_Falcon/v3u-falcon-202001.tar.bz2 +"pptx: V3U Image":../../wiki/V3U_Falcon/FalconV3U_20200604.pptx diff --git a/wiki/V3U_Falcon/FalconV3U_20200604.pptx b/wiki/V3U_Falcon/FalconV3U_20200604.pptx Binary files differnew file mode 100644 index 0000000..cc9afae --- /dev/null +++ b/wiki/V3U_Falcon/FalconV3U_20200604.pptx diff --git a/wiki/V3U_Falcon/v3u-falcon-202001.tar.bz2 b/wiki/V3U_Falcon/v3u-falcon-202001.tar.bz2 Binary files differnew file mode 100644 index 0000000..0a9833a --- /dev/null +++ b/wiki/V3U_Falcon/v3u-falcon-202001.tar.bz2 |