This device contains both master and slave controllers which can be
enabled simultaneously. Both controllers share the same SDA/SCL lines
and interrupt source but has separate control and status registers.
Controllers also works in loopback mode - slave device can communicate
with its own master co
This device contains both master and slave controllers which can be
enabled simultaneously. Both controllers share the same SDA/SCL lines
and interrupt source but has separate control and status registers.
Controllers also works in loopback mode - slave device can communicate
with its own master co
Hi Wolfram,
>Hi Krzysztof,
>
>> +if (fifo_status & SLV_FIFO_DV1) {
>> +if (fifo_status & SLV_FIFO_STRC) {
>> +dev_dbg(dev, "First data byte sent\n");
>
>I think, however, these debug messages could go. They were surely
>helpful during development but assuming th
This device contains both master and slave controllers which can be
enabled simultaneously. Both controllers share the same SDA/SCL lines
and interrupt source but has separate control and status registers.
Controllers also works in loopback mode - slave device can communicate
with its own master co
On Sat, Jun 08, 2019 at 12:32:18AM +0200, Wolfram Sang wrote:
>On Tue, May 28, 2019 at 09:08:21AM +0000, Adamski, Krzysztof (Nokia -
>PL/Wroclaw) wrote:
>> The operation done in the pmbus_update_fan() function is a
>> read-modify-write operation but it lacks any kind of lock p
The operation done in the pmbus_update_fan() function is a
read-modify-write operation but it lacks any kind of lock protection
which may cause problems if run more than once simultaneously. This
patch uses an existing update_lock mutex to fix this problem.
Signed-off-by: Krzysztof Adamski
---
d
On Fri, Apr 12, 2019 at 01:40:56PM +0200, Enrico Weigelt, metux IT consult
wrote:
>On 12.04.19 09:30, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote:
>
>> Well, that depends. If the program doing those writes expects /dev/console
>> to be a tty device, then it cannot be any fil
On Fri, Apr 12, 2019 at 09:17:28AM +0200, Enrico Weigelt, metux IT consult
wrote:
>On 11.04.19 15:05, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote:
>
>> There are (embedded) cases where the kernel ring buffer is stored for> log
>> inspection and all the logs that are *no
On Fri, Apr 05, 2019 at 02:32:41PM +0200, Enrico Weigelt, metux IT consult
wrote:
>On 05.04.19 11:00, Vincent Whitchurch wrote:
>> On Fri, Apr 05, 2019 at 10:39:43AM +0200, Enrico Weigelt, metux IT consult
>> wrote:
>>> On 03.04.19 16:11, Vincent Whitchurch wrote:
>>>
Especially on embedded
On Wed, Apr 03, 2019 at 10:54:02PM +0200, Wolfram Sang wrote:
>Hi,
>
>On Thu, Mar 28, 2019 at 11:19:45AM +, Adamski, Krzysztof (Nokia -
>PL/Wroclaw) wrote:
>> Some recent commits to this driver were trying to make sure the TSS
>> interrupt is not generated on busy
Some recent commits to this driver were trying to make sure the TSS
interrupt is not generated on busy system due to 25ms timer expiring
between commands. It can still happen, however if STOP command is not
issued on time at the end of the transmission. If wait_for_completion in
axxia_i2c_xfer_msg(
In order to comply with SMBus specification, the Axxia I²C module will
abort the multi message transfer if the delay between finishing sending
one message and starting another is longer than 25ms. Unfortunately it
isn't that hard to trigger this situation on a busy system. In order to
fix this prob
Create separate entry for i2c-axxia and set myself as maintainer.
Even though I don't work for Intel/LSI who is the manufacturer of this
IP, I do have access to some documentation and the actual hardware using
this driver and I'm familiar with the code.
Signed-off-by: Krzysztof Adamski
---
MAIN
In order to comply with SMBus specification, the Axxia I²C module will
abort the multi message transfer if the delay between finishing sending
one message and starting another is longer than 25ms. Unfortunately it
isn't that hard to trigger this situation on a busy system. In order to
fix this prob
It was observed that when using seqentional mode contrary to the
documentation, the SS bit (which is supposed to only be set if
automatic/sequence command completed normally), is sometimes set
together with NA (NAK in address phase) causing transfer to falsely be
considered successful.
My assumpti
This patch moves configuration of hardware registers used for setting
i2c client address to separate function. It is preparatory change for
next commit.
Signed-off-by: Krzysztof Adamski
---
drivers/i2c/busses/i2c-axxia.c | 29 ++---
1 file changed, 18 insertions(+), 11 de
Hi Woflram,
This patch was based on your i2c/for-current branch as it adds to my
patch you incuded there. First two patches are just preparations and the
3rd one which is the actual change. It allows us using hardware mode to
send i2c transfers consisting for a write followed by read without the
n
Hi
W dniu 27.11.2018 o 13:26, Wolfram Sang pisze:
> On Fri, Nov 16, 2018 at 01:24:41PM +0000, Adamski, Krzysztof (Nokia -
> PL/Wroclaw) wrote:
>> According to Intel (R) Axxia TM Lionfish Communication Processor
>> Peripheral Subsystem Hardware Reference Manual, the AXXIA I2
According to Intel (R) Axxia TM Lionfish Communication Processor
Peripheral Subsystem Hardware Reference Manual, the AXXIA I2C module
have a programmable Master Wait Timer, which among others, checks the
time between commands send in manual mode. When a timeout (25ms) passes,
TSS bit is set in Mast
19 matches
Mail list logo
