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

On 26 January 2015 at 16:58, Tony Lindgren [off-list ref] wrote:

See earlier I was assuming copy paste issues from dm814x to dm816x

Ahh, you thought the 816x was 814x-derived... yes I can imagine that
will have led to some confusion.

I'm pretty sure I verified the that the audio_pll_clk1 is hardwwired
to 32KiHz by looking at it with a scope on the clkout pin.

Yeah it comes straight from the "rtcdivider" so it'll produce
0.0016384 * devosc.

The global clock structure overview in the TRM (figure 2-6) actually
correctly marks the former-audio-fapll clocks (except audio5 := osc0,
yielding sysclk22 after divider) but you already need to know what the
hell is going on to recognize that.


Oh, on the topic of PRCM, a word of caution: while the cold reset
default of PM_DEFAULT_PWRSTCTRL is 0, performing _any_ write to it
(regardless of value) sets it to 3 (force power-on) until next cold
reset. An unfortunately side-effect I stumbled over is that a
particular bus lockup that can occur in ducati (dual cortex-m3
subsystem) then becomes warm-reset-insensitive.

The statement I got from TI support about the strange behaviour of
this power control register was.. vague:

  In DM814x, complete functionality of PRCM was not used and that
  resulted into such requirements.

  This recommendations was made based on DV test cases with POWERONSTATE
  == ON/0x3.

  We didn?t do any negative testing to see the behaviour in case
  POWERONSTATE != ON/0x3.

  So I can recommend you to test your system without this requirement
  and see if you will have any issues. I think this requirement is not
  needed (POWERONSTATE == ON/0x3), as the DM814x EZSDK (u-boot, linux
  kernel) is working fine without it.

quoted

The inventory of SecSS on Netra yielded exactly the same list of
accelerators and other peripherals as on Centaurus btw. The only
changes seem to be in subsystem control stuff.

What are you using to identify the devices? The device revision
register? Or are there actually some populated interconnect data
available with device info that could be used for a real scannable
bus?

You mean the modules? SecSS unfortunately doesn't have an integrated
memory map like the one present in the Sonics S3220 interconnects, so
I just probed it manually while making use of the knowledge I already
had of SecSS on Centaurus.  It helps that I already did quite a bit of
exploration of SecSS on Centaurus, and it turns out to barely differ
from the original one* on Netra. The differences seem to be
permissions-related: the subsystem control module was split into two
separate parts and there was a tiny bit of rearrangement for the
benefit of being able to cover multiple modules with a single firewall
region.

I've updated the SecSS sheet of my memory-map spreadsheet to highlight
the differences.

It's not totally clear what the intentions are of the various default
firewall regions. Region 0 will undoubtedly be highly restricted on
all but GP devices. On centaurus region 5 looks like it'll be
exclusively for the cortex-m3 on devices where it automatically boots
stand-alone from ROM (EMU/HS) instead of waiting to boot into
user-supplied code on request (Test/GP/EMUL/HSL).


*TI's linux driver calls it "NSS" (Netra Security Subsystem) on both
chips, so presumably Netra was the first to have this kind of
subsystem.