On Thu, Aug 16, 2012 at 5:51 PM, Benoît Thébaudeau <benoit.thebaud...@advansee.com> wrote: > Dear Matt Sealey, > >> On Thu, Aug 16, 2012 at 3:09 PM, Benoît Thébaudeau >> <benoit.thebaud...@advansee.com> wrote: > > To improve code quality... And because I have local boards that also needed > the > same functions, so it avoided more duplications. > >> For i.MX we have two iomux models and function sets available for >> doing identical stuff. Isn't that kind of wasteful? > > There's probably room for improvement on iomux, but we have to start cleanup > with something. If you want, you can submit patches and rebase after mine.
Done, to a degree :) > would avoid you to duplicate your patch code for all boards. These are two > different topics, and my change comes logically first. See patches. On Marex's recommendation I based against u-boot-imx master rather than trying to fit it on top of your stuff. In the end, I would prefer that boards specifically implement pad settings in their own board files rather than assuming that some common function in the driver will suit them; we have an MX6 board here that uses the SD4 pads for UART2 for debug console. This is absolutely not common at all to any other MX6 board, so it would have to do UART pad setup and not use the generic function. With pads defined as reasonable defaults, and NEW_PAD_CTRL available to modify pads per-board this is a more flexible setup and exactly why it was coded this way in Linux and why Freescale seemed to see fit to backport it to U-Boot (and why it was accepted to mainline for MX6). There's still some cleanup, all the other boards, and obviously MX53 needs to be added to make it more useful. If we wish to continue with functions like mx51_uart1_setup() or so, then that function can reference these values, but I think you will find it more likely that someone in the future modifies it to take reference to an iomux_v3_cfg_t array so they can configure their board properly to something that doesn't meet your assumed defaults, or defines the pad setup internally to their board and skips calling your setup function. Then there would be no difference between calling mx51_uart1_setup vs. imx_iomux_v3_setup_multiple_pads anyway.. reducing the need for it. I kept the redefinition of the pads for UART etc, even though POR defaults work fine, just to keep within your assumption that we shouldn't trust POR defaults.. although I don't think that loading code via JTAG and executing it (i.e. skipping the i.MX boot ROM) is a very common process at all as it just flies in the face of what Freescale intend to be the boot process for the chip, and in any case, the defaults are part of the SoC logic (and are correct in the documentation as far as I have checked), not some pre-U-Boot software configuration. Given the dangers inherent in doing this anyway, I don't think it would be fitting to make sure things are configured how you want (and in any case, why would someone configure UART pads differently to your expectations, and then let U-Boot reconfigure them on boot?) -- Matt Sealey <m...@genesi-usa.com> Product Development Analyst, Genesi USA, Inc. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
