Re: com(4) and LSI bug workaround

[KIYOHARA Takashi <kiyohara%kk.iij4u.or.jp@localhost>]

Hi!


From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
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