ISP1761 USB driver

--- Quote Start ---

originally posted by hippo@Aug 15 2006, 11:30 AM

there's a good news. philips semi had opened their isp1761 driver on sf.net as gpl.

it does support iso transfer. ( the current isp1362 driver does not support iso transfer)

it is for 2.6.9 kernel.

see,

http://sourceforge.net/projects/isp176x-hcd (http://sourceforge.net/projects/isp176x-hcd)

http://sourceforge.net/projects/isp1761device/ (http://sourceforge.net/projects/isp1761device/)

(sorry for absent from the forum. i have been very busy.)

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=17608)

--- quote end ---

--- Quote End ---

Hi,hippo

you said "...the current ISP1362 driver does not support ISO transfer....".Dose it mean that if i want to use usb camera in DE2 board, I should improve on the ISP1362 driver for ISO transfers? Or can I have another way to use usb camera in DE2 board?

Pls give me some advice.

Thx.

leewood

--- Quote Start ---

originally posted by leewood+aug 15 2006, 04:10 pm--><div class='quotetop'>quote (leewood @ aug 15 2006, 04:10 pm)</div>

--- quote start ---

<!--quotebegin-hippo@Aug 15 2006, 11:30 AM

there&#39;s a good news. philips semi had opened their isp1761 driver on sf.net as gpl.

it does support iso transfer. ( the current isp1362 driver does not support iso transfer)

it is for 2.6.9 kernel.

see,

http://sourceforge.net/projects/isp176x-hcd (http://sourceforge.net/projects/isp176x-hcd)

http://sourceforge.net/projects/isp1761device/ (http://sourceforge.net/projects/isp1761device/)

(sorry for absent from the forum. i have been very busy.)

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=17608)

--- quote end ---

--- Quote End ---

Hi,hippo

you said "...the current ISP1362 driver does not support ISO transfer....".Dose it mean that if i want to use usb camera in DE2 board, I should improve on the ISP1362 driver for ISO transfers? Or can I have another way to use usb camera in DE2 board?

Pls give me some advice.

Thx.

leewood

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=17613)</div>

[/b]

--- Quote End ---

yes. if your camera need iso transfer, then you need to add iso transfer support to isp1362 driver.

Hi,hippo

Do you know the possible reasons of the following phenomenon:

(a uclinux system had trasplanted into the board DE2 successful,and the usb camera can work)

I was programming for grabbling picture via video4liux API which was used for USB camer.

I can obtain the camera and the picture information using ioctl() function:

fd=open("dev/v4l/video0",O_RDWR);

...........

int cap=ioctl(fd,VIDIOCGCAP,& capability);

..........

int pic=ioctl(fd,VIDIOCGPICT,& picture);

return value:

fd=3;

cap=0;

pic=0;

Above code could work ,and the correct information was obtained.

but when used the following code ,a problem was generated

struct video_mbuf mbuf;

...........

struct video_mmap grab_buf;

grab_buf.frame=0;

grab_buf.height=240;

grab_buf.width=320;

grab_buf.format=VIDEO_PALETTE_RGB24;

char *data;

data=mmap(0,mbuf.size,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);

..................

int grab=ioctl(fd,VIDIOCMCAPTURE,&grab_buf);

.................

int sync=ioctl(fd,VIDIOCSYNC,& grab_buf.frame);

.............

the return value:

data=-1

grab=-1;

sync=-1

That&#39;s to say ,the process of grabbing a frame_picture work failed!

do you know the possible reasons!

the isp1362 driver did not suppot the isochronous ,I have modified the parameter of the isp1362 driver,Now, there wasn&#39;t the note:Isochronous transfer not supportec.

Look forward to you reply! Thank you !

--- Quote Start ---

originally posted by dms2002711@Aug 17 2006, 10:47 PM

hi,hippo

do you know the possible reasons of the following phenomenon:

(a uclinux system had trasplanted into the board de2 successful,and the usb camera can work)

i was programming for grabbling picture via video4liux api which was used for usb camer.

i can obtain the camera and the picture information using ioctl() function:

fd=open("dev/v4l/video0",o_rdwr);

...........

int cap=ioctl(fd,vidiocgcap,& capability);

..........

int pic=ioctl(fd,vidiocgpict,& picture);

return value:

fd=3;

cap=0;

pic=0;

above code could work ,and the correct information was obtained.

but when used the following code ,a problem was generated

struct video_mbuf mbuf;

...........

struct video_mmap grab_buf;

grab_buf.frame=0;

grab_buf.height=240;

grab_buf.width=320;

grab_buf.format=video_palette_rgb24;

char *data;

data=mmap(0,mbuf.size,prot_read|prot_write,map_shared,fd,0);

..................

int grab=ioctl(fd,vidiocmcapture,&grab_buf);

.................

int sync=ioctl(fd,vidiocsync,& grab_buf.frame);

.............

the return value:

data=-1

grab=-1;

sync=-1

that&#39;s to say ,the process of grabbing a frame_picture work failed!

do you know the possible reasons!

the isp1362 driver did not suppot the isochronous ,i have modified the parameter of the isp1362 driver,now, there wasn&#39;t the note:isochronous transfer not supportec.

look forward to you reply! thank you !

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=17693)

--- quote end ---

--- Quote End ---

What is errno for each of your errors? Knowing this will, at least, tell you what&#39;s failing in each of your commands, which is a pretty good place to start.

Cheers,

- slacker

--- Quote Start ---

originally posted by hippo@Aug 15 2006, 11:30 AM

there&#39;s a good news. philips semi had opened their isp1761 driver on sf.net as gpl.

it does support iso transfer. ( the current isp1362 driver does not support iso transfer)

it is for 2.6.9 kernel.

see,

http://sourceforge.net/projects/isp176x-hcd (http://sourceforge.net/projects/isp176x-hcd)

http://sourceforge.net/projects/isp1761device/ (http://sourceforge.net/projects/isp1761device/)

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=17608)

--- quote end ---

--- Quote End ---

I ported the driver to a PXA255 running 2.6.17. It&#39;s at http://dagobah.ucc.asn.au/isp1761/ (http://dagobah.ucc.asn.au/isp1761/). I don&#39;t intend to support or maintain it though. See http://sourceforge.net/mailarchive/forum.p...&forum_id=38940 (http://sourceforge.net/mailarchive/forum.php?thread_id=30473479&forum_id=38940) for more info.

Hi, I&#39;m not developing on uClinux but I am attempting to use ISP1761 (with Philips&#39;s 2.6.9 drivers) and get this working on 2.6.14.

I have the host controller & root hub initialised as far as I can tell. I am seeing PTD HALT when I let the USB subsystem initialise the internal hub.

There are no error-bits enabled, just the HALT bit. Has anyone else seen this? Is it a product of moving from 2.6.9 to newer 2.6 kernel with altered USB Core?

I have tried old vs new device discovery and this made no difference.

In addition, I was wondering if anyone had an opinion on whether there should be ndelays between reads & writes to registers & payload memory? The ISP116x seemed to require 150-300ns. I&#39;ve found I need waits when setting the start-addr register on successive reads from payload.

I&#39;m working on a PPC MPC8548 with the ISP1761 attached over the Local Bus.

Any advice very much welcome as I&#39;m banging my head against a wall right now trying to figure out why the ISP1761 (or internal hub) is refusing either (old) SET_ADDRESS or (new) GET_DESCRIPTOR request. It is refusing the first QTD (8bytes) of a 3 QTD part URB.

I can send more info if anyone is interested.

Thanks in advance!

Mike.

--- Quote Start ---

originally posted by hippo@Feb 7 2007, 10:08 AM

please check if it is endian issue.

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=21328)

--- quote end ---

--- Quote End ---

I assume you mean the payload... the QTD header & payload are (in BE format here):

(These are reversed in the ISP1761 memory)

Dir: 0 Recp: 0 ReqType: USB_TYPE_STANDARD USB_RECIP_DEVICE USB_REQ_SET_ADDRESS

- req:0x00000005 le:wValue:0x00000200 le:wIndex:0x00000000 le:wLength:0x00000000

PEHCI_CHECK: qtd at mapLoc: 1 is being scheduled c2473a80, device 2,map 1

pehci_hcd_dump_qha : (pehci_hcd_schedule_pending_ptds) ---------------------

td_info1 (DW0):0x21000041

V: 1 NrBytesToTrans : 00000008 MaxPacketLength: 00000064 Multi: 1

td_info2 (DW1):0x00000000

Split: 0000 TransType :0000 Token :0000 DevAddr:0000 EP:0000

td_info3 (DW2):0x1e018000

RL : 15

Data Start Addr: 0x00000180 (0x00001000)

td_info4 (DW3):0x82780000

Active :0001 Halt :0000 Babble :0000 XactErr:0000

DToggle:0001 Cerr :0000 NakCnt :0015 NrB Tx :0000

----------------------------------

ISP1761 Register Dump...

- HC_CHIP_ID_REG (0x0304) : 0x00011761 (=0x00011761)

- HC_HW_MODE_REG (0x0300) : 0x00000107

- HC_USBCMD_REG (0x0020) : 0x00000001

- HC_USBSTS_REG (0x0024) : 0x00000004

- HC_CONFIGFLAG_REG (0x0060) : 0x00000001

- HC_PORTSC1_REG (0x0064) : 0x00001005

- HC_SPARAMS_REG (0x0004) : 0x00000011

- HC_CPARAMS_REG (0x0008) : 0x00000086

- HC_INTERRUPT_REG_EHCI (0x0028) : 0x00000000

- HC_FRINDEX_REG (0x002c) : 0x00001f75

- HC_INTERRUPT_REG (0x0310) : 0x00000053

- HC_INTENABLE_REG (0x0314) : 0x00000002

- HC_DMACONFIG_REG (0x0330) : 0x00000000

- HC_TRANS_COUNT_REG (0x0334) : 0x00000000

- HC_BUFFER_STAT_REG (0x0338) : 0x00000000

- HC_MEM_READ_REG (0x033c) : 0x00000000

- OTG_CTRL_REG (0x0374) : 0x04800480

----------------------------------

dev(0xc0355c80) - Writing QHA Header(0xc0c416c0) to ISP1761 0xc00...

Dumping ISP1761 Shared Memory Region from 0x00000bf0 for 64 bytes (BE format)...

0x00000bf0: 0x00000000 0x00000000 0x00000000 0x00000000

->0x00000c00: 0x21000041 0x00000000 0x1e018000 0x82780000

0x00000c10: 0x00000000 0x00000000 0x00000000 0x00000000

0x00000c20: 0x00000000 0x00000000 0x00000000 0x00000000

----------------------------------

Dumping ISP1761 Shared Memory Region from 0x00000ff0 for 64 bytes (BE format)...

0x00000ff0: 0x00000000 0x00000000 0x00000000 0x00000000

->0x00001000: 0x00050200 0x00000000 0x00000000 0x00000000

0x00001010: 0x00000000 0x00000000 0x00000000 0x00000000

0x00001020: 0x00000000 0x00000000 0x00000000 0x00000000

----------------------------------

The driver uses readl and writew via these four utility functions:

isp1761_reg_read32

isp1761_reg_write32

isp1761_mem_read32

isp1761_mem_write32

In these, there is EIEIO & ndelay(100), along with the 0x334 write for mem-reads.

I believe the readl and writew are converting from BE to LE. For data pointer manipulation cpu_to_le32 is used as in original example code.

The code is very similar to that of the Philips example code. I&#39;ve added EIEIO & delays.

Does this look like a valid USB setup-message (USB_REQ_SET_ADDRESS) in BE format?

0x00001000: 0x00050200 0x00000000

This is using the old-style device detection in hub.c.

Mike.

--- Quote Start ---

originally posted by hippo@Feb 7 2007, 10:08 AM

please check if it is endian issue.

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=21328)

--- quote end ---

--- Quote End ---

Well, no one else came to my rescue with anything more profound than "an endian issue".

After some days of bug-hunting there were several issues related to "endianess" although a couple of them not at all obvious (to me!;o) but related to target CPU being in BE and USB2.0 & ISP1761 working in LE.

The biggest headache was composition of PIDs which are in QTD "token" to PTD &#39;token&#39;. This ends up in DW2 of the QHA. In the posts above this second dword is zero using the Philips example code and shouldn&#39;t be, it was not converted to target CPU BE representation.

There were a couple of other similar issues with QTD representation. Once these were changed in the example driver it all sprung to life on PPC platform.

Hope this is of some help to others on non-LE CPUs.

Mike.