Audio support on Mini6410 board [was Re: Hi again]

Audio support on Mini6410 board [was Re: Hi again]

[Sylwester Nawrocki]

Hi Alexander,

Cc: linux-samsung-soc@vger.kernel.org

On 12/21/2012 07:39 PM, Alexander Nestorov wrote:
> Hi once again :)
>
> After some more work there is some (really small) progress.
> I'm able to make the kernel throw errors about something related with
> AC97 and/or ALSA
>
> This is the kernel log: http://pastie.org/5562475
> Those are the patches I have applied (probably something is wrong, I
> just don't know what/where): http://pastie.org/5562478
> And this is the kernel's configuracion: http://pastie.org/5562483
>   (should I disable/enable something?)

It might be correct, but I suspect you need add an entry for Mini6410
board, similar to this one

"SoC AC97 Audio support for SMDK with WM9713"

> What do you think? Any notes/comments?

I have virtually no experience with ASoC and no board to check it,
so my ability to help you with this is really limited. Anyway, let's
try to make it work.

In the kernel log there are 2 things I noticed and would need to be
checked:

Lines 164...166:

soc-audio soc-audio: ASoC machine SMDK WM9713 should use 
snd_soc_register_card()
soc-audio soc-audio: CPU DAI samsung-ac97 not registered
platform soc-audio: Driver soc-audio requests probe deferral

and line 182:

soc-audio: probe of soc-audio failed with error -22

Likely only this last error is important.

I would add some debug prints to snd_soc_register_card() and
snd_soc_instantiate_card() to find out where it fails exactly.

Anyway, it seems you have added wrong audio devices to your board file,
copied from mach-mini2440.c ? Instead, you should find what's in board
files for boards based on s3c6410 SoC, e.g. mach-s3c6410/mach-crag6410.c.

I think you need one of these devices in mini6410_devices[] array:

	&s3c64xx_device_iis0,
	&s3c64xx_device_iis1,

Also, can you check what devices are registered in the system, e.g.

# find /sys/devices

?
You might want to have a look at sound/soc/samsung/smdk_wm9713.c.
Likely you need to add something similar for Mini6410.

And just do remove all mini2440 devices from your board file, like:
uda1340_codec, mini2440_audio. Those certainly shouldn't be there.

I'm not sure yet where AC97_* SoC pins are configured (corresponding
to B29...B33 pins of Tiny6410 module).

--

Regards,
Sylwester

Re: Audio support on Mini6410 board [was Re: Hi again]

[Andrey Gusakov]

Hi.

I also had some problems with WM9714 on mini6410. The problem was
write to register 0x00 of coded. That is SW reset command. I had no
time to deal with it, so I just filter out all writes to register 0x00
in samsung AC97 driver. May be it can help you.
http://comments.gmane.org/gmane.linux.alsa.devel/101674
Also you have to add platform_devices samsung_asoc_dma and s3c64xx_device_ac97
And call s3c64xx_ac97_setup_gpio(S3C64XX_AC97_GPD) from <your_board>_map_io
You Can use sound/soc/samsung/smdk_wm9713.c or create your own. As i
see from boot log you use SMDK file.

On Fri, Jan 11, 2013 at 3:16 AM, Sylwester Nawrocki
<sylvester.nawrocki@gmail.com> wrote:
> Hi Alexander,
>
> Cc: linux-samsung-soc@vger.kernel.org
>
> On 12/21/2012 07:39 PM, Alexander Nestorov wrote:
>>
>> Hi once again :)
>>
>> After some more work there is some (really small) progress.
>> I'm able to make the kernel throw errors about something related with
>> AC97 and/or ALSA
>>
>> This is the kernel log: http://pastie.org/5562475
>> Those are the patches I have applied (probably something is wrong, I
>> just don't know what/where): http://pastie.org/5562478
>> And this is the kernel's configuracion: http://pastie.org/5562483
>>   (should I disable/enable something?)
>
>
> It might be correct, but I suspect you need add an entry for Mini6410
> board, similar to this one
>
> "SoC AC97 Audio support for SMDK with WM9713"
>
>> What do you think? Any notes/comments?
>
>
> I have virtually no experience with ASoC and no board to check it,
> so my ability to help you with this is really limited. Anyway, let's
> try to make it work.
>
> In the kernel log there are 2 things I noticed and would need to be
> checked:
>
> Lines 164...166:
>
> soc-audio soc-audio: ASoC machine SMDK WM9713 should use
> snd_soc_register_card()
> soc-audio soc-audio: CPU DAI samsung-ac97 not registered
> platform soc-audio: Driver soc-audio requests probe deferral
>
> and line 182:
>
> soc-audio: probe of soc-audio failed with error -22
>
> Likely only this last error is important.
>
> I would add some debug prints to snd_soc_register_card() and
> snd_soc_instantiate_card() to find out where it fails exactly.
>
> Anyway, it seems you have added wrong audio devices to your board file,
> copied from mach-mini2440.c ? Instead, you should find what's in board
> files for boards based on s3c6410 SoC, e.g. mach-s3c6410/mach-crag6410.c.
>
> I think you need one of these devices in mini6410_devices[] array:
>
>         &s3c64xx_device_iis0,
>         &s3c64xx_device_iis1,
>
> Also, can you check what devices are registered in the system, e.g.
>
> # find /sys/devices
>
> ?
> You might want to have a look at sound/soc/samsung/smdk_wm9713.c.
> Likely you need to add something similar for Mini6410.
>
> And just do remove all mini2440 devices from your board file, like:
> uda1340_codec, mini2440_audio. Those certainly shouldn't be there.
>
> I'm not sure yet where AC97_* SoC pins are configured (corresponding
> to B29...B33 pins of Tiny6410 module).
>
> --
>
> Regards,
> Sylwester
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Audio support on Mini6410 board [was Re: Hi again]

[Alexander Nestorov]

Hi,

thank you both for REing :)

I made some changes following your instructions and also looking at
the diff between a clean 2.6.38 kernel and FriendlyARM's 2.6.38
kernel.
This is my diff so far: http://pastie.org/5669444
Also, I created a new file for the mini6410 (it's pretty much a copy
of the smdk_wm9713.c in sound/soc/samsung/): http://pastie.org/5669453

So, booting this kernel (3.7 from Sylwester's media/testing branch,
which is just 3.7 with a patch for the OV9650)
gives me this output:

samsung-ac97 samsung-ac97: cfg_gpio callback not provided!
samsung-ac97: probe of samsung-ac97 failed with error -22
soc-audio soc-audio: ASoC machine MINI6410 should use snd_soc_register_card()
soc-audio soc-audio: CPU DAI samsung-ac97 not registered
platform soc-audio: Driver soc-audio requests probe deferral
soc-audio: probe of soc-audio failed with error -22
ALSA device list:
  No soundcards found.

If I uncomment the line 56 in my diff (
//s3c64xx_ac97_setup_gpio(S3C64XX_AC97_GPD); ) I get
errors about the function not being defined. I do know that it's in
arch/arm/mach-s3c64xx/dev-audio.c
and include/linux/platform_data/asoc-s3c.h but I can't see any other
board-specific code using it.

Also S3C64XX_AC97_GPD not being defined, (but present in both files).
What include am I missing? I mean, of course I could include
asoc-s3c.h, but that's not how other boards are
doing it and they do have audio support. How is that done?

@Andrey One more thing, what do you mean by filter all writes to reg 0x0?
Literally something like:

void s3c_ac97_write(*ac97, reg, val){
  if(reg == 0x0)
    return;

  ...code here..
  ...
}

If so, yeah, it looks kind of ugly, but I'll try :)   (as soon as I
can get the "include" problem fixed)

Regards!

--
alexandernst

Re: Audio support on Mini6410 board

[Sylwester Nawrocki]

Hi,

On 01/11/2013 07:17 PM, Alexander Nestorov wrote:
> samsung-ac97 samsung-ac97: cfg_gpio callback not provided!
> samsung-ac97: probe of samsung-ac97 failed with error -22
> soc-audio soc-audio: ASoC machine MINI6410 should use snd_soc_register_card()
> soc-audio soc-audio: CPU DAI samsung-ac97 not registered
> platform soc-audio: Driver soc-audio requests probe deferral
> soc-audio: probe of soc-audio failed with error -22
> ALSA device list:
>    No soundcards found.
>
> If I uncomment the line 56 in my diff (
> //s3c64xx_ac97_setup_gpio(S3C64XX_AC97_GPD); ) I get
> errors about the function not being defined. I do know that it's in
> arch/arm/mach-s3c64xx/dev-audio.c
> and include/linux/platform_data/asoc-s3c.h but I can't see any other
> board-specific code using it.
>
> Also S3C64XX_AC97_GPD not being defined, (but present in both files).
> What include am I missing? I mean, of course I could include
> asoc-s3c.h, but that's not how other boards are
> doing it and they do have audio support. How is that done?

Just include <linux/platform_data/asoc-s3c.h> file in the board file.
This is the only header where the required functions are declared

/* The machine init code calls s3c*_ac97_setup_gpio with
  * one of these defines in order to select appropriate bank
  * of GPIO for AC97 pins
  */
#define S3C64XX_AC97_GPD  0
#define S3C64XX_AC97_GPE  1
extern void s3c64xx_ac97_setup_gpio(int);

Maybe some boards use default gpio configuration callbacks, grep shows
that only arch/arm/mach-s5pc100/mach-smdkc100.c includes this header.

Maybe it's worth to set statically a default gpio helper function:

--------------------8<------------------------

diff --git a/arch/arm/mach-s3c64xx/dev-audio.c 
b/arch/arm/mach-s3c64xx/dev-audio.c
index e367e87..bc41c13 100644
--- a/arch/arm/mach-s3c64xx/dev-audio.c
+++ b/arch/arm/mach-s3c64xx/dev-audio.c
@@ -201,7 +201,9 @@ static struct resource s3c64xx_ac97_resource[] = {
         [4] = DEFINE_RES_IRQ(IRQ_AC97),
  };

-static struct s3c_audio_pdata s3c_ac97_pdata;
+static struct s3c_audio_pdata s3c_ac97_pdata = {
+       .cfg_gpio = s3c64xx_ac97_cfg_gpd
+};

  static u64 s3c64xx_ac97_dmamask = DMA_BIT_MASK(32);

--------------------8<------------------------

so there is no need to add s3c64xx_ac97_setup_gpio(S3C64XX_AC97_GPD)
call to boards that use the GPD port.

> @Andrey One more thing, what do you mean by filter all writes to reg 0x0?
> Literally something like:
>
> void s3c_ac97_write(*ac97, reg, val){
>    if(reg == 0x0)
>      return;
>
>    ...code here..
>    ...
> }

I think this is what he meant. I would just try it and then when you
get similar results to Andrey we might consider trying to find the root
cause of this problem.

--

Regards,
Sylwester

Re: Audio support on Mini6410 board

[Alexander Nestorov]

Hi,

it's finally working! :)

This is my entire diff: http://pastie.org/5674242  (note: it doesn't include
sound/soc/samsung/mini6410_wm9713.c file, which is a copy of the
smdk6410_wm9713.c file)
Here's the mini6410_wm9713.c file: http://pastie.org/5674322


This is what I'm getting from boot:

soc-audio soc-audio: ASoC machine SMDK WM9713 should use snd_soc_register_card()
soc-audio soc-audio:  wm9713-hifi <-> samsung-ac97 mapping ok
ALSA device list:
  #0: MINI6410

which is what I was expecting (at least that's what I get booting the
FriendlyARM kernel).

I had to unmute everything because everything was muted by default,
but that really doesn't bother me.

The bad part is that, as Andrey told us, the filter hack is necessary.
If I remove it, I can't get any sound working.
Even further, if I try to run some amixer sset commands to unmute a
control, I get a few printfs with
"ac97: req addr = 12, rep addr = 00".

Also, there is one strange compile warning which I'm not able to
understand where is coming from:

WARNING: vmlinux.o(.data+0x6a78): Section mismatch in reference from
the variable smdk6410_b_pwr_5v_data to the (unknown reference)
.init.data:(unknown)
The variable smdk6410_b_pwr_5v_data references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

I do know that it came right after adding the mini6410_wm9713.c to the
Makefile but that really shouldn't make it bug. Also, it has nothing
to do with SMDK, which
is what this warning is suggesting. I'm not using
smdk6410_b_pwr_5v_data in my mach-mini6410.c so...

Sylwester, I can start sending you well-formated patches now or I can
wait for the filter hack to be fixed first, just say :)

Regards all and thank you for your help!

-- 
alexandernst

Re: Audio support on Mini6410 board

[Andrey Gusakov]

Hi,

On Sat, Jan 12, 2013 at 9:07 PM, Alexander Nestorov
<alexandernst@gmail.com> wrote:
> Hi,
>
> it's finally working! :)
>
> This is my entire diff: http://pastie.org/5674242  (note: it doesn't include
> sound/soc/samsung/mini6410_wm9713.c file, which is a copy of the
> smdk6410_wm9713.c file)
> Here's the mini6410_wm9713.c file: http://pastie.org/5674322
>
>
> This is what I'm getting from boot:
>
> soc-audio soc-audio: ASoC machine SMDK WM9713 should use snd_soc_register_card()
> soc-audio soc-audio:  wm9713-hifi <-> samsung-ac97 mapping ok
> ALSA device list:
>   #0: MINI6410
>
> which is what I was expecting (at least that's what I get booting the
> FriendlyARM kernel).
>
> I had to unmute everything because everything was muted by default,
> but that really doesn't bother me.
>
> The bad part is that, as Andrey told us, the filter hack is necessary.
> If I remove it, I can't get any sound working.
> Even further, if I try to run some amixer sset commands to unmute a
> control, I get a few printfs with
> "ac97: req addr = 12, rep addr = 00".
The error occurs if the record occurred in the wrong register, which
was expected. Code of s3c_ac97_read s3c_ac97_write and s3c_ac97_irq
looks dirty. May be it some kind of workaround of some undocumented
bug. The only one restriction I found is: "AC_CODEC_CMD ... When the
commands are written on the AC_CODDEC_CMD register, It is recommended
to have the delay time
between the command and the next command is more than 1 / 48kHz.". But
it keeped and should not lead to this error.
I tried to rework this functions, remove delays, but error still happens.

> Also, there is one strange compile warning which I'm not able to
> understand where is coming from:
>
> WARNING: vmlinux.o(.data+0x6a78): Section mismatch in reference from
> the variable smdk6410_b_pwr_5v_data to the (unknown reference)
> .init.data:(unknown)
> The variable smdk6410_b_pwr_5v_data references
> the (unknown reference) __initdata (unknown)
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
>
> I do know that it came right after adding the mini6410_wm9713.c to the
> Makefile but that really shouldn't make it bug. Also, it has nothing
> to do with SMDK, which
> is what this warning is suggesting. I'm not using
> smdk6410_b_pwr_5v_data in my mach-mini6410.c so...
>
> Sylwester, I can start sending you well-formated patches now or I can
> wait for the filter hack to be fixed first, just say :)
>
> Regards all and thank you for your help!
>
> --
> alexandernst

Re: Audio support on Mini6410 board

[Sylwester Nawrocki]

Hi,

Cc: Kukjin Kim, the maintainer of Samsung ARM sub-arch

On 01/12/2013 06:07 PM, Alexander Nestorov wrote:
> Hi,
>
> it's finally working! :)

Great news! ;) I guess you now have all required features working with
latest mainline kernel ? Is there anything still missing ?

> This is my entire diff: http://pastie.org/5674242  (note: it doesn't include
> sound/soc/samsung/mini6410_wm9713.c file, which is a copy of the
> smdk6410_wm9713.c file)
> Here's the mini6410_wm9713.c file: http://pastie.org/5674322
>
>
> This is what I'm getting from boot:
>
> soc-audio soc-audio: ASoC machine SMDK WM9713 should use snd_soc_register_card()
> soc-audio soc-audio:  wm9713-hifi<->  samsung-ac97 mapping ok
> ALSA device list:
>    #0: MINI6410
>
> which is what I was expecting (at least that's what I get booting the
> FriendlyARM kernel).

Sounds good.

> I had to unmute everything because everything was muted by default,
> but that really doesn't bother me.
>
> The bad part is that, as Andrey told us, the filter hack is necessary.
> If I remove it, I can't get any sound working.
> Even further, if I try to run some amixer sset commands to unmute a
> control, I get a few printfs with
> "ac97: req addr = 12, rep addr = 00".
>
> Also, there is one strange compile warning which I'm not able to
> understand where is coming from:
>
> WARNING: vmlinux.o(.data+0x6a78): Section mismatch in reference from
> the variable smdk6410_b_pwr_5v_data to the (unknown reference)
> .init.data:(unknown)
> The variable smdk6410_b_pwr_5v_data references
> the (unknown reference) __initdata (unknown)
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
>
> I do know that it came right after adding the mini6410_wm9713.c to the
> Makefile but that really shouldn't make it bug. Also, it has nothing
> to do with SMDK, which
> is what this warning is suggesting. I'm not using
> smdk6410_b_pwr_5v_data in my mach-mini6410.c so...

This is an issue at the SMDK board file, don't need to worry about it.
I must have shown up when the kernel got linked again. The below patch
should fix that issue.

> Sylwester, I can start sending you well-formated patches now or I can
> wait for the filter hack to be fixed first, just say :)

I know I asked you previously for preparing patches so others don't
need to waste much time to enable all required features on those s3c64xx
reference boards. But now when there is the device tree support for
s3c64xx SoCs on the horizon [1], I'm not sure if we should be updating
the board files. Especially adding new static platform devices might be
not welcome.

@Kukjin: Do you think we can merge things like in this diff:
http://pastie.org/5674242, while device tree support is being worked on ?
Or should that be rather kept in private branches ?

[1] http://www.spinics.net/lists/arm-kernel/msg216616.html

Regards,
Sylwester

-------------8<--------------------------------------

 From 03c7f2470f58a6575b4a15ff52e9d1252f392933 Mon Sep 17 00:00:00 2001
From: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
Date: Sat, 12 Jan 2013 19:49:13 +0100
Subject: [PATCH] ARM: S3C64XX: Fix section mismatch in smdk6410 board file

This patch corrects smdk6410_b_pwr_5v_consumers[] array attribute
and eliminates following compilation warning:

WARNING: arch/arm/mach-s3c64xx/built-in.o(.data+0x5704): Section mismatch
in reference from the variable smdk6410_b_pwr_5v_data to the (unknown
reference) .init.data:(unknown)

The variable smdk6410_b_pwr_5v_data references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

Reported-by: Alexander Nestorov <alexandernst@gmail.com>
Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
---
  arch/arm/mach-s3c64xx/mach-smdk6410.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c 
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index 574a9ee..819c133 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -209,7 +209,7 @@ static struct platform_device smdk6410_smsc911x = {
  };

  #ifdef CONFIG_REGULATOR
-static struct regulator_consumer_supply smdk6410_b_pwr_5v_consumers[] 
__initdata = {
+static struct regulator_consumer_supply smdk6410_b_pwr_5v_consumers[] = {
  	REGULATOR_SUPPLY("PVDD", "0-001b"),
  	REGULATOR_SUPPLY("AVDD", "0-001b"),
  };
-- 
1.7.4.1
-------------8<--------------------------------------

Re: Audio support on Mini6410 board

[Juergen Beisert]

Hi Alexander,

Alexander Nestorov wrote:
> it's finally working! :)

I gave your patches yesterday a try on my Mini6410: when I enable the audio 
support, the system freezes forever. Don't know why yet.
What is the base revision where I have to apply the patches to? I tried with 
3.7.2.

Regards,
Juergen

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |

Re: [oselas] Audio support on Mini6410 board

[Alexander Nestorov]

Hi everyone :)



Juergen Beisert <jbe@pengutronix.de>:
> I gave your patches yesterday a try on my Mini6410: when I enable the audio
> support, the system freezes forever. Don't know why yet.
> What is the base revision where I have to apply the patches to? I tried with
> 3.7.2.

I'm using Sylwester's s3c-camif branch in v4l media[1], that is 3.7.0


Sylwester Nawrocki <sylvester.nawrocki@gmail.com>:
> Great news! ;) I guess you now have all required features working with
>latest mainline kernel ? Is there anything still missing ?

I'm still playing around with the board, trying to run my project on top of it.
Till now video works great (both video output and v4l2 src).
Audio is working great (both speakers and headphones), but I haven't tested
playing audio more than 10s (other than gst-launch audiotestsrc !
autoaudiosink).
Network (via eth) is working too.

I'm not sure if mic is working ok or failing. Can't say yet as there
is some kind of
audio input but it's really week and there's too much noise. I'll keep
playing with it
for a few more days.

The only thing I haven't really tested is the touch screen.
That's what I get if I try to run 'ts_test':
/dev/input/event1: No such file or directory
Also, if I start tapping at the screen, after ~10 taps I start getting
this on the console:
s3c_adc_start: failed to find adc

Anyways, during the boot I get:

s3c-adc s3c64xx-adc: operating without regulator "vdd" .
platform s3c64xx-adc: Driver s3c-adc requests probe deferral
samsung-ts s3c64xx-ts: driver attached, registering input device
input: S3C24XX TouchScreen as /devices/virtual/input/input0

So, why is ts_test trying to use input1 instead of input0?
Also, I'm missing some code related to vdd, right? Can't say if that's
critical or not...

If there is built-in support for this in the kernel, then there must
be something wrong (but small/easy to fix)
with my code. If there isn't, then I'll try diff-ing FriendlyARM's
kernel and an untouched one
and applying to your branch.

>This patch corrects smdk6410_b_pwr_5v_consumers[] compilation warning:

Yes indeed, it worked like a charm :)


>I know I asked you previously for preparing patches so others don't
>need to waste much time to enable all required features on those s3c64xx
>reference boards. But now when there is the device tree support for
>s3c64xx SoCs on the horizon

I'm fine with whatever fits better in the kernel :)
We can wait and see if my patches are needed or I can send them to you
now (or at any moment in the future),
you just need to say.


Regards!


[1] http://git.linuxtv.org/snawrocki/media.git/shortlog/refs/heads/testing/s3c-camif

Re: [oselas] Audio support on Mini6410 board

[Alexander Nestorov]

Hi,

I have been playing for a week with the board. Both audio and video
work correctly, but I haven't
been able to set the mic settings in alsamixer (so I can't test the mic).
The touchscreen isn't working, so I'll try to make it working and send
you some patches.

Anyways, now there's another question/problem that I have. Video
playback is really slow because
I'm not using the device's cpu-decoder but rather doing everything in
software mode.

Is there support for hardware acceleration in the kernel for this
device? Also, after talking with
some people from #gstreamer they pointed me to a component[1] in
gstreamer, but I'm not really
sure how to I use it. Any ideas/experience with that?

Regards!

[1] http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/sys/mfc

-- 
alexandernst

Re: [oselas] Audio support on Mini6410 board

[Andrey Gusakov]

Hi.

On Mon, Jan 21, 2013 at 12:46 AM, Alexander Nestorov
<alexandernst@gmail.com> wrote:
> Hi,
>
> I have been playing for a week with the board. Both audio and video
> work correctly, but I haven't
> been able to set the mic settings in alsamixer (so I can't test the mic).
> The touchscreen isn't working, so I'll try to make it working and send
> you some patches.
>
> Anyways, now there's another question/problem that I have. Video
> playback is really slow because
> I'm not using the device's cpu-decoder but rather doing everything in
> software mode.
>
> Is there support for hardware acceleration in the kernel for this
> device? Also, after talking with
> some people from #gstreamer they pointed me to a component[1] in
> gstreamer, but I'm not really
> sure how to I use it. Any ideas/experience with that?
Kernel that support MFC v1.0 is exist. But it is 2.6.28.
I am now experimenting with MFC on 6410, but it will take a long time
to bring to working condition.
I have just wrote code thats load MFC firmware, starts MFC and get SW version.
[1] is just plugin for Exynos version of MFC.

>
> Regards!
>
> [1] http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/sys/mfc
>
> --
> alexandernst

Re: [oselas] Audio support on Mini6410 board

[Alexander Nestorov]

Hi,

I see. Maybe you already saw it, but just in case, I found this[1] I
hope it helps.
Do you plan sharing your code in GitHub or equivalent? I'm working on
that board too
and I'll probably have to make my software use hw acceleration.

Regards!

[1] http://code.google.com/p/openwrt-arm/source/browse/trunk/openwrt/target/linux/s3c64xx/files-2.6.36/drivers/media/video/samsung/?r=20


-- 
alexandernst

Re: [oselas] Audio support on Mini6410 board

[Andrey Gusakov]

Hi.

On Mon, Jan 21, 2013 at 12:07 PM, Alexander Nestorov
<alexandernst@gmail.com> wrote:
> Hi,
>
> I see. Maybe you already saw it, but just in case, I found this[1] I
> hope it helps.
Thanks. It s looks like code from 2.6.28, I'll take a closer look.

> Do you plan sharing your code in GitHub or equivalent? I'm working on
> that board too
> and I'll probably have to make my software use hw acceleration.
Yes, I'll share it as soon as get it work or at least compile without
errors. Now it looks like mix of code from 2.6.28, s5p-mfc code and
documentation quotes.

Re: [oselas] Audio support on Mini6410 board

[Sylwester Nawrocki]

Hi,

On 01/20/2013 09:46 PM, Alexander Nestorov wrote:
> I have been playing for a week with the board. Both audio and video
> work correctly, but I haven't
> been able to set the mic settings in alsamixer (so I can't test the mic).
> The touchscreen isn't working, so I'll try to make it working and send
> you some patches.
>
> Anyways, now there's another question/problem that I have. Video
> playback is really slow because
> I'm not using the device's cpu-decoder but rather doing everything in
> software mode.
>
> Is there support for hardware acceleration in the kernel for this
> device? Also, after talking with

No, there is still no video codec (MFC) driver for s3c6410 upstream.
Now, when there is support for the hardware video codec available in
newer SoC (Exynos4/5) and some V4L2 infrastructure added together with
the s5p-mfc driver, it should be much easier to write a driver for the
s3c64xx MFC. Still it is relatively huge task and I didn't see any
volunteers willing to add support upstream for the s3c64xx MFC, except
Andrey who replied in this thread. I could provide some help, but
I will likely won't find time to do any development work or testing.

Also please note there is no support for the mem-to-mem features (color
space conversion, scaling, rotation/flip) in the s3c-camif driver.
It should be relatively simple to add it though. I'm not really sure
if it is needed to run the codec on s3c64xx, but the plugin [1] uses
FIMC (CAMIF) as a video post-processor. This plugin sets up processing
pipeline like:

memory (compressed data) -> MFC -> (YCbCr tiled) memory -> FIMC -> 
memory (display)

> some people from #gstreamer they pointed me to a component[1] in
> gstreamer, but I'm not really
> sure how to I use it. Any ideas/experience with that?

This component uses multi-planar V4L2 API [2], which also use the s5p-mfc
and s5p-fimc driver. The s3c-camif driver uses the single-planar API
at the camera capture video node. So if this existing plugin was to be
used with the s3c64xx hardware, the drivers for it would have to
support the multi-planar API, which I believe is not needed on s3c64xx
hardware.
The best is probably to make the drivers only single-plane API aware
and adapt the plugin. The required changes at the plugin wouldn't be
significant.

Anyway, a real problem here is lack of the s3c64xx MFC driver. So
first we need the codec driver, which could be tested with modified
test application [3], or directly with modified plugin [1].

> Regards!
>
> [1] http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/sys/mfc

[2] http://linuxtv.org/downloads/v4l-dvb-apis/planar-apis.html
[3] 
http://git.infradead.org/users/kmpark/public-apps/tree/9c057b001e8873861a70f7025214003837a0860b

--

Regards,
Sylwester

Re: [oselas] Audio support on Mini6410 board

[Sylwester Nawrocki]

Cc: LMML

On 02/09/2013 07:21 PM, Sylwester Nawrocki wrote:
> Hi,
>
> On 01/20/2013 09:46 PM, Alexander Nestorov wrote:
>> I have been playing for a week with the board. Both audio and video
>> work correctly, but I haven't
>> been able to set the mic settings in alsamixer (so I can't test the mic).
>> The touchscreen isn't working, so I'll try to make it working and send
>> you some patches.
>>
>> Anyways, now there's another question/problem that I have. Video
>> playback is really slow because
>> I'm not using the device's cpu-decoder but rather doing everything in
>> software mode.
>>
>> Is there support for hardware acceleration in the kernel for this
>> device? Also, after talking with
>
> No, there is still no video codec (MFC) driver for s3c6410 upstream.
> Now, when there is support for the hardware video codec available in
> newer SoC (Exynos4/5) and some V4L2 infrastructure added together with
> the s5p-mfc driver, it should be much easier to write a driver for the
> s3c64xx MFC. Still it is relatively huge task and I didn't see any
> volunteers willing to add support upstream for the s3c64xx MFC, except
> Andrey who replied in this thread. I could provide some help, but
> I will likely won't find time to do any development work or testing.
>
> Also please note there is no support for the mem-to-mem features (color
> space conversion, scaling, rotation/flip) in the s3c-camif driver.
> It should be relatively simple to add it though. I'm not really sure
> if it is needed to run the codec on s3c64xx, but the plugin [1] uses
> FIMC (CAMIF) as a video post-processor. This plugin sets up processing
> pipeline like:
>
> memory (compressed data) -> MFC -> (YCbCr tiled) memory -> FIMC ->
> memory (display)
>
>> some people from #gstreamer they pointed me to a component[1] in
>> gstreamer, but I'm not really
>> sure how to I use it. Any ideas/experience with that?
>
> This component uses multi-planar V4L2 API [2], which also use the s5p-mfc
> and s5p-fimc driver. The s3c-camif driver uses the single-planar API
> at the camera capture video node. So if this existing plugin was to be
> used with the s3c64xx hardware, the drivers for it would have to
> support the multi-planar API, which I believe is not needed on s3c64xx
> hardware.
> The best is probably to make the drivers only single-plane API aware
> and adapt the plugin. The required changes at the plugin wouldn't be
> significant.
>
> Anyway, a real problem here is lack of the s3c64xx MFC driver. So
> first we need the codec driver, which could be tested with modified
> test application [3], or directly with modified plugin [1].
>
>> Regards!
>>
>> [1] http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/sys/mfc
>
> [2] http://linuxtv.org/downloads/v4l-dvb-apis/planar-apis.html
> [3]
> http://git.infradead.org/users/kmpark/public-apps/tree/9c057b001e8873861a70f7025214003837a0860b
>
>
> --
>
> Regards,
> Sylwester

Re: [oselas] Audio support on Mini6410 board

[Tomasz Figa]

Hi,

On Saturday 09 of February 2013 19:21:32 Sylwester Nawrocki wrote:
> Hi,
> 
> On 01/20/2013 09:46 PM, Alexander Nestorov wrote:
> > I have been playing for a week with the board. Both audio and video
> > work correctly, but I haven't
> > been able to set the mic settings in alsamixer (so I can't test the
> > mic). The touchscreen isn't working, so I'll try to make it working
> > and send you some patches.
> > 
> > Anyways, now there's another question/problem that I have. Video
> > playback is really slow because
> > I'm not using the device's cpu-decoder but rather doing everything in
> > software mode.
> > 
> > Is there support for hardware acceleration in the kernel for this
> > device? Also, after talking with
> 
> No, there is still no video codec (MFC) driver for s3c6410 upstream.
> Now, when there is support for the hardware video codec available in
> newer SoC (Exynos4/5) and some V4L2 infrastructure added together with
> the s5p-mfc driver, it should be much easier to write a driver for the
> s3c64xx MFC. Still it is relatively huge task and I didn't see any
> volunteers willing to add support upstream for the s3c64xx MFC, except
> Andrey who replied in this thread. I could provide some help, but
> I will likely won't find time to do any development work or testing.
> 
> Also please note there is no support for the mem-to-mem features (color
> space conversion, scaling, rotation/flip) in the s3c-camif driver.
> It should be relatively simple to add it though. I'm not really sure
> if it is needed to run the codec on s3c64xx, but the plugin [1] uses
> FIMC (CAMIF) as a video post-processor. This plugin sets up processing
> pipeline like:
> 
> memory (compressed data) -> MFC -> (YCbCr tiled) memory -> FIMC ->
> memory (display)

AFAIK the MFC (like rest of the media processing peripherals) on S3C6410 
does not support tiled buffers. It uses the standard planar Y + Cb + Cr 
format.

In addition, the MFC of S3C6410 supports built-in rotation and mirroring 
of decoded video.

For scaling, there is a video post-processor block. There is no upstreamed 
driver for it, but the hardware is reasonably simple, so it wouldn't be 
too hard to write a driver for it. (I might be able to do it, although 
don't count on me, as I have also much other work to do, part of which is 
also related to S3C64xx).

Best regards,
Tomasz

> > some people from #gstreamer they pointed me to a component[1] in
> > gstreamer, but I'm not really
> > sure how to I use it. Any ideas/experience with that?
> 
> This component uses multi-planar V4L2 API [2], which also use the
> s5p-mfc and s5p-fimc driver. The s3c-camif driver uses the
> single-planar API at the camera capture video node. So if this existing
> plugin was to be used with the s3c64xx hardware, the drivers for it
> would have to support the multi-planar API, which I believe is not
> needed on s3c64xx hardware.
> The best is probably to make the drivers only single-plane API aware
> and adapt the plugin. The required changes at the plugin wouldn't be
> significant.
> 
> Anyway, a real problem here is lack of the s3c64xx MFC driver. So
> first we need the codec driver, which could be tested with modified
> test application [3], or directly with modified plugin [1].
> 
> > Regards!
> > 
> > [1] http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/sys/mfc
> 
> [2] http://linuxtv.org/downloads/v4l-dvb-apis/planar-apis.html
> [3]
> http://git.infradead.org/users/kmpark/public-apps/tree/9c057b001e8873861
> a70f7025214003837a0860b
> 
> --
> 
> Regards,
> Sylwester
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in the body of a message to
> majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hi again

[Sylwester Nawrocki]

Hi Alexander,

Thanks for the update ;)

On 02/05/2013 11:50 PM, Alexander Nestorov wrote:
> Hi Sylwester :)
>
>
> I have been working wth 2 guys from Collabora (company behind
> GStreamer/Farstream) and there has been
> some progress.
>
> We saw that if I run gst-launch v4l2src ! dfbvideosink (without any
> caps) then gstreamer won't show anything at all.
> But as soon as I force caps, like v4l2src !
> video/x-raw-rgb,width=XXX,height=YYY,bpp=16 ! dfbvideosink everything
> starts working.
>
> Same way, if I launch my Farstream app without any parameters, it
> crashes. But if I specify bpp and depth then
> it starts working.
>
> I don't want to confuse you so I'll copy exactly what one of the guys said:
>
> [23:02]<alexandernst_>  KaKaRoTo: I have another question regarding
> the CMOS and the caps "hack"
> [23:03]<alexandernst_>  we're setting bpp and depth because the driver
> isn't returning: a) anything at all  b) invalid values  c) ???
> [23:06]<KaKaRoTo>  alexandernst_, because the driver is reporting big
> endian for 16 bits, and it could easily be a gstreamer issue not
> supporting big endian 16bits rgb.. or the driver is reporting the
> endianness wrong...
> [23:06]<KaKaRoTo>  alexandernst_, the other reason is because the
> driver isn't giving us the capabilities of the CMOS, so we don't knowh

Yes, the driver doesn't implement VIDIOC_ENUM_FRAMESIZES ioctl at
/dev/video? device node. These parameters are supposed to be retrieved
by a driver-specific plugin at the libv4l [1] (it still don't exists
yet..) library. And applications (e.g. v4l2src) should use v4l2_* calls
from this library, rather than plain ioctl(). Until the plugin for the
s3c-camif driver (or a generic Media Controller plugin) is added to
libv4l there is no way v4l2src can query the list of supported resolutions
by the CMOS sensor. Well, it could be hacked in the driver, but I don't
want to do that. I could send you a patch for your own use if you wish,
and if I find some time to write it. ;)

> which resolutions it supports, so we're forced to manually setting it,
> otherwise it tries to do 2048x4096 and it doesn't work..

This looks suspicious, let me check it...

Hmm, no, its GStreamer that forces the s3c-camif driver to use its maximum
supported resolution at /dev/video?.

root@mini2440:~ v4l2-ctl -d /dev/video0 --all
Driver Info (not using libv4l2):
         Driver name   : s3c-camif
         Card type     : s3c-camif
         Bus info      : platform:s3c2440-camif.0
         Driver version: 3.8.0
         Capabilities  : 0x84000001
                 Video Capture
                 Streaming
                 Device Capabilities
         Device Caps   : 0x04000001
                 Video Capture
                 Streaming
Format Video Capture:
         Width/Height  : 1280/1024
         Pixel Format  : '422P'
         Field         : None
         Bytes per Line: 1280
         Size Image    : 614400
         Colorspace    : JPEG (JFIF/ITU601)
Selection: compose, Left 0, Top 0, Width 1280, Height 1024
Selection: compose_default, Left 0, Top 0, Width 1280, Height 1024
Selection: compose_bounds, Left 0, Top 0, Width 1280, Height 1024
Video input : 0 (OV9650: ok)
Priority: 2

The default resolution is 1280/1024.

The problem is that there is not enough memory in your system to allocate
all 2048x4096 buffers (it's 16 MB each, 2 bytes per pixel for 422P format).
The driver doesn't enforce any policy on memory allocation, i.e. there is
no limit in the driver. I could add some module parameter for that if
required. But in general it's the v4l2 memory allocator that should return
an allocation error and it should be propagated up to v4l2 videobuf2 layer
and to GStreamer (e.g. through VIDIOC_REQBUFS ioctl).

IIRC there were some issues in the videobuf2 about reporting memory
allocation errors back to user space. Not sure if this is already fixed.
I'll investigate it and will let you know.

I have enabled debug in videobuf2 and got something like below, which
looks like something unexpected:

root@mini2440:~ echo 100 > /sys/module/videobuf2_core/parameters/debug

root@mini2440:~ gst-launch -v v4l2src device=/dev/video0 queue-size=2
  ! video/x-raw-yuv,format='(fourcc)'YV12 ! ffmpegcolorspace ! fbdevsink

root@mini2440:~ dmesg -c
[ 1907.110000] s3c-camif s3c2440-camif: dma_alloc_coherent of size 
12582912 failed
[ 1907.115000] vb2: Failed allocating memory for buffer 1

The error is ignored here, it should all fail at this point.

[ 1907.120000] vb2: Buffer 0, plane 0 offset 0x00000000
[ 1907.125000] vb2: Allocated 1 buffers, 1 plane(s) each
[ 1907.220000] vb2: Buffer 0, plane 0 successfully mapped
[ 1907.225000] vb2: qbuf of buffer 0 succeeded
[ 1907.230000] vb2: Streamon successful


> [23:07]<KaKaRoTo>  which is also why it freezes (doesn't output
> buffers) instead of giving an error when you try to set that
> resolution
>
> I made a bug report here, and there are 2 REs which might be really
> helpful: https://bugzilla.gnome.org/show_bug.cgi?id=693175
>
>
> On the other hand, I haven't noticed till now because I compile with
> -j9, but I get this when I compile the kernel:
>
> CC      drivers/media/platform/s3c-camif/camif-capture.o
> drivers/media/platform/s3c-camif/camif-capture.c: In function
> 's3c_camif_subdev_set_fmt':
> drivers/media/platform/s3c-camif/camif-capture.c:1281:25: warning:
> array subscript is below array bounds
>
> Maybe that is somehow related to the bug I'm having?

This looks like a real bug, but I doubt it is much related to your
issues as above. Thanks for reporting it. I will prepare a patch for
this for v3.9-rc.

And please note that you should set resolution and frame rate
with e.g. media-ctl tool for optimal results. The libv4l plugin
would let us to do these things from the GStreamer level.

Let me answer your previous e-mail, but can do it only tomorrow...
Need more sleeeeping... ;)

--

Regards,
Sylwester

[1] http://git.linuxtv.org/v4l-utils.git

Re: Hi again

[Sylwester Nawrocki]

On 02/07/2013 12:53 AM, Sylwester Nawrocki wrote:
> root@mini2440:~ echo 100 > /sys/module/videobuf2_core/parameters/debug
>
> root@mini2440:~ gst-launch -v v4l2src device=/dev/video0 queue-size=2
> ! video/x-raw-yuv,format='(fourcc)'YV12 ! ffmpegcolorspace ! fbdevsink
>
> root@mini2440:~ dmesg -c
> [ 1907.110000] s3c-camif s3c2440-camif: dma_alloc_coherent of size
> 12582912 failed
> [ 1907.115000] vb2: Failed allocating memory for buffer 1
>
> The error is ignored here, it should all fail at this point.
>
> [ 1907.120000] vb2: Buffer 0, plane 0 offset 0x00000000
> [ 1907.125000] vb2: Allocated 1 buffers, 1 plane(s) each
> [ 1907.220000] vb2: Buffer 0, plane 0 successfully mapped
> [ 1907.225000] vb2: qbuf of buffer 0 succeeded
> [ 1907.230000] vb2: Streamon successful

I've found there is a bug in the driver. It happens that only one buffer
out of two gets allocated and the minimum required for the driver to start
streaming is 2. I've pushed a patch fixing this bug [1] to the 3.7 based
testing/s3c-camif branch. I'll post it to LMML in a minute.

It won't really solve your problem, but at least there is now clear
indication what's wrong, and the application should not get stuck. Please
check you CMA memory region size. I suspect that you use the default 16 MB
and it allows you to allocate only one buffer. 16 MB might still be
sufficient for 1280x1024 - OV9650's maximum resolution. Anyway, it might
be worth to check what CONFIG_CMA_SIZE_MBYTES is set to.
(Device drivers -> Generic Driver Options -> Contiguous Memory Allocator)

>> [23:07]<KaKaRoTo> which is also why it freezes (doesn't output
>> buffers) instead of giving an error when you try to set that
>> resolution

Thanks,
Sylwester