Re: [PATCH v4 02/13] ASoC: Intel: catpt: Define DSP operations

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

 



On Tue, Aug 25, 2020 at 04:16:15PM +0300, Andy Shevchenko wrote:
> On Mon, Aug 24, 2020 at 06:33:17PM +0200, Cezary Rojewski wrote:
> > On 2020-08-20 11:00 AM, Andy Shevchenko wrote:

...

> > Another question though: PCI_PM_CTRL. In order for me to make use of this,
> > "pm_cap" member would have to be declared for my device. As this is no
> > struct pci_dev, catpt has currently no separate member for that purpose. I
> > don't believe you want me to add that field into struct's declaration.
> > Second option is to define constant for pm_cap offset aka 0x80 within
> > registers.h and then do the operations as follows:
> > 	catpt_updatel_pci(cdev, CATPT_PM_CAP + PCI_PM_CTRL, ...)
> 
> > However, in such case I won't be able to make use of current version of
> > _updatel_pci() as definition of that macro allows me to skip prefix and type
> > implicitly - PMCS (the rest is appended automatically).
> > Maybe let's leave it within registers.h altogether so I can actually keep
> > using said macro?
> 
> Basically what you do with accessing PCI configuration space via these methods
> (catpt_update_pci(), etc) is something repetitive / similar to what xHCI DbC
> support code does. I recommend to spend some time to look for similarities here
> (catpt) and there (PCI core, xHCI DbC, etc) and, if we were lucky, derive
> common helpers for traverse the capability list in more generalized way.

Throwing the idea loud: perhaps we may have something like regmap-pci.c to
access PCI configuration space and make regmap API to take care of which IO
accessors (and locking) will be used.

-- 
With Best Regards,
Andy Shevchenko





[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux