On Thu, 16 Mar 2006, Vishal Oliyil Kunnil wrote:
> Hi,
> I am trying to get the isp1362-hcd driver running on a custom PXA board . Got
> lots of info from the list archives, had to pull the H_WAKE pin low to get
> the clock trigger ready (Thanks to the list archives :) )
>
> IRQ 27 is assinged
On Mon, 31 Oct 2005, Jeroen Roose wrote:
> Hi,
>
> I'm working on usb host support for the isp1362 on out arm
> platform. On the mailinglist I found a patch from Lothar
> Wassmann dated 2005/04/08.
> Is there ongoing development going on for this chip ? Is the
> L.W. patch a good starting point
On Tue, 7 Jun 2005, Lothar Wassmann wrote:
> Hi,
>
> > > This is true for ISP116x. But the ISP1362 has a smarter handling for
> > > periodic transfers than the ISP116x. PTDs in the INTL buffer will
> > > automatically be rescheduled without CPU intervention (as long as they
> > > are NAKed by t
Hi,
> > This is true for ISP116x. But the ISP1362 has a smarter handling for
> > periodic transfers than the ISP116x. PTDs in the INTL buffer will
> > automatically be rescheduled without CPU intervention (as long as they
> > are NAKed by the device). Thus the SOF interrupt is not necessary for
>
On Tue, 7 Jun 2005, Lothar Wassmann wrote:
> Hi,
>
> > SOF interrupt is needed for periodic transfers, while for
> > control and bulk transfers it is not. So, enumeration itself
> >
> This is true for ISP116x. But the ISP1362 has a smarter handling for
> periodic transfers than the ISP116x. P
Hi,
> SOF interrupt is needed for periodic transfers, while for
> control and bulk transfers it is not. So, enumeration itself
>
This is true for ISP116x. But the ISP1362 has a smarter handling for
periodic transfers than the ISP116x. PTDs in the INTL buffer will
automatically be rescheduled wit
On Tue, 7 Jun 2005, Marco Schramel wrote:
> we use an isp1362 on kernel 2.4.25. All works fine and it communicates with
> all devices (mass storage, serials and our own usb devices).
> But there is one question regarding th isp.
> Is it really necessary to handle an interrupt every ms ? Without
> Hey. I just wanted to pipe in that I had this problem for a short
> while as well. It boggled my mind.. doesn't spin_lock prevent two
> interrupt handlers from entering this function at the same time?
>
> irq_active is only referenced in this function, and it's subtracted
> at the end. I did
On Wed, 4 May 2005, Michael wrote:
> Hi.
> I'm pleased to announce that I've got my driver working! I was
> able yesterday to attach a USB-network device, and get it onto the
> network, and use telnet! The ohci-isp1362 driver didn't get me
> that far.
> That's encouraging, and I think that I'll
> Thanks for this clearing int_edge_triggered has made the
> interrupts
> appear, but unfortunately now I hit a 'BUG_ON' in isp1362_irq,
>
> 1089:spin_lock(&isp1362_hcd->lock);
> 1090:
> 1091:BUG_ON(isp1362_hcd->irq_active++);
> 1092:
> 1093:isp1362_write_reg16(isp1362_hc
Hi,
> 1089:spin_lock(&isp1362_hcd->lock);
> 1090:
> 1091:BUG_ON(isp1362_hcd->irq_active++);
> 1092:
> 1093:isp1362_write_reg16(isp1362_hcd, HCuPINTENB, 0);
>
> It would appear that it is entering the interrupt handler twice for some
> reason.
>
> Should I be setting the I
> You should probably clear the 'int_edge_triggered' flag in the
> platform_data to make the chip assert its interrupt output until the
> interrupt has been acknowledged to the chip, since the 160ns pulse
> that the chip generates in 'edge triggered mode' may be too short to
> be detected by the CP
Hi,
> I'm using the ISP1362 HCd recently posted to this mailing list, and have
> it detecting the chip correctly, and passing the CHIP_BUFFER_TEST, but
> it doesn't appear to be sending any interrupts. At this stage I cannot
> be sure it isn't a hardware problem, but I was wondering if there were
On Thursday 28 April 2005 1:07 pm, Michael wrote:
>
>
> As far as the "missing status stage", this still happens, but it
> runs okay. This warning happens for the get descriptors for the
> lang IDs, the iProduct, iManufacturer, and iSerialNumber data. I'm
> assuming it's a more general USB thin
Hi,
> So, we're handling all of the interrupts fine, but every time we
> handle an ATL interrupt, it says that it's not handled, and we get
> the "nobody cared" message.
>
Oops. I wonder, why I did never get one of those...
> Thanks for your feedback and insight. It sure helped me find this
> p
> > No, I suppose I don't have a special reason. I'm running my
> > kernel without any modules at all, so I was sticking to that.
> > I have it automated to be easy enough to boot with a new
> > kernel. (As easy as transferring a new module over and trying
> > it out).
> >
> I'm running my test
Hi Michael,
> No, I suppose I don't have a special reason. I'm running my kernel
> without any modules at all, so I was sticking to that. I have it
> automated to be easy enough to boot with a new kernel. (As easy as
> transferring a new module over and trying it out).
>
I'm running my test sys
--- Lothar Wassmann <[EMAIL PROTECTED]> wrote:
> Hi Michael,
>
> Michael writes:
> > I would disagree. I added a printk at the top of the
> > isp1362_irq function, as you can see in the bootup messages.
> > However, it doesn't show up with the "nobody cared" messages.
> > Perhaps this is a hin
Hi,
> The bigger problem, is that traffic stops after the first Class IN
> request, where I expect to get IN/OUT transactions. I also get a
> bunch of "irq24: nobody cared" messages throughout the
> above-mentioned behavior.
> What exactly does this mean? When does this happen? IRQ24 should
>
A
Hi,
> Is there any reason to connect ISP1362 with 4 byte offset of registers,
> while all registers are 16-bit, and my data-bus width is 16-bit too?
>
Yes. This enables using 32bit load/store instructions to access the
chip (though the chip interface is still 16 bit). The PXA memory
interface doe
Of course i've started my work with isp3163 searching this list,
but I found no driver for 2.6 supports all features that original
one does.
I found and tested ohci-isp1362 one, but there is no support for
DMA and OTG.
Really? At one point, I thought it only supported DMA (in which
case I wa
Can I gripe a little bit?
OK. You are right.
1. Please search the mailing list archives... there you'll find out
that there are some drivers for the ISP1362 (so-called
'ohci-isp1362'), and a new one that's coming out soon.
Of course i've started my work with isp3163 searching this list,
but
> is there any work done to port isp1362 full drivers for 2.6
> kernels?
>
> are there any hints for porting usb drivers for 2.6 series (i'm
> using
> 2.6.11)
> a lot of defines has gone.., structures have been changed
> there are even hard differences between 2.6.7 an 2.6.11 ...
>
> i've j
Hi,
> Does anyone know if there has been much work recently on the OHCI-based
> ISP1362 driver? I see that at http://www.karo-electronics.de/132.0.html
> the last update was in November of last year, and from the mailing list
> it looks as if the idea of basing them on the OHCI framework has died
On Thu, 17 Feb 2005, Andre Renaud wrote:
> On an alternative tack, is it possible to use the 116x driver from
> http://www.artecdesign.ee/~ok/isp116x/ with an 1362 chip for host-only
> support? I was under the impression that the 1362 contained a super set
> of the 116x functionality.
The 1362
25 matches
Mail list logo
