Re: [alsa-devel] [PATCH RFC v2 0/2] Fix simple-card *-master DT parameter handling
Hi Jyri > This patch-set was never merged as such. Instead there is another > patch-set that has been applied by Mark to cover this issue [1]. The > patch maintains backward compatibility, with the Nicolin Chen's patch > [2]. In other words, old style "bitclock-master" and "frame-master" > boolean parameters are read from the codec node if they can not be found > from the top level node. The backward compatibility does not apply to > multi-link [3] configurations. Thank you ! I could find them -- 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 02/11] ARM: shmobile: Armadillo 800 EVA: initialize all struct pwm_lookup members
On Mon, Apr 14, 2014 at 11:59:44PM +0200, Alexandre Belloni wrote:
> Initializing all the struct pwm_lookup members allows to get rid of the struct
> tpu_pwm_platform_data as the polarity initialization will be taken care of by
> the PWM core.
>
> Signed-off-by: Alexandre Belloni
This looks good to me.
Please let me know when the driver code has been merged and
I'll take this patch. Likewise for the other shmobile patch in this series.
> ---
> arch/arm/mach-shmobile/board-armadillo800eva.c | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
> b/arch/arm/mach-shmobile/board-armadillo800eva.c
> index 2858f380beae..1bf61dad9a35 100644
> --- a/arch/arm/mach-shmobile/board-armadillo800eva.c
> +++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
> @@ -31,7 +31,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -399,24 +399,22 @@ static struct resource pwm_resources[] = {
> },
> };
>
> -static struct tpu_pwm_platform_data pwm_device_data = {
> - .channels[2] = {
> - .polarity = PWM_POLARITY_INVERSED,
> - }
> -};
> -
> static struct platform_device pwm_device = {
> .name = "renesas-tpu-pwm",
> .id = -1,
> - .dev = {
> - .platform_data = &pwm_device_data,
> - },
> .num_resources = ARRAY_SIZE(pwm_resources),
> .resource = pwm_resources,
> };
>
> static struct pwm_lookup pwm_lookup[] = {
> - PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL),
> + {
> + .provider = "renesas-tpu-pwm",
> + .index = 2,
> + .dev_id = "pwm-backlight.0",
> + .con_id = NULL,
> + .period = 3,
> + .polarity = PWM_POLARITY_INVERSED,
> + },
> };
>
> /* LCDC and backlight */
> --
> 1.8.3.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 02/11] ARM: OMAP3: Fix idle mode signaling for sys_clkreq and sys_off_mode
On Fri, Apr 11, 2014 at 2:47 AM, Tony Lindgren wrote:
> While debugging legacy mode vs device tree booted PM regressions,
> I noticed that omap3 is not toggling sys_clkreq and sys_off_mode
> pins like it should.
>
> The sys_clkreq and sys_off_mode pins are not toggling because of
> the following issues:
>
> 1. The default polarity for the sys_off_mode pin is wrong.
>OFFMODE_POL needs to be cleared for sys_off_mode to go down when
>hitting off-idle, while CLKREQ_POL needs to be set so sys_clkreq
>goes down when hitting retention.
>
> 2. The values for voltctrl register need to be updated dynamically.
>We need to set either the retention idle bits, or off idle bits
>in the voltctrl register depending the idle mode we're targeting
>to hit.
>
> Let's fix these two issues as otherwise the system will just
> hang if any twl4030 PMIC idle scripts are loaded. The only case
> where the system does not hang is if only retention idle over I2C4
> is configured by the bootloader.
>
> Note that even without the twl4030 PMIC scripts, these fixes will
> do the proper signaling of sys_clkreq and sys_off_mode pins, so
> the fixes are needed to fix monitoring of PM states with LEDs or
> an oscilloscope.
>
> Cc: Kevin Hilman
> Cc: Nishanth Menon
> Cc: Paul Walmsley
> Cc: Tero Kristo
> Signed-off-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/pm34xx.c | 2 +
> arch/arm/mach-omap2/prm-regbits-34xx.h | 11 -
> arch/arm/mach-omap2/vc.c | 75
> +-
> arch/arm/mach-omap2/vc.h | 2 +
> 4 files changed, 87 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 87099bb..3119ec2 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -50,6 +50,7 @@
> #include "sdrc.h"
> #include "sram.h"
> #include "control.h"
> +#include "vc.h"
>
> /* pm34xx errata defined in pm.h */
> u16 pm34xx_errata;
> @@ -282,6 +283,7 @@ void omap_sram_idle(void)
>
> /* CORE */
> if (core_next_state < PWRDM_POWER_ON) {
> + omap3_vc_set_pmic_signaling(core_next_state);
I wonder how is it going to affect latencies, adding stuff to suspend
path hurts things like NAND transfers, which consist of lots of small
blocks with an interrupt after each..
> if (core_next_state == PWRDM_POWER_OFF) {
> omap3_core_save_context();
> omap3_cm_save_context();
> diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h
> b/arch/arm/mach-omap2/prm-regbits-34xx.h
> index cebad56..106132d 100644
> --- a/arch/arm/mach-omap2/prm-regbits-34xx.h
> +++ b/arch/arm/mach-omap2/prm-regbits-34xx.h
> @@ -123,8 +123,15 @@
> #define OMAP3430_GLOBAL_SW_RST_SHIFT 1
> #define OMAP3430_GLOBAL_COLD_RST_SHIFT 0
> #define OMAP3430_GLOBAL_COLD_RST_MASK (1 << 0)
> -#define OMAP3430_SEL_OFF_MASK (1 << 3)
> -#define OMAP3430_AUTO_OFF_MASK (1 << 2)
> +#define OMAP3430_PRM_VOLTCTRL_SEL_VMODE(1 << 4)
> +#define OMAP3430_PRM_VOLTCTRL_SEL_OFF (1 << 3)
> +#define OMAP3430_PRM_VOLTCTRL_AUTO_OFF (1 << 2)
> +#define OMAP3430_PRM_VOLTCTRL_AUTO_RET (1 << 1)
> +#define OMAP3430_PRM_VOLTCTRL_AUTO_SLEEP (1 << 0)
> #define OMAP3430_SETUP_TIME2_MASK (0x << 16)
> #define OMAP3430_SETUP_TIME1_MASK (0x << 0)
> +#define OMAP3430_PRM_POLCTRL_OFFMODE_POL (1 << 3)
> +#define OMAP3430_PRM_POLCTRL_CLKOUT_POL(1 << 2)
> +#define OMAP3430_PRM_POLCTRL_CLKREQ_POL(1 << 1)
> +#define OMAP3430_PRM_POLCTRL_EXTVOL_POL(1 << 0)
> #endif
> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
> index 49ac797..3d5ba5d 100644
> --- a/arch/arm/mach-omap2/vc.c
> +++ b/arch/arm/mach-omap2/vc.c
> @@ -220,6 +220,78 @@ static inline u32 omap_usec_to_32k(u32 usec)
> return DIV_ROUND_UP_ULL(32768ULL * (u64)usec, 100ULL);
> }
>
> +void omap3_vc_set_pmic_signaling(int core_next_state)
> +{
> + u32 voltctrl;
> +
> + voltctrl = omap2_prm_read_mod_reg(OMAP3430_GR_MOD,
> + OMAP3_PRM_VOLTCTRL_OFFSET);
> + switch (core_next_state) {
> + case PWRDM_POWER_OFF:
> + voltctrl &= ~(OMAP3430_PRM_VOLTCTRL_AUTO_RET |
> + OMAP3430_PRM_VOLTCTRL_AUTO_SLEEP);
> + voltctrl |= OMAP3430_PRM_VOLTCTRL_AUTO_OFF;
> + break;
> + case PWRDM_POWER_RET:
> + voltctrl &= ~(OMAP3430_PRM_VOLTCTRL_AUTO_OFF |
> + OMAP3430_PRM_VOLTCTRL_AUTO_SLEEP);
> + voltctrl |= OMAP3430_PRM_VOLTCTRL_AUTO_RET;
> + break;
> + default:
> + voltctrl &= ~
[PATCHv2 02/11] ARM: shmobile: Armadillo 800 EVA: initialize all struct pwm_lookup members
Initializing all the struct pwm_lookup members allows to get rid of the struct
tpu_pwm_platform_data as the polarity initialization will be taken care of by
the PWM core.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-shmobile/board-armadillo800eva.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 2858f380beae..1bf61dad9a35 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -31,7 +31,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -399,24 +399,22 @@ static struct resource pwm_resources[] = {
},
};
-static struct tpu_pwm_platform_data pwm_device_data = {
- .channels[2] = {
- .polarity = PWM_POLARITY_INVERSED,
- }
-};
-
static struct platform_device pwm_device = {
.name = "renesas-tpu-pwm",
.id = -1,
- .dev = {
- .platform_data = &pwm_device_data,
- },
.num_resources = ARRAY_SIZE(pwm_resources),
.resource = pwm_resources,
};
static struct pwm_lookup pwm_lookup[] = {
- PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL),
+ {
+ .provider = "renesas-tpu-pwm",
+ .index = 2,
+ .dev_id = "pwm-backlight.0",
+ .con_id = NULL,
+ .period = 3,
+ .polarity = PWM_POLARITY_INVERSED,
+ },
};
/* LCDC and backlight */
--
1.8.3.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
[PATCHv2 04/11] ARM: OMAP3: Beagle: initialize all the struct pwm_lookup members
This will allow to get rid of the .pwm_period_ns member of struct led_pwm as the
period will be set by the PWM core.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-omap2/board-omap3beagle.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index d6ed819ff15c..f27e1ec90b5e 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -61,7 +61,14 @@
static struct pwm_lookup pwm_lookup[] = {
/* LEDB -> PMU_STAT */
- PWM_LOOKUP("twl-pwmled", 1, "leds_pwm", "beagleboard::pmu_stat"),
+ {
+ .provider = "twl-pwmled",
+ .index = 1,
+ .dev_id = "leds_pwm",
+ .con_id = "beagleboard::pmu_stat",
+ .period = 7812500,
+ .polarity = PWM_POLARITY_NORMAL,
+ },
};
static struct led_pwm pwm_leds[] = {
--
1.8.3.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
[PATCHv2 00/11] improve PWM lookup support without device tree
Hi, A patch set as suggested by Thierry to make lookup with the lookup table instead of device tree behave more like when using device tree. The first patch adds a period and a polarity member to the lookup table and use those to set period and polarity. Patch 2, 4 and 5 are making use of those new members from the board files. Patch 3 removes useless code since setting the polarity is now handled by the PWM core. I couldn't decide on a good name for the extended PWM_LOOKUP macro and I believe we won't have to add members to that structure soon so: Patch 6 modifies the PWM_LOOKUP macro to also initialize period and polarity and Patch 7-9 are making use of the new PWM_LOOKUP macro in the board files Patch 10 and 11 are making the leds-pwm and pwm_bl drivers get the period from the PWM before using pwm_period_ns if it is not already set. Patch 10 will obviously conflict with the series of Russell reworking the leds-pwm probing. I can rebase if necessary The final goal would be to get rid of .pwm_period_ns in leds-pwm and pwm_bl after moving all the remaining users (still around 25) to pwm_lookup. Changes in v2: - correctly unlock the pwm_lookup_lock mutex before returning. - don't change PWM_LOOKUP atomically - remove tpu_pwm_platform_data and the associated header file - make the leds-pwm and pwm_bl drivers get the period from the PWM Alexandre Belloni (11): pwm: add period and polarity to struct pwm_lookup ARM: shmobile: Armadillo 800 EVA: initialize all struct pwm_lookup members pwm: renesas-tpu: remove useless struct tpu_pwm_platform_data ARM: OMAP3: Beagle: initialize all the struct pwm_lookup members ARM: pxa: hx4700: initialize all the struct pwm_lookup members pwm: modify PWM_LOOKUP to initialize all struct pwm_lookup members ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup ARM: shmobile: Armadillo 800 EVA: use PWM_LOOKUP to initialize struct pwm_lookup ARM: pxa: hx4700: use PWM_LOOKUP to initialize struct pwm_lookup leds: leds-pwm: retrieve configured pwm period backlight: pwm_bl: retrieve configured pwm period Documentation/pwm.txt | 3 ++- arch/arm/mach-omap2/board-omap3beagle.c| 3 ++- arch/arm/mach-pxa/hx4700.c | 3 ++- arch/arm/mach-shmobile/board-armadillo800eva.c | 14 +++--- drivers/leds/leds-pwm.c| 5 - drivers/pwm/core.c | 8 +++- drivers/pwm/pwm-renesas-tpu.c | 19 +++ drivers/video/backlight/pwm_bl.c | 8 +--- include/linux/platform_data/pwm-renesas-tpu.h | 16 include/linux/pwm.h| 6 +- 10 files changed, 33 insertions(+), 52 deletions(-) delete mode 100644 include/linux/platform_data/pwm-renesas-tpu.h -- 1.8.3.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
[PATCHv2 03/11] pwm: renesas-tpu: remove useless struct tpu_pwm_platform_data
The struct tpu_pwm_platform_data is not used anymore and the polarity
initialization will be taken care of by the PWM core.
Signed-off-by: Alexandre Belloni
---
drivers/pwm/pwm-renesas-tpu.c | 19 +++
include/linux/platform_data/pwm-renesas-tpu.h | 16
2 files changed, 3 insertions(+), 32 deletions(-)
delete mode 100644 include/linux/platform_data/pwm-renesas-tpu.h
diff --git a/drivers/pwm/pwm-renesas-tpu.c b/drivers/pwm/pwm-renesas-tpu.c
index aff6ba9b49e7..9dbcf82b3e6c 100644
--- a/drivers/pwm/pwm-renesas-tpu.c
+++ b/drivers/pwm/pwm-renesas-tpu.c
@@ -21,13 +21,14 @@
#include
#include
#include
-#include
#include
#include
#include
#include
#include
+#define TPU_CHANNEL_MAX4
+
#define TPU_TSTR 0x00/* Timer start register (shared) */
#define TPU_TCRn 0x00/* Timer control register */
@@ -87,7 +88,6 @@ struct tpu_pwm_device {
struct tpu_device {
struct platform_device *pdev;
- enum pwm_polarity polarities[TPU_CHANNEL_MAX];
struct pwm_chip chip;
spinlock_t lock;
@@ -229,7 +229,7 @@ static int tpu_pwm_request(struct pwm_chip *chip, struct
pwm_device *_pwm)
pwm->tpu = tpu;
pwm->channel = _pwm->hwpwm;
- pwm->polarity = tpu->polarities[pwm->channel];
+ pwm->polarity = PWM_POLARITY_NORMAL;
pwm->prescaler = 0;
pwm->period = 0;
pwm->duty = 0;
@@ -388,16 +388,6 @@ static const struct pwm_ops tpu_pwm_ops = {
* Probe and remove
*/
-static void tpu_parse_pdata(struct tpu_device *tpu)
-{
- struct tpu_pwm_platform_data *pdata = tpu->pdev->dev.platform_data;
- unsigned int i;
-
- for (i = 0; i < ARRAY_SIZE(tpu->polarities); ++i)
- tpu->polarities[i] = pdata ? pdata->channels[i].polarity
- : PWM_POLARITY_NORMAL;
-}
-
static int tpu_probe(struct platform_device *pdev)
{
struct tpu_device *tpu;
@@ -413,9 +403,6 @@ static int tpu_probe(struct platform_device *pdev)
spin_lock_init(&tpu->lock);
tpu->pdev = pdev;
- /* Initialize device configuration from platform data. */
- tpu_parse_pdata(tpu);
-
/* Map memory, get clock and pin control. */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
tpu->base = devm_ioremap_resource(&pdev->dev, res);
diff --git a/include/linux/platform_data/pwm-renesas-tpu.h
b/include/linux/platform_data/pwm-renesas-tpu.h
deleted file mode 100644
index a7220b10ddab..
--- a/include/linux/platform_data/pwm-renesas-tpu.h
+++ /dev/null
@@ -1,16 +0,0 @@
-#ifndef __PWM_RENESAS_TPU_H__
-#define __PWM_RENESAS_TPU_H__
-
-#include
-
-#define TPU_CHANNEL_MAX4
-
-struct tpu_pwm_channel_data {
- enum pwm_polarity polarity;
-};
-
-struct tpu_pwm_platform_data {
- struct tpu_pwm_channel_data channels[TPU_CHANNEL_MAX];
-};
-
-#endif /* __PWM_RENESAS_TPU_H__ */
--
1.8.3.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
[PATCHv2 01/11] pwm: add period and polarity to struct pwm_lookup
Adds a period and a polarity member to struct pwm_lookup so that when performing
a lookup using the lookup table instead of device tree, we are able to set the
period and the polarity accordingly like what is done in
of_pwm_xlate_with_flags.
The period and polarity can be set unconditionally as the default is 0 anyway.
Signed-off-by: Alexandre Belloni
---
drivers/pwm/core.c | 8 +++-
include/linux/pwm.h | 2 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index a80471399c20..4b66bf09ee55 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -661,10 +661,16 @@ struct pwm_device *pwm_get(struct device *dev, const char
*con_id)
}
}
+ mutex_unlock(&pwm_lookup_lock);
+
if (chip)
pwm = pwm_request_from_chip(chip, index, con_id ?: dev_id);
+ if (IS_ERR(pwm))
+ return pwm;
+
+ pwm_set_period(pwm, p->period);
+ pwm_set_polarity(pwm, p->polarity);
- mutex_unlock(&pwm_lookup_lock);
return pwm;
}
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 4717f54051cb..2f45e2fe5b93 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -274,6 +274,8 @@ struct pwm_lookup {
unsigned int index;
const char *dev_id;
const char *con_id;
+ unsigned int period;
+ enum pwm_polarity polarity;
};
#define PWM_LOOKUP(_provider, _index, _dev_id, _con_id)\
--
1.8.3.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
[PATCHv2 10/11] leds: leds-pwm: retrieve configured pwm period
The PWM core is now able to initialize the PWM period. Use it and if it is not configured, use the supplied pwm_period_ns. Signed-off-by: Alexandre Belloni --- drivers/leds/leds-pwm.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c index 7d0aaed1e23a..aa770ec1e892 100644 --- a/drivers/leds/leds-pwm.c +++ b/drivers/leds/leds-pwm.c @@ -181,7 +181,6 @@ static int led_pwm_probe(struct platform_device *pdev) led_dat->cdev.name = cur_led->name; led_dat->cdev.default_trigger = cur_led->default_trigger; led_dat->active_low = cur_led->active_low; - led_dat->period = cur_led->pwm_period_ns; led_dat->cdev.brightness_set = led_pwm_set; led_dat->cdev.brightness = LED_OFF; led_dat->cdev.max_brightness = cur_led->max_brightness; @@ -191,6 +190,10 @@ static int led_pwm_probe(struct platform_device *pdev) if (led_dat->can_sleep) INIT_WORK(&led_dat->work, led_pwm_work); + led_dat->period = pwm_get_period(led_dat->pwm); + if (!led_dat->period && (cur_led->pwm_period_ns > 0)) + led_dat->period = cur_led->pwm_period_ns; + ret = led_classdev_register(&pdev->dev, &led_dat->cdev); if (ret < 0) goto err; -- 1.8.3.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
[PATCHv2 06/11] pwm: modify PWM_LOOKUP to initialize all struct pwm_lookup members
Now that PWM_LOOKUP is not used anymore, modify it to initialize all the
members of struct pwm_lookup.
Signed-off-by: Alexandre Belloni
---
Documentation/pwm.txt | 3 ++-
include/linux/pwm.h | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
index 93cb97974986..f38f99cda64f 100644
--- a/Documentation/pwm.txt
+++ b/Documentation/pwm.txt
@@ -19,7 +19,8 @@ should instead register a static mapping that can be used to
match PWM
consumers to providers, as given in the following example:
static struct pwm_lookup board_pwm_lookup[] = {
- PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL),
+ PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL,
+ 5, PWM_POLARITY_NORMAL),
};
static void __init board_init(void)
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 2f45e2fe5b93..e90628cac8fa 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -278,12 +278,14 @@ struct pwm_lookup {
enum pwm_polarity polarity;
};
-#define PWM_LOOKUP(_provider, _index, _dev_id, _con_id)\
+#define PWM_LOOKUP(_provider, _index, _dev_id, _con_id, _period, _polarity) \
{ \
.provider = _provider, \
.index = _index,\
.dev_id = _dev_id, \
.con_id = _con_id, \
+ .period = _period, \
+ .polarity = _polarity \
}
#if IS_ENABLED(CONFIG_PWM)
--
1.8.3.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
[PATCHv2 08/11] ARM: shmobile: Armadillo 800 EVA: use PWM_LOOKUP to initialize struct pwm_lookup
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-shmobile/board-armadillo800eva.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 1bf61dad9a35..ca82b1e2ebab 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -407,14 +407,8 @@ static struct platform_device pwm_device = {
};
static struct pwm_lookup pwm_lookup[] = {
- {
- .provider = "renesas-tpu-pwm",
- .index = 2,
- .dev_id = "pwm-backlight.0",
- .con_id = NULL,
- .period = 3,
- .polarity = PWM_POLARITY_INVERSED,
- },
+ PWM_LOOKUP("renesas-tpu-pwm", 2, "pwm-backlight.0", NULL,
+ 3, PWM_POLARITY_INVERSED),
};
/* LCDC and backlight */
--
1.8.3.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
[PATCHv2 09/11] ARM: pxa: hx4700: use PWM_LOOKUP to initialize struct pwm_lookup
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-pxa/hx4700.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index 0788a1f171fe..c66ad4edc5e3 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++ b/arch/arm/mach-pxa/hx4700.c
@@ -574,14 +574,8 @@ static struct platform_device backlight = {
};
static struct pwm_lookup hx4700_pwm_lookup[] = {
- {
- .provider = "pxa27x-pwm.1",
- .index = 0,
- .dev_id = "pwm-backlight",
- .con_id = NULL,
- .period = 30923,
- .polarity = PWM_POLARITY_NORMAL,
- },
+ PWM_LOOKUP("pxa27x-pwm.1", 0, "pwm-backlight", NULL,
+ 30923, PWM_POLARITY_NORMAL),
};
/*
--
1.8.3.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
[PATCHv2 07/11] ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup
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),
};
static struct led_pwm pwm_leds[] = {
--
1.8.3.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
[PATCHv2 05/11] ARM: pxa: hx4700: initialize all the struct pwm_lookup members
This will allow to get rid of the .pwm_period_ns member of struct
platform_pwm_backlight_data as the period will be set by the PWM core.
Signed-off-by: Alexandre Belloni
---
arch/arm/mach-pxa/hx4700.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index a7c30eb0c8db..0788a1f171fe 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++ b/arch/arm/mach-pxa/hx4700.c
@@ -574,7 +574,14 @@ static struct platform_device backlight = {
};
static struct pwm_lookup hx4700_pwm_lookup[] = {
- PWM_LOOKUP("pxa27x-pwm.1", 0, "pwm-backlight", NULL),
+ {
+ .provider = "pxa27x-pwm.1",
+ .index = 0,
+ .dev_id = "pwm-backlight",
+ .con_id = NULL,
+ .period = 30923,
+ .polarity = PWM_POLARITY_NORMAL,
+ },
};
/*
--
1.8.3.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
[PATCHv2 11/11] backlight: pwm_bl: retrieve configured pwm period
The PWM core is now able to initialize the PWM period from platform_data. Use it
and if it is not configured, use the supplied pwm_period_ns.
Signed-off-by: Alexandre Belloni
---
drivers/video/backlight/pwm_bl.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index b75201ff46f6..1bb8a69062c5 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -304,12 +304,14 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
/*
* The DT case will set the pwm_period_ns field to 0 and store the
* period, parsed from the DT, in the PWM device. For the non-DT case,
-* set the period from platform data.
+* set the period from platform data if it is not already set.
*/
- if (data->pwm_period_ns > 0)
+ pb->period = pwm_get_period(pb->pwm);
+ if (!pb->period && (data->pwm_period_ns > 0)) {
+ pb->period = data->pwm_period_ns;
pwm_set_period(pb->pwm, data->pwm_period_ns);
+ }
- pb->period = pwm_get_period(pb->pwm);
pb->lth_brightness = data->lth_brightness * (pb->period / pb->scale);
memset(&props, 0, sizeof(struct backlight_properties));
--
1.8.3.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: L3 custom error on OMAP4460 (AES/DES)
On 04/14/2014 02:15 PM, Joachim Eastwood wrote: > On 14 April 2014 15:38, Santosh Shilimkar wrote: >> On Saturday 12 April 2014 05:06 PM, Joachim Eastwood wrote: >>> Hi, >>> >>> I getting the following error on Linus master right now. >>> >>> [ 2.166320] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:113 >>> l3_interrupt_handler+0xf4/0x154() >>> [ 2.166320] L3 custom error: MASTER:MPU TARGET:L4 PER2 >>> [ 2.166320] Modules linked in: [...] >>> The hardware is a VAR-STK-OM44 dev kit. I got one patch on top of >>> Linus master which is the DT support patch which I posted a couple of >>> hours ago. >>> >> Have you tried removing AES from the build ? Probably worth a >> try. > > Removing the aes driver makes the warning from omap_l3_noc disappear. > > I also tried tried the omap_l3_noc patches from Nishanth Menon that > was just posted but it had the same error when the aes driver was > built-in. Yeah - it better :).. Good to know that driver continues to report bad accesses by drivers to targets that are not active yet. will be great if you could provide a "Tested-by" tag on my series :). Btw, I just finished testing on PandaBoard ES and SDP4430 and I dont see the error that you see on var som. I wonder why? pandaboard-es: Boot PASS: http://slexy.org/raw/s21Hsq97mt sdp4430: Boot PASS: http://slexy.org/raw/s2ZQJUqjrP > > Would it be possible for someone to add hwmod data for the aes driver > to the kernel so that the aes could actually work? Joel, are you planning on posting OMAP4 hwmod data for AES/DES? -- Regards, 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: L3 custom error on OMAP4460
On 14 April 2014 15:38, Santosh Shilimkar wrote: > On Saturday 12 April 2014 05:06 PM, Joachim Eastwood wrote: >> Hi, >> >> I getting the following error on Linus master right now. >> >> [ 2.166320] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:113 >> l3_interrupt_handler+0xf4/0x154() >> [ 2.166320] L3 custom error: MASTER:MPU TARGET:L4 PER2 >> [ 2.166320] Modules linked in: >> [ 2.166351] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 3.14.0-12542-gfb5ce8367c24 #11 >> [ 2.166381] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [ 2.166381] [] (show_stack) from [] >> (dump_stack+0x84/0x94) >> [ 2.166412] [] (dump_stack) from [] >> (warn_slowpath_common+0x70/0x8c) >> [ 2.166412] [] (warn_slowpath_common) from [] >> (warn_slowpath_fmt+0x30/0x40) >> [ 2.166412] [] (warn_slowpath_fmt) from [] >> (l3_interrupt_handler+0xf4/0x154) >> [ 2.166442] [] (l3_interrupt_handler) from [] >> (handle_irq_event_percpu+0x54/0x1cc) >> [ 2.166473] [] (handle_irq_event_percpu) from [] >> (handle_irq_event+0x3c/0x5c) >> [ 2.166473] [] (handle_irq_event) from [] >> (handle_fasteoi_irq+0xac/0x1a0) >> [ 2.166473] [] (handle_fasteoi_irq) from [] >> (generic_handle_irq+0x2c/0x3c) >> [ 2.166503] [] (generic_handle_irq) from [] >> (handle_IRQ+0x40/0x90) >> [ 2.166503] [] (handle_IRQ) from [] >> (gic_handle_irq+0x2c/0x5c) >> [ 2.166534] [] (gic_handle_irq) from [] >> (__irq_svc+0x44/0x58) >> [ 2.166534] Exception stack(0xc087bf58 to 0xc087bfa0) >> [ 2.166534] bf40: 0001 0001 >> [ 2.166534] bf60: c08856f8 c087a000 c087a000 c08d9544 >> c0882548 c087a000 ee7ffc40 >> [ 2.166564] bf80: c08824e0 c05b9cec c087bfa0 c007a0f0 >> c000eda8 2113 >> [ 2.166564] [] (__irq_svc) from [] >> (arch_cpu_idle+0x24/0x30) >> [ 2.166595] [] (arch_cpu_idle) from [] >> (cpu_startup_entry+0x138/0x204) >> [ 2.166595] [] (cpu_startup_entry) from [] >> (start_kernel+0x370/0x37c) >> [ 2.166625] [] (start_kernel) from [<80008074>] (0x80008074) >> >> Not sure what to make of it. Anyone got any idea? >> >> Right before the L3 custom WARN I also get these messages from the >> des/aes crypot drivers. Might be unrelated, though. >> [ 2.134643] omap-aes 4b501000.aes: _od_fail_runtime_resume: FIXME: >> missing hwmod/omap_dev info >> [ 2.143737] omap-aes 4b501000.aes: omap_aes_probe: failed to get_sync(-19) >> [ 2.151000] omap-aes 4b501000.aes: initialization failed. >> [ 2.157196] omap-des 480a5000.des: _od_fail_runtime_resume: FIXME: >> missing hwmod/omap_dev info >> [ 2.166290] omap-des 480a5000.des: OMAP DES hw accel rev: 0.0 >> >> The hardware is a VAR-STK-OM44 dev kit. I got one patch on top of >> Linus master which is the DT support patch which I posted a couple of >> hours ago. >> > Have you tried removing AES from the build ? Probably worth a > try. Removing the aes driver makes the warning from omap_l3_noc disappear. I also tried tried the omap_l3_noc patches from Nishanth Menon that was just posted but it had the same error when the aes driver was built-in. Would it be possible for someone to add hwmod data for the aes driver to the kernel so that the aes could actually work? regards, Joachim Eastwood > Regards, > Santosh > -- 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: AM4372: add l3-noc information
From: Afzal Mohammed
AM4372 has two clk domains 100f and 200s. Provide register mapping,
interrupt information and compatibility flags associated with it.
Signed-off-by: Dave Gerlach
Signed-off-by: Afzal Mohammed
Signed-off-by: Sekhar Nori
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/am4372.dtsi |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 36d523a..ef29037 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -67,11 +67,15 @@
};
ocp {
- compatible = "simple-bus";
+ compatible = "ti,am4372-l3-noc", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
ti,hwmods = "l3_main";
+ reg = <0x4400 0x40
+ 0x4480 0x40>;
+ interrupts = ,
+;
prcm: prcm@44df {
compatible = "ti,am4-prcm";
--
1.7.9.5
--
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: DRA7: Use dra7-l3-noc instead of omap4-l3-noc
From: Rajendra Nayak
We have currently marked the DRA7 L3 as being compatible with
omap4-l3-noc This is not true considering the differences in data
involved.
Now that we have proper support for ti,dra7-l3-noc, add the clock
modules clk1 and clk3 (clk2 submodule will be handled by the driver)
and switch compatibility flag to use the proper data.
Signed-off-by: Rajendra Nayak
[n...@ti.com: map up full address range]
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/dra7.dtsi |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1c0f8e1..c7222ca 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -99,13 +99,13 @@
* hierarchy.
*/
ocp {
- compatible = "ti,omap4-l3-noc", "simple-bus";
+ compatible = "ti,dra7-l3-noc", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
ti,hwmods = "l3_main_1", "l3_main_2";
- reg = <0x4400 0x2000>,
- <0x4480 0x3000>;
+ reg = <0x4400 0x100>,
+ <0x4500 0x1000>;
interrupts = ,
;
--
1.7.9.5
--
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/2] ARM: dts: DRA7/AM4372: add l3_noc information
Patch series based on: v3.15-rc1 tag. Depends on series posted: http://marc.info/?l=linux-omap&m=139749383932575&w=2 DTS Patches is available here: https://github.com/nmenon/linux-2.6-playground/commits/l3noc/dts-fixes This just adds the dts information based on driver support provided. Test log: 1: am43xx-epos: Boot PASS: http://slexy.org/raw/s2pjavFUYd 2: DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s21pdAj0hU 3: pandaboard-es: Boot PASS: http://slexy.org/raw/s21Hsq97mt 4:sdp4430: Boot PASS: http://slexy.org/raw/s2ZQJUqjrP 5: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2hNulLOuX Afzal Mohammed (1): ARM: dts: AM4372: add l3-noc information Rajendra Nayak (1): ARM: dts: DRA7: Use dra7-l3-noc instead of omap4-l3-noc arch/arm/boot/dts/am4372.dtsi |6 +- arch/arm/boot/dts/dra7.dtsi |6 +++--- 2 files changed, 8 insertions(+), 4 deletions(-) -- 1.7.9.5 -- 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 09/15] bus: omap_l3_noc: rename functions and data to omap_l3
From: Sricharan R
Since omap_l3_noc driver is now being used for OMAP5 and reusable with
DRA7 and AM437x, using omap4 specific naming is misleading.
Signed-off-by: Sricharan R
Signed-off-by: Nishanth Menon
---
drivers/bus/omap_l3_noc.c | 24
drivers/bus/omap_l3_noc.h | 11 ++-
2 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index c2b0cc3..6848822 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -1,5 +1,5 @@
/*
- * OMAP4XXX L3 Interconnect error handling driver
+ * OMAP L3 Interconnect error handling driver
*
* Copyright (C) 2011-2014 Texas Instruments Incorporated - http://www.ti.com/
* Santosh Shilimkar
@@ -50,7 +50,7 @@
static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
{
- struct omap4_l3 *l3 = _l3;
+ struct omap_l3 *l3 = _l3;
int inttype, i, k;
int err_src = 0;
u32 std_err_main, err_reg, clear, masterid;
@@ -166,9 +166,9 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
return IRQ_HANDLED;
}
-static int omap4_l3_probe(struct platform_device *pdev)
+static int omap_l3_probe(struct platform_device *pdev)
{
- static struct omap4_l3 *l3;
+ static struct omap_l3 *l3;
int ret, i;
l3 = devm_kzalloc(&pdev->dev, sizeof(*l3), GFP_KERNEL);
@@ -221,8 +221,8 @@ MODULE_DEVICE_TABLE(of, l3_noc_match);
#define l3_noc_match NULL
#endif
-static struct platform_driver omap4_l3_driver = {
- .probe = omap4_l3_probe,
+static struct platform_driver omap_l3_driver = {
+ .probe = omap_l3_probe,
.driver = {
.name = "omap_l3_noc",
.owner = THIS_MODULE,
@@ -230,14 +230,14 @@ static struct platform_driver omap4_l3_driver = {
},
};
-static int __init omap4_l3_init(void)
+static int __init omap_l3_init(void)
{
- return platform_driver_register(&omap4_l3_driver);
+ return platform_driver_register(&omap_l3_driver);
}
-postcore_initcall_sync(omap4_l3_init);
+postcore_initcall_sync(omap_l3_init);
-static void __exit omap4_l3_exit(void)
+static void __exit omap_l3_exit(void)
{
- platform_driver_unregister(&omap4_l3_driver);
+ platform_driver_unregister(&omap_l3_driver);
}
-module_exit(omap4_l3_exit);
+module_exit(omap_l3_exit);
diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
index c4a1760..a1931e8 100644
--- a/drivers/bus/omap_l3_noc.h
+++ b/drivers/bus/omap_l3_noc.h
@@ -1,5 +1,5 @@
/*
- * OMAP4XXX L3 Interconnect error handling driver header
+ * OMAP L3 Interconnect error handling driver header
*
* Copyright (C) 2011-2014 Texas Instruments Incorporated - http://www.ti.com/
* Santosh Shilimkar
@@ -14,8 +14,8 @@
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
-#ifndef __ARCH_ARM_MACH_OMAP2_L3_INTERCONNECT_3XXX_H
-#define __ARCH_ARM_MACH_OMAP2_L3_INTERCONNECT_3XXX_H
+#ifndef __OMAP_L3_NOC_H
+#define __OMAP_L3_NOC_H
#define L3_MODULES 3
#define CLEAR_STDERR_LOG (1 << 31)
@@ -140,7 +140,7 @@ static struct l3_target_data *l3_targ[L3_MODULES] = {
l3_target_inst_data_clk3,
};
-struct omap4_l3 {
+struct omap_l3 {
struct device *dev;
struct clk *ick;
@@ -150,4 +150,5 @@ struct omap4_l3 {
int debug_irq;
int app_irq;
};
-#endif
+
+#endif /* __OMAP_L3_NOC_H */
--
1.7.9.5
--
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 13/15] bus: omap_l3_noc: introduce concept of submodule
While OMAP4 and OMAP5 had 3 separate clock domains, DRA7 has only 2
and the first one then is internally divided into 2 sub clock domains.
To better represent this in the driver, we use the concept of submodule.
The address defintions in the devicetree is as per the high level
clock domain(module) base, the sub clockdomain/subdomain which shares
the same register space of a clockdomain is marked in the SoC data as
L3_BASE_IS_SUBMODULE.
L3_BASE_IS_SUBMODULE is used as an indication that it's base address is
the same as the parent module and offsets are considered from the same
base address as they are usually intermingled.
Other than the base address, the submodule is same as a module as it is
functionally so.
Signed-off-by: Nishanth Menon
---
drivers/bus/omap_l3_noc.c | 17 -
drivers/bus/omap_l3_noc.h |6 +-
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 49b19d5..5e2a89d 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -184,7 +184,7 @@ static int omap_l3_probe(struct platform_device *pdev)
{
const struct of_device_id *of_id;
static struct omap_l3 *l3;
- int ret, i;
+ int ret, i, res_idx;
of_id = of_match_device(l3_noc_match, &pdev->dev);
if (!of_id) {
@@ -201,15 +201,22 @@ static int omap_l3_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, l3);
/* Get mem resources */
- for (i = 0; i < l3->num_modules; i++) {
- struct resource *res = platform_get_resource(pdev,
-IORESOURCE_MEM, i);
-
+ for (i = 0, res_idx = 0; i < l3->num_modules; i++) {
+ struct resource *res;
+
+ if (l3->l3_base[i] == L3_BASE_IS_SUBMODULE) {
+ /* First entry cannot be submodule */
+ BUG_ON(i == 0);
+ l3->l3_base[i] = l3->l3_base[i - 1];
+ continue;
+ }
+ res = platform_get_resource(pdev, IORESOURCE_MEM, res_idx);
l3->l3_base[i] = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(l3->l3_base[i])) {
dev_err(l3->dev, "ioremap %d failed\n", i);
return PTR_ERR(l3->l3_base[i]);
}
+ res_idx++;
}
/*
diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
index af33b6e..592821f 100644
--- a/drivers/bus/omap_l3_noc.h
+++ b/drivers/bus/omap_l3_noc.h
@@ -36,6 +36,8 @@
#define L3_TARGET_NOT_SUPPORTEDNULL
+#define L3_BASE_IS_SUBMODULE ((void __iomem *)(1 << 0))
+
/**
* struct l3_masters_data - L3 Master information
* @id:ID of the L3 Master
@@ -76,7 +78,9 @@ struct l3_flagmux_data {
/**
* struct omap_l3 - Description of data relevant for L3 bus.
* @dev: device representing the bus (populated runtime)
- * @l3_base: base addresses of modules (populated runtime)
+ * @l3_base: base addresses of modules (populated runtime if 0)
+ * if set to L3_BASE_IS_SUBMODULE, then uses previous
+ * module index as the base address
* @l3_flag_mux: array containing flag mux data per module
* offset from corresponding module base indexed per
* module.
--
1.7.9.5
--
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 01/15] bus: omap_l3_noc: Fix copyright information
This is an embarrassing patch :(. Texas Corporation does not make OMAP. Texas Instruments Inc does. For that matter I dont seem to be able to find a Texas Corporation on the internet either. While at it, update coverage to the current year and update the template to remove redundant information and use the standard boiler plate licensing. Signed-off-by: Nishanth Menon --- drivers/bus/omap_l3_noc.c | 18 ++ drivers/bus/omap_l3_noc.h | 18 ++ 2 files changed, 12 insertions(+), 24 deletions(-) diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c index 972691a..1eb6d85 100644 --- a/drivers/bus/omap_l3_noc.c +++ b/drivers/bus/omap_l3_noc.c @@ -1,24 +1,18 @@ /* * OMAP4XXX L3 Interconnect error handling driver * - * Copyright (C) 2011 Texas Corporation + * Copyright (C) 2011-2014 Texas Instruments Incorporated - http://www.ti.com/ * Santosh Shilimkar * Sricharan * * 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; either version 2 of the License, or - * (at your option) any later version. + * 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 + * 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. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 - * USA */ #include #include diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h index a6ce34d..cc4b1b1 100644 --- a/drivers/bus/omap_l3_noc.h +++ b/drivers/bus/omap_l3_noc.h @@ -1,24 +1,18 @@ /* * OMAP4XXX L3 Interconnect error handling driver header * - * Copyright (C) 2011 Texas Corporation + * Copyright (C) 2011-2014 Texas Instruments Incorporated - http://www.ti.com/ * Santosh Shilimkar * sricharan * * 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; either version 2 of the License, or - * (at your option) any later version. + * 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 + * 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. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 - * USA */ #ifndef __ARCH_ARM_MACH_OMAP2_L3_INTERCONNECT_3XXX_H #define __ARCH_ARM_MACH_OMAP2_L3_INTERCONNECT_3XXX_H -- 1.7.9.5 -- 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 03/15] bus: omap_l3_noc: un-obfuscate l3_targ address computation
just simplify derefencing that is equivalent. Signed-off-by: Nishanth Menon --- drivers/bus/omap_l3_noc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c index 0d346e6..b39ef93 100644 --- a/drivers/bus/omap_l3_noc.c +++ b/drivers/bus/omap_l3_noc.c @@ -76,7 +76,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3) err_src = __ffs(err_reg); /* Read the stderrlog_main_source from clk domain */ - l3_targ_base = base + *(l3_targ[i] + err_src); + l3_targ_base = base + l3_targ[i][err_src]; l3_targ_stderr = l3_targ_base + L3_TARG_STDERRLOG_MAIN; l3_targ_slvofslsb = l3_targ_base + L3_TARG_STDERRLOG_SLVOFSLSB; -- 1.7.9.5 -- 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 12/15] bus: omap_l3_noc: convert flagmux information into a structure
This allows us to encompass target information and flag mux offset that
points to the target information into a singular structure. This saves
us the need to look up two different arrays indexed by module ID for
information.
This allows us to reduce the static target information allocation to
just the ones that are documented.
Signed-off-by: Nishanth Menon
---
drivers/bus/omap_l3_noc.c | 16 +++
drivers/bus/omap_l3_noc.h | 70 +
2 files changed, 56 insertions(+), 30 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 3819b2f..49b19d5 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -60,6 +60,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
void __iomem *l3_targ_stderr, *l3_targ_slvofslsb, *l3_targ_mstaddr;
char *target_name, *master_name = "UN IDENTIFIED";
struct l3_target_data *l3_targ_inst;
+ struct l3_flagmux_data *flag_mux;
char *err_description;
char err_string[30] = { 0 };
@@ -72,7 +73,8 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
* to determine the source
*/
base = l3->l3_base[i];
- err_reg = readl_relaxed(base + l3->l3_flagmux[i] +
+ flag_mux = l3->l3_flagmux[i];
+ err_reg = readl_relaxed(base + flag_mux->offset +
L3_FLAGMUX_REGERR0 + (inttype << 3));
/* Get the corresponding error and analyse */
@@ -85,9 +87,13 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
/* We DONOT expect err_src to go out of bounds */
BUG_ON(err_src >= MAX_CLKDM_TARGETS);
- l3_targ_inst = &l3->l3_targ[i][err_src];
- target_name = l3_targ_inst->name;
- l3_targ_base = base + l3_targ_inst->offset;
+ if (err_src < flag_mux->num_targ_data) {
+ l3_targ_inst = &flag_mux->l3_targ[err_src];
+ target_name = l3_targ_inst->name;
+ l3_targ_base = base + l3_targ_inst->offset;
+ } else {
+ target_name = L3_TARGET_NOT_SUPPORTED;
+ }
/*
* If we do not know of a register offset to decode
@@ -107,7 +113,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
inttype ? "debug" : "application",
err_src, i, "(unclearable)");
- mask_reg = base + l3->l3_flagmux[i] +
+ mask_reg = base + flag_mux->offset +
L3_FLAGMUX_MASK0 + (inttype << 3);
mask_val = readl(mask_reg);
mask_val &= ~(1 << err_src);
diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
index a546870..af33b6e 100644
--- a/drivers/bus/omap_l3_noc.h
+++ b/drivers/bus/omap_l3_noc.h
@@ -17,8 +17,8 @@
#ifndef __OMAP_L3_NOC_H
#define __OMAP_L3_NOC_H
-#define OMAP_L3_MODULES3
#define MAX_L3_MODULES 3
+#define MAX_CLKDM_TARGETS 30
#define CLEAR_STDERR_LOG (1 << 31)
#define CUSTOM_ERROR 0x2
@@ -36,8 +36,6 @@
#define L3_TARGET_NOT_SUPPORTEDNULL
-#define MAX_CLKDM_TARGETS 30
-
/**
* struct l3_masters_data - L3 Master information
* @id:ID of the L3 Master
@@ -60,21 +58,32 @@ struct l3_target_data {
char *name;
};
+/**
+ * struct l3_flagmux_data - Flag Mux information
+ * @offset:offset from base for flagmux register
+ * @l3_targ: array indexed by flagmux index (bit offset) pointing to the
+ * target data. unsupported ones are marked with
+ * L3_TARGET_NOT_SUPPORTED
+ * @num_targ_data: number of entries in target data
+ */
+struct l3_flagmux_data {
+ u32 offset;
+ struct l3_target_data *l3_targ;
+ u8 num_targ_data;
+};
+
/**
* struct omap_l3 - Description of data relevant for L3 bus.
* @dev: device representing the bus (populated runtime)
* @l3_base: base addresses of modules (populated runtime)
- * @l3_flag_mux: array containing offsets to flag mux per module
+ * @l3_flag_mux: array containing flag mux data per module
* offset from corresponding module base indexed per
* module.
* @num_modules: number of clock domains / modules.
* @l3_masters:array pointing to master data containing name and
register
* offset for the master.
* @num_master: number of masters
- * @l3_targ: array indexed by flagmux index (bit offset) pointing to the
- *
[PATCH 02/15] bus: omap_l3_noc: switch over to relaxed variants of readl/writel
Currently we use __raw_readl and writel in this driver, however, there
is no strict sequencing needs for this driver, hence we should be good
with the relaxed variants.
While at it, simplify address computation using variables for register.
Signed-off-by: Nishanth Menon
---
drivers/bus/omap_l3_noc.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 1eb6d85..0d346e6 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -55,6 +55,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
int err_src = 0;
u32 std_err_main, err_reg, clear, masterid;
void __iomem *base, *l3_targ_base;
+ void __iomem *l3_targ_stderr, *l3_targ_slvofslsb, *l3_targ_mstaddr;
char *target_name, *master_name = "UN IDENTIFIED";
/* Get the Type of interrupt */
@@ -66,8 +67,8 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
* to determine the source
*/
base = l3->l3_base[i];
- err_reg = __raw_readl(base + l3_flagmux[i] +
- + L3_FLAGMUX_REGERR0 + (inttype << 3));
+ err_reg = readl_relaxed(base + l3_flagmux[i] +
+ L3_FLAGMUX_REGERR0 + (inttype << 3));
/* Get the corresponding error and analyse */
if (err_reg) {
@@ -76,10 +77,14 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
/* Read the stderrlog_main_source from clk domain */
l3_targ_base = base + *(l3_targ[i] + err_src);
- std_err_main = __raw_readl(l3_targ_base +
- L3_TARG_STDERRLOG_MAIN);
- masterid = __raw_readl(l3_targ_base +
- L3_TARG_STDERRLOG_MSTADDR);
+ l3_targ_stderr = l3_targ_base + L3_TARG_STDERRLOG_MAIN;
+ l3_targ_slvofslsb = l3_targ_base +
+ L3_TARG_STDERRLOG_SLVOFSLSB;
+ l3_targ_mstaddr = l3_targ_base +
+ L3_TARG_STDERRLOG_MSTADDR;
+
+ std_err_main = readl_relaxed(l3_targ_stderr);
+ masterid = readl_relaxed(l3_targ_mstaddr);
switch (std_err_main & CUSTOM_ERROR) {
case STANDARD_ERROR:
@@ -87,12 +92,10 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
l3_targ_inst_name[i][err_src];
WARN(true, "L3 standard error: TARGET:%s at
address 0x%x\n",
target_name,
- __raw_readl(l3_targ_base +
- L3_TARG_STDERRLOG_SLVOFSLSB));
+ readl_relaxed(l3_targ_slvofslsb));
/* clear the std error log*/
clear = std_err_main | CLEAR_STDERR_LOG;
- writel(clear, l3_targ_base +
- L3_TARG_STDERRLOG_MAIN);
+ writel_relaxed(clear, l3_targ_stderr);
break;
case CUSTOM_ERROR:
@@ -107,8 +110,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
master_name, target_name);
/* clear the std error log*/
clear = std_err_main | CLEAR_STDERR_LOG;
- writel(clear, l3_targ_base +
- L3_TARG_STDERRLOG_MAIN);
+ writel_relaxed(clear, l3_targ_stderr);
break;
default:
--
1.7.9.5
--
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: OMAP2+: free use_gptimer_clksrc variable after boot
The variable use_gptimer_clksrc is only used by two __init functions, So we can freely free it after boot. Signed-off-by: Oussama Ghorbel --- arch/arm/mach-omap2/timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 74044aa..d4a6abd 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -361,7 +361,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id, /* Clocksource code */ static struct omap_dm_timer clksrc; -static bool use_gptimer_clksrc; +static bool use_gptimer_clksrc __initdata; /* * clocksource -- 1.8.3.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 07/15] bus: omap_l3_noc: populate l3->dev and use it
l3->dev is not populated, so populate it and use it to print information
relevant to the device instead of using a generic pr_*.
Signed-off-by: Nishanth Menon
---
drivers/bus/omap_l3_noc.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 0f0417a..da4e27c 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -118,7 +118,8 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
if (std_err) {
WARN(true,
-"L3 %s Error: MASTER %s TARGET %s %s\n",
+"%s:L3 %s Error: MASTER %s TARGET %s %s\n",
+dev_name(l3->dev),
err_description,
master_name, target_name,
err_string);
@@ -143,6 +144,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
if (!l3)
return -ENOMEM;
+ l3->dev = &pdev->dev;
platform_set_drvdata(pdev, l3);
/* Get mem resources */
@@ -152,7 +154,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
l3->l3_base[i] = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(l3->l3_base[i])) {
- dev_err(&pdev->dev, "ioremap %d failed\n", i);
+ dev_err(l3->dev, "ioremap %d failed\n", i);
return PTR_ERR(l3->l3_base[i]);
}
}
@@ -161,19 +163,19 @@ static int omap4_l3_probe(struct platform_device *pdev)
* Setup interrupt Handlers
*/
l3->debug_irq = platform_get_irq(pdev, 0);
- ret = devm_request_irq(&pdev->dev, l3->debug_irq, l3_interrupt_handler,
+ ret = devm_request_irq(l3->dev, l3->debug_irq, l3_interrupt_handler,
IRQF_DISABLED, "l3-dbg-irq", l3);
if (ret) {
- dev_err(&pdev->dev, "request_irq failed for %d\n",
+ dev_err(l3->dev, "request_irq failed for %d\n",
l3->debug_irq);
return ret;
}
l3->app_irq = platform_get_irq(pdev, 1);
- ret = devm_request_irq(&pdev->dev, l3->app_irq, l3_interrupt_handler,
+ ret = devm_request_irq(l3->dev, l3->app_irq, l3_interrupt_handler,
IRQF_DISABLED, "l3-app-irq", l3);
if (ret)
- dev_err(&pdev->dev, "request_irq failed for %d\n", l3->app_irq);
+ dev_err(l3->dev, "request_irq failed for %d\n", l3->app_irq);
return ret;
}
--
1.7.9.5
--
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 10/15] bus: omap_l3_noc: remove iclk from omap_l3 struct
we do not use iclk directly anymore. And, even if we had to, we
should be using pm_runtime APIs to do the same to be completely SoC
independent.
Signed-off-by: Nishanth Menon
---
drivers/bus/omap_l3_noc.h |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
index a1931e8..573e40f 100644
--- a/drivers/bus/omap_l3_noc.h
+++ b/drivers/bus/omap_l3_noc.h
@@ -142,7 +142,6 @@ static struct l3_target_data *l3_targ[L3_MODULES] = {
struct omap_l3 {
struct device *dev;
- struct clk *ick;
/* memory base */
void __iomem *l3_base[L3_MODULES];
--
1.7.9.5
--
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 04/15] bus: omap_l3_noc: move L3 master data structure out
Move the L3 master structure out of the static definition to enable
reuse for other SoCs.
Signed-off-by: Nishanth Menon
---
drivers/bus/omap_l3_noc.h | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
index cc4b1b1..26ad279 100644
--- a/drivers/bus/omap_l3_noc.h
+++ b/drivers/bus/omap_l3_noc.h
@@ -33,6 +33,16 @@
#define NUM_OF_L3_MASTERS (sizeof(l3_masters)/sizeof(l3_masters[0]))
+/**
+ * struct l3_masters_data - L3 Master information
+ * @id:ID of the L3 Master
+ * @name: master name
+ */
+struct l3_masters_data {
+ u32 id;
+ char *name;
+};
+
static u32 l3_flagmux[L3_MODULES] = {
0x500,
0x1000,
@@ -80,10 +90,7 @@ static u32 l3_targ_inst_clk3[] = {
0x0 /* HOST CLK3 */
};
-static struct l3_masters_data {
- u32 id;
- char name[10];
-} l3_masters[] = {
+static struct l3_masters_data l3_masters[] = {
{ 0x0 , "MPU"},
{ 0x10, "CS_ADP"},
{ 0x14, "xxx"},
--
1.7.9.5
--
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 15/15] bus: omap_l3_noc: Add AM4372 interconnect error data
From: Afzal Mohammed
Add AM4372 information to handle L3 error.
AM4372 has two clk domains 100f and 200s. Provide flagmux and data
associated with it.
NOTE: Timeout doesn't have STDERRLOG_MAIN register. And per hardware
team, L3 timeout error cannot be cleared the normal way (by setting
bit 31 in STDERRLOG_MAIN), instead it may be required to do system
reset. L3 error handler can't help in such scenarios.
Hence indicate timeout target offset as L3_TARGET_NOT_SUPPORTED as
done for undocumented bits.
Signed-off-by: Dave Gerlach
Signed-off-by: Afzal Mohammed
Signed-off-by: Sekhar Nori
Signed-off-by: Nishanth Menon
---
.../devicetree/bindings/arm/omap/l3-noc.txt|1 +
drivers/bus/omap_l3_noc.c |1 +
drivers/bus/omap_l3_noc.h | 85
3 files changed, 87 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
index 45d0fc2..974624e 100644
--- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
+++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
@@ -7,6 +7,7 @@ Required properties:
- compatible : Should be "ti,omap3-l3-smx" for OMAP3 family
Should be "ti,omap4-l3-noc" for OMAP4 family
Should be "ti,dra7-l3-noc" for DRA7 family
+ Should be "ti,am4372-l3-noc" for AM43 family
- reg: Contains L3 register address range for each noc domain.
- ti,hwmods: "l3_main_1", ... One hwmod for each noc domain.
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 9b32e53..9853e1d 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -177,6 +177,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
static const struct of_device_id l3_noc_match[] = {
{.compatible = "ti,omap4-l3-noc", .data = &omap_l3_data},
{.compatible = "ti,dra7-l3-noc", .data = &dra_l3_data},
+ {.compatible = "ti,am4372-l3-noc", .data = &am4372_l3_data},
{},
};
MODULE_DEVICE_TABLE(of, l3_noc_match);
diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
index 365a33c..91814e0 100644
--- a/drivers/bus/omap_l3_noc.h
+++ b/drivers/bus/omap_l3_noc.h
@@ -339,4 +339,89 @@ static const struct omap_l3 dra_l3_data = {
.num_masters = ARRAY_SIZE(dra_l3_masters),
};
+/* AM4372 data */
+static struct l3_target_data am4372_l3_target_data_200f[] = {
+ {0xf00, "EMIF",},
+ {0x1200, "DES",},
+ {0x400, "OCMCRAM",},
+ {0x700, "TPTC0",},
+ {0x800, "TPTC1",},
+ {0x900, "TPTC2"},
+ {0xb00, "TPCC",},
+ {0xd00, "DEBUGSS",},
+ {0xdead, L3_TARGET_NOT_SUPPORTED,},
+ {0x200, "SHA",},
+ {0xc00, "SGX530",},
+ {0x500, "AES0",},
+ {0xa00, "L4_FAST",},
+ {0x300, "MPUSS_L2_RAM",},
+ {0x100, "ICSS",},
+};
+
+static struct l3_flagmux_data am4372_l3_flagmux_200f = {
+ .offset = 0x1000,
+ .l3_targ = am4372_l3_target_data_200f,
+ .num_targ_data = ARRAY_SIZE(am4372_l3_target_data_200f),
+};
+
+static struct l3_target_data am4372_l3_target_data_100s[] = {
+ {0x100, "L4_PER_0",},
+ {0x200, "L4_PER_1",},
+ {0x300, "L4_PER_2",},
+ {0x400, "L4_PER_3",},
+ {0x800, "McASP0",},
+ {0x900, "McASP1",},
+ {0xC00, "MMCHS2",},
+ {0x700, "GPMC",},
+ {0xD00, "L4_FW",},
+ {0xdead, L3_TARGET_NOT_SUPPORTED,},
+ {0x500, "ADCTSC",},
+ {0xE00, "L4_WKUP",},
+ {0xA00, "MAG_CARD",},
+};
+
+static struct l3_flagmux_data am4372_l3_flagmux_100s = {
+ .offset = 0x600,
+ .l3_targ = am4372_l3_target_data_100s,
+ .num_targ_data = ARRAY_SIZE(am4372_l3_target_data_100s),
+};
+
+static struct l3_masters_data am4372_l3_masters[] = {
+ { 0x0, "M1 (128-bit)"},
+ { 0x0, "M2 (64-bit)"},
+ { 0x4, "DAP"},
+ { 0x5, "P1500"},
+ { 0xC, "ICSS0"},
+ { 0xD, "ICSS1"},
+ { 0x18, "TPTC0 Read"},
+ { 0x19, "TPTC0 Write"},
+ { 0x1A, "TPTC1 Read"},
+ { 0x1B, "TPTC1 Write"},
+ { 0x1C, "TPTC2 Read"},
+ { 0x1D, "TPTC2 Write"},
+ { 0x20, "SGX530"},
+ { 0x25, "DSS"},
+ { 0x28, "Crypto DMA RD"},
+ { 0x29, "Crypto DMA WR"},
+ { 0x2C, "VPFE0"},
+ { 0x2D, "VPFE1"},
+ { 0x30, "GEMAC"},
+ { 0x34, "USB0 RD"},
+ { 0x35, "USB0 WR"},
+ { 0x36, "USB1 RD"},
+ { 0x37, "USB1 WR"},
+};
+
+static struct l3_flagmux_data *am4372_l3_flagmux[] = {
+ &am4372_l3_flagmux_200f,
+ &am4372_l3_flagmux_100s,
+};
+
+static const struct omap_l3 am4372_l3_data = {
+ .l3_flagmux = am4372_l3_flagmux,
+ .num_modules = ARRAY_SIZE(am4372_l3_flagmux),
+ .l3_masters = am4372_l3_masters,
+ .num_masters = ARRAY_SIZE(am4372_l3_masters),
+};
+
#endif /* __OMAP_L3_NOC_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a me
[PATCH 11/15] bus: omap_l3_noc: use of_match_data to pick up SoC information
From: Sricharan R
DRA7xx SoC has the same l3-noc interconnect ip (as OMAP4 and OMAP5), but
AM437x SoC has just 2 modules instead of 3 which other SoCs have.
So, stop using direct access of array indices and use of->match data and
simplify implementation to benefit future usage.
While at it, rename a few very generic variables to make them omap
specific. This helps us differentiate from DRA7 and AM43xx data in the
future.
NOTE: None of the platforms that use omap_l3_noc are non-device tree
anymore. So, it is safe to assume OF match here.
Signed-off-by: Sricharan R
Signed-off-by: Rajendra Nayak
[n...@ti.com: split, refactor and optimize logic]
Signed-off-by: Nishanth Menon
---
drivers/bus/omap_l3_noc.c | 50 +--
drivers/bus/omap_l3_noc.h | 72 -
2 files changed, 80 insertions(+), 42 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 6848822..3819b2f 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -14,12 +14,14 @@
* 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
+#include
+#include
#include
#include "omap_l3_noc.h"
@@ -64,13 +66,13 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
/* Get the Type of interrupt */
inttype = irq == l3->app_irq ? L3_APPLICATION_ERROR : L3_DEBUG_ERROR;
- for (i = 0; i < L3_MODULES; i++) {
+ for (i = 0; i < l3->num_modules; i++) {
/*
* Read the regerr register of the clock domain
* to determine the source
*/
base = l3->l3_base[i];
- err_reg = readl_relaxed(base + l3_flagmux[i] +
+ err_reg = readl_relaxed(base + l3->l3_flagmux[i] +
L3_FLAGMUX_REGERR0 + (inttype << 3));
/* Get the corresponding error and analyse */
@@ -83,7 +85,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
/* We DONOT expect err_src to go out of bounds */
BUG_ON(err_src >= MAX_CLKDM_TARGETS);
- l3_targ_inst = &l3_targ[i][err_src];
+ l3_targ_inst = &l3->l3_targ[i][err_src];
target_name = l3_targ_inst->name;
l3_targ_base = base + l3_targ_inst->offset;
@@ -105,7 +107,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
inttype ? "debug" : "application",
err_src, i, "(unclearable)");
- mask_reg = base + l3_flagmux[i] +
+ mask_reg = base + l3->l3_flagmux[i] +
L3_FLAGMUX_MASK0 + (inttype << 3);
mask_val = readl(mask_reg);
mask_val &= ~(1 << err_src);
@@ -124,9 +126,9 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
std_err_main = readl_relaxed(l3_targ_stderr);
masterid = readl_relaxed(l3_targ_mstaddr);
- for (k = 0; k < NUM_OF_L3_MASTERS; k++) {
- if (masterid == l3_masters[k].id)
- master_name = l3_masters[k].name;
+ for (k = 0; k < l3->num_masters; k++) {
+ if (masterid == l3->l3_masters[k].id)
+ master_name = l3->l3_masters[k].name;
}
switch (std_err_main & CUSTOM_ERROR) {
@@ -166,20 +168,34 @@ static irqreturn_t l3_interrupt_handler(int irq, void
*_l3)
return IRQ_HANDLED;
}
+static const struct of_device_id l3_noc_match[] = {
+ {.compatible = "ti,omap4-l3-noc", .data = &omap_l3_data},
+ {},
+};
+MODULE_DEVICE_TABLE(of, l3_noc_match);
+
static int omap_l3_probe(struct platform_device *pdev)
{
+ const struct of_device_id *of_id;
static struct omap_l3 *l3;
int ret, i;
+ of_id = of_match_device(l3_noc_match, &pdev->dev);
+ if (!of_id) {
+ dev_err(&pdev->dev, "OF data missing\n");
+ return -EINVAL;
+ }
+
l3 = devm_kzalloc(&pdev->dev, sizeof(*l3), GFP_KERNEL);
if (!l3)
return -ENOMEM;
+ memcpy(l3, of_id->data, sizeof(*l3));
l3->dev = &pdev->dev;
platform_set_drvdata(pdev, l3);
/* Get mem resources */
- for (i = 0; i < L3_MODULES; i++) {
+ for (i = 0; i < l3->num_modules; i++) {
struct resource *res = platform_get_resource(pdev,
IORESOURCE_MEM, i
[PATCH 05/15] bus: omap_l3_noc: convert target information into a structure
Currently the target instance information is organized indexed by bit
field offset into multiple arrays.
1. We currently have offsets specific to each target associated with each
clock domains are in seperate arrays:
l3_targ_inst_clk1
l3_targ_inst_clk2
l3_targ_inst_clk3
2. Then they are organized per master index in l3_targ.
3. We have names in l3_targ_inst_name as an array to array of strings
corresponding to the above with offsets.
Simplify the same by defining a structure for information containing
both target offset and name. this is then stored in arrays per domain
and organized into an array indexed off domain.
The array is still indexed based on bit field offset.
Signed-off-by: Nishanth Menon
---
drivers/bus/omap_l3_noc.c |9 ++--
drivers/bus/omap_l3_noc.h | 129 ++---
2 files changed, 54 insertions(+), 84 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index b39ef93..0ef8b75 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -57,6 +57,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
void __iomem *base, *l3_targ_base;
void __iomem *l3_targ_stderr, *l3_targ_slvofslsb, *l3_targ_mstaddr;
char *target_name, *master_name = "UN IDENTIFIED";
+ struct l3_target_data *l3_targ_inst;
/* Get the Type of interrupt */
inttype = irq == l3->app_irq ? L3_APPLICATION_ERROR : L3_DEBUG_ERROR;
@@ -74,9 +75,11 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
if (err_reg) {
/* Identify the source from control status register */
err_src = __ffs(err_reg);
+ l3_targ_inst = &l3_targ[i][err_src];
+ target_name = l3_targ_inst->name;
+ l3_targ_base = base + l3_targ_inst->offset;
/* Read the stderrlog_main_source from clk domain */
- l3_targ_base = base + l3_targ[i][err_src];
l3_targ_stderr = l3_targ_base + L3_TARG_STDERRLOG_MAIN;
l3_targ_slvofslsb = l3_targ_base +
L3_TARG_STDERRLOG_SLVOFSLSB;
@@ -88,8 +91,6 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
switch (std_err_main & CUSTOM_ERROR) {
case STANDARD_ERROR:
- target_name =
- l3_targ_inst_name[i][err_src];
WARN(true, "L3 standard error: TARGET:%s at
address 0x%x\n",
target_name,
readl_relaxed(l3_targ_slvofslsb));
@@ -99,8 +100,6 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
break;
case CUSTOM_ERROR:
- target_name =
- l3_targ_inst_name[i][err_src];
for (k = 0; k < NUM_OF_L3_MASTERS; k++) {
if (masterid == l3_masters[k].id)
master_name =
diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
index 26ad279..25ba99c 100644
--- a/drivers/bus/omap_l3_noc.h
+++ b/drivers/bus/omap_l3_noc.h
@@ -43,51 +43,62 @@ struct l3_masters_data {
char *name;
};
+/**
+ * struct l3_target_data - L3 Target information
+ * @offset:Offset from base for L3 Target
+ * @name: Target name
+ *
+ * Target information is organized indexed by bit field definitions.
+ */
+struct l3_target_data {
+ u32 offset;
+ char *name;
+};
+
static u32 l3_flagmux[L3_MODULES] = {
0x500,
0x1000,
0X0200
};
-/* L3 Target standard Error register offsets */
-static u32 l3_targ_inst_clk1[] = {
- 0x100, /* DMM1 */
- 0x200, /* DMM2 */
- 0x300, /* ABE */
- 0x400, /* L4CFG */
- 0x600, /* CLK2 PWR DISC */
- 0x0,/* Host CLK1 */
- 0x900 /* L4 Wakeup */
+static struct l3_target_data l3_target_inst_data_clk1[] = {
+ {0x100, "DMM1",},
+ {0x200, "DMM2",},
+ {0x300, "ABE",},
+ {0x400, "L4CFG",},
+ {0x600, "CLK2PWRDISC",},
+ {0x0, "HOSTCLK1",},
+ {0x900, "L4WAKEUP",},
};
-static u32 l3_targ_inst_clk2[] = {
- 0x500, /* CORTEX M3 */
- 0x300, /* DSS */
- 0x100, /* GPMC */
- 0x400, /* ISS */
- 0x700, /* IVAHD */
- 0xD00, /* missing in TRM corresponds to AES1*/
- 0x900, /* L4 PER0*/
- 0x200, /* OCMRAM */
- 0x100, /* missing in TRM corresponds to GPMC sERROR*/
- 0x600, /* SGX */
- 0x800, /* SL2 */
- 0x1600, /* C2C */
- 0x1100, /* missing in TRM corresponds PWR DISC CLK1*/
- 0xF00, /* missing in TRM corrsponds to SHA1*/
- 0xE00, /* missing in TR
[PATCH 00/15] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372
Hi, The following series is based on v3.15-rc1 + peter's patch series: patch #1: https://patchwork.kernel.org/patch/3923141/ (drivers: bus: omap_l3: Convert to use devm_kzalloc) patch #2: https://patchwork.kernel.org/patch/3923061/ (drivers: bus: omap_l3: Convert to use devm_ioremap_resource() ) patch #3: https://patchwork.kernel.org/patch/3923101/ (drivers: bus: omap_l3: Convert to use devm_request_irq()) patch #4: https://patchwork.kernel.org/patch/3923081/ (drivers: bus: omap_l3: Remove the platform driver's remove function) patch #5: https://patchwork.kernel.org/patch/3923121/ (drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails) This series cleansup omap_l3_noc driver and adds data to support DRA7 and AM437x SoCs. Patches(including Peter's) is available here: https://github.com/nmenon/linux-2.6-playground/commits/l3noc/driver-fixes DTS patches (once this series is integrated and related DRA7 memory map fixes are done): https://github.com/nmenon/linux-2.6-playground/commits/l3noc/dts-fixes Testing branch: everything integrated: https://github.com/nmenon/linux-2.6-playground/commits/l3noc/testing Test log: am43xx-epos: Boot PASS: http://slexy.org/raw/s2GQJIppWp DRA7xx-EVM: Boot PASS: http://slexy.org/raw/s20OfeDbO6 pandaboard-es: Boot PASS: http://slexy.org/raw/s2AZSmSYcN sdp4430: Boot PASS: http://slexy.org/raw/s2IfHAbrJA OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s21CkL8glk Afzal Mohammed (1): bus: omap_l3_noc: Add AM4372 interconnect error data Nishanth Menon (10): bus: omap_l3_noc: Fix copyright information bus: omap_l3_noc: switch over to relaxed variants of readl/writel bus: omap_l3_noc: un-obfuscate l3_targ address computation bus: omap_l3_noc: move L3 master data structure out bus: omap_l3_noc: convert target information into a structure bus: omap_l3_noc: make error reporting and handling common. bus: omap_l3_noc: populate l3->dev and use it bus: omap_l3_noc: remove iclk from omap_l3 struct bus: omap_l3_noc: convert flagmux information into a structure bus: omap_l3_noc: introduce concept of submodule Rajendra Nayak (2): bus: omap_l3_noc: Add support for discountinous flag mux input numbers bus: omap_l3_noc: Add DRA7 interconnect error data Sricharan R (2): bus: omap_l3_noc: rename functions and data to omap_l3 bus: omap_l3_noc: use of_match_data to pick up SoC information .../devicetree/bindings/arm/omap/l3-noc.txt|2 + drivers/bus/omap_l3_noc.c | 224 + drivers/bus/omap_l3_noc.h | 495 +++- 3 files changed, 517 insertions(+), 204 deletions(-) -- 1.7.9.5 -- 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 02/15] bus: omap_l3_noc: switched over to relaxed variants of readl/writel
Currently we use __raw_readl and writel in this driver, however, there
is no strict sequencing needs for this driver, hence we should be good
with the relaxed variants.
While at it, simplify address computation using variables for register.
Signed-off-by: Nishanth Menon
---
drivers/bus/omap_l3_noc.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 1eb6d85..0d346e6 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -55,6 +55,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
int err_src = 0;
u32 std_err_main, err_reg, clear, masterid;
void __iomem *base, *l3_targ_base;
+ void __iomem *l3_targ_stderr, *l3_targ_slvofslsb, *l3_targ_mstaddr;
char *target_name, *master_name = "UN IDENTIFIED";
/* Get the Type of interrupt */
@@ -66,8 +67,8 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
* to determine the source
*/
base = l3->l3_base[i];
- err_reg = __raw_readl(base + l3_flagmux[i] +
- + L3_FLAGMUX_REGERR0 + (inttype << 3));
+ err_reg = readl_relaxed(base + l3_flagmux[i] +
+ L3_FLAGMUX_REGERR0 + (inttype << 3));
/* Get the corresponding error and analyse */
if (err_reg) {
@@ -76,10 +77,14 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
/* Read the stderrlog_main_source from clk domain */
l3_targ_base = base + *(l3_targ[i] + err_src);
- std_err_main = __raw_readl(l3_targ_base +
- L3_TARG_STDERRLOG_MAIN);
- masterid = __raw_readl(l3_targ_base +
- L3_TARG_STDERRLOG_MSTADDR);
+ l3_targ_stderr = l3_targ_base + L3_TARG_STDERRLOG_MAIN;
+ l3_targ_slvofslsb = l3_targ_base +
+ L3_TARG_STDERRLOG_SLVOFSLSB;
+ l3_targ_mstaddr = l3_targ_base +
+ L3_TARG_STDERRLOG_MSTADDR;
+
+ std_err_main = readl_relaxed(l3_targ_stderr);
+ masterid = readl_relaxed(l3_targ_mstaddr);
switch (std_err_main & CUSTOM_ERROR) {
case STANDARD_ERROR:
@@ -87,12 +92,10 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
l3_targ_inst_name[i][err_src];
WARN(true, "L3 standard error: TARGET:%s at
address 0x%x\n",
target_name,
- __raw_readl(l3_targ_base +
- L3_TARG_STDERRLOG_SLVOFSLSB));
+ readl_relaxed(l3_targ_slvofslsb));
/* clear the std error log*/
clear = std_err_main | CLEAR_STDERR_LOG;
- writel(clear, l3_targ_base +
- L3_TARG_STDERRLOG_MAIN);
+ writel_relaxed(clear, l3_targ_stderr);
break;
case CUSTOM_ERROR:
@@ -107,8 +110,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
master_name, target_name);
/* clear the std error log*/
clear = std_err_main | CLEAR_STDERR_LOG;
- writel(clear, l3_targ_base +
- L3_TARG_STDERRLOG_MAIN);
+ writel_relaxed(clear, l3_targ_stderr);
break;
default:
--
1.7.9.5
--
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 14/15] bus: omap_l3_noc: Add DRA7 interconnect error data
From: Rajendra Nayak
DRA7 is distinctly different from OMAP4 in terms of masters and clock
domain organization. There two main clock domains which is divided as
follows:
<0x4400 0x100> is clk1 and clk2 is the sub clock domain
<0x4500 0x1000> is clk3
Add all the data needed to handle L3 error handling on DRA7 devices
and mark clk2 as subdomain and provide a compatible flag for
functionality. Other than the data difference the hardware blocks
involved are essentially the same.
Signed-off-by: Rajendra Nayak
[n...@ti.com: bugfixes and generic improvements, documentation]
Signed-off-by: Nishanth Menon
---
.../devicetree/bindings/arm/omap/l3-noc.txt|1 +
drivers/bus/omap_l3_noc.c |1 +
drivers/bus/omap_l3_noc.h | 133
3 files changed, 135 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
index c0105de..45d0fc2 100644
--- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
+++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
@@ -6,6 +6,7 @@ provided by Arteris.
Required properties:
- compatible : Should be "ti,omap3-l3-smx" for OMAP3 family
Should be "ti,omap4-l3-noc" for OMAP4 family
+ Should be "ti,dra7-l3-noc" for DRA7 family
- reg: Contains L3 register address range for each noc domain.
- ti,hwmods: "l3_main_1", ... One hwmod for each noc domain.
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 5e2a89d..9b32e53 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -176,6 +176,7 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
static const struct of_device_id l3_noc_match[] = {
{.compatible = "ti,omap4-l3-noc", .data = &omap_l3_data},
+ {.compatible = "ti,dra7-l3-noc", .data = &dra_l3_data},
{},
};
MODULE_DEVICE_TABLE(of, l3_noc_match);
diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
index 592821f..365a33c 100644
--- a/drivers/bus/omap_l3_noc.h
+++ b/drivers/bus/omap_l3_noc.h
@@ -206,4 +206,137 @@ static const struct omap_l3 omap_l3_data = {
.num_masters = ARRAY_SIZE(omap_l3_masters),
};
+/* DRA7 data */
+static struct l3_target_data dra_l3_target_data_clk1[] = {
+ {0xdead, L3_TARGET_NOT_SUPPORTED,},
+ {0x0200, "DMM_P1",},
+ {0x0600, "DSP2_SDMA",},
+ {0x0b00, "EVE2",},
+ {0x1300, "DMM_P2",},
+ {0xdead, L3_TARGET_NOT_SUPPORTED,},
+ {0x0300, "DSP1_SDMA",},
+ {0x0a00, "EVE1",},
+ {0x0c00, "EVE3",},
+ {0x0d00, "EVE4",},
+ {0x2900, "DSS",},
+ {0x0100, "GPMC",},
+ {0x3700, "PCIE1",},
+ {0x1600, "IVA_CONFIG",},
+ {0x1800, "IVA_SL2IF",},
+ {0x0500, "L4_CFG",},
+ {0x1d00, "L4_WKUP",},
+ {0x3800, "PCIE2",},
+ {0xdead, L3_TARGET_NOT_SUPPORTED,},
+ {0x1200, "GPU",},
+ {0x1000, "IPU1",},
+ {0x1100, "IPU2",},
+ {0x2000, "TPCC_EDMA",},
+ {0x2e00, "TPTC1_EDMA",},
+ {0x2b00, "TPTC2_EDMA",},
+ {0x0700, "VCP1",},
+ {0x2500, "L4_PER2_P3",},
+ {0x0e00, "L4_PER3_P3",},
+ {0x2200, "MMU1",},
+ {0x1400, "PRUSS1",},
+};
+
+static struct l3_flagmux_data dra_l3_flagmux_clk1 = {
+ .offset = 0x803500,
+ .l3_targ = dra_l3_target_data_clk1,
+ .num_targ_data = ARRAY_SIZE(dra_l3_target_data_clk1),
+};
+
+static struct l3_target_data dra_l3_target_data_clk2[] = {
+ {0x0, "RT_CLK1_1",},
+ {0xdead, L3_TARGET_NOT_SUPPORTED,},
+ {0xdead, L3_TARGET_NOT_SUPPORTED,},
+ {0xdead, L3_TARGET_NOT_SUPPORTED,},
+ {0x0900, "BB2D",},
+ {0xdead, L3_TARGET_NOT_SUPPORTED,},
+ {0x2100, "L4_PER1_P3",},
+ {0x1c00, "L4_PER1_P1",},
+ {0x1f00, "L4_PER1_P2",},
+ {0x2300, "L4_PER2_P1",},
+ {0x2400, "L4_PER2_P2",},
+ {0x2600, "L4_PER3_P1",},
+ {0x2700, "L4_PER3_P2",},
+ {0x2f00, "MCASP1",},
+ {0xdead, L3_TARGET_NOT_SUPPORTED,},
+ {0xdead, L3_TARGET_NOT_SUPPORTED,},
+ {0x2800, "MMU2",},
+ {0x0f00, "OCMC_RAM1",},
+ {0x1700, "OCMC_RAM2",},
+ {0x1900, "OCMC_RAM3",},
+ {0xdead, L3_TARGET_NOT_SUPPORTED,},
+ {0x3900, "QSPI",},
+};
+
+static struct l3_flagmux_data dra_l3_flagmux_clk2 = {
+ .offset = 0x803600,
+ .l3_targ = dra_l3_target_data_clk2,
+ .num_targ_data = ARRAY_SIZE(dra_l3_target_data_clk2),
+};
+
+static struct l3_target_data dra_l3_target_data_clk3[] = {
+ {0x0100, "L3_INSTR"},
+ {0x0300, "DEBUGSS_CT_TBR"},
+ {0x0,"HOST CLK3"},
+};
+
+static struct l3_flagmux_data dra_l3_flagmux_clk3 = {
+ .offset = 0x200,
+ .l3_targ = dra_l3_target_data_clk3,
+ .num_targ_data = ARRAY_SIZE(dra_l3_target_data_clk3),
+};
+
+static struct l3_masters_data dra_l3_masters[] = {
+ { 0x0, "MPU" },
+ { 0x4, "CS_DAP" },
+ { 0x8, "DSP1
[PATCH 08/15] bus: omap_l3_noc: Add support for discountinous flag mux input numbers
From: Rajendra Nayak
On DRA7, unlike on OMAP4 and OMAP5, the flag mux input numbers used
to indicate the source of errors are not continous. Have a way in the
driver to catch these and WARN the user of the flag mux input thats
either undocumented or wrong.
In the similar vein, Timeout errors in AM43x can't be cleared per h/w
team, neither does it have a STDERRLOG_MAIN to clear the error.
Further, the mux bit offset might not even be indexed into our array
of known mux input description, in which case we'd have a abort.
So, define a static range check for bit description and any definition
which has target_name set to NULL (the ones that are not populated or
ones that are specifically marked in the case of discontinous input
numbers), can handle the same gracefully. Upon occurance of error from
such sources, mask it. Otherwise, we'd have an infinite interrupt
source without any means to clear it.
[n...@ti.com: rebase, squash and improve]
Signed-off-by: Rajendra Nayak
Signed-off-by: Afzal Mohammed
Signed-off-by: Nishanth Menon
---
drivers/bus/omap_l3_noc.c | 31 +++
drivers/bus/omap_l3_noc.h | 11 ---
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index da4e27c..c2b0cc3 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -79,10 +79,41 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
/* Identify the source from control status register */
err_src = __ffs(err_reg);
+
+ /* We DONOT expect err_src to go out of bounds */
+ BUG_ON(err_src >= MAX_CLKDM_TARGETS);
+
l3_targ_inst = &l3_targ[i][err_src];
target_name = l3_targ_inst->name;
l3_targ_base = base + l3_targ_inst->offset;
+ /*
+* If we do not know of a register offset to decode
+* and clear, then mask.
+*/
+ if (target_name == L3_TARGET_NOT_SUPPORTED) {
+ u32 mask_val;
+ void __iomem *mask_reg;
+
+ /*
+* Certain plaforms may have "undocumented"
+* status pending on boot.. So dont generate
+* a severe warning here.
+*/
+ dev_err(l3->dev,
+ "L3 %s error: target %d mod:%d %s\n",
+ inttype ? "debug" : "application",
+ err_src, i, "(unclearable)");
+
+ mask_reg = base + l3_flagmux[i] +
+ L3_FLAGMUX_MASK0 + (inttype << 3);
+ mask_val = readl(mask_reg);
+ mask_val &= ~(1 << err_src);
+ writel(mask_val, mask_reg);
+
+ break;
+ }
+
/* Read the stderrlog_main_source from clk domain */
l3_targ_stderr = l3_targ_base + L3_TARG_STDERRLOG_MAIN;
l3_targ_slvofslsb = l3_targ_base +
diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
index 25ba99c..c4a1760 100644
--- a/drivers/bus/omap_l3_noc.h
+++ b/drivers/bus/omap_l3_noc.h
@@ -30,6 +30,11 @@
#define L3_TARG_STDERRLOG_SLVOFSLSB0x5c
#define L3_TARG_STDERRLOG_MSTADDR 0x68
#define L3_FLAGMUX_REGERR0 0xc
+#define L3_FLAGMUX_MASK0 0x8
+
+#define L3_TARGET_NOT_SUPPORTEDNULL
+
+#define MAX_CLKDM_TARGETS 30
#define NUM_OF_L3_MASTERS (sizeof(l3_masters)/sizeof(l3_masters[0]))
@@ -61,7 +66,7 @@ static u32 l3_flagmux[L3_MODULES] = {
0X0200
};
-static struct l3_target_data l3_target_inst_data_clk1[] = {
+static struct l3_target_data l3_target_inst_data_clk1[MAX_CLKDM_TARGETS] = {
{0x100, "DMM1",},
{0x200, "DMM2",},
{0x300, "ABE",},
@@ -71,7 +76,7 @@ static struct l3_target_data l3_target_inst_data_clk1[] = {
{0x900, "L4WAKEUP",},
};
-static struct l3_target_data l3_target_inst_data_clk2[] = {
+static struct l3_target_data l3_target_inst_data_clk2[MAX_CLKDM_TARGETS] = {
{0x500, "CORTEXM3",},
{0x300, "DSS",},
{0x100, "GPMC",},
@@ -95,7 +100,7 @@ static struct l3_target_data l3_target_inst_data_clk2[] = {
{0x1700, "LLI",},
};
-static struct l3_target_data l3_target_inst_data_clk3[] = {
+static struct l3_target_data l3_target_inst_data_clk3[MAX_CLKDM_TARGETS] = {
{0x0100, "EMUSS",},
{0x0300, "DEBUG SOURCE",},
{0x0, "HOST CLK3",},
--
1.7.9.5
--
To unsubscribe from this list: send
[PATCH 06/15] bus: omap_l3_noc: make error reporting and handling common.
The logic between handling CUSTOM_ERROR and STANDARD_ERROR
is just the reporting style.
So make it generic, simplify and standardize the reporting
with both master and target information printed to log.
While at it, fix a minor formatting error.
Signed-off-by: Nishanth Menon
---
drivers/bus/omap_l3_noc.c | 47 -
1 file changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 0ef8b75..0f0417a 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -58,6 +58,8 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
void __iomem *l3_targ_stderr, *l3_targ_slvofslsb, *l3_targ_mstaddr;
char *target_name, *master_name = "UN IDENTIFIED";
struct l3_target_data *l3_targ_inst;
+ char *err_description;
+ char err_string[30] = { 0 };
/* Get the Type of interrupt */
inttype = irq == l3->app_irq ? L3_APPLICATION_ERROR : L3_DEBUG_ERROR;
@@ -73,6 +75,8 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
/* Get the corresponding error and analyse */
if (err_reg) {
+ bool std_err = true;
+
/* Identify the source from control status register */
err_src = __ffs(err_reg);
l3_targ_inst = &l3_targ[i][err_src];
@@ -89,35 +93,42 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
std_err_main = readl_relaxed(l3_targ_stderr);
masterid = readl_relaxed(l3_targ_mstaddr);
+ for (k = 0; k < NUM_OF_L3_MASTERS; k++) {
+ if (masterid == l3_masters[k].id)
+ master_name = l3_masters[k].name;
+ }
+
switch (std_err_main & CUSTOM_ERROR) {
case STANDARD_ERROR:
- WARN(true, "L3 standard error: TARGET:%s at
address 0x%x\n",
- target_name,
- readl_relaxed(l3_targ_slvofslsb));
- /* clear the std error log*/
- clear = std_err_main | CLEAR_STDERR_LOG;
- writel_relaxed(clear, l3_targ_stderr);
+ err_description = "Standard";
+ snprintf(err_string, sizeof(err_string),
+": At Address: 0x%08X",
+readl_relaxed(l3_targ_slvofslsb));
break;
case CUSTOM_ERROR:
- for (k = 0; k < NUM_OF_L3_MASTERS; k++) {
- if (masterid == l3_masters[k].id)
- master_name =
- l3_masters[k].name;
- }
- WARN(true, "L3 custom error: MASTER:%s
TARGET:%s\n",
- master_name, target_name);
- /* clear the std error log*/
- clear = std_err_main | CLEAR_STDERR_LOG;
- writel_relaxed(clear, l3_targ_stderr);
+ err_description = "Custom";
break;
default:
+ std_err = false;
/* Nothing to be handled here as of now */
break;
}
- /* Error found so break the for loop */
- break;
+
+ if (std_err) {
+ WARN(true,
+"L3 %s Error: MASTER %s TARGET %s %s\n",
+err_description,
+master_name, target_name,
+err_string);
+ /* clear the std error log*/
+ clear = std_err_main | CLEAR_STDERR_LOG;
+ writel_relaxed(clear, l3_targ_stderr);
+ }
+
+ /* Error found so break the for loop */
+ break;
}
}
return IRQ_HANDLED;
--
1.7.9.5
--
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 02/15] bus: omap_l3_noc: switched over to relaxed variants of readl/writel
On 04/14/2014 11:25 AM, Nishanth Menon wrote: Please ignore this one patch from the series, there is a replacement patch already posted as part of the series... this stale patch got through :( -- Regards, 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 v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On Monday 14 April 2014 06:11 PM, Peter Ujfalusi wrote:
> 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?
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.
>>> 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.
Thanks,
Sekhar
--
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: L3 custom error on OMAP4460
On Saturday 12 April 2014 05:06 PM, Joachim Eastwood wrote: > Hi, > > I getting the following error on Linus master right now. > > [ 2.166320] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:113 > l3_interrupt_handler+0xf4/0x154() > [ 2.166320] L3 custom error: MASTER:MPU TARGET:L4 PER2 > [ 2.166320] Modules linked in: > [ 2.166351] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.14.0-12542-gfb5ce8367c24 #11 > [ 2.166381] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 2.166381] [] (show_stack) from [] (dump_stack+0x84/0x94) > [ 2.166412] [] (dump_stack) from [] > (warn_slowpath_common+0x70/0x8c) > [ 2.166412] [] (warn_slowpath_common) from [] > (warn_slowpath_fmt+0x30/0x40) > [ 2.166412] [] (warn_slowpath_fmt) from [] > (l3_interrupt_handler+0xf4/0x154) > [ 2.166442] [] (l3_interrupt_handler) from [] > (handle_irq_event_percpu+0x54/0x1cc) > [ 2.166473] [] (handle_irq_event_percpu) from [] > (handle_irq_event+0x3c/0x5c) > [ 2.166473] [] (handle_irq_event) from [] > (handle_fasteoi_irq+0xac/0x1a0) > [ 2.166473] [] (handle_fasteoi_irq) from [] > (generic_handle_irq+0x2c/0x3c) > [ 2.166503] [] (generic_handle_irq) from [] > (handle_IRQ+0x40/0x90) > [ 2.166503] [] (handle_IRQ) from [] > (gic_handle_irq+0x2c/0x5c) > [ 2.166534] [] (gic_handle_irq) from [] > (__irq_svc+0x44/0x58) > [ 2.166534] Exception stack(0xc087bf58 to 0xc087bfa0) > [ 2.166534] bf40: 0001 0001 > [ 2.166534] bf60: c08856f8 c087a000 c087a000 c08d9544 > c0882548 c087a000 ee7ffc40 > [ 2.166564] bf80: c08824e0 c05b9cec c087bfa0 c007a0f0 > c000eda8 2113 > [ 2.166564] [] (__irq_svc) from [] > (arch_cpu_idle+0x24/0x30) > [ 2.166595] [] (arch_cpu_idle) from [] > (cpu_startup_entry+0x138/0x204) > [ 2.166595] [] (cpu_startup_entry) from [] > (start_kernel+0x370/0x37c) > [ 2.166625] [] (start_kernel) from [<80008074>] (0x80008074) > > Not sure what to make of it. Anyone got any idea? > > Right before the L3 custom WARN I also get these messages from the > des/aes crypot drivers. Might be unrelated, though. > [ 2.134643] omap-aes 4b501000.aes: _od_fail_runtime_resume: FIXME: > missing hwmod/omap_dev info > [ 2.143737] omap-aes 4b501000.aes: omap_aes_probe: failed to get_sync(-19) > [ 2.151000] omap-aes 4b501000.aes: initialization failed. > [ 2.157196] omap-des 480a5000.des: _od_fail_runtime_resume: FIXME: > missing hwmod/omap_dev info > [ 2.166290] omap-des 480a5000.des: OMAP DES hw accel rev: 0.0 > > The hardware is a VAR-STK-OM44 dev kit. I got one patch on top of > Linus master which is the DT support patch which I posted a couple of > hours ago. > Have you tried removing AES from the build ? Probably worth a try. Regards, Santosh -- 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
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
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. So on a reasonably less loaded system, I am sure you
could run audio even with a lower priority DMA queue.
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.
> 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.
Thanks,
Sekhar
--
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
[PATCH v2 02/13] Documentation: update charger-manager devicetree bindings
This patch changes charger-manager bindings to be compatible with
new extcon bindings.
Signed-off-by: Robert Baldyga
---
.../bindings/power_supply/charger-manager.txt | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/power_supply/charger-manager.txt
b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
index 2b33750..f987bb5 100644
--- a/Documentation/devicetree/bindings/power_supply/charger-manager.txt
+++ b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
@@ -10,8 +10,7 @@ Required properties :
- subnode :
- cm-regulator-name : name of charger regulator
- subnode :
- - cm-cable-name : name of charger cable
- - cm-cable-extcon : name of extcon dev
+ - extcon-cable : specified extcon cable
(optional) - cm-cable-min : minimum current of cable
(optional) - cm-cable-max : maximum current of cable
@@ -65,14 +64,14 @@ Example :
regulator@0 {
cm-regulator-name = "chg-reg";
cable@0 {
- cm-cable-name = "USB";
- cm-cable-extcon = "extcon-dev.0";
+ /* USB cable */
+ extcon-cable = <&extcon 0>;
cm-cable-min = <475000>;
cm-cable-max = <50>;
};
cable@1 {
- cm-cable-name = "TA";
- cm-cable-extcon = "extcon-dev.0";
+ /* TA cable */
+ extcon-cable = <&extcon 1>;
cm-cable-min = <65>;
cm-cable-max = <675000>;
};
--
1.7.9.5
--
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 01/13] Documentation: add extcon devicetree bindings
This patch adds extcon devicetree bindings. Documentation describes in general
client and provider bindings, and contains detailed desctiprion of bindings
for each extcon provider.
Signed-off-by: Robert Baldyga
---
.../devicetree/bindings/extcon/extcon-adc-jack.txt | 60 +++
.../devicetree/bindings/extcon/extcon-arizona.txt | 47 +++
.../devicetree/bindings/extcon/extcon-bindings.txt | 36 +++
.../devicetree/bindings/extcon/extcon-gpio.txt | 63
.../devicetree/bindings/extcon/extcon-max14577.txt | 49 +++
.../devicetree/bindings/extcon/extcon-max77693.txt | 56 +
.../devicetree/bindings/extcon/extcon-max8997.txt | 49 +++
.../devicetree/bindings/extcon/extcon-palmas.txt | 37 ++--
8 files changed, 393 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-arizona.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-bindings.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max14577.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max77693.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max8997.txt
diff --git a/Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt
b/Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt
new file mode 100644
index 000..6e43891
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt
@@ -0,0 +1,60 @@
+* ADC JACK Extcon Controller
+
+ADC JACK extcon controller is responsible for cable detection.
+
+Required Properties:
+
+- compatible: should be "extcon-adc-jack".
+
+- #extcon-cells: should be 1.
+
+- subnode : node describing list of cables.
+ - subnode :
+ - cable-name: name of specific cable
+ - adc-min: minimum specific cable ADC values range
+ - adc-max: maximum specific cable ADC values range
+
+Subnodes of node 'cables' describes specific cables with ADC value ranges
+associated with this cables. When measured ADC value will be between min and
+max value for specific cable, clients will be notified about connection of
+this cable. Value ranges for individual cables cannot be overlaping.
+
+Example 1: An example of a extcon controller node is listed below.
+
+ extcon: adc-jack {
+ compatible = "extcon-adc-jack";
+ #extcon-cells = <1>;
+
+ cables {
+ cable@0 {
+ cable-name = "CABLE-0";
+ adc-min = 120;
+ adc-max = 240;
+ }
+ cable@1 {
+ cable-name = "CABLE-1";
+ adc-min = 250;
+ adc-max = 400;
+ }
+ cable@2 {
+ cable-name = "CABLE-2";
+ adc-min = 500;
+ adc-max = 700;
+ };
+ };
+ };
+
+Example 2: USB controller node that uses cable from the extcon
+ controller. Refer to the standard extcon bindings for
+ information about 'extcon-cables' and 'extcon-names'
+ property.
+
+ usb@1248 {
+ vusb_d-supply = <&vusb_reg>;
+ vusb_a-supply = <&vusbdac_reg>;
+
+ extcon-cables = <&extcon 0>;
+ extcon-names = "USB";
+
+ status = "okay";
+ };
diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
new file mode 100644
index 000..9af4422
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
@@ -0,0 +1,47 @@
+* Wolfson Arizona Extcon Controller
+
+The Wolfson Arizona Extcon Controller is responsible for cable
+detection.
+
+Required Properties:
+
+- compatible: should be "wlf,arizona-extcon".
+
+- #extcon-cells: should be 1.
+
+The following is the list of cables detected by the controller. Each
+cable is assigned an identifier and client nodes use this identifies
+to specify the cable which they are interested in.
+
+ CableID
+
+
+ Mechanical 0
+ Microphone 1
+ Headphone2
+ Line-out 3
+
+Example 1: An example of a extcon controller node is listed below.
+
+ extcon: arizona-extcon {
+ compatible = "wlf,arizona-extcon";
+ #extcon-cells = <1>;
+ };
+
+Example 2: Audio controller node that uses cable from the extcon
+ controller. Refer to the standard extcon bi
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 v2 03/13] extcon: extcon-class: remove extcon_set_cable_state() function
This patch removes extcon_set_cable_state() and replace all calls of
this function witch extcon_set_cable_state_(), which is faster version.
This is first step of changing extcon API to faster and safer.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-class.c| 17
drivers/extcon/extcon-max14577.c | 24 ++--
drivers/extcon/extcon-max77693.c | 79 +++---
drivers/extcon/extcon-max8997.c | 32 +--
drivers/extcon/extcon-palmas.c | 27 +
include/linux/extcon.h |8
6 files changed, 99 insertions(+), 88 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index a45c5e9..1b98c4e 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -358,23 +358,6 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
/**
- * extcon_set_cable_state() - Set the status of a specific cable.
- * @edev: the extcon device that has the cable.
- * @cable_name:cable name.
- * @cable_state: the new cable status. The default semantics is
- * true: attached / false: detached.
- *
- * Note that this is slower than extcon_set_cable_state_.
- */
-int extcon_set_cable_state(struct extcon_dev *edev,
- const char *cable_name, bool cable_state)
-{
- return extcon_set_cable_state_(edev, extcon_find_cable_index
- (edev, cable_name), cable_state);
-}
-EXPORT_SYMBOL_GPL(extcon_set_cable_state);
-
-/**
* extcon_get_extcon_dev() - Get the extcon device instance from the name
* @extcon_name: The extcon name provided with extcon_dev_register()
*/
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 3846941..7a947d3 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -333,7 +333,7 @@ static int max14577_muic_get_cable_type(struct
max14577_muic_info *info,
static int max14577_muic_jig_handler(struct max14577_muic_info *info,
int cable_type, bool attached)
{
- char cable_name[32];
+ int cable;
int ret = 0;
u8 path = CTRL1_SW_OPEN;
@@ -344,17 +344,17 @@ static int max14577_muic_jig_handler(struct
max14577_muic_info *info,
switch (cable_type) {
case MAX14577_MUIC_ADC_FACTORY_MODE_USB_OFF:/* ADC_JIG_USB_OFF */
/* PATH:AP_USB */
- strcpy(cable_name, "JIG-USB-OFF");
+ cable = EXTCON_CABLE_JIG_USB_OFF;
path = CTRL1_SW_USB;
break;
case MAX14577_MUIC_ADC_FACTORY_MODE_USB_ON: /* ADC_JIG_USB_ON */
/* PATH:AP_USB */
- strcpy(cable_name, "JIG-USB-ON");
+ cable = EXTCON_CABLE_JIG_USB_ON;
path = CTRL1_SW_USB;
break;
case MAX14577_MUIC_ADC_FACTORY_MODE_UART_OFF: /* ADC_JIG_UART_OFF */
/* PATH:AP_UART */
- strcpy(cable_name, "JIG-UART-OFF");
+ cable = EXTCON_CABLE_JIG_UART_OFF;
path = CTRL1_SW_UART;
break;
default:
@@ -367,7 +367,7 @@ static int max14577_muic_jig_handler(struct
max14577_muic_info *info,
if (ret < 0)
return ret;
- extcon_set_cable_state(info->edev, cable_name, attached);
+ extcon_set_cable_state_(info->edev, cable, attached);
return 0;
}
@@ -464,20 +464,22 @@ static int max14577_muic_chg_handler(struct
max14577_muic_info *info)
if (ret < 0)
return ret;
- extcon_set_cable_state(info->edev, "USB", attached);
+ extcon_set_cable_state_(info->edev, EXTCON_CABLE_USB, attached);
break;
case MAX14577_CHARGER_TYPE_DEDICATED_CHG:
- extcon_set_cable_state(info->edev, "TA", attached);
+ extcon_set_cable_state_(info->edev, EXTCON_CABLE_TA, attached);
break;
case MAX14577_CHARGER_TYPE_DOWNSTREAM_PORT:
- extcon_set_cable_state(info->edev,
- "Charge-downstream", attached);
+ extcon_set_cable_state_(info->edev,
+ EXTCON_CABLE_CHARGE_DOWNSTREAM, attached);
break;
case MAX14577_CHARGER_TYPE_SPECIAL_500MA:
- extcon_set_cable_state(info->edev, "Slow-charger", attached);
+ extcon_set_cable_state_(info->edev,
+ EXTCON_CABLE_SLOW_CHARGER, attached);
break;
case MAX14577_CHARGER_TYPE_SPECIAL_1A:
- extcon_set_cable_state(info->edev, "Fast-charger", attached);
+ extcon_set_cable_state_(info->edev,
+ EXTCON_CABLE_FAST_CHARGER, attached);
break;
case MAX14577_CH
[PATCH v2 04/13] extcon: extcon-class: match extcon device by devicetree node
This patch modifies extcon_get_edev_by_phandle() function, to match
extcon device by devicetree node. This modification needed to add
field 'node' in extcon_dev structure, and fill it in probe function
of each extcon provider driver.
This patch adds function of_extcon_get_extcon_dev(),
returning extcon device which contains given devicetree node.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-adc-jack.c |1 +
drivers/extcon/extcon-arizona.c |1 +
drivers/extcon/extcon-class.c| 21 -
drivers/extcon/extcon-gpio.c |1 +
drivers/extcon/extcon-max14577.c |2 ++
drivers/extcon/extcon-max77693.c |1 +
drivers/extcon/extcon-max8997.c |1 +
drivers/extcon/extcon-palmas.c |1 +
include/linux/extcon.h |2 ++
9 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index e23f1c2..d65915e 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -111,6 +111,7 @@ static int adc_jack_probe(struct platform_device *pdev)
}
data->edev.dev.parent = &pdev->dev;
+ data->edev.node = pdev->dev.of_node;
data->edev.supported_cable = pdata->cable_names;
/* Check the length of array and set num_cables */
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 98a14f6..fc69cca 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1153,6 +1153,7 @@ static int arizona_extcon_probe(struct platform_device
*pdev)
info->edev.name = "Headset Jack";
info->edev.dev.parent = arizona->dev;
+ info->edev.node = pdev->dev.of_node;
info->edev.supported_cable = arizona_cable;
ret = extcon_dev_register(&info->edev);
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 1b98c4e..b0d9c90 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -377,6 +377,25 @@ out:
}
EXPORT_SYMBOL_GPL(extcon_get_extcon_dev);
+/**
+ * of_extcon_get_extcon_dev() - Get the extcon device instance from the name
+ * @np: The node of extcon device
+ */
+struct extcon_dev *of_extcon_get_extcon_dev(const struct device_node *np)
+{
+ struct extcon_dev *edev;
+
+ mutex_lock(&extcon_dev_list_lock);
+ list_for_each_entry(edev, &extcon_dev_list, entry) {
+ if (edev->node == np)
+ goto out;
+ }
+ edev = NULL;
+out:
+ mutex_unlock(&extcon_dev_list_lock);
+ return edev;
+}
+
static int _call_per_cable(struct notifier_block *nb, unsigned long val,
void *ptr)
{
@@ -827,7 +846,7 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct device
*dev, int index)
return ERR_PTR(-ENODEV);
}
- edev = extcon_get_extcon_dev(node->name);
+ edev = of_extcon_get_extcon_dev(node);
if (!edev) {
dev_err(dev, "unable to get extcon device : %s\n", node->name);
return ERR_PTR(-ENODEV);
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 13d5222..fc90b7a 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -100,6 +100,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
extcon_data->edev.name = pdata->name;
extcon_data->edev.dev.parent = &pdev->dev;
+ extcon_data->edev.node = pdev->dev.of_node;
extcon_data->gpio = pdata->gpio;
extcon_data->gpio_active_low = pdata->gpio_active_low;
extcon_data->state_on = pdata->state_on;
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 7a947d3..b017a0d 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -676,6 +676,8 @@ static int max14577_muic_probe(struct platform_device *pdev)
return -ENOMEM;
}
info->edev->name = DEV_NAME;
+ info->edev->dev.parent = &pdev->dev;
+ info->edev->node = pdev->dev.of_node;
info->edev->supported_cable = max14577_extcon_cable;
ret = extcon_dev_register(info->edev);
if (ret) {
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 7a014cd..2cd8892 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -1200,6 +1200,7 @@ static int max77693_muic_probe(struct platform_device
*pdev)
}
info->edev->name = DEV_NAME;
info->edev->dev.parent = &pdev->dev;
+ info->edev->node = pdev->dev.of_node;
info->edev->supported_cable = max77693_extcon_cable;
ret = extcon_dev_register(info->edev);
if (ret) {
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index a3df70d..c071588 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -718,6 +718,7 @@ static int max8997_m
[PATCH v2 06/13] extcon: extcon-class: remove unused functions
This patch removes two functions, extcon_find_cable_index() and
extcon_get_edev_by_phandle(). They are not longer needed, since
extcon client API has changed to be oriented on extcon_cable instead
of extcon_dev.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-class.c | 67 -
include/linux/extcon.h| 18 ---
2 files changed, 85 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index cd830b0..40a33e2 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -283,32 +283,6 @@ int extcon_set_state(struct extcon_dev *edev, u32 state)
EXPORT_SYMBOL_GPL(extcon_set_state);
/**
- * extcon_find_cable_index() - Get the cable index based on the cable name.
- * @edev: the extcon device that has the cable.
- * @cable_name:cable name to be searched.
- *
- * Note that accessing a cable state based on cable_index is faster than
- * cable_name because using cable_name induces a loop with strncmp().
- * Thus, when get/set_cable_state is repeatedly used, using cable_index
- * is recommended.
- */
-int extcon_find_cable_index(struct extcon_dev *edev, const char *cable_name)
-{
- int i;
-
- if (edev->supported_cable) {
- for (i = 0; edev->supported_cable[i]; i++) {
- if (!strncmp(edev->supported_cable[i],
- cable_name, CABLE_NAME_MAX))
- return i;
- }
- }
-
- return -EINVAL;
-}
-EXPORT_SYMBOL_GPL(extcon_find_cable_index);
-
-/**
* extcon_get_cable_state_() - Get the status of a specific cable.
* @edev: the extcon device that has the cable.
* @index: cable index that can be retrieved by extcon_find_cable_index().
@@ -923,47 +897,6 @@ void extcon_dev_unregister(struct extcon_dev *edev)
}
EXPORT_SYMBOL_GPL(extcon_dev_unregister);
-#ifdef CONFIG_OF
-/*
- * extcon_get_edev_by_phandle - Get the extcon device from devicetree
- * @dev - instance to the given device
- * @index - index into list of extcon_dev
- *
- * return the instance of extcon device
- */
-struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
-{
- struct device_node *node;
- struct extcon_dev *edev;
-
- if (!dev->of_node) {
- dev_err(dev, "device does not have a device node entry\n");
- return ERR_PTR(-EINVAL);
- }
-
- node = of_parse_phandle(dev->of_node, "extcon", index);
- if (!node) {
- dev_err(dev, "failed to get phandle in %s node\n",
- dev->of_node->full_name);
- return ERR_PTR(-ENODEV);
- }
-
- edev = of_extcon_get_extcon_dev(node);
- if (!edev) {
- dev_err(dev, "unable to get extcon device : %s\n", node->name);
- return ERR_PTR(-ENODEV);
- }
-
- return edev;
-}
-#else
-struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
-{
- return ERR_PTR(-ENOSYS);
-}
-#endif /* CONFIG_OF */
-EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
-
static int __init extcon_class_init(void)
{
return create_extcon_class();
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index bc680a9..28e60fb 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -210,8 +210,6 @@ extern int extcon_update_state(struct extcon_dev *edev, u32
mask, u32 state);
* They are used to access the status of each cable based on the cable_name
tt or cable_index, which is retrieved by extcon_find_cable_index
*/
-extern int extcon_find_cable_index(struct extcon_dev *sdev,
- const char *cable_name);
extern int extcon_get_cable_state_(struct extcon_dev *edev, int cable_index);
extern int extcon_set_cable_state_(struct extcon_dev *edev,
int cable_index, bool cable_state);
@@ -255,11 +253,6 @@ extern int extcon_register_notifier(struct extcon_dev
*edev,
extern int extcon_unregister_notifier(struct extcon_dev *edev,
struct notifier_block *nb);
-/*
- * Following API get the extcon device from devicetree.
- * This function use phandle of devicetree to get extcon device directly.
- */
-extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int
index);
#else /* CONFIG_EXTCON */
static inline int extcon_dev_register(struct extcon_dev *edev)
{
@@ -284,12 +277,6 @@ static inline int extcon_update_state(struct extcon_dev
*edev, u32 mask,
return 0;
}
-static inline int extcon_find_cable_index(struct extcon_dev *edev,
- const char *cable_name)
-{
- return 0;
-}
-
static inline int extcon_get_cable_state_(struct extcon_dev *edev,
int cable_index)
{
@@ -351,10 +338,5 @@ static inline int extcon_unregister_interest(struct
extcon_cable_nb
[PATCH v2 05/13] extcon: extcon-class: improve extcon client API
This patch improves extcon client API to get rid of ugly functions operating
on name strings. It gives independency from naming convention in extcon
provider drivers. Names given at provider registration are now used only
for sysfs, debugs, and to support platforms using legacy devicetree bindings.
>From now individual cables are specified in devicetree, so client API has
changed from extcon_dev oriented to extcon_cable oriented. Added also some
minor modifications to simplify interest registration.
The extcon_specific_cable_nb structure has been changed to extcon_cable_nb.
Now this is the only struct which has to be supplied by client. Pointer to
user_nb has been changed to extcon_notifier_fn_t to simplify interest
registation process.
Each single cable is represented by struct extcon_cable. Pointer to
extcon_cable is returned from functions:
of_extcon_get_cable_by_index() - Return cable of given index.
of_extcon_get_cable() - Return cable by name defined in devicetree.
extcon_get_cable() - Similar to of_extcon_get_cable_by_name(),
but it takes struct device instead of struct device_node.
extcon_get_cable_by_name() - return specified cable form extcon device
found by name. It's for use in drivers without devicetree support,
and shouldn't be used in new drivers.
Function extcon_register_interest() has been changed. Registration is now
not based on cable name string, but on pointer to struct extcon_cable.
Also extcon_get_cable_state() function has been changed. Now it takes
pointer to struct extcon_cable.
This patch modifies all client drivers to make it using new extcon API.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-class.c | 246 +++--
drivers/power/charger-manager.c | 36 +++--
drivers/usb/dwc3/dwc3-omap.c | 68 -
drivers/usb/phy/phy-omap-otg.c| 70 +-
include/linux/extcon.h| 104 --
include/linux/power/charger-manager.h |6 +-
6 files changed, 331 insertions(+), 199 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index b0d9c90..cd830b0 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -324,15 +324,14 @@ EXPORT_SYMBOL_GPL(extcon_get_cable_state_);
/**
* extcon_get_cable_state() - Get the status of a specific cable.
- * @edev: the extcon device that has the cable.
- * @cable_name:cable name.
- *
- * Note that this is slower than extcon_get_cable_state_.
+ * @cable: the cable.
*/
-int extcon_get_cable_state(struct extcon_dev *edev, const char *cable_name)
+int extcon_get_cable_state(struct extcon_cable *cable)
{
- return extcon_get_cable_state_(edev, extcon_find_cable_index
- (edev, cable_name));
+ if (!cable)
+ return -ENODEV;
+
+ return !!(cable->edev->state & (1 << cable->cable_index));
}
EXPORT_SYMBOL_GPL(extcon_get_cable_state);
@@ -358,28 +357,27 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
/**
- * extcon_get_extcon_dev() - Get the extcon device instance from the name
+ * extcon_get_extcon_dev_by_name() - Get the extcon device instance from the
name
* @extcon_name: The extcon name provided with extcon_dev_register()
*/
-struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name)
+struct extcon_dev *extcon_get_extcon_dev_by_name(const char *extcon_name)
{
- struct extcon_dev *sd;
+ struct extcon_dev *edev;
mutex_lock(&extcon_dev_list_lock);
- list_for_each_entry(sd, &extcon_dev_list, entry) {
- if (!strcmp(sd->name, extcon_name))
+ list_for_each_entry(edev, &extcon_dev_list, entry) {
+ if (!strcmp(edev->name, extcon_name))
goto out;
}
- sd = NULL;
+ edev = NULL;
out:
mutex_unlock(&extcon_dev_list_lock);
- return sd;
+ return edev;
}
-EXPORT_SYMBOL_GPL(extcon_get_extcon_dev);
/**
* of_extcon_get_extcon_dev() - Get the extcon device instance from the name
- * @np: The node of extcon device
+ * @np:The node of extcon device
*/
struct extcon_dev *of_extcon_get_extcon_dev(const struct device_node *np)
{
@@ -396,24 +394,158 @@ out:
return edev;
}
+/**
+ * of_extcon_get_cable() - Get specified extcon cable instance from devicetree
+ * @np:The node of extcon device
+ */
+struct extcon_cable *of_extcon_get_cable_by_index(struct device_node *np, int
index)
+{
+ struct of_phandle_args extcon_spec;
+ struct extcon_dev *edev;
+ struct extcon_cable *cable;
+ int ret;
+
+ if (index < 0)
+ return ERR_PTR(-EINVAL);
+
+ ret = of_parse_phandle_with_args(np, "extcon-cables", "#extcon-cells",
+ index, &extcon_spec);
+ if (ret)
+ return ERR
[PATCH v2 07/13] extcon: extcon-class: improve get_cable_state_()/set_cable_state_() functions
Added check if pointer to edev is not NULL, and updated documentation of index
parameter. Function extcon_find_cable_index() has been deleted and cannot be
used to retrieve cable number.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-class.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 40a33e2..e9e5e85 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -285,10 +285,12 @@ EXPORT_SYMBOL_GPL(extcon_set_state);
/**
* extcon_get_cable_state_() - Get the status of a specific cable.
* @edev: the extcon device that has the cable.
- * @index: cable index that can be retrieved by extcon_find_cable_index().
+ * @index: cable index in extcon device.
*/
int extcon_get_cable_state_(struct extcon_dev *edev, int index)
{
+ if (!edev)
+ return -ENODEV;
if (index < 0 || (edev->max_supported && edev->max_supported <= index))
return -EINVAL;
@@ -312,8 +314,7 @@ EXPORT_SYMBOL_GPL(extcon_get_cable_state);
/**
* extcon_set_cable_state_() - Set the status of a specific cable.
* @edev: the extcon device that has the cable.
- * @index: cable index that can be retrieved by
- * extcon_find_cable_index().
+ * @index: cable index in extcon device.
* @cable_state: the new cable status. The default semantics is
* true: attached / false: detached.
*/
@@ -322,6 +323,8 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
{
u32 state;
+ if (!edev)
+ return -ENODEV;
if (index < 0 || (edev->max_supported && edev->max_supported <= index))
return -EINVAL;
--
1.7.9.5
--
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 08/13] extcon: extcon-class: simplify extcon_updata_state() function
This patch simplifies extcon_updata_state() function. There is greatly
simplified kobject_uevent preparation. Also meaning of variable passed
to raw_notifier_call_chain() (and in effect to _call_per_cable()) has
changed. Now positions on ones in variable 'val' in _call_per_cable()
indicates numbers of cables which changed their status. It allowed
to simplify also _call_per_cable() function.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-class.c | 81 -
include/linux/extcon.h|1 -
2 files changed, 31 insertions(+), 51 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index e9e5e85..13993c6 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -206,59 +206,48 @@ int extcon_update_state(struct extcon_dev *edev, u32
mask, u32 state)
{
char name_buf[120];
char state_buf[120];
- char *prop_buf;
+ char *tmp;
char *envp[3];
int env_offset = 0;
int length;
unsigned long flags;
+ u32 change;
spin_lock_irqsave(&edev->lock, flags);
- if (edev->state != ((edev->state & ~mask) | (state & mask))) {
- u32 old_state = edev->state;
-
- if (check_mutually_exclusive(edev, (edev->state & ~mask) |
- (state & mask))) {
+ change = (edev->state & mask) ^ (state & mask);
+ if (change) {
+ if (check_mutually_exclusive(edev, edev->state ^ change)) {
spin_unlock_irqrestore(&edev->lock, flags);
return -EPERM;
}
- edev->state &= ~mask;
- edev->state |= state & mask;
-
- raw_notifier_call_chain(&edev->nh, old_state, edev);
- /* This could be in interrupt handler */
- prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
- if (prop_buf) {
- length = name_show(&edev->dev, NULL, prop_buf);
- if (length > 0) {
- if (prop_buf[length - 1] == '\n')
- prop_buf[length - 1] = 0;
- snprintf(name_buf, sizeof(name_buf),
- "NAME=%s", prop_buf);
- envp[env_offset++] = name_buf;
- }
- length = state_show(&edev->dev, NULL, prop_buf);
- if (length > 0) {
- if (prop_buf[length - 1] == '\n')
- prop_buf[length - 1] = 0;
- snprintf(state_buf, sizeof(state_buf),
- "STATE=%s", prop_buf);
- envp[env_offset++] = state_buf;
- }
- envp[env_offset] = NULL;
- /* Unlock early before uevent */
- spin_unlock_irqrestore(&edev->lock, flags);
+ edev->state ^= change;
- kobject_uevent_env(&edev->dev.kobj, KOBJ_CHANGE, envp);
- free_page((unsigned long)prop_buf);
- } else {
- /* Unlock early before uevent */
- spin_unlock_irqrestore(&edev->lock, flags);
+ raw_notifier_call_chain(&edev->nh, change, edev);
+
+ tmp = name_buf + sprintf(name_buf, "NAME=");
+ length = name_show(&edev->dev, NULL, tmp);
+ if (length > 0) {
+ if (tmp[length - 1] == '\n')
+ tmp[length - 1] = 0;
+ envp[env_offset++] = name_buf;
+ }
- dev_err(&edev->dev, "out of memory in
extcon_set_state\n");
- kobject_uevent(&edev->dev.kobj, KOBJ_CHANGE);
+ tmp = state_buf + sprintf(state_buf, "STATE=");
+ length = state_show(&edev->dev, NULL, tmp);
+ if (length > 0) {
+ if (tmp[length - 1] == '\n')
+ tmp[length - 1] = 0;
+ envp[env_offset++] = state_buf;
}
+
+ envp[env_offset] = NULL;
+
+ /* Unlock early before uevent */
+ spin_unlock_irqrestore(&edev->lock, flags);
+
+ kobject_uevent_env(&edev->dev.kobj, KOBJ_CHANGE, envp);
} else {
/* No changes */
spin_unlock_irqrestore(&edev->lock, flags);
@@ -511,18 +500,10 @@ static int _call_per_cable(struct notifier_block *nb,
unsigned long val,
{
struct extcon_cable_nb *obj = container_of(nb,
struct extcon_cable_nb, internal_nb);
- struct extcon_dev *edev = ptr;
-
- if ((val & (1 << obj->cable->cable_index)) !=
-
[PATCH v2 09/13] extcon: extcon-class: move example to Documentation
This patch removes cable array example form extcon code, to avoid
littering driver namespace. Now it's located in extcon documentation.
Signed-off-by: Robert Baldyga
---
Documentation/extcon/extcon.txt | 112 +++
drivers/extcon/extcon-class.c | 32 ---
include/linux/extcon.h | 42 ---
3 files changed, 112 insertions(+), 74 deletions(-)
create mode 100644 Documentation/extcon/extcon.txt
diff --git a/Documentation/extcon/extcon.txt b/Documentation/extcon/extcon.txt
new file mode 100644
index 000..1d5be2f
--- /dev/null
+++ b/Documentation/extcon/extcon.txt
@@ -0,0 +1,112 @@
+Extcon - external connector
+===
+
+Extcon is generic framework used for notifying client drivers
+about specific cable connections and disconnections.
+
+Provider API
+
+
+Providers API consists of very few functions:
+
+extcon_dev_register() - register new extcon provider
+extcon_dev_unregister() - unregister extcon provider
+
+extcon_get_cable_state_() - get specific cable state
+extcon_set_cable_state_() - set specific cable state
+
+extcon_update_state() - update entire extcon state
+extcon_set_state() - set entire extcon state
+
+There are few fields in struct extcon_dev to be filled before passing it
+to extcon_dev_register() functions:
+
+name - name of extcon controller
+node - devicetree node of parent device
+supported_cable - array of strings with cable names ended with NULL pointer
+
+Example of cable array definition example can be found below:
+
+ enum extcon_cable_name {
+ EXTCON_USB = 0,
+ EXTCON_USB_HOST,
+ EXTCON_TA,
+ EXTCON_FAST_CHARGER,
+ EXTCON_SLOW_CHARGER,
+ EXTCON_CHARGE_DOWNSTREAM,
+ EXTCON_HDMI,
+ EXTCON_MHL,
+ EXTCON_DVI,
+ EXTCON_VGA,
+ EXTCON_DOCK,
+ EXTCON_LINE_IN,
+ EXTCON_LINE_OUT,
+ EXTCON_MIC_IN,
+ EXTCON_HEADPHONE_OUT,
+ EXTCON_SPDIF_IN,
+ EXTCON_SPDIF_OUT,
+ EXTCON_VIDEO_IN,
+ EXTCON_VIDEO_OUT,
+ EXTCON_MECHANICAL,
+ };
+
+ const char *extcon_cable_name[] = {
+ [EXTCON_USB]= "USB",
+ [EXTCON_USB_HOST] = "USB-Host",
+ [EXTCON_TA] = "TA",
+ [EXTCON_FAST_CHARGER] = "Fast-charger",
+ [EXTCON_SLOW_CHARGER] = "Slow-charger",
+ [EXTCON_CHARGE_DOWNSTREAM] = "Charge-downstream",
+ [EXTCON_HDMI] = "HDMI",
+ [EXTCON_MHL]= "MHL",
+ [EXTCON_DVI]= "DVI",
+ [EXTCON_VGA]= "VGA",
+ [EXTCON_DOCK] = "Dock",
+ [EXTCON_LINE_IN]= "Line-in",
+ [EXTCON_LINE_OUT] = "Line-out",
+ [EXTCON_MIC_IN] = "Microphone",
+ [EXTCON_HEADPHONE_OUT] = "Headphone",
+ [EXTCON_SPDIF_IN] = "SPDIF-in",
+ [EXTCON_SPDIF_OUT] = "SPDIF-out",
+ [EXTCON_VIDEO_IN] = "Video-in",
+ [EXTCON_VIDEO_OUT] = "Video-out",
+ [EXTCON_MECHANICAL] = "Mechanical",
+ };
+
+Cable name strings are used for debug messages and sysfs.
+
+After extcon device registration you can use functions modifying extcon state.
+If any extcon clients will register their interests in some cables, they will
+recieve notifications about cable state changes.
+
+Client API
+==
+
+Extcon client API is also pretty simple. It consists of funtions:
+
+of_extcon_get_cable_by_index() - returns extcon_cable at selected index
+of_extcon_get_cable() - returns extcon_cable associated with
+ selected name
+extcon_get_cable() - the same as above, but takes struct device
+instead of struct device_node
+extcon_det_cable_by_name() - return specified cable form extcon device
+found by name. It's for use in drivers without
+devicetree support, and shouldn't be used in
+new drivers.
+
+extcon_register_interest() - register interest in selected cable
+extcon_unregister_interest() - unregister cable interest
+
+extcon_get_cable_state() - get state of given cable
+
+The extcon_register_interest() function takes three parameters,
+struct extcon_cable, struct extcon_cable_nb and extcon_notifier_fn_t
+which is pointer to callback function called when cable state changes.
+
+There are also two functions:
+
+extcon_register_notifier() - register notifier for entire extcon state
+extcon_unregister_notifier() - unregister such notifier
+
+But they should be used only for debug, and use of them in client drivers
+is not recommended.
diff --git a/drivers/extc
[PATCH v2 10/13] extcon: extcon-gpio: add devicetree support
This patch modifies extcon-gpio driver to use initialization data from
devicetree if platform data is not available. It allows to set controller
and cable names, and another parameters from devicetree bindings.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-gpio.c | 70 +++-
include/linux/extcon/extcon-gpio.h |2 +-
2 files changed, 62 insertions(+), 10 deletions(-)
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index fc90b7a..ef05bcb 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -28,6 +28,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -53,7 +55,7 @@ static void gpio_extcon_work(struct work_struct *work)
state = gpio_get_value(data->gpio);
if (data->gpio_active_low)
state = !state;
- extcon_set_state(&data->edev, state);
+ extcon_set_cable_state_(&data->edev, 0, state);
}
static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
@@ -70,7 +72,7 @@ static ssize_t extcon_gpio_print_state(struct extcon_dev
*edev, char *buf)
struct gpio_extcon_data *extcon_data =
container_of(edev, struct gpio_extcon_data, edev);
const char *state;
- if (extcon_get_state(edev))
+ if (extcon_get_cable_state_(edev, 0))
state = extcon_data->state_on;
else
state = extcon_data->state_off;
@@ -80,17 +82,57 @@ static ssize_t extcon_gpio_print_state(struct extcon_dev
*edev, char *buf)
return -EINVAL;
}
+#ifdef CONFIG_OF
+static struct gpio_extcon_platform_data *get_pdata_from_dt(struct device *dev)
+{
+ int ret;
+ struct gpio_extcon_platform_data *pdata =
+ devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+
+ ret = of_property_read_string_index(dev->of_node,
+ "gpio-controller-name", 0, &pdata->name);
+ if (ret)
+ return NULL;
+
+ ret = of_property_read_string_index(dev->of_node,
+ "gpio-cable-name", 0, &pdata->cable_name);
+ if (ret)
+ return NULL;
+
+ ret = of_property_read_u32_array(dev->of_node,
+ "gpio-debounce", &pdata->debounce, 0);
+ if (ret)
+ pdata->debounce = 0;
+
+ pdata->gpio = of_get_gpio(dev->of_node, 0);
+ if (pdata->gpio < 0)
+ return NULL;
+
+ pdata->gpio_active_low = of_property_read_bool(dev->of_node,
+ "gpio-active-low");
+
+ pdata->check_on_resume = of_property_read_bool(dev->of_node,
+ "check-on-resume");
+ return pdata;
+}
+#else
+static struct gpio_extcon_platform_data *get_pdata_from_dt(struct device *dev)
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
static int gpio_extcon_probe(struct platform_device *pdev)
{
struct gpio_extcon_platform_data *pdata = dev_get_platdata(&pdev->dev);
struct gpio_extcon_data *extcon_data;
+ const char *gpio_extcon_cable[2];
int ret;
- if (!pdata)
- return -EBUSY;
- if (!pdata->irq_flags) {
- dev_err(&pdev->dev, "IRQ flag is not specified.\n");
- return -EINVAL;
+ if (!pdata) {
+ pdata = get_pdata_from_dt(&pdev->dev);
+ if (!pdata)
+ return -EINVAL;
}
extcon_data = devm_kzalloc(&pdev->dev, sizeof(struct gpio_extcon_data),
@@ -98,10 +140,14 @@ static int gpio_extcon_probe(struct platform_device *pdev)
if (!extcon_data)
return -ENOMEM;
+ gpio_extcon_cable[0] = pdata->cable_name;
+ gpio_extcon_cable[1] = NULL;
+
extcon_data->edev.name = pdata->name;
extcon_data->edev.dev.parent = &pdev->dev;
extcon_data->edev.node = pdev->dev.of_node;
extcon_data->gpio = pdata->gpio;
+ extcon_data->edev.supported_cable = gpio_extcon_cable;
extcon_data->gpio_active_low = pdata->gpio_active_low;
extcon_data->state_on = pdata->state_on;
extcon_data->state_off = pdata->state_off;
@@ -135,8 +181,8 @@ static int gpio_extcon_probe(struct platform_device *pdev)
}
ret = request_any_context_irq(extcon_data->irq, gpio_irq_handler,
- pdata->irq_flags, pdev->name,
- extcon_data);
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
+ pdev->name, extcon_data);
if (ret < 0)
goto err;
@@ -177,6 +223,11 @@ static int gpio_extcon_resume(struct device *dev)
}
#endif
+static struct of_device_id of_gpio_match_tbl[] = {
+ { .compatible = "extcon-gpio", },
+ { /* end */ },
+};
+
static SIMPLE_DEV_PM_OPS(gpio_extcon_pm_ops, NULL, gpio_extcon_resume);
static struct platfor
[PATCH v2 12/13] extcon: extcon-max8997: check if pdata exists
This patch adds check if pdata is NULL, to avoid NULL pointer dereference
when platform data is not available. After this changes, in described
situation driver will be configured with default values.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-max8997.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index c071588..d7d12e9 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -726,7 +726,7 @@ static int max8997_muic_probe(struct platform_device *pdev)
goto err_irq;
}
- if (pdata->muic_pdata) {
+ if (pdata && pdata->muic_pdata) {
struct max8997_muic_platform_data *muic_pdata
= pdata->muic_pdata;
--
1.7.9.5
--
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 13/13] extcon: extcon-max77693: check if pdata exists
This patch adds check if pdata is NULL, to avoid NULL pointer dereference
when platform data is not available. After this changes, in described
situation driver will be configured with default values.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-max77693.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 2cd8892..fa8534e 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -1210,7 +1210,7 @@ static int max77693_muic_probe(struct platform_device
*pdev)
/* Initialize MUIC register by using platform data or default data */
- if (pdata->muic_data) {
+ if (pdata && pdata->muic_data) {
init_data = pdata->muic_data->init_data;
num_init_data = pdata->muic_data->num_init_data;
} else {
--
1.7.9.5
--
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 11/13] extcon: extcon-adc-jack: add devicetree support
This patch modifies extcon-adc-jack driver to use initialization data from
devicetree, when platform data is not available. It allows to define cable list
with ADC value ranges for each of them in devicetree bindings.
Signed-off-by: Robert Baldyga
---
drivers/extcon/extcon-adc-jack.c | 81 ++
1 file changed, 81 insertions(+)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index d65915e..f1a1399 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -92,12 +93,85 @@ static irqreturn_t adc_jack_irq_thread(int irq, void *_data)
return IRQ_HANDLED;
}
+#ifdef CONFIG_OF
+static struct adc_jack_pdata *get_pdata_from_dt(struct device *dev)
+{
+ int ret, cnt, i;
+ struct device_node *cables_np, *child;
+ struct adc_jack_pdata *pdata =
+ devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+
+ ret = of_property_read_string_index(dev->of_node,
+ "adc-name", 0, &pdata->name);
+ if (ret)
+ return NULL;
+
+ ret = of_property_read_string_index(dev->of_node,
+ "adc-consumer-channel", 0, &pdata->consumer_channel);
+ if (ret)
+ return NULL;
+
+ cables_np = of_find_node_by_name(dev->of_node, "cables");
+ if (!cables_np)
+ return NULL;
+
+ cnt = of_get_child_count(cables_np);
+ if (cnt <= 0)
+ return NULL;
+
+ pdata->cable_names = devm_kcalloc(dev, cnt+1,
+ sizeof(*pdata->cable_names), GFP_KERNEL);
+ if (!pdata->cable_names)
+ return NULL;
+
+ pdata->adc_conditions = devm_kcalloc(dev, cnt+1,
+ sizeof(*pdata->adc_conditions), GFP_KERNEL);
+ if (!pdata->adc_conditions)
+ return NULL;
+
+ i = 0;
+ for_each_child_of_node(cables_np, child) {
+ ret = of_property_read_string_index(child,
+ "cable-name", 0, &pdata->cable_names[i]);
+ if (ret)
+ return NULL;
+
+ pdata->adc_conditions[i].state = (1adc_conditions[i].max_adc, 0);
+ if (ret)
+ return NULL;
+
+ i++;
+ }
+
+ return pdata;
+}
+#else
+static struct adc_jack_pdata *get_pdata_from_dt(struct device *dev)
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
static int adc_jack_probe(struct platform_device *pdev)
{
struct adc_jack_data *data;
struct adc_jack_pdata *pdata = dev_get_platdata(&pdev->dev);
int i, err = 0;
+ if (!pdata) {
+ pdata = get_pdata_from_dt(&pdev->dev);
+ if (!pdata)
+ return -EINVAL;
+ }
+
data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
@@ -188,11 +262,18 @@ static int adc_jack_remove(struct platform_device *pdev)
return 0;
}
+static struct of_device_id of_adc_jack_match_tbl[] = {
+ { .compatible = "extcon-adc-jack", },
+ { /* end */ },
+};
+
+
static struct platform_driver adc_jack_driver = {
.probe = adc_jack_probe,
.remove = adc_jack_remove,
.driver = {
.name = "adc-jack",
+ .of_match_table = of_adc_jack_match_tbl,
.owner = THIS_MODULE,
},
};
--
1.7.9.5
--
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 00/13] extcon: major rework
This patchset adds many improvements to extcon class driver and extcon provider drivers. It changes extcon API to faster and safer by replaceing function taking extcon and cable names with functions working with structures representing this objects. It adds more advanced devicetree support which allows to pass specified cables to client drivers. It gives independency from cable naming conventions in individual extcon provider drivers, and allows to simply connect client drivers with providers in way that being transpatent for both of them. It adds also some minor fixes like additional checks for safety increase, and another improvements. Also added some improvements to extcon provider drivers, improved devicetree support and updated them to use faster extcon API. Patches contains also documentation for extcon, and devicetree bindings for all provider drivers. More details can be found in commit messages and Documentation. Best regards Robert Baldyga Samsung R&D Institute Poland Changelog: v2: - add support for platforms without devicetree support - update Documentation v1: https://lkml.org/lkml/2014/4/10/603 Robert Baldyga (13): Documentation: add extcon devicetree bindings Documentation: update charger-manager devicetree bindings extcon: extcon-class: remove extcon_set_cable_state() function extcon: extcon-class: match extcon device by devicetree node extcon: extcon-class: improve extcon client API extcon: extcon-class: remove unused functions extcon: extcon-class: improve get_cable_state_()/set_cable_state_() functions extcon: extcon-class: simplify extcon_updata_state() function extcon: extcon-class: move example to Documentation extcon: extcon-gpio: add devicetree support extcon: extcon-adc-jack: add devicetree support extcon: extcon-max8997: check if pdata exists extcon: extcon-max77693: check if pdata exists .../devicetree/bindings/extcon/extcon-adc-jack.txt | 60 +++ .../devicetree/bindings/extcon/extcon-arizona.txt | 47 ++ .../devicetree/bindings/extcon/extcon-bindings.txt | 36 ++ .../devicetree/bindings/extcon/extcon-gpio.txt | 63 +++ .../devicetree/bindings/extcon/extcon-max14577.txt | 49 +++ .../devicetree/bindings/extcon/extcon-max77693.txt | 56 +++ .../devicetree/bindings/extcon/extcon-max8997.txt | 49 +++ .../devicetree/bindings/extcon/extcon-palmas.txt | 37 +- .../bindings/power_supply/charger-manager.txt | 11 +- Documentation/extcon/extcon.txt| 112 + drivers/extcon/extcon-adc-jack.c | 82 drivers/extcon/extcon-arizona.c|1 + drivers/extcon/extcon-class.c | 451 ++-- drivers/extcon/extcon-gpio.c | 71 ++- drivers/extcon/extcon-max14577.c | 26 +- drivers/extcon/extcon-max77693.c | 82 ++-- drivers/extcon/extcon-max8997.c| 35 +- drivers/extcon/extcon-palmas.c | 28 +- drivers/power/charger-manager.c| 36 +- drivers/usb/dwc3/dwc3-omap.c | 68 +-- drivers/usb/phy/phy-omap-otg.c | 70 +-- include/linux/extcon.h | 165 +++ include/linux/extcon/extcon-gpio.h |2 +- include/linux/power/charger-manager.h |6 +- 24 files changed, 1136 insertions(+), 507 deletions(-) create mode 100644 Documentation/devicetree/bindings/extcon/extcon-adc-jack.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-arizona.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-bindings.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max14577.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max77693.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-max8997.txt create mode 100644 Documentation/extcon/extcon.txt -- 1.7.9.5 -- 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: [alsa-devel] [PATCH RFC v2 0/2] Fix simple-card *-master DT parameter handling
On 04/14/2014 08:07 AM, Kuninori Morimoto wrote: Hi Jyri, Mark ... Could you please teach me current status of this patch ? Hi, This patch-set was never merged as such. Instead there is another patch-set that has been applied by Mark to cover this issue [1]. The patch maintains backward compatibility, with the Nicolin Chen's patch [2]. In other words, old style "bitclock-master" and "frame-master" boolean parameters are read from the codec node if they can not be found from the top level node. The backward compatibility does not apply to multi-link [3] configurations. Best regards, Jyri [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074717.html [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074219.html [3] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074592.html ps. The discussions that lead to the current solution can be found here: http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074388.html -- 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
Add helpers to use GPIOs to control modem lines and implement omap_serial.c
Patches for this feature were already submitted and should land in 3.15 after rc1 (http://www.spinics.net/lists/linux-serial/msg12114.html). Is anyone working on this feature for OMAP? Yegor -- 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] dma: edma: fix incorrect SG list handling
On Monday 14 April 2014 02:27 PM, Vinod Koul wrote: > On Mon, Apr 14, 2014 at 02:01:11PM +0530, Sekhar Nori wrote: >> Vinod, >> >> On Wednesday 19 March 2014 11:25 AM, Sekhar Nori wrote: >>> The code to handle any length SG lists calls edma_resume() >>> even before edma_start() is called. This is incorrect >>> because edma_resume() enables edma events on the channel >>> after which CPU (in edma_start) cannot clear posted >>> events by writing to ECR (per the EDMA user's guide). >>> >>> Because of this EDMA transfers fail to start if due >>> to some reason there is a pending EDMA event registered >>> even before EDMA transfers are started. This can happen if >>> an EDMA event is a byproduct of device initialization. >>> >>> Fix this by calling edma_resume() only if it is not the >>> first batch of MAX_NR_SG elements. >>> >>> Without this patch, MMC/SD fails to function on DA850 EVM >>> with DMA. The behaviour is triggered by specific IP and >>> this can explain why the issue was not reported before >>> (example with MMC/SD on AM335x). >>> >>> Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card. >>> >>> Cc: sta...@vger.kernel.org # v3.12.x+ >>> Cc: Joel Fernandes >>> Acked-by: Joel Fernandes >>> Tested-by: Jon Ringle >>> Tested-by: Alexander Holler >>> Reported-by: Jon Ringle >>> Signed-off-by: Sekhar Nori >> >> Looks like this patch is not in mainline still? > > Sorry looks like I have missed sending the email. I had applied it last week > and > today rebased after rc1. It would be part of rc2... Thank you! Regards, Sekhar -- 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] dma: edma: fix incorrect SG list handling
On Mon, Apr 14, 2014 at 02:01:11PM +0530, Sekhar Nori wrote: > Vinod, > > On Wednesday 19 March 2014 11:25 AM, Sekhar Nori wrote: > > The code to handle any length SG lists calls edma_resume() > > even before edma_start() is called. This is incorrect > > because edma_resume() enables edma events on the channel > > after which CPU (in edma_start) cannot clear posted > > events by writing to ECR (per the EDMA user's guide). > > > > Because of this EDMA transfers fail to start if due > > to some reason there is a pending EDMA event registered > > even before EDMA transfers are started. This can happen if > > an EDMA event is a byproduct of device initialization. > > > > Fix this by calling edma_resume() only if it is not the > > first batch of MAX_NR_SG elements. > > > > Without this patch, MMC/SD fails to function on DA850 EVM > > with DMA. The behaviour is triggered by specific IP and > > this can explain why the issue was not reported before > > (example with MMC/SD on AM335x). > > > > Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card. > > > > Cc: sta...@vger.kernel.org # v3.12.x+ > > Cc: Joel Fernandes > > Acked-by: Joel Fernandes > > Tested-by: Jon Ringle > > Tested-by: Alexander Holler > > Reported-by: Jon Ringle > > Signed-off-by: Sekhar Nori > > Looks like this patch is not in mainline still? Sorry looks like I have missed sending the email. I had applied it last week and today rebased after rc1. It would be part of rc2... -- ~Vinod > > Thanks, > Sekhar -- -- 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] dma: edma: fix incorrect SG list handling
Vinod, On Wednesday 19 March 2014 11:25 AM, Sekhar Nori wrote: > The code to handle any length SG lists calls edma_resume() > even before edma_start() is called. This is incorrect > because edma_resume() enables edma events on the channel > after which CPU (in edma_start) cannot clear posted > events by writing to ECR (per the EDMA user's guide). > > Because of this EDMA transfers fail to start if due > to some reason there is a pending EDMA event registered > even before EDMA transfers are started. This can happen if > an EDMA event is a byproduct of device initialization. > > Fix this by calling edma_resume() only if it is not the > first batch of MAX_NR_SG elements. > > Without this patch, MMC/SD fails to function on DA850 EVM > with DMA. The behaviour is triggered by specific IP and > this can explain why the issue was not reported before > (example with MMC/SD on AM335x). > > Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card. > > Cc: sta...@vger.kernel.org # v3.12.x+ > Cc: Joel Fernandes > Acked-by: Joel Fernandes > Tested-by: Jon Ringle > Tested-by: Alexander Holler > Reported-by: Jon Ringle > Signed-off-by: Sekhar Nori Looks like this patch is not in mainline still? Thanks, Sekhar -- 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] ARM: AM33xx: hwmod: Add INIT_NO_IDLE flag for debugss hwmod
Hi Paul, On Friday 11 April 2014 11:39 PM, Paul Walmsley wrote: > On Fri, 11 Apr 2014, Paul Walmsley wrote: > >> On Wed, 9 Apr 2014, Lokesh Vutla wrote: >> >>> During boot, when hwmod tries to cut clocks for debugss it always >>> gets stuck in transition state and throws the following warning: >>> >>> [0.139581] omap_hwmod: debugss: _wait_target_disable failed >>> >>> As per the information provided by folks, clocks to debugss cannot be cut. >>> So adding HWMOD_INIT_NO_IDLE flag to debugss hwmod. >>> >>> Signed-off-by: Lokesh Vutla >> >> Thanks, queued for v3.15-rc. > > Hmmm. On second thought, this doesn't look like the right fix. Could > you please comment on the issues raised here: > > https://patchwork.kernel.org/patch/2212111/ Yes, I initially created a driver for enabling and disabling clocks for DEBUGSS. But I always see that DEBUGSS is always stuck in transition whenever clocks are cut to DEBUGSS. During boot also when hwmod tries to cut clocks the following warning comes: [0.139581] omap_hwmod: debugss: _wait_target_disable failed. As confirmed by the hardware team that this is a bug in silicon that clocks cannot be cut to DEBUGSS. So I am just adding HWMOD_INIT_NO_IDLE flag to debugss hwmod. I have also tested suspend-resume with $subject patch with TI internal tree. Please let me know if I am not clear. Thanks and regards, Lokesh > > Looks to me like there should be at least one device driver, either for > the entire DEBUGSS, or for the individual IP blocks inside the DEBUGSS. > > Dropping this patch for now. > > > - Paul > -- 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] ARM: dts: omap5: Add clocks to USB3 PHY node
Hi Tony, On 04/01/2014 05:13 PM, Felipe Balbi wrote: > On Tue, Apr 01, 2014 at 01:37:27PM +0300, Roger Quadros wrote: >> The USB3 PHY driver (ti-pipe3) was updated so that the relevant >> clock phandles are expected in the DT node. >> Provide the necessary clocks. >> >> Reported-by: Kishon Vijay Abraham I >> Signed-off-by: Roger Quadros > > Great!!! > > Acked-by: Felipe Balbi Could you please pick this up for 3.15-rc? Thanks. cheers, -roger > >> --- >> arch/arm/boot/dts/omap5.dtsi | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi >> index 757f0b9..4df1e7a 100644 >> --- a/arch/arm/boot/dts/omap5.dtsi >> +++ b/arch/arm/boot/dts/omap5.dtsi >> @@ -794,6 +794,12 @@ >><0x4a084c00 0x40>; >> reg-names = "phy_rx", "phy_tx", "pll_ctrl"; >> ctrl-module = <&omap_control_usb3phy>; >> +clocks = <&usb_phy_cm_clk32k>, >> + <&sys_clkin>, >> + <&usb_otg_ss_refclk960m>; >> +clock-names = "wkupclk", >> +"sysclk", >> +"refclk"; >> #phy-cells = <0>; >> }; >> }; >> -- >> 1.8.3.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
