From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756503Ab0JOQVO (ORCPT ); Fri, 15 Oct 2010 12:21:14 -0400 Received: from arroyo.ext.ti.com ([192.94.94.40]:34858 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754545Ab0JOQVM convert rfc822-to-8bit (ORCPT ); Fri, 15 Oct 2010 12:21:12 -0400 From: "Guzman Lugo, Fernando" To: Felipe Contreras CC: "gregkh@suse.de" , "felipe.contreras@nokia.com" , "ameya.palande@nokia.com" , "Menon, Nishanth" , "Hiroshi.DOYU@nokia.com" , "ohad@wizery.com" , "linux-kernel@vger.kernel.org" , "andy.shevchenko@gmail.com" , "linux-omap@vger.kernel.org" Date: Fri, 15 Oct 2010 11:21:06 -0500 Subject: RE: [PATCHv3 00/11] staging tidspbridge: iommu migration Thread-Topic: [PATCHv3 00/11] staging tidspbridge: iommu migration Thread-Index: ActrmyQ6A2nnEBsHS+Kg4mlNEpzPVgA6Xr9w Message-ID: <496565EC904933469F292DDA3F1663E602F48817EF@dlee06.ent.ti.com> References: <1286310944-25035-1-git-send-email-x0095840@ti.com> <496565EC904933469F292DDA3F1663E602F47B2BB1@dlee06.ent.ti.com> <496565EC904933469F292DDA3F1663E602F47B3002@dlee06.ent.ti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Felipe Contreras [mailto:felipe.contreras@gmail.com] > Sent: Thursday, October 14, 2010 7:27 AM > To: Guzman Lugo, Fernando > Cc: gregkh@suse.de; felipe.contreras@nokia.com; > ameya.palande@nokia.com; Menon, Nishanth; > Hiroshi.DOYU@nokia.com; ohad@wizery.com; > linux-kernel@vger.kernel.org; andy.shevchenko@gmail.com; > linux-omap@vger.kernel.org > Subject: Re: [PATCHv3 00/11] staging tidspbridge: iommu migration > > On Tue, Oct 12, 2010 at 5:39 PM, Guzman Lugo, Fernando > wrote: > >> On Mon, Oct 11, 2010 at 6:03 PM, Guzman Lugo, Fernando > >> wrote: > >> >> On Tue, Oct 5, 2010 at 11:35 PM, Fernando Guzman Lugo > >> >> wrote: > >> >> > This set of patches remove the dspbridge custom mmu > >> >> implementation and > >> >> > use iommu module instead. > >> >> > >> >> I have tried this, it works for simple tests, but not real > >> use-cases. > >> >> I applied all your iommu patches. How did you test this? > >> > > >> > Have you applied: > >> > > >> > - "scatterlist: define SG chain for arm architecture" > >> > - "iovmm: replace __iounmap with omap_iounmap" > >> > - "iovmm: add superpages support to fixed da address" > >> > - "iovmm: IVA2 MMU range is from 0x11000000 to 0xFFFFFFFF" > >> > - "iovmm: no gap checking for fixed address" > >> > >> Yes. > >> > >> > Also make sure your baseline have this patch: > >> > > >> > - "omap:iommu-load cam register before flushing the entry" > >> > >> Huh? That's not even in v2.6.36-rc7, in which baseline is this > >> supposed to be in? Anyway, I'll try adding that. > > > > That's is in latest Hiroshi's tree and it is really needed, > Otherwise > > You will have wrong traslations which can cause unexpected behavior. > > Now I applied that, still fails. > > >> > What kind of error are you getting? > >> > >> Node allocation failing IIRC. > > > > Is it falling to map the Heap?? > > I mean you see this trace? > > > >        if (status) > >                pr_err("%s: Failed to map memory for Heap: 0x%x\n", > >                       __func__, status); > > > > Otherwise, I don't see how that fail is related with iommu changes. > > Nope. > > >> > I don't have a complete framework to test MM testcases at > >> this moment > >> > >> See: > >> http://felipec.wordpress.com/2010/10/08/my-arm-development-notes/ > >> > >> I even prepared a tarball so you just need to extract it on your > >> device. It's not difficult to test this with GStreamer, > and I don't > >> see how you can be confident that they indeed work without testing > >> some real use-cases. Anyway, I'll try that missing patch. > > > > Most of time real use-cases are not so stressing like > testcases We can > > make to test under real stress in order to find out corner cases. > > However when I test it was pretty stable and just few erros because > > staging Does not have latest mailbox patches. Also I test > in a .35 version of staging. > > So now I am using a branch with all new patches and I will > recheck and > > test Again any possible issue. Also I will look at your > gstreamer fail too. > > Well, in my experience it's the other way around, the stress > test-cases don't catch the errors that happen on real > use-case scenarios, no matter how extensive they are. This is > a good example. I am facing some unstability with the latest bridge merge. I am looing into That once it is stable I wil check you testcase too to confirm everything is Working fine. Thanks, Fernando. > > Cheers. > > -- > Felipe Contreras >