linux-kernel - Re: [alsa-devel] [PATCH linux-next v2 9/9] ASoC: rsnd: add busif property to dai stream

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87pnwqpeni.wl-kuninori.morimoto.gx@renesas.com>
Date:   Thu, 4 Oct 2018 03:43:35 +0000
From:   Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
To:     Jiada Wang <jiada_wang@...tor.com>
Cc:     <lgirdwood@...il.com>, <broonie@...nel.org>, <perex@...ex.cz>,
        <tiwai@...e.com>, <alsa-devel@...a-project.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] [PATCH linux-next v2 9/9] ASoC: rsnd: add busif property to dai stream


Hi Jiada

Thank you for your feedback

> >> in GEN3 SSI may use different BUSIF for data transfer,
> >> this patch adds busif property to each dai stream,
> >> to indicate the BUSIF used by playback/capture stream.
> >> 
> >> Also adds rsnd_ssi_select_busif() to automatically select
> >> BUSIF (currently only BUSIF0 is selected)
> >> 
> >> Signed-off-by: Jiada Wang <jiada_wang@...tor.com>
> >> ---
(snip)
> > And this patch selects it on runtime (= hw_param) ?
> Because, in order to automatically determine BUSIF number,
> information like SSI mode (non-Split/Split/Ex-Split), runtime channel,
> are required
> (in our internal implementation, SSI mode is selected by kctrl)
> because of this, in this patch, BUSIF is selected on runtime
> 
> > But, I think we can/should select it on probe timing from DT connection.
> > Am I misunderstanding ?
> with the above reasoning, BUSIF is selected on runtime.
> what do you think?

I have no objection that you are customizing your kernel locally.
But, upstreaming kernel based on it is not acceptable for me.
I'm not sure detail of your local implementation, but I don't think we
need to select SSI mode by kctrl.
If my understanding was correct, it can also be selected automatically somehow.
Or, am I misunderstanding ?

I could understand what you want to do, and yes, I can agree that we want/need
to have it on upstream. Thank you very much to indicating it to me.
But we need to consider more how to implement it.
Especially, it is related to DT bindings.
As you already know, if it is implemented on upstream kernel, we need to keep
compatibility in the future, and it is very difficult.

So, my opinions for BUSIFn support are
	- SSI mode should be selected automatically
	- BUSIFn connection should be selected on DT
	  (I think we don't want random sound output position ?)
	  - To select it, we need to have new "ssiu" DT seetings,
	    or parse sound card. Maybe adding ssiu is realistic.


Best regards
---
Kuninori Morimoto