from:"Igor Plyatov"

Re: Initialisation of SOC USB pads

2019-05-22 Thread Igor Plyatov


Hi!

Topic update...

USB pads operate. I see USB traffic on the bus by Logical analyzer.

This is definitely Linux kernel issue, because USB works fine at U-Boot, 
when I try to load kernel image and device tree from USB disk.


Additionally, USB works on same board with old Linux kernel 2.6.39.

Current Linux kernel (4.9.52), has issue with USB speed on AT91SAM9G20. 
I see different USB speeds in U-Boot and in Linux-4.9.52. U-Boot has 12 
MHz USB speed, while Linux-4.9.52 has 6 MHz USB speed.


I guess, what need to be changed to have correct USB speed?

I have attached resulting Device Tree source code, if it can be useful.

Best wishes.
--
Igor Plyatov


13.05.2019 18:39, Igor Plyatov пишет:

Dear developers,

can you please explain who must configure AT91SAM9G20 SOC pads to 
operate as USB Host port? Is it AT91Bootstrap, U-Boot bootloader, 
Linux kernel or this is not required at all?


I ask, because during connection of USB disk, my board complains

usb 1-1: device descriptor read/64, error -62
usb 1-1: device descriptor read/64, error -62
usb 1-1: device descriptor read/64, error -62
usb 1-1: device descriptor read/64, error -62
usb 1-1: device not accepting address 4, error -62
usb 1-1: device not accepting address 5, error -62
usb usb1-port1: unable to enumerate USB device


Looks like there is no connectivity between USB Host module of SOC and 
USB device. Or am I wrong?



My setup is:


* AT91SAM9G20 based custom board;
* Linux kernel 4.9.36, from LINUX4SAM project.
* USB disk connected to USB Host port 0 (HDPA, HDMA pins of SOC). 39 
Ohm series resistors and 15 Kohm pull-down resistors added at these 
lines. Connectivity between SOC and USB device confirmed by Ohmmeter.

* USB_VBUS voltage measured at USB connector = 4.96 VDC.

Best wishes
--
Igor Plyatov



device-tree.dts
Description: audio/vnd.dts

Re: Issues with i.MX SPI DMA transfers

2019-04-18 Thread Igor Plyatov


Dear Robin,


Hi Igor,
Did you meet any issue with my latest patch?


sorry, but unfortunately I have no time to test it.

I have switched to PIO mode and continue other development.

Maybe later I will find time to test DMA mode, but not sure when.

Thank you for support!

--

Igor Plyatov


-Original Message-
From: Robin Gong
Sent: April 9, 2019 11:26>
Hi Igor,
Please have a try with the attached patches, and revert 25aaa75df1e6,
ad0d92d7ba6a , dd4b487b32a3, df07101e1c4a before apply. Besides XCH, tx
thresh should be set to 0 , now no failure caught on ecspi5.

Re: Issues with i.MX SPI DMA transfers

2019-04-03 Thread Igor Plyatov


Dear Robin,

I have made additional tests on another exemplar of board with 
absolutely same hardware.


The spidev_test failed on eCSPI2 and eCSPI5 interfaces, but works 
successfully on eCSPI1 interface.


So, it looks, issue does not correspond to fixed interface number.

This is generic issue of i.MX6 SOC and hardly broken eCSPI interface 
number can change from SOC chip to chip.


Do you have any idea how to improve situation with eCSPI in DMA mode?

Best wishes.
--
Igor Plyatov

Re: Issues with i.MX SPI DMA transfers

2019-04-03 Thread Igor Plyatov


Dear Robin,


Please apply the attached patch which is based on linux-next commit 
05d08e2995cbe6efdb993482ee0d38a77040861a.

Please notice it has already contained two sdma patches revert - "ad0d92d7ba6a" and 
"25aaa75df1e6"


1) Yours source code is same as mine with exception of SDMA description 
for eCSPI in Device Tree.


I have changed Device Tree for i.MX6Q/DL as in attached patch and 
finally SPI interfaces operate more or less.


My patch revert back patches df07101e1c4a29e820df02f9989a066988b160e6 
and dd4b487b32a3571fdcc66062e661e3a3e360e35b. It is strange, because 
they are merged into mainline while ago. Maybe they are valid for some 
specific variant of i.MX SOC?


"More or less" means I have come to state described in first e-mail of 
this e-mail thread. Byte duplication (ERR009165) happens very often for 
eCSPI5 interface operating through DMA.


Test Conditions:
1.1. Interface under test is eCSPI1 or eCSPI5;
1.2. Four exemplars of "burn-neon" (CPU burn) executes in background to 
have 100% load for all 4 CPU cores (source code taken from 
https://raw.githubusercontent.com/ssvb/cpuburn-arm/dd5c5ba58d2b0b23cfab4a286f9d3f551f20/cpuburn-a8.S 
and https://hardwarebug.org/files/burn.S);
1.3. PC has running "ping -f embedded_device" to have network activity 
around 1 MiB/s Rx and Tx;
1.4. One exemplar of "spidev_test -D /dev/spidevX.0 -s FREQUENCY -b 8 -S 
512 -I 100 -l" executes at different frequencies;


Test Results for eCSPI1:
21 MHz    - success;
20 MHz    - success;
...
16 MHz    - success;
...
 8 MHz    - success;

Test Results for eCSPI5:
21 MHz    - failed;
20 MHz    - failed;
19 MHz    - failed;
...
12 MHz    - failed;
11 MHz    - failed;
10 MHz    - failed;
 9 MHz    - failed;
 8 MHz    - failed;
 7 MHz    - failed;
 6 MHz    - failed;
 5 MHz    - failed;
 4 MHz    - success.

Maybe it is worth to dump content of registers for eCSPI1 and eCSPI5 to 
compare them? I can do this if you will describe how to make it.


Maybe I'm wrong, but I suppose incorrect clock source for eCSPI5. Looks 
like it is worth to check correctness of driver "clk-imx6q.c" or 
something else responsible for eCSPI5 clock.



2) I want to improve description and replace magic numbers by constants 
in Device Tree for SDMA. I mean strings like "dmas = < 11 7 1>, 
< 12 7 2>;"?


So, finally Device Tree will have strings like

dmas = < SOME_DEF_A IMX_DMATYPE_.. DMA_PRIO_..>, < SOME_DEF_B 
IMX_DMATYPE_.. DMA_PRIO_..>;


I think, this will stop black magic manipulations for SDMA in Device 
Tree, by various developers.


Does first digit means "DMA request/event ID"? Where to find more info 
about this?


Does second digit means "enum sdma_peripheral_type"?

Does third digit means "enum imx_dma_prio"?

Where can I find description of difference between IMX_DMATYPE_CSPI (MCU 
domain CSPI) and IMX_DMATYPE_CSPI_SP (Shared CSPI)? Googling does not 
help too much.


Best wishes.
--
Igor Plyatov
>From 2aa277ff36998b805cec803b23d9c746a2a107b7 Mon Sep 17 00:00:00 2001
From: Igor Plyatov 
Date: Wed, 3 Apr 2019 14:51:17 +0300
Subject: [PATCH] Bugfix for incorrect eCSPI SDMA numbers.

* This revert back commits df07101e1c4a29e820df02f9989a066988b160e6 and
  dd4b487b32a3571fdcc66062e661e3a3e360e35b, because they lead to kernel
  errors like
  "spi_master spi4: I/O Error in DMA RX
   spidev spi4.1: SPI transfer failed: -110."
  Tested on i.MX6 Quad/DualLite SOC.

Signed-off-by: Igor Plyatov 
---
 arch/arm/boot/dts/imx6q.dtsi   | 2 +-
 arch/arm/boot/dts/imx6qdl.dtsi | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index d038f4117024..7175898f854e 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -172,7 +172,7 @@
 	clocks = < IMX6Q_CLK_ECSPI5>,
 		 < IMX6Q_CLK_ECSPI5>;
 	clock-names = "ipg", "per";
-	dmas = < 11 8 1>, < 12 8 2>;
+	dmas = < 11 7 1>, < 12 7 2>;
 	dma-names = "rx", "tx";
 	status = "disabled";
 };
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 2eb4c779298b..36c48a18e39a 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -338,7 +338,7 @@
 	clocks = < IMX6QDL_CLK_ECSPI1>,
 		 < IMX6QDL_CLK_ECSPI1>;
 	clock-names = "ipg", "per";
-	dmas = < 3 8 1>, < 4 8 2>;
+	dmas = < 3 7 1>, < 4 7 2>;
 	dma-names = "rx", "tx";
 	status = "disabled";
 };
@@ -352,7 +352,7 @@
 	clocks = < IMX6QDL_CLK_ECSPI2>,
 		 < IMX6QDL_CLK_ECSPI2>;
 	clock-names = "ipg", "per";
-	dmas = < 5 8 1>, < 6 8 2>;
+	dmas = < 5 7

Re: Issues with i.MX SPI DMA transfers

2019-04-02 Thread Igor Plyatov


Dear Robin,


now I have reverted patch ad0d92d7ba6a.
Patches 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch and
0002-spi-spi-imx-fix-ERR009165.patch are applied.


Kernel log show messages

[   29.202639] imx-sdma 20ec000.sdma: loaded firmware 3.3
[   29.238595] spi_imx 2008000.spi: probed
[   29.242802] spi_imx 200c000.spi: probed
[   29.245217] spi_imx 2018000.spi: probed

SPI DMA transfers still not work.

If I test 32 byte transfers, then they work fine. But 64 byte transfers
fails always and I see error messages

root@cr7:~# spidev_test -D /dev/spidev4.1 -s 120 -b 8 -S 64 -I 1 -l
spi mode: 0x20
bits per word: 8
max speed: 120 Hz (1200 KHz)
[  423.686736] spi_master spi4: I/O Error in DMA RX
[  423.691392] spidev spi4.1: SPI transfer failed: -110
[  423.696382] spi_master spi4: failed to transfer one message from queue
can't send spi message: Connection timed out
Aborted (core dumped)

I suppose, transfers shorter then 64 bytes made with help of PIO.

Robin, is there any chance for you to find some time and look at this
issue again?

I have quick test with spidev_test loopback, but didn't meet your error,
Is your code the almost latest code in linux-next as mine?

root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma
  48: 37   GPC   2 Level sdma
  -lt@imx6qpdlsolox:~# ./spidev_test -D /dev/spidev0.0 -s 120 -b 8 -S 64 -I 
1 -l
spi mode: 0x20
bits per word: 8
max speed: 120 Hz (1200 KHz)
root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma
  48: 43   GPC   2 Level sdma
./spidev_test -D /dev/spidev0.0 -s 120 -b 8 -S 512 -I 1 -l
spi mode: 0x20
bits per word: 8
max speed: 120 Hz (1200 KHz)
total: tx 0.5KB, rx 0.5KB



My previous test results based on kernel from "main" branch of 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git.


Now I have tested kernel from "main" branch of 
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git.


Its latest commit is 05d08e2995cbe6efdb993482ee0d38a77040861a.

Additionally, I have reverted patch ad0d92d7ba6a and apply yours patches 
0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch and 
0002-spi-spi-imx-fix-ERR009165.patch.


Difference between 05d08e2995cbe6efdb993482ee0d38a77040861a and current 
state of drivers attached as spi-and-sdma-drivers.diff.


SPI driver still not work. It has same result as from my previous email.

Looks as you use either different GIT branch of kernel or you have 
forget to say me about some patch.


Best wishes.

--

Igor Plyatov

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 5f3c1378b90e..908507fa9526 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -377,7 +377,6 @@ struct sdma_channel {
 	unsigned long			watermark_level;
 	u32shp_addr, per_addr;
 	enum dma_status			status;
-	boolcontext_loaded;
 	struct imx_dma_data		data;
 	struct work_struct		terminate_worker;
 };
@@ -913,6 +912,9 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
 		emi_2_per = sdma->script_addrs->mcu_2_ata_addr;
 		break;
 	case IMX_DMATYPE_CSPI:
+		per_2_emi = sdma->script_addrs->app_2_mcu_addr;
+		emi_2_per = sdma->script_addrs->mcu_2_ecspi_addr;
+		break;
 	case IMX_DMATYPE_EXT:
 	case IMX_DMATYPE_SSI:
 	case IMX_DMATYPE_SAI:
@@ -976,9 +978,6 @@ static int sdma_load_context(struct sdma_channel *sdmac)
 	int ret;
 	unsigned long flags;
 
-	if (sdmac->context_loaded)
-		return 0;
-
 	if (sdmac->direction == DMA_DEV_TO_MEM)
 		load_address = sdmac->pc_from_device;
 	else if (sdmac->direction == DMA_DEV_TO_DEV)
@@ -1021,8 +1020,6 @@ static int sdma_load_context(struct sdma_channel *sdmac)
 
 	spin_unlock_irqrestore(>channel_0_lock, flags);
 
-	sdmac->context_loaded = true;
-
 	return ret;
 }
 
@@ -1062,7 +1059,6 @@ static void sdma_channel_terminate_work(struct work_struct *work)
 	sdmac->desc = NULL;
 	spin_unlock_irqrestore(>vc.lock, flags);
 	vchan_dma_desc_free_list(>vc, );
-	sdmac->context_loaded = false;
 }
 
 static int sdma_disable_channel_async(struct dma_chan *chan)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 09c9a1edb2c6..27578158d922 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -585,8 +585,9 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
 	ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, );
 	spi_imx->spi_bus_clk = clk;
 
+	/* ERR009165: work in XHC mode as PIO */
 	if (spi_imx->usedma)
-		ctrl |= MX51_ECSPI_CTRL_SMC;
+		ctrl &= ~MX51_ECSPI_CTRL_SMC;
 
 	writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
 
@@ -1265,10 +1266,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 {
 	int ret;
 
-	/* use pio mode for i.mx6dl chip TKT238285 */
-	if (of_machine_is_compatible("fsl,imx6dl"))
-		return 0;
-
 	spi_imx->wml = spi_imx->devtype_data->fifo_size / 2;
 
 	/* Prepare for TX DMA: */
diff --git a/include/linux/pla

Re: Issues with i.MX SPI DMA transfers

2019-04-02 Thread Igor Plyatov


Dear Robin Gong,


Sorry...below another sdma patch(ad0d92d7ba6a) need to be reverted, 
because spi driver may dynamically change burst length.



now I have reverted patch ad0d92d7ba6a.

Patches 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch and 
0002-spi-spi-imx-fix-ERR009165.patch are applied.



Kernel log show messages

[   29.202639] imx-sdma 20ec000.sdma: loaded firmware 3.3
[   29.238595] spi_imx 2008000.spi: probed
[   29.242802] spi_imx 200c000.spi: probed
[   29.245217] spi_imx 2018000.spi: probed

SPI DMA transfers still not work.

If I test 32 byte transfers, then they work fine. But 64 byte transfers 
fails always and I see error messages


root@cr7:~# spidev_test -D /dev/spidev4.1 -s 120 -b 8 -S 64 -I 1 -l
spi mode: 0x20
bits per word: 8
max speed: 120 Hz (1200 KHz)
[  423.686736] spi_master spi4: I/O Error in DMA RX
[  423.691392] spidev spi4.1: SPI transfer failed: -110
[  423.696382] spi_master spi4: failed to transfer one message from queue
can't send spi message: Connection timed out
Aborted (core dumped)

I suppose, transfers shorter then 64 bytes made with help of PIO.

Robin, is there any chance for you to find some time and look at this 
issue again?


Best wishes.
--
Igor Plyatov

Re: Issues with i.MX SPI DMA transfers

2019-03-29 Thread Igor Plyatov


Dear Uwe,


On Thu, Mar 28, 2019 at 10:04:21AM +0300, Igor Plyatov wrote:

Dear Uwe,



Hello Igor,

On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote:

please, help to resolve two issues with SPI DMA transfers at i.MX6Q
platform.

First issue is
   [ 4465.008003] spi_master spi0: I/O Error in DMA RX

Second issue is duplication for one of received bytes.

Probably, these issues related to each one.

This is probably the same problem I hit some time ago. Check ERR009165
in the errata. You either need to disable DMA or need a fixed
sdma-Script.

disabling of DMA is not an option, because high throughput required for SPI
bus to communicate with DSPs.

Is this a theoretical reasoning, or is that backed by testing? People
here on the list already said things like:

The eCSPI appears to insert a 4 bit pause after each word in DMA
mode, not done in PIO mode, which can make DMA transfers 50%
slower than PIO.

You might want to read the thread
https://marc.info/?l=linux-spi=155191201208766=2
.


SPI throughput depends from transfer mode (PIO or DMA), OS load and OS 
version.


For example, Linux-4.9.87 has quite bad results for SPI throughput when 
PIO transfer used and OS highly loaded by other processes. Throughput 
varies from 2700 kbps to 0.8 kbps and this is totally unacceptable for 
my application, where streaming of DSP data required.


Linux-5.1.0-rc2 has much better performance of SPI with PIO transfers. 
Throughput varies within 10%.



I'm aware of ERR009165, but as I write some minutes earlier to list, spi0
(alias for ecspi1) and spi1 (alias for ecspi2) work flawless, while spi4
(alias for ecspi5) fails very fast.

As the issue is a timing race, it might depend on things like length of
the SPI lines, load on the data lines and other electrical properties.
So you might just be happy that spi0 and spi1 don't show the issue for
you. Or you didn't apply the "right" work load yet.


This e-mail thread discuss operation of SPI only in loopback mode. So, 
real lines of SPI does not used. SPI module of SOC has connected MOSI 
and MISO lines internally, while MISO disconnected from SOC pad. So, 
electrical characteristics of SPI lines are not important at all.


Best wishes.

--

Igor Plyatov

Re: Issues with i.MX SPI DMA transfers

2019-03-28 Thread Igor Plyatov


Dear Robin,

I have applied patches 
0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch, 
0002-spi-spi-imx-fix-ERR009165.patch and made testing.


Results are following:

root@cr7:~# spidev_test -D /dev/spidev0.0 -s 1200 -b 8 -S 512 -I 
100 -l

spi mode: 0x20
bits per word: 8
max speed: 1200 Hz (12000 KHz)
[  133.987798] spi_imx 2008000.spi: I/O Error in DMA TX
[  133.992810] spidev spi0.0: SPI transfer failed: -110
[  133.997860] spi_master spi0: failed to transfer one message from queue
can't send spi message: Connection timed out
Aborted (core dumped)

root@cr7:~# spidev_test -D /dev/spidev1.0 -s 1200 -b 8 -S 512 -I 
100 -l

spi mode: 0x20
bits per word: 8
max speed: 1200 Hz (12000 KHz)
[  483.530815] spi_imx 200c000.spi: I/O Error in DMA TX
[  483.535825] spidev spi1.0: SPI transfer failed: -110
[  483.540873] spi_master spi1: failed to transfer one message from queue
can't send spi message: Connection timed out
Aborted (core dumped)

root@cr7:~# spidev_test -D /dev/spidev4.0 -s 1200 -b 8 -S 512 -I 
100 -l

spi mode: 0x20
bits per word: 8
max speed: 1200 Hz (12000 KHz)
[   94.228774] spi_imx 2018000.spi: I/O Error in DMA TX
[   94.233788] spidev spi4.0: SPI transfer failed: -110
[   94.238837] spi_master spi4: failed to transfer one message from queue
can't send spi message: Connection timed out
Aborted (core dumped)

Best wishes.

--

Igor Plyatov



Hi Igor,
Please have a try with the attached patch, assume you have already used 
the sdma firmware
 From 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma/sdma-imx6q.bin

-Original Message-
From: Igor Plyatov 
Sent: 2019年3月28日 15:04
To: Uwe Kleine-König 
Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-...@vger.kernel.org; dl-linux-imx ; Fabio Estevam
; Pengutronix Kernel Team ;
Sascha Hauer ; Shawn Guo
; Mark Brown ;
dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams
; Andy Duan ; Han Xu
; Robin Gong ; Clark Wang

Subject: Re: Issues with i.MX SPI DMA transfers

Dear Uwe,



Hello Igor,

On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote:

please, help to resolve two issues with SPI DMA transfers at i.MX6Q
platform.

First issue is
   [ 4465.008003] spi_master spi0: I/O Error in DMA RX

Second issue is duplication for one of received bytes.

Probably, these issues related to each one.

This is probably the same problem I hit some time ago. Check ERR009165
in the errata. You either need to disable DMA or need a fixed
sdma-Script.

disabling of DMA is not an option, because high throughput required for SPI bus
to communicate with DSPs.

I'm aware of ERR009165, but as I write some minutes earlier to list,
spi0 (alias for ecspi1) and spi1 (alias for ecspi2) work flawless, while
spi4 (alias for ecspi5) fails very fast.

Does same SDMA script used for all SPI interfaces or scripts are different?

Best wishes.

--

Igor Plyatov

Re: Issues with i.MX SPI DMA transfers

2019-03-28 Thread Igor Plyatov


Dear Uwe,



Hello Igor,

On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote:

please, help to resolve two issues with SPI DMA transfers at i.MX6Q
platform.

First issue is
  [ 4465.008003] spi_master spi0: I/O Error in DMA RX

Second issue is duplication for one of received bytes.

Probably, these issues related to each one.

This is probably the same problem I hit some time ago. Check ERR009165
in the errata. You either need to disable DMA or need a fixed
sdma-Script.


disabling of DMA is not an option, because high throughput required for 
SPI bus to communicate with DSPs.


I'm aware of ERR009165, but as I write some minutes earlier to list, 
spi0 (alias for ecspi1) and spi1 (alias for ecspi2) work flawless, while 
spi4 (alias for ecspi5) fails very fast.


Does same SDMA script used for all SPI interfaces or scripts are different?

Best wishes.

--

Igor Plyatov

Re: Issues with i.MX SPI DMA transfers

2019-03-28 Thread Igor Plyatov


Dear developers,

I have update about these issues.

12 hours testing show very fast (some seconds) appearance of byte 
duplication at interface spi4 (alias for ecspi5), while interfaces spi0 
(alias for ecspi1) and spi1 (alias for ecspi2) work flawless (at least 
without any other OS load).


Looks like, ecspi5 has some different configuration in SPI or SDMA 
drivers or bug in SDMA script.


Any ideas?

Best wishes.

--

Igor Plyatov

Issues with i.MX SPI DMA transfers

2019-03-27 Thread Igor Plyatov

8 FB F1 38 65 BB AA DE 6E 5F AE CF 89 2B 36 D2 D5 C2 5A 80 84 46 
1F A3 BF 54 43 D3 9D 38 F3 55  |...8e...n_...+6...Z..F...TC..8.U|
 RX | 34 E4 8D 99 9F 38 77 0E 97 25 DD 20 50 13 F2 25 D5 4C A5 5A 93 C5 
FD 52 19 40 25 B6 79 19 0B AD  |48w..%. P..%.L.Z...R.@%.y...|
 RX | FD 98 46 9D D0 BD AB 67 E3 88 88 33 9C 7A 59 71 C7 FE CB 5A C3 C9 
AC DC 09 D1 92 82 EA 9D 2F E8  |..Fg...3.zYq...Z../.|
 RX | 36 75 85 06 33 30 6E 16 B8 F6 49 54 70 A2 C6 37 A1 91 91 64 5A 3D 
41 64 0F D3 E6 F9 71 16 E1 A7  |6u..30n...ITp..7...dZ=Adq...|
 RX | 8B 66 AD BE 96 1B D4 4F 11 1E A3 82 C0 69 B9 61 FB 4B C6 55 88 07 
B9 97 DA A0 91 4B B6 72 F2 41  |.f.O.i.a.K.U...K.r.A|
 RX | D9 A0 00 6F BB D4 BE CD F2 62 4F B3 CB 08 14 C6 53 DA 1C DC E1 D5 
73 BC 75 04 07 2B 77 FA 6D 50  |...o.bO.S.s.u..+w.mP|
 RX | 9A 6D BF 55 41 7E 22 34 E0 71 E7 AB 7A FB 72 CD D6 8E A9 B7 63 1D 
73 D9 21 7B 04 98 75 71 E8 0F  |.m.UA~"4.q..z.r.c.s.!{..uq..|
 RX | DE A8 64 20 26 87 54 06 F8 3B B1 72 36 23 40 0C B1 E9 C4 15 06 37 
EE 28 B2 F2 C0 27 64 A9 36 42  |..d &.T..;.r6#@..7.(...'d.6B|
 RX | 51 9B 62 77 22 B6 7D 1A F1 2E 8D 28 52 CD 34 03 B6 F8 18 BD 30 06 
E5 E2 F9 A5 0A 5D 4E 40 9F 9F  |Q.bw".}(R.4.0..]N@..|
 RX | DB 02 16 FD B8 93 18 AA C2 A5 D2 14 72 06 17 28 FF 30 E5 2F 36 CA 
11 2F 70 1B 8C BE 5C 2C 5E 37  |r..(.0./6../p...\,^7|
 RX | 2E 74 35 E6 08 4D 90 CA F2 62 DE 64 69 F5 8C 68 25 72 97 5C 3C A8 
8B AC C4 18 6B 20 44 C9 57 72  |.t5..M...b.di..h%r.\<.k D.Wr|
 RX | 3D 8C 58 45 D9 E9 0F CB 4B ED 2F B4 E3 BC 1C 08 2E B3 64 6A 5C F0 
17 20 08 82 40 4C 4B 97 BE 88  |=.XEK./...dj\.. ..@LK...|
 RX | 24 16 CE FD FF DD C9 4B CB F8 FF AE B4 1C B6 E2 CF 1B 4D 2B 0B 64 
4B 13 E6 8B 5F 31 23 1D B9 47  |$..K..M+.dK..._1#..G|


Best wishes.
--
Igor Plyatov

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Igor Plyatov


Dear Karel,



Would be possible to somehow detect what is the right default setting for
--delay? I mean for example detect architecture / clock HW, etc.

I have no problem with --delay, but it's tuning for advanced users and
HW specific stuff. It would be nice to have something more portable.

 Karel



As I understood, issue exists only at x86 platform, where 
MC146818-compatible RTC used.


But even if you will correctly detect platform, there is no guaranty to 
get exactly MC146818 RTC. RTC can be other type. It even can be not 
single in the system.


What is more or less usable is "/sys/class/rtc/rtcX/name" file, which 
contains driver name.
For x86 and MC146818-compatible RTC its name is "rtc_cmos". And it can 
be used to distinguish RTC type by hwclock utility.


Best wishes.
--
Igor Plyatov

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Igor Plyatov


Dear Karel,



Would be possible to somehow detect what is the right default setting for
--delay? I mean for example detect architecture / clock HW, etc.

I have no problem with --delay, but it's tuning for advanced users and
HW specific stuff. It would be nice to have something more portable.

 Karel



As I understood, issue exists only at x86 platform, where 
MC146818-compatible RTC used.


But even if you will correctly detect platform, there is no guaranty to 
get exactly MC146818 RTC. RTC can be other type. It even can be not 
single in the system.


What is more or less usable is "/sys/class/rtc/rtcX/name" file, which 
contains driver name.
For x86 and MC146818-compatible RTC its name is "rtc_cmos". And it can 
be used to distinguish RTC type by hwclock utility.


Best wishes.
--
Igor Plyatov

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Igor Plyatov

Dear Rasmus,

thank you very much for explanation!

I have set "RTC_SET_DELAY_SECS = 0.0" in hwclock.c and got acceptable
result.

It wonder why such critical function does not implemented on kernel
level in RTC driver?

It is very strange to rely on specific HW in user space SW.

Best wishes.
--
Igor Plyatov

On 2018-02-19 07:40, Igor Plyatov wrote:

Hi!

I have board based on AT91SAM9G20 (ARM926EJ-S CPU), Linux-4.9.36 kernel
and RTC chip DS1340 (rtc-ds1307.c driver).

RTC chip connected by means of I2C-bus, without HW IRQ line connected.

Kernel configured to not use embedded functions for time getting at
startup and saving at shutdown:
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_SYSTOHC is not set
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_DS1307_CENTURY=y

The hwclock utility is from util-linux-2.29.1.

The OS does not have external time synchronization sources like NTP, PTP
or else.

Generally I need to achieve error within +-20 ms when RTC's time copied
into OS or back from OS into RTC.

I have made measurements during startup and shutdown of OS and have
found 500 ms delay introduced into RTC's time, when "hwclock --utc
--systohc" executed.

Logical analyzer show to me I2C-bus transactions and PPS signal
generated by Linux. And I see 500 ms delay is between of rising edge of
PPS signal (start of OS second) and moment when time saved into RTC.

Please explain, why this happens? Is this due to absence of IRQ line for
RTC or due to a bug in the hwclock, or kernel bug or I have missed
something else?

cc += util-li...@vger.kernel.org

It's because util-linux's hwclock still assumes the world is x86. See
this comment in the util-linux source code:

/*
* The Hardware Clock can only be set to any integer time plus one
* half second. The integer time is required because there is no
* interface to set or get a fractional second. The additional half
* second is because the Hardware Clock updates to the following
* second precisely 500 ms (not 1 second!) after you release the
* divider reset (after setting the new time) - see description of
* DV2, DV1, DV0 in Register A in the MC146818A data sheet (and note

So if hwclock is asked to --systohc at time 01:02:03.x, it waits until
the time is 01:02:03.5 to set the rtc to 01:02:03, or if that has
already passed, waits until 01:02:04.5 and sets it to 01:02:04.

On our ARM BSP we patch util-linux to have the "implicit fractional
part" configurable, and trying to upstream something like that has been
on my todo-list for quite a while. See

https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch

for the patch we currently use (on top of that, we change the 0.5
initializer to 0.0 to avoid having to always pass the --delay argument).
Incidentally, it seems we're on the same util-linux version, so you
should be able to try out that patch and see if it works for you.

Rasmus

Re: 500 ms delay in time saved into RTC

2018-02-19 Thread Igor Plyatov

Dear Rasmus,

thank you very much for explanation!

I have set "RTC_SET_DELAY_SECS = 0.0" in hwclock.c and got acceptable
result.

It wonder why such critical function does not implemented on kernel
level in RTC driver?

It is very strange to rely on specific HW in user space SW.

Best wishes.
--
Igor Plyatov

On 2018-02-19 07:40, Igor Plyatov wrote:

Hi!

I have board based on AT91SAM9G20 (ARM926EJ-S CPU), Linux-4.9.36 kernel
and RTC chip DS1340 (rtc-ds1307.c driver).

RTC chip connected by means of I2C-bus, without HW IRQ line connected.

The hwclock utility is from util-linux-2.29.1.

The OS does not have external time synchronization sources like NTP, PTP
or else.

Generally I need to achieve error within +-20 ms when RTC's time copied
into OS or back from OS into RTC.

I have made measurements during startup and shutdown of OS and have
found 500 ms delay introduced into RTC's time, when "hwclock --utc
--systohc" executed.

Please explain, why this happens? Is this due to absence of IRQ line for
RTC or due to a bug in the hwclock, or kernel bug or I have missed
something else?

cc += util-li...@vger.kernel.org

It's because util-linux's hwclock still assumes the world is x86. See
this comment in the util-linux source code:

On our ARM BSP we patch util-linux to have the "implicit fractional
part" configurable, and trying to upstream something like that has been
on my todo-list for quite a while. See

https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch

Rasmus

500 ms delay in time saved into RTC

2018-02-18 Thread Igor Plyatov


Hi!

I have board based on AT91SAM9G20 (ARM926EJ-S CPU), Linux-4.9.36 kernel 
and RTC chip DS1340 (rtc-ds1307.c driver).


RTC chip connected by means of I2C-bus, without HW IRQ line connected.

Kernel configured to not use embedded functions for time getting at 
startup and saving at shutdown:

CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_SYSTOHC is not set
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_DS1307_CENTURY=y

The hwclock utility is from util-linux-2.29.1.

The OS does not have external time synchronization sources like NTP, PTP 
or else.


Generally I need to achieve error within +-20 ms when RTC's time copied 
into OS or back from OS into RTC.


I have made measurements during startup and shutdown of OS and have 
found 500 ms delay introduced into RTC's time, when "hwclock --utc 
--systohc" executed.


Logical analyzer show to me I2C-bus transactions and PPS signal 
generated by Linux. And I see 500 ms delay is between of rising edge of 
PPS signal (start of OS second) and moment when time saved into RTC.


Please explain, why this happens? Is this due to absence of IRQ line for 
RTC or due to a bug in the hwclock, or kernel bug or I have missed 
something else?


Best wishes.
--
Igor Plyatov

500 ms delay in time saved into RTC

2018-02-18 Thread Igor Plyatov


Hi!

I have board based on AT91SAM9G20 (ARM926EJ-S CPU), Linux-4.9.36 kernel 
and RTC chip DS1340 (rtc-ds1307.c driver).


RTC chip connected by means of I2C-bus, without HW IRQ line connected.

Kernel configured to not use embedded functions for time getting at 
startup and saving at shutdown:

CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_SYSTOHC is not set
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_DS1307_CENTURY=y

The hwclock utility is from util-linux-2.29.1.

The OS does not have external time synchronization sources like NTP, PTP 
or else.


Generally I need to achieve error within +-20 ms when RTC's time copied 
into OS or back from OS into RTC.


I have made measurements during startup and shutdown of OS and have 
found 500 ms delay introduced into RTC's time, when "hwclock --utc 
--systohc" executed.


Logical analyzer show to me I2C-bus transactions and PPS signal 
generated by Linux. And I see 500 ms delay is between of rising edge of 
PPS signal (start of OS second) and moment when time saved into RTC.


Please explain, why this happens? Is this due to absence of IRQ line for 
RTC or due to a bug in the hwclock, or kernel bug or I have missed 
something else?


Best wishes.
--
Igor Plyatov

Re: spi-atmel.c: regression

2017-10-05 Thread Igor Plyatov


Hello!


Hello!

please help to manage issue with data corruption by PDC of SPI.


I have compared operation of Linux-2.6.39 and linux4sam kernel 4.9.36+ 
on the AT91SAM9G20 (Stamp9G20 SOM from Taskit.de) and found regression 
in the spi-atmel.c.


New spi-atmel.c driver works very bad with SPI speeds above 6 MHz. I 
see corruption in data received by Linux and SPI overruns when OS has 
big CPI and IO load.


Old kernel works fine at 22 MHz with the same device driver and hardware.

Can somebody comment and/or help on how to resolve this issue?

Best wishes.
--
Igor Plyatov


For those, who has same interest or encountered the same issue as I had...

Notes:
A) My "gs_mgms_dsp" linux driver is the same for linux-2.6.39 and 
linux-4.9.36
   and communicates with DSP through SPI-bus, where data packets are 32 
byte

   long and last byte is CRC8 to check data integrity.
B) CPU is AT91SAM9G20.

I have encoutered SPI data corruption during receiving of data from DSP by
linux-4.9.36 if SPI-bus has big traffic in parallel with big traffic at MMC
interface.

Old linux-2.6.39 does not suffer from such issue, because atmel-mci.c 
driver has
PIO access to MMC interface. While new kernel has changed the 
atmel-mci.c driver

for use of PDC (Peripheral DMA Controller) for access to MMC interface.

Both kernels have Atmel SPI driver where PDC used for SPI data transfers.

SPI data corruption looks like duplication of one of received bytes.
Such bytes surrounded by "**" at log below.

gs_mgms_dsp spi32766.0: CRC error.
gs_mgms_dsp spi32766.0: <- 35 36 37 38 39 3A 3B 3C 3D  3E 3F  40 41 42 43 44
gs_mgms_dsp spi32766.0: <- 45 46 47 48 49 4A 4B 4C 4D *4F 4F* 50 51 52 53 A4
gs_mgms_dsp spi32766.0: -> EIO=0x05
gs_mgms_dsp spi32766.0: CRC error.
gs_mgms_dsp spi32766.0: <- 0F C2 C3 C4 C5 C6 C7 C8 C9  CA CB  CC CD CE CF D0
gs_mgms_dsp spi32766.0: <- D1 D2 D3 D4 D5 D6 D7 D8 D9 *DB DB* DC DD DE DF 02
gs_mgms_dsp spi32766.0: -> EIO=0x05
gs_mgms_dsp spi32766.0: CRC error.
gs_mgms_dsp spi32766.0: <-  03 5A  5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68
gs_mgms_dsp spi32766.0: <- *6A 6A* 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 25
gs_mgms_dsp spi32766.0: -> EIO=0x05
gs_mgms_dsp spi32766.0: CRC error.
gs_mgms_dsp spi32766.0: <- 15 76 77 78 79 7A  7B 7C  7D 7E 7F 80 81 82 83 84
gs_mgms_dsp spi32766.0: <- 85 86 87 88 89 8A *8C 8C* 8D 8E 8F 90 91 92 93 00
gs_mgms_dsp spi32766.0: -> EIO=0x05
gs_mgms_dsp spi32766.0: CRC error.
gs_mgms_dsp spi32766.0: <- 2A EC ED EE EF F0 F1  F2 F3  F4 F5 F6 F7 F8 F9 FA
gs_mgms_dsp spi32766.0: <- FB FC FD FE FF 00 01 *03 03* 04 05 06 07 08 09 0A
gs_mgms_dsp spi32766.0: -> EIO=0x05

This looks like silent SPI overruns not detected by AT91SAM9G20 HW.

At the end, after some seconds or milliseconds of communication, HW SPI 
overrun

flag detected by the spi-atmel.c driver:
"atmel_spi fffcc000.spi: overrun (0/0 remaining)".

Strictly speaking this is not a regression of spi-atmel.c, but unfortunate
combination with atmel-mmc.c, where PDC used too and I suppose a HW bug in
AT91SAM9G20 CPU.

Please help to answer on questions:
  1) How to modify atmel-mci.c driver to have option for PIO access to MMC
 interface?
  2) Why SPI overrun flag does not asserted each time? I have not found 
such HW bug

 in the Errata for AT91SAM9G20 CPU.

Best wishes.
--
Igor Plyatov

Re: spi-atmel.c: regression

2017-10-05 Thread Igor Plyatov


Hello!


Hello!

please help to manage issue with data corruption by PDC of SPI.


I have compared operation of Linux-2.6.39 and linux4sam kernel 4.9.36+ 
on the AT91SAM9G20 (Stamp9G20 SOM from Taskit.de) and found regression 
in the spi-atmel.c.


New spi-atmel.c driver works very bad with SPI speeds above 6 MHz. I 
see corruption in data received by Linux and SPI overruns when OS has 
big CPI and IO load.


Old kernel works fine at 22 MHz with the same device driver and hardware.

Can somebody comment and/or help on how to resolve this issue?

Best wishes.
--
Igor Plyatov


For those, who has same interest or encountered the same issue as I had...

Notes:
A) My "gs_mgms_dsp" linux driver is the same for linux-2.6.39 and 
linux-4.9.36
   and communicates with DSP through SPI-bus, where data packets are 32 
byte

   long and last byte is CRC8 to check data integrity.
B) CPU is AT91SAM9G20.

I have encoutered SPI data corruption during receiving of data from DSP by
linux-4.9.36 if SPI-bus has big traffic in parallel with big traffic at MMC
interface.

Old linux-2.6.39 does not suffer from such issue, because atmel-mci.c 
driver has
PIO access to MMC interface. While new kernel has changed the 
atmel-mci.c driver

for use of PDC (Peripheral DMA Controller) for access to MMC interface.

Both kernels have Atmel SPI driver where PDC used for SPI data transfers.

SPI data corruption looks like duplication of one of received bytes.
Such bytes surrounded by "**" at log below.

gs_mgms_dsp spi32766.0: CRC error.
gs_mgms_dsp spi32766.0: <- 35 36 37 38 39 3A 3B 3C 3D  3E 3F  40 41 42 43 44
gs_mgms_dsp spi32766.0: <- 45 46 47 48 49 4A 4B 4C 4D *4F 4F* 50 51 52 53 A4
gs_mgms_dsp spi32766.0: -> EIO=0x05
gs_mgms_dsp spi32766.0: CRC error.
gs_mgms_dsp spi32766.0: <- 0F C2 C3 C4 C5 C6 C7 C8 C9  CA CB  CC CD CE CF D0
gs_mgms_dsp spi32766.0: <- D1 D2 D3 D4 D5 D6 D7 D8 D9 *DB DB* DC DD DE DF 02
gs_mgms_dsp spi32766.0: -> EIO=0x05
gs_mgms_dsp spi32766.0: CRC error.
gs_mgms_dsp spi32766.0: <-  03 5A  5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68
gs_mgms_dsp spi32766.0: <- *6A 6A* 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 25
gs_mgms_dsp spi32766.0: -> EIO=0x05
gs_mgms_dsp spi32766.0: CRC error.
gs_mgms_dsp spi32766.0: <- 15 76 77 78 79 7A  7B 7C  7D 7E 7F 80 81 82 83 84
gs_mgms_dsp spi32766.0: <- 85 86 87 88 89 8A *8C 8C* 8D 8E 8F 90 91 92 93 00
gs_mgms_dsp spi32766.0: -> EIO=0x05
gs_mgms_dsp spi32766.0: CRC error.
gs_mgms_dsp spi32766.0: <- 2A EC ED EE EF F0 F1  F2 F3  F4 F5 F6 F7 F8 F9 FA
gs_mgms_dsp spi32766.0: <- FB FC FD FE FF 00 01 *03 03* 04 05 06 07 08 09 0A
gs_mgms_dsp spi32766.0: -> EIO=0x05

This looks like silent SPI overruns not detected by AT91SAM9G20 HW.

At the end, after some seconds or milliseconds of communication, HW SPI 
overrun

flag detected by the spi-atmel.c driver:
"atmel_spi fffcc000.spi: overrun (0/0 remaining)".

Strictly speaking this is not a regression of spi-atmel.c, but unfortunate
combination with atmel-mmc.c, where PDC used too and I suppose a HW bug in
AT91SAM9G20 CPU.

Please help to answer on questions:
  1) How to modify atmel-mci.c driver to have option for PIO access to MMC
 interface?
  2) Why SPI overrun flag does not asserted each time? I have not found 
such HW bug

 in the Errata for AT91SAM9G20 CPU.

Best wishes.
--
Igor Plyatov

spi-atmel.c: regression

2017-10-02 Thread Igor Plyatov


Hello!

please help to manage issue with data corruption by PDC of SPI.


I have compared operation of Linux-2.6.39 and linux4sam kernel 4.9.36+ 
on the AT91SAM9G20 (Stamp9G20 SOM from Taskit.de) and found regression 
in the spi-atmel.c.


New spi-atmel.c driver works very bad with SPI speeds above 6 MHz. I see 
corruption in data received by Linux and SPI overruns when OS has big 
CPI and IO load.


Old kernel works fine at 22 MHz with the same device driver and hardware.

Can somebody comment and/or help on how to resolve this issue?

Best wishes.
--
Igor Plyatov

spi-atmel.c: regression

2017-10-02 Thread Igor Plyatov


Hello!

please help to manage issue with data corruption by PDC of SPI.


I have compared operation of Linux-2.6.39 and linux4sam kernel 4.9.36+ 
on the AT91SAM9G20 (Stamp9G20 SOM from Taskit.de) and found regression 
in the spi-atmel.c.


New spi-atmel.c driver works very bad with SPI speeds above 6 MHz. I see 
corruption in data received by Linux and SPI overruns when OS has big 
CPI and IO load.


Old kernel works fine at 22 MHz with the same device driver and hardware.

Can somebody comment and/or help on how to resolve this issue?

Best wishes.
--
Igor Plyatov

spi-atmel.c: problem with PDC on AT91SAM9G20

2017-09-25 Thread Igor Plyatov


Dear Nicolas, Mark, Cyrille and other developers,

please help to manage issue with data corruption by PDC of SPI.


Versions


I use linux4sam kernel 4.9.36+ 
(7e82b52ca2286e9823d2467b64bfe78980b464b7) on the custom AT91SAM9G20 
board (Stamp9G20 SOM from Taskit.de).


The drivers/spi/spi-atmel.c updated by patches from upstream kernel, 
where last commit is 7094576ccdc3acfe1e06a1e2ab547add375baf7f

Author: Cyrille Pitchen <cyrille.pitc...@microchip.com>
Date:   Fri Jun 23 17:39:16 2017 +0200

spi: atmel: fix corrupted data issue on SAM9 family SoCs


Issue
-

Data corruption happens during receiving of SPI data by kernel. It 
happens quite often (once per minute or so) if OS has some light load, 
like periodical writes to SD card in parallel with communication to SPI 
device (DSP).


Corruption of received SPI data by AT91SAM9G20 CPU confirmed with help 
of logical analyzer.

Analyzer is connected to SPI bus right near CPU.
DSP print SPI data to own serial console for debugging purposes.
Logical analyzer show exactly same data which was printed by DSP.
Kernel driver for DSP print SPI data, where some bytes corrupted, into 
kernel logs for debugging purposes.


The DSP and its linux driver has custom protocol to control correctness 
of communication between Linux host and DSP.

Protocol is quite simple:
* Half duplex.
* Main data transceived as 32 bytes long packets with CRC8 as byte #32.
* Each 32 bytes packet ACKed by one byte (error code) sent back in responce.

This protocol allow to control data integrity during communication 
between Linux host and DSP.



spi-atmel.c reports
---

atmel_spi fffc8000.spi: Atmel SPI Controller version 0x199 at 0xfffc8000 
(irq 32)
atmel_spi fffcc000.spi: Atmel SPI Controller version 0x199 at 0xfffcc000 
(irq 33)


And works with use of SPI PDC.


DSP & Logical Analyzer Data
---

To Linux Host:   01 01 43 F3 00 01 43 E8 00 01 43 EB 00 01 43 E1
To Linux Host:   00 01 43 F4 00 01 43 E1 00 01 43 F0 00 01 43 22
From Linux Host: CRC error.


Kernel Data
---

From DSP:01 01 43 F3 00 01 43 E8 00 01 43 EB 00 01 43 E1
From DSP:00 01 43 F4 00 01 43 E1 00 01 F0 F0 00 01 43 22
   **
To DSP: CRC error.

** Corrupted byte.


The SPI PIO mode works without data corruption, but this is not an 
option, because communication can have critically big lags if OS has 
some load. These lags are not acceptable for our high speed DSP.


Best wishes.
--
Igor Plyatov

spi-atmel.c: problem with PDC on AT91SAM9G20

2017-09-25 Thread Igor Plyatov


Dear Nicolas, Mark, Cyrille and other developers,

please help to manage issue with data corruption by PDC of SPI.


Versions


I use linux4sam kernel 4.9.36+ 
(7e82b52ca2286e9823d2467b64bfe78980b464b7) on the custom AT91SAM9G20 
board (Stamp9G20 SOM from Taskit.de).


The drivers/spi/spi-atmel.c updated by patches from upstream kernel, 
where last commit is 7094576ccdc3acfe1e06a1e2ab547add375baf7f

Author: Cyrille Pitchen 
Date:   Fri Jun 23 17:39:16 2017 +0200

spi: atmel: fix corrupted data issue on SAM9 family SoCs


Issue
-

Data corruption happens during receiving of SPI data by kernel. It 
happens quite often (once per minute or so) if OS has some light load, 
like periodical writes to SD card in parallel with communication to SPI 
device (DSP).


Corruption of received SPI data by AT91SAM9G20 CPU confirmed with help 
of logical analyzer.

Analyzer is connected to SPI bus right near CPU.
DSP print SPI data to own serial console for debugging purposes.
Logical analyzer show exactly same data which was printed by DSP.
Kernel driver for DSP print SPI data, where some bytes corrupted, into 
kernel logs for debugging purposes.


The DSP and its linux driver has custom protocol to control correctness 
of communication between Linux host and DSP.

Protocol is quite simple:
* Half duplex.
* Main data transceived as 32 bytes long packets with CRC8 as byte #32.
* Each 32 bytes packet ACKed by one byte (error code) sent back in responce.

This protocol allow to control data integrity during communication 
between Linux host and DSP.



spi-atmel.c reports
---

atmel_spi fffc8000.spi: Atmel SPI Controller version 0x199 at 0xfffc8000 
(irq 32)
atmel_spi fffcc000.spi: Atmel SPI Controller version 0x199 at 0xfffcc000 
(irq 33)


And works with use of SPI PDC.


DSP & Logical Analyzer Data
---

To Linux Host:   01 01 43 F3 00 01 43 E8 00 01 43 EB 00 01 43 E1
To Linux Host:   00 01 43 F4 00 01 43 E1 00 01 43 F0 00 01 43 22
From Linux Host: CRC error.


Kernel Data
---

From DSP:01 01 43 F3 00 01 43 E8 00 01 43 EB 00 01 43 E1
From DSP:00 01 43 F4 00 01 43 E1 00 01 F0 F0 00 01 43 22
   **
To DSP: CRC error.

** Corrupted byte.


The SPI PIO mode works without data corruption, but this is not an 
option, because communication can have critically big lags if OS has 
some load. These lags are not acceptable for our high speed DSP.


Best wishes.
--
Igor Plyatov

mmc: host: sdhci-esdhc-imx.c: seems driver is broken

2015-09-02 Thread Igor Plyatov

ers/mmc/host/sdhci.c:1001 
sdhci_send_command+0x30/0xd58()

Modules linked in:
CPU: 0 PID: 0 Comm: swapper Tainted: GW 
4.2.0-1.1.0_beta2-04291-geef812a #68

Hardware name: Freescale i.MX51 (Device Tree Support)
Backtrace:
[<80011f10>] (dump_backtrace) from [<80012104>] (show_stack+0x18/0x1c)
 r6:8069d411 r5:0009 r4: r3:0020
[<800120ec>] (show_stack) from [<8053cb24>] (dump_stack+0x20/0x28)
[<8053cb04>] (dump_stack) from [<8001f4e0>] (warn_slowpath_common+0x90/0xb8)
[<8001f450>] (warn_slowpath_common) from [<8001f5ac>] 
(warn_slowpath_null+0x24/0x2c)

 r8:87bd9ac0 r7:0001 r6:8700f5d4 r5:8700f608 r4:87bd9ac0
[<8001f588>] (warn_slowpath_null) from [<803968e8>] 
(sdhci_send_command+0x30/0xd58)
[<803968b8>] (sdhci_send_command) from [<80397858>] 
(sdhci_finish_data+0x248/0x2f0)

 r10:8071a000 r9:80397900 r8:87bd9ac0 r7:0001 r6:0001 r5:8700f608
 r4:87bd9ac0
[<80397610>] (sdhci_finish_data) from [<80397978>] 
(sdhci_timeout_timer+0x78/0xf4)

 r10:8071a000 r9:80397900 r8:87bd9ac0 r7:00200200 r6:80397900 r5:2113
 r4:87bd9ac0
[<80397900>] (sdhci_timeout_timer) from [<80058004>] 
(call_timer_fn.isra.33+0x2c/0x9c)

 r5: r4:0101
[<80057fd8>] (call_timer_fn.isra.33) from [<800582c0>] 
(run_timer_softirq+0x1f0/0x270)

 r6:80725640 r5: r4:80724e00
[<800580d0>] (run_timer_softirq) from [<80021e14>] (__do_softirq+0xd8/0x20c)
 r9:80751a04 r8:000a r7:0101 r6:807519c0 r5:0002 r4:4001
[<80021d3c>] (__do_softirq) from [<800221bc>] (irq_exit+0x88/0xec)
 r10:0020 r9:807514e8 r8:0001 r7:87808400 r6: r5:8072f4bc
 r4:
[<80022134>] (irq_exit) from [<8004a908>] (__handle_domain_irq+0x8c/0xa8)
 r4: r3:0110
[<8004a87c>] (__handle_domain_irq) from [<800093fc>] 
(tzic_handle_irq+0x78/0xa8)

 r8:8071bed0 r7:807514e8 r6:0007 r5:0001 r4:0080 r3:8071bed0
[<80009384>] (tzic_handle_irq) from [<80012bc0>] (__irq_svc+0x40/0x74)
Exception stack(0x8071bed0 to 0x8071bf18)
bec0:  0099 579e7fd6 
80723d10
bee0:  80746788 579e7fd6 0099 80720ca4   
8071bf5c

bf00: 8071bf18 8071bf18 8037f404 8037f44c 6013 
 r10: r9: r8:80720ca4 r7:8071bf04 r6: r5:6013
 r4:8037f44c
[<8037f334>] (cpuidle_enter_state) from [<8037f56c>] 
(cpuidle_enter+0x1c/0x20)

 r10: r9:87eee400 r8:8071c10c r7:8071c10c r6:8071a000 r5:80720c64
 r4:
[<8037f550>] (cpuidle_enter) from [<800436a8>] (call_cpuidle+0x50/0x54)
[<80043658>] (call_cpuidle) from [<800437d4>] 
(cpu_startup_entry+0x128/0x18c)

 r4:80746788 r3:0001
[<800436ac>] (cpu_startup_entry) from [<80539fc0>] (rest_init+0x78/0x90)
 r7:8071c040 r3:8071a000
[<80539f48>] (rest_init) from [<806e3c34>] (start_kernel+0x2ec/0x344)
 r4: r3:8071a000
[<806e3948>] (start_kernel) from [<90008078>] (0x90008078)
---[ end trace 3da0cc3c43e8a19f ]---
mmcblk0: error -110 sending stop command, original cmd response 0x0, 
card status 0x400900
mmcblk0: error -110 transferring data, sector 0, nr 8, cmd response 0x0, 
card status 0x0

blk_update_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on dev mmcblk0, logical block 0, lost async page write
1+0 records in
1+0 records out
root@vmx51:~# mmcblk0: error -84 transferring data, sector 7741312, nr 
8, cmd response 0x900, card status 0xb00

mmc0: tried to reset card

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

mmc: host: sdhci-esdhc-imx.c: seems driver is broken

2015-09-02 Thread Igor Plyatov

ers/mmc/host/sdhci.c:1001 
sdhci_send_command+0x30/0xd58()

Modules linked in:
CPU: 0 PID: 0 Comm: swapper Tainted: GW 
4.2.0-1.1.0_beta2-04291-geef812a #68

Hardware name: Freescale i.MX51 (Device Tree Support)
Backtrace:
[<80011f10>] (dump_backtrace) from [<80012104>] (show_stack+0x18/0x1c)
 r6:8069d411 r5:0009 r4: r3:0020
[<800120ec>] (show_stack) from [<8053cb24>] (dump_stack+0x20/0x28)
[<8053cb04>] (dump_stack) from [<8001f4e0>] (warn_slowpath_common+0x90/0xb8)
[<8001f450>] (warn_slowpath_common) from [<8001f5ac>] 
(warn_slowpath_null+0x24/0x2c)

 r8:87bd9ac0 r7:0001 r6:8700f5d4 r5:8700f608 r4:87bd9ac0
[<8001f588>] (warn_slowpath_null) from [<803968e8>] 
(sdhci_send_command+0x30/0xd58)
[<803968b8>] (sdhci_send_command) from [<80397858>] 
(sdhci_finish_data+0x248/0x2f0)

 r10:8071a000 r9:80397900 r8:87bd9ac0 r7:0001 r6:0001 r5:8700f608
 r4:87bd9ac0
[<80397610>] (sdhci_finish_data) from [<80397978>] 
(sdhci_timeout_timer+0x78/0xf4)

 r10:8071a000 r9:80397900 r8:87bd9ac0 r7:00200200 r6:80397900 r5:2113
 r4:87bd9ac0
[<80397900>] (sdhci_timeout_timer) from [<80058004>] 
(call_timer_fn.isra.33+0x2c/0x9c)

 r5: r4:0101
[<80057fd8>] (call_timer_fn.isra.33) from [<800582c0>] 
(run_timer_softirq+0x1f0/0x270)

 r6:80725640 r5: r4:80724e00
[<800580d0>] (run_timer_softirq) from [<80021e14>] (__do_softirq+0xd8/0x20c)
 r9:80751a04 r8:000a r7:0101 r6:807519c0 r5:0002 r4:4001
[<80021d3c>] (__do_softirq) from [<800221bc>] (irq_exit+0x88/0xec)
 r10:0020 r9:807514e8 r8:0001 r7:87808400 r6: r5:8072f4bc
 r4:
[<80022134>] (irq_exit) from [<8004a908>] (__handle_domain_irq+0x8c/0xa8)
 r4: r3:0110
[<8004a87c>] (__handle_domain_irq) from [<800093fc>] 
(tzic_handle_irq+0x78/0xa8)

 r8:8071bed0 r7:807514e8 r6:0007 r5:0001 r4:0080 r3:8071bed0
[<80009384>] (tzic_handle_irq) from [<80012bc0>] (__irq_svc+0x40/0x74)
Exception stack(0x8071bed0 to 0x8071bf18)
bec0:  0099 579e7fd6 
80723d10
bee0:  80746788 579e7fd6 0099 80720ca4   
8071bf5c

bf00: 8071bf18 8071bf18 8037f404 8037f44c 6013 
 r10: r9: r8:80720ca4 r7:8071bf04 r6: r5:6013
 r4:8037f44c
[<8037f334>] (cpuidle_enter_state) from [<8037f56c>] 
(cpuidle_enter+0x1c/0x20)

 r10: r9:87eee400 r8:8071c10c r7:8071c10c r6:8071a000 r5:80720c64
 r4:
[<8037f550>] (cpuidle_enter) from [<800436a8>] (call_cpuidle+0x50/0x54)
[<80043658>] (call_cpuidle) from [<800437d4>] 
(cpu_startup_entry+0x128/0x18c)

 r4:80746788 r3:0001
[<800436ac>] (cpu_startup_entry) from [<80539fc0>] (rest_init+0x78/0x90)
 r7:8071c040 r3:8071a000
[<80539f48>] (rest_init) from [<806e3c34>] (start_kernel+0x2ec/0x344)
 r4: r3:8071a000
[<806e3948>] (start_kernel) from [<90008078>] (0x90008078)
---[ end trace 3da0cc3c43e8a19f ]---
mmcblk0: error -110 sending stop command, original cmd response 0x0, 
card status 0x400900
mmcblk0: error -110 transferring data, sector 0, nr 8, cmd response 0x0, 
card status 0x0

blk_update_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on dev mmcblk0, logical block 0, lost async page write
1+0 records in
1+0 records out
root@vmx51:~# mmcblk0: error -84 transferring data, sector 7741312, nr 
8, cmd response 0x900, card status 0xb00

mmc0: tried to reset card

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

[PATCH v3] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-14 Thread Igor Plyatov

* Due to HW bug, LAN8700 sometimes does not detect presence of energy in the
  Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN bit is
  set, the ENERGYON bit does not asserted sometimes). This is a common bug of
  LAN87xx family of PHY chips.
* The lan87xx_read_status() was improved to acquire ENERGYON bit. Its previous
  algorythm still not reliable on 100 % and sometimes skip cable plugging.

Signed-off-by: Igor Plyatov 
---
 drivers/net/phy/smsc.c |   31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index c0f6479..d64f016 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -91,19 +91,18 @@ static int lan911x_config_init(struct phy_device *phydev)
 }
 
 /*
- * The LAN8710/LAN8720 requires a minimum of 2 link pulses within 64ms of each
- * other in order to set the ENERGYON bit and exit EDPD mode.  If a link 
partner
- * does send the pulses within this interval, the PHY will remained powered
- * down.
- *
- * This workaround will manually toggle the PHY on/off upon calls to 
read_status
- * in order to generate link test pulses if the link is down.  If a link 
partner
- * is present, it will respond to the pulses, which will cause the ENERGYON bit
- * to be set and will cause the EDPD mode to be exited.
+ * The LAN87xx suffers from rare absence of the ENERGYON-bit when Ethernet 
cable
+ * plugs in while LAN87xx is in Energy Detect Power-Down mode. This leads to
+ * unstable detection of plugging in Ethernet cable.
+ * This workaround disables Energy Detect Power-Down mode and waiting for
+ * response on link pulses to detect presence of plugged Ethernet cable.
+ * The Energy Detect Power-Down mode is enabled again in the end of procedure 
to
+ * save approximately 220 mW of power if cable is unplugged.
  */
 static int lan87xx_read_status(struct phy_device *phydev)
 {
int err = genphy_read_status(phydev);
+   int i;
 
if (!phydev->link) {
/* Disable EDPD to wake up PHY */
@@ -116,8 +115,16 @@ static int lan87xx_read_status(struct phy_device *phydev)
if (rc < 0)
return rc;
 
-   /* Sleep 64 ms to allow ~5 link test pulses to be sent */
-   msleep(64);
+   /* Wait max 640 ms to detect energy */
+   for (i = 0; i < 64; i++) {
+   /* Sleep to allow link test pulses to be sent */
+   msleep(10);
+   rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+   if (rc < 0)
+   return rc;
+   if (rc & MII_LAN83C185_ENERGYON)
+   break;
+   };
 
/* Re-enable EDPD */
rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
@@ -191,7 +198,7 @@ static struct phy_driver smsc_phy_driver[] = {
 
/* basic functions */
.config_aneg= genphy_config_aneg,
-   .read_status= genphy_read_status,
+   .read_status= lan87xx_read_status,
.config_init= smsc_phy_config_init,
.soft_reset = smsc_phy_reset,
 
-- 
1.7.9.5

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

Re: [PATCH v2] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-14 Thread Igor Plyatov


Dear Michael,


The LAN8700, LAN8710, LAN8720 is a product of the SMSC company.
Microchip acquired SMSC in August 2012.

The LAN8700 is a legacy product for Microchip and they will not update
anything about it. So, even if Microchip know about HW bug, then there
is no chance to have Errata sheet or any new documents about LAN8700.
Long time ago, I worked on a custom device with a PHY of the same family.
Errata sheet existed but was only available by signing a NDA. So I simply
wondered whether this changed since SMSC is now Microchip or if they keep
it still so covered...


The Microchip web-site does not contain Errata sheet for LAN87xx devices.
While it contains many Errata sheets for PIC and dsPIC devices.
So, situation is same as many years ago.



I propose following comment for the lan87xx_read_status():
/*
   * The LAN87xx suffers from rare absence of the ENERGYON-bit when
Ethernet cable
   * plugs in while LAN87xx is in Energy Detect Power-Down mode. This
leads to
   * unstable detection of plugging in Ethernet cable.
   * This workaround disables Energy Detect Power-Down mode and waiting for
   * response on link pulses to detect presence of plugged Ethernet cable.
   * The Energy Detect Power-Down mode enabled again in the end of
procedure to
   * save approximately 220 mW of power if cable is unplugged.
   */
Nice. Only one nitpick: ... _is_ enabled again...



Changed in [PATCH v3].

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

Re: [PATCH v2] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-14 Thread Igor Plyatov


Dear Michael,


Hi Igor,

Am Donnerstag, 13. August 2015, 22:18:34 schrieben Sie:

> * Due to HW bug, LAN8700 sometimes does not detect presence of 
energy in the


> Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN 
bit is


> set, the ENERGYON bit does not asserted sometimes). This is a common 
bug of


> LAN87xx family of PHY chips.

Is there any offical errata sheet for this PHY family? How do you 
know, that this is a


common HW bug?



The LAN8700, LAN8710, LAN8720 is a product of the SMSC company. 
Microchip acquired SMSC in August 2012.


The LAN8700 is a legacy product for Microchip and they will not update 
anything about it. So, even if Microchip know about HW bug, then there 
is no chance to have Errata sheet or any new documents about LAN8700.


I think same history is for LAN8710/LAN8720 even if they are not marked 
as legacy. They are SMSC products.


The workarounds for same issue in LAN8710/LAN8720 was committed by:
 * Marek Vasut  as b629820d18fa65cc598390e4b9712fd5f83ee693.
 * Patrick Trantham  as 
4223dbffed9f89596177ff2b256ef3258b20fa46.


Me too, I think that this family has some problems with this mode, 
however, without


hard evidence, I would put it softer.



I have discovered this bug by just monitoring of data to/from MDIO 
registers of LAN8700.
And HW issue is proven on 100 % by rare absence of ENERGYON bit when 
cable is plugged in.

Sometimes, it is required to make 2-20 tests to catch this issue.

The configuration of CPU pins, responsible for the MDIO interface, was 
checked carefully by oscilloscope and they are fine (no spikes, no 
garbage, good shape of edges).


> * The lan87xx_read_status() was improved to acquire ENERGYON bit. 
Its previous


> algorythm still not reliable on 100 % and sometimes skip cable plugging.

>

> Signed-off-by: Igor Plyatov 

> ---

> drivers/net/phy/smsc.c | 15 ---

> 1 file changed, 12 insertions(+), 3 deletions(-)

>

> diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c

> index c0f6479..8559ff1 100644

> --- a/drivers/net/phy/smsc.c

> +++ b/drivers/net/phy/smsc.c

> @@ -104,6 +104,7 @@ static int lan911x_config_init(struct phy_device 
*phydev)


> static int lan87xx_read_status(struct phy_device *phydev)

> {

> int err = genphy_read_status(phydev);

> + int i;

>

> if (!phydev->link) {

> /* Disable EDPD to wake up PHY */

> @@ -116,8 +117,16 @@ static int lan87xx_read_status(struct 
phy_device *phydev)


> if (rc < 0)

> return rc;

>

> - /* Sleep 64 ms to allow ~5 link test pulses to be sent */

> - msleep(64);

> + /* Wait max 640 ms to detect energy */

Why 640ms and not e.g. 650ms?

I'm no PHY expert, but this looks like an ugly workaround.



Such a value was adopted after many trial and probes. It allows to 
detect cable plugging on 100 %.

Ugly or not, but it works and reliable.

Maybe it would be better to avoid this power saving mode at all, when 
it is not


reliable, but this are just my 2cts. :-)



Power saving mode allow to save around 220 mW of energy consumed from 
power supply, when Ethernet cable is not plugged in.

This is a good value for embedded devices.
Better to keep power save mode on.

Anyway, I guess you should also update the explanation on top of the 
function to reflect


your new approach.



I propose following comment for the lan87xx_read_status():
/*
 * The LAN87xx suffers from rare absence of the ENERGYON-bit when 
Ethernet cable
 * plugs in while LAN87xx is in Energy Detect Power-Down mode. This 
leads to

 * unstable detection of plugging in Ethernet cable.
 * This workaround disables Energy Detect Power-Down mode and waiting for
 * response on link pulses to detect presence of plugged Ethernet cable.
 * The Energy Detect Power-Down mode enabled again in the end of 
procedure to

 * save approximately 220 mW of power if cable is unplugged.
 */


> + for (i = 0; i < 64; i++) {

> + /* Sleep to allow link test pulses to be sent */

> + msleep(10);

> + rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);

> + if (rc < 0)

> + return rc;

> + if (rc & MII_LAN83C185_ENERGYON)

> + break;

> + };

>

> /* Re-enable EDPD */

> rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);

> @@ -191,7 +200,7 @@ static struct phy_driver smsc_phy_driver[] = {

>

> /* basic functions */

> .config_aneg = genphy_config_aneg,

> - .read_status = genphy_read_status,

> + .read_status = lan87xx_read_status,

This one makes sense, since I really guess, that the whole PHY family 
behave very similar.


But this change alone does not solve your problem, right?



Yes, use of non modified lan87xx_read_status() only reduce amount of 
false cable detections, but does not resolve issue completely.



> .config_init = smsc_phy_config_init,

> .soft_reset = smsc_phy_reset,

>

>

Regards,

Michael



Best wishes.

Re: [PATCH v2] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-14 Thread Igor Plyatov


Dear Michael,


Hi Igor,

Am Donnerstag, 13. August 2015, 22:18:34 schrieben Sie:

 * Due to HW bug, LAN8700 sometimes does not detect presence of 
energy in the


 Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN 
bit is


 set, the ENERGYON bit does not asserted sometimes). This is a common 
bug of


 LAN87xx family of PHY chips.

Is there any offical errata sheet for this PHY family? How do you 
know, that this is a


common HW bug?



The LAN8700, LAN8710, LAN8720 is a product of the SMSC company. 
Microchip acquired SMSC in August 2012.


The LAN8700 is a legacy product for Microchip and they will not update 
anything about it. So, even if Microchip know about HW bug, then there 
is no chance to have Errata sheet or any new documents about LAN8700.


I think same history is for LAN8710/LAN8720 even if they are not marked 
as legacy. They are SMSC products.


The workarounds for same issue in LAN8710/LAN8720 was committed by:
 * Marek Vasut ma...@denx.de as b629820d18fa65cc598390e4b9712fd5f83ee693.
 * Patrick Trantham patrick.trant...@fuel7.com as 
4223dbffed9f89596177ff2b256ef3258b20fa46.


Me too, I think that this family has some problems with this mode, 
however, without


hard evidence, I would put it softer.



I have discovered this bug by just monitoring of data to/from MDIO 
registers of LAN8700.
And HW issue is proven on 100 % by rare absence of ENERGYON bit when 
cable is plugged in.

Sometimes, it is required to make 2-20 tests to catch this issue.

The configuration of CPU pins, responsible for the MDIO interface, was 
checked carefully by oscilloscope and they are fine (no spikes, no 
garbage, good shape of edges).


 * The lan87xx_read_status() was improved to acquire ENERGYON bit. 
Its previous


 algorythm still not reliable on 100 % and sometimes skip cable plugging.



 Signed-off-by: Igor Plyatov plya...@gmail.com

 ---

 drivers/net/phy/smsc.c | 15 ---

 1 file changed, 12 insertions(+), 3 deletions(-)



 diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c

 index c0f6479..8559ff1 100644

 --- a/drivers/net/phy/smsc.c

 +++ b/drivers/net/phy/smsc.c

 @@ -104,6 +104,7 @@ static int lan911x_config_init(struct phy_device 
*phydev)


 static int lan87xx_read_status(struct phy_device *phydev)

 {

 int err = genphy_read_status(phydev);

 + int i;



 if (!phydev-link) {

 /* Disable EDPD to wake up PHY */

 @@ -116,8 +117,16 @@ static int lan87xx_read_status(struct 
phy_device *phydev)


 if (rc  0)

 return rc;



 - /* Sleep 64 ms to allow ~5 link test pulses to be sent */

 - msleep(64);

 + /* Wait max 640 ms to detect energy */

Why 640ms and not e.g. 650ms?

I'm no PHY expert, but this looks like an ugly workaround.



Such a value was adopted after many trial and probes. It allows to 
detect cable plugging on 100 %.

Ugly or not, but it works and reliable.

Maybe it would be better to avoid this power saving mode at all, when 
it is not


reliable, but this are just my 2cts. :-)



Power saving mode allow to save around 220 mW of energy consumed from 
power supply, when Ethernet cable is not plugged in.

This is a good value for embedded devices.
Better to keep power save mode on.

Anyway, I guess you should also update the explanation on top of the 
function to reflect


your new approach.



I propose following comment for the lan87xx_read_status():
/*
 * The LAN87xx suffers from rare absence of the ENERGYON-bit when 
Ethernet cable
 * plugs in while LAN87xx is in Energy Detect Power-Down mode. This 
leads to

 * unstable detection of plugging in Ethernet cable.
 * This workaround disables Energy Detect Power-Down mode and waiting for
 * response on link pulses to detect presence of plugged Ethernet cable.
 * The Energy Detect Power-Down mode enabled again in the end of 
procedure to

 * save approximately 220 mW of power if cable is unplugged.
 */


 + for (i = 0; i  64; i++) {

 + /* Sleep to allow link test pulses to be sent */

 + msleep(10);

 + rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);

 + if (rc  0)

 + return rc;

 + if (rc  MII_LAN83C185_ENERGYON)

 + break;

 + };



 /* Re-enable EDPD */

 rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);

 @@ -191,7 +200,7 @@ static struct phy_driver smsc_phy_driver[] = {



 /* basic functions */

 .config_aneg = genphy_config_aneg,

 - .read_status = genphy_read_status,

 + .read_status = lan87xx_read_status,

This one makes sense, since I really guess, that the whole PHY family 
behave very similar.


But this change alone does not solve your problem, right?



Yes, use of non modified lan87xx_read_status() only reduce amount of 
false cable detections, but does not resolve issue completely.



 .config_init = smsc_phy_config_init,

 .soft_reset = smsc_phy_reset,





Regards,

Michael



Best wishes.

--
Igor Plyatov

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http

[PATCH v3] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-14 Thread Igor Plyatov

* Due to HW bug, LAN8700 sometimes does not detect presence of energy in the
  Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN bit is
  set, the ENERGYON bit does not asserted sometimes). This is a common bug of
  LAN87xx family of PHY chips.
* The lan87xx_read_status() was improved to acquire ENERGYON bit. Its previous
  algorythm still not reliable on 100 % and sometimes skip cable plugging.

Signed-off-by: Igor Plyatov plya...@gmail.com
---
 drivers/net/phy/smsc.c |   31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index c0f6479..d64f016 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -91,19 +91,18 @@ static int lan911x_config_init(struct phy_device *phydev)
 }
 
 /*
- * The LAN8710/LAN8720 requires a minimum of 2 link pulses within 64ms of each
- * other in order to set the ENERGYON bit and exit EDPD mode.  If a link 
partner
- * does send the pulses within this interval, the PHY will remained powered
- * down.
- *
- * This workaround will manually toggle the PHY on/off upon calls to 
read_status
- * in order to generate link test pulses if the link is down.  If a link 
partner
- * is present, it will respond to the pulses, which will cause the ENERGYON bit
- * to be set and will cause the EDPD mode to be exited.
+ * The LAN87xx suffers from rare absence of the ENERGYON-bit when Ethernet 
cable
+ * plugs in while LAN87xx is in Energy Detect Power-Down mode. This leads to
+ * unstable detection of plugging in Ethernet cable.
+ * This workaround disables Energy Detect Power-Down mode and waiting for
+ * response on link pulses to detect presence of plugged Ethernet cable.
+ * The Energy Detect Power-Down mode is enabled again in the end of procedure 
to
+ * save approximately 220 mW of power if cable is unplugged.
  */
 static int lan87xx_read_status(struct phy_device *phydev)
 {
int err = genphy_read_status(phydev);
+   int i;
 
if (!phydev-link) {
/* Disable EDPD to wake up PHY */
@@ -116,8 +115,16 @@ static int lan87xx_read_status(struct phy_device *phydev)
if (rc  0)
return rc;
 
-   /* Sleep 64 ms to allow ~5 link test pulses to be sent */
-   msleep(64);
+   /* Wait max 640 ms to detect energy */
+   for (i = 0; i  64; i++) {
+   /* Sleep to allow link test pulses to be sent */
+   msleep(10);
+   rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+   if (rc  0)
+   return rc;
+   if (rc  MII_LAN83C185_ENERGYON)
+   break;
+   };
 
/* Re-enable EDPD */
rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
@@ -191,7 +198,7 @@ static struct phy_driver smsc_phy_driver[] = {
 
/* basic functions */
.config_aneg= genphy_config_aneg,
-   .read_status= genphy_read_status,
+   .read_status= lan87xx_read_status,
.config_init= smsc_phy_config_init,
.soft_reset = smsc_phy_reset,
 
-- 
1.7.9.5

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

Re: [PATCH v2] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-14 Thread Igor Plyatov


Dear Michael,


The LAN8700, LAN8710, LAN8720 is a product of the SMSC company.
Microchip acquired SMSC in August 2012.

The LAN8700 is a legacy product for Microchip and they will not update
anything about it. So, even if Microchip know about HW bug, then there
is no chance to have Errata sheet or any new documents about LAN8700.
Long time ago, I worked on a custom device with a PHY of the same family.
Errata sheet existed but was only available by signing a NDA. So I simply
wondered whether this changed since SMSC is now Microchip or if they keep
it still so covered...


The Microchip web-site does not contain Errata sheet for LAN87xx devices.
While it contains many Errata sheets for PIC and dsPIC devices.
So, situation is same as many years ago.



I propose following comment for the lan87xx_read_status():
/*
   * The LAN87xx suffers from rare absence of the ENERGYON-bit when
Ethernet cable
   * plugs in while LAN87xx is in Energy Detect Power-Down mode. This
leads to
   * unstable detection of plugging in Ethernet cable.
   * This workaround disables Energy Detect Power-Down mode and waiting for
   * response on link pulses to detect presence of plugged Ethernet cable.
   * The Energy Detect Power-Down mode enabled again in the end of
procedure to
   * save approximately 220 mW of power if cable is unplugged.
   */
Nice. Only one nitpick: ... _is_ enabled again...



Changed in [PATCH v3].

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

Re: [PATCH] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-13 Thread Igor Plyatov


Dear David and Joe,

thank you for patch review!

Please look at email with subject
"[PATCH v2] net: phy: workaround for buggy cable detection by LAN8700 
after cable plugging"


Best wishes.
--
Igor Plyatov


From: Joe Perches 
Date: Thu, 13 Aug 2015 10:15:15 -0700


On Thu, 2015-08-13 at 20:11 +0300, Igor Plyatov wrote:

On Thu, 2015-08-13 at 16:12 +0300, Igor Plyatov wrote:

* Due to HW bug, LAN8700 sometimes does not detect presence of energy in the
Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN bit is
set, the ENERGYON bit does not asserted sometimes). This is a common bug of
LAN87xx family of PHY chips.
* The lan87xx_read_status() was improved to acquire ENERGYON bit. Its previous
algorythm still not reliable on 100 % and sometimes skip cable plugging.

[]

diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c

[]

@@ -104,10 +104,12 @@ static int lan911x_config_init(struct phy_device *phydev)
   static int lan87xx_read_status(struct phy_device *phydev)
   {
int err = genphy_read_status(phydev);
+   int rc;

Is there a reason to move this declaration?

There is no strict requirement to move declaration of the rc.
It was made just to have all declarations easily visible.

Generally it's better to have declarations
in the minimal/narrowest scope possible.

Agreed, and it's %100 unrelated to the purpose of this patch so not
should be included for that reason as well.

You will need to respin this patch with the variable moving elided.


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

[PATCH v2] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-13 Thread Igor Plyatov

* Due to HW bug, LAN8700 sometimes does not detect presence of energy in the
  Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN bit is
  set, the ENERGYON bit does not asserted sometimes). This is a common bug of
  LAN87xx family of PHY chips.
* The lan87xx_read_status() was improved to acquire ENERGYON bit. Its previous
  algorythm still not reliable on 100 % and sometimes skip cable plugging.

Signed-off-by: Igor Plyatov 
---
 drivers/net/phy/smsc.c |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index c0f6479..8559ff1 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -104,6 +104,7 @@ static int lan911x_config_init(struct phy_device *phydev)
 static int lan87xx_read_status(struct phy_device *phydev)
 {
int err = genphy_read_status(phydev);
+   int i;
 
if (!phydev->link) {
/* Disable EDPD to wake up PHY */
@@ -116,8 +117,16 @@ static int lan87xx_read_status(struct phy_device *phydev)
if (rc < 0)
return rc;
 
-   /* Sleep 64 ms to allow ~5 link test pulses to be sent */
-   msleep(64);
+   /* Wait max 640 ms to detect energy */
+   for (i = 0; i < 64; i++) {
+   /* Sleep to allow link test pulses to be sent */
+   msleep(10);
+   rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+   if (rc < 0)
+   return rc;
+   if (rc & MII_LAN83C185_ENERGYON)
+   break;
+   };
 
/* Re-enable EDPD */
rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
@@ -191,7 +200,7 @@ static struct phy_driver smsc_phy_driver[] = {
 
/* basic functions */
.config_aneg= genphy_config_aneg,
-   .read_status= genphy_read_status,
+   .read_status= lan87xx_read_status,
.config_init= smsc_phy_config_init,
.soft_reset = smsc_phy_reset,
 
-- 
1.7.9.5

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

Re: [PATCH] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-13 Thread Igor Plyatov


Dear Joe,


On Thu, 2015-08-13 at 16:12 +0300, Igor Plyatov wrote:

* Due to HW bug, LAN8700 sometimes does not detect presence of energy in the
   Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN bit is
   set, the ENERGYON bit does not asserted sometimes). This is a common bug of
   LAN87xx family of PHY chips.
* The lan87xx_read_status() was improved to acquire ENERGYON bit. Its previous
   algorythm still not reliable on 100 % and sometimes skip cable plugging.

[]

diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c

[]

@@ -104,10 +104,12 @@ static int lan911x_config_init(struct phy_device *phydev)
  static int lan87xx_read_status(struct phy_device *phydev)
  {
int err = genphy_read_status(phydev);
+   int rc;

Is there a reason to move this declaration?


There is no strict requirement to move declaration of the rc.
It was made just to have all declarations easily visible.


+   int i;
  
  	if (!phydev->link) {

/* Disable EDPD to wake up PHY */
-   int rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+   rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
if (rc < 0)
return rc;
  




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

[PATCH] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-13 Thread Igor Plyatov

* Due to HW bug, LAN8700 sometimes does not detect presence of energy in the
  Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN bit is
  set, the ENERGYON bit does not asserted sometimes). This is a common bug of
  LAN87xx family of PHY chips.
* The lan87xx_read_status() was improved to acquire ENERGYON bit. Its previous
  algorythm still not reliable on 100 % and sometimes skip cable plugging.

Signed-off-by: Igor Plyatov 
---
 drivers/net/phy/smsc.c |   18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index c0f6479..a380958 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -104,10 +104,12 @@ static int lan911x_config_init(struct phy_device *phydev)
 static int lan87xx_read_status(struct phy_device *phydev)
 {
int err = genphy_read_status(phydev);
+   int rc;
+   int i;
 
if (!phydev->link) {
/* Disable EDPD to wake up PHY */
-   int rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+   rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
if (rc < 0)
return rc;
 
@@ -116,8 +118,16 @@ static int lan87xx_read_status(struct phy_device *phydev)
if (rc < 0)
return rc;
 
-   /* Sleep 64 ms to allow ~5 link test pulses to be sent */
-   msleep(64);
+   /* Wait max 640 ms to detect energy */
+   for (i = 0; i < 64; i++) {
+   /* Sleep to allow link test pulses to be sent */
+   msleep(10);
+   rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+   if (rc < 0)
+   return rc;
+   if (rc & MII_LAN83C185_ENERGYON)
+   break;
+   };
 
/* Re-enable EDPD */
rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
@@ -191,7 +201,7 @@ static struct phy_driver smsc_phy_driver[] = {
 
/* basic functions */
.config_aneg= genphy_config_aneg,
-   .read_status= genphy_read_status,
+   .read_status= lan87xx_read_status,
.config_init= smsc_phy_config_init,
.soft_reset = smsc_phy_reset,
 
-- 
1.7.9.5

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

[PATCH] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-13 Thread Igor Plyatov

* Due to HW bug, LAN8700 sometimes does not detect presence of energy in the
  Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN bit is
  set, the ENERGYON bit does not asserted sometimes). This is a common bug of
  LAN87xx family of PHY chips.
* The lan87xx_read_status() was improved to acquire ENERGYON bit. Its previous
  algorythm still not reliable on 100 % and sometimes skip cable plugging.

Signed-off-by: Igor Plyatov plya...@gmail.com
---
 drivers/net/phy/smsc.c |   18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index c0f6479..a380958 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -104,10 +104,12 @@ static int lan911x_config_init(struct phy_device *phydev)
 static int lan87xx_read_status(struct phy_device *phydev)
 {
int err = genphy_read_status(phydev);
+   int rc;
+   int i;
 
if (!phydev-link) {
/* Disable EDPD to wake up PHY */
-   int rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+   rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
if (rc  0)
return rc;
 
@@ -116,8 +118,16 @@ static int lan87xx_read_status(struct phy_device *phydev)
if (rc  0)
return rc;
 
-   /* Sleep 64 ms to allow ~5 link test pulses to be sent */
-   msleep(64);
+   /* Wait max 640 ms to detect energy */
+   for (i = 0; i  64; i++) {
+   /* Sleep to allow link test pulses to be sent */
+   msleep(10);
+   rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+   if (rc  0)
+   return rc;
+   if (rc  MII_LAN83C185_ENERGYON)
+   break;
+   };
 
/* Re-enable EDPD */
rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
@@ -191,7 +201,7 @@ static struct phy_driver smsc_phy_driver[] = {
 
/* basic functions */
.config_aneg= genphy_config_aneg,
-   .read_status= genphy_read_status,
+   .read_status= lan87xx_read_status,
.config_init= smsc_phy_config_init,
.soft_reset = smsc_phy_reset,
 
-- 
1.7.9.5

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

Re: [PATCH] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-13 Thread Igor Plyatov


Dear Joe,


On Thu, 2015-08-13 at 16:12 +0300, Igor Plyatov wrote:

* Due to HW bug, LAN8700 sometimes does not detect presence of energy in the
   Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN bit is
   set, the ENERGYON bit does not asserted sometimes). This is a common bug of
   LAN87xx family of PHY chips.
* The lan87xx_read_status() was improved to acquire ENERGYON bit. Its previous
   algorythm still not reliable on 100 % and sometimes skip cable plugging.

[]

diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c

[]

@@ -104,10 +104,12 @@ static int lan911x_config_init(struct phy_device *phydev)
  static int lan87xx_read_status(struct phy_device *phydev)
  {
int err = genphy_read_status(phydev);
+   int rc;

Is there a reason to move this declaration?


There is no strict requirement to move declaration of the rc.
It was made just to have all declarations easily visible.


+   int i;
  
  	if (!phydev-link) {

/* Disable EDPD to wake up PHY */
-   int rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+   rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
if (rc  0)
return rc;
  




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

Re: [PATCH] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-13 Thread Igor Plyatov


Dear David and Joe,

thank you for patch review!

Please look at email with subject
[PATCH v2] net: phy: workaround for buggy cable detection by LAN8700 
after cable plugging


Best wishes.
--
Igor Plyatov


From: Joe Perches j...@perches.com
Date: Thu, 13 Aug 2015 10:15:15 -0700


On Thu, 2015-08-13 at 20:11 +0300, Igor Plyatov wrote:

On Thu, 2015-08-13 at 16:12 +0300, Igor Plyatov wrote:

* Due to HW bug, LAN8700 sometimes does not detect presence of energy in the
Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN bit is
set, the ENERGYON bit does not asserted sometimes). This is a common bug of
LAN87xx family of PHY chips.
* The lan87xx_read_status() was improved to acquire ENERGYON bit. Its previous
algorythm still not reliable on 100 % and sometimes skip cable plugging.

[]

diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c

[]

@@ -104,10 +104,12 @@ static int lan911x_config_init(struct phy_device *phydev)
   static int lan87xx_read_status(struct phy_device *phydev)
   {
int err = genphy_read_status(phydev);
+   int rc;

Is there a reason to move this declaration?

There is no strict requirement to move declaration of the rc.
It was made just to have all declarations easily visible.

Generally it's better to have declarations
in the minimal/narrowest scope possible.

Agreed, and it's %100 unrelated to the purpose of this patch so not
should be included for that reason as well.

You will need to respin this patch with the variable moving elided.


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

[PATCH v2] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging

2015-08-13 Thread Igor Plyatov

* Due to HW bug, LAN8700 sometimes does not detect presence of energy in the
  Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN bit is
  set, the ENERGYON bit does not asserted sometimes). This is a common bug of
  LAN87xx family of PHY chips.
* The lan87xx_read_status() was improved to acquire ENERGYON bit. Its previous
  algorythm still not reliable on 100 % and sometimes skip cable plugging.

Signed-off-by: Igor Plyatov plya...@gmail.com
---
 drivers/net/phy/smsc.c |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index c0f6479..8559ff1 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -104,6 +104,7 @@ static int lan911x_config_init(struct phy_device *phydev)
 static int lan87xx_read_status(struct phy_device *phydev)
 {
int err = genphy_read_status(phydev);
+   int i;
 
if (!phydev-link) {
/* Disable EDPD to wake up PHY */
@@ -116,8 +117,16 @@ static int lan87xx_read_status(struct phy_device *phydev)
if (rc  0)
return rc;
 
-   /* Sleep 64 ms to allow ~5 link test pulses to be sent */
-   msleep(64);
+   /* Wait max 640 ms to detect energy */
+   for (i = 0; i  64; i++) {
+   /* Sleep to allow link test pulses to be sent */
+   msleep(10);
+   rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+   if (rc  0)
+   return rc;
+   if (rc  MII_LAN83C185_ENERGYON)
+   break;
+   };
 
/* Re-enable EDPD */
rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
@@ -191,7 +200,7 @@ static struct phy_driver smsc_phy_driver[] = {
 
/* basic functions */
.config_aneg= genphy_config_aneg,
-   .read_status= genphy_read_status,
+   .read_status= lan87xx_read_status,
.config_init= smsc_phy_config_init,
.soft_reset = smsc_phy_reset,
 
-- 
1.7.9.5

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

Buggy cable detection on i.MX51, fec driver and LAN8700 PHY

2015-07-27 Thread Igor Plyatov


Dear all,

very often we observe issue with Ethernet cable detection during cable 
unplugging and plugging.


We use Voipac i.MX51 SOMs (System On Modules). They are based on 
Freescale i.MX51 CPU with LAN7800 PHY in MII mode. The schematic of PHY 
connection is very similar to the Freescale i.MX51 Babbage board.


The Ethernet interface eth0 is configured statically for simplicity, but 
same issue exists with DHCP configuration.


I did a lot of tests to determine stability of Ethernet cable detection 
by the "fec" Ethernet driver.


In normal operation, if I unplug the Ethernet cable, then "fec" driver 
prints "fec 83fec000.ethernet eth0: Link is Down" and green LED 
(Ethernet medium detected) is OFF.
If I plug cable back, then "fec" driver print "fec 83fec000.ethernet 
eth0: Link is Up - 100Mbps/Full - flow control off" and green LED is ON.


But sometimes, after cable plugging, "fec" driver does not print 
anything on the console and green LED does not show detection of 
Ethernet cable. Frequency of issue appearing is a random value. 
Sometimes issue appears after second cable unplugging/plugging, but 
sometimes - after 10-20 unplugging/plugging.


The issue was tested and exists on kernels from linux-3.8.5 till current 
linux-4.2-rc4-cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f.


Same tests was made with different versions of the Barebox bootloader 
and cable detection works flawless.


Please, help to resolve issue with Linux drivers.

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

Buggy cable detection on i.MX51, fec driver and LAN8700 PHY

2015-07-27 Thread Igor Plyatov


Dear all,

very often we observe issue with Ethernet cable detection during cable 
unplugging and plugging.


We use Voipac i.MX51 SOMs (System On Modules). They are based on 
Freescale i.MX51 CPU with LAN7800 PHY in MII mode. The schematic of PHY 
connection is very similar to the Freescale i.MX51 Babbage board.


The Ethernet interface eth0 is configured statically for simplicity, but 
same issue exists with DHCP configuration.


I did a lot of tests to determine stability of Ethernet cable detection 
by the fec Ethernet driver.


In normal operation, if I unplug the Ethernet cable, then fec driver 
prints fec 83fec000.ethernet eth0: Link is Down and green LED 
(Ethernet medium detected) is OFF.
If I plug cable back, then fec driver print fec 83fec000.ethernet 
eth0: Link is Up - 100Mbps/Full - flow control off and green LED is ON.


But sometimes, after cable plugging, fec driver does not print 
anything on the console and green LED does not show detection of 
Ethernet cable. Frequency of issue appearing is a random value. 
Sometimes issue appears after second cable unplugging/plugging, but 
sometimes - after 10-20 unplugging/plugging.


The issue was tested and exists on kernels from linux-3.8.5 till current 
linux-4.2-rc4-cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f.


Same tests was made with different versions of the Barebox bootloader 
and cable detection works flawless.


Please, help to resolve issue with Linux drivers.

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

41 matches

Mail list logo