Re: [PATCH v2 02/14] MFD: twl4030-audio: Convert to use devm_kzalloc
On Tue, 2012-08-14 at 17:22 +0300, Peter Ujfalusi wrote: > Signed-off-by: Peter Ujfalusi I think this one could use a short commit message, also about why kfree():s are dropped (handled internally by devm_* etc.) -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/14] MFD/ASoC/Input: twl4030-audio submodule DT support
Hi Peter, The MFD patches in this set look good to me except for the minor comment on patch 2 I just sent. That is with my limited knowledge of DT though... -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MFD: twl-core: Fix chip ID for the twl6030-pwm module
Acked-by: Tero Kristo
On Wed, 2012-10-31 at 15:54 +0100, Peter Ujfalusi wrote:
> The correct chip id is 1 since the PWM module is on address 0x49. With the
> current TWL6030_MODULE_ID1 the kernel will crash early since:
> #define TWL6030_MODULE_ID1 0x0E
> and
> static struct twl_client twl_modules[4];
>
> Down in the stack we try to get the module by:
> struct twl_client *twl = &twl_modules[chip];
>
> Which obviously going to do nasty things.
>
> Signed-off-by: Peter Ujfalusi
> ---
> Hi Samuel,
>
> Can you push this patch to 3.7?
> Without this if the user enables the twl6030-pwm driver the kernel will not
> going to boot on OMAP4.
>
> Thank you,
> Peter
>
> drivers/mfd/twl-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index 2624668..d7577cb 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -672,7 +672,7 @@ add_children(struct twl4030_platform_data *pdata,
> unsigned irq_base,
> }
>
> if (IS_ENABLED(CONFIG_PWM_TWL6030) && twl_class_is_6030()) {
> - child = add_child(TWL6030_MODULE_ID1, "twl6030-pwm", NULL, 0,
> + child = add_child(SUB_CHIP_ID1, "twl6030-pwm", NULL, 0,
> false, 0, 0);
> if (IS_ERR(child))
> return PTR_ERR(child);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/5] clk: dt: binding for basic multiplexer clock
On 08/29/2013 04:14 AM, Mike Turquette wrote:
Quoting Kumar Gala (2013-08-28 08:50:10)
On Aug 22, 2013, at 12:53 AM, Mike Turquette wrote:
Device Tree binding for the basic clock multiplexer, plus the setup
function to register the clock. Based on the existing fixed-clock
binding.
Includes minor beautification of clk-provider.h where some whitespace is
added and of_fixed_factor_clock_setup is relocated to maintain a
consistent style.
Tero Kristo contributed helpful bug fixes to this patch.
Signed-off-by: Mike Turquette
Tested-by: Heiko Stuebner
Reviewed-by: Heiko Stuebner
---
Changes since v3:
* replaced underscores with dashes in DT property names
* bail from of clock setup function early if of_iomap fails
* removed unecessary explict cast
.../devicetree/bindings/clock/mux-clock.txt| 79 ++
drivers/clk/clk-mux.c | 68 ++-
include/linux/clk-provider.h | 5 +-
3 files changed, 150 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/mux-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/mux-clock.txt
b/Documentation/devicetree/bindings/clock/mux-clock.txt
new file mode 100644
index 000..21eb3b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mux-clock.txt
@@ -0,0 +1,79 @@
+Binding for simple mux clock.
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped multiplexer with multiple input clock signals or
+parents, one of which can be selected as output. This clock does not
+gate or adjust the parent rate via a divider or multiplier.
+
+By default the "clocks" property lists the parents in the same order
+as they are programmed into the regster. E.g:
+
+ clocks = <&foo_clock>, <&bar_clock>, <&baz_clock>;
+
+results in programming the register as follows:
+
+register value selected parent clock
+0foo_clock
+1bar_clock
+2baz_clock
+
+Some clock controller IPs do not allow a value of zero to be programmed
+into the register, instead indexing begins at 1. The optional property
+"index-starts-at-one" modified the scheme as follows:
+
+register value selected clock parent
+1foo_clock
+2bar_clock
+3baz_clock
+
+Additionally an optional table of bit and parent pairs may be supplied
+like so:
+
+ table = <&foo_clock 0x0>, <&bar_clock, 0x2>, <&baz_clock, 0x4>;
+
I think this is going way too far for what should be in a device tree. Why
should this not just be encoded in tables in the code?
To reduce kernel data bloat.
The mux-clock binding covers a quite a few platforms that have similar
mux-clock programming requirements. If the DT binding is verbose enough
then the basic mux clock driver is sufficient to initialize all of the
mux clocks from DT: no new platform-specific clock driver with a bunch
of data is necessary.
On the other hand if we rely on tables in C to define how mux-clock
parents are selected then every platform will have to write their own
clock driver just to define their clock data.
Having drivers written for the sole purpose of listing out a bunch of
data sounds like something that DT was meant to solve, even if this
isn't at the board level and is at the SoC level.
+1. For my work this helps quite a bit at least.
-Tero
+where the first value in the pair is the parent clock and the second
+value is the bitfield to be programmed into the register.
+
+The binding must provide the register to control the mux and the mask
+for the corresponding control bits. Optionally the number of bits to
+shift that mask if necessary. If the shift value is missing it is the
+same as supplying a zero shift.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "mux-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks
+- reg : base address for register controlling adjustable mux
+- bit-mask : arbitrary bitmask for programming the adjustable mux
+
+Optional properties:
+- clock-output-names : From common clock binding.
+- table : array of integer pairs defining parents & bitfield values
+- bit-shift : number of bits to shift the bit-mask, defaults to
+ (ffs(mask) - 1) if not present
+- index-starts-at-one : valid input select programming starts at 1, not
+ zero
+- hiword-mask : lower half of the register programs the mux, upper half
+ of the register indicates bits that were updated in the lower half
+
+Examples:
+ clock: clock@4a008100 {
+ compatible = "mux-clock";
+ #clock-cells = <0>;
+ clocks = <&clock_foo>, <&clock_bar>, <&clock_ba
Re: [PATCH v4 3/5] clk: dt: binding for basic multiplexer clock
Hi, Chirping in my thoughts below. On 09/05/2013 11:30 PM, Stephen Warren wrote: On 09/05/2013 12:29 PM, Mike Turquette wrote: On Wed, Sep 4, 2013 at 11:36 AM, Stephen Warren wrote: On 09/03/2013 05:22 PM, Mike Turquette wrote: Quoting Stephen Warren (2013-08-30 14:37:46) On 08/30/2013 02:33 PM, Mike Turquette wrote: ... The clock _data_ seems to always have some churn to it. Moving it out to DT reduces that churn from Linux. My concern above is not about kernel data size. That sounds like the opposite of what we should be doing. It's fine for kernel code/data to change; that's a natural part of development. Obviously, we should minimize churn, through thorough review, domain knowledge, etc. And with the "clock mapping" style bindings we'll end up changing both the DT binding definition and the kernel. Not great. What's a "clock mapping" style binding? I guess that means the style where you have a single DT node that provides multiple clocks, rather than one DT node per clock? If the kernel driver changes its internal data, I don't see why that would have any impact at all on the DT binding definition. We should be able to use one DT binding definition with arbitrary drivers. Yes, I'm referring to a single node providing multiple clocks. As an example see the Exynos 5420 binding: Documentation/devicetree/bindings/clock/exynos5420-clock.txt The clock id's are stored as part of the binding definition resulting in a mapping scheme that can be fragile. The mapping shouldn't be fragile if e.g. include/dt-bindings/clock/exynos5420.h were used to define the values. That way, both the Exynos clock driver and Exynos DT files could both include the header, and would always be in sync. There have already been patches to fix the id's assigned in the binding, which isn't supposed to happen because it's a stable interface. That's definitely a real problem. The values should be stable. Preferably, the values should be derived from some aspect of the HW, and hence be stable. For example, many clock IDs on Tegra are derived from the clock's bit index within the peripheral clock enable registers. Although I must admit we have a bit of a mess in the Tegra clocks w.r.t. mis-using clock IDs for reset IDs and hence there are some peripheral clock IDS that don't map 1:1 with the register, and there are other clocks which aren't peripheral clocksthat we've assigned arbitrary IDs to rather than some HW-derived ID. Alternatively, perhaps a register address unique to the clock could be used. If new values are added, the additions should all happen in a single tree, and hence can be co-ordinated, thus avoiding any merge-conflicts. Even ignoring HW-derived clock IDs, people writing DT bindings simply need to get used to bindings being an ABI, and put extra effort into making sure the list of clocks is accurate and complete. Finally, while it's true that a DT binding definition is an ABI, and perhaps DT content isn't (so if there's a DT content bug it can simply be fixed), if DT is wrong because of insufficient thought about its content, it's still wrong, and the system doesn't work correctly. Whether we edit a kernel clock driver or a DT file to solve a problem, there was still a problem. Placing the data into DT doesn't make it any less likely there will be a problem if sufficient care isn't taken when thinking about the clock structure. If clock phandles are created by individual nodes in DT then the binding definition need never be updated due to merge conflicts or renaming which plagues the mapping scenario. That's true. But if we take that approach, shouldn't we just ban #clock-cells? The only case #clock-cells would still be legitimate would be an array of identical clocks represented by a single node, and even then the argument could be extended so say: just write out a node for each clock in the array, just like if the clocks weren't in an array or were different types. And I'll respond to your points below but the whole "relocate the problem to DT" argument is simply not my main point. What I want to do is increase the usefulness of DT by allowing register-level details into the binding which can Can you expand upon why a DT that encodes register-level details is more useful? I can't see why there would be any difference in usefulness. Sure. The usefulness comes out of the fact that we do not need to maintain data synchronization across dts and clock provider drivers. Only the clock IDs. That's a very small amount of information. And synchronizing the two simply means including a header file that defines the IDs in both places. This is *exactly* why I created the include/dt-bindings/ directory, to house such header files. The data lives in one place and only one place. We absolutely need a phandle to a clock in DT link clock consumer devices to their input clocks, so there is no question that should be in DT. Since we're already doing that, why not do away with trying to keep d
Re: [PATCH v4 0/5] clk: dt: bindings for mux, divider & gate clocks
On 08/29/2013 09:23 PM, Santosh Shilimkar wrote: Mike, On Thursday 22 August 2013 01:53 AM, Mike Turquette wrote: This series introduces binding definitions for common register-mapped clock multiplexer, divider and gate IP blocks along with the corresponding setup functions for matching DT data. The bindings are similar to the struct definitions but please don't hold that against the binding: the struct definitions closely model the hardware register layout. The delta from v3 is very small and only consists of cosmetic changes and one functional change for better error handling. Changes since v3: * added Tested-by & Reviewed-by from Heiko * replaced underscores with dashes in DT property names * bail from of clock setup function early if of_iomap fails * removed unecessary explict cast Mike Turquette (5): clk: divider: replace bitfield width with mask clk: of: helper for determining number of parent clocks clk: dt: binding for basic multiplexer clock clk: dt: binding for basic divider clock clk: dt: binding for basic gate clock I have used $subject series as the base for the Keystone ccf support and tested these patches on Keystone EVM. Will post those patches soon on the lists. For the series if you need more tested-by tags, feel free to add, Tested-by: Santosh Shilimkar Oh yea, same for my set I posted yesterday. Used this as basis for O3/O4/O5/DRA7/AM335x tests, so you can also add my Tested-by tag if you need one. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/13] MFD: twl drivers: Convert to regmap IO and cleanups
Hi Peter / Samuel, I just tested this set on omap3beagle + omap4460 panda boards and both seem to work fine. Did a boot + simple PM test for both to see that regulator control (which is using the I2C related stuff you have changed) works. Also, looking at the code everything seems to be okay to me, thus for whole set: Acked-by: Tero Kristo On Tue, 2012-11-13 at 09:28 +0100, Peter Ujfalusi wrote: > Hello, > > This series converts the twl-core to use regmap for IO towards the chip. > With the conversion to regmap IO we no longer need to allocate bigger buffer > for > writes. > I have appended patches to this series to make some cleanups which will help > in > the future to further clean up the twl stack. > > The series depends on a regression fix patch for the twl-core: > https://patchwork.kernel.org/patch/1679421/ > > Regards, > Peter > --- > Peter Ujfalusi (13): > MFD: twl-core: Register twl4030-madc child only for twl4030 class > MFD: twl-core: Support for proper PWM drivers > MFD: twl-core: Convert to use regmap for I/O > MFD/rtc/gpio: twl: No need to allocate bigger buffer for write > MFD: twl-core: Clean up and correct child registration > mfd: twl: Remove unused TWL_MODULE definitions > mfd: twl: Convert module id definitions to enums > mfd: twl: Use decimal numbers for TWL6030_MODULE_IDs > MFD: twl-core: re-group the twl_mapping table for easier reading > mfd: twl4030-madc: Change TWL4030_MODULE_* ids to TWL_MODULE_* > mfd: twl4030-power: Change TWL4030_MODULE_* ids to TWL_MODULE_* > mfd: twl4030-irq: Change TWL4030_MODULE_* ids to TWL_MODULE_* > mfd: twl-core: Change TWL4030_MODULE_* ids to TWL_MODULE_* > > drivers/gpio/gpio-twl4030.c | 12 +-- > drivers/mfd/twl-core.c | 227 > +++- > drivers/mfd/twl4030-irq.c | 10 +- > drivers/mfd/twl4030-madc.c | 14 +-- > drivers/mfd/twl4030-power.c | 124 ++-- > drivers/mfd/twl6030-irq.c | 4 +- > drivers/rtc/rtc-twl.c | 32 +++ > include/linux/i2c/twl.h | 73 +++--- > 8 files changed, 241 insertions(+), 255 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] CLK: ti: dra7: Initialize USB_DPLL
On 08/02/2013 10:30 AM, Roger Quadros wrote:
Hi Nishant,
On 08/01/2013 06:06 PM, Nishanth Menon wrote:
On 08/01/2013 09:58 AM, Roger Quadros wrote:
USB_DPLL must be initialized and locked at boot so that
USB modules can work.
Also program USB_DLL_M2 output to half rate.
Signed-off-by: Roger Quadros
---
drivers/clk/omap/clk-7xx.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/clk/omap/clk-7xx.c b/drivers/clk/omap/clk-7xx.c
index ddb39dd..f444513 100644
--- a/drivers/clk/omap/clk-7xx.c
+++ b/drivers/clk/omap/clk-7xx.c
@@ -19,6 +19,7 @@
#define DRA7_DPLL_ABE_DEFFREQ361267200
#define DRA7_DPLL_GMAC_DEFFREQ10
+#define DRA7_DPLL_USB_DEFFREQ96000
static struct omap_dt_clk dra7xx_clks[] = {
@@ -63,5 +64,15 @@ int __init dra7xx_clk_init(void)
if (rc)
pr_err("%s: failed to configure GMAC DPLL!\n", __func__);
+dpll_ck = clk_get_sys(NULL, "dpll_usb_ck");
+rc = clk_set_rate(dpll_ck, DRA7_DPLL_USB_DEFFREQ);
+if (rc)
+pr_err("%s: failed to configure USB DPLL!\n", __func__);
+
+dpll_ck = clk_get_sys(NULL, "dpll_usb_m2_ck");
+rc = clk_set_rate(dpll_ck, DRA7_DPLL_USB_DEFFREQ/2);
+if (rc)
+pr_err("%s: failed to set USB_DPLL M2 OUT\n", __func__);
+
return rc;
}
As I had mentioned on [1] - we are going to see similar needs keep popping up.
there is no need to hack this up for even more peripherals :(
http://marc.info/?l=linux-omap&m=137536803106017&w=2
The DPLLs need to be initialized irrespective of whether peripheral drivers are
present or not.
We have seen cases where the SoC fails to enter RETention if the DPLLS are not
correctly
configured.
But I agree with you that we should be able to initialize it by specifying the
initial rate via Clock Data.
This patch can be removed when the appropriate feature is added in OMAP clock
core.
... not OMAP clock core, I would say clock core. This is again a feature
we can work with once we have initial support in place.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: twl: Remove VDD1_VSEL_table and VDD2_VSEL_table
Looks good to me. Ack.
On Fri, 2013-02-15 at 22:23 +0800, Axel Lin wrote:
> Since commit ba305e31 "regulator: twl: fix twl4030 support for smps
> regulators",
> VDD1_VSEL_table and VDD2_VSEL_table are not used any more. Remove them.
>
> Signed-off-by: Axel Lin
> ---
> drivers/regulator/twl-regulator.c |6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/regulator/twl-regulator.c
> b/drivers/regulator/twl-regulator.c
> index 74508cc..683d314 100644
> --- a/drivers/regulator/twl-regulator.c
> +++ b/drivers/regulator/twl-regulator.c
> @@ -441,12 +441,6 @@ static const u16 VSIM_VSEL_table[] = {
> static const u16 VDAC_VSEL_table[] = {
> 1200, 1300, 1800, 1800,
> };
> -static const u16 VDD1_VSEL_table[] = {
> - 800, 1450,
> -};
> -static const u16 VDD2_VSEL_table[] = {
> - 800, 1450, 1500,
> -};
> static const u16 VIO_VSEL_table[] = {
> 1800, 1850,
> };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 0/5] firmware: Add support for TI System Control Interface (TI-SCI) protocol driver
On 08/09/16 20:31, Kevin Hilman wrote: Nishanth Menon writes: On 09/07/2016 01:55 PM, Kevin Hilman wrote: Nishanth Menon writes: [...] full mail thread in https://lkml.org/lkml/2016/9/6/747 Overall architecture is very similar to SCPI[4] as follows: Dumb Q: I'm curious about the limitations in SCPI that were found that made TI decided to implement its own version. [...] Long story short, investigation was done into what SCPI was providing (TI internal ofcourse) and SCPI did not fit our SoC generation needs - Thanks for the detailed explanation. Very helpful. To be clear, I'm not a proponent of always using ARM "standards" (especially when it's not exactly clear if it's a standard or a Juno thing) but I'm seeing several SoCs come out with SCPI derivatives, or old ARM versions etc., so was just curious about the decision making process. Thanks for sharing, Kevin So, any other comments for this series or shall we still try to get it merged for 4.9? We are -rc5 so it might be too late already and probably better to push this for 4.10. -Tero
Re: [PATCH 3/3] clk: keystone: Add sci-clk driver support
Hi Stephen,
Thanks for comments, inlined replies below.
On 24/08/16 11:34, Stephen Boyd wrote:
On 08/19, Nishanth Menon wrote:
THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
M: Hans Verkuil
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index e2d9bd760c84..d1724999be78 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -179,6 +179,19 @@ config COMMON_CLK_NXP
---help---
Support for clock providers on NXP platforms.
+if COMMON_CLK_KEYSTONE
Why not depends on COMMON_CLK_KEYSTONE? Or make the tristate have
an if COMMON_CLK_KEYSTONE after it? So far an if hasn't
happened in this file. And is anything inside
drivers/clk/keystone used by this driver? Maybe this if statement
can just be dropped entirely and then the keystone/Makefile
updated?
Yea will fix that.
+
+config TI_SCI_CLK
+ tristate "TI System Control Interface clock drivers"
+ depends on TI_SCI_PROTOCOL || COMPILE_TEST
+ default y
default TI_SCI_PROTOCOL?
That too.
+ help
+ This adds the clock driver support over TI System Control Interface.
+ If you wish to use clock resources from the PMMC firmware, say Y.
+ Otherwise, say N.
+
+endif # COMMON_CLK_KEYSTONE
+
config COMMON_CLK_PALMAS
tristate "Clock driver for TI Palmas devices"
depends on MFD_PALMAS
diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c
new file mode 100644
index ..6c43e097e6d6
--- /dev/null
+++ b/drivers/clk/keystone/sci-clk.c
@@ -0,0 +1,539 @@
+/*
+ * SCI Clock driver for keystone based devices
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ * Tero Kristo
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
Is this include used?
Yes, it seems I get a compile fail if this is not included:
CC drivers/clk/keystone/sci-clk.o
drivers/clk/keystone/sci-clk.c: In function 'ti_sci_clk_parse_flags':
drivers/clk/keystone/sci-clk.c:444:3: error: implicit declaration of
function 'of_clk_get_from_provider' [-Werror=implicit-function-declaration]
clk = of_clk_get_from_provider(&clkspec);
However, as there is the new API for clk_hw xlate, not sure if this is
needed once I convert the driver to use that. Will check.
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SCI_CLK_SSC_ENABLE BIT(0)
+#define SCI_CLK_ALLOW_FREQ_CHANGE BIT(1)
+#define SCI_CLK_INPUT_TERMINATION BIT(2)
+
+/**
+ * struct sci_clk_provider - TI SCI clock provider representation
+ * @sci:Handle to the System Control Interface protocol handler
+ * @ops:Pointer to the SCI ops to be used by the clocks
+ * @dev:Device pointer for the clock provider
+ * @clocks: List of all registered clocks
+ * @lock: Mutex for locking access to the @clocks list
+ */
+struct sci_clk_provider {
+ const struct ti_sci_handle *sci;
+ const struct ti_sci_clk_ops *ops;
+ struct device *dev;
+ struct list_head clocks;
+ struct mutex lock; /* Protects access to the @clocks list */
+};
+
+/**
+ * struct sci_clk - TI SCI clock representation
+ * @hw: Hardware clock cookie for common clock framework
+ * @dev_id: Device index
+ * @clk_id: Clock index
+ * @node: Clocks list link
+ * @provider: Master clock provider
+ * @flags: Flags for the clock
+ */
+struct sci_clk {
+ struct clk_hw hw;
+ u16 dev_id;
+ u8 clk_id;
+ struct list_head node;
+ struct sci_clk_provider *provider;
+ u8 flags;
+};
+
+#define to_sci_clk(_hw) container_of(_hw, struct sci_clk, hw)
+
+/**
+ * sci_clk_prepare - Prepare (enable) a TI SCI clock
+ * @hw: clock to prepare
+ *
+ * Prepares a clock to be actively used. Returns the SCI protocol status.
+ */
+static int sci_clk_prepare(struct clk_hw *hw)
+{
+ struct sci_clk *clk = to_sci_clk(hw);
+ bool enable_ssc = clk->flags & SCI_CLK_SSC_ENABLE;
+ bool allow_freq_change = clk->flags & SCI_CLK_ALLOW_FREQ_CHANGE;
+ bool input_termination = clk->flags & SCI_CLK_INPUT_TERMINATION;
+
+ return clk->provider->ops->get_clock(clk->provider->sci, clk->dev_id,
+clk->clk_id, enable_ssc,
+allow_freq_change,
+input_termination);
+}
+
+/**
+ * sci_clk_unpr
[GIT PULL] firmware: add support for TI System Control Interface (TI-SCI) protocol driver
Hi Santosh, The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: https://github.com/t-kristo/linux-pm.git 4.8-rc1-ti-sci-fw for you to fetch changes up to 7a2c510cdfa6a4b2f4200c122a377c4d5f4af552: firmware: ti_sci: Add support for reboot core service (2016-08-31 14:50:20 +0300) Nishanth Menon (5): Documentation: Add support for TI System Control Interface (TI-SCI) protocol firmware: Add basic support for TI System Control Interface (TI-SCI) protocol firmware: ti_sci: Add support for Device control firmware: ti_sci: Add support for Clock control firmware: ti_sci: Add support for reboot core service .../devicetree/bindings/arm/keystone/ti,sci.txt| 66 + MAINTAINERS| 10 + drivers/firmware/Kconfig | 15 + drivers/firmware/Makefile |1 + drivers/firmware/ti_sci.c | 1997 drivers/firmware/ti_sci.h | 492 + include/linux/soc/ti/ti_sci_protocol.h | 249 +++ 7 files changed, 2830 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt create mode 100644 drivers/firmware/ti_sci.c create mode 100644 drivers/firmware/ti_sci.h create mode 100644 include/linux/soc/ti/ti_sci_protocol.h
Re: [PATCH 3/3] clk: keystone: Add sci-clk driver support
On 01/09/16 01:31, Stephen Boyd wrote: On 08/31, Tero Kristo wrote: On 24/08/16 11:34, Stephen Boyd wrote: On 08/19, Nishanth Menon wrote: diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c new file mode 100644 index ..6c43e097e6d6 --- /dev/null +++ b/drivers/clk/keystone/sci-clk.c @@ -0,0 +1,539 @@ + return (int)new_rate; determine rate should return a negative number on failure and 0 on success. The actual rate that was found should go into req->rate. This looks broken. Yea it seems broken, I wonder how we haven't seen any issues with this in testing Apparently positive return values from this are interpreted as success. Having a quick look at clk.c seems to confirm this. Anyway, will fix. True, perhaps we should fix that so we don't use a long to hold the int return value either. + * + * Gets a handle to an existing TI SCI clock, or builds a new clock + * entry and registers it with the common clock framework. Called from + * the common clock framework, when a corresponding of_clk_get call is + * executed, or recursively from itself when parsing parent clocks. + * Returns a pointer to the clock struct, or ERR_PTR value in failure. + */ Please move this driver to clk_hw_register() and friends. This on the fly clk generation is scary considering how we hold locks while the provider is asked to give us the pointer, so allocating and registering clks (basically reentering the CCF again) could lead to a locking nightmare. Best to avoid that. Ok, so just converting the driver to use provider->get_hw should be enough? This seems to be a relatively new API in the CCF. Will look at that. Hopefully it will simplify things greatly. Well, it didn't simplify things greatly, but somewhat. I still need to use of_parse_phandle_with_args with one of the helpers for example. Will send out v2 in a bit. + } + + snprintf(name, 20, "%s:%d:%d", dev_name(provider->dev), sci_clk->dev_id, +sci_clk->clk_id); I hope we don't make dev_name() longer than 20 characters Shall I just increase the size of the buffer and add a length check? Using kmalloc or something here seems overkill, as the name gets copied by CCF anyway. There's kasprintf() which would always make it long enough. I don't know if it really matters though. Ok, I will use this one. -Tero
Re: [PATCH] clk: keystone: TI_SCI_PROTOCOL is needed for clk driver
On 22/06/17 00:50, Stephen Boyd wrote:
On 06/20, Arnd Bergmann wrote:
CONFIG_COMPILE_TEST allows building a configuration without
TI_SCI_PROTOCOL, which then fails to link:
drivers/clk/keystone/sci-clk.o: In function `ti_sci_clk_probe':
sci-clk.c:(.text.ti_sci_clk_probe+0x4c): undefined reference to
`devm_ti_sci_get_handle'
This makes it a hard dependency. Right now, that means we can't
actually compile-test the driver unless ARCH_KEYSTONE is set as
well, but we can fix that by allowing TI_MESSAGE_MANAGER to
be selected for COMPILE_TEST as well.
Fixes: b745c0794e2f ("clk: keystone: Add sci-clk driver support")
Signed-off-by: Arnd Bergmann
Looks ok to me. Tero?
Yeah, looks okay to me also, been traveling so sorry about the latency.
Acked-by: Tero Kristo
Re: [PATCH] PM / QoS: Fix default runtime_pm device resume latency
On 01/11/17 00:32, Rafael J. Wysocki wrote:
On Tue, Oct 31, 2017 at 7:07 PM, Geert Uytterhoeven
wrote:
Hi Rafael,
On Tue, Oct 31, 2017 at 6:22 PM, Rafael J. Wysocki wrote:
On Tue, Oct 31, 2017 at 2:55 PM, Geert Uytterhoeven
wrote:
Hi Rafael, Tero,
CC pinchartl, dri-devel
On Tue, Oct 31, 2017 at 2:10 PM, Geert Uytterhoeven
wrote:
CC linux-renesas-soc
On Tue, Oct 31, 2017 at 2:09 PM, Geert Uytterhoeven
wrote:
On Tue, Oct 31, 2017 at 12:27 AM, Rafael J. Wysocki wrote:
On Monday, October 30, 2017 11:19:08 AM CET Rafael J. Wysocki wrote:
On Mon, Oct 30, 2017 at 8:10 AM, Tero Kristo wrote:
The recent change to the PM QoS framework to introduce a proper
no constraint value overlooked to handle the devices which don't
implement PM QoS OPS. Runtime PM is one of the more severely
impacted subsystems, failing every attempt to runtime suspend
a device. This leads into some nasty second level issues like
probe failures and increased power consumption among other things.
Oh, that's bad.
Sorry about breaking it and thanks for the fix!
Fix this by adding a proper return value for devices that don't
implement PM QoS implicitly.
Fixes: 0cc2b4e5a020 ("PM / QoS: Fix device resume latency PM QoS")
Signed-off-by: Tero Kristo
Cc: Rafael J. Wysocki
Applied.
And pushed to Linus.
I'm afraid it is not sufficient.
Commit 0cc2b4e5a020fc7f ("PM / QoS: Fix device resume latency PM QoS")
introduced two issues on Renesas platforms:
1. After boot up, many devices have changed their state from "suspended"
to "active", according to /sys/kernel/debug/pm_genpd/pm_genpd_summary
(comparing that file across boots is one of my standard tests).
Interestingly, doing a system suspend/resume cycle restores their state
to "suspended".
2. During system suspend, the following warning is printed on
r8a7791/koelsch:
i2c-rcar e653.i2c: runtime PM trying to suspend device but
active child
3. I've just bisected a seemingly unrelated issue to the same commit.
On Salvator-XS with R-Car H3, initialization of the rcar-du driver now
takes more than 1 minute due to flip_done time outs, while it took 0.12s
before:
[3.015035] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.021721] [drm] No driver support for vblank timestamp query.
[ 13.280738] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
[CRTC:58:crtc-3] flip_done timed out
[ 23.520707] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
[CRTC:58:crtc-3] flip_done timed out
[ 33.760708] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
[CRTC:58:crtc-3] flip_done timed out
[ 44.000755] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
[CRTC:58:crtc-3] flip_done timed out
[ 44.003597] Console: switching to colour frame buffer device 128x48
[ 54.240707] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
[CRTC:58:crtc-3] flip_done timed out
[ 64.480706] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
[CRTC:58:crtc-3] flip_done timed out
[ 64.544876] rcar-du feb0.display: fb0: frame buffer device
[ 64.552013] [drm] Initialized rcar-du 1.0.0 20130110 for
feb0.display on minor 0
[ 64.559873] [drm] Device feb0.display probed
Commit 2a9a86d5c81389cd ("PM / QoS: Fix default runtime_pm device resume
latency") fixes the second issue, but not the first.
... nor the third.
Reverting commits 2a9a86d5c81389cd ("PM / QoS: Fix default runtime_pm
device resume latency") and 0cc2b4e5a020fc7f ("PM / QoS: Fix device resume
latency PM QoS") fixes both.
... all three.
Sorry for the breakage.
OK, I'll just push the reverts to Linus later today.
Do you have a clue?
Well, kind of.
There is a change in behavior in domain_governor.c that should not
have made any difference to my eyes, but maybe that's it.
Can you please check if the attached patch makes any difference?
Thanks, but it doesn't seem to fix the issues.
Thanks for testing!
I've just pushed the reverts, but the PM QoS still needs to be fixed,
so we have to get to the bottom of this.
The current theory goes that the changes in domain_governor.c are to
blame. Is genpd involved in all of the issues with the PM QoS fix you
have seen?
Thanks,
Rafael
It seems the default values for pm_qos have changed with the patch, and
that breaks genpd at least. I only fixed PM runtime initially, but you
could try this diff to fix the genpd part also:
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index d68b056..7c8f643 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -34,9 +34,9 @@ enum pm_qos_flags_status {
#define PM_QOS_NETWORK_LAT_DEFAULT_VALUE (2000 * USEC_PER_SEC)
#define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE0
#define PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE 0
Re: n900 in next-20170901
On 14/11/17 19:37, Tony Lindgren wrote:
* Joonsoo Kim [171114 06:34]:
On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote:
* Joonsoo Kim [171110 06:34]:
On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote:
+#define OMAP34XX_SRAM_PHYS 0x4020
+#define OMAP34XX_SRAM_VIRT 0xd001
+#define OMAP34XX_SRAM_SIZE 0x1
For my testing environment, vmalloc address space is started at
roughly 0xe000 so 0xd001 would not be valid.
Well we can map it anywhere we want, got any preferences?
My testing environment is a beagle-(xm?) for QEMU. It is configured by
CONFIG_VMSPLIT_3G=y so kernel address space is started at 0xc000.
And, it has 512 MB memory so 0xc000 ~ 0xdff0 is used for
direct mapping. See below.
[0.00] Memory: 429504K/522240K available (11264K kernel code,
1562K rwdata, 4288K rodata, 2048K init, 405K bss, 27200K reserved,
65536K cma-reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
[0.00] vmalloc : 0xe000 - 0xff80 ( 504 MB)
[0.00] lowmem : 0xc000 - 0xdff0 ( 511 MB)
[0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
[0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB)
[0.00] .text : 0xc0208000 - 0xc0e0 (12256 kB)
[0.00] .init : 0xc130 - 0xc150 (2048 kB)
[0.00] .data : 0xc150 - 0xc1686810 (1563 kB)
[0.00].bss : 0xc168fc68 - 0xc16f512c ( 406 kB)
Therefore, if OMAP34XX_SRAM_VIRT is 0xd001, direct mapping is
broken and the system doesn't work. I guess that we should use more
stable address like as 0xf000.
OK. Let's forget about adding static mappings and my earlier
patches to attempt to fix this. Below is what I now think we should
merge as a fix before merging Joonsoo's patches. Please all review
and test, adding Tero to Cc also.
Regards,
Tony
8< ---
From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Mon, 13 Nov 2017 13:23:33 -0800
Subject: [PATCH] ARM: OMAP2+: Fix SRAM virt to phys translation for
save_secure_ram_context
With the CMA changes from Joonsoo Kim , it
was noticed that n900 stopped booting. After investigating it turned
out that n900 save_secure_ram_context does some whacky virtual to
physical address translation for the SRAM data address.
As we now only have minimal parts of omap3 idle code copied to SRAM,
running save_secure_ram_context() in SRAM is not needed. It only gets
called on PM init. And it seems there's no need to ever call this from
SRAM idle code.
So let's just keep save_secure_ram_context() in DDR, and pass it the
physical address of the parameters. We can do everything else in
omap-secure.c like we already do for other secure code.
And since we don't have any documentation, I still have no clue what
the values for 0, 1 and 1 for the parameters might be. If somebody has
figured it out, please do send a patch to add some comments.
Debugged-by: Joonsoo Kim
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/omap-secure.c | 19 +++
arch/arm/mach-omap2/omap-secure.h | 4
arch/arm/mach-omap2/pm.h | 4
arch/arm/mach-omap2/pm34xx.c | 13 -
arch/arm/mach-omap2/sleep34xx.S | 26 --
5 files changed, 31 insertions(+), 35 deletions(-)
I guess you could just use rx51_secure_dispatcher and ditch the
save_secure_ram_context call completely (and most of the other related
code)? That one would handle the cache also in a clean manner.
Something like:
rx51_secure_dispatcher(25, 0, FLAG_START_CRITICAL, 4,
__pa(omap3_secure_ram_storage), 0, 1, 1);
Can't test it myself as I don't have omap3 secure HW.
-Tero
diff --git a/arch/arm/mach-omap2/omap-secure.c
b/arch/arm/mach-omap2/omap-secure.c
--- a/arch/arm/mach-omap2/omap-secure.c
+++ b/arch/arm/mach-omap2/omap-secure.c
@@ -73,6 +73,25 @@ phys_addr_t omap_secure_ram_mempool_base(void)
return omap_secure_memblock_base;
}
+u32 omap3_save_secure_ram(void __iomem *addr, int size)
+{
+ u32 ret;
+ u32 param[5];
+
+ if (size != OMAP3_SAVE_SECURE_RAM_SZ)
+ return OMAP3_SAVE_SECURE_RAM_SZ;
+
+ param[0] = 4; /* Number of arguments */
+ param[1] = __pa(addr); /* Physical address for saving */
+ param[2] = 0;
+ param[3] = 1;
+ param[4] = 1;
+
+ ret = save_secure_ram_context(__pa(param));
+
+ return ret;
+}
+
/**
* rx51_secure_dispatcher: Routine to dispatch secure PPA API calls
* @idx: The PPA API index
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -31,6 +31,8 @@
/* Maximum Secure memory storage size */
#define OMAP_
Re: n900 in next-20170901
On 14/11/17 21:44, Tony Lindgren wrote: * Tero Kristo [171114 19:34]: I guess you could just use rx51_secure_dispatcher and ditch the save_secure_ram_context call completely (and most of the other related code)? That one would handle the cache also in a clean manner. Something like: rx51_secure_dispatcher(25, 0, FLAG_START_CRITICAL, 4, __pa(omap3_secure_ram_storage), 0, 1, 1); That's different, as rx51_secure_dispatcher does the following: - Use arguments + 1 instead of 4, we currently use just 4 - Disables local_irq and fiq, we are not doing that now - Flushes and invalidates cache range, we are not doing that - Calls omap_smc3 that only does mov r6, #0xff, and does not do mov r2, #4 - Missing nops after it's done This just based on a quick look I did earlier. So just because of the extra work it does we don't want to do it even if it worked :) Hmm ok, I was just thinking that all the extra flushes, irq disables etc. might be good to have in place, as a safeguard when entering secure mode. You might get glitches in certain conditions otherwise. The things it is missing might just be clutter. Anyway, that said, the changes you did look sane, but I might have cleaned it up a bit further. :) -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH] PM / QoS: Fix default runtime_pm device resume latency
The recent change to the PM QoS framework to introduce a proper
no constraint value overlooked to handle the devices which don't
implement PM QoS OPS. Runtime PM is one of the more severely
impacted subsystems, failing every attempt to runtime suspend
a device. This leads into some nasty second level issues like
probe failures and increased power consumption among other things.
Fix this by adding a proper return value for devices that don't
implement PM QoS implicitly.
Fixes: 0cc2b4e5a020 ("PM / QoS: Fix device resume latency PM QoS")
Signed-off-by: Tero Kristo
Cc: Rafael J. Wysocki
---
include/linux/pm_qos.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 6737a8c..d68b056 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -175,7 +175,8 @@ static inline s32 dev_pm_qos_requested_flags(struct device
*dev)
static inline s32 dev_pm_qos_raw_read_value(struct device *dev)
{
return IS_ERR_OR_NULL(dev->power.qos) ?
- 0 : pm_qos_read_value(&dev->power.qos->resume_latency);
+ PM_QOS_RESUME_LATENCY_NO_CONSTRAINT :
+ pm_qos_read_value(&dev->power.qos->resume_latency);
}
#else
static inline enum pm_qos_flags_status __dev_pm_qos_flags(struct device *dev,
--
1.9.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] PM / QoS: Fix default runtime_pm device resume latency
On 31/10/17 01:27, Rafael J. Wysocki wrote:
On Monday, October 30, 2017 11:19:08 AM CET Rafael J. Wysocki wrote:
On Mon, Oct 30, 2017 at 8:10 AM, Tero Kristo wrote:
The recent change to the PM QoS framework to introduce a proper
no constraint value overlooked to handle the devices which don't
implement PM QoS OPS. Runtime PM is one of the more severely
impacted subsystems, failing every attempt to runtime suspend
a device. This leads into some nasty second level issues like
probe failures and increased power consumption among other things.
Oh, that's bad.
Sorry about breaking it and thanks for the fix!
Fix this by adding a proper return value for devices that don't
implement PM QoS implicitly.
Fixes: 0cc2b4e5a020 ("PM / QoS: Fix device resume latency PM QoS")
Signed-off-by: Tero Kristo
Cc: Rafael J. Wysocki
Applied.
And pushed to Linus.
That said, probe shouldn't ever fail if PM QoS is set to the
"never suspend" value.
User space can set it that way, after all, so the drivers that fail to probe
in that case aren't correct I'm afraid.
Ok interesting. The probe failure we had was a second order issue. A
driver (omap_nmailbox) was attempting to pm_runtime_get_sync()
...put_sync() during probe, and checked the return value of
pm_runtime_put_sync() which was -EPERM and bailed out. Most of the time,
drivers don't check the return value of this and will just succeed. I
did a grep on kernel and there are few other drivers that check the
return value also, didn't check if they do this during probe though but
it can potentially cause various issues elsewhere also.
So, you are saying we should not check the return value of
pm_runtime_put_x() ever, or should check if it is -EPERM and just pass
in that case? Is there any point returning -EPERM from the runtime core
at all then? This should probably be filtered out within runtime core as
a valid situation and just return 0.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] PM / QoS: Fix default runtime_pm device resume latency
On 31/10/17 10:40, Rafael J. Wysocki wrote:
On Tue, Oct 31, 2017 at 8:13 AM, Tero Kristo wrote:
On 31/10/17 01:27, Rafael J. Wysocki wrote:
On Monday, October 30, 2017 11:19:08 AM CET Rafael J. Wysocki wrote:
On Mon, Oct 30, 2017 at 8:10 AM, Tero Kristo wrote:
The recent change to the PM QoS framework to introduce a proper
no constraint value overlooked to handle the devices which don't
implement PM QoS OPS. Runtime PM is one of the more severely
impacted subsystems, failing every attempt to runtime suspend
a device. This leads into some nasty second level issues like
probe failures and increased power consumption among other things.
Oh, that's bad.
Sorry about breaking it and thanks for the fix!
Fix this by adding a proper return value for devices that don't
implement PM QoS implicitly.
Fixes: 0cc2b4e5a020 ("PM / QoS: Fix device resume latency PM QoS")
Signed-off-by: Tero Kristo
Cc: Rafael J. Wysocki
Applied.
And pushed to Linus.
That said, probe shouldn't ever fail if PM QoS is set to the
"never suspend" value.
User space can set it that way, after all, so the drivers that fail to
probe
in that case aren't correct I'm afraid.
Ok interesting. The probe failure we had was a second order issue. A driver
(omap_nmailbox) was attempting to pm_runtime_get_sync() ...put_sync() during
probe, and checked the return value of pm_runtime_put_sync() which was
-EPERM and bailed out. Most of the time, drivers don't check the return
value of this and will just succeed. I did a grep on kernel and there are
few other drivers that check the return value also, didn't check if they do
this during probe though but it can potentially cause various issues
elsewhere also.
So, you are saying we should not check the return value of
pm_runtime_put_x() ever, or should check if it is -EPERM and just pass in
that case?
The latter.
Is there any point returning -EPERM from the runtime core at all
then? This should probably be filtered out within runtime core as a valid
situation and just return 0.
Fair point.
However, there are other situations in which pm_runtime_put_sync() can
return an error code which needs to be checked, like -EBUSY or -EAGAIN
returned if one of the reference counters is nonzero.
In fact, the "no suspend" PM QoS constraint is somewhat similar to
this situation, so what about changing the error code returned to
-EAGAIN, for example?
Ok yea thats true. Its better to leave the decision to the drivers as
the core most likely can't know what the driver will actually want to do
with a prevented pm_runtime_put. That way the policy can be implemented
on case-by-case basis.
Keeping the -EPERM in place is probably also just fine, if someone needs
a detailed info of what prevented the pm_runtime_put from finishing
properly, and if someone is using this value already.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH] rtc: ds1307: Fix alarm programming for mcp794xx
mcp794xx alarm registers must be written in BCD format. However, the
alarm programming logic neglected this by adding one to the value
after bin2bcd conversion has been already done, writing bad values
to month register in case the alarm being set is in October. In this
case, the alarm month value becomes 0x0a instead of the expected 0x10.
Fix by moving the +1 addition within the bin2bcd call also.
Fixes: 1d1945d261a2 ("drivers/rtc/rtc-ds1307.c: add alarm support for mcp7941x
chips")
Signed-off-by: Tero Kristo
---
drivers/rtc/rtc-ds1307.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index a705e64..188006c 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -718,9 +718,9 @@ static int mcp794xx_set_alarm(struct device *dev, struct
rtc_wkalrm *t)
regs[3] = bin2bcd(t->time.tm_sec);
regs[4] = bin2bcd(t->time.tm_min);
regs[5] = bin2bcd(t->time.tm_hour);
- regs[6] = bin2bcd(t->time.tm_wday) + 1;
+ regs[6] = bin2bcd(t->time.tm_wday + 1);
regs[7] = bin2bcd(t->time.tm_mday);
- regs[8] = bin2bcd(t->time.tm_mon) + 1;
+ regs[8] = bin2bcd(t->time.tm_mon + 1);
/* Clear the alarm 0 interrupt flag. */
regs[6] &= ~MCP794XX_BIT_ALMX_IF;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: ti: dflt: fix enable_reg validity check
On 09/30/2015 01:37 AM, Suman Anna wrote:
The default clock enabling functions for TI clocks -
omap2_dflt_clk_enable() and omap2_dflt_clk_disable() perform a
NULL check for the enable_reg field of the clk_hw_omap structure.
This enable_reg field however is merely a combination of the index
of the master IP module, and the offset from the master IP module's
base address. A value of 0 is perfectly valid, and the current error
checking will fail in these cases. The issue was found when trying
to enable the iva2_ck clock on OMAP3 platforms.
So, switch the check to use IS_ERR. This correction is similar to the
logic used in commit c807dbedb5e5 ("clk: ti: fix ti_clk_get_reg_addr
error handling").
Signed-off-by: Suman Anna
---
Hi Tero,
Patch done against 4.3-rc3. There are couple of similar checks in
drivers/clk/ti/clockdomain.c, but those seem to be ok. This is
a non-urgent fix, as there are currently no active users of
iva2_ck in the kernel (the MMU node is disabled in DT atm).
Boot tested on OMAP3 Beagle-XM, AM437x GP EVM, AM335x BeagleBone
Black, OMAP4 Panda, OMAP5 uEVM and DRA7 Beagle-X15 boards.
regards
Suman
Following is the error log from a unit test of the IVA MMU on OMAP3 using
some additional patch to enable the DTS node,
[ 86.626342] omap_iommu_test_init: iommu_test_init entered
[ 86.632080] omap_iommu_test iommu_test: Enabling IOMMU...
[ 86.647460] omap_iommu_test iommu_test: testing IOMMU 5d00.mmu
[ 86.654815] omap2_dflt_clk_enable: iva2_ck missing enable_reg
[ 86.680938] [ cut here ]
[ 86.685821] WARNING: CPU: 0 PID: 910 at drivers/clk/clk.c:675
clk_disable+0x28/0x34()
[ 86.694091] Modules linked in: iommu_dt_test(O+)
[ 86.698974] CPU: 0 PID: 910 Comm: insmod Tainted: G O
4.3.0-rc3-8-g61458979cbbe #40
[ 86.708618] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[ 86.715240] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 86.723419] [] (show_stack) from []
(dump_stack+0x84/0x9c)
[ 86.731048] [] (dump_stack) from []
(warn_slowpath_common+0x78/0xb4)
[ 86.739593] [] (warn_slowpath_common) from []
(warn_slowpath_null+0x1c/0x24)
[ 86.748870] [] (warn_slowpath_null) from []
(clk_disable+0x28/0x34)
[ 86.757324] [] (clk_disable) from []
(_disable_clocks+0x18/0x68)
[ 86.765502] [] (_disable_clocks) from []
(omap_hwmod_deassert_hardreset+0xc8/0x180)
[ 86.775421] [] (omap_hwmod_deassert_hardreset) from []
(omap_device_deassert_hardreset+0x34/
0x54)
[ 86.786621] [] (omap_device_deassert_hardreset) from []
(omap_iommu_attach_dev+0xbc/0x1fc)
[ 86.797180] [] (omap_iommu_attach_dev) from []
(__iommu_attach_device+0x1c/0x80)
[ 86.806854] [] (__iommu_attach_device) from []
(omap_iommu_test_probe+0xd0/0x21c [iommu_dt_t
est])
[ 86.818054] [] (omap_iommu_test_probe [iommu_dt_test]) from
[] (platform_drv_probe+0x44/0xa4
)
[ 86.828857] [] (platform_drv_probe) from []
(driver_probe_device+0x1f4/0x2f0)
[ 86.838195] [] (driver_probe_device) from []
(__driver_attach+0x94/0x98)
[ 86.847045] [] (__driver_attach) from []
(bus_for_each_dev+0x6c/0xa0)
[ 86.855651] [] (bus_for_each_dev) from []
(bus_add_driver+0x18c/0x214)
[ 86.864349] [] (bus_add_driver) from []
(driver_register+0x78/0xf8)
[ 86.872772] [] (driver_register) from []
(do_one_initcall+0x80/0x1dc)
[ 86.881378] [] (do_one_initcall) from []
(do_init_module+0x5c/0x1d0)
[ 86.889892] [] (do_init_module) from []
(load_module+0x1818/0x1f70)
[ 86.898315] [] (load_module) from []
(SyS_init_module+0xdc/0x14c)
[ 86.906555] [] (SyS_init_module) from []
(ret_fast_syscall+0x0/0x1c)
[ 86.915039] ---[ end trace 49b229a4289ab8b2 ]---
[ 86.919891] omap_hwmod: mmu_iva: failed to hardreset
[ 86.925384] omap-iommu 5d00.mmu: deassert_reset failed: -16
[ 86.931640] omap_iommu_test iommu_test: can't get omap iommu: -16
[ 86.938140] omap_iommu_test iommu_test: can't attach iommu device: -16
[ 86.945068] omap_iommu_test_init failed, ret = -16
drivers/clk/ti/clkt_dflt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Queued for 4.3-rc-fixes thanks, as I have other patches to push for that.
-Tero
diff --git a/drivers/clk/ti/clkt_dflt.c b/drivers/clk/ti/clkt_dflt.c
index 90d7d8a21c49..1ddc288fce4e 100644
--- a/drivers/clk/ti/clkt_dflt.c
+++ b/drivers/clk/ti/clkt_dflt.c
@@ -222,7 +222,7 @@ int omap2_dflt_clk_enable(struct clk_hw *hw)
}
}
- if (unlikely(!clk->enable_reg)) {
+ if (unlikely(IS_ERR(clk->enable_reg))) {
pr_err("%s: %s missing enable_reg\n", __func__,
clk_hw_get_name(hw));
ret = -EINVAL;
@@ -264,7 +264,7 @@ void omap2_dflt_clk_disable(struct clk_hw *hw)
u32 v;
clk = to_clk_hw_omap(hw);
- if (!clk->enable_reg) {
+ if (IS_ERR(clk->enable_reg)) {
/*
* 'independent' here refers to a clock which is not
* controlled by its parent.
--
Re: [PATCH] clk: ti: fix OF child-node lookup
On 29/08/18 10:50, Johan Hovold wrote:
On Tue, Aug 28, 2018 at 03:32:03PM -0700, Stephen Boyd wrote:
Quoting Johan Hovold (2018-08-22 02:03:19)
Fix child-node lookup which by using the wrong OF helper was searching
the whole tree depth-first, something which could end up matching an
unrelated node.
Also fix the related node-reference leaks.
Fixes: 5b385a45e001 ("clk: ti: add support for clkctrl aliases")
Found by inspection? Or it's actively causing problems? I'm thinking
it's the former so this can bake in clk-next for a while.
Right, through inspection. I fixed up most of these last year, but this
one managed to sneak in since then.
clk-next should be fine.
The patch looks fine to me also, just had to test this out with my
latest development branch as it conflicts with that one a bit.
Acked-by: Tero Kristo
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v3 0/4] clk: clk: Add functions to save/restore clock context en-masse
On 10/07/18 08:56, Tony Lindgren wrote: * Keerthy [180621 01:18]: Deep enough power saving mode can result into losing context of the clock registers also, and they need to be restored once coming back from the power saving mode. Hence add functions to save/restore clock context. Patches 1 to 3 look good to me: Acked-by: Tony Lindgren Stephen, if no more comments, can you please set up an immutable branch for me as otherwise the last patch might cause merge conflicts? Regards, Tony Stephen, Mike, Any concerns about this series? This series touches core clock APIs slightly, but from my side these look fine. Do you want to pick #1-#3 up yourself or do you want me to setup a pull-req? Patch #4 seems like should go in via Tony's tree. -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] reset: ti-rstctrl: use the reset-simple driver
On 16/01/18 03:11, Tony Lindgren wrote:
We can support the RSTCTRL reset registers on many TI SoCs with
reset-simple.
Cc: Dave Gerlach
Cc: Mark Rutland
Cc: Nishant Menon
Cc: Philipp Zabel
Cc: Rob Herring
Cc: Suman Anna
Cc: Tero Kristo
Signed-off-by: Tony Lindgren
---
That's all there is to it :) Naturally this can wait for v4.17
if necessary.
Thats pretty neat. :)
-Tero
---
.../devicetree/bindings/reset/ti-rstctrl.txt | 29 ++
drivers/reset/Kconfig | 2 +-
drivers/reset/reset-simple.c | 1 +
3 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/reset/ti-rstctrl.txt
diff --git a/Documentation/devicetree/bindings/reset/ti-rstctrl.txt
b/Documentation/devicetree/bindings/reset/ti-rstctrl.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/ti-rstctrl.txt
@@ -0,0 +1,29 @@
+TI RSTCTRL Reset Controller
+
+Required properties:
+- compatible : "ti,rstctrl"
+- reg : Should contain 1 register ranges(address and length)
+- #reset-cells: 1
+
+Example:
+
+ prcm: prcm@20 {
+ compatible = "ti,am3-prcm", "simple-bus";
+ reg = <0x20 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x20 0x4000>;
+
+ prm_gfx: prm@1100 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x1100 0x100>;
+
+ gfx_rstctrl: rstctrl@4 {
+ reg = <0x4 0x4>;
+ #reset-cells = <1>;
+ compatible = "ti,rstctrl";
+ };
+ };
+ };
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -83,7 +83,7 @@ config RESET_PISTACHIO
config RESET_SIMPLE
bool "Simple Reset Controller Driver" if COMPILE_TEST
- default ARCH_SOCFPGA || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI ||
ARCH_ZX
+ default ARCH_OMAP2PLUS || ARCH_SOCFPGA || ARCH_STM32 || ARCH_STRATIX10
|| ARCH_SUNXI || ARCH_ZX
help
This enables a simple reset controller driver for reset lines that
that can be asserted and deasserted by toggling bits in a contiguous,
diff --git a/drivers/reset/reset-simple.c b/drivers/reset/reset-simple.c
--- a/drivers/reset/reset-simple.c
+++ b/drivers/reset/reset-simple.c
@@ -123,6 +123,7 @@ static const struct of_device_id reset_simple_dt_ids[] = {
{ .compatible = "st,stm32-rcc", },
{ .compatible = "allwinner,sun6i-a31-clock-reset",
.data = &reset_simple_active_low },
+ { .compatible = "ti,rstctrl", },
{ .compatible = "zte,zx296718-reset",
.data = &reset_simple_active_low },
{ /* sentinel */ },
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 4.4 038/134] ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss
On 20/03/18 01:52, Dan Rue wrote:
On Mon, Mar 19, 2018 at 07:05:21PM +0100, Greg Kroah-Hartman wrote:
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Roger Quadros
[ Upstream commit e2d54fe76997301b49311bde7ba8ef52b47896f9 ]
It seems that if L3_INIT clkdomain is kept in HW_AUTO while usb_otg_ss
is in use then there are random chances that the usb_otg_ss module
will fail to completely idle. i.e. IDLEST = 0x2 instead of 0x3.
Preventing L3_INIT from HW_AUTO while usb_otg_ss module is in use
fixes this issue.
We don't know yet if usb_otg_ss instances 3 and 4 are affected by this
issue or not so don't add this flag for those instances.
Cc: Tero Kristo
Signed-off-by: Roger Quadros
Signed-off-by: Tony Lindgren
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
This fails to build for me on arm32 with default config.
#
# make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm
multi_v7_defconfig
#
#
# make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm
#
../arch/arm/mach-omap2/omap_hwmod_7xx_data.c:2243:12: error:
'HWMOD_CLKDM_NOAUTO' undeclared here (not in a function)
.flags = HWMOD_CLKDM_NOAUTO,
^
../scripts/Makefile.build:269: recipe for target
'arch/arm/mach-omap2/omap_hwmod_7xx_data.o' failed
make[2]: *** [arch/arm/mach-omap2/omap_hwmod_7xx_data.o] Error 1
make[2]: Target '__build' not remade because of errors.
/home/buildslave/workspace/kernel-single-defconfig-builder/defconfig/multi_v7_defconfig/label/builder/Makefile:969:
recipe for target 'arch/arm/mach-omap2' failed
make[1]: *** [arch/arm/mach-omap2] Error 2
make[1]: Target '_all' not remade because of errors.
Makefile:152: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
make: Target '_all' not remade because of errors.
This again has some dependencies, at least:
8ff42da41147 ("ARM: OMAP2+ hwmod: Allow modules to disable HW_AUTO")
-Tero
Dan
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c |2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2240,6 +2240,7 @@ static struct omap_hwmod dra7xx_usb_otg_
.class = &dra7xx_usb_otg_ss_hwmod_class,
.clkdm_name = "l3init_clkdm",
.main_clk = "dpll_core_h13x2_ck",
+ .flags = HWMOD_CLKDM_NOAUTO,
.prcm = {
.omap4 = {
.clkctrl_offs =
DRA7XX_CM_L3INIT_USB_OTG_SS1_CLKCTRL_OFFSET,
@@ -2261,6 +2262,7 @@ static struct omap_hwmod dra7xx_usb_otg_
.class = &dra7xx_usb_otg_ss_hwmod_class,
.clkdm_name = "l3init_clkdm",
.main_clk = "dpll_core_h13x2_ck",
+ .flags = HWMOD_CLKDM_NOAUTO,
.prcm = {
.omap4 = {
.clkctrl_offs =
DRA7XX_CM_L3INIT_USB_OTG_SS2_CLKCTRL_OFFSET,
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 11/17] soc: ti: pruss: add pruss_get()/put() API
On 23/11/2018 10:20, Arnd Bergmann wrote: On Thu, Nov 22, 2018 at 12:41 PM Roger Quadros wrote: + + if (IS_ERR_OR_NULL(rproc)) + return ERR_PTR(-EINVAL); Any usage of IS_ERR_OR_NULL() tends to be an indication of a badly designed API. Please change this to allow only one of the two to be passed around. Should this be deprecated then? -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 1/4] dt-bindings: pinctrl: k3: Introduce pinmux definitions
On 20/11/2018 12:44, Vignesh R wrote: On 20/11/18 4:07 PM, Tero Kristo wrote: On 20/11/2018 12:09, Vignesh R wrote: On 19/11/18 12:49 PM, Tero Kristo wrote: On 17/11/2018 18:05, Nishanth Menon wrote: On 11:31-20181113, Vignesh R wrote: The dt-bindings header for TI K3 AM6 SoCs define a set of macros for [...] Thanks for reducing the combinations down to the minimum needed. We can worry about the DS and isolation bits when we have a real user for them. Acked-by: Nishanth Menon Tero: v4.21-rc1 perhaps ? Yeah, looks fine, queueing up for 4.21. Thank you all for the review! Tero, Is there a branch with these patches that I can use as base for my next set of DT patches? Don't have a branch for these atm, but I can create one if you need it. Yes, that would be great. Thanks! Pushed 4.20-rc1-am65x-queue into my public tree. -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 1/4] dt-bindings: pinctrl: k3: Introduce pinmux definitions
On 20/11/2018 12:09, Vignesh R wrote: On 19/11/18 12:49 PM, Tero Kristo wrote: On 17/11/2018 18:05, Nishanth Menon wrote: On 11:31-20181113, Vignesh R wrote: The dt-bindings header for TI K3 AM6 SoCs define a set of macros for [...] Thanks for reducing the combinations down to the minimum needed. We can worry about the DS and isolation bits when we have a real user for them. Acked-by: Nishanth Menon Tero: v4.21-rc1 perhaps ? Yeah, looks fine, queueing up for 4.21. Thank you all for the review! Tero, Is there a branch with these patches that I can use as base for my next set of DT patches? Don't have a branch for these atm, but I can create one if you need it. -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 2/3] clk: ti: check clock type before doing autoidle ops
On 30/11/2018 09:20, Stephen Boyd wrote:
Quoting Andreas Kemnade (2018-11-29 22:15:34)
Hi Stephen,
On Thu, 29 Nov 2018 16:25:05 -0800
Stephen Boyd wrote:
Quoting Andreas Kemnade (2018-11-10 12:31:14)
Code might use autoidle api with clocks not being omap2 clocks,
so check if clock type is not basic
Signed-off-by: Andreas Kemnade
---
New in v2
---
drivers/clk/ti/autoidle.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/ti/autoidle.c b/drivers/clk/ti/autoidle.c
index 161f67850393..5bdae5552d38 100644
--- a/drivers/clk/ti/autoidle.c
+++ b/drivers/clk/ti/autoidle.c
@@ -54,8 +54,12 @@ static DEFINE_SPINLOCK(autoidle_spinlock);
int omap2_clk_deny_idle(struct clk *clk)
{
struct clk_hw_omap *c;
+ struct clk_hw *hw = __clk_get_hw(clk);
- c = to_clk_hw_omap(__clk_get_hw(clk));
+ if (clk_hw_get_flags(hw) & CLK_IS_BASIC)
Please try to avoid using CLK_IS_BASIC if at all possible. Can you?
Maybe add some flag in clk_hw_omap() instead?
hmm, Tero suggested that.
But to check flags in clk_hw_omap I first need to know that there is a
clk_hw_omap behind clk_hw. And for that I either need to check flags in
clk_hw or do more changes in the omap_hwmod code.
Can you do it? The omap code is the only user of CLK_IS_BASIC. All the
other users are marking clks with this but there is no reason to do so.
I'll go make another pass over the tree and nuke those ones from orbit.
The reason for using this flag is because OMAP uses two clock types
around, the basic clocks like fixed-factor-clock/fixed-clock, and then
all the omap derivatives, which can be cast to clk_hw_omap. If we want
to avoid usage of CLK_IS_BASIC, we need to copy paste the remaining
basic code under drivers/clk/ti/ and convert them to use clk_hw_omap as
internal datatype. Is this preferred?
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 0/3] mach-omap2: handle autoidle denial
On 30/11/2018 02:26, Stephen Boyd wrote: Quoting Andreas Kemnade (2018-11-10 12:31:12) On the gta04 with a dm3730 omap_hdq does not work properly when the device enters lower power states. Idling uart1 and 2 is enough to show up that problem, if there are no other things enabled. Further research reveals that hdq iclk must not be turned off during transfers, also according to the TRM. That fact is also correctly described in the flags but the code to handle that is incomplete. To handle multiple users of a single ick, autoidle is disabled when a user of that ick requires that (has the OCPIF_SWSUP_IDLE)) Changes since v1: - uses spinlocks instead of mutexes - invert counter logic - check whether clock type is basic I'm expecting someone like Tero or Tony to review this. Rest of it looks fine to me, except for the discussion under the CLK_IS_BASIC flag, which might trigger a bigger rework of the code. -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 2/3] clk: ti: check clock type before doing autoidle ops
On 30/11/2018 09:57, Stephen Boyd wrote:
Quoting Tero Kristo (2018-11-29 23:35:35)
On 30/11/2018 09:20, Stephen Boyd wrote:
Quoting Andreas Kemnade (2018-11-29 22:15:34)
Hi Stephen,
On Thu, 29 Nov 2018 16:25:05 -0800
Stephen Boyd wrote:
Quoting Andreas Kemnade (2018-11-10 12:31:14)
Code might use autoidle api with clocks not being omap2 clocks,
so check if clock type is not basic
Signed-off-by: Andreas Kemnade
---
New in v2
---
drivers/clk/ti/autoidle.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/ti/autoidle.c b/drivers/clk/ti/autoidle.c
index 161f67850393..5bdae5552d38 100644
--- a/drivers/clk/ti/autoidle.c
+++ b/drivers/clk/ti/autoidle.c
@@ -54,8 +54,12 @@ static DEFINE_SPINLOCK(autoidle_spinlock);
int omap2_clk_deny_idle(struct clk *clk)
{
struct clk_hw_omap *c;
+ struct clk_hw *hw = __clk_get_hw(clk);
- c = to_clk_hw_omap(__clk_get_hw(clk));
+ if (clk_hw_get_flags(hw) & CLK_IS_BASIC)
Please try to avoid using CLK_IS_BASIC if at all possible. Can you?
Maybe add some flag in clk_hw_omap() instead?
hmm, Tero suggested that.
But to check flags in clk_hw_omap I first need to know that there is a
clk_hw_omap behind clk_hw. And for that I either need to check flags in
clk_hw or do more changes in the omap_hwmod code.
Can you do it? The omap code is the only user of CLK_IS_BASIC. All the
other users are marking clks with this but there is no reason to do so.
I'll go make another pass over the tree and nuke those ones from orbit.
The reason for using this flag is because OMAP uses two clock types
around, the basic clocks like fixed-factor-clock/fixed-clock, and then
all the omap derivatives, which can be cast to clk_hw_omap. If we want
to avoid usage of CLK_IS_BASIC, we need to copy paste the remaining
basic code under drivers/clk/ti/ and convert them to use clk_hw_omap as
internal datatype. Is this preferred?
No that is not preferred. Can the omap2_clk_deny_idle() function be
integrated closer into the clk framework in some way that allows it to
be part of the clk_ops structure? And then have that take a clk_hw
structure instead of a struct clk? I haven't looked at this in any
detail whatsoever so I may be way off right now.
It could be added under the main clk_ops struct, however this would
introduce two new func pointers to it which are not used by anything
else but OMAP. Are you aware of any other platforms requiring similar
feature?
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 0/3] mach-omap2: handle autoidle denial
On 30/11/2018 09:57, Stephen Boyd wrote: Quoting Tero Kristo (2018-11-29 23:37:35) On 30/11/2018 02:26, Stephen Boyd wrote: Quoting Andreas Kemnade (2018-11-10 12:31:12) On the gta04 with a dm3730 omap_hdq does not work properly when the device enters lower power states. Idling uart1 and 2 is enough to show up that problem, if there are no other things enabled. Further research reveals that hdq iclk must not be turned off during transfers, also according to the TRM. That fact is also correctly described in the flags but the code to handle that is incomplete. To handle multiple users of a single ick, autoidle is disabled when a user of that ick requires that (has the OCPIF_SWSUP_IDLE)) Changes since v1: - uses spinlocks instead of mutexes - invert counter logic - check whether clock type is basic I'm expecting someone like Tero or Tony to review this. Rest of it looks fine to me, except for the discussion under the CLK_IS_BASIC flag, which might trigger a bigger rework of the code. Is that a Reviewed-by tag? Not yet, lets see where discussion ends up with patch #2. :) -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 1/4] dt-bindings: pinctrl: k3: Introduce pinmux definitions
On 17/11/2018 18:05, Nishanth Menon wrote: On 11:31-20181113, Vignesh R wrote: The dt-bindings header for TI K3 AM6 SoCs define a set of macros for defining pinmux configs in human readable form, instead of raw-coded hex values. Signed-off-by: Vignesh R --- MAINTAINERS | 1 + include/dt-bindings/pinctrl/k3.h | 35 2 files changed, 36 insertions(+) create mode 100644 include/dt-bindings/pinctrl/k3.h diff --git a/MAINTAINERS b/MAINTAINERS index fa45ff36fde9..1574ad6d7ead 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2204,6 +2204,7 @@ S:Supported F:Documentation/devicetree/bindings/arm/ti/k3.txt F:arch/arm64/boot/dts/ti/Makefile F:arch/arm64/boot/dts/ti/k3-* +F: include/dt-bindings/pinctrl/k3.h ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE M:Santosh Shilimkar diff --git a/include/dt-bindings/pinctrl/k3.h b/include/dt-bindings/pinctrl/k3.h new file mode 100644 index ..463d845a9b36 --- /dev/null +++ b/include/dt-bindings/pinctrl/k3.h @@ -0,0 +1,35 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * This header provides constants for pinctrl bindings for TI's K3 SoC + * family. + * + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ + */ +#ifndef _DT_BINDINGS_PINCTRL_TI_K3_H +#define _DT_BINDINGS_PINCTRL_TI_K3_H + +#define PULLUDEN_SHIFT (16) +#define PULLTYPESEL_SHIFT (17) +#define RXACTIVE_SHIFT (18) + +#define PULL_DISABLE (1 << PULLUDEN_SHIFT) +#define PULL_ENABLE(0 << PULLUDEN_SHIFT) + +#define PULL_UP(1 << PULLTYPESEL_SHIFT | PULL_ENABLE) +#define PULL_DOWN (0 << PULLTYPESEL_SHIFT | PULL_ENABLE) + +#define INPUT_EN (1 << RXACTIVE_SHIFT) +#define INPUT_DISABLE (0 << RXACTIVE_SHIFT) + +/* Only these macros are expected be used directly in device tree files */ +#define PIN_OUTPUT (INPUT_DISABLE | PULL_DISABLE) +#define PIN_OUTPUT_PULLUP (INPUT_DISABLE | PULL_UP) +#define PIN_OUTPUT_PULLDOWN(INPUT_DISABLE | PULL_DOWN) +#define PIN_INPUT (INPUT_EN | PULL_DISABLE) +#define PIN_INPUT_PULLUP (INPUT_EN | PULL_UP) +#define PIN_INPUT_PULLDOWN (INPUT_EN | PULL_DOWN) Thanks for reducing the combinations down to the minimum needed. We can worry about the DS and isolation bits when we have a real user for them. Acked-by: Nishanth Menon Tero: v4.21-rc1 perhaps ? Yeah, looks fine, queueing up for 4.21. -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] arm64: dts: k3-am65-wakeup: Fix wakeup_uart reg address
On 07/11/2018 23:00, Nishanth Menon wrote:
On 10:10-20181005, Vutla, Lokesh wrote:
On Thursday 27 September 2018 10:31 AM, Vignesh R wrote:
cbass_wakeup interconnect which is the parent of wakeup_uart node
defines address-cells=1 and size-cells=1, therefore fix up reg property
of wakeup_uart node accordingly. Otherwise, this UART instance fails to
probe if enabled.
Fixes: 4201af2544b3 ("arm64: dts: ti: am654: Add uart nodes")
Signed-off-by: Vignesh R
Reviewed-by: Lokesh Vutla
Tero:
Could we pick this up for rc2? looks like $subject might be good to fix
up to:
arm64: dts: ti: k3-am65-wakeup: Fix wakeup_uart reg address
instead of
arm64: dts: k3-am65-wakeup: Fix wakeup_uart reg address
could be fixed locally.
Thanks, queued up for 4.20-rc.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 2/4] clk: clk: Add clk_dflt_restore
On 19/06/18 07:28, Keerthy wrote:
The default restore context function enables or disables
the clock based on the enable_count. This is done in cases
where the clock context is lost and based on the enable_count
the clock either needs to be enabled/disabled. This particularly
helps restore the state of gate clocks.
Signed-off-by: Keerthy
---
drivers/clk/clk.c| 19 +++
include/linux/clk-provider.h | 2 ++
2 files changed, 21 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 7347e06..c201b8b 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -910,6 +910,25 @@ static int clk_core_enable_lock(struct clk_core *core)
return ret;
}
+/**
+ * clk_dflt_restore_context - restore context for poweroff
+ * @hw: the clk_hw pointer of clock whose state is to be restored
+ *
+ * The default restore context function enables or disables
+ * the clock based on the enable_count. This is done in cases
+ * where the clock context is lost and based on the enable_count
+ * the clock either needs to be enabled/disabled. This particularly
+ * helps restore the state of gate clocks.
+ */
+void clk_dflt_restore_context(struct clk_hw *hw)
I think the name of this function is wrong, it should be
clk_gate_restore_context, as only gate clocks are ever going to be using
this afaics.
-Tero
+{
+ if (hw->clk->core->enable_count)
+ hw->clk->core->ops->enable(hw);
+ else
+ hw->clk->core->ops->disable(hw);
+}
+EXPORT_SYMBOL_GPL(clk_dflt_restore_context);
+
static int _clk_save_context(struct clk_core *clk)
{
struct clk_core *child;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7f30d62..3e0c61a 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -992,5 +992,7 @@ static inline void clk_writel(u32 val, u32 __iomem *reg)
#endif /* platform dependent I/O accessors */
+void clk_dflt_restore_context(struct clk_hw *hw);
+
#endif /* CONFIG_COMMON_CLK */
#endif /* CLK_PROVIDER_H */
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
On 30/05/18 17:50, Tony Lindgren wrote:
* Faiz Abbas [180530 14:12]:
From: Lokesh Vutla
Add MCAN hwmod data and register it for dra762 silicons.
Signed-off-by: Lokesh Vutla
Signed-off-by: Faiz Abbas
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 32 +++
1 file changed, 32 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 62352d1e6361..a2cd7f865a60 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1355,6 +1355,29 @@ static struct omap_hwmod dra7xx_mailbox13_hwmod = {
},
};
+/*
+ * 'mcan' class
+ *
+ */
+static struct omap_hwmod_class dra76x_mcan_hwmod_class = {
+ .name = "mcan",
+};
+
+/* mcan */
+static struct omap_hwmod dra76x_mcan_hwmod = {
+ .name = "mcan",
+ .class = &dra76x_mcan_hwmod_class,
+ .clkdm_name = "wkupaon_clkdm",
+ .main_clk = "mcan_clk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_WKUPAON_ADC_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_WKUPAON_ADC_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
You should be now able to leave out at least the clkctrl_offs and modulemode
here. Please also check if leaving out clkdm_name and main_clk now works :)
@@ -3818,6 +3841,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per2__epwmss2
= {
.user = OCP_USER_MPU,
};
+/* l3_main_1 -> mcan */
+static struct omap_hwmod_ocp_if dra76x_l3_main_1__mcan = {
+ .master = &dra7xx_l3_main_1_hwmod,
+ .slave = &dra76x_mcan_hwmod,
+ .clk= "l3_iclk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
I think this we still need though for the clk. Tero, do you have any comments
on what all clocks can now be left out?
For the OCP if part, I think that is still needed until we switch over
to full sysc driver. clkctrl_offs you probably also need because that is
used for mapping the omap_hwmod against a specific clkctrl clock. Those
can be only removed once we are done with hwmod (or figure out some
other way to assign the clkctrl clock to a hwmod.)
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
On 30/05/18 18:28, Tony Lindgren wrote:
* Tero Kristo [180530 15:18]:
For the OCP if part, I think that is still needed until we switch over to
full sysc driver. clkctrl_offs you probably also need because that is used
for mapping the omap_hwmod against a specific clkctrl clock. Those can be
only removed once we are done with hwmod (or figure out some other way to
assign the clkctrl clock to a hwmod.)
Hmm might be worth testing. I thought your commit 70f05be32133
("ARM: OMAP2+: hwmod: populate clkctrl clocks for hwmods if available")
already parses the clkctrl from dts?
It maps the clkctrl clock to be used by hwmod, if those are available.
We didn't add any specific clock entries to DT for mapping the actual
clkctrl clock without the hwmod_data hints yet though, as that was
deemed temporary solution only due to transition to interconnect driver.
I.e., you would need something like this in DT for every device node:
&uart3 {
clocks = ;
clock-names = "clkctrl";
};
... which is currently not present.
Alternatively you could rename the main_clk in the hwmod_data to point
towards the clkctrl clock, but again, that would be a temporary solution
only.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
On 30/05/18 18:54, Tony Lindgren wrote:
* Tero Kristo [180530 15:44]:
On 30/05/18 18:28, Tony Lindgren wrote:
* Tero Kristo [180530 15:18]:
For the OCP if part, I think that is still needed until we switch over to
full sysc driver. clkctrl_offs you probably also need because that is used
for mapping the omap_hwmod against a specific clkctrl clock. Those can be
only removed once we are done with hwmod (or figure out some other way to
assign the clkctrl clock to a hwmod.)
Hmm might be worth testing. I thought your commit 70f05be32133
("ARM: OMAP2+: hwmod: populate clkctrl clocks for hwmods if available")
already parses the clkctrl from dts?
It maps the clkctrl clock to be used by hwmod, if those are available. We
didn't add any specific clock entries to DT for mapping the actual clkctrl
clock without the hwmod_data hints yet though, as that was deemed temporary
solution only due to transition to interconnect driver. I.e., you would need
something like this in DT for every device node:
&uart3 {
clocks = ;
clock-names = "clkctrl";
};
... which is currently not present.
Hmm is that not the "fck" clkctrl clock we have already in
the dts files for the interconnect target modules?
Oh okay, yeah, we could parse that one, but currently it is not done,
and is not present for everything either I believe.
We can also use pdata callbacks to pass the clock node if
needed. But I guess I don't quite still understand what we
are missing :)
So, what is missing is the glue logic only from the hwmod codebase.
Right now this is not supported but should be relatively trivial thing
to add if we really want to do this.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 3/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
On 31/05/18 13:14, Faiz Abbas wrote: Hi, On Thursday 31 May 2018 09:33 AM, Rob Herring wrote: On Wed, May 30, 2018 at 07:41:30PM +0530, Faiz Abbas wrote: Add clkctrl data for the m_can clocks and register it within the ... diff --git a/include/dt-bindings/clock/dra7.h b/include/dt-bindings/clock/dra7.h index 5e1061b15aed..d7549c57cac3 100644 --- a/include/dt-bindings/clock/dra7.h +++ b/include/dt-bindings/clock/dra7.h @@ -168,5 +168,6 @@ #define DRA7_COUNTER_32K_CLKCTRL DRA7_CLKCTRL_INDEX(0x50) #define DRA7_UART10_CLKCTRL DRA7_CLKCTRL_INDEX(0x80) #define DRA7_DCAN1_CLKCTRLDRA7_CLKCTRL_INDEX(0x88) +#define DRA7_ADC_CLKCTRL DRA7_CLKCTRL_INDEX(0xa0) ADC and mcan are the same thing? The register to control MCAN clocks is called ADC_CLKCTRL, Yes. Is there any reason for this or is that just a documentation bug? -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 1/2] arm64: dts: ti: k3-am654: Add McSPI DT nodes
On 09/12/2018 12:22, Vignesh R wrote:
There are 3 instances of McSPI in MCU domain and 4 instances in Main domain.
Add DT nodes for all McSPI instances present on AM654 SoC.
Signed-off-by: Vignesh R
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 52
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 30 ++
2 files changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 0a0a8fc5df64..6c71e67b8988 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -138,4 +138,56 @@
clocks = <&k3_clks 39 0>;
clock-names = "fck";
};
+
+ main_spi0: spi@210 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
WARNING: DT compatible string "ti,am654-mcspi" appears un-documented --
check ../../Documentation/devicetree/bindings/
#63: FILE: arch/arm64/boot/dts/ti/k3-am65-main.dtsi:143:
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
Same for the rest of the nodes.
Did you forget documentation part?
-Tero
+ reg = <0x0 0x210 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 137 1>;
+ power-domains = <&k3_pds 137>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ main_spi1: spi@211 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x211 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 138 1>;
+ power-domains = <&k3_pds 138>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ assigned-clocks = <&k3_clks 137 1>;
+ assigned-clock-rates = <4800>;
+ };
+
+ main_spi2: spi@212 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x212 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 139 1>;
+ power-domains = <&k3_pds 139>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ main_spi3: spi@213 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x213 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 140 1>;
+ power-domains = <&k3_pds 140>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ main_spi4: spi@214 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x214 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 141 1>;
+ power-domains = <&k3_pds 141>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index 1fd027748e1f..1aeae52fb239 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -26,4 +26,34 @@
clocks = <&k3_clks 114 1>;
power-domains = <&k3_pds 114>;
};
+
+ mcu_spi0: spi@4030 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x4030 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 142 1>;
+ power-domains = <&k3_pds 142>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mcu_spi1: spi@4031 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x4031 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 143 1>;
+ power-domains = <&k3_pds 143>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mcu_spi2: spi@4032 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x4032 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 144 1>;
+ power-domains = <&k3_pds 144>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 1/2] arm64: dts: ti: k3-am654: Add McSPI DT nodes
On 13/12/2018 17:03, Vignesh R wrote:
On 13-Dec-18 8:29 PM, Tero Kristo wrote:
On 09/12/2018 12:22, Vignesh R wrote:
There are 3 instances of McSPI in MCU domain and 4 instances in Main
domain.
Add DT nodes for all McSPI instances present on AM654 SoC.
Signed-off-by: Vignesh R
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 52
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 30 ++
2 files changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 0a0a8fc5df64..6c71e67b8988 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -138,4 +138,56 @@
clocks = <&k3_clks 39 0>;
clock-names = "fck";
};
+
+ main_spi0: spi@210 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
WARNING: DT compatible string "ti,am654-mcspi" appears un-documented --
check ../../Documentation/devicetree/bindings/
#63: FILE: arch/arm64/boot/dts/ti/k3-am65-main.dtsi:143:
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
Same for the rest of the nodes.
Did you forget documentation part?
Documentation patch as been accepted into SPI tree and part of linux-next:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=abc61f47a70f7c8331f00eff1ccb6557a9d4c224
Ok thanks for the info.
-Tero
Regards
Vignesh
-Tero
+ reg = <0x0 0x210 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 137 1>;
+ power-domains = <&k3_pds 137>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ main_spi1: spi@211 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x211 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 138 1>;
+ power-domains = <&k3_pds 138>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ assigned-clocks = <&k3_clks 137 1>;
+ assigned-clock-rates = <4800>;
+ };
+
+ main_spi2: spi@212 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x212 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 139 1>;
+ power-domains = <&k3_pds 139>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ main_spi3: spi@213 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x213 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 140 1>;
+ power-domains = <&k3_pds 140>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ main_spi4: spi@214 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x214 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 141 1>;
+ power-domains = <&k3_pds 141>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index 1fd027748e1f..1aeae52fb239 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -26,4 +26,34 @@
clocks = <&k3_clks 114 1>;
power-domains = <&k3_pds 114>;
};
+
+ mcu_spi0: spi@4030 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x4030 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 142 1>;
+ power-domains = <&k3_pds 142>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mcu_spi1: spi@4031 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x4031 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 143 1>;
+ power-domains = <&k3_pds 143>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mcu_spi2: spi@4032 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x0 0x4032 0x0 0x400>;
+ interrupts = ;
+ clocks = <&k3_clks 144 1>;
+ power-domains = <&k3_pds 144>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
--
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 2/3] clk: ti: check clock type before doing autoidle ops
On 28/12/2018 22:02, Tony Lindgren wrote: * Andreas Kemnade [181227 20:13]: Hi, On Tue, 4 Dec 2018 08:45:57 -0800 Tony Lindgren wrote: * Andreas Kemnade [181204 06:17]: On Mon, 3 Dec 2018 07:39:10 -0800 Tony Lindgren wrote: The consumer device stays active just fine with PM runtime calls. So yes, the problem is keeping a clock controller forced active for the period of consumer device reset. Other than that typically autoidle can be just kept enabled. Are we still talking about the same problem? Maybe I am losing track here. Just to make sure. The patch series was about disabling autoidle for devices which cannot work with it during normal operation. Not during reset or something like that. Or is the keep-clock-active-during-reset just a requirement for bigger restructuring ideas? Yeah there are two issues: The fix needed for the issue you brought up, and also how to let a reset driver to block autoidle for reset. Hmm, is this set now waiting for the famous "somebody" fixing all the stuff? Well I think we're still waiting on Tero to comment on this. The only item requiring immediate fixing is the point Stephen made out, removing the usage of CLK_IS_BASIC from this patch. Afaics, the reset related concerns Tony has can be handled later. -Tero What are currently visible symptoms for the driver not blocking autoidle for reset? Maybe I can at least test something there. I have also omap5 here. Oh that's just for making drivers/reset drivers to work in the long run. Let's keep that separate from these fixes.. Regards, Tony -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 2/3] clk: ti: check clock type before doing autoidle ops
On 04/01/2019 01:39, Stephen Boyd wrote: Quoting Andreas Kemnade (2018-12-31 00:30:21) On Mon, 31 Dec 2018 09:23:01 +0200 Tero Kristo wrote: On 28/12/2018 22:02, Tony Lindgren wrote: * Andreas Kemnade [181227 20:13]: Hi, On Tue, 4 Dec 2018 08:45:57 -0800 Tony Lindgren wrote: * Andreas Kemnade [181204 06:17]: On Mon, 3 Dec 2018 07:39:10 -0800 Tony Lindgren wrote: The consumer device stays active just fine with PM runtime calls. So yes, the problem is keeping a clock controller forced active for the period of consumer device reset. Other than that typically autoidle can be just kept enabled. Are we still talking about the same problem? Maybe I am losing track here. Just to make sure. The patch series was about disabling autoidle for devices which cannot work with it during normal operation. Not during reset or something like that. Or is the keep-clock-active-during-reset just a requirement for bigger restructuring ideas? Yeah there are two issues: The fix needed for the issue you brought up, and also how to let a reset driver to block autoidle for reset. Hmm, is this set now waiting for the famous "somebody" fixing all the stuff? Well I think we're still waiting on Tero to comment on this. The only item requiring immediate fixing is the point Stephen made out, removing the usage of CLK_IS_BASIC from this patch. Afaics, the reset related concerns Tony has can be handled later. hmm, and there we need Stephen's opinion about having the allow/deny autoidle functions in the main clk_ops struct. I have unanswered questions on the list for this thread[1]. The reset portion we can't answer with the current knowledge I fear, we need to prototype this a bit first and see which way to go. I'm not sure what allow/deny autoidle functions mean to clk drivers. It looks like an OMAP specific addition to the clk_ops struct, which sounds wrong to put it plainly. Yeah, I don't think other SoCs implement the same functionality, at least not in the same way. The autoidle bits are available in omap2/omap3 only, where they control the HW autoidle functionality of these clocks. If the bit is enabled, the HW can autonomously disable the clock once it is not needed anymore by HW. Hopefully it can be done outside of the clk framework by having the provider driver know more things about all the frameworks it's hooking into. This is how it has been done so far, however Andreas wants to expand the functionality a bit where it breaks... unless we can use the CLK_IS_BASIC flag to detect if we accessing an OMAP specific clock or not. If we are passing in a clk pointer from a consumer level API, I don't know if there is any other way to go with this if we can't modify the generic clk_ops struct. The same flag check is used across TI clock driver already btw. -Tero [1] https://lkml.kernel.org/r/154385676593.88331.5239924154783168...@swboyd.mtv.corp.google.com -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 2/2] arm: omap_hwmod disable ick autoidling when a hwmod requires that
On 04/10/2018 23:38, Andreas Kemnade wrote:
Deny autoidle for hwmods with the OCPIF_SWSUP_IDLE flag,
that makes hwmods working properly which cannot handle
autoidle properly in lower power states.
Affected is e. g. the omap_hdq.
Since an ick might have mulitple users, autoidle is disabled
when an individual user requires that rather than in
_setup_iclk_autoidle. dss_ick is an example for that.
Signed-off-by: Andreas Kemnade
---
arch/arm/mach-omap2/omap_hwmod.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index bb641e6c93d0..0078b0e1d242 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -986,8 +986,10 @@ static int _enable_clocks(struct omap_hwmod *oh)
clk_enable(oh->_clk);
list_for_each_entry(os, &oh->slave_ports, node) {
- if (os->_clk && (os->flags & OCPIF_SWSUP_IDLE))
+ if (os->_clk && (os->flags & OCPIF_SWSUP_IDLE)) {
+ omap2_clk_deny_idle(os->_clk);
I think calling this unconditionally across all platforms / clock types
might cause problems. Checking kernel, am33xx seems to have one clock
with this flag that is not of omap2 type. Do we have any testing data
that this doesn't break things?
-Tero
clk_enable(os->_clk);
+ }
}
/* The opt clocks are controlled by the device driver. */
@@ -1039,8 +1041,10 @@ static int _disable_clocks(struct omap_hwmod *oh)
clk_disable(oh->_clk);
list_for_each_entry(os, &oh->slave_ports, node) {
- if (os->_clk && (os->flags & OCPIF_SWSUP_IDLE))
+ if (os->_clk && (os->flags & OCPIF_SWSUP_IDLE)) {
clk_disable(os->_clk);
+ omap2_clk_allow_idle(os->_clk);
+ }
}
if (oh->flags & HWMOD_OPT_CLKS_NEEDED)
@@ -2410,9 +2414,13 @@ static void __init _setup_iclk_autoidle(struct
omap_hwmod *oh)
continue;
if (os->flags & OCPIF_SWSUP_IDLE) {
- /* XXX omap_iclk_deny_idle(c); */
+ /*
+* we might have multiple users of one iclk with
+* different requirements, disable autoidle when
+* the module is enabled, e.g. dss iclk
+*/
} else {
- /* XXX omap_iclk_allow_idle(c); */
+ /* we are enabling autoidle afterwards anyways */
clk_enable(os->_clk);
> }
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 1/2] clk: ti: add a usecount for autoidle
On 04/10/2018 23:38, Andreas Kemnade wrote:
We have the scenario that first autoidle is disabled for all clocks,
then it is disabled for selected ones and then enabled for all. So
we should have some counting here, also according to the
comment in _setup_iclk_autoidle()
Signed-off-by: Andreas Kemnade
---
drivers/clk/ti/autoidle.c | 32
include/linux/clk/ti.h| 1 +
2 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/ti/autoidle.c b/drivers/clk/ti/autoidle.c
index 7bb9afbe4058..bb6cff168e73 100644
--- a/drivers/clk/ti/autoidle.c
+++ b/drivers/clk/ti/autoidle.c
@@ -37,6 +37,14 @@ struct clk_ti_autoidle {
static LIST_HEAD(autoidle_clks);
static LIST_HEAD(clk_hw_omap_clocks);
+/*
+ * we have some non-atomic read/write
+ * operations behind it, so lets
+ * take one mutex for handling autoidle
+ * of all clocks
+ */
+static DEFINE_MUTEX(autoidle_mutex);
Why mutex? This prevents calling the autoidle APIs from atomic context.
Did you check the mutex debug kernel configs with this?
This may cause problems with the runtime PM entries to the code at least.
+
/**
* omap2_clk_deny_idle - disable autoidle on an OMAP clock
* @clk: struct clk * to disable autoidle for
@@ -48,8 +56,13 @@ int omap2_clk_deny_idle(struct clk *clk)
struct clk_hw_omap *c;
c = to_clk_hw_omap(__clk_get_hw(clk));
- if (c->ops && c->ops->deny_idle)
- c->ops->deny_idle(c);
+ if (c->ops && c->ops->deny_idle) {
+ mutex_lock(&autoidle_mutex);
+ c->autoidle_count--;
+ if (c->autoidle_count == -1)
I think you should swap the arithmetics here, all the other usecounters
use positive values, here you enter deep to the negative side when
autoidle is denied by multiple users, which might be confusing.
-Tero
+ c->ops->deny_idle(c);
+ mutex_unlock(&autoidle_mutex);
+ }
return 0;
}
@@ -64,8 +77,13 @@ int omap2_clk_allow_idle(struct clk *clk)
struct clk_hw_omap *c;
c = to_clk_hw_omap(__clk_get_hw(clk));
- if (c->ops && c->ops->allow_idle)
- c->ops->allow_idle(c);
+ if (c->ops && c->ops->allow_idle) {
+ mutex_lock(&autoidle_mutex);
+ c->autoidle_count++;
+ if (c->autoidle_count == 0)
+ c->ops->allow_idle(c);
+ mutex_unlock(&autoidle_mutex);
+ }
return 0;
}
@@ -201,8 +219,7 @@ int omap2_clk_enable_autoidle_all(void)
struct clk_hw_omap *c;
list_for_each_entry(c, &clk_hw_omap_clocks, node)
- if (c->ops && c->ops->allow_idle)
- c->ops->allow_idle(c);
+ omap2_clk_allow_idle(c->hw.clk);
_clk_generic_allow_autoidle_all();
@@ -223,8 +240,7 @@ int omap2_clk_disable_autoidle_all(void)
struct clk_hw_omap *c;
list_for_each_entry(c, &clk_hw_omap_clocks, node)
- if (c->ops && c->ops->deny_idle)
- c->ops->deny_idle(c);
+ omap2_clk_deny_idle(c->hw.clk);
_clk_generic_deny_autoidle_all();
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index a8faa38b1ed6..c460355419c0 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -159,6 +159,7 @@ struct clk_hw_omap {
const char *clkdm_name;
struct clockdomain *clkdm;
const struct clk_hw_omap_ops*ops;
+ int autoidle_count;
};
/*
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 2/2] arm: omap_hwmod disable ick autoidling when a hwmod requires that
On 08/11/2018 13:08, Andreas Kemnade wrote:
Hi,
On Thu, 8 Nov 2018 12:26:08 +0200
Tero Kristo wrote:
On 04/10/2018 23:38, Andreas Kemnade wrote:
Deny autoidle for hwmods with the OCPIF_SWSUP_IDLE flag,
that makes hwmods working properly which cannot handle
autoidle properly in lower power states.
Affected is e. g. the omap_hdq.
Since an ick might have mulitple users, autoidle is disabled
when an individual user requires that rather than in
_setup_iclk_autoidle. dss_ick is an example for that.
Signed-off-by: Andreas Kemnade
---
arch/arm/mach-omap2/omap_hwmod.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index bb641e6c93d0..0078b0e1d242 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -986,8 +986,10 @@ static int _enable_clocks(struct omap_hwmod *oh)
clk_enable(oh->_clk);
list_for_each_entry(os, &oh->slave_ports, node) {
- if (os->_clk && (os->flags & OCPIF_SWSUP_IDLE))
+ if (os->_clk && (os->flags & OCPIF_SWSUP_IDLE)) {
+ omap2_clk_deny_idle(os->_clk);
I think calling this unconditionally across all platforms / clock types
might cause problems. Checking kernel, am33xx seems to have one clock
with this flag that is not of omap2 type. Do we have any testing data
that this doesn't break things?
Somehow I have missed that am33xx clock. I have not tested it on that
platform. Concerning am3xxx I have only a beaglebone block but it not
am33xx I guess. So I have to recheck I guess.
Beaglebone black is am33xx based device, so you can use that for testing.
But I think the intention of this flag was to control autoidle
vs. sw-controlled idle according to...
[...]
if (os->flags & OCPIF_SWSUP_IDLE) {
- /* XXX omap_iclk_deny_idle(c); */
+ /*
this comment. So we need a if (clock_is_omap2()) or something like that
or remove that flag from any other clocks?
You could add check within the omap2_clk_deny_idle / allow_idle calls
themselves. You can check for presence of flag CLK_IS_BASIC, this is not
set for omap clocks.
-Tero
Regards,
Andreas
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH RFC 1/2] clk: ti: add a usecount for autoidle
On 04/10/18 08:51, Andreas Kemnade wrote:
We have the scenario that first autoidle is disabled for all clocks,
then it is disabled for selected ones and then enabled for all. So
we should have some counting here, also according to the
comment in _setup_iclk_autoidle()
Signed-off-by: Andreas Kemnade
---
drivers/clk/ti/autoidle.c | 20
include/linux/clk/ti.h| 1 +
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/ti/autoidle.c b/drivers/clk/ti/autoidle.c
index 7bb9afbe4058..be2ce42e4f33 100644
--- a/drivers/clk/ti/autoidle.c
+++ b/drivers/clk/ti/autoidle.c
@@ -48,8 +48,11 @@ int omap2_clk_deny_idle(struct clk *clk)
struct clk_hw_omap *c;
c = to_clk_hw_omap(__clk_get_hw(clk));
- if (c->ops && c->ops->deny_idle)
- c->ops->deny_idle(c);
+ if (c->ops && c->ops->deny_idle) {
+ c->autoidle_count--;
+ if (c->autoidle_count == -1)
+ c->ops->deny_idle(c);
This code is racy as you have no locking in place. Please fix.
Also, this should be verified that it doesn't cause any PM regressions,
I hope you have done that?
-Tero
+ }
return 0;
}
@@ -64,8 +67,11 @@ int omap2_clk_allow_idle(struct clk *clk)
struct clk_hw_omap *c;
c = to_clk_hw_omap(__clk_get_hw(clk));
- if (c->ops && c->ops->allow_idle)
- c->ops->allow_idle(c);
+ if (c->ops && c->ops->allow_idle) {
+ c->autoidle_count++;
+ if (c->autoidle_count == 0)
+ c->ops->allow_idle(c);
+ }
return 0;
}
@@ -201,8 +207,7 @@ int omap2_clk_enable_autoidle_all(void)
struct clk_hw_omap *c;
list_for_each_entry(c, &clk_hw_omap_clocks, node)
- if (c->ops && c->ops->allow_idle)
- c->ops->allow_idle(c);
+ omap2_clk_allow_idle(c->hw.clk);
_clk_generic_allow_autoidle_all();
@@ -223,8 +228,7 @@ int omap2_clk_disable_autoidle_all(void)
struct clk_hw_omap *c;
list_for_each_entry(c, &clk_hw_omap_clocks, node)
- if (c->ops && c->ops->deny_idle)
- c->ops->deny_idle(c);
+ omap2_clk_deny_idle(c->hw.clk);
_clk_generic_deny_autoidle_all();
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index a8faa38b1ed6..c460355419c0 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -159,6 +159,7 @@ struct clk_hw_omap {
const char *clkdm_name;
struct clockdomain *clkdm;
const struct clk_hw_omap_ops*ops;
+ int autoidle_count;
};
/*
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH RFC 0/2] mach-omap2: handle autoidle denial
On 04/10/18 17:25, Tony Lindgren wrote: * Andreas Kemnade [181004 05:56]: On the gta04 with a dm3730 omap_hdq does not work properly when the device enters lower power states. Idling uart1 and 2 is enough to show up that problem, if there are no other things enabled. Further research reveals that hdq iclk must not be turned off during transfers, also according to the TRM. That fact is also correctly described in the flags but the code to handle that is incomplete. Since the order is first disable all autoidles, then disable selected and then enable all, we need to either change that order or add a usecount. Since it is done only in init, we could think about changing order. These patches look OK to me, assuming Tero will review them more closely. There is no locking whatsoever in the autoidle counting atm, that must be fixed otherwise you get races. It seems we should just provide a generic interface for clk_allow_autoidle() and clk_deny_autoidle()? Otherwise we'll be forever stuck with pdata callbacks it seems. The TI clock driver is actually providing these APIs, so that should be fine. I don't think there is any use / need for pdata callbacks atm, it just happens hwmod core is calling these at the moment which might have confused you. -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH RFC 0/2] mach-omap2: handle autoidle denial
On 04/10/18 18:07, Tony Lindgren wrote: * Tero Kristo [181004 14:47]: On 04/10/18 17:25, Tony Lindgren wrote: It seems we should just provide a generic interface for clk_allow_autoidle() and clk_deny_autoidle()? Otherwise we'll be forever stuck with pdata callbacks it seems. The TI clock driver is actually providing these APIs, so that should be fine. I don't think there is any use / need for pdata callbacks atm, it just happens hwmod core is calling these at the moment which might have confused you. Hmm OK. So do we already have some way to deny autoidle for a clock from ti-sysc.c driver without pdata callbacks? Suman pointed out few days ago that for a reset driver to work we must do clkdm_deny_idle() and clkdm_allow_idle() as the hwmod code does. I gues that really just boils down to doing clk deny idle and allow idle on the clockdomain clkctrl clock? Clkdm handling is done via pdata callbacks, that is a separate topic from iclk autoidle. Iclk:s are effectively only for omap3, clkdm autoidle / deny_idle etc. are a generic mechanism that must be used on omap4+ if you want to prevent autoidle of certain domains/IPs. -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH] tracing/synthetic: Print out u64 values properly
The synth traces incorrectly print pointer to the synthetic event values
instead of the actual value when using u64 type. Fix by addressing the
contents of the union properly.
Fixes: ddeea494a16f ("tracing/synthetic: Use union instead of casts")
Cc: sta...@vger.kernel.org
Signed-off-by: Tero Kristo
---
kernel/trace/trace_events_synth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events_synth.c
b/kernel/trace/trace_events_synth.c
index 7fff8235075f..070365959c0a 100644
--- a/kernel/trace/trace_events_synth.c
+++ b/kernel/trace/trace_events_synth.c
@@ -337,7 +337,7 @@ static void print_synth_event_num_val(struct trace_seq *s,
break;
default:
- trace_seq_printf(s, print_fmt, name, val, space);
+ trace_seq_printf(s, print_fmt, name, val->as_u64, space);
break;
}
}
--
2.40.1
Re: [PATCH] tracing/synthetic: Print out u64 values properly
Hi Masami,
On 15/09/2023 09:01, Masami Hiramatsu (Google) wrote:
Hi Tero,
On Mon, 11 Sep 2023 17:17:04 +0300
Tero Kristo wrote:
The synth traces incorrectly print pointer to the synthetic event values
instead of the actual value when using u64 type. Fix by addressing the
contents of the union properly.
Thanks for pointing it out.
But I would like to see a new "case 8:" print code instead of changing
"default". Can you keep the default as it is and add "case 8:" case there?
Are you sure about that? I think keeping the default as is would just
print out a useless pointer value to the synth event itself (which is
what happened with u64 type.)
Anyways, that requires a new patch to be created on top as this has hit
the mainline as a fix already.
-Tero
Thanks,
Fixes: ddeea494a16f ("tracing/synthetic: Use union instead of casts")
Cc: sta...@vger.kernel.org
Signed-off-by: Tero Kristo
---
kernel/trace/trace_events_synth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events_synth.c
b/kernel/trace/trace_events_synth.c
index 7fff8235075f..070365959c0a 100644
--- a/kernel/trace/trace_events_synth.c
+++ b/kernel/trace/trace_events_synth.c
@@ -337,7 +337,7 @@ static void print_synth_event_num_val(struct trace_seq *s,
break;
default:
- trace_seq_printf(s, print_fmt, name, val, space);
+ trace_seq_printf(s, print_fmt, name, val->as_u64, space);
break;
}
}
--
2.40.1
Re: [PATCH 1/3] ARM: dts: OMAP5+: separate the cpu thermal zone definition from omap4
On 03/20/2015 11:54 PM, Eduardo Valentin wrote:
On Fri, Mar 20, 2015 at 02:47:39PM -0500, Nishanth Menon wrote:
From: Tero Kristo
OMAP4 has a finer counter granularity, which allows for a delay of 1000ms
in the thermal zone polling intervals. OMAP5/DRA7 have different counter
mechanism, which allows at maximum a 500ms timer. Adjust the cpu thermal
zone accordingly for OMAP5/DRA7.
Signed-off-by: Tero Kristo
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/omap5-cpu-thermal.dtsi | 41 ++
arch/arm/boot/dts/omap5.dtsi |2 +-
2 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/omap5-cpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap5-cpu-thermal.dtsi
b/arch/arm/boot/dts/omap5-cpu-thermal.dtsi
new file mode 100644
index ..4a6427c1e47e
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-cpu-thermal.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Device Tree Source for OMAP4/5 SoC CPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Tero Kristo
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+
+cpu_thermal: cpu_thermal {
+ polling-delay-passive = <250>; /* milliseconds */
+ polling-delay = <500>; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = <&bandgap 0>;
+
+ cpu_trips: trips {
+ cpu_alert0: cpu_alert {
+ temperature = <10>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+ cpu_crit: cpu_crit {
+ temperature = <125000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cpu_cooling_maps: cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ cooling-device =
+ <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index ddff674bd05e..e650d4eb59dd 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -67,7 +67,7 @@
};
thermal-zones {
- #include "omap4-cpu-thermal.dtsi"
+ #include "omap5-cpu-thermal.dtsi"
Can't we simple change the polling value for the omap5 case and reuse
the omap4 file?
Hmm yea, I posted a patch like this before for o5 and it was queued
already. See:
http://thread.gmane.org/gmane.linux.ports.arm.omap/123729
The dra7 part was missing from this set though, so patches 2/3 do not
directly work with that one and will require some changes similar to the
linked omap4 one.
-Tero
#include "omap5-gpu-thermal.dtsi"
#include "omap5-core-thermal.dtsi"
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AM335x OMAP2 common clock external fixed-clock registration
On 04/15/2015 12:17 AM, Michael Welling wrote: Greetings, I have developed an AM3354 based SoM and it uses an external SI5351 clock generator to drive the clock inputs for an external duart and I2S audio master clock. With the registration according to the documentation the reference clock is not being detected and hence the clock generator is not working as expect. After trying many different things, I started to look around the mailing lists to find information related to this issue. I came acrossed post that has the exact same issue: https://lkml.org/lkml/2013/2/18/468 Seeing as the patch did not land upstream, I am wondering if there is a solution that I am not seeing. I am willing to provide a patch given appropriate guidance. Hi Michael, The info on the email you referenced is kind of obsolete, TI SoCs are calling of_clk_init() during boot now, and thus external clock nodes should be registered fine also. Maybe you can provide the actual DTS patch you are trying out so we can help better...? Are you seeing any boot time error / warning prints for your new clock? -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AM335x OMAP2 common clock external fixed-clock registration
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351 clock
generator to drive the clock inputs for an external duart and I2S audio
master clock. With the registration according to the documentation the
reference clock is not being detected and hence the clock generator is
not working as expect.
After trying many different things, I started to look around the mailing
lists to find information related to this issue.
I came acrossed post that has the exact same issue:
https://lkml.org/lkml/2013/2/18/468
Seeing as the patch did not land upstream, I am wondering if there is
a solution that I am not seeing.
I am willing to provide a patch given appropriate guidance.
Hi Michael,
The info on the email you referenced is kind of obsolete, TI SoCs
are calling of_clk_init() during boot now, and thus external clock
nodes should be registered fine also. Maybe you can provide the
actual DTS patch you are trying out so we can help better...? Are
See attached patch and console output.
I see a bug in your dt data.
+ clocks {
+ ref27: ref27 {
+ #clock-cells = <0>;
+ compatibale = "fixed-clock";
This should be compatible, right? DT is annoying in that it doesn't
verify property names.
+ clock-frequency = <2700>;
+ };
+ };
-Tero
you seeing any boot time error / warning prints for your new clock?
With the debug messages on you see that the reference clock is not being
detected.
Whilest debugging I found that the of_clk_get is returning an error no matter
which clock I pass it:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AM335x OMAP2 common clock external fixed-clock registration
On 04/15/2015 11:51 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351 clock
generator to drive the clock inputs for an external duart and I2S audio
master clock. With the registration according to the documentation the
reference clock is not being detected and hence the clock generator is
not working as expect.
After trying many different things, I started to look around the mailing
lists to find information related to this issue.
I came acrossed post that has the exact same issue:
https://lkml.org/lkml/2013/2/18/468
Seeing as the patch did not land upstream, I am wondering if there is
a solution that I am not seeing.
I am willing to provide a patch given appropriate guidance.
Hi Michael,
The info on the email you referenced is kind of obsolete, TI SoCs
are calling of_clk_init() during boot now, and thus external clock
nodes should be registered fine also. Maybe you can provide the
actual DTS patch you are trying out so we can help better...? Are
See attached patch and console output.
I see a bug in your dt data.
+ clocks {
+ ref27: ref27 {
+ #clock-cells = <0>;
+ compatibale = "fixed-clock";
This should be compatible, right? DT is annoying in that it doesn't
verify property names.
Ooops.
Now the clock appears in /sys/kernel/debug/clk:
root@som3517-som200:/sys/kernel/debug/clk# cat clk_summary
clock enable_cnt prepare_cntrate
accuracy phase
ref27002700
0 0
...
There is still an issue with the si5351.
I had to comment out the clk_put here for the frequency to show up:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133
Ideas?
What is the most recent upstream commit that you are based on?
I am working from 4.0.0-rc7.
7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab
Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get in
the first place, as far as I understand this destroys the clock handle,
which is still being used later in the code.
-Tero
Regards,
Mike
+ clock-frequency = <2700>;
+ };
+ };
-Tero
you seeing any boot time error / warning prints for your new clock?
With the debug messages on you see that the reference clock is not being
detected.
Whilest debugging I found that the of_clk_get is returning an error no matter
which clock I pass it:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AM335x OMAP2 common clock external fixed-clock registration
On 04/17/2015 05:00 AM, Michael Welling wrote: On Fri, Apr 17, 2015 at 01:23:50AM +0200, Sebastian Hesselbarth wrote: On 17.04.2015 00:09, Michael Welling wrote: On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote: On 16.04.2015 18:17, Michael Welling wrote: On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote: On 04/15/2015 11:51 PM, Michael Welling wrote: On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote: On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling wrote: [...] There is still an issue with the si5351. I had to comment out the clk_put here for the frequency to show up: http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133 Ideas? What is the most recent upstream commit that you are based on? I am working from 4.0.0-rc7. 7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get in the first place, as far as I understand this destroys the clock handle, which is still being used later in the code. Not sure how this ever worked. This has been in the code since the initial commit. The reason it worked before may be related with recent rework of clk_put() itself and clk cookies instead of pointers. I lost track on the recent clk subsystem changes here, sorry. However, droping the clk immediately surely isn't right. The thing is, we can remove the clk_put() just because there is no _remove() for that driver. I remember that back in the days the driver was mainlined, clk removal wasn't too easy. FWIW, as soon as _remove() support will be added by someone, we'll have to rethink passing struct clk* by platform_data or at least double-check if we ever used [of_]clk_get() to obtain it. Mind to send a patch removing the clk_put() on !IS_ERR and add a proper error path instead? While of_clk_get() is the only calls that need cleanup on error in si5351_dt_parse() we should probably move that calls to the end of this function. Otherwise we'd also have to cleanup on every of_parse_foo() failure. What would be the proper error path? What cleanup is required? A proper error path would be to release any claimed resource on any error. If you look at the code, the only resources that need to be released are the two clocks in question. So for every error return in the probe function and in the of si5351_dt_parse it needs to clk_put first right? See attached patch to see if we are on the same page. It should be noted that there are more deep rooted issues with the driver that I have noticed. For one the driver behaves differently if the debugging is on and when it is off. I guess you mean #define DEBUG in the driver? Yes. Here is what the kernel reports with debugging off: Do you have any measurement equipment to check what is actually set? Yes, I have an oscilloscope here at my desk. The reported numbers do not always correspond to the actual output in some cases. The ms2 output has appeared to stop working all together sometime whilest testing. I may have to solder a new chip on there. Could misconfiguration damage the chip? root@som3517-som200:~# cat /sys/kernel/debug/clk/clk_summary clock enable_cnt prepare_cntrate accuracy phase ref27002700 0 0 xtal 002700 0 0 pllb 00 59994 0 0 ms0 001249 0 0 clk0 001249 0 0 plla 00 59994 0 0 ms2 00 8219178 0 0 clk2 00 8219178 0 0 ms1 0094117646 0 0 clk1 0094117646 0 0 Here is what the kernel reports with debugging on: clock enable_cnt prepare_cntrate accuracy phase ref27002700 0 0 xtal 002700 0 0 pllb 00 884736000 0 0 ms0 0018432000 0 0 clk0 0018432000 0 0 Is this what you expect for clk0? Yes. plla 00 897023997
Re: [PATCH 1/1] add pwm capability to dm816x
On 06/15/2015 09:36 PM, Brian Hutchinson wrote:
Clocks 4-7 are capable of PWM output on dm816x.
This adds the pwm capability to those timers.
Use checkpatch pls, I see lots of whitespace errors.
Also, I don't think Mike / Stephen care about this patch, as it is
against omap hwmod data only.
-Tero
Cc: Paul Walmsley mailto:p...@pwsan.com>>
Cc: Tero Kristo mailto:t-kri...@ti.com>>
Cc: Tony Lindgren mailto:t...@atomide.com>>
Signed-off-by: Brian Hutchinson mailto:b.hutch...@gmail.com><mailto:t...@atomide.com>>
--- arch/arm/mach-omap2/omap_hwmod_81xx_data.c_orig 2015-06-15
13:20:43.174343431 -0400
+++ arch/arm/mach-omap2/omap_hwmod_81xx_data.c 2015-06-15
13:34:51.770551392 -0400
@@ -546,6 +546,14 @@ static struct omap_timer_capability_dev_
.timer_capability = OMAP_TIMER_ALWON,
};
+/* pwm timers dev attribute.
+ * timers 4-7 may be used for PWM output - see datasheet timer terminal
+ * functions table
+ */
+static struct omap_timer_capability_dev_attr capability_pwm_dev_attr = {
+ .timer_capability = OMAP_TIMER_ALWON | OMAP_TIMER_HAS_PWM,
+};
+
static struct omap_hwmod dm816x_timer1_hwmod = {
.name = "timer1",
.clkdm_name = "alwon_l3s_clkdm",
@@ -619,7 +627,7 @@ static struct omap_hwmod dm816x_timer4_h
.modulemode = MODULEMODE_SWCTRL,
},
},
- .dev_attr = &capability_alwon_dev_attr,
+ .dev_attr = &capability_pwm_dev_attr,
.class = &dm816x_timer_hwmod_class,
};
@@ -640,7 +648,7 @@ static struct omap_hwmod dm816x_timer5_h
.modulemode = MODULEMODE_SWCTRL,
},
},
- .dev_attr = &capability_alwon_dev_attr,
+ .dev_attr = &capability_pwm_dev_attr,
.class = &dm816x_timer_hwmod_class,
};
@@ -661,7 +669,7 @@ static struct omap_hwmod dm816x_timer6_h
.modulemode = MODULEMODE_SWCTRL,
},
},
- .dev_attr = &capability_alwon_dev_attr,
+ .dev_attr = &capability_pwm_dev_attr,
.class = &dm816x_timer_hwmod_class,
};
@@ -682,7 +690,7 @@ static struct omap_hwmod dm816x_timer7_h
.modulemode = MODULEMODE_SWCTRL,
},
},
- .dev_attr = &capability_alwon_dev_attr,
+ .dev_attr = &capability_pwm_dev_attr,
.class = &dm816x_timer_hwmod_class,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Add timer_32k_ck alias for dm816x in clk-816x.c
Subject should have clk: ti: in the beginning. On 06/15/2015 09:54 PM, Brian Hutchinson wrote: dm816x needs timer_32k_ck alias to use dual mode timers in dmtimers.c This adds a timer_32k_ck alias for sys_32_ck in clk-816x.c so omap_dm_timer_set_source will work for dm816x. Use checkpatch please. Or use a mailer that doesn't convert tabs to spaces. This patch seems to have something else that is strange also. Cc: Paul Walmsley mailto:p...@pwsan.com>> Cc: Tero Kristo mailto:t-kri...@ti.com>> Cc: Tony Lindgren mailto:t...@atomide.com>> Signed-off-by: Brian Hutchinson mailto:b.hutch...@gmail.com>> --- drivers/clk/ti/clk-816x.c_orig 2015-06-15 13:46:53.058128064 -0400 +++ drivers/clk/ti/clk-816x.c 2015-06-15 13:47:28.966306123 -0400 What is that _orig here? Are you using git to generate the patches? -Tero @@ -18,6 +18,7 @@ static struct ti_dt_clk dm816x_clks[] = DT_CLK(NULL, "sys_clkin", "sys_clkin_ck"), DT_CLK(NULL, "timer_sys_ck", "sys_clkin_ck"), DT_CLK(NULL, "sys_32k_ck", "sys_32k_ck"), + DT_CLK(NULL, "timer_32k_ck", "sys_32k_ck"), DT_CLK(NULL, "mpu_ck", "mpu_ck"), DT_CLK(NULL, "timer1_fck", "timer1_fck"), DT_CLK(NULL, "timer2_fck", "timer2_fck"), -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
On 06/01/2015 02:53 PM, Vignesh R wrote:
Add hwmod entries for the PWMSS on DRA7.
Can you provide some documentation references for this data?
I was looking at the TRM and at least the main_clk selection is somewhat
unclear to me.
-Tero
Signed-off-by: Vignesh R
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 239 ++
1 file changed, 239 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 0e64c2fac0b5..86a7ac9a3138 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
},
};
+/* pwmss */
+static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
+ .rev_offs = 0x0,
+ .sysc_offs = 0x4,
+ .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type2,
+};
+
+struct omap_hwmod_class dra7xx_epwmss_hwmod_class = {
+ .name = "epwmss",
+ .sysc = &dra7xx_epwmss_sysc,
+};
+
+static struct omap_hwmod_class dra7xx_ecap_hwmod_class = {
+ .name = "ecap",
+};
+
+static struct omap_hwmod_class dra7xx_eqep_hwmod_class = {
+ .name = "eqep",
+};
+
+struct omap_hwmod_class dra7xx_ehrpwm_hwmod_class = {
+ .name = "ehrpwm",
+};
+
+/* epwmss0 */
+struct omap_hwmod dra7xx_epwmss0_hwmod = {
+ .name = "epwmss0",
+ .class = &dra7xx_epwmss_hwmod_class,
+ .clkdm_name = "l4per2_clkdm",
+ .main_clk = "l4_root_clk_div",
+ .prcm = {
+ .omap4 = {
+ .modulemode = MODULEMODE_SWCTRL,
+ .clkctrl_offs =
DRA7XX_CM_L4PER2_PWMSS1_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L4PER2_PWMSS1_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* ecap0 */
+struct omap_hwmod dra7xx_ecap0_hwmod = {
+ .name = "ecap0",
+ .class = &dra7xx_ecap_hwmod_class,
+ .clkdm_name = "l4per2_clkdm",
+ .main_clk = "l4_root_clk_div",
+};
+
+/* eqep0 */
+struct omap_hwmod dra7xx_eqep0_hwmod = {
+ .name = "eqep0",
+ .class = &dra7xx_eqep_hwmod_class,
+ .clkdm_name = "l4per2_clkdm",
+ .main_clk = "l4_root_clk_div",
+};
+
+/* ehrpwm0 */
+struct omap_hwmod dra7xx_ehrpwm0_hwmod = {
+ .name = "ehrpwm0",
+ .class = &dra7xx_ehrpwm_hwmod_class,
+ .clkdm_name = "l4per2_clkdm",
+ .main_clk = "l4_root_clk_div",
+};
+
+/* epwmss1 */
+struct omap_hwmod dra7xx_epwmss1_hwmod = {
+ .name = "epwmss1",
+ .class = &dra7xx_epwmss_hwmod_class,
+ .clkdm_name = "l4per2_clkdm",
+ .main_clk = "l4_root_clk_div",
+ .prcm = {
+ .omap4 = {
+ .modulemode = MODULEMODE_SWCTRL,
+ .clkctrl_offs =
DRA7XX_CM_L4PER2_PWMSS2_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L4PER2_PWMSS2_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* ecap1 */
+struct omap_hwmod dra7xx_ecap1_hwmod = {
+ .name = "ecap1",
+ .class = &dra7xx_ecap_hwmod_class,
+ .clkdm_name = "l4per2_clkdm",
+ .main_clk = "l4_root_clk_div",
+};
+
+/* eqep1 */
+struct omap_hwmod dra7xx_eqep1_hwmod = {
+ .name = "eqep1",
+ .class = &dra7xx_eqep_hwmod_class,
+ .clkdm_name = "l4per2_clkdm",
+ .main_clk = "l4_root_clk_div",
+};
+
+/* ehrpwm1 */
+struct omap_hwmod dra7xx_ehrpwm1_hwmod = {
+ .name = "ehrpwm1",
+ .class = &dra7xx_ehrpwm_hwmod_class,
+ .clkdm_name = "l4per2_clkdm",
+ .main_clk = "l4_root_clk_div",
+};
+
+/* epwmss2 */
+struct omap_hwmod dra7xx_epwmss2_hwmod = {
+ .name = "epwmss2",
+ .class = &dra7xx_epwmss_hwmod_class,
+ .clkdm_name = "l4per2_clkdm",
+ .main_clk = "l4_root_clk_div",
+ .prcm = {
+ .omap4 = {
+ .modulemode = MODULEMODE_SWCTRL,
+ .clkctrl_offs =
DRA7XX_CM_L4PER2_PWMSS3_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L4PER2_PWMSS3_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* ecap2 */
+struct omap_hwmod dra7xx_ecap2_hwmod = {
+ .name = "ecap2",
+ .class = &dra7xx_ecap_hwmod_class,
+ .clkdm_name = "l4per2_clkdm",
+ .main_clk = "l4_root_clk_div",
+};
+
+/* eqep2 */
+struct omap_hwmod dra7xx_eqep2_hwmod = {
+ .name = "eqep2",
+ .class = &dra7xx_eqep_hwmod_class,
+ .clkdm_name = "l4per2_c
Re: [PATCH 3/5] ARM: dts: DRA7: Add TBCLK for PWMSS
On 06/01/2015 02:53 PM, Vignesh R wrote:
tbclk is used by ehrpwm to generate PWM waveform on DRA7 SoC. Add Linux
clock to control ehrpwm tbclk.
Care to add TRM reference here?
-Tero
Signed-off-by: Vignesh R
---
arch/arm/boot/dts/dra7.dtsi | 5 +
arch/arm/boot/dts/dra7xx-clocks.dtsi | 26 ++
2 files changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index f03a091cd076..387c76ca41f9 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -131,6 +131,11 @@
regulator-max-microvolt =
<300>;
};
};
+
+ scm_conf_clocks: clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
dra7_pmx_core: pinmux@1400 {
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 3b933f74d000..92452d61cf58 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -2136,3 +2136,29 @@
clocks = <&dpll_usb_ck>;
};
};
+
+&scm_conf_clocks {
+ ehrpwm0_tbclk: ehrpwm0_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&l4_root_clk_div>;
+ ti,bit-shift = <20>;
+ reg = <0x0558>;
+ };
+
+ ehrpwm1_tbclk: ehrpwm1_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&l4_root_clk_div>;
+ ti,bit-shift = <21>;
+ reg = <0x0558>;
+ };
+
+ ehrpwm2_tbclk: ehrpwm2_tbclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&l4_root_clk_div>;
+ ti,bit-shift = <22>;
+ reg = <0x0558>;
+ };
+};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] dt-bindings: clock: Add binding documentation for TI syscon gate clock
On 28/03/2019 14:31, Rob Herring wrote:
On Tue, Mar 12, 2019 at 02:35:17PM +0530, Vignesh Raghavendra wrote:
Add dt bindings for TI syscon gate clock.
Signed-off-by: Vignesh Raghavendra
---
.../bindings/clock/ti,syscon-gate-clock.txt | 35 +++
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/ti,syscon-gate-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/ti,syscon-gate-clock.txt
b/Documentation/devicetree/bindings/clock/ti,syscon-gate-clock.txt
new file mode 100644
index ..f2bc4281ddba
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,syscon-gate-clock.txt
@@ -0,0 +1,35 @@
+TI syscon gate clock
+
+The gate clock node must be provided inside a system controller node.
+
+Required:
+- comaptible: Must be "ti,syscon-gate-clock"
+- reg: Offset of register that controls the clock within syscon regmap
+- ti,clock-bit-idx: bit index that control gate/ungating of clock
+- clocks: phandle to the clock parent
+- #clock-cells: must be <0>
+
+Example:
+ ctrlmmr_epwm_ctrl: syscon@104140{
+ compatible = "syscon", "simple-bus";
Can't be both of these...
Is this a hard requirement? We seem to have few instances in the various
DTS files for various vendors where this is done, syscon is paired with
simple-mfd or simple-bus, or something else.
Basically, syscon by itself does not probe its children, and you can't
have the simple syscon support from kernel side if you don't have the
syscon compatible. Alternative is that we don't add any of the syscon
children under the syscon but add them as separate nodes outside it.
The above is not an issue for this patch itself if we ditch the separate
clock nodes, but it is more of a question about the syscon functionality
itself.
-Tero
+ reg = <0x0 0x104140 0x0 0x18>;
+ ranges = <0x0 0x0 0x104140>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ehrpwm0_tbclk: clk@0 {
+ compatible = "ti,syscon-gate-clock";
+ reg = <0x0>;
+ #clock-cells = <0>;
+ clocks = <&k3_clks 40 0>;
+ ti,clock-bit-idx = <0>;
This would imply you have multiple nodes at one address which is
discouraged.
+ };
We generally don't describe clocks as 1 clock per node. Give the parent
a specific compatible and make it a clock provider.
+
+ ehrpwm1_tbclk: clk@4 {
+ compatible = "ti,syscon-gate-clock";
+ reg = <0x4>;
+ #clock-cells = <0>;
+ clocks = <&k3_clks 41 0>;
+ ti,clock-bit-idx = <0>;
+ };
+ };
--
2.21.0
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 0/4] dt-bindings: soc/arm: Convert pending ti,sci* bindings to json format
On 16/04/2021 09:37, Nishanth Menon wrote: Hi, I understand that the following series belong to various maintainers, but, it is a bit better reviewed as a single series for cohesiveness. There are also dts fixups that this series exposes, which is good, but I chose to hold them back for now pending binding review at least. The complete series is available in [1] if folks are curious. Nishanth Menon (4): dt-bindings: reset: Convert ti,sci-reset to json schema dt-bindings: clock: Convert ti,sci-clk to json schema dt-bindings: soc: ti: Convert ti,sci-pm-domain to json schema dt-bindings: arm: keystone: Convert ti,sci to json schema For the whole series: Reviewed-by: Tero Kristo .../bindings/arm/keystone/ti,sci.txt | 86 .../bindings/arm/keystone/ti,sci.yaml | 129 ++ .../devicetree/bindings/clock/ti,sci-clk.txt | 36 - .../devicetree/bindings/clock/ti,sci-clk.yaml | 52 +++ .../bindings/reset/ti,sci-reset.txt | 62 - .../bindings/reset/ti,sci-reset.yaml | 51 +++ .../bindings/soc/ti/sci-pm-domain.txt | 65 - .../bindings/soc/ti/sci-pm-domain.yaml| 59 8 files changed, 291 insertions(+), 249 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml [1] https://github.com/nmenon/linux-2.6-playground/commits/yaml/tisci Regards, Nishanth Menon
Re: [PATCH v4 5/5] clk: ti: add am33xx/am43xx spread spectrum clock support
Hi Dario,
Spent some time looking at this, had to read through the TRM chapter of
it also in quite detailed level to figure out how this is supposed to
work out.
Other than couple of minor nits below, the code seems ok to me. What is
the testing that has been done with this?
On 01/04/2021 22:37, Dario Binacchi wrote:
The patch enables spread spectrum clocking (SSC) for MPU and LCD PLLs.
As reported by the TI spruh73x/spruhl7x RM, SSC is only supported for
the DISP/LCD and MPU PLLs on am33xx/am43xx. SSC is not supported for
DDR, PER, and CORE PLLs.
Calculating the required values and setting the registers accordingly
was taken from the set_mpu_spreadspectrum routine contained in the
arch/arm/mach-omap2/am33xx/clock_am33xx.c file of the u-boot project.
In locked condition, DPLL output clock = CLKINP *[M/N]. In case of
SSC enabled, the reference manual explains that there is a restriction
of range of M values. Since the omap2_dpll_round_rate routine attempts
to select the minimum possible N, the value of M obtained is not
guaranteed to be within the range required. With the new "ti,min-div"
parameter it is possible to increase N and consequently M to satisfy the
constraint imposed by SSC.
Signed-off-by: Dario Binacchi
---
/* REVISIT: Set ramp-up delay? */
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index c62f6fa6763d..cba093de62d8 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -63,6 +63,18 @@ struct clk_omap_reg {
* @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg
* @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs
* @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs
+ * @ssc_deltam_reg: register containing the DPLL SSC frequency spreading
+ * @ssc_modfreq_reg: register containing the DPLL SSC modulation frequency
+ * @ssc_modfreq_mant_mask: mask of the mantissa component in @ssc_modfreq_reg
+ * @ssc_modfreq_exp_mask: mask of the exponent component in @ssc_modfreq_reg
+ * @ssc_enable_mask: mask of the DPLL SSC enable bit in @control_reg
+ * @ssc_ack_mask: mask of the DPLL SSC turned on/off bit in @control_reg
+ * @ssc_downspread_mask: mask of the DPLL SSC low frequency only bit in
+ * @control_reg
+ * @ssc_modfreq: the DPLL SSC frequency modulation in kHz
+ * @ssc_deltam: the DPLL SSC frequency spreading in permille (10th of percent)
+ * @ssc_downspread: require the only low frequency spread of the DPLL in SSC
+ * mode
* @flags: DPLL type/features (see below)
*
* Possible values for @flags:
@@ -110,6 +122,18 @@ struct dpll_data {
u8 auto_recal_bit;
u8 recal_en_bit;
u8 recal_st_bit;
+ struct clk_omap_reg ssc_deltam_reg;
+ struct clk_omap_reg ssc_modfreq_reg;
+ u32 ssc_deltam_int_mask;
+ u32 ssc_deltam_frac_mask;
+ u32 ssc_modfreq_mant_mask;
+ u32 ssc_modfreq_exp_mask;
+ u32 ssc_enable_mask;
+ u32 ssc_ack_mask;
ssc_ack_mask is not used for anything in the code.
+ u32 ssc_downspread_mask;
+ u32 ssc_modfreq;
+ u32 ssc_deltam;
+ u8 ssc_downspread;
ssc_downspread should be boolean?
u8 flags;
};
Re: [PATCH 0/2] fdt: translate address if #size-cells = <0>
On 07/04/2021 15:52, Rob Herring wrote:
On Wed, Apr 7, 2021 at 2:07 AM Dario Binacchi wrote:
Il 07/04/2021 03:16 Rob Herring ha scritto:
On Tue, Apr 6, 2021 at 5:02 PM Dario Binacchi wrote:
Il 06/04/2021 16:06 Rob Herring ha scritto:
On Fri, Apr 2, 2021 at 2:21 PM Dario Binacchi wrote:
The series comes from my commit in U-boot
d64b9cdcd4 ("fdt: translate address if #size-cells = <0>")
and from the subsequent exchange of emails at the end of which I was
suggested to send the patch to the linux kernel
(https://patchwork.ozlabs.org/project/uboot/patch/1614324949-61314-1-git-send-email-bmeng...@gmail.com/).
It's 'ranges' that determines translatable which is missing from the
DT. This should have not had a 0 size either though maybe we could
support that.
I have replied to the email you sent to the u-boot mailing list
Does the DT have to be updated anyways for your spread spectrum support?
The spread spectrum support patch does not need this patch to work. They belong
to two different series.
That's not what I asked. Is the spread spectrum support forcing a DT
update for users?
Yes, the deltam and modfreq registers must be added to the DPLL clocks.
That's a shame given this dts has been mostly untouched since 2013.
I think technically it would be possible to map these registers within
the driver also, seeing there are like a handful of the DPLLs for both
am3/am4 which are impacted. Just add a new compatible or something, or
alternatively parse the register addresses and populate the
deltam/modfreq registers based on that.
If the DT has to be changed anyways (not really
great policy), then you could fix this in the DT at the same time.
I could put the fix to the device tree in that series, although I wouldn't
create a single patch to fix and add the SSC registers. First the size-cells =
<0>
fix patch and then the SSC patch.
Do you agree?
By at the same time, I really just meant within 1 release.
But I'd like to hear TI maintainers' thoughts on this.
I did post a comment on patch #1 questioning the approach from TI clock
driver perspective, imho I can't see why these two patches would be
needed right now.
-Tero
Re: [PATCH v5 5/5] clk: ti: add am33xx/am43xx spread spectrum clock support
On 18/04/2021 17:56, Dario Binacchi wrote:
The patch enables spread spectrum clocking (SSC) for MPU and LCD PLLs.
As reported by the TI spruh73x/spruhl7x RM, SSC is only supported for
the DISP/LCD and MPU PLLs on am33xx/am43xx. SSC is not supported for
DDR, PER, and CORE PLLs.
Calculating the required values and setting the registers accordingly
was taken from the set_mpu_spreadspectrum routine contained in the
arch/arm/mach-omap2/am33xx/clock_am33xx.c file of the u-boot project.
In locked condition, DPLL output clock = CLKINP *[M/N]. In case of
SSC enabled, the reference manual explains that there is a restriction
of range of M values. Since the omap2_dpll_round_rate routine attempts
to select the minimum possible N, the value of M obtained is not
guaranteed to be within the range required. With the new "ti,min-div"
parameter it is possible to increase N and consequently M to satisfy the
constraint imposed by SSC.
Signed-off-by: Dario Binacchi
Reviewed-by: Tero Kristo
---
Changes in v5:
- Remove ssc_ack_mask field from dpll_data structure. It was not used.
- Change ssc_downspread type from u8 to bool in dpll_data structure.
Changes in v4:
- Update commit message.
Changes in v3:
- Use "ti,ssc-modfreq-hz" binding instead of "ti,ssc-modfreq".
Changes in v2:
- Move the DT changes to the previous patch in the series.
drivers/clk/ti/dpll.c | 39 ++
drivers/clk/ti/dpll3xxx.c | 85 +++
include/linux/clk/ti.h| 22 ++
3 files changed, 146 insertions(+)
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index d6f1ac5b53e1..e9f9aee936ae 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -290,7 +290,9 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
struct clk_init_data *init = NULL;
const char **parent_names = NULL;
struct dpll_data *dd = NULL;
+ int ssc_clk_index;
u8 dpll_mode = 0;
+ u32 min_div;
dd = kmemdup(ddt, sizeof(*dd), GFP_KERNEL);
clk_hw = kzalloc(sizeof(*clk_hw), GFP_KERNEL);
@@ -345,6 +347,27 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
if (dd->autoidle_mask) {
if (ti_clk_get_reg_addr(node, 3, &dd->autoidle_reg))
goto cleanup;
+
+ ssc_clk_index = 4;
+ } else {
+ ssc_clk_index = 3;
+ }
+
+ if (dd->ssc_deltam_int_mask && dd->ssc_deltam_frac_mask &&
+ dd->ssc_modfreq_mant_mask && dd->ssc_modfreq_exp_mask) {
+ if (ti_clk_get_reg_addr(node, ssc_clk_index++,
+ &dd->ssc_deltam_reg))
+ goto cleanup;
+
+ if (ti_clk_get_reg_addr(node, ssc_clk_index++,
+ &dd->ssc_modfreq_reg))
+ goto cleanup;
+
+ of_property_read_u32(node, "ti,ssc-modfreq-hz",
+&dd->ssc_modfreq);
+ of_property_read_u32(node, "ti,ssc-deltam", &dd->ssc_deltam);
+ dd->ssc_downspread =
+ of_property_read_bool(node, "ti,ssc-downspread");
}
if (of_property_read_bool(node, "ti,low-power-stop"))
@@ -356,6 +379,10 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
if (of_property_read_bool(node, "ti,lock"))
dpll_mode |= 1 << DPLL_LOCKED;
+ if (!of_property_read_u32(node, "ti,min-div", &min_div) &&
+ min_div > dd->min_divider)
+ dd->min_divider = min_div;
+
if (dpll_mode)
dd->modes = dpll_mode;
@@ -585,8 +612,14 @@ static void __init of_ti_am3_no_gate_dpll_setup(struct device_node *node)
const struct dpll_data dd = {
.idlest_mask = 0x1,
.enable_mask = 0x7,
+ .ssc_enable_mask = 0x1 << 12,
+ .ssc_downspread_mask = 0x1 << 14,
.mult_mask = 0x7ff << 8,
.div1_mask = 0x7f,
+ .ssc_deltam_int_mask = 0x3 << 18,
+ .ssc_deltam_frac_mask = 0x3,
+ .ssc_modfreq_mant_mask = 0x7f,
+ .ssc_modfreq_exp_mask = 0x7 << 8,
.max_multiplier = 2047,
.max_divider = 128,
.min_divider = 1,
@@ -645,8 +678,14 @@ static void __init of_ti_am3_dpll_setup(struct device_node
*node)
const struct dpll_data dd = {
.idlest_mask = 0x1,
.enable_mask = 0x7,
+ .ssc_enable_mask = 0x1 << 12,
+ .ssc_downspread_mask = 0x1 << 14,
.mult_mask = 0x7ff << 8,
.div1_mask = 0x7f,
+ .ssc_delt
Re: [PATCH 0/2] fdt: translate address if #size-cells = <0>
On 08/04/2021 23:24, Dario Binacchi wrote:
Il 07/04/2021 15:21 Tero Kristo ha scritto:
On 07/04/2021 15:52, Rob Herring wrote:
On Wed, Apr 7, 2021 at 2:07 AM Dario Binacchi wrote:
Il 07/04/2021 03:16 Rob Herring ha scritto:
On Tue, Apr 6, 2021 at 5:02 PM Dario Binacchi wrote:
Il 06/04/2021 16:06 Rob Herring ha scritto:
On Fri, Apr 2, 2021 at 2:21 PM Dario Binacchi wrote:
The series comes from my commit in U-boot
d64b9cdcd4 ("fdt: translate address if #size-cells = <0>")
and from the subsequent exchange of emails at the end of which I was
suggested to send the patch to the linux kernel
(https://patchwork.ozlabs.org/project/uboot/patch/1614324949-61314-1-git-send-email-bmeng...@gmail.com/).
It's 'ranges' that determines translatable which is missing from the
DT. This should have not had a 0 size either though maybe we could
support that.
I have replied to the email you sent to the u-boot mailing list
Does the DT have to be updated anyways for your spread spectrum support?
The spread spectrum support patch does not need this patch to work. They belong
to two different series.
That's not what I asked. Is the spread spectrum support forcing a DT
update for users?
Yes, the deltam and modfreq registers must be added to the DPLL clocks.
That's a shame given this dts has been mostly untouched since 2013.
I think technically it would be possible to map these registers within
the driver also, seeing there are like a handful of the DPLLs for both
am3/am4 which are impacted. Just add a new compatible or something, or
alternatively parse the register addresses and populate the
deltam/modfreq registers based on that.
I have not added new compatibles, but I have added the offset of the delta and
modfreq
registers to the data structures used by the DPLL drivers and I have set them
in the
related setup functions.
https://lore.kernel.org/patchwork/patch/1406590/
True, I just said that technically it would be possible to add this data
within the driver itself to avoid modifying DT if that would be preferred.
If the DT has to be changed anyways (not really
great policy), then you could fix this in the DT at the same time.
I could put the fix to the device tree in that series, although I wouldn't
create a single patch to fix and add the SSC registers. First the size-cells =
<0>
fix patch and then the SSC patch.
Do you agree?
By at the same time, I really just meant within 1 release.
But I'd like to hear TI maintainers' thoughts on this.
I did post a comment on patch #1 questioning the approach from TI clock
driver perspective, imho I can't see why these two patches would be
needed right now.
Fix to above, it was patch #2 I was referring to.
Because U-boot maintainers asked me after I sent them my patch on this issue.
I believe that the email exchange that took place in the U-boot
(https://patchwork.ozlabs.org/project/uboot/patch/1614324949-61314-1-git-send-email-bmeng...@gmail.com/)
and Linux kernel mailing lists showed that:
- The patch 'fdt: translate address if # size-cells = <0>' is wrong (U-boot has
accepted
it, and it will have to be reverted).
- However, the same patch highlighted that it is wrong to use the size-cells =
<0> property
in the prcm_clocks and scm_clocks nodes of device tree.
- Rob agrees that in the case of the am3xx this is the right choice:
Well, I don't quite like where this is ending at. Basically you are just
modifying the am3/am4 DTs adding a size spec for every clock node. This
leaves the omap3/omap4/omap5/dra7 in the old format. Should someone
convert those also? Has anybody tested what happens with the u-boot
change on those platforms? Or with the kernel change proposed for the TI
clock driver?
Also, none of this changes the fact that imho patch #2 in this series is
wrong and should be fixed. Doing ioremap for every clock node is at
least costly (dra7xx has some 180 clock nodes based on quick grep) and
also potentially breaks things (you get extremely fragmented iomappings,
and some of them might even get rejected because you end up in the same
4K page), and should be avoided.
If things would be fixed properly, we would get rid of the clock nodes
from the DT completely and just leave the clock providers in place;
clocks would be specified via something like 'clocks = <&prcm
AM3_ADC_TSC_FCK>;' similar to what is done with the clkctrl entries, and
rest of the clock data would be built-in to the clock driver. This would
completely get rid of any future compatibility issues and the need to
tweak the DT if some clock driver would need modifications to support
some new feature.
-Tero
diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi
index 1fb22088caeb..59b0a0cf211e 100644
--- a/arch/arm/boot/dts/am33xx-l4.dtsi
Re: [PATCH 0/2] fdt: translate address if #size-cells = <0>
On 11/04/2021 22:30, Dario Binacchi wrote:
Il 09/04/2021 12:32 Tero Kristo ha scritto:
On 08/04/2021 23:24, Dario Binacchi wrote:
Il 07/04/2021 15:21 Tero Kristo ha scritto:
On 07/04/2021 15:52, Rob Herring wrote:
On Wed, Apr 7, 2021 at 2:07 AM Dario Binacchi wrote:
Il 07/04/2021 03:16 Rob Herring ha scritto:
On Tue, Apr 6, 2021 at 5:02 PM Dario Binacchi wrote:
Il 06/04/2021 16:06 Rob Herring ha scritto:
On Fri, Apr 2, 2021 at 2:21 PM Dario Binacchi wrote:
The series comes from my commit in U-boot
d64b9cdcd4 ("fdt: translate address if #size-cells = <0>")
and from the subsequent exchange of emails at the end of which I was
suggested to send the patch to the linux kernel
(https://patchwork.ozlabs.org/project/uboot/patch/1614324949-61314-1-git-send-email-bmeng...@gmail.com/).
It's 'ranges' that determines translatable which is missing from the
DT. This should have not had a 0 size either though maybe we could
support that.
I have replied to the email you sent to the u-boot mailing list
Does the DT have to be updated anyways for your spread spectrum support?
The spread spectrum support patch does not need this patch to work. They belong
to two different series.
That's not what I asked. Is the spread spectrum support forcing a DT
update for users?
Yes, the deltam and modfreq registers must be added to the DPLL clocks.
That's a shame given this dts has been mostly untouched since 2013.
I think technically it would be possible to map these registers within
the driver also, seeing there are like a handful of the DPLLs for both
am3/am4 which are impacted. Just add a new compatible or something, or
alternatively parse the register addresses and populate the
deltam/modfreq registers based on that.
I have not added new compatibles, but I have added the offset of the delta and
modfreq
registers to the data structures used by the DPLL drivers and I have set them
in the
related setup functions.
https://lore.kernel.org/patchwork/patch/1406590/
True, I just said that technically it would be possible to add this data
within the driver itself to avoid modifying DT if that would be preferred.
In the review of the series no one asked not to change the device tree but it
is also true
that no review has been made on the patch 'clk: ti: add am33xx / am43xx spread
spectrum clock support',
the one to be applied on the drivers that support the SSC.
I take this opportunity to ask you if you can kindly review that patch.
The clock driver patch itself seems fine, the devil is on the DT side,
and how we are going to re-arrange the DT data to accommodate it.
If the DT has to be changed anyways (not really
great policy), then you could fix this in the DT at the same time.
I could put the fix to the device tree in that series, although I wouldn't
create a single patch to fix and add the SSC registers. First the size-cells =
<0>
fix patch and then the SSC patch.
Do you agree?
By at the same time, I really just meant within 1 release.
But I'd like to hear TI maintainers' thoughts on this.
I did post a comment on patch #1 questioning the approach from TI clock
driver perspective, imho I can't see why these two patches would be
needed right now.
Fix to above, it was patch #2 I was referring to.
Because U-boot maintainers asked me after I sent them my patch on this issue.
I believe that the email exchange that took place in the U-boot
(https://patchwork.ozlabs.org/project/uboot/patch/1614324949-61314-1-git-send-email-bmeng...@gmail.com/)
and Linux kernel mailing lists showed that:
- The patch 'fdt: translate address if # size-cells = <0>' is wrong (U-boot has
accepted
it, and it will have to be reverted).
- However, the same patch highlighted that it is wrong to use the size-cells =
<0> property
in the prcm_clocks and scm_clocks nodes of device tree.
- Rob agrees that in the case of the am3xx this is the right choice:
Well, I don't quite like where this is ending at. Basically you are just
modifying the am3/am4 DTs adding a size spec for every clock node. This
leaves the omap3/omap4/omap5/dra7 in the old format. Should someone
convert those also? Has anybody tested what happens with the u-boot
change on those platforms? Or with the kernel change proposed for the TI
clock driver?
Also, none of this changes the fact that imho patch #2 in this series is
wrong and should be fixed. Doing ioremap for every clock node is at
least costly (dra7xx has some 180 clock nodes based on quick grep) and
also potentially breaks things (you get extremely fragmented iomappings,
and some of them might even get rejected because you end up in the same
4K page), and should be avoided.
You are right, and in fact in my previous email, I proposed only to change the
ti_clk_get_reg_addr() from:
- if (of_property_read_u32_index (node, "reg", index, &am
Re: [PATCH 2/2] clk: ti: get register address from device tree
On 02/04/2021 22:20, Dario Binacchi wrote:
Until now, only the register offset was retrieved from the device tree
to be added, during access, to a common base address for the clocks.
If possible, we try to retrieve the physical address of the register
directly from the device tree.
The physical address is derived from the base address of the clock
provider, it is not derived from the clock node itself.
Doing what this patch does may actually break things, as you end up
creating an individual ioremap for every single clock register, and they
are typically a word apart from each other. In the TI clock driver case,
the ioremap is done only once for the whole clock register space.
-Tero
Signed-off-by: Dario Binacchi
---
drivers/clk/ti/clk.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index 3da33c786d77..938f5a2cb425 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -265,9 +265,21 @@ int __init ti_clk_retry_init(struct device_node *node,
void *user,
int ti_clk_get_reg_addr(struct device_node *node, int index,
struct clk_omap_reg *reg)
{
+ const __be32 *addrp;
+ u64 size, addr = OF_BAD_ADDR;
+ unsigned int flags;
u32 val;
int i;
+ addrp = of_get_address(node, index, &size, &flags);
+ if (addrp)
+ addr = of_translate_address(node, addrp);
+
+ if (addr != OF_BAD_ADDR) {
+ reg->ptr = ioremap(addr, sizeof(u32));
+ return 0;
+ }
+
for (i = 0; i < CLK_MAX_MEMMAPS; i++) {
if (clocks_node_ptr[i] == node->parent)
break;
@@ -287,7 +299,6 @@ int ti_clk_get_reg_addr(struct device_node *node, int index,
reg->offset = val;
reg->ptr = NULL;
-
return 0;
}
[PATCH] MAINTAINERS: Update my email address and maintainer level status
My employment with TI is ending tomorrow, so update the email address entry in the maintainers file. Also, I don't expect to spend that much time with maintaining TI code anymore, so downgrade the status level to odd fixes only on areas where I remain as the main contact point for now, and move myself as secondary contact point where someone else has taken over the maintainership. Cc: Stephen Boyd Cc: Michael Turquette Cc: Nishanth Menon Cc: Santosh Shilimkar Cc: Borislav Petkov Cc: Tony Luck Signed-off-by: Tero Kristo Signed-off-by: Tero Kristo --- MAINTAINERS | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index f59ebd1eda3d..c362d8d9d316 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2615,8 +2615,8 @@ S:Maintained F: drivers/power/reset/keystone-reset.c ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE -M: Tero Kristo M: Nishanth Menon +M: Tero Kristo L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Supported F: Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -6465,9 +6465,9 @@ S:Maintained F: drivers/edac/skx_*.[ch] EDAC-TI -M: Tero Kristo +M: Tero Kristo L: linux-e...@vger.kernel.org -S: Maintained +S: Odd Fixes F: drivers/edac/ti_edac.c EDIROL UA-101/UA-1000 DRIVER @@ -17503,7 +17503,7 @@ F: drivers/iio/dac/ti-dac7612.c TEXAS INSTRUMENTS' SYSTEM CONTROL INTERFACE (TISCI) PROTOCOL DRIVER M: Nishanth Menon -M: Tero Kristo +M: Tero Kristo M: Santosh Shilimkar L: linux-arm-ker...@lists.infradead.org S: Maintained @@ -17647,9 +17647,9 @@ S: Maintained F: drivers/clk/clk-cdce706.c TI CLOCK DRIVER -M: Tero Kristo +M: Tero Kristo L: linux-o...@vger.kernel.org -S: Maintained +S: Odd Fixes F: drivers/clk/ti/ F: include/linux/clk/ti.h -- 2.17.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 15/20] clk: ti: dpll: Fix misnaming of '_register_dpll()'s 'user' parameter
On 20/01/2021 11:30, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/clk/ti/dpll.c:163: warning: Function parameter or member 'user' not
described in '_register_dpll'
drivers/clk/ti/dpll.c:163: warning: Excess function parameter 'hw'
description in '_register_dpll'
Cc: Tero Kristo
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-o...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Lee Jones
Reviewed-by: Tero Kristo
---
drivers/clk/ti/dpll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 247510e306e2a..d6f1ac5b53e14 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -151,7 +151,7 @@ static const struct clk_ops dpll_x2_ck_ops = {
/**
* _register_dpll - low level registration of a DPLL clock
- * @hw: hardware clock definition for the clock
+ * @user: pointer to the hardware clock definition for the clock
* @node: device node for the clock
*
* Finalizes DPLL registration process. In case a failure (clk-ref or
Re: [PATCH 13/20] clk: ti: clockdomain: Fix description for 'omap2_init_clk_clkdm's hw param
On 20/01/2021 11:30, Lee Jones wrote: Fixes the following W=1 kernel build warning(s): drivers/clk/ti/clockdomain.c:107: warning: Function parameter or member 'hw' not described in 'omap2_init_clk_clkdm' drivers/clk/ti/clockdomain.c:107: warning: Excess function parameter 'clk' description in 'omap2_init_clk_clkdm' Cc: Tero Kristo Cc: Michael Turquette Cc: Stephen Boyd Cc: linux-o...@vger.kernel.org Cc: linux-...@vger.kernel.org Signed-off-by: Lee Jones Reviewed-by: Tero Kristo --- drivers/clk/ti/clockdomain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/ti/clockdomain.c b/drivers/clk/ti/clockdomain.c index 700b7f44f6716..74831b2752b3b 100644 --- a/drivers/clk/ti/clockdomain.c +++ b/drivers/clk/ti/clockdomain.c @@ -97,7 +97,7 @@ void omap2_clkops_disable_clkdm(struct clk_hw *hw) /** * omap2_init_clk_clkdm - look up a clockdomain name, store pointer in clk - * @clk: OMAP clock struct ptr to use + * @hw: Pointer to clk_hw_omap used to obtain OMAP clock struct ptr to use * * Convert a clockdomain name stored in a struct clk 'clk' into a * clockdomain pointer, and save it into the struct clk. Intended to be
Re: [PATCH 16/20] clk: ti: gate: Fix possible doc-rot in 'omap36xx_gate_clk_enable_with_hsdiv_restore'
On 20/01/2021 11:30, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/clk/ti/gate.c:67: warning: Function parameter or member 'hw' not
described in 'omap36xx_gate_clk_enable_with_hsdiv_restore'
drivers/clk/ti/gate.c:67: warning: Excess function parameter 'clk'
description in 'omap36xx_gate_clk_enable_with_hsdiv_restore'
Cc: Tero Kristo
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-o...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Lee Jones
Reviewed-by: Tero Kristo
---
drivers/clk/ti/gate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ti/gate.c b/drivers/clk/ti/gate.c
index 42389558418c5..b1d0fdb40a75a 100644
--- a/drivers/clk/ti/gate.c
+++ b/drivers/clk/ti/gate.c
@@ -55,7 +55,7 @@ static const struct clk_ops omap_gate_clk_hsdiv_restore_ops =
{
/**
* omap36xx_gate_clk_enable_with_hsdiv_restore - enable clocks suffering
* from HSDivider PWRDN problem Implements Errata ID: i556.
- * @clk: DPLL output struct clk
+ * @hw: DPLL output struct clk_hw
*
* 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck,
* dpll4_m5_ck & dpll4_m6_ck dividers gets loaded with reset
Re: [PATCH] arm64: dts: ti: k3*: Fixup PMU compatibility to be CPU specific
On 20/01/2021 21:51, Nishanth Menon wrote:
We can use CPU specific pmu configuration to expose the appropriate
CPU specific events rather than just the basic generic pmuv3 perf
events.
Reported-by: Sudeep Holla
Signed-off-by: Nishanth Menon
Reviewed-by: Tero Kristo
---
AM65: https://pastebin.ubuntu.com/p/TF2cCMySkt/
J721E: https://pastebin.ubuntu.com/p/jgGPNmNgG3/
J7200: https://pastebin.ubuntu.com/p/Kfc3VHHXNB/
Original report:
https://lore.kernel.org/linux-arm-kernel/20210119172412.smsjdo2sjzqi5vcn@bogus/
I have'nt split this patch up for fixes tag primarily because the
basic functionality works and this is an improvement than a critical
fixup to backport for older kernels.
arch/arm64/boot/dts/ti/k3-am65.dtsi | 2 +-
arch/arm64/boot/dts/ti/k3-j7200.dtsi | 2 +-
arch/arm64/boot/dts/ti/k3-j721e.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65.dtsi
b/arch/arm64/boot/dts/ti/k3-am65.dtsi
index d84c0bc05023..a9fc1af03f27 100644
--- a/arch/arm64/boot/dts/ti/k3-am65.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65.dtsi
@@ -56,7 +56,7 @@ a53_timer0: timer-cl0-cpu0 {
};
pmu: pmu {
- compatible = "arm,armv8-pmuv3";
+ compatible = "arm,cortex-a53-pmu";
/* Recommendation from GIC500 TRM Table A.3 */
interrupts = ;
};
diff --git a/arch/arm64/boot/dts/ti/k3-j7200.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200.dtsi
index 66169bcf7c9a..b7005b803149 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200.dtsi
@@ -114,7 +114,7 @@ a72_timer0: timer-cl0-cpu0 {
};
pmu: pmu {
- compatible = "arm,armv8-pmuv3";
+ compatible = "arm,cortex-a72-pmu";
interrupts = ;
};
diff --git a/arch/arm64/boot/dts/ti/k3-j721e.dtsi b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
index cc483f7344af..f0587fde147e 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
@@ -115,7 +115,7 @@ a72_timer0: timer-cl0-cpu0 {
};
pmu: pmu {
- compatible = "arm,armv8-pmuv3";
+ compatible = "arm,cortex-a72-pmu";
/* Recommendation from GIC500 TRM Table A.3 */
interrupts = ;
};
Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock
On 26/01/2021 14:45, Lee Jones wrote:
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
This is the last set. Clock is clean after this.
Lee Jones (21):
clk: zynq: pll: Fix kernel-doc formatting in 'clk_register_zynq_pll's
header
clk: ti: clkt_dpll: Fix some kernel-doc misdemeanours
clk: ti: dpll3xxx: Fix some kernel-doc headers and promote other
worthy ones
clk: qcom: clk-regmap: Provide missing description for
'devm_clk_register_regmap()'s dev param
clk: sunxi: clk-sun9i-core: Demote non-conformant kernel-doc headers
clk: sunxi: clk-usb: Demote obvious kernel-doc abuse
clk: tegra: clk-tegra30: Remove unused variable 'reg'
clk: clkdev: Ignore suggestion to use gnu_printf() as it's not
appropriate here
clk: tegra: cvb: Provide missing description for
'tegra_cvb_add_opp_table()'s align param
clk: ti: dpll44xx: Fix some potential doc-rot
clk: renesas: renesas-cpg-mssr: Fix formatting issues for
'smstpcr_saved's documentation
clk: sunxi: clk-sun6i-ar100: Demote non-conformant kernel-doc header
clk: qcom: gcc-ipq4019: Remove unused variable 'ret'
clk: clk-fixed-mmio: Demote obvious kernel-doc abuse
clk: clk-npcm7xx: Remove unused static const tables 'npcm7xx_gates'
and 'npcm7xx_divs_fx'
clk: qcom: mmcc-msm8974: Remove unused static const tables
'mmcc_xo_mmpll0_1_2_gpll0{map}'
clk: clk-xgene: Add description for 'mask' and fix formatting for
'flags'
clk: qcom: clk-rpm: Remove a bunch of superfluous code
clk: spear: Move prototype to accessible header
clk: imx: Move 'imx6sl_set_wait_clk()'s prototype out to accessible
header
clk: zynqmp: divider: Add missing description for 'max_div'
arch/arm/mach-imx/common.h | 1 -
arch/arm/mach-imx/cpuidle-imx6sl.c | 1 +
arch/arm/mach-imx/pm-imx6.c| 1 +
arch/arm/mach-spear/generic.h | 12 ---
arch/arm/mach-spear/spear13xx.c| 1 +
drivers/clk/clk-fixed-mmio.c | 2 +-
drivers/clk/clk-npcm7xx.c | 108 -
drivers/clk/clk-xgene.c| 5 +-
drivers/clk/clkdev.c | 7 ++
drivers/clk/imx/clk-imx6sl.c | 1 +
drivers/clk/qcom/clk-regmap.c | 1 +
drivers/clk/qcom/clk-rpm.c | 63 ---
drivers/clk/qcom/gcc-ipq4019.c | 7 +-
drivers/clk/qcom/mmcc-msm8974.c| 16
drivers/clk/renesas/renesas-cpg-mssr.c | 4 +-
drivers/clk/spear/spear1310_clock.c| 1 +
drivers/clk/spear/spear1340_clock.c| 1 +
drivers/clk/sunxi/clk-sun6i-ar100.c| 2 +-
drivers/clk/sunxi/clk-sun9i-core.c | 8 +-
drivers/clk/sunxi/clk-usb.c| 2 +-
drivers/clk/tegra/clk-tegra30.c| 5 +-
drivers/clk/tegra/cvb.c| 1 +
drivers/clk/ti/clkt_dpll.c | 3 +-
drivers/clk/ti/dpll3xxx.c | 20 ++---
drivers/clk/ti/dpll44xx.c | 6 +-
For the TI portions:
Reviewed-by: Tero Kristo
drivers/clk/zynq/pll.c | 12 +--
drivers/clk/zynqmp/divider.c | 1 +
include/linux/clk/imx.h| 15
include/linux/clk/spear.h | 23 ++
29 files changed, 92 insertions(+), 238 deletions(-)
create mode 100644 include/linux/clk/imx.h
create mode 100644 include/linux/clk/spear.h
Cc: Ahmad Fatoum
Cc: Andy Gross
Cc: Avi Fishman
Cc: Benjamin Fair
Cc: Bjorn Andersson
Cc: Boris BREZILLON
Cc: Chen-Yu Tsai
Cc: "Emilio López"
Cc: Fabio Estevam
Cc: Geert Uytterhoeven
Cc: Jan Kotas
Cc: Jernej Skrabec
Cc: Jonathan Hunter
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Cc: Loc Ho
Cc: Maxime Ripard
Cc: Michael Turquette
Cc: Michal Simek
Cc: Nancy Yuen
Cc: Nuvoton Technologies
Cc: NXP Linux Team
Cc: open...@lists.ozlabs.org
Cc: Patrick Venture
Cc: Pengutronix Kernel Team
Cc: Peter De Schrijver
Cc: Philipp Zabel
Cc: Prashant Gaikwad
Cc: Rajan Vaja
Cc: Rajeev Kumar
Cc: Richard Woodruff
Cc: Russell King
Cc: Sascha Hauer
Cc: Shawn Guo
Cc: Shiraz Hashim
Cc: "Sören Brinkmann"
Cc: Stephen Boyd
Cc: Tali Perry
Cc: Tero Kristo
Cc: Thierry Reding
Cc: Tomer Maimon
Cc: Viresh Kumar
Re: [RFC 3/5] ARM: OMAP2+: timer: Add clocksource initialization and powerup support
On 03/14/2014 01:36 AM, Joel Fernandes wrote:
On 03/13/2014 04:52 PM, Rob Herring wrote:
On Thu, Mar 13, 2014 at 3:35 PM, Joel Fernandes wrote:
Introduce a generic omap timer initialization function that can
be used by all SoCs for which support is available in the clocksource
driver introduced in the series.
The function will also be responsible for calling clock initialization
required for everything else to work.
Signed-off-by: Joel Fernandes
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/timer.c | 28
2 files changed, 29 insertions(+)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index a6aae30..e58d9a4 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -92,6 +92,7 @@ extern void omap3_secure_sync32k_timer_init(void);
extern void omap3_gptimer_timer_init(void);
extern void omap4_local_timer_init(void);
extern void omap5_realtime_timer_init(void);
+void omap_generic_timer_init(void);
void omap2420_init_early(void);
void omap2430_init_early(void);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 74044aa..08c73a0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -324,6 +324,25 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
return r;
}
+int __init omap_dmtimer_powerup(struct omap_dm_timer *timer,
+ struct device_node *np) {
This function seems unrelated to the commit message.
Ok, I'll add it in the message.
+ struct omap_hwmod *oh;
+ const char *oh_name = NULL;
+
+ of_property_read_string_index(np, "ti,hwmods", 0, &oh_name);
+ if (!oh_name)
+ return -ENODEV;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh)
+ return -ENODEV;
+
+ omap_hwmod_setup_one(oh_name);
+
+ omap_hwmod_enable(oh);
+ return 0;
+}
+
static void __init omap2_gp_clockevent_init(int gptimer_id,
const char *fck_source,
const char *property)
@@ -615,6 +634,15 @@ static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck",
"ti,timer-alwon",
2, "sys_clkin_ck", NULL);
#endif
+void omap_generic_timer_init(void)
+{
+ if (!of_have_populated_dt())
+ BUG_ON("Generic timer init should only be used for DT boot\n");
I thought omap2 is always DT boot now.
That's right, sorry- I'll get rid of the check.
+
+ omap_clk_init();
Can't you use CLK_OF_DECLARE and remove this? Then you can remove the
init_time function hook completely.
There is some dev-id conn-id -> DT node mapping done. I'll let Tero comment
more on this.
It is actually more complicated than this, the reason we have
omap_clk_init() is the static dependencies between the init order of
various components in the system (slab, clocks, hwmod), and also because
OMAP clks have pretty much different basic clock init compared to the
generic DT clk init (memory mappings done differently etc.) and, it
was impossible to get the generic init modified to support OMAP clk init
due to various sources of resistance so here we are. I hope we are able
to merge the required stuff from omap_clk_init towards the generic clk
init eventually and get rid of OMAP specific stuff.
-Tero
Thanks,
-Joel
+ clocksource_of_init();
+}
+
#ifdef CONFIG_ARCH_OMAP4
#ifdef CONFIG_HAVE_ARM_TWD
static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/5] ARM: dts: am33xx: Set parent clock for timer through DT
On 03/13/2014 10:35 PM, Joel Fernandes wrote:
Signed-off-by: Joel Fernandes
---
arch/arm/boot/dts/am33xx.dtsi |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4e6c959..51b7008 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -352,6 +352,7 @@
interrupts = <67>;
ti,hwmods = "timer1";
ti,timer-alwon;
+ ti,default-parent = <&sys_clkin_ck>;
};
timer2: timer@4804 {
@@ -360,6 +361,7 @@
reg = <0x4804 0x400>;
interrupts = <68>;
ti,hwmods = "timer2";
+ ti,default-parent = <&sys_clkin_ck>;
};
timer3: timer@48042000 {
I don't think this works, the ti,default-parent property is only
supported for clock nodes (at least I didn't quickly find anything from
your clocksource driver that would handle this.) You should do something
like this:
&timer1_fck {
ti,default-parent = <&sys_clkin_ck>;
};
&timer2_fck {
ti,default-parent = <&sys_clkin_ck>;
};
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] clk: ti: am335x: remove unecessary cpu0 clk node
On 01/29/2014 08:19 PM, Nishanth Menon wrote:
cpu0 clock node has no functionality, since cpufreq-cpu0 is already
capable of picking up the clock from dts.
Signed-off-by: Nishanth Menon
Acked-by: Tero Kristo
---
drivers/clk/ti/clk-33xx.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/ti/clk-33xx.c b/drivers/clk/ti/clk-33xx.c
index 776ee45..028b337 100644
--- a/drivers/clk/ti/clk-33xx.c
+++ b/drivers/clk/ti/clk-33xx.c
@@ -34,7 +34,6 @@ static struct ti_dt_clk am33xx_clks[] = {
DT_CLK(NULL, "dpll_core_m5_ck", "dpll_core_m5_ck"),
DT_CLK(NULL, "dpll_core_m6_ck", "dpll_core_m6_ck"),
DT_CLK(NULL, "dpll_mpu_ck", "dpll_mpu_ck"),
- DT_CLK("cpu0", NULL, "dpll_mpu_ck"),
DT_CLK(NULL, "dpll_mpu_m2_ck", "dpll_mpu_m2_ck"),
DT_CLK(NULL, "dpll_ddr_ck", "dpll_ddr_ck"),
DT_CLK(NULL, "dpll_ddr_m2_ck", "dpll_ddr_m2_ck"),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ARM: dts: OMAP3+: add clock nodes for CPU
On 01/29/2014 08:19 PM, Nishanth Menon wrote:
OMAP34xx, AM3517 and OMAP36xx platforms use dpll1 clock.
OMAP443x, OMAP446x, OMAP447x, OMAP5, DRA7, AM43xx platforms use
dpll_mpu clock.
Latency used is the generic latency defined in omap-cpufreq
driver.
Signed-off-by: Nishanth Menon
Looks good to me.
Acked-by: Tero Kristo
---
arch/arm/boot/dts/am33xx.dtsi |4
arch/arm/boot/dts/am4372.dtsi |5 +
arch/arm/boot/dts/dra7.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |5 +
arch/arm/boot/dts/omap4.dtsi |5 +
arch/arm/boot/dts/omap5.dtsi |6 ++
6 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 6d95d3d..4bbba26 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -58,6 +58,10 @@
275000 1125000
>;
voltage-tolerance = <2>; /* 2 percentage */
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
clock-latency = <30>; /* From omap-cpufreq driver */
};
};
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index c6bd4d9..33798d9 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -33,6 +33,11 @@
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <30>; /* From omap-cpufreq driver */
};
};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1fd75aa..ce591e5 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -47,6 +47,11 @@
100 106
1176000 116
>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <30>; /* From omap-cpufreq driver */
};
cpu@1 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index a5fc83b..01f2b3b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -35,6 +35,11 @@
compatible = "arm,cortex-a8";
device_type = "cpu";
reg = <0x0>;
+
+ clocks = <&dpll1_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <30>; /* From omap-cpufreq driver */
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..ce87996 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -36,6 +36,11 @@
device_type = "cpu";
next-level-cache = <&L2>;
reg = <0x0>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <30>; /* From omap-cpufreq driver */
};
cpu@1 {
compatible = "arm,cortex-a9";
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..8bb4134 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -49,6 +49,12 @@
100 106
150 125
>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <30>; /* From omap-cpufreq driver */
+
/* cooling options */
cooling-min-level = <0>;
cooling-max-level = <2>;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
On 04/02/2014 04:48 PM, Peter Ujfalusi wrote:
ABE DPLL frequency need to be lowered from 361267200
to 180633600 to facilitate the ATL requironments.
The dpll_abe_m2x2_ck clock need to be set to double
of ABE DPLL rate in order to have correct clocks
for audio.
Do you have some sort of TRM reference for this?
-Tero
Signed-off-by: Peter Ujfalusi
---
drivers/clk/ti/clk-7xx.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index f7e40734c819..19a55bf407dd 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -16,7 +16,7 @@
#include
#include
-#define DRA7_DPLL_ABE_DEFFREQ 361267200
+#define DRA7_DPLL_ABE_DEFFREQ 180633600
#define DRA7_DPLL_GMAC_DEFFREQ10
@@ -322,6 +322,11 @@ int __init dra7xx_dt_clk_init(void)
if (rc)
pr_err("%s: failed to configure ABE DPLL!\n", __func__);
+ dpll_ck = clk_get_sys(NULL, "dpll_abe_m2x2_ck");
+ rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2);
+ if (rc)
+ pr_err("%s: failed to configure ABE DPLL m2x2!\n", __func__);
+
dpll_ck = clk_get_sys(NULL, "dpll_gmac_ck");
rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
if (rc)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
On 04/24/2014 12:11 PM, Peter Ujfalusi wrote:
Mike, Tero,
On 04/03/2014 09:29 AM, Peter Ujfalusi wrote:
On 04/02/2014 05:12 PM, Tero Kristo wrote:
On 04/02/2014 04:48 PM, Peter Ujfalusi wrote:
ABE DPLL frequency need to be lowered from 361267200
to 180633600 to facilitate the ATL requironments.
The dpll_abe_m2x2_ck clock need to be set to double
of ABE DPLL rate in order to have correct clocks
for audio.
Do you have some sort of TRM reference for this?
The ATL's max divider is 32.
For audio purpose the clock coming out from the ATL instance should be
128 * fs. It is only possible to have 44.1KHz sampling rate with ABE DPLL set
to 361267200 or 180633600. Which means:
The atl generated clock should be 128 * 44100 = 5644800
From ABE_DPLL 361267200 we would need to have 64 as divider (ATL can't do
this).
From the suggested ABE_DPLL of 180633600 we can use ATL divider of 32, which
is the maximum it can do.
So the reason for the change is to have ATLPCLK clock which can be used for
audio in the future, the 361267200 is just too high.
Tero: can I have your ack for this patch or do you have further concerns?
Yea looks good to me, except for the fact that there is some work on
getting default rate/parent support through DT. I would like a comment
from Mike about the estimate when this can get in, and whether we should
merge intermediate solutions still like this.
Anyway, you can consider this patch acked by me, I'll let Mike to decide
what to do with it though.
-Tero
Mike: do you want me to resend this patch?
Thanks,
Péter
-Tero
Signed-off-by: Peter Ujfalusi
---
drivers/clk/ti/clk-7xx.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index f7e40734c819..19a55bf407dd 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -16,7 +16,7 @@
#include
#include
-#define DRA7_DPLL_ABE_DEFFREQ361267200
+#define DRA7_DPLL_ABE_DEFFREQ180633600
#define DRA7_DPLL_GMAC_DEFFREQ10
@@ -322,6 +322,11 @@ int __init dra7xx_dt_clk_init(void)
if (rc)
pr_err("%s: failed to configure ABE DPLL!\n", __func__);
+dpll_ck = clk_get_sys(NULL, "dpll_abe_m2x2_ck");
+rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2);
+if (rc)
+pr_err("%s: failed to configure ABE DPLL m2x2!\n", __func__);
+
dpll_ck = clk_get_sys(NULL, "dpll_gmac_ck");
rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
if (rc)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
On 07/30/2014 08:53 AM, Peter Ujfalusi wrote: On 07/29/2014 07:12 PM, Mike Turquette wrote: Oh yea, seems this got lost into the myriad of branches I have. I can push this on top of my for-v3.17/ti-clk-drv if you like. That is the easiest thing for me. I think that Peter wanted to take this as a fix for 3.16 though. Peter is that correct? Yes, it would have been better to have it in 3.16 along with the DRA7 ATL clock driver. W/O this patch the ATL will not going to be usable since the ABE DPLL is set too high to be usable for it's purpose. Ok, this is now pushed on top of the for-v3.17/ti-clk-driver branch in my git-repo. Mike, do you want a new pull-req for this just in case? -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
On 07/31/2014 01:42 AM, Mike Turquette wrote: Quoting Tero Kristo (2014-07-30 05:27:07) On 07/30/2014 08:53 AM, Peter Ujfalusi wrote: On 07/29/2014 07:12 PM, Mike Turquette wrote: Oh yea, seems this got lost into the myriad of branches I have. I can push this on top of my for-v3.17/ti-clk-drv if you like. That is the easiest thing for me. I think that Peter wanted to take this as a fix for 3.16 though. Peter is that correct? Yes, it would have been better to have it in 3.16 along with the DRA7 ATL clock driver. W/O this patch the ATL will not going to be usable since the ABE DPLL is set too high to be usable for it's purpose. Ok, this is now pushed on top of the for-v3.17/ti-clk-driver branch in my git-repo. Mike, do you want a new pull-req for this just in case? I've picked it manually and applied on top of 3.16-rc7 for a last minute fix. I can add your Ack if you like. Ok thanks, Add my ack if you wish, no need from my side. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain
On 07/31/2014 09:28 AM, Tony Lindgren wrote: * Felipe Balbi [140730 09:23]: Hi, On Wed, Jul 30, 2014 at 10:45:41AM -0500, Nishanth Menon wrote: On Wed, Jul 30, 2014 at 9:40 AM, Felipe Balbi wrote: HI, On Tue, Jul 29, 2014 at 11:04:21PM -0700, Tony Lindgren wrote: * Felipe Balbi [140729 09:36]: Hi, On Tue, Jul 29, 2014 at 10:40:57AM -0500, Felipe Balbi wrote: On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote: * Felipe Balbi [140729 07:18]: Hi, On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote: * Felipe Balbi [140728 14:19]: now that we don't need to support legacy board-files, we can completely switch over to a linear irq domain and make use of irq_alloc_domain_generic_chips() to allocate all generic irq chips for us. This patch seems to somehow break off-idle for omap3 where it no longer wakes up. Sure your bisection is correct ? This patch just switches from legacy irq domain to linear irq domain. Yes, I tried it a few times. Just enabling retention idle hangs too with this patch. Maybe it's omap3_prcm_irq_setup that relies on 11 + OMAP_INTC_START? There may be other such issues lol. OMAP4 has the same nonsense. made me think why (if) OMAP4 works with that same setup. Does wake from OFF work with OMAP4 ? Not without similar changes, omap4+ has the same issue.. There's a RFC series from Nishant to fix some of this, and Tero is moving the PRCM into a driver. Anyway, here's a quick little hack to check if that's the reason for the regression: OK yeah that's along the same lines with Nishant's RFC series in thread "[RFC PATCH 0/7] ARM: OMAP4+: PRM: minor cleanups and dt support of interrupts" FYI, it did not compile, needs to include linux/of_irq.h. But yes, I might have sent the wrong version as I had that same build error and fixed it localy. it fixes the regression for me, Also now the whole series works for me :) good to know. What do you want to do now ? Wait for PRCM to become a driver ? Wait for Nishanth's series to get accepted ? I guess the same thing could be done for OMAP3 and AM33, then we would have a chance of having working wake from idle with the new irqchip. I can repost the current series as it stands now once 17-rc1 comes out (without the build failure ofcourse).. if that helps to move it out of RFC status. That'd be great. It would be ever greater if you could add support for OMAP3 on that too. Yeah sounds good to me. Tero, does that work OK for your PRCM changes? Well, this set seems to break PM. suspend-resume on omap3-beagle just hangs after this set is applied. Works fine without it with 3.16-rc5 tag. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: prevent erronous parsing of children during rate change
On 09/22/2014 10:18 PM, Stephen Boyd wrote:
On 08/21, Tero Kristo wrote:
In some cases, clocks can switch their parent with clk_set_rate, for
example clk_mux can do this in some cases. Current implementation of
clk_change_rate uses un-safe list iteration on the clock children, which
will cause wrong clocks to be parsed in case any of the clock children
change their parents during the change rate operation. Fixed by using
the safe list iterator instead.
The problem was detected due to some divide by zero errors generated
by clock init on dra7-evm board, see discussion under
http://article.gmane.org/gmane.linux.ports.arm.kernel/349180 for details.
Signed-off-by: Tero Kristo
To: Mike Turquette
Reported-by: Nishanth Menon
---
drivers/clk/clk.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index b76fa69..bacc06f 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1467,6 +1467,7 @@ static struct clk *clk_propagate_rate_change(struct clk
*clk, unsigned long even
static void clk_change_rate(struct clk *clk)
{
struct clk *child;
+ struct hlist_node *tmp;
unsigned long old_rate;
unsigned long best_parent_rate = 0;
bool skip_set_rate = false;
@@ -1502,7 +1503,11 @@ static void clk_change_rate(struct clk *clk)
if (clk->notifier_count && old_rate != clk->rate)
__clk_notify(clk, POST_RATE_CHANGE, old_rate, clk->rate);
- hlist_for_each_entry(child, &clk->children, child_node) {
+ /*
+* Use safe iteration, as change_rate can actually swap parents
+* for certain clock types.
+*/
+ hlist_for_each_entry_safe(child, tmp, &clk->children, child_node) {
/* Skip children who will be reparented to another clock */
if (child->new_parent && child->new_parent != clk)
continue;
Are we not hitting the new_parent check here? I don't understand
how we can be changing parents here unless the check is being
avoided, in which case I wonder why determine_rate isn't being
used.
It depends how the clock underneath handles the situation. The error I
am seeing actually happens with a SoC specific compound clock (DPLL)
which integrates set_rate + mux functionality into a single clock node.
A call to the clk_set_rate changes the parent of this clock (from bypass
clock to reference clock), in addition to changing the rate (tune the
mul+div.) I looked at using the determine rate call with this type but
it breaks everything up... the parent gets changed but not the clock
rate, in addition to some other issues.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: prevent erronous parsing of children during rate change
On 09/26/2014 04:35 AM, Stephen Boyd wrote: On 09/23/14 06:38, Tero Kristo wrote: On 09/22/2014 10:18 PM, Stephen Boyd wrote: On 08/21, Tero Kristo wrote: /* Skip children who will be reparented to another clock */ if (child->new_parent && child->new_parent != clk) continue; Are we not hitting the new_parent check here? I don't understand how we can be changing parents here unless the check is being avoided, in which case I wonder why determine_rate isn't being used. It depends how the clock underneath handles the situation. The error I am seeing actually happens with a SoC specific compound clock (DPLL) which integrates set_rate + mux functionality into a single clock node. A call to the clk_set_rate changes the parent of this clock (from bypass clock to reference clock), in addition to changing the rate (tune the mul+div.) I looked at using the determine rate call with this type but it breaks everything up... the parent gets changed but not the clock rate, in addition to some other issues. Ok. Is this omap3_noncore_dpll_set_rate()? Yes. > Can we use determine_rate + clk_set_parent_and_rate()? At least clk_set_parent_and_rate() would allow us to do the mult+div and the parent in the same op call, although I don't understand why setting the parent and then setting the rate is not going to work. Well, setting parent first, then rate later causes problems with the DPLL ending up running with illegal (non-specified) rate, the M+N values are most likely wrong if you just switch from bypass clock to reference clock first without programming the M+N first. I'm interested in the other issues that you mentioned too. Mostly these were side-effects from the illegal DPLL setup I guess, like boot hang, failed drivers etc. I didn't really investigate this that much as it is much more simpler just to use safe list iteration here. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: prevent erronous parsing of children during rate change
On 09/27/2014 02:24 AM, Mike Turquette wrote: Quoting Tero Kristo (2014-09-26 00:18:55) On 09/26/2014 04:35 AM, Stephen Boyd wrote: On 09/23/14 06:38, Tero Kristo wrote: On 09/22/2014 10:18 PM, Stephen Boyd wrote: On 08/21, Tero Kristo wrote: /* Skip children who will be reparented to another clock */ if (child->new_parent && child->new_parent != clk) continue; Are we not hitting the new_parent check here? I don't understand how we can be changing parents here unless the check is being avoided, in which case I wonder why determine_rate isn't being used. It depends how the clock underneath handles the situation. The error I am seeing actually happens with a SoC specific compound clock (DPLL) which integrates set_rate + mux functionality into a single clock node. A call to the clk_set_rate changes the parent of this clock (from bypass clock to reference clock), in addition to changing the rate (tune the mul+div.) I looked at using the determine rate call with this type but it breaks everything up... the parent gets changed but not the clock rate, in addition to some other issues. Ok. Is this omap3_noncore_dpll_set_rate()? Yes. > Can we use determine_rate + clk_set_parent_and_rate()? At least clk_set_parent_and_rate() would allow us to do the mult+div and the parent in the same op call, although I don't understand why setting the parent and then setting the rate is not going to work. Well, setting parent first, then rate later causes problems with the DPLL ending up running with illegal (non-specified) rate, the M+N values are most likely wrong if you just switch from bypass clock to reference clock first without programming the M+N first. I took a quick look and it still seems to me that the OMAP DPLLs are still not modeled properly as mux clocks. Is this correct? Yeah, they are not mux clocks, but rather a compound of mux + DPLL multiplier/divider logic. Changing the DPLL to be a separate mux + DPLL div/mult clock will still have overlapping usage of the DPLL_EN field, as the DPLL must be in bypass mode during M+N change. Or, should the DPLL rate change only be allowed if the mux is in bypass setting? Several drivers still depend on direct dpll clk_set_rate working 'properly' (there are some other issues currently present also which have nothing to do with the mux behavior.) This issue has been lingering for a long time and we can't use determine_rate unless that clock has multiple parents. Simply hacking knowledge of the parent bypass clock into the .set_rate callback is not enough. If you believe this _must_ be changed, I can take a look at this for next merge window, but this will cause a DT data compatibility break if nothing else (personally I don't care about this as I always rebuild DT blob with kernel, but lots of other people seem to do.) -Tero Regards, Mike I'm interested in the other issues that you mentioned too. Mostly these were side-effects from the illegal DPLL setup I guess, like boot hang, failed drivers etc. I didn't really investigate this that much as it is much more simpler just to use safe list iteration here. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: ti: dra7-atl-clock: Mark the device as pm_runtime_irq_safe
On 09/29/2014 11:10 AM, Peter Ujfalusi wrote: It is safe to call the pm sync calls in interrupt context in this driver. Signed-off-by: Peter Ujfalusi Thanks, applied to for-v3.18/ti-clk-drv. -Tero --- drivers/clk/ti/clk-dra7-atl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/ti/clk-dra7-atl.c b/drivers/clk/ti/clk-dra7-atl.c index af29359677da..f18d149acd65 100644 --- a/drivers/clk/ti/clk-dra7-atl.c +++ b/drivers/clk/ti/clk-dra7-atl.c @@ -228,6 +228,7 @@ static int of_dra7_atl_clk_probe(struct platform_device *pdev) cinfo->iobase = of_iomap(node, 0); cinfo->dev = &pdev->dev; pm_runtime_enable(cinfo->dev); + pm_runtime_irq_safe(cinfo->dev); pm_runtime_get_sync(cinfo->dev); atl_write(cinfo, DRA7_ATL_PCLKMUX_REG(0), DRA7_ATL_PCLKMUX); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk, ti, LLVMLinux: Move __init outside of type definition
On 09/27/2014 03:57 AM, Behan Webster wrote:
On 09/26/14 17:55, Felipe Balbi wrote:
On Fri, Sep 26, 2014 at 05:31:48PM -0700, Behan Webster wrote:
As written, the __init for ti_clk_get_div_table is in the middle of
the return
type.
The gcc documentation indicates that section attributes should be
added to the
end of the function declaration:
extern void foobar (void) __attribute__ ((section ("bar")));
However gcc seems to be very permissive with where attributes can be
placed.
clang on the other hand isn't so permissive, and fails if you put the
section
definition in the middle of the return type:
drivers/clk/ti/divider.c:298:28: error: expected ';' after struct
static struct clk_div_table
^
;
drivers/clk/ti/divider.c:298:1: warning: 'static' ignored on this
declaration [-Wmissing-declarations]
static struct clk_div_table
^
drivers/clk/ti/divider.c:299:9: error: type specifier missing,
defaults to 'int' [-Werror,-Wimplicit-int]
__init *ti_clk_get_div_table(struct device_node *node)
~~ ^
drivers/clk/ti/divider.c:345:9: warning: incompatible pointer types
returning 'struct clk_div_table *' from a function with result
type 'int *' [-Wincompatible-pointer-types]
return table;
^
drivers/clk/ti/divider.c:419:9: warning: incompatible pointer types
assigning to 'const struct clk_div_table *' from 'int *'
[-Wincompatible-pointer-types]
*table = ti_clk_get_div_table(node);
^ ~~
3 warnings and 2 errors generated.
By convention, most of the kernel code puts section attributes
between the
return type and function name. In the case where the return type is a
pointer,
it's important to place the '*' on left of the __init.
This updated code works for both gcc and clang.
Signed-off-by: Behan Webster
Reviewed-by: Mark Charlebois
makes sense to me:
Reviewed-by: Felipe Balbi
Thank you.
I wonder if we should add this a Sparse or Coccinelle rule.
+1
I'm hoping it can be added to checkpatch as well.
Behan
Thanks, patch applied to for-v3.18/ti-clk-drv.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] clk: Make clk API return per-user struct clk instances
On 09/30/2014 09:54 AM, Mike Turquette wrote: Quoting Stephen Boyd (2014-09-29 18:40:23) On 09/29/14 11:17, Tomeu Vizoso wrote: Also moves clock state to struct clk_core, but takes care to change as little API as possible. struct clk_hw still has a pointer to a struct clk, which is the implementation's per-user clk instance, for backwards compatibility. Signed-off-by: Tomeu Vizoso --- Hello, I'm sending this alternate implementation of the switch to per-user clocks, with the added goal of not requiring any substantial changes to existing users of the API. This is pretty much RFC-quality right now, having only tested that it builds on tegra_defconfig. My main question right now is what do we want to do with those drivers that statically declare clocks. State is now in struct clk_core, so updating the drivers accordingly will amount to a substantial amount of lines changed, which we are now trying to avoid. Who's actually using the static clocks? Isn't it just omap2? It looks like all of those are behind the DEFINE_CLK define so changing it in clk-private.h should "just work". I'm lost as to why static clocks are being used there though. If it was a problem with allocating memory too early it doesn't seem to be the case given that sometimes the .parents field isn't set for a mux and __clk_init() will go and allocate an array of pointers. Maybe I missed something though. Yeah, the old omap2+ static clocks were due to very very early init of things which required clocks If memory serves, that isn't a problem any more. I've talked to Tony and Tero about my desire to remove clk-private.h and the need to get rid of its use in the omap clock code. Tero, what is the status of DT conversion for OMAP2/OMAP3? Can we get get away with only defining clock data in DT for those platforms? Can we finally kill off clk-private.h? Clock data has been converted for all SoCs. The problem is currently that we are missing some OMAP3 based DT board definitions and still require legacy boot => thus requiring legacy clock data also => omap3 legacy clock data can't be removed yet. Tony, whats the latest status with these missing omap3 boards? How many board->dt conversions are still needed? Is there anything someone can do on this front? -Tero Regards, Mike Thanks, Tomeu --- drivers/clk/clk-composite.c | 12 +- drivers/clk/clk.c| 573 +++ drivers/clk/clk.h| 5 + drivers/clk/clkdev.c | 20 +- drivers/clk/tegra/clk.c | 2 +- include/linux/clk-private.h | 20 +- include/linux/clk-provider.h | 22 +- include/linux/clkdev.h | 2 +- 8 files changed, 410 insertions(+), 246 deletions(-) diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c index b9355da..cb4a09d 100644 --- a/drivers/clk/clk-composite.c +++ b/drivers/clk/clk-composite.c @@ -57,14 +57,14 @@ static unsigned long clk_composite_recalc_rate(struct clk_hw *hw, static long clk_composite_determine_rate(struct clk_hw *hw, unsigned long rate, unsigned long *best_parent_rate, - struct clk **best_parent_p) + struct clk_core **best_parent_p) We should avoid exposing clk_core to anything besides clk.c or users of clk-private.h (the latter which should go away once we remove all static clocks). -- 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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: prevent erronous parsing of children during rate change
On 09/30/2014 10:07 AM, Mike Turquette wrote: Quoting Tero Kristo (2014-09-29 01:09:24) On 09/27/2014 02:24 AM, Mike Turquette wrote: Quoting Tero Kristo (2014-09-26 00:18:55) On 09/26/2014 04:35 AM, Stephen Boyd wrote: On 09/23/14 06:38, Tero Kristo wrote: On 09/22/2014 10:18 PM, Stephen Boyd wrote: On 08/21, Tero Kristo wrote: /* Skip children who will be reparented to another clock */ if (child->new_parent && child->new_parent != clk) continue; Are we not hitting the new_parent check here? I don't understand how we can be changing parents here unless the check is being avoided, in which case I wonder why determine_rate isn't being used. It depends how the clock underneath handles the situation. The error I am seeing actually happens with a SoC specific compound clock (DPLL) which integrates set_rate + mux functionality into a single clock node. A call to the clk_set_rate changes the parent of this clock (from bypass clock to reference clock), in addition to changing the rate (tune the mul+div.) I looked at using the determine rate call with this type but it breaks everything up... the parent gets changed but not the clock rate, in addition to some other issues. Ok. Is this omap3_noncore_dpll_set_rate()? Yes. > Can we use determine_rate + clk_set_parent_and_rate()? At least clk_set_parent_and_rate() would allow us to do the mult+div and the parent in the same op call, although I don't understand why setting the parent and then setting the rate is not going to work. Well, setting parent first, then rate later causes problems with the DPLL ending up running with illegal (non-specified) rate, the M+N values are most likely wrong if you just switch from bypass clock to reference clock first without programming the M+N first. I took a quick look and it still seems to me that the OMAP DPLLs are still not modeled properly as mux clocks. Is this correct? Yeah, they are not mux clocks, but rather a compound of mux + DPLL multiplier/divider logic. Changing the DPLL to be a separate mux + DPLL div/mult clock will still have overlapping usage of the DPLL_EN field, I'm not talking about splitting up the clock into two separate clocks. If memory serves the DPLL clock implementation "cheats" and hides the bypass_clk info from the clock framework. To be explicit, from the perspective of Linux clock framework DPLL clocks only have one parent. In reality a typical DPLL should have at least 2 parents (and in some cases starting with OMAP4, some of the DPLL output clocks should have a second HSD parent). But the implementation does not reflect this. No, this is not the DPLLs are modelled. Each DPLL has currently two parents, ref-clk and bypass-clk, which are both modelled as separate clock nodes, and the DPLL switches parents based on bypass/lock mode. The bypass clock is also usually a mux clock, which further selects separate bypass parent, resulting in 3 or more parents for a certain DPLL. as the DPLL must be in bypass mode during M+N change. Or, should the DPLL rate change only be allowed if the mux is in bypass setting? Several drivers still depend on direct dpll clk_set_rate working 'properly' (there are some other issues currently present also which have nothing to do with the mux behavior.) This issue has been lingering for a long time and we can't use determine_rate unless that clock has multiple parents. Simply hacking knowledge of the parent bypass clock into the .set_rate callback is not enough. If you believe this _must_ be changed, I can take a look at this for next merge window, but this will cause a DT data compatibility break if nothing else (personally I don't care about this as I always rebuild DT blob with kernel, but lots of other people seem to do.) Well I guess the question is how long will we put up with the many small headaches caused by incorrectly modeling the clock? Well, its not kind of incorrectly modelled, it is just modelled in such way that clk_set_rate doesn't cope too well with it. determine_rate and clk_set_parent_and_rate should be sufficient for the OMAP DPLLs but only if they are correctly modeled in the framework. Do we have implementation for clk_set_parent_and_rate someplace? I looked at rc7 and didn't find this. I think this would fix the issues I am seeing combined with determine_rate, if clk_set_rate would internally handle changing both rate + parent. -Tero Regards, Mike -Tero Regards, Mike I'm interested in the other issues that you mentioned too. Mostly these were side-effects from the illegal DPLL setup I guess, like boot hang, failed drivers etc. I didn't really investigate this that much as it is much more simpler just to use safe list iteration here. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body o
Re: [PATCH 1/8] CLK: ti: dra7: Initialize USB_DPLL
On 03/07/2014 03:09 PM, Roger Quadros wrote:
USB_DPLL must be initialized and locked at boot so that
USB modules can work.
Also program USB_DLL_M2 output to half rate.
CC: Mike Turquette
CC: Tero Kristo
Signed-off-by: Roger Quadros
---
drivers/clk/ti/clk-7xx.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 9977653..f89f3c2 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -18,6 +18,7 @@
#define DRA7_DPLL_ABE_DEFFREQ 361267200
#define DRA7_DPLL_GMAC_DEFFREQ10
+#define DRA7_DPLL_USB_DEFFREQ 96000
static struct ti_dt_clk dra7xx_clks[] = {
@@ -328,5 +329,15 @@ int __init dra7xx_dt_clk_init(void)
if (rc)
pr_err("%s: failed to configure GMAC DPLL!\n", __func__);
+ dpll_ck = clk_get_sys(NULL, "dpll_usb_ck");
+ rc = clk_set_rate(dpll_ck, DRA7_DPLL_USB_DEFFREQ);
+ if (rc)
+ pr_err("%s: failed to configure USB DPLL!\n", __func__);
+
+ dpll_ck = clk_get_sys(NULL, "dpll_usb_m2_ck");
+ rc = clk_set_rate(dpll_ck, DRA7_DPLL_USB_DEFFREQ/2);
+ if (rc)
+ pr_err("%s: failed to set USB_DPLL M2 OUT\n", __func__);
+
I would rather see this done using the default-rate mechanism provided here:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg101300.html
However, this remains to be commented by Mike whether the patch is okay
or not.
-Tero
return rc;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] ARM: dts: dra7-clock: Add "l3init_960m_gfclk" clock gate
On 03/07/2014 03:09 PM, Roger Quadros wrote:
This clock gate description was missing in older Reference manuals.
It is present on the SoC to provide 960MHz reference clock to the
internal USB PHYs.
Can you provide a document reference here?
-Tero
Use l3init_960m_gfclk as parent of usb_otg_ss1_refclk960m and
usb_otg_ss2_refclk960m.
CC: Tero Kristo
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index e96da9a..b8d3a9d 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1386,6 +1386,14 @@
ti,dividers = <1>, <8>;
};
+ l3init_960m_gfclk: l3init_960m_gfclk {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&dpll_usb_clkdcoldo>;
+ ti,bit-shift = <8>;
+ reg = <0x06c0>;
+ };
+
dss_32khz_clk: dss_32khz_clk {
#clock-cells = <0>;
compatible = "ti,gate-clock";
@@ -1533,7 +1541,7 @@
usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m {
#clock-cells = <0>;
compatible = "ti,gate-clock";
- clocks = <&dpll_usb_clkdcoldo>;
+ clocks = <&l3init_960m_gfclk>;
ti,bit-shift = <8>;
reg = <0x13f0>;
};
@@ -1541,7 +1549,7 @@
usb_otg_ss2_refclk960m: usb_otg_ss2_refclk960m {
#clock-cells = <0>;
compatible = "ti,gate-clock";
- clocks = <&dpll_usb_clkdcoldo>;
+ clocks = <&l3init_960m_gfclk>;
ti,bit-shift = <8>;
reg = <0x1340>;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/8] ARM: dts: dra7: Initialize USB_DPLL
On 03/10/2014 02:49 PM, Roger Quadros wrote:
USB_DPLL must be initialized and locked at boot so that
USB modules can work.
Program USB_DLL_M2 output to half rate as well.
Patch depends on
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg101300.html
CC: Mike Turquette
CC: Tero Kristo
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/dra7.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 597979b..f376923 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -815,3 +815,11 @@
};
/include/ "dra7xx-clocks.dtsi"
+
+&dpll_usb_ck {
+default-rate = <96000>;
+};
+
+&dpll_usb_m2_ck {
+ default-rate = <48000>;
+};
You can add these directly under the dra7xx-clocks.dtsi file as well, as
I don't think anybody needs to modify these. And the properties can be
added directly under the nodes themselves.
However, this patch can't be acked yet as we have no feedback from Mike
for the default-rate proposal.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/13] CLK: TI: DRA7: make return of 0 explicit
On 05/19/2014 10:41 AM, Dan Carpenter wrote:
This one does feel like a bug in the original code as you mention. I
have added the TI devs to the CC list so they can help us.
Yes this is a bug, the dra7_apll_enable() should return some sort of
error code if the lock fails. EBUSY maybe?
-Tero
regards,
dan carpenter
On Mon, May 19, 2014 at 06:31:05AM +0200, Julia Lawall wrote:
From: Julia Lawall
Delete unnecessary local variable whose value is always 0 and that hides
the fact that the result is always 0.
Additionally dropped some unneeded braces in an affected if.
A simplified version of the semantic patch that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@r exists@
local idexpression ret;
expression e;
position p;
@@
-ret = 0;
... when != ret = e
return
- ret
+ 0
;
//
Signed-off-by: Julia Lawall
---
Alternatively, is an error code wanted in either of the MAX_APLL_WAIT_TRIES
cases?
drivers/clk/ti/apll.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/ti/apll.c b/drivers/clk/ti/apll.c
index b986f61..659032a 100644
--- a/drivers/clk/ti/apll.c
+++ b/drivers/clk/ti/apll.c
@@ -37,7 +37,7 @@
static int dra7_apll_enable(struct clk_hw *hw)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
- int r = 0, i = 0;
+ int i = 0;
struct dpll_data *ad;
const char *clk_name;
u8 state = 1;
@@ -55,7 +55,7 @@ static int dra7_apll_enable(struct clk_hw *hw)
v = ti_clk_ll_ops->clk_readl(ad->idlest_reg);
if ((v & ad->idlest_mask) == state)
- return r;
+ return 0;
v = ti_clk_ll_ops->clk_readl(ad->control_reg);
v &= ~ad->enable_mask;
@@ -74,17 +74,14 @@ static int dra7_apll_enable(struct clk_hw *hw)
udelay(1);
}
- if (i == MAX_APLL_WAIT_TRIES) {
+ if (i == MAX_APLL_WAIT_TRIES)
pr_warn("clock: %s failed transition to '%s'\n",
clk_name, (state) ? "locked" : "bypassed");
- } else {
+ else
pr_debug("clock: %s transition to '%s' in %d loops\n",
clk_name, (state) ? "locked" : "bypassed", i);
- r = 0;
- }
-
- return r;
+ return 0;
}
static void dra7_apll_disable(struct clk_hw *hw)
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CLK: TI: DRA7: return error code in failure case
On 05/19/2014 02:25 PM, Julia Lawall wrote:
From: Julia Lawall
Add a returned error code in the MAX_APLL_WAIT_TRIES case. Remove the
updating of the return variable r to 0 if MAX_APLL_WAIT_TRIES is not yet
reached, because r is already 0 at this point.
Signed-off-by: Julia Lawall
Acked-by: Tero Kristo
Mike, do you want to queue this as a fix or shall I add this to be
queued for 3.16?
-Tero
---
diff --git a/drivers/clk/ti/apll.c b/drivers/clk/ti/apll.c
index b986f61..efc71a0 100644
--- a/drivers/clk/ti/apll.c
+++ b/drivers/clk/ti/apll.c
@@ -77,13 +77,11 @@ static int dra7_apll_enable(struct clk_hw *hw)
if (i == MAX_APLL_WAIT_TRIES) {
pr_warn("clock: %s failed transition to '%s'\n",
clk_name, (state) ? "locked" : "bypassed");
- } else {
+ r = -EBUSY;
+ } else
pr_debug("clock: %s transition to '%s' in %d loops\n",
clk_name, (state) ? "locked" : "bypassed", i);
- r = 0;
- }
-
return r;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
On 05/06/2014 04:39 PM, Peter Ujfalusi wrote:
Mike,
On 04/24/2014 06:03 PM, Tero Kristo wrote:
On 04/24/2014 12:11 PM, Peter Ujfalusi wrote:
Mike, Tero,
On 04/03/2014 09:29 AM, Peter Ujfalusi wrote:
On 04/02/2014 05:12 PM, Tero Kristo wrote:
On 04/02/2014 04:48 PM, Peter Ujfalusi wrote:
ABE DPLL frequency need to be lowered from 361267200
to 180633600 to facilitate the ATL requironments.
The dpll_abe_m2x2_ck clock need to be set to double
of ABE DPLL rate in order to have correct clocks
for audio.
Do you have some sort of TRM reference for this?
The ATL's max divider is 32.
For audio purpose the clock coming out from the ATL instance should be
128 * fs. It is only possible to have 44.1KHz sampling rate with ABE DPLL set
to 361267200 or 180633600. Which means:
The atl generated clock should be 128 * 44100 = 5644800
From ABE_DPLL 361267200 we would need to have 64 as divider (ATL can't do
this).
From the suggested ABE_DPLL of 180633600 we can use ATL divider of 32, which
is the maximum it can do.
So the reason for the change is to have ATLPCLK clock which can be used for
audio in the future, the 361267200 is just too high.
Tero: can I have your ack for this patch or do you have further concerns?
Yea looks good to me, except for the fact that there is some work on getting
default rate/parent support through DT. I would like a comment from Mike about
the estimate when this can get in, and whether we should merge intermediate
solutions still like this.
Anyway, you can consider this patch acked by me, I'll let Mike to decide what
to do with it though.
Do you have anything against this patch? Since right now there is no other
ways to fix the ABE DPLL for dra7 it would be great if we could have this in
till we have the final solution. Also I'd like to point out that the original
frequency the ABE DPLL was not correct and renders the audio to be not usable
on the platform.
Thanks,
Péter
Thanks, queued for 3.16/ti-clk-drv.
-Tero
-Tero
Mike: do you want me to resend this patch?
Thanks,
Péter
-Tero
Signed-off-by: Peter Ujfalusi
---
drivers/clk/ti/clk-7xx.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index f7e40734c819..19a55bf407dd 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -16,7 +16,7 @@
#include
#include
-#define DRA7_DPLL_ABE_DEFFREQ361267200
+#define DRA7_DPLL_ABE_DEFFREQ180633600
#define DRA7_DPLL_GMAC_DEFFREQ10
@@ -322,6 +322,11 @@ int __init dra7xx_dt_clk_init(void)
if (rc)
pr_err("%s: failed to configure ABE DPLL!\n", __func__);
+dpll_ck = clk_get_sys(NULL, "dpll_abe_m2x2_ck");
+rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2);
+if (rc)
+pr_err("%s: failed to configure ABE DPLL m2x2!\n", __func__);
+
dpll_ck = clk_get_sys(NULL, "dpll_gmac_ck");
rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
if (rc)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: ti: clk-54xx: Set the rate for dpll_abe_m2x2_ck
On 04/30/2014 02:39 PM, Peter Ujfalusi wrote:
In order to get correct clock dividers for AESS/ABE we need to set the
dpll_abe_m2x2_ck rate to be double of dpll_abe_ck.
Signed-off-by: Peter Ujfalusi
Thanks, queued for 3.15-rc/ti-clk-drv.
-Tero
---
drivers/clk/ti/clk-54xx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/ti/clk-54xx.c b/drivers/clk/ti/clk-54xx.c
index 08f3d1b915b3..5e183993e3ec 100644
--- a/drivers/clk/ti/clk-54xx.c
+++ b/drivers/clk/ti/clk-54xx.c
@@ -240,6 +240,12 @@ int __init omap5xxx_dt_clk_init(void)
if (rc)
pr_err("%s: failed to configure ABE DPLL!\n", __func__);
+ abe_dpll = clk_get_sys(NULL, "dpll_abe_m2x2_ck");
+ if (!rc)
+ rc = clk_set_rate(abe_dpll, OMAP5_DPLL_ABE_DEFFREQ * 2);
+ if (rc)
+ pr_err("%s: failed to configure ABE m2x2 DPLL!\n", __func__);
+
usb_dpll = clk_get_sys(NULL, "dpll_usb_ck");
rc = clk_set_rate(usb_dpll, OMAP5_DPLL_USB_DEFFREQ);
if (rc)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: DTS: omap54xx-clocks: remove the autoidle properties for clock nodes
On 04/30/2014 03:30 PM, Tero Kristo wrote:
On 04/30/2014 02:41 PM, Peter Ujfalusi wrote:
In OMAP5 bit 8 in PRCM registers are not defined (Reserved) unlike their
counterpart in OMAP4.
It is better to not write to these bits.
Yeah, looks like this bug was copied over from the legacy clock data.
Acked-by: Tero Kristo
Also, queued for 3.15-rc/clk-dt.
-Tero
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 48
--
1 file changed, 48 deletions(-)
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index d487fdab3921..d784ff5d3904 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -120,10 +120,8 @@
compatible = "ti,divider-clock";
clocks = <&dpll_abe_x2_ck>;
ti,max-div = <31>;
-ti,autoidle-shift = <8>;
reg = <0x01f0>;
ti,index-starts-at-one;
-ti,invert-autoidle-bit;
};
abe_24m_fclk: abe_24m_fclk {
@@ -164,10 +162,8 @@
compatible = "ti,divider-clock";
clocks = <&dpll_abe_x2_ck>;
ti,max-div = <31>;
-ti,autoidle-shift = <8>;
reg = <0x01f4>;
ti,index-starts-at-one;
-ti,invert-autoidle-bit;
};
dpll_core_ck: dpll_core_ck {
@@ -188,10 +184,8 @@
compatible = "ti,divider-clock";
clocks = <&dpll_core_x2_ck>;
ti,max-div = <63>;
-ti,autoidle-shift = <8>;
reg = <0x0150>;
ti,index-starts-at-one;
-ti,invert-autoidle-bit;
};
c2c_fclk: c2c_fclk {
@@ -215,10 +209,8 @@
compatible = "ti,divider-clock";
clocks = <&dpll_core_x2_ck>;
ti,max-div = <63>;
-ti,autoidle-shift = <8>;
reg = <0x0138>;
ti,index-starts-at-one;
-ti,invert-autoidle-bit;
};
dpll_core_h12x2_ck: dpll_core_h12x2_ck {
@@ -226,10 +218,8 @@
compatible = "ti,divider-clock";
clocks = <&dpll_core_x2_ck>;
ti,max-div = <63>;
-ti,autoidle-shift = <8>;
reg = <0x013c>;
ti,index-starts-at-one;
-ti,invert-autoidle-bit;
};
dpll_core_h13x2_ck: dpll_core_h13x2_ck {
@@ -237,10 +227,8 @@
compatible = "ti,divider-clock";
clocks = <&dpll_core_x2_ck>;
ti,max-div = <63>;
-ti,autoidle-shift = <8>;
reg = <0x0140>;
ti,index-starts-at-one;
-ti,invert-autoidle-bit;
};
dpll_core_h14x2_ck: dpll_core_h14x2_ck {
@@ -248,10 +236,8 @@
compatible = "ti,divider-clock";
clocks = <&dpll_core_x2_ck>;
ti,max-div = <63>;
-ti,autoidle-shift = <8>;
reg = <0x0144>;
ti,index-starts-at-one;
-ti,invert-autoidle-bit;
};
dpll_core_h22x2_ck: dpll_core_h22x2_ck {
@@ -259,10 +245,8 @@
compatible = "ti,divider-clock";
clocks = <&dpll_core_x2_ck>;
ti,max-div = <63>;
-ti,autoidle-shift = <8>;
reg = <0x0154>;
ti,index-starts-at-one;
-ti,invert-autoidle-bit;
};
dpll_core_h23x2_ck: dpll_core_h23x2_ck {
@@ -270,10 +254,8 @@
compatible = "ti,divider-clock";
clocks = <&dpll_core_x2_ck>;
ti,max-div = <63>;
-ti,autoidle-shift = <8>;
reg = <0x0158>;
ti,index-starts-at-one;
-ti,invert-autoidle-bit;
};
dpll_core_h24x2_ck: dpll_core_h24x2_ck {
@@ -281,10 +263,8 @@
compatible = "ti,divider-clock";
clocks = <&dpll_core_x2_ck>;
ti,max-div = <63>;
-ti,autoidle-shift = <8>;
reg = <0x015c>;
ti,index-starts-at-one;
-ti,invert-autoidle-bit;
};
dpll_core_m2_ck: dpll_core_m2_ck {
@@ -292,10 +272,8 @@
compatible = "ti,divider-clock";
clocks = <&dpll_core_ck>;
ti,max-div = <31>;
-ti,autoidle-shift = <8>;
reg = <0x0130>;
ti,index-starts-at-one;
-ti,invert-autoidle-bit;
};
dpll_core_m3x2_ck: dpll_core_m3x2_ck {
@@ -303,10 +281,8 @@
compatible = "ti,divider-clock";
clocks = <&dpll_core_x2_ck>;
ti,max-div = <31>;
-ti,autoidle-shift = <8>;
reg = <0x0134>;
ti,index-starts-at-one;
-ti,invert-autoidle-bit;
};
iva_dpll_hs_clk_div: iva_dpll_hs_clk_div {
@@ -335,10 +311,8 @@
compatible = "ti,divider
Re: [PATCH 2/2] ARM: DTS: omap54xx-clocks: Correct abe_iclk clock node
On 04/30/2014 03:31 PM, Tero Kristo wrote:
On 04/30/2014 02:41 PM, Peter Ujfalusi wrote:
abe_iclk's parent is aess_fclk and not abe_clk.
Also correct the parameters for clock rate calculation as used for OMAP4
since in PRCM level there's no difference between the two platform
regarding to AESS/ABE clocking.
Signed-off-by: Peter Ujfalusi
Acked-by: Tero Kristo
Queued also for 3.15-rc/clk-dt.
-Tero
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index d784ff5d3904..86fc507a0567 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -143,10 +143,11 @@
abe_iclk: abe_iclk {
#clock-cells = <0>;
-compatible = "fixed-factor-clock";
-clocks = <&abe_clk>;
-clock-mult = <1>;
-clock-div = <2>;
+compatible = "ti,divider-clock";
+clocks = <&aess_fclk>;
+ti,bit-shift = <24>;
+reg = <0x0528>;
+ti,dividers = <2>, <1>;
};
abe_lp_clk_div: abe_lp_clk_div {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
