RE: [PATCH v7 2/2] pwm: Add support for RZ/G2L GPT

[Biju Das <biju.das.jz@bp.renesas.com>]

Hi Thierry,

> 
> > > > +	mutex_init(&rzg2l_gpt->lock);
> > > > +
> > > > +	rzg2l_gpt->chip.dev = &pdev->dev;
> > > > +	rzg2l_gpt->chip.ops = &rzg2l_gpt_ops;
> > > > +	rzg2l_gpt->chip.npwm = 2;
> > >
> > > The changelog above mentions that you use a shared reset because
> the
> > > reset is shared between 8 channels, but here you only expose 2.
> > > What's going on there?
> >
> > Each hwchannel has 2 IOs. Each IO is modelled as separate channel.
> > Basically, we have 8 hwchannels * 2 IO's  = 16 pwm channels in
> total.
> >
> > Please correct me if anything wrong here.
> 
> I'm asking because I recently came across a similar driver but where
> the mistake was made to describe the hardware as 4 separate devices
> with 2 channels (or, depending on SoC generation, 1 channel) per
> device.
> Looking at the device tree it's pretty obvious that in that case this
> was really a single device with 8 (or 4, depending) channels. Most of
> the time this doesn't matter and everything works, but then on some HW
> generations all of a sudden you have a shared interrupt for all 8
> channels, and now this becomes really difficult to describe because
> the interrupt needs to be shared between 4 devices, or an extra layer
> is needed to slot in the interrupt somehow.
> 
> So I'm just trying to avoid another such situation. Looking at the DTS
> example from the binding in patch 1, you have gpt4 at 0x10048400 with
> 0x100 bytes. Does gpt3 sit at 0x10048300 with 0x100 bytes? If so, it's
> likely that this is really a single large IP block that you're
> artificially subdividing and that could turn into a similar issue as
> above.

OK, I have modelled as single PWM device with 16 channels
and test results are looks ok.

I will be sending next version soon.

Cheers,
Biju