[PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm

[Tony Lindgren]

* Matthijs van Duin <matthijsvanduin at gmail.com> [150117 14:41]:
> On 17 January 2015 at 19:14, Tony Lindgren <tony at atomide.com> 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 ;-)

Luckily those can be defined which ever way in pinctrl single just
by changing the pinctrl-single,register-width entry.
 
> > 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).

Well sounds like no need to start messing with the existing ti81xx
defines excemt maybe rename cpu_is_ti81xx to soc_is_dm81xx and so
on. There are only very few places referencing that now. 
 
> > 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. ;-)

Yes I mean dm814x sorry :)
 
> 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.)

Uhh yeah.
 
> 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).

Hmm I sort of got the idea that dm814x and dm816x were done about
the same time. Are you saying dm814x was actually done after dm816x? 
 
> 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).

Yeah this davinci_emac vs cpsw stuff is messy and I noticed too that
the registers are different. 
 
> 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

Yeah all the add on devices are a whole different project.. But if
we get the basics working then at least somebody can work on that
if they want to.
 
> 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.

Hmm that's a lot of accelerators..
 
> Once the basics work there's definitely some neat gear on these chips
> to play with

Yup :)

Tony