Re: [PATCH RFC 1/2] Documentation: devicetree: Add property for ignoring the dummy bits sent before read transfer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux