All of lore.kernel.org
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: Update: ARM Sub-Architecture Maintainers workshop at Kernel Summit 2011
Date: Wed, 12 Oct 2011 11:01:09 +0100	[thread overview]
Message-ID: <20111012100109.GB13134@arm.com> (raw)
In-Reply-To: <CACxGe6vMLeHrN7jLB2=JYQON1ykOiWTeGiH8YXkUbguV0D-HEw@mail.gmail.com>

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.

- 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).

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.

Thanks.

-- 
Catalin

  parent reply	other threads:[~2011-10-12 10:01 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-30  6:00 Update: ARM Sub-Architecture Maintainers workshop at Kernel Summit 2011 Grant Likely
2011-08-30  6:27 ` Igor Grinberg
2011-08-30 13:44   ` Grant Likely
2011-08-30 14:00     ` Igor Grinberg
2011-08-30 19:17     ` [Ksummit-2011-discuss] " Chris Ball
2011-08-30 12:55 ` Nicolas Ferre
2011-08-30 13:56 ` Wolfram Sang
2011-08-30 14:42 ` David Brown
2011-08-30 16:58 ` Paul Walmsley
2011-08-30 19:51 ` Olof Johansson
2011-08-30 23:42   ` Stephen Warren
2011-08-31  5:50   ` Marek Szyprowski
2011-08-30 23:10 ` Pavel Machek
2011-08-31  1:29   ` Marek Vasut
2011-08-31  2:31     ` Bryan Wu
2011-08-31  2:58       ` Marek Vasut
2011-08-31  3:07         ` Bryan Wu
2011-08-31 18:57     ` Grant Likely
2011-08-31  2:57 ` Bryan Wu
2011-08-31  2:59   ` Marek Vasut
2011-08-31  3:08     ` Bryan Wu
2011-08-31  4:01       ` Marek Vasut
2011-08-31  5:52         ` Eric Miao
2011-08-31 15:15 ` Marc Zyngier
2011-09-27 13:25 ` Igor Grinberg
2011-10-12  9:14   ` Igor Grinberg
2011-10-12  9:19     ` Catalin Marinas
2011-10-17 17:36       ` Igor Grinberg
2011-10-12 15:33     ` Nicolas Pitre
2011-10-17 17:31       ` Igor Grinberg
2011-10-12 10:01 ` Catalin Marinas [this message]
2011-10-12 15:00   ` Nicolas Pitre
2011-10-17  8:54 ` Catalin Marinas
2011-10-17 10:56   ` Marek Vasut
2011-10-20 13:35 ` Linus Walleij
2011-10-20 13:48   ` Jonathan Cameron
2011-10-20 14:25     ` Barry Song
2011-10-20 14:46       ` Mark Brown
2011-10-20 14:55         ` Jonathan Cameron
2011-10-21  9:39           ` Barry Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111012100109.GB13134@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.