On Mon 2015-11-23 11:46:37, Charles Keepax wrote:
> On Mon, Nov 23, 2015 at 11:30:41AM +, Mark Brown wrote:
> > On Mon, Nov 23, 2015 at 10:25:22AM +, Richard Fitzgerald wrote:
> > > On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote:
> >
> > > > That's what I'm saying. It is good to
On Mon, 23 Nov 2015, Charles Keepax wrote:
> On Mon, Nov 23, 2015 at 11:30:41AM +, Mark Brown wrote:
> > On Mon, Nov 23, 2015 at 10:25:22AM +, Richard Fitzgerald wrote:
> > > On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote:
> >
> > > > That's what I'm saying. It is good to know who
On Mon, Nov 23, 2015 at 11:30:41AM +, Mark Brown wrote:
> On Mon, Nov 23, 2015 at 10:25:22AM +, Richard Fitzgerald wrote:
> > On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote:
>
> > > That's what I'm saying. It is good to know who is the person of
> > > authority, as you can't tell
On Mon, Nov 23, 2015 at 10:25:22AM +, Richard Fitzgerald wrote:
> On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote:
> > That's what I'm saying. It is good to know who is the person of
> > authority, as you can't tell from the From: address.
> It's unreasonable to expect that one member
On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote:
> On Mon 2015-11-23 08:18:57, Lee Jones wrote:
> > On Sun, 22 Nov 2015, Pavel Machek wrote:
> >
> > > On Mon 2015-11-16 14:11:42, Charles Keepax wrote:
> > > > On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote:
> > > > > HiOn Sat
On Mon 2015-11-23 08:18:57, Lee Jones wrote:
> On Sun, 22 Nov 2015, Pavel Machek wrote:
>
> > On Mon 2015-11-16 14:11:42, Charles Keepax wrote:
> > > On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote:
> > > > HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> > > > > On Sat, Nov 14,
On Sun, 22 Nov 2015, Pavel Machek wrote:
> On Mon 2015-11-16 14:11:42, Charles Keepax wrote:
> > On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote:
> > > HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> > > > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> > > >
> > >
On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote:
> On Mon 2015-11-23 08:18:57, Lee Jones wrote:
> > On Sun, 22 Nov 2015, Pavel Machek wrote:
> >
> > > On Mon 2015-11-16 14:11:42, Charles Keepax wrote:
> > > > On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote:
> > > > > HiOn Sat
On Mon, Nov 23, 2015 at 10:25:22AM +, Richard Fitzgerald wrote:
> On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote:
> > That's what I'm saying. It is good to know who is the person of
> > authority, as you can't tell from the From: address.
> It's unreasonable to expect that one member
On Sun, 22 Nov 2015, Pavel Machek wrote:
> On Mon 2015-11-16 14:11:42, Charles Keepax wrote:
> > On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote:
> > > HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> > > > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> > > >
> > >
On Mon 2015-11-23 08:18:57, Lee Jones wrote:
> On Sun, 22 Nov 2015, Pavel Machek wrote:
>
> > On Mon 2015-11-16 14:11:42, Charles Keepax wrote:
> > > On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote:
> > > > HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> > > > > On Sat, Nov 14,
On Mon, Nov 23, 2015 at 11:30:41AM +, Mark Brown wrote:
> On Mon, Nov 23, 2015 at 10:25:22AM +, Richard Fitzgerald wrote:
> > On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote:
>
> > > That's what I'm saying. It is good to know who is the person of
> > > authority, as you can't tell
On Mon, 23 Nov 2015, Charles Keepax wrote:
> On Mon, Nov 23, 2015 at 11:30:41AM +, Mark Brown wrote:
> > On Mon, Nov 23, 2015 at 10:25:22AM +, Richard Fitzgerald wrote:
> > > On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote:
> >
> > > > That's what I'm saying. It is good to know who
On Mon 2015-11-23 11:46:37, Charles Keepax wrote:
> On Mon, Nov 23, 2015 at 11:30:41AM +, Mark Brown wrote:
> > On Mon, Nov 23, 2015 at 10:25:22AM +, Richard Fitzgerald wrote:
> > > On Mon, 2015-11-23 at 11:11 +0100, Pavel Machek wrote:
> >
> > > > That's what I'm saying. It is good to
On Mon 2015-11-16 14:11:42, Charles Keepax wrote:
> On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote:
> > HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> > > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> > >
> > > > Well, mfd_core.c seems to call
On Mon 2015-11-16 14:11:42, Charles Keepax wrote:
> On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote:
> > HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> > > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> > >
> > > > Well, mfd_core.c seems to call
On Mon, Nov 16, 2015 at 01:29:47PM +0100, Pavel Machek wrote:
> > > Ok, so you are saying that if I fix mfd initialization, sound will
> > > automagically switch from global regulators to device-specific
> > > regulators and things will start working?
> > Yes.
> Ok, so something like this
On Mon, Nov 16, 2015 at 01:29:47PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > Every single sound driver gets this right, none of them assume the name
> > > > is global. What makes you say that they assume names are global?
> >
> > > Ok, so you are saying that if I fix mfd initialization, sound
On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote:
> HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> >
> > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
> > > with device that does not have
On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> Hi!
>
> > If you're asking about the regulator API or embedded ALSA both of those
> > are me but there are other things in here - the driver you're working
> > with and the MFD core at least. At the minute I'm not convinced that
> >
On Mon, Nov 16, 2015 at 01:29:47PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > Every single sound driver gets this right, none of them assume the name
> > > > is global. What makes you say that they assume names are global?
> >
> > > Ok, so you are saying that if I fix mfd initialization, sound
Hi!
> > > Every single sound driver gets this right, none of them assume the name
> > > is global. What makes you say that they assume names are global?
>
> > Ok, so you are saying that if I fix mfd initialization, sound will
> > automagically switch from global regulators to device-specific
>
On Mon, Nov 16, 2015 at 08:45:34AM +0100, Pavel Machek wrote:
> > > Ok, so SND_SOC_DAPM_REGULATOR_SUPPLY() does not work, because I have
> > > two regulators, right? Is there similar macro I can use?
> > No? What would make you say that?
> Plus, I'd expect to see some kind of "struct device"
On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote:
> HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> >
> > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
> > > with device that does not have
On Mon, Nov 16, 2015 at 01:29:47PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > Every single sound driver gets this right, none of them assume the name
> > > > is global. What makes you say that they assume names are global?
> >
> > > Ok, so you are saying that if I fix mfd initialization, sound
Hi!
> > > Every single sound driver gets this right, none of them assume the name
> > > is global. What makes you say that they assume names are global?
>
> > Ok, so you are saying that if I fix mfd initialization, sound will
> > automagically switch from global regulators to device-specific
>
On Mon, Nov 16, 2015 at 01:29:47PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > Every single sound driver gets this right, none of them assume the name
> > > > is global. What makes you say that they assume names are global?
> >
> > > Ok, so you are saying that if I fix mfd initialization, sound
On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> Hi!
>
> > If you're asking about the regulator API or embedded ALSA both of those
> > are me but there are other things in here - the driver you're working
> > with and the MFD core at least. At the minute I'm not convinced that
> >
On Mon, Nov 16, 2015 at 01:29:47PM +0100, Pavel Machek wrote:
> > > Ok, so you are saying that if I fix mfd initialization, sound will
> > > automagically switch from global regulators to device-specific
> > > regulators and things will start working?
> > Yes.
> Ok, so something like this
On Mon, Nov 16, 2015 at 08:45:34AM +0100, Pavel Machek wrote:
> > > Ok, so SND_SOC_DAPM_REGULATOR_SUPPLY() does not work, because I have
> > > two regulators, right? Is there similar macro I can use?
> > No? What would make you say that?
> Plus, I'd expect to see some kind of "struct device"
Hi!
> > > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
> > > > with device that does not have dev_name initialized.
>
> > > OK, that'll be the problem then - we're not mapping the supply into the
> > > individual child device but rather system wide, probably because
Hi!
> > > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
> > > > with device that does not have dev_name initialized.
>
> > > OK, that'll be the problem then - we're not mapping the supply into the
> > > individual child device but rather system wide, probably because
On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote:
> HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
> > > with device that does not have
HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
>
> > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
> > with device that does not have dev_name initialized.
>
> OK, that'll be the problem then - we're not
On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
> with device that does not have dev_name initialized.
OK, that'll be the problem then - we're not mapping the supply into the
individual child device but rather
Hi!
> > Obviously I'll need to use the existing interfaces, or extend them as
> > needed. I'd expect subsystem maintainer to know if the existing
> > interfaces are ok or what needs to be fixed, but it seems you either
> > don't know how your subsystem works, or are not willing to tell me.
>
> I
On Sat, Nov 14, 2015 at 08:44:00AM +0100, Pavel Machek wrote:
> Obviously I'll need to use the existing interfaces, or extend them as
> needed. I'd expect subsystem maintainer to know if the existing
> interfaces are ok or what needs to be fixed, but it seems you either
> don't know how your
On Sat, Nov 14, 2015 at 08:44:00AM +0100, Pavel Machek wrote:
> Obviously I'll need to use the existing interfaces, or extend them as
> needed. I'd expect subsystem maintainer to know if the existing
> interfaces are ok or what needs to be fixed, but it seems you either
> don't know how your
Hi!
> > Obviously I'll need to use the existing interfaces, or extend them as
> > needed. I'd expect subsystem maintainer to know if the existing
> > interfaces are ok or what needs to be fixed, but it seems you either
> > don't know how your subsystem works, or are not willing to tell me.
>
> I
On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
> with device that does not have dev_name initialized.
OK, that'll be the problem then - we're not mapping the supply into the
individual child device but rather
HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
>
> > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
> > with device that does not have dev_name initialized.
>
> OK, that'll be the problem then - we're not
On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote:
> HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
> > > with device that does not have
On Fri 2015-11-13 22:53:55, Mark Brown wrote:
> On Fri, Nov 13, 2015 at 10:58:12PM +0100, Pavel Machek wrote:
> > On Tue 2015-10-13 12:53:55, Mark Brown wrote:
> > > On Mon, Oct 12, 2015 at 10:11:38PM +0200, Pavel Machek wrote:
>
> > > > > No, you definitely shouldn't be doing this - the
On Fri, Nov 13, 2015 at 10:58:12PM +0100, Pavel Machek wrote:
> On Tue 2015-10-13 12:53:55, Mark Brown wrote:
> > On Mon, Oct 12, 2015 at 10:11:38PM +0200, Pavel Machek wrote:
> > > > No, you definitely shouldn't be doing this - the regulator names should
> > > > reflect the names the device has
On Tue 2015-10-13 12:53:55, Mark Brown wrote:
> On Mon, Oct 12, 2015 at 10:11:38PM +0200, Pavel Machek wrote:
> > On Mon 2015-10-12 16:47:15, Mark Brown wrote:
> > > On Mon, Oct 12, 2015 at 11:00:45AM +0200, Pavel Machek wrote:
>
> > > > static const struct regulator_desc arizona_ldo1_hc = {
> >
On Fri, Nov 13, 2015 at 10:58:12PM +0100, Pavel Machek wrote:
> On Tue 2015-10-13 12:53:55, Mark Brown wrote:
> > On Mon, Oct 12, 2015 at 10:11:38PM +0200, Pavel Machek wrote:
> > > > No, you definitely shouldn't be doing this - the regulator names should
> > > > reflect the names the device has
On Tue 2015-10-13 12:53:55, Mark Brown wrote:
> On Mon, Oct 12, 2015 at 10:11:38PM +0200, Pavel Machek wrote:
> > On Mon 2015-10-12 16:47:15, Mark Brown wrote:
> > > On Mon, Oct 12, 2015 at 11:00:45AM +0200, Pavel Machek wrote:
>
> > > > static const struct regulator_desc arizona_ldo1_hc = {
> >
On Fri 2015-11-13 22:53:55, Mark Brown wrote:
> On Fri, Nov 13, 2015 at 10:58:12PM +0100, Pavel Machek wrote:
> > On Tue 2015-10-13 12:53:55, Mark Brown wrote:
> > > On Mon, Oct 12, 2015 at 10:11:38PM +0200, Pavel Machek wrote:
>
> > > > > No, you definitely shouldn't be doing this - the
On Mon, Oct 12, 2015 at 10:11:38PM +0200, Pavel Machek wrote:
> On Mon 2015-10-12 16:47:15, Mark Brown wrote:
> > On Mon, Oct 12, 2015 at 11:00:45AM +0200, Pavel Machek wrote:
> > > static const struct regulator_desc arizona_ldo1_hc = {
> > > - .name = "LDO1",
> > No, you definitely shouldn't
On Mon, Oct 12, 2015 at 10:11:38PM +0200, Pavel Machek wrote:
> On Mon 2015-10-12 16:47:15, Mark Brown wrote:
> > On Mon, Oct 12, 2015 at 11:00:45AM +0200, Pavel Machek wrote:
> > > static const struct regulator_desc arizona_ldo1_hc = {
> > > - .name = "LDO1",
> > No, you definitely shouldn't
Hi!
On Mon 2015-10-12 16:47:15, Mark Brown wrote:
> On Mon, Oct 12, 2015 at 11:00:45AM +0200, Pavel Machek wrote:
>
> > Does this look like a step in right direction?
>
> > static const struct regulator_desc arizona_ldo1_hc = {
> > - .name = "LDO1",
>
> No, you definitely shouldn't be doing
On Mon, Oct 12, 2015 at 11:00:45AM +0200, Pavel Machek wrote:
> Does this look like a step in right direction?
> static const struct regulator_desc arizona_ldo1_hc = {
> - .name = "LDO1",
No, you definitely shouldn't be doing this - the regulator names should
reflect the names the device
On Mon, Oct 12, 2015 at 11:00:45AM +0200, Pavel Machek wrote:
> Hi!
>
> > I guess you would need to be careful with the machine driver as
> > well, you will need to use a snd_soc_codec_conf structure for at
> > least one (although I would do both) of the CODECs to give a
> > prefix for all the
Hi!
> I guess you would need to be careful with the machine driver as
> well, you will need to use a snd_soc_codec_conf structure for at
> least one (although I would do both) of the CODECs to give a
> prefix for all the widget/control names, otherwise those will
> clash and everything will
Hi!
> I guess you would need to be careful with the machine driver as
> well, you will need to use a snd_soc_codec_conf structure for at
> least one (although I would do both) of the CODECs to give a
> prefix for all the widget/control names, otherwise those will
> clash and everything will
On Mon, Oct 12, 2015 at 11:00:45AM +0200, Pavel Machek wrote:
> Does this look like a step in right direction?
> static const struct regulator_desc arizona_ldo1_hc = {
> - .name = "LDO1",
No, you definitely shouldn't be doing this - the regulator names should
reflect the names the device
On Mon, Oct 12, 2015 at 11:00:45AM +0200, Pavel Machek wrote:
> Hi!
>
> > I guess you would need to be careful with the machine driver as
> > well, you will need to use a snd_soc_codec_conf structure for at
> > least one (although I would do both) of the CODECs to give a
> > prefix for all the
Hi!
On Mon 2015-10-12 16:47:15, Mark Brown wrote:
> On Mon, Oct 12, 2015 at 11:00:45AM +0200, Pavel Machek wrote:
>
> > Does this look like a step in right direction?
>
> > static const struct regulator_desc arizona_ldo1_hc = {
> > - .name = "LDO1",
>
> No, you definitely shouldn't be doing
58 matches
Mail list logo
