<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   hverkuil: <u>mchehab</u>: will you be able to merge this pull request this week? https://patchwork.linuxtv.org/patch/31670/
   ***: prabhakarlad has left
   hverkuil: <u>mchehab</u>: will you be able to merge this pull request this week? https://patchwork.linuxtv.org/patch/31670/
   <br> <u>mchehab</u>: posted v2 of the draft agenda. Should be pretty close to final.
   mchehab: <u>hverkuil</u>: I'm planning to pull the remaining patches for -next this week
   <br> last week I was at LatinoWare
   <br> I'll take a look at v2 of the agenda
   javier__: <u>mchehab</u>: are you also planning to push the fixes for 4.3 this week?
   mchehab: yes
   javier__: <u>mchehab</u>: great, thanks
   larsc: <u>pinchartl</u>: what exactly is the synchronization issue with the rcar DMA driver?
   <br> you've added the synchronize_irq to both terminate_all() and free_resources(), but wouldn't it only be needed for free_resources()?
   pinchartl: it's needed in free_resources()
   <br> and terminate_all() should or should not be synchronous depending on who you ask and on the phase of the moon
   larsc: I've implemented the dmaengine_synchronize() API and it seems to work http://pastebin.com/kfvEDZEW
   bparrot: pinchartl, i am in Dallas
   ***: benjiG has left
   pinchartl: <u>larsc</u>: the DMA engine API has failed to meet our expectations lately, and quite a few changes are needed. I'm wondering whether they shouldn't be addressed as part of a plan instead of working on them in a ad-hoc fashion
   <br> <u>bparrot</u>: so FOSDEM would be a bit far away for you, especially if Hans can't attend
   <br> ELC would be the best
   <br> and not that much later than FOSDEM anyway
   bparrot: yeah i'll shoot for elc. do you attend those also normally?
   larsc: <u>pinchartl</u>: if you can come up with a masterplan
   pinchartl: <u>bparrot</u>: yes I do
   <br> <u>larsc</u>: give me a time machine :-)
   <br> <u>larsc</u>: will you be in Seoul next week ?
   larsc: no
   <br> no more conferences this year
   <br> only work work work! ;)
   mchehab: shuah, hverkuil, pinchartl: did you receive the invitation for KS workshop? it seems you didn't register so far
   pinchartl: :-)
   shuah: <u>mchehab</u>: I received the invitation and registered week or two ago - let me double check
   <br> hmm. I have my registration confirmation saved on Sept 30th - logging into check
   <br> My registration looks good - I am registered for WS, KLF, and KS
   pinchartl: WS and KLF are on the same day, right ?
   shuah: yes there is an overlap
   <br> Oct 26th is going be very busy :)
   pinchartl: I haven't registered for the KLF. should I ?
   shuah: Just do it! I am speaking from 11:15 to 12:05 on ALSA and Au0828 work on MC Next Gen :)
   <br> I have lots of cool media graphs in my presentation
   pinchartl: :-)
   <br> done
   <br> speaking of ALSA and MC, looks like ALSA is working on another API...
   shuah: to solve what we are trying to solve
   larsc: it's not so easy
   <br> there is some overlap
   <br> would be nice to have something that eventually is the superset of what both need
   pinchartl: what are the ALSA needs not covered by MC ?
   larsc: loading topology from userspace
   <br> that's for topology that describes the graph implemented by a firmware that runs on a DSP
   <br> and well that part is already in the upstream kernel
   pinchartl: would the topology be bound with the firmware ? possibly included in the firmware file ?
   larsc: yes
   <br> http://alsa-project.org/files/talks/summit-autumn-2015/Topology%20Status.pdf
   pinchartl: so in a way the firmware would bind both the DSP binary and the firmware binary to be interpreted by the kernel
   <br> that looks a bit out of scope for MC
   larsc: well the firmware has topology information that is imported and MC has topology information that is exported
   <br> that's the connection between the two
   pinchartl: sure, but I wonder whether there would really be an overlap
   <br> the ALSA firmware parser/importer would create media entities
   larsc: What Intel wants to do is also export the topology again using the same format it is used to import it
   pinchartl: and the MC API would expose them to userspace
   <br> it looks like a clear separation to me :-)
   <br> ah
   <br> so a way to read back the topology blob ?
   larsc: Including all the other hardware topology information
   <br> stuff that comes from ACPI and DT
   pinchartl: is there a specific reason why Intel wants the same format ?
   larsc: so the same tools can be used for importing as for exproting
   <br> exporting
   pinchartl: it doesn't look like the same tool to me. there's binary blob generation on one side and binary blob parsing on the other side. I don't think there would be much code reuse
   larsc: how and the other argument was that MC needs IOCTLs while they want to use cat and echo
   pinchartl: cat to retrieve a binary blob that will need a specific application to be parsed anyway
   <br> that's made up :-)
   broonie: No, their use case is getting stuff off a remote system onto a development machine which has the tooling.
   larsc: <u>pinchartl</u>: have you seen Liam's mail?
   pinchartl: <u>broonie</u>: good point
   <br> <u>larsc</u>: no
   larsc: right, probably filtered
   <br> I forwarded it to you
   pinchartl: thanks
   larsc: <u>pinchartl</u>: the DMA synchronization issue, where did that occur for you? audio or somewhere else?
   pinchartl: do you mean the need for a synchronous terminate_all() ?
   larsc: yes, the patch you send was supposed to fix a observed problem, I guess
   pinchartl: it fixed a problem with free_resources() and touched terminate_all() as a side effect
   larsc: but was this in audio or somewhere else?
   pinchartl: the problem that was reported to me didn't mention terminate_all()
   <br> I think it was in audio
   <br> but I'm not sure
   larsc: k