Re: [Balloon] [patch 1/8] Balloon3 (http://balloonboard.org/…

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Wookey
Date:  
To: ARMlinux kernel, Balloon
CC: Daniel Ribeiro
Subject: Re: [Balloon] [patch 1/8] Balloon3 (http://balloonboard.org/) base machine support
On 2008-11-22 16:29 -0200, Daniel Ribeiro wrote:
> Em Sex, 2008-11-21 às 18:03 +0000, Wookey escreveu:
> > +static void balloon3_mask_irq(unsigned int irq)
> > +{
> > +    int balloon3_irq = (irq - BALLOON3_IRQ(0));
> > +    balloon3_irq_enabled &= ~(1 << balloon3_irq);
> > +    BALLOON3_INT_CONTROL_REG = ~balloon3_irq_enabled ;
> > +}
> > +
> > +static void balloon3_ack_irq(unsigned int irq)
> > +{
> > +    balloon3_mask_irq(irq);
> > +}
> > +
> > +static void balloon3_unmask_irq(unsigned int irq)
> > +{
> > +    int balloon3_irq = (irq - BALLOON3_IRQ(0));
> > +    balloon3_irq_enabled |= (1 << balloon3_irq);
> > +    BALLOON3_INT_CONTROL_REG = ~balloon3_irq_enabled ;
> > +}
> > +
> > +static struct irq_chip balloon3_irq_chip = {
> > +    .name        = "FPGA",
> > +    .ack        = balloon3_ack_irq,
> > +    .mask        = balloon3_mask_irq,
> > +    .unmask        = balloon3_unmask_irq,
> > +};

>
> If balloon3_ack_irq just calls ballon3_mask_irq, why dont you point .mask and .ack
> here to the same function?


Good point. That doesn;t make much sense as it stands.

> Also, are these really the same operation on your board? You disable the irq on ack.


To be honest I'm not sure. Nick, DB? I know we did have some trouble
getting the interrupts to work right, re leading/trailing edges (the
interrupt controller is in our VHDL so we get to get both ends wrong).
So maybe things got changed around to end up like this.

And there is definately something sub-standard in that everything
works but we always get a whinge on startup which appears to be caused
by the PCMCIA interrupt being in an 'unexpected state'.

> > +
> > +static void balloon3_backlight_power(int on)
> > +{
> > +#ifdef CONFIG_BALLOON3_TOPPOLY
> > +/* balloon 3 backlight control is on GPIO99, and it's already set up
> > + * as an output by bootldr in theory, but we set the pin as an output
> > + * just in case
> > + */
> > +    if (on) {
> > +        pr_info("%s: power is on\n", __func__);
> > +        pxa_gpio_mode(BALLOON3_GPIO_RUN_BACKLIGHT | GPIO_OUT);
> > +        GPSR(BALLOON3_GPIO_RUN_BACKLIGHT) =
> > +            GPIO_bit(BALLOON3_GPIO_RUN_BACKLIGHT);
> > +    } else {
> > +        pr_info("%s: power is off\n", __func__);
> > +        pxa_gpio_mode(BALLOON3_GPIO_RUN_BACKLIGHT | GPIO_OUT);
> > +        GPCR(BALLOON3_GPIO_RUN_BACKLIGHT) =
> > +            GPIO_bit(BALLOON3_GPIO_RUN_BACKLIGHT);
> > +    }
> > +#endif
> > +}

>
> Dont use pxa_gpio_mode, use pxa2xx_mfp_config.


OK. yes I saw those warnings. I'll go fix it.

> > +
> > +static void balloon3_udc_command(int cmd)
> > +{
> > +    switch (cmd) {
> > +    case PXA2XX_UDC_CMD_CONNECT:
> > +        UP2OCR |= (UP2OCR_DPPUE + UP2OCR_DPPUBE);
> > +        pr_debug("%s: connect\n", __func__);
> > +        break;
> > +    case PXA2XX_UDC_CMD_DISCONNECT:
> > +        UP2OCR &= ~UP2OCR_DPPUE;
> > +        pr_debug("%s: disconnect\n", __func__);
> > +        break;
> > +    }
> > +
> > +}

>
> I dont get this, are you using an external transceiver or not?


We are, but have never actually got it to work properly unfortunately.

> Is the D+ pull up used at all if you configure the usb port for single-ended operation?


Erm. I don't know. CC:ed to bb.org where the USB guru can comment.
Chris?

> > +
> > +static struct pxa2xx_udc_mach_info balloon3_udc_info = {
> > +    .udc_is_connected = balloon3_udc_is_connected,
> > +    .udc_command      = balloon3_udc_command,
> > +};
> > +
> > +
> > +static struct pxaficp_platform_data balloon3_ficp_platform_data = {
> > +    .transceiver_cap  = IR_SIRMODE | IR_FIRMODE | IR_OFF,
> > +};
> > +
> > +static struct platform_device *platform_devices[] __initdata = {
> > +    &balloon3_audio_device,
> > +    &pxa_device_i2c,
> > +};
> > +
> > +static int balloon3_ohci_init(struct device *dev)
> > +{
> > +    /* setup Port1 GPIO pin. */
> > +    pxa_gpio_mode(88 | GPIO_ALT_FN_1_IN);    /* USBHPWR1 */
> > +    pxa_gpio_mode(89 | GPIO_ALT_FN_2_OUT);    /* USBHPEN1 */
> > +
> > +    /* Set the Power Control Polarity Low and Power Sense
> > +     * Polarity Low to active low.
> > +     */
> > +    UHCHR = (UHCHR | UHCHR_PCPL | UHCHR_PSPL) &
> > +        ~(UHCHR_SSEP1 | UHCHR_SSEP2 | UHCHR_SSEP3 | UHCHR_SSE);
> > +
> > +    pr_debug("%s: Setting up transciever\n", __func__);
> > +    /* set USB Host port 2 to use external transceiver */
> > +    UP2OCR &= ~(7<<24);
> > +    UP2OCR |= (5<<24);

>
> Good, im not alone anymore using an external transceiver.


Does yours work? If so we'd love to compare notes. We have no probs
with host on port 1 and slave on port 2 but we could never get a peep
out of port 2 when configured as host with external transciever
(ISP1301). It would be good to know that it can actually be made to
work on pxa270 - then we might try again.

> But you should use UP2OCR_SEOS(5) here.
>
> > +    /* switch on power to USB host port 2 */
> > +    /* by setting GPIO100 low */
> > +    GPCR3 = GPIO_bit(100);

>
> use gpiolib for all your gpio toggles.


Thanx for the feedback. I'll go make some changes.

Wookey
--
Principal hats: Balloonz - Toby Churchill - Aleph One - Debian
http://wookware.org/