Re: [PATCH 0/2] omap: dsp: make the driver actually work
On 10/5/2010 4:05 PM, Felipe Contreras wrote: On Tue, Oct 5, 2010 at 11:09 PM, Ramirez Luna, Omaromar.rami...@ti.com wrote: Felipe Contreras wrote: ... Hmmm, because my other option was to move the reserved memory outside the kernel, but that involves specifying bootargs again and using dma_alloc_coherent with their restrictions. Huh, if there's no contiguous memory region reserved, then the driver is doing dma_alloc_coherent already, but that fails (apparently 5M is too much). Plus I've read that dma_alloc_coherent is precious; shouldn't be used for that. Initially bridge was using the memory on the upper part of the RAM, specifying in bootargs mem=MAX-6MB, so reintroducing the parameter works fine; dma_alloc_coherent was also used when bridge was compiled as built-in the kernel but now it is not working either. So, first I wanted to try reserving some region with mem=X boot param, but that solution is ugly. If that worked, then I wanted ti see if flushing each time we access that shm memory block works, but in the process I wanted to reorganize the whole initialization code because right now it's very ugly and confusing. Yes, I can help with that, I'm sending a patch to reintroduce the parameter for phys_mempool_base, however we need to remove or disable the memblock functions related with dspbridge. I was thinking of a menuconfig parameter to specify mempool base for built-in compilation. 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: [PATCH 0/2] omap: dsp: make the driver actually work
On Mon, Oct 04, 2010 at 07:09:13PM +0300, Felipe Contreras wrote: Hi, It seems the platform device was dropped from the migration of tidspbridge into staging, plus the sdram meblock (previously bootmem) required for it work are gone. Withouth these patches the driver loads, but doesn't do anything. A second issue with ioremap() still remains, but that can be solved by reverting 309caa9. I think these might be worth to get into 2.6.36, if not, I have versions with more changes; cleanups and so on. I've applied this to my staging-next tree, for .37, as it's not a big deal for .36. thanks, greg k-h -- 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: [PATCH 0/2] omap: dsp: make the driver actually work
On Tue, Oct 5, 2010 at 10:07 PM, Greg KH g...@kroah.com wrote: On Mon, Oct 04, 2010 at 07:09:13PM +0300, Felipe Contreras wrote: It seems the platform device was dropped from the migration of tidspbridge into staging, plus the sdram meblock (previously bootmem) required for it work are gone. Withouth these patches the driver loads, but doesn't do anything. A second issue with ioremap() still remains, but that can be solved by reverting 309caa9. I think these might be worth to get into 2.6.36, if not, I have versions with more changes; cleanups and so on. I've applied this to my staging-next tree, for .37, as it's not a big deal for .36. Well, I thought it would be nice if the driver actually worked on .36, but anyway, I'll rebase the rest of my cleanup patches and send them. Hopefully I find a way to get rid of the ioremap() issue. 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: [PATCH 0/2] omap: dsp: make the driver actually work
Felipe Contreras wrote: ... Well, I thought it would be nice if the driver actually worked on .36, but anyway, I'll rebase the rest of my cleanup patches and send them. Hopefully I find a way to get rid of the ioremap() issue. phys_to_virt instead of ioremap should work fine, still need to try it though. 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: [PATCH 0/2] omap: dsp: make the driver actually work
On Tue, Oct 5, 2010 at 10:52 PM, Ramirez Luna, Omar omar.rami...@ti.com wrote: Felipe Contreras wrote: ... Well, I thought it would be nice if the driver actually worked on .36, but anyway, I'll rebase the rest of my cleanup patches and send them. Hopefully I find a way to get rid of the ioremap() issue. phys_to_virt instead of ioremap should work fine, still need to try it though. I tried that... Didn't work. I guess we need to flush at some points (since the memory is cacheable). -- 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: [PATCH 0/2] omap: dsp: make the driver actually work
Felipe Contreras wrote: ... phys_to_virt instead of ioremap should work fine, still need to try it though. I tried that... Didn't work. I guess we need to flush at some points (since the memory is cacheable). Hmmm, because my other option was to move the reserved memory outside the kernel, but that involves specifying bootargs again and using dma_alloc_coherent with their restrictions. If you are working on a different method and need any help let me know. 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: [PATCH 0/2] omap: dsp: make the driver actually work
On Tue, Oct 5, 2010 at 11:09 PM, Ramirez Luna, Omar omar.rami...@ti.com wrote: Felipe Contreras wrote: ... phys_to_virt instead of ioremap should work fine, still need to try it though. I tried that... Didn't work. I guess we need to flush at some points (since the memory is cacheable). Hmmm, because my other option was to move the reserved memory outside the kernel, but that involves specifying bootargs again and using dma_alloc_coherent with their restrictions. Huh, if there's no contiguous memory region reserved, then the driver is doing dma_alloc_coherent already, but that fails (apparently 5M is too much). Plus I've read that dma_alloc_coherent is precious; shouldn't be used for that. If you are working on a different method and need any help let me know. So, first I wanted to try reserving some region with mem=X boot param, but that solution is ugly. If that worked, then I wanted ti see if flushing each time we access that shm memory block works, but in the process I wanted to reorganize the whole initialization code because right now it's very ugly and confusing. -- 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
[PATCH 0/2] omap: dsp: make the driver actually work
Hi, It seems the platform device was dropped from the migration of tidspbridge into staging, plus the sdram meblock (previously bootmem) required for it work are gone. Withouth these patches the driver loads, but doesn't do anything. A second issue with ioremap() still remains, but that can be solved by reverting 309caa9. I think these might be worth to get into 2.6.36, if not, I have versions with more changes; cleanups and so on. Tested on a Nokia N900. Felipe Contreras (2): omap: add dsp platform device staging: tidspbridge: use omap_dsp_platform_data arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/dsp.c | 85 arch/arm/plat-omap/common.c|2 + arch/arm/plat-omap/devices.c | 30 +++ arch/arm/plat-omap/include/plat/dsp.h | 31 +++ drivers/staging/tidspbridge/core/tiomap3430.c | 14 ++-- drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 14 ++-- drivers/staging/tidspbridge/core/tiomap_io.c |4 +- .../tidspbridge/include/dspbridge/host_os.h| 19 - drivers/staging/tidspbridge/rmgr/drv_interface.c | 10 ++- 10 files changed, 177 insertions(+), 36 deletions(-) create mode 100644 arch/arm/mach-omap2/dsp.c create mode 100644 arch/arm/plat-omap/include/plat/dsp.h -- 1.7.3.1.2.g7fe2b -- 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
