On Sat, 25 Jul 2015, Michael Ellerman wrote:
> On Sat, 2015-07-25 at 10:35 +1000, Finn Thain wrote:
> >
> > ... These are rudimentary tests but combined with my own testing on
> > m68k, ppc32 and x86, coverage is quite good. Some testing on ppc64 is
> > still lacking though.
Here's some code
On Sun, 26 Jul 2015, Michael Schmitz wrote:
> Hi Finn,
>
> For the sake of completeness: further testing on ARAnyM shows no difference
> between original and patched kernel in the NVRAM proc and diff outputs:
>
> scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base 0x0, irq 15,
> can_q
Hi Finn,
For the sake of completeness: further testing on ARAnyM shows no
difference between original and patched kernel in the NVRAM proc and
diff outputs:
scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base 0x0, irq
15, can_queue 8, cmd_per_lun 1, sg_tablesize 0, this_id 7, flags
No need to execute mflr twice.
Signed-off-by: Anton Blanchard
---
arch/powerpc/kernel/entry_64.S | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 8428280..f8779f2 100644
--- a/arch/powerpc/kernel/entry_64
Move all our context switch SPR save and restore code into two
helpers. We do a few optimisations:
- Group all mfsprs and all mtsprs. In many cases an mtspr sets a
scoreboarding bit that an mfspr waits on, so the current practise of
mfspr A; mtspr A; mfpsr B; mtspr B is the worst scheduling we can
There seems little point in disabling the FP/VMX/VSX MSR bits on
context switch since we don't do it after calling
enable_kernel_altivec() in other places. Writing the MSR is slow
so lets not do it unnecessarily.
A context switch microbenchmark using yield():
http://ozlabs.org/~anton/junkcode/con
Hi,
On 07/20/2015 05:08 PM, Krzysztof Opasiak wrote:
On 07/15/2015 08:32 AM, Robert Baldyga wrote:
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/pch_udc.c | 14 --
1 file changed, 12 insertions(+), 2 deletio
Hello linuxppc-dev mailing list!
I come right to the point.
My computer is a Power Mac G4 Quicksilver (original, 2001) with the a flashed
PC graphics card Nvidia 6200 AGP. It is correctly supported in Mac OS X
10.4/10.5 and it was working in Linux with the Debian kernels 3.16. I use
Debian test
On Fri, 2015-07-24 at 12:15 +0530, Aneesh Kumar K.V wrote:
> Michael Ellerman writes:
>
> > The powerpc kernel can be built to have either a 4K PAGE_SIZE or a 64K
> > PAGE_SIZE.
...
> > diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
> > b/arch/powerpc/include/asm/pgtable-ppc64.h
> > index
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
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.
Signed-off-by: Finn Thain
---
Changed since v4:
- Split off the CONFIG_PPC32, CONFIG_PPC_PMAC and CONFIG_
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
Tested
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
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
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
And thus eliminate some twisted CONFIG_GENERIC_NVRAM logic.
Signed-off-by: Finn Thain
---
drivers/char/Makefile|6 -
drivers/char/generic_nvram.c | 175 ---
2 files changed, 1 insertion(+), 180 deletions(-)
Index: linux/drivers/char/Makefile
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
This patch addresses inconsistencies in Mac framebuffer drivers and their
use of Kconfig symbols relating to NVRAM, so PPC64 can use CONFIG_NVRAM.
Macintosh framebuffer drivers use default settings for color mode and
video mode that are found in NVRAM. On PCI Macs, MacOS stores display
settings in
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
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
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 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
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
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
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
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_
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-25 17:45:35.0 +1000
+++ linux/drivers/char/nv
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
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
---
Changes since v4:
- Fix possible gi
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-25 17:45:34.0
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 ++-
Move the m68k-specific code elsewhere to make the driver generic.
Signed-off-by: Finn Thain
Tested-by: Christian T. Steigies
---
Changes since v3:
- Move the vmode fix to a separate patch as requested by Geert.
---
arch/m68k/atari/Makefile |2
arch/m68k/atari/nvram.c | 255 +++
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
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
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
Signed-off-by: Finn Thain
Acked-by: Geert Uytterhoeven
Tested-by: Christian T. Steigies
---
drivers/char/nvram.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/drivers/char/nvram.c
===
--- linux.orig/driver
On Sat, 25 Jul 2015, Michael Ellerman wrote:
> On Sat, 2015-07-25 at 10:35 +1000, Finn Thain wrote:
> >
> > Thanks for helping with this, Christian. I'll add your name in
> > "Tested-by" tags on the relevant patches. These are rudimentary tests
> > but combined with my own testing on m68k, ppc
On Sat, 25 Jul 2015, Michael Schmitz wrote:
> Hi Christian,
>
> good to know this worked - for the record (Finn), this is the kernel
> with Finn's patch applied.
That was v5 of this patch series. I will send that out to the lists now.
It has some minor changes that relate to powerpc.
Thanks
38 matches
Mail list logo
