On Thu, Aug 07, 2008 at 05:31:44PM +0800, Li Yang wrote: [...] > > > > > reg = <0x6c0 0x40 0x8b00 0x100>; > > > interrupts = <11>; > > > interrupt-parent = <&qeic>; > > > mode = "slave"; > > > > I'd suggest to rename this to "peripheral" as we use for fsl dual-role > > usb controller. > > As there will be two drivers chosen by compatible, I'm now inclined to > put this information in compatible.
Please don't. I deliberately wrote bindings w/o specifing "udc" or "host" in the compatible entry. "udc"/"host" is the modes of an USB controller, but the controller itself is the same: "fsl,mpc8323-qe-usb" (the first chip with QE USB). So the driver should always match this device, but it can return -ENODEV if mode is unspecified or !peripheral. > > > + usb-clock = <21>; > > > + pio-handle = <&pio_usb>; > > > > Can we not introduce new pio maps? The pio setup should be done > > by the firmware, or at least fixed up via the board file, as in > > arch/powerpc/platforms/83xx/mpc832x_rdb.c. > > Actually I am more apt to leaving full hardware access to kernel than > firmware, especially for devices that are not used in firmware. The > reason why I made the pin-configuration flexible is that for development > boards the role of pins are often changeable. [...] > Pio config is board and board configuration specific. It's better to > make it configurable by device tree. Device tree isn't configuration file. The bad thing about pio-map is that it is passing raw values instead of actually describing the hardware. For example, pio-map = <1 6 2 0 1 0>; The thing describes bankB/pin6.. but you'll can't tell what exactly this pin supposed to do. :-/ Basically "pio-map" is expanded version of this: fsl,cpodr-reg = <0x...>; fsl,cppar1-reg = <0x...>; fsl,cppar2-reg = <0x...>; ... Instead, it would be great to have something like this: [EMAIL PROTECTED] { /* * gpio/pinmux pin * controller */ pio-map = <&pinmuxA 1 /* bindings says first pin is clk */ &pinmuxB 14 /* bindings says second pin is usboe */ ...>; }; [EMAIL PROTECTED] { pio-map = <&pinmuxA 2 /* bindings says first pin is clk */ &pinmuxB 24 /* bindings says second pin is rxd0 */ &pinmuxB 21 /* bindings says second pin is rxd1 */ ...>; }; Then drivers would call something like this in probe(): clk = qe_get_clock(node, "fsl,fullspeed-clock"); qe_set_pinmux(pin0, QE_PIN_FUNC_CLK(clk)); qe_set_pinmux(pin1, QE_PIN_FUNC_USB_OE); ...or ucc ethernet... qe_set_pinmux(pin[rx_n], QE_PIN_FUNC_UCC_RXD(ucc_num, rx_n)); Obviously, this is quite hard to implement (and expensive, too), since each SoC implementation has its own function<->pin<->regvalue mapping.. Thus nobody even think to bother with this. Anyway, I'm not that opposed to the current pio-maps, but it would be great if we could avoid them where possible. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev