Re: [PATCH v3 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100
On Sun, Nov 3, 2013 at 10:07 PM, Stephen Chivers schiv...@csc.com wrote:
+++ b/arch/powerpc/boot/dts/mvme5100.dts
@@ -0,0 +1,185 @@
+/*
+ * Device Tree Souce for Motorola/Emerson MVME5100.
Source
(unless this expresses your personal appreciation for device trees ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/powernv: Reserve the correct PE number
We're assigning PE numbers after the completion of PCI probe. During
the PCI probe, we had PE#0 as the super container to encompass all
PCI devices. However, that's inappropriate since PELTM has ascending
order of priority on search on P7IOC. So we need PE#127 takes the
role that PE#0 has previously. For PHB3, we still have PE#0 as the
reserved PE.
The patch supposes that the underly firmware has built the RID to
PE# mapping after resetting IODA tables: all PELTM entries except
last one has invalid mapping on P7IOC, but all RTEs have binding
to PE#0. The reserved PE# is being exported by firmware by device
tree.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/pci-ioda.c | 22 +-
arch/powerpc/platforms/powernv/pci.c | 10 +++---
arch/powerpc/platforms/powernv/pci.h |1 +
3 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 198566e..084cdfa 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1209,12 +1209,13 @@ void __init pnv_pci_init_ioda_phb(struct device_node
*np,
pr_err( Failed to map registers !\n);
/* Initialize more IODA stuff */
+ phb-ioda.total_pe = 1;
prop32 = of_get_property(np, ibm,opal-num-pes, NULL);
- if (!prop32)
- phb-ioda.total_pe = 1;
- else
+ if (prop32)
phb-ioda.total_pe = be32_to_cpup(prop32);
-
+ prop32 = of_get_property(np, ibm,opal-reserved-pe, NULL);
+ if (prop32)
+ phb-ioda.reserved_pe = be32_to_cpup(prop32);
phb-ioda.m32_size = resource_size(hose-mem_resources[0]);
/* FW Has already off top 64k of M32 space (MSI space) */
phb-ioda.m32_size += 0x1;
@@ -1243,7 +1244,7 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np,
if (phb-type == PNV_PHB_IODA1)
phb-ioda.io_segmap = aux + iomap_off;
phb-ioda.pe_array = aux + pemap_off;
- set_bit(0, phb-ioda.pe_alloc);
+ set_bit(phb-ioda.reserved_pe, phb-ioda.pe_alloc);
INIT_LIST_HEAD(phb-ioda.pe_dma_list);
INIT_LIST_HEAD(phb-ioda.pe_list);
@@ -1268,8 +1269,10 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np,
segment_size);
#endif
- pr_info( %d PE's M32: 0x%x [segment=0x%x] IO: 0x%x [segment=0x%x]\n,
+ pr_info( %d (%d) PE's M32: 0x%x [segment=0x%x]
+IO: 0x%x [segment=0x%x]\n,
phb-ioda.total_pe,
+ phb-ioda.reserved_pe,
phb-ioda.m32_size, phb-ioda.m32_segsize,
phb-ioda.io_size, phb-ioda.io_segsize);
@@ -1306,13 +1309,6 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np,
rc = opal_pci_reset(phb_id, OPAL_PCI_IODA_TABLE_RESET,
OPAL_ASSERT_RESET);
if (rc)
pr_warning( OPAL Error %ld performing IODA table reset !\n,
rc);
-
- /*
-* On IODA1 map everything to PE#0, on IODA2 we assume the IODA reset
-* has cleared the RTT which has the same effect
-*/
- if (ioda_type == PNV_PHB_IODA1)
- opal_pci_set_pe(phb_id, 0, 0, 7, 1, 1 , OPAL_MAP_PE);
}
void __init pnv_pci_init_ioda2_phb(struct device_node *np)
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index 921ae67..4eb33a9 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -242,11 +242,15 @@ static void pnv_pci_config_check_eeh(struct pnv_phb *phb,
/*
* Get the PE#. During the PCI probe stage, we might not
* setup that yet. So all ER errors should be mapped to
-* PE#0
+* reserved PE.
*/
pe_no = PCI_DN(dn)-pe_number;
- if (pe_no == IODA_INVALID_PE)
- pe_no = 0;
+ if (pe_no == IODA_INVALID_PE) {
+ if (phb-type == PNV_PHB_P5IOC2)
+ pe_no = 0;
+ else
+ pe_no = phb-ioda.reserved_pe;
+ }
/* Read freeze status */
rc = opal_pci_eeh_freeze_status(phb-opal_id, pe_no, fstate, pcierr,
diff --git a/arch/powerpc/platforms/powernv/pci.h
b/arch/powerpc/platforms/powernv/pci.h
index 64d3b12..911c24e 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -125,6 +125,7 @@ struct pnv_phb {
struct {
/* Global bridge info */
unsigned inttotal_pe;
+ unsigned intreserved_pe;
unsigned intm32_size;
unsigned intm32_segsize;
unsigned intm32_pci_base;
--
1.7.9.5
___
Linuxppc-dev
[PATCH 1/2] powerpc/powernv: Add PE to its own PELTV
We need add PE to its own PELTV. Otherwise, the errors originated
from the PE might contribute to other PEs. In the result, we can't
clear up the error successfully even we're checking and clearing
errors during access to PCI config space.
Cc: sta...@vger.kernel.org
Reported-by: kalsh...@in.ibm.com
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/pci-ioda.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index c639af7..198566e 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -163,13 +163,23 @@ static int pnv_ioda_configure_pe(struct pnv_phb *phb,
struct pnv_ioda_pe *pe)
rid_end = pe-rid + 1;
}
- /* Associate PE in PELT */
+ /*
+* Associate PE in PELT. We need add the PE into the
+* corresponding PELT-V as well. Otherwise, the error
+* originated from the PE might contribute to other
+* PEs.
+*/
rc = opal_pci_set_pe(phb-opal_id, pe-pe_number, pe-rid,
bcomp, dcomp, fcomp, OPAL_MAP_PE);
if (rc) {
pe_err(pe, OPAL error %ld trying to setup PELT table\n, rc);
return -ENXIO;
}
+
+ rc = opal_pci_set_peltv(phb-opal_id, pe-pe_number,
+ pe-pe_number, OPAL_ADD_PE_TO_DOMAIN);
+ if (rc)
+ pe_warn(pe, OPAL error %d adding self to PELTV\n, rc);
opal_pci_eeh_freeze_clear(phb-opal_id, pe-pe_number,
OPAL_EEH_ACTION_CLEAR_FREEZE_ALL);
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
On Sat, Nov 02, 2013 at 08:20:48AM -0700, Paul E. McKenney wrote:
On Fri, Nov 01, 2013 at 11:30:17AM +0100, Peter Zijlstra wrote:
Furthermore there's a gazillion parallel userspace programs.
Most of which have very unaggressive concurrency designs.
pthread_mutex_t A, B;
char data_A[x];
int counter_B = 1;
void funA(void)
{
pthread_mutex_lock(A);
memset(data_A, 0, sizeof(data_A));
pthread_mutex_unlock(A);
}
void funB(void)
{
pthread_mutex_lock(B);
counter_B++;
pthread_mutex_unlock(B);
}
void funC(void)
{
pthread_mutex_lock(B)
printf(%d\n, counter_B);
pthread_mutex_unlock(B);
}
Then run: funA, funB, funC concurrently, and end with a funC.
Then explain to userman than his unaggressive program can return:
0
1
Because the memset() thought it might be a cute idea to overwrite
counter_B and fix it up 'later'. Which if I understood you right is
valid in C/C++ :-(
Not that any actual memset implementation exhibiting this trait wouldn't
be shot on the spot.
By marking ptr as atomic, thus telling the compiler not to mess with it.
And thus requiring that all accesses to it be decorated, which in the
case of RCU could be buried in the RCU accessors.
This seems contradictory; marking it atomic would look like:
struct foo {
unsigned long value;
__atomic void *ptr;
unsigned long value1;
};
Clearly we cannot hide this definition in accessors, because then
accesses to value* won't see the annotation.
#define __rcu __atomic
Yeah, except we don't use __rcu all that consistently; in fact I don't
know if I ever added it.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: remove unused REDBOOT Kconfig parameter
This removes the REDBOOT Kconfig parameter, which was no longer used anywhere in the source code and Makefiles. Signed-off-by: Michael Opdenacker michael.opdenac...@free-electrons.com --- arch/powerpc/Kconfig| 3 --- arch/powerpc/platforms/83xx/Kconfig | 1 - arch/powerpc/platforms/8xx/Kconfig | 1 - 3 files changed, 5 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 38f3b7e47ec5..f02a41935c95 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -205,9 +205,6 @@ config DEFAULT_UIMAGE Used to allow a board to specify it wants a uImage built by default default n -config REDBOOT - bool - config ARCH_HIBERNATION_POSSIBLE bool default y diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig index 670a033264c0..2bdc8c862c46 100644 --- a/arch/powerpc/platforms/83xx/Kconfig +++ b/arch/powerpc/platforms/83xx/Kconfig @@ -99,7 +99,6 @@ config SBC834x config ASP834x bool Analogue Micro ASP 834x select PPC_MPC834x - select REDBOOT help This enables support for the Analogue Micro ASP 83xx board. diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig index 8dec3c0911ad..bd6f1a1cf922 100644 --- a/arch/powerpc/platforms/8xx/Kconfig +++ b/arch/powerpc/platforms/8xx/Kconfig @@ -45,7 +45,6 @@ config PPC_EP88XC config PPC_ADDER875 bool Analogue Micro Adder 875 select CPM1 - select REDBOOT help This enables support for the Analogue Micro Adder 875 board. -- 1.8.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
On Mon, Nov 04, 2013 at 10:07:44AM +0100, Peter Zijlstra wrote:
On Sat, Nov 02, 2013 at 08:20:48AM -0700, Paul E. McKenney wrote:
On Fri, Nov 01, 2013 at 11:30:17AM +0100, Peter Zijlstra wrote:
Furthermore there's a gazillion parallel userspace programs.
Most of which have very unaggressive concurrency designs.
pthread_mutex_t A, B;
char data_A[x];
int counter_B = 1;
void funA(void)
{
pthread_mutex_lock(A);
memset(data_A, 0, sizeof(data_A));
pthread_mutex_unlock(A);
}
void funB(void)
{
pthread_mutex_lock(B);
counter_B++;
pthread_mutex_unlock(B);
}
void funC(void)
{
pthread_mutex_lock(B)
printf(%d\n, counter_B);
pthread_mutex_unlock(B);
}
Then run: funA, funB, funC concurrently, and end with a funC.
Then explain to userman than his unaggressive program can return:
0
1
Because the memset() thought it might be a cute idea to overwrite
counter_B and fix it up 'later'. Which if I understood you right is
valid in C/C++ :-(
Not that any actual memset implementation exhibiting this trait wouldn't
be shot on the spot.
Even without such a malicious memcpy() implementation I must still explain
about false sharing when the developer notices that the unaggressive
program isn't running as fast as expected.
By marking ptr as atomic, thus telling the compiler not to mess with
it.
And thus requiring that all accesses to it be decorated, which in the
case of RCU could be buried in the RCU accessors.
This seems contradictory; marking it atomic would look like:
struct foo {
unsigned long value;
__atomic void *ptr;
unsigned long value1;
};
Clearly we cannot hide this definition in accessors, because then
accesses to value* won't see the annotation.
#define __rcu __atomic
Yeah, except we don't use __rcu all that consistently; in fact I don't
know if I ever added it.
There are more than 300 of them in the kernel. Plus sparse can be
convinced to yell at you if you don't use them. So lack of __rcu could
be fixed without too much trouble.
The C/C++11 need to annotate functions that take arguments or return
values taken from rcu_dereference() is another story. But the compilers
have to get significantly more aggressive or developers have to be doing
unusual things that result in rcu_dereference() returning something whose
value the compiler can predict exactly.
Thanx, Paul
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCHv2 6/8] ASoC: fsl: add SGTL5000 based audio machine driver.
Conflicts:
sound/soc/fsl/Makefile
Ahem.
This will be removed.
+static int fsl_sgtl5000_remove(struct platform_device *pdev) {
+ snd_soc_unregister_card(fsl_sgt1500_card);
+
+ return 0;
+}
You're using snd_soc_unregister_card() so you don't need to do this.
See the next version.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Sun, Nov 03, 2013 at 03:34:00PM -0800, Linus Torvalds wrote: On Sun, Nov 3, 2013 at 2:42 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: smp_storebuffer_mb() -- A barrier that enforces those orderings that do not invalidate the hardware store-buffer optimization. Ugh. Maybe. Can you guarantee that those are the correct semantics? And why talk about the hardware semantics, when you really want specific semantics for the *software*. smp_not_w_r_mb() -- A barrier that orders everything except prior writes against subsequent reads. Ok, that sounds more along the lines of these are the semantics we want, but I have to say, it also doesn't make me go ahh, ok. smp_acqrel_mb() -- A barrier that combines C/C++ acquire and release semantics. (C/C++ acquire orders a specific load against subsequent loads and stores, while C/C++ release orders a specific store against prior loads and stores.) I don't think this is true. acquire+release is much stronger than what you're looking for - it doesn't allow subsequent reads to move past the write (because that would violate the acquire part). On x86, for example, you'd need to have a locked cycle for smp_acqrel_mb(). So again, what are the guarantees you actually want? Describe those. And then make a name. I was thinking in terms of the guarantee that TSO systems provide given a barrier() directive, and that PowerPC provides given the lwsync instruction. This guarantee is that loads preceding the barrier will not be reordered with memory referenced following the barrier, and that stores preceding the barrier will not be reordered with stores following the barrier. But given how much easier RCU reviews became after burying smp_wmb() and smp_read_barrier_depends() into rcu_assign_pointer() and rcu_dereference(), respectively, I think I prefer an extension of your idea below. I _think_ the guarantees you want is: - SMP write barrier - *local* read barrier for reads preceding the write. but the problem is that the preceding reads part is really specifically about the write that you had. The barrier should really be attached to the *particular* write operation, it cannot be a standalone barrier. Indeed, neither rcu_assign_pointer() nor the circular queue really needs a standalone barrier, so that attaching the barrier to a particular memory reference would work. And as you note below, in the case of ARM this would turn into one of their new memory-reference instructions. So it would *kind* of act like a smp_wmb() + smp_rmb(), but the problem is that a smp_rmb() doesn't really attach to the preceding write. This is analogous to a acquire operation: you cannot make an acquire barrier, because it's not a barrier *between* two ops, it's associated with one particular op. But you -could- use any barrier that prevented reordering of any preceding load with any subsequent memory reference. Please note that I am -not- advocating this anymore, because I like the idea of attaching the barrier to a particular memory operation. However, for completeness, here it is in the case of TSO systems and PowerPC, respectively: #define smp_acquire_mb() barrier(); #define smp_acquire_mb() \ __asm__ __volatile__ (stringify_in_c(LWSYNC) : : :memory); This functions correctly, but is a pain to review because you have to figure out which of many possible preceding loads the smp_acquire_mb() is supposed to attach to. As you say, it is -way- better to attach the barrier to a particular memory operation. So what I *think* you actually really really want is a store with release consistency, followed by a write barrier. I believe that the combination of store with release consistency and load with acquire consistency should do the trick for the two use cases at this point, which again are circular buffers and rcu_assign_pointer(). At this point, I don't see the need for followed by a write barrier. But I step through the circular buffers below. In TSO, afaik all stores have release consistency, and all writes are ordered, which is why this is a no-op in TSO. And x86 also has that all stores have release consistency, and all writes are ordered model, even if TSO doesn't really describe the x86 model. Yep, as does the mainframe. And these architectures also have all reads having acquire consistency. But on ARM64, for example, I think you'd really want the store itself to be done with stlr (store with release), and then follow up with a dsb st after that. Agree with the stlr but don't (yet, anyway) understand the need for a subsequent dsb st. And notice how that requires you to mark the store itself. There is no actual barrier *after* the store that does the optimized model. And marking the store itself is a very good thing from my viewpoint. Of course, it's entirely possible that it's not worth worrying about this on ARM64, and that just doing it as a normal
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Sun, Nov 03, 2013 at 11:34:00PM +, Linus Torvalds wrote: So it would *kind* of act like a smp_wmb() + smp_rmb(), but the problem is that a smp_rmb() doesn't really attach to the preceding write. Agreed. This is analogous to a acquire operation: you cannot make an acquire barrier, because it's not a barrier *between* two ops, it's associated with one particular op. So what I *think* you actually really really want is a store with release consistency, followed by a write barrier. How does that order reads against reads? (Paul mentioned this as a requirement). I not clear about the use case for this, so perhaps there is a dependency that I'm not aware of. In TSO, afaik all stores have release consistency, and all writes are ordered, which is why this is a no-op in TSO. And x86 also has that all stores have release consistency, and all writes are ordered model, even if TSO doesn't really describe the x86 model. But on ARM64, for example, I think you'd really want the store itself to be done with stlr (store with release), and then follow up with a dsb st after that. So a dsb is pretty heavyweight here (it prevents execution of *any* further instructions until all preceeding stores have completed, as well as ensuring completion of any ongoing cache flushes). In conjunction with the store-release, that's going to hold everything up until the store-release (and therefore any preceeding memory accesses) have completed. Granted, I think that gives Paul his read/read ordering, but it's a lot heavier than what's required. And notice how that requires you to mark the store itself. There is no actual barrier *after* the store that does the optimized model. Of course, it's entirely possible that it's not worth worrying about this on ARM64, and that just doing it as a normal store followed by a full memory barrier is good enough. But at least in *theory* a microarchitecture might make it much cheaper to do a store with release consistency followed by write barrier. I agree with the sentiment but, given that this stuff is so heavily microarchitecture-dependent (and not simple to probe), a simple dmb ish might be the best option after all. That's especially true if the microarchitecture decided to ignore the barrier options and treat everything as `all accesses, full system' in order to keep the hardware design simple. Will ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Mon, Nov 04, 2013 at 02:51:00AM -0800, Paul E. McKenney wrote:
OK, something like this for the definitions (though PowerPC might want
to locally abstract the lwsync expansion):
#define smp_store_with_release_semantics(p, v) /* x86, s390, etc. */ \
do { \
barrier(); \
ACCESS_ONCE(p) = (v); \
} while (0)
#define smp_store_with_release_semantics(p, v) /* PowerPC. */ \
do { \
__asm__ __volatile__ (stringify_in_c(LWSYNC) : : :memory); \
ACCESS_ONCE(p) = (v); \
} while (0)
#define smp_load_with_acquire_semantics(p) /* x86, s390, etc. */ \
({ \
typeof(*p) *_p1 = ACCESS_ONCE(p); \
barrier(); \
_p1; \
})
#define smp_load_with_acquire_semantics(p) /* PowerPC. */ \
({ \
typeof(*p) *_p1 = ACCESS_ONCE(p); \
__asm__ __volatile__ (stringify_in_c(LWSYNC) : : :memory); \
_p1; \
})
For ARM, smp_load_with_acquire_semantics() is a wrapper around the ARM
ldar instruction and smp_store_with_release_semantics() is a wrapper
around the ARM stlr instruction.
This still leaves me confused as to what to do with my case :/
Slightly modified since last time -- as the simplified version was maybe
simplified too far.
To recap, I'd like to get rid of barrier A where possible, since that's
now a full barrier for every event written.
However, there's no immediate store I can attach it to; the obvious one
would be the kbuf-head store, but that's complicated by the
local_cmpxchg() thing.
And we need that cmpxchg loop because a hardware NMI event can
interleave with a software event.
And to be honest, I'm still totally confused about memory barriers vs
control flow vs C/C++. The only way we're ever getting to that memcpy is
if we've already observed ubuf-tail, so that LOAD has to be fully
processes and completed.
I'm really not seeing how a STORE from the memcpy() could possibly go
wrong; and if C/C++ can hoist the memcpy() over a compiler barrier()
then I suppose we should all just go home.
/me who wants A to be a barrier() but is terminally confused.
---
/*
* One important detail is that the kbuf part and the kbuf_writer() are
* strictly per cpu and we can thus rely on program order for those.
*
* Only the userspace consumer can possibly run on another cpu, and thus we
* need to ensure data consistency for those.
*/
struct buffer {
u64 size;
u64 tail;
u64 head;
void *data;
};
struct buffer *kbuf, *ubuf;
/*
* If there's space in the buffer; store the data @buf; otherwise
* discard it.
*/
void kbuf_write(int sz, void *buf)
{
u64 tail, head, offset;
do {
tail = ACCESS_ONCE(ubuf-tail);
offset = head = kbuf-head;
if (CIRC_SPACE(head, tail, kbuf-size) sz) {
/* discard @buf */
return;
}
head += sz;
} while (local_cmpxchg(kbuf-head, offset, head) != offset)
/*
* Ensure that if we see the userspace tail (ubuf-tail) such
* that there is space to write @buf without overwriting data
* userspace hasn't seen yet, we won't in fact store data before
* that read completes.
*/
smp_mb(); /* A, matches with D */
memcpy(kbuf-data + offset, buf, sz);
/*
* Ensure that we write all the @buf data before we update the
* userspace visible ubuf-head pointer.
*/
smp_wmb(); /* B, matches with C */
ubuf-head = kbuf-head;
}
/*
* Consume the buffer data and update the tail pointer to indicate to
* kernel space there's 'free' space.
*/
void ubuf_read(void)
{
u64 head, tail;
tail = ACCESS_ONCE(ubuf-tail);
head = ACCESS_ONCE(ubuf-head);
/*
* Ensure we read the buffer boundaries before the actual buffer
* data...
*/
smp_rmb(); /* C, matches with B */
while (tail != head) {
obj = ubuf-data + tail;
/* process obj */
tail += obj-size;
tail %= ubuf-size;
}
/*
* Ensure all data reads are complete before we issue the
* ubuf-tail update; once that update hits, kbuf_write() can
* observe and overwrite data.
*/
smp_mb(); /* D, matches with A */
ubuf-tail = tail;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V2 PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores
On 11/3/2013 8:34 PM, Benjamin Herrenschmidt wrote: On Thu, 2013-10-31 at 13:38 -0500, Tom wrote: From: Tom Musta tommu...@gmail.com This patch addresses unaligned single precision floating point loads and stores in the single-step code. The old implementation improperly treated an 8 byte structure as an array of two 4 byte words, which is a classic little endian bug. Do that patch differ from v1 ? I also already merged v1 of this one (the only one I didn't merge is the emulate_step one) Cheers, Ben. Ben: Only patch 1/3 (Enable emulate_step in Little Endian Mode) differs in V2. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On Mon, Nov 04, 2013 at 07:35:12AM +, Li Xiubo wrote:
From the ASoC subsystem comments we can see that:
++
Configures the clock dividers. This is used to derive the best DAI bit and
frame clocks from the system or master clock. It's best to set the DAI bit
and frame clocks as low as possible to save system power.
--
You should never use this unless you have to, there is no point in every
single machine driver using your driver having to duplicate the same
calculations.
+static int fsl_sai_dai_probe(struct snd_soc_dai *dai) {
+ int ret;
+ struct fsl_sai *sai = dev_get_drvdata(dai-dev);
+
+ ret = clk_prepare_enable(sai-clk);
+ if (ret)
+ return ret;
It'd be nicer to only enable the clock while the device is in active use.
While if the module clock is not enabled here, the followed registers cannot
read/write in the same function.
And this _probe function is the _dai_probe not the driver's module _probe.
So you can enable the clock when you explicitly need to write to the
registers...
If the clk_prepare_enable(sai-clk) is not here, where should it be will be
nicer ?
One of the following functions ?
.set_sysclk = fsl_sai_set_dai_sysclk,
.set_clkdiv = fsl_sai_set_dai_clkdiv,
.set_fmt= fsl_sai_set_dai_fmt,
.set_tdm_slot = fsl_sai_set_dai_tdm_slot,
.hw_params = fsl_sai_hw_params,
.trigger= fsl_sai_trigger,
It could be in any or all of them except trigger (where the core should
hold a runtime PM reference anyway). You can always take a reference
for the duration of the function if you're concerned it may be called
when the referent isn't otherwise held.
+ ret = snd_dmaengine_pcm_register(pdev-dev, NULL,
+ SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
+ if (ret)
+ return ret;
We should have a devm_ version of this.
Sorry, is there one patch for adding the devm_ version of
snd_dmaengine_pcm_register() already ?
In the -next and other topics branches I could not find it.
No, there isn't one but there should be one.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Mon, Nov 04, 2013 at 08:27:32AM -0800, Paul E. McKenney wrote:
/*
* One important detail is that the kbuf part and the kbuf_writer() are
* strictly per cpu and we can thus rely on program order for those.
*
* Only the userspace consumer can possibly run on another cpu, and thus we
* need to ensure data consistency for those.
*/
struct buffer {
u64 size;
u64 tail;
u64 head;
void *data;
};
struct buffer *kbuf, *ubuf;
/*
* If there's space in the buffer; store the data @buf; otherwise
* discard it.
*/
void kbuf_write(int sz, void *buf)
{
u64 tail, head, offset;
do {
tail = ACCESS_ONCE(ubuf-tail);
So the above load is the key load. It determines whether or not we
have space in the buffer. This of course assumes that only this CPU
writes to -head.
This assumption is true.
If so, then:
tail = smp_load_with_acquire_semantics(ubuf-tail); /* A - D */
OK, the way I understand ACQUIRE semantics are the semi-permeable LOCK
semantics from Documetnation/memory-barriers.txt. In which case the
relevant STORES below could be hoisted up here, but not across the READ,
which I suppose is sufficient.
offset = head = kbuf-head;
if (CIRC_SPACE(head, tail, kbuf-size) sz) {
/* discard @buf */
return;
}
head += sz;
} while (local_cmpxchg(kbuf-head, offset, head) != offset)
If there is an issue with kbuf-head, presumably local_cmpxchg() fails
and we retry.
But sheesh, do you think we could have buried the definitions of
local_cmpxchg() under a few more layers of macro expansion just to
keep things more obscure? Anyway, griping aside...
o __cmpxchg_local_generic() in include/asm-generic/cmpxchg-local.h
doesn't seem to exclude NMIs, so is not safe for this usage.
o __cmpxchg_local() in ARM handles NMI as long as the
argument is 32 bits, otherwise, it uses the aforementionted
__cmpxchg_local_generic(), which does not handle NMI. Given your
u64, this does not look good...
And some ARM subarches (e.g., metag) seem to fail to handle NMI
even in the 32-bit case.
o FRV and M32r seem to act similar to ARM.
Or maybe these architectures don't do NMIs? If they do, local_cmpxchg()
does not seem to be safe against NMIs in general. :-/
That said, powerpc, 64-bit s390, sparc, and x86 seem to handle it.
Ah my bad, so the in-kernel kbuf variant uses unsigned long, which on
all archs should be the native words size and cover the address space.
Only the public variant (ubuf) is u64 wide to not change data structure
layout on compat etc.
I suppose this was a victim on the simplification :/
And in case of 32bit the upper word will always be zero and the partial
reads should all work out just fine.
Of course, x86's local_cmpxchg() has full memory barriers implicitly.
Not quite, the 'lock' in __raw_cmpxchg() expands to due to
__cmpxchg_local(), etc..
/*
* Ensure that if we see the userspace tail (ubuf-tail) such
* that there is space to write @buf without overwriting data
* userspace hasn't seen yet, we won't in fact store data before
* that read completes.
*/
smp_mb(); /* A, matches with D */
Given a change to smp_load_with_acquire_semantics() above, you should not
need this smp_mb().
Because the STORES can not be hoisted across the ACQUIRE, indeed.
memcpy(kbuf-data + offset, buf, sz);
/*
* Ensure that we write all the @buf data before we update the
* userspace visible ubuf-head pointer.
*/
smp_wmb(); /* B, matches with C */
ubuf-head = kbuf-head;
Replace the smp_wmb() and the assignment with:
smp_store_with_release_semantics(ubuf-head, kbuf-head); /* B - C */
And here the RELEASE semantics I assume are the same as the
semi-permeable UNLOCK from _The_ document? In which case the above
STORES cannot be lowered across this store and all should, again, be
well.
}
/*
* Consume the buffer data and update the tail pointer to indicate to
* kernel space there's 'free' space.
*/
void ubuf_read(void)
{
u64 head, tail;
tail = ACCESS_ONCE(ubuf-tail);
Does anyone else write tail? Or is this defense against NMIs?
No, we're the sole writer; just general paranoia. Not sure the actual
userspace does this; /me checks. Nope, distinct lack of ACCESS_ONCE()
there, just the rmb(), which including a barrier() should hopefully
accomplish similar things most of the time ;-)
I'll need to introduce ACCESS_ONCE to the userspace code.
If no one else writes to tail and if NMIs cannot muck things up, then
the above ACCESS_ONCE() is not needed, though I would not object to its
staying.
[PATCH 2/6] powerpc: fix e500 SPE float rounding inexactness detection
From: Joseph Myers jos...@codesourcery.com
The e500 SPE floating-point emulation code for the rounding modes
rounding to positive or negative infinity (which may not be
implemented in hardware) tries to avoid emulating rounding if the
result was inexact. However, it tests inexactness using the sticky
bit with the cumulative result of previous operations, rather than
with the non-sticky bits relating to the operation that generated the
interrupt. Furthermore, when a vector operation generates the
interrupt, it's possible that only one of the low and high parts is
inexact, and so only that part should have rounding emulated. This
results in incorrect rounding of exact results in these modes when the
sticky bit is set from a previous operation.
(I'm not sure why the rounding interrupts are generated at all when
the result is exact, but empirically the hardware does generate them.)
This patch checks for inexactness using the correct bits of SPEFSCR,
and ensures that rounding only occurs when the relevant part of the
result was actually inexact.
Signed-off-by: Joseph Myers jos...@codesourcery.com
---
Previous submission: http://lkml.org/lkml/2013/10/4/497.
diff --git a/arch/powerpc/math-emu/math_efp.c b/arch/powerpc/math-emu/math_efp.c
index 59835c6..ecdf35d 100644
--- a/arch/powerpc/math-emu/math_efp.c
+++ b/arch/powerpc/math-emu/math_efp.c
@@ -680,7 +680,8 @@ int speround_handler(struct pt_regs *regs)
{
union dw_union fgpr;
int s_lo, s_hi;
- unsigned long speinsn, type, fc;
+ int lo_inexact, hi_inexact;
+ unsigned long speinsn, type, fc, fptype;
if (get_user(speinsn, (unsigned int __user *) regs-nip))
return -EFAULT;
@@ -693,8 +694,12 @@ int speround_handler(struct pt_regs *regs)
__FPU_FPSCR = mfspr(SPRN_SPEFSCR);
pr_debug(speinsn:%08lx spefscr:%08lx\n, speinsn, __FPU_FPSCR);
+ fptype = (speinsn 5) 0x7;
+
/* No need to round if the result is exact */
- if (!(__FPU_FPSCR FP_EX_INEXACT))
+ lo_inexact = __FPU_FPSCR (SPEFSCR_FG | SPEFSCR_FX);
+ hi_inexact = __FPU_FPSCR (SPEFSCR_FGH | SPEFSCR_FXH);
+ if (!(lo_inexact || (hi_inexact fptype == VCT)))
return 0;
fc = (speinsn 21) 0x1f;
@@ -705,7 +710,7 @@ int speround_handler(struct pt_regs *regs)
pr_debug(round fgpr: %08x %08x\n, fgpr.wp[0], fgpr.wp[1]);
- switch ((speinsn 5) 0x7) {
+ switch (fptype) {
/* Since SPE instructions on E500 core can handle round to nearest
* and round toward zero with IEEE-754 complied, we just need
* to handle round toward +Inf and round toward -Inf by software.
@@ -728,11 +733,15 @@ int speround_handler(struct pt_regs *regs)
case VCT:
if (FP_ROUNDMODE == FP_RND_PINF) {
- if (!s_lo) fgpr.wp[1]++; /* Z_low 0, choose Z1 */
- if (!s_hi) fgpr.wp[0]++; /* Z_high word 0, choose Z1
*/
+ if (lo_inexact !s_lo)
+ fgpr.wp[1]++; /* Z_low 0, choose Z1 */
+ if (hi_inexact !s_hi)
+ fgpr.wp[0]++; /* Z_high word 0, choose Z1 */
} else { /* round to -Inf */
- if (s_lo) fgpr.wp[1]++; /* Z_low 0, choose Z2 */
- if (s_hi) fgpr.wp[0]++; /* Z_high 0, choose Z2 */
+ if (lo_inexact s_lo)
+ fgpr.wp[1]++; /* Z_low 0, choose Z2 */
+ if (hi_inexact s_hi)
+ fgpr.wp[0]++; /* Z_high 0, choose Z2 */
}
break;
--
Joseph S. Myers
jos...@codesourcery.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/6] math-emu: fix floating-point to integer unsigned saturation
From: Joseph Myers jos...@codesourcery.com
The math-emu macros _FP_TO_INT and _FP_TO_INT_ROUND are supposed to
saturate their results for out-of-range arguments, except in the case
rsigned == 2 (when instead the low bits of the result are taken).
However, in the case rsigned == 0 (converting to unsigned integers),
they mistakenly produce 0 for positive results and the maximum
unsigned integer for negative results, the opposite of correct
unsigned saturation. This patch fixes the logic.
Signed-off-by: Joseph Myers jos...@codesourcery.com
---
Previous submission: http://lkml.org/lkml/2013/10/8/694.
I have made the corresponding changes to the glibc/libgcc copy of this
code, given that it would be desirable to resync the Linux and
glibc/libgcc copies (the latter has had many enhancements and bug
fixes since it was copied into Linux), although strictly this
incorrect saturation is only a bug when trying to emulate particular
instruction semantics, not when used in userspace to implement C
operations where the results of out-of-range conversions are
unspecified or undefined.
diff --git a/include/math-emu/op-common.h b/include/math-emu/op-common.h
index 9696a5e..70fe5e9 100644
--- a/include/math-emu/op-common.h
+++ b/include/math-emu/op-common.h
@@ -685,7 +685,7 @@ do {
\
else
\
{
\
r = 0;
\
- if (X##_s)
\
+ if (!X##_s)
\
r = ~r;
\
}
\
FP_SET_EXCEPTION(FP_EX_INVALID);
\
@@ -762,7 +762,7 @@ do {
\
if (!rsigned)
\
{
\
r = 0;
\
- if (X##_s)
\
+ if (!X##_s)
\
r = ~r;
\
}
\
else if (rsigned != 2)
\
--
Joseph S. Myers
jos...@codesourcery.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/6] powerpc/math-emu: e500 SPE float emulation fixes
This patch series fixes various problems with the floating-point emulation code for powerpc e500 SPE (some being issues with the e500-specific emulation code, some with the generic math-emu headers). All six patches were sent individually last month as the issues were identified and fixed in the course of preparing the e500 glibc port, and received no comments. There are no substantive changes to the patches in this version, but I've retested the glibc port (which is now upstream, along with all the generic math-emu changes relevant to the glibc soft-fp code, and various fixes to soft-fp corresponding to fixes in the kernel code in the hope that at some point we can get the kernel using the current soft-fp code again) with current kernel sources with this patch series applied. The only dependencies between patches in this series should be that patch 5 (fix e500 SPE float to integer and fixed-point conversions) depends on patch 2 (fix e500 SPE float rounding inexactness detection). Other than that, I think any subset of the patches can be applied in any order, if some subset seems OK but there are concerns about other patches in the series. -- Joseph S. Myers jos...@codesourcery.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/6] math-emu: fix floating-point to integer overflow detection
From: Joseph Myers jos...@codesourcery.com
On overflow, the math-emu macro _FP_TO_INT_ROUND tries to saturate its
result (subject to the value of rsigned specifying the desired
overflow semantics). However, if the rounding step has the effect of
increasing the exponent so as to cause overflow (if the rounded result
is 1 larger than the largest positive value with the given number of
bits, allowing for signedness), the overflow does not get detected,
meaning that for unsigned results 0 is produced instead of the maximum
unsigned integer with the give number of bits, without an exception
being raised for overflow, and that for signed results the minimum
(negative) value is produced instead of the maximum (positive) value,
again without an exception. This patch makes the code check for
rounding increasing the exponent and adjusts the exponent value as
needed for the overflow check.
Signed-off-by: Joseph Myers jos...@codesourcery.com
---
Previous submission: http://lkml.org/lkml/2013/10/8/700.
This macro is not present in the glibc/libgcc version of the code. It
remains the case both before and after this patch that the conversions
wrongly treat a signed result of the most negative integer as an
overflow, when actually only that integer minus 1 or smaller should be
an overflow, although this only means an incorrect exception rather
than affecting the value returned; that was one of the bugs I fixed in
the glibc/libgcc version of this code in 2006 (as part of a major
overhaul of the code including various interface changes, so not
trivially backportable to the kernel version).
diff --git a/include/math-emu/op-common.h b/include/math-emu/op-common.h
index 70fe5e9..6bdf8c6 100644
--- a/include/math-emu/op-common.h
+++ b/include/math-emu/op-common.h
@@ -743,12 +743,17 @@ do {
\
}
\
else
\
{
\
+ int _lz0, _lz1;
\
if (X##_e = -_FP_WORKBITS - 1)
\
_FP_FRAC_SET_##wc(X, _FP_MINFRAC_##wc);
\
else
\
_FP_FRAC_SRS_##wc(X, _FP_FRACBITS_##fs - 1 - X##_e,
\
_FP_WFRACBITS_##fs);
\
+ _FP_FRAC_CLZ_##wc(_lz0, X);
\
_FP_ROUND(wc, X);
\
+ _FP_FRAC_CLZ_##wc(_lz1, X);
\
+ if (_lz1 _lz0)
\
+ X##_e++; /* For overflow detection. */
\
_FP_FRAC_SRL_##wc(X, _FP_WORKBITS);
\
_FP_FRAC_ASSEMBLE_##wc(r, X, rsize);
\
}
\
--
Joseph S. Myers
jos...@codesourcery.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/6] powerpc: fix e500 SPE float SIGFPE generation
From: Joseph Myers jos...@codesourcery.com
The e500 SPE floating-point emulation code is called from
SPEFloatingPointException and SPEFloatingPointRoundException in
arch/powerpc/kernel/traps.c. Those functions have support for
generating SIGFPE, but do_spe_mathemu and speround_handler don't
generate a return value to indicate that this should be done. Such a
return value should depend on whether an exception is raised that has
been set via prctl to generate SIGFPE. This patch adds the relevant
logic in these functions so that SIGFPE is generated as expected by
the glibc testsuite.
Signed-off-by: Joseph Myers jos...@codesourcery.com
---
Previous submission: http://lkml.org/lkml/2013/10/10/626.
diff --git a/arch/powerpc/math-emu/math_efp.c b/arch/powerpc/math-emu/math_efp.c
index 01a0abb..28337c9 100644
--- a/arch/powerpc/math-emu/math_efp.c
+++ b/arch/powerpc/math-emu/math_efp.c
@@ -20,6 +20,7 @@
*/
#include linux/types.h
+#include linux/prctl.h
#include asm/uaccess.h
#include asm/reg.h
@@ -691,6 +692,23 @@ update_regs:
pr_debug(va: %08x %08x\n, va.wp[0], va.wp[1]);
pr_debug(vb: %08x %08x\n, vb.wp[0], vb.wp[1]);
+ if (current-thread.fpexc_mode PR_FP_EXC_SW_ENABLE) {
+ if ((FP_CUR_EXCEPTIONS FP_EX_DIVZERO)
+(current-thread.fpexc_mode PR_FP_EXC_DIV))
+ return 1;
+ if ((FP_CUR_EXCEPTIONS FP_EX_OVERFLOW)
+(current-thread.fpexc_mode PR_FP_EXC_OVF))
+ return 1;
+ if ((FP_CUR_EXCEPTIONS FP_EX_UNDERFLOW)
+(current-thread.fpexc_mode PR_FP_EXC_UND))
+ return 1;
+ if ((FP_CUR_EXCEPTIONS FP_EX_INEXACT)
+(current-thread.fpexc_mode PR_FP_EXC_RES))
+ return 1;
+ if ((FP_CUR_EXCEPTIONS FP_EX_INVALID)
+(current-thread.fpexc_mode PR_FP_EXC_INV))
+ return 1;
+ }
return 0;
illegal:
@@ -867,6 +885,8 @@ int speround_handler(struct pt_regs *regs)
pr_debug( to fgpr: %08x %08x\n, fgpr.wp[0], fgpr.wp[1]);
+ if (current-thread.fpexc_mode PR_FP_EXC_SW_ENABLE)
+ return (current-thread.fpexc_mode PR_FP_EXC_RES) ? 1 : 0;
return 0;
}
--
Joseph S. Myers
jos...@codesourcery.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/6] powerpc: fix exception clearing in e500 SPE float emulation
From: Joseph Myers jos...@codesourcery.com
The e500 SPE floating-point emulation code clears existing exceptions
(__FPU_FPSCR = ~FP_EX_MASK;) before ORing in the exceptions from the
emulated operation. However, these exception bits are the sticky,
cumulative exception bits, and should only be cleared by the user
program setting SPEFSCR, not implicitly by any floating-point
instruction (whether executed purely by the hardware or emulated).
The spurious clearing of these bits shows up as missing exceptions in
glibc testing.
Fixing this, however, is not as simple as just not clearing the bits,
because while the bits may be from previous floating-point operations
(in which case they should not be cleared), the processor can also set
the sticky bits itself before the interrupt for an exception occurs,
and this can happen in cases when IEEE 754 semantics are that the
sticky bit should not be set. Specifically, the invalid sticky bit
is set in various cases with non-finite operands, where IEEE 754
semantics do not involve raising such an exception, and the
underflow sticky bit is set in cases of exact underflow, whereas
IEEE 754 semantics are that this flag is set only for inexact
underflow. Thus, for correct emulation the kernel needs to know the
setting of these two sticky bits before the instruction being
emulated.
When a floating-point operation raises an exception, the kernel can
note the state of the sticky bits immediately afterwards. Some
fenv.h functions that affect the state of these bits, such as
fesetenv and feholdexcept, need to use prctl with PR_GET_FPEXC and
PR_SET_FPEXC anyway, and so it is natural to record the state of those
bits during that call into the kernel and so avoid any need for a
separate call into the kernel to inform it of a change to those bits.
Thus, the interface I chose to use (in this patch and the glibc port)
is that one of those prctl calls must be made after any userspace
change to those sticky bits, other than through a floating-point
operation that traps into the kernel anyway. feclearexcept and
fesetexceptflag duly make those calls, which would not be required
were it not for this issue.
Signed-off-by: Joseph Myers jos...@codesourcery.com
---
Previous submission: http://lkml.org/lkml/2013/10/4/495.
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index ce4de5a..0b02e23 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -237,6 +237,8 @@ struct thread_struct {
unsigned long evr[32];/* upper 32-bits of SPE regs */
u64 acc;/* Accumulator */
unsigned long spefscr;/* SPE eFP status */
+ unsigned long spefscr_last; /* SPEFSCR value on last prctl
+ call or trap return */
int used_spe; /* set if process has used spe */
#endif /* CONFIG_SPE */
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
@@ -303,7 +305,9 @@ struct thread_struct {
(_ALIGN_UP(sizeof(init_thread_info), 16) + (unsigned long) init_stack)
#ifdef CONFIG_SPE
-#define SPEFSCR_INIT .spefscr = SPEFSCR_FINVE | SPEFSCR_FDBZE | SPEFSCR_FUNFE
| SPEFSCR_FOVFE,
+#define SPEFSCR_INIT \
+ .spefscr = SPEFSCR_FINVE | SPEFSCR_FDBZE | SPEFSCR_FUNFE |
SPEFSCR_FOVFE, \
+ .spefscr_last = SPEFSCR_FINVE | SPEFSCR_FDBZE | SPEFSCR_FUNFE |
SPEFSCR_FOVFE,
#else
#define SPEFSCR_INIT
#endif
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 96d2fdf..e3b91f1 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1151,6 +1151,7 @@ int set_fpexc_mode(struct task_struct *tsk, unsigned int
val)
if (val PR_FP_EXC_SW_ENABLE) {
#ifdef CONFIG_SPE
if (cpu_has_feature(CPU_FTR_SPE)) {
+ tsk-thread.spefscr_last = mfspr(SPRN_SPEFSCR);
tsk-thread.fpexc_mode = val
(PR_FP_EXC_SW_ENABLE | PR_FP_ALL_EXCEPT);
return 0;
@@ -1182,9 +1183,10 @@ int get_fpexc_mode(struct task_struct *tsk, unsigned
long adr)
if (tsk-thread.fpexc_mode PR_FP_EXC_SW_ENABLE)
#ifdef CONFIG_SPE
- if (cpu_has_feature(CPU_FTR_SPE))
+ if (cpu_has_feature(CPU_FTR_SPE)) {
+ tsk-thread.spefscr_last = mfspr(SPRN_SPEFSCR);
val = tsk-thread.fpexc_mode;
- else
+ } else
return -EINVAL;
#else
return -EINVAL;
diff --git a/arch/powerpc/math-emu/math_efp.c b/arch/powerpc/math-emu/math_efp.c
index a73f088..59835c6 100644
--- a/arch/powerpc/math-emu/math_efp.c
+++ b/arch/powerpc/math-emu/math_efp.c
@@ -630,9 +630,27 @@ update_ccr:
regs-ccr |= (IR ((7 - ((speinsn 23) 0x7)) 2));
update_regs:
- __FPU_FPSCR = ~FP_EX_MASK;
+ /*
+* If the invalid exception sticky bit was set by the
+
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Mon, Nov 04, 2013 at 11:05:53AM +, Will Deacon wrote: On Sun, Nov 03, 2013 at 11:34:00PM +, Linus Torvalds wrote: So it would *kind* of act like a smp_wmb() + smp_rmb(), but the problem is that a smp_rmb() doesn't really attach to the preceding write. Agreed. This is analogous to a acquire operation: you cannot make an acquire barrier, because it's not a barrier *between* two ops, it's associated with one particular op. So what I *think* you actually really really want is a store with release consistency, followed by a write barrier. How does that order reads against reads? (Paul mentioned this as a requirement). I not clear about the use case for this, so perhaps there is a dependency that I'm not aware of. An smp_store_with_release_semantics() orders against prior reads -and- writes. It maps to barrier() for x86, stlr for ARM, and lwsync for PowerPC, as called out in my prototype definitions. In TSO, afaik all stores have release consistency, and all writes are ordered, which is why this is a no-op in TSO. And x86 also has that all stores have release consistency, and all writes are ordered model, even if TSO doesn't really describe the x86 model. But on ARM64, for example, I think you'd really want the store itself to be done with stlr (store with release), and then follow up with a dsb st after that. So a dsb is pretty heavyweight here (it prevents execution of *any* further instructions until all preceeding stores have completed, as well as ensuring completion of any ongoing cache flushes). In conjunction with the store-release, that's going to hold everything up until the store-release (and therefore any preceeding memory accesses) have completed. Granted, I think that gives Paul his read/read ordering, but it's a lot heavier than what's required. I do not believe that we need the trailing dsb st. And notice how that requires you to mark the store itself. There is no actual barrier *after* the store that does the optimized model. Of course, it's entirely possible that it's not worth worrying about this on ARM64, and that just doing it as a normal store followed by a full memory barrier is good enough. But at least in *theory* a microarchitecture might make it much cheaper to do a store with release consistency followed by write barrier. I agree with the sentiment but, given that this stuff is so heavily microarchitecture-dependent (and not simple to probe), a simple dmb ish might be the best option after all. That's especially true if the microarchitecture decided to ignore the barrier options and treat everything as `all accesses, full system' in order to keep the hardware design simple. I believe that we can do quite a bit better with current hardware instructions (in the case of ARM, for a recent definition of current) and also simplify the memory ordering quite a bit. Thanx, Paul ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote:
+#define smp_load_acquire(p, v)
\
I R idiot!! :-)
---
arch/alpha/include/asm/barrier.h | 13 +++
arch/arc/include/asm/barrier.h| 13 +++
arch/arm/include/asm/barrier.h| 26 +
arch/arm64/include/asm/barrier.h | 28 +++
arch/avr32/include/asm/barrier.h | 12 ++
arch/blackfin/include/asm/barrier.h | 13 +++
arch/cris/include/asm/barrier.h | 13 +++
arch/frv/include/asm/barrier.h| 13 +++
arch/h8300/include/asm/barrier.h | 13 +++
arch/hexagon/include/asm/barrier.h| 13 +++
arch/ia64/include/asm/barrier.h | 43 +++
arch/m32r/include/asm/barrier.h | 13 +++
arch/m68k/include/asm/barrier.h | 13 +++
arch/metag/include/asm/barrier.h | 13 +++
arch/microblaze/include/asm/barrier.h | 13 +++
arch/mips/include/asm/barrier.h | 13 +++
arch/mn10300/include/asm/barrier.h| 13 +++
arch/parisc/include/asm/barrier.h | 13 +++
arch/powerpc/include/asm/barrier.h| 15
arch/s390/include/asm/barrier.h | 13 +++
arch/score/include/asm/barrier.h | 13 +++
arch/sh/include/asm/barrier.h | 13 +++
arch/sparc/include/asm/barrier_32.h | 13 +++
arch/sparc/include/asm/barrier_64.h | 13 +++
arch/tile/include/asm/barrier.h | 13 +++
arch/unicore32/include/asm/barrier.h | 13 +++
arch/x86/include/asm/barrier.h| 13 +++
arch/xtensa/include/asm/barrier.h | 13 +++
28 files changed, 423 insertions(+)
diff --git a/arch/alpha/include/asm/barrier.h b/arch/alpha/include/asm/barrier.h
index ce8860a0b32d..464139feee97 100644
--- a/arch/alpha/include/asm/barrier.h
+++ b/arch/alpha/include/asm/barrier.h
@@ -29,6 +29,19 @@ __asm__ __volatile__(mb: : :memory)
#define smp_read_barrier_depends() do { } while (0)
#endif
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p)\
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p); \
+ smp_mb(); \
+ return ___p1; \
+} while (0)
+
#define set_mb(var, value) \
do { var = value; mb(); } while (0)
diff --git a/arch/arc/include/asm/barrier.h b/arch/arc/include/asm/barrier.h
index f6cb7c4ffb35..a779da846fb5 100644
--- a/arch/arc/include/asm/barrier.h
+++ b/arch/arc/include/asm/barrier.h
@@ -30,6 +30,19 @@
#define smp_wmb() barrier()
#endif
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p)\
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p); \
+ smp_mb(); \
+ return ___p1; \
+} while (0)
+
#define smp_mb__before_atomic_dec()barrier()
#define smp_mb__after_atomic_dec() barrier()
#define smp_mb__before_atomic_inc()barrier()
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 60f15e274e6d..4ada4720bdeb 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -53,10 +53,36 @@
#define smp_mb() barrier()
#define smp_rmb() barrier()
#define smp_wmb() barrier()
+
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p)\
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p); \
+ smp_mb(); \
+ return ___p1;
Re: [PATCH v3 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100
geert.uytterhoe...@gmail.com wrote on 11/04/2013 06:59:21 PM:
From: Geert Uytterhoeven ge...@linux-m68k.org
To: Stephen N Chivers/AUS/CSC@CSC
Cc: linuxppc-dev@lists.ozlabs.org linuxppc-dev@lists.ozlabs.org
Date: 11/04/2013 06:59 PM
Subject: Re: [PATCH v3 1/1] powerpc/embedded6xx: Add support for
Motorola/Emerson MVME5100
Sent by: geert.uytterhoe...@gmail.com
On Sun, Nov 3, 2013 at 10:07 PM, Stephen Chivers schiv...@csc.com
wrote:
+++ b/arch/powerpc/boot/dts/mvme5100.dts
@@ -0,0 +1,185 @@
+/*
+ * Device Tree Souce for Motorola/Emerson MVME5100.
Source
Ok. Thanks, will be fixed.
(unless this expresses your personal appreciation for device trees ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker.
But
when I'm talking to journalists I just say programmer or somethinglike
that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote:
On Mon, Nov 04, 2013 at 08:27:32AM -0800, Paul E. McKenney wrote:
All this is leading me to suggest the following shortenings of names:
smp_load_with_acquire_semantics() - smp_load_acquire()
smp_store_with_release_semantics() - smp_store_release()
But names aside, the above gets rid of explicit barriers on TSO
architectures,
allows ARM to avoid full DMB, and allows PowerPC to use lwsync instead of
the heavier-weight sync.
A little something like this? Completely guessed at the arm/arm64/ia64
asm, but at least for those archs I found proper instructions (I hope),
for x86,sparc,s390 which are TSO we can do with a barrier and PPC like
said can do with the lwsync, all others fall back to using a smp_mb().
Should probably come with a proper changelog and an addition to _The_
document.
Maybe something like this for the changelog?
A number of situations currently require the heavyweight smp_mb(),
even though there is no need to order prior stores against later
loads. Many architectures have much cheaper ways to handle these
situations, but the Linux kernel currently has no portable way
to make use of them.
This commit therefore supplies smp_load_acquire() and
smp_store_release() to remedy this situation. The new
smp_load_acquire() primitive orders the specified load against
any subsequent reads or writes, while the new smp_store_release()
primitive orders the specifed store against any prior reads or
writes. These primitives allow array-based circular FIFOs to be
implemented without an smp_mb(), and also allow a theoretical
hole in rcu_assign_pointer() to be closed at no additional
expense on most architectures.
In addition, the RCU experience transitioning from explicit
smp_read_barrier_depends() and smp_wmb() to rcu_dereference()
and rcu_assign_pointer(), respectively resulted in substantial
improvements in readability. It therefore seems likely that
replacing other explicit barriers with smp_load_acquire() and
smp_store_release() will provide similar benefits. It appears
that roughly half of the explicit barriers in core kernel code
might be so replaced.
Some comments below. I believe that opcodes need to be fixed for IA64.
I am unsure of the ifdefs and opcodes for arm64, but the ARM folks should
be able to tell us.
Other than that, for the rest:
Reviewed-by: Paul E. McKenney paul...@linux.vnet.ibm.com
---
arch/alpha/include/asm/barrier.h | 13 +++
arch/arc/include/asm/barrier.h| 13 +++
arch/arm/include/asm/barrier.h| 26 +
arch/arm64/include/asm/barrier.h | 28 +++
arch/avr32/include/asm/barrier.h | 12 ++
arch/blackfin/include/asm/barrier.h | 13 +++
arch/cris/include/asm/barrier.h | 13 +++
arch/frv/include/asm/barrier.h| 13 +++
arch/h8300/include/asm/barrier.h | 13 +++
arch/hexagon/include/asm/barrier.h| 13 +++
arch/ia64/include/asm/barrier.h | 43
+++
arch/m32r/include/asm/barrier.h | 13 +++
arch/m68k/include/asm/barrier.h | 13 +++
arch/metag/include/asm/barrier.h | 13 +++
arch/microblaze/include/asm/barrier.h | 13 +++
arch/mips/include/asm/barrier.h | 13 +++
arch/mn10300/include/asm/barrier.h| 13 +++
arch/parisc/include/asm/barrier.h | 13 +++
arch/powerpc/include/asm/barrier.h| 15
arch/s390/include/asm/barrier.h | 13 +++
arch/score/include/asm/barrier.h | 13 +++
arch/sh/include/asm/barrier.h | 13 +++
arch/sparc/include/asm/barrier_32.h | 13 +++
arch/sparc/include/asm/barrier_64.h | 13 +++
arch/tile/include/asm/barrier.h | 13 +++
arch/unicore32/include/asm/barrier.h | 13 +++
arch/x86/include/asm/barrier.h| 13 +++
arch/xtensa/include/asm/barrier.h | 13 +++
28 files changed, 423 insertions(+)
diff --git a/arch/alpha/include/asm/barrier.h
b/arch/alpha/include/asm/barrier.h
index ce8860a0b32d..464139feee97 100644
--- a/arch/alpha/include/asm/barrier.h
+++ b/arch/alpha/include/asm/barrier.h
@@ -29,6 +29,19 @@ __asm__ __volatile__(mb: : :memory)
#define smp_read_barrier_depends() do { } while (0)
#endif
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Mon, Nov 04, 2013 at 08:18:11PM +0100, Peter Zijlstra wrote:
On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote:
+#define smp_load_acquire(p, v)
\
I R idiot!! :-)
OK, I did miss this one as well... :-/
Thanx, Paul
---
arch/alpha/include/asm/barrier.h | 13 +++
arch/arc/include/asm/barrier.h| 13 +++
arch/arm/include/asm/barrier.h| 26 +
arch/arm64/include/asm/barrier.h | 28 +++
arch/avr32/include/asm/barrier.h | 12 ++
arch/blackfin/include/asm/barrier.h | 13 +++
arch/cris/include/asm/barrier.h | 13 +++
arch/frv/include/asm/barrier.h| 13 +++
arch/h8300/include/asm/barrier.h | 13 +++
arch/hexagon/include/asm/barrier.h| 13 +++
arch/ia64/include/asm/barrier.h | 43
+++
arch/m32r/include/asm/barrier.h | 13 +++
arch/m68k/include/asm/barrier.h | 13 +++
arch/metag/include/asm/barrier.h | 13 +++
arch/microblaze/include/asm/barrier.h | 13 +++
arch/mips/include/asm/barrier.h | 13 +++
arch/mn10300/include/asm/barrier.h| 13 +++
arch/parisc/include/asm/barrier.h | 13 +++
arch/powerpc/include/asm/barrier.h| 15
arch/s390/include/asm/barrier.h | 13 +++
arch/score/include/asm/barrier.h | 13 +++
arch/sh/include/asm/barrier.h | 13 +++
arch/sparc/include/asm/barrier_32.h | 13 +++
arch/sparc/include/asm/barrier_64.h | 13 +++
arch/tile/include/asm/barrier.h | 13 +++
arch/unicore32/include/asm/barrier.h | 13 +++
arch/x86/include/asm/barrier.h| 13 +++
arch/xtensa/include/asm/barrier.h | 13 +++
28 files changed, 423 insertions(+)
diff --git a/arch/alpha/include/asm/barrier.h
b/arch/alpha/include/asm/barrier.h
index ce8860a0b32d..464139feee97 100644
--- a/arch/alpha/include/asm/barrier.h
+++ b/arch/alpha/include/asm/barrier.h
@@ -29,6 +29,19 @@ __asm__ __volatile__(mb: : :memory)
#define smp_read_barrier_depends() do { } while (0)
#endif
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p) \
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p); \
+ smp_mb(); \
+ return ___p1; \
+} while (0)
+
#define set_mb(var, value) \
do { var = value; mb(); } while (0)
diff --git a/arch/arc/include/asm/barrier.h b/arch/arc/include/asm/barrier.h
index f6cb7c4ffb35..a779da846fb5 100644
--- a/arch/arc/include/asm/barrier.h
+++ b/arch/arc/include/asm/barrier.h
@@ -30,6 +30,19 @@
#define smp_wmb() barrier()
#endif
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p) \
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p); \
+ smp_mb(); \
+ return ___p1; \
+} while (0)
+
#define smp_mb__before_atomic_dec() barrier()
#define smp_mb__after_atomic_dec() barrier()
#define smp_mb__before_atomic_inc() barrier()
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 60f15e274e6d..4ada4720bdeb 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -53,10 +53,36 @@
#define smp_mb() barrier()
#define smp_rmb()barrier()
#define smp_wmb()barrier()
+
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p) \
+do {
Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
On Sun, 2013-11-03 at 22:04 -0600, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wang Dongsheng-B40534
Sent: Monday, October 21, 2013 11:11 AM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, October 19, 2013 3:22 AM
To: Wang Dongsheng-B40534
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
On Thu, 2013-10-17 at 22:02 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 2:46 PM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 11:22 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 11:20 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for
pw20 state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 8:16 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for
pw20 state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 1:01 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs
for
pw20 state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, October 15, 2013 2:51 PM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777;
linuxppc-dev@lists.ozlabs.org; Wang
Dongsheng-B40534
Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for
pw20 state and
altivec idle
From: Wang Dongsheng dongsheng.w...@freescale.com
Add a sys interface to enable/diable pw20 state or
altivec idle, and
control the
wait entry time.
Enable/Disable interface:
0, disable. 1, enable.
/sys/devices/system/cpu/cpuX/pw20_state
/sys/devices/system/cpu/cpuX/altivec_idle
Set wait time interface:(Nanosecond)
/sys/devices/system/cpu/cpuX/pw20_wait_time
/sys/devices/system/cpu/cpuX/altivec_idle_wait_time
Example: Base on TBfreq is 41MHZ.
1~48(ns): TB[63]
49~97(ns): TB[62]
98~195(ns): TB[61]
196~390(ns): TB[60]
391~780(ns): TB[59]
781~1560(ns): TB[58] ...
Signed-off-by: Wang Dongsheng
dongsheng.w...@freescale.com
---
*v5:
Change get_idle_ticks_bit function implementation.
*v4:
Move code from 85xx/common.c to kernel/sysfs.c.
Remove has_pw20_altivec_idle function.
Change wait entry_bit to wait time.
diff --git a/arch/powerpc/kernel/sysfs.c
b/arch/powerpc/kernel/sysfs.c
index
27a90b9..10d1128 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -85,6 +85,284 @@ __setup(smt-snooze-delay=,
setup_smt_snooze_delay);
#endif /* CONFIG_PPC64 */
+#ifdef CONFIG_FSL_SOC
+#define MAX_BIT63
+
+static u64 pw20_wt; static u64 altivec_idle_wt;
+
+static unsigned int get_idle_ticks_bit(u64 ns) {
+ u64 cycle;
+
+ if (ns = 1)
+ cycle = div_u64(ns + 500, 1000) *
tb_ticks_per_usec;
+ else
+ cycle = div_u64(ns *
Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
On Sun, 2013-10-20 at 22:27 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, October 19, 2013 3:23 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
On Thu, 2013-10-17 at 21:36 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Friday, October 18, 2013 12:52 AM
To: Wang Dongsheng-B40534
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
On Thu, 2013-10-17 at 00:51 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 11:20 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 8:16 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 1:01 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, October 15, 2013 2:51 PM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org;
Wang
Dongsheng-B40534
Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and
altivec idle
+static ssize_t show_pw20_wait_time(struct device *dev,
+ struct device_attribute *attr,
char
*buf) {
+ u32 value;
+ u64 tb_cycle;
+ s64 time;
+
+ unsigned int cpu = dev-id;
+
+ if (!pw20_wt) {
+ smp_call_function_single(cpu, do_show_pwrmgtcr0,
+value,
1);
+ value = (value PWRMGTCR0_PW20_ENT)
+
PWRMGTCR0_PW20_ENT_SHIFT;
+
+ tb_cycle = (1 (MAX_BIT - value)) * 2;
Is value = 0 and value = 1 legal? These will make tb_cycle =
0,
+ time = div_u64(tb_cycle * 1000,
tb_ticks_per_usec)
- 1;
And time = -1;
Please look at the end of the function, :)
return sprintf(buf, %llu\n, time 0 ? time : 0);
I know you return 0 if value = 0/1, my question was that, is
this correct as per specification?
Ahh, also for value upto 7 you will return 0, no?
If value = 0, MAX_BIT - value = 63 tb_cycle = 0x_,
Actually, tb_cycle will be undefined because you shifted a 32-bit
value
(1) by more than 31 bits. s/1/1ULL/
Actually, we have been discussing this situation that could not have
happened.
See !pw20_wt branch, this branch is read default wait bit.
The default wait bit is 50, the time is about 1ms.
The default wait bit cannot less than 50, means the wait entry time
cannot greater than 1ms.
We have already begun benchmark test, and we got a preliminary results.
55, 56, 57bit looks good, but we need more benchmark to get the default
bit.
What does the default have to do with it? The user could have set a
different value, and then read it back.
Plus, how much time corresponds to bit 50 depends on the actual timebase
frequency which could vary.
if (!pw20_wt) {
smp_call_function_single(cpu, do_show_pwrmgtcr0, value, 1);
value = (value PWRMGTCR0_PW20_ENT)
PWRMGTCR0_PW20_ENT_SHIFT;
tb_cycle = (1 (MAX_BIT - value)) * 2;
time = tb_cycle * (1000 / tb_ticks_per_usec) - 1;
} else {
time = pw20_wt;
}
As we have discussed before we need a variable to save To save the users to
set wait-entry-time value.
See the code, if user have set a value, and the value will be set in pw20_wt.
When the user read it back, the code will do time = pw20_wt branch.
When the user not set the wait-entry-time value and read this sys interface,
the code will do the
[PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
present' made the call to phy_scan optional, if the DT has a link to
the phy node.
However phy_scan has the side effect of calling phy_addr_set, which
writes the phy MDIO address to the ethernet controller. If phy_addr_set
is not called, and the bootloader has not set the correct address then
the driver will fail to function.
Tested on Kirkwood.
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
Cc: David Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 2c210ec..00e43b5 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2890,6 +2890,7 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
PHY_INTERFACE_MODE_GMII);
if (!mp-phy)
err = -ENODEV;
+ phy_addr_set(mp, mp-phy-addr);
} else if (pd-phy_addr != MV643XX_ETH_PHY_NONE) {
mp-phy = phy_scan(mp, pd-phy_addr);
--
1.8.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
Jason, On Mon, Nov 04, 2013 at 05:27:19PM -0700, Jason Gunthorpe wrote: Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node fyi: set core.abbrev = 12 in your git config, according to Linus, 7/8 was a bad decision... present' made the call to phy_scan optional, if the DT has a link to the phy node. However phy_scan has the side effect of calling phy_addr_set, which writes the phy MDIO address to the ethernet controller. If phy_addr_set is not called, and the bootloader has not set the correct address then the driver will fail to function. Tested on Kirkwood. Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com Fixes: cc9d459894b0 net: mv643xx_eth: use of_phy_connect if phy_node present Acked-by: Jason Cooper ja...@lakedaemon.net And it should be suitable for v3.11+ thx, Jason. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, November 05, 2013 7:48 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
altivec idle
On Sun, 2013-10-20 at 22:27 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, October 19, 2013 3:23 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
and altivec idle
On Thu, 2013-10-17 at 21:36 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Friday, October 18, 2013 12:52 AM
To: Wang Dongsheng-B40534
Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
On Thu, 2013-10-17 at 00:51 -0500, Wang Dongsheng-B40534 wrote:
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 11:20 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Thursday, October 17, 2013 8:16 AM
To: Bhushan Bharat-R65777; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for
pw20 state and altivec idle
-Original Message-
From: Bhushan Bharat-R65777
Sent: Thursday, October 17, 2013 1:01 AM
To: Wang Dongsheng-B40534; Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for
pw20 state and altivec idle
-Original Message-
From: Wang Dongsheng-B40534
Sent: Tuesday, October 15, 2013 2:51 PM
To: Wood Scott-B07421
Cc: Bhushan Bharat-R65777;
linuxppc-dev@lists.ozlabs.org; Wang
Dongsheng-B40534
Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for
pw20 state and
altivec idle
+static ssize_t show_pw20_wait_time(struct device *dev,
+ struct device_attribute *attr,
char
*buf) {
+ u32 value;
+ u64 tb_cycle;
+ s64 time;
+
+ unsigned int cpu = dev-id;
+
+ if (!pw20_wt) {
+ smp_call_function_single(cpu,
do_show_pwrmgtcr0,
+value,
1);
+ value = (value PWRMGTCR0_PW20_ENT)
+
PWRMGTCR0_PW20_ENT_SHIFT;
+
+ tb_cycle = (1 (MAX_BIT - value)) * 2;
Is value = 0 and value = 1 legal? These will make
tb_cycle = 0,
+ time = div_u64(tb_cycle * 1000,
tb_ticks_per_usec)
- 1;
And time = -1;
Please look at the end of the function, :)
return sprintf(buf, %llu\n, time 0 ? time : 0);
I know you return 0 if value = 0/1, my question was that, is
this correct as per specification?
Ahh, also for value upto 7 you will return 0, no?
If value = 0, MAX_BIT - value = 63 tb_cycle =
0x_,
Actually, tb_cycle will be undefined because you shifted a
32-bit value
(1) by more than 31 bits. s/1/1ULL/
Actually, we have been discussing this situation that could not
have
happened.
See !pw20_wt branch, this branch is read default wait bit.
The default wait bit is 50, the time is about 1ms.
The default wait bit cannot less than 50, means the wait entry
time
cannot greater than 1ms.
We have already begun benchmark test, and we got a preliminary
results.
55, 56, 57bit looks good, but we need more benchmark to get the
default
bit.
What does the default have to do with it? The user could have set a
different value, and then read it back.
Plus, how much time corresponds to bit 50 depends on the actual
timebase frequency which could vary.
if (!pw20_wt) {
smp_call_function_single(cpu, do_show_pwrmgtcr0, value, 1);
value = (value PWRMGTCR0_PW20_ENT)
PWRMGTCR0_PW20_ENT_SHIFT;
tb_cycle = (1 (MAX_BIT - value)) * 2;
time = tb_cycle * (1000 / tb_ticks_per_usec) - 1;
} else {
time =
Re: [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
Hi Vinod Koul and Dan Williams,
Ping?
On 10/17/2013 01:56 PM, Hongbo Zhang wrote:
Hi Vinod,
I have gotten ACK from Mark for both the 1/3 and 2/3 patches.
Thanks.
On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
This patch adds support to 8-channel DMA engine, thus the driver
works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
drivers/dma/Kconfig |9 +
drivers/dma/fsldma.c |9 ++---
drivers/dma/fsldma.h |2 +-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..3979c65 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -89,14 +89,15 @@ config AT_HDMAC
Support the Atmel AHB DMA controller.
config FSL_DMA
-tristate Freescale Elo and Elo Plus DMA support
+tristate Freescale Elo series DMA support
depends on FSL_SOC
select DMA_ENGINE
select ASYNC_TX_ENABLE_CHANNEL_SWITCH
---help---
- Enable support for the Freescale Elo and Elo Plus DMA
controllers.
- The Elo is the DMA controller on some 82xx and 83xx parts, and
the
- Elo Plus is the DMA controller on 85xx and 86xx parts.
+ Enable support for the Freescale Elo series DMA controllers.
+ The Elo is the DMA controller on some mpc82xx and mpc83xx
parts, the
+ EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3
is on
+ some Txxx and Bxxx parts.
config MPC512X_DMA
tristate Freescale MPC512x built-in DMA engine support
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct
fsldma_device *fdev,
WARN_ON(fdev-feature != chan-feature);
chan-dev = fdev-dev;
-chan-id = ((res.start - 0x100) 0xfff) 7;
+chan-id = (res.start 0xfff) 0x300 ?
+ ((res.start - 0x100) 0xfff) 7 :
+ ((res.start - 0x200) 0xfff) 7;
if (chan-id = FSL_DMA_MAX_CHANS_PER_DEVICE) {
dev_err(fdev-dev, too many channels for device\n);
err = -EINVAL;
@@ -1434,6 +1436,7 @@ static int fsldma_of_remove(struct
platform_device *op)
}
static const struct of_device_id fsldma_of_ids[] = {
+{ .compatible = fsl,elo3-dma, },
{ .compatible = fsl,eloplus-dma, },
{ .compatible = fsl,elo-dma, },
{}
@@ -1455,7 +1458,7 @@ static struct platform_driver fsldma_of_driver = {
static __init int fsldma_init(void)
{
-pr_info(Freescale Elo / Elo Plus DMA driver\n);
+pr_info(Freescale Elo series DMA driver\n);
return platform_driver_register(fsldma_of_driver);
}
@@ -1467,5 +1470,5 @@ static void __exit fsldma_exit(void)
subsys_initcall(fsldma_init);
module_exit(fsldma_exit);
-MODULE_DESCRIPTION(Freescale Elo / Elo Plus DMA driver);
+MODULE_DESCRIPTION(Freescale Elo series DMA driver);
MODULE_LICENSE(GPL);
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..1ffc244 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,7 +112,7 @@ struct fsldma_chan_regs {
};
struct fsldma_chan;
-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
struct fsldma_device {
void __iomem *regs;/* DGSR register base */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, November 05, 2013 5:52 AM To: Wang Dongsheng-B40534 Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Sun, 2013-11-03 at 22:04 -0600, Wang Dongsheng-B40534 wrote: -Original Message- From: Wang Dongsheng-B40534 Sent: Monday, October 21, 2013 11:11 AM To: Wood Scott-B07421 Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wood Scott-B07421 Sent: Saturday, October 19, 2013 3:22 AM To: Wang Dongsheng-B40534 Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle On Thu, 2013-10-17 at 22:02 -0500, Wang Dongsheng-B40534 wrote: -Original Message- From: Bhushan Bharat-R65777 Sent: Thursday, October 17, 2013 2:46 PM To: Wang Dongsheng-B40534; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wang Dongsheng-B40534 Sent: Thursday, October 17, 2013 11:22 AM To: Bhushan Bharat-R65777; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Bhushan Bharat-R65777 Sent: Thursday, October 17, 2013 11:20 AM To: Wang Dongsheng-B40534; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wang Dongsheng-B40534 Sent: Thursday, October 17, 2013 8:16 AM To: Bhushan Bharat-R65777; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Bhushan Bharat-R65777 Sent: Thursday, October 17, 2013 1:01 AM To: Wang Dongsheng-B40534; Wood Scott-B07421 Cc: linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original Message- From: Wang Dongsheng-B40534 Sent: Tuesday, October 15, 2013 2:51 PM To: Wood Scott-B07421 Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534 Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle From: Wang Dongsheng dongsheng.w...@freescale.com Add a sys interface to enable/diable pw20 state or altivec idle, and control the wait entry time. Enable/Disable interface: 0, disable. 1, enable. /sys/devices/system/cpu/cpuX/pw20_state /sys/devices/system/cpu/cpuX/altivec_idle Set wait time interface:(Nanosecond) /sys/devices/system/cpu/cpuX/pw20_wait_time /sys/devices/system/cpu/cpuX/altivec_idle_wait_t ime Example: Base on TBfreq is 41MHZ. 1~48(ns): TB[63] 49~97(ns): TB[62] 98~195(ns): TB[61] 196~390(ns): TB[60] 391~780(ns): TB[59] 781~1560(ns): TB[58] ... Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- *v5: Change get_idle_ticks_bit function implementation. *v4: Move code from 85xx/common.c to kernel/sysfs.c. Remove has_pw20_altivec_idle function. Change wait entry_bit to wait time. diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c index 27a90b9..10d1128 100644 --- a/arch/powerpc/kernel/sysfs.c +++ b/arch/powerpc/kernel/sysfs.c @@ -85,6 +85,284 @@ __setup(smt-snooze-delay=, setup_smt_snooze_delay); #endif /* CONFIG_PPC64 */
RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From the ASoC subsystem comments we can see that:
++
Configures the clock dividers. This is used to derive the best DAI bit
and frame clocks from the system or master clock. It's best to set the
DAI bit and frame clocks as low as possible to save system power.
--
You should never use this unless you have to, there is no point in every
single machine driver using your driver having to duplicate the same
calculations.
Okey, I'll think it over, if not have to, I will revise this.
+static int fsl_sai_dai_probe(struct snd_soc_dai *dai) {
+ int ret;
+ struct fsl_sai *sai = dev_get_drvdata(dai-dev);
+
+ ret = clk_prepare_enable(sai-clk);
+ if (ret)
+ return ret;
It'd be nicer to only enable the clock while the device is in active
use.
While if the module clock is not enabled here, the followed registers
cannot read/write in the same function.
And this _probe function is the _dai_probe not the driver's module
_probe.
So you can enable the clock when you explicitly need to write to the
registers...
If the clk_prepare_enable(sai-clk) is not here, where should it be
will be nicer ?
One of the following functions ?
.set_sysclk = fsl_sai_set_dai_sysclk,
.set_clkdiv = fsl_sai_set_dai_clkdiv,
.set_fmt= fsl_sai_set_dai_fmt,
.set_tdm_slot = fsl_sai_set_dai_tdm_slot,
.hw_params = fsl_sai_hw_params,
.trigger= fsl_sai_trigger,
It could be in any or all of them except trigger (where the core should
hold a runtime PM reference anyway). You can always take a reference for
the duration of the function if you're concerned it may be called when
the referent isn't otherwise held.
While in this _sai_dai_probe function just followed the clock enable sentence,
there are some register writing operations:
The PATCH:
+++
+static int fsl_sai_dai_probe(struct snd_soc_dai *dai) {
+ int ret;
+ struct fsl_sai *sai = dev_get_drvdata(dai-dev);
+
+ ret = clk_prepare_enable(sai-clk); = clock
enable here
+ if (ret)
+ return ret;
+
+ writel(0x0, sai-base + FSL_SAI_RCSR);
==registers writing here.
+ writel(0x0, sai-base + FSL_SAI_TCSR);== and
here
+ writel(sai-dma_params_tx.maxburst, sai-base + FSL_SAI_TCR1);
===and here
+ writel(sai-dma_params_rx.maxburst, sai-base + FSL_SAI_RCR1);
===and here
+
+ dai-playback_dma_data = sai-dma_params_tx;
+ dai-capture_dma_data = sai-dma_params_rx;
+
+ snd_soc_dai_set_drvdata(dai, sai);
+
+ return 0;
+}
-
As your opinions, should I move the four register writing operations to
.set_sysclk/set_clkdiv/... functions too ?
Or just add a clk_disable_unprepare() after them here, and then add
clk_prepare_enable in one of .set_sysclk/set_clkdiv/...?
And the first two of this four registers must be initialize as early as
possible, and if move them to one of the .set_sysclk/set_clkdiv/... functions,
How can I very ensure which one is the first to be called ?
Won't the calling sequence be changed in the feature ?
From the debug logs, we can see that:
1, _sai_probe
This is called when the machine brings up and has one SAI device.
2, _sai_dai_probe
3, .set_sysclk
4, .set_fmt
Are called in order when the machine has Audio driver and is enabled, and also
while the machine brings up.
The above four steps only be called one time in order.
When aplay/arecord is runs the following will be called in order:
5, .set_tdm_slot
6, .hw_param
7, .trigger --begain
8, .trigger -- end
The 2,3,4 are always called almost the same time, and they are all have
register read/write operations.
Now the clk_prepare_enable() is in step 2, and it won't be any different moving
to step 3 or 4.
So, only could move it to step 5 or 6, if so every time the aplay/arecord runs,
clk_prepare_enable() will be
called, and there has no chance to call clk_disable_unprepare().
Now from the code we can see that I have add clk_prepare_enable() in
_sai_dai_probe() and clk_disable_unprepare() in _sai_dai_remove().
Isn't this okey ?
+ ret = snd_dmaengine_pcm_register(pdev-dev, NULL,
+ SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
+ if (ret)
+ return ret;
We should have a devm_ version of this.
Sorry, is there one patch for adding the devm_ version of
snd_dmaengine_pcm_register() already ?
In the -next and other topics branches I could not find it.
No, there isn't one but there should be one.
And if it has existed then I will use it.
BRs,
Xiubo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCHv2 6/8] ASoC: fsl: add SGTL5000 based audio machine driver.
= [...] diff --git a/sound/soc/fsl/fsl-sgtl5000-vf610.c b/sound/soc/fsl/fsl- sgtl5000-vf610.c new file mode 100644 index 000..f535b42 --- /dev/null +++ b/sound/soc/fsl/fsl-sgtl5000-vf610.c @@ -0,0 +1,208 @@ +/* + * Freeacale ALSA SoC Audio using SGT1500 as codec. ^ ^ ^ FreescaleSGTL5000 Yes. See the next version. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCHv2 6/8] ASoC: fsl: add SGTL5000 based audio machine driver.
Hi Nicolin, This is the SGTL5000 codec based audio driver supported with both playback and capture dai link implemention. This implementation is only compatible with device tree definition. Signed-off-by: Alison Wang b18...@freescale.com Signed-off-by: Xiubo Li li.xi...@freescale.com Conflicts: sound/soc/fsl/Makefile --- sound/soc/fsl/Kconfig | 10 ++ sound/soc/fsl/Makefile | 2 + sound/soc/fsl/fsl-sgtl5000-vf610.c | 208 + I just doubt if this file naming is appropriate. Even if we might not have rigor rule for the file names, according to existing ones, they are all in a same pattern: [SoC name]-[codec name].c imx-sgtl5000.c for example I think it would make user less confused about what this file exactly is if this machine driver also follow the pattern: vf610-sgtl5000.c Yes, it looks nicer. @Shawn What do you think about the file name? 3 files changed, 220 insertions(+) create mode 100644 sound/soc/fsl/fsl-sgtl5000-vf610.c diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index 9a8851e..1b835ba 100644 --- a/sound/soc/fsl/Kconfig +++ b/sound/soc/fsl/Kconfig @@ -228,4 +228,14 @@ config SND_SOC_FSL_SAI tristate select SND_SOC_GENERIC_DMAENGINE_PCM +config SND_SOC_FSL_SGTL5000_VF610 Same problem with the this define. + tristate SoC Audio support for FSL boards with sgtl5000 And 'FSL' here confuses me a lot. Because those boards based on i.MX series also could be called FSL boards. Yes, this should be VF610. + depends on OF I2C + select SND_SOC_FSL_SAI + select SND_SOC_FSL_PCM + select SND_SOC_SGTL5000 + help + Say Y if you want to add support for SoC audio on an FSL board with + a sgtl5000 codec. + endif # SND_FSL_SOC diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile index e5acc03..26fc551 100644 --- a/sound/soc/fsl/Makefile +++ b/sound/soc/fsl/Makefile @@ -59,5 +59,7 @@ obj-$(CONFIG_SND_SOC_IMX_MC13783) += snd-soc-imx-mc13783.o # FSL ARM SAI/SGT15000 Platform Support snd-soc-fsl-sai-objs := fsl-sai.o +snd-soc-fsl-sgtl5000-vf610-objs := fsl-sgtl5000-vf610.o obj-$(CONFIG_SND_SOC_FSL_SAI) += snd-soc-fsl-sai.o +obj-$(CONFIG_SND_SOC_FSL_SGTL5000_VF610) += +snd-soc-fsl-sgtl5000-vf610.o diff --git a/sound/soc/fsl/fsl-sgtl5000-vf610.c b/sound/soc/fsl/fsl-sgtl5000-vf610.c new file mode 100644 index 000..f535b42 --- /dev/null +++ b/sound/soc/fsl/fsl-sgtl5000-vf610.c @@ -0,0 +1,208 @@ +/* + * Freeacale ALSA SoC Audio using SGT1500 as codec. + * + * Copyright 2012-2013 Freescale Semiconductor, Inc. + * + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 or later at the following locations: + * + */ + +#include linux/module.h +#include linux/of.h +#include linux/of_platform.h +#include linux/i2c.h +#include linux/clk.h + +#include ../codecs/sgtl5000.h +#include fsl-sai.h + +static unsigned int sysclk_rate; + +static int fsl_sgtl5000_dai_init(struct snd_soc_pcm_runtime *rtd) Naming issue here again. At least from my point of view, if you actually merged imx-sgtl5000 with vf610-sgtl5000 and made it also compatible to other freescale SoCs, you could then fairly call it fsl_sgtl5000_. Well, I might be a little picky here because it's a static function and won't conflict others. Just the name here doesn't look so explicit to me. Please reconsider about this whole file's naming. Yes, I still not very sure the names of the functions and files, from your replies, I have got many information about the rules and others, I'll think it over and do some research, Please see the next version. Best regards, Xiubo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/7] IBM Akebono: Add support to AHCI platform driver
The new IBM Akebono board has an AHCI compliant SATA controller. This
patch adds a compatible property for the new board to the AHCI
platform driver.
Signed-off-by: Alistair Popple alist...@popple.id.au
Cc: linux-...@vger.kernel.org
---
drivers/ata/ahci_platform.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 7d3b853..b20b130 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -328,6 +328,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_suspend,
ahci_resume);
static const struct of_device_id ahci_of_match[] = {
{ .compatible = snps,spear-ahci, },
{ .compatible = snps,exynos5440-ahci, },
+ { .compatible = ibm,akebono-ahci, },
{},
};
MODULE_DEVICE_TABLE(of, ahci_of_match);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/7] IBM Akebono: Add a SDHCI platform driver
This patch adds a SDHCI platform driver for the new IBM Akebono board.
Signed-off-by: Alistair Popple alist...@popple.id.au
Cc: Chris Ball c...@laptop.org
Cc: linux-...@vger.kernel.org
---
drivers/mmc/host/Kconfig| 12 +++
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-of-akebono.c | 60 +++
3 files changed, 73 insertions(+)
create mode 100644 drivers/mmc/host/sdhci-of-akebono.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 7fc5099..d7a1414 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -130,6 +130,18 @@ config MMC_SDHCI_OF_HLWD
If unsure, say N.
+config MMC_SDHCI_OF_AKEBONO
+ tristate SDHCI OF support for the IBM Akebono board
+ depends on MMC_SDHCI_PLTFM
+ depends on PPC_OF
+ help
+ This selects the Secure Digital Host Controller Interface (SDHCI)
+ found on the Akebono 476FP SoC.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
+
config MMC_SDHCI_CNS3XXX
tristate SDHCI support on the Cavium Networks CNS3xxx SoC
depends on ARCH_CNS3XXX
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index c41d0c3..ea7e757 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_MMC_SDHCI_DOVE) += sdhci-dove.o
obj-$(CONFIG_MMC_SDHCI_TEGRA) += sdhci-tegra.o
obj-$(CONFIG_MMC_SDHCI_OF_ESDHC) += sdhci-of-esdhc.o
obj-$(CONFIG_MMC_SDHCI_OF_HLWD)+= sdhci-of-hlwd.o
+obj-$(CONFIG_MMC_SDHCI_OF_AKEBONO) += sdhci-of-akebono.o
obj-$(CONFIG_MMC_SDHCI_BCM_KONA) += sdhci-bcm-kona.o
obj-$(CONFIG_MMC_SDHCI_BCM2835)+= sdhci-bcm2835.o
diff --git a/drivers/mmc/host/sdhci-of-akebono.c
b/drivers/mmc/host/sdhci-of-akebono.c
new file mode 100644
index 000..20041c1
--- /dev/null
+++ b/drivers/mmc/host/sdhci-of-akebono.c
@@ -0,0 +1,60 @@
+/*
+ * drivers/mmc/host/sdhci-of-akebono.c
+ *
+ * Copyright © 2013 Alistair Popple alist...@popple.id.au IBM Corporation
+ *
+ * Based on sdhci-of-hlwd.c
+ *
+ * Copyright (C) 2009 The GameCube Linux Team
+ * Copyright (C) 2009 Albert Herranz
+ *
+ * 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.
+ */
+
+#include linux/delay.h
+#include linux/module.h
+#include linux/mmc/host.h
+#include sdhci-pltfm.h
+
+static const struct sdhci_ops sdhci_akebono_ops = {
+};
+
+static const struct sdhci_pltfm_data sdhci_akebono_pdata = {
+ .ops = sdhci_akebono_ops,
+};
+
+static int sdhci_akebono_probe(struct platform_device *pdev)
+{
+ return sdhci_pltfm_register(pdev, sdhci_akebono_pdata, 0);
+}
+
+static int sdhci_akebono_remove(struct platform_device *pdev)
+{
+ return sdhci_pltfm_unregister(pdev);
+}
+
+static const struct of_device_id sdhci_akebono_of_match[] = {
+ { .compatible = ibm,akebono-sdhci },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sdhci_akebono_of_match);
+
+static struct platform_driver sdhci_akebono_driver = {
+ .driver = {
+ .name = sdhci-akebono,
+ .owner = THIS_MODULE,
+ .of_match_table = sdhci_akebono_of_match,
+ .pm = SDHCI_PLTFM_PMOPS,
+ },
+ .probe = sdhci_akebono_probe,
+ .remove = sdhci_akebono_remove,
+};
+
+module_platform_driver(sdhci_akebono_driver);
+
+MODULE_DESCRIPTION(Akebono SDHCI OF driver);
+MODULE_AUTHOR(Alistair Popple);
+MODULE_LICENSE(GPL v2);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
The IBM Akebono board uses a different ethernet PHY that has wake on lan (WOL) support with the IBM emac. This patch adds suppot to the IBM emac driver for this new PHY. At this stage the wake on lan functionality has not been implemented. Signed-off-by: Alistair Popple alist...@popple.id.au Cc: David S. Miller da...@davemloft.net Cc: net...@vger.kernel.org --- .../devicetree/bindings/powerpc/4xx/emac.txt |9 + drivers/net/ethernet/ibm/emac/Kconfig |4 + drivers/net/ethernet/ibm/emac/Makefile |1 + drivers/net/ethernet/ibm/emac/core.c | 50 +++- drivers/net/ethernet/ibm/emac/core.h | 12 + drivers/net/ethernet/ibm/emac/rgmii_wol.c | 262 drivers/net/ethernet/ibm/emac/rgmii_wol.h | 62 + 7 files changed, 394 insertions(+), 6 deletions(-) create mode 100644 drivers/net/ethernet/ibm/emac/rgmii_wol.c create mode 100644 drivers/net/ethernet/ibm/emac/rgmii_wol.h diff --git a/Documentation/devicetree/bindings/powerpc/4xx/emac.txt b/Documentation/devicetree/bindings/powerpc/4xx/emac.txt index 712baf6..9928d9d 100644 --- a/Documentation/devicetree/bindings/powerpc/4xx/emac.txt +++ b/Documentation/devicetree/bindings/powerpc/4xx/emac.txt @@ -61,6 +61,8 @@ Fox Axon: present, whatever value is appropriate for each EMAC, that is the content of the current (bogus) phy-port property. +- rgmii-wol-device : 1 cell, required iff conntect to a RGMII in the WKUP + power domain. phandle of the RGMII-WOL device node. Optional properties: - phy-address : 1 cell, optional, MDIO address of the PHY. If absent, @@ -146,3 +148,10 @@ available. For Axon: 0x012a + iv) RGMII-WOL node + +Required properties: +- compatible : compatible list, containing 2 entries, first is + ibm,rgmii-wol-CHIP where CHIP is the host ASIC (like + EMAC) and the second is ibm,rgmii-wol. +- reg: registers mapping diff --git a/drivers/net/ethernet/ibm/emac/Kconfig b/drivers/net/ethernet/ibm/emac/Kconfig index 3f44a30..7425c27 100644 --- a/drivers/net/ethernet/ibm/emac/Kconfig +++ b/drivers/net/ethernet/ibm/emac/Kconfig @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII bool default n +config IBM_EMAC_RGMII_WOL + bool + default n + config IBM_EMAC_TAH bool default n diff --git a/drivers/net/ethernet/ibm/emac/Makefile b/drivers/net/ethernet/ibm/emac/Makefile index eba2183..8843803 100644 --- a/drivers/net/ethernet/ibm/emac/Makefile +++ b/drivers/net/ethernet/ibm/emac/Makefile @@ -7,5 +7,6 @@ obj-$(CONFIG_IBM_EMAC) += ibm_emac.o ibm_emac-y := mal.o core.o phy.o ibm_emac-$(CONFIG_IBM_EMAC_ZMII) += zmii.o ibm_emac-$(CONFIG_IBM_EMAC_RGMII) += rgmii.o +ibm_emac-$(CONFIG_IBM_EMAC_RGMII_WOL) += rgmii_wol.o ibm_emac-$(CONFIG_IBM_EMAC_TAH) += tah.o ibm_emac-$(CONFIG_IBM_EMAC_DEBUG) += debug.o diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c index 6b5c722..fc1a775 100644 --- a/drivers/net/ethernet/ibm/emac/core.c +++ b/drivers/net/ethernet/ibm/emac/core.c @@ -630,6 +630,8 @@ static int emac_configure(struct emac_instance *dev) if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII)) rgmii_set_speed(dev-rgmii_dev, dev-rgmii_port, dev-phy.speed); + if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII_WOL)) + rgmii_wol_set_speed(dev-rgmii_wol_dev, dev-phy.speed); if (emac_has_feature(dev, EMAC_FTR_HAS_ZMII)) zmii_set_speed(dev-zmii_dev, dev-zmii_port, dev-phy.speed); @@ -797,6 +799,8 @@ static int __emac_mdio_read(struct emac_instance *dev, u8 id, u8 reg) zmii_get_mdio(dev-zmii_dev, dev-zmii_port); if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII)) rgmii_get_mdio(dev-rgmii_dev, dev-rgmii_port); + if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII_WOL)) + rgmii_wol_get_mdio(dev-rgmii_wol_dev); /* Wait for management interface to become idle */ n = 20; @@ -844,6 +848,8 @@ static int __emac_mdio_read(struct emac_instance *dev, u8 id, u8 reg) DBG2(dev, mdio_read - %04x NL, r); err = 0; bail: + if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII_WOL)) + rgmii_wol_put_mdio(dev-rgmii_wol_dev); if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII)) rgmii_put_mdio(dev-rgmii_dev, dev-rgmii_port); if (emac_has_feature(dev, EMAC_FTR_HAS_ZMII)) @@ -869,6 +875,8 @@ static void __emac_mdio_write(struct emac_instance *dev, u8 id, u8 reg, zmii_get_mdio(dev-zmii_dev, dev-zmii_port); if (emac_has_feature(dev, EMAC_FTR_HAS_RGMII)) rgmii_get_mdio(dev-rgmii_dev,
[PATCH 4/7] IBM Akebono: Add support to the OHCI platform driver for Akebono
The IBM Akebono board has a OHCI compliant USB host interface. This
patch adds support for it to the OHCI platform driver.
As we use device tree to pass platform specific data instead of
platform data we remove the check for platform data and instead
provide reasonable defaults if no platform data is present. This is
similar to what is currently done in ehci-platform.c.
Signed-off-by: Alistair Popple alist...@popple.id.au
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-...@vger.kernel.org
---
drivers/usb/host/ohci-platform.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index a4c6410..4331454 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -23,6 +23,8 @@
#include linux/usb/ohci_pdriver.h
#include linux/usb.h
#include linux/usb/hcd.h
+#include linux/slab.h
+#include linux/of.h
#include ohci.h
@@ -55,6 +57,8 @@ static const struct ohci_driver_overrides platform_overrides
__initconst = {
.reset =ohci_platform_reset,
};
+static struct usb_ohci_pdata ohci_platform_defaults;
+
static int ohci_platform_probe(struct platform_device *dev)
{
struct usb_hcd *hcd;
@@ -63,14 +67,14 @@ static int ohci_platform_probe(struct platform_device *dev)
int irq;
int err = -ENOMEM;
- if (!pdata) {
- WARN_ON(1);
- return -ENODEV;
- }
-
if (usb_disabled())
return -ENODEV;
+ /* Platforms using DT don't always provide platform data.
+* This should provide reasonable defaults. */
+ if (!pdata)
+ dev-dev.platform_data = pdata = ohci_platform_defaults;
+
irq = platform_get_irq(dev, 0);
if (irq 0) {
dev_err(dev-dev, no irq provided);
@@ -171,6 +175,11 @@ static int ohci_platform_resume(struct device *dev)
#define ohci_platform_resume NULL
#endif /* CONFIG_PM */
+static const struct of_device_id ohci_of_match[] = {
+ { .compatible = ibm,akebono-ohci, },
+ {},
+};
+
static const struct platform_device_id ohci_platform_table[] = {
{ ohci-platform, 0 },
{ }
@@ -191,6 +200,7 @@ static struct platform_driver ohci_platform_driver = {
.owner = THIS_MODULE,
.name = ohci-platform,
.pm = ohci_platform_pm_ops,
+ .of_match_table = ohci_of_match,
}
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/7] IBM Akebono: Add support to the EHCI platform driver for Akebono
The IBM Akebono board has an EHCI compliant USB host interface. This
patch adds support for it to the EHCI platform driver.
Signed-off-by: Alistair Popple alist...@popple.id.au
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-...@vger.kernel.org
---
drivers/usb/host/ehci-platform.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index f6b790c..0a67616 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -203,9 +203,10 @@ static int ehci_platform_resume(struct device *dev)
#define ehci_platform_resume NULL
#endif /* CONFIG_PM */
-static const struct of_device_id vt8500_ehci_ids[] = {
+static const struct of_device_id ehci_platform_ids[] = {
{ .compatible = via,vt8500-ehci, },
{ .compatible = wm,prizm-ehci, },
+ { .compatible = ibm,akebono-ehci, },
{}
};
@@ -229,7 +230,7 @@ static struct platform_driver ehci_platform_driver = {
.owner = THIS_MODULE,
.name = ehci-platform,
.pm = ehci_platform_pm_ops,
- .of_match_table = vt8500_ehci_ids,
+ .of_match_table = ehci_platform_ids,
}
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/7] IBM Akebono: Add the Akebono platform
This patch adds support for the IBM Akebono board. Signed-off-by: Alistair Popple alist...@popple.id.au --- .../devicetree/bindings/powerpc/4xx/akebono.txt| 76 arch/powerpc/boot/Makefile |3 + arch/powerpc/boot/dcr.h|2 + arch/powerpc/boot/dts/akebono.dts | 385 arch/powerpc/boot/treeboot-akebono.c | 179 + arch/powerpc/boot/wrapper |3 + arch/powerpc/configs/44x/akebono_defconfig | 148 arch/powerpc/platforms/44x/Kconfig | 28 ++ arch/powerpc/platforms/44x/Makefile|1 + arch/powerpc/platforms/44x/ppc476fpe.c | 112 -- 10 files changed, 914 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/powerpc/4xx/akebono.txt create mode 100644 arch/powerpc/boot/dts/akebono.dts create mode 100644 arch/powerpc/boot/treeboot-akebono.c create mode 100644 arch/powerpc/configs/44x/akebono_defconfig diff --git a/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt b/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt new file mode 100644 index 000..cb5272d --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt @@ -0,0 +1,76 @@ + +IBM Akebono board device tree += + +The IBM Akebono board is a development board for a 476FPE bases SoC. + +0) The root node + + Required properties: + + - model : ibm,akebono. + - compatible : ibm,akebono , ibm,476fpe. + +1.a) The Open Host Controller Interface (OHCI) nodes + + Represent the USB 1.x Open Host Controller Interfaces. + + Required properties: + + - compatible : should be ibm,akebono-ohci. + - reg : should contain the OHCI registers location and length. + - interrupt-parent : a phandle for the interrupt controller. + - interrupts : should contain the OHCI interrupt. + +1.b) The Open Host Controller Interface (EHCI) nodes + + Represent the USB 2.0 Enhanced Host Controller Interface. + + Required properties: + + - compatible : should be ibm,akebono-ehci. + - reg : should contain the EHCI registers location and length. + - interrupt-parent : a phandle for the interrupt controller. + - interrupts : should contain the EHCI interrupt. + +1.c) The Secure Digital Host Controller Interface (SDHCI) node + + Represent the Secure Digital Host Controller Interfaces. + + Required properties: + + - compatible : should be ibm,akebono-sdhci,sdhci. + - reg : should contain the SDHCI registers location and length. + - interrupt-parent : a phandle for the interrupt controller. + - interrupts : should contain the SDHCI interrupt. + +1.d) The Advanced Host Controller Interface (AHCI) SATA node + + Represents the advanced host controller SATA interface. + + Required properties: + + - compatible : should be ibm,akebono-ahci. + - reg : should contain the AHCI registers location and length. + - interrupt-parent : a phandle for the interrupt controller. + - interrupts : should contain the AHCI interrupt. + +1.e) The FPGA node + + The Akebono board stores some board information such as the revision + number in an FPGA which is represented by this node. + + Required properties: + + - compatible : should be ibm,akebono-fpga. + - reg : should contain the FPGA registers location and length. + +1.f) The AVR node + + The Akebono board has an Atmel AVR microprocessor attached to the I2C + bus as a power controller for the board. + + Required properties: + + - compatible : should be ibm,akebono-avr. + - reg : should contain the I2C bus address for the AVR. diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 15ca225..645ff21 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -46,6 +46,7 @@ $(obj)/cuboot-acadia.o: BOOTCFLAGS += -mcpu=405 $(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405 $(obj)/treeboot-iss4xx.o: BOOTCFLAGS += -mcpu=405 $(obj)/treeboot-currituck.o: BOOTCFLAGS += -mcpu=405 +$(obj)/treeboot-akebono.o: BOOTCFLAGS += -mcpu=405 $(obj)/virtex405-head.o: BOOTAFLAGS += -mcpu=405 @@ -85,6 +86,7 @@ src-plat-$(CONFIG_44x) += treeboot-ebony.c cuboot-ebony.c treeboot-bamboo.c \ cuboot-taishan.c cuboot-katmai.c \ cuboot-warp.c cuboot-yosemite.c \ treeboot-iss4xx.c treeboot-currituck.c \ + treeboot-akebono.c \ simpleboot.c fixed-head.S virtex.c src-plat-$(CONFIG_8xx) += cuboot-8xx.c fixed-head.S ep88xc.c redboot-8xx.c src-plat-$(CONFIG_PPC_MPC52xx) += cuboot-52xx.c @@ -235,6 +237,7 @@ image-$(CONFIG_YOSEMITE)+= cuImage.yosemite image-$(CONFIG_ISS4xx) += treeImage.iss4xx \ treeImage.iss4xx-mpic image-$(CONFIG_CURRITUCK)
[PATCH 6/7] IBM Currituck: Clean up board specific code before adding Akebono code
The IBM Akebono code uses the same initialisation functions as the
earlier Currituck board. Rather than create a copy of this code for
Akebono we will instead integrate support for it into the same file as
the Currituck code.
This patch simply renames the file.
Signed-off-by: Alistair Popple alist...@popple.id.au
---
arch/powerpc/platforms/44x/Makefile|2 +-
arch/powerpc/platforms/44x/currituck.c | 233
arch/powerpc/platforms/44x/ppc476fpe.c | 233
3 files changed, 234 insertions(+), 234 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/currituck.c
create mode 100644 arch/powerpc/platforms/44x/ppc476fpe.c
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index d03833a..c4fe9cd 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -10,4 +10,4 @@ obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
obj-$(CONFIG_XILINX_ML510) += virtex_ml510.o
obj-$(CONFIG_ISS4xx) += iss4xx.o
obj-$(CONFIG_CANYONLANDS)+= canyonlands.o
-obj-$(CONFIG_CURRITUCK)+= currituck.o
+obj-$(CONFIG_CURRITUCK)+= ppc476fpe.o
diff --git a/arch/powerpc/platforms/44x/currituck.c
b/arch/powerpc/platforms/44x/currituck.c
deleted file mode 100644
index 7f1b71a..000
--- a/arch/powerpc/platforms/44x/currituck.c
+++ /dev/null
@@ -1,233 +0,0 @@
-/*
- * Currituck board specific routines
- *
- * Copyright © 2011 Tony Breeds IBM Corporation
- *
- * Based on earlier code:
- *Matt Porter mpor...@kernel.crashing.org
- *Copyright 2002-2005 MontaVista Software Inc.
- *
- *Eugene Surovegin eugene.surove...@zultys.com or e...@ebshome.net
- *Copyright (c) 2003-2005 Zultys Technologies
- *
- *Rewritten and ported to the merged powerpc tree:
- *Copyright 2007 David Gibson d...@au1.ibm.com, IBM Corporation.
- *Copyright © 2011 David Kliekamp IBM Corporation
- *
- * 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.
- */
-
-#include linux/init.h
-#include linux/of.h
-#include linux/of_platform.h
-#include linux/rtc.h
-
-#include asm/machdep.h
-#include asm/prom.h
-#include asm/udbg.h
-#include asm/time.h
-#include asm/uic.h
-#include asm/ppc4xx.h
-#include asm/mpic.h
-#include asm/mmu.h
-
-#include linux/pci.h
-
-static __initdata struct of_device_id ppc47x_of_bus[] = {
- { .compatible = ibm,plb4, },
- { .compatible = ibm,plb6, },
- { .compatible = ibm,opb, },
- { .compatible = ibm,ebc, },
- {},
-};
-
-/* The EEPROM is missing and the default values are bogus. This forces USB in
- * to EHCI mode */
-static void quirk_ppc_currituck_usb_fixup(struct pci_dev *dev)
-{
- if (of_machine_is_compatible(ibm,currituck)) {
- pci_write_config_dword(dev, 0xe0, 0x0114231f);
- pci_write_config_dword(dev, 0xe4, 0x6c40);
- }
-}
-DECLARE_PCI_FIXUP_HEADER(0x1033, 0x0035, quirk_ppc_currituck_usb_fixup);
-
-static int __init ppc47x_device_probe(void)
-{
- of_platform_bus_probe(NULL, ppc47x_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(ppc47x, ppc47x_device_probe);
-
-/* We can have either UICs or MPICs */
-static void __init ppc47x_init_irq(void)
-{
- struct device_node *np;
-
- /* Find top level interrupt controller */
- for_each_node_with_property(np, interrupt-controller) {
- if (of_get_property(np, interrupts, NULL) == NULL)
- break;
- }
- if (np == NULL)
- panic(Can't find top level interrupt controller);
-
- /* Check type and do appropriate initialization */
- if (of_device_is_compatible(np, chrp,open-pic)) {
- /* The MPIC driver will get everything it needs from the
-* device-tree, just pass 0 to all arguments
-*/
- struct mpic *mpic =
- mpic_alloc(np, 0, MPIC_NO_RESET, 0, 0, MPIC );
- BUG_ON(mpic == NULL);
- mpic_init(mpic);
- ppc_md.get_irq = mpic_get_irq;
- } else
- panic(Unrecognized top level interrupt controller);
-}
-
-#ifdef CONFIG_SMP
-static void smp_ppc47x_setup_cpu(int cpu)
-{
- mpic_setup_this_cpu();
-}
-
-static int smp_ppc47x_kick_cpu(int cpu)
-{
- struct device_node *cpunode = of_get_cpu_node(cpu, NULL);
- const u64 *spin_table_addr_prop;
- u32 *spin_table;
- extern void start_secondary_47x(void);
-
- BUG_ON(cpunode == NULL);
-
- /* Assume spin table. We could test for the enable-method in
-* the device-tree but currently there's little point as it's
-* our only supported method
-*/
- spin_table_addr_prop =
-
[PATCH] powerpc: Fix fatal SLB miss when restoring PPR
When restoring the PPR value, we incorrectly access the thread structure at a time where MSR:RI is clear, which means we cannot recover from nested faults. However the thread structure isn't covered by the bolted SLB entries and thus accessing can fault. This fixes it by splitting the code so that the PPR value is loaded into a GPR before MSR:RI is cleared. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h index 8deaaad..3c1acc3 100644 --- a/arch/powerpc/include/asm/ppc_asm.h +++ b/arch/powerpc/include/asm/ppc_asm.h @@ -406,13 +406,6 @@ BEGIN_FTR_SECTION_NESTED(945) \ std ra,TASKTHREADPPR(rb); \ END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,945) -#define RESTORE_PPR(ra, rb)\ -BEGIN_FTR_SECTION_NESTED(946) \ - ld ra,PACACURRENT(r13);\ - ld rb,TASKTHREADPPR(ra); \ - mtspr SPRN_PPR,rb;/* Restore PPR */ \ -END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,946) - #endif /* diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S index 12679cd..bbfb029 100644 --- a/arch/powerpc/kernel/entry_64.S +++ b/arch/powerpc/kernel/entry_64.S @@ -818,6 +818,12 @@ fast_exception_return: andi. r0,r3,MSR_RI beq-unrecov_restore + /* Load PPR from thread struct before we clear MSR:RI */ +BEGIN_FTR_SECTION + ld r2,PACACURRENT(r13) + ld r2,TASKTHREADPPR(r2) +END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR) + /* * Clear RI before restoring r13. If we are returning to * userspace and we take an exception after restoring r13, @@ -838,8 +844,10 @@ fast_exception_return: */ andi. r0,r3,MSR_PR beq 1f +BEGIN_FTR_SECTION + mtspr SPRN_PPR,r2 /* Restore PPR */ +END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR) ACCOUNT_CPU_USER_EXIT(r2, r4) - RESTORE_PPR(r2, r4) REST_GPR(13, r1) 1: mtspr SPRN_SRR1,r3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCHv2 6/8] ASoC: fsl: add SGTL5000 based audio machine driver.
sound/soc/fsl/fsl-sgtl5000-vf610.c | 208 + I just doubt if this file naming is appropriate. Even if we might not have rigor rule for the file names, according to existing ones, they are all in a same pattern: [SoC name]-[codec name].c imx-sgtl5000.c for example I think it would make user less confused about what this file exactly is if this machine driver also follow the pattern: vf610-sgtl5000.c @Shawn What do you think about the file name? Yeah, it would be better to name the file following the existing the pattern. Please see the next version. Best Regards, Xiubo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] powerpc/kvm: fix rare but potential deadlock scene
Since kvmppc_hv_find_lock_hpte() is called from both virtmode and realmode, so it can trigger the deadlock. Suppose the following scene: Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of vcpus. If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be caught in realmode for a long time. What makes things even worse if the following happens, On cpuM, bitlockX is hold, on cpuN, Y is hold. vcpu_B_2 try to lock Y on cpuM in realmode vcpu_A_2 try to lock X on cpuN in realmode Oops! deadlock happens Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com --- arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c index 043eec8..28160ac 100644 --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c @@ -474,8 +474,10 @@ static int kvmppc_mmu_book3s_64_hv_xlate(struct kvm_vcpu *vcpu, gva_t eaddr, } /* Find the HPTE in the hash table */ + preempt_disable(); index = kvmppc_hv_find_lock_hpte(kvm, eaddr, slb_v, HPTE_V_VALID | HPTE_V_ABSENT); + preempt_enable(); if (index 0) return -ENOENT; hptep = (unsigned long *)(kvm-arch.hpt_virt + (index 4)); -- 1.8.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] powerpc/kvm: simplify the entering logic for secondary thread
After the primary vcpu changes vcore_state to VCORE_RUNNING, there is
very little chance to schedule to secondary vcpu. So if we change the
code sequence around set vcore_state to VCORE_RUNNING and disable
preemption, we lost little. But we simplify the entering logi, based on
the fact that if primary vcpu runs, the secondary vcpu can not be scheduled.
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_hv.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 62a2b5a..38b1fc0 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1222,8 +1222,8 @@ static void kvmppc_run_core(struct kvmppc_vcore *vc)
kvmppc_create_dtl_entry(vcpu, vc);
}
- vc-vcore_state = VCORE_RUNNING;
preempt_disable();
+ vc-vcore_state = VCORE_RUNNING;
spin_unlock(vc-lock);
kvm_guest_enter();
@@ -1351,12 +1351,7 @@ static int kvmppc_run_vcpu(struct kvm_run *kvm_run,
struct kvm_vcpu *vcpu)
* this thread straight away and have it join in.
*/
if (!signal_pending(current)) {
- if (vc-vcore_state == VCORE_RUNNING
- VCORE_EXIT_COUNT(vc) == 0) {
- vcpu-arch.ptid = vc-n_runnable - 1;
- kvmppc_create_dtl_entry(vcpu, vc);
- kvmppc_start_thread(vcpu);
- } else if (vc-vcore_state == VCORE_SLEEPING) {
+ if (vc-vcore_state == VCORE_SLEEPING) {
wake_up(vc-wq);
}
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] powerpc/kvm: remove redundant assignment
Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_64_mmu_hv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 28160ac..7682837 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -731,7 +731,6 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, struct
kvm_vcpu *vcpu,
lock_rmap(rmap);
/* Check if we might have been invalidated; let the guest retry if so */
- ret = RESUME_GUEST;
if (mmu_notifier_retry(vcpu-kvm, mmu_seq)) {
unlock_rmap(rmap);
goto out_unlock;
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
