como faço para encontrar a velocidade atual do barramento i2c?

Pesquisei sobre isso para um Kernel da série 6.8.0, pois é o que temos atualmente em um sistema Ubuntu 24.04.2 LTS.

O sistema usou uma placa de vídeo Quadro K4200 que expõe um barramento I2C que pode ler a identidade do monitor conectado:

$ sudo i2cdump -y -r 0-0x7f 1 0x50 c | tail -8 | cut -b 5-51 | edid-decode 
edid-decode (hex):

00 ff ff ff ff ff ff 00 22 f0 6a 28 01 01 01 01
02 15 01 03 80 36 23 78 2e fc 81 a4 55 4d 9d 25
12 50 54 21 08 00 81 40 81 80 95 00 a9 40 b3 00
d1 c0 01 01 01 01 28 3c 80 a0 70 b0 23 40 30 20
36 00 22 60 21 00 00 1a 00 00 00 fd 00 3b 3d 18
50 11 00 0a 20 20 20 20 20 20 00 00 00 fc 00 48
50 20 5a 52 32 34 77 0a 20 20 20 20 00 00 00 ff
00 43 4e 54 31 30 32 31 34 30 36 0a 20 20 00 83

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
    Manufacturer: HWP
    Model: 10346
    Serial Number: 16843009
    Made in: week 2 of 2011
  Basic Display Parameters & Features:
    Digital display
    Maximum image size: 54 cm x 35 cm
    Gamma: 2.20
    DPMS levels: Off
    RGB color display
    Default (sRGB) color space is primary color space
    First detailed timing is the preferred timing
  Color Characteristics:
    Red  : 0.6435, 0.3349
    Green: 0.3037, 0.6132
    Blue : 0.1464, 0.0703
    White: 0.3125, 0.3291
  Established Timings I & II:
    DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
    DMT 0x09:   800x600    60.316541 Hz   4:3     37.879 kHz     40.000000 MHz
    DMT 0x10:  1024x768    60.003840 Hz   4:3     48.363 kHz     65.000000 MHz
  Standard Timings:
    DMT 0x20:  1280x960    60.000000 Hz   4:3     60.000 kHz    108.000000 MHz
    DMT 0x23:  1280x1024   60.019740 Hz   5:4     63.981 kHz    108.000000 MHz
    DMT 0x2f:  1440x900    59.887445 Hz  16:10    55.935 kHz    106.500000 MHz
    DMT 0x33:  1600x1200   60.000000 Hz   4:3     75.000 kHz    162.000000 MHz
    DMT 0x3a:  1680x1050   59.954250 Hz  16:10    65.290 kHz    146.250000 MHz
    DMT 0x52:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
  Detailed Timing Descriptors:
    DTD 1:  1920x1200   59.950171 Hz   8:5     74.038 kHz    154.000000 MHz (546 mm x 352 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol P
                 Vfront    3 Vsync   6 Vback   26 Vpol N
    Display Range Limits:
      Monitor ranges (GTF): 59-61 Hz V, 24-80 kHz H, max dotclock 170 MHz
    Display Product Name: 'HP ZR24w'
    Display Product Serial Number: 'CNT1021406'
Checksum: 0x83

A Quadro K4200 usa o nouveaudriver, que também tem uma dependência do i2c-algo-bitmódulo, assim como o i915driver da pergunta.

Olhando abaixo /sys/class/i2c-adapterpara os barramentos I2C fornecidos pela Quadro K4200, não consigo ver nenhum arquivo disponível no espaço do usuário que defina a velocidade do barramento I2C.

O código fonte i2c-algo-bit.c mostra um driver bit-banged de software onde o software controla o indivíduo SCLe SDAos sinais no barramento I2C com software usado para inserir atrasos mínimos entre a alternância dos sinais no barramento I2C.

struct i2c_algo_bit_data tem o seguinte campo que é usado para controlar o tempo do software:

    int udelay;     /* half clock cycle time in us,
                   minimum 2 us for fast-mode I2C,
                   minimum 5 us for standard-mode I2C and SMBus,
                   maximum 50 us for SMBus */

As funções em i2c-algo-bit.c têm chamadas para udelay(), às vezes atrasando for adap->udelaye outras vezes (adap->udelay + 1) / 2.

O driver i915/display/intel_gmbus.c usado na questão codifica a velocidade do barramento I2C com a seguinte macro:

#define I2C_RISEFALL_TIME 10

Que é usado na intel_gpio_setupfunção para inicializar o i2c_algo_bit_data udelay:

    algo->udelay = I2C_RISEFALL_TIME;

Portanto, a velocidade do barramento I2C usada pelo i915 será de no máximo 50 kHz (já que o tempo de meio ciclo de clock é codificado como 10 microssegundos). A velocidade real do barramento provavelmente será menor, devido aos atrasos de software usados ​​para controlar a temporização.

O nouveaudriver usado para o Quadro K4200 também codifica o mesmo udelayvalor para o módulo i2c-algo-bit, na nvkm_i2c_bus_ctorfunção em nouveau/nvkm/subdev/i2c/bus.c

O padrão DDC determina que o hardware deve suportar uma taxa de clock de 100 kHz e que somente a placa gráfica pode ser o mestre (de clock) do barramento I²C. Portanto, seu dispositivo precisa ser capaz de operar em qualquer velocidade de 100 kHz ou menos, incluindo funções I²C complexas, como o alongamento de clock. (Nunca implemente I²C em software. Se o seu microcontrolador não tiver periféricos I²C, use um microcontrolador diferente ou um barramento diferente.)

Se me permite um conselho:

Não .

Eu costumava dar suporte técnico para um dispositivo embarcado que tinha suas próprias EEPROMs no mesmo barramento I²C que também era usado para o cabeçalho mini-HDMI que ele tinha na frente.

Às vezes (como em: vários clientes independentes meus) usar a interface gráfica do usuário enquanto o backend de hardware estava consultando propriedades de hardware das EEPROMs internas fazia com que as EEPROMs interpretassem incorretamente as respostas da memória de tela contendo EDID como comandos de gravação, devido à colisão de tempo das interações de barramento.

E isso acontecia com dispositivos especializados, onde essas transações de barramento não aconteciam mais de uma vez por minuto, talvez. Extrapole para quantas transações seu controlador gerará e qual a probabilidade de você entrar em conflito com a função real do DDC e fazer com que o usuário tenha um dia realmente ruim.

Os drivers de placas de vídeo geralmente apenas bitbang os barramentos I²C e não conseguem reconhecer transações de múltiplas transferências no barramento I²C.

Não tente pendurar um controle de jogo fora da interface da tela. Isso só vai acabar em lágrimas, requer privilégios muito questionáveis ​​para qualquer software que precise interagir com o controle, e adaptadores I²C para USB custam menos de 2€, mesmo nos distribuidores de eletrônicos mais caros, porém confiáveis ; de jeito nenhum o seu "compro um conector de vídeo, encontro uma porta de placa de vídeo não utilizada ou monto um dispositivo de passagem que ainda funciona, embora os sinais de vídeo sejam extremamente sensíveis e tenham largura de banda extremamente alta" chega perto do custo disso.

Se você estiver construindo um controle de jogo para um console dos anos 1980, talvez considere os barramentos específicos que esses consoles tinham – de qualquer forma, você estaria escrevendo um software de baixo nível muito personalizado para eles.

Mais realisticamente, basta fazer o microcontrolador do seu controle de jogo personalizado falar diretamente com USB. A classe Dispositivo de Interface Humana é praticamente a coisa mais simples que você pode implementar em USB. Todas as famílias de microcontroladores relevantes que você usaria para qualquer coisa que não seja produzida aos milhões ou que precise persistir em microwatts contêm membros com hardware USB integrado. Literalmente, qualquer microcontrolador tem uma interface UART; se precisar de algo, você pode conectá-lo à parte traseira do seu PC IBM original.