On Thu, Dec 23, 2010 at 03:04:07PM +0100, Tomasz Fujak wrote:
quoted text
> On 2010-12-23 14:48, Russell King - ARM Linux wrote:
> > On Thu, Dec 23, 2010 at 02:35:00PM +0100, Tomasz Fujak wrote:
> >> Dear Mr. King,
> >>
> >> AFAIK the CMA is the fourth attempt since 2008 taken to solve the
> >> multimedia memory allocation issue on some embedded devices. Most
> >> notably on ARM, that happens to be present in the SoCs we care about
> >> along the IOMMU-incapable multimedia IPs.
> >>
> >> I understand that you have your guidelines taken from the ARM
> >> specification, but this approach is not helping us.
> > I'm sorry you feel like that, but I'm living in reality.  If we didn't
> > have these architecture restrictions then we wouldn't have this problem
> > in the first place.
> Do we really have them, or just the documents say they exist?

Yes.  We have seen CPUs which lockup or crash as a result of mismatched
attributes in the page tables.

quoted text
> > What I'm trying to do here is to ensure that we remain _legal_ to the
> > architecture specification - which for this issue means that we avoid
> > corrupting people's data.
> As legal as the mentioned dma_coherent?

See my other comment in an earlier email.  See the patch which prevents
ioremap() being used on system memory.  There is active movement at the
present time to sorting these violations out and find solutions for
them.

The last thing we need is a new API which introduces new violations.

quoted text
> > Maybe you like having a system which randomly corrupts people's data?
> > I most certainly don't.  But that's the way CMA is heading at the moment
> > on ARM.
> Has this been experienced? I had some ARM-compatible boards on my desk
> (xscale, v6 and v7) and none of them crashed due to this behavior. And
> we *do* have multiple memory mappings, with different attributes.

Xscale doesn't suffer from the problem.  V6 doesn't aggressively speculate.
V7 speculates more aggressively, and corruption has been seen there.

quoted text
> > It is not up to me to solve these problems - that's for the proposer of
> > the new API to do so.  So, please, don't try to lump this problem on
> > my shoulders.  It's not my problem to sort out.
> Just great. Nothing short of spectacular - this way the IA32 is going to
> take the embedded market piece by piece once the big two advance their
> foundry processes.

Look, I've been pointing out this problem ever since the very _first_
CMA patches were posted to the list, yet the CMA proponents have decided
to brush those problems aside each and every time I've raised them.

So, you should be asking _why_ the CMA proponents are choosing to ignore
this issue completely, rather than working to resolve it.

If it's resolved, then the problem goes away.

quoted text
> In other words, should we take your response as yet another NAK?
> Or would you try harder and at least point us to some direction that
> would not doom the effort from the very beginning.

What the fsck do you think I've been doing?  This is NOT THE FIRST time
I've raised this issue.  I gave up raising it after the first couple
of attempts because I wasn't being listened to.

You say about _me_ not being very helpful.  How about the CMA proponents
start taking the issue I've raised seriously, and try to work out how
to solve it?  And how about blaming them for the months of wasted time
on this issue _because_ _they_ have chosen to ignore it?
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/