* Stupid question #1 of many -- unit test harness?
@ 2013-04-15 0:44 TJ Olaes
2013-04-15 14:38 ` Clemens Ladisch
0 siblings, 1 reply; 2+ messages in thread
From: TJ Olaes @ 2013-04-15 0:44 UTC (permalink / raw)
To: alsa-devel
Hi.
So, I'm attempting to write the driver for the eClaro card for a couple of
reasons, one of which is that I currently don't have sound on mine.
So... is there some kind of test harness framework for new drivers? I have
no prior idea how to move forward to build this thing, so I'm snooping around
in the oxygen source files and trying to copy things that look like they make
sense. For instance, I noted that there's mention of an "AK4396" related to
output. I assume this is some kind of chip, and I saw in the Claro code that
something called "ak4396_init(...)" is called, so I just copied that line and
pasted it into the eclaro_init(...) function I'm writing.
I have no idea how I'm going to test this short of just compiling the kernel
and booting into it. I feel like that's the brute-force, non-smart way to do
it, and that you guys who've been doing this for a while might have ideas and
recommendations on how to better test my code so I'm not rebooting my machine
each time I change a line and recompile.
I'd appreciate your guidance, community. Thanks.
-TJ
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Stupid question #1 of many -- unit test harness?
2013-04-15 0:44 Stupid question #1 of many -- unit test harness? TJ Olaes
@ 2013-04-15 14:38 ` Clemens Ladisch
0 siblings, 0 replies; 2+ messages in thread
From: Clemens Ladisch @ 2013-04-15 14:38 UTC (permalink / raw)
To: TJ Olaes; +Cc: alsa-devel
TJ Olaes wrote:
> So, I'm attempting to write the driver for the eClaro card for a couple of
> reasons, one of which is that I currently don't have sound on mine.
>
> So... is there some kind of test harness framework for new drivers?
No. You test drivers by trying to use them.
> I have no prior idea how to move forward to build this thing, so I'm snooping
> around in the oxygen source files and trying to copy things that look like
> they make sense.
All the basic boilerplate code already is in oxygen_lib.c. What's left
for you are the _interesting_ parts where you have to know what you're
doing.
> For instance, I noted that there's mention of an "AK4396" related to
> output. I assume this is some kind of chip
Yes, this is some kind of chip. As the DAC for the front outputs (as
mentioned on HT Omega's website), a quite important one.
> and I saw in the Claro code that something called "ak4396_init(...)"
> is called, so I just copied that line and pasted it into the
> eclaro_init(...) function I'm writing.
The other Claro cards have four AK4396 chips. The eClaro has only one
and handles the other six channels with a CS4362 chip. This is more
similar to the Xonar DX (so you might want to get inspiration from
xonar_cs43xx.c), but the eClaro obviously uses SPI instead of I²C
because that's the only protocol that the AK4396 supports.
> I have no idea how I'm going to test this short of just compiling the kernel
> and booting into it.
You should compile the sound driver as a module, then you'll have to
reboot only when it crashes. ;-)
It might be more productive for me to write the driver, if you are able
to compile your own kernel and to test it.
Regards,
Clemens
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-04-15 14:38 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-15 0:44 Stupid question #1 of many -- unit test harness? TJ Olaes
2013-04-15 14:38 ` Clemens Ladisch
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.