[U-Boot] [PATCH v2 08/15] dm: mmc: sunxi: Pass private data around explicitly

[Simon Glass]

Hi Chen-Yu,

On 8 August 2017 at 21:27, Chen-Yu Tsai <wens at csie.org> wrote:
> Hi Simon,
>
> On Wed, Jul 5, 2017 at 3:31 AM, Simon Glass <sjg at chromium.org> wrote:
>> At present the driver-private data is obtained in various functions by
>> various means. With driver model this is provided automatically. Without
>> driver model it comes from a C array declared at the top of the file.
>>
>> Adjust internal functions so that they are passed the private data as
>> a parameter, allowing the caller to obtain it using either means.
>>
>> Signed-off-by: Simon Glass <sjg at chromium.org>
>
> eMMC is currently broken for sunxi on my Orangepi Plus 2E.
> I've narrowed it down to this patch.
>
> It seems the driver or device is now referencing the wrong
> controller. On versions before this patch, for MMC1 (or eMMC):
>
> => mmc dev 1
> switch to partitions #0, OK
> mmc1(part 0) is current device
> => mmc info
> Device: SUNXI SD/MMC
> Manufacturer ID: 15
> OEM: 100
> Name: AWPD3
> Tran Speed: 52000000
> Rd Block Len: 512
> MMC version 5.0
> High Capacity: Yes
> Capacity: 14.6 GiB
> Bus Width: 8-bit
> Erase Group Size: 512 KiB
> HC WP Group Size: 8 MiB
> User Capacity: 14.6 GiB WRREL
> Boot Capacity: 4 MiB ENH
> RPMB Capacity: 4 MiB ENH
>
>
> On later versions I get:
>
> => mmc dev 1
> switch to partitions #0, OK
> mmc1 is current device
> => mmc info
> Device: SUNXI SD/MMC
> Manufacturer ID: 27
> OEM: 5048
> Name: SD08G
> Tran Speed: 50000000
> Rd Block Len: 512
> SD version 3.0
> High Capacity: Yes
> Capacity: 7.4 GiB
> Bus Width: 1-bit
> Erase Group Size: 512 Bytes
>
>
> For reference, mmc0 looks like:
>
> => mmc dev 0
> switch to partitions #0, OK
> mmc0 is current device
> => mmc info
> Device: SUNXI SD/MMC
> Manufacturer ID: 27
> OEM: 5048
> Name: SD08G
> Tran Speed: 50000000
> Rd Block Len: 512
> SD version 3.0
> High Capacity: Yes
> Capacity: 7.4 GiB
> Bus Width: 4-bit
> Erase Group Size: 512 Bytes
>
>
> So it seems somewhere down the line, the driver is getting
> passed the wrong set of priv data.

Are you sure it was this patch?

The ordering may have changed because there was a strange hack in the
code before. There was some discussion about it but unfortunately I
cannot find the thread right now. Can you take a look?

Regards,
Simon