On Tue, Aug 23, 2016 at 12:44:03AM -0400, Ian Sutton wrote: > 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.
In the existing drm cases the i2c buses are setup by configuring the i2c function pointers in the drivers without a new driver, search for 'ic_acquire_bus = ' in dev/pci/drm/drm_dp_helper.c dev/pci/drm/i915/intel_sdvo.c dev/pci/drm/i915/intel_i2c.c dev/pci/drm/radeon/radeon_i2c.c But with the "ti,tps65217" pmic and possibly cape eeproms on i2c with the bbb, that model doesn't really make sense.
