答复: coherent_ht_mainboard()

[YhLu]

The dynamic code does not work on 4 way MB, I have found out why the s4882
can not soft_reset.

The HT-link between is not properly init properly.

If the dynamic code can init the coherent-ht properly, We can remove
hypertransport.c

Regards

YH

-----邮件原件-----
发件人: Stefan Reinauer [mailto:[e-mail]] 
发送时间: 2004年3月24日 8:41
收件人: YhLu
抄送: [e-mail]
主题: coherent_ht_mainboard()

Yinghai,

tyan/*/hypertransport.c contain some fixed hypertransport register 
values poked into the AMD K8 northbridge. This code was earlier called
by coherent_ht.c:setup_coherent_ht_domain() but I removed the call some
time ago, since I could not see why it is still needed. Does this code
provide any crucial functionality that can't be realized in the dynamic
code of the current CVS tree?

If not, I suggest we drop this code.

The same thing could btw work for the different versions of
resourcemap.c. The biggest reason for the split off here was that the
default resource map did always assume the AMD8111 southbridge on link0
which is not always true. This is fixed by now. 
The bus numbers should meanwhile be entered correctly by the generic
code.
So, we could reduce the amount of involved code a lot, flattening out
all the nasty exceptions we invented to bend the rules..

Stefan

????: coherent_ht_mainboard()

[Stefan Reinauer]

* YhLu  [040324 18:39]:
> The dynamic code does not work on 4 way MB, I have found out why the s4882
> can not soft_reset.
>
> The HT-link between is not properly init properly.

Which link is this? CPU0->AMD8111?
I seemed to have no problems on quartet with 1.1.5, which is 4 way as
well.
Have you been able to track the problem down to a certain function/flaw?
> If the dynamic code can init the coherent-ht properly, We can remove
> hypertransport.c

good.

Stefan

YhLu  writes:
> The dynamic code does not work on 4 way MB, I have found out why the s4882
> can not soft_reset.
>
> The HT-link between is not properly init properly.
>
> If the dynamic code can init the coherent-ht properly, We can remove
> hypertransport.c

hypertransport.c can become a noop I agree but there are systems like:
http://www.970eval.com/ where we will need it for the ppc.  And there
may be other even more interesting cases.

So I continue to see hypertansport.c as normative.  The rest of the
places as just optimizations.  Though I am completely in favor of
increasing the code sharing between hypertransport.c and
incoherent_ht.c

Eric

????: coherent_ht_mainboard()

[Stefan Reinauer]

* Eric W. Biederman  [040324 19:48]:
> hypertransport.c can become a noop I agree but there are systems like:
> http://www.970eval.com/ where we will need it for the ppc.  And there
> may be other even more interesting cases.
>
> So I continue to see hypertansport.c as normative.  The rest of the
> places as just optimizations.  Though I am completely in favor of
> increasing the code sharing between hypertransport.c and
> incoherent_ht.c

I think you mean coherent_ht.c and incoherent_ht.c? hypertransport.c is
only available for tyan boards and contains the hardcodes for link setup
on those tyan boards. coherent_ht.c and incoherent_ht.c are both needed
and more than unlikely to go away, i agree.
Correct me if I misunderstood.

Stefan

????: coherent_ht_mainboard()

Stefan Reinauer  writes:
> Eric W. Biederman  [040324 19:48]:
> > hypertransport.c can become a noop I agree but there are systems like:
> > http://www.970eval.com/ where we will need it for the ppc.  And there
> > may be other even more interesting cases.
> >
> > So I continue to see hypertansport.c as normative.  The rest of the
> > places as just optimizations.  Though I am completely in favor of
> > increasing the code sharing between hypertransport.c and
> > incoherent_ht.c
>
> I think you mean coherent_ht.c and incoherent_ht.c?

I mean devices/hypertransport.c and northbridge/amd/amdk8/incoherent_ht.c
> hypertransport.c is
> only available for tyan boards and contains the hardcodes for link setup
> on those tyan boards.

mainbaord/tyan/*/hypertansport.c can go away yes.  Which may
have been the original suggestion.

devices/hypertransport.c remain and is normative.  
If incoherent_ht.c messes or is not general enough it catches
it.
> coherent_ht.c and incoherent_ht.c are both needed
> and more than unlikely to go away, i agree.
> Correct me if I misunderstood.

Hopefully I have.  Too many pieces not enough names :)

Eric