* Re: [PATCH] SC26XX: New serial driver for SC2681 uarts
From: Pekka Enberg @ 2007-12-22 9:47 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Andrew Morton, linux-kernel, linux-mips, Andy Whitcroft, Alan Cox
In-Reply-To: <20071205092506.GA6691@alpha.franken.de>
Hi Thomas,
On Dec 5, 2007 11:25 AM, Thomas Bogendoerfer <tsbogend@alpha.franken.de> wrote:
> > These:
> >
> > > +#define READ_SC(p, r) readb((p)->membase + RD_##r)
> > > +#define WRITE_SC(p, r, v) writeb((v), (p)->membase + WR_##r)
> >
> > and these:
> >
> > > +#define READ_SC_PORT(p, r) read_sc_port(p, RD_PORT_##r)
> > > +#define WRITE_SC_PORT(p, r, v) write_sc_port(p, WR_PORT_##r, v)
> >
> > really don't need to exist. All they do is make the code harder to read.
>
> but they make the code safer. The chip has common register and port
> registers, which are randomly splattered over the address range. And
> some of them are read only, some write only. Read only and Write
> only register live at the same register offset and their function
> usually doesn't have anything in common. By using these macros I'll
> get compile errors when doing a READ_SC from a write only register
> and vice versa. I will also get compile errors, if I try to access a
> common register via READ_SC_PORT/WRITE_SC_PORT.
You can use grep to make sure there are no reads to a write-only
register. What you have there is not safety but macro obfuscation at
its best. It makes the code harder to read for anyone not intimately
familiar with the driver.
^ permalink raw reply
* Re: [PATCH] SC26XX: New serial driver for SC2681 uarts
From: Andy Whitcroft @ 2007-12-21 17:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: Thomas Bogendoerfer, linux-kernel, linux-mips, Alan Cox
In-Reply-To: <20071203155317.772231f9.akpm@linux-foundation.org>
On Mon, Dec 03, 2007 at 03:53:17PM -0800, Andrew Morton wrote:
> > +#define READ_SC(p, r) readb ((p)->membase + RD_##r)
> > +#define WRITE_SC(p, r, v) writeb ((v), (p)->membase + WR_##r)
>
> No space before the (. checkpatch misses this.
Yep, over careful in the special case for the parameters for #define
macros, which have different spacing rules. This will be fixed in 0.13:
WARNING: no space between function name and open parenthesis '('
#1: FILE: Z45.c:1:
+#define WRITE_SC(p, r, v) writeb ((v), (p)->membase + WR_##r)
-apw
^ permalink raw reply
* Re: [PATCH][MIPS] fix user_cpus_allowed assignment
From: Ralf Baechle @ 2007-12-21 1:11 UTC (permalink / raw)
To: Kevin D. Kissell; +Cc: Pavel Kiryukhin, linux-mips
In-Reply-To: <017c01c840cb$7a5049c0$10eca8c0@grendel>
On Mon, Dec 17, 2007 at 05:40:03PM +0100, Kevin D. Kissell wrote:
> This looks to be a correct fix. Long term, we really do need to convince
> the scheduler maintainer to provide hooks that will allow hardware-driven
> affinity to be integrated with application-driven affinity in a sensible way,
> without requiring replication (and replicated maintenence) of the system
> call code in private copies like this. I asked for such hooks in sched.c
> when it first became apparent that dynamic FPU affinity was desirable,
> but was blown off at that time, so, with regret, I perpetrated the local copy
> hack. But it's silly, and MIPS can't possibly be the only architecture where
> Linux is used in systems with assymmetric resources where adaptive affinity
> is useful.
I dare to speculate that the new job of a certain Mike Uhler may increase
the need for such a scheduler feature :-)
Ralf
^ permalink raw reply
* Re: [directfb-dev] Error in running gtk example on cross compiled GTK with DirectFB on MIPS board
From: Mike Emmel @ 2007-12-20 19:09 UTC (permalink / raw)
To: kaka
Cc: Denis Oliver Kropp, linux-mips, uclinux-dev, linux-fbdev-users,
directfb-dev, celinux-dev, directfb-users
In-Reply-To: <eea8a9c90712201008n37a9a759j6dcee5ee067f918a@mail.gmail.com>
I suspect this is related to the creation of a top level ARGB surface
when gtk is initialized.
You probably should dig around a bit but it looks to me like its a
issue with surface formats.
Since your doing the driver you should try and make sure that you get
a accelerated surface
working for Gtk/Cairo this would need to be either RGB/ARGB because of
limited pixel
format support in Cairo.
gdk_display_open in
gdkdisplay-directfb.c
See how it finally initializes and I suspect that if you do the same
in a simple DirectFB app you get the black screen
and can debug.
On Dec 20, 2007 10:08 AM, kaka <share.kt@gmail.com> wrote:
> Hi Denis,
>
> I am writing gfx driver for DirectFB on BroadCom chip.
> Right now i am using FBdev system to display graphics on BCM chip(MIPS
> platform) which should use software fallbacks from DirectFB.Later on i 'll
> add hardware accelerartion also.
> My framebuffer driver for BCM chip is working fine. I have checked it by
> running a small example. Also the gfxdriver for directFB is working fine for
> Video and Image.
> The problem which i am facing right now is that i am running the fill
> rectangle example.
> IT is not filling any color in the rectangle. I am always getting the black
> screen.
>
> Could you plz provide some clue on it ?
> Also could you plz specify the file name and function in which directFB
> library is writing into the framebuffer memory the color pixel information?
>
> Thanks in Advance.
> kaka
>
>
>
> On 12/17/07, Denis Oliver Kropp <dok@directfb.org> wrote:
>
> > kaka wrote:
> > > HI ALL,
> > >
> > > We have successfully cross compiled GTK and DIRECTFB with all its
> > > dependencies for MIPS board.
> > > On running the basic test example of GTK, it is getting struck in the
> thread
> > > loop infinitely.
> > > We had put the "debug printf" statement in the gtkmain.c and debugged
> the
> > > test example.
> > > It is getting struck in the * g_main_loop_run (loop);* given below is
> > > the code(code
> > > snippet from gtkmain.c)
> > >
> > > void
> > > gtk_main (void)
> > > {
> > > GList *tmp_list;
> > > GList *functions;
> > > GtkInitFunction *init;
> > > GMainLoop *loop;
> > > printf("\n%s :: %d\n",__FILE__,__LINE__);
> > > gtk_main_loop_level++;
> > >
> > > loop = g_main_loop_new (NULL, TRUE);
> > > main_loops = g_slist_prepend (main_loops, loop);
> > > printf("\n%s :: %d\n",__FILE__,__LINE__);
> > > tmp_list = functions = init_functions;
> > > init_functions = NULL;
> > >
> > > while (tmp_list)
> > > {
> > > init = tmp_list->data;
> > > tmp_list = tmp_list->next;
> > >
> > > (* init->function) (init->data);
> > > g_free (init);
> > > }
> > > g_list_free (functions);
> > > printf("\n%s :: %d\n",__FILE__,__LINE__);
> > > if (g_main_loop_is_running (main_loops->data))
> > > {
> > > * printf("\n%s :: %d\n",__FILE__,__LINE__);
> > > GDK_THREADS_LEAVE ();
> > > g_main_loop_run (loop);
> > > GDK_THREADS_ENTER ();
> > > * printf("\n%s :: %d\n",__FILE__,__LINE__);
> >
> > That's normal. If you want runtime you have to create a timer or register
> idle or timeout functions.
> >
> > > gtk_container_add (GTK_CONTAINER (window), pMainWidget);
> > > printf("\n\n\ngtk_container_add (GTK_CONTAINER (window),
> > > pMainWidget);\n\n\n") ;
> > > gtk_widget_show (window);
> > > printf("\n\n\nABHISHEK START OF gtk_main\n\n\n");
> > > gtk_main ();
> > > printf("\n\n\nABHISHEK END OF gtk_main\n\n\n");
> > > return 0;
> >
> > Simply/weakly put: it should not return before the application is quit.
> >
> > --
> > Best regards,
> > Denis Oliver Kropp
> >
> > .------------------------------------------.
> > | DirectFB - Hardware accelerated graphics |
> > | http://www.directfb.org/ |
> > "------------------------------------------"
> >
>
>
>
> --
> Thanks & Regards,
> kaka
> _______________________________________________
> directfb-dev mailing list
> directfb-dev@directfb.org
> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
>
>
^ permalink raw reply
* Fill rectangle is not filling the screen with the COLOR(ALways filling the screen with Black color)
From: kaka @ 2007-12-20 18:11 UTC (permalink / raw)
To: Denis Oliver Kropp
Cc: linux-mips, uclinux-dev, celinux-dev, linux-fbdev-users,
directfb-users, directfb-dev
[-- Attachment #1: Type: text/plain, Size: 3309 bytes --]
>
> Hi Denis,
>
> I am writing gfx driver for DirectFB on BroadCom chip.
> Right now i am using FBdev system to display graphics on BCM chip(MIPS
> platform) which should use software fallbacks from DirectFB.Later on i
> 'll add hardware accelerartion also.
> My framebuffer driver for BCM chip is working fine. I have checked it by
> running a small example. Also the gfxdriver for directFB is working fine for
> Video and Image.
> The problem which i am facing right now is that i am running the fill
> rectangle example.
> IT is not filling any color in the rectangle. I am always getting the
> black screen.
>
> Could you plz provide some clue on it ?
> Also could you plz specify the file name and function in which directFB
> library is writing into the framebuffer memory the color pixel information?
>
> Thanks in Advance.
> kaka
>
>
>
> On 12/17/07, Denis Oliver Kropp <dok@directfb.org> wrote:
> >
> > kaka wrote:
> > > HI ALL,
> > >
> > > We have successfully cross compiled GTK and DIRECTFB with all its
> > > dependencies for MIPS board.
> > > On running the basic test example of GTK, it is getting struck in the
> > thread
> > > loop infinitely.
> > > We had put the "debug printf" statement in the gtkmain.c and
> > debugged the
> > > test example.
> > > It is getting struck in the * g_main_loop_run (loop);* given below is
> > > the code(code
> > > snippet from gtkmain.c)
> > >
> > > void
> > > gtk_main (void)
> > > {
> > > GList *tmp_list;
> > > GList *functions;
> > > GtkInitFunction *init;
> > > GMainLoop *loop;
> > > printf("\n%s :: %d\n",__FILE__,__LINE__);
> > > gtk_main_loop_level++;
> > >
> > > loop = g_main_loop_new (NULL, TRUE);
> > > main_loops = g_slist_prepend (main_loops, loop);
> > > printf("\n%s :: %d\n",__FILE__,__LINE__);
> > > tmp_list = functions = init_functions;
> > > init_functions = NULL;
> > >
> > > while (tmp_list)
> > > {
> > > init = tmp_list->data;
> > > tmp_list = tmp_list->next;
> > >
> > > (* init->function) (init->data);
> > > g_free (init);
> > > }
> > > g_list_free (functions);
> > > printf("\n%s :: %d\n",__FILE__,__LINE__);
> > > if (g_main_loop_is_running (main_loops->data))
> > > {
> > > * printf("\n%s :: %d\n",__FILE__,__LINE__);
> > > GDK_THREADS_LEAVE ();
> > > g_main_loop_run (loop);
> > > GDK_THREADS_ENTER ();
> > > * printf("\n%s :: %d\n",__FILE__,__LINE__);
> >
> > That's normal. If you want runtime you have to create a timer or
> > register idle or timeout functions.
> >
> > > gtk_container_add (GTK_CONTAINER (window), pMainWidget);
> > > printf("\n\n\ngtk_container_add (GTK_CONTAINER (window),
> > > pMainWidget);\n\n\n") ;
> > > gtk_widget_show (window);
> > > printf("\n\n\nABHISHEK START OF gtk_main\n\n\n");
> > > gtk_main ();
> > > printf("\n\n\nABHISHEK END OF gtk_main\n\n\n");
> > > return 0;
> >
> > Simply/weakly put: it should not return before the application is quit.
> >
> > --
> > Best regards,
> > Denis Oliver Kropp
> >
> > .------------------------------------------.
> > | DirectFB - Hardware accelerated graphics |
> > | http://www.directfb.org/ |
> > "------------------------------------------"
> >
>
>
>
> --
> Thanks & Regards,
> kaka
--
Thanks & Regards,
kaka
[-- Attachment #2: Type: text/html, Size: 5107 bytes --]
^ permalink raw reply
* Re: [directfb-dev] Error in running gtk example on cross compiled GTK with DirectFB on MIPS board
From: kaka @ 2007-12-20 18:08 UTC (permalink / raw)
To: Denis Oliver Kropp
Cc: linux-mips, uclinux-dev, celinux-dev, linux-fbdev-users,
directfb-users, directfb-dev
In-Reply-To: <4766B149.5050109@directfb.org>
[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]
Hi Denis,
I am writing gfx driver for DirectFB on BroadCom chip.
Right now i am using FBdev system to display graphics on BCM chip(MIPS
platform) which should use software fallbacks from DirectFB.Later on i 'll
add hardware accelerartion also.
My framebuffer driver for BCM chip is working fine. I have checked it by
running a small example. Also the gfxdriver for directFB is working fine for
Video and Image.
The problem which i am facing right now is that i am running the fill
rectangle example.
IT is not filling any color in the rectangle. I am always getting the black
screen.
Could you plz provide some clue on it ?
Also could you plz specify the file name and function in which directFB
library is writing into the framebuffer memory the color pixel information?
Thanks in Advance.
kaka
On 12/17/07, Denis Oliver Kropp <dok@directfb.org> wrote:
>
> kaka wrote:
> > HI ALL,
> >
> > We have successfully cross compiled GTK and DIRECTFB with all its
> > dependencies for MIPS board.
> > On running the basic test example of GTK, it is getting struck in the
> thread
> > loop infinitely.
> > We had put the "debug printf" statement in the gtkmain.c and debugged
> the
> > test example.
> > It is getting struck in the * g_main_loop_run (loop);* given below is
> > the code(code
> > snippet from gtkmain.c)
> >
> > void
> > gtk_main (void)
> > {
> > GList *tmp_list;
> > GList *functions;
> > GtkInitFunction *init;
> > GMainLoop *loop;
> > printf("\n%s :: %d\n",__FILE__,__LINE__);
> > gtk_main_loop_level++;
> >
> > loop = g_main_loop_new (NULL, TRUE);
> > main_loops = g_slist_prepend (main_loops, loop);
> > printf("\n%s :: %d\n",__FILE__,__LINE__);
> > tmp_list = functions = init_functions;
> > init_functions = NULL;
> >
> > while (tmp_list)
> > {
> > init = tmp_list->data;
> > tmp_list = tmp_list->next;
> >
> > (* init->function) (init->data);
> > g_free (init);
> > }
> > g_list_free (functions);
> > printf("\n%s :: %d\n",__FILE__,__LINE__);
> > if (g_main_loop_is_running (main_loops->data))
> > {
> > * printf("\n%s :: %d\n",__FILE__,__LINE__);
> > GDK_THREADS_LEAVE ();
> > g_main_loop_run (loop);
> > GDK_THREADS_ENTER ();
> > * printf("\n%s :: %d\n",__FILE__,__LINE__);
>
> That's normal. If you want runtime you have to create a timer or register
> idle or timeout functions.
>
> > gtk_container_add (GTK_CONTAINER (window), pMainWidget);
> > printf("\n\n\ngtk_container_add (GTK_CONTAINER (window),
> > pMainWidget);\n\n\n") ;
> > gtk_widget_show (window);
> > printf("\n\n\nABHISHEK START OF gtk_main\n\n\n");
> > gtk_main ();
> > printf("\n\n\nABHISHEK END OF gtk_main\n\n\n");
> > return 0;
>
> Simply/weakly put: it should not return before the application is quit.
>
> --
> Best regards,
> Denis Oliver Kropp
>
> .------------------------------------------.
> | DirectFB - Hardware accelerated graphics |
> | http://www.directfb.org/ |
> "------------------------------------------"
>
--
Thanks & Regards,
kaka
[-- Attachment #2: Type: text/html, Size: 4644 bytes --]
^ permalink raw reply
* Re: [MIPS] Build an embedded initramfs into mips kernel
From: Alon Bar-Lev @ 2007-12-19 18:46 UTC (permalink / raw)
To: Willy Tarreau; +Cc: H. Peter Anvin, linux-mips, LKML
In-Reply-To: <20071218224702.GI15227@1wt.eu>
Thank you for your help.
Indeed the dynamic loader of uclibc is the cause.
I upgraded to latest uclibc-0.9.29, and finally the files was linked
against uclibc's ld.
But it did not work...
Tried to run a dynamic linked executable via static shell, and got
floating point exception.
Tried to compile toolchain and uclibc with softfloat, but still did not work.
So I moved to glibc and all works correctly.
Thank you for quick response!
I will continue the discussion at uclibc lists.
Best Regards,
Alon Bar-Lev.
On 12/19/07, Willy Tarreau <w@1wt.eu> wrote:
> On Wed, Dec 19, 2007 at 12:09:46AM +0200, Alon Bar-Lev wrote:
> > On 12/18/07, H. Peter Anvin <hpa@zytor.com> wrote:
> > > Make sure your /init doesn't depend on an interpreter or library which
> > > isn't available.
> >
> > Thank you for your answer.
> >
> > I already checked.
> >
> > /init is hardlink to busybox, it depends on libc.so.0 which is available at /lib
>
> Are you sure that libc.so.0 is enough and that you don't need any ld.so ?
>
> > But shouldn't I get a different error code if this is the case?
>
> If it does not find part of the dynamic linker or libraries, this error
> makes sense to me.
>
> You should try to build a static init with any stupid thing such as a
> hello world to ensure that the problem really comes from the init and
> nothing else.
>
> Regards,
> Willy
>
>
^ permalink raw reply
* Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28
From: Ralf Baechle @ 2007-12-19 17:27 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: Jeff Garzik, netdev, linux-mips
In-Reply-To: <20071219124235.GA7550@alpha.franken.de>
On Wed, Dec 19, 2007 at 01:42:36PM +0100, Thomas Bogendoerfer wrote:
> - Use inline functions for dma_sync_* instead of macros
> - added Kconfig change to make selection for similair SGI boxes easier
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Ralf
^ permalink raw reply
* Re: [MIPS] Build an embedded initramfs into mips kernel
From: Alex Gonzalez @ 2007-12-19 14:53 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20071218224702.GI15227@1wt.eu>
Hi,
I have a detailed description of the process I went through at my blog
http://www.langabe.org/2007/10/adding-initramfs-support-to-linux.html
It might help you to compare notes.
Alex
On Dec 18, 2007 10:47 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Wed, Dec 19, 2007 at 12:09:46AM +0200, Alon Bar-Lev wrote:
> > On 12/18/07, H. Peter Anvin <hpa@zytor.com> wrote:
> > > Make sure your /init doesn't depend on an interpreter or library which
> > > isn't available.
> >
> > Thank you for your answer.
> >
> > I already checked.
> >
> > /init is hardlink to busybox, it depends on libc.so.0 which is available at /lib
>
> Are you sure that libc.so.0 is enough and that you don't need any ld.so ?
>
> > But shouldn't I get a different error code if this is the case?
>
> If it does not find part of the dynamic linker or libraries, this error
> makes sense to me.
>
> You should try to build a static init with any stupid thing such as a
> hello world to ensure that the problem really comes from the init and
> nothing else.
>
> Regards,
> Willy
>
>
>
^ permalink raw reply
* Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28
From: Thomas Bogendoerfer @ 2007-12-19 12:42 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-mips, ralf
In-Reply-To: <476867F5.3070006@pobox.com>
- Use inline functions for dma_sync_* instead of macros
- added Kconfig change to make selection for similair SGI boxes easier
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
drivers/net/Kconfig | 2 +-
drivers/net/sgiseeq.c | 64 ++++++++++++++++++++++++++-----------------------
2 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 84df799..f816798 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1807,7 +1807,7 @@ config DE620
config SGISEEQ
tristate "SGI Seeq ethernet controller support"
- depends on SGI_IP22
+ depends on SGI_HAS_SEEQ
help
Say Y here if you have an Seeq based Ethernet network card. This is
used in many Silicon Graphics machines.
diff --git a/drivers/net/sgiseeq.c b/drivers/net/sgiseeq.c
index 3145ca1..c69bb8b 100644
--- a/drivers/net/sgiseeq.c
+++ b/drivers/net/sgiseeq.c
@@ -56,14 +56,6 @@ static char *sgiseeqstr = "SGI Seeq8003";
(dma_addr_t)((unsigned long)(v) - \
(unsigned long)((sp)->rx_desc)))
-#define DMA_SYNC_DESC_CPU(dev, addr) \
- do { dma_cache_sync((dev)->dev.parent, (void *)addr, \
- sizeof(struct sgiseeq_rx_desc), DMA_FROM_DEVICE); } while (0)
-
-#define DMA_SYNC_DESC_DEV(dev, addr) \
- do { dma_cache_sync((dev)->dev.parent, (void *)addr, \
- sizeof(struct sgiseeq_rx_desc), DMA_TO_DEVICE); } while (0)
-
/* Copy frames shorter than rx_copybreak, otherwise pass on up in
* a full sized sk_buff. Value of 100 stolen from tulip.c (!alpha).
*/
@@ -116,6 +108,18 @@ struct sgiseeq_private {
spinlock_t tx_lock;
};
+static inline void dma_sync_desc_cpu(struct net_device *dev, void *addr)
+{
+ dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
+ DMA_FROM_DEVICE);
+}
+
+static inline void dma_sync_desc_dev(struct net_device *dev, void *addr)
+{
+ dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
+ DMA_TO_DEVICE);
+}
+
static inline void hpc3_eth_reset(struct hpc3_ethregs *hregs)
{
hregs->reset = HPC3_ERST_CRESET | HPC3_ERST_CLRIRQ;
@@ -184,7 +188,7 @@ static int seeq_init_ring(struct net_device *dev)
/* Setup tx ring. */
for(i = 0; i < SEEQ_TX_BUFFERS; i++) {
sp->tx_desc[i].tdma.cntinfo = TCNTINFO_INIT;
- DMA_SYNC_DESC_DEV(dev, &sp->tx_desc[i]);
+ dma_sync_desc_dev(dev, &sp->tx_desc[i]);
}
/* And now the rx ring. */
@@ -203,10 +207,10 @@ static int seeq_init_ring(struct net_device *dev)
sp->rx_desc[i].rdma.pbuf = dma_addr;
}
sp->rx_desc[i].rdma.cntinfo = RCNTINFO_INIT;
- DMA_SYNC_DESC_DEV(dev, &sp->rx_desc[i]);
+ dma_sync_desc_dev(dev, &sp->rx_desc[i]);
}
sp->rx_desc[i - 1].rdma.cntinfo |= HPCDMA_EOR;
- DMA_SYNC_DESC_DEV(dev, &sp->rx_desc[i - 1]);
+ dma_sync_desc_dev(dev, &sp->rx_desc[i - 1]);
return 0;
}
@@ -341,7 +345,7 @@ static inline void sgiseeq_rx(struct net_device *dev, struct sgiseeq_private *sp
/* Service every received packet. */
rd = &sp->rx_desc[sp->rx_new];
- DMA_SYNC_DESC_CPU(dev, rd);
+ dma_sync_desc_cpu(dev, rd);
while (!(rd->rdma.cntinfo & HPCDMA_OWN)) {
len = PKT_BUF_SZ - (rd->rdma.cntinfo & HPCDMA_BCNT) - 3;
dma_unmap_single(dev->dev.parent, rd->rdma.pbuf,
@@ -397,16 +401,16 @@ memory_squeeze:
/* Return the entry to the ring pool. */
rd->rdma.cntinfo = RCNTINFO_INIT;
sp->rx_new = NEXT_RX(sp->rx_new);
- DMA_SYNC_DESC_DEV(dev, rd);
+ dma_sync_desc_dev(dev, rd);
rd = &sp->rx_desc[sp->rx_new];
- DMA_SYNC_DESC_CPU(dev, rd);
+ dma_sync_desc_cpu(dev, rd);
}
- DMA_SYNC_DESC_CPU(dev, &sp->rx_desc[orig_end]);
+ dma_sync_desc_cpu(dev, &sp->rx_desc[orig_end]);
sp->rx_desc[orig_end].rdma.cntinfo &= ~(HPCDMA_EOR);
- DMA_SYNC_DESC_DEV(dev, &sp->rx_desc[orig_end]);
- DMA_SYNC_DESC_CPU(dev, &sp->rx_desc[PREV_RX(sp->rx_new)]);
+ dma_sync_desc_dev(dev, &sp->rx_desc[orig_end]);
+ dma_sync_desc_cpu(dev, &sp->rx_desc[PREV_RX(sp->rx_new)]);
sp->rx_desc[PREV_RX(sp->rx_new)].rdma.cntinfo |= HPCDMA_EOR;
- DMA_SYNC_DESC_DEV(dev, &sp->rx_desc[PREV_RX(sp->rx_new)]);
+ dma_sync_desc_dev(dev, &sp->rx_desc[PREV_RX(sp->rx_new)]);
rx_maybe_restart(sp, hregs, sregs);
}
@@ -433,12 +437,12 @@ static inline void kick_tx(struct net_device *dev,
* is not active!
*/
td = &sp->tx_desc[i];
- DMA_SYNC_DESC_CPU(dev, td);
+ dma_sync_desc_cpu(dev, td);
while ((td->tdma.cntinfo & (HPCDMA_XIU | HPCDMA_ETXD)) ==
(HPCDMA_XIU | HPCDMA_ETXD)) {
i = NEXT_TX(i);
td = &sp->tx_desc[i];
- DMA_SYNC_DESC_CPU(dev, td);
+ dma_sync_desc_cpu(dev, td);
}
if (td->tdma.cntinfo & HPCDMA_XIU) {
hregs->tx_ndptr = VIRT_TO_DMA(sp, td);
@@ -470,7 +474,7 @@ static inline void sgiseeq_tx(struct net_device *dev, struct sgiseeq_private *sp
for (j = sp->tx_old; j != sp->tx_new; j = NEXT_TX(j)) {
td = &sp->tx_desc[j];
- DMA_SYNC_DESC_CPU(dev, td);
+ dma_sync_desc_cpu(dev, td);
if (!(td->tdma.cntinfo & (HPCDMA_XIU)))
break;
if (!(td->tdma.cntinfo & (HPCDMA_ETXD))) {
@@ -488,7 +492,7 @@ static inline void sgiseeq_tx(struct net_device *dev, struct sgiseeq_private *sp
dev_kfree_skb_any(td->skb);
td->skb = NULL;
}
- DMA_SYNC_DESC_DEV(dev, td);
+ dma_sync_desc_dev(dev, td);
}
}
@@ -598,7 +602,7 @@ static int sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev)
dev->stats.tx_bytes += len;
entry = sp->tx_new;
td = &sp->tx_desc[entry];
- DMA_SYNC_DESC_CPU(dev, td);
+ dma_sync_desc_cpu(dev, td);
/* Create entry. There are so many races with adding a new
* descriptor to the chain:
@@ -618,14 +622,14 @@ static int sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev)
len, DMA_TO_DEVICE);
td->tdma.cntinfo = (len & HPCDMA_BCNT) |
HPCDMA_XIU | HPCDMA_EOXP | HPCDMA_XIE | HPCDMA_EOX;
- DMA_SYNC_DESC_DEV(dev, td);
+ dma_sync_desc_dev(dev, td);
if (sp->tx_old != sp->tx_new) {
struct sgiseeq_tx_desc *backend;
backend = &sp->tx_desc[PREV_TX(sp->tx_new)];
- DMA_SYNC_DESC_CPU(dev, backend);
+ dma_sync_desc_cpu(dev, backend);
backend->tdma.cntinfo &= ~HPCDMA_EOX;
- DMA_SYNC_DESC_DEV(dev, backend);
+ dma_sync_desc_dev(dev, backend);
}
sp->tx_new = NEXT_TX(sp->tx_new); /* Advance. */
@@ -681,11 +685,11 @@ static inline void setup_tx_ring(struct net_device *dev,
while (i < (nbufs - 1)) {
buf[i].tdma.pnext = VIRT_TO_DMA(sp, buf + i + 1);
buf[i].tdma.pbuf = 0;
- DMA_SYNC_DESC_DEV(dev, &buf[i]);
+ dma_sync_desc_dev(dev, &buf[i]);
i++;
}
buf[i].tdma.pnext = VIRT_TO_DMA(sp, buf);
- DMA_SYNC_DESC_DEV(dev, &buf[i]);
+ dma_sync_desc_dev(dev, &buf[i]);
}
static inline void setup_rx_ring(struct net_device *dev,
@@ -698,12 +702,12 @@ static inline void setup_rx_ring(struct net_device *dev,
while (i < (nbufs - 1)) {
buf[i].rdma.pnext = VIRT_TO_DMA(sp, buf + i + 1);
buf[i].rdma.pbuf = 0;
- DMA_SYNC_DESC_DEV(dev, &buf[i]);
+ dma_sync_desc_dev(dev, &buf[i]);
i++;
}
buf[i].rdma.pbuf = 0;
buf[i].rdma.pnext = VIRT_TO_DMA(sp, buf);
- DMA_SYNC_DESC_DEV(dev, &buf[i]);
+ dma_sync_desc_dev(dev, &buf[i]);
}
static int __init sgiseeq_probe(struct platform_device *pdev)
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply related
* Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28
From: Jeff Garzik @ 2007-12-19 0:38 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: netdev, linux-mips, ralf
In-Reply-To: <20071218103006.GA18598@alpha.franken.de>
Thomas Bogendoerfer wrote:
> On Mon, Dec 17, 2007 at 08:18:38PM -0500, Jeff Garzik wrote:
>>> Changes to last version:
>>> - Use inline functions for dma_sync_* instead of macros (suggested by Ralf)
>>> - added Kconfig change to make selection for similair SGI boxes easier
>> hrm, could you rediff? it doesn't seem to apply
>
> sure, against which tree ? I tried netdev-2.6 and it applies without fuzz...
It needs to be the 'upstream' branch of netdev-2.6.
The default netdev-2.6.git branch, master, is a 100% vanilla duplicate
of Linus's git repository.
(this permits a common practice of presenting logs and diffs using git's
branch..branch notation)
Jeff
^ permalink raw reply
* Re: [MIPS] Build an embedded initramfs into mips kernel
From: Willy Tarreau @ 2007-12-18 22:47 UTC (permalink / raw)
To: Alon Bar-Lev; +Cc: H. Peter Anvin, linux-mips, LKML
In-Reply-To: <9e0cf0bf0712181409p2475e1fdk779fdee4fa274722@mail.gmail.com>
On Wed, Dec 19, 2007 at 12:09:46AM +0200, Alon Bar-Lev wrote:
> On 12/18/07, H. Peter Anvin <hpa@zytor.com> wrote:
> > Make sure your /init doesn't depend on an interpreter or library which
> > isn't available.
>
> Thank you for your answer.
>
> I already checked.
>
> /init is hardlink to busybox, it depends on libc.so.0 which is available at /lib
Are you sure that libc.so.0 is enough and that you don't need any ld.so ?
> But shouldn't I get a different error code if this is the case?
If it does not find part of the dynamic linker or libraries, this error
makes sense to me.
You should try to build a static init with any stupid thing such as a
hello world to ensure that the problem really comes from the init and
nothing else.
Regards,
Willy
^ permalink raw reply
* Re: [MIPS] Build an embedded initramfs into mips kernel
From: H. Peter Anvin @ 2007-12-18 22:11 UTC (permalink / raw)
To: Alon Bar-Lev; +Cc: linux-mips, LKML
In-Reply-To: <9e0cf0bf0712181409p2475e1fdk779fdee4fa274722@mail.gmail.com>
Alon Bar-Lev wrote:
> On 12/18/07, H. Peter Anvin <hpa@zytor.com> wrote:
>> Make sure your /init doesn't depend on an interpreter or library which
>> isn't available.
>
> Thank you for your answer.
>
> I already checked.
>
> /init is hardlink to busybox, it depends on libc.so.0 which is available at /lib
>
> But shouldn't I get a different error code if this is the case?
Don't think so.
-hpa
^ permalink raw reply
* Re: [MIPS] Build an embedded initramfs into mips kernel
From: Alon Bar-Lev @ 2007-12-18 22:09 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linux-mips, LKML
In-Reply-To: <47683B2D.9030608@zytor.com>
On 12/18/07, H. Peter Anvin <hpa@zytor.com> wrote:
> Make sure your /init doesn't depend on an interpreter or library which
> isn't available.
Thank you for your answer.
I already checked.
/init is hardlink to busybox, it depends on libc.so.0 which is available at /lib
But shouldn't I get a different error code if this is the case?
Best Regards,
Alon Bar-Lev.
^ permalink raw reply
* Re: [MIPS] Build an embedded initramfs into mips kernel
From: H. Peter Anvin @ 2007-12-18 21:27 UTC (permalink / raw)
To: Alon Bar-Lev; +Cc: linux-mips, LKML
In-Reply-To: <9e0cf0bf0712181208m7f16b9acpf3dba67f3556a613@mail.gmail.com>
Alon Bar-Lev wrote:
> Hello,
>
> I am trying to build a basic initramfs image into the kernel, using
> the CONFIG_INITRAMFS_SOURCE. The required result is a single image
> loaded into a target containing usermode application (busybox).
>
> I use cross compile mipsel-unknown-linux-uclibc in order to build the
> kernel and the initramfs's usermode.
>
> The cpio image is created using cpio -o -H newc command.
>
> The same configuration works with i586-pc-linux-uclibc cross compile.
>
> printk at init/main.c::run_init_process() shows that the
> kernel_execve() returns -2 (ENOENT) for /init and -14 (EFAULT) for
> /*/init.
>
> Looking at the initramfs /init is available and executable.
>
> Any reason why I get ENOENT?
> Any special procedure should be performed for mips arch?
>
Make sure your /init doesn't depend on an interpreter or library which
isn't available.
-hpa
^ permalink raw reply
* [MIPS] Build an embedded initramfs into mips kernel
From: Alon Bar-Lev @ 2007-12-18 20:08 UTC (permalink / raw)
To: linux-mips, LKML
Hello,
I am trying to build a basic initramfs image into the kernel, using
the CONFIG_INITRAMFS_SOURCE. The required result is a single image
loaded into a target containing usermode application (busybox).
I use cross compile mipsel-unknown-linux-uclibc in order to build the
kernel and the initramfs's usermode.
The cpio image is created using cpio -o -H newc command.
The same configuration works with i586-pc-linux-uclibc cross compile.
printk at init/main.c::run_init_process() shows that the
kernel_execve() returns -2 (ENOENT) for /init and -14 (EFAULT) for
/*/init.
Looking at the initramfs /init is available and executable.
Any reason why I get ENOENT?
Any special procedure should be performed for mips arch?
Best Regards,
Alon Bar-Lev.
^ permalink raw reply
* Re: PCI resource unavailable on mips
From: Jon Dufresne @ 2007-12-18 18:40 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-kernel, linux-mips
In-Reply-To: <4761C26C.3010708@shaw.ca>
> > Bar0:PHYS=e0000000 LEN=04000000
> > Bar1:PHYS=efa00000 LEN=00200000
> > Bar2:PHYS=e8000000 LEN=04000000
>
> So, two 64MB BARs and a 2MB one?
That is right.
> Any PCI resource allocation errors in dmesg during the boot process?
> Could be the kernel wasn't able to find a place to map all of the BARs.
>
I went back and looked at the boot up messages and I found this:
PCI: Failed to allocate mem resource #2:4000000@24000000 for
0000:00:0c.0
That is my device. So it does appear that there is an allocation issue.
Any idea how to get around this?
Thanks,
Jon
^ permalink raw reply
* Re: PCI resource unavailable on mips
From: Jon Dufresne @ 2007-12-18 18:11 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Ralf Baechle, linux-kernel, linux-mips
In-Reply-To: <476699FA.5050606@ru.mvista.com>
> Your example doesn't make sense to me so far.
Ok, I simplified my driver down to one small C file that does exactly
what I want, and that is it. Below is my driver under "driver.c" and the
user space program I am using to access it under "user-test.c".
When I insmod this driver under mips, it correctly prints out the PCI
config space by accessing it through the chip's mmio (which is provided
by BAR1), using the offset 0x00040000 as described in the technical
manual. This works correctly. This is the block of memory you see
printed out in the dmesg below.
When I run the user space program, however, I try to print out the same
data through the mmap. This causes a Bus Error which I put the output of
below.
I am very confused by this. I can read the memory in kernel space, but
not user space. This driver works as expected under x86, which only
confuses me further.
Any ideas what I am doing wrong?
I've been starring at this for quite some time. Please feel free to give
me any and all critiques on my code, it will only help towards solving
this problem.
Thanks for the help!
------driver.c----------
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/pci.h>
#define MODULE_NAME "tmexp"
#define PCI_DEVICE_ID_PHILIPS_PNX1700 0x5406
#define MMIO_PCI_BASE 0x00040000
static int pnx1700_mmap(struct file *filp, struct vm_area_struct *vma);
static int pnx1700_probe(struct pci_dev *dev, const struct pci_device_id
*id);
static void pnx1700_remove(struct pci_dev *dev);
struct pnx1700 {
dev_t devno;
struct cdev cdev;
struct pci_dev *pci_dev;
void __iomem *mmio;
};
struct pnx1700 tmexp;
static struct pci_device_id pnx1700_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_PHILIPS, PCI_DEVICE_ID_PHILIPS_PNX1700) },
{ 0, }
};
static struct pci_driver pnx1700_pci_driver = {
.name = MODULE_NAME,
.id_table = pnx1700_ids,
.probe = pnx1700_probe,
.remove = pnx1700_remove,
};
static struct file_operations pnx1700_fops = {
.owner = THIS_MODULE,
.mmap = pnx1700_mmap,
};
static int pnx1700_mmap(struct file *filp, struct vm_area_struct *vma)
{
unsigned long off = vma->vm_pgoff << PAGE_SHIFT;
unsigned long physical = pci_resource_start(tmexp.pci_dev, 1) + off;
unsigned long vsize = vma->vm_end - vma->vm_start;
unsigned long psize = pci_resource_len(tmexp.pci_dev, 1) - off;
BUG_ON(vsize > psize);
return io_remap_pfn_range(vma, vma->vm_start,
physical >> PAGE_SHIFT,
vsize, vma->vm_page_prot);
}
static void dump_pci_mmio(void __iomem *mmio)
{
int i;
u8 mem[16];
for(i = 0; i < 0x100; i += 0x10) {
memcpy_fromio(mem, mmio + MMIO_PCI_BASE + 0x40 + i, 16);
printk("%02x: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %
02x %02x %02x %02x %02x\n",
i, mem[0], mem[1], mem[2], mem[3], mem[4], mem[5], mem[6], mem[7],
mem[8], mem[9], mem[10], mem[11], mem[12], mem[13], mem[14], mem[15]);
}
}
static int pnx1700_probe(struct pci_dev *dev, const struct pci_device_id
*id)
{
int err;
struct resource *resource;
unsigned long start = pci_resource_start(dev, 1);
unsigned long len = pci_resource_len(dev, 1);
tmexp.pci_dev = dev;
err = pci_enable_device(dev);
BUG_ON(err);
err = pci_enable_device_bars(dev, 0x7);
BUG_ON(err);
resource = request_mem_region(start, len, MODULE_NAME);
BUG_ON(!resource);
tmexp.mmio = ioremap(start, len);
BUG_ON(!tmexp.mmio);
dump_pci_mmio(tmexp.mmio);
return 0;
}
static void pnx1700_remove(struct pci_dev *dev)
{
unsigned long start = pci_resource_start(dev, 1);
unsigned long len = pci_resource_len(dev, 1);
iounmap(tmexp.mmio);
release_mem_region(start, len);
}
static int __init tmexp_init(void)
{
int err;
memset(&tmexp, 0, sizeof(struct pnx1700));
err = pci_register_driver(&pnx1700_pci_driver);
BUG_ON(err);
alloc_chrdev_region(&tmexp.devno, 0, 1, MODULE_NAME);
cdev_init(&tmexp.cdev, &pnx1700_fops);
tmexp.cdev.owner = THIS_MODULE;
err = cdev_add(&tmexp.cdev, tmexp.devno, 1);
BUG_ON(err);
return 0;
}
static void __exit tmexp_exit(void)
{
cdev_del(&tmexp.cdev);
unregister_chrdev_region(tmexp.devno, 1);
pci_unregister_driver(&pnx1700_pci_driver);
}
module_init(tmexp_init);
module_exit(tmexp_exit);
----------------
-------user-test.c----------
#include <fcntl.h>
#include <sys/mman.h>
#include <unistd.h>
#include <stdio.h>
#include <stdint.h>
#include <string.h>
#define PCI_MMIO_BASE (0x00040000)
static void dump_mem(void const *src, int offset, int size);
static void sanity_check(void const *mmio);
int main(int argc, char *argv[])
{
int fd;
void *mmio;
fd = open("/dev/pnx1700", O_RDWR);
mmio = mmap(0, 0x00200000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
printf("stuff mapped ready to test\n");
sanity_check(mmio);
dump_mem(mmio, PCI_MMIO_BASE + 0x40, 0x100);
munmap(mmio, 0x00200000);
close(fd);
return 0;
}
static void dump_mem(void const *src, int offset, int size)
{
int i;
unsigned char mem[16];
for(i = 0; i < size; i += 0x10) {
memcpy(mem, src + offset + i, 16);
printf("%02x: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %
02x %02x %02x %02x %02x\n",
i, mem[0], mem[1], mem[2], mem[3], mem[4], mem[5], mem[6], mem[7],
mem[8], mem[9], mem[10], mem[11], mem[12], mem[13], mem[14], mem[15]);
}
}
static void sanity_check(void const *mmio)
{
uint32_t dword;
dword = *((uint32_t *)(mmio + PCI_MMIO_BASE + 0x40));
printf("dword=0x%x\n", dword);
}
-------------
-----output-----
# ./load_driver
PCI: Enabling device 0000:00:0c.0 (0000 -> 0002)
00: 31 11 06 54 02 00 90 82 00 00 80 04 00 00 00 00
10: 08 00 00 20 00 00 00 24 00 00 00 1c 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 36 11 17 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 09 18
40: 01 00 02 00 00 00 00 00 00 00 00 00 03 02 07 00
50: 06 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
10.41.1.162 # ./user-test
stuff mapped reaData bus error, epc == 00400a24, ra == 004007f4
dy to test
Bus error
10.41.1.162 # dmesg
<4>PCI: Enabling device 0000:00:0c.0 (0000 -> 0002)
<4>00: 31 11 06 54 02 00 90 82 00 00 80 04 00 00 00 00
<4>10: 08 00 00 20 00 00 00 24 00 00 00 1c 00 00 00 00
<4>20: 00 00 00 00 00 00 00 00 00 00 00 00 36 11 17 00
<4>30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 09 18
<4>40: 01 00 02 00 00 00 00 00 00 00 00 00 03 02 07 00
<4>50: 06 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<4>60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<4>70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<4>80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<4>90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<4>a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<4>b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<4>c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<4>d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<4>e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<4>f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<1>Data bus error, epc == 00400a24, ra == 004007f4
-----------
^ permalink raw reply
* Re: [PATCH 1/4] Introduced GPI_RM9000 configuration parameter
From: Ralf Baechle @ 2007-12-18 10:52 UTC (permalink / raw)
To: Thomas Koeller; +Cc: linux-mips
In-Reply-To: <20071218003140.4415847A63@mail.koeller.dyndns.org>
On Tue, Dec 18, 2007 at 01:26:19AM +0100, Thomas Koeller wrote:
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index c6fc405..62bc553 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -856,6 +856,9 @@ config GENERIC_ISA_DMA_SUPPORT_BROKEN
> config GENERIC_GPIO
> bool
>
> +config GPI_RM9000
> + bool
> +
> #
> # Endianess selection. Sufficiently obscure so many users don't know what to
> # answer,so we try hard to limit the available choices. Also the use of a
> @@ -927,6 +930,7 @@ config MIPS_TX3927
> config MIPS_RM9122
> bool
> select SERIAL_RM9000
> + select GPI_RM9000
See my earlier reply to http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20070911122005.GC24679%40linux-mips.org
Technically the patch is ok but please only introduce new config symbols
only together with an actual user.
Ralf
^ permalink raw reply
* Re: timer irq setup
From: Ralf Baechle @ 2007-12-18 10:48 UTC (permalink / raw)
To: Thomas Koeller; +Cc: linux-mips
In-Reply-To: <200712171135.24569.thomas@koeller.dyndns.org>
On Mon, Dec 17, 2007 at 11:35:22AM +0100, Thomas Koeller wrote:
> In arch/mips/kernel/traps.c, per_cpu_trap_init() contains
> code to set up the global cp0_compare_irq variable. Does
> this make sense? I'd say that either the irq setup should
> be moved to trap_init(), or cp0_compare_irq should be
> changed to a per-cpu variable, depending on what the original
> intention was.
Technically it would be legal to route the timer interrupt to a different
interrupt for each of possibly multiple processors, that's why it's done
in per_cpu_trap_init().
Obviously the rest of the code isn't quite there and also to best of my
knowledge all actual implementations use the same interrupt across all
cores. So something like a global variable and a paranoia check in
per_cpu_trap_init() to ensure all CPUs really use the same interrupt
would seem reasonable.
Ralf
^ permalink raw reply
* Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28
From: Thomas Bogendoerfer @ 2007-12-18 10:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-mips, ralf
In-Reply-To: <47671FEE.90103@pobox.com>
On Mon, Dec 17, 2007 at 08:18:38PM -0500, Jeff Garzik wrote:
> >Changes to last version:
> >- Use inline functions for dma_sync_* instead of macros (suggested by Ralf)
> >- added Kconfig change to make selection for similair SGI boxes easier
>
> hrm, could you rediff? it doesn't seem to apply
sure, against which tree ? I tried netdev-2.6 and it applies without fuzz...
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [UPDATED PATCH] SGISEEQ: use cached memory access to make driver work on IP28
From: Jeff Garzik @ 2007-12-18 1:18 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: netdev, linux-mips, ralf
In-Reply-To: <20071202103312.75E51C2EB5@solo.franken.de>
Thomas Bogendoerfer wrote:
> SGI IP28 machines would need special treatment (enable adding addtional
> wait states) when accessing memory uncached. To avoid this pain I changed
> the driver to use only cached access to memory.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> ---
>
> Changes to last version:
> - Use inline functions for dma_sync_* instead of macros (suggested by Ralf)
> - added Kconfig change to make selection for similair SGI boxes easier
hrm, could you rediff? it doesn't seem to apply
^ permalink raw reply
* [PATCH 1/4] Introduced GPI_RM9000 configuration parameter
From: Thomas Koeller @ 2007-12-18 0:26 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
Signed-off-by: Thomas Koeller <thomas.koeller@baslerweb.com>
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index c6fc405..62bc553 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -856,6 +856,9 @@ config GENERIC_ISA_DMA_SUPPORT_BROKEN
config GENERIC_GPIO
bool
+config GPI_RM9000
+ bool
+
#
# Endianess selection. Sufficiently obscure so many users don't know what to
# answer,so we try hard to limit the available choices. Also the use of a
@@ -927,6 +930,7 @@ config MIPS_TX3927
config MIPS_RM9122
bool
select SERIAL_RM9000
+ select GPI_RM9000
config PNX8550
bool
--
1.5.3.6
^ permalink raw reply related
* [PATCH 4/4] excite: Supply platform-specific compare and performance timer interrupts
From: Thomas Koeller @ 2007-12-18 0:27 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
As the eXcite platform uses the alternate RM9000 compare interrupt, it
must supply a platform-specific irq value. The performance counter is
currently unused.
Signed-off-by: Thomas Koeller <thomas.koeller@baslerweb.com>
diff --git a/arch/mips/basler/excite/excite_setup.c
b/arch/mips/basler/excite/excite_setup.c
index 6dd8f0d..a91309f 100644
--- a/arch/mips/basler/excite/excite_setup.c
+++ b/arch/mips/basler/excite/excite_setup.c
@@ -85,6 +85,18 @@ void __init plat_time_init(void)
mips_hpt_frequency = EXCITE_CPU_EXT_CLOCK * mult / div / 2;
}
+unsigned int __init
+get_c0_compare_int(void)
+{
+ return 12;
+}
+
+unsigned int __init
+get_c0_perfcounter_int(void)
+{
+ return -1;
+}
+
static int __init excite_init_console(void)
{
#if defined(CONFIG_SERIAL_8250)
--
1.5.3.6
^ permalink raw reply related
* [PATCH 3/4] [MIPS] Allow platform to override default timer and performance counter interrupts
From: Thomas Koeller @ 2007-12-18 0:26 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
While there was a platform hook for setting the compare timer interrupt
before, it was implemented in a somewhat arkward way, and no such hook
existed for the performance counter interrupt. This change aims at a
cleaner solution, by using the platform-supplied values right from the
beginning instead of setting up the standard irq first, and then
ignoring it.
Signed-off-by: Thomas Koeller <thomas.koeller@baslerweb.com>
diff --git a/arch/mips/kernel/cevt-r4k.c b/arch/mips/kernel/cevt-r4k.c
index 24a2d90..3b1407e 100644
--- a/arch/mips/kernel/cevt-r4k.c
+++ b/arch/mips/kernel/cevt-r4k.c
@@ -9,6 +9,7 @@
#include <linux/clockchips.h>
#include <linux/interrupt.h>
#include <linux/percpu.h>
+#include <linux/kernel.h>
#include <asm/smtc_ipi.h>
#include <asm/time.h>
@@ -76,8 +77,8 @@ static irqreturn_t c0_compare_interrupt(int irq, void
*dev_id)
{
const int r2 = cpu_has_mips_r2;
struct clock_event_device *cd;
- int cpu = smp_processor_id();
-
+ const int cpu = smp_processor_id();
+
/*
* Suckage alert:
* Before R2 of the architecture there was no way to see if a
@@ -169,9 +170,6 @@ static void mips_event_handler(struct clock_event_device
*dev)
{
}
-/*
- * FIXME: This doesn't hold for the relocated E9000 compare interrupt.
- */
static int c0_compare_int_pending(void)
{
return (read_c0_cause() >> cp0_compare_irq) & 0x100;
@@ -183,7 +181,8 @@ static int c0_compare_int_usable(void)
unsigned int cnt;
/*
- * IP7 already pending? Try to clear it by acking the timer.
+ * Compare interrupt already pending?
+ * Try to clear it by acking the timer.
*/
if (c0_compare_int_pending()) {
write_c0_compare(read_c0_count());
@@ -221,8 +220,8 @@ static int c0_compare_int_usable(void)
int __cpuinit mips_clockevent_init(void)
{
- uint64_t mips_freq = mips_hpt_frequency;
- unsigned int cpu = smp_processor_id();
+ const uint64_t mips_freq = mips_hpt_frequency;
+ const unsigned int cpu = smp_processor_id();
struct clock_event_device *cd;
unsigned int irq;
@@ -240,17 +239,12 @@ int __cpuinit mips_clockevent_init(void)
return 0;
#endif
- if (!c0_compare_int_usable())
+ if (!c0_compare_int_usable()) {
+ pr_crit("MIPS compare interrupt not working - no timer clock\n");
return -ENXIO;
+ }
- /*
- * With vectored interrupts things are getting platform specific.
- * get_c0_compare_int is a hook to allow a platform to return the
- * interrupt number of it's liking.
- */
irq = MIPS_CPU_IRQ_BASE + cp0_compare_irq;
- if (get_c0_compare_int)
- irq = get_c0_compare_int();
cd = &per_cpu(mips_clockevent_device, cpu);
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index fcae667..268247d 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -1281,6 +1281,20 @@ extern void flush_tlb_handlers(void);
*/
int cp0_compare_irq;
+unsigned int __init __weak
+get_c0_compare_int(void)
+{
+ return cpu_has_mips_r2 ?
+ (read_c0_intctl() >> 29) & 7 : CP0_LEGACY_COMPARE_IRQ;
+}
+
+unsigned int __init __weak
+get_c0_perfcount_int(void)
+{
+ return cpu_has_mips_r2 ?
+ (read_c0_intctl() >> 26) & 7 : -1;
+}
+
/*
* Performance counter IRQ or -1 if shared with timer
*/
@@ -1352,21 +1366,11 @@ void __init per_cpu_trap_init(void)
set_c0_cause(CAUSEF_IV);
}
- /*
- * Before R2 both interrupt numbers were fixed to 7, so on R2 only:
- *
- * o read IntCtl.IPTI to determine the timer interrupt
- * o read IntCtl.IPPCI to determine the performance counter interrupt
- */
- if (cpu_has_mips_r2) {
- cp0_compare_irq = (read_c0_intctl() >> 29) & 7;
- cp0_perfcount_irq = (read_c0_intctl() >> 26) & 7;
- if (cp0_perfcount_irq == cp0_compare_irq)
- cp0_perfcount_irq = -1;
- } else {
- cp0_compare_irq = CP0_LEGACY_COMPARE_IRQ;
+ /* Set up timer & performance counter interrupts */
+ cp0_compare_irq = get_c0_compare_int();
+ cp0_perfcount_irq = get_c0_perfcount_int();
+ if (cp0_perfcount_irq == cp0_compare_irq)
cp0_perfcount_irq = -1;
- }
#ifdef CONFIG_MIPS_MT_SMTC
}
diff --git a/include/asm-mips/time.h b/include/asm-mips/time.h
index 7717934..be0d157 100644
--- a/include/asm-mips/time.h
+++ b/include/asm-mips/time.h
@@ -59,7 +59,8 @@ extern int (*perf_irq)(void);
*/
#ifdef CONFIG_CEVT_R4K
extern int mips_clockevent_init(void);
-extern unsigned int __weak get_c0_compare_int(void);
+extern unsigned int get_c0_compare_int(void);
+extern unsigned int get_c0_perfcount_int(void);
#else
static inline int mips_clockevent_init(void)
{
--
1.5.3.6
^ permalink raw reply related
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