On Tue, Nov 9, 2010 at 10:29 AM, Arnd Bergmann <a...@arndb.de> wrote: > On Tuesday 09 November 2010, Felipe Contreras wrote: >> Felipe Contreras (14): >> Revert "staging: tidspbridge - update Kconfig to select IOMMU module" >> Revert "staging: tidspbridge - remove dmm custom module" >> Revert "staging: tidspbridge - deprecate reserve/unreserve_memory >> funtions" >> Revert "staging: tidspbridge - remove reserved memory clean up" >> Revert "staging: tidspbridge: remove dw_dmmu_base from cfg_hostres >> struct" >> Revert "staging: tidspbridge - move all iommu related code to a new >> file" >> Revert "staging: tidspbridge - remove hw directory" >> Revert "staging: tidspbridge - fix mmufault support" >> Revert "staging: tidspbridge - remove custom mmu code from >> tiomap3430.c" >> Revert "staging: tidspbridge - rename bridge_brd_mem_map/unmap to a >> proper name" >> Revert "staging: tidspbridge - move shared memory iommu maps to >> tiomap3430.c" >> Revert "staging: tidspbridge: replace iommu custom for opensource >> implementation" > > That adds quite a lot of crap back in that was removed by Fernando earlier: > > 44 files changed, 3733 insertions(+), 847 deletions(-) > > It may have been premature to merge the patches as you say, but now that > they are in, I'd vote for giving Fernando a chance to fix up any damage > that was done in the process rather than just reverting all the useful > changes. > > Arnd
tidspbridge iommu change are working fine all the patches and few fixes after that are alredy sent. what breaks tidspbridge, is the unmerged dependencies in linux omap tree, specifically the iommu module patches and the SG patch. if the dependencies are merged tidspbridge work perfectly I don't need to fix anything. As the dependencies are not merge yet it is ok to revert and once push once all the dependencies are merge. I am not familiar with that so I don't know how much time can it take. Regards, Fernando. > -- 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
