On Mon, 14 Oct 2024 14:24:02 +0200,
Ryan Roberts wrote:
>
> On 14/10/2024 12:38, Mark Brown wrote:
> > On Mon, Oct 14, 2024 at 11:58:29AM +0100, Ryan Roberts wrote:
> >> -static const struct snd_pcm_hardware dummy_dma_hardware = {
> >> +static DEFINE_GLOBAL_PAGE_SIZE_VAR_CONST(struct snd_pcm_hardware, dummy_dma_hardware, {
> >> /* Random values to keep userspace happy when checking constraints */
> >> .info = SNDRV_PCM_INFO_INTERLEAVED |
> >> SNDRV_PCM_INFO_BLOCK_TRANSFER,
> >> @@ -107,7 +107,7 @@ static const struct snd_pcm_hardware dummy_dma_hardware = {
> >> .period_bytes_max = PAGE_SIZE*2,
> >> .periods_min = 2,
> >> .periods_max = 128,
> >> -};
> >> +});
> >
> > It's probably better to just use PAGE_SIZE_MAX here and avoid the
> > deferred patching, like the comment says we don't particularly care what
> > the value actually is here given that it's a dummy.
>
> OK, so would that be:
>
> .buffer_bytes_max = 128*1024,
> .period_bytes_min = PAGE_SIZE_MAX, <<<<<
> .period_bytes_max = PAGE_SIZE_MAX*2, <<<<<
> .periods_min = 2,
> .periods_max = 128,
>
> ?
>
> It's not really clear to me how all the parameters interact; the buffer size
> 128K, which, if PAGE_SIZE_MAX is 64K, would hold 1 period of the maximum size.
> But periods_min is 2. So not sure that works? Or perhaps I'm trying to apply too
> much meaning to the param names...
Right, when PAGE_SIZE_MAX is 64k, 128k won't be used because of the
constrant of periods_min=2.
As Mark mentioned, here the actual size itself doesn't matter much.
So I suppose it'd be even simpler to define just 4096 and 4096 * 2 for
period_bytes_min and *_max instead of sticking with PAGE_SIZE. Then
it would become platform-agnostic, too.
thanks,
Takashi
