* [PATCHv5 0/2] ARM: I2C: Add device tree bindings to i2c-mux-gpio
From: Maxime Ripard @ 2012-10-22 12:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This patchset adds the device tree entry to the CFA-10049 board of its i2c
muxer. This muxer controls sub-buses that contains three Nuvoton NAU7802
ADCs and a NXP PCA955 GPIO expander. Support for these will be added
eventually.
Thanks,
Maxime
Changes from v4:
- Fixed a wrong sentence in the bindings documentation, stating a false
behavoiour
Maxime Ripard (2):
i2c: mux: Add dt support to i2c-mux-gpio driver
ARM: dts: cfa10049: Add the i2c muxer buses to the CFA-10049
.../devicetree/bindings/i2c/i2c-mux-gpio.txt | 81 ++++++++++
arch/arm/boot/dts/imx28-cfa10049.dts | 24 +++
drivers/i2c/muxes/i2c-mux-gpio.c | 169 +++++++++++++++-----
3 files changed, 235 insertions(+), 39 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
--
1.7.9.5
^ permalink raw reply
* [PATCH 3/4] ARM/dts: omap5: Update UART with address space and interrupts
From: Benoit Cousson @ 2012-10-22 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50853B94.4060308@ti.com>
On 10/22/2012 02:27 PM, Sourav wrote:
> Hi Benoit,
> On Monday 22 October 2012 05:37 PM, Benoit Cousson wrote:
>> On 10/22/2012 01:57 PM, Benoit Cousson wrote:
>>> Hi Sourav,
>>>
>>> On 10/22/2012 01:16 PM, Sourav wrote:
>>>> Hi Sebastien,
>>>> On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
>>>>> Add base address and interrupt line inside Device Tree data for
>>>> Incomplete sentence!
>>>>> Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
>>>>> ---
>>>>> arch/arm/boot/dts/omap5.dtsi | 16 ++++++++++++++--
>>>>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi
>>>>> b/arch/arm/boot/dts/omap5.dtsi
>>>>> index 6c22e1b..413df94 100644
>>>>> --- a/arch/arm/boot/dts/omap5.dtsi
>>>>> +++ b/arch/arm/boot/dts/omap5.dtsi
>>>>> @@ -237,36 +237,48 @@
>>>>> uart1: serial at 4806a000 {
>>>>> compatible = "ti,omap4-uart";
>>>>> + reg = <0x4806a000 0x100>;
>>>>> + interrupts = <0 72 0x4>;
>>>>> ti,hwmods = "uart1";
>>>>> clock-frequency = <48000000>;
>>>>> };
>>>>> uart2: serial at 4806c000 {
>>>>> compatible = "ti,omap4-uart";
>>>>> + reg = <0x4806c000 0x100>;
>>>>> + interrupts = <0 73 0x4>;
>>>>> ti,hwmods = "uart2";
>>>>> clock-frequency = <48000000>;
>>>>> };
>>>>> uart3: serial at 48020000 {
>>>>> compatible = "ti,omap4-uart";
>>>>> + reg = <0x48020000 0x100>;
>>>>> + interrupts = <0 74 0x4>;
>>>>> ti,hwmods = "uart3";
>>>>> clock-frequency = <48000000>;
>>>>> };
>>>>> uart4: serial at 4806e000 {
>>>>> compatible = "ti,omap4-uart";
>>>>> + reg = <0x4806e000 0x100>;
>>>>> + interrupts = <0 70 0x4>;
>>>>> ti,hwmods = "uart4";
>>>>> clock-frequency = <48000000>;
>>>>> };
>>>>> uart5: serial at 48066000 {
>>>>> - compatible = "ti,omap5-uart";
>>>>> + compatible = "ti,omap4-uart";
>>>>> + reg = <0x48066000 0x100>;
>>>>> + interrupts = <0 105 0x4>;
>>>> In Omap5 TRM, the interrupt number mentioned for uart5 is 138. How is
>>>> 105 coming?
>>> It is from hwmod and thus from the HW spec. It looks like the TRM is
>>> wrong... or the HW spec :-)
>>>
>>>>> ti,hwmods = "uart5";
>>>>> clock-frequency = <48000000>;
>>>>> };
>>>>> uart6: serial at 48068000 {
>>>>> - compatible = "ti,omap6-uart";
>>>>> + compatible = "ti,omap4-uart";
>>>>> + reg = <0x48068000 0x100>;
>>>>> + interrupts = <0 106 0x4>;
>>>> Same here, TRM shows this number to be 139 ?
>> In fact, even the TRM (ES1.0 NDA vM) is aligned with these data.
>> Where did you see 138 and 139?
> I looked at Page 6300 of the above TRM, Figure 24-60. Is this place not
> correct to look
> up for these data?
Nope. Well it should be accurate but since it is a diagram, it does not
necessarily reflect the latest integration data like IRQ line.
You'd better use the table that list all the IRQ per CPU:
18.3.2 Interrupt Requests to INTC_MPU
Regards,
Benoit
^ permalink raw reply
* [PATCH] ARM: dma-mapping: support debug_dma_mapping_error
From: Ming Lei @ 2012-10-22 12:44 UTC (permalink / raw)
To: linux-arm-kernel
Without the patch, kind of below warning will be dumped if DMA-API
debug is enabled:
[ 11.069763] ------------[ cut here ]------------
[ 11.074645] WARNING: at lib/dma-debug.c:948 check_unmap+0x770/0x860()
[ 11.081420] ehci-omap ehci-omap.0: DMA-API: device driver failed to
check map error[device address=0x0000000
0adb78e80] [size=8 bytes] [mapped as single]
[ 11.095611] Modules linked in:
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
arch/arm/include/asm/dma-mapping.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 2300484..78d8e9b 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -91,6 +91,7 @@ static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
*/
static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
{
+ debug_dma_mapping_error(dev, dma_addr);
return dma_addr == DMA_ERROR_CODE;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3] ARM: SMP_TWD: make setup()/stop() reentrant
From: Santosh Shilimkar @ 2012-10-22 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350900649-25369-1-git-send-email-linus.walleij@stericsson.com>
Hi Linus,
On Monday 22 October 2012 03:40 PM, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> It has been brought to my knowledge that the .setup()/.stop()
> function pair in the SMP TWD is going to be called from atomic
> contexts for CPUs coming and going, and then the
> clk_prepare()/clk_unprepare() calls cannot be called
> on subsequent .setup()/.stop() iterations. This is however
> just the tip of an iceberg as the function pair is not
> designed to be reentrant at all.
>
> This change makes the SMP_TWD clock .setup()/.stop() pair reentrant
> by splitting the .setup() function in three parts:
>
> - One COMMON part that is executed the first time the first CPU
> in the TWD cluster is initialized. This will fetch the TWD
> clk for the cluster and prepare+enable it. If no clk is
> available it will calibrate the rate instead.
>
> - One part that is executed the FIRST TIME a certain CPU is
> brought on-line. This initializes and sets up the clock event
> for a certain CPU.
>
> - One part that is executed on every subsequent .setup() call.
> This will re-initialize the clock event. This is augmented
> to call the clk_enable()/clk_disable() pair properly.
>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Reported-by: Peter Chen <peter.chen@freescale.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v2->v3:
> - Split setup() in three parts
> - re-register the clock event on every setup()
> ---
Patch largely looks good to me. Few comments
> arch/arm/kernel/smp_twd.c | 45 ++++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 40 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
> index b92d524..73e25e2 100644
> --- a/arch/arm/kernel/smp_twd.c
> +++ b/arch/arm/kernel/smp_twd.c
> @@ -31,6 +31,8 @@ static void __iomem *twd_base;
>
> static struct clk *twd_clk;
> static unsigned long twd_timer_rate;
> +static bool common_setup_called;
> +static DEFINE_PER_CPU(bool, percpu_setup_called);
>
> static struct clock_event_device __percpu **twd_evt;
> static int twd_ppi;
> @@ -93,6 +95,8 @@ static void twd_timer_stop(struct clock_event_device *clk)
> {
> twd_set_mode(CLOCK_EVT_MODE_UNUSED, clk);
> disable_percpu_irq(clk->irq);
> + if (!IS_ERR(twd_clk))
> + clk_disable(twd_clk);
Is this really needed? This clock disable is bogus since it
can not really disable the clock.
> }
>
> #ifdef CONFIG_COMMON_CLK
> @@ -264,15 +268,46 @@ static struct clk *twd_get_clock(void)
> static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
> {
> struct clock_event_device **this_cpu_clk;
> + int cpu = smp_processor_id();
>
> - if (!twd_clk)
> + /*
> + * If the basic setup for this CPU has been done before don't
> + * bother with the below.
> + */
> + if (per_cpu(percpu_setup_called, cpu)) {
> + if (!IS_ERR(twd_clk))
> + clk_enable(twd_clk);
> + __raw_writel(0, twd_base + TWD_TIMER_CONTROL);
> + clockevents_register_device(*__this_cpu_ptr(twd_evt));
> + enable_percpu_irq(clk->irq, 0);
> + return 0;
> + }
> + per_cpu(percpu_setup_called, cpu) = true;
> +
> + /*
> + * This stuff only need to be done once for the entire TWD cluster
> + * during the runtime of the system.
> + */
> + if (!common_setup_called) {
> twd_clk = twd_get_clock();
>
Moving the 'common_setup_called' code under one helper
might be cleaner. No strong preference though.
> - if (!IS_ERR_OR_NULL(twd_clk))
> - twd_timer_rate = clk_get_rate(twd_clk);
> - else
> - twd_calibrate_rate();
> + /*
> + * We use IS_ERR_OR_NULL() here, because if the clock stubs
> + * are active we will get a valid clk reference which is
> + * however NULL and will return the rate 0. In that case we
> + * need to calibrate the rate instead.
> + */
> + if (!IS_ERR_OR_NULL(twd_clk))
> + twd_timer_rate = clk_get_rate(twd_clk);
> + else
> + twd_calibrate_rate();
> + }
> + common_setup_called = true;
>
So "common_setup_called" will get updated every time the
twd_timer_setup() gets called. You can move this inside
the if loop.
regards
Santosh
^ permalink raw reply
* [PATCH 2/2] ASoC: Ux500: Control apb clock
From: Ulf Hansson @ 2012-10-22 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350909125-20189-1-git-send-email-ulf.hansson@stericsson.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
When switching to common clock driver for ux500 this clock needs to
be handled as well. Before this clock was internally managed by the
clock driver itself.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
sound/soc/ux500/ux500_msp_dai.c | 38 ++++++++++++++++++++++++++++++++------
sound/soc/ux500/ux500_msp_dai.h | 1 +
2 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/sound/soc/ux500/ux500_msp_dai.c b/sound/soc/ux500/ux500_msp_dai.c
index e11187f..74bb3c0 100644
--- a/sound/soc/ux500/ux500_msp_dai.c
+++ b/sound/soc/ux500/ux500_msp_dai.c
@@ -398,13 +398,28 @@ static int ux500_msp_dai_startup(struct snd_pcm_substream *substream,
return ret;
}
- /* Prepare and enable clock */
- dev_dbg(dai->dev, "%s: Enabling MSP-clock.\n", __func__);
+ /* Prepare and enable clocks */
+ dev_dbg(dai->dev, "%s: Enabling MSP-clocks.\n", __func__);
+ ret = clk_prepare_enable(drvdata->pclk);
+ if (ret) {
+ dev_err(drvdata->msp->dev,
+ "%s: Failed to prepare/enable pclk!\n", __func__);
+ goto err_pclk;
+ }
+
ret = clk_prepare_enable(drvdata->clk);
- if (ret)
- regulator_disable(drvdata->reg_vape);
+ if (ret) {
+ dev_err(drvdata->msp->dev,
+ "%s: Failed to prepare/enable clk!\n", __func__);
+ goto err_clk;
+ }
return ret;
+err_clk:
+ clk_disable_unprepare(drvdata->pclk);
+err_pclk:
+ regulator_disable(drvdata->reg_vape);
+ return ret;
}
static void ux500_msp_dai_shutdown(struct snd_pcm_substream *substream,
@@ -430,8 +445,9 @@ static void ux500_msp_dai_shutdown(struct snd_pcm_substream *substream,
__func__, dai->id, snd_pcm_stream_str(substream));
}
- /* Disable and unprepare clock */
+ /* Disable and unprepare clocks */
clk_disable_unprepare(drvdata->clk);
+ clk_disable_unprepare(drvdata->pclk);
/* Disable regulator */
ret = regulator_disable(drvdata->reg_vape);
@@ -782,6 +798,14 @@ static int __devinit ux500_msp_drv_probe(struct platform_device *pdev)
}
prcmu_qos_add_requirement(PRCMU_QOS_APE_OPP, (char *)pdev->name, 50);
+ drvdata->pclk = clk_get(&pdev->dev, "apb_pclk");
+ if (IS_ERR(drvdata->pclk)) {
+ ret = (int)PTR_ERR(drvdata->pclk);
+ dev_err(&pdev->dev, "%s: ERROR: clk_get of pclk failed (%d)!\n",
+ __func__, ret);
+ goto err_pclk;
+ }
+
drvdata->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(drvdata->clk)) {
ret = (int)PTR_ERR(drvdata->clk);
@@ -812,8 +836,9 @@ static int __devinit ux500_msp_drv_probe(struct platform_device *pdev)
err_init_msp:
clk_put(drvdata->clk);
-
err_clk:
+ clk_put(drvdata->pclk);
+err_pclk:
devm_regulator_put(drvdata->reg_vape);
return ret;
@@ -829,6 +854,7 @@ static int __devexit ux500_msp_drv_remove(struct platform_device *pdev)
prcmu_qos_remove_requirement(PRCMU_QOS_APE_OPP, "ux500_msp_i2s");
clk_put(drvdata->clk);
+ clk_put(drvdata->pclk);
ux500_msp_i2s_cleanup_msp(pdev, drvdata->msp);
diff --git a/sound/soc/ux500/ux500_msp_dai.h b/sound/soc/ux500/ux500_msp_dai.h
index 98202a3..9c778d9 100644
--- a/sound/soc/ux500/ux500_msp_dai.h
+++ b/sound/soc/ux500/ux500_msp_dai.h
@@ -69,6 +69,7 @@ struct ux500_msp_i2s_drvdata {
/* Clocks */
unsigned int master_clk;
struct clk *clk;
+ struct clk *pclk;
/* Regulators */
int vape_opp_constraint;
--
1.7.10
^ permalink raw reply related
* [PATCH 1/2] ASoC: Ux500: Fixup use of clocks
From: Ulf Hansson @ 2012-10-22 12:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Ulf Hansson <ulf.hansson@linaro.org>
Make sure clocks are being prepared and unprepared as well
as enabled and disabled.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
sound/soc/ux500/ux500_msp_dai.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/sound/soc/ux500/ux500_msp_dai.c b/sound/soc/ux500/ux500_msp_dai.c
index be94bf9..e11187f 100644
--- a/sound/soc/ux500/ux500_msp_dai.c
+++ b/sound/soc/ux500/ux500_msp_dai.c
@@ -398,11 +398,13 @@ static int ux500_msp_dai_startup(struct snd_pcm_substream *substream,
return ret;
}
- /* Enable clock */
+ /* Prepare and enable clock */
dev_dbg(dai->dev, "%s: Enabling MSP-clock.\n", __func__);
- clk_enable(drvdata->clk);
+ ret = clk_prepare_enable(drvdata->clk);
+ if (ret)
+ regulator_disable(drvdata->reg_vape);
- return 0;
+ return ret;
}
static void ux500_msp_dai_shutdown(struct snd_pcm_substream *substream,
@@ -428,8 +430,8 @@ static void ux500_msp_dai_shutdown(struct snd_pcm_substream *substream,
__func__, dai->id, snd_pcm_stream_str(substream));
}
- /* Disable clock */
- clk_disable(drvdata->clk);
+ /* Disable and unprepare clock */
+ clk_disable_unprepare(drvdata->clk);
/* Disable regulator */
ret = regulator_disable(drvdata->reg_vape);
--
1.7.10
^ permalink raw reply related
* [PATCH 3/4] ARM/dts: omap5: Update UART with address space and interrupts
From: Felipe Balbi @ 2012-10-22 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50853B94.4060308@ti.com>
On Mon, Oct 22, 2012 at 05:57:00PM +0530, Sourav wrote:
> Hi Benoit,
> On Monday 22 October 2012 05:37 PM, Benoit Cousson wrote:
> >On 10/22/2012 01:57 PM, Benoit Cousson wrote:
> >>Hi Sourav,
> >>
> >>On 10/22/2012 01:16 PM, Sourav wrote:
> >>>Hi Sebastien,
> >>>On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
> >>>>Add base address and interrupt line inside Device Tree data for
> >>>Incomplete sentence!
> >>>>Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
> >>>>---
> >>>> arch/arm/boot/dts/omap5.dtsi | 16 ++++++++++++++--
> >>>> 1 file changed, 14 insertions(+), 2 deletions(-)
> >>>>
> >>>>diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> >>>>index 6c22e1b..413df94 100644
> >>>>--- a/arch/arm/boot/dts/omap5.dtsi
> >>>>+++ b/arch/arm/boot/dts/omap5.dtsi
> >>>>@@ -237,36 +237,48 @@
> >>>> uart1: serial at 4806a000 {
> >>>> compatible = "ti,omap4-uart";
> >>>>+ reg = <0x4806a000 0x100>;
> >>>>+ interrupts = <0 72 0x4>;
> >>>> ti,hwmods = "uart1";
> >>>> clock-frequency = <48000000>;
> >>>> };
> >>>> uart2: serial at 4806c000 {
> >>>> compatible = "ti,omap4-uart";
> >>>>+ reg = <0x4806c000 0x100>;
> >>>>+ interrupts = <0 73 0x4>;
> >>>> ti,hwmods = "uart2";
> >>>> clock-frequency = <48000000>;
> >>>> };
> >>>> uart3: serial at 48020000 {
> >>>> compatible = "ti,omap4-uart";
> >>>>+ reg = <0x48020000 0x100>;
> >>>>+ interrupts = <0 74 0x4>;
> >>>> ti,hwmods = "uart3";
> >>>> clock-frequency = <48000000>;
> >>>> };
> >>>> uart4: serial at 4806e000 {
> >>>> compatible = "ti,omap4-uart";
> >>>>+ reg = <0x4806e000 0x100>;
> >>>>+ interrupts = <0 70 0x4>;
> >>>> ti,hwmods = "uart4";
> >>>> clock-frequency = <48000000>;
> >>>> };
> >>>> uart5: serial at 48066000 {
> >>>>- compatible = "ti,omap5-uart";
> >>>>+ compatible = "ti,omap4-uart";
> >>>>+ reg = <0x48066000 0x100>;
> >>>>+ interrupts = <0 105 0x4>;
> >>>In Omap5 TRM, the interrupt number mentioned for uart5 is 138. How is
> >>>105 coming?
> >>It is from hwmod and thus from the HW spec. It looks like the TRM is
> >>wrong... or the HW spec :-)
> >>
> >>>> ti,hwmods = "uart5";
> >>>> clock-frequency = <48000000>;
> >>>> };
> >>>> uart6: serial at 48068000 {
> >>>>- compatible = "ti,omap6-uart";
> >>>>+ compatible = "ti,omap4-uart";
> >>>>+ reg = <0x48068000 0x100>;
> >>>>+ interrupts = <0 106 0x4>;
> >>>Same here, TRM shows this number to be 139 ?
> >In fact, even the TRM (ES1.0 NDA vM) is aligned with these data.
> >Where did you see 138 and 139?
> I looked at Page 6300 of the above TRM, Figure 24-60. Is this place
correct page is 6366
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121022/4af666ee/attachment.sig>
^ permalink raw reply
* [PATCH 5/8] i2c: omap: introduce and use OMAP_I2C_IP_VERSION_3
From: Felipe Balbi @ 2012-10-22 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50853BA8.8000200@ti.com>
Hi,
On Mon, Oct 22, 2012 at 02:27:20PM +0200, Benoit Cousson wrote:
> Hi Felipe,
>
> On 10/22/2012 11:46 AM, Felipe Balbi wrote:
> > on OMAP4+ we want to read IRQSTATUS_RAW register,
> > instead of IRQSTATUS. The reason being that IRQSTATUS
> > will only contain the bits which were enabled on
> > IRQENABLE_SET and that will break when we need to
> > poll for a certain bit which wasn't enabled as an
> > IRQ source.
> >
> > One such case is after we finish converting to
> > deferred stop bit, we will have to poll for ARDY
> > bit before returning control for the client driver
> > in order to prevent us from trying to start a
> > transfer on a bus which is already busy.
> >
> > Note, however, that omap-i2c.c needs a big rework
> > on register definition and register access. Such
> > work will be done in a separate series of patches.
>
> Do you need OMAP_I2C_IP_VERSION_3 for OMAP4?
>
> OMAP_I2C_IP_VERSION_2 was already introduced to detect OMAP3630 vs
> omap4430 because they were sharing the same IP version..
>
> /* I2C controller revisions present on specific hardware */
> #define OMAP_I2C_REV_ON_2430 0x36
> #define OMAP_I2C_REV_ON_3430_3530 0x3C
> #define OMAP_I2C_REV_ON_3630_4430 0x40
>
> So in theory you should not need an extra version.
are you sure that's how they're used ? Looking at the code where we
choose reg_map_ip_v1 and reg_map_ip_v2:
1120 if (dev->dtrev == OMAP_I2C_IP_VERSION_2)
1121 dev->regs = (u8 *)reg_map_ip_v2;
1122 else
1123 dev->regs = (u8 *)reg_map_ip_v1;
And looking at reg_map_ip_v1:
218 static const u8 reg_map_ip_v1[] = {
219 [OMAP_I2C_REV_REG] = 0x00,
220 [OMAP_I2C_IE_REG] = 0x01,
221 [OMAP_I2C_STAT_REG] = 0x02,
222 [OMAP_I2C_IV_REG] = 0x03,
223 [OMAP_I2C_WE_REG] = 0x03,
224 [OMAP_I2C_SYSS_REG] = 0x04,
225 [OMAP_I2C_BUF_REG] = 0x05,
226 [OMAP_I2C_CNT_REG] = 0x06,
227 [OMAP_I2C_DATA_REG] = 0x07,
228 [OMAP_I2C_SYSC_REG] = 0x08,
229 [OMAP_I2C_CON_REG] = 0x09,
230 [OMAP_I2C_OA_REG] = 0x0a,
231 [OMAP_I2C_SA_REG] = 0x0b,
232 [OMAP_I2C_PSC_REG] = 0x0c,
233 [OMAP_I2C_SCLL_REG] = 0x0d,
234 [OMAP_I2C_SCLH_REG] = 0x0e,
235 [OMAP_I2C_SYSTEST_REG] = 0x0f,
236 [OMAP_I2C_BUFSTAT_REG] = 0x10,
237 };
that's really not the register map on OMAP3. That only looks valid for
OMAP1.
-ECONFUSED
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121022/d5deb0e8/attachment.sig>
^ permalink raw reply
* [PATCH 5/8] i2c: omap: introduce and use OMAP_I2C_IP_VERSION_3
From: Benoit Cousson @ 2012-10-22 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350899218-13624-6-git-send-email-balbi@ti.com>
Hi Felipe,
On 10/22/2012 11:46 AM, Felipe Balbi wrote:
> on OMAP4+ we want to read IRQSTATUS_RAW register,
> instead of IRQSTATUS. The reason being that IRQSTATUS
> will only contain the bits which were enabled on
> IRQENABLE_SET and that will break when we need to
> poll for a certain bit which wasn't enabled as an
> IRQ source.
>
> One such case is after we finish converting to
> deferred stop bit, we will have to poll for ARDY
> bit before returning control for the client driver
> in order to prevent us from trying to start a
> transfer on a bus which is already busy.
>
> Note, however, that omap-i2c.c needs a big rework
> on register definition and register access. Such
> work will be done in a separate series of patches.
Do you need OMAP_I2C_IP_VERSION_3 for OMAP4?
OMAP_I2C_IP_VERSION_2 was already introduced to detect OMAP3630 vs
omap4430 because they were sharing the same IP version..
/* I2C controller revisions present on specific hardware */
#define OMAP_I2C_REV_ON_2430 0x36
#define OMAP_I2C_REV_ON_3430_3530 0x3C
#define OMAP_I2C_REV_ON_3630_4430 0x40
So in theory you should not need an extra version.
Regards,
Benoit
^ permalink raw reply
* [PATCH 3/4] ARM/dts: omap5: Update UART with address space and interrupts
From: Sourav @ 2012-10-22 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508536EA.4020808@ti.com>
Hi Benoit,
On Monday 22 October 2012 05:37 PM, Benoit Cousson wrote:
> On 10/22/2012 01:57 PM, Benoit Cousson wrote:
>> Hi Sourav,
>>
>> On 10/22/2012 01:16 PM, Sourav wrote:
>>> Hi Sebastien,
>>> On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
>>>> Add base address and interrupt line inside Device Tree data for
>>> Incomplete sentence!
>>>> Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
>>>> ---
>>>> arch/arm/boot/dts/omap5.dtsi | 16 ++++++++++++++--
>>>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>>>> index 6c22e1b..413df94 100644
>>>> --- a/arch/arm/boot/dts/omap5.dtsi
>>>> +++ b/arch/arm/boot/dts/omap5.dtsi
>>>> @@ -237,36 +237,48 @@
>>>> uart1: serial at 4806a000 {
>>>> compatible = "ti,omap4-uart";
>>>> + reg = <0x4806a000 0x100>;
>>>> + interrupts = <0 72 0x4>;
>>>> ti,hwmods = "uart1";
>>>> clock-frequency = <48000000>;
>>>> };
>>>> uart2: serial at 4806c000 {
>>>> compatible = "ti,omap4-uart";
>>>> + reg = <0x4806c000 0x100>;
>>>> + interrupts = <0 73 0x4>;
>>>> ti,hwmods = "uart2";
>>>> clock-frequency = <48000000>;
>>>> };
>>>> uart3: serial at 48020000 {
>>>> compatible = "ti,omap4-uart";
>>>> + reg = <0x48020000 0x100>;
>>>> + interrupts = <0 74 0x4>;
>>>> ti,hwmods = "uart3";
>>>> clock-frequency = <48000000>;
>>>> };
>>>> uart4: serial at 4806e000 {
>>>> compatible = "ti,omap4-uart";
>>>> + reg = <0x4806e000 0x100>;
>>>> + interrupts = <0 70 0x4>;
>>>> ti,hwmods = "uart4";
>>>> clock-frequency = <48000000>;
>>>> };
>>>> uart5: serial at 48066000 {
>>>> - compatible = "ti,omap5-uart";
>>>> + compatible = "ti,omap4-uart";
>>>> + reg = <0x48066000 0x100>;
>>>> + interrupts = <0 105 0x4>;
>>> In Omap5 TRM, the interrupt number mentioned for uart5 is 138. How is
>>> 105 coming?
>> It is from hwmod and thus from the HW spec. It looks like the TRM is
>> wrong... or the HW spec :-)
>>
>>>> ti,hwmods = "uart5";
>>>> clock-frequency = <48000000>;
>>>> };
>>>> uart6: serial at 48068000 {
>>>> - compatible = "ti,omap6-uart";
>>>> + compatible = "ti,omap4-uart";
>>>> + reg = <0x48068000 0x100>;
>>>> + interrupts = <0 106 0x4>;
>>> Same here, TRM shows this number to be 139 ?
> In fact, even the TRM (ES1.0 NDA vM) is aligned with these data.
> Where did you see 138 and 139?
I looked at Page 6300 of the above TRM, Figure 24-60. Is this place not
correct to look
up for these data?
> Regards,
> Benoit
>
>
>
^ permalink raw reply
* [PATCH 0/7] ARM: OMAP: second set of PRM/CM/CGRM cleanup patches for 3.8
From: Benoit Cousson @ 2012-10-22 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016012448.21844.92339.stgit@dusk.lan>
Hi Paul,
What is CGRM? Is it a typo?
Regards,
Benoit
On 10/16/2012 03:32 AM, Paul Walmsley wrote:
> This series removes the omap_prcm_get_reset_sources() function. This
> was exported from arch/arm/mach-omap2/prcm.c for use by the OMAP
> watchdog driver to report the "boot reason". This series reimplements
> this using a platform_data function pointer for the time being, but
> after the upcoming PRM/CM drivers are merged, the watchdog driver can be
> patched to use an exported function from the drivers.
>
> This series will also be used as a base for other PRM/CM cleanup during the
> 3.8 time frame, since it adds the prm_register() and prm_unregister() functions.
> These are called by SoC-specific PRM IP block drivers to register function
> pointers with the PRM subsystem.
>
> This series changes the format of the watchdog's boot reason data to conform
> with the watchdog subsystem standard (the WDIOF_* flags). If users need
> more detail than that interface provides, either the watchdog interface can
> be patched, or those users can get that information from the upcoming PRM
> drivers.
>
>
> - Paul
>
> ---
>
> prcm_cleanup_b_3.8
> text data bss dec hex filename
> 7519295 696796 5613996 13830087 d307c7 vmlinux.omap2plus_defconfig.orig
> 7520203 696868 5613996 13831067 d30b9b vmlinux.omap2plus_defconfig
>
> Paul Walmsley (7):
> ARM: OMAP2+: PRM: prepare for use of prm_ll_data function pointers
> ARM: OMAP2+: CM: prepare for use of cm_ll_data function pointers
> ARM: OMAP1: create read_reset_sources() function (for initial use by watchdog)
> ARM: OMAP2+: PRM: create PRM reset source API for the watchdog timer driver
> ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
> watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr
> ARM: OMAP2+: PRCM: remove omap_prcm_get_reset_sources()
>
>
> arch/arm/mach-omap1/common.h | 2 +
> arch/arm/mach-omap1/devices.c | 21 ++++++-
> arch/arm/mach-omap1/reset.c | 39 +++++++++++++
> arch/arm/mach-omap2/Makefile | 2 -
> arch/arm/mach-omap2/cm.h | 12 ++++
> arch/arm/mach-omap2/cm_common.c | 71 +++++++++++++++++++++++
> arch/arm/mach-omap2/devices.c | 26 --------
> arch/arm/mach-omap2/prcm.c | 12 ----
> arch/arm/mach-omap2/prm-regbits-24xx.h | 4 +
> arch/arm/mach-omap2/prm-regbits-34xx.h | 10 +++
> arch/arm/mach-omap2/prm.h | 53 +++++++++++++++++
> arch/arm/mach-omap2/prm2xxx.c | 68 ++++++++++++++++++++++
> arch/arm/mach-omap2/prm2xxx.h | 4 +
> arch/arm/mach-omap2/prm2xxx_3xxx.h | 2 +
> arch/arm/mach-omap2/prm3xxx.c | 65 +++++++++++++++++++++
> arch/arm/mach-omap2/prm3xxx.h | 2 +
> arch/arm/mach-omap2/prm44xx.c | 83 ++++++++++++++++++++++++++-
> arch/arm/mach-omap2/prm44xx.h | 2 +
> arch/arm/mach-omap2/prm_common.c | 78 +++++++++++++++++++++++++
> arch/arm/mach-omap2/wd_timer.c | 33 +++++++++++
> arch/arm/plat-omap/include/plat/prcm.h | 1
> drivers/watchdog/omap_wdt.c | 26 ++++----
> include/linux/platform_data/omap-wd-timer.h | 38 ++++++++++++
> 23 files changed, 594 insertions(+), 60 deletions(-)
> create mode 100644 arch/arm/mach-omap2/cm_common.c
> create mode 100644 include/linux/platform_data/omap-wd-timer.h
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v2] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
From: Sourav @ 2012-10-22 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350685470-3634-1-git-send-email-khilman@deeprootsystems.com>
Hi,
On Saturday 20 October 2012 03:54 AM, Kevin Hilman wrote:
> From: Kevin Hilman <khilman@ti.com>
>
> The runtime PM framework assumes that the hardware state of devices
> when initialized is disabled. For all omap_devices, we idle/disable
> device by default. However, the console uart uses a "no idle" option
> during omap_device init in order to allow earlyprintk usage to work
> seamlessly during boot.
>
> Because the hardware is left partially enabled after init (whatever
> the bootloader settings were), the omap_device should later be fully
> initialized (including mux) and the runtime PM framework should be
> told that the device is active, and not disabled so that the hardware
> state is in sync with runtime PM state.
>
> To fix, after the device has been created/registered, call
> omap_device_enable() to finialize init and use pm_runtime_set_active()
> to tell the runtime PM core the device is enabled.
>
> Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
> 3730/Beagle-xM, 4460/PandaES.
>
> Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Sourav Poddar <sourav.poddar@ti.com>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> Applies to v3.7-rc1.
> v2: call omap_device_enable() only after oh->mux has been initialized
> otherwise, IO ring wakeups not properly enabled.
>
> arch/arm/mach-omap2/serial.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 0405c81..a507cd6 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -329,6 +329,11 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
>
> oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
>
> + if (console_uart_id == bdata->id) {
> + omap_device_enable(pdev);
> + pm_runtime_set_active(&pdev->dev);
> + }
> +
> oh->dev_attr = uart;
>
> if (((cpu_is_omap34xx() || cpu_is_omap44xx()) && bdata->pads)
Tested on 3630/Beagle-xm, 4430/Panda, 4430/Sdp, 5430/Evm.
Tested-by: Sourav Poddar <sourav.poddar@ti.com>
^ permalink raw reply
* [PATCH RESEND] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS
From: Prabhakar Lad @ 2012-10-22 12:12 UTC (permalink / raw)
To: linux-arm-kernel
From: Lad, Prabhakar <prabhakar.lad@ti.com>
This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
out.
Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
---
Resending the patch since, it didn't reach the DLOS mailing list.
This patch is based on the following patch series,
ARM: davinci: dm365 EVM: add support for VPBE display
(https://patchwork.kernel.org/patch/1295071/)
arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 2924d61..771abb5 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -514,7 +514,7 @@ static struct vpbe_output dm365evm_vpbe_outputs[] = {
.index = 1,
.name = "Component",
.type = V4L2_OUTPUT_TYPE_ANALOG,
- .capabilities = V4L2_OUT_CAP_CUSTOM_TIMINGS,
+ .capabilities = V4L2_OUT_CAP_DV_TIMINGS,
},
.subdev_name = VPBE_VENC_SUBDEV_NAME,
.default_mode = "480p59_94",
--
1.7.4.1
^ permalink raw reply related
* [PATCH] arm: sched: stop sched_clock() during suspend
From: Felipe Balbi @ 2012-10-22 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350906877-19410-1-git-send-email-balbi@ti.com>
Hi,
On Mon, Oct 22, 2012 at 02:54:37PM +0300, Felipe Balbi wrote:
> The scheduler imposes a requirement to sched_clock()
> which is to stop the clock during suspend, if we don't
> do that IRQ threads will be rescheduled in the future
> which might cause transfers to timeout depending on
> how driver is written.
>
> This became an issue on OMAP when we converted omap-i2c.c
> to use threaded IRQs, it turned out that depending on how
> much time we spent on suspend, the I2C IRQ thread would
> end up being rescheduled so far in the future that I2C
> transfers would timeout and, because omap_hsmmc depends
> on an I2C-connected device to detect if an MMC card is
> inserted in the slot, our rootfs would just vanish.
>
> arch/arm/kernel/sched_clock.c already had an optional
> implementation (sched_clock_needs_suspend()) which would
> handle scheduler's requirement properly, what this patch
> does is simply to make that implementation non-optional.
>
> This has been tested with beagleboard XM (OMAP3630) and
> pandaboard rev A3 (OMAP4430). Suspend to RAM is now working
> after this patch.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
just adding more guys to Cc. Please add more if I have missed someone.
> ---
> arch/arm/include/asm/sched_clock.h | 2 --
> arch/arm/kernel/sched_clock.c | 18 ++++--------------
> 2 files changed, 4 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/include/asm/sched_clock.h b/arch/arm/include/asm/sched_clock.h
> index 05b8e82..e3f7572 100644
> --- a/arch/arm/include/asm/sched_clock.h
> +++ b/arch/arm/include/asm/sched_clock.h
> @@ -10,7 +10,5 @@
>
> extern void sched_clock_postinit(void);
> extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
> -extern void setup_sched_clock_needs_suspend(u32 (*read)(void), int bits,
> - unsigned long rate);
>
> #endif
> diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
> index e21bac2..fc6692e 100644
> --- a/arch/arm/kernel/sched_clock.c
> +++ b/arch/arm/kernel/sched_clock.c
> @@ -107,13 +107,6 @@ static void sched_clock_poll(unsigned long wrap_ticks)
> update_sched_clock();
> }
>
> -void __init setup_sched_clock_needs_suspend(u32 (*read)(void), int bits,
> - unsigned long rate)
> -{
> - setup_sched_clock(read, bits, rate);
> - cd.needs_suspend = true;
> -}
> -
> void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
> {
> unsigned long r, w;
> @@ -189,18 +182,15 @@ void __init sched_clock_postinit(void)
> static int sched_clock_suspend(void)
> {
> sched_clock_poll(sched_clock_timer.data);
> - if (cd.needs_suspend)
> - cd.suspended = true;
> + cd.suspended = true;
> return 0;
> }
>
> static void sched_clock_resume(void)
> {
> - if (cd.needs_suspend) {
> - cd.epoch_cyc = read_sched_clock();
> - cd.epoch_cyc_copy = cd.epoch_cyc;
> - cd.suspended = false;
> - }
> + cd.epoch_cyc = read_sched_clock();
> + cd.epoch_cyc_copy = cd.epoch_cyc;
> + cd.suspended = false;
> }
>
> static struct syscore_ops sched_clock_ops = {
> --
> 1.8.0.rc0
>
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121022/01b6c272/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support
From: Thierry Reding @ 2012-10-22 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210221150.22004.arnd@arndb.de>
On Mon, Oct 22, 2012 at 11:50:21AM +0000, Arnd Bergmann wrote:
> On Monday 22 October 2012, Thierry Reding wrote:
> > On Mon, Oct 22, 2012 at 07:51:52PM +1300, Tony Prisk wrote:
> > > Replies to your comments inline:
> > >
> > > On Mon, 2012-10-22 at 08:34 +0200, Thierry Reding wrote:
> > > ...
> > > > > -static int __devinit pwm_probe(struct platform_device *pdev)
> > > > > +static const struct of_device_id vt8500_pwm_dt_ids[] = {
> > > > > + { .compatible = "via,vt8500-pwm", },
> > > > > + { /* Sentinel */ }
> > > > > +};
> > > > > +
> > > > > +static int __devinit vt8500_pwm_probe(struct platform_device *pdev)
> > > >
> > > > Since you're changing this line anyway, maybe you should drop __devinit
> > > > (and __devexit for the .remove() callback). HOTPLUG is always enabled
> > > > nowadays and will go away eventually, in which case these will need to
> > > > be removed anyway.
> > >
> > > Will do. I must say the inconstancy among comments is rather
> > > frustrating. In another patch I sent out a few days ago (completely
> > > unrelated to this), I told to add __devexit to a remove() function :\
> >
> > This is a rather recent development, so maybe not everyone knows about
> > it yet. You can look at the following commit for the details:
> >
> > 45f035ab9b8f45aaf1eb2213218b7e9c14af3fc2
> >
> > It's been in linux-next for about 6 weeks and has also gone into
> > 3.7-rc1.
>
> As long as we get build warnings for leaving out the __devinit/__devexit
> annotations, I would generally recommend putting them in. If we do a
> patch to remove all of them, a couple extra instances will not cause
> any more troubles than we already have.
I've never seen any build warnings for leaving __devinit/__devexit out.
Where does that happen?
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121022/1edd4237/attachment.sig>
^ permalink raw reply
* [PATCH 3/4] ARM/dts: omap5: Update UART with address space and interrupts
From: Benoit Cousson @ 2012-10-22 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5085348C.60105@ti.com>
On 10/22/2012 01:57 PM, Benoit Cousson wrote:
> Hi Sourav,
>
> On 10/22/2012 01:16 PM, Sourav wrote:
>> Hi Sebastien,
>> On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
>>> Add base address and interrupt line inside Device Tree data for
>> Incomplete sentence!
>>> Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
>>> ---
>>> arch/arm/boot/dts/omap5.dtsi | 16 ++++++++++++++--
>>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>>> index 6c22e1b..413df94 100644
>>> --- a/arch/arm/boot/dts/omap5.dtsi
>>> +++ b/arch/arm/boot/dts/omap5.dtsi
>>> @@ -237,36 +237,48 @@
>>> uart1: serial at 4806a000 {
>>> compatible = "ti,omap4-uart";
>>> + reg = <0x4806a000 0x100>;
>>> + interrupts = <0 72 0x4>;
>>> ti,hwmods = "uart1";
>>> clock-frequency = <48000000>;
>>> };
>>> uart2: serial at 4806c000 {
>>> compatible = "ti,omap4-uart";
>>> + reg = <0x4806c000 0x100>;
>>> + interrupts = <0 73 0x4>;
>>> ti,hwmods = "uart2";
>>> clock-frequency = <48000000>;
>>> };
>>> uart3: serial at 48020000 {
>>> compatible = "ti,omap4-uart";
>>> + reg = <0x48020000 0x100>;
>>> + interrupts = <0 74 0x4>;
>>> ti,hwmods = "uart3";
>>> clock-frequency = <48000000>;
>>> };
>>> uart4: serial at 4806e000 {
>>> compatible = "ti,omap4-uart";
>>> + reg = <0x4806e000 0x100>;
>>> + interrupts = <0 70 0x4>;
>>> ti,hwmods = "uart4";
>>> clock-frequency = <48000000>;
>>> };
>>> uart5: serial at 48066000 {
>>> - compatible = "ti,omap5-uart";
>>> + compatible = "ti,omap4-uart";
>>> + reg = <0x48066000 0x100>;
>>> + interrupts = <0 105 0x4>;
>> In Omap5 TRM, the interrupt number mentioned for uart5 is 138. How is
>> 105 coming?
>
> It is from hwmod and thus from the HW spec. It looks like the TRM is
> wrong... or the HW spec :-)
>
>>> ti,hwmods = "uart5";
>>> clock-frequency = <48000000>;
>>> };
>>> uart6: serial at 48068000 {
>>> - compatible = "ti,omap6-uart";
>>> + compatible = "ti,omap4-uart";
>>> + reg = <0x48068000 0x100>;
>>> + interrupts = <0 106 0x4>;
>> Same here, TRM shows this number to be 139 ?
In fact, even the TRM (ES1.0 NDA vM) is aligned with these data.
Where did you see 138 and 139?
Regards,
Benoit
^ permalink raw reply
* [PATCH 3/4] ARM/dts: omap5: Update UART with address space and interrupts
From: Benoit Cousson @ 2012-10-22 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50852AF9.10703@ti.com>
Hi Sourav,
On 10/22/2012 01:16 PM, Sourav wrote:
> Hi Sebastien,
> On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
>> Add base address and interrupt line inside Device Tree data for
> Incomplete sentence!
>> Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
>> ---
>> arch/arm/boot/dts/omap5.dtsi | 16 ++++++++++++++--
>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>> index 6c22e1b..413df94 100644
>> --- a/arch/arm/boot/dts/omap5.dtsi
>> +++ b/arch/arm/boot/dts/omap5.dtsi
>> @@ -237,36 +237,48 @@
>> uart1: serial at 4806a000 {
>> compatible = "ti,omap4-uart";
>> + reg = <0x4806a000 0x100>;
>> + interrupts = <0 72 0x4>;
>> ti,hwmods = "uart1";
>> clock-frequency = <48000000>;
>> };
>> uart2: serial at 4806c000 {
>> compatible = "ti,omap4-uart";
>> + reg = <0x4806c000 0x100>;
>> + interrupts = <0 73 0x4>;
>> ti,hwmods = "uart2";
>> clock-frequency = <48000000>;
>> };
>> uart3: serial at 48020000 {
>> compatible = "ti,omap4-uart";
>> + reg = <0x48020000 0x100>;
>> + interrupts = <0 74 0x4>;
>> ti,hwmods = "uart3";
>> clock-frequency = <48000000>;
>> };
>> uart4: serial at 4806e000 {
>> compatible = "ti,omap4-uart";
>> + reg = <0x4806e000 0x100>;
>> + interrupts = <0 70 0x4>;
>> ti,hwmods = "uart4";
>> clock-frequency = <48000000>;
>> };
>> uart5: serial at 48066000 {
>> - compatible = "ti,omap5-uart";
>> + compatible = "ti,omap4-uart";
>> + reg = <0x48066000 0x100>;
>> + interrupts = <0 105 0x4>;
> In Omap5 TRM, the interrupt number mentioned for uart5 is 138. How is
> 105 coming?
It is from hwmod and thus from the HW spec. It looks like the TRM is
wrong... or the HW spec :-)
>> ti,hwmods = "uart5";
>> clock-frequency = <48000000>;
>> };
>> uart6: serial at 48068000 {
>> - compatible = "ti,omap6-uart";
>> + compatible = "ti,omap4-uart";
>> + reg = <0x48068000 0x100>;
>> + interrupts = <0 106 0x4>;
> Same here, TRM shows this number to be 139 ?
Same source.
Regards,
Benoit
^ permalink raw reply
* [PATCH] arm: sched: stop sched_clock() during suspend
From: Felipe Balbi @ 2012-10-22 11:54 UTC (permalink / raw)
To: linux-arm-kernel
The scheduler imposes a requirement to sched_clock()
which is to stop the clock during suspend, if we don't
do that IRQ threads will be rescheduled in the future
which might cause transfers to timeout depending on
how driver is written.
This became an issue on OMAP when we converted omap-i2c.c
to use threaded IRQs, it turned out that depending on how
much time we spent on suspend, the I2C IRQ thread would
end up being rescheduled so far in the future that I2C
transfers would timeout and, because omap_hsmmc depends
on an I2C-connected device to detect if an MMC card is
inserted in the slot, our rootfs would just vanish.
arch/arm/kernel/sched_clock.c already had an optional
implementation (sched_clock_needs_suspend()) which would
handle scheduler's requirement properly, what this patch
does is simply to make that implementation non-optional.
This has been tested with beagleboard XM (OMAP3630) and
pandaboard rev A3 (OMAP4430). Suspend to RAM is now working
after this patch.
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
arch/arm/include/asm/sched_clock.h | 2 --
arch/arm/kernel/sched_clock.c | 18 ++++--------------
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/sched_clock.h b/arch/arm/include/asm/sched_clock.h
index 05b8e82..e3f7572 100644
--- a/arch/arm/include/asm/sched_clock.h
+++ b/arch/arm/include/asm/sched_clock.h
@@ -10,7 +10,5 @@
extern void sched_clock_postinit(void);
extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
-extern void setup_sched_clock_needs_suspend(u32 (*read)(void), int bits,
- unsigned long rate);
#endif
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index e21bac2..fc6692e 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -107,13 +107,6 @@ static void sched_clock_poll(unsigned long wrap_ticks)
update_sched_clock();
}
-void __init setup_sched_clock_needs_suspend(u32 (*read)(void), int bits,
- unsigned long rate)
-{
- setup_sched_clock(read, bits, rate);
- cd.needs_suspend = true;
-}
-
void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
{
unsigned long r, w;
@@ -189,18 +182,15 @@ void __init sched_clock_postinit(void)
static int sched_clock_suspend(void)
{
sched_clock_poll(sched_clock_timer.data);
- if (cd.needs_suspend)
- cd.suspended = true;
+ cd.suspended = true;
return 0;
}
static void sched_clock_resume(void)
{
- if (cd.needs_suspend) {
- cd.epoch_cyc = read_sched_clock();
- cd.epoch_cyc_copy = cd.epoch_cyc;
- cd.suspended = false;
- }
+ cd.epoch_cyc = read_sched_clock();
+ cd.epoch_cyc_copy = cd.epoch_cyc;
+ cd.suspended = false;
}
static struct syscore_ops sched_clock_ops = {
--
1.8.0.rc0
^ permalink raw reply related
* [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support
From: Arnd Bergmann @ 2012-10-22 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022071118.GA30026@avionic-0098.mockup.avionic-design.de>
On Monday 22 October 2012, Thierry Reding wrote:
> On Mon, Oct 22, 2012 at 07:51:52PM +1300, Tony Prisk wrote:
> > Replies to your comments inline:
> >
> > On Mon, 2012-10-22 at 08:34 +0200, Thierry Reding wrote:
> > ...
> > > > -static int __devinit pwm_probe(struct platform_device *pdev)
> > > > +static const struct of_device_id vt8500_pwm_dt_ids[] = {
> > > > + { .compatible = "via,vt8500-pwm", },
> > > > + { /* Sentinel */ }
> > > > +};
> > > > +
> > > > +static int __devinit vt8500_pwm_probe(struct platform_device *pdev)
> > >
> > > Since you're changing this line anyway, maybe you should drop __devinit
> > > (and __devexit for the .remove() callback). HOTPLUG is always enabled
> > > nowadays and will go away eventually, in which case these will need to
> > > be removed anyway.
> >
> > Will do. I must say the inconstancy among comments is rather
> > frustrating. In another patch I sent out a few days ago (completely
> > unrelated to this), I told to add __devexit to a remove() function :\
>
> This is a rather recent development, so maybe not everyone knows about
> it yet. You can look at the following commit for the details:
>
> 45f035ab9b8f45aaf1eb2213218b7e9c14af3fc2
>
> It's been in linux-next for about 6 weeks and has also gone into
> 3.7-rc1.
As long as we get build warnings for leaving out the __devinit/__devexit
annotations, I would generally recommend putting them in. If we do a
patch to remove all of them, a couple extra instances will not cause
any more troubles than we already have.
Arnd
^ permalink raw reply
* [PATCH] ARM/dts: omap3: Fix mcbsp2/3 hwmods to be able to probe the drivers for audio
From: Péter Ujfalusi @ 2012-10-22 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507FD32C.7010108@ti.com>
Hi Tony,
On 10/18/2012 12:00 PM, Benoit Cousson wrote:
> On 10/18/2012 11:25 AM, Peter Ujfalusi wrote:
>> Fixes the following errors:
>> [ 2.318084] omap-mcbsp 49022000.mcbsp: invalid rx DMA channel
>> [ 2.324432] omap-mcbsp 49024000.mcbsp: invalid rx DMA channel
>>
>> Which is because we failed to link the sidetone hwmod for McBSP2/3. The
>> missing sidetone hwmod link will prevent omap_device_alloc() to append the
>> DMA resources since we - accidentally - end up having the same number of
>> resources provided from DT (IO/IRQ) as we have in hwmod for the McBSP ports
>> without the ST resources.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>
> Acked-by: Benoit Cousson <b-cousson@ti.com>
Can you take this patch for -rc3?
Thanks,
P?ter
>
> Regards,
> Benoit
>
>> ---
>>
>> Hi Tony, Benoit,
>>
>> Can you please take this patch for 3.7 since if we boot with DT audio will not
>> work on BeagleBoard and on boards which uses McBSP2 or 3 for audio.
>>
>> Thank you,
>> Peter
>>
>> arch/arm/boot/dts/omap3.dtsi | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>> index f38ea87..696e929 100644
>> --- a/arch/arm/boot/dts/omap3.dtsi
>> +++ b/arch/arm/boot/dts/omap3.dtsi
>> @@ -257,7 +257,7 @@
>> interrupt-names = "common", "tx", "rx", "sidetone";
>> interrupt-parent = <&intc>;
>> ti,buffer-size = <1280>;
>> - ti,hwmods = "mcbsp2";
>> + ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
>> };
>>
>> mcbsp3: mcbsp at 49024000 {
>> @@ -272,7 +272,7 @@
>> interrupt-names = "common", "tx", "rx", "sidetone";
>> interrupt-parent = <&intc>;
>> ti,buffer-size = <128>;
>> - ti,hwmods = "mcbsp3";
>> + ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
>> };
>>
>> mcbsp4: mcbsp at 49026000 {
>>
>
^ permalink raw reply
* [PATCH 3/4] ARM/dts: omap5: Update UART with address space and interrupts
From: Sourav @ 2012-10-22 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350901328-3525-4-git-send-email-s-guiriec@ti.com>
Hi Sebastien,
On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
> Add base address and interrupt line inside Device Tree data for
Incomplete sentence!
> Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
> ---
> arch/arm/boot/dts/omap5.dtsi | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 6c22e1b..413df94 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -237,36 +237,48 @@
>
> uart1: serial at 4806a000 {
> compatible = "ti,omap4-uart";
> + reg = <0x4806a000 0x100>;
> + interrupts = <0 72 0x4>;
> ti,hwmods = "uart1";
> clock-frequency = <48000000>;
> };
>
> uart2: serial at 4806c000 {
> compatible = "ti,omap4-uart";
> + reg = <0x4806c000 0x100>;
> + interrupts = <0 73 0x4>;
> ti,hwmods = "uart2";
> clock-frequency = <48000000>;
> };
>
> uart3: serial at 48020000 {
> compatible = "ti,omap4-uart";
> + reg = <0x48020000 0x100>;
> + interrupts = <0 74 0x4>;
> ti,hwmods = "uart3";
> clock-frequency = <48000000>;
> };
>
> uart4: serial at 4806e000 {
> compatible = "ti,omap4-uart";
> + reg = <0x4806e000 0x100>;
> + interrupts = <0 70 0x4>;
> ti,hwmods = "uart4";
> clock-frequency = <48000000>;
> };
>
> uart5: serial at 48066000 {
> - compatible = "ti,omap5-uart";
> + compatible = "ti,omap4-uart";
> + reg = <0x48066000 0x100>;
> + interrupts = <0 105 0x4>;
In Omap5 TRM, the interrupt number mentioned for uart5 is 138. How is
105 coming?
> ti,hwmods = "uart5";
> clock-frequency = <48000000>;
> };
>
> uart6: serial at 48068000 {
> - compatible = "ti,omap6-uart";
> + compatible = "ti,omap4-uart";
> + reg = <0x48068000 0x100>;
> + interrupts = <0 106 0x4>;
Same here, TRM shows this number to be 139 ?
> ti,hwmods = "uart6";
> clock-frequency = <48000000>;
> };
^ permalink raw reply
* [PATCH 2/4] ARM/dts: omap5: Update I2C with address space and interrupts
From: Shubhrajyoti Datta @ 2012-10-22 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350901328-3525-3-git-send-email-s-guiriec@ti.com>
On Mon, Oct 22, 2012 at 3:52 PM, Sebastien Guiriec <s-guiriec@ti.com> wrote:
> Add base address and interrupt line inside Device Tree data for
> OMAP5
Looks good to me.
Thanks ,
Reviewed-by: Shubhrajyoti D <shubhrajyoti@ti.com>
>
> Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
> ---
> arch/arm/boot/dts/omap5.dtsi | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 9e39f9f..6c22e1b 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -192,6 +192,8 @@
>
> i2c1: i2c at 48070000 {
> compatible = "ti,omap4-i2c";
> + reg = <0x48070000 0x100>;
> + interrupts = <0 56 0x4>;
> #address-cells = <1>;
> #size-cells = <0>;
> ti,hwmods = "i2c1";
> @@ -199,6 +201,8 @@
>
> i2c2: i2c at 48072000 {
> compatible = "ti,omap4-i2c";
> + reg = <0x48072000 0x100>;
> + interrupts = <0 57 0x4>;
> #address-cells = <1>;
> #size-cells = <0>;
> ti,hwmods = "i2c2";
> @@ -206,20 +210,26 @@
>
> i2c3: i2c at 48060000 {
> compatible = "ti,omap4-i2c";
> + reg = <0x48060000 0x100>;
> + interrupts = <0 61 0x4>;
> #address-cells = <1>;
> #size-cells = <0>;
> ti,hwmods = "i2c3";
> };
>
> - i2c4: i2c at 4807A000 {
> + i2c4: i2c at 4807a000 {
> compatible = "ti,omap4-i2c";
> + reg = <0x4807a000 0x100>;
> + interrupts = <0 62 0x4>;
> #address-cells = <1>;
> #size-cells = <0>;
> ti,hwmods = "i2c4";
> };
>
> - i2c5: i2c at 4807C000 {
> + i2c5: i2c at 4807c000 {
> compatible = "ti,omap4-i2c";
> + reg = <0x4807c000 0x100>;
> + interrupts = <0 60 0x4>;
> #address-cells = <1>;
> #size-cells = <0>;
> ti,hwmods = "i2c5";
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2 0/7] support the cpts found on am335x devices
From: Richard Cochran @ 2012-10-22 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9FD697@DBDE01.ent.ti.com>
On Mon, Oct 22, 2012 at 10:39:40AM +0000, N, Mugunthan V wrote:
>
> I think the timecounter_init initializes only the software. But still I am
> not clear how the time given in cpts_ptp_settime will be projected to
> hardware. Can you correct me if I am wrong.
Look at the settime function:
+static int cpts_ptp_settime(struct ptp_clock_info *ptp,
+ const struct timespec *ts)
+{
+ u64 ns;
+ unsigned long flags;
+ struct cpts *cpts = container_of(ptp, struct cpts, info);
+
+ ns = ts->tv_sec * 1000000000ULL;
+ ns += ts->tv_nsec;
+
+ spin_lock_irqsave(&cpts->lock, flags);
+ timecounter_init(&cpts->tc, &cpts->cc, ns);
+ spin_unlock_irqrestore(&cpts->lock, flags);
+
+ return 0;
+}
Then, look at the implementation of timecounter_init().
> > > Since we poll for the 32bit over flow for every HZ * 8 cycle, won't
> > > there be a system overhead. If the CPTS ref clock is changed
> > according
> > > to the ptp freq adjust api, how will the timecounter take care of
> > change
> > > in frequency
> >
> > There is nothing to do here. What are you asking?
>
> I think instead of fixing the driver to AM335X, let's make the driver
> generic as the same driver can be used to TI814X, TI813X and other
> upcoming platforms TI811X where the CPTS ref clock can be changed as
> per usage requirement.
Now I see what your are worried about, but it really isn't a big
problem. The solution in your driver of doing a 64 bit division in the
hot path is unattractive and unnecessary. We can accomodate variable
reference clock frequencies using a board specific DT, just as we do
for gianfar today.
Let's just get the am335x working, shall we? Until we actually have
the other boards working, all this talk about TI81xx is really just
talk. I mean, ATM the CPSW does not work on *any* board at all.
> > I hope that you meant, "better if we can configure _either_ slave."
> > Considering how SO_TIMESTAMPING works, you can't use both at once.
> >
>
> Since CPSW as a Ethernet switch, the PTP packet can be delivered to
> any downstream port. So if we fix the PTP time stamping to one port
> then the driver won't receive time stamping information when the packet
> is delivered to the other port.
And just how is this supposed to work with SO_TIMESTAMPING?
Thanks,
Richard
^ permalink raw reply
* [RFC PATCH v2] ARM hardcoded instruction causes cpu-hotplug fail to work on big-endian platfrom
From: Fei Yang @ 2012-10-22 11:01 UTC (permalink / raw)
To: linux-arm-kernel
2012/10/17 Fei Yang <yangfei.kernel@gmail.com>:
> <cut>
>
>> Not handling the Thumb case is a definite bug for any file which may
>> run on v7, since the kernel could be built in Thumb for that case.
>> For example, the existing code is mach-realview/hotplug.c is broken
>> when building an SMP Thumb-2 kernel for the Realview PBX-A9.
>>
>> Cheers
>> ---Dave
>
> Thanks for pointing this out. I think we just cannot make any
> assumption about the versions of the tools used. Based on this, I have
> made a v2 of the patch against linux-3.7-rc1. I am not touching the
> CFLAGS in the patch as I am not familiar with the three ARM boards
> here.
> Can the respective board maintainers
> (mach-exynos/mach-realveiw/mach-shmobile) give any comments about v2
> of the patch?
>
> Thanks.
> ---Fei
>
> v2: Define opcode of the ARM "WFI" instruction in the right way.
>
> Signed-off-by: Fei Yang<yangfei.kernel@gmail.com>
>
> diff -urN linux-3.7-rc1/arch/arm/mach-exynos/hotplug.c
> linux/arch/arm/mach-exynos/hotplug.c
> --- linux-3.7-rc1/arch/arm/mach-exynos/hotplug.c 2012-10-15
> 05:41:04.000000000 +0800
> +++ linux/arch/arm/mach-exynos/hotplug.c 2012-10-17 19:25:49.000000000 +0800
> @@ -18,11 +18,17 @@
> #include <asm/cacheflush.h>
> #include <asm/cp15.h>
> #include <asm/smp_plat.h>
> +#include <asm/opcodes.h>
>
> #include <mach/regs-pmu.h>
>
> #include "common.h"
>
> +/*
> + * Define opcode of the WFI instruction.
> + */
> +#define __WFI __inst_arm_thumb16(0xe320f003, 0xbf30)
> +
> static inline void cpu_enter_lowpower(void)
> {
> unsigned int v;
> @@ -72,7 +78,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(__WFI
> :
> :
> : "memory", "cc");
> diff -urN linux-3.7-rc1/arch/arm/mach-realview/hotplug.c
> linux/arch/arm/mach-realview/hotplug.c
> --- linux-3.7-rc1/arch/arm/mach-realview/hotplug.c 2012-10-15
> 05:41:04.000000000 +0800
> +++ linux/arch/arm/mach-realview/hotplug.c 2012-10-17 19:25:20.000000000 +0800
> @@ -15,6 +15,12 @@
> #include <asm/cacheflush.h>
> #include <asm/cp15.h>
> #include <asm/smp_plat.h>
> +#include <asm/opcodes.h>
> +
> +/*
> + * Define opcode of the WFI instruction.
> + */
> +#define __WFI __inst_arm_thumb16(0xe320f003, 0xbf30)
>
> static inline void cpu_enter_lowpower(void)
> {
> @@ -64,7 +70,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(__WFI
> :
> :
> : "memory", "cc");
> diff -urN linux-3.7-rc1/arch/arm/mach-shmobile/hotplug.c
> linux/arch/arm/mach-shmobile/hotplug.c
> --- linux-3.7-rc1/arch/arm/mach-shmobile/hotplug.c 2012-10-15
> 05:41:04.000000000 +0800
> +++ linux/arch/arm/mach-shmobile/hotplug.c 2012-10-17 19:25:34.000000000 +0800
> @@ -20,6 +20,12 @@
> #include <mach/emev2.h>
> #include <asm/cacheflush.h>
> #include <asm/mach-types.h>
> +#include <asm/opcodes.h>
> +
> +/*
> + * Define opcode of the WFI instruction.
> + */
> +#define __WFI __inst_arm_thumb16(0xe320f003, 0xbf30)
>
> static cpumask_t dead_cpus;
>
> @@ -39,7 +45,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(__WFI
> :
> :
> : "memory", "cc");
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Hi,
Any comments on this patch? It is posted last week. Please let me
know if I missed anything.
Thanks.
---Fei
^ permalink raw reply
* [PATCH V2 0/7] support the cpts found on am335x devices
From: N, Mugunthan V @ 2012-10-22 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017182714.GC2412@netboy.at.omicron.at>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran at gmail.com]
> Sent: Wednesday, October 17, 2012 11:57 PM
> To: N, Mugunthan V
> Cc: netdev at vger.kernel.org; linux-arm-kernel at lists.infradead.org; David
> Miller; Chemparathy, Cyril; Govindarajan, Sriramakrishnan
> Subject: Re: [PATCH V2 0/7] support the cpts found on am335x devices
>
> On Tue, Oct 16, 2012 at 11:11:29PM +0000, N, Mugunthan V wrote:
> >
> > Yes, I do agree that driver handles it. As Half roll over and Full
> roll
> > over events are not handled in the driver, I am just curious how will
> > the misaligned TS would be handled and also in cpts set time, the
> Lower
> > 32 bit time is written to CPTS counter
>
> #include <linux/clocksource.h>
I think the timecounter_init initializes only the software. But still I am
not clear how the time given in cpts_ptp_settime will be projected to
hardware. Can you correct me if I am wrong.
>
> > Since we poll for the 32bit over flow for every HZ * 8 cycle, won't
> > there be a system overhead. If the CPTS ref clock is changed
> according
> > to the ptp freq adjust api, how will the timecounter take care of
> change
> > in frequency
>
> There is nothing to do here. What are you asking?
I think instead of fixing the driver to AM335X, let's make the driver
generic as the same driver can be used to TI814X, TI813X and other
upcoming platforms TI811X where the CPTS ref clock can be changed as
per usage requirement.
>
> > The current driver which is in vanilla kernel doesn't use extended
> slave
> > address which are conflict between TI814x CPSW IP version and AM335x
> CPSW
> > IP version. I have just posted my version of CPTS implementation. May
> be
> > we can work together make the driver compatible with both CPSW
> versions
>
> Okay.
>
> > Since CPSW is a 3port Switch we should not fix time stamping will be
> enabled
> > only for slave 0 or passing slave number through DT. Its better if we
> > can configure both the slaves. This can be tested with EVM-sk which
> has
> > both the slave ports pinned out.
>
> I hope that you meant, "better if we can configure _either_ slave."
> Considering how SO_TIMESTAMPING works, you can't use both at once.
>
Since CPSW as a Ethernet switch, the PTP packet can be delivered to
any downstream port. So if we fix the PTP time stamping to one port
then the driver won't receive time stamping information when the packet
is delivered to the other port.
Regards
Mugunthan V N
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox