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.