BBB & IMX6 Hummingboard SDIO driver

[Ilya Bakulin]

On 2017-07-19 05:19, Russell Haley wrote:
> Current Status:
> 
> Building and Installing - BBB
> - Either the information about building a Beaglebone has fallen out of
> date, or the beaglebone black has different requirements that should
> be documented on that page. Boot pieces:
> - MLO
> -u-boot.img
> -ubldr.bin
> 
> - The kernel I built yesterday panics during load due to a sleep lock
> that has already been identified by kibab (aka Ilya). I will attempt
> to patch it tomorrow.

I'm not sure what problem are you talking about. The patch on 
Phabricator
tries to address a problem that there are several sleep() calls
used in the MMC/SD probe code.
This code shouldn't sleep. So I'm trying to get rid of sleeps,
but the patch I've generated so far doesn't work -- this is just a 
starting point.
So if the version from -HEAD panics at boot -- this is a bug and I need
to address it. I haven't booted BBB in ages and will have sufficient 
time
to debug the problem myself in two weeks (during DevSummit in 
Cambridge).

> Source Code
> The following is my examination of the code I can identify as
> involving the new MMCCAM stack. I am reading first to understand how
> the pieces fit and then will get into the details.
> 
>  - All mmccam functions for BBB sd cards is run through the sdhci
> driver in /sys/dev/sdhci/sdhci.c which is extended by
> arm/ti/ti_sdhci.c. When a custom kernel configuration is used, the
> MMCCAM flag is specified and the MMCCAM specific code is compiled into
> /sys/dev/sdhci/sdhci.c and .h.
Yes, that's right.

>  - There seems to be a implementation specific startup routine
> compiled into the arm/ti/ti_sdhci.c using an ifdef. There is also a
> custom read and write defined so I assume there is some board specific
> things that need adjusting. Need to look closer
Yes, initialization function for MMCCAM is different.
Also there is #ifdef'ed code in write_1 and read_1 because I need to 
adjust
a 8-bit enable bit when writing to SDHC control register.
Old stack did it in ios handling, but MMCCAM doesn't allow device 
drivers
to have their own ios handling.

>  - sdhci code paths seem to directly use the cam_ccb and cam_sim
> rather than call any mmc specific code. It seems the sdhci uses the
> cam bus but not the mmc_sdio code, nore the cam_xpt_* code.
This is correct -- every CAM request/response is routed by the CAM 
subsystem.

> - Note: in /sys/dev/sdhci/sdhci.c the includes on lines 51 through 55
> are duplicated in an ifdef MMCCAM at lines 1979 through 1985. Is that
> intentional?
No, this should be corrected. Thanks!

> 
> cam/mmc
> - mmc_sdio seems to be it's own thing. It includes both the
> cam_sim/cam_ccb and the cam_xpt_* headers but I don't know yet if it
> uses both sets of functionality (code is still opaque to me).
This code is not used yet since there is no SDIO-specific code for now.
> 
> Okay, back at it tomorrow. Ilya, Warner, if you're around at all I'd
> love to get a state of the union from you.

Replying to your question on IRC wrt communication protocol: I don't 
frequently
monitor all FreeBSD mailing lists and can easily miss SDIO-related stuff
unless I'm directly CC'ed.
I have a highlight setup for the #bsdmips IRC channel that notifies me
when SDIO or my nickname is mentioned, so I will know someone was 
talking
about these things.

I'm in Munich (timezone is CEST), so reply times might be longer for 
US-based folk.
-- 
Mit freundlichen Grüßen,
Ilya Bakulin