* [PATCH 1/5] ARM: OMAP5: Fix build for PM code
From: Tony Lindgren @ 2016-10-26 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026151703.24730-1-tony@atomide.com>
It's CONFIG_SOC_OMAP5, not CONFIG_ARCH_OMAP5. Looks like make randconfig
builds have not hit this one yet.
Fixes: b3bf289c1c45 ("ARM: OMAP2+: Fix build with CONFIG_SMP and CONFIG_PM
is not set")
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -80,7 +80,7 @@ endif
# Power Management
omap-4-5-pm-common = omap-mpuss-lowpower.o
obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-pm-common)
-obj-$(CONFIG_ARCH_OMAP5) += $(omap-4-5-pm-common)
+obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-pm-common)
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
ifeq ($(CONFIG_PM),y)
--
2.9.3
^ permalink raw reply
* [PATCH 2/5] ARM: OMAP5: Fix mpuss_early_init
From: Tony Lindgren @ 2016-10-26 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026151703.24730-1-tony@atomide.com>
We need to properly initialize mpuss also on omap5 like we do on omap4.
Otherwise we run into similar kexec problems like we had on omap4 when
trying to kexec from a kernel with PM initialized.
Fixes: 0573b957fc21 ("ARM: OMAP4+: Prevent CPU1 related hang with kexec")
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/io.c | 3 ++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 28 +++++++++++++++++++++-------
arch/arm/mach-omap2/omap4-sar-layout.h | 2 ++
3 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -717,10 +717,11 @@ void __init omap5_init_early(void)
OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
omap2_control_base_init();
- omap4_pm_init_early();
omap2_prcm_base_init();
omap5xxx_check_revision();
omap4_sar_ram_init();
+ omap4_mpuss_early_init();
+ omap4_pm_init_early();
omap54xx_voltagedomains_init();
omap54xx_powerdomains_init();
omap54xx_clockdomains_init();
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -371,8 +371,12 @@ int __init omap4_mpuss_init(void)
pm_info = &per_cpu(omap4_pm_info, 0x0);
if (sar_base) {
pm_info->scu_sar_addr = sar_base + SCU_OFFSET0;
- pm_info->wkup_sar_addr = sar_base +
- CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ if (cpu_is_omap44xx())
+ pm_info->wkup_sar_addr = sar_base +
+ CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ else
+ pm_info->wkup_sar_addr = sar_base +
+ OMAP5_CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
}
pm_info->pwrdm = pwrdm_lookup("cpu0_pwrdm");
@@ -391,8 +395,12 @@ int __init omap4_mpuss_init(void)
pm_info = &per_cpu(omap4_pm_info, 0x1);
if (sar_base) {
pm_info->scu_sar_addr = sar_base + SCU_OFFSET1;
- pm_info->wkup_sar_addr = sar_base +
- CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ if (cpu_is_omap44xx())
+ pm_info->wkup_sar_addr = sar_base +
+ CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ else
+ pm_info->wkup_sar_addr = sar_base +
+ OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
}
@@ -453,15 +461,21 @@ void __init omap4_mpuss_early_init(void)
{
unsigned long startup_pa;
- if (!cpu_is_omap44xx())
+ if (!(cpu_is_omap44xx() || soc_is_omap54xx()))
return;
sar_base = omap4_get_sar_ram_base();
if (cpu_is_omap443x())
startup_pa = virt_to_phys(omap4_secondary_startup);
- else
+ else if (cpu_is_omap446x())
startup_pa = virt_to_phys(omap4460_secondary_startup);
+ else
+ startup_pa = virt_to_phys(omap5_secondary_startup);
- writel_relaxed(startup_pa, sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET);
+ if (cpu_is_omap44xx())
+ writel_relaxed(startup_pa, sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET);
+ else
+ writel_relaxed(startup_pa, sar_base +
+ OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET);
}
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h b/arch/arm/mach-omap2/omap4-sar-layout.h
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -31,6 +31,8 @@
/* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
#define CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xa04
#define CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xa08
+#define OMAP5_CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xe00
+#define OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xe04
#define SAR_BACKUP_STATUS_OFFSET (SAR_BANK3_OFFSET + 0x500)
#define SAR_SECURE_RAM_SIZE_OFFSET (SAR_BANK3_OFFSET + 0x504)
--
2.9.3
^ permalink raw reply
* [PATCH 3/5] ARM: OMAP4+: Fix bad fallthrough for cpuidle
From: Tony Lindgren @ 2016-10-26 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026151703.24730-1-tony@atomide.com>
We don't want to fall through to a bunch of errors for retention
if PM_OMAP4_CPU_OSWR_DISABLE is not configured for a SoC.
Fixes: 6099dd37c669 ("ARM: OMAP5 / DRA7: Enable CPU RET on suspend")
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -244,10 +244,9 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)
save_state = 1;
break;
case PWRDM_POWER_RET:
- if (IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE)) {
+ if (IS_PM44XX_ERRATUM(PM_OMAP4_CPU_OSWR_DISABLE))
save_state = 0;
- break;
- }
+ break;
default:
/*
* CPUx CSWR is invalid hardware state. Also CPUx OSWR
--
2.9.3
^ permalink raw reply
* [PATCH 4/5] ARM: DRA7: PM: cpuidle MPU CSWR support
From: Tony Lindgren @ 2016-10-26 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026151703.24730-1-tony@atomide.com>
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Add DRA74/72 CPUIDLE support.
This patch adds MPUSS low power states in cpuidle.
C1 - CPU0 WFI + CPU1 WFI + MPU ON
C2 - CPU0 RET + CPU1 RET + MPU CSWR
Tested on DRA74/72-EVM for C1 and C2 states.
NOTE: DRA7 does not do voltage scaling as part of retention transition
and has Mercury which speeds up transition paths - Latency numbers are
based on measurements done by toggling GPIOs.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[ j-keerthy at ti.com rework on 3.14]
Signed-off-by: Keerthy <j-keerthy@ti.com>
[nm at ti.com: updates based on profiling]
[tony at atomide.com: dropped CPUIDLE_FLAG_TIME_VALID no longer used]
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/cpuidle44xx.c | 80 ++++++++++++++++++++++++++++++++++++++-
arch/arm/mach-omap2/pm44xx.c | 2 +-
2 files changed, 80 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -21,6 +21,7 @@
#include "common.h"
#include "pm.h"
#include "prm.h"
+#include "soc.h"
#include "clockdomain.h"
#define MAX_CPUS 2
@@ -30,6 +31,7 @@ struct idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
+ u32 mpu_state_vote;
};
static struct idle_statedata omap4_idle_data[] = {
@@ -50,12 +52,26 @@ static struct idle_statedata omap4_idle_data[] = {
},
};
+static struct idle_statedata dra7_idle_data[] = {
+ {
+ .cpu_state = PWRDM_POWER_ON,
+ .mpu_state = PWRDM_POWER_ON,
+ .mpu_logic_state = PWRDM_POWER_ON,
+ },
+ {
+ .cpu_state = PWRDM_POWER_RET,
+ .mpu_state = PWRDM_POWER_RET,
+ .mpu_logic_state = PWRDM_POWER_RET,
+ },
+};
+
static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
static struct clockdomain *cpu_clkdm[MAX_CPUS];
static atomic_t abort_barrier;
static bool cpu_done[MAX_CPUS];
static struct idle_statedata *state_ptr = &omap4_idle_data[0];
+static DEFINE_RAW_SPINLOCK(mpu_lock);
/* Private functions */
@@ -77,6 +93,32 @@ static int omap_enter_idle_simple(struct cpuidle_device *dev,
return index;
}
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct idle_statedata *cx = state_ptr + index;
+ unsigned long flag;
+
+ raw_spin_lock_irqsave(&mpu_lock, flag);
+ cx->mpu_state_vote++;
+ if (cx->mpu_state_vote == num_online_cpus()) {
+ pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
+ }
+ raw_spin_unlock_irqrestore(&mpu_lock, flag);
+
+ omap4_enter_lowpower(dev->cpu, cx->cpu_state);
+
+ raw_spin_lock_irqsave(&mpu_lock, flag);
+ if (cx->mpu_state_vote == num_online_cpus())
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+ cx->mpu_state_vote--;
+ raw_spin_unlock_irqrestore(&mpu_lock, flag);
+
+ return index;
+}
+
static int omap_enter_idle_coupled(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -220,6 +262,32 @@ static struct cpuidle_driver omap4_idle_driver = {
.safe_state_index = 0,
};
+static struct cpuidle_driver dra7_idle_driver = {
+ .name = "dra7_idle",
+ .owner = THIS_MODULE,
+ .states = {
+ {
+ /* C1 - CPU0 ON + CPU1 ON + MPU ON */
+ .exit_latency = 2 + 2,
+ .target_residency = 5,
+ .enter = omap_enter_idle_simple,
+ .name = "C1",
+ .desc = "CPUx WFI, MPUSS ON"
+ },
+ {
+ /* C2 - CPU0 RET + CPU1 RET + MPU CSWR */
+ .exit_latency = 48 + 60,
+ .target_residency = 100,
+ .flags = CPUIDLE_FLAG_TIMER_STOP,
+ .enter = omap_enter_idle_smp,
+ .name = "C2",
+ .desc = "CPUx CSWR, MPUSS CSWR",
+ },
+ },
+ .state_count = ARRAY_SIZE(dra7_idle_data),
+ .safe_state_index = 0,
+};
+
/* Public functions */
/**
@@ -230,6 +298,16 @@ static struct cpuidle_driver omap4_idle_driver = {
*/
int __init omap4_idle_init(void)
{
+ struct cpuidle_driver *idle_driver;
+
+ if (soc_is_dra7xx()) {
+ state_ptr = &dra7_idle_data[0];
+ idle_driver = &dra7_idle_driver;
+ } else {
+ state_ptr = &omap4_idle_data[0];
+ idle_driver = &omap4_idle_driver;
+ }
+
mpu_pd = pwrdm_lookup("mpu_pwrdm");
cpu_pd[0] = pwrdm_lookup("cpu0_pwrdm");
cpu_pd[1] = pwrdm_lookup("cpu1_pwrdm");
@@ -244,5 +322,5 @@ int __init omap4_idle_init(void)
/* Configure the broadcast timer on each cpu */
on_each_cpu(omap_setup_broadcast_timer, NULL, 1);
- return cpuidle_register(&omap4_idle_driver, cpu_online_mask);
+ return cpuidle_register(idle_driver, cpu_online_mask);
}
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -287,7 +287,7 @@ int __init omap4_pm_init(void)
/* Overwrite the default cpu_do_idle() */
arm_pm_idle = omap_default_idle;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx() || soc_is_dra7xx())
omap4_idle_init();
err2:
--
2.9.3
^ permalink raw reply
* [PATCH 5/5] ARM: OMAP5: Enable minimal cpuidle for omap5 retention
From: Tony Lindgren @ 2016-10-26 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026151703.24730-1-tony@atomide.com>
This allows the CPUs to enter retention during idle and takes the idle
power consumption down quite a bit. On omap5-uevm, the power consumption
eventually settles down to about 920mW with ehci-omap and ohci-omap3
unloaded compared to about 1.7W without these patches. Note that it
seems to take few minutes after booting for the idle power to go down
to 920mW from 1.3W, no idea so far what might be causing that.
Note that the TI kernel supports more modes in the v3.8 kernel, but
the omap5 specific states can be added later.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/cpuidle44xx.c | 2 +-
arch/arm/mach-omap2/pm44xx.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -300,7 +300,7 @@ int __init omap4_idle_init(void)
{
struct cpuidle_driver *idle_driver;
- if (soc_is_dra7xx()) {
+ if (soc_is_dra7xx() || soc_is_omap54xx()) {
state_ptr = &dra7_idle_data[0];
idle_driver = &dra7_idle_driver;
} else {
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -287,7 +287,7 @@ int __init omap4_pm_init(void)
/* Overwrite the default cpu_do_idle() */
arm_pm_idle = omap_default_idle;
- if (cpu_is_omap44xx() || soc_is_dra7xx())
+ if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx())
omap4_idle_init();
err2:
--
2.9.3
^ permalink raw reply
* [PATCH 3/4] mfd: altr-a10sr: Add Arria10 SR Monitor
From: Thor Thayer @ 2016-10-26 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026125233.GL11267@dell>
On 10/26/2016 07:52 AM, Lee Jones wrote:
> On Thu, 13 Oct 2016, tthayer at opensource.altera.com wrote:
>
>> From: Thor Thayer <tthayer@opensource.altera.com>
>>
>> Add the Altera Arria10 DevKit System Resource Monitor functionality
>> to the MFD device.
>>
>> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
>> ---
>> drivers/mfd/altera-a10sr.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/mfd/altera-a10sr.c b/drivers/mfd/altera-a10sr.c
>> index 06e1f7f..0942d7d 100644
>> --- a/drivers/mfd/altera-a10sr.c
>> +++ b/drivers/mfd/altera-a10sr.c
>> @@ -33,6 +33,10 @@
>> .name = "altr_a10sr_gpio",
>> .of_compatible = "altr,a10sr-gpio",
>> },
>> + {
>> + .name = "altr_a10sr_mon",
>> + .of_compatible = "altr,a10sr-mon",
>
> "-monitor" would be better in my opinion.
>
OK. I'm flexible and it is clearer. I'll make the changes and resubmit.
Thanks for reviewing!
>> + },
>> };
>>
>> static bool altr_a10sr_reg_readable(struct device *dev, unsigned int reg)
>
^ permalink raw reply
* [PATCH v3] drivers: psci: PSCI checker module
From: Paul E. McKenney @ 2016-10-26 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026131752.GA15478@red-moon>
On Wed, Oct 26, 2016 at 02:17:52PM +0100, Lorenzo Pieralisi wrote:
> On Tue, Oct 25, 2016 at 11:34:36AM -0700, Paul E. McKenney wrote:
>
> [...]
>
> > > > +static int __init psci_checker(void)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + /*
> > > > + * Since we're in an initcall, we assume that all the CPUs that all
> > > > + * CPUs that can be onlined have been onlined.
> > > > + *
> > > > + * The tests assume that hotplug is enabled but nobody else is using it,
> > > > + * otherwise the results will be unpredictable. However, since there
> > > > + * is no userspace yet in initcalls, that should be fine.
> > >
> > > I do not think it is. If you run a kernel with, say,
> > > CONFIG_LOCK_TORTURE_TEST, cpus may disappear from the radar while
> > > running the PSCI checker test itself; that at least would confuse the
> > > checker, and that's just an example.
> > >
> > > I added Paul to check what are the assumptions behind the torture test
> > > hotplug tests, in particular if there are any implicit assumptions for
> > > it to work (ie it is the only kernel test hotplugging cpus in and out
> > > (?)), what I know is that the PSCI checker assumptions are not correct.
> >
> > Both CONFIG_LOCK_TORTURE_TEST and CONFIG_RCU_TORTURE_TEST can and will
> > hotplug CPUs. The locktorture.onoff_holdoff and rcutorture.onoff_holdoff
> > kernel parameters can delay the start of CPU-hotplug testing, and in
> > my testing I set this delay to 30 seconds after boot.
> >
> > One approach would be to make your test refuse to run if either of
> > the lock/RCU torture tests was running. Or do what Lorenzo suggests
> > below. The torture tests aren't crazy enough to offline the last CPU.
> > Though they do try, just for effect, in cases where the last CPU is
> > marked cpu_is_hotpluggable(). ;-)
>
> Thank you Paul. I have an additional question though. Is there any
> implicit assumption in LOCK/RCU torture tests whereby nothing else
> in the kernel is hotplugging cpus in/out (through cpu_down()/up())
> while they are running ?
>
> I am asking because that's the main reason behind my query. Those tests
> hotplug cpus in and out through cpu_down/up() but AFAICS nothing
> prevents another piece of code in the kernel to call those functions and
> the tests may just fail in that case (ie trying to cpu_down() a cpu
> that is not online).
>
> Are false negatives contemplated (or I am missing something) ?
The current code assumes nothing else doing CPU-hotplug operations,
and will therefore print "RCU_HOTPLUG" error (or "LOCK_HOTPLUG" for
locktorture) if any of the hotplug operations failed.
> I just would like to understand if what this patch currently does
> is safe and sound. I think that calling cpu_down() and cpu_up()
> is always safe, but the test can result in false negatives if
> other kernel subsystems (eg LOCK torture test) are calling those
> APIs in parallel (because cpu_down()/cpu_up() calls can fail - eg
> trying to cpu_down() a cpu that is not online any longer, since it
> was taken down by another kernel control path), that's the question
> I have.
I am assuming that these added calls to cpu_down() and cpu_up() aren't
enabled by default. If they are, rcutorture and locktorture need some
way to turn the off.
So maybe we need to have some sort of API that detects concurrent
CPU-hotplug torturing? Maybe something like the following?
static atomic_t n_cpu_hotplug_torturers;
static atomic_t cpu_hotplug_concurrent_torture;
void torture_start_cpu_hotplug(void)
{
if (atomic_inc_return(&n_cpu_hotplug_torturers) > 1)
atomic_inc(&cpu_hotplug_concurrent_torture);
}
void torture_end_cpu_hotplug(void)
{
atomic_dec(&n_cpu_hotplug_torturers);
}
bool torture_cpu_hotplug_was_concurrent(void)
{
return !!atomic_read(&cpu_hotplug_concurrent_torture);
}
The locktorture and rcutorture code could then ignore CPU-hotplug
errors that could be caused by concurrent access. And complain
bitterly about the concurrent access, of course! ;-)
Or am I missing your point?
Thanx, Paul
> Thanks !
> Lorenzo
>
> >
> > Thanx, Paul
> >
> > > There is something simple you can do to get this "fixed".
> > >
> > > You can use the new API James implemented for hibernate,
> > > that allows you to disable (ie PSCI CPU OFF) all "secondary" cpus
> > > other than the primary one passed in as parameter:
> > >
> > > freeze_secondary_cpus(int primary);
> > >
> > > that function will _cpu_down() all online cpus other than "primary"
> > > in one go, without any interference allowed from other bits of the
> > > kernel. It requires an enable_nonboot_cpus() counterpart, and you
> > > can do that for every online cpus you detect (actually you can even
> > > avoid using the online cpu mask and use the present mask to carry
> > > out the test). If there is a resident trusted OS you can just
> > > trigger the test with primary == tos_resident_cpu, since all
> > > others are bound to fail (well, you can run them and check they
> > > do fail, it is a checker after all).
> > >
> > > You would lose the capability of hotplugging a "cluster" at a time, but
> > > I do not think it is a big problem, the test above would cover it
> > > and more importantly, it is safe to execute.
> > >
> > > Or we can augment the torture test API to restrict the cpumask
> > > it actually uses to offline/online cpus (I am referring to
> > > torture_onoff(), kernel/torture.c).
> > >
> > > Further comments appreciated since I am not sure I grokked the
> > > assumption the torture tests make about hotplugging cpus in and out,
> > > I will go through the commits logs again to find more info.
> > >
> > > Thanks !
> > > Lorenzo
> > >
> > > > + */
> > > > + nb_available_cpus = num_online_cpus();
> > > > +
> > > > + /* Check PSCI operations are set up and working. */
> > > > + ret = psci_ops_check();
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + pr_info("PSCI checker started using %u CPUs\n", nb_available_cpus);
> > > > +
> > > > + pr_info("Starting hotplug tests\n");
> > > > + ret = hotplug_tests();
> > > > + if (ret == 0)
> > > > + pr_info("Hotplug tests passed OK\n");
> > > > + else if (ret > 0)
> > > > + pr_err("%d error(s) encountered in hotplug tests\n", ret);
> > > > + else {
> > > > + pr_err("Out of memory\n");
> > > > + return ret;
> > > > + }
> > > > +
> > > > + pr_info("Starting suspend tests (%d cycles per state)\n",
> > > > + NUM_SUSPEND_CYCLE);
> > > > + ret = suspend_tests();
> > > > + if (ret == 0)
> > > > + pr_info("Suspend tests passed OK\n");
> > > > + else if (ret > 0)
> > > > + pr_err("%d error(s) encountered in suspend tests\n", ret);
> > > > + else {
> > > > + switch (ret) {
> > > > + case -ENOMEM:
> > > > + pr_err("Out of memory\n");
> > > > + break;
> > > > + case -ENODEV:
> > > > + pr_warn("Could not start suspend tests on any CPU\n");
> > > > + break;
> > > > + }
> > > > + }
> > > > +
> > > > + pr_info("PSCI checker completed\n");
> > > > + return ret < 0 ? ret : 0;
> > > > +}
> > > > +late_initcall(psci_checker);
> > > > --
> > > > 2.10.0
> > > >
> > >
> >
>
^ permalink raw reply
* [PATCH v2] clocksource/arm_arch_timer: Map frame with of_io_request_and_map()
From: Daniel Lezcano @ 2016-10-26 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026073550.22918-1-sboyd@codeaurora.org>
On 26/10/2016 09:35, Stephen Boyd wrote:
> Let's use the of_io_request_and_map() API so that the frame
> region is protected and shows up in /proc/iomem.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
Applied for 4.10.
Thanks!
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH v14 7/9] clocksource/drivers/arm_arch_timer: Refactor the timer init code to prepare for GTDT
From: Fu Wei @ 2016-10-26 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021113213.GD16630@leverpostej>
Hi Mark,
On 21 October 2016 at 19:32, Mark Rutland <mark.rutland@arm.com> wrote:
> On Thu, Sep 29, 2016 at 02:17:15AM +0800, fu.wei at linaro.org wrote:
>> From: Fu Wei <fu.wei@linaro.org>
>>
>> The patch refactor original memory-mapped timer init code:
>> (1) extract some subfunction for reusing some common code
>> a. get_cnttidr
>> b. is_best_frame
>> (2) move base address and irq code for arch_timer_mem to
>> arch_timer_mem_register
>>
>> Signed-off-by: Fu Wei <fu.wei@linaro.org>
>> ---
>> drivers/clocksource/arm_arch_timer.c | 159 +++++++++++++++++++++--------------
>> 1 file changed, 96 insertions(+), 63 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>> index c7b0040..e78095f 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -57,6 +57,7 @@
>> static unsigned arch_timers_present __initdata;
>>
>> static void __iomem *arch_counter_base;
>> +static void __iomem *cntctlbase __initdata;
>>
>> struct arch_timer {
>> void __iomem *base;
>> @@ -656,15 +657,49 @@ out:
>> return err;
>> }
>>
>> -static int __init arch_timer_mem_register(void __iomem *base, unsigned int irq)
>> +static int __init arch_timer_mem_register(struct device_node *np, void *frame)
>> {
>> - int ret;
>> - irq_handler_t func;
>> + struct device_node *frame_node = NULL;
>> struct arch_timer *t;
>> + void __iomem *base;
>> + irq_handler_t func;
>> + unsigned int irq;
>> + int ret;
>> +
>> + if (!frame)
>> + return -EINVAL;
>
> Why would we call this without a frame?
Sorry, I just verify it , make sure frame is not NULL,
Because it is a "static" function, so we do need this check?
>
>> +
>> + if (np) {
>
> ... or without a node?
For "np", for now, we just just verify it, but it is just paperation
for GTDT support,
Because in next patch, if np == NULL, that means we call this function
from GTDT, but not DT.
>
>> + frame_node = (struct device_node *)frame;
>> + base = of_iomap(frame_node, 0);
>> + arch_timer_detect_rate(base, np);
>
> ... BANG! (we check base too late, below).
>
> Please as Marc requested several versions ago: split the FW parsing
> (ACPI and DT) so that happens first, *then* once we have the data in a
> common format, use that to drive poking the HW, requesting IRQs, etc,
> completely independent of the source.
>
> In patches, do this by:
>
> (1) adding the data structures
> (2) splitting the existing DT probing to use them
> (3) Adding ACPI functionality atop
this patch is a preparation for GTDT support, I have splitted some
functions for reusing them in next patch(GTDT support)
if np == NULL, that means we call this function from GTDT, but
if np != NULL, that means we call this function from DT
>
>> -static int __init arch_timer_mem_init(struct device_node *np)
>> +static int __init get_cnttidr(struct device_node *np, u32 *cnttidr)
>> {
>> - struct device_node *frame, *best_frame = NULL;
>> - void __iomem *cntctlbase, *base;
>> - unsigned int irq, ret = -EINVAL;
>> - u32 cnttidr;
>> + if (!cnttidr)
>> + return -EINVAL;
>> +
>> + if (np)
>> + cntctlbase = of_iomap(np, 0);
>> + else
>> + return -EINVAL;
>
> We want to check this for ACPI too, no?
just like I said above, this is a preparation for GTDT support,
So please correct me if I am doing this in the wrong way, thanks :-)
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH V3 8/8] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops
From: Robin Murphy @ 2016-10-26 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475600632-21289-9-git-send-email-sricharan@codeaurora.org>
On 04/10/16 18:03, Sricharan R wrote:
> With arch_setup_dma_ops now being called late during device's probe after the
> device's iommu is probed, the notifier trick required to handle the early
> setup of dma_ops before the iommu group gets created is not required.
> So removing the notifier's here.
Hooray!
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> ---
> arch/arm64/mm/dma-mapping.c | 100 ++------------------------------------------
> 1 file changed, 3 insertions(+), 97 deletions(-)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index faf4b92..eb593af 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -799,24 +799,6 @@ static struct dma_map_ops iommu_dma_ops = {
> .mapping_error = iommu_dma_mapping_error,
> };
>
> -/*
> - * TODO: Right now __iommu_setup_dma_ops() gets called too early to do
> - * everything it needs to - the device is only partially created and the
> - * IOMMU driver hasn't seen it yet, so it can't have a group. Thus we
> - * need this delayed attachment dance. Once IOMMU probe ordering is sorted
> - * to move the arch_setup_dma_ops() call later, all the notifier bits below
> - * become unnecessary, and will go away.
> - */
> -struct iommu_dma_notifier_data {
> - struct list_head list;
> - struct device *dev;
> - const struct iommu_ops *ops;
> - u64 dma_base;
> - u64 size;
> -};
> -static LIST_HEAD(iommu_dma_masters);
> -static DEFINE_MUTEX(iommu_dma_notifier_lock);
> -
> static bool do_iommu_attach(struct device *dev, const struct iommu_ops *ops,
> u64 dma_base, u64 size)
This should go as well...
> {
> @@ -837,79 +819,9 @@ static bool do_iommu_attach(struct device *dev, const struct iommu_ops *ops,
> return true;
> }
>
> -static void queue_iommu_attach(struct device *dev, const struct iommu_ops *ops,
> - u64 dma_base, u64 size)
> -{
> - struct iommu_dma_notifier_data *iommudata;
> -
> - iommudata = kzalloc(sizeof(*iommudata), GFP_KERNEL);
> - if (!iommudata)
> - return;
> -
> - iommudata->dev = dev;
> - iommudata->ops = ops;
> - iommudata->dma_base = dma_base;
> - iommudata->size = size;
> -
> - mutex_lock(&iommu_dma_notifier_lock);
> - list_add(&iommudata->list, &iommu_dma_masters);
> - mutex_unlock(&iommu_dma_notifier_lock);
> -}
> -
> -static int __iommu_attach_notifier(struct notifier_block *nb,
> - unsigned long action, void *data)
> -{
> - struct iommu_dma_notifier_data *master, *tmp;
> -
> - if (action != BUS_NOTIFY_BIND_DRIVER)
> - return 0;
> -
> - mutex_lock(&iommu_dma_notifier_lock);
> - list_for_each_entry_safe(master, tmp, &iommu_dma_masters, list) {
> - if (data == master->dev && do_iommu_attach(master->dev,
> - master->ops, master->dma_base, master->size)) {
> - list_del(&master->list);
> - kfree(master);
> - break;
> - }
> - }
> - mutex_unlock(&iommu_dma_notifier_lock);
> - return 0;
> -}
> -
> -static int __init register_iommu_dma_ops_notifier(struct bus_type *bus)
> -{
> - struct notifier_block *nb = kzalloc(sizeof(*nb), GFP_KERNEL);
> - int ret;
> -
> - if (!nb)
> - return -ENOMEM;
> -
> - nb->notifier_call = __iommu_attach_notifier;
> -
> - ret = bus_register_notifier(bus, nb);
> - if (ret) {
> - pr_warn("Failed to register DMA domain notifier; IOMMU DMA ops unavailable on bus '%s'\n",
> - bus->name);
> - kfree(nb);
> - }
> - return ret;
> -}
> -
> static int __init __iommu_dma_init(void)
> {
> - int ret;
> -
> - ret = iommu_dma_init();
> - if (!ret)
> - ret = register_iommu_dma_ops_notifier(&platform_bus_type);
> - if (!ret)
> - ret = register_iommu_dma_ops_notifier(&amba_bustype);
> -#ifdef CONFIG_PCI
> - if (!ret)
> - ret = register_iommu_dma_ops_notifier(&pci_bus_type);
> -#endif
> - return ret;
> + return iommu_dma_init();
> }
> arch_initcall(__iommu_dma_init);
>
> @@ -920,18 +832,12 @@ static void __iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>
> if (!ops)
> return;
> - /*
> - * TODO: As a concession to the future, we're ready to handle being
> - * called both early and late (i.e. after bus_add_device). Once all
> - * the platform bus code is reworked to call us late and the notifier
> - * junk above goes away, move the body of do_iommu_attach here.
...per this commment. It has no need to be a separate function once this
is the only call site (plus it has a misleadingly inaccurate name anyway).
> - */
> +
> group = iommu_group_get(dev);
> +
> if (group) {
> do_iommu_attach(dev, ops, dma_base, size);
> iommu_group_put(group);
> - } else {
> - queue_iommu_attach(dev, ops, dma_base, size);
> }
> }
I overlooked it in the last patch as the relevant context was in the
cover letter, so I'll just add the comment here; the domain check and
WARN_ON() in arch_teardown_dma_ops() is mostly a left-over from the
'fake default domain' bodge that was already gone from the final version
of the arm64 dma_ops series. It's based on the assumption that
arch_teardown_dma_ops() is called after the device is removed from the
bus - I'm not convinced that assumption was ever actually true, it now
doesn't necessarily do anything anyway (since detach_device is
deprecated). I'll spin a cleanup patch for that myself...
Robin.
^ permalink raw reply
* [PATCH] tty/serial: at91: fix hardware handshake on Atmel platforms
From: Alexandre Belloni @ 2016-10-26 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f89c29e4-b68f-a8ea-cefb-e70dda6739a0@gmail.com>
Richard,
On 26/10/2016 at 16:55:02 +0200, Richard Genoud wrote :
> On 25/10/2016 19:17, Uwe Kleine-K?nig wrote:
> Quote from the commit message:
> " Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
> hardware handshake is enabled") actually allowed to enable hardware
> handshaking.
> Before, the CRTSCTS flags was silently ignored.
> "
> This wasn't true.
> This was a misunderstanding of the ATMEL_US_USMODE_HWHS flag:
> Commit 1cf6e8fc8341 didn't allowed to enable hardware handshaking, but
> introduced the ATMEL_US_USMODE_HWHS flag.
> And before 1cf6e8fc8341, the CRTSCTS flags wasn't silently ignored, it
> was perfectly respected.
>
It was not really a misunderstanding, it is a difference in
expectations. There is one topic on which we don't agree and I'm fine
with your solution as long as I don't have to support people with the
failures (hence my ack). My (and Cyrille's) opinion is that CRTSCTS has
to be 100% reliable and this is only possible with assistance from the
hardware. That's why I wanted to report when HW didn't have proper
support to userspace.
On your side you are fine with software handling of RTS and CTS (which
is a feature that worked before our patches). You just have to remember
that at some point because of latencies and the way the IPs are clocked,
this will fail and you'll start losing bytes.
Again, I'm fine with that but I won't handle people complaining about it
:)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/5] ARM: davinci: Don't append git rev to local version
From: David Lechner @ 2016-10-26 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <47ad8be9-54e0-4e0c-3ff5-31662e6ca4de@ti.com>
On 10/26/2016 05:54 AM, Sekhar Nori wrote:
> On Monday 24 October 2016 08:45 PM, David Lechner wrote:
>> On 10/24/2016 06:35 AM, Sekhar Nori wrote:
>>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>>> In the davinci default configuration, don't append the git revision to
>>>> the local kernel version by. This seems like the more desirable default
>>>> value.
>>>
>>> Why? To the contrary I actually quite like the fact that the git commit
>>> is appended to version string. Makes it easy for me to cross-check that
>>> I am booting the right image.
>>>
>>>>
>>>> Signed-off-by: David Lechner <david@lechnology.com>
>>>
>>> Thanks,
>>> Sekhar
>>>
>>
>> Each time you make a commit, you get a new version, which installs
>> another copy of the kernel modules on the device. This will fill up the
>> SD card if you are making many commits.
>
> Right, but thats easily fixable by removing existing modules before
> installing new ones.
>
>> Also, if someone wants to build the mainline kernel using the default
>> configuration, it seems odd to have a git revision tacked on to the end
>> even though you made no revisions.
>
> If you checkout a tag and build, then no commit information is added.
> Which I guess is what most end users will do.
>
> I don't see this done in other defconfigs like omap2plus and multi_v7 as
> well. I would like to keep it similar for davinci.
>
> Thanks,
> Sekhar
>
OK, I will drop this patch.
^ permalink raw reply
* [PATCH v14 7/9] clocksource/drivers/arm_arch_timer: Refactor the timer init code to prepare for GTDT
From: Mark Rutland @ 2016-10-26 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADyBb7sJfY4=5NKKPGosOGv4sq4Tg2_TBW-XbWYoqfz4JNE-LA@mail.gmail.com>
On Wed, Oct 26, 2016 at 11:24:32PM +0800, Fu Wei wrote:
> On 21 October 2016 at 19:32, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Thu, Sep 29, 2016 at 02:17:15AM +0800, fu.wei at linaro.org wrote:
> >> +static int __init arch_timer_mem_register(struct device_node *np, void *frame)
> >> {
> >> - int ret;
> >> - irq_handler_t func;
> >> + struct device_node *frame_node = NULL;
> >> struct arch_timer *t;
> >> + void __iomem *base;
> >> + irq_handler_t func;
> >> + unsigned int irq;
> >> + int ret;
> >> +
> >> + if (!frame)
> >> + return -EINVAL;
> >
> > Why would we call this without a frame?
>
> Sorry, I just verify it , make sure frame is not NULL,
> Because it is a "static" function, so we do need this check?
I'd rather we simply don't call the function rather than passing a NULL
frame in.
> >> +
> >> + if (np) {
> >
> > ... or without a node?
>
> For "np", for now, we just just verify it, but it is just paperation
> for GTDT support,
> Because in next patch, if np == NULL, that means we call this function
> from GTDT, but not DT.
Please don't do that. More on that below.
> > Please as Marc requested several versions ago: split the FW parsing
> > (ACPI and DT) so that happens first, *then* once we have the data in a
> > common format, use that to drive poking the HW, requesting IRQs, etc,
> > completely independent of the source.
> >
> > In patches, do this by:
> >
> > (1) adding the data structures
> > (2) splitting the existing DT probing to use them
> > (3) Adding ACPI functionality atop
>
> this patch is a preparation for GTDT support, I have splitted some
> functions for reusing them in next patch(GTDT support)
>
> if np == NULL, that means we call this function from GTDT, but
> if np != NULL, that means we call this function from DT
As above, please structure the patches such that that never happens.
We currently have:
+--------------------------+
| DT Parsing + Common code |
+--------------------------+
Per (1 and 2) make this:
+------------+ +-------------+
| DT parsing |--(common structure)-->| Common code |
+------------+ +-------------+
Then per (3) make this:
+------------+
| DT parsing |--(common structure)------+
+------------+ |
v
+-------------+
| Common code |
+-------------+
^
+--------------+ |
| ACPI parsing |--(common structure)----+
+--------------+
Thanks,
Mark.
^ permalink raw reply
* [PATCH RESEND 1/3] clk: imx6: Mask mmdc_ch1 handshake for periph2_sel and mmdc_ch1_axi_podf
From: Fabio Estevam @ 2016-10-26 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476750554-21961-1-git-send-email-festevam@gmail.com>
Shawn,
Are you collecting the imx clk patches in this cycle?
I see no response from Stephen on this series from a long time.
We missed 4.9, so hopefully this can land in 4.10.
On Mon, Oct 17, 2016 at 10:29 PM, Fabio Estevam <festevam@gmail.com> wrote:
> From: Philipp Zabel <p.zabel@pengutronix.de>
>
> MMDC CH1 is not used on i.MX6Q, so the handshake needed to change the
> parent of periph2_sel or the divider of mmdc_ch1_axi_podf will never
> succeed.
> Disable the handshake mechanism to allow changing the frequency of
> mmdc_ch1_axi, allowing to use it as a possible source for the LDB DI
> clock.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> drivers/clk/imx/clk-imx6q.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
> index ce8ea10..66825a8 100644
> --- a/drivers/clk/imx/clk-imx6q.c
> +++ b/drivers/clk/imx/clk-imx6q.c
> @@ -156,6 +156,19 @@ static struct clk ** const uart_clks[] __initconst = {
> NULL
> };
>
> +#define CCM_CCDR 0x04
> +
> +#define CCDR_MMDC_CH1_MASK BIT(16)
> +
> +static void __init imx6q_mmdc_ch1_mask_handshake(void __iomem *ccm_base)
> +{
> + unsigned int reg;
> +
> + reg = readl_relaxed(ccm_base + CCM_CCDR);
> + reg |= CCDR_MMDC_CH1_MASK;
> + writel_relaxed(reg, ccm_base + CCM_CCDR);
> +}
> +
> static void __init imx6q_clocks_init(struct device_node *ccm_node)
> {
> struct device_node *np;
> @@ -297,6 +310,8 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> base = of_iomap(np, 0);
> WARN_ON(!base);
>
> + imx6q_mmdc_ch1_mask_handshake(base);
> +
> /* name reg shift width parent_names num_parents */
> clk[IMX6QDL_CLK_STEP] = imx_clk_mux("step", base + 0xc, 8, 1, step_sels, ARRAY_SIZE(step_sels));
> clk[IMX6QDL_CLK_PLL1_SW] = imx_clk_mux("pll1_sw", base + 0xc, 2, 1, pll1_sw_sels, ARRAY_SIZE(pll1_sw_sels));
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 4/9] pinctrl: meson: allow gpio to request irq
From: Kevin Hilman @ 2016-10-26 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYqoU0foW1izcZapbgUm+NO4quz9AZZBmts4841BRcigA@mail.gmail.com>
Hi Linus,
Linus Walleij <linus.walleij@linaro.org> writes:
> On Wed, Oct 26, 2016 at 4:22 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
>> On Tue, 2016-10-25 at 20:20 +0200, Linus Walleij wrote:
>
>>> However the semantic is such, that it is not necessary to call
>>> to_irq()
>>> before using an IRQ: the irqchip and gpiochip abstractions should be
>>> orthogonal.
>>
>> Linus,
>>
>> They are orthogonal. You can request an irq from the irqchip controller
>> without the gpiochip, like any other irq controller.
>
> OK good, sorry if I'm stating the obvious.
>
>> irq_create_mapping (and irq_create_fwspec_mapping) internally calls
>> irq_find_mapping. So if the mapping already exist (the irq is already
>> used before calling to_irq), the existing mapping will be returned. The
>> mapping will be actually created only if needed. It seems to be in line
>> with your explanation, no ?
>
> Yes, but you want to call irq_create_mapping() in slowpath (irq setup)
> and irq_find_mapping() in fastpath (irq handler). Else the first IRQ
> may result in unwelcomed surprises.
>
>> There is really a *lot* of gpio drivers which use irq_create_mapping in
>> the to_irq callback, are these all wrong ?
>
> Yes they are all wrong. They should all be using irq_find_mapping().
So, dumb question from someone trying (but having a hard time) to follow
and understand the rationale...
If it's wrong enough to completely reject, why are changes still being
merged that are doing it so wrong? (e.g. like this one[1], just merged
for v4.9)
Kevin
[1] 0eb9f683336d pinctrl: Add IRQ support to STM32 gpios
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/pinctrl/stm32/pinctrl-stm32.c?id=0eb9f683336d7eb99a3b75987620417c574ffb57
^ permalink raw reply
* [PATCH] tty/serial: at91: fix hardware handshake on Atmel platforms
From: Richard Genoud @ 2016-10-26 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026153548.xxvciigcscrjb5uv@piout.net>
2016-10-26 17:35 GMT+02:00 Alexandre Belloni
<alexandre.belloni@free-electrons.com>:
> Richard,
>
> On 26/10/2016 at 16:55:02 +0200, Richard Genoud wrote :
>> On 25/10/2016 19:17, Uwe Kleine-K?nig wrote:
>> Quote from the commit message:
>> " Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
>> hardware handshake is enabled") actually allowed to enable hardware
>> handshaking.
>> Before, the CRTSCTS flags was silently ignored.
>> "
>> This wasn't true.
>> This was a misunderstanding of the ATMEL_US_USMODE_HWHS flag:
>> Commit 1cf6e8fc8341 didn't allowed to enable hardware handshaking, but
>> introduced the ATMEL_US_USMODE_HWHS flag.
>> And before 1cf6e8fc8341, the CRTSCTS flags wasn't silently ignored, it
>> was perfectly respected.
>>
>
> It was not really a misunderstanding, it is a difference in
> expectations. There is one topic on which we don't agree and I'm fine
> with your solution as long as I don't have to support people with the
> failures (hence my ack). My (and Cyrille's) opinion is that CRTSCTS has
> to be 100% reliable and this is only possible with assistance from the
> hardware. That's why I wanted to report when HW didn't have proper
> support to userspace.
> On your side you are fine with software handling of RTS and CTS (which
> is a feature that worked before our patches). You just have to remember
> that at some point because of latencies and the way the IPs are clocked,
> this will fail and you'll start losing bytes.
>
> Again, I'm fine with that but I won't handle people complaining about it
> :)
So you broke this on purpose ?
Without saying so in the commit message ?
Nice to know.
^ permalink raw reply
* [PATCH] ARM: davinci: da850: Fix pwm name matching
From: Kevin Hilman @ 2016-10-26 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f423a705-5ae2-78cf-2b63-609dd4e2cdf6@ti.com>
Hi Sekhar,
Sekhar Nori <nsekhar@ti.com> writes:
> On Tuesday 25 October 2016 11:24 PM, David Lechner wrote:
>> This fixes pwm name matching for DA850 familiy devices. When using device
>> tree, the da850_auxdata_lookup[] table caused pwm devices to have the exact
>> same name, which caused errors when trying to register the devices.
>>
>> The names for clock matching in da850_clks[] also have to be updated to
>> to exactly match in order for the clock lookup to work correctly.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>
> Applied to "fixes" branch. Will send upstream after testing a bit and
> also waiting to see if anyone else has any comments.
I'm not seeing a fixes branch in your tree. Did you push this out?
Similarily, I didn't see the updates in v4.10/defconfig either.
Kevin
^ permalink raw reply
* [PATCH v7] spi: sun4i: Allow transfers larger than FIFO size
From: Alex Gagniuc @ 2016-10-26 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026100743.GZ17252@sirena.org.uk>
On Wed, Oct 26, 2016 at 3:07 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Oct 26, 2016 at 12:00:30AM -0700, Alexandru Gagniuc wrote:
>> This is the seventh attempt to get this patch in. I was prompted to look
>> into this again as someone recently remarked:
>
> Please don't send cover letters for single patches, if there is anything
> that needs saying put it in the changelog of the patch or after the ---
> if it's administrative stuff. This reduces mail volume and ensures that
> any important information is recorded in the changelog rather than being
> lost.
Thanks for the heads up! Sorry about that. Do you want me to resend
this as a single mail?
Alex
^ permalink raw reply
* [PATCH v14 7/9] clocksource/drivers/arm_arch_timer: Refactor the timer init code to prepare for GTDT
From: Fu Wei @ 2016-10-26 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026154608.GB22713@leverpostej>
Hi Mark,
On 26 October 2016 at 23:46, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Oct 26, 2016 at 11:24:32PM +0800, Fu Wei wrote:
>> On 21 October 2016 at 19:32, Mark Rutland <mark.rutland@arm.com> wrote:
>> > On Thu, Sep 29, 2016 at 02:17:15AM +0800, fu.wei at linaro.org wrote:
>> >> +static int __init arch_timer_mem_register(struct device_node *np, void *frame)
>> >> {
>> >> - int ret;
>> >> - irq_handler_t func;
>> >> + struct device_node *frame_node = NULL;
>> >> struct arch_timer *t;
>> >> + void __iomem *base;
>> >> + irq_handler_t func;
>> >> + unsigned int irq;
>> >> + int ret;
>> >> +
>> >> + if (!frame)
>> >> + return -EINVAL;
>> >
>> > Why would we call this without a frame?
>>
>> Sorry, I just verify it , make sure frame is not NULL,
>> Because it is a "static" function, so we do need this check?
>
> I'd rather we simply don't call the function rather than passing a NULL
> frame in.
>
OK, NP, will do
>> >> +
>> >> + if (np) {
>> >
>> > ... or without a node?
>>
>> For "np", for now, we just just verify it, but it is just paperation
>> for GTDT support,
>> Because in next patch, if np == NULL, that means we call this function
>> from GTDT, but not DT.
>
> Please don't do that. More on that below.
>
>> > Please as Marc requested several versions ago: split the FW parsing
>> > (ACPI and DT) so that happens first, *then* once we have the data in a
>> > common format, use that to drive poking the HW, requesting IRQs, etc,
>> > completely independent of the source.
>> >
>> > In patches, do this by:
>> >
>> > (1) adding the data structures
>> > (2) splitting the existing DT probing to use them
>> > (3) Adding ACPI functionality atop
>>
>> this patch is a preparation for GTDT support, I have splitted some
>> functions for reusing them in next patch(GTDT support)
>>
>> if np == NULL, that means we call this function from GTDT, but
>> if np != NULL, that means we call this function from DT
>
> As above, please structure the patches such that that never happens.
>
> We currently have:
>
> +--------------------------+
> | DT Parsing + Common code |
> +--------------------------+
>
> Per (1 and 2) make this:
>
> +------------+ +-------------+
> | DT parsing |--(common structure)-->| Common code |
> +------------+ +-------------+
>
> Then per (3) make this:
>
> +------------+
> | DT parsing |--(common structure)------+
> +------------+ |
> v
> +-------------+
> | Common code |
> +-------------+
> ^
> +--------------+ |
> | ACPI parsing |--(common structure)----+
Thanks for your suggestion , I will do this way in my next patchset
Thanks :-)
> +--------------+
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v6 4/5] ARM: DTS: da850: Add cfgchip syscon node
From: David Lechner @ 2016-10-26 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477451211-31979-5-git-send-email-david@lechnology.com>
On 10/25/2016 10:06 PM, David Lechner wrote:
> Add a syscon node for the SoC CFGCHIPn registers. This is needed for
> the new usb phy driver.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> arch/arm/boot/dts/da850.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index f79e1b9..6bbf20d 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -188,6 +188,10 @@
> };
>
> };
> + cfgchip: cfgchip at 1417c {
I wonder if there is a more generic name instead of cfgchip at . Is there a
preferred generic name for syscon nodes?
> + compatible = "ti,da830-cfgchip", "syscon";
> + reg = <0x1417c 0x14>;
> + };
> edma0: edma at 0 {
> compatible = "ti,edma3-tpcc";
> /* eDMA3 CC0: 0x01c0 0000 - 0x01c0 7fff */
>
^ permalink raw reply
* [PATCH] tty/serial: at91: fix hardware handshake on Atmel platforms
From: Alexandre Belloni @ 2016-10-26 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACQ1gAhfSQG1_otKjvQUiXCajfZvOM-=VqhyKs1D+fXEU9eCnw@mail.gmail.com>
On 26/10/2016 at 17:51:07 +0200, Richard Genoud wrote :
> 2016-10-26 17:35 GMT+02:00 Alexandre Belloni
> <alexandre.belloni@free-electrons.com>:
> > Richard,
> >
> > On 26/10/2016 at 16:55:02 +0200, Richard Genoud wrote :
> >> On 25/10/2016 19:17, Uwe Kleine-K?nig wrote:
> >> Quote from the commit message:
> >> " Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
> >> hardware handshake is enabled") actually allowed to enable hardware
> >> handshaking.
> >> Before, the CRTSCTS flags was silently ignored.
> >> "
> >> This wasn't true.
> >> This was a misunderstanding of the ATMEL_US_USMODE_HWHS flag:
> >> Commit 1cf6e8fc8341 didn't allowed to enable hardware handshaking, but
> >> introduced the ATMEL_US_USMODE_HWHS flag.
> >> And before 1cf6e8fc8341, the CRTSCTS flags wasn't silently ignored, it
> >> was perfectly respected.
> >>
> >
> > It was not really a misunderstanding, it is a difference in
> > expectations. There is one topic on which we don't agree and I'm fine
> > with your solution as long as I don't have to support people with the
> > failures (hence my ack). My (and Cyrille's) opinion is that CRTSCTS has
> > to be 100% reliable and this is only possible with assistance from the
> > hardware. That's why I wanted to report when HW didn't have proper
> > support to userspace.
> > On your side you are fine with software handling of RTS and CTS (which
> > is a feature that worked before our patches). You just have to remember
> > that at some point because of latencies and the way the IPs are clocked,
> > this will fail and you'll start losing bytes.
> >
> > Again, I'm fine with that but I won't handle people complaining about it
> > :)
>
> So you broke this on purpose ?
> Without saying so in the commit message ?
> Nice to know.
No, I didn't think about that use case at the time and I understood
after you explanations. I wouldn't have removed an existing
functionality like that.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [RFC PATCH 1/5] of: introduce the overlay manager
From: Mathieu Poirier @ 2016-10-26 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026145756.21689-2-antoine.tenart@free-electrons.com>
Hi Antoine,
Please find my comments below.
On 26 October 2016 at 08:57, Antoine Tenart
<antoine.tenart@free-electrons.com> wrote:
> The overlay manager is an in-kernel library helping to handle dt overlay
> loading when using capes.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
> drivers/of/Kconfig | 2 +
> drivers/of/Makefile | 1 +
> drivers/of/overlay-manager/Kconfig | 6 +
> drivers/of/overlay-manager/Makefile | 1 +
> drivers/of/overlay-manager/overlay-manager.c | 199 +++++++++++++++++++++++++++
> include/linux/overlay-manager.h | 38 +++++
> 6 files changed, 247 insertions(+)
> create mode 100644 drivers/of/overlay-manager/Kconfig
> create mode 100644 drivers/of/overlay-manager/Makefile
> create mode 100644 drivers/of/overlay-manager/overlay-manager.c
> create mode 100644 include/linux/overlay-manager.h
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index bc07ad30c9bf..e57aeaf0bf4f 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -116,4 +116,6 @@ config OF_OVERLAY
> config OF_NUMA
> bool
>
> +source "drivers/of/overlay-manager/Kconfig"
> +
> endif # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index d7efd9d458aa..d738fd41271f 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_OF_OVERLAY) += overlay.o
> obj-$(CONFIG_OF_NUMA) += of_numa.o
>
> obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> +obj-y += overlay-manager/
> diff --git a/drivers/of/overlay-manager/Kconfig b/drivers/of/overlay-manager/Kconfig
> new file mode 100644
> index 000000000000..eeb76054dcb8
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Kconfig
> @@ -0,0 +1,6 @@
> +config OF_OVERLAY_MGR
> + bool "Device Tree Overlay Manager"
> + depends on OF_OVERLAY
> + help
> + Enable the overlay manager to handle automatic overlay loading when
> + devices are detected.
> diff --git a/drivers/of/overlay-manager/Makefile b/drivers/of/overlay-manager/Makefile
> new file mode 100644
> index 000000000000..86d2b53950e7
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_OF_OVERLAY_MGR) += overlay-manager.o
> diff --git a/drivers/of/overlay-manager/overlay-manager.c b/drivers/of/overlay-manager/overlay-manager.c
> new file mode 100644
> index 000000000000..a725d7e24d38
> --- /dev/null
> +++ b/drivers/of/overlay-manager/overlay-manager.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 - Antoine Tenart <antoine.tenart@free-electrons.com>
> + *
> + * 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/firmware.h>
> +#include <linux/list.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/overlay-manager.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +
> +struct overlay_mgr_overlay {
> + struct list_head list;
> + char *name;
> +};
Please use the proper documentation format for structures.
> +
> +LIST_HEAD(overlay_mgr_overlays);
> +LIST_HEAD(overlay_mgr_formats);
> +DEFINE_SPINLOCK(overlay_mgr_lock);
> +DEFINE_SPINLOCK(overlay_mgr_format_lock);
> +
> +/*
> + * overlay_mgr_register_format()
> + *
> + * Adds a new format candidate to the list of supported formats. The registered
> + * formats are used to parse the headers stored on the dips.
> + */
> +int overlay_mgr_register_format(struct overlay_mgr_format *candidate)
> +{
> + struct overlay_mgr_format *format;
> + int err = 0;
> +
> + spin_lock(&overlay_mgr_format_lock);
> +
> + /* Check if the format is already registered */
> + list_for_each_entry(format, &overlay_mgr_formats, list) {
> + if (!strcpy(format->name, candidate->name)) {
This function is public to the rest of the kernel - limiting the
lenght of ->name and using strncpy() is probably a good idea.
> + err = -EEXIST;
> + goto err;
> + }
> + }
> +
> + list_add_tail(&candidate->list, &overlay_mgr_formats);
> +
> +err:
> + spin_unlock(&overlay_mgr_format_lock);
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_register_format);
> +
> +/*
> + * overlay_mgr_parse()
> + *
> + * Parse raw data with registered format parsers. Fills the candidate string if
> + * one parser understood the raw data format.
> + */
> +int overlay_mgr_parse(struct device *dev, void *data, char ***candidates,
I'm pretty sure there is another way to proceed than using 3 levels of
references. It makes the code hard to read and a prime candidate for
errors.
> + unsigned *n)
> +{
> + struct list_head *pos, *tmp;
> + struct overlay_mgr_format *format;
> +
> + list_for_each_safe(pos, tmp, &overlay_mgr_formats) {
> + format = list_entry(pos, struct overlay_mgr_format, list);
Can you use list_for_each_safe_entry() ?
> +
> + format->parse(dev, data, candidates, n);
->parse() returns an error code. It is probably a good idea to check
it. If it isn't needed then a comment explaining why it is the case
would be appreciated.
> + if (n > 0)
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_parse);
> +
> +static int overlay_mgr_check_overlay(struct device_node *node)
> +{
> + struct property *p;
> + const char *str = NULL;
> +
> + p = of_find_property(node, "compatible", NULL);
> + if (!p)
> + return -EINVAL;
> +
> + do {
> + str = of_prop_next_string(p, str);
> + if (of_machine_is_compatible(str))
> + return 0;
> + } while (str);
> +
> + return -EINVAL;
> +}
> +
> +/*
> + * _overlay_mgr_insert()
> + *
> + * Try to request and apply an overlay given a candidate name.
> + */
> +static int _overlay_mgr_apply(struct device *dev, char *candidate)
> +{
> + struct overlay_mgr_overlay *overlay;
> + struct device_node *node;
> + const struct firmware *firmware;
> + char *firmware_name;
> + int err = 0;
> +
> + spin_lock(&overlay_mgr_lock);
> +
> + list_for_each_entry(overlay, &overlay_mgr_overlays, list) {
> + if (!strcmp(overlay->name, candidate)) {
> + dev_err(dev, "overlay already loaded\n");
> + err = -EEXIST;
> + goto err_lock;
> + }
> + }
> +
> + overlay = devm_kzalloc(dev, sizeof(*overlay), GFP_KERNEL);
Function devm_kzalloc() can sleep but you're holding a spinlock - I'm
surprised the kernel didn't complain here. Allocate the memory before
holding the lock. If the overly is already loaded simply free it on
the error path.
> + if (!overlay) {
> + err = -ENOMEM;
> + goto err_lock;
> + }
> +
> + overlay->name = candidate;
> +
> + firmware_name = kasprintf(GFP_KERNEL, "overlay-%s.dtbo", candidate);
> + if (!firmware_name) {
> + err = -ENOMEM;
> + goto err_free;
> + }
> +
> + dev_info(dev, "requesting firmware '%s'\n", firmware_name);
> +
> + err = request_firmware_direct(&firmware, firmware_name, dev);
> + if (err) {
> + dev_info(dev, "failed to request firmware '%s'\n",
> + firmware_name);
> + goto err_free;
> + }
> +
> + of_fdt_unflatten_tree((unsigned long *)firmware->data, NULL, &node);
> + if (!node) {
> + dev_err(dev, "failed to unflatted tree\n");
> + err = -EINVAL;
> + goto err_fw;
> + }
> +
> + of_node_set_flag(node, OF_DETACHED);
> +
> + err = of_resolve_phandles(node);
> + if (err) {
> + dev_err(dev, "failed to resolve phandles: %d\n", err);
> + goto err_fw;
> + }
> +
> + err = overlay_mgr_check_overlay(node);
> + if (err) {
> + dev_err(dev, "overlay checks failed: %d\n", err);
> + goto err_fw;
> + }
> +
> + err = of_overlay_create(node);
> + if (err < 0) {
> + dev_err(dev, "failed to create overlay: %d\n", err);
> + goto err_fw;
> + }
> +
> + list_add_tail(&overlay->list, &overlay_mgr_overlays);
> +
> + dev_info(dev, "loaded firmware '%s'\n", firmware_name);
> +
out:
> + spin_unlock(&overlay_mgr_lock);
> + return 0;
return err;
> +
> +err_fw:
> + release_firmware(firmware);
> +err_free:
> + devm_kfree(dev, overlay);
goto out;
> +err_lock:
> + spin_unlock(&overlay_mgr_lock);
> + return err;
This code is repeated twice. See above corrections to fix the situation.
> +}
> +
> +int overlay_mgr_apply(struct device *dev, char **candidates, unsigned n)
> +{
> + int i, ret;
> +
> + for (i=0; i < n; i++) {
I'm surprised checkpatch.pl let you get away with this one.
> + ret = _overlay_mgr_apply(dev, candidates[i]);
> + if (!ret)
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_apply);
> diff --git a/include/linux/overlay-manager.h b/include/linux/overlay-manager.h
> new file mode 100644
> index 000000000000..8adcc4f5ddf6
> --- /dev/null
> +++ b/include/linux/overlay-manager.h
> @@ -0,0 +1,38 @@
> +/*
> + * Copyright (C) 2016 - Antoine Tenart <antoine.tenart@free-electrons.com>
> + *
> + * 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.
> + */
> +
> +#ifndef __OVERLAY_MGR_H__
> +#define __OVERLAY_MGR_H__
> +
> +#include <linux/device.h>
> +#include <linux/list.h>
> +#include <linux/sizes.h>
> +
> +#define OVERLAY_MGR_DIP_MAX_SZ SZ_128
> +
> +struct overlay_mgr_format {
> + struct list_head list;
> + char *name;
> + int (*parse)(struct device *dev, void *data, char ***candidates,
> + unsigned *n);
> +};
Please use the kernel documentation standard.
> +
> +int overlay_mgr_register_format(struct overlay_mgr_format *candidate);
> +int overlay_mgr_parse(struct device *dev, void *data, char ***candidates,
> + unsigned *n);
> +int overlay_mgr_apply(struct device *dev, char **candidates, unsigned n);
> +
> +#define dip_convert(field) \
> + ( \
> + (sizeof(field) == 1) ? field : \
> + (sizeof(field) == 2) ? be16_to_cpu(field) : \
> + (sizeof(field) == 4) ? be32_to_cpu(field) : \
> + -1 \
> + )
Please document your macro definition. Otherwise reviewers are left guessing...
> +
> +#endif /* __OVERLAY_MGR_H__ */
> --
> 2.10.1
>
^ permalink raw reply
* [PATCH v6 1/5] ARM: davinci: da8xx: add usb phy clocks
From: David Lechner @ 2016-10-26 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6bcc1ac1-446c-6191-1c63-e37ccfaf9556@ti.com>
On 10/26/2016 02:59 AM, Sekhar Nori wrote:
> On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:
>> Up to this point, the USB phy clock configuration was handled manually in
>> the board files and in the usb drivers. This adds proper clocks so that
>> the usb drivers can use clk_get and clk_enable and not have to worry about
>> the details. Also, the related code is removed from the board files and
>> replaced with the new clock registration functions.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>> ---
>>
>> I have added "ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable"
>> from Axel Haslam to this patch.
>>
>> In the review of Axel's patch, Sekhar said:
>>
>>> We should not be using a NULL device pointer here. Can you pass the musb
>>> device pointer available in the same file? Also, da850_clks[] in da850.c
>>> needs to be fixed to add the matching device name.
>>
>> However, the musb device may not be registered. The usb20_clk can be used to
>> supply a 48MHz clock to USB 1.1 (ohci) without using the musb device. So, I am
>> inclined to leave this as NULL.
>
> But clock look-up has nothing to do with device being registered AFAICT.
> It is used to identify the clock consumer. Passing NULL there means the
> clock is not associated with any device. Which is not correct as we are
> specifically looking at MUSB module clock.
>
> Thanks,
> Sekhar
>
FWIW, clk_get() uses dev_name() to get the device name, which will
return NULL until after the platform device is registered.
I can add the device references anyway. However, this is complicated by
the fact that the musb platform device declaration is inside of an #if
IS_ENABLED(CONFIG_USB_MUSB_HDRC). I can either remove the #if or add
more #if's. Do you have a preference on this?
^ permalink raw reply
* [PATCH 1/2] ARM: dts: uniphier: add CPU clocks and OPP table for Pro5 SoC
From: Masahiro Yamada @ 2016-10-26 16:37 UTC (permalink / raw)
To: linux-arm-kernel
Add a CPU clock to every CPU node and a CPU OPP table to use the
generic cpufreq driver.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm/boot/dts/uniphier-pro5.dtsi | 74 ++++++++++++++++++++++++++++++++++++
1 file changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-pro5.dtsi b/arch/arm/boot/dts/uniphier-pro5.dtsi
index 5357ea9..5bd6068 100644
--- a/arch/arm/boot/dts/uniphier-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro5.dtsi
@@ -56,16 +56,90 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ clocks = <&sys_clk 32>;
enable-method = "psci";
next-level-cache = <&l2>;
+ operating-points-v2 = <&cpu_opp>;
};
cpu at 1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+ clocks = <&sys_clk 32>;
enable-method = "psci";
next-level-cache = <&l2>;
+ operating-points-v2 = <&cpu_opp>;
+ };
+ };
+
+ cpu_opp: opp_table {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp at 100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 116667000 {
+ opp-hz = /bits/ 64 <116667000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 150000000 {
+ opp-hz = /bits/ 64 <150000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 175000000 {
+ opp-hz = /bits/ 64 <175000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 233334000 {
+ opp-hz = /bits/ 64 <233334000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 350000000 {
+ opp-hz = /bits/ 64 <350000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 466667000 {
+ opp-hz = /bits/ 64 <466667000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 700000000 {
+ opp-hz = /bits/ 64 <700000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 933334000 {
+ opp-hz = /bits/ 64 <933334000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 1400000000 {
+ opp-hz = /bits/ 64 <1400000000>;
+ clock-latency-ns = <300>;
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: uniphier: add CPU clocks and OPP table for PXs2 SoC
From: Masahiro Yamada @ 2016-10-26 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477499859-12415-1-git-send-email-yamada.masahiro@socionext.com>
Add a CPU clock to every CPU node and a CPU OPP table to use the
generic cpufreq driver.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm/boot/dts/uniphier-pxs2.dtsi | 46 ++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index 950f07b..83ba3e6 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -56,32 +56,78 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ clocks = <&sys_clk 32>;
enable-method = "psci";
next-level-cache = <&l2>;
+ operating-points-v2 = <&cpu_opp>;
};
cpu at 1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+ clocks = <&sys_clk 32>;
enable-method = "psci";
next-level-cache = <&l2>;
+ operating-points-v2 = <&cpu_opp>;
};
cpu at 2 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <2>;
+ clocks = <&sys_clk 32>;
enable-method = "psci";
next-level-cache = <&l2>;
+ operating-points-v2 = <&cpu_opp>;
};
cpu at 3 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <3>;
+ clocks = <&sys_clk 32>;
enable-method = "psci";
next-level-cache = <&l2>;
+ operating-points-v2 = <&cpu_opp>;
+ };
+ };
+
+ cpu_opp: opp_table {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp at 100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 150000000 {
+ opp-hz = /bits/ 64 <150000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ clock-latency-ns = <300>;
};
};
--
1.9.1
^ 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