* [PATCH 2/2] ARM: dts: hix5hd2: don't change the existing compatible string
From: Dongpo Li @ 2016-12-20 2:09 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
salil.mehta-hv44wF8Li93QT0dZR+AlfA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
arnd-r2nGTMty4D4, andrew-g2DYL2Zd6BY
Cc: xuejiancheng-C8/M+/jPZTeaMJb+Lgu22Q,
benjamin.chenhao-C8/M+/jPZTeaMJb+Lgu22Q,
caizhiyong-C8/M+/jPZTeaMJb+Lgu22Q, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Dongpo Li
In-Reply-To: <1482199769-106501-1-git-send-email-lidongpo-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
The SoC hix5hd2 compatible string has the suffix "-gmac" and
we should not change it.
We should only add the generic compatible string "hisi-gmac-v1".
Fixes: 0855950ba580 ("ARM: dts: hix5hd2: add gmac generic compatible and clock names")
Signed-off-by: Dongpo Li <lidongpo-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
---
arch/arm/boot/dts/hisi-x5hd2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index 0da76c5..2d06f4c 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -436,7 +436,7 @@
};
gmac0: ethernet@1840000 {
- compatible = "hisilicon,hix5hd2-gemac", "hisilicon,hisi-gemac-v1";
+ compatible = "hisilicon,hix5hd2-gmac", "hisilicon,hisi-gmac-v1";
reg = <0x1840000 0x1000>,<0x184300c 0x4>;
interrupts = <0 71 4>;
clocks = <&clock HIX5HD2_MAC0_CLK>;
@@ -445,7 +445,7 @@
};
gmac1: ethernet@1841000 {
- compatible = "hisilicon,hix5hd2-gemac", "hisilicon,hisi-gemac-v1";
+ compatible = "hisilicon,hix5hd2-gmac", "hisilicon,hisi-gmac-v1";
reg = <0x1841000 0x1000>,<0x1843010 0x4>;
interrupts = <0 72 4>;
clocks = <&clock HIX5HD2_MAC1_CLK>;
--
2.8.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/2] net: hix5hd2_gmac: fix compatible strings name
From: Dongpo Li @ 2016-12-20 2:09 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, yisen.zhuang, salil.mehta, davem,
arnd, andrew
Cc: xuejiancheng, benjamin.chenhao, caizhiyong, netdev, devicetree,
linux-kernel, Dongpo Li
In-Reply-To: <1482199769-106501-1-git-send-email-lidongpo@hisilicon.com>
The SoC hix5hd2 compatible string has the suffix "-gmac" and
we should not change its compatible string.
So we should name all the compatible string with the suffix "-gmac".
Creating a new name suffix "-gemac" is unnecessary.
We also add another SoC compatible string in dt binding documentation
and describe which generic version the SoC belongs to.
Fixes: d0fb6ba75dc0 ("net: hix5hd2_gmac: add generic compatible string")
Signed-off-by: Dongpo Li <lidongpo@hisilicon.com>
---
.../devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt | 13 ++++++++-----
drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 13 +++++++------
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
index 063c02d..eea73ad 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
@@ -2,11 +2,14 @@ Hisilicon hix5hd2 gmac controller
Required properties:
- compatible: should contain one of the following SoC strings:
- * "hisilicon,hix5hd2-gemac"
- * "hisilicon,hi3798cv200-gemac"
+ * "hisilicon,hix5hd2-gmac"
+ * "hisilicon,hi3798cv200-gmac"
+ * "hisilicon,hi3516a-gmac"
and one of the following version string:
- * "hisilicon,hisi-gemac-v1"
- * "hisilicon,hisi-gemac-v2"
+ * "hisilicon,hisi-gmac-v1"
+ * "hisilicon,hisi-gmac-v2"
+ The version v1 includes SoCs hix5hd2.
+ The version v2 includes SoCs hi3798cv200, hi3516a.
- reg: specifies base physical address(s) and size of the device registers.
The first region is the MAC register base and size.
The second region is external interface control register.
@@ -35,7 +38,7 @@ Required properties:
Example:
gmac0: ethernet@f9840000 {
- compatible = "hisilicon,hi3798cv200-gemac", "hisilicon,hisi-gemac-v2";
+ compatible = "hisilicon,hi3798cv200-gmac", "hisilicon,hisi-gmac-v2";
reg = <0xf9840000 0x1000>,<0xf984300c 0x4>;
interrupts = <0 71 4>;
#address-cells = <1>;
diff --git a/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c b/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
index ee7e9ce..418ca1f3 100644
--- a/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
@@ -1316,10 +1316,11 @@ static int hix5hd2_dev_remove(struct platform_device *pdev)
}
static const struct of_device_id hix5hd2_of_match[] = {
- { .compatible = "hisilicon,hisi-gemac-v1", .data = (void *)GEMAC_V1 },
- { .compatible = "hisilicon,hisi-gemac-v2", .data = (void *)GEMAC_V2 },
- { .compatible = "hisilicon,hix5hd2-gemac", .data = (void *)GEMAC_V1 },
- { .compatible = "hisilicon,hi3798cv200-gemac", .data = (void *)GEMAC_V2 },
+ { .compatible = "hisilicon,hisi-gmac-v1", .data = (void *)GEMAC_V1 },
+ { .compatible = "hisilicon,hisi-gmac-v2", .data = (void *)GEMAC_V2 },
+ { .compatible = "hisilicon,hix5hd2-gmac", .data = (void *)GEMAC_V1 },
+ { .compatible = "hisilicon,hi3798cv200-gmac", .data = (void *)GEMAC_V2 },
+ { .compatible = "hisilicon,hi3516a-gmac", .data = (void *)GEMAC_V2 },
{},
};
@@ -1327,7 +1328,7 @@ MODULE_DEVICE_TABLE(of, hix5hd2_of_match);
static struct platform_driver hix5hd2_dev_driver = {
.driver = {
- .name = "hisi-gemac",
+ .name = "hisi-gmac",
.of_match_table = hix5hd2_of_match,
},
.probe = hix5hd2_dev_probe,
@@ -1338,4 +1339,4 @@ module_platform_driver(hix5hd2_dev_driver);
MODULE_DESCRIPTION("HISILICON Gigabit Ethernet MAC driver");
MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:hisi-gemac");
+MODULE_ALIAS("platform:hisi-gmac");
--
2.8.2
^ permalink raw reply related
* [PATCH 0/2] net: hix5hd2_gmac: keep the compatible string not changed
From: Dongpo Li @ 2016-12-20 2:09 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, yisen.zhuang, salil.mehta, davem,
arnd, andrew
Cc: xuejiancheng, benjamin.chenhao, caizhiyong, netdev, devicetree,
linux-kernel, Dongpo Li
This patch series fix the patch:
d0fb6ba75dc0 ("net: hix5hd2_gmac: add generic compatible string")
The SoC hix5hd2 compatible string has the suffix "-gmac" and
we should not change its compatible string.
So we should name all the compatible string with the suffix "-gmac".
Creating a new name suffix "-gemac" is unnecessary.
Dongpo Li (2):
net: hix5hd2_gmac: fix compatible strings name
ARM: dts: hix5hd2: don't change the existing compatible string
.../devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt | 13 ++++++++-----
arch/arm/boot/dts/hisi-x5hd2.dtsi | 4 ++--
drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 13 +++++++------
3 files changed, 17 insertions(+), 13 deletions(-)
--
2.8.2
^ permalink raw reply
* Re: [PATCH v2 2/3] Bluetooth: btusb: Add out-of-band wakeup support
From: Rajat Jain @ 2016-12-20 1:46 UTC (permalink / raw)
To: Brian Norris
Cc: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev, devicetree, linux-bluetooth, linux-kernel, Rajat Jain
In-Reply-To: <20161219231021.GA142074@google.com>
Hi Brian,
On Mon, Dec 19, 2016 at 3:10 PM, Brian Norris <briannorris@chromium.org> wrote:
> Hi Rajat,
>
> On Fri, Dec 16, 2016 at 11:30:03AM -0800, Rajat Jain wrote:
>> Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that
>> can be connected to a gpio on the CPU side, and can be used to wakeup
>> the host out-of-band. This can be useful in situations where the
>> in-band wakeup is not possible or not preferable (e.g. the in-band
>> wakeup may require the USB host controller to remain active, and
>> hence consuming more system power during system sleep).
>>
>> The oob gpio interrupt to be used for wakeup on the CPU side, is
>> read from the device tree node, (using standard interrupt descriptors).
>> A devcie tree binding document is also added for the driver. The
>> compatible string is in compliance with
>> Documentation/devicetree/bindings/usb/usb-device.txt
>>
>> Signed-off-by: Rajat Jain <rajatja@google.com>
>
> A few small comments below, but other than those, for the whole series:
>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
>
>> ---
>> v2: * Use interrupt-names ("wakeup") instead of assuming first interrupt.
>> * Leave it on device tree to specify IRQ flags (level /edge triggered)
>> * Mark the device as non wakeable on exit.
>>
>> Documentation/devicetree/bindings/net/btusb.txt | 40 ++++++++++++
>> drivers/bluetooth/btusb.c | 84 +++++++++++++++++++++++++
>> 2 files changed, 124 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/btusb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt
>> new file mode 100644
>> index 0000000..2c0355c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/btusb.txt
>> @@ -0,0 +1,40 @@
>> +Generic Bluetooth controller over USB (btusb driver)
>> +---------------------------------------------------
>> +
>> +Required properties:
>> +
>> + - compatible : should comply with the format "usbVID,PID" specified in
>> + Documentation/devicetree/bindings/usb/usb-device.txt
>> + At the time of writing, the only OF supported devices
>> + (more may be added later) are:
>> +
>> + "usb1286,204e" (Marvell 8997)
>
> I don't know if anyone cares about these sort of organizational aspects,
> but in patch 3 you're extending this binding with device-specific
> Marvell bindings. Seems like it'd be good to have some clear way to
> correlate those 2. e.g., add a reference to marvell-bt-sd8xxx.txt (or
> marvell-bt-8xxx.txt, once you rename it) in patch 3.
Good idea, I'll do it. (I'll add a reference to marvell-bt-8xxx.txt in
btusb.txt).
>
>> +
>> +Optional properties:
>> +
>> + - interrupt-parent: phandle of the parent interrupt controller
>> + - interrupt-names: (see below)
>> + - interrupts : The interrupt specified by the name "wakeup" is the interrupt
>> + that shall be used for out-of-band wake-on-bt. Driver will
>> + request this interrupt for wakeup. During system suspend, the
>> + irq will be enabled so that the bluetooth chip can wakeup host
>> + platform out of band. During system resume, the irq will be
>> + disabled to make sure unnecessary interrupt is not received.
>> +
>> +Example:
>> +
>> +Following example uses irq pin number 3 of gpio0 for out of band wake-on-bt:
>> +
>> +&usb_host1_ehci {
>> + status = "okay";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + mvl_bt1: bt@1 {
>> + compatible = "usb1286,204e";
>> + reg = <1>;
>> + interrupt-parent = <&gpio0>;
>> + interrupt-name = "wakeup";
>> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
>> + };
>> +};
>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>> index ce22cef..beca4e9 100644
>> --- a/drivers/bluetooth/btusb.c
>> +++ b/drivers/bluetooth/btusb.c
>> @@ -24,6 +24,8 @@
>> #include <linux/module.h>
>> #include <linux/usb.h>
>> #include <linux/firmware.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_irq.h>
>> #include <asm/unaligned.h>
>>
>> #include <net/bluetooth/bluetooth.h>
>> @@ -369,6 +371,7 @@ static const struct usb_device_id blacklist_table[] = {
>> #define BTUSB_BOOTING 9
>> #define BTUSB_RESET_RESUME 10
>> #define BTUSB_DIAG_RUNNING 11
>> +#define BTUSB_OOB_WAKE_DISABLED 12
>>
>> struct btusb_data {
>> struct hci_dev *hdev;
>> @@ -416,6 +419,8 @@ struct btusb_data {
>> int (*recv_bulk)(struct btusb_data *data, void *buffer, int count);
>>
>> int (*setup_on_usb)(struct hci_dev *hdev);
>> +
>> + int oob_wake_irq; /* irq for out-of-band wake-on-bt */
>> };
>>
>> static inline void btusb_free_frags(struct btusb_data *data)
>> @@ -2728,6 +2733,65 @@ static int btusb_bcm_set_diag(struct hci_dev *hdev, bool enable)
>> }
>> #endif
>>
>> +#ifdef CONFIG_PM
>> +static irqreturn_t btusb_oob_wake_handler(int irq, void *priv)
>> +{
>> + struct btusb_data *data = priv;
>> +
>> + /* Disable only if not already disabled (keep it balanced) */
>> + if (!test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
>> + disable_irq_nosync(irq);
>> + disable_irq_wake(irq);
>> + }
>> + pm_wakeup_event(&data->udev->dev, 0);
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static const struct of_device_id btusb_match_table[] = {
>> + { .compatible = "usb1286,204e" },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, btusb_match_table);
>
> You define a match table here, but you also define essentially same
> table for Marvell-specific additions in patch 3. It looks like maybe
> it's legal to have more than one OF table in a module? But it seems like
> it would get confusing, besides being somewhat strange to maintain. It
> might also produce duplicate 'modinfo' output.
>
> If you really want to independently opt into device-tree-specified
> interrupts vs. Marvell-specific interrrupt configuration, then you
> should probably just merge the latter into the former table, and
> implement a Marvell/GPIO flag to stick in the .data field of this table.
The data we want to stick (The pin number on the chip) is board
specific rather than being chip specific, and hence .data may not be
useful here.
>
> Or it might be fine to drop one or both "match" checks. Particularly for
> the Marvell-specific stuff, it's probably fair just to check if it has
> an ->of_node and if 'id->driver_info & BTUSB_MARVELL'. Any other Marvell
> device-specific quirks could probably be keyed off of the
> (weirdly-named?) blacklist_table[], which already matches PID/VID.
Yup, I think I can remove the compatible string checks.
I'll be sending a V3.
>
>> +
>> +/* Use an oob wakeup pin? */
>> +static int btusb_config_oob_wake(struct hci_dev *hdev)
>> +{
>> + struct btusb_data *data = hci_get_drvdata(hdev);
>> + struct device *dev = &data->udev->dev;
>> + int irq, ret;
>> +
>> + if (!of_match_device(btusb_match_table, dev))
>> + return 0;
>> +
>> + /* Move on if no IRQ specified */
>> + irq = of_irq_get_byname(dev->of_node, "wakeup");
>> + if (irq <= 0) {
>> + bt_dev_dbg(hdev, "%s: no OOB Wakeup IRQ in DT", __func__);
>> + return 0;
>> + }
>> +
>> + set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
>> +
>> + ret = devm_request_irq(&hdev->dev, irq, btusb_oob_wake_handler,
>> + 0, "OOB Wake-on-BT", data);
>> + if (ret) {
>> + bt_dev_err(hdev, "%s: IRQ request failed", __func__);
>> + return ret;
>> + }
>> +
>> + ret = device_init_wakeup(dev, true);
>> + if (ret) {
>> + bt_dev_err(hdev, "%s: failed to init_wakeup\n", __func__);
>> + return ret;
>> + }
>> +
>> + data->oob_wake_irq = irq;
>> + disable_irq(irq);
>> + bt_dev_info(hdev, "OOB Wake-on-BT configured at IRQ %u\n", irq);
>> + return 0;
>> +}
>> +#endif
>> +
>> static int btusb_probe(struct usb_interface *intf,
>> const struct usb_device_id *id)
>> {
>> @@ -2849,6 +2913,11 @@ static int btusb_probe(struct usb_interface *intf,
>> hdev->send = btusb_send_frame;
>> hdev->notify = btusb_notify;
>>
>> +#ifdef CONFIG_PM
>> + err = btusb_config_oob_wake(hdev);
>> + if (err)
>> + goto out_free_dev;
>> +#endif
>> if (id->driver_info & BTUSB_CW6622)
>> set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
>>
>> @@ -3061,6 +3130,9 @@ static void btusb_disconnect(struct usb_interface *intf)
>> usb_driver_release_interface(&btusb_driver, data->isoc);
>> }
>>
>> + if (data->oob_wake_irq)
>> + device_init_wakeup(&data->udev->dev, false);
>> +
>> hci_free_dev(hdev);
>> }
>>
>> @@ -3089,6 +3161,12 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
>> btusb_stop_traffic(data);
>> usb_kill_anchored_urbs(&data->tx_anchor);
>>
>> + if (data->oob_wake_irq && device_may_wakeup(&data->udev->dev)) {
>> + clear_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
>> + enable_irq_wake(data->oob_wake_irq);
>> + enable_irq(data->oob_wake_irq);
>> + }
>> +
>> /* Optionally request a device reset on resume, but only when
>> * wakeups are disabled. If wakeups are enabled we assume the
>> * device will stay powered up throughout suspend.
>> @@ -3126,6 +3204,12 @@ static int btusb_resume(struct usb_interface *intf)
>> if (--data->suspend_count)
>
> Not related to your patch exactly, but isn't this 'suspend_count' stuff
> useless? I'd send a patch, but it might conflict with yours. Just wanted
> to note it and see if I'm crazy...
>
> Brian
>
>> return 0;
>>
>> + /* Disable only if not already disabled (keep it balanced) */
>> + if (!test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
>> + disable_irq(data->oob_wake_irq);
>> + disable_irq_wake(data->oob_wake_irq);
>> + }
>> +
>> if (!test_bit(HCI_RUNNING, &hdev->flags))
>> goto done;
>>
>> --
>> 2.8.0.rc3.226.g39d4020
>>
^ permalink raw reply
* Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string
From: Dongpo Li @ 2016-12-20 1:35 UTC (permalink / raw)
To: Rob Herring
Cc: David Miller, Mark Rutland, Michael Turquette, Stephen Boyd,
Russell King, Zhangfei Gao, Yisen Zhuang, salil.mehta,
Arnd Bergmann, Andrew Lunn, Jiancheng Xue, benjamin.chenhao,
caizhiyong, netdev, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAL_Jsq+Su84DonQbh2KZ2o8JQ0Mqarag60Oq=Dby3y8Doyozxg@mail.gmail.com>
On 2016/12/20 0:04, Rob Herring wrote:
> On Mon, Dec 19, 2016 at 2:14 AM, Dongpo Li <lidongpo@hisilicon.com> wrote:
>> Hi Rob and David,
>>
>> On 2016/12/12 22:21, Rob Herring wrote:
>>> On Mon, Dec 12, 2016 at 5:16 AM, Dongpo Li <lidongpo@hisilicon.com> wrote:
>>>> Hi Rob,
>>>>
>>>> On 2016/12/10 6:35, Rob Herring wrote:
>>>>> On Mon, Dec 05, 2016 at 09:27:58PM +0800, Dongpo Li wrote:
>
> [...]
>
>>>>>> @@ -20,7 +25,7 @@ Required properties:
>>>>>>
>>>>>> Example:
>>>>>> gmac0: ethernet@f9840000 {
>>>>>> - compatible = "hisilicon,hix5hd2-gmac";
>>>>>> + compatible = "hisilicon,hix5hd2-gemac", "hisilicon,hisi-gemac-v1";
>>>>>
>>>>> You can't just change compatible strings.
>>>>>
>>>> Okay, maybe I should name all the compatible string with the suffix "-gmac" instead of
>>>> "-gemac". This can keep the compatible strings with the same suffix. Is this okay?
>>>> Can I just add the generic compatible string without changing the SoCs compatible string?
>>>> Like following:
>>>> gmac0: ethernet@f9840000 {
>>>> - compatible = "hisilicon,hix5hd2-gmac";
>>>> + compatible = "hisilicon,hix5hd2-gmac", "hisilicon,hisi-gmac-v1";
>>>
>>> Yes, this is fine.
>>
>> As the patch series have been applied to net-next branch,
>> in which way should I commit this compatible fix?
>> Should I send a new patch fixing this compatible string error with "Fixes: xxx"?
>> Looking forward to your reply!
>
> Yes to both.
Okay, thanks for your reply!
I will send the fix patch series as soon as possible.
Regards,
Dongpo
.
^ permalink raw reply
* Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Geoff Lansberry @ 2016-12-19 23:23 UTC (permalink / raw)
To: Rob Herring
Cc: linux-wireless, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, mark.rutland-5wv7dgnIgG8,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Greer, Justin Bronder
In-Reply-To: <20161219223111.itu77g7wsqtj6cvs@rob-hp-laptop>
I can make that change, however, I worry that it may be a bit
misleading, since there are only two supported clock frequencies, but
a number like that to me implies that it could be set to any number
you want. I'm new at this, and so I'll go ahead and change it as you
request, but I'd like to hear your thoughts on my concern.
Thanks
Geoff
Geoff Lansberry
Engineering Guy
Kuvée, Inc
125 Kingston St., 3rd Floor
Boston, MA 02111
1-617-290-1118 (m)
geoff.lansberry (skype)
http://www.kuvee.com
On Mon, Dec 19, 2016 at 5:31 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Dec 15, 2016 at 05:30:42PM -0500, Geoff Lansberry wrote:
>> From: Geoff Lansberry <geoff-R+k406RtEhcAvxtiuMwx3w@public.gmane.org>
>>
>> ---
>> .../devicetree/bindings/net/nfc/trf7970a.txt | 3 ++
>> drivers/nfc/trf7970a.c | 42 ++++++++++++++++------
>> 2 files changed, 34 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
>> index 32b35a0..9dda879 100644
>> --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
>> +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
>> @@ -21,6 +21,8 @@ Optional SoC Specific Properties:
>> - t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
>> where an extra byte is returned by Read Multiple Block commands issued
>> to Type 5 tags.
>> +- crystal_27mhz: Set to specify that the input frequency to the trf7970a is 27.12MHz
>> +
>
> Can't you use 'clock-frequency = "27000000";'?
>
>>
>> Example (for ARM-based BeagleBone with TRF7970A on SPI1):
>>
>> @@ -43,6 +45,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
>> irq-status-read-quirk;
>> en2-rf-quirk;
>> t5t-rmb-extra-byte-quirk;
>> + crystal_27mhz;
>> status = "okay";
>> };
>> };
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/3] Bluetooth: btusb: Add out-of-band wakeup support
From: Brian Norris @ 2016-12-19 23:10 UTC (permalink / raw)
To: Rajat Jain
Cc: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev, devicetree, linux-bluetooth, linux-kernel, rajatxjain
In-Reply-To: <1481916604-114279-2-git-send-email-rajatja@google.com>
Hi Rajat,
On Fri, Dec 16, 2016 at 11:30:03AM -0800, Rajat Jain wrote:
> Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that
> can be connected to a gpio on the CPU side, and can be used to wakeup
> the host out-of-band. This can be useful in situations where the
> in-band wakeup is not possible or not preferable (e.g. the in-band
> wakeup may require the USB host controller to remain active, and
> hence consuming more system power during system sleep).
>
> The oob gpio interrupt to be used for wakeup on the CPU side, is
> read from the device tree node, (using standard interrupt descriptors).
> A devcie tree binding document is also added for the driver. The
> compatible string is in compliance with
> Documentation/devicetree/bindings/usb/usb-device.txt
>
> Signed-off-by: Rajat Jain <rajatja@google.com>
A few small comments below, but other than those, for the whole series:
Reviewed-by: Brian Norris <briannorris@chromium.org>
> ---
> v2: * Use interrupt-names ("wakeup") instead of assuming first interrupt.
> * Leave it on device tree to specify IRQ flags (level /edge triggered)
> * Mark the device as non wakeable on exit.
>
> Documentation/devicetree/bindings/net/btusb.txt | 40 ++++++++++++
> drivers/bluetooth/btusb.c | 84 +++++++++++++++++++++++++
> 2 files changed, 124 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/btusb.txt
>
> diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt
> new file mode 100644
> index 0000000..2c0355c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/btusb.txt
> @@ -0,0 +1,40 @@
> +Generic Bluetooth controller over USB (btusb driver)
> +---------------------------------------------------
> +
> +Required properties:
> +
> + - compatible : should comply with the format "usbVID,PID" specified in
> + Documentation/devicetree/bindings/usb/usb-device.txt
> + At the time of writing, the only OF supported devices
> + (more may be added later) are:
> +
> + "usb1286,204e" (Marvell 8997)
I don't know if anyone cares about these sort of organizational aspects,
but in patch 3 you're extending this binding with device-specific
Marvell bindings. Seems like it'd be good to have some clear way to
correlate those 2. e.g., add a reference to marvell-bt-sd8xxx.txt (or
marvell-bt-8xxx.txt, once you rename it) in patch 3.
> +
> +Optional properties:
> +
> + - interrupt-parent: phandle of the parent interrupt controller
> + - interrupt-names: (see below)
> + - interrupts : The interrupt specified by the name "wakeup" is the interrupt
> + that shall be used for out-of-band wake-on-bt. Driver will
> + request this interrupt for wakeup. During system suspend, the
> + irq will be enabled so that the bluetooth chip can wakeup host
> + platform out of band. During system resume, the irq will be
> + disabled to make sure unnecessary interrupt is not received.
> +
> +Example:
> +
> +Following example uses irq pin number 3 of gpio0 for out of band wake-on-bt:
> +
> +&usb_host1_ehci {
> + status = "okay";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mvl_bt1: bt@1 {
> + compatible = "usb1286,204e";
> + reg = <1>;
> + interrupt-parent = <&gpio0>;
> + interrupt-name = "wakeup";
> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> + };
> +};
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index ce22cef..beca4e9 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -24,6 +24,8 @@
> #include <linux/module.h>
> #include <linux/usb.h>
> #include <linux/firmware.h>
> +#include <linux/of_device.h>
> +#include <linux/of_irq.h>
> #include <asm/unaligned.h>
>
> #include <net/bluetooth/bluetooth.h>
> @@ -369,6 +371,7 @@ static const struct usb_device_id blacklist_table[] = {
> #define BTUSB_BOOTING 9
> #define BTUSB_RESET_RESUME 10
> #define BTUSB_DIAG_RUNNING 11
> +#define BTUSB_OOB_WAKE_DISABLED 12
>
> struct btusb_data {
> struct hci_dev *hdev;
> @@ -416,6 +419,8 @@ struct btusb_data {
> int (*recv_bulk)(struct btusb_data *data, void *buffer, int count);
>
> int (*setup_on_usb)(struct hci_dev *hdev);
> +
> + int oob_wake_irq; /* irq for out-of-band wake-on-bt */
> };
>
> static inline void btusb_free_frags(struct btusb_data *data)
> @@ -2728,6 +2733,65 @@ static int btusb_bcm_set_diag(struct hci_dev *hdev, bool enable)
> }
> #endif
>
> +#ifdef CONFIG_PM
> +static irqreturn_t btusb_oob_wake_handler(int irq, void *priv)
> +{
> + struct btusb_data *data = priv;
> +
> + /* Disable only if not already disabled (keep it balanced) */
> + if (!test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
> + disable_irq_nosync(irq);
> + disable_irq_wake(irq);
> + }
> + pm_wakeup_event(&data->udev->dev, 0);
> + return IRQ_HANDLED;
> +}
> +
> +static const struct of_device_id btusb_match_table[] = {
> + { .compatible = "usb1286,204e" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, btusb_match_table);
You define a match table here, but you also define essentially same
table for Marvell-specific additions in patch 3. It looks like maybe
it's legal to have more than one OF table in a module? But it seems like
it would get confusing, besides being somewhat strange to maintain. It
might also produce duplicate 'modinfo' output.
If you really want to independently opt into device-tree-specified
interrupts vs. Marvell-specific interrrupt configuration, then you
should probably just merge the latter into the former table, and
implement a Marvell/GPIO flag to stick in the .data field of this table.
Or it might be fine to drop one or both "match" checks. Particularly for
the Marvell-specific stuff, it's probably fair just to check if it has
an ->of_node and if 'id->driver_info & BTUSB_MARVELL'. Any other Marvell
device-specific quirks could probably be keyed off of the
(weirdly-named?) blacklist_table[], which already matches PID/VID.
> +
> +/* Use an oob wakeup pin? */
> +static int btusb_config_oob_wake(struct hci_dev *hdev)
> +{
> + struct btusb_data *data = hci_get_drvdata(hdev);
> + struct device *dev = &data->udev->dev;
> + int irq, ret;
> +
> + if (!of_match_device(btusb_match_table, dev))
> + return 0;
> +
> + /* Move on if no IRQ specified */
> + irq = of_irq_get_byname(dev->of_node, "wakeup");
> + if (irq <= 0) {
> + bt_dev_dbg(hdev, "%s: no OOB Wakeup IRQ in DT", __func__);
> + return 0;
> + }
> +
> + set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
> +
> + ret = devm_request_irq(&hdev->dev, irq, btusb_oob_wake_handler,
> + 0, "OOB Wake-on-BT", data);
> + if (ret) {
> + bt_dev_err(hdev, "%s: IRQ request failed", __func__);
> + return ret;
> + }
> +
> + ret = device_init_wakeup(dev, true);
> + if (ret) {
> + bt_dev_err(hdev, "%s: failed to init_wakeup\n", __func__);
> + return ret;
> + }
> +
> + data->oob_wake_irq = irq;
> + disable_irq(irq);
> + bt_dev_info(hdev, "OOB Wake-on-BT configured at IRQ %u\n", irq);
> + return 0;
> +}
> +#endif
> +
> static int btusb_probe(struct usb_interface *intf,
> const struct usb_device_id *id)
> {
> @@ -2849,6 +2913,11 @@ static int btusb_probe(struct usb_interface *intf,
> hdev->send = btusb_send_frame;
> hdev->notify = btusb_notify;
>
> +#ifdef CONFIG_PM
> + err = btusb_config_oob_wake(hdev);
> + if (err)
> + goto out_free_dev;
> +#endif
> if (id->driver_info & BTUSB_CW6622)
> set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
>
> @@ -3061,6 +3130,9 @@ static void btusb_disconnect(struct usb_interface *intf)
> usb_driver_release_interface(&btusb_driver, data->isoc);
> }
>
> + if (data->oob_wake_irq)
> + device_init_wakeup(&data->udev->dev, false);
> +
> hci_free_dev(hdev);
> }
>
> @@ -3089,6 +3161,12 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
> btusb_stop_traffic(data);
> usb_kill_anchored_urbs(&data->tx_anchor);
>
> + if (data->oob_wake_irq && device_may_wakeup(&data->udev->dev)) {
> + clear_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
> + enable_irq_wake(data->oob_wake_irq);
> + enable_irq(data->oob_wake_irq);
> + }
> +
> /* Optionally request a device reset on resume, but only when
> * wakeups are disabled. If wakeups are enabled we assume the
> * device will stay powered up throughout suspend.
> @@ -3126,6 +3204,12 @@ static int btusb_resume(struct usb_interface *intf)
> if (--data->suspend_count)
Not related to your patch exactly, but isn't this 'suspend_count' stuff
useless? I'd send a patch, but it might conflict with yours. Just wanted
to note it and see if I'm crazy...
Brian
> return 0;
>
> + /* Disable only if not already disabled (keep it balanced) */
> + if (!test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
> + disable_irq(data->oob_wake_irq);
> + disable_irq_wake(data->oob_wake_irq);
> + }
> +
> if (!test_bit(HCI_RUNNING, &hdev->flags))
> goto done;
>
> --
> 2.8.0.rc3.226.g39d4020
>
^ permalink raw reply
* Re: [PATCHv2 2/8] dt-bindings: document the STM32 RTC bindings
From: Rob Herring @ 2016-12-19 23:10 UTC (permalink / raw)
To: Amelie Delaunay
Cc: Alessandro Zummo, Alexandre Belloni, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Gabriel Fernandez
In-Reply-To: <1481878257-29163-3-git-send-email-amelie.delaunay-qxv4g6HH51o@public.gmane.org>
On Fri, Dec 16, 2016 at 09:50:51AM +0100, Amelie Delaunay wrote:
> This patch adds documentation of device tree bindings for the STM32 RTC.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay-qxv4g6HH51o@public.gmane.org>
> ---
> .../devicetree/bindings/rtc/st,stm32-rtc.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 1/2] document: dt: add binding for Hi3660 SoC
From: Rob Herring @ 2016-12-19 23:09 UTC (permalink / raw)
To: Chen Feng
Cc: xuwei5, mark.rutland, devicetree, linux-kernel, xuyiping,
suzhuangluan, haojian.zhuang, guodong.xu, dan.zhao, saberlily.xia,
puck.chen, oliver.fu, xuhongtao8
In-Reply-To: <1481874627-79760-1-git-send-email-puck.chen@hisilicon.com>
On Fri, Dec 16, 2016 at 03:50:26PM +0800, Chen Feng wrote:
> Add binding for hisilicon Hi3660 SoC and HiKey960 Board.
>
> Signed-off-by: Chen Feng <puck.chen@hisilicon.com>
> ---
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 4 ++++
> 1 file changed, 4 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] Docs: dt: Be explicit and consistent in reference to IOMMU specifiers
From: Rob Herring @ 2016-12-19 23:06 UTC (permalink / raw)
To: Stuart Yoder
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
will.deacon-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <1481847373-2602-1-git-send-email-stuart.yoder-3arQi8VN3Tc@public.gmane.org>
On Thu, Dec 15, 2016 at 06:16:13PM -0600, Stuart Yoder wrote:
> The generic IOMMU binding says that the meaning of an 'IOMMU specifier'
> is defined by the binding of a specific SMMU. The ARM SMMU binding
> never explicitly uses the term 'specifier' at all. Update implicit
> references to use the explicit term.
>
> In the iommu-map binding change references to iommu-specifier to
> "IOMMU specifier" so we are 100% consistent everywhere with terminology
> and capitalization.
>
> Signed-off-by: Stuart Yoder <stuart.yoder-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.txt | 10 +++++-----
> Documentation/devicetree/bindings/pci/pci-iommu.txt | 6 +++---
> 2 files changed, 8 insertions(+), 8 deletions(-)
Applied, thanks.
Rob
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index e862d148..6cdf32d 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -36,15 +36,15 @@ conditions.
> combined interrupt, it must be listed multiple times.
>
> - #iommu-cells : See Documentation/devicetree/bindings/iommu/iommu.txt
> - for details. With a value of 1, each "iommus" entry
> + for details. With a value of 1, each IOMMU specifier
> represents a distinct stream ID emitted by that device
> into the relevant SMMU.
>
> SMMUs with stream matching support and complex masters
> - may use a value of 2, where the second cell represents
> - an SMR mask to combine with the ID in the first cell.
> - Care must be taken to ensure the set of matched IDs
> - does not result in conflicts.
> + may use a value of 2, where the second cell of the
> + IOMMU specifier represents an SMR mask to combine with
> + the ID in the first cell. Care must be taken to ensure
> + the set of matched IDs does not result in conflicts.
>
> ** System MMU optional properties:
>
> diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> index 56c8296..0def586 100644
> --- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> @@ -32,17 +32,17 @@ PCI root complex
> Optional properties
> -------------------
>
> -- iommu-map: Maps a Requester ID to an IOMMU and associated iommu-specifier
> +- iommu-map: Maps a Requester ID to an IOMMU and associated IOMMU specifier
> data.
>
> The property is an arbitrary number of tuples of
> (rid-base,iommu,iommu-base,length).
>
> Any RID r in the interval [rid-base, rid-base + length) is associated with
> - the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
> + the listed IOMMU, with the IOMMU specifier (r - rid-base + iommu-base).
>
> - iommu-map-mask: A mask to be applied to each Requester ID prior to being
> - mapped to an iommu-specifier per the iommu-map property.
> + mapped to an IOMMU specifier per the iommu-map property.
>
>
> Example (1)
> --
> 1.9.0
>
^ permalink raw reply
* Re: [PATCH 1/3 v2] iio: adc: add device tree bindings for Qualcomm PM8xxx ADCs
From: Rob Herring @ 2016-12-19 22:50 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Ivan T . Ivanov, Andy Gross,
Bjorn Andersson, Stephen Boyd, Srinivas Kandagatla
In-Reply-To: <1481842089-13999-1-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Dec 15, 2016 at 11:48:09PM +0100, Linus Walleij wrote:
> This adds the device tree bindings for the Qualcomm PM8xxx
> ADCs. This is based on the existing DT bindings for the
> SPMI ADC so there are hopefully no controversial features.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Ivan T. Ivanov <iivanov.xz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Andy Gross <andy.gross-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> ChangeLog v1->v2:
> - Spelling fixes
> ---
> .../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 160 +++++++++++++++++++++
> 1 file changed, 160 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> new file mode 100644
> index 000000000000..3c6bca5b4edf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> @@ -0,0 +1,160 @@
> +Qualcomm's PM8xxx voltage XOADC
> +
> +The Qualcomm PM8xxx PMICs contain a HK/XO ADC (Housekeeping/Crystal
> +oscillator ADC) encompassing PM8018, PM8038, PM8058, PM8917 and PM8921.
> +
> +Required properties:
> +
> +- compatible: should be one of:
> + "qcom,pm8018-adc"
> + "qcom,pm8038-adc"
> + "qcom,pm8058-adc"
> + "qcom,pm8917-adc"
> + "qcom,pm8921-adc"
> +
> +- reg: should contain the ADC base address in the PMIC, typically
> + 0x197.
> +
> +The following required properties are standard for IO channels, see
> +iio-bindings.txt for more details:
> +
> +- #address-cells: should be set to <1>
> +
> +- #size-cells: should be set to <0>
> +
> +- #io-channel-cells: should be set to <1>
> +
> +- interrupts: should refer to the parent PMIC interrupt controller
> + and reference the proper ADC interrupt.
> +
> +Required subnodes:
> +
> +The ADC channels are configured as subnodes of the ADC. Since some of
> +them are used for calibrating the ADC, these nodes are compulsory:
> +
> +ref_625mv {
ref@c
> + reg = <0x0c>;
> +};
> +
> +ref_1250mv {
> + reg = <0x0d>;
> +};
> +
> +ref_muxoff {
> + reg = <0x0f>;
> +};
> +
> +These three nodes are used for absolute and ratiometric calibration
> +and only need to have these reg values: they are by hardware definition
> +1:1 ratio converters that sample 625, 1250 and 0 milliV and create
> +an interpolation calibration for all other ADCs.
> +
> +Optional subnodes: any channels other than channel 0x0c, 0x0d and
> +0x0f are optional.
> +
> +Required channel node properties:
> +
> +- reg: should contain the hardware channel number in the range
> + 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
> +
> +Optional channel node properties:
> +
> +- qcom,decimation:
> + Value type: <u32>
> + Definition: This parameter is used to decrease the ADC sampling rate.
> + Quicker measurements can be made by reducing the decimation ratio.
> + Valid values are 512, 1024, 2048, 4096.
> + If the property is not found, a default value of 512 will be used.
> +
> +- qcom,ratiometric:
> + Value type: <empty>
> + Definition: Channel calibration type. If this property is specified
> + VADC will use the VDD reference (1.8V) and GND for channel
> + calibration. If the property is not found, the channel will be
> + calibrated with the 0.625V and 1.25V reference channels, also
> + known as an absolute calibration.
> +
> +- qcom,ratiometric-ref:
> + Value type: <u32>
> + Definition: The reference voltage pair when using ratiometric
> + calibration:
> + 0 = XO_IN/XOADC_GND
> + 1 = PMIC_IN/XOADC_GND
> + 2 = PMIC_IN/BMS_CSP
> + 3 (invalid)
> + 4 = XOADC_GND/XOADC_GND
> + 5 = XOADC_VREF/XOADC_GND
> +
> +Example:
> +
> +xoadc: xoadc@197 {
> + compatible = "qcom,pm8058-adc";
> + reg = <0x197>;
> + interrupt-parent = <&pm8058>;
> + interrupts = <76 1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #io-channel-cells = <1>;
> +
> + vcoin {
> + reg = <0x00>;
If you have a reg property, then you should have a unit address on all
of these.
These should really all be something like adc-channel@... Not sure if we
have a standard node name for ADC channels. Or don't put any of this in
DT.
> + };
> + vbat {
> + reg = <0x01>;
> + };
> + dcin {
> + reg = <0x02>;
> + };
> + ichg {
> + reg = <0x03>;
> + };
> + vph_pwr {
> + reg = <0x04>;
> + };
> + mpp5 {
> + reg = <0x05>;
> + };
> + mpp6 {
> + reg = <0x06>;
> + };
> + mpp7 {
> + reg = <0x07>;
> + };
> + mpp8 {
> + reg = <0x08>;
> + };
> + mpp9 {
> + reg = <0x09>;
> + };
> + usb_vbus {
> + reg = <0x0a>;
> + };
> + die_temp {
> + reg = <0x0b>;
> + };
> + ref_625mv {
> + reg = <0x0c>;
> + };
> + ref_1250mv {
> + reg = <0x0d>;
> + };
> + ref_325mv {
> + reg = <0x0e>;
> + };
> + ref_muxoff {
> + reg = <0x0f>;
> + };
> +};
^ permalink raw reply
* Re: [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Rob Herring @ 2016-12-19 22:35 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo,
mark.rutland, netdev, devicetree, linux-kernel, mgreer, justin
In-Reply-To: <1481841044-4314-2-git-send-email-glansberry@gmail.com>
On Thu, Dec 15, 2016 at 05:30:43PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry <geoff@kuvee.com>
>
> ---
> Documentation/devicetree/bindings/net/nfc/trf7970a.txt | 2 ++
> drivers/nfc/trf7970a.c | 13 ++++++++++++-
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> index 9dda879..208f045 100644
> --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> @@ -21,6 +21,7 @@ Optional SoC Specific Properties:
> - t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
> where an extra byte is returned by Read Multiple Block commands issued
> to Type 5 tags.
> +- vdd_io_1v8: Set to specify that the trf7970a io voltage should be set to 1.8V
Use the regulator binding and provide a fixed 1.8V supply.
> - crystal_27mhz: Set to specify that the input frequency to the trf7970a is 27.12MHz
>
>
> @@ -45,6 +46,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
> irq-status-read-quirk;
> en2-rf-quirk;
> t5t-rmb-extra-byte-quirk;
> + vdd_io_1v8;
> crystal_27mhz;
> status = "okay";
> };
^ permalink raw reply
* Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Rob Herring @ 2016-12-19 22:31 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo,
mark.rutland, netdev, devicetree, linux-kernel, mgreer, justin
In-Reply-To: <1481841044-4314-1-git-send-email-glansberry@gmail.com>
On Thu, Dec 15, 2016 at 05:30:42PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry <geoff@kuvee.com>
>
> ---
> .../devicetree/bindings/net/nfc/trf7970a.txt | 3 ++
> drivers/nfc/trf7970a.c | 42 ++++++++++++++++------
> 2 files changed, 34 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> index 32b35a0..9dda879 100644
> --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> @@ -21,6 +21,8 @@ Optional SoC Specific Properties:
> - t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
> where an extra byte is returned by Read Multiple Block commands issued
> to Type 5 tags.
> +- crystal_27mhz: Set to specify that the input frequency to the trf7970a is 27.12MHz
> +
Can't you use 'clock-frequency = "27000000";'?
>
> Example (for ARM-based BeagleBone with TRF7970A on SPI1):
>
> @@ -43,6 +45,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
> irq-status-read-quirk;
> en2-rf-quirk;
> t5t-rmb-extra-byte-quirk;
> + crystal_27mhz;
> status = "okay";
> };
> };
^ permalink raw reply
* Re: [PATCH V5 2/8] Documentation: devicetree: thermal: da9062/61 TJUNC temperature binding
From: Rob Herring @ 2016-12-19 22:28 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, Eduardo Valentin, LINUX-KERNEL, LINUX-PM,
Mark Rutland, Zhang Rui, Dmitry Torokhov, Guenter Roeck,
LINUX-INPUT, LINUX-WATCHDOG, Lee Jones, Liam Girdwood,
Lukasz Luba, Mark Brown, Support Opensource, Wim Van Sebroeck
In-Reply-To: <ae903f7c3c6325420b90c7f691655d902d137d1f.1481828921.git.stwiss.opensource@diasemi.com>
On Thu, Dec 15, 2016 at 07:08:39PM +0000, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> Device tree binding information for DA9062 and DA9061 thermal junction
> temperature monitor.
>
> Binding descriptions for the DA9061 and DA9062 thermal TJUNC supervisor
> device driver, using a single THERMAL_TRIP_HOT trip-wire and allowing for
> a configurable polling period for over-temperature polling.
>
> This patch also adds two examples, one for DA9062 and one for DA9061. The
> DA9061 example uses a fall-back compatible string for the DA9062.
>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
>
> ---
> This patch applies against linux-next and v4.9
>
> v4 -> v5
> - Rebased from v4.8 to v4.9
> - Updates from comments by Eduardo Valentin
> - Replace vendor defined dlg,tjunc-temp-polling-period-ms with standard
> thermal core polling-delay-passive as part of the device tree
> initialisation
> - Remove Acked-by Rob Herring
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 2/9] doc: DT: venus: binding document for Qualcomm video driver
From: Rob Herring @ 2016-12-19 22:21 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Mauro Carvalho Chehab, Hans Verkuil, Andy Gross, Bjorn Andersson,
Stephen Boyd, Srinivas Kandagatla, linux-media, linux-kernel,
linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <1481822544-29900-3-git-send-email-stanimir.varbanov@linaro.org>
On Thu, Dec 15, 2016 at 07:22:17PM +0200, Stanimir Varbanov wrote:
> Add binding document for Venus video encoder/decoder driver
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
> ---
> .../devicetree/bindings/media/qcom,venus.txt | 68 ++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] Documentation: ehci-omap: remove the unnecessary newline
From: Rob Herring @ 2016-12-19 22:20 UTC (permalink / raw)
To: yegorslists; +Cc: linux-kernel, devicetree, mark.rutland
In-Reply-To: <1481817370-28242-2-git-send-email-yegorslists@googlemail.com>
On Thu, Dec 15, 2016 at 04:56:10PM +0100, yegorslists@googlemail.com wrote:
> From: Yegor Yefremov <yegorslists@googlemail.com>
>
> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
> ---
> Documentation/devicetree/bindings/usb/ehci-omap.txt | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: omap-usb-host: fix OMAP OHCI/EHCI file names
From: Rob Herring @ 2016-12-19 22:19 UTC (permalink / raw)
To: yegorslists; +Cc: linux-kernel, devicetree, mark.rutland
In-Reply-To: <1481817370-28242-1-git-send-email-yegorslists@googlemail.com>
On Thu, Dec 15, 2016 at 04:56:09PM +0100, yegorslists@googlemail.com wrote:
> From: Yegor Yefremov <yegorslists@googlemail.com>
>
> OMAP related files are actually named ehci-omap.txt and ohci-omap3.txt.
>
> Also add full path to ohci-omap3.txt.
>
> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
> ---
> Documentation/devicetree/bindings/mfd/omap-usb-host.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH v3] power: supply: bq24735-charger: optionally poll the ac-detect gpio
From: Rob Herring @ 2016-12-19 22:16 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Sebastian Reichel, Mark Rutland, linux-pm,
devicetree
In-Reply-To: <1481794126-5670-1-git-send-email-peda@axentia.se>
On Thu, Dec 15, 2016 at 10:28:46AM +0100, Peter Rosin wrote:
> If the ac-detect gpio does not support interrupts, provide a fallback
> to poll the gpio at a configurable interval.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
>
> v2 -> v3 changes:
> - use device_property_read_u32 instead of of_property_read_u32
>
> v1 -> v2 changes:
> - use poll-interval instead of ti,poll-interval-ms in the bindings
>
> Cheers,
> peda
>
> .../bindings/power/supply/ti,bq24735.txt | 2 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/power/supply/bq24735-charger.c | 49 +++++++++++++++++++---
> 2 files changed, 46 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: Document the hi3660 clock bindings
From: Rob Herring @ 2016-12-19 22:15 UTC (permalink / raw)
To: Zhangfei Gao
Cc: Stephen Boyd, Arnd Bergmann,
haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A, guodong Xu,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481781493-6188-2-git-send-email-zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Dec 15, 2016 at 01:58:12PM +0800, Zhangfei Gao wrote:
> Add DT bindings documentation for hi3660 SoC clock.
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/clock/hi3660-clock.txt | 42 ++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/hi3660-clock.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/hi3660-clock.txt b/Documentation/devicetree/bindings/clock/hi3660-clock.txt
> new file mode 100644
> index 0000000..7296fd7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/hi3660-clock.txt
> @@ -0,0 +1,42 @@
> +* Hisilicon Hi3660 Clock Controller
> +
> +The Hi3660 clock controller generates and supplies clock to various
> +controllers within the Hi3660 SoC.
> +
> +Required Properties:
> +
> +- compatible: the compatible should be one of the following strings to
> + indicate the clock controller functionality.
> +
> + - "hisilicon,hi3660-crgctrl"
> + - "hisilicon,hi3660-pctrl"
> + - "hisilicon,hi3660-pmuctrl"
> + - "hisilicon,hi3660-sctrl"
> + - "hisilicon,hi3660-iomcu"
> +
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +
> +- #clock-cells: should be 1.
> +
> +Each clock is assigned an identifier and client nodes use this identifier
> +to specify the clock which they consume.
> +
> +All these identifier could be found in <dt-bindings/clock/hi3660-clock.h>.
> +
> +Examples:
> + crg_ctrl: crg_ctrl@fff35000 {
clock-controller@...
> + compatible = "hisilicon,hi3660-crgctrl", "syscon";
> + reg = <0x0 0xfff35000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + uart0: uart@fdf02000 {
serial@...
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0 0xfdf02000 0x0 0x1000>;
> + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&crg_ctrl HI3660_CLK_MUX_UART0>,
> + <&crg_ctrl HI3660_PCLK>;
> + clock-names = "uartclk", "apb_pclk";
> + status = "disabled";
> + };
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/6] watchdog: ts4600: add driver for TS-4600 watchdog
From: Rob Herring @ 2016-12-19 22:13 UTC (permalink / raw)
To: Sebastien Bourdelin
Cc: linux-kernel, linux-watchdog, linux-arm-kernel, devicetree,
kernel, mark, kris, horms+renesas, treding, jonathanh, f.fainelli,
fabio.estevam, kernel, shawnguo, linux, linux, wim, mark.rutland,
damien.riegel, lucile.quirion, olof, arnd, suzuki.poulose,
linus.walleij, will.deacon, yamada.masahiro
In-Reply-To: <20161214231237.17496-7-sebastien.bourdelin@savoirfairelinux.com>
On Wed, Dec 14, 2016 at 06:12:36PM -0500, Sebastien Bourdelin wrote:
> This watchdog is instantiated in a FPGA and can only be access using a
> GPIOs bit-banged bus, called the NBUS by Technologic Systems.
> The watchdog is made of only one register, called the feed register.
> Writing to this register will re-arm the watchdog for a given time (and
> enable it if it was disable). It can be disabled by writing a special
> value into it.
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
> ---
> .../devicetree/bindings/watchdog/ts4600-wdt.txt | 16 ++
> arch/arm/boot/dts/imx28-ts4600-common.dtsi | 5 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/watchdog/Kconfig | 10 +
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/ts4600_wdt.c | 213 +++++++++++++++++++++
> 5 files changed, 245 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
> create mode 100644 drivers/watchdog/ts4600_wdt.c
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: bus: Add documentation for the Technologic Systems NBUS
From: Rob Herring @ 2016-12-19 22:12 UTC (permalink / raw)
To: Sebastien Bourdelin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
kernel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
mark-L1vi/lXTdtvnC/t2CciAbw, kris-L1vi/lXTdtvnC/t2CciAbw,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
treding-DDmLM1+adcrQT0dZR+AlfA, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, fabio.estevam-3arQi8VN3Tc,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-0h96xk9xTtrk1uMJSBkQmQ,
wim-IQzOog9fTRqzQB+pC5nmwQ, mark.rutland-5wv7dgnIgG8,
damien.riegel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
lucile.quirion-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
olof-nZhT3qVonbNeoWH0uzbU5w, arnd-r2nGTMty4D4,
suzuki.poulose-5wv7dgnIgG8, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
will.deacon-5wv7dgnIgG8, yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A
In-Reply-To: <20161214231237.17496-4-sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
On Wed, Dec 14, 2016 at 06:12:33PM -0500, Sebastien Bourdelin wrote:
> Add binding documentation for the Technologic Systems NBUS that is used
> to interface with peripherals in the FPGA of the TS-4600 SoM.
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
> ---
> Documentation/devicetree/bindings/bus/ts-nbus.txt | 50 +++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/ts-nbus.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/ts-nbus.txt b/Documentation/devicetree/bindings/bus/ts-nbus.txt
> new file mode 100644
> index 0000000..2f777ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/ts-nbus.txt
> @@ -0,0 +1,50 @@
> +Technologic Systems NBUS
> +
> +The NBUS is a bus used to interface with peripherals in the Technologic
> +Systems FPGA on the TS-4600 SoM.
> +
> +Required properties :
> + - compatible : "technologic,ts-nbus", "simple-bus"
> + - #address-cells : must be 1
> + - #size-cells : must be 0
> + - pws : The PWM pin connected to the clock line on the FPGA
Using PWM binding?
> + - data-gpios : The GPIO pin connected to the data line on the FPGA
> + - csn-gpios : The GPIO pin connected to the csn line on the FPGA
> + - txrx-gpios : The GPIO pin connected to the txrx line on the FPGA
> + - strobe-gpios : The GPIO pin connected to the stobe line on the FPGA
> + - ale-gpios : The GPIO pin connected to the ale line on the FPGA
> + - rdy-gpios : The GPIO pin connected to the rdy line on the FPGA
These all need vendor prefix.
This is not any sort of standard bus?
> +
> +Child nodes:
> +
> +The NBUS node can contain zero or more child nodes representing peripherals
> +on the bus.
> +
> +Example:
> +
> + nbus {
> + compatible = "technologic,ts-nbus", "simple-bus";
I don't think simple-bus is really valid here. Don't you need the nbus
driver before the devices are usable?
> + pinctrl-0 = <&nbus_pins>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pwms = <&pwm 2 83>;
> + data-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH
> + &gpio0 1 GPIO_ACTIVE_HIGH
> + &gpio0 2 GPIO_ACTIVE_HIGH
> + &gpio0 3 GPIO_ACTIVE_HIGH
> + &gpio0 4 GPIO_ACTIVE_HIGH
> + &gpio0 5 GPIO_ACTIVE_HIGH
> + &gpio0 6 GPIO_ACTIVE_HIGH
> + &gpio0 7 GPIO_ACTIVE_HIGH>;
> + csn-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
> + txrx-gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
> + strobe-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
> + ale-gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
> + rdy-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
> +
> + wdt@2a {
watchdog@...
> + compatible = "...";
> +
> + /* ... */
> + };
> + };
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/6] of: documentation: add bindings documentation for TS-4600
From: Rob Herring @ 2016-12-19 22:05 UTC (permalink / raw)
To: Sebastien Bourdelin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
kernel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
mark-L1vi/lXTdtvnC/t2CciAbw, kris-L1vi/lXTdtvnC/t2CciAbw,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
treding-DDmLM1+adcrQT0dZR+AlfA, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, fabio.estevam-3arQi8VN3Tc,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-0h96xk9xTtrk1uMJSBkQmQ,
wim-IQzOog9fTRqzQB+pC5nmwQ, mark.rutland-5wv7dgnIgG8,
damien.riegel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
lucile.quirion-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
olof-nZhT3qVonbNeoWH0uzbU5w, arnd-r2nGTMty4D4,
suzuki.poulose-5wv7dgnIgG8, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
will.deacon-5wv7dgnIgG8, yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A
In-Reply-To: <20161214231237.17496-2-sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
On Wed, Dec 14, 2016 at 06:12:31PM -0500, Sebastien Bourdelin wrote:
> This adds the documentation for the TS-4600 by Technologic Systems.
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/technologic.txt | 5 +++++
> 1 file changed, 5 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] Bluetooth: btusb: Configure Marvel to use one of the pins for oob wakeup
From: Rob Herring @ 2016-12-19 22:04 UTC (permalink / raw)
To: Rajat Jain
Cc: Mark Rutland, Marcel Holtmann, Gustavo Padovan, Johan Hedberg,
Amitkumar Karwar, Wei-Ning Huang, Xinming Hu, netdev, devicetree,
linux-bluetooth, Brian Norris, rajatxjain
In-Reply-To: <1481742779-15105-3-git-send-email-rajatja@google.com>
On Wed, Dec 14, 2016 at 11:12:59AM -0800, Rajat Jain wrote:
> The Marvell devices may have many gpio pins, and hence for wakeup
> on these out-of-band pins, the chip needs to be told which pin is
> to be used for wakeup, using an hci command.
>
> Thus, we read the pin number etc from the device tree node and send
> a command to the chip.
>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> ---
> Note that while I would have liked to name the compatible string as more
> like "marvell, usb8997-bt", the devicetrees/bindings/usb/usb-device.txt
> requires the compatible property to be of the form "usbVID,PID".
>
> .../{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} | 25 ++++++++-
Acked-by: Rob Herring <robh@kernel.org>
> drivers/bluetooth/btusb.c | 59 ++++++++++++++++++++++
> 2 files changed, 82 insertions(+), 2 deletions(-)
> rename Documentation/devicetree/bindings/net/{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} (76%)
^ permalink raw reply
* Re: [PATCH v3 1/2] iio: adc: hx711: Add DT binding for avia,hx711
From: Rob Herring @ 2016-12-19 22:01 UTC (permalink / raw)
To: Andreas Klinger
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg
In-Reply-To: <20161214161640.GA13885@andreas>
On Wed, Dec 14, 2016 at 05:16:40PM +0100, Andreas Klinger wrote:
> Add DT bindings for avia,hx711
> Add vendor avia to vendor list
>
> Signed-off-by: Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>
> ---
> Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 16 ++++++++++++++++
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 2 files changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
From: Jonathan Cameron @ 2016-12-19 20:49 UTC (permalink / raw)
To: Andreas Klinger, devicetree, linux-iio
Cc: linux-kernel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, knaack.h, lars, pmeerw
In-Reply-To: <20161214161740.GA13896@andreas>
On 14/12/16 16:17, Andreas Klinger wrote:
> This is the IIO driver for AVIA HX711 ADC which ist mostly used in weighting
> cells.
>
> The protocol is quite simple and using GPIOs:
> One GPIO is used as clock (SCK) while another GPIO is read (DOUT)
Youch. Controlling the next conversion via the number of clocks is hideous!
Oh well, guess it's one solution that limits the number of wires needed.
Still not as hideous as some ;) (sht15 I'm looking at you :)
Few comments inline.
Jonathan
>
> The raw value read from the chip is delivered.
> To get a weight one needs to subtract the zero offset and scale it.
>
> Signed-off-by: Andreas Klinger <ak@it-klinger.de>
> ---
> drivers/iio/adc/Kconfig | 18 +++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/hx711.c | 292 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 311 insertions(+)
> create mode 100644 drivers/iio/adc/hx711.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 932de1f9d1e7..918f582288c9 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -205,6 +205,24 @@ config HI8435
> This driver can also be built as a module. If so, the module will be
> called hi8435.
>
> +config HX711
> + tristate "AVIA HX711 ADC for weight cells"
> + depends on GPIOLIB
> + help
> + If you say yes here you get support for AVIA HX711 ADC which is used
> + for weight cells
Typically just called weigh cells rather than weight cells.
One of those ugly bits of English.
> +
> + This driver uses two GPIOs, one for setting the clock and the other
> + one for getting the data
This driver uses two GPIOs, one acts as the clock and controls the channel
selection and gain, the other is used for the measurement data
(or something like that).
> +
> + Currently the raw value is read from the chip and delivered.
> + For getting an actual weight one needs to subtract the
To get an actual weight...
> + zero offset and multiply by a scale factor.
> + This should be done in userspace.
> +
> + This driver can also be built as a module. If so, the module will be
> + called hx711.
> +
> config INA2XX_ADC
> tristate "Texas Instruments INA2xx Power Monitors IIO driver"
> depends on I2C && !SENSORS_INA2XX
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index b1aa456e6af3..d46e289900ef 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
> obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
> obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
> obj-$(CONFIG_HI8435) += hi8435.o
> +obj-$(CONFIG_HX711) += hx711.o
> obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
> obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
> obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
> new file mode 100644
> index 000000000000..700281932ff0
> --- /dev/null
> +++ b/drivers/iio/adc/hx711.c
> @@ -0,0 +1,292 @@
> +/*
> + * HX711: analog to digital converter for weight sensor module
> + *
> + * Copyright (c) 2016 Andreas Klinger <ak@it-klinger.de>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
No need for this blank line.
> + */
> +#include <linux/err.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/slab.h>
> +#include <linux/sched.h>
> +#include <linux/delay.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +
> +#define HX711_GAIN_32 2 /* gain = 32 for channel B */
> +#define HX711_GAIN_64 3 /* gain = 64 for channel A */
> +#define HX711_GAIN_128 1 /* gain = 128 for channel A */
> +
> +struct hx711_data {
> + struct device *dev;
> + struct gpio_desc *gpiod_sck;
> + struct gpio_desc *gpiod_dout;
> + int gain_pulse;
> + struct mutex lock;
> +};
> +
> +static int hx711_reset(struct hx711_data *hx711_data)
> +{
> + int i, val;
> +
> + val = gpiod_get_value(hx711_data->gpiod_dout);
> + if (val) {
> + gpiod_set_value(hx711_data->gpiod_sck, 1);
> + udelay(80);
a comment here on why 80 would be good (it's bigger than 60?)
> + gpiod_set_value(hx711_data->gpiod_sck, 0);
> +
> + for (i = 0; i < 1000; i++) {
> + val = gpiod_get_value(hx711_data->gpiod_dout);
> + if (!val)
> + break;
> + /* sleep at least 1 ms */
> + msleep(1);
> + }
> + }
> +
> + return val;
> +}
> +
> +static int hx711_cycle(struct hx711_data *hx711_data)
> +{
> + int val;
> +
/*
* if pre...
> + /* if preempted for more then 60us while SCK is high:
> + * hx711 is going in reset
> + * ==> measuring is false
> + */
> + preempt_disable();
> + gpiod_set_value(hx711_data->gpiod_sck, 1);
I'm reading the datasheet as suggesting you need to wait at least 0.1 microsecs
here...
> + val = gpiod_get_value(hx711_data->gpiod_dout);
> + gpiod_set_value(hx711_data->gpiod_sck, 0);
> + preempt_enable();
> +
> + return val;
> +}
> +
> +static int hx711_read(struct hx711_data *hx711_data)
> +{
> + int i, ret;
> + int value = 0;
> +
> + mutex_lock(&hx711_data->lock);
> +
> + if (hx711_reset(hx711_data)) {
> + dev_err(hx711_data->dev, "reset failed!");
> + mutex_unlock(&hx711_data->lock);
> + return -1;
> + }
> +
> + for (i = 0; i < 24; i++) {
> + value <<= 1;
> + ret = hx711_cycle(hx711_data);
> + if (ret)
> + value++;
> + }
> +
> + value ^= 0x800000;
> +
> + for (i = 0; i < hx711_data->gain_pulse; i++)
> + ret = hx711_cycle(hx711_data);
> +
> + mutex_unlock(&hx711_data->lock);
> +
> + return value;
> +}
> +
> +static int hx711_read_raw(struct iio_dev *iio_dev,
> + const struct iio_chan_spec *chan,
> + int *val, int *val2, long mask)
> +{
> + struct hx711_data *hx711_data = iio_priv(iio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + switch (chan->type) {
> + case IIO_VOLTAGE:
> + *val = hx711_read(hx711_data);
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static ssize_t hx711_gain_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct hx711_data *hx711_data = iio_priv(dev_to_iio_dev(dev));
> + int val;
> +
> + switch (hx711_data->gain_pulse) {
> + case HX711_GAIN_32:
> + val = 32;
> + break;
> + case HX711_GAIN_64:
> + val = 64;
> + break;
> + default:
> + val = 128;
> + }
> +
> + return sprintf(buf, "%d\n", val);
> +}
> +
> +static ssize_t hx711_gain_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t len)
> +{
> + struct hx711_data *hx711_data = iio_priv(dev_to_iio_dev(dev));
> + int ret, val;
> + int gain_save = hx711_data->gain_pulse;
> +
> + ret = kstrtoint((const char *) buf, 10, &val);
> + if (ret)
> + return -EINVAL;
> +
> + switch (val) {
> + case 32:
> + hx711_data->gain_pulse = HX711_GAIN_32;
> + break;
> + case 64:
> + hx711_data->gain_pulse = HX711_GAIN_64;
> + break;
> + case 128:
> + hx711_data->gain_pulse = HX711_GAIN_128;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + dev_dbg(hx711_data->dev, "gain_pulse: %d\n", hx711_data->gain_pulse);
> +
> + /* if gain has changed do a fake read for the new gain to be set
> + * for the next read
> + */
> + if (gain_save != hx711_data->gain_pulse)
> + hx711_read(hx711_data);
> +
> + return len;
> +}
> +
> +static IIO_DEVICE_ATTR(gain, S_IRUGO | S_IWUSR,
> + hx711_gain_show, hx711_gain_store, 0);
> +
> +static struct attribute *hx711_attributes[] = {
> + &iio_dev_attr_gain.dev_attr.attr,
> + NULL,
> +};
> +
As Lars suggested, please use standard ABI (easier if you use the info_mask
elements and do it through read raw...
> +static struct attribute_group hx711_attribute_group = {
> + .attrs = hx711_attributes,
> +};
> +
> +static const struct iio_info hx711_iio_info = {
> + .driver_module = THIS_MODULE,
> + .read_raw = hx711_read_raw,
> + .attrs = &hx711_attribute_group,
> +};
> +
> +static const struct iio_chan_spec hx711_chan_spec[] = {
> + {
new line here is slightly nicer to read.
>.type = IIO_VOLTAGE,
> + .info_mask_separate =
> + BIT(IIO_CHAN_INFO_RAW),
> + },
> +};
> +
> +static int hx711_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct hx711_data *hx711_data = NULL;
> + struct iio_dev *iio;
> + int ret = 0;
> +
> + iio = devm_iio_device_alloc(dev, sizeof(struct hx711_data));
> + if (!iio) {
> + dev_err(dev, "failed to allocate IIO device\n");
> + return -ENOMEM;
> + }
> +
> + hx711_data = iio_priv(iio);
> + hx711_data->dev = dev;
> +
> + mutex_init(&hx711_data->lock);
> +
> + hx711_data->gpiod_sck = devm_gpiod_get(dev, "sck", GPIOD_OUT_HIGH);
> + if (IS_ERR(hx711_data->gpiod_sck)) {
> + dev_err(dev, "failed to get sck-gpiod: err=%ld\n",
> + PTR_ERR(hx711_data->gpiod_sck));
> + return PTR_ERR(hx711_data->gpiod_sck);
> + }
> +
> + hx711_data->gpiod_dout = devm_gpiod_get(dev, "dout", GPIOD_OUT_HIGH);
If there is a reason for getting an input as an output then it wants a comment!
> + if (IS_ERR(hx711_data->gpiod_dout)) {
> + dev_err(dev, "failed to get dout-gpiod: err=%ld\n",
> + PTR_ERR(hx711_data->gpiod_dout));
> + return PTR_ERR(hx711_data->gpiod_dout);
> + }
> +
> + ret = gpiod_direction_input(hx711_data->gpiod_dout);
> + if (ret < 0) {
> + dev_err(hx711_data->dev, "gpiod_direction_input: %d\n", ret);
> + return ret;
> + }
> +
> + ret = gpiod_direction_output(hx711_data->gpiod_sck, 0);
Doesn't the flag above already mean we are in output mode for this pin?
> + if (ret < 0) {
> + dev_err(hx711_data->dev, "gpiod_direction_output: %d\n", ret);
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, iio);
> +
> + iio->name = pdev->name;
> + iio->dev.parent = &pdev->dev;
> + iio->info = &hx711_iio_info;
> + iio->modes = INDIO_DIRECT_MODE;
> + iio->channels = hx711_chan_spec;
> + iio->num_channels = ARRAY_SIZE(hx711_chan_spec);
> +
> + return devm_iio_device_register(dev, iio);
> +}
> +
> +static const struct of_device_id of_hx711_match[] = {
> + { .compatible = "avia,hx711", },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, of_hx711_match);
> +
> +static struct platform_driver hx711_driver = {
> + .probe = hx711_probe,
> + .driver = {
> + .name = "hx711-gpio",
> + .of_match_table = of_hx711_match,
> + },
> +};
> +
> +module_platform_driver(hx711_driver);
> +
> +MODULE_AUTHOR("Andreas Klinger <ak@it-klinger.de>");
> +MODULE_DESCRIPTION("HX711 bitbanging driver - ADC for weight cells");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:hx711-gpio");
> +
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox