sb800 code derived from sb700 implementation

[She, Kerry]

Sorry to send again, forget the subject last email

I have made a little bit cleanup from the patches originally made by Bao Zheng,

This sb800 code is derived from sb700 implementation.

Release this patch is NOT to confusing people, but make other patches based on this implementation also works.

So this patch don’t need to be checked into the tree.

Regards, 
Kerry She < [e-mail]>
Tel:  [phone]

[Peter Stuge]

She, Kerry wrote:
> I have made a little bit cleanup from the patches originally made
> by Bao Zheng,
>
> This sb800 code is derived from sb700 implementation.
>
> Release this patch is NOT to confusing people, but make other
> patches based on this implementation also works.
>
> So this patch don’t need to be checked into the tree.

Thanks! I think this is a nice addition. Maybe we should add a
Kconfig option to choose between cimx and non-cimx?

//Peter

[Stefan Reinauer]

* Peter Stuge  [110104 12:21]:
> She, Kerry wrote:
> Thanks! I think this is a nice addition. Maybe we should add a
> Kconfig option to choose between cimx and non-cimx?

I think we should, once we actually hit a use case.

[Peter Stuge]

Stefan Reinauer wrote:
> > Maybe we should add a Kconfig option to choose between cimx and
> > non-cimx?
>
> I think we should, once we actually hit a use case.

Um? This is the case right here. I say add it now and get the patch
commited, then can remove in future if not used.

//Peter

[Stefan Reinauer]

* Peter Stuge  [110104 22:18]:
> Stefan Reinauer wrote:
> > > Maybe we should add a Kconfig option to choose between cimx and
> > > non-cimx?
> >
> > I think we should, once we actually hit a use case.
>
> Um? This is the case right here.

Oh? Which board? I thought the patch said "for reference only, not for
checkin". Sorry if I missed something.

Stefan

[Carl-Daniel Hailfinger]

Auf 04.01.2011 22:21, Stefan Reinauer schrieb:
> Peter Stuge  [110104 22:18]:
> > Stefan Reinauer wrote:
> > > > Maybe we should add a Kconfig option to choose between cimx and
> > > > non-cimx?
> > >
> > > I think we should, once we actually hit a use case.
> >
> > Um? This is the case right here.
>
> Oh? Which board? I thought the patch said "for reference only, not for
> checkin". Sorry if I missed something.

Still, having the code checked in is IMHO better than having it on the
list. If there are any CIMx integration issues later, we still have the
alternative code (and as a nice benefit, we can actually touch that code
whereas CIMx should be kept unchanged to allow easier updates).

Regards,
Carl-Daniel

[Stefan Reinauer]

* Carl-Daniel Hailfinger  [110105 00:05]:
> Still, having the code checked in is IMHO better than having it on the
> list. If there are any CIMx integration issues later, we still have the
> alternative code (and as a nice benefit, we can actually touch that code
> whereas CIMx should be kept unchanged to allow easier updates).

I would prefer to see CIMx integration issues fixed rather than worked
around with an in-tree fork for a non-existant user base that might
experience problems in the unforseeable future.

There is nothing that prevents us from reporting issues with the CIMx
code back to AMD to have it fixed.

Stefan