From: David Hildenbrand [mailto:d...@linux.vnet.ibm.com]
From: David Hildenbrand
...
Although it might not be optimal, but keeping a separate counter for
pagefault_disable() as part of the preemption counter seems to be the only
doable thing right now. I am not sure if a completely
From: Mel Gorman
Convert existing users of pte_numa and friends to the new helper. Note
that the kernel is broken after this patch is applied until the other
page table modifiers are also altered. This patch layout is to make
review easier.
Doesn't that break bisection?
David
From: Michael Ellerman
Although we are now selecting NO_BOOTMEM, we still have some traces of
bootmem lying around. That is because even with NO_BOOTMEM there is
still a shim that converts bootmem calls into memblock calls, but
ultimately we want to remove all traces of bootmem.
Most of the
From: leroy christophe
Many drivers use in_be16(), in_be32(), out_be16(), out_be32(), etc
to access to registrers in IO mapped memory.
What is the real purpose of those functions, and are they really needed ?
ioremap() maps the related areas as GUARDED, which means that accesses
From: Chuck Ebbert
David Laight david.lai...@aculab.com wrote:
From: Aaron Tomlin
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region
From: Aaron Tomlin
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region is examined at a later stage, the outcome is undefined
and often results in a
From: Paul E. McKenney
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees:
+
+ (*) These guarantees do not apply to
From: Peter Hurley
[ +cc linux-arm ]
Hi David,
On 09/05/2014 04:30 AM, David Laight wrote:
I've seen gcc generate 32bit accesses for 16bit structure members on arm.
It does this because of the more limited range of the offsets for the 16bit
access.
OTOH I don't know if it ever did
From: Benjamin Herrenschmidt
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat regarding what a compiler might do with adjacent fields in a
structure.
The tty subsystem defines a large aggregate
From: Shilpa Bhat
Hi Viresh,
On Fri, 2014-08-29 at 05:33 +0530, Viresh Kumar wrote:
On 28 August 2014 19:36, Shilpasri G Bhat
shilpa.b...@linux.vnet.ibm.com wrote:
Changes v1-v2:
Invoke .target() driver callback to set the cpus to nominal frequency
in reboot notifier, instead of
From: Gavin Shan
There are multiple global EEH flags. Almost each flag has its own
accessor, which doesn't make sense. The patch refactors EEH flag
accessors so that they look unified:
eeh_add_flag(): Add EEH flag
eeh_set_flag() ??
eeh_clear_flag(): Clear EEH flag
eeh_has_flag():
From: Gavin Shan
The patch prints 4 PCIE or AER config registers each line, which
is part of the EEH log so that it looks a bit more compact.
...
- for (i=0; i=8; i++) {
+ for (i=0, j=0; i=8; i++) {
eeh_ops-read_config(dn, cap+4*i, 4, cfg);
From: Vincent Bernat
Use linux/ctype.h instead of defining custom versions of
isxdigit/isspace/isalnum.
...
-#define isspace(c) (c == ' ' || c == '\t' || c == 10 || c == 13 || c == 0)
That is different from the version in linux/ctype.h
Especially for 'c == 0', but probably also vertical tab
From: Bjorn Helgaas
...
Even if you do that, you ought to write valid interrupt information
into the 4th slot (maybe replicating one of the earlier interrupts).
Then, if the device does raise the 'unexpected' interrupt you don't
get a write to a random kernel location.
I might be
From: Alexander Gordeev
...
Even if you do that, you ought to write valid interrupt information
into the 4th slot (maybe replicating one of the earlier interrupts).
Then, if the device does raise the 'unexpected' interrupt you don't
get a write to a random kernel location.
I might be
From: Bjorn Helgaas
On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote:
There are PCI devices that require a particular value written
to the Multiple Message Enable (MME) register while aligned on
power of 2 boundary value of actually used MSI vectors 'nvec'
is a lesser of
From: Zhao Qiang
ret is unused when CONFIG_FSL_SOC defined,
so include it with #ifndef CONFIG_FSL_SOC.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
drivers/spi/spi-fsl-lib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-fsl-lib.c
From: Wei Yang
On Wed, Jun 25, 2014 at 02:12:34PM +1000, Alexey Kardashevskiy wrote:
On 06/25/2014 11:12 AM, Wei Yang wrote:
On Tue, Jun 24, 2014 at 08:06:32PM +1000, Alexey Kardashevskiy wrote:
On 06/10/2014 11:56 AM, Wei Yang wrote:
Current iommu_table of a PE is a static field. This
From: Guenter Roeck
On 06/25/2014 07:49 AM, Uwe Kleine-Knig wrote:
Hello Guenter,
On Wed, Jun 25, 2014 at 07:27:47AM -0700, Guenter Roeck wrote:
Maybe the author's intention was:
static inline int cpu_corepower_flags(void) __attribute__((const));
?
This specifies that the
From: Uwe Kleine-König
Hello,
On Wed, Jun 25, 2014 at 03:40:28PM +, David Laight wrote:
From: Guenter Roeck
Actually turns out one can use __attribute_const__, and it is
static inline int __attribute_const__ cpu_corepower_flags(void)
which turns out to be widely used
From: Alexey Kardashevskiy
...
So IMHO we should either create new, generic iowrite helpers that don't
do any endian swapping at all or do iowrite32(cpu_to_le32(val)) calls.
I'm one of those people for whom iowrite32(le32_to_cpu(val)) makes sense
I do not understand why @val is
From: Peter Hurley
...
I don't understand the second half of the changelog, it doesn't seem
to fit here: there deadlock that we are trying to avoid here happens
when the *same* tty needs the lock to complete the function that
sends the pending data. I don't think we do still do that any
From: Anton Blanchard
...
diff --git a/arch/powerpc/boot/install.sh b/arch/powerpc/boot/install.sh
index b6a256b..e096e5a 100644
--- a/arch/powerpc/boot/install.sh
+++ b/arch/powerpc/boot/install.sh
@@ -23,8 +23,8 @@ set -e
# User may have a custom install script
-if [ -x
From: Joe Perches
On Wed, 2014-05-28 at 17:11 -0500, Cody P Schafer wrote:
On Wed, May 28, 2014 at 5:05 PM, Cody P Schafer d...@codyps.com wrote:
On Wed, May 28, 2014 at 3:45 AM, David Laight david.lai...@aculab.com
wrote:
From: Cody P Schafer
Rather manually specifying the size
From: Cody P Schafer
Rather manually specifying the size of the integer to be converted, key
off of the type size. Reduces duplicate size info and the occurance of
certain types of bugs (using the wrong sized conversion).
...
+#define be_to_cpu(v) \
+ __builtin_choose_expr(sizeof(v) ==
From: Alexander Graf
...
+ page = pfn_to_page(pfn);
+ eaddr = (unsigned long)kmap_atomic(page);
+ eaddr |= addr ~PAGE_MASK;
+ *instr = *(u32 *)eaddr;
+ kunmap_atomic((u32 *)eaddr);
I think I'd rather write this as
*instr = *(u32 *)(eaddr | (addr ~PAGE));
From: Li Zhong
On Fri, 2014-04-25 at 22:18 +1000, Anton Blanchard wrote:
Hi,
When trying offline cpus, I noticed following Oops in
rtas_stop_self(), and it seems caused by commit 41dd03a9. The Oops
disappears after reverting this commit.
After reading the code, I guess it might
From: Yijing Wang
This patchset rename the current pci_is_bridge() to pci_has_subordinate(),
and introduce a new pci_is_bridge() which determine pci bridge by check
dev-hdr_type. The new one is more accurate. PCIe Spec define the pci
device is a bridge by the dev-hdr_type = 0x01 || 0x02.
That
From: hongbo.zh...@freescale.com
Methods of accessing DMA contorller registers are inconsistent, some registers
^^
are accessed by DMA_IN/OUT directly, while others are accessed by functions
get/set_* which are wrappers of DMA_IN/OUT, and even for the BCR
From: Mark Brown
On Wed, Mar 26, 2014 at 11:59:53AM +, David Laight wrote:
From: Nicolin Chen
+ regmap_read(sai-regmap, FSL_SAI_TCSR, xcsr);
+ regmap_write(sai-regmap, FSL_SAI_TCSR, xcsr);
Assuming these are 'write to clear' bits, you might want
to make the write (above
From: Cody P Schafer
On 03/25/2014 03:43 AM, Anton Blanchard wrote:
Hi Cody,
hv-24x7: could not obtain capabilities, error 0x
fffe, not enabling
hv-gpci: could not obtain capabilities, error 0x
fffe, not enabling
+ pr_info(could not obtain
From: Nicolin Chen
It's quite cricial to clear error flags because SAI might hang if getting
FIFO underrun during playback (I haven't confirmed the same issue on Rx
overflow though).
So this patch enables those irq and adds isr() to clear the flags so as to
keep playback entirely safe.
From: Scott Wood [mailto:scottw...@freescale.com]
On Thu, 2014-03-20 at 11:59 +, David Laight wrote:
I tried to work out what the 'twi, isync' instructions were for (in
in_le32()).
The best I could come up with was to ensure a synchronous bus-fault.
But bus faults are probably only
From: Viresh Kumar
On 21 March 2014 16:34, Gautham R Shenoy e...@linux.vnet.ibm.com wrote:
Heh! Well, that wasn't the reason why this was sent out as a separate
patch, but never mind. Though I don't understand why it would be
difficult to review the patch though.
Because the initial
From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
On 21 March 2014 17:31, David Laight david.lai...@aculab.com wrote:
*(int *)ret_freq = freq;
Because it is very likely to be wrong.
In general casts of pointers to integer types are dangerous.
Where are we converting pointers
From: Kevin Hao
Sent: 20 March 2014 11:48
To: Scott Wood
Cc: linuxppc-dev@lists.ozlabs.org; Chenhui Zhao; jason@freescale.com;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
On Tue, Mar 18, 2014 at 06:18:54PM -0500, Scott Wood
From: j...@joshtriplett.org
On Fri, Mar 07, 2014 at 01:02:44PM -0800, Joe Perches wrote:
On Fri, 2014-03-07 at 15:41 -0500, David Miller wrote:
From: Alistair Popple alist...@popple.id.au
Date: Thu, 6 Mar 2014 14:52:25 +1100
+ out_be32(dev-reg, in_be32(dev-reg) |
From: Sukadev Bhattiprolu
When checking whether a bit representing a register is set in
sample_regs, a 64-bit mask, use 64-bit value (1LL).
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
---
tools/perf/util/unwind.c |4 ++--
1 file changed, 2 insertions(+), 2
However, your other solutions are better.
mask = (FM 1);
mask |= (FM 3) 0x10;
mask |= (FM 6) 0x100;
mask |= (FM 9) 0x1000;
mask |= (FM 12) 0x1;
mask |= (FM 15) 0x10;
mask |= (FM 18) 0x100;
mask |= (FM 21) 0x1000;
I disagree, perhaps mostly because the compiler is not clever enough, but
right
now the code for solution 1 is (actually I have rewritten the code
and it reads:
mask = (FM 1)
| ((FM 3) 0x10)
| ((FM 6) 0x100)
|
From: Michael Moese
Thank you for your help - we might be satisfied with the achieved
18 MB/s.
We achieved about twice that using the PEX dma controller.
I found the following comment I wrote:
/* Long transfer requests are cut into smaller DMA requests.
* Each PCIe request can contain a
From: Michael Moese
On Mon, Feb 03, 2014 at 10:17:43AM +, David Laight wrote:
We achieved about twice that using the PEX dma controller.
Your 3MB/s for single word transfers is similar to what we saw.
Cycle times that make an ISA bus look fast.
Indeed, this is a really poor
From Moese, Michael
Hello PPC-developers,
I'm currently trying to benchmark access speeds to our PCIe-connected IP-cores
located inside our FPGA. On x86-based systems I was able to achieve bursts for
both read and write access. On PPC32, using an e500v2, I had no success at all
so far.
I'm
From: Linuxppc-dev Tony Prisk
On 23/01/14 20:12, Yijing Wang wrote:
Currently, clocksource_register() and __clocksource_register_scale()
functions always return 0, it's pointless, make functions void.
And remove the dead code that check the clocksource_register_hz()
return value.
..
From: Anton Blanchard
We noticed a huge amount of slab memory consumed on a large ppc64 box:
Slab:2094336 kB
Almost 2GB. This box is not balanced and some nodes do not have local
memory, causing slub to be very inefficient in its slab usage.
Each time we call
But broken compiler is much wider issue to be deeply discussed in this
thread. I'm pretty sure that kernel have tons of very subtle
code that actually creates locks and memory ordering. Such code
usually just use the barrier() approach to tell gcc not to combine
or move memory accesses
For instance, your producer must issue a memory barrier instruction
after writing the data to shared memory and before inserting it on
the queue; likewise, your consumer must issue a memory barrier
instruction after removing an item from the queue and before reading
from its memory.
This is not a distro issue. It's a libstdc++ portability issue. libstdc++
hardcodes lwsync unless __NO_LWSYNC__ is explicitly defined,
which you only get with -mcpu=8540/-mcpu=8548. When compiled
for any powerpc target other than -mcpu=8540/-mcpu=8548, including
the default -mcpu=common,
Subject: Re: [PATCH] [RFC] Emulate lwsync to run standard user land on e500
cores
On Oct 23, 2013, at 5:15 AM, Scott Wood wrote:
On Wed, 2013-10-23 at 00:07 -0500, Kumar Gala wrote:
On Oct 18, 2013, at 2:38 AM, Wolfgang Denk wrote:
diff --git a/arch/powerpc/kernel/traps.c
Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 used strcat instead of
strcpy which can result in an overflow of newlines on the buffer.
...
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1531,12 +1531,12 @@ static ssize_t modalias_show(struct device *dev,
struct
Implement instr_is_load_store_2_06() to detect whether a given instruction
is one of the fixed-point or floating-point load/store instructions in the
POWER Instruction Set Architecture v2.06.
...
+int instr_is_load_store_2_06(const unsigned int *instr)
+{
+ unsigned int op, upper, lower;
It seems to me that a more useful interface would take a minimum and
maximum number of vectors from the driver. This wouldn't allow the
driver to specify that it could only accept, say, any even number within
a certain range, but you could still leave the current functions
available for
__initdata tag should be placed between the variable name and equal
sign for the variable to be placed in the intended .init.data section.
...
-static struct __initdata cpm_pin tqm8xx_pins[] = {
+static struct cpm_pin tqm8xx_pins[] __initdata = {
As far as gcc is concerned it can go almost
Subject: Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
On Wed, Sep 25, 2013 at 05:00:16PM -0400, Tejun Heo wrote:
Hello,
On Wed, Sep 25, 2013 at 10:58:05PM +0200, Alexander Gordeev wrote:
Unfortunately, pSeries is a shows-topper here :( It seems we have to
On Thu, Sep 26, 2013 at 09:58:53AM +0100, David Laight wrote:
Would it be possible to do some kind of 2-stage allocation.
In the first pass the driver would pass a minimum and desired
number of MSI-X interrupts, but not actually be given any.
Repeated calls to msi_enable_msi/msix
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -62,6 +62,16 @@ struct ppc64_stub_entry
r2) into the stub. */
static struct ppc64_stub_entry ppc64_stub =
{ .jump = {
+#ifdef __LITTLE_ENDIAN__
+ 0x00, 0x00, 0x82, 0x3d, /* addis r12,r2, high */
+
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -174,7 +174,11 @@ __ftrace_make_nop(struct module *mod,
pr_devel( %08x %08x\n, jmp[0], jmp[1]);
+#ifdef __LITTLE_ENDIAN__
+ ptr = ((unsigned long)jmp[1] 32) + jmp[0];
+#else
ptr = ((unsigned
Subject: Re: [PATCH 0/2] fs: supply inode uid/gid setting interface
On 2013/8/23 12:10, Greg KH wrote:
On Fri, Aug 23, 2013 at 10:48:36AM +0800, Rui Xiang wrote:
This patchset implements an accessor functions to set uid/gid
in inode struct. Just finish code clean up.
Why?
It can
On Tue, Aug 20, 2013 at 02:02:11PM +0930, Alan Modra wrote:
On Tue, Aug 20, 2013 at 12:37:50PM +1000, Anton Blanchard wrote:
address of the trap instruction for our bug exception table. Maybe
we need a gcc builtin in which we can get a label on the trap
instruction. Would that be
On Fri, Jul 19, 2013 at 6:46 AM, Gerhard Sittig g...@denx.de wrote:
So: No, not having to fiddle with DMA stuff when doing PCI need
not be a problem, it's actually expected. But since a DMA engine
might be involved (that's just not under your command), the
accompanying problems may
On 07/15/2013 11:53:54 AM, Scott Wood wrote:
On 07/15/2013 03:45:36 AM, David Laight wrote:
Also, if the high word changes, there is no need to loop.
Just return the second value with a low word of zero
(the returned count happened while the function was active).
That would be more
+#define MFTB(dest, scratch1, scratch2) \
+90: mftbu scratch1; \
+ mftbl dest; \
+ mftbu scratch2; \
+ cmpwscratch1,scratch2; \
+ bne 90b;\
+ rldimi dest,scratch1,32,0;
Are the
+#define IS_SVR_REV(svr, maj, min) \
+ ((SVR_MAJ(svr) == (maj)) (SVR_MIN(svr) == (min)))
I don't think IS_SVR_REV is needed. Callers can just do if
(SVR_REV(svr) == 0x30) or whatever, especially since we're relying on
them to do this for greater/less than comparisons.
Not only that,
It'd also be nice if we had an option to only include the portions
of math-emu that are known to be missing in some CPUs (excluding
CPUs that are missing the entire FPU, of course). Besides its
effect on kernel image size, in my experience math-emu adds a
non-trivial amount of time to a
Reserved fields of the sync instruction have been used for other
instructions (e.g. lwsync). On processors that do not support variants
of the sync instruction, emulate it by executing a sync to subsume the
effect of the intended instruction.
...
+ /* Emulate sync instruction variants */
It would also increase the latency of CPU-hotunplug operations.
Is that a big deal?
I thought that was the whole deal with this patchset - making cpu
hotunplugs lighter and faster mostly for powersaving. That said, just
removing stop_machine call would be a pretty good deal and I
We have 2 fields in struct pnv_phb to trace the states. The patch
replace the fields with one and introduces flags for that. The patch
doesn't impact the logic.
What is the benefit of this change?
...
+
+#define PNV_EEH_STATE_ENABLED(1 0)/* EEH enabled */
+#define
Once stop_machine() is gone from the CPU offline path, we won't be able
to depend on disabling preemption to prevent CPUs from going offline
from under us.
Could you use an rcu-like sequence so that disabling pre-emption
would be enough?
Something like rebuilding the cpu list, then forcing
failure:
__
static inline __attribute__((always_inline))
__attribute__((no_instrument_function)) int
__hash_page_thp(unsigned long ea, unsigned long access,
unsigned long vsid, pmd_t *pmdp,
unsigned long trap, int local,
int ssize, unsigned int psize)
{
do {
I think we should be able to do something better using the C
preprocessor, this is exactly the sort of thing it's good at.
What I mean is something like we do with arch/powerpc/include/asm/systbl.h,
where we define the list of syscalls once, and then include it in
multiple places, using
Note: It's more readable if you use the register names, ie:
lwz %r30, .label - (1b)(%r31)
The form of lwz is
lwz dest_reg, offset(address_reg)
So it will load a 32-bit value from memory at the address contained in
r31 offset by .label - 1b which is itself the
+
+static double crackpot_sqrt(double val)
+{
+int i;
+float x, y;
+const float f = 1.5F;
+
+x = val * 0.5F;
+y = val;
+i = * ( int * ) y;
+i = 0x5f3759df - ( i 1 );
+y = * ( float * ) i;
+y = y * ( f - ( x * y * y ) );
+y
If a BAR has the value of 0, we would assume that it is unset yet and
then mark the resource as unset and would reassign it later.
IIRC the PCI spec allows a BAR address of zero.
Certainly some sparc systems have assigned 0 to a BAR.
So assuming a BAR of 0 means it is unset may not be
true for
ptep = pte_offset_kernel(pmd, addr);
do {
- pte_t pte = *ptep;
+ pte_t pte = ACCESS_ONCE(*ptep);
Why not just define ptep as a 'pointer to volatile'?
David
___
Linuxppc-dev mailing list
strcpy(ssi_private-name, p) in probe() sets name by p, gotten from dts,
while the length of p, if the devicetree node name of SSI is commonly set,
would always be larger than 1 char size, so need a larger size for name.
Are you sure this isn't allowed for when the structure is allocated?
Some MPIC implementations tend to generate a spurrious IRQ in the case
of level IRQs going away. IE. they still remember an event occurred and
interrupt the processor, but on IACK return the spurious vector. However
that isn't guaranteed to be the case and it is perfectly ok (and a good
idea)
Did someone fix btrfs, but not check other kernel locks? Having now
hit the same problem again, have you checked that other kernel locks
don't have adjacent bit fields in the same 64-bit word? And comment
the struct to ensure someone doesn't optimize those unsigned chars
back to bit fields.
Could ppc64 experts confirm using byte is safe, or should we really add
a 32bit hole after the spinlock ? If so, I wonder how many other places
need a change...
...
Also I'd be surprised if ppc64 is the only one with that problem... what
about sparc64 and arm64 ?
Even x86 could be
Also I'd be surprised if ppc64 is the only one with that problem... what
about sparc64 and arm64 ?
Even x86 could be affected.
The width of the memory cycles used by the 'bit set and bit clear'
instructions isn't documented. They are certainly allowed to do
RMW on adjacent bytes.
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index a8836e8..dbdfd2b 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -57,9 +57,10 @@ struct unix_sock {
struct list_headlink;
atomic_long_t inflight;
spinlock_t
Hmm, seems there's no probe_user_address() -- for userspace we
basically want the same thing minus the KERNEL_DS. See
arch/powerpc/perf/callchain.c for an example.
Isn't that just copy_from_user() ?
David
___
Linuxppc-dev mailing list
Is that OK if I use the following code?
...
if (is_in_pci_mem_space(addr)) {
if (!user_mode(regs)) {
ret = probe_kernel_address(regs-nip, inst);
if (!ret) {
rd = get_rt(inst);
On Fri, 2013-03-08 at 11:38 +0800, Chen Gang wrote:
originally I did not notice src buf len and dest buf len are the same.
so origianlly, it is not a bug issue, it is only for beautify code.
and now, using strcpy is better.
Being the same len doesn't mean it's safe to use
In my understanding filling the register could warn the executing process
an error occurred in some cases. But no way to fix the wrong behavior caused
by the instruction lost. So let's say that filling the register may benefit
a little.
IIRC the only ppc instructions that should be accessing
Yes, that's (one reason) why you'd want to fill in a known value. Note
the for now. :-)
-Scott
I think there is no overwhelming reason to fill the destination register
with 0x.
There's a small chance that 0x is treated as regular data rather
than an error sign.
A PCIe erratum of mpc85xx may causes a core hang when a link of PCIe
goes down. when the link goes down, Non-posted transactions issued
via the ATMU requiring completion result in an instruction stall.
At the same time a machine-check exception is generated to the core
to allow further
I wouldn't go that far... ;-) Unfairness is not a show-stopper right?
IMHO, the warning/documentation should suffice for anybody wanting to
try out this locking scheme for other use-cases.
I presume that by 'fairness' you mean 'write preference'?
I'd not sure how difficult it would be, but
* The proto-VSIDs are then scrambled into real VSIDs with the
* multiplicative hash:
...
* VSID_MULTIPLIER is prime, so in particular it is
* co-prime to VSID_MODULUS, making this a 1:1 scrambling function.
* Because the modulus is 2^n-1 we can compute it efficiently without
+ *
+#define CONTEXT_BITS 19
+#define USER_ESID_BITS 18
+#define USER_ESID_BITS_1T6
+
+/*
+ * 256MB segment
+ * The proto-VSID space has 2^(CONTEX_BITS + USER_ESID_BITS) - 1 segments
+ * available for user + kernel mapping. The top 4 contexts are used for
+ * kernel
dcbtr0,r8,0b01010 /* GO */
.machine pop
Jimi, are you using an old binutils from before my patch that
changed the operand order for these types of instructions?
http://sourceware.org/ml/binutils/2009-02/msg00044.html
Actually, this confused me as well, that
Does it mean that pci is supposed be always 64 bit wide?
And there is no option to have just 32bit values.
I certainly believe that all PCIe (not PCI) transfers are
nominally multiples of 64bit data.
There are (effectively) 8 byte-lane enables to allow partial word
transfers (I'm not sure
We have two #defines that rename scanhex() and skipbl() to
xmon_scanhex() and xmon_skipbl() - but no one ever uses those
names.
It looks like they are there for namespace protection.
David
___
Linuxppc-dev mailing list
/* N.B. the only way to get here is from the beq following ret_from_except.
*/
resume_kernel:
- /* check current_thread_info-preempt_count */
+ /* check current_thread_info, _TIF_EMULATE_STACK_STORE */
CURRENT_THREAD_INFO(r9, r1)
+ lwz r8,TI_FLAGS(r9)
+ andis.
+ /* Read command completed register */
+ done_mask = ioread32(hcr_base + CC);
+
+ if (host_priv-quirks SATA_FSL_QUIRK_V2_ERRATA) {
+ if (unlikely(hstatus INT_ON_DATA_LENGTH_MISMATCH)) {
+ for (tag = 0; tag ATA_MAX_QUEUE; tag++) {
+
For flexibility you need to allow for 8bit samples being converted
as:
1) 8bit raw ulaw or alaw data (unchanged from line).
2) 8bit raw data, bit reversed, any hdlc protocol
is bit reversed from audio [1].
3) 8bit audio, converted from alaw to ulaw
4) 8bit audio, converted from ulaw
+3. TDM has programmable slot length (8 bits or 16 bits). This can be
+ configured by:
+
+ #define NUM_BYTES_PER_SLOT 8
I presume you meant NUM_BITS_PER_SLOT ?
These constants need name-space protection
+or
+ #define NUM_BYTES_PER_SLOT 16
+
+depending on the type of
A PCIe erratum of mpc85xx may causes a core hang when a link of PCIe
goes down. when the link goes down, Non-posted transactions issued
via the ATMU requiring completion result in an instruction stall.
At the same time a machine-check exception is generated to the core
to allow further
Fine with me, though FWIW that not only doesn't use
__constant_cpu_to_le16() but actually swaps the non-constant value.
Don't see what point you are trying to make here. Swapping the value
from the actual command structure is always fine with me.
The point is that the result of
-Original Message-
From: Linuxppc-dev
[mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozl
abs.org] On Behalf Of Benjamin Herrenschmidt
Sent: 07 June 2012 07:40
To: Michael Neuling
Cc: mich...@ellerman.id.au; pau...@samba.org; Anton
Blanchard; o...@lixom.net;
We have a system with linux 2.6.32 and the somewhat archaic
uClibc 0.9.27 (but I'm not sure the current version is
any better, and I think there are binary compatibility
if we update).
I've just discovered that pread() is 'implemented'
by using 3 lseek() system calls and read().
401 - 500 of 585 matches
Mail list logo
