From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>,
Nicolas Ferre <nicolas.ferre@atmel.com>,
Sebastian Reichel <sre@kernel.org>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH v2 0/8] ARM: at91: Remove mach/ includes from the reset driver
Date: Tue, 28 Oct 2014 10:11:24 +0100 [thread overview]
Message-ID: <20141028091124.GC31979@lukather> (raw)
In-Reply-To: <20141028090454.GD722@piout.net>
[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]
On Tue, Oct 28, 2014 at 10:04:55AM +0100, Alexandre Belloni wrote:
> > > > I'd rather keep the reset driver as is and move SDRAM related macros
> > > > into a specific header (include/linux/memory/atmel-sdram.h or
> > > > include/soc/atmel/memory.h as you proposed) so that the reset driver
> > > > can reference them without including mach headers.
> > > >
> > >
> > > My personal opinion is that it is better to hide the registers/bits from
> > > the reset driver right now as we have two different IPs and the sdram
> > > driver already knows how to make the difference between them.
> >
> > The reset driver doesn't do anything anymore with these patches. Why
> > not just remove it altogether?
> >
>
> It does, the reset driver knows about the reset registers.
So the only thing it does it to define a few register and that's it?
It looks like it's a case for a header, not a driver.
> The plan is to move the actual reset back to that driver when the
> kernel will be able to easily execute code from sram.
Why not go directly for the plan then?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/8] ARM: at91: Remove mach/ includes from the reset driver
Date: Tue, 28 Oct 2014 10:11:24 +0100 [thread overview]
Message-ID: <20141028091124.GC31979@lukather> (raw)
In-Reply-To: <20141028090454.GD722@piout.net>
On Tue, Oct 28, 2014 at 10:04:55AM +0100, Alexandre Belloni wrote:
> > > > I'd rather keep the reset driver as is and move SDRAM related macros
> > > > into a specific header (include/linux/memory/atmel-sdram.h or
> > > > include/soc/atmel/memory.h as you proposed) so that the reset driver
> > > > can reference them without including mach headers.
> > > >
> > >
> > > My personal opinion is that it is better to hide the registers/bits from
> > > the reset driver right now as we have two different IPs and the sdram
> > > driver already knows how to make the difference between them.
> >
> > The reset driver doesn't do anything anymore with these patches. Why
> > not just remove it altogether?
> >
>
> It does, the reset driver knows about the reset registers.
So the only thing it does it to define a few register and that's it?
It looks like it's a case for a header, not a driver.
> The plan is to move the actual reset back to that driver when the
> kernel will be able to easily execute code from sram.
Why not go directly for the plan then?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141028/7158c471/attachment.sig>
next prev parent reply other threads:[~2014-10-28 9:11 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-27 23:09 [PATCH v2 0/8] ARM: at91: Remove mach/ includes from the reset driver Alexandre Belloni
2014-10-27 23:09 ` Alexandre Belloni
2014-10-27 23:09 ` Alexandre Belloni
2014-10-27 23:09 ` [PATCH v2 1/8] memory: atmel-sdramc: export a shutdown function Alexandre Belloni
2014-10-27 23:09 ` Alexandre Belloni
2014-10-27 23:09 ` [PATCH v2 2/8] memory: atmel-sdramc: allow probing from pdata Alexandre Belloni
2014-10-27 23:09 ` Alexandre Belloni
2014-10-27 23:09 ` [PATCH v2 3/8] ARM: at91: sam9: probe the RAMC driver " Alexandre Belloni
2014-10-27 23:09 ` Alexandre Belloni
2014-10-27 23:09 ` [PATCH v2 4/8] ARM: at91: sam9g45/sam9rl: probe the ramc driver Alexandre Belloni
2014-10-27 23:09 ` Alexandre Belloni
2014-10-27 23:09 ` Alexandre Belloni
2014-10-27 23:09 ` [PATCH v2 5/8] power: reset: at91-reset: use at91_ramc_shutdown Alexandre Belloni
2014-10-27 23:09 ` Alexandre Belloni
2014-10-27 23:09 ` Alexandre Belloni
2014-10-28 2:18 ` Sebastian Reichel
2014-10-28 2:18 ` Sebastian Reichel
2014-10-27 23:09 ` [PATCH v2 6/8] ARM: at91: sam9: remove useless resource for rstc Alexandre Belloni
2014-10-27 23:09 ` Alexandre Belloni
2014-10-27 23:09 ` [PATCH v2 7/8] ARM: at91: sam9g45/sam9rl: remove useless resources " Alexandre Belloni
2014-10-27 23:09 ` Alexandre Belloni
2014-10-27 23:09 ` [PATCH v2 8/8] MAINTAINERS: add at91 power and memory entries Alexandre Belloni
2014-10-27 23:09 ` Alexandre Belloni
2014-10-27 23:17 ` Joe Perches
2014-10-27 23:17 ` Joe Perches
2014-11-21 20:17 ` Pavel Machek
2014-11-21 20:17 ` Pavel Machek
2014-10-28 7:50 ` [PATCH v2 0/8] ARM: at91: Remove mach/ includes from the reset driver Boris Brezillon
2014-10-28 7:50 ` Boris Brezillon
2014-10-28 8:52 ` Alexandre Belloni
2014-10-28 8:52 ` Alexandre Belloni
2014-10-28 8:59 ` Maxime Ripard
2014-10-28 8:59 ` Maxime Ripard
2014-10-28 9:04 ` Alexandre Belloni
2014-10-28 9:04 ` Alexandre Belloni
2014-10-28 9:11 ` Maxime Ripard [this message]
2014-10-28 9:11 ` Maxime Ripard
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=20141028091124.GC31979@lukather \
--to=maxime.ripard@free-electrons.com \
--cc=alexandre.belloni@free-electrons.com \
--cc=boris.brezillon@free-electrons.com \
--cc=dbaryshkov@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=nicolas.ferre@atmel.com \
--cc=plagnioj@jcrosoft.com \
--cc=sre@kernel.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.