Date: Sun, 15 Oct 2006 20:59:11 -0500 From: "Rick C. Petty" <rick-freebsd@kiwi-computer.com> To: "R. B. Riddick" <arne_woerner@yahoo.com> Cc: freebsd-multimedia@freebsd.org, B Briggs <rcbdyndns@bellsouth.net> Subject: Re: New port: pvrxxx for Hauppauge PVR150/500 Message-ID: <20061016015911.GC57865@keira.kiwi-computer.com> In-Reply-To: <20061015064102.8780.qmail@web30310.mail.mud.yahoo.com> References: <45317970.5000508@bellsouth.net> <20061015064102.8780.qmail@web30310.mail.mud.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 14, 2006 at 11:41:02PM -0700, R. B. Riddick wrote: > > > Did the whole system block during that time? > Or did it just take 27 secs until kldload completed? Yes, the whole kernel blocks while the download is happening. It's scary the first few times you see it happen, then you just shrug it off and learn patience. > I wouldnt be so sure, that it has eeprom... I would guess it uses DRAM, because > it is cheaper and easier to handle... You might be right that there's no EEPROM/Flash. But the DSP chip(s) is/are programmed through the I2C bus, at least that's what usleep hinted. > Maybe it is possible to continue with other things, when locking is done less > strict? Or does firmware upload require some important bus (like PCI) during > the whole time? I think it's timing-critical, although an I2C bus has clock and data lines, so I can't see any reason the kernel needs to block during the download. Feel free (anyone) to look into the iic code and pull it out from under GIANT. -- Rick C. Petty
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061016015911.GC57865>