OK - I need to pay more attention to the CS specs - non-programmable funnels are indeed an arm option. Guess I've never been particularly interested in them before!
Mike
On 13 March 2018 at 23:15, Mike Leach mike.leach@linaro.org wrote:
Hi Mathieu, Kim
On 13 March 2018 at 20:20, Kim Phillips kim.phillips@arm.com wrote:
On Tue, 13 Mar 2018 11:03:57 -0600 Mathieu Poirier mathieu.poirier@linaro.org wrote:
On 13 March 2018 at 10:06, Kim Phillips kim.phillips@arm.com wrote:
On Tue, 13 Mar 2018 09:40:14 -0600 Mathieu Poirier mathieu.poirier@linaro.org wrote:
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:
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.
All a node needs to contain to get its driver probed is the compatible property. 'reg' is an optional property.
The initialisation code mandate that a valid address be given [1].
[1]. https://elixir.bootlin.com/linux/latest/source/drivers/of/platform.c#L260
I see, thanks. So that's for an AMBA device, and the current funnel driver is an AMBA driver. Makes sense, but the current replicator driver - that supports non-configurable replicators by not including the "arm,primecell" compatible string - is a platform driver. Isn't it similarly possible to make the funnel driver a platform driver and match solely on the existing "arm,coresight-funnel" compatible? Only in the case of configurable funnels would it also manually register with the AMBA subsytem.
There are a pair of separate drivers for the replicators, one platform for non-programmable, one AMBA for dynamic (i.e. programmable).
Kim _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
I'd be inclined to keep coresight-replicator for the non-programmable version, and perhaps in the same sense that we have a coresight-dynamic-replicator for the programmable version, introduce a new name such as coresight-auto-funnel / coresight-concentrator for this non-programmable variant.
I'd still use the same non-prog platform driver code as you suggest - and change the driver source file name if you like, but reduce the amount of DT churn by avoiding a new name for an existing component.
As to the "arm," prefix on all this - we need to double check that this is an actual arm variant - otherwise it will need to have the actual designer prefix instead. Haven't come across this variant before so need to check it is actually arm specified before claiming it as such.
Regards
Mike
-- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK