[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: com(4) and LSI bug workaround
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
>> 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
> 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 ...
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.
Main Index |
Thread Index |