On Thu, 2015-07-09 at 12:52 +0300, Denis Kirjanov wrote:
> On 7/9/15, Christian Zigotzky wrote:
> > All
> >
> > I think you haven't received the SB600 patch yet. I have pasted it in
> > this email directly. Thank you for your help. I am sorry because of this
> > long patch but I hope you could hel
On 07/13/2015 11:11 AM, Michael Ellerman wrote:
> On Mon, 2015-07-13 at 10:54 +0530, Anshuman Khandual wrote:
>> On 07/10/2015 12:40 PM, Michael Neuling wrote:
>>> What's the performance impact of this? If you run this test with --fp,
>>> --altivec or --vector what is the impact of adding this pat
On Fri, 2015-07-10 at 00:27 +0200, Christian Zigotzky wrote:
> Hi All,
>
> Many thanks for your help. You're right. It was something wrong with my
> last bisect. I did another bisect. I evaluated the one "sometimes boots"
> with good.
.../...
Now that makes more sense since the problem is aro
On Mon, 2015-07-13 at 10:54 +0530, Anshuman Khandual wrote:
> On 07/10/2015 12:40 PM, Michael Neuling wrote:
> > What's the performance impact of this? If you run this test with --fp,
> > --altivec or --vector what is the impact of adding this patch?
> >
> > http://ozlabs.org/~anton/junkcode/cont
On 07/10/2015 12:40 PM, Michael Neuling wrote:
> What's the performance impact of this? If you run this test with --fp,
> --altivec or --vector what is the impact of adding this patch?
>
> http://ozlabs.org/~anton/junkcode/context_switch2.c
>
> eg
> ./context_switch2 --fp 0 0
Please find th
On Sun, 2015-12-07 at 22:02:11 UTC, Bjorn Helgaas wrote:
> Many architectures use a variant of "unexpected IRQ trap at vector %x" to
> log unexpected IRQs. This is confusing because (a) it prints the Linux IRQ
> number, but "vector" more often refers to a CPU vector number, and (b) it
> prints the
> -Original Message-
> From: Laura Abbott [mailto:labb...@redhat.com]
> Sent: Friday, July 10, 2015 5:51 AM
> To: Zhao Qiang-B45475; lau...@codeaurora.org
> Cc: linux-ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> a...@linux-foundation.org; o...@lixom.net; catalin.mari...@arm.co
Many architectures use a variant of "unexpected IRQ trap at vector %x" to
log unexpected IRQs. This is confusing because (a) it prints the Linux IRQ
number, but "vector" more often refers to a CPU vector number, and (b) it
prints the IRQ number in hex with no base indication, while Linux IRQ
numbe
Previously we printed, e.g.,
do_IRQ: 0.242 No irq handler for vector (irq -1)
There's no clue about what "0.242" means, and the IRQ number, which is the
important generic information used by drivers and /proc/interrupts, is
almost an afterthought.
Change the format to this:
No handler for I
The per-cpu vector_irq[] table is indexed by CPU vector numbers, and each
entry contains an IRQ number.
Rename the special values VECTOR_UNDEFINED and VECTOR_RETRIGGERED to
IRQ_UNDEFINED and IRQ_RETRIGGERED to indicate that they are in the IRQ
number space, not the CPU vector number space.
No fun
These don't fix anything at all. But they might make code understanding
and debugging slightly easier.
---
Bjorn Helgaas (3):
x86, irq: Rename VECTOR_UNDEFINED and VECTOR_RETRIGGERED to IRQ_*
x86, irq: Clarify "No irq handler" message
IRQ: Print "unexpected IRQ" messages consis
Add the powerpc-specific sync() method to struct nvram_ops and implement
the corresponding ioctl in the nvram module. This allows the nvram module
to replace the generic_nvram module.
Signed-off-by: Finn Thain
---
On PPC32, the IOC_NVRAM_SYNC ioctl call always returns 0, even for those
platform
Signed-off-by: Finn Thain
---
Tested on a PowerBook 520 and Quadra 650.
Changes since v2:
- Make use of the RTC_* macros from the previous patch and add a few more
besides.
---
arch/m68k/mac/misc.c | 39 +--
include/uapi/linux/pmu.h |2 ++
2 files
Adopt the existing *_read_byte and *_write_byte naming convention.
Rename via_pram_readbyte and via_pram_writebyte to avoid confusion.
Adjust calling conventions of mac_pram_* functions to match the
arch_nvram_ops struct methods.
Signed-off-by: Finn Thain
---
Changes since v1:
- Don't introduce
And thus eliminate some twisted CONFIG_GENERIC_NVRAM logic.
Signed-off-by: Finn Thain
---
drivers/char/Makefile|6 -
drivers/char/generic_nvram.c | 176 ---
2 files changed, 1 insertion(+), 181 deletions(-)
Index: linux/drivers/char/Makefile
A multi-platform kernel binary needs to decide at run-time how to dispatch
the arch_nvram_ops calls. Add platform-independent arch_nvram_ops, for use
when multiple platform-specific NVRAM ops implementations are needed.
Enable CONFIG_HAVE_ARCH_NVRAM_OPS for Macs.
Signed-off-by: Finn Thain
---
Signed-off-by: Finn Thain
---
This is intended to improve code style and not affect code behaviour.
I've tested this on a Quadra 650.
I don't know the meanings of the 4 undocumented write protect register
bits 0x55, so I decided against defining 4 macros for those bits.
---
arch/m68k/mac/misc
Switch PPC32 kernels from the generic_nvram module to the nvram module.
Also fix a theoretical bug where CHRP omits the chrp_nvram_init()
call when CONFIG_NVRAM_MODULE=m.
As before, when CONFIG_PPC && !CONFIG_PPC_PMAC, the IOC_NVRAM_GET_OFFSET
ioctl is unimplemented. For the nvram module, unimple
Adopt nvram module to reduce code duplication.
The IOC_NVRAM_GET_OFFSET ioctl as implemented on PPC64 validates the offset
returned by pmac_get_partition(). Add this test to the nvram module.
Note that the old PPC32 generic_nvram module lacked this test.
So when CONFIG_PPC32 && CONFIG_PPC_PMAC, t
Drivers now use the arch_nvram_ops calls so remove the function exports and
prototypes. nvram_check_checksum() is unused so remove it.
Signed-off-by: Finn Thain
---
arch/m68k/atari/nvram.c |6 +++---
drivers/char/nvram.c| 27 +--
include/linux/nvram.h |8
Make use of arch_nvram_ops in device drivers so that the nvram_*
function exports can be removed.
Since they are no longer global symbols, rename the PPC32 nvram_* functions
appropriately.
Add the missing CONFIG_NVRAM test to imsttfb to avoid a build failure.
Signed-off-by: Finn Thain
---
arc
Implement arch_nvram_ops for PPC32 and make use of it in the generic_nvram
misc device module so that the nvram_* function exports can be removed.
Signed-off-by: Finn Thain
---
arch/powerpc/include/asm/nvram.h |3 ---
arch/powerpc/kernel/setup_32.c | 10 +++---
drivers/char/generic_
Also give functions more sensible names: nvram_misc_* for misc device ops,
nvram_proc_* for proc file ops and nvram_module_* for init and exit
functions. This makes them distict from nvram_ops members.
Signed-off-by: Finn Thain
---
drivers/char/nvram.c | 194 ++-
Refactor the RTC "CMOS" NVRAM functions so that they can be used as
arch_nvram_ops methods. Checksumming logic is moved from the misc device
operations to the nvram read/write operations.
This makes the misc device implementation more generic. This also
preserves the locking semantics such that "r
Add the nvram_size() function to those PowerPC platforms that don't already
have one: CHRP and PowerMac. This means that the ppc_md.nvram_size()
function can be used to implement arch_nvram_ops.get_size()
Since we are addressing inconsistencies here, also rename chrp_nvram_read
and chrp_nvram_writ
The nvram_read_byte() and nvram_write_byte() definitions in asm/nvram.h
duplicate those in linux/nvram.h. Get rid of the former to prepare for
adoption of struct arch_nvram_ops (which is defined in linux/nvram.h for
general use).
Signed-off-by: Finn Thain
---
arch/powerpc/include/asm/nvram.h
The drivers/char/nvram module has previously only supported RTC "CMOS"
NVRAM, for which it provides appropriate checksum ioctls. Make these
ioctls optional so the module can be re-used with other kinds of NVRAM.
The ops struct methods that implement the ioctls now return error
codes so that a mult
Make use of arch_nvram_ops in the thinkpad_acpi driver so that the
nvram_* function exports can be removed.
This patch series was tested on a ThinkPad T43.
Signed-off-by: Finn Thain
Acked-by: Henrique de Moraes Holschuh
Reviewed-by: Darren Hart
---
drivers/platform/x86/thinkpad_acpi.c | 20
Signed-off-by: Finn Thain
---
drivers/char/nvram.c |1 +
1 file changed, 1 insertion(+)
Index: linux/drivers/char/nvram.c
===
--- linux.orig/drivers/char/nvram.c 2015-07-12 20:25:05.0 +1000
+++ linux/drivers/char/nv
Atari RTC NVRAM has a checksum so implement the remaining arch_nvram_ops
methods for the set_checksum and initialize ioctls. Enable
CONFIG_HAVE_ARCH_NVRAM_OPS.
Signed-off-by: Finn Thain
---
This re-enables the nvram module for Atari.
Changes since v3:
- Use bool (and select) instead of def_boo
Signed-off-by: Finn Thain
---
drivers/char/nvram.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
Index: linux/drivers/char/nvram.c
===
--- linux.orig/drivers/char/nvram.c 2015-07-12 20:25:03.0
Different platforms and architectures offer different NVRAM sizes and
access methods. E.g. PPC32 has byte-at-a-time read/write functions whereas
PPC64 has byte-range read/write functions. Adopt the nvram_ops struct so
the nvram module can call such functions as are defined by the various
platforms
Move the m68k-specific code elsewhere to make the driver generic.
Signed-off-by: Finn Thain
---
BTW, I didn't change the SCSI ID location in NVRAM. This code says 16
whereas atari_scsi says 14. Which one is correct?
Changes since v3:
- Move the vmode fix to a separate patch as requested by Gee
Signed-off-by: Finn Thain
Acked-by: Geert Uytterhoeven
---
drivers/char/nvram.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/drivers/char/nvram.c
===
--- linux.orig/drivers/char/nvram.c 2015-07-12 20:2
By implementing an arch_nvram_ops struct, any platform can re-use the
drivers/char/nvram module without needing any arch-specific code
in that module. Atari does so here.
Atari has one user of nvram_check_checksum() whereas the other platforms
(i.e. x86 and ARM platforms) have none at all. Replace
On powerpc, setting CONFIG_NVRAM=n builds a kernel with no NVRAM support.
Setting CONFIG_NVRAM=m enables the /dev/nvram misc device module without
enabling NVRAM support in drivers. Setting CONFIG_NVRAM=y enables the
misc device (built-in) and also enables NVRAM support in drivers.
m68k shares the
The generic NVRAM module, drivers/char/generic_nvram, implements a
/dev/nvram misc device. It is used only by 32-bit PowerPC platforms and
isn't generic enough to be more widely used.
The RTC NVRAM module, drivers/char/nvram, also implements a /dev/nvram
misc device. It is used by x86, ARM and m6
From: Priyanka Jain
T1040D4RDB/T1042D4RDB are Freescale Reference Design Board
which can support T1040/T1042 QorIQ Power
Architecture™ processor respectively
T1040D4RDB/T1042D4RDB board Overview
-
- SERDES Connections, 8 lanes supporting:
- PCI
38 matches
Mail list logo
