From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E736DC433B4 for ; Wed, 21 Apr 2021 17:43:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9F2656141C for ; Wed, 21 Apr 2021 17:43:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244881AbhDURoS (ORCPT ); Wed, 21 Apr 2021 13:44:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244880AbhDURoL (ORCPT ); Wed, 21 Apr 2021 13:44:11 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3DA4C06138B for ; Wed, 21 Apr 2021 10:43:33 -0700 (PDT) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lZGsj-0003PI-NV; Wed, 21 Apr 2021 19:43:21 +0200 Message-ID: <18fbdc4bf0574a722134400ad9e4510d3cbcb767.camel@pengutronix.de> Subject: Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe From: Lucas Stach To: Robin Gong , Shengjiu Wang Cc: Nicolin Chen , Linux-ALSA , Liam Girdwood , "s.hauer@pengutronix.de" , Timur Tabi , Xiubo Li , "shawnguo@kernel.org" , "S.j. Wang" , linux-kernel , "dri-devel@lists.freedesktop.org" , Takashi Iwai , "linaro-mm-sig@lists.linaro.org" , Mark Brown , dl-linux-imx , "kernel@pengutronix.de" , Fabio Estevam , "perex@perex.cz" , "linuxppc-dev@lists.ozlabs.org" , "sumit.semwal@linaro.org" , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" Date: Wed, 21 Apr 2021 19:43:18 +0200 In-Reply-To: References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com> <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de> <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de> <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de> <97262466d537402ad4032098ef277d6d47734f1f.camel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Mittwoch, dem 21.04.2021 um 14:54 +0000 schrieb Robin Gong: > On 20201/04/20 22:01 Lucas Stach wrote: > > Am Dienstag, dem 20.04.2021 um 13:47 +0000 schrieb Robin Gong: > > > On 2021/04/19 17:46 Lucas Stach wrote: > > > > Am Montag, dem 19.04.2021 um 07:17 +0000 schrieb Robin Gong: > > > > > Hi Lucas, > > > > > > > > > > On 2021/04/14 Lucas Stach wrote: > > > > > > Hi Robin, > > > > > > > > > > > > Am Mittwoch, dem 14.04.2021 um 14:33 +0000 schrieb Robin Gong: > > > > > > > On 2020/05/20 17:43 Lucas Stach wrote: > > > > > > > > Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu > > Wang: > > > > > > > > > Hi > > > > > > > > > > > > > > > > > > On Tue, May 19, 2020 at 6:04 PM Lucas Stach > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu > > Wang: > > > > > > > > > > > There are two requirements that we need to move the > > > > > > > > > > > request of dma channel from probe to open. > > > > > > > > > > > > > > > > > > > > How do you handle -EPROBE_DEFER return code from the > > > > > > > > > > channel request if you don't do it in probe? > > > > > > > > > > > > > > > > > > I use the dma_request_slave_channel or dma_request_channel > > > > > > > > > instead of dmaengine_pcm_request_chan_of. so there should > > > > > > > > > be not -EPROBE_DEFER return code. > > > > > > > > > > > > > > > > This is a pretty weak argument. The dmaengine device might > > > > > > > > probe after you try to get the channel. Using a function to > > > > > > > > request the channel that doesn't allow you to handle probe > > > > > > > > deferral is IMHO a bug and should be fixed, instead of > > > > > > > > building even more assumptions on top > > > > > > of it. > > > > > > > > > > > > > > > > > > > - When dma device binds with power-domains, the power > > > > > > > > > > > will be enabled when we request dma channel. If the > > > > > > > > > > > request of dma channel happen on probe, then the > > > > > > > > > > > power-domains will be always enabled after kernel boot > > > > > > > > > > > up, which is not good for power saving, so we need > > > > > > > > > > > to move the request of dma channel to .open(); > > > > > > > > > > > > > > > > > > > > This is certainly something which could be fixed in the > > > > > > > > > > dmaengine driver. > > > > > > > > > > > > > > > > > > Dma driver always call the pm_runtime_get_sync in > > > > > > > > > device_alloc_chan_resources, the > > > > > > > > > device_alloc_chan_resources is called when channel is > > > > > > > > > requested. so power is enabled on channel > > > > > > request. > > > > > > > > > > > > > > > > So why can't you fix the dmaengine driver to do that RPM > > > > > > > > call at a later time when the channel is actually going to > > > > > > > > be used? This will allow further power savings with other > > > > > > > > slave devices than the audio > > > > PCM. > > > > > > > Hi Lucas, > > > > > > >   Thanks for your suggestion. I have tried to implement > > > > > > > runtime autosuspend in fsl-edma driver on i.mx8qm/qxp with > > > > > > > delay time (2 > > > > > > > sec) for this feature as below (or you can refer to > > > > > > > drivers/dma/qcom/hidma.c), and pm_runtime_get_sync/ > > > > > > > pm_runtime_put_autosuspend in all dmaengine driver interface > > > > > > > like > > > > > > > device_alloc_chan_resources/device_prep_slave_sg/device_prep_d > > > > > > > ma_c > > > > > > > ycli > > > > > > > c/ > > > > > > > device_tx_status... > > > > > > > > > > > > > > > > > > > > >                 pm_runtime_use_autosuspend(fsl_chan->de > > v); > > > > > > >                 pm_runtime_set_autosuspend_delay(fsl_cha > > n-> > > > > dev, > > > > > > 2000); > > > > > > > > > > > > > > That could resolve this audio case since the autosuspend could > > > > > > > suspend runtime after > > > > > > > 2 seconds if there is no further dma transfer but only channel > > > > > > request(device_alloc_chan_resources). > > > > > > > But unfortunately, it cause another issue. As you know, on our > > > > > > > i.mx8qm/qxp, power domain done by scfw > > > > > > > (drivers/firmware/imx/scu-pd.c) > > > > > > over mailbox: > > > > > > >  imx_sc_pd_power()->imx_scu_call_rpc()-> > > > > > > > imx_scu_ipc_write()->mbox_send_message() > > > > > > > which means have to 'waits for completion', meanwhile, some > > > > > > > driver like tty will call dmaengine interfaces in non-atomic > > > > > > > case as below, > > > > > > > > > > > > > > static int uart_write(struct tty_struct *tty, const unsigned > > > > > > > char *buf, int count) { > > > > > > >    ....... > > > > > > > port = uart_port_lock(state, flags); > > > > > > >    ...... > > > > > > >         __uart_start(tty); //call > > > > start_tx()->dmaengine_prep_slave_sg... > > > > > > >         uart_port_unlock(port, flags); > > > > > > >         return ret; > > > > > > > } > > > > > > > > > > > > > > Thus dma runtime resume may happen in that timing window and > > > > > > > cause > > > > > > kernel alarm. > > > > > > > I'm not sure whether there are similar limitations on other > > > > > > > driver subsystem. But for me, It looks like the only way to > > > > > > > resolve the contradiction between tty and scu-pd (hardware > > > > > > > limitation on > > > > > > > i.mx8qm/qxp) is to give up autosuspend and keep > > > > > > > pm_runtime_get_sync > > > > > > only in device_alloc_chan_resources because request channel is a > > > > > > safe non-atomic phase. > > > > > > > Do you have any idea? Thanks in advance. > > > > > > > > > > > > If you look closely at the driver you used as an example > > > > > > (hidma.c) it looks like there is already something in there, > > > > > > which looks very much like what you need > > > > > > here: > > > > > > > > > > > > In hidma_issue_pending() the driver tries to get the device to > > > > > > runtime > > > > resume. > > > > > > If this doesn't work, maybe due to the power domain code not > > > > > > being able to be called in atomic context, the actual work of > > > > > > waking up the dma hardware and issuing the descriptor is shunted to a > > tasklet. > > > > > > > > > > > > If I'm reading this right, this is exactly what you need here to > > > > > > be able to call the dmaengine code from atomic context: try the > > > > > > rpm get and issue immediately when possible, otherwise shunt the > > > > > > work to a > > > > > > non- atomic context where you can deal with the requirements of > > scu-pd. > > > > > Yes, I can schedule_work to worker to runtime resume edma channel > > > > > by > > > > calling scu-pd. > > > > > But that means all dmaengine interfaces should be taken care, not > > > > > only > > > > > issue_pending() but also > > > > > dmaengine_terminate_all()/dmaengine_pause()/dmaengine_resume()/ > > > > > dmaengine_tx_status(). Not sure why hidma only take care > > > > > issue_pending. Maybe their user case is just for memcpy/memset so > > > > > that no further complicate case as ALSA or TTY. > > > > > Besides, for autosuspend in cyclic, we have to add > > > > > pm_runtime_get_sync into interrupt handler as qcom/bam_dma.c. but > > > > > how could resolve the scu-pd's non-atmoic limitation in interrupt > > handler? > > > > > > > > Sure, this all needs some careful analysis on how those functions > > > > are called and what to do about atomic callers, but it should be > > > > doable. I don't see any fundamental issues here. > > > > > > > > I don't see why you would ever need to wake the hardware in an > > > > interrupt handler. Surely the hardware is already awake, as it > > > > wouldn't signal an interrupt otherwise. And for the issue with > > > > scu-pd you only care about the state transition of > > > > suspended->running. If the hardware is already running/awake, the > > > > runtime pm state handling is nothing more than bumping a refcount, > > > > which is atomic safe. Putting the HW in suspend is already handled > > asynchronously in a worker, so this is also atomic safe. > > > But with autosuspend used, in corner case, may runtime suspended > > > before falling Into edma interrupt handler if timeout happen with the > > > delay value of pm_runtime_set_autosuspend_delay(). Thus, can't touch > > > any edma interrupt status register unless runtime resume edma in > > > interrupt handler while runtime resume function based on scu-pd's power > > domain may block or sleep. > > > I have a simple workaround that disable runtime suspend in > > > issue_pending worker by calling pm_runtime_forbid() and then enable > > > runtime auto suspend in dmaengine_terminate_all so that we could > > > easily regard that edma channel is always in runtime resume between > > > issue_pending and channel terminated and ignore the above interrupt > > handler/scu-pd limitation. > > > > The IRQ handler is the point where you are informed by the hardware that a > > specific operation is complete. I don't see any use-case where it would be valid > > to drop the rpm refcount to 0 before the IRQ is handled. Surely the hardware > > needs to stay awake until the currently queued operations are complete and if > > the IRQ handler is the completion point the IRQ handler is the first point in > > time where your autosuspend timer should start to run. There should never be > > a situation where the timer expiry can get between IRQ signaling and the > > handler code running. > But the timer of runtime_auto_suspend decide when enter runtime suspend rather > than hardware, while transfer data size and transfer rate on IP bus decide when the > dma interrupt happen.  > But it isn't the hardware that decides to drop the rpm refcount to 0 and starting the autosuspend timer, it's the driver. > Generally, we can call pm_runtime_get_sync(fsl_chan->dev)/ > pm_runtime_mark_last_busy in interrupt handler to hope the runtime_auto_suspend > timer expiry later than interrupt coming, but if the transfer data size is larger in cyclic > and transfer rate is very slow like 115200 or lower on uart, the fix autosuspend timer > 100ms/200ms maybe not enough, hence, runtime suspend may execute meanwhile > the dma interrupt maybe triggered and caught by GIC(but interrupt handler prevent > by spin_lock_irqsave in pm_suspend_timer_fn() ), and then interrupt handler start > to run after runtime suspend. If your driver code drops the rpm refcount to 0 and starts the autosuspend timer while a cyclic transfer is still in flight this is clearly a bug. Autosuspend is not there to paper over driver bugs, but to amortize cost of actually suspending and resuming the hardware. Your driver code must still work even if the timeout is 0, i.e. the hardware is immediately suspended after you drop the rpm refcount to 0. If you still have transfers queued/in-flight the driver code must keep a rpm reference. Regards, Lucas From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 261E6C433B4 for ; Wed, 21 Apr 2021 17:44:40 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 911676141C for ; Wed, 21 Apr 2021 17:44:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 911676141C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 75C9E165D; Wed, 21 Apr 2021 19:43:45 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 75C9E165D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1619027075; bh=5opOIA8IF8guCfSmWp6LK9WzVcsPAyECHxIrHOJi00I=; h=Subject:From:To:Date:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=kCZmBd/Z6vAE1vC96PkXPMoQni6ODyjUgEGpmbFjiQtmX23cDvVF1MbdfDiVJbbHC qv7OXFUYPZb+KT8BnIPgBk/3MRGBIZKKjvIBSttI95FpQPrcVwyXOQJLvJZc2yz7a0 R0NlJy1bYt6z93S752yYDZmafKU16MR2gQUCP0x8= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id BEE92F8019B; Wed, 21 Apr 2021 19:43:44 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id D6C8AF80227; Wed, 21 Apr 2021 19:43:43 +0200 (CEST) Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 19094F800FE for ; Wed, 21 Apr 2021 19:43:30 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 19094F800FE Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lZGsj-0003PI-NV; Wed, 21 Apr 2021 19:43:21 +0200 Message-ID: <18fbdc4bf0574a722134400ad9e4510d3cbcb767.camel@pengutronix.de> Subject: Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe From: Lucas Stach To: Robin Gong , Shengjiu Wang Date: Wed, 21 Apr 2021 19:43:18 +0200 In-Reply-To: References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com> <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de> <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de> <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de> <97262466d537402ad4032098ef277d6d47734f1f.camel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: alsa-devel@alsa-project.org Cc: "sumit.semwal@linaro.org" , "linaro-mm-sig@lists.linaro.org" , Linux-ALSA , "linuxppc-dev@lists.ozlabs.org" , Timur Tabi , Xiubo Li , Fabio Estevam , "s.hauer@pengutronix.de" , Takashi Iwai , Liam Girdwood , "dri-devel@lists.freedesktop.org" , linux-kernel , Nicolin Chen , Mark Brown , dl-linux-imx , "kernel@pengutronix.de" , "shawnguo@kernel.org" , "S.j. Wang" , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Am Mittwoch, dem 21.04.2021 um 14:54 +0000 schrieb Robin Gong: > On 20201/04/20 22:01 Lucas Stach wrote: > > Am Dienstag, dem 20.04.2021 um 13:47 +0000 schrieb Robin Gong: > > > On 2021/04/19 17:46 Lucas Stach wrote: > > > > Am Montag, dem 19.04.2021 um 07:17 +0000 schrieb Robin Gong: > > > > > Hi Lucas, > > > > > > > > > > On 2021/04/14 Lucas Stach wrote: > > > > > > Hi Robin, > > > > > > > > > > > > Am Mittwoch, dem 14.04.2021 um 14:33 +0000 schrieb Robin Gong: > > > > > > > On 2020/05/20 17:43 Lucas Stach wrote: > > > > > > > > Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu > > Wang: > > > > > > > > > Hi > > > > > > > > > > > > > > > > > > On Tue, May 19, 2020 at 6:04 PM Lucas Stach > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu > > Wang: > > > > > > > > > > > There are two requirements that we need to move the > > > > > > > > > > > request of dma channel from probe to open. > > > > > > > > > > > > > > > > > > > > How do you handle -EPROBE_DEFER return code from the > > > > > > > > > > channel request if you don't do it in probe? > > > > > > > > > > > > > > > > > > I use the dma_request_slave_channel or dma_request_channel > > > > > > > > > instead of dmaengine_pcm_request_chan_of. so there should > > > > > > > > > be not -EPROBE_DEFER return code. > > > > > > > > > > > > > > > > This is a pretty weak argument. The dmaengine device might > > > > > > > > probe after you try to get the channel. Using a function to > > > > > > > > request the channel that doesn't allow you to handle probe > > > > > > > > deferral is IMHO a bug and should be fixed, instead of > > > > > > > > building even more assumptions on top > > > > > > of it. > > > > > > > > > > > > > > > > > > > - When dma device binds with power-domains, the power > > > > > > > > > > > will be enabled when we request dma channel. If the > > > > > > > > > > > request of dma channel happen on probe, then the > > > > > > > > > > > power-domains will be always enabled after kernel boot > > > > > > > > > > > up, which is not good for power saving, so we need > > > > > > > > > > > to move the request of dma channel to .open(); > > > > > > > > > > > > > > > > > > > > This is certainly something which could be fixed in the > > > > > > > > > > dmaengine driver. > > > > > > > > > > > > > > > > > > Dma driver always call the pm_runtime_get_sync in > > > > > > > > > device_alloc_chan_resources, the > > > > > > > > > device_alloc_chan_resources is called when channel is > > > > > > > > > requested. so power is enabled on channel > > > > > > request. > > > > > > > > > > > > > > > > So why can't you fix the dmaengine driver to do that RPM > > > > > > > > call at a later time when the channel is actually going to > > > > > > > > be used? This will allow further power savings with other > > > > > > > > slave devices than the audio > > > > PCM. > > > > > > > Hi Lucas, > > > > > > >   Thanks for your suggestion. I have tried to implement > > > > > > > runtime autosuspend in fsl-edma driver on i.mx8qm/qxp with > > > > > > > delay time (2 > > > > > > > sec) for this feature as below (or you can refer to > > > > > > > drivers/dma/qcom/hidma.c), and pm_runtime_get_sync/ > > > > > > > pm_runtime_put_autosuspend in all dmaengine driver interface > > > > > > > like > > > > > > > device_alloc_chan_resources/device_prep_slave_sg/device_prep_d > > > > > > > ma_c > > > > > > > ycli > > > > > > > c/ > > > > > > > device_tx_status... > > > > > > > > > > > > > > > > > > > > >                 pm_runtime_use_autosuspend(fsl_chan->de > > v); > > > > > > >                 pm_runtime_set_autosuspend_delay(fsl_cha > > n-> > > > > dev, > > > > > > 2000); > > > > > > > > > > > > > > That could resolve this audio case since the autosuspend could > > > > > > > suspend runtime after > > > > > > > 2 seconds if there is no further dma transfer but only channel > > > > > > request(device_alloc_chan_resources). > > > > > > > But unfortunately, it cause another issue. As you know, on our > > > > > > > i.mx8qm/qxp, power domain done by scfw > > > > > > > (drivers/firmware/imx/scu-pd.c) > > > > > > over mailbox: > > > > > > >  imx_sc_pd_power()->imx_scu_call_rpc()-> > > > > > > > imx_scu_ipc_write()->mbox_send_message() > > > > > > > which means have to 'waits for completion', meanwhile, some > > > > > > > driver like tty will call dmaengine interfaces in non-atomic > > > > > > > case as below, > > > > > > > > > > > > > > static int uart_write(struct tty_struct *tty, const unsigned > > > > > > > char *buf, int count) { > > > > > > >    ....... > > > > > > > port = uart_port_lock(state, flags); > > > > > > >    ...... > > > > > > >         __uart_start(tty); //call > > > > start_tx()->dmaengine_prep_slave_sg... > > > > > > >         uart_port_unlock(port, flags); > > > > > > >         return ret; > > > > > > > } > > > > > > > > > > > > > > Thus dma runtime resume may happen in that timing window and > > > > > > > cause > > > > > > kernel alarm. > > > > > > > I'm not sure whether there are similar limitations on other > > > > > > > driver subsystem. But for me, It looks like the only way to > > > > > > > resolve the contradiction between tty and scu-pd (hardware > > > > > > > limitation on > > > > > > > i.mx8qm/qxp) is to give up autosuspend and keep > > > > > > > pm_runtime_get_sync > > > > > > only in device_alloc_chan_resources because request channel is a > > > > > > safe non-atomic phase. > > > > > > > Do you have any idea? Thanks in advance. > > > > > > > > > > > > If you look closely at the driver you used as an example > > > > > > (hidma.c) it looks like there is already something in there, > > > > > > which looks very much like what you need > > > > > > here: > > > > > > > > > > > > In hidma_issue_pending() the driver tries to get the device to > > > > > > runtime > > > > resume. > > > > > > If this doesn't work, maybe due to the power domain code not > > > > > > being able to be called in atomic context, the actual work of > > > > > > waking up the dma hardware and issuing the descriptor is shunted to a > > tasklet. > > > > > > > > > > > > If I'm reading this right, this is exactly what you need here to > > > > > > be able to call the dmaengine code from atomic context: try the > > > > > > rpm get and issue immediately when possible, otherwise shunt the > > > > > > work to a > > > > > > non- atomic context where you can deal with the requirements of > > scu-pd. > > > > > Yes, I can schedule_work to worker to runtime resume edma channel > > > > > by > > > > calling scu-pd. > > > > > But that means all dmaengine interfaces should be taken care, not > > > > > only > > > > > issue_pending() but also > > > > > dmaengine_terminate_all()/dmaengine_pause()/dmaengine_resume()/ > > > > > dmaengine_tx_status(). Not sure why hidma only take care > > > > > issue_pending. Maybe their user case is just for memcpy/memset so > > > > > that no further complicate case as ALSA or TTY. > > > > > Besides, for autosuspend in cyclic, we have to add > > > > > pm_runtime_get_sync into interrupt handler as qcom/bam_dma.c. but > > > > > how could resolve the scu-pd's non-atmoic limitation in interrupt > > handler? > > > > > > > > Sure, this all needs some careful analysis on how those functions > > > > are called and what to do about atomic callers, but it should be > > > > doable. I don't see any fundamental issues here. > > > > > > > > I don't see why you would ever need to wake the hardware in an > > > > interrupt handler. Surely the hardware is already awake, as it > > > > wouldn't signal an interrupt otherwise. And for the issue with > > > > scu-pd you only care about the state transition of > > > > suspended->running. If the hardware is already running/awake, the > > > > runtime pm state handling is nothing more than bumping a refcount, > > > > which is atomic safe. Putting the HW in suspend is already handled > > asynchronously in a worker, so this is also atomic safe. > > > But with autosuspend used, in corner case, may runtime suspended > > > before falling Into edma interrupt handler if timeout happen with the > > > delay value of pm_runtime_set_autosuspend_delay(). Thus, can't touch > > > any edma interrupt status register unless runtime resume edma in > > > interrupt handler while runtime resume function based on scu-pd's power > > domain may block or sleep. > > > I have a simple workaround that disable runtime suspend in > > > issue_pending worker by calling pm_runtime_forbid() and then enable > > > runtime auto suspend in dmaengine_terminate_all so that we could > > > easily regard that edma channel is always in runtime resume between > > > issue_pending and channel terminated and ignore the above interrupt > > handler/scu-pd limitation. > > > > The IRQ handler is the point where you are informed by the hardware that a > > specific operation is complete. I don't see any use-case where it would be valid > > to drop the rpm refcount to 0 before the IRQ is handled. Surely the hardware > > needs to stay awake until the currently queued operations are complete and if > > the IRQ handler is the completion point the IRQ handler is the first point in > > time where your autosuspend timer should start to run. There should never be > > a situation where the timer expiry can get between IRQ signaling and the > > handler code running. > But the timer of runtime_auto_suspend decide when enter runtime suspend rather > than hardware, while transfer data size and transfer rate on IP bus decide when the > dma interrupt happen.  > But it isn't the hardware that decides to drop the rpm refcount to 0 and starting the autosuspend timer, it's the driver. > Generally, we can call pm_runtime_get_sync(fsl_chan->dev)/ > pm_runtime_mark_last_busy in interrupt handler to hope the runtime_auto_suspend > timer expiry later than interrupt coming, but if the transfer data size is larger in cyclic > and transfer rate is very slow like 115200 or lower on uart, the fix autosuspend timer > 100ms/200ms maybe not enough, hence, runtime suspend may execute meanwhile > the dma interrupt maybe triggered and caught by GIC(but interrupt handler prevent > by spin_lock_irqsave in pm_suspend_timer_fn() ), and then interrupt handler start > to run after runtime suspend. If your driver code drops the rpm refcount to 0 and starts the autosuspend timer while a cyclic transfer is still in flight this is clearly a bug. Autosuspend is not there to paper over driver bugs, but to amortize cost of actually suspending and resuming the hardware. Your driver code must still work even if the timeout is 0, i.e. the hardware is immediately suspended after you drop the rpm refcount to 0. If you still have transfers queued/in-flight the driver code must keep a rpm reference. Regards, Lucas From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1BD58C433ED for ; Wed, 21 Apr 2021 17:44:20 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 01C766113B for ; Wed, 21 Apr 2021 17:44:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 01C766113B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4FQSbj08pNz30Ff for ; Thu, 22 Apr 2021 03:44:17 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=pengutronix.de (client-ip=2001:67c:670:201:290:27ff:fe1d:cc33; helo=metis.ext.pengutronix.de; envelope-from=l.stach@pengutronix.de; receiver=) Received: from metis.ext.pengutronix.de (unknown [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4FQSbJ4FyRz2yhq for ; Thu, 22 Apr 2021 03:43:54 +1000 (AEST) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lZGsj-0003PI-NV; Wed, 21 Apr 2021 19:43:21 +0200 Message-ID: <18fbdc4bf0574a722134400ad9e4510d3cbcb767.camel@pengutronix.de> Subject: Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe From: Lucas Stach To: Robin Gong , Shengjiu Wang Date: Wed, 21 Apr 2021 19:43:18 +0200 In-Reply-To: References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com> <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de> <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de> <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de> <97262466d537402ad4032098ef277d6d47734f1f.camel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linuxppc-dev@lists.ozlabs.org X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "sumit.semwal@linaro.org" , "linaro-mm-sig@lists.linaro.org" , Linux-ALSA , "linuxppc-dev@lists.ozlabs.org" , Timur Tabi , Xiubo Li , Fabio Estevam , "s.hauer@pengutronix.de" , Takashi Iwai , Liam Girdwood , "dri-devel@lists.freedesktop.org" , linux-kernel , Nicolin Chen , Mark Brown , dl-linux-imx , "kernel@pengutronix.de" , "perex@perex.cz" , "shawnguo@kernel.org" , "S.j. Wang" , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Am Mittwoch, dem 21.04.2021 um 14:54 +0000 schrieb Robin Gong: > On 20201/04/20 22:01 Lucas Stach wrote: > > Am Dienstag, dem 20.04.2021 um 13:47 +0000 schrieb Robin Gong: > > > On 2021/04/19 17:46 Lucas Stach wrote: > > > > Am Montag, dem 19.04.2021 um 07:17 +0000 schrieb Robin Gong: > > > > > Hi Lucas, > > > > > > > > > > On 2021/04/14 Lucas Stach wrote: > > > > > > Hi Robin, > > > > > > > > > > > > Am Mittwoch, dem 14.04.2021 um 14:33 +0000 schrieb Robin Gong: > > > > > > > On 2020/05/20 17:43 Lucas Stach wrote: > > > > > > > > Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu > > Wang: > > > > > > > > > Hi > > > > > > > > > > > > > > > > > > On Tue, May 19, 2020 at 6:04 PM Lucas Stach > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu > > Wang: > > > > > > > > > > > There are two requirements that we need to move the > > > > > > > > > > > request of dma channel from probe to open. > > > > > > > > > > > > > > > > > > > > How do you handle -EPROBE_DEFER return code from the > > > > > > > > > > channel request if you don't do it in probe? > > > > > > > > > > > > > > > > > > I use the dma_request_slave_channel or dma_request_channel > > > > > > > > > instead of dmaengine_pcm_request_chan_of. so there should > > > > > > > > > be not -EPROBE_DEFER return code. > > > > > > > > > > > > > > > > This is a pretty weak argument. The dmaengine device might > > > > > > > > probe after you try to get the channel. Using a function to > > > > > > > > request the channel that doesn't allow you to handle probe > > > > > > > > deferral is IMHO a bug and should be fixed, instead of > > > > > > > > building even more assumptions on top > > > > > > of it. > > > > > > > > > > > > > > > > > > > - When dma device binds with power-domains, the power > > > > > > > > > > > will be enabled when we request dma channel. If the > > > > > > > > > > > request of dma channel happen on probe, then the > > > > > > > > > > > power-domains will be always enabled after kernel boot > > > > > > > > > > > up, which is not good for power saving, so we need > > > > > > > > > > > to move the request of dma channel to .open(); > > > > > > > > > > > > > > > > > > > > This is certainly something which could be fixed in the > > > > > > > > > > dmaengine driver. > > > > > > > > > > > > > > > > > > Dma driver always call the pm_runtime_get_sync in > > > > > > > > > device_alloc_chan_resources, the > > > > > > > > > device_alloc_chan_resources is called when channel is > > > > > > > > > requested. so power is enabled on channel > > > > > > request. > > > > > > > > > > > > > > > > So why can't you fix the dmaengine driver to do that RPM > > > > > > > > call at a later time when the channel is actually going to > > > > > > > > be used? This will allow further power savings with other > > > > > > > > slave devices than the audio > > > > PCM. > > > > > > > Hi Lucas, > > > > > > >   Thanks for your suggestion. I have tried to implement > > > > > > > runtime autosuspend in fsl-edma driver on i.mx8qm/qxp with > > > > > > > delay time (2 > > > > > > > sec) for this feature as below (or you can refer to > > > > > > > drivers/dma/qcom/hidma.c), and pm_runtime_get_sync/ > > > > > > > pm_runtime_put_autosuspend in all dmaengine driver interface > > > > > > > like > > > > > > > device_alloc_chan_resources/device_prep_slave_sg/device_prep_d > > > > > > > ma_c > > > > > > > ycli > > > > > > > c/ > > > > > > > device_tx_status... > > > > > > > > > > > > > > > > > > > > >                 pm_runtime_use_autosuspend(fsl_chan->de > > v); > > > > > > >                 pm_runtime_set_autosuspend_delay(fsl_cha > > n-> > > > > dev, > > > > > > 2000); > > > > > > > > > > > > > > That could resolve this audio case since the autosuspend could > > > > > > > suspend runtime after > > > > > > > 2 seconds if there is no further dma transfer but only channel > > > > > > request(device_alloc_chan_resources). > > > > > > > But unfortunately, it cause another issue. As you know, on our > > > > > > > i.mx8qm/qxp, power domain done by scfw > > > > > > > (drivers/firmware/imx/scu-pd.c) > > > > > > over mailbox: > > > > > > >  imx_sc_pd_power()->imx_scu_call_rpc()-> > > > > > > > imx_scu_ipc_write()->mbox_send_message() > > > > > > > which means have to 'waits for completion', meanwhile, some > > > > > > > driver like tty will call dmaengine interfaces in non-atomic > > > > > > > case as below, > > > > > > > > > > > > > > static int uart_write(struct tty_struct *tty, const unsigned > > > > > > > char *buf, int count) { > > > > > > >    ....... > > > > > > > port = uart_port_lock(state, flags); > > > > > > >    ...... > > > > > > >         __uart_start(tty); //call > > > > start_tx()->dmaengine_prep_slave_sg... > > > > > > >         uart_port_unlock(port, flags); > > > > > > >         return ret; > > > > > > > } > > > > > > > > > > > > > > Thus dma runtime resume may happen in that timing window and > > > > > > > cause > > > > > > kernel alarm. > > > > > > > I'm not sure whether there are similar limitations on other > > > > > > > driver subsystem. But for me, It looks like the only way to > > > > > > > resolve the contradiction between tty and scu-pd (hardware > > > > > > > limitation on > > > > > > > i.mx8qm/qxp) is to give up autosuspend and keep > > > > > > > pm_runtime_get_sync > > > > > > only in device_alloc_chan_resources because request channel is a > > > > > > safe non-atomic phase. > > > > > > > Do you have any idea? Thanks in advance. > > > > > > > > > > > > If you look closely at the driver you used as an example > > > > > > (hidma.c) it looks like there is already something in there, > > > > > > which looks very much like what you need > > > > > > here: > > > > > > > > > > > > In hidma_issue_pending() the driver tries to get the device to > > > > > > runtime > > > > resume. > > > > > > If this doesn't work, maybe due to the power domain code not > > > > > > being able to be called in atomic context, the actual work of > > > > > > waking up the dma hardware and issuing the descriptor is shunted to a > > tasklet. > > > > > > > > > > > > If I'm reading this right, this is exactly what you need here to > > > > > > be able to call the dmaengine code from atomic context: try the > > > > > > rpm get and issue immediately when possible, otherwise shunt the > > > > > > work to a > > > > > > non- atomic context where you can deal with the requirements of > > scu-pd. > > > > > Yes, I can schedule_work to worker to runtime resume edma channel > > > > > by > > > > calling scu-pd. > > > > > But that means all dmaengine interfaces should be taken care, not > > > > > only > > > > > issue_pending() but also > > > > > dmaengine_terminate_all()/dmaengine_pause()/dmaengine_resume()/ > > > > > dmaengine_tx_status(). Not sure why hidma only take care > > > > > issue_pending. Maybe their user case is just for memcpy/memset so > > > > > that no further complicate case as ALSA or TTY. > > > > > Besides, for autosuspend in cyclic, we have to add > > > > > pm_runtime_get_sync into interrupt handler as qcom/bam_dma.c. but > > > > > how could resolve the scu-pd's non-atmoic limitation in interrupt > > handler? > > > > > > > > Sure, this all needs some careful analysis on how those functions > > > > are called and what to do about atomic callers, but it should be > > > > doable. I don't see any fundamental issues here. > > > > > > > > I don't see why you would ever need to wake the hardware in an > > > > interrupt handler. Surely the hardware is already awake, as it > > > > wouldn't signal an interrupt otherwise. And for the issue with > > > > scu-pd you only care about the state transition of > > > > suspended->running. If the hardware is already running/awake, the > > > > runtime pm state handling is nothing more than bumping a refcount, > > > > which is atomic safe. Putting the HW in suspend is already handled > > asynchronously in a worker, so this is also atomic safe. > > > But with autosuspend used, in corner case, may runtime suspended > > > before falling Into edma interrupt handler if timeout happen with the > > > delay value of pm_runtime_set_autosuspend_delay(). Thus, can't touch > > > any edma interrupt status register unless runtime resume edma in > > > interrupt handler while runtime resume function based on scu-pd's power > > domain may block or sleep. > > > I have a simple workaround that disable runtime suspend in > > > issue_pending worker by calling pm_runtime_forbid() and then enable > > > runtime auto suspend in dmaengine_terminate_all so that we could > > > easily regard that edma channel is always in runtime resume between > > > issue_pending and channel terminated and ignore the above interrupt > > handler/scu-pd limitation. > > > > The IRQ handler is the point where you are informed by the hardware that a > > specific operation is complete. I don't see any use-case where it would be valid > > to drop the rpm refcount to 0 before the IRQ is handled. Surely the hardware > > needs to stay awake until the currently queued operations are complete and if > > the IRQ handler is the completion point the IRQ handler is the first point in > > time where your autosuspend timer should start to run. There should never be > > a situation where the timer expiry can get between IRQ signaling and the > > handler code running. > But the timer of runtime_auto_suspend decide when enter runtime suspend rather > than hardware, while transfer data size and transfer rate on IP bus decide when the > dma interrupt happen.  > But it isn't the hardware that decides to drop the rpm refcount to 0 and starting the autosuspend timer, it's the driver. > Generally, we can call pm_runtime_get_sync(fsl_chan->dev)/ > pm_runtime_mark_last_busy in interrupt handler to hope the runtime_auto_suspend > timer expiry later than interrupt coming, but if the transfer data size is larger in cyclic > and transfer rate is very slow like 115200 or lower on uart, the fix autosuspend timer > 100ms/200ms maybe not enough, hence, runtime suspend may execute meanwhile > the dma interrupt maybe triggered and caught by GIC(but interrupt handler prevent > by spin_lock_irqsave in pm_suspend_timer_fn() ), and then interrupt handler start > to run after runtime suspend. If your driver code drops the rpm refcount to 0 and starts the autosuspend timer while a cyclic transfer is still in flight this is clearly a bug. Autosuspend is not there to paper over driver bugs, but to amortize cost of actually suspending and resuming the hardware. Your driver code must still work even if the timeout is 0, i.e. the hardware is immediately suspended after you drop the rpm refcount to 0. If you still have transfers queued/in-flight the driver code must keep a rpm reference. Regards, Lucas From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D6C5C433B4 for ; Wed, 21 Apr 2021 17:46:03 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 263CA6140D for ; Wed, 21 Apr 2021 17:46:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 263CA6140D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Date:Cc:To:From: Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YUu/rQp2IDThw25FNY/s2x10pguh9ZUccicEYZhfqmM=; b=ZtldPZ/OP5X6ToccPCPtqYQ6J /uygz4ubZuX/aARFZu6LdrqAtyoEHW4NIJzmeaT58a2HWovHrrqU7iMy1T0Le95bYWzVvR5OgcKF7 7GifdLiFIfEtO53sFn64qPowuvvbOvvV8kmL+Re4rEOcy3kDLdTyJx8os3SYC3HW6L2M0j1ODsXs3 evOJVyWB2mslVwz1JI6s7Xg9mPhJTUS3hWA378GZhCAO2G30QugPAWcmGPKapD2HRPVk5vBFwNNNe jqqaxXDI7/R0RqdVaumW3KK+uJOgf71UfvFne4XrpqZuBL55HoLudZQcrfOrVTFl7/t6CYu3Y6YAp WvqviehbQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lZGtV-00Eu0Z-HB; Wed, 21 Apr 2021 17:44:09 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lZGtS-00Eu0H-4i for linux-arm-kernel@desiato.infradead.org; Wed, 21 Apr 2021 17:44:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: MIME-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject: Message-ID:Sender:Reply-To:Content-ID:Content-Description; bh=pSaoQfhMP9YvKtNEIjrjBKqb+2YF3JK2leInzTybk2s=; b=eXkQGlLqKLghU1xX+bNaxFPv79 Eo/tVFf83ZC+KupYWWwKEzYG+eR1c5R56yI0EXd+49zokDvzf3QfmEORqYmlLr7YRLkhM0B26Fs/Z sN1ZPQlpvaSAES8kC/0eyhApseQV44biKbg/pHWYH9+mbR9CwWXpY7g3twqr7fO7HqrVP9xk+JAL6 aChXLn9sUA6w3wGi9u4cWSyvlJr3Lo6KOnNaWkI0AY4G4Q453ie+nRh25Cwk73e0mbJN8XQhLG009 AnB4VqsW1VRDMq+Xsiuna2CVhrqRB2kE+hdYcqVsADPnCoxuFlMdGYbIqTalLdEFXSarkGv0ij2lp Lf1sAVdQ==; Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lZGtN-00D4Y8-Dt for linux-arm-kernel@lists.infradead.org; Wed, 21 Apr 2021 17:44:04 +0000 Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lZGsj-0003PI-NV; Wed, 21 Apr 2021 19:43:21 +0200 Message-ID: <18fbdc4bf0574a722134400ad9e4510d3cbcb767.camel@pengutronix.de> Subject: Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe From: Lucas Stach To: Robin Gong , Shengjiu Wang Cc: Nicolin Chen , Linux-ALSA , Liam Girdwood , "s.hauer@pengutronix.de" , Timur Tabi , Xiubo Li , "shawnguo@kernel.org" , "S.j. Wang" , linux-kernel , "dri-devel@lists.freedesktop.org" , Takashi Iwai , "linaro-mm-sig@lists.linaro.org" , Mark Brown , dl-linux-imx , "kernel@pengutronix.de" , Fabio Estevam , "perex@perex.cz" , "linuxppc-dev@lists.ozlabs.org" , "sumit.semwal@linaro.org" , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" Date: Wed, 21 Apr 2021 19:43:18 +0200 In-Reply-To: References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com> <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de> <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de> <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de> <97262466d537402ad4032098ef277d6d47734f1f.camel@pengutronix.de> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210421_104401_661265_02ABB6EE X-CRM114-Status: GOOD ( 72.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org QW0gTWl0dHdvY2gsIGRlbSAyMS4wNC4yMDIxIHVtIDE0OjU0ICswMDAwIHNjaHJpZWIgUm9iaW4g R29uZzoKPiBPbiAyMDIwMS8wNC8yMCAyMjowMSBMdWNhcyBTdGFjaCA8bC5zdGFjaEBwZW5ndXRy b25peC5kZT4gd3JvdGU6Cj4gPiBBbSBEaWVuc3RhZywgZGVtIDIwLjA0LjIwMjEgdW0gMTM6NDcg KzAwMDAgc2NocmllYiBSb2JpbiBHb25nOgo+ID4gPiBPbiAyMDIxLzA0LzE5IDE3OjQ2IEx1Y2Fz IFN0YWNoIDxsLnN0YWNoQHBlbmd1dHJvbml4LmRlPiB3cm90ZToKPiA+ID4gPiBBbSBNb250YWcs IGRlbSAxOS4wNC4yMDIxIHVtIDA3OjE3ICswMDAwIHNjaHJpZWIgUm9iaW4gR29uZzoKPiA+ID4g PiA+IEhpIEx1Y2FzLAo+ID4gPiA+ID4gCj4gPiA+ID4gPiBPbiAyMDIxLzA0LzE0IEx1Y2FzIFN0 YWNoIDxsLnN0YWNoQHBlbmd1dHJvbml4LmRlPiB3cm90ZToKPiA+ID4gPiA+ID4gSGkgUm9iaW4s Cj4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiBBbSBNaXR0d29jaCwgZGVtIDE0LjA0LjIwMjEgdW0g MTQ6MzMgKzAwMDAgc2NocmllYiBSb2JpbiBHb25nOgo+ID4gPiA+ID4gPiA+IE9uIDIwMjAvMDUv MjAgMTc6NDMgTHVjYXMgU3RhY2ggPGwuc3RhY2hAcGVuZ3V0cm9uaXguZGU+IHdyb3RlOgo+ID4g PiA+ID4gPiA+ID4gQW0gTWl0dHdvY2gsIGRlbiAyMC4wNS4yMDIwLCAxNjoyMCArMDgwMCBzY2hy aWViIFNoZW5naml1Cj4gPiBXYW5nOgo+ID4gPiA+ID4gPiA+ID4gPiBIaQo+ID4gPiA+ID4gPiA+ ID4gPiAKPiA+ID4gPiA+ID4gPiA+ID4gT24gVHVlLCBNYXkgMTksIDIwMjAgYXQgNjowNCBQTSBM dWNhcyBTdGFjaAo+ID4gPiA+ID4gPiA+ID4gPiA8bC5zdGFjaEBwZW5ndXRyb25peC5kZT4KPiA+ ID4gPiA+ID4gPiA+IHdyb3RlOgo+ID4gPiA+ID4gPiA+ID4gPiA+IEFtIERpZW5zdGFnLCBkZW4g MTkuMDUuMjAyMCwgMTc6NDEgKzA4MDAgc2NocmllYiBTaGVuZ2ppdQo+ID4gV2FuZzoKPiA+ID4g PiA+ID4gPiA+ID4gPiA+IFRoZXJlIGFyZSB0d28gcmVxdWlyZW1lbnRzIHRoYXQgd2UgbmVlZCB0 byBtb3ZlIHRoZQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gcmVxdWVzdCBvZiBkbWEgY2hhbm5lbCBm cm9tIHByb2JlIHRvIG9wZW4uCj4gPiA+ID4gPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gPiA+ ID4gSG93IGRvIHlvdSBoYW5kbGUgLUVQUk9CRV9ERUZFUiByZXR1cm4gY29kZSBmcm9tIHRoZQo+ ID4gPiA+ID4gPiA+ID4gPiA+IGNoYW5uZWwgcmVxdWVzdCBpZiB5b3UgZG9uJ3QgZG8gaXQgaW4g cHJvYmU/Cj4gPiA+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+ID4gPiBJIHVzZSB0aGUgZG1h X3JlcXVlc3Rfc2xhdmVfY2hhbm5lbCBvciBkbWFfcmVxdWVzdF9jaGFubmVsCj4gPiA+ID4gPiA+ ID4gPiA+IGluc3RlYWQgb2YgZG1hZW5naW5lX3BjbV9yZXF1ZXN0X2NoYW5fb2YuIHNvIHRoZXJl IHNob3VsZAo+ID4gPiA+ID4gPiA+ID4gPiBiZSBub3QgLUVQUk9CRV9ERUZFUiByZXR1cm4gY29k ZS4KPiA+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+ID4gVGhpcyBpcyBhIHByZXR0eSB3ZWFr IGFyZ3VtZW50LiBUaGUgZG1hZW5naW5lIGRldmljZSBtaWdodAo+ID4gPiA+ID4gPiA+ID4gcHJv YmUgYWZ0ZXIgeW91IHRyeSB0byBnZXQgdGhlIGNoYW5uZWwuIFVzaW5nIGEgZnVuY3Rpb24gdG8K PiA+ID4gPiA+ID4gPiA+IHJlcXVlc3QgdGhlIGNoYW5uZWwgdGhhdCBkb2Vzbid0IGFsbG93IHlv dSB0byBoYW5kbGUgcHJvYmUKPiA+ID4gPiA+ID4gPiA+IGRlZmVycmFsIGlzIElNSE8gYSBidWcg YW5kIHNob3VsZCBiZSBmaXhlZCwgaW5zdGVhZCBvZgo+ID4gPiA+ID4gPiA+ID4gYnVpbGRpbmcg ZXZlbiBtb3JlIGFzc3VtcHRpb25zIG9uIHRvcAo+ID4gPiA+ID4gPiBvZiBpdC4KPiA+ID4gPiA+ ID4gPiA+IAo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gLSBXaGVuIGRtYSBkZXZpY2UgYmluZHMgd2l0 aCBwb3dlci1kb21haW5zLCB0aGUgcG93ZXIKPiA+ID4gPiA+ID4gPiA+ID4gPiA+IHdpbGwgYmUg ZW5hYmxlZCB3aGVuIHdlIHJlcXVlc3QgZG1hIGNoYW5uZWwuIElmIHRoZQo+ID4gPiA+ID4gPiA+ ID4gPiA+ID4gcmVxdWVzdCBvZiBkbWEgY2hhbm5lbCBoYXBwZW4gb24gcHJvYmUsIHRoZW4gdGhl Cj4gPiA+ID4gPiA+ID4gPiA+ID4gPiBwb3dlci1kb21haW5zIHdpbGwgYmUgYWx3YXlzIGVuYWJs ZWQgYWZ0ZXIga2VybmVsIGJvb3QKPiA+ID4gPiA+ID4gPiA+ID4gPiA+IHVwLCAgd2hpY2ggaXMg bm90IGdvb2QgZm9yIHBvd2VyIHNhdmluZywgIHNvIHdlIG5lZWQKPiA+ID4gPiA+ID4gPiA+ID4g PiA+IHRvIG1vdmUgdGhlIHJlcXVlc3Qgb2YgZG1hIGNoYW5uZWwgdG8gLm9wZW4oKTsKPiA+ID4g PiA+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gPiA+ID4gPiBUaGlzIGlzIGNlcnRhaW5seSBzb21l dGhpbmcgd2hpY2ggY291bGQgYmUgZml4ZWQgaW4gdGhlCj4gPiA+ID4gPiA+ID4gPiA+ID4gZG1h ZW5naW5lIGRyaXZlci4KPiA+ID4gPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gPiA+IERtYSBk cml2ZXIgYWx3YXlzIGNhbGwgdGhlIHBtX3J1bnRpbWVfZ2V0X3N5bmMgaW4KPiA+ID4gPiA+ID4g PiA+ID4gZGV2aWNlX2FsbG9jX2NoYW5fcmVzb3VyY2VzLCB0aGUKPiA+ID4gPiA+ID4gPiA+ID4g ZGV2aWNlX2FsbG9jX2NoYW5fcmVzb3VyY2VzIGlzIGNhbGxlZCB3aGVuIGNoYW5uZWwgaXMKPiA+ ID4gPiA+ID4gPiA+ID4gcmVxdWVzdGVkLiBzbyBwb3dlciBpcyBlbmFibGVkIG9uIGNoYW5uZWwK PiA+ID4gPiA+ID4gcmVxdWVzdC4KPiA+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+ID4gU28g d2h5IGNhbid0IHlvdSBmaXggdGhlIGRtYWVuZ2luZSBkcml2ZXIgdG8gZG8gdGhhdCBSUE0KPiA+ ID4gPiA+ID4gPiA+IGNhbGwgYXQgYSBsYXRlciB0aW1lIHdoZW4gdGhlIGNoYW5uZWwgaXMgYWN0 dWFsbHkgZ29pbmcgdG8KPiA+ID4gPiA+ID4gPiA+IGJlIHVzZWQ/IFRoaXMgd2lsbCBhbGxvdyBm dXJ0aGVyIHBvd2VyIHNhdmluZ3Mgd2l0aCBvdGhlcgo+ID4gPiA+ID4gPiA+ID4gc2xhdmUgZGV2 aWNlcyB0aGFuIHRoZSBhdWRpbwo+ID4gPiA+IFBDTS4KPiA+ID4gPiA+ID4gPiBIaSBMdWNhcywK PiA+ID4gPiA+ID4gPiDCoMKgVGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb24uIEkgaGF2ZSB0cmll ZCB0byBpbXBsZW1lbnQKPiA+ID4gPiA+ID4gPiBydW50aW1lIGF1dG9zdXNwZW5kIGluIGZzbC1l ZG1hIGRyaXZlciBvbiBpLm14OHFtL3F4cCB3aXRoCj4gPiA+ID4gPiA+ID4gZGVsYXkgdGltZSAo Mgo+ID4gPiA+ID4gPiA+IHNlYykgZm9yIHRoaXMgZmVhdHVyZSBhcyBiZWxvdyAob3IgeW91IGNh biByZWZlciB0bwo+ID4gPiA+ID4gPiA+IGRyaXZlcnMvZG1hL3Fjb20vaGlkbWEuYyksIGFuZCBw bV9ydW50aW1lX2dldF9zeW5jLwo+ID4gPiA+ID4gPiA+IHBtX3J1bnRpbWVfcHV0X2F1dG9zdXNw ZW5kIGluIGFsbCBkbWFlbmdpbmUgZHJpdmVyIGludGVyZmFjZQo+ID4gPiA+ID4gPiA+IGxpa2UK PiA+ID4gPiA+ID4gPiBkZXZpY2VfYWxsb2NfY2hhbl9yZXNvdXJjZXMvZGV2aWNlX3ByZXBfc2xh dmVfc2cvZGV2aWNlX3ByZXBfZAo+ID4gPiA+ID4gPiA+IG1hX2MKPiA+ID4gPiA+ID4gPiB5Y2xp Cj4gPiA+ID4gPiA+ID4gYy8KPiA+ID4gPiA+ID4gPiBkZXZpY2VfdHhfc3RhdHVzLi4uCj4gPiA+ ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqBwbV9ydW50aW1lX3VzZV9hdXRvc3VzcGVuZChmc2xfY2hhbi0+ZGUKPiA+ IHYpOwo+ID4gPiA+ID4gPiA+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgcG1fcnVu dGltZV9zZXRfYXV0b3N1c3BlbmRfZGVsYXkoZnNsX2NoYQo+ID4gbi0+Cj4gPiA+ID4gZGV2LAo+ ID4gPiA+ID4gPiAyMDAwKTsKPiA+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gPiBUaGF0IGNvdWxk IHJlc29sdmUgdGhpcyBhdWRpbyBjYXNlIHNpbmNlIHRoZSBhdXRvc3VzcGVuZCBjb3VsZAo+ID4g PiA+ID4gPiA+IHN1c3BlbmQgcnVudGltZSBhZnRlcgo+ID4gPiA+ID4gPiA+IDIgc2Vjb25kcyBp ZiB0aGVyZSBpcyBubyBmdXJ0aGVyIGRtYSB0cmFuc2ZlciBidXQgb25seSBjaGFubmVsCj4gPiA+ ID4gPiA+IHJlcXVlc3QoZGV2aWNlX2FsbG9jX2NoYW5fcmVzb3VyY2VzKS4KPiA+ID4gPiA+ID4g PiBCdXQgdW5mb3J0dW5hdGVseSwgaXQgY2F1c2UgYW5vdGhlciBpc3N1ZS4gQXMgeW91IGtub3cs IG9uIG91cgo+ID4gPiA+ID4gPiA+IGkubXg4cW0vcXhwLCBwb3dlciBkb21haW4gZG9uZSBieSBz Y2Z3Cj4gPiA+ID4gPiA+ID4gKGRyaXZlcnMvZmlybXdhcmUvaW14L3NjdS1wZC5jKQo+ID4gPiA+ ID4gPiBvdmVyIG1haWxib3g6Cj4gPiA+ID4gPiA+ID4gwqBpbXhfc2NfcGRfcG93ZXIoKS0+aW14 X3NjdV9jYWxsX3JwYygpLT4KPiA+ID4gPiA+ID4gPiBpbXhfc2N1X2lwY193cml0ZSgpLT5tYm94 X3NlbmRfbWVzc2FnZSgpCj4gPiA+ID4gPiA+ID4gd2hpY2ggbWVhbnMgaGF2ZSB0byAnd2FpdHMg Zm9yIGNvbXBsZXRpb24nLCBtZWFud2hpbGUsIHNvbWUKPiA+ID4gPiA+ID4gPiBkcml2ZXIgbGlr ZSB0dHkgd2lsbCBjYWxsIGRtYWVuZ2luZSBpbnRlcmZhY2VzIGluIG5vbi1hdG9taWMKPiA+ID4g PiA+ID4gPiBjYXNlIGFzIGJlbG93LAo+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+IHN0YXRp YyBpbnQgdWFydF93cml0ZShzdHJ1Y3QgdHR5X3N0cnVjdCAqdHR5LCBjb25zdCB1bnNpZ25lZAo+ ID4gPiA+ID4gPiA+IGNoYXIgKmJ1ZiwgaW50IGNvdW50KSB7Cj4gPiA+ID4gPiA+ID4gwqDCoMKg Li4uLi4uLgo+ID4gPiA+ID4gPiA+IAkgICAgcG9ydCA9IHVhcnRfcG9ydF9sb2NrKHN0YXRlLCBm bGFncyk7Cj4gPiA+ID4gPiA+ID4gwqDCoMKgLi4uLi4uCj4gPiA+ID4gPiA+ID4gwqDCoMKgwqDC oMKgwqDCoF9fdWFydF9zdGFydCh0dHkpOyAgLy9jYWxsCj4gPiA+ID4gc3RhcnRfdHgoKS0+ZG1h ZW5naW5lX3ByZXBfc2xhdmVfc2cuLi4KPiA+ID4gPiA+ID4gPiDCoMKgwqDCoMKgwqDCoMKgdWFy dF9wb3J0X3VubG9jayhwb3J0LCBmbGFncyk7Cj4gPiA+ID4gPiA+ID4gwqDCoMKgwqDCoMKgwqDC oHJldHVybiByZXQ7Cj4gPiA+ID4gPiA+ID4gfQo+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+ IFRodXMgZG1hIHJ1bnRpbWUgcmVzdW1lIG1heSBoYXBwZW4gaW4gdGhhdCB0aW1pbmcgd2luZG93 IGFuZAo+ID4gPiA+ID4gPiA+IGNhdXNlCj4gPiA+ID4gPiA+IGtlcm5lbCBhbGFybS4KPiA+ID4g PiA+ID4gPiBJJ20gbm90IHN1cmUgd2hldGhlciB0aGVyZSBhcmUgc2ltaWxhciBsaW1pdGF0aW9u cyBvbiBvdGhlcgo+ID4gPiA+ID4gPiA+IGRyaXZlciBzdWJzeXN0ZW0uIEJ1dCBmb3IgbWUsIEl0 IGxvb2tzIGxpa2UgdGhlIG9ubHkgd2F5IHRvCj4gPiA+ID4gPiA+ID4gcmVzb2x2ZSB0aGUgY29u dHJhZGljdGlvbiBiZXR3ZWVuIHR0eSBhbmQgc2N1LXBkIChoYXJkd2FyZQo+ID4gPiA+ID4gPiA+ IGxpbWl0YXRpb24gb24KPiA+ID4gPiA+ID4gPiBpLm14OHFtL3F4cCkgaXMgdG8gZ2l2ZSB1cCBh dXRvc3VzcGVuZCBhbmQga2VlcAo+ID4gPiA+ID4gPiA+IHBtX3J1bnRpbWVfZ2V0X3N5bmMKPiA+ ID4gPiA+ID4gb25seSBpbiBkZXZpY2VfYWxsb2NfY2hhbl9yZXNvdXJjZXMgYmVjYXVzZSByZXF1 ZXN0IGNoYW5uZWwgaXMgYQo+ID4gPiA+ID4gPiBzYWZlIG5vbi1hdG9taWMgcGhhc2UuCj4gPiA+ ID4gPiA+ID4gRG8geW91IGhhdmUgYW55IGlkZWE/IFRoYW5rcyBpbiBhZHZhbmNlLgo+ID4gPiA+ ID4gPiAKPiA+ID4gPiA+ID4gSWYgeW91IGxvb2sgY2xvc2VseSBhdCB0aGUgZHJpdmVyIHlvdSB1 c2VkIGFzIGFuIGV4YW1wbGUKPiA+ID4gPiA+ID4gKGhpZG1hLmMpIGl0IGxvb2tzIGxpa2UgdGhl cmUgaXMgYWxyZWFkeSBzb21ldGhpbmcgaW4gdGhlcmUsCj4gPiA+ID4gPiA+IHdoaWNoIGxvb2tz IHZlcnkgbXVjaCBsaWtlIHdoYXQgeW91IG5lZWQKPiA+ID4gPiA+ID4gaGVyZToKPiA+ID4gPiA+ ID4gCj4gPiA+ID4gPiA+IEluIGhpZG1hX2lzc3VlX3BlbmRpbmcoKSB0aGUgZHJpdmVyIHRyaWVz IHRvIGdldCB0aGUgZGV2aWNlIHRvCj4gPiA+ID4gPiA+IHJ1bnRpbWUKPiA+ID4gPiByZXN1bWUu Cj4gPiA+ID4gPiA+IElmIHRoaXMgZG9lc24ndCB3b3JrLCBtYXliZSBkdWUgdG8gdGhlIHBvd2Vy IGRvbWFpbiBjb2RlIG5vdAo+ID4gPiA+ID4gPiBiZWluZyBhYmxlIHRvIGJlIGNhbGxlZCBpbiBh dG9taWMgY29udGV4dCwgdGhlIGFjdHVhbCB3b3JrIG9mCj4gPiA+ID4gPiA+IHdha2luZyB1cCB0 aGUgZG1hIGhhcmR3YXJlIGFuZCBpc3N1aW5nIHRoZSBkZXNjcmlwdG9yIGlzIHNodW50ZWQgdG8g YQo+ID4gdGFza2xldC4KPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+IElmIEknbSByZWFkaW5nIHRo aXMgcmlnaHQsIHRoaXMgaXMgZXhhY3RseSB3aGF0IHlvdSBuZWVkIGhlcmUgdG8KPiA+ID4gPiA+ ID4gYmUgYWJsZSB0byBjYWxsIHRoZSBkbWFlbmdpbmUgY29kZSBmcm9tIGF0b21pYyBjb250ZXh0 OiB0cnkgdGhlCj4gPiA+ID4gPiA+IHJwbSBnZXQgYW5kIGlzc3VlIGltbWVkaWF0ZWx5IHdoZW4g cG9zc2libGUsIG90aGVyd2lzZSBzaHVudCB0aGUKPiA+ID4gPiA+ID4gd29yayB0byBhCj4gPiA+ ID4gPiA+IG5vbi0gYXRvbWljIGNvbnRleHQgd2hlcmUgeW91IGNhbiBkZWFsIHdpdGggdGhlIHJl cXVpcmVtZW50cyBvZgo+ID4gc2N1LXBkLgo+ID4gPiA+ID4gWWVzLCBJIGNhbiBzY2hlZHVsZV93 b3JrIHRvIHdvcmtlciB0byBydW50aW1lIHJlc3VtZSBlZG1hIGNoYW5uZWwKPiA+ID4gPiA+IGJ5 Cj4gPiA+ID4gY2FsbGluZyBzY3UtcGQuCj4gPiA+ID4gPiBCdXQgdGhhdCBtZWFucyBhbGwgZG1h ZW5naW5lIGludGVyZmFjZXMgc2hvdWxkIGJlIHRha2VuIGNhcmUsIG5vdAo+ID4gPiA+ID4gb25s eQo+ID4gPiA+ID4gaXNzdWVfcGVuZGluZygpIGJ1dCBhbHNvCj4gPiA+ID4gPiBkbWFlbmdpbmVf dGVybWluYXRlX2FsbCgpL2RtYWVuZ2luZV9wYXVzZSgpL2RtYWVuZ2luZV9yZXN1bWUoKS8KPiA+ ID4gPiA+IGRtYWVuZ2luZV90eF9zdGF0dXMoKS4gTm90IHN1cmUgd2h5IGhpZG1hIG9ubHkgdGFr ZSBjYXJlCj4gPiA+ID4gPiBpc3N1ZV9wZW5kaW5nLiBNYXliZSB0aGVpciB1c2VyIGNhc2UgaXMg anVzdCBmb3IgbWVtY3B5L21lbXNldCBzbwo+ID4gPiA+ID4gdGhhdCBubyBmdXJ0aGVyIGNvbXBs aWNhdGUgY2FzZSBhcyBBTFNBIG9yIFRUWS4KPiA+ID4gPiA+IEJlc2lkZXMsIGZvciBhdXRvc3Vz cGVuZCBpbiBjeWNsaWMsIHdlIGhhdmUgdG8gYWRkCj4gPiA+ID4gPiBwbV9ydW50aW1lX2dldF9z eW5jIGludG8gaW50ZXJydXB0IGhhbmRsZXIgYXMgcWNvbS9iYW1fZG1hLmMuIGJ1dAo+ID4gPiA+ ID4gaG93IGNvdWxkIHJlc29sdmUgdGhlIHNjdS1wZCdzIG5vbi1hdG1vaWMgbGltaXRhdGlvbiBp biBpbnRlcnJ1cHQKPiA+IGhhbmRsZXI/Cj4gPiA+ID4gCj4gPiA+ID4gU3VyZSwgdGhpcyBhbGwg bmVlZHMgc29tZSBjYXJlZnVsIGFuYWx5c2lzIG9uIGhvdyB0aG9zZSBmdW5jdGlvbnMKPiA+ID4g PiBhcmUgY2FsbGVkIGFuZCB3aGF0IHRvIGRvIGFib3V0IGF0b21pYyBjYWxsZXJzLCBidXQgaXQg c2hvdWxkIGJlCj4gPiA+ID4gZG9hYmxlLiBJIGRvbid0IHNlZSBhbnkgZnVuZGFtZW50YWwgaXNz dWVzIGhlcmUuCj4gPiA+ID4gCj4gPiA+ID4gSSBkb24ndCBzZWUgd2h5IHlvdSB3b3VsZCBldmVy IG5lZWQgdG8gd2FrZSB0aGUgaGFyZHdhcmUgaW4gYW4KPiA+ID4gPiBpbnRlcnJ1cHQgaGFuZGxl ci4gU3VyZWx5IHRoZSBoYXJkd2FyZSBpcyBhbHJlYWR5IGF3YWtlLCBhcyBpdAo+ID4gPiA+IHdv dWxkbid0IHNpZ25hbCBhbiBpbnRlcnJ1cHQgb3RoZXJ3aXNlLiBBbmQgZm9yIHRoZSBpc3N1ZSB3 aXRoCj4gPiA+ID4gc2N1LXBkIHlvdSBvbmx5IGNhcmUgYWJvdXQgdGhlIHN0YXRlIHRyYW5zaXRp b24gb2YKPiA+ID4gPiBzdXNwZW5kZWQtPnJ1bm5pbmcuIElmIHRoZSBoYXJkd2FyZSBpcyBhbHJl YWR5IHJ1bm5pbmcvYXdha2UsIHRoZQo+ID4gPiA+IHJ1bnRpbWUgcG0gc3RhdGUgaGFuZGxpbmcg aXMgbm90aGluZyBtb3JlIHRoYW4gYnVtcGluZyBhIHJlZmNvdW50LAo+ID4gPiA+IHdoaWNoIGlz IGF0b21pYyBzYWZlLiBQdXR0aW5nIHRoZSBIVyBpbiBzdXNwZW5kIGlzIGFscmVhZHkgaGFuZGxl ZAo+ID4gYXN5bmNocm9ub3VzbHkgaW4gYSB3b3JrZXIsIHNvIHRoaXMgaXMgYWxzbyBhdG9taWMg c2FmZS4KPiA+ID4gQnV0IHdpdGggYXV0b3N1c3BlbmQgdXNlZCwgaW4gY29ybmVyIGNhc2UsIG1h eSBydW50aW1lIHN1c3BlbmRlZAo+ID4gPiBiZWZvcmUgZmFsbGluZyBJbnRvIGVkbWEgaW50ZXJy dXB0IGhhbmRsZXIgaWYgdGltZW91dCBoYXBwZW4gd2l0aCB0aGUKPiA+ID4gZGVsYXkgdmFsdWUg b2YgcG1fcnVudGltZV9zZXRfYXV0b3N1c3BlbmRfZGVsYXkoKS4gVGh1cywgY2FuJ3QgdG91Y2gK PiA+ID4gYW55IGVkbWEgaW50ZXJydXB0IHN0YXR1cyByZWdpc3RlciB1bmxlc3MgcnVudGltZSBy ZXN1bWUgZWRtYSBpbgo+ID4gPiBpbnRlcnJ1cHQgaGFuZGxlciB3aGlsZSBydW50aW1lIHJlc3Vt ZSBmdW5jdGlvbiBiYXNlZCBvbiBzY3UtcGQncyBwb3dlcgo+ID4gZG9tYWluIG1heSBibG9jayBv ciBzbGVlcC4KPiA+ID4gSSBoYXZlIGEgc2ltcGxlIHdvcmthcm91bmQgdGhhdCBkaXNhYmxlIHJ1 bnRpbWUgc3VzcGVuZCBpbgo+ID4gPiBpc3N1ZV9wZW5kaW5nIHdvcmtlciBieSBjYWxsaW5nIHBt X3J1bnRpbWVfZm9yYmlkKCkgYW5kIHRoZW4gZW5hYmxlCj4gPiA+IHJ1bnRpbWUgYXV0byBzdXNw ZW5kIGluIGRtYWVuZ2luZV90ZXJtaW5hdGVfYWxsIHNvIHRoYXQgd2UgY291bGQKPiA+ID4gZWFz aWx5IHJlZ2FyZCB0aGF0IGVkbWEgY2hhbm5lbCBpcyBhbHdheXMgaW4gcnVudGltZSByZXN1bWUg YmV0d2Vlbgo+ID4gPiBpc3N1ZV9wZW5kaW5nIGFuZCBjaGFubmVsIHRlcm1pbmF0ZWQgYW5kIGln bm9yZSB0aGUgYWJvdmUgaW50ZXJydXB0Cj4gPiBoYW5kbGVyL3NjdS1wZCBsaW1pdGF0aW9uLgo+ ID4gCj4gPiBUaGUgSVJRIGhhbmRsZXIgaXMgdGhlIHBvaW50IHdoZXJlIHlvdSBhcmUgaW5mb3Jt ZWQgYnkgdGhlIGhhcmR3YXJlIHRoYXQgYQo+ID4gc3BlY2lmaWMgb3BlcmF0aW9uIGlzIGNvbXBs ZXRlLiBJIGRvbid0IHNlZSBhbnkgdXNlLWNhc2Ugd2hlcmUgaXQgd291bGQgYmUgdmFsaWQKPiA+ IHRvIGRyb3AgdGhlIHJwbSByZWZjb3VudCB0byAwIGJlZm9yZSB0aGUgSVJRIGlzIGhhbmRsZWQu IFN1cmVseSB0aGUgaGFyZHdhcmUKPiA+IG5lZWRzIHRvIHN0YXkgYXdha2UgdW50aWwgdGhlIGN1 cnJlbnRseSBxdWV1ZWQgb3BlcmF0aW9ucyBhcmUgY29tcGxldGUgYW5kIGlmCj4gPiB0aGUgSVJR IGhhbmRsZXIgaXMgdGhlIGNvbXBsZXRpb24gcG9pbnQgdGhlIElSUSBoYW5kbGVyIGlzIHRoZSBm aXJzdCBwb2ludCBpbgo+ID4gdGltZSB3aGVyZSB5b3VyIGF1dG9zdXNwZW5kIHRpbWVyIHNob3Vs ZCBzdGFydCB0byBydW4uIFRoZXJlIHNob3VsZCBuZXZlciBiZQo+ID4gYSBzaXR1YXRpb24gd2hl cmUgdGhlIHRpbWVyIGV4cGlyeSBjYW4gZ2V0IGJldHdlZW4gSVJRIHNpZ25hbGluZyBhbmQgdGhl Cj4gPiBoYW5kbGVyIGNvZGUgcnVubmluZy4KPiBCdXQgdGhlIHRpbWVyIG9mIHJ1bnRpbWVfYXV0 b19zdXNwZW5kIGRlY2lkZSB3aGVuIGVudGVyIHJ1bnRpbWUgc3VzcGVuZCByYXRoZXIKPiB0aGFu IGhhcmR3YXJlLCB3aGlsZSB0cmFuc2ZlciBkYXRhIHNpemUgYW5kIHRyYW5zZmVyIHJhdGUgb24g SVAgYnVzIGRlY2lkZSB3aGVuIHRoZQo+IGRtYSBpbnRlcnJ1cHQgaGFwcGVuLsKgCj4gCkJ1dCBp dCBpc24ndCB0aGUgaGFyZHdhcmUgdGhhdCBkZWNpZGVzIHRvIGRyb3AgdGhlIHJwbSByZWZjb3Vu dCB0byAwCmFuZCBzdGFydGluZyB0aGUgYXV0b3N1c3BlbmQgdGltZXIsIGl0J3MgdGhlIGRyaXZl ci4KCj4gIEdlbmVyYWxseSwgd2UgY2FuIGNhbGwgcG1fcnVudGltZV9nZXRfc3luYyhmc2xfY2hh bi0+ZGV2KS8KPiBwbV9ydW50aW1lX21hcmtfbGFzdF9idXN5IGluIGludGVycnVwdCBoYW5kbGVy IHRvIGhvcGUgdGhlIHJ1bnRpbWVfYXV0b19zdXNwZW5kCj4gdGltZXIgZXhwaXJ5IGxhdGVyIHRo YW4gaW50ZXJydXB0IGNvbWluZywgYnV0IGlmIHRoZSB0cmFuc2ZlciBkYXRhIHNpemUgaXMgbGFy Z2VyIGluIGN5Y2xpYwo+IGFuZCB0cmFuc2ZlciByYXRlIGlzIHZlcnkgc2xvdyBsaWtlIDExNTIw MCBvciBsb3dlciBvbiB1YXJ0LCB0aGUgZml4IGF1dG9zdXNwZW5kIHRpbWVyCj4gMTAwbXMvMjAw bXMgbWF5YmUgbm90IGVub3VnaCwgaGVuY2UsIHJ1bnRpbWUgc3VzcGVuZCBtYXkgZXhlY3V0ZSBt ZWFud2hpbGUKPiB0aGUgZG1hIGludGVycnVwdCBtYXliZSB0cmlnZ2VyZWQgYW5kIGNhdWdodCBi eSBHSUMoYnV0IGludGVycnVwdCBoYW5kbGVyIHByZXZlbnQKPiBieSBzcGluX2xvY2tfaXJxc2F2 ZSBpbiBwbV9zdXNwZW5kX3RpbWVyX2ZuKCkgKSwgYW5kIHRoZW4gaW50ZXJydXB0IGhhbmRsZXIg c3RhcnQKPiB0byBydW4gYWZ0ZXIgcnVudGltZSBzdXNwZW5kLiAKCklmIHlvdXIgZHJpdmVyIGNv ZGUgZHJvcHMgdGhlIHJwbSByZWZjb3VudCB0byAwIGFuZCBzdGFydHMgdGhlCmF1dG9zdXNwZW5k IHRpbWVyIHdoaWxlIGEgY3ljbGljIHRyYW5zZmVyIGlzIHN0aWxsIGluIGZsaWdodCB0aGlzIGlz CmNsZWFybHkgYSBidWcuIEF1dG9zdXNwZW5kIGlzIG5vdCB0aGVyZSB0byBwYXBlciBvdmVyIGRy aXZlciBidWdzLCBidXQKdG8gYW1vcnRpemUgY29zdCBvZiBhY3R1YWxseSBzdXNwZW5kaW5nIGFu ZCByZXN1bWluZyB0aGUgaGFyZHdhcmUuIFlvdXIKZHJpdmVyIGNvZGUgbXVzdCBzdGlsbCB3b3Jr IGV2ZW4gaWYgdGhlIHRpbWVvdXQgaXMgMCwgaS5lLiB0aGUgaGFyZHdhcmUKaXMgaW1tZWRpYXRl bHkgc3VzcGVuZGVkIGFmdGVyIHlvdSBkcm9wIHRoZSBycG0gcmVmY291bnQgdG8gMC4KCklmIHlv dSBzdGlsbCBoYXZlIHRyYW5zZmVycyBxdWV1ZWQvaW4tZmxpZ2h0IHRoZSBkcml2ZXIgY29kZSBt dXN0IGtlZXAKYSBycG0gcmVmZXJlbmNlLgoKUmVnYXJkcywKTHVjYXMKCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxp bmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3Rz LmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F81FC433ED for ; Wed, 21 Apr 2021 17:43:41 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CFA0E6113B for ; Wed, 21 Apr 2021 17:43:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CFA0E6113B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1B6886E157; Wed, 21 Apr 2021 17:43:40 +0000 (UTC) Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by gabe.freedesktop.org (Postfix) with ESMTPS id BBA836E157 for ; Wed, 21 Apr 2021 17:43:38 +0000 (UTC) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lZGsj-0003PI-NV; Wed, 21 Apr 2021 19:43:21 +0200 Message-ID: <18fbdc4bf0574a722134400ad9e4510d3cbcb767.camel@pengutronix.de> Subject: Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe From: Lucas Stach To: Robin Gong , Shengjiu Wang Date: Wed, 21 Apr 2021 19:43:18 +0200 In-Reply-To: References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com> <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de> <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de> <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de> <97262466d537402ad4032098ef277d6d47734f1f.camel@pengutronix.de> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: dri-devel@lists.freedesktop.org X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linaro-mm-sig@lists.linaro.org" , Linux-ALSA , "linuxppc-dev@lists.ozlabs.org" , Timur Tabi , Xiubo Li , "s.hauer@pengutronix.de" , Takashi Iwai , Liam Girdwood , "dri-devel@lists.freedesktop.org" , linux-kernel , Nicolin Chen , Mark Brown , dl-linux-imx , "kernel@pengutronix.de" , "perex@perex.cz" , "shawnguo@kernel.org" , "S.j. Wang" , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" QW0gTWl0dHdvY2gsIGRlbSAyMS4wNC4yMDIxIHVtIDE0OjU0ICswMDAwIHNjaHJpZWIgUm9iaW4g R29uZzoKPiBPbiAyMDIwMS8wNC8yMCAyMjowMSBMdWNhcyBTdGFjaCA8bC5zdGFjaEBwZW5ndXRy b25peC5kZT4gd3JvdGU6Cj4gPiBBbSBEaWVuc3RhZywgZGVtIDIwLjA0LjIwMjEgdW0gMTM6NDcg KzAwMDAgc2NocmllYiBSb2JpbiBHb25nOgo+ID4gPiBPbiAyMDIxLzA0LzE5IDE3OjQ2IEx1Y2Fz IFN0YWNoIDxsLnN0YWNoQHBlbmd1dHJvbml4LmRlPiB3cm90ZToKPiA+ID4gPiBBbSBNb250YWcs IGRlbSAxOS4wNC4yMDIxIHVtIDA3OjE3ICswMDAwIHNjaHJpZWIgUm9iaW4gR29uZzoKPiA+ID4g PiA+IEhpIEx1Y2FzLAo+ID4gPiA+ID4gCj4gPiA+ID4gPiBPbiAyMDIxLzA0LzE0IEx1Y2FzIFN0 YWNoIDxsLnN0YWNoQHBlbmd1dHJvbml4LmRlPiB3cm90ZToKPiA+ID4gPiA+ID4gSGkgUm9iaW4s Cj4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiBBbSBNaXR0d29jaCwgZGVtIDE0LjA0LjIwMjEgdW0g MTQ6MzMgKzAwMDAgc2NocmllYiBSb2JpbiBHb25nOgo+ID4gPiA+ID4gPiA+IE9uIDIwMjAvMDUv MjAgMTc6NDMgTHVjYXMgU3RhY2ggPGwuc3RhY2hAcGVuZ3V0cm9uaXguZGU+IHdyb3RlOgo+ID4g PiA+ID4gPiA+ID4gQW0gTWl0dHdvY2gsIGRlbiAyMC4wNS4yMDIwLCAxNjoyMCArMDgwMCBzY2hy aWViIFNoZW5naml1Cj4gPiBXYW5nOgo+ID4gPiA+ID4gPiA+ID4gPiBIaQo+ID4gPiA+ID4gPiA+ ID4gPiAKPiA+ID4gPiA+ID4gPiA+ID4gT24gVHVlLCBNYXkgMTksIDIwMjAgYXQgNjowNCBQTSBM dWNhcyBTdGFjaAo+ID4gPiA+ID4gPiA+ID4gPiA8bC5zdGFjaEBwZW5ndXRyb25peC5kZT4KPiA+ ID4gPiA+ID4gPiA+IHdyb3RlOgo+ID4gPiA+ID4gPiA+ID4gPiA+IEFtIERpZW5zdGFnLCBkZW4g MTkuMDUuMjAyMCwgMTc6NDEgKzA4MDAgc2NocmllYiBTaGVuZ2ppdQo+ID4gV2FuZzoKPiA+ID4g PiA+ID4gPiA+ID4gPiA+IFRoZXJlIGFyZSB0d28gcmVxdWlyZW1lbnRzIHRoYXQgd2UgbmVlZCB0 byBtb3ZlIHRoZQo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gcmVxdWVzdCBvZiBkbWEgY2hhbm5lbCBm cm9tIHByb2JlIHRvIG9wZW4uCj4gPiA+ID4gPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gPiA+ ID4gSG93IGRvIHlvdSBoYW5kbGUgLUVQUk9CRV9ERUZFUiByZXR1cm4gY29kZSBmcm9tIHRoZQo+ ID4gPiA+ID4gPiA+ID4gPiA+IGNoYW5uZWwgcmVxdWVzdCBpZiB5b3UgZG9uJ3QgZG8gaXQgaW4g cHJvYmU/Cj4gPiA+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+ID4gPiBJIHVzZSB0aGUgZG1h X3JlcXVlc3Rfc2xhdmVfY2hhbm5lbCBvciBkbWFfcmVxdWVzdF9jaGFubmVsCj4gPiA+ID4gPiA+ ID4gPiA+IGluc3RlYWQgb2YgZG1hZW5naW5lX3BjbV9yZXF1ZXN0X2NoYW5fb2YuIHNvIHRoZXJl IHNob3VsZAo+ID4gPiA+ID4gPiA+ID4gPiBiZSBub3QgLUVQUk9CRV9ERUZFUiByZXR1cm4gY29k ZS4KPiA+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+ID4gVGhpcyBpcyBhIHByZXR0eSB3ZWFr IGFyZ3VtZW50LiBUaGUgZG1hZW5naW5lIGRldmljZSBtaWdodAo+ID4gPiA+ID4gPiA+ID4gcHJv YmUgYWZ0ZXIgeW91IHRyeSB0byBnZXQgdGhlIGNoYW5uZWwuIFVzaW5nIGEgZnVuY3Rpb24gdG8K PiA+ID4gPiA+ID4gPiA+IHJlcXVlc3QgdGhlIGNoYW5uZWwgdGhhdCBkb2Vzbid0IGFsbG93IHlv dSB0byBoYW5kbGUgcHJvYmUKPiA+ID4gPiA+ID4gPiA+IGRlZmVycmFsIGlzIElNSE8gYSBidWcg YW5kIHNob3VsZCBiZSBmaXhlZCwgaW5zdGVhZCBvZgo+ID4gPiA+ID4gPiA+ID4gYnVpbGRpbmcg ZXZlbiBtb3JlIGFzc3VtcHRpb25zIG9uIHRvcAo+ID4gPiA+ID4gPiBvZiBpdC4KPiA+ID4gPiA+ ID4gPiA+IAo+ID4gPiA+ID4gPiA+ID4gPiA+ID4gLSBXaGVuIGRtYSBkZXZpY2UgYmluZHMgd2l0 aCBwb3dlci1kb21haW5zLCB0aGUgcG93ZXIKPiA+ID4gPiA+ID4gPiA+ID4gPiA+IHdpbGwgYmUg ZW5hYmxlZCB3aGVuIHdlIHJlcXVlc3QgZG1hIGNoYW5uZWwuIElmIHRoZQo+ID4gPiA+ID4gPiA+ ID4gPiA+ID4gcmVxdWVzdCBvZiBkbWEgY2hhbm5lbCBoYXBwZW4gb24gcHJvYmUsIHRoZW4gdGhl Cj4gPiA+ID4gPiA+ID4gPiA+ID4gPiBwb3dlci1kb21haW5zIHdpbGwgYmUgYWx3YXlzIGVuYWJs ZWQgYWZ0ZXIga2VybmVsIGJvb3QKPiA+ID4gPiA+ID4gPiA+ID4gPiA+IHVwLCAgd2hpY2ggaXMg bm90IGdvb2QgZm9yIHBvd2VyIHNhdmluZywgIHNvIHdlIG5lZWQKPiA+ID4gPiA+ID4gPiA+ID4g PiA+IHRvIG1vdmUgdGhlIHJlcXVlc3Qgb2YgZG1hIGNoYW5uZWwgdG8gLm9wZW4oKTsKPiA+ID4g PiA+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gPiA+ID4gPiBUaGlzIGlzIGNlcnRhaW5seSBzb21l dGhpbmcgd2hpY2ggY291bGQgYmUgZml4ZWQgaW4gdGhlCj4gPiA+ID4gPiA+ID4gPiA+ID4gZG1h ZW5naW5lIGRyaXZlci4KPiA+ID4gPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gPiA+IERtYSBk cml2ZXIgYWx3YXlzIGNhbGwgdGhlIHBtX3J1bnRpbWVfZ2V0X3N5bmMgaW4KPiA+ID4gPiA+ID4g PiA+ID4gZGV2aWNlX2FsbG9jX2NoYW5fcmVzb3VyY2VzLCB0aGUKPiA+ID4gPiA+ID4gPiA+ID4g ZGV2aWNlX2FsbG9jX2NoYW5fcmVzb3VyY2VzIGlzIGNhbGxlZCB3aGVuIGNoYW5uZWwgaXMKPiA+ ID4gPiA+ID4gPiA+ID4gcmVxdWVzdGVkLiBzbyBwb3dlciBpcyBlbmFibGVkIG9uIGNoYW5uZWwK PiA+ID4gPiA+ID4gcmVxdWVzdC4KPiA+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+ID4gU28g d2h5IGNhbid0IHlvdSBmaXggdGhlIGRtYWVuZ2luZSBkcml2ZXIgdG8gZG8gdGhhdCBSUE0KPiA+ ID4gPiA+ID4gPiA+IGNhbGwgYXQgYSBsYXRlciB0aW1lIHdoZW4gdGhlIGNoYW5uZWwgaXMgYWN0 dWFsbHkgZ29pbmcgdG8KPiA+ID4gPiA+ID4gPiA+IGJlIHVzZWQ/IFRoaXMgd2lsbCBhbGxvdyBm dXJ0aGVyIHBvd2VyIHNhdmluZ3Mgd2l0aCBvdGhlcgo+ID4gPiA+ID4gPiA+ID4gc2xhdmUgZGV2 aWNlcyB0aGFuIHRoZSBhdWRpbwo+ID4gPiA+IFBDTS4KPiA+ID4gPiA+ID4gPiBIaSBMdWNhcywK PiA+ID4gPiA+ID4gPiDCoMKgVGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb24uIEkgaGF2ZSB0cmll ZCB0byBpbXBsZW1lbnQKPiA+ID4gPiA+ID4gPiBydW50aW1lIGF1dG9zdXNwZW5kIGluIGZzbC1l ZG1hIGRyaXZlciBvbiBpLm14OHFtL3F4cCB3aXRoCj4gPiA+ID4gPiA+ID4gZGVsYXkgdGltZSAo Mgo+ID4gPiA+ID4gPiA+IHNlYykgZm9yIHRoaXMgZmVhdHVyZSBhcyBiZWxvdyAob3IgeW91IGNh biByZWZlciB0bwo+ID4gPiA+ID4gPiA+IGRyaXZlcnMvZG1hL3Fjb20vaGlkbWEuYyksIGFuZCBw bV9ydW50aW1lX2dldF9zeW5jLwo+ID4gPiA+ID4gPiA+IHBtX3J1bnRpbWVfcHV0X2F1dG9zdXNw ZW5kIGluIGFsbCBkbWFlbmdpbmUgZHJpdmVyIGludGVyZmFjZQo+ID4gPiA+ID4gPiA+IGxpa2UK PiA+ID4gPiA+ID4gPiBkZXZpY2VfYWxsb2NfY2hhbl9yZXNvdXJjZXMvZGV2aWNlX3ByZXBfc2xh dmVfc2cvZGV2aWNlX3ByZXBfZAo+ID4gPiA+ID4gPiA+IG1hX2MKPiA+ID4gPiA+ID4gPiB5Y2xp Cj4gPiA+ID4gPiA+ID4gYy8KPiA+ID4gPiA+ID4gPiBkZXZpY2VfdHhfc3RhdHVzLi4uCj4gPiA+ ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqBwbV9ydW50aW1lX3VzZV9hdXRvc3VzcGVuZChmc2xfY2hhbi0+ZGUKPiA+ IHYpOwo+ID4gPiA+ID4gPiA+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgcG1fcnVu dGltZV9zZXRfYXV0b3N1c3BlbmRfZGVsYXkoZnNsX2NoYQo+ID4gbi0+Cj4gPiA+ID4gZGV2LAo+ ID4gPiA+ID4gPiAyMDAwKTsKPiA+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gPiBUaGF0IGNvdWxk IHJlc29sdmUgdGhpcyBhdWRpbyBjYXNlIHNpbmNlIHRoZSBhdXRvc3VzcGVuZCBjb3VsZAo+ID4g PiA+ID4gPiA+IHN1c3BlbmQgcnVudGltZSBhZnRlcgo+ID4gPiA+ID4gPiA+IDIgc2Vjb25kcyBp ZiB0aGVyZSBpcyBubyBmdXJ0aGVyIGRtYSB0cmFuc2ZlciBidXQgb25seSBjaGFubmVsCj4gPiA+ ID4gPiA+IHJlcXVlc3QoZGV2aWNlX2FsbG9jX2NoYW5fcmVzb3VyY2VzKS4KPiA+ID4gPiA+ID4g PiBCdXQgdW5mb3J0dW5hdGVseSwgaXQgY2F1c2UgYW5vdGhlciBpc3N1ZS4gQXMgeW91IGtub3cs IG9uIG91cgo+ID4gPiA+ID4gPiA+IGkubXg4cW0vcXhwLCBwb3dlciBkb21haW4gZG9uZSBieSBz Y2Z3Cj4gPiA+ID4gPiA+ID4gKGRyaXZlcnMvZmlybXdhcmUvaW14L3NjdS1wZC5jKQo+ID4gPiA+ ID4gPiBvdmVyIG1haWxib3g6Cj4gPiA+ID4gPiA+ID4gwqBpbXhfc2NfcGRfcG93ZXIoKS0+aW14 X3NjdV9jYWxsX3JwYygpLT4KPiA+ID4gPiA+ID4gPiBpbXhfc2N1X2lwY193cml0ZSgpLT5tYm94 X3NlbmRfbWVzc2FnZSgpCj4gPiA+ID4gPiA+ID4gd2hpY2ggbWVhbnMgaGF2ZSB0byAnd2FpdHMg Zm9yIGNvbXBsZXRpb24nLCBtZWFud2hpbGUsIHNvbWUKPiA+ID4gPiA+ID4gPiBkcml2ZXIgbGlr ZSB0dHkgd2lsbCBjYWxsIGRtYWVuZ2luZSBpbnRlcmZhY2VzIGluIG5vbi1hdG9taWMKPiA+ID4g PiA+ID4gPiBjYXNlIGFzIGJlbG93LAo+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+IHN0YXRp YyBpbnQgdWFydF93cml0ZShzdHJ1Y3QgdHR5X3N0cnVjdCAqdHR5LCBjb25zdCB1bnNpZ25lZAo+ ID4gPiA+ID4gPiA+IGNoYXIgKmJ1ZiwgaW50IGNvdW50KSB7Cj4gPiA+ID4gPiA+ID4gwqDCoMKg Li4uLi4uLgo+ID4gPiA+ID4gPiA+IAkgICAgcG9ydCA9IHVhcnRfcG9ydF9sb2NrKHN0YXRlLCBm bGFncyk7Cj4gPiA+ID4gPiA+ID4gwqDCoMKgLi4uLi4uCj4gPiA+ID4gPiA+ID4gwqDCoMKgwqDC oMKgwqDCoF9fdWFydF9zdGFydCh0dHkpOyAgLy9jYWxsCj4gPiA+ID4gc3RhcnRfdHgoKS0+ZG1h ZW5naW5lX3ByZXBfc2xhdmVfc2cuLi4KPiA+ID4gPiA+ID4gPiDCoMKgwqDCoMKgwqDCoMKgdWFy dF9wb3J0X3VubG9jayhwb3J0LCBmbGFncyk7Cj4gPiA+ID4gPiA+ID4gwqDCoMKgwqDCoMKgwqDC oHJldHVybiByZXQ7Cj4gPiA+ID4gPiA+ID4gfQo+ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+ IFRodXMgZG1hIHJ1bnRpbWUgcmVzdW1lIG1heSBoYXBwZW4gaW4gdGhhdCB0aW1pbmcgd2luZG93 IGFuZAo+ID4gPiA+ID4gPiA+IGNhdXNlCj4gPiA+ID4gPiA+IGtlcm5lbCBhbGFybS4KPiA+ID4g PiA+ID4gPiBJJ20gbm90IHN1cmUgd2hldGhlciB0aGVyZSBhcmUgc2ltaWxhciBsaW1pdGF0aW9u cyBvbiBvdGhlcgo+ID4gPiA+ID4gPiA+IGRyaXZlciBzdWJzeXN0ZW0uIEJ1dCBmb3IgbWUsIEl0 IGxvb2tzIGxpa2UgdGhlIG9ubHkgd2F5IHRvCj4gPiA+ID4gPiA+ID4gcmVzb2x2ZSB0aGUgY29u dHJhZGljdGlvbiBiZXR3ZWVuIHR0eSBhbmQgc2N1LXBkIChoYXJkd2FyZQo+ID4gPiA+ID4gPiA+ IGxpbWl0YXRpb24gb24KPiA+ID4gPiA+ID4gPiBpLm14OHFtL3F4cCkgaXMgdG8gZ2l2ZSB1cCBh dXRvc3VzcGVuZCBhbmQga2VlcAo+ID4gPiA+ID4gPiA+IHBtX3J1bnRpbWVfZ2V0X3N5bmMKPiA+ ID4gPiA+ID4gb25seSBpbiBkZXZpY2VfYWxsb2NfY2hhbl9yZXNvdXJjZXMgYmVjYXVzZSByZXF1 ZXN0IGNoYW5uZWwgaXMgYQo+ID4gPiA+ID4gPiBzYWZlIG5vbi1hdG9taWMgcGhhc2UuCj4gPiA+ ID4gPiA+ID4gRG8geW91IGhhdmUgYW55IGlkZWE/IFRoYW5rcyBpbiBhZHZhbmNlLgo+ID4gPiA+ ID4gPiAKPiA+ID4gPiA+ID4gSWYgeW91IGxvb2sgY2xvc2VseSBhdCB0aGUgZHJpdmVyIHlvdSB1 c2VkIGFzIGFuIGV4YW1wbGUKPiA+ID4gPiA+ID4gKGhpZG1hLmMpIGl0IGxvb2tzIGxpa2UgdGhl cmUgaXMgYWxyZWFkeSBzb21ldGhpbmcgaW4gdGhlcmUsCj4gPiA+ID4gPiA+IHdoaWNoIGxvb2tz IHZlcnkgbXVjaCBsaWtlIHdoYXQgeW91IG5lZWQKPiA+ID4gPiA+ID4gaGVyZToKPiA+ID4gPiA+ ID4gCj4gPiA+ID4gPiA+IEluIGhpZG1hX2lzc3VlX3BlbmRpbmcoKSB0aGUgZHJpdmVyIHRyaWVz IHRvIGdldCB0aGUgZGV2aWNlIHRvCj4gPiA+ID4gPiA+IHJ1bnRpbWUKPiA+ID4gPiByZXN1bWUu Cj4gPiA+ID4gPiA+IElmIHRoaXMgZG9lc24ndCB3b3JrLCBtYXliZSBkdWUgdG8gdGhlIHBvd2Vy IGRvbWFpbiBjb2RlIG5vdAo+ID4gPiA+ID4gPiBiZWluZyBhYmxlIHRvIGJlIGNhbGxlZCBpbiBh dG9taWMgY29udGV4dCwgdGhlIGFjdHVhbCB3b3JrIG9mCj4gPiA+ID4gPiA+IHdha2luZyB1cCB0 aGUgZG1hIGhhcmR3YXJlIGFuZCBpc3N1aW5nIHRoZSBkZXNjcmlwdG9yIGlzIHNodW50ZWQgdG8g YQo+ID4gdGFza2xldC4KPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+IElmIEknbSByZWFkaW5nIHRo aXMgcmlnaHQsIHRoaXMgaXMgZXhhY3RseSB3aGF0IHlvdSBuZWVkIGhlcmUgdG8KPiA+ID4gPiA+ ID4gYmUgYWJsZSB0byBjYWxsIHRoZSBkbWFlbmdpbmUgY29kZSBmcm9tIGF0b21pYyBjb250ZXh0 OiB0cnkgdGhlCj4gPiA+ID4gPiA+IHJwbSBnZXQgYW5kIGlzc3VlIGltbWVkaWF0ZWx5IHdoZW4g cG9zc2libGUsIG90aGVyd2lzZSBzaHVudCB0aGUKPiA+ID4gPiA+ID4gd29yayB0byBhCj4gPiA+ ID4gPiA+IG5vbi0gYXRvbWljIGNvbnRleHQgd2hlcmUgeW91IGNhbiBkZWFsIHdpdGggdGhlIHJl cXVpcmVtZW50cyBvZgo+ID4gc2N1LXBkLgo+ID4gPiA+ID4gWWVzLCBJIGNhbiBzY2hlZHVsZV93 b3JrIHRvIHdvcmtlciB0byBydW50aW1lIHJlc3VtZSBlZG1hIGNoYW5uZWwKPiA+ID4gPiA+IGJ5 Cj4gPiA+ID4gY2FsbGluZyBzY3UtcGQuCj4gPiA+ID4gPiBCdXQgdGhhdCBtZWFucyBhbGwgZG1h ZW5naW5lIGludGVyZmFjZXMgc2hvdWxkIGJlIHRha2VuIGNhcmUsIG5vdAo+ID4gPiA+ID4gb25s eQo+ID4gPiA+ID4gaXNzdWVfcGVuZGluZygpIGJ1dCBhbHNvCj4gPiA+ID4gPiBkbWFlbmdpbmVf dGVybWluYXRlX2FsbCgpL2RtYWVuZ2luZV9wYXVzZSgpL2RtYWVuZ2luZV9yZXN1bWUoKS8KPiA+ ID4gPiA+IGRtYWVuZ2luZV90eF9zdGF0dXMoKS4gTm90IHN1cmUgd2h5IGhpZG1hIG9ubHkgdGFr ZSBjYXJlCj4gPiA+ID4gPiBpc3N1ZV9wZW5kaW5nLiBNYXliZSB0aGVpciB1c2VyIGNhc2UgaXMg anVzdCBmb3IgbWVtY3B5L21lbXNldCBzbwo+ID4gPiA+ID4gdGhhdCBubyBmdXJ0aGVyIGNvbXBs aWNhdGUgY2FzZSBhcyBBTFNBIG9yIFRUWS4KPiA+ID4gPiA+IEJlc2lkZXMsIGZvciBhdXRvc3Vz cGVuZCBpbiBjeWNsaWMsIHdlIGhhdmUgdG8gYWRkCj4gPiA+ID4gPiBwbV9ydW50aW1lX2dldF9z eW5jIGludG8gaW50ZXJydXB0IGhhbmRsZXIgYXMgcWNvbS9iYW1fZG1hLmMuIGJ1dAo+ID4gPiA+ ID4gaG93IGNvdWxkIHJlc29sdmUgdGhlIHNjdS1wZCdzIG5vbi1hdG1vaWMgbGltaXRhdGlvbiBp biBpbnRlcnJ1cHQKPiA+IGhhbmRsZXI/Cj4gPiA+ID4gCj4gPiA+ID4gU3VyZSwgdGhpcyBhbGwg bmVlZHMgc29tZSBjYXJlZnVsIGFuYWx5c2lzIG9uIGhvdyB0aG9zZSBmdW5jdGlvbnMKPiA+ID4g PiBhcmUgY2FsbGVkIGFuZCB3aGF0IHRvIGRvIGFib3V0IGF0b21pYyBjYWxsZXJzLCBidXQgaXQg c2hvdWxkIGJlCj4gPiA+ID4gZG9hYmxlLiBJIGRvbid0IHNlZSBhbnkgZnVuZGFtZW50YWwgaXNz dWVzIGhlcmUuCj4gPiA+ID4gCj4gPiA+ID4gSSBkb24ndCBzZWUgd2h5IHlvdSB3b3VsZCBldmVy IG5lZWQgdG8gd2FrZSB0aGUgaGFyZHdhcmUgaW4gYW4KPiA+ID4gPiBpbnRlcnJ1cHQgaGFuZGxl ci4gU3VyZWx5IHRoZSBoYXJkd2FyZSBpcyBhbHJlYWR5IGF3YWtlLCBhcyBpdAo+ID4gPiA+IHdv dWxkbid0IHNpZ25hbCBhbiBpbnRlcnJ1cHQgb3RoZXJ3aXNlLiBBbmQgZm9yIHRoZSBpc3N1ZSB3 aXRoCj4gPiA+ID4gc2N1LXBkIHlvdSBvbmx5IGNhcmUgYWJvdXQgdGhlIHN0YXRlIHRyYW5zaXRp b24gb2YKPiA+ID4gPiBzdXNwZW5kZWQtPnJ1bm5pbmcuIElmIHRoZSBoYXJkd2FyZSBpcyBhbHJl YWR5IHJ1bm5pbmcvYXdha2UsIHRoZQo+ID4gPiA+IHJ1bnRpbWUgcG0gc3RhdGUgaGFuZGxpbmcg aXMgbm90aGluZyBtb3JlIHRoYW4gYnVtcGluZyBhIHJlZmNvdW50LAo+ID4gPiA+IHdoaWNoIGlz IGF0b21pYyBzYWZlLiBQdXR0aW5nIHRoZSBIVyBpbiBzdXNwZW5kIGlzIGFscmVhZHkgaGFuZGxl ZAo+ID4gYXN5bmNocm9ub3VzbHkgaW4gYSB3b3JrZXIsIHNvIHRoaXMgaXMgYWxzbyBhdG9taWMg c2FmZS4KPiA+ID4gQnV0IHdpdGggYXV0b3N1c3BlbmQgdXNlZCwgaW4gY29ybmVyIGNhc2UsIG1h eSBydW50aW1lIHN1c3BlbmRlZAo+ID4gPiBiZWZvcmUgZmFsbGluZyBJbnRvIGVkbWEgaW50ZXJy dXB0IGhhbmRsZXIgaWYgdGltZW91dCBoYXBwZW4gd2l0aCB0aGUKPiA+ID4gZGVsYXkgdmFsdWUg b2YgcG1fcnVudGltZV9zZXRfYXV0b3N1c3BlbmRfZGVsYXkoKS4gVGh1cywgY2FuJ3QgdG91Y2gK PiA+ID4gYW55IGVkbWEgaW50ZXJydXB0IHN0YXR1cyByZWdpc3RlciB1bmxlc3MgcnVudGltZSBy ZXN1bWUgZWRtYSBpbgo+ID4gPiBpbnRlcnJ1cHQgaGFuZGxlciB3aGlsZSBydW50aW1lIHJlc3Vt ZSBmdW5jdGlvbiBiYXNlZCBvbiBzY3UtcGQncyBwb3dlcgo+ID4gZG9tYWluIG1heSBibG9jayBv ciBzbGVlcC4KPiA+ID4gSSBoYXZlIGEgc2ltcGxlIHdvcmthcm91bmQgdGhhdCBkaXNhYmxlIHJ1 bnRpbWUgc3VzcGVuZCBpbgo+ID4gPiBpc3N1ZV9wZW5kaW5nIHdvcmtlciBieSBjYWxsaW5nIHBt X3J1bnRpbWVfZm9yYmlkKCkgYW5kIHRoZW4gZW5hYmxlCj4gPiA+IHJ1bnRpbWUgYXV0byBzdXNw ZW5kIGluIGRtYWVuZ2luZV90ZXJtaW5hdGVfYWxsIHNvIHRoYXQgd2UgY291bGQKPiA+ID4gZWFz aWx5IHJlZ2FyZCB0aGF0IGVkbWEgY2hhbm5lbCBpcyBhbHdheXMgaW4gcnVudGltZSByZXN1bWUg YmV0d2Vlbgo+ID4gPiBpc3N1ZV9wZW5kaW5nIGFuZCBjaGFubmVsIHRlcm1pbmF0ZWQgYW5kIGln bm9yZSB0aGUgYWJvdmUgaW50ZXJydXB0Cj4gPiBoYW5kbGVyL3NjdS1wZCBsaW1pdGF0aW9uLgo+ ID4gCj4gPiBUaGUgSVJRIGhhbmRsZXIgaXMgdGhlIHBvaW50IHdoZXJlIHlvdSBhcmUgaW5mb3Jt ZWQgYnkgdGhlIGhhcmR3YXJlIHRoYXQgYQo+ID4gc3BlY2lmaWMgb3BlcmF0aW9uIGlzIGNvbXBs ZXRlLiBJIGRvbid0IHNlZSBhbnkgdXNlLWNhc2Ugd2hlcmUgaXQgd291bGQgYmUgdmFsaWQKPiA+ IHRvIGRyb3AgdGhlIHJwbSByZWZjb3VudCB0byAwIGJlZm9yZSB0aGUgSVJRIGlzIGhhbmRsZWQu IFN1cmVseSB0aGUgaGFyZHdhcmUKPiA+IG5lZWRzIHRvIHN0YXkgYXdha2UgdW50aWwgdGhlIGN1 cnJlbnRseSBxdWV1ZWQgb3BlcmF0aW9ucyBhcmUgY29tcGxldGUgYW5kIGlmCj4gPiB0aGUgSVJR IGhhbmRsZXIgaXMgdGhlIGNvbXBsZXRpb24gcG9pbnQgdGhlIElSUSBoYW5kbGVyIGlzIHRoZSBm aXJzdCBwb2ludCBpbgo+ID4gdGltZSB3aGVyZSB5b3VyIGF1dG9zdXNwZW5kIHRpbWVyIHNob3Vs ZCBzdGFydCB0byBydW4uIFRoZXJlIHNob3VsZCBuZXZlciBiZQo+ID4gYSBzaXR1YXRpb24gd2hl cmUgdGhlIHRpbWVyIGV4cGlyeSBjYW4gZ2V0IGJldHdlZW4gSVJRIHNpZ25hbGluZyBhbmQgdGhl Cj4gPiBoYW5kbGVyIGNvZGUgcnVubmluZy4KPiBCdXQgdGhlIHRpbWVyIG9mIHJ1bnRpbWVfYXV0 b19zdXNwZW5kIGRlY2lkZSB3aGVuIGVudGVyIHJ1bnRpbWUgc3VzcGVuZCByYXRoZXIKPiB0aGFu IGhhcmR3YXJlLCB3aGlsZSB0cmFuc2ZlciBkYXRhIHNpemUgYW5kIHRyYW5zZmVyIHJhdGUgb24g SVAgYnVzIGRlY2lkZSB3aGVuIHRoZQo+IGRtYSBpbnRlcnJ1cHQgaGFwcGVuLsKgCj4gCkJ1dCBp dCBpc24ndCB0aGUgaGFyZHdhcmUgdGhhdCBkZWNpZGVzIHRvIGRyb3AgdGhlIHJwbSByZWZjb3Vu dCB0byAwCmFuZCBzdGFydGluZyB0aGUgYXV0b3N1c3BlbmQgdGltZXIsIGl0J3MgdGhlIGRyaXZl ci4KCj4gIEdlbmVyYWxseSwgd2UgY2FuIGNhbGwgcG1fcnVudGltZV9nZXRfc3luYyhmc2xfY2hh bi0+ZGV2KS8KPiBwbV9ydW50aW1lX21hcmtfbGFzdF9idXN5IGluIGludGVycnVwdCBoYW5kbGVy IHRvIGhvcGUgdGhlIHJ1bnRpbWVfYXV0b19zdXNwZW5kCj4gdGltZXIgZXhwaXJ5IGxhdGVyIHRo YW4gaW50ZXJydXB0IGNvbWluZywgYnV0IGlmIHRoZSB0cmFuc2ZlciBkYXRhIHNpemUgaXMgbGFy Z2VyIGluIGN5Y2xpYwo+IGFuZCB0cmFuc2ZlciByYXRlIGlzIHZlcnkgc2xvdyBsaWtlIDExNTIw MCBvciBsb3dlciBvbiB1YXJ0LCB0aGUgZml4IGF1dG9zdXNwZW5kIHRpbWVyCj4gMTAwbXMvMjAw bXMgbWF5YmUgbm90IGVub3VnaCwgaGVuY2UsIHJ1bnRpbWUgc3VzcGVuZCBtYXkgZXhlY3V0ZSBt ZWFud2hpbGUKPiB0aGUgZG1hIGludGVycnVwdCBtYXliZSB0cmlnZ2VyZWQgYW5kIGNhdWdodCBi eSBHSUMoYnV0IGludGVycnVwdCBoYW5kbGVyIHByZXZlbnQKPiBieSBzcGluX2xvY2tfaXJxc2F2 ZSBpbiBwbV9zdXNwZW5kX3RpbWVyX2ZuKCkgKSwgYW5kIHRoZW4gaW50ZXJydXB0IGhhbmRsZXIg c3RhcnQKPiB0byBydW4gYWZ0ZXIgcnVudGltZSBzdXNwZW5kLiAKCklmIHlvdXIgZHJpdmVyIGNv ZGUgZHJvcHMgdGhlIHJwbSByZWZjb3VudCB0byAwIGFuZCBzdGFydHMgdGhlCmF1dG9zdXNwZW5k IHRpbWVyIHdoaWxlIGEgY3ljbGljIHRyYW5zZmVyIGlzIHN0aWxsIGluIGZsaWdodCB0aGlzIGlz CmNsZWFybHkgYSBidWcuIEF1dG9zdXNwZW5kIGlzIG5vdCB0aGVyZSB0byBwYXBlciBvdmVyIGRy aXZlciBidWdzLCBidXQKdG8gYW1vcnRpemUgY29zdCBvZiBhY3R1YWxseSBzdXNwZW5kaW5nIGFu ZCByZXN1bWluZyB0aGUgaGFyZHdhcmUuIFlvdXIKZHJpdmVyIGNvZGUgbXVzdCBzdGlsbCB3b3Jr IGV2ZW4gaWYgdGhlIHRpbWVvdXQgaXMgMCwgaS5lLiB0aGUgaGFyZHdhcmUKaXMgaW1tZWRpYXRl bHkgc3VzcGVuZGVkIGFmdGVyIHlvdSBkcm9wIHRoZSBycG0gcmVmY291bnQgdG8gMC4KCklmIHlv dSBzdGlsbCBoYXZlIHRyYW5zZmVycyBxdWV1ZWQvaW4tZmxpZ2h0IHRoZSBkcml2ZXIgY29kZSBt dXN0IGtlZXAKYSBycG0gcmVmZXJlbmNlLgoKUmVnYXJkcywKTHVjYXMKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QK ZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9w Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo=