RE: Delay between stop condition and start condition

> Subject: Re: Delay between stop condition and start condition > > > > The passthrough mode is not default, it gets activated by the driver so that > > drm_get_edid can then fetch the EDID. One other nasty thing is that to end > > the conversation > > with the

Re: Delay between stop condition and start condition

> The passthrough mode is not default, it gets activated by the driver so that > drm_get_edid can then fetch the EDID. One other nasty thing is that to end > the conversation > with the monitor you are supposed to write 0x00 to register 0x1a of the HDMI > transmitter, > which means the SoC puts

RE: Delay between stop condition and start condition

> Subject: Re: Delay between stop condition and start condition > > > > be fixed in its driver. It probably could be a generic driver, or? > > Wishful thinking. Setting the passthrough mode is probably not default, > so it is device specific. The passthrough mode is not de

Re: Delay between stop condition and start condition

On 2018-10-17 14:16, Wolfram Sang wrote: > >> Or, add an I2C gate driver (sort of like an I2C mux with only one child >> bus) in the HDMI transmitter driver and implement the delay there. Then >> move the monitor to this new gate/mux child bus. > > That would actually be my preferred solution.

Re: Delay between stop condition and start condition

Hi Wolfram, On Wed, Oct 17, 2018 at 2:21 PM Wolfram Sang wrote: > > be fixed in its driver. It probably could be a generic driver, or? > > Wishful thinking. Setting the passthrough mode is probably not default, > so it is device specific. According to the block diagram in

Re: Delay between stop condition and start condition

> be fixed in its driver. It probably could be a generic driver, or? Wishful thinking. Setting the passthrough mode is probably not default, so it is device specific. signature.asc Description: PGP signature

Re: Delay between stop condition and start condition

> Or, add an I2C gate driver (sort of like an I2C mux with only one child > bus) in the HDMI transmitter driver and implement the delay there. Then > move the monitor to this new gate/mux child bus. That would actually be my preferred solution. Because it describes the HW setup best. It is the

Re: Delay between stop condition and start condition

On 2018-10-17 12:32, Wolfram Sang wrote: > Hi Fabrizio, everyone, > > Thanks for bringing this up! > >> What's the best way to address this? I could pull in the HDMI >> transmitter driver the code to read the EDID back from the monitor so >> that I can fit device specific delays without

RE: Delay between stop condition and start condition

Hello Wolfram, Thank you so much for your feedback! > Subject: Re: Delay between stop condition and start condition > > Hi Fabrizio, everyone, > > Thanks for bringing this up! > > > What's the best way to address this? I could pull in the HDMI > > transmitter dr

Re: Delay between stop condition and start condition

Hi Fabrizio, everyone, Thanks for bringing this up! > What's the best way to address this? I could pull in the HDMI > transmitter driver the code to read the EDID back from the monitor so > that I can fit device specific delays without impacting the generic > implementation of the EDID readback,

Delay between stop condition and start condition

Hello Wolfram, While working out what's needed to add HDMI support to the iwg23s from iWave I have stumbled across a problem with the HDMI transmitter (SiI9022ACNU). Such an HDMI transmitter has a DDC pass through mode that allows the SoC to talk directly to the monitor (to allow the SoC to