These are i.MX6S/DL based SBCs embedded in various Y Soft products.
All share the same board design but have slightly different HW
configuration.
Ursa
- i.MX6S SoC, 512MB RAM DDR3, 4GB eMMC, microSD
- parallel WVGA 7" LCD with touch panel
- 1x Eth (QCA8334 switch)
- USB OTG
- USB host (micro-B)
These are i.MX6DualLite/Solo based single board computers used
in various Y Soft products.
Cc: Andrew Lunn
Signed-off-by: Michal Vokáč
---
Changes since v2:
- New patch
Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git
On 13. 01. 19 10:34, Shawn Guo wrote:
> On Thu, Jan 10, 2019 at 04:20:51PM +0000, Vokáč Michal wrote:
>> These are i.MX6S/DL based SBCs embedded in various Y Soft products.
>> All share the same board design but have slightly different HW
>> configuration.
>>
>>
These are i.MX6S/DL based SBCs embedded in various Y Soft products.
All share the same board design but have slightly different HW
configuration.
Ursa
- i.MX6S SoC, 512MB RAM DDR3, 4GB eMMC, microSD
- parallel WVGA 7" LCD with touch panel
- 1x Eth (QCA8334 switch)
- USB OTG
- USB host (micro-B)
These are i.MX6DualLite/Solo based single board computers used
in various Y Soft products.
Cc: Andrew Lunn
Signed-off-by: Michal Vokáč
---
Changes since v2:
- New patch
Documentation/devicetree/bindings/arm/fsl.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git
On 10.1.2019 14:57, Shawn Guo wrote:
> @Vokáč,
>
> Please generate your patches against my for-next branch with dt-bindings
> being separate patch from dts one.
OK, thank you Shawn.
Michal
On 10.1.2019 07:42, Shawn Guo wrote:
> On Sat, Dec 08, 2018 at 09:58:37AM +0800, Shawn Guo wrote:
>> On Thu, Dec 06, 2018 at 05:33:13PM -0600, Rob Herring wrote:
>>> On Wed, Dec 5, 2018 at 8:32 PM Shawn Guo wrote:
On Mon, Dec 03, 2018 at 03:32:07PM -0600, Rob Herring wrote:
>
The reset-active-low property has been removed brom the binding a while
ago. So remove it from the examples as well.
Fixes: 519b4db ("fbdev: ssd1307fb: Remove reset-active-low from the DT binding
document")
Reviewed-by: Rob Herring
Reviewed-by: Alexandre Belloni
Signed-off-by: Michal Vokáč
There was a bug in reset signal generation in ssd1307fb OLED driver.
The display needs an active-low reset signal but the driver produced
the correct sequence only if the GPIO used for reset was specified as
GPIO_ACTIVE_HIGH.
Now as the OLED driver is fixed it is also necessarry to implement
a
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 work.
Do not hard code the active-low sequence into the driver but instead
allow the user to specify the
The reset signal of the SSD1306 OLED display is actually active-low.
Adapt the DT to reflect the real world.
Reviewed-by: Rob Herring
Acked-by: Alexandre Belloni
Signed-off-by: Michal Vokáč
---
Changes in v2 resend:
- Add Acked-by from Alexandre.
Changes from v1:
- Add R-by from Rob
Hi all,
this is my third attempt to fix the ssd1307fb OLED driver reset. In the
second attempt [1] Rob suggested to take different aproach. That is to
apply what was originaly part of the first round and eventually merged
but reverted later on [2][3].
The last patch in this series is a fixup for
On 8.1.2019 16:00, Vokáč Michal wrote:
> On 8.1.2019 15:56, Rob Herring wrote:
>> On Tue, Jan 8, 2019 at 5:43 AM Vokáč Michal wrote:
>>>
>>> On 29.12.2018 00:25, Rob Herring wrote:
>>>> On Tue, Dec 18, 2018 at 02:42:11PM +, Vokáč Michal wrote:
>&g
On 8.1.2019 15:56, Rob Herring wrote:
> On Tue, Jan 8, 2019 at 5:43 AM Vokáč Michal wrote:
>>
>> On 29.12.2018 00:25, Rob Herring wrote:
>>> On Tue, Dec 18, 2018 at 02:42:11PM +, Vokáč Michal wrote:
>>>> These are i.MX6S/DL based SBCs embedded in var
On 8.1.2019 12:43, Vokáč Michal wrote:
> On 29.12.2018 00:25, Rob Herring wrote:
>> On Tue, Dec 18, 2018 at 02:42:11PM +0000, Vokáč Michal wrote:
[...]
>>> + {
>>> + clock-frequency = <10>;
>>> + pinctrl-names = "default";
>
On 29.12.2018 00:25, Rob Herring wrote:
> On Tue, Dec 18, 2018 at 02:42:11PM +0000, Vokáč Michal wrote:
>> These are i.MX6S/DL based SBCs embedded in various Y Soft products.
>> All share the same board design but have slightly different HW
>> configuration.
>>
>>
On 28.12.2018 19:20, Fabio Estevam wrote:
> On Tue, Dec 18, 2018 at 12:42 PM Vokáč Michal wrote:
>
>> + {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_enet>;
>> + phy-mode = "rgmii-id";
>> + phy-reset-gp
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 work.
Do not hard code the active-low sequence into the driver but instead
allow the user to specify the
The reset signal of the SSD1306 OLED display is actually active-low.
Adapt the DT to reflect the real world.
Reviewed-by: Rob Herring
Signed-off-by: Michal Vokáč
---
Changes from v1:
- Add R-by from Rob
arch/arm/boot/dts/imx28-cfa10036.dts | 3 ++-
1 file changed, 2 insertions(+), 1
The reset-active-low property has been removed brom the binding a while
ago. So remove it from the examples as well.
Fixes: 519b4db ("fbdev: ssd1307fb: Remove reset-active-low from the DT binding
document")
Reviewed-by: Rob Herring
Signed-off-by: Michal Vokáč
---
Changes from v1:
- Add R-by
Hi all,
this is my third attempt to fix the ssd1307fb OLED driver reset. In the
second attempt [1] Rob suggested to take different aproach. That is to
apply what was originaly part of the first round and eventually merged
but reverted later on [2][3].
Next step is to apply a fixup for the single
There was a bug in reset signal generation in ssd1307fb OLED driver.
The display needs an active-low reset signal but the driver produced
the correct sequence only if the GPIO used for reset was specified as
GPIO_ACTIVE_HIGH.
Now as the OLED driver is fixed it is also necessarry to implement
a
On 19.12.2018 18:29, Rob Herring wrote:
> On Tue, Dec 04, 2018 at 03:03:40PM +0000, Vokáč Michal wrote:
>> There was a bug in reset signal generation in ssd1307fb OLED driver.
>> The display needs an active-low reset signal but the driver produced
>> the correct sequence
These are i.MX6S/DL based SBCs embedded in various Y Soft products.
All share the same board design but have slightly different HW
configuration.
Ursa
- i.MX6S SoC, 512MB RAM DDR3, 4GB eMMC, microSD
- parallel WVGA 7" LCD with touch panel
- 1x Eth (QCA8334 switch)
- USB OTG
- USB host (micro-B)
On 13.12.2018 21:14, Uwe Kleine-König wrote:> On Thu, Dec 13, 2018 at
06:00:00PM +0100, Thierry Reding wrote:
>> On Thu, Dec 13, 2018 at 09:52:13AM +0100, Uwe Kleine-König wrote:
>>> On Wed, Dec 12, 2018 at 11:54:32AM +0100, Thierry Reding wrote:
On Mon, Oct 01, 2018 at 04:19:48PM +0200,
On 12.12.2018 11:51, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Oct 01, 2018 at 04:19:48PM +0200, Michal Vokáč wrote:
>> Implement the get_state() function and set the initial state to reflect
>> real state of the hardware. This allows to keep the PWM running if it was
>> enabled in bootloader.
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 cycle instead of being shut-off.
Allow users to define a "pwm" and a "gpio" pinctrl states. The pwm pinctrl
This is an attempt to deal with i.MX SoC PWM HW limitation.
When a pad is configured as a PWM output the output level is always 0V
if the PWM block is disabled. This can cause problems when inverted PWM
signal is needed to drive the connected circuit. With inverted output
duty cycle = 0%
Output of the PWM block on i.MX SoCs is always low when the block is
disabled. This can cause issues when inverted PWM polarity is needed.
With inverted polarity a duty cycle = 0% corresponds to high level on
the output. Now, when PWM is disabled its output instantly goes low
which corresponds to
On 12.12.2018 09:01, Uwe Kleine-König wrote:
> On Thu, Dec 06, 2018 at 01:41:31PM +0000, 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 con
On 11.12.2018 13:36, Andrew Lunn wrote:
>>> Hi Rob, gentle ping on this.
>>>
>>> I would like to be sure how to proceed with this. Do you really want me
>>> to move *all* nodes that are disabled in this common dtsi into the per
>>> board dts?
>>>
>>> All the boards use identical PCB. Anything that
On 27.11.2018 13:19, Vokáč Michal wrote:
> On 19.11.2018 15:35, Vokáč Michal wrote:
>> On 12.11.2018 17:41, Rob Herring wrote:
>>> On Thu, Nov 01, 2018 at 03:43:26PM +, Vokáč Michal wrote:
>>>> These are i.MX6S/DL based SBCs embedded in various Y Soft products.
On 10.12.2018 12:17, Uwe Kleine-König wrote:
> On Mon, Dec 10, 2018 at 11:15:05AM +0000, Vokáč Michal wrote:
>> On 6.12.2018 17:16, Uwe Kleine-König wrote:
>>> On Thu, Dec 06, 2018 at 03:37:55PM +, Vokáč Michal wrote:
>>>> On 6.12.2018 14:59, Uwe Kleine-König wro
On 6.12.2018 17:16, Uwe Kleine-König wrote:
> On Thu, Dec 06, 2018 at 03:37:55PM +0000, Vokáč Michal wrote:
>> On 6.12.2018 14:59, Uwe Kleine-König wrote:
>>> On Thu, Dec 06, 2018 at 01:41:31PM +, Vokáč Michal wrote:
>>>
>>> Can it happen, that pinct
On 6.12.2018 14:59, Uwe Kleine-König wrote:
> On Thu, Dec 06, 2018 at 01:41:31PM +0000, Vokáč Michal wrote:
>>
>> +static int imx_pwm_init_pinctrl_info(struct imx_chip *imx_chip,
>> +struct platform_device *pdev)
>
> Please indent the follow up line to th
On 6.12.2018 14:59, Uwe Kleine-König wrote:
> On Thu, Dec 06, 2018 at 01:41:31PM +0000, Vokáč Michal wrote:
>>
>> +static int imx_pwm_init_pinctrl_info(struct imx_chip *imx_chip,
>> +struct platform_device *pdev)
>
> Please indent the follow up line to th
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 cycle instead of being shut-off.
Allow users to define a "pwm" and a "gpio" pinctrl states. The pwm pinctrl
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 cycle instead of being shut-off.
Allow users to define a "pwm" and a "gpio" pinctrl states. The pwm pinctrl
Output of the PWM block on i.MX SoCs is always low when the block is
disabled. This can cause issues when inverted PWM polarity is needed.
With inverted polarity a duty cycle = 0% corresponds to high level on
the output. Now, when PWM is disabled its output instantly goes low
which corresponds to
Output of the PWM block on i.MX SoCs is always low when the block is
disabled. This can cause issues when inverted PWM polarity is needed.
With inverted polarity a duty cycle = 0% corresponds to high level on
the output. Now, when PWM is disabled its output instantly goes low
which corresponds to
This is an attempt to deal with i.MX SoC PWM HW limitation.
When a pad is configured as a PWM output the output level is always 0V
if the PWM block is disabled. This can cause problems when inverted PWM
signal is needed to drive the connected circuit. With inverted output
duty cycle = 0%
This is an attempt to deal with i.MX SoC PWM HW limitation.
When a pad is configured as a PWM output the output level is always 0V
if the PWM block is disabled. This can cause problems when inverted PWM
signal is needed to drive the connected circuit. With inverted output
duty cycle = 0%
On 6.12.2018 14:05, Pavel Machek wrote:
>
> Fix typo and fix compatible value that is not actually permitted by the
> description in the example.
Ahoj Pavle, I think the subject should be more like:
"dt-bindings: net: dsa: ..."
BR, Michal
>
> Signed-off-by: Pavel Machek
>
There was a bug in reset signal generation in ssd1307fb OLED driver.
The display needs an active-low reset signal but the driver produced
the correct sequence only if the GPIO used for reset was specified as
GPIO_ACTIVE_HIGH.
Now as the OLED driver is fixed it is also necessarry to implement
a
There was a bug in reset signal generation in ssd1307fb OLED driver.
The display needs an active-low reset signal but the driver produced
the correct sequence only if the GPIO used for reset was specified as
GPIO_ACTIVE_HIGH.
Now as the OLED driver is fixed it is also necessarry to implement
a
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 work.
Do not hard code the active-low sequence into the driver but instead
allow the user to specify the
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 work.
Do not hard code the active-low sequence into the driver but instead
allow the user to specify the
The reset-active-low property has been removed brom the binding a while
ago. So remove it from the examples as well.
Fixes: 519b4db ("fbdev: ssd1307fb: Remove reset-active-low from the DT binding
document")
Signed-off-by: Michal Vokáč
---
Documentation/devicetree/bindings/display/ssd1307fb.txt
Hi all,
this is my third attempt to fix the ssd1307fb OLED driver reset. In the
second attempt [1] Rob suggested to take different aproach. That is to
apply what was originaly part of the first round and eventually merged
but reverted later on [2][3].
Next step is to apply a fixup for the single
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áč
---
arch/arm/boot/dts/imx28-cfa10036.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx28-cfa10036.dts
The reset-active-low property has been removed brom the binding a while
ago. So remove it from the examples as well.
Fixes: 519b4db ("fbdev: ssd1307fb: Remove reset-active-low from the DT binding
document")
Signed-off-by: Michal Vokáč
---
Documentation/devicetree/bindings/display/ssd1307fb.txt
Hi all,
this is my third attempt to fix the ssd1307fb OLED driver reset. In the
second attempt [1] Rob suggested to take different aproach. That is to
apply what was originaly part of the first round and eventually merged
but reverted later on [2][3].
Next step is to apply a fixup for the single
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áč
---
arch/arm/boot/dts/imx28-cfa10036.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx28-cfa10036.dts
On 28.11.2018 03:39, Shawn Guo wrote:
> On Thu, Nov 01, 2018 at 03:43:26PM +0000, Vokáč Michal wrote:
> ...
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_usdhc3>;
>> +bus-width = <4>;
>> +cd-gpios = <
On 28.11.2018 03:39, Shawn Guo wrote:
> On Thu, Nov 01, 2018 at 03:43:26PM +0000, Vokáč Michal wrote:
> ...
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_usdhc3>;
>> +bus-width = <4>;
>> +cd-gpios = <
On 19.11.2018 15:35, Vokáč Michal wrote:
> On 12.11.2018 17:41, Rob Herring wrote:
>> On Thu, Nov 01, 2018 at 03:43:26PM +0000, Vokáč Michal wrote:
>>> These are i.MX6S/DL based SBCs embedded in various Y Soft products.
>>> All share the same board design but
On 19.11.2018 15:35, Vokáč Michal wrote:
> On 12.11.2018 17:41, Rob Herring wrote:
>> On Thu, Nov 01, 2018 at 03:43:26PM +0000, Vokáč Michal wrote:
>>> These are i.MX6S/DL based SBCs embedded in various Y Soft products.
>>> All share the same board design but
On 26.11.2018 14:34, Thierry Reding wrote:
> On Mon, Nov 26, 2018 at 01:23:16PM +0100, Lothar Waßmann wrote:
>> Thierry Reding wrote:
>>
>>> On Fri, Nov 23, 2018 at 03:15:11PM +, Vokáč Michal wrote:
>>>> On 22.11.2018 20:03, Uwe Kleine-König wrote:
>
On 26.11.2018 14:34, Thierry Reding wrote:
> On Mon, Nov 26, 2018 at 01:23:16PM +0100, Lothar Waßmann wrote:
>> Thierry Reding wrote:
>>
>>> On Fri, Nov 23, 2018 at 03:15:11PM +, Vokáč Michal wrote:
>>>> On 22.11.2018 20:03, Uwe Kleine-König wrote:
>
On 26.11.2018 14:49, Rob Herring wrote:
> On Mon, Nov 26, 2018 at 6:25 AM Vokáč Michal wrote:
>>
>> On 19.11.2018 23:32, Rob Herring wrote:
>>> On Mon, Nov 19, 2018 at 9:12 AM Vokáč Michal wrote:
>>>> On 12.11.2018 17:55, Rob Herring wrote:
>>>>&
On 26.11.2018 14:49, Rob Herring wrote:
> On Mon, Nov 26, 2018 at 6:25 AM Vokáč Michal wrote:
>>
>> On 19.11.2018 23:32, Rob Herring wrote:
>>> On Mon, Nov 19, 2018 at 9:12 AM Vokáč Michal wrote:
>>>> On 12.11.2018 17:55, Rob Herring wrote:
>>>>&
On 19.11.2018 23:32, Rob Herring wrote:
> On Mon, Nov 19, 2018 at 9:12 AM Vokáč Michal wrote:
>> On 12.11.2018 17:55, Rob Herring wrote:
>>> On Fri, Nov 02, 2018 at 02:56:35PM +, Vokáč Michal wrote:
>>>> The SSD130x OLED display reset signal is active lo
On 19.11.2018 23:32, Rob Herring wrote:
> On Mon, Nov 19, 2018 at 9:12 AM Vokáč Michal wrote:
>> On 12.11.2018 17:55, Rob Herring wrote:
>>> On Fri, Nov 02, 2018 at 02:56:35PM +, Vokáč Michal wrote:
>>>> The SSD130x OLED display reset signal is active lo
On 22.11.2018 20:03, Uwe Kleine-König wrote:
> On Thu, Nov 22, 2018 at 04:46:39PM +0000, Vokáč Michal wrote:
>> On 22.11.2018 17:23, Uwe Kleine-König wrote:
>>> On Thu, Nov 22, 2018 at 03:42:14PM +, Vokáč Michal wrote:
>>>> On 16.11.2018 09:25, Uwe Kleine-Kön
On 22.11.2018 20:03, Uwe Kleine-König wrote:
> On Thu, Nov 22, 2018 at 04:46:39PM +0000, Vokáč Michal wrote:
>> On 22.11.2018 17:23, Uwe Kleine-König wrote:
>>> On Thu, Nov 22, 2018 at 03:42:14PM +, Vokáč Michal wrote:
>>>> On 16.11.2018 09:25, Uwe Kleine-Kön
On 22.11.2018 17:23, Uwe Kleine-König wrote:
> Hello Michal,
>
> On Thu, Nov 22, 2018 at 03:42:14PM +0000, Vokáč Michal wrote:
>> On 16.11.2018 09:25, Uwe Kleine-König wrote:
>>> On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote:
>>>> No. You can d
On 22.11.2018 17:23, Uwe Kleine-König wrote:
> Hello Michal,
>
> On Thu, Nov 22, 2018 at 03:42:14PM +0000, Vokáč Michal wrote:
>> On 16.11.2018 09:25, Uwe Kleine-König wrote:
>>> On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote:
>>>> No. You can d
On 16.11.2018 09:25, Uwe Kleine-König wrote:
> On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote:
>> Uwe Kleine-König wrote:
>>> On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote:
On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote:
> On Wed, Nov
On 16.11.2018 09:25, Uwe Kleine-König wrote:
> On Fri, Nov 16, 2018 at 08:34:30AM +0100, Lothar Waßmann wrote:
>> Uwe Kleine-König wrote:
>>> On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote:
On Wed, Nov 14, 2018 at 10:51:20PM +0100, Uwe Kleine-König wrote:
> On Wed, Nov
Ahoj Uwe,
On 20.11.2018 17:54, Uwe Kleine-König wrote:
> On Tue, Nov 20, 2018 at 01:14:33PM +0000, Vokáč Michal wrote:
>> On 16.11.2018 10:51, Thierry Reding wrote:
>>> On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote:
>>>> On Thu, Nov 15, 2018 at 04
Ahoj Uwe,
On 20.11.2018 17:54, Uwe Kleine-König wrote:
> On Tue, Nov 20, 2018 at 01:14:33PM +0000, Vokáč Michal wrote:
>> On 16.11.2018 10:51, Thierry Reding wrote:
>>> On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote:
>>>> On Thu, Nov 15, 2018 at 04
Hi,
sorry for the delay, I was out of office last week.
My comments below are just to clarify my attitude to the topic as my
name was mentioned few times while I was offline.
On 16.11.2018 10:51, Thierry Reding wrote:
> On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote:
>> On Thu,
Hi,
sorry for the delay, I was out of office last week.
My comments below are just to clarify my attitude to the topic as my
name was mentioned few times while I was offline.
On 16.11.2018 10:51, Thierry Reding wrote:
> On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote:
>> On Thu,
On 12.11.2018 17:55, Rob Herring wrote:
> On Fri, Nov 02, 2018 at 02:56:35PM +0000, Vokáč Michal wrote:
>> The SSD130x OLED display reset signal is active low. Now the reset
>> sequence is implemented in such a way that DTS authors are forced to
>> define the
On 12.11.2018 17:55, Rob Herring wrote:
> On Fri, Nov 02, 2018 at 02:56:35PM +0000, Vokáč Michal wrote:
>> The SSD130x OLED display reset signal is active low. Now the reset
>> sequence is implemented in such a way that DTS authors are forced to
>> define the
On 12.11.2018 17:41, Rob Herring wrote:
> On Thu, Nov 01, 2018 at 03:43:26PM +0000, Vokáč Michal wrote:
>> These are i.MX6S/DL based SBCs embedded in various Y Soft products.
>> All share the same board design but have slightly different HW
>> configuration.
>>
>>
On 12.11.2018 17:41, Rob Herring wrote:
> On Thu, Nov 01, 2018 at 03:43:26PM +0000, Vokáč Michal wrote:
>> These are i.MX6S/DL based SBCs embedded in various Y Soft products.
>> All share the same board design but have slightly different HW
>> configuration.
>>
>>
On 8.11.2018 20:18, Uwe Kleine-König wrote:
> On Thu, Nov 08, 2018 at 03:21:44PM +0000, Vokáč Michal wrote:
>> Hi Uwe,
>>
>> On 7.11.2018 16:01, Uwe Kleine-König wrote:
>>>> Interesting idea. I just wonder why nobody else did not come up with such
>>>>
On 8.11.2018 20:18, Uwe Kleine-König wrote:
> On Thu, Nov 08, 2018 at 03:21:44PM +0000, Vokáč Michal wrote:
>> Hi Uwe,
>>
>> On 7.11.2018 16:01, Uwe Kleine-König wrote:
>>>> Interesting idea. I just wonder why nobody else did not come up with such
>>>>
Hi Uwe,
On 7.11.2018 16:01, Uwe Kleine-König wrote:
>> Interesting idea. I just wonder why nobody else did not come up with such
>> a simple solution before.
>
> I think I mentioned it already in this thread, but it went unnoticed :-)
I meant it like "How happened this was not invented years
Hi Uwe,
On 7.11.2018 16:01, Uwe Kleine-König wrote:
>> Interesting idea. I just wonder why nobody else did not come up with such
>> a simple solution before.
>
> I think I mentioned it already in this thread, but it went unnoticed :-)
I meant it like "How happened this was not invented years
Hi Uwe,
On 7.11.2018 10:33, Uwe Kleine-König wrote:
> Hello Michal,
>
> just to state it more explicitly, I think the following patch (not even
> compile tested) is much preferable over your approach:
Interesting idea. I just wonder why nobody else did not come up with such
a simple solution
Hi Uwe,
On 7.11.2018 10:33, Uwe Kleine-König wrote:
> Hello Michal,
>
> just to state it more explicitly, I think the following patch (not even
> compile tested) is much preferable over your approach:
Interesting idea. I just wonder why nobody else did not come up with such
a simple solution
On 6.11.2018 23:07, Jacek Anaszewski wrote:
> Add common LED function definitions for use in Device Tree.
> The function names were extracted from existing dts files
> after eliminating oddities.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Baolin Wang
> Cc: Daniel Mack
> Cc: Dan Murphy
> Cc:
On 6.11.2018 23:07, Jacek Anaszewski wrote:
> Add common LED function definitions for use in Device Tree.
> The function names were extracted from existing dts files
> after eliminating oddities.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Baolin Wang
> Cc: Daniel Mack
> Cc: Dan Murphy
> Cc:
This reverts commit 519b4dba586198eed8f72ba07bc71808af2e0e32.
It is true that the actual implementation has never been there. But
contrary to what the reverted commit message says it does make sense
to add it.
Current implementation of the reset signal is hard-coded to active low
with the
The SSD130x OLED display reset signal is active low. Now the reset
sequence is implemented in such a way that DTS authors are forced to
define the reset-gpios property with GPIO_ACTIVE_HIGH to make the reset
work.
Add the reset-active-low property so the signal is inverted once again
and the
This reverts commit 519b4dba586198eed8f72ba07bc71808af2e0e32.
It is true that the actual implementation has never been there. But
contrary to what the reverted commit message says it does make sense
to add it.
Current implementation of the reset signal is hard-coded to active low
with the
The SSD130x OLED display reset signal is active low. Now the reset
sequence is implemented in such a way that DTS authors are forced to
define the reset-gpios property with GPIO_ACTIVE_HIGH to make the reset
work.
Add the reset-active-low property so the signal is inverted once again
and the
These are i.MX6S/DL based SBCs embedded in various Y Soft products.
All share the same board design but have slightly different HW
configuration.
Ursa
- i.MX6S SoC, 512MB RAM DDR3, 4GB eMMC, microSD
- parallel WVGA 7" LCD with touch panel
- 1x Eth (QCA8334 switch)
- USB OTG
- USB host (micro-B)
These are i.MX6S/DL based SBCs embedded in various Y Soft products.
All share the same board design but have slightly different HW
configuration.
Ursa
- i.MX6S SoC, 512MB RAM DDR3, 4GB eMMC, microSD
- parallel WVGA 7" LCD with touch panel
- 1x Eth (QCA8334 switch)
- USB OTG
- USB host (micro-B)
On 15.10.2018 10:45, Thierry Reding wrote:
> On Sun, Oct 14, 2018 at 10:24:57PM +0200, Uwe Kleine-König wrote:
>> Hello,
>>
>> On Fri, Oct 12, 2018 at 06:08:54PM +0200, Uwe Kleine-König wrote:
>> +if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) {
>
> You must not use PTR_ERR
On 15.10.2018 10:45, Thierry Reding wrote:
> On Sun, Oct 14, 2018 at 10:24:57PM +0200, Uwe Kleine-König wrote:
>> Hello,
>>
>> On Fri, Oct 12, 2018 at 06:08:54PM +0200, Uwe Kleine-König wrote:
>> +if (PTR_ERR(imx_chip->pwm_gpiod) == -EPROBE_DEFER) {
>
> You must not use PTR_ERR
On 12.10.2018 18:08, Uwe Kleine-König wrote:
> Hello,
>
> On Fri, Oct 12, 2018 at 03:04:48PM +0000, Vokáč Michal wrote:
>> On 12.10.2018 10:57, Uwe Kleine-König wrote:
>>> On Wed, Oct 10, 2018 at 09:33:26AM +, Vokáč Michal wrote:
>>>> Normally the PWM out
On 12.10.2018 18:08, Uwe Kleine-König wrote:
> Hello,
>
> On Fri, Oct 12, 2018 at 03:04:48PM +0000, Vokáč Michal wrote:
>> On 12.10.2018 10:57, Uwe Kleine-König wrote:
>>> On Wed, Oct 10, 2018 at 09:33:26AM +, Vokáč Michal wrote:
>>>> Normally the PWM out
On 12.10.2018 18:00, Thierry Reding wrote:
> On Wed, Oct 10, 2018 at 09:33:26AM +0000, 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
On 12.10.2018 18:00, Thierry Reding wrote:
> On Wed, Oct 10, 2018 at 09:33:26AM +0000, 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
On 10.10.2018 15:39, Thierry Reding wrote:
> On Wed, Oct 10, 2018 at 09:33:25AM +0000, Vokáč Michal wrote:
>> Output of the PWM block on i.MX SoCs is always low when the block is
>> disabled. This can cause issues when inverted PWM polarity is needed.
>> With inverted pola
On 10.10.2018 15:39, Thierry Reding wrote:
> On Wed, Oct 10, 2018 at 09:33:25AM +0000, Vokáč Michal wrote:
>> Output of the PWM block on i.MX SoCs is always low when the block is
>> disabled. This can cause issues when inverted PWM polarity is needed.
>> With inverted pola
On 12.10.2018 10:57, Uwe Kleine-König wrote:
> Hello,
>
> On Wed, Oct 10, 2018 at 09:33:26AM +0000, 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
>
1 - 100 of 119 matches
Mail list logo
