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
