Re: MPC5200 fec frame corruption
Hi Asier, > We have been working with the MPC5200 fec and a linux-2.6.10 with some > patches extracted from Sylvain's bitkeeper repository. We have 3 > different boards that worked properly with that kernel. > > We upgraded to the new MPC5200B and it still worked properly with the > 2.6.10 kernel. > > We upgraded to the new code of the Sylvain's git repository and the FEC > transmitted frames are corrupted. This corruption only happens with the > current git repository and the MPC5200B. > > MPC5200 MPC5200B > linux-2.6.10: OK OK > Sylvain's git:OK CORRUPT > I must admit I don't have bitkeeper anymore installed on my machine so I don't remeber exactly what in there. Could you put somewhere on line the diff between 2.6.10 and you tree, eventually minus all the irrelevant/confidential stuff ? What would be needed woud be the arch/ppc/syslib/bestcomm , drivers/net/fec_mpc52xx and the board setup code. > The problem is that the lite5200 and the lite5200b work flawlessly, but > our architecture is essentialy the same but with different PHYs (Marvell > 88E6095F and 88E6060). Our architecture works properly with the > linux-2.6.10, so we don't think that it is a hardware related problem. > We have been watching the MII bus by osciloscope and the errors are > clearly transmitted by the MPC5200B (no noise or distortion). > > We have inserted traces in the functions of the FEC driver with the > buffer information that is sent to the DMA and the frames are correct. > > > [... logs stripped ...] > The corrupted bytes are sometimes correct, sometimes overwriten > by the byte that is 0x20 bytes before, and sometimes changed > by the bytes that is 0x40 bytes before. About 50% of the time > the marked bytes are worong. > > I'd like to know if anything here makes any sense to you, so > that I can understand the origin of the problem, or any > additional test to perform. > Any sense not really. But I would check first the options in the board setup. Things like cache snooping, comm bus prefetching, xlb priority settings and pipelining, ... Then the microcode of the task themselves and the options wich are used when loading them. Finally compare the driver code itself. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] General CHRP/MPC5K2 platform support patch
John Rigby wrote: >> >> * mpc5k2_bestcomm.c (& helpers): I've been in contact with others people >> using bestcomm and please to see the development was still active. I'm >> already using latest code on my board but this is not include in this >> patch. Indeed, it needs some changes for ARCH=powerpc. Moreover, we have >> a different approach for the tasks. I'll be pleased to work with the >> bestcomm folks. >> > > So you preload the bestcomm task code in your boot loader? Do those > of us using other bootloaders still have the option of loading the > task code later in linux? > > What api are you using? Sylvain's proposed one based on Dale's with > some additions from me? Or have you come up with your own? > Hi John, I've sent him the latest API you describe. As for task preloading, I'm not too sure what Nicolas' plan is. I'm waiting to see what he's proposing. Since the bestcomm init is in a module, a different module could be implemented, (like bestcomm-chrp5k2.ko) that instead of clearing SRAM and doing everything from scrtch, would rely on the bootloader more. This would allow "custom" tasks to be marked as "don't touch". So if the bootloader want to load something that will not be altered by the linux driver (for whatever reason ...) However, for the tasks like FEC and ATA and everything supported in the kernel natively, I would still recommend reload the task code (anyway the driver is gonna reset the task and everything ...) Trying to reuse the microcode loaded by the bootloader is not a great idea IMHO. (Imagine, the fec driver is changed to use the latest microcode, but the bootloader is not ... both have to be in perfect sync ...) We would still have to compare the internal FDT and the preloaded one though since they have to match ... Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] General CHRP/MPC5K2 platform support patch
Hi Nicolas,
I don't have much to add to what's already been posted, so here's a
couple of details,
mainly compatibility concerns with the legacy arch/ppc tree.
>
> diff -uprN a/include/asm-ppc/mpc52xx.h b/include/asm-ppc/mpc52xx.h
> --- a/include/asm-ppc/mpc52xx.h 2006-10-25 19:07:48.0 +0200
> +++ b/include/asm-ppc/mpc52xx.h 2006-10-25 19:11:55.0 +0200
> @@ -119,7 +119,7 @@ enum ppc_sys_devices {
> #define MPC52xx_SDMA_IRQ_NUM 17
> #define MPC52xx_PERP_IRQ_NUM 23
>
> -#define MPC52xx_CRIT_IRQ_BASE1
> +#define MPC52xx_CRIT_IRQ_BASE0
As explained in IRC, I'm not sure about this.
I was previously talked into applying this to avoid using interrupt
number 0. In the LITE5200 IRQ0 is used for PCI. It's interrupt number
is equal to MPC52xx_CRIT_IRQ_BASE and if it's 0 some drivers just don't
work.
That's when using the arch/ppc code. Apparently this is no longer an
issue in arch/powerpc (someone to confirm and explain me why ? I would guess
the irq_linear_revmap thingie ), but can a "standard" lite5200 be booted
in a arch/powerpc kernel ?
So if no critical, I would postpone that change until it's confirmed
a lite5200 can boot ...
> -extern int mpc52xx_get_irq(void);
> +extern unsigned int mpc52xx_get_irq(void);
Mmmh, the one in arch/ppc is not unsigned but I guess the warning is fine.
Finally, some triviality : The patch adds some space on empty lines. Also,
the indentation is sometimes done with space and sometimes with space ...
Sylvain
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: status of mpc52xx with arch=powerpc?
Grant Likely wrote:
> On 10/26/06, John Rigby <[EMAIL PROTECTED]> wrote:
>> Does Bestcomm dma belong in here somewhere?
>
> I don't think so for embedded targets; but I may be wrong. Of course;
> I think the kernel should be responsible for setting up the bestcomm
> tasks. If a spec is defined for how firmware could preload bestcomm
> tasks, then maybe.
Yes, we discussed that on IRC.
For I got from it would be something like that :
We would use the API we worked earlier on (Dale, Andrey, John, ...).
To add support of fw preloaded task :
- The bestcomm.ko module would be used when bestcomm is completely
controlled by the kernel
- A different module but with the same exported function would be used
when the fw has a part to play in the init. That allows to customize a bunch
of the sdma init / sram mapping ...
- All the other code (task helpers / the .h / the driver api) would be
exactly
the same.
- Currently the task support code (the arch/ppc/syslib/fec.c for example in
the current code) does this :
struct sdma_task *tsk;
tsk = sdma_task_alloc(queue_len, sizeof(struct sdma_fec_bd));
if (!tsk)
return NULL;
To reuse the preloaded task, it would be changed to
tsk = sdma_task_find_by_name("fec", 0);
if (!tsk)
tsk = sdma_task_alloc("fec", 0, queue_len, sizeof(struct
sdma_fec_bd));
if (!tsk)
return NULL;
So the bestcomm modules maintain a list with all task loaded with a name and
a index attribute. (The index would be used when there is multiple
device with
the same name, like "psc". We could use names like "psc1", "psc2". But that
would imply string manipulation to "create" the name string ;)
In the case of the "classic" (kernel handles it all), the table of task
is just
initially empty. But for the "custom" case, it's filled with whatever
the fw has
passed as infos.
Sylvain
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] General CHRP/MPC5K2 platform support patch
FWIW, Looks good to me too.
Acked-by: Sylvain Munaut <[EMAIL PROTECTED]>
It will need some changes when we'll get rid of the need to stay compatible
with arch/ppc. This will hopefully be soon and getting this in should help
get things moving imho.
Sylvain
Grant Likely wrote:
> My comments are satisfied
>
> Acked-by: Grant Likely <[EMAIL PROTECTED]>
>
> On 10/26/06, Nicolas DET <[EMAIL PROTECTED]> wrote:
>> Grant Likely wrote:
>>
>> >> +
>> >> +struct device_node *find_mpc52xx_pic(void)
>> >> +{
>> >> + struct device_node *dev;
>> >> + const char *piccompatible_list[] =
>> >> + {
>> >> + "mpc5200-interrupt-controller",
>> >> + "mpc52xx-interrupt-controller",
>> >> + "mpc52xx-pic",
>> >> + "mpc5200-pic",
>> >> + "5200-interrupt-controller",
>> >> + "52xx-interrupt-controller",
>> >> + "52xx-pic",
>> >> + "5200-pic",
>> >> + NULL
>> >> + };
>> >
>> > Considering Efika is the *only* CHRP 52xx board out there at the
>> > moment, and only a handful of embedded folks trying to move it to
>> > arch/powerpc, surely we can come to an agreement now on what this
>> > thing is named. :)
>> >
>> >
>>
>> Done
>>
>>
>>
>>
>> --- a/arch/powerpc/sysdev/Makefile 2006-10-25 19:07:24.0
>> +0200
>> +++ b/arch/powerpc/sysdev/Makefile 2006-10-26 11:38:02.0
>> +0200
>> @@ -13,6 +13,7 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o
>> obj-$(CONFIG_PPC_TODC) += todc.o
>> obj-$(CONFIG_TSI108_BRIDGE)+= tsi108_pci.o tsi108_dev.o
>> obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
>> +obj-$(CONFIG_PPC_MPC52xx_PIC) += mpc52xx_pic.o
>>
>> ifeq ($(CONFIG_PPC_MERGE),y)
>> obj-$(CONFIG_PPC_I8259)+= i8259.o
>> --- a/arch/powerpc/sysdev/mpc52xx_pic.c 1970-01-01 01:00:00.0
>> +0100
>> +++ b/arch/powerpc/sysdev/mpc52xx_pic.c 2006-10-26 21:32:05.0
>> +0200
>> @@ -0,0 +1,363 @@
>> +/*
>> + * arch/powerpc/sysdev/mpc52xx_pic.c
>> + *
>> + * Programmable Interrupt Controller functions for the Freescale
>> MPC52xx
>> + * embedded CPU.
>> + * Modified for CHRP Efika 5K2
>> + *
>> + * Maintainer : Sylvain Munaut <[EMAIL PROTECTED]>
>> + *
>> + * Based on (well, mostly copied from) the code from the 2.4 kernel by
>> + * Dale Farnsworth <[EMAIL PROTECTED]> and Kent Borg.
>> + *
>> + * Copyright (C) 2004 Sylvain Munaut <[EMAIL PROTECTED]>
>> + * Copyright (C) 2003 Montavista Software, Inc
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> License
>> + * version 2. This program is licensed "as is" without any warranty
>> of any
>> + * kind, whether express or implied.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +static struct mpc52xx_intr __iomem *intr;
>> +static struct mpc52xx_sdma __iomem *sdma;
>> +
>> +static struct irq_host *mpc52xx_irqhost = NULL;
>> +
>> +static void mpc52xx_ic_disable(unsigned int virq)
>> +{
>> + u32 val;
>> + int irq;
>> +
>> + irq = irq_map[virq].hwirq;
>> +
>> + pr_debug("%s: irq=%d\n", __func__, irq);
>> +
>> + if (irq == MPC52xx_IRQ0) {
>> + val = in_be32(&intr->ctrl);
>> + val &= ~(1 << 11);
>> + out_be32(&intr->ctrl, val);
>> + } else if (irq < MPC52xx_IRQ1) {
>> + BUG();
>> + } else if (irq <= MPC52xx_IRQ3) {
>> + val = in_be32(&intr->ctrl);
>> + val &= ~(1 << (10 - (irq - MPC52xx_IRQ1)));
>> + out_be32(&intr->ctrl, val);
>> + } else if (irq < MPC52xx_SDMA_IRQ_BASE) {
>> + val = in_be32(&intr->main_mask);
>> + val |= 1 << (16 - (irq - MPC52xx_MAIN_IRQ_BASE));
>> + out_be32(&intr-
Re: [PATCH] General CHRP/MPC5K2 platform support patch
Hi Nicolas,
Here is a few comments. I'm not very familiar with the new irq stuff so
others
might have more insights.
Sylvain
> --- a/arch/powerpc/sysdev/mpc52xx_pic.c 1970-01-01 01:00:00.0
> +0100
> +++ b/arch/powerpc/sysdev/mpc52xx_pic.c 2006-10-27 15:58:29.0
> +0200
> @@ -0,0 +1,414 @@
> +/*
> + * arch/powerpc/sysdev/mpc52xx_pic.c
>
Looks like jdl is right, we apparently don't do that any more ... So
let's not ;)
> + * Based on (well, mostly copied from) the code from the 2.4 kernel by
> + * Dale Farnsworth <[EMAIL PROTECTED]> and Kent Borg.
>
That can be removed ... We can't blame Dale anymore if it doesn't work ;)
> +
> +static void mpc52xx_ic_mask_and_ack(unsigned int irq)
> +{
> + mpc52xx_ic_mask(irq);
> + mpc52xx_ic_ack(irq);
> +}
>
>From kernel/irq/chip.c that's done automatically if mask_and_ack is NULL.
> +
> +static struct irq_chip mpc52xx_irqchip = {
> + .typename = " MPC52xx ",
> + .mask = mpc52xx_ic_mask,
> + .unmask = mpc52xx_ic_unmask,
> + .mask_ack = mpc52xx_ic_mask_and_ack,
> +};
Is it useful to implement set_type for IRQ[0-3] ? (Just asking ...)
> + for (i = 0; i < NR_IRQS; i++) {
> + irq_desc[i].chip = &mpc52xx_irqchip;
> + irq_desc[i].status = IRQ_LEVEL;
> +
> + }
>
All LEVEL ?
> +
> + /*
> + * As last step, add an irq host to translate the real
> + * hw irq information provided by the ofw to linux virq
> + */
> +
> + mpc52xx_irqhost =
> + irq_alloc_host(IRQ_HOST_MAP_LINEAR, NR_IRQS, &mpc52xx_irqhost_ops,
> +-1);
> +}
>
NR_IRQS ? Might be time to do something better.
> diff -uprN a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
> --- a/include/asm-powerpc/mpc52xx.h 1970-01-01 01:00:00.0 +0100
> +++ b/include/asm-powerpc/mpc52xx.h 2006-10-27 15:51:55.0 +0200
> @@ -0,0 +1,414 @@
> +/*
> + * include/asm-ppc/mpc52xx.h
> + *
> + * Prototypes, etc. for the Freescale MPC52xx embedded cpu chips
> + * May need to be cleaned as the port goes on ...
> + *
> + *
> + * Maintainer : Sylvain Munaut <[EMAIL PROTECTED]>
> + *
> + * Originally written by Dale Farnsworth <[EMAIL PROTECTED]>
> + * for the 2.4 kernel.
>
Again, remove all that (just leave the first line of the description)
> +
> +/*
> */
> +/* IRQ mapping
> */
> +/*
> */
> +
> +#define MPC52xx_IRQ_L1_CRIT 0
> +#define MPC52xx_IRQ_L1_MAIN 1
> +#define MPC52xx_IRQ_L1_PERP 2
> +#define MPC52xx_IRQ_L1_SDMA 3
> +
> +#define MPC52xx_IRQ_L1_OFFSET (6)
> +#define MPC52xx_IRQ_L1_MASK(0xc0)
> +
> +#define MPC52xx_IRQ_L2_OFFSET (0)
> +#define MPC52xx_IRQ_L2_MASK(0x3f)
>
As benh suggested on IRC, a L1 offset of 8 might be better for
readability of the
hw irq numbers.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] Add MPC52xx Interrupt controller support for ARCH=powerpc
Kumar Gala wrote:
> On Oct 29, 2006, at 5:10 PM, Nicolas DET wrote:
>
>
>> This patch add MPC52xx Interrupt controller for ARCH=powerpc.
>>
>> It includes the main code in arch/powerpc/sysdev/ ad well as an
>> header file in
>> include/asm-powerpc.
>>
>> Signed-off-by: Nicolas DET <[EMAIL PROTECTED]>
>>
>
> Can you see if you can figure out how to inline patches with your
> mailer, its really difficult to comment on issues w/an attachment.
>
.There are also scripts to post patches ... So you're sure it's not mangled
or anything.
> +/* MBAR position */
> +#define MPC52xx_MBAR 0xf000 /* Phys address */
> +#define MPC52xx_MBAR_VIRT0xf000 /* Virt address */
> +#define MPC52xx_MBAR_SIZE0x0001
> +
> +#define MPC52xx_PA(x)((phys_addr_t)(MPC52xx_MBAR + (x)))
> +#define MPC52xx_VA(x)((void __iomem *)(MPC52xx_MBAR_VIRT +
> (x)))
>
> This should be handled dynamically (pulled from the device tree), I
> doubt MBAR will be at the same location for all boards.
>
Agreed.
A little explanation on why they were used before :
the _VA was used for very early access (mostly boot debug) before
anything is setup.
the _PA was used for addresses used at several places. Like, a lot of
driver / code
needs to access XLB and there was not much way to distribute that
address around.
Now with the device tree that should be doable.
Having a nice function/helper
void *find_and_map_my_good_old_register_set(char *)
that would find and ioremap it for you would be nice ;) like
struct mpc52xx_xlb __iomem *xlb_regs =
find_and_map_my_good_old_register_set("xlb");
> * lets drop all the other struct defn in mpc52xx.h. This is a hold
> over from arch/ppc and we really should only put defn that we
> actually need closer to the code that uses them (ie, drivers, etc.)
>
Most of the struct that were in mpc52xx.h are the ones used in more than
one driver.
(or don't really belong to a driver)
That's why they've been left there and not in the driver header, so I
would leave those
there.
(e.g. the IDE struct is not there, neither is the FEC. But sdma is used
at several place
for example, so is rtc, xlb and cdm, ...)
Personnal note to Nicolas : It may seem a long process to just post a
patch but
since it imports a new platform to the arch/powerpc, it kinda requires
to make all
the due cleanups ;)
Sylvain
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] Add MPC52xx Interrupt controller support for ARCH=powerpc
Dale Farnsworth wrote:
> In article <[EMAIL PROTECTED]> Nicolas wrote:
>
>> This patch add MPC52xx Interrupt controller for ARCH=powerpc.
>>
>> It includes the main code in arch/powerpc/sysdev/ ad well as an header
>> file in include/asm-powerpc.
>>
>> Signed-off-by: Nicolas DET <[EMAIL PROTECTED]>
>>
>
> NAK.
>
> Two requests:
> 1. Please include patches inline so that they may be easily reviewed.
> 2. Please do not remove copyright lines from files you modify.
>
Indeed.
Dale Farnsworth wrote:
> Wow, the source code size sure ballooned in this revision.
>
> I'd like to see us go the other direction, with something like the
> following (untested code).
>
Well that's kind of a contradiction with what benh asked (separate IC
chips).
> static inline void io_be_setbit(u32 __iomem *addr, int bitno)
> {
> out_be32(addr, in_be32(addr) | 1 << bitno);
> }
>
> static inline void io_be_clrbit(u32 __iomem *addr, int bitno)
> {
> out_be32(addr, in_be32(addr) & ~(1 << bitno));
> }
>
Those could still be used to cleanup a little the code.
Sylvain
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] Add MPC52xx Interrupt controller support for ARCH=powerpc
Kumar Gala wrote: >>> * lets drop all the other struct defn in mpc52xx.h. This is a hold >>> over from arch/ppc and we really should only put defn that we >>> actually need closer to the code that uses them (ie, drivers, etc.) >>> >> Most of the struct that were in mpc52xx.h are the ones used in more than >> one driver. >> (or don't really belong to a driver) >> That's why they've been left there and not in the driver header, so I >> would leave those >> there. >> >> (e.g. the IDE struct is not there, neither is the FEC. But sdma is used >> at several place >> for example, so is rtc, xlb and cdm, ...) > > I can see that some of these might be used, like SDMA, XLB, and CDM. > However, others like RTC should really be done via a single driver. > Additionally, I'd have to see code use GPIO, SDRAM, GPT, etc before I > think we should have them defined here. I'd rather we add these items > as they are used rather than having them here wholesale. I've just rechecked : * struct mpc52xx_mmap_ctl; * struct mpc52xx_sdram; Not really used any where that I can see/remember. Except for find_end_of_memory ... It should however be used in several place in the future ... (sleep support would need sdram iirc, ...). But can be removed for now if it's annoying to have them there ... * struct mpc52xx_intr; Was used before in platform support code to set the IRQ type of external IRQ (level/irq) ... but that can be done with set_irq_type. So can be safetly moved to a local mpc52xx_pic.h * struct mpc52xx_rtc; Was used before in some common code. When the bootloader didn't pass the bus frequency, we computed it and the rtc was used to do that. Now, with device tree, no need for that anymore. So can be safely removed. * struct mpc52xx_gpio; * struct mpc52xx_gpio_wkup; Port config (pin multiplexing) is in those registers so they should stay there. This is used by several driver and platform code. Beside custom driver could use gpio for different purpose ... It could be placed in a include/asm-powerpc/mpc52xx_gpio.h but that would just make one more file in include/asm-powerpc so it doesn't make much sens imho. It should just stay there. * struct mpc52xx_xlb; * struct mpc52xx_cdm; * struct mpc52xx_sdma; Used at several place and should really stay there. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH/RFC] powerpc: Add of_platform support for OHCI/Bigendian HC
>
>
> +
> +static struct of_device_id ohci_hcd_ppc_of_match_be[] = {
> + {
> + .name = "usb",
> + .compatible = "ohci-bigendian",
> + },
> + {
> + .name = "usb",
> + .compatible = "ohci-be",
> + },
> + {},
> +};
>
> +
> +static struct of_device_id ohci_hcd_ppc_of_match_le[] = {
> + {
> + .name = "usb",
> + .compatible = "ohci-littledian",
> + },
> + {
> + .name = "usb",
> + .compatible = "ohci-le",
> + },
> + {},
> +};
>
Isn't it possible to specify "options" in the device tree rather than
different names ?
(just a though ...)
It's just duplicating all that code doesn't look nice.
> +config USB_OHCI_HCD_PPC_OF
> + bool "OHCI support for PPC USB controller for OpenFirmware platform"
> + depends on USB_OHCI_HCD && PPC_OF
> + default y
> + select USB_OHCI_BIG_ENDIAN
> + select USB_OHCI_LITTLE_ENDIAN
> + ---help---
> + Enables support for the USB controller PowerPC OpenFirmware platform
> +
>
I know what benh said but do we really want to select both all the
times. That adds
quite an overhead to the accesses ...
> --- a/drivers/usb/host/ohci-hcd.c 2006-11-01 09:18:56.0 +0100
> +++ b/drivers/usb/host/ohci-hcd.c 2006-11-02 18:06:02.0 +0100
> @@ -930,6 +930,12 @@ MODULE_LICENSE ("GPL");
> #include "ohci-ppc-soc.c"
> #endif
>
> +#ifdef CONFIG_USB_OHCI_HCD_PPC_OF
> +#include "ohci-ppc-of.c"
> +#endif
> +
> +
> +
> #if defined(CONFIG_ARCH_AT91RM9200) || defined(CONFIG_ARCH_AT91SAM9261)
> #include "ohci-at91.c"
> #endif
>
Don't add space for nothing. All the #if #endif are space by one empty
line, keep it that way.
You also missed the last #if #end
#if !(defined(CONFIG_PCI) \
|| defined(CONFIG_SA) \
|| defined(CONFIG_ARCH_S3C2410) \
|| defined(CONFIG_ARCH_OMAP) \
|| defined (CONFIG_ARCH_LH7A404) \
|| defined (CONFIG_PXA27x) \
|| defined (CONFIG_ARCH_EP93XX) \
|| defined (CONFIG_SOC_AU1X00) \
|| defined (CONFIG_USB_OHCI_HCD_PPC_SOC) \
|| defined (CONFIG_ARCH_AT91RM9200) \
|| defined (CONFIG_ARCH_AT91SAM9261) \
|| defined (CONFIG_ARCH_PNX4008) \
)
#error "missing bus glue for ohci-hcd"
#endif
You need to add a || defined(...) clause there.
Sylvain
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] ppc/powerpc: Fix io.h for config with CONFIG_PCI not set
When CONFIG_PCI option is not set, the variables pci_dram_offset, isa_io_base and isa_mem_base are not defined. Currently, the test is handled in each platform header. This patch moves the test in io.h once and for all. Signed-off-by: Sylvain Munaut <[EMAIL PROTECTED]> --- include/asm-powerpc/mpc85xx.h |8 include/asm-ppc/io.h |8 +--- include/asm-ppc/mpc52xx.h | 11 --- include/asm-ppc/mpc83xx.h |8 include/asm-ppc/mpc85xx.h |8 5 files changed, 1 insertions(+), 42 deletions(-) diff --git a/include/asm-powerpc/mpc85xx.h b/include/asm-powerpc/mpc85xx.h index ccdb8a2..5414299 100644 --- a/include/asm-powerpc/mpc85xx.h +++ b/include/asm-powerpc/mpc85xx.h @@ -31,14 +31,6 @@ #ifdef CONFIG_MPC85xx_CDS #include #endif -#define _IO_BASEisa_io_base -#define _ISA_MEM_BASE isa_mem_base -#ifdef CONFIG_PCI -#define PCI_DRAM_OFFSET pci_dram_offset -#else -#define PCI_DRAM_OFFSET 0 -#endif - /* Let modules/drivers get at CCSRBAR */ extern phys_addr_t get_ccsrbar(void); diff --git a/include/asm-ppc/io.h b/include/asm-ppc/io.h index a4c411b..b744baf 100644 --- a/include/asm-ppc/io.h +++ b/include/asm-ppc/io.h @@ -26,17 +26,11 @@ #define PREP_PCI_DRAM_OFFSET0x8000 #if defined(CONFIG_4xx) #include -#elif defined(CONFIG_PPC_MPC52xx) -#include #elif defined(CONFIG_8xx) #include #elif defined(CONFIG_8260) #include -#elif defined(CONFIG_83xx) -#include -#elif defined(CONFIG_85xx) -#include -#elif defined(CONFIG_APUS) +#elif defined(CONFIG_APUS) || !defined(CONFIG_PCI) #define _IO_BASE 0 #define _ISA_MEM_BASE 0 #define PCI_DRAM_OFFSET 0 diff --git a/include/asm-ppc/mpc52xx.h b/include/asm-ppc/mpc52xx.h index 64c8874..d9d21aa 100644 --- a/include/asm-ppc/mpc52xx.h +++ b/include/asm-ppc/mpc52xx.h @@ -29,17 +29,6 @@ struct pt_regs; #endif /* __ASSEMBLY__ */ -#ifdef CONFIG_PCI -#define _IO_BASE isa_io_base -#define _ISA_MEM_BASE isa_mem_base -#define PCI_DRAM_OFFSETpci_dram_offset -#else -#define _IO_BASE 0 -#define _ISA_MEM_BASE 0 -#define PCI_DRAM_OFFSET0 -#endif - - /* */ /* PPC Sys devices definition */ /* */ diff --git a/include/asm-ppc/mpc83xx.h b/include/asm-ppc/mpc83xx.h index 02ed2c3..c306197 100644 --- a/include/asm-ppc/mpc83xx.h +++ b/include/asm-ppc/mpc83xx.h @@ -25,14 +25,6 @@ #ifdef CONFIG_MPC834x_SYS #include #endif -#define _IO_BASEisa_io_base -#define _ISA_MEM_BASE isa_mem_base -#ifdef CONFIG_PCI -#define PCI_DRAM_OFFSET pci_dram_offset -#else -#define PCI_DRAM_OFFSET 0 -#endif - /* * The "residual" board information structure the boot loader passes * into the kernel. diff --git a/include/asm-ppc/mpc85xx.h b/include/asm-ppc/mpc85xx.h index 9b48511..d7e4a79 100644 --- a/include/asm-ppc/mpc85xx.h +++ b/include/asm-ppc/mpc85xx.h @@ -44,14 +44,6 @@ #if defined(CONFIG_TQM8540) || defined(C #include #endif -#define _IO_BASEisa_io_base -#define _ISA_MEM_BASE isa_mem_base -#ifdef CONFIG_PCI -#define PCI_DRAM_OFFSET pci_dram_offset -#else -#define PCI_DRAM_OFFSET 0 -#endif - /* * The "residual" board information structure the boot loader passes * into the kernel. -- 1.4.2 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH/RFC] powerpc: Add MPC5200 Interrupt Controller support.
>> +picnode = find_mpc52xx_picnode();
>> +sdmanode = find_mpc52xx_sdmanode();
>>
>
> Any reason why you have those inline 1-line functions and just not put
> the actual of_find_* call in here ?
>
I think it might be worth creating a
arch/powerpc/sysdev/mpc52xx_common.c (we'll probably need it later on
anyway)
with a helper that would do
- The find_node
- get_address / translate / get_size
- ioremap
Something like :
intr = mpc52xx_find_and_map("mpc52xx-intr");
sdma = mpc52xx_find_and_map("mpc52xx-sdma");
would be more elegant. Especially since finding and mapping things like
intr/sdma/xlb/cdm ... will be done at several place. That would prevent
repeating all that code for nothing.
Also, in the Makefile, I would make the compilation conditionnal to
CONFIG_PPC_MPC52xx and not CONFIG_PPC_MPC52xx_PIC ...
If you're on a 52xx, you most likely want the interrupt controller ...
But the CONFIG_PPC_MPC52xx option should be in arch/powerpc/Kconfig
and not in the platform/embedded6xx/Kconfig
Sylvain
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] ppc/powerpc: Fix io.h for config with CONFIG_PCI not set
Benjamin Herrenschmidt wrote:
> On Sun, 2006-11-05 at 01:17 +0100, Sylvain Munaut wrote:
>
>> When CONFIG_PCI option is not set, the variables
>> pci_dram_offset, isa_io_base and isa_mem_base are not defined.
>>
>> Currently, the test is handled in each platform header. This
>> patch moves the test in io.h once and for all.
>>
>
> Be careful with _IO_BASE... I'm not 100% sure some platforms don't need
> it set to something else even when PCI is not present.
>
When I saw in mpc83xx.h and mpc85xx.h that they still defined them, I
wondered.
But when looking at the code :
unsigned long isa_io_base = 0;
unsigned long isa_mem_base= 0;
are both defined in pci_{32/64}.c and won't be included if CONFIG_PCI is
not set.
Sylvain
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Has anyone 2.6 kernel with Xenomai and MPC5200 Lite running?
Matthias Fechner wrote: > Hello Grant, > > * Grant Likely <[EMAIL PROTECTED]> [04-11-06 20:32]: > >> Yup, there exists patches for all the functionality that you're >> looking for. You can find them if you search the list, but I'll send >> you a link to a git tree with all those patches in it later tonight. >> > > you maybe mean: > http://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx.git > > I tried that repository but here I was not able to patch the tree with > Xenomai. > But if you have another link it would be a pleasure for me to receive > the link :) > Take the patchs off that link (bestcomm branch), and apply them on a fresh/recent tree, that should work. (that is, clone a official tree, then pull from the above link and merge the two). There is work in progress for the arch/powerpc port but it's not done yet. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH/RFC] powerpc: Add MPC5200 Interrupt Controller support.
>> As said, no option here. I think there is different way to see how works the >> PIC. However, from a register point of view. There is just critical, main, >> peripherals, SDMA. >> >> Loot at "ICTL Perstat, MainStat, MainStat, CritStat Encoded Register--MBAR + >> 0x0524" >> > > You should have your device-tree match your internal numbering. As you > noticed, the CRIT interrupt and the EXT interrupts are just the same. > And you properly folded them under the same level 1... now just make > the device-tree expose the same informations. > > I don't care if you have firmwares in production or whatever... As a > matter of fact, you guys have been working on this board for long enough > you could have dealt with that issue long ago :-) > > So right now, what you should do is figure out a proper encoding for the > firmware, and then either fix your device-tree, or do a hack in > prom_init.c that fixes it up. > I think Nicolas's choice makes sense. The HW provides 4 registers which each contain the "number" of the IRQ that happenned. And IRQ0 is encoded separatly from IRQ[1-3]. So when IRQ0 happens, you really have a flag saying that a critical interrupt happenned, and when you look at the encoded critical interrupt number, you get "00" which is IRQ0. If IRQ2 happend, the flag say a main interrupt happenned and when looking in the encoded main interrupt number, we get "01" which is IRQ2 ... So the Hardware maps the hw IRQ number like this, so it makes sense to use that mapping. Sure we could just not use that mapping and put IRQ0 hwirq number just before IRQ1 but then the hack is just moved in get_irq and we have a numbering scheme which is not really what's in hw. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH/RFC] powerpc: Add MPC5200 Interrupt Controller support.
Grant Likely wrote:
> On 11/4/06, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>> On Sun, 2006-11-05 at 01:27 +0100, Sylvain Munaut wrote:
>> > with a helper that would do
>> > - The find_node
>> > - get_address / translate / get_size
>> > - ioremap
>> >
>> > Something like :
>> >
>> > intr = mpc52xx_find_and_map("mpc52xx-intr");
>> > sdma = mpc52xx_find_and_map("mpc52xx-sdma");
>>
>> Hrm... I don't care that much but I also don't think we need that
>> helper. It's not saving much.
>
> While on this topic... if a helper is added, what about it is 52xx
> specific? Wouldn't the same code apply to all platforms?
>
> g.
>
The code would look like what I included at the end (untested). Not that
I used
of_find_by_name and not find_compatible. We can fix a naming convention
for those units ...
I think it does save quite a few lines and variable. It also simplifies the
error path ... granted it's not an exceptionnal reduction but still
worth it.
If it's not included now it's not that bad, I'll probably submitt a
patch later
when it's used in more places than mpc52xx_pic.c ...
About the use on other platform, maybe but do other platform need that a
lot ?
Here we have several unit that need to be mapped at different places ...
Sylvain
---
void __iomem *mpc52xx_find_and_map(const char *name)
{
struct device_node *ofn;
const u32 *regaddr_p;
u64 regaddr64, size64;
ofn = of_find_by_name(NULL, name);
if (!ofn)
return NULL;
regaddr_p = of_get_address(ofn, 0, &size64, NULL);
if (!regaddr_p) {
of_node_put(ofn);
return NULL;
}
regaddr64 = of_translate_address(ofn, regaddr_p);
of_node_put(ofn);
return ioremap((u32)regaddr64, (u32)size64);
}
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add MPC52xx PIO/ATA support for arch/powerpc
Roman Fietze wrote: > Hallo, > > On Sunday 05 November 2006 12:57, Nicolas DET wrote: > > >> This patch adds ATA/PIO support for Freescale MPC5200 plaforms. >> > > Assumed I've got a preliminary version of an MPC5200 ATA driver with > BestComm ATA support (besides a FEC driver with DMA support as well) > mainly based on code from Sylvain Munaut, Dale Farnsworth and John > Rigby. > > Would you recommend posting those patches here? They are working on > our platform, any comment would be appreciated. > You can post it won't hurt. But bestcomm will change for it's arch/powerpc transition so they will need adaptation ... Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] powerpc: Add of_platform support for OHCI/Bigendian HC
Kumar Gala wrote: > On Nov 6, 2006, at 4:35 AM, Nicolas DET wrote: > > >> This patch use of_platform device to probe and install OHCI big >> endian HC. >> >> PS: I did not success to properly inline the file using thrunderbird. >> > > You really copy the USB maintainers on this. Also, why bother with > the Kconfig for USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE? > I think it's a good idea to use those : - Just including both when PPC_OF is used is overkill because it makes all USB perform useless tests if you never intend to use the LE version for example. - Using the already defined symbol USB_OHCI_BIG_ENDIAN would force other ohci user to select BE/LE and they may not want to expose this. However in this bus glue test : + || defined (CONFIG_USB_OHCI_HCD_PPC_OF_LE) \ + || defined (CONFIG_USB_OHCI_HCD_PPC_OF_BE) \ I would just test for CONFIG_USB_OHCI_HCD_PPC_OF to keep things the same betwenn all the bus glues. (Sure it would be stupid to select PPC_OF and neither LE nor BE ...) But that's just me and if the usb maintainer is ok with it, it's his call. So otherwise, looks good to me. Haven't tested in hw yet ... I'll report asap. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH/RFC] powerpc: Add MPC5200 Interrupt Controller support.
> +
> + /*
> + * Most of ours IRQs will be level low
> + * Only external IRQs on some platform may be others
> + */
> + type = IRQ_TYPE_LEVEL_LOW;
>
I've been wondering : Why LEVEL_LOW ?
Aren't they LEVEL_HIGH ?
(not that it changes much here ...)
> +
> +end:
> + of_node_put(picnode);
> + of_node_put(sdmanode);
>
Is of_node_put specified as resilient to NULL argument ? (in the error
path, that could happen)
Also, I think "PANIC" would be appropriate in the error path. If we
can't init
the PIC properly we may as well give up ... It's not like we're going to
do much
without it ...
> +/* HW IRQ mapping */
> +#define MPC52xx_IRQ_L1_CRIT (0)
> +#define MPC52xx_IRQ_L1_MAIN (1)
> +#define MPC52xx_IRQ_L1_PERP (2)
> +#define MPC52xx_IRQ_L1_SDMA (3)
> +
> +#define MPC52xx_IRQ_L1_OFFSET (6)
> +#define MPC52xx_IRQ_L1_MASK (0xc0)
> +
> +#define MPC52xx_IRQ_L2_OFFSET (0)
> +#define MPC52xx_IRQ_L2_MASK (0x3f)
> +
> +#define MPC52xx_IRQ_HIGHTESTHWIRQ (0xd0)
> +
> +/* Interrupt controller Register set */
> +struct mpc52xx_intr {
> + u32 per_mask; /* INTR + 0x00 */
> + u32 per_pri1; /* INTR + 0x04 */
> + u32 per_pri2; /* INTR + 0x08 */
> + u32 per_pri3; /* INTR + 0x0c */
> + u32 ctrl; /* INTR + 0x10 */
> + u32 main_mask; /* INTR + 0x14 */
> + u32 main_pri1; /* INTR + 0x18 */
> + u32 main_pri2; /* INTR + 0x1c */
> + u32 reserved1; /* INTR + 0x20 */
> + u32 enc_status; /* INTR + 0x24 */
> + u32 crit_status;/* INTR + 0x28 */
> + u32 main_status;/* INTR + 0x2c */
> + u32 per_status; /* INTR + 0x30 */
> + u32 reserved2; /* INTR + 0x34 */
> + u32 per_error; /* INTR + 0x38 */
> +};
>
When I said on IRC you could remerge them, I meant a little more
smartly than just 'join' them. i.e., put the mpc52xx_intr with all the
other register set at the very least ...
Sylvain
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH/RFC] powerpc: Add MPC5200 Interrupt Controller support.
Nicolas DET wrote: > This patch add MPC52xx Interrupt controller for ARCH=powerpc. > > It includes the main code in arch/powerpc/sysdev/ ad well as an header file in > include/asm-powerpc. > > The header file has now distinct section for the struct and the IRQ > mapping/enconding define > > Signed-off-by: Nicolas DET <[EMAIL PROTECTED]> Acked-by: Sylvain Munaut <[EMAIL PROTECTED]> ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] powerpc: Add of_platform support for OHCI/Bigendian HC
This patch use of_platform device to probe and install OHCI big endian HC. PS: I did not success to properly inline the file using thrunderbird. >>> >>> You really copy the USB maintainers on this. Also, why bother with >>> the Kconfig for USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE? >>> >> I think it's a good idea to use those : >> - Just including both when PPC_OF is used is overkill because it makes >> all USB >> perform useless tests if you never intend to use the LE version for >> example. >> - Using the already defined symbol USB_OHCI_BIG_ENDIAN would force >> other ohci user to select BE/LE and they may not want to expose this. > > Maybe I'm missing something, but it looks like the _OF_LE & _OF_BE are > just configuring what matches may occur. This seems like a one time > event. + +config USB_OHCI_HCD_PPC_OF_BE + bool "Support big endian HC" + depends on USB_OHCI_HCD_PPC_OF + default y + select USB_OHCI_BIG_ENDIAN + +config USB_OHCI_HCD_PPC_OF_LE + bool "Support little endian HC" + depends on USB_OHCI_HCD_PPC_OF + default n + select USB_OHCI_LITTLE_ENDIAN What's important is the USB_OHCI_BIG_ENDIAN and USB_OHCI_LITTLE_ENDIAN symbols that are selected when you choose these options. When both are active, each usb mmio access will test either to access in BE mode or LE mode. If only one is active, the test is hardcoded. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH/RFC] powerpc: Add MPC5200 Interrupt Controller support.
Grant Likely wrote: > On 11/7/06, Sylvain Munaut <[EMAIL PROTECTED]> wrote: >> Nicolas DET wrote: >> >> > This patch add MPC52xx Interrupt controller for ARCH=powerpc. >> > >> > It includes the main code in arch/powerpc/sysdev/ ad well as an >> header file in >> > include/asm-powerpc. >> > >> > The header file has now distinct section for the struct and the IRQ >> mapping/enconding define >> > >> > Signed-off-by: Nicolas DET <[EMAIL PROTECTED]> >> Acked-by: Sylvain Munaut <[EMAIL PROTECTED]> > Acked-by: Grant Likely <[EMAIL PROTECTED]> > OOps ... sorry NAK ... All your strings got screwed up ... all your \n got replaced by just n ... And while your at it there is two extraneous whitespace, might be a good time to get rid of them. One in the comment header and one after a "size64". Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH/RFC] ata: Add support for the MPC52xx ATA controller using libata
This is the first attempt at a libata driver for this controller.
The two main issues :
* The manual states we should check for the TIP bit before all
PIO transaction. That's not really supported by libata and requires
reimplementing almost all the hooks. But after talking to Freescale,
it turnsout it's not really necessary. So this driver doesn't implement
that check. I noticed no problem so far ...
* This driver doesn't use the standard function to compute timing
because the 5200 needs more timing parameters that are not handled
by the generic call (ta and t4).
Signed-off-by: Sylvain Munaut <[EMAIL PROTECTED]>
---
Hi everyone,
This is a request for comments, I'd like to get that driver clean enough
for the 2.6.20 merge window ;)
It has been tested on my system (but not stressed to the limits ...). I'd
appreciate if someone could test it as well on other platforms.
Sylvain
---
drivers/ata/Kconfig|9 +
drivers/ata/Makefile |1
drivers/ata/pata_mpc52xx.c | 510
drivers/ata/pata_mpc52xx.h | 107 +
4 files changed, 627 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 03f6338..be01ddf 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -328,6 +328,15 @@ config PATA_TRIFLEX
If unsure, say N.
+config PATA_MPC52xx
+ tristate "Freescale MPC52xx SoC internal IDE"
+ depends on PPC_MPC52xx
+ help
+ This option enables support for integrated IDE controller
+ of the Freescale MPC52xx SoC.
+
+ If unsure, say N.
+
config PATA_MPIIX
tristate "Intel PATA MPIIX support"
depends on PCI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 72243a6..e3a741c 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_PATA_NETCELL)+= pata_netce
obj-$(CONFIG_PATA_NS87410) += pata_ns87410.o
obj-$(CONFIG_PATA_OPTI)+= pata_opti.o
obj-$(CONFIG_PATA_OPTIDMA) += pata_optidma.o
+obj-$(CONFIG_PATA_MPC52xx) += pata_mpc52xx.o
obj-$(CONFIG_PATA_MPIIX) += pata_mpiix.o
obj-$(CONFIG_PATA_OLDPIIX) += pata_oldpiix.o
obj-$(CONFIG_PATA_PCMCIA) += pata_pcmcia.o
diff --git a/drivers/ata/pata_mpc52xx.c b/drivers/ata/pata_mpc52xx.c
new file mode 100644
index 000..c75d4c9
--- /dev/null
+++ b/drivers/ata/pata_mpc52xx.c
@@ -0,0 +1,510 @@
+/*
+ * drivers/ata/pata_mpc52xx.c
+ *
+ * libata driver for the Freescale MPC52xx on-chip IDE interface
+ *
+ * Copyright (C) 2006 Sylvain Munaut <[EMAIL PROTECTED]>
+ * Copyright (C) 2003 Mipsys - Benjamin Herrenschmidt
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "pata_mpc52xx.h"
+
+
+#define DRV_NAME "mpc52xx_ata"
+#define DRV_VERSION"0.1.0"
+
+
+/* Private structures used by the driver */
+struct mpc52xx_ata_timings {
+ u32 pio1;
+ u32 pio2;
+};
+
+struct mpc52xx_ata_priv {
+ unsigned intipb_period;
+ struct mpc52xx_ata __iomem *ata_regs;
+ int ata_irq;
+ struct mpc52xx_ata_timings timings[2];
+ int csel;
+};
+
+
+/* ATAPI-4 PIO specs (in ns) */
+static const int ataspec_t0[5]= {600, 383, 240, 180, 120};
+static const int ataspec_t1[5]= { 70, 50, 30, 30, 25};
+static const int ataspec_t2_8[5] = {290, 290, 290, 80, 70};
+static const int ataspec_t2_16[5] = {165, 125, 100, 80, 70};
+static const int ataspec_t2i[5] = { 0, 0, 0, 70, 25};
+static const int ataspec_t4[5]= { 30, 20, 15, 10, 10};
+static const int ataspec_ta[5]= { 35, 35, 35, 35, 35};
+
+#define CALC_CLKCYC(c,v) v)+(c)-1)/(c)))
+
+
+/* */
+/* Aux fns */
+/* */
+
+
+/* OF device tree */
+
+static unsigned int
+mpc52xx_find_ipb_freq(struct device_node *on)
+{
+ struct device_node *onp;
+ const unsigned int *p_ipb_freq = NULL;
+
+ of_node_get(on);
+ while (on) {
+ p_ipb_freq = get_property(on, "bus-frequency", NULL);
+
+ if (p_ipb_freq)
+ break;
+
+ onp = of_get_parent(on);
+ of_node_put(on);
+ on = onp;
+ }
+
+ if (on)
+ of_node_put(on);
+
+ return p_ipb_freq ? *p_ipb_freq : 0;
+}
+
+
+/* MPC52xx low level hw control */
+
+static int
+mpc52xx_ata_com
Re: [PATCH/RFC] ata: Add support for the MPC52xx ATA controller using libata
Jarno Manninen wrote: > On Friday 17 November 2006 00:12, Sylvain Munaut wrote: > > >> * The manual states we should check for the TIP bit before all >> PIO transaction. That's not really supported by libata and requires >> reimplementing almost all the hooks. But after talking to Freescale, >> it turnsout it's not really necessary. So this driver doesn't implement >> that check. I noticed no problem so far ... >> > > I've had some bad experiences with 2.4 line kernel when using BAPI 2.2 on > Rev. > A 5200 while imposing heavy I/O load. Problems manifested as hanging XLB-bus > and so on. Funny thing is that combinations like Rev.A + BAPI 2.1 and Rev.B + > BAPI 2.[12] seem to be immune while doing similar stress tests. > > Problems went away after wrapping PIO access like this: > > 1. Stop XLB-pipelining > 2. Wait for TIP bit to go down. > 3. Do the access > 4. Restore XLB-pipelining. > > Just polling for the TIP bit is not enough due to errata on Rev. A if the > pipelining is enabled. > > Just in case if someone else is having mysterious hangs on Rev.A:s with newer > microcode. :) > Thanks for the info ! I'll certainly try to remember that. The currentl kernel doesn't handle DMA so far so there is no problem and we deactivate XLB pipelining. Since the current libata doesn't really support overriding IO accessors, I'd keep it like that for now. Apparently some other architecture needs special IO stuff so we could see a way to hook io accessor soon, and then we can change it if we notice big problems. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH/RFC] ata: Add support for the MPC52xx ATA controller using libata
Alan wrote: > On Thu, 16 Nov 2006 23:12:19 +0100 > Sylvain Munaut <[EMAIL PROTECTED]> wrote: > > >> * The manual states we should check for the TIP bit before all >> PIO transaction. That's not really supported by libata and requires >> reimplementing almost all the hooks. But after talking to Freescale, >> it turnsout it's not really necessary. So this driver doesn't implement >> that check. I noticed no problem so far ... >> >> > > All PIO transactions meaning each PIO command sequence or each register > read/write ? In the former case is it not enough just to wrap the command > write ? > Each register write apparently. >> * This driver doesn't use the standard function to compute timing >> because the 5200 needs more timing parameters that are not handled >> by the generic call (ta and t4). >> > > I'd rather the generic code was taught to compute any extra times you > need but it seems clean enough. > Well, I can do that as well. It should be simple enough and not interfere with the existing drivers. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH/RFC] ata: Add support for the MPC52xx ATA controller using libata
Jeff Garzik wrote: > Sylvain Munaut wrote: >> Since the current libata doesn't really support overriding IO accessors, >> I'd keep it like >> that for now. Apparently some other architecture needs special IO stuff >> so we could see >> a way to hook io accessor soon, and then we can change it if we notice >> big problems. > > Sure it does... there are no individual outb etc. hooks, but you can > override every available bitbang function. This is intentional, so > that arches have more power to control when and how a set of registers > is blasted to the hardware. That why I said "really" but in english that doesn't quite mean what I meant. I have a version that does it and it's not pretty, it needs to reimplement every hook where I basically just cut & pasted the standard libata ones and changed the outb to mpc52xx_ata_outb ... I agree that this gives more flexibility when you need more than just change IO accessors. But this also means than when you just need to replace IO access, you need to do more work ... IMHO it would have made sense to add hooks for just inb and outb (not for all the possible io stuff like in driver/ide), but heh, I'm kind of biased ;) So it's possible but as in the current state of thing since it doesn't matter if we do it or not, I'd rather not. If it becomes necessary (when doing DMA or ...), then we can always add it. But for the moment, I would keep it as clean as possible. Aside from that, does the driver looks ok ? It has been tested ok on another 5200b platform as well. I'd like to include it in a patch set I'll probably send next weekend. I'll try to add the timing computation to the generic call and make use of those. Thanks, Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Lite5200B I2S driver
Pedro Luis D. L. wrote: > Hi all, > > I´m working with a Lite5200B EVB, trying to atach an audio output to a PCM > 1680 from Texas Instruments. > At this moment I am using the patched 2.6.16.11-rt18 kernel that comes with > Freescale BSP. > I´ve tried to develop an I2S driver for the platform with no results. I´m > afraid that my driver devolping skills are still too low. > > Anybody knows a working I2S driver for this board that can throw any > audiooutput through PSCs? > > Any help or indication would be apreciated I've never seen one. I'm currently working on a AC97 driver, maybe once it's done you can use it as a base. It's pretty early so don't excepect anything before a while ;) I'm pretty sure some part could be shared between the two ... Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Which kernel for Lite5200 based target board?
> I know Sylvain Munaut is/was also maintaining a kernel tree with working > support for IDE and Bestcomm. This tree seems not very active to me but > my git wisdom is very very poor and I may be wrong :-( > The recent work in my git tree didn't take place in the 'master' branch so you don't see it at first ;) > Please, consider this as a preliminary post. I'm looking for general > suggestion on the more convenient kernel to stay with. I know I will > still need some patching to make everything work fine, but I can't spend > too much time on "unpromising" solutions. If useful I can then post > details about the specific problems I have with IDE and ethernet in > particular. > My 2cents : - Update to a real recent u-boot, with device tree support for the 5200. - Write a device tree for you board based on the lite5200.dts and lite5200b.dts in the kernel source. - This day, use gcl tree. What tree to use between gcl and mine to have the latest can vary from day to day depending on what we do ... but we shouldn't lag too much behind. And use the arch=powerpc support. That's where we're both (Grant and I) working so ... The 2.6.20 should have support for quite a bit out of the box. The most notable exception being no bestcomm (so no ethernet and ATA is PIO only). This will come later (hopefully 2.6.21 ;) But by using our development tree (Grant and mine), you will have more functionnality, at the price that once in a while ... it may not compile/boot ;) > Can you tell me where to find details about the status of the Lite520 > support in the kernels listed above? Or maybe suggest me another kernel > to go with? > It should be there www.246tNt.com/mpc52xx/ ... but I haven't written it yet ;) Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [RFC] lite5200b low power mode
Domen Puncer wrote: > Hi! > > I have managed to implement low power mode... well, to some > degree, at least. > > Short description: > patch u-boot, it's the return from wakeup code. pretty clean. > address is saved at 0x0 (0xc000_) > patch linux with PM-platform_bus-and-late_suspend-early_resume.patch > didn't investigate too much, but it seems to broke mine. > patch linux with lite5200b_low_power.patch > ugly, with debugging, hacks and whatever > > Boot Linux and 'echo mem > /sys/power/state'. > It won't work on PCI, possibly other devices, PSC0 and FEC seem > to work ok for me. > > It seems to work reliably (checksums match, so ram was in self-refresh) > when called from boot scripts, but not so when from console prompt. > > > If someone's interested (or maybe wants to play with this during > holiday? ;-) ), more info follow: > > Well, I'll have a look, that looks interesting ;) Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Ethernet fails on MPC5200 based target
Hi andrea, Could you tell me exactly what kernel you use from me ? (a commit id would do) And did you write your own platform file ? Maybe some things (like xlb pipelining, cache snooping, ...) is not properly setup in you platform support code ? Or maybe since the ethernet code currently only "knows" about the intel phy, something is wrong in the "generic" phy code included in the driver itself. Sylvain Andrea Galbusera wrote: > Hi all, > > I have a problem with ethernet on my MPC5200 based board. > > Ethernet is failing on my target with both 2.6.16.11-rt18 from Freescale > BSP (based on the ltib tool) and 2.6.16-rc1-g7cdaf877 from Sylvain > Munaut's git tree. On the opposite, it works fine with a relatively old > (April 2006) 2.6.16 from Denx. > > What I see is that network is not working (corruption occur). I use a > ramdisk rootfs to boot and I get an up-and-running system. Then, if I > ping it from a remote host I get the following errors: > > >> ping 192.168.0.183 >> PING 192.168.0.183 (192.168.0.183) 56(84) bytes of data. >> 64 bytes from 192.168.0.183: icmp_seq=1 ttl=64 time=8.00 ms >> 64 bytes from 192.168.0.183: icmp_seq=2 ttl=64 time=0.188 ms >> wrong data byte #20 should be 0x14 but was 0xc0 >> #8 8 9 a b c d e f 10 11 12 13 c0 15 16 17 18 19 1a 1b 1c 1d 1e >> 1f 20 21 22 23 24 25 26 27 >> #40 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 >> 64 bytes from 192.168.0.183: icmp_seq=3 ttl=64 time=0.217 ms >> 64 bytes from 192.168.0.183: icmp_seq=5 ttl=64 time=0.216 ms >> wrong data byte #20 should be 0x14 but was 0x0 >> #8 8 9 a b c d e f 10 11 12 13 0 15 16 17 18 19 1a 1b 1c 1d 1e 1f >> 20 21 22 23 24 25 26 27 >> #40 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 >> 64 bytes from 192.168.0.183: icmp_seq=6 ttl=64 time=0.187 ms >> > > Since my target is heavily based on the Lite5200 I tryed all three > kernels on the Lite5200 too and they all show working ethernet. > > This may suggest something related with the different phy hardware, but > consider that the kernel from Denx works fine on it! > My target hardware uses MPC5200B CPU and AMD NetPhy AM79C874 for the > network phy. > > Can you suggest what source file may be responsible for this behaviour > in order to dig the trees and maybe, hopefully, fix the problem? I tryed > a first diffing between the Denx and the Freescale trees (this last one > being mostly based on Sylvain's patches) but I can't figure out any > reasonable answer. > > Consider I can't unfortunately switch to 2.6.16 from Denx because it > does not support ATA/IDE that I need; also switching to the new powerpc > architecture is not an option at moment, since it would require changes > to the system at whole. > > TIA and let me know if you need more details > > > ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Ethernet fails on MPC5200 based target
Andrea Galbusera wrote: >> Maybe some things (like xlb pipelining, cache snooping, ...) is not properly >> setup in you platform support code ? >> > > Following your suggestion, I started from here... Comparing the > unaffected kernel (from DENX) with yours I tryed commenting out the > following in mpc52xx_setup_cpu() : > > /* Disable XLB pipelining */ > /* (cfr errate 292. We could do this only just before ATA PIO > transaction and re-enable it after ...) */ > out_be32(&xlb->config, in_be32(&xlb->config) | MPC52xx_XLB_CFG_PLDIS); > > In fact this gives much better results, but does not completely solve > the problem. Network packets corruption seems to be gone, but, after > massive pinging (about 1k ping packets) it comes back with about the > same frequency as before the change. > And does the problem also appears on the denx kernel after 1k ping packets ? Are the fec driver the same ? Are the fec task code the same ? (in bestcomm/fec.c ) > I can't figure out what is the impact of keeping XLB pipelining enabled > on the eth behavior. I'm sharing this results in the hope someone have > any other valuable suggestion > Well me neither, it should only affect performance, not create corruption ... AFAI understand it anyway. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: mem=XXXM ioremap DMA
Eric Nuckols wrote: > in my driver, I'm calling > my_virt_address = ioremap( 0x1F80, 0x80 ); > my_bus_address = virt_to_bus( my_virt_address ); > You can't use virt_to_bus on address returned by ioremap AFAIK. I think you could do my_bus_address = virt_to_bus(phys_to_virt(0x1f80)); Altough it slightly misuse the functions ... but that should work. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: mem=XXXM ioremap DMA
Eric Nuckols wrote: > >> Eric Nuckols wrote: >> >>> in my driver, I'm calling >>> my_virt_address = ioremap( 0x1F80, 0x80 ); >>> my_bus_address = virt_to_bus( my_virt_address ); >>> >>> >> You can't use virt_to_bus on address returned by ioremap AFAIK. >> >> I think you could do >> my_bus_address = virt_to_bus(phys_to_virt(0x1f80)); >> >> Altough it slightly misuse the functions ... but that should work. >> >> >> Sylvain >> >> > > If I use this approach in a driver, won't I still need to use the ioremap > function to make sure the kernel does not reassign the virtual addresses to > some other physical memory locations? mmh, I wasn't clear : You must do : my_virt_address = ioremap( 0x1F80, 0x80 ); my_bus_address = virt_to_bus(phys_to_virt(0x1f80)); The virtual address returned by phys_to_virt won't be really valid ... but it will be good enough for virt_to_bus. In the end, it will just do PCI_DRAM_OFFSET + 0x1f80; Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [RFC PATCHES] lite5200b low power mode works
Domen Puncer wrote: > On 23/01/07 10:33 +0100, Domen Puncer wrote: > >> I'm planning on porting this to Grant/Sylvain's arch/powerpc mpc52xx >> tree soon. >> > > OK... and I've done that (mainline kernel + FEC/bestcomm patches) > + some cleanups, fixes. > > Any of you guys interested in having this in your tree? > > Sure, feel free to post them. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [RFC PATCHES] lite5200b low power mode works
Domen Puncer wrote: > On 19/02/07 11:15 +0100, Sylvain Munaut wrote: > >> Domen Puncer wrote: >> >>> On 23/01/07 10:33 +0100, Domen Puncer wrote: >>> >>> >>>> I'm planning on porting this to Grant/Sylvain's arch/powerpc mpc52xx >>>> tree soon. >>>> >>>> >>> OK... and I've done that (mainline kernel + FEC/bestcomm patches) >>> + some cleanups, fixes. >>> >>> Any of you guys interested in having this in your tree? >>> >>> >>> >> Sure, feel free to post them. >> > > It seems to be my lucky day. I just figured out what I was doing > wrong with deep-sleep (aplicable to all mpc52xx), so I'll delay this > a few days, and send patches implementing both mpc5200b and lite5200b > "suspend to ram" modes. > Even better ! Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 0/7] MPC5200 and Lite5200b low power modes
Hi, Thanks for providing theses. I hadn't a chance to test them yet, I'll try that this week end. A couple of comments already though : - Is saving the SDMA / PIC registers necessary ? Doesn't the cpu keep those when at sleep ? - And if it is, won't a memcpy_io of the whole zone do the trick ? - On a more general note, there seem to be a lot of stuff decided by #ifdef ... that's not really good as we can build a single kernel that could run on several platform so those need to somehow be enable disabled dynamically. - I may miss something but turning port power off for USB seem like a sane thing to do for every one. Isn't that implemented somehow for all controller somewhere ? Sylvain Domen Puncer wrote: > Hi! > > Patches are based on latest mainline git tree + fec patches: > Fec_MPC5200_eth_driver.patch > Copy_bestcomm_support_files_into_arch_powerpc.patch > Make_FEC_work_on_the_lite5200.patch > > > This patchset includes the following patches: > - [PATCH 1/7] mpc52xx suspend: bestcomm > - [PATCH 2/7] mpc52xx suspend: UART > - [PATCH 3/7] mpc52xx suspend: FEC (ethernet) > - [PATCH 4/7] mpc52xx suspend: USB > - [PATCH 5/7] mpc52xx suspend: deep-sleep > - [PATCH 6/7] lite5200b suspend: PIC > - [u-boot patch] support lite5200b wakeup in u-boot > - [PATCH 7/7] lite5200b suspend: low-power mode > > > I would appreaciate any comments, suggestions etc. > > > Domen > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH alternative] lite5200(b) support for i2c
Domen Puncer wrote: > Add fsl-i2c to lite5200 i2c nodes in device tree, and enable FSL_SOC. > > Tested to work with built-in eeprom on lite5200b. > > > Signed-off-by: Domen Puncer <[EMAIL PROTECTED]> > > --- > This patch obsoletes the previous one, and is shorter too :-) > > > arch/powerpc/Kconfig|1 + > arch/powerpc/boot/dts/lite5200.dts |6 -- > arch/powerpc/boot/dts/lite5200b.dts |6 -- > 3 files changed, 9 insertions(+), 4 deletions(-) > > Index: grant.git/arch/powerpc/Kconfig > === > --- grant.git.orig/arch/powerpc/Kconfig > +++ grant.git/arch/powerpc/Kconfig > @@ -128,6 +128,7 @@ config CLASSIC32 > bool "52xx/6xx/7xx/74xx" > select PPC_FPU > select 6xx > + select FSL_SOC > help > There are four families of PowerPC chips supported. The more common > types (601, 603, 604, 740, 750, 7400), the Motorola embedded > > I would put the select FSL_SOC under the PPC_MPC52xx symbol and not the CLASSIC32 one. Otherwise, looks good. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH try3] lite5200(b) support for i2c
Domen Puncer wrote:
> Add fsl-i2c to mpc5200 i2c node in device tree, and enable FSL_SOC.
>
> Tested to work with built-in eeprom on lite5200b.
>
>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
>
Acked-by: Sylvain Munaut <[EMAIL PROTECTED]>
I'll make sure this is included in my next merge batch to Paul.
Sylvain
> ---
> D'oh, of course it makes more sense under PPC_MPC52xx.
>
> arch/powerpc/Kconfig|1 +
> arch/powerpc/boot/dts/lite5200.dts |6 --
> arch/powerpc/boot/dts/lite5200b.dts |6 --
> 3 files changed, 9 insertions(+), 4 deletions(-)
>
> Index: grant.git/arch/powerpc/Kconfig
> ===
> --- grant.git.orig/arch/powerpc/Kconfig
> +++ grant.git/arch/powerpc/Kconfig
> @@ -434,6 +434,7 @@ config PPC_CHRP
>
> config PPC_MPC52xx
> bool
> + select FSL_SOC
> default n
>
> config PPC_MPC5200
> Index: grant.git/arch/powerpc/boot/dts/lite5200b.dts
> ===
> --- grant.git.orig/arch/powerpc/boot/dts/lite5200b.dts
> +++ grant.git/arch/powerpc/boot/dts/lite5200b.dts
> @@ -323,20 +323,22 @@
>
> [EMAIL PROTECTED] {
> device_type = "i2c";
> - compatible = "mpc5200b-i2c\0mpc5200-i2c";
> + compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
> cell-index = <0>;
> reg = <3d00 40>;
> interrupts = <2 f 0>;
> interrupt-parent = <500>;
> + fsl5200-clocking;
> };
>
> [EMAIL PROTECTED] {
> device_type = "i2c";
> - compatible = "mpc5200b-i2c\0mpc5200-i2c";
> + compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
> cell-index = <1>;
> reg = <3d40 40>;
> interrupts = <2 10 0>;
> interrupt-parent = <500>;
> + fsl5200-clocking;
> };
> [EMAIL PROTECTED] {
> device_type = "sram";
> Index: grant.git/arch/powerpc/boot/dts/lite5200.dts
> ===
> --- grant.git.orig/arch/powerpc/boot/dts/lite5200.dts
> +++ grant.git/arch/powerpc/boot/dts/lite5200.dts
> @@ -318,20 +318,22 @@
>
> [EMAIL PROTECTED] {
> device_type = "i2c";
> - compatible = "mpc5200-i2c";
> + compatible = "mpc5200-i2c\0fsl-i2c";
> cell-index = <0>;
> reg = <3d00 40>;
> interrupts = <2 f 0>;
> interrupt-parent = <500>;
> + fsl5200-clocking;
> };
>
> [EMAIL PROTECTED] {
> device_type = "i2c";
> - compatible = "mpc5200-i2c";
> + compatible = "mpc5200-i2c\0fsl-i2c";
> cell-index = <1>;
> reg = <3d40 40>;
> interrupts = <2 10 0>;
> interrupt-parent = <500>;
> + fsl5200-clocking;
> };
> [EMAIL PROTECTED] {
> device_type = "sram";
>
>
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 0/7] MPC5200 and Lite5200b low power modes
Domen Puncer wrote:
> On 03/03/07 08:33 +0100, Domen Puncer wrote:
>
>> On 02/03/07 22:35 +0100, Sylvain Munaut wrote:
>>
>>> Hi,
>>>
>>> Thanks for providing theses.
>>> I hadn't a chance to test them yet, I'll try that this week end. A
>>> couple of comments already though :
>>>
>>> - Is saving the SDMA / PIC registers necessary ? Doesn't the cpu keep
>>> those when at sleep ?
>>>
>> For deep-sleep this is true, but not for low-power mode (the CPU
>> isn't even powered in that case).
>>
>>
>>> - And if it is, won't a memcpy_io of the whole zone do the trick ?
>>>
>> Oh, nice. I wasn't aware of _memcpy_{to,from}io. I'll try it.
>>
>
> OK, one can't copy the whole zone :-(
> Ie. reading from MBAR+0x3B00 seems to freeze Linux.
>
> Currently I'm having something like (obsoletes PIC and SDMA patches):
>
And does that work ?
I was also wondering if some registers don't need to be restored last.
For example,
the task status in sdma would be restored to 0 then just at the end set
to their "real value".
Saving / Restoring all theses system zones makes more sense to me than
to just save / restore the pic & sdma and hoping than mpc52xx_setup_cpu
will make the rest ...
But saving/restoring all the mbar isn't good either because peripheral
drivers should handle their own setup restore. The suspend / resume
method of the peripheral should differentiate how deep their suspending
/ resuming and do what's necessary accordingly.
Sylvain
>
> Index: grant.git/arch/powerpc/platforms/52xx/lite5200_pm.c
> ===
> --- /dev/null
> +++ grant.git/arch/powerpc/platforms/52xx/lite5200_pm.c
> @@ -0,0 +1,125 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "mpc52xx_pic.h"
> +#include "bestcomm.h"
> +
> +extern void lite5200_low_power(void *sram, void *mbar);
> +extern int mpc52xx_pm_enter(suspend_state_t);
> +extern int mpc52xx_pm_prepare(suspend_state_t);
> +
> +static void __iomem *mbar;
> +
> +static int lite5200_pm_valid(suspend_state_t state)
> +{
> + switch (state) {
> + case PM_SUSPEND_STANDBY:
> + case PM_SUSPEND_MEM:
> + return 1;
> + default:
> + return 0;
> + }
> +}
> +
> +static int lite5200_pm_prepare(suspend_state_t state)
> +{
> + /* deep sleep? let mpc52xx code handle that */
> + if (state == PM_SUSPEND_STANDBY)
> + return mpc52xx_pm_prepare(state);
> +
> + if (state != PM_SUSPEND_MEM)
> + return -EINVAL;
> +
> + /* map registers */
> + mbar = ioremap_nocache(0xf000, 0x8000);
> + if (!mbar) {
> + printk(KERN_ERR "%s:%i Error mapping registers\n", __func__,
> __LINE__);
> + return -ENOSYS;
> + }
> +
> + return 0;
> +}
> +
> +/* save and restore registers not bound to any real devices */
> +static struct mpc52xx_cdm __iomem *cdm;
> +static struct mpc52xx_cdm scdm;
> +static struct mpc52xx_intr __iomem *pic;
> +static struct mpc52xx_intr spic;
> +static struct mpc52xx_sdma __iomem *bes;
> +static struct mpc52xx_sdma sbes;
> +static struct mpc52xx_xlb __iomem *xlb;
> +static struct mpc52xx_xlb sxlb;
> +static struct mpc52xx_gpio __iomem *gps;
> +static struct mpc52xx_gpio sgps;
> +static struct mpc52xx_gpio_wkup __iomem *gpw;
> +static struct mpc52xx_gpio_wkup sgpw;
> +extern char saved_sram[0x4000];
> +
> +static void lite5200_save_regs(void)
> +{
> + _memcpy_fromio(&sbes, bes, sizeof(*bes));
> + _memcpy_fromio(&spic, pic, sizeof(*pic));
> + _memcpy_fromio(&scdm, cdm, sizeof(*cdm));
> + _memcpy_fromio(&sxlb, xlb, sizeof(*xlb));
> + _memcpy_fromio(&sgps, gps, sizeof(*gps));
> + _memcpy_fromio(&sgpw, gpw, sizeof(*gpw));
> +
> + memcpy(saved_sram, sdma.sram, sdma.sram_size);
> +}
> +
> +static void lite5200_restore_regs(void)
> +{
> + memcpy(sdma.sram, saved_sram, sdma.sram_size);
> +
> + _memcpy_toio(gpw, &sgpw, sizeof(*gpw));
> + _memcpy_toio(gps, &sgps, sizeof(*gps));
> + _memcpy_toio(xlb, &sxlb, sizeof(*xlb));
> + _memcpy_toio(cdm, &scdm, sizeof(*cdm));
> + _memcpy_toio(pic, &spic, sizeof(*pic));
> + _memcpy_toio(bes, &sbes, sizeof(*bes));
> +}
> +
> +static int lite5200_pm_enter(suspend_state_t state)
> +{
> + /* deep sleep? let mpc52xx code handle that */
> + if (state == PM_SUSPEND_S
Re: boot LITE5200B
Juan Lopez wrote: > Hello all, > > I have a problem to boot a linux image in a Freescale LITE5200B, I > compile a Kernel image What kernel version, what origin ? ... > bootargs=root=/dev/mtdblock3 ro console=ttyS1 rootfstype=jffs2 > > The console = ttyS1 sounds weird ... there is only 1 serial on the lite5200b IIRC For 2.4 that's ttyS0 For 2.6 ttyPSC0 Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] mpc52xx_pic: fix main interrupt masking
Domen Puncer wrote:
> Fix main interrupt masking.
> Tested with RTC and GPIO_WKUP interrupts.
>
>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
>
Acked-by: Sylvain Munaut <[EMAIL PROTECTED]>
Damn, I knew I forgot something during the last batch ! That bug had
already been spotted earlier ...
> ---
> arch/powerpc/platforms/52xx/mpc52xx_pic.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: grant.git/arch/powerpc/platforms/52xx/mpc52xx_pic.c
> ===
> --- grant.git.orig/arch/powerpc/platforms/52xx/mpc52xx_pic.c
> +++ grant.git/arch/powerpc/platforms/52xx/mpc52xx_pic.c
> @@ -128,7 +128,7 @@ static void mpc52xx_main_mask(unsigned i
>
> pr_debug("%s: irq=%x. l2=%d\n", __func__, irq, l2irq);
>
> - io_be_setbit(&intr->main_mask, 15 - l2irq);
> + io_be_setbit(&intr->main_mask, 16 - l2irq);
> }
>
> static void mpc52xx_main_unmask(unsigned int virq)
> @@ -141,7 +141,7 @@ static void mpc52xx_main_unmask(unsigned
>
> pr_debug("%s: irq=%x. l2=%d\n", __func__, irq, l2irq);
>
> - io_be_clrbit(&intr->main_mask, 15 - l2irq);
> + io_be_clrbit(&intr->main_mask, 16 - l2irq);
> }
>
> static struct irq_chip mpc52xx_main_irqchip = {
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] lite5200(b) typos in dts
Domen Puncer wrote:
> Fix lite5200(b) copy paste typos in dts.
>
>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
>
Acked-by: Sylvain Munaut <[EMAIL PROTECTED]>
Obviously correct ...
> ---
> arch/powerpc/boot/dts/lite5200.dts |2 +-
> arch/powerpc/boot/dts/lite5200b.dts |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> Index: grant.git/arch/powerpc/boot/dts/lite5200.dts
> ===
> --- grant.git.orig/arch/powerpc/boot/dts/lite5200.dts
> +++ grant.git/arch/powerpc/boot/dts/lite5200.dts
> @@ -179,7 +179,7 @@
> interrupt-parent = <500>;
> };
>
> - [EMAIL PROTECTED] {
> + [EMAIL PROTECTED] {
> compatible = "mpc5200-gpio-wkup";
> reg = ;
> interrupts = <1 8 0 0 3 0>;
> Index: grant.git/arch/powerpc/boot/dts/lite5200b.dts
> ===
> --- grant.git.orig/arch/powerpc/boot/dts/lite5200b.dts
> +++ grant.git/arch/powerpc/boot/dts/lite5200b.dts
> @@ -179,7 +179,7 @@
> interrupt-parent = <500>;
> };
>
> - [EMAIL PROTECTED] {
> + [EMAIL PROTECTED] {
> compatible = "mpc5200b-gpio-wkup\0mpc5200-gpio-wkup";
> reg = ;
> interrupts = <1 8 0 0 3 0>;
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Dereferencing phys addr IMMAP works even if it is not a virtual address. Strange?
DI BACCO ANTONIO - technolabs wrote: > Now I'm doing a ioremap_nocache of IMMAP and using the virtual pointer > returned to access my 880 registers but also using the physical > address it works, I can access the registers. If the IMMAP base is high (like 0xf000 ) and therefore doesn't collide with anything, it's quite common practice to map it statically using a BAT somewhere in the setup code and often it's mapped such that phys = virt ... So a physical address in this zone is equal to a virtual addres ... When that's the case, ioremap detects the BAT mapping and just does nothing. But you should always use ioremap nonetheless ... because if at some point some one decide to move the BAT mapping, if you didn't do things properly your code will break. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC5200, PLX9054 PCI Card - stalled DMA transfers
>> Anyway, manually setup a DMA transfer and convince yourself that >> you know which bits to twiddle, then figure out why the driver >> code isn't doing as its asked. >> >> > > I've done so without success. The driver seems to make everything > correct. A block DMA is fairly simple on the 9054, so I think there must > be a hardware reason for this. > Has anybody ever used a PCI card on the MPC5200 which has its own > busmaster controller? I think most people use the BestComm DMA > controller on the MPC5200, right? > No, most PCI card that need big xfer uses bus mater. A ide card, a network card, ... all most certainly use it. Bestcomm on the 5200 is for the SoC internal peripheral mainly. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Howto set DIO on MPC-5200 Lite
Matthias Fechner wrote: > Hi, > > how can I set the DIO ports from a MPC-5200 Lite? > > > Best regards, > Matthias > > What's the DIO port ? Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Howto set DIO on MPC-5200 Lite
Matthias Fechner wrote: > Hi Pedro and Sylvain, > > Pedro Luis D. L. wrote: > >> Could you mean "GIO" ports? >> > > I mean the digital IO ports ok or general IO ports. > What I want is to set a signal to high or low which should control a relais. > > I thought I can use the pin Dxx for that on the board. > > Best regards, > Matthias > Well, just lookup the schematics to which port the pin you want to control is connected, then look in the datasheet how to control the GPIO. You must make sure the port you want to control is in gpio mode in port_config register, then setup it as output and drive a value onto it ... There is nothing currently in place to do that easily from userspace ... Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 3/5 v2] mpc52xx suspend: USB
Domen Puncer wrote:
> + struct usb_hcd *hcd = dev_get_drvdata(&op->dev);
> + if (machine_is_compatible("generic-mpc5200")) {
> + struct ohci_hcd *ohci = hcd_to_ohci(hcd);
>
>
Not good, what if you have a Ohci PCI card on a 5200 board ...
You somehow need to check the compatible list of the of_node associated
with the particular instance you're putting to sleep.
Sylvain
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Howto set DIO on MPC-5200 Lite
Steven Kaiser wrote: > EFIKA seems to have some sort of battery backed RTC to keep date and time, > but without a schematic I can't be sure what it is. Would be nice if the > LITE500B had something like this. What 5200B chip pins does EFIKA use for > this? Maybe should reserve these pins for a future RTC in the EFIKA > tradition. > The EFIKA has a small PIC that serves for power up / down and to keep time. I think it's on a I2C bus but I don't know if they implemented it with the embedded I2C controller or by bitbanging some GPIO. (never saw the schema so that's and educated guess ...) > So my general question is this: What pins on the 5200B are free for external > use by the user (i.e. what pins are reserved by the linux 2.4 and 2.6 stock > kernels for internal use)? > I can only speak for 2.6 and AFAIK it's none ... Anyway you will need to write your own board file and your own device tree and have your boot loader set port_config appropriatly. From there you can free any pin you want (provided that pin is not used by a function you want of course ...) The lines used for PCI IRQ are specified for the Lite5200 and Lite5200B in their device tree (or in the board file if you still use arch/ppc). So when you write those files for your board, just make sure it match your board. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Avoid putting cpu node twice
John Rigby wrote:
> Call of_find_node_by_type with NULL instead of np
> so the cpu node does not get put twice.
> This was causing kref_put warnings.
>
> Signed-off-by: John Rigby <[EMAIL PROTECTED]>
Acked-by: Sylvain Munaut <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/52xx/lite5200.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/52xx/lite5200.c
> b/arch/powerpc/platforms/52xx/lite5200.c
> index cc3b40d..d2f90eb 100644
> --- a/arch/powerpc/platforms/52xx/lite5200.c
> +++ b/arch/powerpc/platforms/52xx/lite5200.c
> @@ -108,9 +108,11 @@ static void __init lite5200_setup_arch(void)
>lite5200_setup_cpu(); /* Platorm specific */
>
> #ifdef CONFIG_PCI
> - np = of_find_node_by_type(np, "pci");
> - if (np)
> + np = of_find_node_by_type(NULL, "pci");
> + if (np) {
>mpc52xx_add_bridge(np);
> + of_node_put(np);
> + }
> #endif
>
> #ifdef CONFIG_BLK_DEV_INITRD
> --
> 1.5.0.6
>
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: RFC: MPC52xx serial port configuration from DT blob
Bartlomiej Sieka wrote:
> Hi All,
>
> We have a MPC5200B-based board running an arch/powerpc kernel and we
> need the ability to configure a non-console serial port for a particular
> baud rate during system start-up. It seems that the UART driver in
> drivers/serial/mpc52xx_uart.c does not support this. It only allows to
> set parameters for a port that is used as a console, and for which those
> parameters are passed in the kernel command line. We would like to
> extend the mpc52xx_uart.c driver to be able to retrieve port options
> from the DT blob and configure a given port accordingly. A new
> port-specific property called "options" would be used for this. It would
> have syntax following its namesake in "console" kernel parameter, as
> described in Documentation/kernel-parameters.txt.
>
> For example, the following settings in the .dts file would make UART5 to
> be configured at 115200 baud, no parity, 8 bits.
>
> [EMAIL PROTECTED] { // PSC5
> device_type = "serial";
> compatible = "mpc5200b-psc-uart\0mpc5200-psc-uart";
> port-number = <4>; // Logical port assignment
> options = "115200n8"
> cell-index = <4>;
> reg = <2800 100>;
> interrupts = <2 c 0>;
> interrupt-parent = <500>;
> };
>
>
> In case a console port has conflicting options given in the kernel
> command line and in the DT blob, the command line values would be used.
>
> Any comments on the above will be appreciated.
>
The kernel only "use" the serial for console. If it's not a console,
then it's used
by userspace and it's userspace job to configure it as it sees fit imho ...
Sylvain
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [Fwd: [alsa-devel] embedded sound architecture question]
Hi, >> If I were you, I would chose one of sound cards which have ALSA >> drivers implemented (the list can be found on ALSA site) and >> mimicked their behavior in your VHDL. >> > > Actually a bunch of theses drivers rely on PCI or ISA. > The few left do all require DMA, what is only an option, if it is some sort > of faked DMA, so the CPU writes directly into the controller's memory as we > intend to stay as independent as possible from Xilinx' IP Cores. > The question was: is that a good (and practicable) idea? > If you can spare the BRAM, that sounds good to me. I'm not an alsa expert but I'm working on a driver right now. And alsa provide you a hook so you can allocate your memory buffer your self. So as long as your control maps it's memory somewhere in the cpu address space you should be fine. What you need is : - Be able to ask the hardware where is is "read pointer". - Be able to ask the hardware to generate an interrupt every 'n' samples. And that should do it. You also need to make the controller build the AC97 frames itself (e.g. for the control slots, a separate set of registers), and also preferrably supporting multiple sample format so the CPU needs to do a minimum of conversion. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC5200 ethernet communication stops unexpected
David Kanceruk wrote: > Hello Hans, > > Our problem was with the FEC sending data with one or two > incorrect bytes when we switched from the MPC5200 to the MPC5200B. The > byte positions were always the same. The socket buffer has the correct > data before and after the DMA engine runs but the FEC TxFIFO does not > always match. > > One solution to our problem was to make the following call prior to > starting the DMA: > > flush_dcache_range((unsigned long)skb->data, (unsigned long)skb->data > + skb->len); > > The other solution was to set the BSDIS bit in the XLB config register > during initialization as follows: > > xlb = (struct mpc52xx_xlb *)MPC5xxx_XLB; > out_be32(&xlb->config, in_be32(&xlb->config) | MPC52xx_XLB_CFG_BSDIS); > > Either solution works for us. The BSDIS bit is a new feature in the > MPC5200B. The MPC5200 did not have this bit. > > According to the Freescale documentation, (Application note AN3045, > for instance) setting this bit is supposed to "disable" BestComm bus > snooping. However, I have reason to believe the documentation is in > error. Everything I have observed seems to indicate that in the > MPC5200 BestComm bus snooping was always enabled or enabled via some > other means. In the MPC5200B it appears to be "disabled" at reset (not > "enabled" as the documentation states). This is why flushing the cache > manually is one solution. Since setting the BSDIS bit also fixes the > problem, it suggests that this actually "enables" BestComm bus > snooping instead of disabling it. In my mind, it could all boil down > to a simple documentation error. > That problem is _very_ weird ... >From what I understand, Bestcomm XLB snooping means that when the BestComm engine has some data cached internally and that it detects a write to the address from where those data comes, he will invalidate his cache. But when the kernel writes data to the skb buffer, they may partially stay in cache so there won't be any transaction at all on the xlb bus. It's when bestcomm will read the skb, that the core will snoop the bus, detects there is a read request for some data he has in cache, force a retry of the bestcomm read, write the data to memory (via xlb), and finally let bestcomm retry the transaction to fetch the good data. So I guess what "could" happen is that : - The kernel allocate a skb, but it ends up being as the same memory location as a "previous" one. (or maybe in a directly following position because of prefetch). - You submit it to bestcomm - When bestcomm does the read, since the skb was used "just before", the line is still in cache but with the wrong data. Since the kernel just wrote the data, there was not yet a xlb transaction because the data are still in cpu cache. Bestcomm think he has the data (no xlb write so it's cache was not invalidated), so he doesn't generate a xlb read. But if there is no xlb read the core doesn't get a chance to snoop it and doesn't flush it's cache ... Although that doesn't explain why setting BSDIS high solve the problem, nor why there is only 1 byte wrong ... Have you checked your XLB snoop window setting ? And that core snooping is enabled ? Also that you don't use the "nap" power saving feature of the core ? (it disables snooping altogether ...). Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [Fwd: [alsa-devel] embedded sound architecture question]
Joachim Förster wrote: > Hi Sylvain, > > thank you very much for your mail, > > On Tue, 2007-05-15 at 09:09 +0200, Sylvain Munaut wrote: > >> I'm not an alsa expert but I'm working on a driver right now. And alsa >> provide you a hook so you can allocate your memory buffer your self. >> So as long as your control maps it's memory somewhere in the >> cpu address space you should be fine. >> > > By "hook", do you mean the prepare()/hw_params() callbacks? > hw_params and hw_free yes. I personally use snd_pcm_lib_malloc_pages to allocate the buffer, but you'll have to write your own, and in the same call back configure the period rate for you hw to generate interrupt. > I noticed that there is an (undocumented?) mmap() callback, too, so I > think, I have to implement that one and call something like > io_remap_pfn_range() to "connect" the device's memory to the VMA > (virtual memory area) which is provided as an argument to the mmap() > callback, right? > Sorry, no idea ... but it's likely that you need to handle the mapping of this zone in userspace by yourself ... > In our case, we are not going to allocate any memory like a typical ALSA > driver does (with DMA) (in prepare()/hw_params() callback), because the > device's IO memory will "be there" - we just have to "announce"/map it > into kernel space, right? Or is this interpretation wrong? > No I think that should work. You need a quite a few BRAMs though ... buffers are often 128k at the minimum, so that's 64 brams Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] mpc52xx_psc_spi: fix it for CONFIG_PPC_MERGE
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 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] mpc52xx_psc_spi: fix it for CONFIG_PPC_MERGE
David Brownell wrote: > On Wednesday 16 May 2007, Sylvain Munaut wrote: > >> Well, this comment is not about the patch but about the driver it self, >> I didn't see it before today. >> > > It merged earlier in the 2.6.22 cycle. If you don't have criticisms > about the patch itself, I'll forward it for merging after I get at > least an ack from Dragos. > Yes, I saw when looking at the spi-devl archive. Would have been nice if the author though of cc-ing the ppc-embedded list ;) The patch looks ok to me (and needed actually since as Domen pointed out, 52xx has been replaced by 5200 in the device tree). And cell-index has been added to know the psc id without dirty tricks. >> - 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. >> > > That PPC_MERGE stuff does look messy. > Yes, trying to support both in a driver is really not pretty. Once we can finally get rid of it I'll submit a patch to clear that out. >> - 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. >> - 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 >> > > Best to use for all of those, but it seems powerpc/ppc > don't support those interfaces yet ... is there maybe a plan for > resolving that issue? > Mmm, I wasn't aware of that interface, I'll look into that. Thanks. Sylvain ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] unbreak lite5200 dts (_pic vs. -pic)
Acked-by: Sylvain Munaut <[EMAIL PROTECTED]> Paul, can you pick this up for you next send ? Here's the patchwork link in case you don't follow -embedded. http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11248 Sylvain Domen Puncer wrote: > Unbreak lite5200 dts, which were broken by > 5c1992f83304cf2d56934dd6c06709b96e1b0c81 > > > Signed-off-by: Domen Puncer <[EMAIL PROTECTED]> > > --- > arch/powerpc/boot/dts/lite5200.dts |2 +- > arch/powerpc/boot/dts/lite5200b.dts |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200.dts > === > --- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200.dts > +++ work-powerpc.git/arch/powerpc/boot/dts/lite5200.dts > @@ -67,7 +67,7 @@ > interrupt-controller; > #interrupt-cells = <3>; > device_type = "interrupt-controller"; > - compatible = "mpc5200_pic"; > + compatible = "mpc5200-pic"; > reg = <500 80>; > built-in; > }; > Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts > === > --- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200b.dts > +++ work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts > @@ -67,7 +67,7 @@ > interrupt-controller; > #interrupt-cells = <3>; > device_type = "interrupt-controller"; > - compatible = "mpc5200b-pic\0mpc5200_pic"; > + compatible = "mpc5200b-pic\0mpc5200-pic"; > reg = <500 80>; > built-in; > }; > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [RFC 1/3] Re: [PATCH] mpc52xx_psc_spi: fix it for CONFIG_PPC_MERGE
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 <[EMAIL PROTECTED]>
>
> ---
> 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
>
>
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] mpc52xx: Correct calculation of FEC RX errors.
Nice catch, I knew something was wrong ( 4 billion errors ;) but I never bothered to look it up. Sylvain Grzegorz Bernacki wrote: > 'ifconfig eth0' command for mpc5200B-based cards shows error for RX. > However none of RX MIB counters is set to value greater than zero. > Number of errors is equal to number of multicast packet. In linux 2.4 > calculation of RX errors is slightly different and takes into account > number of multicast packet. This change is a port of calculation method > of RX errors for FEC controller from linux 2.4 to 2.6. > > Signed-off-by: Grzegorz Bernacki <[EMAIL PROTECTED]> > --- > > drivers/net/fec_mpc52xx/fec.c |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/drivers/net/fec_mpc52xx/fec.c b/drivers/net/fec_mpc52xx/fec.c > index f0ce87e..d2087f6 100644 > --- a/drivers/net/fec_mpc52xx/fec.c > +++ b/drivers/net/fec_mpc52xx/fec.c > @@ -395,7 +395,9 @@ static struct net_device_stats *fec_get_stats(struct > net_device *dev) > > stats->rx_bytes = in_be32(&fec->rmon_r_octets); > stats->rx_packets = in_be32(&fec->rmon_r_packets); > - stats->rx_errors = stats->rx_packets - > in_be32(&fec->ieee_r_frame_ok); > + stats->rx_errors = stats->rx_packets - ( > + in_be32(&fec->ieee_r_frame_ok) + > + in_be32(&fec->rmon_r_mc_pkt)); > stats->tx_bytes = in_be32(&fec->rmon_t_octets); > stats->tx_packets = in_be32(&fec->rmon_t_packets); > stats->tx_errors = stats->tx_packets - ( > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC5200 fec frame corruption
Hi Asier, > We have been working with the MPC5200 fec and a linux-2.6.10 with some > patches extracted from Sylvain's bitkeeper repository. We have 3 > different boards that worked properly with that kernel. > > We upgraded to the new MPC5200B and it still worked properly with the > 2.6.10 kernel. > > We upgraded to the new code of the Sylvain's git repository and the FEC > transmitted frames are corrupted. This corruption only happens with the > current git repository and the MPC5200B. > > MPC5200 MPC5200B > linux-2.6.10: OK OK > Sylvain's git:OK CORRUPT > I must admit I don't have bitkeeper anymore installed on my machine so I don't remeber exactly what in there. Could you put somewhere on line the diff between 2.6.10 and you tree, eventually minus all the irrelevant/confidential stuff ? What would be needed woud be the arch/ppc/syslib/bestcomm , drivers/net/fec_mpc52xx and the board setup code. > The problem is that the lite5200 and the lite5200b work flawlessly, but > our architecture is essentialy the same but with different PHYs (Marvell > 88E6095F and 88E6060). Our architecture works properly with the > linux-2.6.10, so we don't think that it is a hardware related problem. > We have been watching the MII bus by osciloscope and the errors are > clearly transmitted by the MPC5200B (no noise or distortion). > > We have inserted traces in the functions of the FEC driver with the > buffer information that is sent to the DMA and the frames are correct. > > > [... logs stripped ...] > The corrupted bytes are sometimes correct, sometimes overwriten > by the byte that is 0x20 bytes before, and sometimes changed > by the bytes that is 0x40 bytes before. About 50% of the time > the marked bytes are worong. > > I'd like to know if anything here makes any sense to you, so > that I can understand the origin of the problem, or any > additional test to perform. > Any sense not really. But I would check first the options in the board setup. Things like cache snooping, comm bus prefetching, xlb priority settings and pipelining, ... Then the microcode of the task themselves and the options wich are used when loading them. Finally compare the driver code itself. Sylvain
MPC5200 PCI byte-swapping
Mark Chambers wrote: >I've just realized that the 5200 does byte-lane swapping >on all PCI accesses. That is, if you write a 32 bit word >0x12345678, 0x12 will go out on byte 0, 0x34 on byte 1, >etc. Unfortunately, my target, a T.I. DM642, does not >do this, so I've got a big/little endian mismatch. A couple >of questions if anybody knows: > >- Do all MPC8xxx processors do this - byte swap on >all PCI accesses, not just configuration space? > >- Is there an elegant (simple) way to re-swap the bytes? >It's not a big problem really, but if there were a way to >set LE mode on a particular page or something like that >it might be worth it. > > > I'm not sure of what you mean but look at the mapping aroung pdf page 337 of the user manual. It's not configurable as far as I can see. Sylvain
MPC5200 PCI byte-swapping
>Thanks. I had an older manual that didn't spell it out so >clearly. > >I've been trying to interpret the PCI sections for some other >82xx family parts, and it appears that they do NOT do this >byte lane swapping, so this make the 5200 non-standard in >this regard, which is unfortunate. If I'm understanding this >right, one would have to have different drivers for a PCI >device on a 5200 and an 8270, for instance. > > Mmmm ... Still I use the intel eepro driver without problems or modifications. As long as the driver uses the proper readl/writel that should do it or am I mistaken ? I have a FPGA mounted with pci interface, I'll try to see what happens on the bus >Also, I note that when doing simple block reads from pre- >fetchable PCI space, it appears the 5200 does not prefetch, >but does each read individually. This is using stock ELDK >u-boot and 2.4.24 so I haven't yet determined if it's a >configuration matter, (or ruled out target disconnects) >but I'm suspecting that you can't get burst mode from the >5200 without using DMA. > > Last time I checked, the 2.4 from denx didn't create a pci window for prefetchable memory so prefetch mem zone were mapped as non-prefetchable, so no burst for sure. Sylvain
kernel option "Command line partition table parsing"
Robert P. J. Day wrote: > > i'm intrigued by the above kernel option. currently, i define my > MTD partitions in drivers/mtd/maps/rpxlite.c, using structs > map_info, mtd_info, etc., and calling the appropriate routines, > which works just fine. > > will this kernel option actually let me define the basic MTD > partitions completely from the kernel command line without messing > with rpxlite.c? or am i misreading the purpose of this option? I'd suggest having a look at the comment on top of drivers/mtd/cmdlinepart.c But I'm not sure if rpxlite.c . From what I see, it may require to add a "probe" to look at the command line. Someone ? Sylvain Munaut ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Making a "paged" sram aread appear as linear.
Hi, Let's say I have a device on the SRAM bus that an internal RAM of 8Mbyte. It's connected to the MCU on it's SRAM bus. But on the SRAM bus, It only has two window of 64k. One is all the control registers and the other can be mapped to any 64k segment of the device internal RAM. Now, I'd like that a user space process can mmap / open / read / write this aread as if it was linear. So what I thinked of was to allocate a contiguous area of 8Mb, then only really map the current active 64k area and then set a "handler" to catch access to the others area so it can set the active page. The problem is that I have no idea if that's possible, or how to do it. Any advice, pointers ? Sylvain Munaut ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Making a "paged" sram aread appear as linear.
After a little chat on IRC with 'ebs', it seems that changing the vm_operations_struct of the vm_area_struct I get with the mmap call. I'd like to let the cache be enabled for performance. So for me the steps when the user request access to a segment different from the current one are : 1) Flush the cache of the current mapped segment 2) Unmap the segment 3) Write to the control reg to select another segment 4) Map the new area 5) Do what the user requested Any other issues I should take care of ? Sylvain Munaut Sylvain Munaut wrote: | | | Hi, | | Let's say I have a device on the SRAM bus that an internal RAM of | 8Mbyte. It's connected to the MCU on it's SRAM bus. But on the SRAM | bus, It only has two window of 64k. One is all the control | registers and the other can be mapped to any 64k segment of the | device internal RAM. | | Now, I'd like that a user space process can mmap / open / read / | write this aread as if it was linear. So what I thinked of was to | allocate a contiguous area of 8Mb, then only really map the current | active 64k area and then set a "handler" to catch access to the | others area so it can set the active page. The problem is that I | have no idea if that's possible, or how to do it. | | Any advice, pointers ? | | | Sylvain Munaut | | | ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCI scanning and devices initialization
Stefano Gaiotto wrote: >Dear colleagues, > >I'm trying to use a device connected to a PCI bus, more exactly a >PCI/PCMCIA bridge >with u-boot-1.1.1 and Linux (2.4.24 and 2.6.8) in a board with MPC8270. > >Both u-boot and Linux, during scanning procedure show me only the PCI >bridge [1057/18c0] but I can't see the devices connected to the bus. > >I'm a novice with PCI bus and I'm not sure the board is good (is the first >prototype) and so I'd like to know if scanning procedure should tell me the >devices >connected or I have to do some device initialization before I can see them >during scanning. > >I suppose I should see them during scanning and then initialise them via >PCI bus. > >If my assumption is true, shall I suppose my hardware is not good? Or >anything else? > > Hi Yes, there may be something wrong with your hardware. I'm not familiar with the MPC8270 PCI code but your devices should show up during scan. At the PCI init, PCI devices don't yet have an address, so the host detects them using configuration cycles. Theses uses a different addressing scheme, using each address line as a kind of "chip select". So the devices know the host is "talking" to it just by looking at it's IDSEL line going asserted. If on your board the IDSEL isn't wired properly then it won't work. Hopefully if that's the case, you can just wire it by hand, it's not a high speed signal. Also, I've come accross some simple FPGA implementation of PCI devices that just didn't respond to config ... Sylvain PS: I'm not a PCI expert and that's just my understanding. There is probably a lot of things that can go wrong. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[RFC] Re: BestComm and fec
Hi >>Apparently, you've both worked out a version of bestcomm for 2.6. But >>you both based it on old code. (even non GPL). >> >> > >Terrible, may be its time to create special project for MPC5200 (if it >doesn't exist in somewhere in I-net)? First intention - sourceforge. >Comments/suggestions? > >Sylvain, Wolfgang I know you already have projects. But in case of >Sylvain, as I understand, his project on his homepage. >In case of Wolfgang, I'm not sure that DENX will happy to share their >internal CVS with all I-net for write access. Am I right? > > I personnaly use BitKeeper to maintain my trees. I can't provide write access to them because I don't administrate the server they are on, To write, you would need a ssh account and I juste have one for me and can't create others. I try to publish what I'm doing in www.246tNt.com/mpc52xx/state.txt >>I've just tried just taking the newer one and stick it in 2.6 with the >>fec Gabor sent, but it just crashes so it need more work ;) Dale >>Farnsworth just said it'll look into it and porting new bestcomm as well. >> >> > >My fec port work ok. > > Based on old bestcomm or new ? >And CAN, RTC, and possible CRC32/16 (if it will fast enough) :). > > CAN is not on my personnal project list since I have nothing that uses so I couldn't test it anyway. RTC ? The MPC5200 can't save time AFAIK. And Linux should already 'count' time correctly I think. By CRC32/16 I guess you mean to use the BestComm DMA engine to implement the kernel CRC Library ? I'm not sure I've pushed PCI on my tree ( bk://bkbits.246tNt.com/linux-2.5-mpc52xx ) yesterday night. So if you're in position to test it please report ;) Sylvain ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[RFC] MPC5200 dev (was Re: [RFC] Re: BestComm and fec)
Since It's clear that with more peoples working on it, there is a need of synchro. Here's what I'm proposing : I'll a tree : bk://bkbits.246tNt.com/linux-mpc52xx-devel This tree would contain all the latest code to be tested by others. Just send patch to the ml and cc me, I'll put them in this tree. Once every one is happy with it (or part of it), I'll take care of pushing it upstream. Note that since all current work with bestcomm is based on non-GPL code, It won't be in until Dale send me the version he's working on (based on latest code). To avoid duplicate work, you can post here what you're doing, I'll try to keep http://www.246tNt.com/mpc52xx/state-devel.txt up-to-date with who's doing what. The point is to centralize the testing code and having a 'single' contact to merge the work upstream to ease the work of upstream maintainers. This tree is being setup right now, please allow a few hours ;) Comments, suggestions are of course welcome. Sylvain Andrey Volkov wrote: >Hello David, > >Tuesday, August 24, 2004, 12:54:46 PM, you wrote: > > > > >>On Tue, 2004-08-24 at 12:07 +0400, Andrey Volkov wrote: >> >> >>>Terrible, may be its time to create special project for MPC5200 (if it >>>doesn't exist in somewhere in I-net)? First intention - sourceforge. >>>Comments/suggestions? >>> >>> > > > >>Don't start a new project. Just put your changes into the official 2.6 >>tree. >> >> > > > >>The goal of _all_ external trees should be to make themselves obsolete >>by getting all changes to Linus as quickly as possible. Why shoot >>yourself in the foot? >> >> > >Indeed, BUT: > 1) IMHO mail list better approach for >along developer <-> maintainer/many tester > scheme of development. Cvs/bk will be better for team work isn't it? > > 2) So somewhere must exist place for coordination of job, 'cause > I see as minimum 5 person doing SAME work (terrible). > > 3) And I wish have common place for experiments and testing. AFAIK, stable > kernel is not appropriate for it. (If I wrong - why exist -mm -ac > etc branches? :) > >-- >Best regards, > Andrey Volkov > > > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
FEC_IEVENT_RFIFO_ERROR
Hi
> I run 2.6.10-rc2 kernel (http://www.246tNt.com/mpc52xx/)
> for MPC5200 chip on a custom board that is almost lite5200 compatible.
> I noticed a couple of times I have a strange error at bootup.
> It was FEC_IEVENT_RFIFO_ERROR. Most of the times this
> went trough without problems but since today system just hangs.
> Sometimes with several printouts of this error.
> ---boot sequence --
> FEC_IEVENT_RFIFO_ERROR
> FEC_IEVENT_RFIFO_ERROR
> FEC_IEVENT_RFIFO_ERROR
>
Theses are definitly not "normal" but you said "since today it just hangs",
did something change in the environment of the card ?
> I traced a problem a bit and found that this happenes at
> mpc52xx_fec_probe() function in fec.c at this point:
> -
>
>
> /* Get the IRQ we need one by one */
>/* Control */
>dev->irq = ocp->def->irq;
> --> if (request_irq(dev->irq, &fec_interrupt, SA_INTERRUPT,
>"mpc52xx_fec_ctrl", dev)) {
>printk(KERN_ERR "mpc52xx_fec: ctrl interrupt request
> failed\n");
>ret = -EBUSY;
>dev->irq = -1; /* Don't try to free it */
>goto probe_error;
>}
> --
>
>
It ovbiously can't happen before since the message it printed in that
interrupt
handler. But it should not happen there either (not so early) !
This error globally says : "Somthing got wrong with the receive buffer". But
at this point, frame reception is not yet enabled, how could it go wrong
? Unless
your bootloader don't take care of shutting down the fec, then frames
may be
stuck in the fifo between the bootloader and the fec init ...
> This is what I found in MPC5200 Users Manual:
> Receive FIFO Error--indicates error occurred within the forest green
> version
> RX FIFO. When RFIFO_ERROR bit is set, ECNTRL.ETHER_EN is cleared,
> halting FEC frame processing. When this occurs, software must ensure both
> the FIFO Controller and BestComm are soft-reset.
>
> Any ideas on what could be causing this?
I can't explain why this happen so early at init (as I said before) but
other things that could
cause such an event :
- We don't have enough buffer descriptors : The bescomm task just fill
them all and runs out
of them before the interrupt is handled.
- The bestcomm engine don't flush the RX fifo quicly enough. Currently
the only tasks
- Bestcomm stopped processing for whatever reason ...
- Something else that I don't see at the moment. I'll try to "stress
test" network a little bit,
see if I can reproduce the issue.
In the mean time, pull the latest change, I just pushed some fixes
related to frame reception,
I don't think it's related to your issue but ...
Sylvain
FEC_IEVENT_RFIFO_ERROR
Hi > > I tried the patch you've sent and It's still the same. > FEC_IEVENT_RFIFO_ERROR is still here. > Can you/anyone think of something that I could do to make > analyzing this problem easier? > Resetting the FEC early is a good thing so that patch should be there anyway, so we don't setup irq handlers for a hardware in unknow state. However looking at fec code, there is another problem with it : The FEC is enabled in probe, once for all but the DMA tasks that should empty the buffers are only enabled when the interface is up, so during it's down time, any received packed ends up in filling the FIFO ... This problem goes away when the interface is up tough, so you should not experience 'crash' ... Do you nfs boot ? Try with a static image, just to see, maybe having the error at boot screw something. If it doesn't boot with a static image then there is still another problem. Sylvain
MPC5200 kernel with IDE *and* FEC?
Stephen Warren wrote: >From: Dale Farnsworth [mailto:dale at farnsworth.org] > > >>On Tue, Mar 08, 2005 at 05:34:20PM +, Stephen Warren wrote: >> >> >>>I looked at the 2.6.11 kernel.org kernel, and it has MPC5200 IDE >>>support, but apparently no FEC driver support. >>> >>> >>Are you sure it has MPC5200 IDE support? I have yet to see reliable >>5200 IDE support and haven't seen a 5200 IDE driver for 2.6 at all. >> >> > >Not sure, no. Looking at "xconfig", I don't see an option for it. A >colleague said it did. > > No it doesn't. Or it's very well hidden ;) But If you do write it, patches are welcomed. >We've used IDE (for a DVD-ROM) using the Denx kernel. This didn't have >DMA suppport, but Freescale gave us a derivate kernel that it, which >seemed to work well. They said they were going to push this up through >Denx into the main kernel. Didn't they bother to do this? > > I guess they mean push it to Denx kernel which IS the main 2.4 kernel for MPC5200. No new platform support will be accepted for 2.4 now. And freescale probably won't write driver for the tree I maintain since I'm not using the official BestComm API. Sylvain
RFC/Commit: New ocp id for CANbus devs
Andrey Volkov wrote: > Hi Kumar: > >> Is this for 2.6? > > Oh sorry, certainly for 2.6 (Sylvain's kernel more precisely). > But since, Sylvain not maintainer of ocp_ids.h, so I send > this patch to Paul (who create it, am I right?). > >> If so, 5200 needs to be moved to using the new driver model and >> platform devices. Take a look at support for MPC85xx or marvell >> (mv64x60) as examples. >> >> - kumar > > Kumar, please, more cleanly, what did you want to say? If you told about > board_ocp[] in lite5200.c (platform specific). Then yes, I use it, but > not mpc5200.c > No, what he said is that MPC5200 needs to be moved to use the platform bus driver model. I'll post the patch doing just that on Monday along with PCI and sparse clean-ups. (Unless something goes wrong ...) Sylvain
[PATCH 1/2] MPC52xx updates : sparse clean-ups
Hi Tom & all
Here's some updates related to the Freescale MPC52xx. First some
clean-ups for sparse warnings and then PCI support. I'd like to get
theses approved & merged before I submit conversion to platform bus
model.
As usual, the patches can also be pulled of a bk repository :
bk://tnt.bkbits.net/linux-2.5-mpc52xx-pending
(note it's _NOT_ the same url as before even if it's close ;)
Sylvain
---
diff -Nru a/arch/ppc/syslib/mpc52xx_pic.c b/arch/ppc/syslib/mpc52xx_pic.c
--- a/arch/ppc/syslib/mpc52xx_pic.c 2005-03-11 20:41:36 +01:00
+++ b/arch/ppc/syslib/mpc52xx_pic.c 2005-03-11 20:41:36 +01:00
@@ -33,8 +33,8 @@
#include
-static struct mpc52xx_intr *intr;
-static struct mpc52xx_sdma *sdma;
+static struct mpc52xx_intr __iomem *intr;
+static struct mpc52xx_sdma __iomem *sdma;
static void
mpc52xx_ic_disable(unsigned int irq)
@@ -173,7 +173,7 @@
mpc52xx_ic_disable, /* disable(irq) */
mpc52xx_ic_disable_and_ack, /* disable_and_ack(irq) */
mpc52xx_ic_end, /* end(irq) */
- 0 /* set_affinity(irq, cpumask)
SMP. */
+ NULL/* set_affinity(irq, cpumask)
SMP. */
};
void __init
@@ -183,10 +183,8 @@
u32 intr_ctrl;
/* Remap the necessary zones */
- intr = (struct mpc52xx_intr *)
- ioremap(MPC52xx_INTR, sizeof(struct mpc52xx_intr));
- sdma = (struct mpc52xx_sdma *)
- ioremap(MPC52xx_SDMA, sizeof(struct mpc52xx_sdma));
+ intr = ioremap(MPC52xx_INTR, sizeof(struct mpc52xx_intr));
+ sdma = ioremap(MPC52xx_SDMA, sizeof(struct mpc52xx_sdma));
if ((intr==NULL) || (sdma==NULL))
panic("Can't ioremap PIC/SDMA register for init_irq !");
diff -Nru a/arch/ppc/syslib/mpc52xx_setup.c
b/arch/ppc/syslib/mpc52xx_setup.c
--- a/arch/ppc/syslib/mpc52xx_setup.c 2005-03-11 20:41:36 +01:00
+++ b/arch/ppc/syslib/mpc52xx_setup.c 2005-03-11 20:41:36 +01:00
@@ -39,7 +39,8 @@
void
mpc52xx_restart(char *cmd)
{
- struct mpc52xx_gpt* gpt0 = (struct mpc52xx_gpt*) MPC52xx_GPTx(0);
+ struct mpc52xx_gpt __iomem *gpt0 =
+ (struct mpc52xx_gpt __iomem *) MPC52xx_GPTx(0);
local_irq_disable();
@@ -102,7 +103,7 @@
#endif
static void
-mpc52xx_psc_putc(struct mpc52xx_psc * psc, unsigned char c)
+mpc52xx_psc_putc(struct mpc52xx_psc __iomem *psc, unsigned char c)
{
while (!(in_be16(&psc->mpc52xx_psc_status) &
MPC52xx_PSC_SR_TXRDY));
@@ -112,8 +113,9 @@
void
mpc52xx_progress(char *s, unsigned short hex)
{
- struct mpc52xx_psc *psc = (struct mpc52xx_psc *)MPC52xx_CONSOLE;
char c;
+ struct mpc52xx_psc __iomem *psc =
+ (struct mpc52xx_psc __iomem *)MPC52xx_CONSOLE;
while ((c = *s++) != 0) {
if (c == '\n')
@@ -138,11 +140,11 @@
* else get size from sdram config registers
*/
if (ramsize == 0) {
- struct mpc52xx_mmap_ctl *mmap_ctl;
+ struct mpc52xx_mmap_ctl __iomem *mmap_ctl;
u32 sdram_config_0, sdram_config_1;
/* Temp BAT2 mapping active when this is called ! */
- mmap_ctl = (struct mpc52xx_mmap_ctl*) MPC52xx_MMAP_CTL;
+ mmap_ctl = (struct mpc52xx_mmap_ctl __iomem *)
MPC52xx_MMAP_CTL;
sdram_config_0 = in_be32(&mmap_ctl->sdram0);
sdram_config_1 = in_be32(&mmap_ctl->sdram1);
@@ -169,13 +171,11 @@
/* if bootloader didn't pass bus frequencies, calculate them */
if (xlbfreq == 0) {
/* Get RTC & Clock manager modules */
- struct mpc52xx_rtc *rtc;
- struct mpc52xx_cdm *cdm;
+ struct mpc52xx_rtc __iomem *rtc;
+ struct mpc52xx_cdm __iomem *cdm;
- rtc = (struct mpc52xx_rtc*)
- ioremap(MPC52xx_RTC, sizeof(struct mpc52xx_rtc));
- cdm = (struct mpc52xx_cdm*)
- ioremap(MPC52xx_CDM, sizeof(struct mpc52xx_cdm));
+ rtc = ioremap(MPC52xx_RTC, sizeof(struct mpc52xx_rtc));
+ cdm = ioremap(MPC52xx_CDM, sizeof(struct mpc52xx_cdm));
if ((rtc==NULL) || (cdm==NULL))
panic("Can't ioremap RTC/CDM while computing bus
freq");
@@ -212,8 +212,8 @@
__res.bi_pcifreq = pcifreq;
/* Release mapping */
- iounmap((void*)rtc);
- iounmap((void*)cdm);
+ iounmap(rtc);
+ iounmap(cdm);
}
divisor = 4;
diff -Nru a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
--- a/drivers/serial/mpc52xx_uart.c 2005-03-11 20:41:36 +01:00
+++ b/drivers/serial/mpc52xx_uart.c 2005-03-11 20:41:36 +01:00
@@ -86,7 +86,7 @@
*the console_init
*/
-#define PSC(port) ((struct mpc52xx_psc *)((port)->membase))
+#define PSC(port) ((struct mpc
[PATCH 2/2] MPC52xx updates : PCI Support
And here's the second patch :
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/11 19:58:21+01:00 tnt at 246tNt.com
# ppc32: Add PCI bus support for Freescale MPC52xx
#
# Note that this support has "known" problem but theses
# are believed to be due to hardware issues.
#
# Signed-off-by: Sylvain Munaut
#
# arch/ppc/syslib/mpc52xx_pci.h
# 2005/03/11 19:57:56+01:00 tnt at 246tNt.com +139 -0
# ppc32: Add PCI bus support for Freescale MPC52xx
#
# include/linux/pci_ids.h
# 2005/03/11 19:57:56+01:00 tnt at 246tNt.com +1 -0
# ppc32: Add PCI bus support for Freescale MPC52xx
#
# include/asm-ppc/mpc52xx.h
# 2005/03/11 19:57:56+01:00 tnt at 246tNt.com +2 -0
# ppc32: Add PCI bus support for Freescale MPC52xx
#
# arch/ppc/syslib/mpc52xx_pci.h
# 2005/03/11 19:57:56+01:00 tnt at 246tNt.com +0 -0
# BitKeeper file
/home/tnt/musicbox/kernel/linux-2.5-mpc52xx-pending/arch/ppc/syslib/mpc52xx_pci.h
#
# arch/ppc/syslib/mpc52xx_pci.c
# 2005/03/11 19:57:56+01:00 tnt at 246tNt.com +235 -0
# ppc32: Add PCI bus support for Freescale MPC52xx
#
# arch/ppc/syslib/Makefile
# 2005/03/11 19:57:56+01:00 tnt at 246tNt.com +3 -0
# ppc32: Add PCI bus support for Freescale MPC52xx
#
# arch/ppc/platforms/lite5200.c
# 2005/03/11 19:57:56+01:00 tnt at 246tNt.com +33 -3
# ppc32: Add PCI bus support for Freescale MPC52xx
#
# arch/ppc/Kconfig
# 2005/03/11 19:57:56+01:00 tnt at 246tNt.com +1 -1
# ppc32: Add PCI bus support for Freescale MPC52xx
#
# arch/ppc/syslib/mpc52xx_pci.c
# 2005/03/11 19:57:56+01:00 tnt at 246tNt.com +0 -0
# BitKeeper file
/home/tnt/musicbox/kernel/linux-2.5-mpc52xx-pending/arch/ppc/syslib/mpc52xx_pci.c
#
diff -Nru a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig 2005-03-11 20:41:56 +01:00
+++ b/arch/ppc/Kconfig 2005-03-11 20:41:56 +01:00
@@ -1097,7 +1097,7 @@
bool
config PCI
- bool "PCI support" if 40x || CPM2 || 83xx || 85xx
+ bool "PCI support" if 40x || CPM2 || 83xx || 85xx || PPC_MPC52xx
default y if !40x && !CPM2 && !8xx && !APUS && !83xx && !85xx
default PCI_PERMEDIA if !4xx && !CPM2 && !8xx && APUS
default PCI_QSPAN if !4xx && !CPM2 && 8xx
diff -Nru a/arch/ppc/platforms/lite5200.c b/arch/ppc/platforms/lite5200.c
--- a/arch/ppc/platforms/lite5200.c 2005-03-11 20:41:56 +01:00
+++ b/arch/ppc/platforms/lite5200.c 2005-03-11 20:41:56 +01:00
@@ -35,6 +35,8 @@
#include
#include
+#include
+
extern int powersave_nap;
fdef CONFIG_PCI
+static int
+lite5200_map_irq(struct pci_dev *dev, unsigned char idsel,
+ unsigned char pin) {
+ return (pin == 1) && (idsel==24) ? MPC52xx_IRQ0 : -1;
+}
+#endif
+
static void __init
lite5200_setup_cpu(void)
{
+ struct mpc52xx_xlb __iomem *xlb;
struct mpc52xx_intr __iomem *intr;
u32 intr_ctrl;
/* Map zones */
+ xlb = ioremap(MPC52xx_XLB,sizeof(struct mpc52xx_xlb));
intr = ioremap(MPC52xx_INTR,sizeof(struct mpc52xx_intr));
- if (!intr) {
- printk("lite5200.c: Error while mapping INTR during
lite5200_setup_cpu\n");
+ if (!xlb || !intr) {
+ printk("lite5200.c: Error while mapping XLB/INTR during
lite5200_setup_cpu\n");
goto unmap_regs;
}
+ /* Configure the XLB Arbiter */
+ out_be32(&xlb->master_pri_enable, 0xff);
+ out_be32(&xlb->master_priority, 0x);
+
+ /* Enable ram snooping for 1GB window */
+ out_be32(&xlb->config, in_be32(&xlb->config) |
MPC52xx_XLB_CFG_SNOOP);
+ out_be32(&xlb->snoop_window, MPC52xx_PCI_TARGET_MEM | 0x1d);
+
/* IRQ[0-3] setup : IRQ0 - Level Active Low */
/* IRQ[1-3] - Level Active High */
intr_ctrl = in_be32(&intr->ctrl);
@@ -103,6 +123,7 @@
/* Unmap reg zone */
unmap_regs:
+ if (xlb) iounmap(xlb);
if (intr) iounmap(intr);
}
@@ -114,6 +135,11 @@
/* CPU & Port mux setup */
lite5200_setup_cpu();
+
+#ifdef CONFIG_PCI
+ /* PCI Bridge setup */
+ mpc52xx_find_bridges();
+#endif
}
void __init
@@ -152,7 +178,7 @@
/* BAT setup */
mpc52xx_set_bat();
- /* No ISA bus AFAIK */
+ /* No ISA bus by default */
isa_io_base = 0;
isa_mem_base= 0;
@@ -165,6 +191,10 @@
ppc_md.show_percpuinfo = NULL;
ppc_md.init_IRQ = mpc52xx_init_irq;
ppc_md.get_irq = mpc52xx_get_irq;
+
+#ifdef CONFIG_PCI
+ ppc_md.pci_map_irq = lite5200_map_irq;
+#endif
ppc_md.find_end_of_memory = mpc52xx_find_end_of_memory;
ppc_md.setup_io_mappings = mpc52xx_map_io;
diff -Nru a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/a
[PATCH 1/2] MPC52xx updates : sparse clean-ups
Kumar Gala wrote:
>>
>>
>> diff -Nru a/arch/ppc/syslib/mpc52xx_pic.c
>> b/arch/ppc/syslib/mpc52xx_pic.c
>> --- a/arch/ppc/syslib/mpc52xx_pic.c 2005-03-11 20:41:36 +01:00
>> +++ b/arch/ppc/syslib/mpc52xx_pic.c 2005-03-11 20:41:36 +01:00
>> @@ -33,8 +33,8 @@
>> #include
>>
>>
>>
>> -static struct mpc52xx_intr *intr;
>> -static struct mpc52xx_sdma *sdma;
>> +static struct mpc52xx_intr __iomem *intr;
>> +static struct mpc52xx_sdma __iomem *sdma;
>>
>> static void
>> mpc52xx_ic_disable(unsigned int irq)
>> @@ -173,7 +173,7 @@
>> mpc52xx_ic_disable, /* disable(irq) */
>> mpc52xx_ic_disable_and_ack, /* disable_and_ack(irq) */
>> mpc52xx_ic_end, /* end(irq) */
>> - 0 /* set_affinity(irq, cpumask)
>> SMP. */
>> + NULL/* set_affinity(irq, cpumask)
>> SMP. */
>> };
>
>
> It looks like others have moved to a C99 initialization style for
> hw_interrupt_type, see syslib/ipic.c for an example.
>
Indeed. Here's a third patch ;)
It has been added to the bk tree as well.
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/11 21:37:08+01:00 tnt at 246tNt.com
# ppc32: Change to a C99 initialization style for hw_interrupt_type
# in MPC52xx interrupt controller
#
# arch/ppc/syslib/mpc52xx_pic.c
# 2005/03/11 21:36:54+01:00 tnt at 246tNt.com +5 -8
# ppc32: Change to a C99 initialization style for hw_interrupt_type
# in MPC52xx interrupt controller
#
diff -Nru a/arch/ppc/syslib/mpc52xx_pic.c b/arch/ppc/syslib/mpc52xx_pic.c
--- a/arch/ppc/syslib/mpc52xx_pic.c 2005-03-11 21:45:50 +01:00
+++ b/arch/ppc/syslib/mpc52xx_pic.c 2005-03-11 21:45:50 +01:00
@@ -166,14 +166,11 @@
}
static struct hw_interrupt_type mpc52xx_ic = {
- "MPC52xx",
- NULL, /* startup(irq) */
- NULL, /* shutdown(irq) */
- mpc52xx_ic_enable, /* enable(irq) */
- mpc52xx_ic_disable, /* disable(irq) */
- mpc52xx_ic_disable_and_ack, /* disable_and_ack(irq) */
- mpc52xx_ic_end, /* end(irq) */
- NULL/* set_affinity(irq, cpumask)
SMP. */
+ .typename = "MPC52xx",
+ .enable = mpc52xx_ic_enable,
+ .disable= mpc52xx_ic_disable,
+ .ack= mpc52xx_ic_disable_and_ack,
+ .end= mpc52xx_ic_end,
};
void __init
[PATCH 2/2] MPC52xx updates : PCI Support
Dale Farnsworth wrote:
>The first hunk of arch/ppc/platforms/lite5200.c looks corrupted.
>See the line beginning "fdef CONFIG_PCI".
>
>-Dale
>
>
>
Damn, you're right and even the first patch is screwed, half of it is
missing.
Discard theses, I'll put them on-line somewhere and post the urls.
Sylvain
>On Fri, Mar 11, 2005 at 08:08:26PM +, Sylvain Munaut wrote:
>
>
>>And here's the second patch :
>>
>>
>
>[ deleted lines ]
>
>
>
>>diff -Nru a/arch/ppc/platforms/lite5200.c b/arch/ppc/platforms/lite5200.c
>>--- a/arch/ppc/platforms/lite5200.c 2005-03-11 20:41:56 +01:00
>>+++ b/arch/ppc/platforms/lite5200.c 2005-03-11 20:41:56 +01:00
>>@@ -35,6 +35,8 @@
>>#include
>>#include
>>
>>+#include
>>+
>>
>>extern int powersave_nap;
>>
>>fdef CONFIG_PCI
>>+static int
>>+lite5200_map_irq(struct pci_dev *dev, unsigned char idsel,
>>+ unsigned char pin) {
>>+ return (pin == 1) && (idsel==24) ? MPC52xx_IRQ0 : -1;
>>+}
>>+#endif
>>
>>
>
>[ more deleted lines ]
>___
>Linuxppc-embedded mailing list
>Linuxppc-embedded at ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
[PATCH] MPC52xx updates (2nd take) : cleanups + PCI
Ok, second try. I've included the remarks alread done (the C99 init and the missing space for " MPC52xx ") They can be found included (correctly this time I hope), and on-line as well Bitkeeper tree : bk://tnt.bkbits.net/linux-2.5-mpc52xx-pending Patch download : http://www.246tnt.com/mpc52xx/linux-2.5-mpc52xx-pending-20050311-sparsecleanup.diff http://www.246tnt.com/mpc52xx/linux-2.5-mpc52xx-pending-20050311-pci.diff That'll be hopefully enough ... Sylvain -- next part -- A non-text attachment was scrubbed... Name: linux-2.5-mpc52xx-pending-20050311-pci.diff Type: text/x-patch Size: 16352 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050312/11b1682e/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: linux-2.5-mpc52xx-pending-20050311-sparsecleanup.diff Type: text/x-patch Size: 9865 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050312/11b1682e/attachment-0001.bin
[PATCH 0/6] [RFC] Change MPC52xx to platform bus / ppc_sys model
Hi all, This series of patch changes all the MPC52xx related code to use platform bus and ppc_sys instead of OCP. It's divided in several patches that represents "steps" in the conversion. However the intermediate states might not be functionnal. This is the first try, comments and suggestions are welcomed. Sylvain
[PATCH 1/6] ppc32: Remove unnecessary test in MPC52xx reset code
ppc32: Remove unnecessary test in MPC52xx reset code
That test is part of an old version of the code and
erroneously made it to mainstream.
Signed-off-by: Sylvain Munaut
---
diff -Nru a/arch/ppc/syslib/mpc52xx_setup.c b/arch/ppc/syslib/mpc52xx_setup.c
--- a/arch/ppc/syslib/mpc52xx_setup.c 2005-03-21 20:09:24 +01:00
+++ b/arch/ppc/syslib/mpc52xx_setup.c 2005-03-21 20:09:24 +01:00
@@ -46,11 +46,8 @@
/* Turn on the watchdog and wait for it to expire. It effectively
does a reset */
- if (gpt0 != NULL) {
- out_be32(&gpt0->count, 0x00ff);
- out_be32(&gpt0->mode, 0x9004);
- } else
- printk(KERN_ERR "mpc52xx_restart: Unable to ioremap GPT0
registers, -> looping ...");
+ out_be32(&gpt0->count, 0x00ff);
+ out_be32(&gpt0->mode, 0x9004);
while (1);
}
[PATCH 2/6] ppc32: Remove the OCP system from the Freescale MPC52xx support
ppc32: Remove the OCP system from the Freescale MPC52xx support
We remove all usage of the OCP system as preparation to switch
to the platform bus model / ppc_sys model.
This is only for 'generic' support, drivers are adapted separatly,
afterwards.
Signed-off-by: Sylvain Munaut
---
diff -Nru a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig 2005-03-21 20:09:47 +01:00
+++ b/arch/ppc/Kconfig 2005-03-21 20:09:47 +01:00
@@ -822,7 +822,7 @@
config FSL_OCP
bool
- depends on MPC10X_BRIDGE || PPC_MPC52xx
+ depends on MPC10X_BRIDGE
default y
config MPC10X_OPENPIC
diff -Nru a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile
--- a/arch/ppc/platforms/Makefile 2005-03-21 20:09:47 +01:00
+++ b/arch/ppc/platforms/Makefile 2005-03-21 20:09:47 +01:00
@@ -45,7 +45,7 @@
obj-$(CONFIG_SANDPOINT)+= sandpoint.o
obj-$(CONFIG_SBC82xx) += sbc82xx.o
obj-$(CONFIG_SPRUCE) += spruce.o
-obj-$(CONFIG_LITE5200) += lite5200.o mpc5200.o
+obj-$(CONFIG_LITE5200) += lite5200.o
ifeq ($(CONFIG_SMP),y)
obj-$(CONFIG_PPC_PMAC) += pmac_smp.o
diff -Nru a/arch/ppc/platforms/lite5200.c b/arch/ppc/platforms/lite5200.c
--- a/arch/ppc/platforms/lite5200.c 2005-03-21 20:09:47 +01:00
+++ b/arch/ppc/platforms/lite5200.c 2005-03-21 20:09:47 +01:00
@@ -13,7 +13,7 @@
* Dale Farnsworth and
* Wolfgang Denk
*
- * Copyright 2004 Sylvain Munaut
+ * Copyright 2004-2005 Sylvain Munaut
* Copyright 2003 Motorola Inc.
* Copyright 2003 MontaVista Software Inc.
* Copyright 2003 DENX Software Engineering (wd at denx.de)
@@ -29,10 +29,10 @@
#include
#include
#include
+#include
#include
#include
-#include
#include
#include
@@ -46,31 +46,6 @@
/* */
-/* OCP device definition*/
-/* For board/shared resources like PSCs */
-/* */
-/* Be sure not to load conficting devices : e.g. loading the UART drivers for
- * PSC1 and then also loading a AC97 for this same PSC.
- * For details about how to create an entry, look in the doc of the concerned
- * driver ( eg drivers/serial/mpc52xx_uart.c for the PSC in uart mode )
- */
-
-static struct ocp_def board_ocp[] = {
- {
- .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_PSC_UART,
- .index = 0,
- .paddr = MPC52xx_PSC1,
- .irq= MPC52xx_PSC1_IRQ,
- .pm = OCP_CPM_NA,
- },
- { /* Terminating entry */
- .vendor = OCP_VENDOR_INVALID
- }
-};
-
-
-/* */
/* Platform specific code */
/* */
@@ -131,9 +106,6 @@
static void __init
lite5200_setup_arch(void)
{
- /* Add board OCP definitions */
- mpc52xx_add_board_devices(board_ocp);
-
/* CPU & Port mux setup */
lite5200_setup_cpu();
diff -Nru a/arch/ppc/platforms/mpc5200.c b/arch/ppc/platforms/mpc5200.c
--- a/arch/ppc/platforms/mpc5200.c 2005-03-21 20:09:47 +01:00
+++ /dev/null Wed Dec 31 16:00:00 196900
@@ -1,53 +0,0 @@
-/*
- * arch/ppc/platforms/mpc5200.c
- *
- * OCP Definitions for the boards based on MPC5200 processor. Contains
- * definitions for every common peripherals. (Mostly all but PSCs)
- *
- * Maintainer : Sylvain Munaut
- *
- * Copyright 2004 Sylvain Munaut
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
- */
-
-#include
-#include
-
-
-static struct ocp_fs_i2c_data mpc5200_i2c_def = {
-.flags = FS_I2C_CLOCK_5200,
-};
-
-
-/* Here is the core_ocp struct.
- * With all the devices common to all board. Even if port multiplexing is
- * not setup for them (if the user don't want them, just don't select the
- * config option). The potentially conflicting devices (like PSCs) goes in
- * board specific file.
- */
-struct ocp_def core_ocp[] = {
- {
- .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_IIC,
- .index = 0,
- .paddr = MPC52xx_I2C1,
- .irq= OCP_IRQ_NA, /* MPC52xx_IRQ_I2C1 - Buggy */
- .pm = OCP_CPM_NA,
- .additions = &mpc5200_i2c_def,
- },
- {
- .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_IIC,
- .inde
[PATCH 3/6] ppc32: Change constants style in Freescale MPC52xx related code
ppc32: Change constants style in Freescale MPC52xx related code
This patch changes the way the constants used for register block
address are defined/used. This is a preparation for the use of
the platform bus / ppc_sys model.
Signed-off-by: Sylvain Munaut
---
diff -Nru a/arch/ppc/boot/simple/mpc52xx_tty.c
b/arch/ppc/boot/simple/mpc52xx_tty.c
--- a/arch/ppc/boot/simple/mpc52xx_tty.c2005-03-21 20:10:10 +01:00
+++ b/arch/ppc/boot/simple/mpc52xx_tty.c2005-03-21 20:10:10 +01:00
@@ -20,32 +20,31 @@
#include
#include
-#if MPC52xx_PF_CONSOLE_PORT == 0
-#define MPC52xx_CONSOLEMPC52xx_PSC1
-#define MPC52xx_PSC_CONFIG_SHIFT 0
-#elif MPC52xx_PF_CONSOLE_PORT == 1
-#define MPC52xx_CONSOLEMPC52xx_PSC2
-#define MPC52xx_PSC_CONFIG_SHIFT 4
-#elif MPC52xx_PF_CONSOLE_PORT == 2
-#define MPC52xx_CONSOLEMPC52xx_PSC3
-#define MPC52xx_PSC_CONFIG_SHIFT 8
+
+#ifdef MPC52xx_PF_CONSOLE_PORT
+#define MPC52xx_CONSOLE MPC52xx_PSCx_OFFSET(MPC52xx_PF_CONSOLE_PORT)
+#define MPC52xx_PSC_CONFIG_SHIFT ((MPC52xx_PF_CONSOLE_PORT-1)<<2)
#else
#error "MPC52xx_PF_CONSOLE_PORT not defined"
#endif
static struct mpc52xx_psc __iomem *psc =
- (struct mpc52xx_psc __iomem *) MPC52xx_CONSOLE;
+ (struct mpc52xx_psc __iomem *) MPC52xx_PA(MPC52xx_CONSOLE);
/* The decrementer counts at the system bus clock frequency
* divided by four. The most accurate time base is connected to the
- * rtc. We read the decrementer change during one rtc tick (one second)
- * and multiply by 4 to get the system bus clock frequency.
+ * rtc. We read the decrementer change during one rtc tick
+ * and multiply by 4 to get the system bus clock frequency. Since a
+ * rtc tick is one seconds, and that's pretty long, we change the rtc
+ * dividers temporarly to set them 64x faster ;)
*/
static int
mpc52xx_ipbfreq(void)
{
- struct mpc52xx_rtc __iomem *rtc = (struct mpc52xx_rtc __iomem
*)MPC52xx_RTC;
- struct mpc52xx_cdm __iomem *cdm = (struct mpc52xx_cdm __iomem
*)MPC52xx_CDM;
+ struct mpc52xx_rtc __iomem *rtc =
+ (struct mpc52xx_rtc __iomem *) MPC52xx_PA(MPC52xx_RTC_OFFSET);
+ struct mpc52xx_cdm __iomem *cdm =
+ (struct mpc52xx_cdm __iomem *) MPC52xx_PA(MPC52xx_CDM_OFFSET);
int current_time, previous_time;
int tbl_start, tbl_end;
int xlbfreq, ipbfreq;
@@ -68,7 +67,8 @@
unsigned long
serial_init(int ignored, void *ignored2)
{
- struct mpc52xx_gpio __iomem *gpio = (struct mpc52xx_gpio __iomem
*)MPC52xx_GPIO;
+ struct mpc52xx_gpio __iomem *gpio =
+ (struct mpc52xx_gpio __iomem *) MPC52xx_PA(MPC52xx_GPIO_OFFSET);
int divisor;
int mode1;
int mode2;
diff -Nru a/arch/ppc/platforms/lite5200.c b/arch/ppc/platforms/lite5200.c
--- a/arch/ppc/platforms/lite5200.c 2005-03-21 20:10:10 +01:00
+++ b/arch/ppc/platforms/lite5200.c 2005-03-21 20:10:10 +01:00
@@ -73,8 +73,8 @@
u32 intr_ctrl;
/* Map zones */
- xlb = ioremap(MPC52xx_XLB,sizeof(struct mpc52xx_xlb));
- intr = ioremap(MPC52xx_INTR,sizeof(struct mpc52xx_intr));
+ xlb = ioremap(MPC52xx_PA(MPC52xx_XLB_OFFSET), MPC52xx_XLB_SIZE);
+ intr = ioremap(MPC52xx_PA(MPC52xx_INTR_OFFSET), MPC52xx_INTR_SIZE);
if (!xlb || !intr) {
printk("lite5200.c: Error while mapping XLB/INTR during "
diff -Nru a/arch/ppc/platforms/lite5200.h b/arch/ppc/platforms/lite5200.h
--- a/arch/ppc/platforms/lite5200.h 2005-03-21 20:10:10 +01:00
+++ b/arch/ppc/platforms/lite5200.h 2005-03-21 20:10:10 +01:00
@@ -17,7 +17,7 @@
#define __PLATFORMS_LITE5200_H__
/* Serial port used for low-level debug */
-#define MPC52xx_PF_CONSOLE_PORT 0 /* PSC1 */
+#define MPC52xx_PF_CONSOLE_PORT 1 /* PSC1 */
#endif /* __PLATFORMS_LITE5200_H__ */
diff -Nru a/arch/ppc/syslib/mpc52xx_pci.c b/arch/ppc/syslib/mpc52xx_pci.c
--- a/arch/ppc/syslib/mpc52xx_pci.c 2005-03-21 20:10:10 +01:00
+++ b/arch/ppc/syslib/mpc52xx_pci.c 2005-03-21 20:10:10 +01:00
@@ -183,7 +183,7 @@
pci_assign_all_busses = 1;
- pci_regs = ioremap(MPC52xx_PCI, sizeof(struct mpc52xx_pci));
+ pci_regs = ioremap(MPC52xx_PA(MPC52xx_PCI_OFFSET), MPC52xx_PCI_SIZE);
if (!pci_regs)
return;
diff -Nru a/arch/ppc/syslib/mpc52xx_pic.c b/arch/ppc/syslib/mpc52xx_pic.c
--- a/arch/ppc/syslib/mpc52xx_pic.c 2005-03-21 20:10:10 +01:00
+++ b/arch/ppc/syslib/mpc52xx_pic.c 2005-03-21 20:10:10 +01:00
@@ -180,8 +180,8 @@
u32 intr_ctrl;
/* Remap the necessary zones */
- intr = ioremap(MPC52xx_INTR, sizeof(struct mpc52xx_intr));
- sdma = ioremap(MPC52xx_SDMA, sizeof(struct mpc52xx_sdma));
+ intr = ioremap(MPC52xx_PA(MPC52xx_INTR_OFFSET), MPC52xx_INTR_SIZE);
+ sdma = ioremap(MPC52xx_PA(MPC52xx_SDMA_OFFSET), MPC52xx_SDMA_SIZE);
if ((intr==NULL) || (sdma==NULL
[PATCH 4/6] ppc32: Add platform bus / ppc_sys model to Freescale MPC52xx
ppc32: Add platform bus / ppc_sys model to Freescale MPC52xx
This patch makes all platform based around the Freescale MPC52xx use
the platform bus and more precisly the ppc_sys model put in
place by Kumar Gala.
Signed-off-by: Sylvain Munaut
---
diff -Nru a/arch/ppc/platforms/lite5200.c b/arch/ppc/platforms/lite5200.c
--- a/arch/ppc/platforms/lite5200.c 2005-03-21 20:10:34 +01:00
+++ b/arch/ppc/platforms/lite5200.c 2005-03-21 20:10:34 +01:00
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
@@ -49,6 +50,17 @@
/* Platform specific code */
/* */
+/* Supported PSC function in "preference" order */
+struct mpc52xx_psc_func mpc52xx_psc_functions[] = {
+ { .id = 0,
+ .func = "uart",
+ },
+ { .id = -1, /* End entry */
+ .func = NULL,
+ }
+ };
+
+
static int
lite5200_show_cpuinfo(struct seq_file *m)
{
@@ -147,6 +159,9 @@
strcpy(cmd_line, (char *)(r6+KERNELBASE));
}
}
+
+ /* PPC Sys identification */
+ identify_ppc_sys_by_id(mfspr(SPRN_SVR));
/* BAT setup */
mpc52xx_set_bat();
diff -Nru a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile 2005-03-21 20:10:34 +01:00
+++ b/arch/ppc/syslib/Makefile 2005-03-21 20:10:34 +01:00
@@ -106,7 +106,8 @@
obj-$(CONFIG_PCI) += indirect_pci.o pci_auto.o
endif
obj-$(CONFIG_MPC8555_CDS) += todc_time.o
-obj-$(CONFIG_PPC_MPC52xx) += mpc52xx_setup.o mpc52xx_pic.o
+obj-$(CONFIG_PPC_MPC52xx) += mpc52xx_setup.o mpc52xx_pic.o \
+ mpc52xx_sys.o mpc52xx_devices.o
ppc_sys.o
ifeq ($(CONFIG_PPC_MPC52xx),y)
obj-$(CONFIG_PCI) += mpc52xx_pci.o
endif
diff -Nru a/arch/ppc/syslib/mpc52xx_devices.c
b/arch/ppc/syslib/mpc52xx_devices.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/syslib/mpc52xx_devices.c 2005-03-21 20:10:34 +01:00
@@ -0,0 +1,333 @@
+/*
+ * arch/ppc/syslib/mpc52xx_devices.c
+ *
+ * Freescale MPC52xx device descriptions
+ *
+ *
+ * Maintainer : Sylvain Munaut
+ *
+ * Copyright (C) 2005 Sylvain Munaut
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+
+
+static u64 mpc52xx_dma_mask = 0xULL;
+
+static struct fsl_i2c_platform_data mpc52xx_fsl_i2c_pdata = {
+ .device_flags = FSL_I2C_DEV_CLOCK_5200,
+};
+
+
+/* We use relative offsets for IORESOURCE_MEM to be independent from the
+ * MBAR location at compile time
+ */
+
+/* TODO Add the BestComm initiator channel to the device definitions,
+ possibly using IORESOURCE_DMA. But that's when BestComm is ready ... */
+
+struct platform_device ppc_sys_platform_devices[] = {
+ [MPC52xx_MSCAN1] = {
+ .name = "mpc52xx-mscan",
+ .id = 0,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC52xx_MSCAN1_OFFSET,
+ .end= MPC52xx_MSCAN1_OFFSET +
+ MPC52xx_MSCAN_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC52xx_MSCAN1_IRQ,
+ .end= MPC52xx_MSCAN1_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC52xx_MSCAN2] = {
+ .name = "mpc52xx-mscan",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = MPC52xx_MSCAN2_OFFSET,
+ .end= MPC52xx_MSCAN2_OFFSET +
+ MPC52xx_MSCAN_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC52xx_MSCAN2_IRQ,
+ .end= MPC52xx_MSCAN2_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC52xx_SPI] = {
+ .name = "mpc52xx-spi",
+ .id = -1,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .
[PATCH 5/6] serial: Update mpc52xx_uart.c to use platform bus
serial: Update mpc52xx_uart.c to use platform bus
All Freescale MPC52xx related code now use new constants and
the platform bus for it's driver. This patch makes this driver
make use of that.
Signed-off-by: Sylvain Munaut
---
diff -Nru a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
--- a/drivers/serial/mpc52xx_uart.c 2005-03-21 20:11:00 +01:00
+++ b/drivers/serial/mpc52xx_uart.c 2005-03-21 20:11:00 +01:00
@@ -18,7 +18,7 @@
* Some of the code has been inspired/copied from the 2.4 code written
* by Dale Farnsworth .
*
- * Copyright (C) 2004 Sylvain Munaut
+ * Copyright (C) 2004-2005 Sylvain Munaut
* Copyright (C) 2003 MontaVista, Software, Inc.
*
* This file is licensed under the terms of the GNU General Public License
@@ -26,33 +26,26 @@
* kind, whether express or implied.
*/
-/* OCP Usage :
+/* Platform device Usage :
*
- * This drivers uses the OCP model. To load the serial driver for one of the
- * PSCs, just add this to the core_ocp table :
+ * Since PSCs can have multiple function, the correct driver for each one
+ * is selected by calling mpc52xx_match_psc_function(...). The function
+ * handled by this driver is "uart".
*
- * {
- * .vendor = OCP_VENDOR_FREESCALE,
- * .function = OCP_FUNC_PSC_UART,
- * .index = 0,
- * .paddr = MPC52xx_PSC1,
- * .irq= MPC52xx_PSC1_IRQ,
- * .pm = OCP_CPM_NA,
- * },
- *
- * This is for PSC1, replace the paddr and irq according to the PSC you want to
- * use. The driver all necessary registers to place the PSC in uart mode
without
+ * The driver init all necessary registers to place the PSC in uart mode
without
* DCD. However, the pin multiplexing aren't changed and should be set either
* by the bootloader or in the platform init code.
- * The index field must be equal to the PSC index ( e.g. 0 for PSC1, 1 for
PSC2,
+ *
+ * The idx field must be equal to the PSC index ( e.g. 0 for PSC1, 1 for PSC2,
* and so on). So the PSC1 is mapped to /dev/ttyS0, PSC2 to /dev/ttyS1 and so
* on. But be warned, it's an ABSOLUTE REQUIREMENT ! This is needed mainly for
* the console code : without this 1:1 mapping, at early boot time, when we are
* parsing the kernel args console=ttyS?, we wouldn't know wich PSC it will be
- * mapped to because OCP stuff is not yet initialized.
+ * mapped to.
*/
#include
+#include
#include
#include
#include
@@ -61,7 +54,6 @@
#include
#include
-#include
#include
#include
@@ -191,6 +183,13 @@
mpc52xx_uart_startup(struct uart_port *port)
{
struct mpc52xx_psc __iomem *psc = PSC(port);
+ int ret;
+
+ /* Request IRQ */
+ ret = request_irq(port->irq, mpc52xx_uart_int,
+ SA_INTERRUPT | SA_SAMPLE_RANDOM, "mpc52xx_psc_uart", port);
+ if (ret)
+ return ret;
/* Reset/activate the port, clear and enable interrupts */
out_8(&psc->command,MPC52xx_PSC_RST_RX);
@@ -225,6 +224,9 @@
port->read_status_mask = 0;
out_be16(&psc->mpc52xx_psc_imr,port->read_status_mask);
+
+ /* Release interrupt */
+ free_irq(port->irq, port);
}
static void
@@ -326,15 +328,21 @@
iounmap(port->membase);
port->membase = NULL;
}
+
+ release_mem_region(port->mapbase, MPC52xx_PSC_SIZE);
}
static int
mpc52xx_uart_request_port(struct uart_port *port)
{
if (port->flags & UPF_IOREMAP) /* Need to remap ? */
- port->membase = ioremap(port->mapbase, sizeof(struct
mpc52xx_psc));
-
- return port->membase != NULL ? 0 : -EBUSY;
+ port->membase = ioremap(port->mapbase, MPC52xx_PSC_SIZE);
+
+ if (!port->membase)
+ return -EINVAL;
+
+ return request_mem_region(port->mapbase, MPC52xx_PSC_SIZE,
+ "mpc52xx_psc_uart") != NULL ? 0 : -EBUSY;
}
static void
@@ -354,7 +362,7 @@
if ( (ser->irq != port->irq) ||
(ser->io_type != SERIAL_IO_MEM) ||
(ser->baud_base != port->uartclk) ||
-// FIXME Should check addresses/irq as well ?
+(ser->iomem_base != (void*)port->mapbase) ||
(ser->hub6 != 0 ) )
return -EINVAL;
@@ -630,7 +638,7 @@
{
struct uart_port *port = &mpc52xx_uart_ports[co->index];
- int baud = 9600;
+ int baud = CONFIG_SERIAL_MPC52xx_CONSOLE_BAUD;
int bits = 8;
int parity = 'n';
int flow = 'n';
@@ -643,14 +651,12 @@
spin_lock_init(&port->lock);
port->uartclk = __res.bi_ipbfreq / 2; /* Look at CTLR doc */
port->ops = &mpc52xx_uart_ops;
- port->mapbase = MPC52xx_PSCx(co->index);
+ port->mapbase = MPC52xx_
[PATCH 6/6] ppc32: Adds necessary cpu init to use USB on LITE5200 Platform
ppc32: Adds necessary cpu init to use USB on LITE5200 Platform
To use external peripheral on MPC5200, some clocking registers
and port-muxing must be done. Since this is platform specific,
it's placed the platform support file. This particular patch
is for USB support on the LITE5200.
Signed-off-by: Sylvain Munaut
---
diff -Nru a/arch/ppc/platforms/lite5200.c b/arch/ppc/platforms/lite5200.c
--- a/arch/ppc/platforms/lite5200.c 2005-03-21 20:11:23 +01:00
+++ b/arch/ppc/platforms/lite5200.c 2005-03-21 20:11:23 +01:00
@@ -79,21 +79,47 @@
static void __init
lite5200_setup_cpu(void)
{
+ struct mpc52xx_cdm __iomem *cdm;
+ struct mpc52xx_gpio __iomem *gpio;
struct mpc52xx_intr __iomem *intr;
struct mpc52xx_xlb __iomem *xlb;
+ u32 port_config;
u32 intr_ctrl;
/* Map zones */
+ cdm = ioremap(MPC52xx_PA(MPC52xx_CDM_OFFSET), MPC52xx_CDM_SIZE);
+ gpio = ioremap(MPC52xx_PA(MPC52xx_GPIO_OFFSET), MPC52xx_GPIO_SIZE);
xlb = ioremap(MPC52xx_PA(MPC52xx_XLB_OFFSET), MPC52xx_XLB_SIZE);
intr = ioremap(MPC52xx_PA(MPC52xx_INTR_OFFSET), MPC52xx_INTR_SIZE);
- if (!xlb || !intr) {
- printk("lite5200.c: Error while mapping XLB/INTR during "
+ if (!cdm || !gpio || !xlb || !intr) {
+ printk("lite5200.c: Error while mapping CDM/GPIO/XLB/INTR
during"
"lite5200_setup_cpu\n");
goto unmap_regs;
}
+ /* Use internal 48 Mhz */
+ out_8(&cdm->ext_48mhz_en, 0x00);
+ out_8(&cdm->fd_enable, 0x01);
+ if (in_be32(&cdm->rstcfg) & 0x40) /* Assumes 33Mhz clock */
+ out_be16(&cdm->fd_counters, 0x0001);
+ else
+ out_be16(&cdm->fd_counters, 0x);
+
+ /* Get port mux config */
+ port_config = in_be32(&gpio->port_config);
+
+ /* 48Mhz internal, pin is GPIO */
+ port_config &= ~0x0080;
+
+ /* USB port */
+ port_config &= ~0x7000; /* Differential mode - USB1 only */
+ port_config |= 0x1000;
+
+ /* Commit port config */
+ out_be32(&gpio->port_config, port_config);
+
/* Configure the XLB Arbiter */
out_be32(&xlb->master_pri_enable, 0xff);
out_be32(&xlb->master_priority, 0x);
@@ -111,6 +137,8 @@
/* Unmap reg zone */
unmap_regs:
+ if (cdm) iounmap(cdm);
+ if (gpio) iounmap(gpio);
if (xlb) iounmap(xlb);
if (intr) iounmap(intr);
}
@@ -171,7 +199,11 @@
isa_mem_base= 0;
/* Powersave */
- powersave_nap = 1; /* We allow this platform to NAP */
+ /* This is provided as an example on how to do it. But you
+ need to be aware that NAP disable bus snoop and that may
+ be required for some devices to work properly, like USB ... */
+ /* powersave_nap = 1; */
+
/* Setup the ppc_md struct */
ppc_md.setup_arch = lite5200_setup_arch;
[PATCH 0/6] [RFC] Change MPC52xx to platform bus / ppc_sys model
Hi Kumar, Kumar Gala wrote: > Took a quick glance at the patches and they look good. Do you have a bk > tree available with all these changes in them? > > I think a might have a few minor comments, but might be easier to see > the bk tree. Sure, bk://tnt.bkbits.net/linux-2.5-mpc52xx-pending The only difference between that tree and the patch is a few trailing white space that are in BK but not in the patch. Note that now, I should also add CONFIG_PPC_MPC52xx to the change of /proc/cpuinfo. What about a CONFIG_PPC_SYS that would include ppc_sys.o in the kernel and activate the /proc/cpuinfo chipset line ? Sylvain
[RFC] MPC5200 PCI problem
Andrey Volkov wrote: > Hi Sylvain, > > After last synchronization with your bk, > PCI subsys stop calling drv->probe of driver for > my external PCI board (UBoot meanwhile properly displayed and init this > board). May be I do something wrong? Or PCI is in disjoint state now? > With which tree exactly ? Try adding some delays in the pci configuration zone access routines in mpc52xx_pci.c I remember someone needed those but still don't know why, the manual don't say anything about that. What does /proc/pci shows ? Sylvain
[RFC] MPC5200 Kernel/UBoot PCI problem
Hi Andrey, Andrey Volkov wrote: >>> Try adding some delays in the pci configuration zone access routines >>> in mpc52xx_pci.c I remember someone needed those but still don't >>> know why, the manual don't say anything about that. >> >> >> Board started, after I add udelay(7) in read/write config. Really >> strange. > > > Sylvain, answer was in PCI2.2 specification, not in manual. > Indeed good catch ! Never imagined the delay was so long. It should be possible to use the sched_clock(void) to know if we're booting since long enough, because just waiting 1 full second is ... long. Sylvain
[PATCH 0/6] Change MPC52xx to platform bus / ppc_sys model
Hi Andrew, This series of patch changes all the MPC52xx related code to use platform bus and ppc_sys instead of OCP. It's divided in several patches that represents "steps" in the conversion. However the intermediate states might not be functionnal. Theses are against a bk clone of this morning since they depend on some patches that are on bk but not yet in 2.6.12-rc1. I just tested and they also apply/run fine with -mm3. Regards, Sylvain
[PATCH 1/6] ppc32: Remove unnecessary test in MPC52xx reset code
ppc32: Remove unnecessary test in MPC52xx reset code
That test is part of an old version of the code and
erroneously made it to mainstream.
Signed-off-by: Sylvain Munaut
Signed-off-by: Kumar Gala
---
diff -Nru a/arch/ppc/syslib/mpc52xx_setup.c b/arch/ppc/syslib/mpc52xx_setup.c
--- a/arch/ppc/syslib/mpc52xx_setup.c 2005-03-26 19:55:53 +01:00
+++ b/arch/ppc/syslib/mpc52xx_setup.c 2005-03-26 19:55:53 +01:00
@@ -46,11 +46,8 @@
/* Turn on the watchdog and wait for it to expire. It effectively
does a reset */
- if (gpt0 != NULL) {
- out_be32(&gpt0->count, 0x00ff);
- out_be32(&gpt0->mode, 0x9004);
- } else
- printk(KERN_ERR "mpc52xx_restart: Unable to ioremap GPT0
registers, -> looping ...");
+ out_be32(&gpt0->count, 0x00ff);
+ out_be32(&gpt0->mode, 0x9004);
while (1);
}
[PATCH 2/6] ppc32: Remove the OCP system from the Freescale MPC52xx support
ppc32: Remove the OCP system from the Freescale MPC52xx support
We remove all usage of the OCP system as preparation to switch
to the platform bus model / ppc_sys model.
This is only for 'generic' support, drivers are adapted separatly,
afterwards.
Signed-off-by: Sylvain Munaut
Signed-off-by: Kumar Gala
---
diff -Nru a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig 2005-03-26 19:56:03 +01:00
+++ b/arch/ppc/Kconfig 2005-03-26 19:56:03 +01:00
@@ -822,7 +822,7 @@
config FSL_OCP
bool
- depends on MPC10X_BRIDGE || PPC_MPC52xx
+ depends on MPC10X_BRIDGE
default y
config MPC10X_OPENPIC
diff -Nru a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile
--- a/arch/ppc/platforms/Makefile 2005-03-26 19:56:03 +01:00
+++ b/arch/ppc/platforms/Makefile 2005-03-26 19:56:03 +01:00
@@ -45,7 +45,7 @@
obj-$(CONFIG_SANDPOINT)+= sandpoint.o
obj-$(CONFIG_SBC82xx) += sbc82xx.o
obj-$(CONFIG_SPRUCE) += spruce.o
-obj-$(CONFIG_LITE5200) += lite5200.o mpc5200.o
+obj-$(CONFIG_LITE5200) += lite5200.o
ifeq ($(CONFIG_SMP),y)
obj-$(CONFIG_PPC_PMAC) += pmac_smp.o
diff -Nru a/arch/ppc/platforms/lite5200.c b/arch/ppc/platforms/lite5200.c
--- a/arch/ppc/platforms/lite5200.c 2005-03-26 19:56:03 +01:00
+++ b/arch/ppc/platforms/lite5200.c 2005-03-26 19:56:03 +01:00
@@ -13,7 +13,7 @@
* Dale Farnsworth and
* Wolfgang Denk
*
- * Copyright 2004 Sylvain Munaut
+ * Copyright 2004-2005 Sylvain Munaut
* Copyright 2003 Motorola Inc.
* Copyright 2003 MontaVista Software Inc.
* Copyright 2003 DENX Software Engineering (wd at denx.de)
@@ -29,10 +29,10 @@
#include
#include
#include
+#include
#include
#include
-#include
#include
#include
@@ -46,31 +46,6 @@
/* */
-/* OCP device definition*/
-/* For board/shared resources like PSCs */
-/* */
-/* Be sure not to load conficting devices : e.g. loading the UART drivers for
- * PSC1 and then also loading a AC97 for this same PSC.
- * For details about how to create an entry, look in the doc of the concerned
- * driver ( eg drivers/serial/mpc52xx_uart.c for the PSC in uart mode )
- */
-
-static struct ocp_def board_ocp[] = {
- {
- .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_PSC_UART,
- .index = 0,
- .paddr = MPC52xx_PSC1,
- .irq= MPC52xx_PSC1_IRQ,
- .pm = OCP_CPM_NA,
- },
- { /* Terminating entry */
- .vendor = OCP_VENDOR_INVALID
- }
-};
-
-
-/* */
/* Platform specific code */
/* */
@@ -131,9 +106,6 @@
static void __init
lite5200_setup_arch(void)
{
- /* Add board OCP definitions */
- mpc52xx_add_board_devices(board_ocp);
-
/* CPU & Port mux setup */
lite5200_setup_cpu();
diff -Nru a/arch/ppc/syslib/mpc52xx_setup.c b/arch/ppc/syslib/mpc52xx_setup.c
--- a/arch/ppc/syslib/mpc52xx_setup.c 2005-03-26 19:56:03 +01:00
+++ b/arch/ppc/syslib/mpc52xx_setup.c 2005-03-26 19:56:03 +01:00
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
@@ -218,12 +217,3 @@
tb_ticks_per_jiffy = xlbfreq / HZ / divisor;
tb_to_us = mulhwu_scale_factor(xlbfreq / divisor, 100);
}
-
-
-void __init
-mpc52xx_add_board_devices(struct ocp_def board_ocp[]) {
- while (board_ocp->vendor != OCP_VENDOR_INVALID)
- if(ocp_add_one_device(board_ocp++))
- printk("mpc5200-ocp: Failed to add board device !\n");
-}
-
diff -Nru a/include/asm-ppc/mpc52xx.h b/include/asm-ppc/mpc52xx.h
--- a/include/asm-ppc/mpc52xx.h 2005-03-26 19:56:03 +01:00
+++ b/include/asm-ppc/mpc52xx.h 2005-03-26 19:56:03 +01:00
@@ -26,7 +26,6 @@
#include
struct pt_regs;
-struct ocp_def;
#endif /* __ASSEMBLY__ */
@@ -391,7 +390,6 @@
extern void mpc52xx_power_off(void);
extern void mpc52xx_progress(char *s, unsigned short hex);
extern void mpc52xx_calibrate_decr(void);
-extern void mpc52xx_add_board_devices(struct ocp_def board_ocp[]);
extern void mpc52xx_find_bridges(void);
[PATCH 3/6] ppc32: Change constants style in Freescale MPC52xx related code
ppc32: Change constants style in Freescale MPC52xx related code
This patch changes the way the constants used for register block
address are defined/used. This is a preparation for the use of
the platform bus / ppc_sys model.
Signed-off-by: Sylvain Munaut
Signed-off-by: Kumar Gala
---
diff -Nru a/arch/ppc/boot/simple/mpc52xx_tty.c
b/arch/ppc/boot/simple/mpc52xx_tty.c
--- a/arch/ppc/boot/simple/mpc52xx_tty.c2005-03-26 19:56:12 +01:00
+++ b/arch/ppc/boot/simple/mpc52xx_tty.c2005-03-26 19:56:12 +01:00
@@ -20,32 +20,31 @@
#include
#include
-#if MPC52xx_PF_CONSOLE_PORT == 0
-#define MPC52xx_CONSOLEMPC52xx_PSC1
-#define MPC52xx_PSC_CONFIG_SHIFT 0
-#elif MPC52xx_PF_CONSOLE_PORT == 1
-#define MPC52xx_CONSOLEMPC52xx_PSC2
-#define MPC52xx_PSC_CONFIG_SHIFT 4
-#elif MPC52xx_PF_CONSOLE_PORT == 2
-#define MPC52xx_CONSOLEMPC52xx_PSC3
-#define MPC52xx_PSC_CONFIG_SHIFT 8
+
+#ifdef MPC52xx_PF_CONSOLE_PORT
+#define MPC52xx_CONSOLE MPC52xx_PSCx_OFFSET(MPC52xx_PF_CONSOLE_PORT)
+#define MPC52xx_PSC_CONFIG_SHIFT ((MPC52xx_PF_CONSOLE_PORT-1)<<2)
#else
#error "MPC52xx_PF_CONSOLE_PORT not defined"
#endif
static struct mpc52xx_psc __iomem *psc =
- (struct mpc52xx_psc __iomem *) MPC52xx_CONSOLE;
+ (struct mpc52xx_psc __iomem *) MPC52xx_PA(MPC52xx_CONSOLE);
/* The decrementer counts at the system bus clock frequency
* divided by four. The most accurate time base is connected to the
- * rtc. We read the decrementer change during one rtc tick (one second)
- * and multiply by 4 to get the system bus clock frequency.
+ * rtc. We read the decrementer change during one rtc tick
+ * and multiply by 4 to get the system bus clock frequency. Since a
+ * rtc tick is one seconds, and that's pretty long, we change the rtc
+ * dividers temporarly to set them 64x faster ;)
*/
static int
mpc52xx_ipbfreq(void)
{
- struct mpc52xx_rtc __iomem *rtc = (struct mpc52xx_rtc __iomem
*)MPC52xx_RTC;
- struct mpc52xx_cdm __iomem *cdm = (struct mpc52xx_cdm __iomem
*)MPC52xx_CDM;
+ struct mpc52xx_rtc __iomem *rtc =
+ (struct mpc52xx_rtc __iomem *) MPC52xx_PA(MPC52xx_RTC_OFFSET);
+ struct mpc52xx_cdm __iomem *cdm =
+ (struct mpc52xx_cdm __iomem *) MPC52xx_PA(MPC52xx_CDM_OFFSET);
int current_time, previous_time;
int tbl_start, tbl_end;
int xlbfreq, ipbfreq;
@@ -68,7 +67,8 @@
unsigned long
serial_init(int ignored, void *ignored2)
{
- struct mpc52xx_gpio __iomem *gpio = (struct mpc52xx_gpio __iomem
*)MPC52xx_GPIO;
+ struct mpc52xx_gpio __iomem *gpio =
+ (struct mpc52xx_gpio __iomem *) MPC52xx_PA(MPC52xx_GPIO_OFFSET);
int divisor;
int mode1;
int mode2;
diff -Nru a/arch/ppc/platforms/lite5200.c b/arch/ppc/platforms/lite5200.c
--- a/arch/ppc/platforms/lite5200.c 2005-03-26 19:56:12 +01:00
+++ b/arch/ppc/platforms/lite5200.c 2005-03-26 19:56:12 +01:00
@@ -73,8 +73,8 @@
u32 intr_ctrl;
/* Map zones */
- xlb = ioremap(MPC52xx_XLB,sizeof(struct mpc52xx_xlb));
- intr = ioremap(MPC52xx_INTR,sizeof(struct mpc52xx_intr));
+ xlb = ioremap(MPC52xx_PA(MPC52xx_XLB_OFFSET), MPC52xx_XLB_SIZE);
+ intr = ioremap(MPC52xx_PA(MPC52xx_INTR_OFFSET), MPC52xx_INTR_SIZE);
if (!xlb || !intr) {
printk("lite5200.c: Error while mapping XLB/INTR during "
diff -Nru a/arch/ppc/platforms/lite5200.h b/arch/ppc/platforms/lite5200.h
--- a/arch/ppc/platforms/lite5200.h 2005-03-26 19:56:12 +01:00
+++ b/arch/ppc/platforms/lite5200.h 2005-03-26 19:56:12 +01:00
@@ -17,7 +17,7 @@
#define __PLATFORMS_LITE5200_H__
/* Serial port used for low-level debug */
-#define MPC52xx_PF_CONSOLE_PORT 0 /* PSC1 */
+#define MPC52xx_PF_CONSOLE_PORT 1 /* PSC1 */
#endif /* __PLATFORMS_LITE5200_H__ */
diff -Nru a/arch/ppc/syslib/mpc52xx_pci.c b/arch/ppc/syslib/mpc52xx_pci.c
--- a/arch/ppc/syslib/mpc52xx_pci.c 2005-03-26 19:56:12 +01:00
+++ b/arch/ppc/syslib/mpc52xx_pci.c 2005-03-26 19:56:12 +01:00
@@ -183,7 +183,7 @@
pci_assign_all_busses = 1;
- pci_regs = ioremap(MPC52xx_PCI, sizeof(struct mpc52xx_pci));
+ pci_regs = ioremap(MPC52xx_PA(MPC52xx_PCI_OFFSET), MPC52xx_PCI_SIZE);
if (!pci_regs)
return;
diff -Nru a/arch/ppc/syslib/mpc52xx_pic.c b/arch/ppc/syslib/mpc52xx_pic.c
--- a/arch/ppc/syslib/mpc52xx_pic.c 2005-03-26 19:56:12 +01:00
+++ b/arch/ppc/syslib/mpc52xx_pic.c 2005-03-26 19:56:12 +01:00
@@ -180,8 +180,8 @@
u32 intr_ctrl;
/* Remap the necessary zones */
- intr = ioremap(MPC52xx_INTR, sizeof(struct mpc52xx_intr));
- sdma = ioremap(MPC52xx_SDMA, sizeof(struct mpc52xx_sdma));
+ intr = ioremap(MPC52xx_PA(MPC52xx_INTR_OFFSET), MPC52xx_INTR_SIZE);
+ sdma = ioremap(MPC52xx_PA(MPC52xx_SDMA_OFFSET), MPC52xx_SDMA_SIZE);
[PATCH 4/6] ppc32: Use platform bus / ppc_sys model for Freescale MPC52xx
ppc32: Use platform bus / ppc_sys model for Freescale MPC52xx
This patch makes all platform based around the Freescale MPC52xx use
the platform bus and more precisly the ppc_sys model put in
place by Kumar Gala.
Signed-off-by: Sylvain Munaut
Signed-off-by: Kumar Gala
---
diff -Nru a/arch/ppc/platforms/lite5200.c b/arch/ppc/platforms/lite5200.c
--- a/arch/ppc/platforms/lite5200.c 2005-03-26 19:56:21 +01:00
+++ b/arch/ppc/platforms/lite5200.c 2005-03-26 19:56:21 +01:00
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
@@ -49,6 +50,17 @@
/* Platform specific code */
/* */
+/* Supported PSC function in "preference" order */
+struct mpc52xx_psc_func mpc52xx_psc_functions[] = {
+ { .id = 0,
+ .func = "uart",
+ },
+ { .id = -1, /* End entry */
+ .func = NULL,
+ }
+ };
+
+
static int
lite5200_show_cpuinfo(struct seq_file *m)
{
@@ -147,6 +159,9 @@
strcpy(cmd_line, (char *)(r6+KERNELBASE));
}
}
+
+ /* PPC Sys identification */
+ identify_ppc_sys_by_id(mfspr(SPRN_SVR));
/* BAT setup */
mpc52xx_set_bat();
diff -Nru a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile 2005-03-26 19:56:21 +01:00
+++ b/arch/ppc/syslib/Makefile 2005-03-26 19:56:21 +01:00
@@ -106,7 +106,8 @@
obj-$(CONFIG_PCI) += indirect_pci.o pci_auto.o
endif
obj-$(CONFIG_MPC8555_CDS) += todc_time.o
-obj-$(CONFIG_PPC_MPC52xx) += mpc52xx_setup.o mpc52xx_pic.o
+obj-$(CONFIG_PPC_MPC52xx) += mpc52xx_setup.o mpc52xx_pic.o \
+ mpc52xx_sys.o mpc52xx_devices.o
ppc_sys.o
ifeq ($(CONFIG_PPC_MPC52xx),y)
obj-$(CONFIG_PCI) += mpc52xx_pci.o
endif
diff -Nru a/arch/ppc/syslib/mpc52xx_devices.c
b/arch/ppc/syslib/mpc52xx_devices.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/syslib/mpc52xx_devices.c 2005-03-26 19:56:21 +01:00
@@ -0,0 +1,318 @@
+/*
+ * arch/ppc/syslib/mpc52xx_devices.c
+ *
+ * Freescale MPC52xx device descriptions
+ *
+ *
+ * Maintainer : Sylvain Munaut
+ *
+ * Copyright (C) 2005 Sylvain Munaut
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+
+
+static u64 mpc52xx_dma_mask = 0xULL;
+
+static struct fsl_i2c_platform_data mpc52xx_fsl_i2c_pdata = {
+ .device_flags = FSL_I2C_DEV_CLOCK_5200,
+};
+
+
+/* We use relative offsets for IORESOURCE_MEM to be independent from the
+ * MBAR location at compile time
+ */
+
+/* TODO Add the BestComm initiator channel to the device definitions,
+ possibly using IORESOURCE_DMA. But that's when BestComm is ready ... */
+
+struct platform_device ppc_sys_platform_devices[] = {
+ [MPC52xx_MSCAN1] = {
+ .name = "mpc52xx-mscan",
+ .id = 0,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x0900,
+ .end= 0x097f,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC52xx_MSCAN1_IRQ,
+ .end= MPC52xx_MSCAN1_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC52xx_MSCAN2] = {
+ .name = "mpc52xx-mscan",
+ .id = 1,
+ .num_resources = 2,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x0980,
+ .end= 0x09ff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MPC52xx_MSCAN2_IRQ,
+ .end= MPC52xx_MSCAN2_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC52xx_SPI] = {
+ .name = "mpc52xx-spi",
+ .id = -1,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .start = 0x0f00,
+ .end= 0x0f1f,
+ .flags = IORESOURCE_MEM,
+ },
+
[PATCH 5/6] serial: Update mpc52xx_uart.c to use platform bus
serial: Update mpc52xx_uart.c to use platform bus
All Freescale MPC52xx related code now use new constants and
the platform bus for it's driver. This patch makes this driver
make use of that.
Signed-off-by: Sylvain Munaut
Signed-off-by: Kumar Gala
---
diff -Nru a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
--- a/drivers/serial/mpc52xx_uart.c 2005-03-26 19:56:30 +01:00
+++ b/drivers/serial/mpc52xx_uart.c 2005-03-26 19:56:30 +01:00
@@ -18,7 +18,7 @@
* Some of the code has been inspired/copied from the 2.4 code written
* by Dale Farnsworth .
*
- * Copyright (C) 2004 Sylvain Munaut
+ * Copyright (C) 2004-2005 Sylvain Munaut
* Copyright (C) 2003 MontaVista, Software, Inc.
*
* This file is licensed under the terms of the GNU General Public License
@@ -26,33 +26,26 @@
* kind, whether express or implied.
*/
-/* OCP Usage :
+/* Platform device Usage :
*
- * This drivers uses the OCP model. To load the serial driver for one of the
- * PSCs, just add this to the core_ocp table :
+ * Since PSCs can have multiple function, the correct driver for each one
+ * is selected by calling mpc52xx_match_psc_function(...). The function
+ * handled by this driver is "uart".
*
- * {
- * .vendor = OCP_VENDOR_FREESCALE,
- * .function = OCP_FUNC_PSC_UART,
- * .index = 0,
- * .paddr = MPC52xx_PSC1,
- * .irq= MPC52xx_PSC1_IRQ,
- * .pm = OCP_CPM_NA,
- * },
- *
- * This is for PSC1, replace the paddr and irq according to the PSC you want to
- * use. The driver all necessary registers to place the PSC in uart mode
without
+ * The driver init all necessary registers to place the PSC in uart mode
without
* DCD. However, the pin multiplexing aren't changed and should be set either
* by the bootloader or in the platform init code.
- * The index field must be equal to the PSC index ( e.g. 0 for PSC1, 1 for
PSC2,
+ *
+ * The idx field must be equal to the PSC index ( e.g. 0 for PSC1, 1 for PSC2,
* and so on). So the PSC1 is mapped to /dev/ttyS0, PSC2 to /dev/ttyS1 and so
* on. But be warned, it's an ABSOLUTE REQUIREMENT ! This is needed mainly for
* the console code : without this 1:1 mapping, at early boot time, when we are
* parsing the kernel args console=ttyS?, we wouldn't know wich PSC it will be
- * mapped to because OCP stuff is not yet initialized.
+ * mapped to.
*/
#include
+#include
#include
#include
#include
@@ -61,7 +54,6 @@
#include
#include
-#include
#include
#include
@@ -191,6 +183,13 @@
mpc52xx_uart_startup(struct uart_port *port)
{
struct mpc52xx_psc __iomem *psc = PSC(port);
+ int ret;
+
+ /* Request IRQ */
+ ret = request_irq(port->irq, mpc52xx_uart_int,
+ SA_INTERRUPT | SA_SAMPLE_RANDOM, "mpc52xx_psc_uart", port);
+ if (ret)
+ return ret;
/* Reset/activate the port, clear and enable interrupts */
out_8(&psc->command,MPC52xx_PSC_RST_RX);
@@ -225,6 +224,9 @@
port->read_status_mask = 0;
out_be16(&psc->mpc52xx_psc_imr,port->read_status_mask);
+
+ /* Release interrupt */
+ free_irq(port->irq, port);
}
static void
@@ -326,15 +328,21 @@
iounmap(port->membase);
port->membase = NULL;
}
+
+ release_mem_region(port->mapbase, MPC52xx_PSC_SIZE);
}
static int
mpc52xx_uart_request_port(struct uart_port *port)
{
if (port->flags & UPF_IOREMAP) /* Need to remap ? */
- port->membase = ioremap(port->mapbase, sizeof(struct
mpc52xx_psc));
-
- return port->membase != NULL ? 0 : -EBUSY;
+ port->membase = ioremap(port->mapbase, MPC52xx_PSC_SIZE);
+
+ if (!port->membase)
+ return -EINVAL;
+
+ return request_mem_region(port->mapbase, MPC52xx_PSC_SIZE,
+ "mpc52xx_psc_uart") != NULL ? 0 : -EBUSY;
}
static void
@@ -354,7 +362,7 @@
if ( (ser->irq != port->irq) ||
(ser->io_type != SERIAL_IO_MEM) ||
(ser->baud_base != port->uartclk) ||
-// FIXME Should check addresses/irq as well ?
+(ser->iomem_base != (void*)port->mapbase) ||
(ser->hub6 != 0 ) )
return -EINVAL;
@@ -630,7 +638,7 @@
{
struct uart_port *port = &mpc52xx_uart_ports[co->index];
- int baud = 9600;
+ int baud = CONFIG_SERIAL_MPC52xx_CONSOLE_BAUD;
int bits = 8;
int parity = 'n';
int flow = 'n';
@@ -643,14 +651,12 @@
spin_lock_init(&port->lock);
port->uartclk = __res.bi_ipbfreq / 2; /* Look at CTLR doc */
port->ops = &mpc52xx_uart_ops;
- port->mapbase = MPC52xx_PSCx(co->index);
+ port-&
[PATCH 6/6] ppc32: Adds necessary cpu init to use USB on LITE5200 Platform
ppc32: Adds necessary cpu init to use USB on LITE5200 Platform
To use external peripheral on MPC5200, some clocking registers
and port-muxing must be done. Since this is platform specific,
it's placed the platform support file. This particular patch
is for USB support on the LITE5200.
Signed-off-by: Sylvain Munaut
Signed-off-by: Kumar Gala
---
diff -Nru a/arch/ppc/platforms/lite5200.c b/arch/ppc/platforms/lite5200.c
--- a/arch/ppc/platforms/lite5200.c 2005-03-26 19:56:38 +01:00
+++ b/arch/ppc/platforms/lite5200.c 2005-03-26 19:56:38 +01:00
@@ -79,21 +79,47 @@
static void __init
lite5200_setup_cpu(void)
{
+ struct mpc52xx_cdm __iomem *cdm;
+ struct mpc52xx_gpio __iomem *gpio;
struct mpc52xx_intr __iomem *intr;
struct mpc52xx_xlb __iomem *xlb;
+ u32 port_config;
u32 intr_ctrl;
/* Map zones */
+ cdm = ioremap(MPC52xx_PA(MPC52xx_CDM_OFFSET), MPC52xx_CDM_SIZE);
+ gpio = ioremap(MPC52xx_PA(MPC52xx_GPIO_OFFSET), MPC52xx_GPIO_SIZE);
xlb = ioremap(MPC52xx_PA(MPC52xx_XLB_OFFSET), MPC52xx_XLB_SIZE);
intr = ioremap(MPC52xx_PA(MPC52xx_INTR_OFFSET), MPC52xx_INTR_SIZE);
- if (!xlb || !intr) {
- printk("lite5200.c: Error while mapping XLB/INTR during "
+ if (!cdm || !gpio || !xlb || !intr) {
+ printk("lite5200.c: Error while mapping CDM/GPIO/XLB/INTR
during"
"lite5200_setup_cpu\n");
goto unmap_regs;
}
+ /* Use internal 48 Mhz */
+ out_8(&cdm->ext_48mhz_en, 0x00);
+ out_8(&cdm->fd_enable, 0x01);
+ if (in_be32(&cdm->rstcfg) & 0x40) /* Assumes 33Mhz clock */
+ out_be16(&cdm->fd_counters, 0x0001);
+ else
+ out_be16(&cdm->fd_counters, 0x);
+
+ /* Get port mux config */
+ port_config = in_be32(&gpio->port_config);
+
+ /* 48Mhz internal, pin is GPIO */
+ port_config &= ~0x0080;
+
+ /* USB port */
+ port_config &= ~0x7000; /* Differential mode - USB1 only */
+ port_config |= 0x1000;
+
+ /* Commit port config */
+ out_be32(&gpio->port_config, port_config);
+
/* Configure the XLB Arbiter */
out_be32(&xlb->master_pri_enable, 0xff);
out_be32(&xlb->master_priority, 0x);
@@ -111,6 +137,8 @@
/* Unmap reg zone */
unmap_regs:
+ if (cdm) iounmap(cdm);
+ if (gpio) iounmap(gpio);
if (xlb) iounmap(xlb);
if (intr) iounmap(intr);
}
@@ -171,7 +199,11 @@
isa_mem_base= 0;
/* Powersave */
- powersave_nap = 1; /* We allow this platform to NAP */
+ /* This is provided as an example on how to do it. But you
+ need to be aware that NAP disable bus snoop and that may
+ be required for some devices to work properly, like USB ... */
+ /* powersave_nap = 1; */
+
/* Setup the ppc_md struct */
ppc_md.setup_arch = lite5200_setup_arch;
Platform bus/ppc sys model...
Hi, > Is there some good documentation about how to use the platform bus / ppc > sys model or is it only possible to read and try to understand the code > for the freescale devices? I'm not aware on documentation for the ppc_sys model in particular but the code is pretty easy to understand/read. Basically you have a ???_devices.c that describe all the devices you can find in a family of devices (by family I mean basically the same processors but with slightly different options/peripheral), then a ???_sys.c that describe each particular variant with the devices that are really implemented in that variant). Then somewhere in platform init code, you need to identify the ppc system you're runngin on ( by a identify_ppc_sys_by_id(mfspr(SPRN_SVR)); for e.g. ). Kumar, if I got it wrong, please correct ;) > Specifically, how do you make the kernel aware of a certain device and > what else is required? Do I have to "connect" the device and the driver > or will the new model find this out automagically? I'm looking at adding > the usual serials, emacs etc... It's "automatic" by using matching of strings. The driver name has to be the same as the device name. More specifically by matching the name field in struct platform_device with the name field in struct device_driver. The code for this magic is in drivers/base/platform.c > Lastly, I suppose this will be the way all platforms should connect > their boards with the devices "from now on", right? It seems to be the trend yes. The OCP and platform bus model have the same base idea/concept. The advantage of platform bus is that it's common in multiple arch, the rest is mainly style. The ppc sys model is based on platform bus to ease working with SoC variants. Sylvain.
[PATCH 0/9] Some Freescale MPC52xx related updates
Hello Andrew & all,
This set of patches contains misc updates that are in my local
tree since sometimes now and I think they're good to go upstream.
They've been posted separatly on the ppc mailing list at some point
and tested by several people. So far I received no negative feedback.
Most are trivial compile fix, small improvements, ...
Thanks,
Sylvain Munaut
[PATCH 1/9] ppc32: Remove useless file arch/ppc/platforms/mpc5200.c
ppc32: Remove useless file arch/ppc/platforms/mpc5200.c
That file is a left-over of the 'old' OCP model that
should have been erased during the change to platform
model but I forgot it ...
Signed-off-by: Sylvain Munaut
---
commit 144f9d12ec7d04b38f83a131c4e544f78d2d47b2
tree 629ebc02993d06ff02b87e2d0effb257ef842328
parent 48ea753075aa15699bd5fac26faa08431aaa697b
author Sylvain Munaut Sat, 17 Dec 2005 23:03:25 +0100
committer Sylvain Munaut Sat, 17 Dec 2005 23:03:25 +0100
arch/ppc/platforms/mpc5200.c | 53 --
1 files changed, 0 insertions(+), 53 deletions(-)
diff --git a/arch/ppc/platforms/mpc5200.c b/arch/ppc/platforms/mpc5200.c
deleted file mode 100644
index a58db43..000
--- a/arch/ppc/platforms/mpc5200.c
+++ /dev/null
@@ -1,53 +0,0 @@
-/*
- * arch/ppc/platforms/mpc5200.c
- *
- * OCP Definitions for the boards based on MPC5200 processor. Contains
- * definitions for every common peripherals. (Mostly all but PSCs)
- *
- * Maintainer : Sylvain Munaut
- *
- * Copyright 2004 Sylvain Munaut
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
- */
-
-#include
-#include
-
-
-static struct ocp_fs_i2c_data mpc5200_i2c_def = {
-.flags = FS_I2C_CLOCK_5200,
-};
-
-
-/* Here is the core_ocp struct.
- * With all the devices common to all board. Even if port multiplexing is
- * not setup for them (if the user don't want them, just don't select the
- * config option). The potentially conflicting devices (like PSCs) goes in
- * board specific file.
- */
-struct ocp_def core_ocp[] = {
- {
- .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_IIC,
- .index = 0,
- .paddr = MPC52xx_I2C1,
- .irq= OCP_IRQ_NA, /* MPC52xx_IRQ_I2C1 - Buggy */
- .pm = OCP_CPM_NA,
- .additions = &mpc5200_i2c_def,
- },
- {
- .vendor = OCP_VENDOR_FREESCALE,
- .function = OCP_FUNC_IIC,
- .index = 1,
- .paddr = MPC52xx_I2C2,
- .irq= OCP_IRQ_NA, /* MPC52xx_IRQ_I2C2 - Buggy */
- .pm = OCP_CPM_NA,
- .additions = &mpc5200_i2c_def,
- },
- { /* Terminating entry */
- .vendor = OCP_VENDOR_INVALID
- }
-};
[PATCH 2/9] ppc32/serial: Fix compiler errors with GCC 4.x in mpc52xx_uart.c
ppc32/serial: Fix compiler errors with GCC 4.x in mpc52xx_uart.c
Signed-off-by: Wolfgang Denk
Signed-off-by: Sylvain Munaut
---
commit c83b03a94291bdd952c6b1b20ab15981456e8625
tree 81e1121a440a4624a4cd7f112fe44fca438ee140
parent 144f9d12ec7d04b38f83a131c4e544f78d2d47b2
author Sylvain Munaut Sat, 17 Dec 2005 23:12:39 +0100
committer Sylvain Munaut Sat, 17 Dec 2005 23:12:39 +0100
drivers/serial/mpc52xx_uart.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index b8727d9..4dcf031 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -668,7 +668,7 @@ mpc52xx_console_setup(struct console *co
}
-extern struct uart_driver mpc52xx_uart_driver;
+static struct uart_driver mpc52xx_uart_driver;
static struct console mpc52xx_console = {
.name = "ttyS",
[PATCH 3/9] ppc32/serial: Change mpc52xx_uart.c to use the Low Density Serial port major
ppc32/serial: Change mpc52xx_uart.c to use the Low Density Serial port major
Before this patch we were just using the "classic" /dev/ttySx devices.
However when another on the system is loaded that uses those (like drivers
for serial PCMCIA), that creates a conflict for the minors. Therefore, we
now use /dev/ttyPSC[0:5] (note the 0-based numbering !) with some minors
we've been assigned in the "Low Density Serial port major"
Signed-off-by: Sylvain Munaut
---
commit 1661f915e8bd58e52fe3326e038efe74068702e0
tree 04215b96380f2d7d218a223d837b9eabe2f120f4
parent c83b03a94291bdd952c6b1b20ab15981456e8625
author Sylvain Munaut Sat, 17 Dec 2005 23:21:16 +0100
committer Sylvain Munaut Sat, 17 Dec 2005 23:21:16 +0100
drivers/serial/mpc52xx_uart.c | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 4dcf031..1288d62 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -37,11 +37,11 @@
* by the bootloader or in the platform init code.
*
* The idx field must be equal to the PSC index ( e.g. 0 for PSC1, 1 for PSC2,
- * and so on). So the PSC1 is mapped to /dev/ttyS0, PSC2 to /dev/ttyS1 and so
- * on. But be warned, it's an ABSOLUTE REQUIREMENT ! This is needed mainly for
- * the console code : without this 1:1 mapping, at early boot time, when we are
- * parsing the kernel args console=ttyS?, we wouldn't know wich PSC it will be
- * mapped to.
+ * and so on). So the PSC1 is mapped to /dev/ttyPSC0, PSC2 to /dev/ttyPSC1 and
+ * so on. But be warned, it's an ABSOLUTE REQUIREMENT ! This is needed mainly
+ * fpr the console code : without this 1:1 mapping, at early boot time, when we
+ * are parsing the kernel args console=ttyPSC?, we wouldn't know wich PSC it
+ * will be mapped to.
*/
#include
@@ -65,6 +65,10 @@
#include
+/* We've been assigned a range on the "Low-density serial ports" major */
+#define SERIAL_PSC_MAJOR 204
+#define SERIAL_PSC_MINOR 148
+
#define ISR_PASS_LIMIT 256 /* Max number of iteration in the interrupt */
@@ -671,12 +675,12 @@ mpc52xx_console_setup(struct console *co
static struct uart_driver mpc52xx_uart_driver;
static struct console mpc52xx_console = {
- .name = "ttyS",
+ .name = "ttyPSC",
.write = mpc52xx_console_write,
.device = uart_console_device,
.setup = mpc52xx_console_setup,
.flags = CON_PRINTBUFFER,
- .index = -1, /* Specified on the cmdline (e.g. console=ttyS0 ) */
+ .index = -1, /* Specified on the cmdline (e.g. console=ttyPSC0 ) */
.data = &mpc52xx_uart_driver,
};
@@ -703,10 +707,10 @@ console_initcall(mpc52xx_console_init);
static struct uart_driver mpc52xx_uart_driver = {
.owner = THIS_MODULE,
.driver_name= "mpc52xx_psc_uart",
- .dev_name = "ttyS",
- .devfs_name = "ttyS",
- .major = TTY_MAJOR,
- .minor = 64,
+ .dev_name = "ttyPSC",
+ .devfs_name = "ttyPSC",
+ .major = SERIAL_PSC_MAJOR,
+ .minor = SERIAL_PSC_MINOR,
.nr = MPC52xx_PSC_MAXNUM,
.cons = MPC52xx_PSC_CONSOLE,
};
[PATCH 4/9] ppc32: Fix static IO mapping for Freescale MPC52xx
ppc32: Fix static IO mapping for Freescale MPC52xx
The current iomapping used MBAR_SIZE for the size argument
of io_block_mapping, resulting in a call to setbat with a
size argument of 64k which is invalid.
This patch correct this and maps the whole 0xf000->0x
range so that devices on the local bus are also included in
the BAT mapping.
Thanks to Bernhard Kuhn from Metrowerks for pointing this out.
Signed-off-by: Sylvain Munaut
---
commit ae62fed2708efa333d41f7b36893e5fdbd0f6730
tree a1a4da53edb2f235be6658558eeb606a0b2580e9
parent 1661f915e8bd58e52fe3326e038efe74068702e0
author Sylvain Munaut Sun, 18 Dec 2005 11:13:15 +0100
committer Sylvain Munaut Sun, 18 Dec 2005 11:13:15 +0100
arch/ppc/syslib/mpc52xx_setup.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/syslib/mpc52xx_setup.c b/arch/ppc/syslib/mpc52xx_setup.c
index bb23745..a4a4b02 100644
--- a/arch/ppc/syslib/mpc52xx_setup.c
+++ b/arch/ppc/syslib/mpc52xx_setup.c
@@ -84,9 +84,11 @@ mpc52xx_set_bat(void)
void __init
mpc52xx_map_io(void)
{
- /* Here we only map the MBAR */
+ /* Here we map the MBAR and the whole upper zone. MBAR is only
+ 64k but we can't map only 64k with BATs. Map the whole
+ 0xf000 range is ok and helps eventual lpb devices placed there */
io_block_mapping(
- MPC52xx_MBAR_VIRT, MPC52xx_MBAR, MPC52xx_MBAR_SIZE, _PAGE_IO);
+ MPC52xx_MBAR_VIRT, MPC52xx_MBAR, 0x1000, _PAGE_IO);
}
[PATCH 5/9] ppc32: Modify Freescale MPC52xx IRQ mapping to _not_ use irq 0
ppc32: Modify Freescale MPC52xx IRQ mapping to _not_ use irq 0
AFAIK IRQ number 0 is a perfectly valid IRQ number. But it seems there
are numerous places where it's considered to be invalid or "no irq" value.
Since that value is problematic, the IRQ mapping is changed to not
use it.
Signed-off-by: Sylvain Munaut
---
commit 0311bddd40fe347ea69a5659f02e1beb8fe96ea8
tree 16003ab98c67face9c25bdb247e241d88dd596f5
parent ae62fed2708efa333d41f7b36893e5fdbd0f6730
author Sylvain Munaut Sun, 18 Dec 2005 11:20:17 +0100
committer Sylvain Munaut Sun, 18 Dec 2005 11:20:17 +0100
include/asm-ppc/mpc52xx.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-ppc/mpc52xx.h b/include/asm-ppc/mpc52xx.h
index e5f80c2..04d5630 100644
--- a/include/asm-ppc/mpc52xx.h
+++ b/include/asm-ppc/mpc52xx.h
@@ -107,7 +107,7 @@ enum ppc_sys_devices {
#define MPC52xx_SDMA_IRQ_NUM 17
#define MPC52xx_PERP_IRQ_NUM 23
-#define MPC52xx_CRIT_IRQ_BASE 0
+#define MPC52xx_CRIT_IRQ_BASE 1
#define MPC52xx_MAIN_IRQ_BASE (MPC52xx_CRIT_IRQ_BASE + MPC52xx_CRIT_IRQ_NUM)
#define MPC52xx_SDMA_IRQ_BASE (MPC52xx_MAIN_IRQ_BASE + MPC52xx_MAIN_IRQ_NUM)
#define MPC52xx_PERP_IRQ_BASE (MPC52xx_SDMA_IRQ_BASE + MPC52xx_SDMA_IRQ_NUM)
