On Thursday 07 January 2010 09:22:33 pm Kevin Hilman wrote: > "Nori, Sekhar" <[email protected]> writes: > > On Thu, Jan 07, 2010 at 06:05:12, Kevin Hilman wrote: > >> Troy Kisky <[email protected]> writes: > >> > Kevin Hilman wrote: > >> >> Sudhakar Rajashekhara <[email protected]> writes: > >> >>> This patch set corrects some issues with the existing EDMA > >> >>> driver and also adds support for EDMA resource (channel/slots) > >> >>> sharing between two processors (say ARM and DSP). > >> >>> > >> >>> The patch set has been tested on DM646x, OMAP-L137 and OMAP-L138 > >> >>> EVM boards. > >> >> > >> >> Hi Sudhakar, > >> >> > >> >> This series looks good. One minor request. > >> >> > >> >> For the last three patches, I think it would be helpful to describe > >> >> in the changelog or even better at the definition of the reserved > >> >> arrays what the channels are being reserved for. > >> >> > >> >> Kevin > >> > > >> > Hi Kevin > >> > > >> > Why is this comment from you (april 2009) no longer valid? > >> > >> <blush> > >> Hmm, because I've been on vacation for two weeks and thought I did a > >> thorough look before vacation, so didn't look closely enough at these > >> patches thi week. > >> </blush> > >> > >> >>> I'm not crazy about this hard-coded reservation. > >> >>> > >> >>> The DSP code has a kernel-side driver (dsplinkk.) That driver > >> >>> should be doing the channel reservations. > >> >>> > >> >>> Kevin > >> > >> Sudhakar, Troy has (and I had) a good point here. > >> > >> Why does the kernel need hard-coded reservations. The DSP driver > >> should take care of any allocations it needs. > > > > Troy, Kevin, > > > > As I understand, the dsplink doesn't reserve EDMA resource > > currently. > > > > Do you think this approach would be more acceptable if the > > patches did the reservation in the EVM board file instead? > > > > That way the reservation is not imposed on all users and > > another board could easily skip the reservation altogether. > > Yes, the board-file approach is more acceptable. > > But, I don't really like the idea of adding stuff like this to the > kernel simply because a driver simply isn't being updated. > > Why can't dsplink be fixed? >
Because it is quite broken already(in my experience) and there are various versions of it in use today. Patching for these edma changes will not be easy on users side and TI will not care cause they do not support GIT kernel yet. It would be nice for users if you let these "reservations" live in board-files until dsplink is evolved into something Linux friendly. Thanks, Caglar > Kevin > > P.S., I'm planning to drop these 'reserve' parts of this series from > the master and davinci-next branches. > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
