[PATCH V2] tick/broadcast: Make movement of broadcast hrtimer robust against hotplug
Today if the cpu handling broadcasting of wakeups goes offline, the job of broadcasting is handed over to another cpu in the CPU_DEAD phase. The CPU_DEAD notifiers are run only after the offline cpu sets its state as CPU_DEAD. Meanwhile, the kthread doing the offline is scheduled out while waiting for this transition by queuing a timer. This is fatal because if the cpu on which this kthread was running has no other work queued on it, it can re-enter deep idle state, since it sees that a broadcast cpu still exists. However the broadcast wakeup will never come since the cpu which was handling it is offline, and the cpu on which the kthread doing the hotplug operation was running never wakes up to see this because its in deep idle state. Fix this by setting the broadcast timer to a max value so as to force the cpus entering deep idle states henceforth to freshly nominate the broadcast cpu. More importantly this has to be done in the CPU_DYING phase so that it is visible to all cpus right after exiting stop_machine, which is when they can re-enter idle. This ensures that handover of the broadcast duty falls in place on offline of the broadcast cpu, without having to do it explicitly. It fixes the bug reported here: http://linuxppc.10917.n7.nabble.com/offlining-cpus-breakage-td88619.html Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com --- Changes from V1: https://lkml.org/lkml/2015/1/19/168 1. Modified the Changelog kernel/time/clockevents.c|2 +- kernel/time/tick-broadcast.c |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c index 5544990..f3907c9 100644 --- a/kernel/time/clockevents.c +++ b/kernel/time/clockevents.c @@ -568,6 +568,7 @@ int clockevents_notify(unsigned long reason, void *arg) case CLOCK_EVT_NOTIFY_CPU_DYING: tick_handover_do_timer(arg); + tick_shutdown_broadcast_oneshot(arg); break; case CLOCK_EVT_NOTIFY_SUSPEND: @@ -580,7 +581,6 @@ int clockevents_notify(unsigned long reason, void *arg) break; case CLOCK_EVT_NOTIFY_CPU_DEAD: - tick_shutdown_broadcast_oneshot(arg); tick_shutdown_broadcast(arg); tick_shutdown(arg); /* diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c index 066f0ec..e9c1d9b 100644 --- a/kernel/time/tick-broadcast.c +++ b/kernel/time/tick-broadcast.c @@ -675,8 +675,8 @@ static void broadcast_move_bc(int deadcpu) if (!bc || !broadcast_needs_cpu(bc, deadcpu)) return; - /* This moves the broadcast assignment to this cpu */ - clockevents_program_event(bc, bc-next_event, 1); + /* This allows fresh nomination of broadcast cpu */ + bc-next_event.tv64 = KTIME_MAX; } /* -- 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] crypto: replace scatterwalk_sg_next with sg_next
Modify crypto drivers to use the generic SG helper since
both of them are equivalent and the one from crypto is redundant.
See also:
468577abe37ff7b453a9ac613e0ea155349203ae reverted in
b2ab4a57b018aafbba35bff088218f5cc3d2142e
Signed-off-by: Cristian Stoica cristian.sto...@freescale.com
---
crypto/ablkcipher.c | 3 +--
crypto/ahash.c| 2 +-
crypto/scatterwalk.c | 6 +++---
drivers/crypto/bfin_crc.c | 2 +-
drivers/crypto/caam/sg_sw_sec4.h | 8
drivers/crypto/ixp4xx_crypto.c| 4 ++--
drivers/crypto/nx/nx.c| 6 +++---
drivers/crypto/omap-aes.c | 4 ++--
drivers/crypto/omap-des.c | 4 ++--
drivers/crypto/qce/dma.c | 6 +++---
drivers/crypto/qce/sha.c | 2 +-
drivers/crypto/sahara.c | 2 +-
drivers/crypto/talitos.c | 8
drivers/crypto/ux500/cryp/cryp_core.c | 2 +-
include/crypto/scatterwalk.h | 10 +-
15 files changed, 30 insertions(+), 39 deletions(-)
diff --git a/crypto/ablkcipher.c b/crypto/ablkcipher.c
index 7bbc8b4..db201bca 100644
--- a/crypto/ablkcipher.c
+++ b/crypto/ablkcipher.c
@@ -87,8 +87,7 @@ static inline unsigned int ablkcipher_done_slow(struct
ablkcipher_walk *walk,
if (n == len_this_page)
break;
n -= len_this_page;
- scatterwalk_start(walk-out, scatterwalk_sg_next(
- walk-out.sg));
+ scatterwalk_start(walk-out, sg_next(walk-out.sg));
}
return bsize;
diff --git a/crypto/ahash.c b/crypto/ahash.c
index dd28906..8acb886 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -121,7 +121,7 @@ int crypto_hash_walk_done(struct crypto_hash_walk *walk,
int err)
if (!walk-total)
return 0;
- walk-sg = scatterwalk_sg_next(walk-sg);
+ walk-sg = sg_next(walk-sg);
return hash_walk_new_entry(walk);
}
diff --git a/crypto/scatterwalk.c b/crypto/scatterwalk.c
index 79ca227..3bd749c 100644
--- a/crypto/scatterwalk.c
+++ b/crypto/scatterwalk.c
@@ -62,7 +62,7 @@ static void scatterwalk_pagedone(struct scatter_walk *walk,
int out,
walk-offset += PAGE_SIZE - 1;
walk-offset = PAGE_MASK;
if (walk-offset = walk-sg-offset + walk-sg-length)
- scatterwalk_start(walk, scatterwalk_sg_next(walk-sg));
+ scatterwalk_start(walk, sg_next(walk-sg));
}
}
@@ -116,7 +116,7 @@ void scatterwalk_map_and_copy(void *buf, struct scatterlist
*sg,
break;
offset += sg-length;
- sg = scatterwalk_sg_next(sg);
+ sg = sg_next(sg);
}
scatterwalk_advance(walk, start - offset);
@@ -136,7 +136,7 @@ int scatterwalk_bytes_sglen(struct scatterlist *sg, int
num_bytes)
do {
offset += sg-length;
n++;
- sg = scatterwalk_sg_next(sg);
+ sg = sg_next(sg);
/* num_bytes is too large */
if (unlikely(!sg (num_bytes offset)))
diff --git a/drivers/crypto/bfin_crc.c b/drivers/crypto/bfin_crc.c
index 33cf9eb..d9af940 100644
--- a/drivers/crypto/bfin_crc.c
+++ b/drivers/crypto/bfin_crc.c
@@ -110,7 +110,7 @@ static int sg_count(struct scatterlist *sg_list)
while (!sg_is_last(sg)) {
sg_nents++;
- sg = scatterwalk_sg_next(sg);
+ sg = sg_next(sg);
}
return sg_nents;
diff --git a/drivers/crypto/caam/sg_sw_sec4.h b/drivers/crypto/caam/sg_sw_sec4.h
index ce28a56..3b91821 100644
--- a/drivers/crypto/caam/sg_sw_sec4.h
+++ b/drivers/crypto/caam/sg_sw_sec4.h
@@ -37,7 +37,7 @@ sg_to_sec4_sg(struct scatterlist *sg, int sg_count,
dma_to_sec4_sg_one(sec4_sg_ptr, sg_dma_address(sg),
sg_dma_len(sg), offset);
sec4_sg_ptr++;
- sg = scatterwalk_sg_next(sg);
+ sg = sg_next(sg);
sg_count--;
}
return sec4_sg_ptr - 1;
@@ -67,7 +67,7 @@ static inline int __sg_count(struct scatterlist *sg_list, int
nbytes,
nbytes -= sg-length;
if (!sg_is_last(sg) (sg + 1)-length == 0)
*chained = true;
- sg = scatterwalk_sg_next(sg);
+ sg = sg_next(sg);
}
return sg_nents;
@@ -93,7 +93,7 @@ static int dma_map_sg_chained(struct device *dev, struct
scatterlist *sg,
int i;
for (i = 0; i nents; i++) {
dma_map_sg(dev, sg, 1, dir);
- sg = scatterwalk_sg_next(sg);
+ sg = sg_next(sg);
}
} else {
dma_map_sg(dev, sg, nents, dir);
@@ -109,7 +109,7 @@ static int dma_unmap_sg_chained(struct
[PATCH 07/12] pm: at91: the standby mode uses the same sram function as the suspend to memory mode
To simply the PM code, the suspend to standby mode uses the same sram function
as the suspend to memory mode, running in the internal SRAM,
instead of the respective code for each mode.
But for the suspend to standby mode, the master clock doesn't
switch to the slow clock, and the main oscillator doesn't
turn off as well.
Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
---
arch/arm/mach-at91/pm.c | 81 -
arch/arm/mach-at91/pm.h |6 +++
arch/arm/mach-at91/pm_slowclock.S | 18 +
3 files changed, 59 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 691e6db..a1010f0 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -145,62 +145,51 @@ extern void at91_slow_clock(void __iomem *pmc, void
__iomem *ramc0,
void __iomem *ramc1, int memctrl);
extern u32 at91_slow_clock_sz;
+static void at91_pm_suspend(suspend_state_t state)
+{
+ unsigned int pm_data = at91_pm_data.memctrl;
+
+ pm_data |= (state == PM_SUSPEND_MEM) ?
+ (AT91_PM_SLOW_CLOCK AT91_PM_MODE_OFFSET) : 0;
+
+ slow_clock(at91_pmc_base, at91_ramc_base[0],
+ at91_ramc_base[1], pm_data);
+}
+
static int at91_pm_enter(suspend_state_t state)
{
at91_pinctrl_gpio_suspend();
switch (state) {
+ /*
+* Suspend-to-RAM is like STANDBY plus slow clock mode, so
+* drivers must suspend more deeply, the master clock switches
+* to the clk32k and turns off the main oscillator
+*
+* STANDBY mode has *all* drivers suspended; ignores irqs not
+* marked as 'wakeup' event sources; and reduces DRAM power.
+* But otherwise it's identical to PM_SUSPEND_ON: cpu idle, and
+* nothing fancy done with main or cpu clocks.
+*/
+ case PM_SUSPEND_MEM:
+ case PM_SUSPEND_STANDBY:
/*
-* Suspend-to-RAM is like STANDBY plus slow clock mode, so
-* drivers must suspend more deeply: only the master clock
-* controller may be using the main oscillator.
+* Ensure that clocks are in a valid state.
*/
- case PM_SUSPEND_MEM:
- /*
-* Ensure that clocks are in a valid state.
-*/
- if (!at91_pm_verify_clocks())
- goto error;
-
- /*
-* Enter slow clock mode by switching over to clk32k and
-* turning off the main oscillator; reverse on wakeup.
-*/
- if (slow_clock) {
- slow_clock(at91_pmc_base, at91_ramc_base[0],
- at91_ramc_base[1],
- at91_pm_data.memctrl);
- break;
- } else {
- pr_info(AT91: PM - no slow clock mode enabled
...\n);
- /* FALLTHROUGH leaving master clock alone */
- }
+ if (!at91_pm_verify_clocks())
+ goto error;
- /*
-* STANDBY mode has *all* drivers suspended; ignores irqs not
-* marked as 'wakeup' event sources; and reduces DRAM power.
-* But otherwise it's identical to PM_SUSPEND_ON: cpu idle, and
-* nothing fancy done with main or cpu clocks.
-*/
- case PM_SUSPEND_STANDBY:
- /*
-* NOTE: the Wait-for-Interrupt instruction needs to be
-* in icache so no SDRAM accesses are needed until the
-* wakeup IRQ occurs and self-refresh is terminated.
-* For ARM 926 based chips, this requirement is weaker
-* as at91sam9 can access a RAM in self-refresh mode.
-*/
- if (at91_pm_standby)
- at91_pm_standby();
- break;
+ at91_pm_suspend(state);
- case PM_SUSPEND_ON:
- cpu_do_idle();
- break;
+ break;
- default:
- pr_debug(AT91: PM - bogus suspend state %d\n, state);
- goto error;
+ case PM_SUSPEND_ON:
+ cpu_do_idle();
+ break;
+
+ default:
+ pr_debug(AT91: PM - bogus suspend state %d\n, state);
+ goto error;
}
error:
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 7664d39..fbfea42 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -15,6
RE: [f2fs-dev] [RFC PATCH 01/10] f2fs: move ext_lock out of struct extent_info
Ping, any comments on this RFC patch set? Thanks, -Original Message- From: Chao Yu [mailto:chao2...@samsung.com] Sent: Monday, January 12, 2015 3:09 PM To: Jaegeuk Kim; Changman Lee Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net Subject: [f2fs-dev] [RFC PATCH 01/10] f2fs: move ext_lock out of struct extent_info Move ext_lock out of struct extent_info, then in the following patches we can use variables with struct extent_info type as a parameter to pass pure data. -- 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 5/5] tty/serial: Add Spreadtrum sc9836-uart driver support
On Tue, Jan 20, 2015 at 3:37 PM, Lyra Zhang zhang.l...@gmail.com wrote:
Hi, Rob
I still have a question to be conform, specific describes below:
On Mon, Jan 19, 2015 at 10:11 PM, Rob Herring robherri...@gmail.com wrote:
On Mon, Jan 19, 2015 at 3:55 AM, Lyra Zhang zhang.l...@gmail.com wrote:
On Sat, Jan 17, 2015 at 12:41 AM, Rob Herring robherri...@gmail.com wrote:
On Fri, Jan 16, 2015 at 4:00 AM, Chunyan Zhang
chunyan.zh...@spreadtrum.com wrote:
Add a full sc9836-uart driver for SC9836 SoC which is based on the
spreadtrum sharkl64 platform.
This driver also support earlycon.
This patch also replaced the spaces between the macros and their
values with the tabs in serial_core.h
[...]
+static int __init sprd_serial_init(void)
+{
+ int ret = 0;
+
+ ret = uart_register_driver(sprd_uart_driver);
This can be done in probe now. Then you can use module_platform_driver().
Question:
1. there are 4 uart ports configured in dt for sprd_serial, so probe
will be called 4 times, but uart_register_driver only needs to be
called one time, so can we use uart_driver.state to check if
uart_register_driver has already been called ?
Yes.
2. if I use module_platform_driver() instead of
module_init(sprd_serial_init) and module_exit(sprd_serial_exit) , I
must move uart_unregister_driver() which is now processed in
sprd_serial_exit() to sprd_remove(), there is a similar problem with
probe(), sprd_remove() will also be called 4 times, and actually it
should be called only one time. How can we deal with this case?
Look at pl01x or Samsung UART drivers which have done this conversion.
Samsung UART does use module_platform_driver, but pl010/pl011 doesn't.
In the Samsung UART driver, uart_unregister_driver is processed in
remove(), like below:
static int s3c24xx_serial_remove(struct platform_device *dev)
{
struct uart_port *port = s3c24xx_dev_to_port(dev-dev);
if (port) {
s3c24xx_serial_cpufreq_deregister(to_ourport(port));
uart_remove_one_port(s3c24xx_uart_drv, port);
}
uart_unregister_driver(s3c24xx_uart_drv);
}
if this serial has more than one ports, uart_unregister_driver() must
be called multiple times when the device need to be removed.
I think there may be a problem because that uart_unregister_driver()
will do kfree(drv-state) every time when it's called.
I think it is no appropriate to call uart_unregister_driver() at first
port removing.
The drv-state buffer was shared with all uart ports.
If there are some cases that only 1 port is needed to be removed, that
will destroy all others, isn't it?
Regards,
Orson
Thanks,
Chunyan
3. for the second question, we can check the platform_device-id, if
it is equal to the index of last port (e.g. 4 for this case), then
uart_unregister_driver() can be called. Does it work correctly? since
for this case, we must keep the order of releasing ports.
The id will not be the line index in the DT case. I don't think you
can guarantee the order either.
It would be better to make uart_{un}register_driver deal with being
called multiple times so drivers don't have to deal with getting this
correct. I'm not sure if that is feasible though.
Rob
--
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 1/3] Drivers: hv: check vmbus_device_create() return value in vmbus_process_offer()
Dan Carpenter dan.carpen...@oracle.com writes: On Mon, Jan 19, 2015 at 05:56:11PM +0100, Vitaly Kuznetsov wrote: vmbus_device_create() result is not being checked in vmbus_process_offer() and it can fail if kzalloc() fails. Add the check and do minor cleanup to avoid additional duplication of free_channel(); return; block. Reported-by: Jason Wang jasow...@redhat.com Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com out is always a bad name for a label. It's too vague. It implies that the code uses One Err style error handling which is bug prone and I've ranted about that in the past so I won't here. This kind of coding is buggier than direct returns. But recently I've been looking at bugs where we return zero where the code should return a negative error code and, wow, do I hate out labels! if (function_whatever(xxx)) goto out; [ thousands of lines removed. ] out: return ret; Oh crap... Did the coder mean to return success or not??? If you use a direct return then the code looks like: if (function_whatever(xxx)) return 0; In that case, you can immediately see that the coder typed 0 deliberately. Direct returns are best. I guess that's not directly related to this code. But I didn't know that until I read to the bottom of the patch and I already had this rant prepared in my head ready to go... Thank you for your rant, Dan! It contains an explanation _why_ and so is useful. However ... :-) 1) vmbus_process_offer() returns void so we won't forget to set proper return code. 2) this patch is a preparation for the PATCH 3/3 where the label is being used to do some useful (non-trivial) work. Direct returns approach would require us to duplicate the code or move it to a function and call it from all return places. I consider adding out label being less evil. Anyway, I can rename it to something less provocative in PATCH 3/3, e.g. init_rescind. error is a crap label name because it doesn't tell you what the code does. A better name is err_free_chan or something which talks about freeing the channel. And here I have to completely agree with you, I'll rename it in v3. regards, dan carpenter -- Vitaly -- 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 5/5] KVM: nVMX: Enable nested posted interrupt processing.
On 20/01/2015 08:54, Wincy Van wrote: On Tue, Jan 20, 2015 at 3:34 PM, Paolo Bonzini pbonz...@redhat.com wrote: Hence, we can disable local interrupts while delivering nested posted interrupts to make sure we are faster than the destination vcpu. This is a bit tricky but it an avoid that race. I think we do not need to add a spin lock here. RCU does not fit this case, since it will introduce a new race window between the rcu handler and handle_vmptr**. I am wondering that whether there is a better way : ) Why not just use a spinlock? Hmm.. it seems that using a spinlock is the best way. I think we can drop the local_irq_save and use a spinlock instead. I can send v2 if it is necessary, any more ideas? Yes, please send v2 of this patch only. Paolo -- 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/12] pm: at91: rename function name: at91_slow_clock()--at91_pm_suspend_sram_fn
As the file name's renaming, rename the file name at91_slow_clock()--
at91_pm_suspend_sram_fn, rename the function handler's name at the same time.
Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-at91/pm.c | 23 +++
arch/arm/mach-at91/pm_suspend.S | 26 --
2 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index a1010f0..98dfeb2 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -137,13 +137,12 @@ int at91_suspend_entering_slow_clock(void)
}
EXPORT_SYMBOL(at91_suspend_entering_slow_clock);
-
-static void (*slow_clock)(void __iomem *pmc, void __iomem *ramc0,
+static void (*at91_suspend_sram_fn)(void __iomem *pmc, void __iomem *ramc0,
void __iomem *ramc1, int memctrl);
-extern void at91_slow_clock(void __iomem *pmc, void __iomem *ramc0,
+extern void at91_pm_suspend_in_sram(void __iomem *pmc, void __iomem *ramc0,
void __iomem *ramc1, int memctrl);
-extern u32 at91_slow_clock_sz;
+extern u32 at91_pm_suspend_in_sram_sz;
static void at91_pm_suspend(suspend_state_t state)
{
@@ -152,8 +151,8 @@ static void at91_pm_suspend(suspend_state_t state)
pm_data |= (state == PM_SUSPEND_MEM) ?
(AT91_PM_SLOW_CLOCK AT91_PM_MODE_OFFSET) : 0;
- slow_clock(at91_pmc_base, at91_ramc_base[0],
- at91_ramc_base[1], pm_data);
+ at91_suspend_sram_fn(at91_pmc_base, at91_ramc_base[0],
+ at91_ramc_base[1], pm_data);
}
static int at91_pm_enter(suspend_state_t state)
@@ -253,17 +252,19 @@ static void __init at91_pm_sram_init(void)
goto put_node;
}
- sram_base = gen_pool_alloc(sram_pool, at91_slow_clock_sz);
+ sram_base = gen_pool_alloc(sram_pool, at91_pm_suspend_in_sram_sz);
if (!sram_base) {
pr_warn(%s: unable to alloc ocram!\n, __func__);
goto put_node;
}
sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
- slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz, false);
+ at91_suspend_sram_fn = __arm_ioremap_exec(sram_pbase,
+ at91_pm_suspend_in_sram_sz, false);
- /* Copy slow_clock handler to SRAM, and call it */
- memcpy(slow_clock, at91_slow_clock, at91_slow_clock_sz);
+ /* Copy pm suspend handler to SRAM, and call it */
+ memcpy(at91_suspend_sram_fn,
+ at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
put_node:
of_node_put(node);
@@ -312,8 +313,6 @@ static void __init at91_pm_init(void)
at91_pm_sram_init();
- pr_info(AT91: Power Management%s\n, (slow_clock ? (with slow clock
mode) : ));
-
if (at91_cpuidle_device.dev.platform_data)
platform_device_register(at91_cpuidle_device);
diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 420e730..6c3fc50 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -54,23 +54,21 @@ mode.reqr6
.text
-/* void at91_slow_clock(void __iomem *pmc, void __iomem *sdramc,
+/*
+ * void at91_pm_suspend_in_sram(void __iomem *pmc, void __iomem *sdramc,
* void __iomem *ramc1, int memctrl)
+ * @input param:
+ * @r0: the base address of AT91_PMC
+ * @r1: the base address of SDRAM Controller (SDRAM, DDRSDR, or AT91_SYS)
+ * @r2: the base address of second SDRAM Controller or 0 if not present
+ * @r3: the pm information,
+ * least byte: SDRAM controller type
+ * 2nd byte: 1 - suspend to memory, 0 - standby
*/
-ENTRY(at91_slow_clock)
+ENTRY(at91_pm_suspend_in_sram)
/* Save registers on stack */
stmfd sp!, {r4 - r12, lr}
- /*
-* Register usage:
-* R0 = Base address of AT91_PMC
-* R1 = Base address of RAM Controller (SDRAM, DDRSDR, or AT91_SYS)
-* R2 = Base address of second RAM Controller or 0 if not present
-* R3 = Memory controller
-* R4 = temporary register
-* R5 = temporary register
-*/
-
/* Drain write buffer */
mov tmp1, #0
mcr p15, 0, tmp1, c7, c10, 4
@@ -276,5 +274,5 @@ ram_restored:
.saved_sam9_mdr1:
.word 0
-ENTRY(at91_slow_clock_sz)
- .word .-at91_slow_clock
+ENTRY(at91_pm_suspend_in_sram_sz)
+ .word .-at91_pm_suspend_in_sram
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
Hi Viresh,
I explained the relation between memory bus group and memory bus block on
following patch[1].
- [1] https://lkml.org/lkml/2015/1/8/642
On 01/20/2015 04:19 PM, Viresh Kumar wrote:
On 9 January 2015 at 02:48, Rob Herring robherri...@gmail.com wrote:
Adding Viresh.
Sorry for being too late, I was very busy with other cpufreq stuff I was doing
and saved this thread for later as it required me to understand it properly..
+Required properties for memory bus block:
+- clock-names : the name of clock used by the memory bus, memory-bus.
+- clocks : phandles for clock specified in clock-names property.
+- #clock-cells: should be 1.
+- frequency: the frequency table to support DVFS feature.
So you have just defined a new OPP table format. We already have one
and Viresh is working to create a more extendable one. He asked about
what's needed in devfreq, so Viresh here you go. :)
I failed to understand what's new here, probably I need more clarity on
what we are doing here..
So, this is what I see from OPPs point of view, everything else stripped out.
+ memory_bus_int: memory_bus@1 {
+ operating-points =
+ 40 95
+ 20 95
+ 133000 925000
+ 10 85
+ 8 85
+ 5 85;
So these are the OPPs your groups support and below ones are
the frequencies that each block will support. Right ?
Right.
But, the frequency of OPPs is only used for devfreq ondemand governor.
After deciding the proper frequency of memory bus on ondemand governor,
exynos-bus.c (exynos memory bus frequency driver) use the frequency table
of memory bus blocks on below to change the clock rate of memory bus block.
+ blocks {
+ frequency =
+ 10
+ 10
+ 10
+ 10
Why this replication here ?
Firs of all,
I explain the hierarchy of Exynos memory buses.
For example of Exynos3250 memory bus,
This patch divide the memory bus group according to power rail (regulator).
- MIF (Memory Interface ) memory bus group uses the VDD_MIF regulator.
- INT (Internal) memory bus group uses the VDD_INT regulator.
Each memory bus group contains only one power rail(regulator) and one more
memory bus blocks as follwing:
- MIF memory bus group
power rail(VDD_MIF)--|--- memory bus for DMC (Dynamic Memory Controller) block
(dmc clock)
- INT memory bus group
|--- memory bus for PERI block (aclk_100 clock)
|
|--- memory bus for DISPLAY block (aclk_160 clock)
|
|--- memory bus for ISP block (aclk_200 clock)
|
|--- memory bus for GPS block (aclk_266 clock)
power rail(VDD_INT)--|
|--- memory bus for MCUISP block (aclk_400_mcuisp clock)
|
|--- memory bus for Leftbus block (gdl clock)
|
|--- memory bus for Rightbus block (gdr clock)
|
|--- memory bus for MFC block (mfc clock)
Exynos3250 has following table for INT memory bus group:
All clocks of INT memory bus group have to contain the same entry count
againt the number of 'virtual freqw'. So, each memory bus clock could have
duplicate clocks.
Level|virtual freq|PERI's clk|Display's clk|ISP's clk|GPS's clk| voltage|
L6 |40 |10|20 |20 |30 | 95000 |
L5 |20 |10|16 |20 |20 | 95000 |
L4 |133000 |10|10 |10 |133000 | 92500 |
L3 |10 |10|8|8|10 | 85000 |
L2 |8 |5 |8|5|5| 85000 |
L1 |5 |5 |5|5|5| 85000 |
-
(Except for mcuisp, leftbus, rightbus, mfc block)
This table is used for devfreq ondemand governor as following:
1. ondemand governor in devfreq use the 'virtual freq' to devcide the proper
frequency for memory bus.
2. ondemand governor executes the *_target() function to set clock rate and
voltage.
3. *_target() function in exynos-bus.c changes the clock rate of
{PERIS|Display|ISP|GPS} clk
according to decided 'Level' by devfreq ondemand governor.
+ 5
+ 5;
+ };
How
[PATCH 08/12] pm: at91: rename file name: pm_slowclock.S --pm_suspend.S
Because the sram function is used for the suspend to standby mode as well,
more than suspend to memory, so renaming is more elegant.
Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-at91/Makefile |2 +-
arch/arm/mach-at91/pm_slowclock.S | 280 -
arch/arm/mach-at91/pm_suspend.S | 280 +
3 files changed, 281 insertions(+), 281 deletions(-)
delete mode 100644 arch/arm/mach-at91/pm_slowclock.S
create mode 100644 arch/arm/mach-at91/pm_suspend.S
diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index 9c755d9..80473d8 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_SOC_SAMA5) += board-dt-sama5.o
# Power Management
obj-$(CONFIG_PM) += pm.o
-obj-$(CONFIG_PM) += pm_slowclock.o
+obj-$(CONFIG_PM) += pm_suspend.o
ifeq ($(CONFIG_PM_DEBUG),y)
CFLAGS_pm.o += -DDEBUG
diff --git a/arch/arm/mach-at91/pm_slowclock.S
b/arch/arm/mach-at91/pm_slowclock.S
deleted file mode 100644
index 92d7e63..000
--- a/arch/arm/mach-at91/pm_slowclock.S
+++ /dev/null
@@ -1,280 +0,0 @@
-/*
- * arch/arm/mach-at91/pm_slow_clock.S
- *
- * Copyright (C) 2006 Savin Zlobec
- *
- * AT91SAM9 support:
- * Copyright (C) 2007 Anti Sullin anti.sul...@artecdesign.ee
- *
- * 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 linux/linkage.h
-#include linux/clk/at91_pmc.h
-#include mach/at91_ramc.h
-
-#include pm.h
-
-pmc.reqr0
-sdramc .reqr1
-ramc1 .reqr2
-memctrl.reqr3
-tmp1 .reqr4
-tmp2 .reqr5
-mode .reqr6
-
-/*
- * Wait until master clock is ready (after switching master clock source)
- */
- .macro wait_mckrdy
-1: ldr tmp1, [pmc, #AT91_PMC_SR]
- tst tmp1, #AT91_PMC_MCKRDY
- beq 1b
- .endm
-
-/*
- * Wait until master oscillator has stabilized.
- */
- .macro wait_moscrdy
-1: ldr tmp1, [pmc, #AT91_PMC_SR]
- tst tmp1, #AT91_PMC_MOSCS
- beq 1b
- .endm
-
-/*
- * Wait until PLLA has locked.
- */
- .macro wait_pllalock
-1: ldr tmp1, [pmc, #AT91_PMC_SR]
- tst tmp1, #AT91_PMC_LOCKA
- beq 1b
- .endm
-
- .text
-
-/* void at91_slow_clock(void __iomem *pmc, void __iomem *sdramc,
- * void __iomem *ramc1, int memctrl)
- */
-ENTRY(at91_slow_clock)
- /* Save registers on stack */
- stmfd sp!, {r4 - r12, lr}
-
- /*
-* Register usage:
-* R0 = Base address of AT91_PMC
-* R1 = Base address of RAM Controller (SDRAM, DDRSDR, or AT91_SYS)
-* R2 = Base address of second RAM Controller or 0 if not present
-* R3 = Memory controller
-* R4 = temporary register
-* R5 = temporary register
-*/
-
- /* Drain write buffer */
- mov tmp1, #0
- mcr p15, 0, tmp1, c7, c10, 4
-
- mov tmp1, memctrl
- mov tmp2, tmp1, lsr#AT91_PM_MODE_OFFSET
- and mode, tmp2, #AT91_PM_MODE_MASK
-
- mov tmp1, memctrl
- and memctrl, tmp1, #AT91_PM_MEMCTRL_MASK
-
- cmp memctrl, #AT91_MEMCTRL_MC
- bne ddr_sr_enable
-
- /*
-* at91rm9200 Memory controller
-*/
- /* Put SDRAM in self-refresh mode */
- mov tmp1, #1
- str tmp1, [sdramc, #AT91RM9200_SDRAMC_SRR]
- b sdr_sr_done
-
- /*
-* DDRSDR Memory controller
-*/
-ddr_sr_enable:
- cmp memctrl, #AT91_MEMCTRL_DDRSDR
- bne sdr_sr_enable
-
- /* LPDDR1 -- force DDR2 mode during self-refresh */
- ldr tmp1, [sdramc, #AT91_DDRSDRC_MDR]
- str tmp1, .saved_sam9_mdr
- bic tmp1, tmp1, #~AT91_DDRSDRC_MD
- cmp tmp1, #AT91_DDRSDRC_MD_LOW_POWER_DDR
- ldreq tmp1, [sdramc, #AT91_DDRSDRC_MDR]
- biceq tmp1, tmp1, #AT91_DDRSDRC_MD
- orreq tmp1, tmp1, #AT91_DDRSDRC_MD_DDR2
- streq tmp1, [sdramc, #AT91_DDRSDRC_MDR]
-
- /* prepare for DDRAM self-refresh mode */
- ldr tmp1, [sdramc, #AT91_DDRSDRC_LPR]
- str tmp1, .saved_sam9_lpr
- bic tmp1, #AT91_DDRSDRC_LPCB
- orr tmp1, #AT91_DDRSDRC_LPCB_SELF_REFRESH
-
- /* figure out if we use the second ram controller */
- cmp ramc1, #0
- beq ddr_no_2nd_ctrl
-
- ldr tmp2, [ramc1, #AT91_DDRSDRC_MDR]
- str tmp2, .saved_sam9_mdr1
- bic tmp2, tmp2, #~AT91_DDRSDRC_MD
- cmp tmp2, #AT91_DDRSDRC_MD_LOW_POWER_DDR
- ldreq tmp2, [ramc1, #AT91_DDRSDRC_MDR]
- biceq tmp2, tmp2, #AT91_DDRSDRC_MD
- orreq tmp2, tmp2,
[PATCH 06/12] pm: at91: remove the config item CONFIG_AT91_SLOW_CLOCK
The slow clock always exists, for the suspend to memory mode,
the master clock always switch to the slow clock.
To simplify the PM config, remove this config item, remove
the definition code as well.
Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-at91/Kconfig | 13 -
arch/arm/mach-at91/Makefile |2 +-
arch/arm/mach-at91/pm.c |7 +--
3 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 7d5e201..2aed68f 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -127,19 +127,6 @@ menu Atmel AT91 common options
comment AT91 Feature Selections
-config AT91_SLOW_CLOCK
- bool Suspend-to-RAM disables main oscillator
- depends on SUSPEND
- help
- Select this if you want Suspend-to-RAM to save the most power
- possible (without powering off the CPU) by disabling the PLLs
- and main oscillator so that only the 32 KiHz clock is available.
-
- When only that slow-clock is available, some peripherals lose
- functionality. Many can't issue wakeup events unless faster
- clocks are available. Some lose their operating state and
- need to be completely re-initialized.
-
config AT91_TIMER_HZ
int Kernel HZ (jiffies per second)
range 32 1024
diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index fe30e7e..9c755d9 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_SOC_SAMA5) += board-dt-sama5.o
# Power Management
obj-$(CONFIG_PM) += pm.o
-obj-$(CONFIG_AT91_SLOW_CLOCK) += pm_slowclock.o
+obj-$(CONFIG_PM) += pm_slowclock.o
ifeq ($(CONFIG_PM_DEBUG),y)
CFLAGS_pm.o += -DDEBUG
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 609a4f8..691e6db 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -141,11 +141,9 @@ EXPORT_SYMBOL(at91_suspend_entering_slow_clock);
static void (*slow_clock)(void __iomem *pmc, void __iomem *ramc0,
void __iomem *ramc1, int memctrl);
-#ifdef CONFIG_AT91_SLOW_CLOCK
extern void at91_slow_clock(void __iomem *pmc, void __iomem *ramc0,
void __iomem *ramc1, int memctrl);
extern u32 at91_slow_clock_sz;
-#endif
static int at91_pm_enter(suspend_state_t state)
{
@@ -240,7 +238,6 @@ void at91_pm_set_standby(void (*at91_standby)(void))
}
}
-#ifdef CONFIG_AT91_SLOW_CLOCK
static void __init at91_pm_sram_init(void)
{
struct gen_pool *sram_pool;
@@ -282,7 +279,6 @@ static void __init at91_pm_sram_init(void)
put_node:
of_node_put(node);
}
-#endif
static struct of_device_id ramc_ids[] = {
{ .compatible = atmel,at91rm9200-sdramc, .data = at91rm9200_standby },
@@ -324,9 +320,8 @@ static void at91_dt_ramc(void)
static void __init at91_pm_init(void)
{
at91_dt_ramc();
-#ifdef CONFIG_AT91_SLOW_CLOCK
+
at91_pm_sram_init();
-#endif
pr_info(AT91: Power Management%s\n, (slow_clock ? (with slow clock
mode) : ));
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal about reorganize struct irq_data and struct irq_desc
On Mon, 19 Jan 2015, Jiang Liu wrote:
Hi Thomas and Marc,
During working on the generic MSI support, I have some proposal
about reorganizing struct irq_data and struct irq_desc. The proposed
changes are:
1) Add a pointer struct irq_desc * to struct irq_data, so we could
quickly get struct irq_desc from struct irq_data.
2) Move node from struct irq_data into struct irq_desc, NUMA info
should be per-irq instead of per-chip.
3) Move affinity from struct irq_data into struct irq_desc, NUMA info
should be per-irq instead of per-chip.
4) Move msi_desc from struct irq_data into struct irq_desc. (Not sure
whether we should do this. Theoretically we should use
irq_data-handler_data to store msi_desc.)
msi_desc belongs to the msi chip, while handler_data is common data.
I had a look at the usage sites of handler_data. Most of them use it
in combination with chained handlers. Some sites use it instead of
chip data and only a few use it for some random other stuff, where the
x86 sites (hpet, ht, iommu ...) will go away with the irqdomain
conversion.
So in the long run we should provide:
irq_set_chained_handler_and_data(irq, handler, handler_data)
convert everything over and finally remove the direct accessor to
handler_data.
msi_desc in a hierarchical implementation should actually be in
chip_data, but we probably need to keep the msi_desc pointer for
backward compability reasons.
With above change applied, struct irq_data only hosts per-chip data, and
struct irq_desc hosts per-irq data. What's your thoughts?
I'm not so happy with exposing irqdesc to random code again. I went a
great way to hide it from abuse.
So I'd rather like to see something like this:
struct irq_common_data {
unsigned intstate_use_accessors;
unsigned intnode;
void*handler_data;
cpumask_var_t affinity;
};
struct irq_data {
u32 mask;
unsigned intirq;
unsigned long hwirq;
struct irq_chip *chip;
struct irq_domain *domain;
#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
struct irq_data *parent_data;
#endif
void*chip_data;
struct msi_desc *msi_desc;
struct irq_common_data *common_data;
};
struct irq_desc {
struct irq_data irq_data;
struct common_irq_data common_data;
...
};
Thanks,
tglx
--
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] BLACKFIN MEDIA DRIVER: rewrite the blackfin style of read/write into common style
Hi Hans,
On Mon, Jan 19, 2015 at 5:45 PM, Hans Verkuil hverk...@xs4all.nl wrote:
On 01/19/2015 04:13 AM, Hao Liang wrote:
Hi Hans,
Thank you for your reply.
This change comes largely from a non-blackfin architecture dsp processor of
ADI want to reuse this driver.
And i have tested common read/write function on blackfin board to ensure
usability and stability.
Well, looking at arch/blackfin/include/asm/def_LPBlackfin.h it seems that for
certain
blackfin variants the bfin_read/write functions insert an extra nop, so
unless you
test on one of those variants you wouldn't see any problems relating to this
change
(and possibly not even then if this is a rare race condition).
You will have to check this with the blackfin architecture maintainer, Steven
Miao
(added to the CC list). Without the OK of someone who actually understands
that
architecture and the 'ANOMALY_05000198' issues I am not going to merge this.
the ANOMALY_05000198 only exists in blackfin bf533 and bf561 old
silicon revision, and this ppi driver mostly will be used on bf609 and
later platform.
If the bfin_read/write functions are really needed for the blackfin
architecture,
we will sync the __raw_read/write macros with bfin_read/write, and
test it on most of the blackfin bf5xx and bf6xx platform.
then you can always make ppi_read/write functions that check the architecture
and use
bfin_read/write if it is a blackfin and readw/writew otherwise.
That should be safe.
Regards,
Hans
BR
Hao
2015-01-16 19:34 GMT+08:00 Hans Verkuil hverk...@xs4all.nl
mailto:hverk...@xs4all.nl:
Hi Hao,
Why would you do this? read/writew() is AFAICT not the same as
bfin_read/write16
(defined in arch/blackfin/include/asm/def_LPBlackfin.h). And all other
blackfin
sources I've seen all use bfin_read/write.
So unless there is a good reason for this change I am not going to
accept this.
Regards,
Hans
On 01/14/2015 07:57 AM, Hao Liang wrote:
Signed-off-by: Hao Liang hliang1...@gmail.com
mailto:hliang1...@gmail.com
---
drivers/media/platform/blackfin/ppi.c | 72
-
1 file changed, 35 insertions(+), 37 deletions(-)
diff --git a/drivers/media/platform/blackfin/ppi.c
b/drivers/media/platform/blackfin/ppi.c
index cff63e5..de4b5c7 100644
--- a/drivers/media/platform/blackfin/ppi.c
+++ b/drivers/media/platform/blackfin/ppi.c
@@ -20,6 +20,7 @@
#include linux/module.h
#include linux/slab.h
#include linux/platform_device.h
+#include linux/io.h
#include asm/bfin_ppi.h
#include asm/blackfin.h
@@ -59,10 +60,10 @@ static irqreturn_t ppi_irq_err(int irq, void
*dev_id)
/* register on bf561 is cleared when read
* others are W1C
*/
- status = bfin_read16(reg-status);
+ status = readw(reg-status);
if (status 0x3000)
ppi-err = true;
- bfin_write16(reg-status, 0xff00);
+ writew(0xff00, reg-status);
break;
}
case PPI_TYPE_EPPI:
@@ -70,10 +71,10 @@ static irqreturn_t ppi_irq_err(int irq, void
*dev_id)
struct bfin_eppi_regs *reg = info-base;
unsigned short status;
- status = bfin_read16(reg-status);
+ status = readw(reg-status);
if (status 0x2)
ppi-err = true;
- bfin_write16(reg-status, 0x);
+ writew(0x, reg-status);
break;
}
case PPI_TYPE_EPPI3:
@@ -81,10 +82,10 @@ static irqreturn_t ppi_irq_err(int irq, void
*dev_id)
struct bfin_eppi3_regs *reg = info-base;
unsigned long stat;
- stat = bfin_read32(reg-stat);
+ stat = readl(reg-stat);
if (stat 0x2)
ppi-err = true;
- bfin_write32(reg-stat, 0xc0ff);
+ writel(0xc0ff, reg-stat);
break;
}
default:
@@ -139,26 +140,25 @@ static int ppi_start(struct ppi_if *ppi)
case PPI_TYPE_PPI:
{
struct bfin_ppi_regs *reg = info-base;
- bfin_write16(reg-control, ppi-ppi_control);
+ writew(ppi-ppi_control, reg-control);
break;
}
case PPI_TYPE_EPPI:
{
struct bfin_eppi_regs *reg = info-base;
- bfin_write32(reg-control, ppi-ppi_control);
+ writel(ppi-ppi_control, reg-control);
break;
}
case PPI_TYPE_EPPI3:
[PATCH 04/12] pm: at91: move the copying the sram function to the sram initializationi phase
To decrease the suspend time, move the copying the sram function
to the sram initialization phase, instead of every time go to suspend.
Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-at91/pm.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 0990486..609a4f8 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -169,10 +169,6 @@ static int at91_pm_enter(suspend_state_t state)
* turning off the main oscillator; reverse on wakeup.
*/
if (slow_clock) {
-#ifdef CONFIG_AT91_SLOW_CLOCK
- /* copy slow_clock handler to SRAM, and call it
*/
- memcpy(slow_clock, at91_slow_clock,
at91_slow_clock_sz);
-#endif
slow_clock(at91_pmc_base, at91_ramc_base[0],
at91_ramc_base[1],
at91_pm_data.memctrl);
@@ -280,6 +276,9 @@ static void __init at91_pm_sram_init(void)
sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz, false);
+ /* Copy slow_clock handler to SRAM, and call it */
+ memcpy(slow_clock, at91_slow_clock, at91_slow_clock_sz);
+
put_node:
of_node_put(node);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v2 5/7] mfd: cros_ec: Instantiate ChromeOS EC character device
On Fri, 02 Jan 2015, Javier Martinez Canillas wrote:
The ChromeOS EC character device is an user-space interface to
allow applications to access the Embedded Controller.
Add a cell for this device so it's spawned from the mfd driver.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1: None, new patch.
drivers/mfd/cros_ec.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index c872e1b..70f9ed5 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -118,6 +118,10 @@ static const struct mfd_cell cros_devs[] = {
.id = 2,
.of_compatible = google,cros-ec-i2c-tunnel,
},
+ {
+ .name = cros-ec-dev,
*-dev is seldom suitable for naming things.
Please be more imaginative/descriptive in your naming.
+ .id = 3,
+ },
};
int cros_ec_register(struct cros_ec_device *ec_dev)
--
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/
[PATCH 05/12] ARM: at91: move select SRAM to ARCH_AT91
Because the CONFIG_AT91_SLOW_CLOCK will be removed to simply the PM config, so move select SRAM. Signed-off-by: Wenyou Yang wenyou.y...@atmel.com --- arch/arm/mach-at91/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig index 56dcede..7d5e201 100644 --- a/arch/arm/mach-at91/Kconfig +++ b/arch/arm/mach-at91/Kconfig @@ -6,6 +6,7 @@ config ARCH_AT91 select PINCTRL select PINCTRL_AT91 select USE_OF + select SRAM if PM bool menuconfig SOC_SAM_V7 @@ -128,7 +129,6 @@ comment AT91 Feature Selections config AT91_SLOW_CLOCK bool Suspend-to-RAM disables main oscillator - select SRAM depends on SUSPEND help Select this if you want Suspend-to-RAM to save the most power -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/12] pm: at91: remove the struct ramc_ids .data at91_xxx_standby members
Because the at91_xxx_standby function is removed,
remove the struct ramc_ids .data members code.
Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-at91/pm.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 98dfeb2..07b723f 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -271,10 +271,10 @@ put_node:
}
static struct of_device_id ramc_ids[] = {
- { .compatible = atmel,at91rm9200-sdramc, .data = at91rm9200_standby },
- { .compatible = atmel,at91sam9260-sdramc, .data =
at91sam9_sdram_standby },
- { .compatible = atmel,at91sam9g45-ddramc, .data = at91_ddr_standby },
- { .compatible = atmel,sama5d3-ddramc, .data = at91_ddr_standby },
+ { .compatible = atmel,at91rm9200-sdramc },
+ { .compatible = atmel,at91sam9260-sdramc },
+ { .compatible = atmel,at91sam9g45-ddramc },
+ { .compatible = atmel,sama5d3-ddramc },
{ /*sentinel*/ }
};
@@ -283,28 +283,17 @@ static void at91_dt_ramc(void)
struct device_node *np;
const struct of_device_id *of_id;
int idx = 0;
- const void *standby = NULL;
for_each_matching_node_and_match(np, ramc_ids, of_id) {
at91_ramc_base[idx] = of_iomap(np, 0);
if (!at91_ramc_base[idx])
panic(pr_fmt(unable to map ramc[%d] cpu registers\n),
idx);
- if (!standby)
- standby = of_id-data;
-
idx++;
}
if (!idx)
panic(pr_fmt(unable to find compatible ram controller node in
dtb\n));
-
- if (!standby) {
- pr_warn(ramc no standby function available\n);
- return;
- }
-
- at91_pm_set_standby(standby);
}
static void __init at91_pm_init(void)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth: Add hci_h4p driver
Hi Pavel,
On Tue, Dec 23, 2014, Pavel Machek wrote:
+ while (1) {
+ int cmd, len;
+
+ fw_pos += cmd_len;
+
+ if (fw_pos = fw_entry-size)
+ break;
+
+ if (fw_pos + 2 fw_entry-size) {
+ dev_err(info-dev, Corrupted firmware image\n);
+ err = -EMSGSIZE;
+ break;
+ }
+
+ cmd_len = fw_entry-data[fw_pos++];
+ cmd_len += fw_entry-data[fw_pos++] 8;
+ if (cmd_len == 0)
+ break;
+
+ if (fw_pos + cmd_len fw_entry-size) {
+ dev_err(info-dev, Corrupted firmware image\n);
+ err = -EMSGSIZE;
+ break;
+ }
+
+ /* Skip first two packets */
+ if (++num = 2)
+ continue;
+
+ /* Note that this is timing-critical. If sending packets takes
too
+ * long, initialization will fail.
+ */
+ cmd = fw_entry-data[fw_pos+1];
+ cmd += fw_entry-data[fw_pos+2] 8;
+ len = fw_entry-data[fw_pos+3];
+
+ skb = __hci_cmd_sync(info-hdev, cmd, len,
fw_entry-data+fw_pos+4, 500);
+ if (IS_ERR(skb)) {
+ dev_err(info-dev, ...sending cmd %x len %d failed
%ld\n,
+ cmd, len, PTR_ERR(skb));
+ err = -EIO;
+ break;
+ }
+ }
Looks like the code is leaking skb when __hci_cmd_sync() succeeds.
Johan
--
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 12/12] pm: at91: amend the pm_suspend entry for at91_cpuidle_device
Because the at91_xxx_standby() function is substitued by the at91_pm_suspend(),
the pm_suspend entry for at91_cpuidle_device changes as well.
Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-at91/pm.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 07b723f..041adad 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -48,8 +48,6 @@ static struct {
int memctrl;
} at91_pm_data;
-static void (*at91_pm_standby)(void);
-
static int at91_pm_valid_state(suspend_state_t state)
{
switch (state) {
@@ -218,12 +216,15 @@ static struct platform_device at91_cpuidle_device = {
.name = cpuidle-at91,
};
-void at91_pm_set_standby(void (*at91_standby)(void))
+static void at91_cpuidle_suspend(void)
{
- if (at91_standby) {
- at91_cpuidle_device.dev.platform_data = at91_standby;
- at91_pm_standby = at91_standby;
- }
+ at91_pm_suspend(PM_SUSPEND_ON);
+}
+
+static void at91_cpuidle_set_suspend(void (*at91_suspend)(void))
+{
+ if (at91_suspend)
+ at91_cpuidle_device.dev.platform_data = at91_suspend;
}
static void __init at91_pm_sram_init(void)
@@ -302,6 +303,8 @@ static void __init at91_pm_init(void)
at91_pm_sram_init();
+ at91_cpuidle_set_suspend(at91_cpuidle_suspend);
+
if (at91_cpuidle_device.dev.platform_data)
platform_device_register(at91_cpuidle_device);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: vf610: use zero based naming for GPIO nodes
On Fri, Jan 16, 2015 at 06:06:15PM +0100, Stefan Agner wrote: On Vybrid, all peripherals are numbered starting with zero, including the GPIO and PORT module. However, the labels of the corresponding device tree nodes start with one, which is confusing. Fix that by renaming the labels of the gpio nodes in the device tree. Signed-off-by: Stefan Agner ste...@agner.ch Yep, this makes sense since Vybrid Reference Manual is numbering GPIO port from 0. Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.19-rc2 v15 5/8] arm: omap1: Migrate debug_ll macros to use 8250.S
On 19/01/15 21:38, Tony Lindgren wrote: * Daniel Thompson daniel.thomp...@linaro.org [150105 04:49]: The omap1's debug-macro.S is similar to the generic 8250 code. Compared to the 8520 code the omap1 macro automatically determines what UART to use based on breadcrumbs left by the bootloader and automatically copes with the eccentric register layout on OMAP7XX. This patch drops both these features and relies instead on the generic 8250 macros: 1. Dropping support for the bootloader breadcrumbs is identical to the way the migration was handled for OMAP2 (see 808b7e07464d...). 2. Support for OMAP7XX still exists but it must be configured by hand (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org Cc: Russell King li...@arm.linux.org.uk Cc: Arnd Bergmann arnd.bergm...@linaro.org Cc: linux-o...@vger.kernel.org Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Tony Lindgren t...@atomide.com Daniel, I suggest you upload this patch into Russell's patch tracking system to get it merged. That at least shrinks down your patch series if the other patches need more work. This has been in the patch tracker for a week or so: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8271/1 I'm very aware that this patch (and indeed the whole patch set) has been knocking round for longer than it should have. The changelog for this patchset is certainly not one to be especially proud off ;-) . Daniel. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] dt-bindings: Add pinctrl bindings for mt65xx/mt81xx.
On Fri, Jan 16, 2015 at 11:23 AM, Yingjoe Chen
yingjoe.c...@mediatek.com wrote:
On Fri, 2015-01-16 at 10:53 +0100, Linus Walleij wrote:
On Tue, Jan 13, 2015 at 5:16 PM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Tue, Jan 13, 2015 at 11:05:22AM +0100, Linus Walleij wrote:
You often talk about ambiguities. Could you give an example what
ambiguities you mean?
What happened was this pins = ; arguments were sometimes
strings and sometimes integers, that becomes strange to handle
in code, ambiguous.
I see. I like naming it 'pinmux' because that's what it is: pins and
mux settings. A plain 'pinno' suggests that it contains only pin mubers,
without mux setting. How about 'pin-no-mux'? We also could add an
explicit pins-are-numbered property instead of distinguishing this
by property names.
I kind of like this pins-are-numbered thing.
The other property for the pin, whether pinmux or pin-no-mux or
pin-num-and-mux etc is no such big deal, as long as it's
consistent and documented with the generic bindings.
Hi Linus,
To make sure I understand it correct, you think something like this is
OK?
pinctrl@01c20800 {
compatible = mediatek,mt8135-pinctrl;
[...]
pins-are-numbered;
i2c0_pins_a: i2c0@0 {
pins1 {
pins = MT8135_PIN_100_SDA0__FUNC_SDA0,
MT8135_PIN_101_SCL0__FUNC_SCL0;
bias-disable;
};
};
As discussed with Sascha Hauer it is ambigous to use pins for
a numerical value indicating both a mux setting and a pin. Sascha
suggests using pinmux and adding this as a secondary generic
binding for this type of pin controllers that use numbers and #defines
to set up bindings.
We should still move these parsing functions to the core.
See this discussion earlier in this thread:
http://marc.info/?l=linux-kernelm=142116581226500w=2
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v2 3/7] mfd: cros_ec: Add cros_ec_lpc driver for x86 devices
On Fri, 02 Jan 2015, Javier Martinez Canillas wrote:
From: Bill Richardson wfric...@chromium.org
This adds the LPC interface to the Chrome OS EC. Like the
I2C and SPI drivers, this allows userspace access to the EC.
I'm fairly certain that this is _not_ an MFD device. Please locate it
to the proper subsystem (input?).
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1: None, new patch.
drivers/mfd/Kconfig | 10 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/cros_ec_lpc.c | 305
++
3 files changed, 316 insertions(+)
create mode 100644 drivers/mfd/cros_ec_lpc.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2e6b731..7563786 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -110,6 +110,16 @@ config MFD_CROS_EC_I2C
a checksum. Failing accesses will be retried three times to
improve reliability.
+config MFD_CROS_EC_LPC
+ tristate ChromeOS Embedded Controller (LPC)
+ depends on MFD_CROS_EC
+
+ help
+ If you say Y here, you get support for talking to the ChromeOS EC
+ over an LPC bus. This uses a simple byte-level protocol with a
+ checksum. This is used for userspace access only. The kernel
+ typically has its own communication methods.
+
config MFD_CROS_EC_SPI
tristate ChromeOS Embedded Controller (SPI)
depends on MFD_CROS_EC SPI OF
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..94c1516 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_MFD_ASIC3) += asic3.o tmio_core.o
obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o
obj-$(CONFIG_MFD_CROS_EC)+= cros_ec.o
obj-$(CONFIG_MFD_CROS_EC_I2C)+= cros_ec_i2c.o
+obj-$(CONFIG_MFD_CROS_EC_LPC)+= cros_ec_lpc.o
obj-$(CONFIG_MFD_CROS_EC_SPI)+= cros_ec_spi.o
rtsx_pci-objs:= rtsx_pcr.o rtsx_gops.o rts5209.o
rts5229.o rtl8411.o rts5227.o rts5249.o
diff --git a/drivers/mfd/cros_ec_lpc.c b/drivers/mfd/cros_ec_lpc.c
new file mode 100644
index 000..700e4cf
--- /dev/null
+++ b/drivers/mfd/cros_ec_lpc.c
@@ -0,0 +1,305 @@
+/*
+ * cros_ec_lpc - LPC access to the Chrome OS Embedded Controller
+ *
+ * Copyright (C) 2012-2015 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ * This driver uses the Chrome OS EC byte-level message-based protocol for
+ * communicating the keyboard state (which keys are pressed) from a keyboard
EC
+ * to the AP over some bus (such as i2c, lpc, spi). The EC does debouncing,
+ * but everything else (including deghosting) is done here. The main
+ * motivation for this is to keep the EC firmware as simple as possible,
since
+ * it cannot be easily upgraded and EC flash/IRAM space is relatively
+ * expensive.
+ */
+
+#include linux/delay.h
+#include linux/mfd/cros_ec.h
+#include linux/mfd/cros_ec_commands.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/printk.h
+
+#define MYNAME cros_ec_lpc
+
+static int ec_response_timed_out(void)
+{
+ unsigned long one_second = jiffies + HZ;
+
+ usleep_range(200, 300);
+ do {
+ if (!(inb(EC_LPC_ADDR_HOST_CMD) EC_LPC_STATUS_BUSY_MASK))
+ return 0;
+ usleep_range(100, 200);
+ } while (time_before(jiffies, one_second));
+
+ return 1;
+}
+
+static int cros_ec_cmd_xfer_lpc(struct cros_ec_device *ec,
+ struct cros_ec_command *msg)
+{
+ struct ec_lpc_host_args args;
+ int csum;
+ int i;
+ int ret = 0;
+
+ if (msg-outsize EC_PROTO2_MAX_PARAM_SIZE ||
+ msg-insize EC_PROTO2_MAX_PARAM_SIZE) {
+ dev_err(ec-dev,
+ invalid buffer sizes (out %d, in %d)\n,
+ msg-outsize, msg-insize);
+ return -EINVAL;
+ }
+
+ /* Now actually send the command to the EC and get the result */
+ args.flags = EC_HOST_ARGS_FLAG_FROM_HOST;
+ args.command_version = msg-version;
+ args.data_size = msg-outsize;
+
+ /* Initialize checksum */
+ csum = msg-command + args.flags +
+ args.command_version + args.data_size;
+
+ /* Copy data and update checksum */
+ for (i = 0; i msg-outsize; i++) {
+ outb(msg-outdata[i], EC_LPC_ADDR_HOST_PARAM + i);
+
Re: kdbus: add documentation
Daniel, David, On 11/30/2014 06:23 PM, Florian Weimer wrote: * David Herrmann: On Sun, Nov 30, 2014 at 10:02 AM, Florian Weimer f...@deneb.enyo.de wrote: * Greg Kroah-Hartman: +7.4 Receiving messages What happens if this is not possible because the file descriptor limit of the processes would be exceeded? EMFILE, and the message will not be received? The message is returned without installing the FDs. This is signaled by EMFILE, but a valid pool offset. Oh. This is really surprising, so it needs documentation. But it's probably better than the alternative (return EMFILE and leave the message stuck, so that you receive it immediately again—this behavior makes non-blocking accept rather difficult to use correctly). So, was this point in the end explicitly documented? I not obvious that it is documented in the revised kdbus.txt that Greg K-H sent out 4 days ago. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/12] pm: at91: pm_slowclock: remove the unused code related with SLOWDOWN_MASTER_CLOCK
The SLOWDOWN_MASTER_CLOCK definition is not used, remove the redundant code. Signed-off-by: Wenyou Yang wenyou.y...@atmel.com Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com --- arch/arm/mach-at91/pm_slowclock.S | 37 - 1 file changed, 37 deletions(-) diff --git a/arch/arm/mach-at91/pm_slowclock.S b/arch/arm/mach-at91/pm_slowclock.S index 5859f42..634d819 100644 --- a/arch/arm/mach-at91/pm_slowclock.S +++ b/arch/arm/mach-at91/pm_slowclock.S @@ -11,19 +11,10 @@ * published by the Free Software Foundation. * */ - #include linux/linkage.h #include linux/clk/at91_pmc.h #include mach/at91_ramc.h -/* - * When SLOWDOWN_MASTER_CLOCK is defined we will also slow down the Master - * clock during suspend by adjusting its prescalar and divisor. - * NOTE: This hasn't been shown to be stable on SAM9s; and on the RM9200 there - * are errata regarding adjusting the prescalar and divisor. - */ -#undef SLOWDOWN_MASTER_CLOCK - pmc.reqr0 sdramc .reqr1 ramc1 .reqr2 @@ -165,18 +156,6 @@ sdr_sr_done: wait_mckrdy -#ifdef SLOWDOWN_MASTER_CLOCK - /* -* Set the Master Clock PRES and MDIV fields. -* -* See AT91RM9200 errata #27 and #28 for details. -*/ - mov tmp1, #0 - str tmp1, [pmc, #AT91_PMC_MCKR] - - wait_mckrdy -#endif - /* Save PLLA setting and disable it */ ldr tmp1, [pmc, #AT91_CKGR_PLLAR] str tmp1, .saved_pllar @@ -212,22 +191,6 @@ sdr_sr_done: wait_pllalock 4: -#ifdef SLOWDOWN_MASTER_CLOCK - /* -* First set PRES if it was not 0, -* than set CSS and MDIV fields. -* -* See AT91RM9200 errata #27 and #28 for details. -*/ - ldr tmp1, .saved_mckr - tst tmp1, #AT91_PMC_PRES - beq 2f - and tmp1, tmp1, #AT91_PMC_PRES - str tmp1, [pmc, #AT91_PMC_MCKR] - - wait_mckrdy -#endif - /* * Restore master clock setting */ -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v8 2/4] net: netcp: Add Keystone NetCP core ethernet driver
Murali, Wingman, On Thu, 2015-01-15 at 19:12 -0500, Murali Karicheri wrote: The network coprocessor (NetCP) is a hardware accelerator available in Keystone SoCs that processes Ethernet packets. NetCP consists of following hardware components 1 Gigabit Ethernet (GbE) subsystem with a Ethernet switch sub-module to send and receive packets. 2 Packet Accelerator (PA) module to perform packet classification operations such as header matching, and packet modification operations such as checksum generation. 3 Security Accelerator(SA) capable of performing IPSec operations on ingress/egress packets. 4 An optional 10 Gigabit Ethernet Subsystem (XGbE) which includes a 3-port Ethernet switch sub-module capable of 10Gb/s and 1Gb/s rates per Ethernet port. 5 Packet DMA and Queue Management Subsystem (QMSS) to enqueue and dequeue packets and DMA the packets between memory and NetCP hardware components described above. NetCP core driver make use of the Keystone Navigator driver API to allocate DMA channel for the Ethenet device and to handle packet queue/de-queue, Please refer API's in include/linux/soc/ti/knav_dma.h and drivers/soc/ti/knav_qmss.h for details. NetCP driver consists of NetCP core driver and at a minimum Gigabit Ethernet (GBE) module (1) driver to implement the Network device function. Other modules (2,3) can be optionally added to achieve supported hardware acceleration function. The initial version of the driver include NetCP core driver and GBE driver modules. Please refer Documentation/devicetree/bindings/net/keystone-netcp.txt for design of the driver. Cc: David Miller da...@davemloft.net Cc: Rob Herring robh...@kernel.org Cc: Grant Likely grant.lik...@linaro.org Cc: Santosh Shilimkar santosh.shilim...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Signed-off-by: Murali Karicheri m-kariche...@ti.com Signed-off-by: Wingman Kwok w-kw...@ti.com This patch is included as commit 84640e27f230 (net: netcp: Add Keystone NetCP core ethernet driver) in today's linux-next. I noticed because a script I run on linux-next spotted a problem in it. --- MAINTAINERS |7 + drivers/net/ethernet/ti/Kconfig | 11 + drivers/net/ethernet/ti/Makefile |3 + drivers/net/ethernet/ti/netcp.h | 229 drivers/net/ethernet/ti/netcp_core.c | 2141 ++ 5 files changed, 2391 insertions(+) create mode 100644 drivers/net/ethernet/ti/netcp.h create mode 100644 drivers/net/ethernet/ti/netcp_core.c [...] diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig index 605dd90..e11bcfa 100644 --- a/drivers/net/ethernet/ti/Kconfig +++ b/drivers/net/ethernet/ti/Kconfig @@ -73,12 +73,23 @@ config TI_CPSW config TI_CPTS boolean TI Common Platform Time Sync (CPTS) Support depends on TI_CPSW + depends on TI_CPSW || TI_KEYSTONE_NET You probably meant to add || TI_KEYSTONE_NETCP here. Ie, add CP. But as this slipped through testing it _might_ not be needed at all. select PTP_1588_CLOCK ---help--- This driver supports the Common Platform Time Sync unit of the CPSW Ethernet Switch. The unit can time stamp PTP UDP/IPv4 and Layer 2 packets, and the driver offers a PTP Hardware Clock. +config TI_KEYSTONE_NETCP + tristate TI Keystone NETCP Ethernet subsystem Support + depends on OF + depends on KEYSTONE_NAVIGATOR_DMA KEYSTONE_NAVIGATOR_QMSS + ---help--- + This driver supports TI's Keystone NETCP Ethernet subsystem. + + To compile this driver as a module, choose M here: the module + will be called keystone_netcp. + config TLAN tristate TI ThunderLAN support depends on (PCI || EISA) Thanks, Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/12] pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories.
From: Peter Rosin p...@axentia.se The DDRSDR controller fails miserably to put LPDDR1 memories in self-refresh. Force the controller to think it has DDR2 memories during the self-refresh period, as the DDR2 self-refresh spec is equivalent to LPDDR1, and is correctly implemented in the controller. Assume that the second controller has the same fault, but that is untested. Signed-off-by: Peter Rosin p...@axentia.se Acked-by: Nicolas Ferre nicolas.fe...@atmel.com --- arch/arm/mach-at91/pm_slowclock.S | 43 +++- include/soc/at91/at91sam9_ddrsdr.h |2 +- 2 files changed, 39 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-at91/pm_slowclock.S b/arch/arm/mach-at91/pm_slowclock.S index 3d497c7..5859f42 100644 --- a/arch/arm/mach-at91/pm_slowclock.S +++ b/arch/arm/mach-at91/pm_slowclock.S @@ -99,6 +99,16 @@ ddr_sr_enable: cmp memctrl, #AT91_MEMCTRL_DDRSDR bne sdr_sr_enable + /* LPDDR1 -- force DDR2 mode during self-refresh */ + ldr tmp1, [sdramc, #AT91_DDRSDRC_MDR] + str tmp1, .saved_sam9_mdr + bic tmp1, tmp1, #~AT91_DDRSDRC_MD + cmp tmp1, #AT91_DDRSDRC_MD_LOW_POWER_DDR + ldreq tmp1, [sdramc, #AT91_DDRSDRC_MDR] + biceq tmp1, tmp1, #AT91_DDRSDRC_MD + orreq tmp1, tmp1, #AT91_DDRSDRC_MD_DDR2 + streq tmp1, [sdramc, #AT91_DDRSDRC_MDR] + /* prepare for DDRAM self-refresh mode */ ldr tmp1, [sdramc, #AT91_DDRSDRC_LPR] str tmp1, .saved_sam9_lpr @@ -107,14 +117,26 @@ ddr_sr_enable: /* figure out if we use the second ram controller */ cmp ramc1, #0 - ldrne tmp2, [ramc1, #AT91_DDRSDRC_LPR] - strne tmp2, .saved_sam9_lpr1 - bicne tmp2, #AT91_DDRSDRC_LPCB - orrne tmp2, #AT91_DDRSDRC_LPCB_SELF_REFRESH + beq ddr_no_2nd_ctrl + + ldr tmp2, [ramc1, #AT91_DDRSDRC_MDR] + str tmp2, .saved_sam9_mdr1 + bic tmp2, tmp2, #~AT91_DDRSDRC_MD + cmp tmp2, #AT91_DDRSDRC_MD_LOW_POWER_DDR + ldreq tmp2, [ramc1, #AT91_DDRSDRC_MDR] + biceq tmp2, tmp2, #AT91_DDRSDRC_MD + orreq tmp2, tmp2, #AT91_DDRSDRC_MD_DDR2 + streq tmp2, [ramc1, #AT91_DDRSDRC_MDR] + + ldr tmp2, [ramc1, #AT91_DDRSDRC_LPR] + str tmp2, .saved_sam9_lpr1 + bic tmp2, #AT91_DDRSDRC_LPCB + orr tmp2, #AT91_DDRSDRC_LPCB_SELF_REFRESH /* Enable DDRAM self-refresh mode */ + str tmp2, [ramc1, #AT91_DDRSDRC_LPR] +ddr_no_2nd_ctrl: str tmp1, [sdramc, #AT91_DDRSDRC_LPR] - strne tmp2, [ramc1, #AT91_DDRSDRC_LPR] b sdr_sr_done @@ -226,12 +248,17 @@ sdr_sr_done: */ cmp memctrl, #AT91_MEMCTRL_DDRSDR bne sdr_en_restore + /* Restore MDR in case of LPDDR1 */ + ldr tmp1, .saved_sam9_mdr + str tmp1, [sdramc, #AT91_DDRSDRC_MDR] /* Restore LPR on AT91 with DDRAM */ ldr tmp1, .saved_sam9_lpr str tmp1, [sdramc, #AT91_DDRSDRC_LPR] /* if we use the second ram controller */ cmp ramc1, #0 + ldrne tmp2, .saved_sam9_mdr1 + strne tmp2, [ramc1, #AT91_DDRSDRC_MDR] ldrne tmp2, .saved_sam9_lpr1 strne tmp2, [ramc1, #AT91_DDRSDRC_LPR] @@ -262,5 +289,11 @@ ram_restored: .saved_sam9_lpr1: .word 0 +.saved_sam9_mdr: + .word 0 + +.saved_sam9_mdr1: + .word 0 + ENTRY(at91_slow_clock_sz) .word .-at91_slow_clock diff --git a/include/soc/at91/at91sam9_ddrsdr.h b/include/soc/at91/at91sam9_ddrsdr.h index 0210797..dc10c52 100644 --- a/include/soc/at91/at91sam9_ddrsdr.h +++ b/include/soc/at91/at91sam9_ddrsdr.h @@ -92,7 +92,7 @@ #defineAT91_DDRSDRC_UPD_MR (3 20)/* Update load mode register and extended mode register */ #define AT91_DDRSDRC_MDR 0x20/* Memory Device Register */ -#defineAT91_DDRSDRC_MD (3 0)/* Memory Device Type */ +#defineAT91_DDRSDRC_MD (7 0)/* Memory Device Type */ #defineAT91_DDRSDRC_MD_SDR 0 #defineAT91_DDRSDRC_MD_LOW_POWER_SDR 1 #defineAT91_DDRSDRC_MD_LOW_POWER_DDR 3 -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/12] pm: at91: remove the at91_xxx_standby() function definitions in the pm.h
Because the the suspend to standby mode uses the sram function,
these functions will not used, remove the redundant code.
Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-at91/pm.h | 110 ---
1 file changed, 110 deletions(-)
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index fbfea42..46e18bb 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -12,7 +12,6 @@
#define __ARCH_ARM_MACH_AT91_PM
#include asm/proc-fns.h
-
#include mach/at91_ramc.h
#define AT91_PM_MEMCTRL_MASK 0x0f
@@ -21,113 +20,4 @@
#defineAT91_PM_SLOW_CLOCK 0x01
-/*
- * On all at91 except rm9200 and x40 have the System Controller starts
- * at address 0xc000 and has a size of 16KiB.
- *
- * On rm9200 it's start at 0xfffe4000 of 111KiB with non reserved data starting
- * at 0xf000
- *
- * Removes the individual definitions of AT91_BASE_SYS and
- * replaces them with a common version at base 0xfc000 and size 16KiB
- * and map the same memory space
- */
-#define AT91_BASE_SYS 0xc000
-
-#ifdef CONFIG_PM
-extern void at91_pm_set_standby(void (*at91_standby)(void));
-#else
-static inline void at91_pm_set_standby(void (*at91_standby)(void)) { }
-#endif
-
-/*
- * The AT91RM9200 goes into self-refresh mode with this command, and will
- * terminate self-refresh automatically on the next SDRAM access.
- *
- * Self-refresh mode is exited as soon as a memory access is made, but we don't
- * know for sure when that happens. However, we need to restore the low-power
- * mode if it was enabled before going idle. Restoring low-power mode while
- * still in self-refresh is not recommended, but seems to work.
- */
-
-static inline void at91rm9200_standby(void)
-{
- u32 lpr = at91_ramc_read(0, AT91RM9200_SDRAMC_LPR);
-
- asm volatile(
- b1f\n\t
- .align5\n\t
- 1: mcrp15, 0, %0, c7, c10, 4\n\t
- str%0, [%1, %2]\n\t
- str%3, [%1, %4]\n\t
- mcrp15, 0, %0, c7, c0, 4\n\t
- str%5, [%1, %2]
- :
- : r (0), r (AT91_BASE_SYS), r (AT91RM9200_SDRAMC_LPR),
- r (1), r (AT91RM9200_SDRAMC_SRR),
- r (lpr));
-}
-
-/* We manage both DDRAM/SDRAM controllers, we need more than one value to
- * remember.
- */
-static inline void at91_ddr_standby(void)
-{
- /* Those two values allow us to delay self-refresh activation
-* to the maximum. */
- u32 lpr0, lpr1 = 0;
- u32 saved_lpr0, saved_lpr1 = 0;
-
- if (at91_ramc_base[1]) {
- saved_lpr1 = at91_ramc_read(1, AT91_DDRSDRC_LPR);
- lpr1 = saved_lpr1 ~AT91_DDRSDRC_LPCB;
- lpr1 |= AT91_DDRSDRC_LPCB_SELF_REFRESH;
- }
-
- saved_lpr0 = at91_ramc_read(0, AT91_DDRSDRC_LPR);
- lpr0 = saved_lpr0 ~AT91_DDRSDRC_LPCB;
- lpr0 |= AT91_DDRSDRC_LPCB_SELF_REFRESH;
-
- /* self-refresh mode now */
- at91_ramc_write(0, AT91_DDRSDRC_LPR, lpr0);
- if (at91_ramc_base[1])
- at91_ramc_write(1, AT91_DDRSDRC_LPR, lpr1);
-
- cpu_do_idle();
-
- at91_ramc_write(0, AT91_DDRSDRC_LPR, saved_lpr0);
- if (at91_ramc_base[1])
- at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
-}
-
-/* We manage both DDRAM/SDRAM controllers, we need more than one value to
- * remember.
- */
-static inline void at91sam9_sdram_standby(void)
-{
- u32 lpr0, lpr1 = 0;
- u32 saved_lpr0, saved_lpr1 = 0;
-
- if (at91_ramc_base[1]) {
- saved_lpr1 = at91_ramc_read(1, AT91_SDRAMC_LPR);
- lpr1 = saved_lpr1 ~AT91_SDRAMC_LPCB;
- lpr1 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
- }
-
- saved_lpr0 = at91_ramc_read(0, AT91_SDRAMC_LPR);
- lpr0 = saved_lpr0 ~AT91_SDRAMC_LPCB;
- lpr0 |= AT91_SDRAMC_LPCB_SELF_REFRESH;
-
- /* self-refresh mode now */
- at91_ramc_write(0, AT91_SDRAMC_LPR, lpr0);
- if (at91_ramc_base[1])
- at91_ramc_write(1, AT91_SDRAMC_LPR, lpr1);
-
- cpu_do_idle();
-
- at91_ramc_write(0, AT91_SDRAMC_LPR, saved_lpr0);
- if (at91_ramc_base[1])
- at91_ramc_write(1, AT91_SDRAMC_LPR, saved_lpr1);
-}
-
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kdbus: add documentation
Hi Michael, On 01/20/2015 09:09 AM, Michael Kerrisk (man-pages) wrote: On 11/30/2014 06:23 PM, Florian Weimer wrote: * David Herrmann: On Sun, Nov 30, 2014 at 10:02 AM, Florian Weimer f...@deneb.enyo.de wrote: * Greg Kroah-Hartman: +7.4 Receiving messages What happens if this is not possible because the file descriptor limit of the processes would be exceeded? EMFILE, and the message will not be received? The message is returned without installing the FDs. This is signaled by EMFILE, but a valid pool offset. Oh. This is really surprising, so it needs documentation. But it's probably better than the alternative (return EMFILE and leave the message stuck, so that you receive it immediately again—this behavior makes non-blocking accept rather difficult to use correctly). So, was this point in the end explicitly documented? I not obvious that it is documented in the revised kdbus.txt that Greg K-H sent out 4 days ago. No, we've revisited this point and changed the kernel behavior again in v3. We're no longer returning -EMFILE in this case, but rather set KDBUS_RECV_RETURN_INCOMPLETE_FDS in a new field in the receive ioctl struct called 'return_flags'. We believe that's a nicer way of signaling specific errors. The message will carry -1 for all FDs that failed to get installed, so the user can actually see which one is missing. That's also documented in kdbus.txt, but we missed putting it into the Changelog - sorry for that. Hope this helps, Daniel -- 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 5/5] KVM: nVMX: Enable nested posted interrupt processing.
If vcpu has a interrupt in vmx non-root mode, we will
kick that vcpu to inject interrupt timely. With posted
interrupt processing, the kick intr is not needed, and
interrupts are fully taken care of by hardware.
In nested vmx, this feature avoids much more vmexits
than non-nested vmx.
This patch use L0's POSTED_INTR_NV to avoid unexpected
interrupt if L1's vector is different with L0's. If vcpu
is in hardware's non-root mode, we use a physical ipi to
deliver posted interrupts, otherwise we will deliver that
interrupt to L1 and kick that vcpu out of nested
non-root mode.
Signed-off-by: Wincy Van fanwenyi0...@gmail.com
---
arch/x86/kvm/vmx.c | 136 ++--
1 files changed, 132 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index ea56e9f..cda9133 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -215,6 +215,7 @@ struct __packed vmcs12 {
u64 tsc_offset;
u64 virtual_apic_page_addr;
u64 apic_access_addr;
+ u64 posted_intr_desc_addr;
u64 ept_pointer;
u64 eoi_exit_bitmap0;
u64 eoi_exit_bitmap1;
@@ -334,6 +335,7 @@ struct __packed vmcs12 {
u32 vmx_preemption_timer_value;
u32 padding32[7]; /* room for future expansion */
u16 virtual_processor_id;
+ u16 posted_intr_nv;
u16 guest_es_selector;
u16 guest_cs_selector;
u16 guest_ss_selector;
@@ -387,6 +389,7 @@ struct nested_vmx {
/* The host-usable pointer to the above */
struct page *current_vmcs12_page;
struct vmcs12 *current_vmcs12;
+ spinlock_t vmcs12_lock;
struct vmcs *current_shadow_vmcs;
/*
* Indicates if the shadow vmcs must be updated with the
@@ -406,6 +409,8 @@ struct nested_vmx {
*/
struct page *apic_access_page;
struct page *virtual_apic_page;
+ struct page *pi_desc_page;
+ struct pi_desc *pi_desc;
u64 msr_ia32_feature_control;
struct hrtimer preemption_timer;
@@ -621,6 +626,7 @@ static int max_shadow_read_write_fields =
static const unsigned short vmcs_field_to_offset_table[] = {
FIELD(VIRTUAL_PROCESSOR_ID, virtual_processor_id),
+ FIELD(POSTED_INTR_NV, posted_intr_nv),
FIELD(GUEST_ES_SELECTOR, guest_es_selector),
FIELD(GUEST_CS_SELECTOR, guest_cs_selector),
FIELD(GUEST_SS_SELECTOR, guest_ss_selector),
@@ -646,6 +652,7 @@ static const unsigned short vmcs_field_to_offset_table[] = {
FIELD64(TSC_OFFSET, tsc_offset),
FIELD64(VIRTUAL_APIC_PAGE_ADDR, virtual_apic_page_addr),
FIELD64(APIC_ACCESS_ADDR, apic_access_addr),
+ FIELD64(POSTED_INTR_DESC_ADDR, posted_intr_desc_addr),
FIELD64(EPT_POINTER, ept_pointer),
FIELD64(EOI_EXIT_BITMAP0, eoi_exit_bitmap0),
FIELD64(EOI_EXIT_BITMAP1, eoi_exit_bitmap1),
@@ -798,6 +805,7 @@ static void kvm_cpu_vmxon(u64 addr);
static void kvm_cpu_vmxoff(void);
static bool vmx_mpx_supported(void);
static bool vmx_xsaves_supported(void);
+static int vmx_vm_has_apicv(struct kvm *kvm);
static int vmx_set_tss_addr(struct kvm *kvm, unsigned int addr);
static void vmx_set_segment(struct kvm_vcpu *vcpu,
struct kvm_segment *var, int seg);
@@ -1159,6 +1167,11 @@ static inline bool nested_cpu_has_vid(struct
vmcs12 *vmcs12)
return nested_cpu_has2(vmcs12, SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY);
}
+static inline bool nested_cpu_has_posted_intr(struct vmcs12 *vmcs12)
+{
+ return vmcs12-pin_based_vm_exec_control PIN_BASED_POSTED_INTR;
+}
+
static inline bool is_exception(u32 intr_info)
{
return (intr_info (INTR_INFO_INTR_TYPE_MASK | INTR_INFO_VALID_MASK))
@@ -2362,6 +2375,9 @@ static void nested_vmx_setup_ctls_msrs(struct
vcpu_vmx *vmx)
vmx-nested.nested_vmx_pinbased_ctls_high |=
PIN_BASED_ALWAYSON_WITHOUT_TRUE_MSR |
PIN_BASED_VMX_PREEMPTION_TIMER;
+ if (vmx_vm_has_apicv(vmx-vcpu.kvm))
+ vmx-nested.nested_vmx_pinbased_ctls_high |=
+ PIN_BASED_POSTED_INTR;
/* exit controls */
rdmsr(MSR_IA32_VMX_EXIT_CTLS,
@@ -4267,6 +4283,46 @@ static int vmx_vm_has_apicv(struct kvm *kvm)
return enable_apicv irqchip_in_kernel(kvm);
}
+static int vmx_deliver_nested_posted_interrupt(struct kvm_vcpu *vcpu,
+ int vector)
+{
+ int r = 0;
+ struct vmcs12 *vmcs12;
+
+ /*
+* Since posted intr delivery is async,
+* we must aquire a spin-lock to avoid
+* the race of vmcs12.
+*/
+ spin_lock(to_vmx(vcpu)-nested.vmcs12_lock);
+ vmcs12 = get_vmcs12(vcpu);
+ if (!is_guest_mode(vcpu) || !vmcs12) {
+ r = -1;
+ goto out;
+ }
+ if (vector == vmcs12-posted_intr_nv
+ nested_cpu_has_posted_intr(vmcs12)) {
+ if (vcpu-mode == IN_GUEST_MODE)
+
[PATCH] mtd: update ops-oobretlen in concat_write_oob
In concat_read_oob both retlen and oobretlen is updated. concat_write_oob previously only updated retlen. Signed-off-by: Niklas Cassel nikl...@axis.com --- drivers/mtd/mtdconcat.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c index b900056..d85c946 100644 --- a/drivers/mtd/mtdconcat.c +++ b/drivers/mtd/mtdconcat.c @@ -311,7 +311,8 @@ concat_write_oob(struct mtd_info *mtd, loff_t to, struct mtd_oob_ops *ops) devops.len = subdev-size - to; err = mtd_write_oob(subdev, to, devops); - ops-retlen += devops.oobretlen; + ops-retlen += devops.retlen; + ops-oobretlen += devops.oobretlen; if (err) return err; -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] pin control fixes for the v3.19 series
Hi Linus, here is a (hopefully final) slew of pin control fixes for the v3.19 series. The deadlock fix is kind of serious and tagged for stable, the rest is business as usual. Please pull them in! Yours, Linus Walleij The following changes since commit eaa27f34e91a14cdceed26ed6c6793ec1d186115: linux 3.19-rc4 (2015-01-11 12:44:53 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git tags/pinctrl-v3.19-3 for you to fetch changes up to dbe752a34d4bd862de154d1e1f8eb9b649601f77: pinctrl: MAINTAINERS: add git tree reference (2015-01-19 11:27:19 +0100) Pin control fixes for the v3.19 series: - Fix two deadlocks around the pin control mutexes, a long-standing issue that manifest itself in plug/unplug of pin controllers. (Tagged for stable.) - Handle an error path with zero functions in the Qualcomm pin controller. - Drop a bogus second GPIO chip added in the Lantiq driver. - Fix sudden IRQ loss on Rockchip pin controllers. - Register the GIT tree in MAINTAINERS. Doug Anderson (1): pinctrl: rockchip: Avoid losing interrupts when supporting both edges Jim Lin (1): pinctrl: Fix two deadlocks Johan Hovold (1): pinctrl: lantiq: remove bogus of_gpio_chip_add Linus Walleij (1): pinctrl: MAINTAINERS: add git tree reference Stephen Boyd (1): pinctrl: qcom: Don't iterate past end of function array MAINTAINERS| 1 + drivers/pinctrl/core.c | 5 +++-- drivers/pinctrl/pinctrl-rockchip.c | 45 +- drivers/pinctrl/pinctrl-xway.c | 2 -- drivers/pinctrl/qcom/pinctrl-msm.c | 4 ++-- 5 files changed, 26 insertions(+), 31 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/
[PATCH] Selinux/hooks.c: Fix a NULL pointer dereference caused by semop()
A NULL pointer dereference was observed as following panic:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [812735eb] ipc_has_perm+0x4b/0x60
...
Process opcmon (pid: 30712, threadinfo 880237f2a000,
task 88022ac70e40)
Stack:
880237f2bc04 01020953 880237f2bce8
8125818e
0001 37f78004 880237f2bcd8
81273619
880237f2bce8 8126e3e6 880237f2bf68
8125c206
Call Trace:
[8125818e] ? ipcperms+0xae/0x110
[81273619] selinux_sem_semop+0x19/0x20
[8126e3e6] security_sem_semop+0x16/0x20
[8125c206] sys_semtimedop+0x346/0x750
[81188c0c] ? handle_pte_fault+0x1dc/0x200
[8161d830] ? __do_page_fault+0x280/0x500
[810d97d0] ? __lock_release+0x90/0x1b0
[8161d830] ? __do_page_fault+0x280/0x500
[8109a763] ? up_read+0x23/0x40
[8161d830] ? __do_page_fault+0x280/0x500
[81182f1c] ? might_fault+0x5c/0xb0
[81081f96] ? sys_newuname+0x66/0xf0
[810d97d0] ? __lock_release+0x90/0x1b0
[81081f96] ? sys_newuname+0x66/0xf0
[81622f45] ? sysret_check+0x22/0x5d
[8125c620] sys_semop+0x10/0x20
[81622f19] system_call_fastpath+0x16/0x1b
Code: b8 00 00 48 8b 80 48 06 00 00 41 8b 54 24 40 4c 8d
45 d0 89 d9 45 31 c9 48 8b 40 70 8b 78 04 49 8b 44 24 60 c6 45 d0 04 89 55 d8
0f b7 10 8b 70 04 e8 0a dc ff ff 48 83 c4 20 5b 41 5c c9 c3 90
RIP [812735eb] ipc_has_perm+0x4b/0x60
RSP 880237f2bc98
CR2:
The root cause is semtimedop() was called after semget() without checking its
return value in process opcmon. and semget() failed to check permission in
function avc_has_perm() then sem_perm-security was freed shown as following:
sys_semget()
-newary()
-security_sem_alloc()
-sem_alloc_security()
selinux_sem_alloc_security()
-ipc_alloc_security() {
-rc = avc_has_perm()
if (rc) {
ipc_free_security(sma-sem_perm);
return rc;
So ipc_perms-security was NULL, then semtimedop() was called as
following:
sys_semtimedop() / semop()
-selinux_sem_semop()
-ipc_has_perm()
-avc_has_perm(sid, isec-sid, isec-sclass, perms, ad);
^- NULL pointer dereference happens
The test kernel was running on VMware.
This patch use to fix this serious security issue could be triggered by user
space.
This patch was tested with v3.19-rc5.
Signed-off-by: Ethan Zhao ethan.z...@oracle.com
---
security/selinux/hooks.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 6da7532..bbe76f5 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5129,6 +5129,8 @@ static int ipc_has_perm(struct kern_ipc_perm *ipc_perms,
u32 sid = current_sid();
isec = ipc_perms-security;
+ if (!isec)
+ return -EACCES;
ad.type = LSM_AUDIT_DATA_IPC;
ad.u.ipc_id = ipc_perms-key;
--
1.8.3.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/
Michael Wang got a new mail address
Hi, folks And this is my new mail address ;-) Regards, Michael Wang -- 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 0/3] pinctrl: Qualcomm msm8916 pinctrl driver
This series adds a pinctrl driver for Snapdragon 410 (msm8916) SoC. The first patch increase the register address variable size, next adds a binding document and the last patch adds the pinctrl driver Comments are welcome! regards, Stan Joonwoo Park (2): pinctrl: qcom: increase variable size for register addresses pinctrl: qcom: Add msm8916 pinctrl driver Stanimir Varbanov (1): DT: pinctrl: Document Qualcomm MSM8916 pinctrl binding .../bindings/pinctrl/qcom,msm8916-pinctrl.txt | 186 +++ drivers/pinctrl/qcom/Kconfig |8 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-msm.h | 10 +- drivers/pinctrl/qcom/pinctrl-msm8916.c | 1280 5 files changed, 1480 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8916.c -- 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 3/3] phy: ulpi: add driver for TI TUSB1210
TUSB1210 ULPI PHY has vendor specific register for eye
diagram tuning. On some platforms the system firmware has
set optimized value to it. In order to not loose the
optimized value, the driver stores it during probe and
restores it every time the PHY is powered back on.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/ulpi/Kconfig| 11
drivers/phy/ulpi/Makefile | 2 +
drivers/phy/ulpi/tusb1210.c | 131
3 files changed, 144 insertions(+)
create mode 100644 drivers/phy/ulpi/tusb1210.c
diff --git a/drivers/phy/ulpi/Kconfig b/drivers/phy/ulpi/Kconfig
index 8007df2..7cd6f82 100644
--- a/drivers/phy/ulpi/Kconfig
+++ b/drivers/phy/ulpi/Kconfig
@@ -7,3 +7,14 @@ config ULPI_PHY
Say yes if you have ULPI PHY attached to your USB controller.
If unsure, say N.
+
+if ULPI_PHY
+
+config ULPI_TUSB1210
+ tristate TI TUSB1210 USB PHY module
+ depends on POWER_SUPPLY
+ select USB_PHY
+ help
+ Support for TI TUSB1210 USB ULPI PHY.
+
+endif
diff --git a/drivers/phy/ulpi/Makefile b/drivers/phy/ulpi/Makefile
index 59e61cb..7ee6679 100644
--- a/drivers/phy/ulpi/Makefile
+++ b/drivers/phy/ulpi/Makefile
@@ -1,2 +1,4 @@
ulpiphy-y := ulpi.o
obj-$(CONFIG_ULPI_PHY) += ulpiphy.o
+
+obj-$(CONFIG_ULPI_TUSB1210)+= tusb1210.o
diff --git a/drivers/phy/ulpi/tusb1210.c b/drivers/phy/ulpi/tusb1210.c
new file mode 100644
index 000..ac77f98
--- /dev/null
+++ b/drivers/phy/ulpi/tusb1210.c
@@ -0,0 +1,131 @@
+/**
+ * tusb1210.c - TUSB1210 USB ULPI PHY driver
+ *
+ * Copyright (C) 2015 Intel Corporation
+ *
+ * Author: Heikki Krogerus heikki.kroge...@linux.intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/module.h
+#include linux/phy/ulpi/driver.h
+#include linux/phy/ulpi/regs.h
+#include linux/gpio/consumer.h
+
+#include ulpi_phy.h
+
+struct tusb1210 {
+ struct ulpi *ulpi;
+ struct phy *phy;
+ struct gpio_desc *gpio_reset;
+ struct gpio_desc *gpio_cs;
+ u8 ctx[1];
+};
+
+static int tusb1210_power_on(struct phy *phy)
+{
+ struct tusb1210 *tusb = phy_get_drvdata(phy);
+
+ gpiod_set_value_cansleep(tusb-gpio_reset, 1);
+ gpiod_set_value_cansleep(tusb-gpio_cs, 1);
+
+ /* Restore eye optimisation value */
+ ulpi_write(tusb-ulpi, ULPI_EXT_VENDOR_SPECIFIC, tusb-ctx[0]);
+
+ return 0;
+}
+
+static int tusb1210_power_off(struct phy *phy)
+{
+ struct tusb1210 *tusb = phy_get_drvdata(phy);
+
+ gpiod_set_value_cansleep(tusb-gpio_reset, 0);
+ gpiod_set_value_cansleep(tusb-gpio_cs, 0);
+
+ return 0;
+}
+
+static struct phy_ops phy_ops = {
+ .power_on = tusb1210_power_on,
+ .power_off = tusb1210_power_off,
+ .init = tusb1210_power_on,
+ .exit = tusb1210_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int tusb1210_probe(struct ulpi *ulpi)
+{
+ struct gpio_desc *gpio;
+ struct tusb1210 *tusb;
+ int ret;
+
+ tusb = devm_kzalloc(ulpi-dev, sizeof(*tusb), GFP_KERNEL);
+ if (!tusb)
+ return -ENOMEM;
+
+ gpio = devm_gpiod_get(ulpi-dev, reset);
+ if (!IS_ERR(gpio)) {
+ ret = gpiod_direction_output(gpio, 0);
+ if (ret)
+ return ret;
+ tusb-gpio_reset = gpio;
+ }
+
+ gpio = devm_gpiod_get(ulpi-dev, cs);
+ if (!IS_ERR(gpio)) {
+ ret = gpiod_direction_output(gpio, 0);
+ if (ret)
+ return ret;
+ tusb-gpio_cs = gpio;
+ }
+
+ /* Store initial eye diagram optimisation value */
+ ret = ulpi_read(ulpi, ULPI_EXT_VENDOR_SPECIFIC);
+ if (ret 0)
+ return ret;
+
+ tusb-ctx[0] = ret;
+
+ tusb-phy = ulpi_phy_create(ulpi, phy_ops);
+ if (IS_ERR(tusb-phy))
+ return PTR_ERR(tusb-phy);
+
+ tusb-ulpi = ulpi;
+
+ phy_set_drvdata(tusb-phy, tusb);
+ dev_set_drvdata(ulpi-dev, tusb);
+ return 0;
+}
+
+static void tusb1210_remove(struct ulpi *ulpi)
+{
+ struct tusb1210 *tusb = dev_get_drvdata(ulpi-dev);
+
+ ulpi_phy_destroy(ulpi, tusb-phy);
+}
+
+#define TI_VENDOR_ID 0x0451
+
+static struct ulpi_device_id tusb1210_ulpi_id[] = {
+ { TI_VENDOR_ID, 0x1508, },
+ { },
+};
+MODULE_DEVICE_TABLE(ulpi, tusb1210_ulpi_id);
+
+static struct ulpi_driver tusb1210_driver = {
+ .id_table = tusb1210_ulpi_id,
+ .probe = tusb1210_probe,
+ .remove = tusb1210_remove,
+ .driver = {
+ .name = tusb1210,
+ .owner = THIS_MODULE,
+ },
+};
+
+module_ulpi_driver(tusb1210_driver);
+
+MODULE_AUTHOR(Intel Corporation);
+MODULE_LICENSE(GPL);
+MODULE_DESCRIPTION(TUSB1210 ULPI PHY driver);
[PATCH 1/3] pinctrl: qcom: increase variable size for register addresses
From: Joonwoo Park joonw...@codeaurora.org
Newer MSM SoCs have TLMM hardware block upper than 16 bit. Increase to
32 bit registers to hold addresses correctly.
Signed-off-by: Joonwoo Park joonw...@codeaurora.org
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
---
drivers/pinctrl/qcom/pinctrl-msm.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.h
b/drivers/pinctrl/qcom/pinctrl-msm.h
index b952c4b..54fdd04 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.h
+++ b/drivers/pinctrl/qcom/pinctrl-msm.h
@@ -70,11 +70,11 @@ struct msm_pingroup {
unsigned *funcs;
unsigned nfuncs;
- s16 ctl_reg;
- s16 io_reg;
- s16 intr_cfg_reg;
- s16 intr_status_reg;
- s16 intr_target_reg;
+ u32 ctl_reg;
+ u32 io_reg;
+ u32 intr_cfg_reg;
+ u32 intr_status_reg;
+ u32 intr_target_reg;
unsigned mux_bit:5;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] phy: ulpi bus
Heikki Krogerus (3): phy: add bus for USB ULPI PHYs usb: dwc3: add ULPI interface support phy: ulpi: add driver for TI TUSB1210 MAINTAINERS| 7 ++ drivers/phy/Kconfig| 2 + drivers/phy/Makefile | 1 + drivers/phy/ulpi/Kconfig | 20 +++ drivers/phy/ulpi/Makefile | 4 + drivers/phy/ulpi/tusb1210.c| 131 drivers/phy/ulpi/ulpi.c| 246 + drivers/phy/ulpi/ulpi_phy.h| 31 + drivers/usb/dwc3/Kconfig | 7 ++ drivers/usb/dwc3/Makefile | 4 + drivers/usb/dwc3/core.c| 9 +- drivers/usb/dwc3/core.h| 22 drivers/usb/dwc3/ulpi.c| 102 +++ include/linux/phy/ulpi/driver.h| 58 + include/linux/phy/ulpi/interface.h | 23 include/linux/phy/ulpi/regs.h | 130 include/linux/usb/ulpi.h | 135 +--- 17 files changed, 799 insertions(+), 133 deletions(-) create mode 100644 drivers/phy/ulpi/Kconfig create mode 100644 drivers/phy/ulpi/Makefile create mode 100644 drivers/phy/ulpi/tusb1210.c create mode 100644 drivers/phy/ulpi/ulpi.c create mode 100644 drivers/phy/ulpi/ulpi_phy.h create mode 100644 drivers/usb/dwc3/ulpi.c create mode 100644 include/linux/phy/ulpi/driver.h create mode 100644 include/linux/phy/ulpi/interface.h create mode 100644 include/linux/phy/ulpi/regs.h -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] pinctrl: qcom: Add msm8916 pinctrl driver
From: Joonwoo Park joonw...@codeaurora.org
Add initial pinctrl driver to support pin configuration with
pinctrl framework for msm8916.
Signed-off-by: Joonwoo Park joonw...@codeaurora.org
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
---
drivers/pinctrl/qcom/Kconfig |8 +
drivers/pinctrl/qcom/Makefile |1 +
drivers/pinctrl/qcom/pinctrl-msm8916.c | 1280
3 files changed, 1289 insertions(+), 0 deletions(-)
create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8916.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index 3cd243c..ea575f6 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -47,6 +47,14 @@ config PINCTRL_MSM8X74
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 8974 platform.
+config PINCTRL_MSM8916
+ tristate Qualcomm 8916 pin controller driver
+ depends on GPIOLIB OF
+ select PINCTRL_MSM
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm TLMM block found on the Qualcomm 8916 platform.
+
config PINCTRL_QCOM_SPMI_PMIC
tristate Qualcomm SPMI PMIC pin controller driver
depends on GPIOLIB OF SPMI
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index bfd79af..6895870 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -5,5 +5,6 @@ obj-$(CONFIG_PINCTRL_APQ8084) += pinctrl-apq8084.o
obj-$(CONFIG_PINCTRL_IPQ8064) += pinctrl-ipq8064.o
obj-$(CONFIG_PINCTRL_MSM8960) += pinctrl-msm8960.o
obj-$(CONFIG_PINCTRL_MSM8X74) += pinctrl-msm8x74.o
+obj-$(CONFIG_PINCTRL_MSM8916) += pinctrl-msm8916.o
obj-$(CONFIG_PINCTRL_QCOM_SPMI_PMIC) += pinctrl-spmi-gpio.o
obj-$(CONFIG_PINCTRL_QCOM_SPMI_PMIC) += pinctrl-spmi-mpp.o
diff --git a/drivers/pinctrl/qcom/pinctrl-msm8916.c
b/drivers/pinctrl/qcom/pinctrl-msm8916.c
new file mode 100644
index 000..3b851de
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-msm8916.c
@@ -0,0 +1,1280 @@
+/*
+ * Copyright (c) 2015, 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.
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pinctrl/pinctrl.h
+
+#include pinctrl-msm.h
+
+static const struct pinctrl_pin_desc msm8916_pins[] = {
+ PINCTRL_PIN(0, GPIO_0),
+ PINCTRL_PIN(1, GPIO_1),
+ PINCTRL_PIN(2, GPIO_2),
+ PINCTRL_PIN(3, GPIO_3),
+ PINCTRL_PIN(4, GPIO_4),
+ PINCTRL_PIN(5, GPIO_5),
+ PINCTRL_PIN(6, GPIO_6),
+ PINCTRL_PIN(7, GPIO_7),
+ PINCTRL_PIN(8, GPIO_8),
+ PINCTRL_PIN(9, GPIO_9),
+ PINCTRL_PIN(10, GPIO_10),
+ PINCTRL_PIN(11, GPIO_11),
+ PINCTRL_PIN(12, GPIO_12),
+ PINCTRL_PIN(13, GPIO_13),
+ PINCTRL_PIN(14, GPIO_14),
+ PINCTRL_PIN(15, GPIO_15),
+ PINCTRL_PIN(16, GPIO_16),
+ PINCTRL_PIN(17, GPIO_17),
+ PINCTRL_PIN(18, GPIO_18),
+ PINCTRL_PIN(19, GPIO_19),
+ PINCTRL_PIN(20, GPIO_20),
+ PINCTRL_PIN(21, GPIO_21),
+ PINCTRL_PIN(22, GPIO_22),
+ PINCTRL_PIN(23, GPIO_23),
+ PINCTRL_PIN(24, GPIO_24),
+ PINCTRL_PIN(25, GPIO_25),
+ PINCTRL_PIN(26, GPIO_26),
+ PINCTRL_PIN(27, GPIO_27),
+ PINCTRL_PIN(28, GPIO_28),
+ PINCTRL_PIN(29, GPIO_29),
+ PINCTRL_PIN(30, GPIO_30),
+ PINCTRL_PIN(31, GPIO_31),
+ PINCTRL_PIN(32, GPIO_32),
+ PINCTRL_PIN(33, GPIO_33),
+ PINCTRL_PIN(34, GPIO_34),
+ PINCTRL_PIN(35, GPIO_35),
+ PINCTRL_PIN(36, GPIO_36),
+ PINCTRL_PIN(37, GPIO_37),
+ PINCTRL_PIN(38, GPIO_38),
+ PINCTRL_PIN(39, GPIO_39),
+ PINCTRL_PIN(40, GPIO_40),
+ PINCTRL_PIN(41, GPIO_41),
+ PINCTRL_PIN(42, GPIO_42),
+ PINCTRL_PIN(43, GPIO_43),
+ PINCTRL_PIN(44, GPIO_44),
+ PINCTRL_PIN(45, GPIO_45),
+ PINCTRL_PIN(46, GPIO_46),
+ PINCTRL_PIN(47, GPIO_47),
+ PINCTRL_PIN(48, GPIO_48),
+ PINCTRL_PIN(49, GPIO_49),
+ PINCTRL_PIN(50, GPIO_50),
+ PINCTRL_PIN(51, GPIO_51),
+ PINCTRL_PIN(52, GPIO_52),
+ PINCTRL_PIN(53, GPIO_53),
+ PINCTRL_PIN(54, GPIO_54),
+ PINCTRL_PIN(55, GPIO_55),
+ PINCTRL_PIN(56, GPIO_56),
+ PINCTRL_PIN(57, GPIO_57),
+ PINCTRL_PIN(58, GPIO_58),
+ PINCTRL_PIN(59, GPIO_59),
+ PINCTRL_PIN(60, GPIO_60),
+ PINCTRL_PIN(61, GPIO_61),
+ PINCTRL_PIN(62, GPIO_62),
+ PINCTRL_PIN(63,
[PATCH 2/3] DT: pinctrl: Document Qualcomm MSM8916 pinctrl binding
Adds devicetree binding documentation. Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com --- .../bindings/pinctrl/qcom,msm8916-pinctrl.txt | 186 1 files changed, 186 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt new file mode 100644 index 000..10c2dcf --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt @@ -0,0 +1,186 @@ +Qualcomm MSM8916 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +MSM8916 platform. + +- compatible: + Usage: required + Value type: string + Definition: must be qcom,msm8916-pinctrl + +- reg: + Usage: required + Value type: prop-encoded-array + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: prop-encoded-array + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: none + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: u32 + Definition: must be 2. Specifying the pin number and flags, as defined + in dt-bindings/interrupt-controller/irq.h + +- gpio-controller: + Usage: required + Value type: none + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: u32 + Definition: must be 2. Specifying the pin number and flags, as defined + in dt-bindings/gpio/gpio.h + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase pin configuration node. + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: string-array + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio0-gpio121, + sdc1_clk, + sdc1_cmd, + sdc1_data + sdc2_clk, + sdc2_cmd, + sdc2_data, + qdsd_cmd, + qdsd_data0, + qdsd_data1, + qdsd_data2, + qdsd_data3 + +- function: + Usage: required + Value type: string + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + adsp_ext, alsp_int, atest_bbrx0, atest_bbrx1, atest_char, atest_char0, + atest_char1, atest_char2, atest_char3, atest_combodac, atest_gpsadc0, + atest_gpsadc1, atest_tsens, atest_wlan0, atest_wlan1, backlight_en, + bimc_dte0, bimc_dte1, blsp1_spi, blsp2_spi, blsp3_spi, blsp_i2c1, + blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_spi1, + blsp_spi2, blsp_spi3, blsp_spi4, blsp_spi5, blsp_spi6, blsp_uart1, + blsp_uart2, blsp_uim1, blsp_uim2, cam1_rst, cam1_standby, cam_mclk, + cci_async, cci_i2c, cci_timer0, cci_timer1, cci_timer2, cdc_pdm0, + codec_mad, dbg_out, display_5v, dmic0_clk, dmic0_data, dsi_rst, + ebi0_wrcdc, euro_us, ext_lpass, flash_strobe, gcc_gp1_clk_a, + gcc_gp1_clk_b, gcc_gp2_clk_a, gcc_gp2_clk_b, gcc_gp3_clk_a, + gcc_gp3_clk_b, gpio, gsm0_tx0, gsm0_tx1, gsm1_tx0, gsm1_tx1, gyro_accl, + kpsns0, kpsns1, kpsns2, ldo_en, ldo_update, mag_int, mdp_vsync, + modem_tsync, m_voc, nav_pps, nav_tsync, pa_indicator,
Re: [PATCH v2] ARM: dts: exynos5422-odroidxu3: add on-board INA231 sensors
On Wed, 2015-01-14 at 17:08 -0800, Kevin Hilman wrote:
From: Kevin Hilman khil...@linaro.org
The odroid-xu3 has 4 INA231 current sensors on board which can be
accessed from the Linux via the hwmon interface.
There is one sensor for each of these power rails:
- A15 cluster: VDD_ARM
- A7 cluster: VDD_KFC
- GPU: VDD_G3D
- memory: VDD_MEM
In addition to adding the sensors, LDO26 from the PMIC needs to be
enabled because it's powering these sensor.
I haven't tested whether the sensor values are correct, but based on the
schematics the hardkernel dts this describes the hardware correctly.
Reviewed-By: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Signed-off-by: Kevin Hilman khil...@linaro.org
---
v2: use ti,ina231 as compatible string.
Applies on top of ARM: dts: Add dts file for odroid XU3 board from Sjoerd
Simons.
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39
++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index c29123c0734d..50353d023225 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -174,6 +174,13 @@
regulator-always-on;
};
+ ldo26_reg: LDO26 {
+ regulator-name = vdd_ldo26;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-always-on;
+ };
+
buck1_reg: BUCK1 {
regulator-name = vdd_mif;
regulator-min-microvolt = 80;
@@ -257,6 +264,38 @@
};
};
+ i2c_0: i2c@12C6 {
+ status = okay;
+
+ /* A15 cluster: VDD_ARM */
+ ina231@40 {
+ compatible = ti,ina231;
+ reg = 0x40;
+ shunt-resistor = 1;
+ };
+
+ /* memory: VDD_MEM */
+ ina231@41 {
+ compatible = ti,ina231;
+ reg = 0x41;
+ shunt-resistor = 1;
+ };
+
+ /* GPU: VDD_G3D */
+ ina231@44 {
+ compatible = ti,ina231;
+ reg = 0x44;
+ shunt-resistor = 1;
+ };
+
+ /* A7 cluster: VDD_KFC */
+ ina231@45 {
+ compatible = ti,ina231;
+ reg = 0x45;
+ shunt-resistor = 1;
+ };
+ };
+
i2c_2: i2c@12C8 {
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
smime.p7s
Description: S/MIME cryptographic signature
[PATCH 1/3] phy: add bus for USB ULPI PHYs
UTMI+ Low Pin Interface (ULPI) is a commonly used PHY
interface for USB 2.0. It describe a standard set of
registers which the vendors can extend for their specific
needs.
ULPI registers are accessed from the controller. The purpose
of the bus is to provide nice way for the controller drivers
to share that access with the actual PHY drivers.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
MAINTAINERS| 7 ++
drivers/phy/Kconfig| 2 +
drivers/phy/Makefile | 1 +
drivers/phy/ulpi/Kconfig | 9 ++
drivers/phy/ulpi/Makefile | 2 +
drivers/phy/ulpi/ulpi.c| 246 +
drivers/phy/ulpi/ulpi_phy.h| 31 +
include/linux/phy/ulpi/driver.h| 58 +
include/linux/phy/ulpi/interface.h | 23
include/linux/phy/ulpi/regs.h | 130
include/linux/usb/ulpi.h | 135 +---
11 files changed, 512 insertions(+), 132 deletions(-)
create mode 100644 drivers/phy/ulpi/Kconfig
create mode 100644 drivers/phy/ulpi/Makefile
create mode 100644 drivers/phy/ulpi/ulpi.c
create mode 100644 drivers/phy/ulpi/ulpi_phy.h
create mode 100644 include/linux/phy/ulpi/driver.h
create mode 100644 include/linux/phy/ulpi/interface.h
create mode 100644 include/linux/phy/ulpi/regs.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 4ef032a..fce81a4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4233,6 +4233,13 @@ S: Supported
F: drivers/phy/
F: include/linux/phy/
+ULPI PHY BUS
+M: Heikki Krogerus heikki.kroge...@linux.intel.com
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/phy/ulpi/
+F: include/linux/phy/ulpi/
+
GENERIC UIO DRIVER FOR PCI DEVICES
M: Michael S. Tsirkin m...@redhat.com
L: k...@vger.kernel.org
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccad880..9bfb556 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -277,4 +277,6 @@ config PHY_STIH41X_USB
Enable this to support the USB transceiver that is part of
STMicroelectronics STiH41x SoC series.
+source drivers/phy/ulpi/Kconfig
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index aa74f96..8914f3d 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -34,3 +34,4 @@ obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
obj-$(CONFIG_PHY_STIH407_USB) += phy-stih407-usb.o
obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
+obj-$(CONFIG_ULPI_PHY) += ulpi/
diff --git a/drivers/phy/ulpi/Kconfig b/drivers/phy/ulpi/Kconfig
new file mode 100644
index 000..8007df2
--- /dev/null
+++ b/drivers/phy/ulpi/Kconfig
@@ -0,0 +1,9 @@
+
+config ULPI_PHY
+ bool USB ULPI PHY interface support
+ depends on USB || USB_GADGET
+ select GENERIC_PHY
+ help
+ Say yes if you have ULPI PHY attached to your USB controller.
+
+ If unsure, say N.
diff --git a/drivers/phy/ulpi/Makefile b/drivers/phy/ulpi/Makefile
new file mode 100644
index 000..59e61cb
--- /dev/null
+++ b/drivers/phy/ulpi/Makefile
@@ -0,0 +1,2 @@
+ulpiphy-y := ulpi.o
+obj-$(CONFIG_ULPI_PHY) += ulpiphy.o
diff --git a/drivers/phy/ulpi/ulpi.c b/drivers/phy/ulpi/ulpi.c
new file mode 100644
index 000..4a05dd5
--- /dev/null
+++ b/drivers/phy/ulpi/ulpi.c
@@ -0,0 +1,246 @@
+/**
+ * ulpi.c - USB ULPI PHY bus
+ *
+ * Copyright (C) 2015 Intel Corporation
+ *
+ * Author: Heikki Krogerus heikki.kroge...@linux.intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/phy/ulpi/interface.h
+#include linux/phy/ulpi/driver.h
+#include linux/phy/ulpi/regs.h
+#include linux/module.h
+#include linux/slab.h
+
+/* --
*/
+
+int ulpi_read(struct ulpi *ulpi, u8 addr)
+{
+ return ulpi-ops-read(ulpi-ops, addr);
+}
+EXPORT_SYMBOL_GPL(ulpi_read);
+
+int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val)
+{
+ return ulpi-ops-write(ulpi-ops, addr, val);
+}
+EXPORT_SYMBOL_GPL(ulpi_write);
+
+/* --
*/
+
+static int ulpi_match(struct device *dev, struct device_driver *driver)
+{
+ struct ulpi_driver *drv = to_ulpi_driver(driver);
+ struct ulpi *ulpi = to_ulpi_dev(dev);
+ const struct ulpi_device_id *id;
+
+ for (id = drv-id_table; id-vendor; id++)
+ if (id-vendor == ulpi-id.vendor
+ id-product == ulpi-id.product)
+ return 1;
+
+ return 0;
+}
+
+static int ulpi_probe(struct device *dev)
+{
+ struct ulpi_driver *drv = to_ulpi_driver(dev-driver);
+
+
[PATCH 2/3] usb: dwc3: add ULPI interface support
Registers ULPI interface with the ULPI bus if HSPHY type is
ULPI.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/Kconfig | 7
drivers/usb/dwc3/Makefile | 4 ++
drivers/usb/dwc3/core.c | 9 +++-
drivers/usb/dwc3/core.h | 22 ++
drivers/usb/dwc3/ulpi.c | 102 ++
5 files changed, 143 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/dwc3/ulpi.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 58b5b2c..6d0c5e6 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -11,6 +11,13 @@ config USB_DWC3
if USB_DWC3
+config USB_DWC3_ULPI
+ bool Provide ULPI PHY Interface
+ depends on ULPI_PHY=y || ULPI_PHY=USB_DWC3
+ help
+ Select this if you have ULPI type PHY attached to your DWC3
+ controller.
+
choice
bool DWC3 Mode Selection
default USB_DWC3_DUAL_ROLE if (USB USB_GADGET)
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index bb34fbc..2fc44e0 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -16,6 +16,10 @@ ifneq ($(filter y,$(CONFIG_USB_DWC3_GADGET)
$(CONFIG_USB_DWC3_DUAL_ROLE)),)
dwc3-y += gadget.o ep0.o
endif
+ifneq ($(CONFIG_USB_DWC3_ULPI),)
+ dwc3-y += ulpi.o
+endif
+
ifneq ($(CONFIG_DEBUG_FS),)
dwc3-y += debugfs.o
endif
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 25ddc39..5219bc7 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -876,12 +876,17 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-hird_threshold = hird_threshold
| (dwc-is_utmi_l1_suspend 4);
+ platform_set_drvdata(pdev, dwc);
+
+ ret = dwc3_ulpi_init(dwc);
+ if (ret)
+ return ret;
+
ret = dwc3_core_get_phy(dwc);
if (ret)
return ret;
spin_lock_init(dwc-lock);
- platform_set_drvdata(pdev, dwc);
if (!dev-dma_mask) {
dev-dma_mask = dev-parent-dma_mask;
@@ -965,6 +970,7 @@ err1:
err0:
dwc3_free_event_buffers(dwc);
+ dwc3_ulpi_exit(dwc);
return ret;
}
@@ -984,6 +990,7 @@ static int dwc3_remove(struct platform_device *pdev)
phy_power_off(dwc-usb3_generic_phy);
dwc3_core_exit(dwc);
+ dwc3_ulpi_exit(dwc);
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 0842aa8..f6881a6 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -32,6 +32,7 @@
#include linux/usb/otg.h
#include linux/phy/phy.h
+#include linux/phy/ulpi/interface.h
#define DWC3_MSG_MAX 500
@@ -174,6 +175,14 @@
#define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 31)
#define DWC3_GUSB2PHYCFG_SUSPHY(1 6)
+/* Global USB2 PHY Vendor Control Register */
+#define DWC3_GUSB2PHYACC_NEWREGREQ (1 25)
+#define DWC3_GUSB2PHYACC_BUSY (1 23)
+#define DWC3_GUSB2PHYACC_WRITE (1 22)
+#define DWC3_GUSB2PHYACC_ADDR(n) (n 16)
+#define DWC3_GUSB2PHYACC_EXTEND_ADDR(n)(n 8)
+#define DWC3_GUSB2PHYACC_DATA(n) (n 0xff)
+
/* Global USB3 PIPE Control Register */
#define DWC3_GUSB3PIPECTL_PHYSOFTRST (1 31)
#define DWC3_GUSB3PIPECTL_U2SSINP3OK (1 29)
@@ -590,6 +599,7 @@ struct dwc3_hwparams {
#define DWC3_NUM_INT(n)(((n) (0x3f 15)) 15)
/* HWPARAMS3 */
+#define DWC3_ULPI_HSPHY(1 3)
#define DWC3_NUM_IN_EPS_MASK (0x1f 18)
#define DWC3_NUM_EPS_MASK (0x3f 12)
#define DWC3_NUM_EPS(p)(((p)-hwparams3 \
@@ -739,6 +749,8 @@ struct dwc3 {
struct phy *usb2_generic_phy;
struct phy *usb3_generic_phy;
+ struct ulpi *ulpi;
+
void __iomem*regs;
size_t regs_size;
@@ -1035,4 +1047,14 @@ static inline int dwc3_gadget_resume(struct dwc3 *dwc)
}
#endif /* !IS_ENABLED(CONFIG_USB_DWC3_HOST) */
+#if IS_ENABLED(CONFIG_USB_DWC3_ULPI)
+int dwc3_ulpi_init(struct dwc3 *dwc);
+void dwc3_ulpi_exit(struct dwc3 *dwc);
+#else
+static inline int dwc3_ulpi_init(struct dwc3 *dwc)
+{ return 0; }
+static inline void dwc3_ulpi_exit(struct dwc3 *dwc)
+{ }
+#endif
+
#endif /* __DRIVERS_USB_DWC3_CORE_H */
diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c
new file mode 100644
index 000..ee3ebbe
--- /dev/null
+++ b/drivers/usb/dwc3/ulpi.c
@@ -0,0 +1,102 @@
+/**
+ * ulpi.c - DesignWare USB3 Controller's ULPI PHY interface
+ *
+ * Copyright (C) 2015 Intel Corporation
+ *
+ * Author: Heikki Krogerus heikki.kroge...@linux.intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public
[PATCH v2] ARM: clk: add clk-asm9260 driver
Provide CLK support for Alphascale ASM9260 SoC.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/clk/Makefile | 1 +
drivers/clk/clk-asm9260.c | 348 +
include/dt-bindings/clock/alphascale,asm9260.h | 97 +++
3 files changed, 446 insertions(+)
create mode 100644 drivers/clk/clk-asm9260.c
create mode 100644 include/dt-bindings/clock/alphascale,asm9260.h
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d5fba5b..3c41a68 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -16,6 +16,7 @@ endif
# hardware specific clock types
# please keep this section sorted lexicographically by file/directory path name
+obj-$(CONFIG_MACH_ASM9260) += clk-asm9260.o
obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)+= clk-axi-clkgen.o
obj-$(CONFIG_ARCH_AXXIA) += clk-axm5516.o
obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
diff --git a/drivers/clk/clk-asm9260.c b/drivers/clk/clk-asm9260.c
new file mode 100644
index 000..88f4ff6
--- /dev/null
+++ b/drivers/clk/clk-asm9260.c
@@ -0,0 +1,348 @@
+/*
+ * Copyright (c) 2014 Oleksij Rempel li...@rempel-privat.de.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/err.h
+#include linux/io.h
+#include linux/clk-provider.h
+#include linux/spinlock.h
+#include linux/of.h
+#include linux/of_address.h
+#include dt-bindings/clock/alphascale,asm9260.h
+
+#define HW_AHBCLKCTRL0 0x0020
+#define HW_AHBCLKCTRL1 0x0030
+#define HW_SYSPLLCTRL 0x0100
+#define HW_MAINCLKSEL 0x0120
+#define HW_MAINCLKUEN 0x0124
+#define HW_UARTCLKSEL 0x0128
+#define HW_UARTCLKUEN 0x012c
+#define HW_I2S0CLKSEL 0x0130
+#define HW_I2S0CLKUEN 0x0134
+#define HW_I2S1CLKSEL 0x0138
+#define HW_I2S1CLKUEN 0x013c
+#define HW_WDTCLKSEL 0x0160
+#define HW_WDTCLKUEN 0x0164
+#define HW_CLKOUTCLKSEL0x0170
+#define HW_CLKOUTCLKUEN0x0174
+#define HW_CPUCLKDIV 0x017c
+#define HW_SYSAHBCLKDIV0x0180
+#define HW_I2S0MCLKDIV 0x0190
+#define HW_I2S0SCLKDIV 0x0194
+#define HW_I2S1MCLKDIV 0x0188
+#define HW_I2S1SCLKDIV 0x018c
+#define HW_UART0CLKDIV 0x0198
+#define HW_UART1CLKDIV 0x019c
+#define HW_UART2CLKDIV 0x01a0
+#define HW_UART3CLKDIV 0x01a4
+#define HW_UART4CLKDIV 0x01a8
+#define HW_UART5CLKDIV 0x01ac
+#define HW_UART6CLKDIV 0x01b0
+#define HW_UART7CLKDIV 0x01b4
+#define HW_UART8CLKDIV 0x01b8
+#define HW_UART9CLKDIV 0x01bc
+#define HW_SPI0CLKDIV 0x01c0
+#define HW_SPI1CLKDIV 0x01c4
+#define HW_QUADSPICLKDIV 0x01c8
+#define HW_SSP0CLKDIV 0x01d0
+#define HW_NANDCLKDIV 0x01d4
+#define HW_TRACECLKDIV 0x01e0
+#define HW_CAMMCLKDIV 0x01e8
+#define HW_WDTCLKDIV 0x01ec
+#define HW_CLKOUTCLKDIV0x01f4
+#define HW_MACCLKDIV 0x01f8
+#define HW_LCDCLKDIV 0x01fc
+#define HW_ADCANACLKDIV0x0200
+
+static struct clk *clks[MAX_CLKS];
+static struct clk_onecell_data clk_data;
+static DEFINE_SPINLOCK(asm9260_clk_lock);
+
+struct asm9260_div_clk {
+ unsigned int idx;
+ const char *name;
+ const char *parent_name;
+ u32 reg;
+};
+
+struct asm9260_gate_data {
+ unsigned int idx;
+ const char *name;
+ const char *parent_name;
+ u32 reg;
+ u8 bit_idx;
+ unsigned long flags;
+};
+
+struct asm9260_mux_clock {
+ u8 mask;
+ u32 *table;
+ const char *name;
+ const char **parent_names;
+ u8 num_parents;
+ unsigned long offset;
+ unsigned long flags;
+};
+
+static void __iomem *base;
+
+static const struct asm9260_div_clk asm9260_div_clks[] __initconst = {
+ { CLKID_SYS_CPU,cpu_div, main_gate, HW_CPUCLKDIV },
+ { CLKID_SYS_AHB,ahb_div, cpu_div, HW_SYSAHBCLKDIV },
+
+ /* i2s has two deviders: one for only external mclk and internal
+* devider for all clks. */
+ { CLKID_SYS_I2S0M, i2s0m_div, i2s0_mclk, HW_I2S0MCLKDIV },
+ {
Re: [PATCH 5/7] ARM: at91: move debug-macro.S into the common space
Alexandre,
On Mon, 2015-01-12 at 19:42 +0100, Alexandre Belloni wrote:
Move debug-macro.S from include/mach/ to include/debug where all other common
debug macros are.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
This patch became commit 5f58c97099f2 (ARM: at91: move debug-macro.S
into the common space) in today's linux-next (ie, next-20150120). I
noticed because a script I use to check linux-next spotted a problem in
it.
MAINTAINERS | 1 +
arch/arm/Kconfig.debug| 9 +++--
.../mach/debug-macro.S = include/debug/at91.S} | 19
+++
3 files changed, 19 insertions(+), 10 deletions(-)
rename arch/arm/{mach-at91/include/mach/debug-macro.S =
include/debug/at91.S} (68%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3589d67437f8..8c25979a3c43 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -877,6 +877,7 @@ F:arch/arm/boot/dts/at91*.dts
F: arch/arm/boot/dts/at91*.dtsi
F: arch/arm/boot/dts/sama*.dts
F: arch/arm/boot/dts/sama*.dtsi
+F: arch/arm/include/debug/at91.S
ARM/ATMEL AT91 Clock Support
M: Boris Brezillon boris.brezil...@free-electrons.com
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 5ddd4906f7a7..e34d24949c6a 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -115,15 +115,18 @@ choice
0x80024000 | 0xf0024000 | UART9
config AT91_DEBUG_LL_DBGU0
- bool Kernel low-level debugging on rm9200, 9260/9g20,
9261/9g10 and 9rl
+ bool Kernel low-level debugging on rm9200, 9260/9g20,
9261/9g10, 9rl, 9x5, 9n12
+ select DEBUG_AT91_UART
There's no Kconfig symbol DEBUG_AT91_UART in linux-next. So this select
is currently a nop. Why was it added?
depends on HAVE_AT91_DBGU0
config AT91_DEBUG_LL_DBGU1
- bool Kernel low-level debugging on 9263 and 9g45
+ bool Kernel low-level debugging on 9263, 9g45 and sama5d3
+ select DEBUG_AT91_UART
Ditto.
depends on HAVE_AT91_DBGU1
config AT91_DEBUG_LL_DBGU2
bool Kernel low-level debugging on sama5d4
+ select DEBUG_AT91_UART
Ditto.
depends on HAVE_AT91_DBGU2
config DEBUG_BCM2835
@@ -1165,6 +1168,8 @@ config DEBUG_LL_INCLUDE
string
default debug/sa1100.S if DEBUG_SA1100
default debug/8250.S if DEBUG_LL_UART_8250 || DEBUG_UART_8250
+ default debug/at91.S if AT91_DEBUG_LL_DBGU0 || AT91_DEBUG_LL_DBGU1 ||
\
+ AT91_DEBUG_LL_DBGU2
default debug/asm9260.S if DEBUG_ASM9260_UART
default debug/clps711x.S if DEBUG_CLPS711X_UART1 ||
DEBUG_CLPS711X_UART2
default debug/meson.S if DEBUG_MESON_UARTAO
Thanks,
Paul Bolle
--
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 5/5] ARM: omap2plus_defconfig: Enable PCF857X and EXTCON_GPIO_USB
On 19/01/15 21:38, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150119 10:52]: * Roger Quadros rog...@ti.com [150119 09:55]: Both are needed for USB cable type detection on dra7-evm. Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/configs/omap2plus_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index c2c3a85..bc23b90 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -203,6 +203,7 @@ CONFIG_SPI_OMAP24XX=y CONFIG_PINCTRL_SINGLE=y CONFIG_DEBUG_GPIO=y CONFIG_GPIO_SYSFS=y +CONFIG_GPIO_PCF857X=y CONFIG_GPIO_TWL4030=y CONFIG_W1=y CONFIG_BATTERY_BQ27x00=m Looks like I have this too but as a loadable module :) So I'll keep that one. @@ -326,6 +327,7 @@ CONFIG_DMADEVICES=y CONFIG_TI_EDMA=y CONFIG_DMA_OMAP=y CONFIG_EXTCON=y +CONFIG_EXTCON_GPIO_USB=y CONFIG_EXTCON_PALMAS=y CONFIG_PWM=y CONFIG_PWM_TIECAP=y I'll apply this part into omap-for-v3.20/defconfig but make it into =m instead of =y. Oh but this depends on the driver being added, so not applying. Can you please repost a patch adding CONFIG_EXTCON_GPIO_USB=m once the driver is merged? Yes, I'll do that. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: iio: tsl2x7x_core: fix format string warnings
Fixed the following warnings (reported by cppcheck):
[drivers/staging/iio/light/tsl2x7x_core.c:1150]: (warning) %d in format string
(no. 1)
requires 'int' but the argument type is 'unsigned int'.
[drivers/staging/iio/light/tsl2x7x_core.c:1150]: (warning) %d in format string
(no. 2)
requires 'int' but the argument type is 'unsigned int'.
[drivers/staging/iio/light/tsl2x7x_core.c:1150]: (warning) %d in format string
(no. 3)
requires 'int' but the argument type is 'unsigned int'.
Signed-off-by: Asaf Vertz asaf.ve...@tandemg.com
---
drivers/staging/iio/light/tsl2x7x_core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/iio/light/tsl2x7x_core.c
b/drivers/staging/iio/light/tsl2x7x_core.c
index 423f96b..4a5dc26 100644
--- a/drivers/staging/iio/light/tsl2x7x_core.c
+++ b/drivers/staging/iio/light/tsl2x7x_core.c
@@ -1147,7 +1147,7 @@ static ssize_t tsl2x7x_luxtable_show(struct device *dev,
int offset = 0;
while (i (TSL2X7X_MAX_LUX_TABLE_SIZE * 3)) {
- offset += snprintf(buf + offset, PAGE_SIZE, %d,%d,%d,,
+ offset += snprintf(buf + offset, PAGE_SIZE, %u,%u,%u,,
chip-tsl2x7x_device_lux[i].ratio,
chip-tsl2x7x_device_lux[i].ch0,
chip-tsl2x7x_device_lux[i].ch1);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 04/17] ARM64 / ACPI: Introduce early_param for acpi and pass acpi=force to enable ACPI
On 2015年01月20日 02:01, Mark Rutland wrote: On Mon, Jan 19, 2015 at 05:52:33PM +, Catalin Marinas wrote: On Mon, Jan 19, 2015 at 04:59:47PM +, Jon Masters wrote: On 01/19/2015 10:13 AM, Grant Likely wrote: On Mon, 19 Jan 2015 13:51:45 + , Catalin Marinas catalin.mari...@arm.com wrote: On Mon, Jan 19, 2015 at 11:55:32AM +, Ard Biesheuvel wrote: On 19 January 2015 at 11:42, Catalin Marinas catalin.mari...@arm.com wrote: On Wed, Jan 14, 2015 at 03:04:52PM +, Hanjun Guo wrote: From: Al Stone al.st...@linaro.org Introduce one early parameters off and force for acpi, acpi=off will be the default behavior for ARM64, so introduce acpi=force to enable ACPI on ARM64. Disable ACPI before early parameters parsed, and enable it to pass acpi=force if people want use ACPI on ARM64. This ensures DT be the prefer one if ACPI table and DT both are provided at this moment. [...] --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -62,6 +62,7 @@ #include asm/memblock.h #include asm/psci.h #include asm/efi.h +#include asm/acpi.h unsigned int processor_id; EXPORT_SYMBOL(processor_id); @@ -388,6 +389,8 @@ void __init setup_arch(char **cmdline_p) early_fixmap_init(); early_ioremap_init(); + disable_acpi(); + parse_early_param(); /* Did we get to any conclusion here? DT being the preferred one is fine when both DT and ACPI are present but do we still want the kernel to ignore ACPI altogether if DT is not present? It's a bit harder to detect the presence of DT at this point since the EFI_STUB added one already. I guess we could move the acpi=force argument passing to EFI_STUB if no DT is present at boot. Since the EFI stub populates the /chosen node in DT, I would prefer for it to add a property there to indicate whether it created the DT from scratch rather than adding ACPI specific stuff in there (even if it is just a string to concatenate) This works for me. So we could pass acpi=force in EFI stub if it created the DT from scratch *and* ACPI tables are present (can it detect the latter? And maybe it could print something if none are available). If that works, the actual kernel can assume that ACPI needs to be explicitly enabled via acpi=force, irrespective of how much information it has in DT. Ditto for me. I think this is a fine solution. And, yes, the stub can easily detect the presence of ACPI by looking in the UEFI config table. I get the point behind doing this, but could we not have it pass in a different parameter than =force? Perhaps something new? I'd like to separate out the case that it was enabled automatically vs explicitly forced on by a user wanting to use ACPI on a system with both tables. Ard had a point, so we should probably not pass acpi=force from EFI stub (especially since a user may explicitly pass acpi=off irrespective of DT presence). Some other property in the chosen node? It's not even an ABI since that's a contract between EFI stub and the rest of the kernel, so an in-kernel only interface. Not strictly true once kexec is in place. Then it becomes a stub - kernel - kernel - kernel - ... interface, alnog with the rest of the properties the stub puts in the DTB. Having something like /chosen/linux,uefi-stub-generated-dtb sounds sane regardless. How about the patch (just RFC, maybe it is horrible :) ) below: When system supporting both DT and ACPI but firmware providing no dtb, we can use this linux,uefi-stub-generated-dtb property to let kernel know that we can try ACPI configuration data. Signed-off-by: Hanjun Guo hanjun@linaro.org --- Documentation/devicetree/bindings/chosen.txt | 19 arch/arm64/kernel/setup.c| 34 +++- drivers/firmware/efi/libstub/fdt.c | 6 + 3 files changed, 58 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt index ed838f4..18776b9 100644 --- a/Documentation/devicetree/bindings/chosen.txt +++ b/Documentation/devicetree/bindings/chosen.txt @@ -44,3 +44,22 @@ Implementation note: Linux will look for the property linux,stdout-path or on PowerPC stdout if stdout-path is not found. However, the linux,stdout-path and stdout properties are deprecated. New platforms should only use the stdout-path property. + + +linux,uefi-stub-generated-dtb property +-- + +UEFI stub will generate this property in the chosen node to let linux kernel +know that there is no DTB provided by firmware. + +There is a use case for system supporting both DT and ACPI, when firmware +doesn't provide DT, we can try ACPI configration data to boot the system. + +Usage: + +linux,uefi-stub-generated-dtb = true means that it is true that the dtb +is generated by uefi stub + +or + +linux,uefi-stub-generated-dtb = false is the reverse. diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
Re: Logged messages from i915 using kernel 3.19-rc4
On Tue, Jan 20, 2015 at 01:17:10AM -0600, Larry Finger wrote: Hi, I just discovered almost 100 of the following entries in my log: [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before interrupt Those were accumulated in about 12 hours of operation. I also have one that says i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus alignment I got different ones on rc5 :) [0.970103] [drm:intel_set_pch_fifo_underrun_reporting] *ERROR* uncleared pch fifo underrun on pch transcoder A [0.970107] [drm:intel_pch_fifo_underrun_irq_handler] *ERROR* PCH transcoder A FIFO underrun and I'm wondering whether those can be simply shut up or we can actually do something about them... Thanks. -- Regards/Gruss, Boris. -- -- 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/
staging: fbtft: CONFIG_ARCH_BCM2708?
Thomas, Noralf, Your commit c296d5f9957c (staging: fbtft: core support) is included in today's linux-next (ie, next-20150120). I noticed because a script I use to check linux-next spotted a problem in it. See, that commit adds two checks for CONFIG_ARCH_BCM2708. But there's no Kconfig symbol ARCH_BCM2708. (A comment in drivers/mmc/host/sdhci-bcm2835.c does suggest there's an out of tree Main bcm2708 linux port.) Is the code to add the Kconfig symbol ARCH_BCM2708 queued somewhere? Thanks, Paul Bolle -- 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: Behaviour of smp_mb__{before,after}_spin* and acquire/release
On Tue, Jan 13, 2015 at 04:33:54PM +, Will Deacon wrote: Hi Paul, I started dusting off a series I've been working to implement a relaxed atomic API in Linux (i.e. things like atomic_read(v, ACQUIRE)) but I'm having trouble making sense of the ordering semantics we have in mainline today: 2. Does smp_mb__after_unlock_lock order smp_store_release against smp_load_acquire? Again, Documentation/memory-barriers.txt puts these operations into the RELEASE and ACQUIRE classes respectively, but since smp_mb__after_unlock_lock is a NOP everywhere other than PowerPC, I don't think this is enforced by the current code. Yeah, wasn't Paul going to talk to Ben about that? PPC is the only arch that has the weak ACQUIRE/RELEASE for its spinlocks. Most architectures follow the pattern used by asm-generic/barrier.h: release: smp_mb(); STORE acquire: LOAD; smp_mb(); which doesn't provide any release - acquire ordering afaict. Only when combined on the same address, if the LOAD observes the result of the STORE we can guarantee the rest of the ordering. And if you build a locking primitive with them (or circular lists or whatnot) you have that extra condition. But yes, I see your argument that this implementation is weak like the PPC. -- 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] microblaze: Remove *.dtb files in make clean
dts/Makefile is called only for simpleImage target which is causing that *.dtb are not removed. This patch fix it. Signed-off-by: Michal Simek michal.si...@xilinx.com --- arch/microblaze/boot/Makefile | 3 +-- arch/microblaze/boot/dts/Makefile | 2 -- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile index 8e211cc28dac..91d2068da1b9 100644 --- a/arch/microblaze/boot/Makefile +++ b/arch/microblaze/boot/Makefile @@ -34,5 +34,4 @@ $(obj)/simpleImage.%: vmlinux FORCE $(call if_changed,strip) @echo 'Kernel: $@ is ready' ' (#'`cat .version`')' - -clean-files += simpleImage.*.unstrip linux.bin.ub +clean-files += simpleImage.*.unstrip linux.bin.ub dts/*.dtb diff --git a/arch/microblaze/boot/dts/Makefile b/arch/microblaze/boot/dts/Makefile index c4982d16e555..a3d2e42c3c97 100644 --- a/arch/microblaze/boot/dts/Makefile +++ b/arch/microblaze/boot/dts/Makefile @@ -16,5 +16,3 @@ quiet_cmd_cp = CP $ $@$2 # Rule to build device tree blobs DTC_FLAGS := -p 1024 - -clean-files += *.dtb -- 1.8.2.3 pgpTcFgq7ukOQ.pgp Description: PGP signature
Re: [PATCH] staging: iio: ad5933: fix format string warnings
On 01/20/2015 08:25 AM, Asaf Vertz wrote:
Fixed the following warnings (reported by cppcheck):
[drivers/staging/iio/impedance-analyzer/ad5933.c:363]: (warning) %d in format
string (no. 1)
requires 'int' but the argument type is 'unsigned int'.
[drivers/staging/iio/impedance-analyzer/ad5933.c:367]: (warning) %d in format
string (no. 1)
requires 'int' but the argument type is 'unsigned int'.
[drivers/staging/iio/impedance-analyzer/ad5933.c:367]: (warning) %d in format
string (no. 2)
requires 'int' but the argument type is 'unsigned int'.
[drivers/staging/iio/impedance-analyzer/ad5933.c:367]: (warning) %d in format
string (no. 3)
requires 'int' but the argument type is 'unsigned int'.
[drivers/staging/iio/impedance-analyzer/ad5933.c:367]: (warning) %d in format
string (no. 4)
requires 'int' but the argument type is 'unsigned int'.
Signed-off-by: Asaf Vertz asaf.ve...@tandemg.com
Acked-by: Lars-Peter Clausen l...@metafoo.de
Thanks.
---
drivers/staging/iio/impedance-analyzer/ad5933.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
b/drivers/staging/iio/impedance-analyzer/ad5933.c
index b6bd609..4230a43 100644
--- a/drivers/staging/iio/impedance-analyzer/ad5933.c
+++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
@@ -360,11 +360,11 @@ static ssize_t ad5933_show(struct device *dev,
mutex_lock(indio_dev-mlock);
switch ((u32) this_attr-address) {
case AD5933_OUT_RANGE:
- len = sprintf(buf, %d\n,
+ len = sprintf(buf, %u\n,
st-range_avail[(st-ctrl_hb 1) 0x3]);
break;
case AD5933_OUT_RANGE_AVAIL:
- len = sprintf(buf, %d %d %d %d\n, st-range_avail[0],
+ len = sprintf(buf, %u %u %u %u\n, st-range_avail[0],
st-range_avail[3], st-range_avail[2],
st-range_avail[1]);
break;
--
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/2] cpufreq-dt: check CPU clock/power domain during initializing
On 20 January 2015 at 15:39, Viresh Kumar viresh.ku...@linaro.org wrote: On 20 January 2015 at 13:03, Pi-Cheng Chen pi-cheng.c...@linaro.org wrote: I will also try to add intermediate frequency support in next version. Sure BTW, do you think it's a good idea to add a new device tree binding like intermediate_clock = clksys MAINPLL and so that cpufreq-dt could get the intermediate clock? Yeah, we need that. I am trying to implement new opp bindings and will take care of that. Until that time, use platform data to do that. Got it. Thanks. Best Regards, Pi-Cheng -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] compaction: changing initial position of scanners
On 01/19/2015 11:05 AM, Vlastimil Babka wrote: Preliminary testing with THP-like allocations has shown similar improvements, which is somewhat surprising, because THP allocations do not use sync and thus do not defer compaction; but changing the pivot is currently tied to restarting from deferred compaction. Possibly this is due to the other allocation activity than the stress-highalloc test itself. I will post these results when full measurements are done. So here are the full results, before patch 5: 3.19-rc4 3.19-rc4 3.19-rc4 4-thp-1 4-thp-2 4-thp-3 Success 1 Min 24.00 ( 0.00%) 14.00 ( 41.67%) 16.00 ( 33.33%) Success 1 Mean29.80 ( 0.00%) 17.00 ( 42.95%) 19.80 ( 33.56%) Success 1 Max 33.00 ( 0.00%) 25.00 ( 24.24%) 29.00 ( 12.12%) Success 2 Min 26.00 ( 0.00%) 15.00 ( 42.31%) 17.00 ( 34.62%) Success 2 Mean32.60 ( 0.00%) 19.20 ( 41.10%) 21.20 ( 34.97%) Success 2 Max 37.00 ( 0.00%) 28.00 ( 24.32%) 30.00 ( 18.92%) Success 3 Min 85.00 ( 0.00%) 82.00 ( 3.53%) 80.00 ( 5.88%) Success 3 Mean86.20 ( 0.00%) 83.20 ( 3.48%) 81.20 ( 5.80%) Success 3 Max 87.00 ( 0.00%) 84.00 ( 3.45%) 82.00 ( 5.75%) 3.19-rc43.19-rc43.19-rc4 4-thp-1 4-thp-2 4-thp-3 User 6798.70 6905.43 6941.09 System 1064.04 1062.94 1062.76 Elapsed 2108.98 2026.84 2039.40 3.19-rc43.19-rc43.19-rc4 4-thp-1 4-thp-2 4-thp-3 Minor Faults 198099852 197531505 197503750 Major Faults 483 422 490 Swap Ins86 55 113 Swap Outs 3138 887 399 Allocation stalls 652346194816 DMA allocs 20 21 29 DMA32 allocs 124645618 123937328 123927500 Normal allocs 589047575875398258818313 Movable allocs 0 0 0 Direct pages scanned428919 361735 402238 Kswapd pages scanned 2110062 2070576 2042000 Kswapd pages reclaimed 2104207 2067640 2026147 Direct pages reclaimed 427965 361045 401398 Kswapd efficiency 99% 99% 99% Kswapd velocity 1019.4431032.1451015.507 Direct efficiency 99% 99% 99% Direct velocity207.225 180.319 200.037 Percentage direct scans16% 14% 16% Zone normal velocity 408.313 391.138 385.933 Zone dma32 velocity818.355 821.320 829.605 Zone dma velocity0.000
ARM: OMAP3: MACH_OMAP3517EVM?
Tony, Your commit 4d62dbda8561 (ARM: OMAP3: Remove legacy support for am3517-evm) is included in today's linux-next (ie, next-20150120). I noticed because a script I use to check linux-next spotted a problem caused by it. See, your commit removes the Kconfig symbol MACH_OMAP3517EVM. But there's still a reference to that symbol in sound/soc/omap/Kconfig. This means that in linux-next a symbol, SND_OMAP_SOC_AM3517EVM, cannot be set anymore. I assume a patch that address this (either by removing SND_OMAP_SOC_AM3517EVM or by updating its dependencies) is queued somewhere. Is that correct? Thanks, Paul Bolle -- 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/
pull-request: wireless-drivers 2015-01-20
Hi Dave, more fixes for 3.19, I hope these are still appropriate. Please let me know if there are any issues. Kalle The following changes since commit 16dde0d6ac159531a5e03cd3f8bc8a401d9f3fb6: be2net: Allow GRE to work concurrently while a VxLAN tunnel is configured (2015-01-15 01:55:05 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2015-01-20 for you to fetch changes up to e3f31175a3eeb492a6ab788e4fa136c19b43aab4: ath9k: fix race condition in irq processing during hardware reset (2015-01-19 14:32:29 +0200) ath9k: * fix an IRQ storm caused by commit 872b5d814f99 iwlwifi: * A fix for scan that fixes a firmware assertion * A fix that improves roaming behavior. Same fix has been tested for a while in iwldvm. This is a bit of a work around, but the real fix should be in mac80211 and will come later. * A fix for BARs that avoids a WARNING. * one fix for rfkill while scheduled scan is running. Linus's system hit this issue. WiFi would be unavailable after this has happpened because of bad state in cfg80211. David Spinadel (1): iwlwifi: mvm: fix EBS on single scan Emmanuel Grumbach (2): iwlwifi: mvm: drop non VO frames when flushing iwlwifi: mvm: abort scheduled scan upon RFKILL Eyal Shapira (1): iwlwifi: mvm: set the tx cmd tid for BAR frame correctly Felix Fietkau (1): ath9k: fix race condition in irq processing during hardware reset Kalle Valo (2): Merge tag 'iwlwifi-for-kalle-2015-01-13' of https://git.kernel.org/.../iwlwifi/iwlwifi-fixes Merge tag 'iwlwifi-for-kalle-2015-01-15' of https://git.kernel.org/.../iwlwifi/iwlwifi-fixes drivers/net/wireless/ath/ath9k/main.c |7 ++-- drivers/net/wireless/iwlwifi/iwl-fw-file.h |2 + drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h |7 +++- drivers/net/wireless/iwlwifi/mvm/mac80211.c| 20 - drivers/net/wireless/iwlwifi/mvm/scan.c| 53 ++-- drivers/net/wireless/iwlwifi/mvm/tx.c | 11 - 6 files changed, 69 insertions(+), 31 deletions(-) -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] mm/thp: Allocate transparent hugepages on local node
On 01/20/2015 06:52 AM, Aneesh Kumar K.V wrote:
Vlastimil Babka vba...@suse.cz writes:
On 01/17/2015 01:02 AM, Andrew Morton wrote:
On Fri, 16 Jan 2015 12:56:36 +0530 Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
This make sure that we try to allocate hugepages from local node if
allowed by mempolicy. If we can't, we fallback to small page allocation
based on mempolicy. This is based on the observation that allocating pages
on local node is more beneficial than allocating hugepages on remote node.
The changelog is a bit incomplete. It doesn't describe the current
behaviour, nor what is wrong with it. What are the before-and-after
effects of this change?
And what might be the user-visible effects?
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2030,6 +2030,46 @@ retry_cpuset:
return page;
}
+struct page *alloc_hugepage_vma(gfp_t gfp, struct vm_area_struct *vma,
+ unsigned long addr, int order)
alloc_pages_vma() is nicely documented. alloc_hugepage_vma() is not
documented at all. This makes it a bit had for readers to work out the
difference!
Is it possible to scrunch them both into the same function? Probably
too messy?
Hm that could work, alloc_pages_vma already has an if (MPOL_INTERLEAVE)
part, so
just put the THP specialities into an else if (huge_page) part there?
You could probably test for GFP_TRANSHUGE the same way as
__alloc_pages_slowpath
does. There might be false positives theoretically, but is there anything
else
that would use these flags and not be a THP?
is that check correct ? ie,
if ((gfp GFP_TRANSHUGE) == GFP_TRANSHUGE)
may not always indicate transparent hugepage if defrag = 0 . With defrag
cleared, we remove __GFP_WAIT from GFP_TRANSHUGE.
Yep, that looks wrong. Sigh. I guess we can't spare an extra GFP flag to
indicate TRANSHUGE?
static inline gfp_t alloc_hugepage_gfpmask(int defrag, gfp_t extra_gfp)
{
return (GFP_TRANSHUGE ~(defrag ? 0 : __GFP_WAIT)) | extra_gfp;
}
-aneesh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
--
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 00/12] AT91 pm cleanup for 3.20
Hi Nicolas, This patch set is based on Alexandre's patch set of AT91 cleanup for 3.20 #2. It also includes the patches from Peter Rosin and Sylvain Rochet. Removes CONFIG_AT91_SLOW_CLOCK config item to simply the PM config, The suspend to standby mode uses the same sram function as the suspend to memory mode. Remove some unused code. Thank Alexandre for many advices. Best Regards, Wenyou Yang Peter Rosin (1): pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories. Sylvain Rochet (1): pm: at91: pm_slowclock: improve reliability of suspend/resume Wenyou Yang (10): pm: at91: pm_slowclock: remove the unused code related with SLOWDOWN_MASTER_CLOCK pm: at91: move the copying the sram function to the sram initializationi phase ARM: at91: move select SRAM to ARCH_AT91 pm: at91: remove the config item CONFIG_AT91_SLOW_CLOCK pm: at91: the standby mode uses the same sram function as the suspend to memory mode pm: at91: rename file name: pm_slowclock.S --pm_suspend.S pm: at91: rename function name: at91_slow_clock()--at91_pm_suspend_sram_fn pm: at91: remove the at91_xxx_standby() function definitions in the pm.h pm: at91: remove the struct ramc_ids .data at91_xxx_standby members pm: at91: amend the pm_suspend entry for at91_cpuidle_device arch/arm/mach-at91/Kconfig | 15 +- arch/arm/mach-at91/Makefile|2 +- arch/arm/mach-at91/pm.c| 156 - arch/arm/mach-at91/pm.h| 112 + arch/arm/mach-at91/pm_slowclock.S | 322 arch/arm/mach-at91/pm_suspend.S| 278 +++ include/soc/at91/at91sam9_ddrsdr.h |2 +- 7 files changed, 356 insertions(+), 531 deletions(-) delete mode 100644 arch/arm/mach-at91/pm_slowclock.S create mode 100644 arch/arm/mach-at91/pm_suspend.S -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/12] pm: at91: pm_slowclock: improve reliability of suspend/resume
From: Sylvain Rochet sylvain.roc...@finsecur.com
Assume USB PLL and PLL B are already stopped before entering sleep mode,
print a warning if this isn't the case.
Removed timeout on XTAL, PLL lock and Master Clock Ready, hang if
something went wrong instead of continuing in unknown condition. There
is not much we can do if a PLL lock never ends, we are running in SRAM
and we will not be able to connect back the sdram or ddram in order to
be able to fire up a message or just panic.
As a bonus, not decounting the timeout register in slow clock mode
reduce cumulated suspend time and resume time from ~17ms to ~15ms.
Signed-off-by: Sylvain Rochet sylvain.roc...@finsecur.com
---
arch/arm/mach-at91/pm.c | 12 +++
arch/arm/mach-at91/pm_slowclock.S | 62 ++---
2 files changed, 15 insertions(+), 59 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index a4eb290..0990486 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -106,6 +106,18 @@ static int at91_pm_verify_clocks(void)
}
}
+ /* Drivers should have previously suspended USB PLL */
+ if (at91_pmc_read(AT91_CKGR_UCKR) AT91_PMC_UPLLEN) {
+ pr_err(AT91: PM - Suspend-to-RAM with USB PLL running\n);
+ return 0;
+ }
+
+ /* Drivers should have previously suspended PLL B */
+ if (at91_pmc_read(AT91_PMC_SR) AT91_PMC_LOCKB) {
+ pr_err(AT91: PM - Suspend-to-RAM with PLL B running\n);
+ return 0;
+ }
+
return 1;
}
diff --git a/arch/arm/mach-at91/pm_slowclock.S
b/arch/arm/mach-at91/pm_slowclock.S
index 160ba0d..3d497c7 100644
--- a/arch/arm/mach-at91/pm_slowclock.S
+++ b/arch/arm/mach-at91/pm_slowclock.S
@@ -24,11 +24,6 @@
*/
#undef SLOWDOWN_MASTER_CLOCK
-#define MCKRDY_TIMEOUT 1000
-#define MOSCRDY_TIMEOUT1000
-#define PLLALOCK_TIMEOUT 1000
-#define PLLBLOCK_TIMEOUT 1000
-
pmc.reqr0
sdramc .reqr1
ramc1 .reqr2
@@ -40,56 +35,27 @@ tmp2.reqr5
* Wait until master clock is ready (after switching master clock source)
*/
.macro wait_mckrdy
- mov tmp2, #MCKRDY_TIMEOUT
-1: sub tmp2, tmp2, #1
- cmp tmp2, #0
- beq 2f
- ldr tmp1, [pmc, #AT91_PMC_SR]
+1: ldr tmp1, [pmc, #AT91_PMC_SR]
tst tmp1, #AT91_PMC_MCKRDY
beq 1b
-2:
.endm
/*
* Wait until master oscillator has stabilized.
*/
.macro wait_moscrdy
- mov tmp2, #MOSCRDY_TIMEOUT
-1: sub tmp2, tmp2, #1
- cmp tmp2, #0
- beq 2f
- ldr tmp1, [pmc, #AT91_PMC_SR]
+1: ldr tmp1, [pmc, #AT91_PMC_SR]
tst tmp1, #AT91_PMC_MOSCS
beq 1b
-2:
.endm
/*
* Wait until PLLA has locked.
*/
.macro wait_pllalock
- mov tmp2, #PLLALOCK_TIMEOUT
-1: sub tmp2, tmp2, #1
- cmp tmp2, #0
- beq 2f
- ldr tmp1, [pmc, #AT91_PMC_SR]
+1: ldr tmp1, [pmc, #AT91_PMC_SR]
tst tmp1, #AT91_PMC_LOCKA
beq 1b
-2:
- .endm
-
-/*
- * Wait until PLLB has locked.
- */
- .macro wait_pllblock
- mov tmp2, #PLLBLOCK_TIMEOUT
-1: sub tmp2, tmp2, #1
- cmp tmp2, #0
- beq 2f
- ldr tmp1, [pmc, #AT91_PMC_SR]
- tst tmp1, #AT91_PMC_LOCKB
- beq 1b
-2:
.endm
.text
@@ -197,13 +163,6 @@ sdr_sr_done:
orr tmp1, tmp1, #(1 29) /* bit 29 always set */
str tmp1, [pmc, #AT91_CKGR_PLLAR]
- /* Save PLLB setting and disable it */
- ldr tmp1, [pmc, #AT91_CKGR_PLLBR]
- str tmp1, .saved_pllbr
-
- mov tmp1, #AT91_PMC_PLLCOUNT
- str tmp1, [pmc, #AT91_CKGR_PLLBR]
-
/* Turn off the main oscillator */
ldr tmp1, [pmc, #AT91_CKGR_MOR]
bic tmp1, tmp1, #AT91_PMC_MOSCEN
@@ -219,18 +178,6 @@ sdr_sr_done:
wait_moscrdy
- /* Restore PLLB setting */
- ldr tmp1, .saved_pllbr
- str tmp1, [pmc, #AT91_CKGR_PLLBR]
-
- tst tmp1, #(AT91_PMC_MUL 0xff)
- bne 1f
- tst tmp1, #(AT91_PMC_MUL ~0xff)
- beq 2f
-1:
- wait_pllblock
-2:
-
/* Restore PLLA setting */
ldr tmp1, .saved_pllar
str tmp1, [pmc, #AT91_CKGR_PLLAR]
@@ -309,9 +256,6 @@ ram_restored:
.saved_pllar:
.word 0
-.saved_pllbr:
- .word 0
-
.saved_sam9_lpr:
.word 0
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/12] pm: at91: rename function name: at91_slow_clock()--at91_pm_suspend_sram_fn
As the file name's renaming, rename the file name at91_slow_clock()--
at91_pm_suspend_sram_fn, rename the function handler's name at the same time.
Signed-off-by: Wenyou Yang wenyou.y...@atmel.com
Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-at91/pm.c | 23 +++
arch/arm/mach-at91/pm_suspend.S | 26 --
2 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index a1010f0..98dfeb2 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -137,13 +137,12 @@ int at91_suspend_entering_slow_clock(void)
}
EXPORT_SYMBOL(at91_suspend_entering_slow_clock);
-
-static void (*slow_clock)(void __iomem *pmc, void __iomem *ramc0,
+static void (*at91_suspend_sram_fn)(void __iomem *pmc, void __iomem *ramc0,
void __iomem *ramc1, int memctrl);
-extern void at91_slow_clock(void __iomem *pmc, void __iomem *ramc0,
+extern void at91_pm_suspend_in_sram(void __iomem *pmc, void __iomem *ramc0,
void __iomem *ramc1, int memctrl);
-extern u32 at91_slow_clock_sz;
+extern u32 at91_pm_suspend_in_sram_sz;
static void at91_pm_suspend(suspend_state_t state)
{
@@ -152,8 +151,8 @@ static void at91_pm_suspend(suspend_state_t state)
pm_data |= (state == PM_SUSPEND_MEM) ?
(AT91_PM_SLOW_CLOCK AT91_PM_MODE_OFFSET) : 0;
- slow_clock(at91_pmc_base, at91_ramc_base[0],
- at91_ramc_base[1], pm_data);
+ at91_suspend_sram_fn(at91_pmc_base, at91_ramc_base[0],
+ at91_ramc_base[1], pm_data);
}
static int at91_pm_enter(suspend_state_t state)
@@ -253,17 +252,19 @@ static void __init at91_pm_sram_init(void)
goto put_node;
}
- sram_base = gen_pool_alloc(sram_pool, at91_slow_clock_sz);
+ sram_base = gen_pool_alloc(sram_pool, at91_pm_suspend_in_sram_sz);
if (!sram_base) {
pr_warn(%s: unable to alloc ocram!\n, __func__);
goto put_node;
}
sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
- slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz, false);
+ at91_suspend_sram_fn = __arm_ioremap_exec(sram_pbase,
+ at91_pm_suspend_in_sram_sz, false);
- /* Copy slow_clock handler to SRAM, and call it */
- memcpy(slow_clock, at91_slow_clock, at91_slow_clock_sz);
+ /* Copy pm suspend handler to SRAM, and call it */
+ memcpy(at91_suspend_sram_fn,
+ at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
put_node:
of_node_put(node);
@@ -312,8 +313,6 @@ static void __init at91_pm_init(void)
at91_pm_sram_init();
- pr_info(AT91: Power Management%s\n, (slow_clock ? (with slow clock
mode) : ));
-
if (at91_cpuidle_device.dev.platform_data)
platform_device_register(at91_cpuidle_device);
diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 420e730..6c3fc50 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -54,23 +54,21 @@ mode.reqr6
.text
-/* void at91_slow_clock(void __iomem *pmc, void __iomem *sdramc,
+/*
+ * void at91_pm_suspend_in_sram(void __iomem *pmc, void __iomem *sdramc,
* void __iomem *ramc1, int memctrl)
+ * @input param:
+ * @r0: the base address of AT91_PMC
+ * @r1: the base address of SDRAM Controller (SDRAM, DDRSDR, or AT91_SYS)
+ * @r2: the base address of second SDRAM Controller or 0 if not present
+ * @r3: the pm information,
+ * least byte: SDRAM controller type
+ * 2nd byte: 1 - suspend to memory, 0 - standby
*/
-ENTRY(at91_slow_clock)
+ENTRY(at91_pm_suspend_in_sram)
/* Save registers on stack */
stmfd sp!, {r4 - r12, lr}
- /*
-* Register usage:
-* R0 = Base address of AT91_PMC
-* R1 = Base address of RAM Controller (SDRAM, DDRSDR, or AT91_SYS)
-* R2 = Base address of second RAM Controller or 0 if not present
-* R3 = Memory controller
-* R4 = temporary register
-* R5 = temporary register
-*/
-
/* Drain write buffer */
mov tmp1, #0
mcr p15, 0, tmp1, c7, c10, 4
@@ -276,5 +274,5 @@ ram_restored:
.saved_sam9_mdr1:
.word 0
-ENTRY(at91_slow_clock_sz)
- .word .-at91_slow_clock
+ENTRY(at91_pm_suspend_in_sram_sz)
+ .word .-at91_pm_suspend_in_sram
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] mfd: Add support for the MediaTek MT6397 PMIC
From: Flora Fu flora...@mediatek.com
This adds support for the MediaTek MT6397 PMIC. This is a
multifunction device with the following sub modules:
- Regulator
- RTC
- Audio codec
- GPIO
- Clock
It is interfaced to the host controller using SPI interface by a proprietary
hardware called PMIC wrapper or pwrap. MT6397 MFD is a child device of the
pwrap.
Signed-off-by: Flora Fu, MediaTek
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
---
Documentation/devicetree/bindings/mfd/mt6397.txt | 75 +
drivers/mfd/Kconfig | 10 +
drivers/mfd/Makefile | 1 +
drivers/mfd/mt6397-core.c| 251
include/linux/mfd/mt6397/core.h | 76 +
include/linux/mfd/mt6397/registers.h | 362 +++
6 files changed, 775 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/mt6397.txt
create mode 100644 drivers/mfd/mt6397-core.c
create mode 100644 include/linux/mfd/mt6397/core.h
create mode 100644 include/linux/mfd/mt6397/registers.h
diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt
b/Documentation/devicetree/bindings/mfd/mt6397.txt
new file mode 100644
index 000..64ef408
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
@@ -0,0 +1,75 @@
+MediaTek MT6397 Multifunction Device Driver
+
+MT6397 is a multifunction device with the following sub modules:
+- Regulator
+- RTC
+- Audio codec
+- GPIO
+- Clock
+
+It is interfaced to host controller using SPI interface by a proprietary
hardware
+called PMIC wrapper or pwrap. MT6397 MFD is a child device of pwrap.
+See the following for pwarp node definitions:
+Documentation/devicetree/bindings/soc/mediatek,mt8135-pwrap.txt
+
+This document describes the binding for mfd device and its sub module.
+
+Required properties:
+compatible: mediatek,mt6397
+
+Optional properties:
+- codec: Audio codec
+- pinctrl: GPIO in mt6397
+- rtc: RTC
+- clock: clocks in mt6397
+- regulators: regulators in mt6397
+
+Example:
+ pwrap: pwrap@1000f000 {
+ compatible = mediatek,mt8135-pwrap;
+ reg = 0 0x1000f000 0 0x1000,
+ 0 0x11017000 0 0x1000;
+ reg-names = pwrap-base, pwrap-bridge-base;
+ interrupts = GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH;
+ resets = infrarst MT8135_INFRA_PMIC_WRAP_RST,
+ perirst MT8135_PERI_PWRAP_BRIDGE_SW_RST;
+ reset-names = infra-pwrap-rst,
+ peri-pwrap-bridge-rst;
+ clocks = pmicspi_sel, clk26m;
+ clock-names = pmicspi-sel, pmicspi-parent;
+
+ pmic {
+ compatible = mediatek,mt6397;
+
+ codec: mt6397codec {
+ compatible = mediatek,mt6397-codec;
+ };
+
+ pinctrl@0xC000 {
+ compatible = mediatek,mt6397-pinctrl;
+ reg = 0 0xC000 0 0x0108;
+ gpio-controller;
+ };
+
+ mt6397regulator: mt6397regulator {
+ compatible = mediatek,mt6397-regulator;
+
+ mt6397_vpca15_reg: buck_vpca15 {
+ regulator-compatible = buck_vpca15;
+ regulator-name = vpca15;
+ regulator-min-microvolt = 85;
+ regulator-max-microvolt = 140;
+ regulator-ramp-delay = 12500;
+ regulator-always-on;
+ };
+
+ mt6397_vgp4_reg: ldo_vgp4 {
+ regulator-compatible = ldo_vgp4;
+ regulator-name = vgp4;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 330;
+ regulator-enable-ramp-delay = 218;
+ };
+ };
+ };
+ };
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2e6b731..7782e95 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -489,6 +489,16 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MT6397
+ tristate MediaTek MT6397 PMIC Support
+ select MFD_CORE
+ select IRQ_DOMAIN
+ help
+ Say yes here to add support for MediaTek MT6397 PMIC. This is
+ a Power Management IC. This driver provides common support for
+
[PATCH 4/8] soc: mediatek: Add PMIC wrapper for MT8135 and MT6397 SoC
From: Flora Fu flora...@mediatek.com
This adds support for the PMIC wrapper found on MediaTek MT8135 and
MT8173 SoCs.
On MediaTek MT8135, MT8173 and other SoCs the PMIC is connected via
SPI. The SPI master interface is not directly visible to the CPU, but
only through the PMIC wrapper inside the SoC. The communication between
the SoC and the PMIC can optionally be encrypted. Also a non standard
Dual IO SPI mode can be used to increase speed. The MT8135 also supports
a special feature named IP Pairing. With IP Pairing the pins of some
SoC internal peripherals can be on the PMIC. The signals of these pins
are routed over the SPI bus using the pwrap bridge. Because of these
optional non SPI conform features the PMIC driver is not implemented as
a SPI bus master driver.
Signed-off-by: Flora Fu, MediaTek
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
.../devicetree/bindings/soc/mediatek/pwrap.txt | 56 ++
drivers/soc/mediatek/Kconfig |9 +
drivers/soc/mediatek/Makefile |1 +
drivers/soc/mediatek/mtk-pmic-wrap.c | 1025
4 files changed, 1091 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
create mode 100644 drivers/soc/mediatek/mtk-pmic-wrap.c
diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
new file mode 100644
index 000..66cc528
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
@@ -0,0 +1,56 @@
+MediaTek PMIC Wrapper Driver
+
+This document describes the binding for the MediaTek PMIC wrapper.
+
+On MediaTek MT8135, MT8173 and other SoCs the PMIC is connected via
+SPI. The SPI master interface is not directly visible to the CPU, but
+only through the PMIC wrapper inside the SoC. The communication between
+the SoC and the PMIC can optionally be encrypted. Also a non standard
+Dual IO SPI mode can be used to increase speed.
+
+IP Pairing
+
+on MT8135 the pins of some SoC internal peripherals can be on the PMIC.
+The signals of these pins are routed over the SPI bus using the pwrap
+bridge. In the binding description below the properties needed for bridging
+are marked with IP Pairing. These are optional on SoCs which do not support
+IP Pairing
+
+Required properties in pwrap device node.
+- compatible: mediatek,mt8135-pwrap or mediatek,mt8173-pwrap
+- interrupts: IRQ for pwrap in SOC
+- reg-names: Must include the following entries:
+ pwrap: Main registers base
+ pwrap-bridge: bridge base (IP Pairing)
+- reg: Must contain an entry for each entry in reg-names.
+- reset-names: Must include the following entries:
+ pwrap
+ pwrap-bridge (IP Pairing)
+- resets: Must contain an entry for each entry in reset-names.
+- clock-names: Must include the following entries:
+ spi: SPI bus clock
+ wrap: Main module clock
+- clocks: Must contain an entry for each entry in clock-names.
+
+Optional properities:
+- pmic: Mediatek PMIC MFD is the child device of pwrap
+ See the following for child node definitions:
+ Documentation/devicetree/bindings/mfd/mt6397.txt
+
+Example:
+ pwrap: pwrap@1000f000 {
+ compatible = mediatek,mt8135-pwrap;
+ reg = 0 0x1000f000 0 0x1000,
+ 0 0x11017000 0 0x1000;
+ reg-names = pwrap, pwrap-bridge;
+ interrupts = GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH;
+ resets = infracfg MT8135_INFRA_PMIC_WRAP_RST,
+ pericfg MT8135_PERI_PWRAP_BRIDGE_SW_RST;
+ reset-names = pwrap, pwrap-bridge;
+ clocks = clk26m, clk26m;
+ clock-names = spi, wrap;
+
+ pmic {
+ compatible = mediatek,mt6397;
+ };
+ };
diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 9bdb88f..a50f263 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -20,3 +20,12 @@ config MTK_PERICFG
contains several miscellaneous registers for clock, reset and bus
settings. Say yes here if you want to run your kernel on one of these
SoCs.
+
+config MTK_PMIC_WRAP
+ tristate MediaTek PMIC Wrapper Support
+ depends on ARCH_MEDIATEK
+ select REGMAP
+ help
+ Say yes here to add support for MediaTek PMIC Wrapper found
+ on the MT8135 and MT8173 SoCs. The PMIC wrapper is a proprietary
+ hardware to connect the PMIC.
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index e67be7c..a6caa32 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
obj-$(CONFIG_MTK_PERICFG) += mtk-pericfg.o
+obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c
b/drivers/soc/mediatek/mtk-pmic-wrap.c
new file mode 100644
index
[PATCH v2 07/11] powerpc/8xx: macro for handling CPU15 errata
Having a macro will help keep clear code. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr --- v2: no change arch/powerpc/kernel/head_8xx.S | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index a1571b3..065896f 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -297,6 +297,17 @@ SystemCall: * We have to use the MD_xxx registers for the tablewalk because the * equivalent MI_xxx registers only perform the attribute functions. */ + +#ifdef CONFIG_8xx_CPU15 +#define DO_8xx_CPU15(tmp, addr)\ + additmp, addr, PAGE_SIZE; \ + tlbie tmp;\ + additmp, addr, PAGE_SIZE; \ + tlbie tmp +#else +#define DO_8xx_CPU15(tmp, addr) +#endif + InstructionTLBMiss: #ifdef CONFIG_8xx_CPU6 mtspr SPRN_DAR, r3 @@ -304,12 +315,7 @@ InstructionTLBMiss: EXCEPTION_PROLOG_0 mtspr SPRN_SPRG_SCRATCH2, r10 mfspr r10, SPRN_SRR0 /* Get effective address of fault */ -#ifdef CONFIG_8xx_CPU15 - addir11, r10, PAGE_SIZE - tlbie r11 - addir11, r10, -PAGE_SIZE - tlbie r11 -#endif + DO_8xx_CPU15(r11, r10) /* If we are faulting a kernel address, we have to use the * kernel page tables. -- 2.1.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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 00/11] powerpc8xx: Further optimisation of TLB handling
This patchset provides a further optimisation of TLB handling in the 8xx. Main changes are based on: - Using processor handling of PGD/PTE Validity bits instead of testing ourselves the entries validity - Aligning PGD address to allow direct bit manipulation - Not saving registers like CR when not needed It also adds support to any TASK_SIZE Patchset: 01 - powerpc/8xx: remove remaining unnecessary code in FixupDAR 02 - powerpc/8xx: remove tests on PGDIR entry validity 03 - powerpc32: Use kmem_cache memory for PGDIR 04 - powerpc/8xx: Take benefit of aligned PGDIR 05 - powerpc/8xx: Optimise access to swapper_pg_dir 06 - powerpc/8xx: Remove duplicated code in set_context() 07 - powerpc/8xx: macro for handling CPU15 errata 08 - powerpc/8xx: Handle CR out of exception PROLOG/EPILOG 09 - powerpc/8xx: dont save CR in SCRATCH registers 10 - powerpc/8xx: Use SPRG2 instead of DAR for saving r3 11 - powerpc/8xx: Add support for TASK_SIZE greater than 0x8000 All changes have been successfully tested on MPC885 Signed-off-by: Christophe Leroy christophe.le...@c-s.fr Tested-by: Christophe Leroy christophe.le...@c-s.fr --- arch/powerpc/include/asm/pgtable-ppc32.h | 4 + arch/powerpc/kernel/head_8xx.S | 197 +++ arch/powerpc/mm/pgtable_32.c | 16 ++- 3 files changed, 111 insertions(+), 106 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 v4 1/3] pinctrl: add driver for Amlogic Meson SoCs
On Sat, Jan 17, 2015 at 7:15 PM, Beniamino Galvani b.galv...@gmail.com wrote: This is a driver for the pinmux and GPIO controller available in Amlogic Meson SoCs. It currently supports only Meson8, however the common code should be generic enough to work also for other SoCs after having defined the proper set of functions and groups. GPIO interrupts are not supported at the moment due to lack of documentation. Signed-off-by: Beniamino Galvani b.galv...@gmail.com Patch applied. Great work Beniamino! Yours, Linus Walleij -- 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 RFC 0/6] epoll: Introduce new syscall epoll_mod_wait
This adds a new system call, epoll_mod_wait. It's described as below:
NAME
epoll_mod_wait - modify and wait for I/O events on an epoll file
descriptor
SYNOPSIS
int epoll_mod_wait(int epfd, int flags,
int ncmds, struct epoll_mod_cmd *cmds,
struct epoll_wait_spec *spec);
DESCRIPTION
The epoll_mod_wait() system call can be seen as an enhanced combination
of several epoll_ctl(2) calls, which are followed by an epoll_pwait(2)
call. It is superior in two cases:
1) When epoll_ctl(2) are followed by epoll_wait(2), using epoll_mod_wait
will save context switches between user mode and kernel mode;
2) When you need higher precision than microsecond for wait timeout.
The epoll_ctl(2) operations are embedded into this call by with ncmds
and cmds. The latter is an array of command structs:
struct epoll_mod_cmd {
/* Reserved flags for future extension, must be 0 for now. */
int flags;
/* The same as epoll_ctl() op parameter. */
int op;
/* The same as epoll_ctl() fd parameter. */
int fd;
/* The same as the events field in struct epoll_event. */
uint32_t events;
/* The same as the data field in struct epoll_event. */
uint64_t data;
/* Output field, will be set to the return code once this
* command is executed by kernel */
int error;
};
There is no guartantee that all the commands are executed in order. Only
if all the commands are successfully executed (all the error fields are
set to 0), events are polled.
The last parameter spec is a pointer to struct epoll_wait_spec, which
contains the information about how to poll the events. If it's NULL, this
call will immediately return after running all the commands in cmds.
The structure is defined as below:
struct epoll_wait_spec {
/* The same as maxevents in epoll_pwait() */
int maxevents;
/* The same as events in epoll_pwait() */
struct epoll_event *events;
/* Which clock to use for timeout */
int clockid;
/* Maximum time to wait if there is no event */
struct timespec timeout;
/* The same as sigmask in epoll_pwait() */
sigset_t *sigmask;
/* The same as sigsetsize in epoll_pwait() */
size_t sigsetsize;
} EPOLL_PACKED;
RETURN VALUE
When any error occurs, epoll_mod_wait() returns -1 and errno is set
appropriately. All the error fields in cmds are unchanged before they
are executed, and if any cmds are executed, the error fields are set
to a return code accordingly. See also epoll_ctl for more details of the
return code.
When successful, epoll_mod_wait() returns the number of file
descriptors ready for the requested I/O, or zero if no file descriptor
became ready during the requested timeout milliseconds.
If spec is NULL, it returns 0 if all the commands are successful, and -1
if an error occured.
ERRORS
These errors apply on either the return value of epoll_mod_wait or error
status for each command, respectively.
EBADF epfd or fd is not a valid file descriptor.
EFAULT The memory area pointed to by events is not accessible with write
permissions.
EINTR The call was interrupted by a signal handler before either any of
the requested events occurred or the timeout expired; see
signal(7).
EINVAL epfd is not an epoll file descriptor, or maxevents is less than
or equal to zero, or fd is the same as epfd, or the requested
operation op is not supported by this interface.
EEXIST op was EPOLL_CTL_ADD, and the supplied file descriptor fd is
already registered with this epoll instance.
ENOENT op was EPOLL_CTL_MOD or EPOLL_CTL_DEL, and fd is not registered
with this epoll instance.
ENOMEM There was insufficient memory to handle the requested op control
operation.
ENOSPC The limit imposed by /proc/sys/fs/epoll/max_user_watches was
encountered while trying to register (EPOLL_CTL_ADD) a new file
descriptor on an epoll instance. See epoll(7) for further
details.
EPERM The target file fd does not support epoll.
CONFORMING TO
epoll_mod_wait() is Linux-specific.
SEE ALSO
epoll_create(2), epoll_ctl(2), epoll_wait(2), epoll_pwait(2), epoll(7)
Fam
[PATCH v2 08/11] powerpc/8xx: Handle CR out of exception PROLOG/EPILOG
In order to be able to reduce scope during which CR is saved, we take CR saving/restoring out of exception PROLOG and EPILOG Signed-off-by: Christophe Leroy christophe.le...@c-s.fr --- v2: no change arch/powerpc/kernel/head_8xx.S | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index 065896f..27a9997 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -116,13 +116,13 @@ turn_on_mmu: */ #define EXCEPTION_PROLOG \ EXCEPTION_PROLOG_0; \ + mfcrr10;\ EXCEPTION_PROLOG_1; \ EXCEPTION_PROLOG_2 #define EXCEPTION_PROLOG_0 \ mtspr SPRN_SPRG_SCRATCH0,r10; \ - mtspr SPRN_SPRG_SCRATCH1,r11; \ - mfcrr10 + mtspr SPRN_SPRG_SCRATCH1,r11 #define EXCEPTION_PROLOG_1 \ mfspr r11,SPRN_SRR1; /* check whether user or kernel */ \ @@ -162,7 +162,6 @@ turn_on_mmu: * Exception exit code. */ #define EXCEPTION_EPILOG_0 \ - mtcrr10;\ mfspr r10,SPRN_SPRG_SCRATCH0; \ mfspr r11,SPRN_SPRG_SCRATCH1 @@ -313,6 +312,7 @@ InstructionTLBMiss: mtspr SPRN_DAR, r3 #endif EXCEPTION_PROLOG_0 + mfcrr10 mtspr SPRN_SPRG_SCRATCH2, r10 mfspr r10, SPRN_SRR0 /* Get effective address of fault */ DO_8xx_CPU15(r11, r10) @@ -363,6 +363,7 @@ InstructionTLBMiss: mtspr SPRN_DAR, r11 /* Tag DAR */ #endif mfspr r10, SPRN_SPRG_SCRATCH2 + mtcrr10 EXCEPTION_EPILOG_0 rfi @@ -372,6 +373,7 @@ DataStoreTLBMiss: mtspr SPRN_DAR, r3 #endif EXCEPTION_PROLOG_0 + mfcrr10 mtspr SPRN_SPRG_SCRATCH2, r10 mfspr r10, SPRN_MD_EPN @@ -440,6 +442,7 @@ DataStoreTLBMiss: #endif mtspr SPRN_DAR, r11 /* Tag DAR */ mfspr r10, SPRN_SPRG_SCRATCH2 + mtcrr10 EXCEPTION_EPILOG_0 rfi @@ -465,6 +468,7 @@ InstructionTLBError: . = 0x1400 DataTLBError: EXCEPTION_PROLOG_0 + mfcrr10 mfspr r11, SPRN_DAR cmpwi cr0, r11, RPN_PATTERN -- 2.1.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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] gpio/-mm-lantiq: Use devm_kzalloc
On Sun, Jan 18, 2015 at 12:39 PM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: Replace kzalloc with the device managed devm_kzalloc Cc: Linus Walleij linus.wall...@linaro.org Cc: Alexandre Courbot gnu...@gmail.com Cc: John Crispin blo...@openwrt.org Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com Patch applied. Yours, Linus Walleij -- 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 v5 3/5] power: max77693: Add charger driver for Maxim 77693
Add new driver for Maxim 77693 switch-mode charger (part of max77693
MFD driver) providing power supply class information to userspace.
The charger has +20V tolerant input. Current input can be set from 0 to
2.58 A. The charger can deliver up to 2.1 A to the battery or 3.5 A to
the system (when supplying additional current from battery to system).
The driver is configured through DTS (battery and system related
settings) and sysfs entries (timers and top-off charging threshold).
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/power/Kconfig| 6 +
drivers/power/Makefile | 1 +
drivers/power/max77693_charger.c | 758 +++
3 files changed, 765 insertions(+)
create mode 100644 drivers/power/max77693_charger.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index da6981f92697..110d4bc03483 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -332,6 +332,12 @@ config CHARGER_MAX14577
Say Y to enable support for the battery charger control sysfs and
platform data of MAX14577/77836 MUICs.
+config CHARGER_MAX77693
+ tristate Maxim MAX77693 battery charger driver
+ depends on MFD_MAX77693
+ help
+ Say Y to enable support for the Maxim MAX77693 battery charger.
+
config CHARGER_MAX8997
tristate Maxim MAX8997/MAX8966 PMIC battery charger driver
depends on MFD_MAX8997 REGULATOR_MAX8997
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b83a0c749781..31216cb7e8a1 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_CHARGER_LP8788) += lp8788-charger.o
obj-$(CONFIG_CHARGER_GPIO) += gpio-charger.o
obj-$(CONFIG_CHARGER_MANAGER) += charger-manager.o
obj-$(CONFIG_CHARGER_MAX14577) += max14577_charger.o
+obj-$(CONFIG_CHARGER_MAX77693) += max77693_charger.o
obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o
obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o
obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o
diff --git a/drivers/power/max77693_charger.c b/drivers/power/max77693_charger.c
new file mode 100644
index ..56cf2177aad4
--- /dev/null
+++ b/drivers/power/max77693_charger.c
@@ -0,0 +1,758 @@
+/*
+ * max77693_charger.c - Battery charger driver for the Maxim 77693
+ *
+ * Copyright (C) 2014 Samsung Electronics
+ * Krzysztof Kozlowski k.kozlow...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+#include linux/regmap.h
+#include linux/mfd/max77693.h
+#include linux/mfd/max77693-private.h
+
+static const char *max77693_charger_name = max77693-charger;
+static const char *max77693_charger_model = MAX77693;
+static const char *max77693_charger_manufacturer = Maxim Integrated;
+
+struct max77693_charger {
+ struct device *dev;
+ struct max77693_dev *max77693;
+ struct power_supply charger;
+
+ u32 constant_volt;
+ u32 min_system_volt;
+ u32 thermal_regulation_temp;
+ u32 batttery_overcurrent;
+ u32 charge_input_threshold_volt;
+};
+
+static int max77693_get_charger_state(struct regmap *regmap)
+{
+ int state;
+ unsigned int data;
+
+ if (regmap_read(regmap, MAX77693_CHG_REG_CHG_DETAILS_01, data) 0)
+ return POWER_SUPPLY_STATUS_UNKNOWN;
+
+ data = CHG_DETAILS_01_CHG_MASK;
+ data = CHG_DETAILS_01_CHG_SHIFT;
+
+ switch (data) {
+ case MAX77693_CHARGING_PREQUALIFICATION:
+ case MAX77693_CHARGING_FAST_CONST_CURRENT:
+ case MAX77693_CHARGING_FAST_CONST_VOLTAGE:
+ case MAX77693_CHARGING_TOP_OFF:
+ /* In high temp the charging current is reduced, but still charging */
+ case MAX77693_CHARGING_HIGH_TEMP:
+ state = POWER_SUPPLY_STATUS_CHARGING;
+ break;
+ case MAX77693_CHARGING_DONE:
+ state = POWER_SUPPLY_STATUS_FULL;
+ break;
+ case MAX77693_CHARGING_TIMER_EXPIRED:
+ case MAX77693_CHARGING_THERMISTOR_SUSPEND:
+ state = POWER_SUPPLY_STATUS_NOT_CHARGING;
+ break;
+ case MAX77693_CHARGING_OFF:
+ case MAX77693_CHARGING_OVER_TEMP:
+ case MAX77693_CHARGING_WATCHDOG_EXPIRED:
+ state = POWER_SUPPLY_STATUS_DISCHARGING;
+ break;
+ case MAX77693_CHARGING_RESERVED:
+ default:
+
Re: [PATCH 3/8] gpio/mm-lantiq: Do not replicate code
On Sun, Jan 18, 2015 at 12:39 PM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: Do not replicate code from of_mm_gpiochip_add. Cc: Linus Walleij linus.wall...@linaro.org Cc: Alexandre Courbot gnu...@gmail.com Cc: John Crispin blo...@openwrt.org Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com Patch applied. Yours, Linus Walleij -- 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 v5 1/5] devicetree: power/mfd: max77693: Document new bindings for charger
Document new device tree bindings for Maxim 77693 charger driver.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Documentation/devicetree/bindings/mfd/max77693.txt | 45 ++
1 file changed, 45 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt
b/Documentation/devicetree/bindings/mfd/max77693.txt
index 01e9f30fe678..38e64405e98d 100644
--- a/Documentation/devicetree/bindings/mfd/max77693.txt
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -41,6 +41,41 @@ Optional properties:
To get more informations, please refer to documentaion.
[*] refer Documentation/devicetree/bindings/pwm/pwm.txt
+- charger : Node configuring the charger driver.
+ If present, required properties:
+ - compatible : Must be maxim,max77693-charger.
+
+ Optional properties (if not set, defaults will be used):
+ - maxim,constant-microvolt : Battery constant voltage in uV. The charger
+will operate in fast charge constant current mode till battery voltage
+reaches this level. Then the charger will switch to fast charge constant
+voltage mode. Also vsys (system voltage) will be set to this value when
+DC power is supplied but charger is not enabled.
+Valid values: 365 - 440, step by 25000 (rounded down)
+Default: 420
+
+ - maxim,min-system-microvolt : Minimal system voltage in uV.
+Valid values: 300 - 370, step by 10 (rounded down)
+Default: 360
+
+ - maxim,thermal-regulation-celsius : Temperature in Celsius for entering
+high temperature charging mode. If die temperature exceeds this value
+the charging current will be reduced by 105 mA/Celsius.
+Valid values: 70, 85, 100, 115
+Default: 100
+
+ - maxim,battery-overcurrent-microamp : Overcurrent protection threshold
+in uA (current from battery to system).
+Valid values: 200 - 350, step by 25 (rounded down)
+Default: 350
+
+ - maxim,charge-input-threshold-microvolt : Threshold voltage in uV for
+triggering input voltage regulation loop. If input voltage decreases
+below this value, the input current will be reduced to reach the
+threshold voltage.
+Valid values: 430, 470, 480, 490
+Default: 430
+
Example:
max77693@66 {
compatible = maxim,max77693;
@@ -73,4 +108,14 @@ Example:
pwms = pwm 0 4 0;
pwm-names = haptic;
};
+
+ charger {
+ compatible = maxim,max77693-charger;
+
+ maxim,constant-microvolt = 420;
+ maxim,min-system-microvolt = 360;
+ maxim,thermal-regulation-celsius = 75;
+ maxim,battery-overcurrent-microamp = 300;
+ maxim,charge-input-threshold-microvolt = 430;
+ };
};
--
1.9.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/
Re: [PATCH 3.19-rc2 v14 0/7] arm: Implement arch_trigger_all_cpu_backtrace
On 13/01/15 10:26, Daniel Thompson wrote: Hi Thomas, Hi Jason: Patches 1 to 3 are for you (and should be separable from the rest of the series). The patches haven't changes since the last time I posted them. The changes in v14 tidy up the later part of the patch set in order to share more code between x86 and arm. No review comments! Have I finally got this right? If so it possible and/or sensible to get patches 1-3 in a tree that feeds linux-next. I'd really like the gic changes to meet the various ARM build and boot bots. Daniel. This patchset modifies the GIC driver to allow it, on supported platforms, to route IPI interrupts to FIQ and uses this feature to implement arch_trigger_all_cpu_backtrace for arm. On platforms not capable of supporting FIQ the signal to generate a backtrace we fall back to using IRQ for propagation instead (relying on a timeout to avoid wedging the CPU requesting the backtrace if other CPUs are not responsive). It has been tested on two systems capable of supporting grouping (Freescale i.MX6 and STiH416) and two that do not (vexpress-a9 and Qualcomm Snapdragon 600). v14: * Moved a nmi_vprintk() and friends from arch/x86/kernel/apic/hw_nmi.c to printk.c (Steven Rostedt) v13: * Updated the code to print the backtrace to replicate Steven Rostedt's x86 work to make SysRq-l safe. This is pretty much a total rewrite of patches 4 and 5. v12: * Squash first two patches into a single one and re-describe (Thomas Gleixner). * Improve description of irqchip: gic: Make gic_raise_softirq FIQ-safe (Thomas Gleixner). v11: * Optimized gic_raise_softirq() by replacing a register read with a memory read (Jason Cooper). v10: * Add a further patch to optimize away some of the locking on systems where CONFIG_BL_SWITCHER is not set (Marc Zyngier). Compiles OK with exynos_defconfig (which is the only defconfig to set this option). * Whitespace fixes in patch 4. That patch previously used spaces for alignment of new constants but the rest of the file used tabs. v9: * Improved documentation and structure of initial patch (now initial two patches) to make gic_raise_softirq() safe to call from FIQ (Thomas Gleixner). * Avoid masking interrupts during gic_raise_softirq(). The use of the read lock makes this redundant (because we can safely re-enter the function). v8: * Fixed build on arm64 causes by a spurious include file in irq-gic.c. v7-2 (accidentally released twice with same number): * Fixed boot regression on vexpress-a9 (reported by Russell King). * Rebased on v3.18-rc3; removed one patch from set that is already included in mainline. * Dropped arm64/fiq.h patch from the set (still useful but not related to issuing backtraces). v7: * Re-arranged code within the patch series to fix a regression introduced midway through the series and corrected by a later patch (testing by Olof's autobuilder). Tested offending patch in isolation using defconfig identified by the autobuilder. v6: * Renamed svc_entry's call_trace argument to just trace (example code from Russell King). * Fixed mismatched ENDPROC() in __fiq_abt (example code from Russell King). * Modified usr_entry to optional avoid calling into the trace code and used this in FIQ entry from usr path. Modified corresponding exit code to avoid calling into trace code and the scheduler (example code from Russell King). * Ensured the default FIQ register state is restored when the default FIQ handler is reinstalled (example code from Russell King). * Renamed no_fiq_insn to dfl_fiq_insn to reflect the effect of adopting a default FIQ handler. * Re-instated fiq_safe_migration_lock and associated logic in gic_raise_softirq(). gic_raise_softirq() is called by wake_up_klogd() in the console unlock logic. v5: * Rebased on 3.17-rc4. * Removed a spurious line from the final glue it together patch that broke the build. v4: * Replaced push/pop with stmfd/ldmfd respectively (review of Nicolas Pitre). * Really fix bad pt_regs pointer generation in __fiq_abt. * Remove fiq_safe_migration_lock and associated logic in gic_raise_softirq() (review of Russell King) * Restructured to introduce the default FIQ handler first, before the new features (review of Russell King). v3: * Removed redundant header guards from arch/arm64/include/asm/fiq.h (review of Catalin Marinas). * Moved svc_exit_via_fiq macro to entry-header.S (review of Nicolas Pitre). v2: * Restructured to sit nicely on a similar FYI patchset from Russell King. It now effectively replaces the work in progress final patch with something much more complete. * Implemented (and tested) a Thumb-2 implementation of svc_exit_via_fiq (review of Nicolas Pitre) * Dropped the GIC group 0 workaround patch. The issue of FIQ interrupts being
Re: [PATCH v3 2/3] mfd: lubbock_io: add lubbock_io board
On Mon, 19 Jan 2015, Robert Jarzmik wrote:
Lee Jones lee.jo...@linaro.org writes:
On Fri, 16 Jan 2015, Robert Jarzmik wrote:
[...]
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
platform_get_irq()?
No. I need the flags.
Where are they used?
[...]
+ if (ret) {
+ dev_err(pdev-dev, Couldn't request main irq : ret = %d\n,
+ ret);
I'm not keen on this type of formatting. Besides the system will
print out the returned error on failure.
Well, it will print -EINVAL or -ENODEV. When I'll receive an request on the
driver with -ENODEV, how will I know it will come from this request_irq() or
another part of the code ... Well I can remove it if you want, but I think
it's
an error.
I'm not asking you to remove the entire message, just the junk at the
end.
--
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 v7 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support
Hi Marc,
On 16.01.2015 12:15, Marc Zyngier wrote:
On 14/01/15 15:05, Hanjun Guo wrote:
From: Tomasz Nowicki tomasz.nowi...@linaro.org
ACPI kernel uses MADT table for proper GIC initialization. It needs to
parse GIC related subtables, collect CPU interface and distributor
addresses and call driver initialization function (which is hardware
abstraction agnostic). In a similar way, FDT initialize GICv1/2.
NOTE: This commit allow to initialize GICv1/2 basic functionality.
GICv2 vitalization extension, GICv3/4 and ITS are considered as next
steps.
And so is GICv2m, apparently (see below).
Tested-by: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
Tested-by: Yijing Wang wangyij...@huawei.com
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
Signed-off-by: Hanjun Guo hanjun@linaro.org
---
arch/arm64/kernel/acpi.c | 26 +
drivers/irqchip/irq-gic.c| 108 +++
drivers/irqchip/irqchip.c| 3 +
include/linux/irqchip/arm-gic-acpi.h | 31 ++
4 files changed, 168 insertions(+)
create mode 100644 include/linux/irqchip/arm-gic-acpi.h
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index c3e24c4..ea3c9fc 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -23,6 +23,7 @@
#include linux/irqdomain.h
#include linux/bootmem.h
#include linux/smp.h
+#include linux/irqchip/arm-gic-acpi.h
#include asm/cputype.h
#include asm/cpu_ops.h
@@ -315,6 +316,31 @@ void __init acpi_boot_table_init(void)
pr_err(Can't find FADT or error happened during parsing
FADT\n);
}
+void __init acpi_gic_init(void)
+{
+ struct acpi_table_header *table;
+ acpi_status status;
+ acpi_size tbl_size;
+ int err;
+
+ if (acpi_disabled)
+ return;
+
+ status = acpi_get_table_with_size(ACPI_SIG_MADT, 0, table, tbl_size);
+ if (ACPI_FAILURE(status)) {
+ const char *msg = acpi_format_exception(status);
+
+ pr_err(Failed to get MADT table, %s\n, msg);
+ return;
+ }
+
+ err = gic_v2_acpi_init(table);
+ if (err)
+ pr_err(Failed to initialize GIC IRQ controller);
+
+ early_acpi_os_unmap_memory((char *)table, tbl_size);
+}
+
static int __init parse_acpi(char *arg)
{
if (!arg)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index d617ee5..89a8120 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -33,12 +33,14 @@
#include linux/of.h
#include linux/of_address.h
#include linux/of_irq.h
+#include linux/acpi.h
#include linux/irqdomain.h
#include linux/interrupt.h
#include linux/percpu.h
#include linux/slab.h
#include linux/irqchip/chained_irq.h
#include linux/irqchip/arm-gic.h
+#include linux/irqchip/arm-gic-acpi.h
#include asm/cputype.h
#include asm/irq.h
@@ -1083,3 +1085,109 @@ IRQCHIP_DECLARE(msm_8660_qgic, qcom,msm-8660-qgic,
gic_of_init);
IRQCHIP_DECLARE(msm_qgic2, qcom,msm-qgic2, gic_of_init);
#endif
+
+#ifdef CONFIG_ACPI
+static phys_addr_t dist_phy_base, cpu_phy_base;
+static int cpu_base_assigned;
+
+static int __init
+gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+ struct acpi_madt_generic_interrupt *processor;
+ phys_addr_t gic_cpu_base;
+
+ processor = (struct acpi_madt_generic_interrupt *)header;
+
+ if (BAD_MADT_ENTRY(processor, end))
+ return -EINVAL;
+
+ /*
+* There is no support for non-banked GICv1/2 register in ACPI spec.
+* All CPU interface addresses have to be the same.
+*/
+ gic_cpu_base = processor-base_address;
+ if (cpu_base_assigned gic_cpu_base != cpu_phy_base)
+ return -EFAULT;
EFAULT? That feels weird. This error code should be returned if an
access would generate (or has actually generated) a fault, but this is
not the case here. Same for the other cases below.
Right, will fix that and other cases too.
+
+ cpu_phy_base = gic_cpu_base;
+ cpu_base_assigned = 1;
+ return 0;
+}
+
+static int __init
+gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+ struct acpi_madt_generic_distributor *dist;
+
+ dist = (struct acpi_madt_generic_distributor *)header;
+
+ if (BAD_MADT_ENTRY(dist, end))
+ return -EINVAL;
+
+ dist_phy_base = dist-base_address;
+ return 0;
+}
+
+int __init
+gic_v2_acpi_init(struct acpi_table_header *table)
+{
+ void __iomem *cpu_base, *dist_base;
+ int count;
+
+ /* Collect CPU base addresses */
+ count = acpi_parse_entries(ACPI_SIG_MADT,
+ sizeof(struct acpi_table_madt),
+ gic_acpi_parse_madt_cpu, table,
+
[PATCH 21/36] drm/tegra: dc: Do not needlessly deassert reset
From: Thierry Reding tred...@nvidia.com Commit 9c0127004ff4 (drm/tegra: dc: Add powergate support) changed the driver's -probe() implementation to deassert the module reset, and with there being nobody else to assert it until -remove() there is no need to deassert again later on. Signed-off-by: Thierry Reding tred...@nvidia.com --- drivers/gpu/drm/tegra/dc.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 462945abded2..846daf48cf61 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -1160,10 +1160,6 @@ static void tegra_crtc_prepare(struct drm_crtc *crtc) drm_crtc_vblank_off(crtc); - /* hardware initialization */ - reset_control_deassert(dc-rst); - usleep_range(1, 2); - if (dc-pipe) syncpt = SYNCPT_VBLANK1; else -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 04/17] ARM64 / ACPI: Introduce early_param for acpi and pass acpi=force to enable ACPI
On Tue, Jan 20, 2015 at 09:29:14AM +, Hanjun Guo wrote: On 2015年01月20日 02:01, Mark Rutland wrote: On Mon, Jan 19, 2015 at 05:52:33PM +, Catalin Marinas wrote: On Mon, Jan 19, 2015 at 04:59:47PM +, Jon Masters wrote: On 01/19/2015 10:13 AM, Grant Likely wrote: On Mon, 19 Jan 2015 13:51:45 + , Catalin Marinas catalin.mari...@arm.com wrote: On Mon, Jan 19, 2015 at 11:55:32AM +, Ard Biesheuvel wrote: On 19 January 2015 at 11:42, Catalin Marinas catalin.mari...@arm.com wrote: On Wed, Jan 14, 2015 at 03:04:52PM +, Hanjun Guo wrote: From: Al Stone al.st...@linaro.org Introduce one early parameters off and force for acpi, acpi=off will be the default behavior for ARM64, so introduce acpi=force to enable ACPI on ARM64. Disable ACPI before early parameters parsed, and enable it to pass acpi=force if people want use ACPI on ARM64. This ensures DT be the prefer one if ACPI table and DT both are provided at this moment. [...] --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -62,6 +62,7 @@ #include asm/memblock.h #include asm/psci.h #include asm/efi.h +#include asm/acpi.h unsigned int processor_id; EXPORT_SYMBOL(processor_id); @@ -388,6 +389,8 @@ void __init setup_arch(char **cmdline_p) early_fixmap_init(); early_ioremap_init(); + disable_acpi(); + parse_early_param(); /* Did we get to any conclusion here? DT being the preferred one is fine when both DT and ACPI are present but do we still want the kernel to ignore ACPI altogether if DT is not present? It's a bit harder to detect the presence of DT at this point since the EFI_STUB added one already. I guess we could move the acpi=force argument passing to EFI_STUB if no DT is present at boot. Since the EFI stub populates the /chosen node in DT, I would prefer for it to add a property there to indicate whether it created the DT from scratch rather than adding ACPI specific stuff in there (even if it is just a string to concatenate) This works for me. So we could pass acpi=force in EFI stub if it created the DT from scratch *and* ACPI tables are present (can it detect the latter? And maybe it could print something if none are available). If that works, the actual kernel can assume that ACPI needs to be explicitly enabled via acpi=force, irrespective of how much information it has in DT. Ditto for me. I think this is a fine solution. And, yes, the stub can easily detect the presence of ACPI by looking in the UEFI config table. I get the point behind doing this, but could we not have it pass in a different parameter than =force? Perhaps something new? I'd like to separate out the case that it was enabled automatically vs explicitly forced on by a user wanting to use ACPI on a system with both tables. Ard had a point, so we should probably not pass acpi=force from EFI stub (especially since a user may explicitly pass acpi=off irrespective of DT presence). Some other property in the chosen node? It's not even an ABI since that's a contract between EFI stub and the rest of the kernel, so an in-kernel only interface. Not strictly true once kexec is in place. Then it becomes a stub - kernel - kernel - kernel - ... interface, alnog with the rest of the properties the stub puts in the DTB. Having something like /chosen/linux,uefi-stub-generated-dtb sounds sane regardless. How about the patch (just RFC, maybe it is horrible :) ) below: When system supporting both DT and ACPI but firmware providing no dtb, we can use this linux,uefi-stub-generated-dtb property to let kernel know that we can try ACPI configuration data. Signed-off-by: Hanjun Guo hanjun@linaro.org I'm ok with the idea but I'll let Mark comment on the DT aspects. -- Catalin -- 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 23/36] drm/tegra: Atomic conversion, phase 2
From: Thierry Reding tred...@nvidia.com
Hook up the default -reset() and -atomic_duplicate_state() helpers.
This ensures that state objects are properly created and framebuffer
reference counts correctly maintained.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/gpu/drm/tegra/dc.c | 12
drivers/gpu/drm/tegra/drm.c | 2 ++
drivers/gpu/drm/tegra/dsi.c | 2 ++
drivers/gpu/drm/tegra/hdmi.c | 2 ++
drivers/gpu/drm/tegra/rgb.c | 2 ++
drivers/gpu/drm/tegra/sor.c | 2 ++
6 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index e7efb6ca127c..cb2bd0088295 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -25,6 +25,7 @@
#include drm.h
#include gem.h
+#include drm/drm_atomic.h
#include drm/drm_atomic_helper.h
#include drm/drm_plane_helper.h
@@ -406,6 +407,8 @@ static const struct drm_plane_funcs
tegra_primary_plane_funcs = {
.update_plane = drm_plane_helper_update,
.disable_plane = drm_plane_helper_disable,
.destroy = tegra_primary_plane_destroy,
+ .reset = drm_atomic_helper_plane_reset,
+ .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
};
@@ -690,6 +693,8 @@ static const struct drm_plane_funcs
tegra_cursor_plane_funcs = {
.update_plane = drm_plane_helper_update,
.disable_plane = drm_plane_helper_disable,
.destroy = tegra_plane_destroy,
+ .reset = drm_atomic_helper_plane_reset,
+ .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
};
@@ -738,6 +743,8 @@ static const struct drm_plane_funcs
tegra_overlay_plane_funcs = {
.update_plane = drm_plane_helper_update,
.disable_plane = drm_plane_helper_disable,
.destroy = tegra_overlay_plane_destroy,
+ .reset = drm_atomic_helper_plane_reset,
+ .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
};
@@ -990,6 +997,9 @@ static int tegra_dc_page_flip(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
drm_crtc_vblank_get(crtc);
}
+ if (crtc-primary-state)
+ drm_atomic_set_fb_for_plane(crtc-primary-state, fb);
+
tegra_dc_set_base(dc, 0, 0, fb);
crtc-primary-fb = fb;
@@ -1005,6 +1015,8 @@ static const struct drm_crtc_funcs tegra_crtc_funcs = {
.page_flip = tegra_dc_page_flip,
.set_config = drm_crtc_helper_set_config,
.destroy = tegra_dc_destroy,
+ .reset = drm_atomic_helper_crtc_reset,
+ .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
};
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 3326df252c52..58a4ed192e61 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -77,6 +77,8 @@ static int tegra_drm_load(struct drm_device *drm, unsigned
long flags)
if (err 0)
goto fbdev;
+ drm_mode_config_reset(drm);
+
/*
* We don't use the drm_irq_install() helpers provided by the DRM
* core, so we need to set this manually in order to allow the
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index 4bb06c119a18..9799f3edc3f8 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -734,9 +734,11 @@ static void tegra_dsi_connector_dpms(struct drm_connector
*connector, int mode)
static const struct drm_connector_funcs tegra_dsi_connector_funcs = {
.dpms = tegra_dsi_connector_dpms,
+ .reset = drm_atomic_helper_connector_reset,
.detect = tegra_output_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = tegra_output_connector_destroy,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index bf868d54ef7e..728681a3f8c9 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -779,9 +779,11 @@ static void tegra_hdmi_connector_dpms(struct drm_connector
*connector,
static const struct drm_connector_funcs tegra_hdmi_connector_funcs = {
.dpms = tegra_hdmi_connector_dpms,
+ .reset = drm_atomic_helper_connector_reset,
.detect = tegra_output_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = tegra_output_connector_destroy,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
diff --git a/drivers/gpu/drm/tegra/rgb.c
Re: [PATCH v3 00/13] Add kdbus implementation
On Tue, Jan 20, 2015 at 09:13:59AM +0800, Greg Kroah-Hartman wrote: On Tue, Jan 20, 2015 at 12:38:12AM +0100, Johannes Stezenbach wrote: Those automotive applications you were talking about, what was the OS they were ported from and what was the messaging API they used? They were ported from QNX and I don't know the exact api, it is wrapped up in a library layer for them to use. And typically, they run about 40 thousand messages in the first few seconds of startup time. Or was it 400 thousand? Something huge and crazy to be doing on tiny ARM chips, but that's the IVI industry for you :( So I did some googling and found in QNX servers create a channel to receive messages, and clients connect to this channel. Multiple clients can connect to the channel. But it is not a bus -- no multicast/broadcast, and no name service or policy rules like D-Bus has. To me it looks to be similar in functionality to UNIX domain sockets. My guess is that the people porting from QNX were just confused and their use of D-Bus was in error. Maybe they should've used plain sockets, capnproto, ZeroMQ or whatever. As I said before, I'm seeing about a dozen D-Bus messages per minute, nothing that would justify adding kdbus to the kernel for performance reasons. Wrt security I'm also not aware of any open issues with D-Bus. Thus I doubt normal users of D-Bus would see any benefit from kdbus. I also think none of the applications I can install from my distribution has any performance issue with D-Bus. That's because people have not done anything really needing performance on the desktop over D-Bus in the past due to how slow the current implementation is. Now that this is being resolved, that can change, and there are demos out there of even streaming audio over kdbus with no problems. But performance is not just the only reason we want this in the kernel, I listed a whole long range of them. Sure, it's great to now be faster, cutting down the number of context switches and copies by a huge amount, but the other things are equally important for future development (namespaces, containers, security, early-boot, etc.) And this is the point where I ask myself if I missed something. Don't focus purely on performance for your existing desktop system, that's not the only use case here. There are lots of others, as I document, that can benefit and want this. One fun thing I've been talking to someone about is the ability to even port binder to be on top of kdbus. But that's just a research project, and requires some API changes on the userspace binder side, but it shows real promise, and would then mean that we could deprecate the old binder code and a few hundred million devices could then use kdbus instead. But that's long-term goals, not really all that relevant here, but it shows that having a solid bus IPC mechanism is a powerful thing that we have been missing in the past from Linux. Well, IMHO you got it backwards. Before adding a complex new IPC API to the kernel you should do the homework and gather some evidence that there will be enough users to justify the addition. But maybe I misunderstood the purpose of this thread and you're just advertising it to find possible users instead of already suggesting to merge it? If someone has some convincing story to share why kdbus would solve their IPC needs, I'm all ears. (I'm sorry this implies your responses so far were not convincing: not verifiable facts, no numbers, no testimonials etc.) FWIW, my gut feeling was that the earlier attempts to add a new IPC primitve like multicast UNIX domain sockets http://thread.gmane.org/gmane.linux.kernel/1255575/focus=1257999 were a much saner approach. But now I think the comments from this old thread have not been addressed, instead the new approach just made the thing more complex and put in ipc/ instead of net/ to bypass the guards. Thanks, Johannes -- 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 12/36] drm/tegra: output: Make -setup_clock() optional
From: Thierry Reding tred...@nvidia.com
In order to transition output drivers to using the struct tegra_output
as a helper rather than midlayer, make this callback optional. Instead
drivers should implement the equivalent as part of -mode_fixup(). For
the conversion to atomic modesetting a new callback -atomic_check()
should be implemented that updates the display controller's state with
the corresponding parent clock, rate and shift clock divider.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/gpu/drm/tegra/dc.c | 10 +-
drivers/gpu/drm/tegra/drm.h | 10 --
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 9cee6465b753..46fde25863a2 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1074,10 +1074,18 @@ static int tegra_crtc_setup_clk(struct drm_crtc *crtc,
return -ENODEV;
/*
+* The -setup_clock() callback is optional, but if encoders don't
+* implement it they most likely need to do the equivalent within the
+* -mode_fixup() callback.
+*/
+ if (!output-ops || !output-ops-setup_clock)
+ return 0;
+
+ /*
* This assumes that the parent clock is pll_d_out0 or pll_d2_out
* respectively, each of which divides the base pll_d by 2.
*/
- err = tegra_output_setup_clock(output, dc-clk, pclk, div);
+ err = output-ops-setup_clock(output, dc-clk, pclk, div);
if (err 0) {
dev_err(dc-dev, failed to setup clock: %ld\n, err);
return err;
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index bf749ac4a344..d7433976a40b 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -240,16 +240,6 @@ static inline int tegra_output_disable(struct tegra_output
*output)
return output ? -ENOSYS : -EINVAL;
}
-static inline int tegra_output_setup_clock(struct tegra_output *output,
- struct clk *clk, unsigned long pclk,
- unsigned int *div)
-{
- if (output output-ops output-ops-setup_clock)
- return output-ops-setup_clock(output, clk, pclk, div);
-
- return output ? -ENOSYS : -EINVAL;
-}
-
static inline int tegra_output_check_mode(struct tegra_output *output,
struct drm_display_mode *mode,
enum drm_mode_status *status)
--
2.1.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 25/36] drm/tegra: dc: Store clock setup in atomic state
From: Thierry Reding tred...@nvidia.com
This allows the clock setup to be separated from the clock programming
and better matches the expectations of the atomic modesetting where no
code paths must fail during modeset.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/gpu/drm/tegra/dc.c | 76 +++--
drivers/gpu/drm/tegra/drm.h | 4 +++
2 files changed, 77 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 469bfa0fe096..1d8052a8d4c3 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -48,6 +48,22 @@ static inline struct tegra_plane *to_tegra_plane(struct
drm_plane *plane)
return container_of(plane, struct tegra_plane, base);
}
+struct tegra_dc_state {
+ struct drm_crtc_state base;
+
+ struct clk *clk;
+ unsigned long pclk;
+ unsigned int div;
+};
+
+static inline struct tegra_dc_state *to_dc_state(struct drm_crtc_state *state)
+{
+ if (state)
+ return container_of(state, struct tegra_dc_state, base);
+
+ return NULL;
+}
+
static void tegra_dc_window_commit(struct tegra_dc *dc, unsigned int index)
{
u32 value = WIN_A_ACT_REQ index;
@@ -1011,13 +1027,48 @@ static void tegra_dc_destroy(struct drm_crtc *crtc)
drm_crtc_cleanup(crtc);
}
+static void tegra_crtc_reset(struct drm_crtc *crtc)
+{
+ struct tegra_dc_state *state;
+
+ kfree(crtc-state);
+ crtc-state = NULL;
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (state)
+ crtc-state = state-base;
+}
+
+static struct drm_crtc_state *
+tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
+{
+ struct tegra_dc_state *state = to_dc_state(crtc-state);
+ struct tegra_dc_state *copy;
+
+ copy = kmemdup(state, sizeof(*state), GFP_KERNEL);
+ if (!copy)
+ return NULL;
+
+ copy-base.mode_changed = false;
+ copy-base.planes_changed = false;
+ copy-base.event = NULL;
+
+ return copy-base;
+}
+
+static void tegra_crtc_atomic_destroy_state(struct drm_crtc *crtc,
+ struct drm_crtc_state *state)
+{
+ kfree(state);
+}
+
static const struct drm_crtc_funcs tegra_crtc_funcs = {
.page_flip = tegra_dc_page_flip,
.set_config = drm_crtc_helper_set_config,
.destroy = tegra_dc_destroy,
- .reset = drm_atomic_helper_crtc_reset,
- .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+ .reset = tegra_crtc_reset,
+ .atomic_duplicate_state = tegra_crtc_atomic_duplicate_state,
+ .atomic_destroy_state = tegra_crtc_atomic_destroy_state,
};
static void tegra_dc_stop(struct tegra_dc *dc)
@@ -1155,6 +1206,25 @@ int tegra_dc_setup_clock(struct tegra_dc *dc, struct clk
*parent,
return 0;
}
+int tegra_dc_state_setup_clock(struct tegra_dc *dc,
+ struct drm_crtc_state *crtc_state,
+ struct clk *clk, unsigned long pclk,
+ unsigned int div)
+{
+ struct tegra_dc_state *state = to_dc_state(crtc_state);
+ int err;
+
+ err = clk_try_parent(dc-clk, clk);
+ if (err 0)
+ return err;
+
+ state-clk = clk;
+ state-pclk = pclk;
+ state-div = div;
+
+ return 0;
+}
+
static void tegra_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct drm_display_mode *mode = crtc-state-adjusted_mode;
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index bf1c47ec46b6..3db719de312f 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -180,6 +180,10 @@ void tegra_dc_cancel_page_flip(struct drm_crtc *crtc,
struct drm_file *file);
void tegra_dc_commit(struct tegra_dc *dc);
int tegra_dc_setup_clock(struct tegra_dc *dc, struct clk *parent,
unsigned long pclk, unsigned int div);
+int tegra_dc_state_setup_clock(struct tegra_dc *dc,
+ struct drm_crtc_state *crtc_state,
+ struct clk *clk, unsigned long pclk,
+ unsigned int div);
struct tegra_output {
struct device_node *of_node;
--
2.1.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 26/36] drm/tegra: rgb: Implement -atomic_check()
From: Thierry Reding tred...@nvidia.com
The implementation of the -atomic_check() callback precomputes all
parameters to check if the given configuration can be applied. If so the
precomputed values are stored in the atomic state object for the encoder
and applied during modeset. In that way the modeset no longer needs to
perform any checking but simply program values into registers.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/gpu/drm/tegra/rgb.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
index 78e3cb1529d0..be1b38936dbe 100644
--- a/drivers/gpu/drm/tegra/rgb.c
+++ b/drivers/gpu/drm/tegra/rgb.c
@@ -235,6 +235,47 @@ static void tegra_rgb_encoder_disable(struct drm_encoder
*encoder)
drm_panel_unprepare(output-panel);
}
+static int
+tegra_rgb_encoder_atomic_check(struct drm_encoder *encoder,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ struct tegra_output *output = encoder_to_output(encoder);
+ struct tegra_dc *dc = to_tegra_dc(conn_state-crtc);
+ unsigned long pclk = crtc_state-mode.clock * 1000;
+ struct tegra_rgb *rgb = to_rgb(output);
+ unsigned int div;
+ int err;
+
+ /*
+* We may not want to change the frequency of the parent clock, since
+* it may be a parent for other peripherals. This is due to the fact
+* that on Tegra20 there's only a single clock dedicated to display
+* (pll_d_out0), whereas later generations have a second one that can
+* be used to independently drive a second output (pll_d2_out0).
+*
+* As a way to support multiple outputs on Tegra20 as well, pll_p is
+* typically used as the parent clock for the display controllers.
+* But this comes at a cost: pll_p is the parent of several other
+* peripherals, so its frequency shouldn't change out of the blue.
+*
+* The best we can do at this point is to use the shift clock divider
+* and hope that the desired frequency can be matched (or at least
+* matched sufficiently close that the panel will still work).
+*/
+ div = ((clk_get_rate(rgb-clk) * 2) / pclk) - 2;
+ pclk = 0;
+
+ err = tegra_dc_state_setup_clock(dc, crtc_state, rgb-clk_parent,
+pclk, div);
+ if (err 0) {
+ dev_err(output-dev, failed to setup CRTC state: %d\n, err);
+ return err;
+ }
+
+ return err;
+}
+
static const struct drm_encoder_helper_funcs tegra_rgb_encoder_helper_funcs = {
.dpms = tegra_rgb_encoder_dpms,
.mode_fixup = tegra_rgb_encoder_mode_fixup,
@@ -242,6 +283,7 @@ static const struct drm_encoder_helper_funcs
tegra_rgb_encoder_helper_funcs = {
.commit = tegra_rgb_encoder_commit,
.mode_set = tegra_rgb_encoder_mode_set,
.disable = tegra_rgb_encoder_disable,
+ .atomic_check = tegra_rgb_encoder_atomic_check,
};
int tegra_dc_rgb_probe(struct tegra_dc *dc)
--
2.1.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 24/36] drm/tegra: Atomic conversion, phase 3, step 1
From: Thierry Reding tred...@nvidia.com
Switch out the regular plane helpers for the atomic plane helpers. Also
use the default atomic helpers to implement the -atomic_check() and
-atomic_commit() callbacks. The driver now exclusively uses the atomic
interfaces.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/gpu/drm/tegra/dc.c | 12 ++--
drivers/gpu/drm/tegra/drm.c | 4
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index cb2bd0088295..469bfa0fe096 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -404,8 +404,8 @@ static void tegra_primary_plane_destroy(struct drm_plane
*plane)
}
static const struct drm_plane_funcs tegra_primary_plane_funcs = {
- .update_plane = drm_plane_helper_update,
- .disable_plane = drm_plane_helper_disable,
+ .update_plane = drm_atomic_helper_update_plane,
+ .disable_plane = drm_atomic_helper_disable_plane,
.destroy = tegra_primary_plane_destroy,
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
@@ -690,8 +690,8 @@ static void tegra_cursor_atomic_disable(struct drm_plane
*plane,
}
static const struct drm_plane_funcs tegra_cursor_plane_funcs = {
- .update_plane = drm_plane_helper_update,
- .disable_plane = drm_plane_helper_disable,
+ .update_plane = drm_atomic_helper_update_plane,
+ .disable_plane = drm_atomic_helper_disable_plane,
.destroy = tegra_plane_destroy,
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
@@ -740,8 +740,8 @@ static void tegra_overlay_plane_destroy(struct drm_plane
*plane)
}
static const struct drm_plane_funcs tegra_overlay_plane_funcs = {
- .update_plane = drm_plane_helper_update,
- .disable_plane = drm_plane_helper_disable,
+ .update_plane = drm_atomic_helper_update_plane,
+ .disable_plane = drm_atomic_helper_disable_plane,
.destroy = tegra_overlay_plane_destroy,
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 58a4ed192e61..0dd81d050ccb 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -10,6 +10,8 @@
#include linux/host1x.h
#include linux/iommu.h
+#include drm/drm_atomic_helper.h
+
#include drm.h
#include gem.h
@@ -29,6 +31,8 @@ static const struct drm_mode_config_funcs
tegra_drm_mode_funcs = {
#ifdef CONFIG_DRM_TEGRA_FBDEV
.output_poll_changed = tegra_fb_output_poll_changed,
#endif
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
};
static int tegra_drm_load(struct drm_device *drm, unsigned long flags)
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 04/16] virtio/console: verify device has config space
On Tue, Jan 20, 2015 at 04:10:40PM +0530, Amit Shah wrote:
On (Wed) 14 Jan 2015 [19:27:35], Michael S. Tsirkin wrote:
Some devices might not implement config space access
(e.g. remoteproc used not to - before 3.9).
virtio/console needs config space access so make it
fail gracefully if not there.
Do we know any such devices? Wondering what prompted this patch. If
it's just theoretical, I'd rather let it be like this, and pull this
in when there's a device that doesn't have config space.
Yes, with virtio 1.0 config space can be in a separate BAR now. If
that's not enabled by BIOS (e.g. out of space), we won't have config
space.
Also, just the console functionality (i.e. F_MULTIPORT is unset) is
available w/o config space access.
Supporting this by gracefully disabling F_MULTIPORT
would require getting this info from driver before
features are finalized.
Alternatively, check F_MULTIPORT and only fail if set?
Let me know, I'll cook up a patch.
In fact, getting this patch in
would mean remoteproc wouldn't even run in its pre-config days...
It seems to have get callback unconditionally now - or did I miss
something?
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index de03df9..26afb56 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1986,6 +1986,12 @@ static int virtcons_probe(struct virtio_device *vdev)
bool multiport;
bool early = early_put_chars != NULL;
+ if (!vdev-config-get) {
+ dev_err(vdev-dev, %s failure: config access disabled\n,
+ __func__);
+ return -EINVAL;
+ }
+
Amit
--
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 05/36] drm/atomic: Add drm_atomic_plane_get_crtc_state()
On Tue, Jan 20, 2015 at 11:48:24AM +0100, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
This function is useful to obtain the state of the CRTC that a plane is
being attached to.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
include/drm/drm_atomic.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 51168a8b723a..ddca107e5cce 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -75,4 +75,25 @@ int __must_check drm_atomic_check_only(struct
drm_atomic_state *state);
int __must_check drm_atomic_commit(struct drm_atomic_state *state);
int __must_check drm_atomic_async_commit(struct drm_atomic_state *state);
+/**
+ * drm_atomic_plane_get_crtc_state - obtain atomic state of the CRTC that a
+ * plane is being attached to
+ * @state: atomic state of plane
+ *
+ * Getting the atomic state of the CRTC that a given plane being attached to
+ * is non-trivial. We need to look at the global atomic state that the plane
+ * state is part of and extract the CRTC state using the CRTC's index. Using
+ * the drm_atomic_get_crtc_state() helper we make sure to acquire the proper
+ * locks, too.
+ *
+ * RETURNS:
+ * The atomic state of the CRTC that the plane is being attached to, or an
+ * ERR_PTR()-encoded negative error code on failure.
+ */
+static inline struct drm_crtc_state *
+drm_atomic_plane_get_crtc_state(struct drm_plane_state *state)
+{
+ return drm_atomic_get_crtc_state(state-state, state-crtc);
Hm, imo open-coding this is totally ok. Actually better since state-crtc
might be NULL, and hiding that isn't a good idea.
If you have a atomic_plane_disable hook then -crtc is guaranteed to be
non-NULL in atomic_plane_update, but being explicit here is imo a feature.
So nacked from my side.
-Daniel
+}
+
#endif /* DRM_ATOMIC_H_ */
--
2.1.3
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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 02/36] drm/plane: Make -atomic_update() mandatory
On Tue, Jan 20, 2015 at 11:48:21AM +0100, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com There is no use-case where it would be useful for drivers not to implement this function and the transitional plane helpers already require drivers to provide an implementation. Signed-off-by: Thierry Reding tred...@nvidia.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/drm_atomic_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index d467185f7942..010661f23035 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1108,7 +1108,7 @@ void drm_atomic_helper_commit_planes(struct drm_device *dev, funcs = plane-helper_private; - if (!funcs || !funcs-atomic_update) + if (!funcs) continue; old_plane_state = old_state-plane_states[i]; -- 2.1.3 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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 34/36] drm/tegra: Track active planes in CRTC state
On Tue, Jan 20, 2015 at 11:48:53AM +0100, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
Wrap struct drm_crtc_state in a driver-specific structure and add the
planes field which keeps track of which planes are updated or disabled
during a modeset. This allows atomic updates of the the display engine
at -atomic_flush() time.
Signed-off-by: Thierry Reding tred...@nvidia.com
commit 6ddd388ab222b66b596342becc76d5031c0e2fc8
Author: Rob Clark robdcl...@gmail.com
Date: Fri Nov 21 15:28:31 2014 -0500
drm/atomic: track bitmask of planes attached to crtc
added this to the core since it seems to be generally useful. Does tegra
need more?
-Daniel
---
drivers/gpu/drm/tegra/dc.c | 72
--
1 file changed, 44 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 52ae563cb531..835de4398c8f 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -54,6 +54,8 @@ struct tegra_dc_state {
struct clk *clk;
unsigned long pclk;
unsigned int div;
+
+ u32 planes;
};
static inline struct tegra_dc_state *to_dc_state(struct drm_crtc_state
*state)
@@ -64,20 +66,6 @@ static inline struct tegra_dc_state *to_dc_state(struct
drm_crtc_state *state)
return NULL;
}
-static void tegra_dc_window_commit(struct tegra_dc *dc, unsigned int index)
-{
- u32 value = WIN_A_ACT_REQ index;
-
- tegra_dc_writel(dc, value 8, DC_CMD_STATE_CONTROL);
- tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
-}
-
-static void tegra_dc_cursor_commit(struct tegra_dc *dc)
-{
- tegra_dc_writel(dc, CURSOR_ACT_REQ 8, DC_CMD_STATE_CONTROL);
- tegra_dc_writel(dc, CURSOR_ACT_REQ, DC_CMD_STATE_CONTROL);
-}
-
/*
* Reads the active copy of a register. This takes the dc-lock spinlock to
* prevent races with the VBLANK processing which also needs access to the
@@ -395,8 +383,6 @@ static void tegra_dc_setup_window(struct tegra_dc *dc,
unsigned int index,
break;
}
- tegra_dc_window_commit(dc, index);
-
spin_unlock_irqrestore(dc-lock, flags);
}
@@ -439,9 +425,28 @@ static void tegra_plane_cleanup_fb(struct drm_plane
*plane,
{
}
+static int tegra_plane_state_add(struct tegra_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct drm_crtc_state *crtc_state;
+ struct tegra_dc_state *tegra;
+
+ /* Propagate errors from allocation or locking failures. */
+ crtc_state = drm_atomic_plane_get_crtc_state(state);
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
+
+ tegra = to_dc_state(crtc_state);
+
+ tegra-planes |= WIN_A_ACT_REQ plane-index;
+
+ return 0;
+}
+
static int tegra_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
+ struct tegra_plane *tegra = to_tegra_plane(plane);
struct tegra_dc *dc = to_tegra_dc(state-crtc);
struct tegra_bo_tiling tiling;
int err;
@@ -472,6 +477,10 @@ static int tegra_plane_atomic_check(struct drm_plane
*plane,
}
}
+ err = tegra_plane_state_add(tegra, state);
+ if (err 0)
+ return err;
+
return 0;
}
@@ -538,8 +547,6 @@ static void tegra_plane_atomic_disable(struct drm_plane
*plane,
value = ~WIN_ENABLE;
tegra_dc_writel(dc, value, DC_WIN_WIN_OPTIONS);
- tegra_dc_window_commit(dc, p-index);
-
spin_unlock_irqrestore(dc-lock, flags);
}
@@ -599,6 +606,9 @@ static const u32 tegra_cursor_plane_formats[] = {
static int tegra_cursor_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
+ struct tegra_plane *tegra = to_tegra_plane(plane);
+ int err;
+
/* no need for further checks if the plane is being disabled */
if (!state-crtc)
return 0;
@@ -616,6 +626,10 @@ static int tegra_cursor_atomic_check(struct drm_plane
*plane,
state-crtc_w != 128 state-crtc_w != 256)
return -EINVAL;
+ err = tegra_plane_state_add(tegra, state);
+ if (err 0)
+ return err;
+
return 0;
}
@@ -680,9 +694,6 @@ static void tegra_cursor_atomic_update(struct drm_plane
*plane,
value = (state-crtc_y 0x3fff) 16 | (state-crtc_x 0x3fff);
tegra_dc_writel(dc, value, DC_DISP_CURSOR_POSITION);
- /* apply changes */
- tegra_dc_cursor_commit(dc);
- tegra_dc_commit(dc);
}
static void tegra_cursor_atomic_disable(struct drm_plane *plane,
@@ -700,9 +711,6 @@ static void tegra_cursor_atomic_disable(struct drm_plane
*plane,
value = tegra_dc_readl(dc, DC_DISP_DISP_WIN_OPTIONS);
value = ~CURSOR_ENABLE;
tegra_dc_writel(dc, value, DC_DISP_DISP_WIN_OPTIONS);
-
-
Re: [PATCH 1/2] if_link: Add VF multicast promiscuous mode control
Hiroshi Shimamoto h-shimam...@ct.jp.nec.com writes:
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Add netlink directives and ndo entry to control VF multicast promiscuous mode.
Intel ixgbe and ixgbevf driver can handle only 30 multicast MAC addresses
per VF. It means that we cannot assign over 30 IPv6 addresses to a single
VF interface on VM. We want thousands IPv6 addresses in VM.
There is capability of multicast promiscuous mode in Intel 82599 chip.
It enables all multicast packets are delivered to the target VF.
This patch prepares to control that VF multicast promiscuous functionality.
Adding a new hook for this seems over-complicated to me. And it still
doesn't solve the real problems that
a) the user has to know about this limit, and
b) manually configure the feature
Most of us, lacking the ability to imagine such arbitrary hardware
limitations, will go through a few hours of frustrating debugging before
we figure this one out...
Why can't the ixgbevf driver just automatically signal the ixgbe driver
to enable multicast promiscuous mode whenever the list grows past the
limit?
I'd also like to note that this comment in
drivers/net/ethernet/intel/ixgbevf/vf.c
indicates that the author had some ideas about how more than 30
addresses could/should be handled:
static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
struct net_device *netdev)
{
struct netdev_hw_addr *ha;
u32 msgbuf[IXGBE_VFMAILBOX_SIZE];
u16 *vector_list = (u16 *)msgbuf[1];
u32 cnt, i;
/* Each entry in the list uses 1 16 bit word. We have 30
* 16 bit words available in our HW msg buffer (minus 1 for the
* msg type). That's 30 hash values if we pack 'em right. If
* there are more than 30 MC addresses to add then punt the
* extras for now and then add code to handle more than 30 later.
* It would be unusual for a server to request that many multi-cast
* addresses except for in large enterprise network environments.
*/
The last 2 lines of that comment are of course totally bogus and
pointless and should be deleted in any case... It's obvious that 30
multicast addresses is ridiculously low for lots of normal use cases.
Bjørn
--
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/
[tip:x86/urgent] x86, irq: Properly tag virtualization entry in / proc/interrupts
Commit-ID: 4a0d3107d6b19125f21172c2b7d95f9c30ecaf6f Gitweb: http://git.kernel.org/tip/4a0d3107d6b19125f21172c2b7d95f9c30ecaf6f Author: Jan Beulich jbeul...@suse.com AuthorDate: Fri, 16 Jan 2015 15:47:07 + Committer: Thomas Gleixner t...@linutronix.de CommitDate: Tue, 20 Jan 2015 12:37:23 +0100 x86, irq: Properly tag virtualization entry in /proc/interrupts The mis-naming likely was a copy-and-paste effect. Signed-off-by: Jan Beulich jbeul...@suse.com Cc: sta...@vger.kernel.org Link: http://lkml.kernel.org/r/54b9408b027800055...@mail.emea.novell.com Signed-off-by: Thomas Gleixner t...@linutronix.de --- arch/x86/kernel/irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c index 6307a0f..705ef8d 100644 --- a/arch/x86/kernel/irq.c +++ b/arch/x86/kernel/irq.c @@ -127,7 +127,7 @@ int arch_show_interrupts(struct seq_file *p, int prec) seq_puts(p, Machine check polls\n); #endif #if IS_ENABLED(CONFIG_HYPERV) || defined(CONFIG_XEN) - seq_printf(p, %*s: , prec, THR); + seq_printf(p, %*s: , prec, HYP); for_each_online_cpu(j) seq_printf(p, %10u , irq_stats(j)-irq_hv_callback_count); seq_puts(p, Hypervisor callback interrupts\n); -- 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/
[tip:x86/urgent] x86, boot: Skip relocs when load address unchanged
Commit-ID: f285f4a21c3253887caceed493089ece17579d59
Gitweb: http://git.kernel.org/tip/f285f4a21c3253887caceed493089ece17579d59
Author: Kees Cook keesc...@chromium.org
AuthorDate: Thu, 15 Jan 2015 16:51:46 -0800
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Tue, 20 Jan 2015 12:37:23 +0100
x86, boot: Skip relocs when load address unchanged
On 64-bit, relocation is not required unless the load address gets
changed. Without this, relocations do unexpected things when the kernel
is above 4G.
Reported-by: Baoquan He b...@redhat.com
Signed-off-by: Kees Cook keesc...@chromium.org
Tested-by: Thomas D. whi...@whissi.de
Cc: Vivek Goyal vgo...@redhat.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Junjie Mao eternal@gmail.com
Cc: Andi Kleen a...@linux.intel.com
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/20150116005146.ga4...@www.outflux.net
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
arch/x86/boot/compressed/misc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index dcc1c53..a950864 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -373,6 +373,8 @@ asmlinkage __visible void *decompress_kernel(void *rmode,
memptr heap,
unsigned long output_len,
unsigned long run_size)
{
+ unsigned char *output_orig = output;
+
real_mode = rmode;
sanitize_boot_params(real_mode);
@@ -421,7 +423,12 @@ asmlinkage __visible void *decompress_kernel(void *rmode,
memptr heap,
debug_putstr(\nDecompressing Linux... );
decompress(input_data, input_len, NULL, NULL, output, NULL, error);
parse_elf(output);
- handle_relocations(output, output_len);
+ /*
+* 32-bit always performs relocations. 64-bit relocations are only
+* needed if kASLR has chosen a different load address.
+*/
+ if (!IS_ENABLED(CONFIG_X86_64) || output != output_orig)
+ handle_relocations(output, output_len);
debug_putstr(done.\nBooting the kernel.\n);
return output;
}
--
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: Re: Re: [PATCH tip 0/9] tracing: attach eBPF programs to tracepoints/syscalls/kprobe
(2015/01/20 12:55), Alexei Starovoitov wrote: On Mon, Jan 19, 2015 at 6:58 PM, Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote: it's done already... one can do the same skb-dev-name logic in kprobe attached program... so from bpf program point of view, tracepoints and kprobes feature-wise are exactly the same. Only input is different. No, I meant that the input should also be same, at least for the first step. I guess it is easy to hook the ring buffer committing and fetch arguments from the event entry. No. That would be very slow. See my comment to Steven and more detailed numbers below. Thank you for measuring the performance differences. Indeed, the ring buffer looks slow. Allocating ring buffer takes too much time. And what I expected scenario was 1. setup kprobe traceevent with fd, buf, count by using perf-probe. 2. load bpf module 3. the module processes given event arguments. from ring buffer? that's too slow. Ok, BTW, would you think is it possible to use a reusable small scratchpad memory for passing arguments? (just a thought) It's not usable for high frequency events which need this in-kernel aggregation. If events are rare, then just dumping everything into trace buffer is just fine. No in-kernel program is needed. Hmm, let me ensure your point, the performance number is the reason why we need to do it in the kernel, right? Not mainly for the flexibility but speed. Hmm, it sounds making another systemtap on top of tracepoint and kprobes. Why don't you just reuse the existing facilities (perftools and ftrace) instead of co-exist? hmm. I don't think we're on the same page yet... ring buffer and tracing interface is fully reused. programs are run as soon as event triggers. They can return non-zero and kernel will allocate ring buffer which user space will consume. Please take a look at tracex1 I see, this code itself is not a destructive change. Just look how ktap scripts look alike for kprobes and tracepoints. Ktap is a good example, it provides only a language parser and a runtime engine. Actually, currently it lacks a feature to execute perf-probe helper from script, but it is easy to add such feature. ... For this usecase, I've made --output option for perf probe https://lkml.org/lkml/2014/10/31/210 you're proposing to call perf binary from ktap binary? Yes, that's right :) I think packaging headaches and error conditions will make such approach very hard to use. No, I don't think so. perf can be a buffer from the kernel API and command-line API. If you need to get clearer error, you also can join the upstream development. it would be much cleaner to have ktap as part of perf generating bpf on the fly and feeding into kernel. 'perf probe' parsing and functions don't belong in kernel when userspace can generate them in more efficient way. No, perf probe still be needed to users who don't choose injecting binary blob tracing. Efficiency is NOT only one index. - perf probe and kprobe-event gives us a complete understandable interface for what will be recorded at where. (we can see the event definitions via kprobe_events interface, without any tools) - kprobe-event gives a completely same interface as other tracepoint events. - it also doesn't require any build-binary parts :) nor special tools. We can play with ftrace on just a small busybox. However, this does NOT interfere your patch upstreaming. I just said current ftrace method is also meaningful for some reasons :) By the way, I concern about that bpf compiler can become another systemtap, especially if you build it on llvm. Would you plan to develop it on kernel tree? or apart from the kernel-side development? I think it is hard to sync the development if you do it out-of-tree. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/14] mfd: twl-core: Constify struct regmap_config and reg_default array
On Mon, 05 Jan 2015, Krzysztof Kozlowski wrote:
The regmap_config struct may be const because it is not modified by the
driver and regmap_init() accepts pointer to const. Make array of
struct reg_default const as well.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Tony Lindgren t...@atomide.com
Cc: linux-o...@vger.kernel.org
---
drivers/mfd/twl-core.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Applied with Tony's Ack, thanks.
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index db11b4f40611..489674a2497e 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -207,7 +207,7 @@ static struct twl_mapping twl4030_map[] = {
{ 2, TWL5031_BASEADD_INTERRUPTS },
};
-static struct reg_default twl4030_49_defaults[] = {
+static const struct reg_default twl4030_49_defaults[] = {
/* Audio Registers */
{ 0x01, 0x00}, /* CODEC_MODE*/
{ 0x02, 0x00}, /* OPTION*/
@@ -306,7 +306,7 @@ static const struct regmap_access_table
twl4030_49_volatile_table = {
.n_yes_ranges = ARRAY_SIZE(twl4030_49_volatile_ranges),
};
-static struct regmap_config twl4030_regmap_config[4] = {
+static const struct regmap_config twl4030_regmap_config[4] = {
{
/* Address 0x48 */
.reg_bits = 8,
@@ -369,7 +369,7 @@ static struct twl_mapping twl6030_map[] = {
{ 1, TWL6030_BASEADD_GASGAUGE },
};
-static struct regmap_config twl6030_regmap_config[3] = {
+static const struct regmap_config twl6030_regmap_config[3] = {
{
/* Address 0x48 */
.reg_bits = 8,
@@ -1087,7 +1087,7 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
struct twl4030_platform_data*pdata = dev_get_platdata(client-dev);
struct device_node *node = client-dev.of_node;
struct platform_device *pdev;
- struct regmap_config*twl_regmap_config;
+ const struct regmap_config *twl_regmap_config;
int irq_base = 0;
int status;
unsignedi, num_slaves;
--
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 v5 5/5] tty/serial: Add Spreadtrum sc9836-uart driver support
Hi, Peter, Thank you for reviewing our code! Some discussion below. On 2015年01月16日 23:20, Peter Hurley wrote: On 01/16/2015 05:00 AM, Chunyan Zhang wrote: Add a full sc9836-uart driver for SC9836 SoC which is based on the spreadtrum sharkl64 platform. This driver also support earlycon. This patch also replaced the spaces between the macros and their values with the tabs in serial_core.h The locking doesn't look correct. Specific notations below. Signed-off-by: Chunyan Zhang chunyan.zh...@spreadtrum.com Signed-off-by: Orson Zhai orson.z...@spreadtrum.com Originally-by: Lanqing Liu lanqing@spreadtrum.com --- drivers/tty/serial/Kconfig | 18 + drivers/tty/serial/Makefile |1 + drivers/tty/serial/sprd_serial.c | 772 ++ include/uapi/linux/serial_core.h |3 + 4 files changed, 794 insertions(+) create mode 100644 drivers/tty/serial/sprd_serial.c diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index c79b43c..969d3cd 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1577,6 +1577,24 @@ config SERIAL_MEN_Z135 This driver can also be build as a module. If so, the module will be called men_z135_uart.ko +config SERIAL_SPRD + tristate Support for SPRD serial + depends on ARCH_SPRD + select SERIAL_CORE + help + This enables the driver for the Spreadtrum's serial. + +config SERIAL_SPRD_CONSOLE + bool SPRD UART console support + depends on SERIAL_SPRD=y + select SERIAL_CORE_CONSOLE + select SERIAL_EARLYCON + help + Support for early debug console using Spreadtrum's serial. This enables + the console before standard serial driver is probed. This is enabled + with earlycon on the kernel command line. The console is + enabled when early_param is processed. + endmenu config SERIAL_MCTRL_GPIO diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile index 9a548ac..4801aca 100644 --- a/drivers/tty/serial/Makefile +++ b/drivers/tty/serial/Makefile @@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_ARC) += arc_uart.o obj-$(CONFIG_SERIAL_RP2) += rp2.o obj-$(CONFIG_SERIAL_FSL_LPUART) += fsl_lpuart.o obj-$(CONFIG_SERIAL_MEN_Z135) += men_z135_uart.o +obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o # GPIOLIB helpers for modem control lines obj-$(CONFIG_SERIAL_MCTRL_GPIO) += serial_mctrl_gpio.o diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c new file mode 100644 index 000..81839e4 --- /dev/null +++ b/drivers/tty/serial/sprd_serial.c @@ -0,0 +1,772 @@ +/* + * Copyright (C) 2012 Spreadtrum Communications Inc. + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * 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. + */ + +#include linux/clk.h +#include linux/console.h +#include linux/delay.h +#include linux/io.h +#include linux/ioport.h +#include linux/kernel.h +#include linux/module.h +#include linux/of.h +#include linux/platform_device.h +#include linux/serial_core.h +#include linux/serial.h +#include linux/slab.h +#include linux/tty.h +#include linux/tty_flip.h + +/* device name */ +#define UART_NR_MAX8 +#define SPRD_TTY_NAME ttySPX +#define SPRD_FIFO_SIZE 128 +#define SPRD_DEF_RATE 2600 +#define SPRD_TIMEOUT 2048 + +/* the offset of serial registers and BITs for them */ +/* data registers */ +#define SPRD_TXD 0x +#define SPRD_RXD 0x0004 + +/* line status register and its BITs */ +#define SPRD_LSR 0x0008 +#define SPRD_LSR_OEBIT(4) +#define SPRD_LSR_FEBIT(3) +#define SPRD_LSR_PEBIT(2) +#define SPRD_LSR_BIBIT(7) +#define SPRD_LSR_TX_OVER BIT(15) + +/* data number in TX and RX fifo */ +#define SPRD_STS1 0x000C + +/* interrupt enable register and its BITs */ +#define SPRD_IEN 0x0010 +#define SPRD_IEN_RX_FULL BIT(0) +#define SPRD_IEN_TX_EMPTY BIT(1) +#define SPRD_IEN_BREAK_DETECT BIT(7) +#define SPRD_IEN_TIMEOUT BIT(13) + +/* interrupt clear register */ +#define SPRD_ICLR 0x0014 + +/* line control register */ +#define SPRD_LCR 0x0018 +#define SPRD_LCR_STOP_1BIT 0x10 +#define SPRD_LCR_STOP_2BIT 0x30 +#define SPRD_LCR_DATA_LEN (BIT(2) | BIT(3)) +#define SPRD_LCR_DATA_LEN5 0x0 +#define SPRD_LCR_DATA_LEN6 0x4 +#define SPRD_LCR_DATA_LEN7 0x8 +#define SPRD_LCR_DATA_LEN8 0xc +#define SPRD_LCR_PARITY(BIT(0) |
[PATCH v5] arm: perf: Directly handle SMP platforms with one SPI
Some ARM platforms mux the PMU interrupt of every core into a single
SPI. On such platforms if the PMU of any core except 0 raises an interrupt
then it cannot be serviced and eventually, if you are lucky, the spurious
irq detection might forcefully disable the interrupt.
On these SoCs it is not possible to determine which core raised the
interrupt so workaround this issue by queuing irqwork on the other
cores whenever the primary interrupt handler is unable to service the
interrupt.
The u8500 platform has an alternative workaround that dynamically alters
the affinity of the PMU interrupt. This workaround logic is no longer
required so the original code is removed as is the hook it relied upon.
Tested on imx6q (which has fours cores/PMUs all muxed to a single SPI)
using a simple soak, combined perf and CPU hotplug soak and using
perf fuzzer's fast_repro.sh.
Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
---
Notes:
v2 was tested on u8500 (thanks to Linus Walleij). v4 doesn't change
anything conceptual but the changes were sufficient for me not to
preserve the Tested-By:.
v5:
* Removed the work queue nonsense; being completely race-free requires
us to take a mutex or avoid dispatch from interrupt (Will Deacon).
Replacement code can potentially race with a CPU hot unplug however
it is careful to minimise exposure, to mitigate harmful effects and
has fairly prominent comments.
v4:
* Ripped out the logic that tried to preserve the operation of the
spurious interrupt detector. It was complex and not really needed
(Will Deacon).
* Removed a redundant memory barrier and added a comment explaining
why it is not needed (Will Deacon).
* Made fully safe w.r.t. hotplug by falling back to a work queue
if there is a hotplug operation in flight when the PMU interrupt
comes in (Will Deacon). The work queue code paths have been tested
synthetically (by changing the if condition).
* Posted the correct, as in compilable and tested, version of the code
(Will Deacon).
v3:
* Removed function pointer indirection when deploying workaround code
and reorganise the code accordingly (Mark Rutland).
* Move the workaround state tracking into the existing percpu data
structure (Mark Rutland).
* Renamed cret to percpu_ret and rewrote the comment describing the
purpose of this variable (Mark Rutland).
* Copy the cpu_online_mask and use that to act on a consistent set of
cpus throughout the workaround (Mark Rutland).
* Changed single_irq to muxed_spi to more explicitly describe
the problem.
v2:
* Fixed build problems on systems without SMP.
v1:
* Thanks to Lucas Stach, Russell King and Thomas Gleixner for
critiquing an older, completely different way to tackle the
same problem.
arch/arm/include/asm/pmu.h | 12
arch/arm/kernel/perf_event.c | 9 +--
arch/arm/kernel/perf_event_cpu.c | 128 +++
arch/arm/kernel/perf_event_v7.c | 2 +-
arch/arm/mach-ux500/cpu-db8500.c | 29 -
5 files changed, 142 insertions(+), 38 deletions(-)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index b1596bd59129..dfef7904b790 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -87,6 +87,14 @@ struct pmu_hw_events {
* already have to allocate this struct per cpu.
*/
struct arm_pmu *percpu_pmu;
+
+#ifdef CONFIG_SMP
+ /*
+* This is used to schedule workaround logic on platforms where all
+* the PMUs are attached to a single SPI.
+*/
+ struct irq_work work;
+#endif
};
struct arm_pmu {
@@ -117,6 +125,10 @@ struct arm_pmu {
struct platform_device *plat_device;
struct pmu_hw_events__percpu *hw_events;
struct notifier_block hotplug_nb;
+#ifdef CONFIG_SMP
+ int muxed_spi_workaround_irq;
+ atomic_tremaining_irq_work;
+#endif
};
#define to_arm_pmu(p) (container_of(p, struct arm_pmu, pmu))
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index f7c65adaa428..e5c537b57f94 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -299,8 +299,6 @@ validate_group(struct perf_event *event)
static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
{
struct arm_pmu *armpmu;
- struct platform_device *plat_device;
- struct arm_pmu_platdata *plat;
int ret;
u64 start_clock, finish_clock;
@@ -311,14 +309,9 @@ static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
* dereference.
*/
armpmu = *(void **)dev;
- plat_device = armpmu-plat_device;
- plat = dev_get_platdata(plat_device-dev);
start_clock = sched_clock();
- if (plat
[PATCH 2/2] ARM: l2c: Maintain CPU endianness for early resume function
In big endian CPU mode l2x0_saved_regs structure stores registers values in BE format. In order to maintain BE CPU mode, these values and immediate constants must be converted back to LE format before writing them to cache controller. Signed-off-by: Dmitry Osipenko dig...@gmail.com --- arch/arm/mm/l2c-l2x0-resume.S | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/mm/l2c-l2x0-resume.S b/arch/arm/mm/l2c-l2x0-resume.S index fda415e..9f99c7e 100644 --- a/arch/arm/mm/l2c-l2x0-resume.S +++ b/arch/arm/mm/l2c-l2x0-resume.S @@ -30,6 +30,15 @@ ENTRY(l2c310_early_resume) teq r1, #0 reteq lr + @ Reverse for big endian kernel +ARM_BE8(revr2, r2) +ARM_BE8(revr3, r3) +ARM_BE8(revr4, r4) +ARM_BE8(revr5, r5) +ARM_BE8(revr6, r6) +ARM_BE8(revr7, r7) +ARM_BE8(revr8, r8) + @ The prefetch and power control registers are revision dependent @ and can be written whether or not the L2 cache is enabled ldr r0, [r1, #L2X0_CACHE_ID] @@ -51,6 +60,7 @@ ENTRY(l2c310_early_resume) str r2, [r1, #L2X0_AUX_CTRL] mov r9, #L2X0_CTRL_EN +ARM_BE8(revr9, r9) str r9, [r1, #L2X0_CTRL] ret lr ENDPROC(l2c310_early_resume) -- 2.2.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/
Re: [PATCH v3 2/4] clk: mediatek: Add initial common clock support for Mediatek SoCs.
2015-01-08 3:55 GMT+01:00 James Liao jamesjj.l...@mediatek.com: Hi Matthias, On Wed, 2015-01-07 at 18:22 +0100, Matthias Brugger wrote: 2015-01-07 4:25 GMT+01:00 James Liao jamesjj.l...@mediatek.com: [...] + +extern spinlock_t *get_mtk_clk_lock(void); + +#define mtk_clk_lock(flags)spin_lock_irqsave(get_mtk_clk_lock(), flags) +#define mtk_clk_unlock(flags) \ + spin_unlock_irqrestore(get_mtk_clk_lock(), flags) Please use the spinlock directly without this akward defines. Do you mean we should export clk_ops_lock (from clk-mtk.c) directly instead of get_mtk_clk_lock()? Or simply remove mtk_clk_lock/unlock()? I think you should use spin_lock_irqsave(clk_ops_lock, flags) instead of mtk_clk_lock. In any case I think you should define a spinlock in clk-mt8135.c and pass a reference of it in the init functions. See drivers/clk/berlin as a good example. Thanks, Matthias -- motzblog.wordpress.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC v10 05/19] mfd: max77693: Modify flash cell name identifiers
On 01/20/2015 12:13 PM, Lee Jones wrote:
On Fri, 09 Jan 2015, Jacek Anaszewski wrote:
Change flash cell identifiers from max77693-flash to max77693-led
to avoid confusion with NOR/NAND Flash.
This is okay by me, but aren't these ABI yet?
No, the led driver using it hasn't been merged yet.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Chanwoo Choi cw00.c...@samsung.com
Cc: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/max77693.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index a159593..cb14afa 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -53,8 +53,8 @@ static const struct mfd_cell max77693_devs[] = {
.of_compatible = maxim,max77693-haptic,
},
{
- .name = max77693-flash,
- .of_compatible = maxim,max77693-flash,
+ .name = max77693-led,
+ .of_compatible = maxim,max77693-led,
},
};
--
Best Regards,
Jacek Anaszewski
--
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 5/6] epoll: Add implementation for epoll_mod_wait
Hello Fam Zheng,
On 01/20/2015 10:57 AM, Fam Zheng wrote:
This syscall is a sequence of
1) a number of epoll_ctl calls
2) a epoll_pwait, with timeout enhancement.
The epoll_ctl operations are embeded so that application doesn't have to use
separate syscalls to insert/delete/update the fds before poll. It is more
efficient if the set of fds varies from one poll to another, which is the
common pattern for certain applications.
Which applications? Could we have some specific examples? This is a
complex API, and it needs good justification.
For example, depending on the input
buffer status, a data reading program may decide to temporarily not polling an
fd.
Because the enablement of batching in this interface, even that regular
epoll_ctl call sequence, which manipulates several fds, can be optimized to
one
single epoll_ctl_wait (while specifying spec=NULL to skip the poll part).
^^ should be epoll_mod_wait
I think you mean to say:
The ability to batch multiple epoll_ctl operations into a single call
means that even when no wait events are requested (i.e., spec == NULL),
poll_mod_wait() provides a performance optimization over using multiple
epoll_ctl() calls.
Right? If yes, please amend the commit message, and this text should
also make its way into the revised man page under a heading NOTES.
The only complexity is returning the result of each operation. For each
epoll_mod_cmd in cmds, the field error is an output field that will be
stored
the return code *iff* the command is executed (0 for success and -errno of the
equivalent epoll_ctl call), and will be left unchanged if the command is not
executed because some earlier error, for example due to failure of
copy_from_user to copy the array.
Applications can utilize this fact to do error handling: they could initialize
all the epoll_mod_wait.error to a positive value, which is by definition not a
possible output value from epoll_mod_wait. Then when the syscall returned,
they
know whether or not the command is executed by comparing each error with the
init value, if they're different, they have the result of the command.
More roughly, they can put any non-zero and not distinguish not run from
failure.
The cmds' are not executed in a specified order plus the need to
initialize the 'errors' fields to a positive value feels a bit ugly.
And indeed the whole command list was only partially run case
is not pretty. Am I correct to understand that if an error is found
during execution of one of the epoll_ctl commands in 'cmds' then
the system call will return -1 with errno set, indicating an error,
even though the epoll interest list may have changed because some
of the earlier 'cmds' executed successfully? This all seems a bit of
a headache for user space.
I have a couple of questions:
Q1. I can see that batching epoll_ctl commands might be useful,
since it results in fewer systems calls. But, does it really
need to be bound together with the epoll_pwait functionality?
(Perhaps this point was covered in previous discussions, but
neither the message accompanying this patch nor the 0/6 man page
provide a compelling rationale for the need to bind these two
operations together.)
Yes, I realize you might save a system call, but it makes for a
cumbersome API that has the above headache, and also forces the
need for double pointer indirection in the 'spec' argument (i.e.,
spec is a pointer to an array of structures where each element
in turn includes an 'events' pointer that points to another array).
Why not a simpler API with two syscalls such as:
epoll_ctl_batch(int epfd, int flags,
int ncmds, struct epoll_mod_cmd *cmds);
epoll_pwait1(int epfd, struct epoll_event *events, int maxevents,
struct timespec *timeout, int clock_id,
const sigset_t *sigmask, size_t sigsetsize);
This gives us much of the benefit of reducing system calls, but
with greater simplicity. And epoll_ctl_batch() could simply return
the number of 'cmds' that were successfully executed.)
Q2. In the man page in 0/6 you said that the 'cmds' were not
guaranteed to be executed in order. Why not? If you did provide
such a guarantee, then, when using your current epoll_mod_wait(),
user space could do the following:
1. Initialize the cmd.errors fields to zero.
2. Call epoll_ctl_mod()
3. Iterate through cmd.errors looking for the first nonzero
field.
Also, timeout parameter is enhanced: timespec is used, compared to the old ms
scalar. This provides higher precision.
Yes, that change seemed inevitable. It slightly puzzled me at the time when
Davide Libenzi added epoll_wait() that the timeout was milliseconds, even
though pselect() already had demonstrated the need for higher precision.
I should have called it out way back then :-{.
The parameter field in struct
epoll_wait_spec, clockid, also makes it possible for users to use a
different
clock than the
Re: [PATCH v2 1/5] irqchip: add dumb demultiplexer implementation
On Thu, 15 Jan 2015, Rob Herring wrote: On Thu, Jan 15, 2015 at 3:11 AM, Thomas Gleixner t...@linutronix.de wrote: On Wed, 14 Jan 2015, Rob Herring wrote: We do not change shared interrupts in any way. We provide an alternative mechanism for braindead hardware. And if the at91 folks are fine with the DT change, then it's their decision. Nothing forces this on everyone. We are changing how shared interrupts are described in DT. We don't need 2 ways to describe them. We could say this is only for AT91 and continue to describe shared interrupts as has been done forever. Then the next platform that hits this problem will have to go thru the same ABI breakage. Or we change DT practices to describe all shared interrupts with a demux node. Given the way DTs are incrementally created, it is not something we can check with review or tools, so we will still have the same ABI breakage problem. This is not describing the proper shared interrupts. This is a special case for a special case of braindamaged hardware. Whats wrong with doing that? We dont have to change that for all shared interrupts because 99% of them have a proper hardware implementation and are not affected by this. What's wrong with serving the AT91 with a proper solution, which does NOT inflict horrible hacks into the core code and does NOT weaken sanity checks and does NOT require irq chip specific knowledge in device drivers? There are probably ways to do this demux irqchip without a DT change. So far you have not provided any useful hint how to do so. What's the problem with a DT change for a single platform, if the maintainers are willing to take it and deal with the fallout? What's the solution for a platform that an ABI break is not okay and can't deal with the fallout? There is no other platform affected. This is a break for a specific set of devices and the 'fallout' is confined, well known and accepted. So what's your problem, really? Thanks, tglx -- 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 5/5] KVM: nVMX: Enable nested posted interrupt processing.
On 20/01/2015 09:48, Wincy Van wrote:
+static int vmx_deliver_nested_posted_interrupt(struct kvm_vcpu *vcpu,
+ int vector)
+{
+ int r = 0;
+ struct vmcs12 *vmcs12;
+
+ /*
+* Since posted intr delivery is async,
+* we must aquire a spin-lock to avoid
+* the race of vmcs12.
+*/
+ spin_lock(to_vmx(vcpu)-nested.vmcs12_lock);
+ vmcs12 = get_vmcs12(vcpu);
+ if (!is_guest_mode(vcpu) || !vmcs12) {
+ r = -1;
+ goto out;
+ }
is_guest_mode should be checked first outside the lock, to avoid
affecting the non-nested fast path. You can then recheck it later
inside the lock.
Another way to avoid the spinlock: in prepare_vmcs02 or a similar place,
you can save vmcs12-posted_intr_nv in a new field
vmx-nested.posted_intr_nv; just set it to -1 if
!nested_cpu_has_posted_intr(vmcs12). In vmclear, again you just set the
field to -1, and here you can do
if (!is_guest_mode(vcpu) ||
vector != to_vmx(vcpu)-nested.posted_intr_nv) {
r = -1;
goto out;
}
You don't need to access vmcs12, and while there is a race, it's okay
because there is no pointer access.
+ if (vcpu-mode == IN_GUEST_MODE)
+ apic-send_IPI_mask(get_cpu_mask(vcpu-cpu),
+ POSTED_INTR_VECTOR);
Please add a comment that PIR and ON have been set by the L1 hypervisor.
I'll do a full review the other patches as soon as possible.
Paolo
+ else {
+ r = -1;
+ goto out;
+ }
+
+ /*
+* if posted intr is done by hardware, the
+* corresponding eoi was sent to L0. Thus
+* we should send eoi to L1 manually.
+*/
+ kvm_apic_set_eoi_accelerated(vcpu,
+ vmcs12-posted_intr_nv);
--
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/
