From: Peter Rosin <peda@axentia.se>
To: Ajay Gupta <ajayg@nvidia.com>,
"wsa@the-dreams.de" <wsa@the-dreams.de>,
"heikki.krogerus@linux.intel.com"
<heikki.krogerus@linux.intel.com>
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: [v9,1/2] i2c: buses: add i2c bus driver for NVIDIA GPU
Date: Sat, 08 Sep 2018 07:20:26 +0200 [thread overview]
Message-ID: <5254644A-E11F-41FD-AD53-A41DBE1817D0@axentia.se> (raw)
On September 7, 2018 11:48:37 PM GMT+02:00, Ajay Gupta <ajayg@nvidia.com> wrote:
>> >> Per your comments on v8, the address has to be programmed before
>the
>> >> transfer, but you fail to do that if the first message is a read.
>> > This will never happen. Hint: I2C_AQ_COMB_WRITE_FIRST
>>
>> Yes, it will. If the transfer consists of a single read, i.e. w/o any
>leading write.
>> E.g. i2c_smbus_read_byte (which is emulated in your case and will
>generate
>> this pattern).
>I don't think we intend to support SMBUS commands and so I will drop
>I2C_FUNC_SMBUS_EMUL.
SMBUS has nothing to do with the problem, that was just an example. An I2C client driver can issue such I2C xfers all by itself without going through emulation, so just dropping the _EMUL flag is not the answer. And I'd be surprised if the hardware doesn't support single message reads.
There is no quirk flag for this abnormality, so you will have to open code the check in your master_xfer if you can't make such xfers work, but the best fix is certainly to just make them work...
Cheers,
Peter
next reply other threads:[~2018-09-08 5:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-08 5:20 Peter Rosin [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-09-08 14:33 [v9,1/2] i2c: buses: add i2c bus driver for NVIDIA GPU Peter Rosin
2018-09-08 14:13 Ajay Gupta
2018-09-07 21:48 Ajay Gupta
2018-09-07 17:46 Peter Rosin
2018-09-07 17:15 Ajay Gupta
2018-09-07 9:11 Peter Rosin
2018-09-06 23:56 Ajay Gupta
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=5254644A-E11F-41FD-AD53-A41DBE1817D0@axentia.se \
--to=peda@axentia.se \
--cc=ajayg@nvidia.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--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.