* 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
* 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
* [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: 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
* 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: 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: 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: 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: 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: 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: 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
* [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: [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] 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: 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
* 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: 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: 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: [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: [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: mpc 860 boot linux2.6.23 problem
From: Scott Wood @ 2007-10-17 15:31 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <85100356-D95B-4343-98BE-66080EA9887D@embeddedalley.com>
Dan Malek wrote:
>
> On Oct 16, 2007, at 12:18 PM, Scott Wood wrote:
>
>> Upgrading to the latest u-boot certainly shouldn't hurt, but I don't
>> think there's any device tree support for 8xx yet,
>
> Have you tried it? Works for me. In fact, most
> of the development you see today was done
> by Pantelis on the 8xx.
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.
-Scott
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Stephen Hemminger @ 2007-10-17 15:31 UTC (permalink / raw)
To: benh; +Cc: netdev, Roland Dreier, David S. Miller, Jeff Garzik,
linuxppc-dev list
In-Reply-To: <1192591481.11899.134.camel@pasglop>
Please don't use double underscore, for this function name. There is no
reason to not make it a normal API call.
The sky2 fix I am working on will use napi_synchronize as well.
--- a/include/linux/netdevice.h 2007-10-16 16:48:20.000000000 -0700
+++ b/include/linux/netdevice.h 2007-10-17 08:29:55.000000000 -0700
@@ -407,6 +407,24 @@ static inline void napi_enable(struct na
clear_bit(NAPI_STATE_SCHED, &n->state);
}
+#ifdef CONFIG_SMP
+/**
+ * napi_synchronize - wait until NAPI is not running
+ * @n: napi context
+ *
+ * Wait until NAPI is done being scheduled on this context.
+ * Any outstanding processing completes but
+ * does not disable future activations.
+ */
+static inline void napi_synchronize(const struct napi_struct *n)
+{
+ while (test_bit(NAPI_STATE_SCHED, &n->state))
+ msleep(1);
+}
+#else
+# define napi_synchronize(n) barrier()
+#endif
+
/*
* The DEVICE structure.
* Actually, this whole structure is a big mistake. It mixes I/O
^ permalink raw reply
* Re: [PATCH 4/4] [POWERPC] Enable restart support for lite5200 board
From: Grant Likely @ 2007-10-17 15:31 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <471607DB.4060509@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Looks good; I'll pick this one up when you respin the others.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 3/4] [POWERPC] Add restart support for mpc52xx based platforms
From: Grant Likely @ 2007-10-17 15:30 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <471607A8.6050203@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add common helper routines: mpc52xx_map_wdt() and mpc52xx_restart().
>
> This patch relies on Sascha Hauer's patch published in:
> http://patchwork.ozlabs.org/linuxppc/patch?id=8910.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>
> arch/powerpc/platforms/52xx/mpc52xx_common.c | 45 +++++++++++++++++++++++++++
> include/asm-powerpc/mpc52xx.h | 3 +
> 2 files changed, 48 insertions(+)
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
> index 74b4b41..553937b 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
> @@ -18,6 +18,13 @@ #include <asm/io.h>
> #include <asm/prom.h>
> #include <asm/mpc52xx.h>
>
> +/*
> + * This variable is mapped in mpc52xx_map_wdt() and used in mpc52xx_restart().
> + * Permanent mapping is required because mpc52xx_restart() can be called
> + * from interrupt context while node mapping (which calls iorenmap())
> + * cannot be used at such point.
> + */
> +static volatile struct mpc52xx_gpt *mpc52xx_wdt = NULL;
>
> static void __iomem *
> mpc52xx_map_node(struct device_node *ofn)
> @@ -126,3 +133,41 @@ mpc52xx_declare_of_platform_devices(void
> "Error while probing of_platform bus\n");
> }
>
> +void __init
> +mpc52xx_map_wdt(void)
> +{
> + const void *has_wdt;
> + struct device_node *np;
> +
> + /* mpc52xx_wdt is mapped here and used in mpc52xx_restart,
> + * possibly from a interrupt context. */
> +
> + for (np = NULL;
> + (np = of_find_compatible_node(np, NULL, "fsl,mpc5200-gpt")) != NULL;
> + ) {
> + /* wdt is only implement on gpt0, check has-wdt property. */
> + has_wdt = of_get_property(np, "fsl,has-wdt", NULL);
Test for both "has-wdt" and "fsl,has-wdt" for now.
Otherwise, looks good.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules
From: Kumar Gala @ 2007-10-17 15:30 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev list, Timur Tabi
In-Reply-To: <24BADA7A-1716-43B1-BC92-F4DB7ED0D331@kernel.crashing.org>
On May 25, 2007, at 7:15 AM, Kumar Gala wrote:
>
> On May 24, 2007, at 9:45 PM, Li Yang-r58472 wrote:
>
>>
>>> -----Original Message-----
>>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>>> Sent: Thursday, May 24, 2007 7:44 PM
>>> To: Li Yang-r58472
>>> Cc: Paul; linuxppc-dev@ozlabs.org
>>> Subject: Re: [PATCH] qe_lib: export symbols to fix compile error
>>> when
>> QE drivers
>>> compile as modules
>>>
>>>
>>> On May 24, 2007, at 4:14 AM, Li Yang wrote:
>>>
>>>> Export symbols of qe_lib to be used by QE drivers.
>>>>
>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>> ---
>>>> arch/powerpc/sysdev/qe_lib/ucc.c | 7 +++++++
>>>> arch/powerpc/sysdev/qe_lib/ucc_fast.c | 8 ++++++++
>>>> arch/powerpc/sysdev/qe_lib/ucc_slow.c | 12 ++++++++++--
>>>> 3 files changed, 25 insertions(+), 2 deletions(-)
>>>
>>> A number of the EXPORT_SYMBOL() are not used by any in kernel
>>> drivers
>>> and thus should not be added. See comments below. Also, should
>>> these be EXPORT_SYMBOL_GPL().
>>
>> Some of them are not used by in kernel driver, but they are used by
>> some
>> off kernel drivers and driver in development. Shouldn't we export
>> them?
>
> Nope, its been a pretty established rule that we don't export symbols
> for drivers not in the kernel. These drivers should really be
> submitted for acceptance into the kernel and than we can export the
> symbols they need.
>
> While I can see a need for the *slow* symbols to be exported until
> there is a driver needing them we shouldn't export the symbols.
>
>> I know Linux is again non-GPL modules, but Freescale won't be forcing
>> customers to use GPL as long as Linux doesn't ban non-GPL module
>> completely.
>
> That's fine.
>
>>>> static void get_cmxucr_reg(int ucc_num, volatile u32 ** p_cmxucr,
>>>> u8 * reg_num,
>>>> u8 * shift)
>>>> @@ -122,6 +126,7 @@ static void get_cmxucr_reg(int ucc_num,
>>>> volatile u32 ** p_cmxucr, u8 * reg_num,
>>>> break;
>>>> }
>>>> }
>>>> +EXPORT_SYMBOL(get_cmxucr_reg);
>>>
>>> remove, you shouldn't be exporting something marked static.
>>
>> Good catch.
>>
>> Thanks,
>> Leo
What happened with this?
- k
^ 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