On Thu, Mar 26, 2015 at 02:31:30PM +0200, Peter Ujfalusi wrote:
> On 03/26/2015 12:56 PM, Vinod Koul wrote:
> >> +#define TI_XBAR_OUTPUTS 127
> >> +#define TI_XBAR_INPUTS256
> > Ideally this should be moved to DT. Will next revision of this chip always
> > support these output and inputs?
>
* Peter Ujfalusi [150326 05:32]:
> On 03/26/2015 12:56 PM, Vinod Koul wrote:
> >> +
> >> +static void ti_dma_xbar_free(struct device *dev, void *route_data)
> >> +{
> >> + struct ti_dma_xbar_data *xbar = dev_get_drvdata(dev);
> >> + struct ti_dma_xbar_map *map = route_data;
> >> +
> >> + dev_db
On 03/26/2015 12:56 PM, Vinod Koul wrote:
>> +#define TI_XBAR_OUTPUTS 127
>> +#define TI_XBAR_INPUTS 256
> Ideally this should be moved to DT. Will next revision of this chip always
> support these output and inputs?
They are coming from DT. I'm using these as fall back values in case we
On Wed, Mar 11, 2015 at 03:23:26PM +0200, Peter Ujfalusi wrote:
> The DRA7x has more peripherals with DMA requests than the sDMA can handle:
> 205 vs 127. All DMA requests are routed through the DMA crossbar, which can
> be configured to route selected incoming DMA requests to specific sDMA
> reque
The DRA7x has more peripherals with DMA requests than the sDMA can handle:
205 vs 127. All DMA requests are routed through the DMA crossbar, which can
be configured to route selected incoming DMA requests to specific sDMA
request.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/Kconfig |
5 matches
Mail list logo
