* DEBUG_LL broken for socfpga
From: Thomas Petazzoni @ 2012-10-25 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351186792.15182.14.camel@dinh-ubuntu>
Dinh,
On Thu, 25 Oct 2012 11:39:52 -0600, Dinh Nguyen wrote:
> Doesn't this patch address the fix?
>
> in arm-soc for-next
> commit ef3f94412a4d7e107392e7c7cfc3e2d0668aa1aa
>
> http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=ef3f94412a4d7e107392e7c7cfc3e2d0668aa1aa
Indeed, it fixes the problem. I was looking at 3.7-rc2, and forgot to
check in arm-soc/for-next before reporting the issue.
Sorry for the noise.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: PMU: fix runtime PM enable
From: Will Deacon @ 2012-10-25 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vcdy33ma.fsf@deeprootsystems.com>
On Thu, Oct 25, 2012 at 05:42:21PM +0100, Kevin Hilman wrote:
> Jon Hunter <jon-hunter@ti.com> writes:
> > On 10/24/2012 12:23 PM, Will Deacon wrote:
> >> What do other drivers do? Grepping around, I see calls to pm_runtime_enable
> >> made in various drivers and, given that you pass the device in there, what's
> >> the problem with us just calling that unconditionally from perf? I know you
> >> said that will work for OMAP, but I'm trying to understand the effect that
> >> has on PM-aware platforms that don't require this for the PMU (since this
> >> seems to be per-device).
> >
> > I had done this initially when testing on OMAP platforms that do and
> > don't require runtime PM for PMU. I don't see any side affect of this,
> > however, may be Kevin could comment on if that is ok. It would be the
> > best approach.
>
> Unconditonally enabling runtime PM should be fine. It may add a slight
> bit of overhead calling runtime PM functions that ultimately do nothing
> (because there are no callbacks), but it will be harmless.
>
> Personally, I think that would be cleaner. The less pdata we need, the
> better, IMO.
Thanks Kevin, I'm fine with that. Jon: want me to write a patch or do you
have something I can take into the ARM perf tree (if the latter, please
base against perf/updates)?
Cheers,
Will
^ permalink raw reply
* [PATCH v2] gpio/omap: fix off-mode bug: clear debounce clock enable mask on free/reset
From: Jon Hunter @ 2012-10-25 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87hapi4ir9.fsf@deeprootsystems.com>
On 10/25/2012 11:30 AM, Kevin Hilman wrote:
> Jon Hunter <jon-hunter@ti.com> writes:
>
>> On 10/25/2012 02:00 AM, Santosh Shilimkar wrote:
>>> On Thursday 25 October 2012 04:24 AM, Jon Hunter wrote:
>>>>
>>>> On 10/24/2012 12:10 PM, Kevin Hilman wrote:
>>>>> From: Kevin Hilman <khilman@ti.com>
>>>>>
>>>>> When a GPIO bank is freed or shutdown, ensure that the banks
>>>>> dbck_enable_mask is cleared also. Otherwise, context restore on
>>>>> subsequent off-mode transition will restore previous value from the
>>>>> shadow copies (bank->context.debounce*) leading to mismatch state
>>>>> between driver state and hardware state.
>>>>>
>>>>> This was discovered when board code was doing
>>>>>
>>>>> gpio_request_one()
>>>>> gpio_set_debounce()
>>>>> gpio_free()
>>>>>
>>>>> which was leaving the GPIO debounce settings in a confused state. If
>>>>> that GPIO bank is subsequently used with off-mode enabled, bogus state
>>>>> would be restored, leaving GPIO debounce enabled which then prevented
>>>>> the CORE powerdomain from transitioning.
>>>>>
>>>>> To fix, ensure that bank->dbck_enable_mask is cleared when the bank
>>>>> is freed/shutdown so debounce state doesn't persist.
>>> The freed part is fine but I don't understand why it needs to be done
>>> on _a_ gpio irq shutdown callback where IRQs related configuration
>>> on that one GPIO needs to be cleared. De-bounce clock is surely not IRQ
>>> related configuration.
>>
>> If we are freeing the IRQs related to gpio and resetting the gpio, then
>> I don't see why we should not. We should not leave the debounce clock on
>> if these gpios are no longer being used.
>>
>>>>> Special thanks to Grazvydas Ignotas for pointing out a bug in an
>>>>> earlier version that would've disabled debounce on any runtime PM
>>>>> transition.
>>>>>
>>>>> Reported-by: Paul Walmsley <paul@pwsan.com>
>>>>> Cc: Igor Grinberg <grinberg@compulab.co.il>
>>>>> Cc: Grazvydas Ignotas <notasas@gmail.com>
>>>>> Signed-off-by: Kevin Hilman <khilman@ti.com>
>>>>> ---
>>>>> v2: only clear mask in free/shutdown, not in runtime PM paths,
>>>>> clarified changelog
>>>>> Applies on v3.7-rc2.
>>>>>
>>>>> drivers/gpio/gpio-omap.c | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>>>> index 94cbc84..113b167 100644
>>>>> --- a/drivers/gpio/gpio-omap.c
>>>>> +++ b/drivers/gpio/gpio-omap.c
>>>>> @@ -539,6 +539,7 @@ static void _reset_gpio(struct gpio_bank *bank,
>>>>> int gpio)
>>>>> _set_gpio_irqenable(bank, gpio, 0);
>>>>> _clear_gpio_irqstatus(bank, gpio);
>>>>> _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE);
>>>>> + bank->dbck_enable_mask = 0;
>>>>> }
>>>>
>>>> Does this need to be ...
>>>>
>>>> + bank->dbck_enable_mask &= ~(GPIO_BIT(bank, gpio));
>>>> + _gpio_dbck_disable(bank);
>>>>
>>> Yes, its a per bank clock. There is an alternate. See below.
>>>
>>>> There could be more than one gpio using debounce and so we should only
>>>> clear the appropriate bit. Also after clearing a bit we could see if we
>>>> can disable the debounce clock too.
>>>>
>>> When I mentioned the clearing in gpio_free() path will do trick, I had
>>> something like below in mind.
>>>
>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>> index dee2856..8574105 100644
>>> --- a/drivers/gpio/gpio-omap.c
>>> +++ b/drivers/gpio/gpio-omap.c
>>> @@ -629,8 +629,10 @@ static void omap_gpio_free(struct gpio_chip *chip,
>>> unsigned offset)
>>> * If this is the last gpio to be freed in the bank,
>>> * disable the bank module.
>>> */
>>> - if (!bank->mod_usage)
>>> + if (!bank->mod_usage) {
>>> + bank->dbck_enable_mask = 0;
>>> pm_runtime_put(bank->dev);
>>> + }
>>
>> However, with this we could be leaving the debounce clock on longer than
>> needed. I think we need to call _gpio_dbck_disable() each time we free a
>> gpio and this function will determine if it can turn off the debounce
>> clock.
>>
>> In fact, there appears to be another bug in the current driver, that we
>> do not clear the debounce_en register when freeing the gpio. Your patch
>> addresses this, but I think that debounce should be disabled when a gpio
>> is freed and not just when the last one is freed.
>>
>> Also, with the above change, can't we still run into the original
>> problem? In other words, if a gpio is freed, but there is still another
>> one active in the back that is not using debounce, then we could restore
>> a incorrect debounce context because we have not clean-up the debounce
>> settings?
>>
>> So may be we need to add a _clear_gpio_debounce() function and
>> call this when freeing a gpio.
>
> Care to cook up a patch for this, on top of v3 of $SUBJECT patch?
Yes will do.
Cheers
Jon
^ permalink raw reply
* [PATCH] ARM: PMU: fix runtime PM enable
From: Jon Hunter @ 2012-10-25 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025164714.GK11267@mudshark.cambridge.arm.com>
On 10/25/2012 11:47 AM, Will Deacon wrote:
> On Thu, Oct 25, 2012 at 05:42:21PM +0100, Kevin Hilman wrote:
>> Jon Hunter <jon-hunter@ti.com> writes:
>>> On 10/24/2012 12:23 PM, Will Deacon wrote:
>>>> What do other drivers do? Grepping around, I see calls to pm_runtime_enable
>>>> made in various drivers and, given that you pass the device in there, what's
>>>> the problem with us just calling that unconditionally from perf? I know you
>>>> said that will work for OMAP, but I'm trying to understand the effect that
>>>> has on PM-aware platforms that don't require this for the PMU (since this
>>>> seems to be per-device).
>>>
>>> I had done this initially when testing on OMAP platforms that do and
>>> don't require runtime PM for PMU. I don't see any side affect of this,
>>> however, may be Kevin could comment on if that is ok. It would be the
>>> best approach.
>>
>> Unconditonally enabling runtime PM should be fine. It may add a slight
>> bit of overhead calling runtime PM functions that ultimately do nothing
>> (because there are no callbacks), but it will be harmless.
>>
>> Personally, I think that would be cleaner. The less pdata we need, the
>> better, IMO.
>
> Thanks Kevin, I'm fine with that. Jon: want me to write a patch or do you
> have something I can take into the ARM perf tree (if the latter, please
> base against perf/updates)?
I can easily spin this. Will base on top of your branch.
Cheers
Jon
^ permalink raw reply
* [PATCH] [ARM] pxa/spitz_pm.c: Fix hang under certain conditions when resuming from STR.
From: dromede at gmail.com @ 2012-10-25 16:51 UTC (permalink / raw)
To: linux-arm-kernel
From: Marko Katic <dromede.gmail.com>
Devices that use spitz_pm.c will fail to resume
from STR (Suspend To Ram) when the charger plug is inserted
or removed when a device is in STR mode. The culprit is
a misconfigured gpio line - GPIO18. GPIO18 should be configured as a
regular GPIO input but it gets configured as an alternate function
GPIO18_RDY. And then later in postsuspend() it gets configured as
a regular GPIO18 input line.
Fix this by removing the GPIO18_RDY configuration so that GPIO18
only gets configured as a regular gpio input.
Signed-off-by: Marko Katic <dromede.gmail.com>
---
arch/arm/mach-pxa/spitz_pm.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-pxa/spitz_pm.c b/arch/arm/mach-pxa/spitz_pm.c
index 438f02f..842596d 100644
--- a/arch/arm/mach-pxa/spitz_pm.c
+++ b/arch/arm/mach-pxa/spitz_pm.c
@@ -86,10 +86,7 @@ static void spitz_discharge1(int on)
gpio_set_value(SPITZ_GPIO_LED_GREEN, on);
}
-static unsigned long gpio18_config[] = {
- GPIO18_RDY,
- GPIO18_GPIO,
-};
+static unsigned long gpio18_config = GPIO18_GPIO;
static void spitz_presuspend(void)
{
@@ -112,7 +109,7 @@ static void spitz_presuspend(void)
PGSR3 &= ~SPITZ_GPIO_G3_STROBE_BIT;
PGSR2 |= GPIO_bit(SPITZ_GPIO_KEY_STROBE0);
- pxa2xx_mfp_config(&gpio18_config[0], 1);
+ pxa2xx_mfp_config(&gpio18_config, 1);
gpio_request_one(18, GPIOF_OUT_INIT_HIGH, "Unknown");
gpio_free(18);
@@ -131,7 +128,6 @@ static void spitz_presuspend(void)
static void spitz_postsuspend(void)
{
- pxa2xx_mfp_config(&gpio18_config[1], 1);
}
static int spitz_should_wakeup(unsigned int resume_on_alarm)
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Tony Lindgren @ 2012-10-25 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1466344.HbU9q5zM1q@avalon>
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [121025 01:39]:
>
> I still think you should split this in two files, omap-iommu.h and omap-
> iovmm.h. The later would just be arch/arm/plat-omap/include/plat/iovmm.h moved
> to include/linux.h.
Can you please explain a bit more why you're thinking a separate
omap-iovmm.h is needed in addtion to omap-iommu.h?
My reasoning for not adding it is that neither intel nor amd needs
more than intel-iommu.h and amd-iommu.h. And hopefully the iommu
framework will eventually provide the API needed. And I'd rather
not be the person introducing this second new file into
include/linux :)
Joerg and Ohad, do you have any opinions on this?
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP2+: PM: add missing newline to VC warning message
From: Kevin Hilman @ 2012-10-25 17:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Kevin Hilman <khilman@ti.com>
Add missing newline to warning message to avoid annoying
wrapping problems during kernel boot like this one:
omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).Power Management for TI OMAP4.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/vc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 880249b..75878c3 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -264,7 +264,7 @@ static void __init omap_vc_i2c_init(struct voltagedomain *voltdm)
if (initialized) {
if (voltdm->pmic->i2c_high_speed != i2c_high_speed)
- pr_warn("%s: I2C config for vdd_%s does not match other channels (%u).",
+ pr_warn("%s: I2C config for vdd_%s does not match other channels (%u).\n",
__func__, voltdm->name, i2c_high_speed);
return;
}
--
1.8.0
^ permalink raw reply related
* DEBUG_LL broken for socfpga
From: Dinh Nguyen @ 2012-10-25 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025181823.6c3fa0de@skate>
Hi Thomas,
On Thu, 2012-10-25 at 18:18 +0200, Thomas Petazzoni wrote:
> Dinh,
>
> The arch/arm/include/debug/socfpga.S file implements only addruart, and
> forgets to implement waituart, senduart, busyuart:
>
> AS arch/arm/kernel/debug.o
> /home/thomas/projets/linux-2.6/arch/arm/kernel/debug.S: Assembler messages:
> /home/thomas/projets/linux-2.6/arch/arm/kernel/debug.S:83: Error: bad instruction `waituart r2,r3'
> /home/thomas/projets/linux-2.6/arch/arm/kernel/debug.S:84: Error: bad instruction `senduart r1,r3'
> /home/thomas/projets/linux-2.6/arch/arm/kernel/debug.S:85: Error: bad instruction `busyuart r2,r3'
>
> Since the socfpga UART is apparently 8250 compatible, adding:
>
> #define UART_SHIFT 2
> #include <asm/hardware/debug-8250.S>
>
> at the end of socfpga.S should be sufficient. However, socfpga.S uses
> an undefined DEBUG_LL_UART_OFFSET. And also most likely there is a
> missing static mapping for the UART registers in
> arch/arm/mach-socfpga/socfpga.c in order to get a virtual address for
> the UART registers soon enough for earlyprintk to work.
>
> Probably easy to fix, but I have no hardware and no datasheet.
> Certainly better if someone having those could handle the
> implementation of the fix.
Doesn't this patch address the fix?
in arm-soc for-next
commit ef3f94412a4d7e107392e7c7cfc3e2d0668aa1aa
http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=ef3f94412a4d7e107392e7c7cfc3e2d0668aa1aa
Thanks,
Dinh
>
> Best regards,
>
> Thomas
^ permalink raw reply
* [PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support
From: Tony Lindgren @ 2012-10-25 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025061722.GB4449@arwen.pp.htv.fi>
* Felipe Balbi <balbi@ti.com> [121024 23:24]:
> Hi,
>
> On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [121016 09:53]:
> > > * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> > > > ocp2scp was not having pdata support which makes *musb* fail for non-dt
> > > > boot in OMAP platform. The pdata will have information about the devices
> > > > that is connected to ocp2scp. ocp2scp driver will now make use of this
> > > > information to create the devices that is attached to ocp2scp.
> > > >
> > > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > >
> > > This fixes the regression on my panda es for musb port:
> > >
> > > Acked-by: Tony Lindgren <tony@atomide.com>
> >
> > Looks like nobody has picked this one up and we need it to
> > fix the musb regression on omap, so I'll queue these up.
>
> I don't seem to have the patches around in any mailbox :-(
Bounced them to you. Do you have any better ideas for the
-rc cycle to fix the MUSB regression on omap4?
Regards,
Tony
^ permalink raw reply
* [PATCHv2] arm:socfpga: Enable SMP for socfpga
From: Dinh Nguyen @ 2012-10-25 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50895D9F.4080009@gmail.com>
HI Rob,
On Thu, 2012-10-25 at 10:41 -0500, Rob Herring wrote:
>
> On 10/25/2012 11:25 AM, Dinh Nguyen wrote:
> > Hi Rob,
> >
> > On Wed, 2012-10-24 at 18:01 -0500, Rob Herring wrote:
> >> On 10/18/2012 12:32 PM, dinguyen at altera.com wrote:
> >>> From: Dinh Nguyen <dinguyen@altera.com>
> >>>
> >>> Enable SMP for the SOCFPGA platform.
> >>>
> >>> Signed-off-by: Pavel Machek <pavel@denx.de>
> >>> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> >>> ---
> >>> v2:
> >>> -Remove pen_release code
> >>> -Remove code that was already done by v7_setup
> >>> -Add bindings document for reset and system manager
> >>> -Move socfpga_sysmgr_init from platsmp.c to socfpga.c, because
> >>> we will need to use the reset and system manager for more than SMP.
> >>> -Move core.h to mach-socfpga from mach-socfpga/include/mach
> >>
> >> Just some lingering comments on the defconfig. Otherwise,
> >>
> >> Reviewed-by: Rob Herring <rob.herring@calxeda.com>
> >>
> >>> diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig
> >>> index 0ac1293..349ac22 100644
> >>> --- a/arch/arm/configs/socfpga_defconfig
> >>> +++ b/arch/arm/configs/socfpga_defconfig
> >>
> >> I'm still not clear why multi_v7 config does not work for you?
> >
> > multi_v7 works fine for me. But I need
> > +#CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
>
> Why? I don't think those should break other versions of A9. If they do,
> we need to fix that. In general, we should turn on all errata for
> multi-platform builds, so we need to make sure they are done in a
> compatible way and can be bypassed if they have performance impacts.
> That may ultimately require some runtime patching though.
Our virtual platform is having a problem with CONFIG_ARM_ERRATA_751472.
It could be that our virtual platform is not simulating this correctly.
Dinh
>
> Rob
>
> >
> > in order for SMP to work correctly on our platform.
> >
> >
> >>
> >>> @@ -1,5 +1,5 @@
> >>> CONFIG_EXPERIMENTAL=y
> >>> -CONFIG_SYSVIPC=y
> >>> +CONFIG_NO_HZ=y
> >>> CONFIG_IKCONFIG=y
> >>> CONFIG_IKCONFIG_PROC=y
> >>> CONFIG_LOG_BUF_SHIFT=14
> >>> @@ -16,10 +16,13 @@ CONFIG_MODULE_UNLOAD=y
> >>> # CONFIG_IOSCHED_DEADLINE is not set
> >>> # CONFIG_IOSCHED_CFQ is not set
> >>> CONFIG_ARCH_SOCFPGA=y
> >>> -CONFIG_MACH_SOCFPGA_CYCLONE5=y
> >>> -CONFIG_ARM_THUMBEE=y
> >>> +# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
> >>> # CONFIG_CACHE_L2X0 is not set
> >>> CONFIG_HIGH_RES_TIMERS=y
> >>> +CONFIG_SMP=y
> >>> +CONFIG_ARM_ARCH_TIMER=y
> >>
> >> You're an A9, right? You don't have arch timers.
> >
> > Yes, will remove in v3.
> >>
> >>> +CONFIG_HIGHMEM=y
> >>
> >> How much RAM? You need more than 2GB with CONFIG_VMSPLIT_2G.
> >
> > 1G for RAM only, so will remove in v3.
> >
> > Thanks,
> > Dinh
> >>
> >>> +CONFIG_HIGHPTE=y
> >>> CONFIG_VMSPLIT_2G=y
> >>> CONFIG_NR_CPUS=2
> >>> CONFIG_AEABI=y
> >>
> >>
> >
> >
> >
>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: PM: add missing newline to VC warning message
From: Nishanth Menon @ 2012-10-25 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351186501-32223-1-git-send-email-khilman@deeprootsystems.com>
On 10:35-20121025, Kevin Hilman wrote:
> From: Kevin Hilman <khilman@ti.com>
>
> Add missing newline to warning message to avoid annoying
> wrapping problems during kernel boot like this one:
>
> omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
> omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).Power Management for TI OMAP4.
>
> Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> arch/arm/mach-omap2/vc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
> index 880249b..75878c3 100644
> --- a/arch/arm/mach-omap2/vc.c
> +++ b/arch/arm/mach-omap2/vc.c
> @@ -264,7 +264,7 @@ static void __init omap_vc_i2c_init(struct voltagedomain *voltdm)
>
> if (initialized) {
> if (voltdm->pmic->i2c_high_speed != i2c_high_speed)
> - pr_warn("%s: I2C config for vdd_%s does not match other channels (%u).",
> + pr_warn("%s: I2C config for vdd_%s does not match other channels (%u).\n",
> __func__, voltdm->name, i2c_high_speed);
> return;
> }
Acked-by: Nishanth Menon <nm@ti.com>
while we are at it, could we clean up the pr_warning usage back to
pr_warn as well?
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 880249b..2d66f8c 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -186,7 +186,7 @@ int omap_vc_bypass_scale(struct voltagedomain *voltdm,
loop_cnt++;
if (retries_cnt > 10) {
- pr_warning("%s: Retry count exceeded\n", __func__);
+ pr_warn("%s: Retry count exceeded\n", __func__);
return -ETIMEDOUT;
}
--
Regards,
Nishanth Menon
^ permalink raw reply related
* [PATCH] ARM: OMAP2+: PM: VP: minor pr_warn updates
From: Nishanth Menon @ 2012-10-25 17:58 UTC (permalink / raw)
To: linux-arm-kernel
change pr_warnings to pr_warn and ensure a newline
is present in all messages
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/vp.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 85241b8..60d8515 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -138,7 +138,7 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
udelay(1);
}
if (timeout >= VP_TRANXDONE_TIMEOUT) {
- pr_warn("%s: vdd_%s TRANXDONE timeout exceeded. Voltage change aborted",
+ pr_warn("%s: vdd_%s TRANXDONE timeout exceeded. Voltage change aborted\n",
__func__, voltdm->name);
return -ETIMEDOUT;
}
@@ -197,7 +197,7 @@ void omap_vp_enable(struct voltagedomain *voltdm)
u32 vpconfig, volt;
if (!voltdm || IS_ERR(voltdm)) {
- pr_warning("%s: VDD specified does not exist!\n", __func__);
+ pr_warn("%s: VDD specified does not exist!\n", __func__);
return;
}
@@ -214,7 +214,7 @@ void omap_vp_enable(struct voltagedomain *voltdm)
volt = voltdm_get_voltage(voltdm);
if (!volt) {
- pr_warning("%s: unable to find current voltage for %s\n",
+ pr_warn("%s: unable to find current voltage for %s\n",
__func__, voltdm->name);
return;
}
@@ -242,7 +242,7 @@ void omap_vp_disable(struct voltagedomain *voltdm)
int timeout;
if (!voltdm || IS_ERR(voltdm)) {
- pr_warning("%s: VDD specified does not exist!\n", __func__);
+ pr_warn("%s: VDD specified does not exist!\n", __func__);
return;
}
@@ -272,8 +272,7 @@ void omap_vp_disable(struct voltagedomain *voltdm)
VP_IDLE_TIMEOUT, timeout);
if (timeout >= VP_IDLE_TIMEOUT)
- pr_warning("%s: vdd_%s idle timedout\n",
- __func__, voltdm->name);
+ pr_warn("%s: vdd_%s idle timedout\n", __func__, voltdm->name);
vp->enabled = false;
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 00/13] sched: Integrating Per-entity-load-tracking with the core scheduler
From: Preeti U Murthy @ 2012-10-25 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351180603.12171.31.camel@twins>
Hi Peter,
Thank you very much for your feedback.
On 10/25/2012 09:26 PM, Peter Zijlstra wrote:
> OK, so I tried reading a few patches and I'm completely failing.. maybe
> its late and my brain stopped working, but it simply doesn't make any
> sense.
>
> Most changelogs and comments aren't really helping either. At best they
> mention what you're doing, not why and how. This means I get to
> basically duplicate your entire thought pattern and I might as well do
> the patches myself.
>
> I also don't see the 'big' picture of what you're doing, you start out
> by some weird avoid short running task movement.. why is that a good
> start?
>
> I would have expected a series like this to replace rq->cpu_load /
> rq->load with a saner metric and go from there.. instead it looks like
> its going about at things completely backwards. Fixing small details
> instead of the big things.
Let me see if I get what you are saying here right.You want to replace for example cfs_rq->load.weight with a saner metric because it does not consider the run time of the sched entities queued on it,merely their priorities.If this is right,in this patchset I believe cfs_rq->runnable_load_avg would be that right metric because it considers the run time of the sched entities queued on it.
So why didnt I replace? I added cfs_rq->runnable_load_avg as an additional metric instead of replacing the older metric.I let the old metric be as a dead metric and used the newer metric as an alternative.so if this alternate metric does not do us good we have the old metric to fall back on.
> At best they mention what you're doing, not why and how.
So the above explains *what* I am doing.
*How* am i doing it: Everywhere the scheduler needs to make a decision on:
a.find_busiest_group/find_idlest_group/update_sg_lb_stats:use sum of cfs_rq->runnable_load_avg to decide this instead of sum of cfs_rq->load.weight.
b.find_busiest_queue/find_idlest_queue: use cfs_rq->runnable_load_avg to decide this instead of cfs_rq->load.weight
c.move_tasks: use se->avg.load_avg_contrib to decide the weight of of each task instead of se->load.weight as the former reflects the runtime of the sched entity and hence its actual load.
This is what my patches3-13 do.Merely *Replace*.
*Why am I doing it*: Feed the load balancer with a more realistic metric to do load balancing and observe the consequences.
> you start out by some weird avoid short running task movement.
> why is that a good start?
The short running tasks are not really burdening you,they have very little run time,so why move them?
Throughout the concept of load balancing the focus is on *balancing the *existing* load* between the sched groups.But not really evaluating the *absolute load* of any given sched group.
Why is this *the start*? This is like a round of elimination before the actual interview round ;) Try to have only those sched groups as candidates for load balancing that are sufficiently loaded.[Patch1]
This *sufficiently loaded* is decided by the new metric explained in the *How* above.
> I also don't see the 'big' picture of what you're doing
Patch1: is explained above.*End result:Good candidates for lb.*
Patch2:
10%
10%
10% 100%
------ ------
SCHED_GP1 SCHED_GP2
Before Patch After Patch
-----------------------------------
SCHED_GP1 load:3072 SCHED_GP1:512
SCHED_GP2 load:1024 SCHED_GP2:1024
SCHED_GP1 is busiest SCHED_GP2 is busiest:
But Patch2 re-decides between GP1 and GP2 to check if the latency of tasks is getting affected although there is less load on GP1.If yes it is a better *busy * gp.
*End Result: Better candidates for lb*
Rest of the patches: now that we have our busy sched group,let us load balance with the aid of the new metric.
*End Result: Hopefully a more sensible movement of loads*
This is how I build the picture.
Regards
Preeti
^ permalink raw reply
* [PATCH] i2c: omap: ensure writes to dev->buf_len are ordered
From: Felipe Balbi @ 2012-10-25 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8739124idt.fsf@deeprootsystems.com>
Hi,
On Thu, Oct 25, 2012 at 09:38:06AM -0700, Kevin Hilman wrote:
> +Paul
>
> Felipe Balbi <balbi@ti.com> writes:
>
> > if we allow compiler reorder our writes, we could
> > fall into a situation where dev->buf_len is reset
> > for no apparent reason.
>
> Any chance this would help with the bug Paul found with I2C timeouts on
> beagle userspace startup?
I replied to the original thread asking the same ;-)
--
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/20121025/8550556d/attachment-0001.sig>
^ permalink raw reply
* [RFC/PATCH] mmc: omap_hsmmc: introduce omap_hsmmc_prepare/complete
From: Felipe Balbi @ 2012-10-25 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022132708.GA14033@arwen.pp.htv.fi>
Hi,
On Mon, Oct 22, 2012 at 04:27:08PM +0300, Felipe Balbi wrote:
> On Mon, Oct 22, 2012 at 03:59:28PM +0300, Felipe Balbi wrote:
> > prepare() is supposed to prevent new children from
> > being registered. On the MMC subsystem, children
> > (new cards) registration starts with the card
> > detect IRQ.
> >
> > Move card detect IRQ disabling to prepare() so that
> > no new cards will be registered while we're trying
> > to suspend.
> >
> > Likewise, move card detect IRQ enabling to complete()
> > so we only try to register new children after our MMC
> > IP is back up.
> >
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> >
> > Venkat, do you think the patch below makes sense ?
>
> btw, just checked suspend to ram with beagle and panda. We still have
> our filesystem after waking up.
>
> ps: you will [1] to test it:
>
> [1] http://marc.info/?l=linux-arm-kernel&m=135090724817604&w=2
ping
>
> > diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> > index 54bfd0c..4c8b41e 100644
> > --- a/drivers/mmc/host/omap_hsmmc.c
> > +++ b/drivers/mmc/host/omap_hsmmc.c
> > @@ -2022,6 +2022,26 @@ static int __devexit omap_hsmmc_remove(struct platform_device *pdev)
> > }
> >
> > #ifdef CONFIG_PM
> > +static int omap_hsmmc_prepare(struct device *dev)
> > +{
> > + struct omap_hsmmc_host *host = dev_get_drvdata(dev);
> > +
> > + if (host->pdata->suspend)
> > + return host->pdata->suspend(dev, host->slot_id);
> > +
> > + return 0;
> > +}
> > +
> > +static int omap_hsmmc_complete(struct device *dev)
> > +{
> > + struct omap_hsmmc_host *host = dev_get_drvdata(dev);
> > +
> > + if (host->pdata->resume)
> > + return host->pdata->resume(dev, host->slot_id);
> > +
> > + return 0;
> > +}
> > +
> > static int omap_hsmmc_suspend(struct device *dev)
> > {
> > int ret = 0;
> > @@ -2035,23 +2055,10 @@ static int omap_hsmmc_suspend(struct device *dev)
> >
> > pm_runtime_get_sync(host->dev);
> > host->suspended = 1;
> > - if (host->pdata->suspend) {
> > - ret = host->pdata->suspend(dev, host->slot_id);
> > - if (ret) {
> > - dev_dbg(dev, "Unable to handle MMC board"
> > - " level suspend\n");
> > - host->suspended = 0;
> > - return ret;
> > - }
> > - }
> > ret = mmc_suspend_host(host->mmc);
> >
> > if (ret) {
> > host->suspended = 0;
> > - if (host->pdata->resume) {
> > - if (host->pdata->resume(dev, host->slot_id))
> > - dev_dbg(dev, "Unmask interrupt failed\n");
> > - }
> > goto err;
> > }
> >
> > @@ -2088,12 +2095,6 @@ static int omap_hsmmc_resume(struct device *dev)
> > if (!(host->mmc->pm_flags & MMC_PM_KEEP_POWER))
> > omap_hsmmc_conf_bus_power(host);
> >
> > - if (host->pdata->resume) {
> > - ret = host->pdata->resume(dev, host->slot_id);
> > - if (ret)
> > - dev_dbg(dev, "Unmask interrupt failed\n");
> > - }
> > -
> > omap_hsmmc_protect_card(host);
> >
> > /* Notify the core to resume the host */
> > @@ -2109,8 +2110,10 @@ static int omap_hsmmc_resume(struct device *dev)
> > }
> >
> > #else
> > +#define omap_hsmmc_prepare NULL
> > +#define omap_hsmmc_complete NULL
> > #define omap_hsmmc_suspend NULL
> > -#define omap_hsmmc_resume NULL
> > +#define omap_hsmmc_resume NULL
> > #endif
> >
> > static int omap_hsmmc_runtime_suspend(struct device *dev)
> > @@ -2138,6 +2141,8 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
> > static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
> > .suspend = omap_hsmmc_suspend,
> > .resume = omap_hsmmc_resume,
> > + .prepare = omap_hsmmc_prepare,
> > + .complete = omap_hsmmc_complete,
> > .runtime_suspend = omap_hsmmc_runtime_suspend,
> > .runtime_resume = omap_hsmmc_runtime_resume,
> > };
> > --
> > 1.8.0.rc0
> >
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121025/58d5fb70/attachment.sig>
^ permalink raw reply
* [PATCHv2] ARM: Push selects for TWD/SCU into machine entries
From: Stephen Boyd @ 2012-10-25 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50882B6E.5020103@wwwdotorg.org>
On 10/24/12 10:54, Stephen Warren wrote:
> Where will this patch be merged?
>
> It probably won't happen for 3.8, but that config fragment will move to
> arch/arm/mach-tegra/Kconfig when Tegra enables single zImage support, I
> believe. So, it'd be good to make sure this patch gets merged somewhere
> that could be used as a baseline for other arm-soc branches if needed,
> to avoid merge conflicts.
I was hoping this could go through the arm-soc tree for the 3.8 merge
window.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 1/2] ARM: vt8500: Convert arch-vt8500 to multiplatform
From: Tony Prisk @ 2012-10-25 18:10 UTC (permalink / raw)
To: linux-arm-kernel
This patch almosts completes the conversion to ARCH_MULTI_V5
for arch-vt8500.
Both single platform and multiplatform configurations are supported
until earlyprintk support is available for multiplatform.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
Hi Olof/Arnd,
This patch needs an 'ackd' to finish off the multiplatform conversion
for vt8500. It was previously ack'd by Olof, but we had to revert to
keep the single kernel image working until multiplatform earlyprintk
is available.
arch/arm/Kconfig | 4 +++-
arch/arm/mach-vt8500/Kconfig | 12 ++++++++++++
2 files changed, 15 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-vt8500/Kconfig
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 97b40d0..2a262a8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -941,7 +941,7 @@ config ARCH_OMAP
help
Support for TI's OMAP platform (OMAP1/2/3/4).
-config ARCH_VT8500
+config ARCH_VT8500_SINGLE
bool "VIA/WonderMedia 85xx"
select ARCH_HAS_CPUFREQ
select ARCH_REQUIRE_GPIOLIB
@@ -1128,6 +1128,8 @@ source "arch/arm/mach-versatile/Kconfig"
source "arch/arm/mach-vexpress/Kconfig"
source "arch/arm/plat-versatile/Kconfig"
+source "arch/arm/mach-vt8500/Kconfig"
+
source "arch/arm/mach-w90x900/Kconfig"
# Definitions to make life easier
diff --git a/arch/arm/mach-vt8500/Kconfig b/arch/arm/mach-vt8500/Kconfig
new file mode 100644
index 0000000..2ed0b7d
--- /dev/null
+++ b/arch/arm/mach-vt8500/Kconfig
@@ -0,0 +1,12 @@
+config ARCH_VT8500
+ bool "VIA/WonderMedia 85xx" if ARCH_MULTI_V5
+ default ARCH_VT8500_SINGLE
+ select ARCH_HAS_CPUFREQ
+ select ARCH_REQUIRE_GPIOLIB
+ select CLKDEV_LOOKUP
+ select CPU_ARM926T
+ select GENERIC_CLOCKEVENTS
+ select GENERIC_GPIO
+ select HAVE_CLK
+ help
+ Support for VIA/WonderMedia VT8500/WM85xx System-on-Chip.
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 00/13] sched: Integrating Per-entity-load-tracking with the core scheduler
From: Preeti U Murthy @ 2012-10-25 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351180603.12171.31.camel@twins>
Hi Peter,
Thank you very much for your feedback.Please ignore the previous post.I
am extremely sorry about the word wrap issues with it.
On 10/25/2012 09:26 PM, Peter Zijlstra wrote:
> OK, so I tried reading a few patches and I'm completely failing.. maybe
> its late and my brain stopped working, but it simply doesn't make any
> sense.
>
> Most changelogs and comments aren't really helping either. At best they
> mention what you're doing, not why and how. This means I get to
> basically duplicate your entire thought pattern and I might as well do
> the patches myself.
>
> I also don't see the 'big' picture of what you're doing, you start out
> by some weird avoid short running task movement.. why is that a good
> start?
>
> I would have expected a series like this to replace rq->cpu_load /
> rq->load with a saner metric and go from there.. instead it looks like
> its going about at things completely backwards. Fixing small details
> instead of the big things.
>
> Do explain..
>
Let me see if I get what you are saying here right.You want to replace
for example cfs_rq->load.weight with a saner metric because it does not
consider the run time of the sched entities queued on it,merely their
priorities.If this is right,in this patchset I believe
cfs_rq->runnable_load_avg would be that right metric because it
considers the run time of the sched entities queued on it.
So why didnt I replace? I added cfs_rq->runnable_load_avg as an
additional metric instead of replacing the older metric.I let the old
metric be as a dead metric and used the newer metric as an
alternative.so if this alternate metric does not do us good we have the
old metric to fall back on.
> At best they mention what you're doing, not why and how.
So the above explains *what* I am doing.
*How* am i doing it: Everywhere the scheduler needs to make a decision on:
a.find_busiest_group/find_idlest_group/update_sg_lb_stats:use sum of
cfs_rq->runnable_load_avg to decide this instead of sum of
cfs_rq->load.weight.
b.find_busiest_queue/find_idlest_queue: use cfs_rq->runnable_load_avg
to decide this instead of cfs_rq->load.weight
c.move_tasks: use se->avg.load_avg_contrib to decide the weight of of
each task instead of se->load.weight as the former reflects the runtime
of the sched entity and hence its actual load.
This is what my patches3-13 do.Merely *Replace*.
*Why am I doing it*: Feed the load balancer with a more realistic metric
to do load balancing and observe the consequences.
> you start out by some weird avoid short running task movement.
> why is that a good start?
The short running tasks are not really burdening you,they have very
little run time,so why move them?
Throughout the concept of load balancing the focus is on *balancing the
*existing* load* between the sched groups.But not really evaluating the
*absolute load* of any given sched group.
Why is this *the start*? This is like a round of elimination before the
actual interview round Try to have only those sched groups as
candidates for load balancing that are sufficiently loaded.[Patch1]
This *sufficiently loaded* is decided by the new metric explained in the
*How* above.
> I also don't see the 'big' picture of what you're doing
Patch1: is explained above.*End result:Good candidates for lb.*
Patch2:
10%
10%
10% 100%
------ ------
SCHED_GP1 SCHED_GP2
Before Patch After Patch
-----------------------------------
SCHED_GP1 load:3072 SCHED_GP1:512
SCHED_GP2 load:1024 SCHED_GP2:1024
SCHED_GP1 is busiest SCHED_GP2 is busiest:
But Patch2 re-decides between GP1 and GP2 to check if the latency of
tasks is getting affected although there is less load on GP1.If yes it
is a better *busy * gp.
*End Result: Better candidates for lb*
Rest of the patches: now that we have our busy sched group,let us load
balance with the aid of the new metric.
*End Result: Hopefully a more sensible movement of loads*
This is how I build the picture.
Regards
Preeti U Murthy
^ permalink raw reply
* [PATCH] arm: kirkwood: add support for ZyXEL NSA310
From: Jason Cooper @ 2012-10-25 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1210251735020.15860@mirri>
Hi Tero,
Thanks for the patch!
On Thu, Oct 25, 2012 at 06:01:00PM +0300, Tero Jaasko wrote:
> Hello,
> following patch adds support for the ZyXEL NSA310 NAS box. It has been
> tested and developed in a linux-stable/linux-3.6.y tree, up to 3.6.2.
hmmm, there probably won't be any conflicts when I go to apply this, but
in the future, please base against a tag in Linus' tree. eg v3.6
> As mentioned in commit, the code is derived from the openwrt.org's
> repository. I have only done the device tree conversion.
> I have tested and used it on my NAS without trouble for a while.
> Testing of nand and adt7476 was limited to verifying that they are
> probed as I have no use for them.
>
> In order to use the kernel with stock uBoot, one needs to build with
> "make zImage modules dtbs",
> "cat arch/arm/boot/kirkwood-nsa310.dtb >> arch/arm/boot/zImage"
> "make uImage"
> sequence.
The above comments are typically added after SoB,--- and before the
diffstat.
> ---
> From f31af66eadc0df17bb75c8e5607d56ce6e2ef899 Mon Sep 17 00:00:00 2001
> From: Tero Jaasko <tero.jaasko@mail.suomi.net>
> Date: Mon, 22 Oct 2012 22:43:37 +0300
> Subject: [PATCH] arm: kirkwood: add support for ZyXEL NSA310
>
> Bring in the support for ZyXEL NSA310 NAS box. Code is mostly imported
> from the openwrt.org, (https://dev.openwrt.org/browser/trunk/target/
> linux/kirkwood/patches-3.3/202-zyxel-nsa-310.patch?rev=31673).
>
> Original code is converted to use flattened device tree descriptions
> for the support for serial uart, sata, gpio keys and gpio leds.
>
> Signed-off-by: Tero Jaasko <tero.jaasko@mail.suomi.net>
> ---
> arch/arm/boot/dts/kirkwood-nsa310.dts | 96 ++++++++++++++++++++
> arch/arm/mach-kirkwood/Kconfig | 9 ++
> arch/arm/mach-kirkwood/Makefile | 1 +
> arch/arm/mach-kirkwood/Makefile.boot | 1 +
> arch/arm/mach-kirkwood/board-dt.c | 4 +
> arch/arm/mach-kirkwood/board-nsa310.c | 166 ++++++++++++++++++++++++++++++++++
> arch/arm/mach-kirkwood/common.h | 6 ++
> 7 files changed, 283 insertions(+)
> create mode 100644 arch/arm/boot/dts/kirkwood-nsa310.dts
> create mode 100644 arch/arm/mach-kirkwood/board-nsa310.c
>
> diff --git a/arch/arm/boot/dts/kirkwood-nsa310.dts b/arch/arm/boot/dts/kirkwood-nsa310.dts
> new file mode 100644
> index 0000000..554d81a
> --- /dev/null
> +++ b/arch/arm/boot/dts/kirkwood-nsa310.dts
> @@ -0,0 +1,96 @@
> +/dts-v1/;
> +
> +/include/ "kirkwood.dtsi"
> +
> +/ {
> + model = "ZyXEL NSA310";
> + compatible = "zyxel,nsa310", "marvell,kirkwood-88f6281", "marvell,kirkwood";
Is there only one variant of the nsa310? eg did they change flash types
or ram size during a production run? Whether they did or not, we prefer
to be as specific as possible here, eg "zyxel,nsa310-PRODNUM" If you can
locate a PRODNUM that will most likely change if they change the BOM,
etc. Please add this string in addition to what you currently have.
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x10000000>;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + };
> +
> + ocp at f1000000 {
> + serial at 12000 {
> + clock-frequency = <200000000>;
> + status = "ok";
> + };
> +
> + sata at 80000 {
> + status = "okay";
> + nr-ports = <2>;
> + };
> + };
> +
> + gpio_keys {
> + compatible = "gpio-keys";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + button at 1 {
> + label = "Power Button";
> + linux,code = <116>;
> + gpios = <&gpio1 14 0>;
> + };
> + button at 2 {
> + label = "Copy Button";
> + linux,code = <133>;
> + gpios = <&gpio1 5 1>;
> + };
> + button at 3 {
> + label = "Reset Button";
> + linux,code = <0x198>;
> + gpios = <&gpio1 4 1>;
> + };
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + green-sys {
> + label = "nsa310:green:sys";
> + gpios = <&gpio0 28 0>;
> + };
> + red-sys {
> + label = "nsa310:red:sys";
> + gpios = <&gpio0 29 0>;
> + };
> + green-hdd {
> + label = "nsa310:green:hdd";
> + gpios = <&gpio1 9 0>;
> + };
> + red-hdd {
> + label = "nsa310:red:hdd";
> + gpios = <&gpio1 10 0>;
> + };
> + green-esata {
> + label = "nsa310:green:esata";
> + gpios = <&gpio0 12 0>;
> + };
> + red-esata {
> + label = "nsa310:red:esata";
> + gpios = <&gpio0 13 0>;
> + };
> + green-usb {
> + label = "nsa310:green:usb";
> + gpios = <&gpio0 15 0>;
> + };
> + red-usb {
> + label = "nsa310:red:usb";
> + gpios = <&gpio0 16 0>;
> + };
> + green-copy {
> + label = "nsa310:green:copy";
> + gpios = <&gpio1 7 0>;
> + };
> + red-copy {
> + label = "nsa310:red:copy";
> + gpios = <&gpio1 8 0>;
> + };
> + };
> +};
> diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
> index ca5c15a..1172a2a 100644
> --- a/arch/arm/mach-kirkwood/Kconfig
> +++ b/arch/arm/mach-kirkwood/Kconfig
> @@ -195,6 +195,15 @@ config MACH_T5325
> Say 'Y' here if you want your kernel to support the
> HP t5325 Thin Client.
>
> +config MACH_NSA310_DT
> + bool "ZyXEL NSA-310 (Flattened Device Tree)"
> + select ARCH_KIRKWOOD_DT
> + select ARM_APPENDED_DTB
> + select ARM_ATAG_DTB_COMPAT
I would prefer not to enable APPENDED_DTB by default.
> + help
> + Say 'Y' here if you want your kernel to support the
> + ZyXEL NSA-310 board (Flattened Device Tree).
> +
> endmenu
>
> endif
> diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
> index 055c85a..b2663e2 100644
> --- a/arch/arm/mach-kirkwood/Makefile
> +++ b/arch/arm/mach-kirkwood/Makefile
> @@ -28,3 +28,4 @@ obj-$(CONFIG_MACH_IB62X0_DT) += board-ib62x0.o
> obj-$(CONFIG_MACH_TS219_DT) += board-ts219.o tsx1x-common.o
> obj-$(CONFIG_MACH_GOFLEXNET_DT) += board-goflexnet.o
> obj-$(CONFIG_MACH_LSXL_DT) += board-lsxl.o
> +obj-$(CONFIG_MACH_NSA310_DT) += board-nsa310.o
> diff --git a/arch/arm/mach-kirkwood/Makefile.boot b/arch/arm/mach-kirkwood/Makefile.boot
> index a13299d..67d8666 100644
> --- a/arch/arm/mach-kirkwood/Makefile.boot
> +++ b/arch/arm/mach-kirkwood/Makefile.boot
> @@ -12,3 +12,4 @@ dtb-$(CONFIG_MACH_TS219_DT) += kirkwood-ts219-6282.dtb
> dtb-$(CONFIG_MACH_GOFLEXNET_DT) += kirkwood-goflexnet.dtb
> dtb-$(CONFIG_MACH_LSXL_DT) += kirkwood-lschlv2.dtb
> dtb-$(CONFIG_MACH_LSXL_DT) += kirkwood-lsxhl.dtb
> +dtb-$(CONFIG_MACH_NSA310_DT) += kirkwood-nsa310.dtb
> diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
> index e4eb450..2a005a7 100644
> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -87,6 +87,9 @@ static void __init kirkwood_dt_init(void)
> if (of_machine_is_compatible("buffalo,lsxl"))
> lsxl_init();
>
> + if (of_machine_is_compatible("zyxel,nsa310"))
> + nsa310_init();
> +
> of_platform_populate(NULL, kirkwood_dt_match_table,
> kirkwood_auxdata_lookup, NULL);
> }
> @@ -100,6 +103,7 @@ static const char *kirkwood_dt_board_compat[] = {
> "qnap,ts219",
> "seagate,goflexnet",
> "buffalo,lsxl",
> + "zyxel,nsa310",
> NULL
> };
>
> diff --git a/arch/arm/mach-kirkwood/board-nsa310.c b/arch/arm/mach-kirkwood/board-nsa310.c
> new file mode 100644
> index 0000000..4d20841
> --- /dev/null
> +++ b/arch/arm/mach-kirkwood/board-nsa310.c
> @@ -0,0 +1,166 @@
> +/*
> + * arch/arm/mach-kirkwood/board-nsa310.c
> + *
> + * ZyXEL NSA-310 Setup
Copyright?
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/i2c.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/mtd/partitions.h>
> +#include <linux/gpio.h>
> +
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <mach/kirkwood.h>
> +#include "common.h"
> +#include "mpp.h"
> +
> +#define NSA310_GPIO_LED_ESATA_GREEN 12
> +#define NSA310_GPIO_LED_ESATA_RED 13
> +#define NSA310_GPIO_LED_USB_GREEN 15
> +#define NSA310_GPIO_LED_USB_RED 16
> +#define NSA310_GPIO_USB_POWER_OFF 21
> +#define NSA310_GPIO_LED_SYS_GREEN 28
> +#define NSA310_GPIO_LED_SYS_RED 29
> +#define NSA310_GPIO_KEY_RESTART 36
> +#define NSA310_GPIO_KEY_COPY 37
> +#define NSA310_GPIO_LED_COPY_GREEN 39
> +#define NSA310_GPIO_LED_COPY_RED 40
> +#define NSA310_GPIO_LED_HDD_GREEN 41
> +#define NSA310_GPIO_LED_HDD_RED 42
> +#define NSA310_GPIO_BUZZER 44
> +#define NSA310_GPIO_KEY_POWER 46
> +#define NSA310_GPIO_POWER_OFF 48
Please remove any of the above #define's that aren't used.
> +
> +
> +static unsigned int nsa310_mpp_config[] __initdata = {
> + MPP12_GPIO, /* led esata green */
> + MPP13_GPIO, /* led esata red */
> + MPP15_GPIO, /* led usb green */
> + MPP16_GPIO, /* led usb red */
> + MPP21_GPIO, /* control usb power off */
> + MPP28_GPIO, /* led sys green */
> + MPP29_GPIO, /* led sys red */
> + MPP36_GPIO, /* key reset */
> + MPP37_GPIO, /* key copy */
> + MPP39_GPIO, /* led copy green */
> + MPP40_GPIO, /* led copy red */
> + MPP41_GPIO, /* led hdd green */
> + MPP42_GPIO, /* led hdd red */
> + MPP44_GPIO, /* ?? */
> + MPP46_GPIO, /* key power */
> + MPP48_GPIO, /* control power off */
> + 0
> +};
There is a patch series to convert all kirkwood DT boards over to DT
init of MPP is under review currently. If things go well, I'd like to
see this use it as well.
> +
> +static struct mtd_partition nsa310_mtd_parts[] = {
> + {
> + .name = "uboot",
> + .offset = 0,
> + .size = 0x100000,
> + .mask_flags = MTD_WRITEABLE,
> + }, {
> + .name = "uboot_env",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0x80000,
> + }, {
> + .name = "key_store",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0x80000,
> + }, {
> + .name = "info",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0x80000,
> + }, {
> + .name = "etc",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0xa00000,
> + }, {
> + .name = "kernel_1",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0xa00000,
> + }, {
> + .name = "rootfs1",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0x2fc0000,
> + }, {
> + .name = "kernel_2",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0xa00000,
> + }, {
> + .name = "rootfs2",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0x2fc0000,
> + },
> +};
Please move the above partition definitions into the dts file, you can
then remove all of the nand init and relevant includes.
> +
> +static struct i2c_board_info __initdata nsa310_i2c_info[] = {
> + { I2C_BOARD_INFO("adt7476", 0x2e) },
> +};
how far off from the adt7461 (lm90) is this? If similar, please
consider extending lm90's compatibility list and describing this in the
dts instead.
> +
> +static void nsa310_power_off(void)
> +{
> + gpio_set_value(NSA310_GPIO_POWER_OFF, 1);
> +}
> +
> +static int __init nsa310_gpio_request(unsigned int gpio, unsigned long flags,
> + const char *label)
> +{
> + int err;
> +
> + err = gpio_request_one(gpio, flags, label);
> + if (err)
> + pr_err("NSA-310: can't setup GPIO%u (%s), err=%d\n",
> + gpio, label, err);
> +
> + return err;
> +}
> +
> +static void __init nsa310_gpio_init(void)
> +{
> + int err;
> +
> + err = nsa310_gpio_request(NSA310_GPIO_POWER_OFF, GPIOF_OUT_INIT_LOW,
> + "Power Off");
> + if (!err)
> + pm_power_off = nsa310_power_off;
This doesn't smell right.
> +
> + nsa310_gpio_request(NSA310_GPIO_USB_POWER_OFF, GPIOF_OUT_INIT_LOW,
> + "USB Power Off");
> +}
> +
> +void __init nsa310_init(void)
> +{
> + u32 dev, rev;
> +
> + kirkwood_mpp_conf(nsa310_mpp_config);
> +
> + nsa310_gpio_init();
> +
> + kirkwood_nand_init(ARRAY_AND_SIZE(nsa310_mtd_parts), 35);
> +
> + /* this can be removed once the mainline kirkwood.dtsi gets
> + * the ehci configuration by default */
> + kirkwood_ehci_init();
> +
> + kirkwood_pcie_id(&dev, &rev);
Does this board actually use pcie? If so, we've been looking for one to
test on. Just an fyi, we'll probably be hitting you up later for pcie
DT binding testing. ;-)
thx,
Jason.
> +
> + i2c_register_board_info(0, ARRAY_AND_SIZE(nsa310_i2c_info));
> + kirkwood_i2c_init();
> +}
> +
> +static int __init nsa310_pci_init(void)
> +{
> + if (of_machine_is_compatible("zyxel,nsa310"))
> + kirkwood_pcie_init(KW_PCIE0);
> +
> + return 0;
> +}
> +
> +subsys_initcall(nsa310_pci_init);
> diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
> index 304dd1a..a9256d7 100644
> --- a/arch/arm/mach-kirkwood/common.h
> +++ b/arch/arm/mach-kirkwood/common.h
> @@ -94,6 +94,12 @@ void lsxl_init(void);
> static inline void lsxl_init(void) {};
> #endif
>
> +#ifdef CONFIG_MACH_NSA310_DT
> +void nsa310_init(void);
> +#else
> +static inline void nsa310_init(void) {};
> +#endif
> +
> /* early init functions not converted to fdt yet */
> char *kirkwood_id(void);
> void kirkwood_l2_init(void);
> --
> 1.7.12.3
>
^ permalink raw reply
* [PATCH] arm: kirkwood: add support for ZyXEL NSA310
From: Andrew Lunn @ 2012-10-25 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1210251735020.15860@mirri>
Hi Tero
On Thu, Oct 25, 2012 at 06:01:00PM +0300, Tero Jaasko wrote:
> +#define NSA310_GPIO_LED_ESATA_GREEN 12
> +#define NSA310_GPIO_LED_ESATA_RED 13
> +#define NSA310_GPIO_LED_USB_GREEN 15
> +#define NSA310_GPIO_LED_USB_RED 16
> +#define NSA310_GPIO_USB_POWER_OFF 21
> +#define NSA310_GPIO_LED_SYS_GREEN 28
> +#define NSA310_GPIO_LED_SYS_RED 29
> +#define NSA310_GPIO_KEY_RESTART 36
> +#define NSA310_GPIO_KEY_COPY 37
> +#define NSA310_GPIO_LED_COPY_GREEN 39
> +#define NSA310_GPIO_LED_COPY_RED 40
> +#define NSA310_GPIO_LED_HDD_GREEN 41
> +#define NSA310_GPIO_LED_HDD_RED 42
> +#define NSA310_GPIO_BUZZER 44
> +#define NSA310_GPIO_KEY_POWER 46
> +#define NSA310_GPIO_POWER_OFF 48
It looks like most of these are not used. Please remove them.
> +static struct mtd_partition nsa310_mtd_parts[] = {
> + {
> + .name = "uboot",
> + .offset = 0,
> + .size = 0x100000,
> + .mask_flags = MTD_WRITEABLE,
> + }, {
> + .name = "uboot_env",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0x80000,
> + }, {
> + .name = "key_store",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0x80000,
> + }, {
> + .name = "info",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0x80000,
> + }, {
> + .name = "etc",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0xa00000,
> + }, {
> + .name = "kernel_1",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0xa00000,
> + }, {
> + .name = "rootfs1",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0x2fc0000,
> + }, {
> + .name = "kernel_2",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0xa00000,
> + }, {
> + .name = "rootfs2",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = 0x2fc0000,
> + },
> +};
You should be able to put all that into DT. Take a look at
arch/arm/boot/dts/kirkwood-goflexnet.dts for example.
> +
> +static struct i2c_board_info __initdata nsa310_i2c_info[] = {
> + { I2C_BOARD_INFO("adt7476", 0x2e) },
> +};
You can also do this in DT as well. kirkwood-ts219.dtsi has
i2c at 11000 {
status = "okay";
clock-frequency = <400000>;
s35390a: s35390a at 30 {
compatible = "s35390a";
reg = <0x30>;
};
Thanks
Andrew
^ permalink raw reply
* [PATCH V2] ARM: OMAP2+: PM: VP: minor pr_warn updates
From: Nishanth Menon @ 2012-10-25 18:37 UTC (permalink / raw)
To: linux-arm-kernel
change pr_warnings to pr_warn and ensure a newline
is present in all messages
Cc: linux-omap at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Nishanth Menon <nm@ti.com>
---
V2: minor checkpatch alignment warning fix
and linux-omap in cc this time! apologies on the spam!
V1: https://patchwork.kernel.org/patch/1646261/
arch/arm/mach-omap2/vp.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index 85241b8..6e9fe85 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -138,7 +138,7 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
udelay(1);
}
if (timeout >= VP_TRANXDONE_TIMEOUT) {
- pr_warn("%s: vdd_%s TRANXDONE timeout exceeded. Voltage change aborted",
+ pr_warn("%s: vdd_%s TRANXDONE timeout exceeded. Voltage change aborted\n",
__func__, voltdm->name);
return -ETIMEDOUT;
}
@@ -197,7 +197,7 @@ void omap_vp_enable(struct voltagedomain *voltdm)
u32 vpconfig, volt;
if (!voltdm || IS_ERR(voltdm)) {
- pr_warning("%s: VDD specified does not exist!\n", __func__);
+ pr_warn("%s: VDD specified does not exist!\n", __func__);
return;
}
@@ -214,8 +214,8 @@ void omap_vp_enable(struct voltagedomain *voltdm)
volt = voltdm_get_voltage(voltdm);
if (!volt) {
- pr_warning("%s: unable to find current voltage for %s\n",
- __func__, voltdm->name);
+ pr_warn("%s: unable to find current voltage for %s\n",
+ __func__, voltdm->name);
return;
}
@@ -242,7 +242,7 @@ void omap_vp_disable(struct voltagedomain *voltdm)
int timeout;
if (!voltdm || IS_ERR(voltdm)) {
- pr_warning("%s: VDD specified does not exist!\n", __func__);
+ pr_warn("%s: VDD specified does not exist!\n", __func__);
return;
}
@@ -272,8 +272,7 @@ void omap_vp_disable(struct voltagedomain *voltdm)
VP_IDLE_TIMEOUT, timeout);
if (timeout >= VP_IDLE_TIMEOUT)
- pr_warning("%s: vdd_%s idle timedout\n",
- __func__, voltdm->name);
+ pr_warn("%s: vdd_%s idle timedout\n", __func__, voltdm->name);
vp->enabled = false;
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 1/5] ARM: dts: OMAP: Add timer nodes
From: Jon Hunter @ 2012-10-25 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB4AB13@DBDE01.ent.ti.com>
On 10/25/2012 10:27 AM, Hiremath, Vaibhav wrote:
...
> Can you merge it to your test module? I am thinking of pushing application
> to github for others to use. I believe you are ok with this. I am planning
> to push all the application there.
>
> https://github.com/hvaibhav/sample-applications
Thanks. I have been meaning to do this. I have pushed my latest version
here [1]. Should include the AM335x fix too. Let me know if this is
working for you.
Cheers
Jon
[1] https://github.com/jonhunter/omap-test
^ permalink raw reply
* [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
From: Paul Walmsley @ 2012-10-25 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025153805.GB11623@blackmetal.musicnaut.iki.fi>
Terve,
On Thu, 25 Oct 2012, Aaro Koskinen wrote:
> On Mon, Oct 15, 2012 at 07:32:33PM -0600, Paul Walmsley wrote:
> > The OMAP watchdog timer driver directly calls a function exported by
> > code in arch/arm/mach-omap2. This is not good; it tightly couples
> > this driver to the mach-omap2 integration code. Instead, add a
> > temporary platform_data function pointer to abstract this function
> > call. A subsequent patch will convert the watchdog driver to use this
> > function pointer.
>
> Why a function is needed? Reset cause won't change until the next reset,
> so it should be enough to read it once during the init and store it into
> the platform data.
Once the PRM/CM drivers and DT conversion is complete, this driver won't
have any platform_data. There won't be any watchdog driver initialization
code in arch/arm/mach-omap2. At that point in time, the driver will just
call a function from the PRM driver that provides the reset source data.
As you say, the watchdog can certainly do this from its probe code; it
would be more efficient. Just didn't want to make that change now; seems
like it would be best done as a separate optimization patch.
- Paul
^ permalink raw reply
* [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
From: Tony Lindgren @ 2012-10-25 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210251846130.21193@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121025 11:53]:
> Terve,
>
> On Thu, 25 Oct 2012, Aaro Koskinen wrote:
>
> > On Mon, Oct 15, 2012 at 07:32:33PM -0600, Paul Walmsley wrote:
> > > The OMAP watchdog timer driver directly calls a function exported by
> > > code in arch/arm/mach-omap2. This is not good; it tightly couples
> > > this driver to the mach-omap2 integration code. Instead, add a
> > > temporary platform_data function pointer to abstract this function
> > > call. A subsequent patch will convert the watchdog driver to use this
> > > function pointer.
> >
> > Why a function is needed? Reset cause won't change until the next reset,
> > so it should be enough to read it once during the init and store it into
> > the platform data.
>
> Once the PRM/CM drivers and DT conversion is complete, this driver won't
> have any platform_data. There won't be any watchdog driver initialization
> code in arch/arm/mach-omap2. At that point in time, the driver will just
> call a function from the PRM driver that provides the reset source data.
>
> As you say, the watchdog can certainly do this from its probe code; it
> would be more efficient. Just didn't want to make that change now; seems
> like it would be best done as a separate optimization patch.
Ideally we'd have some Linux generic function to implement in the PRM/CM
drivers for getting the bootreason. But I guess we don't?
Regards,
Tony
^ permalink raw reply
* [PATCH 08/16] ARM: OMAP2: Move plat/menelaus.h to linux/mfd/menelaus.h
From: Tony Lindgren @ 2012-10-25 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025111158.GA5297@sortiz-mobl>
* Samuel Ortiz <sameo@linux.intel.com> [121025 04:14]:
> Hi Tony,
>
> On Thu, Oct 04, 2012 at 03:04:52PM -0700, Tony Lindgren wrote:
> > We can move menelaus.h to live with other mfd headers to
> > get it out of plat for ARM common zImage support.
> >
> > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Thanks, I've now pushed a branch with this patch only
to omap-for-v3.8/cleanup-headers-menelaus branch in case
you need to merge it in too.
Regards,
Tony
^ 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