On 12 March 2018 at 13:02, Kim Phillips kim.phillips@arm.com wrote:
On Mon, 12 Mar 2018 11:28:33 -0600 Mathieu Poirier mathieu.poirier@linaro.org wrote:
Good day to all,
The CS specification defines replicators that are not showing on the AMBA bus and can't be configured - they simply provide a hard wire between components. Earlier this week someone wrote to me on the open mailing list asking for guidance in dealing with a new type of funnel their company has introduced in a design. Just like a replicator it doesn't show up on the AMBA bus and can't be configured.
It makes sense to deal with this new component the same way we do with the above-mentioned replicator, i.e use a platform driver that does nothing and add it to the CS topology when specified in the device tree. It also make sense to re-use the same code [1] for that.
But moving forward with this also means we need to re-brand the current coresight-replicator.c file, along with adding new "compatible" strings. Here is what I suggest:
- Keep the "arm,coresight-replicator" compatible string for backward
compatibility (I'm seriously tempted not to [2]). 2) Add a new "arm,coresight-hw-replicator" compatible string for replicators that don't show up on the AMBA bus. 3) Add a new "arm,coresight-hw-funnel" compatible string for funnels that don't show up on the AMBA bus. 4) Use a match table to deal with the above two new compatible string and the old one (if we keep it around). 5) Rename coresight-replicator.c to coresight-hw-link.c.
I'm reaching out to the list because once we have a naming convention it is hard to modify it. Let me know what you think of the above.
Thanks, Mathieu
[1]. https://elixir.bootlin.com/linux/latest/source/drivers/hwtracing/coresight/c... [2]. We could also delete the old "arm,coresight-replicator" and make the changes in the DT for current users. People that haven't upstream their in-house solution will have to adapt, but that's something that happens with all the out-of-tree code.
I'd rather not introduce incompatibility when it's strictly not necessary.
Is it possible to keep everything equal (no new compatibles or other changes), and have functions like funnel_enable_hw, funnel_disable_hw do something like this instead?:
if (!drvdata->base) return;
Not that I'm aware of - a funnel device won't get probed if it doesn't have a valid 'reg' property to poke at.
Alternately, the devm_ioremap_resource() callsite in funnel_probe() could check for the specific error that represents no reg property found, assume it's a 'dummy funnel', and just continue (and not error out), but not register any link_ops.
Kim