mach-omap2/timer.c: Bug introduced while merging patch - ff931c82
Hi, Not sure whether this got discussed and fixed already, but Google didn't give me anything :) The below commit got merged wrongly to Mainline (Changes from timer.c got missed), and due to this none of omap boards will boot. >From ff931c821bab6713a52b768b0cd7ee7e90713b36 Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Thu, 21 Mar 2013 11:04:52 + Subject: ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized It seems Linux-omap tree has the fix patch for this, and it should get pushed ASAP. Below are links for Linus's mainline commit [1], the actual patch submitted to the list [2] and Commit present in Linux-omap [3]. [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/mach-omap2/io.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36 [2] https://patchwork.kernel.org/patch/2300071/ [3] http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/commit/arch/arm/mach-omap2/timer.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36 Thanks, Vaibhav -- 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: dts: OMAP4+: remove multimedia carveouts
Hi Suman,
On 04/17/2013 11:26 PM, Suman Anna wrote:
> The carveouts that have been reserved for multimedia usecases
> are not being used currently by any driver and so have been
> cleaned up. Memory will be allocated runtime through CMA for
> enabling the multimedia usecases.
>
> Signed-off-by: Suman Anna
Thanks for that cleanup. I'll queue that after the merge widow on top of
3.10-rc1.
Regards,
Benoit
> ---
> arch/arm/boot/dts/omap4.dtsi | 8
> arch/arm/boot/dts/omap5.dtsi | 8
> 2 files changed, 16 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 55c633a..79aaafe 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -6,14 +6,6 @@
> * published by the Free Software Foundation.
> */
>
> -/*
> - * Carveout for multimedia usecases
> - * It should be the last 48MB of the first 512MB memory part
> - * In theory, it should not even exist. That zone should be reserved
> - * dynamically during the .reserve callback.
> - */
> -/memreserve/ 0x9d00 0x0300;
> -
> /include/ "skeleton.dtsi"
>
> / {
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index c9ecdbe..7006554 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -7,14 +7,6 @@
> * Based on "omap4.dtsi"
> */
>
> -/*
> - * Carveout for multimedia usecases
> - * It should be the last 48MB of the first 512MB memory part
> - * In theory, it should not even exist. That zone should be reserved
> - * dynamically during the .reserve callback.
> - */
> -/memreserve/ 0x9d00 0x0300;
> -
> /include/ "skeleton.dtsi"
>
> / {
>
--
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] ti_tscadc: Update with IIO map interface & deal with partial activation
Hi Pantelis, while trying out your patch on a custom AM335x board, I noticed that the sysfs entries ware missing. This is fixed in the first patch, you might want to squash that into your original patch. The second one makes sure that the iio framework does not read invalid data. Regards, Jan -- 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] iio: adc: ti_am335x_adc: make tiadc_read_raw() more robust
Check that mask is actually IIO_CHAN_INFO_RAW.
Also handle the case where not enough data is in the fifo.
Signed-off-by: Jan Luebbe
---
drivers/iio/adc/ti_am335x_adc.c | 48 -
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 620cc0c..4b764a9 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -157,26 +157,34 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
int i;
unsigned int fifo1count, readx1;
- /*
-* When the sub-system is first enabled,
-* the sequencer will always start with the
-* lowest step (1) and continue until step (16).
-* For ex: If we have enabled 4 ADC channels and
-* currently use only 1 out of them, the
-* sequencer still configures all the 4 steps,
-* leading to 3 unwanted data.
-* Hence we need to flush out this data.
-*/
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ /*
+* When the sub-system is first enabled,
+* the sequencer will always start with the
+* lowest step (1) and continue until step (16).
+* For ex: If we have enabled 4 ADC channels and
+* currently use only 1 out of them, the
+* sequencer still configures all the 4 steps,
+* leading to 3 unwanted data.
+* Hence we need to flush out this data.
+*/
+
+ fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
+ for (i = 0; i < fifo1count; i++) {
+ readx1 = tiadc_readl(adc_dev, REG_FIFO1);
+ if (i == chan->channel)
+ *val = readx1 & 0xfff;
+ }
+ tiadc_writel(adc_dev, REG_SE, STPENB_STEPENB);
- fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
- for (i = 0; i < fifo1count; i++) {
- readx1 = tiadc_readl(adc_dev, REG_FIFO1);
- if (i == chan->channel)
- *val = readx1 & 0xfff;
- }
- tiadc_writel(adc_dev, REG_SE, STPENB_STEPENB);
+ if (fifo1count <= chan->channel)
+ return -EINVAL;
- return IIO_VAL_INT;
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
}
static const struct iio_info tiadc_info = {
@@ -213,7 +221,7 @@ static int tiadc_probe(struct platform_device *pdev)
else {
node = of_get_child_by_name(node, "adc");
if (!node)
- return -EINVAL;
+ return -EINVAL;
else {
err = of_property_read_u32(node,
"ti,adc-channels", &val32);
@@ -310,7 +318,7 @@ static const struct dev_pm_ops tiadc_pm_ops = {
static struct platform_driver tiadc_driver = {
.driver = {
- .name = "tiadc",
+ .name = "tiadc",
.owner = THIS_MODULE,
.pm = TIADC_PM_OPS,
},
--
1.8.2.rc2
--
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] iio: adc: ti_am335x_adc: revert info_mask removal
Commit "ti_tscadc: Update with IIO map interface & deal with partial activation" by Pantelis Antoniou removed this line. Without it, the in_voltage?_raw entries are missing from sysfs. Signed-off-by: Jan Luebbe --- drivers/iio/adc/ti_am335x_adc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c index ee20c0c..620cc0c 100644 --- a/drivers/iio/adc/ti_am335x_adc.c +++ b/drivers/iio/adc/ti_am335x_adc.c @@ -107,6 +107,7 @@ static int tiadc_channel_init(struct iio_dev *indio_dev, chan->type = IIO_VOLTAGE; chan->indexed = 1; chan->channel = i; + chan->info_mask = IIO_CHAN_INFO_RAW_SEPARATE_BIT; chan->datasheet_name = s; chan->scan_type.sign = 'u'; chan->scan_type.realbits = 12; -- 1.8.2.rc2 -- 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: mach-omap2/timer.c: Bug introduced while merging patch - ff931c82
* Hiremath, Vaibhav [130506 00:12]: > Hi, > > Not sure whether this got discussed and fixed already, but Google didn't give > me anything :) > > The below commit got merged wrongly to Mainline (Changes from timer.c got > missed), and > due to this none of omap boards will boot. > > > From ff931c821bab6713a52b768b0cd7ee7e90713b36 Mon Sep 17 00:00:00 2001 > From: Rajendra Nayak > Date: Thu, 21 Mar 2013 11:04:52 + > Subject: ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized > > > It seems Linux-omap tree has the fix patch for this, and it should get pushed > ASAP. > Below are links for Linus's mainline commit [1], the actual patch submitted > to the list [2] and > Commit present in Linux-omap [3]. Can you please provide a proper patch for the regression since sounds like you already figured out what happened? Regards, Tony > [1] > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/mach-omap2/io.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36 > [2] https://patchwork.kernel.org/patch/2300071/ > [3] > http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/commit/arch/arm/mach-omap2/timer.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36 -- 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: gpmc: fix compilation warning
From: Vincent Stehlé
Fix the following compilation warning:
arch/arm/mach-omap2/gpmc.c: In function 'gpmc_probe_generic_child':
arch/arm/mach-omap2/gpmc.c:1477:4: warning: format '%x' expects argument of
type 'unsigned int', but argument 4 has type 'resource_size_t' [-Wformat]
Signed-off-by: Vincent Stehlé
Cc: triv...@kernel.org
---
(This is a resend.)
arch/arm/mach-omap2/gpmc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ed946df..3cd7074 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1474,7 +1474,7 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
ret = gpmc_cs_remap(cs, res.start);
if (ret < 0) {
dev_err(&pdev->dev, "cannot remap GPMC CS %d to 0x%x\n",
- cs, res.start);
+ cs, (unsigned)res.start);
goto err;
}
--
1.7.10.4
--
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] ti_tscadc: Update with IIO map interface & deal with partial activation
On 05/06/2013 01:48 PM, Jan Luebbe wrote: > Hi Pantelis, > > while trying out your patch on a custom AM335x board, I noticed that the > sysfs entries ware missing. This is fixed in the first patch, you might want > to squash that into your original patch. > > The second one makes sure that the iio framework does not read invalid data. > > Regards, > Jan I don't believe Pantelis ever came back with a response to the various issues raised with the original patches? If Pantelis has moved on, Jan feel free to pick up the patches, respin them and resend to linux-iio if you like (with appropriate crediting naturally) Until these are appropriately fixed up and resent, I'm lazy so will ignore these. (your patches look reasonable to me based on a really superficial look) Jonathan -- 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: mach-omap2/timer.c: Bug introduced while merging patch - ff931c82
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Monday, May 06, 2013 8:57 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
> arm-ker...@lists.infradead.org
> Subject: Re: mach-omap2/timer.c: Bug introduced while merging patch -
> ff931c82
>
> * Hiremath, Vaibhav [130506 00:12]:
> > Hi,
> >
> > Not sure whether this got discussed and fixed already, but Google
> didn't give me anything :)
> >
> > The below commit got merged wrongly to Mainline (Changes from timer.c
> got missed), and
> > due to this none of omap boards will boot.
> >
> >
> > From ff931c821bab6713a52b768b0cd7ee7e90713b36 Mon Sep 17 00:00:00
> 2001
> > From: Rajendra Nayak
> > Date: Thu, 21 Mar 2013 11:04:52 +
> > Subject: ARM: OMAP: clocks: Delay clk inits atleast until slab is
> initialized
> >
> >
> > It seems Linux-omap tree has the fix patch for this, and it should
> get pushed ASAP.
> > Below are links for Linus's mainline commit [1], the actual patch
> submitted to the list [2] and
> > Commit present in Linux-omap [3].
>
> Can you please provide a proper patch for the regression since sounds
> like you already figured out what happened?
>
Ohh yeah, I already have a patch for it -
From: Vaibhav Hiremath
Date: Mon, 6 May 2013 13:23:27 +0530
Subject: [PATCH] ARM: OMAP2+: Regression: Add missing code while merging commit
ff931c82 to Mainline
While merging commit ff931c82 [1] to Mainline,, it seems not all the changes
from
the original patch [2] have been merged; changes from mach-omap2/timer.c have
been
dropped, which invokes xxx_clk_init() function required to register platform
clock table. And without this none of OMAP family of devices will boot from
Mainline.
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/mach-omap2/io.c?id=ff931c821bab6713a52b768b0cd7ee7e90713b36
[2] https://patchwork.kernel.org/patch/2300071/
Signed-off-by: Vaibhav Hiremath
---
arch/arm/mach-omap2/timer.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index f12aa6c..31ae764 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -549,6 +549,8 @@ static inline void __init realtime_counter_init(void)
clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_gptimer_timer_init(void) \
{ \
+ if (omap_clk_init) \
+ omap_clk_init();\
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
@@ -559,6 +561,8 @@ void __init omap##name##_gptimer_timer_init(void)
\
clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_sync32k_timer_init(void) \
{ \
+ if (omap_clk_init) \
+ omap_clk_init();\
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
/* Enable the use of clocksource="gp_timer" kernel parameter */ \
Thanks,
Vaibhav
--
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] spi/omap2: Let device core handle pinctrl
Since commit ab78029 (drivers/pinctrl: grab default handles from device
core) we can rely on device core for handling pinctrl so remove
devm_pinctrl_get_select_default() from the driver.
Signed-off-by: Mark Brown
---
drivers/spi/spi-omap2-mcspi.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 893c3d7..3777bd5 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
@@ -1170,7 +1169,6 @@ static int omap2_mcspi_probe(struct platform_device *pdev)
static int bus_num = 1;
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
- struct pinctrl *pinctrl;
master = spi_alloc_master(&pdev->dev, sizeof *mcspi);
if (master == NULL) {
@@ -1268,11 +1266,6 @@ static int omap2_mcspi_probe(struct platform_device
*pdev)
if (status < 0)
goto dma_chnl_free;
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&pdev->dev,
- "pins are not configured from the driver\n");
-
pm_runtime_use_autosuspend(&pdev->dev);
pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
pm_runtime_enable(&pdev->dev);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH 0/3] arm: enable TI SoC thermal driver
Hello Tony, I am resending these three patches for your consideration. Idea is to add the missing bits under arch/arm/*omap* required to enable by default the ti-soc-thermal driver. I am planing to move it out of staging tree. It would be interesting to get feedback from other ppl. By enabling it by default we could reach more ppl for testing it across the supported chips. All best, Eduardo Valentin (3): arm: dts: introduce config HAS_BANDGAP arm: dts: add bandgap entry for OMAP443x devices arm: add bandgap entry for OMAP4460 devices arch/arm/Kconfig| 3 +++ arch/arm/boot/dts/omap443x.dtsi | 4 arch/arm/boot/dts/omap4460.dtsi | 9 + arch/arm/mach-omap2/Kconfig | 1 + 4 files changed, 17 insertions(+) -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH 3/3] arm: add bandgap entry for OMAP4460 devices
Include bandgap devices for OMAP4460 devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap4460.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 7c2c23c..3808b5c 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -29,4 +29,13 @@
<0 55 0x4>;
ti,hwmods = "debugss";
};
+
+ bandgap {
+ reg = <0x4a002260 0x4
+ 0x4a00232C 0x4
+ 0x4a002378 0x18>;
+ compatible = "ti,omap4460-bandgap";
+ interrupts = <0 126 4>; /* talert */
+ ti,tshut-gpio = <86>;
+ };
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
Introduce HAS_BANDGAP config entry. This config is a boolean value so that arch code can flag is they feature a bandgap device. Cc: Russell King Cc: Tony Lindgren Cc: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin --- arch/arm/Kconfig| 3 +++ arch/arm/mach-omap2/Kconfig | 1 + 2 files changed, 4 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f95674a..39fc561 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -176,6 +176,9 @@ config ARCH_HAS_CPUFREQ and that the relevant menu configurations are displayed for it. +config ARCH_HAS_BANDGAP + bool + config GENERIC_HWEIGHT bool default y diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..8620ab5 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -4,6 +4,7 @@ config ARCH_OMAP config ARCH_OMAP2PLUS bool "TI OMAP2/3/4/5 SoCs with device tree support" if (ARCH_MULTI_V6 || ARCH_MULTI_V7) select ARCH_HAS_CPUFREQ + select ARCH_HAS_BANDGAP select ARCH_HAS_HOLES_MEMORYMODEL select ARCH_OMAP select ARCH_REQUIRE_GPIOLIB -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH 2/3] arm: dts: add bandgap entry for OMAP443x devices
This patch add the bandgap entry for OMAP4430 devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap443x.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index cccf39a..8d6c968 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -24,4 +24,8 @@
clock-latency = <30>; /* From legacy driver */
};
};
+ bandgap {
+ reg = <0x4a002260 0x4 0x4a00232C 0x4>;
+ compatible = "ti,omap4430-bandgap";
+ };
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On Mon, May 06, 2013 at 05:00:56PM -0400, Eduardo Valentin wrote: > Introduce HAS_BANDGAP config entry. This config is a > boolean value so that arch code can flag is they > feature a bandgap device. Maybe it could be mentioned that omap-thermal already depend on this? At least for a random reviewer it was not immediately clear why this is added, especially since there were no users for it in subsequent patches. A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On 05/06/2013 03:00 PM, Eduardo Valentin wrote: > Introduce HAS_BANDGAP config entry. This config is a > boolean value so that arch code can flag is they > feature a bandgap device. What does this patch have to do with device tree (there's "dts" in the subject)? What's a BANDGAP device? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On Tue, May 07, 2013 at 12:34:13AM +0300, Aaro Koskinen wrote: > On Mon, May 06, 2013 at 05:00:56PM -0400, Eduardo Valentin wrote: > > Introduce HAS_BANDGAP config entry. This config is a > > boolean value so that arch code can flag is they > > feature a bandgap device. > > Maybe it could be mentioned that omap-thermal already depend on this? > At least for a random reviewer it was not immediately clear why this is > added, especially since there were no users for it in subsequent patches. I looked (very briefly), and it seemed like omap-thermal is self contained and doesn't need arch support? I get the impression it is desired to minimize driver kconfig dependencies to the minimum required to compile to increase build testing coverage, so maybe it would be appropriate to drop this entirely? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On 06-05-2013 17:34, Aaro Koskinen wrote: > On Mon, May 06, 2013 at 05:00:56PM -0400, Eduardo Valentin wrote: >> Introduce HAS_BANDGAP config entry. This config is a >> boolean value so that arch code can flag is they >> feature a bandgap device. > > Maybe it could be mentioned that omap-thermal already depend on this? > At least for a random reviewer it was not immediately clear why this is > added, especially since there were no users for it in subsequent patches. > > A. > > The flag has been proposed here [1]. The adaptation on the driver has been introduced here [2,3]. It has reached the staging (next) tree. That is why you do not see any follow up patch. Although it does not have users at v3.9, the patch on the user has been sent several weeks ago. [1] - http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101827.html [2] - http://marc.info/?l=linux-omap&m=136335347305197&w=2 [3] - http://marc.info/?l=linux-driver-devel&m=136335404205514&w=1 signature.asc Description: OpenPGP digital signature
Re: Removing vestiges of CONFIG_USB_SUSPEND
Hi Alan, Alan Stern writes: > Felipe and Kevin: > > While removing the remaining usages of USB_SUSPEND (things that I > missed in the original patch), I noticed that > arch/arm/configs/omap2plus_defconfig does not enable PM_RUNTIME -- even > though it currently does enable USB_SUSPEND, which depends on > PM_RUNTIME. Was this an oversight? Looks like an oversight, but covered up by some other default options in mach-omap2/Kconfig. Specifially, config ARCH_OMAP2PLUS_TYPICAL (default y) does a select PM_RUNTIME. > In a little while I will submit a patch which removes USB_SUSPEND from > that file. You or someone else may want to write a separate patch to > enable PM_RUNTIME. I think we'll be covered by our current defaults. Thanks for the heads up. Kevin -- 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: mach-omap2/timer.c: Bug introduced while merging patch - ff931c82
* Hiremath, Vaibhav [130506 11:35]:
>
> Ohh yeah, I already have a patch for it -
Thanks, I'll add that into omap-for-v3.10/fixes. I modified
the comments a bit trying to figure out where it changed, updated
patch below.
Regards,
Tony
From: Vaibhav Hiremath
Date: Mon, 6 May 2013 15:19:01 -0700
Subject: [PATCH] ARM: OMAP2+: Fix mismerge for timer.c between ff931c82 and
da4a686a
Looks like the timer.c fixes in commit ff931c82 (ARM: OMAP: clocks:
Delay clk inits atleast until slab is initialized) got lost in a
merge with da4a686a (ARM: smp_twd: convert to use CLKSRC_OF init).
Without the omap_clk_init() calls none of OMAP family of devices
boot.
Signed-off-by: Vaibhav Hiremath
[t...@atomide.com: updated comments to describe merge error]
Signed-off-by: Tony Lindgren
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -549,6 +549,8 @@ static inline void __init realtime_counter_init(void)
clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_gptimer_timer_init(void) \
{ \
+ if (omap_clk_init) \
+ omap_clk_init();\
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
@@ -559,6 +561,8 @@ void __init omap##name##_gptimer_timer_init(void)
\
clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_sync32k_timer_init(void) \
{ \
+ if (omap_clk_init) \
+ omap_clk_init();\
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
/* Enable the use of clocksource="gp_timer" kernel parameter */ \
--
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
[GIT PULL] Urgent omap timer fix for current merge window
The following changes since commit dc2d3db8137fba0f62d7517e1bea8a47f69fcbc4: Merge tag 'omap-for-v3.10/timer-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/drivers (2013-04-08 19:30:48 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/fixes-for-merge-window for you to fetch changes up to 08a48be32ff31d38bcfec7d210c954cb62fd5cd7: ARM: OMAP4: change the device names in usb_bind_phy (2013-05-06 16:39:16 -0700) An urgent fix for a timer mismerge for and a regression fix for musb device naming change. Kishon Vijay Abraham I (1): ARM: OMAP4: change the device names in usb_bind_phy Vaibhav Hiremath (1): ARM: OMAP2+: Fix mismerge for timer.c between ff931c82 and da4a686a arch/arm/mach-omap2/board-4430sdp.c| 2 +- arch/arm/mach-omap2/board-omap4panda.c | 2 +- arch/arm/mach-omap2/timer.c| 4 3 files changed, 6 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On 06-05-2013 17:31, Stephen Warren wrote: > On 05/06/2013 03:00 PM, Eduardo Valentin wrote: >> Introduce HAS_BANDGAP config entry. This config is a >> boolean value so that arch code can flag is they >> feature a bandgap device. > > What does this patch have to do with device tree (there's "dts" in the > subject)? What's a BANDGAP device? > > In fact, this one has nothing to do with DT. dts in the title is a typo.. signature.asc Description: OpenPGP digital signature
Re: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On 06-05-2013 18:36, Jason Gunthorpe wrote: > On Tue, May 07, 2013 at 12:34:13AM +0300, Aaro Koskinen wrote: >> On Mon, May 06, 2013 at 05:00:56PM -0400, Eduardo Valentin wrote: >>> Introduce HAS_BANDGAP config entry. This config is a >>> boolean value so that arch code can flag is they >>> feature a bandgap device. >> >> Maybe it could be mentioned that omap-thermal already depend on this? >> At least for a random reviewer it was not immediately clear why this is >> added, especially since there were no users for it in subsequent patches. > > I looked (very briefly), and it seemed like omap-thermal is self > contained and doesn't need arch support? > It is. At least I tried to make it, at least to the extenstion I could get. > I get the impression it is desired to minimize driver kconfig > dependencies to the minimum required to compile to increase build > testing coverage, so maybe it would be appropriate to drop this > entirely? > Well, it is also desired to compile things to the correct target right? Thats the idea behind this config option. It follows the same design as CONFIG_ARCH_HAS_CPUFREQ, for instance. > Jason > > signature.asc Description: OpenPGP digital signature
Re: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On Mon, May 06, 2013 at 08:23:13PM -0400, Eduardo Valentin wrote: > > I get the impression it is desired to minimize driver kconfig > > dependencies to the minimum required to compile to increase build > > testing coverage, so maybe it would be appropriate to drop this > > entirely? > Well, it is also desired to compile things to the correct target > right? There is some of that too.. But broadly the direction seems that drivers should have minimal dependencies so, eg, the thermal maintainer compiling for x86 should be able to compile test/static analyze your driver.. > Thats the idea behind this config option. It follows the same design as > CONFIG_ARCH_HAS_CPUFREQ, for instance. That is entirely contained inside arch/arm and doesn't involve drivers. Jason -- 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: mach-omap2/timer.c: Bug introduced while merging patch - ff931c82
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Tuesday, May 07, 2013 5:08 AM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; linux- > arm-ker...@lists.infradead.org > Subject: Re: mach-omap2/timer.c: Bug introduced while merging patch - > ff931c82 > > * Hiremath, Vaibhav [130506 11:35]: > > > > Ohh yeah, I already have a patch for it - > > Thanks, I'll add that into omap-for-v3.10/fixes. I modified > the comments a bit trying to figure out where it changed, updated > patch below. > Thanks Tony. Thanks, Vaibhav -- 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] spi/omap2: Let device core handle pinctrl
On Tue, May 07, 2013 at 01:06:38, Mark Brown wrote:
> Since commit ab78029 (drivers/pinctrl: grab default handles from device
> core) we can rely on device core for handling pinctrl so remove
> devm_pinctrl_get_select_default() from the driver.
NACK.
There are cases where driver('s) needs to place pin-mux's to sleep on suspend
& default/idle on resume. For such cases Pinctrl needs to be handled inside
the driver. Example [1].
I will be submitting a patch to enhance the existing pinctrl support for
spi omap2 shortly which does above work.
Regards
Gururaja
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi-pl022.c
pl022_suspend_resources() & pl022_resume_resources()
>
> Signed-off-by: Mark Brown
> ---
> drivers/spi/spi-omap2-mcspi.c |7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
> index 893c3d7..3777bd5 100644
> --- a/drivers/spi/spi-omap2-mcspi.c
> +++ b/drivers/spi/spi-omap2-mcspi.c
> @@ -38,7 +38,6 @@
> #include
> #include
> #include
> -#include
>
> #include
>
> @@ -1170,7 +1169,6 @@ static int omap2_mcspi_probe(struct platform_device
> *pdev)
> static int bus_num = 1;
> struct device_node *node = pdev->dev.of_node;
> const struct of_device_id *match;
> - struct pinctrl *pinctrl;
>
> master = spi_alloc_master(&pdev->dev, sizeof *mcspi);
> if (master == NULL) {
> @@ -1268,11 +1266,6 @@ static int omap2_mcspi_probe(struct platform_device
> *pdev)
> if (status < 0)
> goto dma_chnl_free;
>
> - pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> - if (IS_ERR(pinctrl))
> - dev_warn(&pdev->dev,
> - "pins are not configured from the driver\n");
> -
> pm_runtime_use_autosuspend(&pdev->dev);
> pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
> pm_runtime_enable(&pdev->dev);
> --
> 1.7.10.4
>
> --
> 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
>
Regards,
Gururaja
--
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
