Update: ARM Sub-Architecture Maintainers workshop at Kernel Summit 2011

Nicolas Pitre nicolas.pitre at linaro.org
Wed Oct 12 11:00:10 EDT 2011


On Wed, 12 Oct 2011, Catalin Marinas wrote:

> Hi Grant,
> 
> On Tue, Aug 30, 2011 at 07:00:16AM +0100, Grant Likely wrote:
> > 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



More information about the linux-arm-kernel mailing list