On Thu, 30 Jul 2009 15:49:34 +0300 Eduardo Valentin <[email protected]> wrote:
> From: Peter Ujfalusi <[email protected]> > > It adds a new sysfs file, where the user can configure the mcbsp mode to use. > If the mcbsp channel is in use, it does not allow the change. > Than in omap_pcm_open we can call the omap_mcbsp_get_opmode to get the mode, > store it, than use it to implement the different modes. > ... > +/********************** McBSP DMA operating modes **************************/ > +#define MCBSP_DMA_MODE_ELEMENT 0 > +#define MCBSP_DMA_MODE_THRESHOLD 1 > +#define MCBSP_DMA_MODE_FRAME 2 ... > +static ssize_t dma_op_mode_show(struct device *dev, > + struct device_attribute *attr, char *buf) > +{ > + struct omap_mcbsp *mcbsp = dev_get_drvdata(dev); > + int dma_op_mode; > + > + spin_lock_irq(&mcbsp->lock); > + dma_op_mode = mcbsp->dma_op_mode; > + spin_unlock_irq(&mcbsp->lock); > + > + return sprintf(buf, "%d\n", dma_op_mode); It would be good to handle this as an ascii like e.g /sys/power/state does. "element", "threshold" or "frame". A number value doesn't tell much (for me when testing). > @@ -1195,12 +1266,14 @@ static int __devinit omap_mcbsp_probe (struct platform_device *pdev) > if (cpu_is_omap34xx()) { > mcbsp->max_tx_thres = max_thres(mcbsp); > mcbsp->max_rx_thres = max_thres(mcbsp); > + mcbsp->dma_op_mode = MCBSP_DMA_MODE_THRESHOLD; > if (omap_additional_add(pdev)) > dev_warn(&pdev->dev, > "Unable to create threshold controls\n"); > } else { > mcbsp->max_tx_thres = -EINVAL; > mcbsp->max_rx_thres = -EINVAL; > + mcbsp->dma_op_mode = MCBSP_DMA_MODE_ELEMENT; > } I would say the default mode for the omap34xx should be also element as it keeps the omap_pcm_pointer behavior the same than currently and avoids possible regression. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
