diff options
Diffstat (limited to 'wiki')
| -rw-r--r-- | wiki/Chat_log/20200806-core-chatlog | 147 | ||||
| -rw-r--r-- | wiki/Chat_log/20200806-io-chatlog | 108 | ||||
| -rw-r--r-- | wiki/Chat_log/20200903-core-chatlog | 137 | ||||
| -rw-r--r-- | wiki/Chat_log/20200903-io-chatlog | 175 | ||||
| -rw-r--r-- | wiki/Chat_log/20200903-mm-chatlog | 255 |
5 files changed, 822 insertions, 0 deletions
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..8d4e6a7 --- /dev/null +++ b/wiki/Chat_log/20200903-io-chatlog @@ -0,0 +1,175 @@ +<wsa> welcome everyone, hope you are fine +<wsa> here are the collected status updates +<wsa> Status updates +<wsa> ============== +<wsa> A - what have I done since last time +<wsa> ------------------------------------ +<wsa> Geert +<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 +<wsa> Niklas +<wsa> : unsuccessfully tested SDIO WiFi with Koelsch on Gen2. Probably because + of a too long cable. He will try a shorter one. +<wsa> Shimoda-san +<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 +<wsa> Ulrich +<wsa> : sent "watchdog: da9063: wake up parent ahead of reboot" to enable late + atomic transfers with IIC [16:01] +<wsa> Wolfram +<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 +<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 +<wsa> B - what I want to do until next time +<wsa> ------------------------------------- +<wsa> Shimoda-san +<wsa> : wants to convert rcar-pci dt doc to json-schema, and ping the serial + gadget patch I have submitted +<wsa> Ulrich +<wsa> : wants to address feedback for "watchdog: da9063: wake up parent ahead + of reboot", and implement atomic transfers for i2c-rcar +<wsa> Wolfram +<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 +<wsa> C - problems I currently have +<wsa> ----------------------------- +<wsa> Geert +<wsa> : wonders how to avoid PCIe s2ram crash on R-Car Gen2 +<wsa> Wolfram +<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 +<wsa> If you have questions or comments, please fire away +<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? [16:02] +<marex> I was about to ask the same +<geertu> wsa: marex: It's the same issue as on R-Car Gen3. +<geertu> But on arm64, it was fixed in ATF (by marex-san) +<marex> geertu: thats on RZ then ? +<geertu> marex: No, R-Car Gen2 (koelsch). But RZ/G1 should be affected, too. + [16:03] +<marex> ah sigh +<geertu> + https://github.com/ARM-software/arm-trusted-firmware/commit/0969397f295621aa26b3d14b76dd397d22be58bf + [16:04] +<geertu> On arm32, we need to hook up something into the exception handling in + Linux? +<marex> geertu: so is linux able to get the fault and fix it up ? +<geertu> marex: Currently not [16:05] +<marex> geertu: I suspect you might just need to do as iMX6 does +<marex> geertu: that one did generate some faults when PCIe went nuts too +<marex> geertu: and there both U-Boot and Linux hooked the fault handler +<wsa> geertu: what is missing for Linux? [16:06] +<marex> wsa: the same workaround as in TFA apparently +<geertu> marex: Sounds like a good job for the PCI DRIVER FOR RENESAS R-CAR + maintainer? ;-) +<marex> wsa: except implemented via the fault hooks [16:07] +<marex> wsa: that is , IFF , the gen2 generates such a fault instead of + locking up +<marex> needs to be checked +<geertu> marex: It generates such a fault +<wsa> ok, that's sounds doable? I understood Geert's comment that way that + Linux is missing some prerequisite to handle it [16:08] +<marex> wsa: nope +<wsa> So, on Gen3, why did we chose the ATF way instead of pure Linux? +<marex> wsa: the stuff should be all there +<marex> wsa: because on Gen3, you get a fault in EL3 [16:09] +<geertu> Unhandled fault: asynchronous external abort (0x1211) at 0x00000000 +<wsa> ok +<geertu> (that line is from M2-W) +<marex> geertu: hold on, I need some coffee first +<wsa> ok, I'll wait for Marex to get some coffee and _then_ ask him if he is + interested in tackling it ;) [16:11] +<wsa> shimoda: thanks for the quick testing of my SDHI patches +<wsa> I really hope we have no more stalled SCC problems anymore +<shimoda> wsa: you're welcome! i'll review manual calib patches later [16:12] +<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 +<wsa> shimoda: Awesome, thanks! [16:13] +<marex> geertu: drivers/pci/controller/dwc/pci-imx6.c +<marex> 1300 hook_fault_code(8, imx6q_pcie_abort_handler, SIGBUS, 0, +<marex> 1301 "external abort on non-linefetch"); +<marex> look ^ +<marex> so we'll need similar "workaround" +<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? [16:15] +<geertu> wsa: No SPI devices, AFAIK +<wsa> uli___: seems that Guenter missed that there is no RPM that late, or? +<wsa> geertu: ah, okay. well, you would have known if there are any ;) [16:16] +<damm> i don't mind hooking up stuff if needed +<geertu> wsa: I think he doesn't know much about RPM in general +<uli___> wsa: just needs a little explaining, I guess [16:17] +<wsa> damm: that's great! next one will be the CAN devices ;) +<geertu> damm: Perhaps just a wire? Then we can do SPI loopback tests +<wsa> damm: so, get your car close to the lab +<damm> great! I need an extension cable to be able to reach all the way to the + car =) +<wsa> :) +<damm> send me an email with details please [16:18] +<damm> if you do it today EU time then I can finish it this week +<damm> otherwise it will have to wait for a couple of weeks +<wsa> magnus is going to okinawa? [16:19] +<damm> just leaving the remote access location for a while [16:20] +<marex> damm: would you still be able to reinstate and/or install ssh keys ? +<damm> yeah that i can do remotely +<geertu> marex: As you're mostly familiar with the PCIe issue, can you please + handle it? +<damm> cables are more difficult =) +<wsa> marex: that would be great, in deed [16:21] +<marex> yeah +<wsa> awesome, thanks! [16:22] +<wsa> this is all from my side, any question left? +<wsa> not the case [16:23] +<wsa> geertu: ready for core? +<geertu> wsa: But but... it's not yet hh:30? +<wsa> IO group is in HS400 mode [16:24] +<geertu> please retune now ;-) +<wsa> uh oh [16:25] +<moriperi> wsa: 1 thing from me +<marex> geertu: downshift to MMC52 is hard, dont torture them +<wsa> geertu triggerd a halted system again, great! ;) +<wsa> moriperi: what is it? +<moriperi> Now BSP team is tring to enable I2C on V3U board, but has timeout + error. +<moriperi> But, it started works if some delay was added, they said. [16:26] +<moriperi> 1 concern is that V3U is *almost* same as previous SoC, but in my + understanding, previous SoC needed some workaround. +<moriperi> If V3U was fixed around I2C, workaround might be not needed + anymore. +<moriperi> Now BSP team is investigating / confirming. +<moriperi> So nothing to do today, but just information for you. +<wsa> OK +<moriperi> We will ask something to you if V3U board was ready +<moriperi> that's all from me, thanks [16:27] +<wsa> I'll just wait +<wsa> I can't recall any workaround or additional delay from the top of my + head, but we will see... +<marex> real shame there's no OSSJ this year, we could've done V3U peripericon + and bring it all up +<geertu> marex: virtual peripericon? [16:28] +<geertu> Time to launch core? +<marex> geertu: someone would have to write a qemulation of v3u +<marex> oh ... +<wsa> can't we go to Japan just for V3U bringup +<wsa> :) 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] |