Re: [linux-sunxi] Kernel CEC driver.

2016-10-18 Thread Chen-Yu Tsai 
On Tue, Oct 18, 2016 at 6:14 PM, Hans de Goede  wrote:
> Hi,
>
> On 17-10-16 23:33, Jarosław Nieć wrote:
>>
>> Hi Maxime,
>>
>>
>> On Mon, Oct 17, 2016 at 9:51 PM, Maxime Ripard
>> >
>> wrote:
>>
>> Hi Jarosław,
>>
>> On Mon, Oct 17, 2016 at 08:15:53PM +0200, Jarosław Nieć wrote:
>> > I've decided that I want to learn kernel hacking a little and
>> because of
>> > that and because of new HDMI CEC Framework in kernel 4.8 I chose to
>> write
>> > CEC driver for old Allwinner A10.
>> > There in no CEC hardware core for this CPU and I think the only way
>> is to
>> > create implementation that uses bit banging.
>> > I've investigated the topic a little, tried few things and finally I
>> have
>> > prototype that more or less can receive and send CEC messages using
>> this
>> > new Framework.
>> > Code isn't very pretty right now and there is few things missing
>> (like
>> > proper error handling etc.) but before I continue I want firstly ask
>> you
>> > guys few questions.
>>
>> I actually started to look into this too a few days ago. Nothing
>> really major though :)
>>
>>
>> OK so maybe I will clean my implementation (I hope in few days) and pass
>> it to first review.
>> You could see it and decide if it make sense to invest more time in it or
>> start from scratch :)
>>
>>
>> > 1) For bit banging I'm using high resolution timer. If CEC line is
>> idle
>> > this timer ticks every 2.4 ms (416Hz). For every tick it checks the
>> state
>> > of CEC line and when it detects start of CEC message it reduce delay
>> to 0.1
>> > ms (1Hz).
>> > We need more or less this kind of frequency to probe CEC line to
>> detect if
>> > transmitted bit is 0 or 1. I've used high resolution timer because
>> it was
>> > the solution that give me this very accurate 0.1 ms delay.
>> > I've also tried udelay, usleep_range and few other functions, but
>> without
>> > success. They were too unreliable (because triggered by scheduler)
>> or too
>> > CPU consuming (because of using busy-wait loop for too long).
>> > OK so the first question is does it make sens to use HR timer for
>> bit
>> > banging? What other things I could try? Maybe you know some traps
>> that are
>> > connected with HR timers?
>>
>> I had this exact same discussion today on #v4l, and what design we
>> should implement, and we came to pretty much that conclusion.
>>
>>
>> I had also another idea how this CEC could be implemented, but I don't
>> think it is possible.
>> CEC line is connected to P23 CPU ball (for A10) and it would be very good
>> if we could use this pin as a GPIO.
>> Implementing CEC using GPIO should be much easier than using this CEC
>> register.
>> But as I mentioned I don't think it is possible, not for this pin.
>>
>> BTW Implementing general cec-over-gpio driver could be also quite useful
>> for lot of projects.
>
>
> If all the hardware allows you to-do is set / read the pin, you could write
> a gpio-chip
> driver for it, and then attach a generic cec-over-gpio driver to that, that
> seems like
> a better idea then an Allwinner specific bit-bang driver.

That might not be easy to do. The CEC line is a dedicated pin on the SoC,
leading to the HDMI controller, much like the HDMI DDC lines. And the control
bits are in the middle of the HDMI register space.

Doing a one-line GPIO controller for that pin should work, though it's a
really convoluted approach.

ChenYu

>
>
> Regards,
>
> Hans
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] A20, Mainline kernel: how to get sound on headphone output?

2016-10-18 Thread Thomas Gahr 

>
> can you run dmesg | grep codec and also show a diff of all your 
> changes. To get the codec working should only be one line added to 
> your dts. 
>

D'oh! You got me thinking here for a while. Turns out, I made the wrong 
kind of change to the dts.
I generated the .dts from the .dtb in /boot/dtbs with dtc -I dtb -O dts and 
then changed codec's status from "disabled" to "enabled". (I'm coming from 
3.4.X & .fex land so I need to get used to dts).
I now added the following entry to sun7i-a20-olinuxino-micro.dts and went 
the whole preprocess-then-dtc route and it works fine now.

 {
  status="okay";
}



Sorry for the noise and thanks for the help/inspiration :)

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] A20, Mainline kernel: how to get sound on headphone output?

2016-10-18 Thread Code Kipper 
On 18 October 2016 at 12:13, Thomas Gahr  wrote:
>> Hi Thomas,
>> have you played with the alsamixer settings? you may have to do some
>> unmuting https://groups.google.com/forum/#!topic/linux-sunxi/rJDiF8qSnLc
>
>
> Hi CodeKipper,
> thanks for your answer!
>
> I'm afraid playing with alsa(mixer) settings is no help for me, since alsa
> does not even recognize the card, so there's nothing I can unmute.
> I *did* try to play with the settings (like the suggestion from
> https://linux-sunxi.org/Audio_Codec) but, no surprise here, this did not
> work, it only lead to I/O error message from alsamixer.
> The hardware is not even showing up in /sys/class/sound so I think the error
> is "below" alsa, i.e. something wrong with my kernel config / modules loaded
> or missing
can you run dmesg | grep codec and also show a diff of all your
changes. To get the codec working should only be one line added to
your dts.
CK
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Kernel CEC driver.

2016-10-18 Thread Hans de Goede 

Hi,

On 17-10-16 23:33, Jarosław Nieć wrote:

Hi Maxime,

On Mon, Oct 17, 2016 at 9:51 PM, Maxime Ripard > wrote:

Hi Jarosław,

On Mon, Oct 17, 2016 at 08:15:53PM +0200, Jarosław Nieć wrote:
> I've decided that I want to learn kernel hacking a little and because of
> that and because of new HDMI CEC Framework in kernel 4.8 I chose to write
> CEC driver for old Allwinner A10.
> There in no CEC hardware core for this CPU and I think the only way is to
> create implementation that uses bit banging.
> I've investigated the topic a little, tried few things and finally I have
> prototype that more or less can receive and send CEC messages using this
> new Framework.
> Code isn't very pretty right now and there is few things missing (like
> proper error handling etc.) but before I continue I want firstly ask you
> guys few questions.

I actually started to look into this too a few days ago. Nothing
really major though :)


OK so maybe I will clean my implementation (I hope in few days) and pass it to 
first review.
You could see it and decide if it make sense to invest more time in it or start 
from scratch :)


> 1) For bit banging I'm using high resolution timer. If CEC line is idle
> this timer ticks every 2.4 ms (416Hz). For every tick it checks the state
> of CEC line and when it detects start of CEC message it reduce delay to 
0.1
> ms (1Hz).
> We need more or less this kind of frequency to probe CEC line to detect if
> transmitted bit is 0 or 1. I've used high resolution timer because it was
> the solution that give me this very accurate 0.1 ms delay.
> I've also tried udelay, usleep_range and few other functions, but without
> success. They were too unreliable (because triggered by scheduler) or too
> CPU consuming (because of using busy-wait loop for too long).
> OK so the first question is does it make sens to use HR timer for bit
> banging? What other things I could try? Maybe you know some traps that are
> connected with HR timers?

I had this exact same discussion today on #v4l, and what design we
should implement, and we came to pretty much that conclusion.


I had also another idea how this CEC could be implemented, but I don't think it 
is possible.
CEC line is connected to P23 CPU ball (for A10) and it would be very good if we 
could use this pin as a GPIO.
Implementing CEC using GPIO should be much easier than using this CEC register.
But as I mentioned I don't think it is possible, not for this pin.

BTW Implementing general cec-over-gpio driver could be also quite useful for 
lot of projects.


If all the hardware allows you to-do is set / read the pin, you could write a 
gpio-chip
driver for it, and then attach a generic cec-over-gpio driver to that, that 
seems like
a better idea then an Allwinner specific bit-bang driver.


Regards,

Hans

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] A20, Mainline kernel: how to get sound on headphone output?

2016-10-18 Thread Thomas Gahr 

>
> Hi Thomas, 
> have you played with the alsamixer settings? you may have to do some 
> unmuting https://groups.google.com/forum/#!topic/linux-sunxi/rJDiF8qSnLc 
>

Hi CodeKipper,
thanks for your answer!

I'm afraid playing with alsa(mixer) settings is no help for me, since alsa 
does not even recognize the card, so there's nothing I can unmute.
I *did* try to play with the settings (like the suggestion from 
https://linux-sunxi.org/Audio_Codec) but, no surprise here, this did not 
work, it only lead to I/O error message from alsamixer.
The hardware is not even showing up in /sys/class/sound so I think the 
error is "below" alsa, i.e. something wrong with my kernel config / modules 
loaded or missing 

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] A20, Mainline kernel: how to get sound on headphone output?

2016-10-18 Thread Thomas Gahr 
Hello,

I've been trying to figure out how to get sound on the headphone outputs. 
AFAICT, A20 supports I2S and S/PDIF but these are for external audio 
components, while I only need the internal headphone amp.
I've seen that the audio codec has been added in 4.4 but it is disabled in 
the .dts file used in my kernel. I've enabled it and re-compiled the dtb, 
and after reboot I loaded the sun4i-codec module but still I have no 
success.

The problem: alsa does not show the device, also in /dev/snd there's only 
the USB audio card I've been using so far (which I'd love to get rid of). 
dmesg also does not mention anything about the audio-codec.
I'm sure there's something simple I'm missing, the question is just: what?

Some information:

root@alarmaster /boot # uname -a
Linux alarmaster 4.8.1-2-ARCH #1 SMP Sat Oct 8 15:03:46 MDT 2016 armv7l 
GNU/Linux

root@alarmaster /boot # lsmod|grep snd
snd_soc_pcm 5489  0
snd_soc_s3c_dma 1531  1 snd_soc_pcm
snd_soc_core  151946  3 sun4i_codec,snd_soc_pcm,snd_soc_s3c_dma
snd_pcm_dmaengine   5600  1 snd_soc_core
ac97_bus1838  1 snd_soc_core
snd_usb_audio 141947  0
snd_usbmidi_lib20465  1 snd_usb_audio
snd_hwdep   6292  1 snd_usb_audio
snd_rawmidi23170  1 snd_usbmidi_lib
snd_seq_device  4852  1 snd_rawmidi
snd_pcm95325  4 
snd_soc_pcm,snd_usb_audio,snd_pcm_dmaengine,snd_soc_core
snd_timer  22629  1 snd_pcm



root@alarmaster /boot # lsmod
Module  Size  Used by
snd_soc_pcm 5489  0
snd_soc_s3c_dma 1531  1 snd_soc_pcm
sun4i_codec12356  0
snd_soc_core  151946  3 sun4i_codec,snd_soc_pcm,snd_soc_s3c_dma
snd_pcm_dmaengine   5600  1 snd_soc_core
ac97_bus1838  1 snd_soc_core
ccm 7895  3
usb_f_ecm   6613  2
usb_f_rndis15906  2
u_ether12644  2 usb_f_ecm,usb_f_rndis
ipt_MASQUERADE  1223  1
nf_nat_masquerade_ipv4 2957  1 ipt_MASQUERADE
iptable_nat 1924  1
nf_nat_ipv4 5381  1 iptable_nat
nf_nat 17482  2 nf_nat_masquerade_ipv4,nf_nat_ipv4
xt_tcpudp   2322  8
nf_conntrack_ipv4  14210  2
nf_defrag_ipv4  1620  1 nf_conntrack_ipv4
xt_conntrack3007  1
nf_conntrack  103452  5 
nf_conntrack_ipv4,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat
iptable_filter  1929  1
arc41943  2
ath9k_htc  56999  0
snd_usb_audio 141947  0
ath9k_common   28242  1 ath9k_htc
snd_usbmidi_lib20465  1 snd_usb_audio
ath9k_hw  438363  2 ath9k_htc,ath9k_common
snd_hwdep   6292  1 snd_usb_audio
snd_rawmidi23170  1 snd_usbmidi_lib
evdev  12539  0
snd_seq_device  4852  1 snd_rawmidi
snd_pcm95325  4 
snd_soc_pcm,snd_usb_audio,snd_pcm_dmaengine,snd_soc_core
snd_timer  22629  1 snd_pcm
ath21859  3 ath9k_htc,ath9k_hw,ath9k_common
mac80211  417547  1 ath9k_htc
axp20x_pek  3651  0
dwmac_sunxi 2638  0
stmmac_platform 5932  1 dwmac_sunxi
cfg80211  254986  4 ath9k_htc,mac80211,ath,ath9k_common
stmmac 82035  3 stmmac_platform,dwmac_sunxi
rfkill 19399  3 cfg80211
sun4i_ts4456  0
sun4i_ss   16538  0
sun4i_lradc_keys3478  0
spi_sun4i   4571  0
sunxi_wdt   3769  0
uio_pdrv_genirq 3591  0
uio 9341  1 uio_pdrv_genirq
sch_fq_codel9160  8
libcomposite   44779  16 usb_f_ecm,usb_f_rndis
ip_tables  12937  2 iptable_filter,iptable_nat
x_tables   18965  5 
ip_tables,iptable_filter,xt_tcpudp,ipt_MASQUERADE,xt_conntrack




Thanks,


Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] usb boot on windows

2016-10-18 Thread Bernhard Nortmann 

Am 18.10.2016 um 03:45 schrieb Ronnel Tolentino:

Hi Bernhard,

It's working now. Thanks.

Regards,
Ronnel


Great. Thanks for your feedback!

Regards, B. Nortmann

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH] clk: sunxi-ng: sun6i-a31: Force AHB1 clock to use PLL6 as parent

2016-10-18 Thread Chen-Yu Tsai 
On Tue, Oct 18, 2016 at 3:50 PM, Jean-Francois Moine  wrote:
> On Tue, 18 Oct 2016 13:42:09 +0800
> Chen-Yu Tsai  wrote:
>
>> On the A31, the DMA engine only works if AHB1 is clocked from PLL6.
>> In addition, the hstimer is clocked from AHB1, and if AHB1 is clocked
>> from the CPU clock, and cpufreq is working, we get an unstable timer.
>>
>> Force the AHB1 clock to use PLL6 as its parent. Previously this was done
>> in the device tree with the assigned-clocks and assigned-clocks-parent
>> bindings. However with this new monolithic driver, the system critical
>> clocks aren't exported through the device tree. The alternative is to
>> force this setting in the driver before the clocks are registered.
>
> It should be simpler to export the constant (CLK_AHB1) instead of
> adding code...

I get you. But the plan is to not export system core clocks that
don't have a direct user.

ChenYu

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH] clk: sunxi-ng: sun6i-a31: Force AHB1 clock to use PLL6 as parent

2016-10-18 Thread Jean-Francois Moine 
On Tue, 18 Oct 2016 13:42:09 +0800
Chen-Yu Tsai  wrote:

> On the A31, the DMA engine only works if AHB1 is clocked from PLL6.
> In addition, the hstimer is clocked from AHB1, and if AHB1 is clocked
> from the CPU clock, and cpufreq is working, we get an unstable timer.
> 
> Force the AHB1 clock to use PLL6 as its parent. Previously this was done
> in the device tree with the assigned-clocks and assigned-clocks-parent
> bindings. However with this new monolithic driver, the system critical
> clocks aren't exported through the device tree. The alternative is to
> force this setting in the driver before the clocks are registered.

It should be simpler to export the constant (CLK_AHB1) instead of
adding code...

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.