* [PATCH] arm64: dts: allwinner: a64-oceanic-5205-5inmfd: Enable CAN @ 2019-04-18 14:16 Jagan Teki 2019-04-18 14:56 ` Maxime Ripard 0 siblings, 1 reply; 6+ messages in thread From: Jagan Teki @ 2019-04-18 14:16 UTC (permalink / raw) To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland Cc: devicetree, linux-kernel, linux-sunxi, Jagan Teki, Michael Trimarchi, linux-amarula, linux-arm-kernel Oceanic 5205 5inMFD has MCP2515 CAN device connected via SPI1. - via SPI1 bus - vdd supplied by 5V supply along with PL2 enable pin - xceiver supply same as vdd - can oscillator connected at 20MHz - PB2 gpio as interrupt pin - PD6 gpio as RX_BUF1_CAN0 - PD7 gpio as RX_BUF0_CAN0 Tested-by: Tamas Papp <tamas@osukl.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> --- .../sun50i-a64-oceanic-5205-5inmfd.dts | 43 +++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts index f0cd6587f619..22535a297f51 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts @@ -21,6 +21,24 @@ chosen { stdout-path = "serial0:115200n8"; }; + + can_osc: can-osc { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <20000000>; + }; + + reg_can_v5v: reg-can-v5v { + compatible = "regulator-fixed"; + regulator-name = "reg-can-v5v"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + regulator-boot-on; + enable-active-high; + gpio = <&r_pio 0 2 GPIO_ACTIVE_HIGH>; /* CAN_3V3_EN: PL2 */ + status = "okay"; + }; + }; &ehci0 { @@ -77,6 +95,31 @@ status = "okay"; }; +&pio { + can_pins: can-pins { + pins = "PD6", /* RX_BUF1_CAN0 */ + "PD7"; /* RX_BUF0_CAN0 */ + function = "gpio_in"; + }; +}; + +&spi1 { + status = "okay"; + + can@0 { + compatible = "microchip,mcp2515"; + reg = <0>; + spi-max-frequency = <10000000>; + pinctrl-names = "default"; + pinctrl-0 = <&can_pins>; + interrupt-parent = <&pio>; + interrupts = <1 2 IRQ_TYPE_EDGE_FALLING>; /* INT_CAN0: PB2 */ + clocks = <&can_osc>; + vdd-supply = <®_can_v5v>; + xceiver-supply = <®_can_v5v>; + }; +}; + &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_pb_pins>; -- 2.18.0.321.gffc6fa0e3 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] arm64: dts: allwinner: a64-oceanic-5205-5inmfd: Enable CAN 2019-04-18 14:16 [PATCH] arm64: dts: allwinner: a64-oceanic-5205-5inmfd: Enable CAN Jagan Teki @ 2019-04-18 14:56 ` Maxime Ripard 2019-05-21 6:47 ` Michael Nazzareno Trimarchi 0 siblings, 1 reply; 6+ messages in thread From: Maxime Ripard @ 2019-04-18 14:56 UTC (permalink / raw) To: Jagan Teki Cc: Mark Rutland, devicetree, linux-sunxi, linux-kernel, Chen-Yu Tsai, Rob Herring, Michael Trimarchi, linux-amarula, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 1898 bytes --] On Thu, Apr 18, 2019 at 07:46:58PM +0530, Jagan Teki wrote: > Oceanic 5205 5inMFD has MCP2515 CAN device connected via SPI1. > > - via SPI1 bus > - vdd supplied by 5V supply along with PL2 enable pin > - xceiver supply same as vdd > - can oscillator connected at 20MHz > - PB2 gpio as interrupt pin > - PD6 gpio as RX_BUF1_CAN0 > - PD7 gpio as RX_BUF0_CAN0 > > Tested-by: Tamas Papp <tamas@osukl.com> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > --- > .../sun50i-a64-oceanic-5205-5inmfd.dts | 43 +++++++++++++++++++ > 1 file changed, 43 insertions(+) > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts > index f0cd6587f619..22535a297f51 100644 > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts > @@ -21,6 +21,24 @@ > chosen { > stdout-path = "serial0:115200n8"; > }; > + > + can_osc: can-osc { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <20000000>; > + }; > + > + reg_can_v5v: reg-can-v5v { > + compatible = "regulator-fixed"; > + regulator-name = "reg-can-v5v"; > + regulator-min-microvolt = <5000000>; > + regulator-max-microvolt = <5000000>; > + regulator-boot-on; > + enable-active-high; > + gpio = <&r_pio 0 2 GPIO_ACTIVE_HIGH>; /* CAN_3V3_EN: PL2 */ > + status = "okay"; You don't need the status property here. > + }; > + > }; > > &ehci0 { > @@ -77,6 +95,31 @@ > status = "okay"; > }; > > +&pio { > + can_pins: can-pins { > + pins = "PD6", /* RX_BUF1_CAN0 */ > + "PD7"; /* RX_BUF0_CAN0 */ > + function = "gpio_in"; > + }; > +}; That isn't needed. What are they used for, you're not tying them to anything? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] arm64: dts: allwinner: a64-oceanic-5205-5inmfd: Enable CAN 2019-04-18 14:56 ` Maxime Ripard @ 2019-05-21 6:47 ` Michael Nazzareno Trimarchi 2019-05-21 8:10 ` Maxime Ripard 0 siblings, 1 reply; 6+ messages in thread From: Michael Nazzareno Trimarchi @ 2019-05-21 6:47 UTC (permalink / raw) To: Maxime Ripard Cc: Mark Rutland, devicetree, linux-sunxi, LKML, Chen-Yu Tsai, Rob Herring, Jagan Teki, linux-amarula, linux-arm-kernel Hi Maxime On Thu, Apr 18, 2019 at 4:56 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > On Thu, Apr 18, 2019 at 07:46:58PM +0530, Jagan Teki wrote: > > Oceanic 5205 5inMFD has MCP2515 CAN device connected via SPI1. > > > > - via SPI1 bus > > - vdd supplied by 5V supply along with PL2 enable pin > > - xceiver supply same as vdd > > - can oscillator connected at 20MHz > > - PB2 gpio as interrupt pin > > - PD6 gpio as RX_BUF1_CAN0 > > - PD7 gpio as RX_BUF0_CAN0 > > > > Tested-by: Tamas Papp <tamas@osukl.com> > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > --- > > .../sun50i-a64-oceanic-5205-5inmfd.dts | 43 +++++++++++++++++++ > > 1 file changed, 43 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts > > index f0cd6587f619..22535a297f51 100644 > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts > > @@ -21,6 +21,24 @@ > > chosen { > > stdout-path = "serial0:115200n8"; > > }; > > + > > + can_osc: can-osc { > > + compatible = "fixed-clock"; > > + #clock-cells = <0>; > > + clock-frequency = <20000000>; > > + }; > > + > > + reg_can_v5v: reg-can-v5v { > > + compatible = "regulator-fixed"; > > + regulator-name = "reg-can-v5v"; > > + regulator-min-microvolt = <5000000>; > > + regulator-max-microvolt = <5000000>; > > + regulator-boot-on; > > + enable-active-high; > > + gpio = <&r_pio 0 2 GPIO_ACTIVE_HIGH>; /* CAN_3V3_EN: PL2 */ > > + status = "okay"; > > You don't need the status property here. > Correct, need to be dropped > > + }; > > + > > }; > > > > &ehci0 { > > @@ -77,6 +95,31 @@ > > status = "okay"; > > }; > > > > +&pio { > > + can_pins: can-pins { > > + pins = "PD6", /* RX_BUF1_CAN0 */ > > + "PD7"; /* RX_BUF0_CAN0 */ > > + function = "gpio_in"; > > + }; > > +}; > > That isn't needed. What are they used for, you're not tying them to > anything? Mux of their function is correct. They are connected in the schematics but not used right now. I can garantee that kernel wlll always configurred in the right way and if I want I can export in userspace for debug purpose Michael > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] arm64: dts: allwinner: a64-oceanic-5205-5inmfd: Enable CAN 2019-05-21 6:47 ` Michael Nazzareno Trimarchi @ 2019-05-21 8:10 ` Maxime Ripard 2019-05-21 11:08 ` Michael Nazzareno Trimarchi 0 siblings, 1 reply; 6+ messages in thread From: Maxime Ripard @ 2019-05-21 8:10 UTC (permalink / raw) To: Michael Nazzareno Trimarchi Cc: Mark Rutland, devicetree, linux-sunxi, LKML, Chen-Yu Tsai, Rob Herring, Jagan Teki, linux-amarula, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 1279 bytes --] On Tue, May 21, 2019 at 08:47:02AM +0200, Michael Nazzareno Trimarchi wrote: > > > + }; > > > + > > > }; > > > > > > &ehci0 { > > > @@ -77,6 +95,31 @@ > > > status = "okay"; > > > }; > > > > > > +&pio { > > > + can_pins: can-pins { > > > + pins = "PD6", /* RX_BUF1_CAN0 */ > > > + "PD7"; /* RX_BUF0_CAN0 */ > > > + function = "gpio_in"; > > > + }; > > > +}; > > > > That isn't needed. What are they used for, you're not tying them to > > anything? > > Mux of their function is correct. They are connected in the schematics > but not used right now. Then describe the whole thing or don't? And that's kind of missing my point. If that pin group isn't related to any device, the pin muxing will not be changed. So that group, in itself, has strictly no effect. Moreover, you don't need a pin group in the first place to mux pins in GPIOs, the GPIO API will make sure that is the case when you request it. > I can garantee that kernel wlll always configurred in the right way > and if I want I can export in userspace > for debug purpose Yes, because the API does it, not your change Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] arm64: dts: allwinner: a64-oceanic-5205-5inmfd: Enable CAN 2019-05-21 8:10 ` Maxime Ripard @ 2019-05-21 11:08 ` Michael Nazzareno Trimarchi 2019-05-23 20:54 ` Maxime Ripard 0 siblings, 1 reply; 6+ messages in thread From: Michael Nazzareno Trimarchi @ 2019-05-21 11:08 UTC (permalink / raw) To: Maxime Ripard Cc: Mark Rutland, devicetree, linux-sunxi, LKML, Chen-Yu Tsai, Rob Herring, Jagan Teki, linux-amarula, linux-arm-kernel Hi Maxime On Tue, May 21, 2019 at 10:10 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > On Tue, May 21, 2019 at 08:47:02AM +0200, Michael Nazzareno Trimarchi wrote: > > > > + }; > > > > + > > > > }; > > > > > > > > &ehci0 { > > > > @@ -77,6 +95,31 @@ > > > > status = "okay"; > > > > }; > > > > > > > > +&pio { > > > > + can_pins: can-pins { > > > > + pins = "PD6", /* RX_BUF1_CAN0 */ > > > > + "PD7"; /* RX_BUF0_CAN0 */ > > > > + function = "gpio_in"; > > > > + }; > > > > +}; > > > > > > That isn't needed. What are they used for, you're not tying them to > > > anything? > > > > Mux of their function is correct. They are connected in the schematics > > but not used right now. > > Then describe the whole thing or don't? > Ok > And that's kind of missing my point. If that pin group isn't related > to any device, the pin muxing will not be changed. So that group, in > itself, has strictly no effect. > > Moreover, you don't need a pin group in the first place to mux pins in > GPIOs, the GPIO API will make sure that is the case when you request > it. This is correct on sunxi. Is this valid for sunxi or in general in all the SoC? Anyway make sense to have pins configured and place in the right state, just suppose if the booting stage is wrong or anything that make those pins in the wrong configuration > > > I can garantee that kernel wlll always configurred in the right way > > and if I want I can export in userspace > > for debug purpose Correct if you start to use it but if you want them right configured the right place is in the default state e/o initstate if this can be a problem of the hardware Default state: the state the pinctrl handle shall be put * into as default, usually this means the pins are up and ready to * be used by the device driver. This state is commonly used by * hogs to configure muxing and pins at boot, and also as a state * to go into when returning from sleep and idle in * .pm_runtime_resume() or ordinary .resume() for example. Now the pins are connected to the canbus as should be and they are configured and usually put in the right state. + compatible = "microchip,mcp2515"; + reg = <0>; + spi-max-frequency = <10000000>; + pinctrl-names = "default"; + pinctrl-0 = <&can_pins>; > > Yes, because the API does it, not your change > Do you prefer to drop the pinmux? or update the commit message > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] arm64: dts: allwinner: a64-oceanic-5205-5inmfd: Enable CAN 2019-05-21 11:08 ` Michael Nazzareno Trimarchi @ 2019-05-23 20:54 ` Maxime Ripard 0 siblings, 0 replies; 6+ messages in thread From: Maxime Ripard @ 2019-05-23 20:54 UTC (permalink / raw) To: Michael Nazzareno Trimarchi Cc: Mark Rutland, devicetree, linux-sunxi, LKML, Chen-Yu Tsai, Rob Herring, Jagan Teki, linux-amarula, linux-arm-kernel Hi Michael, On Tue, May 21, 2019 at 01:08:09PM +0200, Michael Nazzareno Trimarchi wrote: > On Tue, May 21, 2019 at 10:10 AM Maxime Ripard > <maxime.ripard@bootlin.com> wrote: > > > > On Tue, May 21, 2019 at 08:47:02AM +0200, Michael Nazzareno Trimarchi wrote: > > > > > + }; > > > > > + > > > > > }; > > > > > > > > > > &ehci0 { > > > > > @@ -77,6 +95,31 @@ > > > > > status = "okay"; > > > > > }; > > > > > > > > > > +&pio { > > > > > + can_pins: can-pins { > > > > > + pins = "PD6", /* RX_BUF1_CAN0 */ > > > > > + "PD7"; /* RX_BUF0_CAN0 */ > > > > > + function = "gpio_in"; > > > > > + }; > > > > > +}; > > > > > > > > That isn't needed. What are they used for, you're not tying them to > > > > anything? > > > > > > Mux of their function is correct. They are connected in the schematics > > > but not used right now. > > > > Then describe the whole thing or don't? > > > > Ok > > > And that's kind of missing my point. If that pin group isn't related > > to any device, the pin muxing will not be changed. So that group, in > > itself, has strictly no effect. > > > > Moreover, you don't need a pin group in the first place to mux pins in > > GPIOs, the GPIO API will make sure that is the case when you request > > it. > > This is correct on sunxi. Is this valid for sunxi or in general in > all the SoC? IIRC, it happens on all the SoCs that have a shared GPIO/pinctrl driver. > Anyway make sense to have pins configured and place in the right > state, just suppose if the booting stage is wrong or anything that > make those pins in the wrong configuration It would be a bug in the pinctrl / GPIO code that would need to be fixed. > > > > > I can garantee that kernel wlll always configurred in the right way > > > and if I want I can export in userspace > > > for debug purpose > > Correct if you start to use it but if you want them right configured > the right place is in the default state e/o initstate if this can be > a problem of the hardware What problem do you have exactly? > Default state: the state the pinctrl handle shall be put > * into as default, usually this means the pins are up and ready to > * be used by the device driver. This state is commonly used by > * hogs to configure muxing and pins at boot, and also as a state > * to go into when returning from sleep and idle in > * .pm_runtime_resume() or ordinary .resume() for example. > > Now the pins are connected to the canbus as should be and they are > configured and usually put in the right state. As soon as you call gpio_get, the pins will be configured properly. And, pinctrl shouldn't allow that configuration (gpio_get + a pinctrl node for GPIOs) in our case. We do on most SoCs (all but the H6) for historical reasons, but this creates other bugs that we can't really fix right now. Still, we're slowly removing all of those pinctrl nodes, so it's not really to add new ones. > + compatible = "microchip,mcp2515"; > + reg = <0>; > + spi-max-frequency = <10000000>; > + pinctrl-names = "default"; > + pinctrl-0 = <&can_pins>; > > > > > Yes, because the API does it, not your change > > Do you prefer to drop the pinmux? or update the commit message Drop the pinctrl group Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-05-23 20:55 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-04-18 14:16 [PATCH] arm64: dts: allwinner: a64-oceanic-5205-5inmfd: Enable CAN Jagan Teki 2019-04-18 14:56 ` Maxime Ripard 2019-05-21 6:47 ` Michael Nazzareno Trimarchi 2019-05-21 8:10 ` Maxime Ripard 2019-05-21 11:08 ` Michael Nazzareno Trimarchi 2019-05-23 20:54 ` Maxime Ripard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox