On Wed, 12 Oct 2011, Catalin Marinas wrote:

Hi Grant,

On Tue, Aug 30, 2011 at 07:00:16AM +0100, Grant Likely wrote:

quoted

Agenda proposals (Thanks to Nicolas and Olof):
- DT bindings for GPIO and pin mux
- the pin mux subsystem from linusw (especially if it is still RFC by
 then)
- progress with the single zImage work
- presentation/status of the DMA and memory management work wrt CMA
 (some SOC specific hacks should go away once this is available)
- DT porting progress
- boot architecture status
- Report from Arnd on experiences from first arm-soc merge window
  - what worked well and where's room for improvement?
  - Any particular SoC workflow that should be tuned to make his life easier?
  - Where are the gaps where he needs help right now?
  - How did it work out for the SoC maintainers?

Some more thoughts, probably under some of the above topics like single
zImage or boot architecture if there is time on the agenda:

- Errata (CPU, cache controller etc.) workarounds - do we need some
  common way to register workarounds that individual SoCs need to be
  enabled during boot? With a single zImage platform, we need to enable
  as many (CPU) errata workarounds as possible but, even though we check
  the CPU revision, we may find that some undocumented bits cannot be
  set because Linux is running in non-secure mode (and the secure code
  on the SoC doesn't set the bit either) or the SoC already implemented
  an ECO fix and the workaround is no longer needed.

Yes, that would be good to cover during single zImage discussions.

- CPU topology - Vincent Guittot proposed patches to automatically
  generate a CPU topology based on the MPIDR. I think we should be able
  to override this using some DT description (and also be able to
  describe the mapping between GIC CPU interfaces and the CPU numbering
  via DT).

I think some discussion around DT bindings is planned.  That would fit 
there.

Unrelated to the above

- Different DMA coherency requirements within the same SoC - this is
  linked to the work already started by Marek on dma_map_ops (though the
  focus was mainly IOMMU). Basically there are SoCs where some device
  requires non-cacheable memory while another device is connected via a
  coherency port and can snoop the CPU caches. The arch_is_coherent()
  that we currently have is not fine-grained enough for this task.

If you have actual example use cases and solution proposals then this 
could certainly be brought up during DMA oriented discussions.


Nicolas