Hi Subhasish,
On Mon, Nov 29, 2010 at 19:12:52, Subhasish Ghosh wrote:
> >>
> >> +static struct clk pru_clk = {
> >> + .name = "pru_ck",
> >> + .parent = &pll0_sysclk2,
> >> + .lpsc = DA8XX_LPSC0_DMAX,
> >> + .flags = ALWAYS_ENABLED,
> >
> > Why it's always enabled?
> > [SG] - As per the L138 Datasheet, this falls under "Always On" domain.
Always ON is different from usage of ALWAYS_ENABLED here.
All the modules on OMAP-L138 are on Always ON domain; but
the clock to the module need not remain enabled always.
> >> +static struct resource omapl138_pru_suart_resources[] = {
> >> + {
> >> + .name = "omapl_pru_suart",
> >> + .start = OMAPL138_PRU_MEM_BASE,
> >> + .end = OMAPL138_PRU_MEM_BASE + 0xFFFF,
> >> + .flags = IORESOURCE_MEM,
> >> + },
> >> + {
> >> + .start = DAVINCI_DA8XX_MCASP0_REG_BASE,
> >> + .end = DAVINCI_DA8XX_MCASP0_REG_BASE + (SZ_1K * 12) - 1,
> >> + .flags = IORESOURCE_MEM,
> >> + },
> >> + {
> >> + .start = DA8XX_PSC0_BASE,
> >> + .end = DA8XX_PSC0_BASE + (SZ_1K * 3) - 1,
> >> + .flags = IORESOURCE_MEM,
> >> + },
> >> + {
> >> + .start = DA8XX_PSC1_BASE,
> >> + .end = DA8XX_PSC1_BASE + (SZ_1K * 3) - 1,
> >> + .flags = IORESOURCE_MEM,
> >
> > Why do you need PSCs?
> > [SG] - These are required by the PRU firmware to enable McASPs.
Why should the PRU firmware enable the PSCs? Why cant it be done
by the driver running on the ARM? As I understand the PRU instruction
space is quite limited.
> >
> >> + },
> >> + {
> >> + .start = DA8XX_SHARED_RAM_BASE,
> >> + .end = DA8XX_SHARED_RAM_BASE + (SZ_1K * 8) - 1,
> >> + .flags = IORESOURCE_MEM,
> >> + },
> >> + {
> >> + .start = OMAPL138_INT_PRU_SUART_1,
> >> + .end = OMAPL138_INT_PRU_SUART_1,
> >> + .flags = IORESOURCE_IRQ,
> >> + },
> >> + {
> >> + .start = OMAPL138_INT_PRU_SUART_2,
> >> + .end = OMAPL138_INT_PRU_SUART_2,
> >> + .flags = IORESOURCE_IRQ,
> >> + },
> >> + {
> >> + .start = OMAPL138_INT_PRU_SUART_3,
> >> + .end = OMAPL138_INT_PRU_SUART_3,
> >> + .flags = IORESOURCE_IRQ,
> >> + },
> >> + {
> >> + .start = OMAPL138_INT_PRU_SUART_4,
> >> + .end = OMAPL138_INT_PRU_SUART_4,
> >> + .flags = IORESOURCE_IRQ,
> >> + },
> >> + {
> >> + .start = OMAPL138_INT_PRU_SUART_5,
> >> + .end = OMAPL138_INT_PRU_SUART_5,
> >> + .flags = IORESOURCE_IRQ,
> >> + },
> >> + {
> >> + .start = OMAPL138_INT_PRU_SUART_6,
> >> + .end = OMAPL138_INT_PRU_SUART_6,
> >> + .flags = IORESOURCE_IRQ,
> >> + },
> >> + {
> >> + .start = OMAPL138_INT_PRU_SUART_7,
> >> + .end = OMAPL138_INT_PRU_SUART_7,
> >> + .flags = IORESOURCE_IRQ,
> >> + },
> >> + {
> >> + .start = OMAPL138_INT_PRU_SUART_8,
> >> + .end = OMAPL138_INT_PRU_SUART_8,
> >> + .flags = IORESOURCE_IRQ,
> >> + },
> >> +};
> >
> > What kind of device is this, with so many subdevices and IRQs?
> > [SG] -- We are emulating eight UARTs on the two PRUs available in OMAPL.
> > The interrupts are for each of the eight UARTs. For the application,
> > the visibility is a single controller emulating eight UARTs.
It will be good to see the driver using these resources. Ideally
the driver and the platform changes should be part of the same
patch series.
Thanks,
Sekhar
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
