Re: [RFC PATCH 3/7 v2] ppc: do not search for dma-window property on dlpar remove

On 29.11.2010 [12:38:41 +1100], Benjamin Herrenschmidt wrote:
> On Tue, 2010-10-26 at 20:35 -0700, Nishanth Aravamudan wrote:
> > The iommu_table pointer in the pci auxiliary struct of device_node has
> > not been used by the iommu ops since the dma refactor of
> > 12d04eef927bf61328af2c7cbe756c96f98ac3bf, however this code still uses
> > it to find tables for dlpar. By only setting the PCI_DN iommu_table
> > pointer on nodes with dma window properties, we will be able to quickly
> > find the node for later checks, and can remove the table without looking
> > for the the dma window property on dlpar remove.
> 
> The answer might well be yes but are we sure this works with busses &
> devices that don't have a dma,window ? ie. we always properly look for
> parents when assigning pci devices arch_data iommu table ? Did you test
> it ?  (Best way is to find a card with a P2P bridge on it).

I haven't tested this particular case. I'm getting a machine to do so
now, though.

Thanks,
Nish

--

-- 
Nishanth Aravamudan <nacc <at> us.ibm.com>
IBM Linux Technology Center

Re: ppc_set_hwdebug vs ptrace_set_debugreg

On Mon, Nov 29, 2010 at 11:15:51AM +0100, Andreas Schwab wrote:
> "K.Prasad" <prasad <at> linux.vnet.ibm.com> writes:
> 
> > Although ppc_set_hwdebug() can set DABR through set_dabr() in
> > arch/powerpc/kernel/process.c, it is good to have it converted to use
> > register_user_hw_breakpoint().
> 
> What do you mean with "good to have"?  It doesn't work without it unless
> I disable PERF_EVENTS (which is the only way to disable
> HAVE_HW_BREAKPOINT).
> 
> Andreas.
>

Let me see if I can cook up a patch for this i.e. make set_dabr() invoke
register_user_hw_breakpoint() when CONFIG_PPC_BOOK3S is defined; before I
head out on my vacation (starting second week of this month).

Thanks,
K.Prasad

Re: [PATCH 01/13] powerpc/nvram: Move things out of asm/nvram.h

On Tue, 2010-11-30 at 16:47 +1100, benh <at> kernel.crashing.org wrote:
> From: Benjamin Herrenschmidt <benh <at> kernel.crashing.org>
> 
> This moves a bunch of definitions out of asm/nvram.h to the files
> that use them or just outright remove completely unused stuff.
> 
> We leave the partition signatures definitions, they will be useful
> 
> Signed-off-by: Benjamin Herrenschmidt <benh <at> kernel.crashing.org>

I applied the whole 13-patch set, and built and booted the result.
Seems fine.

Tested-by: Jim Keniston <jkenisto <at> us.ibm.com>

Jim

[MPC52xx]Latency issue with DMA on FEC

Hi lists !

I measured the latency and the jitter of the RX and TX ethernet paths
on my MPC5200 board.
The RX path is quite good, but the TX path can be slow.

[ 1218.976762] [mpc52xx_fec_start_xmit]Delay >30us for dma_map_single
=> 76364 ns
[ 1219.188405] [mpc52xx_fec_tx_interrupt]Delay >30us for
dma_unmap_single => 34515 ns
[ 1220.628785] [mpc52xx_fec_start_xmit]Delay >30us for
bcom_submit_next_buffer => 97273 ns
[ 1225.776784] [mpc52xx_fec_tx_interrupt]Delay >30us for
dma_unmap_single => 95273 ns

As one can see, this is obviously problematic.
The first function I analyzed is bcom_submit_next_buffer() => This
function doesn't do lots of things, except a call to mb().

I have been looking to the "MPC603e RISC Microprocessor User's Manual"
and especially the chapter named "2.3.4.7 Memory Synchronization
Instructions—UISA".

Here is a paragraph which explains a lot :

"The functions performed by the sync instruction normally take a
significant amount of time
to complete; as a result, frequent use of this instruction may
adversely affect performance.
In addition, the number of cycles required to complete a sync

Re: PHY/FEC Network adapter failed to initialize on MPC52xx Board

Tanks to all for the reply to this thread. I got the tip from the thread Tiejun
mentioned.

Quotation: 'St. Strobel' in Xenomai-help

"I had this problem too. In my case the problem was caused by an incorrect port multiplex configuration in
U-Boot, see CONIFG_SYS_GPS_PORT_CONFIG (I use 0x xxx5xxxx, which corresponds to 10/100Mbit
Eth with MD). "

That fixed it for me.

Regards, Peter

Am 29.11.2010 03:48, schrieb tiejun.chen:
> Peter wrote:
>> Hi all
>>
>> I got completely stuck with a network adapter problem on my
>> ppc board (MPC52xx style). The ntwork adapter does not seem
>> to intialize correctly when booted without 'help from uboot'
>>
> Looks your problem is very similar to one I replied here not long ago :) That is
> also issued from MPC5200. And I remember there was a wrong Port Multiplex
> Configuration.
>
> If possible maybe you can check the email subjected "Problem Ethernet
> Initialization MPC5200 +  LXT971A" on linuxppc-dev list.
>
> Hope its useful.

[PATCH] of/address: use propper endianess in get_flags

This patch changes u32 to __be32 for all "ranges", "prop" and "addr" and
such. Those variables are pointing to the device tree which containts
intergers in big endian format.
Most functions are doing it right because of_read_number() is doing the
right thing for them. of_bus_isa_get_flags(), of_bus_pci_get_flags() and
of_bus_isa_map() were accessing the data directly and were doing it wrong.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy <at> linutronix.de>
---
 arch/powerpc/include/asm/prom.h |    2 +-
 drivers/of/address.c            |   54 ++++++++++++++++++++------------------
 include/linux/of_address.h      |    6 ++--
 3 files changed, 32 insertions(+), 30 deletions(-)

diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index ae26f2e..ab34f60 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
 <at>  <at>  -42,7 +42,7  <at>  <at>  extern void pci_create_OF_bus_map(void);

 /* Translate a DMA address from device space to CPU space */
 extern u64 of_translate_dma_address(struct device_node *dev,
-				    const u32 *in_addr);
+				    const __be32 *in_addr);

 #ifdef CONFIG_PCI
 extern unsigned long pci_address_to_pio(phys_addr_t address);
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 3a1c7e7..b4559c5 100644
--- a/drivers/of/address.c

[PATCH] eSPI: change the read behavior of the SPIRF

The user must read N bytes of SPIRF (1 <= N <= 4) that do not exceed the
amount of data in the receive FIFO, so read the SPIRF byte by byte when
the data in receive FIFO is less than 4 bytes.

On Simics, when read N bytes that exceed the amout of data in receive
FIFO, we can't read the data out, that is we can't clear the rx FIFO,
then the CPU will loop on the espi rx interrupt.

Signed-off-by: Mingkai Hu <Mingkai.hu <at> freescale.com>
---
 drivers/spi/spi_fsl_espi.c |   19 ++++++++++++++++---
 1 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi_fsl_espi.c b/drivers/spi/spi_fsl_espi.c
index e3b4f64..ae78926 100644
--- a/drivers/spi/spi_fsl_espi.c
+++ b/drivers/spi/spi_fsl_espi.c
 <at>  <at>  -507,16 +507,29  <at>  <at>  void fsl_espi_cpu_irq(struct mpc8xxx_spi *mspi, u32 events)

 	/* We need handle RX first */
 	if (events & SPIE_NE) {
-		u32 rx_data;
+		u32 rx_data, tmp;
+		u8 rx_data_8;

 		/* Spin until RX is done */
 		while (SPIE_RXCNT(events) < min(4, mspi->len)) {
 			cpu_relax();
 			events = mpc8xxx_spi_read_reg(&reg_base->event);
 		}

Basic driver devel questions ?

Hello all,
is it OK if I ask basic driver development questions here ?
Could you recommend a better forum for that maybe ?
Thanks
--

-- 
Guillaume Dargaud
http://www.gdargaud.net/

Re: Basic driver devel questions ?

On Wed, 2010-12-01 at 11:15 +0100, Guillaume Dargaud wrote:
> Hello all,
> is it OK if I ask basic driver development questions here ?
> Could you recommend a better forum for that maybe ?

Hi Guillaume,

I guess it depends how basic they are :)

If they're basic _powerpc_ driver questions then this is probably the
right place.

But I'd say just ask and maybe someone will be able to help, or maybe
they'll point you somewhere else.

cheers

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev <at> lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev