Re: About a suspicious msleep during doxfer in s3c2410 i2c bus driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




2009. 07. 22, 오후 9:43, Mark Brown 작성:

On Wed, Jul 22, 2009 at 05:12:17PM +0900, Dongsoo, Nathaniel Kim wrote:

Since I was working on S3C64XX and C1XX, I found something weird on
I2C bus device.
The thing is that when I try to write multiple registers through I2C
bus, it takes much more time for multiple registers to be written than
any other processor's i2c bus device.

Yes, this is extremely painful for a lot of devices - audio CODECs tend
to be noticably affected, especially at resume.  Depending on your
device and what you're doing you *may* be able to speed things up by
accessing many registers in a single I/O in the chip driver but
obviously that's not ideal.

With several different target boards using s3c64xx and s5pc1xx, it
went good without that msleep(). And of course it is working great
with multiple i2c device attached as well.
So, I want to ask Ben and anyone else using I2C device about removing
that msleep might be ok or not. In my case, it went ok. Please let me
know your opinion.

My *recollection* is that this is mostly there for multi-master
configurations.

I'm wondering if even if we can't remove the delay completely yet we
could add platform data to allow it to be configured on a per-board
basis?

I wish I could answer clearly about this but not having much experience over various I2C bus devices so I can't say with a strict "yes". But in my experience, I've never seen any i2c bus driver serving platform data to be configured with delay support. Tho if it is really necessary for some specified class of i2c devices, we should make one. I'm wondering why anybody has been issued this topic yet. the driver for s3c2410 i2c bus has been the way it is for ages I guess. It obviously seems to be taking long time to write down registers through the s3c2410 i2c bus driver than any other processor's i2c driver. maybe not so many people using enormous i2c register programming on Samsung processors could be the reason I suppose. anyway, let's figure it out the best way we can.
Cheers,

Nate




=
Dongsoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media & Communications R&D Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo.kim@xxxxxxxxx
           dongsoo45.kim@xxxxxxxxxxx

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

[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux