From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755421AbbICMrF (ORCPT ); Thu, 3 Sep 2015 08:47:05 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:49844 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753881AbbICMrC (ORCPT ); Thu, 3 Sep 2015 08:47:02 -0400 Date: Thu, 3 Sep 2015 13:46:32 +0100 From: Mark Brown To: Qais Yousef Cc: alsa-devel@alsa-project.org, Liam Girdwood , Jaroslav Kysela , Takashi Iwai , linux-kernel@vger.kernel.org Message-ID: <20150903124632.GZ12027@sirena.org.uk> References: <1440419959-14315-1-git-send-email-qais.yousef@imgtec.com> <1440419959-14315-4-git-send-email-qais.yousef@imgtec.com> <20150826183700.GD28760@sirena.org.uk> <55DEFF77.8070309@imgtec.com> <20150827153233.GD5313@sirena.org.uk> <55E02871.9050607@imgtec.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vBrReJOVREFtblek" Content-Disposition: inline In-Reply-To: <55E02871.9050607@imgtec.com> X-Cookie: You are fairminded, just and loving. User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 87.112.220.204 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 03/10] ALSA: add AXD Audio Processing IP alsa driver X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --vBrReJOVREFtblek Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 28, 2015 at 10:22:57AM +0100, Qais Yousef wrote: > On 08/27/2015 04:32 PM, Mark Brown wrote: > >On Thu, Aug 27, 2015 at 01:15:51PM +0100, Qais Yousef wrote: > >>>>+#define AXD_BASE_VADDR 0xD0000000 > >>>This sounds like something that is going to be platform dependant, > >>>should this be supplied from board configuration? > >>I don't expect this to change. Can we add the configuration later if we hit > >>the need to change it? > >It should be trivial to make things configurable shouldn't it? > Yes and I am all with configurability but I don't think it makes sense here. > AXD will always have its own MMU and will not share virtual address space, > so the possibility of us wanting to move this somewhere else is really very > thin. Also I don't think this is the kind of detail we need to concern the > user with. I'll see if I can make the binary header parsing more flexible so > we can add more info like this and the one above in the future and be more > future proof. So this is a virtual address in the memory map of the DSP? That's not what I thought it was. > >>>>+ memcpy_toio((void *)cached_fw_base, fw->data, fw->size); > >>>Why the cast here? I'm also not seeing where we handled the copying to > >>>I/O in the decompression case? > >>I couldn't avoid the cast. If cached_fw_base is 'void *' I'll get a warning > >>when initialising cached_fw_base from CAC_ADDR(). > >Why do you get a warning from that? Perhaps the warnings are trying to > >tell us something... > Because we try to assign an int to a pointer. So the error is 'makes pointer > from integer without a cast'. To convert an address from uncached to cached > we need to convert to an int as in MIPS it's a case of adding or subtracting > a value then convert this value back to it's original form. > I'll see if I can find a better way to fix the coherency issue when we copy > through uncached. Why can't you just use pointer arithmmetic? > >>Good point. When decompressing crypto_comp_decompress() will write directly > >>to the memory. It is safe but it doesn't go through the correct API. Not > >>sure what I can do here. > >Uncompress to a buffer then write that buffer to the final destination? > Yes but the binary could be multi MiB so we can't get a temp buffer that > large. If the crypto API allows decompressing in steps we can use a small > buffer to move the data iteratively. I'll have a look. A few megabytes doesn't seem like that big an ask (it's not *nice* but it's doable with vmalloc()). Iteratively copying is nicer though. > >>>>+ /* wake up any task sleeping on command response */ > >>>>+ wake_up(&axd->cmd.wait); > >>>>+ /* give chance to user land tasks to react to the crash */ > >>>>+ ssleep(2); > >>>This looks horribly racy, I'd expect us to be trashing and/or killing > >>>off any active work and resources here. > >>OK. I was trying to play nicely by giving the chance to userland to repond > >>to -ERESTART which would be sent from aborting any pending reads/writes. > >>Are you suggesting to send SIGKILL using force_sig()? > >No, I'm suggesting tearing down the kernel side of any work and kicking > >errors back to userspace if it continues to interact with anything that > >was ongoing. > OK. This is what we do (see my other email about abort). I'll have a think > for a way to get rid of the ssleep(). Any ideas are welcome. Just delete it? --vBrReJOVREFtblek Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV6EEnAAoJECTWi3JdVIfQi+8H/0oJnPQov8/g/uFZcRDSDhAH ygEUWDxWikmTM/4VndZsh6F1dqATnDtojEQfrHm6yi3csD6EDqghQeWJD3OXoG6r 1HH1Sj0BxmjDSRzdwmRb212tgKFlwJNj0aBFGBZxBgZhAJAvsCwB5SNrD6pInjlR IffsRiaQ+gXd/6Pl9A5YsrcbX9n38y+jTwuGVzO/AzKaVr+UZkmAuv4ntLN8ua64 aufRwWc7WmSGubxGJdMA+Cg142Qolb4PlnqBPEXkP5ogSxK2avK4vysIQNFroU4L IxRnPVlhKllr2TQrZ/hrJQ6igDwf5asy9GCE8P2uGBCuL2faR/798StP4RAXCJo= =ON8Y -----END PGP SIGNATURE----- --vBrReJOVREFtblek--