Hi Clemens,
On Tue, Jan 10, 2017 at 10:33 PM, Clemens Gruber
wrote:
> Hi Fabio,
>
> On Sun, Jan 08, 2017 at 07:46:29PM -0200, Fabio Estevam wrote:
>> > What's the revision of the i.MX6Q on your board? Mine is 1.5 (TO 1.3)
>>
>> Mine is a mx6solo rev1.1.
>
> Could it
Hi Clemens,
On Tue, Jan 10, 2017 at 10:33 PM, Clemens Gruber
wrote:
> Hi Fabio,
>
> On Sun, Jan 08, 2017 at 07:46:29PM -0200, Fabio Estevam wrote:
>> > What's the revision of the i.MX6Q on your board? Mine is 1.5 (TO 1.3)
>>
>> Mine is a mx6solo rev1.1.
>
> Could it be dependent upon SMP? Do you
Hi Fabio,
On Sun, Jan 08, 2017 at 07:46:29PM -0200, Fabio Estevam wrote:
> > What's the revision of the i.MX6Q on your board? Mine is 1.5 (TO 1.3)
>
> Mine is a mx6solo rev1.1.
Could it be dependent upon SMP? Do you have an i.MX6Q board around to
try?
--
I made a few interesting discoveries
Hi Fabio,
On Sun, Jan 08, 2017 at 07:46:29PM -0200, Fabio Estevam wrote:
> > What's the revision of the i.MX6Q on your board? Mine is 1.5 (TO 1.3)
>
> Mine is a mx6solo rev1.1.
Could it be dependent upon SMP? Do you have an i.MX6Q board around to
try?
--
I made a few interesting discoveries
On Sun, Jan 8, 2017 at 4:06 PM, Clemens Gruber
wrote:
> I just did the experiment with your configuration and the rs485conf tool
> you mentioned.
> But still, no luck :(
>
> What's the revision of the i.MX6Q on your board? Mine is 1.5 (TO 1.3)
Mine is a mx6solo
On Sun, Jan 8, 2017 at 4:06 PM, Clemens Gruber
wrote:
> I just did the experiment with your configuration and the rs485conf tool
> you mentioned.
> But still, no luck :(
>
> What's the revision of the i.MX6Q on your board? Mine is 1.5 (TO 1.3)
Mine is a mx6solo rev1.1.
> Another example: If I
Hi Fabio,
On Sun, Jan 08, 2017 at 12:30:24AM -0200, Fabio Estevam wrote:
> Hi Clemens,
>
> On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber
> wrote:
>
> > Just remuxed GPIO signals to these pads, applied your two patches and
> > used rts-gpios in the DT but I still
Hi Fabio,
On Sun, Jan 08, 2017 at 12:30:24AM -0200, Fabio Estevam wrote:
> Hi Clemens,
>
> On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber
> wrote:
>
> > Just remuxed GPIO signals to these pads, applied your two patches and
> > used rts-gpios in the DT but I still see the same problem :/
> >
>
Hi Clemens,
On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber
wrote:
> Just remuxed GPIO signals to these pads, applied your two patches and
> used rts-gpios in the DT but I still see the same problem :/
As you have tested my 'rts-gpios' patches, would it be possible
Hi Clemens,
On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber
wrote:
> Just remuxed GPIO signals to these pads, applied your two patches and
> used rts-gpios in the DT but I still see the same problem :/
As you have tested my 'rts-gpios' patches, would it be possible to
reply with your Tested-by
Hi Clemens,
On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber
wrote:
> Just remuxed GPIO signals to these pads, applied your two patches and
> used rts-gpios in the DT but I still see the same problem :/
>
> When transmit something, I get doubled characters, then zeros
Hi Clemens,
On Sat, Jan 7, 2017 at 9:06 PM, Clemens Gruber
wrote:
> Just remuxed GPIO signals to these pads, applied your two patches and
> used rts-gpios in the DT but I still see the same problem :/
>
> When transmit something, I get doubled characters, then zeros and at the
> end garbled
Hi Fabio,
On Sat, Jan 07, 2017 at 07:43:48PM -0200, Fabio Estevam wrote:
> Hi Clemens,
>
> On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber
> wrote:
>
> > Great!
> >
> > Did you observe the same effect I described, with the doubling of
> > characters in the front and
Hi Fabio,
On Sat, Jan 07, 2017 at 07:43:48PM -0200, Fabio Estevam wrote:
> Hi Clemens,
>
> On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber
> wrote:
>
> > Great!
> >
> > Did you observe the same effect I described, with the doubling of
> > characters in the front and the leftovers from previous
Hi Clemens,
On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber
wrote:
> Great!
>
> Did you observe the same effect I described, with the doubling of
> characters in the front and the leftovers from previous transmissions at
> the end?
No, I don't observe these errors
Hi Clemens,
On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber
wrote:
> Great!
>
> Did you observe the same effect I described, with the doubling of
> characters in the front and the leftovers from previous transmissions at
> the end?
No, I don't observe these errors when I use 'rts-gpios' in the
On Sat, Jan 07, 2017 at 02:48:03PM -0200, Fabio Estevam wrote:
> On Sat, Jan 7, 2017 at 1:34 PM, Clemens Gruber
> wrote:
> > Hi Fabio,
> >
> > On Sat, Jan 07, 2017 at 12:57:10PM -0200, Fabio Estevam wrote:
> >> The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only
On Sat, Jan 07, 2017 at 02:48:03PM -0200, Fabio Estevam wrote:
> On Sat, Jan 7, 2017 at 1:34 PM, Clemens Gruber
> wrote:
> > Hi Fabio,
> >
> > On Sat, Jan 07, 2017 at 12:57:10PM -0200, Fabio Estevam wrote:
> >> The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only valid in dte mode.
> >
> > Ah,
On Sat, Jan 7, 2017 at 1:34 PM, Clemens Gruber
wrote:
> Hi Fabio,
>
> On Sat, Jan 07, 2017 at 12:57:10PM -0200, Fabio Estevam wrote:
>> The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only valid in dte mode.
>
> Ah, the input select is limited in that way, I see.
>
>
On Sat, Jan 7, 2017 at 1:34 PM, Clemens Gruber
wrote:
> Hi Fabio,
>
> On Sat, Jan 07, 2017 at 12:57:10PM -0200, Fabio Estevam wrote:
>> The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only valid in dte mode.
>
> Ah, the input select is limited in that way, I see.
>
> You wrote that you tried
Hi Fabio,
On Sat, Jan 07, 2017 at 12:57:10PM -0200, Fabio Estevam wrote:
> The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only valid in dte mode.
Ah, the input select is limited in that way, I see.
You wrote that you tried rts-gpios.
What about setting cts-gpios to gpio6 2 in the DT?
Or can
Hi Fabio,
On Sat, Jan 07, 2017 at 12:57:10PM -0200, Fabio Estevam wrote:
> The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only valid in dte mode.
Ah, the input select is limited in that way, I see.
You wrote that you tried rts-gpios.
What about setting cts-gpios to gpio6 2 in the DT?
Or can
Hi Clemens,
On Sat, Jan 7, 2017 at 11:45 AM, Clemens Gruber
wrote:
> It should work like this, I don't think using an extra GPIO is
> necessary.
The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only valid in dte mode.
If I pass 'fsl,dte-mode' then I can see this
Hi Clemens,
On Sat, Jan 7, 2017 at 11:45 AM, Clemens Gruber
wrote:
> It should work like this, I don't think using an extra GPIO is
> necessary.
The MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B option is only valid in dte mode.
If I pass 'fsl,dte-mode' then I can see this pin toggling. (rx, tx
would
Hi Fabio,
On Fri, Jan 06, 2017 at 10:31:16PM -0200, Fabio Estevam wrote:
> Yes, I have tried like this:
>
> {
> pinctrl-names = "default";
> pinctrl-0 = <_uart4>;
> uart-has-rtscts;
> status = "okay";
> };
>
> pinctrl_uart4: uart4grp {
> fsl,pins = <
>
Hi Fabio,
On Fri, Jan 06, 2017 at 10:31:16PM -0200, Fabio Estevam wrote:
> Yes, I have tried like this:
>
> {
> pinctrl-names = "default";
> pinctrl-0 = <_uart4>;
> uart-has-rtscts;
> status = "okay";
> };
>
> pinctrl_uart4: uart4grp {
> fsl,pins = <
>
Hi Clemens,
On Fri, Jan 6, 2017 at 8:50 PM, Clemens Gruber
wrote:
> But according to the i.MX Pins tool, they can be muxed vice-versa too.
> So if you connected the transceiver-enable to ball L4 (CSI0_DAT16), you
> could mux MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B and
>
Hi Clemens,
On Fri, Jan 6, 2017 at 8:50 PM, Clemens Gruber
wrote:
> But according to the i.MX Pins tool, they can be muxed vice-versa too.
> So if you connected the transceiver-enable to ball L4 (CSI0_DAT16), you
> could mux MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B and
>
Hi Fabio,
On Fri, Jan 06, 2017 at 07:22:32PM -0200, Fabio Estevam wrote:
> Hi Clemens,
>
> On Wed, Jan 4, 2017 at 2:00 PM, Clemens Gruber
> wrote:
> > Hi,
> >
> > I observed odd behavior of the current tty/serial/imx.c driver in RS-485
> > mode.
> >
> > RX works
Hi Fabio,
On Fri, Jan 06, 2017 at 07:22:32PM -0200, Fabio Estevam wrote:
> Hi Clemens,
>
> On Wed, Jan 4, 2017 at 2:00 PM, Clemens Gruber
> wrote:
> > Hi,
> >
> > I observed odd behavior of the current tty/serial/imx.c driver in RS-485
> > mode.
> >
> > RX works fine, but TX does not: When
Hi Clemens,
On Wed, Jan 4, 2017 at 2:00 PM, Clemens Gruber
wrote:
> Hi,
>
> I observed odd behavior of the current tty/serial/imx.c driver in RS-485
> mode.
>
> RX works fine, but TX does not: When sending data, it arrives multiple
I am also trying to get rs485 in
Hi Clemens,
On Wed, Jan 4, 2017 at 2:00 PM, Clemens Gruber
wrote:
> Hi,
>
> I observed odd behavior of the current tty/serial/imx.c driver in RS-485
> mode.
>
> RX works fine, but TX does not: When sending data, it arrives multiple
I am also trying to get rs485 in half-duplex mode to work on
Hi,
I observed odd behavior of the current tty/serial/imx.c driver in RS-485
mode.
RX works fine, but TX does not: When sending data, it arrives multiple
times and with data from previous transmissions at the end, after a
delay.
# My setup
Hardware:
i.MX6Q board with UARTn_RX_DATA, _TX_DATA
Hi,
I observed odd behavior of the current tty/serial/imx.c driver in RS-485
mode.
RX works fine, but TX does not: When sending data, it arrives multiple
times and with data from previous transmissions at the end, after a
delay.
# My setup
Hardware:
i.MX6Q board with UARTn_RX_DATA, _TX_DATA
34 matches
Mail list logo