[PATCH v4 01/13] ASoC: Intel: Add catpt device

Cezary Rojewski cezary.rojewski at intel.com
Tue Aug 25 11:32:57 CEST 2020


On 2020-08-19 3:43 PM, Andy Shevchenko wrote:
> On Wed, Aug 19, 2020 at 03:26:04PM +0200, Cezary Rojewski wrote:
>> On 2020-08-18 12:07 PM, Andy Shevchenko wrote:
>>> On Mon, Aug 17, 2020 at 12:02:39PM +0200, Cezary Rojewski wrote:
>>>> On 2020-08-13 8:29 PM, Andy Shevchenko wrote:
>>>>> On Wed, Aug 12, 2020 at 10:57:41PM +0200, Cezary Rojewski wrote:

>>>>>> +#define CATPT_SSP_SSC0		0x0
>>>>>> +#define CATPT_SSP_SSC1		0x4
>>>>>> +#define CATPT_SSP_SSS		0x8
>>>>>> +#define CATPT_SSP_SSIT		0xC
>>>>>> +#define CATPT_SSP_SSD		0x10 and
>>>>>> +#define CATPT_SSP_SSTO		0x28
>>>>>> +#define CATPT_SSP_SSPSP		0x2C
>>>>>> +#define CATPT_SSP_SSTSA		0x30
>>>>>> +#define CATPT_SSP_SSRSA		0x34
>>>>>> +#define CATPT_SSP_SSTSS		0x38
>>>>>> +#define CATPT_SSP_SSC2		0x40
>>>>>> +#define CATPT_SSP_SSPSP2	0x44
>>>>>
>>>>> Isn't it PXA2xx register set? Can you use their definitions?
>>>>
>>>> Could you be more specific? Wasn't able to find anything useful in /include.
>>>
>>> include/linux/pxa2xx_ssp.h
>>
>> Did some reconnaissance and it while this registers are shared, LPT/WPT are
>> equipped with a newer version of said ssp device with some old
>> functionalities have been removed too. So the question comes down to: do I
>> re-use PXA2XX registers due to historical background (inheritance) -or-
>> leave it explicit as is. Honestly, I don't really mind either of these. Got
>> surprised by short register names in mentioned header though.
> 
> Short names are for historical reasons, but you may change them over the
> kernel, if you wish (I think you won't spend time on this).
> 
> My vision is to extend that header to cover changes and use it in your code.
> It might, though, require some cleanups to be done against pxa2xx_ssp.h.
> 

Conclusion from checking pxa2_ssp.h registers:

- SSPSP2 is missing (0x44)
- SSC2 vs SSACDD (0x40) both same offset but different purpose so 
probably new define would have to be added

As situation is similar to the resource-API case below are the options:
a) ship catpt with existing ssp reg set, update pxa2_ssp.h in following 
series and then re-use them for catpt
b) update pxa2_ssp.h first, await merge, ship catpt only afterward

I vote for option a) given the maturity driver is reaching plus I'd 
rather be done with sound/soc/intel/ sanitization sooner than later.

Czarek


More information about the Alsa-devel mailing list