All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
To: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
Cc: "Wolfram Sang" <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>,
	"Michal Simek"
	<michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Kedareswara rao Appana"
	<appana.durga.rao-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>,
	"Kedareswara rao Appana"
	<appanad-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>,
	"Jean Delvare" <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>,
	"Peter Korsgaard"
	<jacmet-OfajU3CKLf1/SzgSGea1oA@public.gmane.org>,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Richard Röjfors"
	<richard.rojfors-gfIc91nka+FZroRs9YW3xA@public.gmane.org>,
	"Steven A. Falco"
	<sfalco-7/gz0mrWfc7QT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH v2 2/3] i2c: xilinx: Set tx direction in write operation
Date: Fri, 04 Oct 2013 15:38:01 +0200	[thread overview]
Message-ID: <524EC4B9.7000202@monstr.eu> (raw)
In-Reply-To: <524EC4DC.1020708-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 3103 bytes --]

On 10/04/2013 03:38 PM, Lars-Peter Clausen wrote:
> On 10/04/2013 03:09 PM, Michal Simek wrote:
>>
>>
>> On 10/04/2013 02:12 PM, Lars-Peter Clausen wrote:
>>> On 10/04/2013 01:55 PM, Wolfram Sang wrote:
>>>> On Fri, Oct 04, 2013 at 11:53:49AM +0200, Michal Simek wrote:
>>>>> On 10/04/2013 07:46 AM, Wolfram Sang wrote:
>>>>>>
>>>>>>> +	cr = xiic_getreg32(i2c, XIIC_CR_REG_OFFSET);
>>>>>>> +	cr |= XIIC_CR_DIR_IS_TX_MASK;
>>>>>>> +	xiic_setreg32(i2c, XIIC_CR_REG_OFFSET, cr);
>>>>>>> +
>>>>>>
>>>>>> Is there no need to clear the bit again when receiving?
>>>>>
>>>>> This bit is cleared in xiic_xfer() -> xiic_start_xfer() ->xiic_reinit()
>>>>>
>>>>> xiic_setreg8(i2c, XIIC_CR_REG_OFFSET, XIIC_CR_TX_FIFO_RESET_MASK);
>>>>
>>>> A bit implicit, but OK.
>>>>
>>>>>> And did
>>>>>> transferring ever work if this bit was never set before?
>>>>>
>>>>> I really don't know. We have switched from old driver to this new mainline one
>>>>> and based on our eeprom testing we have found that this bit hasn't been setup properly.
>>>>>
>>>>> It is described here.
>>>>> http://www.xilinx.com/support/documentation/ip_documentation/axi_iic/v1_02_a/axi_iic_ds756.pdf
>>>>> page 28 - step 3.
>>>>>
>>>>> IIC Master Transmitter with a Repeated Start
>>>>> 1. Write the IIC device address to the TX_FIFO.
>>>>> 2. Write data to TX_FIFO.
>>>>> 3. Write to Control Register (CR) to set MSMS = 1 and TX = 1.
>>>>> 4. Continue writing data to TX_FIFO.
>>>>> 5. Wait for transmit FIFO empty interrupt. This implies the IIC has throttled the bus.
>>>>> 6. Write to CR to set RSTA = 1.
>>>>
>>>> Repeated start is not happening in the driver as well, or am I
>>>> overlooking something?
>>>>
>>>>> 7. Write IIC device address to TX_FIFO.
>>>>> 8. Write all data except last byte to TX_FIFO.
>>>>> 9. Wait for transmit FIFO empty interrupt. This implies the IIC has throttled the bus.
>>>>> 10. Write to CR to set MSMS = 0. The IIC generates a stop condition at the end of the last byte.
>>>>> 11. Write last byte of data to TX_FIFO.
>>>>
>>>> CCing more people who worked on the driver in the past and might have
>>>> experiences
>>>
>>> The current version works fine here. The driver uses whats described in the
>>> datasheet as "dynamic controller logic flow" and not the "standard
>>> controller logic flow". The sequence Michal mentioned above is from the
>>> "standard controller logic flow" section.
>>
>> Does this change break "dynamic controller logic flow"?
> 
> Not sure, but I would assume that the bit is ignored in this mode. But I
> don't think the patch should be applied since this step is not in the
> sequence of steps that should be done.

Kedar: Can you please look at both these modes and provide feedback?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Michal Simek <monstr@monstr.eu>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: "Wolfram Sang" <wsa@the-dreams.de>,
	"Michal Simek" <michal.simek@xilinx.com>,
	linux-kernel@vger.kernel.org,
	"Kedareswara rao Appana" <appana.durga.rao@xilinx.com>,
	"Kedareswara rao Appana" <appanad@xilinx.com>,
	"Jean Delvare" <khali@linux-fr.org>,
	"Peter Korsgaard" <jacmet@sunsite.dk>,
	linux-i2c@vger.kernel.org,
	"Richard Röjfors" <richard.rojfors@pelagicore.com>,
	"Steven A. Falco" <sfalco@harris.com>
Subject: Re: [PATCH v2 2/3] i2c: xilinx: Set tx direction in write operation
Date: Fri, 04 Oct 2013 15:38:01 +0200	[thread overview]
Message-ID: <524EC4B9.7000202@monstr.eu> (raw)
In-Reply-To: <524EC4DC.1020708@metafoo.de>

[-- Attachment #1: Type: text/plain, Size: 3103 bytes --]

On 10/04/2013 03:38 PM, Lars-Peter Clausen wrote:
> On 10/04/2013 03:09 PM, Michal Simek wrote:
>>
>>
>> On 10/04/2013 02:12 PM, Lars-Peter Clausen wrote:
>>> On 10/04/2013 01:55 PM, Wolfram Sang wrote:
>>>> On Fri, Oct 04, 2013 at 11:53:49AM +0200, Michal Simek wrote:
>>>>> On 10/04/2013 07:46 AM, Wolfram Sang wrote:
>>>>>>
>>>>>>> +	cr = xiic_getreg32(i2c, XIIC_CR_REG_OFFSET);
>>>>>>> +	cr |= XIIC_CR_DIR_IS_TX_MASK;
>>>>>>> +	xiic_setreg32(i2c, XIIC_CR_REG_OFFSET, cr);
>>>>>>> +
>>>>>>
>>>>>> Is there no need to clear the bit again when receiving?
>>>>>
>>>>> This bit is cleared in xiic_xfer() -> xiic_start_xfer() ->xiic_reinit()
>>>>>
>>>>> xiic_setreg8(i2c, XIIC_CR_REG_OFFSET, XIIC_CR_TX_FIFO_RESET_MASK);
>>>>
>>>> A bit implicit, but OK.
>>>>
>>>>>> And did
>>>>>> transferring ever work if this bit was never set before?
>>>>>
>>>>> I really don't know. We have switched from old driver to this new mainline one
>>>>> and based on our eeprom testing we have found that this bit hasn't been setup properly.
>>>>>
>>>>> It is described here.
>>>>> http://www.xilinx.com/support/documentation/ip_documentation/axi_iic/v1_02_a/axi_iic_ds756.pdf
>>>>> page 28 - step 3.
>>>>>
>>>>> IIC Master Transmitter with a Repeated Start
>>>>> 1. Write the IIC device address to the TX_FIFO.
>>>>> 2. Write data to TX_FIFO.
>>>>> 3. Write to Control Register (CR) to set MSMS = 1 and TX = 1.
>>>>> 4. Continue writing data to TX_FIFO.
>>>>> 5. Wait for transmit FIFO empty interrupt. This implies the IIC has throttled the bus.
>>>>> 6. Write to CR to set RSTA = 1.
>>>>
>>>> Repeated start is not happening in the driver as well, or am I
>>>> overlooking something?
>>>>
>>>>> 7. Write IIC device address to TX_FIFO.
>>>>> 8. Write all data except last byte to TX_FIFO.
>>>>> 9. Wait for transmit FIFO empty interrupt. This implies the IIC has throttled the bus.
>>>>> 10. Write to CR to set MSMS = 0. The IIC generates a stop condition at the end of the last byte.
>>>>> 11. Write last byte of data to TX_FIFO.
>>>>
>>>> CCing more people who worked on the driver in the past and might have
>>>> experiences
>>>
>>> The current version works fine here. The driver uses whats described in the
>>> datasheet as "dynamic controller logic flow" and not the "standard
>>> controller logic flow". The sequence Michal mentioned above is from the
>>> "standard controller logic flow" section.
>>
>> Does this change break "dynamic controller logic flow"?
> 
> Not sure, but I would assume that the bit is ignored in this mode. But I
> don't think the patch should be applied since this step is not in the
> sequence of steps that should be done.

Kedar: Can you please look at both these modes and provide feedback?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  parent reply	other threads:[~2013-10-04 13:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-30 14:15 [PATCH v2 1/3] i2c: xilinx: Fix i2c checkpatch warnings Michal Simek
2013-09-30 14:15 ` Michal Simek
2013-09-30 14:15 ` [PATCH v2 2/3] i2c: xilinx: Set tx direction in write operation Michal Simek
     [not found]   ` <57a4f5352ce6f03bde7aafe8b880f91b52994379.1380550490.git.michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
2013-10-04  5:46     ` Wolfram Sang
2013-10-04  5:46       ` Wolfram Sang
2013-10-04  9:53       ` Michal Simek
2013-10-04  9:53         ` Michal Simek
     [not found]         ` <524E902D.8030809-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
2013-10-04 11:55           ` Wolfram Sang
2013-10-04 11:55             ` Wolfram Sang
2013-10-04 12:12             ` Lars-Peter Clausen
     [not found]               ` <524EB090.2070708-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
2013-10-04 13:09                 ` Michal Simek
2013-10-04 13:09                   ` Michal Simek
     [not found]                   ` <524EBDF6.1070605-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
2013-10-04 13:38                     ` Lars-Peter Clausen
2013-10-04 13:38                       ` Lars-Peter Clausen
     [not found]                       ` <524EC4DC.1020708-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
2013-10-04 13:38                         ` Michal Simek [this message]
2013-10-04 13:38                           ` Michal Simek
     [not found]                           ` <524EC4B9.7000202-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
2013-10-07  9:19                             ` Appana Durga Kedareswara Rao
2013-10-07  9:19                               ` Appana Durga Kedareswara Rao
     [not found] ` <f3fd6f38d2553e59b077edff1969f4d07f8aa811.1380550490.git.michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
2013-09-30 14:15   ` [PATCH v2 3/3] i2c: xilinx: Use devm_* functions Michal Simek
2013-09-30 14:15     ` Michal Simek
     [not found]     ` <83ec9558211389896f21d9682e9824cd7979466c.1380550490.git.michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
2013-10-04  5:33       ` Wolfram Sang
2013-10-04  5:33         ` Wolfram Sang
2013-10-04  9:16         ` Michal Simek
2013-10-04  9:16           ` Michal Simek
2013-10-04 11:58           ` Wolfram Sang
2013-10-04 12:04             ` Michal Simek
2013-10-04 12:04               ` Michal Simek
2013-10-05  5:59               ` Wolfram Sang

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=524EC4B9.7000202@monstr.eu \
    --to=monstr-psz03upnqpehxe+lvdladg@public.gmane.org \
    --cc=appana.durga.rao-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org \
    --cc=appanad-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org \
    --cc=jacmet-OfajU3CKLf1/SzgSGea1oA@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
    --cc=lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org \
    --cc=richard.rojfors-gfIc91nka+FZroRs9YW3xA@public.gmane.org \
    --cc=sfalco-7/gz0mrWfc7QT0dZR+AlfA@public.gmane.org \
    --cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org \
    /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.