2008-09-23 15:32:24     PPI Driver for BF54x. Can't run twice and data pins don't toggle.

Document created by Aaronwu Employee on Aug 7, 2013
Version 1Show Document
  • View in full screen mode

2008-09-23 15:32:24     PPI Driver for BF54x. Can't run twice and data pins don't toggle.

Isaac Leung (CANADA)

Message: 62581   

 

We need to have a PPI driver for our custom board using the BF547, so I'm making one up based on the "bfin_ppi.c" version that is already in there. I made some modifications for it to work on EPPI1.

 

I can boot uClinux, and I see "/dev/ppi1" there. During boot, I see it initialized and it would seem to have the right IRQ (which I think should be 44 for EPPI1)

 

 

 

I've made a little test program that opens it up, sets a bunch of config registers using ioctl(), writes out some stuff, then just closes it.

 

I'm running into a couple of problems:

 

- If I run my test program twice, it fails on the 2nd open. Kernel panic and says "Unable to attach Blackfin PPI Error Interrupt". This happens even if the test program does nothing but open/close. For the PPI error interrupt, I'm using  IRQ_EPP1_ERROR, which I assume is the correct value

 

- If I run my test program just once (with writing to the port), I seem to be able to get a pulse out of FrameSync1 and the PPI clock, but no toggle on any of the PPI data pins. (These pins are physically connected ok, when configured as GPIO, I can get the expected output on them).

 

 

 

I suspect it may be a related problem, that I'm not initializing the driver correctly? This is what I have for  the open and close functions (really just the same as the included bfin_ppi with minor edits). I'm no expert at debugging drivers, so any tips on how to start looking for the problem appreciated.

 

 

 

static int ppi_open(struct inode *inode, struct file *filp)

{

char intname[20];

int minor = MINOR(inode->i_rdev);

unsigned long flags;

 

pr_debug("Attempting ppi_open:\n");

printk("=> Inside ppi_open()\n");

 

if (minor != PPI1_MINOR)

  return -ENXIO;

 

spin_lock_irqsave(&eppi1_lock, flags);

 

if (ppiinfo.opened)

{

  spin_unlock_irqrestore(&eppi1_lock, flags);

  return -EMFILE;

}

 

/* Clear configuration information */

memset(&ppiinfo, 0, sizeof(ppi_device_t));

 

if (filp->f_flags & O_NONBLOCK)

  ppiinfo.nonblock = 1;

 

ppiinfo.rx_avail = &ppi_wq0;

 

ppiinfo.opened = 1;

ppiinfo.cont = 0;

 

strcpy(intname, PPI_INTNAME);

ppiinfo.irqnum = IRQ_EPPI1;

 

filp->private_data = &ppiinfo;

 

ppi_reg_reset(filp->private_data);

 

/* Request DMA channel, and pass the interrupt handler */

 

if (peripheral_request_list(per_req_ppi_data, PPI_DEVNAME)) {

  printk(KERN_ERR PPI_DEVNAME

  ": Requesting Peripherals failed\n");

  return -EBUSY;

}

 

if (request_dma(CH_EPPI1, "BF54x_PPI_DMA") < 0)

{

  panic("Unable to attach BlackFin PPI DMA channel\n");

  return -EFAULT;

}

else

{

  set_dma_callback(CH_EPPI1, (void *)ppi_irq, filp->private_data);

}

 

if (request_irq(IRQ_EPP1_ERROR, (void *)ppi_irq_error, IRQF_DISABLED, "PPI ERROR", NULL) < 0)

{

  panic("Unable to attach BlackFin PPI Error Interrupt\n");

  return -EFAULT;

}

 

spin_unlock_irqrestore(&eppi1_lock, flags);

 

pr_debug("ppi_open: return\n");

 

return 0;

}

 

 

static int ppi_release(struct inode *inode, struct file *filp)

{

ppi_device_t *pdev = filp->private_data;

unsigned long flags;

 

printk("=> Closing: ppi_release()\n");

pr_debug("ppi_release: close()\n");

 

spin_lock_irqsave(&eppi1_lock, flags);

 

/* After finish DMA, release it. */

free_dma(CH_EPPI1);

free_irq(IRQ_EPP1_ERROR, filp->private_data);

 

ppi_reg_reset(filp->private_data);

pdev->opened = 0;

spin_unlock_irqrestore(&eppi1_lock, flags);

 

peripheral_free_list(per_req_ppi_data);

peripheral_free_list(per_req_ppi_ctrl);

 

ppi_fasync(-1, filp, 0);

 

pr_debug("ppi_release: close() return\n");

return 0;

}

 

 

QuoteReplyEditDelete

 

 

2008-09-23 15:43:51     Re: PPI Driver for BF54x. Can't run twice and data pins don't toggle.

Mike Frysinger (UNITED STATES)

Message: 62583   

 

your request/free irq calls are not doing the same thing and so the irq never actually gets freed

Attachments

    Outcomes