There is one issue to use i2c_smbus_XX functions: i2c_smbus_read_i2c_block_data has limitation with the maximum count I2C_SMBUS_BLOCK_MAX. But in function hdmi_hdcp_recv_ksv_fifo, since the downstream ksv_fifo size will exceed this limitation and must be read in a single transaction, we can't use this function then. > On Fri, Jan 30, 2015 at 2:39 PM, Bjorn Andersson <bjorn@xxxxxxx> wrote: >> On Fri, Jan 30, 2015 at 1:51 PM, Bjorn Andersson <bjorn@xxxxxxx> wrote: >>> On Tue, Jan 13, 2015 at 12:43 PM, Jilai Wang <jilaiw@xxxxxxxxxxxxxx> >>> wrote: >>>> Add HDMI HDCP support including HDCP PartI/II/III authentication. >>>> V1: Initial Change >>>> V2: Address Bjorn&Rob's comments >>>> Refactor the authentication process to use single work instead >>>> of multiple work for different authentication stages. >>>> >>> Looks cleaner and the SCM parts look good now. >>> >>> But the ddc communication still makes me wonder, see below. >>> >> >> Rob made me aware about the fact that the hdmi driver is both >> implementing a driver for the i2c controller and now for the hdcp >> client and hence doesn't have an i2c_client handle. >> >> So unless this is redesigned to be split in a separate i2c client >> driver we probably have to have the ddc functions like this. >> >> I'm fine with this as is for now. >> > > After digging some more in the i2c stack I found others using > i2c_new_dummy() to create a "dummy" i2c client from and adaptor and an > address. > By introducing that we could make hdmi->i2c an actual i2c_client and > use the client api in here. > > Regards, > Bjorn > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
