Re: [PATCH 1/3] x86/hash: fix build failure with older binutils
>>> On 21.02.14 at 20:17, "H. Peter Anvin" wrote: > On 02/21/2014 06:16 AM, Jan Beulich wrote: > On 21.02.14 at 13:51, "H. Peter Anvin" wrote: >>> How old? >> >> 2.16.91.0.5 (SLE10) >> > > I would *love* to kill off binutils 2.16. It was a horribly buggy > version, and it has been hard to deal with keeping things alive with it. > How important is this? > > Since this is the first I've heard of this being broken, I am kind of > encouraged that maybe we can move on? 2.17 doesn't have support for it either, yet has support for fxsaveq (which you can see in the patch context we check for too). Apart from that Documentation/Changes continues to state binutils 2.12 to be the minimum requirement... Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: gpio-rcar: init at postcore level
Hi Vladimir,
On Mon, Feb 24, 2014 at 4:42 PM, Vladimir Barinov
wrote:
> Hi Magnus,
>
>
> On 02/24/2014 06:57 AM, Magnus Damm wrote:
>>
>> Hi Vladimir,
>>
>> On Mon, Feb 24, 2014 at 1:37 AM,
>> wrote:
>>>
>>> From: Vladimir Barinov
>>>
>>> This adds ability to use gpio API at board init_machine level.
>>>
>>> F.e. it can be used in the following situation.
>>> Many reference hardware has onboard switches that selects which
>>> periferals
>>> to connect to the system. The gpio input state from switches can be used
>>> in choosing platform devices runtime in board code instead of
>>> ifdefs/defconfig
>>> changes.
>>>
>>> Signed-off-by:
>>>
>>> ---
>>> drivers/gpio/gpio-rcar.c | 12 +++-
>>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> Index: build/drivers/gpio/gpio-rcar.c
>>> ===
>>> --- build.orig/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:51.456229152
>>> +0400
>>> +++ build/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:52.320229133
>>> +0400
>>> @@ -485,7 +485,17 @@
>>> }
>>> };
>>>
>>> -module_platform_driver(gpio_rcar_device_driver);
>>> +static int __init gpio_rcar_init(void)
>>> +{
>>> + return platform_driver_register(&gpio_rcar_device_driver);
>>> +}
>>> +postcore_initcall(gpio_rcar_init);
>>> +
>>> +static void __exit gpio_rcar_exit(void)
>>> +{
>>> + platform_driver_unregister(&gpio_rcar_device_driver);
>>> +}
>>> +module_exit(gpio_rcar_exit);
>>>
>>> MODULE_AUTHOR("Magnus Damm");
>>> MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");
>>
>> Hi Vladimir,
>>
>> Thanks for your help. Good to see that you are working on enabling the
>> dual role USB port on Koelsch.
>>
>> Your current board code is checking some DIP switch value during boot,
>> and that kind of early use of GPIO would require a change in the probe
>> order like this patch implements. I do however believe that we should
>> not implement checking during boot like this.
>>
>> If you for instance check the legacy Lager USBHS DIP switch code that
>> runs during driver probe() then that can run can use GPIO without the
>> need for a change like this. So your GPIO user code needs to be
>> adjusted.
>
> Yes, this is true for USBHS that has platform callbacks like
> hardware_init/exit.
> But this is not acceptable for other devices like EHCI PCI/PHY and others.
> So we wouldn't be able to do such fixup for other cases.
Right, the USBHS driver has callbacks but PCI-based hardrware like
EHCI and OHCI do not have such. But I believe we already have some
kind of USB PHY abstraction level and we also have a R-Car Gen2 PHY
driver that somehow is integrated together with the PCI-based
hardware. Based on that my feeling is that the answer to ID-pin
control is there somewhere, and not just once during the boot! =)
Cheers,
/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rcu: fix incorrect notes for code
-/* Is the specified CPU a no-CPUs CPU? */
+/* Is the specified CPU a no-CBs CPU? */
bool rcu_is_nocb_cpu(int cpu)
Signed-off-by: Liu Ping Fan
---
kernel/rcu/tree_plugin.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 6e2ef4b..ec6cb76 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -2101,7 +2101,7 @@ static void rcu_init_one_nocb(struct rcu_node *rnp)
init_waitqueue_head(&rnp->nocb_gp_wq[1]);
}
-/* Is the specified CPU a no-CPUs CPU? */
+/* Is the specified CPU a no-CBs CPU? */
bool rcu_is_nocb_cpu(int cpu)
{
if (have_rcu_nocb_mask)
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: Add support for COMe-mBT10, COMe-cBT6 and COMe-cHL6 to Kontron PLD driver
This patch adds DMI system IDs for the Kontron modules COMe-mBT10, COMe-cBT6
and COMe-cHL6 to the Kontron PLD driver. The list of supported products in
the module description is also updated.
Signed-off-by: Michael Brunner
Acked-by: Christian Rauch
---
drivers/mfd/Kconfig | 5 +
drivers/mfd/kempld-core.c | 24
2 files changed, 29 insertions(+)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 49bb445..f093401 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -270,13 +270,18 @@ config MFD_KEMPLD
device may provide functions like watchdog, GPIO, UART and I2C bus.
The following modules are supported:
+ * COMe-bHL6
* COMe-bIP#
* COMe-bPC2 (ETXexpress-PC)
* COMe-bSC# (ETXexpress-SC T#)
+ * COMe-cBT6
* COMe-cCT6
* COMe-cDC2 (microETXexpress-DC)
+ * COMe-cHL6
* COMe-cPC2 (microETXexpress-PC)
+ * COMe-mBT10
* COMe-mCT10
+ * COMe-mTT10 (nanoETXexpress-TT)
* ETX-OH
This driver can also be built as a module. If so, the module
diff --git a/drivers/mfd/kempld-core.c b/drivers/mfd/kempld-core.c
index d3e2327..20a6afc 100644
--- a/drivers/mfd/kempld-core.c
+++ b/drivers/mfd/kempld-core.c
@@ -438,6 +438,14 @@ static struct dmi_system_id __initdata kempld_dmi_table[]
= {
.driver_data = (void *)&kempld_platform_data_generic,
.callback = kempld_create_platform_device,
}, {
+ .ident = "CHL6",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Kontron"),
+ DMI_MATCH(DMI_BOARD_NAME, "COMe-cHL6"),
+ },
+ .driver_data = (void *)&kempld_platform_data_generic,
+ .callback = kempld_create_platform_device,
+ }, {
.ident = "CHR2",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Kontron"),
@@ -510,6 +518,14 @@ static struct dmi_system_id __initdata kempld_dmi_table[]
= {
.driver_data = (void *)&kempld_platform_data_generic,
.callback = kempld_create_platform_device,
}, {
+ .ident = "CVV6",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Kontron"),
+ DMI_MATCH(DMI_BOARD_NAME, "COMe-cBT"),
+ },
+ .driver_data = (void *)&kempld_platform_data_generic,
+ .callback = kempld_create_platform_device,
+ }, {
.ident = "FRI2",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Kontron"),
@@ -533,6 +549,14 @@ static struct dmi_system_id __initdata kempld_dmi_table[]
= {
.driver_data = (void *)&kempld_platform_data_generic,
.callback = kempld_create_platform_device,
}, {
+ .ident = "MVV1",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Kontron"),
+ DMI_MATCH(DMI_BOARD_NAME, "COMe-mBT"),
+ },
+ .driver_data = (void *)&kempld_platform_data_generic,
+ .callback = kempld_create_platform_device,
+ }, {
.ident = "NTC1",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Kontron"),
--
1.8.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: comedi: Fix coding style issue in poc.c This is a patch to remove unneccessary space after function pointer name found with checkpatch.pl
Signed-off-by: David Roddick
---
drivers/staging/comedi/drivers/poc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/comedi/drivers/poc.c
b/drivers/staging/comedi/drivers/poc.c
index 2ae4ee1..22c7392 100644
--- a/drivers/staging/comedi/drivers/poc.c
+++ b/drivers/staging/comedi/drivers/poc.c
@@ -36,15 +36,15 @@ Configuration options:
struct boarddef_struct {
const char *name;
unsigned int iosize;
- int (*setup) (struct comedi_device *);
+ int (*setup)(struct comedi_device *);
int type;
int n_chan;
int n_bits;
- int (*winsn) (struct comedi_device *, struct comedi_subdevice *,
+ int (*winsn)(struct comedi_device *, struct comedi_subdevice *,
struct comedi_insn *, unsigned int *);
- int (*rinsn) (struct comedi_device *, struct comedi_subdevice *,
+ int (*rinsn)(struct comedi_device *, struct comedi_subdevice *,
struct comedi_insn *, unsigned int *);
- int (*insnbits) (struct comedi_device *, struct comedi_subdevice *,
+ int (*insnbits)(struct comedi_device *, struct comedi_subdevice *,
struct comedi_insn *, unsigned int *);
const struct comedi_lrange *range;
};
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] perf ui/tui: Add 'F' hotkey to toggle percentage output
On Thu, 20 Feb 2014 11:54:02 +0100, Jiri Olsa wrote: > On Mon, Feb 10, 2014 at 11:47:25AM +0900, Namhyung Kim wrote: >> Add 'F' hotkey to toggle relative and absolute percentage of filtered >> entries. >> >> Suggested-by: Jiri Olsa >> Signed-off-by: Namhyung Kim >> --- >> tools/perf/ui/browsers/hists.c | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c >> index 14ba6d524943..681c484c5c8e 100644 >> --- a/tools/perf/ui/browsers/hists.c >> +++ b/tools/perf/ui/browsers/hists.c >> @@ -1447,6 +1447,7 @@ static int perf_evsel__hists_browse(struct perf_evsel >> *evsel, int nr_events, >> "C Collapse all callchains\n" \ >> "d Zoom into current DSO\n" \ >> "E Expand all callchains\n" \ >> +"F Toggle percentage of filtered entries\n" \ >> >> /* help messages are sorted by lexical order of the hotkey */ >> const char report_help[] = HIST_BROWSER_HELP_COMMON >> @@ -1552,6 +1553,9 @@ static int perf_evsel__hists_browse(struct perf_evsel >> *evsel, int nr_events, >> if (env->arch) >> tui__header_window(env); >> continue; >> +case 'F': >> +symbol_conf.filter_relative ^= 1; >> +continue; >> case K_F1: >> case 'h': >> case '?': >> -- >> 1.7.11.7 >> > > when in relative mode i get 0 samples count > also in --stdio: > > [jolsa@krava perf]$ ./perf report -s symbol --symbols=system_call,vfs_write > --stdio --percentage=relative > Failed to open /tmp/perf-1063.map, continuing without symbols > # To display the perf.data header info, please use --header/--header-only > options. > # > # Samples: 0 of event 'cycles' > # Event count (approx.): 6046797 > # > # Overhead Symbol > # ... > # > 57.05% [k] system_call > 42.95% [k] vfs_write Oops, I found that I missed to increase it when adding hist entries.. will fix. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] Cpuidle: Use actual state latency in menu governor
Currently menu governor records the exit latency of the state it has
chosen for the idle period. The stored latency value is then later
used to calculate the actual length of the idle period. This value
may however be incorrect, as the entered state may not be the one
chosen by the governor. The entered state information is available,
so we can use that to obtain the real exit latency.
Signed-off-by: Tuukka Tikkanen
---
drivers/cpuidle/governors/menu.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index e9a2a27..115386a 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -124,7 +124,6 @@ struct menu_device {
unsigned intnext_timer_us;
unsigned intpredicted_us;
- unsigned intexit_us;
unsigned intbucket;
unsigned intcorrection_factor[BUCKETS];
unsigned intintervals[INTERVALS];
@@ -298,7 +297,6 @@ static int menu_select(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
}
data->last_state_idx = 0;
- data->exit_us = 0;
/* Special case when user has set very strict latency requirement */
if (unlikely(latency_req == 0))
@@ -359,7 +357,6 @@ static int menu_select(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
continue;
data->last_state_idx = i;
- data->exit_us = s->exit_latency;
}
return data->last_state_idx;
@@ -410,8 +407,8 @@ static void menu_update(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
* We correct for the exit latency; we are assuming here that the
* exit latency happens after the event that we're interested in.
*/
- if (measured_us > data->exit_us)
- measured_us -= data->exit_us;
+ if (measured_us > target->exit_latency)
+ measured_us -= target->exit_latency;
/* Update our correction ratio */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: Set policy to non-NULL only after all hotplug online work is done
On 02/24/2014 12:27 PM, Saravana Kannan wrote:
> The existing code sets the per CPU policy to a non-NULL value before all
> the steps performed during the hotplug online path is done. Specifically,
> this is done before the policy min/max, governors, etc are initialized for
> the policy. This in turn means that calls to cpufreq_cpu_get() return a
> non-NULL policy before the policy/CPU is ready to be used.
>
> To fix this, move the update of per CPU policy to a valid value after all
> the initialization steps for the policy are completed.
>
> Example kernel panic without this fix:
> [ 512.146185] Unable to handle kernel NULL pointer dereference at virtual
> address 0020
> [ 512.146195] pgd = c0003000
> [ 512.146213] [0020] *pgd=804003, *pmd=
> [ 512.146228] Internal error: Oops: 206 [#1] PREEMPT SMP ARM
>
> [ 512.146297] PC is at __cpufreq_governor+0x10/0x1ac
> [ 512.146312] LR is at cpufreq_update_policy+0x114/0x150
>
> [ 512.149740] ---[ end trace f23a8defea6cd706 ]---
> [ 512.149761] Kernel panic - not syncing: Fatal exception
> [ 513.152016] CPU0: stopping
> [ 513.154710] CPU: 0 PID: 7136 Comm: mpdecision Tainted: G D W
> 3.10.0-gd727407-00074-g979ede8 #396
>
> [ 513.317224] [] (notifier_call_chain+0x40/0x68) from []
> (__blocking_notifier_call_chain+0x40/0x58)
> [ 513.327809] [] (__blocking_notifier_call_chain+0x40/0x58) from
> [] (blocking_notifier_call_chain+0x14/0x1c)
> [ 513.339182] [] (blocking_notifier_call_chain+0x14/0x1c) from
> [] (cpufreq_set_policy+0xd4/0x2b8)
> [ 513.349594] [] (cpufreq_set_policy+0xd4/0x2b8) from []
> (cpufreq_init_policy+0x30/0x98)
> [ 513.359231] [] (cpufreq_init_policy+0x30/0x98) from []
> (__cpufreq_add_dev.isra.17+0x4dc/0x7a4)
> [ 513.369560] [] (__cpufreq_add_dev.isra.17+0x4dc/0x7a4) from
> [] (cpufreq_cpu_callback+0x58/0x84)
> [ 513.379978] [] (cpufreq_cpu_callback+0x58/0x84) from
> [] (notifier_call_chain+0x40/0x68)
> [ 513.389704] [] (notifier_call_chain+0x40/0x68) from []
> (__cpu_notify+0x28/0x44)
> [ 513.398728] [] (__cpu_notify+0x28/0x44) from []
> (_cpu_up+0xf4/0x1dc)
> [ 513.406797] [] (_cpu_up+0xf4/0x1dc) from []
> (cpu_up+0x5c/0x78)
> [ 513.414357] [] (cpu_up+0x5c/0x78) from []
> (store_online+0x44/0x74)
> [ 513.422253] [] (store_online+0x44/0x74) from []
> (sysfs_write_file+0x108/0x14c)
> [ 513.431195] [] (sysfs_write_file+0x108/0x14c) from []
> (vfs_write+0xd0/0x180)
> [ 513.439958] [] (vfs_write+0xd0/0x180) from []
> (SyS_write+0x38/0x68)
> [ 513.447947] [] (SyS_write+0x38/0x68) from []
> (ret_fast_syscall+0x0/0x30)
>
> In this specific case, CPU0 set's CPU1's policy->governor in
> cpufreq_init_policy() to NULL while CPU1 is using the policy->governor in
> __cpufreq_governor().
>
Whoa! That's horrible! Can you please explain how exactly you
triggered this? I'm curious...
> Signed-off-by: Saravana Kannan
> ---
> drivers/cpufreq/cpufreq.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index cb003a6..d5ceb43 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1109,11 +1109,6 @@ static int __cpufreq_add_dev(struct device *dev,
> struct subsys_interface *sif,
> goto err_set_policy_cpu;
> }
>
> - write_lock_irqsave(&cpufreq_driver_lock, flags);
> - for_each_cpu(j, policy->cpus)
> - per_cpu(cpufreq_cpu_data, j) = policy;
> - write_unlock_irqrestore(&cpufreq_driver_lock, flags);
> -
> if (cpufreq_driver->get) {
> policy->cur = cpufreq_driver->get(policy->cpu);
If you move the per-cpu init further down, then what happens to the
cpufreq_generic_get() that gets invoked here by some of the drivers?
It will almost always fail (because policy will be NULL) and hence
CPU online will be unsuccessful (though you wont observe it because
the error code is not bubbled up to the CPU hotplug core; perhaps we
should).
IMHO, we should fix the synchronization in cpufreq_init_policy().
I notice cpufreq_update_policy() as well as __cpufreq_governor() in
your stack trace, which means cpufreq_set_policy() was involved.
cpufreq_update_policy() takes the policy->rwsem for write, whereas
cpufreq_init_policy() doesn't take that lock at all, which is clearly
wrong.
My guess is that, if we fix that locking, everything will be fine and
you won't hit the bug. Would you like to give that a shot?
Regards,
Srivatsa S. Bhat
> if (!policy->cur) {
> @@ -1207,6 +1202,11 @@ static int __cpufreq_add_dev(struct device *dev,
> struct subsys_interface *sif,
> policy->user_policy.governor = policy->governor;
> }
>
> + write_lock_irqsave(&cpufreq_driver_lock, flags);
> + for_each_cpu(j, policy->cpus)
> + per_cpu(cpufreq_cpu_data, j) = policy;
> + write_unlock_irqrestore(&cpufreq_driver_lock, flags);
> +
> kobject_uevent(&policy->kobj, KOBJ_ADD);
> up_read(
[PATCH 1/7] Cpuidle: rename expected_us to next_timer_us in menu governor
The field expected_us is used to store the time remaining until next
timer expiry. The name is inaccurate, as we really do not expect all
wakeups to be caused by timers. In addition, another field with a very
similar name (predicted_us) is used to store the predicted time
remaining until any wakeup source being active.
This patch renames expected_us to next_timer_us in order to better
reflect the contained information.
Signed-off-by: Tuukka Tikkanen
---
drivers/cpuidle/governors/menu.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index cf7f2f0..e9a2a27 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -122,7 +122,7 @@ struct menu_device {
int last_state_idx;
int needs_update;
- unsigned intexpected_us;
+ unsigned intnext_timer_us;
unsigned intpredicted_us;
unsigned intexit_us;
unsigned intbucket;
@@ -257,7 +257,7 @@ again:
stddev = int_sqrt(stddev);
if (((avg > stddev * 6) && (divisor * 4 >= INTERVALS * 3))
|| stddev <= 20) {
- if (data->expected_us > avg)
+ if (data->next_timer_us > avg)
data->predicted_us = avg;
return;
}
@@ -306,11 +306,11 @@ static int menu_select(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
/* determine the expected residency time, round up */
t = ktime_to_timespec(tick_nohz_get_sleep_length());
- data->expected_us =
+ data->next_timer_us =
t.tv_sec * USEC_PER_SEC + t.tv_nsec / NSEC_PER_USEC;
- data->bucket = which_bucket(data->expected_us);
+ data->bucket = which_bucket(data->next_timer_us);
multiplier = performance_multiplier();
@@ -326,7 +326,7 @@ static int menu_select(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
* operands are 32 bits.
* Make sure to round up for half microseconds.
*/
- data->predicted_us = div_round64((uint64_t)data->expected_us *
+ data->predicted_us = div_round64((uint64_t)data->next_timer_us *
data->correction_factor[data->bucket],
RESOLUTION * DECAY);
@@ -336,7 +336,7 @@ static int menu_select(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
* We want to default to C1 (hlt), not to busy polling
* unless the timer is happening really really soon.
*/
- if (data->expected_us > 5 &&
+ if (data->next_timer_us > 5 &&
!drv->states[CPUIDLE_DRIVER_STATE_START].disabled &&
dev->states_usage[CPUIDLE_DRIVER_STATE_START].disable == 0)
data->last_state_idx = CPUIDLE_DRIVER_STATE_START;
@@ -401,7 +401,7 @@ static void menu_update(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
* for the whole expected time.
*/
if (unlikely(!(target->flags & CPUIDLE_FLAG_TIME_VALID)))
- last_idle_us = data->expected_us;
+ last_idle_us = data->next_timer_us;
measured_us = last_idle_us;
@@ -418,8 +418,8 @@ static void menu_update(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
new_factor = data->correction_factor[data->bucket];
new_factor -= new_factor / DECAY;
- if (data->expected_us > 0 && measured_us < MAX_INTERESTING)
- new_factor += RESOLUTION * measured_us / data->expected_us;
+ if (data->next_timer_us > 0 && measured_us < MAX_INTERESTING)
+ new_factor += RESOLUTION * measured_us / data->next_timer_us;
else
/*
* we were idle so long that we count it as a perfect
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: gpio-rcar: init at postcore level
Hello Ben, On 02/23/2014 11:09 PM, Ben Dooks wrote: On 23/02/14 16:37, vladimir.bari...@cogentembedded.com wrote: From: Vladimir Barinov This adds ability to use gpio API at board init_machine level. F.e. it can be used in the following situation. Many reference hardware has onboard switches that selects which periferals to connect to the system. The gpio input state from switches can be used in choosing platform devices runtime in board code instead of ifdefs/defconfig changes. Firstly, anyone still using platform_devices to describe their system needs to be stopped. We cannot go on supporting this when our primary boot method is supposed to be device-tree. If we keep doing this then we will not get any of the current issues fixed. Understand. I see that this is not a time for such changes. Hope that the DT model will take into account such kind of situation in the future. Will it impact the devicetree bindings on rcar? No Regards, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: gpio-rcar: init at postcore level
Hi Magnus,
On 02/24/2014 06:57 AM, Magnus Damm wrote:
Hi Vladimir,
On Mon, Feb 24, 2014 at 1:37 AM, wrote:
From: Vladimir Barinov
This adds ability to use gpio API at board init_machine level.
F.e. it can be used in the following situation.
Many reference hardware has onboard switches that selects which periferals
to connect to the system. The gpio input state from switches can be used
in choosing platform devices runtime in board code instead of ifdefs/defconfig
changes.
Signed-off-by:
---
drivers/gpio/gpio-rcar.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
Index: build/drivers/gpio/gpio-rcar.c
===
--- build.orig/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:51.456229152 +0400
+++ build/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:52.320229133 +0400
@@ -485,7 +485,17 @@
}
};
-module_platform_driver(gpio_rcar_device_driver);
+static int __init gpio_rcar_init(void)
+{
+ return platform_driver_register(&gpio_rcar_device_driver);
+}
+postcore_initcall(gpio_rcar_init);
+
+static void __exit gpio_rcar_exit(void)
+{
+ platform_driver_unregister(&gpio_rcar_device_driver);
+}
+module_exit(gpio_rcar_exit);
MODULE_AUTHOR("Magnus Damm");
MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");
Hi Vladimir,
Thanks for your help. Good to see that you are working on enabling the
dual role USB port on Koelsch.
Your current board code is checking some DIP switch value during boot,
and that kind of early use of GPIO would require a change in the probe
order like this patch implements. I do however believe that we should
not implement checking during boot like this.
If you for instance check the legacy Lager USBHS DIP switch code that
runs during driver probe() then that can run can use GPIO without the
need for a change like this. So your GPIO user code needs to be
adjusted.
Yes, this is true for USBHS that has platform callbacks like
hardware_init/exit.
But this is not acceptable for other devices like EHCI PCI/PHY and others.
So we wouldn't be able to do such fixup for other cases.
So this patch will receive a NAK from me I'm afraid.
Thank you for review.
Regards,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] Cpuidle: Do not substract exit latency from assumed sleep length
The menu governor statistics update function tries to determine the
amount of time between entry to low power state and the occurrence
of the wakeup event. However, the time measured by the framework
includes exit latency on top of the desired value. This exit latency
is substracted from the measured value to obtain the desired value.
When measured value is not available, the menu governor assumes
the wakeup was caused by the timer and the time is equal to remaining
timer length. No exit latency should be substracted from this value.
This patch prevents the erroneous substraction and clarifies the
associated comment. It also removes one intermediate variable that
serves no purpose.
Signed-off-by: Tuukka Tikkanen
---
drivers/cpuidle/governors/menu.c | 44 ++
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index f0995dd..b347c10 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -387,32 +387,40 @@ static void menu_update(struct cpuidle_driver *drv,
struct cpuidle_device *dev)
{
struct menu_device *data = &__get_cpu_var(menu_devices);
int last_idx = data->last_state_idx;
- unsigned int last_idle_us = cpuidle_get_last_residency(dev);
struct cpuidle_state *target = &drv->states[last_idx];
unsigned int measured_us;
unsigned int new_factor;
/*
-* Ugh, this idle state doesn't support residency measurements, so we
-* are basically lost in the dark. As a compromise, assume we slept
-* for the whole expected time.
+* Try to figure out how much time passed between entry to low
+* power state and occurrence of the wakeup event.
+*
+* If the entered idle state didn't support residency measurements,
+* we are basically lost in the dark how much time passed.
+* As a compromise, assume we slept for the whole expected time.
+*
+* Any measured amount of time will include the exit latency.
+* Since we are interested in when the wakeup begun, not when it
+* was completed, we must substract the exit latency. However, if
+* the measured amount of time is less than the exit latency,
+* assume the state was never reached and the exit latency is 0.
*/
- if (unlikely(!(target->flags & CPUIDLE_FLAG_TIME_VALID)))
- last_idle_us = data->next_timer_us;
-
+ if (unlikely(!(target->flags & CPUIDLE_FLAG_TIME_VALID))) {
+ /* Use timer value as is */
+ measured_us = data->next_timer_us;
- measured_us = last_idle_us;
+ } else {
+ /* Use measured value */
+ measured_us = cpuidle_get_last_residency(dev);
- /*
-* We correct for the exit latency; we are assuming here that the
-* exit latency happens after the event that we're interested in.
-*/
- if (measured_us > target->exit_latency)
- measured_us -= target->exit_latency;
+ /* Deduct exit latency */
+ if (measured_us > target->exit_latency)
+ measured_us -= target->exit_latency;
- /* Make sure our coefficients do not exceed unity */
- if (measured_us > data->next_timer_us)
- measured_us = data->next_timer_us;
+ /* Make sure our coefficients do not exceed unity */
+ if (measured_us > data->next_timer_us)
+ measured_us = data->next_timer_us;
+ }
/* Update our correction ratio */
new_factor = data->correction_factor[data->bucket];
@@ -439,7 +447,7 @@ static void menu_update(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
data->correction_factor[data->bucket] = new_factor;
/* update the repeating-pattern data */
- data->intervals[data->interval_ptr++] = last_idle_us;
+ data->intervals[data->interval_ptr++] = measured_us;
if (data->interval_ptr >= INTERVALS)
data->interval_ptr = 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] usb: gadget: gr_udc: Make struct platform_device variable name clearer
On 2014-02-18 16:52, Felipe Balbi wrote:
On Thu, Jan 09, 2014 at 11:54:13AM +0100, Andreas Larsson wrote:
Rename struct platform_device pointers from ofdev to pdev for clarity.
Suggested by Mark Rutland.
Signed-off-by: Andreas Larsson
---
drivers/usb/gadget/gr_udc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
index 914cbd8..e66dcf0 100644
--- a/drivers/usb/gadget/gr_udc.c
+++ b/drivers/usb/gadget/gr_udc.c
@@ -2071,9 +2071,9 @@ static int gr_udc_init(struct gr_udc *dev)
return 0;
}
-static int gr_remove(struct platform_device *ofdev)
+static int gr_remove(struct platform_device *pdev)
{
- struct gr_udc *dev = dev_get_drvdata(&ofdev->dev);
+ struct gr_udc *dev = dev_get_drvdata(&pdev->dev);
you can use platform_get_drvdata()
@@ -2083,7 +2083,7 @@ static int gr_remove(struct platform_device *ofdev)
gr_dfs_delete(dev);
if (dev->desc_pool)
dma_pool_destroy(dev->desc_pool);
- dev_set_drvdata(&ofdev->dev, NULL);
+ dev_set_drvdata(&pdev->dev, NULL);
and platform_set_drvdata()
Yes, but wouldn't that be better handled in a separate patch?
Best regards,
Andreas Larsson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] Cpuidle: Deal with timer expiring in the past
Sometimes (fairly often) when the cpuidle menu governor is making a decision about idle state to enter the next timer for the cpu appears to expire in the past. The menu governor expects the expiry to always be in the future and in fact stores the time delta in an unsigned variable. However, when the expiry is in the past, the value returned by tick_nohz_get_sleep_length can be negative. This patch prevents using negative values, instead making the governor return immediately similar to having latency requirement set to 0. Note: As with latency == 0, the return value is 0 with no check to see if the state 0 has been disabled or not. Signed-off-by: Tuukka Tikkanen --- drivers/cpuidle/governors/menu.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index 71b5232..c414468 100644 --- a/drivers/cpuidle/governors/menu.c +++ b/drivers/cpuidle/governors/menu.c @@ -302,8 +302,16 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev) if (unlikely(latency_req == 0)) return 0; - /* determine the expected residency time, round up */ + /* +* Determine the expected residency time. If the time is negative, +* a timer interrupt has probably just expired after disabling +* interrupts. Return as quickly as possible in the most shallow +* state possible. tv_nsec is always positive, so only check the +* seconds. +*/ t = ktime_to_timespec(tick_nohz_get_sleep_length()); + if (t.tv_sec < 0) + return 0; data->next_timer_us = t.tv_sec * USEC_PER_SEC + t.tv_nsec / NSEC_PER_USEC; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/10] spi: sh-msiof: Add support for R-Car H2 and M2
Hi Magnus,
On Mon, Feb 24, 2014 at 3:45 AM, Magnus Damm wrote:
> On Fri, Feb 21, 2014 at 1:13 AM, Geert Uytterhoeven
> wrote:
>> On Thu, Feb 20, 2014 at 4:41 PM, Magnus Damm wrote:
>>> On thing stuck out a bit with the bindings. I can see that you specify
>>> both fifo size and use the SoC suffix for the r8a7790 and r8a7791
>>> bindings. Isn't that a bit of redundant information there, if we know
>>> that the SoC is r8a7790 or r8a7791 then can't we simply put that
>>> information in r8a779x_data above and perhaps keep the binding
>>> simpler? Perhaps same thing applies to other properties as well?
>>
>> "renesas,tx-fifo-size" and "renesas,rx-fifo-size" are part of the existing
>> bindings, so I'm a bit reluctant to change these.
>> Hmm, since the original bindings didn't specify the default values,
>> I could make them chip-specific, though.
>
> Thanks, yes I think treating the "renesas,tx-fifo-size" and
> "renesas,rx-fifo-size" bindings as optional and allow us to rely on
> chip-specific default values makes sense.
>
>> The only other property is "num-cs", which can have any value if you
>> start using the generic "cs-gpios".
>
> I see. It looks to me that such a setting is board-specific, so what
> is a sane default in the SoC DTSI? You seem to have it set to "1"
> today, but if the board is supposed to override it anyway then do we
> need to set it?
>
> Anyway, "num-cs" is a minor detail so no need to bother about that too much!
In v2, I'll drop the "num-cs" from the dtsi, so it will default to the driver's
default (which is 1, for the simple case of using hardware controlled CS).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: comedi: Fix coding style issue in poc.c This is a patch to remove unneccessary space after function pointer name found with checkpatch.pl
Leave a blank line between the subject and the body of the changelog. The signed-off-by line is missing. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 3/4] ARM: shmobile: koelsch: Add USBHS and internal PCI USB support
Hello Magnus,
Thank you for the quick response.
On 02/24/2014 07:52 AM, Magnus Damm wrote:
+static int usbhs_hardware_init(struct platform_device *pdev)
+{
+ struct usbhs_private *priv = usbhs_get_priv(pdev);
+ struct usb_phy *phy;
+
+ phy = usb_get_phy_dev(&pdev->dev, 0);
+ if (IS_ERR(phy))
+ return PTR_ERR(phy);
+
+ priv->phy = phy;
+ return 0;
+}
+
+static int usbhs_hardware_exit(struct platform_device *pdev)
+{
+ struct usbhs_private *priv = usbhs_get_priv(pdev);
+
+ if (!priv->phy)
+ return 0;
+
+ usb_put_phy(priv->phy);
+ priv->phy = NULL;
+ return 0;
+}
+
+static int usbhs_get_id(struct platform_device *pdev)
+{
+ return USBHS_GADGET;
+}
Uhm, I sort of expected this place to be where you read out the ID pin
state from the MAX device.
Yes, I've seen your work for lager board.
I did differently then you beacause of problem in USBHS Host driver,
hence the need of setup PHY at initial stage to PCI USB and not to USBHS.
+static u32 koelsch_usbhs_pipe_type[] = {
+
+/* Add all available USB devices */
+static void __init koelsch_add_usb_devices(void)
+{
+ /* MAX3355E ID pin */
+ gpio_request_one(RCAR_GP_PIN(5, 31), GPIOF_IN, NULL);
+ if (!gpio_get_value(RCAR_GP_PIN(5, 31))) {
+ usbhs_phy_pdata.chan0_pci = 1; /* Channel 0 is PCI USB host */
+ koelsch_add_usb0_host();
+ } else {
+ usbhs_phy_pdata.chan0_pci = 0; /* Channel 0 is USBHS */
+ koelsch_add_usb0_gadget();
+ }
I don't think we should perform this kind of check at boot-up. This
goes without saying, but normal USB supports hot-plug so we should
check the cable type when the cable insertion event happens. Please
see my comment above for USBHS-specific location.
I do however understand that according to your investigation you
cannot use USBHS in host mode. I believe further investigation is
needed in that area to determine what is the best way forward.
Regarding VBUS control, I believe it should be possible to drive the
USB0_VBUS as GPIO and manually control the power.
I see.
Would it be possible for you to break out USB PCI support for USB1 and
resend that so we can begin by merging that?
Wouldn't you like me also add USBHS in gadget mode for USB0 with the
similar check like you did on lager (with ID pin),
since it does not need the gpio-rcar changes too.
Also if you'd like I can add the USBHS in Host mode with the ID pin
check like you suggested, but the usb0 host will not be stable.
Probably this could speed up the USBHS Host development/fixing.
Regards,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] avr32: remove cpu_data macro to fix compiles
Around Sat 22 Feb 2014 09:28:27 +0100 or thereabout, Wolfram Sang wrote:
> Having cpu_data as a parameterless macro can easily cause build failures
> because it can be a variable name like in linux/pm_domain.h [1]. So,
> remove the macro and convert its only user. Because this architecture
> cannot do SMP, remove the whole SMP block, too. Only compile tested due
> to no hardware.
Looks sane, AVR32 doesn't support SMP, so this change should be fine.
> Signed-off-by: Wolfram Sang
>
Acked-by: Hans-Christian Egtvedt
> [1] https://lists.01.org/pipermail/kbuild-all/2014-February/003252.html
>
clockevents/3.15 branch, mens what you have queued up for 3.15?
I can queue this in my linux-next, and send Linus an early pull request the
moment 3.14 is released.
> ---
>
> arch/avr32/include/asm/bugs.h | 2 +-
> arch/avr32/include/asm/processor.h | 7 +--
> 2 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/arch/avr32/include/asm/bugs.h b/arch/avr32/include/asm/bugs.h
> index 7635e77..278661b 100644
> --- a/arch/avr32/include/asm/bugs.h
> +++ b/arch/avr32/include/asm/bugs.h
> @@ -9,7 +9,7 @@
>
> static void __init check_bugs(void)
> {
> - cpu_data->loops_per_jiffy = loops_per_jiffy;
> + boot_cpu_data.loops_per_jiffy = loops_per_jiffy;
> }
>
> #endif /* __ASM_AVR32_BUGS_H */
> diff --git a/arch/avr32/include/asm/processor.h
> b/arch/avr32/include/asm/processor.h
> index 48d71c5..972adcc 100644
> --- a/arch/avr32/include/asm/processor.h
> +++ b/arch/avr32/include/asm/processor.h
> @@ -83,13 +83,8 @@ static inline unsigned int avr32_get_chip_revision(struct
> avr32_cpuinfo *cpu)
>
> extern struct avr32_cpuinfo boot_cpu_data;
>
> -#ifdef CONFIG_SMP
> -extern struct avr32_cpuinfo cpu_data[];
> -#define current_cpu_data cpu_data[smp_processor_id()]
> -#else
> -#define cpu_data (&boot_cpu_data)
> +/* No SMP support so far */
> #define current_cpu_data boot_cpu_data
> -#endif
>
> /* This decides where the kernel will search for a free chunk of vm
> * space during mmap's
--
mvh
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] f2fs: implement a lock-free stat_show
The stat_show is just to show the current status of f2fs.
So, we can remove all the there-in locks.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/debug.c | 3 ---
fs/f2fs/f2fs.h| 18 +++---
fs/f2fs/segment.h | 27 +++
3 files changed, 6 insertions(+), 42 deletions(-)
diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index 46a12e4..b7111c4 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -86,7 +86,6 @@ static void update_sit_info(struct f2fs_sb_info *sbi)
{
struct f2fs_stat_info *si = F2FS_STAT(sbi);
unsigned int blks_per_sec, hblks_per_sec, total_vblocks, bimodal, dist;
- struct sit_info *sit_i = SIT_I(sbi);
unsigned int segno, vblocks;
int ndirty = 0;
@@ -94,7 +93,6 @@ static void update_sit_info(struct f2fs_sb_info *sbi)
total_vblocks = 0;
blks_per_sec = sbi->segs_per_sec * (1 << sbi->log_blocks_per_seg);
hblks_per_sec = blks_per_sec / 2;
- mutex_lock(&sit_i->sentry_lock);
for (segno = 0; segno < TOTAL_SEGS(sbi); segno += sbi->segs_per_sec) {
vblocks = get_valid_blocks(sbi, segno, sbi->segs_per_sec);
dist = abs(vblocks - hblks_per_sec);
@@ -105,7 +103,6 @@ static void update_sit_info(struct f2fs_sb_info *sbi)
ndirty++;
}
}
- mutex_unlock(&sit_i->sentry_lock);
dist = TOTAL_SECS(sbi) * hblks_per_sec * hblks_per_sec / 100;
si->bimodal = bimodal / dist;
if (si->dirty_count)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 11fd8be..4beedcc 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -704,11 +704,7 @@ static inline int get_blocktype_secs(struct f2fs_sb_info
*sbi, int block_type)
static inline block_t valid_user_blocks(struct f2fs_sb_info *sbi)
{
- block_t ret;
- spin_lock(&sbi->stat_lock);
- ret = sbi->total_valid_block_count;
- spin_unlock(&sbi->stat_lock);
- return ret;
+ return sbi->total_valid_block_count;
}
static inline unsigned long __bitmap_size(struct f2fs_sb_info *sbi, int flag)
@@ -804,11 +800,7 @@ static inline void dec_valid_node_count(struct
f2fs_sb_info *sbi,
static inline unsigned int valid_node_count(struct f2fs_sb_info *sbi)
{
- unsigned int ret;
- spin_lock(&sbi->stat_lock);
- ret = sbi->total_valid_node_count;
- spin_unlock(&sbi->stat_lock);
- return ret;
+ return sbi->total_valid_node_count;
}
static inline void inc_valid_inode_count(struct f2fs_sb_info *sbi)
@@ -829,11 +821,7 @@ static inline void dec_valid_inode_count(struct
f2fs_sb_info *sbi)
static inline unsigned int valid_inode_count(struct f2fs_sb_info *sbi)
{
- unsigned int ret;
- spin_lock(&sbi->stat_lock);
- ret = sbi->total_valid_inode_count;
- spin_unlock(&sbi->stat_lock);
- return ret;
+ return sbi->total_valid_inode_count;
}
static inline void f2fs_put_page(struct page *page, int unlock)
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 4024546..c3d5e36 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -380,26 +380,12 @@ static inline void get_sit_bitmap(struct f2fs_sb_info
*sbi,
static inline block_t written_block_count(struct f2fs_sb_info *sbi)
{
- struct sit_info *sit_i = SIT_I(sbi);
- block_t vblocks;
-
- mutex_lock(&sit_i->sentry_lock);
- vblocks = sit_i->written_valid_blocks;
- mutex_unlock(&sit_i->sentry_lock);
-
- return vblocks;
+ return SIT_I(sbi)->written_valid_blocks;
}
static inline unsigned int free_segments(struct f2fs_sb_info *sbi)
{
- struct free_segmap_info *free_i = FREE_I(sbi);
- unsigned int free_segs;
-
- read_lock(&free_i->segmap_lock);
- free_segs = free_i->free_segments;
- read_unlock(&free_i->segmap_lock);
-
- return free_segs;
+ return FREE_I(sbi)->free_segments;
}
static inline int reserved_segments(struct f2fs_sb_info *sbi)
@@ -409,14 +395,7 @@ static inline int reserved_segments(struct f2fs_sb_info
*sbi)
static inline unsigned int free_sections(struct f2fs_sb_info *sbi)
{
- struct free_segmap_info *free_i = FREE_I(sbi);
- unsigned int free_secs;
-
- read_lock(&free_i->segmap_lock);
- free_secs = free_i->free_sections;
- read_unlock(&free_i->segmap_lock);
-
- return free_secs;
+ return FREE_I(sbi)->free_sections;
}
static inline unsigned int prefree_segments(struct f2fs_sb_info *sbi)
--
1.8.4.474.g128a96c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] f2fs: introduce a radix_tree for the free_nid list
This patch introduces a radix tree for the list of free_nids, which enhances
the performance on free nid management.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/f2fs.h | 1 +
fs/f2fs/node.c | 36 +---
2 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index c56e67b..11fd8be 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -247,6 +247,7 @@ struct f2fs_nm_info {
struct list_head dirty_nat_entries; /* cached nat entry list (dirty) */
/* free node ids management */
+ struct radix_tree_root free_nid_root;/* root of the free_nid cache */
struct list_head free_nid_list; /* a list for free nids */
spinlock_t free_nid_list_lock; /* protect free nid list */
unsigned int fcnt; /* the number of free node id */
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 431bcb4..1f9cf21 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1269,21 +1269,17 @@ const struct address_space_operations f2fs_node_aops = {
.releasepage= f2fs_release_node_page,
};
-static struct free_nid *__lookup_free_nid_list(nid_t n, struct list_head *head)
+static struct free_nid *__lookup_free_nid_list(struct f2fs_nm_info *nm_i,
+ nid_t n)
{
- struct list_head *this;
- struct free_nid *i;
- list_for_each(this, head) {
- i = list_entry(this, struct free_nid, list);
- if (i->nid == n)
- return i;
- }
- return NULL;
+ return radix_tree_lookup(&nm_i->free_nid_root, n);
}
-static void __del_from_free_nid_list(struct free_nid *i)
+static void __del_from_free_nid_list(struct f2fs_nm_info *nm_i,
+ struct free_nid *i)
{
list_del(&i->list);
+ radix_tree_delete(&nm_i->free_nid_root, i->nid);
kmem_cache_free(free_nid_slab, i);
}
@@ -1304,7 +1300,8 @@ static int add_free_nid(struct f2fs_nm_info *nm_i, nid_t
nid, bool build)
/* do not add allocated nids */
read_lock(&nm_i->nat_tree_lock);
ne = __lookup_nat_cache(nm_i, nid);
- if (ne && nat_get_blkaddr(ne) != NULL_ADDR)
+ if (ne &&
+ (!ne->checkpointed || nat_get_blkaddr(ne) != NULL_ADDR))
allocated = true;
read_unlock(&nm_i->nat_tree_lock);
if (allocated)
@@ -1316,7 +1313,7 @@ static int add_free_nid(struct f2fs_nm_info *nm_i, nid_t
nid, bool build)
i->state = NID_NEW;
spin_lock(&nm_i->free_nid_list_lock);
- if (__lookup_free_nid_list(nid, &nm_i->free_nid_list)) {
+ if (radix_tree_insert(&nm_i->free_nid_root, i->nid, i)) {
spin_unlock(&nm_i->free_nid_list_lock);
kmem_cache_free(free_nid_slab, i);
return 0;
@@ -1331,9 +1328,9 @@ static void remove_free_nid(struct f2fs_nm_info *nm_i,
nid_t nid)
{
struct free_nid *i;
spin_lock(&nm_i->free_nid_list_lock);
- i = __lookup_free_nid_list(nid, &nm_i->free_nid_list);
+ i = __lookup_free_nid_list(nm_i, nid);
if (i && i->state == NID_NEW) {
- __del_from_free_nid_list(i);
+ __del_from_free_nid_list(nm_i, i);
nm_i->fcnt--;
}
spin_unlock(&nm_i->free_nid_list_lock);
@@ -1457,9 +1454,9 @@ void alloc_nid_done(struct f2fs_sb_info *sbi, nid_t nid)
struct free_nid *i;
spin_lock(&nm_i->free_nid_list_lock);
- i = __lookup_free_nid_list(nid, &nm_i->free_nid_list);
+ i = __lookup_free_nid_list(nm_i, nid);
f2fs_bug_on(!i || i->state != NID_ALLOC);
- __del_from_free_nid_list(i);
+ __del_from_free_nid_list(nm_i, i);
spin_unlock(&nm_i->free_nid_list_lock);
}
@@ -1475,10 +1472,10 @@ void alloc_nid_failed(struct f2fs_sb_info *sbi, nid_t
nid)
return;
spin_lock(&nm_i->free_nid_list_lock);
- i = __lookup_free_nid_list(nid, &nm_i->free_nid_list);
+ i = __lookup_free_nid_list(nm_i, nid);
f2fs_bug_on(!i || i->state != NID_ALLOC);
if (nm_i->fcnt > 2 * MAX_FREE_NIDS) {
- __del_from_free_nid_list(i);
+ __del_from_free_nid_list(nm_i, i);
} else {
i->state = NID_NEW;
nm_i->fcnt++;
@@ -1812,6 +1809,7 @@ static int init_node_manager(struct f2fs_sb_info *sbi)
nm_i->fcnt = 0;
nm_i->nat_cnt = 0;
+ INIT_RADIX_TREE(&nm_i->free_nid_root, GFP_ATOMIC);
INIT_LIST_HEAD(&nm_i->free_nid_list);
INIT_RADIX_TREE(&nm_i->nat_root, GFP_ATOMIC);
INIT_LIST_HEAD(&nm_i->nat_entries);
@@ -1865,7 +1863,7 @@ void destroy_node_manager(struct f2fs_sb_info *sbi)
spin_lock(&nm_i->free_nid_list_lock);
list_for_each_entry_safe(i, next_i, &nm_i->free_nid_list, list) {
f2fs_bug_on(i->state == NID
[PATCH] PM / devfreq: Fix out of bounds access of transition table array
The previous_freq value for a device could be an invalid frequency that
results in a error value being returned from devfreq_get_freq_level().
Check for an error value before using that to index into the transition
table.
Not doing this check will result in memory corruption when previous_freq is
not a valid frequency.
Signed-off-by: Saravana Kannan
---
drivers/devfreq/devfreq.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index a0b2f7e..f91ea29 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -101,14 +101,20 @@ static int devfreq_update_status(struct devfreq *devfreq,
unsigned long freq)
cur_time = jiffies;
devfreq->time_in_state[lev] +=
cur_time - devfreq->last_stat_updated;
- if (freq != devfreq->previous_freq) {
- prev_lev = devfreq_get_freq_level(devfreq,
- devfreq->previous_freq);
+ devfreq->last_stat_updated = cur_time;
+
+ if (freq == devfreq->previous_freq)
+ return 0;
+
+ prev_lev = devfreq_get_freq_level(devfreq, devfreq->previous_freq);
+ if (prev_lev < 0)
+ return 0;
+
+ if (lev != prev_lev) {
devfreq->trans_table[(prev_lev *
devfreq->profile->max_state) + lev]++;
devfreq->total_trans++;
}
- devfreq->last_stat_updated = cur_time;
return 0;
}
--
1.8.2.1
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/14] perf, x86: Haswell LBR call stack support
Your patches still only have 3-4 lines of Changelog, I'll continue ignoring them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Thermal: Allow first update of cooling device state
Hi, Rui Do you have any comment for it ? Thanks. Wei. On 02/17/2014 11:02 AM, Wei Ni wrote: > In initialization, if the cooling device is initialized at > max cooling state, and the thermal zone temperature is below > the first trip point, then the cooling state can't be updated > to the right state, untill the first trip point be triggered. > > To fix this issue, allow first update of cooling device state > during registration, initialized "updated" device field as > "false" (instead of "true"). > > Signed-off-by: Wei Ni > --- > drivers/thermal/thermal_core.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c > index 338a88b..02f57af 100644 > --- a/drivers/thermal/thermal_core.c > +++ b/drivers/thermal/thermal_core.c > @@ -1107,7 +1107,7 @@ __thermal_cooling_device_register(struct device_node > *np, > INIT_LIST_HEAD(&cdev->thermal_instances); > cdev->np = np; > cdev->ops = ops; > - cdev->updated = true; > + cdev->updated = false; > cdev->device.class = &thermal_class; > cdev->devdata = devdata; > dev_set_name(&cdev->device, "cooling_device%d", cdev->id); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:sched/core] sched, nohz: Exclude isolated cores from load balancing
On Mon, Feb 24, 2014 at 3:07 PM, Peter Zijlstra wrote: > On Mon, Feb 24, 2014 at 10:11:05AM +0800, Lei Wen wrote: >> How about use the API as cpumask_test_and_clear_cpu? >> Then below one line is enough. > > Its more expensive. > I see... No problem for me then. Acked-by: Lei Wen Thanks, Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched: hang in migrate_swap
On Mon, Feb 24, 2014 at 01:19:15PM +0800, Michael wang wrote: > Peter, do we accidentally missed this commit? > > http://git.kernel.org/tip/477af336ba06ef4c32e97892bb0d2027ce30f466 Ingo dropped it on Saturday because it makes locking_selftest() unhappy. That is because we call locking_selftest() way before we're ready to call schedule() and guess what it does :-/ I'm not entirely sure what to do.. ideally I'd shoot locking_selftest in the head, but clearly that's not entirely desired either. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v1 2/3] Fix hibernation restore hang in freeze_processes
On Wed, Feb 19, 2014 at 9:52 AM, Sebastian Capella wrote: > During restore, pm_notifier chain are called with > PM_RESTORE_PREPARE. The firmware_class driver handler > fw_pm_notify does not have a handler for this. As a result, > it keeps a reader on the kmod.c umhelper_sem. During > freeze_processes, the call to __usermodehelper_disable tries to > take a write lock on this semaphore and hangs waiting. > > Signed-off-by: Sebastian Capella > Cc: Russ Dill > Cc: Ming Lei > Cc: Greg Kroah-Hartman Acked-by: Ming Lei Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:sched/core] sched, nohz: Exclude isolated cores from load balancing
On Mon, Feb 24, 2014 at 10:11:05AM +0800, Lei Wen wrote: > How about use the API as cpumask_test_and_clear_cpu? > Then below one line is enough. Its more expensive. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sdhci: Add a quirk to disable write-protect
When a board does not have the WP line wired at all, the card
may be detected as read-only. Add a quirk and a device property
to disable WP detection.
Signed-off-by: Mike Looijmans
---
drivers/mmc/host/sdhci-pltfm.c |3 +++
drivers/mmc/host/sdhci.c |3 ++-
include/linux/mmc/sdhci.h |2 ++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index e2065a4..9e83ada 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -83,6 +83,9 @@ void sdhci_get_of_property(struct platform_device *pdev)
if (sdhci_of_wp_inverted(np))
host->quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
+ if (of_get_property(np, "disable-wp", NULL))
+ host->quirks2 |= SDHCI_QUIRK2_DISABLE_WP;
+
if (of_get_property(np, "broken-cd", NULL))
host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7a7fb4f..68f47fc 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1635,7 +1635,8 @@ static int sdhci_check_ro(struct sdhci_host *host)
spin_lock_irqsave(&host->lock, flags);
- if (host->flags & SDHCI_DEVICE_DEAD)
+ if ((host->flags & SDHCI_DEVICE_DEAD) ||
+ (host->quirks2 & SDHCI_QUIRK2_DISABLE_WP))
is_readonly = 0;
else if (host->ops->get_ro)
is_readonly = host->ops->get_ro(host);
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 3e781b8..967dba0 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -98,6 +98,8 @@ struct sdhci_host {
#define SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON (1<<4)
/* Controller has a non-standard host control register */
#define SDHCI_QUIRK2_BROKEN_HOST_CONTROL (1<<5)
+/* Controller lacks write protect detection */
+#define SDHCI_QUIRK2_DISABLE_WP(1<<6)
int irq;/* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: Set policy to non-NULL only after all hotplug online work is done
The existing code sets the per CPU policy to a non-NULL value before all
the steps performed during the hotplug online path is done. Specifically,
this is done before the policy min/max, governors, etc are initialized for
the policy. This in turn means that calls to cpufreq_cpu_get() return a
non-NULL policy before the policy/CPU is ready to be used.
To fix this, move the update of per CPU policy to a valid value after all
the initialization steps for the policy are completed.
Example kernel panic without this fix:
[ 512.146185] Unable to handle kernel NULL pointer dereference at virtual
address 0020
[ 512.146195] pgd = c0003000
[ 512.146213] [0020] *pgd=804003, *pmd=
[ 512.146228] Internal error: Oops: 206 [#1] PREEMPT SMP ARM
[ 512.146297] PC is at __cpufreq_governor+0x10/0x1ac
[ 512.146312] LR is at cpufreq_update_policy+0x114/0x150
[ 512.149740] ---[ end trace f23a8defea6cd706 ]---
[ 512.149761] Kernel panic - not syncing: Fatal exception
[ 513.152016] CPU0: stopping
[ 513.154710] CPU: 0 PID: 7136 Comm: mpdecision Tainted: G D W
3.10.0-gd727407-00074-g979ede8 #396
[ 513.317224] [] (notifier_call_chain+0x40/0x68) from []
(__blocking_notifier_call_chain+0x40/0x58)
[ 513.327809] [] (__blocking_notifier_call_chain+0x40/0x58) from
[] (blocking_notifier_call_chain+0x14/0x1c)
[ 513.339182] [] (blocking_notifier_call_chain+0x14/0x1c) from
[] (cpufreq_set_policy+0xd4/0x2b8)
[ 513.349594] [] (cpufreq_set_policy+0xd4/0x2b8) from []
(cpufreq_init_policy+0x30/0x98)
[ 513.359231] [] (cpufreq_init_policy+0x30/0x98) from []
(__cpufreq_add_dev.isra.17+0x4dc/0x7a4)
[ 513.369560] [] (__cpufreq_add_dev.isra.17+0x4dc/0x7a4) from
[] (cpufreq_cpu_callback+0x58/0x84)
[ 513.379978] [] (cpufreq_cpu_callback+0x58/0x84) from []
(notifier_call_chain+0x40/0x68)
[ 513.389704] [] (notifier_call_chain+0x40/0x68) from []
(__cpu_notify+0x28/0x44)
[ 513.398728] [] (__cpu_notify+0x28/0x44) from []
(_cpu_up+0xf4/0x1dc)
[ 513.406797] [] (_cpu_up+0xf4/0x1dc) from []
(cpu_up+0x5c/0x78)
[ 513.414357] [] (cpu_up+0x5c/0x78) from []
(store_online+0x44/0x74)
[ 513.422253] [] (store_online+0x44/0x74) from []
(sysfs_write_file+0x108/0x14c)
[ 513.431195] [] (sysfs_write_file+0x108/0x14c) from []
(vfs_write+0xd0/0x180)
[ 513.439958] [] (vfs_write+0xd0/0x180) from []
(SyS_write+0x38/0x68)
[ 513.447947] [] (SyS_write+0x38/0x68) from []
(ret_fast_syscall+0x0/0x30)
In this specific case, CPU0 set's CPU1's policy->governor in
cpufreq_init_policy() to NULL while CPU1 is using the policy->governor in
__cpufreq_governor().
Signed-off-by: Saravana Kannan
---
drivers/cpufreq/cpufreq.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index cb003a6..d5ceb43 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1109,11 +1109,6 @@ static int __cpufreq_add_dev(struct device *dev, struct
subsys_interface *sif,
goto err_set_policy_cpu;
}
- write_lock_irqsave(&cpufreq_driver_lock, flags);
- for_each_cpu(j, policy->cpus)
- per_cpu(cpufreq_cpu_data, j) = policy;
- write_unlock_irqrestore(&cpufreq_driver_lock, flags);
-
if (cpufreq_driver->get) {
policy->cur = cpufreq_driver->get(policy->cpu);
if (!policy->cur) {
@@ -1207,6 +1202,11 @@ static int __cpufreq_add_dev(struct device *dev, struct
subsys_interface *sif,
policy->user_policy.governor = policy->governor;
}
+ write_lock_irqsave(&cpufreq_driver_lock, flags);
+ for_each_cpu(j, policy->cpus)
+ per_cpu(cpufreq_cpu_data, j) = policy;
+ write_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
kobject_uevent(&policy->kobj, KOBJ_ADD);
up_read(&cpufreq_rwsem);
--
1.8.2.1
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/5] ACPI / processor_core: Rework _PDC related stuff to make it more arch-independent
On 2014-2-22 18:33, Catalin Marinas wrote: > On 21 Feb 2014, at 23:35, Rafael J. Wysocki wrote: >> On Friday, February 21, 2014 06:24:24 PM Catalin Marinas wrote: >>> On Wed, Feb 19, 2014 at 01:50:22AM +0100, Rafael J. Wysocki wrote: On Wednesday, February 19, 2014 12:23:55 AM Hanjun Guo wrote: > _PDC related stuff in processor_core.c is little bit X86/IA64 dependent, > rework the code to make it more arch-independent, no functional change > in this patch. > > Signed-off-by: Hanjun Guo > Signed-off-by: Graeme Gregory I've queued up patches [1,3-5/5] from this series for 3.15 (modulo changelog modifications), but this one should be CCed to the x86 and ia64 maintainers. >>> >>> Thanks for taking these patches. I would however hold onto patch 3/5 as >>> this is still under discussion. Basically for patches specific to ARM >>> ACPI I would really like to see more acks before being merged as that's >>> a new thing for us. >> >> OK, I'll drop [3/5] for now, then. > > Thanks (it’s only temporary ;)). > >> I'm wondering, though, whose ACKs I should be waiting for before applying >> those >> patches? > > Good question ;). In this particular case, there is an ongoing > discussion between Hanjun and Sudeep. While there isn’t anything > major, I would like to see some agreement and potentially an Ack from > the other party involved in the discussion (Sudeep). > > There are other patches that are not specific to ARM, so it’s > really your decision. As for the general ARM(64) ACPI case, I don’t > think we have anyone in charge with deciding what’s correct or not > (BTW, who are the people active both in the _ARM_ Linux kernel community > and the ACPI standardisation forum?). I'm in ASWG (ACPI spec working group) under UEFI, and Al Stone and Charles (+cc Charles) are also in this forum. Thanks Hanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ASoC: cs42888: Add codec driver support
This patch adds support for the Cirrus Logic CS42888 Audio CODEC that
has four 24-bit A/D and eight 24-bit D/A converters.
[ CS42888 supports both I2C and SPI control ports. As initial patch,
this patch only adds the support for I2C. ]
Signed-off-by: Nicolin Chen
---
.../devicetree/bindings/sound/cs42888.txt | 27 +
sound/soc/codecs/Kconfig | 5 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/cs42888.c | 552 +
sound/soc/codecs/cs42888.h | 209
5 files changed, 795 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/cs42888.txt
create mode 100644 sound/soc/codecs/cs42888.c
create mode 100644 sound/soc/codecs/cs42888.h
diff --git a/Documentation/devicetree/bindings/sound/cs42888.txt
b/Documentation/devicetree/bindings/sound/cs42888.txt
new file mode 100644
index 000..7736527
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cs42888.txt
@@ -0,0 +1,27 @@
+CS42888 audio CODEC
+
+Required properties:
+
+ - compatible : "cirrus,cs42888"
+
+ - reg : the I2C address of the device for I2C
+
+ - clocks : phandle to the clock source for MCLK
+
+ - clock-names : must contain "mclk".
+
+ - VA-supply, VD-supply, VLS-supply, VLC-supply: power supplies for the
device,
+as covered in Documentation/devicetree/bindings/regulator/regulator.txt
+
+Example:
+
+codec: cs42888@48 {
+ compatible = "cirrus,cs42888";
+ reg = <0x48>;
+ clocks = <&codec_mclk 0>;
+ clock-names = "mclk";
+ VA-supply = <®_audio>;
+ VD-supply = <®_audio>;
+ VLS-supply = <®_audio>;
+ VLC-supply = <®_audio>;
+};
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index f2383eb..3211488 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -44,6 +44,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_CS42L73 if I2C
select SND_SOC_CS4270 if I2C
select SND_SOC_CS4271 if SND_SOC_I2C_AND_SPI
+ select SND_SOC_CS42888 if I2C
select SND_SOC_CX20442 if TTY
select SND_SOC_DA7210 if I2C
select SND_SOC_DA7213 if I2C
@@ -300,6 +301,10 @@ config SND_SOC_CS4271
tristate "Cirrus Logic CS4271 CODEC"
depends on SND_SOC_I2C_AND_SPI
+config SND_SOC_CS42888
+ tristate "Cirrus Logic CS42888 CODEC"
+ depends on I2C
+
config SND_SOC_CX20442
tristate
depends on TTY
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 6af7a55..75fe757 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -30,6 +30,7 @@ snd-soc-cs42l52-objs := cs42l52.o
snd-soc-cs42l73-objs := cs42l73.o
snd-soc-cs4270-objs := cs4270.o
snd-soc-cs4271-objs := cs4271.o
+snd-soc-cs42888-objs := cs42888.o
snd-soc-cx20442-objs := cx20442.o
snd-soc-da7210-objs := da7210.o
snd-soc-da7213-objs := da7213.o
@@ -173,6 +174,7 @@ obj-$(CONFIG_SND_SOC_CS42L52) += snd-soc-cs42l52.o
obj-$(CONFIG_SND_SOC_CS42L73) += snd-soc-cs42l73.o
obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o
obj-$(CONFIG_SND_SOC_CS4271) += snd-soc-cs4271.o
+obj-$(CONFIG_SND_SOC_CS42888) += snd-soc-cs42888.o
obj-$(CONFIG_SND_SOC_CX20442) += snd-soc-cx20442.o
obj-$(CONFIG_SND_SOC_DA7210) += snd-soc-da7210.o
obj-$(CONFIG_SND_SOC_DA7213) += snd-soc-da7213.o
diff --git a/sound/soc/codecs/cs42888.c b/sound/soc/codecs/cs42888.c
new file mode 100644
index 000..8561a25
--- /dev/null
+++ b/sound/soc/codecs/cs42888.c
@@ -0,0 +1,552 @@
+/*
+ * Cirrus Logic CS42888 Audio CODEC Digital Audio Interface (DAI) driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ *
+ * Author: Nicolin Chen
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cs42888.h"
+
+#define CS42888_NUM_SUPPLIES 4
+static const char *cs42888_supply_names[CS42888_NUM_SUPPLIES] = {
+ "VA",
+ "VD",
+ "VLS",
+ "VLC",
+};
+
+#define CS42888_FORMATS(SNDRV_PCM_FMTBIT_S16_LE | \
+SNDRV_PCM_FMTBIT_S20_3LE | \
+SNDRV_PCM_FMTBIT_S24_LE | \
+SNDRV_PCM_FMTBIT_S32_LE)
+
+/* codec private data */
+struct cs42888_priv {
+ struct regulator_bulk_data supplies[CS42888_NUM_SUPPLIES];
+ struct regmap *regmap;
+ struct clk *clk;
+
+ bool slave_mode;
+ unsigned long sysclk;
+};
+
+/* -127.5dB to 0dB with step of 0.5dB */
+static const DECLARE_TLV_DB_SCALE(dac_tlv, -12750, 50, 1);
+/* -64dB to 24dB with step of 0.5dB */
+static const DECLARE_TLV_DB_SCALE(adc_tlv, -6400, 50, 0);
+
+static const char *cs42888_adc_single[] = { "Differential", "Single-Ended" };
+static const char *cs42888_szc[]
Re: [PATCH v5 3/5] ACPI / processor: Introduce map_gic_id() to get apic id from MADT or _MAT method
On 2014-2-22 19:30, Marc Zyngier wrote:
> On 2014-02-22 10:21, Hanjun Guo wrote:
>> On 2014-2-21 20:37, Sudeep Holla wrote:
>>> Hi Hanjun,
>>>
>>> (Adding MarcZ for his views on GIC)
>>>
>>> On 20/02/14 03:59, Hanjun Guo wrote:
Hi Sudeep,
Thanks for your comments, please refer to the replies below. :)
On 2014年02月19日 22:33, Sudeep Holla wrote:
> Hi Hanjun,
>
> On 18/02/14 16:23, Hanjun Guo wrote:
>> Get apic id from MADT or _MAT method is not implemented on arm/arm64,
>> and ACPI 5.0 introduces GIC Structure for it, so this patch introduces
>> map_gic_id() to get apic id followed the ACPI 5.0 spec.
>>
>> Signed-off-by: Hanjun Guo
>> ---
>> drivers/acpi/processor_core.c | 26 ++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/drivers/acpi/processor_core.c
>> b/drivers/acpi/processor_core.c
>> index 4dcf776..d316d9b 100644
>> --- a/drivers/acpi/processor_core.c
>> +++ b/drivers/acpi/processor_core.c
>> @@ -71,6 +71,27 @@ static int map_lsapic_id(struct acpi_subtable_header
>> *entry,
>> return 0;
>> }
>>
>> +static int map_gic_id(struct acpi_subtable_header *entry,
>> +int device_declaration, u32 acpi_id, int *apic_id)
>> +{
>> +struct acpi_madt_generic_interrupt *gic =
>> +(struct acpi_madt_generic_interrupt *)entry;
>> +
>> +if (!(gic->flags & ACPI_MADT_ENABLED))
>> +return -ENODEV;
>> +
>> +/* In the GIC interrupt model, logical processors are
>> + * required to have a Processor Device object in the DSDT,
>> + * so we should check device_declaration here
>> + */
>> +if (device_declaration && (gic->uid == acpi_id)) {
>> +*apic_id = gic->gic_id;
> I have mentioned this earlier, it's not clear yet to me how does this
> work ?
> It needs more clarity in the form of comment here at-least as the
> ACPIv5.0 is
> also not so clear or explicit on how to handle this.
Yes, I noticed your comments and had a reply for that, after a
long consideration for this, I would withdraw my previous comments
before, please refer to the comments below.
>
> Here you are expecting gic->uid = acpi_id which is fine, while
> acpi_map_cpuid
> matches apic_id with cpu_physical_id(which must be MPIDR in ARM{32,64}).
> The
> latter imposes restriction that gic->gic_id has to be MPIDR. Does that
> mean we
> are imposing restriction on GIC ID to be MPIDR ? If so please document it
> here
> and please explain the reason behind that choice.
On x86 and IA64, APIC/SAPIC ID is the hardware id of the logical
processor, and UID is just a unique ID to identify the processor in DSDT,
it
can be any value, and even can be strings defined in ASL if I remember
that correctly.
>>> OK, but that's not the case on ARM{32,64}. My main concern here is if we
>>> don't
>>> make this definitions clear enough, the vendors might produce ACPI tables
>>> with
>>> whatever suits them and we may end up supporting them. Since we are starting
>>> with clean slate, we can avoid getting into such situations. I will be to be
>>> more elaborate this time.
>>
>> I agree.
>>
>>>
>>> The GIC ID is referred as the local GIC’s hardware ID in ACPIv5.0.
>>> IIUC, since GICC is per-cpu entry, it has to GIC CPU interface ID.
>>>
>>> Now how does it differ from MPIDR ? e.g. ARM TC2(multi cluster system)
>>> GIC IDMPIDRComment
>>> 00x000CA15_0
>>> 10x001CA15_1
>>> 20x100CA7_0
>>> 30x101CA7_1
>>> 40x102CA7_2
>>
>> Yes, obvious different. I know GIC ID can matche the bit index of the
>> associated processor
>> in the distributor's GICD_ITARGETSR register, and it a clear
>> statement in GICv1/GICv2, my
>> question is that is this consistent in GICv3/v4 too? this will have
>> some impact on the
>> code implementation.
>
> For GICv3/v4, the only way you can match a CPU with its local redistributor
> is by using the CPU MPIDR. The GIC CPU ID is an implementation choice that
> may not exist (it doesn't in a distributed
> implementation), so anything that relies on a GIC CPU ID is broken for GICv3.
So that's the broken part, it seems that GIC ID is useless both
in GICv1/v2 and GICv3/v4 if it represents GIC CPU interface ID,
the only reliable one is the MPIDR.
I agree UID should be MPIDR for future usage, so how about this solution:
+static int map_gic_id(struct acpi_subtable_header *entry,
+ int device_declaration, u32 acpi_id, int *apic_id)
+{
+ struct acpi_madt_generic_interrupt *gic =
+ (struct acpi_madt_generic_interrupt *)entry;
+
+ if (!(gic->flags & ACPI_MADT_ENABLED))
+ return -ENODEV
[PATCH] ASoC: core: add snd_soc_dai_set_tdm_slot_xlate()
The parameters of rx_mask and tx_mask has no use for
snd_soc_dai_set_tdm_slot(), because they could be generated by
{XXX_ .}of_xlate_tdm_slot_mask().
This patch add snd_soc_dai_set_tdm_slot_xlate() which will replace
the snd_soc_dai_set_tdm_slot() eventually.
Signed-off-by: Xiubo Li
---
include/sound/soc-dai.h | 3 +++
sound/soc/soc-core.c| 33 -
2 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index d86e0fc..68569ee 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -110,6 +110,9 @@ int snd_soc_dai_set_bclk_ratio(struct snd_soc_dai *dai,
unsigned int ratio);
/* Digital Audio interface formatting */
int snd_soc_dai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt);
+int snd_soc_dai_set_tdm_slot_xlate(struct snd_soc_dai *dai,
+ unsigned int slots,
+ unsigned int slot_width);
int snd_soc_dai_set_tdm_slot(struct snd_soc_dai *dai,
unsigned int tx_mask, unsigned int rx_mask, int slots, int slot_width);
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 0911856..e5a535b 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3687,19 +3687,20 @@ static int snd_soc_of_xlate_tdm_slot_mask(unsigned int
slots,
}
/**
- * snd_soc_dai_set_tdm_slot - configure DAI TDM.
+ * snd_soc_dai_set_tdm_slot_xlate - configure DAI TDM with of xlate.
* @dai: DAI
- * @tx_mask: bitmask representing active TX slots.
- * @rx_mask: bitmask representing active RX slots.
* @slots: Number of slots in use.
* @slot_width: Width in bits for each slot.
*
* Configures a DAI for TDM operation. Both mask and slots are codec and DAI
* specific.
*/
-int snd_soc_dai_set_tdm_slot(struct snd_soc_dai *dai,
- unsigned int tx_mask, unsigned int rx_mask, int slots, int slot_width)
+int snd_soc_dai_set_tdm_slot_xlate(struct snd_soc_dai *dai,
+ unsigned int slots,
+ unsigned int slot_width)
{
+ unsigned int tx_mask, rx_mask;
+
if (dai->driver && dai->driver->ops->of_xlate_tdm_slot_mask)
dai->driver->ops->of_xlate_tdm_slot_mask(slots,
&tx_mask, &rx_mask);
@@ -3712,6 +3713,28 @@ int snd_soc_dai_set_tdm_slot(struct snd_soc_dai *dai,
else
return -ENOTSUPP;
}
+EXPORT_SYMBOL_GPL(snd_soc_dai_set_tdm_slot_xlate);
+
+/**
+ * snd_soc_dai_set_tdm_slot - configure DAI TDM.
+ * @dai: DAI
+ * @tx_mask: bitmask representing active TX slots.
+ * @rx_mask: bitmask representing active RX slots.
+ * @slots: Number of slots in use.
+ * @slot_width: Width in bits for each slot.
+ *
+ * Configures a DAI for TDM operation. Both mask and slots are codec and DAI
+ * specific.
+ */
+int snd_soc_dai_set_tdm_slot(struct snd_soc_dai *dai,
+ unsigned int tx_mask, unsigned int rx_mask, int slots, int slot_width)
+{
+ if (dai->driver && dai->driver->ops->set_tdm_slot)
+ return dai->driver->ops->set_tdm_slot(dai, tx_mask, rx_mask,
+ slots, slot_width);
+ else
+ return -ENOTSUPP;
+}
EXPORT_SYMBOL_GPL(snd_soc_dai_set_tdm_slot);
/**
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 0/7] cpufreq: suspend early/resume late: dpm_{suspend|resume}()
On 17 February 2014 14:55, Viresh Kumar wrote:
> This patchset creates/calls cpufreq suspend/resume callbacks from
> dpm_{suspend|resume}()
> for handling suspend/resume of cpufreq governors and core.
>
> There are multiple problems that are fixed by this patch:
> - Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His
> board
> wasn't working well with suspend/resume as calls for removing non-boot CPUs
> was turning out into a call to drivers ->target() which then tries to play
> with regulators. But regulators and their I2C bus were already suspended and
> this resulted in a failure. Many platforms have such problems, samsung,
> tegra,
> etc.. They solved it with driver specific PM notifiers where they used to
> disable their driver's ->target() routine.
> - Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found an issue where tunables
> configuration for clusters/sockets with non-boot CPUs was getting lost after
> suspend/resume, as we were notifying governors with CPUFREQ_GOV_POLICY_EXIT
> on
> removal of the last cpu for that policy and so deallocating memory for
> tunables. This is fixed by this patch as we don't allow any operation on
> governors after device suspend and before device resume now.
>
> This is already tested by few people and so incorporating their Tested-by as
> well.
>
> I have tested this again on latest stuff on my thinkpad for several
> suspend/resume cycles.
>
> V6->V7:
> - Fixed crash reported by S.Warren on systems without a cpufreq driver.
> - Moved some function doc-comments to patch 1 from a later patch.
>
> For-v3.15
>
> Viresh Kumar (7):
> cpufreq: suspend governors on system suspend/hibernate
> cpufreq: suspend governors from dpm_{suspend|resume}()
> cpufreq: call driver's suspend/resume for each policy
> cpufreq: Implement cpufreq_generic_suspend()
> cpufreq: exynos: Use cpufreq_generic_suspend()
> cpufreq: s5pv210: Use cpufreq_generic_suspend()
> cpufreq: Tegra: Use cpufreq_generic_suspend()
>
> drivers/base/power/main.c | 5 ++
> drivers/cpufreq/cpufreq.c | 137
> +++---
> drivers/cpufreq/exynos-cpufreq.c | 96 ++
> drivers/cpufreq/s5pv210-cpufreq.c | 49 +-
> drivers/cpufreq/tegra-cpufreq.c | 46 ++---
> include/linux/cpufreq.h | 11 +++
> 6 files changed, 113 insertions(+), 231 deletions(-)
Hi Rafael,
I think this patch is good to go now for 3.15?
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 09/26] arm: mmp: Remove pointless fiddling with irq internals
On Mon, Feb 24, 2014 at 2:07 PM, Chao Xie wrote: > On Mon, Feb 24, 2014 at 7:17 AM, Uwe Kleine-König > wrote: >> Hi Thomas, >> >> On Sun, Feb 23, 2014 at 09:40:13PM -, Thomas Gleixner wrote: >>> The pm-mmp2 and pm-pxa910 power management related irq_set_wake >>> callbacks fiddle pointlessly with the irq actions for no reason except >>> for lack of understanding how the wakeup mechanism works. >>> >>> On supsend the core disables all interrupts lazily, i.e. it does not >>> mask them at the irq controller level. So any interrupt which is >>> firing during supsend will mark the corresponding interrupt line as >> s/supsend/suspend/ twice >>> pending. Just before the core powers down it checks whether there are >>> interrupts pending from interrupt lines which are marked as wakeup >>> sources and if so it aborts the resume and resends the interrupts. >> It's the suspend that is aborted, not the resume. >> >> Other than that your change looks fine. >> > For pxa910 and MMP2, wake up source only wake up the AP subsystem. > The AP subsystem includes the APMU(AP Power Mangament Unit) and cores. > Now the core is still powered down. APMU will check the interrupt > lines, and find > that there are interrupt pending, it will power on the cores. > So if the irq is disabled, even wake up source can wake up AP subsystem, but > the > core is still powered down. It will not be powered up by APMU. > Yes, suspend/resume can't work if the above code is removed. Interrupt source (logic AND with interrupt mask register) is connected to MPMU as wakeup source. If the interrupt is disabled, there's no wakeup source event. And APMU is waken up by MPMU. So please don't remove the above code. We must keep these interrupt lines active to wake up the whole system. Regards Haojian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 0/7] cpufreq: suspend early/resume late: dpm_{suspend|resume}()
On 20 February 2014 23:10, Stephen Warren wrote: > Well, except that still leaves a bunch of errors in the kernel log, and > I have to remember to ignore them:-/ Just for few releases, before this patchset goes in. > It'd be nice if the cpufreq core didn't keep changing its behaviour and > adding new error prints. It really should be up to the cpufreq drivers > to log the errors if they experience any. Hmm... not sure.. Its better to do error prints at a single place, i.e. cpufreq core on behalf of all drivers. If there is a error being returned from some routine, we better print a message for that. Rather than living in the illusion that everything is fine :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] perf tools: Add hist.percentage config option
On Thu, 20 Feb 2014 12:01:12 +0100, Jiri Olsa wrote:
> On Mon, Feb 10, 2014 at 11:47:23AM +0900, Namhyung Kim wrote:
>> Add hist.percentage option for setting default value of the
>> symbol_conf.filter_relative. It affects the output of various perf
>> commands (like perf report, top and diff) only if filter(s) applied.
>>
>> An user can write .perfconfig file like below to show absolute
>> percentage of filtered entries by default:
>
> SNIP
>
>> +++ b/tools/perf/util/hist.c
>> @@ -934,3 +934,17 @@ int hists__link(struct hists *leader, struct hists
>> *other)
>>
>> return 0;
>> }
>> +
>> +int perf_hist_config(const char *var, const char *value)
>> +{
>> +if (!strcmp(var, "hist.percentage")) {
>> +if (!strcmp(value, "relative"))
>> +symbol_conf.filter_relative = true;
>> +else if (!strcmp(value, "absolute"))
>> +symbol_conf.filter_relative = false;
>> +else
>> +return -1;
>> +}
>> +
>> +return 0;
>> +}
>
> the inner stuff could be done in parse_percentage function
> not to duplicate the symbol_conf.filter_relative assignment
Will do!
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Feb 24
Hi all, This tree fails (more than usual) the powerpc allyesconfig build. Changes since 20140221: The mvebu tree gained a conflict against Linus' tree. The powerpc tree still had its build failure. The mfd-lj tree still had its build failure so I used the version from next-20140210. The sound-asoc tree gained a conflict against the mvebu tree. The spi tree gained a build failure so I sued the version from next-20140221. The rcu tree gained a conflict against the tip tree. The char-misc tree still had its build failure for which I applied a merge fix patch. Non-merge commits (relative to Linus' tree): 4150 4214 files changed, 152464 insertions(+), 78715 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 210 trees (counting Linus' and 28 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (f9b080803ec6 Merge tag 'usb-3.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1) Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8) Merging arm-current/fixes (b36345759308 ARM: 7980/1: kernel: improve error message when LPAE config doesn't match CPU) Merging m68k-current/for-linus (7247f55381d5 m68k: Wire up sched_setattr and sched_getattr) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (66f9af83e56b powerpc/eeh: Disable EEH on reboot) Merging sparc/master (10527106abec Merge tag 'dt-for-linus' of git://git.secretlab.ca/git/linux) Merging net/master (916e4cf46d02 ipv6: reuse ip6_frag_id from ip6_ufo_append_data) Merging ipsec/master (ee5c23176fcc xfrm: Clone states properly on migration) Merging sound-current/for-linus (c60666bd2224 ALSA: hda/realtek - Add more entry for enable HP mute led) Merging pci-current/for-linus (fc40363b2140 ahci: Fix broken fallback to single MSI mode) Merging wireless/master (b3050248c167 ath9k: Fix ETSI compliance for AR9462 2.0) Merging driver-core.current/driver-core-linus (6d0abeca3242 Linux 3.14-rc3) Merging tty.current/tty-linus (5c0a2450d695 Revert "tty: Set correct tty name in 'active' sysfs attribute") Merging usb.current/usb-linus (5bf5dbeda245 usb: chipidea: need to mask when writting endptflush and endptprime) Merging staging.current/staging-linus (e194fd8a5d8e staging: binder: Fix death notifications) Merging char-misc.current/char-misc-linus (accb884b32e8 mei: set client's read_cb to NULL when flow control fails) Merging input-current/for-linus (70b0052425ff Input: da9052_onkey - use correct register bit for key status) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (ee97dc7db4cb crypto: s390 - fix des and des3_ede ctr concurrency issue) Merging ide/master (738b52bb9845 Merge tag 'microblaze-3.14-rc3' of git://git.monstr.eu/linux-2.6-microblaze) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (1f42e5dd5065 of: Add self test for of_match_node()) Merging rr-fi
Re: [PATCH 3/8] perf report: Add --percentage option
Hi Jiri,
On Thu, 20 Feb 2014 11:39:50 +0100, Jiri Olsa wrote:
> On Mon, Feb 10, 2014 at 11:47:20AM +0900, Namhyung Kim wrote:
>> The --percentage option is for controlling overhead percentage
>> displayed. It can only receive either of "relative" or "absolute".
>>
>> "relative" means it's relative to filtered entries only so that the
>> sum of shown entries will be always 100%. "absolute" means it retains
>> the original value before and after the filter is applied.
>
> SNIP
>
>> diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
>> index 78f4c92e9b73..714f3f00ea55 100644
>> --- a/tools/perf/ui/hist.c
>> +++ b/tools/perf/ui/hist.c
>> @@ -21,10 +21,13 @@ static int __hpp__fmt(struct perf_hpp *hpp, struct
>> hist_entry *he,
>>
>> if (fmt_percent) {
>> double percent = 0.0;
>> +u64 total = hists->stats.total_period;
>>
>> -if (hists->stats.total_period)
>> -percent = 100.0 * get_field(he) /
>> - hists->stats.total_period;
>> +if (symbol_conf.filter_relative)
>> +total = hists->stats.total_filtered_period;
>> +
>> +if (total)
>> +percent = 100.0 * get_field(he) / total;
>>
>> ret = print_fn(hpp->buf, hpp->size, fmt, percent);
>> } else
>> @@ -41,6 +44,9 @@ static int __hpp__fmt(struct perf_hpp *hpp, struct
>> hist_entry *he,
>> u64 period = get_field(pair);
>> u64 total = pair->hists->stats.total_period;
>>
>> +if (symbol_conf.filter_relative)
>> +total =
>> pair->hists->stats.total_filtered_period;
>> +
>> if (!total)
>> continue;
>
> looks like we could use something like:
>
> perf_hists__total_period(hists)
> {
> u64 total = hists->stats.total_period;
>
> if (symbol_conf.filter_relative)
> total = hists->stats.total_filtered_period;
>
> return total;
> }
>
> probably on other places as well
Right! Will change.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] perf top: Add --percentage option
On Thu, 20 Feb 2014 11:44:40 +0100, Jiri Olsa wrote:
> On Mon, Feb 10, 2014 at 11:47:21AM +0900, Namhyung Kim wrote:
>> The --percentage option is for controlling overhead percentage
>> displayed. It can only receive either of "relative" or "absolute".
>>
>> For more information, please see previous commit same thing done to
>> "perf report".
>>
>> Signed-off-by: Namhyung Kim
>> ---
>
> SNIP
>
>>
>> diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
>> index ed99ec4a309f..a516e0389c5e 100644
>> --- a/tools/perf/builtin-top.c
>> +++ b/tools/perf/builtin-top.c
>> @@ -1011,6 +1011,20 @@ parse_percent_limit(const struct option *opt, const
>> char *arg,
>> return 0;
>> }
>>
>> +static int
>> +parse_percentage(const struct option *opt __maybe_unused, const char *arg,
>> + int unset __maybe_unused)
>> +{
>> +if (!strcmp(arg, "relative"))
>> +symbol_conf.filter_relative = true;
>> +else if (!strcmp(arg, "absolute"))
>> +symbol_conf.filter_relative = false;
>> +else
>> +return -1;
>> +
>> +return 0;
>> +}
>
> please make one of parse_percentage functions public and
> share it among report/top/diff commands
Okay.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warning after merge of the tip tree
Hi Andrew, On Sun, 23 Feb 2014 22:12:17 -0800 Andrew Morton wrote: > > Doh, I missed that. I don't know if it's "allowed" or not, but it's > clearly the wrong thing to do - the whole point of asmlinkage is to > export the thing to other compilation units. > > So I suppose this: > > mm/process_vm_access.c:416:1: warning: no previous prototype for > `compat_process_vm_rw' [-Wmissing-prototypes] > > should be squashed by giving it a prototype. Something like Or maybe it should be static but *not* asmlinkage like process_vm_rw() ? As far as I can see it is only used in mm/process_vm_access.c. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpsoG556SypL.pgp Description: PGP signature
Re: linux-next: build warning after merge of the tip tree
On Mon, 24 Feb 2014 16:56:21 +1100 Stephen Rothwell
wrote:
> Hi all,
>
> On Mon, 24 Feb 2014 15:17:32 +1100 Stephen Rothwell
> wrote:
> >
> > I guess that there may be more places where "asmlinkage" is used with
> > "static" - I assume that they are all incorrect?
> >
> > $ git grep -l 'static.*asmlinkage'
> > arch/x86/crypto/sha1_ssse3_glue.c
> > arch/x86/crypto/sha256_ssse3_glue.c
> > arch/x86/crypto/sha512_ssse3_glue.c
>
> In fact, my x86_64 allmodconfig build produces these:
>
> arch/x86/crypto/sha1_ssse3_glue.c:43:1: warning: 'externally_visible'
> attribute have effect only on public objects [-Wattributes]
> static asmlinkage void (*sha1_transform_asm)(u32 *, const char *, unsigned
> int);
> ^
> arch/x86/crypto/sha256_ssse3_glue.c:56:1: warning: 'externally_visible'
> attribute have effect only on public objects [-Wattributes]
> static asmlinkage void (*sha256_transform_asm)(const char *, u32 *, u64);
> ^
> arch/x86/crypto/sha512_ssse3_glue.c:55:1: warning: 'externally_visible'
> attribute have effect only on public objects [-Wattributes]
> static asmlinkage void (*sha512_transform_asm)(const char *, u64 *, u64);
> ^
> mm/process_vm_access.c:422:1: warning: 'externally_visible' attribute have
> effect only on public objects [-Wattributes]
> {
> ^
>
> That last is added by commit 700d00f85598 ("mm/process_vm_access.c: mark
> function as static") from the akpm-current tree.
>
> So is "static asmlinkage" not allowed?
Doh, I missed that. I don't know if it's "allowed" or not, but it's
clearly the wrong thing to do - the whole point of asmlinkage is to
export the thing to other compilation units.
So I suppose this:
mm/process_vm_access.c:416:1: warning: no previous prototype for
`compat_process_vm_rw' [-Wmissing-prototypes]
should be squashed by giving it a prototype. Something like
--- a/include/linux/compat.h~a
+++ a/include/linux/compat.h
@@ -644,6 +644,13 @@ asmlinkage ssize_t compat_sys_mq_timedre
asmlinkage long compat_sys_socketcall(int call, u32 __user *args);
asmlinkage long compat_sys_sysctl(struct compat_sysctl_args __user *args);
+asmlinkage ssize_t compat_process_vm_rw(compat_pid_t pid,
+const struct compat_iovec __user *lvec,
+unsigned long liovcnt,
+const struct compat_iovec __user *rvec,
+unsigned long riovcnt,
+unsigned long flags, int vm_write);
+
extern ssize_t compat_rw_copy_check_uvector(int type,
const struct compat_iovec __user *uvector,
unsigned long nr_segs,
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 09/26] arm: mmp: Remove pointless fiddling with irq internals
On Mon, Feb 24, 2014 at 7:17 AM, Uwe Kleine-König wrote: > Hi Thomas, > > On Sun, Feb 23, 2014 at 09:40:13PM -, Thomas Gleixner wrote: >> The pm-mmp2 and pm-pxa910 power management related irq_set_wake >> callbacks fiddle pointlessly with the irq actions for no reason except >> for lack of understanding how the wakeup mechanism works. >> >> On supsend the core disables all interrupts lazily, i.e. it does not >> mask them at the irq controller level. So any interrupt which is >> firing during supsend will mark the corresponding interrupt line as > s/supsend/suspend/ twice >> pending. Just before the core powers down it checks whether there are >> interrupts pending from interrupt lines which are marked as wakeup >> sources and if so it aborts the resume and resends the interrupts. > It's the suspend that is aborted, not the resume. > > Other than that your change looks fine. > For pxa910 and MMP2, wake up source only wake up the AP subsystem. The AP subsystem includes the APMU(AP Power Mangament Unit) and cores. Now the core is still powered down. APMU will check the interrupt lines, and find that there are interrupt pending, it will power on the cores. So if the irq is disabled, even wake up source can wake up AP subsystem, but the core is still powered down. It will not be powered up by APMU. > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König| > Industrial Linux Solutions | http://www.pengutronix.de/ | > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the spi tree
On Mon, Feb 24, 2014 at 02:45:29PM +1100, Stephen Rothwell wrote: > compilation with COMPILE_TEST"). Please at least test building on x86 > before allowing a build with COMPILE_TEST. Yeah, I tend to rely on the zero day tester to get that when travelling since it's normally quicker to get a result from that than it is for me to build on my laptop. That doesn't seem to have worked out though... Like I said in reply to Axel's patch it's not exactly sane that things like this are an issue in the first place. signature.asc Description: Digital signature
[RFC 0/6] vhost/scsi: Add T10 PI SGL passthrough support
From: Nicholas Bellinger Hi MST, MKP, Paolo & Co, The following is an initial RFC series for allowing vhost/scsi to accept T10 protection information (PI) as seperate SGLs along side existing data payload SGLs from within virtio-scsi guest memory. In it's current form, both ends are using virtio_scsi_cmd_req->prio for signaling the total protection SGLs vs. data payload SGLs to be expected. This is due to the current inability of virtio / vhost to signal a seperate SGL count specific for T10 PI metadata. AFAICT up until this point the ->prio field has been unused, but I'm certainly open to better ways of signaling (to vhost) that some number of metadata iovs are to be expected.. Any thoughts..? Also included is a new VIRTIO_SCSI_F_T10_PI feature bit to signal DIF/DIX fabric support. Note this is currently hardcoded to 1 for testing purposes as v3.14-rc2 code is having problems correctly proposing + acknowleding feature bits so that virtio_has_feature() works as expected. Still tracking this seperate bug down.. That said, here's a quick look of the WIP code in action on v3.14-rc2 host/guest. Comments..? --nab [3.324348] virtio-pci :00:04.0: irq 40 for MSI/MSI-X [3.324407] virtio-pci :00:04.0: irq 41 for MSI/MSI-X [3.324475] virtio-pci :00:04.0: irq 42 for MSI/MSI-X [3.324529] virtio-pci :00:04.0: irq 43 for MSI/MSI-X [3.325421] scsi0 : Virtio SCSI HBA [3.486951] scsi 0:0:1:0: Direct-Access LIO-ORG FILEIO 4.0 PQ: 0 ANSI: 5 [3.515702] sd 0:0:1:0: [sda] Enabling DIF Type 1 protection [3.515713] sd 0:0:1:0: [sda] 4194304 512-byte logical blocks: (2.14 GB/2.00 GiB) [3.608441] sd 0:0:1:0: [sda] Write Protect is off [3.632304] sd 0:0:1:0: [sda] Mode Sense: 43 00 00 08 [3.662132] sd 0:0:1:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [3.938072] sda: unknown partition table [3.970423] sd 0:0:1:0: [sda] Enabling DIX T10-DIF-TYPE1-CRC protection [3.970425] sd 0:0:1:0: [sda] DIF application tag size 2 TYPE1 VERIFY> [ 113.273961] virtio_scsi_add_cmd: CDB: 0x00 EDTL: 0 sg_count: 0 out_num: 1 in_num: 1 [ 113.277687] virtqueue_add_sgs: total_out: 1 total_in: 1 [ 114.438563] Entering sd_dif_type1_generate >>> [ 114.438571] TYPE1 Generate: sector: 0 sdt->guard_tag: 0x21b2 sdt->app_tag: 0x sdt->ref_tag: 0 [ 114.438578] TYPE1 Generate: sector: 1 sdt->guard_tag: 0xe534 sdt->app_tag: 0x sdt->ref_tag: 1 [ 114.438582] TYPE1 Generate: sector: 2 sdt->guard_tag: 0x4f0b sdt->app_tag: 0x sdt->ref_tag: 2 [ 114.438586] TYPE1 Generate: sector: 3 sdt->guard_tag: 0xe8cc sdt->app_tag: 0x sdt->ref_tag: 3 [ 114.438590] TYPE1 Generate: sector: 4 sdt->guard_tag: 0xab21 sdt->app_tag: 0x sdt->ref_tag: 4 [ 114.438594] TYPE1 Generate: sector: 5 sdt->guard_tag: 0x6c36 sdt->app_tag: 0x sdt->ref_tag: 5 [ 114.438598] TYPE1 Generate: sector: 6 sdt->guard_tag: 0x5f28 sdt->app_tag: 0x sdt->ref_tag: 6 [ 114.438602] TYPE1 Generate: sector: 7 sdt->guard_tag: 0xecd3 sdt->app_tag: 0x sdt->ref_tag: 7 [ 114.438610] Entering sd_dif_type1_generate >>> [ 114.438614] TYPE1 Generate: sector: 8 sdt->guard_tag: 0x01b4 sdt->app_tag: 0x sdt->ref_tag: 8 [ 114.438618] TYPE1 Generate: sector: 9 sdt->guard_tag: 0x4362 sdt->app_tag: 0x sdt->ref_tag: 9 [ 114.438622] TYPE1 Generate: sector: 10 sdt->guard_tag: 0x21fa sdt->app_tag: 0x sdt->ref_tag: 10 [ 114.438626] TYPE1 Generate: sector: 11 sdt->guard_tag: 0xdb56 sdt->app_tag: 0x sdt->ref_tag: 11 [ 114.438630] TYPE1 Generate: sector: 12 sdt->guard_tag: 0xb680 sdt->app_tag: 0x sdt->ref_tag: 12 [ 114.438634] TYPE1 Generate: sector: 13 sdt->guard_tag: 0xd00f sdt->app_tag: 0x sdt->ref_tag: 13 [ 114.438638] TYPE1 Generate: sector: 14 sdt->guard_tag: 0xfc4d sdt->app_tag: 0x sdt->ref_tag: 14 [ 114.438643] TYPE1 Generate: sector: 15 sdt->guard_tag: 0x0447 sdt->app_tag: 0x sdt->ref_tag: 15 [ 114.438655] Attaching prot_sg list for WRITE, prot_sg_count: 2 [ 114.440029] virtio_scsi_add_cmd: CDB: 0x2a EDTL: 8192 sg_count: 2 out_num: 3 in_num: 1 [ 114.440029] virtqueue_add_sgs: total_out: 5 total_in: 1 [ 132.407792] Attaching prot_sg list for READ, prot_sg_count: 1 [ 132.408039] virtio_scsi_add_cmd: CDB: 0x28 EDTL: 8192 sg_count: 2 out_num: 1 in_num: 3 [ 132.408039] virtqueue_add_sgs: total_out: 1 total_in: 4 [ 132.417454] TYPE1 Verify sector: 0 sdt->guard_tag: 0x21b2 sdt->app_tag: 0x sdt->ref_tag: 0 [ 132.417459] TYPE1 Verify sector: 1 sdt->guard_tag: 0xe534 sdt->app_tag: 0x sdt->ref_tag: 1 [ 132.417463] TYPE1 Verify sector: 2 sdt->guard_tag: 0x4f0b sdt->app_tag: 0x sdt->ref_tag: 2 [ 132.417468] TYPE1 Verify sector: 3 sdt->guard_tag: 0xe8cc sdt->app_tag: 0x sdt->ref_tag: 3 [ 132.417472] TYPE1 Verify sector: 4 sdt->guard_tag: 0xab21 sdt->app_tag: 0x sdt->ref_tag: 4 [ 132.417476] TYPE1 Verify sector: 5 sdt->guard_tag: 0x6c36 sdt->app_tag: 0
[RFC 2/6] vhost/scsi: Add preallocation of protection SGLs
From: Nicholas Bellinger
This patch updates tcm_vhost_make_nexus() to pre-allocate per descriptor
tcm_vhost_cmd->tvc_prot_sgl[] used to expose protection SGLs from within
virtio-scsi guest memory to vhost-scsi.
Cc: Michael S. Tsirkin
Cc: Paolo Bonzini
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
---
drivers/vhost/scsi.c | 56 +-
1 file changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 31feb47..314cbd4 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -58,6 +58,7 @@
#define TCM_VHOST_DEFAULT_TAGS 256
#define TCM_VHOST_PREALLOC_SGLS 2048
#define TCM_VHOST_PREALLOC_UPAGES 2048
+#define TCM_VHOST_PREALLOC_PROT_SGLS 512
struct vhost_scsi_inflight {
/* Wait for the flush operation to finish */
@@ -83,6 +84,7 @@ struct tcm_vhost_cmd {
u32 tvc_lun;
/* Pointer to the SGL formatted memory from virtio-scsi */
struct scatterlist *tvc_sgl;
+ struct scatterlist *tvc_prot_sgl;
struct page **tvc_upages;
/* Pointer to response */
struct virtio_scsi_cmd_resp __user *tvc_resp;
@@ -717,7 +719,7 @@ vhost_scsi_get_tag(struct vhost_virtqueue *vq,
struct tcm_vhost_cmd *cmd;
struct tcm_vhost_nexus *tv_nexus;
struct se_session *se_sess;
- struct scatterlist *sg;
+ struct scatterlist *sg, *prot_sg;
struct page **pages;
int tag;
@@ -736,10 +738,12 @@ vhost_scsi_get_tag(struct vhost_virtqueue *vq,
cmd = &((struct tcm_vhost_cmd *)se_sess->sess_cmd_map)[tag];
sg = cmd->tvc_sgl;
+ prot_sg = cmd->tvc_prot_sgl;
pages = cmd->tvc_upages;
memset(cmd, 0, sizeof(struct tcm_vhost_cmd));
cmd->tvc_sgl = sg;
+ cmd->tvc_prot_sgl = prot_sg;
cmd->tvc_upages = pages;
cmd->tvc_se_cmd.map_tag = tag;
cmd->tvc_tag = v_req->tag;
@@ -852,6 +856,47 @@ vhost_scsi_map_iov_to_sgl(struct tcm_vhost_cmd *cmd,
return 0;
}
+static int
+vhost_scsi_map_iov_to_prot(struct tcm_vhost_cmd *cmd,
+ struct iovec *iov,
+ int niov,
+ bool write)
+{
+ struct scatterlist *prot_sg = cmd->tvc_prot_sgl;
+ unsigned int prot_sgl_count = 0;
+ int ret, i;
+
+ for (i = 0; i < niov; i++)
+ prot_sgl_count += iov_num_pages(&iov[i]);
+
+ if (prot_sgl_count > TCM_VHOST_PREALLOC_PROT_SGLS) {
+ pr_err("vhost_scsi_map_iov_to_prot() sgl_count: %u greater than"
+ " preallocated TCM_VHOST_PREALLOC_PROT_SGLS: %u\n",
+ prot_sgl_count, TCM_VHOST_PREALLOC_PROT_SGLS);
+ return -ENOBUFS;
+ }
+
+ pr_debug("%s prot_sg %p prot_sgl_count %u\n", __func__,
+prot_sg, prot_sgl_count);
+ sg_init_table(prot_sg, prot_sgl_count);
+ cmd->tvc_prot_sgl_count = prot_sgl_count;
+
+ for (i = 0; i < niov; i++) {
+ ret = vhost_scsi_map_to_sgl(cmd, prot_sg, prot_sgl_count,
&iov[i],
+ cmd->tvc_upages, write);
+ if (ret < 0) {
+ for (i = 0; i < cmd->tvc_prot_sgl_count; i++)
+ put_page(sg_page(&cmd->tvc_prot_sgl[i]));
+
+ cmd->tvc_prot_sgl_count = 0;
+ return ret;
+ }
+ prot_sg += ret;
+ prot_sgl_count -= ret;
+ }
+ return 0;
+}
+
static void tcm_vhost_submission_work(struct work_struct *work)
{
struct tcm_vhost_cmd *cmd =
@@ -1692,6 +1737,7 @@ static void tcm_vhost_free_cmd_map_res(struct
tcm_vhost_nexus *nexus,
tv_cmd = &((struct tcm_vhost_cmd *)se_sess->sess_cmd_map)[i];
kfree(tv_cmd->tvc_sgl);
+ kfree(tv_cmd->tvc_prot_sgl);
kfree(tv_cmd->tvc_upages);
}
}
@@ -1750,6 +1796,14 @@ static int tcm_vhost_make_nexus(struct tcm_vhost_tpg
*tpg,
pr_err("Unable to allocate tv_cmd->tvc_upages\n");
goto out;
}
+
+ tv_cmd->tvc_prot_sgl = kzalloc(sizeof(struct scatterlist) *
+ TCM_VHOST_PREALLOC_PROT_SGLS,
GFP_KERNEL);
+ if (!tv_cmd->tvc_prot_sgl) {
+ mutex_unlock(&tpg->tv_tpg_mutex);
+ pr_err("Unable to allocate tv_cmd->tvc_prot_sgl\n");
+ goto out;
+ }
}
/*
* Since we are running in 'demo mode' this call with generate a
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.or
[RFC 1/6] vhost/scsi: Move sanity check into vhost_scsi_map_iov_to_sgl
From: Nicholas Bellinger
Move the overflow check for sgl_count > TCM_VHOST_PREALLOC_SGLS into
vhost_scsi_map_iov_to_sgl() so that it's based on the total number
of SGLs for all IOVs, instead of single IOVs.
Also, rename TCM_VHOST_PREALLOC_PAGES -> TCM_VHOST_PREALLOC_UPAGES
to better describe pointers to user-space pages.
Cc: Michael S. Tsirkin
Cc: Paolo Bonzini
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
---
drivers/vhost/scsi.c | 59 +-
1 file changed, 25 insertions(+), 34 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 0a025b8..31feb47 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -57,7 +57,7 @@
#define TCM_VHOST_MAX_CDB_SIZE 32
#define TCM_VHOST_DEFAULT_TAGS 256
#define TCM_VHOST_PREALLOC_SGLS 2048
-#define TCM_VHOST_PREALLOC_PAGES 2048
+#define TCM_VHOST_PREALLOC_UPAGES 2048
struct vhost_scsi_inflight {
/* Wait for the flush operation to finish */
@@ -762,35 +762,28 @@ vhost_scsi_map_to_sgl(struct tcm_vhost_cmd *tv_cmd,
struct scatterlist *sgl,
unsigned int sgl_count,
struct iovec *iov,
- int write)
+ struct page **pages,
+ bool write)
{
unsigned int npages = 0, pages_nr, offset, nbytes;
struct scatterlist *sg = sgl;
void __user *ptr = iov->iov_base;
size_t len = iov->iov_len;
- struct page **pages;
int ret, i;
- if (sgl_count > TCM_VHOST_PREALLOC_SGLS) {
- pr_err("vhost_scsi_map_to_sgl() psgl_count: %u greater than"
- " preallocated TCM_VHOST_PREALLOC_SGLS: %u\n",
- sgl_count, TCM_VHOST_PREALLOC_SGLS);
- return -ENOBUFS;
- }
-
pages_nr = iov_num_pages(iov);
- if (pages_nr > sgl_count)
+ if (pages_nr > sgl_count) {
+ pr_err("vhost_scsi_map_iov_to_sgl() pages_nr: %u greater than"
+ " sgl_count: %u\n", pages_nr, sgl_count);
return -ENOBUFS;
-
- if (pages_nr > TCM_VHOST_PREALLOC_PAGES) {
+ }
+ if (pages_nr > TCM_VHOST_PREALLOC_UPAGES) {
pr_err("vhost_scsi_map_to_sgl() pages_nr: %u greater than"
- " preallocated TCM_VHOST_PREALLOC_PAGES: %u\n",
- pages_nr, TCM_VHOST_PREALLOC_PAGES);
+ " preallocated TCM_VHOST_PREALLOC_UPAGES: %u\n",
+ pages_nr, TCM_VHOST_PREALLOC_UPAGES);
return -ENOBUFS;
}
- pages = tv_cmd->tvc_upages;
-
ret = get_user_pages_fast((unsigned long)ptr, pages_nr, write, pages);
/* No pages were pinned */
if (ret < 0)
@@ -820,33 +813,32 @@ out:
static int
vhost_scsi_map_iov_to_sgl(struct tcm_vhost_cmd *cmd,
struct iovec *iov,
- unsigned int niov,
- int write)
+ int niov,
+ bool write)
{
- int ret;
- unsigned int i;
- u32 sgl_count;
- struct scatterlist *sg;
+ struct scatterlist *sg = cmd->tvc_sgl;
+ unsigned int sgl_count = 0;
+ int ret, i;
- /*
-* Find out how long sglist needs to be
-*/
- sgl_count = 0;
for (i = 0; i < niov; i++)
sgl_count += iov_num_pages(&iov[i]);
- /* TODO overflow checking */
+ if (sgl_count > TCM_VHOST_PREALLOC_SGLS) {
+ pr_err("vhost_scsi_map_iov_to_sgl() sgl_count: %u greater than"
+ " preallocated TCM_VHOST_PREALLOC_SGLS: %u\n",
+ sgl_count, TCM_VHOST_PREALLOC_SGLS);
+ return -ENOBUFS;
+ }
- sg = cmd->tvc_sgl;
pr_debug("%s sg %p sgl_count %u\n", __func__, sg, sgl_count);
sg_init_table(sg, sgl_count);
-
cmd->tvc_sgl_count = sgl_count;
- pr_debug("Mapping %u iovecs for %u pages\n", niov, sgl_count);
+ pr_debug("Mapping iovec %p for %u pages\n", &iov[0], sgl_count);
+
for (i = 0; i < niov; i++) {
ret = vhost_scsi_map_to_sgl(cmd, sg, sgl_count, &iov[i],
- write);
+ cmd->tvc_upages, write);
if (ret < 0) {
for (i = 0; i < cmd->tvc_sgl_count; i++)
put_page(sg_page(&cmd->tvc_sgl[i]));
@@ -854,7 +846,6 @@ vhost_scsi_map_iov_to_sgl(struct tcm_vhost_cmd *cmd,
cmd->tvc_sgl_count = 0;
return ret;
}
-
sg += ret;
sgl_count -= ret;
}
@@ -1753,7 +1744,7 @@ static int tcm_vhost_make_nexus(struct tcm_vhost_tpg *tpg,
}
tv_cmd->tvc_upag
Re: linux-next: manual merge of the sound-asoc tree with the mvebu tree
On Mon, Feb 24, 2014 at 01:37:52PM +1100, Stephen Rothwell wrote: > I fixed it up (Probably incorrectly - see below) and can carry the fix as > necessary (no action is required). That looks right (or at least like it won't do any harm or cause bisection problems), thanks. signature.asc Description: Digital signature
Re: sched: hang in migrate_swap
On 02/24/2014 12:19 AM, Michael wang wrote: On 02/24/2014 11:23 AM, Sasha Levin wrote: [snip] >>> >>>Could I get a link to the patch please? It's a pain testing other things >>>with this issue reproducing every time. >> >>Please take a try on the latest tip tree, patches has been merged as I >>saw:) > >Nope, still see it with latest -tip. > >I ran tip's master branch, should I have tried a different one? Hmm... I don't see the changes we expected on master either... Peter, do we accidentally missed this commit? http://git.kernel.org/tip/477af336ba06ef4c32e97892bb0d2027ce30f466 I've tried grabbing this patch and it does pretty bad things on my testing VM, it just gets stuck early in the boot process and doesn't show any progress. The VM never even gets close to starting up all the cpus (usually dies around the lockdep self-testing). Are there any other dependencies? Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warning after merge of the tip tree
Hi all,
On Mon, 24 Feb 2014 15:17:32 +1100 Stephen Rothwell
wrote:
>
> I guess that there may be more places where "asmlinkage" is used with
> "static" - I assume that they are all incorrect?
>
> $ git grep -l 'static.*asmlinkage'
> arch/x86/crypto/sha1_ssse3_glue.c
> arch/x86/crypto/sha256_ssse3_glue.c
> arch/x86/crypto/sha512_ssse3_glue.c
In fact, my x86_64 allmodconfig build produces these:
arch/x86/crypto/sha1_ssse3_glue.c:43:1: warning: 'externally_visible' attribute
have effect only on public objects [-Wattributes]
static asmlinkage void (*sha1_transform_asm)(u32 *, const char *, unsigned
int);
^
arch/x86/crypto/sha256_ssse3_glue.c:56:1: warning: 'externally_visible'
attribute have effect only on public objects [-Wattributes]
static asmlinkage void (*sha256_transform_asm)(const char *, u32 *, u64);
^
arch/x86/crypto/sha512_ssse3_glue.c:55:1: warning: 'externally_visible'
attribute have effect only on public objects [-Wattributes]
static asmlinkage void (*sha512_transform_asm)(const char *, u64 *, u64);
^
mm/process_vm_access.c:422:1: warning: 'externally_visible' attribute have
effect only on public objects [-Wattributes]
{
^
That last is added by commit 700d00f85598 ("mm/process_vm_access.c: mark
function as static") from the akpm-current tree.
So is "static asmlinkage" not allowed?
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpVzKO3pn4Gd.pgp
Description: PGP signature
[RFC 4/6] vhost/scsi: Enable T10 PI IOV -> SGL memory mapping
From: Nicholas Bellinger
This patch updates vhost_scsi_handle_vq() to calculate a data_niov +
prot_niov currently based upon virtio_scsi_cmd_req->prio for figuring
out many of seperate data + protection SGLs to expect from data_num.
Also update tcm_vhost_submission_work() to pass the pre-allocated
cmd->tvc_prot_sgl[] memory into target_submit_cmd_map_sgls().
Cc: Michael S. Tsirkin
Cc: Paolo Bonzini
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
---
drivers/vhost/scsi.c | 45 ++---
1 file changed, 30 insertions(+), 15 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 0cf5948..3bdb625 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -908,18 +908,15 @@ static void tcm_vhost_submission_work(struct work_struct
*work)
container_of(work, struct tcm_vhost_cmd, work);
struct tcm_vhost_nexus *tv_nexus;
struct se_cmd *se_cmd = &cmd->tvc_se_cmd;
- struct scatterlist *sg_ptr, *sg_bidi_ptr = NULL;
- int rc, sg_no_bidi = 0;
+ struct scatterlist *sg_ptr, *sg_prot_ptr = NULL;
+ int rc;
+ /* FIXME: BIDI operation */
if (cmd->tvc_sgl_count) {
sg_ptr = cmd->tvc_sgl;
-/* FIXME: Fix BIDI operation in tcm_vhost_submission_work() */
-#if 0
- if (se_cmd->se_cmd_flags & SCF_BIDI) {
- sg_bidi_ptr = NULL;
- sg_no_bidi = 0;
- }
-#endif
+
+ if (cmd->tvc_prot_sgl_count)
+ sg_prot_ptr = cmd->tvc_prot_sgl;
} else {
sg_ptr = NULL;
}
@@ -930,7 +927,7 @@ static void tcm_vhost_submission_work(struct work_struct
*work)
cmd->tvc_lun, cmd->tvc_exp_data_len,
cmd->tvc_task_attr, cmd->tvc_data_direction,
TARGET_SCF_ACK_KREF, sg_ptr, cmd->tvc_sgl_count,
- sg_bidi_ptr, sg_no_bidi, NULL, 0);
+ NULL, 0, sg_prot_ptr, cmd->tvc_prot_sgl_count);
if (rc < 0) {
transport_send_check_condition_and_sense(se_cmd,
TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE, 0);
@@ -966,7 +963,7 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
vhost_virtqueue *vq)
struct tcm_vhost_cmd *cmd;
u32 exp_data_len, data_first, data_num, data_direction;
unsigned out, in, i;
- int head, ret;
+ int head, ret, data_niov, prot_niov;
u8 target;
mutex_lock(&vq->mutex);
@@ -998,7 +995,7 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
vhost_virtqueue *vq)
break;
}
-/* FIXME: BIDI operation */
+ /* FIXME: BIDI operation */
if (out == 1 && in == 1) {
data_direction = DMA_NONE;
data_first = 0;
@@ -1052,8 +1049,17 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
vhost_virtqueue *vq)
continue;
}
+ data_niov = data_num;
+ prot_niov = 0;
+
+ if (data_num && v_req.prio != 0) {
+ /* FIXME: Figure out a better way.. */
+ data_niov = data_num - v_req.prio;
+ prot_niov = v_req.prio;
+ }
+
exp_data_len = 0;
- for (i = 0; i < data_num; i++)
+ for (i = 0; i < data_niov; i++)
exp_data_len += vq->iov[data_first + i].iov_len;
cmd = vhost_scsi_get_tag(vq, tpg, &v_req,
@@ -1096,14 +1102,23 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
vhost_virtqueue *vq)
if (data_direction != DMA_NONE) {
ret = vhost_scsi_map_iov_to_sgl(cmd,
- &vq->iov[data_first], data_num,
+ &vq->iov[data_first], data_niov,
data_direction == DMA_FROM_DEVICE);
if (unlikely(ret)) {
vq_err(vq, "Failed to map iov to sgl\n");
goto err_free;
}
}
-
+ if (prot_niov) {
+ ret = vhost_scsi_map_iov_to_prot(cmd,
+ &vq->iov[data_first + data_niov],
prot_niov,
+ data_direction == DMA_FROM_DEVICE);
+ if (unlikely(ret)) {
+ vq_err(vq, "Failed to map iov to"
+ " prot_sgl\n");
+ goto err_free;
+ }
+ }
/*
* Save the descriptor from vhost_get_vq_desc() to be used to
* complet
[RFC 6/6] virtio-scsi: Enable DIF/DIX modes in SCSI host LLD
From: Nicholas Bellinger
This patch updates virtscsi_probe() to setup all necessary Scsi_Host
level protection resources necessary to enable DIF on virtio-scsi
<-> vhost-scsi LUNs. Currently hardcoded to 1.
It changes virtscsi_add_cmd() so that outgoing / incoming protection
SGLs are attached after each data payload, and is currently using the
unused virtio_scsi_cmd_req->prio bits to signal the total number of
prot_sgl_count for vhost/scsi to expect.
Cc: Paolo Bonzini
Cc: Michael S. Tsirkin
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
---
drivers/scsi/virtio_scsi.c | 33 -
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 16bfd50..294466d 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -440,7 +440,7 @@ static int virtscsi_add_cmd(struct virtqueue *vq,
size_t req_size, size_t resp_size, gfp_t gfp)
{
struct scsi_cmnd *sc = cmd->sc;
- struct scatterlist *sgs[4], req, resp;
+ struct scatterlist *sgs[6], req, resp;
struct sg_table *out, *in;
unsigned out_num = 0, in_num = 0;
@@ -458,16 +458,22 @@ static int virtscsi_add_cmd(struct virtqueue *vq,
sgs[out_num++] = &req;
/* Data-out buffer. */
- if (out)
+ if (out) {
sgs[out_num++] = out->sgl;
+ if (scsi_prot_sg_count(sc))
+ sgs[out_num++] = scsi_prot_sglist(sc);
+ }
/* Response header. */
sg_init_one(&resp, &cmd->resp, resp_size);
sgs[out_num + in_num++] = &resp;
/* Data-in buffer */
- if (in)
+ if (in) {
sgs[out_num + in_num++] = in->sgl;
+ if (scsi_prot_sg_count(sc))
+ sgs[out_num + in_num++] = scsi_prot_sglist(sc);
+ }
return virtqueue_add_sgs(vq, sgs, out_num, in_num, cmd, gfp);
}
@@ -498,6 +504,7 @@ static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
{
struct virtio_scsi_cmd *cmd;
int ret;
+ u8 prio = 0;
struct Scsi_Host *shost = virtio_scsi_host(vscsi->vdev);
BUG_ON(scsi_sg_count(sc) > shost->sg_tablesize);
@@ -515,6 +522,10 @@ static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
memset(cmd, 0, sizeof(*cmd));
cmd->sc = sc;
+
+ if (scsi_prot_sg_count(sc))
+ prio = (u8)scsi_prot_sg_count(sc);
+
cmd->req.cmd = (struct virtio_scsi_cmd_req){
.lun[0] = 1,
.lun[1] = sc->device->id,
@@ -522,7 +533,7 @@ static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
.lun[3] = sc->device->lun & 0xff,
.tag = (unsigned long)sc,
.task_attr = VIRTIO_SCSI_S_SIMPLE,
- .prio = 0,
+ .prio = prio,
.crn = 0,
};
@@ -871,7 +882,7 @@ static int virtscsi_probe(struct virtio_device *vdev)
{
struct Scsi_Host *shost;
struct virtio_scsi *vscsi;
- int err;
+ int err, host_prot;
u32 sg_elems, num_targets;
u32 cmd_per_lun;
u32 num_queues;
@@ -921,6 +932,17 @@ static int virtscsi_probe(struct virtio_device *vdev)
shost->max_id = num_targets;
shost->max_channel = 0;
shost->max_cmd_len = VIRTIO_SCSI_CDB_SIZE;
+
+ /* FIXME: Figure out why this is broken.. */
+ if (1 || virtio_has_feature(vdev, VIRTIO_SCSI_F_T10_PI)) {
+ host_prot = SHOST_DIF_TYPE1_PROTECTION |
SHOST_DIF_TYPE2_PROTECTION |
+ SHOST_DIF_TYPE3_PROTECTION |
SHOST_DIX_TYPE1_PROTECTION |
+ SHOST_DIX_TYPE2_PROTECTION |
SHOST_DIX_TYPE3_PROTECTION;
+
+ scsi_host_set_prot(shost, host_prot);
+ scsi_host_set_guard(shost, SHOST_DIX_GUARD_CRC);
+ }
+
err = scsi_add_host(shost, &vdev->dev);
if (err)
goto scsi_add_host_failed;
@@ -990,6 +1012,7 @@ static struct virtio_device_id id_table[] = {
static unsigned int features[] = {
VIRTIO_SCSI_F_HOTPLUG,
VIRTIO_SCSI_F_CHANGE,
+ VIRTIO_SCSI_F_T10_PI,
};
static struct virtio_driver virtio_scsi_driver = {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 5/6] vhost/scsi: Add new VIRTIO_SCSI_F_T10_PI feature bit
From: Nicholas Bellinger
This patch adds a VIRTIO_SCSI_F_T10_PI feature bit for signaling
host support of accepting T10 protection information SGLs from
virtio-scsi guest.
Cc: Michael S. Tsirkin
Cc: Paolo Bonzini
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
---
drivers/vhost/scsi.c|3 ++-
include/linux/virtio_scsi.h |1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 3bdb625..734a76c 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -169,7 +169,8 @@ enum {
};
enum {
- VHOST_SCSI_FEATURES = VHOST_FEATURES | (1ULL << VIRTIO_SCSI_F_HOTPLUG)
+ VHOST_SCSI_FEATURES = VHOST_FEATURES | (1ULL << VIRTIO_SCSI_F_HOTPLUG) |
+ (1ULL << VIRTIO_SCSI_F_T10_PI)
};
#define VHOST_SCSI_MAX_TARGET 256
diff --git a/include/linux/virtio_scsi.h b/include/linux/virtio_scsi.h
index 4195b97..dc3764b 100644
--- a/include/linux/virtio_scsi.h
+++ b/include/linux/virtio_scsi.h
@@ -97,6 +97,7 @@ struct virtio_scsi_config {
#define VIRTIO_SCSI_F_INOUT0
#define VIRTIO_SCSI_F_HOTPLUG 1
#define VIRTIO_SCSI_F_CHANGE 2
+#define VIRTIO_SCSI_F_T10_PI 3
/* Response codes */
#define VIRTIO_SCSI_S_OK 0
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 3/6] vhost/scsi: Add T10 PI IOV -> SGL memory mapping logic
From: Nicholas Bellinger
This patch adds vhost_scsi_map_iov_to_prot() to perform the mapping of
T10 data integrity memory between virtio iov + struct scatterlist using
get_user_pages_fast() following existing code.
As with vhost_scsi_map_iov_to_sgl(), this does sanity checks against the
total prot_sgl_count vs. pre-allocated SGLs, and loops across protection
iovs using vhost_scsi_map_to_sgl() to perform the actual memory mapping.
Also update tcm_vhost_release_cmd() to release associated tvc_prot_sgl[]
struct page.
Cc: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Michael S. Tsirkin
Cc: Paolo Bonzini
Cc: Sagi Grimberg
Signed-off-by: Nicholas Bellinger
---
drivers/vhost/scsi.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 314cbd4..0cf5948 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -80,6 +80,7 @@ struct tcm_vhost_cmd {
u64 tvc_tag;
/* The number of scatterlists associated with this cmd */
u32 tvc_sgl_count;
+ u32 tvc_prot_sgl_count;
/* Saved unpacked SCSI LUN for tcm_vhost_submission_work() */
u32 tvc_lun;
/* Pointer to the SGL formatted memory from virtio-scsi */
@@ -458,12 +459,16 @@ static void tcm_vhost_release_cmd(struct se_cmd *se_cmd)
struct tcm_vhost_cmd *tv_cmd = container_of(se_cmd,
struct tcm_vhost_cmd, tvc_se_cmd);
struct se_session *se_sess = se_cmd->se_sess;
+ int i;
if (tv_cmd->tvc_sgl_count) {
- u32 i;
for (i = 0; i < tv_cmd->tvc_sgl_count; i++)
put_page(sg_page(&tv_cmd->tvc_sgl[i]));
}
+ if (tv_cmd->tvc_prot_sgl_count) {
+ for (i = 0; i < tv_cmd->tvc_prot_sgl_count; i++)
+ put_page(sg_page(&tv_cmd->tvc_prot_sgl[i]));
+ }
tcm_vhost_put_inflight(tv_cmd->inflight);
percpu_ida_free(&se_sess->sess_tag_pool, se_cmd->map_tag);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] zram: support REQ_DISCARD
zram is ram based block device and can be used by backend of filesystem.
When filesystem deletes a file, it normally doesn't do anything on data
block of that file. It just marks on metadata of that file. This behavior
has no problem on disk based block device, but has problems on ram based
block device, since we can't free memory used for data block. To overcome
this disadvantage, there is REQ_DISCARD functionality. If block device
support REQ_DISCARD and filesystem is mounted with discard option,
filesystem sends REQ_DISCARD to block device whenever some data blocks are
discarded. All we have to do is to handle this request.
This patch implements to flag up QUEUE_FLAG_DISCARD and handle this
REQ_DISCARD request. With it, we can free memory used by zram if it isn't
used.
Signed-off-by: Joonsoo Kim
---
This patch is based on master branch of linux-next tree.
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 5ec61be..cff2c0e 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -501,6 +501,20 @@ static int zram_bvec_rw(struct zram *zram, struct bio_vec
*bvec, u32 index,
return ret;
}
+static void zram_bio_discard(struct zram *zram, struct bio *bio)
+{
+ u32 index = bio->bi_iter.bi_sector >> SECTORS_PER_PAGE_SHIFT;
+ size_t n = bio->bi_iter.bi_size;
+
+ while (n >= PAGE_SIZE) {
+ write_lock(&zram->meta->tb_lock);
+ zram_free_page(zram, index);
+ write_unlock(&zram->meta->tb_lock);
+ index++;
+ n -= PAGE_SIZE;
+ }
+}
+
static void zram_reset_device(struct zram *zram, bool reset_capacity)
{
size_t index;
@@ -618,6 +632,12 @@ static void __zram_make_request(struct zram *zram, struct
bio *bio)
struct bio_vec bvec;
struct bvec_iter iter;
+ if (unlikely(bio->bi_rw & REQ_DISCARD)) {
+ zram_bio_discard(zram, bio);
+ bio_endio(bio, 0);
+ return;
+ }
+
index = bio->bi_iter.bi_sector >> SECTORS_PER_PAGE_SHIFT;
offset = (bio->bi_iter.bi_sector &
(SECTORS_PER_PAGE - 1)) << SECTOR_SHIFT;
@@ -784,6 +804,10 @@ static int create_device(struct zram *zram, int device_id)
ZRAM_LOGICAL_BLOCK_SIZE);
blk_queue_io_min(zram->disk->queue, PAGE_SIZE);
blk_queue_io_opt(zram->disk->queue, PAGE_SIZE);
+ zram->disk->queue->limits.discard_granularity = PAGE_SIZE;
+ zram->disk->queue->limits.max_discard_sectors = UINT_MAX;
+ zram->disk->queue->limits.discard_zeroes_data = 1;
+ queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, zram->disk->queue);
add_disk(zram->disk);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
xxx.refs.info is updated with kernels released last week
Hi, the following kernel cross references are added into www.xrefs.info linux-3.13.5 linux-3.13.4 linux-3.10.32 linux-3.10.31 linux-3.10.30 linux-3.4.82 linux-3.4.81 linux-3.4.80 linux-3.2.55 linux-3.2.54 linux-2.6.34.15 linux-2.6.34.14 linux-2.6.34.13 linux-2.6.34.12 linux-2.6.34.11 linux-2.6.34.10 linux-2.6.34.9 linux-2.6.34.8 ~ FYI... http://www.xrefs.info is made for open source community in the hope of making open source developers more productive. The site hosts many open source code projects' cross references based on OpenGrok, which is a very fast cross reference tool, and easy to use. To access, you can go to http://www.xrefs.info, select a project, pick a version. If you want to search the definition of a function, simply type it in the definition box; If you want to do a full search, type your text in the first box; If you want to search a file, simply type file name in file path box. Hit search button, That's it! The site covers following: - Linux kernel cross reference: from verion 0.01 - latest release, plus nightly linus' tree latest. - Linux boot loaders cross reference: u-boot, lilo, grub, syslinux,plus nightly latest. - Linux user space core packages cross reference - Android various releases cross reference, plus nightly latest. - Cloud computing other projects: - xen hypervisor cross reference - VirtualBox cross reference; - OpenStack cross reference - cloudStack cross reference. - Puppet cross reference - Salt cross reference - Cloud Foundary cross reference - OpenShift cross reference - Chef cross reference - Juju cross reference - Big data project Hadoop cross reference - BSD: FreeBSD cross reference, NetBSD cross reference, DragonflyBSD cross reference - Database: MySQL cross reference, MariaDB cross reference, mongoDB cross reference, redis, neo4j, hbase, cassandra - Languages: OpenJDK cross reference, Perl cross reference, Python cross reference, PHP cross reference. If you have any questions, comments or suggestions for the site, please let me know. Thanks. xrefs.i...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH for-next 2/4] epoll: epoll() syscall declaration
On Sun, Feb 23, 2014 at 9:32 PM, Eric Wong wrote: > Nathaniel Yazdani wrote: >> +asmlinkage long sys_epoll(int ep, struct epoll __user *in, >> + unsigned int inc, struct epoll __user *out, >> + unsigned int outc, int timeout); > > I can understand using the new struct for 'in', but 'out' could just be > "struct epoll_event *" like sys_epoll_wait, right? > >> asmlinkage long sys_epoll_wait(int epfd, struct epoll_event __user *events, Yeah and I went back and forth on that, it just seemed to me that the inconsistency could be confusing to others... maybe instead of defining a new struct to begin with it might make me sense to just have an 'infd' array of file descriptors in addition to an 'in' array of epoll_event struct (obviously the length of these would be identical). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[TRIVIAL][PATCH] x86/ioapic: Using printk in func print_entries avoiding print incomplete infos
Commit(afcc8a40a090f): Introduce x86_io_apic_ops.print_entries for
debugging. Using kernel parameter apci=debug/verbose, kernel print
the incomplete infomation if we don't enable CONFIG_DYNAMIC_DEBUG.
So using printk to replace.
Signed-off-by: Jianpeng Ma
---
arch/x86/kernel/apic/io_apic.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 6ad4658..26996fc 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1480,14 +1480,14 @@ void native_io_apic_print_entries(unsigned int apic,
unsigned int nr_entries)
{
int i;
- pr_debug(" NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:\n");
+ printk(KERN_DEBUG" NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:\n");
for (i = 0; i <= nr_entries; i++) {
struct IO_APIC_route_entry entry;
entry = ioapic_read_entry(apic, i);
- pr_debug(" %02x %02X ", i, entry.dest);
+ printk(KERN_DEBUG" %02x %02X ", i, entry.dest);
pr_cont("%1d%1d%1d %1d %1d"
"%1d%1d%02X\n",
entry.mask,
@@ -1506,7 +1506,7 @@ void intel_ir_io_apic_print_entries(unsigned int apic,
{
int i;
- pr_debug(" NR Indx Fmt Mask Trig IRR Pol Stat Indx2 Zero Vect:\n");
+ printk(KERN_DEBUG" NR Indx Fmt Mask Trig IRR Pol Stat Indx2 Zero
Vect:\n");
for (i = 0; i <= nr_entries; i++) {
struct IR_IO_APIC_route_entry *ir_entry;
@@ -1516,7 +1516,7 @@ void intel_ir_io_apic_print_entries(unsigned int apic,
ir_entry = (struct IR_IO_APIC_route_entry *)&entry;
- pr_debug(" %02x %04X ", i, ir_entry->index);
+ printk(KERN_DEBUG " %02x %04X ", i, ir_entry->index);
pr_cont("%1d %1d%1d%1d %1d "
"%1d%1d %X%02X\n",
ir_entry->format,
--
1.7.10.4
Re: [PATCH 2/2] asoc: soc-core: fix coccinelle warnings
On Mon, Feb 24, 2014 at 11:05:14AM +0800, Nenghua Cao wrote: > On 02/22/2014 10:52 AM, Mark Brown wrote: > > type changes. What coccinelle was suggesting here was to replace with a > > simple assingment statement rather than change the argument within the > > memcpy(), I think this stops the warning showing because of that issue > I am not familiar with coccinelle. But it isn't reasonable and > convenient to use simple assignment instead of memcpy() here. So let's > retain it. I will submit another patch to fix "Assignment of bool to > 0/1" issue. How do you think about it? Well, the two should be separate patches anyway but it's totally reasonable to do an assigment - what it's telling you is that with modern C "a = b" is valid even if a and b are structs. signature.asc Description: Digital signature
Re: [PATCH 2/3] regmap: Add API call apply but not register a patch file
On Sun, Feb 23, 2014 at 04:11:59PM +, Charles Keepax wrote: > On Sat, Feb 22, 2014 at 11:10:48AM +0900, Mark Brown wrote: > > This is just regmap_multi_reg_write() I think? That already exists, the > > theory was that we're going to get an optimised version of that for some > > hardware which can stream things and cut out some overheads though that > > doesn't seem to have materialised yet. > I had missed regmap_multi_reg_write but the difference here is that we > apply cache bypass, and that the cache bypass is only applied whilst the > regmap lock is held. This allows users to be sure that no writes > from other threads will accidentally have the bypass applied to them. Right, OK - but it should still be a wrapper for a core implementation and share interface/naming. signature.asc Description: Digital signature
Re: [RFC PATCH 3/6] PM / Voltagedomain: introduce voltage domain driver support
On Tue, Feb 18, 2014 at 02:32:20PM -0600, Nishanth Menon wrote:
> The current regulator model provides the basic building blocks for the
> transitions, however SoC drivers specific to each of these devices, be
> it cpufreq/devfreq have to replicate the logic for functionality.
> To simply the logic, we can hence introduce a layer that takes care
> of the mundane transition logic, registration mechanisms to provide
> the "user drivers" such as cpufreq/devfreq a generic interface, whose
> details are abstracted by the device tree description for the SoC on
> which the driver operates on.
This doesn't really provide a picture of what the generic interface
that's being offered is and...
> drivers/power/voltdm/Kconfig |5 +
> drivers/power/voltdm/Makefile |3 +
> drivers/power/voltdm/core.c | 347
> +++--
> drivers/power/voltdm/voltage_domain_private.h | 86 ++
> 4 files changed, 424 insertions(+), 17 deletions(-)
...the diffstat doesn't make it obvious what the external interface is
either. It would be much easier to review this with a clearer picture
of what it's aiming to implement.
> + voltdm_np = of_parse_phandle(np, prop_name, 0);
> + if (voltdm_np) {
> + ret = of_parse_phandle_with_args(np, prop_name, "#voltdm-cells",
> + 0, args);
> + if (ret)
> + return ERR_PTR(ret);
There seems to be some DT stuff going on here, is the interface DT only?
signature.asc
Description: Digital signature
Re: [RFC] drivercore: deferral race condition fix
On Mon, Dec 23, 2013 at 02:41:31PM +0200, Peter Ujfalusi wrote: > The proposed solution is to try the deferred queue once more when the last > driver is asking for deferring and we had drivers probed while this last > driver was probing. Greg, this patch doesn't seem to have been applied but it looks like it's addressing a real issue and seems like a reasonable fix? Peter's analysis seems good to me. signature.asc Description: Digital signature
Re: [PATCH] [RFC] spi: spidev: Add support for Dual/Quad SPI Transfers
On Fri, Feb 21, 2014 at 05:14:53PM +0100, Geert Uytterhoeven wrote: > The Kconfig entry for SPI_SPIDEV states: > Note that this application programming interface is EXPERIMENTAL > and hence SUBJECT TO CHANGE WITHOUT NOTICE while it stabilizes. > So it's OK to break binary compatibility? > Or should we introduce PI_IOC_RD_MODE16 and SPI_IOC_WR_MODE16 instead? I think it's been experimental for so long that it has become a stable interface I'm afraid - the new calls would be better. Why not go for 32 bits instead of 16 bits for the new calls, that way it'll take longer to fill up again? signature.asc Description: Digital signature
Re: [RFC PATCH for-next 2/4] epoll: epoll() syscall declaration
Nathaniel Yazdani wrote: > +asmlinkage long sys_epoll(int ep, struct epoll __user *in, > + unsigned int inc, struct epoll __user *out, > + unsigned int outc, int timeout); I can understand using the new struct for 'in', but 'out' could just be "struct epoll_event *" like sys_epoll_wait, right? > asmlinkage long sys_epoll_wait(int epfd, struct epoll_event __user *events, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RESEND] [media] davinci: vpfe: remove deprecated IRQF_DISABLED
Hi Michael, On Thu, Feb 20, 2014 at 6:47 PM, Michael Opdenacker wrote: > Hi Laurent, > > On 02/20/2014 12:36 PM, Laurent Pinchart wrote: >> Hi Michael, >> >> What's the status of this patch ? Do expect Prabhakar to pick it up, or do >> you >> plan to push all your IRQF_DISABLED removal patches in one go ? > It's true a good number of my patches haven't been picked up yet, even > after multiple resends. > > I was planning to ask the community tomorrow about what to do to finally > get rid of IRQF_DISABLED. Effectively, pushing all the remaining changes > in one go (or removing the definition of IRQF_DISABLED) may be the final > solution. > > I hope to be able to answer your question by the end of the week. > gentle ping. should I pick it up ? Regards, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH for-next 1/4] epoll: struct epoll userspace definiton
Nathaniel Yazdani wrote:
> +++ b/include/uapi/linux/eventpoll.h
> @@ -61,6 +61,12 @@ struct epoll_event {
> __u64 data;
> } EPOLL_PACKED;
>
> +struct epoll {
> + int ep_fildes; /* file descriptor */
> + int ep_events; /* triggering events */
> + long long ep_ident; /* entry ID (cf. epoll_event->data) */
> +} EPOLL_PACKED;
Why not reuse the existing epoll_event struct?
struct epoll {
int ep_fildes; /* file descriptor */
struct epoll_event event;
} EPOLL_PACKED;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/5] arch: atomic rework
On Sun, Feb 23, 2014 at 8:59 PM, Paul E. McKenney wrote: > On Sun, Feb 23, 2014 at 05:35:28PM -0800, Linus Torvalds wrote: >> >> But "q = p->next" is ordered by how something can alias "p->next", not by >> 'q'! >> >> There is no need to restrict anything but 'p' for all of this to work. > > I cannot say I understand this last sentence right new from the viewpoint > of the standard, but suspending disbelief for the moment... So 'p' is what comes from that consuming load that returns a 'restrict' pointer. That doesn't affect 'q' in any way. But the act of initializing 'q' by dereferencing p (in "p->next") is - by virtue of the restrict - something that the compiler can see cannot alias with anything else, so the compiler could re-order other memory accesses freely around it, if you see what I mean. Modulo all the *other* ordering guarantees, of course. So other atomics and volatiles etc may have their own rules, quite apart from any aliasing issues. > Understood -- in this variant, you are taking the marking from the > fact that there was an assignment from a memory_order_consume load > rather than from a keyword on the assigned-to variable's declaration. Yes, and to me, it's really just a legalistic trick to make it clear that any *other* pointer that happens to point to the same object cannot be dereferenced within scope of the result of the atomic_read(mo_consume), at least not if you expect to get the memory ordering semantics. You can do it, but then you violate the guarantee of the restrict, and you get what you get - a potential non-ordering. So if somebody just immediately assigns the value to a normal (non-restrict) pointer nothing *really* changes. It's just there to describe the guarantees. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf_fuzzer compiled for x32 causes reboot
On 02/23/2014 07:02 PM, Vince Weaver wrote: > On Sun, 23 Feb 2014, Vince Weaver wrote: >> >> and as far as I can tell nothing touches rbp again until the segfault. >> Nothing in _memset_sse2 does as far as I can tell. > > I only know enough about ftrace to be dangerous, but here is what I think > is the trace of the problem: > > perf_fuzzer-11492 [000] 197077.488420: function: > perf_output_put_handle > perf_fuzzer-11492 [000] 197077.488421: function: > __do_page_fault So we do a write to the buffer rather immediately before this happens, and in particular that will update the head: rb->user_page->data_head = head; However, that doesn't explain what is going on and in particular the write to whatever address was in %rbp. The rest pretty much seems to be the page fault logic. Incidentally, I doubt that this is x32-related in any way; there seems to be absolutely no difference between x86-64 perf and x32 perf; more likely it just makes the error more reproducible because the address space is so much smaller. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched: hang in migrate_swap
On 02/24/2014 11:23 AM, Sasha Levin wrote: [snip] >>> >>> Could I get a link to the patch please? It's a pain testing other things >>> with this issue reproducing every time. >> >> Please take a try on the latest tip tree, patches has been merged as I >> saw :) > > Nope, still see it with latest -tip. > > I ran tip's master branch, should I have tried a different one? Hmm... I don't see the changes we expected on master either... Peter, do we accidentally missed this commit? http://git.kernel.org/tip/477af336ba06ef4c32e97892bb0d2027ce30f466 Regards, Michael Wang > > > Thanks, > sasha > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm/zswap: support multiple swap devices
Cai Liu reporeted that now zbud pool pages counting has a problem
when multiple swap is used because it just counts only one swap
intead of all of swap so zswap cannot control writeback properly.
The result is unnecessary writeback or no writeback when we should
really writeback.
IOW, it made zswap crazy.
Another problem in zswap is following as.
For example, let's assume we use two swap A and B with different
priority and A already has charged 19% long time ago and let's assume
that A swap is full now so VM start to use B so that B has charged 1%
recently. It menas zswap charged (19% + 1%) is full by default.
Then, if VM want to swap out more pages into B, zbud_reclaim_page
would be evict one of pages in B's pool and it would be repeated
continuously. It's totally LRU reverse problem and swap thrashing
in B would happen.
This patch makes zswap consider mutliple swap by creating *a* zbud
pool which will be shared by multiple swap so all of zswap pages
in multiple swap keep order by LRU so it can prevent above two
problems.
Cc: Bob Liu
Cc: Seth Jennings
Reported-by: Cai Liu
Suggested-by: Weijie Yang
Signed-off-by: Minchan Kim
---
mm/zswap.c | 64 --
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index 25312eb373a0..7ab2b36e3340 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -89,6 +89,9 @@ static unsigned int zswap_max_pool_percent = 20;
module_param_named(max_pool_percent,
zswap_max_pool_percent, uint, 0644);
+/* zbud_pool is shared by all of zswap backend */
+static struct zbud_pool *shared_mem_pool;
+
/*
* compression functions
**/
@@ -189,7 +192,6 @@ struct zswap_header {
struct zswap_tree {
struct rb_root rbroot;
spinlock_t lock;
- struct zbud_pool *pool;
};
static struct zswap_tree *zswap_trees[MAX_SWAPFILES];
@@ -285,13 +287,12 @@ static void zswap_rb_erase(struct rb_root *root, struct
zswap_entry *entry)
* Carries out the common pattern of freeing and entry's zbud allocation,
* freeing the entry itself, and decrementing the number of stored pages.
*/
-static void zswap_free_entry(struct zswap_tree *tree,
- struct zswap_entry *entry)
+static void zswap_free_entry(struct zswap_entry *entry)
{
- zbud_free(tree->pool, entry->handle);
+ zbud_free(shared_mem_pool, entry->handle);
zswap_entry_cache_free(entry);
atomic_dec(&zswap_stored_pages);
- zswap_pool_pages = zbud_get_pool_size(tree->pool);
+ zswap_pool_pages = zbud_get_pool_size(shared_mem_pool);
}
/* caller must hold the tree lock */
@@ -311,7 +312,7 @@ static void zswap_entry_put(struct zswap_tree *tree,
BUG_ON(refcount < 0);
if (refcount == 0) {
zswap_rb_erase(&tree->rbroot, entry);
- zswap_free_entry(tree, entry);
+ zswap_free_entry(entry);
}
}
@@ -545,7 +546,7 @@ static int zswap_writeback_entry(struct zbud_pool *pool,
unsigned long handle)
zbud_unmap(pool, handle);
tree = zswap_trees[swp_type(swpentry)];
offset = swp_offset(swpentry);
- BUG_ON(pool != tree->pool);
+ BUG_ON(pool != shared_mem_pool);
/* find and ref zswap entry */
spin_lock(&tree->lock);
@@ -573,13 +574,13 @@ static int zswap_writeback_entry(struct zbud_pool *pool,
unsigned long handle)
case ZSWAP_SWAPCACHE_NEW: /* page is locked */
/* decompress */
dlen = PAGE_SIZE;
- src = (u8 *)zbud_map(tree->pool, entry->handle) +
+ src = (u8 *)zbud_map(shared_mem_pool, entry->handle) +
sizeof(struct zswap_header);
dst = kmap_atomic(page);
ret = zswap_comp_op(ZSWAP_COMPOP_DECOMPRESS, src,
entry->length, dst, &dlen);
kunmap_atomic(dst);
- zbud_unmap(tree->pool, entry->handle);
+ zbud_unmap(shared_mem_pool, entry->handle);
BUG_ON(ret);
BUG_ON(dlen != PAGE_SIZE);
@@ -652,7 +653,7 @@ static int zswap_frontswap_store(unsigned type, pgoff_t
offset,
/* reclaim space if needed */
if (zswap_is_full()) {
zswap_pool_limit_hit++;
- if (zbud_reclaim_page(tree->pool, 8)) {
+ if (zbud_reclaim_page(shared_mem_pool, 8)) {
zswap_reject_reclaim_fail++;
ret = -ENOMEM;
goto reject;
@@ -679,7 +680,7 @@ static int zswap_frontswap_store(unsigned type, pgoff_t
offset,
/* store */
len = dlen + sizeof(struct zswap_header);
- ret = zbud_alloc(tree->pool, len, __GFP_NORETRY | __GFP_NOWARN,
+ ret = zbud_alloc(shared_mem_pool, len, __GFP_NORETRY | __GFP_NOWARN,
&handle);
if (ret == -ENOS
[PATCH 10/10] sched: clean up task_hot function
task_hot doesn't need the 'sched_domain' parameter, so remove it.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6469c7a..b0c189d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5003,7 +5003,7 @@ static void move_task(struct task_struct *p, struct
lb_env *env)
* Is this task likely cache-hot:
*/
static int
-task_hot(struct task_struct *p, u64 now, struct sched_domain *sd)
+task_hot(struct task_struct *p, u64 now)
{
s64 delta;
@@ -5164,7 +5164,7 @@ int can_migrate_task(struct task_struct *p, struct lb_env
*env)
* 2) task is cache cold, or
* 3) too many balance attempts have failed.
*/
- tsk_cache_hot = task_hot(p, rq_clock_task(env->src_rq), env->sd);
+ tsk_cache_hot = task_hot(p, rq_clock_task(env->src_rq));
if (!tsk_cache_hot)
tsk_cache_hot = migrate_degrades_locality(p, env);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/10] sched: rewrite update_cpu_load_nohz
After change to sched_avg, the cpu load in idle exit was decayed.
So, it maybe near zero if waking a long time sleep task, or, a full
non-decay load if waking a new forked task. Then, we can use it to
reflect the cpu load, don't need to pretend 0.
Signed-off-by: Alex Shi
---
kernel/sched/proc.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/kernel/sched/proc.c b/kernel/sched/proc.c
index 057bb9b..383c4ba 100644
--- a/kernel/sched/proc.c
+++ b/kernel/sched/proc.c
@@ -461,28 +461,13 @@ void update_idle_cpu_load(struct rq *this_rq)
}
/*
- * Called from tick_nohz_idle_exit() -- try and fix up the ticks we missed.
+ * Called from tick_nohz_idle_exit()
*/
void update_cpu_load_nohz(void)
{
struct rq *this_rq = this_rq();
- unsigned long curr_jiffies = ACCESS_ONCE(jiffies);
- unsigned long pending_updates;
-
- if (curr_jiffies == this_rq->last_load_update_tick)
- return;
- raw_spin_lock(&this_rq->lock);
- pending_updates = curr_jiffies - this_rq->last_load_update_tick;
- if (pending_updates) {
- this_rq->last_load_update_tick = curr_jiffies;
- /*
-* We were idle, this means load 0, the current load might be
-* !0 due to remote wakeups and the sort.
-*/
- __update_cpu_load(this_rq, 0);
- }
- raw_spin_unlock(&this_rq->lock);
+ update_idle_cpu_load(this_rq);
}
#endif /* CONFIG_NO_HZ */
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/10] sched: rename update_*_cpu_load
Since we have no cpu_load update, rename the related functions:
s/update_idle_cpu_load/update_idle_rt_avg/
s/update_cpu_load_nohz/update_rt_avg_nohz/
s/update_cpu_load_active/update_avg_load_active/
No functional change.
Signed-off-by: Alex Shi
---
include/linux/sched.h| 2 +-
kernel/sched/core.c | 2 +-
kernel/sched/fair.c | 2 +-
kernel/sched/proc.c | 8
kernel/sched/sched.h | 4 ++--
kernel/time/tick-sched.c | 2 +-
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6c416c8..f6afcb3 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -174,7 +174,7 @@ extern unsigned long this_cpu_load(void);
extern void calc_global_load(unsigned long ticks);
-extern void update_cpu_load_nohz(void);
+extern void update_rt_avg_nohz(void);
extern unsigned long get_parent_ip(unsigned long addr);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 32602595..74dae0e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2431,7 +2431,7 @@ void scheduler_tick(void)
raw_spin_lock(&rq->lock);
update_rq_clock(rq);
curr->sched_class->task_tick(rq, curr, 0);
- update_cpu_load_active(rq);
+ update_avg_load_active(rq);
raw_spin_unlock(&rq->lock);
perf_event_task_tick();
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 66fa69b..6469c7a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6986,7 +6986,7 @@ static void nohz_idle_balance(struct rq *this_rq, enum
cpu_idle_type idle)
raw_spin_lock_irq(&rq->lock);
update_rq_clock(rq);
- update_idle_cpu_load(rq);
+ update_idle_rt_avg(rq);
raw_spin_unlock_irq(&rq->lock);
rebalance_domains(rq, CPU_IDLE);
diff --git a/kernel/sched/proc.c b/kernel/sched/proc.c
index dd3c2d9..42b7706 100644
--- a/kernel/sched/proc.c
+++ b/kernel/sched/proc.c
@@ -423,7 +423,7 @@ static void calc_load_account_active(struct rq *this_rq)
* Called from nohz_idle_balance() to update the load ratings before doing the
* idle balance.
*/
-void update_idle_cpu_load(struct rq *this_rq)
+void update_idle_rt_avg(struct rq *this_rq)
{
unsigned long curr_jiffies = ACCESS_ONCE(jiffies);
@@ -440,17 +440,17 @@ void update_idle_cpu_load(struct rq *this_rq)
/*
* Called from tick_nohz_idle_exit()
*/
-void update_cpu_load_nohz(void)
+void update_rt_avg_nohz(void)
{
struct rq *this_rq = this_rq();
- update_idle_cpu_load(this_rq);
+ update_idle_rt_avg(this_rq);
}
#endif /* CONFIG_NO_HZ */
/*
* Called from scheduler_tick()
*/
-void update_cpu_load_active(struct rq *this_rq)
+void update_avg_load_active(struct rq *this_rq)
{
this_rq->last_load_update_tick = jiffies;
sched_avg_update(this_rq);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index c623131..ab310c2 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -21,7 +21,7 @@ extern unsigned long calc_load_update;
extern atomic_long_t calc_load_tasks;
extern long calc_load_fold_active(struct rq *this_rq);
-extern void update_cpu_load_active(struct rq *this_rq);
+extern void update_avg_load_active(struct rq *this_rq);
/*
* Helpers for converting nanosecond timing to jiffy resolution
@@ -1194,7 +1194,7 @@ extern void init_dl_task_timer(struct sched_dl_entity
*dl_se);
unsigned long to_ratio(u64 period, u64 runtime);
-extern void update_idle_cpu_load(struct rq *this_rq);
+extern void update_idle_rt_avg(struct rq *this_rq);
extern void init_task_runnable_average(struct task_struct *p);
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 9f8af69..b1a400a 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -866,7 +866,7 @@ static void tick_nohz_restart_sched_tick(struct tick_sched
*ts, ktime_t now)
{
/* Update jiffies first */
tick_do_update_jiffies64(now);
- update_cpu_load_nohz();
+ update_rt_avg_nohz();
calc_load_exit_idle();
touch_softlockup_watchdog();
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/10] sched: remove rq->cpu_load and rq->nr_load_updates
The cpu_load is the copy of rq->cfs.runnable_load_avg. And it updated
on time. So we can use the latter directly. Thus saved 2 rq variables:
cpu_load and nr_load_updates.
Then don't need __update_cpu_load(), just keep sched_avg_update().
Thus removed get_rq_runnable_load() which used for update_cpu_load only.
Signed-off-by: Alex Shi
---
kernel/sched/core.c | 2 --
kernel/sched/debug.c | 2 --
kernel/sched/proc.c | 55 +---
kernel/sched/sched.h | 2 --
4 files changed, 13 insertions(+), 48 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ac2f10c..32602595 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6800,8 +6800,6 @@ void __init sched_init(void)
INIT_LIST_HEAD(&rq->leaf_rt_rq_list);
init_tg_rt_entry(&root_task_group, &rq->rt, NULL, i, NULL);
#endif
-
- rq->cpu_load = 0;
rq->last_load_update_tick = jiffies;
#ifdef CONFIG_SMP
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index a24d549..83737ce 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -298,12 +298,10 @@ do {
\
SEQ_printf(m, " .%-30s: %lu\n", "load",
rq->load.weight);
P(nr_switches);
- P(nr_load_updates);
P(nr_uninterruptible);
PN(next_balance);
SEQ_printf(m, " .%-30s: %ld\n", "curr->pid",
(long)(task_pid_nr(rq->curr)));
PN(clock);
- P(cpu_load);
#undef P
#undef PN
diff --git a/kernel/sched/proc.c b/kernel/sched/proc.c
index 383c4ba..dd3c2d9 100644
--- a/kernel/sched/proc.c
+++ b/kernel/sched/proc.c
@@ -8,12 +8,19 @@
#include "sched.h"
+#ifdef CONFIG_SMP
unsigned long this_cpu_load(void)
{
- struct rq *this = this_rq();
- return this->cpu_load;
+ struct rq *rq = this_rq();
+ return rq->cfs.runnable_load_avg;
}
-
+#else
+unsigned long this_cpu_load(void)
+{
+ struct rq *rq = this_rq();
+ return rq->load.weight;
+}
+#endif
/*
* Global load-average calculations
@@ -398,34 +405,6 @@ static void calc_load_account_active(struct rq *this_rq)
* End of global load-average stuff
*/
-
-/*
- * Update rq->cpu_load statistics. This function is usually called every
- * scheduler tick (TICK_NSEC). With tickless idle this will not be called
- * every tick. We fix it up based on jiffies.
- */
-static void __update_cpu_load(struct rq *this_rq, unsigned long this_load)
-{
- this_rq->nr_load_updates++;
-
- /* Update our load: */
- this_rq->cpu_load = this_load; /* Fasttrack for idx 0 */
-
- sched_avg_update(this_rq);
-}
-
-#ifdef CONFIG_SMP
-static inline unsigned long get_rq_runnable_load(struct rq *rq)
-{
- return rq->cfs.runnable_load_avg;
-}
-#else
-static inline unsigned long get_rq_runnable_load(struct rq *rq)
-{
- return rq->load.weight;
-}
-#endif
-
#ifdef CONFIG_NO_HZ_COMMON
/*
* There is no sane way to deal with nohz on smp when using jiffies because the
@@ -447,17 +426,15 @@ static inline unsigned long get_rq_runnable_load(struct
rq *rq)
void update_idle_cpu_load(struct rq *this_rq)
{
unsigned long curr_jiffies = ACCESS_ONCE(jiffies);
- unsigned long load = get_rq_runnable_load(this_rq);
/*
* bail if there's load or we're actually up-to-date.
*/
- if (load || curr_jiffies == this_rq->last_load_update_tick)
+ if (curr_jiffies == this_rq->last_load_update_tick)
return;
this_rq->last_load_update_tick = curr_jiffies;
-
- __update_cpu_load(this_rq, load);
+ sched_avg_update(this_rq);
}
/*
@@ -466,7 +443,6 @@ void update_idle_cpu_load(struct rq *this_rq)
void update_cpu_load_nohz(void)
{
struct rq *this_rq = this_rq();
-
update_idle_cpu_load(this_rq);
}
#endif /* CONFIG_NO_HZ */
@@ -476,12 +452,7 @@ void update_cpu_load_nohz(void)
*/
void update_cpu_load_active(struct rq *this_rq)
{
- unsigned long load = get_rq_runnable_load(this_rq);
- /*
-* See the mess around update_idle_cpu_load() / update_cpu_load_nohz().
-*/
this_rq->last_load_update_tick = jiffies;
- __update_cpu_load(this_rq, load);
-
+ sched_avg_update(this_rq);
calc_load_account_active(this_rq);
}
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 5b2d4a1..c623131 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -517,7 +517,6 @@ struct rq {
unsigned int nr_numa_running;
unsigned int nr_preferred_running;
#endif
- unsigned long cpu_load;
unsigned long last_load_update_tick;
#ifdef CONFIG_NO_HZ_COMMON
u64 nohz_stamp;
@@ -530,7 +529,6 @@ struct rq {
/* capture load from *all* tasks on this cpu: */
struct load_weight load;
- unsigned long nr_load_updates;
u64 nr_switches;
struct cfs_rq cfs;
--
[PATCH 06/10] sched: clean up source_load/target_load
Don't need 'rq' variable now.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 5a3ea72..d91d925 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3954,13 +3954,7 @@ static unsigned long weighted_cpuload(const int cpu)
*/
static unsigned long source_load(int cpu)
{
- struct rq *rq = cpu_rq(cpu);
- unsigned long total = weighted_cpuload(cpu);
-
- if (!sched_feat(LB_BIAS))
- return total;
-
- return min(rq->cpu_load, total);
+ return weighted_cpuload(cpu);
}
/*
@@ -3969,7 +3963,6 @@ static unsigned long source_load(int cpu)
*/
static unsigned long target_load(int cpu, int imbalance_pct)
{
- struct rq *rq = cpu_rq(cpu);
unsigned long total = weighted_cpuload(cpu);
if (!sched_feat(LB_BIAS))
@@ -3978,9 +3971,7 @@ static unsigned long target_load(int cpu, int
imbalance_pct)
/*
* Bias target load with imbalance_pct.
*/
- total = total * imbalance_pct / 100;
-
- return max(rq->cpu_load, total);
+ return total * imbalance_pct / 100;
}
static unsigned long power_of(int cpu)
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/10] sched: unify imbalance bias for target group
Old code considers the bias in source/target_load already. but still
use imbalance_pct as last check in idlest/busiest group finding. It is
also a kind of redundant job. If we bias imbalance in source/target_load,
we'd better not use imbalance_pct again.
After cpu_load array removed, it is nice time to unify the target bias
consideration. So I remove the imbalance_pct from last check and add the
live bias using.
On wake_affine, since all archs' wake_idx is 0, current logical is just
want to prefer current cpu. so we follows this logical. Just renaming the
target_load/source_load to wegithed_cpuload for more exact meaning.
Thanks for reminding from Morten!
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index eeffe75..5a3ea72 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1016,7 +1016,7 @@ bool should_numa_migrate_memory(struct task_struct *p,
struct page * page,
static unsigned long weighted_cpuload(const int cpu);
static unsigned long source_load(int cpu);
-static unsigned long target_load(int cpu);
+static unsigned long target_load(int cpu, int imbalance_pct);
static unsigned long power_of(int cpu);
static long effective_load(struct task_group *tg, int cpu, long wl, long wg);
@@ -3967,7 +3967,7 @@ static unsigned long source_load(int cpu)
* Return a high guess at the load of a migration-target cpu weighted
* according to the scheduling class and "nice" value.
*/
-static unsigned long target_load(int cpu)
+static unsigned long target_load(int cpu, int imbalance_pct)
{
struct rq *rq = cpu_rq(cpu);
unsigned long total = weighted_cpuload(cpu);
@@ -3975,6 +3975,11 @@ static unsigned long target_load(int cpu)
if (!sched_feat(LB_BIAS))
return total;
+ /*
+* Bias target load with imbalance_pct.
+*/
+ total = total * imbalance_pct / 100;
+
return max(rq->cpu_load, total);
}
@@ -4190,8 +4195,8 @@ static int wake_affine(struct sched_domain *sd, struct
task_struct *p, int sync)
this_cpu = smp_processor_id();
prev_cpu = task_cpu(p);
- load = source_load(prev_cpu);
- this_load = target_load(this_cpu);
+ load = weighted_cpuload(prev_cpu);
+ this_load = weighted_cpuload(this_cpu);
/*
* If sync wakeup then subtract the (maximum possible)
@@ -4247,7 +4252,7 @@ static int wake_affine(struct sched_domain *sd, struct
task_struct *p, int sync)
if (balanced ||
(this_load <= load &&
-this_load + target_load(prev_cpu) <= tl_per_task)) {
+this_load + weighted_cpuload(prev_cpu) <= tl_per_task)) {
/*
* This domain has SD_WAKE_AFFINE and
* p is cache cold in this domain, and
@@ -4293,7 +4298,7 @@ find_idlest_group(struct sched_domain *sd, struct
task_struct *p, int this_cpu)
if (local_group)
load = source_load(i);
else
- load = target_load(i);
+ load = target_load(i, imbalance);
avg_load += load;
}
@@ -4309,7 +4314,7 @@ find_idlest_group(struct sched_domain *sd, struct
task_struct *p, int this_cpu)
}
} while (group = group->next, group != sd->groups);
- if (!idlest || 100*this_load < imbalance*min_load)
+ if (!idlest || this_load < min_load)
return NULL;
return idlest;
}
@@ -5745,6 +5750,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
{
unsigned long load;
int i;
+ int bias = 100 + (env->sd->imbalance_pct - 100) / 2;
memset(sgs, 0, sizeof(*sgs));
@@ -5752,8 +5758,8 @@ static inline void update_sg_lb_stats(struct lb_env *env,
struct rq *rq = cpu_rq(i);
/* Bias balancing toward cpus of our domain */
- if (local_group)
- load = target_load(i);
+ if (local_group && env->idle != CPU_IDLE)
+ load = target_load(i, bias);
else
load = source_load(i);
@@ -6193,14 +6199,6 @@ static struct sched_group *find_busiest_group(struct
lb_env *env)
if ((local->idle_cpus < busiest->idle_cpus) &&
busiest->sum_nr_running <= busiest->group_weight)
goto out_balanced;
- } else {
- /*
-* In the CPU_NEWLY_IDLE, CPU_NOT_IDLE cases, use
-* imbalance_pct to be conservative.
-*/
- if (100 * busiest->avg_load <=
- env->sd->imbalance_pct * local->avg_load)
- goto out_balanced;
}
force_balance:
[PATCH 07/10] sched: replace source_load by weighted_cpuload
Now, without load_idx source_load is just weighted_cpuload, so
replace it to reduce a conception for cpu load.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d91d925..66fa69b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1015,7 +1015,6 @@ bool should_numa_migrate_memory(struct task_struct *p,
struct page * page,
}
static unsigned long weighted_cpuload(const int cpu);
-static unsigned long source_load(int cpu);
static unsigned long target_load(int cpu, int imbalance_pct);
static unsigned long power_of(int cpu);
static long effective_load(struct task_group *tg, int cpu, long wl, long wg);
@@ -3939,27 +3938,15 @@ static void dequeue_task_fair(struct rq *rq, struct
task_struct *p, int flags)
}
#ifdef CONFIG_SMP
-/* Used instead of source_load when we know the type == 0 */
+/* weighted cpu load with runnable time, 'nice' value on CFS class */
static unsigned long weighted_cpuload(const int cpu)
{
return cpu_rq(cpu)->cfs.runnable_load_avg;
}
/*
- * Return a low guess at the load of a migration-source cpu weighted
- * according to the scheduling class and "nice" value.
- *
- * We want to under-estimate the load of migration sources, to
- * balance conservatively.
- */
-static unsigned long source_load(int cpu)
-{
- return weighted_cpuload(cpu);
-}
-
-/*
* Return a high guess at the load of a migration-target cpu weighted
- * according to the scheduling class and "nice" value.
+ * according to the runnable time and "nice" value.
*/
static unsigned long target_load(int cpu, int imbalance_pct)
{
@@ -4287,7 +4274,7 @@ find_idlest_group(struct sched_domain *sd, struct
task_struct *p, int this_cpu)
for_each_cpu(i, sched_group_cpus(group)) {
/* Bias balancing toward cpus of our domain */
if (local_group)
- load = source_load(i);
+ load = weighted_cpuload(i);
else
load = target_load(i, imbalance);
@@ -5752,7 +5739,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
if (local_group && env->idle != CPU_IDLE)
load = target_load(i, bias);
else
- load = source_load(i);
+ load = weighted_cpuload(i);
sgs->group_load += load;
sgs->sum_nr_running += rq->nr_running;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/10] sched: clean up cpu_load update
Since we don't decay the rq->cpu_load, so we don't need the
pending_updates. But we still want update rq->rt_avg, so
still keep rq->last_load_update_tick and func __update_cpu_load.
Signed-off-by: Alex Shi
---
kernel/sched/proc.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/proc.c b/kernel/sched/proc.c
index a2435c5..057bb9b 100644
--- a/kernel/sched/proc.c
+++ b/kernel/sched/proc.c
@@ -404,8 +404,7 @@ static void calc_load_account_active(struct rq *this_rq)
* scheduler tick (TICK_NSEC). With tickless idle this will not be called
* every tick. We fix it up based on jiffies.
*/
-static void __update_cpu_load(struct rq *this_rq, unsigned long this_load,
- unsigned long pending_updates)
+static void __update_cpu_load(struct rq *this_rq, unsigned long this_load)
{
this_rq->nr_load_updates++;
@@ -449,7 +448,6 @@ void update_idle_cpu_load(struct rq *this_rq)
{
unsigned long curr_jiffies = ACCESS_ONCE(jiffies);
unsigned long load = get_rq_runnable_load(this_rq);
- unsigned long pending_updates;
/*
* bail if there's load or we're actually up-to-date.
@@ -457,10 +455,9 @@ void update_idle_cpu_load(struct rq *this_rq)
if (load || curr_jiffies == this_rq->last_load_update_tick)
return;
- pending_updates = curr_jiffies - this_rq->last_load_update_tick;
this_rq->last_load_update_tick = curr_jiffies;
- __update_cpu_load(this_rq, load, pending_updates);
+ __update_cpu_load(this_rq, load);
}
/*
@@ -483,7 +480,7 @@ void update_cpu_load_nohz(void)
* We were idle, this means load 0, the current load might be
* !0 due to remote wakeups and the sort.
*/
- __update_cpu_load(this_rq, 0, pending_updates);
+ __update_cpu_load(this_rq, 0);
}
raw_spin_unlock(&this_rq->lock);
}
@@ -499,7 +496,7 @@ void update_cpu_load_active(struct rq *this_rq)
* See the mess around update_idle_cpu_load() / update_cpu_load_nohz().
*/
this_rq->last_load_update_tick = jiffies;
- __update_cpu_load(this_rq, load, 1);
+ __update_cpu_load(this_rq, load);
calc_load_account_active(this_rq);
}
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/10] sched: shortcut to remove load_idx
Shortcut to remove rq->cpu_load[load_idx] effect in scheduler.
In five load idx, only busy_idx, idle_idx are not zero.
Newidle_idx, wake_idx and fork_idx are all zero in all archs.
So, change the idx to zero here can fully remove load_idx effect.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 235cfa7..4fcc3a3 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5908,7 +5908,7 @@ static inline void update_sd_lb_stats(struct lb_env *env,
struct sd_lb_stats *sd
if (child && child->flags & SD_PREFER_SIBLING)
prefer_sibling = 1;
- load_idx = get_sd_load_idx(env->sd, env->idle);
+ load_idx = 0;
do {
struct sg_lb_stats *sgs = &tmp_sgs;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 0/10] sched: remove cpu_load
The cpu_load decays on time according past cpu load of rq. The sched_avg also decays tasks' load on time. Now we has 2 kind decay for cpu_load. That is a kind of redundancy. And increase the system load by decay calculation. This patch try to remove the cpu_load decay. There are 5 load_idx used for cpu_load in sched_domain. busy_idx and idle_idx are not zero usually, but newidle_idx, wake_idx and forkexec_idx are all zero on every arch. A shortcut to remove cpu_Load decay in the first patch. just one line patch for this change. V3, 1, correct the wake_affine bias. Thanks for Morten's reminder! 2, replace source_load by weighted_cpuload for better function name meaning. V2, 1, This version do some tuning on load bias of target load. 2, Got further to remove the cpu_load in rq. 3, Revert the patch 'Limit sd->*_idx range on sysctl' since no needs Any testing/comments are appreciated. This patch rebase on latest tip/master. The git tree for this patchset at: g...@github.com:alexshi/power-scheduling.git noload -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/10] sched: remove rq->cpu_load[load_idx] array
Since load_idx effect removed in load balance, we don't need the
load_idx decays in scheduler. that will save some process in sched_tick
and others places.
Signed-off-by: Alex Shi
---
arch/ia64/include/asm/topology.h | 5 ---
arch/metag/include/asm/topology.h | 5 ---
arch/tile/include/asm/topology.h | 6 ---
include/linux/sched.h | 5 ---
include/linux/topology.h | 8
kernel/sched/core.c | 58 +++-
kernel/sched/debug.c | 6 +--
kernel/sched/fair.c | 79 +
kernel/sched/proc.c | 92 ++-
kernel/sched/sched.h | 3 +-
10 files changed, 42 insertions(+), 225 deletions(-)
diff --git a/arch/ia64/include/asm/topology.h b/arch/ia64/include/asm/topology.h
index a2496e4..54e5b17 100644
--- a/arch/ia64/include/asm/topology.h
+++ b/arch/ia64/include/asm/topology.h
@@ -55,11 +55,6 @@ void build_cpu_to_node_map(void);
.busy_factor= 64, \
.imbalance_pct = 125, \
.cache_nice_tries = 2,\
- .busy_idx = 2,\
- .idle_idx = 1,\
- .newidle_idx= 0,\
- .wake_idx = 0,\
- .forkexec_idx = 0,\
.flags = SD_LOAD_BALANCE \
| SD_BALANCE_NEWIDLE\
| SD_BALANCE_EXEC \
diff --git a/arch/metag/include/asm/topology.h
b/arch/metag/include/asm/topology.h
index 8e9c0b3..d1d15cd 100644
--- a/arch/metag/include/asm/topology.h
+++ b/arch/metag/include/asm/topology.h
@@ -13,11 +13,6 @@
.busy_factor= 32, \
.imbalance_pct = 125, \
.cache_nice_tries = 2,\
- .busy_idx = 3,\
- .idle_idx = 2,\
- .newidle_idx= 0,\
- .wake_idx = 0,\
- .forkexec_idx = 0,\
.flags = SD_LOAD_BALANCE \
| SD_BALANCE_FORK \
| SD_BALANCE_EXEC \
diff --git a/arch/tile/include/asm/topology.h b/arch/tile/include/asm/topology.h
index d15c0d8..05f6ffe 100644
--- a/arch/tile/include/asm/topology.h
+++ b/arch/tile/include/asm/topology.h
@@ -57,12 +57,6 @@ static inline const struct cpumask *cpumask_of_node(int node)
.busy_factor= 64, \
.imbalance_pct = 125, \
.cache_nice_tries = 1,\
- .busy_idx = 2,\
- .idle_idx = 1,\
- .newidle_idx= 0,\
- .wake_idx = 0,\
- .forkexec_idx = 0,\
- \
.flags = 1*SD_LOAD_BALANCE \
| 1*SD_BALANCE_NEWIDLE \
| 1*SD_BALANCE_EXEC \
diff --git a/include/linux/sched.h b/include/linux/sched.h
index c49a258..6c416c8 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -892,11 +892,6 @@ struct sched_domain {
unsigned int busy_factor; /* less balancing by factor if busy */
unsigned int imbalance_pct; /* No balance until over watermark */
unsigned int cache_nice_tries; /* Leave cache hot tasks for # tries */
- unsigned int busy_idx;
- unsigned int idle_idx;
- unsigned int newidle_idx;
- unsigned int wake_idx;
- unsigned int forkexec_idx;
unsigned int smt_gain;
int nohz_idle; /* NOHZ IDLE status */
diff --git a/include/linux/topology.h b/include/linux/topology.h
index 12ae6ce..863fad3 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -121,9 +121,6 @@ int arch_update_cpu_topology(void);
.busy_factor= 64, \
.imbalance_pct = 125, \
.cache_nice_tries = 1,\
- .busy_idx = 2,\
- .wake_idx = 0,\
- .forkexec_idx = 0,\
Re: [RFC][PATCH 0/5] arch: atomic rework
On Sun, Feb 23, 2014 at 05:35:28PM -0800, Linus Torvalds wrote: > On Sun, Feb 23, 2014 at 5:16 PM, Paul E. McKenney > wrote: > >> > >> (a) we've said 'q' is restricted, so there is no aliasing between q > >> and the pointers b/c. So the compiler is free to move those accesses > >> around the "q = p->next" access. > > > > Ah, if I understand you, very good! > > > > My example intentionally left "q" -not- restricted. > > No, I 100% agree with that. "q" is *not* restricted. But "p" is, since > it came from that consuming load. > > But "q = p->next" is ordered by how something can alias "p->next", not by 'q'! > > There is no need to restrict anything but 'p' for all of this to work. I cannot say I understand this last sentence right new from the viewpoint of the standard, but suspending disbelief for the moment... (And yes, given current compilers and CPUs, I agree that this should all work in practice. My concern is the legality, not the reality.) > Btw, it's also worth pointing out that I do *not* in any way expect > people to actually write the "restrict" keyword anywhere. So no need > to change source code. Understood -- in this variant, you are taking the marking from the fact that there was an assignment from a memory_order_consume load rather than from a keyword on the assigned-to variable's declaration. > What you have is a situation where the pointer coming out of the > memory_order_consume is restricted. But if you assign it to a > non-restricted pointer, that's *fine*. That's perfectly normal C > behavior. The "restrict" concept is not something that the programmer > needs to worry about or ever even notice, it's basically just a > promise to the compiler that "if somebody has another pointer lying > around, accesses though that other pointer do not require ordering". > > So it sounds like you believe that the programmer would mark things > "restrict", and I did not mean that at all. Indeed I did believe that. I must confess that I was looking for an easy way to express in standardese -exactly- where the ordering guarantee did and did not propagate. The thing is that the vast majority of the Linux-kernel RCU code is more than happy with the guarantee only applying to fetches via the pointer returned from the memory_order_consume load. There are relatively few places where groups of structures are made visible to RCU readers via a single rcu_assign_pointer(). I guess I need to actually count them. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9] slab: remove a useless lockdep annotation
On Tue, Feb 18, 2014 at 10:21:10AM -0600, Christoph Lameter wrote: > On Mon, 17 Feb 2014, Joonsoo Kim wrote: > > > > Why change the BAD_ALIEN_MAGIC? > > > > Hello, Christoph. > > > > BAD_ALIEN_MAGIC is only checked by slab_set_lock_classes(). We remove this > > function in this patch, so returning BAD_ALIEN_MAGIC is useless. > > Its not useless. The point is if there is a pointer deref then we will see > this as a pointer value and know that it is realted to alien cache > processing. > > > And, in fact, BAD_ALIEN_MAGIC is already useless, because > > alloc_alien_cache() > > can't be called on !CONFIG_NUMA. This function is called if use_alien_caches > > is positive, but on !CONFIG_NUMA, use_alien_caches is always 0. So we don't > > have any chance to meet this BAD_ALIEN_MAGIC in runtime. > > Maybe it no longer serves a point. But note that caches may not be > populated because processors/nodes are not up yet. Hello, Let me clarify about alloc_alien_cache(). alloc_alien_cache() has two definitions, one for !CONFIG_NUMA, and the other for CONFIG_NUMA. BAD_ALIEN_MAGIC is only assigned on !CONFIG_NUMA definition. On CONFIG_NUMA, alloc_alien_cache() doesn't use BAD_ALIEN_MAGIC. So it is sufficient to consider just !CONFIG_NUMA case. As I mentioned before, this function isn't called if use_alien_caches is zero and use_alien_caches is always zero on !CONFIG_NUMA. Therefore we cannot see BAD_ALIEN_MAGIC on any configuration. I don't know why BAD_ALIEN_MAGIC is introduced, however, it no longer serves a point, so it is better to remove it. There are lots of code to check whether processor/nodes are up or not and these doesn't use BAD_ALIEN_MAGIC. Instead, it checks NULL on alien_cache of specific node. So removing BAD_ALIEN_MAGIC doesn't harm anything here. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the rcu tree with the tip tree
On Mon, Feb 24, 2014 at 03:18:01PM +1100, Stephen Rothwell wrote:
> Hi Paul,
>
> Today's linux-next merge of the rcu tree got a conflict in
> kernel/rcu/rcutorture.c between commit d277d868dab6 ("rcu: Use MAX_NICE
> to replace hardcoding of 19") from the tip tree (where this file is
> called kernel/rcu/torture.c) and commit 5ccf60f23d33 ("rcutorture: Rename
> PRINTK to TOROUT") from the rcu tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Hello, Stephen,
Looks correct at first glance, thank you!
Thanx, Paul
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc kernel/rcu/rcutorture.c
> index 219761db1a46,f59d48597dde..
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@@ -802,10 -693,10 +693,10 @@@ rcu_torture_writer(void *arg
> struct rcu_torture *rp;
> struct rcu_torture *rp1;
> struct rcu_torture *old_rp;
> - static DEFINE_RCU_RANDOM(rand);
> + static DEFINE_TORTURE_RANDOM(rand);
>
> - VERBOSE_PRINTK_STRING("rcu_torture_writer task started");
> + VERBOSE_TOROUT_STRING("rcu_torture_writer task started");
> -set_user_nice(current, 19);
> +set_user_nice(current, MAX_NICE);
>
> do {
> schedule_timeout_uninterruptible(1);
> @@@ -868,19 -756,19 +756,19 @@@
> static int
> rcu_torture_fakewriter(void *arg)
> {
> - DEFINE_RCU_RANDOM(rand);
> + DEFINE_TORTURE_RANDOM(rand);
>
> - VERBOSE_PRINTK_STRING("rcu_torture_fakewriter task started");
> + VERBOSE_TOROUT_STRING("rcu_torture_fakewriter task started");
> -set_user_nice(current, 19);
> +set_user_nice(current, MAX_NICE);
>
> do {
> - schedule_timeout_uninterruptible(1 + rcu_random(&rand)%10);
> - udelay(rcu_random(&rand) & 0x3ff);
> + schedule_timeout_uninterruptible(1 + torture_random(&rand)%10);
> + udelay(torture_random(&rand) & 0x3ff);
> if (cur_ops->cb_barrier != NULL &&
> - rcu_random(&rand) % (nfakewriters * 8) == 0) {
> + torture_random(&rand) % (nfakewriters * 8) == 0) {
> cur_ops->cb_barrier();
> } else if (gp_normal == gp_exp) {
> - if (rcu_random(&rand) & 0x80)
> + if (torture_random(&rand) & 0x80)
> cur_ops->sync();
> else
> cur_ops->exp_sync();
> @@@ -986,8 -871,8 +871,8 @@@ rcu_torture_reader(void *arg
> struct timer_list t;
> unsigned long long ts;
>
> - VERBOSE_PRINTK_STRING("rcu_torture_reader task started");
> + VERBOSE_TOROUT_STRING("rcu_torture_reader task started");
> -set_user_nice(current, 19);
> +set_user_nice(current, MAX_NICE);
> if (irqreader && cur_ops->irq_capable)
> setup_timer_on_stack(&t, rcu_torture_timer, 0);
>
> @@@ -1583,8 -1160,8 +1160,8 @@@ static int rcu_torture_barrier_cbs(voi
> struct rcu_head rcu;
>
> init_rcu_head_on_stack(&rcu);
> - VERBOSE_PRINTK_STRING("rcu_torture_barrier_cbs task started");
> + VERBOSE_TOROUT_STRING("rcu_torture_barrier_cbs task started");
> -set_user_nice(current, 19);
> +set_user_nice(current, MAX_NICE);
> do {
> wait_event(barrier_cbs_wq[myid],
> (newphase =
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] can: xilinx CAN controller support.
This patch adds xilinx CAN controller support.
This driver supports both ZYNQ CANPS and Soft IP
AXI CAN controller.
Signed-off-by: Kedareswara rao Appana
---
This patch is rebased on the 3.14 rc4 kernel.
Changes for v4:
- Added check for the tx fifo full interrupt condition in
Tx interrupt routine.
- Added be io helper functions.
- Moved the clock enable/disable to probe/remove because of
Added big endian support for AXI CAN controller case(reading
a register during the probe for that we need to enable clock).
Changes for v3:
- Updated the driver with review comments.
- Modified the transmit logic as per Marc suggestion.
- Enabling the clocks when the interface is up to reduce the
Power consumption.
Changes for v2:
- Updated with the review comments.
- Removed the unnecessary debug prints.
- include tx,rx fifo depths in ZYNQ CANPS case also.
---
.../devicetree/bindings/net/can/xilinx_can.txt | 45 +
drivers/net/can/Kconfig|7 +
drivers/net/can/Makefile |1 +
drivers/net/can/xilinx_can.c | 1162
4 files changed, 1215 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/xilinx_can.txt
create mode 100644 drivers/net/can/xilinx_can.c
diff --git a/Documentation/devicetree/bindings/net/can/xilinx_can.txt
b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
new file mode 100644
index 000..0e57103
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
@@ -0,0 +1,45 @@
+Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings
+-
+
+Required properties:
+- compatible : Should be "xlnx,zynq-can-1.00.a" for Zynq CAN
+ controllers and "xlnx,axi-can-1.00.a" for Axi CAN
+ controllers.
+- reg : Physical base address and size of the Axi CAN/Zynq
+ CANPS registers map.
+- interrupts : Property with a value describing the interrupt
+ number.
+- interrupt-parent : Must be core interrupt controller
+- clock-names : List of input clock names - "ref_clk", "aper_clk"
+ (See clock bindings for details. Two clocks are
+ required for Zynq CAN. For Axi CAN
+ case it is one(ref_clk)).
+- clocks : Clock phandles (see clock bindings for details).
+- tx-fifo-depth: Can Tx fifo depth.
+- rx-fifo-depth: Can Rx fifo depth.
+
+
+Example:
+
+For Zynq CANPS Dts file:
+ zynq_can_0: zynq-can@e0008000 {
+ compatible = "xlnx,zynq-can-1.00.a";
+ clocks = <&clkc 19>, <&clkc 36>;
+ clock-names = "ref_clk", "aper_clk";
+ reg = <0xe0008000 0x1000>;
+ interrupts = <0 28 4>;
+ interrupt-parent = <&intc>;
+ tx-fifo-depth = <0x40>;
+ rx-fifo-depth = <0x40>;
+ };
+For Axi CAN Dts file:
+ axi_can_0: axi-can@4000 {
+ compatible = "xlnx,axi-can-1.00.a";
+ clocks = <&clkc 0>;
+ clock-names = "ref_clk" ;
+ reg = <0x4000 0x1>;
+ interrupt-parent = <&intc>;
+ interrupts = <0 59 1>;
+ tx-fifo-depth = <0x40>;
+ rx-fifo-depth = <0x40>;
+ };
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index 9e7d95d..b180239 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -125,6 +125,13 @@ config CAN_GRCAN
endian syntheses of the cores would need some modifications on
the hardware level to work.
+config CAN_XILINXCAN
+ tristate "Xilinx CAN"
+ depends on ARCH_ZYNQ || MICROBLAZE
+ ---help---
+ Xilinx CAN driver. This driver supports both soft AXI CAN IP and
+ Zynq CANPS IP.
+
source "drivers/net/can/mscan/Kconfig"
source "drivers/net/can/sja1000/Kconfig"
diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
index c744039..0b8e11e 100644
--- a/drivers/net/can/Makefile
+++ b/drivers/net/can/Makefile
@@ -25,5 +25,6 @@ obj-$(CONFIG_CAN_JANZ_ICAN3) += janz-ican3.o
obj-$(CONFIG_CAN_FLEXCAN) += flexcan.o
obj-$(CONFIG_PCH_CAN) += pch_can.o
obj-$(CONFIG_CAN_GRCAN)+= grcan.o
+obj-$(CONFIG_CAN_XILINXCAN)+= xilinx_can.o
ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
new file mode 100644
index 000..7564bef
--- /dev/null
+++ b/drivers/net/can/xilinx_can.c
@@ -0,0 +1,1162 @@
+/* Xilinx CAN device driver
+ *
+ * Copyright (C) 2012 - 2014 Xilinx, Inc.
+ * Copyright (C) 2009
Re: [PATCH v2 2/2] x86: Support compiling out human-friendly processor feature names
On 02/23/2014 01:55 PM, Josh Triplett wrote: > > Why have the build system waste time building several things that won't > be used? It seems like the Makefiles are exactly where we *should* have > the ifdef machinery, rather than in source. I'd happily add another > ifdef in the Makefile rule that builds cpustr.h, to generate a stub > cpustr.h header, and then remove one more ifdef in the source. > The ifdeffery in the Makefiles really tend to be more complicated than in the source code. The amount of code added from v2 to v3 when it could be handled by *removing* two lines in the Makefile makes it worth it. If it was enough build stuff to be anywhere near remotely significant it would be one thing. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the rcu tree with the tip tree
Hi Paul,
Today's linux-next merge of the rcu tree got a conflict in
kernel/rcu/rcutorture.c between commit d277d868dab6 ("rcu: Use MAX_NICE
to replace hardcoding of 19") from the tip tree (where this file is
called kernel/rcu/torture.c) and commit 5ccf60f23d33 ("rcutorture: Rename
PRINTK to TOROUT") from the rcu tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc kernel/rcu/rcutorture.c
index 219761db1a46,f59d48597dde..
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@@ -802,10 -693,10 +693,10 @@@ rcu_torture_writer(void *arg
struct rcu_torture *rp;
struct rcu_torture *rp1;
struct rcu_torture *old_rp;
- static DEFINE_RCU_RANDOM(rand);
+ static DEFINE_TORTURE_RANDOM(rand);
- VERBOSE_PRINTK_STRING("rcu_torture_writer task started");
+ VERBOSE_TOROUT_STRING("rcu_torture_writer task started");
- set_user_nice(current, 19);
+ set_user_nice(current, MAX_NICE);
do {
schedule_timeout_uninterruptible(1);
@@@ -868,19 -756,19 +756,19 @@@
static int
rcu_torture_fakewriter(void *arg)
{
- DEFINE_RCU_RANDOM(rand);
+ DEFINE_TORTURE_RANDOM(rand);
- VERBOSE_PRINTK_STRING("rcu_torture_fakewriter task started");
+ VERBOSE_TOROUT_STRING("rcu_torture_fakewriter task started");
- set_user_nice(current, 19);
+ set_user_nice(current, MAX_NICE);
do {
- schedule_timeout_uninterruptible(1 + rcu_random(&rand)%10);
- udelay(rcu_random(&rand) & 0x3ff);
+ schedule_timeout_uninterruptible(1 + torture_random(&rand)%10);
+ udelay(torture_random(&rand) & 0x3ff);
if (cur_ops->cb_barrier != NULL &&
- rcu_random(&rand) % (nfakewriters * 8) == 0) {
+ torture_random(&rand) % (nfakewriters * 8) == 0) {
cur_ops->cb_barrier();
} else if (gp_normal == gp_exp) {
- if (rcu_random(&rand) & 0x80)
+ if (torture_random(&rand) & 0x80)
cur_ops->sync();
else
cur_ops->exp_sync();
@@@ -986,8 -871,8 +871,8 @@@ rcu_torture_reader(void *arg
struct timer_list t;
unsigned long long ts;
- VERBOSE_PRINTK_STRING("rcu_torture_reader task started");
+ VERBOSE_TOROUT_STRING("rcu_torture_reader task started");
- set_user_nice(current, 19);
+ set_user_nice(current, MAX_NICE);
if (irqreader && cur_ops->irq_capable)
setup_timer_on_stack(&t, rcu_torture_timer, 0);
@@@ -1583,8 -1160,8 +1160,8 @@@ static int rcu_torture_barrier_cbs(voi
struct rcu_head rcu;
init_rcu_head_on_stack(&rcu);
- VERBOSE_PRINTK_STRING("rcu_torture_barrier_cbs task started");
+ VERBOSE_TOROUT_STRING("rcu_torture_barrier_cbs task started");
- set_user_nice(current, 19);
+ set_user_nice(current, MAX_NICE);
do {
wait_event(barrier_cbs_wq[myid],
(newphase =
pgpH3sCBAzTyb.pgp
Description: PGP signature
linux-next: build warning after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/irqchip/irq-armada-370-xp.c:415:1: warning: 'externally_visible'
attribute have effect only on public objects [-Wattributes]
drivers/irqchip/irq-sun4i.c:39:70: warning: 'externally_visible' attribute have
effect only on public objects [-Wattributes]
drivers/irqchip/irq-sun4i.c:140:1: warning: 'externally_visible' attribute have
effect only on public objects [-Wattributes]
drivers/irqchip/irq-gic.c:283:1: warning: 'externally_visible' attribute have
effect only on public objects [-Wattributes]
drivers/irqchip/irq-sirfsoc.c:51:1: warning: 'externally_visible' attribute
have effect only on public objects [-Wattributes]
drivers/irqchip/irq-vt8500.c:183:1: warning: 'externally_visible' attribute
have effect only on public objects [-Wattributes]
Probably introduced by commit 128ea04a9885 ("lto: Make asmlinkage __visible").
I guess that there may be more places where "asmlinkage" is used with
"static" - I assume that they are all incorrect?
$ git grep -l 'static.*asmlinkage'
arch/x86/crypto/sha1_ssse3_glue.c
arch/x86/crypto/sha256_ssse3_glue.c
arch/x86/crypto/sha512_ssse3_glue.c
drivers/irqchip/irq-armada-370-xp.c
drivers/irqchip/irq-bcm2835.c
drivers/irqchip/irq-gic.c
drivers/irqchip/irq-mmp.c
drivers/irqchip/irq-moxart.c
drivers/irqchip/irq-orion.c
drivers/irqchip/irq-sirfsoc.c
drivers/irqchip/irq-sun4i.c
drivers/irqchip/irq-vic.c
drivers/irqchip/irq-vt8500.c
drivers/irqchip/irq-zevio.c
drivers/pnp/pnpbios/bioscalls.c
scripts/checkpatch.pl
(the last two don't matter)
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpneVND71Qt1.pgp
Description: PGP signature
Re: [PATCH V4 3/4] ARM: shmobile: koelsch: Add USBHS and internal PCI USB support
On Mon, Feb 24, 2014 at 3:00 AM, wrote:
> From: Vladimir Barinov
>
> This adds the following to R-Car M2 Koelsch board:
> - USBHS PHY
> - USBHS device
> - internal PCI USB host devices
>
> Depending on state of ID pin from MAX3355E chip the usb0 is configured
> ether as host or gadget.
> In case of gadget the USBHS device is registered.
> In case of host the PCI USB is registered.
>
> The USB phy is bound to either USB host or USBHS device respectively, hence
> configured to ether channel 0 or 2.
>
> The USBHS can act as USB Host, and this can be easily configured.
> But the simplest test with storage stick connected to USBHS Host provides
> IP resets and system hangs. Even the PWEN pin is not handled and it is
> nessasary to
> provide VBUS using gpio. It is easy to see in RCAR H2/M2 documentation
> that the USBHS IP changed. F.e. the PWEN/EXTLP pins are no more presented in
> USBHS via DVSTCTR register. And others.
>
> Since the USBHS is not stable in Host mode lets connect fully tested PCI USB
> IP to usb0.
>
> Signed-off-by: Valentine Barshak
> Signed-off-by: Vladimir Barinov
>
> Changes in V4:
> * folded USBHS and internal PCI USB related patches together
> * added handling of ID pin from MAX3355E chip
> * removed ifdefs
Thanks for removing the ifdefs and adding some initial implementation
for the MAX chip.
Please see my comments below.
> --- build.orig/arch/arm/mach-shmobile/board-koelsch.c 2014-02-23
> 21:47:44.510571967 +0400
> +++ build/arch/arm/mach-shmobile/board-koelsch.c2014-02-23
> 21:47:59.358571662 +0400
> @@ -367,6 +370,177 @@
> DEFINE_RES_IRQ(gic_spi(168)),
> };
>
> +/* USBHS */
> +static const struct resource usbhs_resources[] __initconst = {
> + DEFINE_RES_MEM(0xe659, 0x100),
> + DEFINE_RES_IRQ(gic_spi(107)),
> +};
> +
> +struct usbhs_private {
> + struct renesas_usbhs_platform_info info;
> + struct usb_phy *phy;
> +};
> +
> +#define usbhs_get_priv(pdev) \
> + container_of(renesas_usbhs_get_info(pdev), struct usbhs_private, info)
> +
> +static int usbhs_power_ctrl(struct platform_device *pdev,
> + void __iomem *base, int enable)
> +{
> + struct usbhs_private *priv = usbhs_get_priv(pdev);
> +
> + if (!priv->phy)
> + return -ENODEV;
> +
> + if (enable) {
> + int retval = usb_phy_init(priv->phy);
> +
> + if (!retval)
> + retval = usb_phy_set_suspend(priv->phy, 0);
> + return retval;
> + }
> +
> + usb_phy_set_suspend(priv->phy, 1);
> + usb_phy_shutdown(priv->phy);
> + return 0;
> +}
> +
> +static int usbhs_hardware_init(struct platform_device *pdev)
> +{
> + struct usbhs_private *priv = usbhs_get_priv(pdev);
> + struct usb_phy *phy;
> +
> + phy = usb_get_phy_dev(&pdev->dev, 0);
> + if (IS_ERR(phy))
> + return PTR_ERR(phy);
> +
> + priv->phy = phy;
> + return 0;
> +}
> +
> +static int usbhs_hardware_exit(struct platform_device *pdev)
> +{
> + struct usbhs_private *priv = usbhs_get_priv(pdev);
> +
> + if (!priv->phy)
> + return 0;
> +
> + usb_put_phy(priv->phy);
> + priv->phy = NULL;
> + return 0;
> +}
> +
> +static int usbhs_get_id(struct platform_device *pdev)
> +{
> + return USBHS_GADGET;
> +}
Uhm, I sort of expected this place to be where you read out the ID pin
state from the MAX device.
> +static u32 koelsch_usbhs_pipe_type[] = {
> + USB_ENDPOINT_XFER_CONTROL,
> + USB_ENDPOINT_XFER_ISOC,
> + USB_ENDPOINT_XFER_ISOC,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_INT,
> + USB_ENDPOINT_XFER_INT,
> + USB_ENDPOINT_XFER_INT,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> + USB_ENDPOINT_XFER_BULK,
> +};
> +
> +static struct usbhs_private usbhs_priv __initdata = {
> + .info = {
> + .platform_callback = {
> + .power_ctrl = usbhs_power_ctrl,
> + .hardware_init = usbhs_hardware_init,
> + .hardware_exit = usbhs_hardware_exit,
> + .get_id = usbhs_get_id,
> + },
> + .driver_param = {
> + .buswait_bwait = 4,
> + .pipe_type = koelsch_usbhs_pipe_type,
> + .pipe_size = ARRAY_SIZE(koelsch_usbhs_pipe_type),
> + },
> + }
> +};
> +
> +static void __init koelsch_add_usb0_gadget(void)
> +{
> + usb_bind_phy("renesas_usbhs", 0, "usb_phy_rcar_gen2");
> + platform_device_register_resndata(&platform_bus,
> + "renesas_usbhs", -1,
> +
[PATCH v7 0/3] Exynos 5410 support
The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture Patches add new platform description, support of clock controller and device tree for Exynos 5410. Has been build on Linux Kernel v3.14-rc1 (Samsung kernel, for-next branch, commit aaeeda6f57833c7c0e16fef3d76205f36882c21b, "Merge branch 'v3.15-next/cleanup-samsung' into for-next") Has been tested on Exynos 5410 reference board (exynos_defconfig) I hope, this is enough clean and hasn't any dependencies to go through Samsung tree. Tarek. Changelog: v7: small changes for resolving conflicts related to changes in Samsung tree. Tarek Dakhran (3): ARM: EXYNOS: Add support for EXYNOS5410 SoC clk: exynos5410: register clocks using common clock framework ARM: dts: Add initial device tree support for EXYNOS5410 .../devicetree/bindings/clock/exynos5410-clock.txt | 54 + arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/exynos5410-smdk5410.dts | 72 +++ arch/arm/boot/dts/exynos5410.dtsi | 140 + arch/arm/mach-exynos/Kconfig | 10 + arch/arm/mach-exynos/common.c | 18 ++ arch/arm/mach-exynos/include/mach/map.h|1 + arch/arm/mach-exynos/mach-exynos5-dt.c |1 + arch/arm/mach-exynos/platsmp.c |2 + arch/arm/plat-samsung/include/plat/cpu.h |8 + arch/arm/plat-samsung/include/plat/map-s5p.h |3 + drivers/clk/samsung/Makefile |1 + drivers/clk/samsung/clk-exynos5410.c | 208 include/dt-bindings/clock/exynos5410.h | 32 +++ 14 files changed, 551 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/exynos5410-clock.txt create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts create mode 100644 arch/arm/boot/dts/exynos5410.dtsi create mode 100644 drivers/clk/samsung/clk-exynos5410.c create mode 100644 include/dt-bindings/clock/exynos5410.h -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
EXYNOS5410 is SoC in Samsung's Exynos5 SoC series.
Add initial support for this SoC.
Signed-off-by: Tarek Dakhran
Signed-off-by: Vyacheslav Tyrtov
Reviewed-by: Tomasz Figa
---
arch/arm/mach-exynos/Kconfig | 10 ++
arch/arm/mach-exynos/common.c| 18 ++
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |1 +
arch/arm/mach-exynos/platsmp.c |2 ++
arch/arm/plat-samsung/include/plat/cpu.h |8
arch/arm/plat-samsung/include/plat/map-s5p.h |3 +++
7 files changed, 43 insertions(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 4c414af..97a06c3 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -91,6 +91,16 @@ config SOC_EXYNOS5250
help
Enable EXYNOS5250 SoC support
+config SOC_EXYNOS5410
+ bool "SAMSUNG EXYNOS5410"
+ default y
+ depends on ARCH_EXYNOS5
+ select PM_GENERIC_DOMAINS if PM
+ select S5P_PM if PM_SLEEP
+ select S5P_SLEEP if PM_SLEEP
+ help
+ Enable EXYNOS5410 SoC support
+
config SOC_EXYNOS5420
bool "SAMSUNG EXYNOS5420"
default y
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 025fd82..5d53795 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -52,6 +52,7 @@ static const char name_exynos4210[] = "EXYNOS4210";
static const char name_exynos4212[] = "EXYNOS4212";
static const char name_exynos4412[] = "EXYNOS4412";
static const char name_exynos5250[] = "EXYNOS5250";
+static const char name_exynos5410[] = "EXYNOS5410";
static const char name_exynos5420[] = "EXYNOS5420";
static const char name_exynos5440[] = "EXYNOS5440";
@@ -85,6 +86,12 @@ static struct cpu_table cpu_ids[] __initdata = {
.init = exynos_init,
.name = name_exynos5250,
}, {
+ .idcode = EXYNOS5410_SOC_ID,
+ .idmask = EXYNOS5_SOC_MASK,
+ .map_io = exynos5_map_io,
+ .init = exynos_init,
+ .name = name_exynos5410,
+ }, {
.idcode = EXYNOS5420_SOC_ID,
.idmask = EXYNOS5_SOC_MASK,
.map_io = exynos5_map_io,
@@ -215,6 +222,15 @@ static struct map_desc exynos4x12_iodesc[] __initdata = {
},
};
+static struct map_desc exynos5410_iodesc[] __initdata = {
+ {
+ .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
+ .pfn= __phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ },
+};
+
static struct map_desc exynos5250_iodesc[] __initdata = {
{
.virtual= (unsigned long)S5P_VA_SYSRAM_NS,
@@ -379,6 +395,8 @@ static void __init exynos5_map_io(void)
if (soc_is_exynos5250())
iotable_init(exynos5250_iodesc, ARRAY_SIZE(exynos5250_iodesc));
+ if (soc_is_exynos5410())
+ iotable_init(exynos5410_iodesc, ARRAY_SIZE(exynos5410_iodesc));
}
struct bus_type exynos_subsys = {
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 7b046b5..894f431 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -29,6 +29,7 @@
#define EXYNOS4210_PA_SYSRAM_NS0x0203F000
#define EXYNOS4x12_PA_SYSRAM_NS0x0204F000
#define EXYNOS5250_PA_SYSRAM_NS0x0204F000
+#define EXYNOS5410_PA_SYSRAM_NS0x02073000
#define EXYNOS_PA_CHIPID 0x1000
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index 37ea261..22245b2 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -51,6 +51,7 @@ static void __init exynos5_dt_machine_init(void)
static char const *exynos5_dt_compat[] __initdata = {
"samsung,exynos5250",
+ "samsung,exynos5410",
"samsung,exynos5420",
"samsung,exynos5440",
NULL
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 8ea02f6..b681f89 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -39,6 +39,8 @@ static inline void __iomem *cpu_boot_reg_base(void)
{
if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_1_1)
return S5P_INFORM5;
+ if (soc_is_exynos5410())
+ return EXYNOS5410_BOOT_REG;
return S5P_VA_SYSRAM;
}
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index 31164b3..262ef86 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -46,6 +4
[PATCH v7 3/3] ARM: dts: Add initial device tree support for EXYNOS5410
Add initial device tree nodes for EXYNOS5410 SoC and SMDK5410 board.
Signed-off-by: Tarek Dakhran
Signed-off-by: Vyacheslav Tyrtov
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/Makefile|1 +
arch/arm/boot/dts/exynos5410-smdk5410.dts | 72 +++
arch/arm/boot/dts/exynos5410.dtsi | 140 +
3 files changed, 213 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts
create mode 100644 arch/arm/boot/dts/exynos5410.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b9d6a8b..693dcdc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -73,6 +73,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
exynos5420-arndale-octa.dtb \
+ exynos5410-smdk5410.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
new file mode 100644
index 000..7ffd351
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -0,0 +1,72 @@
+/*
+ * SAMSUNG SMDK5410 board device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include "exynos5410.dtsi"
+/ {
+ model = "Samsung SMDK5410 board based on EXYNOS5410";
+ compatible = "samsung,smdk5410", "samsung,exynos5410";
+
+ memory {
+ reg = <0x4000 0x8000>;
+ };
+
+ chosen {
+ bootargs = "console=ttySAC2,115200";
+ };
+
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fin_pll: clock-fin-pll {
+ compatible = "fixed-clock";
+ reg = <0>;
+ #clock-cells = <0>;
+ clock-frequency = <2400>;
+ clock-output-names = "fin_pll";
+ };
+ };
+
+ mmc@1220 {
+ status = "okay";
+ num-slots = <1>;
+ supports-highspeed;
+ broken-cd;
+ card-detect-delay = <200>;
+ samsung,dw-mshc-ciu-div = <3>;
+ samsung,dw-mshc-sdr-timing = <2 3>;
+ samsung,dw-mshc-ddr-timing = <1 2>;
+
+ slot@0 {
+ reg = <0>;
+ bus-width = <8>;
+ };
+ };
+
+ mmc@1222 {
+ status = "okay";
+ num-slots = <1>;
+ supports-highspeed;
+ card-detect-delay = <200>;
+ samsung,dw-mshc-ciu-div = <3>;
+ samsung,dw-mshc-sdr-timing = <2 3>;
+ samsung,dw-mshc-ddr-timing = <1 2>;
+
+ slot@0 {
+ reg = <0>;
+ bus-width = <4>;
+ disable-wp;
+ };
+ };
+
+};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
new file mode 100644
index 000..56b44d1
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -0,0 +1,140 @@
+/*
+ * SAMSUNG EXYNOS5410 SoC device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SAMSUNG EXYNOS5410 SoC device nodes are listed in this file.
+ * EXYNOS5410 based board files can include this file and provide
+ * values for board specfic bindings.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include "exynos5.dtsi"
+/ {
+ compatible = "samsung,exynos5410";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ clock-frequency = <16>;
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ clock-frequency = <16>;
+ };
+
+ CPU2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <2>;
+ clock-frequency = <16>;
+ };
+
+ CPU3: cpu@3 {
+ device_type =
[PATCH v7 2/3] clk: exynos5410: register clocks using common clock framework
The EXYNOS5410 clocks are statically listed and registered
using the Samsung specific common clock helper functions.
Signed-off-by: Tarek Dakhran
Signed-off-by: Vyacheslav Tyrtov
Acked-by: Tomasz Figa
---
.../devicetree/bindings/clock/exynos5410-clock.txt | 54 +
drivers/clk/samsung/Makefile |1 +
drivers/clk/samsung/clk-exynos5410.c | 208
include/dt-bindings/clock/exynos5410.h | 32 +++
4 files changed, 295 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/exynos5410-clock.txt
create mode 100644 drivers/clk/samsung/clk-exynos5410.c
create mode 100644 include/dt-bindings/clock/exynos5410.h
diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
new file mode 100644
index 000..604a75c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
@@ -0,0 +1,54 @@
+* Samsung Exynos5410 Clock Controller
+
+The Exynos5410 clock controller generates and supplies clock to various
+controllers within the Exynos5410 SoC.
+
+Required Properties:
+
+- compatible: should be "samsung,exynos5410-clock"
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5410.h header and can be used in device
+tree sources.
+
+External clock:
+
+There is clock that is generated outside the SoC. It is expected
+that it is defined using standard clock bindings with following
+clock-output-name:
+ - "fin_pll" - PLL input clock - required.
+
+Example 1: An example of a clock controller node is listed below.
+
+ clock: clock-controller@0x1001 {
+ compatible = "samsung,exynos5410-clock";
+ reg = <0x1001 0x3>;
+ #clock-cells = <1>;
+ };
+
+Example 2: Required external clock.
+
+ fin_pll: clock-fin-pll {
+ compatible = "fixed-clock";
+ reg = <0>;
+ #clock-cells = <0>;
+ clock-frequency = <2400>;
+ clock-output-names = "fin_pll";
+ };
+
+Example 3: UART controller node that consumes the clock generated by the clock
+ controller. Refer to the standard clock bindings for information
+ about 'clocks' and 'clock-names' property.
+
+ serial@12C2 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x12C0 0x100>;
+ interrupts = <0 51 0>;
+ clocks = <&clock CLK_UART0>, <&clock CLK_SCLK_UART0>;
+ clock-names = "uart", "clk_uart_baud0";
+ };
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..b572dd7 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
+obj-$(CONFIG_SOC_EXYNOS5410) += clk-exynos5410.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o
diff --git a/drivers/clk/samsung/clk-exynos5410.c
b/drivers/clk/samsung/clk-exynos5410.c
new file mode 100644
index 000..adc4db6
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos5410.c
@@ -0,0 +1,208 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tarek Dakhran
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Common Clock Framework support for Exynos5410 SoC.
+*/
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+#define APLL_LOCK 0x0
+#define APLL_CON0 0x100
+#define CPLL_LOCK 0x10020
+#define CPLL_CON0 0x10120
+#define MPLL_LOCK 0x4000
+#define MPLL_CON0 0x4100
+#define BPLL_LOCK 0x20010
+#define BPLL_CON0 0x20110
+#define KPLL_LOCK 0x28000
+#define KPLL_CON0 0x28100
+
+#define SRC_CPU0x200
+#define DIV_CPU0 0x500
+#define SRC_CPERI1 0x4204
+#define DIV_TOP0 0x10510
+#define DIV_TOP1 0x10514
+#define DIV_FSYS1 0x1054c
+#define DIV_FSYS2 0x10550
+#define DIV_PERIC0 0x10558
+#define SRC_TOP0 0x10210
+#define SRC_TOP1 0x10214
+#define SRC_TOP2 0x10218
+#define SRC_FSYS 0x10244
+#define SRC_PERIC0 0x10250
+#define SRC_MASK_FSYS 0x10340
+#define SRC_MASK_PERIC00x10350
+#define GATE_BUS_FSYS0
linux-next: build failure after merge of the spi tree
Hi Mark,
After merging the spi tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/spi/spi-qup.c: In function 'spi_qup_set_state':
drivers/spi/spi-qup.c:185:3: error: implicit declaration of function
'writel_relaxed' [-Werror=implicit-function-declaration]
writel_relaxed(QUP_STATE_CLEAR, controller->base + QUP_STATE);
^
Caused by commit 64ff247a978f ("spi: Add Qualcomm QUP SPI controller
support") and exposed by commit 702d3cf9d05d ("spi: qup: Enable driver
compilation with COMPILE_TEST"). Please at least test building on x86
before allowing a build with COMPILE_TEST.
I have used the spi tree from next-20140221 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpyHaP1DGGB_.pgp
Description: PGP signature
RE: [PATCH v4 3/3] KVM: x86: Enable Intel MPX for guest
Paolo Bonzini wrote: > Il 21/02/2014 18:57, Liu, Jinsong ha scritto: >> -F(BMI2) | F(ERMS) | f_invpcid | F(RTM) | F(RDSEED) | >> +F(BMI2) | F(ERMS) | f_invpcid | F(RTM) | F(MPX) | F(RDSEED) | >> F(ADX); > > MPX also needs to be conditional on mpx_supported here, like it is > done with f_rdtscp for example. > > Paolo Yes, has updated and sent out. Thanks, Jinsong-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net V2] virtio-net: alloc big buffers also when guest can receive UFO
"Michael S. Tsirkin" writes: > On Fri, Feb 21, 2014 at 01:08:04PM +0800, Jason Wang wrote: >> We should alloc big buffers also when guest can receive UFO >> pakcets to let the big packets be fit into guest rx buffer. > > s/pakcets/packets/ > > s/be fit/fit/ > > otherwise: > > Acked-by: Michael S. Tsirkin Indeed. Acked-by: Rusty Russell Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] There should have a warn/log when out-of-tree module is loaded
Xudong Zhang writes: > I can not get any hint when I found that my kernel is tainted (out of > tree module is loaded). And I checked all loaded and loadable modules > but it showed that all of them are intree modules. > I think we need a warn when out of tree module is loaded. > > Signed-off-by: Xudong Zhang This would be an escalation. This taint only has an effect on oops messages, and /proc/sys/kernel/tainted. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] virtio: Use pci_enable_msix_exact() instead of pci_enable_msix()
"Michael S. Tsirkin" writes: > On Fri, Feb 21, 2014 at 06:01:28PM +0100, Alexander Gordeev wrote: >> As result of deprecation of MSI-X/MSI enablement functions >> pci_enable_msix() and pci_enable_msi_block() all drivers >> using these two interfaces need to be updated to use the >> new pci_enable_msi_range() or pci_enable_msi_exact() >> and pci_enable_msix_range() or pci_enable_msix_exact() >> interfaces. > > > Acked-by: Michael S. Tsirkin Thanks, applied. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] genirq: Fix the possible synchronize_irq() wait-forever
We hit one rare case below:
T1 calling disable_irq(), but hanging at synchronize_irq()
always;
The corresponding irq thread is in sleeping state;
And all CPUs are in idle state;
After analysis, we found there is one possible scenerio which
causes T1 is waiting there forever:
CPU0 CPU1
synchronize_irq()
wait_event()
spin_lock()
atomic_dec_and_test(&threads_active)
insert the __wait into queue
spin_unlock()
if(waitqueue_active)
atomic_read(&threads_active)
wait_up()
Here after inserted the __wait into queue on CPU0, and before
test if queue is empty on CPU1, there is no barrier, it maybe
cause it is not visible for CPU1 immediately, although CPU0 has
updated the queue list.
It is similar for CPU0 atomic_read() threads_active also.
So we need one smp_mb() before waitqueue_active or something like
that.
Thomas shared one good option that removing waitqueue_active()
judgement directly, it will make things to be simple and clear.
Cc: Thomas Gleixner
Cc: Xiaoming Wang
Signed-off-by: Chuansheng Liu
---
kernel/irq/manage.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 481a13c..d3bf660 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -802,8 +802,7 @@ static irqreturn_t irq_thread_fn(struct irq_desc *desc,
static void wake_threads_waitq(struct irq_desc *desc)
{
- if (atomic_dec_and_test(&desc->threads_active) &&
- waitqueue_active(&desc->wait_for_threads))
+ if (atomic_dec_and_test(&desc->threads_active))
wake_up(&desc->wait_for_threads);
}
--
1.9.rc0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] capability: Use current logging styles
On Fri, 21 Feb 2014, Joe Perches wrote: > Prefix logging output with "capability: " via pr_fmt. > Convert printks to pr_. > Use pr__once instead of guard flags. > Coalesce formats. > > Signed-off-by: Joe Perches Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
