Hi!
From: Izumi Tsutsui <[email protected]> Date: Wed, 2 Oct 2013 22:29:52 +0900 >> > First of all, your guess has no evidence and actually it seems incorrect. >> > >> > There are some articles that indicate it's a documented future: >> > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/203948 >> >> Yes. >> Although that those are not the things for 16750 understood me, I did >> not know that it was IP of Synopsys DesignWare. And although his mail >> does not have a corroboration which is a fact, either, probably it is >> right. > > Then can you revert your changes? Is it better to revirt right now? >> > Isn't it much simpler and explicit to call such a MD workaround >> > function directly from comintr() and wrap those blocks with >> > #if COM_XXXMDname > 0 / #endif with "needs-flag" declaration >> > in the config(9) file? >> >> I think that I should check not by "needs-flag" but by COM_TYPE_XXXX. >> Since ARMADAXP has some PCIe, com should be able to be attached there. > > What makes you think the com at PCIe will also have the same quirk? > > If the quirks is not chip specific, the workaround function should > also be in the MI com.c, then no need to wrap them with #ifdef. > >> COM_TYPE_APBUART or COM_TYPE_SNPS or ... ? > > In ARMADAXP case I don't see any reason to put #ifdef at all. > > If IIR_BUSY is returned we should always check the USR register. > It's no worth to have a separate mvuart_armadaxp_workaround() function > you suggested. Please let me confirm. Is it wrong although I understood that you desired "#ifdef ARMADAXP ... #endif"? I desire a method of setting COM_TYPE_XXXX to sc_type like OMAP and PXA2x0. it is like COM_TYPE_APBUART. # It may be better for the name of sinopsys to enter. COM_TYPE_SNPS? And actual processing will move to com.c. This is because it is not dependent on ARMADAXP. This understands that you also agree. Thanks, -- kiyohara
