Hi, On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: > 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. > > I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out..
Regards, Sricharan > > _______________________________________________ > U-Boot mailing list > [email protected] > http://lists.denx.de/mailman/listinfo/u-boot
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
