[U-Boot] [PATCH 2/2] ARM: tegra: Add the Tamonten™ NG Evaluation Carrier board

[Alban Bedel <alban.bedel@avionic-design.de>]

On Wed, 04 Sep 2013 12:05:00 -0600
Stephen Warren <swarren@wwwdotorg.org> wrote:

> On 09/04/2013 07:00 AM, Alban Bedel wrote:
> > Add support for the new Tamonten? NG platform from Avionic Design. 
> > Currently only I2C, MMC, USB and ethernet have been tested.
> 
> (Also CC'ing the Tegra maintainer here)

Ok, I'll add him in the next patch round.

> > diff --git a/board/avionic-design/common/tamonten-ng.c
> > b/board/avionic-design/common/tamonten-ng.c
> >
> > +void pmu_write(uchar reg, uchar data)
> > +{
> > +	int i;
> > +   i2c_set_bus_num(0);	/* PMU is on bus 0 */
> > +	for (i = 0; i < MAX_I2C_RETRY; ++i) {
> > +		if (i2c_write(PMU_I2C_ADDRESS, reg, 1, &data, 1))
> > +			udelay(100);
> > +		else
> > +			break;
> > +	}
> > +}
> 
> Is there really a need to retry the I2C transactions? If so, why do
> they fail? I assume this was just copy/pasted from some other board
> file, and there's no need for any retries?

Yes, that was adapted from the cardhu code and the retry are most
probably useless. I just made a bit more generic function because
we have to set several outputs, on cardhu only one is set.

> It'd be nice if there was a proper PMU subsystem, so we could have a
> specific driver for each PMU chip, rather than having
> open-coded/custom writes to the PMU registers in each board file, but
> I guess that's not an issue with this patch specfically.

A PMU subsystem would be nice, although something that would be
compatible with the Linux regulator and their representation in DT
would be even better.

Otherwise a first step could be to at least create a driver for this
PMU, similar to one for tps6586x. That would at least prevent too much
code duplication between the T30 boards.

> > diff --git a/include/configs/tec-ng.h b/include/configs/tec-ng.h
> >
> > +/* support the new (FDT-based) image format */
> > +#define CONFIG_FIT
> 
> Hmmm. Do the standard Tegra boot scripts in tegra-common-post.h deal
> well with FIT? I've tried to avoid FIT usage as much as possible.

AFAIU it doesn't change anything if you use old images, it just allow
you to also use FIT image. As the build system we use for our platform
produce FIT image we do need support for it. Or should such things,
which are not related to the HW config, be configured in another place?

Alban