lkml.org 
[lkml]   [2012]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] efikamx: reintroduce Genesi Efika MX Smarttop via device tree
    On Wed, Aug 8, 2012 at 10:15 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
    > On Tue, Aug 07, 2012 at 04:46:18PM -0500, Matt Sealey wrote:
    >> This device tree only supports the final retail board ("TO3").
    >>
    >> It is currently feature equivalent to the MX51 Babbage device tree. The
    >> following features have been tested and work as well as can be expected:
    [snip]
    >> + soc {
    >> + aips@70000000 {
    >> + spba@70000000 {
    >> + esdhc@70004000 {
    >
    > The pinctrl_provide_dummies() in imx51_dt_init() is something to be
    > removed. Then any driver calling pinctrl API will require pinctrl
    > set up for the device here. So please have the pinctrl setup for
    > those devices.

    Absolutely not. Our pins are muxed in U-Boot as they should be. I
    refuse to add pinmux entries
    or any setup at all for this. What's stopping this right now is you
    need a new U-Boot which we
    didn't release or mainline because we are still testing it (old U-Boot
    shipped on the boards
    cannot boot device tree anyway). While the number of users of this is
    limited to everyone in
    the office here and a few trusted testers, actually the support here
    is meaningless for everyone
    else, but we feel it needs to go into the tree so we can track changes
    when people changing
    bindings and basically be future-thinking. We need the nitpicks, but
    in this instance, I will
    take a leaf from Russell's book and say I violently disagree with
    requiring pinctrl to be set up.
    There's no need on MX51 with the current state of the architecture and
    we've successfully
    tested all pad settings in mainline (and older kernels by stripping
    muxing from the kernel)
    just relying on gpio_direction and value sets.

    We'll have a public U-Boot for this board by the end of next week
    probably, and it will do it
    right the first time.

    >> + wdog@73f98000 {
    >> + status = "okay";
    >> + };
    >
    > Remove it. I have queued a patch to enable wdog in <soc>.dtsi
    > by default.

    Okay.

    >> + aips@80000000 {
    >> + sdma@83fb0000 {
    >> + fsl,sdma-ram-script-name = "imx/sdma/sdma-imx51.bin";
    >> + };
    >
    > Remove it. I have seen a patch to move this name into <soc>.dtsi
    > as default.

    BTW I propose we make this somehow a bootloader-stage thing - at least, the SDMA
    firmware should be in a location which is dictated not by the kernel
    itself, certainly not
    the device tree, but packaging and operating system dependent
    features. It describes
    the board, not the rootfs. As in, depending on the OS booted it may not be
    imx/sdma/sdma-imx51.bin or anything like it. Remember device trees are NOT just
    for Linux (or Android, which may still put it in a relative path with
    that name, but it
    may NOT depending on future changes!)

    In a boot.scr for modern U-Boot you might just have

    setenv bootargs ${bootargs} imx-sdma.firmware="imx/sdma/sdma-imx51.bin"

    Or something similar. OS filesystem paths in device tree are absolutely wrong.

    >> -dtb-$(CONFIG_MACH_IMX51_DT) += imx51-babbage.dtb
    >> +dtb-$(CONFIG_MACH_IMX51_DT) += imx51-babbage.dtb imx51-efikamx.dtb
    >
    > Please have the new entry on the new line like dtb-$(CONFIG_SOC_IMX6Q).
    > Yes, we will change dtb-$(CONFIG_MACH_IMX53_DT).

    Okay.

    --
    Matt Sealey <matt@genesi-usa.com>
    Product Development Analyst, Genesi USA, Inc.


    \
     
     \ /
      Last update: 2012-08-08 19:21    [W:4.323 / U:0.548 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site