From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason() Date: Fri, 20 Nov 2015 14:48:20 +0100 Message-ID: <5158930.I1IPZa4jtW@wuerfel> References: <1432646768-12532-1-git-send-email-peter.ujfalusi@ti.com> <6118451.vaLZWOZEF5@wuerfel> <564F1773.9030006@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Vinod Koul , Geert Uytterhoeven , Tony Lindgren , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Dan Williams , dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Linux MMC List , linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-spi , Linux Media Mailing List , ALSA Development Mailing List To: Peter Ujfalusi Return-path: In-Reply-To: <564F1773.9030006-l0cyMroinI0@public.gmane.org> Sender: linux-spi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-crypto.vger.kernel.org On Friday 20 November 2015 14:52:03 Peter Ujfalusi wrote: > > >> For legacy the filter function is pretty much needed to handle the differences > >> between the platforms as not all of them does the filtering in a same way. So > >> the first type of map would be feasible IMHO. > > > > It certainly makes the transition to a map table much easier. > > And the aim anyway is to convert everything to DT, right? We won't be able to do that. Some architectures (avr32 and sh for instance) use the dmaengine API but will likely never support DT. On ARM, at least sa1100 is in the same category, probably also ep93xx and portions of pxa, omap1 and davinci. > > int dmam_register_platform_map(struct device *dev, dma_filter_fn filter, struct dma_chan_map *map) > > { > > struct dma_map_list *list = kmalloc(sizeof(*list), GFP_KERNEL); > > > > if (!list) > > return -ENOMEM; > > > > list->dev = dev; > > list->filter = filter; > > list->map = map; > > > > mutex_lock(&dma_map_mutex); > > list_add(&dma_map_list, &list->node); > > mutex_unlock(&dma_map_mutex); > > } > > > > Now we can completely remove the dependency on the filter function definition > > from platform code and slave drivers. > > Sounds feasible for OMAP and daVinci and for others as well. I think > I would go with this if someone asks my opinion Ok. > The core change to add the new API + the dma_map support should be pretty > straight forward. It can live alongside with the old API and we can phase out > the users of the old one. > The legacy support would need more time since we need to modify the arch codes > and the corresponding DMA drivers to get the map registered, but after that > the remaining drivers can be converted to use the new API. Right. It's not urgent and as long as we agree on the overall approach, we can always do the platform support first and wait for the following merge window before moving over the slave drivers. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162750AbbKTNse (ORCPT ); Fri, 20 Nov 2015 08:48:34 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:56153 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759684AbbKTNsc (ORCPT ); Fri, 20 Nov 2015 08:48:32 -0500 X-Greylist: delayed 150817 seconds by postgrey-1.27 at vger.kernel.org; Fri, 20 Nov 2015 08:48:31 EST From: Arnd Bergmann To: Peter Ujfalusi Cc: Vinod Koul , Geert Uytterhoeven , Tony Lindgren , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Dan Williams , dmaengine@vger.kernel.org, "linux-serial@vger.kernel.org" , "linux-omap@vger.kernel.org" , Linux MMC List , linux-crypto@vger.kernel.org, linux-spi , Linux Media Mailing List , ALSA Development Mailing List Subject: Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason() Date: Fri, 20 Nov 2015 14:48:20 +0100 Message-ID: <5158930.I1IPZa4jtW@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <564F1773.9030006@ti.com> References: <1432646768-12532-1-git-send-email-peter.ujfalusi@ti.com> <6118451.vaLZWOZEF5@wuerfel> <564F1773.9030006@ti.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:ilvYIJsxE4s9xblG50seG0IPTuLKLi6htMl9if5UM3qsufNWP8W bHq3exdnAF67yZ47X+nn0Rpookx8n0vVm9nlSOd266PSW2Vqyeu4FJxL7SPE1wayfuuYmvc 6Ig1wrptld4lUYOmKEoFDJDS4ENp7BE70IuCDWIrFYULCZh5iOjY+dxcpkD5YNDL4xcZGW/ OY/S0FgEvl5eeqCFd89Mg== X-UI-Out-Filterresults: notjunk:1;V01:K0:8ABM4hpg/bw=:c0nm0aj65yPsXmE6FGBoX2 stS5xu4kWEgubbyWLe+DHfOzwsCpGdKSS0aQSkTUelV0/9icQGWjZ40pQRZzFfD2ZpA8dfQHE gcx5SZO9XwpS0LiLpvZMASYcqAQSNl+sMQIlqJfYpdQ9iwyR8kgENuyYP4+UkgpIlsUqRXDZq kYQeMfieAES0i0NHDQrjZiorO2iU32+0/DaPi1+QXy8TSS5X5O2AiuH+S1T+Y5zgsAmMPmRLv Cdf5fW+8qSXECuuOLxkEIldLQxt6P0cmH5/LTVlkSTdUgh6l473pI7VZFGK6WmZ7zJyKp4bD5 3pfxAf6+6ko1qhDu0smGZ3BtU5ja78qEFwfSeuU3cwQmyHBKs1JxFiMPfzQc4T53PyzGCi+nE EMcEH2NkrQpVyTJSVQTrjwydP3SeInl+yt6VWk/WY75m2/VxYys7pPWb8DNO9BIBecaPdMFFO bFTTIgMcXs+xIgJVSLXEbyiEcQr12SsYs6aSilA5PhAE3zTPxSzWH7lXO990RDp0FAttX+7v/ clGTJBfybknmmnR3OK5ZSEfoFaj121JxYUPozgeXo3CxEv1CAxC8NOHrKDDnxdFDJqkEUQnQh c72j1Ne8jHrfkb5xzwpcrTxHBhIqsDL0DIcdZ2uZXipU/NYw3gkIuj81RNog0nCsLw64fMxdu Pv+cyhcoG87lvU4LS5wlmY3bsCQntQxjZieaVjyDIx+WehKd5/0PFNCVibSh2MsnbKiO59JTu HqAEn2ytfrRpF2uf Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 20 November 2015 14:52:03 Peter Ujfalusi wrote: > > >> For legacy the filter function is pretty much needed to handle the differences > >> between the platforms as not all of them does the filtering in a same way. So > >> the first type of map would be feasible IMHO. > > > > It certainly makes the transition to a map table much easier. > > And the aim anyway is to convert everything to DT, right? We won't be able to do that. Some architectures (avr32 and sh for instance) use the dmaengine API but will likely never support DT. On ARM, at least sa1100 is in the same category, probably also ep93xx and portions of pxa, omap1 and davinci. > > int dmam_register_platform_map(struct device *dev, dma_filter_fn filter, struct dma_chan_map *map) > > { > > struct dma_map_list *list = kmalloc(sizeof(*list), GFP_KERNEL); > > > > if (!list) > > return -ENOMEM; > > > > list->dev = dev; > > list->filter = filter; > > list->map = map; > > > > mutex_lock(&dma_map_mutex); > > list_add(&dma_map_list, &list->node); > > mutex_unlock(&dma_map_mutex); > > } > > > > Now we can completely remove the dependency on the filter function definition > > from platform code and slave drivers. > > Sounds feasible for OMAP and daVinci and for others as well. I think > I would go with this if someone asks my opinion Ok. > The core change to add the new API + the dma_map support should be pretty > straight forward. It can live alongside with the old API and we can phase out > the users of the old one. > The legacy support would need more time since we need to modify the arch codes > and the corresponding DMA drivers to get the map registered, but after that > the remaining drivers can be converted to use the new API. Right. It's not urgent and as long as we agree on the overall approach, we can always do the platform support first and wait for the following merge window before moving over the slave drivers. Arnd