All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Cezary Rojewski <cezary.rojewski@intel.com>
Cc: pierre-louis.bossart@linux.intel.com,
	alsa-devel@alsa-project.org, filip.kaczmarski@intel.com,
	harshapriya.n@intel.com, marcin.barlik@intel.com,
	zwisler@google.com, lgirdwood@gmail.com, tiwai@suse.com,
	filip.proborszcz@intel.com, broonie@kernel.org,
	amadeuszx.slawinski@linux.intel.com, michal.wasko@intel.com,
	cujomalainey@chromium.org, krzysztof.hejmowski@intel.com,
	ppapierkowski@habana.ai, vamshi.krishna.gopal@intel.com
Subject: Re: [PATCH v4 01/13] ASoC: Intel: Add catpt device
Date: Wed, 19 Aug 2020 16:43:23 +0300	[thread overview]
Message-ID: <20200819134323.GM1891694@smile.fi.intel.com> (raw)
In-Reply-To: <7cd5fa73-797e-17c3-4b7c-7635a18c59af@intel.com>

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:

...

> And this is a very good approach. Thought device_get_match_data is 'heavier'
> than the devm_kzalloc.

Memory allocation in 90% cases are heavier then the rest (because of page fault
exceptions).

...

> I did some testing today and indeed very simple approach suffices:
> - devm_platform_get_and_ioremap_resource for DSP bar
> - devm_platform_ioremap_resource for PCI bar
> - instead of doing devm_ioremap_resource() separately for dmac in
> catpt_dmac_probe(), just do:
> 
> dmac->regs = cdev->lpe_ba + cdev->spec->host_dma_offset[<engine id>]

Yes, something like this. Basically what you have is particular case of MFD
(see drivers/mfd for other uses).

...

> > > > > +#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.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2020-08-19 13:44 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-12 20:57 [PATCH v4 00/13] ASoC: Intel: Catpt - Lynx and Wildcat point Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 01/13] ASoC: Intel: Add catpt device Cezary Rojewski
2020-08-13 18:29   ` Andy Shevchenko
2020-08-17 10:02     ` Cezary Rojewski
2020-08-18 10:07       ` Andy Shevchenko
2020-08-19 13:26         ` Cezary Rojewski
2020-08-19 13:43           ` Andy Shevchenko [this message]
2020-08-25  9:32             ` Cezary Rojewski
2020-08-25 13:18               ` Andy Shevchenko
2020-08-25 13:19                 ` Andy Shevchenko
2020-08-25 20:43       ` Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 02/13] ASoC: Intel: catpt: Define DSP operations Cezary Rojewski
2020-08-13 18:51   ` Andy Shevchenko
2020-08-17 11:12     ` Cezary Rojewski
2020-08-18 11:50       ` Andy Shevchenko
2020-08-19 13:46         ` Cezary Rojewski
2020-08-19 14:21           ` Andy Shevchenko
2020-08-19 14:54             ` Cezary Rojewski
2020-08-20  7:30       ` Cezary Rojewski
2020-08-20  9:00         ` Andy Shevchenko
2020-08-24 16:33           ` Cezary Rojewski
2020-08-25 13:16             ` Andy Shevchenko
2020-08-25 13:23               ` Andy Shevchenko
2020-08-27 10:06               ` Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 03/13] ASoC: Intel: catpt: Firmware loading and context restore Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 04/13] ASoC: Intel: catpt: Implement IPC protocol Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 05/13] ASoC: Intel: catpt: Add IPC messages Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 06/13] ASoC: Intel: catpt: PCM operations Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 07/13] ASoC: Intel: catpt: Event tracing Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 08/13] ASoC: Intel: catpt: Simple sysfs attributes Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 09/13] ASoC: Intel: Select catpt and deprecate haswell Cezary Rojewski
2020-08-12 20:57 ` [PATCH v4 10/13] ASoC: Intel: haswell: Remove haswell-solution specific code Cezary Rojewski
2020-08-13 18:57   ` Andy Shevchenko
2020-08-12 20:57 ` [PATCH v4 11/13] ASoC: Intel: broadwell: " Cezary Rojewski
2020-08-13 18:56   ` Andy Shevchenko
2020-08-12 20:57 ` [PATCH v4 12/13] ASoC: Intel: bdw-5650: " Cezary Rojewski
2020-08-13 18:56   ` Andy Shevchenko
2020-08-12 20:57 ` [PATCH v4 13/13] ASoC: Intel: bdw-5677: " Cezary Rojewski
2020-08-13 18:57   ` Andy Shevchenko
2020-08-13  8:30 ` [PATCH v4 00/13] ASoC: Intel: Catpt - Lynx and Wildcat point Amadeusz Sławiński
2020-08-13 16:00 ` Liam Girdwood
2020-08-13 18:11   ` Cezary Rojewski
2020-08-13 19:03     ` Liam Girdwood

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=20200819134323.GM1891694@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=cujomalainey@chromium.org \
    --cc=filip.kaczmarski@intel.com \
    --cc=filip.proborszcz@intel.com \
    --cc=harshapriya.n@intel.com \
    --cc=krzysztof.hejmowski@intel.com \
    --cc=lgirdwood@gmail.com \
    --cc=marcin.barlik@intel.com \
    --cc=michal.wasko@intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=ppapierkowski@habana.ai \
    --cc=tiwai@suse.com \
    --cc=vamshi.krishna.gopal@intel.com \
    --cc=zwisler@google.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.