From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache
Date: Sat, 8 Aug 2009 20:59:11 +0200 [thread overview]
Message-ID: <20090808185911.GE17045@game.jcrosoft.org> (raw)
In-Reply-To: <20090808180356.6C90A832E416@gemini.denx.de>
On 20:03 Sat 08 Aug , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> In message <20090808152633.GD17045@game.jcrosoft.org> you wrote:
> >
> > > >so NACK
> > >
> > > Let's summarize:
> > >
> > > - First, you NACK because of device_type and function name
> > > - Then, you mention "this code is omap3 specific"
> > > - Then, you mention "this code is not needed at all"
> > >
> > the current implementation is wrong
>
> I try to stay out of this flame war, but Jean-Christophenm I cannot
> prevent myself from stating that indeed with each noew message from
> you in this thread you come up with new arguments. This is not exactly
> a convincing method, and it makes me (and probably others) wonder if
> you are just argumenting because you want to have some fight or if
> ther eis really some technical argument.
>
> If there is one, it should remain contant, so we can try to understand
> what you mean.
>
> > and yes I do want to have armv7 name in the armv cache function
>
> And this is something which does not make any sense to me. If we have
> a function flush_dcache() it should be indeed a genric one, so it can
> be used everywhere in the code where we need to flush the data cache.
> What would be the sense to stick the architecture name in it? If we -
> for example - decide we need to flush the data cache somewhere in the
> generic code, then I want to be able to write
>
> flush_dcache();
>
> Your proposal sounds as if we would end up with
>
> #if defined(_ARMV7_)
> armv7_flush_dcache();
> #elif defined(_OMAP3_)
> omap3__flush_dcache();
again no need of omap3 flush code
so just armv7_flush_cache
> ...
> #elif defined(_MIPS32_)
> mips32_flush_dcache();
> #elif defined(_MIPS64_)
> mips64_flush_dcache();
> ...
>
> This cannot be your intention?
no on more and more soc as cortex from armltd
the difference between two soc for U-Boot point of view will be the cache version
which we detect via the cp15 and have only one U-Boot for both
> A _generig_ name is a must, I think.
>
>
> > I known you will tell but the other does not
> > I agree the other arm flush code need to be clean and it's plan anyway
> > as I need it to add the mmu and d-cache support
> > which will be done later
>
> Again this argument of some clenup that might be performed some time in
> the future. If this should happen one day, then changing one funcktion
> name more or less probably makes only marginal difference.
no the patch cleanup nothing it just move code in omap3 that is mostly armv7
specific and not omap3 specific. The only part that is omap3 specfic is non
need anyway so move it make no sense
>
> > > As already mentioned, let us apply the patch so that other Cortex A8
> > > patches are not stalled any more. Then everybody (including you) can
> > > send additional patches for further improvements.
> > It's plan as I'm working currentlty on the mmu and d-cache support for arm
> > and the current arm implementation will be udpated really soon to allow
> > this and after I'll take a look in the relocation scheme on arm
>
> So this is all plans for some future release. Fine.
>
> But what we're discussing here is a patch for the current release.
> And we've been told that other development depends on getting this
> into a working state, so I even tend to consider this a bug fix.
as the current code fix nothing and on contrary introduce a bug as the code in
most armv7 specifc not omap3
the true fix will to remove the omap3 code as it's not needed
Best Regards,
J.
next prev parent reply other threads:[~2009-08-08 18:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-08 10:46 [U-Boot] [PATCH v2] ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache Dirk Behme
2009-08-08 10:46 ` [U-Boot] [PATCH] OMAP3: Fix missing GPMC_CONFIG_CS0_BASE Dirk Behme
2009-08-09 22:13 ` Wolfgang Denk
2009-08-08 11:26 ` [U-Boot] [PATCH v2] ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache Jean-Christophe PLAGNIOL-VILLARD
2009-08-08 13:47 ` Dirk Behme
2009-08-08 14:10 ` Jean-Christophe PLAGNIOL-VILLARD
2009-08-08 14:35 ` Dirk Behme
2009-08-08 15:00 ` Jean-Christophe PLAGNIOL-VILLARD
2009-08-08 15:18 ` Dirk Behme
2009-08-08 15:26 ` Jean-Christophe PLAGNIOL-VILLARD
2009-08-08 18:03 ` Wolfgang Denk
2009-08-08 18:59 ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2009-08-10 16:20 ` Dirk Behme
2009-08-19 23:49 ` Jean-Christophe PLAGNIOL-VILLARD
2009-08-20 11:48 ` Tom
2009-08-20 13:52 ` Dirk Behme
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=20090808185911.GE17045@game.jcrosoft.org \
--to=plagnioj@jcrosoft.com \
--cc=u-boot@lists.denx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox