* [PATCH 6/8] pwm: pwm-tiehrpwm: Adding TBCLK gating support.
From: Bedia, Vaibhav @ 2012-11-06 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352106749-9437-7-git-send-email-avinashphilip@ti.com>
On Mon, Nov 05, 2012 at 14:42:27, Philip, Avinash wrote:
[...]
> + /* Some platforms require explicit tbclk gating */
> + if (of_property_read_bool(pdev->dev.of_node, "tbclkgating")) {
> + pc->tbclk = clk_get(&pdev->dev, "tbclk");
> + if (IS_ERR(pc->tbclk)) {
> + dev_err(&pdev->dev, "Could not get EHRPWM TBCLK\n");
> + return PTR_ERR(pc->tbclk);
> + }
> + }
> +
> + /* Enable tbclk & leave */
> + if (pc->tbclk)
> + clk_enable(pc->tbclk);
> +
Here also why are you leaving this clock always running?
Regards,
Vaibhav
^ permalink raw reply
* [PATCH 8/8] ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm
From: Bedia, Vaibhav @ 2012-11-06 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352106749-9437-9-git-send-email-avinashphilip@ti.com>
On Mon, Nov 05, 2012 at 14:42:29, Philip, Avinash wrote:
[...]
> + am33xx_pinmux: pinmux at 44e10800 {
> + ecap0_pins: backlight_pins {
> + pinctrl-single,pins = <
> + 0x164 0x0 /* eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
> + >;
> + };
> + };
> +
Ok I see the pinctrl entries here. Shouldn't this be done before
the change in the driver?
Regards.
Vaibhav
^ permalink raw reply
* [PATCH 5/8] pwm: pwm-tiehrpwm: Add device-tree binding support for EHRPWM driver
From: Bedia, Vaibhav @ 2012-11-06 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352106749-9437-6-git-send-email-avinashphilip@ti.com>
On Mon, Nov 05, 2012 at 14:42:26, Philip, Avinash wrote:
[...]
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/consumer.h>
Pinctrl changes should be separate patch. Morevoer, you don't mention
that you making this change.
> +
> +#include "tipwmss.h"
>
> /* EHRPWM registers and bits definitions */
>
> @@ -107,6 +111,10 @@
> #define AQCSFRC_CSFA_FRCHIGH BIT(1)
> #define AQCSFRC_CSFA_DISSWFRC (BIT(1) | BIT(0))
>
> +#define EPWMCLK_EN_SHIFT 8
> +
> +#define PWM_CELL_SIZE 3
> +
> #define NUM_PWM_CHANNEL 2 /* EHRPWM channels */
>
> struct ehrpwm_pwm_chip {
> @@ -392,12 +400,27 @@ static const struct pwm_ops ehrpwm_pwm_ops = {
> .owner = THIS_MODULE,
> };
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id ehrpwm_of_match[] = {
> + {
> + .compatible = "ti,am33xx-ehrpwm",
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ehrpwm_of_match);
> +#endif
> +
> static int __devinit ehrpwm_pwm_probe(struct platform_device *pdev)
> {
> int ret;
> struct resource *r;
> struct clk *clk;
> struct ehrpwm_pwm_chip *pc;
> + struct pinctrl *pinctrl;
> +
> + pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
I didn't see a patch adding the pinctrl entries.
> + if (IS_ERR(pinctrl))
> + dev_warn(&pdev->dev, "failed to configure pins from driver\n");
>
> pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
> if (!pc) {
> @@ -419,6 +442,7 @@ static int __devinit ehrpwm_pwm_probe(struct platform_device *pdev)
>
> pc->chip.dev = &pdev->dev;
> pc->chip.ops = &ehrpwm_pwm_ops;
> + pc->chip.of_pwm_n_cells = PWM_CELL_SIZE;
> pc->chip.base = -1;
> pc->chip.npwm = NUM_PWM_CHANNEL;
>
> @@ -437,8 +461,11 @@ static int __devinit ehrpwm_pwm_probe(struct platform_device *pdev)
> dev_err(&pdev->dev, "pwmchip_add() failed: %d\n", ret);
> return ret;
> }
> -
> pm_runtime_enable(&pdev->dev);
> + pm_runtime_get_sync(&pdev->dev);
> + pwmss_submodule_state_change(pdev->dev.parent, EPWMCLK_EN_SHIFT, true);
I think you should modify this API to return the status for drivers to check.
Another related question, why should this clock be enabled in probe and not only when it
is required? Shouldn't it be disabled in suspend?
Regards,
Vaibhav
^ permalink raw reply
* arm: Add ARM ERRATA 775420 workaround
From: jungseung lee @ 2012-11-06 6:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I have question the work-around code.
The below code will be enter after handling exception handling path. (that
is fix-up code)
As far as i know, the dsb instruction should be inserted before the any isb
instruction on exception handling code for breaking erratum condition .
It could meet the requirement?
> source "arch/arm/common/Kconfig"
> diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
> index 39e3fb3..3b17227 100644
> --- a/arch/arm/mm/cache-v7.S
> +++ b/arch/arm/mm/cache-v7.S
> @@ -211,6 +211,9 @@ ENTRY(v7_coherent_user_range)
> * isn't mapped, fail with -EFAULT.
> */
> 9001:
> +#ifdef CONFIG_ARM_ERRATA_775420
> + dsb
> +#endif
> mov r0, #-EFAULT
> mov pc, lr
> UNWIND(.fnend )
>
>
thanks
> On Thu, Sep 20, 2012 at 10:58:53AM +0100, Catalin Marinas wrote:
> > On 12 September 2012 08:14, Simon Horman wrote:
> > > +config ARM_ERRATA_775420
> > > + bool "ARM errata: A data cache maintenance operation which
aborts, might lead to deadlock"
> > > + depends on CPU_V7
> > > + help
> > > + This option enables the workaround for the 775420 Cortex-A9
(r2p2,
> > > + r2p6,r2p8,r2p10,r3p0) erratum. In case a date cache
maintenance
> > > + operation aborts with MMU exception, it might cause the
processor
> > > + deadlock. This workaround puts DSB before executing ISB at
the
> > > + beginning of the abort exception handler.
> > > +
> > > endmenu
> >
> > The only case where we can get an abort on cache maintenance is
> > v7_coherent_user_range(). I don't think we have any ISB on the
> > exception handling path for this function, so we could just add the
> > DSB there:
>
> I think that an advantage of Abe-san's implementation is that
> it might to be a bit more robust. But your proposal is certainly
> much cleaner and for that reason I agree it is a good option.
>
> I've updated the patch, but since the code is now all yours
> I'm unsure if the author should be changed or not.
>
> ----------------------------------------------------------------
> From: Kouei Abe
>
> arm: Add ARM ERRATA 775420 workaround
>
> Workaround for the 775420 Cortex-A9 (r2p2, r2p6,r2p8,r2p10,r3p0) erratum.
> In case a date cache maintenance operation aborts with MMU exception, it
> might cause the processor to deadlock. This workaround puts DSB before
> executing ISB if an abort may occur on cache maintenance.
>
> Based on work by Kouei Abe and feedback from Catalin Marinas.
>
> Cc: Catalin Marinas
> Signed-off-by: Kouei Abe
> Signed-off-by: Simon Horman
>
> ---
>
> v2
> * Add some details to changelog entry
> * Alternate implementation suggested by Catalin Marinas
> - Add the dsb directly to v7_coherent_user_range() rather
> than the exception handler
> ---
> arch/arm/Kconfig | 10 ++++++++++
> arch/arm/mm/cache-v7.S | 3 +++
> 2 files changed, 13 insertions(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2f88d8d..48c19d4 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1413,6 +1413,16 @@ config PL310_ERRATA_769419
> on systems with an outer cache, the store buffer is drained
> explicitly.
>
> +config ARM_ERRATA_775420
> + bool "ARM errata: A data cache maintenance operation which
aborts, might lead to deadlock"
> + depends on CPU_V7
> + help
> + This option enables the workaround for the 775420 Cortex-A9 (r2p2,
> + r2p6,r2p8,r2p10,r3p0) erratum. In case a date cache maintenance
> + operation aborts with MMU exception, it might cause the processor
> + to deadlock. This workaround puts DSB before executing ISB if
> + an abort may occur on cache maintenance.
> +
> endmenu
>
> source "arch/arm/common/Kconfig"
> diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
> index 39e3fb3..3b17227 100644
> --- a/arch/arm/mm/cache-v7.S
> +++ b/arch/arm/mm/cache-v7.S
> @@ -211,6 +211,9 @@ ENTRY(v7_coherent_user_range)
> * isn't mapped, fail with -EFAULT.
> */
> 9001:
> +#ifdef CONFIG_ARM_ERRATA_775420
> + dsb
> +#endif
> mov r0, #-EFAULT
> mov pc, lr
> UNWIND(.fnend )
> --
> 1.7.10.4
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121106/43b68033/attachment-0001.html>
^ permalink raw reply
* [PATCH 04/15] ARM: OMAP2+: hwmod: Update the reset API for AM33XX
From: Bedia, Vaibhav @ 2012-11-06 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB635A4@DBDE01.ent.ti.com>
On Tue, Nov 06, 2012 at 11:36:20, Hiremath, Vaibhav wrote:
[...]
>
> The code is checking whether the line is already de-asserted (== 0), so I am
> not sure how this will change if hardreset line is asserted during bootup.
You are right. I just checked the behavior since I recall seeing something odd
earlier. Looks like this is needed to avoid issues with subsequent hardreset
deassertions so I'll put it back in.
Regards.
Vaibhav
^ permalink raw reply
* [PATCH 15/16] mm: use vm_unmapped_area() on sparc32 architecture
From: Rik van Riel @ 2012-11-06 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105.202501.1246122770431623794.davem@davemloft.net>
On 11/05/2012 08:25 PM, David Miller wrote:
> From: Michel Lespinasse <walken@google.com>
> Date: Mon, 5 Nov 2012 14:47:12 -0800
>
>> Update the sparc32 arch_get_unmapped_area function to make use of
>> vm_unmapped_area() instead of implementing a brute force search.
>>
>> Signed-off-by: Michel Lespinasse <walken@google.com>
>
> Hmmm...
>
>> - if (flags & MAP_SHARED)
>> - addr = COLOUR_ALIGN(addr);
>> - else
>> - addr = PAGE_ALIGN(addr);
>
> What part of vm_unmapped_area() is going to duplicate this special
> aligning logic we need on sparc?
>
That would be this part:
+found:
+ /* We found a suitable gap. Clip it with the original low_limit. */
+ if (gap_start < info->low_limit)
+ gap_start = info->low_limit;
+
+ /* Adjust gap address to the desired alignment */
+ gap_start += (info->align_offset - gap_start) & info->align_mask;
+
+ VM_BUG_ON(gap_start + info->length > info->high_limit);
+ VM_BUG_ON(gap_start + info->length > gap_end);
+ return gap_start;
+}
^ permalink raw reply
* [PATCH 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
From: Bedia, Vaibhav @ 2012-11-06 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509829C5.100@ti.com>
Hi Jon,
On Tue, Nov 06, 2012 at 02:34:05, Hunter, Jon wrote:
[...]
> > static struct clock_event_device clockevent_gpt = {
> > .name = "gp_timer",
> > .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
> > @@ -142,6 +171,8 @@ static struct clock_event_device clockevent_gpt = {
> > .rating = 300,
> > .set_next_event = omap2_gp_timer_set_next_event,
> > .set_mode = omap2_gp_timer_set_mode,
> > + .suspend = omap_clkevt_suspend,
> > + .resume = omap_clkevt_resume,
>
> So these suspend/resume callbacks are going to be called for all OMAP2+
> and AMxxxx devices? I don't think we want that. AFAIK OMAP timers will
> idle on their own when stopped and don't require this.
>
IMO instead of skipping the callback registration we could have checks in the
suspend/resume callbacks to decide what to do.
I'll check if the idling part is AM33xx specific. If not, based on the recent timer
changes that you did, perhaps checking if the clockevent selected doesn't have the
"ti,timer-alwon" capability will be good enough. What do you think?
Regards.
Vaibhav
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Felipe Balbi @ 2012-11-06 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB6361E@DBDE01.ent.ti.com>
Hi,
On Tue, Nov 06, 2012 at 07:17:19AM +0100, Hiremath, Vaibhav wrote:
> On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
> > Hi,
> >
> > On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
> > > * Felipe Balbi <balbi@ti.com> [121030 10:34]:
> > > > Hi,
> > > >
> > > > On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > > > > * Vaibhav Hiremath <hvaibhav@ti.com> [121030 07:50]:
> > > > > > >
> > > > > > > MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
> > > > > > > already submitted to the list recently. So MMC support will come along with
> > > > > > > EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes.
> > > > >
> > > > > This is a bogus dependency, the MMC driver needs to also work
> > > > > without DMA.
> > > >
> > > > heh, too bad driver errors out when it doesn't find DMA channels :-)
> > >
> > > It should just print a warning instead and continue.
> > >
> > > > 1869 host->rx_chan = dma_request_channel(mask, omap_dma_filter_fn, &rx_req);
> > > > 1870 if (!host->rx_chan) {
> > > > 1871 dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine channel %u\n", rx_req);
> > > > 1872 ret = -ENXIO;
> > > > 1873 goto err_irq;
> > > > 1874 }
> > > > 1875
> > > > 1876 host->tx_chan = dma_request_channel(mask, omap_dma_filter_fn, &tx_req);
> > > > 1877 if (!host->tx_chan) {
> > > > 1878 dev_err(mmc_dev(host->mmc), "unable to obtain TX DMA engine channel %u\n", tx_req);
> > > > 1879 ret = -ENXIO;
> > > > 1880 goto err_irq;
> > > > 1881 }
> > > >
> > > > in fact, if DMAENGINE isn't enabled, this won't even compile due to
> > > > omap_dma_filter_fn() right ?
> > >
> > > It should, CONFIG_DMADEVICES is optional. If it does not compile,
> > > then there's a bug somewhere.
> >
> > you're right, there's a static inline nop for when we don't have omap
> > dma engine driver compiled.
> >
> > nevermind.
> >
>
> Did anybody tried polling mode MMC support on OMAP devices in the
> past?
why are you trying out polling when we have a working interrupt mode ?
--
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/20121106/6107e7d4/attachment.sig>
^ permalink raw reply
* [PATCH V2 RESEND 2/5] gpiolib: provide provision for gpiolib to register pin range
From: Linus Walleij @ 2012-11-06 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <77b462979e474f8b921d0f5ab8ac5b2a2fb2808e.1351330569.git.viresh.kumar@linaro.org>
On Sat, Oct 27, 2012 at 11:51 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> From: Shiraz Hashim <shiraz.hashim@st.com>
>
> pinctrl subsystem needs gpio chip base to prepare set of gpio pin ranges, which
> a given pinctrl driver can handle. This is important to handle pinctrl gpio
> request calls in order to program a given pin properly for gpio operation.
>
> As gpio base is allocated dynamically during gpiochip registration, presently
> there exists no clean way to pass this information to the pinctrl subsystem.
>
> After few discussions from [1], it was concluded that may be gpio controller
> reporting the pin range it supports, is a better way than pinctrl subsystem
> directly registering it.
>
> [1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816
>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com>
Hey thanks for working out the details of this!!
Patch applied, but I was a bit picky about the English in the
documentation so I patched it around a little, hope you don't
mind (diff below).
I will now try to make the U300 use this new range concep
as guinea pig, and that platform is *not* using DT so we'll
see for sure if it works :-)
Yours,
Linus Walleij
-gpio-controller and pinctrl subsystem
+GPIO controllers and the pinctrl subsystem
------------------------------------------
-gpio-controller on a SOC might be tightly coupled with the pinctrl
+A GPIO controller on a SOC might be tightly coupled with the pinctrl
subsystem, in the sense that the pins can be used by other functions
-together with optional gpio feature.
+together with an optional gpio feature. We have already covered the
+case where e.g. a GPIO controller need to reserve a pin or set the
+direction of a pin by calling any of:
-While the pin allocation is totally managed by the pin ctrl subsystem,
+pinctrl_request_gpio()
+pinctrl_free_gpio()
+pinctrl_gpio_direction_input()
+pinctrl_gpio_direction_output()
+
+But how does the pin control subsystem cross-correlate the GPIO
+numbers (which are a global business) to a certain pin on a certain
+pin controller?
+
+This is done by registering "ranges" of pins, which are essentially
+cross-reference tables. These are described in
+Documentation/pinctrl.txt
+
+While the pin allocation is totally managed by the pinctrl subsystem,
gpio (under gpiolib) is still maintained by gpio drivers. It may happen
that different pin ranges in a SoC is managed by different gpio drivers.
This makes it logical to let gpio drivers announce their pin ranges to
-the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to
-request the corresponding pin before any gpio usage.
+the pin ctrl subsystem before it will call 'pinctrl_request_gpio' in order
+to request the corresponding pin to be prepared by the pinctrl subsystem
+before any gpio usage.
-For this, the gpio controller can register its pin range with pinctrl subsystem
-There are two ways of doing it currently with or without DT.
+For this, the gpio controller can register its pin range with pinctrl
+subsystem. There are two ways of doing it currently: with or without DT.
For with DT support refer to Documentation/devicetree/bindings/gpio/gpio.txt.
For non-DT support, user can call gpiochip_add_pin_range() with appropriate
parameters to register a range of gpio pins with a pinctrl driver. For this
-exact name string of pinctrl device has to be passed as one of the argument to
-this routine.
+exact name string of pinctrl device has to be passed as one of the
+argument to this routine.
What do these conventions omit?
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Felipe Balbi @ 2012-11-06 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB63A74@DBDE01.ent.ti.com>
Hi,
On Tue, Nov 06, 2012 at 09:07:47AM +0100, Hiremath, Vaibhav wrote:
> On Tue, Nov 06, 2012 at 13:28:00, Balbi, Felipe wrote:
> > Hi,
> >
> > On Tue, Nov 06, 2012 at 07:17:19AM +0100, Hiremath, Vaibhav wrote:
> > > On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
> > > > Hi,
> > > >
> > > > On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
> > > > > * Felipe Balbi <balbi@ti.com> [121030 10:34]:
> > > > > > Hi,
> > > > > >
> > > > > > On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > > > > > > * Vaibhav Hiremath <hvaibhav@ti.com> [121030 07:50]:
> > > > > > > > >
> > > > > > > > > MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
> > > > > > > > > already submitted to the list recently. So MMC support will come along with
> > > > > > > > > EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes.
> > > > > > >
> > > > > > > This is a bogus dependency, the MMC driver needs to also work
> > > > > > > without DMA.
> > > > > >
> > > > > > heh, too bad driver errors out when it doesn't find DMA channels :-)
> > > > >
> > > > > It should just print a warning instead and continue.
> > > > >
> > > > > > 1869 host->rx_chan = dma_request_channel(mask, omap_dma_filter_fn, &rx_req);
> > > > > > 1870 if (!host->rx_chan) {
> > > > > > 1871 dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine channel %u\n", rx_req);
> > > > > > 1872 ret = -ENXIO;
> > > > > > 1873 goto err_irq;
> > > > > > 1874 }
> > > > > > 1875
> > > > > > 1876 host->tx_chan = dma_request_channel(mask, omap_dma_filter_fn, &tx_req);
> > > > > > 1877 if (!host->tx_chan) {
> > > > > > 1878 dev_err(mmc_dev(host->mmc), "unable to obtain TX DMA engine channel %u\n", tx_req);
> > > > > > 1879 ret = -ENXIO;
> > > > > > 1880 goto err_irq;
> > > > > > 1881 }
> > > > > >
> > > > > > in fact, if DMAENGINE isn't enabled, this won't even compile due to
> > > > > > omap_dma_filter_fn() right ?
> > > > >
> > > > > It should, CONFIG_DMADEVICES is optional. If it does not compile,
> > > > > then there's a bug somewhere.
> > > >
> > > > you're right, there's a static inline nop for when we don't have omap
> > > > dma engine driver compiled.
> > > >
> > > > nevermind.
> > > >
> > >
> > > Did anybody tried polling mode MMC support on OMAP devices in the
> > > past?
> >
> > why are you trying out polling when we have a working interrupt mode ?
> >
> The thread started with need of MMC support without EDMA. So when I
> say polling, I would like to try MMC without DMA support, not to put
> dependency on EDMA-DMA engine migration patches.
I see, so you meant interrupt/PIO mode. That's supposed to be working
and I'm sure Venkat and Balaji test that every now and then.
--
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/20121106/0d4d00f7/attachment.sig>
^ permalink raw reply
* [PATCH V2 1/5] Revert "pinctrl: remove pinctrl_remove_gpio_range"
From: Linus Walleij @ 2012-11-06 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d08146fb6ea692330a2b0c6a4fe2df75edc0f20e.1351330569.git.viresh.kumar@linaro.org>
On Sat, Oct 27, 2012 at 11:51 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> This reverts earlier commit which removed pinctrl_remove_gpio_range(), because
> at that time there aren't any more users of that routine. It was removed as the
> removal of ranges was done in unregister of pinctrl.
>
> But because we are registering stuff from gpiolib now, we may remove and insert
> a gpio module multiple times. So, we need that again.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied as prerequisite for patch 2.
Yours,
Linus Walleij
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Hiremath, Vaibhav @ 2012-11-06 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106075726.GA10873@arwen.pp.htv.fi>
On Tue, Nov 06, 2012 at 13:28:00, Balbi, Felipe wrote:
> Hi,
>
> On Tue, Nov 06, 2012 at 07:17:19AM +0100, Hiremath, Vaibhav wrote:
> > On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
> > > Hi,
> > >
> > > On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
> > > > * Felipe Balbi <balbi@ti.com> [121030 10:34]:
> > > > > Hi,
> > > > >
> > > > > On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > > > > > * Vaibhav Hiremath <hvaibhav@ti.com> [121030 07:50]:
> > > > > > > >
> > > > > > > > MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
> > > > > > > > already submitted to the list recently. So MMC support will come along with
> > > > > > > > EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes.
> > > > > >
> > > > > > This is a bogus dependency, the MMC driver needs to also work
> > > > > > without DMA.
> > > > >
> > > > > heh, too bad driver errors out when it doesn't find DMA channels :-)
> > > >
> > > > It should just print a warning instead and continue.
> > > >
> > > > > 1869 host->rx_chan = dma_request_channel(mask, omap_dma_filter_fn, &rx_req);
> > > > > 1870 if (!host->rx_chan) {
> > > > > 1871 dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine channel %u\n", rx_req);
> > > > > 1872 ret = -ENXIO;
> > > > > 1873 goto err_irq;
> > > > > 1874 }
> > > > > 1875
> > > > > 1876 host->tx_chan = dma_request_channel(mask, omap_dma_filter_fn, &tx_req);
> > > > > 1877 if (!host->tx_chan) {
> > > > > 1878 dev_err(mmc_dev(host->mmc), "unable to obtain TX DMA engine channel %u\n", tx_req);
> > > > > 1879 ret = -ENXIO;
> > > > > 1880 goto err_irq;
> > > > > 1881 }
> > > > >
> > > > > in fact, if DMAENGINE isn't enabled, this won't even compile due to
> > > > > omap_dma_filter_fn() right ?
> > > >
> > > > It should, CONFIG_DMADEVICES is optional. If it does not compile,
> > > > then there's a bug somewhere.
> > >
> > > you're right, there's a static inline nop for when we don't have omap
> > > dma engine driver compiled.
> > >
> > > nevermind.
> > >
> >
> > Did anybody tried polling mode MMC support on OMAP devices in the
> > past?
>
> why are you trying out polling when we have a working interrupt mode ?
>
The thread started with need of MMC support without EDMA.
So when I say polling, I would like to try MMC without DMA support, not to
put dependency on EDMA-DMA engine migration patches.
Thanks,
Vaibhav
> --
> balbi
>
^ permalink raw reply
* [PATCH V2 3/5] pinctrl: SPEAr: Add plgpio driver
From: Linus Walleij @ 2012-11-06 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fb1487265f89bd2ad0d215c5ed2d6be8b0958867.1351330569.git.viresh.kumar@linaro.org>
On Sat, Oct 27, 2012 at 11:51 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> Most of SPEAr SoCs, which support pinctrl, can configure & use pads as gpio.
> This patch adds plgpio driver for configuring these pads as gpio.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V2 RESEND 2/5] gpiolib: provide provision for gpiolib to register pin range
From: Viresh Kumar @ 2012-11-06 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYm6AUaRJQ3=G4tvkMrFEOpvkLC8oLFFeC5m235q21akA@mail.gmail.com>
On 6 November 2012 13:33, Linus Walleij <linus.walleij@linaro.org> wrote:
> Hey thanks for working out the details of this!!
>
> Patch applied, but I was a bit picky about the English in the
> documentation so I patched it around a little, hope you don't
> mind (diff below).
>
No way. Its just perfect. :)
> I will now try to make the U300 use this new range concep
> as guinea pig, and that platform is *not* using DT so we'll
> see for sure if it works :-)
Hope it works, as i haven't tested it at all. Don't have any SPEAr
board with me :)
Hope this long gpioi chain will end now.
--
viresh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121106/7918a549/attachment-0001.html>
^ permalink raw reply
* [PATCH V2 4/5] pinctrl: SPEAr: Add gpio ranges support
From: Linus Walleij @ 2012-11-06 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3b2f9fa0864f1f736e24ee0dbc081cd9a79b7468.1351330569.git.viresh.kumar@linaro.org>
On Sat, Oct 27, 2012 at 11:51 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> Most of SPEAr SoCs, which support pinctrl, can configure & use pads as gpio.
> This patch gpio enable support for SPEAr pinctrl drivers.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>
> It has few differences since the time it was last posted. I kept your Acked-by
> as the changes aren't that big (I believe). :)
This does not apply to my devel branch, so I guess it is dependent
on some of the stuff I just merged to fixes. I will send the
fixes up to Torvalds, then merge fixes to the devel branch
so we can proceed with patches 4 and 5, OK?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V2 4/5] pinctrl: SPEAr: Add gpio ranges support
From: Viresh Kumar @ 2012-11-06 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbRDi-TcDvVbAywMeWocfyYUrXS3a=e_GS5onXBj1Cdng@mail.gmail.com>
On 6 November 2012 13:39, Linus Walleij <linus.walleij@linaro.org> wrote:
> This does not apply to my devel branch, so I guess it is dependent
> on some of the stuff I just merged to fixes. I will send the
> fixes up to Torvalds, then merge fixes to the devel branch
> so we can proceed with patches 4 and 5, OK?
When will i learn how to send patches x-(
Yes, they were rebased over fixes.
--
viresh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121106/060b0d9e/attachment-0001.html>
^ permalink raw reply
* [PATCH 0/7] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
From: Mugunthan V N @ 2012-11-06 8:12 UTC (permalink / raw)
To: linux-arm-kernel
This patch-series adds support for,
[1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's
[2/7]: Adds parent<->child relation between CPSW & MDIO module inside cpsw
driver, as in case of AM33XX, the resources are shared and common
register bit-field is provided to control module/clock enable/disable,
makes it difficult to handle common resource.
So the solution here is, to create parent<->child relation between them.
[3/7]: Add hwmod entry for MDIO module, required for MDIO driver.
[4/7]: cpsw: simplify the setup of the register pointers
[5/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi,
am335x-evm.dts and am335x-bone.dts file
[6/7]: Enable CPSW support to omap2plus_defconfig
[7/7]: cpsw: Kernel warn fix during suspend
This patch series has been created on top of net-next/master and tested
on BeagleBone platform for NFS boot and basic ping test cases.
Mugunthan V N (4):
ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
ARM: OMAP2+: omap2plus_defconfig: Enable CPSW support
net: cpsw: halt network stack before halting the device during
suspend
Richard Cochran (1):
cpsw: simplify the setup of the register pointers
Vaibhav Hiremath (2):
net: davinci_mdio: Fix typo mistake in calling runtime-pm api
net: cpsw: Add parent<->child relation support between cpsw and mdio
Documentation/devicetree/bindings/net/cpsw.txt | 34 ----
arch/arm/boot/dts/am335x-bone.dts | 8 +
arch/arm/boot/dts/am335x-evm.dts | 8 +
arch/arm/boot/dts/am33xx.dtsi | 42 +++++
arch/arm/configs/omap2plus_defconfig | 3 +
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 32 ++++
drivers/net/ethernet/ti/cpsw.c | 231 ++++++++++--------------
drivers/net/ethernet/ti/davinci_mdio.c | 2 +-
include/linux/platform_data/cpsw.h | 19 --
9 files changed, 193 insertions(+), 186 deletions(-)
^ permalink raw reply
* [PATCH 1/7] net: davinci_mdio: Fix typo mistake in calling runtime-pm api
From: Mugunthan V N @ 2012-11-06 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352189545-26303-1-git-send-email-mugunthanvnm@ti.com>
From: Vaibhav Hiremath <hvaibhav@ti.com>
By mistake (most likely a copy-paste), instead of pm_runtime_get_sync()
api, driver is calling pm_runtime_put_sync() api in resume callback
function. The bug was introduced by commit id (ae2c07aaf74:
davinci_mdio: runtime PM support).
Now, the reason why it didn't impact functionality is, the patch has
been tested on AM335x-EVM and BeagleBone platform while submitting;
and in case of AM335x the MDIO driver doesn't control the module
enable/disable part, which is handled by CPSW driver.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Richard Cochran <richardcochran@gmail.com>
---
drivers/net/ethernet/ti/davinci_mdio.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 51a96db..ae74280 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -465,7 +465,7 @@ static int davinci_mdio_resume(struct device *dev)
u32 ctrl;
spin_lock(&data->lock);
- pm_runtime_put_sync(data->dev);
+ pm_runtime_get_sync(data->dev);
/* restart the scan state machine */
ctrl = __raw_readl(&data->regs->control);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/7] net: cpsw: Add parent<->child relation support between cpsw and mdio
From: Mugunthan V N @ 2012-11-06 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352189545-26303-1-git-send-email-mugunthanvnm@ti.com>
From: Vaibhav Hiremath <hvaibhav@ti.com>
CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
cpsw, etc... These sub-modules are also used in some of Davinci family
of devices. Now based on requirement, use-case and available technology
nodes the integration of these sub-modules varies across devices.
So coming back to Linux net driver, currently separate and independent
platform devices & drivers for CPSW and MDIO is implemented. In case of
Davinci they both has separate control, from resources perspective,
like clock.
In case of AM33XX, the resources are shared and only one register
bit-field is provided to control module/clock enable/disable, makes it
difficult to handle common resource.
So the solution here implemented in this patch is,
Create parent<->child relationship between both the drivers, making
CPSW as a parent and MDIO as its child and enumerate all the child nodes
under CPSW module.
Both the drivers will function exactly the way it was operating before,
including runtime-pm functionality. No change is required in MDIO driver
(for that matter to any child driver).
As this is only supported during DT boot, the parent<->child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making MDIO as a child to CPSW node.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Richard Cochran <richardcochran@gmail.com>
---
drivers/net/ethernet/ti/cpsw.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 7654a62..7007aba 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1144,7 +1144,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
data->mac_control = prop;
- for_each_child_of_node(node, slave_node) {
+ for_each_node_by_name(slave_node, "slave") {
struct cpsw_slave_data *slave_data = data->slave_data + i;
const char *phy_id = NULL;
const void *mac_addr = NULL;
@@ -1179,6 +1179,14 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
i++;
}
+ /*
+ * Populate all the child nodes here...
+ */
+ ret = of_platform_populate(node, NULL, NULL, &pdev->dev);
+ /* We do not want to force this, as in some cases may not have child */
+ if (ret)
+ pr_warn("Doesn't have any child node\n");
+
return 0;
error_ret:
@@ -1212,6 +1220,11 @@ static int __devinit cpsw_probe(struct platform_device *pdev)
priv->msg_enable = netif_msg_init(debug_level, CPSW_DEBUG);
priv->rx_packet_max = max(rx_packet_max, 128);
+ /*
+ * This may be required here for child devices.
+ */
+ pm_runtime_enable(&pdev->dev);
+
if (cpsw_probe_dt(&priv->data, pdev)) {
pr_err("cpsw: platform data missing\n");
ret = -ENODEV;
@@ -1238,7 +1251,6 @@ static int __devinit cpsw_probe(struct platform_device *pdev)
for (i = 0; i < data->slaves; i++)
priv->slaves[i].slave_num = i;
- pm_runtime_enable(&pdev->dev);
priv->clk = clk_get(&pdev->dev, "fck");
if (IS_ERR(priv->clk)) {
dev_err(&pdev->dev, "fck is not found\n");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/7] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
From: Mugunthan V N @ 2012-11-06 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352189545-26303-1-git-send-email-mugunthanvnm@ti.com>
This patch adds hwmod entry for davinci MDIO module,
creating parent<->child relationship between CPSW and MDIO module.
This Parent-child relation is required in order to use common resources
like, clock, but still maintaining the logical separation between them.
CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
cpsw, etc... These sub-modules are also used in some of Davinci
family of devices, so separate and independent platform devices &
drivers for CPSW and MDIO is implemented.
In case of AM33XX, the resources are shared and common register
bit-field is provided to control module/clock enable/disable,
makes it difficult to handle common resources from both drivers.
So the solution is, create parent<->child relationship between
CPGMAC & MDIO modules.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 32 ++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 59d5c1c..b3f9ce4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -674,6 +674,7 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
.name = "cpgmac0",
.class = &am33xx_cpgmac0_hwmod_class,
.clkdm_name = "cpsw_125mhz_clkdm",
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
.mpu_irqs = am33xx_cpgmac0_irqs,
.main_clk = "cpsw_125mhz_gclk",
.prcm = {
@@ -685,6 +686,20 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
};
/*
+ * mdio class
+ */
+static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
+ .name = "davinci_mdio",
+};
+
+static struct omap_hwmod am33xx_mdio_hwmod = {
+ .name = "davinci_mdio",
+ .class = &am33xx_mdio_hwmod_class,
+ .clkdm_name = "cpsw_125mhz_clkdm",
+ .main_clk = "cpsw_125mhz_gclk",
+};
+
+/*
* dcan class
*/
static struct omap_hwmod_class am33xx_dcan_hwmod_class = {
@@ -2501,6 +2516,22 @@ static struct omap_hwmod_ocp_if am33xx_l4_hs__cpgmac0 = {
.user = OCP_USER_MPU,
};
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4A101000,
+ .pa_end = 0x4A101000 + SZ_256 - 1,
+ .flags = ADDR_MAP_ON_INIT,
+ },
+ { }
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+ .master = &am33xx_cpgmac0_hwmod,
+ .slave = &am33xx_mdio_hwmod,
+ .addr = am33xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
{
.pa_start = 0x48080000,
@@ -3371,6 +3402,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
&am33xx_l3_main__tptc2,
&am33xx_l3_s__usbss,
&am33xx_l4_hs__cpgmac0,
+ &am33xx_cpgmac0__mdio,
NULL,
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH 4/7] cpsw: simplify the setup of the register pointers
From: Mugunthan V N @ 2012-11-06 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352189545-26303-1-git-send-email-mugunthanvnm@ti.com>
From: Richard Cochran <richardcochran@gmail.com>
Instead of having a host of different register offsets in the device tree,
this patch simplifies the CPSW code by letting the driver set the proper
register offsets automatically, based on the CPSW version.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
Documentation/devicetree/bindings/net/cpsw.txt | 34 ----
drivers/net/ethernet/ti/cpsw.c | 209 +++++++++--------------
include/linux/platform_data/cpsw.h | 19 --
3 files changed, 82 insertions(+), 180 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
index 2214607..6cf5d92 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -9,15 +9,7 @@ Required properties:
number
- interrupt-parent : The parent interrupt controller
- cpdma_channels : Specifies number of channels in CPDMA
-- host_port_no : Specifies host port shift
-- cpdma_reg_ofs : Specifies CPDMA submodule register offset
-- cpdma_sram_ofs : Specifies CPDMA SRAM offset
-- ale_reg_ofs : Specifies ALE submodule register offset
- ale_entries : Specifies No of entries ALE can hold
-- host_port_reg_ofs : Specifies host port register offset
-- hw_stats_reg_ofs : Specifies hardware statistics register offset
-- cpts_reg_ofs : Specifies the offset of the CPTS registers
-- bd_ram_ofs : Specifies internal desciptor RAM offset
- bd_ram_size : Specifies internal descriptor RAM size
- rx_descs : Specifies number of Rx descriptors
- mac_control : Specifies Default MAC control register content
@@ -26,8 +18,6 @@ Required properties:
- cpts_active_slave : Specifies the slave to use for time stamping
- cpts_clock_mult : Numerator to convert input clock ticks into nanoseconds
- cpts_clock_shift : Denominator to convert input clock ticks into nanoseconds
-- slave_reg_ofs : Specifies slave register offset
-- sliver_reg_ofs : Specifies slave sliver register offset
- phy_id : Specifies slave phy id
- mac-address : Specifies slave MAC address
@@ -49,15 +39,7 @@ Examples:
interrupts = <55 0x4>;
interrupt-parent = <&intc>;
cpdma_channels = <8>;
- host_port_no = <0>;
- cpdma_reg_ofs = <0x800>;
- cpdma_sram_ofs = <0xa00>;
- ale_reg_ofs = <0xd00>;
ale_entries = <1024>;
- host_port_reg_ofs = <0x108>;
- hw_stats_reg_ofs = <0x900>;
- cpts_reg_ofs = <0xc00>;
- bd_ram_ofs = <0x2000>;
bd_ram_size = <0x2000>;
no_bd_ram = <0>;
rx_descs = <64>;
@@ -67,15 +49,11 @@ Examples:
cpts_clock_mult = <0x80000000>;
cpts_clock_shift = <29>;
cpsw_emac0: slave at 0 {
- slave_reg_ofs = <0x200>;
- sliver_reg_ofs = <0xd80>;
phy_id = "davinci_mdio.16:00";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave at 1 {
- slave_reg_ofs = <0x300>;
- sliver_reg_ofs = <0xdc0>;
phy_id = "davinci_mdio.16:01";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
@@ -87,15 +65,7 @@ Examples:
compatible = "ti,cpsw";
ti,hwmods = "cpgmac0";
cpdma_channels = <8>;
- host_port_no = <0>;
- cpdma_reg_ofs = <0x800>;
- cpdma_sram_ofs = <0xa00>;
- ale_reg_ofs = <0xd00>;
ale_entries = <1024>;
- host_port_reg_ofs = <0x108>;
- hw_stats_reg_ofs = <0x900>;
- cpts_reg_ofs = <0xc00>;
- bd_ram_ofs = <0x2000>;
bd_ram_size = <0x2000>;
no_bd_ram = <0>;
rx_descs = <64>;
@@ -105,15 +75,11 @@ Examples:
cpts_clock_mult = <0x80000000>;
cpts_clock_shift = <29>;
cpsw_emac0: slave at 0 {
- slave_reg_ofs = <0x200>;
- sliver_reg_ofs = <0xd80>;
phy_id = "davinci_mdio.16:00";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave at 1 {
- slave_reg_ofs = <0x300>;
- sliver_reg_ofs = <0xdc0>;
phy_id = "davinci_mdio.16:01";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 7007aba..f94aa8f 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -80,6 +80,29 @@ do { \
#define CPSW_VERSION_1 0x19010a
#define CPSW_VERSION_2 0x19010c
+
+#define HOST_PORT_NUM 0
+#define SLIVER_SIZE 0x40
+
+#define CPSW1_HOST_PORT_OFFSET 0x028
+#define CPSW1_SLAVE_OFFSET 0x050
+#define CPSW1_SLAVE_SIZE 0x040
+#define CPSW1_CPDMA_OFFSET 0x100
+#define CPSW1_STATERAM_OFFSET 0x200
+#define CPSW1_CPTS_OFFSET 0x500
+#define CPSW1_ALE_OFFSET 0x600
+#define CPSW1_SLIVER_OFFSET 0x700
+
+#define CPSW2_HOST_PORT_OFFSET 0x108
+#define CPSW2_SLAVE_OFFSET 0x200
+#define CPSW2_SLAVE_SIZE 0x100
+#define CPSW2_CPDMA_OFFSET 0x800
+#define CPSW2_STATERAM_OFFSET 0xa00
+#define CPSW2_CPTS_OFFSET 0xc00
+#define CPSW2_ALE_OFFSET 0xd00
+#define CPSW2_SLIVER_OFFSET 0xd80
+#define CPSW2_BD_OFFSET 0x2000
+
#define CPDMA_RXTHRESH 0x0c0
#define CPDMA_RXFREE 0x0e0
#define CPDMA_TXHDP 0x00
@@ -87,21 +110,6 @@ do { \
#define CPDMA_TXCP 0x40
#define CPDMA_RXCP 0x60
-#define cpsw_dma_regs(base, offset) \
- (void __iomem *)((base) + (offset))
-#define cpsw_dma_rxthresh(base, offset) \
- (void __iomem *)((base) + (offset) + CPDMA_RXTHRESH)
-#define cpsw_dma_rxfree(base, offset) \
- (void __iomem *)((base) + (offset) + CPDMA_RXFREE)
-#define cpsw_dma_txhdp(base, offset) \
- (void __iomem *)((base) + (offset) + CPDMA_TXHDP)
-#define cpsw_dma_rxhdp(base, offset) \
- (void __iomem *)((base) + (offset) + CPDMA_RXHDP)
-#define cpsw_dma_txcp(base, offset) \
- (void __iomem *)((base) + (offset) + CPDMA_TXCP)
-#define cpsw_dma_rxcp(base, offset) \
- (void __iomem *)((base) + (offset) + CPDMA_RXCP)
-
#define CPSW_POLL_WEIGHT 64
#define CPSW_MIN_PACKET_SIZE 60
#define CPSW_MAX_PACKET_SIZE (1500 + 14 + 4 + 4)
@@ -629,8 +637,7 @@ static int cpsw_ndo_open(struct net_device *ndev)
pm_runtime_get_sync(&priv->pdev->dev);
- reg = __raw_readl(&priv->regs->id_ver);
- priv->version = reg;
+ reg = priv->version;
dev_info(priv->dev, "initializing cpsw version %d.%d (%d)\n",
CPSW_MAJOR_VERSION(reg), CPSW_MINOR_VERSION(reg),
@@ -995,15 +1002,16 @@ static const struct ethtool_ops cpsw_ethtool_ops = {
.get_ts_info = cpsw_get_ts_info,
};
-static void cpsw_slave_init(struct cpsw_slave *slave, struct cpsw_priv *priv)
+static void cpsw_slave_init(struct cpsw_slave *slave, struct cpsw_priv *priv,
+ u32 slave_reg_ofs, u32 sliver_reg_ofs)
{
void __iomem *regs = priv->regs;
int slave_num = slave->slave_num;
struct cpsw_slave_data *data = priv->data.slave_data + slave_num;
slave->data = data;
- slave->regs = regs + data->slave_reg_ofs;
- slave->sliver = regs + data->sliver_reg_ofs;
+ slave->regs = regs + slave_reg_ofs;
+ slave->sliver = regs + sliver_reg_ofs;
}
static int cpsw_probe_dt(struct cpsw_platform_data *data,
@@ -1051,8 +1059,6 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
return -EINVAL;
}
- data->no_bd_ram = of_property_read_bool(node, "no_bd_ram");
-
if (of_property_read_u32(node, "cpdma_channels", &prop)) {
pr_err("Missing cpdma_channels property in the DT.\n");
ret = -EINVAL;
@@ -1060,34 +1066,6 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
data->channels = prop;
- if (of_property_read_u32(node, "host_port_no", &prop)) {
- pr_err("Missing host_port_no property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
- }
- data->host_port_num = prop;
-
- if (of_property_read_u32(node, "cpdma_reg_ofs", &prop)) {
- pr_err("Missing cpdma_reg_ofs property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
- }
- data->cpdma_reg_ofs = prop;
-
- if (of_property_read_u32(node, "cpdma_sram_ofs", &prop)) {
- pr_err("Missing cpdma_sram_ofs property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
- }
- data->cpdma_sram_ofs = prop;
-
- if (of_property_read_u32(node, "ale_reg_ofs", &prop)) {
- pr_err("Missing ale_reg_ofs property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
- }
- data->ale_reg_ofs = prop;
-
if (of_property_read_u32(node, "ale_entries", &prop)) {
pr_err("Missing ale_entries property in the DT.\n");
ret = -EINVAL;
@@ -1095,34 +1073,6 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
data->ale_entries = prop;
- if (of_property_read_u32(node, "host_port_reg_ofs", &prop)) {
- pr_err("Missing host_port_reg_ofs property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
- }
- data->host_port_reg_ofs = prop;
-
- if (of_property_read_u32(node, "hw_stats_reg_ofs", &prop)) {
- pr_err("Missing hw_stats_reg_ofs property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
- }
- data->hw_stats_reg_ofs = prop;
-
- if (of_property_read_u32(node, "cpts_reg_ofs", &prop)) {
- pr_err("Missing cpts_reg_ofs property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
- }
- data->cpts_reg_ofs = prop;
-
- if (of_property_read_u32(node, "bd_ram_ofs", &prop)) {
- pr_err("Missing bd_ram_ofs property in the DT.\n");
- ret = -EINVAL;
- goto error_ret;
- }
- data->bd_ram_ofs = prop;
-
if (of_property_read_u32(node, "bd_ram_size", &prop)) {
pr_err("Missing bd_ram_size property in the DT.\n");
ret = -EINVAL;
@@ -1156,22 +1106,6 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
slave_data->phy_id = phy_id;
- if (of_property_read_u32(slave_node, "slave_reg_ofs", &prop)) {
- pr_err("Missing slave[%d] slave_reg_ofs property\n", i);
- ret = -EINVAL;
- goto error_ret;
- }
- slave_data->slave_reg_ofs = prop;
-
- if (of_property_read_u32(slave_node, "sliver_reg_ofs",
- &prop)) {
- pr_err("Missing slave[%d] sliver_reg_ofs property\n",
- i);
- ret = -EINVAL;
- goto error_ret;
- }
- slave_data->sliver_reg_ofs = prop;
-
mac_addr = of_get_mac_address(slave_node);
if (mac_addr)
memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
@@ -1201,8 +1135,9 @@ static int __devinit cpsw_probe(struct platform_device *pdev)
struct cpsw_priv *priv;
struct cpdma_params dma_params;
struct cpsw_ale_params ale_params;
- void __iomem *regs;
+ void __iomem *ss_regs, *wr_regs;
struct resource *res;
+ u32 slave_offset, sliver_offset, slave_size;
int ret = 0, i, k = 0;
ndev = alloc_etherdev(sizeof(struct cpsw_priv));
@@ -1270,15 +1205,14 @@ static int __devinit cpsw_probe(struct platform_device *pdev)
ret = -ENXIO;
goto clean_clk_ret;
}
- regs = ioremap(priv->cpsw_res->start, resource_size(priv->cpsw_res));
- if (!regs) {
+ ss_regs = ioremap(priv->cpsw_res->start, resource_size(priv->cpsw_res));
+ if (!ss_regs) {
dev_err(priv->dev, "unable to map i/o region\n");
goto clean_cpsw_iores_ret;
}
- priv->regs = regs;
- priv->host_port = data->host_port_num;
- priv->host_port_regs = regs + data->host_port_reg_ofs;
- priv->cpts.reg = regs + data->cpts_reg_ofs;
+ priv->regs = ss_regs;
+ priv->version = __raw_readl(&priv->regs->id_ver);
+ priv->host_port = HOST_PORT_NUM;
priv->cpsw_wr_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
if (!priv->cpsw_wr_res) {
@@ -1292,32 +1226,59 @@ static int __devinit cpsw_probe(struct platform_device *pdev)
ret = -ENXIO;
goto clean_iomap_ret;
}
- regs = ioremap(priv->cpsw_wr_res->start,
+ wr_regs = ioremap(priv->cpsw_wr_res->start,
resource_size(priv->cpsw_wr_res));
- if (!regs) {
+ if (!wr_regs) {
dev_err(priv->dev, "unable to map i/o region\n");
goto clean_cpsw_wr_iores_ret;
}
- priv->wr_regs = regs;
-
- for_each_slave(priv, cpsw_slave_init, priv);
+ priv->wr_regs = wr_regs;
memset(&dma_params, 0, sizeof(dma_params));
+ memset(&ale_params, 0, sizeof(ale_params));
+
+ switch (priv->version) {
+ case CPSW_VERSION_1:
+ priv->host_port_regs = ss_regs + CPSW1_HOST_PORT_OFFSET;
+ priv->cpts.reg = ss_regs + CPSW1_CPTS_OFFSET;
+ dma_params.dmaregs = ss_regs + CPSW1_CPDMA_OFFSET;
+ dma_params.txhdp = ss_regs + CPSW1_STATERAM_OFFSET;
+ ale_params.ale_regs = ss_regs + CPSW1_ALE_OFFSET;
+ slave_offset = CPSW1_SLAVE_OFFSET;
+ slave_size = CPSW1_SLAVE_SIZE;
+ sliver_offset = CPSW1_SLIVER_OFFSET;
+ dma_params.desc_mem_phys = 0;
+ break;
+ case CPSW_VERSION_2:
+ priv->host_port_regs = ss_regs + CPSW2_HOST_PORT_OFFSET;
+ priv->cpts.reg = ss_regs + CPSW2_CPTS_OFFSET;
+ dma_params.dmaregs = ss_regs + CPSW2_CPDMA_OFFSET;
+ dma_params.txhdp = ss_regs + CPSW2_STATERAM_OFFSET;
+ ale_params.ale_regs = ss_regs + CPSW2_ALE_OFFSET;
+ slave_offset = CPSW2_SLAVE_OFFSET;
+ slave_size = CPSW2_SLAVE_SIZE;
+ sliver_offset = CPSW2_SLIVER_OFFSET;
+ dma_params.desc_mem_phys =
+ (u32 __force) priv->cpsw_res->start + CPSW2_BD_OFFSET;
+ break;
+ default:
+ dev_err(priv->dev, "unknown version 0x%08x\n", priv->version);
+ ret = -ENODEV;
+ goto clean_cpsw_wr_iores_ret;
+ }
+ for (i = 0; i < priv->data.slaves; i++) {
+ struct cpsw_slave *slave = &priv->slaves[i];
+ cpsw_slave_init(slave, priv, slave_offset, sliver_offset);
+ slave_offset += slave_size;
+ sliver_offset += SLIVER_SIZE;
+ }
+
dma_params.dev = &pdev->dev;
- dma_params.dmaregs = cpsw_dma_regs((u32)priv->regs,
- data->cpdma_reg_ofs);
- dma_params.rxthresh = cpsw_dma_rxthresh((u32)priv->regs,
- data->cpdma_reg_ofs);
- dma_params.rxfree = cpsw_dma_rxfree((u32)priv->regs,
- data->cpdma_reg_ofs);
- dma_params.txhdp = cpsw_dma_txhdp((u32)priv->regs,
- data->cpdma_sram_ofs);
- dma_params.rxhdp = cpsw_dma_rxhdp((u32)priv->regs,
- data->cpdma_sram_ofs);
- dma_params.txcp = cpsw_dma_txcp((u32)priv->regs,
- data->cpdma_sram_ofs);
- dma_params.rxcp = cpsw_dma_rxcp((u32)priv->regs,
- data->cpdma_sram_ofs);
+ dma_params.rxthresh = dma_params.dmaregs + CPDMA_RXTHRESH;
+ dma_params.rxfree = dma_params.dmaregs + CPDMA_RXFREE;
+ dma_params.rxhdp = dma_params.txhdp + CPDMA_RXHDP;
+ dma_params.txcp = dma_params.txhdp + CPDMA_TXCP;
+ dma_params.rxcp = dma_params.txhdp + CPDMA_RXCP;
dma_params.num_chan = data->channels;
dma_params.has_soft_reset = true;
@@ -1325,10 +1286,7 @@ static int __devinit cpsw_probe(struct platform_device *pdev)
dma_params.desc_mem_size = data->bd_ram_size;
dma_params.desc_align = 16;
dma_params.has_ext_regs = true;
- dma_params.desc_mem_phys = data->no_bd_ram ? 0 :
- (u32 __force)priv->cpsw_res->start + data->bd_ram_ofs;
- dma_params.desc_hw_addr = data->hw_ram_addr ?
- data->hw_ram_addr : dma_params.desc_mem_phys ;
+ dma_params.desc_hw_addr = dma_params.desc_mem_phys;
priv->dma = cpdma_ctlr_create(&dma_params);
if (!priv->dma) {
@@ -1348,10 +1306,7 @@ static int __devinit cpsw_probe(struct platform_device *pdev)
goto clean_dma_ret;
}
- memset(&ale_params, 0, sizeof(ale_params));
ale_params.dev = &ndev->dev;
- ale_params.ale_regs = (void *)((u32)priv->regs) +
- ((u32)data->ale_reg_ofs);
ale_params.ale_ageout = ale_ageout;
ale_params.ale_entries = data->ale_entries;
ale_params.ale_ports = data->slaves;
diff --git a/include/linux/platform_data/cpsw.h b/include/linux/platform_data/cpsw.h
index b5c16c3..4b0ed74 100644
--- a/include/linux/platform_data/cpsw.h
+++ b/include/linux/platform_data/cpsw.h
@@ -18,8 +18,6 @@
#include <linux/if_ether.h>
struct cpsw_slave_data {
- u32 slave_reg_ofs;
- u32 sliver_reg_ofs;
const char *phy_id;
int phy_if;
u8 mac_addr[ETH_ALEN];
@@ -28,31 +26,14 @@ struct cpsw_slave_data {
struct cpsw_platform_data {
u32 ss_reg_ofs; /* Subsystem control register offset */
u32 channels; /* number of cpdma channels (symmetric) */
- u32 cpdma_reg_ofs; /* cpdma register offset */
- u32 cpdma_sram_ofs; /* cpdma sram offset */
-
u32 slaves; /* number of slave cpgmac ports */
struct cpsw_slave_data *slave_data;
u32 cpts_active_slave; /* time stamping slave */
u32 cpts_clock_mult; /* convert input clock ticks to nanoseconds */
u32 cpts_clock_shift; /* convert input clock ticks to nanoseconds */
-
- u32 ale_reg_ofs; /* address lookup engine reg offset */
u32 ale_entries; /* ale table size */
-
- u32 host_port_reg_ofs; /* cpsw cpdma host port registers */
- u32 host_port_num; /* The port number for the host port */
-
- u32 hw_stats_reg_ofs; /* cpsw hardware statistics counters */
- u32 cpts_reg_ofs; /* cpts registers */
-
- u32 bd_ram_ofs; /* embedded buffer descriptor RAM offset*/
u32 bd_ram_size; /*buffer descriptor ram size */
- u32 hw_ram_addr; /*if the HW address for BD RAM is different */
- bool no_bd_ram; /* no embedded BD ram*/
-
u32 rx_descs; /* Number of Rx Descriptios */
-
u32 mac_control; /* Mac control register */
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH 5/7] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: Mugunthan V N @ 2012-11-06 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352189545-26303-1-git-send-email-mugunthanvnm@ti.com>
Add CPSW and MDIO related device tree data for AM33XX.
Also enable them into board/evm dts files by providing
respective phy-id.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Benoit Cousson <b-cousson@ti.com>
---
arch/arm/boot/dts/am335x-bone.dts | 8 +++++++
arch/arm/boot/dts/am335x-evm.dts | 8 +++++++
arch/arm/boot/dts/am33xx.dtsi | 42 +++++++++++++++++++++++++++++++++++++
3 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..e233cfa 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -78,3 +78,11 @@
};
};
};
+
+&cpsw_emac0 {
+ phy_id = "4a101000.mdio:00";
+};
+
+&cpsw_emac1 {
+ phy_id = "4a101000.mdio:01";
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 185d632..415c3b3 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -118,3 +118,11 @@
};
};
};
+
+&cpsw_emac0 {
+ phy_id = "4a101000.mdio:00";
+};
+
+&cpsw_emac1 {
+ phy_id = "4a101000.mdio:01";
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..2a0c8fe 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,47 @@
interrupt-parent = <&intc>;
interrupts = <91>;
};
+
+ mac: ethernet at 4A100000 {
+ compatible = "ti,cpsw";
+ ti,hwmods = "cpgmac0";
+ cpdma_channels = <8>;
+ ale_entries = <1024>;
+ bd_ram_size = <0x2000>;
+ no_bd_ram = <0>;
+ rx_descs = <64>;
+ mac_control = <0x20>;
+ slaves = <2>;
+ cpts_active_slave = <0>;
+ cpts_clock_mult = <0x80000000>;
+ cpts_clock_shift = <29>;
+ reg = <0x4a100000 0x800
+ 0x4a101200 0x100
+ 0x4a101000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&intc>;
+ /* c0_rx_thresh_pend c0_rx_pend c0_tx_pend c0_misc_pend*/
+ interrupts = <40 41 42 43>;
+ ranges;
+ cpsw_emac0: slave at 0 {
+ phy_id = "davinci_mdio.16:00";
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+ cpsw_emac1: slave at 1 {
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ davinci_mdio: mdio at 4a101000 {
+ compatible = "ti,davinci_mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "davinci_mdio";
+ bus_freq = <1000000>;
+ reg = <0x4a101000 0x100>;
+ };
+ };
};
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH 6/7] ARM: OMAP2+: omap2plus_defconfig: Enable CPSW support
From: Mugunthan V N @ 2012-11-06 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352189545-26303-1-git-send-email-mugunthanvnm@ti.com>
Enable CPSW support in defconfig which is present in AM33xx SoC
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index a4b330e..41b595e 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -242,3 +242,6 @@ CONFIG_CRC_ITU_T=y
CONFIG_CRC7=y
CONFIG_LIBCRC32C=y
CONFIG_SOC_OMAP5=y
+CONFIG_TI_DAVINCI_MDIO=y
+CONFIG_TI_DAVINCI_CPDMA=y
+CONFIG_TI_CPSW=y
--
1.7.0.4
^ permalink raw reply related
* [PATCH 7/7] net: cpsw: halt network stack before halting the device during suspend
From: Mugunthan V N @ 2012-11-06 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352189545-26303-1-git-send-email-mugunthanvnm@ti.com>
Move network stack halt APIs before halting the hardware to ensure no
packets are queued to hardware during closing the device during
suspend sequence.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index f94aa8f..b46dbb4 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -698,12 +698,12 @@ static int cpsw_ndo_stop(struct net_device *ndev)
struct cpsw_priv *priv = netdev_priv(ndev);
cpsw_info(priv, ifdown, "shutting down cpsw device\n");
- cpsw_intr_disable(priv);
- cpdma_ctlr_int_ctrl(priv->dma, false);
- cpdma_ctlr_stop(priv->dma);
netif_stop_queue(priv->ndev);
napi_disable(&priv->napi);
netif_carrier_off(priv->ndev);
+ cpsw_intr_disable(priv);
+ cpdma_ctlr_int_ctrl(priv->dma, false);
+ cpdma_ctlr_stop(priv->dma);
cpsw_ale_stop(priv->ale);
for_each_slave(priv, cpsw_slave_stop, priv);
pm_runtime_put_sync(&priv->pdev->dev);
--
1.7.0.4
^ permalink raw reply related
* [PATCH RFC] ARM: EXYNOS5: Setup legacy i2c controller interrupts on SMDK5250
From: Thomas Abraham @ 2012-11-06 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352182726-29221-1-git-send-email-a.kesavan@samsung.com>
On 6 November 2012 11:48, Abhilash Kesavan <a.kesavan@samsung.com> wrote:
> On Exynos5 we have a new high-speed i2c controller. The interrupt
> sources for the legacy and new controller are muxed and are controlled
> via the SYSCON I2C_CFG register.
> At reset the interrupt source is configured for the high-speed controller,
> to continue using the old i2c controller we need to modify the I2C_CFG
> register.
If the high-speed i2c controllers are not used, can this configuration
be moved into the bootloader?
The other option could be, in the exynos5250_dt_machine_init()
function, first check if the platform is compatible with
"samsung,exynos5250" and if so search for a high-speed i2c controller
compatible node. If a high-speed controller node is found and if that
node is not disabled, then do not change the reset value of I2C_CFG
register.
Thanks,
Thomas.
>
> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
> ---
> This is a hack, I am not quite clear on how to handle this via DT. Suggestions
> welcome.
>
> arch/arm/mach-exynos/mach-exynos5-dt.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index ed37273..badffd4 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -13,10 +13,12 @@
> #include <linux/serial_core.h>
> #include <linux/memblock.h>
> #include <linux/of_fdt.h>
> +#include <linux/io.h>
>
> #include <asm/mach/arch.h>
> #include <asm/hardware/gic.h>
> #include <mach/map.h>
> +#include <mach/regs-pmu.h>
>
> #include <plat/cpu.h>
> #include <plat/regs-serial.h>
> @@ -89,6 +91,12 @@ static const struct of_dev_auxdata exynos5250_auxdata_lookup[] __initconst = {
> {},
> };
>
> +static void exynos5_i2c_setup(void)
> +{
> + /* Setup the low-speed i2c controller interrupts */
> + writel(0x0, EXYNOS5_SYS_I2C_CFG);
> +}
> +
> static void __init exynos5250_dt_map_io(void)
> {
> exynos_init_io(NULL, 0);
> @@ -97,6 +105,8 @@ static void __init exynos5250_dt_map_io(void)
>
> static void __init exynos5250_dt_machine_init(void)
> {
> + exynos5_i2c_setup();
> +
> of_platform_populate(NULL, of_default_bus_match_table,
> exynos5250_auxdata_lookup, NULL);
> }
> --
> 1.6.6.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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