Hi Nick,
On Tuesday, 5 December 2017 05:22:28 EET Nick Bowler wrote:
> On 2017-12-04 21:34 +0200, Laurent Pinchart wrote:
> > On Monday, 4 December 2017 21:30:01 EET Nick Bowler wrote:
> >> On 2017-12-04 21:06 +0200, Laurent Pinchart wrote:
> >>> As you reported that the PLL lock failure message
On 2017-12-04 13:33 -0500, Nick Bowler wrote:
> On 2017-12-04 10:04 +, Jose Abreu wrote:
> > Hmmm, my first thought was that audio is being configured first
> > because of the phy lock wait time, I've seen this happening before.
> >
> > Lets try this:
> > - Disable all alsa clients (e.g.
On 2017-12-04 10:04 +, Jose Abreu wrote:
> On 03-12-2017 05:20, Nick Bowler wrote:
> > I brought the original test equipment back to the setup so I can
> > see the video and pink bar again. The symptoms remain the same
> > (unexpected size, pink bar, and no audio).
> >
>
> Can you tell me
Hi,
On 2017-12-04 21:06 +0200, Laurent Pinchart wrote:
> As you reported that the PLL lock failure message is not printed, the
> failure can only come from either the extra delay introduced by the
> above loop, or from reading the HDMI_PHY_STAT0 register.
>
> How many iterations of the for loop
On 2017-12-04 21:34 +0200, Laurent Pinchart wrote:
> On Monday, 4 December 2017 21:30:01 EET Nick Bowler wrote:
> > On 2017-12-04 21:06 +0200, Laurent Pinchart wrote:
> > > As you reported that the PLL lock failure message is not printed, the
> > > failure can only come from either the extra delay
Hi Nick,
On Monday, 4 December 2017 21:30:01 EET Nick Bowler wrote:
> On 2017-12-04 21:06 +0200, Laurent Pinchart wrote:
> > As you reported that the PLL lock failure message is not printed, the
> > failure can only come from either the extra delay introduced by the
> > above loop, or from
Hi Nick,
On Friday, 1 December 2017 02:11:46 EET Nick Bowler wrote:
> On 2017-11-27 22:30 -0500, Nick Bowler wrote:
> > A note about the test setup: I had to remove the test equipment so I
> > no longer have any information about the video mode from the sink side
> > (like in the photos). Thus,
On 03-12-2017 05:20, Nick Bowler wrote:
>
> Your patch changes things. With this applied on top of 4.15-rc1
> it is failing 100% of the time instead of only half of the time.
Ok, it was a long shot anyway.
>
> I brought the original test equipment back to the setup so I can
> see the video and
Hi Jose,
On 2017-12-02 17:11 +, Jose Abreu wrote:
> On 01-12-2017 00:11, Nick Bowler wrote:
> > Another data point... the following patch appears sufficient to
> > restore working behaviour.
[...]
> I don't think you can do this. The phy pll lock check is
> recommended and can indicate hw
Hi Nick,
On 01-12-2017 00:11, Nick Bowler wrote:
> Hi,
>
> On 2017-11-27 22:30 -0500, Nick Bowler wrote:
>> A note about the test setup: I had to remove the test equipment so I
>> no longer have any information about the video mode from the sink side
>> (like in the photos). Thus, with the
Hi,
On 2017-11-27 22:30 -0500, Nick Bowler wrote:
> A note about the test setup: I had to remove the test equipment so I
> no longer have any information about the video mode from the sink side
> (like in the photos). Thus, with the current setup, I am using the
> presense or absense of audio to
On 2017-11-27 11:00 +0200, Laurent Pinchart wrote:
> On Monday, 27 November 2017 06:05:03 EET Archit Taneja wrote:
> > On 2017-11-05 11:41 -0500, Nick Bowler wrote:
[...]
> > > Bisection implicates the following commit:
> > >
> > > 181e0ef092a4952aa523c5b9cb21394cf43bcd46 is the first bad commit
Hi,
On 11/27/17, Laurent Pinchart wrote:
> The driver should print a "PHY PLL failed to lock" error message to the
> kernel log in that case. Nick, does that happen on your system ?
I will try to test the other things later today, but after bootup there
were
Hi Archit,
Thank you for handling this, and sorry for missing the original bug report
(and for breaking this in the first place).
On Monday, 27 November 2017 06:05:03 EET Archit Taneja wrote:
> On 11/16/2017 11:58 AM, Nick Bowler wrote:
> > On 2017-11-05 11:41 -0500, Nick Bowler wrote:
> >> On
Hi,
On 11/16/2017 11:58 AM, Nick Bowler wrote:
Hi,
Any ideas on this issue? Are there any additional tests I can perform
to help debug this?
On 2017-11-05 11:41 -0500, Nick Bowler wrote:
I completed bisecting this issue. See below.
On 2017-11-02, Nick Bowler wrote:
Hi,
Any ideas on this issue? Are there any additional tests I can perform
to help debug this?
On 2017-11-05 11:41 -0500, Nick Bowler wrote:
> I completed bisecting this issue. See below.
>
> On 2017-11-02, Nick Bowler wrote:
> > ~50% of the time after a hotplug, there is
Hi,
I completed bisecting this issue. See below.
On 2017-11-02, Nick Bowler wrote:
> ~50% of the time after a hotplug, there is a vertical pink bar on the
> left of the display area and audio is not working at all. According to
> the sink device the display size is
Hi,
On my Asus C201 laptop (rk3288) the HDMI has been behaving weirdly after
Linux upgrade.
~50% of the time after a hotplug, there is a vertical pink bar on the
left of the display area and audio is not working at all. According to
the sink device the display size is 1282x720 which seems
18 matches
Mail list logo