Re: [linux-sunxi] KMS - VE - Lima
On Tue, 22 Sep 2015 11:09:23 +0200 Andreas Baierl wrote: > I recognized, that there has already been done some basic (and more > or less complete) work on each of that tasks by different developers. > I won't list the names, involved people know them, and something > is/was listed in our wiki, too. > In summary the basic question is, if these developers intend to > finish their work at sometime or plan to share their efforts. If not, > what are the reasons, why this seems to be "paused". Personal mood, > Allwinner, payment, time? Is there anything that can be done by the > community to help? Well, where should this start? Is oblivious that the problem is not technical. You and others already know some of this story, but this is a very delicate matter that without the complete picture of the events, some of the new people that just joined (sunxi) will think as bizarre some of the behavior and decisions taken. To not get (again) be "accused" of not working "hard" enough, there must be caution in how to describe this situation. To do so, some context is need and if not clear enough, please make questions. Sorry to repeat all the same things, that we all would prefer not to get involved in (if we had the choice). My version of events, in the video engine context only. (correction welcome if any thing is not the right truth) - somehow, allwinner publish the A10 kernel/bootloader source code, that triggers the formation of the linux-sunxi community, as that was so uncommon for a Chinese arm soc vendor. - lot of interest around the allwinner socs, including some developers of a popular media player, that with allwinner cooperation worked to add hardware decoding support. But. After some time, those same developers unsatisfied by the level of cooperation given by allwinner, ceased all the work. This was the event that made the allwinner-proprietary-driver-library have bad reputation, equal to a piece of manure. (which is not full deserved, is true that proprietary-driver-library had/has some problems, but other than that, it works.)(only is need some willing to spend the time to make it work.) - people started to think about reverse-engineering. as is what happens when there is hardware that one what to use, but the software side is "limiting" said use. But unfortunately, this first try didn't achieve the momentum need. - some months later, the wish to reverse-engineering reemerged again, this time with more people (which i am one of them) - after some weeks (around a month or so), came to light the existence of multiple license violations in the proprietary-driver-libraries, (multiple, because wasn't only a L(GPL) violation) - but, as we all were so happy and hopeful of allwinner that appeared to be following and doing the right thing. Together with the finding that the video engine hardware was easy to reserse-engineering. We just chosen to not go bother allwinner about this, and ignore the license violations. Looking back, i am now of opinion that this was a huge mistake. - a year passed, and with the new A80 soc, massive license violations emerged, together with an difficulty to communicate with allwinner, and its close board vendor (cubieboard) - at this point the discussions (mainly in the irc) of this situation, referred to again this video-engine proprietary-driver-library license violations At this point i believe that allwinner was contacted about the existence of this license violations, and was given (to allwinner) a solution in which all sides ended as all winner, a solution that if allwinner had chosen to accept would not required that this license violations be made public. This happened to my best knowledge around july/june of 2014, as i was not involved in this dialog, dont know its date. At this point, we all know what happened, and is not need specific in detail. Allwinner did not choose to collaborate with the linux-sunxi community, instead allwinner came into this community expecting that we, this open-source community accept a proprietary-driver-library with such unacceptable license violations. At the face of this, we can not stay silence. But you may ask, why is important that this license violations in the proprietary-driver-library be resolved, if we prefer to reverse-engineering and to work to write a fully 100% open-source-driver. The unwillingness of allwinner to resolve or to dialogue with the community to find a solution, creates uncertain about the future. Will allwinner respect the license of this new driver written by this community? This is a question that i personally would like to be answered. As i am well aware that media-playback bring certain business strategies in which an open-source driver is unwanted. I refuse to be *alone* in the writing of any driver, because i don't want to be *alone* in the likelihood of having to remember that license vi
Re: [linux-sunxi][alsa-devel][PATCH 3/3] ASOC: sunxi: Add support for the spdif block
On 28 September 2015 at 10:25, Maxime Ripard
wrote:
> On Thu, Sep 24, 2015 at 04:30:05PM +0200, codekip...@gmail.com wrote:
>> From: Marcus Cooper
>>
>> The sun4i, sun6i and sun7i SoC families have an SPDIF
>> block which is capable of playback and capture.
>>
>> This patch enables the playback of this block for
>> the sun4i and sun7i families.
>>
>> Signed-off-by: Marcus Cooper
>> ---
>> sound/soc/sunxi/Kconfig | 10 +
>> sound/soc/sunxi/Makefile | 4 +
>> sound/soc/sunxi/sunxi-machine-spdif.c | 110 +
>> sound/soc/sunxi/sunxi-spdif.c | 801
>> ++
>> 4 files changed, 925 insertions(+)
>> create mode 100644 sound/soc/sunxi/sunxi-machine-spdif.c
>> create mode 100644 sound/soc/sunxi/sunxi-spdif.c
>>
>> diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
>> index 84c72ec..053db02 100644
>> --- a/sound/soc/sunxi/Kconfig
>> +++ b/sound/soc/sunxi/Kconfig
>> @@ -8,4 +8,14 @@ config SND_SUN4I_CODEC
>> Select Y or M to add support for the Codec embedded in the Allwinner
>> A10 and affiliated SoCs.
>>
>> +config SND_SOC_SUNXI_DAI_SPDIF
>> +tristate
>> +select SND_SOC_GENERIC_DMAENGINE_PCM
>> +select REGMAP_MMIO
>> +
>> +config SND_SOC_SUNXI_MACHINE_SPDIF
>> +tristate "APB on-chip sun4i/sun5i/sun7i SPDIF"
>> +select SND_SOC_SUNXI_DAI_SPDIF
>> +help
>> + Say Y if you want to add support for SoC S/PDIF audio as simple
>> audio card.
>> endmenu
>> diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
>> index ea8a08c..7849a75 100644
>> --- a/sound/soc/sunxi/Makefile
>> +++ b/sound/soc/sunxi/Makefile
>> @@ -1,2 +1,6 @@
>> obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
>>
>> +snd-soc-sunxi-dai-spdif-objs := sunxi-spdif.o
>> +obj-$(CONFIG_SND_SOC_SUNXI_DAI_SPDIF) += snd-soc-sunxi-dai-spdif.o
>> +snd-soc-sunxi-machine-spdif-objs := sunxi-machine-spdif.o
>> +obj-$(CONFIG_SND_SOC_SUNXI_MACHINE_SPDIF) += snd-soc-sunxi-machine-spdif.o
>> diff --git a/sound/soc/sunxi/sunxi-machine-spdif.c
>> b/sound/soc/sunxi/sunxi-machine-spdif.c
>> new file mode 100644
>> index 000..f8f6bd8
>> --- /dev/null
>> +++ b/sound/soc/sunxi/sunxi-machine-spdif.c
>> @@ -0,0 +1,110 @@
>> +/*
>> + * Copyright (C) 2015 Andrea Venturi
>> + * From code by (C) 2013 Freescale Semiconductor, Inc.
>> + * (sound/soc/fsl/imx-spdif.c)
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +struct sunxi_machine_spdif_data {
>> + struct snd_soc_dai_link dai;
>> + struct snd_soc_card card;
>> +};
>> +
>> +static int sunxi_machine_spdif_audio_probe(struct platform_device *pdev)
>> +{
>> + struct device_node *spdif_np, *np = pdev->dev.of_node;
>> + struct sunxi_machine_spdif_data *data;
>> + int ret = 0;
>> +
>> + dev_dbg(&pdev->dev, "%s: Looking for spdif-controller\n", __func__);
>> + spdif_np = of_parse_phandle(np, "spdif-controller", 0);
>> + if (!spdif_np) {
>> + dev_err(&pdev->dev, "failed to find spdif-controller\n");
>> + ret = -EINVAL;
>> + goto end;
>> + }
>> +
>> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
>> + if (!data) {
>> + ret = -ENOMEM;
>> + goto end;
>> + }
>> +
>> + data->dai.name = "S/PDIF PCM";
>> + data->dai.stream_name = "S/PDIF PCM";
>> + data->dai.codec_dai_name = "snd-soc-dummy-dai";
>> + data->dai.codec_name = "snd-soc-dummy";
>> + data->dai.cpu_of_node = spdif_np;
>> + data->dai.platform_of_node = spdif_np;
>> + data->dai.playback_only = true;
>> + data->dai.capture_only = true;
>> +
>> + if (of_property_read_bool(np, "spdif-out"))
>> + data->dai.capture_only = false;
>> +
>> + if (of_property_read_bool(np, "spdif-in"))
>> + data->dai.playback_only = false;
>> +
>> + if (data->dai.playback_only && data->dai.capture_only) {
>> + dev_err(&pdev->dev, "no enabled S/PDIF DAI link\n");
>> + goto end;
>> + }
>> +
>> + data->card.dev = &pdev->dev;
>> + data->card.dai_link = &data->dai;
>> + data->card.num_links = 1;
>> + data->card.owner = THIS_MODULE;
>> +
>> + ret = snd_soc_of_parse_card_name(&data->card, "model");
>> + if (ret)
>> + goto end;
>> +
>> + ret = devm_snd_soc_register_card(&pdev->dev, &data->card);
>> + if (ret) {
>> + dev_err(&pdev->dev,
[linux-sunxi] Re: [PATCH 2/3] ARM: dts: sun8i: Add sun8i-a33-q8-tablet.dts file
On Thu, Sep 24, 2015 at 05:23:53PM +0200, Hans de Goede wrote: > This is a generic dts file for A33 based q8 formfactor tablets, > this is intended to replace both sun8i-a33-ippo-q8h-v1.2.dts and > sun8i-a33-et-q8-v1.6.dts (these can be fully dropped after a > transition period). > > Signed-off-by: Hans de Goede Applied, together with patch 3. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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. signature.asc Description: Digital signature
Re: [linux-sunxi] All winner A13 pin mapping
Hello, Please find the user manual at below link, refer page no. 322 https://github.com/allwinner-zh/documents/blob/master/A13/A13_User_Manual_v1.5_20150510.pdf Regards, Vishnu On Mon, Sep 28, 2015 at 10:24 AM, wrote: > Hi guys, > > I am looking into http://linux-sunxi.org/images/e/eb/A13_Datasheet.pdf to > understand what each pin on the IC is connected to. However I observe that > the pin description is not complete. I still dont understand the role of each > pin. Is there any other datasheet which explain this in more detail? > > -- > 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][alsa-devel][PATCH 3/3] ASOC: sunxi: Add support for the spdif block
On Thu, Sep 24, 2015 at 04:30:05PM +0200, codekip...@gmail.com wrote:
> From: Marcus Cooper
>
> The sun4i, sun6i and sun7i SoC families have an SPDIF
> block which is capable of playback and capture.
>
> This patch enables the playback of this block for
> the sun4i and sun7i families.
>
> Signed-off-by: Marcus Cooper
> ---
> sound/soc/sunxi/Kconfig | 10 +
> sound/soc/sunxi/Makefile | 4 +
> sound/soc/sunxi/sunxi-machine-spdif.c | 110 +
> sound/soc/sunxi/sunxi-spdif.c | 801
> ++
> 4 files changed, 925 insertions(+)
> create mode 100644 sound/soc/sunxi/sunxi-machine-spdif.c
> create mode 100644 sound/soc/sunxi/sunxi-spdif.c
>
> diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
> index 84c72ec..053db02 100644
> --- a/sound/soc/sunxi/Kconfig
> +++ b/sound/soc/sunxi/Kconfig
> @@ -8,4 +8,14 @@ config SND_SUN4I_CODEC
> Select Y or M to add support for the Codec embedded in the Allwinner
> A10 and affiliated SoCs.
>
> +config SND_SOC_SUNXI_DAI_SPDIF
> +tristate
> +select SND_SOC_GENERIC_DMAENGINE_PCM
> +select REGMAP_MMIO
> +
> +config SND_SOC_SUNXI_MACHINE_SPDIF
> +tristate "APB on-chip sun4i/sun5i/sun7i SPDIF"
> +select SND_SOC_SUNXI_DAI_SPDIF
> +help
> + Say Y if you want to add support for SoC S/PDIF audio as simple
> audio card.
> endmenu
> diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
> index ea8a08c..7849a75 100644
> --- a/sound/soc/sunxi/Makefile
> +++ b/sound/soc/sunxi/Makefile
> @@ -1,2 +1,6 @@
> obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
>
> +snd-soc-sunxi-dai-spdif-objs := sunxi-spdif.o
> +obj-$(CONFIG_SND_SOC_SUNXI_DAI_SPDIF) += snd-soc-sunxi-dai-spdif.o
> +snd-soc-sunxi-machine-spdif-objs := sunxi-machine-spdif.o
> +obj-$(CONFIG_SND_SOC_SUNXI_MACHINE_SPDIF) += snd-soc-sunxi-machine-spdif.o
> diff --git a/sound/soc/sunxi/sunxi-machine-spdif.c
> b/sound/soc/sunxi/sunxi-machine-spdif.c
> new file mode 100644
> index 000..f8f6bd8
> --- /dev/null
> +++ b/sound/soc/sunxi/sunxi-machine-spdif.c
> @@ -0,0 +1,110 @@
> +/*
> + * Copyright (C) 2015 Andrea Venturi
> + * From code by (C) 2013 Freescale Semiconductor, Inc.
> + * (sound/soc/fsl/imx-spdif.c)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +
> +struct sunxi_machine_spdif_data {
> + struct snd_soc_dai_link dai;
> + struct snd_soc_card card;
> +};
> +
> +static int sunxi_machine_spdif_audio_probe(struct platform_device *pdev)
> +{
> + struct device_node *spdif_np, *np = pdev->dev.of_node;
> + struct sunxi_machine_spdif_data *data;
> + int ret = 0;
> +
> + dev_dbg(&pdev->dev, "%s: Looking for spdif-controller\n", __func__);
> + spdif_np = of_parse_phandle(np, "spdif-controller", 0);
> + if (!spdif_np) {
> + dev_err(&pdev->dev, "failed to find spdif-controller\n");
> + ret = -EINVAL;
> + goto end;
> + }
> +
> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data) {
> + ret = -ENOMEM;
> + goto end;
> + }
> +
> + data->dai.name = "S/PDIF PCM";
> + data->dai.stream_name = "S/PDIF PCM";
> + data->dai.codec_dai_name = "snd-soc-dummy-dai";
> + data->dai.codec_name = "snd-soc-dummy";
> + data->dai.cpu_of_node = spdif_np;
> + data->dai.platform_of_node = spdif_np;
> + data->dai.playback_only = true;
> + data->dai.capture_only = true;
> +
> + if (of_property_read_bool(np, "spdif-out"))
> + data->dai.capture_only = false;
> +
> + if (of_property_read_bool(np, "spdif-in"))
> + data->dai.playback_only = false;
> +
> + if (data->dai.playback_only && data->dai.capture_only) {
> + dev_err(&pdev->dev, "no enabled S/PDIF DAI link\n");
> + goto end;
> + }
> +
> + data->card.dev = &pdev->dev;
> + data->card.dai_link = &data->dai;
> + data->card.num_links = 1;
> + data->card.owner = THIS_MODULE;
> +
> + ret = snd_soc_of_parse_card_name(&data->card, "model");
> + if (ret)
> + goto end;
> +
> + ret = devm_snd_soc_register_card(&pdev->dev, &data->card);
> + if (ret) {
> + dev_err(&pdev->dev, "snd_soc_register_card failed: %d\n", ret);
> + goto end;
> + }
> +
> + platform_set_drvdata(pdev, data);
> +
> +end:
> + of_node_put(spdif_np);
> +
> +
[linux-sunxi] All winner A13 pin mapping
Hi guys, I am looking into http://linux-sunxi.org/images/e/eb/A13_Datasheet.pdf to understand what each pin on the IC is connected to. However I observe that the pin description is not complete. I still dont understand the role of each pin. Is there any other datasheet which explain this in more detail? -- 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] [PATCH 0/2] ASoC: Add support for the Allwinner A10 codec
Hi Priit, On Tue, Sep 22, 2015 at 04:26:57PM +0300, Priit Laes wrote: > On Sat, 2015-09-12 at 15:26 +0200, Maxime Ripard wrote: > > Hi everyone, > > > > This patch set adds the support for what Allwinner calls the codec on > > their SoCs. > > > > This codec is actually a combination of a codec and DAI, tied > > together > > in a single memory-mapped IP. It is completely standalone, and > > outputs > > directly the analog signal. > > > > While it supports both playback and capture, the capture is not > > implemented in this patch, and will be posted eventually as a > > separate > > one. > > > > This set, in order to be functional, has a dependency on the audio > > clocks patch set posted separately. However, it doesn't needs this to > > compile properly, so I guess it can be merged without really caring > > for the merging status of the clock patches. > > It works on Gemei G9 tablet which has also extra chip that > automatically switches output over from internal speakers to headphones > when connector is inserted. > > Now I noticed some weird things: > > When I have all the switches as ON in alsamixer, and I start disabling > them, I get following weird results. > > Left Mixer Left - LML > Right Mixer Left - LMR > Right Mixer Right - RMR > > Very faint output: > LML - ON > RML - Mute > RMR - ON > > Output works fully: > LML - Mute > RML - Mute > RMR - Mute > > When I Mute Pre-Amplifier and fiddle any of LML, RML or RMR, the output > stays mute even after setting Pre-Amplifier Mute back on: > > 1. All switches on > 2. Mute pre-amplifier > 3. Mute RMR > 4. Pre-Amilifier Mute Off > .. Music stays off > 5. Toggle Pre-Amplifier twice - output turns on Unfortunately, I don't have access to that SoC or that setup. Do you have another A10 board with a simpler audio setup, like a cubieboard? > And also following in dmesg: > sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok > sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack > sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Left -> direct -> > Headphone Jack > sun4i-codec 1c22c00.codec: ASoC: no sink widget found for Headphone Jack > sun4i-codec 1c22c00.codec: ASoC: Failed to add route HP Right -> direct -> > Headphone Jack That one is weird, I'll look into this. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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. signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH] musb: sunxi: Ignore VBus errors in host-only mode
Hi,
On 27-09-15 16:58, Stefan Monnier wrote:
&usbphy {
/* Unset otg detect pins as we force dr_mode */
/delete-property/ usb0_id_det-gpio;
/delete-property/ usb0_vbus_det-gpio;
};
Side question [ wearing my "contributor to Emacs's dts-mode" hat ]:
How should this piece of syntax be parsed? Is
// blabla;
a general syntax accepted in DTS files, with various possible
in there? Could someone point me to some documentation
explaining/describing this syntax?
It is probably best to start a new thread about this on
,
that way people who may actually know the answer will see the mail :)
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] cpufreq scaling broken on cubietruck
Hi, On 27-09-15 22:14, Clive Messer wrote: On Sunday, 27 September 2015 13:37:01 UTC+1, Clive Messer wrote: On Sun, 2015-09-27 at 12:37 +0200, Hans de Goede wrote: This is likely a problem with your kernel config, make sure that you've the axp209 mfd and regulator drivers enabled and loaded. Thanks, Hans. I really should have figured that out on my own! Do you think it's worth asking PeterR if he will change the default Fedora armv7 config to CONFIG_REGULATOR_AXP20X=y rather than the current CONFIG_REGULATOR_AXP20X=m? (I suspect that request might carry more weight if it comes from you rather than me. ;) Hans, Do you have an opinion, (or anyone else for that matter), on what would be the upstream preferred way of getting the axp20x regulator driver to auto-load, from a DT reference, assuming it is built as a module? Something like the attached patch? (Not tested, just thinking out loud.) This is already fixed by this patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/regulator/axp20x-regulator.c?id=d4ea7d86457a8d0ea40ce77bdeda1fc966cc35ec 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] cpufreq scaling broken on cubietruck
Hi, On 27-09-15 14:36, Clive Messer wrote: On Sun, 2015-09-27 at 12:37 +0200, Hans de Goede wrote: This is likely a problem with your kernel config, make sure that you've the axp209 mfd and regulator drivers enabled and loaded. Thanks, Hans. I really should have figured that out on my own! Do you think it's worth asking PeterR if he will change the default Fedora armv7 config to CONFIG_REGULATOR_AXP20X=y rather than the current CONFIG_REGULATOR_AXP20X=m? Peter tries to keep the Fedora ARM kernel config as modular as possible because of the wide variety of hardware it runs on + low amount of memory on some hardware. So this will have to be kept modular (I know this because I already asked :) ). 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.
