Re: [PATCHv12 06/49] clk: add support for low level register ops
On 12/22/2013 07:39 PM, Gerhard Sittig wrote:
[ added agust@ for mpc5xxx, dropped devicetree ]
On Fri, Dec 20, 2013 at 18:34 +0200, Tero Kristo wrote:
Low level register ops are needed for providing SoC or IP block specific
access routines to clock registers. Subsequent patches add support for
the low level ops for the individual clock drivers.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/clk.c| 28
include/linux/clk-provider.h | 17 +
2 files changed, 45 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 29281f6..8bcd1e0 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -34,6 +34,34 @@ static HLIST_HEAD(clk_root_list);
static HLIST_HEAD(clk_orphan_list);
static LIST_HEAD(clk_notifier_list);
+/**
+ * clk_readl_default - default clock register read support function
+ * @reg: register to read
+ *
+ * Default implementation for reading a clock register.
+ */
+static u32 clk_readl_default(void __iomem *reg)
+{
+ return readl(reg);
+}
+
+/**
+ * clk_writel_default - default clock register write support function
+ * @val: value to write
+ * @reg: register to write to
+ *
+ * Default implementation for writing a clock register.
+ */
+static void clk_writel_default(u32 val, void __iomem *reg)
+{
+ writel(val, reg);
+}
+
+struct clk_ll_ops clk_ll_ops_default = {
+ .clk_readl = clk_readl_default,
+ .clk_writel = clk_writel_default
+};
+
/*** locking ***/
static void clk_prepare_lock(void)
{
Mike, Anatolij, this is a HEADS UP for the clock and mpc5xxx
maintainers: This patch will break the recently introduced CCF
support for MPC512x (currently sitting in -next, to get merged
for 3.14), and requires some adjustment.
Either the clk_{read,write}l_default() routines' bodies need to
depend on the architecture, or the clk_ll_ops_default structure
needs to get preset differently depending on the architecture.
For least intrusive changes in future use, adding a routine which
allows to register a different ll_ops structure could be most
appropriate. That would allow to pre-set the ll_ops structure
with the readl()/writel() implementation (current state of
mainline code, working for the ARM architecture and maybe other
little endian peripherals), and allows to register the
ioread32be()/iowrite32be() routines for PowerPC, or whatever
other platforms or architectures will require.
Expecting each individual clock item registration to specify a
differing set of ll_ops if readl()/writel() are not appropriate
would look weird to me.
Further I'd suggest to split this register access aspect out of
the TI clock series, and to prepare it already for regmap style
access to the hardware registers. See the next comment below.
This sounds like a good idea to me, seeing it is blocking lots of other
things.
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index a4f14ae..671dff4 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -198,6 +198,23 @@ struct clk_hw {
const struct clk_init_data *init;
};
+/**
+ * struct clk_ll_ops - low-level register access ops for a clock
+ * @clk_readl: pointer to register read function
+ * @clk_writel: pointer to register write function
+ *
+ * Low-level register access ops are generally used by the basic clock types
+ * (clk-gate, clk-mux, clk-divider etc.) to provide support for various
+ * low-level hardware interfaces (direct MMIO, regmap etc.), but can also be
+ * used by other hardware-specific clock drivers if needed.
+ */
+struct clk_ll_ops {
+ u32 (*clk_readl)(void __iomem *reg);
+ void(*clk_writel)(u32 val, void __iomem *reg);
+};
+
+extern struct clk_ll_ops clk_ll_ops_default;
+
I'd suggest to add a strct clk_ll_ops pointer to the routines'
list of arguments, and to add some user data pointer to the
struct.
This would provide more than the reg pointer to the routine,
e.g. to determine an offset within a register set, and/or to hold
a regmap handle.
Not adding this extension now would lead to our queueing several
patches which will result in potential conflicts, or requiring
more cycles than necessary to achieve a working state for
currently pending changes.
Yea I think this sounds like a good idea.
There is another issue with this series: It introduces
alternative _default() routines (which are verbatim copies of
the static inlines from the header), then adjusts the basic clock
types (div, gate, mux), but does not remove the then obsolete
static inlines from the header.
Tero, can you please verify whether the clk_readl() and
clk_writel() routines from linux/clock-provider.h become
obsolete with your patch, or whether any unchanged users remain?
Just did a quick grep and it seems you are right, the routines become
obsolete and could be removed (or alternatively just rename the
clk_readl/writel_default to
Re: [PATCHv12 07/49] clk: divider: add support for low level ops
On 12/22/2013 07:52 PM, Gerhard Sittig wrote: [ dropped devicetree, we're clock specific here ] On Fri, Dec 20, 2013 at 18:34 +0200, Tero Kristo wrote: Divider clock can now be registered to use low level register access ops. Preferred initialization method is via clock description. Signed-off-by: Tero Kristo t-kri...@ti.com --- drivers/clk/clk-divider.c| 22 +++--- include/linux/clk-provider.h |4 2 files changed, 23 insertions(+), 3 deletions(-) diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c index 8cfed5c..887e2d8 100644 --- a/drivers/clk/clk-divider.c +++ b/drivers/clk/clk-divider.c @@ -108,7 +108,12 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw, struct clk_divider *divider = to_clk_divider(hw); unsigned int div, val; - val = clk_readl(divider-reg) divider-shift; + if (divider-ll_ops) + val = divider-ll_ops-clk_readl(divider-reg); + else + val = clk_readl(divider-reg); Should this not better always use an ll_ops structure, which either is individual to the clock item, or is global for a platform, yet can get re-registered at runtime (see the comment on 06/49)? And why are you referencing clk_readl() instead of clk_readl_default() which you specifically have introduced in the previous patch? Adding a copy of the routine and using both the copy and the original doesn't look right. In some cases, the clock data is defined statically during compile time and here, ll_ops can be (and for OMAP cases at least is) NULL. I had kind of a global ll_ops definition in some of the earlier versions of this series, but it was frowned upon by some of the maintainers thus I dropped it. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/3] power_supply: Add power_supply notifier
Anton,
I don't see this patch in Linux tree. Any update on this would be helpful
Thanks
Jenny
-Original Message-
From: Anton Vorontsov [mailto:an...@scarybugs.org] On Behalf Of Anton
Vorontsov
Sent: Monday, December 02, 2013 3:54 AM
To: Pali Rohár
Cc: David Woodhouse; Tony Lindgren; Russell King;
linux-ker...@vger.kernel.org;
linux-omap@vger.kernel.org; freemangor...@abv.bg; aaro.koski...@iki.fi;
pa...@ucw.cz; Tc, Jenny
Subject: Re: [PATCH v2 1/3] power_supply: Add power_supply notifier
On Tue, Nov 19, 2013 at 11:18:03AM +0100, Pali Rohár wrote:
This patch adds a notifier chain to the power_supply.
This notifier helps drivers in other subsystem to listen to changes in
power supply subsystem. This would help to take some actions in those
drivers on changing the power supply properties.
One such scenario is to increase/decrease system performance based on
the battery capacity/voltage. Another scenario is to adjust the h/w
peak current detection voltage/current thresholds based on battery
voltage/capacity. The notifier helps drivers to listen to changes in
power_suppy susbystem without polling the power_supply properties
Signed-off-by: Jenny TC jenny...@intel.com
Signed-off-by: Pali Rohár pali.ro...@gmail.com
...
+enum power_supply_notifier_events {
+ PSY_EVENT_NONE,
This one is not needed.
+ PSY_EVENT_PROP_CHANGED,
+ PSY_EVENT_BATTERY,
+ PSY_EVENT_CABLE,
+};
The only event that is currently used in your patch series is
EVENT_PROP_CHANGED... So, I applied the patch with the following changes:
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h index
c6f52c0..0c2a260 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -15,6 +15,7 @@
#include linux/init.h
#include linux/slab.h
#include linux/device.h
+#include linux/notifier.h
#include linux/err.h
#include linux/power_supply.h
#include linux/thermal.h
@@ -159,10 +159,7 @@ enum power_supply_type { };
enum power_supply_notifier_events {
- PSY_EVENT_NONE,
PSY_EVENT_PROP_CHANGED,
- PSY_EVENT_BATTERY,
- PSY_EVENT_CABLE,
};
union power_supply_propval {
@@ -242,7 +239,7 @@ struct power_supply_info {
int use_for_apm;
};
-extern struct atomic_notifier_headpower_supply_notifier;
+extern struct atomic_notifier_head power_supply_notifier;
extern int power_supply_reg_notifier(struct notifier_block *nb); extern void
power_supply_unreg_notifier(struct notifier_block *nb); extern struct
power_supply *power_supply_get_by_name(const char *name);
Re: [RFT/RFC/PATCH 00/31] arm: omap: irq: cleanup INTC driver
[]..
so a bit more work is needed. Maybe also rebase these against
omap-for-v3.14/dt too?
Will do.
Rebased on top of omap-for-v3.14/omap3-board-removal. Patches are on my
k.org tree:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git wip/omap-fix-intc
It needs a minor build fix though..
diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index b58c5d5..d03b5a3 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -151,7 +151,7 @@ static void omap_mask_ack_irq(struct irq_data *d)
static void omap_suspend_irq(struct irq_data *d)
{
omap_intc_save_context();
- omap3_intc_prepare_idle();
+ omap_intc_prepare_idle();
/* A pending interrupt would prevent OMAP from entering suspend */
omap_ack_irq(NULL);
regards,
Rajendra
cheers
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/2] DMM DT adaptation
Hullo, On Tuesday 17 December 2013 03:32 PM, Archit Taneja wrote: The DMM/Tiler block can used by omapdrm to allocate frame buffers. With the removal of address and irq data from the omap4 hwmods, the probe of DMM driver fails and omapdrm isn't able to utilize the DMM hardware. Add DMM bindings for OMAP4 and OMAP5 and DRA7x. Can this be pulled for 3.14? I've incorporated comments from Mark and other folks. Thanks, Archit Changes in v5: - Use of_match_ptr() in the dmm driver. - Add DT node for DRA7x as dra7.dtsi is now in mainline. Changes in v4: - Clean up documentation further. Changes in v3: - Fix mistakes in documentation and remove aliases for dmm nodes. Changes in v2: - No changes, split out into a separate series containing only DT related parts. Archit Taneja (2): arm: dts: omap4+: Add DMM bindings drm: omap: Enable DT support for DMM Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 ++ arch/arm/boot/dts/dra7.dtsi| 7 +++ arch/arm/boot/dts/omap4.dtsi | 7 +++ arch/arm/boot/dts/omap5.dtsi | 7 +++ drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 7 +++ 5 files changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] power_supply: Add power_supply notifier
On Fri, Jan 03, 2014 at 11:09:49AM +, Tc, Jenny wrote: Anton, I don't see this patch in Linux tree. Any update on this would be helpful http://git.infradead.org/battery-2.6.git/commit/d36240d26025bec95f3499e2401a56db98d9f01c ?.. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT/RFC/PATCH 00/31] arm: omap: irq: cleanup INTC driver
On Fri, Jan 03, 2014 at 05:42:41PM +0530, Rajendra Nayak wrote:
[]..
so a bit more work is needed. Maybe also rebase these against
omap-for-v3.14/dt too?
Will do.
Rebased on top of omap-for-v3.14/omap3-board-removal. Patches are on my
k.org tree:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
wip/omap-fix-intc
It needs a minor build fix though..
diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index b58c5d5..d03b5a3 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -151,7 +151,7 @@ static void omap_mask_ack_irq(struct irq_data *d)
static void omap_suspend_irq(struct irq_data *d)
{
omap_intc_save_context();
- omap3_intc_prepare_idle();
+ omap_intc_prepare_idle();
fixed now, thanks. Wonder how come I didn't see that, I was building
every commit with omap2plus_defconfig :-( Oh well...
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv12 06/49] clk: add support for low level register ops
On 01/03/14 01:13, Tero Kristo wrote: On 12/22/2013 07:39 PM, Gerhard Sittig wrote: Further I'd suggest to split this register access aspect out of the TI clock series, and to prepare it already for regmap style access to the hardware registers. See the next comment below. This sounds like a good idea to me, seeing it is blocking lots of other things. This ll_ops struct looks like a simplified regmap. Have you seen my series that adds regmap support to the common clock framework[1]? Is there any reason why you can't use those patches and layer some patches on top to add support for regmap to the basic clock types? [1] https://lkml.org/lkml/2013/12/23/461 -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
