| Message ID | 20170921164940.20343-4-georgi.djakov@linaro.org (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Headers | show |
On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > Move the structure shared by the APCS IPC device and its subdevices > into a separate header file. > As you're creating the apcs regmap with devm_regmap_init_mmio() you can just call dev_get_regmap(dev->parent) in your child to get the handle. But I would prefer that you just add the clock code to the existing driver. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Bjorn, Thanks for reviewing! On 10/26/2017 07:28 AM, Bjorn Andersson wrote: > On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > >> Move the structure shared by the APCS IPC device and its subdevices >> into a separate header file. >> > > As you're creating the apcs regmap with devm_regmap_init_mmio() you can > just call dev_get_regmap(dev->parent) in your child to get the handle. Ok, thanks! > > But I would prefer that you just add the clock code to the existing > driver. This will require an ack from Stephen, and i got the impression that he prefers a separate clk driver [1]. Stephen, are you ok with registering the clocks from the apcs mailbox driver? [1] https://lkml.org/lkml/2017/6/26/750 -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/27, Georgi Djakov wrote: > Hi Bjorn, > > Thanks for reviewing! > > On 10/26/2017 07:28 AM, Bjorn Andersson wrote: > > On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > > > >> Move the structure shared by the APCS IPC device and its subdevices > >> into a separate header file. > >> > > > > As you're creating the apcs regmap with devm_regmap_init_mmio() you can > > just call dev_get_regmap(dev->parent) in your child to get the handle. > > Ok, thanks! > > > > > But I would prefer that you just add the clock code to the existing > > driver. > > This will require an ack from Stephen, and i got the impression that he > prefers a separate clk driver [1]. > > Stephen, are you ok with registering the clocks from the apcs mailbox > driver? > > [1] https://lkml.org/lkml/2017/6/26/750 The parent regmap "trick" was the plan. Is something wrong with that? Not having random clk drivers scattered throughout the tree is sort of nice because it makes for an easier time finding things that are similar. Maybe that's an abuse of the driver model though? Just to get things into some same directory. I'm fine either way.
On Mon 13 Nov 18:12 PST 2017, Stephen Boyd wrote: > On 10/27, Georgi Djakov wrote: > > Hi Bjorn, > > > > Thanks for reviewing! > > > > On 10/26/2017 07:28 AM, Bjorn Andersson wrote: > > > On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > > > > > >> Move the structure shared by the APCS IPC device and its subdevices > > >> into a separate header file. > > >> > > > > > > As you're creating the apcs regmap with devm_regmap_init_mmio() you can > > > just call dev_get_regmap(dev->parent) in your child to get the handle. > > > > Ok, thanks! > > > > > > > > But I would prefer that you just add the clock code to the existing > > > driver. > > > > This will require an ack from Stephen, and i got the impression that he > > prefers a separate clk driver [1]. > > > > Stephen, are you ok with registering the clocks from the apcs mailbox > > driver? > > > > [1] https://lkml.org/lkml/2017/6/26/750 > > The parent regmap "trick" was the plan. Is something wrong with > that? > Not at all, but then this patch (moving apcs context to a shared header file) shouldn't be needed, or am I missing something? > Not having random clk drivers scattered throughout the tree is > sort of nice because it makes for an easier time finding things > that are similar. Maybe that's an abuse of the driver model > though? Just to get things into some same directory. I'm fine > either way. > Keeping the clock driver in the clock subsystem does make sense. I see now that there is a include of a local header file as well, so that would just be messy to keep split. I'm fine with the extra driver instance, it's the DT that I don't think should describe the fact that we want to keep the clock-part in the clock subsystem. Do you see any problems spawning the clock driver programmatically and then calling of_clk_add_hw_provider() on the parent's of_node? Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/13, Bjorn Andersson wrote: > On Mon 13 Nov 18:12 PST 2017, Stephen Boyd wrote: > > > On 10/27, Georgi Djakov wrote: > > > Hi Bjorn, > > > > > > Thanks for reviewing! > > > > > > On 10/26/2017 07:28 AM, Bjorn Andersson wrote: > > > > On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > > > > > > > >> Move the structure shared by the APCS IPC device and its subdevices > > > >> into a separate header file. > > > >> > > > > > > > > As you're creating the apcs regmap with devm_regmap_init_mmio() you can > > > > just call dev_get_regmap(dev->parent) in your child to get the handle. > > > > > > Ok, thanks! > > > > > > > > > > > But I would prefer that you just add the clock code to the existing > > > > driver. > > > > > > This will require an ack from Stephen, and i got the impression that he > > > prefers a separate clk driver [1]. > > > > > > Stephen, are you ok with registering the clocks from the apcs mailbox > > > driver? > > > > > > [1] https://lkml.org/lkml/2017/6/26/750 > > > > The parent regmap "trick" was the plan. Is something wrong with > > that? > > > > Not at all, but then this patch (moving apcs context to a shared header > file) shouldn't be needed, or am I missing something? Agreed. > > > Not having random clk drivers scattered throughout the tree is > > sort of nice because it makes for an easier time finding things > > that are similar. Maybe that's an abuse of the driver model > > though? Just to get things into some same directory. I'm fine > > either way. > > > > Keeping the clock driver in the clock subsystem does make sense. I see > now that there is a include of a local header file as well, so that > would just be messy to keep split. > > I'm fine with the extra driver instance, it's the DT that I don't think > should describe the fact that we want to keep the clock-part in the > clock subsystem. > > Do you see any problems spawning the clock driver programmatically and > then calling of_clk_add_hw_provider() on the parent's of_node? Nope. We shouldn't need to modify DT to make this work.
diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c b/drivers/mailbox/qcom-apcs-ipc-mailbox.c index fd9055eacf42..50c7f6c54b74 100644 --- a/drivers/mailbox/qcom-apcs-ipc-mailbox.c +++ b/drivers/mailbox/qcom-apcs-ipc-mailbox.c @@ -20,16 +20,7 @@ #include <linux/platform_device.h> #include <linux/regmap.h> #include <linux/mailbox_controller.h> - -#define QCOM_APCS_IPC_BITS 32 - -struct qcom_apcs_ipc { - struct mbox_controller mbox; - struct mbox_chan mbox_chans[QCOM_APCS_IPC_BITS]; - - struct regmap *regmap; - unsigned long offset; -}; +#include <linux/mailbox/qcom-apcs.h> static const struct regmap_config apcs_regmap_config = { .reg_bits = 32, diff --git a/include/linux/mailbox/qcom-apcs.h b/include/linux/mailbox/qcom-apcs.h new file mode 100644 index 000000000000..7e48fa2372dc --- /dev/null +++ b/include/linux/mailbox/qcom-apcs.h @@ -0,0 +1,34 @@ +/* + * Copyright (c) 2017, Linaro Limited + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef _LINUX_QCOM_APCS_H_ +#define _LINUX_QCOM_APCS_H_ + +#define QCOM_APCS_IPC_BITS 32 + +/** + * struct qcom_apcs_ipc - APCS shared struct + * + * @mbox: mailbox controller + * @mbox_chans: array of the available communication channels + * @offset: mailbox IPC register offset + * @regmap: register map used to access APCS registers + */ +struct qcom_apcs_ipc { + struct mbox_controller mbox; + struct mbox_chan mbox_chans[QCOM_APCS_IPC_BITS]; + unsigned long offset; + struct regmap *regmap; +}; + +#endif /* _LINUX_QCOM_APCS_H_ */
Move the structure shared by the APCS IPC device and its subdevices into a separate header file. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> --- drivers/mailbox/qcom-apcs-ipc-mailbox.c | 11 +---------- include/linux/mailbox/qcom-apcs.h | 34 +++++++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+), 10 deletions(-) create mode 100644 include/linux/mailbox/qcom-apcs.h -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html