linux-kernel - RE: [PATCH v6 1/2] i2c: imx: add DMA support for freescale i2c driver

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <31f8f5504fc24d999f5af74338602bed@BLUPR03MB373.namprd03.prod.outlook.com>
Date:	Thu, 7 Aug 2014 05:28:51 +0000
From:	"fugang.duan@...escale.com" <fugang.duan@...escale.com>
To:	Yao Yuan <yao.yuan@...escale.com>,
	"wsa@...-dreams.de" <wsa@...-dreams.de>,
	"marex@...x.de" <marex@...x.de>
CC:	"LW@...O-electronics.de" <LW@...O-electronics.de>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"shawn.guo@...aro.org" <shawn.guo@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"Frank.Li@...escale.com" <Frank.Li@...escale.com>
Subject: RE: [PATCH v6 1/2] i2c: imx: add DMA support for freescale i2c driver

From: Yuan Yao-B46683 Data: Wednesday, August 06, 2014 3:07 PM
>To: Duan Fugang-B38611; wsa@...-dreams.de; marex@...x.de
>Cc: LW@...O-electronics.de; mark.rutland@....com; shawn.guo@...aro.org;
>linux-kernel@...r.kernel.org; linux-arm-kernel@...ts.infradead.org; linux-
>i2c@...r.kernel.org; Li Frank-B20596
>Subject: RE: [PATCH v6 1/2] i2c: imx: add DMA support for freescale i2c
>driver
>
>Hi Fugang,
>
>Duan Fugang wrote:
>[...]
>>+	dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
>>+	dma_sconfig.dst_maxburst = 1;
>> The maxburst is 1 cause very slow efficiency for DMA copy, which
>> system performance even is slower Than cpu mode.
>
>There is no FIFO for IMX i2c, so the maxburst shoud be 1 for hardware
>request.
>
Understand. Thanks.

>
>> >+	/* Waiting for Transfer complete. */
>> >+	while (timeout--) {
>> >+		temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
>> >+		if (temp & I2SR_ICF)
>> >+			break;
>> >+		udelay(10);
>> >+	}
>> Whether there have better method like interrupt to avoid dead wait
>> here until timeout ?
>
>Can you give me more suggestion? We have discussed it with our team, It
>seems the short query wait is necessary.
>
At least, you can use schdule_timeout() instead of udelay() ?

>> >+
>> >+	if (!timeout)
>> >+		return -ETIMEDOUT;
>> >+	temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
>> >+	temp &= ~I2CR_DMAEN;
>> >+	imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
>> >+
>> >+	/* The last data byte must be transferred by the CPU. */
>> >+	imx_i2c_write_reg(msgs->buf[msgs->len-1],
>> >+				i2c_imx, IMX_I2C_I2DR);
>> >+	result = i2c_imx_trx_complete(i2c_imx);
>> >+	if (result)
>> >+		return result;
>> I don't understand why the last data need to be transmited by cpu. I
>> guess you want to get IIF interrupt ?
>
>Yes, we need the interrupt to do some mop-up.
>
>Also follow the hardware request as:
>
>The following flow diagram details exactly the operation for using a DMA
>controller to transmit "n" data bytes to a slave. The first byte (the
>slave calling address) is always transmitted by the CPU. All subsequent
>data bytes (apart from the last data byte) can be transferred by the DMA
>controller. The last data byte must be transferred by the CPU.
>
>> >+
>> >+	result = i2c_imx_acked(i2c_imx);
>> >+	if (result)
>> >+		return result;
>> >+
--
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/