wiki: Porting wiki: Porting Chat Log

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

1 files changed, 362 insertions, 0 deletions

diff --git a/wiki/Chat_log/20170620-core-chatlog b/wiki/Chat_log/20170620-core-chatlog
new file mode 100644
index 0000000..6bebc1c
--- /dev/null
+++ b/wiki/Chat_log/20170620-core-chatlog
@@ -0,0 +1,362 @@
+Core-chat-meeting-2017-06-20
+
+10:06 < geertu> Welcome to today's Core Group Chat!
+10:06 < dammsan> i've heard that issue before
+10:06 < geertu> pinchartl: Does it happen on H3 ES2?
+10:06 < dammsan> maybe m3-w don't recall
+10:06 < pinchartl> geertu: haha, good joke :-)
+10:06 < pinchartl> (I'll tell you when I'll have an H3 ES2.0 board...)
+10:06 < geertu> pinchartl: Havenn't you played with H3 ES2 in Tokyo?
+10:07 < pinchartl> geertu: not to the point where I could test this properly
+10:07 < geertu> Agenda:
+10:07 < geertu> 1. Status updates
+10:07 < geertu> 2. Core additional tasks
+10:07 < geertu> Topic 1. Status updates
+10:07 < geertu> A) What have I done since last time
+10:07 < geertu> B) What I plan to do till next time
+10:07 < geertu> C) Problems I have currently
+10:07 < pinchartl> dammsan: if anything comes back to your memory, please let me know
+10:07 < dammsan> ok!
+10:07 < pinchartl> (now I'll stop hijacking the meeting)
+10:07 < dammsan> (same here)
+10:07 < geertu> 'sort -R' tells me Niklas is first
+10:08 < neg> A) Nothing
+10:08 < neg> B) Nothing planed (Multimedia eats time...)
+10:08 < neg> C) None
+10:08 < neg> --eot--
+10:09 < geertu> Thank you, Niklas!
+10:09 < geertu> Next is Magnus
+10:09 < dammsan> A) IPMMU update posted
+10:10 < dammsan> B) resend IPMMU if I get enough feedback, need to review patches from Laurent
+10:10 < dammsan> C) None
+10:10 < geertu> Thank you, Magnus!
+10:11 < geertu> Next is Shimoda-san
+10:11 < shimoda> yes
+10:11 < shimoda> A)
+10:12 < shimoda>  - Nothing
+10:12 < shimoda> B)
+10:12 < shimoda>  - Get feedback about R-Car D3's CPG for Geert-san's questions
+10:12 < shimoda> C)
+10:12 < shimoda>  - Nothing
+10:12 < shimoda> -- EOT --
+10:12 < geertu> Thank you, Shimoda-san!
+10:12 < geertu> Next is Geert
+10:13 < geertu> A)
+10:13 < geertu> - RFC for CPG/MSSR module clock restore during resume
+10:13 < geertu> - Initial Salvator XS support
+10:13 < geertu> B)
+10:13 < geertu> - More suspend/resume for CPG/MSSR and PFC
+10:13 < geertu> - Mark periupport priority < H commits that are in linux-next
+10:13 < geertu> C)
+10:13 < geertu> - None
+10:13 < geertu> -- EOT --
+10:13 < geertu> Next is Marek
+10:14 < marex-cloud> Marek is broken
+10:14 < marex-cloud> A) ULCB M3 U-Boot port is posted , but only tested by booting U-Boot from U-Boot
+10:15 < marex-cloud> B) work on DT conversion of the U-Boot , so we can drop DT from Linux into U-Boot and create board ports that way instead
+10:15 < marex-cloud> C) none
+10:15 < marex-cloud> is U-Boot even part of the core group ?
+10:16 < geertu> Good question!
+10:16 < geertu> dammsan: It's not listed in my SoW ;-)
+10:17 < geertu> But as it's part of basic infrastructure, it fits better in core than in any of the other groups
+10:18 < geertu> Regarding B, that means we'll have to update U-Boot regularly, as we keep on adding more device support to the DTS?
+10:18 < marex-cloud> that's a good question
+10:19 < marex-cloud> usually you don't want to update your bootloader in a delivered product
+10:19 < marex-cloud> on a devkit, that might be easier
+10:19 < geertu> I guess if you TFTP a specific DTB, it will take precedence?
+10:19 < marex-cloud> then again, while you're adding more devices to Linux, U-Boot will only support a subset of them (we don't need ie. any of the multimedia stuff in U-Boot, maybe video out, but that's about it)
+10:20 < marex-cloud> geertu: for now, I'd like to keep bundling the DT with U-Boot just like we do on other boards
+10:20 < geertu> Or is the DTB stored in a separate partition on FLASH, so it cane be updated easily?
+10:20 < marex-cloud> geertu: we can unbundle that later, once things are a bit more fleshed out
+10:20 < marex-cloud> geertu: also, we'd probably need to patch BL2/BL3 to load two files, U-Boot and DT
+10:21 < pinchartl> marex-cloud: what "other boards" ?
+10:21 < geertu> marex-cloud: IC, as U-Boot need the DT for its own initialization
+10:22 < marex-cloud> pinchartl: other boards in U-Boot
+10:22 < geertu> it cannot load it from FLASH later.
+10:22 < geertu> s/need/needs/
+10:22 < pinchartl> marex-cloud: don't break my TFTP + NFS workflow
+10:22 < marex-cloud> geertu: there are ways around that if your flash is memory mapped, which I'm not sure the RPC supports
+10:22 < geertu> BL2/BL3 can pass a minimal DTB, and U-Boot can load a more advanced one later, which we can update when needed?
+10:22 < pinchartl> I'm fine if U-Boot needs some DT that I don't need to update more often than updating the boot loader itself
+10:22 < marex-cloud> pinchartl: eh ? how would that break it ?
+10:23 < marex-cloud> pinchartl: OK
+10:23 < pinchartl> but I want to be able to load kernel + DT over TFTP and boot them regardless of what DT is bundled with U-Boot
+10:23 < marex-cloud> pinchartl: ah, that's fine then
+10:23 < marex-cloud> pinchartl: you can use separate DTs for both (although it would be preferred if you didnt :) )
+10:24 < pinchartl> in particular, if U-Boot patches the DT (to set the DRAM size for instance), it has to patch the DT I load over TFTP
+10:24 < marex-cloud> pinchartl: U-Boot does patch the DT passed to the kernel with RAM size and ethernet MAC
+10:24 < marex-cloud> geertu: well, if that's the case already, we could use that to supply DT to U-Boot
+10:25 < pinchartl> marex-cloud: if you want to use the same DT for U-Boot and Linux, then add TFTP support to BL3 :-)
+10:25 < marex-cloud> geertu: but I'd rather like to start slow, get the DT support in at all first and then move on to fiddling with BL
+10:26 < marex-cloud> geertu: I think these are two tasks which depend on one another, but getting the DT support into U-Boot with bundled DT is much easier then complicating it with passing DT from BL
+10:27 < marex-cloud> pinchartl: just use U-Boot as your TFTP client ...
+10:27 < geertu> marex-cloud: OK, bundling a (minimal) DT is fine.
+10:28 < marex-cloud> geertu: I'd like to bundle the same DT as we use in linux, not a minimal one ...
+10:29 < marex-cloud> geertu: the less we diverge with the DT, the better
+10:29 < geertu> marex-cloud: OK, but we're still developing "the one in Linux"
+10:29 < marex-cloud> geertu: you can sync the one in U-Boot with the one in Linux, that's OK
+10:30 < marex-cloud> geertu: until Linux pulls out the DTs from it's codebase, we don't have much other options anyway ...
+10:31 < geertu> OK
+10:31 < geertu> Thank you, Marek!
+10:31 < geertu> Next is Simon
+10:33 < horms> Todo Update
+10:33 < horms>    NULL
+10:33 < horms> A) What have I done since last time
+10:33 < horms> B) What I plan to do till next time
+10:33 < horms>    No Core task at this time
+10:33 < horms> C) Problems I have currently
+10:33 < horms> D) Posted/Accepted bugfix patch
+10:33 < horms>    None
+10:33 < horms> -- end --
+10:33 < geertu> Thank you, Simon!
+10:33 < geertu> Next is Laurent
+10:34 < pinchartl> nothing on my side
+10:34 < pinchartl> as usual :-)
+10:34 < geertu> Thank you, Laurent!
+10:34 < geertu> Next is Jacopo
+10:35 < jmondi> yep
+10:35 < jmondi> A) RZ pinctrl: sent v6 off-line to collect feedback on how to handle pinmux flags inside the driver
+10:36 < jmondi> A) pinconf generic: sent patch to add output-enable, on which the RZ pinctrl depends on
+10:36 < jmondi> B) Keep working on this (mostly background due to high latencies in receiving feedbacks from gpio people)
+10:36 < jmondi> C) Null
+10:36 < jmondi> --eot--
+10:37 < geertu> Thank you, Jacopo!
+10:38 < geertu> Topic 2. Core additional tasks
+10:39 < geertu> Is anyone interested in doing a core additional task in Q3 (targets middle of August and middle of September)?
+10:39 < geertu> Topics to consider:
+10:40 < geertu>   - Taking over R-Car Gen3 CPUFreq support
+10:40 < geertu>   - Salvator-XS board support
+10:40 < geertu>   - R-Car D3 and Draak board support
+10:40 < geertu>   - DMA (as usual ;-)
+10:40 < geertu>   - As v4.14 will be the next LTS, I think it would be good to tackle the
+10:40 < geertu>     missing DT description tasks by then.
+10:40 < geertu>     Whether these are done in the context of base or additional contracts is
+10:40 < geertu>     TBD.
+10:40 < geertu>   - H3 ES2.0 PFC tasks
+10:40 < geertu>   - Emergency shutdown
+10:40 < geertu>       - Detection = I/O
+10:40 < geertu>       - Handling = core
+10:41 < horms> What is involved in the first two?
+10:41 < neg> As previusly indicated I'm interested in Emergency shutdown :-)
+10:42 < geertu> horms: Khiem posted a first version last year.  It received some review comments, but they were never adressed.
+10:43 < geertu> IIRC, the framework itself has seen some changes too, so the patches need to be updated.
+10:43 < horms> Ok, I'd be happy to look at that loose end.
+10:43 < geertu> The task is
+10:43 < geertu> CPUFreq,v4.13,public,khiem,R-Car Gen3 CPUFreq support
+10:43 < geertu> There's a related task
+10:43 < geertu> DevFreq,?,noplan,?,GPU needs DevFreq, as DVFS is shared between CPU and GPU
+10:44 < geertu> but that's more complicated, as we don't support the GPU in upstream
+10:45 < geertu> so it may be more appropriate to consider the latter as a separate task
+10:45 < jmondi> geertu: pinchartl: I only have 1 additional task for Q3 and I'm not sure where it will be allocated, but generally speaking I would be interested in looking in cpufreq.. Maybe I can help Simon on this in Q4?
+10:46 < geertu> jmondi: It's a bit too early for Q4. And we'll have to see how it goes first.
+10:46 < geertu> For D3/Draak one important question is: when will hardware be available?
+10:46 < pinchartl> jmondi: if you have time for multimedia in Q3, I'd like you to continue the work on the max9286 and rdacm20 drivers
+10:47 < jmondi> pinchartl: that will be most of my base time, on top of which there will be an additional task tbd
+10:47 < dammsan> geertu: i think remote access for D3 may be possible for first batch
+10:47 < shimoda> geertu: i will get D3 boards in early July. but i doubt it though... :)
+10:48 < geertu> dammsan: Good to hear that!
+10:48 < dammsan> shimoda: any other boards available? =)
+10:48 < geertu> Japanese "I doubt it" == "No way!"? ;-)
+10:48 < dammsan> "Maybe" == "No way"
+10:48 < dammsan> =)
+10:48 < shimoda> anyway I negotiate someone we must need a board at least :)
+10:48 < marex-cloud> geertu: since when do japanese speak english ? :)
+10:49 < shimoda> dammsan: :)
+10:49 < geertu> Do other D3 boards exist?
+10:50 < dammsan> Not sure
+10:50 < shimoda> I don't know
+10:50 < horms> I think there is a schrodinger board
+10:50 < dammsan> shimoda: how about other SoC? =)
+10:51 < shimoda> but, i heard some option boards exist for D3
+10:51 < pinchartl> dammsan: speaking of boards, is there a plan to send H3ULCBs to team members ?
+10:51 < geertu> shimoda: The MCU-board for CN50?
+10:52 < shimoda> dammsan: about V3M board, i'm asking board team when we can buy it
+10:52  * marex-cloud would be interested in M3ULCB , since they're not in stock anywhere :-/
+10:52 < dammsan> pinchartl: i think ULCBs should be purchased from within EU
+10:52 < marex-cloud> also, what about the RPC driver ? Can we do something about that ?
+10:52 < shimoda> geertu: sorry i don't know the detail
+10:52 < dammsan> however it might be wise to wait with H3 to get ES2+
+10:53 < pinchartl> dammsan: that's fine with me
+10:53 < marex-cloud> dammsan: I tried, they're not in stock, more available in ~1 month ; digikey cannot ship them from US due to restrictions
+10:53 < dammsan> shipito.com =)
+10:54 < pinchartl> dammsan: have you used that to work around export restrictions ?
+10:54 < dammsan> (they can fill in the customs declaration for you if you pay them)
+10:54 < dammsan> i use them to get stuff from the US to JP all the time
+10:54 < marex-cloud> dammsan: ooooooh :-)
+10:55 < marex-cloud> dammsan: thanks
+10:55 < pinchartl> https://www.shipito.com/en/help/faq#restricted
+10:55 < dammsan> but i fill in my papers by myself
+10:57 < marex-cloud> or maybe it's worth waiting for the ULCB to become available in EU again ?
+10:57 < dammsan> no stress from my side
+10:59  * marex-cloud really wants to test U-Boot on it :-)
+10:59 < marex-cloud> dammsan: any opinion on the RPC driver ?
+11:00 < pinchartl> (unrelated question as everybody seems idle: should I add comments such as "Under development" to the periupport file, or should I just leave the non-upported commits untouched ?)
+11:01 < horms> <2c>seems useful to me </2c>
+11:01 < pinchartl> horms: thanks
+11:01 < dammsan> marex-cloud: sorry no time to look into things yet
+11:02 < marex-cloud> dammsan: no stress :-)
+11:05 < pinchartl> horms: another related question, are commit IDs in your arm64-dt-for-v4.13 branch stable ? can I use them in periupport, or will the commits be cherry-picked/rewritten when going upstream ?
+11:06 < horms> simple answer: yes
+11:06 < pinchartl> horms: thanks
+11:06 < pinchartl> (unless something bad happens I assume, but that's ok)
+11:06 < geertu> horms: Unless Olof is in a bad mood ;-)
+11:06 < horms> That branch has been merged into ARM-SoC and is closed
+11:06 < horms> Olof was a bit grumpy but pulled them anyway
+11:07 < horms> However, before things are pulled they may change
+11:07 < pinchartl> horms: how so ?
+11:08 < horms> well for one things I make errors and fix things
+11:08 < horms> for another people ask me to drop patches
+11:08 < horms> and lastly the ARM-SoC maintainers ask for changes from time to time
+11:09 < geertu> Anyone else interested in doing a core additional task?
+11:09 < geertu> Well, you can still email me after the meeting.
+11:09 < marex-cloud> geertu: what's missing on the XS ?
+11:09 < pinchartl> horms: of course. fair enough. I was mostly interested in knowing whether the process involves modifying commits as part of the normal workflow
+11:09 < geertu> Salvator-XS,?,plan,marek,VersaClock 5P49V6901A clock generator driver
+11:10 < horms> pinchartl: no, its just for exceptions
+11:10 < geertu> marex-cloud: I assume you're already looking into that?
+11:10 < dammsan> geertu: at some point i would like to tackle the "multiple-devices" per pin issue we have with DT and PFC
+11:10 < geertu> Plus Salvator-XS has H3 ES2.0, which has very limited PFC support for now.
+11:11 < marex-cloud> geertu: patches are available, I sent them to dammsan to get an OK from him to submit to linux-clk ; will CC renesas-soc once cleared
+11:11 < geertu> But lots of pins/functions/groups can be mined from the BSP. They just need review/testing.
+11:11 < marex-cloud> geertu: speaking of that, dammsan , do I need to ask for clearance to submit patches from you always or shall I just submit ?
+11:11 < marex-cloud> dammsan: which way do you prefer to handle this ?
+11:12 < dammsan> good question
+11:12 < dammsan> i think stuff ordered directly from my is good to handle the existing way
+11:12 < marex-cloud> dammsan: if I ask for clearance every time, you have more control, but it introduces delays
+11:12 < dammsan> however for your base task time there is no need to check with me
+11:12 < geertu> Should all patches follow the reverse money path? ;-)
+11:13 < dammsan> so if you have a strict contract then talk to me
+11:13 < dammsan> otherwise ignore me
+11:13 < dammsan> makes sense?
+11:13 < dammsan> i expect everyone to coordinate with the group leaders anyway
+11:14 < pinchartl> dammsan: just curious, is there any reason to hold off by default on posting patches ?
+11:14 < dammsan> not really
+11:14 < geertu> Most H3 ES2.0 PFC work needed is small things, not worth a full additional task. So I'd recommend just doing it when scratching an itch...
+11:15 < dammsan> geertu: i noticed that ULCB has a SCIF1 as secondary debug port
+11:15 < geertu> dammsan: What's the "multiple-devices" per pin issue again?
+11:15 < dammsan> (that may not be populated on the board)
+11:15 < geertu> dammsan: Salvator-X has, too?
+11:16 < marex-cloud> dammsan: I don't quite get it, so I might just ask for your clearance until I see the pattern
+11:16 < dammsan> on those two pins for RX and TX we can chose between SCIF and HSCIF
+11:16 < dammsan> marex-cloud: thats fine
+11:16 < dammsan> geertu: so the hardware allows us to select either SCIF or HSCIF
+11:17 < dammsan> but can we do that with current DT?
+11:17 < marex-cloud> dammsan: thank you
+11:17 < dammsan> (without setting sofware policy)
+11:17 < dammsan> that's what i mean by "multiple devices" per pin
+11:18 < dammsan> i want to describe the hardware in DT =)
+11:19 < geertu> dammsan: DT overlay? (modulo aliases, for which I have a hackish patch)
+11:19  * pinchartl will have to leave soon
+11:20 < pinchartl> I'd like to briefly discuss meeting schedules if that's fine
+11:20 < marex-cloud> dammsan: is that what ie. IMX does now ? Each peripheral has a list of per-pin settings instead of what we have on RCar3 PFC ?
+11:20 < pinchartl> dammsan: you expressed the desire to group multiple meetings in the same day
+11:20 < dammsan> yes
+11:20 < pinchartl> for this week it's too late, I'll send the invitation for the multimedia meeting for tomorrow
+11:20 < dammsan> i would prefer that if possible
+11:20 < dammsan> sure
+11:20 < pinchartl> but for the next one, how would you like to handle this ?
+11:20 < dammsan> not sure what other people think
+11:21 < dammsan> i like to group together meetings and paperwork into a single day if possible
+11:21 < geertu> You want to have Core, I/O, and MultiMedia meetings on the same day?
+11:21 < dammsan> not sure what is the best way to deal with things
+11:21 < geertu> Or on the same day of week? And switch to tri-weekly?
+11:22 < dammsan> i just know that several meetings per week starting in the afternoon kind of kills the evening schedule pretty good
+11:23 < geertu> With all meetings on a single day, it may be difficult to meet timezone constraints.
+11:23 < dammsan> yeah there is that for sure
+11:23 < pinchartl> we shouldn't start earlier than 8:00 British time
+11:23 < dammsan> i would like to know if the other japanese guys have some opinion about schedule
+11:24 < pinchartl> that's 16:00 Japanese time
+11:24 < pinchartl> if we have three one-hour meetings, that's up to 19:00 in Japan
+11:24 < pinchartl> 08:00-11:00 in the UK
+11:24 < pinchartl> 09:00-12:00 in central Europe
+11:24 < pinchartl> and 10:00-13:00 in Finland
+11:25 < geertu> In Summer
+11:25 < pinchartl> yes
+11:25 < pinchartl> we'd have to strictly cap every meeting to one hour though
+11:25 < dammsan> for me, i'd rather spend one day and continue after EU lunch time instead of two days
+11:25 < pinchartl> which should be enough for status reporting
+11:26 < pinchartl> but might be short if we need to start discussing issues
+11:26 < pinchartl> or maybe 3x 1.5h meetings then ?
+11:26 < neg> Maybe status reporting can be moved to email, as done for the IO group and only talk about points of interesst during the meeting?
+11:26 < dammsan> with 2 group meetings on tue + wed and two days in the renesas office that kind of kills 4 nights without any chance for code output
+11:27 < dammsan> if we could do it before EU lunch time then that would be very nice IMO
+11:27 < pinchartl> neg: we already do status reporting through e-mail. I think it's useful to copy&paste it here, as it gives me (and others) a chance to ask questions
+11:29 < neg> pinchartl: There is no call for A/B/C updates for the Core meeting by mail, but I agree that pasting it here is usefull
+11:29 < dammsan> alternatively do brief 30 minutes per group before lunch, and schedule afternoon on-demand
+11:29 < dammsan> but do that on a single day for all groups
+11:30 < dammsan> perhaps that would make the situation worse for you guys
+11:30 < pinchartl> I don't mind personally
+11:30 < pinchartl> it would be nice if the meetings didn't overlap lunch time though
+11:31 < dammsan> it is good with dinner break at this side of the world too
+11:31  * marex-cloud doesn't mind either way
+11:32 < dammsan> how about restricting to only A/B/C before lunch EU time
+11:32 < dammsan> and propose afternoon topics on the fly
+11:32 < dammsan> then have a lunch/dinner break
+11:32 < dammsan> and get back to it
+11:32 < jmondi> it's fine for me as well, but generally speaking, 1 day of just meetings it's really bad :)
+11:33 < jmondi> but I understand the timezone thing...
+11:33 < dammsan> yeah coming home at 21:00+ several days in a row with no code output kind of sucks
+11:33 < pinchartl> another idea
+11:33 < pinchartl> if it's just A/B/C in the morning
+11:33 < pinchartl> and if we have the three groups on the same morning
+11:33 < pinchartl> do we need to split the meeting between groups ?
+11:34 < pinchartl> we could have a combined A/B/C
+11:34 < dammsan> sounds good to me
+11:34 < neg> I like that idea as well
+11:34 < pinchartl> but then who will be responsible for writing reports ? :-)
+11:35 < pinchartl> we could take turns I suppose
+11:35 < dammsan> perhaps the group leaders need to bid on each patch =)
+11:35 < pinchartl> I have to go now I'm afraid
+11:36 < pinchartl> I'll let you continue the discussion and read the result after lunch
+11:36 < dammsan> sure
+11:36 < dammsan> bon apetit
+11:36 < dammsan> !
+11:36 < pinchartl> (oh, and schedule-wise, Tuesday is probably the worst day for me, as that's the day of my weekly Linux developers lunch in Helsinki)
+11:36 < dammsan> geertu: what is your opinion about meeting schedule?
+11:37 < geertu> dammsan: We could move the A/B/C to email, and use the meeting for questions/discussions
+11:37 < pinchartl> dammsan: if you're still at the office, could you check with Morimoto-san about the Salvator-XS shipping issues ? in particular I'd like to know whether a permanent import is fine, as explained in my last e-mail
+11:38 < geertu> That frees up some time
+11:38 < pinchartl> geertu: I'd still like to copy&paste the status report here, as it often leads to questions (at least for me)
+11:38 < dammsan> pinchartl: i'm not in the renesas office. i will setup a H3 ES2 board for your remote access
+11:38 < pinchartl> copy & paste shouldn't be long
+11:38 < pinchartl> dammsan: thank you
+11:38 < pinchartl> now I really have to go
+11:38  * pinchartl is gone
+11:39 < dammsan> geertu: that sounds good to me
+11:39 < geertu> I'd prefer not to split the meeting in before/after lunch/dinner
+11:39 < dammsan> same here ideally
+11:39 < geertu> Just have 1 hour for each group? And each group leader is responsible for the report for his group, as is currently done
+11:40 < dammsan> that seems pretty straightforward and good to me
+11:40 < geertu> Round-robin reporting of a huge 3 hour meeting with topics you may not be interested in is a killer
+11:40 < dammsan> yeah for sure
+11:40 < dammsan> just want to avoid having that multiple days in a row =)
+11:41 < geertu> So it's all about making effective use of the limited time (1 hour/topic)
+11:41 < dammsan> i agree
+11:41 < geertu> s@topic@group@
+11:41 < dammsan> geertu: can we improve how we handle SCIF/HSCIF in DT somehow?
+11:42 < geertu> Or do we need a different split in 4 submeetings: Core. I/O, MultiMedia, Common?
+11:43 < dammsan> as long as they are on the same day i'm happy =)
+11:43 < geertu> I/O is usually a short meeting
+11:43 < geertu> MM is usually long?
+11:43 < dammsan> similar to core i think
+11:43 < geertu> dammsan: pinctrl-0 and pinctrl-1, cfr. SDHI?
+11:43 < neg> yes I think MM tends to be a bit longer then Core
+11:45 < jmondi> a bit longer, yes
+11:45 < dammsan> geertu: that's for two states within same device, no?
+11:46 < geertu> dammsan: I know. As SCIF and HSCIF are handled by the same driver, we could hack in something?
+11:46 < dammsan> hacking is possible for sure
+11:47 < dammsan> maybe this is similar to the I2C master switch topic
+11:47 < marex-cloud> dammsan: do you need to switch between those two at runtime ?
+11:47 < geertu> In some sense all pinctrl is "software policy"
+11:47 < geertu> have you looked at Pantelis' connector work?
+11:48 < dammsan> i saw a talk from him
+11:48 < marex-cloud> geertu: did that make it to mainline ? :)
+11:48 < geertu> I think it would allow to describe a serial port the way we wwant
+11:48 < dammsan> marex-cloud: i want to separate hardware description and software policy
+11:48 < geertu> marex-cloud: No, just like DT overlays
+11:49 < dammsan> if we can use both SCIF and HSCIF on pins then our DT should represent that somehow
+11:49 < marex-cloud> geertu: DTOs are in mainline, I think the missing part is the configfs interface for loading them
+11:49 < geertu> For the hungry people: shall we conclude the Core meeting itself? We can keep on chatting, of course.
+11:49 < dammsan> geertu: good point
+11:49 < geertu> marex-cloud: Right, that's the part I mean
+11:55 < geertu> Thanks for joinin, and have a nice continued day!