RE: [PATCH v2 5/5] xhci: Remove recursive call to xhci_handle_event
- xhci_handle_event(xhci);
+ while (xhci_handle_event(xhci)) {}
I must admit I dislike the style with empty loop bodies...
I would use an explicit 'continue;' for the body
of an otherwise empty loop.
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: dtc: remove obsolete .gitignore entries
On Sat, Mar 12, 2011 at 05:44:10PM +0100, Wolfram Sang wrote: dtc was moved and .gitignores have been added to the new location. So, we can delete the old, forgotten ones. Signed-off-by: Wolfram Sang w.s...@pengutronix.de Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Ping. Is this one more for Ben or more for Grant? --- arch/powerpc/boot/.gitignore |1 - arch/powerpc/boot/dtc-src/.gitignore |3 --- 2 files changed, 0 insertions(+), 4 deletions(-) delete mode 100644 arch/powerpc/boot/dtc-src/.gitignore diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore index 3d80c3e..12da77e 100644 --- a/arch/powerpc/boot/.gitignore +++ b/arch/powerpc/boot/.gitignore @@ -1,5 +1,4 @@ addnote -dtc empty.c hack-coff infblock.c diff --git a/arch/powerpc/boot/dtc-src/.gitignore b/arch/powerpc/boot/dtc-src/.gitignore deleted file mode 100644 index a7c3f94..000 --- a/arch/powerpc/boot/dtc-src/.gitignore +++ /dev/null @@ -1,3 +0,0 @@ -dtc-lexer.lex.c -dtc-parser.tab.c -dtc-parser.tab.h -- 1.7.2.3 -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: checking status semantics with compatible functions
[Adding proper lists on CC]
- k
On Mar 30, 2011, at 3:07 AM, Kumar Gala wrote:
Grant,
We have a few helper functions like:
drivers/of/base.c:EXPORT_SYMBOL(of_device_is_compatible);
drivers/of/base.c:EXPORT_SYMBOL(of_find_compatible_node);
That we use in places like arch/powerpc/platform/85xx/mpc85xx_ds.c:
for_each_node_by_type(np, pci) {
if (of_device_is_compatible(np, fsl,mpc8540-pci) ||
of_device_is_compatible(np, fsl,mpc8548-pcie) ||
of_device_is_compatible(np, fsl,p2020-pcie)) {
It seems like we should check 'status' in these cases with
'of_device_is_available'. I'm thinking that we should have versions of the
helpers that also do the 'of_device_is_available' checking. Or should we
just change the helpers to call of_device_is_available?
- k
___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: rename get_irq_desc_data and get_irq_desc_chip
These two functions disappeared in commit
0c6f8a8b917ad361319c8ace3e9f28e69bfdb4c1
genirq: Remove compat code
but they still exist in qe_ic.h.
This patch renames the function to their new names.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
arch/powerpc/include/asm/qe_ic.h | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/qe_ic.h b/arch/powerpc/include/asm/qe_ic.h
index 9e2cb20..f706164 100644
--- a/arch/powerpc/include/asm/qe_ic.h
+++ b/arch/powerpc/include/asm/qe_ic.h
@@ -81,7 +81,7 @@ int qe_ic_set_high_priority(unsigned int virq, unsigned int
priority, int high);
static inline void qe_ic_cascade_low_ipic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = get_irq_desc_data(desc);
+ struct qe_ic *qe_ic = irq_desc_get_handler_data(desc);
unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
if (cascade_irq != NO_IRQ)
@@ -91,7 +91,7 @@ static inline void qe_ic_cascade_low_ipic(unsigned int irq,
static inline void qe_ic_cascade_high_ipic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = get_irq_desc_data(desc);
+ struct qe_ic *qe_ic = irq_desc_get_handler_data(desc);
unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
if (cascade_irq != NO_IRQ)
@@ -101,9 +101,9 @@ static inline void qe_ic_cascade_high_ipic(unsigned int irq,
static inline void qe_ic_cascade_low_mpic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = get_irq_desc_data(desc);
+ struct qe_ic *qe_ic = irq_desc_get_handler_data(desc);
unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
- struct irq_chip *chip = get_irq_desc_chip(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
@@ -114,9 +114,9 @@ static inline void qe_ic_cascade_low_mpic(unsigned int irq,
static inline void qe_ic_cascade_high_mpic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = get_irq_desc_data(desc);
+ struct qe_ic *qe_ic = irq_desc_get_handler_data(desc);
unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
- struct irq_chip *chip = get_irq_desc_chip(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
@@ -127,9 +127,9 @@ static inline void qe_ic_cascade_high_mpic(unsigned int irq,
static inline void qe_ic_cascade_muxed_mpic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = get_irq_desc_data(desc);
+ struct qe_ic *qe_ic = irq_desc_get_handler_data(desc);
unsigned int cascade_irq;
- struct irq_chip *chip = get_irq_desc_chip(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
cascade_irq = qe_ic_get_high_irq(qe_ic);
if (cascade_irq == NO_IRQ)
--
1.7.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: rename get_irq_desc_data and get_irq_desc_chip
On Wed, 30 Mar 2011, Richard Cochran wrote: These two functions disappeared in commit 0c6f8a8b917ad361319c8ace3e9f28e69bfdb4c1 genirq: Remove compat code but they still exist in qe_ic.h. This patch renames the function to their new names. oops. I really need to figure out to teach coccinelle not to ignore header files. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: checking status semantics with compatible functions
On Wed, Mar 30, 2011 at 03:26:29AM -0500, Kumar Gala wrote:
[Adding proper lists on CC]
- k
On Mar 30, 2011, at 3:07 AM, Kumar Gala wrote:
Grant,
We have a few helper functions like:
drivers/of/base.c:EXPORT_SYMBOL(of_device_is_compatible);
drivers/of/base.c:EXPORT_SYMBOL(of_find_compatible_node);
That we use in places like arch/powerpc/platform/85xx/mpc85xx_ds.c:
for_each_node_by_type(np, pci) {
if (of_device_is_compatible(np, fsl,mpc8540-pci) ||
of_device_is_compatible(np, fsl,mpc8548-pcie) ||
of_device_is_compatible(np, fsl,p2020-pcie)) {
It seems like we should check 'status' in these cases with
'of_device_is_available'. I'm thinking that we should have
versions of the helpers that also do the 'of_device_is_available'
checking. Or should we just change the helpers to call
of_device_is_available?
Yes, of_device_is_available() should be checked, but it should not be
added directly to of_device_is_compatible(). I'm okay with adding
a helper variant that does the of_device_is_compatible() check.
In that particular case, I'd also suggest using for_each_matching_node().
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] POWER: perf_event: Skip updating kernel counters if register value shrinks
On Wed, 30 Mar 2011, Benjamin Herrenschmidt wrote: On Tue, 2011-03-29 at 10:25 -0400, Eric B Munson wrote: Here I made the assumption that the hardware would never remove more events in a speculative roll back than it had added. This is not a situation I encoutered in my limited testing, so I didn't think underflow was possible. I will send out a V2 using the signed 32 bit delta and remeber to CC stable this time. I'm not thinking about underflow but rollover... or that isn't possible with those counters ? IE. They don't wrap back to 0 after hitting ? They do roll over to 0 after , but I thought that case was already covered by the perf_event_interrupt. Are you concerned that we will reset a counter and speculative roll back will underflow that counter? signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mmotm threatens ppc preemption again
On Mon, 21 Mar 2011 13:22:30 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Sun, 2011-03-20 at 19:20 -0700, Hugh Dickins wrote: As long as the races to avoid are between map/unmap vs. access, yes, it -should- be fine, and we used to not do demand faulting on kernel space (but for how long ?). I'm wondering why we don't just stick a ptl in there or is there a good reason why we can't ? We can - but we usually prefer to avoid unnecessary locking. An arch function which locks init_mm.page_table_lock on powerpc, but does nothing on others? That still means gratuitous differences between how the normal and kernel page tables are handled. Maybe that's not worth bothering ... So what will we do here? I still have mm-remove-unused-token-argument-from-apply_to_page_range-callback.patch mm-add-apply_to_page_range_batch.patch ioremap-use-apply_to_page_range_batch-for-ioremap_page_range.patch vmalloc-use-plain-pte_clear-for-unmaps.patch vmalloc-use-apply_to_page_range_batch-for-vunmap_page_range.patch vmalloc-use-apply_to_page_range_batch-for-vmap_page_range_noflush.patch vmalloc-use-apply_to_page_range_batch-in-alloc_vm_area.patch xen-mmu-use-apply_to_page_range_batch-in-xen_remap_domain_mfn_range.patch xen-grant-table-use-apply_to_page_range_batch.patch floating around and at some stage they may cause merge problems. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mmotm threatens ppc preemption again
On 03/30/2011 01:53 PM, Andrew Morton wrote: On Mon, 21 Mar 2011 13:22:30 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Sun, 2011-03-20 at 19:20 -0700, Hugh Dickins wrote: As long as the races to avoid are between map/unmap vs. access, yes, it -should- be fine, and we used to not do demand faulting on kernel space (but for how long ?). I'm wondering why we don't just stick a ptl in there or is there a good reason why we can't ? We can - but we usually prefer to avoid unnecessary locking. An arch function which locks init_mm.page_table_lock on powerpc, but does nothing on others? That still means gratuitous differences between how the normal and kernel page tables are handled. Maybe that's not worth bothering ... So what will we do here? I still have mm-remove-unused-token-argument-from-apply_to_page_range-callback.patch mm-add-apply_to_page_range_batch.patch ioremap-use-apply_to_page_range_batch-for-ioremap_page_range.patch vmalloc-use-plain-pte_clear-for-unmaps.patch vmalloc-use-apply_to_page_range_batch-for-vunmap_page_range.patch vmalloc-use-apply_to_page_range_batch-for-vmap_page_range_noflush.patch vmalloc-use-apply_to_page_range_batch-in-alloc_vm_area.patch xen-mmu-use-apply_to_page_range_batch-in-xen_remap_domain_mfn_range.patch xen-grant-table-use-apply_to_page_range_batch.patch floating around and at some stage they may cause merge problems. Well, my understanding of the situation is: 1. There's a basic asymmetry between user and kernel pagetables, in that the former has a standard pte locking scheme, whereas the latter uses ad-hoc locking depending on what particular subsystem is doing the changes (presumably to its own private piece of kernel virtual address space) 2. Power was assuming that all lazy mmu updates were done under spinlock, or are at least non-preemptable. This is incompatible with 1), but it was moot because no kernel updates were done lazily 3. These patches add the first instance of lazy mmu updates, which reveals the mismatch between Power's expectations and the actual locking rules. So the options are: 1. Change the locking rules for kernel updates to also require a pte lock 2. Special-case batched kernel updates to include a pte lock 3. Make Power deal with preemption during a batched kernel update 4. Never do batched kernel updates on Power 5. Never do batched kernel updates (the current state) 1 seems like a big change. 2 is pretty awkward, and has the side-effect of increasing preemption latencies (since if you're doing enough updates to be worth batching, you'll be disabling preemption for a longish time). I don't know how complex 3 is; I guess it depends on the details of the batched hashtable update thingy. 4 looks like it should be simple. 5 is the default do-nothing state, but it seems unfair on anyone who can actually take advantage of batched updates. Ben, how hard would something like 3 or 4 be to implement? Thanks, J ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/5] xhci: Remove recursive call to xhci_handle_event
On 30/03/11 07:00, Dmitry Torokhov wrote:
On Sunday, March 27, 2011 09:53:00 pm Matt Evans wrote:
@@ -2282,7 +2284,7 @@ hw_died:
/* FIXME this should be a delayed service routine
* that clears the EHB.
*/
-xhci_handle_event(xhci);
+while (xhci_handle_event(xhci)) {}
I must admit I dislike the style with empty loop bodies, do you think
we could have something like below instead?
Well, although I don't mind empty while()s at all (they're clean and obvious
IMHO) I would remove an empty blightful while loop with something like this:
do {
ret = xhci_handle_event(xhci);
} while (ret 0);
;-) (Not sure that refactoring its contents into the IRQ handler is a good idea,
if that area's going to be revisited soon to extend error
handling/reporting.)
Cheers,
Matt
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mmotm threatens ppc preemption again
On Wed, 2011-03-30 at 14:07 -0700, Jeremy Fitzhardinge wrote: 1. Change the locking rules for kernel updates to also require a pte lock 2. Special-case batched kernel updates to include a pte lock 3. Make Power deal with preemption during a batched kernel update 4. Never do batched kernel updates on Power 5. Never do batched kernel updates (the current state) We deal with preemption already since the PTL turns into a mutex on -rt, so we could bring that patch into mainline. The easiest approach however for now would be to not do the kernel batched updates on kernel (solution 4), and I can sort it out later if I want to enable it. The problem is that it's hard for me to fix that with the current accessors as arch_enter_lazy_mmu_mode() don't get any argument that could point me to which mm is being operated on. Jeremy, I haven't had a chance to look at your patches in detail, do you just use those accessors or do you create new ones for batching kernel updates in which case powerpc could just make them do nothing ? Else, we could have one patch that adds an mm argument accross the tree, it shouldn't be too hard. Later on, I can bring in the stuff from -rt stuff to enable lazy batching of kernel pages on power if I wish to do so. Cheers, Ben ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to define an I2C-to-SPI bridge device ?
On Tue, Mar 29, 2011 at 06:21:50PM +0200, Andre Schwarz wrote: On 03/25/2011 10:28 AM, Andre Schwarz wrote: Grant, Anton, got it. providing modalis = spidev within spi_board_info works like a charme ... Good. Glad you got it sorted out. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
