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,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 74908C433DF for ; Fri, 9 Oct 2020 12:57:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 16BEC20658 for ; Fri, 9 Oct 2020 12:57:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bTLrKdrf" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387917AbgJIM5U (ORCPT ); Fri, 9 Oct 2020 08:57:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387898AbgJIM5U (ORCPT ); Fri, 9 Oct 2020 08:57:20 -0400 Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C3BDC0613D2 for ; Fri, 9 Oct 2020 05:57:20 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id r4so2310885ioh.0 for ; Fri, 09 Oct 2020 05:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EECETrKbmoPSDvlqCGPtlVQRxwctT/KKRtpH7yPiQSk=; b=bTLrKdrfvuUK/6IApP7UUzshOURZdohqllb2TZ3nBt9kzD9gameKV377bq+QAuPI0b 6mfCpjifwKllmzcR8KNJS4p/uMXgeWXPrAnhbgq0K6qD5m8GU9BhpKuP6QsFidjGzmu/ nBpvq9cS147lMoHSh/6m53gBPiqVRDZxYjksv3vnJbdlcav/88WA6s3UVN90fDa1Ao40 Md4FfOu/SjaqvQ9DASYxyfqpqHAbeV/U7nbQLhxtICcGHUBwznT46ADLRpZsmLx44Op/ kg9hWziKzWl9ybsoOWtGEIQi8oKttWjHmSJQLboS0WcJfSG9YvfFQaHHM1mNFHpFwCIn ZAEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EECETrKbmoPSDvlqCGPtlVQRxwctT/KKRtpH7yPiQSk=; b=QCPWLME4UPKVojJ502cRyOKbcWTMqsOXBW8joOnm/KbcTwtPnD1T0pLU/NWdtfgGnn 3e9ghfV0ynutvz784mtUs4E2YNFssHVvujEQwyrihmQ7o2Gv6VKCvKI7CinHZZuJfo9W SKcCYpojzrdWxxglFFhNcrh8LDyAy0U7MBQVUiWUsX32y9xvrkumvqizAKuKgbS91iqc wgo5FgWVEpRQ2F+nTP3EFuCdaJ9BaIKf9eUqWTBOR5vY/1+GptnbP0ygfNLSPSXomOxe CfwqTxuJbShHIKB0EcXRgbJoJur8KFk9A3FAgEVyd6ub8bkCym9eHx5eGLM1mkjZQEJv CrFA== X-Gm-Message-State: AOAM5317T5bJOyVifGRRNt1SK9QYmhlLFYnHRR7cFZSgmBvom9RMo4Yh CK5DDJ2iqKhYqum6z7C+4VVRgU1E+Q/ONfYJx3Y= X-Google-Smtp-Source: ABdhPJykomo7ZyhdhH1YAXK4xyhoskOkpMaFOo5VC5j570wBLwCkeIO07SDkL4VXj7joM1DNnEXvjwfYLNuNM1n89rQ= X-Received: by 2002:a5e:c70a:: with SMTP id f10mr9148283iop.178.1602248239403; Fri, 09 Oct 2020 05:57:19 -0700 (PDT) MIME-Version: 1.0 References: <20200930155006.535712-1-l.stach@pengutronix.de> <5287bbc0ede98dd3fc0022f2062148275dafa05c.camel@pengutronix.de> In-Reply-To: <5287bbc0ede98dd3fc0022f2062148275dafa05c.camel@pengutronix.de> From: Adam Ford Date: Fri, 9 Oct 2020 07:57:08 -0500 Message-ID: Subject: Re: [PATCH 00/11] i.MX8MM power domain support To: Lucas Stach Cc: Jacky Bai , Shawn Guo , Rob Herring , Marek Vasut , "devicetree@vger.kernel.org" , Frieder Schrempf , "patchwork-lst@pengutronix.de" , dl-linux-imx , "kernel@pengutronix.de" , Fabio Estevam , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Fri, Oct 9, 2020 at 6:16 AM Lucas Stach wrote: > > Hi Jacky, > > On Fr, 2020-10-09 at 03:00 +0000, Jacky Bai wrote: > > > -----Original Message----- > > > From: Lucas Stach [mailto:l.stach@pengutronix.de] > > > Sent: Wednesday, September 30, 2020 11:50 PM > > > To: Shawn Guo ; Rob Herring > > > Cc: dl-linux-imx ; Fabio Estevam > > > ; Frieder Schrempf ; > > > Marek Vasut ; linux-arm-kernel@lists.infradead.org; > > > devicetree@vger.kernel.org; kernel@pengutronix.de; > > > patchwork-lst@pengutronix.de > > > Subject: [PATCH 00/11] i.MX8MM power domain support > > > > > > Hi all, > > > > > > this adds power domain support for the i.MX8MM to the existing GPCv2 driver. > > > It is not complete yet, as it is still missing the VPU and display power domains, > > > as those require support for the BLK_CTL regions of the VPUMIX and > > > DISPLAYMIX domains. A Linux driver for those regions on the i.MX8MP is > > > currently under development and we plan to use this as a template for the > > > i.MX8MM when the dust has settled. The changes in this series have been > > > made with this in mind, so once the BLK_CTL driver exists it should be a > > > matter of hooking things together via DT, with no further changes required on > > > the GPCv2 driver side (famous last words). > > > > > > Special thanks to Marek Vasut who helped with testing and debugging of early > > > versions of this code. > > > > > > > Lucas, > > > > thanks for working on this, but I think current support for 8MM can NOT 100% work due to HW limitation. > > Maybe, we need further discussion before moving forward, otherwise, we will meet awkward situation when NXP > > doing LTS upgrade. Below are some info shared. > > > > 1. The GPU & VPU related power domains need to do special handling due to HW limitation, can refer to the power domain sequence > > In NXP release. > > For the GPU this driver already does the same thing as the TF-A based > implementation by driving the GPU2D and GPU3D domains together and > triggering the SRC reset. > > For the VPU I expect that we can do all the necessary syncing with a > proper VPU BLK_CTL driver. > > > 2. another reason that we do power domain control in TF-A in NXP release is that MAIN NOC power domain can only be controlled by > > TF-A, and before MAIN NOC power domain, we need to check other MIXs' power status. If other power domain is controlled by linux side, > > It is not easy to cross world status sync. > > This is a valid concern and I want to learn more about this. When do > you turn off MAIN NOC power in the TF-A? Is it just system suspend? If > so I think it's a valid requirement for the kernel driver to shut down > all the peripheral power domains before entering system suspend. > > > 3. either 8MM, 8MN, or 8MP, the power domain design is different, I am not sure if it is the good to add hundreds line of code in GPCv2 each time > > a new SOC is added. > > I don't buy into this argument. We have lots of drivers in the Linux > kernel that require some changes for new SoC generations, that's what > Linux drivers are for. The complexity of the hardware doesn't disappear > just because you push some of the driver bits into TF-A, you just > handle the complexity at a different palce and IMHO that the wrong > place. The power domains have complex interactions with other drivers > in the Linux system, so debugging and deplyong fixes is much easier > when the power domain handling is fully done by a kernel driver. In an effort to keep the code size manageable, what if we were to propose a gpc-core configured to be a generic function common to all SoC's, and move the tables for each unique SoC into separate files. Making each SoC's GPC a Kconfig option could give people the ability to disable the various options that don't apply to their specific application, and the setup and configuration of the tables should be easier to read. I know of at least one touchscreen driver that does this (tsc200x). adam > > Regards, > Lucas > > > BR > > Jacky Bai > > > > > Regards, > > > Lucas > > > > > > Lucas Stach (11): > > > soc: imx: gpcv2: move to more ideomatic error handling in probe > > > soc: imx: gpcv2: move domain mapping to domain driver probe > > > soc: imx: gpcv2: split power up and power down sequence control > > > soc: imx: gpcv2: wait for ADB400 handshake > > > soc: imx: gpcv2: add runtime PM support for power-domains > > > soc: imx: gpcv2: allow domains without power-sequence control > > > soc: imx: gpcv2: add support for optional resets > > > dt-bindings: add defines for i.MX8MM power domains > > > soc: imx: gpcv2: add support for i.MX8MM power domains > > > arm64: dts: imx8mm: add GPC node and power domains > > > arm64: dts: imx8mm: put USB controllers into power-domains > > > > > > .../bindings/power/fsl,imx-gpcv2.yaml | 8 + > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 59 +++ > > > drivers/soc/imx/gpcv2.c | 501 > > > +++++++++++++++--- > > > include/dt-bindings/power/imx8mm-power.h | 22 + > > > 4 files changed, 516 insertions(+), 74 deletions(-) create mode 100644 > > > include/dt-bindings/power/imx8mm-power.h > > > > > > -- > > > 2.20.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 7220CC433DF for ; Fri, 9 Oct 2020 12:58:50 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 0A6DF222BA for ; Fri, 9 Oct 2020 12:58:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JnrrvhO1"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bTLrKdrf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0A6DF222BA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wnKdBgekX5+KBY8Fjq7RPn+hwDIkE87MGXXshg/B9S0=; b=JnrrvhO1P6vx4zuYF/UiabebB gE0XsNc0IcipNB1AWGkGOCMVKUBqKQnVcEdEpMfOh4aTqoTFgmS4hbl0HmGyNfZcyhe9J9Njx2mSG IygOck03YdR3iNHxW0EZkfs/KeldlkSBjLLxE8NGxo74RLcBNvJ/zfsC1mLMTP74T9gJDlq6AGkt5 6VUOJcl3xgs/wptrJofIwPbLM0UDQXx0g4Fbg9gsftR/OG6tQA4o69VsVwxf9wh4OTGsnHinTalt1 +IeZcBsQlvkGw7oCaaPSD6CV1W5sXEzu+DzO4h+EMj75OwkNeuCKHeJsz34O3R82vKCHJmKGBgmzJ MjIvfSi8Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQrxc-0001Pw-Si; Fri, 09 Oct 2020 12:57:24 +0000 Received: from mail-io1-xd44.google.com ([2607:f8b0:4864:20::d44]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQrxZ-0001P2-AL for linux-arm-kernel@lists.infradead.org; Fri, 09 Oct 2020 12:57:22 +0000 Received: by mail-io1-xd44.google.com with SMTP id k25so9967428ioh.7 for ; Fri, 09 Oct 2020 05:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EECETrKbmoPSDvlqCGPtlVQRxwctT/KKRtpH7yPiQSk=; b=bTLrKdrfvuUK/6IApP7UUzshOURZdohqllb2TZ3nBt9kzD9gameKV377bq+QAuPI0b 6mfCpjifwKllmzcR8KNJS4p/uMXgeWXPrAnhbgq0K6qD5m8GU9BhpKuP6QsFidjGzmu/ nBpvq9cS147lMoHSh/6m53gBPiqVRDZxYjksv3vnJbdlcav/88WA6s3UVN90fDa1Ao40 Md4FfOu/SjaqvQ9DASYxyfqpqHAbeV/U7nbQLhxtICcGHUBwznT46ADLRpZsmLx44Op/ kg9hWziKzWl9ybsoOWtGEIQi8oKttWjHmSJQLboS0WcJfSG9YvfFQaHHM1mNFHpFwCIn ZAEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EECETrKbmoPSDvlqCGPtlVQRxwctT/KKRtpH7yPiQSk=; b=nGmgTB12ClL7e8XTtQAxi0y5Yx+wk310vPauGnP9JnZEnwEAdNgJ6yc6gAu2cxe7Q3 co6chZ4Asngx2NvWGkWk/XY2LzrkVjEE8cobwTkYAUJqJcT2nZWve3fPkfqLIbWVtyT9 jNJhGE3fqdCS9EuPumDcw9t2FO4J5GL4w5LM8geiI3gu83kLsoMMoZA2/jjtl7JuDEyV u8o+UrWCf9PyP2MH2iOArLjfSAa+mNdmoDK+oTxUAT1GFtCVc2nO0lvetCRhvLWDZbVl 1FMY9Sp5WAhGVbF2YwRlfwqifHKemgyvqOLv+WoO28YfMSsuCcUwTCYo5x9sPIv3iCv1 dEiw== X-Gm-Message-State: AOAM531P8vj+UGP9z3XOZ1rzcTxST5OQMfE8AwrgGzExNT4Va6oqFKrT bqc/lX0YsmNT85Uno0iCqGnVNcpdlFGG+RW/keFEiQAdFdM= X-Google-Smtp-Source: ABdhPJykomo7ZyhdhH1YAXK4xyhoskOkpMaFOo5VC5j570wBLwCkeIO07SDkL4VXj7joM1DNnEXvjwfYLNuNM1n89rQ= X-Received: by 2002:a5e:c70a:: with SMTP id f10mr9148283iop.178.1602248239403; Fri, 09 Oct 2020 05:57:19 -0700 (PDT) MIME-Version: 1.0 References: <20200930155006.535712-1-l.stach@pengutronix.de> <5287bbc0ede98dd3fc0022f2062148275dafa05c.camel@pengutronix.de> In-Reply-To: <5287bbc0ede98dd3fc0022f2062148275dafa05c.camel@pengutronix.de> From: Adam Ford Date: Fri, 9 Oct 2020 07:57:08 -0500 Message-ID: Subject: Re: [PATCH 00/11] i.MX8MM power domain support To: Lucas Stach X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201009_085721_370142_77FB54AA X-CRM114-Status: GOOD ( 42.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marek Vasut , "devicetree@vger.kernel.org" , Jacky Bai , Fabio Estevam , Frieder Schrempf , "patchwork-lst@pengutronix.de" , Rob Herring , dl-linux-imx , "kernel@pengutronix.de" , Shawn Guo , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 9, 2020 at 6:16 AM Lucas Stach wrote: > > Hi Jacky, > > On Fr, 2020-10-09 at 03:00 +0000, Jacky Bai wrote: > > > -----Original Message----- > > > From: Lucas Stach [mailto:l.stach@pengutronix.de] > > > Sent: Wednesday, September 30, 2020 11:50 PM > > > To: Shawn Guo ; Rob Herring > > > Cc: dl-linux-imx ; Fabio Estevam > > > ; Frieder Schrempf ; > > > Marek Vasut ; linux-arm-kernel@lists.infradead.org; > > > devicetree@vger.kernel.org; kernel@pengutronix.de; > > > patchwork-lst@pengutronix.de > > > Subject: [PATCH 00/11] i.MX8MM power domain support > > > > > > Hi all, > > > > > > this adds power domain support for the i.MX8MM to the existing GPCv2 driver. > > > It is not complete yet, as it is still missing the VPU and display power domains, > > > as those require support for the BLK_CTL regions of the VPUMIX and > > > DISPLAYMIX domains. A Linux driver for those regions on the i.MX8MP is > > > currently under development and we plan to use this as a template for the > > > i.MX8MM when the dust has settled. The changes in this series have been > > > made with this in mind, so once the BLK_CTL driver exists it should be a > > > matter of hooking things together via DT, with no further changes required on > > > the GPCv2 driver side (famous last words). > > > > > > Special thanks to Marek Vasut who helped with testing and debugging of early > > > versions of this code. > > > > > > > Lucas, > > > > thanks for working on this, but I think current support for 8MM can NOT 100% work due to HW limitation. > > Maybe, we need further discussion before moving forward, otherwise, we will meet awkward situation when NXP > > doing LTS upgrade. Below are some info shared. > > > > 1. The GPU & VPU related power domains need to do special handling due to HW limitation, can refer to the power domain sequence > > In NXP release. > > For the GPU this driver already does the same thing as the TF-A based > implementation by driving the GPU2D and GPU3D domains together and > triggering the SRC reset. > > For the VPU I expect that we can do all the necessary syncing with a > proper VPU BLK_CTL driver. > > > 2. another reason that we do power domain control in TF-A in NXP release is that MAIN NOC power domain can only be controlled by > > TF-A, and before MAIN NOC power domain, we need to check other MIXs' power status. If other power domain is controlled by linux side, > > It is not easy to cross world status sync. > > This is a valid concern and I want to learn more about this. When do > you turn off MAIN NOC power in the TF-A? Is it just system suspend? If > so I think it's a valid requirement for the kernel driver to shut down > all the peripheral power domains before entering system suspend. > > > 3. either 8MM, 8MN, or 8MP, the power domain design is different, I am not sure if it is the good to add hundreds line of code in GPCv2 each time > > a new SOC is added. > > I don't buy into this argument. We have lots of drivers in the Linux > kernel that require some changes for new SoC generations, that's what > Linux drivers are for. The complexity of the hardware doesn't disappear > just because you push some of the driver bits into TF-A, you just > handle the complexity at a different palce and IMHO that the wrong > place. The power domains have complex interactions with other drivers > in the Linux system, so debugging and deplyong fixes is much easier > when the power domain handling is fully done by a kernel driver. In an effort to keep the code size manageable, what if we were to propose a gpc-core configured to be a generic function common to all SoC's, and move the tables for each unique SoC into separate files. Making each SoC's GPC a Kconfig option could give people the ability to disable the various options that don't apply to their specific application, and the setup and configuration of the tables should be easier to read. I know of at least one touchscreen driver that does this (tsc200x). adam > > Regards, > Lucas > > > BR > > Jacky Bai > > > > > Regards, > > > Lucas > > > > > > Lucas Stach (11): > > > soc: imx: gpcv2: move to more ideomatic error handling in probe > > > soc: imx: gpcv2: move domain mapping to domain driver probe > > > soc: imx: gpcv2: split power up and power down sequence control > > > soc: imx: gpcv2: wait for ADB400 handshake > > > soc: imx: gpcv2: add runtime PM support for power-domains > > > soc: imx: gpcv2: allow domains without power-sequence control > > > soc: imx: gpcv2: add support for optional resets > > > dt-bindings: add defines for i.MX8MM power domains > > > soc: imx: gpcv2: add support for i.MX8MM power domains > > > arm64: dts: imx8mm: add GPC node and power domains > > > arm64: dts: imx8mm: put USB controllers into power-domains > > > > > > .../bindings/power/fsl,imx-gpcv2.yaml | 8 + > > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 59 +++ > > > drivers/soc/imx/gpcv2.c | 501 > > > +++++++++++++++--- > > > include/dt-bindings/power/imx8mm-power.h | 22 + > > > 4 files changed, 516 insertions(+), 74 deletions(-) create mode 100644 > > > include/dt-bindings/power/imx8mm-power.h > > > > > > -- > > > 2.20.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel