All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Reid <preid@electromag.com.au>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	linux-i2c@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	kernel@pengutronix.de,
	Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFT 1/6] i2c: designware: use open drain for recovery GPIO
Date: Wed, 25 Jul 2018 11:26:29 +0800	[thread overview]
Message-ID: <4163910a-f37b-5987-ecc2-074cebda753b@electromag.com.au> (raw)
In-Reply-To: <20180724072637.smhlrx4kpyh6hvwa@ninjato>

On 24/07/2018 15:26, Wolfram Sang wrote:
> Hi Phil,
> 
>>> So, it is not possible to read SCL status then? Hmm, currently a working
>>> get_scl is required...
> ...
>>> Well, I don't know much about this IP core and how/where it is used. I
>>> just wonder what happens if another user comes along using an
>>> open-drain GPIO. Is that possible?
>>>
>>> I assume it is the same with SDA? Non open-drain? Output only?
>>>
>>
>> Just had a closer look at how it's setup here.
>> Maybe the following helps.
> 
> Thanks for the detailed explanation. I am just afraid it is a litle too
> detailed for me. I am not sure if I can read it correctly:
> 
> When you read the SCL/SDA GPIO, does it return the true state of the
> SCL/SDA line or does it just reflect the value it was set to output?
Yes it returns the true state of the output pin.
I admit it's a bit odd from the classic GPIO point of view.

> 
>> There's no concept of HiZ internally in the FPGA.
> 
> Which probably means SDA is to be treated the same as SCL -> push/pull.
Yes. They're both driven push/pull, but the try state of the line is available.

> 
>> If there was some kinda of OpenDrain gpio driver that modelled a FET
>> driven by a push pull GPIO I guess it could be made to work.
> 
> Still, that sounds quite unlikely to me, so we can for now assume that
> all designware users will have push/pull?
I know of one other doing the same thing with the core in the Altera SocFPGA platform.
As they put me on to this solution for doing the recovery when the i2c was routed thru the SOC's fpga.

In other hard configurations they may have a 'proper' GPIO available that needs to be OpenDrain.



> 
> Disclaimer: I have zero experience with this core, I don't know how hard
> it is to modify or which versions are out there.
> 


-- 
Regards
Phil Reid

  reply	other threads:[~2018-07-25  3:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-13 21:09 [PATCH/RFT 0/6] i2c: recovery: fix GPIO usage for recovery Wolfram Sang
2018-07-13 21:09 ` Wolfram Sang
2018-07-13 21:09 ` Wolfram Sang
2018-07-13 21:09 ` [PATCH/RFT 1/6] i2c: designware: use open drain for recovery GPIO Wolfram Sang
2018-07-16  0:47   ` Phil Reid
2018-07-17  9:09     ` Wolfram Sang
2018-07-17  9:27       ` Phil Reid
2018-07-24  7:26         ` Wolfram Sang
2018-07-25  3:26           ` Phil Reid [this message]
2018-07-13 21:09 ` [PATCH/RFT 2/6] i2c: imx: " Wolfram Sang
2018-07-23 12:47   ` Lucas Stach
2018-07-24  7:28     ` Wolfram Sang
2018-07-24 13:01   ` Wolfram Sang
2018-07-13 21:09 ` [PATCH/RFT 3/6] i2c: designware: set SDA as output for recovery Wolfram Sang
2018-07-13 21:09 ` [PATCH/RFT 4/6] i2c: davinci: " Wolfram Sang
2018-07-13 21:09   ` Wolfram Sang
2018-07-13 21:09 ` [PATCH/RFT 5/6] i2c: imx: " Wolfram Sang
2018-07-13 21:09 ` [PATCH/RFT 6/6] i2c: recovery: remove bogus check if SDA GPIO is set to output Wolfram Sang
2018-07-16  9:29   ` Ulrich Hecht

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=4163910a-f37b-5987-ecc2-074cebda753b@electromag.com.au \
    --to=preid@electromag.com.au \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=wsa@the-dreams.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.