Re: [RFC PATCH 3/9] memory: tegra: add flush operation for Tegra124 memory clients

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 2, 2015 at 5:54 PM, Vince Hsu <vinceh@xxxxxxxxxx> wrote:
>>>          {
>>>                  .id = 0x00,
>>>                  .name = "ptcr",
>>> @@ -959,7 +961,108 @@ static const struct tegra_smmu_swgroup
>>> tegra124_swgroups[] = {
>>>          { .swgroup = TEGRA_SWGROUP_VI,        .reg = 0x280 },
>>>   };
>>>
>>> +static struct tegra_mc_hotreset tegra124_mc_hotreset[] = {
>>> +       {TEGRA_SWGROUP_AFI,        0x200, 0x204,  0},
>>> +       {TEGRA_SWGROUP_AVPC,       0x200, 0x204,  1},
>>> +       {TEGRA_SWGROUP_DC,         0x200, 0x204,  2},
>>> +       {TEGRA_SWGROUP_DCB,        0x200, 0x204,  3},
>>> +       {TEGRA_SWGROUP_HC,         0x200, 0x204,  6},
>>> +       {TEGRA_SWGROUP_HDA,        0x200, 0x204,  7},
>>> +       {TEGRA_SWGROUP_ISP2,       0x200, 0x204,  8},
>>> +       {TEGRA_SWGROUP_MPCORE,     0x200, 0x204,  9},
>>> +       {TEGRA_SWGROUP_MPCORELP,   0x200, 0x204, 10},
>>> +       {TEGRA_SWGROUP_MSENC,      0x200, 0x204, 11},
>>> +       {TEGRA_SWGROUP_PPCS,       0x200, 0x204, 14},
>>> +       {TEGRA_SWGROUP_SATA,       0x200, 0x204, 15},
>>> +       {TEGRA_SWGROUP_VDE,        0x200, 0x204, 16},
>>> +       {TEGRA_SWGROUP_VI,         0x200, 0x204, 17},
>>> +       {TEGRA_SWGROUP_VIC,        0x200, 0x204, 18},
>>> +       {TEGRA_SWGROUP_XUSB_HOST,  0x200, 0x204, 19},
>>> +       {TEGRA_SWGROUP_XUSB_DEV,   0x200, 0x204, 20},
>>> +       {TEGRA_SWGROUP_TSEC,       0x200, 0x204, 22},
>>> +       {TEGRA_SWGROUP_SDMMC1A,    0x200, 0x204, 29},
>>> +       {TEGRA_SWGROUP_SDMMC2A,    0x200, 0x204, 30},
>>> +       {TEGRA_SWGROUP_SDMMC3A,    0x200, 0x204, 31},
>>> +       {TEGRA_SWGROUP_SDMMC4A,    0x970, 0x974,  0},
>>> +       {TEGRA_SWGROUP_ISP2B,      0x970, 0x974,  1},
>>> +       {TEGRA_SWGROUP_GPU,        0x970, 0x974,  2},
>>> +};
>>> +
>>>   #ifdef CONFIG_ARCH_TEGRA_124_SOC
>>> +
>>> +static bool tegra124_stable_hotreset_check(struct tegra_mc *mc,
>>> +               u32 reg, u32 *stat)
>>> +{
>>> +       int i;
>>> +       u32 cur_stat;
>>> +       u32 prv_stat;
>>> +
>>> +       /*
>>> +        * There might be a glitch seen with the status register if we
>>> program
>>> +        * the control register and then read the status register in a
>>> short
>>> +        * window due to a HW bug. So here we poll for a stable status
>>> read.
>>> +        */
>>> +       prv_stat = mc_readl(mc, reg);
>>> +       for (i = 0; i < 5; i++) {
>>
>> Why 5 times?
>
> This is a magic number from downstream. It should be enough to reach a
> stable state.

Most people don't like arbitrary numbers without any explanation. And
sentences like "should be enough" make me nervous. :) Could you try to
document this number so we at least know why *this* value instead of
one of the possible other values an integer can take?

>
>>> +               cur_stat = mc_readl(mc, reg);
>>> +               if (cur_stat != prv_stat)
>>> +                       return false;
>>> +       }
>>> +       *stat = cur_stat;
>>> +       return true;
>>> +}
>>> +
>>> +static int tegra124_mc_flush(struct tegra_mc *mc,
>>> +               const struct tegra_mc_hotreset *hotreset)
>>> +{
>>> +       u32 val;
>>> +
>>> +       if (!mc || !hotreset)
>>> +               return -EINVAL;
>>> +
>>> +       /* XXX add mutex */
>>
>> I guess this is a TODO for when this series exists the RFC state. :)
>
> Oh, yes.
>
>>> +
>>> +       val = mc_readl(mc, hotreset->ctrl);
>>> +       val |= BIT(hotreset->bit);
>>> +       mc_writel(mc, val, hotreset->ctrl);
>>> +       mc_readl(mc, hotreset->ctrl);
>>> +
>>> +       /* poll till the flush is done */
>>> +       do {
>>> +               udelay(10);
>>> +               val = 0;
>>> +               if (!tegra124_stable_hotreset_check(mc, hotreset->status,
>>> &val))
>>> +                       continue;
>>> +       } while (!(val & BIT(hotreset->bit)));
>>
>> So here you are waiting for the right bit in hotreset->status to turn
>> to 1. Why is the whole thing with tegra124_stable_hotreset_check()
>> needed? Could it switch from 1 to 0 to 1 again, with the first window
>> at 1 being invalid?
>
> There is a comment which describes why we have to check this in
> tegra124_stable_hotreset_check().
>
>> In that case isn't there a risk that
>> tegra124_stable_hotreset_check() might do 5 consecutive reads on that
>> invalid state and let us continue before the flush is completed?
>
> So there is another check in while(). :)

Yeah, I guess the issue is reduced to ensuring that 6 consecutive
identical reads are enough to guarantee that the value of this
register is stable.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux