[U-Boot] [PATCH v2] i2c: intel_i2c: SMBus driver PCI addition (e.g. BayTrail)

[Heiko Schocher <hs@denx.de>]

Hello Simon, Stefan,

Am 16.08.2016 um 06:50 schrieb Simon Glass:
> Hi Stefan,
>
> On 15 August 2016 at 04:02, Stefan Roese <sr@denx.de> wrote:
>> Hi Simon,
>>
>>
>> On 10.08.2016 04:59, Simon Glass wrote:
>>>
>>> On 8 August 2016 at 23:41, Stefan Roese <sr@denx.de> wrote:
>>>>
>>>> This patch adds support for the SMBus block read/write functionality.
>>>> Other protocols like the SMBus quick command need to get added
>>>> if this is needed.
>>>>
>>>> This patch also removed the SMBus related defines from the Ivybridge
>>>> pch.h header. As they are integrated in this driver and should be
>>>> used from here. This change is added in this patch to avoid compile
>>>> breakage to keep the source git bisectable.
>>>>
>>>> Tested on a congatec BayTrail board to configure the SMSC2513 USB
>>>> hub.
>>>>
>>>> Signed-off-by: Stefan Roese <sr@denx.de>
>>>> Cc: Bin Meng <bmeng.cn@gmail.com>
>>>> Cc: Simon Glass <sjg@chromium.org>
>>>> Cc: Heiko Schocher <hs@denx.de>
>>>> Cc: George McCollister <george.mccollister@gmail.com>
>>>> ---
>>>> v2:
>>>> - Avoid using BSS. Patch from Simon intergrated to fix problem before
>>>>    relocation.
>>>> - Remove IvyBridge code and add PCI device for IvyBridge (Panther Point
>>>>    PCH).
>>>> - Add overrun check to smbus_block_read() as suggested by George
>>>>
>>>>   arch/x86/include/asm/arch-ivybridge/pch.h |  26 ---
>>>>   drivers/i2c/intel_i2c.c                   | 290
>>>> +++++++++++++++++++++++++++---
>>>>   2 files changed, 269 insertions(+), 47 deletions(-)
>>>>
>>>
>>> This does not crash, but I see nothing on the bus with 'i2c dev 0; i2c
>>> probe'. Is that expected?
>>
>>
>> This depends on the devices available on the I2C bus. As SMBus defines
>> multiples protocols (byte read/write, block read/write...), and your
>> I2C devices probably don't support the currently implemented block
>> read/write protocol, we need to find a way configure / switch the SMBus
>> protocol. Do you have an idea on how to do this? Perhaps we need to add
>> a config call for this to switch between the different protocols? And
>> also add a way to do this from the cmdline. Perhaps "i2c flags" can be
>> used for this?
>
> Yes I suppose a flag is the best idea. You should be able to add one
> to the existing flags. Then it can be configured from the device or
> via the command line 'i2c flags'.

Yes, an "i2c flag" seems a good solution.

Hmm.. thinking about it ...

May we need such a functionality like in linux:/include/uapi/linux/i2c.h
I2C_FUNC_* and i2c_check_functionality() ?

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany