Nori, Sekhar wrote:
>
> 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.
>
> [SG] -- Should just removing the .flags be enough? I am using clk_get &
> clk_enable from the driver already.
>
>> >> +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.
>
> [SG] -- Correction, the PSC handling is done at the driver API layer.
>
>> >
>> >> + },
>> >> + {
>> >> + .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
>
>
--
View this message in context:
http://davinci-linux-open-source.1494791.n2.nabble.com/RFC-PATCH-1-1-da850-evm-Support-for-TI-s-PRU-SoftUART-Emulation-tp5783929p5787239.html
Sent from the davinci-linux-open-source mailing list archive at Nabble.com.
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
