* Maciej Purski [180307 14:38]:
>
> On 03/07/2018 03:10 PM, Mark Brown wrote:
> > On Wed, Mar 07, 2018 at 01:57:12PM +0100, Maciej Purski wrote:
> >
> > > I'm trying to figure out what is so special about these boards. The only
> > > strange thing, that I haven't noticed
* Maciej Purski [180307 14:38]:
>
> On 03/07/2018 03:10 PM, Mark Brown wrote:
> > On Wed, Mar 07, 2018 at 01:57:12PM +0100, Maciej Purski wrote:
> >
> > > I'm trying to figure out what is so special about these boards. The only
> > > strange thing, that I haven't noticed at first, is that all
On Tue, Mar 06, 2018 at 07:10:01PM -0300, Fabio Estevam wrote:
> Yesterday I spent a few hours trying to understand this locking issue,
> but didn't get any success on this task.
Right, so I'm thinking that if it's taking this much effort to think
about the problem we should just drop the patch
On Tue, Mar 06, 2018 at 07:10:01PM -0300, Fabio Estevam wrote:
> Yesterday I spent a few hours trying to understand this locking issue,
> but didn't get any success on this task.
Right, so I'm thinking that if it's taking this much effort to think
about the problem we should just drop the patch
On 03/07/2018 03:10 PM, Mark Brown wrote:
On Wed, Mar 07, 2018 at 01:57:12PM +0100, Maciej Purski wrote:
I'm trying to figure out what is so special about these boards. The only
strange thing, that I haven't noticed at first, is that all regulators share
a common supply - dummy regulator. It
On 03/07/2018 03:10 PM, Mark Brown wrote:
On Wed, Mar 07, 2018 at 01:57:12PM +0100, Maciej Purski wrote:
I'm trying to figure out what is so special about these boards. The only
strange thing, that I haven't noticed at first, is that all regulators share
a common supply - dummy regulator. It
On Wed, Mar 07, 2018 at 01:57:12PM +0100, Maciej Purski wrote:
> I'm trying to figure out what is so special about these boards. The only
> strange thing, that I haven't noticed at first, is that all regulators share
> a common supply - dummy regulator. It is defined in anatop_regulator.c.
No,
On Wed, Mar 07, 2018 at 01:57:12PM +0100, Maciej Purski wrote:
> I'm trying to figure out what is so special about these boards. The only
> strange thing, that I haven't noticed at first, is that all regulators share
> a common supply - dummy regulator. It is defined in anatop_regulator.c.
No,
Hi all,
sorry it took me so long to answer.
On 03/06/2018 05:30 PM, Mark Brown wrote:
On Mon, Mar 05, 2018 at 08:22:26PM -0300, Fabio Estevam wrote:
On Mon, Mar 5, 2018 at 8:12 PM, Tony Lindgren wrote:
Looks like with next-20180305 there's a regulator regression
where
Hi all,
sorry it took me so long to answer.
On 03/06/2018 05:30 PM, Mark Brown wrote:
On Mon, Mar 05, 2018 at 08:22:26PM -0300, Fabio Estevam wrote:
On Mon, Mar 5, 2018 at 8:12 PM, Tony Lindgren wrote:
Looks like with next-20180305 there's a regulator regression
where mmc0 won't show any
On Tue, Mar 6, 2018 at 6:33 PM, Mark Brown wrote:
> No, unfortunately, apart from the generic kernel ones (like lockdep).
> I'll try to have a poke at adding some tomorrow, though I'm also
> considering just dropping the series for now.
Ok, lockdep is already enabled by
On Tue, Mar 6, 2018 at 6:33 PM, Mark Brown wrote:
> No, unfortunately, apart from the generic kernel ones (like lockdep).
> I'll try to have a poke at adding some tomorrow, though I'm also
> considering just dropping the series for now.
Ok, lockdep is already enabled by default in the defconfig
On Tue, Mar 06, 2018 at 05:06:48PM -0300, Fabio Estevam wrote:
> On Tue, Mar 6, 2018 at 4:12 PM, Mark Brown wrote:
> > Yeah, that's what I expected. What we really need to figure out I think
> > is what exactly is taking the lock that we end up colliding with, I
> > don't
On Tue, Mar 06, 2018 at 05:06:48PM -0300, Fabio Estevam wrote:
> On Tue, Mar 6, 2018 at 4:12 PM, Mark Brown wrote:
> > Yeah, that's what I expected. What we really need to figure out I think
> > is what exactly is taking the lock that we end up colliding with, I
> > don't seem to be able to
Hi Mark,
On Tue, Mar 6, 2018 at 4:12 PM, Mark Brown wrote:
> Yeah, that's what I expected. What we really need to figure out I think
> is what exactly is taking the lock that we end up colliding with, I
> don't seem to be able to reproduce so I'm having to just go on
Hi Mark,
On Tue, Mar 6, 2018 at 4:12 PM, Mark Brown wrote:
> Yeah, that's what I expected. What we really need to figure out I think
> is what exactly is taking the lock that we end up colliding with, I
> don't seem to be able to reproduce so I'm having to just go on staring
> at the code
On Tue, Mar 06, 2018 at 01:56:42PM -0300, Fabio Estevam wrote:
> On Tue, Mar 6, 2018 at 1:30 PM, Mark Brown wrote:
> > - for (i = 0; rdev; rdev = rdev_get_supply(rdev), i++)
> > + for (i = 1000; rdev; rdev = rdev_get_supply(rdev), i++)
> >
On Tue, Mar 06, 2018 at 01:56:42PM -0300, Fabio Estevam wrote:
> On Tue, Mar 6, 2018 at 1:30 PM, Mark Brown wrote:
> > - for (i = 0; rdev; rdev = rdev_get_supply(rdev), i++)
> > + for (i = 1000; rdev; rdev = rdev_get_supply(rdev), i++)
> > mutex_lock_nested(>mutex,
* Fabio Estevam [180306 16:57]:
> Hi Mark,
>
> On Tue, Mar 6, 2018 at 1:30 PM, Mark Brown wrote:
>
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index e685f8b94acf..2c5b20a97f51 100644
> > --- a/drivers/regulator/core.c
> > +++
* Fabio Estevam [180306 16:57]:
> Hi Mark,
>
> On Tue, Mar 6, 2018 at 1:30 PM, Mark Brown wrote:
>
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index e685f8b94acf..2c5b20a97f51 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@
Hi Mark,
On Tue, Mar 6, 2018 at 1:30 PM, Mark Brown wrote:
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index e685f8b94acf..2c5b20a97f51 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -159,7 +159,7 @@ static void
Hi Mark,
On Tue, Mar 6, 2018 at 1:30 PM, Mark Brown wrote:
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index e685f8b94acf..2c5b20a97f51 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -159,7 +159,7 @@ static void
On Mon, Mar 05, 2018 at 08:22:26PM -0300, Fabio Estevam wrote:
> On Mon, Mar 5, 2018 at 8:12 PM, Tony Lindgren wrote:
> > Looks like with next-20180305 there's a regulator regression
> > where mmc0 won't show any cards or produces errors:
> > mmcblk0: error -110 requesting
On Mon, Mar 05, 2018 at 08:22:26PM -0300, Fabio Estevam wrote:
> On Mon, Mar 5, 2018 at 8:12 PM, Tony Lindgren wrote:
> > Looks like with next-20180305 there's a regulator regression
> > where mmc0 won't show any cards or produces errors:
> > mmcblk0: error -110 requesting status
> > mmc1: new
Hi Tony,
On Mon, Mar 5, 2018 at 8:12 PM, Tony Lindgren wrote:
> Hi Mark and Maciej,
>
> Looks like with next-20180305 there's a regulator regression
> where mmc0 won't show any cards or produces errors:
>
> mmcblk0: error -110 requesting status
> mmc1: new high speed SDIO card
Hi Tony,
On Mon, Mar 5, 2018 at 8:12 PM, Tony Lindgren wrote:
> Hi Mark and Maciej,
>
> Looks like with next-20180305 there's a regulator regression
> where mmc0 won't show any cards or produces errors:
>
> mmcblk0: error -110 requesting status
> mmc1: new high speed SDIO card at address 0001
>
26 matches
Mail list logo