* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
@ 2008-11-21 7:34 ` Paul Mundt
2008-11-21 10:08 ` Kristoffer Ericson
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Paul Mundt @ 2008-11-21 7:34 UTC (permalink / raw)
To: linux-sh
On Thu, Nov 20, 2008 at 01:16:00AM +0100, Kristoffer Ericson wrote:
> HD64461 configured at 0xb0000000 on irq 36(mapped into 64 to 79)
> HD64461: enabling PCMCIA devices
[snip]
> scsi0 : pata_platform
> ata1: PATA max PIO0 mmio cmd 0x150001f0 ctl 0x150001fe irq 77
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pc = 00000000
> *pde = 00000000
> Oops: 0000 [#1]
> Modules linked in:
>
> Pid : 0, Comm: swapper
> PC is at 0x0
> PC : 00000000 SP : 8d291f54 SR : 400001f1 TEA : 00000000 Not tainted
> R0 : 0000004d R1 : 00000000 R2 : 8d2c1a98 R3 : 0000000f
> R4 : 0000004d R5 : 8d29970c R6 : 00000019 R7 : ffffffff
> R8 : 8d2cec0c R9 : 00000000 R10 : 00000034 R11 : 8d2c009c
> R12 : 8d21bb80 R13 : 8d2c005c R14 : 8d013cc0
> MACH: 000071c6 MACL: 000010d8 GBR : 8c009800 PR : 8d0036c4
>
> Call trace:
> [<8d0070e8>] ret_from_irq+0x0/0x10
> [<8d066130>] quicklist_trim+0x0/0x120
> [<8d003690>] do_IRQ+0x0/0x60
> [<8d003730>] default_idle+0x0/0xd0
> [<8d066130>] quicklist_trim+0x0/0x120
> [<8d21bb80>] __sched_text_start+0x0/0x4b0
> [<8d013cc0>] printk+0x0/0x20
> [<8d003782>] default_idle+0x52/0xd0
> [<8d003854>] cpu_idle+0x54/0xb0
> [<8d2a994e>] start_kernel+0x4ee/0x560
> [<8d2ae4f0>] __alloc_bootmem+0x0/0x10
> [<8d0e7810>] strlen+0x0/0x60
> [<8d002024>] _stext+0x24/0x30
On Thu, Nov 20, 2008 at 06:04:48PM +0100, Kristoffer Ericson wrote:
> 5093c9a4e41518425d42c0bb5bb92f514ec77b1d is first bad commit
> commit 5093c9a4e41518425d42c0bb5bb92f514ec77b1d
> Author: Paul Mundt <lethal@linux-sh.org>
> Date: Mon Aug 4 14:17:13 2008 +0900
>
> sh: define GENERIC_HARDIRQS_NO__DO_IRQ.
>
> We haven't called in to __do_IRQ() in a long time, so it seems like a
> reasonable time to switch this on by default.
>
> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
>
> :040000 040000 cf3a9f428a81b93dcdc7d8da101ef722b6e0159e 563fcba3d9482fd80e8f4f9b02178eb17567bbb7 M arch
>
> Paul, thoughts about this?
>
The only relevant change here is the dispatch in include/linux/irq.h.
With this patch reverted, the call goes through __do_IRQ() if there is no
desc->handle_irq(). Given that the hd64461 code maps the vector that
blows up, the implication is that the hd64461 interrupt code is broken.
Indeed, looking at the code, I suspect it is the demux that is where the
problem comes from, given that the hd64461 irq code does its own special
thing and completely bypasses the generic hardirq layer for chained
handlers.
So, pending a rewrite of hd64461, we should probably just leave the
__do_IRQ() dispatch as an option there, until someone gets around to
rewriting that mess. I will conditionalize it on !HD64461 for now.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
2008-11-21 7:34 ` Paul Mundt
@ 2008-11-21 10:08 ` Kristoffer Ericson
2008-11-22 16:49 ` Matt Fleming
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Kristoffer Ericson @ 2008-11-21 10:08 UTC (permalink / raw)
To: linux-sh
Appreciate it.
As I said the other bug (the complete cold reboot) was my hd64461-mfd
driver's fault. I've fixed it now, seemed to be caused by
hd64461 io functions being used without the base adress being
initialized (doh!).
So far the hd64461-mfd handles the IRQ's and io functions, I'm working
on integrating the framebuffer. So the driver is progressing
although alot slower than I expect (mfd's are alot more complex than
I first realized).
Best wishes
Kristoffer
2008/11/21, Paul Mundt <lethal@linux-sh.org>:
> On Thu, Nov 20, 2008 at 01:16:00AM +0100, Kristoffer Ericson wrote:
>> HD64461 configured at 0xb0000000 on irq 36(mapped into 64 to 79)
>> HD64461: enabling PCMCIA devices
> [snip]
>> scsi0 : pata_platform
>> ata1: PATA max PIO0 mmio cmd 0x150001f0 ctl 0x150001fe irq 77
>> Unable to handle kernel NULL pointer dereference at virtual address
>> 00000000
>> pc = 00000000
>> *pde = 00000000
>> Oops: 0000 [#1]
>> Modules linked in:
>>
>> Pid : 0, Comm: swapper
>> PC is at 0x0
>> PC : 00000000 SP : 8d291f54 SR : 400001f1 TEA : 00000000 Not tainted
>> R0 : 0000004d R1 : 00000000 R2 : 8d2c1a98 R3 : 0000000f
>> R4 : 0000004d R5 : 8d29970c R6 : 00000019 R7 : ffffffff
>> R8 : 8d2cec0c R9 : 00000000 R10 : 00000034 R11 : 8d2c009c
>> R12 : 8d21bb80 R13 : 8d2c005c R14 : 8d013cc0
>> MACH: 000071c6 MACL: 000010d8 GBR : 8c009800 PR : 8d0036c4
>>
>> Call trace:
>> [<8d0070e8>] ret_from_irq+0x0/0x10
>> [<8d066130>] quicklist_trim+0x0/0x120
>> [<8d003690>] do_IRQ+0x0/0x60
>> [<8d003730>] default_idle+0x0/0xd0
>> [<8d066130>] quicklist_trim+0x0/0x120
>> [<8d21bb80>] __sched_text_start+0x0/0x4b0
>> [<8d013cc0>] printk+0x0/0x20
>> [<8d003782>] default_idle+0x52/0xd0
>> [<8d003854>] cpu_idle+0x54/0xb0
>> [<8d2a994e>] start_kernel+0x4ee/0x560
>> [<8d2ae4f0>] __alloc_bootmem+0x0/0x10
>> [<8d0e7810>] strlen+0x0/0x60
>> [<8d002024>] _stext+0x24/0x30
>
> On Thu, Nov 20, 2008 at 06:04:48PM +0100, Kristoffer Ericson wrote:
>> 5093c9a4e41518425d42c0bb5bb92f514ec77b1d is first bad commit
>> commit 5093c9a4e41518425d42c0bb5bb92f514ec77b1d
>> Author: Paul Mundt <lethal@linux-sh.org>
>> Date: Mon Aug 4 14:17:13 2008 +0900
>>
>> sh: define GENERIC_HARDIRQS_NO__DO_IRQ.
>>
>> We haven't called in to __do_IRQ() in a long time, so it seems like a
>> reasonable time to switch this on by default.
>>
>> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
>>
>> :040000 040000 cf3a9f428a81b93dcdc7d8da101ef722b6e0159e
>> 563fcba3d9482fd80e8f4f9b02178eb17567bbb7 M arch
>>
>> Paul, thoughts about this?
>>
> The only relevant change here is the dispatch in include/linux/irq.h.
> With this patch reverted, the call goes through __do_IRQ() if there is no
> desc->handle_irq(). Given that the hd64461 code maps the vector that
> blows up, the implication is that the hd64461 interrupt code is broken.
> Indeed, looking at the code, I suspect it is the demux that is where the
> problem comes from, given that the hd64461 irq code does its own special
> thing and completely bypasses the generic hardirq layer for chained
> handlers.
>
> So, pending a rewrite of hd64461, we should probably just leave the
> __do_IRQ() dispatch as an option there, until someone gets around to
> rewriting that mess. I will conditionalize it on !HD64461 for now.
>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
2008-11-21 7:34 ` Paul Mundt
2008-11-21 10:08 ` Kristoffer Ericson
@ 2008-11-22 16:49 ` Matt Fleming
2008-11-25 17:40 ` Kristoffer Ericson
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Matt Fleming @ 2008-11-22 16:49 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
On Fri, Nov 21, 2008 at 04:34:45PM +0900, Paul Mundt wrote:
>
> So, pending a rewrite of hd64461, we should probably just leave the
> __do_IRQ() dispatch as an option there, until someone gets around to
> rewriting that mess. I will conditionalize it on !HD64461 for now.
Kristoffer can you try the attached patch, please? It compiles OK but I
haven't had chance to test it on actual hardware.
[-- Attachment #2: 0001-sh-Switch-HD64461-from-hw_interrupt_type-to-irq_chi.patch --]
[-- Type: text/plain, Size: 5075 bytes --]
From 7258c0f9c1a2cf01a87d67d6221daf6dd79fa3e8 Mon Sep 17 00:00:00 2001
From: Matt Fleming <mjf@gentoo.org>
Date: Sat, 22 Nov 2008 16:24:35 +0000
Subject: [PATCH] sh: Switch HD64461 from hw_interrupt_type to irq_chip
Use struct irq_chip for the interrupt handler for the HD64461. Also
convert some in{b,w} and out{b,w} calls to the equivalent __raw_* calls.
This is the first step to allow machines with HD64461 to define
GENERIC_HARDIRQS_NO__DO_IRQ.
Signed-off-by: Matt Fleming <mjf@gentoo.org>
---
arch/sh/cchips/hd6446x/hd64461.c | 111 ++++++++-----------------------------
1 files changed, 24 insertions(+), 87 deletions(-)
diff --git a/arch/sh/cchips/hd6446x/hd64461.c b/arch/sh/cchips/hd6446x/hd64461.c
index f1a4a07..a550833 100644
--- a/arch/sh/cchips/hd6446x/hd64461.c
+++ b/arch/sh/cchips/hd6446x/hd64461.c
@@ -17,90 +17,42 @@
/* This belongs in cpu specific */
#define INTC_ICR1 0xA4140010UL
-static void disable_hd64461_irq(unsigned int irq)
+static void hd64461_mask_irq(unsigned int irq)
{
unsigned short nimr;
unsigned short mask = 1 << (irq - HD64461_IRQBASE);
- nimr = inw(HD64461_NIMR);
+ nimr = __raw_readw(HD64461_NIMR);
nimr |= mask;
- outw(nimr, HD64461_NIMR);
+ __raw_writew(nimr, HD64461_NIMR);
}
-static void enable_hd64461_irq(unsigned int irq)
+static void hd64461_unmask_irq(unsigned int irq)
{
unsigned short nimr;
unsigned short mask = 1 << (irq - HD64461_IRQBASE);
- nimr = inw(HD64461_NIMR);
+ nimr = __raw_readw(HD64461_NIMR);
nimr &= ~mask;
- outw(nimr, HD64461_NIMR);
+ __raw_writew(nimr, HD64461_NIMR);
}
-static void mask_and_ack_hd64461(unsigned int irq)
+static void hd64461_mask_and_ack_irq(unsigned int irq)
{
- disable_hd64461_irq(irq);
+ hd64461_mask_irq(irq);
#ifdef CONFIG_HD64461_ENABLER
if (irq == HD64461_IRQBASE + 13)
- outb(0x00, HD64461_PCC1CSCR);
+ __raw_writeb(0x00, HD64461_PCC1CSCR);
#endif
}
-static void end_hd64461_irq(unsigned int irq)
-{
- if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)))
- enable_hd64461_irq(irq);
-}
-
-static unsigned int startup_hd64461_irq(unsigned int irq)
-{
- enable_hd64461_irq(irq);
- return 0;
-}
-
-static void shutdown_hd64461_irq(unsigned int irq)
-{
- disable_hd64461_irq(irq);
-}
-
-static struct hw_interrupt_type hd64461_irq_type = {
- .typename = "HD64461-IRQ",
- .startup = startup_hd64461_irq,
- .shutdown = shutdown_hd64461_irq,
- .enable = enable_hd64461_irq,
- .disable = disable_hd64461_irq,
- .ack = mask_and_ack_hd64461,
- .end = end_hd64461_irq,
+static struct irq_chip hd64461_irq_chip = {
+ .name = "HD64461-IRQ",
+ .mask = hd64461_mask_irq,
+ .mask_ack = hd64461_mask_and_ack_irq,
+ .unmask = hd64461_unmask_irq,
};
-static irqreturn_t hd64461_interrupt(int irq, void *dev_id)
-{
- printk(KERN_INFO
- "HD64461: spurious interrupt, nirr: 0x%x nimr: 0x%x\n",
- inw(HD64461_NIRR), inw(HD64461_NIMR));
-
- return IRQ_NONE;
-}
-
-static struct {
- int (*func) (int, void *);
- void *dev;
-} hd64461_demux[HD64461_IRQ_NUM];
-
-void hd64461_register_irq_demux(int irq,
- int (*demux) (int irq, void *dev), void *dev)
-{
- hd64461_demux[irq - HD64461_IRQBASE].func = demux;
- hd64461_demux[irq - HD64461_IRQBASE].dev = dev;
-}
-
-EXPORT_SYMBOL(hd64461_register_irq_demux);
-
-void hd64461_unregister_irq_demux(int irq)
-{
- hd64461_demux[irq - HD64461_IRQBASE].func = 0;
-}
-
EXPORT_SYMBOL(hd64461_unregister_irq_demux);
int hd64461_irq_demux(int irq)
@@ -115,25 +67,11 @@ int hd64461_irq_demux(int irq)
for (bit = 1, i = 0; i < 16; bit <<= 1, i++)
if (nirr & bit)
break;
- if (i == 16)
- irq = CONFIG_HD64461_IRQ;
- else {
- irq = HD64461_IRQBASE + i;
- if (hd64461_demux[i].func != 0) {
- irq = hd64461_demux[i].func(irq, hd64461_demux[i].dev);
- }
- }
+ irq = HD64461_IRQBASE + i;
}
return irq;
}
-static struct irqaction irq0 = {
- .handler = hd64461_interrupt,
- .flags = IRQF_DISABLED,
- .mask = CPU_MASK_NONE,
- .name = "HD64461",
-};
-
int __init setup_hd64461(void)
{
int i;
@@ -146,22 +84,21 @@ int __init setup_hd64461(void)
CONFIG_HD64461_IOBASE, CONFIG_HD64461_IRQ, HD64461_IRQBASE,
HD64461_IRQBASE + 15);
-#if defined(CONFIG_CPU_SUBTYPE_SH7709) /* Should be at processor specific part.. */
- outw(0x2240, INTC_ICR1);
+/* Should be at processor specific part.. */
+#if defined(CONFIG_CPU_SUBTYPE_SH7709)
+ __raw_writew(0x2240, INTC_ICR1);
#endif
- outw(0xffff, HD64461_NIMR);
+ __raw_writew(0xffff, HD64461_NIMR);
/* IRQ 80 -> 95 belongs to HD64461 */
- for (i = HD64461_IRQBASE; i < HD64461_IRQBASE + 16; i++) {
- irq_desc[i].chip = &hd64461_irq_type;
- }
-
- setup_irq(CONFIG_HD64461_IRQ, &irq0);
+ for (i = HD64461_IRQBASE; i < HD64461_IRQBASE + 16; i++)
+ set_irq_chip_and_handler(i, &hd64461_irq_chip,
+ handle_level_irq);
#ifdef CONFIG_HD64461_ENABLER
printk(KERN_INFO "HD64461: enabling PCMCIA devices\n");
- outb(0x4c, HD64461_PCC1CSCIER);
- outb(0x00, HD64461_PCC1CSCR);
+ __raw_writeb(0x4c, HD64461_PCC1CSCIER);
+ __raw_writeb(0x00, HD64461_PCC1CSCR);
#endif
return 0;
--
1.5.6.4
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (2 preceding siblings ...)
2008-11-22 16:49 ` Matt Fleming
@ 2008-11-25 17:40 ` Kristoffer Ericson
2008-11-25 17:54 ` Paul Mundt
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Kristoffer Ericson @ 2008-11-25 17:40 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 845 bytes --]
On Sat, 22 Nov 2008 16:49:52 +0000
Matt Fleming <mjf@gentoo.org> wrote:
> On Fri, Nov 21, 2008 at 04:34:45PM +0900, Paul Mundt wrote:
> >
> > So, pending a rewrite of hd64461, we should probably just leave the
> > __do_IRQ() dispatch as an option there, until someone gets around to
> > rewriting that mess. I will conditionalize it on !HD64461 for now.
>
> Kristoffer can you try the attached patch, please? It compiles OK but I
> haven't had chance to test it on actual hardware.
Sorry for the late reply, been having issues with my internet
connection. Anyhow, not sure if this solves anything since
I've already rewritten the IRQ part to be alot more
sensible. Basicly only wanting to get FB going
before I push it upstreams.
What you think Paul?
>
>
--
Kristoffer Ericson <kristoffer.ericson@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (3 preceding siblings ...)
2008-11-25 17:40 ` Kristoffer Ericson
@ 2008-11-25 17:54 ` Paul Mundt
2008-11-25 18:47 ` Kristoffer Ericson
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Paul Mundt @ 2008-11-25 17:54 UTC (permalink / raw)
To: linux-sh
On Tue, Nov 25, 2008 at 07:40:39PM +0100, Kristoffer Ericson wrote:
> On Sat, 22 Nov 2008 16:49:52 +0000
> Matt Fleming <mjf@gentoo.org> wrote:
>
> > On Fri, Nov 21, 2008 at 04:34:45PM +0900, Paul Mundt wrote:
> > >
> > > So, pending a rewrite of hd64461, we should probably just leave the
> > > __do_IRQ() dispatch as an option there, until someone gets around to
> > > rewriting that mess. I will conditionalize it on !HD64461 for now.
> >
> > Kristoffer can you try the attached patch, please? It compiles OK but I
> > haven't had chance to test it on actual hardware.
>
> Sorry for the late reply, been having issues with my internet
> connection. Anyhow, not sure if this solves anything since
> I've already rewritten the IRQ part to be alot more
> sensible. Basicly only wanting to get FB going
> before I push it upstreams.
>
> What you think Paul?
>
Matt's patch should allow us to fix the __do_IRQ() problem, if you want
to build on top of that, that is fine, but it is still helpful to know
whether it works for you with CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ enabled.
The only problematic thing I see is the lack of the base IRQ factoring,
only the chained handlers for the multiplexed sources are defined. This
is the way it should be, but it is possible that there will have to be
another handler set up to at least get the hd64461 IRQ firing. This is
the basis for that silly i = 16 thing in the old demux code. Any user
that depends on that behaviour deserves to be broken, though.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (4 preceding siblings ...)
2008-11-25 17:54 ` Paul Mundt
@ 2008-11-25 18:47 ` Kristoffer Ericson
2008-11-25 19:50 ` Paul Mundt
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Kristoffer Ericson @ 2008-11-25 18:47 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 8081 bytes --]
On Wed, 26 Nov 2008 02:54:26 +0900
Paul Mundt <lethal@linux-sh.org> wrote:
> On Tue, Nov 25, 2008 at 07:40:39PM +0100, Kristoffer Ericson wrote:
> > On Sat, 22 Nov 2008 16:49:52 +0000
> > Matt Fleming <mjf@gentoo.org> wrote:
> >
> > > On Fri, Nov 21, 2008 at 04:34:45PM +0900, Paul Mundt wrote:
> > > >
> > > > So, pending a rewrite of hd64461, we should probably just leave the
> > > > __do_IRQ() dispatch as an option there, until someone gets around to
> > > > rewriting that mess. I will conditionalize it on !HD64461 for now.
> > >
> > > Kristoffer can you try the attached patch, please? It compiles OK but I
> > > haven't had chance to test it on actual hardware.
> >
> > Sorry for the late reply, been having issues with my internet
> > connection. Anyhow, not sure if this solves anything since
> > I've already rewritten the IRQ part to be alot more
> > sensible. Basicly only wanting to get FB going
> > before I push it upstreams.
> >
> > What you think Paul?
> >
> Matt's patch should allow us to fix the __do_IRQ() problem, if you want
> to build on top of that, that is fine, but it is still helpful to know
> whether it works for you with CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ enabled.
>
> The only problematic thing I see is the lack of the base IRQ factoring,
> only the chained handlers for the multiplexed sources are defined. This
> is the way it should be, but it is possible that there will have to be
> another handler set up to at least get the hd64461 IRQ firing. This is
> the basis for that silly i == 16 thing in the old demux code. Any user
> that depends on that behaviour deserves to be broken, though.
I've attached the code I got so far. You can atleast see my
approach to the issue.
/*
*
* MFD driver for the Hitachi HD64461 companion chip
*
* HD64461 chip contains 8 interrupts handled by an demuxer
* It controls pcmcia x 2, UART, IRDA, FB.
*
*
* (C) 2008 Kristoffer Ericson <Kristoffer.Ericson@gmail.com>
*
*
*/
#include <linux/sched.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/param.h>
#include <linux/interrupt.h>
#include <linux/init.h>
#include <linux/irq.h>
#include <linux/errno.h>
#include <linux/spinlock.h>
#include <linux/platform_device.h>
#include <linux/hd64461.h>
#include <asm/io.h>
#include <asm/irq.h>
struct hd64461_irq_list *irq_master;
struct hd64461_devdata *hd_master;
void hd64461_io_write16(u16 value, unsigned int reg)
{
iowrite16(value, (hd_master->io_start + reg));
}
void hd64461_io_write8(u8 value, unsigned int reg)
{
iowrite8(value, (hd_master->io_start + reg));
}
u16 hd64461_io_read16(unsigned int reg)
{
return(ioread16(hd_master->io_start + reg));
}
u8 hd64461_io_read8(unsigned int reg)
{
return(ioread8(hd_master->io_start + reg));
}
EXPORT_SYMBOL(hd64461_io_write16);
EXPORT_SYMBOL(hd64461_io_write8);
EXPORT_SYMBOL(hd64461_io_read16);
EXPORT_SYMBOL(hd64461_io_read8);
/*
* hd64461_irq_demask - find out what number our irq_mask equals
*
*
*
* returns number between 1-16
*/
unsigned int hd64461_irq_demask(u16 mask)
{
unsigned int i;
for (i = 1; i < 16; i++)
if ((1 << i) & mask)
break;
return i;
}
/*
* hd64461_irq_set_hand - set handler for hd64461 source
*
*
*
*/
unsigned int hd64461_irq_set_hand(u16 mask, void (*fn)(int, void *))
{
u16 number;
number = hd64461_irq_demask(mask);
if (irq_master->irq[number].fn == NULL)
irq_master->irq[number].fn = fn;
return 0;
}
/*
* hd64461_irq_enable - make the hd64461 source active
*
* !note, handler should be installed before this!
*/
unsigned int hd64461_irq_enable(u16 mask)
{
u16 nimr;
u16 number;
nimr = hd64461_io_read16(HD64461_NIMR);
nimr |= mask;
hd64461_io_write16(nimr, HD64461_NIMR);
number = hd64461_irq_demask(mask);
irq_master->irq[number].irq_enabled = 1;
irq_master->irq[number].irq_mask = mask;
return 0;
}
/*
*
* hd64461_irq_disable - make the hd64461 source inactive
*/
unsigned int hd64461_irq_disable(u16 mask)
{
u16 nimr;
u16 number;
nimr = hd64461_io_read16(HD64461_NIMR);
nimr &= ~mask;
hd64461_io_write16(nimr, HD64461_NIMR);
number = hd64461_irq_demask(mask);
irq_master->irq[number].irq_enabled = 0;
irq_master->irq[number].irq_mask = 0;
/* TODO HANDLER */
return 0;
}
/*
* hd64461_irq_trigger - set irq trigger for hd64461 source
*/
unsigned int hd64461_irq_trigger(u16 mask, u16 trigger_mask)
{
if (!(mask & HD64461_PCC0_MASK) || !(mask & HD64461_PCC1_MASK)) {
printk(KERN_INFO "this interrupt doesn't support trigger settings\n");
return 0;
}
/* TODO */
return 0;
}
void hd64461_irq_request(u16 mask, void (*fn)(int, void *), u16 trigger_mask)
{
hd64461_irq_set_hand(mask, fn);
hd64461_irq_trigger(mask, trigger_mask);
hd64461_irq_enable(mask);
}
static irqreturn_t hd64461_irq_handler(int irq, void *devid)
{
unsigned short bit;
int i;
u16 value;
u16 nimr;
value = 0xffff;
printk(KERN_INFO "Entering interrupt!\n");
/* read -> inactivate */
nimr = hd64461_io_read16(HD64461_NIMR);
hd64461_io_write16(value, HD64461_NIMR);
/* run through the source/s and check
* which one is causing the interrupt.
* only run handler if we are sure
* one exists and is enabled (by us).
*/
for (i = 0, bit = 1; i < 16; bit <<= 1, i++)
if (nimr & irq_master->irq[i].irq_mask) {
if (irq_master->irq[i].irq_enabled)
irq_master->irq[i].fn(i, devid);
else
printk(KERN_INFO "spurious interrupt detected from interrupt mask %x\n", irq_master->irq[i].irq_mask);
}
return IRQ_HANDLED;
}
static struct irqaction irq0 = {
.handler = hd64461_irq_handler,
.flags = IRQF_DISABLED,
.mask = CPU_MASK_NONE,
.name = "hd64461-mfd",
};
static int __init hd64461_probe(struct platform_device *pdev)
{
struct resource *res;
unsigned int ret;
ret = -ENOMEM;
printk(KERN_INFO "hd64461-mfd: driver starting\n");
/* Allocate the memory for devdata */
hd_master = kzalloc(sizeof(struct hd64461_devdata), GFP_KERNEL);
if (!hd_master) {
goto fault_0;
}
irq_master = kzalloc(sizeof(struct hd64461_irq_list), GFP_KERNEL);
if (!irq_master) {
goto fault_1;
}
/* We get our IRQ from the driver resource */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res)
goto fault_1;
hd_master->master_irq = res->start;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
goto fault_1;
hd_master->io_start = 0xb0000000;
// hd_master->io_end = res->end;
// ioremap(res->start, (res->end - res->start) - 1);
// platform_set_drvdata(pdev, hd_master);
setup_irq(36, &irq0);
// ret = request_irq(hd_master->master_irq, hd64461_irq_handler, IRQF_DISABLED, "hd64461-mfd", hd_master);
return 0;
fault_0:
return ret;
fault_1:
kfree(hd_master);
return ret;
}
static int __exit hd64461_remove(struct platform_device *pdev)
{
return 0;
}
static struct platform_driver hd64461_mfd_driver = {
.driver = {
.name = "hd64461-mfd",
.owner = THIS_MODULE,
},
.probe = hd64461_probe,
.remove = __exit_p(hd64461_remove),
};
static int __init hd64461_init(void)
{
return platform_driver_probe(&hd64461_mfd_driver, hd64461_probe);
}
static void __exit hd64461_exit(void)
{
platform_driver_unregister(&hd64461_mfd_driver);
}
module_init(hd64461_init)
module_exit(hd64461_exit)
MODULE_AUTHOR("Kristoffer Ericson <kristoffer.ericson@gmail.com>");
MODULE_DESCRIPTION("Core Driver for HD64461");
MODULE_LICENSE("GPL v2");
--
Kristoffer Ericson <kristoffer.ericson@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (5 preceding siblings ...)
2008-11-25 18:47 ` Kristoffer Ericson
@ 2008-11-25 19:50 ` Paul Mundt
2008-11-25 20:11 ` Matt Fleming
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Paul Mundt @ 2008-11-25 19:50 UTC (permalink / raw)
To: linux-sh
On Tue, Nov 25, 2008 at 08:48:21PM +0100, Kristoffer Ericson wrote:
> On Wed, 26 Nov 2008 02:54:26 +0900
> Paul Mundt <lethal@linux-sh.org> wrote:
> > Matt's patch should allow us to fix the __do_IRQ() problem, if you want
> > to build on top of that, that is fine, but it is still helpful to know
> > whether it works for you with CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ enabled.
> >
> > The only problematic thing I see is the lack of the base IRQ factoring,
> > only the chained handlers for the multiplexed sources are defined. This
> > is the way it should be, but it is possible that there will have to be
> > another handler set up to at least get the hd64461 IRQ firing. This is
> > the basis for that silly i = 16 thing in the old demux code. Any user
> > that depends on that behaviour deserves to be broken, though.
>
> I've attached the code I got so far. You can atleast see my
> approach to the issue.
>
The approach you use has all of the same problems as the old code in
terms of how the demux is handled and how it completely sidesteps the
generic hardirq code. Additionally, this is new code, rather than
refactoring existing code. If Matt's patch doesn't work for you, then we
just leave CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ disabled for hd64461. If it
does work however, then you are much better off adopting that code and
including it in your MFD driver. The main thing is to fix what we have
in-tree first.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (6 preceding siblings ...)
2008-11-25 19:50 ` Paul Mundt
@ 2008-11-25 20:11 ` Matt Fleming
2008-11-25 20:19 ` Kristoffer Ericson
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Matt Fleming @ 2008-11-25 20:11 UTC (permalink / raw)
To: linux-sh
On Tue, Nov 25, 2008 at 08:48:21PM +0100, Kristoffer Ericson wrote:
>
> unsigned int hd64461_irq_demask(u16 mask)
> {
> unsigned int i;
>
> for (i = 1; i < 16; i++)
> if ((1 << i) & mask)
> break;
>
Is there a reason that this starts from i = 1 and not i = 0?
>
> void hd64461_irq_request(u16 mask, void (*fn)(int, void *), u16 trigger_mask)
> {
> hd64461_irq_set_hand(mask, fn);
> hd64461_irq_trigger(mask, trigger_mask);
> hd64461_irq_enable(mask);
> }
I can't find any code in the kernel that registers with the current demux
code. Is this interface still necessary?
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (7 preceding siblings ...)
2008-11-25 20:11 ` Matt Fleming
@ 2008-11-25 20:19 ` Kristoffer Ericson
2008-11-25 20:26 ` Kristoffer Ericson
2008-11-27 19:02 ` Kristoffer Ericson
10 siblings, 0 replies; 12+ messages in thread
From: Kristoffer Ericson @ 2008-11-25 20:19 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 2629 bytes --]
On Wed, 26 Nov 2008 04:50:11 +0900
Paul Mundt <lethal@linux-sh.org> wrote:
> On Tue, Nov 25, 2008 at 08:48:21PM +0100, Kristoffer Ericson wrote:
> > On Wed, 26 Nov 2008 02:54:26 +0900
> > Paul Mundt <lethal@linux-sh.org> wrote:
> > > Matt's patch should allow us to fix the __do_IRQ() problem, if you want
> > > to build on top of that, that is fine, but it is still helpful to know
> > > whether it works for you with CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ enabled.
> > >
> > > The only problematic thing I see is the lack of the base IRQ factoring,
> > > only the chained handlers for the multiplexed sources are defined. This
> > > is the way it should be, but it is possible that there will have to be
> > > another handler set up to at least get the hd64461 IRQ firing. This is
> > > the basis for that silly i == 16 thing in the old demux code. Any user
> > > that depends on that behaviour deserves to be broken, though.
> >
> > I've attached the code I got so far. You can atleast see my
> > approach to the issue.
> >
> The approach you use has all of the same problems as the old code in
> terms of how the demux is handled and how it completely sidesteps the
> generic hardirq code.
I must be missing something. Last time you said that there wasn't
much point in adding a virtual IRQ range, and thats what
I've been avoiding to do. Everything goes into the HD64461_IRQ
which simply sends "notifier"/runs interrupt of the
mask requesting it. Perhaps I misunderstod in what
way you wanted the mfd to notify the driver.
> Additionally, this is new code, rather than
> refactoring existing code.
I can understand that changing existing code is better
than removing->adding new code. But I'm doing this
to get the pcmcia driver inside, which you said wouldn't
happen until the hd64461 was transformed into an MFD driver.
So on one side the hd64461 should be transformed into
an mfd driver and on the other existing approach should
be preserved.
> If Matt's patch doesn't work for you, then we
> just leave CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ disabled for hd64461. If it
> does work however, then you are much better off adopting that code and
> including it in your MFD driver. The main thing is to fix what we have
> in-tree first.
I will test Matt's patch later today and see if it solves it,
It probably will. I mean no disrespect with my comments,
just that its frustrating missing your points all the time.
I don't do this for a living and medical studies doesn't
provide much of a + in these areas.
--
Kristoffer Ericson <kristoffer.ericson@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (8 preceding siblings ...)
2008-11-25 20:19 ` Kristoffer Ericson
@ 2008-11-25 20:26 ` Kristoffer Ericson
2008-11-27 19:02 ` Kristoffer Ericson
10 siblings, 0 replies; 12+ messages in thread
From: Kristoffer Ericson @ 2008-11-25 20:26 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]
On Tue, 25 Nov 2008 20:11:06 +0000
Matt Fleming <mjf@gentoo.org> wrote:
> On Tue, Nov 25, 2008 at 08:48:21PM +0100, Kristoffer Ericson wrote:
> >
> > unsigned int hd64461_irq_demask(u16 mask)
> > {
> > unsigned int i;
> >
> > for (i = 1; i < 16; i++)
> > if ((1 << i) & mask)
> > break;
> >
>
> Is there a reason that this starts from i = 1 and not i = 0?
Only 14,12,13,11,10,9,6,5 are actually reporting anything so
it could simply run from 5->14. But this 1->16 has been
used previously, most likely to just point out that
the register is 16bit. The reason I haven't changed it
is the fact that hd64465 got more sources, so locking it
down isn't a good idea.
>
> >
> > void hd64461_irq_request(u16 mask, void (*fn)(int, void *), u16 trigger_mask)
> > {
> > hd64461_irq_set_hand(mask, fn);
> > hd64461_irq_trigger(mask, trigger_mask);
> > hd64461_irq_enable(mask);
> > }
>
> I can't find any code in the kernel that registers with the current demux
> code. Is this interface still necessary?
>
The idea is to use it in the coming hd64461 relevant code (pcmcia/fb/...) so
currently nothing is using it. The above code hasn't been applied anywhere.
--
Kristoffer Ericson <kristoffer.ericson@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: HP Jornada 600-series bisected
2008-11-19 23:15 HP Jornada 600-series bisected Kristoffer Ericson
` (9 preceding siblings ...)
2008-11-25 20:26 ` Kristoffer Ericson
@ 2008-11-27 19:02 ` Kristoffer Ericson
10 siblings, 0 replies; 12+ messages in thread
From: Kristoffer Ericson @ 2008-11-27 19:02 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 4139 bytes --]
On Sat, 22 Nov 2008 16:49:52 +0000
Matt Fleming <mjf@gentoo.org> wrote:
> On Fri, Nov 21, 2008 at 04:34:45PM +0900, Paul Mundt wrote:
> >
> > So, pending a rewrite of hd64461, we should probably just leave the
> > __do_IRQ() dispatch as an option there, until someone gets around to
> > rewriting that mess. I will conditionalize it on !HD64461 for now.
>
> Kristoffer can you try the attached patch, please? It compiles OK but I
> haven't had chance to test it on actual hardware.
>
>
Seems to have solved the kernel panics errors, however
get some ATA errors now, weird but alot better than before.
Considering the state before this patch, I'm inclined to
ack it.
/Kristoffer
Linux version 2.6.28-rc6-00007-ged31348-dirty (kristoffer@BoTux) (gcc version 3.4.5) #4 Thu No8
Boot params:
... MOUNT_ROOT_RDONLY - 00000000
... RAMDISK_FLAGS - ffffffff
... ORIG_ROOT_DEV - ffffffff
... LOADER_TYPE - 00000001
... INITRD_START - ffffffff
... INITRD_SIZE - ffffffff
Booting machvec: hp6xx
Node 0: start_pfn = 0xd000, low = 0xe000
Zone PFN ranges:
Normal 0x0000d000 -> 0x0000e000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x0000d000 -> 0x0000e000
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
Kernel command line: mem=16M console=ttySC1,115200
PID hash table entries: 64 (order: 6, 256 bytes)
Using tmu for system timer
Using 5.528 MHz high precision timer.
Console: colour dummy device 80x25
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 13896k/16384k available (1286k kernel code, 380k data, 76k init)
Calibrating delay loop (skipped)... 132.66 BogoMIPS PRESET (lpj=265320)
Mount-cache hash table entries: 512
CPU: SH7729
SCSI subsystem initialized
DMA: Registering DMA API.
DMA: Registering sh_dmac handler (4 channels).
HD64461 configured at 0xb0000000 on irq 36(mapped into 64 to 79)
HD64461: enabling PCMCIA devices
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Console: switching to colour frame buffer device 80x30
fb0: Hitachi HD64461 frame buffer device
SuperH SCI(F) driver initialized
sh-sci: ttySC0 at MMIO 0xfffffe80 (irq = 25) is a sci
sh-sci: ttySC1 at MMIO 0xa4000150 (irq = 59) is a scif
console [ttySC1] enabled
sh-sci: ttySC2 at MMIO 0xa4000140 (irq = 55) is a irda
Driver 'sd' needs updating - please use bus_type methods
scsi0 : pata_platform
ata1: PATA max PIO0 mmio cmd 0x150001f0 ctl 0x150001fe irq 77
ata1.00: CFA: SanDisk SDCFH-256, HDX 2.15, max PIO4
ata1.00: 501760 sectors, multi 0: LBA
ata1.00: configured for PIO
scsi 0:0:0:0: Direct-Access ATA SanDisk SDCFH-25 HDX PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 501760 512-byte hardware sectors: (256 MB/245 MiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 501760 512-byte hardware sectors: (256 MB/245 MiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
................
................
................
ata1.00: cmd 20/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for PIO
ata1: EH complete
ata1.00: limiting speed to UDMA7:PIO5
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: cmd 20/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
......................
......................
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
ata1: EH complete
unable to read partition table
sd 0:0:0:0: [sda] Attached SCSI removable disk
--
Kristoffer Ericson <kristoffer.ericson@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread