linux-kernel - Re: [PATCH 3/3 v2] sound/soc/lapis: add platform driver for ML7213 IOH I2S

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]

Date:	Mon, 26 Dec 2011 15:33:29 +0900
From:	Tomoya MORINAGA <tomoya.rohm@...il.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Liam Girdwood <lrg@...com>, Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.de>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Dimitris Papastamos <dp@...nsource.wolfsonmicro.com>,
	Mike Frysinger <vapier@...too.org>,
	Daniel Mack <zonque@...il.com>, alsa-devel@...a-project.org,
	linux-kernel@...r.kernel.org, qi.wang@...el.com,
	yong.y.wang@...el.com, joel.clark@...el.com, kok.howg.ewe@...el.com
Subject: Re: [PATCH 3/3 v2] sound/soc/lapis: add platform driver for ML7213
 IOH I2S

2011/12/22 Mark Brown <broonie@...nsource.wolfsonmicro.com>:
> On Thu, Dec 22, 2011 at 05:10:24PM +0900, Tomoya MORINAGA wrote:
>
>> I can understand your saying.
>> However, in case of Tx interrupt, only ALMOST-EMPTY occurs. in case of
>> Rx, only Rx ALMOST-FULL occurs.
>> So as long as a user uses ML7213 I2S, your mentioned behavior is never happened.
>
> That's not what your code says...  it may be that the other interrupts
> are very rare but that's not the same thing.

I'll delete these except initialize() and transfer_complete().

>
>> They have the "filter" function immediately next to the code uses
>> "dma_request_channel".
>
> That's a rather large function...
>
>> Anyway, if you want me to change the name, I can change the name.
>> Please decide it.
>
> Rename.
I'll obey your opinion.

>
>> > You're implementing some sort of custom buffering in your driver?  That
>> > sounds terribly unidiomatic - pretty much all DMA drivers are very thin
>> > and manage to work well, I'd expect this is masking some problems in the
>> > code rather than anything else.  Can you provide more detail on what
>> > this is working around?
>
>> Not sorted but queuing only.
>> In sound/voice control system, queuing is not rare, I think.
>> If necessary, though this method is very common, I can send the method
>> of the queue.
>
> No, please describe the problem you're trying to fix.

When CPU is heavy load, this buffer is useful.
The heavy load causes delaying receiving processing.
If there is no buffer, stream sound/voice can be broken.
If there is the buffer, it can prevent the broken sound.

thanks,
tomoya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/