* Re: [patch 6/7] ps3: ROM Storage Driver
From: Arnd Bergmann @ 2007-05-25 16:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert.Uytterhoeven, linux-kernel
In-Reply-To: <20070525083632.677742000@sonycom.com>
On Friday 25 May 2007, Geert.Uytterhoeven@sonycom.com wrote:
> Add a CD/DVD/BD Storage Driver for the PS3:
> - Implemented as a SCSI device driver
I assume you tried implementing it as a block device driver,
like you PS3 disk driver does, and failed for some reason.
What is the problem? Is there infrastructure missing in the
CD-ROM layer?
Arnd <><
^ permalink raw reply
* Re: [patch 5/7] ps3: Disk Storage Driver
From: Arnd Bergmann @ 2007-05-25 16:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert.Uytterhoeven, linux-kernel
In-Reply-To: <20070525083632.575306000@sonycom.com>
On Friday 25 May 2007, Geert.Uytterhoeven@sonycom.com wrote:
> +static void ps3disk_scatter_gather(struct ps3_storage_device *dev,
> + struct request *req, int gather)
> +{
> + unsigned int sectors = 0, offset = 0;
> + struct bio *bio;
> + sector_t sector;
> + struct bio_vec *bvec;
> + unsigned int i = 0, j;
> + size_t size;
> + void *buf;
> +
> + rq_for_each_bio(bio, req) {
> + sector = bio->bi_sector;
> + dev_dbg(&dev->sbd.core,
> + "%s:%u: bio %u: %u segs %u sectors from %lu\n",
> + __func__, __LINE__, i, bio_segments(bio),
> + bio_sectors(bio), sector);
> + bio_for_each_segment(bvec, bio, j) {
> + size = bio_cur_sectors(bio)*KERNEL_SECTOR_SIZE;
> + buf = __bio_kmap_atomic(bio, j, KM_USER0);
> + if (gather)
> + memcpy(dev->bounce_buf+offset, buf, size);
> + else
> + memcpy(buf, dev->bounce_buf+offset, size);
> + offset += size;
> + __bio_kunmap_atomic(bio, KM_USER0);
> + }
> + sectors += bio_sectors(bio);
> + i++;
> + }
> +}
So the hypervison uses guest-real addresses here? I would have expected
it to use the kernel page tables, which lets you use vmap() to do
scatter-gather.
> +static int ps3disk_thread(void *data)
> +{
> + struct ps3_storage_device *dev = data;
> + struct ps3disk_private *priv = ps3disk_priv(dev);
> + request_queue_t *q = priv->queue;
> + struct request *req;
> +
> + dev_dbg(&dev->sbd.core, "%s thread init\n", __func__);
> +
> + current->flags |= PF_NOFREEZE;
> +
> + while (!kthread_should_stop()) {
> + spin_lock_irq(&priv->lock);
> + set_current_state(TASK_INTERRUPTIBLE);
> + req = elv_next_request(q);
> + if (!req) {
> + spin_unlock_irq(&priv->lock);
> + schedule();
> + continue;
> + }
> + if (!blk_fs_request(req)) {
> + blk_dump_rq_flags(req, DEVICE_NAME " bad request");
> + end_request(req, 0);
> + spin_unlock_irq(&priv->lock);
> + continue;
> + }
> + spin_unlock_irq(&priv->lock);
> + ps3disk_handle_request_sg(dev, req);
> + }
> +
> + dev_dbg(&dev->sbd.core, "%s thread exit\n", __func__);
> + return 0;
> +}
I don't really understand what the kthread is needed for. You probably
thought about multiple options and ended up with this, but having
a comment in front of it might be helpful.
Arnd <><
^ permalink raw reply
* Re: [patch 4/7] ps3: Storage Driver Probing
From: Arnd Bergmann @ 2007-05-25 16:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert.Uytterhoeven, linux-kernel
In-Reply-To: <20070525083632.474400000@sonycom.com>
On Friday 25 May 2007, Geert.Uytterhoeven@sonycom.com wrote:
> Add storage driver probing.
> New storage devices are detected and added by a kthread.
Hi Geert,
the driver looks pretty good, just a few details I noticed:
> +static u64 ps3stor_wait_for_completion(u64 devid, u64 tag,
> + unsigned int timeout)
> +{
> + unsigned int retries = 0;
> + u64 res = -1, status;
> +
> + for (retries = 0; retries < timeout; retries++) {
> + res = lv1_storage_check_async_status(NOTIFICATION_DEVID, tag,
> + &status);
> + if (!res)
> + break;
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(1);
> + }
Any reason not to use msleep(1) instead of the schedule_timeout?
> + switch (dev_type) {
> + case PS3_DEV_TYPE_STOR_DISK:
> + match_id = PS3_MATCH_ID_STOR_DISK;
> + break;
> +
> + case PS3_DEV_TYPE_STOR_ROM:
> + match_id = PS3_MATCH_ID_STOR_ROM;
> + break;
> +
> + case PS3_DEV_TYPE_STOR_FLASH:
> + match_id = PS3_MATCH_ID_STOR_FLASH;
> + break;
> +
> + default:
> + return 0;
> + }
Why do you have separate constants for PS3_DEV_TYPE_* and
PS3_MATCH_ID_*? If you don't do any conversion, this driver
will immediately work for additional types as well, if more
get added later.
> +
> +// pr_debug("%s:%u: Checking for new storage devices...\n",
> +// __func__, __LINE__);
Should be removed, or not in comments, either way is fine, as pr_debug
normally does not get compiled in anyway.
> +
> + msleep_interruptible(ms);
> + if (ms < 60000)
> + ms <<= 1;
Is this timeout only for the disk spinup, or also for detecting media
added at run time, like inserting a DVD? One minute timeout for
detecting a DVD would sound very long to me.
Arnd <><
^ permalink raw reply
* Re: zImage.elf loads but does not start
From: Mirek23 @ 2007-05-25 15:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4656E1B9.9090308@ru.mvista.com>
Hi Andrei,
Thank you very much for your suggestion.
I am very grateful for all of your hints. They were always very valuable to
me.
I have set as you mentioned:
#define XPAR_DDR_0_SIZE 0x2000000
And now all works fine!!!!
The root file system is mounted and I can execute whatever I like from the
rootfile system.
It was just my mistake that I did not noticed the memory size was wrong :(
After all of that I would like to use the GPIO driver to talk to the FPGA
part of the board.
Do you have some experience with that.
in my xparameters_ml403.h I have two devices defined: LEDs and SWITCHES as
listed below
/* Definitions for peripheral LEDS_8BIT */
#define XPAR_LEDS_8BIT_BASEADDR 0x40000000
#define XPAR_LEDS_8BIT_HIGHADDR 0x4000FFFF
#define XPAR_LEDS_8BIT_DEVICE_ID 0
#define XPAR_LEDS_8BIT_INTERRUPT_PRESENT 0
#define XPAR_LEDS_8BIT_IS_DUAL 0
/* Definitions for peripheral DIP_SWITCHES_8BIT */
#define XPAR_DIP_SWITCHES_8BIT_BASEADDR 0x40020000
#define XPAR_DIP_SWITCHES_8BIT_HIGHADDR 0x4002FFFF
#define XPAR_DIP_SWITCHES_8BIT_DEVICE_ID 1
#define XPAR_DIP_SWITCHES_8BIT_INTERRUPT_PRESENT 0
#define XPAR_DIP_SWITCHES_8BIT_IS_DUAL 0
#define XPAR_GPIO_0_BASEADDR XPAR_LEDS_8BIT_BASEADDR
#define XPAR_GPIO_0_HIGHADDR XPAR_LEDS_8BIT_HIGHADDR
#define XPAR_GPIO_0_IS_DUAL XPAR_LEDS_8BIT_IS_DUAL
#define XPAR_GPIO_0_DEVICE_ID XPAR_LEDS_8BIT_DEVICE_ID
#define XPAR_GPIO_1_BASEADDR XPAR_DIP_SWITCHES_8BIT_BASEADDR
#define XPAR_GPIO_1_HIGHADDR XPAR_DIP_SWITCHES_8BIT_HIGHADDR
#define XPAR_GPIO_1_IS_DUAL XPAR_DIP_SWITCHES_8BIT_IS_DUAL
#define XPAR_GPIO_1_DEVICE_ID XPAR_DIP_SWITCHES_8BIT_DEVICE_ID
but I do not know how exactly to talk to them by means of the xgpio driver.
Best Regards and many many thanks for your support
Mirek
Andrei Konovalov wrote:
>
> Mirek,
>
> Miroslaw Dach wrote:
>> I do not know however if the stack is properly configured since I did not
>> see any parameter in kernel which refers to the stack or heap.
>>
>> My bsp i.e xparameteres_ml403.h contains two macros:
>> #define XPAR_DDR_SDRAM_1_MEM0_BASEADDR 0x00000000
>> #define XPAR_DDR_SDRAM_1_MEM0_HIGHADDR 0x01FFFFFF
>>
>> I have the feeling that they are ignored because I did not find anywhere
>> in the kernel source those names.
>>
>> When kernel boots it prints at the beginning:
>> loaded at: 00400000 004F9138
>> board data at: 004F7120 004F7138
>> relocated to: 00404064 0040407C
>> zimage at: 00404DF1 004F6BBB
>> avail ram: 004FA000 04000000
>
> Have you fixed this?
>
> For 32 MBytes of DRAM you should have
> #define XPAR_DDR_0_SIZE 0x2000000
> in your xparameters_ml403.h file.
> I can't recall the whole story, but EDK 8.2 doesn't
> add this #define when generating the xparameters file,
> so I had to add this line by hand for EDK 8.2 generated
> files. Probably earlier EDK versions did that automatically.
>
> But your kernel (the bootwrapper to be precise) wouldn't compile
> if XPAR_DDR_0_SIZE were not defined...
> Do you use uboot?
>
> Thanks,
> Andrei
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/zImage.elf-loads-but-not-starts-tf3607582.html#a10805157
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Fix compiler/assembler flags for Ebony platform boot files
From: Dave Jiang @ 2007-05-25 15:01 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <1180101877.3360.39.camel@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Fri, 2007-05-25 at 13:19 +1000, David Gibson wrote:
>> The recent addition of assembler flags for 44x.c and ebony.c in the
>> bootwrapper to make them compile on certain toolchains was not correct
>> and could break other platforms. This patch switches to using a
>> compiler flag instead, which implies the appropriate assembler flag,
>> and also stops the compiler itself generating instructions which are
>> invalid for the platform in question.
>
> This looks good to me, but I don't have one of the failing toolchains.
> Dave, can you test this patch out?
>
> josh
>
Built ok for me after the patch.
^ permalink raw reply
* Re: [RFC 1/3] Re: [PATCH] mpc52xx_psc_spi: fix it for CONFIG_PPC_MERGE
From: Sylvain Munaut @ 2007-05-25 14:50 UTC (permalink / raw)
To: Domen Puncer; +Cc: Dragos Carp, domen.puncer, linuxppc-embedded
In-Reply-To: <20070525084304.GA23149@nd47.coderock.org>
NACK
Not at all what I meant ...
We should not modify port config in any automatic way, just let the boot
loader set it up.
If it known not to do it propertly, then in the platform file
(lite5200b, efika, ...)
adjust port config according to what's really on the board.
Sylvain
Domen Puncer wrote:
> Hi!
>
> I tried to fix these issues, like suggested.
>
> On 16/05/07 10:19 +0200, Sylvain Munaut wrote:
>
>> - Chaning port_config in the driver is just wrong ... you should _not_
>> do that. That should have been setup by the bootloader or at worse in
>> the platform setup code.
>>
>
> [ trimming spi-devel and dbrownell from cc: ]
>
> Setup gpio->port_config to match PSC's set in device tree.
>
> Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
>
> ---
> arch/powerpc/platforms/52xx/mpc52xx_common.c | 64 +++++++++++++++++++++++++++
> 1 file changed, 64 insertions(+)
>
> Index: work-powerpc.git/arch/powerpc/platforms/52xx/mpc52xx_common.c
> ===================================================================
> --- work-powerpc.git.orig/arch/powerpc/platforms/52xx/mpc52xx_common.c
> +++ work-powerpc.git/arch/powerpc/platforms/52xx/mpc52xx_common.c
> @@ -75,6 +75,68 @@ mpc52xx_find_ipb_freq(struct device_node
> }
> EXPORT_SYMBOL(mpc52xx_find_ipb_freq);
>
> +void __init
> +mpc52xx_setup_port_config(void)
> +{
> + struct mpc52xx_gpio __iomem *gpio;
> + struct device_node *np, *child = NULL;
> + u32 port_config;
> +
> + /* Map zones */
> + gpio = mpc52xx_find_and_map("mpc5200-gpio");
> + if (!gpio) {
> + printk(KERN_ERR __FILE__ ": "
> + "Error while mapping GPIO register for port config. "
> + "Expect some abnormal behavior\n");
> + return;
> + }
> +
> + /* Set port config */
> + port_config = in_be32(&gpio->port_config);
> +
> + np = of_find_node_by_type(NULL, "soc");
> + if (!np) {
> + printk(KERN_ERR "%s: %i can't find node with type 'soc'\n",
> + __func__, __LINE__);
> + iounmap(gpio);
> + return;
> + }
> +
> + while ((child = of_get_next_child(np, child))) {
> + if (of_device_is_compatible(child, "mpc5200-psc")) {
> + int ci = -1;
> + const int *pci;
> +
> + pci = of_get_property(child, "cell-index", NULL);
> + if (pci)
> + ci = *pci;
> + if (ci < 0 || ci > 5 || ci == 3 || ci == 4) {
> + printk(KERN_ALERT "%s: %i psc node '%s' has invalid "
> + "cell-index: %i\n", __func__, __LINE__,
> + child->name, ci);
> + continue;
> + }
> +
> + port_config &= ~(0x7 << ci*4);
> + if (strcmp(child->name, "ac97") == 0)
> + port_config |= 0x2 << ci*4; /* AC97 functionality */
> + else if (strcmp(child->name, "serial") == 0)
> + port_config |= 0x5 << ci*4; /* UARTe with CD */
> + else if (strcmp(child->name, "spi") == 0)
> + port_config |= 0x7 << ci*4; /* CODEC with MCLK */
> + else
> + printk(KERN_ALERT "%s: %i psc node '%s' not handled\n",
> + __func__, __LINE__, child->name);
> + }
> + }
> + of_node_put(np);
> +
> + pr_debug("port_config: old:%x new:%x\n",
> + in_be32(&gpio->port_config), port_config);
> + out_be32(&gpio->port_config, port_config);
> +
> + iounmap(gpio);
> +}
>
> void __init
> mpc52xx_setup_cpu(void)
> @@ -114,6 +176,8 @@ mpc52xx_setup_cpu(void)
> unmap_regs:
> if (cdm) iounmap(cdm);
> if (xlb) iounmap(xlb);
> +
> + mpc52xx_setup_port_config();
> }
>
> void __init
>
>
^ permalink raw reply
* Re: Fix compiler/assembler flags for Ebony platform boot files
From: Segher Boessenkool @ 2007-05-25 14:28 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <1180101877.3360.39.camel@zod.rchland.ibm.com>
> This looks good to me, but I don't have one of the failing toolchains.
> Dave, can you test this patch out?
You can test by using make CC="gcc -mcpu=e500" ...
Segher
^ permalink raw reply
* Re: TSI ethernet PHY question
From: Segher Boessenkool @ 2007-05-25 14:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, David Gibson, Alexandre Bounine
In-Reply-To: <18006.31742.533944.368969@cargo.ozlabs.ibm.com>
>> Only if you think the device tree is a configuration
>> mechanism for the OS.
>
> Well, actually, it's whatever we want it to be...
Oh not this discussion again.
> There is some value in making the device tree abstract and general,
> but not an overwhelming value that trumps all other considerations.
Yes, there can be other considerations; however, not making
a mess out of it all is certainly a very important one in
my book.
Segher
^ permalink raw reply
* Re: TSI ethernet PHY question
From: Segher Boessenkool @ 2007-05-25 14:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Alexandre Bounine, David Gibson, linuxppc-dev list
In-Reply-To: <1180058031.32247.1091.camel@localhost.localdomain>
>> However in this case you could put a property in the
>> PHY node, similar things have been done before. It's
>> ugly and doesn't solve any problem (it is just as much
>> work to parse the board model as to find this magic
>> property), and you *still* should pass in the flag
>> from the platform layer, and not have the phylib try
>> to handle it by itself.
>
> I disagree, it's not ugly and nicely solves the problem.
It doesn't solve the conceived problem that making this
a board-dependent workaround would be "too hard".
> For example, imagine you have 2 PHYs on a board and only one needs the
> workaround ? Really, the PHY node is the best place for it.
Then the board code will know that.
>> The ethernet driver is a powerpc-specific driver, that's
>> one thing. Also, the workaround should be initiated by
>> the platform code, so has to go through the ethernet driver
>> (since it instantiates the phylib driver).
>
> Still... it can be done via generic calls in powerpc ethernet drivers
> that set flags in phylib based on things in the device-tree.
Yes, exactly.
>> For many similar workarounds, the ethernet driver _does_ have
>> to cooperate in the workaround. For some other such workarounds,
>> the soc code has to be involved. Etc. etc.
>
>> You can do a quick "fix" now by doing this magic property
>> thing, and it sure is a *quick* fix; but later on you'll
>> have to do some other workarounds the proper way. And
>> you'll be stuck with the property forever. Not such a
>> big deal, sure; hey, I already _did_ say I'm okay with it,
>> right? It's just the "wrong" thing to do ;-)
>
> I have no bloody idea what you consider "the proper way"
Make board-specific workarounds triggered by the board code.
> I think it's the right thing to do.
And I don't :-) But I already said I'm okay with it, it's
only one property and it won't hurt anything else.
Segher
^ permalink raw reply
* Re: TSI ethernet PHY question
From: Segher Boessenkool @ 2007-05-25 14:17 UTC (permalink / raw)
To: David Gibson; +Cc: Alexandre Bounine, linuxppc-dev list
In-Reply-To: <20070525020059.GA13575@localhost.localdomain>
>> Since the specific bug we're talking about here is not a
>> problem with the PHY, but a miswiring on the board, I wouldn't
>> put a flag for the workaround in the phy node in the device
>> tree. It certainly is an option though.
>
> Uh.. something to bear in mind is that although it is a board
> miswiring, it's of a type that it will plausibly occur in other
> boards.
It is possible yes.
> IIRC, if a LED is attached to this PHY the workaround is
> necessary, or something similar.
Only if it is attached the wrong way, so it acts as a
pull-up (or was it pull-down) during chip reset.
> So there is value in having a
> particular flag for this rather than just looking at the board model.
A bit, maybe.
Segher
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Segher Boessenkool @ 2007-05-25 14:11 UTC (permalink / raw)
To: David Gibson; +Cc: Alexandre Bounine, linuxppc-dev list
In-Reply-To: <20070525043852.GH13575@localhost.localdomain>
> Waah! Third time lucky?
You wish :-)
> - Second, the PHYs give only "bcm54xx" as a compatible
> property. This is unfortunate, because there are many bcm54xx PHY
> models, and they have differences which can matter. We add a more
> precise compatible string, giving the precise PHY model (bcm5461A in
> this case).
You completely removed the "compatible" properties instead.
Bad idea.
Segher
^ permalink raw reply
* Re: Fix compiler/assembler flags for Ebony platform boot files
From: Josh Boyer @ 2007-05-25 14:04 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070525031917.GC13575@localhost.localdomain>
On Fri, 2007-05-25 at 13:19 +1000, David Gibson wrote:
> The recent addition of assembler flags for 44x.c and ebony.c in the
> bootwrapper to make them compile on certain toolchains was not correct
> and could break other platforms. This patch switches to using a
> compiler flag instead, which implies the appropriate assembler flag,
> and also stops the compiler itself generating instructions which are
> invalid for the platform in question.
This looks good to me, but I don't have one of the failing toolchains.
Dave, can you test this patch out?
josh
^ permalink raw reply
* Re: Fix compiler/assembler flags for Ebony platform boot files
From: Segher Boessenkool @ 2007-05-25 14:05 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070525031917.GC13575@localhost.localdomain>
> The recent addition of assembler flags for 44x.c and ebony.c in the
> bootwrapper to make them compile on certain toolchains was not correct
> and could break other platforms. This patch switches to using a
> compiler flag instead, which implies the appropriate assembler flag,
> and also stops the compiler itself generating instructions which are
> invalid for the platform in question.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: Josh Boyer @ 2007-05-25 14:03 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev list, Alexandre Bounine
In-Reply-To: <20070525043852.GH13575@localhost.localdomain>
On Fri, 2007-05-25 at 14:38 +1000, David Gibson wrote:
>
> Waah! Third time lucky?
Not quite. :)
> - Second, the PHYs give only "bcm54xx" as a compatible
> property. This is unfortunate, because there are many bcm54xx PHY
> models, and they have differences which can matter. We add a more
> precise compatible string, giving the precise PHY model (bcm5461A in
> this case).
You don't actually do this. Instead, you specify a
txc-rxc-delay-disable property.
> - PHY1: ethernet-phy@6000 {
> - device_type = "ethernet-phy";
> - compatible = "bcm54xx";
> - reg = <6000 50>;
> - phy-id = <1>;
> + PHY1: ethernet-phy@1 {
> + reg = <1>;
> + txc-rxc-delay-disable;
> };
I would have rather we left the compatible = "bmc5461A" as well. Though
perhaps a comment would suffice instead.
> Index: working-2.6/arch/powerpc/sysdev/tsi108_dev.c
> ===================================================================
> --- working-2.6.orig/arch/powerpc/sysdev/tsi108_dev.c 2007-05-25 14:34:00.000000000 +1000
> +++ working-2.6/arch/powerpc/sysdev/tsi108_dev.c 2007-05-25 14:38:32.000000000 +1000
> +
> tsi_eth_data.regs = r[0].start;
> tsi_eth_data.phyregs = res.start;
> tsi_eth_data.phy = *phy_id;
> tsi_eth_data.irq_num = irq_of_parse_and_map(np, 0);
> - if (of_device_is_compatible(phy, "bcm54xx"))
> +
> + if (of_get_property(phy, "txc-rxc-delay-disable", NULL))
> tsi_eth_data.phy_type = TSI108_PHY_BCM54XX;
> of_node_put(phy);
At the very least this needs a comment explaining what exactly is being
done here. Right now, it's looking for some magical property and
setting the PHY type to a Broadcom PHY... very confusing to someone
that hasn't followed the email thread.
josh
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Segher Boessenkool @ 2007-05-25 14:01 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <20070525013005.GB11789@localhost.localdomain>
>> No, those options _do_ work on 440, but the -mbooke
>> assembler flag disallows isel (since it is an optional
>> insn).
>
> But not on 440GP, which is what Ebony is.
I meant it is an optional insn in the arch.
-mcpu=440 doesn't enable isel, anyway; only -mcpu=e500
does in any FSF GCC release as far as I can see.
Segher
^ permalink raw reply
* Re: zImage.elf loads but does not start
From: Andrei Konovalov @ 2007-05-25 13:16 UTC (permalink / raw)
To: Miroslaw Dach; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0705152027280.16487-100000@slslc02.psi.ch>
Mirek,
Miroslaw Dach wrote:
> I do not know however if the stack is properly configured since I did not
> see any parameter in kernel which refers to the stack or heap.
>
> My bsp i.e xparameteres_ml403.h contains two macros:
> #define XPAR_DDR_SDRAM_1_MEM0_BASEADDR 0x00000000
> #define XPAR_DDR_SDRAM_1_MEM0_HIGHADDR 0x01FFFFFF
>
> I have the feeling that they are ignored because I did not find anywhere
> in the kernel source those names.
>
> When kernel boots it prints at the beginning:
> loaded at: 00400000 004F9138
> board data at: 004F7120 004F7138
> relocated to: 00404064 0040407C
> zimage at: 00404DF1 004F6BBB
> avail ram: 004FA000 04000000
Have you fixed this?
For 32 MBytes of DRAM you should have
#define XPAR_DDR_0_SIZE 0x2000000
in your xparameters_ml403.h file.
I can't recall the whole story, but EDK 8.2 doesn't
add this #define when generating the xparameters file,
so I had to add this line by hand for EDK 8.2 generated
files. Probably earlier EDK versions did that automatically.
But your kernel (the bootwrapper to be precise) wouldn't compile
if XPAR_DDR_0_SIZE were not defined...
Do you use uboot?
Thanks,
Andrei
^ permalink raw reply
* Re: Latest GCC/GLIBC working combo for a Linux 2.4.x kernel?
From: Clemens Koller @ 2007-05-25 12:54 UTC (permalink / raw)
To: Sasvata Chatterjee; +Cc: linuxppc-embedded
In-Reply-To: <a9fc2a630705241728q4d203569n6eb008cc65a7eba9@mail.gmail.com>
Hi, Sasvata!
> We are using a RHEL/386 machine to cross-compile for Debian/PowerPC
> (8260) target, a few year old embedded system that we inherited. The
> kernel is 2.4.9. Using crosstools, and following Dan Kegel's notes, the
> combo we have is gcc-2.95-3/glibc-2.2.5.
>
> Does anybody have any working version using newer versions of the 2.4
> kernel and newer GCC versions for a powerpc-603e target? One motivation
> is to use BusyBox-1.5.1, but I am told on that list that GCC 2/x is too
> old (I tried before I asked, it doesn't compile).
It's propably painful to work your way through crosstools with such an
old toolchain. I would have a look if one of the ELDK's from
http://www.denx.de can be used for your board - at least for a good start.
If you run into problems with older linux-2.4 kernel version with the newer ELDK's,
you can also go back to some older version?
> Any help, pointers, example config files for crosstools, etc. would be
> really appreciated!
You are always welcome at their mailing list. See:
http://kegel.com/crosstool
Best greets,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: MPC8560 Gianfar driver hangs after soft reboot
From: Clemens Koller @ 2007-05-25 12:42 UTC (permalink / raw)
To: Bill Farrow; +Cc: linuxppc-embedded
In-Reply-To: <34E73CC1202BF246B7DE3463BEBC068998EE82@postie.optiscan.com>
Hi, Bill!
Bill Farrow schrieb:
> The Gianfar driver is hanging during boot-up after a soft reboot. It
> works fine when the board is power cycled.
>
> Any hints on where to look further on this issue?
I have had some rare issues with PHY initialization on the PM854
with the u-boot-1.2.0 not being able to download something
via TFTP. There is an entry somewhere in the U-Boot wiki (I think)
that the TQM8540 board can have some issues... well the boards
are quite similar.
Pushing the reset button (Never needed to power that off) solves
the issue.
> 3. After rebooting, the system starts up Linux and it hangs after:
>
> eth0: Gianfar Ethernet Controller Version 1.2, 00:40:42:01:00:00
> eth0: Running with NAPI enabled
> eth0: 256/256 RX/TX BD ring size
The Kernels I 've tried (2.6.13 up to 2.6.21-rc5 and some latest gits)
never stopped there...
I would just try another kernel. Checkout the code in the latest
git.
> Also tried soft rebooting without the network cable and the kernel boots
> without hanging, but the network does not work when the re-connected.
> The PHY seems to be working because when we plug the cable back in it
> detects the link and writes this console message:
>
> [ 1557.465085] PHY: 0:01 - Link is Up - 100/Full
>
> Note that there are two Ethernet controllers on the board (eth0 and
> eth1). Only eth1 is connected to the network.
What PHY's do you have on these ports?
(MV88E1111 over here)
> Background info:
> Kernel version 2.6.20.4 PPC
> Uboot version 1.2.0
> Busybox version 1.5.0
> ELDK: 4.1
> JTAG: BDI-2000
> Board : Microsys PM856 - with MPC8560 processor.
Looks good. I am using the PM854.
Well, some other thing: I had some instabilities on my prototyping
hardware in the beginnging, but I guess due to EMI and the sloppy setup.
After I got all the stuff nailed down onto some aluminum-plate, the
boards is working _very_ stable (24/7).
Greets,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: zImage.elf loads but does not start
From: Mirek23 @ 2007-05-25 12:24 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <10681348.post@talk.nabble.com>
Hi All,
I have done more research on the problem with my ml403 board.
I use linux 2.6.21rc6 by Grant. I have configured the kernel to mount the
rootfile system via NFS.
The kernel boots properly up to the point to execute init.
My Last observation is as following.
I have written my own statically build init just to printf some strings to
the screen. The message is printed as expected. The size of my executable is
around 520 Kbytes.
When I have added more code to have a bigger executable I reached the point
when my init was sometimes executed and some times not (ie. the system
hanged and ping did not work) . This happens when the executable is around
647 Kbytes large.
I have aslo noticed that when the code is bigger than 700 Kbytes the system
hangs always.
To have more evidence I have compiled klibc rootfile system which is very
small but it uses dynamically linked library libc.so which is around 111
Kbytes. In such a case the init was executed fine so it seems to be the
problem of the file size the system is going to execute (load via NFS).
I suspect that it is the Temac which causes the problem. I do not however
know it is possible to adjust some temac parameters like the FIFOs size or
so. Maybe it is the Temac driver?
It could be also that NFS client server communication which brakes due to
unknown reason. My eteral program which I used to monitor the network
traffic on the NFS server shows that NFS server works all the time and it
sends periodically the packets to the client even if the client hags.
Would you have some idea what could be wrong?
Best Regards
Mirek
Mirek23 wrote:
>
>> Anyway, you could try adding
>> nfsroot=,rsize=1024,wsize=1024
>> to your cmdline just in case...
>
> I have tried that but it did not help :(
>
> Best Regards
>
> Mirek
>
--
View this message in context: http://www.nabble.com/zImage.elf-loads-but-not-starts-tf3607582.html#a10801964
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules
From: Kumar Gala @ 2007-05-25 12:15 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Paul
In-Reply-To: <989B956029373F45A0B8AF0297081890B768A2@zch01exm26.fsl.freescale.net>
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
^ permalink raw reply
* Re: [patch 5/7] ps3: Disk Storage Driver
From: Olaf Hering @ 2007-05-25 11:45 UTC (permalink / raw)
To: Geert.Uytterhoeven; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20070525083632.575306000@sonycom.com>
On Fri, May 25, Geert.Uytterhoeven@sonycom.com wrote:
> Add a Disk Storage Driver for the PS3:
There is no device symlink in /sys/block/ps3da/
^ permalink raw reply
* Re: [patch 6/7] ps3: ROM Storage Driver
From: Olaf Hering @ 2007-05-25 11:24 UTC (permalink / raw)
To: Geert.Uytterhoeven; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20070525083632.677742000@sonycom.com>
On Fri, May 25, Geert.Uytterhoeven@sonycom.com wrote:
> +++ b/drivers/scsi/ps3rom.c
> + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
linux/highmem.h is not included to get the kmap_* prototypes.
^ permalink raw reply
* Re: Badness at include/linux/slub_def.h
From: Michel Dänzer @ 2007-05-25 9:05 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, linux-kernel, dri-devel
In-Reply-To: <Pine.LNX.4.64.0705202304530.14522@sheep.housecafe.de>
On Sun, 2007-05-20 at 23:10 +0100, Christian Kujau wrote:
>
> [41653.487050] Badness at include/linux/slub_def.h:77
> [41653.487060] Call Trace:
> [41653.487068] [ecafbcb0] [c0008d00] show_stack+0x3c/0x194 (unreliable)
> [41653.487097] [ecafbce0] [c01426d4] report_bug+0x84/0xf4
> [41653.487116] [ecafbcf0] [c0010280] program_check_exception+0xbc/0x530
> [41653.487137] [ecafbd20] [c0011f8c] ret_from_except_full+0x0/0x4c
> [41653.487154] --- Exception: 700 at get_slab+0x248/0x260
> [41653.487168] LR = __kmalloc+0x1c/0x9c
> [41653.487176] [ecafbde0] [101dfbc8] 0x101dfbc8 (unreliable)
> [41653.487213] [ecafbe10] [c0080398] __kmalloc+0x1c/0x9c
> [41653.487227] [ecafbe30] [c01c2150] drm_rmdraw+0x26c/0x29c
> [41653.487243] [ecafbe80] [c01c2b74] drm_ioctl+0xe0/0x250
> [41653.487257] [ecafbeb0] [c00924a0] do_ioctl+0x9c/0xa8
> [41653.487273] [ecafbed0] [c0092530] vfs_ioctl+0x84/0x490
> [41653.487287] [ecafbf10] [c009297c] sys_ioctl+0x40/0x74
> [41653.487301] [ecafbf40] [c0011930] ret_from_syscall+0x0/0x38
> [41653.487315] --- Exception: c01 at 0xfd132a8
> [41653.487327] LR = 0xfd13240
Does the patch below against the drm tree fix it? Only build tested.
---
>From f0e6bdc165cb484b8992b14172a7280f301bf513 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michel_D=C3=A4nzer?= <michel@tungstengraphics.com>
Date: Fri, 25 May 2007 11:02:05 +0200
Subject: Make sure the drawable code doesn't call malloc(0).
Signed-off-by: Michel Dänzer <michel@tungstengraphics.com>
---
linux-core/drm_drawable.c | 41 ++++++++++++++++++++++++++---------------
1 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/linux-core/drm_drawable.c b/linux-core/drm_drawable.c
index 0817e32..b540a0e 100644
--- a/linux-core/drm_drawable.c
+++ b/linux-core/drm_drawable.c
@@ -172,38 +172,49 @@ int drm_rmdraw(DRM_IOCTL_ARGS)
bitfield_length = idx + 1;
- if (idx != id / (8 * sizeof(*bitfield)))
- bitfield = drm_alloc(bitfield_length *
- sizeof(*bitfield), DRM_MEM_BUFS);
+ bitfield = NULL;
- if (!bitfield && bitfield_length) {
- bitfield = dev->drw_bitfield;
- bitfield_length = dev->drw_bitfield_length;
+ if (bitfield_length) {
+ if (bitfield_length != dev->drw_bitfield_length)
+ bitfield = drm_alloc(bitfield_length *
+ sizeof(*bitfield),
+ DRM_MEM_BUFS);
+
+ if (!bitfield) {
+ bitfield = dev->drw_bitfield;
+ bitfield_length = dev->drw_bitfield_length;
+ }
}
}
if (bitfield != dev->drw_bitfield) {
info_length = 8 * sizeof(*bitfield) * bitfield_length;
- info = drm_alloc(info_length * sizeof(*info), DRM_MEM_BUFS);
+ if (info_length) {
+ info = drm_alloc(info_length * sizeof(*info),
+ DRM_MEM_BUFS);
- if (!info && info_length) {
- info = dev->drw_info;
- info_length = dev->drw_info_length;
- }
+ if (!info) {
+ info = dev->drw_info;
+ info_length = dev->drw_info_length;
+ }
+ } else
+ info = NULL;
spin_lock_irqsave(&dev->drw_lock, irqflags);
- memcpy(bitfield, dev->drw_bitfield, bitfield_length *
- sizeof(*bitfield));
+ if (bitfield)
+ memcpy(bitfield, dev->drw_bitfield, bitfield_length *
+ sizeof(*bitfield));
drm_free(dev->drw_bitfield, sizeof(*bitfield) *
dev->drw_bitfield_length, DRM_MEM_BUFS);
dev->drw_bitfield = bitfield;
dev->drw_bitfield_length = bitfield_length;
if (info != dev->drw_info) {
- memcpy(info, dev->drw_info, info_length *
- sizeof(*info));
+ if (info)
+ memcpy(info, dev->drw_info, info_length *
+ sizeof(*info));
drm_free(dev->drw_info, sizeof(*info) *
dev->drw_info_length, DRM_MEM_BUFS);
dev->drw_info = info;
--
1.5.2-rc3.GIT
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply related
* [Patch ] Kexec/Kdump support - POWER6
From: Sachin P. Sant @ 2007-05-25 8:55 UTC (permalink / raw)
To: Olof Johansson, Paul Mackerras; +Cc: linuxppc-dev, kexec, Milton Miller II
In-Reply-To: <20070524142133.GA13191@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 460 bytes --]
Olof Johansson wrote:
> As Paul says above, you need to check for failures and compare the VSID
> and possibly unhash it anyway in case of non-match. Otherwise if the
> kernel ever starts using 1TB segments for regular use, those pages will
> never be unhashed. I don't see your code doing that now.
>
>
How about the following patch ?
Thanks
-Sachin
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
Signed-off-by : Mohan Kumar M <mohan@in.ibm.com>
---
[-- Attachment #2: kexec-kdump-support-on-POWER6 --]
[-- Type: text/plain, Size: 2524 bytes --]
* On Power machines supporting VRMA, Kexec/Kdump does not work.
* Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables.
* Make sure these hpte entries are left untouched.
*
* This patch also adds plpar_pte_read_raw() on the lines of
* plpar_pte_remove_raw().
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
Signed-off-by : Mohan Kumar M <mohan@in.ibm.com>
---
diff -Naurp a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
--- a/arch/powerpc/platforms/pseries/lpar.c 2007-05-19 09:36:17.000000000 +0530
+++ b/arch/powerpc/platforms/pseries/lpar.c 2007-05-25 14:09:59.000000000 +0530
@@ -369,16 +369,30 @@ static long pSeries_lpar_hpte_remove(uns
return -1;
}
+#define VRMA_HPTE_B_1TB ASM_CONST(0x4000000000000000)
+#define VRMA_MASK ASM_CONST(0x4001ffffff)
+
static void pSeries_lpar_hptab_clear(void)
{
unsigned long size_bytes = 1UL << ppc64_pft_size;
unsigned long hpte_count = size_bytes >> 4;
- unsigned long dummy1, dummy2;
+ unsigned long dummy1, dummy2, dword0;
+ long lpar_rc;
int i;
/* TODO: Use bulk call */
- for (i = 0; i < hpte_count; i++)
- plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2);
+ for (i = 0; i < hpte_count; i++) {
+ /* dont remove HPTEs with VRMA mappings */
+ lpar_rc = plpar_pte_remove_raw(H_ANDCOND, i, VRMA_HPTE_B_1TB,
+ &dummy1, &dummy2);
+ if (lpar_rc == H_NOT_FOUND) {
+ lpar_rc = plpar_pte_read_raw(0, i, &dword0, &dummy1);
+ if (!lpar_rc &&
+ (((dword0 >> 24) & VRMA_MASK) != VRMA_MASK))
+ /* Can be hpte for 1TB Seg. So remove it */
+ plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2);
+ }
+ }
}
/*
diff -Naurp a/arch/powerpc/platforms/pseries/plpar_wrappers.h b/arch/powerpc/platforms/pseries/plpar_wrappers.h
--- a/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-19 09:36:17.000000000 +0530
+++ b/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-05-25 12:20:38.000000000 +0530
@@ -108,6 +108,21 @@ static inline long plpar_pte_read(unsign
return rc;
}
+/* plpar_pte_read_raw can be called in real mode. It calls plpar_hcall_raw */
+static inline long plpar_pte_read_raw(unsigned long flags, unsigned long ptex,
+ unsigned long *old_pteh_ret, unsigned long *old_ptel_ret)
+{
+ long rc;
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+
+ rc = plpar_hcall_raw(H_READ, retbuf, flags, ptex);
+
+ *old_pteh_ret = retbuf[0];
+ *old_ptel_ret = retbuf[1];
+
+ return rc;
+}
+
static inline long plpar_pte_protect(unsigned long flags, unsigned long ptex,
unsigned long avpn)
{
^ permalink raw reply
* [RFC 3/3] Re: [PATCH] mpc52xx_psc_spi: fix it for CONFIG_PPC_MERGE
From: Domen Puncer @ 2007-05-25 8:47 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Dragos Carp, David Brownell, linuxppc-embedded
In-Reply-To: <464ABE97.7090603@246tNt.com>
On 16/05/07 10:19 +0200, Sylvain Munaut wrote:
>
> Well, this comment is not about the patch but about the driver it self,
> I didn't see it before today.
> So here's a few things I see from a quick glance at the code :
>
> - Chaning port_config in the driver is just wrong ... you should _not_
> do that. That should have been setup by the bootloader or at worse in
> the platform setup code.
> - You do read/write/modify operation on CDM shared register
> (clk_enables) from a driver, you should have added something in common
> 52xx code to do theses with proper locking.
> - MPC52xx_PA(MPC52xx_PSCx_OFFSET(...)) ??? You should get that from the
> resource of the platform_device. This macro is just there for early
> console stuff.
> - You can get f_system from the device tree instead of just assuming
> it's 512 MHz. It probably need to be done the same way it's done to find
> ipb_freq.
> - Would have been nice to be able to somehow configure MCLK rather than
> #define it
> - I hope to remove all arch/ppc stuff by 2.6.23 if I can make the
> cuimage stuff work in arch/powerpc so just including the platform code
> stuff for 1 kernel version ...
>
>
> Sylvain
[ trimming spi-devel from cc: ]
For clk.h, it does seem quite some code, compared what's there currently.
Comments?
Use previous two patches (port_config, clk.h).
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
drivers/spi/mpc52xx_psc_spi.c | 49 +++++++++++++++++++++++++++++++++++++-----
1 file changed, 44 insertions(+), 5 deletions(-)
Index: work-powerpc.git/drivers/spi/mpc52xx_psc_spi.c
===================================================================
--- work-powerpc.git.orig/drivers/spi/mpc52xx_psc_spi.c
+++ work-powerpc.git/drivers/spi/mpc52xx_psc_spi.c
@@ -18,6 +18,7 @@
#if defined(CONFIG_PPC_MERGE)
#include <asm/of_platform.h>
+#include <linux/clk.h>
#else
#include <linux/platform_device.h>
#endif
@@ -106,13 +107,52 @@ static void mpc52xx_psc_spi_activate_cs(
/* Set clock frequency and bits per word
* Because psc->ccr is defined as 16bit register instead of 32bit
* just set the lower byte of BitClkDiv
+ * Because BitClkDiv is 8-bit on mpc5200. Lets stay compatible.
*/
+#if defined(CONFIG_PPC_MERGE)
ccr = in_be16(&psc->ccr);
ccr &= 0xFF00;
+ {
+ u8 bitclkdiv = 2; /* minimum bitclkdiv */
+ int speed = cs->speed_hz ? cs->speed_hz : 1000000;
+ char clk_name[10];
+ struct clk *clk; // TODO into mps, clk_get, clk_put
+ int mclk;
+ int system;
+ /*
+ * pscclk = mclk/(bitclkdiv+1)) bitclkdiv is 8-bit, >= 2
+ * mclk = fsys/(mclkdiv+1) mclkdiv is 9-bit, >= 1
+ * as mclkdiv has higher precision, we want is as big as possible
+ * => we get < 0.002*clock error
+ */
+
+ snprintf(clk_name, 10, "psc%i_mclk", spi->master->bus_num);
+
+ clk = clk_get(&spi->dev, clk_name);
+ if (!clk)
+ dev_err(&spi->dev, "couldn't get %s clock\n", clk_name);
+
+ system = clk_get_rate(clk_get_parent(clk)); // TODO, checking, refcounting
+ mclk = speed * (bitclkdiv+1);
+ if (system/mclk > 512) { /* bigger than mclkdiv */
+ bitclkdiv = system/512/speed;
+ mclk = speed * (bitclkdiv+1);
+ }
+
+ if (clk_set_rate(clk, mclk))
+ dev_err(&spi->dev, "couldn't set %s's rate\n", clk_name);
+
+ dev_info(&spi->dev, "clock: wanted: %i, got: %li\n", speed,
+ clk_round_rate(clk, mclk) / (bitclkdiv+1));
+
+ ccr |= bitclkdiv;
+ }
+#else
if (cs->speed_hz)
ccr |= (MCLK / cs->speed_hz - 1) & 0xFF;
else /* by default SPI Clk 1MHz */
ccr |= (MCLK / 1000000 - 1) & 0xFF;
+#endif
out_be16(&psc->ccr, ccr);
mps->bits_per_word = cs->bits_per_word;
@@ -328,13 +368,9 @@ static int mpc52xx_psc_spi_port_config(i
u32 mclken_div;
int ret = 0;
-#if defined(CONFIG_PPC_MERGE)
- cdm = mpc52xx_find_and_map("mpc5200-cdm");
- gpio = mpc52xx_find_and_map("mpc5200-gpio");
-#else
+#if !defined(CONFIG_PPC_MERGE)
cdm = ioremap(MPC52xx_PA(MPC52xx_CDM_OFFSET), MPC52xx_CDM_SIZE);
gpio = ioremap(MPC52xx_PA(MPC52xx_GPIO_OFFSET), MPC52xx_GPIO_SIZE);
-#endif
if (!cdm || !gpio) {
printk(KERN_ERR "Error mapping CDM/GPIO\n");
ret = -EFAULT;
@@ -390,6 +426,7 @@ static int mpc52xx_psc_spi_port_config(i
ret = -EINVAL;
goto unmap_regs;
}
+#endif
/* Reset the PSC into a known state */
out_8(&psc->command, MPC52xx_PSC_RST_RX);
@@ -413,11 +450,13 @@ static int mpc52xx_psc_spi_port_config(i
mps->bits_per_word = 8;
+#if !defined(CONFIG_PPC_MERGE)
unmap_regs:
if (cdm)
iounmap(cdm);
if (gpio)
iounmap(gpio);
+#endif
return ret;
}
^ 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