On 17 January 2015 at 19:14, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > Oh OK. And looks like dm814x trm claims to have PINCNTL[7:0] > bits for MUXMODE instead of just bits [2:0]? However, the datasheet's table of possible mux modes per pin has as column headers: 0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 0x80. (mode 0, called "safe mode" is mentioned separately) For compatibility sake I'm personally more inclined to consider them modes 0-7 with "safe mode" being -1. Oh, and I just remembered: while 811x is mostly compatible with 814x, it has up to 12 mux modes per pin. So replace "byte-write" by "u16-write" in my previous post ;-) >> It also means you can change mode with a u16-write to avoid touching >> the upper bits > > Maybe that's why some bits got shifted :) Yes, in general bitfields seem to be grouped into separate bytes in quite a few places where it may be convenient to take advantage of the fact that both PRCM and the Control module are byte-addressable to avoid having to do a read-modify-update. (For example the omap4/5 standard layout for CLKCTRL puts modulemode in byte 0, optional fclks in byte 1, and any mux/div config the module may have in the upper bytes. Only the am335x violates this rule.) >> The overall control module layout is actually compatible across the >> whole happy family > > Got any generic naming in mind for the helper macro we could use? I've already been pondering what to call this family, since architecturally they do very clearly form a fairly close family related to, but also clearly distinct from, the omap4/5 line. As you may notice from my spreadsheet I already generally prefer to use their names (Netra, Centaurus, Subarctic, Aegis), both because names are rather more memorable and distinguishable for humans than 4-digit numbers and because each actually has a flurry of wildly different part codes depending on which subsystems happen to fail the factory test and get disabled (which may of course be a big deal featurewise but is rather irrelevant to the kernel). Still leaves four names to unify... I may be biased but I'm leaning towards "Centauroid": Centaurus (814x) seems to have a fairly central position, being memory-map compatible with the there other members (i.e. no subsystem/peripheral of Centaurus overlaps a different one of another device), while the same is not true between Netra (816x) and subarctic (335x). I suspect this may be because Centaurus and Netra form a single product line (DM81xx) iin one market segment (video) while Centaurus and Subarctic form a single product line (DRA6xx) in another market segment (automotive). > Cool, that certainly helps. To me it looks dm814x needs it's own > clock driver for the source clocks, but after that the dividers > are similar to dm816x and am33xx. Have not looked at the am814x > beyond that though. dm814x you mean... the downfeatured Sitara version got called am387x, naturally. ;-) The biggest architectural differences between three chips are indeed in PRCM, where each member has its own peculiarities: Netra and Centaurus both have the simple but clean omap4-subset PRCM. No fancy auto-management by hardware but at least a clean well-organised interface, with the biggest blemish being the register-swap in PRM_SGX. (Subarctic's PRCM is of course shocking in contrast, being organized by "sort -R", incompatibility with the omap4/5 register layouts, and a seemingly endless supply of novel ways of being inconsistent.) Netra however has the FAPLL experiment, which apparently wasn't a success so while Centaurus retained much of the clock tree it reverted to using normal PLLs by replacing the FAPLLs with its PLL subsystem containing additional clock muxes to sort of glue it onto the existing clock tree, making the clock tree a bit messier. (Especially older versions of the TRM were very confusing to those unfamiliar with this Netra-heritage since FAPLL names were still all over the place.) In line with the "fully software managed" tradition, it seems to wire *all* control/status signals of the PLLs directly into registers. They can be slightly fickle (and mucking up the MPU PLL can leave you pretty screwed, especially since the watchdog reset doesn't reset the PLLs). Also important: Centaurus has very similar Ethernet subsystem to that of subarctic, though some components are a slightly older minor revision. In violation of what a "minor revision" normally means, they are however software-incompatible thanks to moving blocks of registers around to different offsets, and some per-port settings became global or vice versa. This however seems to be a tradition for the 3-port gigabit switch subsystem: out of curiosity I examined the ones in other TI SoCs, and it turns out that literally *all* of them have different, incompatible register layouts (sometimes also extending to the switch table entries and/or DMA descriptors). Other than this, the subsystems and peripherals are mostly familiar omap4-generation stuff, but with a standard C674x DSP instead of omap4's weird custom "Tesla" DSP (although some Tesla documentation accidentally got copy-pasted into Netra's TRM). An overview of the video situation on Centaurus (afaik, I'm not deeply into the video stuff) can be found in this post, where I was also cheerleading your efforts towards mainline dm81xx support: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/246653/1396681#1396681 There's also an interesting Security Subsystem, which houses the crypto accelerators (2x AES, 2x Hash, DES, PKA, RNG), an SDMA engine, 128 KB + 16 KB of local RAM, a cortex-M3, some timers for its benefit, irq routing, and an elaborate L3 firewall instance covering both external and internal access. It is about as well-documented as the crypto accelerators on the am335x are :P Still, it's not hard to get it operational, and allows e.g. sequencing of composite crypto operations combined with DMA without the kernel having to micro-manage it, along with secure local key storage. Once the basics work there's definitely some neat gear on these chips to play with -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
