Re: [PATCHv3 00/11] staging tidspbridge: iommu migration

[Felipe Contreras]

On Tue, Oct 12, 2010 at 5:39 PM, Guzman Lugo, Fernando
<fernando.lugo@xxxxxx> wrote:
>> On Mon, Oct 11, 2010 at 6:03 PM, Guzman Lugo, Fernando
>> <fernando.lugo@xxxxxx> wrote:
>> >> On Tue, Oct 5, 2010 at 11:35 PM, Fernando Guzman Lugo
>> >> <x0095840@xxxxxx> 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.

Cheers.

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