Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On 9/17/2015 03:42, Mark Brown wrote: On Tue, Sep 15, 2015 at 11:11:53AM +0800, Wu, Songjun wrote: I try to use one entry, but there is a problem. It's about 'driver_data' in struct device. In function snd_soc_register_card, the parameter 'card' will be set to 'driver_data' by the code 'dev_set_drvdata(card->dev, card)'. Then some resources(eg. regmap, clock) also need be recorded by 'driver_data'. One entry could only has one 'driver_data'. I think the best way is to create two entries, like the current dts. What's your opinion? Look at the recently applied sunxi driver for an example of how to do this - it's a similar piece of hardware (entirely in the SoC and so on). Thank you, It really helps me. I will make a second version soon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On Tue, Sep 15, 2015 at 11:11:53AM +0800, Wu, Songjun wrote: > I try to use one entry, but there is a problem. > It's about 'driver_data' in struct device. > In function snd_soc_register_card, the parameter 'card' will be set to > 'driver_data' by the code 'dev_set_drvdata(card->dev, card)'. > Then some resources(eg. regmap, clock) also need be recorded by > 'driver_data'. One entry could only has one 'driver_data'. I think the best > way is to create two entries, like the current dts. > What's your opinion? Look at the recently applied sunxi driver for an example of how to do this - it's a similar piece of hardware (entirely in the SoC and so on). signature.asc Description: Digital signature
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On 9/17/2015 03:42, Mark Brown wrote: On Tue, Sep 15, 2015 at 11:11:53AM +0800, Wu, Songjun wrote: I try to use one entry, but there is a problem. It's about 'driver_data' in struct device. In function snd_soc_register_card, the parameter 'card' will be set to 'driver_data' by the code 'dev_set_drvdata(card->dev, card)'. Then some resources(eg. regmap, clock) also need be recorded by 'driver_data'. One entry could only has one 'driver_data'. I think the best way is to create two entries, like the current dts. What's your opinion? Look at the recently applied sunxi driver for an example of how to do this - it's a similar piece of hardware (entirely in the SoC and so on). Thank you, It really helps me. I will make a second version soon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On Tue, Sep 15, 2015 at 11:11:53AM +0800, Wu, Songjun wrote: > I try to use one entry, but there is a problem. > It's about 'driver_data' in struct device. > In function snd_soc_register_card, the parameter 'card' will be set to > 'driver_data' by the code 'dev_set_drvdata(card->dev, card)'. > Then some resources(eg. regmap, clock) also need be recorded by > 'driver_data'. One entry could only has one 'driver_data'. I think the best > way is to create two entries, like the current dts. > What's your opinion? Look at the recently applied sunxi driver for an example of how to do this - it's a similar piece of hardware (entirely in the SoC and so on). signature.asc Description: Digital signature
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On 9/8/2015 20:23, Mark Brown wrote: On Tue, Sep 08, 2015 at 05:36:13PM +0800, Wu, Songjun wrote: On 9/8/2015 00:25, Mark Brown wrote: Sure, there's no problem at all having that structure in software but it should be possible to do this without having to represent this structure in DT. It should be possible to register the card at the same time as the rest of the components rather than needing the separate device in the DT. Do you mean using a single entry in the DT for the whole classD system and instantiate ASoC components from it. For now, there are two entry, they could be combined to one entry. Yes, exactly. I try to use one entry, but there is a problem. It's about 'driver_data' in struct device. In function snd_soc_register_card, the parameter 'card' will be set to 'driver_data' by the code 'dev_set_drvdata(card->dev, card)'. Then some resources(eg. regmap, clock) also need be recorded by 'driver_data'. One entry could only has one 'driver_data'. I think the best way is to create two entries, like the current dts. What's your opinion? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On 9/8/2015 20:23, Mark Brown wrote: On Tue, Sep 08, 2015 at 05:36:13PM +0800, Wu, Songjun wrote: On 9/8/2015 00:25, Mark Brown wrote: Sure, there's no problem at all having that structure in software but it should be possible to do this without having to represent this structure in DT. It should be possible to register the card at the same time as the rest of the components rather than needing the separate device in the DT. Do you mean using a single entry in the DT for the whole classD system and instantiate ASoC components from it. For now, there are two entry, they could be combined to one entry. Yes, exactly. I try to use one entry, but there is a problem. It's about 'driver_data' in struct device. In function snd_soc_register_card, the parameter 'card' will be set to 'driver_data' by the code 'dev_set_drvdata(card->dev, card)'. Then some resources(eg. regmap, clock) also need be recorded by 'driver_data'. One entry could only has one 'driver_data'. I think the best way is to create two entries, like the current dts. What's your opinion? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On 9/8/2015 20:23, Mark Brown wrote: On Tue, Sep 08, 2015 at 05:36:13PM +0800, Wu, Songjun wrote: On 9/8/2015 00:25, Mark Brown wrote: Sure, there's no problem at all having that structure in software but it should be possible to do this without having to represent this structure in DT. It should be possible to register the card at the same time as the rest of the components rather than needing the separate device in the DT. Do you mean using a single entry in the DT for the whole classD system and instantiate ASoC components from it. For now, there are two entry, they could be combined to one entry. Yes, exactly. Accept. the two entries will be combined to one entry. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On Tue, Sep 08, 2015 at 05:36:13PM +0800, Wu, Songjun wrote: > On 9/8/2015 00:25, Mark Brown wrote: > >Sure, there's no problem at all having that structure in software but it > >should be possible to do this without having to represent this structure > >in DT. It should be possible to register the card at the same time as > >the rest of the components rather than needing the separate device in > >the DT. > Do you mean using a single entry in the DT for the whole classD system and > instantiate ASoC components from it. > For now, there are two entry, they could be combined to one entry. Yes, exactly. signature.asc Description: Digital signature
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On 9/8/2015 00:25, Mark Brown wrote: On Sun, Sep 06, 2015 at 05:44:30PM +0800, Wu, Songjun wrote: On 9/3/2015 19:43, Mark Brown wrote: Why is this a separate DT node? It seems that this IP is entirely self contained so I'm not clear why we need a separate node for the card, the card is usually a separate node because it ties together multiple different devices in the system but that's not the case here. The classD can finish the audio function without other devices. But I want to reuse the code in ASoC, leave many things(like creating PCM, DMA operations) to ASoC, then the driver can only focus on how to configure classD. The classD IP is divided to tree parts logically, platform, CPU dai, and codec, and these parts are registered to ASoC. This separate DT node is needed in ASoC, ties these tree parts in ClassD. Sure, there's no problem at all having that structure in software but it should be possible to do this without having to represent this structure in DT. It should be possible to register the card at the same time as the rest of the components rather than needing the separate device in the DT. Do you mean using a single entry in the DT for the whole classD system and instantiate ASoC components from it. For now, there are two entry, they could be combined to one entry. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On 9/8/2015 00:25, Mark Brown wrote: On Sun, Sep 06, 2015 at 05:44:30PM +0800, Wu, Songjun wrote: On 9/3/2015 19:43, Mark Brown wrote: Why is this a separate DT node? It seems that this IP is entirely self contained so I'm not clear why we need a separate node for the card, the card is usually a separate node because it ties together multiple different devices in the system but that's not the case here. The classD can finish the audio function without other devices. But I want to reuse the code in ASoC, leave many things(like creating PCM, DMA operations) to ASoC, then the driver can only focus on how to configure classD. The classD IP is divided to tree parts logically, platform, CPU dai, and codec, and these parts are registered to ASoC. This separate DT node is needed in ASoC, ties these tree parts in ClassD. Sure, there's no problem at all having that structure in software but it should be possible to do this without having to represent this structure in DT. It should be possible to register the card at the same time as the rest of the components rather than needing the separate device in the DT. Do you mean using a single entry in the DT for the whole classD system and instantiate ASoC components from it. For now, there are two entry, they could be combined to one entry. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On Tue, Sep 08, 2015 at 05:36:13PM +0800, Wu, Songjun wrote: > On 9/8/2015 00:25, Mark Brown wrote: > >Sure, there's no problem at all having that structure in software but it > >should be possible to do this without having to represent this structure > >in DT. It should be possible to register the card at the same time as > >the rest of the components rather than needing the separate device in > >the DT. > Do you mean using a single entry in the DT for the whole classD system and > instantiate ASoC components from it. > For now, there are two entry, they could be combined to one entry. Yes, exactly. signature.asc Description: Digital signature
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On 9/8/2015 20:23, Mark Brown wrote: On Tue, Sep 08, 2015 at 05:36:13PM +0800, Wu, Songjun wrote: On 9/8/2015 00:25, Mark Brown wrote: Sure, there's no problem at all having that structure in software but it should be possible to do this without having to represent this structure in DT. It should be possible to register the card at the same time as the rest of the components rather than needing the separate device in the DT. Do you mean using a single entry in the DT for the whole classD system and instantiate ASoC components from it. For now, there are two entry, they could be combined to one entry. Yes, exactly. Accept. the two entries will be combined to one entry. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On Sun, Sep 06, 2015 at 05:44:30PM +0800, Wu, Songjun wrote: > On 9/3/2015 19:43, Mark Brown wrote: > >Why is this a separate DT node? It seems that this IP is entirely self > >contained so I'm not clear why we need a separate node for the card, the > >card is usually a separate node because it ties together multiple > >different devices in the system but that's not the case here. > The classD can finish the audio function without other devices. > But I want to reuse the code in ASoC, leave many things(like creating PCM, > DMA operations) to ASoC, then the driver can only focus on how to configure > classD. > The classD IP is divided to tree parts logically, platform, CPU dai, > and codec, and these parts are registered to ASoC. > This separate DT node is needed in ASoC, ties these tree parts in ClassD. Sure, there's no problem at all having that structure in software but it should be possible to do this without having to represent this structure in DT. It should be possible to register the card at the same time as the rest of the components rather than needing the separate device in the DT. signature.asc Description: Digital signature
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On Sun, Sep 06, 2015 at 05:44:30PM +0800, Wu, Songjun wrote: > On 9/3/2015 19:43, Mark Brown wrote: > >Why is this a separate DT node? It seems that this IP is entirely self > >contained so I'm not clear why we need a separate node for the card, the > >card is usually a separate node because it ties together multiple > >different devices in the system but that's not the case here. > The classD can finish the audio function without other devices. > But I want to reuse the code in ASoC, leave many things(like creating PCM, > DMA operations) to ASoC, then the driver can only focus on how to configure > classD. > The classD IP is divided to tree parts logically, platform, CPU dai, > and codec, and these parts are registered to ASoC. > This separate DT node is needed in ASoC, ties these tree parts in ClassD. Sure, there's no problem at all having that structure in software but it should be possible to do this without having to represent this structure in DT. It should be possible to register the card at the same time as the rest of the components rather than needing the separate device in the DT. signature.asc Description: Digital signature
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On 9/3/2015 19:43, Mark Brown wrote:
On Tue, Sep 01, 2015 at 01:41:41PM +0800, Songjun Wu wrote:
+classd: classd@fc048000 {
+ compatible = "atmel,sama5d2-classd";
+ reg = <0xfc048000 0x100>;
+ interrupts = <59 IRQ_TYPE_LEVEL_HIGH 7>;
+ dmas = <
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
+ | AT91_XDMAC_DT_PERID(47))>;
+ dma-names = "tx";
+ clocks = <_clk>, <_gclk>, <_pll_pmc>;
+ clock-names = "pclk", "gclk", "aclk";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_classd_default>;
+ atmel,pwm-type = "diff";
+ atmel,non-overlap-time = <10>;
+};
+Example:
+sound {
+ compatible = "atmel,asoc-classd";
+
+ atmel,model = "classd @ SAMA5D2-Xplained";
+ atmel,audio-platform = <>;
+ atmel,audio-cpu-dai-name = "fc048000.classd";
+ atmel,audio-codec = <>;
+};
Why is this a separate DT node? It seems that this IP is entirely self
contained so I'm not clear why we need a separate node for the card, the
card is usually a separate node because it ties together multiple
different devices in the system but that's not the case here.
The classD can finish the audio function without other devices.
But I want to reuse the code in ASoC, leave many things(like creating
PCM, DMA operations) to ASoC, then the driver can only focus on how to
configure classD.
The classD IP is divided to tree parts logically, platform, CPU dai,
and codec, and these parts are registered to ASoC.
This separate DT node is needed in ASoC, ties these tree parts in ClassD.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On 9/3/2015 19:43, Mark Brown wrote:
On Tue, Sep 01, 2015 at 01:41:41PM +0800, Songjun Wu wrote:
+classd: classd@fc048000 {
+ compatible = "atmel,sama5d2-classd";
+ reg = <0xfc048000 0x100>;
+ interrupts = <59 IRQ_TYPE_LEVEL_HIGH 7>;
+ dmas = <
+ (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
+ | AT91_XDMAC_DT_PERID(47))>;
+ dma-names = "tx";
+ clocks = <_clk>, <_gclk>, <_pll_pmc>;
+ clock-names = "pclk", "gclk", "aclk";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_classd_default>;
+ atmel,pwm-type = "diff";
+ atmel,non-overlap-time = <10>;
+};
+Example:
+sound {
+ compatible = "atmel,asoc-classd";
+
+ atmel,model = "classd @ SAMA5D2-Xplained";
+ atmel,audio-platform = <>;
+ atmel,audio-cpu-dai-name = "fc048000.classd";
+ atmel,audio-codec = <>;
+};
Why is this a separate DT node? It seems that this IP is entirely self
contained so I'm not clear why we need a separate node for the card, the
card is usually a separate node because it ties together multiple
different devices in the system but that's not the case here.
The classD can finish the audio function without other devices.
But I want to reuse the code in ASoC, leave many things(like creating
PCM, DMA operations) to ASoC, then the driver can only focus on how to
configure classD.
The classD IP is divided to tree parts logically, platform, CPU dai,
and codec, and these parts are registered to ASoC.
This separate DT node is needed in ASoC, ties these tree parts in ClassD.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On Tue, Sep 01, 2015 at 01:41:41PM +0800, Songjun Wu wrote:
> +classd: classd@fc048000 {
> + compatible = "atmel,sama5d2-classd";
> + reg = <0xfc048000 0x100>;
> + interrupts = <59 IRQ_TYPE_LEVEL_HIGH 7>;
> + dmas = <
> + (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
> + | AT91_XDMAC_DT_PERID(47))>;
> + dma-names = "tx";
> + clocks = <_clk>, <_gclk>, <_pll_pmc>;
> + clock-names = "pclk", "gclk", "aclk";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_classd_default>;
> + atmel,pwm-type = "diff";
> + atmel,non-overlap-time = <10>;
> +};
> +Example:
> +sound {
> + compatible = "atmel,asoc-classd";
> +
> + atmel,model = "classd @ SAMA5D2-Xplained";
> + atmel,audio-platform = <>;
> + atmel,audio-cpu-dai-name = "fc048000.classd";
> + atmel,audio-codec = <>;
> +};
Why is this a separate DT node? It seems that this IP is entirely self
contained so I'm not clear why we need a separate node for the card, the
card is usually a separate node because it ties together multiple
different devices in the system but that's not the case here.
signature.asc
Description: Digital signature
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On Tue, Sep 01, 2015 at 01:41:41PM +0800, Songjun Wu wrote:
> +classd: classd@fc048000 {
> + compatible = "atmel,sama5d2-classd";
> + reg = <0xfc048000 0x100>;
> + interrupts = <59 IRQ_TYPE_LEVEL_HIGH 7>;
> + dmas = <
> + (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
> + | AT91_XDMAC_DT_PERID(47))>;
> + dma-names = "tx";
> + clocks = <_clk>, <_gclk>, <_pll_pmc>;
> + clock-names = "pclk", "gclk", "aclk";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_classd_default>;
> + atmel,pwm-type = "diff";
> + atmel,non-overlap-time = <10>;
> +};
> +Example:
> +sound {
> + compatible = "atmel,asoc-classd";
> +
> + atmel,model = "classd @ SAMA5D2-Xplained";
> + atmel,audio-platform = <>;
> + atmel,audio-cpu-dai-name = "fc048000.classd";
> + atmel,audio-codec = <>;
> +};
Why is this a separate DT node? It seems that this IP is entirely self
contained so I'm not clear why we need a separate node for the card, the
card is usually a separate node because it ties together multiple
different devices in the system but that's not the case here.
signature.asc
Description: Digital signature
