* Re: [POWERPC 03/15] [POWERPC] TQM5200 board support
From: Scott Wood @ 2007-10-17 15:33 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4715F51D.2060000@semihalf.com>
Marian Balakowicz wrote:
> Scott Wood wrote:
>>> +void tqm5200_show_cpuinfo(struct seq_file *m)
>>> +{
>>> + struct device_node* np = of_find_all_nodes(NULL);
>>> + const char *model = NULL;
>>> +
>>> + if (np)
>>> + model = of_get_property(np, "model", NULL);
>>> +
>>> + seq_printf(m, "vendor\t\t: Freescale Semiconductor\n");
>>> + seq_printf(m, "machine\t\t: %s\n", model ? model : "unknown");
>>> +
>>> + of_node_put(np);
>>> +}
>> Get rid of this.
>
> Agree, that may be overhead in some cases. But there would be also
> cases where printing out a machine name would be informative. CM5200
> is one such example, there are several variants of the hw and platform
> name is too generic.
Maybe, though if we're going to do that it'd be better to just print
/model in the generic cpuinfo (or somewhere else generic). And there's
always /proc/device-tree/model...
-Scott
^ permalink raw reply
* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Sergei Shtylyov @ 2007-10-17 15:34 UTC (permalink / raw)
To: Tony Breeds
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel
In-Reply-To: <1190345162.620000.305760830507.qpush@thor>
Hello.
Tony Breeds wrote:
> With these functions implemented we cooperate better with the generic
> timekeeping code. This obsoletes the need for the timer sysdev as a bonus.
Aha, I'm seeing it's not merged to mainline yet! And this can't be merged
to -rt patch either, beucase -rt alsready has read_persistent_clock()
implemented since around 2.6.18-rt...
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> ---
> Patch set updated to powerpc/for-2.6.24
> * Compile tested for arch/powerpc/configs/*_defconfig
> * Booted on pSeries, iSeries, Cell and PS3
> arch/powerpc/Kconfig | 3 +
> arch/powerpc/kernel/time.c | 85 ++++++++++-------------------------
> arch/powerpc/sysdev/Makefile | 5 --
> arch/powerpc/sysdev/timer.c | 81 ---------------------------------
> 4 files changed, 29 insertions(+), 145 deletions(-)
>
> Index: working/arch/powerpc/Kconfig
> ===================================================================
> --- working.orig/arch/powerpc/Kconfig
> +++ working/arch/powerpc/Kconfig
> @@ -21,6 +21,9 @@ config MMU
> bool
> default y
>
> +config GENERIC_CMOS_UPDATE
> + def_bool y
> +
> config GENERIC_HARDIRQS
> bool
> default y
> Index: working/arch/powerpc/kernel/time.c
> ===================================================================
> --- working.orig/arch/powerpc/kernel/time.c
> +++ working/arch/powerpc/kernel/time.c
> @@ -881,12 +837,35 @@ void __init generic_calibrate_decr(void)
> #endif
> }
>
> -unsigned long get_boot_time(void)
> +int update_persistent_clock(struct timespec now)
> {
> struct rtc_time tm;
>
> - if (ppc_md.get_boot_time)
> - return ppc_md.get_boot_time();
> + if (!ppc_md.set_rtc_time)
> + return 0;
> +
> + to_tm(now.tv_sec + 1 + timezone_offset, &tm);
> + tm.tm_year -= 1900;
> + tm.tm_mon -= 1;
> +
> + return ppc_md.set_rtc_time(&tm);
> +}
> +
> +unsigned long read_persistent_clock(void)
> +{
> + struct rtc_time tm;
> + static int first = 1;
> +
> + /* XXX this is a litle fragile but will work okay in the short term */
> + if (first) {
> + first = 0;
> + if (ppc_md.time_init)
> + timezone_offset = ppc_md.time_init();
> +
> + /* get_boot_time() isn't guaranteed to be safe to call late */
> + if (ppc_md.get_boot_time)
> + return ppc_md.get_boot_time() -timezone_offset;
> + }
This looks incomplete.
> @@ -898,14 +877,10 @@ unsigned long get_boot_time(void)
> void __init time_init(void)
> {
> unsigned long flags;
> - unsigned long tm = 0;
> struct div_result res;
> u64 scale, x;
> unsigned shift;
>
> - if (ppc_md.time_init != NULL)
> - timezone_offset = ppc_md.time_init();
> -
> if (__USE_RTC()) {
> /* 601 processor: dec counts down by 128 every 128ns */
> ppc_tb_freq = 1000000000;
> @@ -980,19 +955,14 @@ void __init time_init(void)
> /* Save the current timebase to pretty up CONFIG_PRINTK_TIME */
> boot_tb = get_tb_or_rtc();
>
> - tm = get_boot_time();
> -
> write_seqlock_irqsave(&xtime_lock, flags);
Is there any sense of grabbing xtime_lock in time_init() when you've
implemented read_persistent_clock()?
>
> /* If platform provided a timezone (pmac), we correct the time */
> if (timezone_offset) {
> sys_tz.tz_minuteswest = -timezone_offset / 60;
> sys_tz.tz_dsttime = 0;
> - tm -= timezone_offset;
> }
>
> - xtime.tv_sec = tm;
> - xtime.tv_nsec = 0;
Huh? The 'xtime' should now be set by the *generic* timekeeping code using
read_persistent_clock() -- or else what's the point to implement the function? :-/
> @@ -1010,9 +980,6 @@ void __init time_init(void)
>
> time_freq = 0;
>
> - last_rtc_update = xtime.tv_sec;
> - set_normalized_timespec(&wall_to_monotonic,
> - -xtime.tv_sec, -xtime.tv_nsec);
> write_sequnlock_irqrestore(&xtime_lock, flags);
That 'xtime_lock' grabbing should be gone with this patch, and is not. NAK.
WBR, Sergei
^ permalink raw reply
* Re: linux-2.6.git: cannot build PS3 image
From: Scott Wood @ 2007-10-17 15:35 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <Pine.LNX.4.62.0710171523120.19421@pademelon.sonytel.be>
Geert Uytterhoeven wrote:
>> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
>> index 39b27e5..795f988 100755
>> --- a/arch/powerpc/boot/wrapper
>> +++ b/arch/powerpc/boot/wrapper
>> @@ -232,7 +232,7 @@ base=0x`${CROSS}nm "$ofile" | grep ' _start$' | cut -d' ' -f1`
>> entry=`${CROSS}objdump -f "$ofile" | grep '^start address ' | cut -d' ' -f3`
>>
>> if [ -n "$binary" ]; then
>> - mv "$ofile" "$ofile".elf
>> + cp "$ofile" "$ofile".elf
>> ${CROSS}objcopy -O binary "$ofile".elf "$ofile".bin
>> fi
>
> No comments?
That'd work in this case, though it'd probably be better to make the
$ofile be the end result that will boot on the ps3, and leave a suffix
on the intermediate files.
I wonder if we may be better off just making zImage a phony target and
removing the link altogether....
-Scott
^ permalink raw reply
* Re: PPC440EPx GPIO control help
From: David Hawkins @ 2007-10-17 16:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4715A9D9.6090308@mock.com>
Hi Dell,
If you do decide to look at kernel drivers, Jeff has sent you
code, and I also have a tutorial with example code you are
welcome to look at:
http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-723-Hawkins.pdf
http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz
Feel free to ask questions. I recall writing some test driver
code for the 440EP Yosemite board too. I'm just not sure where
I put it ... :)
Cheers,
Dave
^ permalink raw reply
* RE: Merge dtc
From: Stephen Neuendorffer @ 2007-10-17 16:22 UTC (permalink / raw)
To: Grant Likely, Paul Mackerras, Josh Boyer, linuxppc-dev
In-Reply-To: <fa686aa40710170615q3b69b13ch7a0038e9c6270729@mail.gmail.com>
=20
> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.or
> g=20
> [mailto:linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@o
zlabs.org] On Behalf Of Grant Likely
> Sent: Wednesday, October 17, 2007 6:15 AM
> To: Grant Likely; Paul Mackerras; Josh Boyer; linuxppc-dev@ozlabs.org
> Subject: Re: Merge dtc
>=20
> On 10/16/07, David Gibson <dwg@au1.ibm.com> wrote:
> > On Tue, Oct 16, 2007 at 07:17:01AM -0600, Grant Likely wrote:
> > > On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > > > This very large patch incorporates a copy of dtc into the kernel
> > > > source, in arch/powerpc/boot/dtc-src. This means that dtc is no
> > > > longer an external dependency to build kernels with=20
> configurations
> > > > which need a dtb file.
> > >
> > > Powerpc is probably not going to be the only user of dtc.=20
> Microblaze
> > > will be using it too. Can it be put somewhere more common?
> >
> > Well, I guess we can move it to scripts/ when microblaze=20
> starts using
> > it.
> >
> > Also, tell me more about this microblaze, I'm certainly=20
> interested in
> > new users of dtc...
>=20
> It's a 'soft processor'. Implemented in the fabric of an FPGA. It's
> a ucLinux target. Xilinx Virtex and Xilinx MicroBlaze targets share a
> lot of common devices.
>=20
> Cheers,
> g.
Basically, this partially works today. Most of the device information
can come out of a flat device tree, with most of the kernel code copied
straight from arch/powerpc. I'm still trying to sort out how some of
the architecture specific stuff can be extracted in a smart way. For
instance, the microblaze has configurable cache sizes, and may or may
not be available. Currently, this is #defined in the kernel, but I'd
like to get to the point where the same information is pulled out of a
device tree. My main quandry at the moment is that I'm not wild about
self-modifying code and I'm not sure if the extra overhead of
implementing it with conditionals is significant.
In any event, my plan is to get this into a reasonable state and then
post it here for review. The main reason why we went with flat device
trees for this was to get as much symmettry as possible between the soft
microblaze and the embedded ppc405 hard core in some FPGAs.
Steve
^ permalink raw reply
* Re: mpc 860 boot linux2.6.23 problem
From: Dan Malek @ 2007-10-17 16:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <47162AE7.80305@freescale.com>
On Oct 17, 2007, at 11:31 AM, Scott Wood wrote:
> I just pulled Wolfgang's latest u-boot tree, and I don't see any
> fdt or ft_ calls in cpu/mpc8xx, nor in any 8xx board that I recognize.
The STx XTc 885 is supported and was used for
a majority of the FT development in u-boot. I
just built it a few months ago, it worked fine, so
if it isn't working today the changes should be
minimal to bring it up to date.
Thanks.
-- Dan
^ permalink raw reply
* [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
From: Grant Likely @ 2007-10-17 16:36 UTC (permalink / raw)
To: Sven Luther, domen.puncer, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Only the MPC5200 needs this bug fix. MPC5200B is okay.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Sven, Domen;
Can you please test this patch?
Thanks,
g.
arch/powerpc/sysdev/bestcomm/bestcomm.c | 9 ++++++---
include/asm-powerpc/mpc52xx.h | 5 +++++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/bestcomm/bestcomm.c b/arch/powerpc/sysdev/bestcomm/bestcomm.c
index 48492a8..740ad73 100644
--- a/arch/powerpc/sysdev/bestcomm/bestcomm.c
+++ b/arch/powerpc/sysdev/bestcomm/bestcomm.c
@@ -269,6 +269,7 @@ bcom_engine_init(void)
int task;
phys_addr_t tdt_pa, ctx_pa, var_pa, fdt_pa;
unsigned int tdt_size, ctx_size, var_size, fdt_size;
+ u16 regval;
/* Allocate & clear SRAM zones for FDT, TDTs, contexts and vars/incs */
tdt_size = BCOM_MAX_TASKS * sizeof(struct bcom_tdt);
@@ -319,9 +320,11 @@ bcom_engine_init(void)
/* Init 'always' initiator */
out_8(&bcom_eng->regs->ipr[BCOM_INITIATOR_ALWAYS], BCOM_IPR_ALWAYS);
- /* Disable COMM Bus Prefetch, apparently it's not reliable yet */
- /* FIXME: This should be done on 5200 and not 5200B ... */
- out_be16(&bcom_eng->regs->PtdCntrl, in_be16(&bcom_eng->regs->PtdCntrl) | 1);
+ /* Disable COMM Bus Prefetch on the original 5200; it's broken */
+ if ((mfspr(SPRN_SVR) & MPC5200_SVR_MASK) == MPC5200_SVR) {
+ regval = in_be16(&bcom_eng->regs->PtdCntrl);
+ out_be16(&bcom_eng->regs->PtdCntrl, regval | 1);
+ }
/* Init lock */
spin_lock_init(&bcom_eng->lock);
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index 24751df..25b2e55 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -18,6 +18,11 @@
#include <asm/prom.h>
#endif /* __ASSEMBLY__ */
+/* Variants of the 5200(B) */
+#define MPC5200_SVR 0x80110010
+#define MPC5200_SVR_MASK 0xfffffff0
+#define MPC5200B_SVR 0x80110020
+#define MPC5200B_SVR_MASK 0xfffffff0
/* ======================================================================== */
/* Structures mapping of some unit register set */
^ permalink raw reply related
* Re: [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
From: Sven Luther @ 2007-10-17 16:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, domen.puncer
In-Reply-To: <20071017163555.24992.40095.stgit@trillian.cg.shawcable.net>
On Wed, Oct 17, 2007 at 10:36:27AM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Only the MPC5200 needs this bug fix. MPC5200B is okay.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> Sven, Domen;
>
> Can you please test this patch?
I will test it tomorrow. For some obscure reason, my efika refuses to
get the console=ttyPSC0 appended, so i have a hard time testing it.
Friendly,
Sven Luther
^ permalink raw reply
* [PATCH] [POWERPC] lite5200: Add bestcomm to defconfigs
From: Grant Likely @ 2007-10-17 16:55 UTC (permalink / raw)
To: linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Add bestcomm to lite5200 defconfig
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/configs/lite5200_defconfig | 56 ++++++++++++++++++++++++-------
1 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/configs/lite5200_defconfig b/arch/powerpc/configs/lite5200_defconfig
index d42e226..f231f44 100644
--- a/arch/powerpc/configs/lite5200_defconfig
+++ b/arch/powerpc/configs/lite5200_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.23-rc4
-# Tue Aug 28 21:24:38 2007
+# Linux kernel version: 2.6.23
+# Wed Oct 17 10:25:12 2007
#
# CONFIG_PPC64 is not set
@@ -21,8 +21,13 @@ CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
# CONFIG_SMP is not set
CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
@@ -65,6 +70,8 @@ CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
+CONFIG_FAIR_GROUP_SCHED=y
+CONFIG_FAIR_USER_SCHED=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
@@ -83,7 +90,6 @@ CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
# CONFIG_EPOLL is not set
CONFIG_SIGNALFD=y
-CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
@@ -122,7 +128,6 @@ CONFIG_DEFAULT_IOSCHED="anticipatory"
# Platform support
#
CONFIG_PPC_MULTIPLATFORM=y
-# CONFIG_EMBEDDED6xx is not set
# CONFIG_PPC_82xx is not set
# CONFIG_PPC_83xx is not set
# CONFIG_PPC_86xx is not set
@@ -137,6 +142,7 @@ CONFIG_PPC_LITE5200=y
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
# CONFIG_PQ2ADS is not set
+# CONFIG_EMBEDDED6xx is not set
# CONFIG_MPIC is not set
# CONFIG_MPIC_WEIRD is not set
# CONFIG_PPC_I8259 is not set
@@ -150,11 +156,19 @@ CONFIG_PPC_LITE5200=y
# CONFIG_TAU is not set
# CONFIG_CPM2 is not set
# CONFIG_FSL_ULI1575 is not set
+CONFIG_PPC_BESTCOMM=y
+CONFIG_PPC_BESTCOMM_ATA=y
+CONFIG_PPC_BESTCOMM_FEC=y
+CONFIG_PPC_BESTCOMM_GEN_BD=y
#
# Kernel options
#
# CONFIG_HIGHMEM is not set
+# CONFIG_TICK_ONESHOT is not set
+# CONFIG_NO_HZ is not set
+# CONFIG_HIGH_RES_TIMERS is not set
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
@@ -187,10 +201,13 @@ CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP=y
+CONFIG_SUSPEND_UP_POSSIBLE=y
CONFIG_SUSPEND=y
+CONFIG_HIBERNATION_UP_POSSIBLE=y
# CONFIG_HIBERNATION is not set
CONFIG_SECCOMP=y
-# CONFIG_WANT_DEVICE_TREE is not set
+CONFIG_WANT_DEVICE_TREE=y
+CONFIG_DEVICE_TREE=""
CONFIG_ISA_DMA_API=y
#
@@ -225,7 +242,7 @@ CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
-CONFIG_TASK_SIZE=0x80000000
+CONFIG_TASK_SIZE=0xc0000000
CONFIG_BOOT_LOAD=0x00800000
#
@@ -265,6 +282,7 @@ CONFIG_SYN_COOKIES=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
+# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
@@ -322,6 +340,7 @@ CONFIG_DEFAULT_TCP_CONG="cubic"
#
# Generic Driver Options
#
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
@@ -392,6 +411,7 @@ CONFIG_SCSI_WAIT_SCAN=m
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
+# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
@@ -403,6 +423,7 @@ CONFIG_SCSI_LOWLEVEL=y
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
+# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
@@ -471,6 +492,7 @@ CONFIG_PATA_MPC52xx=y
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
+# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
@@ -485,14 +507,7 @@ CONFIG_PATA_MPC52xx=y
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_PLATFORM is not set
# CONFIG_MD is not set
-
-#
-# Fusion MPT device support
-#
# CONFIG_FUSION is not set
-# CONFIG_FUSION_SPI is not set
-# CONFIG_FUSION_FC is not set
-# CONFIG_FUSION_SAS is not set
#
# IEEE 1394 (FireWire) support
@@ -508,12 +523,15 @@ CONFIG_NETDEVICES=y
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
+# CONFIG_VETH is not set
+# CONFIG_IP1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_NET_ETHERNET is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
+# CONFIG_E1000E is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
@@ -521,6 +539,7 @@ CONFIG_NETDEV_1000=y
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
+# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
@@ -530,11 +549,14 @@ CONFIG_NETDEV_1000=y
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
+# CONFIG_IXGBE is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
+# CONFIG_NIU is not set
# CONFIG_MLX4_CORE is not set
+# CONFIG_TEHUTI is not set
# CONFIG_TR is not set
#
@@ -614,6 +636,12 @@ CONFIG_DEVPORT=y
# CONFIG_HWMON is not set
#
+# Sonics Silicon Backplane
+#
+CONFIG_SSB_POSSIBLE=y
+# CONFIG_SSB is not set
+
+#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
@@ -845,3 +873,5 @@ CONFIG_FORCED_INLINING=y
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_CRYPTO is not set
+CONFIG_PPC_CLOCK=y
+CONFIG_PPC_LIB_RHEAP=y
^ permalink raw reply related
* Re: mpc 860 boot linux2.6.23 problem
From: Scott Wood @ 2007-10-17 17:26 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <5E6FFDE1-D706-4460-8621-0BFA38FDC502@embeddedalley.com>
Dan Malek wrote:
>
> On Oct 17, 2007, at 11:31 AM, Scott Wood wrote:
>
>> I just pulled Wolfgang's latest u-boot tree, and I don't see any fdt
>> or ft_ calls in cpu/mpc8xx, nor in any 8xx board that I recognize.
>
> The STx XTc 885 is supported and was used for
> a majority of the FT development in u-boot. I
> just built it a few months ago, it worked fine, so
> if it isn't working today the changes should be
> minimal to bring it up to date.
OK, that wasn't a board I recognized. :-P
Still, most 8xx boards are not yet converted AFAICT. Not that it'd be
hard to do so, but it might be a bit misleading to say "upgrade u-boot
and get device tree support". :-)
-Scott
^ permalink raw reply
* Re: MPC85xx and linux IDE driver
From: Michael Brian Willis @ 2007-10-17 17:47 UTC (permalink / raw)
To: Ben Warren; +Cc: linuxppc-embedded
In-Reply-To: <470FCF8A.1000504@qstreams.com>
On Fri, 2007-10-12 at 15:48 -0400, Ben Warren wrote:
> Here's what I use:
>
> http://marc.info/?l=linux-kernel&m=113877891224982&w=2
Thanks for the response Ben.
I have put the driver you mentioned in my linux source and added the
necessary information in the Kconfig file and the Makefile. So, I am now
able to build the driver when I make my kernel image. However, I can't
figure out what else needs to be done in order to actually use the
driver for my compact flash device. Do I need to specify anything at the
kernel command line, or do I need to modify any other config files?
(Below is the ide portion of my linux .config file)
Thank you for your help so far, anymore help/direction is greatly
appreciated.
Regards,
Michael Willis
Applied Research Labs - University of Texas
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_IDE_MAX_HWIFS=4
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_IDEDISK is not set
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_IDE_TASK_IOCTL=y
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_IDEPCI is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_CFIDE=y
# CONFIG_BLK_DEV_IDEDMA is not set
# CONFIG_BLK_DEV_HD is not set
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: aauer1 @ 2007-10-17 18:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40710170754p54aa405au9b046f7039ecb9ac@mail.gmail.com>
Grant Likely-2 wrote:
>
> On 10/17/07, aauer1 <aauer1@gmx.at> wrote:
>> Now, I know that the kernel boots but I don't get an output with my
>> Xilinx
>> UartLite module. Are there some kernel modules which must be activated??
>> Btw. I have used the Linux-2.6-virtex kernel from
>> http://git.secretlab.ca/git/ and another Kernel (2.6.23 from kernel.org)
>> -
>> both with the same result.
>
> Post the output of __log_buf here please.
>
>
Here is my dump of the __log_buf:
======================
<5>[ 0.000000] Linux version 2.6.23-rc2
(aauer@servitus.student.iaik.tugraz.at) (gcc version 4.0.0 (DENX ELDK 4.1
4.0
.0)) #8 Wed Oct 17 20:05:28 CEST 2007
<6>[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
<7>[ 0.000000] Entering add_active_range(0, 0, 16384) 0 entries of 256
used
<4>[ 0.000000] Zone PFN ranges:
<4>[ 0.000000] DMA 0 -> 16384
<4>[ 0.000000] Normal 16384 -> 16384
<4>[ 0.000000] Movable zone start PFN for each node
<4>[ 0.000000] early_node_map[1] active PFN ranges
<4>[ 0.000000] 0: 0 -> 16384
<7>[ 0.000000] On node 0 totalpages: 16384
<7>[ 0.000000] DMA zone: 128 pages used for memmap
<7>[ 0.000000] DMA zone: 0 pages reserved
<7>[ 0.000000] DMA zone: 16256 pages, LIFO batch:3
<7>[ 0.000000] Normal zone: 0 pages used for memmap
<7>[ 0.000000] Movable zone: 0 pages used for memmap
<4>[ 0.000000] Built 1 zonelists in Zone order. Total pages: 16256
<5>[ 0.000000] Kernel command line: console=ttUL0 root=/dev/xsysace2 rw
<6>[ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
<4>[ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
<4>[ 0.000325] Console: colour dummy device 80x25
<6>[ 0.001380] Dentry cache hash table entries: 8192 (order: 3, 32768
bytes)
<6>[ 0.002924] Inode-cache hash table entries: 4096 (order: 2, 16384
bytes)
<4>[ 0.029750] Memory: 63256k available (1172k kernel code, 384k data,
84k init, 0k highmem)
<7>[ 0.030975] Calibrating delay loop... 299.00 BogoMIPS (lpj=598016)
<4>[ 0.120718] Mount-cache hash table entries: 512
<6>[ 0.171779] io scheduler noop registered
<6>[ 0.171857] io scheduler anticipatory registered (default)
<6>[ 0.171884] io scheduler deadline registered
<6>[ 0.172262] io scheduler cfq registered
<6>[ 0.268268] uartlite.0: ttyUL0 at MMIO 0x40600000 (irq = 2) is a
uartlite
<4>[ 0.281400] RAMDISK driver initialized: 8 RAM disks of 8192K size 1024
blocksize
<6>[ 0.282765] mice: PS/2 mouse device common for all mice
<4>[ 0.286181] VFS: Cannot open root device "xsysace2" or
unknown-block(0,0)
<4>[ 0.286252] Please append a correct "root=" boot option; here are the
available partitions:
<0>[ 0.286323] Kernel panic - not syncing: VFS: Unable to mount root fs
on unknown-block(0,0)
<0>[ 0.286374] Rebooting in 180 seconds..
Thanks,
Andreas
--
View this message in context: http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a13259685
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: Grant Likely @ 2007-10-17 18:23 UTC (permalink / raw)
To: aauer1; +Cc: linuxppc-embedded
In-Reply-To: <13259685.post@talk.nabble.com>
On 10/17/07, aauer1 <aauer1@gmx.at> wrote:
>
>
> Grant Likely-2 wrote:
> >
> > On 10/17/07, aauer1 <aauer1@gmx.at> wrote:
> >> Now, I know that the kernel boots but I don't get an output with my
> >> Xilinx
> >> UartLite module. Are there some kernel modules which must be activated??
> >> Btw. I have used the Linux-2.6-virtex kernel from
> >> http://git.secretlab.ca/git/ and another Kernel (2.6.23 from kernel.org)
> >> -
> >> both with the same result.
> >
> > Post the output of __log_buf here please.
> >
> >
>
> Here is my dump of the __log_buf:
> ======================
> <5>[ 0.000000] Linux version 2.6.23-rc2
> (aauer@servitus.student.iaik.tugraz.at) (gcc version 4.0.0 (DENX ELDK 4.1
> 4.0
> .0)) #8 Wed Oct 17 20:05:28 CEST 2007
> <6>[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
> <7>[ 0.000000] Entering add_active_range(0, 0, 16384) 0 entries of 256
> used
> <4>[ 0.000000] Zone PFN ranges:
> <4>[ 0.000000] DMA 0 -> 16384
> <4>[ 0.000000] Normal 16384 -> 16384
> <4>[ 0.000000] Movable zone start PFN for each node
> <4>[ 0.000000] early_node_map[1] active PFN ranges
> <4>[ 0.000000] 0: 0 -> 16384
> <7>[ 0.000000] On node 0 totalpages: 16384
> <7>[ 0.000000] DMA zone: 128 pages used for memmap
> <7>[ 0.000000] DMA zone: 0 pages reserved
> <7>[ 0.000000] DMA zone: 16256 pages, LIFO batch:3
> <7>[ 0.000000] Normal zone: 0 pages used for memmap
> <7>[ 0.000000] Movable zone: 0 pages used for memmap
> <4>[ 0.000000] Built 1 zonelists in Zone order. Total pages: 16256
> <5>[ 0.000000] Kernel command line: console=ttUL0 root=/dev/xsysace2 rw
Typo! :-)
Try "ttyUL0"
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: boards in arch/ppc -> arch/powerpc for 85xx
From: David Woodhouse @ 2007-10-17 18:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Stefan Roese
In-Reply-To: <7DBC0977-0367-40F5-8A30-ACA02FD4E9FA@kernel.crashing.org>
On Mon, 2007-10-15 at 18:07 -0500, Kumar Gala wrote:
> Guys,
>
> I was wondering if you cared about the following boards existing in
> arch/powerpc:
>
> * STX GP3
> * TQM 85xx
> * SBC 8560
>
> I'm told WR doesn't care about the SBC 8560, so I'll see if David does.
Well, I found an sbc8560 in the boot of my car the other day and I
suppose it shouldn't take much -- so I might as well take a look, next
time I'm home.
--
dwmw2
^ permalink raw reply
* Re: MPC85xx and linux IDE driver
From: Ben Warren @ 2007-10-17 18:44 UTC (permalink / raw)
To: Michael Brian Willis; +Cc: linuxppc-embedded
In-Reply-To: <1192643237.4929.41.camel@louie>
Michael Brian Willis wrote:
> On Fri, 2007-10-12 at 15:48 -0400, Ben Warren wrote:
>
>
>> Here's what I use:
>>
>> http://marc.info/?l=linux-kernel&m=113877891224982&w=2
>>
>
> Thanks for the response Ben.
>
> I have put the driver you mentioned in my linux source and added the
> necessary information in the Kconfig file and the Makefile. So, I am now
> able to build the driver when I make my kernel image. However, I can't
> figure out what else needs to be done in order to actually use the
> driver for my compact flash device. Do I need to specify anything at the
> kernel command line, or do I need to modify any other config files?
> (Below is the ide portion of my linux .config file)
>
>
This device driver is a platform driver, so you need to register a
platform device somewhere in your board-specific init code that contains
the hardware details (memory mapping and IRQ #). You can either pass
this in via device tree or hard code it. I chose the latter in order to
get up and runninq quickly. Here's the init function I use. CS0 is @
0xe4000000, CS1 is @ 0xe4100000 and I'm using IRQ20, which is one of the
external IRQs on my CPU:
/* Compact Flash Initialization */
static int __init prism_setup_cf(void)
{
struct resource r[3];
struct platform_device *cf_dev;
unsigned int virq;
memset(&r, 0, sizeof(r));
r[0].start = 0xe4000000;
r[0].end = 0xe400000f;
r[0].flags = IORESOURCE_MEM;
r[1].start = 0xe4100000;
r[1].end = 0xe410000f;
r[1].flags = IORESOURCE_MEM;
virq = irq_find_mapping(NULL, 20);
set_irq_type(virq, IRQ_TYPE_EDGE_FALLING);
r[2].start = virq;
r[2].end = 0;
r[2].flags = IORESOURCE_IRQ;
cf_dev = platform_device_register_simple("mmio-cfide", 0, r, 3);
return (cf_dev ? 0 : PTR_ERR(cf_dev));
}
> Thank you for your help so far, anymore help/direction is greatly
> appreciated.
>
>
Glad to help.
regards,
Ben
^ permalink raw reply
* Re: mpc 860 boot linux2.6.23 problem
From: Jochen Friedrich @ 2007-10-17 18:54 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <47162AE7.80305@freescale.com>
Hi Scott,
> I just pulled Wolfgang's latest u-boot tree, and I don't see any fdt or
> ft_ calls in cpu/mpc8xx, nor in any 8xx board that I recognize.
>
> I may have been unclear in that I was talking about device tree support
> in u-boot, not the kernel. Obviously there's device tree support in the
> kernel, as evidenced by my reference to using cuImage.
>
Can u-boot work on dtb trees embedded in an cuImage, at all?
How would command line arguments work without a chosen
node?
I tried to boot a mpc823 using the 3 argument mboot command.
u-boot processed the dtb and added the chosen node correctly,
however the kernel immediately oopsed with unable to access
virtual memory when accessing the dtb memory as this memory
was not contained in the kernel MMU space.
Thanks,
Jochen
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: aauer1 @ 2007-10-17 18:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40710171123uefac227q4fecd64516794129@mail.gmail.com>
Thanks. Now, I get the output over the serial line!!!!
Thanks, very much!
Andreas
Grant Likely-2 wrote:
>
> On 10/17/07, aauer1 <aauer1@gmx.at> wrote:
>>
>>
>> Grant Likely-2 wrote:
>> >
>> > On 10/17/07, aauer1 <aauer1@gmx.at> wrote:
>> >> Now, I know that the kernel boots but I don't get an output with my
>> >> Xilinx
>> >> UartLite module. Are there some kernel modules which must be
>> activated??
>> >> Btw. I have used the Linux-2.6-virtex kernel from
>> >> http://git.secretlab.ca/git/ and another Kernel (2.6.23 from
>> kernel.org)
>> >> -
>> >> both with the same result.
>> >
>> > Post the output of __log_buf here please.
>> >
>> >
>>
>> Here is my dump of the __log_buf:
>> ======================
>> <5>[ 0.000000] Linux version 2.6.23-rc2
>> (aauer@servitus.student.iaik.tugraz.at) (gcc version 4.0.0 (DENX ELDK 4.1
>> 4.0
>> .0)) #8 Wed Oct 17 20:05:28 CEST 2007
>> <6>[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
>> <7>[ 0.000000] Entering add_active_range(0, 0, 16384) 0 entries of 256
>> used
>> <4>[ 0.000000] Zone PFN ranges:
>> <4>[ 0.000000] DMA 0 -> 16384
>> <4>[ 0.000000] Normal 16384 -> 16384
>> <4>[ 0.000000] Movable zone start PFN for each node
>> <4>[ 0.000000] early_node_map[1] active PFN ranges
>> <4>[ 0.000000] 0: 0 -> 16384
>> <7>[ 0.000000] On node 0 totalpages: 16384
>> <7>[ 0.000000] DMA zone: 128 pages used for memmap
>> <7>[ 0.000000] DMA zone: 0 pages reserved
>> <7>[ 0.000000] DMA zone: 16256 pages, LIFO batch:3
>> <7>[ 0.000000] Normal zone: 0 pages used for memmap
>> <7>[ 0.000000] Movable zone: 0 pages used for memmap
>> <4>[ 0.000000] Built 1 zonelists in Zone order. Total pages: 16256
>> <5>[ 0.000000] Kernel command line: console=ttUL0 root=/dev/xsysace2
>> rw
>
> Typo! :-)
>
> Try "ttyUL0"
>
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a13260526
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] fs_enet: Update for API changes
From: Scott Wood @ 2007-10-17 17:42 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
This driver was recently broken by several changes for which this
driver was not (or was improperly) updated:
1. SET_MODULE_OWNER() was removed.
2. netif_napi_add() was only being called when building with
the old CPM binding.
3. The received/budget test was backwards.
4. to_net_dev() was wrong -- the device struct embedded in
the net_device struct is not the same as the of_platform
device in the private struct.
5. napi_disable/napi_enable was being called even when napi
was not being used.
These changes have been fixed, and napi is now on by default.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
drivers/net/fs_enet/fs_enet-main.c | 28 ++++++++++++++++------------
drivers/net/fs_enet/fs_enet.h | 1 +
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index 04c6fae..f2a4d39 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -88,7 +88,7 @@ static void skb_align(struct sk_buff *skb, int align)
static int fs_enet_rx_napi(struct napi_struct *napi, int budget)
{
struct fs_enet_private *fep = container_of(napi, struct fs_enet_private, napi);
- struct net_device *dev = to_net_dev(fep->dev);
+ struct net_device *dev = fep->ndev;
const struct fs_platform_info *fpi = fep->fpi;
cbd_t __iomem *bdp;
struct sk_buff *skb, *skbn, *skbt;
@@ -217,7 +217,7 @@ static int fs_enet_rx_napi(struct napi_struct *napi, int budget)
fep->cur_rx = bdp;
- if (received >= budget) {
+ if (received < budget) {
/* done */
netif_rx_complete(dev, napi);
(*fep->ops->napi_enable_rx)(dev);
@@ -807,20 +807,23 @@ static int fs_enet_open(struct net_device *dev)
int r;
int err;
- napi_enable(&fep->napi);
+ if (fep->fpi->use_napi)
+ napi_enable(&fep->napi);
/* Install our interrupt handler. */
r = fs_request_irq(dev, fep->interrupt, "fs_enet-mac", fs_enet_interrupt);
if (r != 0) {
printk(KERN_ERR DRV_MODULE_NAME
": %s Could not allocate FS_ENET IRQ!", dev->name);
- napi_disable(&fep->napi);
+ if (fep->fpi->use_napi)
+ napi_disable(&fep->napi);
return -EINVAL;
}
err = fs_init_phy(dev);
- if(err) {
- napi_disable(&fep->napi);
+ if (err) {
+ if (fep->fpi->use_napi)
+ napi_disable(&fep->napi);
return err;
}
phy_start(fep->phydev);
@@ -1232,7 +1235,7 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
fpi->rx_ring = 32;
fpi->tx_ring = 32;
fpi->rx_copybreak = 240;
- fpi->use_napi = 0;
+ fpi->use_napi = 1;
fpi->napi_weight = 17;
ret = find_phy(ofdev->node, fpi);
@@ -1249,11 +1252,11 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
goto out_free_fpi;
}
- SET_MODULE_OWNER(ndev);
dev_set_drvdata(&ofdev->dev, ndev);
fep = netdev_priv(ndev);
fep->dev = &ofdev->dev;
+ fep->ndev = ndev;
fep->fpi = fpi;
fep->ops = match->data;
@@ -1288,10 +1291,11 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
ndev->stop = fs_enet_close;
ndev->get_stats = fs_enet_get_stats;
ndev->set_multicast_list = fs_set_multicast_list;
- if (fpi->use_napi) {
- ndev->poll = fs_enet_rx_napi;
- ndev->weight = fpi->napi_weight;
- }
+
+ if (fpi->use_napi)
+ netif_napi_add(ndev, &fep->napi, fs_enet_rx_napi,
+ fpi->napi_weight);
+
ndev->ethtool_ops = &fs_ethtool_ops;
ndev->do_ioctl = fs_ioctl;
diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
index baf6477..c675e29 100644
--- a/drivers/net/fs_enet/fs_enet.h
+++ b/drivers/net/fs_enet/fs_enet.h
@@ -75,6 +75,7 @@ struct phy_info {
struct fs_enet_private {
struct napi_struct napi;
struct device *dev; /* pointer back to the device (must be initialized first) */
+ struct net_device *ndev;
spinlock_t lock; /* during all ops except TX pckt processing */
spinlock_t tx_lock; /* during fs_start_xmit and fs_tx */
struct fs_platform_info *fpi;
--
1.5.3.4
^ permalink raw reply related
* Re: mpc 860 boot linux2.6.23 problem
From: Scott Wood @ 2007-10-17 19:15 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <47165A7E.1070206@scram.de>
Jochen Friedrich wrote:
> Hi Scott,
>
>> I just pulled Wolfgang's latest u-boot tree, and I don't see any fdt
>> or ft_ calls in cpu/mpc8xx, nor in any 8xx board that I recognize.
>>
>> I may have been unclear in that I was talking about device tree
>> support in u-boot, not the kernel. Obviously there's device tree
>> support in the kernel, as evidenced by my reference to using cuImage.
>>
>
> Can u-boot work on dtb trees embedded in an cuImage, at all?
No. If you want that, you need to use a normal uImage.
> How would command line arguments work without a chosen
> node?
The bad old way: argument registers and the bd_t. The bootwrapper fills
in /chosen/bootargs and other things based on that.
It's just for compatibility; use uImage if you can.
> I tried to boot a mpc823 using the 3 argument mboot command.
> u-boot processed the dtb and added the chosen node correctly,
> however the kernel immediately oopsed with unable to access
> virtual memory when accessing the dtb memory as this memory
> was not contained in the kernel MMU space.
Make sure your version of u-boot understands the new bindings for things
like brg frequency, or (less preferred) set it manually in your dts.
-Scott
^ permalink raw reply
* Re: [PATCH take2] [POWERPC] i2c: adds support for i2c bus on 8xx
From: Jochen Friedrich @ 2007-10-17 19:20 UTC (permalink / raw)
To: Scott Wood
Cc: Carsten Juttner, linux-kernel, i2c, linuxppc-embedded@ozlabs.org
In-Reply-To: <20071015183107.GA4361@loki.buserror.net>
Hi Scott,
> Do we really need to be adding features for arch/ppc at this point? It'll
> be going away in June. arch/ppc-specific things outside of arch/ppc itself
> will also be more likely to be missed in the removal.
>
> Also, please post inline rather than as an attachment; attachments are
> harder to quote in a reply.
>
OK. I'll remove the ARC=ppc parts.
>> diff --git a/arch/powerpc/boot/dts/mpc885ads.dts b/arch/powerpc/boot/dts/mpc885ads.dts
>> index 8848e63..a526c02 100644
>> --- a/arch/powerpc/boot/dts/mpc885ads.dts
>> +++ b/arch/powerpc/boot/dts/mpc885ads.dts
>> @@ -213,6 +213,15 @@
>> fsl,cpm-command = <0080>;
>> linux,network-index = <2>;
>> };
>> +
>> + i2c@860 {
>> + device_type = "i2c";
>>
>
> No device_type.
>
Why? Documentation/powerpc/booting-without-of.txt says for I2C interfaces
device_type is required and should be "i2c". Is this no longer true?
> Should be fsl,cpm-i2c. Is cpm2 i2c the same? If not, it should be
> fsl,cpm1-i2c. It's probably best to specify it anyway, along with
> fsl,mpc885-i2c.
>
CPM2 i2c seems to be the same. However, i have no way to test this.
>> +#ifdef CONFIG_I2C_8XX
>> + setbits32(&mpc8xx_immr->im_cpm.cp_pbpar, 0x00000030);
>> + setbits32(&mpc8xx_immr->im_cpm.cp_pbdir, 0x00000030);
>> + setbits16(&mpc8xx_immr->im_cpm.cp_pbodr, 0x0030);
>> +#endif
>>
>
> Please add this to mpc885ads_pins, rather than poking the registers
> directly. The relevant lines are:
>
> {CPM_PORTB, 26, CPM_PIN_OUTPUT},
> {CPM_PORTB, 27, CPM_PIN_OUTPUT},
>
I noticed cpm1_set_pin32, but this function don't seem to set the
odr register. Will this be added? Then it would be:
{CPM_PORTB, 26, CPM_PIN_OUTPUT | CPM_PIN_OPENDRAIN},
{CPM_PORTB, 27, CPM_PIN_OUTPUT | CPM_PIN_OPENDRAIN},
>> + /* Select an arbitrary address. Just make sure it is unique.
>> + */
>> + out_8(&i2c->i2c_i2add, 0xfe);
>>
>
> It's a 7-bit address... and are you sure that 0x7e is unique? Does this
> driver even support slave operation?
>
It's in fact 0x7F << 1. The same value is used in the 2.4 driver and
in u-boot, as well. Slave operation is not supported.
> Why is an 8xx driver matching all i2c cpm (i.e. what about cpm2)?
>
With the suggested change to use fsl,cpm-command, the driver should
be able to use both cpm1 and cpm2. The operation and structs for i2c
are identical. The only difference might be the hack^wsupport for
relocation.
Thanks,
Jochen
^ permalink raw reply
* loading NOR flash from DT
From: Sebastian Siewior @ 2007-10-17 19:26 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I have here a MPC8544 DS board with NOR flash on it and Kumar's git
tree. I'm trying to detect this flash with the physmap_of module. I
added a nor_flash block (I used sequoia.dts as an example) into my
device tree on the same level as soc8544 or memory (or between them).
After modprobing physmap_of nothing happend. Then I tried to make a tree
with plb -> opb -> ebc and finally nor_flash but still nothing changed.
Is there a user space dependency or did I just edit my device tree the
wrong way? Any hints are welcome :)
Sebastian
^ permalink raw reply
* Re: [PATCH take2] [POWERPC] i2c: adds support for i2c bus on 8xx
From: Scott Wood @ 2007-10-17 19:35 UTC (permalink / raw)
To: Jochen Friedrich
Cc: Carsten Juttner, linux-kernel, i2c, linuxppc-embedded@ozlabs.org
In-Reply-To: <47166085.1010608@scram.de>
Jochen Friedrich wrote:
>>> diff --git a/arch/powerpc/boot/dts/mpc885ads.dts
>>> b/arch/powerpc/boot/dts/mpc885ads.dts
>>> index 8848e63..a526c02 100644
>>> --- a/arch/powerpc/boot/dts/mpc885ads.dts
>>> +++ b/arch/powerpc/boot/dts/mpc885ads.dts
>>> @@ -213,6 +213,15 @@
>>> fsl,cpm-command = <0080>;
>>> linux,network-index = <2>;
>>> };
>>> +
>>> + i2c@860 {
>>> + device_type = "i2c";
>>>
>>
>> No device_type.
>>
>
> Why? Documentation/powerpc/booting-without-of.txt says for I2C interfaces
> device_type is required and should be "i2c". Is this no longer true?
booting-without-of.txt should be changed.
>> Should be fsl,cpm-i2c. Is cpm2 i2c the same? If not, it should be
>> fsl,cpm1-i2c. It's probably best to specify it anyway, along with
>> fsl,mpc885-i2c.
>
> CPM2 i2c seems to be the same. However, i have no way to test this.
OK, let's make the compatible "fsl,mpc885-i2c", "fsl,cpm1-i2c",
"fsl,cpm-i2c".
For now, match on the last one, but if any differences pop up, we have
the more specific ones.
> I noticed cpm1_set_pin32, but this function don't seem to set the
> odr register. Will this be added? Then it would be:
>
> {CPM_PORTB, 26, CPM_PIN_OUTPUT | CPM_PIN_OPENDRAIN},
> {CPM_PORTB, 27, CPM_PIN_OUTPUT | CPM_PIN_OPENDRAIN},
>
Ah, missed that -- there's opendrain support for port E, but I missed
that port B had it as well. Feel free to add it.
>> It's a 7-bit address... and are you sure that 0x7e is unique? Does this
>> driver even support slave operation?
>
> It's in fact 0x7F << 1.
Gah, I hate powerpc bit numbering, especially without the
numbered-as-if-64-bit hack. I specifically looked at the manual before
to see if it was shifted, saw "0-6", and concluded it wasn't. :-P
> The same value is used in the 2.4 driver and
> in u-boot, as well.
That doesn't mean that this isn't a good time to review what the code is
doing. :-)
> Slave operation is not supported.
If slave operation isn't supported, how is this value used?
>> Why is an 8xx driver matching all i2c cpm (i.e. what about cpm2)?
>
> With the suggested change to use fsl,cpm-command, the driver should
> be able to use both cpm1 and cpm2. The operation and structs for i2c
> are identical. The only difference might be the hack^wsupport for
> relocation.
OK. Would that allow it to become one driver, rather than a wrapper and
an algorithm?
-Scott
^ permalink raw reply
* Re: loading NOR flash from DT
From: Josh Boyer @ 2007-10-17 19:47 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-embedded
In-Reply-To: <20071017192651.GA5192@Chamillionaire.breakpoint.cc>
On Wed, 17 Oct 2007 21:26:51 +0200
Sebastian Siewior <linuxppc-embedded@ml.breakpoint.cc> wrote:
> Hello,
>
> I have here a MPC8544 DS board with NOR flash on it and Kumar's git
> tree. I'm trying to detect this flash with the physmap_of module. I
> added a nor_flash block (I used sequoia.dts as an example) into my
> device tree on the same level as soc8544 or memory (or between them).
> After modprobing physmap_of nothing happend. Then I tried to make a tree
> with plb -> opb -> ebc and finally nor_flash but still nothing changed.
>
> Is there a user space dependency or did I just edit my device tree the
> wrong way? Any hints are welcome :)
Post your device tree please. I don't recall MPC8544 even having PLB,
OPB, or EBC busses, so they likely aren't getting probed.
josh
^ permalink raw reply
* Re: loading NOR flash from DT
From: Sebastian Siewior @ 2007-10-17 19:55 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20071017144759.320209bd@weaponx.rchland.ibm.com>
* Josh Boyer | 2007-10-17 14:47:59 [-0500]:
>On Wed, 17 Oct 2007 21:26:51 +0200
>Sebastian Siewior <linuxppc-embedded@ml.breakpoint.cc> wrote:
>
>> Hello,
>>
>> I have here a MPC8544 DS board with NOR flash on it and Kumar's git
>> tree. I'm trying to detect this flash with the physmap_of module. I
>> added a nor_flash block (I used sequoia.dts as an example) into my
>> device tree on the same level as soc8544 or memory (or between them).
>> After modprobing physmap_of nothing happend. Then I tried to make a tree
>> with plb -> opb -> ebc and finally nor_flash but still nothing changed.
>>
>> Is there a user space dependency or did I just edit my device tree the
>> wrong way? Any hints are welcome :)
>
>Post your device tree please. I don't recall MPC8544 even having PLB,
>OPB, or EBC busses, so they likely aren't getting probed.
/*
* MPC8544 DS Device Tree Source
*
* Copyright 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 as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
/ {
model = "MPC8544DS";
compatible = "MPC8544DS", "MPC85xxDS";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8544@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K
i-cache-size = <8000>; // L1, 32K
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
};
};
memory {
device_type = "memory";
reg = <00000000 00000000>; // Filled by U-Boot
};
flash@fc000000 {
compatible = "amd,s29gl512n", "cfi-flash";
reg = <fc000000 4000000>;
bank-width = <2>;
#address-cells = <1>;
#size-cells = <1>;
fs@0 {
label = "fs";
reg = <0 f80000>;
};
firmware@f80000 {
label ="firmware";
reg = <f80000 80000>;
read-only;
};
soc8544@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
ranges = <00000000 e0000000 00100000>;
reg = <e0000000 00001000>; // CCSRBAR 1M
bus-frequency = <0>; // Filled out by uboot.
memory-controller@2000 {
compatible = "fsl,8544-memory-controller";
reg = <2000 1000>;
interrupt-parent = <&mpic>;
interrupts = <12 2>;
};
l2-cache-controller@20000 {
compatible = "fsl,8544-l2-cache-controller";
reg = <20000 1000>;
cache-line-size = <20>; // 32 bytes
cache-size = <40000>; // L2, 256K
interrupt-parent = <&mpic>;
interrupts = <10 2>;
};
i2c@3000 {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <2b 2>;
interrupt-parent = <&mpic>;
dfsrr;
};
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
phy0: ethernet-phy@0 {
interrupt-parent = <&mpic>;
interrupts = <a 1>;
reg = <0>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <a 1>;
reg = <1>;
device_type = "ethernet-phy";
};
};
ethernet@24000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <24000 1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <1d 2 1e 2 22 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy0>;
phy-connection-type = "rgmii-id";
};
ethernet@26000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <26000 1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <1f 2 20 2 21 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy1>;
phy-connection-type = "rgmii-id";
};
serial@4500 {
device_type = "serial";
compatible = "ns16550";
reg = <4500 100>;
clock-frequency = <0>;
interrupts = <2a 2>;
interrupt-parent = <&mpic>;
};
serial@4600 {
device_type = "serial";
compatible = "ns16550";
reg = <4600 100>;
clock-frequency = <0>;
interrupts = <2a 2>;
interrupt-parent = <&mpic>;
};
global-utilities@e0000 { //global utilities block
compatible = "fsl,mpc8548-guts";
reg = <e0000 1000>;
fsl,has-rstcr;
};
mpic: pic@40000 {
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <40000 40000>;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
};
pci@e0008000 {
compatible = "fsl,mpc8540-pci";
device_type = "pci";
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x11 J17 Slot 1 */
8800 0 0 1 &mpic 2 1
8800 0 0 2 &mpic 3 1
8800 0 0 3 &mpic 4 1
8800 0 0 4 &mpic 1 1
/* IDSEL 0x12 J16 Slot 2 */
9000 0 0 1 &mpic 3 1
9000 0 0 2 &mpic 4 1
9000 0 0 3 &mpic 2 1
9000 0 0 4 &mpic 1 1>;
interrupt-parent = <&mpic>;
interrupts = <18 2>;
bus-range = <0 ff>;
ranges = <02000000 0 c0000000 c0000000 0 20000000
01000000 0 00000000 e1000000 0 00010000>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <e0008000 1000>;
};
pcie@e0009000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <e0009000 1000>;
bus-range = <0 ff>;
ranges = <02000000 0 80000000 80000000 0 20000000
01000000 0 00000000 e1010000 0 00010000>;
clock-frequency = <1fca055>;
interrupt-parent = <&mpic>;
interrupts = <1a 2>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x0 */
0000 0 0 1 &mpic 4 1
0000 0 0 2 &mpic 5 1
0000 0 0 3 &mpic 6 1
0000 0 0 4 &mpic 7 1
>;
pcie@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <02000000 0 80000000
02000000 0 80000000
0 20000000
01000000 0 00000000
01000000 0 00000000
0 00010000>;
};
};
pcie@e000a000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <e000a000 1000>;
bus-range = <0 ff>;
ranges = <02000000 0 a0000000 a0000000 0 10000000
01000000 0 00000000 e1020000 0 00010000>;
clock-frequency = <1fca055>;
interrupt-parent = <&mpic>;
interrupts = <19 2>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x0 */
0000 0 0 1 &mpic 0 1
0000 0 0 2 &mpic 1 1
0000 0 0 3 &mpic 2 1
0000 0 0 4 &mpic 3 1
>;
pcie@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <02000000 0 a0000000
02000000 0 a0000000
0 10000000
01000000 0 00000000
01000000 0 00000000
0 00010000>;
};
};
pcie@e000b000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <e000b000 1000>;
bus-range = <0 ff>;
ranges = <02000000 0 b0000000 b0000000 0 00100000
01000000 0 00000000 b0100000 0 00100000>;
clock-frequency = <1fca055>;
interrupt-parent = <&mpic>;
interrupts = <1b 2>;
interrupt-map-mask = <fb00 0 0 0>;
interrupt-map = <
// IDSEL 0x1c USB
e000 0 0 0 &i8259 c 2
e100 0 0 0 &i8259 9 2
e200 0 0 0 &i8259 a 2
e300 0 0 0 &i8259 b 2
// IDSEL 0x1d Audio
e800 0 0 0 &i8259 6 2
// IDSEL 0x1e Legacy
f000 0 0 0 &i8259 7 2
f100 0 0 0 &i8259 7 2
// IDSEL 0x1f IDE/SATA
f800 0 0 0 &i8259 e 2
f900 0 0 0 &i8259 5 2
>;
pcie@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <02000000 0 b0000000
02000000 0 b0000000
0 00100000
01000000 0 00000000
01000000 0 00000000
0 00100000>;
uli1575@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
ranges = <02000000 0 b0000000
02000000 0 b0000000
0 00100000
01000000 0 00000000
01000000 0 00000000
0 00100000>;
isa@1e {
device_type = "isa";
#interrupt-cells = <2>;
#size-cells = <1>;
#address-cells = <2>;
reg = <f000 0 0 0 0>;
ranges = <1 0
01000000 0 0
00001000>;
interrupt-parent = <&i8259>;
i8259: interrupt-controller@20 {
reg = <1 20 2
1 a0 2
1 4d0 2>;
interrupt-controller;
device_type = "interrupt-controller";
#address-cells = <0>;
#interrupt-cells = <2>;
compatible = "chrp,iic";
interrupts = <9 2>;
interrupt-parent = <&mpic>;
};
i8042@60 {
#size-cells = <0>;
#address-cells = <1>;
reg = <1 60 1 1 64 1>;
interrupts = <1 3 c 3>;
interrupt-parent = <&i8259>;
keyboard@0 {
reg = <0>;
compatible = "pnpPNP,303";
};
mouse@1 {
reg = <1>;
compatible = "pnpPNP,f03";
};
};
rtc@70 {
compatible = "pnpPNP,b00";
reg = <1 70 2>;
};
gpio@400 {
reg = <1 400 80>;
};
};
};
};
};
};
>
>josh
Sebastian
^ permalink raw reply
* [PATCH][NET] gianfar: fix obviously wrong #ifdef CONFIG_GFAR_NAPI placement
From: Anton Vorontsov @ 2007-10-17 19:57 UTC (permalink / raw)
To: leoli, jgarzik, paulus; +Cc: netdev, linux-kernel, linuxppc-dev
Erroneous #ifdef introduced by 293c8513398657f6263fcdb03c87f2760cf61be4
causing NAPI-less ethernet malfunctioning.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
---
if (...)
#if
...;
#endif
good candidate for checkpatch?
drivers/net/gianfar.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index cc288d8..38268d7 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -956,10 +956,12 @@ static int gfar_enet_open(struct net_device *dev)
}
err = startup_gfar(dev);
- if (err)
+ if (err) {
#ifdef CONFIG_GFAR_NAPI
napi_disable(&priv->napi);
#endif
+ return err;
+ }
netif_start_queue(dev);
--
1.5.0.6
^ permalink raw reply related
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