[PATCH 1/3] ARM: dts: sunxi: h3/h5: add missing uart2 rts/cts pins
uart1 and uart3 had existing pin definitions for the rts/cts pairs.
Add definitions for uart2 as well.
Signed-off-by: Karl Palsson
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index a4c757c0b741..38d3deefa0e3 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -472,6 +472,11 @@
function = "uart2";
};
+ uart2_rts_cts_pins: uart2_rts_cts {
+ pins = "PA2", "PA3";
+ function = "uart2";
+ };
+
uart3_pins: uart3 {
pins = "PA13", "PA14";
function = "uart3";
--
2.14.5
[PATCH 2/3] ARM: dts: sun8i: add FriendlyARM NanoPi Duo2
This is an Allwinner H3 based board, with 512MB ram, a USB OTG port,
microsd slot, an onboard AP6212A wifi/bluetooth module, and a CSI
connector.
Full details and schematic available from vendor:
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_Duo2
Signed-off-by: Karl Palsson
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts | 148 +
2 files changed, 149 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 78551c4375d5..7f296bfea94a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1063,6 +1063,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-h3-beelink-x2.dtb \
sun8i-h3-libretech-all-h3-cc.dtb \
sun8i-h3-mapleboard-mp130.dtb \
+ sun8i-h3-nanopi-duo2.dtb \
sun8i-h3-nanopi-m1.dtb \
sun8i-h3-nanopi-m1-plus.dtb \
sun8i-h3-nanopi-neo.dtb \
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts
b/arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts
new file mode 100644
index ..07d2f1bebd56
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Karl Palsson
+ */
+
+/dts-v1/;
+#include "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include
+#include
+
+/ {
+ model = "FriendlyARM NanoPi Duo2";
+ compatible = "friendlyarm,nanopi-duo2", "allwinner,sun8i-h3";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ status {
+ label = "nanopi:green:status";
+ gpios = <&pio 0 10 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ pwr {
+ label = "nanopi:red:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ r_gpio_keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&sw_r_npi>;
+
+ k1 {
+ label = "k1";
+ linux,code = ;
+ gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ reg_vdd_cpux: vdd-cpux-regulator {
+ compatible = "regulator-gpio";
+ regulator-name = "vdd-cpux";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <110>;
+ regulator-max-microvolt = <130>;
+ regulator-ramp-delay = <50>; /* 4ms */
+
+ gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
+ enable-active-high;
+ gpios-states = <0x1>;
+ states = <110 0x0
+ 130 0x1>;
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>; /* PL7 */
+ };
+
+};
+
+&cpu0 {
+ cpu-supply = <®_vdd_cpux>;
+};
+
+&usb_otg {
+ status = "okay";
+ dr_mode = "otg";
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+®_usb0_vbus {
+ gpio = <&r_pio 0 2 GPIO_ACTIVE_HIGH>; /* PL2 */
+ status = "okay";
+};
+
+&r_pio {
+ sw_r_npi: key_pins {
+ pins = "PL3";
+ function = "gpio_in";
+ };
+};
+
+&usbphy {
+ usb0_id_det-gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
+ usb0_vbus-supply = <®_usb0_vbus>;
+ status = "okay";
+};
+
+&mmc0 {
+ bus-width = <4>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
+ status = "okay";
+ vmmc-supply = <®_vcc3v3>;
+};
+
+&mmc1 {
+ vmmc-supply = <®_vcc3v3>;
+ vqmmc-supply = <®_vcc3v3>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ sdio_wifi: sdio_wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&pio>;
+ interrupts = <6 10 IRQ_TYPE_LEVEL_LOW>; /* PG10 / EINT10 */
+ interrupt-names = "host-wake";
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>, <&uart2_rts_cts_pins>;
+ uart-has-rtscts;
+ status = "okay";
+
+ /* bluetooth goes here */
+};
--
2.14.5
[PATCH 3/3] ARM: dts: sun8i: add FriendlyARM NanoPi Duo2-IoT Box
The IoT-Box is a dock for the NanoPi Duo2, adding two USB host ports, a
10/100 ethernet port, a variety of pin headers for i2c and uarts, and a
quad band 2G GSM module, a SIM800C.
Full documentation and schematics available from vendor:
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_Duo2_IoT-Box
Signed-off-by: Karl Palsson
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/sun8i-h3-nanopi-duo2-iotbox.dts | 45 +++
2 files changed, 46 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h3-nanopi-duo2-iotbox.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7f296bfea94a..b62d84639c7a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1064,6 +1064,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-h3-libretech-all-h3-cc.dtb \
sun8i-h3-mapleboard-mp130.dtb \
sun8i-h3-nanopi-duo2.dtb \
+ sun8i-h3-nanopi-duo2-iotbox.dtb \
sun8i-h3-nanopi-m1.dtb \
sun8i-h3-nanopi-m1-plus.dtb \
sun8i-h3-nanopi-neo.dtb \
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-duo2-iotbox.dts
b/arch/arm/boot/dts/sun8i-h3-nanopi-duo2-iotbox.dts
new file mode 100644
index ..4e7fae4046a8
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-duo2-iotbox.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Karl Palsson
+ */
+
+#include "sun8i-h3-nanopi-duo2.dts"
+
+/ {
+ model = "FriendlyARM NanoPi Duo2 IoT Box";
+ compatible = "friendlyarm,nanopi-duo2-iotbox",
+ "friendlyarm,nanopi-duo2",
+ "allwinner,sun8i-h3";
+};
+
+&ehci2 {
+ status = "okay";
+};
+
+&ehci3 {
+ status = "okay";
+};
+
+&ohci2 {
+ status = "okay";
+};
+
+&ohci3 {
+ status = "okay";
+};
+
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
+/* Not addressed, SIM800C module on uart3 */
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins>, <&uart3_rts_cts_pins>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
--
2.14.5
Re: Re: [PATCH] USB: serial: add nt124 usb to serial driver
Johan Hovold wrote: > On Mon, Dec 08, 2014 at 05:24:17PM -0600, George McCollister wrote: > > + newline.bParityType = termios->c_cflag & PARENB ? > > + (termios->c_cflag & PARODD ? 1 : 2) + > > + (termios->c_cflag & CMSPAR ? 2 : 0) : 0; > > This hardly readable. Don't use ?: > There's also C_PARENB(tty), C_PARODD(tty), and C_CMSPAR(tty) macros available, in addition to the others that Johan pointed out. Sincerely, Karl P
Re: [PATCH v2] ARM: dts: rockchip: use internal pull-up resistors on I2C busses
I'd be more inclined to have pulls disabled by default, it's more standard with
what smaller
micros do, but I've no experience with these bigger cortex-a parts. It's also
the "least
surprise" path. If you want to try and use the onboard pullups, you can
specify that in your
board file, but for people deliberately selecting pullups for their timing and
load expectations,
being required to take an extra step to turn off something seems unexpected.
If you _want_ to be able to probe an i2c bus for devices added aftermarket, on
a board that
didn't get i2c pull ups because no devices were planned, and you want to turn
on the internal
pullups for that, I think that's something you need to do yourself, not making
it a hard default
in the SoC dtsi file.
so, if it's off by default, you get this
dtsi dts
Board1, i2c periphs, designed pullups => off -
board2, no peripsh, pulls in case => off -
board3, no periphs, forgot pulls, pray=> offon
If you turn it on by default, sure, it causes no harm in most cases, but you're
no longer getting
the values you expect, without having to turn off things that are not default
anyway.
Sincerely,
Karl Palsson
On Wed, Oct 29, 2014 at 02:17:23PM +0100, Heiko Stübner wrote:
> Hi Addy, Max, Wolfram,
>
> after Doug's explanation of disfavour [0] and Julien's subsequent response I'm
> not sure which direction to go. So if possible I'd like to collect some more
> opinions of people knowing a lot more about i2c internals than myself :-) .
>
>
> Thanks
> Heiko
>
>
> [0]
> http://lists.infradead.org/pipermail/linux-rockchip/2014-October/000934.html
>
> Am Dienstag, 28. Oktober 2014, 11:36:36 schrieb Julien CHAUVEAU:
> > According to the I2C bus specification, it is required to use pull-up
> > resistors on the clock and data lines. Probing the I2C busses with
> > i2cdetect results in bad results when no devices are connected and no
> > external resistors are used.
> >
> > This patch configures the I2C busses to use the internal pull-up resistors
> > on the RK3066, RK3188 and RK3288 Rockchip processors. It should also be
> > noted that these default pull settings match the original configuration on
> > these SoCs.
> >
> > Below is the results of using i2cdetect on a I2C bus with no devices
> > connected before (1) and after (2) applying this patch.
> >
> > (1) root@localhost:~# i2cdetect -y 3
> > 0 1 2 3 4 5 6 7 8 9 a b c d e f
> > 00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
> > 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
> > 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
> > 30: -- -- -- -- -- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x81, state: 2
> > -- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 2
> > -- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 2
> > -- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 3
> > -- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 3
> > -- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 3
> > ...
> >
> > (2) root@localhost:~# i2cdetect -y 3
> > 0 1 2 3 4 5 6 7 8 9 a b c d e f
> > 00: -- -- -- -- -- -- -- -- -- -- -- -- --
> > 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > 70: -- -- -- -- -- -- -- --
> >
> > Signed-off-by: Julien CHAUVEAU
> > ---
> > Changes since v1:
> > - fix the rk3066a pull settings (only available is pull_none/pull_default)
> > - remove the warnings in the results of i2cdetect
> >
> > arch/arm/boot/dts/rk3066a.dtsi | 20 ++--
> > arch/arm/boot/dts/rk3188.dtsi | 20 ++--
> > arch/arm/boot/dts/rk3288.dtsi | 24
> > 3 files changed, 32 insertions(+), 32 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> > index ad9c2db..dbc1a0b 100644
> > --- a/arch/arm/boot/dts/rk3066a.dtsi
> > +++ b/arch/arm/boot/dts/rk3066a.dtsi
> > @@ -202,36 +202,36 @@
> >
> > i2c0 {
> > i2c0_xfer: i2c0-xfer {
> > - rockchip,pins = > &pcfg_pull_none>,
> > -> &
Re: [PATCH v2] ARM: dts: rockchip: use internal pull-up resistors on I2C busses
However, and possibly out of line, but should we consider submitting a patch to remove the pullups by default for exynos that Doug hinted at? Cheers, Karl P On Wed, Oct 29, 2014 at 03:34:27PM +0100, NEO-Technologies / Julien CHAUVEAU wrote: > Hi everyone, > > Okay, I understand your opinion. So let's drop my patch in this case. > > Thank you for your comments. > > Julien > > > Le 29/10/2014 15:02, Max Schwarz a écrit : > >Hi, > > > >I'll agree with Karl and Doug. If you (as a board vendor/maintainer/etc) want > >to use I2C, it's *your* responsibility to provide the pullup resistors by > >either including pullup resistors on the board or by enabling the internal > >ones. > >Either way, you should think a moment about the consequences (frequency/trace > >length limitations), which is why I'm also against the pullup-by-default > >behavior. > > > >Also, it's much harder to diagnose effects like Doug is describing (slightly > >out-of-spec due to internal + external pulls) than the effects you are seeing > >without any pullups. With your i2cdetect results my first thought would have > >been "are there pullups on the bus?". > > > >Cheers, > > Max > > > >Am Mittwoch, 29. Oktober 2014, 13:44:15 schrieb Karl Palsson: > >>I'd be more inclined to have pulls disabled by default, it's more standard > >>with what smaller micros do, but I've no experience with these bigger > >>cortex-a parts. It's also the "least surprise" path. If you want to try > >>and use the onboard pullups, you can specify that in your board file, but > >>for people deliberately selecting pullups for their timing and load > >>expectations, being required to take an extra step to turn off something > >>seems unexpected. > >> > >>If you _want_ to be able to probe an i2c bus for devices added aftermarket, > >>on a board that didn't get i2c pull ups because no devices were planned, > >>and you want to turn on the internal pullups for that, I think that's > >>something you need to do yourself, not making it a hard default in the SoC > >>dtsi file. > >> > >>so, if it's off by default, you get this > >> dtsi dts > >>Board1, i2c periphs, designed pullups => off - > >>board2, no peripsh, pulls in case => off - > >>board3, no periphs, forgot pulls, pray=> offon > >> > >>If you turn it on by default, sure, it causes no harm in most cases, but > >>you're no longer getting the values you expect, without having to turn off > >>things that are not default anyway. > >> > >>Sincerely, > >>Karl Palsson > >> > >>On Wed, Oct 29, 2014 at 02:17:23PM +0100, Heiko Stübner wrote: > >>>Hi Addy, Max, Wolfram, > >>> > >>>after Doug's explanation of disfavour [0] and Julien's subsequent response > >>>I'm not sure which direction to go. So if possible I'd like to collect > >>>some more opinions of people knowing a lot more about i2c internals than > >>>myself :-) . > >>> > >>> > >>>Thanks > >>>Heiko > >>> > >>> > >>>[0] > >>>http://lists.infradead.org/pipermail/linux-rockchip/2014-October/000934.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
block: DISK_MEDIA_CHANGE uevents vs add/remove events
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm trying to get userspace to properly mount/unmount a microSD card attached to a (built in) usb card reader (SMSC2640) when the card is inserted/removed from the slot. On Fedora/Gnome, this is being handled by the udisks daemon and using the uevent-hotplug debugger example from https://www.kernel.org/doc/pending/hotplug.txt and "udevadm monitor" I can see the kernel creates the two change events, and the final add event, the first change event with DISK_MEDIA_CHANGE=1 for /dev/sda, (the card reader slot), and ending with a "remove" event for /dev/sda1 (the partition itself) I'm working on OpenWrt, without the udisks daemon, but OpenWrt's userspace is still properly handling the "add" and "remove" events and mounting/unmounting, _if_ it gets them. However, I don't see the add or remove events there. I have to explicitly run a command that touches /dev/sda to trigger anything, and then I only get a single "change" event. (or use the in kernel polling[1]) My question is then really: 1: Why don't I get the add/remove events? Who is _really_ responsible for them? Or alternatively, is userspace _meant_ to be handling this directly from the "change" events? I see that with a CD-ROM, there are no kernel add/remove events, only change events, unlike SD cards. Sincerely, Karl Palsson [1] Using the "in kernel" event polling with "echo 250 > /sys/block/sda/events_poll_msecs" and then using usbmon, I can see the SCSI LUN check polling happening, and I can immediately see the uevents for "change" events. Yay. that's nice. Originally I wrote this mail while testing linux 3.18, where this _didn't_ work. But upgrading to 4.1.16 fixed this, so one less thing to worry about :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJWzI5wAAoJEBmotQ/U1cr2iMYP/A+uDtxaRGSfwqAVInjli4kD BDZqjGnv9S3AkEMK9GWrCb6QLl/4h+YeXDVge0LPsBozaK8e5CSz+82B1ZyuZNH9 fJAxzVrsgLlg1YVf2b4Z0p2Fwa5e91qZtrBAh2IgkyEMJFUljb5+fnhYNC/09k17 EDFyF684k65Rc8o9VcvkkxxZea0BuunCFfkfWf81OnPtmvtv4yaIjSrcxRLzg1DN DCujidVZIflAIhH22+ATGqXRAXsbRqAf5rwHkNdytizHNGMdmNiFDdhzibYZNhxN YIv3EetjqcFYio7PCL10nReW7hA0mMqFSjcb0gpy+begadFpK+y7LfnDj5MOPFja 2q/jGhPyxgDmGzM9v+bZNWobWYOj/bJD9frclturJp1LiQHoh6We9sOOQ8XR8S13 aZRTGcZkBIBSU0kirEDWIsP6zVtoIkDsE/fZuV9pNTrycqlWgkr4ZY1uWuPIMW76 828gAlNI0PsiIilaAx7JZ7wUDa5WW4IQ6owSkV+uetB8Dqp4fq/UBcPWGatnD2wz KucEwtbbc54vthJjS2aHeln4qIsWPYKKWAo8orMN9KWd6A8Ohv9juWUyy6qsiZ+W zKLyOU4SyNiT46dKsXUFtozhvwfN4QkKXWaAUy1qVHbNQzebIN39DXMOaIkw2hOW 0SBGpyowQWZpE1itssvz =EH8A -END PGP SIGNATURE-
Re: [PATCH v2 07/14] USB: ch341: add support for parity, frame length, stop bits
Grigori Goronzy wrote:
> With the new reinitialization method, configuring parity,
> different frame lengths and different stop bit settings work as
> expected on both CH340G and CH341A. This has been extensively
> tested with a logic analyzer.
>
> Tested-by: Ryan Barber
> Signed-off-by: Grigori Goronzy
> ---
> drivers/usb/serial/ch341.c | 36 ++--
> 1 file changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/serial/ch341.c
> b/drivers/usb/serial/ch341.c index c001773..4d66f0f 100644
> --- a/drivers/usb/serial/ch341.c
> +++ b/drivers/usb/serial/ch341.c
> @@ -346,6 +346,7 @@ static void ch341_set_termios(struct tty_struct *tty,
> unsigned baud_rate;
> unsigned long flags;
> unsigned char ctrl;
> + unsigned cflag = tty->termios.c_cflag;
> int r;
>
> /* redundant changes may cause the chip to lose bytes */
> @@ -356,7 +357,35 @@ static void ch341_set_termios(struct tty_struct *tty,
>
> priv->baud_rate = baud_rate;
>
> - ctrl = CH341_LCR_ENABLE_RX | CH341_LCR_ENABLE_TX | CH341_LCR_CS8;
> + ctrl = CH341_LCR_ENABLE_RX | CH341_LCR_ENABLE_TX;
> +
> + switch (cflag & CSIZE) {
> + case CS5:
> + ctrl |= CH341_LCR_CS5;
> + break;
> + case CS6:
> + ctrl |= CH341_LCR_CS6;
> + break;
> + case CS7:
> + ctrl |= CH341_LCR_CS7;
> + break;
> + case CS8:
> + default:
> + ctrl |= CH341_LCR_CS8;
> + break;
> + }
> +
> + if (cflag & PARENB) {
> + ctrl |= CH341_LCR_ENABLE_PAR;
> + if ((cflag & PARODD) == 0)
> + ctrl |= CH341_LCR_PAR_EVEN;
> + }
> +
> + if (cflag & CMSPAR)
> + ctrl |= CH341_LCR_MARK_SPACE;
> +
> + if (cflag & CSTOPB)
> + ctrl |= CH341_LCR_STOP_BITS_2;
>
I think this should be moved up to the PARENB check, at least,
when I was working on this. Also there's macros for some of the
flag checks: (From some code I was working on, but you can see
the mark/space is differently handled, this matched the windows
driver I was reversing usb captures from.)
if (C_PARENB(tty)) {
*lcr |= CH341_LCR_PARITY;
if (C_CMSPAR(tty)) {
*lcr |= CH341_LCR_SPAR;
if (C_PARODD(tty)) {
dev_dbg(&port->dev, "parity = mark\n");
*lcr &= ~CH341_LCR_EPAR;
} else {
dev_dbg(&port->dev, "parity = space\n");
*lcr |= CH341_LCR_EPAR;
}
} else {
*lcr &= ~CH341_LCR_SPAR;
if (C_PARODD(tty)) {
dev_dbg(&port->dev, "parity = odd\n");
*lcr &= ~CH341_LCR_EPAR;
} else {
dev_dbg(&port->dev, "parity = even\n");
*lcr |= CH341_LCR_EPAR;
}
}
} else {
*lcr &= ~(CH341_LCR_PARITY | CH341_LCR_SPAR | CH341_LCR_EPAR);
dev_dbg(&port->dev, "parity = none\n");
}
> if (baud_rate) {
> spin_lock_irqsave(&priv->lock, flags);
> @@ -373,11 +402,6 @@ static void ch341_set_termios(struct tty_struct *tty,
>
> ch341_set_handshake(port->serial->dev, priv->line_control);
>
> - /* Unimplemented:
> - * (cflag & CSIZE) : data bits [5, 8]
> - * (cflag & PARENB) : parity {NONE, EVEN, ODD}
> - * (cflag & CSTOPB) : stop bits [1, 2]
> - */
> }
>
> static void ch341_break_ctl(struct tty_struct *tty, int break_state)
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-usb" in the body of a message to
> majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 14/14] USB: ch341: implement tx_empty callback
Grigori Goronzy wrote:
> The status bit was found with USB captures of the Windows
> driver and some luck. Tested on CH340G and CH341A.
By my reversing, bit 0x4, is "multiple status changes since last
interrupt"
>
> Signed-off-by: Grigori Goronzy
> ---
> drivers/usb/serial/ch341.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/serial/ch341.c
> b/drivers/usb/serial/ch341.c index 6981e2ad..adf7d79 100644
> --- a/drivers/usb/serial/ch341.c
> +++ b/drivers/usb/serial/ch341.c
> @@ -82,6 +82,8 @@
> #define CH341_LCR_CS6 0x01
> #define CH341_LCR_CS5 0x00
>
> +#define CH341_STATUS_TXBUSY0x01
> +
> static const struct usb_device_id id_table[] = {
> { USB_DEVICE(0x4348, 0x5523) },
> { USB_DEVICE(0x1a86, 0x7523) },
> @@ -95,6 +97,7 @@ struct ch341_private {
> unsigned baud_rate; /* set baud rate */
> u8 line_control; /* set line control value RTS/DTR */
> u8 line_status; /* active status of modem control inputs */
> + u8 uart_status; /* generic UART status bits */
> };
>
> static void ch341_set_termios(struct tty_struct *tty,
> @@ -187,7 +190,8 @@ static int ch341_get_status(struct usb_device *dev,
> struct ch341_private *priv)
> if (r == 2) {
> r = 0;
> spin_lock_irqsave(&priv->lock, flags);
> - priv->line_status = (~(*buffer)) & CH341_BITS_MODEM_STAT;
> + priv->line_status = (~buffer[0]) & CH341_BITS_MODEM_STAT;
> + priv->uart_status = buffer[1];
> spin_unlock_irqrestore(&priv->lock, flags);
> } else {
> r = -EPROTO;
> @@ -198,6 +202,18 @@ out:
> return r;
> }
>
> +static bool ch341_tx_empty(struct usb_serial_port *port)
> +{
> + int r;
> + struct ch341_private *priv = usb_get_serial_port_data(port);
> +
> + r = ch341_get_status(port->serial->dev, priv);
> + if (r < 0)
> + return true;
> +
> + return !(priv->uart_status & CH341_STATUS_TXBUSY);
> +}
> +
> /*
> -- */
>
> static int ch341_configure(struct usb_device *dev, struct ch341_private
> *priv)
> @@ -606,6 +622,7 @@ static struct usb_serial_driver ch341_device = {
> .carrier_raised= ch341_carrier_raised,
> .close = ch341_close,
> .set_termios = ch341_set_termios,
> + .tx_empty = ch341_tx_empty,
> .break_ctl = ch341_break_ctl,
> .tiocmget = ch341_tiocmget,
> .tiocmset = ch341_tiocmset,
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-usb" in the body of a message to
> majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/13] USB: ch341: add support for parity, frame length, stop bits
Sorry if you get this twice, I was having some client problems,
but wanted to make sure you got this one...
Grigori Goronzy wrote:
> With the new reinitialization method, configuring parity,
> different frame lengths and different stop bit settings work as
> expected on both CH340G and CH341A. This has been extensively
> tested with a logic analyzer.
>
> v2: only set mark/space when parity is enabled,
> simplifications, patch termios HW flags.
>
> Tested-by: Ryan Barber
> Signed-off-by: Grigori Goronzy
> ---
> drivers/usb/serial/ch341.c | 40 ++--
> 1 file changed, 30 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/usb/serial/ch341.c
> b/drivers/usb/serial/ch341.c index 6181616..99b4621 100644
> --- a/drivers/usb/serial/ch341.c
> +++ b/drivers/usb/serial/ch341.c
> @@ -341,7 +341,6 @@ static void ch341_set_termios(struct tty_struct *tty,
> struct usb_serial_port *port, struct ktermios *old_termios)
> {
> struct ch341_private *priv = usb_get_serial_port_data(port);
> - unsigned baud_rate;
> unsigned long flags;
> unsigned char ctrl;
> int r;
> @@ -350,13 +349,39 @@ static void ch341_set_termios(struct tty_struct *tty,
> if (old_termios && !tty_termios_hw_change(&tty->termios, old_termios))
> return;
>
> - baud_rate = tty_get_baud_rate(tty);
> + priv->baud_rate = tty_get_baud_rate(tty);
>
> - priv->baud_rate = baud_rate;
> + ctrl = CH341_LCR_ENABLE_RX | CH341_LCR_ENABLE_TX;
>
> - ctrl = CH341_LCR_ENABLE_RX | CH341_LCR_ENABLE_TX | CH341_LCR_CS8;
> + switch (C_CSIZE(tty)) {
> + case CS5:
> + ctrl |= CH341_LCR_CS5;
> + break;
> + case CS6:
> + ctrl |= CH341_LCR_CS6;
> + break;
> + case CS7:
> + ctrl |= CH341_LCR_CS7;
> + break;
> + default:
> + tty->termios.c_cflag |= CS8;
> + case CS8:
> + ctrl |= CH341_LCR_CS8;
> + break;
> + }
> +
> + if (C_PARENB(tty)) {
> + ctrl |= CH341_LCR_ENABLE_PAR;
> + if (C_PARODD(tty))
> + ctrl |= CH341_LCR_PAR_EVEN;
Are you sure this does the right thing now? this is, as best as I
can tell, the inverse of what you had earlier, and doesn't read
right, if this is working, then I suggest renaming _LCR_PAR_EVEN
to LCR_PAR_ODD?
Cheers,
Karl P
> + if (C_CMSPAR(tty))
> + ctrl |= CH341_LCR_MARK_SPACE;
> + }
> +
> + if (C_CSTOPB(tty))
> + ctrl |= CH341_LCR_STOP_BITS_2;
>
> - if (baud_rate) {
> + if (priv->baud_rate) {
> spin_lock_irqsave(&priv->lock, flags);
> priv->line_control |= (CH341_BIT_DTR | CH341_BIT_RTS);
> spin_unlock_irqrestore(&priv->lock, flags);
> @@ -373,11 +398,6 @@ static void ch341_set_termios(struct tty_struct *tty,
>
> ch341_set_handshake(port->serial->dev, priv->line_control);
>
> - /* Unimplemented:
> - * (cflag & CSIZE) : data bits [5, 8]
> - * (cflag & PARENB) : parity {NONE, EVEN, ODD}
> - * (cflag & CSTOPB) : stop bits [1, 2]
> - */
> }
>
> static void ch341_break_ctl(struct tty_struct *tty, int break_state)
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-usb" in the body of a message to
> majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
signature.asc
Description: OpenPGP Digital Signature
Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Douglas Anderson wrote: > > + /* > + * Sleep for 10-15 ms after the reset to let it finish. > + * > + * It's been confirmed on at least one version of the controller > + * that this is a requirement that this is a requirement in order for ^^ duplicate wording here. Cheers, Karl P -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJW2h5AAAoJEBmotQ/U1cr2izQQAJ26Rnz1arSPnccUXyOilD9g vkf6wEEZNHsQUsnrzLbY9+x7rUAWgK6Wq+LYFv7vsOL63ogKpf6O52bZVE0/KQkT IABKZB312AecotpbSdsZBXaK1SYFUXSRd0CDHqnL9o7SBE2sNRVVd+e/h2z45hUg H2KkHZbzJA5btZveR+kkYX8PzV3QTBAmgqZ4YjI3uFllQtcRyJflYg9lJNm/GzpG +ckG/JDlfSfv8Y4C7CrvCot0iTktLXFgzYO8ftI2z8ZAbV2IP3kOf2sc+8b+TX34 yI3odnpf+N0lNQhJESQaYAbOLF45SLGbFK5cqi1zi0AuHJA2eTISOOZWo5Zl/nhE vneDG6zkS2q0YQRJlBIq23KxTdT9WJjW6qNs+OhVFo5k1900GWtuibfKr43g7JeF l2d5uVeL9trwDUNmMvyGelSRXL12DhJ/k3IX1TgVMPsfACbGFWS74nzWfdHYjTUS 48ou5a9QED632Na1ZsxhSa1Ce4IOn7Uhaa13WIjKqo8IZM5TXEWwTAczF/9lLpBM kz4Gb1tII5lQt0KpTOMHs/rXs0/k9iq0x0zuSUVNQEYJrAPhcJ/r+SBRJMqQb5Zy jzsMzWiuYrL7hpAjQv9s9vyJdQT+/IlIhgM3g+MiQat+LO3uUO10xIspK1+hIglJ A9VTP1o6Il8hRlQGrqLl =p21r -END PGP SIGNATURE-
Re: [PATCH v7 1/5] leds: core: add generic support for RGB LED's
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Heiner Kallweit wrote: > Add generic support for RGB LED's. > > Basic idea is to use enum led_brightness also for the hue and > saturation color components.This allows to implement the color > extension w/o changes to struct led_classdev. > > Select LEDS_RGB to enable building drivers using the RGB > extension. > > Flag LED_SET_HUE_SAT allows to specify that hue / saturation > should be overridden even if the provided values are zero. > > Some examples for writing values to > /sys/class/leds//brightness: (now also hex notation can be > used) > > 255 -> set full brightness and keep existing color if set 0 -> > switch LED off but keep existing color so that it can be > restored > if the LED is switched on again later > 0x100 -> switch LED off and set also hue and saturation to > 0 0x00 -> set full brightness, full saturation and set hue > to 0 (red) > I admit I hadn't seen this earlier, and I didn't spend all day looking at previous attempts, but what's the motivation for putting all this overloaded syntax into the "brightness" file? I thought the point was to have a single value in each file, one of the references I did find was http://www.spinics.net/lists/linux-leds/msg02995.html Is there some thread where this was decided as advantageous? Surely 0-255 for _brightness_ is what the brightness entry should do? I'd like to set the rgb colour of a led (or hsv, that can be it's own file too) and separately ramp the brightness up and down. I also think it's substantially simpler and easier to use from the user's point of view, which is surely the place you want easy right? Sincerely, Karl Palsson -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJW3Jk5AAoJEBmotQ/U1cr2fxYP/AsuQ/x8ky86S9xf9Y8UdRrk IC7eouBpf07RsDTv2KobRwEH69tk12zxGKmOpNZ5SY8ozVT/VDXMA8Iw/cwKL2t4 EBWTdBhORrOlfxw0sykp4SXYSYBm9n2Z+xZGK9b/fN+2g+XCv4B+W2iDejyvAsIt c/eH6dGR0PvYdovEh0Tq7qAflpXRAhU0ykRR0Ydq/HrF8Xfxi+MDHC99zTRrHIsV rPTbPh26cxZ3zyOoUxwgPLNmm4O1BvMsghxuQXV49A95gOlRet+ewDQxBgwWabEp AUh3fuOl53R/ODJSqjX/JjlO4ynXWgv/9kdCF8QwPUAl13gyhilPvIdI5O3gm3Nr beiW/rUnvHej3ZxbRUe/Q8ZlQ099WTVH4cEgSxLclC5hiWm4dCjsjskJA1acbnZV 4w5WSqrAqSyNP81Rhy7WV6k8kazDUrASSAl4JFnNJVRC4WNdHQJA4pKkH08mtYyo 5ls3ydMzU2eiTNKCFEze4/cH3MgUWM+L29rLRzev6rT7s32rPzR0JKaKv460pocd rjpKanbt+zgUVySprVzX4t4GsmDZtKjQkTGooz9BabZP5+WeVvDtEMK3kciZ1d/x ubtvcMXGbDpZ0FMcQkTQj44Sq3wMdr3P0CoMiDspDGk7XY67gSXsmUgSSh0JTLRL X4K67h/OUpH0A00XGZCO =86mG -END PGP SIGNATURE-
Re: [PATCH v7 1/5] leds: core: add generic support for RGB LED's
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > I admit I hadn't seen this earlier, and I didn't spend all day > > looking at previous attempts, but what's the motivation for > > putting all this overloaded syntax into the "brightness" file? I > > thought the point was to have a single value in each file, one of > > the references I did find was > > http://www.spinics.net/lists/linux-leds/msg02995.html Is there > > some thread where this was decided as advantageous? Surely 0-255 > > for _brightness_ is what the brightness entry should do? > > > The referenced mail thread refers to a proposed sysfs attribute > holding a list of space-separated entries. Here it's still > about one numeric value. Advantage of the approach used now is > the full backwards compatibilty. You can still set brightness > to 0..255 and only the brightness will change (as expected). Or > in other words: So far only V was supported, now we support HSV > as a superset. > > > I'd like to set the rgb colour of a led (or hsv, that can be it's > > own file too) and separately ramp the brightness up and down. I > > also think it's substantially simpler and easier to use from the > > user's point of view, which is surely the place you want easy > > right? > > > What you describe is perfectly possible with the new approach. > Only by using magically different formats for what I write to the file labelled "brightness" I'm really not a fan of a knob called "brightness" that does _other things_ if you write something different to it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJW3LXbAAoJEBmotQ/U1cr2fdUQAKONfj98SS2b4zcHheXG4+ts PfiyS3nhh3VxlNykJSF13ou6ZBgYs4vuTVFuXO2Vya07TFWGrRM4ZNM0d+3JU7BY QkDq8nhqYkxBmIvuz3dgmr+HrMShT/ECQoOYSoIq9bAHpXj0v+eCvYnlLseVLBGx inwgyBme0jSiXvITRDBc0YM0wvpnh492UlruOHGsGkoTSaPaBXU8E+Uv4sv+y448 muYI9M3l+4Lg+B5k9UyXEvwCi2pyLJ2pSGbXyk6flSWYxI92Mny0decOQ+myJqEr sfIqOczGbXFXiWXo8oX2i/Dm9+b+ChrMEXAtcfMcuB+9+469p/2eoqcCCtMWnAUJ qmM8h37mNoohwDIv9c4blG2Y2854n6L2R7ZCXGMZj1Thidmn7ANNhnIFp+ojyXsz O/JSongYWxX4b9pMQ8QhZFRCXfi/V7c/0RDREN5IcjB5nm+1W4Wr/u0jqDGsD7hW kYgWHLbRzBtjOk7ruyDRBNlUyV+xCwxmYgmHAo3Ko3ZPs0MAPQoD+u6mtG5BPDkY ek8ek7+Zw1V8MQSKp1LEfVr6GX5rTkaTD13odbC8PcMYACAC6NKFDqS1NNvSclKv nUyccdaxw0NU4WZtG1dalvJGMwMj6z5MT9BjlE9JvSs4vROYx7RGOQvGvxw9syJT j5AL5VA86J8n30tDXFuy =hUju -END PGP SIGNATURE-
