* Re: Help required on mpc8260 kernel boot
From: Wolfgang Denk @ 2005-12-07 12:19 UTC (permalink / raw)
To: batsayan.das; +Cc: linuxppc-embedded
In-Reply-To: <OFCBD37606.7E278616-ON652570D0.0028C041-652570D0.00360A00@tcs.com>
In message <OFCBD37606.7E278616-ON652570D0.0028C041-652570D0.00360A00@tcs.com> you wrote:
>
> I am using customs board with MPC8260 processor. I have RAM version of
> U-Boot and I am able to get U-Boot prompt when I load and run u-bbot.srec
> by TRACE32. My memory map is as follows
>
> SDRAM start address :0x30000000 and 128MB
> Flash start address: 0x00000000 and 1MB
One of your fellows (mail address pritha.bhattacharya@tcs.com) posted
this before, and received pretty clear hints that your configuration
is not correct.
Also, you continue to ignore answers from the FAQs.
Please read the answers you received before, and follow the advice
given.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
panic: can't find /
^ permalink raw reply
* Re: Help needed : MCC driver for MPC8260 ADS
From: Stevan Ignjatovic @ 2005-12-07 12:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OFE97B5EA0.D9C1175E-ON652570D0.00392019-652570D0.003AB2EA@tcs.com>
Start point for your MCC driver could be at
http://sourceforge.net/projects/mcc8260/
On Wed, 2005-12-07 at 11:41, s.maiti@tcs.com wrote:
> Hello All,
>
> For our project we need to have a MCC driver for MPC8260 ADS board. I
> couldn't find any driver in the linux source tree for the same.
> Any help in this regard will be highly appreciated.
> Thanks and regards,
>
> Souvik Maiti
> Tata Consultancy Services Limited
> Bengal Intelligent Park
> Bldg. - D, Plots - A2, M2 & N2
> Block - GP, Sector V
> Salt Lake Electronics Complex
> Kolkata - 700091, West Bengal
> India
> Mailto: s.maiti@tcs.com
> Website: http://www.tcs.com
> Notice: The information contained in this e-mail message and/or
> attachments to it may contain confidential or privileged information.
> If you are not the intended recipient, any dissemination, use, review,
> distribution, printing or copying of the information contained in this
> e-mail message and/or attachments to it are strictly prohibited. If
> you have received this communication in error, please notify us by
> reply e-mail or telephone and immediately and permanently delete the
> message and any attachments. Thank you
>
> ______________________________________________________________________
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Transmit timeouts on 440GX Ocotea on 10baseT-HD network
From: Wade Farnsworth @ 2005-12-07 15:15 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
Hi Eugene,
I'm seeing some "NETDEV WATCHDOG: eth0: transmit timed out" messages on
the Ocotea when it's connected to a 10baseT hub, and it's put under
heavy load. I'm using the most current 2.6 git tree.
This can be reproduced by ssh'ing into the Ocotea and running the
command "ping <host-machine> -A -s 1200", then also doing the same ping
command from the host to the Ocotea. The pings will be successful for a
short time, then all transmits on the Ocotea will stop for a few seconds
(usually preceded by a few duplicate packets). Transmits begin again
once the timeout occurs. /proc/net/dev doesn't report any errors, just a
few dropped packets.
Do you know what might be causing the EMAC to stop transmitting in this
situation?
Thanks,
Wade Farnsworth
^ permalink raw reply
* Re: MPC8245 with its internal UART
From: Kumar Gala @ 2005-12-07 16:39 UTC (permalink / raw)
To: Dan Malek; +Cc: HappyPhot, linuxppc-embedded
In-Reply-To: <03f747f66110e0d5976c2c03a76945aa@embeddededge.com>
On Dec 6, 2005, at 10:43 PM, Dan Malek wrote:
>
> On Dec 6, 2005, at 7:44 PM, HappyPhot wrote:
>
>> Who can tell me which flatform is similar to mine ? I've tried
>> "make sandpoint_defconfig", but seems not the right one.
>
> That's the one I would have recommended. I don't think there
> is any Linux platform port that uses the 8245 internal DUART,
> at least not in the public source tree. The DUART is actually
> pretty easy, just use the generic 8250 driver and point the address
> to the Embedded Utilities Block DUART.
The 2.6 kernel tree has support for the DUART on 8245 Sandpoint
systems. (We added it in the last few months).
- kumar
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Kumar Gala @ 2005-12-07 16:54 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Arnd Bergmann, linuxppc64-dev
In-Reply-To: <20051207001720.GB25533@localhost.localdomain>
On Dec 6, 2005, at 6:17 PM, David Gibson wrote:
> On Tue, Dec 06, 2005 at 08:48:55PM +0100, Arnd Bergmann wrote:
>> On Maandag 05 Dezember 2005 22:06, Jon Loeliger wrote:
>>> Included below is a proposed Revision 0.5 of the
>>> "Booting the Linux/ppc kernel without Open Firmware"
>>> document. This modification primarily extends the
>>> Revision 0.4 by adding definitions for OF Nodes that
>>> cover the System-On-a-Chip features found on PPC parts.
>>> It also generalizes some earlier wording that pertained
>>> to only PPC64 parts and covers the new, merged PPC 32
>>> and 64 parts together. Finally, minor typos, style
>>> consistency and grammar problems were corrected.
>>
>> A few points are not clear yet, either because I don't understand the
>> document or one it references correctly or because I might have
>> different requirements:
>
> All comments below IMHO, and subject to persuasion otherwise.
>
>> - Do we need a way to identify the type of soc bus? There are
>> different
>> standards for this, e.g. PLB4 on PPC440 or the EIB on the Cell BE.
>> My initial idea was to have different device-type properties for
>> these,
>> but I now think that device_type = "soc" makes sense for all of
>> them.
>> Maybe we could add a model or compatible property for them.
>
> It think it would be a good idea to have something labelling the
> specific type of SOC bus, though I'm not immediately sure where.
> "model" perhaps, if it rarely has an effect on how to operate the bus.
I think this should be optional since it rarely has an effect on usage.
>> - It does not really belong into this document, but is related
>> anyway:
>> how do you want to represent this in Linux? Currently, most of
>> these
>> would be of_platform_device, but I think it would be good to have
>> a new bus_type for it. The advantage would be that you can see the
>> devices in /sys/devices/soc@xxx/ even if the driver is not loaded
>> and the driver can even be autoloaded by udev.
>> Also, which properties should show up in sysfs? All of them or just
>> those specified in this document or a subset of them?
>
> I concur - I believe we already have a bus_type for on-chip devices on
> 4xx.
Not, sure what the 4xx reference is but, we have be using the
platform bus in the kernel for "soc" connected devices. I dont see
the need to invent a new bus type unless there is a specific reason to.
>> - What do we do with pci root devices? They are often physically
>> connected
>> to the internal CPU bus, so it would make sense to represent them
>> this way in the device tree. Should we add them to the
>> specification
>> here? Would it even work the expected way in Linux?
>
> The host bridges should sit on the soc bus then, as you suggest (just
> as the PCI busses hang off HyperTransport on the G5). I think you
> need to refer to the OF docs for how to represent the PCI host bridge
> and devices themselves.
We need to provide some details on PCI nodes based on the OF docs.
Ben and I have talked a little about this. Its mainly about what
parts of the OF spec are truly required. We will probably add some
additional information that the OF spec doesnt handle for host
bridges setup.
>> - For some devices, you mandate a model property, for others you
>> don't.
>> Is this intentional? It might be easier to find the right device
>> driver if the match string always contains a model name.
>
> You rarely want to match model name to find a device - generally you
> want to match either on "compatible" or "device_type", or possibly
> both.
>
>> - How would I represent nested interrupt controllers? E.g. suppose I
>> have a Cell internal interrupt controller on one SOC bus and
>> and an external interrupt controller on another SOC bus but have
>> that deliver interrupts to the first one.
>
> Again, I believe this is in the OF docs - interrupt controllers have
> an interrupt-parent property IIRC, which gives the phandle of the next
> interrupt controller up the chain.
Yep, you need to check out the "Interrupt Mapping" OF spec for
details. It handles describing the chaining you speak of. However,
you will need to provide some "spec" for any properties of the
interrupt controllers that you may need.
>> - Should it mention nested SOC buses, e.g. a PLB4 bus connected to a
>> PLB5 bus?
>
> Yes.
Is there anything special about this? are these PLB4/5 busses
software visible?
>
>> - The title says 'without Open Firmware', but it should also be
>> allowed
>> to use the same SOC bus layout when using SLOF or some other OF
>> implementation, right?
>
> I guess so.
>
>> - Also not new in this version, but still: Should there be support
>> for
>> specifying CPUs with multiple SMT threads?
>
> Umm.. maybe.
- kumar
^ permalink raw reply
* Re: Transmit timeouts on 440GX Ocotea on 10baseT-HD network
From: Wade Farnsworth @ 2005-12-07 16:54 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <1133968527.8299.50.camel@rhino.az.mvista.com>
On Wed, 2005-12-07 at 08:15, Wade Farnsworth wrote:
> Hi Eugene,
>
> I'm seeing some "NETDEV WATCHDOG: eth0: transmit timed out" messages on
> the Ocotea when it's connected to a 10baseT hub, and it's put under
> heavy load. I'm using the most current 2.6 git tree.
>
> This can be reproduced by ssh'ing into the Ocotea and running the
> command "ping <host-machine> -A -s 1200", then also doing the same ping
> command from the host to the Ocotea. The pings will be successful for a
> short time, then all transmits on the Ocotea will stop for a few seconds
> (usually preceded by a few duplicate packets). Transmits begin again
> once the timeout occurs. /proc/net/dev doesn't report any errors, just a
> few dropped packets.
>
> Do you know what might be causing the EMAC to stop transmitting in this
> situation?
One more data point to consider: I ran this test on an Ebony board, but
don't encounter any timeouts. Do you know of any 440GX-specific issues
that might cause this?
Thanks again,
Wade Farnsworth
^ permalink raw reply
* Re: Video Card to Lite5200
From: roger blofeld @ 2005-12-07 17:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051205203941.GA16695@mail.gnudd.com>
What is the status of the mpc5200 support? I see Sylvain's repository
is still at 2.6.12 (5 months old).
http://gitbits.246tnt.com/gitweb.cgi?p=linux-2.6-mpc52xx.git;a=summary
The current kernel.org kernel doesn't appear to support fec/DMA. Is
there a plan to get networking support into the mainstream kernel?
Thanks
-rb
--- Alessandro Rubini <rubini@gnudd.com> wrote:
>
> > Note that the 5200 code in the kernel is work in progress. I do
> not
> > cleaim that it does work in any way. If you want stable code use
> our
> > 2.4.25 kernel instead.
>
> FWIW, I have your 2.6.14 happily running on the lite5200, with PCI,
> IDE (no DMA though) and flash.
>
> I can publish the patches, if anyone is interested. Until now I
> didn't,
> as Sylvain's work is considered the official one (but it didn't have
> IDE last time I checked -- and I don't have bitkeeper to pull it).
>
> /alessandro
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
__________________________________________
Yahoo! DSL – Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
^ permalink raw reply
* Re: Transmit timeouts on 440GX Ocotea on 10baseT-HD network
From: Eugene Surovegin @ 2005-12-07 17:35 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <1133968527.8299.50.camel@rhino.az.mvista.com>
On Wed, Dec 07, 2005 at 08:15:28AM -0700, Wade Farnsworth wrote:
> Hi Eugene,
>
> I'm seeing some "NETDEV WATCHDOG: eth0: transmit timed out" messages on
> the Ocotea when it's connected to a 10baseT hub, and it's put under
> heavy load. I'm using the most current 2.6 git tree.
>
> This can be reproduced by ssh'ing into the Ocotea and running the
> command "ping <host-machine> -A -s 1200", then also doing the same ping
> command from the host to the Ocotea. The pings will be successful for a
> short time, then all transmits on the Ocotea will stop for a few seconds
> (usually preceded by a few duplicate packets). Transmits begin again
> once the timeout occurs. /proc/net/dev doesn't report any errors, just a
> few dropped packets.
>
> Do you know what might be causing the EMAC to stop transmitting in this
> situation?
Hmm, I think this should have been fixed in the latest 2.6. Check
that you tree has this patch:
[PATCH] ibm_emac: fix graceful stop timeout handling
It went in on 01 Dec. Although this fix assumed FDX operation for
timeouts, without collisions. Maybe I was too optimistic thinking that
nobody uses 10/HDX :).
Try making STOP_TIMEOUT_10 bigger, say twice as big.
If this doesn't help, I'll send you patch with enables some additional
debugging, so I can check that stop you are experiencing is the same
problem I had last month.
--
Eugene
^ permalink raw reply
* Re: Transmit timeouts on 440GX Ocotea on 10baseT-HD network
From: Wade Farnsworth @ 2005-12-07 18:00 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
In-Reply-To: <20051207173554.GA21578@gate.ebshome.net>
On Wed, 2005-12-07 at 10:35, Eugene Surovegin wrote:
> Hmm, I think this should have been fixed in the latest 2.6. Check
> that you tree has this patch:
>
> [PATCH] ibm_emac: fix graceful stop timeout handling
>
> It went in on 01 Dec. Although this fix assumed FDX operation for
> timeouts, without collisions. Maybe I was too optimistic thinking that
> nobody uses 10/HDX :).
That was my first thought as well, but I've tried it with the patch, and
still get the timeouts.
>
> Try making STOP_TIMEOUT_10 bigger, say twice as big.
That doesn't seem to help any.
>
> If this doesn't help, I'll send you patch with enables some additional
> debugging, so I can check that stop you are experiencing is the same
> problem I had last month.
Much appreciated. Thanks!
Regards,
Wade Farnsworth
^ permalink raw reply
* Re: Video Card to Lite5200
From: Alan Carvalho @ 2005-12-07 18:53 UTC (permalink / raw)
To: roger blofeld; +Cc: linuxppc-embedded
In-Reply-To: <20051207172321.77464.qmail@web53515.mail.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 588 bytes --]
Hi Roger,
On 12/7/05, roger blofeld <blofeldus@yahoo.com> wrote:
>
> What is the status of the mpc5200 support? I see Sylvain's repository
> is still at 2.6.12 (5 months old).
>
> http://gitbits.246tnt.com/gitweb.cgi?p=linux-2.6-mpc52xx.git;a=summary
>
> The current kernel.org kernel doesn't appear to support fec/DMA. Is
> there a plan to get networking support into the mainstream kernel?
I am using linux kernel 2.6.14, downloaded from denx site, it is supporting
FEC correctly, well it show a silly error msg, but work fine.
Thanks
> -rb
Cheers,
Alan
[-- Attachment #2: Type: text/html, Size: 1175 bytes --]
^ permalink raw reply
* Re: Video Card to Lite5200
From: Wolfgang Denk @ 2005-12-07 19:51 UTC (permalink / raw)
To: roger blofeld; +Cc: linuxppc-embedded
In-Reply-To: <20051207172321.77464.qmail@web53515.mail.yahoo.com>
In message <20051207172321.77464.qmail@web53515.mail.yahoo.com> you wrote:
>
> The current kernel.org kernel doesn't appear to support fec/DMA. Is
> there a plan to get networking support into the mainstream kernel?
I don;t know - the patches were submitted to this list a long time
ago; we added them to our repository without any additional problems;
see http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If ignorance is bliss, why aren't there more happy people?
^ permalink raw reply
* Re: Video Card to Lite5200
From: bennett78 @ 2005-12-07 21:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051205203515.51D4C353F5E@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]
Wolfgang Denk wrote:
>Dear Alan,
>
>in message <dc70db7d0512051130s498f7d5fk42a0f4886c006efd@mail.gmail.com> you wrote:
>
>
>>I am just looking for a cheaper video card to use with Lite5200 board.
>>CoralP is very expansive, then I will use ATI Rage Mobility.
>>
>>
>
>Make sure that you don't need to run any (x86) BIOS code on your card
>to initialize it. This is the main issue with most graphics cards.
>
>
>
>>Well, my video card is not ATI Rage Mobility M1 EVA, it has not 723
>>regulator, it use MTD3302 as regulator, do you know if I need change
>>something on the Lite5200's PCI slot to it work with this video card?
>>
>>
>
>If your card is a true 3.3V PCI card it should be at least possible
>to attach and test it. Chances are that it does not work (at least
>not without some amount of work).
>
>
>
>>My Lite5200 is Version 2.0, and Freescale connected some wire (small cables)
>>to PCI slot, maybe to fix some PCI problems.
>>
>>
>
>You probably want to ask FS about this.
>
>
>
>>I am using linux kernel 2.6.14, downloaded from denx's web site. Linux is
>>
>>
>
>Note that the 5200 code in the kernel is work in progress. I do not
>cleaim that it does work in any way. If you want stable code use our
>2.4.25 kernel instead.
>
>
>
>>running fine in this board, but until now I am using only serial console.
>>Now I want use a video card with it.
>>
>>
>
>Well, if your time is worth anything you might find out that the
>CoralP is the cheaper solution - or using a graphics controller that
>can be attached directly to the bus.
>
>
Wolfgang:
The denx.de web site looks great.
Where can someone get this PCI card? Do I have to contact Fujitsu
directly? Cost?
The Fujitsu CoralP evaluation board MB86295EB01? or did you use the
Coral PA?
I saw a posting that you also had some streaming video running. Tell me
more.
What resolution? 4CIF (full DVD)
What display? LCD SVGA (800x600) and/or VGA analog port?
Software MPEG decoder or does the Coral have a decoder?
Which player did you use?
Is all this covered in some release notes?
Was the katix stuff ever integrated into linux_2_4_development?
How does Wolfgang make a living if he spends all his time answering our
questions?
thanks,
Frank Bennett
>Best regards,
>
>Wolfgang Denk
>
>
*//* <mailto:frank.bennett@triadsyseng.com>
[-- Attachment #2: Type: text/html, Size: 3658 bytes --]
^ permalink raw reply
* ppc4xx DMA fixes for simultaneous sg transfers
From: ductusrhe @ 2005-12-07 21:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 12046 bytes --]
Linux 2.4.20 (probably 2.6 as well?)
Conclusion:
Scatter/gather DMA is not thread safe.
Background:
1. We run all four dma channels simultaneously in SG mode on the PPC440EP, starting and stopping them in different threads.
2. Also we need to change channel configs between different transfers, i.e. run ppc4xx_init_dma_channel() to set read or write mode.
Problem and cause:
1. All is well when running one channel at a time, but when starting/stopping a new channel during the time another is active can - if you are unlucky - cause problems.
Because all channels SG start/stop bits are in the same register (ASGC), it must not be read then changed and written to the way it was done.
That can cause a channel that is just done, to start again, or a newly started channel to stop.
The register includes a feature that can be used as a semaphore - the read enable (mask) bits, but it was not used correctly in the code, it was enabled for all channels in the start-up.
2. It is said in the comment of ppc4xx_init_dma_channel() that it should only be used once in the start-up. If you comply, you will not have any problem with it.
However, when running this for a channel when other channels are active, can cause channels to stop or maybe never give an interrupt or false interrupts. The method clears the entire status register, not only the bits for the given channel.
Solution:
1. - In ppc4xx_alloc_dma_handle(), do not touch the ASGC register!
- In ppc4xx_enable_dma_sgl() and ppc4xx_disable_dma_sgl(), when setting the ASGC register, only change the given channel.
That's done without reading the register at all, just set/clear the enable bit of the channel to change, then set the MASK_ENABLE for the same channel.
Probably this is the way the register was intended to be handled?
2. - In ppc4xx_init_dma_channel(), only clear the correct bits of the DMASR register, not the whole register.
(The polarity was also not set as it's supposed to in this function, but there exists a patch for that)
I can send a patch with our changes, that works very well and stable, but there are many changes and not all of them in line with the current official version of the files (we handle the sg descriptor list differently). Maybe someone feeling for it will take a look at the changes and make them into the real code, since the above fixes does not interfere with the usage, only improves thread safety.
I have no idea if this has been fixed in some patch already... but I have not seen it on this list anyway.
I'm not a regular poster, just want to help others avoid some of the struggle when running many channels.
/Ronnie Hedlund
Our changed code:
In "ppc4xx_dma.c"
-----------------------
/*
* The comment states that this function should only be run at start-up, and never more.
* That is unacceptable, with the fix it can be run anywhere as long as the given channel is not running.
*/
int ppc4xx_init_dma_channel(unsigned int dmanr, ppc_dma_ch_t * p_init)
{
unsigned int status_bits[] = { DMA_CS0 | DMA_TS0 | DMA_CH0_ERR,
DMA_CS1 | DMA_TS1 | DMA_CH1_ERR,
DMA_CS2 | DMA_TS2 | DMA_CH2_ERR,
DMA_CS3 | DMA_TS3 | DMA_CH3_ERR};
unsigned int polarity;
uint32_t control = 0;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
DMA_MODE_READ = (unsigned long) DMA_TD; /* Peripheral to Memory */
DMA_MODE_WRITE = 0; /* Memory to Peripheral */
if (!p_init) {
printk("ppc4xx_init_dma_channel: NULL p_init\n");
return DMA_STATUS_NULL_POINTER;
}
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_init_dma_channel: bad channel %d\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
#if DCRN_POL > 0
polarity = mfdcr(DCRN_POL);
#else
polarity = 0;
#endif
/* Setup the control register based on the values passed to
* us in p_init. Then, over-write the control register with this
* new value.
*/
control |= SET_DMA_CONTROL;
switch (dmanr) {
case 0:
/* clear all polarity signals and then "or" in new signal levels */
polarity &= ~GET_DMA_POLARITY(0);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR0, control);
break;
case 1:
polarity &= ~GET_DMA_POLARITY(1);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR1, control);
break;
case 2:
polarity &= ~GET_DMA_POLARITY(2);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR2, control);
break;
case 3:
polarity &= ~GET_DMA_POLARITY(3);
polarity |= p_init->polarity;
#if DCRN_POL > 0
mtdcr(DCRN_POL, polarity);
#endif
mtdcr(DCRN_DMACR3, control);
break;
default:
return DMA_STATUS_BAD_CHANNEL;
}
/* save these values in our dma channel structure */
memcpy(p_dma_ch, p_init, sizeof (ppc_dma_ch_t));
/*
* The peripheral width values written in the control register are:
* PW_8 0
* PW_16 1
* PW_32 2
* PW_64 3
*
* Since the DMA count register takes the number of "transfers",
* we need to divide the count sent to us in certain
* functions by the appropriate number. It so happens that our
* right shift value is equal to the peripheral width value.
*/
p_dma_ch->shift = p_init->pwidth;
/*
* Save the control word for easy access.
*/
p_dma_ch->control = control;
/*
* clear status register for the channel
* only TS, CS and RI needs to be cleared.
*/
mtdcr(DCRN_DMASR, status_bits[dmanr]);
return DMA_STATUS_GOOD;
}
In "ppc4xx_sgdma.c"
-----------------------
int
ppc4xx_alloc_dma_handle(sgl_handle_t * phandle, unsigned int mode, unsigned int dmanr)
{
sgl_list_info_t *psgl = NULL;
ppc_dma_ch_t *p_dma_ch = &dma_channels[dmanr];
//uint32_t sg_command;
if (dmanr >= MAX_PPC4xx_DMA_CHANNELS) {
printk("ppc4xx_alloc_dma_handle: invalid channel 0x%x\n", dmanr);
return DMA_STATUS_BAD_CHANNEL;
}
if (!phandle) {
printk("ppc4xx_alloc_dma_handle: null handle pointer\n");
return DMA_STATUS_NULL_POINTER;
}
/* Get memory for the listinfo struct */
psgl = kmalloc(sizeof(sgl_list_info_t), GFP_KERNEL);
if (psgl == NULL) {
*phandle = (sgl_handle_t) NULL;
return DMA_STATUS_OUT_OF_MEMORY;
}
memset(psgl, 0, sizeof(sgl_list_info_t));
/* dma_addr is unused now */
psgl->dmanr = dmanr;
/*
* Modify and save the control word. These words will be
* written to each sgl descriptor. The DMA engine then
* loads this control word into the control register
* every time it reads a new descriptor.
*/
psgl->control = p_dma_ch->control;
/* Clear all mode bits */
psgl->control &= ~(DMA_TM_MASK | DMA_TD);
/* Save control word and mode */
psgl->control |= (mode | DMA_CE_ENABLE);
/* PPC Errata? DMA else ignore count on first in list */
psgl->control |= SET_DMA_TCE(1);
/* In MM mode, we must set ETD/TCE */
if (mode == DMA_MODE_MM)
psgl->control |= DMA_ETD_OUTPUT | DMA_TCE_ENABLE;
if (p_dma_ch->int_enable) {
/* Enable channel interrupt */
psgl->control |= DMA_CIE_ENABLE;
} else {
psgl->control &= ~DMA_CIE_ENABLE;
}
/* we must not touch the SGC, it can cause problems to other channels! */
psgl->sgl_control = SG_LINK;
if (p_dma_ch->int_enable) {
if (p_dma_ch->tce_enable)
{
/* reuse as Terminal Count Interrupt Enable on all descr. */
psgl->sgl_control |= SG_TCI_ENABLE;
}
psgl->sgl_control |= SG_ERI_ENABLE | SG_ETI_ENABLE;
}
*phandle = (sgl_handle_t) psgl;
return DMA_STATUS_GOOD;
}
void
ppc4xx_enable_dma_sgl(sgl_handle_t handle)
{
sgl_list_info_t *psgl = (sgl_list_info_t *) handle;
ppc_dma_ch_t *p_dma_ch;
uint32_t sg_command;
if (!handle) {
printk("ppc4xx_enable_dma_sgl: null handle\n");
return;
} else if (psgl->dmanr > (MAX_PPC4xx_DMA_CHANNELS - 1)) {
printk("ppc4xx_enable_dma_sgl: bad channel in handle %d\n",
psgl->dmanr);
return;
} else if (!psgl->phead) {
printk("ppc4xx_enable_dma_sgl: sg list empty\n");
return;
}
p_dma_ch = &dma_channels[psgl->dmanr];
psgl->ptail->control_count &= ~SG_LINK; /* make this the last dscrptr */
if (p_dma_ch->int_enable)
{
/* Require Terminal Count interrupt on last */
psgl->ptail->control_count |= SG_TCI_ENABLE;
}
/* No more changes to tail object allowed */
//dma_cache_wback((unsigned long)psgl->ptail, sizeof(ppc_sgl_t));
dma_cache_wback_inv((unsigned long)psgl->ptail, sizeof(ppc_sgl_t));
ppc4xx_set_sg_addr(psgl->dmanr, virt_to_phys(psgl->phead));
sg_command = 0;
switch (psgl->dmanr) {
case 0:
sg_command = SSG0_ENABLE | SSG0_MASK_ENABLE;
break;
case 1:
sg_command = SSG1_ENABLE | SSG1_MASK_ENABLE;
break;
case 2:
sg_command = SSG2_ENABLE | SSG2_MASK_ENABLE;
break;
case 3:
sg_command = SSG3_ENABLE | SSG3_MASK_ENABLE;
break;
default:
printk("ppc4xx_enable_dma_sgl: bad channel: %d\n", psgl->dmanr);
}
mtdcr(DCRN_ASGC, sg_command); /* start transfer */
}
void
ppc4xx_disable_dma_sgl(sgl_handle_t handle)
{
sgl_list_info_t *psgl = (sgl_list_info_t *) handle;
uint32_t sg_command;
if (!handle) {
printk("ppc4xx_disable_dma_sgl: null handle\n");
return;
} else if (psgl->dmanr > (MAX_PPC4xx_DMA_CHANNELS - 1)) {
printk("ppc4xx_disable_dma_sgl: bad channel in handle %d\n",
psgl->dmanr);
return;
}
sg_command = 0; //disable dma
switch (psgl->dmanr) {
case 0:
sg_command = SSG0_MASK_ENABLE;
break;
case 1:
sg_command = SSG1_MASK_ENABLE;
break;
case 2:
sg_command = SSG2_MASK_ENABLE;
break;
case 3:
sg_command = SSG3_MASK_ENABLE;
break;
default:
printk("ppc4xx_disable_dma_sgl: bad channel: %d\n", psgl->dmanr);
}
mtdcr(DCRN_ASGC, sg_command); /* stop transfer */
}
[-- Attachment #2: Type: text/html, Size: 28296 bytes --]
^ permalink raw reply
* Re: Video Card to Lite5200
From: Wolfgang Denk @ 2005-12-07 22:53 UTC (permalink / raw)
To: Frank Bennett; +Cc: linuxppc-embedded
In-Reply-To: <439752BE.9030207@digis.net>
In message <439752BE.9030207@digis.net> you wrote:
>
> The denx.de web site looks great.
Thanks :-)
> Where can someone get this PCI card? Do I have to contact Fujitsu
> directly? Cost?
I guess you have to contact Fujitsu directly; we worked with Fujitsu
Microelectronics Europe.
> The Fujitsu CoralP evaluation board MB86295EB01? or did you use the
Yes.
> Coral PA?
No.
> I saw a posting that you also had some streaming video running. Tell me
> more.
See ftp://ftp.denx.de/pub/fujitsu/Coral-P/README.html
> What resolution? 4CIF (full DVD)
> What display? LCD SVGA (800x600) and/or VGA analog port?
We used a 1024 x 768 LCD.
> Software MPEG decoder or does the Coral have a decoder?
There was no decoder involved at all. The CoralP can stream video
directly, without any CPU load :-) We used the "zvideo" application
for demos - see above.
> Which player did you use?
None. Just a video source like a standard DVD player or a camera.
> Is all this covered in some release notes?
See the README.html
> Was the katix stuff ever integrated into linux_2_4_development?
Yes, it was. See the drivers/spi/ diretory in our linuxppc_2_4_devel
tree, or
http://www.denx.de/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git;a=tree;h=464f005880de29947ee7d2d8941446c4ba76b0f8;hb=95300e1ab7d8a330784a882db868e355af6d638a;f=drivers/spi
> How does Wolfgang make a living if he spends all his time answering our
> questions?
Dunno. Next question, please :-)
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Bradley's Bromide: If computers get too powerful, we can organize
them into a committee - that will do them in.
^ permalink raw reply
* Re: Help needed : MCC driver for MPC8260 ADS
From: Manish Joshi @ 2005-12-08 0:09 UTC (permalink / raw)
To: Stevan Ignjatovic, linuxppc-embedded
In-Reply-To: <1133959955.3248.1.camel@stevan.iritel.co.yu>
[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]
This would also help you a lot.
http://www.ibiblio.org/gferg/ldp/MPC8260-MCC-HOWTO.txt
-Manish
Stevan Ignjatovic <stevan@iritel.com> wrote:
Start point for your MCC driver could be at
http://sourceforge.net/projects/mcc8260/
On Wed, 2005-12-07 at 11:41, s.maiti@tcs.com wrote:
> Hello All,
>
> For our project we need to have a MCC driver for MPC8260 ADS board. I
> couldn't find any driver in the linux source tree for the same.
> Any help in this regard will be highly appreciated.
> Thanks and regards,
>
> Souvik Maiti
> Tata Consultancy Services Limited
> Bengal Intelligent Park
> Bldg. - D, Plots - A2, M2 & N2
> Block - GP, Sector V
> Salt Lake Electronics Complex
> Kolkata - 700091, West Bengal
> India
> Mailto: s.maiti@tcs.com
> Website: http://www.tcs.com
> Notice: The information contained in this e-mail message and/or
> attachments to it may contain confidential or privileged information.
> If you are not the intended recipient, any dissemination, use, review,
> distribution, printing or copying of the information contained in this
> e-mail message and/or attachments to it are strictly prohibited. If
> you have received this communication in error, please notify us by
> reply e-mail or telephone and immediately and permanently delete the
> message and any attachments. Thank you
>
> ______________________________________________________________________
> _______________________________________________
> 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
---------------------------------
Yahoo! Shopping
Find Great Deals on Gifts at Yahoo! Shopping
[-- Attachment #2: Type: text/html, Size: 2463 bytes --]
^ permalink raw reply
* Re: Video Card to Lite5200
From: Alessandro Rubini @ 2005-12-08 0:25 UTC (permalink / raw)
To: blofeldus; +Cc: linuxppc-embedded
In-Reply-To: <20051207172321.77464.qmail@web53515.mail.yahoo.com>
> What is the status of the mpc5200 support? I see Sylvain's repository
> is still at 2.6.12 (5 months old).
I just published what I've done (on a previous 2.6.14-rc3 tree by Denx).
It's in ftp://gnudd.com/pub/patches/mpc5200/ (also http://).
I used Sylvain's FEC support, hacked a mb() to make PCI initialize
and ported PIO-mode IDE from 2.4 (with a gross hack about port addresses),
enabled some MTD configurations so cmdlineparts work fine.
/alessandro, who doesn't have a 5200 with him any more.
^ permalink raw reply
* Re: Video Card to Lite5200
From: White @ 2005-12-08 5:59 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051207172321.77464.qmail@web53515.mail.yahoo.com>
Am Wed, 7 Dec 2005 09:23:21 -0800 (PST) schrieb roger blofeld
<blofeldus@yahoo.com> :
> What is the status of the mpc5200 support? I see Sylvain's repository
> is still at 2.6.12 (5 months old).
>
> http://gitbits.246tnt.com/gitweb.cgi?p=linux-2.6-mpc52xx.git;a=summary
>
> The current kernel.org kernel doesn't appear to support fec/DMA. Is
> there a plan to get networking support into the mainstream kernel?
>
> Thanks
> -rb
>
i think Sylvians should be update in some days. I hope.
you can pull his rep. without problems on current 2.6.15-rc4.
DMA is a problem, because the implementation from Freescale use binary
data, and has some dirty points. This would never be included in the
mainstream kernel. Sylvian has included the new DMA .. works fine for
FEC.
If someone get this new implementtion running with AC97 or PCI would be
fine.
^ permalink raw reply
* patches in powerpc.git tree
From: Paul Mackerras @ 2005-12-08 6:22 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-dev
Here is a list of patches currently in the powerpc.git tree that
aren't already in Linus' tree.
Paul.
Adrian Bunk:
PPC_PREP: remove unneeded exports
Andy Whitcroft:
powerpc: powermac adb fix dependency on btext_drawchar
powerpc: powermac adb fix udbg_adb_use_btext warning
powerpc32: clean up available memory models
powerpc32: fix definition of distribute_irqs
Arnd Bergmann:
spufs: The SPU file system, base
spufs: cooperative scheduler support
spufs: Make all exports GPL-only
spufs: fix local store page refcounting
spufs: Fix oops when spufs module is not loaded
spufs: Turn off debugging output
spufs: Improved SPU preemptability.
spufs: Improved SPU preemptability [part 2].
spufs: fix mailbox polling
cell: add platform detection code
Benjamin Herrenschmidt:
powerpc: Merge align.c (#2)
powerpc: Add OF address parsing code (#2)
powerpc: serial port discovery (#2)
powerpc: Unify udbg (#2)
powerpc: Add back support for booting from BootX (#2)
powerpc: convert macio_asic to use prom_parse
powerpc: Fix g5 build with xmon
powerpc: More serial probe fixes (#2)
powerpc: udbg updates
powerpc: Update OF address parsers
powerpc: Fix a huge page bug
powerpc: Remove debug code in hash path
David Gibson:
powerpc: Remove imalloc.h
powerpc: Make hugepage mappings respect hint addresses
is_aligned_hugepage_range() cleanup
powerpc: Remove ItLpRegSave area from the paca
powerpc: Remove some unneeded fields from the paca
David Woodhouse:
syscall entry/exit revamp
ppc64 syscall_exit_work: call the save_nvgprs function, not its descriptor.
powerpc: serial port discovery: cope with broken firmware
Save NVGPRS in 32-bit signal frame
Fix code that saves NVGPRS in 32-bit signal frame
ppc: Make ARCH=ppc build again with new syscall path
Heiko J Schick:
powerpc: IBMEBUS bus support
Hugh Dickins:
mm: powerpc ptlock comments
mm: powerpc init_mm without ptlock
Kumar Gala:
powerpc: moved ipic code to arch/powerpc
powerpc: Add support for building uImages
powerpc: Fix suboptimal uImage target
linas:
powerpc/pseries: dlpar-add crash on null pointer deref
powerpc: minor cleanup of void ptr deref
Linas Vepstas:
powerpc: PCI hotplug common code elimination
powerpc: make pcibios_claim_one_bus available to other code
powerpc: migrate common PCI hotplug code
PCI Error Recovery: header file patch
powerpc: PCI Error Recovery: PPC64 core recovery routines
powerpc: Split out PCI address cache to its own file
powerpc: Add "partitionable endpoint" support
powerpc: remove bogus printk
powerpc: Remove duplicate code
powerpc: bugfix: fill in uninitialized field
powerpc: Use PE configuration address consistently
powerpc: set up the RTAS token just like the rest of them.
powerpc: Don't continue with PCI Error recovery if slot reset failed.
powerpc: handle multifunction PCI devices properly
powerpc: IOMMU: don't ioremap null addresses
powerpc: Save device BARs much earlier in the boot sequence
powerpc: get rid of per_cpu EEH counters
Marcelo Tosatti:
ppc32: m8xx watchdog update
powerpc/8xx: Fix m8xx_wdt issues
Mark Nutter:
spufs: switchable spu contexts
kernel-side context switch code for spufs
spufs: add spu-side context switch code
Michael Ellerman:
powerpc: Merge kexec
powerpc: Propagate regs through to machine_crash_shutdown
powerpc: Add a is_kernel_addr() macro
powerpc: Separate usage of KERNELBASE and PAGE_OFFSET
powerpc: Add CONFIG_CRASH_DUMP
powerpc: Create a trampoline for the fwnmi vectors
powerpc: Reroute interrupts from 0 + offset to PHYSICAL_START + offset
powerpc: Fixups for kernel linked at 32 MB
powerpc: Add arch dependent basic infrastructure for Kdump.
powerpc: Parse crashkernel= parameter in first kernel
powerpc: Add arch-dependent copy_oldmem_page
powerpc: Add support for "linux,usable-memory" on memory nodes
Michal Ostrowski:
powerpc/pseries: Fix TCE building with 64k pagesize
Mike Kravetz:
Remove SPAN_OTHER_NODES config definition
powerpc: Minor numa memory code cleanup
powerpc: Minor numa memory code cleanup
powerpc: numa placement for dynamically added memory
powerpc/pseries: boot failures on numa if no memory on node
Olaf Hering:
powerpc: correct the NR_CPUS description text
Olof Johansson:
powerpc: remove redundant code in stab init
Otavio Salvador:
ppc: removed unused variable i from code.
Paul Mackerras:
powerpc: Update __NR_syscalls to account for SPU syscalls
ppc: remove duplicate bseip.h
powerpc: Fix up some compile errors in the PCI error recovery code
powerpc/pseries: Optimize IOMMU setup
ppc: Build in all three of powermac, PREP and CHRP support
Revert "powerpc: Minor numa memory code cleanup"
powerpc: Fix typo in head_64.S
Stephen Rothwell:
powerpc: remove arch/powerpc/include hack for 64 bit
powerpc: cleanup iseries irq.c
powerpc: use end_IRQ for iseries irqs
powerpc: partly merge iseries do_IRQ
powerpc: reduce include in irq.c
powerpc: more iseries irq work
powerpc: fix for "Update OF address parsers"
^ permalink raw reply
* Re: patches in powerpc.git tree
From: Stephen Rothwell @ 2005-12-08 6:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <17303.53564.160668.376061@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
On Thu, 8 Dec 2005 17:22:52 +1100 Paul Mackerras <paulus@samba.org> wrote:
>
> Stephen Rothwell:
> powerpc: remove arch/powerpc/include hack for 64 bit
That one is in Linus' tree ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32: Add TQM85xx (8540/8541/8555/8560) board support
From: Kumar Gala @ 2005-12-08 7:13 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200512011430.48271.sr@denx.de>
On Dec 1, 2005, at 7:30 AM, Stefan Roese wrote:
> This patch adds support for the TQ Components TQM85xx modules.
> Currently the
> modules TQM8540/8541/8555/8560 are supported.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
>
> Best regards,
> Stefan
> <add-tqm85xx-board-support-2.patch>
Had a question on this, any reason you have to hookup the rtc with an
late_initcall()?
- kumar
^ permalink raw reply
* HR posix timers on mpc8xx??
From: David Jander @ 2005-12-08 8:55 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
With 2.6 now relatively stable running on mpc8xx, I was wondering if someone
has tried to patch in support for High-resolution Posix-timers, as from here:
http://sourceforge.net/projects/high-res-timers
It sounds really attractive, and I wonder why this still isn't officially part
of 2.6?
There is a patch for 2.6.10 for ppc, but I wonder if someone managed to port
it to 2.6.14 (or later) and runs it on an mpc8xx.
Greetings,
--
David Jander
^ permalink raw reply
* mpc823 SCC3 flow control bug
From: debora liu @ 2005-12-08 9:04 UTC (permalink / raw)
To: denx; +Cc: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
Hello denx:
I found one bug when SCC3 as UART, my cpu is mpc823.
cts/cd config as:
CTS PC5
CD PC4
your ELDK-3.1.1 linux-2.4.25 uart.c set pcpar,pcso, pcdir:
immap->im_ioport.iop_pcpar &= ~iobits;
immap->im_ioport.iop_pcso |= iobits;
immap->im_ioport.iop_pcdir &= ~iobits;
but MPC823UM tell me CD3 and CTS3 is bit6 and bit7 on PCSO register, so I modify:
fix_pcso = iobits;
#if defined(CONFIG_UART_CTS_CONTROL_SCC3)
fix_pcso &=~(1 << (15 - CONFIG_CTS3_PIN));
fix_pcso |= 0x0100;
#endif
#if defined(CONFIG_UART_CD_CONTROL_SCC3)
fix_pcso &=~(1 << (15 - CONFIG_CD3_PIN));
fix_pcso |= 0x0200;
#endif
immap->im_ioport.iop_pcpar &= ~iobits;
immap->im_ioport.iop_pcso |= fix_pcso;
immap->im_ioport.iop_pcdir &= ~iobits;
My board have success communication to moderm with SCC3 hard flow control.
debora liu
deboraliu@tom.com
2005-12-08
[-- Attachment #2: fox.gif --]
[-- Type: image/gif, Size: 9519 bytes --]
^ permalink raw reply
* Fix boot on some 12" powerbooks, need testers on others
From: Benjamin Herrenschmidt @ 2005-12-08 10:48 UTC (permalink / raw)
To: Guy Yasko; +Cc: linuxppc-dev list
In-Reply-To: <87bqzs5cio.fsf@oedipa.disorg>
This patch against 2.6.15-rc5 might help fixing boot on some recent
powerbooks like some 12" aluminium. However, I need urgently some
testers with other models of powerbooks and mac mini to tell me if it
causes any regression (that is before tomorrow) so it _might_ have a
chance to make it in 2.6.15.
Index: linux-work/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/feature.c 2005-11-19 10:56:07.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/feature.c 2005-12-08 21:45:30.000000000 +1100
@@ -1650,11 +1650,17 @@
*/
if (macio->type == macio_intrepid) {
- if (enable)
- UN_OUT(UNI_N_CLOCK_SPREADING, 2);
- else
- UN_OUT(UNI_N_CLOCK_SPREADING, 0);
- mdelay(40);
+ struct device_node *clock =
+ of_find_node_by_path("/uni-n@f8000000/hw-clock");
+ if (clock && get_property(clock, "platform-do-clockspreading",
+ NULL)) {
+ if (enable)
+ UN_OUT(UNI_N_CLOCK_SPREADING, 2);
+ else
+ UN_OUT(UNI_N_CLOCK_SPREADING, 0);
+ mdelay(40);
+ }
+ of_node_put(clock);
}
while (machine_is_compatible("PowerBook5,2") ||
Index: linux-work/arch/ppc/platforms/pmac_feature.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_feature.c 2005-11-14 20:32:16.000000000 +1100
+++ linux-work/arch/ppc/platforms/pmac_feature.c 2005-12-08 21:45:48.000000000 +1100
@@ -1606,11 +1606,17 @@
*/
if (macio->type == macio_intrepid) {
- if (enable)
- UN_OUT(UNI_N_CLOCK_SPREADING, 2);
- else
- UN_OUT(UNI_N_CLOCK_SPREADING, 0);
- mdelay(40);
+ struct device_node *clock =
+ of_find_node_by_path("/uni-n@f8000000/hw-clock");
+ if (clock && get_property(clock, "platform-do-clockspreading",
+ NULL)) {
+ if (enable)
+ UN_OUT(UNI_N_CLOCK_SPREADING, 2);
+ else
+ UN_OUT(UNI_N_CLOCK_SPREADING, 0);
+ mdelay(40);
+ }
+ of_node_put(clock);
}
while (machine_is_compatible("PowerBook5,2") ||
^ permalink raw reply
* Re: Fix boot on some 12" powerbooks, need testers on others
From: Michael Hanselmann @ 2005-12-08 11:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Guy Yasko, linuxppc-dev list
In-Reply-To: <1134038881.11760.11.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 208 bytes --]
> However, I need urgently some testers with other models of powerbooks
> and mac mini to tell me if it causes any regression [...]
Works for me on a PowerBook5,8 (15", 1.67 GHz, Oct 2005).
Greets,
Michael
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Netpoll controller support for PPC EMAC driver
From: Ruslan V. Sushko @ 2005-12-08 12:34 UTC (permalink / raw)
To: ebs; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 123 bytes --]
This patch adds netpoll controller support for PPC EMAC driver
Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>
[-- Attachment #2: ppc_emac_napi_netpoll.patch --]
[-- Type: text/x-patch, Size: 4097 bytes --]
This patch adds netpoll controller support for PPC EMAC driver
---
commit a482261f165edb7e6af363d13ea94e8e7429f085
tree b5bee5eb8a971c3f40867946225051e1ff320763
parent e4f5c82a92c2a546a16af1614114eec19120e40a
author Ruslan V. Sushko <rsushko@ru.mvista.com> Thu, 08 Dec 2005 15:22:38 +0300
committer Ruslan V. Sushko <rsushko@ru.mvista.com> Thu, 08 Dec 2005 15:22:38 +0300
drivers/net/ibm_emac/ibm_emac_core.c | 42 +++++++++++++++++++++++++++++++++-
drivers/net/ibm_emac/ibm_emac_mal.c | 14 -----------
drivers/net/ibm_emac/ibm_emac_mal.h | 12 ++++++++++
3 files changed, 53 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -1071,8 +1071,16 @@ static int emac_start_xmit(struct sk_buf
struct ocp_enet_private *dev = ndev->priv;
unsigned int len = skb->len;
int slot;
+ u16 ctrl;
- u16 ctrl = EMAC_TX_CTRL_GFCS | EMAC_TX_CTRL_GP | MAL_TX_CTRL_READY |
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ if (unlikely(dev->tx_cnt == NUM_TX_BUFF)) {
+ netif_stop_queue(ndev);
+ return -EBUSY;
+ }
+#endif
+
+ ctrl = EMAC_TX_CTRL_GFCS | EMAC_TX_CTRL_GP | MAL_TX_CTRL_READY |
MAL_TX_CTRL_LAST | emac_tx_csum(dev, skb);
slot = dev->tx_slot++;
@@ -1938,6 +1946,33 @@ static int emac_ioctl(struct net_device
return -EOPNOTSUPP;
}
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+void
+poll_ctrl(struct net_device *dev)
+{
+ int budget = 16;
+ struct ibm_ocp_mal *mal = ((struct ocp_enet_private*)(dev->priv))->mal;
+ struct net_device *poll_dev = &(mal->poll_dev);
+
+ /* disable MAL interrupts */
+ mal_disable_eob_irq(mal);
+ netif_poll_disable(poll_dev);
+
+ emac_poll_rx(dev->priv, budget);
+ emac_poll_tx(dev->priv);
+
+ netif_poll_enable(poll_dev);
+ /* Enable mal interrupts */
+ mal_enable_eob_irq(mal);
+}
+
+int
+poll_fake(struct net_device *dev, int *budget)
+{
+ /* It will be never invoked */
+ return 0;
+}
+#endif
static int __init emac_probe(struct ocp_device *ocpdev)
{
@@ -2188,6 +2223,11 @@ static int __init emac_probe(struct ocp_
netif_carrier_off(ndev);
netif_stop_queue(ndev);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ ndev->poll_controller = poll_ctrl;
+ ndev->poll = poll_fake;
+#endif
+
err = register_netdev(ndev);
if (err) {
printk(KERN_ERR "emac%d: failed to register net device (%d)!\n",
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.c b/drivers/net/ibm_emac/ibm_emac_mal.c
--- a/drivers/net/ibm_emac/ibm_emac_mal.c
+++ b/drivers/net/ibm_emac/ibm_emac_mal.c
@@ -155,20 +155,6 @@ void mal_poll_del(struct ibm_ocp_mal *ma
local_bh_enable();
}
-/* synchronized by mal_poll() */
-static inline void mal_enable_eob_irq(struct ibm_ocp_mal *mal)
-{
- MAL_DBG2("%d: enable_irq" NL, mal->def->index);
- set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) | MAL_CFG_EOPIE);
-}
-
-/* synchronized by __LINK_STATE_RX_SCHED bit in ndev->state */
-static inline void mal_disable_eob_irq(struct ibm_ocp_mal *mal)
-{
- set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) & ~MAL_CFG_EOPIE);
- MAL_DBG2("%d: disable_irq" NL, mal->def->index);
-}
-
static irqreturn_t mal_serr(int irq, void *dev_instance, struct pt_regs *regs)
{
struct ibm_ocp_mal *mal = dev_instance;
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h b/drivers/net/ibm_emac/ibm_emac_mal.h
--- a/drivers/net/ibm_emac/ibm_emac_mal.h
+++ b/drivers/net/ibm_emac/ibm_emac_mal.h
@@ -216,6 +216,18 @@ static inline void set_mal_dcrn(struct i
mtdcr(mal->dcrbase + reg, val);
}
+/* synchronized by mal_poll() */
+static inline void mal_enable_eob_irq(struct ibm_ocp_mal *mal)
+{
+ set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) | MAL_CFG_EOPIE);
+}
+
+/* synchronized by __LINK_STATE_RX_SCHED bit in ndev->state */
+static inline void mal_disable_eob_irq(struct ibm_ocp_mal *mal)
+{
+ set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) & ~MAL_CFG_EOPIE);
+}
+
/* Register MAL devices */
int mal_init(void) __init;
void mal_exit(void) __exit;
\f
!-------------------------------------------------------------flip-
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox