Re: [RESEND 2/2] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
Hi Javier,
On 06/27/2014 09:23 PM, Javier Martinez Canillas wrote:
> Hello Peter,
>
> On Fri, Jun 27, 2014 at 8:01 AM, Peter Ujfalusi wrote:
>> Palmas class of devices can provide 32K clock(s) to be used by other devices
>> on the board. Depending on the actual device the provided clocks can be:
>> CLK32K_KG and CLK32K_KGAUDIO
>> or only one:
>> CLK32K_KG (TPS659039 for example)
>>
>> Use separate compatible flags for the two 32K clock.
>> A system which needs or have only one of the 32k clock from
>> Palmas will need to add node(s) for each clock as separate section
>> in the dts file.
>> The two compatible property is:
>> "ti,palmas-clk32kg" for clk32kg clock
>> "ti,palmas-clk32kgaudio" for clk32kgaudio clock
>>
>> Apart from the register control of the clocks - which is done via
>> the clock API there is a posibility to enable the external sleep
>> control. In this way the clock can be enabled/disabled on demand by the
>> user of the clock.
>>
>> See the documentation for more details.
>>
>> Signed-off-by: Peter Ujfalusi
>> Reviewed-by: Nishanth Menon
>> +static unsigned long palmas_clks_recalc_rate(struct clk_hw *hw,
>> +unsigned long parent_rate)
>> +{
>> + return 32768;
>> +}
>
> I see that other clock drivers using a constant rate return 0 if the
> clock has not been enabled.
and there are examples when similar fixed clock drivers returns only the clock
value, like clk-max77686. I can not find clear guidelines neither in the
documentation or around the header/c files for this.
Mike, what is the appropriate way of handling the recalc_rate?
> So maybe is more correct to have something
> like the following?
>
> if (__clk_is_enabled(hw->clk))
> return 32768;
> else
> return 0;
>
> Best regards,
> Javier
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND 0/2] clk: Support for Palmas clk32kg and clk32kgaudio clocks
Hi Mike, This is a resend of the v2 version of the palmas clock driver which seamingly missed the 3.16 merge window. I have added Nishanth's Reviewed-by tag to the patches. Changes since v1: - binding documentation and driver has been separated based on Nishanth Menon's comment v2 of the series: https://lkml.org/lkml/2014/5/6/323 v1 of the driver can be found: https://lkml.org/lkml/2014/4/3/104 Palmas class of devices can provide 32K clock(s) to be used by other devices on the board. Depending on the actual device the provided clocks can be: CLK32K_KG and CLK32K_KGAUDIO or only one: CLK32K_KG (TPS659039 for example) Use separate compatible flags for the two 32K clock. A system which needs or have only one of the 32k clock from Palmas will need to add node(s) for each clock as separate section in the dts file. The two compatible property is: "ti,palmas-clk32kg" for clk32kg clock "ti,palmas-clk32kgaudio" for clk32kgaudio clock Apart from the register control of the clocks - which is done via the clock API there is a posibility to enable the external sleep control. In this way the clock can be enabled/disabled on demand by the user of the clock. Regards, Peter --- Peter Ujfalusi (2): dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio clocks clk: Add driver for Palmas clk32kg and clk32kgaudio clocks .../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35 +++ drivers/clk/Kconfig| 7 + drivers/clk/Makefile | 1 + drivers/clk/clk-palmas.c | 307 + include/dt-bindings/mfd/palmas.h | 18 ++ 5 files changed, 368 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt create mode 100644 drivers/clk/clk-palmas.c create mode 100644 include/dt-bindings/mfd/palmas.h -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND 2/2] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
Palmas class of devices can provide 32K clock(s) to be used by other devices
on the board. Depending on the actual device the provided clocks can be:
CLK32K_KG and CLK32K_KGAUDIO
or only one:
CLK32K_KG (TPS659039 for example)
Use separate compatible flags for the two 32K clock.
A system which needs or have only one of the 32k clock from
Palmas will need to add node(s) for each clock as separate section
in the dts file.
The two compatible property is:
"ti,palmas-clk32kg" for clk32kg clock
"ti,palmas-clk32kgaudio" for clk32kgaudio clock
Apart from the register control of the clocks - which is done via
the clock API there is a posibility to enable the external sleep
control. In this way the clock can be enabled/disabled on demand by the
user of the clock.
See the documentation for more details.
Signed-off-by: Peter Ujfalusi
Reviewed-by: Nishanth Menon
---
drivers/clk/Kconfig | 7 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-palmas.c | 307 +++
3 files changed, 315 insertions(+)
create mode 100644 drivers/clk/clk-palmas.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9f9c5ae5359b..cfd3af7b2cbd 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -102,6 +102,13 @@ config COMMON_CLK_KEYSTONE
Supports clock drivers for Keystone based SOCs. These SOCs have local
a power sleep control module that gate the clock to the IPs and PLLs.
+config COMMON_CLK_PALMAS
+ tristate "Clock driver for TI Palmas devices"
+ depends on MFD_PALMAS
+ ---help---
+ This driver supports TI Palmas devices 32KHz output KG and KG_AUDIO
+ using common clock framework.
+
source "drivers/clk/qcom/Kconfig"
endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 567f10259029..312742c10661 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
+obj-$(CONFIG_COMMON_CLK_PALMAS)+= clk-palmas.o
obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
diff --git a/drivers/clk/clk-palmas.c b/drivers/clk/clk-palmas.c
new file mode 100644
index ..781630e1372b
--- /dev/null
+++ b/drivers/clk/clk-palmas.c
@@ -0,0 +1,307 @@
+/*
+ * Clock driver for Palmas device.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation.
+ * Copyright (c) 2013-2014 Texas Instruments, Inc.
+ *
+ * Author: Laxman Dewangan
+ * Peter Ujfalusi
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PALMAS_CLOCK_DT_EXT_CONTROL_ENABLE11
+#define PALMAS_CLOCK_DT_EXT_CONTROL_ENABLE22
+#define PALMAS_CLOCK_DT_EXT_CONTROL_NSLEEP 3
+
+struct palmas_clk32k_desc {
+ const char *clk_name;
+ unsigned int control_reg;
+ unsigned int enable_mask;
+ unsigned int sleep_mask;
+ unsigned int sleep_reqstr_id;
+ int delay;
+};
+
+struct palmas_clock_info {
+ struct device *dev;
+ struct clk *clk;
+ struct clk_hw hw;
+ struct palmas *palmas;
+ struct palmas_clk32k_desc *clk_desc;
+ int ext_control_pin;
+};
+
+static inline struct palmas_clock_info *to_palmas_clks_info(struct clk_hw *hw)
+{
+ return container_of(hw, struct palmas_clock_info, hw);
+}
+
+static unsigned long palmas_clks_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ return 32768;
+}
+
+static int palmas_clks_prepare(struct clk_hw *hw)
+{
+ struct palmas_clock_info *cinfo = to_palmas_clks_info(hw);
+ int ret;
+
+ ret = palmas_update_bits(cinfo->palmas, PALMAS_RESOURCE_BASE,
+cinfo->clk_desc->control_reg,
+cinfo->clk_desc->enable_mask,
+cinfo->clk_desc->enable_mask);
+ if (ret < 0)
+ dev_err(cinfo->dev, "Reg 0x%02x update failed, %d\n",
+ cinfo->clk_desc->control_reg, ret);
+ else if (cinfo->clk_desc->delay)
+ udelay(cinfo->clk_desc->d
[RESEND 1/2] dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio clocks
Palmas class of devices can provide 32K clock(s) to be used by other devices
on the board. Depending on the actual device the provided clocks can be:
CLK32K_KG and CLK32K_KGAUDIO
or only one:
CLK32K_KG (TPS659039 for example)
Use separate compatible flags for the two 32K clock.
A system which needs or have only one of the 32k clock from
Palmas will need to add node(s) for each clock as separate section
in the dts file.
The two compatible property is:
"ti,palmas-clk32kg" for clk32kg clock
"ti,palmas-clk32kgaudio" for clk32kgaudio clock
Apart from the register control of the clocks - which is done via
the clock API there is a posibility to enable the external sleep
control. In this way the clock can be enabled/disabled on demand by the
user of the clock.
Signed-off-by: Peter Ujfalusi
Reviewed-by: Nishanth Menon
---
.../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35 ++
include/dt-bindings/mfd/palmas.h | 18 +++
2 files changed, 53 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt
create mode 100644 include/dt-bindings/mfd/palmas.h
diff --git
a/Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt
b/Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt
new file mode 100644
index ..4208886d834a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt
@@ -0,0 +1,35 @@
+* Palmas 32KHz clocks *
+
+Palmas device has two clock output pins for 32KHz, KG and KG_AUDIO.
+
+This binding uses the common clock binding ./clock-bindings.txt.
+
+Required properties:
+- compatible : "ti,palmas-clk32kg" for clk32kg clock
+ "ti,palmas-clk32kgaudio" for clk32kgaudio clock
+- #clock-cells : shall be set to 0.
+
+Optional property:
+- ti,external-sleep-control: The external enable input pins controlled the
+ enable/disable of clocks. The external enable input pins ENABLE1,
+ ENABLE2 and NSLEEP. The valid values for the external pins are:
+ PALMAS_EXT_CONTROL_PIN_ENABLE1 for ENABLE1 pin
+ PALMAS_EXT_CONTROL_PIN_ENABLE2 for ENABLE2 pin
+ PALMAS_EXT_CONTROL_PIN_NSLEEP for NSLEEP pin
+ Option 0 or missing this property means the clock is enabled/disabled
+ via register access and these pins do not have any control.
+ The macros of external control pins for DTS is defined at
+ dt-bindings/mfd/palmas.h
+
+Example:
+ #include
+ ...
+ palmas: tps65913@58 {
+ ...
+ clk32kg: palmas_clk32k@0 {
+ compatible = "ti,palmas-clk32kg";
+ #clock-cells = <0>;
+ ti,external-sleep-control =
;
+ };
+ ...
+ };
diff --git a/include/dt-bindings/mfd/palmas.h b/include/dt-bindings/mfd/palmas.h
new file mode 100644
index ..2c8ac4841385
--- /dev/null
+++ b/include/dt-bindings/mfd/palmas.h
@@ -0,0 +1,18 @@
+/*
+ * This header provides macros for Palmas device bindings.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation.
+ *
+ * Author: Laxman Dewangan
+ *
+ */
+
+#ifndef __DT_BINDINGS_PALMAS_H__
+#define __DT_BINDINGS_PALMAS_H
+
+/* External control pins */
+#define PALMAS_EXT_CONTROL_PIN_ENABLE1 1
+#define PALMAS_EXT_CONTROL_PIN_ENABLE2 2
+#define PALMAS_EXT_CONTROL_PIN_NSLEEP 3
+
+#endif /* __DT_BINDINGS_PALMAS_H */
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] sound/soc/omap/mcbsp.c: remove unnecessary null test before kfree
Hi Fabian, On 06/23/2014 07:33 PM, Fabian Frederick wrote: > Fix checkpatch warning: > WARNING: kfree(NULL) is safe this check is probably not required can you send the same patch to alsa-devel with subject: ASoC: mcbsp: remove unnecessary null test before kfree You can add my: Acked-by: Peter Ujfalusi > > Cc: Peter Ujfalusi > Cc: Jarkko Nikula > Cc: linux-omap@vger.kernel.org > Signed-off-by: Fabian Frederick > --- > sound/soc/omap/mcbsp.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c > index 86c7538..68a1252 100644 > --- a/sound/soc/omap/mcbsp.c > +++ b/sound/soc/omap/mcbsp.c > @@ -621,8 +621,7 @@ void omap_mcbsp_free(struct omap_mcbsp *mcbsp) > mcbsp->reg_cache = NULL; > spin_unlock(&mcbsp->lock); > > - if (reg_cache) > - kfree(reg_cache); > + kfree(reg_cache); > } > > /* > -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/10] platform_data: edma: Be precise with the paRAM struct
On 05/27/2014 06:03 PM, Joel Fernandes wrote: > On 05/27/2014 05:22 AM, Peter Ujfalusi wrote: >> On 05/27/2014 12:32 AM, Olof Johansson wrote: > [..] >>> >>> I came across this patch when I was looking at a pull request from >>> Sekhar for EDMA cleanups, and it made me look closer at the contents >>> of this file. >>> >>> The include/linux/platform_data/ directory is meant to hold >>> platform_data definitions for drivers, and nothing more. >>> platform_data/edma.h also contains a whole bunch of interface >>> definitions for the driver. They do not belong there, and should be >>> moved to a different include file. >>> >>> That also includes the above struct, because as far as I can tell it's >>> a runtime state structure, not something that is passed in with >>> platform data. >>> >>> Can someone please clean this up? Thanks. >> >> I think Joel is working on to move/merge the code from arch/arm/common/edma.c >> to drivers/dma/edma.c > > Yes, I am planning to work on that soon. But there is an issue, more on > that discussed below.. > >> I'm sure within this work he is going to clean up the header file as well. > > Agreed. The private API should not be expored in any header and should > be exclusive for the EDMA dmaengine driver ideally. > >> As a first step I think the non platform_data content can be moved as >> include/linux/edma.h or probably as ti-edma.h? >> > > sound/soc/davinci/davinci-pcm.c: This still uses the EDMA private API in > arch/arm/common/edma.c. Peter, any idea when the private usage will be > removed fully, and we switch to dmaengine for ASoC? Before that can > happen, we can't clean up or do any merges. We have the edma-pcm platform driver upstream already which I'm using locally for a long time now on AM335x/AM437x. I'm planning to send a patch to do the same upstream after the 3.16 window closes. But, davinci-pcm has a mode called 'ping-pong' which is not available via dmaengine and this mode is used by several daVinci SoCs to overcome buffer underflow/overflow issues. This mode essentially means in playback case: dma_ch1 dma_ch2 SDRAM ---> SRAM ---> McASP ch1 is to move a block of samples to SRAM from where ch2 will copy the samples word by word to McASP. If we move all davinci SoCs to use the edma-pcm, we are going to loose this mode. As a note: the edma-pcm is confirmed to work fine on the tested daVinci boards. I think what we need to do first: find a board which is using ping-pong mode, put under stress test in: - davinci-pcm, ping-pong mode - davinci-pcm, no ping-pong mode - edma-pcm and see how edma-pcm behaves compared to the davinci-pcm. One of the issue with davinci-pcm is that in non ping-pong mode it reconfigures the eDMA after every period, which is a bad thing. The dmaengine implementation does not need to do that, so we might be fine there. > What I'd like to do is fold the private API into the dmaengine driver > and eliminate the need to expose the private API, thus also getting rid > of the interface declarations Olof referred to. > > thanks, > > -Joel > -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/10] platform_data: edma: Be precise with the paRAM struct
On 05/27/2014 12:32 AM, Olof Johansson wrote:
> Hi,
>
> On Mon, Apr 14, 2014 at 4:41 AM, Peter Ujfalusi wrote:
>> The edmacc_param struct should follow the layout of the paRAM area in the
>> HW. Be explicit on the size of the fields (u32) and also mark the struct
>> as packed to avoid any padding on non 32bit architectures.
>>
>> Signed-off-by: Peter Ujfalusi
>> Acked-by: Joel Fernandes
>> ---
>> include/linux/platform_data/edma.h | 18 +-
>> 1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/include/linux/platform_data/edma.h
>> b/include/linux/platform_data/edma.h
>> index f50821cb64be..923f8a3e4ce0 100644
>> --- a/include/linux/platform_data/edma.h
>> +++ b/include/linux/platform_data/edma.h
>> @@ -43,15 +43,15 @@
>>
>> /* PaRAM slots are laid out like this */
>> struct edmacc_param {
>> - unsigned int opt;
>> - unsigned int src;
>> - unsigned int a_b_cnt;
>> - unsigned int dst;
>> - unsigned int src_dst_bidx;
>> - unsigned int link_bcntrld;
>> - unsigned int src_dst_cidx;
>> - unsigned int ccnt;
>> -};
>> + u32 opt;
>> + u32 src;
>> + u32 a_b_cnt;
>> + u32 dst;
>> + u32 src_dst_bidx;
>> + u32 link_bcntrld;
>> + u32 src_dst_cidx;
>> + u32 ccnt;
>> +} __packed;
>>
>> /* fields in edmacc_param.opt */
>> #define SAMBIT(0)
>
> I came across this patch when I was looking at a pull request from
> Sekhar for EDMA cleanups, and it made me look closer at the contents
> of this file.
>
> The include/linux/platform_data/ directory is meant to hold
> platform_data definitions for drivers, and nothing more.
> platform_data/edma.h also contains a whole bunch of interface
> definitions for the driver. They do not belong there, and should be
> moved to a different include file.
>
> That also includes the above struct, because as far as I can tell it's
> a runtime state structure, not something that is passed in with
> platform data.
>
> Can someone please clean this up? Thanks.
I think Joel is working on to move/merge the code from arch/arm/common/edma.c
to drivers/dma/edma.c
I'm sure within this work he is going to clean up the header file as well.
As a first step I think the non platform_data content can be moved as
include/linux/edma.h or probably as ti-edma.h?
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: omap-pcm: Move omap-pcm under include/sound
On 05/26/2014 11:51 AM, Jyri Sarha wrote:
> Make including the omap-pcm.h outside sound/soc/omap more convenient.
Acked-by: Peter Ujfalusi
>
> Signed-off-by: Jyri Sarha
> ---
> It would be nice to get this applied at ASAP for OMAP HDMI audio
> rework patches depend on this and it would help a lot if this would
> already be there when applying to OMAPDSS side patches.
>
> include/sound/omap-pcm.h | 30 ++
> sound/soc/davinci/davinci-mcasp.c |2 +-
> sound/soc/omap/omap-dmic.c|2 +-
> sound/soc/omap/omap-hdmi.c|2 +-
> sound/soc/omap/omap-mcbsp.c |2 +-
> sound/soc/omap/omap-mcpdm.c |2 +-
> sound/soc/omap/omap-pcm.h | 30 --
> 7 files changed, 35 insertions(+), 35 deletions(-)
> create mode 100644 include/sound/omap-pcm.h
> delete mode 100644 sound/soc/omap/omap-pcm.h
>
> diff --git a/include/sound/omap-pcm.h b/include/sound/omap-pcm.h
> new file mode 100644
> index 000..c1d2f31
> --- /dev/null
> +++ b/include/sound/omap-pcm.h
> @@ -0,0 +1,30 @@
> +/*
> + * omap-pcm.h - OMAP PCM driver
> + *
> + * Copyright (C) 2014 Texas Instruments, Inc.
> + *
> + * Author: Peter Ujfalusi
> + *
> + * 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 in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#ifndef __OMAP_PCM_H__
> +#define __OMAP_PCM_H__
> +
> +#if IS_ENABLED(CONFIG_SND_OMAP_SOC)
> +int omap_pcm_platform_register(struct device *dev);
> +#else
> +static inline int omap_pcm_platform_register(struct device *dev)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_SND_OMAP_SOC */
> +
> +#endif /* __OMAP_PCM_H__ */
> diff --git a/sound/soc/davinci/davinci-mcasp.c
> b/sound/soc/davinci/davinci-mcasp.c
> index 14058dc..9afb146 100644
> --- a/sound/soc/davinci/davinci-mcasp.c
> +++ b/sound/soc/davinci/davinci-mcasp.c
> @@ -33,10 +33,10 @@
> #include
> #include
> #include
> +#include
>
> #include "davinci-pcm.h"
> #include "davinci-mcasp.h"
> -#include "../omap/omap-pcm.h"
>
> #define MCASP_MAX_AFIFO_DEPTH64
>
> diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
> index 53da041..6925d71 100644
> --- a/sound/soc/omap/omap-dmic.c
> +++ b/sound/soc/omap/omap-dmic.c
> @@ -40,9 +40,9 @@
> #include
> #include
> #include
> +#include
>
> #include "omap-dmic.h"
> -#include "omap-pcm.h"
>
> struct omap_dmic {
> struct device *dev;
> diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
> index 537a1ec..eb9c392 100644
> --- a/sound/soc/omap/omap-hdmi.c
> +++ b/sound/soc/omap/omap-hdmi.c
> @@ -34,9 +34,9 @@
> #include
> #include
> #include
> +#include
>
> #include "omap-hdmi.h"
> -#include "omap-pcm.h"
>
> #define DRV_NAME "omap-hdmi-audio-dai"
>
> diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
> index 71d2266..efe2cd6 100644
> --- a/sound/soc/omap/omap-mcbsp.c
> +++ b/sound/soc/omap/omap-mcbsp.c
> @@ -34,11 +34,11 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include "mcbsp.h"
> #include "omap-mcbsp.h"
> -#include "omap-pcm.h"
>
> #define OMAP_MCBSP_RATES (SNDRV_PCM_RATE_8000_96000)
>
> diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
> index d8ebb52..f0e2ebe 100644
> --- a/sound/soc/omap/omap-mcpdm.c
> +++ b/sound/soc/omap/omap-mcpdm.c
> @@ -40,9 +40,9 @@
> #include
> #include
> #include
> +#include
>
> #include "omap-mcpdm.h"
> -#include "omap-pcm.h"
>
> struct mcpdm_link_config {
> u32 link_mask; /* channel mask for the direction */
> diff --git a/sound/soc/omap/omap-pcm.h b/sound/soc/omap/omap-pcm.h
> deleted file mode 100644
> index c1d2f31..000
> --- a/sound/soc/omap/omap-pcm.h
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -/*
> - * omap-pcm.h - OMAP PCM driver
> - *
> - * Copyright (C) 2014 Texas Instruments, Inc.
> - *
> - * Author: Peter Ujfalusi
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General
Re: [PATCH v2 0/2] clk: Support for Palmas clk32kg and clk32kgaudio clocks
Mike, On 05/06/2014 04:31 PM, Nishanth Menon wrote: > On 16:24-20140506, Peter Ujfalusi wrote: >> Hi, >> >> Changes since v1: >> - binding documentation and driver has been separated based on Nishanth >> Menon's >> comment Could you take a look at this series please? I really hoped that it would make it to 3.16... Thanks, Péter >> >> v1 of the driver can be found: >> https://lkml.org/lkml/2014/4/3/104 >> >> Palmas class of devices can provide 32K clock(s) to be used by other devices >> on the board. Depending on the actual device the provided clocks can be: >> CLK32K_KG and CLK32K_KGAUDIO >> or only one: >> CLK32K_KG (TPS659039 for example) >> >> Use separate compatible flags for the two 32K clock. >> A system which needs or have only one of the 32k clock from >> Palmas will need to add node(s) for each clock as separate section >> in the dts file. >> The two compatible property is: >> "ti,palmas-clk32kg" for clk32kg clock >> "ti,palmas-clk32kgaudio" for clk32kgaudio clock >> >> Apart from the register control of the clocks - which is done via >> the clock API there is a posibility to enable the external sleep >> control. In this way the clock can be enabled/disabled on demand by the >> user of the clock. >> >> Regards, >> Peter >> --- >> Peter Ujfalusi (2): >> dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio >> clocks >> clk: Add driver for Palmas clk32kg and clk32kgaudio clocks >> >> .../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35 +++ >> drivers/clk/Kconfig| 7 + >> drivers/clk/Makefile | 1 + >> drivers/clk/clk-palmas.c | 307 >> + >> include/dt-bindings/mfd/palmas.h | 18 ++ >> 5 files changed, 368 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt >> create mode 100644 drivers/clk/clk-palmas.c >> create mode 100644 include/dt-bindings/mfd/palmas.h >> >> -- >> 1.9.2 >> > > Series: > Reviewed-by: Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/13] ARM/DT: edma: IP configuration from hardware and cleanups
On 05/19/2014 04:06 PM, Sekhar Nori wrote: > On Friday 16 May 2014 05:47 PM, Peter Ujfalusi wrote: >> Hi, >> >> Changes since v2: >> - Comments from Sekhar and Arnd has been addressed best as I could. >> - Use the CCCFG information in all cases instead of pdata provided >> information >> - To achieve this I needed to do a bit more cleanup in this series >> - In the documentation patch, retrain the old properties for reference >> - Cleanups in the old davinci board files and removing edma_soc_info members >> >> Changes sicne v1: >> - added missing patch to remove the memset from edma_of_parse_dt() >> >> We are requesting redundant information via DT for the driver since the very >> same >> data is available in the HW: by reading and decoding the content of CCCFG >> register we can get: >> Number of channels: NUM_DMACH >> Number of regions: NUM_REGN >> Number of slots (PaRAM sets): NUM_PAENTRY >> Number of TC/EQ: NUM_EVQUE >> >> So these does not need to be provided by the DT binding. >> >> The driver will no longer look for these properties from DT and they can be >> removed from the binding documentation and from the dtsi files as well. >> The change will not introduce regression when new kernel is booted using >> older >> DTB (since we just ignore the mentioned properties). > > Applied all patches and pushed to branch v3.16/edma of: > > git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git > > Since the patches did not apply cleanly, please verify. I tested on > DA850 EVM using MMC/SD as EDMA user. The patches in this series looks OK in your branch. However I can not find the following commits in there, which I have in linux-next: c689a7b79c28 Merge remote-tracking branch 'slave-dma/next' cdae05a0f0f7 dmaengine: edma: Make reading the position of active channels work cf7eb979116c ARM: common: edma: Fix xbar mapping 232b223d8281 dmaengine: edma: Set DMA_CYCLIC capability flag 7cf2af90cd51 arm: common: edma: Save the number of event queues/TCs They might come via different route... > > I will wait to get acks from DT maintainers before sending to ARM-SoC. > > Thanks, > Sekhar > Thanks, Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 02/13] ARM: edma: Take the number of tc from edma_soc_info (pdata)
On 05/19/2014 02:07 PM, Sekhar Nori wrote: > To which baseline do the patches apply? These lines are not present at > least in v3.15-rc5. I am applying the patch without this hunk. It is generate on top of linux-next-20140515. next picked up several patches since 3.15-rc and I also have my other patch in my working branch under this series: ARM: edma: Clean up and simplify the code around irq request -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 01/13] ARM: edma: No need to clean the pdata in edma_of_parse_dt()
The pdata has been just allocated with devm_kzalloc() in edma_setup_info_from_dt() and passed to this function. Signed-off-by: Peter Ujfalusi --- arch/arm/common/edma.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 8452cf246330..01707aae0a2b 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1472,8 +1472,6 @@ static int edma_of_parse_dt(struct device *dev, struct edma_rsv_info *rsv_info; s8 (*queue_tc_map)[2], (*queue_priority_map)[2]; - memset(pdata, 0, sizeof(struct edma_soc_info)); - ret = of_property_read_u32(node, "dma-channels", &value); if (ret < 0) return ret; -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 00/13] ARM/DT: edma: IP configuration from hardware and cleanups
Hi, Changes since v2: - Comments from Sekhar and Arnd has been addressed best as I could. - Use the CCCFG information in all cases instead of pdata provided information - To achieve this I needed to do a bit more cleanup in this series - In the documentation patch, retrain the old properties for reference - Cleanups in the old davinci board files and removing edma_soc_info members Changes sicne v1: - added missing patch to remove the memset from edma_of_parse_dt() We are requesting redundant information via DT for the driver since the very same data is available in the HW: by reading and decoding the content of CCCFG register we can get: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE So these does not need to be provided by the DT binding. The driver will no longer look for these properties from DT and they can be removed from the binding documentation and from the dtsi files as well. The change will not introduce regression when new kernel is booted using older DTB (since we just ignore the mentioned properties). Regards, Peter --- Peter Ujfalusi (13): ARM: edma: No need to clean the pdata in edma_of_parse_dt() ARM: edma: Take the number of tc from edma_soc_info (pdata) ARM: edma: Do not change TC -> Queue mapping, leave it to default. ARM: davinci: Remove eDMA3 queue_tc_mapping data from edma_soc_info ARM/platform_data: edma: Remove queue_tc_mapping data from edma_soc_info ARM: edma: Remove num_cc member from struct edma ARM: edma: Save number of regions from pdata to struct edma ARM: edma: Get IP configuration from HW (number of channels, tc, etc) dt/bindings: ti,edma: Remove redundant properties from documentation ARM: dts: am33xx: Remove obsolete properties from edma node ARM: dts: am4372: Remove obsolete properties from edma node ARM: davinci: Remove redundant/unused parameters for edma ARM/platform_data: edma: Remove redundant/unused parameters from edma_soc_info Documentation/devicetree/bindings/dma/ti-edma.txt | 13 +- arch/arm/boot/dts/am33xx.dtsi | 3 - arch/arm/boot/dts/am4372.dtsi | 3 - arch/arm/common/edma.c| 149 +++--- arch/arm/mach-davinci/devices-da8xx.c | 31 - arch/arm/mach-davinci/dm355.c | 14 -- arch/arm/mach-davinci/dm365.c | 16 --- arch/arm/mach-davinci/dm644x.c| 14 -- arch/arm/mach-davinci/dm646x.c| 16 --- include/linux/platform_data/edma.h| 8 -- 10 files changed, 81 insertions(+), 186 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 03/13] ARM: edma: Do not change TC -> Queue mapping, leave it to default.
There is no need to change the default TC -> Queue mapping. By default the
mapping is: TC0 -> Q0, TC1 -> Q1, etc.
Changing this has no benefits at all and all the board files are just setting
the same mapping back to the HW.
Signed-off-by: Peter Ujfalusi
---
arch/arm/common/edma.c | 28 +---
1 file changed, 1 insertion(+), 27 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index d42c84a3432a..0bc5ed6fc249 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -290,12 +290,6 @@ static void map_dmach_queue(unsigned ctlr, unsigned ch_no,
~(0x7 << bit), queue_no << bit);
}
-static void __init map_queue_tc(unsigned ctlr, int queue_no, int tc_no)
-{
- int bit = queue_no * 4;
- edma_modify(ctlr, EDMA_QUETCMAP, ~(0x7 << bit), ((tc_no & 0x7) << bit));
-}
-
static void __init assign_priority_to_queue(unsigned ctlr, int queue_no,
int priority)
{
@@ -1470,7 +1464,7 @@ static int edma_of_parse_dt(struct device *dev,
struct property *prop;
size_t sz;
struct edma_rsv_info *rsv_info;
- s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+ s8 (*queue_priority_map)[2];
ret = of_property_read_u32(node, "dma-channels", &value);
if (ret < 0)
@@ -1495,19 +1489,6 @@ static int edma_of_parse_dt(struct device *dev,
return -ENOMEM;
pdata->rsv = rsv_info;
- queue_tc_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
- if (!queue_tc_map)
- return -ENOMEM;
-
- for (i = 0; i < 3; i++) {
- queue_tc_map[i][0] = i;
- queue_tc_map[i][1] = i;
- }
- queue_tc_map[i][0] = -1;
- queue_tc_map[i][1] = -1;
-
- pdata->queue_tc_mapping = queue_tc_map;
-
queue_priority_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
if (!queue_priority_map)
return -ENOMEM;
@@ -1568,7 +1549,6 @@ static int edma_probe(struct platform_device *pdev)
struct edma_soc_info**info = pdev->dev.platform_data;
struct edma_soc_info*ninfo[EDMA_MAX_CC] = {NULL};
s8 (*queue_priority_mapping)[2];
- s8 (*queue_tc_mapping)[2];
int i, j, off, ln, found = 0;
int status = -1;
const s16 (*rsv_chans)[2];
@@ -1735,14 +1715,8 @@ static int edma_probe(struct platform_device *pdev)
for (i = 0; i < edma_cc[j]->num_channels; i++)
map_dmach_queue(j, i, info[j]->default_queue);
- queue_tc_mapping = info[j]->queue_tc_mapping;
queue_priority_mapping = info[j]->queue_priority_mapping;
- /* Event queue to TC mapping */
- for (i = 0; queue_tc_mapping[i][0] != -1; i++)
- map_queue_tc(j, queue_tc_mapping[i][0],
- queue_tc_mapping[i][1]);
-
/* Event queue priority mapping */
for (i = 0; queue_priority_mapping[i][0] != -1; i++)
assign_priority_to_queue(j,
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 05/13] ARM/platform_data: edma: Remove queue_tc_mapping data from edma_soc_info
It is no longer in use by the driver or board files.
Signed-off-by: Peter Ujfalusi
---
include/linux/platform_data/edma.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index 12f134b1493c..633e196ebdf2 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -175,7 +175,6 @@ struct edma_soc_info {
/* Resource reservation for other cores */
struct edma_rsv_info*rsv;
- s8 (*queue_tc_mapping)[2];
s8 (*queue_priority_mapping)[2];
const s16 (*xbar_chans)[2];
};
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 02/13] ARM: edma: Take the number of tc from edma_soc_info (pdata)
Instead of saving the for loop length, take the num_tc value from the pdata. In case of DT boot set the n_tc to 3 as it is hardwired in edma_of_parse_dt() This is a temporary state since upcoming patch(es) will change how we are dealing with these parameters. Signed-off-by: Peter Ujfalusi --- arch/arm/common/edma.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 01707aae0a2b..d42c84a3432a 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1488,6 +1488,7 @@ static int edma_of_parse_dt(struct device *dev, pdata->n_slot = value; pdata->n_cc = 1; + pdata->n_tc = 3; rsv_info = devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL); if (!rsv_info) @@ -1648,6 +1649,7 @@ static int edma_probe(struct platform_device *pdev) EDMA_MAX_PARAMENTRY); edma_cc[j]->num_cc = min_t(unsigned, info[j]->n_cc, EDMA_MAX_CC); + edma_cc[j]->num_tc = info[j]->n_tc; edma_cc[j]->default_queue = info[j]->default_queue; @@ -1741,9 +1743,6 @@ static int edma_probe(struct platform_device *pdev) map_queue_tc(j, queue_tc_mapping[i][0], queue_tc_mapping[i][1]); - /* Save the number of TCs */ - edma_cc[j]->num_tc = i; - /* Event queue priority mapping */ for (i = 0; queue_priority_mapping[i][0] != -1; i++) assign_priority_to_queue(j, -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 07/13] ARM: edma: Save number of regions from pdata to struct edma
To be consistent in the code that we take parameters from edma_cc[j] struct
and not randomly from info[j] as well.
Signed-off-by: Peter Ujfalusi
---
arch/arm/common/edma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 929a03e4749c..aa9473cb0c23 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1628,6 +1628,7 @@ static int edma_probe(struct platform_device *pdev)
edma_cc[j]->num_tc = info[j]->n_tc;
edma_cc[j]->default_queue = info[j]->default_queue;
+ edma_cc[j]->num_region = info[j]->n_region;
dev_dbg(&pdev->dev, "DMA REG BASE ADDR=%p\n",
edmacc_regs_base[j]);
@@ -1725,7 +1726,7 @@ static int edma_probe(struct platform_device *pdev)
if (edma_read(j, EDMA_CCCFG) & CHMAP_EXIST)
map_dmach_param(j);
- for (i = 0; i < info[j]->n_region; i++) {
+ for (i = 0; i < edma_cc[j]->num_region; i++) {
edma_write_array2(j, EDMA_DRAE, i, 0, 0x0);
edma_write_array2(j, EDMA_DRAE, i, 1, 0x0);
edma_write_array(j, EDMA_QRAE, i, 0x0);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 04/13] ARM: davinci: Remove eDMA3 queue_tc_mapping data from edma_soc_info
It is ignored by the edma driver since we are just setting back the default
mapping of TC -> Queue.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-davinci/devices-da8xx.c | 16
arch/arm/mach-davinci/dm355.c | 9 -
arch/arm/mach-davinci/dm365.c | 11 ---
arch/arm/mach-davinci/dm644x.c| 9 -
arch/arm/mach-davinci/dm646x.c| 11 ---
5 files changed, 56 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 56ea41d5f849..7f376e54b266 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -134,13 +134,6 @@ struct platform_device da8xx_serial_device[] = {
}
};
-static s8 da8xx_queue_tc_mapping[][2] = {
- /* {event queue no, TC no} */
- {0, 0},
- {1, 1},
- {-1, -1}
-};
-
static s8 da8xx_queue_priority_mapping[][2] = {
/* {event queue no, Priority} */
{0, 3},
@@ -148,12 +141,6 @@ static s8 da8xx_queue_priority_mapping[][2] = {
{-1, -1}
};
-static s8 da850_queue_tc_mapping[][2] = {
- /* {event queue no, TC no} */
- {0, 0},
- {-1, -1}
-};
-
static s8 da850_queue_priority_mapping[][2] = {
/* {event queue no, Priority} */
{0, 3},
@@ -166,7 +153,6 @@ static struct edma_soc_info da830_edma_cc0_info = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
- .queue_tc_mapping = da8xx_queue_tc_mapping,
.queue_priority_mapping = da8xx_queue_priority_mapping,
.default_queue = EVENTQ_1,
};
@@ -182,7 +168,6 @@ static struct edma_soc_info da850_edma_cc_info[] = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
- .queue_tc_mapping = da8xx_queue_tc_mapping,
.queue_priority_mapping = da8xx_queue_priority_mapping,
.default_queue = EVENTQ_1,
},
@@ -192,7 +177,6 @@ static struct edma_soc_info da850_edma_cc_info[] = {
.n_slot = 128,
.n_tc = 1,
.n_cc = 1,
- .queue_tc_mapping = da850_queue_tc_mapping,
.queue_priority_mapping = da850_queue_priority_mapping,
.default_queue = EVENTQ_0,
},
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 07381d8cea62..e27f7ff54570 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -569,14 +569,6 @@ static u8 dm355_default_priorities[DAVINCI_N_AINTC_IRQ] = {
/*--*/
static s8
-queue_tc_mapping[][2] = {
- /* {event queue no, TC no} */
- {0, 0},
- {1, 1},
- {-1, -1},
-};
-
-static s8
queue_priority_mapping[][2] = {
/* {event queue no, Priority} */
{0, 3},
@@ -590,7 +582,6 @@ static struct edma_soc_info edma_cc0_info = {
.n_slot = 128,
.n_tc = 2,
.n_cc = 1,
- .queue_tc_mapping = queue_tc_mapping,
.queue_priority_mapping = queue_priority_mapping,
.default_queue = EVENTQ_1,
};
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 08a61b938333..88835b0aaead 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -853,16 +853,6 @@ static u8 dm365_default_priorities[DAVINCI_N_AINTC_IRQ] = {
/* Four Transfer Controllers on DM365 */
static s8
-dm365_queue_tc_mapping[][2] = {
- /* {event queue no, TC no} */
- {0, 0},
- {1, 1},
- {2, 2},
- {3, 3},
- {-1, -1},
-};
-
-static s8
dm365_queue_priority_mapping[][2] = {
/* {event queue no, Priority} */
{0, 7},
@@ -878,7 +868,6 @@ static struct edma_soc_info edma_cc0_info = {
.n_slot = 256,
.n_tc = 4,
.n_cc = 1,
- .queue_tc_mapping = dm365_queue_tc_mapping,
.queue_priority_mapping = dm365_queue_priority_mapping,
.default_queue = EVENTQ_3,
};
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 5debffba4b24..8ea34be879b4 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -499,14 +499,6 @@ static u8 dm644x_default_priorities[DAVINCI_N_AINTC_IRQ] =
{
/*--*/
static s8
-queue_tc_mapping[][2] = {
- /* {event queue no, TC no} */
- {0, 0},
- {1, 1},
- {-1, -1},
-};
-
-static s8
queue_priority_mapping[][2] = {
/* {event queue no, Priority} */
{0, 3},
@@ -520,7 +512,6 @@ static struct edma_soc_info edma_cc0_i
[PATCH v3 08/13] ARM: edma: Get IP configuration from HW (number of channels, tc, etc)
>From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
In case when booted with DT or the queue_priority_mapping is not provided
set up a default priority map.
Signed-off-by: Peter Ujfalusi
---
arch/arm/common/edma.c | 115 +++--
1 file changed, 73 insertions(+), 42 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index aa9473cb0c23..485be42519b9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -102,7 +102,13 @@
#define PARM_OFFSET(param_no) (EDMA_PARM + ((param_no) << 5))
#define EDMA_DCHMAP0x0100 /* 64 registers */
-#define CHMAP_EXISTBIT(24)
+
+/* CCCFG register */
+#define GET_NUM_DMACH(x) (x & 0x7) /* bits 0-2 */
+#define GET_NUM_PAENTRY(x) ((x & 0x7000) >> 12) /* bits 12-14 */
+#define GET_NUM_EVQUE(x) ((x & 0x7) >> 16) /* bits 16-18 */
+#define GET_NUM_REGN(x)((x & 0x30) >> 20) /* bits 20-21 */
+#define CHMAP_EXISTBIT(24)
#define EDMA_MAX_DMACH 64
#define EDMA_MAX_PARAMENTRY 512
@@ -1408,6 +1414,67 @@ void edma_clear_event(unsigned channel)
}
EXPORT_SYMBOL(edma_clear_event);
+static int edma_setup_from_hw(struct device *dev, struct edma_soc_info *pdata,
+ struct edma *edma_cc)
+{
+ int i;
+ u32 value, cccfg;
+ s8 (*queue_priority_map)[2];
+
+ /* Decode the eDMA3 configuration from CCCFG register */
+ cccfg = edma_read(0, EDMA_CCCFG);
+
+ value = GET_NUM_REGN(cccfg);
+ edma_cc->num_region = BIT(value);
+
+ value = GET_NUM_DMACH(cccfg);
+ edma_cc->num_channels = BIT(value + 1);
+
+ value = GET_NUM_PAENTRY(cccfg);
+ edma_cc->num_slots = BIT(value + 4);
+
+ value = GET_NUM_EVQUE(cccfg);
+ edma_cc->num_tc = value + 1;
+
+ dev_dbg(dev, "eDMA3 HW configuration (cccfg: 0x%08x):\n", cccfg);
+ dev_dbg(dev, "num_region: %u\n", edma_cc->num_region);
+ dev_dbg(dev, "num_channel: %u\n", edma_cc->num_channels);
+ dev_dbg(dev, "num_slot: %u\n", edma_cc->num_slots);
+ dev_dbg(dev, "num_tc: %u\n", edma_cc->num_tc);
+
+ /* Nothing need to be done if queue priority is provided */
+ if (pdata->queue_priority_mapping)
+ return 0;
+
+ /*
+* Configure TC/queue priority as follows:
+* Q0 - priority 0
+* Q1 - priority 1
+* Q2 - priority 2
+* ...
+* The meaning of priority numbers: 0 highest priority, 7 lowest
+* priority. So Q0 is the highest priority queue and the last queue has
+* the lowest priority.
+*/
+ queue_priority_map = devm_kzalloc(dev,
+ (edma_cc->num_tc + 1) * sizeof(s8),
+ GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+
+ for (i = 0; i < edma_cc->num_tc; i++) {
+ queue_priority_map[i][0] = i;
+ queue_priority_map[i][1] = i;
+ }
+ queue_priority_map[i][0] = -1;
+ queue_priority_map[i][1] = -1;
+
+ pdata->queue_priority_mapping = queue_priority_map;
+ pdata->default_queue = 0;
+
+ return 0;
+}
+
#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_DMADEVICES)
static int edma_xbar_event_map(struct device *dev, struct device_node *node,
@@ -1458,50 +1525,16 @@ static int edma_of_parse_dt(struct device *dev,
struct device_node *node,
struct edma_soc_info *pdata)
{
- int ret = 0, i;
- u32 value;
+ int ret = 0;
struct property *prop;
size_t sz;
struct edma_rsv_info *rsv_info;
- s8 (*queue_priority_map)[2];
-
- ret = of_property_read_u32(node, "dma-channels", &value);
- if (ret < 0)
- return ret;
- pdata->n_channel = value;
-
- ret = of_property_read_u32(node, "ti,edma-regions", &value);
- if (ret < 0)
- return ret;
- pdata->n_region = value;
-
- ret = of_property_read_u32(node, "ti,edma-slots", &value);
- if (ret < 0)
- return ret;
- pdata->n_slot = value;
-
- pdata->n_tc = 3;
rsv_info = devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
if (!rsv_info)
return -ENOMEM;
pdata->rsv = rsv_info;
- queue_priority_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
- if (!queue_priority_map)
- return -ENOMEM;
-
- for (i = 0; i < 3; i++) {
- queue_priori
[PATCH v3 09/13] dt/bindings: ti,edma: Remove redundant properties from documentation
>From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
The ti,edma-regions; ti,edma-slots and dma-channels in DT are
redundant since the very same information can be obtained from the HW.
The mentioned properties are deprecated.
Signed-off-by: Peter Ujfalusi
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 68ff2137bae7..5ba525a10035 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -2,11 +2,8 @@ TI EDMA
Required properties:
- compatible : "ti,edma3"
-- ti,edma-regions: Number of regions
-- ti,edma-slots: Number of slots
- #dma-cells: Should be set to <1>
Clients should use a single channel number per DMA request.
-- dma-channels: Specify total DMA channels per CC
- reg: Memory map for accessing module
- interrupt-parent: Interrupt controller the interrupt is routed through
- interrupts: Exactly 3 interrupts need to be specified in the order:
@@ -17,6 +14,13 @@ Optional properties:
- ti,hwmods: Name of the hwmods associated to the EDMA
- ti,edma-xbar-event-map: Crossbar event to channel map
+Deprecated properties:
+Listed here in case one wants to boot an old kernel with new DTB. These
+properties might need to be added to the new DTS files.
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- dma-channels: Specify total DMA channels per CC
+
Example:
edma: edma@4900 {
@@ -26,9 +30,6 @@ edma: edma@4900 {
compatible = "ti,edma3";
ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
#dma-cells = <1>;
- dma-channels = <64>;
- ti,edma-regions = <4>;
- ti,edma-slots = <256>;
ti,edma-xbar-event-map = /bits/ 16 <1 12
2 13>;
};
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 11/13] ARM: dts: am4372: Remove obsolete properties from edma node
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/am4372.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 03a225505126..b9f83b705f4b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -108,9 +108,6 @@
,
;
#dma-cells = <1>;
- dma-channels = <64>;
- ti,edma-regions = <4>;
- ti,edma-slots = <256>;
};
uart0: serial@44e09000 {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 12/13] ARM: davinci: Remove redundant/unused parameters for edma
The following parameters are no longer needed by the edma driver since the
information can be obtained from the IP's CCCFG register:
n_channel, n_region, n_slot and n_tc.
Remove the initialization of n_cc as well since in this context it has no
meaning. We have separate edma_soc_info struct/eDMA3_CC instance so this
member does not make any sense (and the driver no longer uses it).
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-davinci/devices-da8xx.c | 15 ---
arch/arm/mach-davinci/dm355.c | 5 -
arch/arm/mach-davinci/dm365.c | 5 -
arch/arm/mach-davinci/dm644x.c| 5 -
arch/arm/mach-davinci/dm646x.c| 5 -
5 files changed, 35 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 7f376e54b266..b85b781b05fd 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -148,11 +148,6 @@ static s8 da850_queue_priority_mapping[][2] = {
};
static struct edma_soc_info da830_edma_cc0_info = {
- .n_channel = 32,
- .n_region = 4,
- .n_slot = 128,
- .n_tc = 2,
- .n_cc = 1,
.queue_priority_mapping = da8xx_queue_priority_mapping,
.default_queue = EVENTQ_1,
};
@@ -163,20 +158,10 @@ static struct edma_soc_info *da830_edma_info[EDMA_MAX_CC]
= {
static struct edma_soc_info da850_edma_cc_info[] = {
{
- .n_channel = 32,
- .n_region = 4,
- .n_slot = 128,
- .n_tc = 2,
- .n_cc = 1,
.queue_priority_mapping = da8xx_queue_priority_mapping,
.default_queue = EVENTQ_1,
},
{
- .n_channel = 32,
- .n_region = 4,
- .n_slot = 128,
- .n_tc = 1,
- .n_cc = 1,
.queue_priority_mapping = da850_queue_priority_mapping,
.default_queue = EVENTQ_0,
},
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index e27f7ff54570..2f3ed3a58d57 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -577,11 +577,6 @@ queue_priority_mapping[][2] = {
};
static struct edma_soc_info edma_cc0_info = {
- .n_channel = 64,
- .n_region = 4,
- .n_slot = 128,
- .n_tc = 2,
- .n_cc = 1,
.queue_priority_mapping = queue_priority_mapping,
.default_queue = EVENTQ_1,
};
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 88835b0aaead..0ae8114f5cc9 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -863,11 +863,6 @@ dm365_queue_priority_mapping[][2] = {
};
static struct edma_soc_info edma_cc0_info = {
- .n_channel = 64,
- .n_region = 4,
- .n_slot = 256,
- .n_tc = 4,
- .n_cc = 1,
.queue_priority_mapping = dm365_queue_priority_mapping,
.default_queue = EVENTQ_3,
};
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 8ea34be879b4..dc52657909c4 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -507,11 +507,6 @@ queue_priority_mapping[][2] = {
};
static struct edma_soc_info edma_cc0_info = {
- .n_channel = 64,
- .n_region = 4,
- .n_slot = 128,
- .n_tc = 2,
- .n_cc = 1,
.queue_priority_mapping = queue_priority_mapping,
.default_queue = EVENTQ_1,
};
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 97e90dc5ed43..6c3bbea7d77d 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -543,11 +543,6 @@ dm646x_queue_priority_mapping[][2] = {
};
static struct edma_soc_info edma_cc0_info = {
- .n_channel = 64,
- .n_region = 6,/* 0-1, 4-7 */
- .n_slot = 512,
- .n_tc = 4,
- .n_cc = 1,
.queue_priority_mapping = dm646x_queue_priority_mapping,
.default_queue = EVENTQ_1,
};
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 10/13] ARM: dts: am33xx: Remove obsolete properties from edma node
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/am33xx.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f1eea4af40ed..37d4cad4dd38 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -147,9 +147,6 @@
<0x44e10f90 0x40>;
interrupts = <12 13 14>;
#dma-cells = <1>;
- dma-channels = <64>;
- ti,edma-regions = <4>;
- ti,edma-slots = <256>;
};
gpio0: gpio@44e07000 {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 13/13] ARM/platform_data: edma: Remove redundant/unused parameters from edma_soc_info
The following parameters are no longer needed by the edma driver since the
information can be obtained from the IP's CCCFG register:
n_channel, n_region, n_slot and n_tc.
Remove the n_cc as well since in this context it has no meaning. We have
separate edma_soc_info struct/eDMA3_CC instance so this member does not
make any sense (and the driver no longer uses it).
Signed-off-by: Peter Ujfalusi
---
include/linux/platform_data/edma.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index 633e196ebdf2..eb8d5627d080 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -158,13 +158,6 @@ struct edma_rsv_info {
/* platform_data for EDMA driver */
struct edma_soc_info {
-
- /* how many dma resources of each type */
- unsignedn_channel;
- unsignedn_region;
- unsignedn_slot;
- unsignedn_tc;
- unsignedn_cc;
/*
* Default queue is expected to be a low-priority queue.
* This way, long transfers on the default queue started
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] ARM: edma: Get IP information from HW when booting with DT
Hi Sekhar,
On 05/15/2014 11:53 AM, Sekhar Nori wrote:
> Hi Peter,
>
> On Tuesday 13 May 2014 04:00 PM, Peter Ujfalusi wrote:
>> From CCCFG register of eDMA3 we can get all the needed information for the
>> driver about the IP:
>> Number of channels: NUM_DMACH
>> Number of regions: NUM_REGN
>> Number of slots (PaRAM sets): NUM_PAENTRY
>> Number of TC/EQ: NUM_EVQUE
>>
>> Signed-off-by: Peter Ujfalusi
>> ---
>> arch/arm/common/edma.c | 128
>> ++---
>> 1 file changed, 79 insertions(+), 49 deletions(-)
>>
>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
>> index fade9ada81f8..1a98f3cd4cd9 100644
>> --- a/arch/arm/common/edma.c
>> +++ b/arch/arm/common/edma.c
>> @@ -102,7 +102,16 @@
>> #define PARM_OFFSET(param_no) (EDMA_PARM + ((param_no) << 5))
>>
>> #define EDMA_DCHMAP 0x0100 /* 64 registers */
>> -#define CHMAP_EXIST BIT(24)
>> +
>> +/* CCCFG register */
>> +#define GET_NUM_DMACH(x)(x & 0x7) /* bits 0-2 */
>> +#define GET_NUM_QDMACH(x) ((x & 0x70) >> 4) /* bits 4-6 */
>> +#define GET_NUM_INTCH(x)((x & 0x700) >> 8) /* bits 8-10 */
>> +#define GET_NUM_PAENTRY(x) ((x & 0x7000) >> 12) /* bits 12-14 */
>> +#define GET_NUM_EVQUE(x)((x & 0x7) >> 16) /* bits 16-18 */
>> +#define GET_NUM_REGN(x) ((x & 0x30) >> 20) /* bits 20-21 */
>> +#define CHMAP_EXIST BIT(24)
>> +#define MP_EXISTBIT(25)
>
> Of these new defines, you do not use GET_NUM_QDMACH(), GET_NUM_INTCH()
> and MP_EXIST (at least in this patch). Can you please get rid of them if
> not needed? May be its just me but its pretty annoying to search for a
> define only to find its never used :)
Sure, I can remove the ones we are not using in the code. I usually prefer to
have full description if the register even if we only use one bit from the
register.
>
>>
>> #define EDMA_MAX_DMACH 64
>> #define EDMA_MAX_PARAMENTRY 512
>> @@ -1415,6 +1424,68 @@ void edma_clear_event(unsigned channel)
>> }
>> EXPORT_SYMBOL(edma_clear_event);
>>
>> +static int edma_setup_info_from_hw(struct device *dev,
>> + struct edma_soc_info *pdata)
>> +{
>> +int i;
>> +u32 value, cccfg, n_tc;
>> +s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
>> +
>> +/* Decode the eDMA3 configuration from CCCFG register */
>> +cccfg = edma_read(0, EDMA_CCCFG);
>
> You do not handle the second controller here, but its pretty straight
> forward to add that by passing the controller number to this function.
The second controller is not handled because in DT boot we only handle 1 cc as
far as I know. I don't know why, but this is how the DT support has been
written and used.
> I was wondering why we never read the hardware for this information
> before, and strangely enough cannot find any SoC where the CCCFG
> register does not publish this information correctly. I have tested on
> DA850, DA830, DM365, DM355 and DM6467.
Good question. I was also puzzled about this.
> Instead of keeping this specific to OF case, the code can be simplified
> much better if we read from hardware all the time. We can directly
> populate the equivalent variables in the internal structure 'struct
> edma' instead of populating them in 'struct edma_soc_info' and then
> copying then over.
Yes, we can switch the non DT boot to this mode as well, true. At first I
wanted to change code which I can test easily. For non DT boot I would need to
set up my old daVinci board ;)
>> +
>> +value = GET_NUM_DMACH(cccfg);
>> +pdata->n_channel = BIT(value + 1);
>> +
>> +value = GET_NUM_REGN(cccfg);
>> +pdata->n_region = BIT(value);
>> +
>> +value = GET_NUM_PAENTRY(cccfg);
>> +pdata->n_slot = BIT(value + 4);
>> +
>> +value = GET_NUM_EVQUE(cccfg);
>> +n_tc = value + 1;
>> +
>> +dev_dbg(dev, "eDMA3 HW configuration (cccfg: 0x%08x):\n", cccfg);
>> +dev_dbg(dev, "n_channel: %u\n", pdata->n_channel);
>> +dev_dbg(dev, "n_region: %u\n", pdata->n_region);
>> +dev_dbg(dev, "n_slot: %u\n", pdata->n_slot);
>> +dev_dbg(dev, "n_tc: %u\n", n_tc);
>> +
>
> [snip]
>
>> +pdata->n_cc = 1;
>> +
>> +queue_tc_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8), GFP_KERNEL);
>> +if (!queue_tc_map)
>> +return -ENOMEM;
>>
Re: [PATCH v2 3/5] dt/bindings: ti,edma: Remove redundant properties from documentation
On 05/15/2014 11:01 AM, Arnd Bergmann wrote: > On Tuesday 13 May 2014 13:30:30 Peter Ujfalusi wrote: >> From CCCFG register of eDMA3 we can get all the needed information for the >> driver about the IP: >> Number of channels: NUM_DMACH >> Number of regions: NUM_REGN >> Number of slots (PaRAM sets): NUM_PAENTRY >> Number of TC/EQ: NUM_EVQUE >> >> The ti,edma-regions; ti,edma-slots and dma-channels in DT are >> redundant since the very same information can be obtained from the HW. >> The mentioned properties can be removed from the binding document. >> >> Signed-off-by: Peter Ujfalusi > > I wonder if we should keep them listed as "optional" properties so you > can have a dtb file that still works with older kernels which need them. > > What you do is an incompatible change to the binding, which we shouldn't > do lightly. Any new dts files don't need this information of course, but > as a general rule, I'd rather keep things like this around unless we > already have to enforce an ABI break that is well documented. We could keep them as optional, or to be precise: ignored properties since we are not going to even look at them in the future. But I do not really see the reason to do so. With this change new kernels will boot with old DTB - if it can not be changed which I have not seen yet. Sure old kernel would not boot with this change, but why would you downgrade the kernel and update the DTB on a board? Bisecting is not a good reason since the bug you might be hunting for could be in the DTS or in the kernel code so you need to update both of them to be sure you reach the commit you are looking for. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] ARM/DT: edma: Get IP configuration from hardware
Hi, Changes sicne v1: - added missing patch to remove the memset from edma_of_parse_dt() We are requesting redundant information via DT for the driver since the very same data is available in the HW: by reading and decoding the content of CCCFG register we can get: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE So these does not need to be provided by the DT binding. The driver will no longer look for these properties from DT and they can be removed from the binding documentation and from the dtsi files as well. The change will not introduce regression when new kernel is booted using older DTB (since we just ignore the mentioned properties). Regards, Peter --- Peter Ujfalusi (5): ARM: edma: No need to clean the pdata in edma_of_parse_dt() ARM: edma: Get IP information from HW when booting with DT dt/bindings: ti,edma: Remove redundant properties from documentation ARM: dts: am33xx: Remove obsolete properties from edma node ARM: dts: am4372: Remove obsolete properties from edma node Documentation/devicetree/bindings/dma/ti-edma.txt | 6 - arch/arm/boot/dts/am33xx.dtsi | 3 - arch/arm/boot/dts/am4372.dtsi | 3 - arch/arm/common/edma.c| 130 +- 4 files changed, 79 insertions(+), 63 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/5] ARM: dts: am33xx: Remove obsolete properties from edma node
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/am33xx.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index baf56cc92040..5e8f647ee4ec 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -147,9 +147,6 @@
<0x44e10f90 0x10>;
interrupts = <12 13 14>;
#dma-cells = <1>;
- dma-channels = <64>;
- ti,edma-regions = <4>;
- ti,edma-slots = <256>;
};
gpio0: gpio@44e07000 {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] ARM: edma: No need to clean the pdata in edma_of_parse_dt()
The pdata has been just allocated with devm_kzalloc() in edma_setup_info_from_dt() and passed to this function. Signed-off-by: Peter Ujfalusi --- arch/arm/common/edma.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index b9bd42ad2d6e..fade9ada81f8 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1490,8 +1490,6 @@ static int edma_of_parse_dt(struct device *dev, struct edma_rsv_info *rsv_info; s8 (*queue_tc_map)[2], (*queue_priority_map)[2]; - memset(pdata, 0, sizeof(struct edma_soc_info)); - ret = of_property_read_u32(node, "dma-channels", &value); if (ret < 0) return ret; -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] ARM: edma: Get IP information from HW when booting with DT
>From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
Signed-off-by: Peter Ujfalusi
---
arch/arm/common/edma.c | 128 ++---
1 file changed, 79 insertions(+), 49 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index fade9ada81f8..1a98f3cd4cd9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -102,7 +102,16 @@
#define PARM_OFFSET(param_no) (EDMA_PARM + ((param_no) << 5))
#define EDMA_DCHMAP0x0100 /* 64 registers */
-#define CHMAP_EXISTBIT(24)
+
+/* CCCFG register */
+#define GET_NUM_DMACH(x) (x & 0x7) /* bits 0-2 */
+#define GET_NUM_QDMACH(x) ((x & 0x70) >> 4) /* bits 4-6 */
+#define GET_NUM_INTCH(x) ((x & 0x700) >> 8) /* bits 8-10 */
+#define GET_NUM_PAENTRY(x) ((x & 0x7000) >> 12) /* bits 12-14 */
+#define GET_NUM_EVQUE(x) ((x & 0x7) >> 16) /* bits 16-18 */
+#define GET_NUM_REGN(x)((x & 0x30) >> 20) /* bits 20-21 */
+#define CHMAP_EXISTBIT(24)
+#define MP_EXIST BIT(25)
#define EDMA_MAX_DMACH 64
#define EDMA_MAX_PARAMENTRY 512
@@ -1415,6 +1424,68 @@ void edma_clear_event(unsigned channel)
}
EXPORT_SYMBOL(edma_clear_event);
+static int edma_setup_info_from_hw(struct device *dev,
+ struct edma_soc_info *pdata)
+{
+ int i;
+ u32 value, cccfg, n_tc;
+ s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ /* Decode the eDMA3 configuration from CCCFG register */
+ cccfg = edma_read(0, EDMA_CCCFG);
+
+ value = GET_NUM_DMACH(cccfg);
+ pdata->n_channel = BIT(value + 1);
+
+ value = GET_NUM_REGN(cccfg);
+ pdata->n_region = BIT(value);
+
+ value = GET_NUM_PAENTRY(cccfg);
+ pdata->n_slot = BIT(value + 4);
+
+ value = GET_NUM_EVQUE(cccfg);
+ n_tc = value + 1;
+
+ dev_dbg(dev, "eDMA3 HW configuration (cccfg: 0x%08x):\n", cccfg);
+ dev_dbg(dev, "n_channel: %u\n", pdata->n_channel);
+ dev_dbg(dev, "n_region: %u\n", pdata->n_region);
+ dev_dbg(dev, "n_slot: %u\n", pdata->n_slot);
+ dev_dbg(dev, "n_tc: %u\n", n_tc);
+
+ pdata->n_cc = 1;
+
+ queue_tc_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8), GFP_KERNEL);
+ if (!queue_tc_map)
+ return -ENOMEM;
+
+ for (i = 0; i < n_tc; i++) {
+ queue_tc_map[i][0] = i;
+ queue_tc_map[i][1] = i;
+ }
+ queue_tc_map[i][0] = -1;
+ queue_tc_map[i][1] = -1;
+
+ pdata->queue_tc_mapping = queue_tc_map;
+
+ queue_priority_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8),
+ GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+
+ for (i = 0; i < n_tc; i++) {
+ queue_priority_map[i][0] = i;
+ queue_priority_map[i][1] = i;
+ }
+ queue_priority_map[i][0] = -1;
+ queue_priority_map[i][1] = -1;
+
+ pdata->queue_priority_mapping = queue_priority_map;
+
+ pdata->default_queue = 0;
+
+ return 0;
+}
+
#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_DMADEVICES)
static int edma_of_read_u32_to_s16_array(const struct device_node *np,
@@ -1483,63 +1554,16 @@ static int edma_of_parse_dt(struct device *dev,
struct device_node *node,
struct edma_soc_info *pdata)
{
- int ret = 0, i;
- u32 value;
+ int ret = 0;
struct property *prop;
size_t sz;
struct edma_rsv_info *rsv_info;
- s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
-
- ret = of_property_read_u32(node, "dma-channels", &value);
- if (ret < 0)
- return ret;
- pdata->n_channel = value;
-
- ret = of_property_read_u32(node, "ti,edma-regions", &value);
- if (ret < 0)
- return ret;
- pdata->n_region = value;
-
- ret = of_property_read_u32(node, "ti,edma-slots", &value);
- if (ret < 0)
- return ret;
- pdata->n_slot = value;
-
- pdata->n_cc = 1;
rsv_info = devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
if (!rsv_info)
return -ENOMEM;
pdata->rsv = rsv_info;
- queue_tc_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
- if (!queue_tc_map)
- return -ENOMEM;
-
- for (i = 0; i < 3; i++) {
- queue_tc_map[i][0] = i;
- queue_tc_map[i][1] = i;
- }
- queue_tc_map[i][0] = -1;
- que
[PATCH v2 5/5] ARM: dts: am4372: Remove obsolete properties from edma node
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/am4372.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 03a225505126..b9f83b705f4b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -108,9 +108,6 @@
,
;
#dma-cells = <1>;
- dma-channels = <64>;
- ti,edma-regions = <4>;
- ti,edma-slots = <256>;
};
uart0: serial@44e09000 {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] dt/bindings: ti,edma: Remove redundant properties from documentation
>From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
The ti,edma-regions; ti,edma-slots and dma-channels in DT are
redundant since the very same information can be obtained from the HW.
The mentioned properties can be removed from the binding document.
Signed-off-by: Peter Ujfalusi
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 9fbbdb783a72..cf8d0a2d5b33 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -2,11 +2,8 @@ TI EDMA
Required properties:
- compatible : "ti,edma3"
-- ti,edma-regions: Number of regions
-- ti,edma-slots: Number of slots
- #dma-cells: Should be set to <1>
Clients should use a single channel number per DMA request.
-- dma-channels: Specify total DMA channels per CC
- reg: Memory map for accessing module
- interrupt-parent: Interrupt controller the interrupt is routed through
- interrupts: Exactly 3 interrupts need to be specified in the order:
@@ -26,9 +23,6 @@ edma: edma@4900 {
compatible = "ti,edma3";
ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
#dma-cells = <1>;
- dma-channels = <64>;
- ti,edma-regions = <4>;
- ti,edma-slots = <256>;
ti,edma-xbar-event-map = <1 12
2 13>;
};
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ARM/DT: edma: Get IP configuration from hardware
On 05/13/2014 11:33 AM, Sekhar Nori wrote: > On Tuesday 13 May 2014 01:13 PM, Peter Ujfalusi wrote: >> Hi, >> >> We are requesting redundant information via DT for the driver since the very >> same >> data is available in the HW: by reading and decoding the content of CCCFG >> register we can get: >> Number of channels: NUM_DMACH >> Number of regions: NUM_REGN >> Number of slots (PaRAM sets): NUM_PAENTRY >> Number of TC/EQ: NUM_EVQUE >> >> So these does not need to be provided by the DT binding. >> >> The driver will no longer look for these properties from DT and they can be >> removed from the binding documentation and from the dtsi files as well. >> The change will not introduce regression when new kernel is booted using >> older >> DTB (since we just ignore the mentioned properties). > > Peter, to which baseline do these patches apply? I tried applying them > to v3.15-rc5 but 1/4 doesn't apply cleanly. It is on top of next-20140509. Now that I looked at my branch, I missed one small patch from the series which could cause the issue (removing the memset from edma_of_parse_dt). I'll resend ASAP with that patch included. > > Thanks, > Sekhar > -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] dt/bindings: ti,edma: Remove redundant properties from documentation
>From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
The ti,edma-regions; ti,edma-slots and dma-channels in DT are
redundant since the very same information can be obtained from the HW.
The mentioned properties can be removed from the binding document.
Signed-off-by: Peter Ujfalusi
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 9fbbdb783a72..cf8d0a2d5b33 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -2,11 +2,8 @@ TI EDMA
Required properties:
- compatible : "ti,edma3"
-- ti,edma-regions: Number of regions
-- ti,edma-slots: Number of slots
- #dma-cells: Should be set to <1>
Clients should use a single channel number per DMA request.
-- dma-channels: Specify total DMA channels per CC
- reg: Memory map for accessing module
- interrupt-parent: Interrupt controller the interrupt is routed through
- interrupts: Exactly 3 interrupts need to be specified in the order:
@@ -26,9 +23,6 @@ edma: edma@4900 {
compatible = "ti,edma3";
ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
#dma-cells = <1>;
- dma-channels = <64>;
- ti,edma-regions = <4>;
- ti,edma-slots = <256>;
ti,edma-xbar-event-map = <1 12
2 13>;
};
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: dts: am4372: Remove obsolete properties from edma node
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/am4372.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 03a225505126..b9f83b705f4b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -108,9 +108,6 @@
,
;
#dma-cells = <1>;
- dma-channels = <64>;
- ti,edma-regions = <4>;
- ti,edma-slots = <256>;
};
uart0: serial@44e09000 {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: edma: Get IP information from HW when booting with DT
>From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
Signed-off-by: Peter Ujfalusi
---
arch/arm/common/edma.c | 128 ++---
1 file changed, 79 insertions(+), 49 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index fade9ada81f8..1a98f3cd4cd9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -102,7 +102,16 @@
#define PARM_OFFSET(param_no) (EDMA_PARM + ((param_no) << 5))
#define EDMA_DCHMAP0x0100 /* 64 registers */
-#define CHMAP_EXISTBIT(24)
+
+/* CCCFG register */
+#define GET_NUM_DMACH(x) (x & 0x7) /* bits 0-2 */
+#define GET_NUM_QDMACH(x) ((x & 0x70) >> 4) /* bits 4-6 */
+#define GET_NUM_INTCH(x) ((x & 0x700) >> 8) /* bits 8-10 */
+#define GET_NUM_PAENTRY(x) ((x & 0x7000) >> 12) /* bits 12-14 */
+#define GET_NUM_EVQUE(x) ((x & 0x7) >> 16) /* bits 16-18 */
+#define GET_NUM_REGN(x)((x & 0x30) >> 20) /* bits 20-21 */
+#define CHMAP_EXISTBIT(24)
+#define MP_EXIST BIT(25)
#define EDMA_MAX_DMACH 64
#define EDMA_MAX_PARAMENTRY 512
@@ -1415,6 +1424,68 @@ void edma_clear_event(unsigned channel)
}
EXPORT_SYMBOL(edma_clear_event);
+static int edma_setup_info_from_hw(struct device *dev,
+ struct edma_soc_info *pdata)
+{
+ int i;
+ u32 value, cccfg, n_tc;
+ s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ /* Decode the eDMA3 configuration from CCCFG register */
+ cccfg = edma_read(0, EDMA_CCCFG);
+
+ value = GET_NUM_DMACH(cccfg);
+ pdata->n_channel = BIT(value + 1);
+
+ value = GET_NUM_REGN(cccfg);
+ pdata->n_region = BIT(value);
+
+ value = GET_NUM_PAENTRY(cccfg);
+ pdata->n_slot = BIT(value + 4);
+
+ value = GET_NUM_EVQUE(cccfg);
+ n_tc = value + 1;
+
+ dev_dbg(dev, "eDMA3 HW configuration (cccfg: 0x%08x):\n", cccfg);
+ dev_dbg(dev, "n_channel: %u\n", pdata->n_channel);
+ dev_dbg(dev, "n_region: %u\n", pdata->n_region);
+ dev_dbg(dev, "n_slot: %u\n", pdata->n_slot);
+ dev_dbg(dev, "n_tc: %u\n", n_tc);
+
+ pdata->n_cc = 1;
+
+ queue_tc_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8), GFP_KERNEL);
+ if (!queue_tc_map)
+ return -ENOMEM;
+
+ for (i = 0; i < n_tc; i++) {
+ queue_tc_map[i][0] = i;
+ queue_tc_map[i][1] = i;
+ }
+ queue_tc_map[i][0] = -1;
+ queue_tc_map[i][1] = -1;
+
+ pdata->queue_tc_mapping = queue_tc_map;
+
+ queue_priority_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8),
+ GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+
+ for (i = 0; i < n_tc; i++) {
+ queue_priority_map[i][0] = i;
+ queue_priority_map[i][1] = i;
+ }
+ queue_priority_map[i][0] = -1;
+ queue_priority_map[i][1] = -1;
+
+ pdata->queue_priority_mapping = queue_priority_map;
+
+ pdata->default_queue = 0;
+
+ return 0;
+}
+
#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_DMADEVICES)
static int edma_of_read_u32_to_s16_array(const struct device_node *np,
@@ -1483,63 +1554,16 @@ static int edma_of_parse_dt(struct device *dev,
struct device_node *node,
struct edma_soc_info *pdata)
{
- int ret = 0, i;
- u32 value;
+ int ret = 0;
struct property *prop;
size_t sz;
struct edma_rsv_info *rsv_info;
- s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
-
- ret = of_property_read_u32(node, "dma-channels", &value);
- if (ret < 0)
- return ret;
- pdata->n_channel = value;
-
- ret = of_property_read_u32(node, "ti,edma-regions", &value);
- if (ret < 0)
- return ret;
- pdata->n_region = value;
-
- ret = of_property_read_u32(node, "ti,edma-slots", &value);
- if (ret < 0)
- return ret;
- pdata->n_slot = value;
-
- pdata->n_cc = 1;
rsv_info = devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
if (!rsv_info)
return -ENOMEM;
pdata->rsv = rsv_info;
- queue_tc_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
- if (!queue_tc_map)
- return -ENOMEM;
-
- for (i = 0; i < 3; i++) {
- queue_tc_map[i][0] = i;
- queue_tc_map[i][1] = i;
- }
- queue_tc_map[i][0] = -1;
- que
[PATCH 3/4] ARM: dts: am33xx: Remove obsolete properties from edma node
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/am33xx.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index baf56cc92040..5e8f647ee4ec 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -147,9 +147,6 @@
<0x44e10f90 0x10>;
interrupts = <12 13 14>;
#dma-cells = <1>;
- dma-channels = <64>;
- ti,edma-regions = <4>;
- ti,edma-slots = <256>;
};
gpio0: gpio@44e07000 {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM/DT: edma: Get IP configuration from hardware
Hi, We are requesting redundant information via DT for the driver since the very same data is available in the HW: by reading and decoding the content of CCCFG register we can get: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE So these does not need to be provided by the DT binding. The driver will no longer look for these properties from DT and they can be removed from the binding documentation and from the dtsi files as well. The change will not introduce regression when new kernel is booted using older DTB (since we just ignore the mentioned properties). Regards, Peter --- Peter Ujfalusi (4): ARM: edma: Get IP information from HW when booting with DT dt/bindings: ti,edma: Remove redundant properties from documentation ARM: dts: am33xx: Remove obsolete properties from edma node ARM: dts: am4372: Remove obsolete properties from edma node Documentation/devicetree/bindings/dma/ti-edma.txt | 6 - arch/arm/boot/dts/am33xx.dtsi | 3 - arch/arm/boot/dts/am4372.dtsi | 3 - arch/arm/common/edma.c| 128 +- 4 files changed, 79 insertions(+), 61 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: edma: Clean up and simplify the code around irq request
Get the two interrupt line number at the same time by merging the two
instance of if(node){}else{} places.
replace the &pdev->dev with the already existing dev which makes it possible
to collapse lines with devm_request_irq()
Signed-off-by: Peter Ujfalusi
---
arch/arm/common/edma.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index db2d9dc62d33..fade9ada81f8 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1596,7 +1596,6 @@ static int edma_probe(struct platform_device *pdev)
struct resource *r[EDMA_MAX_CC] = {NULL};
struct resource res[EDMA_MAX_CC];
charres_name[10];
- charirq_name[10];
struct device_node *node = pdev->dev.of_node;
struct device *dev = &pdev->dev;
int ret;
@@ -1718,14 +1717,21 @@ static int edma_probe(struct platform_device *pdev)
if (node) {
irq[j] = irq_of_parse_and_map(node, 0);
+ err_irq[j] = irq_of_parse_and_map(node, 2);
} else {
+ char irq_name[10];
+
sprintf(irq_name, "edma%d", j);
irq[j] = platform_get_irq_byname(pdev, irq_name);
+
+ sprintf(irq_name, "edma%d_err", j);
+ err_irq[j] = platform_get_irq_byname(pdev, irq_name);
}
edma_cc[j]->irq_res_start = irq[j];
- status = devm_request_irq(&pdev->dev, irq[j],
- dma_irq_handler, 0, "edma",
- &pdev->dev);
+ edma_cc[j]->irq_res_end = err_irq[j];
+
+ status = devm_request_irq(dev, irq[j], dma_irq_handler, 0,
+ "edma", dev);
if (status < 0) {
dev_dbg(&pdev->dev,
"devm_request_irq %d failed --> %d\n",
@@ -1733,16 +1739,8 @@ static int edma_probe(struct platform_device *pdev)
return status;
}
- if (node) {
- err_irq[j] = irq_of_parse_and_map(node, 2);
- } else {
- sprintf(irq_name, "edma%d_err", j);
- err_irq[j] = platform_get_irq_byname(pdev, irq_name);
- }
- edma_cc[j]->irq_res_end = err_irq[j];
- status = devm_request_irq(&pdev->dev, err_irq[j],
- dma_ccerr_handler, 0,
- "edma_error", &pdev->dev);
+ status = devm_request_irq(dev, err_irq[j], dma_ccerr_handler, 0,
+ "edma_error", dev);
if (status < 0) {
dev_dbg(&pdev->dev,
"devm_request_irq %d failed --> %d\n",
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: omap4: hwmod_data: Clean up audio related structures (remove/merge them)
All audio related omap_hwmod_ocp_if *_dma can be removed from the data since
we can just add the user flag to the non dma structure.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 99 +++---
1 file changed, 9 insertions(+), 90 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1219280bb976..41e54f759934 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3635,15 +3635,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__dmic = {
.master = &omap44xx_l4_abe_hwmod,
.slave = &omap44xx_dmic_hwmod,
.clk= "ocp_abe_iclk",
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe -> dmic (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__dmic_dma = {
- .master = &omap44xx_l4_abe_hwmod,
- .slave = &omap44xx_dmic_hwmod,
- .clk= "ocp_abe_iclk",
- .user = OCP_USER_SDMA,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* dsp -> iva */
@@ -4209,15 +4201,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp1
= {
.master = &omap44xx_l4_abe_hwmod,
.slave = &omap44xx_mcbsp1_hwmod,
.clk= "ocp_abe_iclk",
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe -> mcbsp1 (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp1_dma = {
- .master = &omap44xx_l4_abe_hwmod,
- .slave = &omap44xx_mcbsp1_hwmod,
- .clk= "ocp_abe_iclk",
- .user = OCP_USER_SDMA,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* l4_abe -> mcbsp2 */
@@ -4225,15 +4209,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp2
= {
.master = &omap44xx_l4_abe_hwmod,
.slave = &omap44xx_mcbsp2_hwmod,
.clk= "ocp_abe_iclk",
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe -> mcbsp2 (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp2_dma = {
- .master = &omap44xx_l4_abe_hwmod,
- .slave = &omap44xx_mcbsp2_hwmod,
- .clk= "ocp_abe_iclk",
- .user = OCP_USER_SDMA,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* l4_abe -> mcbsp3 */
@@ -4241,15 +4217,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp3
= {
.master = &omap44xx_l4_abe_hwmod,
.slave = &omap44xx_mcbsp3_hwmod,
.clk= "ocp_abe_iclk",
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe -> mcbsp3 (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp3_dma = {
- .master = &omap44xx_l4_abe_hwmod,
- .slave = &omap44xx_mcbsp3_hwmod,
- .clk= "ocp_abe_iclk",
- .user = OCP_USER_SDMA,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* l4_per -> mcbsp4 */
@@ -4265,15 +4233,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcpdm =
{
.master = &omap44xx_l4_abe_hwmod,
.slave = &omap44xx_mcpdm_hwmod,
.clk= "ocp_abe_iclk",
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe -> mcpdm (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcpdm_dma = {
- .master = &omap44xx_l4_abe_hwmod,
- .slave = &omap44xx_mcpdm_hwmod,
- .clk= "ocp_abe_iclk",
- .user = OCP_USER_SDMA,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* l4_per -> mcspi1 */
@@ -4575,15 +4535,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__timer5
= {
.master = &omap44xx_l4_abe_hwmod,
.slave = &omap44xx_timer5_hwmod,
.clk= "ocp_abe_iclk",
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe -> timer5 (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__timer5_dma = {
- .master = &omap44xx_l4_abe_hwmod,
- .slave = &omap44xx_timer5_hwmod,
- .clk= "ocp_abe_iclk",
- .user = OCP_USER_SDMA,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* l4_abe -> timer6 */
@@ -4591,15 +4543,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__timer6
= {
.master = &omap44xx_l4_abe_hwmod,
.slave = &omap44xx_timer6_hwmod,
.clk= "ocp_abe_iclk",
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe -> timer6 (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__timer6_dma = {
- .master
[PATCH v2] ARM: omap5: hwmod_data: Correct IDLEMODE for McPDM
McPDM need to be configured to NO_IDLE mode when it is in used otherwise
vital clocks will be gated which results 'slow motion' audio playback.
Signed-off-by: Peter Ujfalusi
---
Hi Paul,
Changes since v1:
- updated the commit message
If this can still make it to 3.15, that would be great.
Regards,
Peter
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 892317294fdc..e829664e6a6c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -895,7 +895,7 @@ static struct omap_hwmod omap54xx_mcpdm_hwmod = {
* current exception.
*/
- .flags = HWMOD_EXT_OPT_MAIN_CLK,
+ .flags = HWMOD_EXT_OPT_MAIN_CLK | HWMOD_SWSUP_SIDLE,
.main_clk = "pad_clks_ck",
.prcm = {
.omap4 = {
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: omap5: hwmod_data: Add AESS related data
Paul,
On 04/30/2014 02:43 PM, Peter Ujfalusi wrote:
> Add the needed hwmod entries which is needed for AESS (Audio Engine
> SubSystem) and ABE.
please ignore this patch to add AESS to hwmod data. W/o addresses defined we
will see warnings printed. So either I add the addresses to hwmod data or need
to have aess also in DT.
--
Péter
> Signed-off-by: Peter Ujfalusi
> ---
> arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 64
> ++
> 1 file changed, 64 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> index e829664e6a6c..3e20c025b5a4 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> @@ -146,6 +146,7 @@ static struct omap_hwmod omap54xx_l4_abe_hwmod = {
> .prcm = {
> .omap4 = {
> .clkctrl_offs = OMAP54XX_CM_ABE_L4_ABE_CLKCTRL_OFFSET,
> + .context_offs = OMAP54XX_RM_ABE_AESS_CONTEXT_OFFSET,
> .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
> },
> },
> @@ -211,6 +212,42 @@ static struct omap_hwmod omap54xx_mpu_private_hwmod = {
> };
>
> /*
> + * 'aess' class
> + * audio engine sub system
> + */
> +
> +static struct omap_hwmod_class_sysconfig omap54xx_aess_sysc = {
> + .rev_offs = 0x,
> + .sysc_offs = 0x0010,
> + .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> +MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART |
> +MSTANDBY_SMART_WKUP),
> + .sysc_fields= &omap_hwmod_sysc_type2,
> +};
> +
> +static struct omap_hwmod_class omap54xx_aess_hwmod_class = {
> + .name = "aess",
> + .sysc = &omap54xx_aess_sysc,
> + .enable_preprogram = omap_hwmod_aess_preprogram,
> +};
> +
> +/* aess */
> +static struct omap_hwmod omap54xx_aess_hwmod = {
> + .name = "aess",
> + .class = &omap54xx_aess_hwmod_class,
> + .clkdm_name = "abe_clkdm",
> + .main_clk = "aess_fclk",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = OMAP54XX_CM_ABE_AESS_CLKCTRL_OFFSET,
> + .context_offs = OMAP54XX_RM_ABE_AESS_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_SWCTRL,
> + },
> + },
> +};
> +
> +/*
> * 'counter' class
> * 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
> */
> @@ -1892,6 +1929,14 @@ static struct omap_hwmod_ocp_if
> omap54xx_l4_cfg__l3_main_3 = {
> .user = OCP_USER_MPU | OCP_USER_SDMA,
> };
>
> +/* aess -> l4_abe */
> +static struct omap_hwmod_ocp_if __maybe_unused omap54xx_aess__l4_abe = {
> + .master = &omap54xx_aess_hwmod,
> + .slave = &omap54xx_l4_abe_hwmod,
> + .clk= "abe_iclk",
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> /* l3_main_1 -> l4_abe */
> static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l4_abe = {
> .master = &omap54xx_l3_main_1_hwmod,
> @@ -1966,6 +2011,22 @@ static struct omap_hwmod_ocp_if
> omap54xx_l4_cfg__dma_system = {
> .user = OCP_USER_MPU | OCP_USER_SDMA,
> };
>
> +/* l4_abe -> aess */
> +static struct omap_hwmod_ocp_if __maybe_unused omap54xx_l4_abe__aess = {
> + .master = &omap54xx_l4_abe_hwmod,
> + .slave = &omap54xx_aess_hwmod,
> + .clk= "abe_iclk",
> + .user = OCP_USER_MPU,
> +};
> +
> +/* l4_abe -> aess (dma) */
> +static struct omap_hwmod_ocp_if __maybe_unused omap54xx_l4_abe__aess_dma = {
> + .master = &omap54xx_l4_abe_hwmod,
> + .slave = &omap54xx_aess_hwmod,
> + .clk= "abe_iclk",
> + .user = OCP_USER_SDMA,
> +};
> +
> /* l4_abe -> dmic */
> static struct omap_hwmod_ocp_if omap54xx_l4_abe__dmic = {
> .master = &omap54xx_l4_abe_hwmod,
> @@ -2417,6 +2478,9 @@ static struct omap_hwmod_ocp_if
> *omap54xx_hwmod_ocp_ifs[] __initdata = {
> &omap54xx_l3_main_1__l3_main_3,
> &omap54xx_l3_main_2__l3_main_3,
> &omap54xx_l4_cfg__l3_main_3,
> + &omap54xx_l4_abe__aess,
> + &omap54xx_l4_abe__aess_dma,
> + &omap54xx_aess__l4_abe,
> &omap54xx_l3_main_1__l4_abe,
> &omap54xx_mpu__l4_abe,
> &omap54xx_l3_main_1__l4_cfg,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: omap5: hwmod_data: Update McPDM hwmod's flags
Hi Paul, On 05/08/2014 03:20 AM, Paul Walmsley wrote: > Hi Péter, > > On Wed, 30 Apr 2014, Peter Ujfalusi wrote: > >> Add HWMOD_SWSUP_SIDLE to flags. >> >> Signed-off-by: Peter Ujfalusi > > This patch could use a better changelog. It would be ideal to understand > _why_ HWMOD_SWSUP_SIDLE is needed. Is there a known hardware bug? Or is > this simply based on practical observation, e.g., something bad happens if > the McPDM is not software-idled? The same issue exists on OMAP5 as on OMAP4: commit 12d82e4b0aa6c71f38b668a372f9a13f243207da Author: Peter Ujfalusi Date: Fri Jan 18 16:48:16 2013 -0700 ARM: OMAP4: hwmod_data: Correct IDLEMODE for McPDM McPDM need to be configured to NO_IDLE mode when it is in used otherwise vital clocks will be gated which results 'slow motion' audio playback. Signed-off-by: Peter Ujfalusi [p...@pwsan.com: copy patch description into hwmod data comments] Signed-off-by: Paul Walmsley diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] ARM: dts: dra7xx-clocks: Correct name for atl clkin3 clock
To allign the name with the other atl clock names:
atlclkin3_ck -> atl_clkin3_ck
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 22 +++---
drivers/clk/ti/clk-7xx.c | 2 +-
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index cfb8fc753f50..30160348934c 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -26,7 +26,7 @@
clock-frequency = <0>;
};
- atlclkin3_ck: atlclkin3_ck {
+ atl_clkin3_ck: atl_clkin3_ck {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <0>;
@@ -730,7 +730,7 @@
mcasp1_ahclkr_mux: mcasp1_ahclkr_mux {
#clock-cells = <0>;
compatible = "ti,mux-clock";
- clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+ clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atl_clkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
ti,bit-shift = <28>;
reg = <0x0550>;
};
@@ -738,7 +738,7 @@
mcasp1_ahclkx_mux: mcasp1_ahclkx_mux {
#clock-cells = <0>;
compatible = "ti,mux-clock";
- clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+ clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atl_clkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
ti,bit-shift = <24>;
reg = <0x0550>;
};
@@ -1631,7 +1631,7 @@
mcasp2_ahclkr_mux: mcasp2_ahclkr_mux {
#clock-cells = <0>;
compatible = "ti,mux-clock";
- clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+ clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atl_clkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
ti,bit-shift = <28>;
reg = <0x1860>;
};
@@ -1639,7 +1639,7 @@
mcasp2_ahclkx_mux: mcasp2_ahclkx_mux {
#clock-cells = <0>;
compatible = "ti,mux-clock";
- clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+ clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atl_clkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
[PATCH v2 3/4] clk: ti: Driver for DRA7 ATL (Audio Tracking Logic)
Audio Tracking Logic is designed to be used by HD Radio applications to
synchronize the audio output clocks to the baseband clock. ATL can be also
used to track errors between two reference clocks (BWS, AWS) and generate a
modulated
clock output which averages to some desired frequency.
In essence ATL is generating a clock to be used by an audio codec and also
to be used by the SoC as MCLK.
To be able to integrate the ATL provided clocks to the clock tree we need
two types of DT binding:
- DT clock nodes to represent the ATL clocks towards the CCF
- binding for the ATL IP itself which is going to handle the hw
configuration
The reason for this type of setup is that ATL itself is a separate device
in the SoC, it has it's own address space and clock domain. Other IPs can
use the ATL generated clock as their functional clock (McASPs for example)
and external components like audio codecs can also use the very same clock
as their MCLK.
The ATL IP in DRA7 contains 4 ATL instences.
Signed-off-by: Peter Ujfalusi
---
drivers/clk/ti/Makefile | 3 +-
drivers/clk/ti/clk-dra7-atl.c | 313 ++
2 files changed, 315 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/ti/clk-dra7-atl.c
diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
index 4319d4031aa3..18e2443224e6 100644
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_SOC_AM33XX)+= $(clk-common)
clk-33xx.o
obj-$(CONFIG_ARCH_OMAP3) += $(clk-common) interface.o clk-3xxx.o
obj-$(CONFIG_ARCH_OMAP4) += $(clk-common) clk-44xx.o
obj-$(CONFIG_SOC_OMAP5)+= $(clk-common) clk-54xx.o
-obj-$(CONFIG_SOC_DRA7XX) += $(clk-common) clk-7xx.o
+obj-$(CONFIG_SOC_DRA7XX) += $(clk-common) clk-7xx.o \
+ clk-dra7-atl.o
obj-$(CONFIG_SOC_AM43XX) += $(clk-common) clk-43xx.o
endif
diff --git a/drivers/clk/ti/clk-dra7-atl.c b/drivers/clk/ti/clk-dra7-atl.c
new file mode 100644
index ..97a8992eebb7
--- /dev/null
+++ b/drivers/clk/ti/clk-dra7-atl.c
@@ -0,0 +1,313 @@
+/*
+ * DRA7 ATL (Audio Tracking Logic) clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Peter Ujfalusi
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRA7_ATL_INSTANCES 4
+
+#define DRA7_ATL_PPMR_REG(id) (0x200 + (id * 0x80))
+#define DRA7_ATL_BBSR_REG(id) (0x204 + (id * 0x80))
+#define DRA7_ATL_ATLCR_REG(id) (0x208 + (id * 0x80))
+#define DRA7_ATL_SWEN_REG(id) (0x210 + (id * 0x80))
+#define DRA7_ATL_BWSMUX_REG(id)(0x214 + (id * 0x80))
+#define DRA7_ATL_AWSMUX_REG(id)(0x218 + (id * 0x80))
+#define DRA7_ATL_PCLKMUX_REG(id) (0x21c + (id * 0x80))
+
+#define DRA7_ATL_SWEN BIT(0)
+#define DRA7_ATL_DIVIDER_MASK (0x1f)
+#define DRA7_ATL_PCLKMUX BIT(0)
+struct dra7_atl_clock_info;
+
+struct dra7_atl_desc {
+ struct clk *clk;
+ struct clk_hw hw;
+ struct dra7_atl_clock_info *cinfo;
+ int id;
+
+ bool probed;/* the driver for the IP has been loaded */
+ bool valid; /* configured */
+ bool enabled;
+ u32 bws;/* Baseband Word Select Mux */
+ u32 aws;/* Audio Word Select Mux */
+ u32 divider;/* Cached divider value */
+};
+
+struct dra7_atl_clock_info {
+ struct device *dev;
+ void __iomem *iobase;
+
+ struct dra7_atl_desc *cdesc;
+};
+
+#define to_atl_desc(_hw) container_of(_hw, struct dra7_atl_desc, hw)
+
+static inline void atl_write(struct dra7_atl_clock_info *cinfo, u32 reg,
+u32 val)
+{
+ __raw_writel(val, cinfo->iobase + reg);
+}
+
+static inline int atl_read(struct dra7_atl_clock_info *cinfo, u32 reg)
+{
+ return __raw_readl(cinfo->iobase + reg);
+}
+
+static int atl_clk_enable(struct clk_hw *hw)
+{
+ struct dra7_atl_desc *cdesc = to_atl_desc(hw);
+
+ if (!cdesc->probed)
+ goto out;
+
+ if (unlikely(!cdesc->valid))
+ dev_warn(cdesc->cinfo->dev, "atl%d has not been configured\n",
+cdesc->id);
+ pm_runtime_get_sync(cdesc->cinfo->dev);
+
+ atl_write(cdesc->cinfo, DRA7_ATL_ATLCR_REG(cdesc->id)
[PATCH v2 4/4] ARM: DTS: dra7/dra7xx-clocks: ATL related changes
Modify the clock nodes for the ATL clocks to use the ATL clock driver to
handle them.
Add the ATL device node at the same time for DRA7.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/dra7.dtsi | 11 +++
arch/arm/boot/dts/dra7xx-clocks.dtsi | 16
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 149b55099935..84071423016e 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -789,6 +789,17 @@
dma-names = "tx0", "rx0";
status = "disabled";
};
+
+ atl: atl@4843c000 {
+ compatible = "ti,dra7-atl";
+ reg = <0x4843c000 0x3ff>;
+ ti,hwmods = "atl";
+ ti,provided-clocks = <&atl_clkin0_ck>, <&atl_clkin1_ck>,
+<&atl_clkin2_ck>, <&atl_clkin3_ck>;
+ clocks = <&atl_gfclk_mux>;
+ clock-names = "fck";
+ status = "disabled";
+ };
};
};
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 30160348934c..789e92cd5595 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -10,26 +10,26 @@
&cm_core_aon_clocks {
atl_clkin0_ck: atl_clkin0_ck {
#clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
};
atl_clkin1_ck: atl_clkin1_ck {
#clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
};
atl_clkin2_ck: atl_clkin2_ck {
#clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
};
atl_clkin3_ck: atl_clkin3_ck {
#clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
};
hdmi_clkin_ck: hdmi_clkin_ck {
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] clk: Add clock driver for DRA7 ATL (Audio Tracking Logic)
Hi, Changes since v1: - ATL binding documentation and driver has been separated. Audio Tracking Logic is designed to be used by HD Radio applications to synchronize the audio output clocks to the baseband clock. ATL can be also used to track errors between two reference clocks (BWS, AWS) and generate a modulated clock output which averages to some desired frequency. In essence ATL is generating a clock to be used by an audio codec and also to be used by the SoC as MCLK. The series will correct atl related clock names, adds binding documentation and corresponding driver for the ATL and integrates the ATL clock into the clock tree. V1 of the ATL series: https://lkml.org/lkml/2014/4/2/238 Regards, Peter --- Peter Ujfalusi (4): ARM: dts: dra7xx-clocks: Correct name for atl clkin3 clock dt:/bindings: DRA7 ATL (Audio Tracking Logic) clock bindings clk: ti: Driver for DRA7 ATL (Audio Tracking Logic) ARM: DTS: dra7/dra7xx-clocks: ATL related changes .../devicetree/bindings/clock/ti/dra7-atl.txt | 97 +++ arch/arm/boot/dts/dra7.dtsi| 11 + arch/arm/boot/dts/dra7xx-clocks.dtsi | 38 +-- drivers/clk/ti/Makefile| 3 +- drivers/clk/ti/clk-7xx.c | 2 +- drivers/clk/ti/clk-dra7-atl.c | 313 + include/dt-bindings/clk/ti-dra7-atl.h | 40 +++ 7 files changed, 483 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/dra7-atl.txt create mode 100644 drivers/clk/ti/clk-dra7-atl.c create mode 100644 include/dt-bindings/clk/ti-dra7-atl.h -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] dt:/bindings: DRA7 ATL (Audio Tracking Logic) clock bindings
Audio Tracking Logic is designed to be used by HD Radio applications to
synchronize the audio output clocks to the baseband clock. ATL can be also
used to track errors between two reference clocks (BWS, AWS) and generate a
modulated
clock output which averages to some desired frequency.
In essence ATL is generating a clock to be used by an audio codec and also
to be used by the SoC as MCLK.
To be able to integrate the ATL provided clocks to the clock tree we need
two types of DT binding:
- DT clock nodes to represent the ATL clocks towards the CCF
- binding for the ATL IP itself which is going to handle the hw
configuration
The reason for this type of setup is that ATL itself is a separate device
in the SoC, it has it's own address space and clock domain. Other IPs can
use the ATL generated clock as their functional clock (McASPs for example)
and external components like audio codecs can also use the very same clock
as their MCLK.
The ATL IP in DRA7 contains 4 ATL instences.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/clock/ti/dra7-atl.txt | 97 ++
include/dt-bindings/clk/ti-dra7-atl.h | 40 +
2 files changed, 137 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/ti/dra7-atl.txt
create mode 100644 include/dt-bindings/clk/ti-dra7-atl.h
diff --git a/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt
b/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt
new file mode 100644
index ..c90e63c443ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt
@@ -0,0 +1,97 @@
+Device Tree Clock bindings for ATL (Audio Tracking Logic) of DRA7 SoC.
+
+The ATL IP is used to generate clock to be used to synchronize baseband and
+audio codec. A single ATL IP provides four ATL clock instances sharing the same
+functional clock but can be configured to provide different clocks.
+ATL can maintain a clock averages to some desired frequency based on the
bws/aws
+signals - can compensate the drift between the two ws signal.
+
+In order to provide the support for ATL and it's output clocks (which can be
used
+internally within the SoC or external components) two sets of bindings is
needed:
+
+Clock tree binding:
+This binding uses the common clock binding[1].
+To be able to integrate the ATL clocks with DT clock tree.
+Provides ccf level representation of the ATL clocks to be used by drivers.
+Since the clock instances are part of a single IP this binding is used as a
node
+for the DT clock tree, the IP driver is needed to handle the actual
configuration
+of the IP.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "ti,dra7-atl-clock"
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles to functional clock of ATL
+
+Binding for the IP driver:
+This binding is used to configure the IP driver which is going to handle the
+configuration of the IP for the ATL clock instances.
+
+Required properties:
+- compatible : shall be "ti,dra7-atl"
+- reg : base address for the ATL IP
+- ti,provided-clocks : List of phandles to the clocks associated with the ATL
+- clocks : link phandles to functional clock of ATL
+- clock-names : Shall be set to "fck"
+- ti,hwmods : Shall be set to "atl"
+
+Optional properties:
+Configuration of ATL instances:
+- atl{0/1/2/3} {
+ - bws : Baseband word select signal selection
+ - aws : Audio word select signal selection
+};
+
+For valid word select signals, see the dt-bindings/clk/ti-dra7-atl.h include
+file.
+
+Examples:
+/* clock bindings for atl provided clocks */
+atl_clkin0_ck: atl_clkin0_ck {
+ #clock-cells = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
+};
+
+atl_clkin1_ck: atl_clkin1_ck {
+ #clock-cells = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
+};
+
+atl_clkin2_ck: atl_clkin2_ck {
+ #clock-cells = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
+};
+
+atl_clkin3_ck: atl_clkin3_ck {
+ #clock-cells = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
+};
+
+/* binding for the IP */
+atl: atl@4843c000 {
+ compatible = "ti,dra7-atl";
+ reg = <0x4843c000 0x3ff>;
+ ti,hwmods = "atl";
+ ti,provided-clocks = <&atl_clkin0_ck>, <&atl_clkin1_ck>,
+ <&atl_clkin2_ck>, <&atl_clkin3_ck>;
+ clocks = <&atl_gfclk_mux>;
+ clock-names = "fck";
+ status = "disabled";
+};
+
+#include
+
+&atl {
+ status = "okay";
+
+ atl2 {
+ bws = ;
+ a
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
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
>
> -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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio clocks
Palmas class of devices can provide 32K clock(s) to be used by other devices
on the board. Depending on the actual device the provided clocks can be:
CLK32K_KG and CLK32K_KGAUDIO
or only one:
CLK32K_KG (TPS659039 for example)
Use separate compatible flags for the two 32K clock.
A system which needs or have only one of the 32k clock from
Palmas will need to add node(s) for each clock as separate section
in the dts file.
The two compatible property is:
"ti,palmas-clk32kg" for clk32kg clock
"ti,palmas-clk32kgaudio" for clk32kgaudio clock
Apart from the register control of the clocks - which is done via
the clock API there is a posibility to enable the external sleep
control. In this way the clock can be enabled/disabled on demand by the
user of the clock.
Signed-off-by: Peter Ujfalusi
---
.../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35 ++
include/dt-bindings/mfd/palmas.h | 18 +++
2 files changed, 53 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt
create mode 100644 include/dt-bindings/mfd/palmas.h
diff --git
a/Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt
b/Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt
new file mode 100644
index ..4208886d834a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt
@@ -0,0 +1,35 @@
+* Palmas 32KHz clocks *
+
+Palmas device has two clock output pins for 32KHz, KG and KG_AUDIO.
+
+This binding uses the common clock binding ./clock-bindings.txt.
+
+Required properties:
+- compatible : "ti,palmas-clk32kg" for clk32kg clock
+ "ti,palmas-clk32kgaudio" for clk32kgaudio clock
+- #clock-cells : shall be set to 0.
+
+Optional property:
+- ti,external-sleep-control: The external enable input pins controlled the
+ enable/disable of clocks. The external enable input pins ENABLE1,
+ ENABLE2 and NSLEEP. The valid values for the external pins are:
+ PALMAS_EXT_CONTROL_PIN_ENABLE1 for ENABLE1 pin
+ PALMAS_EXT_CONTROL_PIN_ENABLE2 for ENABLE2 pin
+ PALMAS_EXT_CONTROL_PIN_NSLEEP for NSLEEP pin
+ Option 0 or missing this property means the clock is enabled/disabled
+ via register access and these pins do not have any control.
+ The macros of external control pins for DTS is defined at
+ dt-bindings/mfd/palmas.h
+
+Example:
+ #include
+ ...
+ palmas: tps65913@58 {
+ ...
+ clk32kg: palmas_clk32k@0 {
+ compatible = "ti,palmas-clk32kg";
+ #clock-cells = <0>;
+ ti,external-sleep-control =
;
+ };
+ ...
+ };
diff --git a/include/dt-bindings/mfd/palmas.h b/include/dt-bindings/mfd/palmas.h
new file mode 100644
index ..2c8ac4841385
--- /dev/null
+++ b/include/dt-bindings/mfd/palmas.h
@@ -0,0 +1,18 @@
+/*
+ * This header provides macros for Palmas device bindings.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation.
+ *
+ * Author: Laxman Dewangan
+ *
+ */
+
+#ifndef __DT_BINDINGS_PALMAS_H__
+#define __DT_BINDINGS_PALMAS_H
+
+/* External control pins */
+#define PALMAS_EXT_CONTROL_PIN_ENABLE1 1
+#define PALMAS_EXT_CONTROL_PIN_ENABLE2 2
+#define PALMAS_EXT_CONTROL_PIN_NSLEEP 3
+
+#endif /* __DT_BINDINGS_PALMAS_H */
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
Palmas class of devices can provide 32K clock(s) to be used by other devices
on the board. Depending on the actual device the provided clocks can be:
CLK32K_KG and CLK32K_KGAUDIO
or only one:
CLK32K_KG (TPS659039 for example)
Use separate compatible flags for the two 32K clock.
A system which needs or have only one of the 32k clock from
Palmas will need to add node(s) for each clock as separate section
in the dts file.
The two compatible property is:
"ti,palmas-clk32kg" for clk32kg clock
"ti,palmas-clk32kgaudio" for clk32kgaudio clock
Apart from the register control of the clocks - which is done via
the clock API there is a posibility to enable the external sleep
control. In this way the clock can be enabled/disabled on demand by the
user of the clock.
See the documentation for more details.
Signed-off-by: Peter Ujfalusi
---
drivers/clk/Kconfig | 7 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-palmas.c | 307 +++
3 files changed, 315 insertions(+)
create mode 100644 drivers/clk/clk-palmas.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 6f56d3a4f010..a070b77a1e17 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -109,6 +109,13 @@ config COMMON_CLK_KEYSTONE
Supports clock drivers for Keystone based SOCs. These SOCs have local
a power sleep control module that gate the clock to the IPs and PLLs.
+config COMMON_CLK_PALMAS
+ tristate "Clock driver for TI Palmas devices"
+ depends on MFD_PALMAS
+ ---help---
+ This driver supports TI Palmas devices 32KHz output KG and KG_AUDIO
+ using common clock framework.
+
source "drivers/clk/qcom/Kconfig"
endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 5f8a28735c96..d67214debc12 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
+obj-$(CONFIG_COMMON_CLK_PALMAS)+= clk-palmas.o
obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
diff --git a/drivers/clk/clk-palmas.c b/drivers/clk/clk-palmas.c
new file mode 100644
index ..781630e1372b
--- /dev/null
+++ b/drivers/clk/clk-palmas.c
@@ -0,0 +1,307 @@
+/*
+ * Clock driver for Palmas device.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation.
+ * Copyright (c) 2013-2014 Texas Instruments, Inc.
+ *
+ * Author: Laxman Dewangan
+ * Peter Ujfalusi
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PALMAS_CLOCK_DT_EXT_CONTROL_ENABLE11
+#define PALMAS_CLOCK_DT_EXT_CONTROL_ENABLE22
+#define PALMAS_CLOCK_DT_EXT_CONTROL_NSLEEP 3
+
+struct palmas_clk32k_desc {
+ const char *clk_name;
+ unsigned int control_reg;
+ unsigned int enable_mask;
+ unsigned int sleep_mask;
+ unsigned int sleep_reqstr_id;
+ int delay;
+};
+
+struct palmas_clock_info {
+ struct device *dev;
+ struct clk *clk;
+ struct clk_hw hw;
+ struct palmas *palmas;
+ struct palmas_clk32k_desc *clk_desc;
+ int ext_control_pin;
+};
+
+static inline struct palmas_clock_info *to_palmas_clks_info(struct clk_hw *hw)
+{
+ return container_of(hw, struct palmas_clock_info, hw);
+}
+
+static unsigned long palmas_clks_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ return 32768;
+}
+
+static int palmas_clks_prepare(struct clk_hw *hw)
+{
+ struct palmas_clock_info *cinfo = to_palmas_clks_info(hw);
+ int ret;
+
+ ret = palmas_update_bits(cinfo->palmas, PALMAS_RESOURCE_BASE,
+cinfo->clk_desc->control_reg,
+cinfo->clk_desc->enable_mask,
+cinfo->clk_desc->enable_mask);
+ if (ret < 0)
+ dev_err(cinfo->dev, "Reg 0x%02x update failed, %d\n",
+ cinfo->clk_desc->control_reg, ret);
+ else if (cinfo->clk_desc->delay)
+ udelay(cinfo->clk_desc->delay);
+
+ return r
[PATCH v2 0/2] clk: Support for Palmas clk32kg and clk32kgaudio clocks
Hi, Changes since v1: - binding documentation and driver has been separated based on Nishanth Menon's comment v1 of the driver can be found: https://lkml.org/lkml/2014/4/3/104 Palmas class of devices can provide 32K clock(s) to be used by other devices on the board. Depending on the actual device the provided clocks can be: CLK32K_KG and CLK32K_KGAUDIO or only one: CLK32K_KG (TPS659039 for example) Use separate compatible flags for the two 32K clock. A system which needs or have only one of the 32k clock from Palmas will need to add node(s) for each clock as separate section in the dts file. The two compatible property is: "ti,palmas-clk32kg" for clk32kg clock "ti,palmas-clk32kgaudio" for clk32kgaudio clock Apart from the register control of the clocks - which is done via the clock API there is a posibility to enable the external sleep control. In this way the clock can be enabled/disabled on demand by the user of the clock. Regards, Peter --- Peter Ujfalusi (2): dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio clocks clk: Add driver for Palmas clk32kg and clk32kgaudio clocks .../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35 +++ drivers/clk/Kconfig| 7 + drivers/clk/Makefile | 1 + drivers/clk/clk-palmas.c | 307 + include/dt-bindings/mfd/palmas.h | 18 ++ 5 files changed, 368 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt create mode 100644 drivers/clk/clk-palmas.c create mode 100644 include/dt-bindings/mfd/palmas.h -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mfd: twl6040: Correct HPPLL configuration for 19.2 and 38.4 MHz mclk
When the MCLK is 19.2 or 38.4 MHz the HPPLL need to be enabled and can be put in bypass mode. This will fix HPPLL use on boards with 19.2MHz mclk. Signed-off-by: Peter Ujfalusi --- drivers/mfd/twl6040.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c index 12b314ea48dc..ae26d84b3a59 100644 --- a/drivers/mfd/twl6040.c +++ b/drivers/mfd/twl6040.c @@ -441,12 +441,9 @@ int twl6040_set_pll(struct twl6040 *twl6040, int pll_id, TWL6040_HPLLENA; break; case 1920: - /* - * PLL disabled - * (enable PLL if MCLK jitter quality - * doesn't meet specification) - */ - hppllctl |= TWL6040_MCLK_19200KHZ; + /* PLL enabled, bypass mode */ + hppllctl |= TWL6040_MCLK_19200KHZ | + TWL6040_HPLLBP | TWL6040_HPLLENA; break; case 2600: /* PLL enabled, active mode */ @@ -454,9 +451,9 @@ int twl6040_set_pll(struct twl6040 *twl6040, int pll_id, TWL6040_HPLLENA; break; case 3840: - /* PLL enabled, active mode */ + /* PLL enabled, bypass mode */ hppllctl |= TWL6040_MCLK_38400KHZ | - TWL6040_HPLLENA; + TWL6040_HPLLBP | TWL6040_HPLLENA; break; default: dev_err(twl6040->dev, -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: omap5: hwmod_data: Add AESS related data
Add the needed hwmod entries which is needed for AESS (Audio Engine
SubSystem) and ABE.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 64 ++
1 file changed, 64 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e829664e6a6c..3e20c025b5a4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -146,6 +146,7 @@ static struct omap_hwmod omap54xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP54XX_CM_ABE_L4_ABE_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_ABE_AESS_CONTEXT_OFFSET,
.flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
},
},
@@ -211,6 +212,42 @@ static struct omap_hwmod omap54xx_mpu_private_hwmod = {
};
/*
+ * 'aess' class
+ * audio engine sub system
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_aess_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART |
+ MSTANDBY_SMART_WKUP),
+ .sysc_fields= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_aess_hwmod_class = {
+ .name = "aess",
+ .sysc = &omap54xx_aess_sysc,
+ .enable_preprogram = omap_hwmod_aess_preprogram,
+};
+
+/* aess */
+static struct omap_hwmod omap54xx_aess_hwmod = {
+ .name = "aess",
+ .class = &omap54xx_aess_hwmod_class,
+ .clkdm_name = "abe_clkdm",
+ .main_clk = "aess_fclk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_ABE_AESS_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_ABE_AESS_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'counter' class
* 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
*/
@@ -1892,6 +1929,14 @@ static struct omap_hwmod_ocp_if
omap54xx_l4_cfg__l3_main_3 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* aess -> l4_abe */
+static struct omap_hwmod_ocp_if __maybe_unused omap54xx_aess__l4_abe = {
+ .master = &omap54xx_aess_hwmod,
+ .slave = &omap54xx_l4_abe_hwmod,
+ .clk= "abe_iclk",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_1 -> l4_abe */
static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l4_abe = {
.master = &omap54xx_l3_main_1_hwmod,
@@ -1966,6 +2011,22 @@ static struct omap_hwmod_ocp_if
omap54xx_l4_cfg__dma_system = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_abe -> aess */
+static struct omap_hwmod_ocp_if __maybe_unused omap54xx_l4_abe__aess = {
+ .master = &omap54xx_l4_abe_hwmod,
+ .slave = &omap54xx_aess_hwmod,
+ .clk= "abe_iclk",
+ .user = OCP_USER_MPU,
+};
+
+/* l4_abe -> aess (dma) */
+static struct omap_hwmod_ocp_if __maybe_unused omap54xx_l4_abe__aess_dma = {
+ .master = &omap54xx_l4_abe_hwmod,
+ .slave = &omap54xx_aess_hwmod,
+ .clk= "abe_iclk",
+ .user = OCP_USER_SDMA,
+};
+
/* l4_abe -> dmic */
static struct omap_hwmod_ocp_if omap54xx_l4_abe__dmic = {
.master = &omap54xx_l4_abe_hwmod,
@@ -2417,6 +2478,9 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[]
__initdata = {
&omap54xx_l3_main_1__l3_main_3,
&omap54xx_l3_main_2__l3_main_3,
&omap54xx_l4_cfg__l3_main_3,
+ &omap54xx_l4_abe__aess,
+ &omap54xx_l4_abe__aess_dma,
+ &omap54xx_aess__l4_abe,
&omap54xx_l3_main_1__l4_abe,
&omap54xx_mpu__l4_abe,
&omap54xx_l3_main_1__l4_cfg,
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: omap5: hwmod_data: Update McPDM hwmod's flags
Add HWMOD_SWSUP_SIDLE to flags.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 892317294fdc..e829664e6a6c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -895,7 +895,7 @@ static struct omap_hwmod omap54xx_mcpdm_hwmod = {
* current exception.
*/
- .flags = HWMOD_EXT_OPT_MAIN_CLK,
+ .flags = HWMOD_EXT_OPT_MAIN_CLK | HWMOD_SWSUP_SIDLE,
.main_clk = "pad_clks_ck",
.prcm = {
.omap4 = {
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: DTS: omap54xx-clocks: Correct abe_iclk clock node
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
---
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 {
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: DTS: omap54xx-clocks: remove the autoidle properties for clock nodes
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.
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";
[PATCH] clk: ti: clk-54xx: Set the rate for dpll_abe_m2x2_ck
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
---
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)
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 00/19] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372
On 04/24/2014 05:19 PM, Nishanth Menon wrote: > On 04/24/2014 03:55 AM, Peter Ujfalusi wrote: >> On 04/18/2014 12:00 AM, Nishanth Menon wrote: >>> On 04/17/2014 03:57 PM, Santosh Shilimkar wrote: >>>> I looked at the series and its looks pretty good. Thanks for fixups, >>>> updates. >>>> For whole series, >>>> Acked-by: Santosh Shilimkar >>>> >>> >>> Thanks. >>> >>>>> Patches(including Peter's) is available here: >>>>> https://github.com/nmenon/linux-2.6-playground/commits/l3noc/driver-fixes-v2 >>>>> >>>> Can Tony pull this branch for 3.16 then which includes Peter's series as >>>> well ? >>> >>> there is just an empty commit with information about peter's patches >>> that i lined up to differentiate the series.. I can drop it if Tony >>> would like me to. >> >> Looking at the branch I see my patches underneath so they are in the branch. >> It would be great if Tony pulls this... Will be a great present to my patches >> (omap_l3 patches in the branch) for their 1 year anniversary of being out on >> the mailing list ;) >> > Peter, can I take this as an Ack for this series? if yes, I can repost > a v3 with all the acks, updates together. Nishanth, sure you can add my Ack or Reviewed-by. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 00/19] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372
On 04/18/2014 12:00 AM, Nishanth Menon wrote: > On 04/17/2014 03:57 PM, Santosh Shilimkar wrote: >> I looked at the series and its looks pretty good. Thanks for fixups, updates. >> For whole series, >> Acked-by: Santosh Shilimkar >> > > Thanks. > >>> Patches(including Peter's) is available here: >>> https://github.com/nmenon/linux-2.6-playground/commits/l3noc/driver-fixes-v2 >>> >> Can Tony pull this branch for 3.16 then which includes Peter's series as >> well ? > > there is just an empty commit with information about peter's patches > that i lined up to differentiate the series.. I can drop it if Tony > would like me to. Looking at the branch I see my patches underneath so they are in the branch. It would be great if Tony pulls this... Will be a great present to my patches (omap_l3 patches in the branch) for their 1 year anniversary of being out on the mailing list ;) -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] clk: Add clock driver for DRA7 ATL (Audio Tracking Logic)
Hi Mike, On 04/02/2014 04:55 PM, Peter Ujfalusi wrote: > Hi, > > Audio Tracking Logic is designed to be used by HD Radio > applications to synchronize the audio output clocks to the > baseband clock. ATL can be also used to track errors between > two reference clocks (BWS, AWS) and generate a modulated > clock output which averages to some desired frequency. > > To be able to integrate the ATL provided clocks to the clock tree we need > two types of DT binding: > - DT clock nodes to represent the ATL clocks towards the CCF > - binding for the ATL IP itself which is going to handle the hw > configuration > > The reason for this type of setup is that ATL itself is a separate device > in the SoC, it has it's own address space and clock domain. Other IPs can > use the ATL generated clock as their functional clock (McASPs for example) > and external components like audio codecs can also use the very same clock > as their MCLK. > > With setup pm_runtime can handle the ATL clock on demand of it's use and > all the IP which needs ATL clock can be sure that it is enabled for them. > > The first patch fixes the name of atl clkin3 node in dtsi file. Can you take a look at this series? Thanks, Péter > > Regards, > Peter > --- > Peter Ujfalusi (3): > ARM: dts: dra7xx-clocks: Correct name for atl clkin3 clock > clk: Driver for DRA7 ATL (Audio Tracking Logic) > ARM: DTS: dra7/dra7xx-clocks: ATL related changes > > .../devicetree/bindings/clock/ti/dra7-atl.txt | 97 +++ > arch/arm/boot/dts/dra7.dtsi| 11 + > arch/arm/boot/dts/dra7xx-clocks.dtsi | 38 +-- > drivers/clk/ti/Makefile| 3 +- > drivers/clk/ti/clk-7xx.c | 2 +- > drivers/clk/ti/clk-dra7-atl.c | 313 > + > include/dt-bindings/clk/ti-dra7-atl.h | 40 +++ > 7 files changed, 483 insertions(+), 21 deletions(-) > create mode 100644 Documentation/devicetree/bindings/clock/ti/dra7-atl.txt > create mode 100644 drivers/clk/ti/clk-dra7-atl.c > create mode 100644 include/dt-bindings/clk/ti-dra7-atl.h > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND 0/3] mfd: twl6040: Updates for i2s speed and fix for chip deadlock
Lee, On 04/01/2014 04:44 PM, Peter Ujfalusi wrote: > Hi, > > While looking into a report by Florian Vaussard [1] I have noticed couple of > most > likely unrelated issues: > - all boards using twl6040 configures the i2c bus to 400KHz while twl6040 is > set > to 100KHz as default. > - if I set the audpwron GPIO high [2] in the bootloader the i2c communication > towards > twl6040 will be broken > - got confirmation from HW design teams that twl6040 can work on a bus with > 400KHz even if after hard reset but it is optimal to swithc to 400KHz mode > as > soon as possible. > > The solution or these are: > set the twl6040 to i2c fast mode with regmap patch > Clear the INTID register right after we request the audpwron GPIO and set it > to > low. Do you want me to resend this series again? Thanks, Péter > > Generated on top of: > git://git.linaro.org/people/lee.jones/mfd.git for-mfd-next > > Tested on PandaBoard, PandaBoardES, OMAP4-blaze (SDP) > > [1] http://www.spinics.net/lists/arm-kernel/msg310725.html > [2] Command in u-boot to enable the audpwron on PandaBoards: gpio set 127 > > Regards, > Peter > --- > Peter Ujfalusi (3): > mfd: twl6040: Select i2c fast mode as default with regmap patch > mfd: twl6040: Move register patching earlier in probe > mfd: twl6040: Clear the interrupt ID register before requesting IRQ > > drivers/mfd/twl6040.c | 19 +-- > include/linux/mfd/twl6040.h | 1 + > 2 files changed, 14 insertions(+), 6 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
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?
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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
Hi Mike,
On 04/03/2014 01:52 PM, Peter Ujfalusi wrote:
> Palmas class of devices have either twl 32K clock outputs:
> CLK32K_KG and CLK32K_KGAUDIO
> or only one:
> CLK32K_KG (TPS659039 for example)
>
> Use separate compatible flags for the two 32K clock.
> A system which needs or have only one of the 32k clock from
> Palmas will need to add node(s) for each clock as separate section
> in the dts file.
> The two compatible property is:
> "ti,palmas-clk32kg" for clk32kg clock
> "ti,palmas-clk32kgaudio" for clk32kgaudio clock
>
> Apart from the register control of the clocks - which is done via
> the clock API there is a posibility to enable the external sleep
> control.
>
> See the documentation for more details.
Can you take a look at this and comment so I can resend it with
documentation/implementation separated.
Thanks,
Péter
>
> Signed-off-by: Peter Ujfalusi
> ---
> Hi,
>
> Part of the driver is based on the v4 of palmas clock driver from
> Laxman Dewangan, which can be found here:
> https://lkml.org/lkml/2013/10/9/146
>
> Since no updates followed after the comments and patches I have squashed my
> updates to rewrite the original driver to be able to support more devices from
> the Palmas family.
>
> Regards,
> Peter
>
> .../devicetree/bindings/clock/clk-palmas.txt | 35 +++
> drivers/clk/Kconfig| 7 +
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-palmas.c | 307
> +
> include/dt-bindings/mfd/palmas.h | 18 ++
> 5 files changed, 368 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas.txt
> create mode 100644 drivers/clk/clk-palmas.c
> create mode 100644 include/dt-bindings/mfd/palmas.h
>
> diff --git a/Documentation/devicetree/bindings/clock/clk-palmas.txt
> b/Documentation/devicetree/bindings/clock/clk-palmas.txt
> new file mode 100644
> index ..4208886d834a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/clk-palmas.txt
> @@ -0,0 +1,35 @@
> +* Palmas 32KHz clocks *
> +
> +Palmas device has two clock output pins for 32KHz, KG and KG_AUDIO.
> +
> +This binding uses the common clock binding ./clock-bindings.txt.
> +
> +Required properties:
> +- compatible : "ti,palmas-clk32kg" for clk32kg clock
> + "ti,palmas-clk32kgaudio" for clk32kgaudio clock
> +- #clock-cells : shall be set to 0.
> +
> +Optional property:
> +- ti,external-sleep-control: The external enable input pins controlled the
> + enable/disable of clocks. The external enable input pins ENABLE1,
> + ENABLE2 and NSLEEP. The valid values for the external pins are:
> + PALMAS_EXT_CONTROL_PIN_ENABLE1 for ENABLE1 pin
> + PALMAS_EXT_CONTROL_PIN_ENABLE2 for ENABLE2 pin
> + PALMAS_EXT_CONTROL_PIN_NSLEEP for NSLEEP pin
> + Option 0 or missing this property means the clock is enabled/disabled
> + via register access and these pins do not have any control.
> + The macros of external control pins for DTS is defined at
> + dt-bindings/mfd/palmas.h
> +
> +Example:
> + #include
> + ...
> + palmas: tps65913@58 {
> + ...
> + clk32kg: palmas_clk32k@0 {
> + compatible = "ti,palmas-clk32kg";
> + #clock-cells = <0>;
> + ti,external-sleep-control =
> ;
> + };
> + ...
> + };
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 6f56d3a4f010..a070b77a1e17 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -109,6 +109,13 @@ config COMMON_CLK_KEYSTONE
>Supports clock drivers for Keystone based SOCs. These SOCs have
> local
> a power sleep control module that gate the clock to the IPs and PLLs.
>
> +config COMMON_CLK_PALMAS
> + tristate "Clock driver for TI Palmas devices"
> + depends on MFD_PALMAS
> + ---help---
> + This driver supports TI Palmas devices 32KHz output KG and KG_AUDIO
> + using common clock framework.
> +
> source "drivers/clk/qcom/Kconfig"
>
> endmenu
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 5f8a28735c96..d67214debc12 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
> obj-$(CONFIG_ARCH_MOXART)+= clk-moxart.o
> obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
> obj-$(CONFIG_ARCH_NSPIRE)+= clk-nspire
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On 04/16/2014 07:05 PM, Joel Fernandes wrote: > On 04/16/2014 07:59 AM, Peter Ujfalusi wrote: > [..] >>>>>> If the dma-priority is missing we should assume lowest priority (0). >>>>>> The highest priority depends on the platform. For eDMA3 in AM335x it is >>>>>> three >>>>>> level. For designware controller you might have the range 0-8 as valid. >>>>>> >>>>>> The question is how to get this information into use? >>>>>> We can take the priority number in the core when the dma channel is >>>>>> requested >>>>>> and add field to "struct dma_chan" in order to store it and the DMA >>>>>> drivers >>>>>> could have access to it. >>> >>> How about Vinod's idea of extending dma_slave_config? Priority is >>> similar to rest of the runtime setup dmaengine_slave_config() is meant >>> to do. >> >> The dma_slave_config is prepared by the client drivers, so they would need to >> be updated to handle the priority for the DMA. This would lead to duplicated >> code - unless we have a small function in dmaengine core to fetch this >> information, but still all dmaengine clients would need to call that. >> IMHO it would be better to let the dmaengine core to take the priority for >> the >> channel when it has been asked so client drivers does not need to know about >> it. >> > > I still feel it is much cleaner to keep this out of DT and have audio > driver configure the channel manually for higher priority. Because, > AFAIK audio is the only device that uses slave DMA and needs higher > priority. I'd imagine everyone else who needs high priority, have their > own dedicated DMAC, so from that sense I don't see the priority > mechanism being used a lot anywhere else but audio, so atleast we can > rule out things like code duplication in other drivers. Priority can be > set to a default of low for those drivers that don't configure the > channel for priority. I'm also OK with EDMA driver configuring channel > for higher priority manually for the Cyclic case like you did initially. So how should we go about this? I'm fine to select higher priority in the eDMA driver for now when a cyclic channel is configured and later when we have (if we ever have) generic way to handle DMA channel/transaction priority we can switch eDMA as well to use it. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND] dmaengine: edma: Add channel number to debug prints
It helps to identify issues if we have some information regarding to the
channel which the event is associated.
Signed-off-by: Peter Ujfalusi
Acked-by: Joel Fernandes
---
Hi Vinod,
rebased on:
git://git.infradead.org/users/vkoul/slave-dma.git next
On top of:
406efb1a745c dmaengine: edma: No need save/restore interrupt flags during...
Regards,
Peter
drivers/dma/edma.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index fa87fd52b0ad..473155d34d7b 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -183,7 +183,8 @@ static void edma_execute(struct edma_chan *echan)
}
if (edesc->processed <= MAX_NR_SG) {
- dev_dbg(dev, "first transfer starting %d\n", echan->ch_num);
+ dev_dbg(dev, "first transfer starting on channel %d\n",
+ echan->ch_num);
edma_start(echan->ch_num);
} else {
dev_dbg(dev, "chan: %d: completed %d elements, resuming\n",
@@ -197,7 +198,7 @@ static void edma_execute(struct edma_chan *echan)
* MAX_NR_SG
*/
if (echan->missed) {
- dev_dbg(dev, "missed event in execute detected\n");
+ dev_dbg(dev, "missed event on channel %d\n", echan->ch_num);
edma_clean_channel(echan->ch_num);
edma_stop(echan->ch_num);
edma_start(echan->ch_num);
@@ -779,7 +780,7 @@ static int edma_alloc_chan_resources(struct dma_chan *chan)
echan->alloced = true;
echan->slot[0] = echan->ch_num;
- dev_dbg(dev, "allocated channel for %u:%u\n",
+ dev_dbg(dev, "allocated channel %d for %u:%u\n", echan->ch_num,
EDMA_CTLR(echan->ch_num), EDMA_CHAN_SLOT(echan->ch_num));
return 0;
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: do not set up hardware for IRQ_TYPE_NONE
On 04/23/2014 05:50 PM, Linus Walleij wrote: > Some GPIO irqchip drivers exploit the irqdomain mapping > function to set up the IRQ default type in the hardware, > make sure that if we pass IRQ_TYPE_NONE, no hardware setup > whatsoever takes place (this should be the norm) until > later when the IRQ gets utilized. > > Cc: Nishanth Menon > Cc: Peter Ujfalusi > Cc: Ezequiel Garcia > Cc: Javier Martinez Canillas > Cc: Tony Lindgren > Cc: Santosh Shilimkar > Cc: linux-omap > Signed-off-by: Linus Walleij > --- > TI folks: can you provide a Tested-by tag if this makes your > OMAPs work? I am pretty sure the other platforms will be > unaffected, if they aren't I will switch them over to react > to IRQ_TYPE_DEFAULT. > --- > drivers/gpio/gpiolib.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) Thanks: Tested-by: Peter Ujfalusi > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > index ee1819fdcf35..97d173e9aa2d 100644 > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -1409,7 +1409,12 @@ static int gpiochip_irq_map(struct irq_domain *d, > unsigned int irq, > #else > irq_set_noprobe(irq); > #endif > - irq_set_irq_type(irq, chip->irq_default_type); > + /* > + * No set-up of the hardware will happen if IRQ_TYPE_NONE > + * is passed as default type. > + */ > + if (chip->irq_default_type != IRQ_TYPE_NONE) > + irq_set_irq_type(irq, chip->irq_default_type); > > return 0; > } > @@ -1490,7 +1495,8 @@ static void gpiochip_irqchip_remove(struct gpio_chip > *gpiochip) > * @first_irq: if not dynamically assigned, the base (first) IRQ to > * allocate gpiochip irqs from > * @handler: the irq handler to use (often a predefined irq core function) > - * @type: the default type for IRQs on this irqchip > + * @type: the default type for IRQs on this irqchip, pass IRQ_TYPE_NONE > + * to have the core avoid setting up any default type in the hardware. > * > * This function closely associates a certain irqchip with a certain > * gpiochip, providing an irq domain to translate the local IRQs to > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next regressions (next-20140423 A15: uevm/dra7)
On 04/23/2014 04:47 PM, Nishanth Menon wrote: > Hi, > > Will be great if someone else could confirm as well. > > next-20140423-multi_lpae_defconfig > 1: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2HJJ9SKzM > 2: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2HoDCbtO0 > TOTAL = 2 boards, Booted Boards = 0, No Boot boards = 2 > > next-20140423-multi_v7_defconfig > 1: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2070nXdAg > 2: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s20wKQEqGp > TOTAL = 2 boards, Booted Boards = 0, No Boot boards = 2 > > next-20140423-omap2plus_defconfig > 1: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2XrqUmRqz > 2: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2gQkdoTH4 I suspect you are using ext4 as rootfs? I just sent a fix for this or similar crash (as in the OMAP5432uEVM log): http://marc.info/?l=linux-kernel&m=139826085609497&w=2 > > > Exactly the same setup (rootfs and bootloader) as of yesterday's built > image: > next-20140422-omap2plus_defconfig > 1: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s20sRLHVgN > 2: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s20ZxlYWaB > TOTAL = 2 boards, Booted Boards = 2, No Boot boards = 0 > > -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regressions in linux-next?
On 04/23/2014 10:24 AM, Javier Martinez Canillas wrote: > Hello Nishanth and Tony, > > On Wed, Apr 23, 2014 at 3:30 AM, Nishanth Menon wrote: >> On 01:08-20140423, Javier Martinez Canillas wrote: >> [...] >>>> on AM335x-sk: >>>>> So this makes only am335x-sk to fail with the gpiolib irpchip >>>>> conversion as reported by Peter and you. >>>>> >>>>> Do you know what special use of GPIO have this board to behave >>>>> differently than the other boards? I've looked at the DTS but didn't >>>>> find anything evident. >>>> >>>> I could not find anything interesting yet. Peter did mention that >>>> reverting d04b76626e94 helped make the platform boot fine. I am trying >>>> to add a few prints and see which specific line does things go bad.. >>>> and if so why.. unfortunately, I am using the board remotely as well.. >>>> Will try to track this down in the next few hours and post back. >>>> >>> >>> Great, thanks a lot for your help and sorry for the inconvenience! >> >> Yep - If I am correct, and as we all suspected, GPIO0_7 which controls >> the VTT regulator for DDR is getting configured as input, instead of >> output. >> http://slexy.org/raw/s2gReMRZI6 (with diff: >> http://slexy.org/view/s20nueCE8H - ignore many of the prints as I was >> trying to truncate and isolate - had to switch to non-relaxed versions >> of writes to force sequencing with barriers to trace it down..) >> >> >> Anyways, the key log is [0]: >> gpiochip_irq_map -> calls >> irq_set_irq_type(irq, chip->irq_default_type); >> which inturn triggers: gpio-omap.c's gpio_irq_type >> in this, logic: >> if (!LINE_USED(bank->mod_usage, offset)) is invoked prior to >> setting the input type for the GPIO 0_7 (you can see the logic >> walks through setting every GPIO to input!). >> >> The original usage as far as I could discern was that this function was >> only called after probe got completed as the gpio requests were >> triggered. > > Thanks a lot for figuring out what was going on here. I think that is > not correct for gpiochip_irq_map() to call this function. After all > creating a mapping doesn't mean that the GPIO is actually used as an > IRQ. > >> >> There are probably many hacks possible, but a cleaner solution might >> involve gpio_irqchip knowing when to set the type and knowing which gpios >> not to mess with. >> >> Example hack: >> Since we call gpiochip_irqchip_add with IRQ_TYPE_NONE, >> in gpio-omap's gpio_irq_type could do: >>if (type == IRQ_TYPE_NONE) >> return 0; >> boots, http://slexy.org/raw/s24M8lHqZX - but ofcourse, there'd be other >> side effects I have'nt thought through.. > > Linus, what do you think of the following patch? > > From ede333e85e0320d32e8c2d123560808ed7e43ece Mon Sep 17 00:00:00 2001 > From: Javier Martinez Canillas > Date: Wed, 23 Apr 2014 09:13:54 +0200 > Subject: [PATCH 1/1] gpio: don't call irq_set_irq_type() on IRQ domain map > function > > Creating a mapping for a GPIO pin into the Linux virtual IRQ > space does not necessarily mean that the GPIO is going to be > used as an interrupt line, it only means that it could be used. > > So, calling irq_set_irq_type() is not correct since that is > already done either when a driver calls request_irq() or when > the OF core calls of_irq_to_resource() because a device node > defined a GPIO controller phandle as its "interrupt-parent". > > In either case irq_set_irq_type() will be called and the GPIO > controller driver will take any required action for an IRQ. > > Signed-off-by: Javier Martinez Canillas > --- > drivers/gpio/gpiolib.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > index c12fe9d..b493781 100644 > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -1402,7 +1402,6 @@ static int gpiochip_irq_map(struct irq_domain > *d, unsigned int irq, > #else > irq_set_noprobe(irq); > #endif > - irq_set_irq_type(irq, chip->irq_default_type); > > return 0; > } > Thanks, this makes am335x-evmsk boot with linux-next. Tested-by: Peter Ujfalusi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regressions in linux-next?
On 04/22/2014 04:18 PM, Nishanth Menon wrote: > next-20140422-omap2plus_defconfig > 1: am335x-sk: Boot FAIL: http://slexy.org/raw/s2gh6XsLve > 2: am3517-evm: Boot PASS: http://slexy.org/raw/s2MTkdzPnb > 3: am37x-evm: Boot PASS: http://slexy.org/raw/s2SJwrVat8 > 4: am43xx-epos: Boot PASS: http://slexy.org/raw/s2184jfKlq > 5: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21qIYDHqa >> known > 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21EyANlGX > 7: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s20lc3icwS > 8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ykosQg6C > 9: beaglebone: Boot PASS: http://slexy.org/raw/s2DN9gqlmo > 10: craneboard: Boot FAIL: http://slexy.org/raw/s21bP0auhl > 11: DRA7xx-EVM: Boot FAIL: http://slexy.org/raw/s2rBG0C1x6 > 12: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2N3afw0TI > 13: n900: Boot PASS: http://slexy.org/raw/s21qmT6XCJ > 14: pandaboard-es: Boot FAIL: http://slexy.org/raw/s28vlMGdeh > 15: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20yHoGHdW > 16:sdp2430: Boot PASS: http://slexy.org/raw/s20i8Ir3yn > 17:sdp3430: Boot PASS: http://slexy.org/raw/s20t4VTeEB > 18:sdp4430: Boot FAIL: http://slexy.org/raw/s21SHcOP01 > 19: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s2qmlRZped > TOTAL = 19 boards, Booted Boards = 9, No Boot boards = 10 > > next-20140417-omap2plus_defconfig > 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2Yvz8RRkn > 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2JFbaPPVA >> farm issues. - But peter reports fail as well. Yes, 20140417 boot fails for me on am335x-evmsk. What I can see with early printk is that the boot hangs around/after omap-gpio in all cases without any further information. I have checked the diff between 20140407, which was fine on evmsk regarding to omap-gpio and if I revert: d04b76626e94 gpio: omap: convert driver to use gpiolib irqchip am335x-evmsk boots up fine. With that commit in place PandaBoardES boots fine, but evmsk does not. > 3: am3517-evm: Boot PASS: http://slexy.org/raw/s29h2lXGuw > 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20Whu6Qjr > 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21jBdk51T > 6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2118uUlle >> known. > 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s29I92x0p3 > 8: beagleboard-vanilla: Boot FAIL: http://slexy.org/raw/s2GqJbMp7C >> farm issues > 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s2fb7JvizO > 10: beaglebone: Boot PASS: http://slexy.org/raw/s2uQNDnOlV > 11: craneboard: Boot PASS: http://slexy.org/raw/s2pTk8AgdX > 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2r2XdK8XF > 13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s213f9wx5p > 14: n900: Boot PASS: http://slexy.org/raw/s2SaNcFG85 > 15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2fR7PoakJ > 16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2IMJ75sNc > 17:sdp2430: Boot PASS: http://slexy.org/raw/s207NAmPbO > 18:sdp3430: Boot PASS: http://slexy.org/raw/s20Yzlg3lU > 19:sdp4430: Boot PASS: http://slexy.org/raw/s21eYIZxtI > 20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2HIEtrDX9 > TOTAL = 20 boards, Booted Boards = 17, No Boot boards = 3 > > next-20140416-omap2plus_defconfig > 1: am335x-evm: Boot PASS: http://slexy.org/raw/s20LxN1Qn4 > 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s202mfovsx > 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2IAJlhTFg > 4: am37x-evm: Boot PASS: http://slexy.org/raw/s213AOULx7 > 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s22NCBg38K > 6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s2IhClBS3N >> known > 7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2octtFj30 > 8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20t9axfIr > 9: beaglebone-black: Boot PASS: http://slexy.org/raw/s21FvZM0Gz > 10: beaglebone: Boot PASS: http://slexy.org/raw/s2119uANhW > 11: craneboard: Boot PASS: http://slexy.org/raw/s2FoVFiYaC > 12: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s2FJjqu4MU > 13: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s29X2FBMhu > 14: n900: Boot PASS: http://slexy.org/raw/s2AcjThjhw > 15: pandaboard-es: Boot PASS: http://slexy.org/raw/s2LF8KsxJw > 16: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2E2KTBSFY > 17:sdp2430: Boot PASS: http://slexy.org/raw/s20HnXbU9M > 18:sdp3430: Boot PASS: http://slexy.org/raw/s20OuKg9mw > 19:sdp4430: Boot PASS: http://slexy.org/raw/s25V9CJgUB > 20: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s21WFeZmTd > TOTAL = 20 boards, Booted Boards = 18, No Boot boards = 2 > -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On 04/14/2014 05:32 PM, Sekhar Nori wrote:
>> Yes, you can. But as soon as you have other devices using the same priority
>> (with eDMA3 at least) and asks for a 'long' transfer it can ruin the audio.
>> During audio playback/capture you execute a long MMC read for example can
>> introduce a glitch.
>>
>>> Moreover, IMHO, encoding it in DT now will make it an ABI. Without a
>>> wide variety of example use cases, I think it is too early to commit to
>>> an ABI.
>>
>> True, but we need to start from somewhere?
>
> Right, and based on our IRC discussion, we are not really fixing up the
> priority value space. That makes me much more comfortable with the idea.
The only thing we should agree on is the 0 means lowest priority. I think this
will help in case when a new kernel is fed with an older dt blob where the
property does not exist.
>
Not sure if we should set the range for this either. What I was thinking
is to
add an optional new property to be set by the client nodes, using DMA:
mcasp0: mcasp@48038000 {
compatible = "ti,am33xx-mcasp-audio";
...
dmas = <&edma 8>,
<&edma 9>;
dma-names = "tx", "rx";
dma-priorities = <2>, <2>;
};
>
We could agree that lower number means lower priority, higher is - well -
higher priority.
>
> Even this does not have to be uniform across, right? The numbers could
> be left to interpretation per-SoC.
>
If the dma-priority is missing we should assume lowest priority (0).
The highest priority depends on the platform. For eDMA3 in AM335x it is
three
level. For designware controller you might have the range 0-8 as valid.
The question is how to get this information into use?
We can take the priority number in the core when the dma channel is
requested
and add field to "struct dma_chan" in order to store it and the DMA drivers
could have access to it.
>
> How about Vinod's idea of extending dma_slave_config? Priority is
> similar to rest of the runtime setup dmaengine_slave_config() is meant
> to do.
The dma_slave_config is prepared by the client drivers, so they would need to
be updated to handle the priority for the DMA. This would lead to duplicated
code - unless we have a small function in dmaengine core to fetch this
information, but still all dmaengine clients would need to call that.
IMHO it would be better to let the dmaengine core to take the priority for the
channel when it has been asked so client drivers does not need to know about it.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 07/11] ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup
On 04/15/2014 10:14 AM, Simon Horman wrote:
> On Tue, Apr 15, 2014 at 10:01:44AM +0300, Peter Ujfalusi wrote:
>> On 04/15/2014 12:59 AM, Alexandre Belloni wrote:
>>> Signed-off-by: Alexandre Belloni
>>> ---
>>> arch/arm/mach-omap2/board-omap3beagle.c | 10 ++
>>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
>>> b/arch/arm/mach-omap2/board-omap3beagle.c
>>> index f27e1ec90b5e..54c135a5b4f7 100644
>>> --- a/arch/arm/mach-omap2/board-omap3beagle.c
>>> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
>>> @@ -61,14 +61,8 @@
>>>
>>> static struct pwm_lookup pwm_lookup[] = {
>>> /* LEDB -> PMU_STAT */
>>> - {
>>> - .provider = "twl-pwmled",
>>> - .index = 1,
>>> - .dev_id = "leds_pwm",
>>> - .con_id = "beagleboard::pmu_stat",
>>> - .period = 7812500,
>>> - .polarity = PWM_POLARITY_NORMAL,
>>> - },
>>> + PWM_LOOKUP("twl-pwmled", 1, "leds_pwm", "beagleboard::pmu_stat",
>>> + 7812500, PWM_POLARITY_NORMAL),
>>
>> Why do you need to do this in two steps?
>> In patch 4 you removed the existing PWM_LOOKUP() and now you are adding it
>> back.
>> Would not be simpler if you just add the two new parameters in patch 4 (the
>> 812500, PWM_POLARITY_NORMAL)?
>
> Such an approach would apply an atomic change to both the infrastructure
> and the users.
Yes, I overlooked patch 6...
Just ignore my comment.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 07/11] ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup
On 04/15/2014 12:59 AM, Alexandre Belloni wrote:
> Signed-off-by: Alexandre Belloni
> ---
> arch/arm/mach-omap2/board-omap3beagle.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
> b/arch/arm/mach-omap2/board-omap3beagle.c
> index f27e1ec90b5e..54c135a5b4f7 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -61,14 +61,8 @@
>
> static struct pwm_lookup pwm_lookup[] = {
> /* LEDB -> PMU_STAT */
> - {
> - .provider = "twl-pwmled",
> - .index = 1,
> - .dev_id = "leds_pwm",
> - .con_id = "beagleboard::pmu_stat",
> - .period = 7812500,
> - .polarity = PWM_POLARITY_NORMAL,
> - },
> + PWM_LOOKUP("twl-pwmled", 1, "leds_pwm", "beagleboard::pmu_stat",
> +7812500, PWM_POLARITY_NORMAL),
Why do you need to do this in two steps?
In patch 4 you removed the existing PWM_LOOKUP() and now you are adding it back.
Would not be simpler if you just add the two new parameters in patch 4 (the
812500, PWM_POLARITY_NORMAL)?
> };
>
> static struct led_pwm pwm_leds[] = {
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On 04/14/2014 03:12 PM, Sekhar Nori wrote:
> On Monday 14 April 2014 05:26 PM, Peter Ujfalusi wrote:
>> Hi Vinod,
>>
>> On 04/11/2014 03:46 PM, Vinod Koul wrote:
>>> I think the number shouldn't be viewed in absolute terms. If we decide that
>>> (lets
>>> say) 0-7, then any controller should map 0 to lowest and 7 to highest.
>>>
>>> For your case you can do this and then intermediate numbers would be medium
>>> priority. Such a system might work well...
>>>
>>> Also how would a client driver know which priority to use? Would it come
>>> from
>>> DT?
>>
>> I think DT would be the best place.
>
> In the strict sense of what DT is supposed to represent, DT is not the
> best place for this. Priority is usecase driven rather that hardware
> description driven.
While this is true, the DMA priority - if supported by the DMA engine - is a
HW feature as well. If it is supported by the HW it can be used to tune and
partition the system for the anticipated load or purpose.
> So on a reasonably less loaded system, I am sure you
> could run audio even with a lower priority DMA queue.
Yes, you can. But as soon as you have other devices using the same priority
(with eDMA3 at least) and asks for a 'long' transfer it can ruin the audio.
During audio playback/capture you execute a long MMC read for example can
introduce a glitch.
> Moreover, IMHO, encoding it in DT now will make it an ABI. Without a
> wide variety of example use cases, I think it is too early to commit to
> an ABI.
True, but we need to start from somewhere?
I'm fine if we handle this right now as I did in this series (to put only
cyclic on high priority) for now. With some forward looking changes in the
implementation of course.
>> Not sure if we should set the range for this either. What I was thinking is
>> to
>> add an optional new property to be set by the client nodes, using DMA:
>>
>> mcasp0: mcasp@48038000 {
>> compatible = "ti,am33xx-mcasp-audio";
>> ...
>> dmas = <&edma 8>,
>> <&edma 9>;
>> dma-names = "tx", "rx";
>> dma-priorities = <2>, <2>;
>> };
>>
>> We could agree that lower number means lower priority, higher is - well -
>> higher priority.
>> If the dma-priority is missing we should assume lowest priority (0).
>> The highest priority depends on the platform. For eDMA3 in AM335x it is three
>> level. For designware controller you might have the range 0-8 as valid.
>>
>> The question is how to get this information into use?
>> We can take the priority number in the core when the dma channel is requested
>> and add field to "struct dma_chan" in order to store it and the DMA drivers
>> could have access to it.
>> In this way we only need to update the nodes which needs non default priority
>> for DMA.
>>
>> What do you think?
>
> If we are using dma_slave_config, I think it will be easiest to define
> two levels of priority (HIGH and LOW, as thats all we see a need for
> right now), and have the audio driver select the HIGH priority. If
> nothing is set, EDMA can default to LOW.
But the information on which channel should be high priority should be coming
form somewhere... We can wire it in the audio stack, but I don't think it is a
good idea to start with.
And if we have high/low priority we could as well have an integer to specify
the desired level.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 03/10] dmaengine: edma: Correct the handling of src/dst_maxburst == 0
When clients asks for maxburst = 0 it is basically the same case as if they were asking for maxburst = 1 since in both case ASYNC need to be used and the eDMA is expected to write/read one word per DMA request. Signed-off-by: Peter Ujfalusi Acked-by: Joel Fernandes --- drivers/dma/edma.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index cd04eb7b182e..2742867fd1e6 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -285,6 +285,10 @@ static int edma_config_pset(struct dma_chan *chan, struct edmacc_param *pset, int absync; acnt = dev_width; + + /* src/dst_maxburst == 0 is the same case as src/dst_maxburst == 1 */ + if (!burst) + burst = 1; /* * If the maxburst is equal to the fifo width, use * A-synced transfers. This allows for large contiguous -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 02/10] arm: common: edma: Save the number of event queues/TCs
For later use save the number of queues available for the CC. Signed-off-by: Peter Ujfalusi Acked-by: Joel Fernandes --- arch/arm/common/edma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 41bca32409fc..999266bf69b9 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1768,6 +1768,9 @@ static int edma_probe(struct platform_device *pdev) map_queue_tc(j, queue_tc_mapping[i][0], queue_tc_mapping[i][1]); + /* Save the number of TCs */ + edma_cc[j]->num_tc = i; + /* Event queue priority mapping */ for (i = 0; queue_priority_mapping[i][0] != -1; i++) assign_priority_to_queue(j, -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 01/10] platform_data: edma: Be precise with the paRAM struct
The edmacc_param struct should follow the layout of the paRAM area in the
HW. Be explicit on the size of the fields (u32) and also mark the struct
as packed to avoid any padding on non 32bit architectures.
Signed-off-by: Peter Ujfalusi
Acked-by: Joel Fernandes
---
include/linux/platform_data/edma.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index f50821cb64be..923f8a3e4ce0 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -43,15 +43,15 @@
/* PaRAM slots are laid out like this */
struct edmacc_param {
- unsigned int opt;
- unsigned int src;
- unsigned int a_b_cnt;
- unsigned int dst;
- unsigned int src_dst_bidx;
- unsigned int link_bcntrld;
- unsigned int src_dst_cidx;
- unsigned int ccnt;
-};
+ u32 opt;
+ u32 src;
+ u32 a_b_cnt;
+ u32 dst;
+ u32 src_dst_bidx;
+ u32 link_bcntrld;
+ u32 src_dst_cidx;
+ u32 ccnt;
+} __packed;
/* fields in edmacc_param.opt */
#define SAMBIT(0)
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
Hi Vinod,
On 04/11/2014 03:46 PM, Vinod Koul wrote:
> I think the number shouldn't be viewed in absolute terms. If we decide that
> (lets
> say) 0-7, then any controller should map 0 to lowest and 7 to highest.
>
> For your case you can do this and then intermediate numbers would be medium
> priority. Such a system might work well...
>
> Also how would a client driver know which priority to use? Would it come from
> DT?
I think DT would be the best place.
Not sure if we should set the range for this either. What I was thinking is to
add an optional new property to be set by the client nodes, using DMA:
mcasp0: mcasp@48038000 {
compatible = "ti,am33xx-mcasp-audio";
...
dmas = <&edma 8>,
<&edma 9>;
dma-names = "tx", "rx";
dma-priorities = <2>, <2>;
};
We could agree that lower number means lower priority, higher is - well -
higher priority.
If the dma-priority is missing we should assume lowest priority (0).
The highest priority depends on the platform. For eDMA3 in AM335x it is three
level. For designware controller you might have the range 0-8 as valid.
The question is how to get this information into use?
We can take the priority number in the core when the dma channel is requested
and add field to "struct dma_chan" in order to store it and the DMA drivers
could have access to it.
In this way we only need to update the nodes which needs non default priority
for DMA.
What do you think?
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 04/10] dmaengine: edma: Add support for DMA_PAUSE/RESUME operation
Pause/Resume can be used by the audio stack when the stream is paused/resumed
The edma platform code has support for this and the legacy audio stack used
this.
Signed-off-by: Peter Ujfalusi
Acked-by: Joel Fernandes
---
drivers/dma/edma.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2742867fd1e6..7891378a03f0 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -240,6 +240,26 @@ static int edma_slave_config(struct edma_chan *echan,
return 0;
}
+static int edma_dma_pause(struct edma_chan *echan)
+{
+ /* Pause/Resume only allowed with cyclic mode */
+ if (!echan->edesc->cyclic)
+ return -EINVAL;
+
+ edma_pause(echan->ch_num);
+ return 0;
+}
+
+static int edma_dma_resume(struct edma_chan *echan)
+{
+ /* Pause/Resume only allowed with cyclic mode */
+ if (!echan->edesc->cyclic)
+ return -EINVAL;
+
+ edma_resume(echan->ch_num);
+ return 0;
+}
+
static int edma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
unsigned long arg)
{
@@ -255,6 +275,14 @@ static int edma_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd,
config = (struct dma_slave_config *)arg;
ret = edma_slave_config(echan, config);
break;
+ case DMA_PAUSE:
+ ret = edma_dma_pause(echan);
+ break;
+
+ case DMA_RESUME:
+ ret = edma_dma_resume(echan);
+ break;
+
default:
ret = -ENOSYS;
}
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 05/10] dmaengine: edma: Set DMA_CYCLIC capability flag
Indicate that the edma dmaengine driver has support for cyclic mode. Signed-off-by: Peter Ujfalusi Acked-by: Joel Fernandes --- arch/arm/common/edma.c | 1 + drivers/dma/edma.c | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 999266bf69b9..0b37f7734d0f 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1574,6 +1574,7 @@ static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev, return ERR_PTR(ret); dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); + dma_cap_set(DMA_CYCLIC, edma_filter_info.dma_cap); of_dma_controller_register(dev->of_node, of_dma_simple_xlate, &edma_filter_info); diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index 7891378a03f0..1dd9e8806975 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -891,6 +891,7 @@ static int edma_probe(struct platform_device *pdev) dma_cap_zero(ecc->dma_slave.cap_mask); dma_cap_set(DMA_SLAVE, ecc->dma_slave.cap_mask); + dma_cap_set(DMA_CYCLIC, ecc->dma_slave.cap_mask); edma_dma_init(ecc, &ecc->dma_slave, &pdev->dev); -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 06/10] dmaengine: edma: Implement device_slave_caps callback
With the callback implemented omap-dma can provide information to client
drivers regarding to supported address widths, directions, residue
granularity, etc.
Signed-off-by: Peter Ujfalusi
Acked-by: Joel Fernandes
---
drivers/dma/edma.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 1dd9e8806975..2f58c04cbcb1 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -852,6 +852,23 @@ static void __init edma_chan_init(struct edma_cc *ecc,
}
}
+#define EDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static int edma_dma_device_slave_caps(struct dma_chan *dchan,
+ struct dma_slave_caps *caps)
+{
+ caps->src_addr_widths = EDMA_DMA_BUSWIDTHS;
+ caps->dstn_addr_widths = EDMA_DMA_BUSWIDTHS;
+ caps->directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+ caps->cmd_pause = true;
+ caps->cmd_terminate = true;
+ caps->residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
+
+ return 0;
+}
+
static void edma_dma_init(struct edma_cc *ecc, struct dma_device *dma,
struct device *dev)
{
@@ -862,6 +879,7 @@ static void edma_dma_init(struct edma_cc *ecc, struct
dma_device *dma,
dma->device_issue_pending = edma_issue_pending;
dma->device_tx_status = edma_tx_status;
dma->device_control = edma_control;
+ dma->device_slave_caps = edma_dma_device_slave_caps;
dma->dev = dev;
INIT_LIST_HEAD(&dma->channels);
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 07/10] dmaengine: edma: Reduce debug print verbosity for non verbose debugging
Do not print the paRAM information when verbose debugging is not asked and
also reduce the number of lines printed in edma_prep_dma_cyclic()
Signed-off-by: Peter Ujfalusi
Acked-by: Joel Fernandes
---
drivers/dma/edma.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2f58c04cbcb1..6d9edc47150d 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -141,7 +141,7 @@ static void edma_execute(struct edma_chan *echan)
for (i = 0; i < nslots; i++) {
j = i + edesc->processed;
edma_write_slot(echan->slot[i], &edesc->pset[j]);
- dev_dbg(echan->vchan.chan.device->dev,
+ dev_vdbg(echan->vchan.chan.device->dev,
"\n pset[%d]:\n"
" chnum\t%d\n"
" slot\t%d\n"
@@ -560,9 +560,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc->cyclic = 1;
edesc->pset_nr = nslots;
- dev_dbg(dev, "%s: nslots=%d\n", __func__, nslots);
- dev_dbg(dev, "%s: period_len=%d\n", __func__, period_len);
- dev_dbg(dev, "%s: buf_len=%d\n", __func__, buf_len);
+ dev_dbg(dev, "%s: channel=%d nslots=%d period_len=%zu buf_len=%zu\n",
+ __func__, echan->ch_num, nslots, period_len, buf_len);
for (i = 0; i < nslots; i++) {
/* Allocate a PaRAM slot, if needed */
@@ -596,8 +595,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
else
src_addr += period_len;
- dev_dbg(dev, "%s: Configure period %d of buf:\n", __func__, i);
- dev_dbg(dev,
+ dev_vdbg(dev, "%s: Configure period %d of buf:\n", __func__, i);
+ dev_vdbg(dev,
"\n pset[%d]:\n"
" chnum\t%d\n"
" slot\t%d\n"
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 08/10] dmaengine: edma: Prefix debug prints where the text were identical in prep callbacks
prep_slave_sg and prep_dma_cyclic callbacks have mostly same failure cases
with the same texts printed in case we hit them. It helps when debugging if
we know exactly which callback generated the errors.
At the same time change the debug level for descriptor allocation failure
from dbg to err since all other error cases are dev_err and this failure is
similarly fatal as the other ones.
Signed-off-by: Peter Ujfalusi
Acked-by: Joel Fernandes
---
drivers/dma/edma.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 6d9edc47150d..bc8175c92e0c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -436,14 +436,14 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
}
if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
- dev_err(dev, "Undefined slave buswidth\n");
+ dev_err(dev, "%s: Undefined slave buswidth\n", __func__);
return NULL;
}
edesc = kzalloc(sizeof(*edesc) + sg_len *
sizeof(edesc->pset[0]), GFP_ATOMIC);
if (!edesc) {
- dev_dbg(dev, "Failed to allocate a descriptor\n");
+ dev_err(dev, "%s: Failed to allocate a descriptor\n", __func__);
return NULL;
}
@@ -459,7 +459,8 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
EDMA_SLOT_ANY);
if (echan->slot[i] < 0) {
kfree(edesc);
- dev_err(dev, "Failed to allocate slot\n");
+ dev_err(dev, "%s: Failed to allocate slot\n",
+ __func__);
return NULL;
}
}
@@ -528,7 +529,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
}
if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
- dev_err(dev, "Undefined slave buswidth\n");
+ dev_err(dev, "%s: Undefined slave buswidth\n", __func__);
return NULL;
}
@@ -553,7 +554,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc = kzalloc(sizeof(*edesc) + nslots *
sizeof(edesc->pset[0]), GFP_ATOMIC);
if (!edesc) {
- dev_dbg(dev, "Failed to allocate a descriptor\n");
+ dev_err(dev, "%s: Failed to allocate a descriptor\n", __func__);
return NULL;
}
@@ -571,7 +572,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
EDMA_SLOT_ANY);
if (echan->slot[i] < 0) {
kfree(edesc);
- dev_err(dev, "Failed to allocate slot\n");
+ dev_err(dev, "%s: Failed to allocate slot\n",
+ __func__);
return NULL;
}
}
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 09/10] dmaengine: edma: Add channel number to debug prints
It helps to identify issues if we have some information regarding to the
channel which the event is associated.
Signed-off-by: Peter Ujfalusi
Acked-by: Joel Fernandes
---
drivers/dma/edma.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index bc8175c92e0c..4aa5eb005b5c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -185,7 +185,8 @@ static void edma_execute(struct edma_chan *echan)
edma_resume(echan->ch_num);
if (edesc->processed <= MAX_NR_SG) {
- dev_dbg(dev, "first transfer starting %d\n", echan->ch_num);
+ dev_dbg(dev, "first transfer starting on channel %d\n",
+ echan->ch_num);
edma_start(echan->ch_num);
}
@@ -195,7 +196,7 @@ static void edma_execute(struct edma_chan *echan)
* MAX_NR_SG
*/
if (echan->missed) {
- dev_dbg(dev, "missed event in execute detected\n");
+ dev_dbg(dev, "missed event on channel %d\n", echan->ch_num);
edma_clean_channel(echan->ch_num);
edma_stop(echan->ch_num);
edma_start(echan->ch_num);
@@ -735,7 +736,7 @@ static int edma_alloc_chan_resources(struct dma_chan *chan)
echan->alloced = true;
echan->slot[0] = echan->ch_num;
- dev_dbg(dev, "allocated channel for %u:%u\n",
+ dev_dbg(dev, "allocated channel %d for %u:%u\n", echan->ch_num,
EDMA_CTLR(echan->ch_num), EDMA_CHAN_SLOT(echan->ch_num));
return 0;
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 10/10] dmaengine: edma: Print the direction value as well when it is not supported
In case of not supported direction it is better to print the direction also.
It is unlikely, but in such an event it helps with the debugging.
Signed-off-by: Peter Ujfalusi
Acked-by: Joel Fernandes
---
drivers/dma/edma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 4aa5eb005b5c..91849aa50de1 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -432,7 +432,7 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
dev_width = echan->cfg.dst_addr_width;
burst = echan->cfg.dst_maxburst;
} else {
- dev_err(dev, "%s: bad direction?\n", __func__);
+ dev_err(dev, "%s: bad direction: %d\n", __func__, direction);
return NULL;
}
@@ -525,7 +525,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
dev_width = echan->cfg.dst_addr_width;
burst = echan->cfg.dst_maxburst;
} else {
- dev_err(dev, "%s: bad direction?\n", __func__);
+ dev_err(dev, "%s: bad direction: %d\n", __func__, direction);
return NULL;
}
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 00/10] dma: edma: Fixes for cyclic (audio) operation
Hi, Changes since v2: - Dropped patch 10 from v2 (simplify direction configuration...) - Dropped the channel priority related patches since we are going to go via different route for configuring the priority. - Added ACK from Joel for the patches since they are not changed since v2 Changes since v1: - ASoC patches removed - Comments from Andriy Shevchenko addressed - patch added to fix cases when src/dst_maxburst is set to 0 The series contains now only: Support for DMA pause/resume in cyclic mode device_slave_caps callback and DMA_CYCLIC flag correction. While debugging the edma to get things sorted out I noticed that the debug was too verbose and the important information was hidden even when the we did not asked for verbose dmaengine debug. I have included some debug cleanups for the edma dmaengine driver also. Regards, Peter --- Peter Ujfalusi (10): platform_data: edma: Be precise with the paRAM struct arm: common: edma: Save the number of event queues/TCs dmaengine: edma: Correct the handling of src/dst_maxburst == 0 dmaengine: edma: Add support for DMA_PAUSE/RESUME operation dmaengine: edma: Set DMA_CYCLIC capability flag dmaengine: edma: Implement device_slave_caps callback dmaengine: edma: Reduce debug print verbosity for non verbose debugging dmaengine: edma: Prefix debug prints where the text were identical in prep callbacks dmaengine: edma: Add channel number to debug prints dmaengine: edma: Print the direction value as well when it is not supported arch/arm/common/edma.c | 4 ++ drivers/dma/edma.c | 87 ++ include/linux/platform_data/edma.h | 18 3 files changed, 83 insertions(+), 26 deletions(-) -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On 04/11/2014 02:31 PM, Vinod Koul wrote: >> I would say that it is channel based config. I don't see the reason why would >> one mix different priorities on a configured channel between descriptors. >> >>> If not then we can add this in dma_slave_config ? >> >> So adding to the struct for example: >> bool high_priority; > > In designware controller, we can have channel priorties from 0 to 7 which > IIRC 7 > being highest. So bool wont work. unsigned int/u8 would be good. I see. But from a generic code what number should one pass if we want to get the highest priority? With eDMA3 we essentially have three levels (see later) so if we receive 7 as priority what shall we do? Just treat as highest? But if we receive 4, which is somewhere in the middle for designware it is still means highest for us. I see this too small step partitioning in common code a bit problematic when it comes to how to interpret the 'magic numbers'. Also how all the driver in the system will decide the priority number? I'm sure they will pick something conveniently average for themselves and I imagine audio would try to pick something which is bigger than the numbers others have taken... > How about your controller, is it binary? We also have priority from 0 to 7, 0 being the highest priority. We have 3 Transfer Controllers/Event Queues and we can set the priority for the TC/EQ and assign the given channel to the desired TC/EQ. So in reality we have 3 priorities to choose from in my view since we only have 3 TC/EQ in eDMA3 (of AM335x/AM447x) on other SoCs we can have different number of TC/EQ. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
Hi Vinod, On 04/11/2014 12:42 PM, Vinod Koul wrote: > On Fri, Apr 11, 2014 at 12:38:00PM +0300, Peter Ujfalusi wrote: >> On 04/11/2014 11:56 AM, Sekhar Nori wrote: >>> On Friday 11 April 2014 02:20 PM, Peter Ujfalusi wrote: >>>> On 04/11/2014 11:17 AM, Sekhar Nori wrote: >>>>> On Tuesday 01 April 2014 06:36 PM, Peter Ujfalusi wrote: >>>>>> Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high >>>>>> priority channels, like audio. >>>>>> >>>>>> Signed-off-by: Peter Ujfalusi >>>>> >>>>> Acked-by: Sekhar Nori >>>>> >>>>>> --- >>>>>> arch/arm/common/edma.c | 3 ++- >>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c >>>>>> index 86a8b263278f..19520e2519d9 100644 >>>>>> --- a/arch/arm/common/edma.c >>>>>> +++ b/arch/arm/common/edma.c >>>>>> @@ -1546,7 +1546,8 @@ static int edma_of_parse_dt(struct device *dev, >>>>>> >>>>>> pdata->queue_priority_mapping = queue_priority_map; >>>>>> >>>>>> -pdata->default_queue = 0; >>>>>> +/* select queue 1 as default */ >>>>> >>>>> It will be nice to expand the comment with explanation of why this is >>>>> being chosen as default (lower priority queue by default for typical >>>>> bulk data transfer). >>>> >>>> Yes, extended comment is a good idea. >>>> >>>> For the next version I think I'm going to change the code around default >>>> TC/Queue and the non default queue selection, mostly based on Joel's >>>> comment: >>>> >>>> EVENTQ_1 as default queue. >>>> Set the EVENTQ_1 priority to 7 >>>> EVENTQ_0 priority is going to stay 0 and EVENTQ_2 as 2 >>>> >>>> Add new member to struct edma, like high_pri_queue. >>>> When we set the queue priorities in edma_probe() we look for the highest >>>> priority queue and save the number in high_pri_queue. >>>> >>>> I will rename the edma_request_non_default_queue() to >>>> edma_request_high_pri_queue() and it will assign the channel to the high >>>> priority queue. >>>> >>>> I think this way it is going to be more explicit and IMHO a bit more safer >>>> in >>>> a sense the we are going to get high priority when we ask for it. >>> >>> Sounds much better. I had posted some ideas about adding support for >>> channel priority in the core code but we can leave that for Vinod and >>> Dan to say if they really see a need for that. > Is it part of this series? No, it is not. The original series tackled the DMA queue selection within the edma driver stack. It was selecting high priority channel for cyclic (audio) use only, all other DMA channels were executed on a lower priority queue. >> If we do it via the dmaengine core I think it would be better to have a new >> flag to be passed to dmaengine_prep_dma_*(). >> We could have for example: >> DMA_PREP_HIGH_PRI as flag to indicate that we need high priority DMA if it is >> possible. >> We can watch for this flag in the edma driver and act accordingly. >> ALSA's dmaengine_pcm_prepare_and_submit() could set this flag unconditionally >> since audio should be treated in this way if the DMA IP can do this. > > Will the priority be different for each descriptor or would be based on > channel > usage. I would say that it is channel based config. I don't see the reason why would one mix different priorities on a configured channel between descriptors. > If not then we can add this in dma_slave_config ? So adding to the struct for example: bool high_priority; I'm not sure if it helps if we have let's say three priority level like, low, normal and high. I don't think that any client would ask for low priority instead using the normal priority. > I can forsee its usage on slave controllers, so yes its useful :) True I'm sure it is going to be used as soon as it is available if the HW supports priorities. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On 04/11/2014 11:56 AM, Sekhar Nori wrote: > On Friday 11 April 2014 02:20 PM, Peter Ujfalusi wrote: >> On 04/11/2014 11:17 AM, Sekhar Nori wrote: >>> On Tuesday 01 April 2014 06:36 PM, Peter Ujfalusi wrote: >>>> Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high >>>> priority channels, like audio. >>>> >>>> Signed-off-by: Peter Ujfalusi >>> >>> Acked-by: Sekhar Nori >>> >>>> --- >>>> arch/arm/common/edma.c | 3 ++- >>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c >>>> index 86a8b263278f..19520e2519d9 100644 >>>> --- a/arch/arm/common/edma.c >>>> +++ b/arch/arm/common/edma.c >>>> @@ -1546,7 +1546,8 @@ static int edma_of_parse_dt(struct device *dev, >>>> >>>>pdata->queue_priority_mapping = queue_priority_map; >>>> >>>> - pdata->default_queue = 0; >>>> + /* select queue 1 as default */ >>> >>> It will be nice to expand the comment with explanation of why this is >>> being chosen as default (lower priority queue by default for typical >>> bulk data transfer). >> >> Yes, extended comment is a good idea. >> >> For the next version I think I'm going to change the code around default >> TC/Queue and the non default queue selection, mostly based on Joel's comment: >> >> EVENTQ_1 as default queue. >> Set the EVENTQ_1 priority to 7 >> EVENTQ_0 priority is going to stay 0 and EVENTQ_2 as 2 >> >> Add new member to struct edma, like high_pri_queue. >> When we set the queue priorities in edma_probe() we look for the highest >> priority queue and save the number in high_pri_queue. >> >> I will rename the edma_request_non_default_queue() to >> edma_request_high_pri_queue() and it will assign the channel to the high >> priority queue. >> >> I think this way it is going to be more explicit and IMHO a bit more safer in >> a sense the we are going to get high priority when we ask for it. > > Sounds much better. I had posted some ideas about adding support for > channel priority in the core code but we can leave that for Vinod and > Dan to say if they really see a need for that. If we do it via the dmaengine core I think it would be better to have a new flag to be passed to dmaengine_prep_dma_*(). We could have for example: DMA_PREP_HIGH_PRI as flag to indicate that we need high priority DMA if it is possible. We can watch for this flag in the edma driver and act accordingly. ALSA's dmaengine_pcm_prepare_and_submit() could set this flag unconditionally since audio should be treated in this way if the DMA IP can do this. Not sure what to do with eDMA's 8 priority level. With that we could have high priority; low priority; low, but not the lowest priority; about in the middle priority; etc. We could have also new callback in the dma_device struct with needed wrappers to set priority level, but where to draw the range? High, Mid and Low? Range of 0 - 10? -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On 04/11/2014 11:17 AM, Sekhar Nori wrote: > On Tuesday 01 April 2014 06:36 PM, Peter Ujfalusi wrote: >> Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high >> priority channels, like audio. >> >> Signed-off-by: Peter Ujfalusi > > Acked-by: Sekhar Nori > >> --- >> arch/arm/common/edma.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c >> index 86a8b263278f..19520e2519d9 100644 >> --- a/arch/arm/common/edma.c >> +++ b/arch/arm/common/edma.c >> @@ -1546,7 +1546,8 @@ static int edma_of_parse_dt(struct device *dev, >> >> pdata->queue_priority_mapping = queue_priority_map; >> >> -pdata->default_queue = 0; >> +/* select queue 1 as default */ > > It will be nice to expand the comment with explanation of why this is > being chosen as default (lower priority queue by default for typical > bulk data transfer). Yes, extended comment is a good idea. For the next version I think I'm going to change the code around default TC/Queue and the non default queue selection, mostly based on Joel's comment: EVENTQ_1 as default queue. Set the EVENTQ_1 priority to 7 EVENTQ_0 priority is going to stay 0 and EVENTQ_2 as 2 Add new member to struct edma, like high_pri_queue. When we set the queue priorities in edma_probe() we look for the highest priority queue and save the number in high_pri_queue. I will rename the edma_request_non_default_queue() to edma_request_high_pri_queue() and it will assign the channel to the high priority queue. I think this way it is going to be more explicit and IMHO a bit more safer in a sense the we are going to get high priority when we ask for it. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/14] dma: edma: Simplify direction configuration in edma_config_pset()
On 04/11/2014 01:40 AM, Joel Fernandes wrote:
> On 04/01/2014 08:06 AM, Peter Ujfalusi wrote:
>> We only support DEV_TO_MEM or MEM_TO_DEV directions with edma driver and the
>> check for the direction has been already done in the function calling
>> edma_config_pset().
>> The error reporting is redundant and also the "else if ()" can be removed.
>>
>
> NAK. Please don't do this. I have been working on MEM_TO_MEM support as
> well so leave it as it is for future.
Sure. It is still valid to say that the error else {} will never going to
happen since you have the same check in the calling function and they already
filtered the non implemented direction.
I'll leave this out from v3.
--
Péter
>
> Thanks,
> -Joel
>
>> Signed-off-by: Peter Ujfalusi
>> ---
>> drivers/dma/edma.c | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>> index 855766672aa9..d954099650ae 100644
>> --- a/drivers/dma/edma.c
>> +++ b/drivers/dma/edma.c
>> @@ -372,14 +372,12 @@ static int edma_config_pset(struct dma_chan *chan,
>> struct edmacc_param *pset,
>> src_cidx = cidx;
>> dst_bidx = 0;
>> dst_cidx = 0;
>> -} else if (direction == DMA_DEV_TO_MEM) {
>> +} else {
>> +/* DMA_DEV_TO_MEM */
>> src_bidx = 0;
>> src_cidx = 0;
>> dst_bidx = acnt;
>> dst_cidx = cidx;
>> -} else {
>> -dev_err(dev, "%s: direction not implemented yet\n", __func__);
>> -return -EINVAL;
>> }
>>
>> pset->opt = EDMA_TCC(EDMA_CHAN_SLOT(echan->ch_num));
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
On 04/03/2014 04:49 PM, Nishanth Menon wrote: > On 04/03/2014 05:52 AM, Peter Ujfalusi wrote: > [...] >> .../devicetree/bindings/clock/clk-palmas.txt | 35 +++ >> drivers/clk/Kconfig| 7 + >> drivers/clk/Makefile | 1 + >> drivers/clk/clk-palmas.c | 307 >> + >> include/dt-bindings/mfd/palmas.h | 18 ++ >> 5 files changed, 368 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas.txt >> create mode 100644 drivers/clk/clk-palmas.c >> create mode 100644 include/dt-bindings/mfd/palmas.h > > > Only complaint i have is based on : > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a9330010bea5982a5c6593824bc036bf62d67b7 Oh, I see. I'll wait for comments and resend as a series. Probably it is going to be better if I rename the documentation file as well to bindings/clock/ti,palmas-clk.txt I think having two separate document for the two clock is overkill. > you may want to split the new binding off to a separate patch. > Otherwise, personally, I think it is an good evolution, thanks for > doing it. > > -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
Palmas class of devices have either twl 32K clock outputs:
CLK32K_KG and CLK32K_KGAUDIO
or only one:
CLK32K_KG (TPS659039 for example)
Use separate compatible flags for the two 32K clock.
A system which needs or have only one of the 32k clock from
Palmas will need to add node(s) for each clock as separate section
in the dts file.
The two compatible property is:
"ti,palmas-clk32kg" for clk32kg clock
"ti,palmas-clk32kgaudio" for clk32kgaudio clock
Apart from the register control of the clocks - which is done via
the clock API there is a posibility to enable the external sleep
control.
See the documentation for more details.
Signed-off-by: Peter Ujfalusi
---
Hi,
Part of the driver is based on the v4 of palmas clock driver from
Laxman Dewangan, which can be found here:
https://lkml.org/lkml/2013/10/9/146
Since no updates followed after the comments and patches I have squashed my
updates to rewrite the original driver to be able to support more devices from
the Palmas family.
Regards,
Peter
.../devicetree/bindings/clock/clk-palmas.txt | 35 +++
drivers/clk/Kconfig| 7 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-palmas.c | 307 +
include/dt-bindings/mfd/palmas.h | 18 ++
5 files changed, 368 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas.txt
create mode 100644 drivers/clk/clk-palmas.c
create mode 100644 include/dt-bindings/mfd/palmas.h
diff --git a/Documentation/devicetree/bindings/clock/clk-palmas.txt
b/Documentation/devicetree/bindings/clock/clk-palmas.txt
new file mode 100644
index ..4208886d834a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-palmas.txt
@@ -0,0 +1,35 @@
+* Palmas 32KHz clocks *
+
+Palmas device has two clock output pins for 32KHz, KG and KG_AUDIO.
+
+This binding uses the common clock binding ./clock-bindings.txt.
+
+Required properties:
+- compatible : "ti,palmas-clk32kg" for clk32kg clock
+ "ti,palmas-clk32kgaudio" for clk32kgaudio clock
+- #clock-cells : shall be set to 0.
+
+Optional property:
+- ti,external-sleep-control: The external enable input pins controlled the
+ enable/disable of clocks. The external enable input pins ENABLE1,
+ ENABLE2 and NSLEEP. The valid values for the external pins are:
+ PALMAS_EXT_CONTROL_PIN_ENABLE1 for ENABLE1 pin
+ PALMAS_EXT_CONTROL_PIN_ENABLE2 for ENABLE2 pin
+ PALMAS_EXT_CONTROL_PIN_NSLEEP for NSLEEP pin
+ Option 0 or missing this property means the clock is enabled/disabled
+ via register access and these pins do not have any control.
+ The macros of external control pins for DTS is defined at
+ dt-bindings/mfd/palmas.h
+
+Example:
+ #include
+ ...
+ palmas: tps65913@58 {
+ ...
+ clk32kg: palmas_clk32k@0 {
+ compatible = "ti,palmas-clk32kg";
+ #clock-cells = <0>;
+ ti,external-sleep-control =
;
+ };
+ ...
+ };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 6f56d3a4f010..a070b77a1e17 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -109,6 +109,13 @@ config COMMON_CLK_KEYSTONE
Supports clock drivers for Keystone based SOCs. These SOCs have local
a power sleep control module that gate the clock to the IPs and PLLs.
+config COMMON_CLK_PALMAS
+ tristate "Clock driver for TI Palmas devices"
+ depends on MFD_PALMAS
+ ---help---
+ This driver supports TI Palmas devices 32KHz output KG and KG_AUDIO
+ using common clock framework.
+
source "drivers/clk/qcom/Kconfig"
endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 5f8a28735c96..d67214debc12 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
+obj-$(CONFIG_COMMON_CLK_PALMAS)+= clk-palmas.o
obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
diff --git a/drivers/clk/clk-palmas.c b/drivers/clk/clk-palmas.c
new file mode 100644
index ..e2b7d3cade26
--- /dev/null
+++ b/drivers/clk/clk-palmas.c
@@ -0,0 +1,307 @@
+/*
+ * Clock driver for Palmas device.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation.
+ * Copyright (c) 2013-2014 Texas Instruments, Inc.
+ *
+ * Author: Laxman Dewangan
+ * Peter Ujfalusi
+ *
+ * This program is free software; you can redistribute
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
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
>
>>
>> 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)
>>
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: dts: dra7xx-clocks: Correct name for atl clkin3 clock
To allign the name with the other atl clock names:
atlclkin3_ck -> atl_clkin3_ck
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 22 +++---
drivers/clk/ti/clk-7xx.c | 2 +-
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index cfb8fc753f50..30160348934c 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -26,7 +26,7 @@
clock-frequency = <0>;
};
- atlclkin3_ck: atlclkin3_ck {
+ atl_clkin3_ck: atl_clkin3_ck {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <0>;
@@ -730,7 +730,7 @@
mcasp1_ahclkr_mux: mcasp1_ahclkr_mux {
#clock-cells = <0>;
compatible = "ti,mux-clock";
- clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+ clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atl_clkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
ti,bit-shift = <28>;
reg = <0x0550>;
};
@@ -738,7 +738,7 @@
mcasp1_ahclkx_mux: mcasp1_ahclkx_mux {
#clock-cells = <0>;
compatible = "ti,mux-clock";
- clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+ clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atl_clkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
ti,bit-shift = <24>;
reg = <0x0550>;
};
@@ -1631,7 +1631,7 @@
mcasp2_ahclkr_mux: mcasp2_ahclkr_mux {
#clock-cells = <0>;
compatible = "ti,mux-clock";
- clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+ clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atl_clkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
ti,bit-shift = <28>;
reg = <0x1860>;
};
@@ -1639,7 +1639,7 @@
mcasp2_ahclkx_mux: mcasp2_ahclkx_mux {
#clock-cells = <0>;
compatible = "ti,mux-clock";
- clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
+ clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>,
<&atl_clkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>,
<&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>,
<&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
[PATCH 2/3] clk: Driver for DRA7 ATL (Audio Tracking Logic)
Audio Tracking Logic is designed to be used by HD Radio
applications to synchronize the audio output clocks to the
baseband clock. ATL can be also used to track errors between
two reference clocks (BWS, AWS) and generate a modulated
clock output which averages to some desired frequency.
The ATL IP in DRA7 contains 4 ATL instences.
To be able to integrate the ATL provided clocks to the clock tree we need
two types of DT binding:
- DT clock nodes to represent the ATL clocks towards the CCF
- binding for the ATL IP itself which is going to handle the hw
configuration
The reason for this type of setup is that ATL itself is a separate device
in the SoC, it has it's own address space and clock domain. Other IPs can
use the ATL generated clock as their functional clock (McASPs for example)
and external components like audio codecs can also use the very same clock
as their MCLK.
With setup pm_runtime can handle the ATL clock on demand of it's use and
all the IP which needs ATL clock can be sure that it is enabled for them.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/clock/ti/dra7-atl.txt | 97 +++
drivers/clk/ti/Makefile| 3 +-
drivers/clk/ti/clk-dra7-atl.c | 313 +
include/dt-bindings/clk/ti-dra7-atl.h | 40 +++
4 files changed, 452 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti/dra7-atl.txt
create mode 100644 drivers/clk/ti/clk-dra7-atl.c
create mode 100644 include/dt-bindings/clk/ti-dra7-atl.h
diff --git a/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt
b/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt
new file mode 100644
index ..c90e63c443ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt
@@ -0,0 +1,97 @@
+Device Tree Clock bindings for ATL (Audio Tracking Logic) of DRA7 SoC.
+
+The ATL IP is used to generate clock to be used to synchronize baseband and
+audio codec. A single ATL IP provides four ATL clock instances sharing the same
+functional clock but can be configured to provide different clocks.
+ATL can maintain a clock averages to some desired frequency based on the
bws/aws
+signals - can compensate the drift between the two ws signal.
+
+In order to provide the support for ATL and it's output clocks (which can be
used
+internally within the SoC or external components) two sets of bindings is
needed:
+
+Clock tree binding:
+This binding uses the common clock binding[1].
+To be able to integrate the ATL clocks with DT clock tree.
+Provides ccf level representation of the ATL clocks to be used by drivers.
+Since the clock instances are part of a single IP this binding is used as a
node
+for the DT clock tree, the IP driver is needed to handle the actual
configuration
+of the IP.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "ti,dra7-atl-clock"
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles to functional clock of ATL
+
+Binding for the IP driver:
+This binding is used to configure the IP driver which is going to handle the
+configuration of the IP for the ATL clock instances.
+
+Required properties:
+- compatible : shall be "ti,dra7-atl"
+- reg : base address for the ATL IP
+- ti,provided-clocks : List of phandles to the clocks associated with the ATL
+- clocks : link phandles to functional clock of ATL
+- clock-names : Shall be set to "fck"
+- ti,hwmods : Shall be set to "atl"
+
+Optional properties:
+Configuration of ATL instances:
+- atl{0/1/2/3} {
+ - bws : Baseband word select signal selection
+ - aws : Audio word select signal selection
+};
+
+For valid word select signals, see the dt-bindings/clk/ti-dra7-atl.h include
+file.
+
+Examples:
+/* clock bindings for atl provided clocks */
+atl_clkin0_ck: atl_clkin0_ck {
+ #clock-cells = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
+};
+
+atl_clkin1_ck: atl_clkin1_ck {
+ #clock-cells = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
+};
+
+atl_clkin2_ck: atl_clkin2_ck {
+ #clock-cells = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
+};
+
+atl_clkin3_ck: atl_clkin3_ck {
+ #clock-cells = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
+};
+
+/* binding for the IP */
+atl: atl@4843c000 {
+ compatible = "ti,dra7-atl";
+ reg = <0x4843c000 0x3ff>;
+ ti,hwmods = "atl";
+ ti,provided-clocks = <&atl_clkin0_ck>, <&atl_clkin1_ck>,
+ <&atl_clkin2_ck>, <&atl_clkin3_ck>;
+ clocks
[PATCH 3/3] ARM: DTS: dra7/dra7xx-clocks: ATL related changes
Modify the clock nodes for the ATL clocks to use the ATL clock driver to
handle them.
Add the ATL device node at the same time for DRA7.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/dra7.dtsi | 11 +++
arch/arm/boot/dts/dra7xx-clocks.dtsi | 16
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1c0f8e1893ae..5e360e939aa7 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -789,6 +789,17 @@
dma-names = "tx0", "rx0";
status = "disabled";
};
+
+ atl: atl@4843c000 {
+ compatible = "ti,dra7-atl";
+ reg = <0x4843c000 0x3ff>;
+ ti,hwmods = "atl";
+ ti,provided-clocks = <&atl_clkin0_ck>, <&atl_clkin1_ck>,
+<&atl_clkin2_ck>, <&atl_clkin3_ck>;
+ clocks = <&atl_gfclk_mux>;
+ clock-names = "fck";
+ status = "disabled";
+ };
};
};
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 30160348934c..789e92cd5595 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -10,26 +10,26 @@
&cm_core_aon_clocks {
atl_clkin0_ck: atl_clkin0_ck {
#clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
};
atl_clkin1_ck: atl_clkin1_ck {
#clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
};
atl_clkin2_ck: atl_clkin2_ck {
#clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
};
atl_clkin3_ck: atl_clkin3_ck {
#clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <0>;
+ compatible = "ti,dra7-atl-clock";
+ clocks = <&atl_gfclk_mux>;
};
hdmi_clkin_ck: hdmi_clkin_ck {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] clk: Add clock driver for DRA7 ATL (Audio Tracking Logic)
Hi, Audio Tracking Logic is designed to be used by HD Radio applications to synchronize the audio output clocks to the baseband clock. ATL can be also used to track errors between two reference clocks (BWS, AWS) and generate a modulated clock output which averages to some desired frequency. To be able to integrate the ATL provided clocks to the clock tree we need two types of DT binding: - DT clock nodes to represent the ATL clocks towards the CCF - binding for the ATL IP itself which is going to handle the hw configuration The reason for this type of setup is that ATL itself is a separate device in the SoC, it has it's own address space and clock domain. Other IPs can use the ATL generated clock as their functional clock (McASPs for example) and external components like audio codecs can also use the very same clock as their MCLK. With setup pm_runtime can handle the ATL clock on demand of it's use and all the IP which needs ATL clock can be sure that it is enabled for them. The first patch fixes the name of atl clkin3 node in dtsi file. Regards, Peter --- Peter Ujfalusi (3): ARM: dts: dra7xx-clocks: Correct name for atl clkin3 clock clk: Driver for DRA7 ATL (Audio Tracking Logic) ARM: DTS: dra7/dra7xx-clocks: ATL related changes .../devicetree/bindings/clock/ti/dra7-atl.txt | 97 +++ arch/arm/boot/dts/dra7.dtsi| 11 + arch/arm/boot/dts/dra7xx-clocks.dtsi | 38 +-- drivers/clk/ti/Makefile| 3 +- drivers/clk/ti/clk-7xx.c | 2 +- drivers/clk/ti/clk-dra7-atl.c | 313 + include/dt-bindings/clk/ti-dra7-atl.h | 40 +++ 7 files changed, 483 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/dra7-atl.txt create mode 100644 drivers/clk/ti/clk-dra7-atl.c create mode 100644 include/dt-bindings/clk/ti-dra7-atl.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
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.
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_DEFFREQ 10
@@ -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)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: DTS: dra7xx-clocks: Correct mcasp2_ahclkx_mux bit-shift
The correct bit is 24 for AHCLKX. Signed-off-by: Peter Ujfalusi --- arch/arm/boot/dts/dra7xx-clocks.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi index e96da9a898ad..cfb8fc753f50 100644 --- a/arch/arm/boot/dts/dra7xx-clocks.dtsi +++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi @@ -1640,7 +1640,7 @@ #clock-cells = <0>; compatible = "ti,mux-clock"; clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>, <&atlclkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>; - ti,bit-shift = <28>; + ti,bit-shift = <24>; reg = <0x1860>; }; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
