diff options
Diffstat (limited to 'wiki/Chat_log/20170620-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20170620-core-chatlog | 362 |
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! |