Re: [linux-sunxi] Kernel CEC driver.
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 >> mailto:maxime.rip...@free-electrons.com>> >> 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?
> > 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. &codec { 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?
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.
Hi, On 17-10-16 23:33, Jarosław Nieć wrote: Hi Maxime, On Mon, Oct 17, 2016 at 9:51 PM, Maxime Ripard mailto:maxime.rip...@free-electrons.com>> 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?
> > 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.
Re: [linux-sunxi] A20, Mainline kernel: how to get sound on headphone output?
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 BR, CK On 18 October 2016 at 11:48, Thomas Gahr wrote: > 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. -- 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?
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
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
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
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.