[...] >>> >>>> To solve this problem, I was thinking we could convert to use the >>>> asynchronous pm_runtime_get() API, when trying to runtime resume the >>>> device from atomic contexts. >>> >>> I'm not sure if this will work for DMA engine devices. If I understand >>> correctly some client's of DMA engine device might rely on the DMA >>> engine being configured and operational after queuing a request and >>> they might lock up if the DMA engine device activation if postponed >>> because of async runtime pm activation. >> >> I didn't know about this. If you have an example from the top of your >> head, could you perhaps point me to it? > > > No, I don't have any example. This is just my fear that there might be some > hardware which works this way. I can imagine a driver, which queue dma > engine > request and then triggers 'start' command to its hw block. HW blocks usually > uses some additional signal lines for DMA, so the HW block might check if > all > needed signals from DMA engine HW are ready. If not it will fail to start > avoid lockup of starting without DMA engine HW being ready. Well, I think this reasoning makes lots of sense! Clearly we wouldn't be able to guarantee that there's isn't a glitch in an undefined HW behaviour. I will drop my suggested approach and try out another one. > > However I don't have much experience with DMA engine and drivers. I only > helped in adding DMA engine support to Samsung UART driver and in the > hardware manual there is information about additional lines between DMA > controller and UART module, which are used in the DMA mode. Thanks for sharing your experience! Now, I should allow you to get back to the original review! :-) Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |