Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 9 Dec 2022 15:09:08 +0100 Maciek Machnikowski wrote:
> On 12/9/2022 12:07 PM, Jiri Pirko wrote:
> > Looking at the documentation of the chips, they all have mupltiple DPLLs
> > on a die. Arkadiusz, in your proposed implementation, do you model each
> > DPLL separatelly? If yes, then I understand the urgency of need of a
> > shared pin. So all DPLLs sharing the pin are part of the same chip?
> > 
> > Question: can we have an entity, that would be 1:1 mapped to the actual
> > device/chip here? Let's call is "a synchronizer". It would contain
> > multiple DPLLs, user-facing-sources(input_connector),
> > user-facing-outputs(output_connector), i/o pins.
> > 
> > An example:
> >                                SYNCHRONIZER
> > 
> >                               ┌───────────────────────────────────────┐
> >                               │                                       │
> >                               │                                       │
> >   SyncE in connector          │              ┌─────────┐              │     SyncE out connector
> >                 ┌───┐         │in pin 1      │DPLL_1   │     out pin 1│    ┌───┐
> >                 │   ├─────────┼──────────────┤         ├──────────────┼────┤   │
> >                 │   │         │              │         │              │    │   │
> >                 └───┘         │              │         │              │    └───┘
> >                               │              │         │              │
> >                               │           ┌──┤         │              │
> >    GNSS in connector          │           │  └─────────┘              │
> >                 ┌───┐         │in pin 2   │                  out pin 2│     EXT SMA connector
> >                 │   ├─────────┼───────────┘                           │    ┌───┐
> >                 │   │         │                           ┌───────────┼────┤   │
> >                 └───┘         │                           │           │    │   │
> >                               │                           │           │    └───┘
> >                               │                           │           │
> >    EXT SMA connector          │                           │           │
> >                 ┌───┐   mux   │in pin 3      ┌─────────┐  │           │
> >                 │   ├────┬────┼───────────┐  │         │  │           │
> >                 │   │    │    │           │  │DPLL_2   │  │           │
> >                 └───┘    │    │           │  │         │  │           │
> >                          │    │           └──┤         ├──┘           │
> >                          │    │              │         │              │
> >    EXT SMA connector     │    │              │         │              │
> >                 ┌───┐    │    │              │         │              │
> >                 │   ├────┘    │              └─────────┘              │
> >                 │   │         │                                       │
> >                 └───┘         └───────────────────────────────────────┘
> > 
> > Do I get that remotelly correct?  
> 
> It looks goot, hence two corrections are needed:
> - all inputs can go to all DPLLs, and a single source can drive more
>   than one DPLL
> - The external mux for SMA connector should not be a part of the
>   Synchronizer subsystem - I believe there's already a separate MUX
>   subsystem in the kernel and all external connections should be handled
>   by a devtree or a similar concept.
> 
> The only "muxing" thing that could potentially be modeled is a
> synchronizer output to synchronizer input relation. Some synchronizers
> does that internally and can use the output of one DPLL as a source for
> another.

My experience with DT and muxes is rapidly aging, have you worked with
those recently? From what I remember the muxes were really.. "embedded"
and static compared to what we want here.

Using DT may work nicely for defining the topology, but for config we
still need a different mechanism.

> > synch
> > synchronizer_register(synch)
> >    dpll_1
> >    synchronizer_dpll_register(synch, dpll_1)
> >    dpll_2
> >    synchronizer_dpll_register(synch, dpll_2)
> >    source_pin_1
> >    synchronizer_pin_register(synch, source_pin_1)
> >    output_pin_1
> >    synchronizer_pin_register(synch, output_pin_1)
> >    output_pin_2
> >    synchronizer_pin_register(synch, output_pin_2)
> > 
> > synch_board
> >    synchronizer_board_register(synch_board)
> >    synch
> >    synchronizer_board_sync_register(synch_board, synch)
> >    source_connector_1
> >    synchronizer_board_connector_register(synch_board, source_connector_1, source_pin_1)
> >    output_connector_1
> >    synchronizer_board_connector_register(synch_board, output_connector_1, output_pin_1)
> >    output_connector_2
> >    synchronizer_board_connector_register(synch_board, output_connector_2, output_pin_2)  
> 
> I'd rather not use pins at all - just stick to sources and outputs. Both
> can use some labels to be identifiable.

TBH I can't comprehend your suggestion.
IIUC you want an object for a source, but my brain can't handle
modeling an external object. For instance the source could be GNSS, 
but this is not the GNSS subsystem. We have a pin connected to GNSS,
not the GNSS itself. 
Maybe a diagram would help?