Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

Felipe Contreras
2010-11-09T22:05:01Z

On Tue, Nov 9, 2010 at 6:29 PM, Arnd Bergmann <arnd@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.

The changes from Fernando require changes in other trees: arm, omap.
These cannot get into 2.6.37, and I have my doubts they would get into
2.6.38, as I haven't seen those ack'ed yet.

Moreover, I have applied all the patches Fernando has sent, and I
still haven't seen this driver working with the new iommu code.

So, sure, these patches are good, we (Nokia), requested them years
ago, but right now there's no way to get this driver working with them
on 2.6.37. I would rather have a working driver for once on a vanilla
kernel. It is really tiring to point people to different places to get
working code depending on which week they ask.

--
Felipe Contreras