[U-Boot] [PATCH v1] cpu: Add Intel Tangier support

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, 2017-06-20 at 13:35 -0600, Simon Glass wrote:
> Hi Andy,
> 
> On 20 June 2017 at 13:02, Andy Shevchenko <andy.shevchenko@gmail.com>
> wrote:
> > On Tue, Jun 20, 2017 at 9:51 PM, Simon Glass <sjg@chromium.org>
> > wrote:
> > > On 20 April 2017 at 03:41, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > Andy, any update on this please? Is it still in progress?
> > 
> > Hi, yes, it is still in progress.
> > The issue is I have not much time to look at it.
> 
> OK thanks.

I'm about to send new version.
Though, there is one thing to be clear of...

> 
> > Can you remind me what is the summary regarding power suppliers?
> > 
> > From hardware point of view there no regulators wrt SDHCI host
> > controllers, only some let's say magic bits that needs to be set or
> > clear.
> 
> The issue is just that we cannot call from drivers into board code. If
> you don't want to model it as a regulator 

Okay, meaning there is no consensus, U-Boot (as I see currently) is
broken in few ways, one of them is ignoring hardware and proposing to
emulate something which certain board doesn't have. That's not how
things work.

Linux kernel is not the same in terms of DM in this case. In Linux this
board (and SDHCI controllers) is represented differently (by emulating
PCI programming interface). And there the PM code is much more
complicated than here.

> perhaps you could call into
> code in arch/arm/cpu/... to flip the bits?

(x86)

It was at very beginning like that, but since SCU and PMU are
represented as system controllers (which they indeed are), the calling
to them from CPU code would be hackish.

So, the only way I see now is to disable SD card slot on that board
blaming U-Boot upstream DM design for that.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy