On Mon, Oct 25, 2010 at 04:52:45PM +0530, Pratyush Anand wrote: > > Does reading app_reg->slv_armisc register have any side effects? > > Is there any reason you can't cache this value and use the cached value > > with the '|' expression? > > I will modify it. Will use readl only once. If there are no side effects, read the register once at init() time, cache this value, update the cached value and write the new value back to the real register on every update. > > Why the udelay()? > > Is the writel() a posted or non-posted write? > > (ie does the CPU stall until the write completes or not?) > > If the CPU does not stall (writes are "posted"), then the udelay() is > > pointless and misleading. > > I am still investigating this issue. Write is posted. So wmb() would > have been correct option. > But it does not help. wmb() does not create any kind of delay. AFAIK, only readl() can force the first writel() to complete (unless the chipset has some special support.) So the sequence would be: writel() readl() udelay() writel() wmb() prevents stores to normal Host memory from getting reordered on systems with weakly ordered instructions or memory. writel() calls are by definition already strongly ordered and wmb() should have no effect on writel(). > > Why clear those bits in the slv_armisc register? > > > > If I do orring without clearing, then it might generate wrong values. "It"? What might generate wrong values? If the slv_armisc register can be cached, then the readl and writel here can be dropped. Just update the cached copy. I'm wondering if the cfg transaction is NOT sent out the PCIe wires until *after* these bits are cleared. That would definitely affect the cfg cycle type. ... > > Why do both pcie_rd_conf() and spear13xx_pcie_rd_conf() > > have to check the bus->number? > > pcie_rd_conf checks whether, request is for RC (lets say Bus 0) or > Downstream device (lets says bus1). > If it is DS device then , spear13xx_pcie_rd_conf() checks whether it > is for the first device below RC (cfg0) or > next in the tree(cfg1). Ok. But I'm still suspicious of the logic. I don't have time to review specs for this HW even if they were available. Just keep it in mind if PCIe protocol traces show the wrong type of transactions are generated on the downstream devices. grant -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
