.
Signed-off-by: Michal Vokáč
---
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
index 51972c85e207..111d4d331f98 100644
--- a/arch/arm/boot/dts/imx6dl-yapp4
stead of
PHYLIB"). That commit revealed the FEC configuration was not correct.
Fixes: 87489ec3a77f ("ARM: dts: imx: Add Y Soft IOTA Draco, Hydra and Ursa
boards")
Cc: sta...@vger.kernel.org
Signed-off-by: Michal Vokáč
---
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 6 +
On 24. 07. 20 22:22, Rodrigo Alencar wrote:
This patch provides support for displays like VGM128064B0W10,
which requires a column offset of 2, i.e., its segments starts
in SEG2 and ends in SEG129.
Signed-off-by: Rodrigo Alencar <455.rodrigo.alen...@gmail.com>
Hi Bartlomiej,
what is the status
different configuration (mirror + segment offset). We want to support
both display types so it does no matter which one was used on the assembly
line. Hence the displays are placed at different I2C addresses.
Signed-off-by: Michal Vokáč
---
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 15
Add devicetree binding for Orion - new board variant in the Y Soft
IOTA family.
Signed-off-by: Michal Vokáč
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentation/devicetree/bindings
Add devicetree for new variant of the Y Soft IOT appliance.
The board is based on Hydra with the following changes:
- faster SoC (1GHz), 4GB RAM and 64GB eMMC
- removed miniPCIe
- removed Audio jack
- removed uSD slot
- removed RJ10 serial
- HDMI replaced by USB host
Signed-off-by: Michal
Add aliases for ethernet switch ports to allow bootloader to fix
MAC addresses to the ones stored in onboard configuration EEPROM.
Ursa has only one ethernet port populated (eth2) so alias for
the first port has to be removed on this board.
Signed-off-by: Michal Vokáč
---
arch/arm/boot/dts
K!
qca8k 2188000.ethernet-1:0a eth2 (uninitialized): PHY [2188000.ethernet-1:01]
driver [Generic PHY]
qca8k 2188000.ethernet-1:0a eth1 (uninitialized): PHY [2188000.ethernet-1:02]
driver [Generic PHY]
Fixes: 7e99e3470172 ("net: dsa: remove dsa_switch_alloc helper")
Cc:
Signed-
dst->cpu_dp and the dsa_switch_alloc helper.
I just tried the whole series on our imx6dl-yapp4-hydra with QCA8334
switch and did not notice any problems as well. Thank you.
Tested-by: Michal Vokáč
imx6dl-yapp4 Draco and Ursa boards use the I2C3 bus to control some
external devices through the /dev files.
So enable the I2C3 bus on all board variants, not just on Hydra.
Signed-off-by: Michal Vokáč
---
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 2 +-
arch/arm/boot/dts/imx6dl-yapp4
The second UART is needed for 3D or MFD printer control.
Signed-off-by: Michal Vokáč
---
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
index
. When I change the poll interval from sysfs, the new
value is correctly reported.
Tested-by: Michal Vokáč
---
drivers/input/input-poller.c | 9 +
include/linux/input.h| 1 +
2 files changed, 10 insertions(+)
On 01. 10. 19 1:08, Dmitry Torokhov wrote:
On Tue, Sep 24, 2019 at 05:02:11PM +0800, Anson Huang wrote:
Add helper variable dev = >dev to simply the code.
Do we get any code savings from this?
I noticed Anson submitted similar patches into various other subsystems.
Here [1] is a very
On 26. 09. 19 10:59, Michal Vokáč wrote:
The QCA8K family supports up to 7 ports. So use the existing
QCA8K_NUM_PORTS define to allocate the switch structure and limit all
operations with the switch ports.
This was not an issue until commit 0394a63acfe2 ("net: dsa: enable and
disable all
394a63acfe2 ("net: dsa: enable and disable all ports")
Signed-off-by: Michal Vokáč
---
I am not sure which of the fixes tags should be used but this definetelly
fixes something..
IMHO the 0394a63acfe2 ("net: dsa: enable and disable all ports") did not
cause the issue but made it v
s this ready to land?
Little bit OT question: what tree/branch do you use to apply patches?
According to the mailing list you recently applied some patches but
I can not find them here [1].
Thank you,
Michal
[1] https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/
Tested-by: Mich
On 14. 08. 19 11:23, Uwe Kleine-König wrote:
Hello Baolin,
On Wed, Aug 14, 2019 at 04:42:28PM +0800, Baolin Wang wrote:
On Tue, 13 Aug 2019 at 23:16, Uwe Kleine-König
wrote:
On Tue, Aug 13, 2019 at 09:46:41PM +0800, Baolin Wang wrote:
[...]
Not really, our hardware's method is, when you
On 07. 08. 19 10:26, Philippe Schenker wrote:
From: Oleksandr Suvorov
- add recovery mode for applicable i2c buses for
Colibri iMX7 module.
Signed-off-by: Oleksandr Suvorov
Signed-off-by: Philippe Schenker
---
Hi Philippe,
since you are going to send v4 anyway I suggest you update the
On 02. 08. 19 1:49, Dmitry Torokhov wrote:
On Tue, Jul 30, 2019 at 11:25:49AM +0200, Michal Vokáč wrote:
On 27. 07. 19 9:31, Dmitry Torokhov wrote:
On Fri, Jul 26, 2019 at 01:31:31PM +0200, Michal Vokáč wrote:
On 25. 07. 19 16:40, Dmitry Torokhov wrote:
On Thu, Jul 25, 2019 at 02:58:02PM
On 30. 07. 19 16:46, Philippe Schenker wrote:
From: Philippe Schenker
This patch prepares the devicetree for the new Ixora V1.2 where we are
able to turn off the supply of the can transceiver. This implies to use
a sleep state on transmission pins in order to prevent backfeeding.
On 30. 07. 19 16:46, Philippe Schenker wrote:
From: Philippe Schenker
This patch adds some missing pinmuxing that is in the colibri
standard to the dts.
Signed-off-by: Philippe Schenker
---
"ARM: dts: imx6-colibri: " in the subject for consistency.
Same for the Apalis, please.
Michal
On 31. 07. 19 8:43, Philippe Schenker wrote:
On Tue, 2019-07-30 at 17:46 -0300, Fabio Estevam wrote:
On Tue, Jul 30, 2019 at 11:57 AM Philippe Schenker wrote:
+ /* Atmel maxtouch controller */
+ atmel_mxt_ts: atmel_mxt_ts@4a {
Generic node names, please:
touchscreen@4a
+
On 27. 07. 19 9:31, Dmitry Torokhov wrote:
On Fri, Jul 26, 2019 at 01:31:31PM +0200, Michal Vokáč wrote:
On 25. 07. 19 16:40, Dmitry Torokhov wrote:
On Thu, Jul 25, 2019 at 02:58:02PM +0200, Michal Vokáč wrote:
On 25. 07. 19 10:57, Dmitry Torokhov wrote:
Hi Michal,
On Tue, May 21, 2019
On 25. 07. 19 16:40, Dmitry Torokhov wrote:
On Thu, Jul 25, 2019 at 02:58:02PM +0200, Michal Vokáč wrote:
On 25. 07. 19 10:57, Dmitry Torokhov wrote:
Hi Michal,
On Tue, May 21, 2019 at 08:51:17AM +0200, Michal Vokáč wrote:
On 21. 05. 19 7:37, Dmitry Torokhov wrote:
Hi Michal,
On Fri, May
On 25. 07. 19 10:57, Dmitry Torokhov wrote:
Hi Michal,
On Tue, May 21, 2019 at 08:51:17AM +0200, Michal Vokáč wrote:
On 21. 05. 19 7:37, Dmitry Torokhov wrote:
Hi Michal,
On Fri, May 17, 2019 at 03:12:49PM +0200, Michal Vokáč wrote:
Hi,
I have to deal with a situation where we have
On 14. 06. 19 0:39, Rob Herring wrote:
On Fri, May 17, 2019 at 03:12:50PM +0200, Michal Vokáč wrote:
Normally, the MPR121 controller uses separate interrupt line to notify
the I2C host that a key was touched/released. To support platforms that
can not use the interrupt line, polling
On 21. 05. 19 7:37, Dmitry Torokhov wrote:
Hi Michal,
On Fri, May 17, 2019 at 03:12:49PM +0200, Michal Vokáč wrote:
Hi,
I have to deal with a situation where we have a custom i.MX6 based
platform in production that uses the MPR121 touchkey controller.
Unfortunately the chip is connected using
Enable the I2C connected touch keypad on Hydra board.
Use the polled binding as the interrupt line is not available.
Signed-off-by: Michal Vokáč
---
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 12
arch/arm/boot/dts/imx6dl-yapp4-hydra.dts | 4
2 files changed, 16 insertions
one.
I will appreciate any comments. Thank you in advance,
Michal
Michal Vokáč (4):
dt-bindings: input: Add support for the MPR121 without interrupt line
Input: mpr121-polled: Add polling variant of the MPR121 touchkey
driver
Input: mpr121-polled: Add write-through cache to detect
counter limit is exceeded, the chip is re-initialized.
Signed-off-by: Michal Vokáč
---
drivers/input/keyboard/mpr121_touchkey_polled.c | 100 +---
1 file changed, 88 insertions(+), 12 deletions(-)
diff --git a/drivers/input/keyboard/mpr121_touchkey_polled.c
b/drivers/input
This driver is based on the original driver with interrupts. Polling
driver may be used in cases where the MPR121 chip is connected using
only the I2C interface and the interrupt line is not available.
Signed-off-by: Michal Vokáč
---
drivers/input/keyboard/Kconfig | 13
Normally, the MPR121 controller uses separate interrupt line to notify
the I2C host that a key was touched/released. To support platforms that
can not use the interrupt line, polling of the MPR121 registers can be
used.
Signed-off-by: Michal Vokáč
---
Changes since v1:
- Document the polled
On 02. 05. 19 2:48, Rob Herring wrote:
On Fri, Apr 26, 2019 at 10:30:17AM +0200, Michal Vokáč wrote:
Normally, the MPR121 controller uses separate interrupt line to notify
the I2C host that a key was touched/released. To support platforms that
can not use the interrupt line, polling
This driver is based on the original driver with interrupts. Polling
driver may be used in cases where the MPR121 chip is connected using
only the I2C interface and the interrupt line is not available.
Signed-off-by: Michal Vokáč
---
drivers/input/keyboard/Kconfig | 13
Normally, the MPR121 controller uses separate interrupt line to notify
the I2C host that a key was touched/released. To support platforms that
can not use the interrupt line, polling of the MPR121 registers can be
used.
Signed-off-by: Michal Vokáč
---
.../bindings/input/mpr121-touchkey
certainly needs more properties than
just compatible, reg and interrupt so trivial-devices.yaml does not
seem appropriate.
I will appreciate any comments. Thank you in advance,
Michal
Michal Vokáč (4):
dt-bindings: input: Add support for the MPR121 without interrupt line
Input: mpr121-polled
counter limit is exceeded, the chip is re-initialized.
Signed-off-by: Michal Vokáč
---
drivers/input/keyboard/mpr121_touchkey_polled.c | 100 +---
1 file changed, 88 insertions(+), 12 deletions(-)
diff --git a/drivers/input/keyboard/mpr121_touchkey_polled.c
b/drivers/input
Enable the I2C connected touch keypad on Hydra board.
Use the polled binding as the interrupt line is not available.
Signed-off-by: Michal Vokáč
---
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 12
arch/arm/boot/dts/imx6dl-yapp4-hydra.dts | 4
2 files changed, 16 insertions
On 22. 03. 19 3:24, Fabio Estevam wrote:
On Thu, Mar 21, 2019 at 11:15 PM Shawn Guo wrote:
Unfortunately, just by looking at the dts files we do not know if a
board uses an AR803x PHY or not, so I am afraid we can not do an
automatic conversion.
At least for those we already know?
Yes, I
struct bridge_vlan_info info;
int ret;
+ if (vid == 0)
+ return 0;
+
/* Check for a possible bridge VLAN entry now since there is no
* need to emulate the switchdev prepare + commit phase.
*/
Tested-by: Michal Vokáč
I am not sure what was th
qca8k: disable delay for RGMII mode")
removed the delays from the RGMII mode and hence broke the networking.
To fix the problem, commit a968b5e9d587 ("net: dsa: qca8k: Enable delay
for RGMII_ID mode") was introduced.
Now the correct phy mode is available so use it.
Signed-off-by: Micha
On 01. 03. 19 3:13, Shawn Guo wrote:
On Tue, Feb 19, 2019 at 02:37:00PM +0100, Michal Vokáč wrote:
The PHY must add delays to both Tx and Rx clock on the cpu port
to work propperly.
It worked with the rgmii mode before beacause the qca8k driver
(incorrecly) enabled delays in that mode.
Signed
On 27. 02. 19 18:26, p...@cmp.felk.cvut.cz wrote:
From: Pavel Pisa
Ahoj Pavle,
I can not comment on the content of the binding but it is a good
practice to add at least a short description to each commit even
if it should be the subject said differently.
Anyway, hats off to all of you,
The PHY must add delays to both Tx and Rx clock on the cpu port
to work propperly.
It worked with the rgmii mode before beacause the qca8k driver
(incorrecly) enabled delays in that mode.
Signed-off-by: Michal Vokáč
---
This imx6dl-yapp4 platform is currently waiting in linux-next.
Commit
On 18. 02. 19 14:03, Vinod Koul wrote:
On 18-02-19, 12:54, Michal Vokáč wrote:
On 18. 02. 19 11:45, Vinod Koul wrote:
On 15-02-19, 16:23, Andrew Lunn wrote:
On Fri, Feb 15, 2019 at 04:01:08PM +0100, Michal Vokáč wrote:
Hi,
networking on my boards [1], which are currently in linux-next
On 18. 02. 19 11:45, Vinod Koul wrote:
On 15-02-19, 16:23, Andrew Lunn wrote:
On Fri, Feb 15, 2019 at 04:01:08PM +0100, Michal Vokáč wrote:
Hi,
networking on my boards [1], which are currently in linux-next, suddently
stopped working. I tracked it down to this commit 5ecdd77c61c8 ("net
Hi,
networking on my boards [1], which are currently in linux-next, suddently
stopped working. I tracked it down to this commit 5ecdd77c61c8 ("net: dsa:
qca8k: disable delay for RGMII mode") [2].
So I think the rgmii-id mode is obviously needed in my case.
I was able to find a couple drivers
On 10. 02. 19 21:24, Stephen Rothwell wrote:
Hi Bartlomiej,
In commit
7d7e58d30e04 ("dt-bindings: display: ssd1307fb: Remove reset-active-low from
examples")
Fixes tag
Fixes: 519b4db ("fbdev: ssd1307fb: Remove reset-active-low from the DT binding
document")
has these problem(s):
Hi Uwe,
On 30. 01. 19 16:39, Uwe Kleine-König wrote:
On Wed, Jan 30, 2019 at 03:42:29PM +0100, Michal Vokáč wrote:
[...]> There are quite some drivers known (to me) being buggy here. My feeling
is that Thierry doesn't share that impression and I think the only
reasonable path forw
On 24.1.2019 11:44, Uwe Kleine-König wrote:
On Thu, Jan 24, 2019 at 11:12:12AM +0100, Michal Vokáč wrote:
On 24.1.2019 10:22, Uwe Kleine-König wrote:
I think it might be beneficial to allow (or require) that disable acts
immediately. But this is not how it used to be and in my discussion
On 24.1.2019 10:22, Uwe Kleine-König wrote:
On Thu, Jan 24, 2019 at 09:59:47AM +0100, Michal Vokáč wrote:
On 12.12.2018 13:12, Uwe Kleine-König wrote:
On Wed, Dec 12, 2018 at 11:42:17AM +, Vokáč Michal wrote:
On 12.12.2018 09:01, Uwe Kleine-König wrote:
On Thu, Dec 06, 2018 at 01:41:31PM
__ __ __ _ |
| out L \_/ \_/ \_/ |
| ^^^|
+------+
Signed-off-by: Michal Vokáč
---
Changes in v3:
- Commit message update.
- Minor fix in code comment
On 13.12.2018 09:56, Uwe Kleine-König wrote:
On Wed, Dec 12, 2018 at 12:04:51PM +, Vokáč Michal wrote:
Normally the PWM output is held LOW when PWM is disabled. This can cause
problems when inverted PWM signal polarity is needed. With this behavior
the connected circuit is fed by 100% duty
[1] https://lkml.org/lkml/2018/9/25/713
Signed-off-by: Fabrice Gasnier
Tested-by: Gottfried Haider
Tested-by: Michal Vokáč
[1] https://lkml.org/lkml/2018/9/25/713
Signed-off-by: Fabrice Gasnier
Tested-by: Gottfried Haider
Tested-by: Michal Vokáč
also seen on other platform [2]
[1] https://lkml.org/lkml/2018/9/25/713
[2] https://lkml.org/lkml/2018/9/25/447
Signed-off-by: Fabrice Gasnier
Tested-by: Gottfried Haider
Tested-by: Michal Vokáč
---
drivers/pwm/sysfs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pwm/sy
also seen on other platform [2]
[1] https://lkml.org/lkml/2018/9/25/713
[2] https://lkml.org/lkml/2018/9/25/447
Signed-off-by: Fabrice Gasnier
Tested-by: Gottfried Haider
Tested-by: Michal Vokáč
---
drivers/pwm/sysfs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pwm/sy
On 1.10.2018 15:23, Fabrice Gasnier wrote:
Since commit 7e5d1fd75c3d ("pwm: Set class for exported channels in sysfs")
- it's not possible to export more than one PWM channel
- ABI has changed, as a side effect. It may cause bad behavior as pwmchip
attributes are wrongly added to pwm channels
On 1.10.2018 15:23, Fabrice Gasnier wrote:
Since commit 7e5d1fd75c3d ("pwm: Set class for exported channels in sysfs")
- it's not possible to export more than one PWM channel
- ABI has changed, as a side effect. It may cause bad behavior as pwmchip
attributes are wrongly added to pwm channels
the clock was disabled. It is totally non-deterministic and it may be LOW
or HIGH.
Signed-off-by: Michal Vokáč
---
drivers/pwm/pwm-imx.c | 53 +++
1 file changed, 53 insertions(+)
diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index
the clock was disabled. It is totally non-deterministic and it may be LOW
or HIGH.
Signed-off-by: Michal Vokáč
---
drivers/pwm/pwm-imx.c | 53 +++
1 file changed, 53 insertions(+)
diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index
Use existing macros to define register fields instead of manually shifting
the bit masks. Also define some more register bits.
Signed-off-by: Michal Vokáč
---
drivers/pwm/pwm-imx.c | 78 ++-
1 file changed, 58 insertions(+), 20 deletions(-)
diff
Use existing macros to define register fields instead of manually shifting
the bit masks. Also define some more register bits.
Signed-off-by: Michal Vokáč
---
drivers/pwm/pwm-imx.c | 78 ++-
1 file changed, 58 insertions(+), 20 deletions(-)
diff
Sort included header files alphabetically.
Signed-off-by: Michal Vokáč
---
drivers/pwm/pwm-imx.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index 1d5242c..bcbcac4 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers
Sort included header files alphabetically.
Signed-off-by: Michal Vokáč
---
drivers/pwm/pwm-imx.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index 1d5242c..bcbcac4 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers
The reset signal of the SSD1306 OLED display is actually active-low.
Adapt the DT to reflect the real world.
Signed-off-by: Michal Vokáč
---
v2 changes: New patch in the series
arch/arm/boot/dts/imx28-cfa10036.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm
The reset signal of the SSD1306 OLED display is actually active-low.
Adapt the DT to reflect the real world.
Signed-off-by: Michal Vokáč
---
v2 changes: New patch in the series
arch/arm/boot/dts/imx28-cfa10036.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm
the gpio as GPIO_ACTIVE_LOW to reflect
the real world.
Signed-off-by: Michal Vokáč
---
v2 changes: Split the DT changes into separate patch.
drivers/video/fbdev/ssd1307fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev
the gpio as GPIO_ACTIVE_LOW to reflect
the real world.
Signed-off-by: Michal Vokáč
---
v2 changes: Split the DT changes into separate patch.
drivers/video/fbdev/ssd1307fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev
The reset signal can be produced by GPIO expander that can sleep.
In that case the probe function fails. Allow using GPIO expanders for
the reset signal by using the non-atomic gpiod_set_value_cansleep()
function.
Signed-off-by: Michal Vokáč
Reviewed-by: Fabio Estevam
---
v2 changes: add R
The reset signal can be produced by GPIO expander that can sleep.
In that case the probe function fails. Allow using GPIO expanders for
the reset signal by using the non-atomic gpiod_set_value_cansleep()
function.
Signed-off-by: Michal Vokáč
Reviewed-by: Fabio Estevam
---
v2 changes: add R
On 25.9.2018 12:21, Thierry Reding wrote:
On Tue, Sep 25, 2018 at 11:11:32AM +0200, Michal Vokáč wrote:
Hi,
Since commit 7e5d1fd75c3d ("pwm: Set class for exported channels in
sysfs") it is not possible to export more than one PWM channel.
This is because for each exported channel a
On 25.9.2018 12:21, Thierry Reding wrote:
On Tue, Sep 25, 2018 at 11:11:32AM +0200, Michal Vokáč wrote:
Hi,
Since commit 7e5d1fd75c3d ("pwm: Set class for exported channels in
sysfs") it is not possible to export more than one PWM channel.
This is because for each exported channel a
Hi,
Since commit 7e5d1fd75c3d ("pwm: Set class for exported channels in
sysfs") it is not possible to export more than one PWM channel.
This is because for each exported channel a directory named pwmN is
created in /sys/class/pwm/. As channels for all PWM chips are numbered
from 0 it is not
Hi,
Since commit 7e5d1fd75c3d ("pwm: Set class for exported channels in
sysfs") it is not possible to export more than one PWM channel.
This is because for each exported channel a directory named pwmN is
created in /sys/class/pwm/. As channels for all PWM chips are numbered
from 0 it is not
On 19.9.2018 15:17, Michal Vokáč wrote:
The reset signal can be produced by GPIO expander that can sleep.
In that case the probe function fails. Allow using GPIO expanders for
the reset signal by using the non-atomic gpiod_set_value_cansleep()
function.
Signed-off-by: Michal Vokáč
I forgot
On 19.9.2018 15:17, Michal Vokáč wrote:
The reset signal can be produced by GPIO expander that can sleep.
In that case the probe function fails. Allow using GPIO expanders for
the reset signal by using the non-atomic gpiod_set_value_cansleep()
function.
Signed-off-by: Michal Vokáč
I forgot
The reset signal of the SSD1306 OLED display is actually active-low.
Adapt the DT to reflect the real world.
Signed-off-by: Michal Vokáč
---
v2 changes: New patch in the series
arch/arm/boot/dts/imx28-cfa10036.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm
The reset signal can be produced by GPIO expander that can sleep.
In that case the probe function fails. Allow using GPIO expanders for
the reset signal by using the non-atomic gpiod_set_value_cansleep()
function.
Signed-off-by: Michal Vokáč
---
v2 changes: none
drivers/video/fbdev/ssd1307fb.c
the gpio as GPIO_ACTIVE_LOW to reflect
the real world.
Signed-off-by: Michal Vokáč
---
v2 changes: Split the DT changes into separate patch.
drivers/video/fbdev/ssd1307fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev
The reset signal of the SSD1306 OLED display is actually active-low.
Adapt the DT to reflect the real world.
Signed-off-by: Michal Vokáč
---
v2 changes: New patch in the series
arch/arm/boot/dts/imx28-cfa10036.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm
The reset signal can be produced by GPIO expander that can sleep.
In that case the probe function fails. Allow using GPIO expanders for
the reset signal by using the non-atomic gpiod_set_value_cansleep()
function.
Signed-off-by: Michal Vokáč
---
v2 changes: none
drivers/video/fbdev/ssd1307fb.c
the gpio as GPIO_ACTIVE_LOW to reflect
the real world.
Signed-off-by: Michal Vokáč
---
v2 changes: Split the DT changes into separate patch.
drivers/video/fbdev/ssd1307fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev
On 19.9.2018 14:12, Fabio Estevam wrote:
Hi Michal,
On Wed, Sep 19, 2018 at 6:18 AM, Michal Vokáč wrote:
The SSD130x OLED display reset signal is active low. Now the reset
sequence is implemented in such a way that users are forced to
define reset-gpios as GPIO_ACTIVE_HIGH in DT to make
On 19.9.2018 14:12, Fabio Estevam wrote:
Hi Michal,
On Wed, Sep 19, 2018 at 6:18 AM, Michal Vokáč wrote:
The SSD130x OLED display reset signal is active low. Now the reset
sequence is implemented in such a way that users are forced to
define reset-gpios as GPIO_ACTIVE_HIGH in DT to make
The reset signal can be produced by GPIO expander that can sleep.
In that case the probe function fails. Allow using GPIO expanders for
the reset signal by using the non-atomic gpiod_set_value_cansleep()
function.
Signed-off-by: Michal Vokáč
---
drivers/video/fbdev/ssd1307fb.c | 4 ++--
1 file
the gpio as GPIO_ACTIVE_LOW to reflect
the real world.
The only single in-tree user of the display is converted and builds
fine.
Signed-off-by: Michal Vokáč
---
I am not really sure wheater this should be in one commit or the DT
changes should be done in separate commit. Just tell me and I
The reset signal can be produced by GPIO expander that can sleep.
In that case the probe function fails. Allow using GPIO expanders for
the reset signal by using the non-atomic gpiod_set_value_cansleep()
function.
Signed-off-by: Michal Vokáč
---
drivers/video/fbdev/ssd1307fb.c | 4 ++--
1 file
the gpio as GPIO_ACTIVE_LOW to reflect
the real world.
The only single in-tree user of the display is converted and builds
fine.
Signed-off-by: Michal Vokáč
---
I am not really sure wheater this should be in one commit or the DT
changes should be done in separate commit. Just tell me and I
Hi Song,
On 5.9.2018 04:34, Song Qiang wrote:
Some leds on our board are active low leds, which means these leds
are lighted when the corresponding gpio line is low, while the
original leds-gpio driver default all leds are active high leds.
This patch adds a devicetree node "light-state", whose
Hi Song,
On 5.9.2018 04:34, Song Qiang wrote:
Some leds on our board are active low leds, which means these leds
are lighted when the corresponding gpio line is low, while the
original leds-gpio driver default all leds are active high leds.
This patch adds a devicetree node "light-state", whose
On 31.8.2018 14:45, Lothar Waßmann wrote:
Rob Herring wrote:
On Tue, Aug 21, 2018 at 04:38:52PM +0200, Michal Vokáč wrote:
Output of the PWM block of i.MX SoCs is always zero volts when the block
is disabled. This can caue issues when inverted PWM polarity is needed.
With inverted polarity
On 31.8.2018 14:45, Lothar Waßmann wrote:
Rob Herring wrote:
On Tue, Aug 21, 2018 at 04:38:52PM +0200, Michal Vokáč wrote:
Output of the PWM block of i.MX SoCs is always zero volts when the block
is disabled. This can caue issues when inverted PWM polarity is needed.
With inverted polarity
On 23.8.2018 13:18, Lothar Waßmann wrote:
Michal Vokáč wrote:
On 22.8.2018 16:10, Lothar Waßmann wrote:
My use case is attaching different displays to the same baseboard,
where some displays have the brightness control pin inverted with
respect to the others. It's easy to change
On 23.8.2018 13:18, Lothar Waßmann wrote:
Michal Vokáč wrote:
On 22.8.2018 16:10, Lothar Waßmann wrote:
My use case is attaching different displays to the same baseboard,
where some displays have the brightness control pin inverted with
respect to the others. It's easy to change
the backlight. I mentioned that somewhere in the
previous discussion with Lothar.
I also think this could be useful not only for backlight. Any circuit that
requires truly inverted PWM signal can use it. I see it as an enhancement
to what you with Lothar have already done ;)
Signed-off-by: Michal Vokáč
the backlight. I mentioned that somewhere in the
previous discussion with Lothar.
I also think this could be useful not only for backlight. Any circuit that
requires truly inverted PWM signal can use it. I see it as an enhancement
to what you with Lothar have already done ;)
Signed-off-by: Michal Vokáč
On 22.8.2018 16:10, Lothar Waßmann wrote:
Michal Vokáč wrote:
On 22.8.2018 13:17, Lothar Waßmann wrote:
Michal Vokáč wrote:
On 22.8.2018 08:14, Lothar Waßmann wrote:
Michal Vokáč wrote:
Output of the PWM block of i.MX SoCs is always zero volts when the block
is disabled
On 22.8.2018 16:10, Lothar Waßmann wrote:
Michal Vokáč wrote:
On 22.8.2018 13:17, Lothar Waßmann wrote:
Michal Vokáč wrote:
On 22.8.2018 08:14, Lothar Waßmann wrote:
Michal Vokáč wrote:
Output of the PWM block of i.MX SoCs is always zero volts when the block
is disabled
On 22.8.2018 13:17, Lothar Waßmann wrote:
Michal Vokáč wrote:
On 22.8.2018 08:14, Lothar Waßmann wrote:
Michal Vokáč wrote:
Output of the PWM block of i.MX SoCs is always zero volts when the block
is disabled. This can caue issues when inverted PWM polarity is needed.
With inverted
1 - 100 of 185 matches
Mail list logo
