Re: [PATCH v3 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Gupta, Pekon <pekon@xxxxxx> [140509 11:52]:
> >From: Tony Lindgren [mailto:tony@xxxxxxxxxxx]
> >
> >* Pekon Gupta <pekon@xxxxxx> [140422 00:34]:
> >> --- a/arch/arm/boot/dts/am335x-bone.dts
> >> +++ b/arch/arm/boot/dts/am335x-bone.dts
> >> @@ -9,6 +9,7 @@
> >>
> >>  #include "am33xx.dtsi"
> >>  #include "am335x-bone-common.dtsi"
> >> +#include "am335x-bone-memory-cape.dts"
> >>
> >>  &ldo3_reg {
> >>  	regulator-min-microvolt = <1800000>;
> >> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> >> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> >> @@ -9,6 +9,7 @@
> >>
> >>  #include "am33xx.dtsi"
> >>  #include "am335x-bone-common.dtsi"
> >> +#include "am335x-bone-memory-cape.dts"
> >>
> >>  &ldo3_reg {
> >>  	regulator-min-microvolt = <1800000>;
> >
> >Have you checked that including the capes unconditionally for
> >non-integrated devices is safe? Maybe decompile the dtb using
> >dtc and see what is in the produced dts file?
> >
> >I'm mostly worried about pinmux and GPMC as the pins can be used
> >by other capes and GPMC can have other devices.
> >
> I checked by de-compiling beaglebone.dtb with this patch included,
> where GPMC pinmux conflicts with eMMC (MMC2). It shows that
> both the pin-mux are present, and GPMC node is "disabled" by
> default, whereas the eMMC (MMC2) node.
> So I think this patch is safe pin-muxing wise.
> ---------------
> 	gpmc@50000000 {
> 			...
> 			status = "disabled";
> 			pinctrl-names = "default";
> 			pinctrl-0 = <0x38>;
> 			}
> 	mmc@481d8000 {
> 			ti,hwmods = "mmc2";
> 			...
> 			status = "okay";
> 			pinctrl-0 = <0x2e>;
> 			bus-width = <0x8>;
> 		}
> 
> 		pinmux_emmc_pins {
> 			pinctrl-single,pins = <0x80 0x32 0x84 0x32 0x0 0x31 0x4 0x31 0x8 0x31 0xc 0x31 0x10 0x31 0x14 0x31 0x18 0x31 0x1c 0x31>;
> 			linux,phandle = <0x2e>;
> 			phandle = <0x2e>;
> 		};
> 		nand_flash_x16 {
> 			pinctrl-single,pins = <0x0 0x28 0x4 0x28 0x8 0x28 0xc 0x28 0x10 0x28 0x14 0x28 0x18 0x28 0x1c 0x28 0x20 0x28 0x24 0x28 0x28 0x28 0x2c 0x28 0x30 0x28 0x34 0x28 0x38 0x28 0x3c 0x28 0x70 0x30 0x74 0x17 0x7c 0x10 0x90 0x8 0x94 0x8 0x98 0x8 0x9c 0x8>;
> 			linux,phandle = <0x38>;
> 			phandle = <0x38>;
> 		};
> --------------

OK makes sense as long as the pin names in .dtb are different
for the capes. 
 
> >Also, this should probably also wait until u-boot has been
> >confirmed of being able to enable these devices?
> >
> Would be good if you accept this one, as this will act as reference for
> beaglebone cape users for pin-mux and other GPMC related bindings

What about other GPMC using capes? If we have another cape
that uses a separate GPMC partition we can't just set &gpmc
to status = "disabled" state.

Sorry, I can't merge this until all the issues are sorted out
and we have proven that the concept works by having u-boot
toggle the enabled status for the capes.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux