On Feb 28, 2014 11:15 AM, "Mauro Carvalho Chehab" wrote:
>
> Em Wed, 19 Feb 2014 17:39:07 -0800
> Andy Lutomirski escreveu:
>
> > On Wed, Feb 19, 2014 at 11:03 AM, Luck, Tony wrote:
> > >> (I'm c/c Tony here, as he also shared the same concern that I had on a
> > >> previous feedback about
Em Wed, 19 Feb 2014 17:39:07 -0800
Andy Lutomirski escreveu:
> On Wed, Feb 19, 2014 at 11:03 AM, Luck, Tony wrote:
> >> (I'm c/c Tony here, as he also shared the same concern that I had on a
> >> previous feedback about using I2C to talk with the DIMM).
> >
> > Correct - I've heard the same
Em Wed, 19 Feb 2014 17:39:07 -0800
Andy Lutomirski l...@amacapital.net escreveu:
On Wed, Feb 19, 2014 at 11:03 AM, Luck, Tony tony.l...@intel.com wrote:
(I'm c/c Tony here, as he also shared the same concern that I had on a
previous feedback about using I2C to talk with the DIMM).
On Feb 28, 2014 11:15 AM, Mauro Carvalho Chehab m.che...@samsung.com wrote:
Em Wed, 19 Feb 2014 17:39:07 -0800
Andy Lutomirski l...@amacapital.net escreveu:
On Wed, Feb 19, 2014 at 11:03 AM, Luck, Tony tony.l...@intel.com wrote:
(I'm c/c Tony here, as he also shared the same concern that
On Fri, Feb 21, 2014 at 7:32 AM, One Thousand Gnomes
wrote:
>> I'm suggesting identifying a range of addresses on a bus with a "port"
>> (or whatever it should be called). Multiple ports could claim
>> non-overlapping ranges on the same bus.
>
> Which is fine until you meant a mux or a device
On Fri, Feb 21, 2014 at 7:32 AM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
I'm suggesting identifying a range of addresses on a bus with a port
(or whatever it should be called). Multiple ports could claim
non-overlapping ranges on the same bus.
Which is fine until you meant a
> I'm suggesting identifying a range of addresses on a bus with a "port"
> (or whatever it should be called). Multiple ports could claim
> non-overlapping ranges on the same bus.
Which is fine until you meant a mux or a device that can be moved about
by writing to it, or has a wide range of
I'm suggesting identifying a range of addresses on a bus with a port
(or whatever it should be called). Multiple ports could claim
non-overlapping ranges on the same bus.
Which is fine until you meant a mux or a device that can be moved about
by writing to it, or has a wide range of addresses
On Thu, Feb 20, 2014 at 8:42 AM, Luck, Tony wrote:
>> NV-DIMM control registers are exposed via i2c, presumably because
>> trying to access them through the memory pins would be a giant mess.
>> So, one way or another, something needs to be able to initiate
>> transactions to access those
> NV-DIMM control registers are exposed via i2c, presumably because
> trying to access them through the memory pins would be a giant mess.
> So, one way or another, something needs to be able to initiate
> transactions to access those registers. BIOS will do some initial
> setup, but the OS will
NV-DIMM control registers are exposed via i2c, presumably because
trying to access them through the memory pins would be a giant mess.
So, one way or another, something needs to be able to initiate
transactions to access those registers. BIOS will do some initial
setup, but the OS will need
On Thu, Feb 20, 2014 at 8:42 AM, Luck, Tony tony.l...@intel.com wrote:
NV-DIMM control registers are exposed via i2c, presumably because
trying to access them through the memory pins would be a giant mess.
So, one way or another, something needs to be able to initiate
transactions to access
On Wed, Feb 19, 2014 at 11:03 AM, Luck, Tony wrote:
>> (I'm c/c Tony here, as he also shared the same concern that I had on a
>> previous feedback about using I2C to talk with the DIMM).
>
> Correct - I've heard the same issues that reads on I2C can be misinterpreted
> as writes ... and oops, you
On Wed, Feb 19, 2014 at 11:26 AM, One Thousand Gnomes
wrote:
>> example, lots of graphics drivers provide i2c busses, and those busses
>> often contain eeproms, and, in theory, things should know that the
>> eeprom is associated with a particular graphics port, for example.
>> Unfortunately, the
> example, lots of graphics drivers provide i2c busses, and those busses
> often contain eeproms, and, in theory, things should know that the
> eeprom is associated with a particular graphics port, for example.
> Unfortunately, the i2c core does not know that, things like
> decode-dimms will try
> (I'm c/c Tony here, as he also shared the same concern that I had on a
> previous feedback about using I2C to talk with the DIMM).
Correct - I've heard the same issues that reads on I2C can be misinterpreted
as writes ... and oops, you have a brick.
What is the larger context/ What problem
(I'm c/c Tony here, as he also shared the same concern that I had on a
previous feedback about using I2C to talk with the DIMM).
Em Wed, 19 Feb 2014 09:30:46 -0800
Andy Lutomirski escreveu:
> On Wed, Feb 19, 2014 at 7:16 AM, Wolfram Sang wrote:
> > On Fri, Dec 20, 2013 at 05:45:13PM -0800,
On Wed, Feb 19, 2014 at 7:16 AM, Wolfram Sang wrote:
> On Fri, Dec 20, 2013 at 05:45:13PM -0800, Andy Lutomirski wrote:
>> Add i2c_scan_dimm_bus to declare that a particular i2c_adapter
>> contains DIMMs. This will probe (and autoload modules!) for useful
>> SMBUS devices that live on DIMMs.
On Fri, Dec 20, 2013 at 05:45:13PM -0800, Andy Lutomirski wrote:
> Add i2c_scan_dimm_bus to declare that a particular i2c_adapter
> contains DIMMs. This will probe (and autoload modules!) for useful
> SMBUS devices that live on DIMMs. i2c_imc calls it.
Hmm, after thinking about it for a while
On Fri, Dec 20, 2013 at 05:45:13PM -0800, Andy Lutomirski wrote:
Add i2c_scan_dimm_bus to declare that a particular i2c_adapter
contains DIMMs. This will probe (and autoload modules!) for useful
SMBUS devices that live on DIMMs. i2c_imc calls it.
Hmm, after thinking about it for a while and
On Wed, Feb 19, 2014 at 7:16 AM, Wolfram Sang w...@the-dreams.de wrote:
On Fri, Dec 20, 2013 at 05:45:13PM -0800, Andy Lutomirski wrote:
Add i2c_scan_dimm_bus to declare that a particular i2c_adapter
contains DIMMs. This will probe (and autoload modules!) for useful
SMBUS devices that live on
(I'm c/c Tony here, as he also shared the same concern that I had on a
previous feedback about using I2C to talk with the DIMM).
Em Wed, 19 Feb 2014 09:30:46 -0800
Andy Lutomirski l...@amacapital.net escreveu:
On Wed, Feb 19, 2014 at 7:16 AM, Wolfram Sang w...@the-dreams.de wrote:
On Fri,
(I'm c/c Tony here, as he also shared the same concern that I had on a
previous feedback about using I2C to talk with the DIMM).
Correct - I've heard the same issues that reads on I2C can be misinterpreted
as writes ... and oops, you have a brick.
What is the larger context/ What problem are
example, lots of graphics drivers provide i2c busses, and those busses
often contain eeproms, and, in theory, things should know that the
eeprom is associated with a particular graphics port, for example.
Unfortunately, the i2c core does not know that, things like
decode-dimms will try to
On Wed, Feb 19, 2014 at 11:26 AM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
example, lots of graphics drivers provide i2c busses, and those busses
often contain eeproms, and, in theory, things should know that the
eeprom is associated with a particular graphics port, for example.
On Wed, Feb 19, 2014 at 11:03 AM, Luck, Tony tony.l...@intel.com wrote:
(I'm c/c Tony here, as he also shared the same concern that I had on a
previous feedback about using I2C to talk with the DIMM).
Correct - I've heard the same issues that reads on I2C can be misinterpreted
as writes ...
Add i2c_scan_dimm_bus to declare that a particular i2c_adapter
contains DIMMs. This will probe (and autoload modules!) for useful
SMBUS devices that live on DIMMs. i2c_imc calls it.
As more SMBUS-addressable DIMM components become supported, this
code can be extended to probe for them.
Add i2c_scan_dimm_bus to declare that a particular i2c_adapter
contains DIMMs. This will probe (and autoload modules!) for useful
SMBUS devices that live on DIMMs. i2c_imc calls it.
As more SMBUS-addressable DIMM components become supported, this
code can be extended to probe for them.
28 matches
Mail list logo
