* [PATCH] mips: picvue: pvc_sem semaphore to mutex
From: Daniel Walker @ 2008-01-11 4:53 UTC (permalink / raw)
To: brian; +Cc: mingo, ralf, linux-mips
This semaphore conforms to the new struct mutex, so I've converted it
to use that new API.
I also changed the name to pvc_mutex, and moved the define to the file
it's used in which allows it to be static.
Signed-off-by: Daniel Walker <dwalker@mvista.com>
---
arch/mips/lasat/picvue.c | 2 --
arch/mips/lasat/picvue.h | 3 ---
arch/mips/lasat/picvue_proc.c | 18 ++++++++++--------
3 files changed, 10 insertions(+), 13 deletions(-)
Index: linux-2.6.23/arch/mips/lasat/picvue.c
===================================================================
--- linux-2.6.23.orig/arch/mips/lasat/picvue.c
+++ linux-2.6.23/arch/mips/lasat/picvue.c
@@ -22,8 +22,6 @@
struct pvc_defs *picvue;
-DECLARE_MUTEX(pvc_sem);
-
static void pvc_reg_write(u32 val)
{
*picvue->reg = val;
Index: linux-2.6.23/arch/mips/lasat/picvue.h
===================================================================
--- linux-2.6.23.orig/arch/mips/lasat/picvue.h
+++ linux-2.6.23/arch/mips/lasat/picvue.h
@@ -4,8 +4,6 @@
* Brian Murphy <brian.murphy@eicon.com>
*
*/
-#include <asm/semaphore.h>
-
struct pvc_defs {
volatile u32 *reg;
u32 data_shift;
@@ -45,4 +43,3 @@ void pvc_move(u8 cmd);
void pvc_clear(void);
void pvc_home(void);
-extern struct semaphore pvc_sem;
Index: linux-2.6.23/arch/mips/lasat/picvue_proc.c
===================================================================
--- linux-2.6.23.orig/arch/mips/lasat/picvue_proc.c
+++ linux-2.6.23/arch/mips/lasat/picvue_proc.c
@@ -13,9 +13,11 @@
#include <linux/interrupt.h>
#include <linux/timer.h>
+#include <linux/mutex.h>
#include "picvue.h"
+static DEFINE_MUTEX(pvc_mutex);
static char pvc_lines[PVC_NLINES][PVC_LINELEN+1];
static int pvc_linedata[PVC_NLINES];
static struct proc_dir_entry *pvc_display_dir;
@@ -48,9 +50,9 @@ static int pvc_proc_read_line(char *page
return 0;
}
- down(&pvc_sem);
+ mutex_lock(&pvc_mutex);
page += sprintf(page, "%s\n", pvc_lines[lineno]);
- up(&pvc_sem);
+ mutex_unlock(&pvc_mutex);
return page - origpage;
}
@@ -73,10 +75,10 @@ static int pvc_proc_write_line(struct fi
if (buffer[count-1] == '\n')
count--;
- down(&pvc_sem);
+ mutex_lock(&pvc_mutex);
strncpy(pvc_lines[lineno], buffer, count);
pvc_lines[lineno][count] = '\0';
- up(&pvc_sem);
+ mutex_unlock(&pvc_mutex);
tasklet_schedule(&pvc_display_tasklet);
@@ -89,7 +91,7 @@ static int pvc_proc_write_scroll(struct
int origcount = count;
int cmd = simple_strtol(buffer, NULL, 10);
- down(&pvc_sem);
+ mutex_lock(&pvc_mutex);
if (scroll_interval != 0)
del_timer(&timer);
@@ -106,7 +108,7 @@ static int pvc_proc_write_scroll(struct
}
add_timer(&timer);
}
- up(&pvc_sem);
+ mutex_unlock(&pvc_mutex);
return origcount;
}
@@ -117,9 +119,9 @@ static int pvc_proc_read_scroll(char *pa
{
char *origpage = page;
- down(&pvc_sem);
+ mutex_lock(&pvc_mutex);
page += sprintf(page, "%d\n", scroll_dir * scroll_interval);
- up(&pvc_sem);
+ mutex_unlock(&pvc_mutex);
return page - origpage;
}
--
--
^ permalink raw reply
* [PATCH] mips: picvue: pvc_sem semaphore to mutex
From: Daniel Walker @ 2008-01-11 4:53 UTC (permalink / raw)
To: brian; +Cc: mingo, ralf, linux-mips
This semaphore conforms to the new struct mutex, so I've converted it
to use that new API.
I also changed the name to pvc_mutex, and moved the define to the file
it's used in which allows it to be static.
Signed-off-by: Daniel Walker <dwalker@mvista.com>
---
arch/mips/lasat/picvue.c | 2 --
arch/mips/lasat/picvue.h | 3 ---
arch/mips/lasat/picvue_proc.c | 18 ++++++++++--------
3 files changed, 10 insertions(+), 13 deletions(-)
Index: linux-2.6.23/arch/mips/lasat/picvue.c
===================================================================
--- linux-2.6.23.orig/arch/mips/lasat/picvue.c
+++ linux-2.6.23/arch/mips/lasat/picvue.c
@@ -22,8 +22,6 @@
struct pvc_defs *picvue;
-DECLARE_MUTEX(pvc_sem);
-
static void pvc_reg_write(u32 val)
{
*picvue->reg = val;
Index: linux-2.6.23/arch/mips/lasat/picvue.h
===================================================================
--- linux-2.6.23.orig/arch/mips/lasat/picvue.h
+++ linux-2.6.23/arch/mips/lasat/picvue.h
@@ -4,8 +4,6 @@
* Brian Murphy <brian.murphy@eicon.com>
*
*/
-#include <asm/semaphore.h>
-
struct pvc_defs {
volatile u32 *reg;
u32 data_shift;
@@ -45,4 +43,3 @@ void pvc_move(u8 cmd);
void pvc_clear(void);
void pvc_home(void);
-extern struct semaphore pvc_sem;
Index: linux-2.6.23/arch/mips/lasat/picvue_proc.c
===================================================================
--- linux-2.6.23.orig/arch/mips/lasat/picvue_proc.c
+++ linux-2.6.23/arch/mips/lasat/picvue_proc.c
@@ -13,9 +13,11 @@
#include <linux/interrupt.h>
#include <linux/timer.h>
+#include <linux/mutex.h>
#include "picvue.h"
+static DEFINE_MUTEX(pvc_mutex);
static char pvc_lines[PVC_NLINES][PVC_LINELEN+1];
static int pvc_linedata[PVC_NLINES];
static struct proc_dir_entry *pvc_display_dir;
@@ -48,9 +50,9 @@ static int pvc_proc_read_line(char *page
return 0;
}
- down(&pvc_sem);
+ mutex_lock(&pvc_mutex);
page += sprintf(page, "%s\n", pvc_lines[lineno]);
- up(&pvc_sem);
+ mutex_unlock(&pvc_mutex);
return page - origpage;
}
@@ -73,10 +75,10 @@ static int pvc_proc_write_line(struct fi
if (buffer[count-1] == '\n')
count--;
- down(&pvc_sem);
+ mutex_lock(&pvc_mutex);
strncpy(pvc_lines[lineno], buffer, count);
pvc_lines[lineno][count] = '\0';
- up(&pvc_sem);
+ mutex_unlock(&pvc_mutex);
tasklet_schedule(&pvc_display_tasklet);
@@ -89,7 +91,7 @@ static int pvc_proc_write_scroll(struct
int origcount = count;
int cmd = simple_strtol(buffer, NULL, 10);
- down(&pvc_sem);
+ mutex_lock(&pvc_mutex);
if (scroll_interval != 0)
del_timer(&timer);
@@ -106,7 +108,7 @@ static int pvc_proc_write_scroll(struct
}
add_timer(&timer);
}
- up(&pvc_sem);
+ mutex_unlock(&pvc_mutex);
return origcount;
}
@@ -117,9 +119,9 @@ static int pvc_proc_read_scroll(char *pa
{
char *origpage = page;
- down(&pvc_sem);
+ mutex_lock(&pvc_mutex);
page += sprintf(page, "%d\n", scroll_dir * scroll_interval);
- up(&pvc_sem);
+ mutex_unlock(&pvc_mutex);
return page - origpage;
}
--
--
^ permalink raw reply
* Re: pnx8xxx: move to clocksource
From: Sergei Shtylyov @ 2008-01-10 17:05 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Vitaly Wool, linux-mips
In-Reply-To: <20080110162744.GA16880@linux-mips.org>
Ralf Baechle wrote:
> On Thu, Jan 10, 2008 at 07:21:17PM +0300, Sergei Shtylyov wrote:
>>>Index: linux-2.6/arch/mips/philips/pnx8550/common/time.c
>>>===================================================================
>>>--- linux-2.6.orig/arch/mips/philips/pnx8550/common/time.c
>>>+++ linux-2.6/arch/mips/philips/pnx8550/common/time.c
>>>@@ -22,7 +22,6 @@
>>>#include <linux/kernel_stat.h>
>>>#include <linux/spinlock.h>
>>>#include <linux/interrupt.h>
>>>-#include <linux/module.h>
>>>
>>>#include <asm/bootinfo.h>
>>>#include <asm/cpu.h>
>>>@@ -41,11 +40,60 @@ static cycle_t hpt_read(void)
>>> return read_c0_count2();
>>>}
>>
>>>+static struct clocksource pnx_clocksource = {
>>>+ .name = "pnx8xxx",
>>>+ .rating = 200,
>>>+ .read = hpt_read,
>>>+ .flags = CLOCK_SOURCE_IS_CONTINUOUS,
>>>+};
>> Something probably have converted tabs to 8 spaces...
> Only 3 of them?
Erm, it's format=flowed that spoils the tabs for Mozilla which renders
them to 4 spaces, so it's actually hard to see which tabs are actually tabs
and which are not... :-/
>> I would have done it otherwise -- using timer 1 as a generic MIPS
>>clocksource (just hooking the IRQ to reload the comparator to all ones),
>>and timer 2 as clockevent...
>>>static void timer_ack(void)
>>>{
>>> write_c0_compare(cpj);
>>>}
>> Do we still need this function? I don't think so -- mips_timer_ack() is
>>dead...
> It's only used on initialization.
Could have put the call inline, or loaded the comparator with all ones
just like timer 2 -- we don't need 'cpj' variable any more as well...
>>[...]
>>>+static struct clock_event_device pnx8xxx_clockevent = {
>>>+ .name = "pnx8xxx_clockevent",
>>>+ .features = CLOCK_EVT_FEAT_ONESHOT,
>> Aren't PNX8550 timers actually periodic in nature?
> All I recall is they were odd ;-)
> The hardware nature of timers and how to declare them to the Linux timer
> code is not always the same. CLOCK_EVT_FEAT_ONESHOT be used if the
> time to the next shot can be programmed.
I meant that both modes should have been indicated by the flags.
And actually, shouldn't we disable the timer after expiry if in one-shot mode.
Writing to the comparator doesn't clear the counter, AFAICS -- so, isn't the
explicit counter clearing to 0 needed in set_next_event() method?
>>>__init void plat_time_init(void)
>>>{
>>>+ unsigned int configPR;
>> Something has definitely spoilt all the tabs in the patch...
> I fixed the three checkpatch.pl was bitching about.
All the others were due to the way format=flowed is rendered by Mozilla it
seems...
>>> unsigned int n;
>>> unsigned int m;
>>> unsigned int p;
>>> unsigned int pow2p;
>>>
>>>+ clockevents_register_device(&pnx8xxx_clockevent);
>>>+ clocksource_register(&pnx_clocksource);
>>>+
>>>+ setup_irq(PNX8550_INT_TIMER1, &pnx8xxx_timer_irq);
>>>+ setup_irq(PNX8550_INT_TIMER2, &monotonic_irqaction);
>>>+
>>>+ /* Timer 1 start */
>>>+ configPR = read_c0_config7();
>>>+ configPR &= ~0x00000008;
>>>+ write_c0_config7(configPR);
>>>+
>>>+ /* Timer 2 start */
>>>+ configPR = read_c0_config7();
>>>+ configPR &= ~0x00000010;
>>>+ write_c0_config7(configPR);
>>>+
>>>+ /* Timer 3 stop */
>>>+ configPR = read_c0_config7();
>>>+ configPR |= 0x00000020;
>>>+ write_c0_config7(configPR);
>> Enabling timers before they are actually set up? :-|
> Are the additional timers used at all?
Additional == timer 3? It's not used, only 1 and 2 are -- and their
count/compare registers are initialized further in this function...
> Ralf
WBR, Sergei
^ permalink raw reply
* Re: pnx8xxx: move to clocksource
From: Vitaly Wool @ 2008-01-10 16:48 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Sergei Shtylyov, linux-mips
In-Reply-To: <20080110162744.GA16880@linux-mips.org>
> > Something probably have converted tabs to 8 spaces...
No, it's just the lines of original code moved.
> > [...]
> >
> >> +static struct clock_event_device pnx8xxx_clockevent = {
> >> + .name = "pnx8xxx_clockevent",
> >> + .features = CLOCK_EVT_FEAT_ONESHOT,
> >
> > Aren't PNX8550 timers actually periodic in nature?
>
> All I recall is they were odd ;-)
>
> The hardware nature of timers and how to declare them to the Linux timer
> code is not always the same. CLOCK_EVT_FEAT_ONESHOT be used if the
> time to the next shot can be programmed.
Absolutely :)
> > Enabling timers before they are actually set up? :-|
>
> Are the additional timers used at all?
Heh, that also was the original code which was just moved from one
place in the file to the other.
Sergei, I decided not to mix whitespace cleanups and the clocksource
changes. I'll come up with the whitespace/tab fixups soon arranging it
as a separate patch.
Vitaly
^ permalink raw reply
* Re: MIPS 4KEc with 2.6.15
From: Martin Michlmayr @ 2008-01-10 16:36 UTC (permalink / raw)
To: Jorgen Lundman; +Cc: linux-mips
In-Reply-To: <478599B5.4060207@lundman.net>
* Jorgen Lundman <lundman@lundman.net> [2008-01-10 13:06]:
> Sure, and I agree. We both know how often than happens, or how
> quickly. So, while we hold our breath for that to happen, mean
> while, I am hoping to find the TangoX mips-board details
> somewhere...
If they are not helpful, you could try asking the guys from
http://gpl-violations.org/ for help.
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply
* Re: pnx8xxx: move to clocksource
From: Ralf Baechle @ 2008-01-10 16:27 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Vitaly Wool, linux-mips
In-Reply-To: <478645FD.2090708@ru.mvista.com>
On Thu, Jan 10, 2008 at 07:21:17PM +0300, Sergei Shtylyov wrote:
>> Index: linux-2.6/arch/mips/philips/pnx8550/common/time.c
>> ===================================================================
>> --- linux-2.6.orig/arch/mips/philips/pnx8550/common/time.c
>> +++ linux-2.6/arch/mips/philips/pnx8550/common/time.c
>> @@ -22,7 +22,6 @@
>> #include <linux/kernel_stat.h>
>> #include <linux/spinlock.h>
>> #include <linux/interrupt.h>
>> -#include <linux/module.h>
>>
>> #include <asm/bootinfo.h>
>> #include <asm/cpu.h>
>> @@ -41,11 +40,60 @@ static cycle_t hpt_read(void)
>> return read_c0_count2();
>> }
>
>> +static struct clocksource pnx_clocksource = {
>> + .name = "pnx8xxx",
>> + .rating = 200,
>> + .read = hpt_read,
>> + .flags = CLOCK_SOURCE_IS_CONTINUOUS,
>> +};
>
> Something probably have converted tabs to 8 spaces...
Only 3 of them?
> I would have done it otherwise -- using timer 1 as a generic MIPS
> clocksource (just hooking the IRQ to reload the comparator to all ones),
> and timer 2 as clockevent...
>
>> static void timer_ack(void)
>> {
>> write_c0_compare(cpj);
>> }
>
> Do we still need this function? I don't think so -- mips_timer_ack() is
> dead...
It's only used on initialization.
> [...]
>
>> +static struct clock_event_device pnx8xxx_clockevent = {
>> + .name = "pnx8xxx_clockevent",
>> + .features = CLOCK_EVT_FEAT_ONESHOT,
>
> Aren't PNX8550 timers actually periodic in nature?
All I recall is they were odd ;-)
The hardware nature of timers and how to declare them to the Linux timer
code is not always the same. CLOCK_EVT_FEAT_ONESHOT be used if the
time to the next shot can be programmed.
>>
>> __init void plat_time_init(void)
>> {
>> + unsigned int configPR;
>
> Something has definitely spoilt all the tabs in the patch...
I fixed the three checkpatch.pl was bitching about.
>> unsigned int n;
>> unsigned int m;
>> unsigned int p;
>> unsigned int pow2p;
>>
>> + clockevents_register_device(&pnx8xxx_clockevent);
>> + clocksource_register(&pnx_clocksource);
>> +
>> + setup_irq(PNX8550_INT_TIMER1, &pnx8xxx_timer_irq);
>> + setup_irq(PNX8550_INT_TIMER2, &monotonic_irqaction);
>> +
>> + /* Timer 1 start */
>> + configPR = read_c0_config7();
>> + configPR &= ~0x00000008;
>> + write_c0_config7(configPR);
>> +
>> + /* Timer 2 start */
>> + configPR = read_c0_config7();
>> + configPR &= ~0x00000010;
>> + write_c0_config7(configPR);
>> +
>> + /* Timer 3 stop */
>> + configPR = read_c0_config7();
>> + configPR |= 0x00000020;
>> + write_c0_config7(configPR);
>
> Enabling timers before they are actually set up? :-|
Are the additional timers used at all?
Ralf
^ permalink raw reply
* Re: pnx8xxx: move to clocksource
From: Sergei Shtylyov @ 2008-01-10 16:21 UTC (permalink / raw)
To: Vitaly Wool; +Cc: ralf, linux-mips
In-Reply-To: <4786273D.7010006@gmail.com>
Hello.
Vitaly Wool wrote:
> This patch converts PNX8XXX system timer to clocksource.
Well, this patch has been already committed but nevertheless...
> arch/mips/philips/pnx8550/common/time.c | 109
> +++++++++++++++++++++-----------
> 1 files changed, 72 insertions(+), 37 deletions(-)
> Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
> Index: linux-2.6/arch/mips/philips/pnx8550/common/time.c
> ===================================================================
> --- linux-2.6.orig/arch/mips/philips/pnx8550/common/time.c
> +++ linux-2.6/arch/mips/philips/pnx8550/common/time.c
> @@ -22,7 +22,6 @@
> #include <linux/kernel_stat.h>
> #include <linux/spinlock.h>
> #include <linux/interrupt.h>
> -#include <linux/module.h>
>
> #include <asm/bootinfo.h>
> #include <asm/cpu.h>
> @@ -41,11 +40,60 @@ static cycle_t hpt_read(void)
> return read_c0_count2();
> }
> +static struct clocksource pnx_clocksource = {
> + .name = "pnx8xxx",
> + .rating = 200,
> + .read = hpt_read,
> + .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> +};
Something probably have converted tabs to 8 spaces...
I would have done it otherwise -- using timer 1 as a generic MIPS
clocksource (just hooking the IRQ to reload the comparator to all ones), and
timer 2 as clockevent...
> static void timer_ack(void)
> {
> write_c0_compare(cpj);
> }
Do we still need this function? I don't think so -- mips_timer_ack() is
dead...
[...]
> +static struct clock_event_device pnx8xxx_clockevent = {
> + .name = "pnx8xxx_clockevent",
> + .features = CLOCK_EVT_FEAT_ONESHOT,
Aren't PNX8550 timers actually periodic in nature?
> + .set_next_event = pnx8xxx_set_next_event,
> +};
> +
> /*
> * plat_time_init() - it does the following things:
> *
> @@ -58,11 +106,34 @@ static void timer_ack(void)
>
> __init void plat_time_init(void)
> {
> + unsigned int configPR;
Something has definitely spoilt all the tabs in the patch...
> unsigned int n;
> unsigned int m;
> unsigned int p;
> unsigned int pow2p;
>
> + clockevents_register_device(&pnx8xxx_clockevent);
> + clocksource_register(&pnx_clocksource);
> +
> + setup_irq(PNX8550_INT_TIMER1, &pnx8xxx_timer_irq);
> + setup_irq(PNX8550_INT_TIMER2, &monotonic_irqaction);
> +
> + /* Timer 1 start */
> + configPR = read_c0_config7();
> + configPR &= ~0x00000008;
> + write_c0_config7(configPR);
> +
> + /* Timer 2 start */
> + configPR = read_c0_config7();
> + configPR &= ~0x00000010;
> + write_c0_config7(configPR);
> +
> + /* Timer 3 stop */
> + configPR = read_c0_config7();
> + configPR |= 0x00000020;
> + write_c0_config7(configPR);
Enabling timers before they are actually set up? :-|
> +
> +
> /* PLL0 sets MIPS clock (PLL1 <=> TM1, PLL6 <=> TM2, PLL5 <=>
> mem) */
> /* (but only if CLK_MIPS_CTL select value [bits 3:1] is 1:
> FIXME) */
>
WBR, Sergei
^ permalink raw reply
* Re: Linux mips and DMA
From: Jon Dufresne @ 2008-01-10 15:04 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20080110143142.GA13210@linux-mips.org>
> What you were doing seemed to be the right thing. The API is supposed
> to do the necessary address conversion and cache flushes for the driver.
> That is the unchanged driver should work on any architecture.
>
> According to the current kernel code the PNX8550 non-coheren (aka software
> coherency).
>
Thanks Ralf,
So it sounds like you're saying even though my platform does not have HW
coherency, it shouldn't affect the driver code.
In my code, the device creates an interrupt when a message is to be
passed to the host. The message is written in the DMA memory. When I
receive that interrupt, is there some sort of flush I should do to
update the memory the cpu sees, with the data written by the device?
As of right now when I receive the interrupt, then inspect the dma
memory it appears as though nothing was written to memory. So at this
point I left thinking either the device can't correctly write to the
memory, or the memory isn't ready to be read by the host. I am having
trouble discovering which case is actually occurring.
Jon
^ permalink raw reply
* Re: pnx8xxx: move to clocksource
From: Ralf Baechle @ 2008-01-10 14:37 UTC (permalink / raw)
To: Vitaly Wool; +Cc: linux-mips
In-Reply-To: <4786273D.7010006@gmail.com>
On Thu, Jan 10, 2008 at 05:10:05PM +0300, Vitaly Wool wrote:
> This patch converts PNX8XXX system timer to clocksource.
Checkpatch had a little to moan on your patch:
$ scripts/checkpatch.pl /tmp/pend
ERROR: use tabs not spaces
#79: FILE: arch/mips/philips/pnx8550/common/time.c:57:
+ struct clock_event_device *c = dev_id;$
ERROR: use tabs not spaces
#81: FILE: arch/mips/philips/pnx8550/common/time.c:59:
+ /* clear MATCH, signal the event */$
ERROR: use tabs not spaces
#82: FILE: arch/mips/philips/pnx8550/common/time.c:60:
+ c->event_handler(c);$
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
I fixed those, applied. Thanks!
Ralf
^ permalink raw reply
* Re: Linux mips and DMA
From: Ralf Baechle @ 2008-01-10 14:31 UTC (permalink / raw)
To: Jon Dufresne; +Cc: linux-mips
In-Reply-To: <1199974344.4344.16.camel@microwave.infinitevideocorporation.com>
On Thu, Jan 10, 2008 at 09:12:23AM -0500, Jon Dufresne wrote:
> > Hardware coherency for DMA is the exception for low-end embedded MIPS
> > systems andgiven the CPU address your's is no exception from that.
> >
> > If your system was supporting hardware coherency for DMA I/O you would
> > have obtained a cachable CPU address like:
> >
> > dma_handle=0x026f0000 size=0x00010000 cpu_addr=0x826f0000
> > ^^^
> >
> > A 0x8??????? would be in KSEG0 so cachable.
>
> I do have a an embedded system. Are you saying that, in all likelyhood,
> I do not have coherency? If I understand you correctly, this is a bad
> thing right? Will I need to take extra care to work around this issue.
>
> So are you saying I would prefer a cpu_addr in the 0x8******* range?
No. because you don't seem to have hw coherency.
> If it is true that I don't have hardware coherency should I still be
> using the pci_*_consistent api? Or should I switch to the
> dma_*_noncoherent api? Also what extra steps do I need to take to get
> this to work with a non-coherent system?
What you were doing seemed to be the right thing. The API is supposed
to do the necessary address conversion and cache flushes for the driver.
That is the unchanged driver should work on any architecture.
The dma_* API is a generalization of the slightly older pci_* API. You
can use either one for a PCI device.
In fact on MIPS the pci_* functions are just wrappers around their dma_*
equivalents.
> I am reading Documentation/DMA-API.txt which has some discussion about
> non-coherent systems to see if I can get a handle on this.
>
>
> > What hardware are you using anyway?
>
> I am using the MDS-810 platform supplied by Momentum Data Systems which
> contains a Phillips/Nexperia pnx8950 chip. That chip contains a MIPS32
> core. http://www.mds.com/products/product.asp?prod=MDS-810
According to the current kernel code the PNX8550 non-coheren (aka software
coherency).
Ralf
^ permalink raw reply
* Re: Linux mips and DMA
From: Jon Dufresne @ 2008-01-10 14:12 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20080110134634.GA12060@linux-mips.org>
> Hardware coherency for DMA is the exception for low-end embedded MIPS
> systems andgiven the CPU address your's is no exception from that.
>
> If your system was supporting hardware coherency for DMA I/O you would
> have obtained a cachable CPU address like:
>
> dma_handle=0x026f0000 size=0x00010000 cpu_addr=0x826f0000
> ^^^
>
> A 0x8??????? would be in KSEG0 so cachable.
I do have a an embedded system. Are you saying that, in all likelyhood,
I do not have coherency? If I understand you correctly, this is a bad
thing right? Will I need to take extra care to work around this issue.
So are you saying I would prefer a cpu_addr in the 0x8******* range?
If it is true that I don't have hardware coherency should I still be
using the pci_*_consistent api? Or should I switch to the
dma_*_noncoherent api? Also what extra steps do I need to take to get
this to work with a non-coherent system?
I am reading Documentation/DMA-API.txt which has some discussion about
non-coherent systems to see if I can get a handle on this.
> What hardware are you using anyway?
I am using the MDS-810 platform supplied by Momentum Data Systems which
contains a Phillips/Nexperia pnx8950 chip. That chip contains a MIPS32
core. http://www.mds.com/products/product.asp?prod=MDS-810
Thanks again,
Jon
^ permalink raw reply
* pnx8xxx: move to clocksource
From: Vitaly Wool @ 2008-01-10 14:10 UTC (permalink / raw)
To: ralf; +Cc: linux-mips
This patch converts PNX8XXX system timer to clocksource.
arch/mips/philips/pnx8550/common/time.c | 109 +++++++++++++++++++++-----------
1 files changed, 72 insertions(+), 37 deletions(-)
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Index: linux-2.6/arch/mips/philips/pnx8550/common/time.c
===================================================================
--- linux-2.6.orig/arch/mips/philips/pnx8550/common/time.c
+++ linux-2.6/arch/mips/philips/pnx8550/common/time.c
@@ -22,7 +22,6 @@
#include <linux/kernel_stat.h>
#include <linux/spinlock.h>
#include <linux/interrupt.h>
-#include <linux/module.h>
#include <asm/bootinfo.h>
#include <asm/cpu.h>
@@ -41,11 +40,60 @@ static cycle_t hpt_read(void)
return read_c0_count2();
}
+static struct clocksource pnx_clocksource = {
+ .name = "pnx8xxx",
+ .rating = 200,
+ .read = hpt_read,
+ .flags = CLOCK_SOURCE_IS_CONTINUOUS,
+};
+
static void timer_ack(void)
{
write_c0_compare(cpj);
}
+static irqreturn_t pnx8xxx_timer_interrupt(int irq, void *dev_id)
+{
+ struct clock_event_device *c = dev_id;
+
+ /* clear MATCH, signal the event */
+ c->event_handler(c);
+
+ return IRQ_HANDLED;
+}
+
+static struct irqaction pnx8xxx_timer_irq = {
+ .handler = pnx8xxx_timer_interrupt,
+ .flags = IRQF_DISABLED | IRQF_PERCPU,
+ .name = "pnx8xxx_timer",
+};
+
+static irqreturn_t monotonic_interrupt(int irq, void *dev_id)
+{
+ /* Timer 2 clear interrupt */
+ write_c0_compare2(-1);
+ return IRQ_HANDLED;
+}
+
+static struct irqaction monotonic_irqaction = {
+ .handler = monotonic_interrupt,
+ .flags = IRQF_DISABLED,
+ .name = "Monotonic timer",
+};
+
+static int pnx8xxx_set_next_event(unsigned long delta,
+ struct clock_event_device *evt)
+{
+ write_c0_compare(delta);
+ return 0;
+}
+
+static struct clock_event_device pnx8xxx_clockevent = {
+ .name = "pnx8xxx_clockevent",
+ .features = CLOCK_EVT_FEAT_ONESHOT,
+ .set_next_event = pnx8xxx_set_next_event,
+};
+
/*
* plat_time_init() - it does the following things:
*
@@ -58,11 +106,34 @@ static void timer_ack(void)
__init void plat_time_init(void)
{
+ unsigned int configPR;
unsigned int n;
unsigned int m;
unsigned int p;
unsigned int pow2p;
+ clockevents_register_device(&pnx8xxx_clockevent);
+ clocksource_register(&pnx_clocksource);
+
+ setup_irq(PNX8550_INT_TIMER1, &pnx8xxx_timer_irq);
+ setup_irq(PNX8550_INT_TIMER2, &monotonic_irqaction);
+
+ /* Timer 1 start */
+ configPR = read_c0_config7();
+ configPR &= ~0x00000008;
+ write_c0_config7(configPR);
+
+ /* Timer 2 start */
+ configPR = read_c0_config7();
+ configPR &= ~0x00000010;
+ write_c0_config7(configPR);
+
+ /* Timer 3 stop */
+ configPR = read_c0_config7();
+ configPR |= 0x00000020;
+ write_c0_config7(configPR);
+
+
/* PLL0 sets MIPS clock (PLL1 <=> TM1, PLL6 <=> TM2, PLL5 <=> mem) */
/* (but only if CLK_MIPS_CTL select value [bits 3:1] is 1: FIXME) */
@@ -87,42 +158,6 @@ __init void plat_time_init(void)
write_c0_count2(0);
write_c0_compare2(0xffffffff);
- clocksource_mips.read = hpt_read;
- mips_timer_ack = timer_ack;
-}
-
-static irqreturn_t monotonic_interrupt(int irq, void *dev_id)
-{
- /* Timer 2 clear interrupt */
- write_c0_compare2(-1);
- return IRQ_HANDLED;
}
-static struct irqaction monotonic_irqaction = {
- .handler = monotonic_interrupt,
- .flags = IRQF_DISABLED,
- .name = "Monotonic timer",
-};
-void __init plat_timer_setup(struct irqaction *irq)
-{
- int configPR;
-
- setup_irq(PNX8550_INT_TIMER1, irq);
- setup_irq(PNX8550_INT_TIMER2, &monotonic_irqaction);
-
- /* Timer 1 start */
- configPR = read_c0_config7();
- configPR &= ~0x00000008;
- write_c0_config7(configPR);
-
- /* Timer 2 start */
- configPR = read_c0_config7();
- configPR &= ~0x00000010;
- write_c0_config7(configPR);
-
- /* Timer 3 stop */
- configPR = read_c0_config7();
- configPR |= 0x00000020;
- write_c0_config7(configPR);
-}
^ permalink raw reply
* Re: Linux mips and DMA
From: Ralf Baechle @ 2008-01-10 13:46 UTC (permalink / raw)
To: Jon Dufresne; +Cc: linux-mips
In-Reply-To: <1199971818.4344.5.camel@microwave.infinitevideocorporation.com>
On Thu, Jan 10, 2008 at 08:30:16AM -0500, Jon Dufresne wrote:
> > MIPS hardware is different so pci_alloc_consistent is implemented
> > differently. For correct use however this should not matter. Any bugs
> > you may find porting to MIPS were already bugs on x86.
> >
> > (Or in pci_alloc_consistent but I'm optimistic ;-)
>
>
> Is there a chance that my platform does not support coherent DMA
> mappings? Or is this unheard of for a MIPs platform?
Hardware coherency for DMA is the exception for low-end embedded MIPS
systems andgiven the CPU address your's is no exception from that.
If your system was supporting hardware coherency for DMA I/O you would
have obtained a cachable CPU address like:
dma_handle=0x026f0000 size=0x00010000 cpu_addr=0x826f0000
^^^
A 0x8??????? would be in KSEG0 so cachable.
What hardware are you using anyway?
Ralf
^ permalink raw reply
* Re: Linux mips and DMA
From: Jon Dufresne @ 2008-01-10 13:30 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20080110113931.GA4774@linux-mips.org>
> MIPS hardware is different so pci_alloc_consistent is implemented
> differently. For correct use however this should not matter. Any bugs
> you may find porting to MIPS were already bugs on x86.
>
> (Or in pci_alloc_consistent but I'm optimistic ;-)
Is there a chance that my platform does not support coherent DMA
mappings? Or is this unheard of for a MIPs platform?
Thanks for the help!
Jon
^ permalink raw reply
* Re: Linux mips and DMA
From: Ralf Baechle @ 2008-01-10 11:39 UTC (permalink / raw)
To: Jon Dufresne; +Cc: linux-mips
In-Reply-To: <1199905038.3572.8.camel@microwave.infinitevideocorporation.com>
On Wed, Jan 09, 2008 at 01:57:17PM -0500, Jon Dufresne wrote:
> I am in the process of porting a known working linux driver for a pci
> device from an x86 machine to a mips machine. This is my first time
> developing a driver under mips (but not the first time with x86) so I am
> learning some of the differences and gotchas that exist when porting a
> driver like this.
>
> My most recent problem exists when setting up dma between the host and
> the device. I am using the following two websites as guides for doing
> this:
>
> https://lwn.net/Articles/28230/
> https://lwn.net/Articles/28092/
The articles are fairly old and the APIs and their documentation are
occasionally changing. I suggest you use Documentation/DMA-mapping.txt
as the primary documentation - though as usual Jonathan Corbet's article
is very well written.
> In addition I am using LDD.
>
> To create the dma memory area I am using the function
> "pci_alloc_consistent". When I pass the "dma_handle" (as I understand it
> the host's physical address of the dma memory), to the pci device, the
> device in the x86 box correctly access this memory, not so in the mips
> box.
>
> Not sure if this is helpful, but the fuction returns the following
> addresses on the mips when I use it:
>
> dma_handle=0x026f0000 size=0x00010000 cpu_addr=0xa26f0000
>
> Does this physical address seem abnormally low? It is well outside the
> range of the PCI BARs which exist around 0x20000000.
There is no relation to the PCI bars whatsoever. pci_alloc_consistent
works on a memory that is RAM range. 0xa26f0000 is an uncached address
in KSEG1 and 0x026f0000 the equivalent physical address.
All these numbers look sane which suggest your problem may be elsewhere.
One potencial problem might be that bus addresses as used on the PCI bus
and physical addresses as use by the CPU are not identical. The
return value of pci_alloc_consistent shows that your kernel is setup
to assume that both addresses are identical. Which is true on most
x86 and MIPS platforms but not all.
Note you may not touch a cached mapping of this range for example
0x826f0000 in KSEG0 or any other cached mapping you may have created or
data corruption will happen.
> Anything I should know about using pci_alloc_consistent on a mips?
MIPS hardware is different so pci_alloc_consistent is implemented
differently. For correct use however this should not matter. Any bugs
you may find porting to MIPS were already bugs on x86.
(Or in pci_alloc_consistent but I'm optimistic ;-)
Ralf
^ permalink raw reply
* Re: MIPS 4KEc with 2.6.15
From: Jorgen Lundman @ 2008-01-10 4:06 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <47853CA4.9020503@avtrex.com>
Sure, and I agree. We both know how often than happens, or how quickly.
So, while we hold our breath for that to happen, mean while, I am hoping
to find the TangoX mips-board details somewhere...
David Daney wrote:
> Jorgen Lundman wrote:
>> Yeha I would love to use tangox, but there is none with Linux, at
>> least no tarball of the kernel I have found?
>>
>> Where can I get tangox?
>>
>> Lund
>>
> The Linux kernel is GPL, whoever gave you the board and the kernel
> should give you the kernel source.
>
> David Daney
>
>
--
Jorgen Lundman | <lundman@lundman.net>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
^ permalink raw reply
* Re: MIPS 4KEc with 2.6.15
From: David Daney @ 2008-01-09 21:29 UTC (permalink / raw)
To: Jorgen Lundman; +Cc: Mark Lin, linux-mips
In-Reply-To: <4784008A.1020106@lundman.net>
Jorgen Lundman wrote:
> Yeha I would love to use tangox, but there is none with Linux, at
> least no tarball of the kernel I have found?
>
> Where can I get tangox?
>
> Lund
>
The Linux kernel is GPL, whoever gave you the board and the kernel
should give you the kernel source.
David Daney
^ permalink raw reply
* Linux mips and DMA
From: Jon Dufresne @ 2008-01-09 18:57 UTC (permalink / raw)
To: linux-mips
Hello,
I am in the process of porting a known working linux driver for a pci
device from an x86 machine to a mips machine. This is my first time
developing a driver under mips (but not the first time with x86) so I am
learning some of the differences and gotchas that exist when porting a
driver like this.
My most recent problem exists when setting up dma between the host and
the device. I am using the following two websites as guides for doing
this:
https://lwn.net/Articles/28230/
https://lwn.net/Articles/28092/
In addition I am using LDD.
To create the dma memory area I am using the function
"pci_alloc_consistent". When I pass the "dma_handle" (as I understand it
the host's physical address of the dma memory), to the pci device, the
device in the x86 box correctly access this memory, not so in the mips
box.
Not sure if this is helpful, but the fuction returns the following
addresses on the mips when I use it:
dma_handle=0x026f0000 size=0x00010000 cpu_addr=0xa26f0000
Does this physical address seem abnormally low? It is well outside the
range of the PCI BARs which exist around 0x20000000.
Anything I should know about using pci_alloc_consistent on a mips?
If you need more information to understand the situation I'd be happy to
supply it but right now I'm not sure what to supply.
Thanks,
Jon
^ permalink raw reply
* Re: memory dump on mips
From: Andi @ 2008-01-09 14:49 UTC (permalink / raw)
To: linux-mips
Hello,
Thiemo Seufer wrote:
> > This sounds like you are confusing physical and virtual addresses.
> > Typically the kernel is loaded to the direct-mapped KSEG0 segment,
> > which starts at physical 0x00000000 / virtual 0x80000000.
Thank you for pointing on that. I was not sure if this was virtual or
physical since i grabbed this address from a serial-debug output. But if
one thinks about that the device has around 128mb it should be clear
that this can't be a physical address if ram starts at 0x00000000.
We'll check this ..
Regards,
Andi
^ permalink raw reply
* 答复: kseg1 uncache access issue
From: lovecentry @ 2008-01-09 13:20 UTC (permalink / raw)
To: 'Ralf Baechle', 'Thomas Bogendoerfer'; +Cc: linux-mips
In-Reply-To: <20080108185903.GC30643@linux-mips.org>
Hi gents
Thanks for your reply. Now I try to implement MIPS R10000
microprcoessor simulation with C language, so many issues still puzzle me
although I have read MIPS R10000 Microprocessor paper introduced by Yeager
1996 more than ten times since last year.
As Thomas said, R10K will access directly to dram for those uncached
load/store operations. Which path in the MIPS R10k makes it available? Is
system interface does that stuff? I found it has uncached buffer.
Another issue arises, as system brings up the PC will be assigned to
0xbfc00000 and it need to fetch instructions from dram directly rather than
dram then put first four instructions into decode/remap unit, but from the
MIPS R10000 diagram decode/remap unit only get instructions from ICACHE. How
MIPS R10000 handle this case?
Tony
-----邮件原件-----
发件人: Ralf Baechle [mailto:ralf@linux-mips.org]
发送时间: 2008年1月9日 2:59
收件人: Thomas Bogendoerfer
抄送: lovecentry; linux-mips@linux-mips.org
主题: Re: kseg1 uncache access issue
On Tue, Jan 08, 2008 at 06:02:06PM +0100, Thomas Bogendoerfer wrote:
> On Wed, Jan 09, 2008 at 12:35:06AM +0800, lovecentry wrote:
> > As we know in mips achitecture if current pc falls into kseg1 segment,
any
> > memory reference will bypass cache and fetch directly from dram. But for
> > some prcoessor such like mips R10K it has off chip L2 cache. I haven't
found
>
> why do you think so ? R10k L2 cache controller is inside CPU and any
> access with uncached attribute will go directly to memory. The only
> systems, where this might be different are systems with caches unknown
> to the cpu. But even those usually obey that uncached accesses are
> going directly to memory.
It should also be mentioned that some R10000 machines do odd stuff with
uncached addresses.
IP27 class machines reuse the entire physical address space several times
to map different things. The selection of the four uncached address
spaces id done by the uncached attribute which is specified either in
the TLB or or as as bit 59..60 of a virtual address in XKPHYS.
The memory controller of the Indigo 2 R10000 needs to be switched to a
special slower mode to allow uncached accesses first.
Ralf
^ permalink raw reply
* 答复: kseg1 uncache access issue
From: lovecentry @ 2008-01-09 13:20 UTC (permalink / raw)
To: 'Ralf Baechle', 'Thomas Bogendoerfer'; +Cc: linux-mips
In-Reply-To: <20080108185903.GC30643@linux-mips.org>
Hi gents
Thanks for your reply. Now I try to implement MIPS R10000
microprcoessor simulation with C language, so many issues still puzzle me
although I have read MIPS R10000 Microprocessor paper introduced by Yeager
1996 more than ten times since last year.
As Thomas said, R10K will access directly to dram for those uncached
load/store operations. Which path in the MIPS R10k makes it available? Is
system interface does that stuff? I found it has uncached buffer.
Another issue arises, as system brings up the PC will be assigned to
0xbfc00000 and it need to fetch instructions from dram directly rather than
dram then put first four instructions into decode/remap unit, but from the
MIPS R10000 diagram decode/remap unit only get instructions from ICACHE. How
MIPS R10000 handle this case?
Tony
-----邮件原件-----
发件人: Ralf Baechle [mailto:ralf@linux-mips.org]
发送时间: 2008年1月9日 2:59
收件人: Thomas Bogendoerfer
抄送: lovecentry; linux-mips@linux-mips.org
主题: Re: kseg1 uncache access issue
On Tue, Jan 08, 2008 at 06:02:06PM +0100, Thomas Bogendoerfer wrote:
> On Wed, Jan 09, 2008 at 12:35:06AM +0800, lovecentry wrote:
> > As we know in mips achitecture if current pc falls into kseg1 segment,
any
> > memory reference will bypass cache and fetch directly from dram. But for
> > some prcoessor such like mips R10K it has off chip L2 cache. I haven't
found
>
> why do you think so ? R10k L2 cache controller is inside CPU and any
> access with uncached attribute will go directly to memory. The only
> systems, where this might be different are systems with caches unknown
> to the cpu. But even those usually obey that uncached accesses are
> going directly to memory.
It should also be mentioned that some R10000 machines do odd stuff with
uncached addresses.
IP27 class machines reuse the entire physical address space several times
to map different things. The selection of the four uncached address
spaces id done by the uncached attribute which is specified either in
the TLB or or as as bit 59..60 of a virtual address in XKPHYS.
The memory controller of the Indigo 2 R10000 needs to be switched to a
special slower mode to allow uncached accesses first.
Ralf
^ permalink raw reply
* Re: Toshiba JMR 3927 working setup?
From: Thiemo Seufer @ 2008-01-09 0:17 UTC (permalink / raw)
To: Gregor Waltz; +Cc: linux-mips
In-Reply-To: <47840D53.50009@raritan.com>
Gregor Waltz wrote:
> Ralf Baechle wrote:
>> You may want to switch to a recent binutils like 2.18 and gcc 4.2.2.
>
> Ralf, are you or anybody else using that combination for mips?
>
> With which versions of glibc and glibc-linuxthreads?
>
> I have been having a joyous time trying to build more recent tools.
> I keep getting errors like the following when building glibc of any
> version (tried from 2.3.6 through 2.7):
> sysdeps/unix/sysv/linux/waitid.c:51: error: memory input 6 is not
> directly addressable
>
> I found a patch for that
> (http://sourceware.org/ml/crossgcc/2005-04/msg00208.html), but, after
> passing that file, it fails similarly on pread.c. It seems to be an
> issue with INLINE_SYSCALL, rather than the call sites, that appears to
> be related to later versions of gcc.
>
> Later versions of glibc (2.7, 2.6...) fail at configure time with the
> error: "The mipsel is not supported."
This suggests you are missing the "ports" add-on.
> So, what are the lastest versions of the build tools that people are
> using on mips?
Debian uses binutils 2.18+, gcc 4.2 and glibc 2.7 in the "unstable"
development branch. This environment works fine for me.
Thiemo
^ permalink raw reply
* Re: Toshiba JMR 3927 working setup?
From: Gregor Waltz @ 2008-01-08 23:54 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20080105144535.GA12824@linux-mips.org>
Ralf Baechle wrote:
> You may want to switch to a recent binutils like 2.18 and gcc 4.2.2.
Ralf, are you or anybody else using that combination for mips?
With which versions of glibc and glibc-linuxthreads?
I have been having a joyous time trying to build more recent tools.
I keep getting errors like the following when building glibc of any
version (tried from 2.3.6 through 2.7):
sysdeps/unix/sysv/linux/waitid.c:51: error: memory input 6 is not
directly addressable
I found a patch for that
(http://sourceware.org/ml/crossgcc/2005-04/msg00208.html), but, after
passing that file, it fails similarly on pread.c. It seems to be an
issue with INLINE_SYSCALL, rather than the call sites, that appears to
be related to later versions of gcc.
Later versions of glibc (2.7, 2.6...) fail at configure time with the
error: "The mipsel is not supported."
So, what are the lastest versions of the build tools that people are
using on mips?
Thanks
^ permalink raw reply
* Re: MIPS 4KEc with 2.6.15
From: Jorgen Lundman @ 2008-01-08 23:00 UTC (permalink / raw)
To: Mark Lin; +Cc: linux-mips
In-Reply-To: <24f397b0801081402j24f7000cr841090ba5ab9bcc1@mail.gmail.com>
Yeha I would love to use tangox, but there is none with Linux, at least
no tarball of the kernel I have found?
Where can I get tangox?
Lund
Mark Lin wrote:
> Jorgen,
>
> You should not be using the atlas definition. Try the tangox one instead.
>
> With the flush_cache_page changes, FUSE works fine for me using 2.6.15
> and Sigma's tango2 board.
>
> Mark Lin
>
> On Jan 7, 2008 10:52 AM, David Daney <ddaney@avtrex.com> wrote:
>> Jorgen Lundman wrote:
>>> Hello list,
>>>
>>> I have an embedded device running 2.6.15 kernel on a MIPS 4KEc 300MHz
>>> CPU. It was configured for Sigma's tango2 board, which I know nothing
>>> about, so I picked a mips-board by random, "atlas", and found I can
>>> produce working kernel module compiles.
>>>
>>> However, when I compiled FUSE kernel module, it behaves erratically in
>>> a way making the FUSE developer think I may have come across the cache
>>> coherency bug in arm and mips, fixed sometime around 2.6.17.
>>>
>>> Since I can not change the kernel that is running, I was looking for
>>> alternate solutions. FUSE itself has a work around, that calls
>>> flush_cache_page(), but I found that mips-board atlas does not have
>>> this defined:
>>>
>>> fuse: Unknown symbol flush_cache_page
>> There are cache coherency issues on the 8634. You should be using the
>> vendor's very most recent kernels. For me they seem to have resolved
>> the cache issues.
>>
>> Also as noted by others, you need the exact kernel sources if you are
>> going to build working modules.
>>
>> David Daney
>>
>>
>
--
Jorgen Lundman | <lundman@lundman.net>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
^ permalink raw reply
* Re: MIPS 4KEc with 2.6.15
From: Mark Lin @ 2008-01-08 22:02 UTC (permalink / raw)
To: Jorgen Lundman; +Cc: linux-mips
In-Reply-To: <47824ACF.7050003@avtrex.com>
Jorgen,
You should not be using the atlas definition. Try the tangox one instead.
With the flush_cache_page changes, FUSE works fine for me using 2.6.15
and Sigma's tango2 board.
Mark Lin
On Jan 7, 2008 10:52 AM, David Daney <ddaney@avtrex.com> wrote:
> Jorgen Lundman wrote:
> >
> > Hello list,
> >
> > I have an embedded device running 2.6.15 kernel on a MIPS 4KEc 300MHz
> > CPU. It was configured for Sigma's tango2 board, which I know nothing
> > about, so I picked a mips-board by random, "atlas", and found I can
> > produce working kernel module compiles.
> >
> > However, when I compiled FUSE kernel module, it behaves erratically in
> > a way making the FUSE developer think I may have come across the cache
> > coherency bug in arm and mips, fixed sometime around 2.6.17.
> >
> > Since I can not change the kernel that is running, I was looking for
> > alternate solutions. FUSE itself has a work around, that calls
> > flush_cache_page(), but I found that mips-board atlas does not have
> > this defined:
> >
> > fuse: Unknown symbol flush_cache_page
>
> There are cache coherency issues on the 8634. You should be using the
> vendor's very most recent kernels. For me they seem to have resolved
> the cache issues.
>
> Also as noted by others, you need the exact kernel sources if you are
> going to build working modules.
>
> David Daney
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox