On Friday 08 March 2013, Tomasz Figa wrote:
I have a question regarding making this an MFD driver.
As you know, the main clocksource driver must be initialized early, from
init_time callback of machine_desc. How does using the MFD subsystem fit
into this scheme?
P.S. I'm still not
On Thursday 07 of March 2013 08:22:03 Thierry Reding wrote:
On Thu, Mar 07, 2013 at 03:02:46AM +, Arnd Bergmann wrote:
On Wednesday 06 March 2013, Thierry Reding wrote:
Option 2 would probably come down to having a trivial MFD driver
exposing a regmap. You can probably reuse
On Wed, Mar 06, 2013 at 10:50:42AM +, Arnd Bergmann wrote:
On Tuesday 05 March 2013, Tomasz Figa wrote:
On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote:
If none of these are needed for DT-based systems, we should probably
build that code conditionally based on the
Am Dienstag, 5. März 2013, 23:48:45 schrieb Tomasz Figa:
On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote:
On Tuesday 05 March 2013, Tomasz Figa wrote:
With this patch set, we can build mach-exynos as part
of a multiplatform kernel, with the following caveats:
* Only DT
On Wednesday 06 of March 2013 23:14:56 Heiko Stübner wrote:
Am Dienstag, 5. März 2013, 23:48:45 schrieb Tomasz Figa:
On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote:
On Tuesday 05 March 2013, Tomasz Figa wrote:
With this patch set, we can build mach-exynos as part
of a
On Wednesday 06 of March 2013 13:34:26 Thierry Reding wrote:
On Wed, Mar 06, 2013 at 10:50:42AM +, Arnd Bergmann wrote:
On Tuesday 05 March 2013, Tomasz Figa wrote:
On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote:
If none of these are needed for DT-based systems, we should
On Wednesday 06 March 2013, Thierry Reding wrote:
Option 2 would probably come down to having a trivial MFD driver exposing
a regmap. You can probably reuse drivers/mfd/syscon.c for this and make
the node compatible with syscon to designate the clock registers as
a system-wide resource,
On Thu, Mar 07, 2013 at 03:02:46AM +, Arnd Bergmann wrote:
On Wednesday 06 March 2013, Thierry Reding wrote:
Option 2 would probably come down to having a trivial MFD driver exposing
a regmap. You can probably reuse drivers/mfd/syscon.c for this and make
the node compatible with
Hi everyone,
Although I'm not present at the Linaro Connect hacking
sessions, I am participating remotely and have tried
hacking on multiplatform support for Exynos. This patch
set is far from complete, but I think the patches
can be useful anyway.
The series gets increasingly fishy towards the
* Arnd Bergmann a...@arndb.de [130305 09:51]:
Hi everyone,
Although I'm not present at the Linaro Connect hacking
sessions, I am participating remotely and have tried
hacking on multiplatform support for Exynos. This patch
set is far from complete, but I think the patches
can be useful
Hi Arnd,
First of all, thanks for your great effort on making Exynos multiplatform-
friendly.
I have added my two cents inline.
On Tuesday 05 of March 2013 18:42:10 Arnd Bergmann wrote:
Hi everyone,
Although I'm not present at the Linaro Connect hacking
sessions, I am participating
On Tuesday 05 March 2013, Tomasz Figa wrote:
With this patch set, we can build mach-exynos as part
of a multiplatform kernel, with the following caveats:
* Only DT based boards are supported
As far as I'm aware, there are plans to drop non-DT Exynos support. Kgene
should know more
On Tuesday 05 March 2013, Heiko Stübner wrote:
If I remember correctly Kgene mentioning some time back, that someone was
working on converting the s3c dma to dmaengine, but I never heard anything
more about it.
Ok, let's see if we can find out what happened to that.
So personally I would
Am Dienstag, 5. März 2013, 18:42:10 schrieb Arnd Bergmann:
Hi everyone,
Although I'm not present at the Linaro Connect hacking
sessions, I am participating remotely and have tried
hacking on multiplatform support for Exynos. This patch
set is far from complete, but I think the patches
can
On Tuesday 05 March 2013, Arnd Bergmann wrote:
The s3c64xx_dma code is also interesting because
it has both an implementation of the s3c_dma interface in
arch/arm/mach-s3c64xx/dma.c and one using the generic interface in
drivers/dma/amba-pl08x.c.
This actually brings me to an interesting
On Tuesday 05 of March 2013 21:54:22 Arnd Bergmann wrote:
On Tuesday 05 March 2013, Arnd Bergmann wrote:
The s3c64xx_dma code is also interesting because
it has both an implementation of the s3c_dma interface in
arch/arm/mach-s3c64xx/dma.c and one using the generic interface in
On Tuesday 05 March 2013, Tomasz Figa wrote:
AFAIR, the PL080 in S3C64xx is a slightly customized variant and requires
some modifications to the driver. However I'm saying this only based on
what I remember from the past, as I haven't checked current version of the
driver yet, so it's
Am Dienstag, 5. März 2013, 22:54:22 schrieb Arnd Bergmann:
On Tuesday 05 March 2013, Arnd Bergmann wrote:
The s3c64xx_dma code is also interesting because
it has both an implementation of the s3c_dma interface in
arch/arm/mach-s3c64xx/dma.c and one using the generic interface in
On Tuesday 05 March 2013, Heiko Stübner wrote:
Am Dienstag, 5. März 2013, 22:54:22 schrieb Arnd Bergmann:
On Tuesday 05 March 2013, Arnd Bergmann wrote:
We still need a solution for the ASoC drivers, but they are
not as essential. We could probably move the wrapper files
from
On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote:
On Tuesday 05 March 2013, Tomasz Figa wrote:
With this patch set, we can build mach-exynos as part
of a multiplatform kernel, with the following caveats:
* Only DT based boards are supported
As far as I'm aware, there are
20 matches
Mail list logo
