On Fri, Aug 19, 2016 at 03:02:34PM +1000, Jonathan Gray wrote: > On Fri, Aug 19, 2016 at 02:38:32PM +1000, Jonathan Gray wrote: > > On Thu, Aug 18, 2016 at 04:34:38PM -0400, Ian Sutton wrote: > > > On Sat, Aug 06, 2016 at 04:26:27AM -0400, Ian Sutton wrote: > > > > Interestingly, the am335x SoC does not have a HDMI/DP/etc transmitter on > > > > silicon -- the BBB has its LCDC pins wired to a TDA19988 HDMI > > > > transmitter which is additionally backwired to one of the am335x's i2c > > > > ports: > > > > > > > > "nxp,tda998x" at iic0 addr 0x70 not configured > > > > > > > > Without a TDA19988 driver we are unable to probe for an attached > > > > display's EDID bits thus unable to tailor timing/videomode parameters > > > > on a per-display basis. > > > > > > The following patch adds the nxptda(4) i2c driver: > > > > > > nxptda0 at iic0 addr 0x70: rev 0x0301 > > > > > > It correctly ascertains the EDID bits of displays connected to the > > > beaglebone black: > > > > > > nxptda0 at iic0 addr 0x70 > > > nxptda0: set page to 0x00 > > > nxptda0: read 0x31 from 0x00 on page 0x00, result: 0 > > > nxptda0: read 0x03 from 0x02 on page 0x00, result: 0 > > > nxptda0: rev 0x0301 > > > nxptda0: read 0x00 from 0x0a on page 0x00, result: 0 > > > nxptda0: wrote 0x03 to 0x0a on page 0x00, result: 0 > > > nxptda0: read 0x03 from 0x0a on page 0x00, result: 0 > > > nxptda0: wrote 0x00 to 0x0a on page 0x00, result: 0 > > > > > > <snip> > > > > > > nxptda0: read 0x02 from 0x11 on page 0x00, result: 0 > > > nxptda0: EDID-ready IRQ fired > > > nxptda0: set page to 0x09 > > > nxptda0: ------------- EDID ------------- > > > nxptda0: 00ffffffffffff0022f05b2801010101 > > > nxptda0: 1b15010380261e8ceef6b0a3554c9b25 > > > nxptda0: 115054a1080081808140010101010101 > > > nxptda0: 010101010101302a009851002a403070 > > > nxptda0: 13007c2c1100001e000000fd00324c18 > > > nxptda0: 530e000a202020202020000000fc004c > > > nxptda0: 41313935310a202020202020000000ff > > > nxptda0: 00434e43313237504c56420a20200022 > > > nxptda0: -------------------------------- > > > ^--matches EDID bits from `xrandr --verbose` > > > > > > > > > This will be important for upcoming display support on armv7 (see > > > amdisplay(4) threads on this list[1]). The following code is > > > review-ready to some degree, however, I imagine further register > > > fiddling will be needed to communicate the intended timings perhaps > > > implicating more externally callable functions. > > > > > > Speaking of which: > > > > > > I am apprehensive of nxptda(4)'s current external interface model. I > > > currently have the lone nxptda_refresh_edid() function declared in > > > nxptdavar.h header in sys/dev/i2c/, meant to be included by other drivers > > > which need the EDID information it provides. No other such foo_var.h > > > headers appear in that directory which makes me think I am doing > > > something wrong. nxptda(4) is an i2c driver and must attach to the MI > > > iic(4) driver precluding a direct attachment interface. Is there a > > > better way of doing this? > > > > Have you considered directly attaching the i2c bus to your other > > driver without creating a new driver and using drm_edid.c ? > > Though this would mean not attaching to tiiic, and unlike > inteldrm/radeondrm there are other things on the i2c bus.
I am not sure what you mean here -- if nxptda doesn't attach to tiiic then how is nxptda afforded the abstracted i2c subroutines filled in by tiiic? All the iic-* functions nxptda should use require an i2c_tag_t which in this case can only be provided by attaching at tiiic.
