public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Helmut Raiger <helmut.raiger@hale.at>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mx31: provide readable WEIM CS accessor
Date: Thu, 29 Sep 2011 08:32:23 +0200	[thread overview]
Message-ID: <4E8410F7.5020901@hale.at> (raw)
In-Reply-To: <4E8339E9.3080204@denx.de>

On 09/28/2011 05:14 PM, Stefano Babic wrote
>> Is there a reason to embed this function in imx-regs.h ? Why not in
>> ./arch/arm/cpu/arm1136/mx31/generic.c, where I think this function
>> belongs ?
>>
I took it from the kernel where it is done that way and didn't ask why. 
I'll move it.

>> We are trying to get consistency among the several i.MX SOCs. For this
>> reason, a general function should not have a specific SOC prefix.
>> You introduce now a new accessor to set up the WEIM registers. We have
>> not yet such as function, but we can have then for other SOCs, too.
>> Rename your function as mxc_setup_weimcs(), and when an accessor will be
>> supplied for MX5 (or MX*), the same name must be used.
>>
>> +		unsigned int upper, unsigned int lower, unsigned int add)
>> +{
>> +	writel(upper, WEIM_CSCR_U(cs));
>> +	writel(lower, WEIM_CSCR_L(cs));
>> +	writel(add, WEIM_CSCR_A(cs));
>> +}
> You are using offests to access registers. Why not to set a structure as:
>
> struct weim_regs {
> 	u32 upper;
> 	u32 lower;
> 	u32 adder;
> 	u32 reserved;
> }
>
> and then :
>
> struct weim {
> 	struct weim_regs cs[6];
> };
>
> ...or something like that.
>
> Passing the register values to the function makes the accessor too
> striclty bound to the mx31. But if you pass a struct weim*, that is void
> mxc_setup_weimcs(struct weim *), we can have the same accessor (with a
> different implementation, of course) for the other SOCs, too. I can
> imagine we can have MX5 (at the moment I see only the mx53ard) using the
> same way to set up the WEIM interface.

I used the writel register access to assure correct memory barriers, but 
this might not be a problem with the CS registers. However passing the 
complete set of chip selects wouldn't work, as only a few will be setup 
in the function, while others aren't touched (we could pass a bitmap to 
select which ones should be set, but this seems flamboyant).

What about:

void mxc_setup_weimcs(int cs, const struct mxc_weimcs *cs)
{
...
}

void some_board_init_func(void)
{
     /* CS5: CPLD incl. network controller */
     static const struct mxc_weimcs cs5 = {
         /*    sp wp bcd bcs psz pme sync dol cnc wsc ew wws edc */
         CSCR_U(0, 0,  0,  0,  0,  0,   0,  0,  3, 24, 0,  4,  3),
         /*   oea oen ebwa ebwn csa ebc dsz csn psr cre wrap csen */
         CSCR_L(2,  2,   2,   5,  2,  0,  5,  2,  0,  0,   0,   1),
         /*  ebra ebrn rwa rwn mum lah lbn lba dww dct wwu age cnc2 fce*/
         CSCR_A(2,   2,  2,  2,  0,  0,  2,  2,  0,  0,  0,  0,   0,  0)
     };

     mxc_setup_weimcs(5, &cs5);
}

This should still work for different SOCs (with different struct 
mxc_weimcs). CSCR_U et al. will be mx31 specific defines.

Helmut


--
Scanned by MailScanner.

  reply	other threads:[~2011-09-29  6:32 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-22 12:12 [U-Boot] mx31: Add board support for HALE TT-01 Helmut Raiger
2011-09-22 12:12 ` [U-Boot] [PATCH 1/2] mx31: define pins and init for UART2 and CSPI3 Helmut Raiger
2011-09-22 12:12 ` [U-Boot] [PATCH 2/2] TT-01: add basic board support for HALE TT-01 Helmut Raiger
2011-09-22 13:36   ` Fabio Estevam
2011-09-22 13:51   ` Stefano Babic
2011-10-06 13:07     ` Helmut Raiger
2011-10-06 13:27       ` Stefano Babic
2011-09-22 14:08   ` Wolfgang Denk
2011-09-28 12:48     ` [U-Boot] mx31: Approach for WEIM CS accessors Helmut Raiger
2011-09-28 12:48       ` [U-Boot] [PATCH] mx31: provide readable WEIM CS accessor Helmut Raiger
2011-09-28 15:14         ` Stefano Babic
2011-09-29  6:32           ` Helmut Raiger [this message]
2011-09-29  6:59             ` Stefano Babic
2011-09-29  7:30           ` Helmut Raiger
2011-09-29  9:17             ` Stefano Babic
2011-09-29 12:19         ` [U-Boot] [PATCH V2] " Helmut Raiger
2011-09-29 12:25         ` [U-Boot] [Resend PATCH V2 (forgot generic.c)] " Helmut Raiger
2011-09-29 13:21           ` Stefano Babic
2011-09-29 14:01             ` Helmut Raiger
2011-09-29 14:16               ` Stefano Babic
2011-09-29 14:55                 ` [U-Boot] [PATCH V3] " Helmut Raiger
2011-09-29 15:11                   ` Helmut Raiger
2011-09-29 15:19                     ` Stefano Babic
2011-09-29 15:45                 ` [U-Boot] [Resend PATCH " Helmut Raiger
2011-09-30  7:32                   ` Stefano Babic
2011-10-05 11:51                   ` Stefano Babic
2011-09-29 17:32               ` [U-Boot] [Resend PATCH V2 (forgot generic.c)] " Wolfgang Denk
2011-10-14  8:05 ` [U-Boot] [PATCH V2 1/3] mx31: define pins and init for UART2 and CSPI3 Helmut Raiger
2011-10-14  8:05   ` [U-Boot] [PATCH V2 2/3] mx31: add ESD control registers Helmut Raiger
2011-10-14 13:29     ` Stefano Babic
2011-10-14  8:05   ` [U-Boot] [PATCH V2 3/3] mx31: Add board support for HALE TT-01 Helmut Raiger
2011-10-14 11:04     ` Stefano Babic
2011-10-14 21:14       ` Wolfgang Denk
2011-10-15  5:40         ` stefano babic
2011-10-15  8:52           ` Wolfgang Denk
2011-10-15 11:11             ` Stefano Babic
2011-10-14 10:04   ` [U-Boot] [PATCH V2 1/3] mx31: define pins and init for UART2 and CSPI3 Stefano Babic
2011-10-27 11:31 ` [U-Boot] [PATCH V3 " Helmut Raiger
2011-10-27 11:31   ` [U-Boot] [PATCH V3 2/3] mx31: add ESD control registers Helmut Raiger
2011-10-27 12:49     ` Stefano Babic
2011-10-28  8:28     ` Stefano Babic
2011-10-27 11:31   ` [U-Boot] [PATCH V3 3/3] mx31: Add board support for HALE TT-01 Helmut Raiger
2011-10-27 12:59     ` Stefano Babic
2011-10-27 12:49   ` [U-Boot] [PATCH V3 1/3] mx31: define pins and init for UART2 and CSPI3 Stefano Babic
2011-10-28  8:28   ` Stefano Babic

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=4E8410F7.5020901@hale.at \
    --to=helmut.raiger@hale.at \
    --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