[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=U531pq__emY9nXm1hZF3Hp3tGFQQTn0eX17rHYp5nH1Q@mail.gmail.com>
Date: Wed, 10 Apr 2019 13:59:18 -0700
From: Doug Anderson <dianders@...omium.org>
To: Matthias Kaehlcke <mka@...omium.org>
Cc: Heiko Stuebner <heiko@...ech.de>, Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
devicetree@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Douglas Anderson <dianders@...omium.org>
Subject: Re: [PATCH] ARM: dts: rockchip: Add BT_EN to the power sequence for veyron
Hi,
On Tue, Apr 9, 2019 at 4:14 PM Matthias Kaehlcke <mka@...omium.org> wrote:
>
> Add GPIO D5 (BT_ENABLE_L) as reset-GPIO to the power sequence for the
> Bluetooth/WiFi module. On devices with a Broadcom module the signal
> needs to be asserted to use Bluetooth.
>
> Note that BT_ENABLE_L is a misnomer in the schematics, the signal
> actually is active-high.
>
> Signed-off-by: Matthias Kaehlcke <mka@...omium.org>
> ---
> arch/arm/boot/dts/rk3288-veyron.dtsi | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
Looks right to me. Thanks!
Note that this might enable the signals in a different order than in
the downstream Chrome OS kernel, but it looks like it doesn't matter
in this case since the datasheet for the AzureWave module talks about
enabling / disabling these pins in either order.
Reviewed-by: Douglas Anderson <dianders@...omium.org>
Powered by blists - more mailing lists