Re: Query about regmap SPI

Re: Query about regmap SPI

[Ashish Chavan]

On Tue, 2012-03-06 at 20:15 +0530, Ashish Chavan wrote:
> On Tue, Mar 06, 2012 at 12:53:51PM +0500, Ashish Chavan wrote:
> 

> Please always CC the relevant mailing lists on postings.  I shouldn't
> need to remind you about this stuff.

Yes, I agree :-(
It's my mistake that I missed linux-kernel@vger.kernel.org


> No, implementing stuff like this in individual device drivers rather
> defeats the point of having frameworks.  It sounds like it should be
> trivial to add support for this to regmap.

I also think that there should be a way to handle this kind of stuff by
the framework. May I know if you have any plan to add this to regmap? or
should I come up with a patch to extend regmap to support this and
propose you?

Re: Query about regmap SPI

[Mark Brown]

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

On Tue, Mar 06, 2012 at 08:38:52PM +0530, Ashish Chavan wrote:

> I also think that there should be a way to handle this kind of stuff by
> the framework. May I know if you have any plan to add this to regmap? or
> should I come up with a patch to extend regmap to support this and
> propose you?

I have no need for it so I'm unlikely to work on it myself, if you were
to send a patch that'd be great.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Query about regmap SPI

[Ashish Chavan]

On Tue, 2012-03-06 at 16:30 +0000, Mark Brown wrote:
> On Tue, Mar 06, 2012 at 08:38:52PM +0530, Ashish Chavan wrote:
> 
> > I also think that there should be a way to handle this kind of stuff by
> > the framework. May I know if you have any plan to add this to regmap? or
> > should I come up with a patch to extend regmap to support this and
> > propose you?
> 
> I have no need for it so I'm unlikely to work on it myself, if you were
> to send a patch that'd be great.

OK, I will go through regmap sources in detail to find out appropriate
place to put this. BTW do you have any recommendation in terms of a good
way to achieve this. e.g. will it be useful and generic enough if we
introduce two more fields like read/write_flag_mask to indicate shifting
and use those fields before applying read/write_flag_masks?

Re: Query about regmap SPI

[Mark Brown]

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

On Tue, Mar 06, 2012 at 11:04:12PM +0530, Ashish Chavan wrote:

> place to put this. BTW do you have any recommendation in terms of a good
> way to achieve this. e.g. will it be useful and generic enough if we
> introduce two more fields like read/write_flag_mask to indicate shifting
> and use those fields before applying read/write_flag_masks?

That sounds like a sensible approach.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Query about regmap SPI

[Ashish Chavan]

Hi,
  I am planning to add SPI support for da7210 codec driver. SPI for this
codec has slightly different format than others. It has 8 bit register
address and 8 bit data. Out of 8 bits of register address, one bit (i.e.
LSB) is used to indicate read or write. Value of 1 at LSB denotes READ
while value of 0 at LSB denotes write operation.

Thus in order for SPI READ to work correctly, the register address need
to be left shifted by one and then ORed with 0x1. In the same way for
SPI WRITE to work correctly, it need to be left shifted by one.

I have gone though the regmap sources and found that ORing can be
achieved by setting correct read_flag_mask. But I couldn't find anything
by which I can tell regmap core to shift the register address before
ORing it with read_flag_mask. Am I missing anything here?

Is there any other way to achieve this using regmap? The only other way
I can think of is providing a wrapper function to read and write in
codec driver and doing the shifting job inside that wrapper.

TIA!

Re: Query about regmap SPI

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 710 bytes --]

On Tue, Mar 06, 2012 at 12:53:51PM +0500, Ashish Chavan wrote:

>   I am planning to add SPI support for da7210 codec driver. SPI for this
> codec has slightly different format than others. It has 8 bit register

Please always CC the relevant mailing lists on postings.  I shouldn't
need to remind you about this stuff.

> Is there any other way to achieve this using regmap? The only other way
> I can think of is providing a wrapper function to read and write in
> codec driver and doing the shifting job inside that wrapper.

No, implementing stuff like this in individual device drivers rather
defeats the point of having frameworks.  It sounds like it should be
trivial to add support for this to regmap.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Query About regmap SPI

[Ashish Chavan]

Hi,
  I am planning to add SPI support for da7210 codec driver. SPI for this
codec has slightly different format than others. It has 8 bit register
address and 8 bit data. Out of 8 bits of register address, one bit (i.e.
LSB) is used to indicate read or write. Value of 1 at LSB denotes READ
while value of 0 at LSB denotes write operation.

Thus in order for SPI READ to work correctly, the register address need
to be left shifted by one and then ORed with 0x1. In the same way for
SPI WRITE to work correctly, it need to be left shifted by one.

I have gone though the regmap sources and found that ORing can be
achieved by setting correct read_flag_mask. But I couldn't find anything
by which I can tell regmap core to shift the register address before
ORing it with read_flag_mask. Am I missing anything here?

Is there any other way to achieve this using regmap? The only other way
I can think of is providing a wrapper function to read and write in
codec driver and doing the shifting job inside that wrapper.




This message contains information that may be privileged or confidential and is the property of the KPIT Cummins Infosystems Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Cummins Infosystems Ltd. does not accept any liability for virus infected mails.