Hey Ricardo,
On 11-05-16 23:38, Ricardo Ribalda Delgado wrote:
Some update
I have not received anything to test it and I will be out of the
office from today until the 30th :S. So it seems that I have not way
to test the changes.
That's understandable, meanwhile I've been running some
Hey Ricardo,
On 11-05-16 23:38, Ricardo Ribalda Delgado wrote:
Some update
I have not received anything to test it and I will be out of the
office from today until the 30th :S. So it seems that I have not way
to test the changes.
That's understandable, meanwhile I've been running some
Hey Ricardo,
On 11-05-16 23:38, Ricardo Ribalda Delgado wrote:
Some update
I have not received anything to test it and I will be out of the
office from today until the 30th :S. So it seems that I have not way
to test the changes.
That's understandable, meanwhile I've been running some
Hey Ricardo,
On 11-05-16 23:38, Ricardo Ribalda Delgado wrote:
Some update
I have not received anything to test it and I will be out of the
office from today until the 30th :S. So it seems that I have not way
to test the changes.
That's understandable, meanwhile I've been running some
Hi Ricardo,
On 20-04-16 11:17, Ricardo Ribalda Delgado wrote:
Hello again
On Wed, Apr 20, 2016 at 11:06 AM, Olliver Schinagl wrote:
The devil is in the details :)
:)
Saving mode2 sounds like a good compromise then.
But I still believe that we should limit the lock to
Hi Ricardo,
On 20-04-16 11:17, Ricardo Ribalda Delgado wrote:
Hello again
On Wed, Apr 20, 2016 at 11:06 AM, Olliver Schinagl wrote:
The devil is in the details :)
:)
Saving mode2 sounds like a good compromise then.
But I still believe that we should limit the lock to ledout. No matter
Hey,
On 20-04-16 11:17, Ricardo Ribalda Delgado wrote:
Hello again
On Wed, Apr 20, 2016 at 11:06 AM, Olliver Schinagl wrote:
The devil is in the details :)
:)
Saving mode2 sounds like a good compromise then.
But I still believe that we should limit the lock to ledout.
Hey,
On 20-04-16 11:17, Ricardo Ribalda Delgado wrote:
Hello again
On Wed, Apr 20, 2016 at 11:06 AM, Olliver Schinagl wrote:
The devil is in the details :)
:)
Saving mode2 sounds like a good compromise then.
But I still believe that we should limit the lock to ledout. No matter
what we
Hello again
On Wed, Apr 20, 2016 at 11:06 AM, Olliver Schinagl wrote:
> The devil is in the details :)
:)
>>
>> Saving mode2 sounds like a good compromise then.
>>
>> But I still believe that we should limit the lock to ledout. No matter
>> what we do, we cannot have two
Hello again
On Wed, Apr 20, 2016 at 11:06 AM, Olliver Schinagl wrote:
> The devil is in the details :)
:)
>>
>> Saving mode2 sounds like a good compromise then.
>>
>> But I still believe that we should limit the lock to ledout. No matter
>> what we do, we cannot have two leds blinking at
On 20-04-16 10:56, Ricardo Ribalda Delgado wrote:
Hi
On Wed, Apr 20, 2016 at 10:51 AM, Olliver Schinagl wrote:
As I said before, the reason for this proposal is that the code NEVER
clears PCA963X_MODE2_DMBLNK, only sets it.
Unfortunately I do not have the HW to test
On 20-04-16 10:56, Ricardo Ribalda Delgado wrote:
Hi
On Wed, Apr 20, 2016 at 10:51 AM, Olliver Schinagl wrote:
As I said before, the reason for this proposal is that the code NEVER
clears PCA963X_MODE2_DMBLNK, only sets it.
Unfortunately I do not have the HW to test this change.
The code
Hi
On Wed, Apr 20, 2016 at 10:51 AM, Olliver Schinagl wrote:
>> As I said before, the reason for this proposal is that the code NEVER
>> clears PCA963X_MODE2_DMBLNK, only sets it.
>> Unfortunately I do not have the HW to test this change.
>
> The code never clears it, but
Hi
On Wed, Apr 20, 2016 at 10:51 AM, Olliver Schinagl wrote:
>> As I said before, the reason for this proposal is that the code NEVER
>> clears PCA963X_MODE2_DMBLNK, only sets it.
>> Unfortunately I do not have the HW to test this change.
>
> The code never clears it, but the hardware does. So
Hey Ricardo,
On 20-04-16 10:01, Ricardo Ribalda Delgado wrote:
Hi Ollivier
On Wed, Apr 20, 2016 at 9:21 AM, Olliver Schinagl wrote:
What I am propossing is at probe():
replace:
if (pdata) {
/* Configure output: open-drain or totem pole (push-pull) */
if (pdata->outdrv
Hey Ricardo,
On 20-04-16 10:01, Ricardo Ribalda Delgado wrote:
Hi Ollivier
On Wed, Apr 20, 2016 at 9:21 AM, Olliver Schinagl wrote:
What I am propossing is at probe():
replace:
if (pdata) {
/* Configure output: open-drain or totem pole (push-pull) */
if (pdata->outdrv ==
Hi Ollivier
On Wed, Apr 20, 2016 at 9:21 AM, Olliver Schinagl wrote:
What I am propossing is at probe():
replace:
if (pdata) {
/* Configure output: open-drain or totem pole (push-pull) */
if (pdata->outdrv == PCA963X_OPEN_DRAIN)
i2c_smbus_write_byte_data(client,
Hi Ollivier
On Wed, Apr 20, 2016 at 9:21 AM, Olliver Schinagl wrote:
What I am propossing is at probe():
replace:
if (pdata) {
/* Configure output: open-drain or totem pole (push-pull) */
if (pdata->outdrv == PCA963X_OPEN_DRAIN)
i2c_smbus_write_byte_data(client, PCA963X_MODE2, 0x01);
else
Hey Ricardo,
On 19-04-16 15:42, Ricardo Ribalda Delgado wrote:
Hi again
On Tue, Apr 19, 2016 at 3:27 PM, Olliver Schinagl wrote:
Hey Ricardo,
Without actually looking at the code right now, but the driver does a
read/modify/write on the register, and a register is shared
Hey Ricardo,
On 19-04-16 15:42, Ricardo Ribalda Delgado wrote:
Hi again
On Tue, Apr 19, 2016 at 3:27 PM, Olliver Schinagl wrote:
Hey Ricardo,
Without actually looking at the code right now, but the driver does a
read/modify/write on the register, and a register is shared among several
leds.
Hi again
On Tue, Apr 19, 2016 at 3:27 PM, Olliver Schinagl wrote:
> Hey Ricardo,
> Without actually looking at the code right now, but the driver does a
> read/modify/write on the register, and a register is shared among several
> leds. So in that regard, it makes sense and
Hi again
On Tue, Apr 19, 2016 at 3:27 PM, Olliver Schinagl wrote:
> Hey Ricardo,
> Without actually looking at the code right now, but the driver does a
> read/modify/write on the register, and a register is shared among several
> leds. So in that regard, it makes sense and I don't think it's
Hey Ricardo,
On 19-04-16 13:18, Ricardo Ribalda Delgado wrote:
Hi Ollivier
Sorry to not reply to the patches, but I am not subscribed to linux-leds
Regarding:
[PATCH 2/6] leds: pca963x: Lock i2c r/w access
I am not sure why this patch is needed. the only thing that should be
protected is the
Hey Ricardo,
On 19-04-16 13:18, Ricardo Ribalda Delgado wrote:
Hi Ollivier
Sorry to not reply to the patches, but I am not subscribed to linux-leds
Regarding:
[PATCH 2/6] leds: pca963x: Lock i2c r/w access
I am not sure why this patch is needed. the only thing that should be
protected is the
Hi Ollivier
Sorry to not reply to the patches, but I am not subscribed to linux-leds
Regarding:
[PATCH 2/6] leds: pca963x: Lock i2c r/w access
I am not sure why this patch is needed. the only thing that should be
protected is the write to ledout.
It seems that mode2 needs to be set to
Hi Ollivier
Sorry to not reply to the patches, but I am not subscribed to linux-leds
Regarding:
[PATCH 2/6] leds: pca963x: Lock i2c r/w access
I am not sure why this patch is needed. the only thing that should be
protected is the write to ledout.
It seems that mode2 needs to be set to
On 19-04-16 11:23, Jacek Anaszewski wrote:
Hi Olliver,
Thanks for the patches.
Adding driver authors on cc.
Ah sorry about that, thanks. I guess get_maintainers doesn't do that.
As for the compile bug, I'll fix that with v2, it only applies on the
intermediate patches, not on the whole set.
On 19-04-16 11:23, Jacek Anaszewski wrote:
Hi Olliver,
Thanks for the patches.
Adding driver authors on cc.
Ah sorry about that, thanks. I guess get_maintainers doesn't do that.
As for the compile bug, I'll fix that with v2, it only applies on the
intermediate patches, not on the whole set.
Hi Olliver,
Thanks for the patches.
Adding driver authors on cc.
On 04/19/2016 09:40 AM, Olliver Schinagl wrote:
Using the pca963x for a while, I noticed something that may look like some
i2c accessing issues where sometimes data was incorrectly written to the bus,
possibly because we where
Hi Olliver,
Thanks for the patches.
Adding driver authors on cc.
On 04/19/2016 09:40 AM, Olliver Schinagl wrote:
Using the pca963x for a while, I noticed something that may look like some
i2c accessing issues where sometimes data was incorrectly written to the bus,
possibly because we where
Using the pca963x for a while, I noticed something that may look like some
i2c accessing issues where sometimes data was incorrectly written to the bus,
possibly because we where not properly locking the i2c reads. Though I'm not
familiar enough with the i2c framework to be certain reads need to
Using the pca963x for a while, I noticed something that may look like some
i2c accessing issues where sometimes data was incorrectly written to the bus,
possibly because we where not properly locking the i2c reads. Though I'm not
familiar enough with the i2c framework to be certain reads need to
32 matches
Mail list logo