B3 buzzer + change front LED color

[asl]

I think blinking at around 10Hz is possible. From mach-orion5x/dns323-setup.c

Code: Select all

#define ORION_BLINK_HALF_PERIOD 100 /* ms */

static int dns323_gpio_blink_set(unsigned gpio, int state,
        unsigned long *delay_on, unsigned long *delay_off)
{

        if (delay_on && delay_off && !*delay_on && !*delay_off)
                *delay_on = *delay_off = ORION_BLINK_HALF_PERIOD;

        switch(state) {
        case GPIO_LED_NO_BLINK_LOW:
        case GPIO_LED_NO_BLINK_HIGH:
                orion_gpio_set_blink(gpio, 0);
                gpio_set_value(gpio, state);
                break;
        case GPIO_LED_BLINK:
                orion_gpio_set_blink(gpio, 1);
        }
        return 0;
}

I _think_ this will work on B3 as well. I won't know until i actually get some hardware and try it out.

[tor]

Hi again asl,

You are absolutely correct in that one should use the gpio-led functionality. The reason for me not using it in the first place was to accommodate the use of this one wire pvm.

Unfortunately our userspace code isn't that abstracted. Fortunately we are talking about some shell scripts and a few perl dito. So migrating these really shouldn't be a big problem.

Regarding the blinking from the dns323 I say ignore it. I assume this code uses the built in blink functionality in the CPU. The frequency is derived from one of the clock sources and we wrote that of for some reason, which i don't remember any more, during development.

Are you considering adapting the sources for upstreams submission? Have you read the discussions at debian arm http://www.mail-archive.com/debian-arm@ ... 11791.html?

And if you want more info/help don't hesitate to contact me personally. I would really like seeing these sources upstream but our resources internally is limited to say the least

/Tor

[asl]

Hi Tor

I did see the Debian post before. It seems like a good itch to scratch, get it in mainline. I've had a few minor patches included in the past, but never support for a new target.

It looks like the basic target code itself is not too controversial. The four defconfig i guess are a no go, given the recent removal of lots of defconfig files from the ARM arch. I will at some point look at how well the kirkwood_defconfig fits. Inverting the PHY LED i guess is also doable. The Atheros regulatory domains could be a bigger issue. Some how i think that patch will get rejected, unless it is possible to argue that other chipsets allow it. Maybe a better solution is to provide a tool for writing to the eeprom? I've no idea if that is actually possible.

[tor]

Hi asl,

Regarding defconfigs, I think you really would like to have our default default one if possible. The other three is only for our maintenance and could safely be removed.

The phy-led patch does not add any necessary functionality. WIthout it the leds will, as implied, be inverted i.e on it is normally of and vice versa. But that said it would be nice to have included.

The regulatory patch will never be accepted upstream, we picked that one up from openwrt, since it loosens the regulatory. Allowing us to set a domain depending on what country/timezone you are in.

/Tor

[asl]

Looking at the sources it seems that only one defconfig per architecture is now allowed. It contains enough to compile the kernel, but it is very minimalistic. When building a distribution you use another .config file, eg the debian .config, or the ubuntu .config.

My current plan is to just add the bubba3 to the kirkwood defconfig and not submit any other defconfig files. Anybody building 3.6.39 would just copy the 2.6.37 .config from /boot and use that as a basis.

[asl]

Hi asl (And others),

You can safely ignore these functions for now. The first revisions of B3 had a one wire "pvm" interface to enable blinking with the leds. This never worked out due to crappy documentation on that circuit (Resulting in really crappy code on that part as well). Thus we ripped out all functionality except the code to set the circuit in "Pass through" mode leaving simple GPIO for the leds.

Upcoming production batches will thus not even have this circuit. So do ignore

/Tor

What state does the PWM come up in? Do i need to initialize it into pass through mode, or will a power on reset will it on its own go into pass through mode? Is the data sheet available without an NDA?

I don't want to break however many thousand devices that are already out there with the PWM, but i also don't want to add code if its not needed.

[asl]

You can use any of the standard LED trippers:

lunn@b3:/sys/class/leds/bubba3:blue:active$ cat trigger
[none] timer heartbeat default-on phy0rx phy0tx phy0assoc phy0radio phy0tpt

Here phy* is referring to the wlan PHY.

However, this is only currently available in my kernel. I ran into problems getting this into mainline linux kernel. They have stopped accepting new ARM boards unless you do it with device tree. I'm waiting for device tree support for ARM to stabilize a bit, maybe Linux 3.1, then i want to work on making B3 boot with device tree.