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
=====================================================================
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox