All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mx31: provide readable WEIM CS accessor
Date: Thu, 29 Sep 2011 08:59:25 +0200	[thread overview]
Message-ID: <4E84174D.2010908@denx.de> (raw)
In-Reply-To: <4E8410F7.5020901@hale.at>

On 09/29/2011 08:32 AM, Helmut Raiger wrote:
> 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*,

Note: I understand now the misunderstanding. I want to pass a struct
weim_regs *, not 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,

This is ok

> but
> this might not be a problem with the CS registers. However passing the
> complete set of chip selects wouldn't work,

This is not what I meant. I want that the function change only one
chipselect, not all chipselects in one shot.

> 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).

No bitmap please...

> 
> What about:
> 
> void mxc_setup_weimcs(int cs, const struct mxc_weimcs *cs)
> {
> ...
> }

This is what I meant ! Only to check the names: mxc_weimcs is what I
described as weim_regs, right ? And this structure can be specified for
each SOC.

> 
> 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);

Yes, right

> }
> 
> This should still work for different SOCs (with different struct
> mxc_weimcs).

Exactly.

> CSCR_U et al. will be mx31 specific defines.

This is not a problem - other SOCc have or can have a different layout.
It is correct to define these macro into imx-regs.h, as you already did.

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

  reply	other threads:[~2011-09-29  6:59 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
2011-09-29  6:59             ` Stefano Babic [this message]
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=4E84174D.2010908@denx.de \
    --to=sbabic@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 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.