* [BUG] panda board locks up on boot
From: Steven Rostedt @ 2013-01-25 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125085234.GY23505@n2100.arm.linux.org.uk>
On Fri, 2013-01-25 at 08:52 +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 24, 2013 at 10:01:26PM -0500, Steven Rostedt wrote:
> > I've recently started testing my work on arm boards and have found that
> > they both don't boot under the latest kernel anymore. I already posted
> > about my snowball board, but my panda board also locks up.
>
> You need to enable DMA engine and the OMAP DMA engine driver. I believe
> someone was going to work on adding PIO-mode support to the driver but
> I suspect as TI's OMAP division is being reorganized, all that is now
> uncertain.
Well, I be darn...
Yep, selecting DMA_OMAP which selects DMA_ENGINE makes everything
better. Who'da thunk?
Now only if there was a config option missing for my snowball?
Thanks!
-- Steve
^ permalink raw reply
* [PATCH v2 2/3] pwm: Add can_sleep property to drivers
From: Peter Ujfalusi @ 2013-01-25 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359121471-21457-3-git-send-email-florian.vaussard@epfl.ch>
On 01/25/2013 02:44 PM, Florian Vaussard wrote:
> Calls to PWM drivers connected through I2C can sleep.
> Use the new can_sleep property.
>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
> drivers/pwm/pwm-twl-led.c | 1 +
> drivers/pwm/pwm-twl.c | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c
> index 9dfa0f3..6261193 100644
> --- a/drivers/pwm/pwm-twl-led.c
> +++ b/drivers/pwm/pwm-twl-led.c
> @@ -300,6 +300,7 @@ static int twl_pwmled_probe(struct platform_device *pdev)
>
> twl->chip.dev = &pdev->dev;
> twl->chip.base = -1;
> + twl->chip.can_sleep = 1;
>
> mutex_init(&twl->mutex);
>
> diff --git a/drivers/pwm/pwm-twl.c b/drivers/pwm/pwm-twl.c
> index e65db95..4e56cd8 100644
> --- a/drivers/pwm/pwm-twl.c
> +++ b/drivers/pwm/pwm-twl.c
> @@ -315,6 +315,7 @@ static int twl_pwm_probe(struct platform_device *pdev)
> twl->chip.dev = &pdev->dev;
> twl->chip.base = -1;
> twl->chip.npwm = 2;
> + twl->chip.can_sleep = 1;
>
> mutex_init(&twl->mutex);
>
>
--
P?ter
^ permalink raw reply
* [PATCH v2 1/3] pwm: Add pwm_cansleep() as exported API to users
From: Peter Ujfalusi @ 2013-01-25 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359121471-21457-2-git-send-email-florian.vaussard@epfl.ch>
On 01/25/2013 02:44 PM, Florian Vaussard wrote:
> Calls to some external PWM chips can sleep. To help users,
> add pwm_cansleep() API.
>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
> drivers/pwm/core.c | 12 ++++++++++++
> include/linux/pwm.h | 10 ++++++++++
> 2 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 4a13da4..e737f5f 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -763,6 +763,18 @@ void devm_pwm_put(struct device *dev, struct pwm_device *pwm)
> }
> EXPORT_SYMBOL_GPL(devm_pwm_put);
>
> +/**
> + * pwm_cansleep() - report whether pwm access will sleep
> + * @pwm: PWM device
> + *
> + * It returns nonzero if accessing the PWM can sleep.
> + */
> +int pwm_cansleep(struct pwm_device *pwm)
> +{
> + return pwm->chip->can_sleep;
> +}
> +EXPORT_SYMBOL_GPL(pwm_cansleep);
> +
> #ifdef CONFIG_DEBUG_FS
> static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
> {
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index 70655a2..e2cb5c7 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -146,6 +146,8 @@ struct pwm_ops {
> * @base: number of first PWM controlled by this chip
> * @npwm: number of PWMs controlled by this chip
> * @pwms: array of PWM devices allocated by the framework
> + * @can_sleep: flag must be set iff config()/enable()/disable() methods sleep,
> + * as they must while accessing PWM chips over I2C or SPI
> */
> struct pwm_chip {
> struct device *dev;
> @@ -159,6 +161,7 @@ struct pwm_chip {
> struct pwm_device * (*of_xlate)(struct pwm_chip *pc,
> const struct of_phandle_args *args);
> unsigned int of_pwm_n_cells;
> + unsigned int can_sleep:1;
> };
>
> #if IS_ENABLED(CONFIG_PWM)
> @@ -182,6 +185,8 @@ struct pwm_device *devm_pwm_get(struct device *dev, const char *con_id);
> struct pwm_device *devm_of_pwm_get(struct device *dev, struct device_node *np,
> const char *con_id);
> void devm_pwm_put(struct device *dev, struct pwm_device *pwm);
> +
> +int pwm_cansleep(struct pwm_device *pwm);
> #else
> static inline int pwm_set_chip_data(struct pwm_device *pwm, void *data)
> {
> @@ -242,6 +247,11 @@ static inline struct pwm_device *devm_of_pwm_get(struct device *dev,
> static inline void devm_pwm_put(struct device *dev, struct pwm_device *pwm)
> {
> }
> +
> +static inline int pwm_cansleep(struct pwm_device *pwm)
> +{
> + return 0;
> +}
> #endif
>
> struct pwm_lookup {
>
--
P?ter
^ permalink raw reply
* [PATCH v2 3/3] leds: leds-pwm: Defer led_pwm_set() if PWM can sleep
From: Peter Ujfalusi @ 2013-01-25 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359121471-21457-4-git-send-email-florian.vaussard@epfl.ch>
On 01/25/2013 02:44 PM, Florian Vaussard wrote:
> Call to led_pwm_set() can happen inside atomic context, like triggers.
> If the PWM call can sleep, defer using a worker.
>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
> drivers/leds/leds-pwm.c | 50 +++++++++++++++++++++++++++++++++++++++-------
> 1 files changed, 42 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> index a1ea5f6..70effa7 100644
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -23,12 +23,16 @@
> #include <linux/pwm.h>
> #include <linux/leds_pwm.h>
> #include <linux/slab.h>
> +#include <linux/workqueue.h>
>
> struct led_pwm_data {
> struct led_classdev cdev;
> struct pwm_device *pwm;
> + struct work_struct work;
> unsigned int active_low;
> unsigned int period;
> + int duty;
> + unsigned can_sleep:1;
> };
>
> struct led_pwm_priv {
> @@ -36,6 +40,26 @@ struct led_pwm_priv {
> struct led_pwm_data leds[0];
> };
>
> +static void __led_pwm_set(struct led_pwm_data *led_dat)
> +{
> + int new_duty = led_dat->duty;
> +
> + pwm_config(led_dat->pwm, new_duty, led_dat->period);
> +
> + if (new_duty == 0)
> + pwm_disable(led_dat->pwm);
> + else
> + pwm_enable(led_dat->pwm);
> +}
> +
> +static void led_pwm_work(struct work_struct *work)
> +{
> + struct led_pwm_data *led_dat =
> + container_of(work, struct led_pwm_data, work);
> +
> + __led_pwm_set(led_dat);
> +}
> +
> static void led_pwm_set(struct led_classdev *led_cdev,
> enum led_brightness brightness)
> {
> @@ -44,13 +68,12 @@ static void led_pwm_set(struct led_classdev *led_cdev,
> unsigned int max = led_dat->cdev.max_brightness;
> unsigned int period = led_dat->period;
>
> - if (brightness == 0) {
> - pwm_config(led_dat->pwm, 0, period);
> - pwm_disable(led_dat->pwm);
> - } else {
> - pwm_config(led_dat->pwm, brightness * period / max, period);
> - pwm_enable(led_dat->pwm);
> - }
> + led_dat->duty = brightness * period / max;
> +
> + if (led_dat->can_sleep)
> + schedule_work(&led_dat->work);
> + else
> + __led_pwm_set(led_dat);
> }
>
> static inline size_t sizeof_pwm_leds_priv(int num_leds)
> @@ -100,6 +123,10 @@ static struct led_pwm_priv *led_pwm_create_of(struct platform_device *pdev)
> led_dat->cdev.brightness = LED_OFF;
> led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
>
> + led_dat->can_sleep = pwm_cansleep(led_dat->pwm);
> + if (led_dat->can_sleep)
> + INIT_WORK(&led_dat->work, led_pwm_work);
> +
> ret = led_classdev_register(&pdev->dev, &led_dat->cdev);
> if (ret < 0) {
> dev_err(&pdev->dev, "failed to register for %s\n",
> @@ -153,6 +180,10 @@ static int led_pwm_probe(struct platform_device *pdev)
> led_dat->cdev.max_brightness = cur_led->max_brightness;
> led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
>
> + led_dat->can_sleep = pwm_cansleep(led_dat->pwm);
> + if (led_dat->can_sleep)
> + INIT_WORK(&led_dat->work, led_pwm_work);
> +
> ret = led_classdev_register(&pdev->dev, &led_dat->cdev);
> if (ret < 0)
> goto err;
> @@ -180,8 +211,11 @@ static int led_pwm_remove(struct platform_device *pdev)
> struct led_pwm_priv *priv = platform_get_drvdata(pdev);
> int i;
>
> - for (i = 0; i < priv->num_leds; i++)
> + for (i = 0; i < priv->num_leds; i++) {
> led_classdev_unregister(&priv->leds[i].cdev);
> + if (priv->leds[i].can_sleep)
> + cancel_work_sync(&priv->leds[i].work);
> + }
>
> return 0;
> }
>
--
P?ter
^ permalink raw reply
* [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
From: Rob Clark @ 2013-01-25 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA939BB@DBDE01.ent.ti.com>
On Fri, Jan 25, 2013 at 7:19 AM, Mohammed, Afzal <afzal@ti.com> wrote:
> Hi Rob,
>
> On Wed, Jan 23, 2013 at 04:06:22, Rob Clark wrote:
>
>> A simple DRM/KMS driver for the TI LCD Controller found in various
>> smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
>
>> +void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
>
>> + /* in raster mode, minimum divisor is 2: */
>> + ret = clk_set_rate(priv->disp_clk, crtc->mode.clock * 1000 * 2);
>
> These things can better be handled with divider clock having a
> minimum value (being discussed with Mike on how exactly it should
> be) and instead of setting rate over a platform specific clock,
> you can set rate over lcd clock using SET_RATE_PARENT at platform
> level, more below,
I looked at that patch you were proposing for da8xx-fb.. to be
honest, it did not seem simpler to me, so I was sort of failing to see
the benefit..
>> + /* Configure the LCD clock divisor. */
>> + tilcdc_write(dev, LCDC_CTRL_REG, LCDC_CLK_DIVISOR(div) |
>> + LCDC_RASTER_MODE);
>> +
>> + if (priv->rev == 2)
>> + tilcdc_set(dev, LCDC_CLK_ENABLE_REG,
>> + LCDC_V2_DMA_CLK_EN | LCDC_V2_LIDD_CLK_EN |
>> + LCDC_V2_CORE_CLK_EN);
>
> Mike was suggesting to model the above using gate/divider/composite
> clocks of CCF in the FB driver.
>
>> + priv->clk = clk_get(dev->dev, "fck");
>> + if (IS_ERR(priv->clk)) {
>> + dev_err(dev->dev, "failed to get functional clock\n");
>> + ret = -ENODEV;
>> + goto fail;
>> + }
>> +
>> + priv->disp_clk = clk_get(dev->dev, "dpll_disp_ck");
>> + if (IS_ERR(priv->clk)) {
>> + dev_err(dev->dev, "failed to get display clock\n");
>> + ret = -ENODEV;
>> + goto fail;
>> + }
>
> "dpll_disp_ck" is a platform specific matter, driver should not
> be handling platform specifics. And this won't work on DaVinci,
> you can probably make use of
meaning the clock has a different name on davinci, or? Presumably
there must be some clock generating the pixel clock for the display,
but I confess to not being too familiar with the details on davinci..
BR,
-R
> my series "[PATCH v2 0/4] ARM: AM335x: LCDC platform support"
>
> or something similar to overcome this.
>
> Regards
> Afzal
>
>
^ permalink raw reply
* [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
From: Mohammed, Afzal @ 2013-01-25 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF6AEGsqkUr0R3eYa4P371tUPq_NLSJLhH=N_MkyJF31s068+g@mail.gmail.com>
Hi Rob,
On Fri, Jan 25, 2013 at 19:29:40, Rob Clark wrote:
> On Fri, Jan 25, 2013 at 7:19 AM, Mohammed, Afzal <afzal@ti.com> wrote:
> > On Wed, Jan 23, 2013 at 04:06:22, Rob Clark wrote:
> >> A simple DRM/KMS driver for the TI LCD Controller found in various
> >> smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
> >> +void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
> >
> >> + /* in raster mode, minimum divisor is 2: */
> >> + ret = clk_set_rate(priv->disp_clk, crtc->mode.clock * 1000 * 2);
> > These things can better be handled with divider clock having a
> > minimum value (being discussed with Mike on how exactly it should
> > be) and instead of setting rate over a platform specific clock,
> > you can set rate over lcd clock using SET_RATE_PARENT at platform
> > level, more below,
> I looked at that patch you were proposing for da8xx-fb.. to be
> honest, it did not seem simpler to me, so I was sort of failing to see
> the benefit..
It's not about being simple, but not doing the wrong way, here you are
relying on a platform specific clock in a driver, think about the case
where same IP is used on another platform. Either way it is not a good
thing to handle platform specific details (about disp_clk) in driver.
And Mike mentioned that one of design goals of CCF is to model these
kinds of clocks in IP's.
> >> + /* Configure the LCD clock divisor. */
> >> + tilcdc_write(dev, LCDC_CTRL_REG, LCDC_CLK_DIVISOR(div) |
> >> + LCDC_RASTER_MODE);
> >> +
> >> + if (priv->rev == 2)
> >> + tilcdc_set(dev, LCDC_CLK_ENABLE_REG,
> >> + LCDC_V2_DMA_CLK_EN | LCDC_V2_LIDD_CLK_EN |
> >> + LCDC_V2_CORE_CLK_EN);
> >
> > Mike was suggesting to model the above using gate/divider/composite
> > clocks of CCF in the FB driver.
> >> + priv->clk = clk_get(dev->dev, "fck");
> >> + if (IS_ERR(priv->clk)) {
> >> + dev_err(dev->dev, "failed to get functional clock\n");
> >> + ret = -ENODEV;
> >> + goto fail;
> >> + }
> >> +
> >> + priv->disp_clk = clk_get(dev->dev, "dpll_disp_ck");
> >> + if (IS_ERR(priv->clk)) {
> >> + dev_err(dev->dev, "failed to get display clock\n");
> >> + ret = -ENODEV;
> >> + goto fail;
> >> + }
> >
> > "dpll_disp_ck" is a platform specific matter, driver should not
> > be handling platform specifics. And this won't work on DaVinci,
> > you can probably make use of
>
> meaning the clock has a different name on davinci, or? Presumably
> there must be some clock generating the pixel clock for the display,
> but I confess to not being too familiar with the details on davinci..
The only option for the driver in DaVinci is to configure clock rate
using the divider of LCDC IP, it has "fck", which gives a rate
decided by its ancestors.
Regards
Afzal
^ permalink raw reply
* [PATCH] ARM: omap2: gpmc: Remove unneeded of_node_put()
From: Jon Hunter @ 2013-01-25 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359116387-32613-1-git-send-email-ezequiel.garcia@free-electrons.com>
On 01/25/2013 06:19 AM, Ezequiel Garcia wrote:
> for_each_node_by_name() automatically calls of_node_put() on each
> node passed; so don't do it explicitly unless there's an error.
>
> Reported-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
> arch/arm/mach-omap2/gpmc.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 01ce462..c6255f7 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -1271,9 +1271,10 @@ static int gpmc_probe_dt(struct platform_device *pdev)
>
> for_each_node_by_name(child, "nand") {
> ret = gpmc_probe_nand_child(pdev, child);
> - of_node_put(child);
> - if (ret < 0)
> + if (ret < 0) {
> + of_node_put(child);
> return ret;
> + }
> }
>
> return 0;
>
Acked-by: Jon Hunter <jon-hunter@ti.com>
Thanks!
Jon
^ permalink raw reply
* [PATCHv1 for soc 1/5] arm: socfpga: Add new device tree source for actual socfpga HW
From: Pavel Machek @ 2013-01-25 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359075633-13502-2-git-send-email-dinguyen@altera.com>
Hi!
> From: Dinh Nguyen <dinguyen@altera.com>
>
> Up to this point, support for socfpga has only been on a virtual
> platform. Now that actual hardware is available, we add the appropriate
> device tree source files.
Wow, actual hardware :-). Can I get one?
> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Pavel Machek <pavel@denx.de>
I tested it on 3.7-rc2-based tree, as it is newest I have around. It
seems to work ok. [Do you have newer git tree somewhere?]
Tested-by: Pavel Machek <pavel@denx.de>
Reviewed-by: Pavel Machek <pavel@denx.de>
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH 09/19] mfd/twl4030: don't warn about uninitialized return code
From: Arnd Bergmann @ 2013-01-25 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510295BF.80709@ti.com>
On Friday 25 January 2013 15:25:03 Peter Ujfalusi wrote:
> On 01/25/2013 03:14 PM, Arnd Bergmann wrote:
> > If the twl4030_write_script function gets called with
> > a zero length argument, its return value does not
> > get set. We know that all scripts have a nonzero
> > length, but returning an error in case they ever
> > do is probably appropriate.
> >
> > Without this patch, building omap2plus_defconfig results in:
> >
> > drivers/mfd/twl4030-power.c: In function 'load_twl4030_script':
> > drivers/mfd/twl4030-power.c:414:5: error: 'err' may be used uninitialized in this function
>
> I've fixed up Kevin's email since he is no longer with TI and added Tero to
> the CC list since this is *something*-power on OMAP platforms
>
> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Thanks!
I also got the mailing list address wrong on all mails, so I'll
retransmit the whole series in a bit, just waiting for other
quick comments to come in.
Arnd
^ permalink raw reply
* [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
From: Mohammed, Afzal @ 2013-01-25 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA92B0B@DBDE01.ent.ti.com>
Hi Kishon,
On Thu, Jan 24, 2013 at 17:21:45, Mohammed, Afzal wrote:
> On Wed, Jan 23, 2013 at 19:56:37, ABRAHAM, KISHON VIJAY wrote:
> > On Wednesday 23 January 2013 07:28 PM, Mohammed, Afzal wrote:
> > > USB first instance of am335x works in mainline as of now.
>
> > Can you check if this series indeed breaks am335x?
> >
> > Thanks for your help.
>
> Do you have a tree having these changes, it would be easier for me.
I tried with your "omap5-with-palmas" branch that was mentioned in
the cover letter of your latest series (but couldn't find the commit
that you mentioned in the cover letter, HEAD of that branch that I
tested was "2c29519 ARM: dts: palmas: update dt data for palmas-usb")
usb first instance of am335x works as earlier.
Regards
Afzal
^ permalink raw reply
* [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
From: Rob Clark @ 2013-01-25 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA93A7D@DBDE01.ent.ti.com>
On Fri, Jan 25, 2013 at 8:15 AM, Mohammed, Afzal <afzal@ti.com> wrote:
> Hi Rob,
>
> On Fri, Jan 25, 2013 at 19:29:40, Rob Clark wrote:
>> On Fri, Jan 25, 2013 at 7:19 AM, Mohammed, Afzal <afzal@ti.com> wrote:
>> > On Wed, Jan 23, 2013 at 04:06:22, Rob Clark wrote:
>
>> >> A simple DRM/KMS driver for the TI LCD Controller found in various
>> >> smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
>
>> >> +void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
>> >
>> >> + /* in raster mode, minimum divisor is 2: */
>> >> + ret = clk_set_rate(priv->disp_clk, crtc->mode.clock * 1000 * 2);
>
>> > These things can better be handled with divider clock having a
>> > minimum value (being discussed with Mike on how exactly it should
>> > be) and instead of setting rate over a platform specific clock,
>> > you can set rate over lcd clock using SET_RATE_PARENT at platform
>> > level, more below,
>
>> I looked at that patch you were proposing for da8xx-fb.. to be
>> honest, it did not seem simpler to me, so I was sort of failing to see
>> the benefit..
>
> It's not about being simple, but not doing the wrong way, here you are
> relying on a platform specific clock in a driver, think about the case
> where same IP is used on another platform. Either way it is not a good
> thing to handle platform specific details (about disp_clk) in driver.
Right, but I was trying to understand what was the benefit that the
added complexity is. I didn't realize on davinci that you are limited
to just setting divider values (which is going to drastically limit
the timings you can generate, although maybe not an issue if all you
support is a fixed lcd panel).
> And Mike mentioned that one of design goals of CCF is to model these
> kinds of clocks in IP's.
>
>> >> + /* Configure the LCD clock divisor. */
>> >> + tilcdc_write(dev, LCDC_CTRL_REG, LCDC_CLK_DIVISOR(div) |
>> >> + LCDC_RASTER_MODE);
>> >> +
>> >> + if (priv->rev == 2)
>> >> + tilcdc_set(dev, LCDC_CLK_ENABLE_REG,
>> >> + LCDC_V2_DMA_CLK_EN | LCDC_V2_LIDD_CLK_EN |
>> >> + LCDC_V2_CORE_CLK_EN);
>> >
>> > Mike was suggesting to model the above using gate/divider/composite
>> > clocks of CCF in the FB driver.
>
>> >> + priv->clk = clk_get(dev->dev, "fck");
>> >> + if (IS_ERR(priv->clk)) {
>> >> + dev_err(dev->dev, "failed to get functional clock\n");
>> >> + ret = -ENODEV;
>> >> + goto fail;
>> >> + }
>> >> +
>> >> + priv->disp_clk = clk_get(dev->dev, "dpll_disp_ck");
>> >> + if (IS_ERR(priv->clk)) {
>> >> + dev_err(dev->dev, "failed to get display clock\n");
>> >> + ret = -ENODEV;
>> >> + goto fail;
>> >> + }
>> >
>> > "dpll_disp_ck" is a platform specific matter, driver should not
>> > be handling platform specifics. And this won't work on DaVinci,
>> > you can probably make use of
>>
>> meaning the clock has a different name on davinci, or? Presumably
>> there must be some clock generating the pixel clock for the display,
>> but I confess to not being too familiar with the details on davinci..
>
> The only option for the driver in DaVinci is to configure clock rate
> using the divider of LCDC IP, it has "fck", which gives a rate
> decided by its ancestors.
Well, from looking at the other patch series it seems CCF doesn't
support minimum divider yet. And davinci doesn't support CCF yet. So
at the moment all this discussion is a bit moot. I'd propose leaving
the driver as it is for now, because that at least makes it useful on
am33xx. And when CCF and davinci have the needed support in place,
then send a patch to change the clock handling in tilcdc. I don't
actually have any davinci hw to test on, but I can easily test on
am33xx.
BR,
-R
> Regards
> Afzal
^ permalink raw reply
* [PATCH v4 1/4] drivers: usb: phy: add a new driver for usb part of control module
From: Felipe Balbi @ 2013-01-25 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125122943.GB16795@e106331-lin.cambridge.arm.com>
Hi,
On Fri, Jan 25, 2013 at 12:29:43PM +0000, Mark Rutland wrote:
> > > > + depending upon omap4 or omap5.
> > > > + - reg-names: The names of the register addresses corresponding to the registers
> > > > + filled in "reg".
> > > > + - ti,type: This is used to differentiate whether the control module has
> > > > + usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
> > > > + notify events to the musb core and omap5 has usb3 phy power register to
> > > > + power on usb3 phy. Should be "1" if it has mailbox and "2" if it has usb3
> > > > + phy power.
> > >
> > > Why not make this a string property, perhaps values "mailbox" or "register"?
> >
> > NAK.
>
> Can I ask what your objection to using a string property is?
>
> As far as I can see, "ti,type" is only used by this driver, so there's no
> common convention to stick to. Using a string makes the binding easier for
> humans to read, and thus harder to mess up in a dts, and it decouples the
> binding from kernel-side constants.
IIRC there is some work going on to add #define-like support for DT,
which would allow us to match against integers while still having
meaningful symbolic representations.
--
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/20130125/868c5612/attachment.sig>
^ permalink raw reply
* [RFC V2 PATCH 0/8] ARM: kirkwood: cleanup DT conversion
From: Sebastian Hesselbarth @ 2013-01-25 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125125214.GI1758@titan.lakedaemon.net>
On Fri, Jan 25, 2013 at 1:52 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> Once I have the mv643xx_eth binding working reliably, preferably with
> mvmdio, I'll take a look at removing the last board-*.c files. If the
> stars align, we'll get it all done for v3.9.
>
> The only big thing left will be pcie.
Jason,
there is also addr_map that we haven't thought about yet. Is it supposed
to be configurable through DT or do we leave it as "linux wants it that way"?
Sebastian
^ permalink raw reply
* [PATCH 2/2] ARM: multi_v7_defconfig: add ARCH_ZYNQ
From: Michal Simek @ 2013-01-25 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124201709.GB1036@beefymiracle.amer.corp.natinst.com>
> -----Original Message-----
> From: Josh Cartwright [mailto:josh.cartwright at ni.com]
> Sent: Thursday, January 24, 2013 9:17 PM
> To: arm at kernel.org; Rob Herring
> Cc: linux-arm-kernel at lists.infradead.org; Michal Simek
> Subject: Re: [PATCH 2/2] ARM: multi_v7_defconfig: add ARCH_ZYNQ
>
> On Thu, Jan 24, 2013 at 01:33:25PM -0600, Josh Cartwright wrote:
> > Cc: Michal Simek <michal.simek@ni.com>
>
> Ugh, my fingers typed '@ni.com' out of habit. Corrected patch below (and
> correct Cc added).
Acked-by: Michal Simek <michal.simek@xilinx.com>
M
^ permalink raw reply
* [PATCHv1 for soc 3/5] arm: socfpga: Add entries to enable make dtbs socfpga
From: Pavel Machek @ 2013-01-25 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359075633-13502-4-git-send-email-dinguyen@altera.com>
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -124,6 +124,8 @@ dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
> r8a7740-armadillo800eva.dtb \
> sh73a0-kzm9g.dtb \
> sh7372-mackerel.dtb
> +dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_cyclone5.dtb \
> + socfpga_vt.dtb
> dtb-$(CONFIG_ARCH_SPEAR13XX) += spear1310-evb.dtb \
> spear1340-evb.dtb
> dtb-$(CONFIG_ARCH_SPEAR3XX)+= spear300-evb.dtb \
This allows me to remove manual dtb invocation from the build
scripts. Good.
For 2,3/5:
Tested-by: Pavel Machek <pavel@denx.de>
Reviewed-by: Pavel Machek <pavel@denx.de>
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH v2 0/5] ARM build regressions in 3.8
From: Arnd Bergmann @ 2013-01-25 15:28 UTC (permalink / raw)
To: linux-arm-kernel
This is what remains from my previous 15 patch series,
the other patches have largely been obsoleted by
fixes from other people that found the same issues.
The samsung and w90x900 fixes should probably go through
the arm-soc tree, while I'd hope James Morris to pick
up the seccomp one and Dave Airlie to take the
exynos drm patch, but we can also put both into arm-soc
if that makes their lifes easier.
On the compressed/head.S patch, I'm still awaiting
feedback. It's not urgent since it is only a warning.
Arnd Bergmann (5):
samples/seccomp: be less stupid about cross compiling
ARM: compressed/head.S: work around new binutils warning
ARM: samsung: fix assembly syntax for new gas
ARM: w90x900: fix legacy assembly syntax
drm/exynos: don't include plat/gpio-cfg.h
arch/arm/boot/compressed/Makefile | 2 +-
arch/arm/boot/compressed/head.S | 12 ++++++++++++
arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 12 ++++++------
arch/arm/mach-s3c24xx/include/mach/entry-macro.S | 4 ++--
arch/arm/mach-s3c24xx/pm-h1940.S | 2 +-
arch/arm/mach-s3c24xx/sleep-s3c2410.S | 12 ++++++------
arch/arm/mach-s3c24xx/sleep-s3c2412.S | 12 ++++++------
arch/arm/mach-w90x900/include/mach/entry-macro.S | 4 ++--
arch/arm/plat-samsung/include/plat/debug-macro.S | 18 +++++++++---------
drivers/gpu/drm/exynos/exynos_hdmi.c | 1 -
samples/seccomp/Makefile | 2 ++
11 files changed, 47 insertions(+), 34 deletions(-)
--
1.7.10.4
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: David Airlie <airlied@linux.ie>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Rob Clark <rob@ti.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: dri-devel at lists.freedesktop.org
^ permalink raw reply
* [PATCH 1/5] samples/seccomp: be less stupid about cross compiling
From: Arnd Bergmann @ 2013-01-25 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359127711-19070-1-git-send-email-arnd@arndb.de>
The seccomp filters are currently built for the build
host, not for the machine that they are going to run
on, but they are also built for with the -m32 flag
if the kernel is built for a 32 bit machine, both
of which seems rather odd.
It broke allyesconfig on my machine, which is x86-64, but
building for 32 bit ARM, with this error message:
In file included from /usr/include/stdio.h:28:0,
from samples/seccomp/bpf-fancy.c:15:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
because there are no 32 bit libc headers installed on
this machine. We should really be building all the
samples for the target machine rather than the build
host, but since the infrastructure for that appears
to be missing right now, let's be a little bit smarter
and not pass the '-m32' flag to the HOSTCC when cross-
compiling.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Morris <james.l.morris@oracle.com>
---
samples/seccomp/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
index bbbd276..7203e66 100644
--- a/samples/seccomp/Makefile
+++ b/samples/seccomp/Makefile
@@ -19,6 +19,7 @@ bpf-direct-objs := bpf-direct.o
# Try to match the kernel target.
ifndef CONFIG_64BIT
+ifndef CROSS_COMPILE
# s390 has -m31 flag to build 31 bit binaries
ifndef CONFIG_S390
@@ -35,6 +36,7 @@ HOSTLOADLIBES_bpf-direct += $(MFLAG)
HOSTLOADLIBES_bpf-fancy += $(MFLAG)
HOSTLOADLIBES_dropper += $(MFLAG)
endif
+endif
# Tell kbuild to always build the programs
always := $(hostprogs-y)
--
1.8.0
^ permalink raw reply related
* [PATCH 2/5] ARM: compressed/head.S: work around new binutils warning
From: Arnd Bergmann @ 2013-01-25 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359127711-19070-1-git-send-email-arnd@arndb.de>
In August 2012, Matthew Gretton-Dann checked a change
into binutils labelled "Error on obsolete & warn on
deprecated registers", apparently as part of ARMv8
support. Apparently, this was supposed to emit
the message "Warning: This coprocessor register access
is deprecated in ARMv8" when using certain mcr/mrc
instructions and building for ARMv8. Unfortunately,
the message that is actually emitted appears to be
'(null)', which is less helpful in comparison.
Even more unfortunately, this is biting us on
every single kernel build with a new gas, because
arch/arm/boot/compressed/head.S and some other files
in that directory are built with -march=all since
kernel commit 80cec14a8 "[ARM] Add -march=all to
assembly file build in arch/arm/boot/compressed"
back in v2.6.28.
This patch reverts Russell's nice solution and
replaces it with a more complex one that sprinkles
.arch statements inside of the head.S file in
functions that are executed in different architecture
levels, which seems to solve the original problem
just as well, and gets rid of the new one, too.
Without this patch, building anything results in:
arch/arm/boot/compressed/head.S: Assembler messages:
arch/arm/boot/compressed/head.S:565: Warning: (null)
arch/arm/boot/compressed/head.S:676: Warning: (null)
arch/arm/boot/compressed/head.S:698: Warning: (null)
arch/arm/boot/compressed/head.S:722: Warning: (null)
arch/arm/boot/compressed/head.S:726: Warning: (null)
arch/arm/boot/compressed/head.S:957: Warning: (null)
arch/arm/boot/compressed/head.S:996: Warning: (null)
arch/arm/boot/compressed/head.S:997: Warning: (null)
arch/arm/boot/compressed/head.S:1027: Warning: (null)
arch/arm/boot/compressed/head.S:1035: Warning: (null)
arch/arm/boot/compressed/head.S:1046: Warning: (null)
arch/arm/boot/compressed/head.S:1060: Warning: (null)
arch/arm/boot/compressed/head.S:1092: Warning: (null)
arch/arm/boot/compressed/head.S:1094: Warning: (null)
arch/arm/boot/compressed/head.S:1095: Warning: (null)
arch/arm/boot/compressed/head.S:1102: Warning: (null)
arch/arm/boot/compressed/head.S:1134: Warning: (null)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Matthew Gretton-Dann <matthew.gretton-dann@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/boot/compressed/Makefile | 2 +-
arch/arm/boot/compressed/head.S | 12 ++++++++++++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 5cad8a6..dfe5687 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -121,7 +121,7 @@ KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS))
endif
ccflags-y := -fpic -fno-builtin -I$(obj)
-asflags-y := -Wa,-march=all -DZIMAGE
+asflags-y := -DZIMAGE
# Supply kernel BSS size to the decompressor via a linker symbol.
KBSS_SZ = $(shell $(CROSS_COMPILE)size $(obj)/../../../../vmlinux | \
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index fe4d9c3..3b0b21a 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -548,6 +548,7 @@ cache_on: mov r3, #8 @ cache_on function
* to cover all 32bit address and cacheable and bufferable.
*/
__armv4_mpu_cache_on:
+ .arch armv4
mov r0, #0x3f @ 4G, the whole
mcr p15, 0, r0, c6, c7, 0 @ PR7 Area Setting
mcr p15, 0, r0, c6, c7, 1
@@ -655,6 +656,7 @@ ENDPROC(__setup_mmu)
@ Enable unaligned access on v6, to allow better code generation
@ for the decompressor C code:
__armv6_mmu_cache_on:
+ .arch armv6
mrc p15, 0, r0, c1, c0, 0 @ read SCTLR
bic r0, r0, #2 @ A (no unaligned access fault)
orr r0, r0, #1 << 22 @ U (v6 unaligned access model)
@@ -663,11 +665,13 @@ __armv6_mmu_cache_on:
__arm926ejs_mmu_cache_on:
#ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
+ .arch armv5
mov r0, #4 @ put dcache in WT mode
mcr p15, 7, r0, c15, c0, 0
#endif
__armv4_mmu_cache_on:
+ .arch armv4
mov r12, lr
#ifdef CONFIG_MMU
mov r6, #CB_BITS | 0x12 @ U
@@ -688,6 +692,7 @@ __armv4_mmu_cache_on:
mov pc, r12
__armv7_mmu_cache_on:
+ .arch armv7-a
mov r12, lr
#ifdef CONFIG_MMU
mrc p15, 0, r11, c0, c1, 4 @ read ID_MMFR0
@@ -1031,6 +1036,7 @@ cache_clean_flush:
mov r3, #16
b call_cache_fn
+ .arch armv4
__armv4_mpu_cache_flush:
mov r2, #1
mov r3, #0
@@ -1056,6 +1062,7 @@ __fa526_cache_flush:
mov pc, lr
__armv6_mmu_cache_flush:
+ .arch armv6
mov r1, #0
mcr p15, 0, r1, c7, c14, 0 @ clean+invalidate D
mcr p15, 0, r1, c7, c5, 0 @ invalidate I+BTB
@@ -1063,6 +1070,7 @@ __armv6_mmu_cache_flush:
mcr p15, 0, r1, c7, c10, 4 @ drain WB
mov pc, lr
+ .arch armv7-a
__armv7_mmu_cache_flush:
mrc p15, 0, r10, c0, c1, 5 @ read ID_MMFR1
tst r10, #0xf << 16 @ hierarchical cache (ARMv7)
@@ -1123,6 +1131,7 @@ iflush:
mcr p15, 0, r10, c7, c5, 4 @ ISB
mov pc, lr
+ .arch armv5
__armv5tej_mmu_cache_flush:
1: mrc p15, 0, r15, c7, c14, 3 @ test,clean,invalidate D cache
bne 1b
@@ -1130,6 +1139,7 @@ __armv5tej_mmu_cache_flush:
mcr p15, 0, r0, c7, c10, 4 @ drain WB
mov pc, lr
+ .arch armv4
__armv4_mmu_cache_flush:
mov r2, #64*1024 @ default: 32K dcache size (*2)
mov r11, #32 @ default: 32 byte line size
@@ -1168,6 +1178,8 @@ __armv3_mpu_cache_flush:
mcr p15, 0, r1, c7, c0, 0 @ invalidate whole cache v3
mov pc, lr
+ .arch armv4
+
/*
* Various debugging routines for printing hex characters and
* memory, which again must be relocatable.
--
1.8.0
^ permalink raw reply related
* [PATCH 3/5] ARM: samsung: fix assembly syntax for new gas
From: Arnd Bergmann @ 2013-01-25 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359127711-19070-1-git-send-email-arnd@arndb.de>
Recent assembler versions complain about extraneous
whitespace inside [] brackets. This fixes all of
these instances for the samsung platforms. We should
backport this to all kernels that might need to
be built with new binutils.
arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2410.S:48: Error: ARM register expected -- `ldr r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:49: Error: ARM register expected -- `ldr r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:50: Error: ARM register expected -- `ldr r9,[ r6 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:64: Error: ARM register expected -- `streq r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:65: Error: ARM register expected -- `streq r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:66: Error: ARM register expected -- `streq r9,[ r6 ]'
arch/arm/kernel/debug.S: Assembler messages:
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/mach-s3c24xx/pm-h1940.S: Assembler messages:
arch/arm/mach-s3c24xx/pm-h1940.S:33: Error: ARM register expected -- `ldr pc,[ r0,#((0x0B8)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000)))]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2412.S:60: Error: ARM register expected -- `ldrne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:61: Error: ARM register expected -- `strne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:62: Error: ARM register expected -- `ldrne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:63: Error: ARM register expected -- `strne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:64: Error: ARM register expected -- `ldrne r9,[ r3 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:65: Error: ARM register expected -- `strne r9,[ r3 ]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: stable at vger.kernel.org
---
arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 12 ++++++------
arch/arm/mach-s3c24xx/include/mach/entry-macro.S | 4 ++--
arch/arm/mach-s3c24xx/pm-h1940.S | 2 +-
arch/arm/mach-s3c24xx/sleep-s3c2410.S | 12 ++++++------
arch/arm/mach-s3c24xx/sleep-s3c2412.S | 12 ++++++------
arch/arm/plat-samsung/include/plat/debug-macro.S | 18 +++++++++---------
6 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
index 4135de8..13ed33c 100644
--- a/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/debug-macro.S
@@ -40,17 +40,17 @@
addeq \rd, \rx, #(S3C24XX_PA_GPIO - S3C24XX_PA_UART)
addne \rd, \rx, #(S3C24XX_VA_GPIO - S3C24XX_VA_UART)
bic \rd, \rd, #0xff000
- ldr \rd, [ \rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0) ]
+ ldr \rd, [\rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0)]
and \rd, \rd, #0x00ff0000
teq \rd, #0x00440000 @ is it 2440?
1004:
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
moveq \rd, \rd, lsr #SHIFT_2440TXF
tst \rd, #S3C2410_UFSTAT_TXFULL
.endm
.macro fifo_full_s3c2410 rd, rx
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
tst \rd, #S3C2410_UFSTAT_TXFULL
.endm
@@ -68,18 +68,18 @@
addeq \rd, \rx, #(S3C24XX_PA_GPIO - S3C24XX_PA_UART)
addne \rd, \rx, #(S3C24XX_VA_GPIO - S3C24XX_VA_UART)
bic \rd, \rd, #0xff000
- ldr \rd, [ \rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0) ]
+ ldr \rd, [\rd, # S3C2410_GSTATUS1 - S3C2410_GPIOREG(0)]
and \rd, \rd, #0x00ff0000
teq \rd, #0x00440000 @ is it 2440?
10000:
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
andne \rd, \rd, #S3C2410_UFSTAT_TXMASK
andeq \rd, \rd, #S3C2440_UFSTAT_TXMASK
.endm
.macro fifo_level_s3c2410 rd, rx
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
and \rd, \rd, #S3C2410_UFSTAT_TXMASK
.endm
diff --git a/arch/arm/mach-s3c24xx/include/mach/entry-macro.S b/arch/arm/mach-s3c24xx/include/mach/entry-macro.S
index 7615a14..6a21bee 100644
--- a/arch/arm/mach-s3c24xx/include/mach/entry-macro.S
+++ b/arch/arm/mach-s3c24xx/include/mach/entry-macro.S
@@ -31,10 +31,10 @@
@@ try the interrupt offset register, since it is there
- ldr \irqstat, [ \base, #INTPND ]
+ ldr \irqstat, [\base, #INTPND ]
teq \irqstat, #0
beq 1002f
- ldr \irqnr, [ \base, #INTOFFSET ]
+ ldr \irqnr, [\base, #INTOFFSET ]
mov \tmp, #1
tst \irqstat, \tmp, lsl \irqnr
bne 1001f
diff --git a/arch/arm/mach-s3c24xx/pm-h1940.S b/arch/arm/mach-s3c24xx/pm-h1940.S
index c93bf2d..6183a68 100644
--- a/arch/arm/mach-s3c24xx/pm-h1940.S
+++ b/arch/arm/mach-s3c24xx/pm-h1940.S
@@ -30,4 +30,4 @@
h1940_pm_return:
mov r0, #S3C2410_PA_GPIO
- ldr pc, [ r0, #S3C2410_GSTATUS3 - S3C24XX_VA_GPIO ]
+ ldr pc, [r0, #S3C2410_GSTATUS3 - S3C24XX_VA_GPIO]
diff --git a/arch/arm/mach-s3c24xx/sleep-s3c2410.S b/arch/arm/mach-s3c24xx/sleep-s3c2410.S
index dd5b638..65200ae 100644
--- a/arch/arm/mach-s3c24xx/sleep-s3c2410.S
+++ b/arch/arm/mach-s3c24xx/sleep-s3c2410.S
@@ -45,9 +45,9 @@ ENTRY(s3c2410_cpu_suspend)
ldr r4, =S3C2410_REFRESH
ldr r5, =S3C24XX_MISCCR
ldr r6, =S3C2410_CLKCON
- ldr r7, [ r4 ] @ get REFRESH (and ensure in TLB)
- ldr r8, [ r5 ] @ get MISCCR (and ensure in TLB)
- ldr r9, [ r6 ] @ get CLKCON (and ensure in TLB)
+ ldr r7, [r4] @ get REFRESH (and ensure in TLB)
+ ldr r8, [r5] @ get MISCCR (and ensure in TLB)
+ ldr r9, [r6] @ get CLKCON (and ensure in TLB)
orr r7, r7, #S3C2410_REFRESH_SELF @ SDRAM sleep command
orr r8, r8, #S3C2410_MISCCR_SDSLEEP @ SDRAM power-down signals
@@ -61,8 +61,8 @@ ENTRY(s3c2410_cpu_suspend)
@@ align next bit of code to cache line
.align 5
s3c2410_do_sleep:
- streq r7, [ r4 ] @ SDRAM sleep command
- streq r8, [ r5 ] @ SDRAM power-down config
- streq r9, [ r6 ] @ CPU sleep
+ streq r7, [r4] @ SDRAM sleep command
+ streq r8, [r5] @ SDRAM power-down config
+ streq r9, [r6] @ CPU sleep
1: beq 1b
mov pc, r14
diff --git a/arch/arm/mach-s3c24xx/sleep-s3c2412.S b/arch/arm/mach-s3c24xx/sleep-s3c2412.S
index c82418e..5adaceb 100644
--- a/arch/arm/mach-s3c24xx/sleep-s3c2412.S
+++ b/arch/arm/mach-s3c24xx/sleep-s3c2412.S
@@ -57,12 +57,12 @@ s3c2412_sleep_enter1:
* retry, as simply returning causes the system to lock.
*/
- ldrne r9, [ r1 ]
- strne r9, [ r1 ]
- ldrne r9, [ r2 ]
- strne r9, [ r2 ]
- ldrne r9, [ r3 ]
- strne r9, [ r3 ]
+ ldrne r9, [r1]
+ strne r9, [r1]
+ ldrne r9, [r2]
+ strne r9, [r2]
+ ldrne r9, [r3]
+ strne r9, [r3]
bne s3c2412_sleep_enter1
mov pc, r14
diff --git a/arch/arm/plat-samsung/include/plat/debug-macro.S b/arch/arm/plat-samsung/include/plat/debug-macro.S
index 207e275..f3a9cff 100644
--- a/arch/arm/plat-samsung/include/plat/debug-macro.S
+++ b/arch/arm/plat-samsung/include/plat/debug-macro.S
@@ -14,12 +14,12 @@
/* The S5PV210/S5PC110 implementations are as belows. */
.macro fifo_level_s5pv210 rd, rx
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
and \rd, \rd, #S5PV210_UFSTAT_TXMASK
.endm
.macro fifo_full_s5pv210 rd, rx
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
tst \rd, #S5PV210_UFSTAT_TXFULL
.endm
@@ -27,7 +27,7 @@
* most widely re-used */
.macro fifo_level_s3c2440 rd, rx
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
and \rd, \rd, #S3C2440_UFSTAT_TXMASK
.endm
@@ -36,7 +36,7 @@
#endif
.macro fifo_full_s3c2440 rd, rx
- ldr \rd, [ \rx, # S3C2410_UFSTAT ]
+ ldr \rd, [\rx, # S3C2410_UFSTAT]
tst \rd, #S3C2440_UFSTAT_TXFULL
.endm
@@ -45,11 +45,11 @@
#endif
.macro senduart,rd,rx
- strb \rd, [\rx, # S3C2410_UTXH ]
+ strb \rd, [\rx, # S3C2410_UTXH]
.endm
.macro busyuart, rd, rx
- ldr \rd, [ \rx, # S3C2410_UFCON ]
+ ldr \rd, [\rx, # S3C2410_UFCON]
tst \rd, #S3C2410_UFCON_FIFOMODE @ fifo enabled?
beq 1001f @
@ FIFO enabled...
@@ -60,7 +60,7 @@
1001:
@ busy waiting for non fifo
- ldr \rd, [ \rx, # S3C2410_UTRSTAT ]
+ ldr \rd, [\rx, # S3C2410_UTRSTAT]
tst \rd, #S3C2410_UTRSTAT_TXFE
beq 1001b
@@ -68,7 +68,7 @@
.endm
.macro waituart,rd,rx
- ldr \rd, [ \rx, # S3C2410_UFCON ]
+ ldr \rd, [\rx, # S3C2410_UFCON]
tst \rd, #S3C2410_UFCON_FIFOMODE @ fifo enabled?
beq 1001f @
@ FIFO enabled...
@@ -79,7 +79,7 @@
b 1002f
1001:
@ idle waiting for non fifo
- ldr \rd, [ \rx, # S3C2410_UTRSTAT ]
+ ldr \rd, [\rx, # S3C2410_UTRSTAT]
tst \rd, #S3C2410_UTRSTAT_TXFE
beq 1001b
--
1.8.0
^ permalink raw reply related
* [PATCH 4/5] ARM: w90x900: fix legacy assembly syntax
From: Arnd Bergmann @ 2013-01-25 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359127711-19070-1-git-send-email-arnd@arndb.de>
New ARM binutils don't allow extraneous whitespace inside
of brackets, which causes this error on all mach-w90x900
defconfigs:
arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'
This removes the whitespace in order to build the kernel
again.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Wan ZongShun <mcuos.com@gmail.com>
---
arch/arm/mach-w90x900/include/mach/entry-macro.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-w90x900/include/mach/entry-macro.S b/arch/arm/mach-w90x900/include/mach/entry-macro.S
index e286dac..0ff612a 100644
--- a/arch/arm/mach-w90x900/include/mach/entry-macro.S
+++ b/arch/arm/mach-w90x900/include/mach/entry-macro.S
@@ -19,8 +19,8 @@
mov \base, #AIC_BA
- ldr \irqnr, [ \base, #AIC_IPER]
- ldr \irqnr, [ \base, #AIC_ISNR]
+ ldr \irqnr, [\base, #AIC_IPER]
+ ldr \irqnr, [\base, #AIC_ISNR]
cmp \irqnr, #0
.endm
--
1.8.0
^ permalink raw reply related
* [PATCH 5/5] drm/exynos: don't include plat/gpio-cfg.h
From: Arnd Bergmann @ 2013-01-25 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359127711-19070-1-git-send-email-arnd@arndb.de>
Patch 9eb3e9e6f3 "drm/exynos: add support for ARCH_MULTIPLATFORM"
allowed building the exynos hdmi driver on non-samsung platforms,
which unfortunately broke compilation in combination with 22c4f42897
"drm: exynos: hdmi: add support for exynos5 hdmi", which added
an inclusion of the samsung-specific plat/gpio-cfg.h header file.
Fortunately, that header file is not required any more here, so
we can simply revert the inclusion in order to build the ARM
allyesconfig again without getting this error:
drivers/gpu/drm/exynos/exynos_hdmi.c:37:27: fatal error: plat/gpio-cfg.h: No such file or directory
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Clark <rob@ti.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Rahul Sharma <rahul.sharma@samsung.com>
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 41ff79d..b5f5119 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,7 +34,6 @@
#include <linux/regulator/consumer.h>
#include <linux/io.h>
#include <linux/of_gpio.h>
-#include <plat/gpio-cfg.h>
#include <drm/exynos_drm.h>
--
1.8.0
^ permalink raw reply related
* [GIT PULL v2] arm-soc: Xilinx zynq timer changes for v3.9
From: Michal Simek @ 2013-01-25 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHTX3d+qeKPT3YYG3=YgWYN5YTS1oT9HoTEpVwC4GZAYve5uYw@mail.gmail.com>
Hi Arnd and Olof,
can you please look at this pull request?
Thanks,
Michal
2013/1/22 Michal Simek <michal.simek@xilinx.com>:
> Hi Arnd and Olof,
>
> please pull these timer changes to your arm-soc tree.
> As Arnd suggested this branch v2 is based on timer/cleanup and
> clocksource/cleanup arm-soc branches.
> There was one conflict with arch/arm/mach-pxa/time.c which I have resolved
> like Olof in the patch "Merge branch 'clocksource/cleanup' into next/cleanup"
> (sha1: 8d84981e395850aab31c3f2ca7e2738e03f671d7).
> (Also changed indentation in the pxa timer driver as Olof has done)
>
> Arnd also mentioned to move this timer driver to drivers/clocksource
> (+ use the new infrastructure introduced there) but this
> need to be a separate patch which must be reviewed first.
>
> Please let me know if I miss something.
>
> Thanks,
> Michal
>
> The following changes since commit 05ed8a3e5c3a48b5b63305920f88da94d9272b36:
> Michal Simek (1):
> Merge branch 'clocksource/cleanup' into zynq/timer
>
> are available in the git repository at:
>
> git://git.xilinx.com/linux-xlnx.git zynq/timer
>
> Soren Brinkmann (7):
> arm: zynq: timer: Replace PSS through PS
> arm: zynq: timer: Remove unnecessary register write
> arm: zynq: timer: Remove unused #defines
> arm: zynq: timer: Align columns
> arm: zynq: timer: Remove redundant #includes
> arm: zynq: timer: Fix comment style
> arm: zynq: timer: Set clock_event cpumask
>
> arch/arm/mach-zynq/common.c | 2 +-
> arch/arm/mach-zynq/common.h | 2 +-
> arch/arm/mach-zynq/timer.c | 150 ++++++++++++++++++++----------------------
> 3 files changed, 73 insertions(+), 81 deletions(-)
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian
^ permalink raw reply
* [PATCHv1 for soc 4/5] arm: Add v7_invalidate_l1 to cache-v7.S
From: Pavel Machek @ 2013-01-25 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359075633-13502-5-git-send-email-dinguyen@altera.com>
Hi!
> mach-socfpga is another platform that needs to use
> v7_invalidate_l1 to bringup additional cores. There was a comment that
> the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
If there are three copies of code, with fourth one needed for next
platform, moving it into common code makes sense.
But... The code was not identical before the merge. Are you sure that
the differences do not hurt? At the very least, it should be mentioned
in the changelog.
Thanks,
Pavel
> diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> index 7e49deb..921fc15 100644
> --- a/arch/arm/mach-imx/headsmp.S
> +++ b/arch/arm/mach-imx/headsmp.S
> @@ -17,53 +17,6 @@
> -ENTRY(v7_invalidate_l1)
> - mov r0, #0
> - mcr p15, 0, r0, c7, c5, 0 @ invalidate I cache
> - mcr p15, 2, r0, c0, c0, 0
> - mrc p15, 1, r0, c0, c0, 0
...
> diff --git a/arch/arm/mach-tegra/headsmp.S b/arch/arm/mach-tegra/headsmp.S
> index 4a317fa..fb082c4 100644
> --- a/arch/arm/mach-tegra/headsmp.S
> +++ b/arch/arm/mach-tegra/headsmp.S
> @@ -18,49 +18,6 @@
> -ENTRY(v7_invalidate_l1)
> - mov r0, #0
> - mcr p15, 2, r0, c0, c0, 0
> - mrc p15, 1, r0, c0, c0, 0
[Note missing mcr p15, 0, .. line.]
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH v3 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
From: Mark Rutland @ 2013-01-25 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359116591-32730-3-git-send-email-ezequiel.garcia@free-electrons.com>
Hi,
I have a couple more comments after looking though this a bit more thoroughly.
On Fri, Jan 25, 2013 at 12:23:11PM +0000, Ezequiel Garcia wrote:
> This patch adds device tree bindings for OMAP OneNAND devices.
> Tested on an OMAP3 3430 IGEPv2 board.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
> Changes from v2:
> * Remove unneeded of_node_put() as reported by Mark Rutland
>
> Changes from v1:
> * Fix typo in Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
>
> .../devicetree/bindings/mtd/gpmc-onenand.txt | 43 +++++++++++++++++++
> arch/arm/mach-omap2/gpmc.c | 45 ++++++++++++++++++++
> 2 files changed, 88 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
> new file mode 100644
> index 0000000..deec9da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
> @@ -0,0 +1,43 @@
> +Device tree bindings for GPMC connected OneNANDs
> +
> +GPMC connected OneNAND (found on OMAP boards) are represented as child nodes of
> +the GPMC controller with a name of "onenand".
> +
> +All timing relevant properties as well as generic gpmc child properties are
> +explained in a separate documents - please refer to
> +Documentation/devicetree/bindings/bus/ti-gpmc.txt
Which tree can I find this in?
> +
> +Required properties:
> +
> + - reg: The CS line the peripheral is connected to
> +
> +Optional properties:
> +
> + - dma-channel: DMA Channel index
> +
> +For inline partiton table parsing (optional):
> +
> + - #address-cells: should be set to 1
> + - #size-cells: should be set to 1
> +
> +Example for an OMAP3430 board:
> +
> + gpmc: gpmc at 6e000000 {
> + compatible = "ti,omap3430-gpmc";
> + ti,hwmods = "gpmc";
> + reg = <0x6e000000 0x1000000>;
> + interrupts = <20>;
> + gpmc,num-cs = <8>;
> + gpmc,num-waitpins = <4>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> +
> + onenand at 0 {
> + reg = <0 0 0>; /* CS0, offset 0 */
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + /* partitions go here */
> + };
> + };
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index c6255f7..0636d0a 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -39,6 +39,7 @@
> #include "omap_device.h"
> #include "gpmc.h"
> #include "gpmc-nand.h"
> +#include "gpmc-onenand.h"
>
> #define DEVICE_NAME "omap-gpmc"
>
> @@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct platform_device *pdev,
> }
> #endif
>
> +#ifdef CONFIG_MTD_ONENAND
> +static int gpmc_probe_onenand_child(struct platform_device *pdev,
> + struct device_node *child)
> +{
> + u32 val;
> + struct omap_onenand_platform_data *gpmc_onenand_data;
> +
> + if (of_property_read_u32(child, "reg", &val) < 0) {
> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
> + child->full_name);
> + return -ENODEV;
> + }
I don't understand the format of the reg property, but it seems odd that you
only need to read one cell from it. Are the remaining address cell and size
cell used anywhere?
> +
> + gpmc_onenand_data = devm_kzalloc(&pdev->dev, sizeof(*gpmc_onenand_data),
> + GFP_KERNEL);
> + if (!gpmc_onenand_data)
> + return -ENOMEM;
> +
> + gpmc_onenand_data->cs = val;
> + gpmc_onenand_data->of_node = child;
> + gpmc_onenand_data->dma_channel = -1;
> +
> + if (!of_property_read_u32(child, "dma-channel", &val))
> + gpmc_onenand_data->dma_channel = val;
> +
> + gpmc_onenand_init(gpmc_onenand_data);
> +
> + return 0;
> +}
[...]
Otherwise looks good.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 18/19] ARM: at91: suspend both memory controllers on at91sam9263
From: Arnd Bergmann @ 2013-01-25 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125154219.GM7360@game.jcrosoft.org>
On Friday 25 January 2013 16:42:19 Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 14:14 Fri 25 Jan , Arnd Bergmann wrote:
> > For the past three years, we have had a #warning in
> > mach-at91 about the sdram_selfrefresh_enable or
> > at91sam9_standby functions possibly not working on
> > at91sam9263. In the meantime a function was added
> > to do the right thing on at91sam9g45, which looks like
> > it should also work on '9263.
> >
> > This patch blindly removes the warning and changes the
> > at91sam9263 to use the same code at at91sam9g45, which
> > may or may not be the right solution. If it is not,
> > maybe someone could provide a better fix.
> it's not
>
> the 9g45 use DDR Controler where the 9263 use a SDRAM controler
>
Ah, right. What about this one then?
Arnd
8<-----
Subject: [PATCH] ARM: at91: suspend both memory controllers on at91sam9263
For the past three years, we have had a #warning in
mach-at91 about the sdram_selfrefresh_enable or
at91sam9_standby functions possibly not working on
at91sam9263. In the meantime a function was added
to do the right thing on at91sam9g45, which looks like
it should also work on '9263.
This patch blindly removes the warning and changes the
at91sam9263 to use the same code at at91sam9g45, which
may or may not be the right solution. If it is not,
maybe someone could provide a better fix.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 0c63815..4c67946 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -38,6 +38,8 @@ static int at91_enter_idle(struct cpuidle_device *dev,
at91rm9200_standby();
else if (cpu_is_at91sam9g45())
at91sam9g45_standby();
+ else if (cpu_is_at91sam9263())
+ at91sam9263_standby();
else
at91sam9_standby();
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index adb6db8..b8017c1 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -267,6 +267,8 @@ static int at91_pm_enter(suspend_state_t state)
at91rm9200_standby();
else if (cpu_is_at91sam9g45())
at91sam9g45_standby();
+ else if (cpu_is_at91sam9263())
+ at91sam9263_standby();
else
at91sam9_standby();
break;
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 38f467c..2f5908f 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -70,13 +70,31 @@ static inline void at91sam9g45_standby(void)
at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
}
-#ifdef CONFIG_SOC_AT91SAM9263
-/*
- * FIXME either or both the SDRAM controllers (EB0, EB1) might be in use;
- * handle those cases both here and in the Suspend-To-RAM support.
+/* We manage both DDRAM/SDRAM controllers, we need more than one value to
+ * remember.
*/
-#warning Assuming EB1 SDRAM controller is *NOT* used
-#endif
+static inline void at91sam9263_standby(void)
+{
+ u32 lpr0, lpr1;
+ u32 saved_lpr0, saved_lpr1;
+
+ saved_lpr1 = at91_ramc_read(1, AT91_SDRAMC_LPR);
+ lpr1 = saved_lpr1 & ~AT91_SDRAMC_LPCB;
+ lpr1 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
+
+ saved_lpr0 = at91_ramc_read(0, AT91_SDRAMC_LPR);
+ lpr0 = saved_lpr0 & ~AT91_SDRAMC_LPCB;
+ lpr0 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
+
+ /* self-refresh mode now */
+ at91_ramc_write(0, AT91_SDRAMC_LPR, lpr0);
+ at91_ramc_write(1, AT91_SDRAMC_LPR, lpr1);
+
+ cpu_do_idle();
+
+ at91_ramc_write(0, AT91_SDRAMC_LPR, saved_lpr0);
+ at91_ramc_write(1, AT91_SDRAMC_LPR, saved_lpr1);
+}
static inline void at91sam9_standby(void)
{
^ permalink raw reply related
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