* [U-Boot] [PATCH] mmc: modified calculated mmc-capacity & set mmc trans_speed
From: Wolfgang Denk @ 2010-05-05 22:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <n2l91990fe21004072036kacf48a2aqf28a92c8d4dd6237@mail.gmail.com>
Dear Andy,
In message <n2l91990fe21004072036kacf48a2aqf28a92c8d4dd6237@mail.gmail.com> Jae hoon Chung wrote:
> The patches do the following
> 1. If mmc size is more than 2GB , we need to calculated using the
> extended csd register.
> 2. mmc_set_clock() is hard setting, that is not good solution.
>
> If mmc is not MMC_MODE_HS, mmc will set card's trans_speed.
>
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>
> ---
> drivers/mmc/mmc.c | 13 ++++++++-----
> 1 files changed, 8 insertions(+), 5 deletions(-)
Is this patch somewhere in your queue?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There are things that are so serious that you can only joke about
them" - Heisenberg
^ permalink raw reply
* [U-Boot] [PATCH v2] POST: Added ECC memory test for mpc83xx.
From: Wolfgang Denk @ 2010-05-05 22:01 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1270654208-32319-1-git-send-email-michael.zaidman@gmail.com>
Dear Michael Zaidman,
In message <1270654208-32319-1-git-send-email-michael.zaidman@gmail.com> you wrote:
> Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
> ---
> post/cpu/mpc83xx/Makefile | 30 ++++++++
> post/cpu/mpc83xx/ecc.c | 167 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 197 insertions(+), 0 deletions(-)
> create mode 100644 post/cpu/mpc83xx/Makefile
> create mode 100644 post/cpu/mpc83xx/ecc.c
Applied, after fixing incorrect brace style:
> + /* Set bit to be injected */
> + if (errbit < 32) {
> + __raw_writel(1 << errbit, &ddr->data_err_inject_lo);
> + __raw_writel(0, &ddr->data_err_inject_hi);
> + }
> + else {
... here.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I can type faster than I can move a mouse, so I find menu-driven
drawing packages time consuming and frustrating. - W. R. Stevens
^ permalink raw reply
* [U-Boot] [PATCH] cmd_onenand.c: moved to standard subcommand handling
From: Wolfgang Denk @ 2010-05-05 21:57 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1269706476-20496-1-git-send-email-fransmeulenbroeks@gmail.com>
Dear Frans Meulenbroeks,
In message <1269706476-20496-1-git-send-email-fransmeulenbroeks@gmail.com> you wrote:
> On the fly also fixed the following things:
> - write help talked about a parameter oob, but that one was not used, so
> removed it from the help message.
> - the test command also allowed a force subcommand but didn't use it.
> eliminated the code.
> - do_onenand made static
> - do_onenand contained
> int blocksize;
> ...
> mtd = &onenand_mtd;
> this = mtd->priv;
> blocksize = (1 << this->erase_shift);
> As blocksize was not used the last two statements were unneeded so
> removed them.
> The first statement (mtd = ....) assigns to a global. Not sure if it
> is needed, and since I could not test this, left the line for now
>
> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
> ---
> common/cmd_onenand.c | 307 +++++++++++++++++++++++++++++++-------------------
> 1 files changed, 192 insertions(+), 115 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Life would be so much easier if we could just look at the source
code. -- Dave Olson
^ permalink raw reply
* [U-Boot] [PATCH] ppc: unused memory region too close to current stack pointer
From: Wolfgang Denk @ 2010-05-05 21:56 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201003191434.o2JEYPRF024813@linpc062.aimsys.nl>
Dear Norbert van Bolhuis,
In message <201003191434.o2JEYPRF024813@linpc062.aimsys.nl> you wrote:
>
> This avoids a possible overwrite of the (end of) ramdisk by u-boot.
> The unused memory region for ppc boot currently starts 1k below the
> do_bootm->bootm_start->arch_lmb_reserve stack ptr. This isn't enough since
> do_bootm->do_bootm_linux->boot_relocate_fdt calls printf which may
> very well use more than 1k stack space.
>
> diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
> index 0685a93..6702df5 100644
> --- a/lib_ppc/bootm.c
> +++ b/lib_ppc/bootm.c
> @@ -163,8 +163,8 @@ void arch_lmb_reserve(struct lmb *lmb)
> sp = get_sp();
> debug ("## Current stack ends at 0x%08lx\n", sp);
>
> - /* adjust sp by 1K to be safe */
> - sp -= 1024;
> + /* adjust sp by 4K to be safe */
> + sp -= 4096;
> lmb_reserve(lmb, sp, (CONFIG_SYS_SDRAM_BASE + get_effective_memsize() - sp));
>
> return ;
> --
> 1.5.2.2
>
> Signed-off-by: Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
Applied - but could you please use "git format-patch" next time? For
example, the Signed-off-by line must be part of the commit message,
and not come below the signature separator.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The high cost of living hasn't affected its popularity.
^ permalink raw reply
* [U-Boot] [PATCH] Add SPI support to mx51evk board
From: Wolfgang Denk @ 2010-05-05 21:53 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1268756541-2179-1-git-send-email-sbabic@denx.de>
Dear Stefano Babic,
In message <1268756541-2179-1-git-send-email-sbabic@denx.de> you wrote:
> The patch adds SPI devices to the mx51evk board. Two devices
> are supported: Atmel SPI flash and MC13892 power
> controller.
>
> Signed-off-by: Stefano Babic <sbabic@denx.de>
> ---
> board/freescale/mx51evk/mx51evk.c | 178 +++++++++++++++++++++++++++++++++++++
> include/configs/mx51evk.h | 17 ++++
> 2 files changed, 195 insertions(+), 0 deletions(-)
It seems this patch has not been picked up yet - can you please check?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Do you suppose the reason the ends of the `Intel Inside' logo don't
match up is that it was drawn on a Pentium?
^ permalink raw reply
* [U-Boot] [PATCH 2/2] remove main CHANGELOG file
From: Wolfgang Denk @ 2010-05-05 21:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1273095808.2451.4674.camel@localhost.localdomain>
Dear Peter Tyser,
In message <1273095808.2451.4674.camel@localhost.localdomain> you wrote:
>
> I see, makes sense. This seems like a problem that is unique to you, as
> well as potentially a few other maintainers. I imagine the vast
> majority of developers rarely use the CHANGELOG file though. Would
> having maintainers create their own CHANGELOG files and/or use something
> like patchwork be acceptable?
As far as the patch processing is concerned, a dynamically generated
file is perfectly good enough for me. If we can keep the "CHANGELOG"
make target I have all I need here.
> > I disagree here. I find myself quite frequently in the situation that
> > I have to identify the exact version some source tree has been
> > derived from. Companies who maintain out-of-tree ports usually don't
> > include any SCM information either. To me, the CHANGELOG is an
> > extremely useful resource in such cases.
>
> The CHANGELOG in a company's source tree won't provide any more
> information than the VERSION, PATCHLEVEL, and EXTRAVERSION in the
> Makefile though, right? Ie the CHANGELOG is only updated when the
> VERSION, PATCHLEVEL, and EXTRAVERSION are updated. Either way, it seems
> like an inexact method to determine the revision of the source code, and
> there should be a better solution so that you don't have to be a
> detective every time you get another vendor's source tree.
Thats's not quite right. I used to update CHANGELOG more frequently in
the past.
> It seems bad to have an inaccurate CHANGELOG. For example if someone
> got a snapshot tarball a week before the last release, their CHANGELOG
> would be missing over 500 changes. In this case the CHANGELOG clearly
Agreed. It was never perfect, but the best we (well, I) had.
> OK, its a stretch, but I don't get the purpose of an inaccurate
> CHANGELOG in any case. Other than when the 1 commit that correlates to
> a tagged release is the the top-of-tree, the CHANGELOG is *never* up to
> date. It can only be believed if someone downloads an officially
> released tarball - otherwise it is most likely wrong.
Right. Well, Kim's pointer to gitattributes is probably the solution
to this issue. Please allow me for some time to let this sink in.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
He is truly wise who gains wisdom from another's mishap.
^ permalink raw reply
* [U-Boot] [PATCH 0/3] Support for TI's DA850/OMAP-L138 platform
From: Tom Rix @ 2010-05-05 21:43 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1272445207-341-1-git-send-email-sudhakar.raj@ti.com>
Sudhakar Rajashekhara wrote:
> This patch series adds support for TI's DA850/OMAP-L138
> platform. This series is dependant on the following
> patch which I have submitted earlier:
>
> [U-Boot] [PATCH] da830: Move common code out of da830evm.c file
>
> Sudhakar Rajashekhara (3):
> TI: DaVinci: Prepare for da850 support
> TI: DaVinci: Add board specific code for da850 EVM
> TI: DaVinci: Create configuration file for da850 EVM
I ran into
da850evm.c:64: error: array type has incomplete element type
da850evm.c: In function 'board_init':
da850evm.c:75: warning: implicit declaration of function 'irq_init'
da850evm.c:90: warning: implicit declaration of function
'davinci_configure_lpsc_items'
Please check that this patchset still builds and rebase if necessary.
Tom
>
> MAINTAINERS | 4 +
> MAKEALL | 1 +
> Makefile | 5 +-
> arch/arm/include/asm/arch-davinci/hardware.h | 1 +
> board/davinci/{da830evm => da8xxevm}/Makefile | 5 +-
> board/davinci/{da830evm => da8xxevm}/config.mk | 0
> board/davinci/{da830evm => da8xxevm}/da830evm.c | 0
> board/davinci/da8xxevm/da850evm.c | 111 +++++++++++++++++++
> include/configs/da850evm.h | 135 +++++++++++++++++++++++
> 9 files changed, 260 insertions(+), 2 deletions(-)
> rename board/davinci/{da830evm => da8xxevm}/Makefile (91%)
> rename board/davinci/{da830evm => da8xxevm}/config.mk (100%)
> rename board/davinci/{da830evm => da8xxevm}/da830evm.c (100%)
> create mode 100644 board/davinci/da8xxevm/da850evm.c
> create mode 100644 include/configs/da850evm.h
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
^ permalink raw reply
* [U-Boot] [PATCH 2/2] remove main CHANGELOG file
From: Peter Tyser @ 2010-05-05 21:43 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20100505205802.97211B0FF81@gemini.denx.de>
> > I'll quit whining, just wanted to give my +1 for removing the changelog.
>
> I don't consider you whining. I am listening to the arguments.
> I am not convinced yet, though.
Well in that case, I'll chime in again:)
> > I still don't grasp what the common use of looking at U-Boot's entire
> > changelog is. What are some common tasks that require grepping U-Boot's
> > entire changelog? Are these tasks performed frequently enough that the
> > extra <1 second 'git log' requires is bothersome?
>
> I'm trying to maintain some awareness of open patches. For example,
> when I receive a pull request I mark all included patches as
> processed; sometimes this includes tracking down older versions of
> the patches, or commit messages that have been changed on the way.
> And yes, the <1 second delay is bothersome when doing this frequently
> enough.
I see, makes sense. This seems like a problem that is unique to you, as
well as potentially a few other maintainers. I imagine the vast
majority of developers rarely use the CHANGELOG file though. Would
having maintainers create their own CHANGELOG files and/or use something
like patchwork be acceptable?
> > > -> wget -O u-boot.tgz 'http://git.denx.de/?p=u-boot.git;a=snapshot;sf=tgz'
> >
> > For snapshots, the CHANGELOG file is going to be out of date though.
> > It'll only list the changes that occurred up to the previous release.
> > This seems worse than not having a CHANGELOG at all as its actively
> > misleading people as to what changes their source code has.
>
> I disagree here. I find myself quite frequently in the situation that
> I have to identify the exact version some source tree has been
> derived from. Companies who maintain out-of-tree ports usually don't
> include any SCM information either. To me, the CHANGELOG is an
> extremely useful resource in such cases.
The CHANGELOG in a company's source tree won't provide any more
information than the VERSION, PATCHLEVEL, and EXTRAVERSION in the
Makefile though, right? Ie the CHANGELOG is only updated when the
VERSION, PATCHLEVEL, and EXTRAVERSION are updated. Either way, it seems
like an inexact method to determine the revision of the source code, and
there should be a better solution so that you don't have to be a
detective every time you get another vendor's source tree.
It seems bad to have an inaccurate CHANGELOG. For example if someone
got a snapshot tarball a week before the last release, their CHANGELOG
would be missing over 500 changes. In this case the CHANGELOG clearly
isn't serving its intended purpose and could actually mislead someone,
eg "I know commit XYZ introduces a bug, but the changelog says I don't
have commit XYZ in my tree, so I'm bug free!". In reality there have
been 500 commits the user is unaware of, including potentially commit
XYZ they were trying to avoid.
OK, its a stretch, but I don't get the purpose of an inaccurate
CHANGELOG in any case. Other than when the 1 commit that correlates to
a tagged release is the the top-of-tree, the CHANGELOG is *never* up to
date. It can only be believed if someone downloads an officially
released tarball - otherwise it is most likely wrong.
Best,
Peter
^ permalink raw reply
* [U-Boot] [PATCH 5/6 v3] spi_flash: support old STMicro parts with RES
From: Mike Frysinger @ 2010-05-05 21:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20100505195729.638FCF648D6@gemini.denx.de>
On Wednesday 05 May 2010 15:57:29 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > ive merged this into my sf branch and will push out next merge window if
> > Wolfgang doesnt pick it up before that
>
> Just let me know what you (and Thomas) prefer
doesnt matter to me whether you pull my branch now or after the merge window:
git://git.denx.de/u-boot-blackfin.git sf
> and what exactly (which patch[es] from this series) the "it" is that should
> be picked up (or not).
there is only one patch in this thread ...
referring to all the patches in my branch, none are "bugfixes" persay which is
why i didnt know if you wanted to let them sit until next merge window.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100505/3714b67e/attachment.pgp
^ permalink raw reply
* [U-Boot] [PATCH v2 12/17] SPEAr : i2c driver moved completely into drivers/i2c
From: Tom Rix @ 2010-05-05 21:37 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4BDFE3B7.7090809@st.com>
Vipin KUMAR wrote:
> On 5/3/2010 5:55 AM, Tom Rix wrote:
>> Vipin KUMAR wrote:
>>> The i2c IP used by spear platform is a synopsys i2c controller
>> 'IP' expand.
>
> IP is Intellectual Property i.e peripheral hardware
>
Please use the term 'peripheral hardware' in place of IP
IP is too generic.
Tom
>> What is the connection between 'synopsys' and 'designware' ?
>> If the part is synopsys, that should be the string used
>> instead of 'dw' or 'designware'
>
> Synopsys is the vendor and designware is the class of peripherals
> from synopsys
>
>>> The earlier driver adds the driver of this controller as if it is
>>> specific to
>>> spear platform.
>>> The driver files are now moved into drivers/i2c folder for reusability
>>> by other
>> Maybe something like
>> 'The earlier i2c driver was specific to spear platforms.
>> This driver has been moved to the common driver directory drivers/i2c
>> where it can be used by other platforms'
>>
> OK. I would improve on this
>
> Regards
> Vipin
>
>
^ permalink raw reply
* [U-Boot] [PATCH 01/17] SPARC: added unaligned definitions, patch supplied by Magnus Sjalander.
From: Wolfgang Denk @ 2010-05-05 21:35 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1264680996-13804-1-git-send-email-daniel@gaisler.com>
Dear Daniel Hellstrom,
In message <1264680996-13804-1-git-send-email-daniel@gaisler.com> you wrote:
> Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
> ---
> include/asm-sparc/unaligned.h | 17 +++++++++++++++++
> 1 files changed, 17 insertions(+), 0 deletions(-)
> create mode 100644 include/asm-sparc/unaligned.h
This whole patch series has been out there for many months, but I'm
still waiting for a pull request from you.
Do you have any such plans?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Sorry, but my karma just ran over your dogma.
^ permalink raw reply
* [U-Boot] Endless loop in cmd_log.c?
From: Dennis Ruffer @ 2010-05-05 21:34 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1273069733-6194-4-git-send-email-weisserm@arcor.de>
I am trying to implement CONFIG_LOGBUFFER and CONFIG_CMD_LOG on our ARM
systems and I seem to have run into an endless loop. With loglevel=5 so we
still see our console output, the printf at the end of logbuff_printk
appears to create an endless loop.
I had to replace that line with serial_puts(msg);
Have I missed some other solution or do the systems that use this never set
logbuffer higher than default_message_loglevel?
DaR
^ permalink raw reply
* [U-Boot] [PATCH 2/2] remove main CHANGELOG file
From: Kim Phillips @ 2010-05-05 21:09 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20100505160607.99edd83d.kim.phillips@freescale.com>
On Wed, 5 May 2010 16:06:07 -0500
Kim Phillips <kim.phillips@freescale.com> wrote:
> echo 'snapshot.commit' > .git/info/attributes
make that:
echo 'snapshot.commit export-subst' > .git/info/attributes
Kim
^ permalink raw reply
* [U-Boot] [PATCH] ARM1136: Fix cache_flush() error and correct cpu_init_crit() comments
From: George G. Davis @ 2010-05-05 21:09 UTC (permalink / raw)
To: u-boot
The ARM1136 cache_flush() function uses the "mcr p15, 0, rn, c7, c7, 0"
instruction which means "Invalidate Both Caches" when in fact the intent
is to "Clean and Invalidate Entire Data Cache". So change the ARM1136
cache_flush() function to use the "mcr p15, 0, rn, c7, c7, 0 @ Clean &
invalidate D-Cache" instruction to insure that memory is consistent
with any dirty cache lines.
Also fix a couple of "flush v*" comments in ARM1136 cpu_init_crit() so
that they correctly describe the actual ARM1136 CP15 C7 Cache Operations
used.
Signed-off-by: George G. Davis <gdavis@mvista.com>
---
arch/arm/cpu/arm1136/cpu.c | 8 ++++----
arch/arm/cpu/arm1136/start.S | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index ade7f46..a00698f 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -69,8 +69,8 @@ int cleanup_before_linux (void)
static void cache_flush(void)
{
- unsigned long i = 0;
-
- asm ("mcr p15, 0, %0, c7, c7, 0": :"r" (i)); /* invalidate both caches and flush btb */
- asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (i)); /* mem barrier to sync things */
+ asm (
+ " mcr p15, 0, %0, c7, c14, 0 @ Clean & invalidate D-Cache\n"
+ " mcr p15, 0, %0, c7, c10, 4 @ DSB\n"
+ : : "r" (0) : "memory");
}
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index 957f438..922d01c 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -226,8 +226,8 @@ cpu_init_crit:
* flush v4 I/D caches
*/
mov r0, #0
- mcr p15, 0, r0, c7, c7, 0 /* flush v3/v4 cache */
- mcr p15, 0, r0, c8, c7, 0 /* flush v4 TLB */
+ mcr p15, 0, r0, c7, c7, 0 /* Invalidate I+D+BTB caches */
+ mcr p15, 0, r0, c8, c7, 0 /* Invalidate Unified TLB */
/*
* disable MMU stuff and caches
--
1.6.3.3.328.ga9ee94
^ permalink raw reply related
* [U-Boot] [PATCH 2/2] remove main CHANGELOG file
From: Wolfgang Denk @ 2010-05-05 21:07 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20100505160607.99edd83d.kim.phillips@freescale.com>
Dear Kim Phillips,
In message <20100505160607.99edd83d.kim.phillips@freescale.com> you wrote:
>
> > How would you try such identification?
>
> it appears that the granularity of CHANGELOG updates is equal to that
> of VERSION, PATCHLEVEL, and EXTRAVERSION assignments in the root
> Makefile; so presumably one can refer to those instead.
This doesn't workl reliably. Too often companies insert their own
version information there, which sometimes is completely unrelated to
what we use.
> For exact per-export granularity, one can do something like this:
>
> cd u-boot
> echo '$Format:%H$' > snapshot.commit
> git add snapshot.commit && git commit -m 'add snapshot.commit file'
> echo 'snapshot.commit' > .git/info/attributes
> git archive --format=tar --prefix=${PREFIX}/ <commit> ...
>
> ...the resultant tarball's snapshot.commit file will contain the value
> of the sha id representing commit <commit>.
>
> for more info, see the gitattributes manpage and the list of
> placeholders in the PRETTY FORMATS section of the git log manpage.
Ah! That's interesting. Another git feature I didn't know yet.
/me is reading the documentation.
Thanks a lot for this interesting tip!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Mandrell: "You know what I think?"
Doctor: "Ah, ah that's a catch question. With a brain your size you
don't think, right?"
- Dr. Who
^ permalink raw reply
* [U-Boot] [PATCH 2/2] remove main CHANGELOG file
From: Kim Phillips @ 2010-05-05 21:06 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20100505065401.04FACB076D3@gemini.denx.de>
On Wed, 5 May 2010 08:54:01 +0200
Wolfgang Denk <wd@denx.de> wrote:
> Dear Kim Phillips,
>
> In message <20100504192544.6506945d.kim.phillips@freescale.com> you wrote:
> >
> > > > It is assumed that this file's only purpose is to serve non-git users
> > > > downloading u-boot project source in the form of a tarball release. If
> > > > that is the case, then the generation of the CHANGELOG file should occur
> > > > at tarball release generation time, and not consume duplicate history,
>
> Can you recommend a way how such auto-generation / inclusion would be
> done?
>
> Currently I'm using something like this:
>
> $ V=2010.03
> $ PREFIX=u-boot-${V}
> $ git archive --format=tar --prefix=${PREFIX}/ v${V} | \
> > bzip2 -v9 >~/tmp/${PREFIX}.tar.bz2
>
> How could this be made to include a non-git-controlled CHANGELOG?
(see below)
> > > Slowing things down? C'me on.
> >
> > maybe not git grep performance-wise (yet), but on a
> > frequently-occurring search term, when we have to visually sift through
> > and page down through a large number of CHANGELOG hits (that invariably
> > show up first), then yes, I consider that a development-time barrier.
>
> So what about git performance? A "grep foobar CHANGELOG" is
> significantly faster than a "git log --grep=foobar", isn't it?
true, but I find that git log runs well after it is run once and
everything is loaded in the cache.
Also, if I'm git grepping in the u-boot git tree, I want to grep
the source, not the git log.
> > > NAK. My position about these files has not changed.
> >
> > Please reconsider: u-boot has no need to be 'special' in this area, and
> > this file's continued existence is a lingering harassment for
> > developers such as myself.
>
> Harassment? Strong words. I am seriously listening to your arguments,
> but so far I feel that there is a lot of emotion in your message but
> only few arguments I can follow.
you are right; bad choice of words; I meant something milder - more
along the lines of 'annoyance'.
> In addition to the arguments already mentioned here is another reason
> why I would like to keep this file in place: Quite often we have to
> work with copies of the U-Boot source tree that do not contain any
> good information about which version they might have been derived
> from; the CHANGELOG at least gives an idea about the time frame.
>
> How would you try such identification?
it appears that the granularity of CHANGELOG updates is equal to that
of VERSION, PATCHLEVEL, and EXTRAVERSION assignments in the root
Makefile; so presumably one can refer to those instead.
For exact per-export granularity, one can do something like this:
cd u-boot
echo '$Format:%H$' > snapshot.commit
git add snapshot.commit && git commit -m 'add snapshot.commit file'
echo 'snapshot.commit' > .git/info/attributes
git archive --format=tar --prefix=${PREFIX}/ <commit> ...
...the resultant tarball's snapshot.commit file will contain the value
of the sha id representing commit <commit>.
for more info, see the gitattributes manpage and the list of
placeholders in the PRETTY FORMATS section of the git log manpage.
Kim
^ permalink raw reply
* [U-Boot] [PATCH 2/2] remove main CHANGELOG file
From: Wolfgang Denk @ 2010-05-05 20:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1273091842.2451.4563.camel@localhost.localdomain>
Dear Peter Tyser,
In message <1273091842.2451.4563.camel@localhost.localdomain> you wrote:
>
> I still don't grasp what the common use of looking at U-Boot's entire
> changelog is. What are some common tasks that require grepping U-Boot's
> entire changelog? Are these tasks performed frequently enough that the
> extra <1 second 'git log' requires is bothersome?
I'm trying to maintain some awareness of open patches. For example,
when I receive a pull request I mark all included patches as
processed; sometimes this includes tracking down older versions of
the patches, or commit messages that have been changed on the way.
And yes, the <1 second delay is bothersome when doing this frequently
enough.
> > -> wget -O u-boot.tgz 'http://git.denx.de/?p=u-boot.git;a=snapshot;sf=tgz'
>
> For snapshots, the CHANGELOG file is going to be out of date though.
> It'll only list the changes that occurred up to the previous release.
> This seems worse than not having a CHANGELOG at all as its actively
> misleading people as to what changes their source code has.
I disagree here. I find myself quite frequently in the situation that
I have to identify the exact version some source tree has been
derived from. Companies who maintain out-of-tree ports usually don't
include any SCM information either. To me, the CHANGELOG is an
extremely useful resource in such cases.
> I'll quit whining, just wanted to give my +1 for removing the changelog.
I don't consider you whining. I am listening to the arguments.
I am not convinced yet, though.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The human race is faced with a cruel choice: work or daytime tele-
vision.
^ permalink raw reply
* [U-Boot] [PATCH] ARM1136: Fix cache_flush() error and correct cpu_init_crit() comments
From: George G. Davis @ 2010-05-05 20:57 UTC (permalink / raw)
To: u-boot
The ARM1136 cache_flush() function uses the "mcr p15, 0, rn, c7, c7, 0"
instruction which means "Invalidate Both Caches" when in fact the intent
is to "Clean and Invalidate Entire Data Cache". So change the ARM1136
cache_flush() function to use the "mcr p15, 0, rn, c7, c7, 0 @ Clean &
invalidate D-Cache" instruction to insure that memory is consistent
with any dirty cache lines.
Also fix a couple of "flush v*" comments in ARM1136 cpu_init_crit() so
that they correctly describe the actual ARM1136 CP15 C7 Cache Operations
used.
Signed-off-by: George G. Davis <gdavis@mvista.com>
---
arch/arm/cpu/arm1136/cpu.c | 8 ++++----
arch/arm/cpu/arm1136/start.S | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index ade7f46..a00698f 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -69,8 +69,8 @@ int cleanup_before_linux (void)
static void cache_flush(void)
{
- unsigned long i = 0;
-
- asm ("mcr p15, 0, %0, c7, c7, 0": :"r" (i)); /* invalidate both caches and flush btb */
- asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (i)); /* mem barrier to sync things */
+ asm (
+ " mcr p15, 0, %0, c7, c14, 0 @ Clean & invalidate D-Cache\n"
+ " mcr p15, 0, %0, c7, c10, 4 @ DSB\n"
+ : : "r" (0) : "memory");
}
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index 957f438..922d01c 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -226,8 +226,8 @@ cpu_init_crit:
* flush v4 I/D caches
*/
mov r0, #0
- mcr p15, 0, r0, c7, c7, 0 /* flush v3/v4 cache */
- mcr p15, 0, r0, c8, c7, 0 /* flush v4 TLB */
+ mcr p15, 0, r0, c7, c7, 0 /* Invalidate I+D+BTB caches */
+ mcr p15, 0, r0, c8, c7, 0 /* Invalidate Unified TLB */
/*
* disable MMU stuff and caches
--
1.6.3.3.328.ga9ee94
^ permalink raw reply related
* [U-Boot] [PATCH 2/2] remove main CHANGELOG file
From: Peter Tyser @ 2010-05-05 20:37 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20100505190541.BFEFCB0FF8E@gemini.denx.de>
Hi Wolfgang,
> > Could you describe what you use CHANGELOG for? I often look at logs,
> > but 99% of the time its a log of a specific file or directory to trace a
> > bug, see why feature X was added, etc. I rarely look at the
> > repositories entire log, and if I do, I use 'git log'. Although 'git
> > log' takes longer, its guaranteed to be accurate, unlike CHANGELOG which
> > may be slightly out of date.
>
> Most frequently I use it in combination with some form of grep command
> (grep, agrep etc.); sometimes I use it in vi/view for manual searching
> / reading.
I still don't grasp what the common use of looking at U-Boot's entire
changelog is. What are some common tasks that require grepping U-Boot's
entire changelog? Are these tasks performed frequently enough that the
extra <1 second 'git log' requires is bothersome?
<snip>
> 3) it delivers only the lines I cactually search for, while "git log
> 4) I can use arbitrary grep options. I am not aware of a git
> 5) I can use other tools to process the messages, like agrep for fuzzy
As Scott mentioned, these can be solved via 'git grep | <cmd>'.
> > If you do prefer the speed of looking at a CHANGELOG file, its easy to
> > generate one when you require it.
>
> Yes, I know. But I also want it available to those who don't use git,
> so it should to be included in the release tarball, and in the
> auto-generated tarballs when using the "snapshot" links on the web
> interface; for example try:
>
> -> wget -O u-boot.tgz 'http://git.denx.de/?p=u-boot.git;a=snapshot;sf=tgz'
For snapshots, the CHANGELOG file is going to be out of date though.
It'll only list the changes that occurred up to the previous release.
This seems worse than not having a CHANGELOG at all as its actively
misleading people as to what changes their source code has.
<snip>
> > - For any change that is automated via a script/grep/sed/etc one needs
> > to filter out the CHANGELOG files.
>
> You probably need to exclude a number of other files as well?
I think in general you'd want to update all files other than CHANGELOG.
As a concrete example, the following is a snippet from a script used for
the recent directory reorganization:
git grep lib_$ARCH | grep -v CHANGELOG | sed s/:.*$// | uniq | xargs perl -pi -e "s/lib_$ARCH/arch\/$ARCH\/lib/"
I'll quit whining, just wanted to give my +1 for removing the changelog.
Best,
Peter
^ permalink raw reply
* [U-Boot] [PATCH 2/2] remove main CHANGELOG file
From: Wolfgang Denk @ 2010-05-05 20:36 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4BE1CACE.6040005@freescale.com>
Dear Scott Wood,
In message <4BE1CACE.6040005@freescale.com> you wrote:
>
> Surely the extra quarter second is not too significant compared to the
> time it takes to formulate the query and examine the results.
The requests are often generated by some script, and there may be tens
of them - enough that the 'git log' versions takes several seconds.
> > 2) it's more efficient:
> >
> > -> strace -f grep foobar CHANGELOG 2>&1>/dev/null | wc -l
> > 143
> > -> strace -f git log --grep=foobar 2>&1>/dev/null | wc -l
> > 2494
>
> It also requires that a cache be maintained just for this purpose.
I can't parse that.
> You could even have a cron job keep it up to date. :-)
Agreed. There are many, many possibilities.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Perl itself is usually pretty good about telling you what you
shouldn't do. :-) - Larry Wall in <11091@jpl-devvax.JPL.NASA.GOV>
^ permalink raw reply
* [U-Boot] [PATCH 2/2] [v6] allow print_size to print large numbers on 32-bit systems
From: Wolfgang Denk @ 2010-05-05 20:18 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1271182563-17615-2-git-send-email-timur@freescale.com>
Dear Timur Tabi,
In message <1271182563-17615-2-git-send-email-timur@freescale.com> you wrote:
> Modify print_size() so that it can accept numbers larger than 4GB on 32-bit
> systems.
>
> Add support for display terabyte, petabyte, and exabyte sizes. Change the
> output to use International Electrotechnical Commission binary prefix standard.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> include/common.h | 2 +-
> lib/display_options.c | 31 ++++++++++++++++++-------------
> 2 files changed, 19 insertions(+), 14 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The years of peak mental activity are undoubtedly between the ages of
four and eighteen. At four we know all the questions, at eighteen all
the answers.
^ permalink raw reply
* [U-Boot] [PATCH 1/2] [v2] fix print_size printing fractional gigabyte numbers on 32-bit platforms
From: Wolfgang Denk @ 2010-05-05 20:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1271182563-17615-1-git-send-email-timur@freescale.com>
Dear Timur Tabi,
In message <1271182563-17615-1-git-send-email-timur@freescale.com> you wrote:
> In print_size(), the math that calculates the fractional remainder of a number
> used the same integer size as a physical address. However, the "10 *" factor
> of the algorithm means that a large number (e.g. 1.5GB) can overflow the
> integer if we're running on a 32-bit system. Therefore, we need to
> disassociate this function from the size of a physical address.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> lib/display_options.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I am not now, nor have I ever been, a member of the demigodic party.
-- Dennis Ritchie
^ permalink raw reply
* [U-Boot] [PATCH-V2 4/4] AM35x: Add support for EMIF4
From: Wolfgang Denk @ 2010-05-05 20:14 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1272034546-26041-6-git-send-email-hvaibhav@ti.com>
Dear hvaibhav at ti.com,
In message <1272034546-26041-6-git-send-email-hvaibhav@ti.com> you wrote:
> From: Vaibhav Hiremath <hvaibhav@ti.com>
>
> This patch adds support for the EMIF4 interface
> available in the AM35x processors.
>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> ---
> arch/arm/cpu/arm_cortexa8/omap3/Makefile | 3 +
> arch/arm/cpu/arm_cortexa8/omap3/emif4.c | 168 +++++++++++++++++++++++++++
> arch/arm/include/asm/arch-omap3/cpu.h | 24 ++++
> arch/arm/include/asm/arch-omap3/emif4.h | 79 +++++++++++++
> arch/arm/include/asm/arch-omap3/sys_proto.h | 3 +
> 5 files changed, 277 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/cpu/arm_cortexa8/omap3/emif4.c
> create mode 100644 arch/arm/include/asm/arch-omap3/emif4.h
>
> diff --git a/arch/arm/cpu/arm_cortexa8/omap3/Makefile b/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> index 8cc7802..0a23fa5 100644
> --- a/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> +++ b/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> @@ -36,6 +36,9 @@ COBJS += mem.o
> ifdef CONFIG_SDRC
> COBJS += sdrc.o
> endif
> +ifdef CONFIG_EMIF4
> +COBJS += emif4.o
> +endif
Don't use ifdef, use COBJS-$(CONFIG_EMIF4) instead.
> diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h b/arch/arm/include/asm/arch-omap3/sys_proto.h
> index 34e4e0d..7b425be 100644
> --- a/arch/arm/include/asm/arch-omap3/sys_proto.h
> +++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
> @@ -35,6 +35,9 @@ void memif_init(void);
> void sdrc_init(void);
> void do_sdrc_init(u32, u32);
> #endif
> +#if defined(CONFIG_EMIF4)
> +void emif4_init(void);
> +#endif
I guess you can omit the #ifdef here, right?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A failure will not appear until a unit has passed final inspection.
^ permalink raw reply
* [U-Boot] [PATCH-V2 3/4] AM35x: Add support for AM3517EVM
From: Wolfgang Denk @ 2010-05-05 20:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1272034546-26041-5-git-send-email-hvaibhav@ti.com>
Dear hvaibhav at ti.com,
In message <1272034546-26041-5-git-send-email-hvaibhav@ti.com> you wrote:
> From: Vaibhav Hiremath <hvaibhav@ti.com>
>
> This patch adds basic support for the AM3517EVM.
> It includes:
> - Board int file (.c and .h)
> - Default configuration file
> - Updates for Makefile
>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> ---
> Makefile | 3 +
> arch/arm/include/asm/arch-omap3/mux.h | 36 +++
> board/logicpd/am3517evm/Makefile | 47 ++++
> board/logicpd/am3517evm/am3517evm.c | 76 ++++++
> board/logicpd/am3517evm/am3517evm.h | 405 +++++++++++++++++++++++++++++++++
> board/logicpd/am3517evm/config.mk | 30 +++
> include/configs/am3517_evm.h | 297 ++++++++++++++++++++++++
> 7 files changed, 894 insertions(+), 0 deletions(-)
> create mode 100644 board/logicpd/am3517evm/Makefile
> create mode 100644 board/logicpd/am3517evm/am3517evm.c
> create mode 100644 board/logicpd/am3517evm/am3517evm.h
> create mode 100644 board/logicpd/am3517evm/config.mk
> create mode 100644 include/configs/am3517_evm.h
Entries to MAKEALL and MAINTAINERS missing.
> diff --git a/Makefile b/Makefile
> index 34f10ce..487ae73 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -3169,6 +3169,9 @@ omap3_zoom1_config : unconfig
> omap3_zoom2_config : unconfig
> @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom2 logicpd omap3
>
> +am3517_evm_config : unconfig
> + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 am3517evm logicpd omap3
> +
> smdkc100_config: unconfig
> @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 smdkc100 samsung s5pc1xx
Please keep list sorted.
> diff --git a/arch/arm/include/asm/arch-omap3/mux.h b/arch/arm/include/asm/arch-omap3/mux.h
> index 0c01c73..8ea47b6 100644
> --- a/arch/arm/include/asm/arch-omap3/mux.h
> +++ b/arch/arm/include/asm/arch-omap3/mux.h
> @@ -283,6 +283,7 @@
> /*Control and debug */
> #define CONTROL_PADCONF_SYS_32K 0x0A04
> #define CONTROL_PADCONF_SYS_CLKREQ 0x0A06
> +#define CONTROL_PADCONF_SYS_NRESWARM 0x0A08
> #define CONTROL_PADCONF_SYS_NIRQ 0x01E0
> #define CONTROL_PADCONF_SYS_BOOT0 0x0A0A
> #define CONTROL_PADCONF_SYS_BOOT1 0x0A0C
CONTROL_PADCONF_SYS_NIRQ looks out of place here. And all this asks
to be converted into a proper C struct.
> diff --git a/board/logicpd/am3517evm/Makefile b/board/logicpd/am3517evm/Makefile
> new file mode 100644
> index 0000000..3c71fef
> --- /dev/null
> +++ b/board/logicpd/am3517evm/Makefile
...
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
Don't add trailing empty lines. [Please check & fix globally.]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Any sufficiently advanced technology is indistinguishable from magic.
Clarke's Third Law - _Profiles of the Future_ (1962; rev. 1973)
``Hazards of Prophecy: The Failure of Imagination''
^ permalink raw reply
* [U-Boot] [PATCH-V2 2/4] omap3: Consolidate SDRC related operations
From: Wolfgang Denk @ 2010-05-05 20:07 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1272034546-26041-4-git-send-email-hvaibhav@ti.com>
Dear hvaibhav at ti.com,
In message <1272034546-26041-4-git-send-email-hvaibhav@ti.com> you wrote:
> From: Vaibhav Hiremath <hvaibhav@ti.com>
>
> Consolidated SDRC related functions into one file - sdrc.c
>
> And also replaced sdrc_init with generic memory init
> function (mem_init), this generalization of omap memory setup
> is necessary to support the new emif4 interface introduced in AM3517.
>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> diff --git a/arch/arm/cpu/arm_cortexa8/omap3/Makefile b/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> index 136b163..8cc7802 100644
> --- a/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> +++ b/arch/arm/cpu/arm_cortexa8/omap3/Makefile
> @@ -33,6 +33,9 @@ COBJS += board.o
> COBJS += clock.o
> COBJS += gpio.o
> COBJS += mem.o
> +ifdef CONFIG_SDRC
> +COBJS += sdrc.o
> +endif
Please don't use 'ifdef" here; instead, use `COBJS-$(CONFIG_SDRC)'
> diff --git a/arch/arm/include/asm/arch-omap3/cpu.h b/arch/arm/include/asm/arch-omap3/cpu.h
> index aa8de32..a49af10 100644
> --- a/arch/arm/include/asm/arch-omap3/cpu.h
> +++ b/arch/arm/include/asm/arch-omap3/cpu.h
> @@ -183,6 +183,7 @@ struct sms {
> /* SDRC */
> #ifndef __KERNEL_STRICT_NAMES
> #ifndef __ASSEMBLY__
> +#if defined(CONFIG_SDRC)
> struct sdrc_cs {
> u32 mcfg; /* 0x80 || 0xB0 */
> u32 mr; /* 0x84 || 0xB4 */
> @@ -215,6 +216,8 @@ struct sdrc {
> u8 res4[0xC];
> struct sdrc_cs cs[2]; /* 0x80 || 0xB0 */
> };
> +
> +#endif /* CONFIG_SDRC */
I don't like such a #ifdef here - it is absolutely necessary? Why?
> diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h b/arch/arm/include/asm/arch-omap3/sys_proto.h
> index 34bd515..34e4e0d 100644
> --- a/arch/arm/include/asm/arch-omap3/sys_proto.h
> +++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
> @@ -31,8 +31,10 @@ void prcm_init(void);
> void per_clocks_enable(void);
>
> void memif_init(void);
> +#if defined(CONFIG_SDRC)
> void sdrc_init(void);
> void do_sdrc_init(u32, u32);
> +#endif
Ditto - please drop this #ifdef.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
People seldom know what they want until you give them what they ask
for.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox