tech-kern archive

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

Re: com(4) and LSI bug workaround


From: Izumi Tsutsui <>
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:
>> >
>> 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.
> 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 ...
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.


Home | Main Index | Thread Index | Old Index