Messages in this thread | | | Subject | Re: [PATCH v2 2/2] reset: Reset controller driver for Intel LGM SoC | From | Dilip Kota <> | Date | Mon, 14 Oct 2019 17:41:00 +0800 |
| |
Hi Philipp,
On 10/8/2019 11:56 PM, Philipp Zabel wrote: > Hi Martin, > > On Mon, 2019-10-07 at 21:53 +0200, Martin Blumenstingl wrote: >> Hi Philipp, >> >> On Thu, Oct 3, 2019 at 4:19 PM Philipp Zabel <pza@pengutronix.de> wrote: >> [...] >>>> because the register layout was greatly simplified for the newer SoCs >>>> (for which there is reset-intel) compared to the older ones >>>> (reset-lantiq). >>>> Dilip's suggestion (in my own words) is that you take his new >>>> reset-intel driver, then we will work on porting reset-lantiq over to >>>> that so in the end we can drop the reset-lantiq driver. >>> Just to be sure, you are suggesting to add support for the current >>> lantiq,reset binding to the reset-intel driver at a later point? I >>> see no reason not to do that, but I'm also not quite sure what the >>> benefit will be over just keeping reset-lantiq as is? >> according to Chuan and Dilip the current reset-lantiq implementation >> is wrong [0]. > The only issue seems to be the .reset callback, which doesn't have any > users anway. The DT binding of reset-lantiq driver is also having issue. I have explained here [1]. > >> my understanding is that the Lantiq and Intel LGM reset controllers >> are identical except: >> - the Lantiq variant uses a weird register layout (reset and status >> registers not at consecutive offsets) >> - the bits of the reset and status registers sometimes don't match on >> the Lantiq variant > Thank you, so these are a good explanation for why the DT bindings > should be different. > >> - the Intel variant has a dedicated registers area for the reset >> controller registers, while the Lantiq variant mixes them with various >> other functionality (for example: USB2 PHYs) > I'm not quite sure I understand why the intel driver is using syscon, > then. Either way, it shouldn't make a big difference if regmap is used > anyway. Yes, we decided to remove the syscon and use the regmap.[2] > >>>> This approach means more work for me (as I am probably the one who >>>> then has to do the work to port reset-lantiq over to reset-intel). >>> More work than what alternative? >> compared to "fixing" the existing reset-lantiq driver (reset callback) > That is still something you could do, or just drop the .reset callback > because there are no reset consumers using it anyway. > > One correct thing to do would be to identify those self-clearing reset > bits and to disallow calling assert/deassert on them. > >> and then (instead of adding a new driver) integrating Intel LGM >> support into reset-lantiq > Since at this point I'm not even sure whether merging the two at all is > better than keeping them separate, I have no opinion on whether merging > intel support into the lantiq driver or the other way around is > preferable. > >>>> I'm happy to do that work if you think that it's worth following this >>>> approach. So I want your opinion on this before I spend any effort on >>>> porting reset-lantiq over to reset-intel. >>> Reset drivers are typically so simple, I'm not quite sure whether it is >>> worth to integrate multiple drivers if it complicates matters too much. >>> In this case though I expect it would just be adding support for a >>> custom .of_xlate and lantiq specific register property parsing? >> yes, that's how I understand the Lantiq and Intel reset controllers: >> - reset/status/assert/deassert callbacks would be shared across all variants >> - register parsing and of_xlate are SoC specific > Ok. If that turns out to be less rather than more boilerplate than two > separate drivers, that should be fine.
Thanks Philipp for your time and briefly explaining your view.
Regards, Dilip
[1]: https://www.spinics.net/lists/devicetree/msg308930.html [2]: https://lkml.org/lkml/2019/9/2/289
> regards > Philipp
| |