On Thu, Aug 29, 2013 at 5:33 PM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: [...] >>> >>> 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 :\ >> 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. >> 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. > >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
