From: Rob Herring <robh@kernel.org>
To: Aswath Govindraju <a-govindraju@ti.com>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Vadym Kochan <vadym.kochan@plvision.eu>,
Vignesh Raghavendra <vigneshr@ti.com>,
Sekhar Nori <nsekhar@ti.com>
Subject: Re: [PATCH RFC 1/2] Documentation: devicetree: Add property for ignoring the dummy bits sent before read transfer
Date: Mon, 14 Dec 2020 16:23:39 -0600 [thread overview]
Message-ID: <20201214222339.GA2471866@robh.at.kernel.org> (raw)
In-Reply-To: <70d6c152-5d8d-9ad6-ce06-95a9f599c492@ti.com>
On Fri, Dec 11, 2020 at 08:34:57PM +0530, Aswath Govindraju wrote:
> Hi,
> On 11/12/20 9:03 am, Rob Herring wrote:
> > On Wed, Dec 09, 2020 at 11:27:07PM +0530, Aswath Govindraju wrote:
> >> Dummy zero bits are sent before data during a read transfer. This causes
> >> the data read to be shifted to the right. To fix this send zero bits after
> >> the address during a read transfer.
> >>
> >> Add property to send zero bits after the address during a read transfer.
> >
> > When is this necessary? Why can't it be implied by the compatible
> > string which should be specific to the chip model?
> >
>
> This is necessary for 93AA46A/B/C, 93LC46A/B/C, 93C46A/B/C eeproms, as
> it can be seen in section 2.7 of [1]. We were not sure if these were the
> only devices supported by the driver(eeprom_93xx46.c). So, in order to
> apply this only to the above listed devices, we thought that it would be
> better to apply this change when required by introducing a DT property.
>
> May I know how has this case been handled till now ??
>
No idea. From the at93c46d (which has a compatible string) datasheet it
looks like it has the same thing.
> If this is required by all the devices then we can drop the property and
> include the zero bit by default.
Looks like you need a combination of compatible strings for the above
devices and a property for the ORG pin state on the C devices. I assume
s/w needs to know if x8 or x16?
Rob
next prev parent reply other threads:[~2020-12-14 22:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 17:57 [PATCH RFC 0/2] eeprom: eeprom_93xx46: Add support for sending zero bits after address during read transfer Aswath Govindraju
2020-12-09 17:57 ` [PATCH RFC 1/2] Documentation: devicetree: Add property for ignoring the dummy bits sent before " Aswath Govindraju
2020-12-11 3:33 ` Rob Herring
2020-12-11 15:04 ` Aswath Govindraju
2020-12-14 22:23 ` Rob Herring [this message]
2020-12-15 16:12 ` Aswath Govindraju
2020-12-17 13:48 ` Aswath Govindraju
2020-12-17 15:48 ` Rob Herring
2020-12-17 16:02 ` Aswath Govindraju
2020-12-09 17:57 ` [PATCH RFC 2/2] eeprom: eeprom_93xx46: Add support for ignoring the dummy bit preceding data during " Aswath Govindraju
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=20201214222339.GA2471866@robh.at.kernel.org \
--to=robh@kernel.org \
--cc=a-govindraju@ti.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=vadym.kochan@plvision.eu \
--cc=vigneshr@ti.com \
/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.