[linux-sunxi] Re: [PATCH v2 2/2] drm: sun4i: hdmi: Add support for sun4i HDMI encoder audio
On 1/21/20 8:29 PM, Maxime Ripard wrote:
+Mark
On Mon, Jan 20, 2020 at 02:33:26PM +0200, Stefan Mavrodiev wrote:
Add HDMI audio support for the sun4i-hdmi encoder, used on
the older Allwinner chips - A10, A20, A31.
Most of the code is based on the BSP implementation. In it
dditional formats are supported (S20_3LE and S24_LE), however
there where some problems with them and only S16_LE is left.
What are those problems?
It was all noise. Guess it's some byte alignment issue, but
I didn't manage to solve it.
Signed-off-by: Stefan Mavrodiev
---
+static int sun4i_hdmi_audio_probe(struct platform_device *pdev)
+{
+ struct snd_soc_card *card = _hdmi_audio_card;
+ struct snd_soc_dai_link_component *comp;
+ struct snd_soc_dai_link *link;
+ struct device *dev = >dev;
+ struct sun4i_hdmi_audio *priv;
+ int ret;
+
+ ret = devm_snd_dmaengine_pcm_register(dev,
+ _hdmi_audio_pcm_config, 0);
+ if (ret) {
+ dev_err(dev, "Failed registering PCM DMA component\n");
+ return ret;
+ }
+
+ ret = devm_snd_soc_register_component(dev,
+ _hdmi_audio_component,
+ _hdmi_audio_dai, 1);
+ if (ret) {
+ dev_err(dev, "Failed registering DAI component\n");
+ return ret;
+ }
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->hdmi = dev->parent;
+ dev->of_node = dev->parent->of_node;
+
+ link = devm_kzalloc(dev, sizeof(*link), GFP_KERNEL);
+ if (!link)
+ return -ENOMEM;
+
+ comp = devm_kzalloc(dev, sizeof(*comp) * 3, GFP_KERNEL);
+ if (!comp)
+ return -ENOMEM;
+
+ link->cpus = [0];
+ link->codecs = [1];
+ link->platforms = [2];
+
+ link->num_cpus = 1;
+ link->num_codecs = 1;
+ link->num_platforms = 1;
+
+ link->playback_only = 1;
+
+ link->name = "SUN4I-HDMI";
+ link->stream_name = "SUN4I-HDMI PCM";
+
+ link->codecs->name = dev_name(dev);
+ link->codecs->dai_name= sun4i_hdmi_audio_dai.name;
+
+ link->cpus->dai_name = dev_name(dev);
+
+ link->platforms->name = dev_name(dev);
+
+ link->dai_fmt = SND_SOC_DAIFMT_I2S;
+
+ card->dai_link = link;
+ card->num_links = 1;
+ card->dev = dev;
+
+ snd_soc_card_set_drvdata(card, priv);
+ return devm_snd_soc_register_card(dev, card);
+}
+
+static int sun4i_hdmi_audio_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver sun4i_hdmi_audio_driver = {
+ .probe = sun4i_hdmi_audio_probe,
+ .remove = sun4i_hdmi_audio_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ },
+};
+module_platform_driver(sun4i_hdmi_audio_driver);
+
+MODULE_AUTHOR("Stefan Mavrodiev
Sorry if I wasn't clear enough in the previous mail, I didn't suggest
to do a driver, this will open another can of worm (as kbuild already
pointed out), but to create a new device, and pass that new device to
ASoC's functions.
The problem here is that I used sunxi_defconfig instead of the arch
defconfig during testing. The difference is that in "our" config the
modules are built-in and thus there is no module_init.
However I've managed to get it working in v3 (it's not submitted
yet).
I've added separate entry in the Kconfig of type bool. This is to
manage the SND_SOC dependency. The current patch will fail if
SND_SOC=m and SUN4I_HDMI=y for example.
Then I've dropped this as it's useless:
+module_platform_driver(sun4i_hdmi_audio_driver);
+
+MODULE_AUTHOR("Stefan Mavrodiev
In sun4i_hdmi_enc.c I've added __init and __exit
functions where I register/unregister the additional platform_driver.
Thus we get 2 platform drivers from one module, which is not something
uncommon.
If you like this approach I can submit v3.
I tried that, and failed, so I guess it's not an option either.
Mark, our issue here is that we have a driver tied to a device that is
an HDMI encoder. Obviously, we'll want to register into DRM, which is
what we were doing so far, with the usual case where at remove /
unbind time, in order to free the resources, we just retrieve our
pointer to our private structure using the device's drvdata.
Now, snd_soc_register_card also sets that pointer to the card we try
to register, which is problematic. It seems that it's used to handle
suspend / resume automatically, which in this case would be also not
really fit for us (or rather, we would need to do more that just
suspend the audio part).
Is there anyway we can have that kind of setup? I believe vc4 is in a
similar situation, but they worked around it by storing the data they
want to access in a global pointer, but that only works for one device
which doesn't really suit us either.
Any suggestions?
[linux-sunxi] Re: [PATCH v2 1/2] Input: axp20x-pek - Respect userspace wakeup configuration
On Wed, Jan 15, 2020 at 11:50:08AM +0100, Hans de Goede wrote:
> Hi,
>
> On 15-01-2020 06:12, Samuel Holland wrote:
> > Unlike most other power button drivers, this driver unconditionally
> > enables its wakeup IRQ. It should be using device_may_wakeup() to
> > respect the userspace configuration of wakeup sources.
> >
> > Because the AXP20x MFD device uses regmap-irq, the AXP20x PEK IRQs are
> > nested off of regmap-irq's threaded interrupt handler. The device core
> > ignores such interrupts, so to actually disable wakeup, we must
> > explicitly disable all non-wakeup interrupts during suspend.
> >
> > Signed-off-by: Samuel Holland
>
> Patch looks good to me:
>
> Reviewed-by: Hans de Goede
Applied, thank you.
>
> Regards,
>
> Hans
>
>
>
> > ---
> > drivers/input/misc/axp20x-pek.c | 37 -
> > 1 file changed, 36 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/misc/axp20x-pek.c
> > b/drivers/input/misc/axp20x-pek.c
> > index 17c1cca74498..0ace3fe3d7dc 100644
> > --- a/drivers/input/misc/axp20x-pek.c
> > +++ b/drivers/input/misc/axp20x-pek.c
> > @@ -280,7 +280,7 @@ static int axp20x_pek_probe_input_device(struct
> > axp20x_pek *axp20x_pek,
> > }
> > if (axp20x_pek->axp20x->variant == AXP288_ID)
> > - enable_irq_wake(axp20x_pek->irq_dbr);
> > + device_init_wakeup(>dev, true);
> > return 0;
> > }
> > @@ -352,6 +352,40 @@ static int axp20x_pek_probe(struct platform_device
> > *pdev)
> > return 0;
> > }
> > +static int __maybe_unused axp20x_pek_suspend(struct device *dev)
> > +{
> > + struct axp20x_pek *axp20x_pek = dev_get_drvdata(dev);
> > +
> > + /*
> > +* As nested threaded IRQs are not automatically disabled during
> > +* suspend, we must explicitly disable non-wakeup IRQs.
> > +*/
> > + if (device_may_wakeup(dev)) {
> > + enable_irq_wake(axp20x_pek->irq_dbf);
> > + enable_irq_wake(axp20x_pek->irq_dbr);
> > + } else {
> > + disable_irq(axp20x_pek->irq_dbf);
> > + disable_irq(axp20x_pek->irq_dbr);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int __maybe_unused axp20x_pek_resume(struct device *dev)
> > +{
> > + struct axp20x_pek *axp20x_pek = dev_get_drvdata(dev);
> > +
> > + if (device_may_wakeup(dev)) {
> > + disable_irq_wake(axp20x_pek->irq_dbf);
> > + disable_irq_wake(axp20x_pek->irq_dbr);
> > + } else {
> > + enable_irq(axp20x_pek->irq_dbf);
> > + enable_irq(axp20x_pek->irq_dbr);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int __maybe_unused axp20x_pek_resume_noirq(struct device *dev)
> > {
> > struct axp20x_pek *axp20x_pek = dev_get_drvdata(dev);
> > @@ -371,6 +405,7 @@ static int __maybe_unused
> > axp20x_pek_resume_noirq(struct device *dev)
> > }
> > static const struct dev_pm_ops axp20x_pek_pm_ops = {
> > + SET_SYSTEM_SLEEP_PM_OPS(axp20x_pek_suspend, axp20x_pek_resume)
> > #ifdef CONFIG_PM_SLEEP
> > .resume_noirq = axp20x_pek_resume_noirq,
> > #endif
> >
>
--
Dmitry
--
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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200122060419.GD110084%40dtor-ws.
[linux-sunxi] Re: [PATCH v2 2/2] Input: axp20x-pek - Enable wakeup for all AXP variants
On Tue, Jan 14, 2020 at 11:12:53PM -0600, Samuel Holland wrote: > There are many devices, including several mobile battery-powered > devices, using other AXP variants as their PMIC. Allow them to use > the power key as a wakeup source. > > Reviewed-by: Hans de Goede > Signed-off-by: Samuel Holland Applied, thank you. > --- > drivers/input/misc/axp20x-pek.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c > index 0ace3fe3d7dc..1872607e87c3 100644 > --- a/drivers/input/misc/axp20x-pek.c > +++ b/drivers/input/misc/axp20x-pek.c > @@ -279,8 +279,7 @@ static int axp20x_pek_probe_input_device(struct > axp20x_pek *axp20x_pek, > return error; > } > > - if (axp20x_pek->axp20x->variant == AXP288_ID) > - device_init_wakeup(>dev, true); > + device_init_wakeup(>dev, true); > > return 0; > } > -- > 2.23.0 > -- Dmitry -- 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. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200122060427.GE110084%40dtor-ws.
[linux-sunxi] Re: [PATCH 3/9] arm64: dts: allwinner: pinebook: Remove unused AXP803 regulators
On 1/21/20 3:05 AM, Maxime Ripard wrote:
> On Sun, Jan 19, 2020 at 10:30:58AM -0600, Samuel Holland wrote:
>> The Pinebook does not use the CSI bus on the A64. In fact it does not
>> use GPIO port E for anything at all. Thus the following regulators are
>> not used and do not need voltages set:
>>
>> - ALDO1: Connected to VCC-PE only
>> - DLDO3: Not connected
>> - ELDO3: Not connected
>>
>> Signed-off-by: Samuel Holland
>> ---
>> .../boot/dts/allwinner/sun50i-a64-pinebook.dts | 16 +---
>> 1 file changed, 1 insertion(+), 15 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>> index ff32ca1a495e..8e7ce6ad28dd 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>> @@ -202,9 +202,7 @@
>> };
>>
>> _aldo1 {
>> -regulator-min-microvolt = <280>;
>> -regulator-max-microvolt = <280>;
>> -regulator-name = "vcc-csi";
>> +regulator-name = "vcc-pe";
>> };
>
> If it's connected to PE, I'd expect the voltage to be at 3.3v?
If we provide voltage constraints, the regulator core will enable the regulator
and set its voltage at boot. That seems like a bit of a waste.
I don't think the voltage really matters, since nothing is plugged in to the
port. ALDO1 can't go over 3.3V anyway, so even if it does get turned on for some
reason, nothing will get damaged.
Samuel
--
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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/8006a501-733e-b998-edb3-378769cd3a4c%40sholland.org.
[linux-sunxi] Re: [PATCH 3/9] arm64: dts: allwinner: pinebook: Remove unused AXP803 regulators
On Tue, Jan 21, 2020 at 1:05 AM Maxime Ripard wrote:
>
> On Sun, Jan 19, 2020 at 10:30:58AM -0600, Samuel Holland wrote:
> > The Pinebook does not use the CSI bus on the A64. In fact it does not
> > use GPIO port E for anything at all. Thus the following regulators are
> > not used and do not need voltages set:
> >
> > - ALDO1: Connected to VCC-PE only
> > - DLDO3: Not connected
> > - ELDO3: Not connected
> >
> > Signed-off-by: Samuel Holland
> > ---
> > .../boot/dts/allwinner/sun50i-a64-pinebook.dts | 16 +---
> > 1 file changed, 1 insertion(+), 15 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > index ff32ca1a495e..8e7ce6ad28dd 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > @@ -202,9 +202,7 @@
> > };
> >
> > _aldo1 {
> > - regulator-min-microvolt = <280>;
> > - regulator-max-microvolt = <280>;
> > - regulator-name = "vcc-csi";
> > + regulator-name = "vcc-pe";
> > };
>
> If it's connected to PE, I'd expect the voltage to be at 3.3v?
Commit message says that PE is not used, so we don't need to set it at all.
> Maxime
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CA%2BE%3DqVcdza_E17_%3Dr%2B0eZ2UexCYah35jt8%3Dv%2BuFTLHx3%2BBvHSg%40mail.gmail.com.
[linux-sunxi] Re: [PATCH v2 2/2] drm: sun4i: hdmi: Add support for sun4i HDMI encoder audio
On Tue, Jan 21, 2020 at 07:29:37PM +0100, Maxime Ripard wrote: > > Mark, our issue here is that we have a driver tied to a device that is > > an HDMI encoder. Obviously, we'll want to register into DRM, which is > > what we were doing so far, with the usual case where at remove / > > unbind time, in order to free the resources, we just retrieve our > > pointer to our private structure using the device's drvdata. > > Now, snd_soc_register_card also sets that pointer to the card we try > > to register, which is problematic. It seems that it's used to handle > > suspend / resume automatically, which in this case would be also not > > really fit for us (or rather, we would need to do more that just > > suspend the audio part). There's a drvdata field in the snd_soc_card for cases like this - would that work for you? -- 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. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200121183247.GL4656%40sirena.org.uk. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH 1/2] dmaengine: sun4i: Add support for cyclic requests with dedicated DMA
On 1/21/20 10:35 AM, Vinod Koul wrote: On 15-01-20, 18:07, Maxime Ripard wrote: On Wed, Jan 15, 2020 at 06:01:37PM +0530, Vinod Koul wrote: On 10-01-20, 16:11, Stefan Mavrodiev wrote: Currently the cyclic transfers can be used only with normal DMAs. They can be used by pcm_dmaengine module, which is required for implementing sound with sun4i-hdmi encoder. This is so because the controller can accept audio only from a dedicated DMA. This patch enables them, following the existing style for the scatter/gather type transfers. I presume you want this to go with drm tree (if not let me know) so: Acked-by: Vinod Koul There's no need for it to go through DRM, it can go through your tree :) okay in that case I have applied now :), thanks Hi, Should I keep this patch in the future series or drop it? Best regards, Stefan Mavrodiev -- 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. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/54b1a38f-3903-49b7-d20b-f97824a528ba%40olimex.com.
[linux-sunxi] Re: [PATCH 1/4] sunxi: dts: R40: Update Bananapi M2 Berry .dts
On Thu, Jan 2, 2020 at 5:15 AM Andre Przywara wrote: > > Update the .dts file from the kernel, which carries much more nodes, > some of them we need to enable USB and Ethernet support for the board. > > Signed-off-by: Andre Przywara > --- Would be better to have all R40 files to sync at the same time? -- 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. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAMty3ZCJDj9sMDde6_3ninEr8KyT8zFr_UV9oW_geosHkJ2Obg%40mail.gmail.com.
[linux-sunxi] Re: [PATCH 3/6] sunxi: SPL SPI: Introduce is_new_gen_spi()
On Mon, Jan 6, 2020 at 6:59 AM Andre Przywara wrote:
>
> So far we were using the CONFIG_SUNXI_GEN_SUN6I symbol to select between
> the two SPI controller generations used on Allwinner SoCs. This is a
> convenience symbol to roughly differentiate between "older" and "newer"
> generation of SoCs.
>
> The H6 SoCs is the newest SoC so far, but is sufficiently different to
> not define this symbol. However it is using a SPI controller compatible
> to the "new gen" SoCs.
>
> To prepare for H6 support, we replace the check for this single symbol
> with an explicit function, which can later be extended.
> For now we just return CONFIG_SUNXI_GEN_SUN6I in there, so this does not
> create a functional change.
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/mach-sunxi/spl_spi_sunxi.c | 22 ++
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/spl_spi_sunxi.c
> b/arch/arm/mach-sunxi/spl_spi_sunxi.c
> index 5b4598a25b..b19f1bf4af 100644
> --- a/arch/arm/mach-sunxi/spl_spi_sunxi.c
> +++ b/arch/arm/mach-sunxi/spl_spi_sunxi.c
> @@ -100,9 +100,14 @@ static void spi0_pinmux_setup(unsigned int pin_function)
> sunxi_gpio_set_cfgpin(SUNXI_GPC(3), pin_function);
> }
>
> +static bool is_new_gen_spi(void)
> +{
> + return IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I);
> +}
Doesn't it confusing? new gen is H6, but it returns 6I?
--
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.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAMty3ZAfZrA9-SV16hU7_eEBG83do2SHiJVd7UdA9ROfrH2wOA%40mail.gmail.com.
