Re: [PATCH 0/5] rtc: s5m: Add support for S2MPS14
> Few days ago I sent patches adding support for S2MPS14 device to the
> sec-core/s2mps11 drivers. These patches were rather large as they covered
> multiple subsystems so I decided to split everything into smaller, separate
> patches.
>
> The original patchset (version 3) can be found here:
> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/27194/focus=1649217
>
> This patchset is a small subset of above related to the S5M RTC driver.
> It adds support for the S2MPS14 device.
>
> These patches are rebased against Lee's "for-mfd-next" tree because they
> require
> changes in main MFD sec-core driver ("Add support for S2MPS14 for-mfd-next",
> which is already in Lee's "for-mfd-next" tree).
I'm happy to take this patch-set though the MFD tree and provide a
immutable branch for the RTC guys to pull from.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 akpm-current tree with the arm-soc tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
arch/arm/mach-picoxcell/Kconfig between commit ddb902cc3459 ("ARM:
centralize common multi-platform kconfig options") from the arm-soc tree
and commit b096b0b50c4b ("Kconfig: rename HAS_IOPORT to HAS_IOPORT_MAP")
from the akpm-current 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 arch/arm/mach-picoxcell/Kconfig
index eca9eb1c5931,c03cd6ffb429..
--- a/arch/arm/mach-picoxcell/Kconfig
+++ b/arch/arm/mach-picoxcell/Kconfig
@@@ -1,7 -1,12 +1,7 @@@
config ARCH_PICOXCELL
bool "Picochip PicoXcell" if ARCH_MULTI_V6
select ARCH_REQUIRE_GPIOLIB
- select ARM_PATCH_PHYS_VIRT
select ARM_VIC
- select CPU_V6K
select DW_APB_TIMER_OF
- select GENERIC_CLOCKEVENTS
select HAVE_TCM
- select NO_IOPORT
+ select NO_IOPORT_MAP
- select SPARSE_IRQ
- select USE_OF
pgpQ5LWwUJSo1.pgp
Description: PGP signature
RE: LOCAL MAP OPTIMIZATION FOR : mail-archive.com (Less Than $99/Month)
Good Morning Sir / Mam Is your business ranking in local maps shown on PAGE 1 of google ? With new google policies they have specifically asked local business owners to optimize their website for local maps rather than JUST organics. Do you know the reason why you are not ranked well on google MAPs or why there is drop in your website rankings? Prime reason for bad rankings for a busniess is lack of local presence and local citations ie getting your business listed on directories like YELP, MANTA & Many more. These websites not just give your business a push but also help you Maintain a good Online Reputation. Why you need to optimize your website for local MAP Listings ? - MAP listings get 10 times more clicks than organic listings - Increased conversions because of real reviews posted on your Google Plus Page - Every year there is 30% increase in searches for local keywords - Increases legitimacy of a Business We will help you get your website ranked well on google for the related keywords in your niche. We specialize in LOCAL SEARCH ENGINE OPTIMIZATION increasing visibility for small businesses by ranking them for geographically-related keywords. Say for eg-: you want to search a plumber in your city, You will be typing in keywords like Plumbers + City Or Plumbers + IN + City. We make sure your website comes in google MAP listings shown on page 1 for each such keyword. Now Google believes in - BE ORIGINAL, HAVE ORIGINAL AND GIVE ORIGINAL which means that google wants to end up that frustrating experience of users who are searching for Service Or Product and seeing the results that are not even close to what they are looking for. Google only wants to give their user original and relevant results. This makes it even more important that we showcase our business in the best possible way and make sure our website in valued high by google. We at TheLOCALIST will make google feel the importance of your business by following their guidelines thus ranking your website higher in serach results. We are presently offering LOCAL OPTIMIZATION to more than 400 websites and they all rank page 1 for all possible keywords !!! Each month your website is submitted to more than 50 citations and social presence is controlled by posting videos and blogs all over the web. Email us back with your website & phone number so we can discuss this further with you. Our Packages start from as low as 99$/month. Thanks For Taking Time To Read Our Email Polly Martin Local SEO Manager ( THE Localist ) Address : 24 ST Suite 32 Downtown Provo Utah --- NOT INTERESTED ? REPLY WITH NOT INTERESTED IN THE SUBJECT LINE -- 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 1/5] idle/cpuidle: Split cpuidle_idle_call main function into smaller functions
In order to allow better integration between the cpuidle framework and the
scheduler, reducing the distance between these two sub-components will
facilitate this integration by moving part of the cpuidle code in the idle
task file and, because idle.c is in the sched directory, we have access to
the scheduler's private structures.
This patch splits the cpuidle_idle_call main entry function into 3 calls
to a newly added API:
1. select the idle state
2. enter the idle state
3. reflect the idle state
The cpuidle_idle_call calls these three functions to implement the main
idle entry function.
Signed-off-by: Daniel Lezcano
Acked-by: Nicolas Pitre
---
ChangeLog:
V4:
* rebased on top of tip/master
V3:
* moved broadcast timer outside of cpuidle_enter() as suggested by
Preeti U Murthy : https://lkml.org/lkml/2014/2/24/601
V2:
* splitted cpuidle_select error check into 'cpuidle_enabled' function
---
drivers/cpuidle/cpuidle.c | 96 +++---
include/linux/cpuidle.h | 19 +
2 files changed, 94 insertions(+), 21 deletions(-)
Index: cpuidle-next/drivers/cpuidle/cpuidle.c
===
--- cpuidle-next.orig/drivers/cpuidle/cpuidle.c
+++ cpuidle-next/drivers/cpuidle/cpuidle.c
@@ -65,6 +65,26 @@ int cpuidle_play_dead(void)
}
/**
+ * cpuidle_enabled - check if the cpuidle framework is ready
+ * @dev: cpuidle device for this cpu
+ * @drv: cpuidle driver for this cpu
+ *
+ * Return 0 on success, otherwise:
+ * -NODEV : the cpuidle framework is not available
+ * -EBUSY : the cpuidle framework is not initialized
+ */
+int cpuidle_enabled(struct cpuidle_driver *drv, struct cpuidle_device *dev)
+{
+ if (off || !initialized)
+ return -ENODEV;
+
+ if (!drv || !dev || !dev->enabled)
+ return -EBUSY;
+
+ return 0;
+}
+
+/**
* cpuidle_enter_state - enter the state and update stats
* @dev: cpuidle device for this cpu
* @drv: cpuidle driver for this cpu
@@ -108,6 +128,51 @@ int cpuidle_enter_state(struct cpuidle_d
}
/**
+ * cpuidle_select - ask the cpuidle framework to choose an idle state
+ *
+ * @drv: the cpuidle driver
+ * @dev: the cpuidle device
+ *
+ * Returns the index of the idle state.
+ */
+int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
+{
+ return cpuidle_curr_governor->select(drv, dev);
+}
+
+/**
+ * cpuidle_enter - enter into the specified idle state
+ *
+ * @drv: the cpuidle driver tied with the cpu
+ * @dev: the cpuidle device
+ * @index: the index in the idle state table
+ *
+ * Returns the index in the idle state, < 0 in case of error.
+ * The error code depends on the backend driver
+ */
+int cpuidle_enter(struct cpuidle_driver *drv, struct cpuidle_device *dev,
+ int index)
+{
+ if (cpuidle_state_is_coupled(dev, drv, index))
+ return cpuidle_enter_state_coupled(dev, drv, index);
+ return cpuidle_enter_state(dev, drv, index);
+}
+
+/**
+ * cpuidle_reflect - tell the underlying governor what was the state
+ * we were in
+ *
+ * @dev : the cpuidle device
+ * @index: the index in the idle state table
+ *
+ */
+void cpuidle_reflect(struct cpuidle_device *dev, int index)
+{
+ if (cpuidle_curr_governor->reflect)
+ cpuidle_curr_governor->reflect(dev, index);
+}
+
+/**
* cpuidle_idle_call - the main idle loop
*
* NOTE: no locks or semaphores should be used here
@@ -116,26 +181,21 @@ int cpuidle_enter_state(struct cpuidle_d
int cpuidle_idle_call(void)
{
struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
- struct cpuidle_driver *drv;
- int next_state, entered_state;
+ struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
+ int next_state, entered_state, ret;
bool broadcast;
- if (off || !initialized)
- return -ENODEV;
-
- /* check if the device is ready */
- if (!dev || !dev->enabled)
- return -EBUSY;
-
- drv = cpuidle_get_cpu_driver(dev);
+ ret = cpuidle_enabled(drv, dev);
+ if (ret < 0)
+ return ret;
/* ask the governor for the next state */
- next_state = cpuidle_curr_governor->select(drv, dev);
+ next_state = cpuidle_select(drv, dev);
+
if (need_resched()) {
dev->last_residency = 0;
/* give the governor an opportunity to reflect on the outcome */
- if (cpuidle_curr_governor->reflect)
- cpuidle_curr_governor->reflect(dev, next_state);
+ cpuidle_reflect(dev, next_state);
local_irq_enable();
return 0;
}
@@ -146,14 +206,9 @@ int cpuidle_idle_call(void)
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, >cpu))
return -EBUSY;
-
trace_cpu_idle_rcuidle(next_state, dev->cpu);
- if (cpuidle_state_is_coupled(dev, drv,
[PATCH V4 3/5] idle: Reorganize the idle loop
Now that we have the main cpuidle function in idle.c, move some code from
the idle mainloop to this function for the sake of clarity.
That removes if then else indentation difficult to follow when looking at the
code. This patch does not change the current behavior.
Signed-off-by: Daniel Lezcano
Acked-by: Nicolas Pitre
---
Changelog:
V4:
* no changes
V3:
* no changes
V2:
* fixed type in patch's description
---
include/linux/cpuidle.h |2 ++
kernel/sched/idle.c | 33 +++--
2 files changed, 17 insertions(+), 18 deletions(-)
Index: cpuidle-next/include/linux/cpuidle.h
===
--- cpuidle-next.orig/include/linux/cpuidle.h
+++ cpuidle-next/include/linux/cpuidle.h
@@ -180,6 +180,8 @@ static inline int cpuidle_enable_device(
{return -ENODEV; }
static inline void cpuidle_disable_device(struct cpuidle_device *dev) { }
static inline int cpuidle_play_dead(void) {return -ENODEV; }
+static inline struct cpuidle_driver *cpuidle_get_cpu_driver(
+ struct cpuidle_device *dev) {return NULL; }
#endif
#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
Index: cpuidle-next/kernel/sched/idle.c
===
--- cpuidle-next.orig/kernel/sched/idle.c
+++ cpuidle-next/kernel/sched/idle.c
@@ -63,7 +63,6 @@ void __weak arch_cpu_idle(void)
local_irq_enable();
}
-#ifdef CONFIG_CPU_IDLE
/**
* cpuidle_idle_call - the main idle function
*
@@ -77,9 +76,14 @@ static int cpuidle_idle_call(void)
int next_state, entered_state, ret;
bool broadcast;
+ stop_critical_timings();
+ rcu_idle_enter();
+
ret = cpuidle_enabled(drv, dev);
- if (ret < 0)
- return ret;
+ if (ret < 0) {
+ arch_cpu_idle();
+ goto out;
+ }
/* ask the governor for the next state */
next_state = cpuidle_select(drv, dev);
@@ -89,7 +93,7 @@ static int cpuidle_idle_call(void)
/* give the governor an opportunity to reflect on the outcome */
cpuidle_reflect(dev, next_state);
local_irq_enable();
- return 0;
+ goto out;
}
broadcast = !!(drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP);
@@ -109,15 +113,15 @@ static int cpuidle_idle_call(void)
/* give the governor an opportunity to reflect on the outcome */
cpuidle_reflect(dev, entered_state);
+out:
+ if (WARN_ON_ONCE(irqs_disabled()))
+ local_irq_enable();
+
+ rcu_idle_exit();
+ start_critical_timings();
return 0;
}
-#else
-static inline int cpuidle_idle_call(void)
-{
- return -ENODEV;
-}
-#endif
/*
* Generic idle loop implementation
@@ -150,14 +154,7 @@ static void cpu_idle_loop(void)
cpu_idle_poll();
} else {
if (!current_clr_polling_and_test()) {
- stop_critical_timings();
- rcu_idle_enter();
- if (cpuidle_idle_call())
- arch_cpu_idle();
- if (WARN_ON_ONCE(irqs_disabled()))
- local_irq_enable();
- rcu_idle_exit();
- start_critical_timings();
+ cpuidle_idle_call();
} else {
local_irq_enable();
}
--
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 2/5] cpuidle/idle: Move the cpuidle_idle_call function to idle.c
The cpuidle_idle_call does nothing more than calling the three individuals
function and is no longer used by any arch specific code but only in the
cpuidle framework code.
We can move this function into the idle task code to ensure better
proximity to the scheduler code.
Signed-off-by: Daniel Lezcano
Acked-by: Nicolas Pitre
---
Changelog:
V4:
* rebased on the top of tip/master
---
drivers/cpuidle/cpuidle.c | 49
include/linux/cpuidle.h |2 -
kernel/sched/idle.c | 56 ++
3 files changed, 56 insertions(+), 51 deletions(-)
Index: cpuidle-next/drivers/cpuidle/cpuidle.c
===
--- cpuidle-next.orig/drivers/cpuidle/cpuidle.c
+++ cpuidle-next/drivers/cpuidle/cpuidle.c
@@ -173,55 +173,6 @@ void cpuidle_reflect(struct cpuidle_devi
}
/**
- * cpuidle_idle_call - the main idle loop
- *
- * NOTE: no locks or semaphores should be used here
- * return non-zero on failure
- */
-int cpuidle_idle_call(void)
-{
- struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
- struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
- int next_state, entered_state, ret;
- bool broadcast;
-
- ret = cpuidle_enabled(drv, dev);
- if (ret < 0)
- return ret;
-
- /* ask the governor for the next state */
- next_state = cpuidle_select(drv, dev);
-
- if (need_resched()) {
- dev->last_residency = 0;
- /* give the governor an opportunity to reflect on the outcome */
- cpuidle_reflect(dev, next_state);
- local_irq_enable();
- return 0;
- }
-
- broadcast = !!(drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP);
-
- if (broadcast &&
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, >cpu))
- return -EBUSY;
-
- trace_cpu_idle_rcuidle(next_state, dev->cpu);
-
- entered_state = cpuidle_enter(drv, dev, next_state);
-
- trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
-
- if (broadcast)
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, >cpu);
-
- /* give the governor an opportunity to reflect on the outcome */
- cpuidle_reflect(dev, entered_state);
-
- return 0;
-}
-
-/**
* cpuidle_install_idle_handler - installs the cpuidle idle loop handler
*/
void cpuidle_install_idle_handler(void)
Index: cpuidle-next/include/linux/cpuidle.h
===
--- cpuidle-next.orig/include/linux/cpuidle.h
+++ cpuidle-next/include/linux/cpuidle.h
@@ -128,7 +128,6 @@ extern int cpuidle_enter(struct cpuidle_
struct cpuidle_device *dev, int index);
extern void cpuidle_reflect(struct cpuidle_device *dev, int index);
-extern int cpuidle_idle_call(void);
extern int cpuidle_register_driver(struct cpuidle_driver *drv);
extern struct cpuidle_driver *cpuidle_get_driver(void);
extern struct cpuidle_driver *cpuidle_driver_ref(void);
@@ -160,7 +159,6 @@ static inline int cpuidle_enter(struct c
struct cpuidle_device *dev, int index)
{return -ENODEV; }
static inline void cpuidle_reflect(struct cpuidle_device *dev, int index) { }
-static inline int cpuidle_idle_call(void) { return -ENODEV; }
static inline int cpuidle_register_driver(struct cpuidle_driver *drv)
{return -ENODEV; }
static inline struct cpuidle_driver *cpuidle_get_driver(void) {return NULL; }
Index: cpuidle-next/kernel/sched/idle.c
===
--- cpuidle-next.orig/kernel/sched/idle.c
+++ cpuidle-next/kernel/sched/idle.c
@@ -63,6 +63,62 @@ void __weak arch_cpu_idle(void)
local_irq_enable();
}
+#ifdef CONFIG_CPU_IDLE
+/**
+ * cpuidle_idle_call - the main idle function
+ *
+ * NOTE: no locks or semaphores should be used here
+ * return non-zero on failure
+ */
+static int cpuidle_idle_call(void)
+{
+ struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
+ struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
+ int next_state, entered_state, ret;
+ bool broadcast;
+
+ ret = cpuidle_enabled(drv, dev);
+ if (ret < 0)
+ return ret;
+
+ /* ask the governor for the next state */
+ next_state = cpuidle_select(drv, dev);
+
+ if (need_resched()) {
+ dev->last_residency = 0;
+ /* give the governor an opportunity to reflect on the outcome */
+ cpuidle_reflect(dev, next_state);
+ local_irq_enable();
+ return 0;
+ }
+
+ broadcast = !!(drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP);
+
+ if (broadcast &&
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, >cpu))
+ return -EBUSY;
+
+
[PATCH V4 5/5] idle: Add more comments to the code
The idle main function is a complex and a critical function. Added more
comments to the code.
Signed-off-by: Daniel Lezcano
Acked-by: Nicolas Pitre
---
Changelog:
V4:
* updated comments with new code
V3:
* no changes
V2:
* fixed typo in comment
---
kernel/sched/idle.c | 59 ++--
1 file changed, 57 insertions(+), 2 deletions(-)
Index: cpuidle-next/kernel/sched/idle.c
===
--- cpuidle-next.orig/kernel/sched/idle.c
+++ cpuidle-next/kernel/sched/idle.c
@@ -76,21 +76,49 @@ static int cpuidle_idle_call(void)
int next_state, entered_state, ret;
bool broadcast;
+ /*
+* Check if the idle task must be rescheduled. If it is the
+* case, exit the function after re-enabling the local irq and
+* set again the polling flag
+*/
if (current_clr_polling_and_test()) {
local_irq_enable();
__current_set_polling();
return 0;
}
+ /*
+* During the idle period, stop measuring the disabled irqs
+* critical sections latencies
+*/
stop_critical_timings();
+
+ /*
+* Tell the RCU framework we are entering an idle section,
+* so no more rcu read side critical sections and one more
+* step to the grace period
+*/
rcu_idle_enter();
+ /*
+* Check if the cpuidle framework is ready, otherwise fallback
+* to the default arch specific idle method
+*/
ret = cpuidle_enabled(drv, dev);
if (!ret) {
- /* ask the governor for the next state */
+ /*
+* Ask the governor to choose an idle state it thinks
+* it is convenient to go to. There is *always* a
+* convenient idle state
+*/
next_state = cpuidle_select(drv, dev);
+ /*
+* The idle task must be scheduled, it is pointless to
+* go to idle, just update no idle residency and get
+* out of this function
+*/
if (current_clr_polling_and_test()) {
dev->last_residency = 0;
entered_state = next_state;
@@ -100,6 +128,14 @@ static int cpuidle_idle_call(void)
CPUIDLE_FLAG_TIMER_STOP);
if (broadcast)
+ /*
+* Tell the time framework to switch
+* to a broadcast timer because our
+* local timer will be shutdown. If a
+* local timer is used from another
+* cpu as a broadcast timer, this call
+* may fail if it is not available
+*/
ret = clockevents_notify(
CLOCK_EVT_NOTIFY_BROADCAST_ENTER,
>cpu);
@@ -107,6 +143,14 @@ static int cpuidle_idle_call(void)
if (!ret) {
trace_cpu_idle_rcuidle(next_state, dev->cpu);
+ /*
+* Enter the idle state previously
+* returned by the governor
+* decision. This function will block
+* until an interrupt occurs and will
+* take care of re-enabling the local
+* interrupts
+*/
entered_state = cpuidle_enter(drv, dev,
next_state);
@@ -118,17 +162,28 @@ static int cpuidle_idle_call(void)
CLOCK_EVT_NOTIFY_BROADCAST_EXIT,
>cpu);
- /* give the governor an opportunity to reflect
on the outcome */
+ /*
+* Give the governor an opportunity to reflect
on the
+* outcome
+*/
cpuidle_reflect(dev, entered_state);
}
}
}
+ /*
+* We can't use the cpuidle framework, let's use the default
+* idle routine
+*/
if (ret)
arch_cpu_idle();
__current_set_polling();
+ /*
+* It is up to the idle functions to enable back the local
+* interrupt
+*/
if (WARN_ON_ONCE(irqs_disabled()))
local_irq_enable();
--
To unsubscribe from
[PATCH V4 4/5] idle: Move idle conditions in cpuidle_idle main function
This patch moves the condition before entering idle into the cpuidle main
function located in idle.c. That simplify the idle mainloop functions and
increase the readibility of the conditions to enter truly idle.
This patch is code reorganization and does not change the behavior of the
function.
Signed-off-by: Daniel Lezcano
Cc: Peter Zijlstra
---
V4:
* took into account clockevents_notify(ENTER) could fail
* removed an extra current_clr_polling_and_test added in V3
V3:
* reorganized cpuidle_idle_call function as Suggested by Peter Zijlstra
https://lkml.org/lkml/2014/2/24/492
---
kernel/sched/idle.c | 84 +---
1 file changed, 47 insertions(+), 37 deletions(-)
Index: cpuidle-next/kernel/sched/idle.c
===
--- cpuidle-next.orig/kernel/sched/idle.c
+++ cpuidle-next/kernel/sched/idle.c
@@ -76,44 +76,59 @@ static int cpuidle_idle_call(void)
int next_state, entered_state, ret;
bool broadcast;
+ if (current_clr_polling_and_test()) {
+ local_irq_enable();
+ __current_set_polling();
+ return 0;
+ }
+
stop_critical_timings();
rcu_idle_enter();
ret = cpuidle_enabled(drv, dev);
- if (ret < 0) {
- arch_cpu_idle();
- goto out;
- }
- /* ask the governor for the next state */
- next_state = cpuidle_select(drv, dev);
+ if (!ret) {
+ /* ask the governor for the next state */
+ next_state = cpuidle_select(drv, dev);
+
+ if (current_clr_polling_and_test()) {
+ dev->last_residency = 0;
+ entered_state = next_state;
+ local_irq_enable();
+ } else {
+ broadcast = !!(drv->states[next_state].flags &
+ CPUIDLE_FLAG_TIMER_STOP);
+
+ if (broadcast)
+ ret = clockevents_notify(
+ CLOCK_EVT_NOTIFY_BROADCAST_ENTER,
+ >cpu);
+
+ if (!ret) {
+ trace_cpu_idle_rcuidle(next_state, dev->cpu);
+
+ entered_state = cpuidle_enter(drv, dev,
+ next_state);
+
+ trace_cpu_idle_rcuidle(PWR_EVENT_EXIT,
+ dev->cpu);
+
+ if (broadcast)
+ clockevents_notify(
+ CLOCK_EVT_NOTIFY_BROADCAST_EXIT,
+ >cpu);
- if (need_resched()) {
- dev->last_residency = 0;
- /* give the governor an opportunity to reflect on the outcome */
- cpuidle_reflect(dev, next_state);
- local_irq_enable();
- goto out;
+ /* give the governor an opportunity to reflect
on the outcome */
+ cpuidle_reflect(dev, entered_state);
+ }
+ }
}
- broadcast = !!(drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP);
-
- if (broadcast &&
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, >cpu))
- return -EBUSY;
-
- trace_cpu_idle_rcuidle(next_state, dev->cpu);
-
- entered_state = cpuidle_enter(drv, dev, next_state);
-
- trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
+ if (ret)
+ arch_cpu_idle();
- if (broadcast)
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, >cpu);
+ __current_set_polling();
- /* give the governor an opportunity to reflect on the outcome */
- cpuidle_reflect(dev, entered_state);
-out:
if (WARN_ON_ONCE(irqs_disabled()))
local_irq_enable();
@@ -150,16 +165,11 @@ static void cpu_idle_loop(void)
* know that the IPI is going to arrive right
* away
*/
- if (cpu_idle_force_poll ||
tick_check_broadcast_expired()) {
+ if (cpu_idle_force_poll ||
tick_check_broadcast_expired())
cpu_idle_poll();
- } else {
- if (!current_clr_polling_and_test()) {
- cpuidle_idle_call();
- } else {
- local_irq_enable();
- }
- __current_set_polling();
- }
+ else
+
Re: [PATCH RFC/RFT v3 2/9] drivers: base: support cpu cache information interface to userspace via sysfs
Hi Greg, On Sat, Mar 1, 2014 at 12:42 AM, Greg Kroah-Hartman wrote: > On Wed, Feb 19, 2014 at 04:06:09PM +, Sudeep Holla wrote: >> From: Sudeep Holla >> >> This patch adds initial support for providing processor cache information >> to userspace through sysfs interface. This is based on already existing >> implementations(x86, ia64, s390 and powerpc) and hence the interface is >> intended to be fully compatible. >> >> The main purpose of this generic support is to avoid further code >> duplication to support new architectures and also to unify all the existing >> different implementations. >> >> This implementation maintains the hierarchy of cache objects which reflects >> the system's cache topology. Cache devices are instantiated as needed as >> CPUs come online. The cache information is replicated per-cpu even if they >> are >> shared. A per-cpu array of cache information maintained is used mainly for >> sysfs-related book keeping. >> >> It also implements the shared_cpu_map attribute, which is essential for >> enabling both kernel and user-space to discover the system's overall cache >> topology. >> >> This patch also add the missing ABI documentation for the cacheinfo sysfs >> interface already, which is well defined and widely used. >> >> Signed-off-by: Sudeep Holla >> Cc: Greg Kroah-Hartman >> Cc: Rob Herring >> Cc: linux-...@vger.kernel.org >> --- >> Documentation/ABI/testing/sysfs-devices-system-cpu | 40 ++ >> drivers/base/Makefile | 2 +- >> drivers/base/cacheinfo.c | 484 >> + >> include/linux/cacheinfo.h | 55 +++ >> 4 files changed, 580 insertions(+), 1 deletion(-) >> create mode 100644 drivers/base/cacheinfo.c >> create mode 100644 include/linux/cacheinfo.h >> >> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu >> b/Documentation/ABI/testing/sysfs-devices-system-cpu >> index d5a0d33..dabe03e 100644 >> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu >> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu >> @@ -224,3 +224,43 @@ Description: Parameters for the Intel P-state driver >> frequency range. >> >> More details can be found in >> Documentation/cpu-freq/intel-pstate.txt >> + >> +What: >> /sys/devices/system/cpu/cpu*/cache/index*/ >> +Date:February 2014 >> +Contact: Linux kernel mailing list > > No, your name goes here, you don't get to run away from this new code :) > No problem, I can add my name and I am happy to do that. I am only adding missing documentation to already existing interface as I have mentioned in the patch description. I didn't want to take that credit :), but am OK if that's acceptable. >> +Description: Parameters for the CPU cache attributes >> + >> + attributes: >> + - writethrough: data is written to both the cache line >> + and to the block in the lower-level >> memory >> + - writeback: data is written only to the cache line and >> + the modified cache line is written to main >> + memory only when it is replaced >> + - writeallocate: allocate a memory location to a cache >> line >> + on a cache miss because of a write >> + - readallocate: allocate a memory location to a cache >> line >> + on a cache miss because of a read >> + >> + coherency_line_size: the minimum amount of data that gets >> transferred >> + >> + level: the cache hierarcy in the multi-level cache >> configuration >> + >> + number_of_sets: total number of sets in the cache, a set is a >> + collection of cache lines with the same cache >> index >> + >> + physical_line_partition: number of physical cache line per >> cache tag >> + >> + shared_cpu_list: the list of cpus sharing the cache >> + >> + shared_cpu_map: logical cpu mask containing the list of cpus >> sharing >> + the cache >> + >> + size: the total cache size in kB >> + >> + type: >> + - instruction: cache that only holds instructions >> + - data: cache that only caches data >> + - unified: cache that holds both data and instructions >> + >> + ways_of_associativity: degree of freedom in placing a >> particular block >> + of memory in the cache > > With this patch, does this all work for x86, or does it need more glue > logic? No, the core code is mainly based on existing x86 implementation. There should be no extra glue logic required. I have not yet tested on x86, but will do that before the first
Re: linux-next: build failure after merge of the mfd-lj tree
Hi Lee, On Mon, 3 Mar 2014 15:23:31 +0800 Lee Jones wrote: > > Sorry about all this. Your mails are being filtered into an unused > mailbox for a currently unknown reason. I will investigate this > immediately. It was a mistake to push this patch, I will rectify right > away. I was beginning to wonder if I had been spam binned :-) Thanks for taking care of this. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpnLxqvApvjI.pgp Description: PGP signature
Re: [PATCH 3/5 v2] Staging: cxt1e1: Fix line length over 80 characters in hwprobe.c
I think line break is a solution about long line warning. And replacing with hex_dump() is better than managing with another patch. So I said this improvement is separated with another patch. Just my opinion. If I'm wrong, I try to change as Krzysztof's comment in same patch. Thanks. Daeseok Youn. 2014-03-03 16:10 GMT+09:00 Joe Perches : > On Mon, 2014-03-03 at 16:01 +0900, DaeSeok Youn wrote: >> 2014-03-03 15:46 GMT+09:00 Krzysztof Hałasa : >> > why not use some existing *hex_dump*() instead? >> OK. but this patch is only for fix line length over 80 characters, >> right? If it can be improved as your comment, >> it must be in another patch. > > Not true. Always strive to improve the code in > preference to shutting up checkpatch warnings. > > -- 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: zram: lockdep spew for zram->init_lock
Hello Andrew,
I'm not in office now and I would be off in this week, maybe
so I don't have source code on top of Sergey's recent change
but it seems below code has same problem.
Pz, Sergey or Jerome Could you confirm it instead of me?
On Fri, Feb 28, 2014 at 04:32:06PM -0800, Andrew Morton wrote:
> On Fri, 28 Feb 2014 08:56:29 +0900 Minchan Kim wrote:
>
> > Sasha reported following below lockdep spew of zram.
> >
> > It was introduced by [1] in recent linux-next but it's false positive
> > because zram_meta_alloc with down_write(init_lock) couldn't be called
> > during zram is working as swap device so we could annotate the lock.
> >
> > But I don't think it's worthy because it would make greate lockdep
> > less effective. Instead, move zram_meta_alloc out of the lock as good
> > old day so we could do unnecessary allocation/free of zram_meta for
> > initialied device as Sergey claimed in [1] but it wouldn't be common
> > and be harmful if someone might do it. Rather than, I'd like to respect
> > lockdep which is great tool to prevent upcoming subtle bugs.
> >
> > [1] zram: delete zram_init_device
> >
> > ...
> >
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -537,26 +537,27 @@ static ssize_t disksize_store(struct device *dev,
> > struct device_attribute *attr, const char *buf, size_t len)
> > {
> > u64 disksize;
> > + struct zram_meta *meta;
> > struct zram *zram = dev_to_zram(dev);
> >
> > disksize = memparse(buf, NULL);
> > if (!disksize)
> > return -EINVAL;
> >
> > + disksize = PAGE_ALIGN(disksize);
> > + meta = zram_meta_alloc(disksize);
> > + if (!meta)
> > + return -ENOMEM;
> > +
> > down_write(>init_lock);
> > if (init_done(zram)) {
> > + zram_meta_free(meta);
> > up_write(>init_lock);
> > pr_info("Cannot change disksize for initialized device\n");
> > return -EBUSY;
> > }
> >
> > - disksize = PAGE_ALIGN(disksize);
> > - zram->meta = zram_meta_alloc(disksize);
> > - if (!zram->meta) {
> > - up_write(>init_lock);
> > - return -ENOMEM;
> > - }
> > -
> > + zram->meta = meta;
> > zram->disksize = disksize;
> > set_capacity(zram->disk, zram->disksize >> SECTOR_SHIFT);
> > up_write(>init_lock);
>
> When applying zram-use-zcomp-compressing-backends.patch on top of this
> we get a bit of a mess, and simple conflict resolution results in a
> leak.
>
> disksize_store() was one of those nasty functions which does multiple
> "return" statements after performing locking and resource allocation.
> As usual, this led to a resource leak. Remember folks, "return" is a
> goto in disguise.
>
>
> Here's what I ended up with. Please review.
>
> static ssize_t disksize_store(struct device *dev,
> struct device_attribute *attr, const char *buf, size_t len)
> {
> u64 disksize;
> struct zram_meta *meta;
> struct zram *zram = dev_to_zram(dev);
> int err;
>
> disksize = memparse(buf, NULL);
> if (!disksize)
> return -EINVAL;
>
> disksize = PAGE_ALIGN(disksize);
> meta = zram_meta_alloc(disksize);
> if (!meta)
> return -ENOMEM;
>
> down_write(>init_lock);
> if (init_done(zram)) {
> pr_info("Cannot change disksize for initialized device\n");
> err = -EBUSY;
> goto out_free_meta;
> }
>
> zram->comp = zcomp_create(default_compressor);
AFAIR, zcomp_create try to allocate memory with GFP_KERNEL so it could
make a same problem. If so, let's allocate it out of the lock.
Please check it.
> if (!zram->comp) {
> pr_info("Cannot initialise %s compressing backend\n",
> default_compressor);
> err = -EINVAL;
> goto out_free_meta;
> }
>
> zram->meta = meta;
> zram->disksize = disksize;
> set_capacity(zram->disk, zram->disksize >> SECTOR_SHIFT);
> up_write(>init_lock);
>
> return len;
>
> out_free_meta:
> up_write(>init_lock);
> zram_meta_free(meta);
> return err;
> }
>
--
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/RFT v3 1/9] drivers: base: add new class "cpu" to group cpu devices
Hi Greg, On Sat, Mar 1, 2014 at 12:42 AM, Greg Kroah-Hartman wrote: > On Wed, Feb 19, 2014 at 04:06:08PM +, Sudeep Holla wrote: >> From: Sudeep Holla >> >> This patch creates a new class called "cpu" and assigns it to all the >> cpu devices. This helps in grouping all the cpu devices and associated >> child devices under the same class. >> >> This patch also: >> 1. modifies the get_parent_device to return the legacy path >>(/sys/devices/system/cpu/..) for the cpu class devices to support >>existing sysfs ABI >> 2. avoids creating link in the class directory pointing to the device as >>there would be per-cpu instance of these devices with the same name >> 3. makes sure subsystem symlink continues pointing to cpu bus instead of >>cpu class for cpu devices >> >> Signed-off-by: Sudeep Holla >> Cc: Greg Kroah-Hartman > > Does the sysfs layout change at all with this patch applied? > No change to the existing layout, it just adds new entries, e.g. device symlink. Before this patch: / # ls /sys/devices/system/cpu/cpu0/ -l total 0 drwxr-xr-x5 root 00 Jan 1 00:02 cpuidle -rw-r--r--1 root 0 4096 Jan 1 00:02 online drwxr-xr-x2 root 00 Jan 1 00:02 power lrwxrwxrwx1 root 00 Jan 1 00:02 subsystem -> ../../../../bus/cpu drwxr-xr-x2 root 00 Jan 1 00:02 topology -rw-r--r--1 root 0 4096 Jan 1 00:02 uevent After this patch: /sys/class/cpu # ls /sys/devices/system/cpu/cpu0 -l total 0 drwxr-xr-x6 root 00 Jan 1 00:00 cache drwxr-xr-x5 root 00 Jan 1 00:00 cpuidle lrwxrwxrwx1 root 00 Jan 1 00:00 device -> ../../cpu -rw-r--r--1 root 0 4096 Jan 1 00:00 online drwxr-xr-x2 root 00 Jan 1 00:00 power lrwxrwxrwx1 root 00 Jan 1 00:00 subsystem -> ../../../../bus/cpu drwxr-xr-x2 root 00 Jan 1 00:00 topology -rw-r--r--1 root 0 4096 Jan 1 00:00 uevent Regards, Sudeep -- 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 22/46] kernel: Include appropriate header file in time/timekeeping_debug.c
On Thu, Feb 27, 2014 at 7:55 PM, Rashika Kheria wrote: > Include appropriate header file kernel/time/timekeeping_internal.h in > kernel/time/timekeeping_debug.c because it has prototype declaration of > function defined in kernel/time/timekeeping_debug.c. > > This eliminates the following warning in > kernel/time/timekeeping_debug.c: > kernel/time/timekeeping_debug.c:68:6: warning: no previous prototype for > 'tk_debug_account_sleep_time' [-Wmissing-prototypes] > > Signed-off-by: Rashika Kheria > Reviewed-by: Josh Triplett Thanks for sending this in.. I've queued this for 3.15. thanks -john -- 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] timberdale: Use pci_enable_msix_exact() instead of pci_enable_msix()
> > 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. > > > > Signed-off-by: Alexander Gordeev > > Cc: Samuel Ortiz > > Cc: Lee Jones > > Cc: linux-...@vger.kernel.org > > --- > > drivers/mfd/timberdale.c |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > Applied, thanks. I've reverted this patch, as it doesn't build othognally. drivers/mfd/timberdale.c:718:2: error: implicit declaration of function ‘pci_enable_msix_exact’ [-Werror=implicit-function-declaration] -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: [PATCHv3 1/3] ASoC: codec: Simplify ASoC probe code.
> > static int ak4535_probe(struct snd_soc_codec *codec)
> > {
> > - struct ak4535_priv *ak4535 = snd_soc_codec_get_drvdata(codec);
> > - int ret;
> > -
> > - codec->control_data = ak4535->regmap;
> > - ret = snd_soc_codec_set_cache_io(codec, 8, 8, SND_SOC_REGMAP);
> > - if (ret < 0) {
> > - dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret);
> > - return ret;
> > - }
> > /* power on device */
> > ak4535_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
>
> Are you sure that the set_bias_level() call doesn't do anything with
> I/O? Can I suggest sending a patch that just does the drivers that only
> do set_cache_io() and nothing else in probe - that would be really quick
> and simple to fix.
>
> > - ret = snd_soc_codec_set_cache_io(codec, 8, 8, SND_SOC_REGMAP);
> > - if (ret < 0) {
> > - dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret);
> > - return ret;
> > - }
> > -
> > /* Default to using ALC auto offset calibration mode. */
> > snd_soc_update_bits(codec, DA7213_ALC_CTRL1,
> > DA7213_ALC_CALIB_MODE_MAN, 0);
>
> This one will fail.
Sorry, I'm not very understand why will this fail ? Before the ASoC probe,
the ASoC core will set the I/O.
:)
--
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 mfd-lj tree
Hi Stephen,
> > > > > After merging the mfd-lj tree, today's linux-next build (x86_64
> > > > > allmodconfig) failed like this:
> > > > >
> > > > > In file included from drivers/mfd/max665x.c:19:0:
> > > > > include/linux/mfd/max665x-private.h:31:1: error: expected ';',
> > > > > identifier or '(' before 'struct'
> > > > > struct max665x_dev {
> > > > > ^
> > > > >
> > > > > Caused by commit e77bb5297293 ("mfd: max665x: Differentiate between
> > > > > MAX665X devices"). Clearly never built by anyone :-(
> > > > >
> > > > > I have used the mfd-lj tree from next-20140210 again for today (since
> > > > > the
> > > > > other version had other problems).
> > > >
> > > > Still seeing this error.
> > >
> > > Still ...
> >
> > Ping ...
>
> I am still seeing this error which means that I am still using the
> version of your tree from next-20140210 i.e. Feb 10. It is a bit
> disappointing that his has not been fixed in such a long time even though
> there have been other updates to your tree which means that those other
> changes have received no exposure in linux-next. It is a trivial error,
> but it does indicate that noone ever build tested that particular commit.
>
> (this is now commit 2fc7e7d25bee in your tree since it was rewritten but
> not fixed on Feb 14.)
Sorry about all this. Your mails are being filtered into an unused
mailbox for a currently unknown reason. I will investigate this
immediately. It was a mistake to push this patch, I will rectify right
away.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] drivers: cpufreq: Mark function as static in cpufreq.c
On 3 March 2014 09:12, Patrick Palka wrote: > -Wmissing-prototypes warns when a non-static function is defined > before a corresponding prototype (usually inside an included header > file) is declared. In such a case, it is impossible to reference the > non-static function from another file, and therefore the function > should be marked static (usually). Hope that makes sense! I understand that it should be made static as we don't have a prototype in any other header file, but I thought we shouldn't get the warning we are getting. warning: no previous prototype for 'show_boost' Because we have prototype/definition of function before it is used. Maybe a warning like: local function should be marked static could have been there ;) -- 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 1/2] x86: IOSF: add dummy functions for loadable modules
On 2014/3/1 10:40, David E. Box wrote:
> From: "David E. Box"
>
> Some loadable modules only need IOSF access on the platforms where it exists.
> Provide dummy functions to allow these modules to compile and load on the
> platforms where it doesn't exist.
This is not the right way, I think.
We can either default built-in this IOSF component, so that the
interface is always here, Or we can register the interfaces to the
global hooks, so that the consumers are able to check the hook to see if
it's available and make the calls if it is.
In the long turn, this could be a bus driver and framework needed.
Thanks,
-Aubrey
>
> Signed-off-by: David E. Box
> ---
> arch/x86/include/asm/iosf_mbi.h | 33 +
> arch/x86/kernel/iosf_mbi.c |6 ++
> 2 files changed, 39 insertions(+)
>
> diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
> index 8e71c79..9fc5402 100644
> --- a/arch/x86/include/asm/iosf_mbi.h
> +++ b/arch/x86/include/asm/iosf_mbi.h
> @@ -5,6 +5,8 @@
> #ifndef IOSF_MBI_SYMS_H
> #define IOSF_MBI_SYMS_H
>
> +#ifdef CONFIG_IOSF_MBI
> +
> #define MBI_MCR_OFFSET 0xD0
> #define MBI_MDR_OFFSET 0xD4
> #define MBI_MCRX_OFFSET 0xD8
> @@ -50,6 +52,8 @@
> #define BT_MBI_PCIE_READ 0x00
> #define BT_MBI_PCIE_WRITE0x01
>
> +bool iosf_mbi_available(void);
> +
> /**
> * iosf_mbi_read() - MailBox Interface read command
> * @port:port indicating subunit being accessed
> @@ -87,4 +91,33 @@ int iosf_mbi_write(u8 port, u8 opcode, u32 offset, u32
> mdr);
> */
> int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask);
>
> +#else /* CONFIG_IOSF_MBI is not enabled */
> +static inline
> +bool iosf_mbi_available(void)
> +{
> + return false;
> +}
> +
> +static inline
> +int iosf_mbi_read(u8 port, u8 opcode, u32 offset, u32 *mdr)
> +{
> + WARN();
> + return -EPERM;
> +}
> +
> +static inline
> +int iosf_mbi_write(u8 port, u8 opcode, u32 offset, u32 mdr)
> +{
> + WARN();
> + return -EPERM;
> +}
> +
> +static inline
> +int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask)
> +{
> + WARN();
> + return -EPERM;
> +}
> +#endif /* CONFIG_IOSF_MBI */
> +
> #endif /* IOSF_MBI_SYMS_H */
> diff --git a/arch/x86/kernel/iosf_mbi.c b/arch/x86/kernel/iosf_mbi.c
> index c3aae66..d3803c6 100644
> --- a/arch/x86/kernel/iosf_mbi.c
> +++ b/arch/x86/kernel/iosf_mbi.c
> @@ -177,6 +177,12 @@ int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32
> mdr, u32 mask)
> }
> EXPORT_SYMBOL(iosf_mbi_modify);
>
> +bool iosf_mbi_available(void)
> +{
> + return mbi_pdev;
> +}
> +EXPORT_SYMBOL(iosf_mbi_available);
> +
> static int iosf_mbi_probe(struct pci_dev *pdev,
> const struct pci_device_id *unused)
> {
>
--
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 PATCH] support Thinkpad X1 Carbon's adaptive keyboard
Hi all,
We are working together with Lenovo to enable thinkpad X1 Carbon's
fancy feature, Adaptive Keyboard[1] for Linux. Adaptive keyboard has
five modes on Windows including Home mode, Web browser mode, Web
conference mode, Function mode and Lay-flat mode. We enabled Home
mode and Function mode currently. Will try to find out how to enable
other modes later. Please review and comment attached patch.
Thanks,
Shuduo
[1]:http://shop.lenovo.com/us/en/laptops/thinkpad/x-series/x1-carbon/#features
>From da9d43beaa23071558a8031950cc21cc93946ec6 Mon Sep 17 00:00:00 2001
From: Shuduo Sang
Date: Mon, 3 Mar 2014 14:29:32 +0800
Subject: [PATCH] support thinkpad X1 Carbon's adaptive keyboard
Thinkpad X1 Carbon's adaptive keyboard has five modes including Home
mode, Web browser mode, Web conference mode, Function mode and Lay-flat
mode. We support Home mode and Function mode currently.
Signed-off-by: Bruce Ma
Signed-off-by: Shuduo Sang
---
drivers/platform/x86/thinkpad_acpi.c | 97
1 file changed, 97 insertions(+)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index defb6af..fcb738e 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3437,6 +3437,101 @@ err_exit:
return (res < 0)? res : 1;
}
+/* Thinkpad X1 Carbon support 5 modes including Home mode, Web browser
+ * mode, Web conference mode, Function mode and Lay-flat mode.
+ * We support Home mode and Function mode currently.
+ *
+ * Will consider support rest of modes in future.
+ *
+ */
+enum ADAPTIVE_KEY_MODE {
+ HOME_MODE,
+ WEB_BROWSER_MODE,
+ WEB_CONFERENCE_MODE,
+ FUNCTION_MODE,
+ LAYFLAT_MODE
+};
+
+int adaptive_keyboard_modes[] = {
+ HOME_MODE,
+/* WEB_BROWSER_MODE = 2,
+ WEB_CONFERENCE_MODE = 3, */
+ FUNCTION_MODE
+};
+
+#define DFR_CHANGE_ROW 0x101
+#define DFR_SHOW_QUICKVIEW_ROW 0x102
+
+/* press Fn key a while second, it will switch to Function Mode. Then
+ * release Fn key, previous mode be restored.
+ */
+bool adaptive_keyboard_mode_is_saved;
+int adaptive_keybarod_prev_mode;
+
+static int adaptive_keyboard_get_next_mode(int mode)
+{
+ int i;
+ int max_mode = sizeof(adaptive_keyboard_modes)/sizeof(int) - 1;
+
+ for (i = 0; i <= max_mode; i++) {
+ if (adaptive_keyboard_modes[i] == mode)
+ break;
+ }
+
+ if (i >= max_mode)
+ i = 0;
+ else
+ i++;
+
+ return adaptive_keyboard_modes[i];
+}
+
+static bool adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
+{
+ u32 current_mode = 0;
+ int new_mode = 0;
+
+ switch (scancode) {
+ case DFR_CHANGE_ROW:
+ if (adaptive_keyboard_mode_is_saved) {
+ new_mode = adaptive_keybarod_prev_mode;
+ adaptive_keyboard_mode_is_saved = false;
+ } else {
+ if (!acpi_evalf(
+ hkey_handle, _mode,
+ "GTRW", "dd", 0)) {
+ pr_err("Cannot read adaptive keyboard mode\n");
+ return false;
+ } else {
+ new_mode = adaptive_keyboard_get_next_mode(
+ current_mode);
+ }
+ }
+
+ if (!acpi_evalf(hkey_handle, NULL, "STRW", "vd", new_mode))
+ pr_err("Cannot set adaptive keyboard mode\n");
+
+ return true;
+
+ case DFR_SHOW_QUICKVIEW_ROW:
+ if (!acpi_evalf(hkey_handle,
+ _keybarod_prev_mode,
+ "GTRW", "dd", 0)) {
+ pr_err("Cannot read adaptive keyboard mode\n");
+ } else {
+ adaptive_keyboard_mode_is_saved = true;
+
+ if (!acpi_evalf(hkey_handle,
+ NULL, "STRW", "vd", FUNCTION_MODE))
+ pr_err("Cannot set adaptive keyboard mode\n");
+ }
+ return true;
+
+ default:
+ return false;
+ }
+}
+
static bool hotkey_notify_hotkey(const u32 hkey,
bool *send_acpi_ev,
bool *ignore_acpi_ev)
@@ -3456,6 +3551,8 @@ static bool hotkey_notify_hotkey(const u32 hkey,
*ignore_acpi_ev = true;
}
return true;
+ } else {
+ return adaptive_keyboard_hotkey_notify_hotkey(scancode);
}
return false;
}
--
1.9.0
--
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
linux-next: manual merge of the usb tree with the arm-soc tree
Hi Greg,
Today's linux-next merge of the usb tree got a conflict in
arch/arm/mach-tegra/Kconfig between commit ddb902cc3459 ("ARM: centralize
common multi-platform kconfig options") from the arm-soc tree and commit
f6723b569a67 ("usb: host: remove selects of USB_ARCH_HAS_?HCI") from the
usb 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 arch/arm/mach-tegra/Kconfig
index f61cd5b9f103,4926bd11f190..
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@@ -12,9 -18,10 +12,8 @@@ config ARCH_TEGR
select ARCH_HAS_RESET_CONTROLLER
select RESET_CONTROLLER
select SOC_BUS
- select USB_ARCH_HAS_EHCI if USB_SUPPORT
- select SPARSE_IRQ
select USB_ULPI if USB_PHY
select USB_ULPI_VIEWPORT if USB_PHY
- select USE_OF
help
This enables support for NVIDIA Tegra based systems.
pgpjoTPpz2eCY.pgp
Description: PGP signature
Re: [PATCH 3/5 v2] Staging: cxt1e1: Fix line length over 80 characters in hwprobe.c
On Mon, 2014-03-03 at 16:01 +0900, DaeSeok Youn wrote: > 2014-03-03 15:46 GMT+09:00 Krzysztof Hałasa : > > why not use some existing *hex_dump*() instead? > OK. but this patch is only for fix line length over 80 characters, > right? If it can be improved as your comment, > it must be in another patch. Not true. Always strive to improve the code in preference to shutting up checkpatch warnings. -- 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/2] x86: IOSF: Change IOSF_MBI Kconfig to default y
On 2014/3/1 10:40, David E. Box wrote: > From: "David E. Box" > > Make the IOSF Mailbox driver built in as it provides core functionality needed > for new Intel SOC platforms to access the device registers on the SOC. > > Signed-off-by: David E. Box > --- > arch/x86/Kconfig |7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index d3b1f8b..e34b252 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -2385,12 +2385,9 @@ config X86_DMA_REMAP > depends on STA2X11 > > config IOSF_MBI > - bool > + bool "Intel IOSF Mailbox Driver support" One concern here is, IOSF is not architectural for all of X86, can we change this as "Intel Atom IOSF Mailbox Driver support"? Or if you can confirm we'll use IOSF in the future onchip product, can we change this as "Intel SOC IOSF Mailbox Driver support"? Better to rename the file name as well. Thanks, -Aubrey > + default y > depends on PCI > - ---help--- > - To be selected by modules requiring access to the Intel OnChip System > - Fabric (IOSF) Sideband MailBox Interface (MBI). For MBI platforms > - enumerable by PCI. > > source "net/Kconfig" > > -- 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 3/5 v2] Staging: cxt1e1: Fix line length over 80 characters in hwprobe.c
2014-03-03 15:46 GMT+09:00 Krzysztof Hałasa :
> Daeseok Youn writes:
>
>> clean up checkpatch.pl warnings:
>> WARNING: Line length over 80 characters
>
> This warning should be long gone IMHO. It does more harm than good.
>
>> unsigned char *ucp = (unsigned char *) >mfg_info.data;
>>
>> pr_info("eeprom[00]: %02x %02x %02x %02x %02x %02x %02x
>> %02x\n",
>> - *(ucp + 0), *(ucp + 1), *(ucp + 2), *(ucp +
>> 3), *(ucp + 4), *(ucp + 5), *(ucp + 6), *(ucp + 7));
>> + *(ucp + 0), *(ucp + 1), *(ucp + 2), *(ucp + 3),
>> + *(ucp + 4), *(ucp + 5), *(ucp + 6), *(ucp + 7));
>> pr_info("eeprom[08]: %02x %02x %02x %02x %02x %02x %02x
>> %02x\n",
>> - *(ucp + 8), *(ucp + 9), *(ucp + 10), *(ucp +
>> 11), *(ucp + 12), *(ucp + 13), *(ucp + 14), *(ucp + 15));
>> + *(ucp + 8), *(ucp + 9), *(ucp + 10), *(ucp + 11),
>> + *(ucp + 12), *(ucp + 13), *(ucp + 14), *(ucp + 15));
>> pr_info("eeprom[16]: %02x %02x %02x %02x %02x %02x %02x
>> %02x\n",
>> - *(ucp + 16), *(ucp + 17), *(ucp + 18), *(ucp +
>> 19), *(ucp + 20), *(ucp + 21), *(ucp + 22), *(ucp + 23));
>> + *(ucp + 16), *(ucp + 17), *(ucp + 18), *(ucp + 19),
>> + *(ucp + 20), *(ucp + 21), *(ucp + 22), *(ucp + 23));
>> pr_info("eeprom[24]: %02x %02x %02x %02x %02x %02x %02x
>> %02x\n",
>> - *(ucp + 24), *(ucp + 25), *(ucp + 26), *(ucp +
>> 27), *(ucp + 28), *(ucp + 29), *(ucp + 30), *(ucp + 31));
>> + *(ucp + 24), *(ucp + 25), *(ucp + 26), *(ucp + 27),
>> + *(ucp + 28), *(ucp + 29), *(ucp + 30), *(ucp + 31));
>> pr_info("eeprom[32]: %02x %02x %02x %02x %02x %02x %02x
>> %02x\n",
>> - *(ucp + 32), *(ucp + 33), *(ucp + 34), *(ucp +
>> 35), *(ucp + 36), *(ucp + 37), *(ucp + 38), *(ucp + 39));
>> + *(ucp + 32), *(ucp + 33), *(ucp + 34), *(ucp + 35),
>> + *(ucp + 36), *(ucp + 37), *(ucp + 38), *(ucp + 39));
>> pr_info("eeprom[40]: %02x %02x %02x %02x %02x %02x %02x
>> %02x\n",
>> - *(ucp + 40), *(ucp + 41), *(ucp + 42), *(ucp +
>> 43), *(ucp + 44), *(ucp + 45), *(ucp + 46), *(ucp + 47));
>> + *(ucp + 40), *(ucp + 41), *(ucp + 42), *(ucp + 43),
>> + *(ucp + 44), *(ucp + 45), *(ucp + 46), *(ucp + 47));
>> }
>
> This one is probably an improvement, though... why not use some existing
> *hex_dump*() instead?
OK. but this patch is only for fix line length over 80 characters,
right? If it can be improved as your comment,
it must be in another patch.
>
>> - * match with board's first found interface, otherwise this is
>> first
>> - * found
>> + * match with board's first found interface, otherwise this is
>> + * fisrt found
>^
> I wonder what's your exact procedure for doing such changes :-)
"first" word is over 80 line character after applying my previous patch(2/5)
(previous patch is already merged to staging-next tree :-))
>
>> #ifdef SBE_MAP_DEBUG
>> pr_warning("%s: io remapped from phys %x to virt %x\n",
>> -hi->devname, (u_int32_t) hi->addr[j],
>> (u_int32_t) hi->addr_mapped[j]);
>> +hi->devname, (u_int32_t) hi->addr[j],
>> +(u_int32_t) hi->addr_mapped[j]);
>
> This one is fine, too. The others, I wouldn't touch them.
this line, same reason above one.
> --
> Krzysztof Halasa
>
> Research Institute for Automation and Measurements PIAP
> Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
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/2] x86: IOSF: Add loadable module support
Hi David, I'm probably too late to catch this thread. Just one question, what's the relationship between arch/x86/kernel/iosf_mbi.c and drivers/platform/x86/intel_baytrail.c Thanks, -Aubrey On 2014/3/1 10:40, David E. Box wrote: > From: "David E. Box" > > This patch series adds missing functionalty that mostly affected loadable > modules. > > The first patch adds dummy functions to allow drivers not completely > dependant on the IOSF MBI driver to compile on systems that don't have it. > > The second makes MBI driver built in. > > Changes from V4: > > - Put back Kconfig prompt for IOSF_MBI. > > Changes from V3: > > - Code is agreed to be small enough to not warrant forcing for > non-EXPERT only > > Changes from V2: > > - Remove non linux style externs from iosf_mbi.h > > Changes from V1: > > - Force default y for non-EXPERT to allow easier custom configuration > as suggested by hpa > - Add WARN() to dummy functions, other than iosf_mbi_available(), to > signal incorrect use as suggested by Alan > Also return EPERM in these functions > - Splits single patch into two patch series > > David E. Box (2): > x86: IOSF: add dummy functions for loadable modules > x86: IOSF: Change IOSF_MBI Kconfig to default y > > arch/x86/Kconfig|7 ++- > arch/x86/include/asm/iosf_mbi.h | 33 + > arch/x86/kernel/iosf_mbi.c |6 ++ > 3 files changed, 41 insertions(+), 5 deletions(-) > -- 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 v12 1/4] PHY: Add function set_speed to generic PHY framework
Hi Felipe and Kishon,
>>> >> >> This patch adds function set_speed to the generic PHY framework
>>> >> >> operation
>>> >> >> structure. This function can be called to instruct the PHY underlying
>>> >> >> layer
>>> >> >> at specified lane to configure for specified speed in hertz.
>>> >> >
>>> >> > why ? looks like clk_set_rate() is your friend here. Can you be more
>>> >> > descriptive of the use case ? When will this be used ?
>>> >> >
>>> >>
>>> >> The phy_set_speed is used to configure the operation speed of the PHY
>>> >> at run-time. The clock interface in general is used to configure the
>>> >> clock input to the IP. I don't believe they are the same thing. Maybe
>>> >> it will be clear in my response to your second email
>>> >
>>> > The problem with this is that you end up adding SATA-specific details to
>>> > something which is supposed to be generic.
>>>
>>> Setting the operation speed is pretty generic from an interface point
>>> of view. An generic multi-purpose PHY can support multiple speed. If
>>
>> no it's not. Specially when you consider that your "speed" argument can
>> be just about anything and depending on the underlying bus, it *will* be
>> treated differently. Note that e.g. in OMAP devices the exact *same* PHY
>> IP is used for PCIe, SATA and USB... now, let's assume for the sake of
>> argument that we were to implement ->set_speed() in that environment,
>> how do you plan to do that ? a 6MHz arguments isn't valid from USB stand
>> point and could mean different things in PCIe or SATA.
>>
>
> Correct me if I am wrong here. If the same PHY is used for PCIe, SATA,
> and USB, would you not need to indicate what speed the PHY should be
> operated at - unless the underlying IP magically negotiate and
> configured automatically? If so, what about PHY isn't so intelligent?
> How should you suggest that we handle these?
>
>>> the upper layer wish to operate at an specified speed (say for testing
>>> purpose and etc), it can be allowed.
>>
>> anything for testing purposes, should be limited to test scenarios.
>
> Testing purpose is only one use case. Another use case is to limit the
> speed so that I can confirm the driver actually works with various
> speed of the device and handle correctly.
>
>>
>>> > After negoatiation, don't you
>>> > get any interrupt from your PHY indicating that link speed negotiation
>>> > is done ? Or is that IRQ only on AHCI IP ?
>>>
>>> There is NO interrupt from the PHY. The IRQ is assoicated with the
>>> AHCI IP. With SATA host flow, it starts off with an COMRESET to start
>>> the link negotiation. At that point, it will poll for completion.
>>>
>>> Any other concerns?
>>
>> hey, calm down... just trying to prevent us from applying something
>> which isn't truly generic and I don't think "->set_speed" is generic
>> enough. The semantics of the "speed" argument won't be valid for all use
>> cases.
>>
>> I can already see people using that to pass
>> USB_SPEED_{LOW,FULL,HIGH,SUPER}, instead of actual speed numbers. We wil
>> end up with a mess to handle from a PHY driver, specially in cases such
>> as OMAP where, as mentioned above, the same IP is used for SATA, PCIe
>> and USB3.
>>
>
> This PHY isn't as "intelligent" as other PHY's. What would you suggest
> as I need an method to indicate to the underlying PHY that I want to
> operate at an specified speed?
Sorry if I am pinging you guys too fast here. I am look from an
solution and open to any solution in which it is acceptable for your
original intent of the generic PHY framework. I understand that you
don't believe set_speed is generic enough and may not apply to omap.
Or if you prefer we can try changing the init function to take an
initial MAX speed?
-Loc
--
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 v8 2/2] dmaengine: add Qualcomm BAM dma driver
On Mon, 2014-03-03 at 00:30 -0600, Andy Gross wrote:
> Add the DMA engine driver for the QCOM Bus Access Manager (BAM) DMA controller
> found in the MSM 8x74 platforms.
>
> Each BAM DMA device is associated with a specific on-chip peripheral. Each
> channel provides a uni-directional data transfer engine that is capable of
> transferring data between the peripheral and system memory (System mode), or
> between two peripherals (BAM2BAM).
[]
trivia:
> +static u32 process_channel_irqs(struct bam_device *bdev)
> +{
[]
> + for (i = 0; i < bdev->num_channels; i++) {
> + struct bam_chan *bchan = >channels[i];
> + if (srcs & BIT(i)) {
> + /* clear pipe irq */
> + pipe_stts = readl_relaxed(bdev->regs +
> + BAM_P_IRQ_STTS(i));
> +
> + writel_relaxed(pipe_stts, bdev->regs +
> + BAM_P_IRQ_CLR(i));
> +
> + spin_lock_irqsave(>vc.lock, flags);
> + async_desc = bchan->curr_txd;
> +
> + if (async_desc) {
> + async_desc->num_desc -= async_desc->xfer_len;
> + async_desc->curr_desc += async_desc->xfer_len;
> + bchan->curr_txd = NULL;
> +
> + /* manage FIFO */
> + bchan->head += async_desc->xfer_len;
> + bchan->head %= MAX_DESCRIPTORS;
> +
> + /*
> + * if complete, process cookie. Otherwise
> + * push back to front of desc_issued so that
> + * it gets restarted by the tasklet
> + */
> + if (!async_desc->num_desc)
> + vchan_cookie_complete(_desc->vd);
> + else
> + list_add(_desc->vd.node,
> + >vc.desc_issued);
> + }
> +
> + spin_unlock_irqrestore(>vc.lock, flags);
> + }
> + }
This could be written with fewer indents using continue
(and maybe faster using ffs too)
for (i = 0; i < bdev->num_channels; i++) {
struct bam_chan *bchan;
if (!(srcs & BIT(i)))
continue;
bchan = >channels[i];
/* clear pipe irq */
pipe_stts = readl_relaxed(bdev->regs + BAM_P_IRQ_STTS(i));
writel_relaxed(pipe_stts, bdev->regs + BAM_P_IRQ_CLR(i));
etc...
--
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 3/5 v2] Staging: cxt1e1: Fix line length over 80 characters in hwprobe.c
Daeseok Youn writes:
> clean up checkpatch.pl warnings:
> WARNING: Line length over 80 characters
This warning should be long gone IMHO. It does more harm than good.
> unsigned char *ucp = (unsigned char *) >mfg_info.data;
>
> pr_info("eeprom[00]: %02x %02x %02x %02x %02x %02x %02x
> %02x\n",
> - *(ucp + 0), *(ucp + 1), *(ucp + 2), *(ucp + 3),
> *(ucp + 4), *(ucp + 5), *(ucp + 6), *(ucp + 7));
> + *(ucp + 0), *(ucp + 1), *(ucp + 2), *(ucp + 3),
> + *(ucp + 4), *(ucp + 5), *(ucp + 6), *(ucp + 7));
> pr_info("eeprom[08]: %02x %02x %02x %02x %02x %02x %02x
> %02x\n",
> - *(ucp + 8), *(ucp + 9), *(ucp + 10), *(ucp +
> 11), *(ucp + 12), *(ucp + 13), *(ucp + 14), *(ucp + 15));
> + *(ucp + 8), *(ucp + 9), *(ucp + 10), *(ucp + 11),
> + *(ucp + 12), *(ucp + 13), *(ucp + 14), *(ucp + 15));
> pr_info("eeprom[16]: %02x %02x %02x %02x %02x %02x %02x
> %02x\n",
> - *(ucp + 16), *(ucp + 17), *(ucp + 18), *(ucp +
> 19), *(ucp + 20), *(ucp + 21), *(ucp + 22), *(ucp + 23));
> + *(ucp + 16), *(ucp + 17), *(ucp + 18), *(ucp + 19),
> + *(ucp + 20), *(ucp + 21), *(ucp + 22), *(ucp + 23));
> pr_info("eeprom[24]: %02x %02x %02x %02x %02x %02x %02x
> %02x\n",
> - *(ucp + 24), *(ucp + 25), *(ucp + 26), *(ucp +
> 27), *(ucp + 28), *(ucp + 29), *(ucp + 30), *(ucp + 31));
> + *(ucp + 24), *(ucp + 25), *(ucp + 26), *(ucp + 27),
> + *(ucp + 28), *(ucp + 29), *(ucp + 30), *(ucp + 31));
> pr_info("eeprom[32]: %02x %02x %02x %02x %02x %02x %02x
> %02x\n",
> - *(ucp + 32), *(ucp + 33), *(ucp + 34), *(ucp +
> 35), *(ucp + 36), *(ucp + 37), *(ucp + 38), *(ucp + 39));
> + *(ucp + 32), *(ucp + 33), *(ucp + 34), *(ucp + 35),
> + *(ucp + 36), *(ucp + 37), *(ucp + 38), *(ucp + 39));
> pr_info("eeprom[40]: %02x %02x %02x %02x %02x %02x %02x
> %02x\n",
> - *(ucp + 40), *(ucp + 41), *(ucp + 42), *(ucp +
> 43), *(ucp + 44), *(ucp + 45), *(ucp + 46), *(ucp + 47));
> + *(ucp + 40), *(ucp + 41), *(ucp + 42), *(ucp + 43),
> + *(ucp + 44), *(ucp + 45), *(ucp + 46), *(ucp + 47));
> }
This one is probably an improvement, though... why not use some existing
*hex_dump*() instead?
> - * match with board's first found interface, otherwise this is
> first
> - * found
> + * match with board's first found interface, otherwise this is
> + * fisrt found
^
I wonder what's your exact procedure for doing such changes :-)
> #ifdef SBE_MAP_DEBUG
> pr_warning("%s: io remapped from phys %x to virt %x\n",
> -hi->devname, (u_int32_t) hi->addr[j],
> (u_int32_t) hi->addr_mapped[j]);
> +hi->devname, (u_int32_t) hi->addr[j],
> +(u_int32_t) hi->addr_mapped[j]);
This one is fine, too. The others, I wouldn't touch them.
--
Krzysztof Halasa
Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
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 3/5] spi: remove obsolete spi-ti-ssp driver
On Wed, Feb 26, 2014 at 01:43:32PM +0100, Arnd Bergmann wrote: > The tnetv107x platform is getting removed, so this driver > will not be needed any more. If you get the acks you're looking for can you please resend with them? signature.asc Description: Digital signature
[Patch v8 0/2] Add Qualcomm BAM dmaengine driver
This patch set introduces the dmaengine driver for the Qualcomm Bus Access Manager (BAM) DMA controller present on MSM 8x74 devices. A number of the on-chip devices have their own BAM DMA controller and use it to move data between system memory and peripherals or between two peripherals. The initial version of this driver will only support slave DMA operations between system memory and peripherals. Changes from v7: - Fix shift issue when reading NUM_EEs field. - Unmask global BAM interrupt during BAM initialization. Changes from v6: - Changed KConfig dependency from ARCH_MSM_DT to ARCH_QCOM. - Incorporated comments on DT binding. - Changed driver source file to accomodate DT changes. Changes from v5: - Separated copyright from BAM description - Removed usage of slave dma direction - Reworked slave config interface - Removed max segment size restriction in slave_sg - Added acked-by on DT patch - Fixed nit comments Changes from v4: - Add devm_free_irq() to .remove to avoid race condition - Free FIFO memory in .remove Changes from v3: - Remove unused bam_channel_dir. - Remove incorrect write to BAM_IRQ_SRCS_EE (read only). - Remove dma direction from DT binding and revise driver to use direction from prep_slave_sg. - Remove unnecessary channel reset from channel_init. This could affect channels controlled from other execution environments. - Change terminate_all to also take care of the current active descriptor. - Rework .remove function to correctly mask interrupts and clean up resources and tasklets. Changes from v2: - Corrected Kconfig dependencies - Moved execution environment ID to controller DT binding. The EE is a global setting across all of the channels on the controller. - Combined header into source file. - Corrected copyright date. - Moved channel hardware initialization to occur when channel is used for the first time. - Converted dma_alloc_coherent to dma_alloc_writecombine - Removed unecessary reset of channel from the dma terminate_all - Corrected usage of EE in irq handler and channel configuration functions. - Changed resource functions inside probe to use correct APIs. - Removed dma filter function and modified dma_xlate to use dma_get_slave_channel API - Fixed various nit comments Changes from v1: - Converted driver to use virt-dma - Reworked probe function per review comments - tx_status function now computes and returns residuals - Removed proprietary slave config. Removed associated include file. - Renamed files to reflect vendor name instead of specific device - Converted to use (readl|writel)_relaxed w/ appropriate barriers - Removed unions in favor of standard types. Andy Gross (2): dmaengine: qcom_bam_dma: Add device tree binding dmaengine: add Qualcomm BAM dma driver .../devicetree/bindings/dma/qcom_bam_dma.txt | 41 + drivers/dma/Kconfig|9 + drivers/dma/Makefile |1 + drivers/dma/qcom_bam_dma.c | 1110 4 files changed, 1161 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/qcom_bam_dma.txt create mode 100644 drivers/dma/qcom_bam_dma.c -- 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/
[Patch v8 1/2] dmaengine: qcom_bam_dma: Add device tree binding
Add device tree binding support for the QCOM BAM DMA driver.
Acked-by: Kumar Gala
Signed-off-by: Andy Gross
---
.../devicetree/bindings/dma/qcom_bam_dma.txt | 41
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
new file mode 100644
index 000..d75a9d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
@@ -0,0 +1,41 @@
+QCOM BAM DMA controller
+
+Required properties:
+- compatible: must contain "qcom,bam-v1.4.0" for MSM8974
+- reg: Address range for DMA registers
+- interrupts: Should contain the one interrupt shared by all channels
+- #dma-cells: must be <1>, the cell in the dmas property of the client device
+ represents the channel number
+- clocks: required clock
+- clock-names: must contain "bam_clk" entry
+- qcom,ee : indicates the active Execution Environment identifier (0-7) used in
+ the secure world.
+
+Example:
+
+ uart-bam: dma@f9984000 = {
+ compatible = "qcom,bam-v1.4.0";
+ reg = <0xf9984000 0x15000>;
+ interrupts = <0 94 0>;
+ clocks = < GCC_BAM_DMA_AHB_CLK>;
+ clock-names = "bam_clk";
+ #dma-cells = <1>;
+ qcom,ee = <0>;
+ };
+
+DMA clients must use the format described in the dma.txt file, using a two cell
+specifier for each channel.
+
+Example:
+ serial@f991e000 {
+ compatible = "qcom,msm-uart";
+ reg = <0xf991e000 0x1000>
+ <0xf9944000 0x19000>;
+ interrupts = <0 108 0>;
+ clocks = < GCC_BLSP1_UART2_APPS_CLK>,
+ < GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+
+ dmas = < 0>, < 1>;
+ dma-names = "rx", "tx";
+ };
--
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/
[Patch v8 2/2] dmaengine: add Qualcomm BAM dma driver
Add the DMA engine driver for the QCOM Bus Access Manager (BAM) DMA controller
found in the MSM 8x74 platforms.
Each BAM DMA device is associated with a specific on-chip peripheral. Each
channel provides a uni-directional data transfer engine that is capable of
transferring data between the peripheral and system memory (System mode), or
between two peripherals (BAM2BAM).
The initial release of this driver only supports slave transfers between
peripherals and system memory.
Signed-off-by: Andy Gross
---
drivers/dma/Kconfig|9 +
drivers/dma/Makefile |1 +
drivers/dma/qcom_bam_dma.c | 1110
3 files changed, 1120 insertions(+)
create mode 100644 drivers/dma/qcom_bam_dma.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 605b016..f87cef9 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -401,4 +401,13 @@ config DMATEST
config DMA_ENGINE_RAID
bool
+config QCOM_BAM_DMA
+ tristate "QCOM BAM DMA support"
+ depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ ---help---
+ Enable support for the QCOM BAM DMA controller. This controller
+ provides DMA capabilities for a variety of on-chip devices.
+
endif
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index a029d0f4..907b915 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -44,3 +44,4 @@ obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
obj-$(CONFIG_TI_CPPI41) += cppi41.o
obj-$(CONFIG_K3_DMA) += k3dma.o
obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
+obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
new file mode 100644
index 000..3210983
--- /dev/null
+++ b/drivers/dma/qcom_bam_dma.c
@@ -0,0 +1,1110 @@
+/*
+ * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+/*
+ * QCOM BAM DMA engine driver
+ *
+ * QCOM BAM DMA blocks are distributed amongst a number of the on-chip
+ * peripherals on the MSM 8x74. The configuration of the channels are
dependent
+ * on the way they are hard wired to that specific peripheral. The peripheral
+ * device tree entries specify the configuration of each channel.
+ *
+ * The DMA controller requires the use of external memory for storage of the
+ * hardware descriptors for each channel. The descriptor FIFO is accessed as a
+ * circular buffer and operations are managed according to the offset within
the
+ * FIFO. After pipe/channel reset, all of the pipe registers and internal
state
+ * are back to defaults.
+ *
+ * During DMA operations, we write descriptors to the FIFO, being careful to
+ * handle wrapping and then write the last FIFO offset to that channel's
+ * P_EVNT_REG register to kick off the transaction. The P_SW_OFSTS register
+ * indicates the current FIFO offset that is being processed, so there is some
+ * indication of where the hardware is currently working.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dmaengine.h"
+#include "virt-dma.h"
+
+struct bam_desc_hw {
+ u32 addr; /* Buffer physical address */
+ u16 size; /* Buffer size in bytes */
+ u16 flags;
+};
+
+#define DESC_FLAG_INT BIT(15)
+#define DESC_FLAG_EOT BIT(14)
+#define DESC_FLAG_EOB BIT(13)
+
+struct bam_async_desc {
+ struct virt_dma_desc vd;
+
+ u32 num_desc;
+ u32 xfer_len;
+ struct bam_desc_hw *curr_desc;
+
+ enum dma_transfer_direction dir;
+ size_t length;
+ struct bam_desc_hw desc[0];
+};
+
+#define BAM_CTRL 0x
+#define BAM_REVISION 0x0004
+#define BAM_SW_REVISION0x0080
+#define BAM_NUM_PIPES 0x003C
+#define BAM_TIMER 0x0040
+#define BAM_TIMER_CTRL 0x0044
+#define BAM_DESC_CNT_TRSHLD0x0008
+#define BAM_IRQ_SRCS 0x000C
+#define BAM_IRQ_SRCS_MSK 0x0010
+#define BAM_IRQ_SRCS_UNMASKED 0x0030
+#define BAM_IRQ_STTS 0x0014
+#define BAM_IRQ_CLR0x0018
+#define BAM_IRQ_EN 0x001C
+#define BAM_CNFG_BITS 0x007C
+#define BAM_IRQ_SRCS_EE(pipe) (0x0800 + ((pipe) * 0x80))
+#define BAM_IRQ_SRCS_MSK_EE(pipe)
Re: [PATCH v6 00/14] uprobes: Add uprobes support for ARM
> Oleg, > > I've been looking at arch/Kconfig and kernel/trace/Kconfig where > they deal with uprobes. The relevant items are CONFIG_UPROBES and > CONFIG_UPROBE_EVENT. It just doesn't look right to me. It looks It should be me who should take the blame for this and not Oleg. This was discussed more than couple of times. I can recollect couple of discussions here. http://article.gmane.org/gmane.linux.kernel/1017186 http://article.gmane.org/gmane.linux.kernel/1001605 I know there were more discussions on this, but I cant dig them out at this time. Finally it was decided that 1. Users shouldnt have to select more than one config to select Uprobes. 2. There was no point in selecting Uprobes and not having Uprobe_event and vice versa. >From the above, If a user chose UPROBE_EVENT, (which is the interface for uprobes), we would automatically assume that he wants to use Uprobes framework. > like "select" is used in part maybe just to avoid the recursive > dependency error that would be generated if "depends on" were used > in both places. We did "Select Uprobes" not because of avoiding recursive dependency but as told above, to select the framework, given that user has chosen the framework. We dont want to give a choice to user to choose uprobe_event but not choose Uprobes or vice versa. > However I don't think UPROBES should be dependent on > UPROBE_EVENT, only the other way around. As RK noted in previous Whats the point of having the framework(Uprobes) without an interface? > email (copied in part below) the select does not pull in the lower > level dependencies. This all works on x86 only because > arch/x86/Kconfig defines CONFIG_PERF_EVENT (which feels like a big > hammer). We don't need to do this on ARM, and we don't do it. The > result is that, unless PERF_EVENT is set separately, uprobes tends > not to build. I was lucking-out in my testing due to other default > config items turning on PERF_EVENT. > -- Thanks and Regards Srikar Dronamraju -- 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] asm-generic: add sched_setattr/sched_getattr syscalls
Acked-by: Lennox Wu 2014-02-03 23:33 GMT+08:00 James Hogan : > Add the sched_setattr and sched_getattr syscalls to the generic syscall > list, which is used by the following architectures: arc, arm64, c6x, > hexagon, metag, openrisc, score, tile, unicore32. > > Signed-off-by: James Hogan > Cc: Arnd Bergmann > Cc: linux-a...@vger.kernel.org > Cc: Vineet Gupta > Cc: Catalin Marinas > Cc: Will Deacon > Cc: linux-arm-ker...@lists.infradead.org > Cc: Mark Salter > Cc: Aurelien Jacquiot > Cc: linux-c6x-...@linux-c6x.org > Cc: Richard Kuo > Cc: linux-hexa...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: Jonas Bonn > Cc: li...@lists.openrisc.net > Cc: Chen Liqin > Cc: Lennox Wu > Cc: Chris Metcalf > Cc: Guan Xuetao > --- > include/uapi/asm-generic/unistd.h | 6 +-> 1 file changed, 5 > insertions(+), 1 deletion(-) > > diff --git a/include/uapi/asm-generic/unistd.h > b/include/uapi/asm-generic/unistd.h > index a20a9b4d3871..dde8041f40d2 100644 > --- a/include/uapi/asm-generic/unistd.h > +++ b/include/uapi/asm-generic/unistd.h > @@ -692,9 +692,13 @@ __SC_COMP(__NR_process_vm_writev, sys_process_vm_writev, > \ > __SYSCALL(__NR_kcmp, sys_kcmp) > #define __NR_finit_module 273 > __SYSCALL(__NR_finit_module, sys_finit_module) > +#define __NR_sched_setattr 274 > +__SYSCALL(__NR_sched_setattr, sys_sched_setattr) > +#define __NR_sched_getattr 275 > +__SYSCALL(__NR_sched_getattr, sys_sched_getattr) > > #undef __NR_syscalls > -#define __NR_syscalls 274 > +#define __NR_syscalls 276 > > /* > * All syscalls below here should go away really, > -- > 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/
linux-next: manual merge of the tip tree with the pci tree
Hi all,
Today's linux-next merge of the tip tree got conflicts in
arch/x86/pci/numaq_32.c and arch/x86/pci/visws.c between commit
8d7d818676d3 ("x86/PCI: Use pcibios_scan_root() instead of
pci_scan_bus_with_sysdata()") from the pci tree and commits c5f9ee3d665a
("x86, platforms: Remove SGI Visual Workstation") and b5660ba76b41 ("x86,
platforms: Remove NUMAQ") from the tip tree.
I just removed the files and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpMjKXD8Se6r.pgp
Description: PGP signature
linux-next: manual merge of the tip tree with the pci tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
drivers/pci/Makefile between commit 39656f29f665 ("PCI: Cleanup per-arch
list of object files") from the pci tree and commit c5f9ee3d665a ("x86,
platforms: Remove SGI Visual Workstation") from the tip 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 drivers/pci/Makefile
index e2501ac6fe84,9d5ee4dcee7d..
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@@ -33,15 -33,20 +33,14 @@@ obj-$(CONFIG_PCI_IOV) += iov.
#
# Some architectures use the generic PCI setup functions
#
-obj-$(CONFIG_X86) += setup-bus.o
-obj-$(CONFIG_ALPHA) += setup-bus.o setup-irq.o
-obj-$(CONFIG_ARM) += setup-bus.o setup-irq.o
-obj-$(CONFIG_UNICORE32) += setup-bus.o setup-irq.o
-obj-$(CONFIG_PARISC) += setup-bus.o
-obj-$(CONFIG_SUPERH) += setup-bus.o setup-irq.o
-obj-$(CONFIG_PPC) += setup-bus.o
-obj-$(CONFIG_FRV) += setup-bus.o
-obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
-obj-$(CONFIG_MN10300) += setup-bus.o
-obj-$(CONFIG_MICROBLAZE) += setup-bus.o
-obj-$(CONFIG_TILE) += setup-bus.o setup-irq.o
-obj-$(CONFIG_SPARC_LEON) += setup-bus.o setup-irq.o
-obj-$(CONFIG_M68K) += setup-bus.o setup-irq.o
+obj-$(CONFIG_ALPHA) += setup-irq.o
+obj-$(CONFIG_ARM) += setup-irq.o
+obj-$(CONFIG_UNICORE32) += setup-irq.o
+obj-$(CONFIG_SUPERH) += setup-irq.o
+obj-$(CONFIG_MIPS) += setup-irq.o
- obj-$(CONFIG_X86_VISWS) += setup-irq.o
+obj-$(CONFIG_TILE) += setup-irq.o
+obj-$(CONFIG_SPARC_LEON) += setup-irq.o
+obj-$(CONFIG_M68K) += setup-irq.o
#
# ACPI Related PCI FW Functions
pgpM0d4fWjIBe.pgp
Description: PGP signature
linux-next: manual merge of the watchdog tree with the arm-soc tree
Hi Wim,
Today's linux-next merge of the watchdog tree got a conflict in
drivers/watchdog/Kconfig between commit 59416745bb8c ("watchdog: orion:
Enable the build on ARCH_MVEBU") from the arm-soc tree and commit
db5dd336cb23 ("watchdog: orion: prepare new Dove DT Kconfig variable")
from the watchdog 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 drivers/watchdog/Kconfig
index f1ff408c4b17,90f950d039c4..
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@@ -292,7 -301,7 +301,7 @@@ config DAVINCI_WATCHDO
config ORION_WATCHDOG
tristate "Orion watchdog"
- depends on ARCH_ORION5X || ARCH_KIRKWOOD || ARCH_DOVE || ARCH_MVEBU
- depends on ARCH_ORION5X || ARCH_KIRKWOOD || ARCH_DOVE || MACH_DOVE
++ depends on ARCH_ORION5X || ARCH_KIRKWOOD || ARCH_DOVE || ARCH_MVEBU ||
MACH_DOVE
select WATCHDOG_CORE
help
Say Y here if to include support for the watchdog timer
pgpCErxEfbDzF.pgp
Description: PGP signature
Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree
On Sun, Mar 2, 2014 at 9:21 PM, Stephen Warren wrote:
> On 03/02/2014 06:02 PM, Stephen Rothwell wrote:
>> Hi Stephen,
>>
>> Today's linux-next merge of the bcm2835 tree got a conflict in
>> arch/arm/mach-bcm2835/Kconfig between commits ddb902cc3459 ("ARM:
>> centralize common multi-platform kconfig options") and
>> 0676b21fffd1 ("ARM: bcm2835: enable V6K instead of plain V6") from
>> the arm-soc tree and commit d30fe6272183 ("ARM: bcm2835: Move to
>> mach-bcm directory") from the bcm2835 tree.
>
> Olof, Arnd, Kevin,
>
> Do you want me to rebase the patch that moves
> arch/arm/mach-bcm2835/Kconfig into arch/arm/mach-bcm/Kconfig, or even
> drop it and take it through arm-soc directly? Or, will you just handle
> this when you merge the pull request?
We should be fine handling it when we merge. Conflicts when we merge
in are just fine unless they are excessive, what we want to avoid for
most silly cases is when it'll be exposed all the way up to Linus.
Even then, some of them are ok since it's just how development works.
-Olof
--
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 V9 2/2] ARM: dts: Enable ahci sata and sata phy
This patch adds dt entry for ahci sata controller and its
corresponding phy controller.phy node has been added w.r.t
new generic phy framework.
Signed-off-by: Yuvaraj Kumar C D
---
Changes since V8:
1.sata@122f and sata_phy@1217 disabled by default in
SOC specific dts file and enabled the same in board dts file.
Changes since V7:
1.syscon-phandle name updated.
Changes since V6:none
Changes since V5:none
Changes since V4:
1.Used the new phandle "sata_phy_i2c" in the DT entry.
2.Updated binding document.
Changes since V3:
1.Moved the binding info to the /bindings/phy/
Changes since V2:
1.Used syscon interface to PMU handling.
2.Changed "sata-phy-i2c" to "exynos-sataphy-i2c".
Changes since V1:
1.Minor changes to node name convention.
2.Updated binding document.
.../devicetree/bindings/ata/exynos-sata-phy.txt| 14
.../devicetree/bindings/ata/exynos-sata.txt| 25 +-
.../devicetree/bindings/phy/samsung-phy.txt| 36
arch/arm/boot/dts/exynos5250-arndale.dts | 21
arch/arm/boot/dts/exynos5250-smdk5250.dts | 17 +
arch/arm/boot/dts/exynos5250.dtsi | 18 +++---
6 files changed, 98 insertions(+), 33 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
diff --git a/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
b/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
deleted file mode 100644
index 37824fa..000
--- a/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* Samsung SATA PHY Controller
-
-SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
-Each SATA PHY controller should have its own node.
-
-Required properties:
-- compatible: compatible list, contains "samsung,exynos5-sata-phy"
-- reg :
-
-Example:
-sata@ffe07000 {
-compatible = "samsung,exynos5-sata-phy";
-reg = <0xffe07000 0x1000>;
-};
diff --git a/Documentation/devicetree/bindings/ata/exynos-sata.txt
b/Documentation/devicetree/bindings/ata/exynos-sata.txt
index 0849f10..b2adb1f 100644
--- a/Documentation/devicetree/bindings/ata/exynos-sata.txt
+++ b/Documentation/devicetree/bindings/ata/exynos-sata.txt
@@ -4,14 +4,21 @@ SATA nodes are defined to describe on-chip Serial ATA
controllers.
Each SATA controller should have its own node.
Required properties:
-- compatible: compatible list, contains "samsung,exynos5-sata"
-- interrupts:
-- reg :
-- samsung,sata-freq :
+- compatible : compatible list, contains "samsung,exynos5-sata"
+- interrupts :
+- reg :
+- samsung,sata-freq:
+- phys : as mentioned in phy-bindings.txt
+- phy-names: as mentioned in phy-bindings.txt
Example:
-sata@ffe08000 {
-compatible = "samsung,exynos5-sata";
-reg = <0xffe08000 0x1000>;
-interrupts = <115>;
-};
+ sata@122f {
+ compatible = "snps,dwc-ahci";
+ samsung,sata-freq = <66>;
+ reg = <0x122f 0x1ff>;
+ interrupts = <0 115 0>;
+ clocks = < 277>, < 143>;
+ clock-names = "sata", "sclk_sata";
+ phys = <_phy>;
+ phy-names = "sata-phy";
+ };
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index c0fccaa..a937f75 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -20,3 +20,39 @@ Required properties:
- compatible : should be "samsung,exynos5250-dp-video-phy";
- reg : offset and length of the Display Port PHY register set;
- #phy-cells : from the generic PHY bindings, must be 0;
+
+Samsung SATA PHY Controller
+---
+
+SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
+Each SATA PHY controller should have its own node.
+
+Required properties:
+- compatible: compatible list, contains "samsung,exynos5250-sata-phy"
+- reg : offset and length of the SATA PHY register set;
+- #phy-cells : from the generic phy bindings;
+
+Example:
+ sata_phy: sata-phy@1217 {
+ compatible = "samsung,exynos5250-sata-phy";
+ reg = <0x1217 0x1ff>;
+ clocks = < 287>;
+ clock-names = "sata_phyctrl";
+ #phy-cells = <0>;
+ samsung,exynos-sataphy-i2c-phandle = <_phy_i2c>;
+ samsung,syscon-phandle = <_syscon>;
+ };
+
+Device-Tree bindings for sataphy i2c client driver
+--
+
+Required properties:
+compatible: Should
[PATCH] target-i386: bugfix of Intel MPX
>From 3a7783cd9a0556787809d3d5ecb5f2b85dd9fc02 Mon Sep 17 00:00:00 2001
From: Liu Jinsong
Date: Mon, 3 Mar 2014 18:56:39 +0800
Subject: [PATCH] target-i386: bugfix of Intel MPX
The correct size of cpuid 0x0d sub-leaf 4 is 0x40, not 0x10.
This is confirmed by Anvin H Peter and Mallick Asit K.
Signed-off-by: Liu Jinsong
Cc: H. Peter Anvin
Cc: Asit K Mallick
---
target-i386/cpu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 0e8812a..9f69d7e 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -339,7 +339,7 @@ static const ExtSaveArea ext_save_areas[] = {
[3] = { .feature = FEAT_7_0_EBX, .bits = CPUID_7_0_EBX_MPX,
.offset = 0x3c0, .size = 0x40 },
[4] = { .feature = FEAT_7_0_EBX, .bits = CPUID_7_0_EBX_MPX,
-.offset = 0x400, .size = 0x10 },
+.offset = 0x400, .size = 0x40 },
};
const char *get_register_name_32(unsigned int reg)
--
1.7.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 V9 1/2] PHY: Exynos: Add Exynos5250 SATA PHY driver
This patch adds the SATA PHY driver for Exynos5250.This driver uses the generic PHY framework to deal with SATA PHY.Exynos5250 SATA PHY comprises of CMU and TRSV blocks which are of I2C register Map.So this driver configures the CMU and TRSV block of exynos5250 SATA PHY using i2c. Signed-off-by: Yuvaraj Kumar C D Signed-off-by: Girish K S Signed-off-by: Vasanth Ananthan --- Changes from V8: 1. Updated commit message. Changes from V7: 1.Used BIT macro and made CONFIG_PHY_EXYNOS5250_SATA depends on HAS_IOMEM and OF. Changes from V6: 1.Removed phy-exynos5250-sata-i2c.c,as it is not required after moving to of_find_i2c_device_by_node(). 2.Changed struct __iomem *pmureg to struct regmap *pmureg. 3.Changed the wait_for_reg_status() to return 0 or -EFAULT. Changes from V5: 1.Rebased on latest generic PHY framework for-next tree. 2.Minor nits such as indentations. Changes from V4: 1.Made Exynos5250 SATA PHY driver by default selects CONFIG_I2C and CONFIG_I2C_S3C2410, as SATA PHY driver depends on I2C. 2.struct i2c_driver sataphy_i2c_driver made static which was earlier global type. 3.Renamed the files to phy-exynos5250-sata.c and phy-exynos5250-sata-i2c.c and CONFIG_EXYNOS5250_SATA_PHY to CONFIG_PHY_EXYNOS5250_SATA. Changes from V3: 1.Moved devm_phy_create before to devm_phy_provider_register. Changes from V2: 1.Removed of_match_table 2.Moved to syscon interface for PMU handling. Changes from V1: 1.Adapted to latest version of Generic PHY framework 2.Removed exynos_sata_i2c_remove function. drivers/phy/Kconfig | 15 +++ drivers/phy/Makefile |1 + drivers/phy/phy-exynos5250-sata.c | 251 + 3 files changed, 267 insertions(+) create mode 100644 drivers/phy/phy-exynos5250-sata.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 5bf9ed3..0431284 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -70,4 +70,19 @@ config BCM_KONA_USB2_PHY help Enable this to support the Broadcom Kona USB 2.0 PHY. +config PHY_EXYNOS5250_SATA + tristate "Exynos5250 Sata SerDes/PHY driver" + depends on SOC_EXYNOS5250 + depends on HAS_IOMEM + depends on OF + select GENERIC_PHY + select I2C + select I2C_S3C2410 + select MFD_SYSCON + help + Enable this to support SATA SerDes/Phy found on Samsung's + Exynos5250 based SoCs.This SerDes/Phy supports SATA 1.5 Gb/s, + SATA 3.0 Gb/s, SATA 6.0 Gb/s speeds. It supports one SATA host + port to accept one SATA device. + endmenu diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index b57c253..0d03822 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -9,3 +9,4 @@ obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o +obj-$(CONFIG_PHY_EXYNOS5250_SATA) += phy-exynos5250-sata.o diff --git a/drivers/phy/phy-exynos5250-sata.c b/drivers/phy/phy-exynos5250-sata.c new file mode 100644 index 000..8ccd305 --- /dev/null +++ b/drivers/phy/phy-exynos5250-sata.c @@ -0,0 +1,251 @@ +/* + * Samsung SATA SerDes(PHY) driver + * + * Copyright (C) 2013 Samsung Electronics Co., Ltd. + * Authors: Girish K S + * Yuvaraj Kumar C D + * + * 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 +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define SATAPHY_CONTROL_OFFSET 0x0724 +#define EXYNOS5_SATAPHY_PMU_ENABLE BIT(0) +#define EXYNOS5_SATA_RESET 0x4 +#define RESET_GLOBAL_RST_N BIT(0) +#define RESET_CMN_RST_NBIT(1) +#define RESET_CMN_BLOCK_RST_N BIT(2) +#define RESET_CMN_I2C_RST_NBIT(3) +#define RESET_TX_RX_PIPE_RST_N BIT(4) +#define RESET_TX_RX_BLOCK_RST_NBIT(5) +#define RESET_TX_RX_I2C_RST_N (BIT(6) | BIT(7)) +#define LINK_RESET 0xf +#define EXYNOS5_SATA_MODE0 0x10 +#define SATA_SPD_GEN3 BIT(1) +#define EXYNOS5_SATA_CTRL0 0x14 +#define CTRL0_P0_PHY_CALIBRATED_SELBIT(9) +#define CTRL0_P0_PHY_CALIBRATEDBIT(8) +#define EXYNOS5_SATA_PHSATA_CTRLM 0xe0 +#define PHCTRLM_REF_RATE BIT(1) +#define PHCTRLM_HIGH_SPEED BIT(0) +#define EXYNOS5_SATA_PHSATA_STATM 0xf0 +#define PHSTATM_PLL_LOCKED BIT(0) + +#define PHY_PLL_TIMEOUT
[PATCH V9 0/2] Exynos5250 SATA Support
This patch series enable the SATA support on Exynos5250 based boards. It incorporates the generic phy framework to deal with sata phy. Yuvaraj Kumar C D (2): PHY: Exynos: Add Exynos5250 SATA PHY driver ARM: dts: Enable ahci sata and sata phy .../devicetree/bindings/ata/exynos-sata-phy.txt| 14 -- .../devicetree/bindings/ata/exynos-sata.txt| 25 +- .../devicetree/bindings/phy/samsung-phy.txt| 36 +++ arch/arm/boot/dts/exynos5250-arndale.dts | 21 ++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 17 +- arch/arm/boot/dts/exynos5250.dtsi | 18 +- drivers/phy/Kconfig| 15 ++ drivers/phy/Makefile |1 + drivers/phy/phy-exynos5250-sata.c | 251 9 files changed, 365 insertions(+), 33 deletions(-) delete mode 100644 Documentation/devicetree/bindings/ata/exynos-sata-phy.txt create mode 100644 drivers/phy/phy-exynos5250-sata.c -- 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/
Re: linux-next: manual merge of the bcm2835 tree with the arm-soc tree
On 03/02/2014 06:02 PM, Stephen Rothwell wrote:
> Hi Stephen,
>
> Today's linux-next merge of the bcm2835 tree got a conflict in
> arch/arm/mach-bcm2835/Kconfig between commits ddb902cc3459 ("ARM:
> centralize common multi-platform kconfig options") and
> 0676b21fffd1 ("ARM: bcm2835: enable V6K instead of plain V6") from
> the arm-soc tree and commit d30fe6272183 ("ARM: bcm2835: Move to
> mach-bcm directory") from the bcm2835 tree.
Olof, Arnd, Kevin,
Do you want me to rebase the patch that moves
arch/arm/mach-bcm2835/Kconfig into arch/arm/mach-bcm/Kconfig, or even
drop it and take it through arm-soc directly? Or, will you just handle
this when you merge the pull request?
--
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 mfd-lj tree
Hi Lee,
On Tue, 25 Feb 2014 14:32:46 +1100 Stephen Rothwell
wrote:
>
> On Thu, 20 Feb 2014 15:05:08 +1100 Stephen Rothwell
> wrote:
> >
> > On Mon, 17 Feb 2014 14:14:46 +1100 Stephen Rothwell
> > wrote:
> > >
> > > On Fri, 14 Feb 2014 13:42:17 +1100 Stephen Rothwell
> > > wrote:
> > > >
> > > > After merging the mfd-lj tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > >
> > > > In file included from drivers/mfd/max665x.c:19:0:
> > > > include/linux/mfd/max665x-private.h:31:1: error: expected ';',
> > > > identifier or '(' before 'struct'
> > > > struct max665x_dev {
> > > > ^
> > > >
> > > > Caused by commit e77bb5297293 ("mfd: max665x: Differentiate between
> > > > MAX665X devices"). Clearly never built by anyone :-(
> > > >
> > > > I have used the mfd-lj tree from next-20140210 again for today (since
> > > > the
> > > > other version had other problems).
> > >
> > > Still seeing this error.
> >
> > Still ...
>
> Ping ...
I am still seeing this error which means that I am still using the
version of your tree from next-20140210 i.e. Feb 10. It is a bit
disappointing that his has not been fixed in such a long time even though
there have been other updates to your tree which means that those other
changes have received no exposure in linux-next. It is a trivial error,
but it does indicate that noone ever build tested that particular commit.
(this is now commit 2fc7e7d25bee in your tree since it was rewritten but
not fixed on Feb 14.)
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpxXCyD3tdC1.pgp
Description: PGP signature
[PATCH] f2fs: fix to write node pages with WRITE_SYNC
This patch fixes performance regression of dbench reported by
Alex .
This issue was revealed by Phoronix tests results:
http://www.phoronix.com/scan.php?page=article=linux_314_ssdfs=2
It turns out that we need to assign WRITE_SYNC to the node writes, if
fsync is triggered.
The performance numbers are like below, which is measured by Alex.
1. 355MB/s ext4
2. 225MB/s f2fs : WRITE for node writes
3. 525MB/s f2fs : WRITE_SYNC for node writes
Reported-And-Tested-by: Alex .
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 00f937e..a4cc1d6 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -115,7 +115,7 @@ int f2fs_sync_file(struct file *file, loff_t start, loff_t
end, int datasync)
int ret = 0;
bool need_cp = false;
struct writeback_control wbc = {
- .sync_mode = WB_SYNC_NONE,
+ .sync_mode = WB_SYNC_ALL,
.nr_to_write = LONG_MAX,
.for_reclaim = 0,
};
--
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] mm: add pte_present() check on existing hugetlb_entry callbacks
Hi Sasha, > I can confirm that with this patch the lockdep issue is gone. However, the > NULL deref in > walk_pte_range() and the BUG at mm/hugemem.c:3580 still appear. I spotted the cause of this problem. Could you try testing if this patch fixes it? Thanks, Naoya --- Page table walker doesn't check non-present hugetlb entry in common path, so hugetlb_entry() callbacks must check it. The reason for this behavior is that some callers want to handle it in its own way. However, some callers don't check it now, which causes unpredictable result, for example when we have a race between migrating hugepage and reading /proc/pid/numa_maps. This patch fixes it by adding pte_present checks on buggy callbacks. This bug exists for long and got visible by introducing hugepage migration. Reported-by: Sasha Levin Signed-off-by: Naoya Horiguchi Cc: sta...@vger.kernel.org # 3.12+ --- fs/proc/task_mmu.c | 3 +++ mm/mempolicy.c | 6 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git next-20140228.orig/fs/proc/task_mmu.c next-20140228/fs/proc/task_mmu.c index 3746d89c768b..a4cecadce867 100644 --- next-20140228.orig/fs/proc/task_mmu.c +++ next-20140228/fs/proc/task_mmu.c @@ -1299,6 +1299,9 @@ static int gather_hugetlb_stats(pte_t *pte, unsigned long addr, if (pte_none(*pte)) return 0; + if (pte_present(*pte)) + return 0; + page = pte_page(*pte); if (!page) return 0; diff --git next-20140228.orig/mm/mempolicy.c next-20140228/mm/mempolicy.c index c0d1cbd68790..1e171186ee6d 100644 --- next-20140228.orig/mm/mempolicy.c +++ next-20140228/mm/mempolicy.c @@ -524,8 +524,12 @@ static int queue_pages_hugetlb(pte_t *pte, unsigned long addr, unsigned long flags = qp->flags; int nid; struct page *page; + pte_t entry; - page = pte_page(huge_ptep_get(pte)); + entry = huge_ptep_get(pte); + if (pte_present(entry)) + return 0; + page = pte_page(entry); nid = page_to_nid(page); if (node_isset(nid, *qp->nmask) == !!(flags & MPOL_MF_INVERT)) return 0; -- 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: [PATCHv3 1/3] ASoC: codec: Simplify ASoC probe code.
On Mon, Mar 03, 2014 at 10:42:22AM +0800, Xiubo Li wrote:
> static int ak4535_probe(struct snd_soc_codec *codec)
> {
> - struct ak4535_priv *ak4535 = snd_soc_codec_get_drvdata(codec);
> - int ret;
> -
> - codec->control_data = ak4535->regmap;
> - ret = snd_soc_codec_set_cache_io(codec, 8, 8, SND_SOC_REGMAP);
> - if (ret < 0) {
> - dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret);
> - return ret;
> - }
> /* power on device */
> ak4535_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
Are you sure that the set_bias_level() call doesn't do anything with
I/O? Can I suggest sending a patch that just does the drivers that only
do set_cache_io() and nothing else in probe - that would be really quick
and simple to fix.
> - ret = snd_soc_codec_set_cache_io(codec, 8, 8, SND_SOC_REGMAP);
> - if (ret < 0) {
> - dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret);
> - return ret;
> - }
> -
> /* Default to using ALC auto offset calibration mode. */
> snd_soc_update_bits(codec, DA7213_ALC_CTRL1,
> DA7213_ALC_CALIB_MODE_MAN, 0);
This one will fail.
signature.asc
Description: Digital signature
[patch] rt,blk,mq: Make blk_mq_cpu_notify_lock a raw spinlock
[ 365.164040] BUG: sleeping function called from invalid context at
kernel/rtmutex.c:674
[ 365.164041] in_atomic(): 1, irqs_disabled(): 1, pid: 26, name: migration/1
[ 365.164043] no locks held by migration/1/26.
[ 365.164044] irq event stamp: 6648
[ 365.164056] hardirqs last enabled at (6647): []
restore_args+0x0/0x30
[ 365.164062] hardirqs last disabled at (6648): []
multi_cpu_stop+0x9d/0x120
[ 365.164070] softirqs last enabled at (0): []
copy_process.part.28+0x6fc/0x1920
[ 365.164072] softirqs last disabled at (0): [< (null)>]
(null)
[ 365.164076] CPU: 1 PID: 26 Comm: migration/1 Tainted: GF N
3.12.12-rt19-0.gcb6c4a2-rt #3
[ 365.164078] Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS
QSSC-S4R.QCI.01.00.S013.032920111005 03/29/2011
[ 365.164091] 0001 880a42ea7c30 815367e6
81a086c0
[ 365.164099] 880a42ea7c40 8108919c 880a42ea7c60
8153c24f
[ 365.164107] 880a42ea91f0 ffe1 880a42ea7c88
81297ec0
[ 365.164108] Call Trace:
[ 365.164119] [] try_stack_unwind+0x191/0x1a0
[ 365.164127] [] dump_trace+0x92/0x360
[ 365.164133] [] show_trace_log_lvl+0x48/0x60
[ 365.164138] [] show_stack_log_lvl+0xd8/0x1d0
[ 365.164143] [] show_stack+0x20/0x50
[ 365.164153] [] dump_stack+0x54/0x9a
[ 365.164163] [] __might_sleep+0xfc/0x140
[ 365.164173] [] rt_spin_lock+0x1f/0x70
[ 365.164182] [] blk_mq_main_cpu_notify+0x20/0x70
[ 365.164191] [] notifier_call_chain+0x4c/0x70
[ 365.164201] [] __raw_notifier_call_chain+0x9/0x10
[ 365.164207] [] cpu_notify+0x1e/0x40
[ 365.164217] [] take_cpu_down+0x22/0x40
[ 365.164223] [] multi_cpu_stop+0xd6/0x120
[ 365.164229] [] cpu_stopper_thread+0xd7/0x1e0
[ 365.164235] [] smpboot_thread_fn+0x203/0x380
[ 365.164241] [] kthread+0xc8/0xd0
[ 365.164250] [] ret_from_fork+0x7c/0xb0
[ 365.164429] smpboot: CPU 1 is now offline
Signed-off-by: Mike Galbraith
---
block/blk-mq-cpu.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/block/blk-mq-cpu.c
+++ b/block/blk-mq-cpu.c
@@ -11,7 +11,7 @@
#include "blk-mq.h"
static LIST_HEAD(blk_mq_cpu_notify_list);
-static DEFINE_SPINLOCK(blk_mq_cpu_notify_lock);
+static DEFINE_RAW_SPINLOCK(blk_mq_cpu_notify_lock);
static int blk_mq_main_cpu_notify(struct notifier_block *self,
unsigned long action, void *hcpu)
@@ -19,12 +19,12 @@ static int blk_mq_main_cpu_notify(struct
unsigned int cpu = (unsigned long) hcpu;
struct blk_mq_cpu_notifier *notify;
- spin_lock(_mq_cpu_notify_lock);
+ raw_spin_lock(_mq_cpu_notify_lock);
list_for_each_entry(notify, _mq_cpu_notify_list, list)
notify->notify(notify->data, action, cpu);
- spin_unlock(_mq_cpu_notify_lock);
+ raw_spin_unlock(_mq_cpu_notify_lock);
return NOTIFY_OK;
}
@@ -32,16 +32,16 @@ void blk_mq_register_cpu_notifier(struct
{
BUG_ON(!notifier->notify);
- spin_lock(_mq_cpu_notify_lock);
+ raw_spin_lock(_mq_cpu_notify_lock);
list_add_tail(>list, _mq_cpu_notify_list);
- spin_unlock(_mq_cpu_notify_lock);
+ raw_spin_unlock(_mq_cpu_notify_lock);
}
void blk_mq_unregister_cpu_notifier(struct blk_mq_cpu_notifier *notifier)
{
- spin_lock(_mq_cpu_notify_lock);
+ raw_spin_lock(_mq_cpu_notify_lock);
list_del(>list);
- spin_unlock(_mq_cpu_notify_lock);
+ raw_spin_unlock(_mq_cpu_notify_lock);
}
void blk_mq_init_cpu_notifier(struct blk_mq_cpu_notifier *notifier,
--
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: [PATCHv2 1/3] ASoC: codec: Simplify ASoC probe code.
On Mon, Mar 03, 2014 at 03:01:52AM +, li.xi...@freescale.com wrote: > I think we should move the set_cache_io() calling more earlier as we discussed > before, but need much more research and testing. Splitting them into another > separate patch later will be much better and easier to be reviewed. Yes, exactly - do the simple, boring cases first and then anything that needs thought separately. signature.asc Description: Digital signature
[GIT PULL] clk: fixes for 3.14
The following changes since commit cfbf8d4857c26a8a307fb7cd258074c9dcd8c691:
Linux 3.14-rc4 (2014-02-23 17:40:03 -0800)
are available in the git repository at:
git://git.linaro.org/people/mike.turquette/linux.git tags/clk-fixes-for-linus
for you to fetch changes up to f63fcc90a379a269a07af5b7ba28ebcb1eb4:
clk:at91: Fix memory leak in of_at91_clk_master_setup() (2014-02-26 18:00:56
-0800)
Clock framework and driver fixes, all of which fix user-visible
regressions. There is a single framework fix that prevents dereferencing
a NULL pointer when calling clk_get. The range of fixes for clock driver
regressions spans memory leak fixes, touching the wrong registers that
cause things to explode, misconfigured clock rates that result in
non-responsive devices and even some boot failures. The most benign fix
is DT binding doc typo. It is a stable ABI exposed from the kernel that
was introduced in -rc1, so best to fix it now.
Andrew Bresticker (3):
clk: tegra: fix sdmmc clks on Tegra1x4
clk: tegra: cclk_lp has a pllx/2 divider
clk: tegra: use max divider if divider overflows
David Ung (1):
clk: tegra: PLLD2 fixes for hdmi
Gabe Black (1):
clk: tegra: Fix PLLP rate table
Ivan Khoronzhuk (2):
clk: keystone: gate: fix clk_init_data initialization
ARM: keystone: dts: fix clkvcp3 control register address
Laurent Pinchart (5):
clk: shmobile: rcar-gen2: Fix clock parent all non-PLL clocks
clk: shmobile: rcar-gen2: Fix qspi divisor
clk: shmobile: rcar-gen2: Fix clock parent for all non-PLL clocks
clk: shmobile: rcar-gen2: Fix qspi divisor
clk: shmobile: Fix typo in MSTP clock DT bindings
Linus Walleij (1):
clk: nomadik: fix multiplatform problem
Mark Zhang (1):
clk: tegra: fix host1x clock on Tegra124
Masanari Iida (1):
clk:at91: Fix memory leak in of_at91_clk_master_setup()
Mike Turquette (4):
Merge tag 'mvebu-clk-fixes-3.14' of git://git.infradead.org/linux-mvebu
into clk-fixes
Merge branch 'for_3.14-rcx/clk-fixes' of
git://git.kernel.org/.../ssantosh/linux-keystone into clk-fixes
Merge branch 'clk-tegra-more-fixes-3.14' of
git://nv-tegra.nvidia.com/user/pdeschrijver/linux into clk-fixes
Merge branch 'clocks/fixes/drivers' of git://linuxtv.org/pinchartl/fbdev
into clk-fixes
Peter De Schrijver (3):
clk: tegra: Add missing Tegra20 fuse clks
clk: tegra: Fix vic03 mux index
clk: tegra124: remove gr2d and gr3d clocks
Rhyland Klein (1):
clk: tegra: Fix PLLD mnp table
Sebastian Hesselbarth (4):
clk: mvebu: armada-370: maintain clock init order
clk: mvebu: armada-xp: maintain clock init order
clk: mvebu: dove: maintain clock init order
clk: mvebu: kirkwood: maintain clock init order
Sylwester Nawrocki (1):
clk: Correct handling of NULL clk in __clk_{get, put}
Thierry Reding (1):
clk: tegra: Correct clock number for UARTE
.../bindings/clock/renesas,cpg-mstp-clocks.txt | 4 +-
arch/arm/boot/dts/keystone-clocks.dtsi | 2 +-
drivers/clk/at91/clk-master.c | 2 +-
drivers/clk/clk-nomadik.c | 3 ++
drivers/clk/clk.c | 13 +++---
drivers/clk/keystone/gate.c| 1 +
drivers/clk/mvebu/armada-370.c | 21 +-
drivers/clk/mvebu/armada-xp.c | 20 -
drivers/clk/mvebu/dove.c | 19 -
drivers/clk/mvebu/kirkwood.c | 34 ---
drivers/clk/shmobile/clk-rcar-gen2.c | 12 +-
drivers/clk/tegra/clk-divider.c| 2 +-
drivers/clk/tegra/clk-id.h | 4 ++
drivers/clk/tegra/clk-tegra-periph.c | 10 +++--
drivers/clk/tegra/clk-tegra-super-gen4.c | 2 +-
drivers/clk/tegra/clk-tegra114.c | 8 ++--
drivers/clk/tegra/clk-tegra124.c | 48 --
drivers/clk/tegra/clk-tegra20.c| 2 +
include/dt-bindings/clock/tegra124-car.h | 4 +-
19 files changed, 116 insertions(+), 95 deletions(-)
--
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 29/44] arc: Use translate_signal()
Hi Richard, Thanks for this. On Monday 03 March 2014 07:59 AM, Richard Weinberger wrote: > Use the common helper instead of it's own variant. > > Signed-off-by: Richard Weinberger Acked-by: Vineet Gupta [arch/arc bits] -Vineet -- 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, Mar 02, 2014 at 11:44:52PM +, Peter Sewell wrote:
> On 2 March 2014 23:20, Paul E. McKenney wrote:
> > On Sun, Mar 02, 2014 at 04:05:52AM -0600, Peter Sewell wrote:
> >> On 1 March 2014 08:03, Paul E. McKenney wrote:
> >> > On Sat, Mar 01, 2014 at 04:06:34AM -0600, Peter Sewell wrote:
> >> >> Hi Paul,
> >> >>
> >> >> On 28 February 2014 18:50, Paul E. McKenney
> >> >> wrote:
> >> >> > On Thu, Feb 27, 2014 at 12:53:12PM -0800, Paul E. McKenney wrote:
> >> >> >> On Thu, Feb 27, 2014 at 11:47:08AM -0800, Linus Torvalds wrote:
> >> >> >> > On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney
> >> >> >> > wrote:
> >> >> >> > >
> >> >> >> > > 3. The comparison was against another RCU-protected pointer,
> >> >> >> > > where that other pointer was properly fetched using one
> >> >> >> > > of the RCU primitives. Here it doesn't matter which
> >> >> >> > > pointer
> >> >> >> > > you use. At least as long as the rcu_assign_pointer()
> >> >> >> > > for
> >> >> >> > > that other pointer happened after the last update to the
> >> >> >> > > pointed-to structure.
> >> >> >> > >
> >> >> >> > > I am a bit nervous about #3. Any thoughts on it?
> >> >> >> >
> >> >> >> > I think that it might be worth pointing out as an example, and
> >> >> >> > saying
> >> >> >> > that code like
> >> >> >> >
> >> >> >> >p = atomic_read(consume);
> >> >> >> >X;
> >> >> >> >q = atomic_read(consume);
> >> >> >> >Y;
> >> >> >> >if (p == q)
> >> >> >> > data = p->val;
> >> >> >> >
> >> >> >> > then the access of "p->val" is constrained to be data-dependent on
> >> >> >> > *either* p or q, but you can't really tell which, since the
> >> >> >> > compiler
> >> >> >> > can decide that the values are interchangeable.
> >> >> >> >
> >> >> >> > I cannot for the life of me come up with a situation where this
> >> >> >> > would
> >> >> >> > matter, though. If "X" contains a fence, then that fence will be a
> >> >> >> > stronger ordering than anything the consume through "p" would
> >> >> >> > guarantee anyway. And if "X" does *not* contain a fence, then the
> >> >> >> > atomic reads of p and q are unordered *anyway*, so then whether the
> >> >> >> > ordering to the access through "p" is through p or q is kind of
> >> >> >> > irrelevant. No?
> >> >> >>
> >> >> >> I can make a contrived litmus test for it, but you are right, the
> >> >> >> only
> >> >> >> time you can see it happen is when X has no barriers, in which case
> >> >> >> you don't have any ordering anyway -- both the compiler and the CPU
> >> >> >> can
> >> >> >> reorder the loads into p and q, and the read from p->val can, as you
> >> >> >> say,
> >> >> >> come from either pointer.
> >> >> >>
> >> >> >> For whatever it is worth, hear is the litmus test:
> >> >> >>
> >> >> >> T1: p = kmalloc(...);
> >> >> >> if (p == NULL)
> >> >> >> deal_with_it();
> >> >> >> p->a = 42; /* Each field in its own cache line. */
> >> >> >> p->b = 43;
> >> >> >> p->c = 44;
> >> >> >> atomic_store_explicit(, p, memory_order_release);
> >> >> >> p->b = 143;
> >> >> >> p->c = 144;
> >> >> >> atomic_store_explicit(, p, memory_order_release);
> >> >> >>
> >> >> >> T2: p = atomic_load_explicit(, memory_order_consume);
> >> >> >> r1 = p->b; /* Guaranteed to get 143. */
> >> >> >> q = atomic_load_explicit(, memory_order_consume);
> >> >> >> if (p == q) {
> >> >> >> /* The compiler decides that q->c is same as p->c. */
> >> >> >> r2 = p->c; /* Could get 44 on weakly order system. */
> >> >> >> }
> >> >> >>
> >> >> >> The loads from gp1 and gp2 are, as you say, unordered, so you get
> >> >> >> what
> >> >> >> you get.
> >> >> >>
> >> >> >> And publishing a structure via one RCU-protected pointer, updating
> >> >> >> it,
> >> >> >> then publishing it via another pointer seems to me to be asking for
> >> >> >> trouble anyway. If you really want to do something like that and
> >> >> >> still
> >> >> >> see consistency across all the fields in the structure, please put a
> >> >> >> lock
> >> >> >> in the structure and use it to guard updates and accesses to those
> >> >> >> fields.
> >> >> >
> >> >> > And here is a patch documenting the restrictions for the current Linux
> >> >> > kernel. The rules change a bit due to rcu_dereference() acting a bit
> >> >> > differently than atomic_load_explicit(, memory_order_consume).
> >> >> >
> >> >> > Thoughts?
> >> >>
> >> >> That might serve as informal documentation for linux kernel
> >> >> programmers about the bounds on the optimisations that you expect
> >> >> compilers to do for common-case RCU code - and I guess that's what you
> >> >> intend it to be for. But I don't see how one can make it precise
> >> >> enough to serve as a language definition, so that compiler people
> >> >> could confidently say "yes, we respect that", which I guess is what
> >> >> you
Re: A Bug Inquiry in linux/tools/perf/builtin-record.c
于 2014/2/27 10:53, xiakaixu 写道:
> Hi Namhyung,
>
> 于 2014/2/26 16:03, Namhyung Kim 写道:
>> Hi xiakaixu,
>>
>>> 于 2014/2/19 9:48, xiakaixu 写道:
Hi all,
There is a bug found in my work when running "perf record". The basic
information
is here. As we know, perf record is a parent process and the programme
traced is
a child process when running "perf record". Sometimes the child process
become
zombie state and disappear until the parent process is killed. The bug
stays in linux/
tools/perf/builtin-record.c.
*
static int __cmd_record(struct perf_record *rec, int argc, const char
**argv)
..
if (hits == rec->samples) {
if (done)
break;
err = poll(evsel_list->pollfd,
evsel_list->nr_fds, -1);
waking++;
}
..
*
The parent process still call the function
poll(evsel_list->pollfd, evsel_list->nr_fds, -1) when the child process
has exited
already, which caused a zombie process.
May I have your opinion ?
Waiting for your reply!
>>
>> Do you have a real bug report based on this?
> yeah, of course we have it, I'll be glad to provide it if necessary.
>>
>> AFAIK perf record installed a signal handler for SIGCHLD so it'll set
>> the 'done' variable when child exits and then break the loop.
> yes, you are right. Though the 'done' varible will be set when child exits,
> there is time gap between "if(done)" statement and "poll(...)" function.
> The 'done' variable won't be judge when child exits in this time gap.
> You know this time gap is instruction level, so this bug is small probability.
> My solution is adding a while(...) statement outside poll(...) function.
>>
>> 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] regulator: tps65217: Allow missing init_data for diagnostics
On Fri, Feb 21, 2014 at 09:42:23PM +0800, Axel Lin wrote: > The regulator core supports this to allow the configuration to be inspected > at runtime even if no software management is enabled. Applied, thanks. signature.asc Description: Digital signature
Re: [RFC PATCH 3/6] PM / Voltagedomain: introduce voltage domain driver support
On Mon, Feb 24, 2014 at 08:38:07AM -0600, Nishanth Menon wrote: > Intent here is to allow drivers such as cpufreq-cpu0 to be reused on > platforms such as TI's OMAP derivatives, and other SoCs which differ > only by the sequence involved in voltage scale operations. So, this > patch provides a framework for registering the underlying > implementation of the SoC specific voltage change methodology. That bit is clear, what's very opaque from the code is how this is going to be accomplished. > Overall the sequence takes place after this patch is as follows: > a) voltage domain drivers such as those of TI or others register with > voltage domain with devm_voltdm_register. > b) cpufreq-cpu0/devfreq drivers: > of_pm_voltdm_notifier_register(introduced as part of patch #1) to > register notifiers around clk of interest. This request is linked to > the specific voltage domain using phandle in device tree. > c) when cpufreq-cpu0/devfreq does a clk_set_rate, the common clock > framework triggers notifiers in voltage domain core which in turn, > invokes the corresponding handlers for the voltage domain driver > ensuring the right dvfs sequence specific to the SoC is triggered. So the first question I have here is what happens if multiple clocks need to be updated in lock step - if we're only triggering off clock notifiers that seems tricky. The other thing here is that the fact that your API is "of_" suggests that it is in fact linked very srongly to DT - it'd be good to split out the layers to make sure things make sense standalone, the DT helpers are obviously good but the API should be able to stand separately. signature.asc Description: Digital signature
Re: [PATCH] x86, make check_irq_vectors_for_cpu_disable() aware of numa node irqs
On Tue, Feb 25, 2014 at 09:04:21AM -0500, Prarit Bhargava wrote:
> This patch explicitly depends on Yinghai's patch, [PATCH v3] x86, irq: get
> correct available vectors for cpu disable, which was last posted here:
>
> http://marc.info/?l=linux-kernel=139094603622814=2
>
> and is not yet in any tree AFAICT.
>
> P.
>
Sounds reasonable to me. Just a nitpick.
Acked-by: Gong Chen
[...]
> + if (cpumask_empty(_new)) {
> + pr_warn("CPU %d disable failed: IRQ %u has no availble
> CPUS to transition IRQ.\n",
These words looks not fluent to native speaker. (but I'm not native
speaker, too ;-))
signature.asc
Description: Digital signature
Re: [PATCH] md / procfs: avoid Oops if md-mod removed while /proc/mdstat is being polled.
On Thu, 27 Feb 2014 15:32:42 -0800 Andrew Morton wrote: > On Fri, 28 Feb 2014 10:07:57 +1100 NeilBrown wrote: > > > On Thu, 27 Feb 2014 13:51:25 -0800 Andrew Morton > > wrote: > > > > > On Fri, 28 Feb 2014 08:34:43 +1100 NeilBrown wrote: > > > > > > > On Thu, 27 Feb 2014 12:58:07 -0800 Andrew Morton > > > > > > > > wrote: > > > > > > > > > On Thu, 27 Feb 2014 17:24:45 +1100 NeilBrown wrote: > > > > > > > > > > > If poll or select is waiting on /proc/mdstat when md-mod is unloaded > > > > > > an oops will ensure when the poll/select completes. > > > > > > > > > > > > This is because the wait_queue_head which is registered with > > > > > > poll_wait() > > > > > > is local to the module and no longer exists when the poll completes > > > > > > and > > > > > > detaches that wait_queue_head (in poll_free_wait -> > > > > > > remove_wait_queue). > > > > > > > > > > > > To fix this we need the wait_queue_head to have (at least) the same > > > > > > life > > > > > > time as the proc_dir_entry. So this patch places it in that > > > > > > structure. > > > > > > > > > > > > We: > > > > > > - add pde_poll_wait to struct proc_dir_entry > > > > > > - call poll_wait() passing this when poll() is called on the proc > > > > > > file > > > > > > - export a function proc_wake_up which will call wake_up() on > > > > > > pde_poll_wait > > > > > > > > > > > > and make use of all that in md.c > > > > > > > > > > This sounds wrong. If a userspace process is waiting on > > > > > md_event_waiters then the md module is "busy" and the rmmod attempt > > > > > should fail? > > > > > > > > Al Viro says "no" quite firmly. > > > > > > > > I think the core argument is that > > > > > > > > rmmod md-mod < /proc/mdstat > > > > > > > > would deadlock. > > > > > > Well, only if the rmmod hangs around waiting for the module to go idle. > > > I'm thinking rmmod should fail. EBUSY. > > This? What happens if we just fail the rmmod when the module is busy > (which it is). I was hoping that Al would step in with an answer, but I got impatient had had a look around myself. I found commit 99b76233803beab302123d243eea9e41149804f3 Author: Alexey Dobriyan Date: Wed Mar 25 22:48:06 2009 +0300 proc 2/2: remove struct proc_dir_entry::owner which references https://bugzilla.kernel.org/show_bug.cgi?id=12454 which seems to suggest that we used to try to do as you suggest but it was racy and would be a lot of work to "fix". The chosen solution was to only 'get' the module during read/write, not just while the /proc file is open. NeilBrown signature.asc Description: PGP signature
Re: [PATCH] ARM: tegra: add device tree for SHIELD
On 03/03/2014 12:49 PM, Alexandre Courbot wrote: Add a device tree for NVIDIA SHIELD. The set of enabled features is still minimal with no display option and USB requiring external power. A default kernel command-line as well as initrd addresses are hardcoded to match the static values the bootloader is known to use. This allows booting from an appended DTB without having to alter it at boot time, since the bootloader has no Device Tree support. Signed-off-by: Alexandre Courbot --- Forgot to specify this is a v2, apologies for the inconvenience. Changes since v1: - Comment on the memory range - Removed nodes for currently unsupported hardware (i.e. wifi) -- 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] ARM: tegra: add device tree for Tegra Note 7
Add a device tree for Tegra Note 7. The set of enabled features is
still minimal with no display option and USB requiring external power.
Pinctrl is not set yet, as the bootloader-provided values allow us to
use the currently-supported hardware.
A default kernel command-line as well as initrd addresses are hardcoded
to match the static values the bootloader is known to use. This allows
booting from an appended DTB without having to alter it at boot time,
since the bootloader has no Device Tree support.
Signed-off-by: Alexandre Courbot
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/tegra114-tn7.dts | 278 +
2 files changed, 279 insertions(+)
create mode 100644 arch/arm/boot/dts/tegra114-tn7.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 27ca6fd664d0..77829a8aa615 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -357,6 +357,7 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
tegra30-cardhu-a04.dtb \
tegra114-dalmore.dtb \
tegra114-roth.dtb \
+ tegra114-tn7.dtb \
tegra124-venice2.dtb
dtb-$(CONFIG_ARCH_VERSATILE) += versatile-ab.dtb \
versatile-pb.dtb
diff --git a/arch/arm/boot/dts/tegra114-tn7.dts
b/arch/arm/boot/dts/tegra114-tn7.dts
new file mode 100644
index ..185759dc3f7f
--- /dev/null
+++ b/arch/arm/boot/dts/tegra114-tn7.dts
@@ -0,0 +1,278 @@
+/dts-v1/;
+
+#include "tegra114.dtsi"
+
+/ {
+ model = "Tegra Note 7";
+ compatible = "nvidia,tn7", "nvidia,tegra114";
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 console=tty1 gpt cma=128M
fbcon=rotate:2";
+ linux,initrd-start = <0x8200>;
+ linux,initrd-end = <0x8280>;
+ };
+
+ firmware {
+ trusted-foundations {
+ compatible = "tlm,trusted-foundations";
+ tlm,version-major = <2>;
+ tlm,version-minor = <8>;
+ };
+ };
+
+ memory {
+ /* memory >= 0x37e0 is reserved for firmware usage */
+ reg = <0x8000 0x37e0>;
+ };
+
+ serial@70006300 {
+ status = "okay";
+ };
+
+ pwm@7000a000 {
+ status = "okay";
+ };
+
+ i2c@7000d000 {
+ status = "okay";
+ clock-frequency = <40>;
+
+ palmas: pmic@58 {
+ compatible = "ti,palmas";
+ reg = <0x58>;
+ interrupts = <0 86 IRQ_TYPE_LEVEL_HIGH>;
+ ti,irq-externally-inverted;
+
+ #interrupt-cells = <2>;
+ interrupt-controller;
+
+ palmas_gpio: gpio {
+ compatible = "ti,palmas-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ pmic {
+ compatible = "ti,tps65913-pmic",
"ti,palmas-pmic";
+
+ regulators {
+ smps123 {
+ regulator-name = "vd-cpu";
+ regulator-min-microvolt =
<100>;
+ regulator-max-microvolt =
<100>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ smps45 {
+ regulator-name = "vd-soc";
+ regulator-min-microvolt =
<110>;
+ regulator-max-microvolt =
<110>;
+ regulator-always-on;
+ };
+
+ smps6 {
+ regulator-name = "va-lcd-hv";
+ regulator-min-microvolt =
<300>;
+ regulator-max-microvolt =
<300>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ smps7 {
+ regulator-name = "vd-ddr";
+ regulator-min-microvolt =
<135>;
+ regulator-max-microvolt =
<135>;
+ regulator-boot-on;
+ regulator-always-on;
+
[PATCHv3 2/3] ASoC: io: New signature for snd_soc_codec_set_cache_io()
Now that all users have been converted to regmap and the config.reg_bits
and config.val_bits can be setted by each user through regmap core API.
So these two params are redundant here.
Since the only control type that left is SND_SOC_REGMAP, so remove it. Drop
the control params and add struct regmap *regmap to simplify the code.
Signed-off-by: Xiubo Li
---
include/sound/soc.h| 7 +--
sound/soc/codecs/cq93vc.c | 3 +--
sound/soc/codecs/mc13783.c | 4 ++--
sound/soc/codecs/tlv320dac33.c | 1 -
sound/soc/codecs/wm5102.c | 4 +---
sound/soc/codecs/wm5110.c | 3 +--
sound/soc/codecs/wm8350.c | 4 +---
sound/soc/codecs/wm8400.c | 3 +--
sound/soc/codecs/wm8994.c | 3 +--
sound/soc/codecs/wm8997.c | 4 +---
sound/soc/soc-core.c | 2 +-
sound/soc/soc-io.c | 47 ++
12 files changed, 31 insertions(+), 54 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index ecfb334..4c4d7e1 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -354,10 +354,6 @@ typedef int (*hw_write_t)(void *,const char* ,int);
extern struct snd_ac97_bus_ops *soc_ac97_ops;
-enum snd_soc_control_type {
- SND_SOC_REGMAP,
-};
-
enum snd_soc_pcm_subclass {
SND_SOC_PCM_CLASS_PCM = 0,
SND_SOC_PCM_CLASS_BE= 1,
@@ -404,8 +400,7 @@ int snd_soc_codec_readable_register(struct snd_soc_codec
*codec,
int snd_soc_codec_writable_register(struct snd_soc_codec *codec,
unsigned int reg);
int snd_soc_codec_set_cache_io(struct snd_soc_codec *codec,
- int addr_bits, int data_bits,
- enum snd_soc_control_type control);
+ struct regmap *regmap);
int snd_soc_cache_sync(struct snd_soc_codec *codec);
int snd_soc_cache_init(struct snd_soc_codec *codec);
int snd_soc_cache_exit(struct snd_soc_codec *codec);
diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c
index 43737a27..1e25c7a 100644
--- a/sound/soc/codecs/cq93vc.c
+++ b/sound/soc/codecs/cq93vc.c
@@ -138,9 +138,8 @@ static int cq93vc_probe(struct snd_soc_codec *codec)
struct davinci_vc *davinci_vc = codec->dev->platform_data;
davinci_vc->cq93vc.codec = codec;
- codec->control_data = davinci_vc->regmap;
- snd_soc_codec_set_cache_io(codec, 32, 32, SND_SOC_REGMAP);
+ snd_soc_codec_set_cache_io(codec, davinci_vc->regmap);
/* Off, with power on */
cq93vc_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
diff --git a/sound/soc/codecs/mc13783.c b/sound/soc/codecs/mc13783.c
index c605036..3331cc7 100644
--- a/sound/soc/codecs/mc13783.c
+++ b/sound/soc/codecs/mc13783.c
@@ -614,8 +614,8 @@ static int mc13783_probe(struct snd_soc_codec *codec)
struct mc13783_priv *priv = snd_soc_codec_get_drvdata(codec);
int ret;
- codec->control_data = dev_get_regmap(codec->dev->parent, NULL);
- ret = snd_soc_codec_set_cache_io(codec, 8, 24, SND_SOC_REGMAP);
+ ret = snd_soc_codec_set_cache_io(codec,
+ dev_get_regmap(codec->dev->parent, NULL));
if (ret != 0) {
dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret);
return ret;
diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c
index 9ce8496..30d8596 100644
--- a/sound/soc/codecs/tlv320dac33.c
+++ b/sound/soc/codecs/tlv320dac33.c
@@ -122,7 +122,6 @@ struct tlv320dac33_priv {
unsigned int uthr;
enum dac33_state state;
- enum snd_soc_control_type control_type;
void *control_data;
};
diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c
index 293dffc..01b6ee4 100644
--- a/sound/soc/codecs/wm5102.c
+++ b/sound/soc/codecs/wm5102.c
@@ -1760,9 +1760,7 @@ static int wm5102_codec_probe(struct snd_soc_codec *codec)
struct wm5102_priv *priv = snd_soc_codec_get_drvdata(codec);
int ret;
- codec->control_data = priv->core.arizona->regmap;
-
- ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP);
+ ret = snd_soc_codec_set_cache_io(codec, priv->core.arizona->regmap);
if (ret != 0)
return ret;
diff --git a/sound/soc/codecs/wm5110.c b/sound/soc/codecs/wm5110.c
index 4de2bf1..cf5d828f 100644
--- a/sound/soc/codecs/wm5110.c
+++ b/sound/soc/codecs/wm5110.c
@@ -1587,10 +1587,9 @@ static int wm5110_codec_probe(struct snd_soc_codec
*codec)
struct wm5110_priv *priv = snd_soc_codec_get_drvdata(codec);
int ret;
- codec->control_data = priv->core.arizona->regmap;
priv->core.arizona->dapm = >dapm;
- ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP);
+ ret = snd_soc_codec_set_cache_io(codec, priv->core.arizona->regmap);
if (ret != 0)
return ret;
diff --git a/sound/soc/codecs/wm8350.c b/sound/soc/codecs/wm8350.c
index
[PATCHv3 1/3] ASoC: codec: Simplify ASoC probe code.
For some CODEC drivers like who act as the MFDs children are ignored
by this patch.
Signed-off-by: Xiubo Li
---
sound/soc/codecs/ad193x.c| 10 +-
sound/soc/codecs/adau1373.c | 7 ---
sound/soc/codecs/adav80x.c | 7 ---
sound/soc/codecs/ak4535.c| 9 -
sound/soc/codecs/ak4641.c| 8
sound/soc/codecs/ak4642.c| 8
sound/soc/codecs/ak4671.c| 12 +---
sound/soc/codecs/alc5623.c | 7 ---
sound/soc/codecs/alc5632.c | 8
sound/soc/codecs/cs4270.c| 9 -
sound/soc/codecs/cs42l51.c | 6 --
sound/soc/codecs/cs42l52.c | 9 +
sound/soc/codecs/cs42l73.c | 11 +--
sound/soc/codecs/da7210.c| 8
sound/soc/codecs/da7213.c| 8
sound/soc/codecs/da732x.c| 13 ++---
sound/soc/codecs/da9055.c| 8
sound/soc/codecs/isabelle.c | 16
sound/soc/codecs/lm49453.c | 17 -
sound/soc/codecs/max9768.c | 5 -
sound/soc/codecs/max98088.c | 6 --
sound/soc/codecs/max98090.c | 8
sound/soc/codecs/max98095.c | 6 --
sound/soc/codecs/max9850.c | 8
sound/soc/codecs/ml26124.c | 10 --
sound/soc/codecs/rt5631.c| 9 -
sound/soc/codecs/rt5640.c| 8
sound/soc/codecs/sn95031.c | 2 --
sound/soc/codecs/ssm2518.c | 10 --
sound/soc/codecs/ssm2602.c | 7 ---
sound/soc/codecs/sta32x.c| 14 --
sound/soc/codecs/sta529.c| 10 --
sound/soc/codecs/tlv320aic23.c | 8
sound/soc/codecs/tlv320aic26.c | 2 --
sound/soc/codecs/tlv320aic32x4.c | 2 --
sound/soc/codecs/tlv320aic3x.c | 6 --
sound/soc/codecs/wm2000.c| 2 --
sound/soc/codecs/wm2200.c| 7 ---
sound/soc/codecs/wm5100.c| 7 ---
sound/soc/codecs/wm8510.c| 10 +-
sound/soc/codecs/wm8523.c| 7 ---
sound/soc/codecs/wm8580.c| 6 --
sound/soc/codecs/wm8711.c| 6 --
sound/soc/codecs/wm8728.c| 11 +--
sound/soc/codecs/wm8731.c| 7 ---
sound/soc/codecs/wm8737.c| 6 --
sound/soc/codecs/wm8741.c| 6 --
sound/soc/codecs/wm8750.c| 6 --
sound/soc/codecs/wm8753.c| 7 ---
sound/soc/codecs/wm8770.c| 6 --
sound/soc/codecs/wm8776.c| 6 --
sound/soc/codecs/wm8804.c| 8
sound/soc/codecs/wm8900.c| 8 +---
sound/soc/codecs/wm8903.c| 10 +-
sound/soc/codecs/wm8904.c| 9 -
sound/soc/codecs/wm8940.c| 6 --
sound/soc/codecs/wm8955.c| 8
sound/soc/codecs/wm8960.c| 6 --
sound/soc/codecs/wm8961.c| 7 ---
sound/soc/codecs/wm8962.c| 7 ---
sound/soc/codecs/wm8971.c| 6 --
sound/soc/codecs/wm8974.c| 6 --
sound/soc/codecs/wm8978.c| 8 +---
sound/soc/codecs/wm8983.c| 6 --
sound/soc/codecs/wm8985.c| 7 ---
sound/soc/codecs/wm8988.c| 8
sound/soc/codecs/wm8990.c| 8
sound/soc/codecs/wm8991.c| 8
sound/soc/codecs/wm8993.c| 7 ---
sound/soc/codecs/wm8995.c| 7 ---
sound/soc/codecs/wm8996.c| 12 +---
sound/soc/codecs/wm9081.c| 11 +--
sound/soc/codecs/wm9090.c| 10 --
73 files changed, 13 insertions(+), 562 deletions(-)
diff --git a/sound/soc/codecs/ad193x.c b/sound/soc/codecs/ad193x.c
index 9381a76..6844d0b 100644
--- a/sound/soc/codecs/ad193x.c
+++ b/sound/soc/codecs/ad193x.c
@@ -322,14 +322,6 @@ static struct snd_soc_dai_driver ad193x_dai = {
static int ad193x_codec_probe(struct snd_soc_codec *codec)
{
struct ad193x_priv *ad193x = snd_soc_codec_get_drvdata(codec);
- int ret;
-
- codec->control_data = ad193x->regmap;
- ret = snd_soc_codec_set_cache_io(codec, 0, 0, SND_SOC_REGMAP);
- if (ret < 0) {
- dev_err(codec->dev, "failed to set cache I/O: %d\n", ret);
- return ret;
- }
/* default setting for ad193x */
@@ -347,7 +339,7 @@ static int ad193x_codec_probe(struct snd_soc_codec *codec)
regmap_write(ad193x->regmap, AD193X_PLL_CLK_CTRL0, 0x99); /*
mclk=24.576Mhz: 0x9D; mclk=12.288Mhz: 0x99 */
regmap_write(ad193x->regmap, AD193X_PLL_CLK_CTRL1, 0x04);
- return ret;
+ return 0;
}
static struct snd_soc_codec_driver soc_codec_dev_ad193x = {
diff --git a/sound/soc/codecs/adau1373.c b/sound/soc/codecs/adau1373.c
index 5765c22..97f610a 100644
--- a/sound/soc/codecs/adau1373.c
+++ b/sound/soc/codecs/adau1373.c
@@ -1376,15 +1376,8 @@ static int adau1373_probe(struct snd_soc_codec *codec)
struct adau1373_platform_data
[PATCH] ARM: tegra: add device tree for SHIELD
Add a device tree for NVIDIA SHIELD. The set of enabled features is
still minimal with no display option and USB requiring external power.
A default kernel command-line as well as initrd addresses are hardcoded
to match the static values the bootloader is known to use. This allows
booting from an appended DTB without having to alter it at boot time,
since the bootloader has no Device Tree support.
Signed-off-by: Alexandre Courbot
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/tegra114-roth.dts | 1069 +++
2 files changed, 1070 insertions(+)
create mode 100644 arch/arm/boot/dts/tegra114-roth.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c98f343b47ca..27ca6fd664d0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -356,6 +356,7 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
tegra30-cardhu-a02.dtb \
tegra30-cardhu-a04.dtb \
tegra114-dalmore.dtb \
+ tegra114-roth.dtb \
tegra124-venice2.dtb
dtb-$(CONFIG_ARCH_VERSATILE) += versatile-ab.dtb \
versatile-pb.dtb
diff --git a/arch/arm/boot/dts/tegra114-roth.dts
b/arch/arm/boot/dts/tegra114-roth.dts
new file mode 100644
index ..bb19abeb956a
--- /dev/null
+++ b/arch/arm/boot/dts/tegra114-roth.dts
@@ -0,0 +1,1069 @@
+/dts-v1/;
+
+#include "tegra114.dtsi"
+
+/ {
+ model = "NVIDIA SHIELD";
+ compatible = "nvidia,roth", "nvidia,tegra114";
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 console=tty1 gpt cma=128M
fbcon=rotate:1";
+ linux,initrd-start = <0x8200>;
+ linux,initrd-end = <0x8280>;
+ };
+
+ firmware {
+ trusted-foundations {
+ compatible = "tlm,trusted-foundations";
+ tlm,version-major = <2>;
+ tlm,version-minor = <8>;
+ };
+ };
+
+ memory {
+ /* memory >= 0x7960 is reserved for firmware usage */
+ reg = <0x8000 0x7960>;
+ };
+
+ pinmux@7868 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+
+ state_default: pinmux {
+ clk1_out_pw4 {
+ nvidia,pins = "clk1_out_pw4";
+ nvidia,function = "extperiph1";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ dap1_din_pn1 {
+ nvidia,pins = "dap1_din_pn1";
+ nvidia,function = "i2s0";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ dap1_dout_pn2 {
+ nvidia,pins = "dap1_dout_pn2",
+ "dap1_fs_pn0",
+ "dap1_sclk_pn3";
+ nvidia,function = "i2s0";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ dap2_din_pa4 {
+ nvidia,pins = "dap2_din_pa4";
+ nvidia,function = "i2s1";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ dap2_dout_pa5 {
+ nvidia,pins = "dap2_dout_pa5",
+ "dap2_fs_pa2",
+ "dap2_sclk_pa3";
+ nvidia,function = "i2s1";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ dap4_din_pp5 {
+ nvidia,pins = "dap4_din_pp5",
+ "dap4_dout_pp6",
+ "dap4_fs_pp4",
+ "dap4_sclk_pp7";
+ nvidia,function = "i2s3";
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
+ };
+ dvfs_pwm_px0 {
+ nvidia,pins = "dvfs_pwm_px0",
+ "dvfs_clk_px2";
+ nvidia,function =
[PATCHv3 3/3] ASoC: core: Fix check before setting default I/O up try regmap
Since the CODEC driver could specify its own I/O(read and write)
while registering the CODEC for some reason, maybe the MFDs is
used, etc.
So just do check it, if they are not specified by CODEC driver
then try to set up the default regmap I/O if regmap is used.
Signed-off-by: Xiubo Li
---
sound/soc/soc-core.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 6880fad..a14155b 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1137,9 +1137,15 @@ static int soc_probe_codec(struct snd_soc_card *card,
codec->dapm.idle_bias_off = driver->idle_bias_off;
- /* Set the default I/O up try regmap */
- if (dev_get_regmap(codec->dev, NULL))
- snd_soc_codec_set_cache_io(codec, NULL);
+ if (!codec->write && dev_get_regmap(codec->dev, NULL)) {
+ /* Set the default I/O up try regmap */
+ ret = snd_soc_codec_set_cache_io(codec, NULL);
+ if (ret < 0) {
+ dev_err(codec->dev,
+ "Failed to set cache I/O: %d\n", ret);
+ goto err_probe;
+ }
+ }
if (driver->probe) {
ret = driver->probe(codec);
--
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/
[PATCHv3 0/3] Simplify the CODEC ASoC probe code.
Mainly fix the warnings about unused variables caused by the first patch. Xiubo Li (3): ASoC: codec: Simplify ASoC probe code. ASoC: io: New signature for snd_soc_codec_set_cache_io() ASoC: core: Fix check before setting default I/O up try regmap include/sound/soc.h | 7 +- sound/soc/codecs/ad193x.c| 10 + sound/soc/codecs/adau1373.c | 7 -- sound/soc/codecs/adav80x.c | 7 -- sound/soc/codecs/ak4535.c| 9 sound/soc/codecs/ak4641.c| 8 --- sound/soc/codecs/ak4642.c| 8 --- sound/soc/codecs/ak4671.c| 12 +- sound/soc/codecs/alc5623.c | 7 -- sound/soc/codecs/alc5632.c | 8 --- sound/soc/codecs/cq93vc.c| 3 +-- sound/soc/codecs/cs4270.c| 9 sound/soc/codecs/cs42l51.c | 6 - sound/soc/codecs/cs42l52.c | 9 +--- sound/soc/codecs/cs42l73.c | 11 +- sound/soc/codecs/da7210.c| 8 --- sound/soc/codecs/da7213.c| 8 --- sound/soc/codecs/da732x.c| 13 ++- sound/soc/codecs/da9055.c| 8 --- sound/soc/codecs/isabelle.c | 16 -- sound/soc/codecs/lm49453.c | 17 --- sound/soc/codecs/max9768.c | 5 - sound/soc/codecs/max98088.c | 6 - sound/soc/codecs/max98090.c | 8 --- sound/soc/codecs/max98095.c | 6 - sound/soc/codecs/max9850.c | 8 --- sound/soc/codecs/mc13783.c | 4 ++-- sound/soc/codecs/ml26124.c | 10 - sound/soc/codecs/rt5631.c| 9 sound/soc/codecs/rt5640.c| 8 --- sound/soc/codecs/sn95031.c | 2 -- sound/soc/codecs/ssm2518.c | 10 - sound/soc/codecs/ssm2602.c | 7 -- sound/soc/codecs/sta32x.c| 14 sound/soc/codecs/sta529.c| 10 - sound/soc/codecs/tlv320aic23.c | 8 --- sound/soc/codecs/tlv320aic26.c | 2 -- sound/soc/codecs/tlv320aic32x4.c | 2 -- sound/soc/codecs/tlv320aic3x.c | 6 - sound/soc/codecs/tlv320dac33.c | 1 - sound/soc/codecs/wm2000.c| 2 -- sound/soc/codecs/wm2200.c| 7 -- sound/soc/codecs/wm5100.c| 7 -- sound/soc/codecs/wm5102.c| 4 +--- sound/soc/codecs/wm5110.c| 3 +-- sound/soc/codecs/wm8350.c| 4 +--- sound/soc/codecs/wm8400.c| 3 +-- sound/soc/codecs/wm8510.c| 10 + sound/soc/codecs/wm8523.c| 7 -- sound/soc/codecs/wm8580.c| 6 - sound/soc/codecs/wm8711.c| 6 - sound/soc/codecs/wm8728.c| 11 +- sound/soc/codecs/wm8731.c| 7 -- sound/soc/codecs/wm8737.c| 6 - sound/soc/codecs/wm8741.c| 6 - sound/soc/codecs/wm8750.c| 6 - sound/soc/codecs/wm8753.c| 7 -- sound/soc/codecs/wm8770.c| 6 - sound/soc/codecs/wm8776.c| 6 - sound/soc/codecs/wm8804.c| 8 --- sound/soc/codecs/wm8900.c| 8 +-- sound/soc/codecs/wm8903.c| 10 + sound/soc/codecs/wm8904.c| 9 sound/soc/codecs/wm8940.c| 6 - sound/soc/codecs/wm8955.c| 8 --- sound/soc/codecs/wm8960.c| 6 - sound/soc/codecs/wm8961.c| 7 -- sound/soc/codecs/wm8962.c| 7 -- sound/soc/codecs/wm8971.c| 6 - sound/soc/codecs/wm8974.c| 6 - sound/soc/codecs/wm8978.c| 8 +-- sound/soc/codecs/wm8983.c| 6 - sound/soc/codecs/wm8985.c| 7 -- sound/soc/codecs/wm8988.c| 8 --- sound/soc/codecs/wm8990.c| 8 --- sound/soc/codecs/wm8991.c| 8 --- sound/soc/codecs/wm8993.c| 7 -- sound/soc/codecs/wm8994.c| 3 +-- sound/soc/codecs/wm8995.c| 7 -- sound/soc/codecs/wm8996.c| 12 +- sound/soc/codecs/wm8997.c| 4 +--- sound/soc/codecs/wm9081.c| 11 +- sound/soc/codecs/wm9090.c| 10 - sound/soc/soc-core.c | 12 +++--- sound/soc/soc-io.c | 47 +--- 85 files changed, 52 insertions(+), 618 deletions(-) -- 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/
[PATCHv3 0/3] Simplify the CODEC ASoC probe code.
Mainly fix the warnings about unused variables caused by the first patch. Xiubo Li (3): ASoC: codec: Simplify ASoC probe code. ASoC: io: New signature for snd_soc_codec_set_cache_io() ASoC: core: Fix check before setting default I/O up try regmap include/sound/soc.h | 7 +- sound/soc/codecs/ad193x.c| 10 + sound/soc/codecs/adau1373.c | 7 -- sound/soc/codecs/adav80x.c | 7 -- sound/soc/codecs/ak4535.c| 9 sound/soc/codecs/ak4641.c| 8 --- sound/soc/codecs/ak4642.c| 8 --- sound/soc/codecs/ak4671.c| 12 +- sound/soc/codecs/alc5623.c | 7 -- sound/soc/codecs/alc5632.c | 8 --- sound/soc/codecs/cq93vc.c| 3 +-- sound/soc/codecs/cs4270.c| 9 sound/soc/codecs/cs42l51.c | 6 - sound/soc/codecs/cs42l52.c | 9 +--- sound/soc/codecs/cs42l73.c | 11 +- sound/soc/codecs/da7210.c| 8 --- sound/soc/codecs/da7213.c| 8 --- sound/soc/codecs/da732x.c| 13 ++- sound/soc/codecs/da9055.c| 8 --- sound/soc/codecs/isabelle.c | 16 -- sound/soc/codecs/lm49453.c | 17 --- sound/soc/codecs/max9768.c | 5 - sound/soc/codecs/max98088.c | 6 - sound/soc/codecs/max98090.c | 8 --- sound/soc/codecs/max98095.c | 6 - sound/soc/codecs/max9850.c | 8 --- sound/soc/codecs/mc13783.c | 4 ++-- sound/soc/codecs/ml26124.c | 10 - sound/soc/codecs/rt5631.c| 9 sound/soc/codecs/rt5640.c| 8 --- sound/soc/codecs/sn95031.c | 2 -- sound/soc/codecs/ssm2518.c | 10 - sound/soc/codecs/ssm2602.c | 7 -- sound/soc/codecs/sta32x.c| 14 sound/soc/codecs/sta529.c| 10 - sound/soc/codecs/tlv320aic23.c | 8 --- sound/soc/codecs/tlv320aic26.c | 2 -- sound/soc/codecs/tlv320aic32x4.c | 2 -- sound/soc/codecs/tlv320aic3x.c | 6 - sound/soc/codecs/tlv320dac33.c | 1 - sound/soc/codecs/wm2000.c| 2 -- sound/soc/codecs/wm2200.c| 7 -- sound/soc/codecs/wm5100.c| 7 -- sound/soc/codecs/wm5102.c| 4 +--- sound/soc/codecs/wm5110.c| 3 +-- sound/soc/codecs/wm8350.c| 4 +--- sound/soc/codecs/wm8400.c| 3 +-- sound/soc/codecs/wm8510.c| 10 + sound/soc/codecs/wm8523.c| 7 -- sound/soc/codecs/wm8580.c| 6 - sound/soc/codecs/wm8711.c| 6 - sound/soc/codecs/wm8728.c| 11 +- sound/soc/codecs/wm8731.c| 7 -- sound/soc/codecs/wm8737.c| 6 - sound/soc/codecs/wm8741.c| 6 - sound/soc/codecs/wm8750.c| 6 - sound/soc/codecs/wm8753.c| 7 -- sound/soc/codecs/wm8770.c| 6 - sound/soc/codecs/wm8776.c| 6 - sound/soc/codecs/wm8804.c| 8 --- sound/soc/codecs/wm8900.c| 8 +-- sound/soc/codecs/wm8903.c| 10 + sound/soc/codecs/wm8904.c| 9 sound/soc/codecs/wm8940.c| 6 - sound/soc/codecs/wm8955.c| 8 --- sound/soc/codecs/wm8960.c| 6 - sound/soc/codecs/wm8961.c| 7 -- sound/soc/codecs/wm8962.c| 7 -- sound/soc/codecs/wm8971.c| 6 - sound/soc/codecs/wm8974.c| 6 - sound/soc/codecs/wm8978.c| 8 +-- sound/soc/codecs/wm8983.c| 6 - sound/soc/codecs/wm8985.c| 7 -- sound/soc/codecs/wm8988.c| 8 --- sound/soc/codecs/wm8990.c| 8 --- sound/soc/codecs/wm8991.c| 8 --- sound/soc/codecs/wm8993.c| 7 -- sound/soc/codecs/wm8994.c| 3 +-- sound/soc/codecs/wm8995.c| 7 -- sound/soc/codecs/wm8996.c| 12 +- sound/soc/codecs/wm8997.c| 4 +--- sound/soc/codecs/wm9081.c| 11 +- sound/soc/codecs/wm9090.c| 10 - sound/soc/soc-core.c | 12 +++--- sound/soc/soc-io.c | 47 +--- 85 files changed, 52 insertions(+), 618 deletions(-) -- 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/
[PATCHv3 2/3] ASoC: io: New signature for snd_soc_codec_set_cache_io()
Now that all users have been converted to regmap and the config.reg_bits
and config.val_bits can be setted by each user through regmap core API.
So these two params are redundant here.
Since the only control type that left is SND_SOC_REGMAP, so remove it. Drop
the control params and add struct regmap *regmap to simplify the code.
Signed-off-by: Xiubo Li
---
include/sound/soc.h| 7 +--
sound/soc/codecs/cq93vc.c | 3 +--
sound/soc/codecs/mc13783.c | 4 ++--
sound/soc/codecs/tlv320dac33.c | 1 -
sound/soc/codecs/wm5102.c | 4 +---
sound/soc/codecs/wm5110.c | 3 +--
sound/soc/codecs/wm8350.c | 4 +---
sound/soc/codecs/wm8400.c | 3 +--
sound/soc/codecs/wm8994.c | 3 +--
sound/soc/codecs/wm8997.c | 4 +---
sound/soc/soc-core.c | 2 +-
sound/soc/soc-io.c | 47 ++
12 files changed, 31 insertions(+), 54 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index ecfb334..4c4d7e1 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -354,10 +354,6 @@ typedef int (*hw_write_t)(void *,const char* ,int);
extern struct snd_ac97_bus_ops *soc_ac97_ops;
-enum snd_soc_control_type {
- SND_SOC_REGMAP,
-};
-
enum snd_soc_pcm_subclass {
SND_SOC_PCM_CLASS_PCM = 0,
SND_SOC_PCM_CLASS_BE= 1,
@@ -404,8 +400,7 @@ int snd_soc_codec_readable_register(struct snd_soc_codec
*codec,
int snd_soc_codec_writable_register(struct snd_soc_codec *codec,
unsigned int reg);
int snd_soc_codec_set_cache_io(struct snd_soc_codec *codec,
- int addr_bits, int data_bits,
- enum snd_soc_control_type control);
+ struct regmap *regmap);
int snd_soc_cache_sync(struct snd_soc_codec *codec);
int snd_soc_cache_init(struct snd_soc_codec *codec);
int snd_soc_cache_exit(struct snd_soc_codec *codec);
diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c
index 43737a27..1e25c7a 100644
--- a/sound/soc/codecs/cq93vc.c
+++ b/sound/soc/codecs/cq93vc.c
@@ -138,9 +138,8 @@ static int cq93vc_probe(struct snd_soc_codec *codec)
struct davinci_vc *davinci_vc = codec->dev->platform_data;
davinci_vc->cq93vc.codec = codec;
- codec->control_data = davinci_vc->regmap;
- snd_soc_codec_set_cache_io(codec, 32, 32, SND_SOC_REGMAP);
+ snd_soc_codec_set_cache_io(codec, davinci_vc->regmap);
/* Off, with power on */
cq93vc_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
diff --git a/sound/soc/codecs/mc13783.c b/sound/soc/codecs/mc13783.c
index c605036..3331cc7 100644
--- a/sound/soc/codecs/mc13783.c
+++ b/sound/soc/codecs/mc13783.c
@@ -614,8 +614,8 @@ static int mc13783_probe(struct snd_soc_codec *codec)
struct mc13783_priv *priv = snd_soc_codec_get_drvdata(codec);
int ret;
- codec->control_data = dev_get_regmap(codec->dev->parent, NULL);
- ret = snd_soc_codec_set_cache_io(codec, 8, 24, SND_SOC_REGMAP);
+ ret = snd_soc_codec_set_cache_io(codec,
+ dev_get_regmap(codec->dev->parent, NULL));
if (ret != 0) {
dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret);
return ret;
diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c
index 9ce8496..30d8596 100644
--- a/sound/soc/codecs/tlv320dac33.c
+++ b/sound/soc/codecs/tlv320dac33.c
@@ -122,7 +122,6 @@ struct tlv320dac33_priv {
unsigned int uthr;
enum dac33_state state;
- enum snd_soc_control_type control_type;
void *control_data;
};
diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c
index 293dffc..01b6ee4 100644
--- a/sound/soc/codecs/wm5102.c
+++ b/sound/soc/codecs/wm5102.c
@@ -1760,9 +1760,7 @@ static int wm5102_codec_probe(struct snd_soc_codec *codec)
struct wm5102_priv *priv = snd_soc_codec_get_drvdata(codec);
int ret;
- codec->control_data = priv->core.arizona->regmap;
-
- ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP);
+ ret = snd_soc_codec_set_cache_io(codec, priv->core.arizona->regmap);
if (ret != 0)
return ret;
diff --git a/sound/soc/codecs/wm5110.c b/sound/soc/codecs/wm5110.c
index 4de2bf1..cf5d828f 100644
--- a/sound/soc/codecs/wm5110.c
+++ b/sound/soc/codecs/wm5110.c
@@ -1587,10 +1587,9 @@ static int wm5110_codec_probe(struct snd_soc_codec
*codec)
struct wm5110_priv *priv = snd_soc_codec_get_drvdata(codec);
int ret;
- codec->control_data = priv->core.arizona->regmap;
priv->core.arizona->dapm = >dapm;
- ret = snd_soc_codec_set_cache_io(codec, 32, 16, SND_SOC_REGMAP);
+ ret = snd_soc_codec_set_cache_io(codec, priv->core.arizona->regmap);
if (ret != 0)
return ret;
diff --git a/sound/soc/codecs/wm8350.c b/sound/soc/codecs/wm8350.c
index
[PATCHv3 3/3] ASoC: core: Fix check before setting default I/O up try regmap
Since the CODEC driver could specify its own I/O(read and write)
while registering the CODEC for some reason, maybe the MFDs is
used, etc.
So just do check it, if they are not specified by CODEC driver
then try to set up the default regmap I/O if regmap is used.
Signed-off-by: Xiubo Li
---
sound/soc/soc-core.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 6880fad..a14155b 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1137,9 +1137,15 @@ static int soc_probe_codec(struct snd_soc_card *card,
codec->dapm.idle_bias_off = driver->idle_bias_off;
- /* Set the default I/O up try regmap */
- if (dev_get_regmap(codec->dev, NULL))
- snd_soc_codec_set_cache_io(codec, NULL);
+ if (!codec->write && dev_get_regmap(codec->dev, NULL)) {
+ /* Set the default I/O up try regmap */
+ ret = snd_soc_codec_set_cache_io(codec, NULL);
+ if (ret < 0) {
+ dev_err(codec->dev,
+ "Failed to set cache I/O: %d\n", ret);
+ goto err_probe;
+ }
+ }
if (driver->probe) {
ret = driver->probe(codec);
--
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/
[PATCHv3 1/3] ASoC: codec: Simplify ASoC probe code.
For some CODEC drivers like who act as the MFDs children are ignored
by this patch.
Signed-off-by: Xiubo Li
---
sound/soc/codecs/ad193x.c| 10 +-
sound/soc/codecs/adau1373.c | 7 ---
sound/soc/codecs/adav80x.c | 7 ---
sound/soc/codecs/ak4535.c| 9 -
sound/soc/codecs/ak4641.c| 8
sound/soc/codecs/ak4642.c| 8
sound/soc/codecs/ak4671.c| 12 +---
sound/soc/codecs/alc5623.c | 7 ---
sound/soc/codecs/alc5632.c | 8
sound/soc/codecs/cs4270.c| 9 -
sound/soc/codecs/cs42l51.c | 6 --
sound/soc/codecs/cs42l52.c | 9 +
sound/soc/codecs/cs42l73.c | 11 +--
sound/soc/codecs/da7210.c| 8
sound/soc/codecs/da7213.c| 8
sound/soc/codecs/da732x.c| 13 ++---
sound/soc/codecs/da9055.c| 8
sound/soc/codecs/isabelle.c | 16
sound/soc/codecs/lm49453.c | 17 -
sound/soc/codecs/max9768.c | 5 -
sound/soc/codecs/max98088.c | 6 --
sound/soc/codecs/max98090.c | 8
sound/soc/codecs/max98095.c | 6 --
sound/soc/codecs/max9850.c | 8
sound/soc/codecs/ml26124.c | 10 --
sound/soc/codecs/rt5631.c| 9 -
sound/soc/codecs/rt5640.c| 8
sound/soc/codecs/sn95031.c | 2 --
sound/soc/codecs/ssm2518.c | 10 --
sound/soc/codecs/ssm2602.c | 7 ---
sound/soc/codecs/sta32x.c| 14 --
sound/soc/codecs/sta529.c| 10 --
sound/soc/codecs/tlv320aic23.c | 8
sound/soc/codecs/tlv320aic26.c | 2 --
sound/soc/codecs/tlv320aic32x4.c | 2 --
sound/soc/codecs/tlv320aic3x.c | 6 --
sound/soc/codecs/wm2000.c| 2 --
sound/soc/codecs/wm2200.c| 7 ---
sound/soc/codecs/wm5100.c| 7 ---
sound/soc/codecs/wm8510.c| 10 +-
sound/soc/codecs/wm8523.c| 7 ---
sound/soc/codecs/wm8580.c| 6 --
sound/soc/codecs/wm8711.c| 6 --
sound/soc/codecs/wm8728.c| 11 +--
sound/soc/codecs/wm8731.c| 7 ---
sound/soc/codecs/wm8737.c| 6 --
sound/soc/codecs/wm8741.c| 6 --
sound/soc/codecs/wm8750.c| 6 --
sound/soc/codecs/wm8753.c| 7 ---
sound/soc/codecs/wm8770.c| 6 --
sound/soc/codecs/wm8776.c| 6 --
sound/soc/codecs/wm8804.c| 8
sound/soc/codecs/wm8900.c| 8 +---
sound/soc/codecs/wm8903.c| 10 +-
sound/soc/codecs/wm8904.c| 9 -
sound/soc/codecs/wm8940.c| 6 --
sound/soc/codecs/wm8955.c| 8
sound/soc/codecs/wm8960.c| 6 --
sound/soc/codecs/wm8961.c| 7 ---
sound/soc/codecs/wm8962.c| 7 ---
sound/soc/codecs/wm8971.c| 6 --
sound/soc/codecs/wm8974.c| 6 --
sound/soc/codecs/wm8978.c| 8 +---
sound/soc/codecs/wm8983.c| 6 --
sound/soc/codecs/wm8985.c| 7 ---
sound/soc/codecs/wm8988.c| 8
sound/soc/codecs/wm8990.c| 8
sound/soc/codecs/wm8991.c| 8
sound/soc/codecs/wm8993.c| 7 ---
sound/soc/codecs/wm8995.c| 7 ---
sound/soc/codecs/wm8996.c| 12 +---
sound/soc/codecs/wm9081.c| 11 +--
sound/soc/codecs/wm9090.c| 10 --
73 files changed, 13 insertions(+), 562 deletions(-)
diff --git a/sound/soc/codecs/ad193x.c b/sound/soc/codecs/ad193x.c
index 9381a76..6844d0b 100644
--- a/sound/soc/codecs/ad193x.c
+++ b/sound/soc/codecs/ad193x.c
@@ -322,14 +322,6 @@ static struct snd_soc_dai_driver ad193x_dai = {
static int ad193x_codec_probe(struct snd_soc_codec *codec)
{
struct ad193x_priv *ad193x = snd_soc_codec_get_drvdata(codec);
- int ret;
-
- codec->control_data = ad193x->regmap;
- ret = snd_soc_codec_set_cache_io(codec, 0, 0, SND_SOC_REGMAP);
- if (ret < 0) {
- dev_err(codec->dev, "failed to set cache I/O: %d\n", ret);
- return ret;
- }
/* default setting for ad193x */
@@ -347,7 +339,7 @@ static int ad193x_codec_probe(struct snd_soc_codec *codec)
regmap_write(ad193x->regmap, AD193X_PLL_CLK_CTRL0, 0x99); /*
mclk=24.576Mhz: 0x9D; mclk=12.288Mhz: 0x99 */
regmap_write(ad193x->regmap, AD193X_PLL_CLK_CTRL1, 0x04);
- return ret;
+ return 0;
}
static struct snd_soc_codec_driver soc_codec_dev_ad193x = {
diff --git a/sound/soc/codecs/adau1373.c b/sound/soc/codecs/adau1373.c
index 5765c22..97f610a 100644
--- a/sound/soc/codecs/adau1373.c
+++ b/sound/soc/codecs/adau1373.c
@@ -1376,15 +1376,8 @@ static int adau1373_probe(struct snd_soc_codec *codec)
struct adau1373_platform_data
MONEY GRAM
Your$6.5million.Is ready to release contact with your full details as blow, email(moneygramoffice...@rediffmail.com) call on phone +22998091427,once you sent your full details,such as your name phone number your country and address and drive licenses. Paul Ego -- 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] drivers: cpufreq: Mark function as static in cpufreq.c
On Thu, Feb 27, 2014 at 12:25 AM, Viresh Kumar wrote: > Hi Rashika, > > On 26 February 2014 22:08, Rashika Kheria wrote: >> Mark function as static in cpufreq.c because it is not >> used outside this file. >> >> This eliminates the following warning in cpufreq.c: >> drivers/cpufreq/cpufreq.c:355:9: warning: no previous prototype for >> 'show_boost' [-Wmissing-prototypes] > > Can you please elaborate how this warning is related to > the non-static definition of this function? -Wmissing-prototypes warns when a non-static function is defined before a corresponding prototype (usually inside an included header file) is declared. In such a case, it is impossible to reference the non-static function from another file, and therefore the function should be marked static (usually). Hope that makes sense! -- 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 3.14-rc5
Another week, another rc.
Things were fairly calm, and fairly normal. Drivers account for just
under 60% of the patch (sound dominates due to a couple of patches
that are larger but trivial, but there's various misc oneliners all
over). The rest is mostly arch updates (mainly powerpc and xtensa),
and then there's a smattering of small stuff elsewhere.
Not a lot. Which is just how I like it.
Go verify that it all works for you..
Linus
---
Alex Deucher (7):
MAINTAINERS: add entry for drm radeon driver
MAINTAINERS: update drm git tree entry
drm/radeon: print the supported atpx function mask
drm/radeon: disable pll sharing for DP on DCE4.1
drm/radeon: fix audio disable on dce6+
drm/radeon: change audio enable logic
drm/radeon: enable speaker allocation setup on dce3.2
Alexey Khoroshilov (1):
drm/vmwgfx: avoid null pointer dereference at failure paths
Andi Kleen (1):
perf tools: fix BFD detection on opensuse
Andrew Honig (1):
kvm: x86: fix emulator buffer overflow (CVE-2014-0049)
Benjamin Herrenschmidt (2):
powerpc/powernv: Fix opal_xscom_{read,write} prototype
powerpc/powernv: Fix indirect XSCOM unmangling
Beomho Seo (2):
iio: cm36651: Fix read/write integration time function.
iio: cm32181: Change cm32181 ambient light sensor driver
Brian Norris (1):
mtd: nand: fix off-by-one read retry mode counting
Catalin Marinas (1):
arm64: Fix !CONFIG_SMP kernel build
Charles Keepax (3):
ASoC: dapm: Correct regulator bypass error messages
Input - arizona-haptics: Fix double lock of dapm_mutex
ASoC: dapm: Add locking to snd_soc_dapm__pin functions
Chris Zankel (2):
xtensa: fix fast_syscall_spill_registers
xtensa: fix fast_syscall_spill_registers
Christian Engelmayer (1):
pwm: lp3943: Fix potential memory leak during request
Christian König (1):
drm/radeon: fix missing bo reservation
Dan Carpenter (1):
UBI: fix some use after free bugs
Dan Williams (1):
ioat: fix tasklet tear down
Davidlohr Bueso (1):
ipc,mqueue: remove limits for the amount of system-wide queues
Denis CIOCCA (1):
iio:gyro: bug on L3GD20H gyroscope support
Dirk Brandewie (1):
intel_pstate: Change busy calculation to use fixed point math.
Dmitry Osipenko (1):
drm/tegra: Add guard to avoid double disable/enable of RGB outputs
Dr. Greg Wettstein (1):
qla2xxx: Fix kernel panic on selective retransmission request
Eric Paris (1):
SELinux: bigendian problems with filename trans rules
Erik Faye-Lund (1):
gpu: host1x: do not check previously handled gathers
Eugene Surovegin (1):
x86, kaslr: export offset in VMCOREINFO ELF notes
Fathi Boudra (1):
Makefile: fix extra parenthesis typo when
CC_STACKPROTECTOR_REGULAR is enabled
Gavin Shan (2):
powerpc/powernv: Dump PHB diag-data immediately
powerpc/powernv: Refactor PHB diag-data dump
Geert Uytterhoeven (3):
m68k: Sort arch/m68k/include/asm/Kbuild
m68k: Switch to asm-generic/barrier.h
m68k: Wire up sched_setattr and sched_getattr
Gerald Schaefer (1):
s390/pci/dma: use correct segment boundary size
Hannes Reinecke (1):
dm mpath: fix stalls when handling invalid ioctls
Heiko Carstens (1):
s390/compat: fix sys_sched_getattr compat wrapper
Heinz Mauelshagen (1):
dm cache: fix truncation bug when mapping I/O to >2TB fast device
Ingo Tuchscherer (1):
s390/zcrypt: additional check to avoid overflow in msg-type 6 requests
James Hogan (2):
asm-generic: add sched_setattr/sched_getattr syscalls
irq-metag*: stop set_affinity vectoring to offline cpus
Jan Beulich (1):
Makefile: fix build with make 3.80 again
Jan Kara (7):
inotify: Fix reporting of cookies for inotify events
udf: Fix data corruption on file type conversion
quota: Fix race between dqput() and dquot_scan_active()
Revert "writeback: do not sync data dirtied after sync start"
fsnotify: Fix detection whether overflow event is queued
fanotify: Handle overflow in case of permission events
fsnotify: Allocate overflow events with proper type
Jean Delvare (2):
i7core_edac: Fix PCI device reference count
i7300_edac: Fix device reference count
Jerome Glisse (1):
drm/radeon: free uvd ring on unload
Jiri Olsa (1):
perf tools: Fix strict alias issue for find_first_bit
Joe Perches (3):
drivers/iommu/omap-iommu-debug.c: fix decimal permissions
drivers/fmc/fmc-write-eeprom.c: fix decimal permissions
MAINTAINERS: update L: misuses
Joerg Dorchain (1):
USB: ftdi_sio: add Cressi Leonardo PID
Juergen Beisert (1):
staging:iio:adc:MXS:LRADC: fix touchscreen statemachine
Kailang Yang (2):
ALSA: hda/realtek - Add more entry for enable HP mute led
ALSA: hda/realtek - Add more entry for enable HP mute led
Kees Cook (1):
x86, kaslr: add
Re: [PATCH 3/4] power_supply: Introduce PSE compliant algorithm
On Fri, Feb 28, 2014 at 11:08:16AM +0100, Pavel Machek wrote: > On Fri 2014-02-28 08:37:27, Jenny Tc wrote: > > On Thu, Feb 27, 2014 at 09:18:57PM +0100, Linus Walleij wrote: > > > On Tue, Feb 4, 2014 at 6:12 AM, Jenny TC wrote: > > > > > > > +static inline bool __is_battery_full > > > > + (long volt, long cur, long iterm, unsigned long cv) > > > > > > Overall I wonder if you've run checkpatch on these patches, but why > > > are you naming this one function with a double __underscore? > > > Just is_battery_full_check() or something would work fine I guess? > > > > Just to convey that is_battery_full is a local function and not generic. You > > can find similar usage in power_supply_core.c (__power_supply_changed_work) > > and in other drivers. Isn't it advised to have __ prefixes? > > It is static; everybody sees it is local. __ prefix usually means > something else. Agreed, I will remove the __ prefix in next patchset. Meanwhile I would appreciate if anyone could help me to understand what __ prefix really means. > > > > + u16 capacity; /* mAh */ > > > > + u16 voltage_max; /* mV */ > > > > + /* charge termination current */ > > > > + u16 chrg_term_mA; > > > > + /* Low battery level voltage */ > > > > + u16 low_batt_mV; > > > > + /* upper and lower temperature limits on discharging */ > > > > + s8 disch_temp_ul; /* Degree Celsius */ > > > > + s8 disch_temp_ll; /* Degree Celsius */ > > > > + /* number of temperature monitoring ranges */ > > > > + u16 temp_mon_ranges; > > > > + struct psy_ps_temp_chg_table temp_mon_range[BATT_TEMP_NR_RNG]; > > > > + /* lowest temperature supported */ > > > > + s8 temp_low_lim; > > > > +} __packed; > > > > > > Why packed, and convert to kerneldoc for this struct. > > > > Battery charging profile, may come from EEPROM/emmc which would be packed. > > Do you need to do endianness conversion, too? May/may not depending on the stored format. If needed, the endianess conversion should be done at driver level where the EEPROM/emmc reading happens. -- 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: [PATCHv2 1/3] ASoC: codec: Simplify ASoC probe code.
> > "Just removing the set_cache_io() call will not work for all
> > drivers. There are some MFD child devices which use regmap from the parent
> > device. So dev_get_regmap() will return NULL for those."
>
> This is the sort of thing that I was referring to when talking about
> doing the non-boring drivers separately. As well as the warnings Lars
> mentioned there's a bisection issue here:
>
> > - codec->control_data = da7213->regmap;
> > - ret = snd_soc_codec_set_cache_io(codec, 8, 8, SND_SOC_REGMAP);
> > - if (ret < 0) {
> > - dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret);
> > - return ret;
> > - }
> > -
> > /* Default to using ALC auto offset calibration mode. */
> > snd_soc_update_bits(codec, DA7213_ALC_CTRL1,
> > DA7213_ALC_CALIB_MODE_MAN, 0);
>
> Unless the core sets up the I/O before calling probe() the above is
> going to mean that the snd_soc_update_bits() call fails since the I/O
> operations won't have been set up. There is a defualt call to set a
> regmap up but it's only done after the probe.
Yes, like the SGTL5000 CODEC driver, which needs to read the chip information
in main probe. And then it must use the regmap core APIs directly.
And I have do another research early, all the CODEC drivers who are calling
set_cache_io() in ASoC probes, and before that they all are using the regmap
core
APIs instead of ASoC ones if needed.
I think we should move the set_cache_io() calling more earlier as we discussed
before, but need much more research and testing. Splitting them into another
separate patch later will be much better and easier to be reviewed.
Thanks,
--
Best Regards,
Xiubo
--
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 v2 1/2] Staging: comedi: introduce {outl,inl}_amcc() and {outl,inl}_iobase() helper functions in hwdrv_apci1564.c
This patch introduces a few simple outl and inl helper functions to allow
several lines which violate the character limit to be shortened
appropriately. It also changes a few macro values which represented
offset values from a single unique base value to instead represent the value
of that base plus the offset. This is to simplify the use of these macros
in the new helper functions.
Cc: Dan Carpenter
Signed-off-by: Chase Southwood
---
All right, here's another shot at this. Dan, I took your outl_amcc idea
and did a version for the outl/inl calls based from devpriv->iobase as well.
I changed all of the macros which only offset from one base value as you
had mentioned as well, and the result is starting to look very good.
The only outl/inl calls which still look a little gross (see PATCH v2 2/2) are
the ones involving DIGITAL_OP_WATCHDOG, TIMER, or any of the COUNTER macros,
just because they use a common set of offset macros so simplifying
those calls in the same way as the rest isn't possible. What are your
thoughts on this version of the patchset?
This is version 2 of [PATCH 1/2] Staging: comedi: introduce outl_1564_* and
inl_1564_* helper functions in hwdrv_apci1564.c
2: Changed helper functions from {outl,inl}_1564_*() to
{outl,inl}_{amcc,iobase}()
Comments welcome!
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 38 +-
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 2b47fa1..58e301d 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -49,25 +49,25 @@ This program is distributed in the hope that it will be
useful, but WITHOUT ANY
/* DIGITAL INPUT-OUTPUT DEFINE */
/* Input defines */
#define APCI1564_DIGITAL_IP0x04
-#define APCI1564_DIGITAL_IP_INTERRUPT_MODE14
-#define APCI1564_DIGITAL_IP_INTERRUPT_MODE28
-#define APCI1564_DIGITAL_IP_IRQ16
+#define APCI1564_DIGITAL_IP_INTERRUPT_MODE1(0x04 + 0x04)
+#define APCI1564_DIGITAL_IP_INTERRUPT_MODE2(0x04 + 0x08)
+#define APCI1564_DIGITAL_IP_IRQ(0x04 + 0x10)
/* Output defines */
#define APCI1564_DIGITAL_OP0x18
-#define APCI1564_DIGITAL_OP_RW 0
-#define APCI1564_DIGITAL_OP_INTERRUPT 4
-#define APCI1564_DIGITAL_OP_IRQ12
+#define APCI1564_DIGITAL_OP_RW 0x18
+#define APCI1564_DIGITAL_OP_INTERRUPT (0x18 + 0x04)
+#define APCI1564_DIGITAL_OP_IRQ(0x18 + 0x0C)
/* Digital Input IRQ Function Selection */
#define ADDIDATA_OR0
#define ADDIDATA_AND 1
/* Digital Input Interrupt Status */
-#define APCI1564_DIGITAL_IP_INTERRUPT_STATUS 12
+#define APCI1564_DIGITAL_IP_INTERRUPT_STATUS (0x04 + 0x0C)
/* Digital Output Interrupt Status */
-#define APCI1564_DIGITAL_OP_INTERRUPT_STATUS 8
+#define APCI1564_DIGITAL_OP_INTERRUPT_STATUS (0x18 + 0x08)
/* Digital Input Interrupt Enable Disable. */
#define APCI1564_DIGITAL_IP_INTERRUPT_ENABLE 0x4
@@ -99,6 +99,28 @@ This program is distributed in the hope that it will be
useful, but WITHOUT ANY
#define APCI1564_TCW_WARN_TIMEVAL 24
#define APCI1564_TCW_WARN_TIMEBASE 28
+static void outl_amcc(struct addi_private *devpriv, unsigned int cmd,
+ unsigned int reg)
+{
+ outl(cmd, devpriv->i_IobaseAmcc + reg);
+}
+
+static unsigned int inl_amcc(struct addi_private *devpriv, unsigned int reg)
+{
+ return inl(devpriv->i_IobaseAmcc + reg);
+}
+
+static void outl_iobase(struct addi_private *devpriv, unsigned int cmd,
+ unsigned int reg)
+{
+ outl(cmd, devpriv->iobase + reg);
+}
+
+static void inl_iobase(struct addi_private *devpriv, unsigned int reg)
+{
+ return inl(devpriv->iobase + reg);
+}
+
/* Global variables */
static unsigned int ui_InterruptStatus_1564;
static unsigned int ui_InterruptData, ui_Type;
--
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/
[PATCH v2 2/2] Staging: comedi: use inl() and outl() helper functions
Use the newly created helper functions to improve code readability and shorten
several lines to under the character limit.
Cc: Dan Carpenter
Signed-off-by: Chase Southwood
---
I've reviewed this as best as I can, but I know it's a bear to review.
If there is some logical way that you'd like me to split this up into separate
patches to make it easier to review, please let me know.
Also, Dan, as best as I can possibly tell, i_APCI1564_Reset() is absolutely
buggy. When making up this patch, I made the changes that seem correct (and
somewhat obvious) from looking at the other addi-data drivers, the other
functions in this file, and the hardware specs that I could find, but
unfortunately I have no way to test the code.
This patch is version 2 of [PATCH 2/2] Staging: comedi: use outl_1564_* and
inl_1564_* helper functions in hwdrv_apci1564.c
2: Helper functions changed.
Comments are welcome!
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 366 -
1 file changed, 137 insertions(+), 229 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 58e301d..4b4a4bb 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -165,31 +165,17 @@ static int i_APCI1564_ConfigDigitalInput(struct
comedi_device *dev,
if (data[0] == ADDIDATA_ENABLE) {
data[2] = data[2] << 4;
data[3] = data[3] << 4;
- outl(data[2],
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_INTERRUPT_MODE1);
- outl(data[3],
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_INTERRUPT_MODE2);
+ outl_amcc(devpriv, data[2],
APCI1564_DIGITAL_IP_INTERRUPT_MODE1);
+ outl_amcc(devpriv, data[3],
APCI1564_DIGITAL_IP_INTERRUPT_MODE2);
if (data[1] == ADDIDATA_OR) {
- outl(0x4,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_IRQ);
+ outl_amcc(devpriv, 0x4, APCI1564_DIGITAL_IP_IRQ);
} else {
- outl(0x6,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_IRQ);
+ outl_amcc(devpriv, 0x6, APCI1564_DIGITAL_IP_IRQ);
}
} else {
- outl(0x0,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_INTERRUPT_MODE1);
- outl(0x0,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_INTERRUPT_MODE2);
- outl(0x0,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP +
- APCI1564_DIGITAL_IP_IRQ);
+ outl_amcc(devpriv, 0x0, APCI1564_DIGITAL_IP_INTERRUPT_MODE1);
+ outl_amcc(devpriv, 0x0, APCI1564_DIGITAL_IP_INTERRUPT_MODE2);
+ outl_amcc(devpriv, 0x0, APCI1564_DIGITAL_IP_IRQ);
}
return insn->n;
@@ -202,7 +188,7 @@ static int apci1564_di_insn_bits(struct comedi_device *dev,
{
struct addi_private *devpriv = dev->private;
- data[1] = inl(devpriv->i_IobaseAmcc + APCI1564_DIGITAL_IP);
+ data[1] = inl_amcc(devpriv, APCI1564_DIGITAL_IP);
return insn->n;
}
@@ -261,12 +247,8 @@ static int i_APCI1564_ConfigDigitalOutput(struct
comedi_device *dev,
else
ul_Command = ul_Command & 0xFFFD;
- outl(ul_Command,
- devpriv->i_IobaseAmcc + APCI1564_DIGITAL_OP +
- APCI1564_DIGITAL_OP_INTERRUPT);
- ui_InterruptData =
- inl(devpriv->i_IobaseAmcc + APCI1564_DIGITAL_OP +
- APCI1564_DIGITAL_OP_INTERRUPT);
+ outl_amcc(devpriv, ul_Command, APCI1564_DIGITAL_OP_INTERRUPT);
+ ui_InterruptData = inl_amcc(devpriv, APCI1564_DIGITAL_OP_INTERRUPT);
devpriv->tsk_Current = current;
return insn->n;
}
@@ -278,12 +260,10 @@ static int apci1564_do_insn_bits(struct comedi_device
*dev,
{
struct addi_private *devpriv = dev->private;
- s->state = inl(devpriv->i_IobaseAmcc + APCI1564_DIGITAL_OP +
- APCI1564_DIGITAL_OP_RW);
+ s->state = inl_amcc(devpriv, APCI1564_DIGITAL_OP_RW);
if (comedi_dio_update_state(s, data))
- outl(s->state, devpriv->i_IobaseAmcc + APCI1564_DIGITAL_OP +
- APCI1564_DIGITAL_OP_RW);
+ outl_amcc(devpriv, s->state, APCI1564_DIGITAL_OP_RW);
data[1] = s->state;
@@ -333,81 +313,61 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct
comedi_device *dev,
Re: [PATCH 2/2] aio: make aio_read_events_ring be aware of aio_complete
Hi Kent, Sorry for late replay. On 03/01/2014 04:52 AM, Kent Overstreet wrote: > On Fri, Feb 28, 2014 at 06:27:18PM +0800, Gu Zheng wrote: >> Commit 5ffac122dbda8(aio: Don't use ctx->tail unnecessarily) uses >> ring->tail rather than the ctx->tail, but with this change, we fetch 'tail' >> only once at the start, so that we can not be aware of adding event by >> aio_complete >> when reading events. It seems a regression. > > "Seems a regression" is not good enough. What breaks? Previously without the commit 5ffac122dbda8, we used tail from aio context to judge whether the ring buffer has events(have not been read) each time, as following: avail = (head <= ctx->tail ? ctx->tail : ctx->nr_events) - head; so that we can be aware of new events that added by aio_complete when we are reading the current ones, and we can read the new added events together. E.g. we want to read 10 events, only 8 events now, add 2 events added while we copying current 8 events to userspace, and we can read the 2 new events in the next circle. But with the commit 5ffac122dbda8, we fetch tail from ring buffer only once when we start to read events, so that we can not be aware of events that added by aio_complete while we are reading current events(e.g. copy currents events to user space). Such as the case mentioned above can only read 8 events, though these are 2 new events in the ring buffer. Is not it a regression, or am I missing something? Regards, Gu > >> So here we fetch the ring->tail in start of the loop each time to make it be >> aware of adding event from aio_complete. >> >> Signed-off-by: Gu Zheng >> --- >> fs/aio.c |6 +- >> 1 files changed, 5 insertions(+), 1 deletions(-) >> >> diff --git a/fs/aio.c b/fs/aio.c >> index 7eaa631..f5b8551 100644 >> --- a/fs/aio.c >> +++ b/fs/aio.c >> @@ -1029,10 +1029,14 @@ static long aio_read_events_ring(struct kioctx *ctx, >> struct io_event *ev; >> struct page *page; >> >> -avail = (head <= tail ? tail : ctx->nr_events) - head; >> +ring = kmap_atomic(ctx->ring_pages[0]); >> +tail = ring->tail; >> +kunmap_atomic(ring); >> + >> if (head == tail) >> break; >> >> +avail = (head <= tail ? tail : ctx->nr_events) - head; >> avail = min(avail, nr - ret); >> avail = min_t(long, avail, AIO_EVENTS_PER_PAGE - >> ((head + AIO_EVENTS_OFFSET) % AIO_EVENTS_PER_PAGE)); >> -- >> 1.7.7 >> > -- 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/
fs: pipe: memory corruption in inode_cache
Hi all, While fuzzing with trinity inside a KVM tools guest running latest -next kernel I've stumbled on the following spew: [ 315.799264] = [ 315.800055] BUG inode_cache (Tainted: GB W ): Object padding overwritten [ 315.800055] - [ 315.800055] [ 315.800055] INFO: 0x880229a67030-0x880229a67033. First byte 0x1e instead of 0x5a [ 315.800055] INFO: Allocated in alloc_inode+0x41/0xa0 age=2328 cpu=33 pid=9788 [ 315.800055] __slab_alloc+0x413/0x4d0 [ 315.800055] kmem_cache_alloc+0x12f/0x2e0 [ 315.800055] alloc_inode+0x41/0xa0 [ 315.800055] new_inode_pseudo+0x1b/0x70 [ 315.800055] get_pipe_inode+0x1c/0xf0 [ 315.800055] create_pipe_files+0x2c/0x170 [ 315.800055] __do_pipe_flags+0x41/0xf0 [ 315.800055] SyS_pipe2+0x2b/0xb0 [ 315.800055] tracesys+0xdd/0xe2 [ 315.800055] INFO: Freed in free_inode_nonrcu+0x18/0x20 age=2516 cpu=33 pid=9819 [ 315.800055] __slab_free+0x41/0x5e0 [ 315.800055] kmem_cache_free+0x27b/0x380 [ 315.800055] free_inode_nonrcu+0x18/0x20 [ 315.800055] destroy_inode+0x4b/0x70 [ 315.800055] evict+0x188/0x1a0 [ 315.800055] iput_final+0x163/0x180 [ 315.814864] iput+0x4f/0x60 [ 315.814864] dentry_iput+0xc8/0xf0 [ 315.814864] d_kill+0x4e/0xc0 [ 315.814864] dentry_kill+0xdb/0x100 [ 315.814864] dput+0x10d/0x130 [ 315.814864] __fput+0x2a7/0x2c0 [ 315.814864] fput+0xe/0x10 [ 315.814864] task_work_run+0xae/0xf0 [ 315.814864] do_notify_resume+0x8e/0xe0 [ 315.814864] int_signal+0x12/0x17 [ 315.814864] INFO: Slab 0xea0008a69800 objects=23 used=13 fp=0x880229a62568 flags=0x6f80004081 [ 315.814864] INFO: Object 0x880229a66ae0 @offset=27360 fp=0x880229a66588 [ 315.814864] [ 315.814864] Bytes b4 880229a66ad0: 56 ff ff ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a V... [ 315.814864] Object 880229a66ae0: 80 11 04 00 ff bf ff ff 00 00 00 00 00 00 00 00 [ 315.814864] Object 880229a66af0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 315.814864] Object 880229a66b00: 80 3b 51 88 ff ff ff ff 48 91 07 29 01 88 ff ff .;Q.H..) [ 315.814864] Object 880229a66b10: f0 6c a6 29 02 88 ff ff 00 00 00 00 00 00 00 00 .l.) [ 315.814864] Object 880229a66b20: 89 08 00 00 00 00 00 00 01 00 00 00 00 00 00 00 [ 315.814864] Object 880229a66b30: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 [ 315.814864] Object 880229a66b40: 00 87 93 03 00 00 00 00 01 00 00 00 00 00 00 00 [ 315.814864] Object 880229a66b50: 00 87 93 03 00 00 00 00 01 00 00 00 00 00 00 00 [ 315.814864] Object 880229a66b60: 00 87 93 03 00 00 00 00 12 00 12 00 ad 4e ad de .N.. [ 315.814864] Object 880229a66b70: ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff [ 315.814864] Object 880229a66b80: e8 4d ae 86 ff ff ff ff 00 00 00 00 00 00 00 00 .M.. [ 315.814864] Object 880229a66b90: 00 00 00 00 00 00 00 00 f7 63 77 85 ff ff ff ff .cw. [ 315.814864] Object 880229a66ba0: 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 !... [ 315.814864] Object 880229a66bb0: 00 00 00 00 0c 00 00 00 00 00 00 00 00 00 00 00 [ 315.814864] Object 880229a66bc0: 60 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 `... [ 315.814864] Object 880229a66bd0: 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .N.. [ 315.814864] Object 880229a66be0: ff ff ff ff ff ff ff ff 20 42 76 87 ff ff ff ff Bv. [ 315.814864] Object 880229a66bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 315.814864] Object 880229a66c00: 66 fe 6b 85 ff ff ff ff 21 00 00 00 00 00 00 00 f.k.!... [ 315.814864] Object 880229a66c10: 00 00 00 00 00 00 00 00 18 6c a6 29 02 88 ff ff .l.) [ 315.814864] Object 880229a66c20: 18 6c a6 29 02 88 ff ff 00 00 00 00 00 00 00 00 .l.) [ 315.814864] Object 880229a66c30: 00 00 00 00 00 00 00 00 c8 6b a6 29 02 88 ff ff .k.) [ 315.814864] Object 880229a66c40: f0 4d ae 86 ff ff ff ff 00 00 00 00 00 00 00 00 .M.. [ 315.814864] Object 880229a66c50: 00 00 00 00 00 00 00 00 0f 64 77 85 ff ff ff ff .dw. [ 315.814864] Object 880229a66c60: 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 !... [ 315.814864] Object 880229a66c70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 315.814864] Object 880229a66c80: 00 00 00 00 00 00 00 00 88 6c a6 29 02 88 ff ff .l.) [ 315.814864] Object 880229a66c90: 88 6c a6 29 02 88 ff ff 98 6c a6 29 02 88 ff ff .l.).l.) [ 315.814864] Object 880229a66ca0:
Re: [PATCH -next] cris: cpuinfo_op should depend on CONFIG_PROC_FS
On Mon, Mar 03, 2014 at 11:16:54AM +1100, Stephen Rothwell wrote:
> Hi Geert,
>
> On Sun, 2 Mar 2014 11:34:39 +0100 Geert Uytterhoeven
> wrote:
> >
> > Now allnoconfig started disabling CONFIG_PROC_FS:
> >
> > arch/cris/kernel/built-in.o:(.rodata+0xc): undefined reference to
> > `show_cpuinfo'
> > make: *** [vmlinux] Error 1
> >
> > Signed-off-by: Geert Uytterhoeven
>
> Added as a merge fix to (for the akpm-current tree) linux-next from today.
>
> [rest left here for Andrew and Josh ...]
Reviewed-by: Josh Triplett
> > http://kisskb.ellerman.id.au/kisskb/buildresult/10665698/
> >
> > arch/cris/kernel/setup.c |2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/cris/kernel/setup.c b/arch/cris/kernel/setup.c
> > index 32c3d248868e..905b70ea9939 100644
> > --- a/arch/cris/kernel/setup.c
> > +++ b/arch/cris/kernel/setup.c
> > @@ -165,6 +165,7 @@ void __init setup_arch(char **cmdline_p)
> > strcpy(init_utsname()->machine, cris_machine_name);
> > }
> >
> > +#ifdef CONFIG_PROC_FS
> > static void *c_start(struct seq_file *m, loff_t *pos)
> > {
> > return *pos < nr_cpu_ids ? (void *)(int)(*pos + 1) : NULL;
> > @@ -188,6 +189,7 @@ const struct seq_operations cpuinfo_op = {
> > .stop = c_stop,
> > .show = show_cpuinfo,
> > };
> > +#endif /* CONFIG_PROC_FS */
> >
> > static int __init topology_init(void)
> > {
> > --
> > 1.7.9.5
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
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/3] regulator: s2mps11: Don't store registered regulators in state container
On Fri, Feb 28, 2014 at 11:01:48AM +0100, Krzysztof Kozlowski wrote: > Regulators registered by devm_regulator_register() do not have to be > stored in state container because they are never dereferenced later. > The array of regulator_dev can be safely removed from state container. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 3/3] regulator: s2mps11: Copy supported regulators from initconst
On Fri, Feb 28, 2014 at 11:01:50AM +0100, Krzysztof Kozlowski wrote: > Add __initconst to 'regulator_desc' array with supported regulators. > During probe choose how many and which regulators will be supported > according to device ID. Then copy the 'regulator_desc' array to > allocated memory so the regulator core can use it. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 2/3] regulator: s2mps11: Constify regulator_desc array
On Fri, Feb 28, 2014 at 11:01:49AM +0100, Krzysztof Kozlowski wrote: > Constify the regulator_desc 'regulators' array. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v9 1/3] mmc: sdhci-msm: Qualcomm SDHCI binding documentation
On Fri, Feb 28, 2014 at 3:24 AM, Georgi Djakov wrote:
> This platform driver adds the initial support of Secure
> Digital Host Controller Interface compliant controller
> found in Qualcomm chipsets.
>
Hi Georgi,
When testing this I was confused by the warnings from sdhci not finding vmmc
and vqmmc. Is the power irq something Qualcomm specific or is there any other
reason why the sdhci provided regulator functionality can't be used?
Regarding the usage of the regulator api here, I think you should call
regulator_set_voltage() with your default voltage when you acquire the
regulator handles; then your power enable/disable functions will be simpler and
you should be able to clean up the power irq function further.
>
[...]
> +/* This structure keeps information per regulator */
> +struct sdhci_msm_reg_data {
> + struct regulator *reg;
> + const char *name;
> + /* Voltage level values */
> + u32 low_vol_level;
> + u32 high_vol_level;
Is there a reason why these should be different? In your example and the other
cases I've seen they are always 2.95V and 1.8V.
>
[...]
> +
> +static int sdhci_msm_vreg_enable(struct device *dev,
> +struct sdhci_msm_reg_data *vreg)
> +{
> + int ret = 0;
> +
> + if (!regulator_is_enabled(vreg->reg)) {
> + /* Set voltage level */
> + ret = regulator_set_voltage(vreg->reg, vreg->high_vol_level,
> + vreg->high_vol_level);
> + if (ret)
> + return ret;
So when you enable voltage in the irq handler or in probe, you will go to "high
voltage", then you might lower this directly again.
> + }
> +
> + ret = regulator_enable(vreg->reg);
> + if (ret) {
> + dev_err(dev, "Failed to enable regulator %s (%d)\n",
> + vreg->name, ret);
> + }
> +
> + return ret;
> +}
> +
> +static int sdhci_msm_vreg_disable(struct device *dev,
> + struct sdhci_msm_reg_data *vreg)
> +{
> + int ret = 0;
> +
> + if (!regulator_is_enabled(vreg->reg))
> + return ret;
> +
> + /* Set min. voltage to 0 */
> + ret = regulator_set_voltage(vreg->reg, 0, vreg->high_vol_level);
> + if (ret)
> + return ret;
Why do you set the voltage to 0 here?
> +
> + ret = regulator_disable(vreg->reg);
> + if (ret) {
> + dev_err(dev, "Failed to disable regulator %s (%d)\n",
> + vreg->name, ret);
> + }
> +
> + return ret;
> +}
> +
> +static int sdhci_msm_setup_vreg(struct sdhci_msm_host *msm_host, bool enable)
> +{
Instead of having a function with one big if statement of which path you came
from you should have two functions for this.
> + int ret, i;
> + struct sdhci_msm_reg_data *vreg_table[2];
> +
> + vreg_table[0] = _host->pdata.vdd;
> + vreg_table[1] = _host->pdata.vdd_io;
> +
> + for (i = 0; i < ARRAY_SIZE(vreg_table); i++) {
> + if (enable)
> + ret = sdhci_msm_vreg_enable(_host->pdev->dev,
> + vreg_table[i]);
> + else
> + ret = sdhci_msm_vreg_disable(_host->pdev->dev,
> +vreg_table[i]);
> + if (ret)
> + return ret;
> + }
This seems to a complicated way of saying:
if (enable) {
sdhci_msm_vreg_enable(vdd)
sdhci_msm_vreg_enable(vdd_io)
} else {
sdhci_msm_vreg_disable(vdd)
sdhci_msm_vreg_disable(vdd_io)
}
Do you plan to add more regulators here?
> +
> + return 0;
> +}
> +
> +static int sdhci_msm_vreg_init(struct device *dev,
> + struct sdhci_msm_pltfm_data *pdata)
> +{
> + struct sdhci_msm_reg_data *vdd_reg = >vdd;
> + struct sdhci_msm_reg_data *vdd_io_reg = >vdd_io;
> +
> + vdd_reg->reg = devm_regulator_get(dev, vdd_reg->name);
> + if (IS_ERR(vdd_reg->reg))
> + return PTR_ERR(vdd_reg->reg);
> +
> + vdd_io_reg->reg = devm_regulator_get(dev, vdd_io_reg->name);
> + if (IS_ERR(vdd_io_reg->reg))
> + return PTR_ERR(vdd_io_reg->reg);
> +
> + return 0;
> +}
> +
> +static irqreturn_t sdhci_msm_pwr_irq(int irq, void *data)
> +{
> + struct sdhci_host *host = (struct sdhci_host *)data;
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = pltfm_host->priv;
> + u8 irq_status;
> + u8 irq_ack = 0;
> + int ret = 0;
> +
> + irq_status = readb_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
> + dev_dbg(mmc_dev(msm_host->mmc), "%s: Received IRQ(%d), status=0x%x\n",
> + mmc_hostname(msm_host->mmc), irq, irq_status);
> +
> + /* Clear the interrupt */
> + writeb_relaxed(irq_status,
Re: fs: gpf in simple_setattr
On 03/01/2014 10:35 PM, Linus Torvalds wrote: On Sat, Mar 1, 2014 at 2:05 PM, Sasha Levin wrote: ping again? I've been working on it, but don't see an obvious issue. It does look like an access to invalid memory easily doable from userspace, so it should probably get fixed soon... It doesn't happen in mainline? Any possibility that you could try to bisect it? It might be in mainline, it just happens once in a couple of days and since I'm not usually fuzzing mainline I can't say for sure. I've tried bisecting but since I don't have a reliable way to reproduce it the bisection goes wrong pretty fast. I've tried adding some debug code in, which clearly suggests that the object is gone, but I can't pinpoint to where it disappears. 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: [PATCH] spi: core: make zero length transfer valid again
On Sat, Mar 01, 2014 at 12:40:39PM +0100, Martin Sperl wrote: > I am not sure if it might make some bus-drivers more complicated > /inefficient just to support this zero length. For most of them it should be relatively straightforward, especially as we factor things out into the core so that the drivers don't need to implement the delays at all and it's all handled in the core. > For example: the spi-bcm2835.c driver would do the following with a > spi_transfer.len == 0 in the transfer_on method: > * enables SPI and wait for interrupt completion > * the above which will trigger an interrupt > ** in the interrupt we find out that there is nothing to transfer, > so we signal completion to transfer_one, so it may continue. > * the main transfer_one will get woken up > ** it will do a delay_usecs > ** it will handle CS_CHANGE > ** it will disable SPI/reset HW again > So this implementation shows that there is a lot of inefficient > overhead/delay just to trigger a delay... You really ought to be deferring to task context to implement the delays anyway - delaying in interrupt context is rude (though doable for very short delays). I'd have expected that the enable/disable to be bypassable, unless the hardware needs to be reset between transfers this should only be happening when the device goes idle. > I guess other drivers will show similar code-artefacts and > some may even make the implicit assumption it has to be non-zero, > which would break functionality those odd devices. There's lots of stuff that's broken with individual drivers - anything that relies on cs_change is going to break with half the drivers out there. Some of this is legitimate hardware limitations (where the /CS control is out of the control of software) but a lot of it is just bugs due to people open coding things. signature.asc Description: Digital signature
linux-next: manual merge of the imx-mxs tree with the arm-soc tree
Hi Shawn,
Today's linux-next merge of the imx-mxs tree got a conflict in
arch/arm/mach-imx/Kconfig between commits ddb902cc3459 ("ARM: centralize
common multi-platform kconfig options") and 37dff0825611 ("ARM: imx6:
introduce CONFIG_SOC_IMX6 for i.MX6 common stuff") from the arm-soc tree
and commit f702c0213144 ("ARM: mach-imx: Select CONFIG_SRAM at ARCH_MXC
level") from the imx-mxs tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-imx/Kconfig
index 41ffd433f709,e45062d41fcb..
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@@ -1,12 -1,22 +1,15 @@@
config ARCH_MXC
bool "Freescale i.MX family" if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
+ select ARCH_HAS_CPUFREQ
+ select ARCH_HAS_OPP
select ARCH_REQUIRE_GPIOLIB
select ARM_CPU_SUSPEND if PM
- select ARM_PATCH_PHYS_VIRT
select CLKSRC_MMIO
- select GENERIC_ALLOCATOR
- select COMMON_CLK
- select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_CHIP
- select MIGHT_HAVE_CACHE_L2X0 if ARCH_MULTI_V6_V7
- select MULTI_IRQ_HANDLER
select PINCTRL
+ select PM_OPP if PM
select SOC_BUS
- select SPARSE_IRQ
+ select SRAM
- select USE_OF
help
Support for Freescale MXC/iMX-based family of processors
@@@ -114,10 -124,11 +117,10 @@@ config SOC_IMX3
config SOC_IMX35
bool
select ARCH_MXC_IOMUX_V3
- select CPU_V6K
select HAVE_EPIT
select MXC_AVIC
+ select PINCTRL_IMX35
select SMP_ON_UP if SMP
- select PINCTRL
config SOC_IMX5
bool
@@@ -775,16 -786,12 +777,11 @@@ config SOC_IMX5
help
This enables support for Freescale i.MX53 processor.
- config SOC_IMX6Q
- bool "i.MX6 Quad/DualLite support"
- select ARCH_HAS_CPUFREQ
- select ARCH_HAS_OPP
+ config SOC_IMX6
+ bool
select ARM_ERRATA_754322
- select ARM_ERRATA_764369 if SMP
select ARM_ERRATA_775420
select ARM_GIC
- select HAVE_ARM_SCU if SMP
- select HAVE_ARM_TWD if SMP
- select CPU_V7
select HAVE_IMX_ANATOP
select HAVE_IMX_GPC
select HAVE_IMX_MMDC
@@@ -793,10 -800,17 +790,16 @@@
select PL310_ERRATA_588369 if CACHE_PL310
select PL310_ERRATA_727915 if CACHE_PL310
select PL310_ERRATA_769419 if CACHE_PL310
- select PM_OPP if PM
+
+ config SOC_IMX6Q
+ bool "i.MX6 Quad/DualLite support"
+ select ARM_ERRATA_764369 if SMP
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if SMP
- select HAVE_SMP
+ select MIGHT_HAVE_PCI
+ select PCI_DOMAINS if PCI
+ select PINCTRL_IMX6Q
+ select SOC_IMX6
help
This enables support for Freescale i.MX6 Quad processor.
pgpUzw33Lh2nX.pgp
Description: PGP signature
RE: [alsa-devel] [PATCHv2 1/3] ASoC: codec: Simplify ASoC probe code.
> Looks good in general, but try to build these kinds of changes with > CONFIG_COMPILE_TEST=y and CONFIG_SND_SOC_ALL_CODECS=y before sending the > patch. There are a lot of warnings about unused variables caused by this > patch. > @Lars, Oh, yes, these are very low-level errors, I will fix them then. Thanks very much. > sound/soc/codecs/ad193x.c: In function 'ad193x_codec_probe': > sound/soc/codecs/ad193x.c:343:2: warning: 'ret' is used uninitialized in > this function [-Wuninitialized] > sound/soc/codecs/adau1373.c: In function 'adau1373_probe': > sound/soc/codecs/adau1373.c:1379:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/adav80x.c: In function 'adav80x_probe': > sound/soc/codecs/adav80x.c:804:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/ak4535.c: In function 'ak4535_probe': > sound/soc/codecs/ak4535.c:392:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/ak4535.c:391:22: warning: unused variable 'ak4535' > [-Wunused-variable] > sound/soc/codecs/ak4641.c: In function 'ak4641_probe': > sound/soc/codecs/ak4641.c:522:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/ak4642.c: In function 'ak4642_probe': > sound/soc/codecs/ak4642.c:468:6: warning: unused variable 'ret' [-Wunused- > sound/soc/codecs/ak4671.c: In function 'ak4671_probe': > sound/soc/codecs/ak4671.c:620:2: warning: 'ret' is used uninitialized in > this function [-Wuninitialized] > sound/soc/codecs/cs42l52.c: In function 'cs42l52_probe': > sound/soc/codecs/cs42l52.c:1125:2: warning: 'ret' is used uninitialized in > this function [-Wuninitialized] > sound/soc/codecs/cs42l73.c: In function 'cs42l73_probe': > sound/soc/codecs/cs42l73.c:1363:2: warning: 'ret' is used uninitialized in > this function [-Wuninitialized] > sound/soc/codecs/da7210.c: In function 'da7210_probe': > sound/soc/codecs/da7210.c:1074:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/da7213.c: In function 'da7213_probe': > sound/soc/codecs/da7213.c:1396:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/da732x.c: In function 'da732x_probe': > sound/soc/codecs/da732x.c:1522:1: warning: label 'err' defined but not used > [-Wunused-label] > sound/soc/codecs/da9055.c: In function 'da9055_probe': > sound/soc/codecs/da9055.c:1386:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/max9850.c: In function 'max9850_probe': > sound/soc/codecs/max9850.c:315:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/ml26124.c: In function 'ml26124_probe': > sound/soc/codecs/ml26124.c:590:23: warning: unused variable 'priv' > [-Wunused-variable] > sound/soc/codecs/ml26124.c:589:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/rt5631.c: In function 'rt5631_probe': > sound/soc/codecs/rt5631.c:1573:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/rt5640.c: In function 'rt5640_probe': > sound/soc/codecs/rt5640.c:1939:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/ssm2518.c: In function 'ssm2518_probe': > sound/soc/codecs/ssm2518.c:652:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/ssm2518.c:651:18: warning: unused variable 'ssm2518' > [-Wunused-variable] > sound/soc/codecs/sta32x.c: In function 'sta32x_probe': > sound/soc/codecs/sta32x.c:940:1: warning: label 'err' defined but not used > [-Wunused-label] > sound/soc/codecs/sta529.c: In function 'sta529_probe': > sound/soc/codecs/sta529.c:326:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/sta529.c:325:17: warning: unused variable 'sta529' > [-Wunused-variable] > sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_probe': > sound/soc/codecs/tlv320aic23.c:562:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/wm8510.c: In function 'wm8510_probe': > sound/soc/codecs/wm8510.c:599:2: warning: 'ret' is used uninitialized in > this function [-Wuninitialized] > sound/soc/codecs/wm8523.c: In function 'wm8523_probe': > sound/soc/codecs/wm8523.c:395:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/wm8728.c: In function 'wm8728_probe': > sound/soc/codecs/wm8728.c:236:2: warning: 'ret' is used uninitialized in > this function [-Wuninitialized] > sound/soc/codecs/wm8900.c: In function 'wm8900_probe': > sound/soc/codecs/wm8900.c:1181:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/wm8903.c: In function 'wm8903_probe': > sound/soc/codecs/wm8903.c:1907:2: warning: 'ret' is used uninitialized in > this function [-Wuninitialized] > sound/soc/codecs/wm8904.c: In function 'wm8904_probe': > sound/soc/codecs/wm8904.c:2051:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/wm8961.c: In function 'wm8961_probe': > sound/soc/codecs/wm8961.c:839:6: warning: unused variable 'ret' > [-Wunused-variable] > sound/soc/codecs/wm8978.c: In
Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop
On 2014/3/3 9:47, H. Peter Anvin wrote: > We are not removing BOOT_BIOS... whether or not we have it on buy default is > another matter. Right, I meant I remove BOOT_BIOS from my second patch if needed. Thanks, -Aubrey > > On March 2, 2014 5:36:02 PM PST, "Li, Aubrey" > wrote: >> On 2014/3/3 8:18, H. Peter Anvin wrote: >>> On 03/02/2014 04:07 PM, Matthew Garrett wrote: On Mon, Mar 03, 2014 at 07:23:06AM +0800, Li, Aubrey wrote: > Windows doesn't do because there is no 32/64 mixed windows and EFI >> on > the planet. Since the silicon is actually 64 bit, I failed to see a > reason to refuse the user install 64bit linux on it. So we >> encountered a > case windows didn't. And we'll call the 32 bit EFI call, so what's the problem? >> >> No problem after Fleming's mixed mode is landed. >> > So, you didn't mention BOOT_BIOS, if you don't want to add >> BOOT_BIOS, > and you also don't like DMI entires, how do you want to deal with >> the > machines requiring BOOT_BIOS to reboot their machine? I was planning on ignoring them. >> >> Well, I'm fine to ignore BOOT_BIOS because I don't have one in hand, >> but >> I'll bother you again with the same logic when I have one, heihei. >> Do you need me to refine the patch to remove BOOT_BIOS? >> >>> >>> I suspect we'll never get away from having a DMI table, if nothing >> else >>> because we can't test enough, but the current situation where it >> seems >>> like we need to add every since Dell box to the DMI table is clearly >> broken. >>> >>> -hpa >>> >> Agree, definitely. >> >> Thanks, >> -Aubrey > -- 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] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop
We are not removing BOOT_BIOS... whether or not we have it on buy default is another matter. On March 2, 2014 5:36:02 PM PST, "Li, Aubrey" wrote: >On 2014/3/3 8:18, H. Peter Anvin wrote: >> On 03/02/2014 04:07 PM, Matthew Garrett wrote: >>> On Mon, Mar 03, 2014 at 07:23:06AM +0800, Li, Aubrey wrote: >>> Windows doesn't do because there is no 32/64 mixed windows and EFI >on the planet. Since the silicon is actually 64 bit, I failed to see a reason to refuse the user install 64bit linux on it. So we >encountered a case windows didn't. >>> >>> And we'll call the 32 bit EFI call, so what's the problem? > >No problem after Fleming's mixed mode is landed. > >>> So, you didn't mention BOOT_BIOS, if you don't want to add >BOOT_BIOS, and you also don't like DMI entires, how do you want to deal with >the machines requiring BOOT_BIOS to reboot their machine? >>> >>> I was planning on ignoring them. >>> > >Well, I'm fine to ignore BOOT_BIOS because I don't have one in hand, >but >I'll bother you again with the same logic when I have one, heihei. >Do you need me to refine the patch to remove BOOT_BIOS? > >> >> I suspect we'll never get away from having a DMI table, if nothing >else >> because we can't test enough, but the current situation where it >seems >> like we need to add every since Dell box to the DMI table is clearly >broken. >> >> -hpa >> >Agree, definitely. > >Thanks, >-Aubrey -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot sequence loop
On 2014/3/3 8:18, H. Peter Anvin wrote: > On 03/02/2014 04:07 PM, Matthew Garrett wrote: >> On Mon, Mar 03, 2014 at 07:23:06AM +0800, Li, Aubrey wrote: >> >>> Windows doesn't do because there is no 32/64 mixed windows and EFI on >>> the planet. Since the silicon is actually 64 bit, I failed to see a >>> reason to refuse the user install 64bit linux on it. So we encountered a >>> case windows didn't. >> >> And we'll call the 32 bit EFI call, so what's the problem? No problem after Fleming's mixed mode is landed. >> >>> So, you didn't mention BOOT_BIOS, if you don't want to add BOOT_BIOS, >>> and you also don't like DMI entires, how do you want to deal with the >>> machines requiring BOOT_BIOS to reboot their machine? >> >> I was planning on ignoring them. >> Well, I'm fine to ignore BOOT_BIOS because I don't have one in hand, but I'll bother you again with the same logic when I have one, heihei. Do you need me to refine the patch to remove BOOT_BIOS? > > I suspect we'll never get away from having a DMI table, if nothing else > because we can't test enough, but the current situation where it seems > like we need to add every since Dell box to the DMI table is clearly broken. > > -hpa > Agree, definitely. Thanks, -Aubrey -- 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] USB AX88179/178A: Support D-Link DUB-1312
From: Gerry Demaret Date: Fri, 28 Feb 2014 18:50:46 +0100 > Add the USB device ID for the D-Link DUB-1312 USB 3.0 to Gigabit Ethernet > Adapter to the AX88179/178A driver. > > Signed-off-by: Gerry Demaret Applied, thank you. -- 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 2/4] ACPICA: Introduce new acpi_os_physical_table_add OS callback
Hi, Thomas
I have a patch series that can cleanup the ACPICA table manager, and change the
acpi_load_table into the following style:
acpi_status acpi_install_table(acpi_physical_address address, char *signature,
u8 flags, bool override);
For the flags parameter, it will be:
ACPI_TABLE_ORIGIN_EXTERNAL_PHYSICAL (renamed from ACPI_TABLE_ORIGIN_UNKNOWN)
ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL (renamed from ACPI_TABLE_ORIGIN_OVERRIDE)
ACPI_TABLE_ORIGIN_INTERNAL_PHYSICAL (renamed from ACPI_TABLE_ORIGIN_MAPPED)
ACPI_TABLE_ORIGIN_INTERNAL_LOGICAL (renamed from ACPI_TABLE_ORIGIN_ALLOCATED)
So that we can have the following advantages:
1. the table signature can be validate in one single function.
2. the table checksum can always be validated before installing it to
acpi_gbl_root_table_list.
3. acpi_os_table_override() and acpi_os_phsycal_table_override() can be merged
4. for acpi_load_table (renamed to acpi_install_table()) invocations, if it is
invoked by OSPM, override can be avoided.
5. part of the acpi_tb_parse_root_table() code can be merged with the
acpi_load_table() by invoking same installing API with flags specified.
And with this API, you don't have to introduce code into ACPICA to achieve
acpi_os_physical_table_add().
You only need to invoke an OSPM only initialization step after
acpi_initialize_tables(), inside of which, you can invoke acpi_install_table()
to install new arbitrary tables serving for the purposes of OSPM.
For your cases, I think you can implement the code in this way:
Int __init acpi_table_init(void)
{
Status = acpi_initialize_tables()
/* add all tables, if they haven't been overridden, they will be newly
installed */
for (no = 0; no < no_of_overridden_tables; no++) {
acpi_install_table(the_phsycail_address, NULL,
ACPI_TABLE_ORIGIN_EXTERNAL_PHYSICAL, false);
}
}
This function also has been carefully redesigned to ensure:
1. override can avoided for the newly added table.
2. checksum can be verified before adding it to the acpi_gbl_root_table_list,
and it will only be verified once per table.
3. No need to save the table no that has already been physically overridden, it
will be taken care by the new interfaces.
I can send out the cleanup series for you to confirm.
Thanks and best regards
-Lv
> -Original Message-
> From: Thomas Renninger [mailto:tr...@suse.de]
> Sent: Saturday, March 01, 2014 1:24 AM
> To: Moore, Robert; Zheng, Lv; Box, David E; Wysocki, Rafael J
> Cc: Thomas Renninger; h...@zytor.com; t...@linutronix.de;
> c...@conrad-kostecki.de; linux-kernel@vger.kernel.org; x...@kernel.org;
> mi...@redhat.com; r...@rjwysocki.net; de...@acpica.org
> Subject: [PATCH 2/4] ACPICA: Introduce new acpi_os_physical_table_add OS
> callback
>
> This one allows OS to add arbitrary ACPI tables.
>
> ToDo: It should get checked whether a table with the same signature already
> exists and if this is the case, adding should not happen.
>
> Signed-off-by: Thomas Renninger
> CC: h...@zytor.com
> CC: t...@linutronix.de
> CC: c...@conrad-kostecki.de
> CC: linux-kernel@vger.kernel.org
> CC: x...@kernel.org
> CC: mi...@redhat.com
> CC: r...@rjwysocki.net
> CC: de...@acpica.org
> ---
> drivers/acpi/acpica/tbutils.c | 36
> include/acpi/acpiosxf.h |6 ++
> 2 files changed, 42 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
> index 6412d3c..a819d198 100644
> --- a/drivers/acpi/acpica/tbutils.c
> +++ b/drivers/acpi/acpica/tbutils.c
> @@ -453,6 +453,8 @@ static acpi_status
> acpi_tb_validate_xsdt(acpi_physical_address xsdt_address)
> *
>
> **/
>
> +#define ACPI_MAX_TABLE_ADD 64
> +
> acpi_status __init acpi_tb_parse_root_table(acpi_physical_address
> rsdp_address)
> {
> struct acpi_table_rsdp *rsdp;
> @@ -623,5 +625,39 @@ acpi_status __init
> acpi_tb_parse_root_table(acpi_physical_address rsdp_address)
> }
> }
>
> + /*
> + * ACPI Table Add:
> + * Allow the OS to add additional tables to the global root table list
> + */
> + for (i = 0; i < ACPI_MAX_TABLE_ADD; i++) {
> + int tmp, k;
> + table_entry_size = 0;
> + address = 0;
> + status = acpi_os_physical_table_add(,
> + _entry_size);
> + if (status == AE_OK && table_entry_size && address) {
> + table = acpi_os_map_memory(address, table_entry_size);
> + for (k = 2; k <
> acpi_gbl_root_table_list.current_table_count; k++) {
> + /*
> + Always add SSDTs. Only allow adding of other
> + tables if none of such a signature already
> + exists. Use the override interface
[PATCH 02/13] perf ui/gtk: Reuse generic __hpp__fmt() code
The __hpp__color_fmt used in the gtk code can be replace by the
generic code with small change in print_fn callback.
This is a preparation to upcoming changes and no functional changes
intended.
Cc: Jiri Olsa
Cc: Pekka Enberg
Signed-off-by: Namhyung Kim
---
tools/perf/ui/gtk/hists.c | 73 +++
tools/perf/ui/hist.c | 9 ++
tools/perf/util/hist.h| 6
3 files changed, 19 insertions(+), 69 deletions(-)
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 5b95c44f3435..3dab00e748f2 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -8,16 +8,22 @@
#define MAX_COLUMNS32
-static int __percent_color_snprintf(char *buf, size_t size, double percent)
+static int __percent_color_snprintf(char *buf, size_t size, const char *fmt,
...)
{
int ret = 0;
+ va_list args;
+ double percent;
const char *markup;
+ va_start(args, fmt);
+ percent = va_arg(args, double);
+ va_end(args);
+
markup = perf_gtk__get_percent_color(percent);
if (markup)
ret += scnprintf(buf, size, markup);
- ret += scnprintf(buf + ret, size - ret, " %6.2f%%", percent);
+ ret += scnprintf(buf + ret, size - ret, fmt, percent);
if (markup)
ret += scnprintf(buf + ret, size - ret, "");
@@ -25,66 +31,6 @@ static int __percent_color_snprintf(char *buf, size_t size,
double percent)
return ret;
}
-
-static int __hpp__color_fmt(struct perf_hpp *hpp, struct hist_entry *he,
- u64 (*get_field)(struct hist_entry *))
-{
- int ret;
- double percent = 0.0;
- struct hists *hists = he->hists;
- struct perf_evsel *evsel = hists_to_evsel(hists);
-
- if (hists->stats.total_period)
- percent = 100.0 * get_field(he) / hists->stats.total_period;
-
- ret = __percent_color_snprintf(hpp->buf, hpp->size, percent);
-
- if (perf_evsel__is_group_event(evsel)) {
- int prev_idx, idx_delta;
- struct hist_entry *pair;
- int nr_members = evsel->nr_members;
-
- prev_idx = perf_evsel__group_idx(evsel);
-
- list_for_each_entry(pair, >pairs.head, pairs.node) {
- u64 period = get_field(pair);
- u64 total = pair->hists->stats.total_period;
-
- evsel = hists_to_evsel(pair->hists);
- idx_delta = perf_evsel__group_idx(evsel) - prev_idx - 1;
-
- while (idx_delta--) {
- /*
-* zero-fill group members in the middle which
-* have no sample
-*/
- ret += __percent_color_snprintf(hpp->buf + ret,
- hpp->size - ret,
- 0.0);
- }
-
- percent = 100.0 * period / total;
- ret += __percent_color_snprintf(hpp->buf + ret,
- hpp->size - ret,
- percent);
-
- prev_idx = perf_evsel__group_idx(evsel);
- }
-
- idx_delta = nr_members - prev_idx - 1;
-
- while (idx_delta--) {
- /*
-* zero-fill group members at last which have no sample
-*/
- ret += __percent_color_snprintf(hpp->buf + ret,
- hpp->size - ret,
- 0.0);
- }
- }
- return ret;
-}
-
#define __HPP_COLOR_PERCENT_FN(_type, _field)
\
static u64 he_get_##_field(struct hist_entry *he)
\
{
\
@@ -95,7 +41,8 @@ static int perf_gtk__hpp_color_##_type(struct perf_hpp_fmt
*fmt __maybe_unused,
struct perf_hpp *hpp,
\
struct hist_entry *he)
\
{
\
- return __hpp__color_fmt(hpp, he, he_get_##_field);
\
+ return __hpp__fmt(hpp, he, he_get_##_field, " %6.2f%%",
\
+ __percent_color_snprintf, true);
\
}
__HPP_COLOR_PERCENT_FN(overhead, period)
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index 6094562c9523..085353435f07 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -8,12
[PATCH 01/13] perf ui/stdio: Fix invalid output on event group report
When some of group member has 0 overhead, it printed previous
percentage instead of 0.00%. It's because passing integer 0 as a
percent rather than double 0.0 so the remaining bits came from
garbage. The TUI and GTK don't have this problem since they pass 0.0.
Before:
# Samples: 845 of event 'anon group { cycles, cache-references, cache-misses
}'
# Event count (approx.): 174775051
#
# Overhead Samples
#
#
20.32% 8.58% 73.51%45 30 138
6.87% 6.87% 6.87%21 0 0
5.29% 0.31% 0.31%10 1 0
1.89% 1.89% 1.89% 6 0 0
1.76% 1.76% 1.76% 2 0 0
After:
# Overhead Samples
#
#
20.32% 8.58% 73.51%45 30 138
6.87% 0.00% 0.00%21 0 0
5.29% 0.31% 0.00%10 1 0
1.89% 0.00% 0.00% 6 0 0
1.76% 0.00% 0.00% 2 0 0
Signed-off-by: Namhyung Kim
---
tools/perf/ui/hist.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index 78f4c92e9b73..6094562c9523 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -52,8 +52,15 @@ static int __hpp__fmt(struct perf_hpp *hpp, struct
hist_entry *he,
* zero-fill group members in the middle which
* have no sample
*/
- ret += print_fn(hpp->buf + ret, hpp->size - ret,
- fmt, 0);
+ if (fmt_percent) {
+ ret += print_fn(hpp->buf + ret,
+ hpp->size - ret,
+ fmt, 0.0);
+ } else {
+ ret += print_fn(hpp->buf + ret,
+ hpp->size - ret,
+ fmt, 0ULL);
+ }
}
if (fmt_percent)
@@ -72,8 +79,13 @@ static int __hpp__fmt(struct perf_hpp *hpp, struct
hist_entry *he,
/*
* zero-fill group members at last which have no sample
*/
- ret += print_fn(hpp->buf + ret, hpp->size - ret,
- fmt, 0);
+ if (fmt_percent) {
+ ret += print_fn(hpp->buf + ret, hpp->size - ret,
+ fmt, 0.0);
+ } else {
+ ret += print_fn(hpp->buf + ret, hpp->size - ret,
+ fmt, 0ULL);
+ }
}
}
return ret;
--
1.7.11.7
--
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 06/13] perf tools: Count periods of filtered entries separately
Currently if a sample was filtered by command line option, it just
dropped. But this affects final output in that the percentage can be
different since the filtered entries were not included to the total.
But user might want to see the original percentages when filter
applied so add new total_filtered_period filed to hists->stats in
order to be controlled by user later. It doesn't change the current
behavior yet.
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 2 +-
tools/perf/util/event.c | 22 ++
tools/perf/util/hist.c | 10 ++
tools/perf/util/hist.h | 10 ++
tools/perf/util/symbol.h| 2 +-
5 files changed, 24 insertions(+), 22 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index d882b6f96411..5f7f1a332186 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -223,7 +223,7 @@ static int process_sample_event(struct perf_tool *tool,
return -1;
}
- if (al.filtered || (rep->hide_unresolved && al.sym == NULL))
+ if (rep->hide_unresolved && al.sym == NULL)
return 0;
if (rep->cpu_list && !test_bit(sample->cpu, rep->cpu_bitmap))
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index b0f3ca850e9e..21aa8c6248ee 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -3,6 +3,7 @@
#include "debug.h"
#include "machine.h"
#include "sort.h"
+#include "hist.h"
#include "string.h"
#include "strlist.h"
#include "thread.h"
@@ -661,7 +662,7 @@ void thread__find_addr_map(struct thread *thread,
al->thread = thread;
al->addr = addr;
al->cpumode = cpumode;
- al->filtered = false;
+ al->filtered = 0;
if (machine == NULL) {
al->map = NULL;
@@ -687,11 +688,11 @@ void thread__find_addr_map(struct thread *thread,
if ((cpumode == PERF_RECORD_MISC_GUEST_USER ||
cpumode == PERF_RECORD_MISC_GUEST_KERNEL) &&
!perf_guest)
- al->filtered = true;
+ al->filtered |= (1 << HIST_FILTER__GUEST);
if ((cpumode == PERF_RECORD_MISC_USER ||
cpumode == PERF_RECORD_MISC_KERNEL) &&
!perf_host)
- al->filtered = true;
+ al->filtered |= (1 << HIST_FILTER__HOST);
return;
}
@@ -748,9 +749,6 @@ int perf_event__preprocess_sample(const union perf_event
*event,
if (thread == NULL)
return -1;
- if (thread__is_filtered(thread))
- goto out_filtered;
-
dump_printf(" ... thread: %s:%d\n", thread__comm_str(thread),
thread->tid);
/*
* Have we already created the kernel maps for this machine?
@@ -765,6 +763,10 @@ int perf_event__preprocess_sample(const union perf_event
*event,
thread__find_addr_map(thread, machine, cpumode, MAP__FUNCTION,
sample->ip, al);
+
+ if (thread__is_filtered(thread))
+ al->filtered |= (1 << HIST_FILTER__THREAD);
+
dump_printf(" .. dso: %s\n",
al->map ? al->map->dso->long_name :
al->level == 'H' ? "[hypervisor]" : "");
@@ -780,7 +782,7 @@ int perf_event__preprocess_sample(const union perf_event
*event,
(dso->short_name != dso->long_name &&
strlist__has_entry(symbol_conf.dso_list,
dso->long_name)
- goto out_filtered;
+ al->filtered |= (1 << HIST_FILTER__DSO);
al->sym = map__find_symbol(al->map, al->addr,
machine->symbol_filter);
@@ -789,11 +791,7 @@ int perf_event__preprocess_sample(const union perf_event
*event,
if (symbol_conf.sym_list &&
(!al->sym || !strlist__has_entry(symbol_conf.sym_list,
al->sym->name)))
- goto out_filtered;
-
- return 0;
+ al->filtered |= (1 << HIST_FILTER__SYMBOL);
-out_filtered:
- al->filtered = true;
return 0;
}
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 0466efa71140..d0c40897c955 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -13,13 +13,6 @@ static bool hists__filter_entry_by_thread(struct hists
*hists,
static bool hists__filter_entry_by_symbol(struct hists *hists,
struct hist_entry *he);
-enum hist_filter {
- HIST_FILTER__DSO,
- HIST_FILTER__THREAD,
- HIST_FILTER__PARENT,
- HIST_FILTER__SYMBOL,
-};
-
struct callchain_param callchain_param = {
.mode = CHAIN_GRAPH_REL,
.min_percent = 0.5,
@@ -330,6 +323,7 @@
[PATCH 07/13] perf hists: Add support for showing relative percentage
When filtering by thread, dso or symbol on TUI it also update total
period so that the output shows different result than no filter - the
percentage changed to relative to filtered entries only. Sometimes
this is not desired since users might expect same results with filter.
So new filtered_* fields to hists->stats to count them separately.
They'll be controlled/used by user later.
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 6 ++
tools/perf/util/hist.c | 19 +++
tools/perf/util/hist.h | 2 ++
3 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 5f7f1a332186..3f8478603d51 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -121,6 +121,8 @@ static int report__add_mem_hist_entry(struct report *rep,
struct addr_location *
evsel->hists.stats.total_period += cost;
hists__inc_nr_events(>hists, PERF_RECORD_SAMPLE);
+ if (!he->filtered)
+ evsel->hists.stats.nr_filtered_samples++;
err = hist_entry__append_callchain(he, sample);
out:
return err;
@@ -170,6 +172,8 @@ static int report__add_branch_hist_entry(struct report
*rep, struct addr_locatio
evsel->hists.stats.total_period += 1;
hists__inc_nr_events(>hists, PERF_RECORD_SAMPLE);
+ if (!he->filtered)
+ evsel->hists.stats.nr_filtered_samples++;
} else
goto out;
}
@@ -201,6 +205,8 @@ static int report__add_hist_entry(struct report *rep,
struct perf_evsel *evsel,
err = hist_entry__inc_addr_samples(he, evsel->idx, al->addr);
evsel->hists.stats.total_period += sample->period;
+ if (!he->filtered)
+ evsel->hists.stats.nr_filtered_samples++;
hists__inc_nr_events(>hists, PERF_RECORD_SAMPLE);
out:
return err;
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index d0c40897c955..743947d891bd 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -675,8 +675,8 @@ void hists__output_resort(struct hists *hists)
next = rb_first(root);
hists->entries = RB_ROOT;
- hists->nr_entries = 0;
- hists->stats.total_period = 0;
+ hists->nr_entries = hists->nr_filtered_entries = 0;
+ hists->stats.total_period = hists->stats.total_filtered_period = 0;
hists__reset_col_len(hists);
while (next) {
@@ -695,12 +695,17 @@ static void hists__remove_entry_filter(struct hists
*hists, struct hist_entry *h
if (h->filtered)
return;
- ++hists->nr_entries;
- if (h->ms.unfolded)
+ hists->nr_entries++;
+ hists->nr_filtered_entries++;
+ if (h->ms.unfolded) {
hists->nr_entries += h->nr_rows;
+ hists->nr_filtered_entries += h->nr_rows;
+ }
h->row_offset = 0;
hists->stats.total_period += h->stat.period;
+ hists->stats.total_filtered_period += h->stat.period;
hists->stats.nr_events[PERF_RECORD_SAMPLE] += h->stat.nr_events;
+ hists->stats.nr_filtered_samples += h->stat.nr_events;
hists__calc_col_len(hists, h);
}
@@ -723,7 +728,9 @@ void hists__filter_by_dso(struct hists *hists)
struct rb_node *nd;
hists->nr_entries = hists->stats.total_period = 0;
+ hists->nr_filtered_entries = hists->stats.total_filtered_period = 0;
hists->stats.nr_events[PERF_RECORD_SAMPLE] = 0;
+ hists->stats.nr_filtered_samples = 0;
hists__reset_col_len(hists);
for (nd = rb_first(>entries); nd; nd = rb_next(nd)) {
@@ -756,7 +763,9 @@ void hists__filter_by_thread(struct hists *hists)
struct rb_node *nd;
hists->nr_entries = hists->stats.total_period = 0;
+ hists->nr_filtered_entries = hists->stats.total_filtered_period = 0;
hists->stats.nr_events[PERF_RECORD_SAMPLE] = 0;
+ hists->stats.nr_filtered_samples = 0;
hists__reset_col_len(hists);
for (nd = rb_first(>entries); nd; nd = rb_next(nd)) {
@@ -787,7 +796,9 @@ void hists__filter_by_symbol(struct hists *hists)
struct rb_node *nd;
hists->nr_entries = hists->stats.total_period = 0;
+ hists->nr_filtered_entries = hists->stats.total_filtered_period = 0;
hists->stats.nr_events[PERF_RECORD_SAMPLE] = 0;
+ hists->stats.nr_filtered_samples = 0;
hists__reset_col_len(hists);
for (nd = rb_first(>entries); nd; nd = rb_next(nd)) {
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 5ccc70057934..115d2e7f0a15 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -41,6 +41,7 @@ struct events_stats {
u64 total_lost;
u64 total_invalid_chains;
u32 nr_events[PERF_RECORD_HEADER_MAX];
+ u32 nr_filtered_samples;
u32 nr_lost_warned;
[PATCH 04/13] perf ui/tui: Reuse generic __hpp__fmt() code
The __hpp__color_fmt used in the TUI code can be replace by the
generic code with small change in print_fn callback. And it also
needs to move callback function to the generic __hpp__fmt().
No functional changes intended.
Cc: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 122 ++---
tools/perf/ui/gtk/hists.c | 2 +-
tools/perf/ui/hist.c | 26 ++---
tools/perf/util/hist.h | 4 +-
4 files changed, 63 insertions(+), 91 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index b720b92eba6e..7ec871af3f6f 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -587,95 +587,52 @@ struct hpp_arg {
bool current_entry;
};
-static int __hpp__color_callchain(struct hpp_arg *arg)
+static int __hpp__overhead_callback(struct perf_hpp *hpp, bool front)
{
- if (!symbol_conf.use_callchain)
- return 0;
-
- slsmg_printf("%c ", arg->folded_sign);
- return 2;
-}
-
-static int __hpp__color_fmt(struct perf_hpp *hpp, struct hist_entry *he,
- u64 (*get_field)(struct hist_entry *),
- int (*callchain_cb)(struct hpp_arg *))
-{
- int ret = 0;
- double percent = 0.0;
- struct hists *hists = he->hists;
struct hpp_arg *arg = hpp->ptr;
- if (hists->stats.total_period)
- percent = 100.0 * get_field(he) / hists->stats.total_period;
-
- ui_browser__set_percent_color(arg->b, percent, arg->current_entry);
-
- if (callchain_cb)
- ret += callchain_cb(arg);
-
- ret += scnprintf(hpp->buf, hpp->size, "%6.2f%%", percent);
- slsmg_printf("%s", hpp->buf);
-
- if (symbol_conf.event_group) {
- int prev_idx, idx_delta;
- struct perf_evsel *evsel = hists_to_evsel(hists);
- struct hist_entry *pair;
- int nr_members = evsel->nr_members;
-
- if (nr_members <= 1)
- goto out;
+ if (arg->current_entry && arg->b->navkeypressed)
+ ui_browser__set_color(arg->b, HE_COLORSET_SELECTED);
+ else
+ ui_browser__set_color(arg->b, HE_COLORSET_NORMAL);
- prev_idx = perf_evsel__group_idx(evsel);
+ if (front) {
+ if (!symbol_conf.use_callchain)
+ return 0;
- list_for_each_entry(pair, >pairs.head, pairs.node) {
- u64 period = get_field(pair);
- u64 total = pair->hists->stats.total_period;
+ slsmg_printf("%c ", arg->folded_sign);
+ return 2;
+ }
- if (!total)
- continue;
+ return 0;
+}
- evsel = hists_to_evsel(pair->hists);
- idx_delta = perf_evsel__group_idx(evsel) - prev_idx - 1;
+static int __hpp__color_callback(struct perf_hpp *hpp, bool front
__maybe_unused)
+{
+ struct hpp_arg *arg = hpp->ptr;
- while (idx_delta--) {
- /*
-* zero-fill group members in the middle which
-* have no sample
-*/
- ui_browser__set_percent_color(arg->b, 0.0,
- arg->current_entry);
- ret += scnprintf(hpp->buf, hpp->size,
-" %6.2f%%", 0.0);
- slsmg_printf("%s", hpp->buf);
- }
+ if (!arg->current_entry || !arg->b->navkeypressed)
+ ui_browser__set_color(arg->b, HE_COLORSET_NORMAL);
+ return 0;
+}
- percent = 100.0 * period / total;
- ui_browser__set_percent_color(arg->b, percent,
- arg->current_entry);
- ret += scnprintf(hpp->buf, hpp->size,
-" %6.2f%%", percent);
- slsmg_printf("%s", hpp->buf);
+static int __hpp__slsmg_color_printf(struct perf_hpp *hpp, const char *fmt,
...)
+{
+ struct hpp_arg *arg = hpp->ptr;
+ int ret;
+ va_list args;
+ double percent;
- prev_idx = perf_evsel__group_idx(evsel);
- }
+ va_start(args, fmt);
+ percent = va_arg(args, double);
+ va_end(args);
- idx_delta = nr_members - prev_idx - 1;
+ ui_browser__set_percent_color(arg->b, percent, arg->current_entry);
- while (idx_delta--) {
- /*
-* zero-fill group members at last which have no sample
-*/
-
[PATCHSET 00/13] perf tools: Update on filtered entries' percentage output (v6)
Hello, I added --percentage option to perf report to control display of percentage of filtered entries. usage: perf report [] --percentage how to display percentage of filtered entries "relative" means it's relative to filtered entries only so that the sum of shown entries will be always 100%. "absolute" means it retains original value before and after the filter applied. In patch 8/8, I made the "absolute" as default since it makes more sense IMHO. $ perf report -s comm # Overhead Command # # 74.19% cc1 7.61% gcc 6.11%as 4.35%sh 4.14% make 1.13%fixdep ... $ perf report -s comm -c cc1,gcc --percentage absolute # Overhead Command # # 74.19% cc1 7.61% gcc $ perf report -s comm -c cc1,gcc --percentage relative # Overhead Command # # 90.69% cc1 9.31% gcc Note that it has zero effect if no filter was applied. * changes in v6: - fix a bug in --stdio group report - reuse __hpp__fmt() function in TUI/GTK - add Acked-by from Jiri * changes in v5: - fix 0 samples in relative percent output (Jiri) - factor hists__total_period function (Jiri) - share config parsing code with option parser (Jiri) * changes in v4: - support perf top and perf diff also (Jiri) - add HIST_FILTER__HOST/GUEST (Jiri) - retain both of filtered and total stats (Arnaldo) - add 'F' hotkey on TUI (Jiri) - rename config variable to have "hist." prefix You can get this on the 'perf/percentage-v6' branch in my tree git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Any comments are welcome, thanks Namhyung Namhyung Kim (13): perf ui/stdio: Fix invalid output on event group report perf ui/gtk: Reuse generic __hpp__fmt() code perf ui/hists: Pass struct hpp to print functions perf ui/tui: Reuse generic __hpp__fmt() code perf tools: Pass evsel to hpp->header/width functions explicitly perf tools: Count periods of filtered entries separately perf hists: Add support for showing relative percentage perf report: Add --percentage option perf top: Add --percentage option perf diff: Add --percentage option perf tools: Add hist.percentage config option perf ui/tui: Add 'F' hotkey to toggle percentage output perf tools: Show absolute percentage by default tools/perf/Documentation/perf-diff.txt | 21 +++- tools/perf/Documentation/perf-report.txt | 24 +++-- tools/perf/Documentation/perf-top.txt| 18 +++- tools/perf/builtin-diff.c| 42 ++-- tools/perf/builtin-report.c | 24 - tools/perf/builtin-top.c | 2 + tools/perf/ui/browsers/hists.c | 161 ++- tools/perf/ui/gtk/hists.c| 89 - tools/perf/ui/hist.c | 159 -- tools/perf/ui/stdio/hist.c | 11 +-- tools/perf/util/config.c | 4 + tools/perf/util/event.c | 22 ++--- tools/perf/util/hist.c | 65 + tools/perf/util/hist.h | 39 +++- tools/perf/util/symbol.h | 5 +- 15 files changed, 406 insertions(+), 280 deletions(-) -- 1.7.11.7 -- 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/13] perf top: Add --percentage option
The --percentage option is for controlling overhead percentage
displayed. It can only receive either of "relative" or "absolute".
Move the parser callback function into a common location since it's
used by multiple commands now.
For more information, please see previous commit same thing done to
"perf report".
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-top.txt | 18 +++---
tools/perf/builtin-report.c | 16 +---
tools/perf/builtin-top.c | 2 ++
tools/perf/util/hist.c| 13 +
tools/perf/util/hist.h| 5 +
5 files changed, 36 insertions(+), 18 deletions(-)
diff --git a/tools/perf/Documentation/perf-top.txt
b/tools/perf/Documentation/perf-top.txt
index cdd8d4946dba..0acf54f203f0 100644
--- a/tools/perf/Documentation/perf-top.txt
+++ b/tools/perf/Documentation/perf-top.txt
@@ -124,13 +124,16 @@ Default is to monitor all CPUS.
Show a column with the sum of periods.
--dsos::
- Only consider symbols in these dsos.
+ Only consider symbols in these dsos. This option will affect the
+ percentage of the overhead column. See --percentage for more info.
--comms::
- Only consider symbols in these comms.
+ Only consider symbols in these comms. This option will affect the
+ percentage of the overhead column. See --percentage for more info.
--symbols::
- Only consider these symbols.
+ Only consider these symbols. This option will affect the
+ percentage of the overhead column. See --percentage for more info.
-M::
--disassembler-style=:: Set disassembler style for objdump.
@@ -166,6 +169,15 @@ Default is to monitor all CPUS.
Do not show entries which have an overhead under that percent.
(Default: 0).
+--percentage::
+ Determine how to display the overhead percentage of filtered entries.
+ Filters can be applied by --comms, --dsos and/or --symbols options and
+ Zoom operations on the TUI (thread, dso, etc).
+
+ "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.
+
INTERACTIVE PROMPTING KEYS
--
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 2385e694c8c2..ca9a7fd2780e 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -709,20 +709,6 @@ parse_percent_limit(const struct option *opt, const char
*str,
return 0;
}
-static int
-parse_percentage(const struct option *opt __maybe_unused, const char *str,
-int unset __maybe_unused)
-{
- if (!strcmp(str, "relative"))
- symbol_conf.filter_relative = true;
- else if (!strcmp(str, "absolute"))
- symbol_conf.filter_relative = false;
- else
- return -1;
-
- return 0;
-}
-
int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)
{
struct perf_session *session;
@@ -846,7 +832,7 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_CALLBACK(0, "percent-limit", , "percent",
"Don't show entries under that percent",
parse_percent_limit),
OPT_CALLBACK(0, "percentage", NULL, "relative|absolute",
-"how to display percentage of filtered entries",
parse_percentage),
+"how to display percentage of filtered entries",
parse_filter_percentage),
OPT_END()
};
struct perf_data_file file = {
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index ed99ec4a309f..18a2467bdf00 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1114,6 +1114,8 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_STRING('u', "uid", >uid_str, "user", "user to profile"),
OPT_CALLBACK(0, "percent-limit", , "percent",
"Don't show entries under that percent",
parse_percent_limit),
+ OPT_CALLBACK(0, "percentage", NULL, "relative|absolute",
+"How to display percentage of filtered entries",
parse_filter_percentage),
OPT_END()
};
const char * const top_usage[] = {
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 7d72deb96b77..3143b8c14a4b 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -940,3 +940,16 @@ u64 hists__total_period(struct hists *hists)
return symbol_conf.filter_relative ? hists->stats.total_filtered_period
:
hists->stats.total_period;
}
+
+int parse_filter_percentage(const struct option *opt __maybe_unused,
+ const char *arg, int unset __maybe_unused)
+{
+ if (!strcmp(arg, "relative"))
+
[PATCH 05/13] perf tools: Pass evsel to hpp->header/width functions explicitly
Those functions need evsel to investigate event group and it's passed
via hpp->ptr. However as it can be missed easily so it's better to
pass it via an argument IMHO.
Cc: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-diff.c | 7 ---
tools/perf/ui/gtk/hists.c | 3 +--
tools/perf/ui/hist.c | 37 -
tools/perf/ui/stdio/hist.c | 5 ++---
tools/perf/util/hist.h | 6 --
5 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index a77e31246c00..204fffe22532 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -952,8 +952,8 @@ static int hpp__entry_global(struct perf_hpp_fmt *_fmt,
struct perf_hpp *hpp,
dfmt->header_width, buf);
}
-static int hpp__header(struct perf_hpp_fmt *fmt,
- struct perf_hpp *hpp)
+static int hpp__header(struct perf_hpp_fmt *fmt, struct perf_hpp *hpp,
+ struct perf_evsel *evsel __maybe_unused)
{
struct diff_hpp_fmt *dfmt =
container_of(fmt, struct diff_hpp_fmt, fmt);
@@ -963,7 +963,8 @@ static int hpp__header(struct perf_hpp_fmt *fmt,
}
static int hpp__width(struct perf_hpp_fmt *fmt,
- struct perf_hpp *hpp __maybe_unused)
+ struct perf_hpp *hpp __maybe_unused,
+ struct perf_evsel *evsel __maybe_unused)
{
struct diff_hpp_fmt *dfmt =
container_of(fmt, struct diff_hpp_fmt, fmt);
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 7912dab6e5fb..e395ef9b0ae0 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -165,7 +165,6 @@ static void perf_gtk__show_hists(GtkWidget *window, struct
hists *hists,
struct perf_hpp hpp = {
.buf= s,
.size = sizeof(s),
- .ptr= hists_to_evsel(hists),
};
nr_cols = 0;
@@ -192,7 +191,7 @@ static void perf_gtk__show_hists(GtkWidget *window, struct
hists *hists,
col_idx = 0;
perf_hpp__for_each_format(fmt) {
- fmt->header(fmt, );
+ fmt->header(fmt, , hists_to_evsel(hists));
gtk_tree_view_insert_column_with_attributes(GTK_TREE_VIEW(view),
-1, ltrim(s),
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index ac39313a3f0c..765e3918368f 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -116,31 +116,28 @@ int __hpp__fmt(struct perf_hpp *hpp, struct hist_entry
*he,
return ret;
}
-#define __HPP_HEADER_FN(_type, _str, _min_width, _unit_width) \
-static int hpp__header_##_type(struct perf_hpp_fmt *fmt __maybe_unused,
\
- struct perf_hpp *hpp)\
-{ \
- int len = _min_width; \
- \
- if (symbol_conf.event_group) { \
- struct perf_evsel *evsel = hpp->ptr;\
- \
- len = max(len, evsel->nr_members * _unit_width);\
- } \
- return scnprintf(hpp->buf, hpp->size, "%*s", len, _str);\
+#define __HPP_HEADER_FN(_type, _str, _min_width, _unit_width)
\
+static int hpp__header_##_type(struct perf_hpp_fmt *fmt __maybe_unused,
\
+ struct perf_hpp *hpp, struct perf_evsel *evsel)
\
+{
\
+ int len = _min_width;
\
+
\
+ if (symbol_conf.event_group)
\
+ len = max(len, evsel->nr_members * _unit_width);
\
+
\
+ return scnprintf(hpp->buf, hpp->size, "%*s", len, _str);
\
}
#define __HPP_WIDTH_FN(_type, _min_width, _unit_width)
\
static int hpp__width_##_type(struct perf_hpp_fmt *fmt __maybe_unused, \
- struct perf_hpp *hpp __maybe_unused) \
+ struct perf_hpp *hpp __maybe_unused, \
+ struct perf_evsel *evsel) \
{ \
int len = _min_width; \
[PATCH 13/13] perf tools: Show absolute percentage by default
Now perf report will show absolute percentage on filter entries by
default.
Suggested-by: Jiri Olsa
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/util/symbol.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 233681e304dd..0ada68b3b096 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -33,7 +33,6 @@ struct symbol_conf symbol_conf = {
.try_vmlinux_path = true,
.annotate_src = true,
.demangle = true,
- .filter_relative = true,
.symfs= "",
};
--
1.7.11.7
--
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/
