RE: tidspbridge broken?

2010-10-04 Thread Ramirez Luna, Omar
Hi,

Felipe Contreras wrote:
 Hi,
 
 I was trying the iommu patches but I noticed the tidspbridge driver
 doesn't work at all, I found two critical issues: 
 
 First, the platform device is missing, so there's no way the driver
 can work. It seems to have been dropped from the migration to staging
 which happened some time ago... I would have expected somebody to
 notice a thing like this. I already have patches that fix this.   

Yes this is missing from beginning, I seeked advice on whether to send a patch 
for this or not, and since it would be touching mach dependent files it would 
be out of the scope of staging tree, however if needed:

http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=commit;h=4dcb41d484653d162b2bc6e1bf226c2dad0b953c

This was meant to placed under dspbridge wiki, I still have to do that one.

 
 And second, since 2.6.35, ioremap() doesn't work on RAM, so this
 driver cannot work anymore unless 309caa9 is reverted. I am reserving
 the memory with memblock, but it still fails the ioremap(), and
 __va() doesn't seem to work (don't know why).   


Yes that's true, so far the only solution I have seen is to move the allocation 
on memory outside kernel control, I believe framebuffer has the same problem, 
but I haven't contacted them to see if we can align on a common solution.
 
 Has anyone tried the driver on 2.6.36-rcX?

Yes I have, I was rebasing your mailbox hwmod patches but seems something has 
changed since they don't work, I was trying to write my own version.

After that, I was planning the migration from bridge tasklet to a process 
context, and see how it works, since the spin_lock method used in the mailbox 
driver also causes an invalid locking condition.

Regards,

Omar--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: tidspbridge broken?

2010-10-04 Thread Felipe Contreras
Hi,

On Mon, Oct 4, 2010 at 6:59 PM, Ramirez Luna, Omar omar.rami...@ti.com wrote:
 Felipe Contreras wrote:
 I was trying the iommu patches but I noticed the tidspbridge driver
 doesn't work at all, I found two critical issues:

 First, the platform device is missing, so there's no way the driver
 can work. It seems to have been dropped from the migration to staging
 which happened some time ago... I would have expected somebody to
 notice a thing like this. I already have patches that fix this.

 Yes this is missing from beginning, I seeked advice on whether to send a 
 patch for this or not, and since it would be touching mach dependent files it 
 would be out of the scope of staging tree, however if needed:

 http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=commit;h=4dcb41d484653d162b2bc6e1bf226c2dad0b953c

 This was meant to placed under dspbridge wiki, I still have to do that one.

This seems to be worth mentioning in the TODO file:
* Make it actually work

Anyway, first, I think I tried a version similar to that one, and
doesn't apply on mainline any more, also, bootmem doesn't seem to be
working on ARM either, so I had to move to memblock, and third, I
don't think that platform device is correct since it depends on the
headers of a driver.

My version is basically the same, but using memblock, and stands on
it's own. Even if tidspbridge wasn't in staging I think this could go
to mainline, plus, perhaps other implementations like dsp-link could
make use of it (who knows):
http://article.gmane.org/gmane.linux.kernel/1044209

 And second, since 2.6.35, ioremap() doesn't work on RAM, so this
 driver cannot work anymore unless 309caa9 is reverted. I am reserving
 the memory with memblock, but it still fails the ioremap(), and
 __va() doesn't seem to work (don't know why).

 Yes that's true, so far the only solution I have seen is to move the 
 allocation on memory outside kernel control, I believe framebuffer has the 
 same problem, but I haven't contacted them to see if we can align on a common 
 solution.

At least on my N900 the framebuffer is not working either, and I've
heard the same on beagleboard.

Maybe something like this:
http://article.gmane.org/gmane.linux.kernel.mm/52757

 Has anyone tried the driver on 2.6.36-rcX?

 Yes I have,

I guess by applying your patches on top and reverting 309caa9.

 I was rebasing your mailbox hwmod patches but seems something has changed 
 since they don't work, I was trying to write my own version.

You should have said so, I'll try to rebase myself.

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: tidspbridge broken?

2010-10-04 Thread Ramirez Luna, Omar
Felipe Contreras wrote:
...
 
 Anyway, first, I think I tried a version similar to that one, and
 doesn't apply on mainline any more, also, bootmem doesn't seem to be
 working on ARM either, so I had to move to memblock, and third, I
 don't think that platform device is correct since it depends on the
 headers of a driver.

AFAIK, bootmem is going down 
(http://marc.info/?l=linux-omapm=126955999303922w=2), I succesfully tried LMB 
a while back when rebasing but for the latest RCs I haven't seen it around.

...
 
 At least on my N900 the framebuffer is not working either, and I've
 heard the same on beagleboard. 
 
 Maybe something like this:
 http://article.gmane.org/gmane.linux.kernel.mm/52757

Will look at it.

...

Regards,

Omar

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: tidspbridge broken?

2010-10-04 Thread Felipe Contreras
On Mon, Oct 4, 2010 at 8:34 PM, Ramirez Luna, Omar omar.rami...@ti.com wrote:
 Felipe Contreras wrote:
 ...

 Anyway, first, I think I tried a version similar to that one, and
 doesn't apply on mainline any more, also, bootmem doesn't seem to be
 working on ARM either, so I had to move to memblock, and third, I
 don't think that platform device is correct since it depends on the
 headers of a driver.

 AFAIK, bootmem is going down 
 (http://marc.info/?l=linux-omapm=126955999303922w=2), I succesfully tried 
 LMB a while back when rebasing but for the latest RCs I haven't seen it 
 around.

It's called memblock now. And yeah, bootmem is going down, but it
should still work right now.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html