path: root/wiki/Chat_log/20150708-core-chatlog

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! Geert­san!
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. Shimoda­san'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 Shimoda­san 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 as­is 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
On­chip 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/2015­May/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
write­combining?
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 page­aligned
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 non­cacheable, so that's fine
Magnus Damm ­ 11:32 AM
but the API described by Documentation/DMA­API.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 dma­engine 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
Morimoto­san?
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 Shimoda­san and Morimoto­san 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, shimoda­san
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/linux­arm­kernel/2013­April/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 e­mail 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 dma­engine 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 shimoda­san.
We can convert it English ­> Japanese, and ask to HW team. then feedback to you guys.
Is that OK ?
Magnus Damm ­ 11:53 AM
Morimoto­san, I think you can get history from Shimoda­san
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 phase­out
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 R­Car 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 R­Car 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, marzen­reference) 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 board­marzen­reference.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 setup­r88a7770.c?
Laurent Pinchart ­ 12:07 PM
and then later move to DT­based SMP support
we'll have a regression
Magnus Damm ­ 12:08 PM
laurent: we only have a regression when we decide to remove backward­support
Geert Uytterhoeven ­ 12:08 PM
(setup­r8a7779.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 phase­out 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 "enable­method" 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
morimoto­san: we are talking about removing legacy (non­multiplatform) 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 Bock­W 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 board­bockw.c and board­bockw­reference.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 multi­platform r8a7778
(VIN, USB, FPGA IRQ?)
2. Identify missing support in multi­platform r8a7779
Then
3. Add support for valuable devices to multi­platform r8a7778
4. Add support for valuable devices to multi­platform 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 board­marzen­reference.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 r8a7778­bockw.dts and r8a7778­bockw­reference.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 board­marzn­reference.c
ah ok
Magnus Damm ­ 12:34 PM
quite recently
so the board­mz­ref.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 INTC­IRQPIN 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 e­mail
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