Menu
▾
▴
linuxsh-dev
|
From: Fabio G. <fg...@ti...> - 2002-04-08 15:33:53
|
Hi everybody, and in particular hi Stuart. I have a question: what are the steps to enable a keybord. I was able to enable a framebuffer, but I have trouble to understand what is the way to enable a keybord. Thanks for the support. Regards. |
|
From: NIIBE Y. <gn...@m1...> - 2002-04-09 00:30:15
|
Fabio Giovagnini wrote: > Hi everybody, and in particular hi Stuart. > I have a question: > what are the steps to enable a keybord. > I was able to enable a framebuffer, but I have trouble to understand what is > the way to enable a keybord. Perhaps, most easy way is using something like Super I/O chip like SolutionEngine (if you need PC keyboard driver). You can check arch/sh/kernel/setup_se.c. Another way is using key-matrix, like HP Jornada 620. You can check driver/char/scan_keyb.c. -- |
|
From: Fabio G. <fg...@ti...> - 2002-04-09 13:17:36
|
Hi, where could I set the Sense Select of My IRQs? Again, where and how I can an IRQ form a companion chip multiplaxing the interrupt sources? Thanks |
|
From: Stuart M. <stu...@st...> - 2002-04-09 19:16:56
|
Hi there On Tue, 9 Apr 2002 15:14:32 +0200 fg...@ti... wrote: > Hi, > > where could I set the Sense Select of My IRQs? From what I can see in a brief scan of the 7709a manual, the IRQ0-3 pins can be used either in encoded (IRL mode), or as individual pins (IRQ mode). It looks like IRQ4-5 are always in IRQ mode. In encoded mode, you have no choise over the trigger mode. In IRQ mode you can choose rising edge, falling edge or active low. No option for active high. Look at Interrupt Control Register 1 (ICR1) for how to set all this up. The PINT interrupts look to be programmable for active high or low though, using Interrupt Control Register 2 (ICR2). Unfortuntaly the interrupt systems on the various SuperH chips are not orthogonal. Each device has its own set of additions to the basic feature set, so its quite likely that a particular feature may only be present on a subset of the interrupts on a particular device. So for example, just because the PINT interrupts can be programmed for active high/low, don't expect the IRQ interrupts to be similarly programmable. > Again, where and how I can an IRQ form a companion chip multiplaxing the > interrupt sources? We've always done it using an FPGA or GAL. But I would guess a standard priority encoder, something like a 74HCT147, would do the job. Stuart -- Stuart Menefy stu...@st... STMicroelectronics Ltd ST Intranet: mo.bri.st.com Bristol, UK Rest of the World: www.linuxsh.st.com |
|
From: Fabio G. <fg...@ti...> - 2002-04-11 06:35:35
|
Thanks, yesterday I was thinking about end I reached the same result about to
implement the demux mechanism.
Thanks again
On Wednesday 10 April 2002 20:19, Stuart Menefy wrote:
> Several of your options dropped off the end of the email I got here, but
> if I understand you correctly, you have exactly the same problem as people
> using companion chips such as the HD64465.
>
> Have a look for the macro irq_demux. This is defined differently for
> different systems, but in all cases it is used to demux a single interrupt
> comming into the CPU into a number of 'soft' interrupts, based on an
> external status register. These soft interrupts appear as interrupt
> numbers immediatly above the normal interrupts, so you'll also need to
> change the defintion of OFFCHIP_NR_IRQS, and register your device
> drivers to respond to these soft interrupt numbers.
>
> Stuart
>
>
>
> On Wed, 10 Apr 2002 10:25:33 +0200
>
> fg...@ti... wrote:
> > Hi, Sirs
> >
> > This is my hamletic question.
> >
> > My board has a companion chip (CC) with its own interrupt enabel
> > registers and its own interrutp status register. When someting wired to
> > my CC generates an interupt request the CC generate an interrupt on IQR0
> > on my sh7709a. So I have to handle the IQR0 request choosing the rigth
> > handler according to the exact source (keyboad, mouse, timer etc).
> > In linux Sh if I understand good there are two ways to solve this
> > problem: 1) using the IRQ0 handler writing an
> > static struct irqaction irq0 = { CC_interrupt, SA_INTERRUPT, 0, "CC",
> > NULL, NULL};
|
|
From: NIIBE Y. <gn...@m1...> - 2002-04-11 08:00:57
|
Fabio Giovagnini wrote: > Thanks, yesterday I was thinking about end I reached the same result about to > implement the demux mechanism. Yes. With demux mechanism, it is possible to re-use drivers written for another system, you see. -- |
|
From: Fabio G. <fg...@ti...> - 2002-04-11 08:57:19
|
Hi, Sirs
This is my hamletic question.
My board has a companion chip (CC) with its own interrupt enabel registers
and its own interrutp status register. When someting wired to my CC generates
an interupt request the CC generate an interrupt on IQR0 on my sh7709a. So I
have to handle the IQR0 request choosing the rigth handler according to the
exact source (keyboad, mouse, timer etc).
In linux Sh if I understand good there are two ways to solve this problem:
1) using the IRQ0 handler writing an
static struct irqaction irq0 = { CC_interrupt, SA_INTERRUPT, 0, "CC", NULL,
NULL};
.
.
.
setup_irq(CONFIG_ISP0110_IRQ, &irq0);
.
.
.
where CC_interrupt in the iterrupt handler of IRQ0 and inside this fuction I
examine the correct source and I do the rigth thing for the exact interrupt
source.
2) implementing a dedicated interrupt handler with a demux function. So i
have to write:
- static struct hw_interrupt_type CC_irq_type = {
"CC-IRQ",
startup_CC_irq,
shutdown_CC_irq,
enable_CC_irq,
disable_CC_irq,
mask_CC_isp0110,
end_CC_irq
};
- all these functions
- for (i = CC_IRQ_BASE; i < CC_IRQ_BASE + 16; i++) {
irq_desc[i].handler = &CC_irq_type;
}
- static struct irqaction irq_src_1 = { irq_src_1_interrupt, SA_INTERRUPT,
0, "SOURCE 1", NULL, NULL};
- static struct irqaction irq_src_2 = { irq_src_2_interrupt, SA_INTERRUPT,
0, "SOURCE 2", NULL, NULL};
and so on for all my external sources
- all the functions irq_src_1_interrupt,irq_src_2_interrupt,...
Correct?
But here my doubts:
1) which way is the best according to performance;
2) which way is the best according to elegance of solution on the linux
kernel;
3) what are the unwished effect of solution n.1 and solution .2
Thanks a lot for your support.
|
|
From: Stuart M. <stu...@st...> - 2002-04-10 18:19:36
|
Several of your options dropped off the end of the email I got here, but
if I understand you correctly, you have exactly the same problem as people
using companion chips such as the HD64465.
Have a look for the macro irq_demux. This is defined differently for
different systems, but in all cases it is used to demux a single interrupt
comming into the CPU into a number of 'soft' interrupts, based on an
external status register. These soft interrupts appear as interrupt
numbers immediatly above the normal interrupts, so you'll also need to
change the defintion of OFFCHIP_NR_IRQS, and register your device
drivers to respond to these soft interrupt numbers.
Stuart
On Wed, 10 Apr 2002 10:25:33 +0200
fg...@ti... wrote:
> Hi, Sirs
>
> This is my hamletic question.
>
> My board has a companion chip (CC) with its own interrupt enabel registers
> and its own interrutp status register. When someting wired to my CC generates
> an interupt request the CC generate an interrupt on IQR0 on my sh7709a. So I
> have to handle the IQR0 request choosing the rigth handler according to the
> exact source (keyboad, mouse, timer etc).
> In linux Sh if I understand good there are two ways to solve this problem:
> 1) using the IRQ0 handler writing an
> static struct irqaction irq0 = { CC_interrupt, SA_INTERRUPT, 0, "CC", NULL,
> NULL};
--
Stuart Menefy stu...@st...
STMicroelectronics Ltd ST Intranet: mo.bri.st.com
Bristol, UK Rest of the World: www.linuxsh.st.com
|
|
From: Fabio G. <fg...@ti...> - 2002-04-11 17:40:21
|
Hi, having solved the IRQ hw_interrupt handler problem, I'd like to boot my board for the Compact Flash slot. I'm able (or bettr I soppose to be able bat I have to verify) to set my companion chip (CC) in the rigth way to access the PCMCIA bus. But even if I can access the bus I don't know hao to configure the compact flash so that it becames able to be a bootable devices. Do you suggest to me any domumentation and / or examples to stdy compact flash so that I can improve sh-ipl+g with ide support for my board? Thanks a lot. Fabio |
|
From: Fabio G. <fg...@ti...> - 2002-04-12 16:13:08
|
If you know explane to me. Thanks. |
|
From: Stuart M. <stu...@st...> - 2002-04-12 20:22:49
|
PCMCIA actually supports three different address spaces:
- attribute - read by the CPU to determine what card is plugged in,
and possibly to configure the card as a whole.
- I/O - used for control registers of device(s) on the card,
eg for a serial port pr network device
- memory - normally used for real memory: RAM, Flash etc, but can
also be used for device control registers.
They share the same address and data lines, but different control lines go
active to indicate which space is being read or written.
All cards must support config space, whether they support memory or
I/O depends on the card designer.
When a card is plugged in, it is always assumed to be a memory only card.
This allows the Card Information Structure (CIS) to be read from the card,
which tells the driver what types of card this is. If it is an I/O card,
or multifunction card (I/O and memory), then the PCMCIA interface hardware
must be told this, and certain pins on the PCMCIA interface change their
function to support I/O addressing.
I suspect this is what you mean by memory mode and I/O mode.
Stuart
On Fri, 12 Apr 2002 18:12:25 +0200
fg...@ti... wrote:
> If you know explane to me.
>
> Thanks.
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
--
Stuart Menefy stu...@st...
STMicroelectronics Ltd ST Intranet: mo.bri.st.com
Bristol, UK Rest of the World: www.linuxsh.st.com
|
|
From: NIIBE Y. <gn...@m1...> - 2002-04-13 04:41:58
|
You mean, in the case of connecting it to SuperH. For i386, the difference is big, because memory access and I/O access is diffeent thing totally (in hardware and software). For SuperH, where I/O is mapped to memory address space, there's not so much. However, there's one big issue, interrupt. It get interrupted only when accessing I/O mode, this is my experience. Hope this helps. -- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X