Re: [PATCH] i2c: pxa: enable high speed mode for i2c bus
Hi All
Would you please help to look at this patch?
Thanks!
2013/7/22 James Lebron :
> Hi Guys
>
> Any comments?
>
> 2013/7/11 James Lebron :
>> Hi all
>>
>> I am still waiting for your response.
>>
>> 2013/7/5 James Lebron :
>>> Hi guys,
>>>
>>> Any comments?
>>>
>>> 2013/7/2 James Lebron :
Hi Wolfram
Have you finished reading datasheet?
2013/6/15 Wolfram Sang :
> Hi,
>
> On Fri, Jun 07, 2013 at 02:38:17PM +0800, Leilei Shang wrote:
>> To enter high speed mode, following steps should be done:
>> 1. When running in high speed mode, i2c clock rate is different
>> from standard mode. Clock rate must be set according to
>> specification first.
>> 2. When i2c controller sends a master code and wins arbitration,
>> high speed mode is entered.
>>
>> If you want to enable high speed mode, the following members of
>> platform data should be set to proper value:
>
> I couldn't find any support for hs-mode in pxa2xx and pxa3xx. So it
> shouldn't be set in platform data, but depending on checks if this is
> supported on this device at all. And why don't simply switch to it if
> rate is bigger than what is supported without hs-mode?
>
1. High speed mode is hardware feature, you can't read it from
software. It's similar to fast mode, and fast mode is set in platform
data.
The only method I can think of is to add a platform, like pxa910.
And if you enable hs mode and platform is not pxa910, we'll set it to
normal mode. Is this OK?
2. About hs mode clock setting. We don't know whether currently hs
mode clock will be changed in future. Do you think below code is OK?
if (i2c->rate)
clk_set_rate(i2c->clk, i2c->rate);
else
clk_set_rate(i2c->clk, 6240);
pr_info("i2c: <%s> set rate to %ld\n",
i2c->adap.name, clk_get_rate(i2c->clk));
>> 1. "high_mode" should be set to "1".
>> 2. "master_code" should be set to "8'b _1xxx"(x is 0 or 1).
>>If no master_code is set, set to default value 0xe.
>> 3. "rate" should be set according to specification.
>
> Note that you should fall back to full-speed mode after sending the stop
> bit in high-speed mode. I can't find this in the code?
>
3. Will fall back to normal mode when stop bit is sent.
>>
>> Signed-off-by: Leilei Shang
>
> Which SoC supports this? I'd like to have a look at the datasheet.
>
> Thanks,
>
>Wolfram
>
Hope you can reply soon!
Best regards
Leilei
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PC to PC link via i2c on nvidia (VGA) cards. Is it possible in theory?
Hello, linux-i2c! I have a toy project that requires connection of two PC computers. I want to abuse DDC pins on VGA cards to send/receive data via i2c. What do you think, Is it really possible? I have read that linux computer can only be a i2c master, will it be a problem for the task? Of course, I am teaching myself i2c at the moment. But any advice or directions will be really appreciated. Thank you! -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] i2c_imc: New driver for Intel's iMC, found on LGA2011 chips
On Thu, Jul 18, 2013 at 3:40 PM, Guenter Roeck wrote: > On Thu, Jul 18, 2013 at 02:37:40PM -0700, Andy Lutomirski wrote: >> On Thu, Jul 18, 2013 at 2:33 PM, Guenter Roeck wrote: >> > On Thu, Jul 18, 2013 at 11:36:54AM -0700, Andy Lutomirski wrote: >> >> Sandy Bridge Xeon and Extreme chips have integrated memory controllers >> >> with (rather limited) onboard SMBUS masters. This driver gives access >> >> to the bus. >> >> >> >> Signed-off-by: Andy Lutomirski >> >> --- >> >> drivers/i2c/busses/Kconfig | 15 ++ >> >> drivers/i2c/busses/Makefile | 1 + >> >> drivers/i2c/busses/i2c-imc.c | 548 >> >> +++ >> >> 3 files changed, 564 insertions(+) >> >> create mode 100644 drivers/i2c/busses/i2c-imc.c >> >> >> >> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig >> >> index e837f0e..7636782 100644 >> >> --- a/drivers/i2c/busses/Kconfig >> >> +++ b/drivers/i2c/busses/Kconfig >> >> @@ -137,6 +137,21 @@ config I2C_DIMM_BUS >> >> tristate >> >> default n >> >> >> >> +config I2C_IMC >> >> + tristate "Intel iMC (LGA 2011) SMBus Controller" >> >> + depends on PCI && X86 >> >> + select I2C_DIMM_BUS >> >> + help >> >> + If you say yes to this option, support will be included for the >> >> Intel >> >> + Integrated Memory Controller SMBus host controller interface. >> >> This >> >> + controller is found on LGA 2011 Xeons and Core i7 Extremes. >> >> + >> >> + It is possibly, although unlikely, that the use of this driver >> >> will >> >> + interfere with your platform's RAM thermal management. >> >> + >> >> + This driver can also be built as a module. If so, the module >> >> will be >> >> + called i2c-imc. >> >> + >> >> config I2C_PIIX4 >> >> tristate "Intel PIIX4 and compatible >> >> (ATI/AMD/Serverworks/Broadcom/SMSC)" >> >> depends on PCI >> >> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile >> >> index 226bb2e..790b63d 100644 >> >> --- a/drivers/i2c/busses/Makefile >> >> +++ b/drivers/i2c/busses/Makefile >> >> @@ -15,6 +15,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o >> >> obj-$(CONFIG_I2C_I801) += i2c-i801.o >> >> obj-$(CONFIG_I2C_ISCH) += i2c-isch.o >> >> obj-$(CONFIG_I2C_ISMT) += i2c-ismt.o >> >> +obj-$(CONFIG_I2C_IMC)+= i2c-imc.o >> >> obj-$(CONFIG_I2C_NFORCE2)+= i2c-nforce2.o >> >> obj-$(CONFIG_I2C_NFORCE2_S4985) += i2c-nforce2-s4985.o >> >> obj-$(CONFIG_I2C_PIIX4) += i2c-piix4.o >> >> diff --git a/drivers/i2c/busses/i2c-imc.c b/drivers/i2c/busses/i2c-imc.c >> >> new file mode 100644 >> >> index 000..9643aeb >> >> --- /dev/null >> >> +++ b/drivers/i2c/busses/i2c-imc.c >> > >> > [ ... ] >> > >> >> + >> >> + i2c_scan_dimm_bus(&ch->adapter); >> >> + >> > Wonder if this should (can) be part of the infrastructure, eg by >> > introducing >> > I2C_CLASS_DIMM. >> >> If so, it'll have to work differently than the current class bits. >> All they do is determine which drivers get detected, and that >> detection happens by completely generic means that's not really >> applicable to DIMMs (and doesn't work on this bus). >> > In i2c_detect_address: > > if (adap->class & I2C_CLASS_DIMM) > return i2c_detect_dimm(); > > > or in i2c_default_probe, call a dimm specific probe function and then > depend on the device detect functions (if that is possible). > > Sure, the i2c core code would have to change a bit to accomodate the new > I2C_CLASS_DIMM, but I personally would prefer that to calling > the detect function from the adapter driver. > > Personal preference, though; this ultimately depends on the i2c maintainers. > > Thanks, > Guenter Jean? I have some driver changes pending for v5, but I'd like to nail down whether the current scanning approach is acceptable first. Thanks, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/27] drivers/i2c/busses: don't check resource with devm_ioremap_resource
On Tue, Jul 23, 2013 at 8:01 PM, Wolfram Sang wrote: > devm_ioremap_resource does sanity checks on the given resource. No need to > duplicate this in the driver. > > Signed-off-by: Wolfram Sang > --- > Please apply via the subsystem-tree. Are you talking to yourself ;-) Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
