From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] ColdFire I2C implementing I2C idle [PATCH] -- resent in git format
Date: Thu, 21 Jan 2010 12:49:25 +0100 [thread overview]
Message-ID: <4B583F45.8080900@denx.de> (raw)
In-Reply-To: <20100121102918.GE23389@leila.ping.de>
Hello Wolfgang,
Wolfgang Wegner wrote:
> On Thu, Jan 21, 2010 at 09:04:29AM +0100, Heiko Schocher wrote:
>> Hello Joakim,
>>
>> Joakim Tjernlund wrote:
>>>> Hello Michael,
>>>>
>>>> Thanks for posting your patches in plain text.
>>>>
>>>> Michael Durrant wrote:
>>>>> drivers_i2c_fsl_i2c.patch
>>>>> - need to set I2C to be idle according to the MCF5282 user's manual
>>>>>
>>>>> If I2SR[IBB] is set when the I2C bus module is enabled,
>>>>> execute the following code sequence before proceeding with
>>>>> normal initialization code. This issues a STOP command to the
>>>>> slave device, placing it in idle state as if it were just
>>>>> power-cycled on.
>>>>>
>>>>> I2CR = 0x0
>>>>> I2CR = 0xA
>>>>> dummy read of I2DR
>>>>> I2SR = 0x0
>>>>> I2CR = 0x0
>>>>>
>>>>> Signed-off-by: David Wu <davidwu@arcturusnetworks.com>
>>>>> Signed-off-by: Michael Durrant <mdurrant@arcturusnetworks.com>
>>>>> ---
>>>>> drivers/i2c/fsl_i2c.c | 13 +++++++++++++
>>>>> 1 files changed, 13 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
>>>>> index 2241990..bce750c 100644
>>>>> --- a/drivers/i2c/fsl_i2c.c
>>>>> +++ b/drivers/i2c/fsl_i2c.c
>>>>> @@ -251,12 +251,25 @@ i2c_init(int speed, int slaveadd)
>>>>> #endif
>>>>> }
>>>>>
>>>>> +static __inline__ int i2c_set_idle(void)
>>>>> +{
>>>>> + writeb(0, &i2c_dev[i2c_bus_num]->cr);
>>>>> + writeb(I2C_CR_MEN | I2C_CR_MSTA, &i2c_dev[i2c_bus_num]->cr);
>>>>> + readb(&i2c_dev[i2c_bus_num]->dr);
>>>>> + writeb(0, &i2c_dev[i2c_bus_num]->sr);
>>>>> + writeb(0, &i2c_dev[i2c_bus_num]->cr);
>>>>> + writeb(I2C_CR_MEN, &i2c_dev[i2c_bus_num]->cr);
>>>>> +}
>>>>> +
>>>>> static int
>>>>> i2c_wait4bus(void)
>>>>> {
>>>>> unsigned long long timeval = get_ticks();
>>>>> const unsigned long long timeout = usec2ticks(CONFIG_I2C_MBB_TIMEOUT);
>>>>>
>>>>> + if (readb(&i2c_dev[i2c_bus_num]->sr) & I2C_SR_MBB)
>>>>> + i2c_set_idle();
>>>>> +
>>>>> while (readb(&i2c_dev[i2c_bus_num]->sr) & I2C_SR_MBB) {
>>>>> if ((get_ticks() - timeval) > timeout)
>>>>> return -1;
>>>> Hmm.. I can;t find this for example in the MPC8360ERM.pdf, which
>>>> uses also this driver ... So I vote for activating this only,
>>>> if this driver is used for __M68K__ ...
>>>>
>>>> Also, you write, that this sequence is necessary before normal
>>>> initialization code, but i2c_wait4bus() is called from i2c_read()
>>>> and i2c_write(), so the I2C bus is long ago initialized ...
>>>> or what do you mean with "normal initialization code" ?
>>>>
>>>> Also, whats with multimaster systems? Your code maybe cuts a running
>>>> data transmission. The MPC8360ERM.pdf manual says "check the MBB bit,
>>>> if the bus is free, before switching to master mode", thats what
>>>> actual code did ... so, I want this only activated, if __M68K__
>>>> is defined ...
>>> All true. This cannot go in as is. What you need is a I2C reset sequence
>>> as the above isn't enough in the general case. Michael, have a look at the
>>> kernel driver, it has some fixup code you could borrow.
>> Michael: Maybe you take a look in u-boot:board/keymile/common/common.c
>> i2c_init_board(), there is a I2C reset sequence for 83xx based boards
>> from keymile, which use this i2c driver.
>>
>> Maybe its time to move this code in the i2c driver?
>
> this code looks good except I do not see how the special case of
> multi-master systems you mentioned is handled.
I have no experience with multimaster systems, and I think, this
special case is not yet factored in code.
> I think for multi-master a timeout would have to be implemented to
> wait for a possible other master transfer to finish before initiating
> the abort sequence, or is this too much time spent during init?
Or, it could be detected? If BB Bit is set and the SCL pin doesn;t
alter, the I2C bus must be blocked ... just an idea.
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
next prev parent reply other threads:[~2010-01-21 11:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-19 20:50 [U-Boot] ColdFire I2C implementing I2C idle [PATCH] Michael Durrant
2010-01-20 8:26 ` Heiko Schocher
2010-01-20 18:33 ` [U-Boot] ColdFire I2C implementing I2C idle [PATCH] -- resent in git format Michael Durrant
2010-01-21 7:25 ` Heiko Schocher
2010-01-21 7:41 ` Joakim Tjernlund
2010-01-21 8:04 ` Heiko Schocher
2010-01-21 10:29 ` Wolfgang Wegner
2010-01-21 11:49 ` Heiko Schocher [this message]
2010-01-21 17:49 ` Michael Durrant
2010-01-25 8:17 ` Heiko Schocher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B583F45.8080900@denx.de \
--to=hs@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.