"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? 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
