* [PATCH 4/4] bootwrapper: cuboot for 83xx
From: Scott Wood @ 2007-04-16 23:25 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070416232451.GA26667@ld0162-tx32.am.freescale.net>
This adds cuboot support for MPC83xx platforms.
A device tree used with this must have linux,stdout-path in /chosen and
linux,network-index in any network device nodes that need mac addresses
assigned.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/Makefile | 3 +-
arch/powerpc/boot/cuboot-83xx.c | 68 +++++++++++++++++++++++++++++++++++++++
2 files changed, 70 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-83xx.c
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d602b7c..3e172ff 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -43,7 +43,7 @@ $(addprefix $(obj)/,$(zlib) main.o): $(addprefix $(obj)/,$(zliblinuxheader)) \
src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
gunzip_util.c elf_util.c $(zlib) devtree.c
-src-plat := of.c
+src-plat := of.c cuboot-83xx.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -162,6 +162,7 @@ $(obj)/zImage.initrd.ps3: vmlinux
$(obj)/uImage: vmlinux $(wrapperbits)
$(call if_changed,wrap,uboot)
+cuboot-plat-$(CONFIG_83xx) += 83xx
cuboot-plat-y += unknown-platform
dts = $(if $(shell echo $(CONFIG_) | grep '^/'),\
diff --git a/arch/powerpc/boot/cuboot-83xx.c b/arch/powerpc/boot/cuboot-83xx.c
new file mode 100644
index 0000000..8f11d1e
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-83xx.c
@@ -0,0 +1,68 @@
+/*
+ * Old U-boot compatibility for 83xx
+ *
+ * Author: Scott Wood <scottwood@freescale.com>
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+
+#define TARGET_83xx
+#include "ppcboot.h"
+
+static bd_t bd;
+extern char _end[];
+extern char _dtb_start[], _dtb_end[];
+
+static void platform_fixups(void)
+{
+ void *soc;
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
+ dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+
+ /* Unfortunately, the specific model number is encoded in the
+ * soc node name in existing dts files -- once that is fixed,
+ * this can do a simple path lookup.
+ */
+ soc = find_node_by_devtype(NULL, "soc");
+ if (soc) {
+ void *serial = NULL;
+
+ setprop(soc, "bus-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+
+ while ((serial = find_node_by_devtype(serial, "serial"))) {
+ if (get_parent(serial) != soc)
+ continue;
+
+ setprop(serial, "clock-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+ }
+ }
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ unsigned long end_of_ram = bd.bi_memstart + bd.bi_memsize;
+ unsigned long avail_ram = end_of_ram - (unsigned long)_end;
+
+ memcpy(&bd, (bd_t *)r3, sizeof(bd));
+ loader_info.initrd_addr = r4;
+ loader_info.initrd_size = r4 ? r5 : 0;
+ loader_info.cmdline = (char *)r6;
+ loader_info.cmdline_len = r7 - r6;
+
+ simple_alloc_init(_end, avail_ram, 32, 64);
+ ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
--
1.5.0.3
^ permalink raw reply related
* [PATCH 3/4] bootwrapper: Add ppcboot.h.
From: Scott Wood @ 2007-04-16 23:25 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070416232451.GA26667@ld0162-tx32.am.freescale.net>
This file describes the bd_t struct, which is used by old versions of
U-boot to pass information to the kernel. Platform code that needs to
interoperate with such firmware can use this; it should not be used for
anything new.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/ppcboot.h | 108 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 108 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/ppcboot.h
diff --git a/arch/powerpc/boot/ppcboot.h b/arch/powerpc/boot/ppcboot.h
new file mode 100644
index 0000000..5290ff2
--- /dev/null
+++ b/arch/powerpc/boot/ppcboot.h
@@ -0,0 +1,108 @@
+/*
+ * This interface is used for compatibility with old U-boots *ONLY*.
+ * Please do not imitate or extend this.
+ */
+
+/*
+ * (C) Copyright 2000, 2001
+ * Wolfgang Denk, DENX Software Engineering, wd@denx.de.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __PPCBOOT_H__
+#define __PPCBOOT_H__
+
+/*
+ * Board information passed to kernel from PPCBoot
+ *
+ * include/asm-ppc/ppcboot.h
+ */
+
+#include "types.h"
+
+typedef struct bd_info {
+ unsigned long bi_memstart; /* start of DRAM memory */
+ unsigned long bi_memsize; /* size of DRAM memory in bytes */
+ unsigned long bi_flashstart; /* start of FLASH memory */
+ unsigned long bi_flashsize; /* size of FLASH memory */
+ unsigned long bi_flashoffset; /* reserved area for startup monitor */
+ unsigned long bi_sramstart; /* start of SRAM memory */
+ unsigned long bi_sramsize; /* size of SRAM memory */
+#if defined(TARGET_8xx) || defined(TARGET_CPM2) || defined(TARGET_85xx) ||\
+ defined(TARGET_83xx)
+ unsigned long bi_immr_base; /* base of IMMR register */
+#endif
+#if defined(TARGET_PPC_MPC52xx)
+ unsigned long bi_mbar_base; /* base of internal registers */
+#endif
+ unsigned long bi_bootflags; /* boot / reboot flag (for LynxOS) */
+ unsigned long bi_ip_addr; /* IP Address */
+ unsigned char bi_enetaddr[6]; /* Ethernet address */
+ unsigned short bi_ethspeed; /* Ethernet speed in Mbps */
+ unsigned long bi_intfreq; /* Internal Freq, in MHz */
+ unsigned long bi_busfreq; /* Bus Freq, in MHz */
+#if defined(TARGET_CPM2)
+ unsigned long bi_cpmfreq; /* CPM_CLK Freq, in MHz */
+ unsigned long bi_brgfreq; /* BRG_CLK Freq, in MHz */
+ unsigned long bi_sccfreq; /* SCC_CLK Freq, in MHz */
+ unsigned long bi_vco; /* VCO Out from PLL, in MHz */
+#endif
+#if defined(TARGET_PPC_MPC52xx)
+ unsigned long bi_ipbfreq; /* IPB Bus Freq, in MHz */
+ unsigned long bi_pcifreq; /* PCI Bus Freq, in MHz */
+#endif
+ unsigned long bi_baudrate; /* Console Baudrate */
+#if defined(TARGET_4xx)
+ unsigned char bi_s_version[4]; /* Version of this structure */
+ unsigned char bi_r_version[32]; /* Version of the ROM (IBM) */
+ unsigned int bi_procfreq; /* CPU (Internal) Freq, in Hz */
+ unsigned int bi_plb_busfreq; /* PLB Bus speed, in Hz */
+ unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
+ unsigned char bi_pci_enetaddr[6]; /* PCI Ethernet MAC address */
+#endif
+#if defined(TARGET_HYMOD)
+ hymod_conf_t bi_hymod_conf; /* hymod configuration information */
+#endif
+#if defined(TARGET_EVB64260) || defined(TARGET_405EP) || defined(TARGET_44x) || \
+ defined(TARGET_85xx) || defined(TARGET_83xx)
+ /* second onboard ethernet port */
+ unsigned char bi_enet1addr[6];
+#define HAVE_ENET1ADDR
+#endif
+#if defined(TARGET_EVB64260) || defined(TARGET_440GX) || defined(TARGET_85xx)
+ /* third onboard ethernet ports */
+ unsigned char bi_enet2addr[6];
+#define HAVE_ENET2ADDR
+#endif
+#if defined(TARGET_440GX)
+ /* fourth onboard ethernet ports */
+ unsigned char bi_enet3addr[6];
+#define HAVE_ENET3ADDR
+#endif
+#if defined(TARGET_4xx)
+ unsigned int bi_opbfreq; /* OB clock in Hz */
+ int bi_iic_fast[2]; /* Use fast i2c mode */
+#endif
+#if defined(TARGET_440GX)
+ int bi_phynum[4]; /* phy mapping */
+ int bi_phymode[4]; /* phy mode */
+#endif
+} bd_t;
+
+#define bi_tbfreq bi_intfreq
+
+#endif /* __PPCBOOT_H__ */
--
1.5.0.3
^ permalink raw reply related
* [PATCH 2/4] bootwrapper: Add a cuboot platform and a cuImage target.
From: Scott Wood @ 2007-04-16 23:25 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070416232451.GA26667@ld0162-tx32.am.freescale.net>
The cuImage target will build a uImage with bootwrapper code and a device
tree. The default device tree and platform file are determined by the
kernel configuration.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
This version of the patch handles "make clean" correctly.
arch/powerpc/Makefile | 2 +-
arch/powerpc/boot/.gitignore | 3 +++
arch/powerpc/boot/Makefile | 13 +++++++++++--
arch/powerpc/boot/wrapper | 21 +++++++++++++++++++--
4 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index a00fe72..e6c3add 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -148,7 +148,7 @@ all: $(KBUILD_IMAGE)
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd uImage
+BOOT_TARGETS = zImage zImage.initrd uImage cuImage
PHONY += $(BOOT_TARGETS)
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index 0734b2f..eec7af7 100644
--- a/arch/powerpc/boot/.gitignore
+++ b/arch/powerpc/boot/.gitignore
@@ -18,6 +18,9 @@ kernel-vmlinux.strip.c
kernel-vmlinux.strip.gz
mktree
uImage
+cuImage
+cuImage.bin.gz
+cuImage.elf
zImage
zImage.chrp
zImage.coff
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 928b88a..d602b7c 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -129,7 +129,7 @@ image-$(CONFIG_PPC_CELLEB) += zImage.pseries
image-$(CONFIG_PPC_CHRP) += zImage.chrp
image-$(CONFIG_PPC_EFIKA) += zImage.chrp
image-$(CONFIG_PPC_PMAC) += zImage.pmac
-image-$(CONFIG_DEFAULT_UIMAGE) += uImage
+image-$(CONFIG_DEFAULT_UIMAGE) += uImage cuImage
# For 32-bit powermacs, build the COFF and miboot images
# as well as the ELF images.
@@ -162,6 +162,14 @@ $(obj)/zImage.initrd.ps3: vmlinux
$(obj)/uImage: vmlinux $(wrapperbits)
$(call if_changed,wrap,uboot)
+cuboot-plat-y += unknown-platform
+
+dts = $(if $(shell echo $(CONFIG_) | grep '^/'),\
+ ,$(srctree)/$(src)/dts/)$(CONFIG_DEVICE_TREE)
+
+$(obj)/cuImage: vmlinux $(wrapperbits)
+ $(call if_changed,wrap,cuboot-$(word 1,$(cuboot-plat-y)),$(dts))
+
$(obj)/zImage: $(addprefix $(obj)/, $(image-y))
@rm -f $@; ln $< $@
$(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y))
@@ -171,7 +179,8 @@ install: $(CONFIGURE) $(image-y)
sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)" $<
# anything not in $(targets)
-clean-files += $(image-) $(initrd-) zImage zImage.initrd
+clean-files += $(image-) $(initrd-) zImage zImage.initrd \
+ cuImage.elf cuImage.bin.gz
# clean up files cached by wrapper
clean-kernel := vmlinux.strip vmlinux.bin
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index e4566bd..5cedd90 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -141,6 +141,9 @@ miboot|uboot)
ksection=image
isection=initrd
;;
+cuboot*)
+ gzip=
+ ;;
esac
vmz="$tmpdir/`basename \"$kernel\"`.$ext"
@@ -161,13 +164,17 @@ fi
vmz="$vmz$gzip"
case "$platform" in
-uboot)
- rm -f "$ofile"
+uboot|cuboot*)
version=`${CROSS}strings "$kernel" | grep '^Linux version [-0-9.]' | \
cut -d' ' -f3`
if [ -n "$version" ]; then
version="-n Linux-$version"
fi
+esac
+
+case "$platform" in
+uboot)
+ rm -f "$ofile"
mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
$version -d "$vmz" "$ofile"
if [ -z "$cacheit" ]; then
@@ -216,4 +223,14 @@ pmaccoff)
${CROSS}objcopy -O aixcoff-rs6000 --set-start "$entry" "$ofile"
$object/hack-coff "$ofile"
;;
+cuboot*)
+ base=`${CROSS}nm "$ofile" | grep ' _start$' | cut -d' ' -f1`
+ entry=`${CROSS}objdump -f "$ofile" | grep '^start address ' | \
+ cut -d' ' -f3`
+ mv "$ofile" "$ofile".elf
+ ${CROSS}objcopy -O binary "$ofile".elf "$ofile".bin
+ gzip -f -9 "$ofile".bin
+ mkimage -A ppc -O linux -T kernel -C gzip -a "$base" -e "$entry" \
+ $version -d "$ofile".bin.gz "$ofile"
+ ;;
esac
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH 1/4 v2] powerpc: document max-speed and interface-type properties
From: Segher Boessenkool @ 2007-04-16 23:25 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev
In-Reply-To: <98DB6E05-1869-47E9-882E-17B4F574581F@freescale.com>
>> Yep. The whole reason why any property is wanted here is
>> to say what type the PHY is, as the enet controller can
>> be attached to several kinds. And what type the PHY is
>> belongs in the PHY node, obviously. In its "compatible"
>> property to be exact.
>
> It's not saying what type the PHY is, though. It's describing the
> connection. The PHY is just as flexible wrt connection type as the
> ethernet controller.
Huh, I've never seen that. I'll take your word for it.
> This is actually a property of the board. In some cases its a fixed
> property of the board. In some cases it's changeable through dip
> switches, or even through software.
In such a case you cannot describe this with a fixed
flat device tree *at all*.
> Ethernet controllers need to know what the connection is so they can
> establish a data connection with the PHYs
Can't you probe for PHYs?
> The reason for choosing the ethernet controller in this case has to do
> with the flow of information.
>
> 1) The driver tells the PHY what interface to use
The device tree is not structured after how Linux device
drivers want to use the information; instead, it describes
the hardware.
> 2) The ethernet controller is the endpoint of this connection which is
> accessible by everyone else. IE data is not sent through PHYs by any
> means but through the ethernet controller, and data is not received
> from PHYs by any means but through the ethernet controller.
So?
> 3) The UCC needs to be told the connection type, because it does not
> have logic to detect it on its own.
Just try all possible kinds, see if you can see a PHY
connected?
> The truth is, this is a somewhat intractable problem because of the
> myriad possibilities for how board designers can hook up ethernet
> controllers to PHYs. One can envision scenarios where controllers can
> hook up to multiple PHYs, each of one fixed type.
Yeah, seen that. Quite a common scenario.
> One can envision scenarios where multiple controllers are hooked up to
> one PHY, and each of the controllers can use different connections.
How would that work at all, except when only one controller
is active and the rest are shut down?
> If we put the information in the PHY node, we allow for the first
> scenario, but not the second. If we put it in the ethernet node, we
> reverse that situation. In either case, we'd currently have to modify
> our dts to specify which PHY we want to use.
Which brings me back to, can't you just probe for it?
Segher
^ permalink raw reply
* [PATCH 1/4] bootwrapper: Add CONFIG_DEVICE_TREE
From: Scott Wood @ 2007-04-16 23:24 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
This provides a way to tell the bootwrapper makefile which device tree to
include by default. The wrapper can still be invoked standalone to wrap
with a different device tree without reconfiguring the kernel, if that is
desired.
The user will only be asked to provide a device tree if the platform
selects CONFIG_WANT_DEVICE_TREE.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
Note that Kumar has said he's in favor of always asking (at least when
not on true OF) so that the dts name can be used from external build
scripts. I'm not convinced that that's a good idea (after all, such
scripts will need other parameters (e.g. the u-boot target name) which
definitely should not go in the kernel .config); however, I don't care
all that much whether you pull this patch or the previous version (which
asked unconditionally).
arch/powerpc/Kconfig | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 740892a..9fe636d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -162,6 +162,7 @@ config PPC_83xx
select FSL_SOC
select 83xx
select PPC_FPU
+ select WANT_DEVICE_TREE
config PPC_85xx
bool "Freescale 85xx"
@@ -591,6 +592,29 @@ config SECCOMP
If unsure, say Y. Only embedded should say N here.
+config WANT_DEVICE_TREE
+ bool
+ default n
+
+config DEVICE_TREE
+ string "Static device tree source file"
+ depends on WANT_DEVICE_TREE
+ help
+ This specifies the device tree source (.dts) file to be
+ compiled and included when building the bootwrapper. If a
+ relative filename is given, then it will be relative to
+ arch/powerpc/boot/dts. If you are not using the bootwrapper,
+ or do not need to build a dts into the bootwrapper, this
+ field is ignored.
+
+ For example, this is required when building a cuImage target
+ for an older U-Boot, which cannot pass a device tree itself.
+ Such a kernel will not work with a newer U-Boot that tries to
+ pass a device tree (unless you tell it not to). If your U-Boot
+ does not mention a device tree in "help bootm", then use the
+ cuImage target and specify a device tree here. Otherwise, use
+ the uImage target and leave this field blank.
+
endmenu
config ISA_DMA_API
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH 1/4 v2] powerpc: document max-speed and interface-type properties
From: Segher Boessenkool @ 2007-04-16 23:18 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20070416115729.292c10b1.kim.phillips@freescale.com>
> I don't need to know what type the PHY is, e.g. whether it's m88e11x1
> compatible or not, the phylib handles that.
You need to tell the phylib what kind of bus the PHY uses.
You can put "rgmii" or whatever in the "compatible" property
as well.
> If I were to put the properties in the PHY node, I wouldn't be able to
> describe a 1000Mbit/s capable UCC connected to a 100Mbit/s capable PHY,
> or vice versa.
Of course you can. The "compatible" in the enet node
implies it can do 1000Mbps; the "compatible" in the
PHY node implies it does 100Mbps.
Segher
^ permalink raw reply
* Re: [PATCH] [5/5] pasemi: GPIO MDIO of_platform driver
From: Arnd Bergmann @ 2007-04-16 23:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, paulus
In-Reply-To: <20070416063139.GC20319@lixom.net>
On Monday 16 April 2007, Olof Johansson wrote:
> +static int __devinit hack_init(void)
> +{
> +=A0=A0=A0=A0=A0=A0=A0struct platform_device *pdev;
> +
> +=A0=A0=A0=A0=A0=A0=A0pdev =3D platform_device_register_simple("gpio-mdio=
=2Dbitbang", 0, NULL, 0);
> +
> +=A0=A0=A0=A0=A0=A0=A0return 0;
> +}
> +late_initcall(hack_init);
Why do you need this? The name already suggests that you are aware that this
should be autoprobed, but it would be good to have a comment explaining
why you did it this way.
Arnd <><
^ permalink raw reply
* Re: Variable "current" in Linux kernel...
From: Andreas Schwab @ 2007-04-16 22:53 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D75A76F1@corpexc01.corp.networkrobots.com>
"Siva Prasad" <sprasad@bivio.net> writes:
> I would like to know where exactly the value of variable "current" gets
> changed.
In _switch (see arch/powerpc/kernel/entry_{32,64}.S). For ppc32, current
is always in r2.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Variable "current" in Linux kernel...
From: Phillip Lougher @ 2007-04-16 22:52 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D75A76F1@corpexc01.corp.networkrobots.com>
On 4/16/07, Siva Prasad <sprasad@bivio.net> wrote:
>
> I would like to know where exactly the value of variable "current" gets
> changed.
current points to the task_struct structure of the currently running
process. It, obviously, changes each time the scheduler schedules
another process.
>
>
> BTW=85 did any one tried before to run from a different location of memor=
y
> than the usual 0x00000000? What are the main problems you faced? I know t=
his
> is open ended question, but wanted to see if any one ever did that.
>
I changed the 2.4 PPC kernel to do this about 5 years ago (for
Zarlink). Most of the issues relate to the PPC specific code, all
functions which map from a va->pa, from a pte->va, and vice-versa have
to be changed. The early start up assembly code has to be aware the
kernel is not running at zero, specifically the code which creates the
initial TLB entries. As far as I can recall, only one line of non-PPC
specific code needed to be changed. It is, however, a difficult task
which requires careful auditing of the code, and obviously knowledge
of the vm and memory allocator systems.
Phillip
^ permalink raw reply
* Re: [PATCH] hvc_console polling mode timer backoff
From: Linas Vepstas @ 2007-04-16 21:59 UTC (permalink / raw)
To: Will Schmidt; +Cc: Olof Johansson, Milton Miller, ppcdev
In-Reply-To: <1176754943.28514.133.camel@farscape.rchland.ibm.com>
On Mon, Apr 16, 2007 at 03:22:23PM -0500, Will Schmidt wrote:
>
> (Not sure I prefer this over the other one, but will see what other
> commentary this generates...)
Its making me think about the color of the bicycle shed.
--linas
^ permalink raw reply
* Variable "current" in Linux kernel...
From: Siva Prasad @ 2007-04-16 21:56 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]
Hi,
I would like to know where exactly the value of variable "current" gets
changed.
Background:
I am trying to get Linux running on 32-bit PowerPC. However, I want to
get that running from address 1GB (0x40000000) as the starting memory,
and not the regular 0x00000000. When I am making this change, I found
that the value of "current" is getting messed up some where. I tried to
search unsuccessfully where it gets set. Appreciate any help.
BTW... did any one tried before to run from a different location of
memory than the usual 0x00000000? What are the main problems you faced?
I know this is open ended question, but wanted to see if any one ever
did that.
Thanks
Siva
[-- Attachment #2: Type: text/html, Size: 3354 bytes --]
^ permalink raw reply
* Re: Xilinx , Ml403, Linux And Money!
From: Roger Larsson @ 2007-04-16 21:10 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY115-W4270CF08F77CA41348714B2850@phx.gbl>
On Monday 05 March 2007 00:40, Mohammad Sadegh Sadri wrote:
> Finally we see montavista asking for your registration before allowing you
> to download the preview kit, and then their answer "you are not allowed to
> access the prev kit because .... ..... "
>
> I was expecting linux kernel source to be free .... But it seems that it is
> not free at all.
You should reread the GPL license!
No one is REQUIRED to GIVE ANYONE their source.
But as a customer you should get it:
1) If you get binaries for the kernel you should be able to get the source.
2) If you are an end user, you should be able to get the source
(Unless it is a binary independently developed from the kernel -
then it is a legal question to solve in a court...)
Ohh.. And the linux kernel IS free!
http://www.kernel.org/
http://www.denx.de/en/News/PressReleaseELDK41
/RogerL
^ permalink raw reply
* DHT walnut
From: [d]are [d]evil [c]oder, the-prince-of-flame @ 2007-04-16 21:17 UTC (permalink / raw)
To: linuxppc-embedded
hi,
i found a problem using a pci sound card in the DHT-WALNUT.
It has been correctly recognized by the kernel, the DMA feature (ppc405-dma) is setted, but the card is not working.
somebody says it is a bug, somebody says ppcboot solves the problem inizializing the pci in the correct way. I don't know, i'm using the uboot v1.1.4 and it is not working
also have a look to this
<> but i already thought so when i saw the "pci long" output
<> no BAR was assigned with an address
<> this was different some time ago
<> could be something changed in the last few months in the common pci support
<> i'll check with an ex-kollegue and let you know
<> this will take till beginning of next week though
<> hey, i just checked the source (sometimes helpful)
<> you just need to enable the host bridge configuration via an env variable
<> => setenv pciconfighost yes
<> then
<> => saveenv
<> => reset
<> after this reset the BAR1 will be configured:
<> => pci long
<> Scanning PCI devices on bus 0
<> Found PCI device 00.00.00:
<> vendor ID = 0x1014
<> device ID = 0x0156
<> command register = 0x0006
<> status register = 0x2210
<> revision ID = 0x01
<> class code = 0x0b (Processor)
<> sub class code = 0x20
<> programming interface = 0x00
<> cache line = 0x00
<> latency time = 0x87
<> header type = 0x00
<> BIST = 0x00
<> base address 0 = 0x00000000
<> base address 1 = 0x80000008
could you help me to understand how to plug a soundcard ?
:)
best regards
--
i've pulled the plug
insert coins, please
^ permalink raw reply
* Please pull from 'kconfig' branch of powerpc for 2.6.22
From: Kumar Gala @ 2007-04-16 21:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'kconfig' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git kconfig
No one seemed to have any issues with these changes.
to receive the following updates:
arch/powerpc/Kconfig | 47 +++++--------------------
arch/powerpc/platforms/82xx/Kconfig | 50 ++++++++------------------
arch/powerpc/platforms/83xx/Kconfig | 6 ---
arch/powerpc/platforms/85xx/Kconfig | 29 ++-------------
arch/powerpc/platforms/86xx/Kconfig | 18 +--------
arch/powerpc/platforms/8xx/Kconfig | 67 ++++++++++++++++--------------------
arch/powerpc/platforms/Kconfig | 58 ++++++++++++++++++++++++-------
7 files changed, 109 insertions(+), 166 deletions(-)
Kumar Gala (7):
[POWERPC] Ensure platform CONFIG options have correct dependencies
[POWERPC] Convert 86xx platform to unified platform Kconfig
[POWERPC] Convert 83xx platform to unified platform Kconfig
[POWERPC] Convert 82xx platform to unified platform Kconfig
[POWERPC] Convert 8xx platform to unified platform Kconfig
[POWERPC] Convert 85xx platform to unified platform Kconfig
[POWERPC] Miscellaneous arch/powerpc Kconfig and platform/Kconfig cleanup
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 740892a..26713da 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -192,7 +192,6 @@ config 44x
bool "AMCC 44x"
select PPC_DCR_NATIVE
-
config E200
bool "Freescale e200"
@@ -375,14 +374,6 @@ source "init/Kconfig"
source "arch/powerpc/platforms/Kconfig"
-source arch/powerpc/platforms/embedded6xx/Kconfig
-source arch/powerpc/platforms/4xx/Kconfig
-source arch/powerpc/platforms/82xx/Kconfig
-source arch/powerpc/platforms/83xx/Kconfig
-source arch/powerpc/platforms/85xx/Kconfig
-source arch/powerpc/platforms/86xx/Kconfig
-source arch/powerpc/platforms/8xx/Kconfig
-
menu "Kernel options"
config HIGHMEM
@@ -464,15 +455,6 @@ config CRASH_DUMP
Don't change this unless you know what you are doing.
-config EMBEDDEDBOOT
- bool
- depends on 8xx || 8260
- default y
-
-config PC_KEYBOARD
- bool "PC PS/2 style Keyboard"
- depends on 4xx || CPM2
-
config PPCBUG_NVRAM
bool "Enable reading PPCBUG NVRAM during boot" if PPLUS || LOPEC
default y if PPC_PREP
@@ -486,7 +468,6 @@ config IRQ_ALL_CPUS
CPU. Generally saying Y is safe, although some problems have been
reported with SMP Power Macintoshes with this option enabled.
-
config NUMA
bool "NUMA support"
depends on PPC64
@@ -536,10 +517,10 @@ config PPC_64K_PAGES
depends on PPC64
help
This option changes the kernel logical page size to 64k. On machines
- without processor support for 64k pages, the kernel will simulate
- them by loading each individual 4k page on demand transparently,
- while on hardware with such support, it will be used to map
- normal application pages.
+ without processor support for 64k pages, the kernel will simulate
+ them by loading each individual 4k page on demand transparently,
+ while on hardware with such support, it will be used to map
+ normal application pages.
config SCHED_SMT
bool "SMT (Hyperthreading) scheduler support"
@@ -619,24 +600,17 @@ config GENERIC_ISA_DMA
depends on PPC64 || POWER4 || 6xx && !CPM2
default y
-config MPIC
- bool
- default n
-
-config MPIC_WEIRD
- bool
- default n
-
-config PPC_I8259
- bool
- default n
-
config PPC_INDIRECT_PCI
bool
depends on PCI
default y if 40x || 44x
default n
+config PPC_INDIRECT_PCI_BE
+ bool
+ depends PPC_INDIRECT_PCI
+ default n
+
config EISA
bool
@@ -857,11 +831,10 @@ source "fs/Kconfig"
source "arch/powerpc/sysdev/qe_lib/Kconfig"
-
source "lib/Kconfig"
menu "Instrumentation Support"
- depends on EXPERIMENTAL
+ depends on EXPERIMENTAL
source "arch/powerpc/oprofile/Kconfig"
diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/platforms/82xx/Kconfig
index 4110716..de7fce9 100644
--- a/arch/powerpc/platforms/82xx/Kconfig
+++ b/arch/powerpc/platforms/82xx/Kconfig
@@ -1,56 +1,36 @@
-menu "Platform support"
- depends on PPC_82xx
-
choice
- prompt "Machine Type"
- default MPC82xx_ADS
+ prompt "Machine Type"
+ depends on PPC_82xx
+ default MPC82xx_ADS
config MPC82xx_ADS
- bool "Freescale MPC82xx ADS"
- select DEFAULT_UIMAGE
- select PQ2ADS
- select 8272
- select 8260
- select CPM2
- select FSL_SOC
- help
- This option enables support for the MPC8272 ADS board
+ bool "Freescale MPC82xx ADS"
+ select DEFAULT_UIMAGE
+ select PQ2ADS
+ select 8272
+ select 8260
+ select FSL_SOC
+ help
+ This option enables support for the MPC8272 ADS board
endchoice
config PQ2ADS
bool
- depends on ADS8272
- default y
-
-config ADS8272
- bool
+ default n
config 8260
- bool "CPM2 Support" if WILLOW
+ bool
depends on 6xx
- default y if PQ2FADS
+ select CPM2
help
- The MPC8260 is a typical embedded CPU made by Motorola. Selecting
+ The MPC8260 is a typical embedded CPU made by Freescale. Selecting
this option means that you wish to build a kernel for a machine with
an 8260 class CPU.
config 8272
bool
- depends on 6xx
- default y if ADS8272
select 8260
help
The MPC8272 CPM has a different internal dpram setup than other CPM2
devices
-
-config CPM2
- bool
- depends on 8260 || MPC8560 || MPC8555
- default y
- help
- The CPM2 (Communications Processor Module) is a coprocessor on
- embedded CPUs made by Motorola. Selecting this option means that
- you wish to build a kernel for a machine with a CPM2 coprocessor
- on it (826x, 827x, 8560).
-endmenu
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index 2a23392..19cafdf 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -1,8 +1,6 @@
-menu "Platform support"
- depends on PPC_83xx
-
choice
prompt "Machine Type"
+ depends on PPC_83xx
default MPC834x_MDS
config MPC8313_RDB
@@ -77,5 +75,3 @@ config PPC_MPC836x
select PPC_UDBG_16550
select PPC_INDIRECT_PCI
default y if MPC836x_MDS
-
-endmenu
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 124e2c5..c79ae86 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -1,8 +1,6 @@
-menu "Platform support"
- depends on PPC_85xx
-
choice
prompt "Machine Type"
+ depends on PPC_85xx
default MPC8540_ADS
config MPC8540_ADS
@@ -46,33 +44,14 @@ config MPC8540
config MPC8560
bool
- select PPC_INDIRECT_PCI
+ select CPM2
default y if MPC8560_ADS
config MPC85xx
bool
select PPC_UDBG_16550
select PPC_INDIRECT_PCI
+ select PPC_INDIRECT_PCI_BE
+ select MPIC
default y if MPC8540_ADS || MPC85xx_CDS || MPC8560_ADS \
|| MPC85xx_MDS || MPC8544_DS
-
-config PPC_INDIRECT_PCI_BE
- bool
- depends on PPC_85xx
- default y
-
-config MPIC
- bool
- default y
-
-config CPM2
- bool
- depends on MPC8560
- default y
- help
- The CPM2 (Communications Processor Module) is a coprocessor on
- embedded CPUs made by Motorola. Selecting this option means that
- you wish to build a kernel for a machine with a CPM2 coprocessor
- on it.
-
-endmenu
diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
index 0c70944..d1bcff5 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -1,8 +1,6 @@
-menu "Platform Support"
- depends on PPC_86xx
-
choice
prompt "Machine Type"
+ depends on PPC_86xx
default MPC8641_HPCN
config MPC8641_HPCN
@@ -14,20 +12,10 @@ config MPC8641_HPCN
endchoice
-
config MPC8641
bool
select PPC_INDIRECT_PCI
+ select PPC_INDIRECT_PCI_BE
select PPC_UDBG_16550
+ select MPIC
default y if MPC8641_HPCN
-
-config MPIC
- bool
- default y
-
-config PPC_INDIRECT_PCI_BE
- bool
- depends on PPC_86xx
- default y
-
-endmenu
diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig
index beea683..39bb8c5 100644
--- a/arch/powerpc/platforms/8xx/Kconfig
+++ b/arch/powerpc/platforms/8xx/Kconfig
@@ -1,6 +1,3 @@
-menu "Platform support"
- depends on PPC_8xx
-
config FADS
bool
@@ -9,6 +6,7 @@ config CPM1
choice
prompt "8xx Machine Type"
+ depends on PPC_8xx
depends on 8xx
default MPC885ADS
@@ -36,38 +34,36 @@ config MPC885ADS
endchoice
menu "Freescale Ethernet driver platform-specific options"
- depends on (FS_ENET && MPC885ADS)
-
- config MPC8xx_SECOND_ETH
- bool "Second Ethernet channel"
- depends on MPC885ADS
- default y
- help
- This enables support for second Ethernet on MPC885ADS and MPC86xADS boards.
- The latter will use SCC1, for 885ADS you can select it below.
-
- choice
- prompt "Second Ethernet channel"
- depends on MPC8xx_SECOND_ETH
- default MPC8xx_SECOND_ETH_FEC2
-
- config MPC8xx_SECOND_ETH_FEC2
- bool "FEC2"
- depends on MPC885ADS
- help
- Enable FEC2 to serve as 2-nd Ethernet channel. Note that SMC2
- (often 2-nd UART) will not work if this is enabled.
-
- config MPC8xx_SECOND_ETH_SCC3
- bool "SCC3"
- depends on MPC885ADS
- help
- Enable SCC3 to serve as 2-nd Ethernet channel. Note that SMC1
- (often 1-nd UART) will not work if this is enabled.
-
- endchoice
+ depends on (FS_ENET && MPC885ADS)
-endmenu
+ config MPC8xx_SECOND_ETH
+ bool "Second Ethernet channel"
+ depends on MPC885ADS
+ default y
+ help
+ This enables support for second Ethernet on MPC885ADS and MPC86xADS boards.
+ The latter will use SCC1, for 885ADS you can select it below.
+
+ choice
+ prompt "Second Ethernet channel"
+ depends on MPC8xx_SECOND_ETH
+ default MPC8xx_SECOND_ETH_FEC2
+
+ config MPC8xx_SECOND_ETH_FEC2
+ bool "FEC2"
+ depends on MPC885ADS
+ help
+ Enable FEC2 to serve as 2-nd Ethernet channel. Note that SMC2
+ (often 2-nd UART) will not work if this is enabled.
+
+ config MPC8xx_SECOND_ETH_SCC3
+ bool "SCC3"
+ depends on MPC885ADS
+ help
+ Enable SCC3 to serve as 2-nd Ethernet channel. Note that SMC1
+ (often 1-nd UART) will not work if this is enabled.
+
+ endchoice
endmenu
@@ -98,7 +94,7 @@ config 8xx_CPU6
require workarounds for Linux (and most other OSes to work). If you
get a BUG() very early in boot, this might fix the problem. For
more details read the document entitled "MPC860 Family Device Errata
- Reference" on Motorola's website. This option also incurs a
+ Reference" on Freescale's website. This option also incurs a
performance hit.
If in doubt, say N here.
@@ -135,4 +131,3 @@ config UCODE_PATCH
depends on !NO_UCODE_PATCH
endmenu
-
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 161ab79..86be82a 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -1,8 +1,8 @@
menu "Platform support"
- depends on PPC64 || CLASSIC32
choice
prompt "Machine type"
+ depends on PPC64 || CLASSIC32
default PPC_MULTIPLATFORM
config PPC_MULTIPLATFORM
@@ -25,14 +25,6 @@ config APUS
<http://linux-apus.sourceforge.net/>.
endchoice
-config QUICC_ENGINE
- bool
- help
- The QUICC Engine (QE) is a new generation of communications
- coprocessors on Freescale embedded CPUs (akin to CPM in older chips).
- Selecting this option means that you wish to build a kernel
- for a machine with a QE coprocessor.
-
source "arch/powerpc/platforms/pseries/Kconfig"
source "arch/powerpc/platforms/iseries/Kconfig"
source "arch/powerpc/platforms/chrp/Kconfig"
@@ -41,9 +33,16 @@ source "arch/powerpc/platforms/powermac/Kconfig"
source "arch/powerpc/platforms/prep/Kconfig"
source "arch/powerpc/platforms/maple/Kconfig"
source "arch/powerpc/platforms/pasemi/Kconfig"
-source arch/powerpc/platforms/celleb/Kconfig
-source arch/powerpc/platforms/ps3/Kconfig
-source arch/powerpc/platforms/cell/Kconfig
+source "arch/powerpc/platforms/celleb/Kconfig"
+source "arch/powerpc/platforms/ps3/Kconfig"
+source "arch/powerpc/platforms/cell/Kconfig"
+source "arch/powerpc/platforms/8xx/Kconfig"
+source "arch/powerpc/platforms/82xx/Kconfig"
+source "arch/powerpc/platforms/83xx/Kconfig"
+source "arch/powerpc/platforms/85xx/Kconfig"
+source "arch/powerpc/platforms/86xx/Kconfig"
+source "arch/powerpc/platforms/embedded6xx/Kconfig"
+#source "arch/powerpc/platforms/4xx/Kconfig
config PPC_NATIVE
bool
@@ -68,6 +67,18 @@ config XICS
bool
default y
+config MPIC
+ bool
+ default n
+
+config MPIC_WEIRD
+ bool
+ default n
+
+config PPC_I8259
+ bool
+ default n
+
config U3_DART
bool
depends on PPC_MULTIPLATFORM && PPC64
@@ -137,6 +148,9 @@ config GENERIC_IOMAP
bool
default n
+menu "CPU Frequency support"
+ depends on PPC64 || CLASSIC32
+
source "drivers/cpufreq/Kconfig"
config CPU_FREQ_PMAC
@@ -155,6 +169,7 @@ config CPU_FREQ_PMAC64
help
This adds support for frequency switching on Apple iMac G5,
and some of the more recent desktop G5 machines as well.
+endmenu
config PPC601_SYNC_FIX
bool "Workarounds for PPC601 bugs"
@@ -172,7 +187,7 @@ config PPC601_SYNC_FIX
config TAU
bool "On-chip CPU temperature sensor support"
- depends on 6xx
+ depends on CLASSIC32
help
G3 and G4 processors have an on-chip temperature sensor called the
'Thermal Assist Unit (TAU)', which, in theory, can measure the on-die
@@ -214,4 +229,21 @@ config TAU_AVERAGE
If in doubt, say N here.
+config QUICC_ENGINE
+ bool
+ help
+ The QUICC Engine (QE) is a new generation of communications
+ coprocessors on Freescale embedded CPUs (akin to CPM in older chips).
+ Selecting this option means that you wish to build a kernel
+ for a machine with a QE coprocessor.
+
+config CPM2
+ bool
+ default n
+ help
+ The CPM2 (Communications Processor Module) is a coprocessor on
+ embedded CPUs made by Freescale. Selecting this option means that
+ you wish to build a kernel for a machine with a CPM2 coprocessor
+ on it (826x, 827x, 8560).
+
endmenu
^ permalink raw reply related
* Re: [PATCH] hvc_console polling mode timer backoff
From: Will Schmidt @ 2007-04-16 20:22 UTC (permalink / raw)
To: Milton Miller; +Cc: Olof Johansson, ppcdev
In-Reply-To: <97762565fcdccbf85d1d04cd055b1197@bga.com>
On Sat, 2007-14-04 at 14:42 -0500, Milton Miller wrote:
> Michael Ellerman wrote:
> Did you consider making MAX_TIMEOUT a module parameter? It could then
> be changed at runtime through /sys/modules/.
Yup, considered that.
Decided against it, for no reason other than "keeping it simple". Not
sure that extra function does more good or bad.
Who really wants the ability to tune their console timeout value
anyway? :-) hrm, maybe thats a silly question.
For discussion, I'll attach a version of the patch that adds a sysfs
parm for setting max_timeout. I'm not 100% on the S_IR* parms in the
param call, but verified that it works and it's sufficient to illustrate
what we're discussing.
A downside is that it does no input checking, so if a useradmin wishes
to wait a very long time for their console, they can do so. In this
implementation, it is worth noting that the current timeout value (say
100000), will not automatically decrease if a smaller max_timeout value
(say 500) is entered. The timeout only gets reset (to MIN_TIMEOUT)
during console input.
> Keeping MIN_TIMEOUT a define is okay with me, and the code will
> naturally ignore max < MIN. It may overshoot timeout by 1/64th.
> I doubt we would worry about the overflow case, because by then
> the timeout would have been quite long, and the user would like
> it to be short again.
You mean like ending up with a timeout of 2016 when max_timeout is 2000?
I think we're OK with that. :-)
> milton
>
(Not sure I prefer this over the other one, but will see what other
commentary this generates...)
-Will
--
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index a0a88aa..ba4c3cc 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -47,8 +47,6 @@ #include "hvc_console.h"
#define HVC_MAJOR 229
#define HVC_MINOR 0
-#define TIMEOUT (10)
-
/*
* Wait this long per iteration while trying to push buffered data to the
* hypervisor before allowing the tty to complete a close operation.
@@ -550,6 +548,23 @@ static int hvc_chars_in_buffer(struct tt
return hp->n_outbuf;
}
+/*
+ * timeout will vary between the MIN and max_timeout values here. By default
+ * and during console activity we will use a default MIN_TIMEOUT of 10. When
+ * the console is idle, we increase the timeout value on each pass through
+ * msleep until we reach the max. This may be noticeable as a brief (average
+ * one second) delay on the console before the console responds to input when
+ * there has been no input for some time. The max_timeout defaults to 2000, but
+ * can be set via /sys/module/hvc_console/parameters/max_timeout.
+ */
+#define MIN_TIMEOUT (10)
+static u32 max_timeout = 2000;
+static u32 timeout = MIN_TIMEOUT;
+
+module_param_named(max_timeout,max_timeout,uint,S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(max_timeout,
+ "Max for timer delay used by hvc_console in polling mode. (default: 2000)");
+
#define HVC_POLL_READ 0x00000001
#define HVC_POLL_WRITE 0x00000002
@@ -642,9 +657,14 @@ #endif /* CONFIG_MAGIC_SYSRQ */
bail:
spin_unlock_irqrestore(&hp->lock, flags);
- if (read_total)
+ if (read_total) {
+ /* Activity is occurring, so reset the polling backoff value to
+ a minimum for performance. */
+ timeout = MIN_TIMEOUT;
+
tty_flip_buffer_push(tty);
-
+ }
+
return poll_mask;
}
@@ -688,8 +708,12 @@ int khvcd(void *unused)
if (!hvc_kicked) {
if (poll_mask == 0)
schedule();
- else
- msleep_interruptible(TIMEOUT);
+ else {
+ if (timeout < max_timeout)
+ timeout += (timeout >> 6) + 1;
+
+ msleep_interruptible(timeout);
+ }
}
__set_current_state(TASK_RUNNING);
} while (!kthread_should_stop());
^ permalink raw reply related
* Re: DMA Puzzle
From: Kelsey Dawes @ 2007-04-16 19:35 UTC (permalink / raw)
To: Charles Krinke
Cc: Randy Brown, Vahid Fereydounkolahi, Chris Carlson,
linuxppc-embedded
In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06A1D2@MERCURY.inside.istor.com>
On Thu, Apr 12, 2007 at 04:23:00PM -0700, Charles Krinke wrote:
> My apologies for the complexity of this e-mail but DMA seems to be a
> complex subject. Thanks to Ed.S a while back, I have DMA working fine
> from U-Boot, but I am having a problem in Linux with the 8541 processor
> using the 2.6.17.11 kernel. I need to DMA through an outbound address
> translation window setup at 0x8800_0000 and the chip I am DMA'ing to is
> responding to 64bit DAC (Dual Address Cycles) and its memory is setup
<SNIP>
Hi Charles - have you checked the device errata for 8541? I do not have the details in front of me, but do recall several items specific to DMA signal to complete DMA transaction.
Worth a look anyway -
Kelsey
^ permalink raw reply
* Re: [PATCH] hvc_console polling mode timer backoff
From: Will Schmidt @ 2007-04-16 19:34 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1176644012.5422.3.camel@concordia.ozlabs.ibm.com>
On Sun, 2007-15-04 at 23:33 +1000, Michael Ellerman wrote:
> On Fri, 2007-04-13 at 14:11 -0500, Will Schmidt wrote:
> > On Fri, 2007-13-04 at 17:47 +1000, Michael Ellerman wrote:
> >
> > Is this part temporary for your graphing, or think it's something that
> > should go in?
>
> No that's just debug foobar I used for the graphs, I'll send a cleaned
> up version during the week if you don't beat me to it.
I'll do it, just waiting to see if I should rework it to include a sys
interface or not..
> Time to get a blag! ;)
yup.
> cheers
>
-Will
^ permalink raw reply
* Re: [PATCH 1/4 v2] powerpc: document max-speed and interface-type properties
From: Andy Fleming @ 2007-04-16 18:40 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <ba8618e3bd28389b66262e549387ac8d@kernel.crashing.org>
On Apr 16, 2007, at 10:47, Segher Boessenkool wrote:
>
>> I believe the question is about where the information should truly
>> live.
>
> Yeah.
Agreed
>
>> It would seem to be more of a property of the phy than of the enet
>> controller.
>
> Yep. The whole reason why any property is wanted here is
> to say what type the PHY is, as the enet controller can
> be attached to several kinds. And what type the PHY is
> belongs in the PHY node, obviously. In its "compatible"
> property to be exact.
It's not saying what type the PHY is, though. It's describing the
connection. The PHY is just as flexible wrt connection type as the
ethernet controller. This is actually a property of the board. In
some cases its a fixed property of the board. In some cases it's
changeable through dip switches, or even through software.
Ethernet controllers need to know what the connection is so they can
establish a data connection with the PHYs
PHYs need to know what the connection is so they can establish a data
connection with the ethernet controllers.
There is equal flexibility on both sides, and I think the choice of
where to put this information is fairly arbitrary. The reason for
choosing the ethernet controller in this case has to do with the flow
of information.
1) The driver tells the PHY what interface to use
2) The ethernet controller is the endpoint of this connection which
is accessible by everyone else. IE data is not sent through PHYs by
any means but through the ethernet controller, and data is not
received from PHYs by any means but through the ethernet controller.
3) The UCC needs to be told the connection type, because it does not
have logic to detect it on its own.
The truth is, this is a somewhat intractable problem because of the
myriad possibilities for how board designers can hook up ethernet
controllers to PHYs. One can envision scenarios where controllers
can hook up to multiple PHYs, each of one fixed type. One can
envision scenarios where multiple controllers are hooked up to one
PHY, and each of the controllers can use different connections. If
we put the information in the PHY node, we allow for the first
scenario, but not the second. If we put it in the ethernet node, we
reverse that situation. In either case, we'd currently have to
modify our dts to specify which PHY we want to use.
Andy
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: document max-speed and interface-type properties
From: Kumar Gala @ 2007-04-16 18:19 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev
In-Reply-To: <2C4757AA-5302-4832-91BB-9B102A60FA5C@freescale.com>
On Apr 16, 2007, at 12:28 PM, Andy Fleming wrote:
>
> On Apr 12, 2007, at 02:06, Segher Boessenkool wrote:
>
>>> + - max-speed : The maximum speed supported by the controller (in
>>> Mbit/s)
>>> + - interface-type : a string naming the controller/PHY interface
>>> type,
>>> + i.e., one of "mii", "gmii", "sgmii", "tbi", "rmii",
>>> "rgmii", or
>>> "rtbi".
>>
>> This information should be in the PHY node, instead.
>> Both property values would normally be implied by
>> "compatible" in that node (and this node, for the
>> max speed).
>
>
> Why should it be in the PHY node? It's not a property of the PHY.
> It's a property of the connection between the PHY and the ethernet
> controller. The PHY Lib API has the ethernet provide the connection
> type as an argument in the phy_connect() call, so it makes sense for
> this property to reside in the ethernet node. I think ethernet
> drivers typically have the most power in this situation, and so it's
> best (IMHO) to let the ethernet node provide this information.
The interface type should be a property of the phy because its a
property of the physical 'phy' device on the board.
- k
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: document max-speed and interface-type properties
From: Andy Fleming @ 2007-04-16 17:28 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <377816979b46808cd11a12640ceabb14@kernel.crashing.org>
On Apr 12, 2007, at 02:06, Segher Boessenkool wrote:
>> + - max-speed : The maximum speed supported by the controller (in
>> Mbit/s)
>> + - interface-type : a string naming the controller/PHY interface
>> type,
>> + i.e., one of "mii", "gmii", "sgmii", "tbi", "rmii", "rgmii", or
>> "rtbi".
>
> This information should be in the PHY node, instead.
> Both property values would normally be implied by
> "compatible" in that node (and this node, for the
> max speed).
Why should it be in the PHY node? It's not a property of the PHY.
It's a property of the connection between the PHY and the ethernet
controller. The PHY Lib API has the ethernet provide the connection
type as an argument in the phy_connect() call, so it makes sense for
this property to reside in the ethernet node. I think ethernet
drivers typically have the most power in this situation, and so it's
best (IMHO) to let the ethernet node provide this information.
Andy
^ permalink raw reply
* Re: [PATCH] hvc_console polling mode timer backoff
From: Linas Vepstas @ 2007-04-16 17:03 UTC (permalink / raw)
To: Milton Miller; +Cc: Olof Johansson, ppcdev
In-Reply-To: <97762565fcdccbf85d1d04cd055b1197@bga.com>
On Sat, Apr 14, 2007 at 02:42:02PM -0500, Milton Miller wrote:
>
> Did you consider making MAX_TIMEOUT a module parameter? It could then
> be changed at runtime through /sys/modules/.
There's a philosophy (that I have warmed up to over time) that
says that too much kernel configurability is a bad thing.
Less configurability makes problems easier to debug: you don't
have to worry about:
-- bugs that occur for only certain parameter settings
-- some dang-fool user/sysadmin setting the timout to
1000 seconds (mistaking seconds for milliseconds) and
then reporting a bug.
-- the latest fedora core having some udev script that
finds the hvc console and slaps some crazy values into it.
Surely, we have all known that bright-eyed, bushy-tailed
developer who, when they ask you for help with a bug,
your first questions are "did you mess with it?" and
"which part did you mess with?"
--linas
^ permalink raw reply
* Re: [PATCH 1/4 v2] powerpc: document max-speed and interface-type properties
From: Kim Phillips @ 2007-04-16 16:57 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <ba8618e3bd28389b66262e549387ac8d@kernel.crashing.org>
On Mon, 16 Apr 2007 17:47:18 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> >>>> Since ucc_geth is being migrated to use the phylib, the existing
> >>>> (undocumented) 'interface' property is being deprecated in favour
> >>>> of unconjoined variations 'max-speed' and 'interface-type'.
> >>>
> >>> Again, please explain why this information shouldn't
> >>> be in the PHY node instead?
> >>>
> >>
> >> Strictly speaking, it should be neither in the UCC node nor the PHY
> >> node, as it describes the connection between the two, but..
>
> Connections are never described with separate nodes in
> the device tree.
>
> >> the UCC driver utilizes the data itself; the UCC, unlike other network
> >> controllers, does not provide interface data in its programming model.
>
> I have no idea what this means?
The UCC is a direct consumer of the values of the properties.
> >> the phy drivers are not of_ drivers. Porting phylib drivers to be of_
> >> drivers would break phylib for non-OF arches, e.g. x86.
> >
> > Nothing stops the code in the UCC driver from grabbing the phy device
> > node and pulling the information out if it.
>
> Quite so. This isn't "bad style" either, it is a perfectly
> normal thing to do.
>
> > I believe the question is about where the information should truly
> > live.
>
> Yeah.
>
> > It would seem to be more of a property of the phy than of the enet
> > controller.
> Yep. The whole reason why any property is wanted here is
> to say what type the PHY is, as the enet controller can
> be attached to several kinds. And what type the PHY is
> belongs in the PHY node, obviously. In its "compatible"
> property to be exact.
>
I don't need to know what type the PHY is, e.g. whether it's m88e11x1
compatible or not, the phylib handles that.
If I were to put the properties in the PHY node, I wouldn't be able to
describe a 1000Mbit/s capable UCC connected to a 100Mbit/s capable PHY,
or vice versa.
Kim
^ permalink raw reply
* Re: [RFC] Xilinx SystemACE device driver
From: Andrei Konovalov @ 2007-04-16 16:53 UTC (permalink / raw)
To: Grant Likely
Cc: Peter Korsgaard, Stefan Roese, Rick Moleres, linuxppc-embedded
In-Reply-To: <528646bc0704160933o76861f6cqaeac768415f8adb8@mail.gmail.com>
Grant Likely wrote:
> On 4/16/07, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
>> Hi Grant,
>>
>> Grant Likely wrote:
>> > Add support for block device access to the Xilinx SystemACE Compact
>> > flash interface
>>
>> Does the driver support 8-bit bus_width?
>>
>> Just gave the driver a try on ML300, and my first attempt failed.
>> Wonder if it's me having done something wrong, or something the driver
>> doesn't
>> handle yet.
>
> Doesn't handle it yet, you'll need to add 8-bit access macros to the
> top of the file.
OK. Thanks!
Will try that.
Thanks,
Andrei
> Cheers,
> g.
>
^ permalink raw reply
* Re: Mr Grant Likely's New Patches for 2.6 Kernel and Xilinx FPGA ( Virtex-4 & Virtex-2
From: Andrei Konovalov @ 2007-04-16 16:51 UTC (permalink / raw)
To: Grant Likely; +Cc: Linux PPC, Mohammad Sadegh Sadri
In-Reply-To: <528646bc0704160926i73c7976ree34564a113b3caf@mail.gmail.com>
Grant Likely wrote:
> On 4/16/07, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
>> Grant Likely wrote:
>> > No, I did not include TEMAC support. However, I will publish my git
>> > tree tomorrow which will include the TEMAC driver.
>>
>>
>> Seems the TEMAC driver is not on your git server yet. Hence the
>> questions.
>> Guess this is PLB TEMAC version 3.00a as you wrote auto negotiation is
>> supported.
>
> yup
>
>> Is your driver based on the one by Xilinx (the one from EDK 8.2.02 and
>> the update posted by Rick Moleres)?
>
> Yup, it's just the adapter.c file that Rick posted plus some fixups to
> get it to compile in my tree. Nothing really exciting. I'm very
> interested in the phylib work that you've done. I hope to take a look
> at that in the next day or so.
The feedback is very welcome.
Mostly was trying to use what is already in the kernel, and not to reinvent
the wheel.
I wouldn't say I've completely done with it.
Few SGDMA related ioctls to add (should be fairly straightforward).
And to check the advertised capabilities - as I wrote in the previous
posting, it looks like the driver stops advertising 1000Mbits at some
point (after turning auto negotiation off, switching to the lower speeds,
and trying to go back to 1000Mbits).
> I'm only publishing my tree as a
> convienient starting point for those who need it.
>
> Ideally, I'd like to look at doing a full rewrite so it's in a
> condition acceptable for mainline, but I don't have time for that at
> the moment.
I am not certain if the "linux adapter plus the OS independent code"
could easily be accepted (provided that the OS independent code is
reformatted as much as possible to fit into the community).
Afraid complete rewrite is fairly large effort, and, moreover, so far PLB TEMAC
has been significantly changing from one EDK release to the next. So
one could have to rewrite considerable parts of the driver every EDK release.
Would be nice to reuse the man-hours Xilinx put in their OS indpendent code.
Thanks,
Andrei
> Cheers,
> g.
>
^ permalink raw reply
* Re: [RFC] Xilinx SystemACE device driver
From: Grant Likely @ 2007-04-16 16:33 UTC (permalink / raw)
To: Andrei Konovalov
Cc: Peter Korsgaard, Stefan Roese, Rick Moleres, linuxppc-embedded
In-Reply-To: <4623A523.3040705@ru.mvista.com>
On 4/16/07, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
> Hi Grant,
>
> Grant Likely wrote:
> > Add support for block device access to the Xilinx SystemACE Compact
> > flash interface
>
> Does the driver support 8-bit bus_width?
>
> Just gave the driver a try on ML300, and my first attempt failed.
> Wonder if it's me having done something wrong, or something the driver doesn't
> handle yet.
Doesn't handle it yet, you'll need to add 8-bit access macros to the
top of the file.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox