On Thu, Aug 29, 2013 at 5:33 PM, Kevin Hilman [off-list ref] wrote:
[...]

quoted

quoted

Maybe I'm getting confused, but the more you talk about the linux and
the firmware doing the same code, the more I think the firmware is
(trying) to do too much.  If this is going to be understandable (and
maintainable), there needs to be a clean split of roles between the MPU
and the M3.

In the past i tried to keep the firmware as minimal as possible and pushed
back all efforts to push unnecessary stuff in there. Like Kevin, i too was of
the opinion that we need to do whatever's possible in the kernel.

Sadly, things just got a point where it made much more sense (technically
as well as non-technically) to just put the low level stuff in the M3.

1. In addition to the Linux support, we have non-OS based code for AM335x
(and AM437x) which in the past just had to duplicate whatever was done
in the Linux. Being a different codebase the non-OS guys have their own
set of challenges and we had to at times sit through and debug issues in
one codebase while the other was working fine. Ideally these things should
never come up but sadly they do and we need to solve them.

We also have people trying to implement this thing on different sort of
OS environments and they also end up debugging the same set of issues.

With only a handful of folks able to spend time debugging issues 'do everything
in Linux and expect others to copy it' model doesn't scale up. Keeping
things in the
firmware with the code available online helps do away with the
'developer scalability'
problem and if one looks at things differently enables code-reuse at
the same time.

Yes, yes, this is the classic argument for a HAL, and making that case has always
gone over well in the kernel. ;)

If the carefully crafted C code with a bit of linker magic thrown in
works, that's great
but for anyone without the generic Linux code in general and the Linux community
to go to with queries will have a tough time getting it done. TI
non-OS code has been
implemented from scratch and one of the purposes is to keep things as simple
as possible for folks. I know it's all non-technical stuff and most
likely i am a bit
biased but just a different POV from someone who spent hours debugging
'this works
and that doesn't' kind of issues. Trying to wrap your head around
random s/w stacks
and figuring out what needs to be changed is not pretty IMHO :\

quoted

Moreover, when the code was finally moved to M3, AFAICT we had validated
all supported combinations (DDR2, DDR3, DDR3 with VTT, DDR3 without VTT
control) that TI hardware guys could throw at us.Yes there could be stupid bugs
lurking in the code since it wasn't reviewed as much as i would have
liked but we
have something which proves the functionality to be used as the base.

I don't follow the argument here.  You mean it was validated *before*
moving it to the M3, or after?  Either way, I'm how that makes a case
for moving it to the M3.  Surely if it was on the MPU, it would also
have been validated, no?

At least i did all the validation without the VDD_CORE changes. The point i was
trying to make is that we are not trying to hide bugs in there, if
that's one of the
concerns. Just trying to make it simple (subjective, i know) for others to use.

quoted

2. As has been already been pointed out by Russ, on AM335x this step needs
to be done very late in the suspend process (the last stage
actually).

late, yes.  But *technically*, it can still be done from the MPU.

quoted

On the next SoC there are other complications related to security
which enforce this step must be done from the M3.

Aha!  So far, the first technical reason I've seen.  Can you elaborate?
Exactly which step has to be done from the M3, and why can't the MPU do
it?  And could it be done more simply by putting *only* the parts needed
on the M3 and not letting it snowball into a pile of stuff?

Sent out another mail for this.

Regards,
Vaibhav