From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760799AbdEOJpi (ORCPT ); Mon, 15 May 2017 05:45:38 -0400 Received: from mga04.intel.com ([192.55.52.120]:56806 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751449AbdEOJpg (ORCPT ); Mon, 15 May 2017 05:45:36 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,344,1491289200"; d="scan'208";a="968476804" Message-ID: <1494841350.6967.55.camel@linux.intel.com> Subject: Re: [PATCH v2 2/2] dmaengine: dw: Remove AVR32 bits from the driver From: Andy Shevchenko To: Lars-Peter Clausen , Vinod Koul Cc: Hans-Christian Noren Egtvedt , linux-kernel@vger.kernel.org, Haavard Skinnemoen , Nicolas Ferre , Boris Brezillon , Mark Brown , Liam Girdwood , alsa-devel@alsa-project.org, dmaengine@vger.kernel.org, Eugeniy Paltsev Date: Mon, 15 May 2017 12:42:30 +0300 In-Reply-To: <45cb3a0a-28b5-a64c-90ac-1abf0c59d70f@metafoo.de> References: <20170509161837.48301-1-andriy.shevchenko@linux.intel.com> <20170509161837.48301-3-andriy.shevchenko@linux.intel.com> <20170514130457.GK6263@localhost> <1494837791.6967.44.camel@linux.intel.com> <45cb3a0a-28b5-a64c-90ac-1abf0c59d70f@metafoo.de> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2017-05-15 at 11:25 +0200, Lars-Peter Clausen wrote: > On 05/15/2017 10:43 AM, Andy Shevchenko wrote: > > On Sun, 2017-05-14 at 18:34 +0530, Vinod Koul wrote: > > > On Tue, May 09, 2017 at 07:18:37PM +0300, Andy Shevchenko wrote: > > > > AVR32 is gone. Now it's time to clean up the driver by removing > > > > leftovers that was used by AVR32 related code. > > > > > > Since the cover didn't mention any dependency, I went ahead and > > > applied this > > > now > > > > > > > Sorry, I forgot to mention that it's supposed to go via either tree, > > though together. Since first we remove users of non-standard DMA > > callbacks. > > > > Since there is no hurry maybe split it over multiple releases. Audio > patch > now through the audio tree and once it has made it to a upstream > release > apply the DMA patch through the DMA tree. While there is indeed no hurry (I'm not expecting long patches against dw_dmac), we may do that, though OTOH better to do it at once to minimize a probability that the second change might be forgotten for longer. -- Andy Shevchenko Intel Finland Oy