On Thu, 09 Nov 2017, Russell King - ARM Linux wrote:
> On Thu, Nov 09, 2017 at 02:12:45PM +0200, Jani Nikula wrote:
>> And as I said elsewhere in the thread, Russell's patch may be relevant
>> for current Linus' master and stable. We just need to reconciliate how
>> the two things should work toge
On Thu, Nov 09, 2017 at 09:23:18AM +0100, Daniel Vetter wrote:
> On Tue, Nov 07, 2017 at 11:27:21AM +, Russell King wrote:
> > Parsing the EDID for HDMI and audio information in the get_modes()
> > callback is incorrect - this only parses the EDID read from the
> > connector, not any override o
Complementing my previous email information with better dmesg output
(I had booted with my TV monitor off in my previous email):
[8.687907] [drm] Initialized etnaviv 1.1.0 20151214 for
gpu-subsystem on minor 0
[8.689356] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[8.689
Hi everyone,
I can try that patch and see if it fixes the problem.
Give me a moment so that I can check how it goes.
Luís
On Thu, Nov 9, 2017 at 9:49 AM, Jani Nikula
wrote:
> On Thu, 09 Nov 2017, Russell King - ARM Linux
> wrote:
> > On Thu, Nov 09, 2017 at 09:23:18AM +0100, Daniel Vetter w
On Thu, Nov 09, 2017 at 02:12:45PM +0200, Jani Nikula wrote:
> And as I said elsewhere in the thread, Russell's patch may be relevant
> for current Linus' master and stable. We just need to reconciliate how
> the two things should work together in drm-next and v4.15 and on.
Exactly, the patch is i
I've verified that dw_hdmi tracks when there is a monitor connected or
not and reacts to it, there are logs that are generated when the
TV/Monitor goes into standby and this is true even if DDC cannot be
read.
My original problem is that if the EDID data cannot be read then
dw_hdmi will enter DVI m
On Thu, Nov 09, 2017 at 05:01:35PM +0200, Jani Nikula wrote:
> On Thu, 09 Nov 2017, Luís Mendes wrote:
> > Hi Jani,
> >
> > I tried:
> > git clone git://people.freedesktop.org/~airlied/linux -b drm-next
> > --depth=1 --single-branch
> >
> > I got this:
> > EDID isn't loaded from file
> >
> > # cat
Hi,
I've just applied the referred individual patch to kernel-4.14-rc5 and
the EDID isn't loaded. dw-hdmi gets no firmware at all.
#cat /proc/cmdline
console=ttymxc0,115200 root=/dev/sda2 rw video=HDMI-A-1:1920x1080M@60
drm.edid_firmware=edid/ktc_edid.bin dw_hdmi.dyndbg=+pfl cma=128M
#zcat /proc
Hi Jani,
I tried:
git clone git://people.freedesktop.org/~airlied/linux -b drm-next
--depth=1 --single-branch
I got this:
EDID isn't loaded from file
# cat /proc/cmdline
console=ttymxc0,115200 root=/dev/sda2 rw video=HDMI-A-1:1920x1080M@60
drm.edid_firmware=edid/ktc_edid.bin dw_hdmi.dyndbg=+pfl
On Thu, 09 Nov 2017, Luís Mendes wrote:
> Hi Jani,
>
> I tried:
> git clone git://people.freedesktop.org/~airlied/linux -b drm-next
> --depth=1 --single-branch
>
> I got this:
> EDID isn't loaded from file
>
> # cat /proc/cmdline
> console=ttymxc0,115200 root=/dev/sda2 rw video=HDMI-A-1:1920x1080M
On Thu, 09 Nov 2017, Luís Mendes wrote:
> I've just applied the referred individual patch to kernel-4.14-rc5 and
> the EDID isn't loaded. dw-hdmi gets no firmware at all.
Sorry, I didn't mean you could just cherry-pick that one commit and make
it work. There were a number of preparatory patches b
On Thu, 09 Nov 2017, Russell King - ARM Linux wrote:
> On Thu, Nov 09, 2017 at 09:23:18AM +0100, Daniel Vetter wrote:
>> On Tue, Nov 07, 2017 at 11:27:21AM +, Russell King wrote:
>> > Parsing the EDID for HDMI and audio information in the get_modes()
>> > callback is incorrect - this only pars
On Tue, 07 Nov 2017, Russell King wrote:
> Parsing the EDID for HDMI and audio information in the get_modes()
> callback is incorrect - this only parses the EDID read from the
> connector, not any override or firmware provided EDID.
>
> The correct place to parse the EDID for these parameters is t
On Tue, Nov 07, 2017 at 11:27:21AM +, Russell King wrote:
> Parsing the EDID for HDMI and audio information in the get_modes()
> callback is incorrect - this only parses the EDID read from the
> connector, not any override or firmware provided EDID.
>
> The correct place to parse the EDID for
On 11/07/2017 04:57 PM, Russell King wrote:
Parsing the EDID for HDMI and audio information in the get_modes()
callback is incorrect - this only parses the EDID read from the
connector, not any override or firmware provided EDID.
The correct place to parse the EDID for these parameters is the
Parsing the EDID for HDMI and audio information in the get_modes()
callback is incorrect - this only parses the EDID read from the
connector, not any override or firmware provided EDID.
The correct place to parse the EDID for these parameters is the
fill_modes() callback, after we've called the he
16 matches
Mail list logo