On 09/03/2020 23:50, Stephen Boyd wrote: > Quoting Enric Balletbo Serra (2020-03-06 14:09:50) >> Missatge de Stephen Boyd <sboyd@xxxxxxxxxx> del dia dv., 6 de mar >> 2020 a les 22:37: >>> >>> Quoting Enric Balletbo i Serra (2020-03-06 08:30:16) >>>> On 5/3/20 22:01, Stephen Boyd wrote: >>>>> Quoting Enric Balletbo i Serra (2020-03-02 03:01:26) >>>>>> diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c >>>>>> new file mode 100644 >>>>>> index 000000000000..473cdf732fb5 >>>>>> --- /dev/null >>>>>> +++ b/drivers/soc/mediatek/mtk-mmsys.c >>>>>> @@ -0,0 +1,154 @@ >>>>>> +// SPDX-License-Identifier: GPL-2.0-only >>>>>> +/* >>>>>> + * Copyright (c) 2014 MediaTek Inc. >>>>>> + * Author: James Liao <jamesjj.liao@xxxxxxxxxxxx> >>>>>> + */ >>>>>> + >>>>>> +#include <linux/clk-provider.h> >>>>>> +#include <linux/of_device.h> >>>>>> +#include <linux/platform_device.h> >>>>>> + >>>>>> +#include "../../clk/mediatek/clk-gate.h" >>>>>> +#include "../../clk/mediatek/clk-mtk.h" >>>>> >>>>> Why not use include/linux/clk/? >>>>> >>>> >>>> I can move these files to include, this will impact a lot more of drivers but, >>>> yes, I think is the right way. >>>> >>>>> But I also don't understand why the clk driver is moved outside of >>>>> drivers/clk/ into drivers/soc/. Commit text saying that it has shared >>>>> registers doesn't mean it can't still keep the clk driver part in the >>>>> drivers/clk/ area. >>>>> >>>> >>>> Actually moving this to the soc directory has been requested by CK (mediatek) as >>>> a change in v8. You can see the discussion in [1] >>>> >>> >>> I can reply there in that thread if necessary, but we shouldn't need to >>> force simple-mfd into DT bindings to support this. Match the compatible >>> string in drivers/soc/ and register devices in software for the >>> different pieces of this overall hardware block. If necessary, pass down >>> the ioremapped addresss down through device data to each logical driver >>> in the respective subsystem. >>> >>> So yes, it looks like an MFD, but that doesn't mean we have to change >>> the DT binding or put it in drivers/mfd to support that. And we don't >>> have to fix any problems with allowing two drivers to probe the same >>> compatible string. >>> >> >> That thread maybe has too much information and things evolved since >> then. Note that the final solution is not an MFD neither we change the >> bindings. I pointed to that thread just because CK (CK please correct >> me if I'm wrong) thought that the driver is not a pure clock driver >> and he preferred to move to drivers/soc/mediatek (in that thread, he >> exposes his opinion on that). Sorry to introduce more confusion. >> >> You seem to be fine with the approach (just minor changes), so it >> looks to me that the only problem is if this should be in drivers/clk >> or drivers/soc. Honestly, this is not something I can't decide and >> I'll let you (the soc and clk maintainers) decide. I don't really have >> a strong opinion here. I don't mind move again to drivers/clk if that >> is what we want but let's come to an agreement. >> > > It's already in drivers/clk, so leave the clk part there and register > the clk device and any other devices by matching the compatible in > drivers/soc. That is my preferred solution. Can that be done? > I think we can once again create a platform device in drivers/soc which matches the drivers/clk and then do the routing in drivers/soc. Enric any thoughts?
