[U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)

[Tom Rini]

On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote:
> Hi Tom,
> 
> On 14/05/13 17:52, Tom Rini wrote:
> > On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote:
> >> Hi Tom,
> >>
> >> I'm currently busy with other work; on the other hand, careful
> >> rebasing shall require some time, especially the Palmas stuff.
> >> What would be the deadline for a V2 submission?
> >>
> >> Meanwhile could you please have a look at the (already old)
> >> http://patchwork.ozlabs.org/patch/232743/? A simple patch,
> >> shall be needed if we enable USB (for the uEVM along with
> >> our board). In general, what are your plans regarding USB
> >> (.../patch/232742/)?
> > 
> > Thanks for the reminder, I'll grab 232743 soon.  232742 looks OK, but do
> > you have a patch around for uEVM still?
> Not yet (didn't have the opportunity to test, although some uEVMs should
> be around at MMS). As you know, a patch shall be needed in the uEVM board
> file along with the common USB stuff.

Yeah, I can test it as well if you write it up, and may find the time if
you point me in the right direction.

> >> And again on I2C (.../patch/233823/): what is you final
> >> opinion? I'm confident that this patch is a major improvement
> >> for OMAP4/5 at least.
> > 
> > I'm inclined to go with it, just need to mentally unswap the i2c notes
> > in my brain and think it over one more time.
> Just applied 233823 to current u-boot-ti master. Works fine.

OK, thanks.

> > [snip]
> >>>>>> +	 * TODO: Replace this ugly hardcoding with proper defines +
> >>>>>> */ +	writel(0x0100, 0x4ae0a310);
> >>>>>
> >>>>> Again, do please.
> >>>> This should be (*scrm)->auxclk0. The problem is that the
> >>>> omap5_scrm_regs struct (holding the auxclk0 member) has to be
> >>>> defined somewhere in the common OMAP5 headers. Sricharan? Or should
> >>>> I hack around?
> >>>
> >>> Add it to the most likely struct in the headers.
> >> The entire struct (I call it omap5_scrm_regs in theory, similar to the
> >> corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of
> >> course I could define only the member that I need, but I guess it is
> >> a (responsible) TI job to define hardware descriptors. Or I'm wrong?
> >> Please advise. If I have time, I could do it myself - it's some 27
> >> registers, almost identical to the OMAP4, and should go into 
> >> arch/arm/include/asm/arch-omap5/clocks.h.
> > 
> > Whomever uses / needs it should do it.  I gave the TRM a quick read and
> > I don't see any conflicts per-se just some reserved areas being named
> > and vice versa.  So rename it to omap_scrm_regs and move to
> > <asm/omap_common.h>.  Thanks!
> I would argue that this is not very appropriate. Those regs that are
> reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4;
> on the other hand the OMAP5 has some modem clock regs that are reserved
> on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3
> and below?

We don't need to use ifdefs since there's no conflicts, things are
either reserved in one case and used in the other.  And we can make sure
we don't try and use the omap5 bits on omap4 and vice versa.  I don't
see scrm in the first omap3 TRM I pulled up, so we don't need to worry
there.

> Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h
> file and I have already done the same for OMAP5 by analogy. I must admit
> however that this approach does not correspond to the latest way by which
> groups of OMAP hardware regs are defined, prcm in particular - a struct in
> omap_common.h, holding only the required regs, no padding and such garbage,
> and an init with the physical addresses in a .c file for the particular SoC
> (prcm-regs.c). But still the Panda board, for example, uses the old way for
> scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and
> lazy ;) ).

Yes, I'm OK starting off with moving things into omap_common.h as-is and
then updating them a bit later ala pcrm-regs.c.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130514/0d6e9e6c/attachment.pgp>