On Fri, 03 Feb 2023, Biju Das wrote: > > Hi Lee Jones, > > Thanks for the feedback. > > > -----Original Message----- > > From: Lee Jones <lee@xxxxxxxxxx> > > Sent: Friday, February 3, 2023 8:01 AM > > To: Biju Das <biju.das.jz@xxxxxxxxxxxxxx> > > Cc: William Breathitt Gray <william.gray@xxxxxxxxxx>; linux- > > iio@xxxxxxxxxxxxxxx; Daniel Lezcano <daniel.lezcano@xxxxxxxxxx>; Thierry > > Reding <thierry.reding@xxxxxxxxx>; Uwe Kleine-König <u.kleine- > > koenig@xxxxxxxxxxxxxx>; Geert Uytterhoeven <geert+renesas@xxxxxxxxx>; Chris > > Paterson <Chris.Paterson2@xxxxxxxxxxx>; Prabhakar Mahadev Lad > > <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>; linux-renesas-soc@xxxxxxxxxxxxxxx > > Subject: Re: [PATCH v12 4/6] counter: Add Renesas RZ/G2L MTU3a counter > > driver > > > > On Thu, 02 Feb 2023, Biju Das wrote: > > > > > Add RZ/G2L MTU3a counter driver. This IP supports the following phase > > > counting modes on MTU1 and MTU2 channels > > > > > > 1) 16-bit phase counting modes on MTU1 and MTU2 channels. > > > 2) 32-bit phase counting mode by cascading MTU1 and MTU2 channels. > > > > > > This patch adds 3 counter value channels. > > > count0: 16-bit phase counter value channel on MTU1 > > > count1: 16-bit phase counter value channel on MTU2 > > > count2: 32-bit phase counter value channel by cascading > > > MTU1 and MTU2 channels. > > > > > > The external input phase clock pin for the counter value channels are > > > as follows: > > > count0: "MTCLKA-MTCLKB" > > > count1: "MTCLKA-MTCLKB" or "MTCLKC-MTCLKD" > > > count2: "MTCLKA-MTCLKB" or "MTCLKC-MTCLKD" > > > > > > Use the sysfs variable "external_input_phase_clock_select" to select > > > the external input phase clock pin and "cascade_counts_enable" to > > > enable/ disable cascading of channels. > > > > > > Signed-off-by: Biju Das <biju.das.jz@xxxxxxxxxxxxxx> > > > Reviewed-by: William Breathitt Gray <william.gray@xxxxxxxxxx> > > > > When we come to merge this, an Ack will be required. > > You mean an Ack from William Breathitt Gray and you can take it through > MFD (ie, core + counter patches together)?? > > or > > You will apply core driver and create an immutable branch, counter subsystem > can use that branch to avoid build issues while applying?? > > Please share your view on this. My assumption is that William provided his tag with a view to not merging this via his own repo. However, if there aren't any *build time* dependencies between the patches (i.e. shared header files, etc), then the preference would be for each commit to be merged through their own associated subsystem trees. However if there are build time deps, then it's common for the entire set to be merged in via the MFD tree. In the latter case a subsequent pull-request would then be provided for each of the other maintainers to pull from (if they so desire / need to). -- Lee Jones [李琼斯]
