LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* 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: 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

* 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: 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: 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: 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: 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: 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: 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: 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

* 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: 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

* 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: linux 2.4 on Xilinx ml403
From: Yoshio Kashiwagi @ 2005-12-07 11:31 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <259581790512070010s3be8b3cfg6cfd17d2f503b0f7@mail.gmail.com>

Hi,

libgen of EDK should generate the definition of
XPAR_INTC_0_SYSACE_0_VEC_ID as follows according to your design to
xparameters.h.

[snip]
#define XPAR_INTC_0_SYSACE_0_VEC_ID XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_
SYSACE_IRQ_INTR
[snip]

Have you copied xparameters.h which EDK generated to the kernel tree?

Best Regards,

Yoshio Kashiwagi

> Hi all,
> 
> I have been trying to run linux 2.4.26 on Virtex 4 for a while and 
without
> success.
> 
> I am trying to implement a simple design, with an UART, SystemACE and
> everything interrupt driven. When I try to make bzImage, there is an 
error
> in (SysACE) adapter.c file, because XPAR_INTC_0_SYSACE_0_VEC_ID is not
> defined.
> 
> I have applied the patch given by Xilinx for switching from the ml300 
to the
> ml403, which copies the bsp, .config and xparameter files into the 
kernel.
> 
> I am stucked here, and do not know how to keep going from that.
> Could anyone help me a little bit?
> 
> Thanks and have a good day!
> 

^ permalink raw reply

* Help required on mpc8260 kernel boot
From: batsayan.das @ 2005-12-07  9:50 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]


Hello,

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

I copied the kernel image at 0x30000000 by kermit. The load address and 
the entry point of the UImage is set at 0x34000000 and 0x34000000. At 
U-boot prompt when I run "bootm 0x30000000" . The kernel hangs with the 
message " Uncompressing Kernel Image..OK" 

My questions are

1. Is the above memory configuration is correct to run kernel from RAM 
U-boot?
2. The U-Boot documentation says that SDRAM should be at 0.  Does the 
kernel will run if SDRAM is not set to 0?
3. How can I debug where in kernel source tree it got hanged? 


Any pointer will be helpful. Thanks in advance.

Regards,
Batsayan Das
Tata Consultancy Services Limited
Mailto: batsayan.das@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

[-- Attachment #2: Type: text/html, Size: 2130 bytes --]

^ permalink raw reply

* Help needed : MCC driver for MPC8260 ADS
From: s.maiti @ 2005-12-07 10:41 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20051207061210.C32AD68896@ozlabs.org>

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]


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

[-- Attachment #2: Type: text/html, Size: 1325 bytes --]

^ permalink raw reply

* Re: no IRQ from USB on MPC8248
From: Mike Rapoport @ 2005-12-07  8:58 UTC (permalink / raw)
  To: Nathael PAJANI; +Cc: linuxppc-embedded
In-Reply-To: <4395AA59.5030209@cpe.fr>

Nathael PAJANI wrote:

[snip]

> which means the hub detects a device, and tries to configure it.

The root hub is virtual and implemented in SW. It detects the device any 
time there's a pull-up on one of the D+ or D- lines, no matter if 
controller is working properly or not.

>
> second: the device is happy to see a request and replies correctly.... 
> but there's no interrupt fired, whether using SUI_INT_USB (==11) or 
> the SCC3 interrupt (==42)
>
Make sure you've adopted the following functions to your board:
    static int board_configure(struct m8xxhci_private *hp)
    static int setup_usb_clock(struct m8xxhci_private *hp)
so the controller will get proper USB clock.

-- 
Sincerely yours,
Mike Rapoport

^ permalink raw reply

* linux 2.4 on Xilinx ml403
From: Paulinha @ 2005-12-07  8:10 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

Hi all,

I have been trying to run linux 2.4.26 on Virtex 4 for a while and without
success.

I am trying to implement a simple design, with an UART, SystemACE and
everything interrupt driven. When I try to make bzImage, there is an error
in (SysACE) adapter.c file, because XPAR_INTC_0_SYSACE_0_VEC_ID is not
defined.

I have applied the patch given by Xilinx for switching from the ml300 to the
ml403, which copies the bsp, .config and xparameter files into the kernel.

I am stucked here, and do not know how to keep going from that.
Could anyone help me a little bit?

Thanks and have a good day!

[-- Attachment #2: Type: text/html, Size: 668 bytes --]

^ permalink raw reply

* MPC8245 with its internal UART
From: Heiko Schocher @ 2005-12-07  7:33 UTC (permalink / raw)
  To: linuxppc-embedded

Hello,

> Who can tell me which flatform is similar to mine ? I've tried
> "make sandpoint_defconfig", but seems not the right one.

If you want to use Linux 2.4.25, you can try CPC45_defconfig
from the Denx Kernel ...

Best regards,
Heiko

^ permalink raw reply

* MPC8245 with its internal UART
From: Heiko Schocher @ 2005-12-07  7:36 UTC (permalink / raw)
  To: linuxppc-embedded; +Cc: happyphot

Hello,

> Who can tell me which flatform is similar to mine ? I've tried
> "make sandpoint_defconfig", but seems not the right one.

If you want to use Linux 2.4.25, you can try CPC45_defconfig
from the Denx Kernel ...

Best regards,
Heiko

^ permalink raw reply

* Re: [PATCH 5/5] ppc32: Add PCI-X support for Yucca board
From: Roland Dreier @ 2005-12-07  5:16 UTC (permalink / raw)
  To: Ruslan V. Sushko; +Cc: linuxppc-embedded
In-Reply-To: <1133873451.16347.47.camel@mephisto.spb.rtsoft.ru>

Looks good.  Matt, please apply.

 - R.

^ permalink raw reply

* Re: [PATCH 4/5] ppc32: Fix the PCI bus numbering assignment for Yucca PCI initialization.
From: Roland Dreier @ 2005-12-07  5:15 UTC (permalink / raw)
  To: Ruslan V. Sushko; +Cc: linuxppc-embedded
In-Reply-To: <1133873432.16347.45.camel@mephisto.spb.rtsoft.ru>

Looks good.  Matt, please apply.

 - R.

^ permalink raw reply

* Re: [PATCH 3/5] ppc32: Fix config space address calculation for Yucca PCIE initialization
From: Roland Dreier @ 2005-12-07  5:15 UTC (permalink / raw)
  To: Ruslan V. Sushko; +Cc: rollandd, linuxppc-embedded
In-Reply-To: <1133873425.16347.43.camel@mephisto.spb.rtsoft.ru>

Looks good.  Matt, please apply.

 - R.

^ permalink raw reply

* Re: [PATCH 1/5] ppc32: Removes dead code from original Yucca PCIE initialization sequence
From: Roland Dreier @ 2005-12-07  5:13 UTC (permalink / raw)
  To: Ruslan V. Sushko; +Cc: linuxppc-embedded
In-Reply-To: <1133873322.16347.39.camel@mephisto.spb.rtsoft.ru>

Looks good.  Matt, please apply.

 - R.

^ permalink raw reply

* Re: [PATCH 2/5] ppc32: verbose error checking for Yucca PCIE initialization
From: Roland Dreier @ 2005-12-07  5:17 UTC (permalink / raw)
  To: Ruslan V. Sushko; +Cc: linuxppc-embedded
In-Reply-To: <1133873391.16347.42.camel@mephisto.spb.rtsoft.ru>

    Ruslan> I haven't saw any error but this is potential issue
    Ruslan> because this flag asserts only then PCI Express port
    Ruslan> initialization is completed. I guess the initialization
    Ruslan> sequences assumes time using. Therefore the error may
    Ruslan> appears in future revision of the boards if Core clock
    Ruslan> will grow up.  Nevertheless I do not know the time which
    Ruslan> is necessary for completeness, so I add this just to be
    Ruslan> safe.

Hmm, I guess this is OK.  Matt, go ahead and apply this.

 - R.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox