Date:	Tue, 16 Apr 2013 12:35:40 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Kukjin Kim <kgene.kim@...sung.com>
Cc:	Mike Turquette <mturquette@...aro.org>,
	Tushar Behera <tushar.behera@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	Patch Tracking <patches@...aro.org>,
	Thomas Abraham <thomas.abraham@...aro.org>,
	Olof Johansson <olofj@...omium.org>
Subject: Re: [PATCH] clk: exynos5250: Fix divider values for sclk_mmc{0,1,2,3}

Hi,

On Mon, Apr 8, 2013 at 12:22 AM, Kukjin Kim <kgene.kim@...sung.com> wrote:
> Mike Turquette wrote:
>>
>> Quoting Tushar Behera (2013-04-02 01:20:40)
>> > In legacy setup, sclk_mmc{0,1,2,3} used PRE_RATIO bit-field (8-bit wide)
>> > instead of RATIO bit-field (4-bit wide) for dividing clock rate.
>> >
>> > With current common clock setup, we are using RATIO bit-field which
>> > is creating FIFO read errors while accessing eMMC. Changing over to
>> > use PRE_RATIO bit-field fixes this issue.
>> >
>> > dwmmc_exynos 12200000.dwmmc0: data FIFO error (status=00008020)
>> > mmcblk0: error -5 transferring data, sector 1, nr 7, cmd response 0x900,
>> card status 0x0
>> > end_request: I/O error, dev mmcblk0, sector 1
>> >
>> > Signed-off-by: Tushar Behera <tushar.behera@...aro.org>
>> > CC: Thomas Abraham <thomas.abraham@...aro.org>
>>
>> I guess this will be applied through the samsung tree, so:
>>
>> Acked-by: Mike Turquette <mturquette@...aro.org>
>>
> Thanks, applied.

I haven't yet had time to dig / track down why, but this patch totally
messes up access to the eMMC on the ARM Chromebook (exynos5250-snow).
I suddenly start getting FIFO errors like you show above.  When I
revert your change then I'm all happy.

Perhaps I need a device tree setting change as well?  I always forget
how the "samsung,dw-mshc-ciu-div" / "samsung,dw-mshc-sdr-timing"
properties work...

For the short term I'm going to revert locally since I've got a few
other things to do over the next few days.  If nobody else gets around
to it then I'll try to find time to dig further.

---

Log messages at boot before your change applied:

localhost ~ # dmesg | grep mmc[a-z]*0
[    1.460000] dwmmc_exynos 12200000.dwmmc0: Using internal DMA controller.
[    1.465000] dwmmc_exynos 12200000.dwmmc0: Version ID is 241a
[    1.475000] dwmmc_exynos 12200000.dwmmc0: DW MMC controller at irq
107, 32 bit host data width, 128 deep fifo
[    1.485000] mmc0: no vmmc regulator found
[    1.510000] mmc_host mmc0: Bus speed (slot 0) = 100000000Hz (slot
req 400000Hz, actual 400000HZ div = 125)
[    1.530000] dwmmc_exynos 12200000.dwmmc0: 1 slots initialized
[    1.750000] mmc0: BKOPS_EN bit is not set
[    1.750000] mmc_host mmc0: Bus speed (slot 0) = 100000000Hz (slot
req 52000000Hz, actual 50000000HZ div = 1)
[    1.755000] mmc0: new high speed DDR MMC card at address 0001
[    1.755000] mmcblk0: mmc0:0001 SEM16G 14.6 GiB
[    1.780000] mmcblk0boot0: mmc0:0001 SEM16G partition 1 2.00 MiB
[    1.785000] mmcblk0boot1: mmc0:0001 SEM16G partition 2 2.00 MiB
[    1.790000] mmcblk0rpmb: mmc0:0001 SEM16G partition 3 128 KiB
[    1.800000]  mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12
[    1.825000]  mmcblk0boot1: unknown partition table
[    1.835000]  mmcblk0boot0: unknown partition table


Log messages at boot after your change (note that the bus speed is
reported as different which is what lead me to your change):

localhost ~ # dmesg | grep mmc[a-z]*0
[    1.440000] dwmmc_exynos 12200000.dwmmc0: Using internal DMA controller.
[    1.445000] dwmmc_exynos 12200000.dwmmc0: Version ID is 241a
[    1.455000] dwmmc_exynos 12200000.dwmmc0: DW MMC controller at irq
107, 32 bit host data width, 128 deep fifo
[    1.465000] mmc0: no vmmc regulator found
[    1.490000] mmc_host mmc0: Bus speed (slot 0) = 200000000Hz (slot
req 400000Hz, actual 400000HZ div = 250)
[    1.510000] dwmmc_exynos 12200000.dwmmc0: 1 slots initialized
[    1.760000] mmc0: BKOPS_EN bit is not set
[    1.770000] mmc_host mmc0: Bus speed (slot 0) = 200000000Hz (slot
req 52000000Hz, actual 50000000HZ div = 2)
[    1.770000] mmc0: new high speed DDR MMC card at address 0001
[    1.785000] mmcblk0: mmc0:0001 SEM16G 14.6 GiB
[    1.855000] mmcblk0boot0: mmc0:0001 SEM16G partition 1 2.00 MiB
[    1.860000] mmcblk0boot1: mmc0:0001 SEM16G partition 2 2.00 MiB
[    1.950000] mmcblk0rpmb: mmc0:0001 SEM16G partition 3 128 KiB
[    1.955000] mmcblk0: error -84 transferring data, sector 0, nr 8,
cmd response 0x900, card status 0xb00
[    1.965000] mmcblk0: retrying using single block read
[    1.970000] mmcblk0: error -84 transferring data, sector 0, nr 8,
cmd response 0x900, card status 0x0
[    1.980000] end_request: I/O error, dev mmcblk0, sector 0
[    1.985000] mmcblk0: error -84 transferring data, sector 1, nr 7,
cmd response 0x900, card status 0x0
[    1.995000] end_request: I/O error, dev mmcblk0, sector 1
[    2.000000] mmcblk0: error -84 transferring data, sector 2, nr 6,
cmd response 0x900, card status 0x0
[    2.010000] end_request: I/O error, dev mmcblk0, sector 2
[    2.015000] mmcblk0: error -84 transferring data, sector 3, nr 5,
cmd response 0x900, card status 0x0
[    2.025000] end_request: I/O error, dev mmcblk0, sector 3
[    2.030000] mmcblk0: error -84 transferring data, sector 4, nr 4,
cmd response 0x900, card status 0x0
[    2.040000] end_request: I/O error, dev mmcblk0, sector 4
[    2.045000] dwmmc_exynos 12200000.dwmmc0: data FIFO error (status=00008008)
[    2.050000] mmcblk0: error -5 transferring data, sector 5, nr 3,
cmd response 0x900, card status 0x0
[    2.060000] end_request: I/O error, dev mmcblk0, sector 5
...
...
...
...

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists