On 14 March 2018 at 09:56, Mike Leach mike.leach@linaro.org wrote:
On 14 March 2018 at 15:51, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On 13 March 2018 at 17:22, Mike Leach mike.leach@linaro.org wrote:
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!
Perfect - that is something I've been meaning to look into. I was also wondering... Do non-programmable funnel and replicators need a clock to work or is this something that is implementation dependant? The datasheet doesn't say anything and I'm thinking that it could go both ways.
Mathieu
Clocks are needed - the non-programmable components are essentially the same with default values in the registers that you cannot see / program
Swell - thanks
. Mike.
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
-- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK
-- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK