public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] KW: Move the memory register definitions into kirkwood.h
Date: Fri, 29 Jun 2012 12:51:53 +0200	[thread overview]
Message-ID: <201206291251.53275.marex@denx.de> (raw)
In-Reply-To: <4FED8316.9070108@keymile.com>

Dear Gerlando Falauto,

> Dear Marek Vasut,
> 
> On 06/29/2012 12:08 PM, Marek Vasut wrote:
> > Dear Gerlando Falauto,
> > 
> >> Dear Maruk,
> 
> sorry about my misspelling!
> 
> >> I am currently trying to address the exact same issue (SDRAM size
> >> detection and fixup).
> >> My idea was however (as opposed to moving register definition as you
> >> did), to add a fixup function to dram.c, say:
> >> 
> >> /*
> >> 
> >>    * kw_sdram_bs - writes SDRAM Bank size
> >>    */
> >> 
> >> void kw_sdram_bs_set(enum memory_bank bank, u32 size)
> >> {
> >> 
> >> 	/* Read current register value */
> >> 	u32 reg = readl(KW_REG_CPUCS_WIN_SZ(bank));
> >> 	
> >> 	printf("Current value: %x\n", reg);
> >> 	/* Clear window size */
> >> 	reg&= ~KW_REG_CPUCS_WIN_SIZE(0xFF);
> >> 	
> >> 	/* Set new window size */
> >> 	reg |= KW_REG_CPUCS_WIN_SIZE((size - 1)>>  24);
> >> 	
> >> 	printf("Writing: %x\n", reg);
> >> 	writel(reg, KW_REG_CPUCS_WIN_SZ(bank));
> >> 
> >> }
> >> 
> >> which would then be called to fix the window size according to the total
> >> memory size as reported by get_ram_size().
> > 
> > Read up at [1].
> > 
> > http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/133991
> 
> Did read up, not sure I understand.
> If I get it right, *this* thread and patchset follows the feedback from
> the above thread.
> 
> What I am trying to say is: we have a function (available to all
> kirkwood boards) which reads the value of the window size register for a
> given memory bank and returns its size.
> Now we want to do the opposite, write the window size register according
> to the detected SDRAM size.
> Why should we make up our own (board-specific) register manipulation
> tweaks, as opposed to having a function do it for us in dram.c as its
> companion?
> Reasons behind it, are board-specific, so in your case it would turn into:
> 
> +int board_early_init_f(void)
> +{
> +	unsigned long size = get_ram_size(PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
> +
> +	/* 256MB module, adjust BAR register */
> +	if (size == 256 * 1024 * 1024)
> +		kw_sdram_bs_set(0, size);
> 
> Which I find cleaner.
> Even the if part could be also removed.
> And would work as-is on any board needing it (ours, for instance).
> 
> What do you think?

I'm all right with it. But Prafulla is the maintainer, so you better negotiate 
with him :-)

> Thank you for your patience,
> Gerlando

Best regards,
Marek Vasut

  reply	other threads:[~2012-06-29 10:51 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-26 18:49 [U-Boot] [PATCH 1/2] KW: Move the memory register definitions into kirkwood.h Marek Vasut
2012-06-26 18:49 ` [U-Boot] [PATCH 2/2] Kirkwood: Add support for Ka-Ro TK71 Marek Vasut
2012-06-27 12:02   ` [U-Boot] [PATCH 2/2 V2] " Marek Vasut
2012-07-03 11:43     ` Prafulla Wadaskar
2012-07-03 11:56     ` Prafulla Wadaskar
2012-07-03 12:08     ` Prafulla Wadaskar
2012-07-03 12:23       ` Marek Vasut
2012-07-03 12:27     ` [U-Boot] [PATCH V3 2/2] " Marek Vasut
2012-07-03 12:44       ` Prafulla Wadaskar
2012-07-03 12:51         ` Marek Vasut
2012-07-03 13:00           ` Prafulla Wadaskar
2012-07-03 13:03             ` Marek Vasut
2012-07-03 13:02       ` [U-Boot] [PATCH 2/2 V4] " Marek Vasut
2012-07-03 13:12         ` Prafulla Wadaskar
2012-06-29 10:02 ` [U-Boot] [PATCH 1/2] KW: Move the memory register definitions into kirkwood.h Gerlando Falauto
2012-06-29 10:08   ` Marek Vasut
2012-06-29 10:27     ` Gerlando Falauto
2012-06-29 10:51       ` Marek Vasut [this message]
2012-06-29 11:37 ` [U-Boot] [PATCH] kirkwood: implement kw_sdram_bs_set() Gerlando Falauto
2012-07-05 10:39   ` Albert ARIBAUD
2012-07-05 10:57     ` Gerlando Falauto
2012-07-05 11:02       ` Albert ARIBAUD
2012-07-05 12:16         ` Prafulla Wadaskar

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=201206291251.53275.marex@denx.de \
    --to=marex@denx.de \
    --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