On Thu, Aug 20, 2015 at 09:52:46AM -0500, Pledge Roy-R01356 wrote: > I guess my point isn't getting through - channel-id and cell-index are > too independent concepts that are coincidentally the same. Cell-index > is only used by u-boot and is used to determine the portal number. It > is absolutely possible that we produce and SoC where portal number 0 > has channel 0x1000. We've changed these things in the past as well - > this is why we introduced the channel-id property. This is also > consistent with other blocks (FMan, PME, DCE) that have channels > associated with them. > > The cell-index is useless - the portal ID can be derived from the > portal address. The fact that you're unwilling to remove cell-index > doesn't mean that channel-id is redundant and should be removed. I guess my point isn't getting through. Any concept that cell-index represented that was not identical to channel id is dead and gone, as is the concept of "portal number". Every time you see cell-index just pretend you are seeing fsl,qman-channel-id. cell-index is *not* defined as anything to do with the portal address. > > > The only thing cell-index indicates is the offset of the portal in the > > > QMan address space. > > > > cell-index has been redefined to not mean that at all. It now only means > > channel ID. We can do this because the value happens to be the same for all > > existing SoCs (and we should be sure to avoid putting things into the SDK for > > the aforementioned ARM chips that are contrary to the new definition). > > > > U-boot doesn't dictate the HW architecture and shouldn't - you're > trying very hard not to admit you changed something you didn't fully > understand and actually making the system harder to deal with. At no > point in time have we ever assumed portal ID would equal channel id. cell-index does not mean "portal ID". > With your logic u-boot is broken because it is using channel ID to > index into an array that is per portal not per channel. We shouldn't > have removed channel-id in the first place - trying to redefine that > portals = channels is just plain incorrect. That's not what happened. > I'm not sure how else to get through to you on this, your base > assumption is wrong. Likewise. -Scott -- 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