Hello,
On 2015-01-25 15:32, Sebastian Reichel wrote:
On Fri, Jan 23, 2015 at 12:11:22PM +0100, Marek Szyprowski wrote:
Frankly, I analyzed this case once again and I came to conclusion
that there is no need to make a separate reset driver for Odroid
boards. There is nothing special, specific to whole board about
this gpio. It is rather a property of MMC host controller and eMMC
card that is connected to it. When only gpio toggling code is
moved to reset handler registered from mmc controller, the board
properly performs reboot with a generic exynos4 code.
OK, so I guess this will be fixed independently via mmc subsystem.
I've posted an updated patch.
The poweroff code in above driver is just a generic Exynos4 code,
so again there is no need to duplicate it.
OK. It seems there is a driver for that in arch/arm/mach-exynos.
Otherwise I would have suggest to create something like
syscon-reboot for shutdown.
By moving the code to mmc driver, the same approach can be used for other
Odroid boards (XU/XU3) and maybe even other boards which need manual
resetting of eMMC cards to properly perform reboot procedure.
I suggest to start a new thread for discussing this, which includes
linux-mmc. It might be interesting to provide some more details about
eMMC_nDET, since MMC already contain a reset signal (which seems to
be used according to the odroid schematics I found).
My fault. The documentation for this initial driver was incorrect. The
reboot
fix has noting to eMMC_nDET signal. It should be eMMC nreset, which is
routed
directly to SoC GPIO line with external pull-up resistor. I really have no
idea why I wrote eMMC_nDET instead of nreset.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
