Есть ли риск, что новый драйвер ядра ee1004 может заблокировать spd eeprom?

Я подозреваю, что вы имеете в виду не конкретную проблему с ОЗУ, SPD или "новыми EEPROM", а скорее двухпроводную шину, которая используется для связи с этими EEPROM.

I²C и SMBus - очень похожие шины и "посуществу совместимы".

Я могу только думать, что блокировка, на которую вы ссылаетесь, связана с тем, что шина не возвращается в режим ожидания после транзакции, что вполне возможно для этих шин из-за их архитектуры - то есть: открытый сток с подтягиванием.

Из-за того, как работают шины, каждый из сигналов синхронизации (SCL) или данных (SDA) может находиться в одном из двух состояний:

1. Высокий / Логический 1 - все устройства устанавливают свой соответствующий вывод на Hi-Z (высокий импеданс / отсутствие тока или источника тока), что позволяет подтягивающим резисторам повышать уровень сигнала.
2. Low / Logic 0 - одно или несколько устройств могут потреблять ток, чтобы вывести соответствующий сигнал на низкий уровень.

Первоначально мастер будет управлять шиной, управляя тактовой частотой и линиями передачи данных на низком уровне для обращения к подчиненному устройству. Затем ведомое устройство подтвердит адресацию, подтвердив строку данных. Для запроса на чтение мастер продолжит переключать часы, чтобы подчиненный мог ответить:

Ведущий и ведомый по очереди утверждают сигналы для передачи данных между собой. Как только транзакция завершена, шина возвращается в состояние "ожидания", где оба сигнала являются "высокими".

Проблемы могут возникнуть по ряду причин, например:

• "Растяжение часов" - когда подчиненное устройство может на законных основаниях запрашивать больше времени для обработки запроса, продолжая утверждать тактовый сигнал (SCL) после того, как мастер его отпустил... но ненадлежащее устройство могло продолжать утверждать SCL еще долго после него. Предназначен для.
• "Ошибки связи" - когда ведомый, возможно, не соблюдает правильное количество тактов и остается в активном состоянии, продолжая утверждать шину.

Это то, где I²C и SMBus различаются - принципиально, SMBus указывает таймауты, а I²C - нет. Это означает, что SMBus более устойчив к ошибкам связи или другим проблемам, которые могут привести к блокировке шины.

Тайм-аут SMBus указывается в виде "минимальной тактовой частоты" - если SCL установлен более 35 мс, ведомое устройство должно сбросить свой интерфейс, вернув выводы SCL и SDA в Hi-Z.

Похоже, что N34C04, для которого вы привязали таблицу данных, будет соблюдать спецификации тайм-аута SMBus, оставаясь при этом совместимым и с шинами I²C.

Проблема с блокировками, вероятно, будет связана с системами, где на шине есть устройство I²C, котороене наблюдает тайм-ауты шины SMBus, и где происходит повреждение или неправильная работа устройства... Устройство может быть датчиком температуры, EEPROM, или целое множество других устройств, присутствующих в модуле RAM, на материнской плате или в другом месте полностью.

Драйвер, с которым вы связались( ee1004.c), также прямо заявляет, что:

Мы используем доступ SMBus, даже если I2C доступен, эти EEPROM достаточно малы, и чтение с них происходит достаточно редко, поэтому мы предпочитаем простоту, а не производительность.

Хотя помните, что это потенциально подчиненные устройства, которые могут привести к блокировке шины.

Кто-нибудь знает более подробную информацию о рисках блокировки I2C для новых EDRROM DDR4? (временный или постоянный отказ в изменении конфигурации?)

Также важно отметить, что SPD обычно считается только для чтения, и изменение содержимого может вызвать серьезные проблемы, если вы не знаете, что делаете.

Постоянные проблемы маловероятны, и цикл питания должен очистить шину, если проблема все же произойдет, хотя вряд ли.

Есть ли риск, что новый драйвер ядра ee1004 может заблокировать SPD EEPROM?

Я бы предположил, что это очень маловероятно... как упоминалось выше, ведомое устройство с большей вероятностью вызовет блокировку, чем новый драйвер (который действует как мастер SMBus).