From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752562AbdBNHuw (ORCPT ); Tue, 14 Feb 2017 02:50:52 -0500 Received: from mailout4.w1.samsung.com ([210.118.77.14]:39627 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752443AbdBNHut (ORCPT ); Tue, 14 Feb 2017 02:50:49 -0500 X-AuditID: cbfec7ef-f79d26d00000420c-35-58a2b6d78a13 Subject: Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM To: Vinod Koul , Ulf Hansson Cc: "Rafael J. Wysocki" , linux-samsung-soc , dmaengine@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , Lars-Peter Clausen , Arnd Bergmann , Inki Dae From: Marek Szyprowski Message-id: Date: Tue, 14 Feb 2017 08:50:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-version: 1.0 In-reply-to: <20170213154727.GN2843@localhost> Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH++0+dieufk2zH2YZkyJ7+CCjS5b46I8LUhgImtjjkhe1nMqu SvaPYpk604aiiSTqtAzTtKnL1GpNcYWSr2nRQ4lhunAUrETLSW5Xw/8+55zv75zzPfwoTPaa 8KSSUzM4ZSqbIiddcN3g8siR9zpNbIB+0p+2lw2K6adVbQT9uMJO0GUzapweGWkX043ltQSt NU8R9ETPfZK2lQwAumrkpYgeHhonaGNrDG0pfYWHSpm/f8oA09BnETHa5iKS+TzVRzIdjTlM 44KBYDonC3CmtLMZMDbtnihJnMvJBC4lOYtT+odcdkma0Twn09XwukldS+aCD64qIKEQDEJz hS0igT3Q6HQbqQIulAw+BOhTwzBwFGTQBtAtjXLjgenrhOi/qMY4iAnBHEATj3rFDpUbPIc+ royTDnaHkci01CR2iDBYgaPuGjXhKJAwEKmsKqdICkPQclWBM4/DfWjepHPmd8B4VKKtxATN drRUPo07WAL9UOug3bkeBk+gb6v5hMDeqKPF6twIQasYrXatrE2m1oLdSKvHBAunkflZoVhg N/Td2LnOXmiivBgX+C5AefmHBK4C6J1VKnAw6jeOrc/aisp09zChvRQV3pYJEgb11BnW24Sh ydl6sXCgRRy19JpwNfCu3mSnepOF6k0W6gDWDNy5TF6RyPGBfjyr4DNTE/2upCm0YO1jDa0a f3SD2ZvRBgApIHeVqvX1sTKCzeKzFQaAKEzuLt1SoomVSRPY7BucMu2SMjOF4w1gF4XLd0pf 1JliZDCRzeCucVw6p9yoiiiJZy4IvRp8bFvXRfZLE9O64CpR+NwpDesvymRDPPZGnYlosYap ZIcTDPrwrnF9+hQwqyyRv+wR7a3HD1Qu8pa+dtxqthQU58Ub46POWnx1p+LewIB5rwdJ1N5i yiev7u1Rz/HwJd/Q8znk/ie/xdHNGdM/g3JhwVjegH00/8KyrVyO80ls4EFMybP/ALzvRwpU AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsVy+t/xK7o3ti2KMPi2jdni76Rj7BYbZ6xn tVg99S+rxaT7E1gszp/fwG6xZPJ8VotNj6+xWlzeNYfN4nPvEUaLGef3MVmcOX2J1eL42nCL l337WRx4PX7/msTosXjPSyaPTas62TzuXNvD5rF5Sb3HkjeHWD22XG1n8ejbsorR4/MmuQDO KDebjNTElNQihdS85PyUzLx0W6XQEDddCyWFvMTcVFulCF3fkCAlhbLEnFIgz8gADTg4B7gH K+nbJbhl3F+0k61ggkDFlQnz2RoYb/B0MXJySAiYSFx5eJkJwhaTuHBvPRuILSSwhFGiYYIw hP2cUeL10hQQW1jAX2LSh+2sILaIgLfElR/L2bsYuYBqvrFIXFn1C8xhFpjOIvF++hKwqWwC hhJdb7vApvIK2En8nNEO1s0ioCrx4so2sLioQIzE3v77TBA1ghI/Jt9jAbE5BfQk1h77ywhi MwuYSXx5eZgVwpaX2LzmLfMERoFZSFpmISmbhaRsASPzKkaR1NLi3PTcYiO94sTc4tK8dL3k /NxNjMDo3Xbs55YdjF3vgg8xCnAwKvHwWuxbGCHEmlhWXJl7iFGCg1lJhJehd1GEEG9KYmVV alF+fFFpTmrxIUZToCcmMkuJJucDE0teSbyhiaG5paGRsYWFuZGRkjjv1A9XwoUE0hNLUrNT UwtSi2D6mDg4pRoYLdyvPnocVV0wxe2KdOSbOXu/ZPzL+ifMrrfz6gRu+dmrKldVlG7J8N17 q0jyY8TMt7f5f63eu8E54ojAKTOODSvElQSL97yz3XMoZ15XzzWjS8Je/rYvNayqz6zS1lz0 wfjNXtXG9k5h85J3Wv/NznCm7d/aqsvLJMFZKZTjuZnnxWGh/tmSSizFGYmGWsxFxYkAdRAD RvQCAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170214075044eucas1p2d7a27f59735b826c41fbe6698303380a X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRs=?= =?UTF-8?B?7IK87ISx7KCE7J6QG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Global-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRtT?= =?UTF-8?B?YW1zdW5nIEVsZWN0cm9uaWNzG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTI=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20170209142309eucas1p2b1277d96139eafc0d1dcc14145600476 X-RootMTR: 20170209142309eucas1p2b1277d96139eafc0d1dcc14145600476 References: <1486650171-20598-1-git-send-email-m.szyprowski@samsung.com> <1486650171-20598-4-git-send-email-m.szyprowski@samsung.com> <20170210045004.GN19244@localhost> <20170213020340.GH2843@localhost> <20170213122742.GL2843@localhost> <20170213154727.GN2843@localhost> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vinod, On 2017-02-13 16:47, Vinod Koul wrote: > On Mon, Feb 13, 2017 at 04:32:32PM +0100, Ulf Hansson wrote: >> [...] >> >>>> Although, I don't know of other examples, besides the runtime PM use >>>> case, where non-atomic channel prepare/unprepare would make sense. Do >>>> you? >>> The primary ask for that has been to enable runtime_pm for drivers. It's not >>> a new ask, but we somehow haven't gotten around to do it. >> Okay, I see. >> >>>>> As I said earlier, if we want to solve that problem a better idea is to >>>>> actually split the prepare as we discussed in [1] >>>>> >>>>> This way we can get a non atomic descriptor allocate/prepare and release. >>>>> Yes we need to redesign the APIs to solve this, but if you guys are up for >>>>> it, I think we can do it and avoid any further round abouts :) >>>> Adding/re-designing dma APIs is a viable option to solve the runtime PM case. >>>> >>>> Changes would be needed for all related dma client drivers as well, >>>> although if that's what we need to do - let's do it. >>> Yes, but do bear in mind that some cases do need atomic prepare. The primary >>> cases for DMA had that in mind and also submitting next transaction from the >>> callback (tasklet) context, so that won't go away. >>> >>> It would help in other cases where clients know that they will not be in >>> atomic context so we provide additional non-atomic "allocation" followed by >>> prepare, so that drivers can split the work among these and people can do >>> runtime_pm and other things.. >> That for sharing the details. >> >> It seems like some dma expert really need to be heavily involved if we >> ever are going to complete this work. :-) > Sure, I will help out :) > > If anyone of you are in Portland next week, then we can discuss these f2f. I > will try taking a stab at the new API design next week. I'm not going to Portland, but I hope that you will have a fruitful discussion there. [...] Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Szyprowski Subject: Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM Date: Tue, 14 Feb 2017 08:50:43 +0100 Message-ID: References: <1486650171-20598-1-git-send-email-m.szyprowski@samsung.com> <1486650171-20598-4-git-send-email-m.szyprowski@samsung.com> <20170210045004.GN19244@localhost> <20170213020340.GH2843@localhost> <20170213122742.GL2843@localhost> <20170213154727.GN2843@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <20170213154727.GN2843@localhost> Sender: linux-kernel-owner@vger.kernel.org To: Vinod Koul , Ulf Hansson Cc: "Rafael J. Wysocki" , linux-samsung-soc , dmaengine@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , Lars-Peter Clausen , Arnd Bergmann , Inki Dae List-Id: linux-pm@vger.kernel.org Hi Vinod, On 2017-02-13 16:47, Vinod Koul wrote: > On Mon, Feb 13, 2017 at 04:32:32PM +0100, Ulf Hansson wrote: >> [...] >> >>>> Although, I don't know of other examples, besides the runtime PM use >>>> case, where non-atomic channel prepare/unprepare would make sense. Do >>>> you? >>> The primary ask for that has been to enable runtime_pm for drivers. It's not >>> a new ask, but we somehow haven't gotten around to do it. >> Okay, I see. >> >>>>> As I said earlier, if we want to solve that problem a better idea is to >>>>> actually split the prepare as we discussed in [1] >>>>> >>>>> This way we can get a non atomic descriptor allocate/prepare and release. >>>>> Yes we need to redesign the APIs to solve this, but if you guys are up for >>>>> it, I think we can do it and avoid any further round abouts :) >>>> Adding/re-designing dma APIs is a viable option to solve the runtime PM case. >>>> >>>> Changes would be needed for all related dma client drivers as well, >>>> although if that's what we need to do - let's do it. >>> Yes, but do bear in mind that some cases do need atomic prepare. The primary >>> cases for DMA had that in mind and also submitting next transaction from the >>> callback (tasklet) context, so that won't go away. >>> >>> It would help in other cases where clients know that they will not be in >>> atomic context so we provide additional non-atomic "allocation" followed by >>> prepare, so that drivers can split the work among these and people can do >>> runtime_pm and other things.. >> That for sharing the details. >> >> It seems like some dma expert really need to be heavily involved if we >> ever are going to complete this work. :-) > Sure, I will help out :) > > If anyone of you are in Portland next week, then we can discuss these f2f. I > will try taking a stab at the new API design next week. I'm not going to Portland, but I hope that you will have a fruitful discussion there. [...] Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From mboxrd@z Thu Jan 1 00:00:00 1970 From: m.szyprowski@samsung.com (Marek Szyprowski) Date: Tue, 14 Feb 2017 08:50:43 +0100 Subject: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM In-Reply-To: <20170213154727.GN2843@localhost> References: <1486650171-20598-1-git-send-email-m.szyprowski@samsung.com> <1486650171-20598-4-git-send-email-m.szyprowski@samsung.com> <20170210045004.GN19244@localhost> <20170213020340.GH2843@localhost> <20170213122742.GL2843@localhost> <20170213154727.GN2843@localhost> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Vinod, On 2017-02-13 16:47, Vinod Koul wrote: > On Mon, Feb 13, 2017 at 04:32:32PM +0100, Ulf Hansson wrote: >> [...] >> >>>> Although, I don't know of other examples, besides the runtime PM use >>>> case, where non-atomic channel prepare/unprepare would make sense. Do >>>> you? >>> The primary ask for that has been to enable runtime_pm for drivers. It's not >>> a new ask, but we somehow haven't gotten around to do it. >> Okay, I see. >> >>>>> As I said earlier, if we want to solve that problem a better idea is to >>>>> actually split the prepare as we discussed in [1] >>>>> >>>>> This way we can get a non atomic descriptor allocate/prepare and release. >>>>> Yes we need to redesign the APIs to solve this, but if you guys are up for >>>>> it, I think we can do it and avoid any further round abouts :) >>>> Adding/re-designing dma APIs is a viable option to solve the runtime PM case. >>>> >>>> Changes would be needed for all related dma client drivers as well, >>>> although if that's what we need to do - let's do it. >>> Yes, but do bear in mind that some cases do need atomic prepare. The primary >>> cases for DMA had that in mind and also submitting next transaction from the >>> callback (tasklet) context, so that won't go away. >>> >>> It would help in other cases where clients know that they will not be in >>> atomic context so we provide additional non-atomic "allocation" followed by >>> prepare, so that drivers can split the work among these and people can do >>> runtime_pm and other things.. >> That for sharing the details. >> >> It seems like some dma expert really need to be heavily involved if we >> ever are going to complete this work. :-) > Sure, I will help out :) > > If anyone of you are in Portland next week, then we can discuss these f2f. I > will try taking a stab at the new API design next week. I'm not going to Portland, but I hope that you will have a fruitful discussion there. [...] Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland