| Message ID | 1436279277-3386-3-git-send-email-rogerq@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 07/07/2015 04:27 PM, Roger Quadros wrote: > Driver core sets "default" pinmux on on probe and CAN driver > sets "sleep" pinmux during register. This causes a small window > where the CAN pins are in "default" state with the DCAN module > being disabled. > > Change the "default" state to be like sleep so this glitch is > avoided. Add a new "active" state that is used by the driver > when CAN is actually active. Who is taking care of this patch? I'm applying 1/2 (v2) to linux-can, should I take this patch, too? Marc
On 07/09/2015 08:34 PM, Marc Kleine-Budde wrote: > On 07/07/2015 04:27 PM, Roger Quadros wrote: >> Driver core sets "default" pinmux on on probe and CAN driver >> sets "sleep" pinmux during register. This causes a small window >> where the CAN pins are in "default" state with the DCAN module >> being disabled. >> >> Change the "default" state to be like sleep so this glitch is >> avoided. Add a new "active" state that is used by the driver >> when CAN is actually active. > > Who is taking care of this patch? I'm applying 1/2 (v2) to linux-can, > should I take this patch, too? I've included this patch in my pull request. Marc
* Marc Kleine-Budde <mkl@pengutronix.de> [150712 12:22]: > On 07/09/2015 08:34 PM, Marc Kleine-Budde wrote: > > On 07/07/2015 04:27 PM, Roger Quadros wrote: > >> Driver core sets "default" pinmux on on probe and CAN driver > >> sets "sleep" pinmux during register. This causes a small window > >> where the CAN pins are in "default" state with the DCAN module > >> being disabled. > >> > >> Change the "default" state to be like sleep so this glitch is > >> avoided. Add a new "active" state that is used by the driver > >> when CAN is actually active. > > > > Who is taking care of this patch? I'm applying 1/2 (v2) to linux-can, > > should I take this patch, too? > > I've included this patch in my pull request. That's fine thanks there should not be any merge conflicts. For things going in during the merge windows we need to worry about the dts merge conflicts. Usually not a problem for fixes. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index aa46590..096f68b 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -686,7 +686,8 @@ &dcan1 { status = "ok"; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&dcan1_pins_default>; + pinctrl-names = "default", "sleep", "active"; + pinctrl-0 = <&dcan1_pins_sleep>; pinctrl-1 = <&dcan1_pins_sleep>; + pinctrl-2 = <&dcan1_pins_default>; }; diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts index 4e1b605..8037384 100644 --- a/arch/arm/boot/dts/dra72-evm.dts +++ b/arch/arm/boot/dts/dra72-evm.dts @@ -587,9 +587,10 @@ &dcan1 { status = "ok"; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&dcan1_pins_default>; + pinctrl-names = "default", "sleep", "active"; + pinctrl-0 = <&dcan1_pins_sleep>; pinctrl-1 = <&dcan1_pins_sleep>; + pinctrl-2 = <&dcan1_pins_default>; }; &qspi {
Driver core sets "default" pinmux on on probe and CAN driver sets "sleep" pinmux during register. This causes a small window where the CAN pins are in "default" state with the DCAN module being disabled. Change the "default" state to be like sleep so this glitch is avoided. Add a new "active" state that is used by the driver when CAN is actually active. Signed-off-by: Roger Quadros <rogerq@ti.com> --- arch/arm/boot/dts/dra7-evm.dts | 5 +++-- arch/arm/boot/dts/dra72-evm.dts | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-)