Re: tidspbridge broken?
On Mon, Oct 4, 2010 at 8:34 PM, Ramirez Luna, Omar 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-omap&m=126955999303922&w=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
RE: tidspbridge broken?
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-omap&m=126955999303922&w=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?
Hi, On Mon, Oct 4, 2010 at 6:59 PM, Ramirez Luna, Omar 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?
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
tidspbridge broken?
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. 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). Has anyone tried the driver on 2.6.36-rcX? -- 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
