[PATCH v2 6/6] arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster

[Wesley Cheng]

Add the required DTS node for the USB VBUS output regulator, which is
available on PM8150B.  This will provide the VBUS source to connected
peripherals.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi   | 6 ++
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index ec44a8bc2f84..b7274d9d7341 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,12 @@ power-on@800 {
status = "disabled";
};
 
+   qcom,dcdc@1100 {
+   compatible = "qcom,pm8150b-vbus-reg";
+   status = "disabled";
+   reg = <0x1100>;
+   };
+
qcom,typec@1500 {
compatible = "qcom,pm8150b-usb-typec";
status = "disabled";
diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts 
b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
index 6c6325c3af59..3845d19893eb 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
@@ -426,6 +426,13 @@ _1 {
status = "okay";
 };
 
+_bus {
+   pmic@2 {
+   qcom,dcdc@1100 {
+   status = "okay";
+   };
+};
+
 _1_dwc3 {
dr_mode = "peripheral";
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 2/6] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding

[Wesley Cheng]

Introduce the dt-binding for enabling USB type C orientation and role
detection using the PM8150B.  The driver will be responsible for receiving
the interrupt at a state change on the CC lines, reading the orientation/role,
and communicating this information to the remote clients, which can include
a role switch node and a type C switch.

Signed-off-by: Wesley Cheng 
---
 .../bindings/usb/qcom,pmic-typec.yaml | 117 ++
 1 file changed, 117 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml

diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml 
b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
new file mode 100644
index ..085b4547d75a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/qcom,pmic-typec.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Qualcomm PMIC based USB type C Detection Driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  Qualcomm PMIC Type C Detect
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-usb-typec
+
+  reg:
+maxItems: 1
+description: Type C base address
+
+  interrupts:
+maxItems: 1
+description: CC change interrupt from PMIC
+
+  connector:
+description: Connector type for remote endpoints
+type: object
+
+properties:
+  compatible:
+enum:
+  - usb-c-connector
+
+  power-role:
+   enum:
+ - dual
+ - source
+ - sink
+
+  data-role:
+enum:
+  - dual
+  - host
+  - device
+
+  port:
+description: Remote endpoint connections
+type: object
+
+properties:
+  endpoint@0:
+description: Connection to USB type C mux node
+type: object
+
+properties:
+  remote-endpoint:
+maxItems: 1
+description: Node reference to the type C mux
+
+  endpoint@1:
+description: Connection to role switch node
+type: object
+
+properties:
+  remote-endpoint:
+maxItems: 1
+description: Node reference to the role switch node
+
+required:
+  - compatible
+
+required:
+  - compatible
+  - interrupts
+  - connector
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+qcom,typec@1500 {
+compatible = "qcom,pm8150b-usb-typec";
+reg = <0x1500>;
+interrupts =
+<0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+
+connector {
+compatible = "usb-c-connector";
+power-role = "dual";
+data-role = "dual";
+port {
+#address-cells = <1>;
+#size-cells = <0>;
+usb3_data_ss: endpoint@0 {
+reg = <0>;
+remote-endpoint =
+<_ss_mux>;
+};
+
+usb3_role: endpoint@1 {
+
+reg = <1>;
+remote-endpoint =
+<_drd_switch>;
+};
+};
+};
+};
+};
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 5/6] dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output regulator

[Wesley Cheng]

This describes how to enable the Qualcomm PMIC VBUS booster used for
providing power to connected USB peripherals when the USB role is host
mode.  The driver itself will register the vbus_usb regulator, so that
external drivers can utilize the enable/disable regulator APIs.

Signed-off-by: Wesley Cheng 
---
 .../regulator/qcom,usb-vbus-regulator.yaml| 41 +++
 1 file changed, 41 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
new file mode 100644
index ..2fa76111cfb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,usb-vbus-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The Qualcomm PMIC VBUS output regulator driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  This regulator driver controls the VBUS output by the Qualcomm PMIC.  This
+  regulator will be enabled in situations where the device is required to
+  provide power to the connected peripheral.
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-vbus-reg
+
+  reg:
+maxItems: 1
+description: VBUS output base address
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+ pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+qcom,dcdc@1100 {
+compatible = "qcom,pm8150b-vbus-reg";
+reg = <0x1100>;
+};
+ };
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 0/6] Introduce PMIC based USB type C detection

[Wesley Cheng]

Changes in v2:
 - Use devm_kzalloc() in qcom_pmic_typec_probe()
 - Add checks to make sure return value of typec_find_port_power_role() is
   valid
 - Added a VBUS output regulator driver, which will be used by the PMIC USB
   type c driver to enable/disable the source
 - Added logic to control vbus source from the PMIC type c driver when
   UFP/DFP is detected
 - Added dt-binding for this new regulator driver
 - Fixed Kconfig typec notation to match others
 - Leave type C block disabled until enabled by a platform DTS

Add the required drivers for implementing type C orientation and role
detection using the Qualcomm PMIC.  Currently, PMICs such as the PM8150B
have an integrated type C block, which can be utilized for this.  This
series adds the dt-binding, PMIC type C driver, and DTS nodes.

The PMIC type C driver will register itself as a type C port w/ a
registered type C switch for orientation, and will fetch a USB role switch
handle for the role notifications.  It will also have the ability to enable
the VBUS output to any connected devices based on if the device is behaving
as a UFP or DFP.

Wesley Cheng (6):
  usb: typec: Add QCOM PMIC typec detection driver
  dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding
  arm64: boot: dts: qcom: pm8150b: Add node for USB type C block
  regulator: Add support for QCOM PMIC VBUS booster
  dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output
regulator
  arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster

 .../regulator/qcom,usb-vbus-regulator.yaml|  41 +++
 .../bindings/usb/qcom,pmic-typec.yaml | 117 
 arch/arm64/boot/dts/qcom/pm8150b.dtsi |  13 +
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts   |   7 +
 drivers/regulator/Kconfig |  10 +
 drivers/regulator/Makefile|   1 +
 drivers/regulator/qcom_usb_vbus-regulator.c   | 147 ++
 drivers/usb/typec/Kconfig |  12 +
 drivers/usb/typec/Makefile|   1 +
 drivers/usb/typec/qcom-pmic-typec.c   | 275 ++
 10 files changed, 624 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 3/6] arm64: boot: dts: qcom: pm8150b: Add node for USB type C block

[Wesley Cheng]

The PM8150B has a dedicated USB type C block, which can be used for type C
orientation and role detection.  Create the reference node to this type C
block for further use.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 322379d5c31f..ec44a8bc2f84 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,14 @@ power-on@800 {
status = "disabled";
};
 
+   qcom,typec@1500 {
+   compatible = "qcom,pm8150b-usb-typec";
+   status = "disabled";
+   reg = <0x1500>;
+   interrupts =
+   <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+   };
+
adc@3100 {
compatible = "qcom,spmi-adc5";
reg = <0x3100>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver

[Wesley Cheng]

On 6/10/2020 12:37 PM, Bjorn Andersson wrote:
>> along with USB_BASE @ 0x1300, is it ok to allow this driver to access
>> registers outside of its 'reg' base (0x1500 according to the DT
>> bindings)?
>>
> 
> Depending on how entangled a future driver for the charger blocks would
> be one could either just upstream a dcdc regulator driver to control
> vbus today, or a "lite version" of a charging driver exposing just the
> vbus regulator.
> 
> Either way I would prefer this over poking the register directly from
> this driver, as it will make it tricky to migrate to a proper charger
> driver later.
> 
> Regards,
> Bjorn
> 

Hi Bjorn/Jack,

I have removed the need for referencing other base addresses other than
the type C block within the  driver, and have moved the DCDC set to be
handled by another regulator driver, which solely controls the vbus
output.  The type C driver will control the vbus output using the
regulator APIs.  Thanks for the input.

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver

[Wesley Cheng]

On 6/9/2020 7:27 PM, Jun Li wrote:
>> +static int qcom_pmic_typec_probe(struct platform_device *pdev)
>> +{
>> +   struct device *dev = >dev;
>> +   struct qcom_pmic_typec *qcom_usb;
>> +   struct typec_capability *cap;
>> +   const char *buf;
>> +   int ret, irq, role;
>> +
>> +   qcom_usb = kzalloc(sizeof(*qcom_usb), GFP_KERNEL);
> 
> devm_kzalloc().
> 

Hi Jun,

Thanks for the input.  I have replaced with devm_kzalloc() as you
recommended.

>> +   if (!qcom_usb)
>> +   return -ENOMEM;
>> +
>> +   qcom_usb->dev = dev;
>> +
>> +   qcom_usb->regmap = dev_get_regmap(dev->parent, NULL);
>> +   if (!qcom_usb->regmap) {
>> +   dev_err(dev, "Failed to get regmap\n");
>> +   return -EINVAL;
>> +   }
>> +
>> +   irq = platform_get_irq(pdev, 0);
>> +   if (irq < 0) {
>> +   dev_err(dev, "Failed to get CC irq\n");
>> +   return -EINVAL;
>> +   }
>> +
>> +   ret = devm_request_irq(qcom_usb->dev, irq, qcom_pmic_typec_interrupt,
>> +  IRQF_SHARED, "qcom-pmic-typec", qcom_usb);
>> +   if (ret) {
>> +   dev_err(>dev, "Could not request IRQ\n");
>> +   return ret;
>> +   }
>> +
>> +   qcom_usb->fwnode = device_get_named_child_node(dev, "connector");
>> +   if (!qcom_usb->fwnode)
>> +   return -EINVAL;
>> +
>> +   cap = kzalloc(sizeof(*cap), GFP_KERNEL);
> 
> devm_kzalloc().
> 
>> +   if (!cap) {
>> +   ret = -ENOMEM;
>> +   goto err_put_node;
>> +   }
>> +
>> +   ret = fwnode_property_read_string(qcom_usb->fwnode, "power-role", 
>> );
>> +   if (!ret)
>> +   role = typec_find_port_power_role(buf);
> 
> if (role < 0)
> 


Added a check for role <0, if so, set to SNK as well
>> +   else
>> +   role = TYPEC_PORT_SNK;
>> +   cap->type = role;
>> +
>> +   ret = fwnode_property_read_string(qcom_usb->fwnode, "data-role", 
>> );
>> +   if (!ret)
>> +   role = typec_find_port_data_role(buf);
> 
> if (role < 0)
> 

Added a check for role <0, if so, set to UFP as well
>> +   else
>> +   role = TYPEC_PORT_UFP;
>> +   cap->data = role;
>> +
>> +   cap->prefer_role = -1;
> 
> TYPEC_NO_PREFERRED_ROLE
> 

Done.
>> +   cap->fwnode = qcom_usb->fwnode;
>> +   qcom_usb->port = typec_register_port(dev, cap);
>> +   if (IS_ERR(qcom_usb->port)) {
>> +   dev_err(dev, "Failed to register type c port %d\n",
>> +   IS_ERR(qcom_usb->port));
>> +   ret = PTR_ERR(qcom_usb->port);
> 
> dev_err(dev, , ret)?
> 
> Li Jun

Agreed.  Thanks!

>> +   goto err_put_node;
>> +   }
>> +
>> +   qcom_usb->cap = cap;
>> +
>> +   qcom_usb->role_sw = fwnode_usb_role_switch_get(qcom_usb->fwnode);
>> +   if (IS_ERR(qcom_usb->role_sw)) {
>> +   if (PTR_ERR(qcom_usb->role_sw) != -EPROBE_DEFER)
>> +   dev_err(dev, "failed to get role switch\n");
>> +   ret = PTR_ERR(qcom_usb->role_sw);
>> +   goto err_typec_port;
>> +   }
>> +
>> +   INIT_WORK(_usb->bh_work, qcom_pmic_typec_bh_work);
>> +   platform_set_drvdata(pdev, qcom_usb);
>> +   qcom_pmic_typec_typec_hw_init(qcom_usb);
>> +
>> +   queue_work(system_power_efficient_wq, _usb->bh_work);
>> +
>> +   return 0;
>> +
>> +err_typec_port:
>> +   typec_unregister_port(qcom_usb->port);
>> +err_put_node:
>> +   fwnode_handle_put(qcom_usb->fwnode);
>> +
>> +   return ret;
>> +}
>> +
>> +static int qcom_pmic_typec_remove(struct platform_device *pdev)
>> +{
>> +   struct qcom_pmic_typec *qcom_usb = platform_get_drvdata(pdev);
>> +
>> +   cancel_work_sync(_usb->bh_work);
>> +   usb_role_switch_set_role(qcom_usb->role_sw, USB_ROLE_NONE);
>> +   qcom_pmic_typec_vbus_disable(qcom_usb);
>> +
>> +   typec_unregister_port(qcom_usb->port);
>> +   usb_role_switch_put(qcom_usb->role_sw);
>> +   fwnode_handle_put(qcom_usb->fwnode);
>> +
>> +   return 0;
>> +}
>> +
>> +static const struct of_device_id qcom_pmic_typec_table[] = {
>> +   { .compatible = "qcom,pm8150b-usb-typec" },
>> +   { },
>> +};
>> +MODULE_DEVICE_TABLE(of, qcom_pmic_typec_table);
>> +
>> +static struct platform_driver qcom_pmic_typec = {
>> +   .driver = {
>> +   .name = "qcom,pmic-typec",
>> +   .of_match_table = qcom_pmic_typec_table,
>> +   },
>> +   .probe = qcom_pmic_typec_probe,
>> +   .remove = qcom_pmic_typec_remove,
>> +};
>> +
>> +module_platform_driver(qcom_pmic_typec);
>> +
>> +MODULE_DESCRIPTION("QCOM PMIC USB type C driver");
>> +MODULE_LICENSE("GPL v2");
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation 

Re: [PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver

[Wesley Cheng]

On 6/9/2020 2:20 PM, Randy Dunlap wrote:
> On 6/9/20 1:58 PM, Wesley Cheng wrote:
>> diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
>> index 559dd06..8de2520 100644
>> --- a/drivers/usb/typec/Kconfig
>> +++ b/drivers/usb/typec/Kconfig
>> @@ -73,6 +73,17 @@ config TYPEC_TPS6598X
>>If you choose to build this driver as a dynamically linked module, the
>>module will be called tps6598x.ko.
>>
> 
> Hi,
> Please spell "Type-C" like all of the other drivers do.
> 
>> +config TYPEC_QCOM_PMIC
>> +tristate "Qualcomm PMIC USB typec driver"
>> +depends on ARCH_QCOM
>> +help
>> +  Driver for supporting role switch over the Qualcomm PMIC.  This will
>> +  handle the type C role and orientation detection reported by the QCOM
>> +  PMIC if the PMIC has the capability to handle type C detection.
>> +
>> +  It will also enable the VBUS output to connected devices when a
>> +  DFP connection is made.
>> +
>>  source "drivers/usb/typec/mux/Kconfig"
>>  
>>  source "drivers/usb/typec/altmodes/Kconfig"

Hi Randy,

Will do.

Thanks
> 
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[cobirds] Unfortunate birding at Bud Mielke Reservoir. Loveland, larimer county

[Jace Wesley Brasher]

The farmers are mowing the fields north and south of  Bud Mielke Reservoir in
loveland( location of eastern meadowlark, Dickcissel, and bobolink nests).
Unfortunately this means any possible nests are being destroyed.

Jace brasher
Loveland
Larimer county

-- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/CAP7yTyiMnO7wL9S8CPN2ama8fPGc0ejzchrQUA1uhN3VcYYa2A%40mail.gmail.com.

[Mpi-forum] Procedures Reading and Vote Announcements for June 2020 Meeting

[Wesley Bland via mpi-forum]

Hi all,

I’d like to announce formal readings and votes for the procedures changes that 
I read earlier today. For both of these proposals, I’ve made changes based on 
the feedback from the group so they are hopefully both acceptable to everyone. 
Please have a look and make any comments on the PR before Monday if there’s 
anything that’s still unclear.

Proceedings PR #6  - Update to 
RCM/FRM rules for GitHub
Proceedings PR #7  - Add 
procedures for officer elections

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver

[Wesley Cheng]

The QCOM SPMI typec driver handles the role and orientation detection, and
notifies client drivers using the USB role switch framework.   It registers
as a typec port, so orientation can be communicated using the typec switch
APIs.  The driver also registers the VBUS output regulator, so client
drivers can enable the VBUS source when acting as a source/host.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/typec/Kconfig   |  11 ++
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/qcom-pmic-typec.c | 278 
 3 files changed, 290 insertions(+)
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 559dd06..8de2520 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -73,6 +73,17 @@ config TYPEC_TPS6598X
  If you choose to build this driver as a dynamically linked module, the
  module will be called tps6598x.ko.
 
+config TYPEC_QCOM_PMIC
+   tristate "Qualcomm PMIC USB typec driver"
+   depends on ARCH_QCOM
+   help
+ Driver for supporting role switch over the Qualcomm PMIC.  This will
+ handle the type C role and orientation detection reported by the QCOM
+ PMIC if the PMIC has the capability to handle type C detection.
+
+ It will also enable the VBUS output to connected devices when a
+ DFP connection is made.
+
 source "drivers/usb/typec/mux/Kconfig"
 
 source "drivers/usb/typec/altmodes/Kconfig"
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index 7753a5c3..cceffd9 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_TYPEC_TCPM)+= tcpm/
 obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
 obj-$(CONFIG_TYPEC_HD3SS3220)  += hd3ss3220.o
 obj-$(CONFIG_TYPEC_TPS6598X)   += tps6598x.o
+obj-$(CONFIG_TYPEC_QCOM_PMIC)  += qcom-pmic-typec.o
 obj-$(CONFIG_TYPEC)+= mux/
diff --git a/drivers/usb/typec/qcom-pmic-typec.c 
b/drivers/usb/typec/qcom-pmic-typec.c
new file mode 100644
index 000..ce6319c
--- /dev/null
+++ b/drivers/usb/typec/qcom-pmic-typec.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DCDC_BASE  0x1100
+#define CMD_OTG(DCDC_BASE + 0x40)
+#define OTG_EN BIT(0)
+#define OTG_CFG(DCDC_BASE + 0x53)
+#define OTG_EN_SRC_CFG BIT(1)
+
+#define USB_BASE   0x1300
+#define TYPE_C_CFG_REG (USB_BASE + 0x58)
+#define BC12_START_ON_CC   BIT(7)
+
+#define TYPEC_BASE 0x1500
+#define TYPEC_MISC_STATUS  (TYPEC_BASE + 0xb)
+#define CC_ATTACHEDBIT(0)
+#define CC_ORIENTATION BIT(1)
+#define SNK_SRC_MODE   BIT(6)
+#define TYPEC_MODE_CFG (TYPEC_BASE + 0x44)
+#define TYPEC_DISABLE_CMD  BIT(0)
+#define EN_SNK_ONLYBIT(1)
+#define EN_SRC_ONLYBIT(2)
+#define EN_TRY_SNK BIT(4)
+#define TYPEC_VCONN_CONTROL(TYPEC_BASE + 0x46)
+#define VCONN_EN_SRC   BIT(0)
+#define VCONN_EN_VAL   BIT(1)
+#define TYPEC_EXIT_STATE_CFG   (TYPEC_BASE + 0x50)
+#define SEL_SRC_UPPER_REF  BIT(2)
+#define TYPEC_INTR_EN_CFG_1(TYPEC_BASE + 0x5e)
+#define TYPEC_INTR_EN_CFG_1_MASK   GENMASK(0, 7)
+
+struct qcom_pmic_typec {
+   struct device   *dev;
+   struct fwnode_handle*fwnode;
+   struct regmap   *regmap;
+   struct work_struct  bh_work;
+
+   struct typec_capability *cap;
+   struct typec_port   *port;
+   struct usb_role_switch *role_sw;
+
+   struct regulator_desc usb_vbus_rdesc;
+   struct regulator_dev *usb_vbus_reg;
+};
+
+static int qcom_pmic_typec_vbus_enable(struct qcom_pmic_typec *qcom_usb)
+{
+   int rc;
+
+   rc = regmap_update_bits(qcom_usb->regmap, CMD_OTG, OTG_EN, OTG_EN);
+   if (rc)
+   dev_err(qcom_usb->dev, "failed to update OTG_CTL\n");
+
+   return rc;
+}
+
+static int qcom_pmic_typec_vbus_disable(struct qcom_pmic_typec *qcom_usb)
+{
+   int rc;
+
+   rc = regmap_update_bits(qcom_usb->regmap, CMD_OTG, OTG_EN, 0);
+   if (rc)
+   dev_err(qcom_usb->dev, "failed to update OTG_CTL\n");
+
+   return rc;
+}
+
+void qcom_pmic_typec_bh_work(struct work_struct *w)
+{
+   struct qcom_pmic_typec *qcom_usb = container_of(w,
+   

[PATCH 3/3] arm64: boot: dts: qcom: pm8150b: Add node for USB type C block

[Wesley Cheng]

The PM8150B has a dedicated USB type C block, which can be used for type C
orientation and role detection.  Create the reference node to this type C
block for further use.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 40b5d75..7364d6b 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,13 @@
status = "disabled";
};
 
+   qcom,typec@1500 {
+   compatible = "qcom,pm8150b-usb-typec";
+   reg = <0x1500>;
+   interrupts =
+   <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+   };
+
adc@3100 {
compatible = "qcom,spmi-adc5";
reg = <0x3100>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 0/3] Introduce PMIC based USB type C detection

[Wesley Cheng]

Add the required drivers for implementing type C orientation and role
detection using the Qualcomm PMIC.  Currently, PMICs such as the PM8150B
have an integrated type C block, which can be utilized for this.  This
series adds the dt-binding, PMIC type C driver, and DTS nodes.

The PMIC type C driver will register itself as a type C port w/ a
registered type C switch for orientation, and will fetch a USB role switch
handle for the role notifications.  It will also have the ability to enable
the VBUS output to any connected devices based on if the device is behaving
as a UFP or DFP.

Wesley Cheng (3):
  usb: typec: Add QCOM PMIC typec detection driver
  dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding
  arm64: boot: dts: qcom: pm8150b: Add node for USB type C block

 .../devicetree/bindings/usb/qcom,pmic-typec.yaml   | 118 +
 arch/arm64/boot/dts/qcom/pm8150b.dtsi  |   7 +
 drivers/usb/typec/Kconfig  |  11 +
 drivers/usb/typec/Makefile |   1 +
 drivers/usb/typec/qcom-pmic-typec.c| 278 +
 5 files changed, 415 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/3] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding

[Wesley Cheng]

Introduce the dt-binding for enabling USB type C orientation and role
detection using the PM8150B.  The driver will be responsible for receiving
the interrupt at a state change on the CC lines, reading the orientation/role,
and communicating this information to the remote clients, which can include
a role switch node and a type C switch.

Signed-off-by: Wesley Cheng 
---
 .../devicetree/bindings/usb/qcom,pmic-typec.yaml   | 118 +
 1 file changed, 118 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml

diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml 
b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
new file mode 100644
index 000..34058fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/qcom,pmic-typec.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Qualcomm PMIC based USB type C Detection Driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  Qualcomm PMIC Type C Detect
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-usb-typec
+
+  reg:
+maxItems: 1
+description: Type C base address
+
+  interrupts:
+maxItems: 1
+description: CC change interrupt from PMIC
+
+  connector:
+description: Connector type for remote endpoints
+type: object
+
+properties:
+  compatible:
+enum:
+  - usb-c-connector
+
+  power-role:
+   enum:
+ - dual
+ - source
+ - sink
+
+  data-role:
+enum:
+  - dual
+  - host
+  - device
+
+  port:
+description: Remote endpoint connections
+type: object
+
+properties:
+  endpoint@0:
+description: Connection to USB type C mux node
+type: object
+
+properties:
+  remote-endpoint:
+maxItems: 1
+description: Node reference to the type C mux
+
+  endpoint@1:
+description: Connection to role switch node
+type: object
+
+properties:
+  remote-endpoint:
+maxItems: 1
+description: Node reference to the role switch node
+
+required:
+  - compatible
+
+required:
+  - compatible
+  - interrupts
+  - connector
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+qcom,typec@1500 {
+compatible = "qcom,pm8150b-usb-typec";
+reg = <0x1500>;
+interrupts =
+<0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+
+connector {
+compatible = "usb-c-connector";
+power-role = "dual";
+data-role = "dual";
+port {
+#address-cells = <1>;
+#size-cells = <0>;
+usb3_data_ss: endpoint@0 {
+reg = <0>;
+remote-endpoint =
+<_ss_mux>;
+};
+
+usb3_role: endpoint@1 {
+
+reg = <1>;
+remote-endpoint =
+<_drd_switch>;
+};
+};
+};
+};
+};
+...
+
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: Alternative SMTP server

[Wesley]

try pobox.com, whose smtp relay is reliable and cheap (20 USD/y).

regards.

Forums wrote:
So, my idea is to use automatically (managed by Postfix) an alternative 
SMTP server (Gmail SMTP with my Google account) when an email is 
rejected. But I don't know if it's possible and how to configure that.

[Mpi-forum] Additional MPI Forum Procedures Discussions

[Wesley Bland via mpi-forum]

Hi all,

Now that we’ve made the urgent changes to be able to hold exceptional virtual 
meetings, I’d like to discuss two additional sets of changes.

First, during the discussion of the virtual meetings, we realized and I 
mentioned that there were some minor changes necessary to the RCM/FRM 
procedures for completing an MPI Standard Document. Those changes are available 
here: Update to RCM/FRM rules for GitHub 


Second, Martin and I have been discussing the need for a more formal elections 
system for a while to get ready for the next round of MPI Standard Documents so 
there would be a more clear process for replacing officers or confirming them 
in their existing roles (to avoid the more on-the-fly discussion that we had 
after MPI 3.1). I’m proposing some text to formalize that here: 
https://github.com/mpi-forum/procedures/pull/7 


A very short version of what’s in the proposal is:
Add a definition for MPI Forum Treasurer (to replace the current role of 
Meeting Convener, which has largely morphed into treasurer over the past few 
years anyway).
Officers serve through one “major release cycle” (from MPI 4.0 -> MPI 5.0) to 
provide longer term continuity by default.
Nominations open at the Release Candidate Meeting and elections occur at the 
Final Ratification Meeting for the major versions. Elections are a simple 
majority (not plurality) to avoid deadlock.
Officers may vacate their positions if needed and will be replaced at the next 
voting meeting.
These rules would apply to the four “officer” positions that the MPI Forum 
currently recognizes:
Chair
Secretary
Treasurer
Document Editor
All of the details are available in the relatively short pull request so please 
go over that when you have a chance.

I’ll present both of these pull requests briefly on Wednesday during the 
virtual meeting before we start the main topic from Rolf on Virtual Topologies.

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: The historical roots of our computer terms

[wesley]

m...@junc.eu, please see the screenshot above, you have also sent message 
repeatly.

maybe the bug of postfix-users mailing list?

regards

m...@junc.eu wrote:
> On 2020-06-08 07:52, cl...@mobile.oche.de wrote:
>
> you repeatly send the same mail :/
>


ATT1.HTML
Description: Binary data

Re: The historical roots of our computer terms

[wesley]

This message contains attachment 2 of 2.
See message 83 for further information.

JCMCPJGGFKPIGHOM.PNG
Description: Binary data

Re: The historical roots of our computer terms

[Wesley]

m...@junc.eu, please see the screenshot above, you have also sent message 
repeatly.


maybe the bug of postfix-users mailing list?

regards

m...@junc.eu wrote:

On 2020-06-08 07:52, cl...@mobile.oche.de wrote:

you repeatly send the same mail :/

Re: unsubscribe

[Wesley]

please send an empty email to: user-unsubscr...@spark.apache.org for 
unsubscribing.


thanks.



unsubscribe


-
To unsubscribe e-mail: user-unsubscr...@spark.apache.org

[Mpi-forum] Editor Pass Reading and Vote Announcements

[Wesley Bland via mpi-forum]

Hi all,

Here’s the list of issues that have all been informally read as part of the 
general cleanup work we’ve been doing in virtual meetings for the last couple 
of months. Unless someone specifically steps up to contradict me, this will 
serve as an announcement for each of these items for an official reading during 
the June meeting and the person who will do the reading.

Errata Reading and Vote

Joseph - Omission: p. 440 - WIN_DETATCH Binding Fix · Issue #179 · 
mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/229 

PR: https://github.com/mpi-forum/mpi-standard/pull/230 

Joseph - Omission: p. 439 - WIN_ATTACH_ Binding Fix · Issue #178 · 
mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/229 

Dan - Error: Section 3.3.2 - p. 38 - Replace C process · Issue #167 · 
mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/201 

Dan - Clarification: Section 3.2.2 - p. 27 - Datatype Footnote · Issue #252 · 
mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/224 

Dan - Update: Section 3.7.5 - p. 60 - Replace C-bias with LIS · Issue #190 · 
mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/225 

Wes - Update: Section 17.1 - p. 635 - Update Backward Incompatibility Text · 
Issue #218 · mpi-forum/mpi-issues · GitHub 

PR https://github.com/mpi-forum/mpi-standard/pull/183 

Wes - Clarification: Section 11.3.5 - p. 458 - Error in Status Field 
Clarification · Issue #262 · mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/210 

Wes - Clarification: Section 11.7 - p. 482 - MPI Exception Clarification · 
Issue #263 · mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/177 

Wes - Error: Section 12.4.3 - p. 515 - MPI_INIT argc/argv values · Issue #168 · 
mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/182 

George - Error in text: Section 4.1.1 - p. 87 - INTEGER*8 Extension · Issue 
#171 · mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/196 

George - Omission: p. 387 - Initialized Binding Fix · Issue #176 · 
mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/195 

George - Oversight: Section 8.7 - p. 383 - Escape Spaces in Arguments · Issue 
#181 · mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/172 

George - Clarification: Example 4.17 - p. 128 - Example Comment · Issue #254 · 
mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/181 

Guillaume - Update: Section 6.2.4 - p. 248 - Remove Host Process · Issue #196 · 
mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/176 

Marc-Andre - Clarification: Section 14.3.7 - p. 615 - MPI_T Session Impact 
Clarifications · Issue #268 · mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/168 

Martin - Error: Section 13.4.1 - p. 535 - MPI_FILE_READ Equivalency · Issue 
#169 · mpi-forum/mpi-issues · GitHub 

PR: https://github.com/mpi-forum/mpi-standard/pull/216 

Julien - Clarification: Section 5.1 - p. 144 - Collective Synchronization · 
Issue 

Re: [go-nuts] SSL socket listener

['Wesley Peng' via golang-nuts]

Thanks. how about the sample of general socket listener with SSL rather 
than net/http implementation?


Regards

Dimas Prawira wrote:

Here is an example running server with TLS

package  main

import  (
 "net/http"
 "log"
)

func  HelloServer(w  http.ResponseWriter,req  *http.Request) {
 w.Header().Set("Content-Type","text/plain")
 w.Write([]byte("This is an example server.\n"))
}

func  main() {
 http.HandleFunc("/hello",HelloServer)
 err  :=  http.ListenAndServeTLS(":443","server.crt","server.key",nil)
 if  err  !=  nil  {
 log.Fatal("ListenAndServe: ",err)
 }
}



--
Wesley Peng
wesleyp...@aol.com

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ffdb0882-3e1a-173d-6c3c-91f63d88bbfe%40aol.com.

Re: [VOTE] Apache CloudStack 4.14.0.0 RC3

[Wesley Peng]

Andrija Panic wrote:

http://docs.cloudstack.apache.org/en/latest/upgrading/upgrade/upgrade-4.13.html#time-zone-requirements


handled in the Upgrade docs - exactly the same..



[OT] is there a cloudstack private IAAS deployment solution? not that 
large scale, most for storage. if there is the commercial solution, we 
can pay for it.


Thanks.

[go-nuts] SSL socket listener

['Wesley Peng' via golang-nuts]

Hello,
How do I program with SSL to make a server listen on specific port which 
accepts SSL transfer only?
Is there any guide for this since I have no experience on SSL socket 
programming.
Thanks.

Wesley Peng
wesleyp...@aol.com

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1690752345.1320667.1591168756241%40mail.yahoo.com.

Re: [grpc-io] gRPC hostname

[Wesley Peng]

XCompiler wrote:
     server.Listen(IPAddress.Loopback, 5001, 
listenOptions =>


You have server listened on lookback interface, please change it to a 
regular IP address.


regards.

--
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/dd0615c0-f27f-1675-6825-1fe40cfb8076%40gmail.com.

Re: connection refused

[Wesley Peng]

Does either client or server have any logs?

Thanks

On Tue, Jun 2, 2020 at 6:37 PM Clay Teahouse  wrote:

> I'd appreciate your help with this issue.
> I have a server and a client node, the latter running in tomcat. I get
> connection refused if I try to connect to the server node from the client,
> although the server shows the client has joined the cluster. I don't have a
> problem running a service on the server's service grid from the client node.
> I don't have any issue connecting from any client anywhere, if the client
> is not running in tomcat.
> what could be the problem?
>
>

[Mpi-forum] June MPI Forum Votes and Reading Announcements

[Wesley Bland via mpi-forum]

Hi all,

I’d like to announce a bunch of readings a votes for the upcoming meeting. The 
issue and pull request links can be found for each below.

Thanks,
Wes

Readings

#263  - Clarification: 
Section 11.7 - p. 482 - MPI Exception Clarification (Pull Request 
)
#168  - Error: Section 
12.4.3 - p. 515 - MPI_INIT argc/argv values (Pull Request 
)
#218  - Update: Section 
17.1 - p. 635 - Update Backward Incompatibility Text (Pull Request 
)
#262  - Clarification: 
Section 11.3.5 - p. 458 - Error in Status Field Clarification (Pull Request 
)

#259  - Clarification: 
Section 8.5 - p. 377 - Error Class and Code Advice to Implementors (Pull 
Request )
#283  - Add 
MPI_Remove_error_class, MPI_Remove_error_code, MPI_Remove_error_string (Pull 
Request )

Errata Votes

#263  - Clarification: 
Section 11.7 - p. 482 - MPI Exception Clarification (Pull Request 
)
#168  - Error: Section 
12.4.3 - p. 515 - MPI_INIT argc/argv values (Pull Request 
)
#218  - Update: Section 
17.1 - p. 635 - Update Backward Incompatibility Text (Pull Request 
)
#262  - Clarification: 
Section 11.3.5 - p. 458 - Error in Status Field Clarification (Pull Request 
)

2nd Votes

#143  - Create MPI_INFO_ENV 
before MPI_INIT (Pull Request 
)___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [casper] Red Pitaya access registers of snap blocks from PS

[Wesley New]

Hi Sean.

progska is a c utility that we use to speed up the programming of the
skarab boards and is not needed for the RP.


On Mon, 01 Jun 2020, 7:23 PM Sean Mckee,  wrote:

> Hi Jack,
>
> I did try installing casperfpga on the red pitaya, but it appears that one
> of the libraries (progska, if I recall correctly) requires 64-bit. It was
> giving me ELFCLASS64 error. Not sure if there's a work around, but I'm
> pretty comfortable writing C code to run on the red pitaya to manage the
> registers, so that's the direction I've gone.
>
> Thanks!
> Sean
>
> On Monday, June 1, 2020 at 3:59:13 AM UTC-6, Jack Hickish wrote:
>>
>> Hi Sean,
>>
>> Just to explicitly add to wes's advice - in addition to the telnet
>> interface on localhost, you can "just" install full blown casperfpga to
>> your red pitaya, and connect via localhost using the scripts you already
>> have. Unless your performance requirements are such that python is out of
>> the question, this is probably the easiest thing to do.
>>
>> Cheers
>> Jack
>>
>>
>> On Sun, 31 May 2020, 10:45 pm Sean Mckee,  wrote:
>>
>>> Hi Wesley,
>>>
>>> Thank you, that's what I was looking for!
>>>
>>> On Sunday, May 31, 2020 at 12:54:31 PM UTC-6, wesley wrote:
>>>>
>>>> Hi Sean,
>>>>
>>>> These are all good questions and Ill try to point you in the right
>>>> direction.
>>>>
>>>> So if you followed this tutorial to setup your red pitaya:
>>>> https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html#running-the-script-on-a-preloaded-rp-sd-card
>>>> You should have tcpborphserver installed on the PS. You can telnet into
>>>> tcpborphserver and issue register read and writes that way. ie you could
>>>> telnet into tcpborphserver on localhost form the RP using a python script
>>>> and run your tasks that way. If I remember correctly tcpboprhserver can
>>>> address a register by name so you shouldnt need to worry about memory maps,
>>>> but if you are you can look at the fpg file that you uploaded and the
>>>> header will contain the memory map. You can also see the memory map in a
>>>> file called coreinfo.tab in your build directory.
>>>>
>>>> Hope this helps.
>>>>
>>>> Wesley New
>>>> South African SKA Project
>>>> +2721 506 7300
>>>> www.ska.ac.za
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, May 31, 2020 at 7:56 PM Sean Mckee 
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm trying to determine how I would go about finding/using the
>>>>> addresses of the memory mapped registers being used by the FPGA, from the
>>>>> PS side of the Red Pitaya. For example, in the spectrometer tutorial, 
>>>>> there
>>>>> are several registers used to control the design, and others to pull data
>>>>> out from the design. If I access the Red Pitaya from my computer using the
>>>>> casperfpga.py module, these registers are all conveniently named and the
>>>>> python module has tools to read data from snap blocks, write to the reset
>>>>> and trigger registers, etc.
>>>>>
>>>>> Is there a convenient way to have this same level of control on the
>>>>> red pitaya itself? I would like to write code that runs on the PS to
>>>>> monitor these registers and handle the data output. From what I can
>>>>> currently find, I will need to open the /dev/mem file and use the mmap()
>>>>> command. But how do I find out which physical register corresponds to 
>>>>> which
>>>>> simulink block? And I assume that even a minor update to the simulink
>>>>> design could result in the registers being moved around, so what is a good
>>>>> way to account for this?
>>>>>
>>>>> Currently, I am trying to trace what happens when I call casperfpga
>>>>> commands from my computer. I understand the parsing of the commands and 
>>>>> the
>>>>> hand off to tcpborphserver, but I can't seem to unravel what is happening
>>>>> when the red pitaya receives these commands. I'm assuming this code is
>>>>> somewhere in the katcp library (https://github.com/ska-sa/katcp)?
>>>>>
>>>>> Hopefully someone kn

Re: Zookeeper discovery in mix environments.

[Wesley Peng]

Maybe you would ask the question on VM/container related mailing list?

Regards

On Mon, Jun 1, 2020 at 9:32 PM John Smith  wrote:

> Any news on this? Thanks
>
>
> On Thu., May 28, 2020, 1:10 p.m. John Smith, 
> wrote:
>
>> Hi, I'm running an ignite cluster on VMs running on Openstack and using
>> regular network stack nothing special here.
>>
>> My CLIENT (client=true) applications are running in DC/OS using docker
>> container in bridged network mode.
>>
>> When using TCP discovery everything works nice and dandy. But I recently
>> tried to switch to Zookeeper discovery but the docker application can't
>> seem to connect or get discovered?
>>
>> I'm assuming when running in bridge mode I need to open a port on the
>> bridge to allow other node to connect back. Is there a way to the ignite
>> client/zookeeper SPI that the CLIENT node is available at a specific
>> ip/port?
>>
>

Re: [casper] Red Pitaya access registers of snap blocks from PS

[Wesley New]

Hi Sean,

These are all good questions and Ill try to point you in the right
direction.

So if you followed this tutorial to setup your red pitaya:
https://casper-toolflow.readthedocs.io/projects/tutorials/en/latest/tutorials/redpitaya/red_pitaya_setup.html#running-the-script-on-a-preloaded-rp-sd-card
You should have tcpborphserver installed on the PS. You can telnet into
tcpborphserver and issue register read and writes that way. ie you could
telnet into tcpborphserver on localhost form the RP using a python script
and run your tasks that way. If I remember correctly tcpboprhserver can
address a register by name so you shouldnt need to worry about memory maps,
but if you are you can look at the fpg file that you uploaded and the
header will contain the memory map. You can also see the memory map in a
file called coreinfo.tab in your build directory.

Hope this helps.

Wesley New
South African SKA Project
+2721 506 7300
www.ska.ac.za




On Sun, May 31, 2020 at 7:56 PM Sean Mckee  wrote:

> Hi all,
>
> I'm trying to determine how I would go about finding/using the addresses
> of the memory mapped registers being used by the FPGA, from the PS side of
> the Red Pitaya. For example, in the spectrometer tutorial, there are
> several registers used to control the design, and others to pull data out
> from the design. If I access the Red Pitaya from my computer using the
> casperfpga.py module, these registers are all conveniently named and the
> python module has tools to read data from snap blocks, write to the reset
> and trigger registers, etc.
>
> Is there a convenient way to have this same level of control on the red
> pitaya itself? I would like to write code that runs on the PS to monitor
> these registers and handle the data output. From what I can currently find,
> I will need to open the /dev/mem file and use the mmap() command. But how
> do I find out which physical register corresponds to which simulink block?
> And I assume that even a minor update to the simulink design could result
> in the registers being moved around, so what is a good way to account for
> this?
>
> Currently, I am trying to trace what happens when I call casperfpga
> commands from my computer. I understand the parsing of the commands and the
> hand off to tcpborphserver, but I can't seem to unravel what is happening
> when the red pitaya receives these commands. I'm assuming this code is
> somewhere in the katcp library (https://github.com/ska-sa/katcp)?
>
> Hopefully someone knows of a good resource to fill in my knowledge gaps.
>
> Thanks!
> Sean
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7fcb1398-42a3-45a0-8da5-1801f2274d71%40lists.berkeley.edu
> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7fcb1398-42a3-45a0-8da5-1801f2274d71%40lists.berkeley.edu?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAE2vkmVR1ky10b0D2TER-rgD3K-PRnA3mmzgPDi%3D3ASjai%3D_-A%40mail.gmail.com.

Stus-List Two things:

[Patrick Wesley via CnC-List]

I've just sold my 1983 24 Mk II, thanks for several responses re the sale 
process. So this will be my last or close-to-last posting. By the way, I did 
mention this list to the purchaser, having often found it to be of use or 
amusement over the years.


The other thing is, many years ago, in the flush of new ownership I bought 
something that was no doubt a good purchase, but for a boat with a crew of 
about 6 people. It is called a Morlift. The idea is that if you have a MOB 
(should that be Person Overboard these days) one recovery method is to lower 
the jib into the water, move the MOB into the sling thereby created and hoist 
them out on the halyard winch. The trouble apparently is the difficulty of 
stopping them sliding back into the water when the water runs out of the sail.


Enter the Morlift which has a mesh that lets the water run out out. Well made, 
as I recall in Nova Scotia. However when my buddy and I tried it at the dock we 
quickly figured out that you would have to have the aforementioned crew of 
maybe six people.


My purchaser did not want it and the Victoria Maritime Museum used equipment 
store which supplies funds to it is closed because of COVID. Is there anyone in 
legal range of Victoria, BC who could use it and could be relied upon to pick 
it up for free at the time and day agreed??


Regards, Patrick Wesley



___

Thanks everyone for supporting this list with your contributions.  Each and 
every one is greatly appreciated.  If you want to support the list - use PayPal 
to send contribution --   https://www.paypal.me/stumurray

[tip: irq/core] irqchip/sifive-plic: Remove incorrect requirement about number of irq contexts

[tip-bot2 for Wesley W. Terpstra]

The following commit has been merged into the irq/core branch of tip:

Commit-ID: 82f2202ddc97490994fad0dbfec04a014fa5163d
Gitweb:
https://git.kernel.org/tip/82f2202ddc97490994fad0dbfec04a014fa5163d
Author:Wesley W. Terpstra 
AuthorDate:Tue, 12 May 2020 10:26:36 -07:00
Committer: Marc Zyngier 
CommitterDate: Mon, 18 May 2020 10:28:30 +01:00

irqchip/sifive-plic: Remove incorrect requirement about number of irq contexts

A PLIC may not be connected to all the cores. In that case, nr_contexts
may be less than num_possible_cpus. This requirement is only valid a single
PLIC is the only interrupt controller for the whole system.

Signed-off-by: Atish Patra 
Signed-off-by: "Wesley W. Terpstra" 
Signed-off-by: Marc Zyngier 
Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 
Link: https://lore.kernel.org/r/20200512172636.96299-1-atish.pa...@wdc.com

[Atish: Modified the commit text]
---
 drivers/irqchip/irq-sifive-plic.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/irqchip/irq-sifive-plic.c 
b/drivers/irqchip/irq-sifive-plic.c
index d0a71fe..822e074 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -301,8 +301,6 @@ static int __init plic_init(struct device_node *node,
nr_contexts = of_irq_count(node);
if (WARN_ON(!nr_contexts))
goto out_iounmap;
-   if (WARN_ON(nr_contexts < num_possible_cpus()))
-   goto out_iounmap;
 
error = -ENOMEM;
priv->irqdomain = irq_domain_add_linear(node, nr_irqs + 1,

Re: [RFC v3 1/3] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Wesley Cheng]

On 5/29/2020 9:28 AM, Jack Pham wrote:
> Hi Wesley,
> 
> On Wed, May 27, 2020 at 06:46:01PM -0700, Wesley Cheng wrote:
>> Some devices have USB compositions which may require multiple endpoints
>> that support EP bursting.  HW defined TX FIFO sizes may not always be
>> sufficient for these compositions.  By utilizing flexible TX FIFO
>> allocation, this allows for endpoints to request the required FIFO depth to
>> achieve higher bandwidth.  With some higher bMaxBurst configurations, using
>> a larger TX FIFO size results in better TX throughput.
>>
>> Ensure that one TX FIFO is reserved for every IN endpoint.  This allows for
>> the FIFO logic to prevent running out of FIFO space.
>>
>> Signed-off-by: Wesley Cheng 
>> ---
> 
> 
> 
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 00746c2..9b09528 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -540,6 +540,117 @@ static int dwc3_gadget_start_config(struct dwc3_ep 
>> *dep)
>>  return 0;
>>  }
>>  
>> +/*
>> + * dwc3_gadget_resize_tx_fifos - reallocate fifo spaces for current use-case
>> + * @dwc: pointer to our context structure
>> + *
>> + * This function will a best effort FIFO allocation in order
>> + * to improve FIFO usage and throughput, while still allowing
>> + * us to enable as many endpoints as possible.
>> + *
>> + * Keep in mind that this operation will be highly dependent
>> + * on the configured size for RAM1 - which contains TxFifo -,
>> + * the amount of endpoints enabled on coreConsultant tool, and
>> + * the width of the Master Bus.
>> + *
>> + * In general, FIFO depths are represented with the following equation:
>> + *
>> + * fifo_size = mult * ((max_packet + mdwidth)/mdwidth + 1) + 1
>> + *
>> + * Conversions can be done to the equation to derive the number of packets 
>> that
>> + * will fit to a particular FIFO size value.
>> + */
>> +static int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc, struct dwc3_ep 
>> *dep)
> 
> The 'dep' param should be sufficient; we can just get 'dwc' from
> dep->dwc. That will make it more clear this function operates on each
> endpoint that needs resizing.
> 

Hi Jack,

Thanks for the inputs.  Sure, I agree with that.  Will make the changes
to pass in only the dep.

>> +{
>> +int ram1_depth, mdwidth, fifo_0_start, tmp, num_in_ep;
>> +int min_depth, remaining, fifo_size, mult = 1, fifo, max_packet = 1024;
>> +
>> +if (!dwc->needs_fifo_resize)
>> +return 0;
>> +
>> +/* resize IN endpoints except ep0 */
>> +if (!usb_endpoint_dir_in(dep->endpoint.desc) || dep->number <= 1)
>> +return 0;
>> +
>> +/* Don't resize already resized IN endpoint */
>> +if (dep->fifo_depth)
>> +return 0;
>> +
>> +ram1_depth = DWC3_RAM1_DEPTH(dwc->hwparams.hwparams7);
>> +mdwidth = DWC3_MDWIDTH(dwc->hwparams.hwparams0);
>> +/* MDWIDTH is represented in bits, we need it in bytes */
>> +mdwidth >>= 3;
>> +
>> +if (((dep->endpoint.maxburst > 1) &&
>> +usb_endpoint_xfer_bulk(dep->endpoint.desc))
>> +|| usb_endpoint_xfer_isoc(dep->endpoint.desc))
>> +mult = 3;
>> +
>> +if ((dep->endpoint.maxburst > 6) &&
>> +usb_endpoint_xfer_bulk(dep->endpoint.desc)
>> +&& dwc3_is_usb31(dwc))
>> +mult = 6;
>> +
>> +/* FIFO size for a single buffer */
>> +fifo = (max_packet + mdwidth)/mdwidth;
>> +fifo++;
>> +
>> +/* Calculate the number of remaining EPs w/o any FIFO */
>> +num_in_ep = dwc->num_eps/2;
>> +num_in_ep -= dwc->num_ep_resized;
>> +/* Ignore EP0 IN */
>> +num_in_ep--;
>> +
>> +/* Reserve at least one FIFO for the number of IN EPs */
>> +min_depth = num_in_ep * (fifo+1);
>> +remaining = ram1_depth - min_depth - dwc->last_fifo_depth;
>> +
>> +/* We've already reserved 1 FIFO per EP, so check what we can fit in
>> + * addition to it.  If there is not enough remaining space, allocate
>> + * all the remaining space to the EP.
>> + */
>> +fifo_size = (mult-1) * fifo;
>> +if (remaining < fifo_size) {
>> +if (remaining > 0)
>> +fifo_size = remaining;
>> +else
>> +fi

Re: [RFC v3 0/3] Re-introduce TX FIFO resize for larger EP bursting

[Wesley Cheng]

On 5/29/2020 3:12 AM, Greg KH wrote:
> On Wed, May 27, 2020 at 06:46:00PM -0700, Wesley Cheng wrote:
>> Changes in V3:
>>  - Removed "Reviewed-by" tags
>>  - Renamed series back to RFC
>>  - Modified logic to ensure that fifo_size is reset if we pass the minimum
>>threshold.  Tested with binding multiple FDs requesting 6 FIFOs.
>>
>> Changes in V2:
>>  - Modified TXFIFO resizing logic to ensure that each EP is reserved a
>>FIFO.
>>  - Removed dev_dbg() prints and fixed typos from patches
>>  - Added some more description on the dt-bindings commit message
>>
>> Currently, there is no functionality to allow for resizing the TXFIFOs, and
>> relying on the HW default setting for the TXFIFO depth.  In most cases, the
>> HW default is probably sufficient, but for USB compositions that contain
>> multiple functions that require EP bursting, the default settings
>> might not be enough.  Also to note, the current SW will assign an EP to a
>> function driver w/o checking to see if the TXFIFO size for that particular
>> EP is large enough. (this is a problem if there are multiple HW defined
>> values for the TXFIFO size)
>>
>> It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3
>> is required for an EP that supports bursting.  Otherwise, there may be
>> frequent occurences of bursts ending.  For high bandwidth functions,
>> such as data tethering (protocols that support data aggregation), mass
>> storage, and media transfer protocol (over FFS), the bMaxBurst value can be
>> large, and a bigger TXFIFO depth may prove to be beneficial in terms of USB
>> throughput. (which can be associated to system access latency, etc...)  It
>> allows for a more consistent burst of traffic, w/o any interruptions, as
>> data is readily available in the FIFO.
>>
>> With testing done using the mass storage function driver, the results show
>> that with a larger TXFIFO depth, the bandwidth increased significantly.
> 
> Why is this still a "RFC" series?  That implies you don't want this
> applied...
> 

Hi Greg,

As Felipe mentioned, we need to make sure that this TX FIFO resize logic
is carefully thought out, since the behavior could be different based
off the HW configuration as shown in the past.  Eventually, I hope that
this does get applied, but I think the changes needs more detailed
reviews, as there may be potential shortfalls I did not consider due to
my limited knowledge of what happened w/ the previous logic.  That's
pretty much the reason for tagging it as a RFC, since we still need to
hash out if this is the right approach.

Thanks!

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

RE: MFA on RDP

[Wesley de Graaf]

Hi Nick,

Well at least I do have some solid information to work with, I agree its not a 
good solution. But I guess we will be able to get some workaround for this.

Thanks for the info, threat can be closed.

Kind regards,

Wesley.
From: Nick Couchman 
Sent: Friday, May 29, 2020 1:55 PM
To: user@guacamole.apache.org
Subject: Re: MFA on RDP

On Wed, May 27, 2020 at 3:35 AM Wesley de Graaf 
mailto:wes...@workspace365.net>> wrote:
Hi,

Sometimes we encounter an issue with the default timeout on the RDP connection 
in the guacamole. As far as we know the default is 15 seconds. But in some 
cases a user has to give an MFA consent on RDP connection and then the 15 
seconds are to short and the connection is closed and reconnect attempt is 
started.

Does anyone have a suggestion for this?


This is something I've looked into in the past - in fact, I have a JIRA issue 
opened for the ability to configure timeouts.  Unfortunately, the way RDP 
support works in Guacamole, leveraging the FreeRDP libraries, it relies on the 
FreeRDP libraries for the ability to set things like timeout, and the FreeRDP 
library does not support that, and they have basically refused to implement it. 
 So, I'm not sure there's a good answer for this today, except to educate users 
that they'd better have MFA ready when they log in so that they can hit that 15 
second window.  And, yes, I know that's not a good answer

-Nick

Re: Stus-List Stupid Sailing Trick Contest

[Patrick Wesley via CnC-List]

Hi Joe, thanks for this, I'm wrestling with sale process and needed a laugh! My 
other response is, how long have you got? Patrick. The Boat. 24 Mk II

On May 28, 2020 at 7:36 a.m., Joe Della Barba via CnC-List 
 wrote:


Has anyone got me beat for 2020?

I backed out of my slip right onto the dinghy painter, which somehow
didn't float well enough and wrapped right around the prop shaft :(

After a refreshing swim to unwind that, I went up the river to fix a
mooring and fixed the WRONG ONE. I got a phone call thanking me from my
buddy who was wondering who got his stuck shackle loose, he was dreading
the job. I also discovered either barnacles grow WAY faster than anyone
ever realized or the diver missed a spot last week.

Joe Della Barba

Coquina C 35 MK I



___

Thanks everyone for supporting this list with your contributions. Each and 
every one is greatly appreciated. If you want to support the list - use PayPal 
to send contribution -- https://www.paypal.me/stumurray

___

Thanks everyone for supporting this list with your contributions.  Each and 
every one is greatly appreciated.  If you want to support the list - use PayPal 
to send contribution --   https://www.paypal.me/stumurray

[RFC v3 2/3] arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic

[Wesley Cheng]

Enable the flexible TX FIFO resize logic on SM8150.  Using a larger TX FIFO
SZ can help account for situations when system latency is greater than the
USB bus transmission latency.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi 
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index a36512d..c285233 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -708,6 +708,7 @@
interrupts = ;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+   tx-fifo-resize;
phys = <_1_hsphy>, <_1_ssphy>;
phy-names = "usb2-phy", "usb3-phy";
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[RFC v3 1/3] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Wesley Cheng]

Some devices have USB compositions which may require multiple endpoints
that support EP bursting.  HW defined TX FIFO sizes may not always be
sufficient for these compositions.  By utilizing flexible TX FIFO
allocation, this allows for endpoints to request the required FIFO depth to
achieve higher bandwidth.  With some higher bMaxBurst configurations, using
a larger TX FIFO size results in better TX throughput.

Ensure that one TX FIFO is reserved for every IN endpoint.  This allows for
the FIFO logic to prevent running out of FIFO space.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/core.c   |   2 +
 drivers/usb/dwc3/core.h   |   8 
 drivers/usb/dwc3/ep0.c|  37 ++-
 drivers/usb/dwc3/gadget.c | 115 ++
 4 files changed, 161 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index edc1715..cca5554 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1304,6 +1304,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
_thr_num_pkt_prd);
device_property_read_u8(dev, "snps,tx-max-burst-prd",
_max_burst_prd);
+   dwc->needs_fifo_resize = device_property_read_bool(dev,
+   "tx-fifo-resize");
 
dwc->disable_scramble_quirk = device_property_read_bool(dev,
"snps,disable_scramble_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4c171a8..ce0bf28 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -675,6 +675,7 @@ struct dwc3_event_buffer {
  * isochronous START TRANSFER command failure workaround
  * @start_cmd_status: the status of testing START TRANSFER command with
  * combo_num = 'b00
+ * @fifo_depth: allocated TXFIFO depth
  */
 struct dwc3_ep {
struct usb_ep   endpoint;
@@ -727,6 +728,7 @@ struct dwc3_ep {
/* For isochronous START TRANSFER workaround only */
u8  combo_num;
int start_cmd_status;
+   int fifo_depth;
 };
 
 enum dwc3_phy {
@@ -1004,6 +1006,7 @@ struct dwc3_scratchpad_array {
  * 1   - utmi_l1_suspend_n
  * @is_fpga: true when we are using the FPGA board
  * @pending_events: true when we have pending IRQs to be handled
+ * @needs_fifo_resize: not all users might want fifo resizing, flag it
  * @pullups_connected: true when Run/Stop bit is set
  * @setup_packet_pending: true when there's a Setup Packet in FIFO. Workaround
  * @three_stage_setup: set if we perform a three phase setup
@@ -1044,6 +1047,8 @@ struct dwc3_scratchpad_array {
  * @dis_metastability_quirk: set to disable metastability quirk.
  * @imod_interval: set the interrupt moderation interval in 250ns
  * increments or 0 to disable.
+ * @last_fifo_depth: total TXFIFO depth of all enabled USB IN/INT endpoints
+ * @num_ep_resized: the number of TX FIFOs that have already been resized
  */
 struct dwc3 {
struct work_struct  drd_work;
@@ -1204,6 +1209,7 @@ struct dwc3 {
unsignedis_utmi_l1_suspend:1;
unsignedis_fpga:1;
unsignedpending_events:1;
+   unsignedneeds_fifo_resize:1;
unsignedpullups_connected:1;
unsignedsetup_packet_pending:1;
unsignedthree_stage_setup:1;
@@ -1236,6 +1242,8 @@ struct dwc3 {
unsigneddis_metastability_quirk:1;
 
u16 imod_interval;
+   int last_fifo_depth;
+   int num_ep_resized;
 };
 
 #define INCRX_BURST_MODE 0
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 6dee4da..76db9b5 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -601,8 +601,9 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
 {
enum usb_device_state state = dwc->gadget.state;
u32 cfg;
-   int ret;
+   int ret, num, size;
u32 reg;
+   struct dwc3_ep *dep;
 
cfg = le16_to_cpu(ctrl->wValue);
 
@@ -611,6 +612,40 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
return -EINVAL;
 
case USB_STATE_ADDRESS:
+   /*
+* If tx-fifo-resize flag is not set for the controller, then
+* do not clear existing allocated TXFIFO since we do not
+* allocate it again in dwc3_gadget_resize_tx_fifos
+*/
+   if (dwc->needs_fifo_resize) {
+   /* Read ep0IN related TXFIFO size */
+   dep = dwc->eps[1];
+   size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ

[RFC v3 3/3] dt-bindings: usb: dwc3: Add entry for tx-fifo-resize

[Wesley Cheng]

Re-introduce the comment for the tx-fifo-resize setting for the DWC3
controller.  This allows for vendors to control if they require the TX FIFO
resizing logic on their HW, as the default FIFO size configurations may
already be sufficient.

Signed-off-by: Wesley Cheng 
---
 Documentation/devicetree/bindings/usb/dwc3.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 9946ff9..489f5da 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -105,7 +105,7 @@ Optional properties:
1-16 (DWC_usb31 programming guide section 1.2.3) to
enable periodic ESS TX threshold.
 
- -  tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
  - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
register, undefined length INCR burst type enable and 
INCRx type.
When just one value, which means INCRX burst mode 
enabled. When
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[RFC v3 0/3] Re-introduce TX FIFO resize for larger EP bursting

[Wesley Cheng]

Changes in V3:
 - Removed "Reviewed-by" tags
 - Renamed series back to RFC
 - Modified logic to ensure that fifo_size is reset if we pass the minimum
   threshold.  Tested with binding multiple FDs requesting 6 FIFOs.

Changes in V2:
 - Modified TXFIFO resizing logic to ensure that each EP is reserved a
   FIFO.
 - Removed dev_dbg() prints and fixed typos from patches
 - Added some more description on the dt-bindings commit message

Currently, there is no functionality to allow for resizing the TXFIFOs, and
relying on the HW default setting for the TXFIFO depth.  In most cases, the
HW default is probably sufficient, but for USB compositions that contain
multiple functions that require EP bursting, the default settings
might not be enough.  Also to note, the current SW will assign an EP to a
function driver w/o checking to see if the TXFIFO size for that particular
EP is large enough. (this is a problem if there are multiple HW defined
values for the TXFIFO size)

It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3
is required for an EP that supports bursting.  Otherwise, there may be
frequent occurences of bursts ending.  For high bandwidth functions,
such as data tethering (protocols that support data aggregation), mass
storage, and media transfer protocol (over FFS), the bMaxBurst value can be
large, and a bigger TXFIFO depth may prove to be beneficial in terms of USB
throughput. (which can be associated to system access latency, etc...)  It
allows for a more consistent burst of traffic, w/o any interruptions, as
data is readily available in the FIFO.

With testing done using the mass storage function driver, the results show
that with a larger TXFIFO depth, the bandwidth increased significantly.

Test Parameters:
 - Platform: Qualcomm SM8150
 - bMaxBurst = 6
 - USB req size = 256kB
 - Num of USB reqs = 16
 - USB Speed = Super-Speed
 - Function Driver: Mass Storage (w/ ramdisk)
 - Test Application: CrystalDiskMark

Results:

TXFIFO Depth = 3 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 193.60
  |   | 195.86
  |   | 184.77
  |   | 193.60
---

TXFIFO Depth = 6 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 287.35
  |   | 304.94
  |   | 289.64
  |   | 293.61
-------

Wesley Cheng (3):
  usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
  arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic
  dt-bindings: usb: dwc3: Add entry for tx-fifo-resize

 Documentation/devicetree/bindings/usb/dwc3.txt |   2 +-
 arch/arm64/boot/dts/qcom/sm8150.dtsi   |   1 +
 drivers/usb/dwc3/core.c|   2 +
 drivers/usb/dwc3/core.h|   8 ++
 drivers/usb/dwc3/ep0.c |  37 +++-
 drivers/usb/dwc3/gadget.c  | 115 +
 6 files changed, 163 insertions(+), 2 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[jira] [Commented] (SPARK-31836) input_file_name() gives wrong value following Python UDF usage

[Wesley Hildebrandt (Jira)]

[ 
https://issues.apache.org/jira/browse/SPARK-31836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117726#comment-17117726
 ] 

Wesley Hildebrandt commented on SPARK-31836:


One last note .. with only four (or fewer) files this doesn't happen, I suspect 
because PySpark uses four executors so each only takes a single input file.

> input_file_name() gives wrong value following Python UDF usage
> --
>
> Key: SPARK-31836
> URL: https://issues.apache.org/jira/browse/SPARK-31836
> Project: Spark
>  Issue Type: Bug
>  Components: Spark Core
>Affects Versions: 3.0.0
>Reporter: Wesley Hildebrandt
>Priority: Major
>
> I'm using PySpark for Spark 3.0.0 RC1 with Python 3.6.8.
> The following commands demonstrate that the input_file_name() function 
> sometimes returns the wrong filename following usage of a Python UDF:
> $ for i in `seq 5`; do echo $i > /tmp/test-file-$i; done
> $ pyspark
> >>> import pyspark.sql.functions as F
> >>> spark.readStream.text('file:///tmp/test-file-*', 
> >>> wholetext=True).withColumn('file1', 
> >>> F.input_file_name()).withColumn('udf', F.udf(lambda 
> >>> x:x)('value')).withColumn('file2', 
> >>> F.input_file_name()).writeStream.trigger(once=True).foreachBatch(lambda 
> >>> df,_: df.select('file1','file2').show(truncate=False, 
> >>> vertical=True)).start().awaitTermination()
> A few notes about this bug:
>  * It happens with many different files, so it's not related to the file 
> contents
>  * It also happens loading files from HDFS, so storage location is not a 
> factor
>  * It also happens using .csv() to read the files instead of .text(), so 
> input format is not a factor
>  * I have not been able to cause the error without using readStream, so it 
> seems to be related to streaming
>  * The bug also happens using spark-submit to send a job to my cluster
>  * I haven't tested an older version, but it's possible that Spark pulls 
> 24958 and 25321([https://github.com/apache/spark/pull/24958], 
> [https://github.com/apache/spark/pull/25321]) to fix issue 28153 
> (https://issues.apache.org/jira/browse/SPARK-28153) introduced this bug?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

[jira] [Created] (SPARK-31836) input_file_name() gives wrong value following Python UDF usage

[Wesley Hildebrandt (Jira)]

Wesley Hildebrandt created SPARK-31836:
--

 Summary: input_file_name() gives wrong value following Python UDF 
usage
 Key: SPARK-31836
 URL: https://issues.apache.org/jira/browse/SPARK-31836
 Project: Spark
  Issue Type: Bug
  Components: Spark Core
Affects Versions: 3.0.0
Reporter: Wesley Hildebrandt


I'm using PySpark for Spark 3.0.0 RC1 with Python 3.6.8.

The following commands demonstrate that the input_file_name() function 
sometimes returns the wrong filename following usage of a Python UDF:

$ for i in `seq 5`; do echo $i > /tmp/test-file-$i; done

$ pyspark

>>> import pyspark.sql.functions as F

>>> spark.readStream.text('file:///tmp/test-file-*', 
>>> wholetext=True).withColumn('file1', F.input_file_name()).withColumn('udf', 
>>> F.udf(lambda x:x)('value')).withColumn('file2', 
>>> F.input_file_name()).writeStream.trigger(once=True).foreachBatch(lambda 
>>> df,_: df.select('file1','file2').show(truncate=False, 
>>> vertical=True)).start().awaitTermination()

A few notes about this bug:
 * It happens with many different files, so it's not related to the file 
contents
 * It also happens loading files from HDFS, so storage location is not a factor
 * It also happens using .csv() to read the files instead of .text(), so input 
format is not a factor
 * I have not been able to cause the error without using readStream, so it 
seems to be related to streaming
 * The bug also happens using spark-submit to send a job to my cluster
 * I haven't tested an older version, but it's possible that Spark pulls 24958 
and 25321([https://github.com/apache/spark/pull/24958], 
[https://github.com/apache/spark/pull/25321]) to fix issue 28153 
(https://issues.apache.org/jira/browse/SPARK-28153) introduced this bug?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

MFA on RDP

[Wesley de Graaf]

Hi,

Sometimes we encounter an issue with the default timeout on the RDP connection 
in the guacamole. As far as we know the default is 15 seconds. But in some 
cases a user has to give an MFA consent on RDP connection and then the 15 
seconds are to short and the connection is closed and reconnect attempt is 
started.

Does anyone have a suggestion for this?

Kind regards,

Wesley

[cobirds] Clarification on RBA

[Jace Wesley Brasher]

Today I noticed that there was no RBA and that there is talk of
discontinuing the RBA. Why is this? Why stop now? Was it causing a problem?
As someone who gets both the ebird and cobird alerts I find that the
cobirds is more thorough and detailed. It would be very disappointing to
see it be discontinued.

Jace Brasher
Loveland CO
Larimer county

-- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/CAP7yTyjQ17A1wvwxkz0wqDunm2KQpszop2u83or4Fkq0oLWVuQ%40mail.gmail.com.

[PATCH] NTB: correct ntb_peer_spad_addr and ntb_peer_spad_read comment typos

[Wesley Sheng]

The comment for ntb_peer_spad_addr and ntb_peer_spad_read
incorrectly referred to peer doorbell register and local
scratchpad register.

Signed-off-by: Wesley Sheng 
---
 include/linux/ntb.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/ntb.h b/include/linux/ntb.h
index 8c13538aeffe..b9b0d805d0f9 100644
--- a/include/linux/ntb.h
+++ b/include/linux/ntb.h
@@ -1351,7 +1351,7 @@ static inline int ntb_spad_write(struct ntb_dev *ntb, int 
sidx, u32 val)
  * @sidx:  Scratchpad index.
  * @spad_addr: OUT - The address of the peer scratchpad register.
  *
- * Return the address of the peer doorbell register.  This may be used, for
+ * Return the address of the peer scratchpad register.  This may be used, for
  * example, by drivers that offload memory copy operations to a dma engine.
  *
  * Return: Zero on success, otherwise an error number.
@@ -1373,7 +1373,7 @@ static inline int ntb_peer_spad_addr(struct ntb_dev *ntb, 
int pidx, int sidx,
  *
  * Read the peer scratchpad register, and return the value.
  *
- * Return: The value of the local scratchpad register.
+ * Return: The value of the peer scratchpad register.
  */
 static inline u32 ntb_peer_spad_read(struct ntb_dev *ntb, int pidx, int sidx)
 {
-- 
2.16.2

Re: [ANNOUNCE] Please welcome Lijin Bin to the HBase PMC

[Wesley]

张铎(Duo Zhang) wrote:

Congratulations!

宾莉金（binlijin）  于2020年5月26日周二 上午9:33写道：


Thanks everybody. It’s an honor to join the PMC and I’ll try to do my best
to help the project and the community.


Congrats Binli Jin.

Stus-List Selling C & C 24 Sidney BC

[Patrick Wesley via CnC-List]

My 1983 24 ft Mk II is now up for sale, asking C$7,500.



https://www.usedvictoria.com/classified-ad/1983-24-ft-C--C-sloop_35825144




Patrick Wesley


On May 13, 2020 at 8:59 a.m., Patrick Wesley  wrote:


Regret to say that the time has come to part with The Boat after many years of 
great fun. Watch this space. Any advice on how to do this, I have little 
practice! Patrick Wesley



___

Thanks everyone for supporting this list with your contributions.  Each and 
every one is greatly appreciated.  If you want to support the list - use PayPal 
to send contribution --   https://www.paypal.me/stumurray

[Bug 1878890] Re: [Ubuntu Server 20.04 LTS]: Failed Install (subiquity...install_fail/add_info) during partitioning

[Michael Wesley]

Thanks for fixing this @raharper!
How can I make use of this so I can finally successfully run the installation?
Do I just need to select the "Update Installer" option again?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1878890

Title:
  [Ubuntu Server 20.04 LTS]: Failed Install
  (subiquity...install_fail/add_info) during partitioning

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1878890/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[cobirds] Unknown bird!

[Jace Wesley Brasher]

Today while birding at gateway natural area in fort Collins me and my
family observed a bird that I was unable to identify even after extensive
research. The bird had a completely black body and a deep blue head. We saw
this bird twice in two different locations so there may be multiple. One
time it was observed by my non-birding family, and the second I saw if fly
into a tree overhead. I quickly compared it to the nearby lazuli bunting
and noticed it was not the same. Unlike the lazuli or black throated blue
warbler it did not have a white chest. We also considered blue grosbeak but
they dont have white wing bars where as this bird did.

Any ideas or help is greatly appreciated.
Jace brasher
Larimer county

-- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/CAP7yTyho6fQuwgp0maOVPXVH_nMyx%2BorTwzik7JsUwdSV%3DoiOA%40mail.gmail.com.

Re: [PATCH v2 0/3] Re-introduce TX FIFO resize for larger EP bursting

[Wesley Cheng]

On 5/22/2020 2:54 AM, Felipe Balbi wrote:
> Wesley Cheng  writes:
> 
>> Changes in V2:
>>  - Modified TXFIFO resizing logic to ensure that each EP is reserved a
>>FIFO.
>>  - Removed dev_dbg() prints and fixed typos from patches
>>  - Added some more description on the dt-bindings commit message
>>
>> Reviewed-by: Felipe Balbi 
> 
> I don't remember giving you a Reviewed-by, did I?
> 

Hi Felipe,

Sorry, I put the Reviewed-by tag by mistake, I sent a follow up email to
disregard the tags.  If you need me to resubmit the patch series
version, please let me know.  Thanks!

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: please unsubscribe me

[Wesley]

shiva kumar wrote:

please unsubscribe me.


you should be able to unsubscribe yourself from the list by sending an 
empty email to: user-unsubscr...@pig.apache.org

[PATCH v2] phy: qcom-snps: Add runtime suspend and resume handlers

[Wesley Cheng]

Allow for the PHY to be put into a powered down state when possible.
Add the required suspend and resume callbacks, which will determine
what resources can be turned off depending on the cable status.

Signed-off-by: Wesley Cheng 

---
Changes in v2:
 - Addressed checkpatch alignment/line length warnings.
 - Removed superfluous init in qcom_snps_hsphy_resume().

 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 100 ++
 1 file changed, 100 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c 
b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
index 4d74045..0a4e77af 100644
--- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
+++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
@@ -76,7 +76,9 @@
  * @iface_clk: phy interface clock
  * @phy_reset: phy reset control
  * @vregs: regulator supplies bulk data
+ * @suspended: PHY is in the suspended state
  * @phy_initialized: if PHY has been initialized correctly
+ * @mode: contains the current mode the PHY is in
  */
 struct qcom_snps_hsphy {
struct phy *phy;
@@ -87,7 +89,9 @@ struct qcom_snps_hsphy {
struct reset_control *phy_reset;
struct regulator_bulk_data vregs[SNPS_HS_NUM_VREGS];
 
+   bool suspended;
bool phy_initialized;
+   enum phy_mode mode;
 };
 
 static inline void qcom_snps_hsphy_write_mask(void __iomem *base, u32 offset,
@@ -104,6 +108,84 @@ static inline void qcom_snps_hsphy_write_mask(void __iomem 
*base, u32 offset,
readl_relaxed(base + offset);
 }
 
+static int qcom_snps_hsphy_suspend(struct qcom_snps_hsphy *hsphy)
+{
+   if (hsphy->suspended)
+   return 0;
+
+   dev_dbg(>phy->dev, "Suspend QCOM SNPS PHY, mode:%d\n",
+   hsphy->mode);
+
+   if (hsphy->mode == PHY_MODE_USB_HOST) {
+   /* Enable auto-resume to meet remote wakeup timing */
+   qcom_snps_hsphy_write_mask(hsphy->base,
+   USB2_PHY_USB_PHY_HS_PHY_CTRL2,
+   USB2_AUTO_RESUME,
+   USB2_AUTO_RESUME);
+   usleep_range(500, 1000);
+   qcom_snps_hsphy_write_mask(hsphy->base,
+   USB2_PHY_USB_PHY_HS_PHY_CTRL2,
+   0, USB2_AUTO_RESUME);
+   }
+
+   clk_disable_unprepare(hsphy->cfg_ahb_clk);
+   hsphy->suspended = true;
+
+   return 0;
+}
+
+static int qcom_snps_hsphy_resume(struct qcom_snps_hsphy *hsphy)
+{
+   int ret;
+
+   if (!hsphy->suspended)
+   return 0;
+
+   dev_dbg(>phy->dev, "Resume QCOM SNPS PHY, mode:%d\n",
+   hsphy->mode);
+
+   ret = clk_prepare_enable(hsphy->cfg_ahb_clk);
+   if (ret) {
+   dev_err(>phy->dev,
+   "failed to enable cfg ahb clock, %d\n", ret);
+   return ret;
+   }
+
+   hsphy->suspended = false;
+   return 0;
+}
+
+static int __maybe_unused qcom_snps_hsphy_runtime_suspend(struct device *dev)
+{
+   struct qcom_snps_hsphy *hsphy = dev_get_drvdata(dev);
+
+   if (!hsphy->phy_initialized)
+   return 0;
+
+   qcom_snps_hsphy_suspend(hsphy);
+   return 0;
+}
+
+static int __maybe_unused qcom_snps_hsphy_runtime_resume(struct device *dev)
+{
+   struct qcom_snps_hsphy *hsphy = dev_get_drvdata(dev);
+
+   if (!hsphy->phy_initialized)
+   return 0;
+
+   qcom_snps_hsphy_resume(hsphy);
+   return 0;
+}
+
+static int qcom_snps_hsphy_set_mode(struct phy *phy, enum phy_mode mode,
+   int submode)
+{
+   struct qcom_snps_hsphy *hsphy = phy_get_drvdata(phy);
+
+   hsphy->mode = mode;
+   return 0;
+}
+
 static int qcom_snps_hsphy_init(struct phy *phy)
 {
struct qcom_snps_hsphy *hsphy = phy_get_drvdata(phy);
@@ -175,6 +257,7 @@ static int qcom_snps_hsphy_init(struct phy *phy)
UTMI_PHY_CMN_CTRL_OVERRIDE_EN, 0);
 
hsphy->phy_initialized = true;
+   hsphy->suspended = false;
 
return 0;
 
@@ -201,6 +284,7 @@ static int qcom_snps_hsphy_exit(struct phy *phy)
 static const struct phy_ops qcom_snps_hsphy_gen_ops = {
.init   = qcom_snps_hsphy_init,
.exit   = qcom_snps_hsphy_exit,
+   .set_mode   = qcom_snps_hsphy_set_mode,
.owner  = THIS_MODULE,
 };
 
@@ -212,6 +296,11 @@ static int qcom_snps_hsphy_exit(struct phy *phy)
 };
 MODULE_DEVICE_TABLE(of, qcom_snps_hsphy_of_match_table);
 
+static const struct dev_pm_ops qcom_snps_hsphy_pm_ops = {
+   SET_RUNTIME_PM_OPS(qcom_snps_hsphy_runtime_suspend,
+  qcom_snps_hsphy_runtime_resume, NULL)
+};
+
 static int qcom_snps_hsphy_probe(struct platform_device *pdev)
 {
struct device 

Re: [PATCH v2 0/3] Re-introduce TX FIFO resize for larger EP bursting

[Wesley Cheng]

On 5/21/2020 1:36 AM, Wesley Cheng wrote:
> Changes in V2:
>  - Modified TXFIFO resizing logic to ensure that each EP is reserved a
>FIFO.
>  - Removed dev_dbg() prints and fixed typos from patches
>  - Added some more description on the dt-bindings commit message
>


> Reviewed-by: Felipe Balbi 
> Reviewed-by: Rob Herring 
> 

Sorry, please disregard the Reviewed-by tags in the patches.  I added
those mistakenly.

> Currently, there is no functionality to allow for resizing the TXFIFOs, and
> relying on the HW default setting for the TXFIFO depth.  In most cases, the
> HW default is probably sufficient, but for USB compositions that contain
> multiple functions that require EP bursting, the default settings
> might not be enough.  Also to note, the current SW will assign an EP to a
> function driver w/o checking to see if the TXFIFO size for that particular
> EP is large enough. (this is a problem if there are multiple HW defined
> values for the TXFIFO size)
> 
> It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3
> is required for an EP that supports bursting.  Otherwise, there may be
> frequent occurences of bursts ending.  For high bandwidth functions,
> such as data tethering (protocols that support data aggregation), mass
> storage, and media transfer protocol (over FFS), the bMaxBurst value can be
> large, and a bigger TXFIFO depth may prove to be beneficial in terms of USB
> throughput. (which can be associated to system access latency, etc...)  It
> allows for a more consistent burst of traffic, w/o any interruptions, as
> data is readily available in the FIFO.
> 
> With testing done using the mass storage function driver, the results show
> that with a larger TXFIFO depth, the bandwidth increased significantly.
> 
> Test Parameters:
>  - Platform: Qualcomm SM8150
>  - bMaxBurst = 6
>  - USB req size = 256kB
>  - Num of USB reqs = 16
>  - USB Speed = Super-Speed
>  - Function Driver: Mass Storage (w/ ramdisk)
>  - Test Application: CrystalDiskMark
> 
> Results:
> 
> TXFIFO Depth = 3 max packets
> 
> Test Case | Data Size | AVG tput (in MB/s)
> ---
> Sequential|1 GB x | 
> Read  |9 loops| 193.60
> |   | 195.86
>   |   | 184.77
>   |   | 193.60
> ---
> 
> TXFIFO Depth = 6 max packets
> 
> Test Case | Data Size | AVG tput (in MB/s)
> ---
> Sequential|1 GB x | 
> Read  |9 loops| 287.35
> |   | 304.94
>   |   | 289.64
>   |   | 293.61
> ---
> 
> Wesley Cheng (3):
>   usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
>   arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic
>   dt-bindings: usb: dwc3: Add entry for tx-fifo-resize
> 
>  Documentation/devicetree/bindings/usb/dwc3.txt |   2 +-
>  arch/arm64/boot/dts/qcom/sm8150.dtsi   |   1 +
>  drivers/usb/dwc3/core.c|   2 +
>  drivers/usb/dwc3/core.h|   8 ++
>  drivers/usb/dwc3/ep0.c |  37 -
>  drivers/usb/dwc3/gadget.c  | 111 
> +
>  6 files changed, 159 insertions(+), 2 deletions(-)
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 1/3] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Wesley Cheng]

Some devices have USB compositions which may require multiple endpoints
that support EP bursting.  HW defined TX FIFO sizes may not always be
sufficient for these compositions.  By utilizing flexible TX FIFO
allocation, this allows for endpoints to request the required FIFO depth to
achieve higher bandwidth.  With some higher bMaxBurst configurations, using
a larger TX FIFO size results in better TX throughput.

Ensure that one TX FIFO is reserved for every IN endpoint.  This allows for
the FIFO logic to prevent running out of FIFO space.

Signed-off-by: Wesley Cheng 
Reviewed-by: Felipe Balbi 
---
 drivers/usb/dwc3/core.c   |   2 +
 drivers/usb/dwc3/core.h   |   8 
 drivers/usb/dwc3/ep0.c|  37 +++-
 drivers/usb/dwc3/gadget.c | 111 ++
 4 files changed, 157 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index edc1715..cca5554 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1304,6 +1304,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
_thr_num_pkt_prd);
device_property_read_u8(dev, "snps,tx-max-burst-prd",
_max_burst_prd);
+   dwc->needs_fifo_resize = device_property_read_bool(dev,
+   "tx-fifo-resize");
 
dwc->disable_scramble_quirk = device_property_read_bool(dev,
"snps,disable_scramble_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4c171a8..ce0bf28 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -675,6 +675,7 @@ struct dwc3_event_buffer {
  * isochronous START TRANSFER command failure workaround
  * @start_cmd_status: the status of testing START TRANSFER command with
  * combo_num = 'b00
+ * @fifo_depth: allocated TXFIFO depth
  */
 struct dwc3_ep {
struct usb_ep   endpoint;
@@ -727,6 +728,7 @@ struct dwc3_ep {
/* For isochronous START TRANSFER workaround only */
u8  combo_num;
int start_cmd_status;
+   int fifo_depth;
 };
 
 enum dwc3_phy {
@@ -1004,6 +1006,7 @@ struct dwc3_scratchpad_array {
  * 1   - utmi_l1_suspend_n
  * @is_fpga: true when we are using the FPGA board
  * @pending_events: true when we have pending IRQs to be handled
+ * @needs_fifo_resize: not all users might want fifo resizing, flag it
  * @pullups_connected: true when Run/Stop bit is set
  * @setup_packet_pending: true when there's a Setup Packet in FIFO. Workaround
  * @three_stage_setup: set if we perform a three phase setup
@@ -1044,6 +1047,8 @@ struct dwc3_scratchpad_array {
  * @dis_metastability_quirk: set to disable metastability quirk.
  * @imod_interval: set the interrupt moderation interval in 250ns
  * increments or 0 to disable.
+ * @last_fifo_depth: total TXFIFO depth of all enabled USB IN/INT endpoints
+ * @num_ep_resized: the number of TX FIFOs that have already been resized
  */
 struct dwc3 {
struct work_struct  drd_work;
@@ -1204,6 +1209,7 @@ struct dwc3 {
unsignedis_utmi_l1_suspend:1;
unsignedis_fpga:1;
unsignedpending_events:1;
+   unsignedneeds_fifo_resize:1;
unsignedpullups_connected:1;
unsignedsetup_packet_pending:1;
unsignedthree_stage_setup:1;
@@ -1236,6 +1242,8 @@ struct dwc3 {
unsigneddis_metastability_quirk:1;
 
u16 imod_interval;
+   int last_fifo_depth;
+   int num_ep_resized;
 };
 
 #define INCRX_BURST_MODE 0
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 6dee4da..76db9b5 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -601,8 +601,9 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
 {
enum usb_device_state state = dwc->gadget.state;
u32 cfg;
-   int ret;
+   int ret, num, size;
u32 reg;
+   struct dwc3_ep *dep;
 
cfg = le16_to_cpu(ctrl->wValue);
 
@@ -611,6 +612,40 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
return -EINVAL;
 
case USB_STATE_ADDRESS:
+   /*
+* If tx-fifo-resize flag is not set for the controller, then
+* do not clear existing allocated TXFIFO since we do not
+* allocate it again in dwc3_gadget_resize_tx_fifos
+*/
+   if (dwc->needs_fifo_resize) {
+   /* Read ep0IN related TXFIFO size */
+   dep = dwc->eps[1];
+   size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ

[PATCH v2 3/3] dt-bindings: usb: dwc3: Add entry for tx-fifo-resize

[Wesley Cheng]

Re-introduce the comment for the tx-fifo-resize setting for the DWC3
controller.  This allows for vendors to control if they require the TX FIFO
resizing logic on their HW, as the default FIFO size configurations may
already be sufficient.

Signed-off-by: Wesley Cheng 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/dwc3.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 9946ff9..489f5da 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -105,7 +105,7 @@ Optional properties:
1-16 (DWC_usb31 programming guide section 1.2.3) to
enable periodic ESS TX threshold.
 
- -  tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
  - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
register, undefined length INCR burst type enable and 
INCRx type.
When just one value, which means INCRX burst mode 
enabled. When
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 2/3] arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic

[Wesley Cheng]

Enable the flexible TX FIFO resize logic on SM8150.  Using a larger TX FIFO
SZ can help account for situations when system latency is greater than the
USB bus transmission latency.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi 
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index a36512d..c285233 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -708,6 +708,7 @@
interrupts = ;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+   tx-fifo-resize;
phys = <_1_hsphy>, <_1_ssphy>;
phy-names = "usb2-phy", "usb3-phy";
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 0/3] Re-introduce TX FIFO resize for larger EP bursting

[Wesley Cheng]

Changes in V2:
 - Modified TXFIFO resizing logic to ensure that each EP is reserved a
   FIFO.
 - Removed dev_dbg() prints and fixed typos from patches
 - Added some more description on the dt-bindings commit message

Reviewed-by: Felipe Balbi 
Reviewed-by: Rob Herring 

Currently, there is no functionality to allow for resizing the TXFIFOs, and
relying on the HW default setting for the TXFIFO depth.  In most cases, the
HW default is probably sufficient, but for USB compositions that contain
multiple functions that require EP bursting, the default settings
might not be enough.  Also to note, the current SW will assign an EP to a
function driver w/o checking to see if the TXFIFO size for that particular
EP is large enough. (this is a problem if there are multiple HW defined
values for the TXFIFO size)

It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3
is required for an EP that supports bursting.  Otherwise, there may be
frequent occurences of bursts ending.  For high bandwidth functions,
such as data tethering (protocols that support data aggregation), mass
storage, and media transfer protocol (over FFS), the bMaxBurst value can be
large, and a bigger TXFIFO depth may prove to be beneficial in terms of USB
throughput. (which can be associated to system access latency, etc...)  It
allows for a more consistent burst of traffic, w/o any interruptions, as
data is readily available in the FIFO.

With testing done using the mass storage function driver, the results show
that with a larger TXFIFO depth, the bandwidth increased significantly.

Test Parameters:
 - Platform: Qualcomm SM8150
 - bMaxBurst = 6
 - USB req size = 256kB
 - Num of USB reqs = 16
 - USB Speed = Super-Speed
 - Function Driver: Mass Storage (w/ ramdisk)
 - Test Application: CrystalDiskMark

Results:

TXFIFO Depth = 3 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 193.60
  |   | 195.86
  |   | 184.77
  |   | 193.60
---

TXFIFO Depth = 6 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 287.35
  |   | 304.94
  |   | 289.64
  |   | 293.61
---

Wesley Cheng (3):
  usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
  arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic
  dt-bindings: usb: dwc3: Add entry for tx-fifo-resize

 Documentation/devicetree/bindings/usb/dwc3.txt |   2 +-
 arch/arm64/boot/dts/qcom/sm8150.dtsi   |   1 +
 drivers/usb/dwc3/core.c|   2 +
 drivers/usb/dwc3/core.h|   8 ++
 drivers/usb/dwc3/ep0.c |  37 -
 drivers/usb/dwc3/gadget.c  | 111 +
 6 files changed, 159 insertions(+), 2 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[Bug 1875560] Re: subiquity crashes on configuring existing partition

[Michael Wesley]

Has this bug been confirmed as fixed?

I'm still experiencing this error, even when using the new installer as
prompted during the update.

https://bugs.launchpad.net/subiquity/+bug/1878890

Unless something else is going on in with my installation...?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1875560

Title:
  subiquity crashes on configuring existing partition

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1875560/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[cobirds] Townsend's warbler Oxbow Natural Area. Loveland, Larimer county

[Jace Wesley Brasher]

Male Townsend's warbler on the hidden hogback trail south of oxbow. Seen
from both sides. In trees river side 90 yards down the hogback trail.
photos coming soon

Jace Brasher
Loveland
Larimer county

-- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/CAP7yTyjfCxe_t57MDCXb9mV8jPpybFnt19yc79jccuXBc5JhCA%40mail.gmail.com.

[cobirds] Re: Townsend's warbler Oxbow Natural Area. Loveland, Larimer county

[Jace Wesley Brasher]

Many Blackpoll warblers as well!

On Sat, May 16, 2020, 12:27 PM Jace Wesley Brasher  wrote:

> Male Townsend's warbler on the hidden hogback trail south of oxbow. Seen
> from both sides. In trees river side 90 yards down the hogback trail.
> photos coming soon
>
> Jace Brasher
> Loveland
> Larimer county
>

-- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/CAP7yTyiL-%3DYB-dP2UsowQmKrOytH1OLdu7pk%2BcVr%3DR%2B6PdG-Fw%40mail.gmail.com.

[cobirds] Re: Chestnut sided warbler larimer county

[Jace Wesley Brasher]

If you need help locating or want more information email or call me.
970-413-1240

On Fri, May 15, 2020, 5:27 PM Jace Wesley Brasher  wrote:

> According to google maps coordinates are 40.4024885, -105.1459421
>
> On Fri, May 15, 2020, 5:24 PM Jace Wesley Brasher 
> wrote:
>
>> Hello,
>> Currently looking at a chestnut sided warbler in loveland. Adult male on
>> the 15th hole Of mariana butte golf course just south of the west side of
>> oxbow natural area. It is just behind the green west of the hole. Photos
>> coming.
>>
>> Jace brasher
>> Larimer county
>> Loveland
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/CAP7yTyijOK_iyE9%3DpcyUqTVRsvejbCuYCd28mNZ1-E2LcEBfuQ%40mail.gmail.com.

[cobirds] Re: Chestnut sided warbler larimer county

[Jace Wesley Brasher]

According to google maps coordinates are 40.4024885, -105.1459421

On Fri, May 15, 2020, 5:24 PM Jace Wesley Brasher  wrote:

> Hello,
> Currently looking at a chestnut sided warbler in loveland. Adult male on
> the 15th hole Of mariana butte golf course just south of the west side of
> oxbow natural area. It is just behind the green west of the hole. Photos
> coming.
>
> Jace brasher
> Larimer county
> Loveland
>

-- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/CAP7yTyjKUhjCYHHZEQA7t_cU%3DzLrg8nYFr%2BF-e3VqQ%2B5UjGb%2Bw%40mail.gmail.com.

[cobirds] Chestnut sided warbler larimer county

[Jace Wesley Brasher]

Hello,
Currently looking at a chestnut sided warbler in loveland. Adult male on
the 15th hole Of mariana butte golf course just south of the west side of
oxbow natural area. It is just behind the green west of the hole. Photos
coming.

Jace brasher
Larimer county
Loveland

-- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/CAP7yTyjs2xetHa%3DhnscHJcRgwQeydn7Kaj7L_j0SO8ppgrGaug%40mail.gmail.com.

Re: [RFC 3/3] dt-bindings: usb: dwc3: Add entry for tx-fifo-resize

[Wesley Cheng]

On 5/14/2020 8:10 PM, Rob Herring wrote:
> On Thu, May 07, 2020 at 02:59:28PM -0700, Wesley Cheng wrote:
>> Re-introduce the comment for the tx-fifo-resize setting for the DWC3
>> controller.
> 
> Why?
> 

Hi Rob,

Initially, the reasoning behind bringing back the DTSI parameter, was to
address situations where vendors don't require the resizing logic.  I
was assuming that each vendor has their own HW configuration for the TX
FIFO size, and some may already have sufficient space to account for
their endpoint requirements.  However, if Felipe doesn't believe we need
to have a DTSI parameter for this, then we don't need to re-add this
back in.

>>
>> Signed-off-by: Wesley Cheng 
>> ---
>>  Documentation/devicetree/bindings/usb/dwc3.txt | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
>> b/Documentation/devicetree/bindings/usb/dwc3.txt
>> index 9946ff9..489f5da 100644
>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>> @@ -105,7 +105,7 @@ Optional properties:
>>  1-16 (DWC_usb31 programming guide section 1.2.3) to
>>  enable periodic ESS TX threshold.
>>  
>> - -  tx-fifo-resize: determines if the FIFO *has* to be 
>> reallocated.
>> + - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
>>   - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
>>  register, undefined length INCR burst type enable and 
>> INCRx type.
>>  When just one value, which means INCRX burst mode 
>> enabled. When
>> -- 
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: Stus-List Preparing to sell C & C 24 Sidney BC

[Patrick Wesley via CnC-List]

Thanks, Peter, good advice. Good point about the photos. 

On May 13, 2020 at 9:56 p.m., Peter Fell  wrote:


Are you speaking of the legal paperwork, etc required for a sale, or more how / 
where to advertise?


With respect to the latter, are you a member of any of the Facebook C groups? 
You could try there. Also Usedvictoria, craigslist, kijiji, varagesale, etc. Look 
at detail provided on some of the broker sites in terms of details,  listing of 
included equipment, etc. Online sites vary in terms of number of pictures , etc 
allowed, so I'd make up a fact sheet / scan copies of survey, etc (redact personal 
information) and extra pictures and put them up on a image hosting site like 
Flickr. Then link in the ad.


By the way I hate ads that show multiple interior shots and nothing of any of 
the systems, engine, etc.


On Wed., May 13, 2020, 9:01 a.m. Patrick Wesley via CnC-List, 
 wrote:

Regret to say that the time has come to part with The Boat after many years of 
great fun. Watch this space. Any advice on how to do this, I have little 
practice! Patrick Wesley




___

Thanks everyone for supporting this list with your contributions.  Each and 
every one is greatly appreciated.  If you want to support the list - use PayPal 
to send contribution --   https://www.paypal.me/stumurray

___

Thanks everyone for supporting this list with your contributions.  Each and 
every one is greatly appreciated.  If you want to support the list - use PayPal 
to send contribution --   https://www.paypal.me/stumurray

Stus-List Preparing to sell C & C 24 Sidney BC

[Patrick Wesley via CnC-List]

Regret to say that the time has come to part with The Boat after many years of 
great fun. Watch this space. Any advice on how to do this, I have little 
practice! Patrick Wesley



___

Thanks everyone for supporting this list with your contributions.  Each and 
every one is greatly appreciated.  If you want to support the list - use PayPal 
to send contribution --   https://www.paypal.me/stumurray

RE: [cayugabirds-l] ebird reporting question re: motion activated photos

[Wesley M. Hochachka]

 that is based on assuming that all of the 
observations are made by people.  It would be a completely different story if 
*all* of the observations are being made by camera traps, in which case 
observations from the cameras are comparable (Snapshot Serengeti is a good 
demonstration of this, I think), and the occasional human-made observation 
would just cause problems.
   Basically, eBird was not designed for, and shouldn’t be used for information 
from camera traps (or reports of dead birds, or reports of birds seen and heard 
from live-streaming feeder cams).  That’s not the sort of information that 
eBird was designed to collect.

   Having written that, personally, I see nothing wrong with including a camera 
trap’s photograph as an accompaniment to an eBird checklist documenting 
observations that a person has made, even if the human observation was from a 
different (but nearby) period of time, like hearing an owl at dusk and then 
having the camera trap photograph it later in the evening.  A photograph like 
that is just support for the auditory identification.  I will hasten to add 
that I am just expressing my own personal opinion here, and I am absolutely, 
totally *not* stating or creating any official eBird policy.

   Finally, I’ll quickly note that eBird checklists of camera-trap 
“observations” are problematic from a birding perspective, because it’s not 
clear if a bird watcher has actually seen or heard a species themselves, and 
there’s a potentially slippery slope running from reporting that one has seen a 
species in a photo from their camera trap, through to having seen species on a 
feeder cam, and further into a gray zone of what it means to put a species on 
one’s life list.  An arbitrary line has to be drawn somewhere, and eBird (and, 
I think, birders in general) draw that line at requiring an actual human to 
have detected a species in real time.

   For those of you who made it to the end of this uncharacteristically long 
CAYUGABIRDS-L post, apologies for my verbosity, but I just cannot think of a 
briefer way of answering Deb’s question.

Wesley




From: bounce-124627226-3494...@list.cornell.edu 
 On Behalf Of Deborah G Lauper
Sent: Tuesday, May 12, 2020 5:35 PM
To: CAYUGABIRDS-L 
Subject: [cayugabirds-l] ebird reporting question re: motion activated photos

Maybe someone can clarify or refer me to the right place. I have lived and 
birded in the Cayugabirds region for 30+ years and use ebird. I also spend 
winters in Arizona, specifically Pima County (near Tucson, Madera Canyon etc). 
Owls have been visiting our bird baths nightly. Great Horned and Western 
Screech, got great pictures on motion activated cams. I recently learned that 
ebird does not want motion activated pictures and also, don't bother reporting 
it unless you saw it directly. My question is why? The ebird expert/monitor 
from this county (great guy by the way) advised me of this and said he doesn’t 
agree with it and doesn’t know the rationale either. Anyway, it’s amazing what 
we get on our motion cameras, mammals and birds, and it would be great to be 
able to include the birds on ebird. I want to be as accurate as possible and 
follow the rules so I deleted my owl pictures and sightings but I’m 
disappointed and hope I can get an explanation.
Deb Lauper (Corning, NY and Sahuarita, AZ)


--
Cayugabirds-L List Info:
Welcome and Basics<http://www.northeastbirding.com/CayugabirdsWELCOME>
Rules and Information<http://www.northeastbirding.com/CayugabirdsRULES>
Subscribe, Configuration and 
Leave<http://www.northeastbirding.com/CayugabirdsSubscribeConfigurationLeave.htm>
Archives:
The Mail 
Archive<http://www.mail-archive.com/cayugabirds-l@cornell.edu/maillist.html>
Surfbirds<http://www.surfbirds.com/birdingmail/Group/Cayugabirds>
BirdingOnThe.Net<http://birdingonthe.net/mailinglists/CAYU.html>
Please submit your observations to eBird<http://ebird.org/content/ebird/>!
--
--
Cayugabirds-L List Info:
Welcome and Basics<http://www.northeastbirding.com/CayugabirdsWELCOME>
Rules and Information<http://www.northeastbirding.com/CayugabirdsRULES>
Subscribe, Configuration and 
Leave<http://www.northeastbirding.com/CayugabirdsSubscribeConfigurationLeave.htm>
Archives:
The Mail 
Archive<http://www.mail-archive.com/cayugabirds-l@cornell.edu/maillist.html>
Surfbirds<http://www.surfbirds.com/birdingmail/Group/Cayugabirds>
BirdingOnThe.Net<http://birdingonthe.net/mailinglists/CAYU.html>
Please submit your observations to eBird<http://ebird.org/content/ebird/>!
--

--

Cayugabirds-L List Info:
http://www.NortheastBirding.com/CayugabirdsWELCOME
http://www.NortheastBirding.com/CayugabirdsRULES
http://www.NortheastBirding.com/CayugabirdsSubscribeConfigurationLeave.htm

ARCHIVES:
1) http://www.mail-archive.com/cayugabirds-l@cornell.edu/maillist.html
2) http://www.surfbirds.com/birdingmail/Group/Cayugabirds
3) http://birdingonthe.net/mailinglists/CAYU.html

Please submit your observations to eBird:
http://ebird.org/content/ebird/

--

[Mpi-forum] June 2020 MPI Forum Meeting Registration

[Wesley Bland via mpi-forum]

Hi all,

Now that the meeting in June is official an exceptional virtual meeting, the 
registration page is now open here:

https://forms.gle/Cr7zengLT9qiWzd78  

As with the meeting last week, registration is still required even though there 
is no registration fee and may be done up to the time of the first voting block.

The logistics, agenda, and all of the other usual information is available on 
the website:

https://www.mpi-forum.org/meetings/  

Note that while the current meeting times start and end times are accurate, the 
times for individual items are placeholders (including the voting block) and 
are subject to the whims of our distinguished leader. :) You can probably start 
sending your reading/vote/plenary requests to him to start filling that out 
more accurately.

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: [RFC 1/3] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Wesley Cheng]

On 5/8/2020 5:45 AM, Felipe Balbi wrote:
> 
> Hi,
> 
> Wesley Cheng  writes:
>> Some devices have USB compositions which may require multiple endpoints
>> that support EP bursting.  HW defined TX FIFO sizes may not always be
>> sufficient for these compositions.  By utilizing flexible TX FIFO
>> allocation, this allows for endpoints to request the required FIFO depth to
>> achieve higher bandwidth.  With some higher bMaxBurst configurations, using
>> a larger TX FIFO size results in better TX throughput.
> 
> This needs to be carefully thought out as it can introduce situations
> where gadget drivers that worked previously stop working.
> 

Hi Felipe,

Thanks for the feedback.  I agree, the TX FIFO resizing logic should be
reviewed carefully to, in order not to cause any regressions.  Would you
be willing to shed some light on some of the failures you've seen
previously where the gadget drivers stopped working?  (would help
possibly come up with better approaches, etc...)

>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index 4c171a8..e815c13 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>> @@ -675,6 +675,7 @@ struct dwc3_event_buffer {
>>   *  isochronous START TRANSFER command failure workaround
>>   * @start_cmd_status: the status of testing START TRANSFER command with
>>   *  combo_num = 'b00
>> + * @fifo_depth: allocated TXFIFO depth
>>   */
>>  struct dwc3_ep {
>>  struct usb_ep   endpoint;
>> @@ -718,6 +719,7 @@ struct dwc3_ep {
>>  u8  resource_index;
>>  u32 frame_number;
>>  u32 interval;
>> +int fifo_depth;
>>  
>>  charname[20];
>>  
>> @@ -1004,6 +1006,7 @@ struct dwc3_scratchpad_array {
>>   *  1   - utmi_l1_suspend_n
>>   * @is_fpga: true when we are using the FPGA board
>>   * @pending_events: true when we have pending IRQs to be handled
>> + * @needs_fifo_resize: not all users might want fifo resizing, flag it
>>   * @pullups_connected: true when Run/Stop bit is set
>>   * @setup_packet_pending: true when there's a Setup Packet in FIFO. 
>> Workaround
>>   * @three_stage_setup: set if we perform a three phase setup
>> @@ -1044,6 +1047,7 @@ struct dwc3_scratchpad_array {
>>   * @dis_metastability_quirk: set to disable metastability quirk.
>>   * @imod_interval: set the interrupt moderation interval in 250ns
>>   * increments or 0 to disable.
>> + * @last_fifo_depth: total TXFIFO depth of all enabled USB IN/INT endpoints
>>   */
>>  struct dwc3 {
>>  struct work_struct  drd_work;
>> @@ -1204,6 +1208,7 @@ struct dwc3 {
>>  unsignedis_utmi_l1_suspend:1;
>>  unsignedis_fpga:1;
>>  unsignedpending_events:1;
>> +unsignedneeds_fifo_resize:1;
> 
> Instead of passing a flag, this could be detected in runtime during 
> ->udc_start()
> 

The flag was going to serve the purpose of allowing platforms to define
if they want to enable the TX FIFO resizing logic or not.  Maybe in
their particular HW platform, the HW default FIFO settings are sufficient.

>> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
>> index 6dee4da..7ee2302 100644
>> --- a/drivers/usb/dwc3/ep0.c
>> +++ b/drivers/usb/dwc3/ep0.c
>> @@ -611,6 +612,43 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
>> usb_ctrlrequest *ctrl)
>>  return -EINVAL;
>>  
>>  case USB_STATE_ADDRESS:
> 
> are you sure it's safe to fiddle with TX FIFO allocation at SetAddress()
> time?
> 

It should be acceptable, as the function drivers shouldn't be calling
usb_ep_enable() until we receive a SET_CONFIG from the host to enable
the configuration.  __dwc3_gadget_ep_enable() -->
dwc3_gadget_set_ep_config() is where we'd assign the EP to a particular
TX FIFO.

>> +/*
>> + * If tx-fifo-resize flag is not set for the controller, then
>> + * do not clear existing allocated TXFIFO since we do not
>> + * allocate it again in dwc3_gadget_resize_tx_fifos
>> + */
>> +if (dwc->needs_fifo_resize) {
>> +/* Read ep0IN related TXFIFO size */
>> +dep = dwc->eps[1];
>> +size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(0));
>> +if (dwc3_is_usb31(dwc))
>> +dep->fifo_depth

[cobirds] ???Prothonotary warbler location???

[Jace Wesley Brasher]

Hello, I am looking for more guidance and specifics on the location of the
prothonotary warbler at prospect ponds natural area in fort Collins? Any
info is helpful.
Thank you!

Jace Brasher
Loveland CO
Larimer county

-- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/CAP7yTyiz79rfmurg_dUvmUM8wC3rm7wAa3GP7%3D6HXtuquoPOJw%40mail.gmail.com.

[RFC 0/3] Re-introduce TX FIFO resize for larger EP bursting

[Wesley Cheng]

Currently, there is no functionality to allow for resizing the TXFIFOs, and
relying on the HW default setting for the TXFIFO depth.  In most cases, the
HW default is probably sufficient, but for USB compositions that contain
multiple functions that require EP bursting, the default settings
might not be enough.  Also to note, the current SW will assign an EP to a
function driver w/o checking to see if the TXFIFO size for that particular
EP is large enough. (this is a problem if there are multiple HW defined
values for the TXFIFO size)

It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3
is required for an EP that supports bursting.  Otherwise, there may be
frequent occurences of bursts ending.  For high bandwidth functions,
such as data tethering (protocols that support data aggregation), mass
storage, and media transfer protocol (over FFS), the bMaxBurst value can be
large, and a bigger TXFIFO depth may prove to be beneficial in terms of USB
throughput. (which can be associated to system access latency, etc...)  It
allows for a more consistent burst of traffic, w/o any interruptions, as
data is readily available in the FIFO.

With testing done using the mass storage function driver, the results show
that with a larger TXFIFO depth, the bandwidth increased significantly.

Test Parameters:
 - Platform: Qualcomm SM8150
 - bMaxBurst = 6
 - USB req size = 256kB
 - Num of USB reqs = 16
 - USB Speed = Super-Speed
 - Function Driver: Mass Storage (w/ ramdisk)
 - Test Application: CrystalDiskMark

Results:

TXFIFO Depth = 3 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 193.60
  |   | 195.86
  |   | 184.77
  |   | 193.60
---

TXFIFO Depth = 6 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 287.35
  |   | 304.94
  |   | 289.64
  |   | 293.61
---

Wesley Cheng (3):
  usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
  arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic
  dt-bindings: usb: dwc3: Add entry for tx-fifo-resize

 Documentation/devicetree/bindings/usb/dwc3.txt |  2 +-
 arch/arm64/boot/dts/qcom/sm8150.dtsi   |  1 +
 drivers/usb/dwc3/core.c|  2 +
 drivers/usb/dwc3/core.h|  6 ++
 drivers/usb/dwc3/ep0.c | 40 ++-
 drivers/usb/dwc3/gadget.c  | 95 ++
 6 files changed, 144 insertions(+), 2 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[RFC 2/3] arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic

[Wesley Cheng]

Enable the flexible TX FIFO resize logic on SM8150.  Using a larger TX FIFO
SZ can help account for situations when system latency is greater than the
USB bus transmission latency.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi 
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index a36512d..c285233 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -708,6 +708,7 @@
interrupts = ;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+   tx-fifo-resize;
phys = <_1_hsphy>, <_1_ssphy>;
phy-names = "usb2-phy", "usb3-phy";
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[RFC 1/3] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Wesley Cheng]

Some devices have USB compositions which may require multiple endpoints
that support EP bursting.  HW defined TX FIFO sizes may not always be
sufficient for these compositions.  By utilizing flexible TX FIFO
allocation, this allows for endpoints to request the required FIFO depth to
achieve higher bandwidth.  With some higher bMaxBurst configurations, using
a larger TX FIFO size results in better TX throughput.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/core.c   |  2 +
 drivers/usb/dwc3/core.h   |  6 +++
 drivers/usb/dwc3/ep0.c| 40 +++-
 drivers/usb/dwc3/gadget.c | 95 +++
 4 files changed, 142 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index edc1715..cca5554 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1304,6 +1304,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
_thr_num_pkt_prd);
device_property_read_u8(dev, "snps,tx-max-burst-prd",
_max_burst_prd);
+   dwc->needs_fifo_resize = device_property_read_bool(dev,
+   "tx-fifo-resize");
 
dwc->disable_scramble_quirk = device_property_read_bool(dev,
"snps,disable_scramble_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4c171a8..e815c13 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -675,6 +675,7 @@ struct dwc3_event_buffer {
  * isochronous START TRANSFER command failure workaround
  * @start_cmd_status: the status of testing START TRANSFER command with
  * combo_num = 'b00
+ * @fifo_depth: allocated TXFIFO depth
  */
 struct dwc3_ep {
struct usb_ep   endpoint;
@@ -718,6 +719,7 @@ struct dwc3_ep {
u8  resource_index;
u32 frame_number;
u32 interval;
+   int fifo_depth;
 
charname[20];
 
@@ -1004,6 +1006,7 @@ struct dwc3_scratchpad_array {
  * 1   - utmi_l1_suspend_n
  * @is_fpga: true when we are using the FPGA board
  * @pending_events: true when we have pending IRQs to be handled
+ * @needs_fifo_resize: not all users might want fifo resizing, flag it
  * @pullups_connected: true when Run/Stop bit is set
  * @setup_packet_pending: true when there's a Setup Packet in FIFO. Workaround
  * @three_stage_setup: set if we perform a three phase setup
@@ -1044,6 +1047,7 @@ struct dwc3_scratchpad_array {
  * @dis_metastability_quirk: set to disable metastability quirk.
  * @imod_interval: set the interrupt moderation interval in 250ns
  * increments or 0 to disable.
+ * @last_fifo_depth: total TXFIFO depth of all enabled USB IN/INT endpoints
  */
 struct dwc3 {
struct work_struct  drd_work;
@@ -1204,6 +1208,7 @@ struct dwc3 {
unsignedis_utmi_l1_suspend:1;
unsignedis_fpga:1;
unsignedpending_events:1;
+   unsignedneeds_fifo_resize:1;
unsignedpullups_connected:1;
unsignedsetup_packet_pending:1;
unsignedthree_stage_setup:1;
@@ -1236,6 +1241,7 @@ struct dwc3 {
unsigneddis_metastability_quirk:1;
 
u16 imod_interval;
+   int last_fifo_depth;
 };
 
 #define INCRX_BURST_MODE 0
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 6dee4da..7ee2302 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -601,8 +601,9 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
 {
enum usb_device_state state = dwc->gadget.state;
u32 cfg;
-   int ret;
+   int ret, num, size;
u32 reg;
+   struct dwc3_ep *dep;
 
cfg = le16_to_cpu(ctrl->wValue);
 
@@ -611,6 +612,43 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
return -EINVAL;
 
case USB_STATE_ADDRESS:
+   /*
+* If tx-fifo-resize flag is not set for the controller, then
+* do not clear existing allocated TXFIFO since we do not
+* allocate it again in dwc3_gadget_resize_tx_fifos
+*/
+   if (dwc->needs_fifo_resize) {
+   /* Read ep0IN related TXFIFO size */
+   dep = dwc->eps[1];
+   size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(0));
+   if (dwc3_is_usb31(dwc))
+   dep->fifo_depth = DWC31_GTXFIFOSIZ_TXFDEP(size);
+   else
+   dep->fifo_depth = DWC3_GTXFIFOSIZ_TXFDEP(size);
+
+

[RFC 3/3] dt-bindings: usb: dwc3: Add entry for tx-fifo-resize

[Wesley Cheng]

Re-introduce the comment for the tx-fifo-resize setting for the DWC3
controller.

Signed-off-by: Wesley Cheng 
---
 Documentation/devicetree/bindings/usb/dwc3.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 9946ff9..489f5da 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -105,7 +105,7 @@ Optional properties:
1-16 (DWC_usb31 programming guide section 1.2.3) to
enable periodic ESS TX threshold.
 
- -  tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
  - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
register, undefined length INCR burst type enable and 
INCRx type.
When just one value, which means INCRX burst mode 
enabled. When
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[Mpi-forum] Exceptional Virtual Meeting Vote Results

[Wesley Bland via mpi-forum]

Hi all,

The results of yesterday’s vote are now posted on the website:

https://www.mpi-forum.org/meetings/2020/05/votes 


The vote passed unanimously (27 yes, 0 no, 0 abstain). This means the ballot 
passed and I’ll update the procedures document based on these changes.

Thanks for responding and letting me know about any issues you had. I believe 
only one person had major issues with this voting system and I’ll work with 
them to figure out what happened. If anyone else had problems, please let me 
know so we can work them out before the June meeting.

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[PATCH] dt-bindings: phy: usb-snps-femto-v2: Add regulator entries to example

[Wesley Cheng]

Fix errors reported by dt_binding_check, due to missing required
regulators in the example node.

Fixes: f06b9fc9a814 ("dt-bindings: phy: Add binding for qcom,usb-snps-femto-v2")
Signed-off-by: Wesley Cheng 
Reported-by: Rob Herring 
---
 Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml 
b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
index 984242f..574f890 100644
--- a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
@@ -72,5 +72,9 @@ examples:
 clock-names = "ref";
 
 resets = < GCC_QUSB2PHY_PRIM_BCR>;
+
+vdda-pll-supply = <_usb_hs_core>;
+vdda33-supply = <_usb_hs_3p1>;
+vdda18-supply = <_usb_hs_1p8>;
 };
 ...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 2/5] phy: qcom-snps: Add SNPS USB PHY driver for QCOM based SOCs

[Wesley Cheng]

This adds the SNPS FemtoPHY V2 driver used in QCOM SOCs.  There
are potentially multiple instances of this UTMI PHY on the
SOC, all which can utilize this driver.  The V2 driver will
have a different register map compared to V1.

Signed-off-by: Wesley Cheng 
Reviewed-by: Philipp Zabel 
Reviewed-by: Manu Gautam 
Reviewed-by: Vinod Koul 
Reviewed-by: Stephen Boyd 
---
 drivers/phy/qualcomm/Kconfig  |  10 +
 drivers/phy/qualcomm/Makefile |   1 +
 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 287 ++
 3 files changed, 298 insertions(+)
 create mode 100644 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c

diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index b86f955..ca9ce7e 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -92,6 +92,16 @@ config PHY_QCOM_USB_HS
  Support for the USB high-speed ULPI compliant phy on Qualcomm
  chipsets.
 
+config PHY_QCOM_USB_SNPS_FEMTO_V2
+   tristate "Qualcomm SNPS FEMTO USB HS PHY V2 module"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable support for the USB high-speed SNPS Femto phy on Qualcomm
+ chipsets.  This PHY has differences in the register map compared
+ to the V1 variants.  The PHY is paired with a Synopsys DWC3 USB
+ controller on Qualcomm SOCs.
+
 config PHY_QCOM_USB_HSIC
tristate "Qualcomm USB HSIC ULPI PHY module"
depends on USB_ULPI_BUS
diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
index 4174678..86fb32e 100644
--- a/drivers/phy/qualcomm/Makefile
+++ b/drivers/phy/qualcomm/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_PHY_QCOM_USB_HS) += 
phy-qcom-usb-hs.o
 obj-$(CONFIG_PHY_QCOM_USB_HSIC)+= phy-qcom-usb-hsic.o
 obj-$(CONFIG_PHY_QCOM_USB_HS_28NM) += phy-qcom-usb-hs-28nm.o
 obj-$(CONFIG_PHY_QCOM_USB_SS)  += phy-qcom-usb-ss.o
+obj-$(CONFIG_PHY_QCOM_USB_SNPS_FEMTO_V2)+= phy-qcom-snps-femto-v2.o
diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c 
b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
new file mode 100644
index 000..4d74045
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
@@ -0,0 +1,287 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define USB2_PHY_USB_PHY_UTMI_CTRL0(0x3c)
+#define SLEEPM BIT(0)
+#define OPMODE_MASKGENMASK(4, 3)
+#define OPMODE_NORMAL  (0x00)
+#define OPMODE_NONDRIVING  BIT(3)
+#define TERMSELBIT(5)
+
+#define USB2_PHY_USB_PHY_UTMI_CTRL1(0x40)
+#define XCVRSELBIT(0)
+
+#define USB2_PHY_USB_PHY_UTMI_CTRL5(0x50)
+#define PORBIT(1)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON0   (0x54)
+#define RETENABLEN BIT(3)
+#define FSEL_MASK  GENMASK(7, 5)
+#define FSEL_DEFAULT   (0x3 << 4)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON1   (0x58)
+#define VBUSVLDEXTSEL0 BIT(4)
+#define PLLBTUNE   BIT(5)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON2   (0x5c)
+#define VREGBYPASS BIT(0)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL1  (0x60)
+#define VBUSVLDEXT0BIT(0)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL2  (0x64)
+#define USB2_AUTO_RESUME   BIT(0)
+#define USB2_SUSPEND_N BIT(2)
+#define USB2_SUSPEND_N_SEL BIT(3)
+
+#define USB2_PHY_USB_PHY_CFG0  (0x94)
+#define UTMI_PHY_DATAPATH_CTRL_OVERRIDE_EN BIT(0)
+#define UTMI_PHY_CMN_CTRL_OVERRIDE_EN  BIT(1)
+
+#define USB2_PHY_USB_PHY_REFCLK_CTRL   (0xa0)
+#define REFCLK_SEL_MASKGENMASK(1, 0)
+#define REFCLK_SEL_DEFAULT (0x2 << 0)
+
+static const char * const qcom_snps_hsphy_vreg_names[] = {
+   "vdda-pll", "vdda33", "vdda18",
+};
+
+#define SNPS_HS_NUM_VREGS  ARRAY_SIZE(qcom_snps_hsphy_vreg_names)
+
+/**
+ * struct qcom_snps_hsphy - snps hs phy attributes
+ *
+ * @phy: generic phy
+ * @base: iomapped memory space for snps hs phy
+ *
+ * @cfg_ahb_clk: AHB2PHY interface clock
+ * @ref_clk: phy reference clock
+ * @iface_clk: phy interface clock
+ * @phy_reset: phy reset control
+ * @vregs: regulator supplies bulk data
+ * @phy_initialized: if PHY has been initialized correctly
+ */
+struct

[PATCH v9 5/5] phy: qcom-qmp: Rename UFS PCS QMP v4 registers

[Wesley Cheng]

The UFS QMP v4 PHY has a largely different register set versus USB and
PCIe.  Rename the register offsets to denote that the value is specific for
the UFS PCS register.

Signed-off-by: Wesley Cheng 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 20 +--
 drivers/phy/qualcomm/phy-qcom-qmp.h | 40 ++---
 2 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index dec4a17..2d2d5ba 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -191,9 +191,9 @@ enum qphy_reg_layout {
 };
 
 static const unsigned int sm8150_ufsphy_regs_layout[] = {
-   [QPHY_START_CTRL]   = QPHY_V4_PHY_START,
-   [QPHY_PCS_READY_STATUS] = QPHY_V4_PCS_READY_STATUS,
-   [QPHY_SW_RESET] = QPHY_V4_SW_RESET,
+   [QPHY_START_CTRL]   = QPHY_V4_PCS_UFS_PHY_START,
+   [QPHY_PCS_READY_STATUS] = QPHY_V4_PCS_UFS_READY_STATUS,
+   [QPHY_SW_RESET] = QPHY_V4_PCS_UFS_SW_RESET,
 };
 
 static const struct qmp_phy_init_tbl msm8996_pcie_serdes_tbl[] = {
@@ -1280,13 +1280,13 @@ enum qphy_reg_layout {
 };
 
 static const struct qmp_phy_init_tbl sm8150_ufsphy_pcs_tbl[] = {
-   QMP_PHY_INIT_CFG(QPHY_V4_RX_SIGDET_CTRL2, 0x6d),
-   QMP_PHY_INIT_CFG(QPHY_V4_TX_LARGE_AMP_DRV_LVL, 0x0a),
-   QMP_PHY_INIT_CFG(QPHY_V4_TX_SMALL_AMP_DRV_LVL, 0x02),
-   QMP_PHY_INIT_CFG(QPHY_V4_TX_MID_TERM_CTRL1, 0x43),
-   QMP_PHY_INIT_CFG(QPHY_V4_DEBUG_BUS_CLKSEL, 0x1f),
-   QMP_PHY_INIT_CFG(QPHY_V4_RX_MIN_HIBERN8_TIME, 0xff),
-   QMP_PHY_INIT_CFG(QPHY_V4_MULTI_LANE_CTRL1, 0x02),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_RX_SIGDET_CTRL2, 0x6d),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_TX_LARGE_AMP_DRV_LVL, 0x0a),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_TX_SMALL_AMP_DRV_LVL, 0x02),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_TX_MID_TERM_CTRL1, 0x43),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_DEBUG_BUS_CLKSEL, 0x1f),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_RX_MIN_HIBERN8_TIME, 0xff),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_MULTI_LANE_CTRL1, 0x02),
 };
 
 static const struct qmp_phy_init_tbl sm8150_usb3_serdes_tbl[] = {
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.h 
b/drivers/phy/qualcomm/phy-qcom-qmp.h
index c8c06b82..6d017a0 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.h
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.h
@@ -425,26 +425,26 @@
 #define QSERDES_V4_RX_VTH_CODE 0x1c4
 
 /* Only for QMP V4 PHY - UFS PCS registers */
-#define QPHY_V4_PHY_START  0x000
-#define QPHY_V4_POWER_DOWN_CONTROL 0x004
-#define QPHY_V4_SW_RESET   0x008
-#define QPHY_V4_TIMER_20US_CORECLK_STEPS_MSB   0x00c
-#define QPHY_V4_TIMER_20US_CORECLK_STEPS_LSB   0x010
-#define QPHY_V4_PLL_CNTL   0x02c
-#define QPHY_V4_TX_LARGE_AMP_DRV_LVL   0x030
-#define QPHY_V4_TX_SMALL_AMP_DRV_LVL   0x038
-#define QPHY_V4_BIST_FIXED_PAT_CTRL0x060
-#define QPHY_V4_TX_HSGEAR_CAPABILITY   0x074
-#define QPHY_V4_RX_HSGEAR_CAPABILITY   0x0b4
-#define QPHY_V4_DEBUG_BUS_CLKSEL   0x124
-#define QPHY_V4_LINECFG_DISABLE0x148
-#define QPHY_V4_RX_MIN_HIBERN8_TIME0x150
-#define QPHY_V4_RX_SIGDET_CTRL20x158
-#define QPHY_V4_TX_PWM_GEAR_BAND   0x160
-#define QPHY_V4_TX_HS_GEAR_BAND0x168
-#define QPHY_V4_PCS_READY_STATUS   0x180
-#define QPHY_V4_TX_MID_TERM_CTRL1  0x1d8
-#define QPHY_V4_MULTI_LANE_CTRL1   0x1e0
+#define QPHY_V4_PCS_UFS_PHY_START  0x000
+#define QPHY_V4_PCS_UFS_POWER_DOWN_CONTROL 0x004
+#define QPHY_V4_PCS_UFS_SW_RESET   0x008
+#define QPHY_V4_PCS_UFS_TIMER_20US_CORECLK_STEPS_MSB   0x00c
+#define QPHY_V4_PCS_UFS_TIMER_20US_CORECLK_STEPS_LSB   0x010
+#define QPHY_V4_PCS_UFS_PLL_CNTL   0x02c
+#define QPHY_V4_PCS_UFS_TX_LARGE_AMP_DRV_LVL   0x030
+#define QPHY_V4_PCS_UFS_TX_SMALL_AMP_DRV_LVL   0x038
+#define QPHY_V4_PCS_UFS_BIST_FIXED_PAT_CTRL0x060
+#define QPHY_V4_PCS_UFS_TX_HSGEAR_CAPABILITY   0x074
+#define QPHY_V4_PCS_UFS_RX_HSGEAR_CAPABILITY   0x0b4
+#define QPHY_V4_PCS_UFS_DEBUG_BUS_CLKSEL   0x124
+#define QPHY_V4_PCS_UFS_LINECFG_DISABLE0x148
+#define QPHY_V4_PCS_UFS_RX_MIN_HIBERN8_TIME0x150
+#define QPHY_V4_PCS_UFS_RX_SIGDET_CTRL20x158
+#define QPHY_V4_PCS_UFS_TX_PWM_GEAR_BAND   0x160

[PATCH v9 4/5] phy: qcom-qmp: Use proper PWRDOWN offset for sm8150 USB

[Wesley Cheng]

The register map for SM8150 QMP USB SSPHY has moved
QPHY_POWER_DOWN_CONTROL to a different offset.  Allow for
an offset in the register table to override default value
if it is a DP capable PHY.

Signed-off-by: Wesley Cheng 
Reviewed-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index d62bd09..dec4a17 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -119,6 +119,7 @@ enum qphy_reg_layout {
QPHY_PCS_AUTONOMOUS_MODE_CTRL,
QPHY_PCS_LFPS_RXTERM_IRQ_CLEAR,
QPHY_PCS_LFPS_RXTERM_IRQ_STATUS,
+   QPHY_PCS_POWER_DOWN_CONTROL,
 };
 
 static const unsigned int msm8996_ufsphy_regs_layout[] = {
@@ -181,6 +182,7 @@ enum qphy_reg_layout {
[QPHY_SW_RESET] = 0x00,
[QPHY_START_CTRL]   = 0x44,
[QPHY_PCS_STATUS]   = 0x14,
+   [QPHY_PCS_POWER_DOWN_CONTROL]   = 0x40,
 };
 
 static const unsigned int sdm845_ufsphy_regs_layout[] = {
@@ -2030,11 +2032,18 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
 SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
}
 
-   if (cfg->has_phy_com_ctrl)
+   if (cfg->has_phy_com_ctrl) {
qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
 SW_PWRDN);
-   else
-   qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
+   } else {
+   if (cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL])
+   qphy_setbits(pcs,
+   cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL],
+   cfg->pwrdn_ctrl);
+   else
+   qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL,
+   cfg->pwrdn_ctrl);
+   }
 
/* Serdes configuration */
qcom_qmp_phy_configure(serdes, cfg->regs, cfg->serdes_tbl,
@@ -2260,7 +2269,13 @@ static int qcom_qmp_phy_disable(struct phy *phy)
qphy_clrbits(qphy->pcs, cfg->regs[QPHY_START_CTRL], cfg->start_ctrl);
 
/* Put PHY into POWER DOWN state: active low */
-   qphy_clrbits(qphy->pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
+   if (cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL]) {
+   qphy_clrbits(qphy->pcs, cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL],
+cfg->pwrdn_ctrl);
+   } else {
+   qphy_clrbits(qphy->pcs, QPHY_POWER_DOWN_CONTROL,
+   cfg->pwrdn_ctrl);
+   }
 
if (cfg->has_lane_rst)
reset_control_assert(qphy->lane_rst);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 3/5] phy: qcom-qmp: Add SM8150 QMP USB3 PHY support

[Wesley Cheng]

From: Jack Pham 

Add support for SM8150 QMP USB3 PHY with the necessary
initialization sequences as well as additional QMP V4
register definitions.

Signed-off-by: Jack Pham 
Signed-off-by: Wesley Cheng 
Reviewed-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 153 
 drivers/phy/qualcomm/phy-qcom-qmp.h | 198 +++-
 2 files changed, 349 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 50cbcdc..d62bd09 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -177,6 +177,12 @@ enum qphy_reg_layout {
[QPHY_PCS_STATUS]   = 0x2ac,
 };
 
+static const unsigned int qmp_v4_usb3phy_regs_layout[] = {
+   [QPHY_SW_RESET] = 0x00,
+   [QPHY_START_CTRL]   = 0x44,
+   [QPHY_PCS_STATUS]   = 0x14,
+};
+
 static const unsigned int sdm845_ufsphy_regs_layout[] = {
[QPHY_START_CTRL]   = 0x00,
[QPHY_PCS_READY_STATUS] = 0x160,
@@ -1281,6 +1287,115 @@ enum qphy_reg_layout {
QMP_PHY_INIT_CFG(QPHY_V4_MULTI_LANE_CTRL1, 0x02),
 };
 
+static const struct qmp_phy_init_tbl sm8150_usb3_serdes_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_EN_CENTER, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_PER1, 0x31),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_PER2, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_STEP_SIZE1_MODE0, 0xde),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_STEP_SIZE2_MODE0, 0x07),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_STEP_SIZE1_MODE1, 0xde),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_STEP_SIZE2_MODE1, 0x07),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_BUF_ENABLE, 0x0a),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_CMN_IPTRIM, 0x20),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_CP_CTRL_MODE0, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_CP_CTRL_MODE1, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_RCTRL_MODE0, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_RCTRL_MODE1, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_CCTRL_MODE0, 0x36),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_CCTRL_MODE1, 0x36),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_EN_SEL, 0x1a),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP_EN, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE0, 0x14),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE0, 0x34),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE1, 0x34),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE1, 0x82),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE0, 0x82),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE1, 0x82),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START1_MODE0, 0xab),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE0, 0xea),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE0, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_MAP, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START1_MODE1, 0xab),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE1, 0xea),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE1, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE1_MODE0, 0x24),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE1_MODE1, 0x24),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE2_MODE1, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_CORECLK_DIV_MODE1, 0x08),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0xca),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x1e),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE1, 0xca),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE1, 0x1e),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_HSCLK_SEL, 0x11),
+};
+
+static const struct qmp_phy_init_tbl sm8150_usb3_tx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V4_TX_RES_CODE_LANE_TX, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V4_TX_RES_CODE_LANE_RX, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V4_TX_LANE_MODE_1, 0xd5),
+   QMP_PHY_INIT_CFG(QSERDES_V4_TX_RCV_DETECT_LVL_2, 0x12),
+   QMP_PHY_INIT_CFG(QSERDES_V4_TX_PI_QEC_CTRL, 0x20),
+};
+
+static const struct qmp_phy_init_tbl sm8150_usb3_rx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_GAIN, 0x05),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FASTLOCK_FO_GAIN, 0x2f),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x7f),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FASTLOCK_COUNT_LOW, 0xff),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FASTLOCK_COUNT_HIGH, 0x0f),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_PI_CONTROLS, 0x99),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SB2_THRESH1, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SB2_THRESH2, 0x08),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SB2_GAIN1, 0x05),
+   QMP_PHY_INIT_CFG

[PATCH v9 1/5] dt-bindings: phy: Add binding for qcom,usb-snps-femto-v2

[Wesley Cheng]

This binding shows the descriptions and properties for the
Synopsis Femto USB PHY V2 used on QCOM platforms.

Signed-off-by: Wesley Cheng 
Reviewed-by: Rob Herring 
Reviewed-by: Stephen Boyd 
---
 .../bindings/phy/qcom,usb-snps-femto-v2.yaml   | 80 ++
 1 file changed, 80 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml

diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml 
b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
new file mode 100644
index 000..574f890
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/qcom,usb-snps-femto-v2.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Qualcomm Synopsys Femto High-Speed USB PHY V2
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  Qualcomm High-Speed USB PHY
+
+properties:
+  compatible:
+enum:
+  - qcom,usb-snps-hs-7nm-phy
+  - qcom,sm8150-usb-hs-phy
+  - qcom,usb-snps-femto-v2-phy
+
+  reg:
+maxItems: 1
+
+  "#phy-cells":
+const: 0
+
+  clocks:
+items:
+  - description: rpmhcc ref clock
+
+  clock-names:
+items:
+  - const: ref
+
+  resets:
+items:
+  - description: PHY core reset
+
+  vdda-pll-supply:
+description: phandle to the regulator VDD supply node.
+
+  vdda18-supply:
+description: phandle to the regulator 1.8V supply node.
+
+  vdda33-supply:
+description: phandle to the regulator 3.3V supply node.
+
+required:
+  - compatible
+  - reg
+  - "#phy-cells"
+  - clocks
+  - clock-names
+  - resets
+  - vdda-pll-supply
+  - vdda18-supply
+  - vdda33-supply
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+phy@88e2000 {
+compatible = "qcom,sm8150-usb-hs-phy";
+reg = <0 0x088e2000 0 0x400>;
+#phy-cells = <0>;
+
+clocks = < RPMH_CXO_CLK>;
+clock-names = "ref";
+
+resets = < GCC_QUSB2PHY_PRIM_BCR>;
+
+vdda-pll-supply = <_usb_hs_core>;
+vdda33-supply = <_usb_hs_3p1>;
+vdda18-supply = <_usb_hs_1p8>;
+};
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v9 0/5] Add SS/HS-USB changes for Qualcomm SM8150 chipset

[Wesley Cheng]

This series adds support for the Synopsis 7nm HSPHY USB driver being
used in QCOM chipsets.  The HSPHY register map differs compared to 
other PHY revisions.  In addition, modifications and updates are done
to the QMP driver to add new registers/offsets, and to update the
initialization sequence for enabling the SSUSB path on SM8150.

Changes in v9:
 - Fixed missing required regulators in DT bindings file

Reviewed-by: Rob Herring 

Changes in v8:
 - Fix checkpatch warnings about characters per line.
 - Rebase to linux-phy/next branch

Reviewed-by: Vinod Koul 

Changes in v7:
 - Use _relaxed() variants for writel/readl calls in
   phy-qcom-snps-femto-v2.c
 - Remove comments in the phy init function
 - Use devm_platform_ioremap_resource instead of devm_ioremap_resource
 - Fix chipset naming in Kconfig
 - Address minor fixups in the YAML file (remove status in example, fix
   "Hi-speed" to "High-speed", add a newline at the end)

Changes in v6:
 - Addressed coding style errors in phy-qcom-snps-femto-v2.c

Changes in v5:
 - Reorganize IF check for when to use the proper PWRDOWN CTRL offset
 - Rename UFS specific offset definitions in the QMP PHY driver to clearly
   denote they are UFS specific
 - Rename the phy-qcom-snps-7nm driver to phy-qcom-snps-femto-v2

Changes in v4:
 - Fix POWERDOWN offset for QMP PHY exit routine, and check for
   has_phy_dp_com_ctrl instead of !has_phy_com_ctrl

Changes in v3:
 - Use devm_reset_control_get_exclusive instead of referencing index for
   reset handle

Changes in v2:
 - Fixed YAML errors caught by dt_binding_check

Jack Pham (1):
  phy: qcom-qmp: Add SM8150 QMP USB3 PHY support

Wesley Cheng (4):
  dt-bindings: phy: Add binding for qcom,usb-snps-femto-v2
  phy: qcom-snps: Add SNPS USB PHY driver for QCOM based SOCs
  phy: qcom-qmp: Use proper PWRDOWN offset for sm8150 USB
  phy: qcom-qmp: Rename UFS PCS QMP v4 registers

 .../bindings/phy/qcom,usb-snps-femto-v2.yaml   |  80 ++
 drivers/phy/qualcomm/Kconfig   |  10 +
 drivers/phy/qualcomm/Makefile  |   1 +
 drivers/phy/qualcomm/phy-qcom-qmp.c| 196 +-
 drivers/phy/qualcomm/phy-qcom-qmp.h| 238 +++--
 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c  | 287 +
 6 files changed, 776 insertions(+), 36 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
 create mode 100644 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v8 1/5] dt-bindings: phy: Add binding for qcom,usb-snps-femto-v2

[Wesley Cheng]

On 5/5/2020 6:34 AM, Rob Herring wrote:
> On Mon,  4 May 2020 16:54:23 -0700, Wesley Cheng wrote:
>> This binding shows the descriptions and properties for the
>> Synopsis Femto USB PHY V2 used on QCOM platforms.
>>
>> Signed-off-by: Wesley Cheng 
>> Reviewed-by: Rob Herring 
>> Reviewed-by: Stephen Boyd 
>> ---
>>  .../bindings/phy/qcom,usb-snps-femto-v2.yaml   | 77 
>> ++
>>  1 file changed, 77 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
>>
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.example.dt.yaml:
>  phy@88e2000: 'vdda-pll-supply' is a required property
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.example.dt.yaml:
>  phy@88e2000: 'vdda18-supply' is a required property
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.example.dt.yaml:
>  phy@88e2000: 'vdda33-supply' is a required property
> 
> See https://patchwork.ozlabs.org/patch/1283143
> 
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure dt-schema is up to date:
> 
> pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
> --upgrade
> 
> Please check and re-submit.
> 

Hi Rob,

I updated the dt-schema version, and I can see the same error.  Will fix
and resubmit.  I also realized that the dt_binding_check doesn't stop if
errors are detected in the example DT checking phase, and that was
probably why I missed this initially.  I'll pass the DT_SCHEMA_FILES
argument to my specific binding next time to help verify my file.
Thanks again!

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [Mpi-forum] May 6 Exceptional Virtual Meeting Registration

[Wesley Bland via mpi-forum]

Hi all,

In case you missed or didn’t read this email before, I just want to remind 
everyone that we have a VOTING meeting tomorrow (May 6) at 10am Central US 
time. Registration ahead of time is REQUIRED in order to be able to vote. 
Information on the meeting can be found in the usual place for our voting 
meetings:

https://www.mpi-forum.org/meetings/ <https://www.mpi-forum.org/meetings/> 

Thanks,
Wes

> On Apr 22, 2020, at 1:48 PM, Wesley Bland  wrote:
> 
> *** ACTION ITEMS ***
> 
> 1. Register for the May 6 Exceptional Virtual Meeting
> 2. Read the procedure changes proposal to enable virtual meetings
> 3. Attend the May 6 Exceptional Virtual Meeting and vote on the proposed 
> changes
> 
> ***
> 
> Hi folks,
> 
> As we’ve been discussing for the last few weeks, the MPI Forum will need to 
> adapt to the current global situation. Specifically, because most of us are 
> unable to travel, we will need to hold at least our planned June meeting and 
> possibly future meetings as virtual meetings rather than physical meetings.
> 
> To that end, I’ve drafted new rules to support this change, and we’ve all 
> been discussing them during the recent virtual meeting time slots. After our 
> meeting earlier today, I think we’ve reached agreement on how these rules 
> should look and they are ready to be put up for a vote. You can find the 
> proposed rule changes on the pull request here:
> 
> https://github.com/mpi-forum/procedures/pull/5 
> <https://github.com/mpi-forum/procedures/pull/5>
> 
> If you get a 404 error trying to view that page, it’s either because you’re 
> not logged into GitHub or because you don’t have access to the repository. 
> You can email me directly to get access.
> 
> To vote in these new rules, because we don’t have any existing rules to do 
> so, we’ll use the new rules themselves. To that end, we will hold our first 
> Exceptional Virtual MPI Forum Meeting in two weeks, on May 6, 2020. The 
> meeting will happen in our usual virtual meeting time slot (10 AM US Central 
> time). You can find all of the information in the usual place for a voting 
> meeting (used to be called physical):
> 
> https://www.mpi-forum.org/meetings/ <https://www.mpi-forum.org/meetings/> 
> 
> During that meeting, I will officially read the proposed changes to the 
> procedures. After that, I’ll open up the voting system for everyone who 
> attends. In order to run this meeting as close to our existing rules as 
> possible and enable us to calculate quorum, everyone will need to register 
> (for free) for the meeting before the meeting time at the following link:
> 
> https://forms.gle/jJxi5ztuoYg6xGSk8 <https://forms.gle/jJxi5ztuoYg6xGSk8> 
> 
> Note that if you do not register, I will not email you the link to vote. 
> Also, this meeting will use the same rules for quorum as any other MPI Forum 
> meeting so it is important that each organization register at least one 
> person. Because we are calling this meeting on relatively short notice, I 
> plan to leave the voting site running for 24 hours to give people who can not 
> attend the ability to vote at a time that is more convenient for them. If you 
> can not attend the call during the usual time slot, please make sure you read 
> the proposal carefully and/or watch the recording of today’s call (posted on 
> the virtual meeting website tomorrow) to hear the unofficial reading.
> 
> Please let me know if you have any questions.
> 
> Thanks,
> Wes

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[PATCH v8 0/5] Add SS/HS-USB changes for Qualcomm SM8150 chipset

[Wesley Cheng]

This series adds support for the Synopsis 7nm HSPHY USB driver being
used in QCOM chipsets.  The HSPHY register map differs compared to 
other PHY revisions.  In addition, modifications and updates are done
to the QMP driver to add new registers/offsets, and to update the
initialization sequence for enabling the SSUSB path on SM8150.

Changes in v8:
 - Fix checkpatch warnings about characters per line.
 - Rebase to linux-phy/next branch

Reviewed-by: Vinod Koul 

Changes in v7:
 - Use _relaxed() variants for writel/readl calls in
   phy-qcom-snps-femto-v2.c
 - Remove comments in the phy init function
 - Use devm_platform_ioremap_resource instead of devm_ioremap_resource
 - Fix chipset naming in Kconfig
 - Address minor fixups in the YAML file (remove status in example, fix
   "Hi-speed" to "High-speed", add a newline at the end)

Changes in v6:
 - Addressed coding style errors in phy-qcom-snps-femto-v2.c

Changes in v5:
 - Reorganize IF check for when to use the proper PWRDOWN CTRL offset
 - Rename UFS specific offset definitions in the QMP PHY driver to clearly
   denote they are UFS specific
 - Rename the phy-qcom-snps-7nm driver to phy-qcom-snps-femto-v2

Changes in v4:
 - Fix POWERDOWN offset for QMP PHY exit routine, and check for
   has_phy_dp_com_ctrl instead of !has_phy_com_ctrl

Changes in v3:
 - Use devm_reset_control_get_exclusive instead of referencing index for
   reset handle

Changes in v2:
 - Fixed YAML errors caught by dt_binding_check

Jack Pham (1):
  phy: qcom-qmp: Add SM8150 QMP USB3 PHY support

Wesley Cheng (4):
  dt-bindings: phy: Add binding for qcom,usb-snps-femto-v2
  phy: qcom-snps: Add SNPS USB PHY driver for QCOM based SOCs
  phy: qcom-qmp: Use proper PWRDOWN offset for sm8150 USB
  phy: qcom-qmp: Rename UFS PCS QMP v4 registers

 .../bindings/phy/qcom,usb-snps-femto-v2.yaml   |  77 ++
 drivers/phy/qualcomm/Kconfig   |  10 +
 drivers/phy/qualcomm/Makefile  |   1 +
 drivers/phy/qualcomm/phy-qcom-qmp.c| 196 +-
 drivers/phy/qualcomm/phy-qcom-qmp.h| 238 +++--
 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c  | 287 +
 6 files changed, 773 insertions(+), 36 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
 create mode 100644 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v8 4/5] phy: qcom-qmp: Use proper PWRDOWN offset for sm8150 USB

[Wesley Cheng]

The register map for SM8150 QMP USB SSPHY has moved
QPHY_POWER_DOWN_CONTROL to a different offset.  Allow for
an offset in the register table to override default value
if it is a DP capable PHY.

Signed-off-by: Wesley Cheng 
Reviewed-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index d62bd09..dec4a17 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -119,6 +119,7 @@ enum qphy_reg_layout {
QPHY_PCS_AUTONOMOUS_MODE_CTRL,
QPHY_PCS_LFPS_RXTERM_IRQ_CLEAR,
QPHY_PCS_LFPS_RXTERM_IRQ_STATUS,
+   QPHY_PCS_POWER_DOWN_CONTROL,
 };
 
 static const unsigned int msm8996_ufsphy_regs_layout[] = {
@@ -181,6 +182,7 @@ enum qphy_reg_layout {
[QPHY_SW_RESET] = 0x00,
[QPHY_START_CTRL]   = 0x44,
[QPHY_PCS_STATUS]   = 0x14,
+   [QPHY_PCS_POWER_DOWN_CONTROL]   = 0x40,
 };
 
 static const unsigned int sdm845_ufsphy_regs_layout[] = {
@@ -2030,11 +2032,18 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
 SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
}
 
-   if (cfg->has_phy_com_ctrl)
+   if (cfg->has_phy_com_ctrl) {
qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
 SW_PWRDN);
-   else
-   qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
+   } else {
+   if (cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL])
+   qphy_setbits(pcs,
+   cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL],
+   cfg->pwrdn_ctrl);
+   else
+   qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL,
+   cfg->pwrdn_ctrl);
+   }
 
/* Serdes configuration */
qcom_qmp_phy_configure(serdes, cfg->regs, cfg->serdes_tbl,
@@ -2260,7 +2269,13 @@ static int qcom_qmp_phy_disable(struct phy *phy)
qphy_clrbits(qphy->pcs, cfg->regs[QPHY_START_CTRL], cfg->start_ctrl);
 
/* Put PHY into POWER DOWN state: active low */
-   qphy_clrbits(qphy->pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
+   if (cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL]) {
+   qphy_clrbits(qphy->pcs, cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL],
+cfg->pwrdn_ctrl);
+   } else {
+   qphy_clrbits(qphy->pcs, QPHY_POWER_DOWN_CONTROL,
+   cfg->pwrdn_ctrl);
+   }
 
if (cfg->has_lane_rst)
reset_control_assert(qphy->lane_rst);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v8 2/5] phy: qcom-snps: Add SNPS USB PHY driver for QCOM based SOCs

[Wesley Cheng]

This adds the SNPS FemtoPHY V2 driver used in QCOM SOCs.  There
are potentially multiple instances of this UTMI PHY on the
SOC, all which can utilize this driver.  The V2 driver will
have a different register map compared to V1.

Signed-off-by: Wesley Cheng 
Reviewed-by: Philipp Zabel 
Reviewed-by: Manu Gautam 
Reviewed-by: Vinod Koul 
Reviewed-by: Stephen Boyd 
---
 drivers/phy/qualcomm/Kconfig  |  10 +
 drivers/phy/qualcomm/Makefile |   1 +
 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 287 ++
 3 files changed, 298 insertions(+)
 create mode 100644 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c

diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index b86f955..ca9ce7e 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -92,6 +92,16 @@ config PHY_QCOM_USB_HS
  Support for the USB high-speed ULPI compliant phy on Qualcomm
  chipsets.
 
+config PHY_QCOM_USB_SNPS_FEMTO_V2
+   tristate "Qualcomm SNPS FEMTO USB HS PHY V2 module"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable support for the USB high-speed SNPS Femto phy on Qualcomm
+ chipsets.  This PHY has differences in the register map compared
+ to the V1 variants.  The PHY is paired with a Synopsys DWC3 USB
+ controller on Qualcomm SOCs.
+
 config PHY_QCOM_USB_HSIC
tristate "Qualcomm USB HSIC ULPI PHY module"
depends on USB_ULPI_BUS
diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
index 4174678..86fb32e 100644
--- a/drivers/phy/qualcomm/Makefile
+++ b/drivers/phy/qualcomm/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_PHY_QCOM_USB_HS) += 
phy-qcom-usb-hs.o
 obj-$(CONFIG_PHY_QCOM_USB_HSIC)+= phy-qcom-usb-hsic.o
 obj-$(CONFIG_PHY_QCOM_USB_HS_28NM) += phy-qcom-usb-hs-28nm.o
 obj-$(CONFIG_PHY_QCOM_USB_SS)  += phy-qcom-usb-ss.o
+obj-$(CONFIG_PHY_QCOM_USB_SNPS_FEMTO_V2)+= phy-qcom-snps-femto-v2.o
diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c 
b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
new file mode 100644
index 000..4d74045
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
@@ -0,0 +1,287 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define USB2_PHY_USB_PHY_UTMI_CTRL0(0x3c)
+#define SLEEPM BIT(0)
+#define OPMODE_MASKGENMASK(4, 3)
+#define OPMODE_NORMAL  (0x00)
+#define OPMODE_NONDRIVING  BIT(3)
+#define TERMSELBIT(5)
+
+#define USB2_PHY_USB_PHY_UTMI_CTRL1(0x40)
+#define XCVRSELBIT(0)
+
+#define USB2_PHY_USB_PHY_UTMI_CTRL5(0x50)
+#define PORBIT(1)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON0   (0x54)
+#define RETENABLEN BIT(3)
+#define FSEL_MASK  GENMASK(7, 5)
+#define FSEL_DEFAULT   (0x3 << 4)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON1   (0x58)
+#define VBUSVLDEXTSEL0 BIT(4)
+#define PLLBTUNE   BIT(5)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON2   (0x5c)
+#define VREGBYPASS BIT(0)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL1  (0x60)
+#define VBUSVLDEXT0BIT(0)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL2  (0x64)
+#define USB2_AUTO_RESUME   BIT(0)
+#define USB2_SUSPEND_N BIT(2)
+#define USB2_SUSPEND_N_SEL BIT(3)
+
+#define USB2_PHY_USB_PHY_CFG0  (0x94)
+#define UTMI_PHY_DATAPATH_CTRL_OVERRIDE_EN BIT(0)
+#define UTMI_PHY_CMN_CTRL_OVERRIDE_EN  BIT(1)
+
+#define USB2_PHY_USB_PHY_REFCLK_CTRL   (0xa0)
+#define REFCLK_SEL_MASKGENMASK(1, 0)
+#define REFCLK_SEL_DEFAULT (0x2 << 0)
+
+static const char * const qcom_snps_hsphy_vreg_names[] = {
+   "vdda-pll", "vdda33", "vdda18",
+};
+
+#define SNPS_HS_NUM_VREGS  ARRAY_SIZE(qcom_snps_hsphy_vreg_names)
+
+/**
+ * struct qcom_snps_hsphy - snps hs phy attributes
+ *
+ * @phy: generic phy
+ * @base: iomapped memory space for snps hs phy
+ *
+ * @cfg_ahb_clk: AHB2PHY interface clock
+ * @ref_clk: phy reference clock
+ * @iface_clk: phy interface clock
+ * @phy_reset: phy reset control
+ * @vregs: regulator supplies bulk data
+ * @phy_initialized: if PHY has been initialized correctly
+ */
+struct

[PATCH v8 5/5] phy: qcom-qmp: Rename UFS PCS QMP v4 registers

[Wesley Cheng]

The UFS QMP v4 PHY has a largely different register set versus USB and
PCIe.  Rename the register offsets to denote that the value is specific for
the UFS PCS register.

Signed-off-by: Wesley Cheng 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 20 +--
 drivers/phy/qualcomm/phy-qcom-qmp.h | 40 ++---
 2 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index dec4a17..2d2d5ba 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -191,9 +191,9 @@ enum qphy_reg_layout {
 };
 
 static const unsigned int sm8150_ufsphy_regs_layout[] = {
-   [QPHY_START_CTRL]   = QPHY_V4_PHY_START,
-   [QPHY_PCS_READY_STATUS] = QPHY_V4_PCS_READY_STATUS,
-   [QPHY_SW_RESET] = QPHY_V4_SW_RESET,
+   [QPHY_START_CTRL]   = QPHY_V4_PCS_UFS_PHY_START,
+   [QPHY_PCS_READY_STATUS] = QPHY_V4_PCS_UFS_READY_STATUS,
+   [QPHY_SW_RESET] = QPHY_V4_PCS_UFS_SW_RESET,
 };
 
 static const struct qmp_phy_init_tbl msm8996_pcie_serdes_tbl[] = {
@@ -1280,13 +1280,13 @@ enum qphy_reg_layout {
 };
 
 static const struct qmp_phy_init_tbl sm8150_ufsphy_pcs_tbl[] = {
-   QMP_PHY_INIT_CFG(QPHY_V4_RX_SIGDET_CTRL2, 0x6d),
-   QMP_PHY_INIT_CFG(QPHY_V4_TX_LARGE_AMP_DRV_LVL, 0x0a),
-   QMP_PHY_INIT_CFG(QPHY_V4_TX_SMALL_AMP_DRV_LVL, 0x02),
-   QMP_PHY_INIT_CFG(QPHY_V4_TX_MID_TERM_CTRL1, 0x43),
-   QMP_PHY_INIT_CFG(QPHY_V4_DEBUG_BUS_CLKSEL, 0x1f),
-   QMP_PHY_INIT_CFG(QPHY_V4_RX_MIN_HIBERN8_TIME, 0xff),
-   QMP_PHY_INIT_CFG(QPHY_V4_MULTI_LANE_CTRL1, 0x02),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_RX_SIGDET_CTRL2, 0x6d),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_TX_LARGE_AMP_DRV_LVL, 0x0a),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_TX_SMALL_AMP_DRV_LVL, 0x02),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_TX_MID_TERM_CTRL1, 0x43),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_DEBUG_BUS_CLKSEL, 0x1f),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_RX_MIN_HIBERN8_TIME, 0xff),
+   QMP_PHY_INIT_CFG(QPHY_V4_PCS_UFS_MULTI_LANE_CTRL1, 0x02),
 };
 
 static const struct qmp_phy_init_tbl sm8150_usb3_serdes_tbl[] = {
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.h 
b/drivers/phy/qualcomm/phy-qcom-qmp.h
index c8c06b82..6d017a0 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.h
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.h
@@ -425,26 +425,26 @@
 #define QSERDES_V4_RX_VTH_CODE 0x1c4
 
 /* Only for QMP V4 PHY - UFS PCS registers */
-#define QPHY_V4_PHY_START  0x000
-#define QPHY_V4_POWER_DOWN_CONTROL 0x004
-#define QPHY_V4_SW_RESET   0x008
-#define QPHY_V4_TIMER_20US_CORECLK_STEPS_MSB   0x00c
-#define QPHY_V4_TIMER_20US_CORECLK_STEPS_LSB   0x010
-#define QPHY_V4_PLL_CNTL   0x02c
-#define QPHY_V4_TX_LARGE_AMP_DRV_LVL   0x030
-#define QPHY_V4_TX_SMALL_AMP_DRV_LVL   0x038
-#define QPHY_V4_BIST_FIXED_PAT_CTRL0x060
-#define QPHY_V4_TX_HSGEAR_CAPABILITY   0x074
-#define QPHY_V4_RX_HSGEAR_CAPABILITY   0x0b4
-#define QPHY_V4_DEBUG_BUS_CLKSEL   0x124
-#define QPHY_V4_LINECFG_DISABLE0x148
-#define QPHY_V4_RX_MIN_HIBERN8_TIME0x150
-#define QPHY_V4_RX_SIGDET_CTRL20x158
-#define QPHY_V4_TX_PWM_GEAR_BAND   0x160
-#define QPHY_V4_TX_HS_GEAR_BAND0x168
-#define QPHY_V4_PCS_READY_STATUS   0x180
-#define QPHY_V4_TX_MID_TERM_CTRL1  0x1d8
-#define QPHY_V4_MULTI_LANE_CTRL1   0x1e0
+#define QPHY_V4_PCS_UFS_PHY_START  0x000
+#define QPHY_V4_PCS_UFS_POWER_DOWN_CONTROL 0x004
+#define QPHY_V4_PCS_UFS_SW_RESET   0x008
+#define QPHY_V4_PCS_UFS_TIMER_20US_CORECLK_STEPS_MSB   0x00c
+#define QPHY_V4_PCS_UFS_TIMER_20US_CORECLK_STEPS_LSB   0x010
+#define QPHY_V4_PCS_UFS_PLL_CNTL   0x02c
+#define QPHY_V4_PCS_UFS_TX_LARGE_AMP_DRV_LVL   0x030
+#define QPHY_V4_PCS_UFS_TX_SMALL_AMP_DRV_LVL   0x038
+#define QPHY_V4_PCS_UFS_BIST_FIXED_PAT_CTRL0x060
+#define QPHY_V4_PCS_UFS_TX_HSGEAR_CAPABILITY   0x074
+#define QPHY_V4_PCS_UFS_RX_HSGEAR_CAPABILITY   0x0b4
+#define QPHY_V4_PCS_UFS_DEBUG_BUS_CLKSEL   0x124
+#define QPHY_V4_PCS_UFS_LINECFG_DISABLE0x148
+#define QPHY_V4_PCS_UFS_RX_MIN_HIBERN8_TIME0x150
+#define QPHY_V4_PCS_UFS_RX_SIGDET_CTRL20x158
+#define QPHY_V4_PCS_UFS_TX_PWM_GEAR_BAND   0x160

[PATCH v8 3/5] phy: qcom-qmp: Add SM8150 QMP USB3 PHY support

[Wesley Cheng]

From: Jack Pham 

Add support for SM8150 QMP USB3 PHY with the necessary
initialization sequences as well as additional QMP V4
register definitions.

Signed-off-by: Jack Pham 
Signed-off-by: Wesley Cheng 
Reviewed-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 153 
 drivers/phy/qualcomm/phy-qcom-qmp.h | 198 +++-
 2 files changed, 349 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 50cbcdc..d62bd09 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -177,6 +177,12 @@ enum qphy_reg_layout {
[QPHY_PCS_STATUS]   = 0x2ac,
 };
 
+static const unsigned int qmp_v4_usb3phy_regs_layout[] = {
+   [QPHY_SW_RESET] = 0x00,
+   [QPHY_START_CTRL]   = 0x44,
+   [QPHY_PCS_STATUS]   = 0x14,
+};
+
 static const unsigned int sdm845_ufsphy_regs_layout[] = {
[QPHY_START_CTRL]   = 0x00,
[QPHY_PCS_READY_STATUS] = 0x160,
@@ -1281,6 +1287,115 @@ enum qphy_reg_layout {
QMP_PHY_INIT_CFG(QPHY_V4_MULTI_LANE_CTRL1, 0x02),
 };
 
+static const struct qmp_phy_init_tbl sm8150_usb3_serdes_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_EN_CENTER, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_PER1, 0x31),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_PER2, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_STEP_SIZE1_MODE0, 0xde),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_STEP_SIZE2_MODE0, 0x07),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_STEP_SIZE1_MODE1, 0xde),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SSC_STEP_SIZE2_MODE1, 0x07),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_BUF_ENABLE, 0x0a),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_CMN_IPTRIM, 0x20),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_CP_CTRL_MODE0, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_CP_CTRL_MODE1, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_RCTRL_MODE0, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_RCTRL_MODE1, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_CCTRL_MODE0, 0x36),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_CCTRL_MODE1, 0x36),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_EN_SEL, 0x1a),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP_EN, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE0, 0x14),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE0, 0x34),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE1, 0x34),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE1, 0x82),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE0, 0x82),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE1, 0x82),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START1_MODE0, 0xab),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE0, 0xea),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE0, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_MAP, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START1_MODE1, 0xab),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE1, 0xea),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE1, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE1_MODE0, 0x24),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE1_MODE1, 0x24),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE2_MODE1, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_CORECLK_DIV_MODE1, 0x08),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0xca),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x1e),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE1_MODE1, 0xca),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_CMP_CODE2_MODE1, 0x1e),
+   QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIN_VCOCAL_HSCLK_SEL, 0x11),
+};
+
+static const struct qmp_phy_init_tbl sm8150_usb3_tx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V4_TX_RES_CODE_LANE_TX, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V4_TX_RES_CODE_LANE_RX, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V4_TX_LANE_MODE_1, 0xd5),
+   QMP_PHY_INIT_CFG(QSERDES_V4_TX_RCV_DETECT_LVL_2, 0x12),
+   QMP_PHY_INIT_CFG(QSERDES_V4_TX_PI_QEC_CTRL, 0x20),
+};
+
+static const struct qmp_phy_init_tbl sm8150_usb3_rx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_GAIN, 0x05),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FASTLOCK_FO_GAIN, 0x2f),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x7f),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FASTLOCK_COUNT_LOW, 0xff),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FASTLOCK_COUNT_HIGH, 0x0f),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_PI_CONTROLS, 0x99),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SB2_THRESH1, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SB2_THRESH2, 0x08),
+   QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SB2_GAIN1, 0x05),
+   QMP_PHY_INIT_CFG

[PATCH v8 1/5] dt-bindings: phy: Add binding for qcom,usb-snps-femto-v2

[Wesley Cheng]

This binding shows the descriptions and properties for the
Synopsis Femto USB PHY V2 used on QCOM platforms.

Signed-off-by: Wesley Cheng 
Reviewed-by: Rob Herring 
Reviewed-by: Stephen Boyd 
---
 .../bindings/phy/qcom,usb-snps-femto-v2.yaml   | 77 ++
 1 file changed, 77 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml

diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml 
b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
new file mode 100644
index 000..64d59c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/qcom,usb-snps-femto-v2.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Qualcomm Synopsys Femto High-Speed USB PHY V2
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  Qualcomm High-Speed USB PHY
+
+properties:
+  compatible:
+enum:
+  - qcom,usb-snps-hs-7nm-phy
+  - qcom,sm8150-usb-hs-phy
+  - qcom,usb-snps-femto-v2-phy
+
+  reg:
+maxItems: 1
+
+  "#phy-cells":
+const: 0
+
+  clocks:
+items:
+  - description: rpmhcc ref clock
+
+  clock-names:
+items:
+  - const: ref
+
+  resets:
+items:
+  - description: PHY core reset
+
+  vdda-pll-supply:
+description: phandle to the regulator VDD supply node.
+
+  vdda18-supply:
+description: phandle to the regulator 1.8V supply node.
+
+  vdda33-supply:
+description: phandle to the regulator 3.3V supply node.
+
+required:
+  - compatible
+  - reg
+  - "#phy-cells"
+  - clocks
+  - clock-names
+  - resets
+  - vdda-pll-supply
+  - vdda18-supply
+  - vdda33-supply
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+phy@88e2000 {
+compatible = "qcom,sm8150-usb-hs-phy";
+reg = <0 0x088e2000 0 0x400>;
+#phy-cells = <0>;
+
+clocks = < RPMH_CXO_CLK>;
+clock-names = "ref";
+
+resets = < GCC_QUSB2PHY_PRIM_BCR>;
+};
+...
+
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v6 0/5] Add SS/HS-USB changes for Qualcomm SM8150 chipset

[Wesley Cheng]

On 5/4/2020 12:15 AM, Vinod Koul wrote:
> Hi Wesley,
> 
> On 09-04-20, 15:52, Wesley Cheng wrote:
>> This series adds support for the Synopsis 7nm HSPHY USB driver being
>> used in QCOM chipsets.  The HSPHY register map differs compared to 
>> other PHY revisions.  In addition, modifications and updates are done
>> to the QMP driver to add new registers/offsets, and to update the
>> initialization sequence for enabling the SSUSB path on SM8150.
> 
> This fails to apply for me, Can you please rebase on
> git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git next and
> send.
> 
> Also, I saw checkpatch --strict complain about "Alignment should match
> open parenthesis" please check and fix while not sacrificing readablity.
> 
> Thanks
> 

Hi Vinod,

Got it!  Will rebase and fix warnings, and resend a patch revision
tomorrow.  Thanks again.

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[go-nuts] Is this AMQP 0.9.1 library updated?

['Wesley Peng' via golang-nuts]

Hello,
I tried to access RabbitMQ using this AMQP 
library:https://github.com/streadway/amqp

I am not sure if this library get updated following the recent RMQ 
version.Please suggest, thanks.

Wesley Peng
wesleyp...@aol.com

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1077505155.1304617.1588125421267%40mail.yahoo.com.

Re: [PATCH v6 0/5] Add SS/HS-USB changes for Qualcomm SM8150 chipset

[Wesley Cheng]

Hi Kishon/Vinod,

Is this series good, and can be picked up?  Noticed that there was
another recent change to the QMP PHY driver as well:
https://patchwork.kernel.org/cover/11514761/

Did you want me to rebase my changes on top of that, or the current
changes are sufficient?

Thanks
Wesley

On 4/9/2020 3:52 PM, Wesley Cheng wrote:
> This series adds support for the Synopsis 7nm HSPHY USB driver being
> used in QCOM chipsets.  The HSPHY register map differs compared to 
> other PHY revisions.  In addition, modifications and updates are done
> to the QMP driver to add new registers/offsets, and to update the
> initialization sequence for enabling the SSUSB path on SM8150.
> 
> Changes in v6:
>  - Addressed coding style errors in phy-qcom-snps-femto-v2.c
> 
> Changes in v5:
>  - Reorganize IF check for when to use the proper PWRDOWN CTRL offset
>  - Rename UFS specific offset definitions in the QMP PHY driver to clearly
>denote they are UFS specific
>  - Rename the phy-qcom-snps-7nm driver to phy-qcom-snps-femto-v2
> 
> Changes in v4:
>  - Fix POWERDOWN offset for QMP PHY exit routine, and check for
>has_phy_dp_com_ctrl instead of !has_phy_com_ctrl
> 
> Changes in v3:
>  - Use devm_reset_control_get_exclusive instead of referencing index for
>reset handle
> 
> Changes in v2:
>  - Fixed YAML errors caught by dt_binding_check
> 
> Jack Pham (1):
>   phy: qcom-qmp: Add SM8150 QMP USB3 PHY support
> 
> Wesley Cheng (4):
>   dt-bindings: phy: Add binding for qcom,usb-snps-femto-v2
>   phy: qcom-snps: Add SNPS USB PHY driver for QCOM based SOCs
>   phy: qcom-qmp: Use proper PWRDOWN offset for sm8150 USB
>   phy: qcom-qmp: Rename UFS PCS QMP v4 registers
> 
>  .../bindings/phy/qcom,usb-snps-femto-v2.yaml   |  77 ++
>  drivers/phy/qualcomm/Kconfig   |  10 +
>  drivers/phy/qualcomm/Makefile  |   1 +
>  drivers/phy/qualcomm/phy-qcom-qmp.c| 193 +-
>  drivers/phy/qualcomm/phy-qcom-qmp.h| 238 +++--
>  drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c  | 296 
> +
>  6 files changed, 779 insertions(+), 36 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
>  create mode 100644 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

RE: [cayugabirds-l] Spotting scope question

[Wesley M. Hochachka]

I doubt that there is any such thing as the “perfect” all-purpose spotting 
scope…regardless of price.  So I think that it’s important to decide how a 
scope will typically be used, and then buy a style of scope that maximizes 
utility for the most likely use cases, without eliminating the possibility of 
other likely use cases.  Jody, and Melissa and Wade described a couple of 
different use cases for which different styles of scopes would be preferred.

Oh, and there really is a difference between scopes whose optics include “ED” 
(or “high dispersion” or some other “special” glass), if a company makes models 
with and without any “special” glass.  Images are just crisper when 
special-glass elements are included.  I’ve seen this in side-by-side 
comparisons of scopes even from high-end companies like Swarovski.

I’ll second Jody’s suggestion that it’s important to budget for a good tripod 
and tripod head (with a decent quick-release system for removing the scope), in 
addition to the scope.  One thing to consider regarding the combination of 
scope + tripod is that (in my opinion) an extendable center column of a tripod 
a the devil’s own invention, because an extended center column is a lever arm 
that magnifies any vibration caused by wind, or touching the scope or tripod.  
It’s better to get a scope up to the desired height by only extending the 
tripod’s legs than to have to raise a center column in order for the scope to 
be raised to a suitable height for use.  That’s another reason why an 
angled-eyepiece scope can be better (assuming that angling would meet other 
requirements): the scope doesn’t have to be raised as high in order to look 
into the eyepiece.

Wesley


From: bounce-124587702-3494...@list.cornell.edu 
 On Behalf Of Gone
Sent: Tuesday, April 28, 2020 10:27 AM
To: CAYUGABIRDS-L 
Subject: RE: [cayugabirds-l] Spotting scope question

My wife and I use straight 60x  80mm scopes, hers is a Vortex Optics Viper HD 
and mine is a  Clestron Ultima 80  with a BAADER PLANETARIUM  Hyperion zoom 
8-24 mark III eyepiece. I found my Celestron lacking after looking through my 
wifes Viper with the ED glass so I added the BADDER eyepiece to mine which made 
a world of difference putting my scope on par with hers. We found the angled 
scopes did not work for us because looking in a close tree the angle was good 
but the field of view was limited so our 10x42 and 12x42 binos worked just fine 
for that. Another reason for straight, for us, is that we scope more than 75% 
of the time with car window mounts and the angled scope will not work for that.
Melissa and Wade


From: 
bounce-124586701-26966...@list.cornell.edu<mailto:bounce-124586701-26966...@list.cornell.edu>
 [mailto:bounce-124586701-26966...@list.cornell.edu] On Behalf Of Peter Saracino
Sent: Monday, April 27, 2020 8:45 PM
To: Cayugabirds-L@cornell.edu<mailto:Cayugabirds-L@cornell.edu>
Subject: [cayugabirds-l] Spotting scope question

Hi folks. I'm in the market for a relatively inexpensive (but halfway 
decent)spotting scope (straight barrel), and am wondering if anyone out there 
can recommend one.
Thank you.
Pete Sar
--
Cayugabirds-L List Info:
Welcome and Basics<http://www.northeastbirding.com/CayugabirdsWELCOME>
Rules and Information<http://www.northeastbirding.com/CayugabirdsRULES>
Subscribe, Configuration and 
Leave<http://www.northeastbirding.com/CayugabirdsSubscribeConfigurationLeave.htm>
Archives:
The Mail 
Archive<http://www.mail-archive.com/cayugabirds-l@cornell.edu/maillist.html>
Surfbirds<http://www.surfbirds.com/birdingmail/Group/Cayugabirds>
BirdingOnThe.Net<http://birdingonthe.net/mailinglists/CAYU.html>
Please submit your observations to eBird<http://ebird.org/content/ebird/>!
--
--
Cayugabirds-L List Info:
Welcome and Basics<http://www.northeastbirding.com/CayugabirdsWELCOME>
Rules and Information<http://www.northeastbirding.com/CayugabirdsRULES>
Subscribe, Configuration and 
Leave<http://www.northeastbirding.com/CayugabirdsSubscribeConfigurationLeave.htm>
Archives:
The Mail 
Archive<http://www.mail-archive.com/cayugabirds-l@cornell.edu/maillist.html>
Surfbirds<http://www.surfbirds.com/birdingmail/Group/Cayugabirds>
BirdingOnThe.Net<http://birdingonthe.net/mailinglists/CAYU.html>
Please submit your observations to eBird<http://ebird.org/content/ebird/>!
--

--

Cayugabirds-L List Info:
http://www.NortheastBirding.com/CayugabirdsWELCOME
http://www.NortheastBirding.com/CayugabirdsRULES
http://www.NortheastBirding.com/CayugabirdsSubscribeConfigurationLeave.htm

ARCHIVES:
1) http://www.mail-archive.com/cayugabirds-l@cornell.edu/maillist.html
2) http://www.surfbirds.com/birdingmail/Group/Cayugabirds
3) http://birdingonthe.net/mailinglists/CAYU.html

Please submit your observations to eBird:
http://ebird.org/content/ebird/

--

Re: [rdo-dev] New services on rdoproject.org

[Wesley Hayutin]

On Tue, Apr 28, 2020 at 9:35 AM Daniel Pawlik  wrote:

> Hi,
>
> Today we enable new services on rdoproject.org:
> - cgit
> - codesearch
>

Great additions! Thanks Daniel!


>
> Old domain codesearch.rdoproject.org will be removed and now
> service address is: https://review.rdoproject.org/codesearch/.
> I suggest to "hard" refresh the review.rdoproject.org to
> update the site cache.
>
> If you have any problems related to this change, please do not hesitate to
> contact me.
>
>
> Regards,
> Dan
> ___
> dev mailing list
> dev@lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscr...@lists.rdoproject.org
>
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Scaling question - 1500 jobs a night?

[Anthony Wesley]

Hiya,

Clear question up front: what additional concerns should I have when 
running 1500 jobs a night?  

Details:
We are using Jenkins to run integration tests for our software.  I wrote a 
pipeline script to operate on a single chunk of data representing a test 
case.  However, I have roughly 1500 permutations of this data.  I have 
never asked this much of Jenkins.  
It finishes quick enough, especially thanks to parallel builds (this is 
precisely why we are using Jenkins to run these tests - we can distribute 
this across our nodes very easily and it handles scheduling for us).  

My guess is that this is well within Jenkins' limits and we are managing 
our workspaces with good hygiene.  A year from now, however, I will have 
ran half a million Jenkins jobs.  Any thoughts on that?

Thank you very kindly,

Anthony Wesley

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/7ea69575-295d-45b2-840c-ade499a927ea%40googlegroups.com.

Re: POST multipart/form-data with Invokehttp

[Wesley C. Dias de Oliveira]

Owh!

Great, Otto!

Good news!

Em seg., 27 de abr. de 2020 às 14:50, Otto Fowler 
escreveu:

> What good timing, I just did : https://github.com/apache/nifi/pull/4234
> If you can build and try that would be sweet!  or maybe a review!
>
> On April 27, 2020 at 13:45:42, Etienne Jouvin (lapinoujou...@gmail.com)
> wrote:
>
> Hello.
>
> I did it with a processor ExecuteGroovyScript.
>
> The script body is something like :
>
> import org.apache.http.entity.mime.MultipartEntityBuilder
> import org.apache.http.entity.ContentType
>
> flowFileList = session.get(100)
> if(!flowFileList.isEmpty()) {
>   flowFileList.each { flowFile ->
> def multipart
> String text = flowFile.read().getText("UTF-8")
>
> flowFile.write{streamIn, streamOut->
>   multipart = MultipartEntityBuilder.create()
> //specify multipart entries here
> .addTextBody("object", text, ContentType.APPLICATION_JSON)
> .addBinaryBody("content", new
> File(flowFile.'document.content.path'),
> ContentType.create(flowFile.'document.mime.type'), flowFile.'document.name
> ')
> .build()
>   multipart.writeTo(streamOut)
> }
> //set the `documentum.action.rest.content.type` attribute to be used
> as `Content-Type` in InvokeHTTP
> flowFile.'document.content.type' =
> multipart.getContentType().getValue()
> session.transfer(flowFile, REL_SUCCESS)
>   }
> }
>
>
> Attributes are :
>
>- document.content.path : content path
>- document.mime.type : content mime type
>- document.name : binaire content name
>
>
> Output update attribute
> document.content.type : multipart content type.
>
> You need some extra librairies :
>
>- httpcore-4.4.12.jar
>- httpmime-4.5.10.jar
>
>
> This will build a multipart as the flowfile content and you can use it for
> the call after.
>
>
> Etienne
>
>
> Le lun. 27 avr. 2020 à 19:21, Luis Carmona  a
> écrit :
>
>> Hi everyone,
>>
>> Hoping everybody is doing ok, wherever you are, need some help please.
>>
>> Does anyone has sent a file and parameters to a REST point using
>> Invokehhtp with multipart/form-data as mime-type ?
>>
>> I can't figure out how to include the -F , speaking in terms
>> of curl syntax.
>>
>> I really need this done throught NIFIso any help will be highly
>> apreciated.
>>
>> Thanks in advance.
>>
>> LC
>>
>>

-- 
Grato,
Wesley C. Dias de Oliveira.

Linux User nº 576838.

Re: POST multipart/form-data with Invokehttp

[Wesley C. Dias de Oliveira]

Hello, Luis.

Have you tried to send with ExecuteProcessor?

[image: image.png]

Using that way you can invoke curl explicit to run your command.

Em seg., 27 de abr. de 2020 às 14:21, Luis Carmona 
escreveu:

> Hi everyone,
>
> Hoping everybody is doing ok, wherever you are, need some help please.
>
> Does anyone has sent a file and parameters to a REST point using
> Invokehhtp with multipart/form-data as mime-type ?
>
> I can't figure out how to include the -F , speaking in terms
> of curl syntax.
>
> I really need this done throught NIFIso any help will be highly
> apreciated.
>
> Thanks in advance.
>
> LC
>
>

-- 
Grato,
Wesley C. Dias de Oliveira.

Linux User nº 576838.

[ovirt-users] Custom ignition in cloud-init?

[Wesley Stewart]

Before anyone tells me this is now included in 4.4.0, I saw this, but I
don't think I'm willing to update my centos7 host to centos8 yet. (But
perhaps that will be the answer).  Currently on 4.3.9/Centos 7

I am trying to run fedora core is to test it out, and the ISO installer
hangs on:
"failed to isolate default target freezing"

So I tried the QCOW2 image, but I'm looking at ways of running the ignition
file.  I see in the "run once" section i can deploy a custom unit script,
and I was wondering is this filetype agnostic?  If I generate a JSON
ignition script and put it in there will it get passed through correctly ?
Or will I need to update to 4.4.0?

I also found:
https://gerrit.ovirt.org/#/c/18/
This was abondoned for a "better solution" last September.  Was this
referring to the changes in 4.4.0?

Lastly has anyone who was running 4.3.9 upgrade their centos host to
centos8 and then upgrade ovirt without any issues?  I usually try and wait
at least a couple of minor version changes before switching to a new major
version.

Thanks guys!
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LJ7MZMWXFHBG2Q5SJVWXFLH6M25E4VV7/

RE: Capslock not working in RDP

[Wesley de Graaf]

Hi,

So to clarify the issue we have, I've tested it with the latest versions of 
guac-server and guac-client (1.1.0) on Ubuntu 18.04. 

Test setup: RDP to Windows server 2016, RDP to Windows server 2019.

Both scenario's, not depending on the keyboard settings, the Caps lock is not 
working as expected. When opening the RDP session everything is working as 
expected. But when pressing the Caps lock you see that the caps lock is enabled 
on the remote server but the input you type will still be non-capital letters...

When you open the on-creen keyboard in the RDP session and you enable the caps 
lock there, it is working for some reason.. 

Are there any suggestions on this on how to fix it, we've checked everything 
but can't seem to get it working.  

Kind regards,

Wesley

-Original Message-
From: Wesley de Graaf 
Sent: Thursday, April 16, 2020 4:47 PM
To: user@guacamole.apache.org
Subject: RE: Capslock not working in RDP

Hi Alesandro,

Thanks for your information. We have it set to ENG, and all keyboard shortcuts 
are working as expected, only enabling CAPS Lock does not seem to work 
correctly.

The CAPS locks seems to be enabled in the RDP session, but typing still gives 
me the NON capital letters. It’s a strange issue. 

Kind regards,

Wesley

-Original Message-
From: Niubbo75  
Sent: Thursday, April 16, 2020 2:23 PM
To: user@guacamole.apache.org
Subject: RE: Capslock not working in RDP

Hi,
I do not have your caps lock issue, I'm on compiled Guacamole server on
CentOS7 with the latest update.
On our remote server we have set IT layout but when we connect to them via 
Guacamole keyboard automatically switch to EN, if we do not touch anything, 
keyboard works like a charm and we do not have any issues, if we switch to IT 
then keymap become wrong (I mean hitting key # and get £).

In Guacamole client we have setup default language Italian, on every type of 
connection we do not have this kind of issue with keyboard (VNC, RDP, Telnet, 
SSH).

Alessandro.



--
Sent from: 
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org