| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAD=FV=UUg9Apb0o+zLdidDUmkLZt1phgo80bxug=o6JmANCPfw@mail.gmail.com>
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