Re: mpc5200 and PWM
On Sun, Jan 25, 2009 at 1:24 AM, Grant Likely wrote: > On Sat, Jan 24, 2009 at 6:20 PM, Jon Smirl wrote: >> Is it possible to use Bestcomm with PWM to generate complex waveforms? >> For example change the frequency and duty cycle after each cycle? Has >> anyone tried doing this? I'd like to build a table of count/width >> pairs and then feed them to the PWM pin without taking an interrupt on >> each cycle. > > I assume you're looking at using one of the GPT PWMs devices, correct? Yes, so this is as hard as I thought it would be. I think I'll stick with Plan A and use a PSC to make the wave form. We're trying to figure out a cheap way to add X10/Insteon support. You can buy PIC chips to do it but they cost $10 with the software license. The external transmit receive circuitry costs about $2 to build. I have the output from it hooked up to a PSC. The signals are 131.65Khz BPSK. I need to get the mpc5200 to make and decode those signals. We want to use X10/Insteon in combination with a keypad to do volume and channel selection. But it works the other way around too. The same circuit can turn the lights off/on. I'd love to get a GPL driver in the kernel for X10/Insteon that just needs the $2 of external circuitry. I'll write one if I can figure out how to do the low level signal processing (my background in it is zero) to get at the packets. I'm not having much luck decoding the BPSK since it has a lot of noise and frequency variance in it. > If so, the you probably cannot do what you want easily. While you > may be able to writing a custom bestcomm task to write into the PWM > registers, the bestcomm engine isn't wired up to the PWM and so cannot > be triggered on PWM events. > > However, the gpio blocks are wired up to the Bestcomm engine so they > can be used as requestors, so if you wired up the PWM output to one of > the GPIO inputs, then you may be able to do something with that. > > g. > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
What are the default VMA maps for linux on PPC32?
Is there a good source that lists the standard virtual address mappings of the various components of linux? I know the kernel starts at 0xC000_ and user apps start at 0x1000_, but things like shared objects are much less clear. For example, the smap entry for my ntpd process shows two distinct areas of usage: ~0xf000_ and ~0x3000_, but I have no idea what's where and why. Can anyone shed some light on this? Thanks. Matt 0fbde000-0fbe2000 r-xp 00:0c 905394 /lib/libnss_dns-2.3.6.so 0fbe2000-0fbf1000 ---p 4000 00:0c 905394 /lib/libnss_dns-2.3.6.so 0fbf1000-0fbf2000 r--p 3000 00:0c 905394 /lib/libnss_dns-2.3.6.so 0fbf2000-0fbf3000 rwxp 4000 00:0c 905394 /lib/libnss_dns-2.3.6.so 0ffba000-0ffbe000 rwxp 0012a000 00:0c 905395 /lib/libc-2.3.6.so 0ffd-0ffe7000 r-xp 00:0c 905370 /lib/ld-2.3.6.so 0fff6000-0fff7000 r--p 00016000 00:0c 905370 /lib/ld-2.3.6.so 0fff7000-0fff8000 rwxp 00017000 00:0c 905370 /lib/ld-2.3.6.so 30009000-3001e000 r-xp 00:0c 1323564/usr/lib/libelf-0.108.so 3001e000-3002d000 ---p 00015000 00:0c 1323564/usr/lib/libelf-0.108.so 3002d000-3002e000 rwxp 00014000 00:0c 1323564/usr/lib/libelf-0.108.so ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] powerpc/5200: update device tree binding documentation
Hello Grant, On Wed, Jan 21, 2009 at 01:55:07PM -0700, Grant Likely wrote: > From: Grant Likely > > This patch updates the mpc5200 binding documentation to match > actual usage conventions, to remove incorrect information, and > to remove topics which are more thoroughly described elsewhere. > > Signed-off-by: Grant Likely > CC: devtree-disc...@ozlabs.org > CC: Wolfram Sang > --- > > Documentation/powerpc/dts-bindings/fsl/mpc5200.txt | 181 + > .../powerpc/mpc52xx-device-tree-bindings.txt | 277 > > 2 files changed, 181 insertions(+), 277 deletions(-) > create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpc5200.txt > delete mode 100644 Documentation/powerpc/mpc52xx-device-tree-bindings.txt > > > diff --git a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt > b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt > new file mode 100644 > index 000..1eddda7 > --- /dev/null > +++ b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt > @@ -0,0 +1,181 @@ > +MPC5200 Device Tree Bindings > + > + > +(c) 2006-2009 Secret Lab Technologies Ltd > +Grant Likely > + > +Naming conventions > +-- > +For mpc5200 on-chip devices, the format for each compatible value is > +-[-]. The OS should be able to match a device driver > +to the device based solely on the compatible value. If two drivers > +match on the compatible list; the 'most compatible' driver should be > +selected. > + > +The split between the MPC5200 and the MPC5200B leaves a bit of a > +conundrum. How should the compatible property be set up to provide > +maximum compatibility information; but still accurately describe the > +chip? For the MPC5200; the answer is easy. Most of the SoC devices > +originally appeared on the MPC5200. Since they didn't exist anywhere > +else; the 5200 compatible properties will contain only one item; > +"fsl,mpc5200-". > + > +The 5200B is almost the same as the 5200, but not quite. It fixes > +silicon bugs and it adds a small number of enhancements. Most of the > +devices either provide exactly the same interface as on the 5200. A few > +devices have extra functions but still have a backwards compatible mode. > +To express this information as completely as possible, 5200B device trees > +should have two items in the compatible list: > + compatible = "fsl,mpc5200b-","fsl,mpc5200-"; > + > +It is *strongly* recommended that 5200B device trees follow this convention > +(instead of only listing the base mpc5200 item). > + > +ie. ethernet on mpc5200: compatible = "fsl,mpc5200-ethernet"; > +ethernet on mpc5200b: compatible = "fsl,mpc5200b-ethernet", > + "fsl,mpc5200-ethernet"; > + > +Modal devices, like PSCs, also append the configured function to the > +end of the compatible field. ie. A PSC in i2s mode would specify > +"fsl,mpc5200-psc-i2s", not "fsl,mpc5200-i2s". This convention is chosen to > +avoid naming conflicts with non-psc devices providing the same > +function. For example, "fsl,mpc5200-spi" and "fsl,mpc5200-psc-spi" describe > +the mpc5200 simple spi device and a PSC spi mode respectively. > + > +At the time of writing, exact chip may be either 'fsl,mpc5200' or > +'fsl,mpc5200b'. > + > +The soc node > + > +This node describes the on chip SOC peripherals. Every mpc5200 based > +board will have this node, and as such there is a common naming > +convention for SOC devices. > + > +Required properties: > +name description > + --- > +ranges Memory range of the internal memory mapped > registers. > + Should be <0 [baseaddr] 0xc000> > +reg Should be <[baseaddr] 0x100> > +compatible mpc5200: "fsl,mpc5200-immr" > + mpc5200b: "fsl,mpc5200b-immr" > +system-frequency Fsystem frequency; source of all Fsystem? Typo? The unit would be nice here, too, I think. > + other clocks. > +bus-frequencyIPB bus frequency in HZ. Clock rate > + used by most of the soc devices. > + > +soc child nodes > +--- > +Any on chip SOC devices available to Linux must appear as soc5200 child > nodes. > + > +Note: The tables below show the value for the mpc5200. A mpc5200b device > +tree should use the "fsl,mpc5200b-","fsl,mpc5200-" form. > + > +Required soc5200 child nodes: > +name compatible Description > + -- --- > +cdm@ fsl,mpc5200-cmd Clock Distribution ^^ cdm! > +interrupt-controller@ fsl,mpc5200-pic need an interrupt > + controller to boot > +bestcomm@ fsl,mpc5200-bestcommBestcomm DMA > controller > + > +Recommended soc5200 child
Re: [PATCH 7/8] powerpc/5200: Refactor mpc5200 interrupt controller driver
Grant Likely wrote:
> From: Grant Likely
>
> Rework the mpc5200-pic driver to simplify it and fix up the setting
> of desc->status when set_type is called for internal IRQs (so they
> are reported as level, not edge). The simplification is due to
> splitting off the handling of external IRQs into a separate block
> so they don't need to be handled as exceptions in the normal
> CRIT, MAIN and PERP paths.
>
> Signed-off-by: Grant Likely
> CC: Wolfram Sang
> ---
>
> arch/powerpc/platforms/52xx/mpc52xx_pic.c | 145
> -
> 1 files changed, 58 insertions(+), 87 deletions(-)
>
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
> b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
> index c0a9559..277c9c5 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
> @@ -190,10 +190,10 @@ static void mpc52xx_extirq_ack(unsigned int virq)
>
> static int mpc52xx_extirq_set_type(unsigned int virq, unsigned int flow_type)
> {
> - struct irq_desc *desc = get_irq_desc(virq);
> u32 ctrl_reg, type;
> int irq;
> int l2irq;
> + void *handler = handle_level_irq;
>
> irq = irq_map[virq].hwirq;
> l2irq = irq & MPC52xx_IRQ_L2_MASK;
> @@ -201,32 +201,21 @@ static int mpc52xx_extirq_set_type(unsigned int virq,
> unsigned int flow_type)
> pr_debug("%s: irq=%x. l2=%d flow_type=%d\n", __func__, irq, l2irq,
> flow_type);
>
> switch (flow_type) {
> - case IRQF_TRIGGER_HIGH:
> - type = 0;
> - break;
> - case IRQF_TRIGGER_RISING:
> - type = 1;
> - break;
> - case IRQF_TRIGGER_FALLING:
> - type = 2;
> - break;
> - case IRQF_TRIGGER_LOW:
> - type = 3;
> - break;
> + case IRQF_TRIGGER_HIGH: type = 0; break;
> + case IRQF_TRIGGER_RISING: type = 1; handler = handle_edge_irq; break;
> + case IRQF_TRIGGER_FALLING: type = 2; handler = handle_edge_irq; break;
> + case IRQF_TRIGGER_LOW: type = 3; break;
The Linux coding style tells us not to do that:
http://lxr.linux.no/linux+v2.6.28.2/Documentation/CodingStyle#L60
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 7/8] powerpc/5200: Refactor mpc5200 interrupt controller driver
On Sun, Jan 25, 2009 at 1:06 PM, Wolfgang Grandegger
wrote:
> Grant Likely wrote:
>> From: Grant Likely
>>
>> Rework the mpc5200-pic driver to simplify it and fix up the setting
>> of desc->status when set_type is called for internal IRQs (so they
>> are reported as level, not edge). The simplification is due to
>> splitting off the handling of external IRQs into a separate block
>> so they don't need to be handled as exceptions in the normal
>> CRIT, MAIN and PERP paths.
>>
>> Signed-off-by: Grant Likely
>> CC: Wolfram Sang
>> ---
>>
>> arch/powerpc/platforms/52xx/mpc52xx_pic.c | 145
>> -
>> 1 files changed, 58 insertions(+), 87 deletions(-)
>>
>>
>> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
>> b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
>> index c0a9559..277c9c5 100644
>> --- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
>> +++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
>> @@ -190,10 +190,10 @@ static void mpc52xx_extirq_ack(unsigned int virq)
>>
>> static int mpc52xx_extirq_set_type(unsigned int virq, unsigned int
>> flow_type)
>> {
>> - struct irq_desc *desc = get_irq_desc(virq);
>> u32 ctrl_reg, type;
>> int irq;
>> int l2irq;
>> + void *handler = handle_level_irq;
>>
>> irq = irq_map[virq].hwirq;
>> l2irq = irq & MPC52xx_IRQ_L2_MASK;
>> @@ -201,32 +201,21 @@ static int mpc52xx_extirq_set_type(unsigned int virq,
>> unsigned int flow_type)
>> pr_debug("%s: irq=%x. l2=%d flow_type=%d\n", __func__, irq, l2irq,
>> flow_type);
>>
>> switch (flow_type) {
>> - case IRQF_TRIGGER_HIGH:
>> - type = 0;
>> - break;
>> - case IRQF_TRIGGER_RISING:
>> - type = 1;
>> - break;
>> - case IRQF_TRIGGER_FALLING:
>> - type = 2;
>> - break;
>> - case IRQF_TRIGGER_LOW:
>> - type = 3;
>> - break;
>> + case IRQF_TRIGGER_HIGH: type = 0; break;
>> + case IRQF_TRIGGER_RISING: type = 1; handler = handle_edge_irq; break;
>> + case IRQF_TRIGGER_FALLING: type = 2; handler = handle_edge_irq; break;
>> + case IRQF_TRIGGER_LOW: type = 3; break;
>
> The Linux coding style tells us not to do that:
>
> http://lxr.linux.no/linux+v2.6.28.2/Documentation/CodingStyle#L60
In principle I agree and follow that rule most of the time, but I have
good reason for not choosing to do so here.
The whole point of coding style is to promote
readability/manageability. ie. the 80 column rule is a very strong
guideline, but there are places where breaking that rule makes for
more readable code than breaking things up and it is left to the
discretion of the coder and the maintainer.
In this case I looked at the block of code and saw that a large number
of lines (11) were needed to do a set of nearly identical operations.
I chose to line them up because in my opinion it is easier to follow
the pattern with them written in horizontal columns instead of in
vertical blocks. In other words, in this case it is harder to hide
something in the code written this way because it wouldn't match the
pattern of the other lines. For the same reason you'll also notice
that I did *not* put all the statements on the same line for the
default case because it doesn't match the pattern of the specific
cases.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] powerpc/5200: update device tree binding documentation
On Sun, Jan 25, 2009 at 12:48 PM, Wolfram Sang wrote: > On Wed, Jan 21, 2009 at 01:55:07PM -0700, Grant Likely wrote: >> +system-frequency Fsystem frequency; source of all > > Fsystem? Typo? Not really, that's the name of the clock in the MP5200 user guide. I'll clarify what I've written here though. > The unit would be nice here, too, I think. Unit? Do you mean stating that it is in Hz? >> +cdm@ fsl,mpc5200-cmd Clock Distribution > > ^^ cdm! >> +is for flags which is currently unsused. > > Typo: should be "unused". Good catches, thanks. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 7/8] powerpc/5200: Refactor mpc5200 interrupt controller driver
Dear Grant Likely, In message you wrote: > > >> - case IRQF_TRIGGER_HIGH: > >> - type = 0; > >> - break; > >> - case IRQF_TRIGGER_RISING: > >> - type = 1; > >> - break; > >> - case IRQF_TRIGGER_FALLING: > >> - type = 2; > >> - break; > >> - case IRQF_TRIGGER_LOW: > >> - type = 3; > >> - break; > >> + case IRQF_TRIGGER_HIGH: type = 0; break; > >> + case IRQF_TRIGGER_RISING: type = 1; handler = handle_edge_irq; break; > >> + case IRQF_TRIGGER_FALLING: type = 2; handler = handle_edge_irq; > >> break; > >> + case IRQF_TRIGGER_LOW: type = 3; break; > > > > The Linux coding style tells us not to do that: ... > In principle I agree and follow that rule most of the time, but I have > good reason for not choosing to do so here. > > The whole point of coding style is to promote > readability/manageability. ie. the 80 column rule is a very strong > guideline, but there are places where breaking that rule makes for > more readable code than breaking things up and it is left to the > discretion of the coder and the maintainer. It's not so much the line length, IMO. It's "Don't put multiple statements on a single line", plus readability. I think the new version is more difficult to read. It's plain ugly, and inconsistent. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. - Franklin D. Roosevelt ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
