diff options
Diffstat (limited to 'wiki/Chat_log/20150708-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20150708-core-chatlog | 862 |
1 files changed, 862 insertions, 0 deletions
diff --git a/wiki/Chat_log/20150708-core-chatlog b/wiki/Chat_log/20150708-core-chatlog new file mode 100644 index 0000000..68014b1 --- /dev/null +++ b/wiki/Chat_log/20150708-core-chatlog @@ -0,0 +1,862 @@ +Geert Uytterhoeven 11:01 AM +Good morning/afternoon! +Magnus Damm 11:01 AM +Hey Geert! +Simon Horman 11:01 AM +Hi +Yoshihiro Shimoda 11:01 AM +Good afternoon! Geertsan! +Kuninori Morimoto 11:01 AM +Hi +Ulrich Hecht 11:01 AM +hello +Laurent Pinchart 11:02 AM +hello +Geert Uytterhoeven 11:02 AM +Cool, looks like it's working +Some people need pictures +Laurent Pinchart 11:03 AM +Are we having an audio conference ? +or just text ? +Geert Uytterhoeven 11:03 AM +Just text +Laurent Pinchart 11:03 AM +then why not irc ??? +Geert Uytterhoeven 11:04 AM +Good question... +Ulrich Hecht 11:04 AM +i was, in fact, even prepared for video +Geert Uytterhoeven 11:04 AM +Google Hangout is good for chat archival +Laurent Pinchart 11:04 AM +so is IRC, logs are easy +and there's more screen real estate +Geert Uytterhoeven 11:04 AM +Maybe next time on irc +Laurent Pinchart 11:04 AM +GH is a toy for text chat +Geert Uytterhoeven 11:05 AM +Well, this is a first try. +Agenda for first session: +1. IPMMU, +2. SMP DT, +3. Legacy board phase out. +A. Magnus' todo list format? +Magnus Damm 11:05 AM +Oh right +Geert Uytterhoeven 11:06 AM +I'd like to limit this to 1h30, so 20' per item? +Let's start with IPMMU. +Laurent Pinchart 11:06 AM +speaking of IRC, I believe it would be interesting to create a channel for our team. can we add that to the +agenda ? +it won't take long +Simon Horman 11:07 AM +Perhaps we can tackle that last if we have time +I agree it shouldn't take long +Geert Uytterhoeven 11:08 AM +I think IPMMU is (mostly) Laurent's kettle of fish? +Laurent Pinchart 11:08 AM +yes +what would you like to know about it ? +Magnus Damm 11:09 AM +we want to define tasks +Geert Uytterhoeven 11:09 AM +Apparently there's an issue with using IPMMU with (some) devices, cfr. Shimodasan's email +Magnus Damm 11:09 AM +and some back ground would be nice too +Geert Uytterhoeven 11:09 AM +What devices do we know IPMMU works with? +Laurent Pinchart 11:10 AM +it's not an IPMMU issue +it's a DMAC issue +we know about one IPMMU issue +Geert Uytterhoeven 11:10 AM +What devices do we know IPMMU doesn't work with? +Laurent Pinchart 11:10 AM +or rather one DMAC + IPMMU issue +Geert Uytterhoeven 11:10 AM +So I should have written IPMMU/DMAC +Laurent Pinchart 11:10 AM +in that DMAC channel 0 doesn't work properly with the IPMMU +I've raised that a long time ago +and got no feedback +Geert Uytterhoeven 11:11 AM +But we have a workaround for that, right? +Laurent Pinchart 11:11 AM +we don't know whether it has been fixed on Gen3 +the workaround is to not use channel 0 +so we're losing hardware +the second issue that Shimodasan raised is not caused by the IPMMU itself +Geert Uytterhoeven 11:12 AM +It's integration DMAC/IPMMU? +Laurent Pinchart 11:12 AM +but by the DMAC driver configuring the DMAC to issue bus master requests to a physical address even when +the accesses are translated by the IPMMU +it's a DMAC driver issue +or possibly a DMA slave driver issue +Geert Uytterhoeven 11:13 AM +Do you know how other DMAC drivers handle this? I'd assume IPMMU or not should be transparent. +Apparently all DMA slave drivers use the physical address when accessing device registers. +Laurent Pinchart 11:14 AM +as far as I can see, they don't, they're all broken +Magnus Damm 11:14 AM +From my side it looks like none of our DMA Engine slave drivers can work with IPMMU asis today, right? +But it may "only" be an issue of fixing the DMAC driver +Laurent Pinchart 11:14 AM +correct +Magnus Damm 11:15 AM +thanks for confirming my suspicion +Laurent Pinchart 11:15 AM +the DMA engine API passes the slave address as a dma_addr_t +but our drivers pass a physical address +so either we map the physical address to a DMA address in the slave drivers +or we modify the DMA engine API to pass a phys_addr_t and map the address in the DMAC driver +Geert Uytterhoeven 11:16 AM +yes, dma_slave_config uses dma_addr_t. but the docs say it's a physical address. And it's been like that since +its introduction +Magnus Damm 11:17 AM +it looks to me like the DMA Engine slave drivers are supposed to perform something similar to ioremap() to get +a virtual bus address +I think PCI device drivers tend to do something like that +but not for DMA Engine purpose +Laurent Pinchart 11:18 AM +the API documentation is incoherent +we first need to define what API we need +and then to fix the side that is broken +Magnus Damm 11:19 AM +sounds like a good plan +Geert Uytterhoeven 11:19 AM +I'm wondering why nobody else has that problem. +Magnus Damm 11:19 AM +we may want to cook up a prototype too so we can check if we can get it working at all +Geert Uytterhoeven 11:20 AM +At least on PowerPC/Cell, the IOMMU is mandatory. +Magnus Damm 11:20 AM +No one is using DMA Engine with IOMMU? +Geert Uytterhoeven 11:20 AM +On PS3, that was hidden by the hypervisor. +But on other Cell platorms, it should apply. +Magnus Damm 11:20 AM +Onchip devices with bus mastering capability is kind of common, right? +Geert Uytterhoeven 11:21 AM +spidernet doesn't use dma engine config (only dma to ring buffers) +Laurent Pinchart 11:21 AM +it could be that on some systems the DMA engine can bypass the IOMMU when it accesses slave devices, I +don't know +Geert Uytterhoeven 11:21 AM +Looking for other cell drivers... +Yoshihiro Shimoda 11:21 AM +I'm not sure but IOMMU ML is discussing PCI enviromnet +http://lists.linuxfoundation.org/pipermail/iommu/2015May/013052.html +Magnus Damm 11:22 AM +dma_map_resource() +Geert Uytterhoeven 11:22 AM +yep +Magnus Damm 11:22 AM +maybe similar to ioremap() but for devices? +Laurent Pinchart 11:22 AM +we don't need to map the whole resource, just part of it in our case +Magnus Damm 11:22 AM +right +Laurent Pinchart 11:23 AM +but in practice we can't map areas smaller than a page anyway +Geert Uytterhoeven 11:23 AM +indeed +Laurent Pinchart 11:23 AM +which, from an isolation point of view, is an issue +if we want to isolate devices, especially in virtual environment, we need to use PIO +Magnus Damm 11:23 AM +we will get a whole ton of these issues with security and virtualization +but lets save those for later +Geert Uytterhoeven 11:24 AM +I don't see any devices where we need a granularity smaller than 4 KiB? +Laurent Pinchart 11:24 AM +all of them ? +we're talking about DMA access to a hardware register +Magnus Damm 11:25 AM +i thought we sort of assigned one side at a time for the DMA API +so the CPU and the IOMMU should not be able to map at the same time +Geert Uytterhoeven 11:26 AM +Yes. What's the problem with accessing the other registers in the register block? It's the same device. +Magnus Damm 11:26 AM +writecombining? +Laurent Pinchart 11:26 AM +can you guarantee that the 4kB around the hardware register will always belong to the same device ? +Magnus Damm 11:26 AM +perhaps depends on the topology? +i think we can assume that +Geert Uytterhoeven 11:26 AM +I had a quick look at r8a7791.dtsi +(before I said "I don't see any devices where we need a granularity smaller than 4 KiB?") +CPU uses the plain MMU +DMA uses the IOMMU +Magnus Damm 11:27 AM +I think we can assume they are pagealigned +Geert Uytterhoeven 11:27 AM +Both can map the same register block ("4 KiB") at the same time +If a VM can use e.g. QSPI, it can map the registers using both MMU and IOMMU. +That's the idea, right? +Laurent Pinchart 11:28 AM +anyway, that's not an API issue, it's a hardware design issue +if multiple devices share the same 4kB page there's nothing we can do +Magnus Damm 11:28 AM +right +Laurent Pinchart 11:28 AM +and we don't need to take that into account in the API +Geert Uytterhoeven 11:28 AM +If the OS implementer is too stupid to DMA to other QSPI registers, that's his problem. He can write to these +registers using PIO too +Laurent Pinchart 11:29 AM +any other question regarding the IPMMU isssue ? +Magnus Damm 11:29 AM +i have one about the API +not about stupid users in virtualized environments +but the DMA API where I believe the "user" of a certain device is passed around and can either be the CPU or +the device +not both at the same time +so if we have a device using IOMMU with DMAC to access the hardware then is it OK to access other control +registers from the CPU? +Laurent Pinchart 11:31 AM +all the mappings will be noncacheable, so that's fine +Magnus Damm 11:32 AM +but the API described by Documentation/DMAAPI.txt allows more detailed control than that +but yes, we can treat it in a simple way for now, and more advanced usage may require different 4K pages for +different I/O areas within the save device +and in such case our hardware design may not be good enough +but shall we leave that for later? +Laurent Pinchart 11:34 AM +I'm not sure to see where the problem is +so let's leave it for later +Magnus Damm 11:34 AM +good +Laurent Pinchart 11:35 AM +no other question ? +Magnus Damm 11:35 AM +what needs to be done? +Laurent Pinchart 11:36 AM +I was going to mention that +action points for this item ? +Magnus Damm 11:36 AM +I think we need to cook up some prototype code +Laurent Pinchart 11:36 AM +1. finally get feedback from the hardware developers regarding the IPMMU + DMAC channel 0 issue +Magnus Damm 11:36 AM +to see if we can get _anything_ working at all +(haha, good luck) +Laurent Pinchart 11:37 AM +2. discuss API changes on the dmaengine mailing list +3. fix the code +1. is for Magnus +Magnus Damm 11:37 AM +I don't think so +if for anyone it would be the "Renesas interface person" +Geert Uytterhoeven 11:37 AM +Morimotosan? +Simon Horman 11:37 AM +I thought we agreed not to assign people to taks +Laurent Pinchart 11:38 AM +congratulations, you've just been appointed as the Renesas interface person ! +Yoshihiro Shimoda 11:38 AM +I will do the 1. +Geert Uytterhoeven 11:38 AM +Right +Laurent Pinchart 11:38 AM +Simon: did we ? ok +so, 3 actions points +Magnus Damm 11:38 AM +I expect both Shimodasan and Morimotosan to help out as Renesas interface for the core group +Simon Horman 11:38 AM +I may be mistaken +Laurent Pinchart 11:38 AM +1 is standalone, 3 depends on 2 +Magnus Damm 11:38 AM +thanks for stepping up, shimodasan +prototype is standalone too +Geert, can you collect these please? +Geert Uytterhoeven 11:39 AM +Sure, 3 is prototype? +Magnus Damm 11:40 AM +i thought 3 was proper implementation? +after determining the proper API +without knowing if the hardware works we can't do anything IMO +Geert Uytterhoeven 11:40 AM +Ah, so 0 is prototype +1.5 is prototype? +Magnus Damm 11:41 AM +that's better! (for me at least) +Geert Uytterhoeven 11:41 AM +BTW http://lists.infradead.org/pipermail/linuxarmkernel/2013April/165411.html +Laurent Pinchart 11:41 AM +I don't see a need for a prototype +Geert Uytterhoeven 11:41 AM +Arnd: The dma engine driver must know the address in its dma space, while the +slave driver has it available in physical space. These two are often the +same, but there is no generic way to convert between the two, especially +if the dma engine resides behind an IOMMU. +The best assumption we can make is that the dma engine driver knows +how to convert between the two. Interestingly the documentation for +dma_slave_config talks about "physical address", while the structure +itself uses a dma_addr_t. Linus Walleij introduced the structure in +c156d0a5b0 "DMAENGINE: generic slave channel control v3", so I assume +he can shed some light on what he was thinking. I assume the documentation +is right but the structure is not and should be converted to use +phys_add_t or resource_size_t. +Simon Horman 11:41 AM +I think it is likely some kind of loop between discuss and implement may emerge +Magnus Damm 11:42 AM +Laurent: have you tried DMA Slave API with IOMMU? +Laurent Pinchart 11:42 AM +Simon: agreed +Geert Uytterhoeven 11:42 AM +(Arnd should know, as he did PowerPC/Cell before, where the IOMMU is mandatory. Some scanning in the +sources makes me think it was al handled by the (real) Open Firmware on Cell) +Laurent Pinchart 11:42 AM +Magnus: no, and I'm not worried about it. it's an API issue +Magnus Damm 11:43 AM +I'm worried that we found it out at this timing. +I thought it was tested and ready to integrate +Geert Uytterhoeven 11:43 AM +Yes +Magnus Damm 11:44 AM +I agree that a proper API is needed +Geert Uytterhoeven 11:44 AM +Hence my question " +What devices do we know IPMMU works with?" in the beginning +But we're running out of time for this topic? +Laurent Pinchart 11:44 AM +ok, there's a discussion of the issue in that email thread +Magnus Damm 11:44 AM +I've tested the IPMMU with the DU +Geert Uytterhoeven 11:44 AM +s/we're running/we ran/ +Laurent Pinchart 11:44 AM +we need to study it and revive it +Yoshihiro Shimoda 11:45 AM +I have tested the IPMMU with xhci +Laurent Pinchart 11:45 AM +DU, VSP1 and DMAC (in mem to mem mode) have been tested +Magnus Damm 11:45 AM +I also tested USBHS +with some prototype patches +Simon Horman 11:45 AM +by tested, is the implication that they work? +Magnus Damm 11:45 AM +at least it may work +I believe USBHS needs more work +Yoshihiro Shimoda 11:46 AM +xhci works, I think +Magnus Damm 11:46 AM +but it is separate from the DMAC issue that sort of holds back a whole range of devices +But with USBHS I've seen that the hardware seems to work +I never seen anything like that for DMAC and IPMMU combo with DMA Engine slave +so may I add a prototype task just to test the hardware? +Laurent Pinchart 11:48 AM +Magnus: I think that's overkill +the DMA engine API needs to be fixed anyway +Magnus Damm 11:49 AM +Well, I don't want to flame, but I expected you to do this for your MMCIF work last summer after the IOMMU +and DMAC work +sure +Im not arguing against fixing the API +Laurent Pinchart 11:49 AM +that's interesting, because I'm pretty sure I've tested MMCIF +Magnus Damm 11:50 AM +So i thought it was tested +but it seems to not work at all +I should have tested on my side +so no blame on you +Laurent Pinchart 11:50 AM +I clearly remember running into issues with channel 0 + IOMMU with MMCIF +and not with channel 1 +Magnus Damm 11:50 AM +But looking at it now it seems that it couldn't ever work +Geert Uytterhoeven 11:50 AM +cfg.src_addr = res>start + MMCIF_CE_DATA; +Magnus Damm 11:51 AM +laurent: i'm not trying to get you to write a prototype +just saying that we need to do it +actual assignment is a different matter +Geert Uytterhoeven 11:51 AM +We just ran out of time for topic 2 +Magnus Damm 11:52 AM +haha +Geert Uytterhoeven 11:52 AM +Topic 2. SMP DT, +Magnus Damm 11:52 AM +So what does the Core Group leader say about prototyping? +Geert Uytterhoeven 11:52 AM +I wrote down: +Magnus Damm 11:52 AM +I will follow our leader penguin +Geert Uytterhoeven 11:52 AM +1. finally get feedback from the hardware developers regarding the IPMMU + DMAC channel 0 issue +2. implement prototype +3. discuss API changes on the dmaengine mailing list +4. implement proper solution +Kuninori Morimoto 11:52 AM +About quetion to HW team, +I can ask to HW team any quetion, but then I need "original question mail" from you guys. +It is difficult to create it by myself, since I don't know detail of this issue/background/problem. +Then, please send question email to my or shimodasan. +We can convert it English > Japanese, and ask to HW team. then feedback to you guys. +Is that OK ? +Magnus Damm 11:53 AM +Morimotosan, I think you can get history from Shimodasan +or me +Geert Uytterhoeven 11:53 AM +If the original answer is VHDL, please don't translate VHDL > Japanese > English +Topic 2. SMP DT +Magnus Damm 11:53 AM +ok +Geert Uytterhoeven 11:55 AM +This is about properly handling this with DT support, which is not backwards compatible with old DT +And it hinders topic 3. Legacy board phase out. +Magnus, you had patches to move forward? +Magnus Damm 11:55 AM +(Only if we want to) +Yeah, I think it is fine to disconnect the DT SMP enablement from the board phaseout +Simon Horman 11:56 AM +From my point of view the key is to undersand how we can move forward with the new DT SMP properties. +Magnus Damm 11:56 AM +This because DT SMP is likely to take quite a bit of time +Simon Horman 11:56 AM +While handling backwards compatibility in some controlled fashion +Magnus Damm 11:56 AM +Especially if we are going to open the can of worms with challenging the current API +Geert Uytterhoeven 11:57 AM +Yes +Magnus Damm 11:57 AM +s/API/DT style/g +Simon Horman 11:57 AM +And from my point of view r8a7779/marzen is a particularly interesting/difficult case +Magnus Damm 11:58 AM +I think it is a silly case, because we have nothing to share code with for r8a7779 +at least for RCar Gen2 we can use a new DT format to enable SMP on remaining SoCs +r8a7779 is breakage only without upside. complete wank +Geert Uytterhoeven 11:59 AM +And we don't care about DT backward compatibility for RCar Gen1 +Magnus Damm 11:59 AM +Well.. +We have some freedom +Simon Horman 12:00 PM +[to summarise the interesting/difficult big] we have an SoC (r8a7779) compat string which does not support +SMP while we have board (marzen, marzenreference) compat strings which do support SMP. And the default +configuration gives the latter. +s/big/bit/ +Magnus Damm 12:01 PM +What's the upside of doing SMP DT first? +(or doing it at all) +I mean compared to phasing out board support first +Geert Uytterhoeven 12:02 PM +For Gen1 or Gen2? +Magnus Damm 12:02 PM +r8a7779 +Geert Uytterhoeven 12:02 PM +We don't break SMP +Magnus Damm 12:02 PM +We do require DTB update for the existing boards, no? +which equals breakage +Geert Uytterhoeven 12:03 PM +Yes. So we have to update the DTB to keep SMP. +Magnus Damm 12:03 PM +if we do SMP DT first +Simon Horman 12:03 PM +taking a step back +Geert Uytterhoeven 12:04 PM +I understand there will be only one mandatory DT upgrade instead of two? +Simon Horman 12:04 PM +I believe we already support SMP for marzen using multiplatform +Magnus Damm 12:04 PM +simon: correct SMP is already supported by boardmarzenreference.c +Geert: I don't see the number of required updates? +Geert Uytterhoeven 12:06 PM +Forget about it, I think I'm mixing up with something else +Magnus Damm 12:06 PM +So adding a DT SMP dependency just delays things from my point of view +and by "things" i mean board cleanup +Laurent: Can you explain your concern? +Laurent Pinchart 12:07 PM +if we add SMP support through the machine description first +Simon Horman 12:07 PM +and by cleanup, your mean removal, right? +Geert Uytterhoeven 12:07 PM +For r8a7779 we may do without SMP DT. What prevents us from adding .smp = +smp_ops(r8a7779_smp_ops), to setupr88a7770.c? +Laurent Pinchart 12:07 PM +and then later move to DTbased SMP support +we'll have a regression +Magnus Damm 12:08 PM +laurent: we only have a regression when we decide to remove backwardsupport +Geert Uytterhoeven 12:08 PM +(setupr8a7779.c, of course) +Laurent Pinchart 12:08 PM +Magnus: of course +and I'd like to remove that +or, rather, not introduce it in the first place +Magnus Damm 12:08 PM +simon: cleanup = removal, yes +but we already have that for the board case, no? +so it is a matter of when to remove it? +Laurent Pinchart 12:09 PM +it's bad enough when we only have to deal with backward compat for unforeseen issues +if we already know that bindings will become deprecated before using them, it's even worse +Magnus Damm 12:10 PM +i thought we already were using them? +Laurent Pinchart 12:10 PM +on some platforms yes +my point is about new platforms +Magnus Damm 12:10 PM +on all r8a7779 systems +new platforms of course +but r8a7779 is not new +Geert Uytterhoeven 12:11 PM +I think ignoring DT SMP for r8a7779 makes sense. We already have enough to do for Gen2 +(and Gen3) +Magnus Damm 12:11 PM +We can perhaps keep an incremental DT SMP for r8a7779 task around? +But not let that block board phase out +Geert Uytterhoeven 12:11 PM +yes +task added +What about Gen2? +Magnus Damm 12:12 PM +We should add SMP DT before adding SMP support for new SoCs +Simon Horman 12:12 PM +magnus: would that retain the current beaviour where multiplatform supports SMP for marzen? +Magnus Damm 12:12 PM +but before adding SMP DT I want to discuss the DT format with ARM SoC maintainers +Geert Uytterhoeven 12:12 PM +Yes, else we're "too late", and stuck with more backward compatibility +Magnus Damm 12:13 PM +simon and geert: i'm confused with mix of marzen and Gen2, please rephrase +Simon Horman 12:13 PM +perhaps I am confused. Geert, did you have a proposal? +Geert Uytterhoeven 12:14 PM +If we add SMP support for new SoCs before adding SMP DT, we're "too late", and stuck with more backward +compatibility +Magnus Damm 12:14 PM +Geert: we will not +we have the "old way" for r8a7790 and r8a7791 +Geert Uytterhoeven 12:14 PM +not add support? Not be late? +Laurent Pinchart 12:14 PM +if we go strought for SMP DT for new SoCs I'll be happy, I don't need more +s/strought/straight/ +Magnus Damm 12:15 PM +Laurent: of course, i thought that's what we're doing +perhaps I'm wrong, but I thought newer SoCs don't include SMP support at this point +Simon Horman 12:15 PM +I think that is the nub of the issue +Magnus Damm 12:15 PM +Ulrich: do you know hte current state? +Geert Uytterhoeven 12:15 PM +Does that include the option to use new SMP DT (with a new DT of course) on '90/'91? +Simon Horman 12:15 PM +We should use the latest way to handle new SoCs. +Magnus Damm 12:15 PM +yes of course +Ulrich Hecht 12:16 PM +of what? +Magnus Damm 12:16 PM +if newer kernel suport for SoCs include SMP support or not? I don't remember latest state, but i believe you +hacked on it +My series "[PATCH 00/04] ARM: shmobile: APMU DT support via SMP Enable method" is intended to upgrade +SMP DT on r8a7790 and r8a7791, and be the only format for newer SoCs +Laurent Pinchart 12:17 PM +Geert: for 90 and 91, I'd like to add support for SMP DT and deprecate smp_ops. we'll have to keep them for +backward compatibility of course, and hopefully phase them out at some point +Ulrich Hecht 12:17 PM +no, i'm not aware +Geert Uytterhoeven 12:17 PM +OK +Magnus Damm 12:18 PM +ulrich: ok +Laurent Pinchart 12:18 PM +it looks like we all agree, don't we ? +Magnus Damm 12:18 PM +i think so +good +Simon Horman 12:18 PM +can we clafiry what we agreed on +? +Magnus Damm 12:18 PM +but i still want to discuss with ARM SoC maintainers about the existing format +Laurent Pinchart 12:18 PM +action points ? discuss SMP DT bindings with ARM SoC maintainers ? +Magnus Damm 12:18 PM +yeah +Geert Uytterhoeven 12:18 PM +Running out of time +Magnus Damm 12:18 PM +that is one task for sure +another task is APMU DT support +Simon Horman 12:19 PM +ok, geert, perhaps you could summarise things in an email +Geert Uytterhoeven 12:19 PM +My task list is +1. discuss SMP DT bindings with ARM SoC maintainers +2. Add DT SMP support for new SoCs (r8a7793/r8a7794) +A. Plan phaseout of old smp_ops for r8a7790/r8a7791 +B. DT SMP for r8a7779 +Magnus Damm 12:19 PM +sweet, thanks!! +Geert Uytterhoeven 12:19 PM +Isn't APMU DT included? +Magnus Damm 12:19 PM +it is part of 2 +Geert Uytterhoeven 12:20 PM +I mean, needed for seconary bringup? +Magnus Damm 12:20 PM +currently C structures encode the base address of the APMU +DT is on the way +Geert Uytterhoeven 12:20 PM +yes, that needs to move to DT +Magnus Damm 12:20 PM +but I rather handle it together with the silly "enablemethod" or whatnot +Geert Uytterhoeven 12:21 PM +yep +Topic 3. Legacy board phase out. +r8a7740 and sh73a0 are gone +r8a7778 and r8a7779 are next +Simon Horman 12:22 PM +is anything blocking the Gen1 boards? +Geert Uytterhoeven 12:22 PM +(esp. r8a7779 would make SYSC PM domains less work) +Kuninori Morimoto 12:22 PM +Can we remove r8a7778/r8a7779 support from driver then ? if so it is very good for me +Simon Horman 12:22 PM +I know we just talked about SMP for the 79. But anying else? +Magnus Damm 12:22 PM +Now when r8a7779 SMP DT has been agreed then we can fix that +I will resubmit patches +Geert Uytterhoeven 12:23 PM +we still need '78/'79 support in drivers, but only DT based +bockw mostly needs vin etc? +Simon Horman 12:23 PM +morimotosan: we are talking about removing legacy (nonmultiplatform) support. Not all support. +Kuninori Morimoto 12:24 PM +sorry +Simon Horman 12:24 PM +Ok, so some vin bindings are a dependency for removing bockw legacy? +Magnus Damm 12:24 PM +can anyone volunteer to get rid of r8a7778 legacy? +and finalize the conversion? +Geert Uytterhoeven 12:25 PM +The pins are in the dts, but not the vin enablement +Magnus Damm 12:25 PM +in reverse order? +How many BockW boards do we have? +Laurent Pinchart 12:25 PM +what are the missing pieces beyond vin ? +Magnus Damm 12:25 PM +I have one +Simon Horman 12:25 PM +I could look into that +Geert Uytterhoeven 12:25 PM +usb is missing +Simon Horman 12:26 PM +ok, so its enabled in board code but not in DT? +Geert Uytterhoeven 12:26 PM +yep +Simon Horman 12:26 PM +ok +Geert Uytterhoeven 12:26 PM +(was the same on armadillo, there it was known borken) +Laurent Pinchart 12:26 PM +are we missing USB DT support completely, or is it just a matter of enabling it ? +Simon Horman 12:26 PM +how about I start by looking at exactly what is missing: so far the list is vin and usb DT enablement +Laurent Pinchart 12:26 PM +how about the FPGA IRQ controller ? +Geert Uytterhoeven 12:27 PM +task added +Simon Horman 12:27 PM +i have (remote) access to the hw. so that is a start +Magnus Damm 12:27 PM +simon: ok, but pretty useless for USB and VIN +Simon Horman 12:27 PM +i also suspect ethernet is broken all over the place for gen1. that could be another task. +Magnus Damm 12:27 PM +and real physical hardware seems like a waste of time +in general r8a7778 seems like a waste of time to me +but that's just me +Simon Horman 12:28 PM +ok +shold we jsut remove it from mainline entirely? +Magnus Damm 12:28 PM +add a task: give magnus coffee to make him less grumpy +Simon Horman 12:28 PM +or leave it there without usb and vin enabled? +Magnus Damm 12:28 PM +Simon, you are interested in fixing it up? +is it possible to do so remotely? +Geert Uytterhoeven 12:29 PM +fpga is in both boardbockw.c and boardbockwreference.c +Magnus Damm 12:29 PM +and is that our only board? +Geert Uytterhoeven 12:29 PM +needed for sound and ethernet? +Simon Horman 12:29 PM +usb sounds possible to me +vin, perhaps not +Magnus Damm 12:30 PM +so perhaps USB and VIN shall be moved to I/O and Multimedia discussions? +and we can decide to either wait for those or just remove regardless +Simon Horman 12:30 PM +good idea +I'm interested in getting bockw fixd to whatever level we agree is sane. +Magnus Damm 12:30 PM +Maybe we can vote on what level is sane? +Simon Horman 12:31 PM +I would not object +Geert Uytterhoeven 12:31 PM +Before we can vote, we need +Simon Horman 12:31 PM +anyway, i will look at what is missing +Geert Uytterhoeven 12:31 PM +1. Identify missing support in multiplatform r8a7778 +(VIN, USB, FPGA IRQ?) +2. Identify missing support in multiplatform r8a7779 +Then +3. Add support for valuable devices to multiplatform r8a7778 +4. Add support for valuable devices to multiplatform r8a7779 +sorry, 2b vote +Simon Horman 12:32 PM +sounds good +Magnus Damm 12:32 PM +Geert: Sure, that is true, but there are cleanups needed before 1 too +Geert Uytterhoeven 12:32 PM +6. Drop legacy r8a7778/bockw +7. Drop legacy r8a7779/marzen +Simon Horman 12:32 PM +shall I take 1 and 2(a) ? +Magnus Damm 12:32 PM +for instance, for r8a7779 we can remove the boardmarzenreference.c +and for r8a7778 I think we have split DTSI still? +Simon Horman 12:32 PM +cleanups required to identify what is incomplete? +Magnus Damm 12:33 PM +no my 0 cleaups are independent +i'll fix r8a7779 +Geert Uytterhoeven 12:33 PM +Yes r8a7778bockw.dts and r8a7778bockwreference.dts +Magnus Damm 12:33 PM +but someone needs to fix r8a7778 +who had r8a7779 multiplatform as task? +Simon Horman 12:33 PM +it should not be as difficule at 79 +Magnus Damm 12:33 PM +i mean r8a7778 multiplat +Simon Horman 12:33 PM +as its UP, right? +Laurent Pinchart 12:34 PM +Magnus: don't we also miss r8a7779_init_irq_extpin ? +Magnus Damm 12:34 PM +laurent: it has been fixed already +Laurent Pinchart 12:34 PM +it's called from boardmarznreference.c +ah ok +Magnus Damm 12:34 PM +quite recently +so the boardmzref.c is ready to go after some minor SMP bit +but r8a7778 is more messy +Laurent Pinchart 12:35 PM +where's the fix ? +Magnus Damm 12:35 PM +it should have been picked up by simon +it was in the same series as where you questioned the SMP DT order for r8a7779. +let me find it +Laurent Pinchart 12:36 PM +"[PATCH v2 01/06] ARM: shmobile: r8a7779: Configure IRLM mode via DT" ? +Magnus Damm 12:36 PM +yes +Geert Uytterhoeven 12:36 PM +We ran out of time +Laurent Pinchart 12:36 PM +ok, I didn't realize it was about that +Magnus Damm 12:36 PM +once all contents of "[PATCH v2 00/06] ARM: shmobile: r8a7779 IRQ update and Marzen cleanup V2" are in i +intend to remove legacy code too +Laurent Pinchart 12:37 PM +by the way the commit message says "Adjust the r8a7779 SoC DTS and the Marzen Reference +C board code to use DTS only for INTCIRQPIN IRLM setup." +Magnus Damm 12:37 PM +but step by step +Laurent Pinchart 12:37 PM +but the patch doesn't touch C board code +Magnus Damm 12:37 PM +the board removal patch takes care of that i think +Laurent Pinchart 12:37 PM +yes it does +Magnus Damm 12:38 PM +so who can do r8a7778? +who did it initially? +Ulrich Hecht 12:38 PM +r8a7778 MP was me +but i don't have a board, making usb and vin difficult +Geert Uytterhoeven 12:38 PM +We found a winner +Magnus Damm 12:38 PM +you have a core developer task, right? +Ulrich Hecht 12:39 PM +me? yes, i do +Magnus Damm 12:39 PM +if so, can you move the multiplatform support forward? +like getting rid of that duplicated DTS setup +and things that do not depend on vin and usb +Geert Uytterhoeven 12:40 PM +Guys, we're running late. And my daughters want me to join lunch +Ulrich Hecht 12:40 PM +i just checked, and i think the list of missing stuff is conclusive. so apart from usb and vin, there's the fpga +Magnus Damm 12:40 PM +ok ok +Geert Uytterhoeven 12:40 PM +I will send the task list to periperi for final review +Magnus Damm 12:40 PM +thanks a lot everyone +Geert Uytterhoeven 12:40 PM +yes, thanks a lot. +Magnus Damm 12:40 PM +and thanks for preparing the task list geert!! +and arranging this meeting +Simon Horman 12:40 PM +Likewise, thanks everyine +Geert Uytterhoeven 12:41 PM +Will send out an invitation and RFC for topics for next chat +Magnus Damm 12:41 PM +wonderful +Laurent Pinchart 12:41 PM +what about the todo list format ? next time ? +Ulrich Hecht 12:41 PM +thanks, too. and if someone can give me a hint as to how to handle the fpga, i'd appreciate it +Magnus Damm 12:41 PM +ulrich: you can probably merge DTS independently of FPGA +Geert Uytterhoeven 12:41 PM +the fpga seems to be needed for Ethernet +Laurent Pinchart 12:41 PM +Ulrich: you might need to write a driver for the FPGA I'm afraid +Ulrich Hecht 12:41 PM +yes, of course +Laurent Pinchart 12:41 PM +I can assist with that +Ulrich Hecht 12:42 PM +that would be helpful. i couldn't find anything similar on other platforms +Laurent Pinchart 12:42 PM +we can discuss it later. on IRC maybe ? +Geert Uytterhoeven 12:42 PM +bye! (I'll keep the chat window open, though) +Magnus Damm 12:42 PM +bye bye! +Ulrich Hecht 12:43 PM +i'd prefer something more asynchronous, like email +Simon Horman 12:43 PM +I also need to attend to family matters, but will leave this window open. I expect to be back in 20min or so +Laurent Pinchart 12:43 PM +Ulrich: that works too +Ulrich Hecht 12:43 PM +ok, thanks a lot +Kuninori Morimoto 12:47 PM +Bye, I go back to my home +Yoshihiro Shimoda 12:50 PM +Bye! I also go back to my home |