public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Dirk Eibach <dirk.eibach@gdsys.cc>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 06/10] powerpc/ppc4xx: Use generic FPGA accessors on all gdsys 405ep/ex boards
Date: Wed, 08 May 2013 13:17:04 +0200	[thread overview]
Message-ID: <913a7e8badaaed06605fdf68faacedc8@gdsys.cc> (raw)
In-Reply-To: <20130508101333.6DDB438119E@gemini.denx.de>

Hi Wolfgang,

thanks for investing so much time into this. It is really appreciated.

Am 08.05.2013 12:13, schrieb Wolfgang Denk:
> Dear Dirk,
> 
> In message <58ff5023adcbf08481bc2707b0a70f50@gdsys.cc> you wrote:
>> 
>> in my example we have four FPGAs. One is memory mapped while the 
>> other
>> three are not.
>> They all have the same register interface which is mapped by
>>    struct ihs_fpga {
>> 	u16 reflection_low;
>> 	u16 versions;
>> 	...
>> 	u16 mc_tx_address;
>> 	u16 mc_tx_data;
>> 	u16 mc_tx_cmd;
>> 	...
>>    };
>> 
>> To have instances of those FPGA structs, we might create an array 
>> like
>> this:
>>    struct ihs_fpga system_fpgas[] = {
>> 	(struct ihs_fpga *)CONFIG_SYS_FPGA_BASE,
>> 	(struct ihs_fpga *)NULL,
>> 	(struct ihs_fpga *)NULL,
>> 	(struct ihs_fpga *)NULL,
>>    };
>> The first element ist our memory mapped FPGA with base address
>> CONFIG_SYS_FPGA_BASE. For the other three I use NULL as base address
>> because I don't have any better idea what else to choose.
>> 
>> To probe those FPGAs we might have to do something like:
>>    for (k=0; k < 4; ++k)
>> 	fpga_set_reg(k, &system_fpgas[k].reflection_low,
> 
> I think using index notation everywhere makes the code hard to read.
> Use a pointer, for example like that:
> 
> 	struct ihs_fpga *fpgap = system_fpgas[k];
> 
> 	fpga_set_reg(k, &fpgap->reflection_low, ...
> 
>> The implementation of fpga_set_reg() might look like:
>> 
>> void fpga_set_reg(unsigned int fpga, u16 *reg, u16 data)
>> {
>> 	switch (fpga) {
>> 	case 0:
>> 		out_le16(reg, data);
>> 		break;
>> 	default:
>> 		mclink_send(fpga - 1, (u16)reg, data);
>> 		break;
>> 	}
>> }
> 
> The problem here comes from your decision to use the same interface
> for two different, incompatible things.  There are two ugly parts in
> this code:  first is the need for a cast, second (and even worse) is
> the use of a pointer value of 0 to get to the offset of a field.
> Actually this is not even standard conformng, as you initialize the
> pointer as NULL, and there is no real guarantee that
> 
> 	NULL == (struct ihs_fpga *)0

You are right. This is *exactly* what I meant when I wrote: "We have 
FPGAs that are memory mapped and others that are not. They must be 
accessed by the same drivers. So the alternative would be to create FPGA 
instances at address NULL and getting the register offesets by casting 
pointers to u16. Not very nice either." on monday.


> It appears you need both the element address and the offset in your
> fpga_set_reg() code, so you should pass this information, like that
> [note that we no longer need an array of addresses]:
> 
> struct ihs_fpga fpga_ptr = (struct ihs_fpga *)CONFIG_SYS_FPGA_BASE;
> ...
> 
> void fpga_set_reg(u32 fpga, u16 *reg, off_t regoff, u16 data)
> {
> 	if (fpga)
> 		return mclink_send(fpga - 1, regoff, data);
> 
> 	return out_le16(reg, data);
> }
> 
>> where mclink_send() is the routine to access the non memory mapped
>> FPGAs through the memory mapped FPGA:
>>    int mclink_send(u8 slave, u16 addr, u16 data)
>>    {
>> 	...
>> 	fpga_set_reg(0, &system_fpgas[0].mc_tx_address, addr);
>> 	fpga_set_reg(0, &system_fpgas[0].mc_tx_data, data);
>> 	fpga_set_reg(0, &system_fpgas[0].mc_tx_cmd, (slave & 0x03) << 14);
>>    }
> 
> And this becomes:
> 
> 	fpga_set_reg(0,
> 		     &fpga_ptr->mc_tx_address,
> 		     offsetof(struct ihs_fpga, mc_tx_address),
> 		     addr);
> 
> etc. Yes, this is long and ugly to write, so you may want to define a
> helper macro like:
> 
> #define FPGA_SET_REG(ix,fld,val)	\
> 	fpga_set_reg((ix),		\
> 	&fpga_ptr->fld,			\
> 	offsetof(struct ihs_fpga, fld),	\
> 	val)
> 
> so this turns into a plain and simple
> 
> 	FPGA_SET_REG(0, mc_tx_address, addr);
> 	FPGA_SET_REG(0, mc_tx_data, data);
> 	FPGA_SET_REG(0, mc_tx_cmd, (slave & 0x03) << 14);
> 
> 
> What do you think?

Very nice.
I think this looks supringsingly similar to my original implementation 
in the patch series. There we have:
   #define REG(reg) offsetof(struct ihs_fpga, reg)
and
   fpga_set_reg(k, REG(reflection_low), REFLECTION_TESTPATTERN);
and
   void fpga_set_reg(unsigned int fpga, u16 reg, u16 data)
   {
	int res;
	struct ihs_fpga *fpga_0 = (struct ihs_fpga *)CONFIG_SYS_FPGA_BASE(0);

	switch (fpga) {
	case 0:
		out_le16((u16 *)fpga_0 + reg / sizeof(u16), data);
		break;
	default:
		res = mclink_send(fpga - 1, reg, data);
		if (res < 0)
			printf("mclink_send reg %02x data %04x returned %d\n",
			       reg, data, res);
		break;
	}
   }

Sorry, I'm a little confused here. Is your approach an improvement 
anyway?

Cheers
Dirk

  reply	other threads:[~2013-05-08 11:17 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-06 13:35 [U-Boot] [PATCH v2 0/10] Update gdsys ppc4xx-based boards dirk.eibach at gdsys.cc
2013-05-06 13:35 ` [U-Boot] [PATCH v2 01/10] powerpc/ppc4xx: Add generic accessor functions for gdsys FPGA dirk.eibach at gdsys.cc
2013-05-06 14:01   ` Wolfgang Denk
2013-05-06 14:02   ` Wolfgang Denk
2013-05-06 13:35 ` [U-Boot] [PATCH v2 02/10] powerpc/ppc4xx: Add gdsys mclink interface dirk.eibach at gdsys.cc
2013-05-06 13:35 ` [U-Boot] [PATCH v2 03/10] powerpc/ppc4xx: Add fpgad command for dumping gdsys fpga registers dirk.eibach at gdsys.cc
2013-05-06 13:35 ` [U-Boot] [PATCH v2 04/10] powerpc/ppc4xx: Use generic FPGA accessors in gdsys common code dirk.eibach at gdsys.cc
2013-05-06 14:07   ` Wolfgang Denk
2013-05-06 14:57     ` Tom Rini
2013-05-06 15:02       ` Dirk Eibach
2013-05-06 15:09         ` Tom Rini
2013-05-06 15:51           ` Dirk Eibach
2013-05-06 13:35 ` [U-Boot] [PATCH v2 05/10] powerpc/ppc4xx: Support gdsys multichannel iocon hardware dirk.eibach at gdsys.cc
2013-05-06 14:12   ` Wolfgang Denk
2013-05-06 14:16     ` Dirk Eibach
2013-05-06 15:18       ` Wolfgang Denk
2013-05-06 15:49         ` Dirk Eibach
2013-05-06 19:15           ` Wolfgang Denk
2013-05-06 19:31             ` Joe Hershberger
2013-05-06 13:35 ` [U-Boot] [PATCH v2 06/10] powerpc/ppc4xx: Use generic FPGA accessors on all gdsys 405ep/ex boards dirk.eibach at gdsys.cc
2013-05-06 14:10   ` Wolfgang Denk
2013-05-06 14:50     ` Dirk Eibach
2013-05-06 15:22       ` Wolfgang Denk
2013-05-06 15:55         ` Dirk Eibach
2013-05-06 19:23           ` Wolfgang Denk
2013-05-07  8:32             ` Dirk Eibach
2013-05-07 11:36               ` Wolfgang Denk
2013-05-07 12:08                 ` Dirk Eibach
2013-05-07 19:18                   ` Wolfgang Denk
2013-05-07 20:45                     ` Dirk Eibach
2013-05-08 10:13                       ` Wolfgang Denk
2013-05-08 11:17                         ` Dirk Eibach [this message]
2013-05-08 15:37                           ` Wolfgang Denk
2013-05-15  9:23                         ` Dirk Eibach
2013-05-28  7:39                           ` Dirk Eibach
2013-05-28  7:47                           ` Dirk Eibach
2013-05-28 11:47                           ` Wolfgang Denk
2013-05-06 13:35 ` [U-Boot] [PATCH v2 07/10] powerpc/ppc4xx: Fixup phy erratum on gdsys iocon hardware dirk.eibach at gdsys.cc
2013-05-06 13:35 ` [U-Boot] [PATCH v2 08/10] powerpc/ppc4xx: Increase timeout for gdsys mclink bus startup dirk.eibach at gdsys.cc
2013-05-06 13:35 ` [U-Boot] [PATCH v2 09/10] powerpc/ppc4xx: Consider gdsys FPGA OSD size dirk.eibach at gdsys.cc
2013-05-06 13:35 ` [U-Boot] [PATCH v2 10/10] powerpc/ppc4xx: Remove CONFIG_SYS_FLASH_PROTECTION from gdsys boards dirk.eibach at gdsys.cc
2013-05-06 14:03 ` [U-Boot] [PATCH v2 0/10] Update gdsys ppc4xx-based boards Wolfgang Denk

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=913a7e8badaaed06605fdf68faacedc8@gdsys.cc \
    --to=dirk.eibach@gdsys.cc \
    --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