* Re: [PATCH 1/2] xilinx_dma: Edit device tree bindings documentation
From: Laurent Pinchart @ 2016-12-14 19:56 UTC (permalink / raw)
To: Ramiro Oliveira
Cc: dmaengine, devicetree, linux-arm-kernel, linux-kernel, vinod.koul,
robh+dt, mark.rutland, michal.simek, soren.brinkmann,
appana.durga.rao, anuragku, dan.j.williams, CARLOS.PALMINHA
In-Reply-To: <78b8d3b8540a2310818cf0c5b05adbc29e067981.1481735244.git.roliveir@synopsys.com>
Hi Ramiro,
Thank you for the patch.
On Wednesday 14 Dec 2016 17:18:23 Ramiro Oliveira wrote:
> Add reset property documentation for Xilinx DMA
>
> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> ---
> Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt index
> a2b8bfa..7ebce72 100644
> --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> @@ -40,6 +40,10 @@ Required properties for VDMA:
> Optional properties:
> - xlnx,include-sg: Tells configured for Scatter-mode in
> the hardware.
> +- resets : Must contain an entry for each entry in reset-names.
> + See ../reset/reset.txt for details.
> +- reset-names : Must include the following entries:
> + - reset
If the IP core has a single reset, can't we omit the name ?
> Optional properties for AXI DMA:
> - xlnx,mcdma: Tells whether configured for multi-channel mode in the
> hardware. Optional properties for VDMA:
> @@ -83,6 +87,8 @@ axi_vdma_0: axivdma@40030000 {
> clocks = <&clk 0>, <&clk 1>, <&clk 2>, <&clk 3>, <&clk 4>;
> clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk",
> "m_axis_mm2s_aclk", "s_axis_s2mm_aclk";
> + resets = <&rst 2>;
> + reset-names = "reset";
> dma-channel@40030000 {
> compatible = "xlnx,axi-vdma-mm2s-channel";
> interrupts = < 0 54 4 >;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 3/3] Bluetooth: btusb: Configure Marvel to use one of the pins for oob wakeup
From: Rajat Jain @ 2016-12-14 19:12 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Brian Norris
Cc: Rajat Jain, rajatxjain-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1481742779-15105-1-git-send-email-rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
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-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
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 ++++++++-
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%)
diff --git a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
similarity index 76%
rename from Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
index 6a9a63c..471bef8 100644
--- a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997) bluetooth SDIO devices
+Marvell 8897/8997 (sd8897/sd8997) bluetooth devices (SDIO or USB based)
------
Required properties:
@@ -6,11 +6,13 @@ Required properties:
- compatible : should be one of the following:
* "marvell,sd8897-bt"
* "marvell,sd8997-bt"
+ * "usb1286,204e"
Optional properties:
- marvell,cal-data: Calibration data downloaded to the device during
initialization. This is an array of 28 values(u8).
+ This is only applicable to SDIO devices.
- marvell,wakeup-pin: It represents wakeup pin number of the bluetooth chip.
firmware will use the pin to wakeup host system (u16).
@@ -29,7 +31,9 @@ Example:
IRQ pin 119 is used as system wakeup source interrupt.
wakeup pin 13 and gap 100ms are configured so that firmware can wakeup host
using this device side pin and wakeup latency.
-calibration data is also available in below example.
+
+Example for SDIO device follows (calibration data is also available in
+below example).
&mmc3 {
status = "okay";
@@ -54,3 +58,20 @@ calibration data is also available in below example.
marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
};
};
+
+Example for USB device:
+
+&usb_host1_ohci {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mvl_bt1: bt@1 {
+ compatible = "usb1286,204e";
+ reg = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <119 IRQ_TYPE_LEVEL_LOW>;
+ marvell,wakeup-pin = /bits/ 16 <0x0d>;
+ marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
+ };
+};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 32a6f22..99d7f6d 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2343,6 +2343,58 @@ static int btusb_shutdown_intel(struct hci_dev *hdev)
return 0;
}
+#ifdef CONFIG_PM
+static const struct of_device_id mvl_oob_wake_match_table[] = {
+ { .compatible = "usb1286,204e" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, mvl_oob_wake_match_table);
+
+/* Configure an out-of-band gpio as wake-up pin, if specified in device tree */
+static int marvell_config_oob_wake(struct hci_dev *hdev)
+{
+ struct sk_buff *skb;
+ struct btusb_data *data = hci_get_drvdata(hdev);
+ struct device *dev = &data->udev->dev;
+ u16 pin, gap, opcode;
+ int ret;
+ u8 cmd[5];
+
+ if (!of_match_device(mvl_oob_wake_match_table, dev))
+ return 0;
+
+ if (of_property_read_u16(dev->of_node, "marvell,wakeup-pin", &pin) ||
+ of_property_read_u16(dev->of_node, "marvell,wakeup-gap-ms", &gap))
+ return -EINVAL;
+
+ /* Vendor specific command to configure a GPIO as wake-up pin */
+ opcode = hci_opcode_pack(0x3F, 0x59);
+ cmd[0] = opcode & 0xFF;
+ cmd[1] = opcode >> 8;
+ cmd[2] = 2; /* length of parameters that follow */
+ cmd[3] = pin;
+ cmd[4] = gap; /* time in ms, for which wakeup pin should be asserted */
+
+ skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
+ if (!skb) {
+ bt_dev_err(hdev, "%s: No memory\n", __func__);
+ return -ENOMEM;
+ }
+
+ memcpy(skb_put(skb, sizeof(cmd)), cmd, sizeof(cmd));
+ hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
+
+ ret = btusb_send_frame(hdev, skb);
+ if (ret) {
+ bt_dev_err(hdev, "%s: configuration failed\n", __func__);
+ kfree_skb(skb);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
static int btusb_set_bdaddr_marvell(struct hci_dev *hdev,
const bdaddr_t *bdaddr)
{
@@ -2917,6 +2969,13 @@ static int btusb_probe(struct usb_interface *intf,
err = btusb_config_oob_wake(hdev);
if (err)
goto out_free_dev;
+
+ /* Marvel devices may need a specific chip configuration */
+ if (id->driver_info & BTUSB_MARVELL && data->oob_wake_irq) {
+ err = marvell_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);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 2/3] Bluetooth: btusb: Add out-of-band wakeup support
From: Rajat Jain @ 2016-12-14 19:12 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Brian Norris
Cc: Rajat Jain, rajatxjain-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1481742779-15105-1-git-send-email-rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Some 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.
Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
Documentation/devicetree/bindings/net/btusb.txt | 38 ++++++++++++
drivers/bluetooth/btusb.c | 82 +++++++++++++++++++++++++
2 files changed, 120 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..bb27f92
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -0,0 +1,38 @@
+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)
+
+Optional properties:
+
+ - interrupt-parent: phandle of the parent interrupt controller
+ - interrupts : The first interrupt specified is the interrupt that shall be
+ used for out-of-band wake-on-bt. Driver will request an irq
+ based on this interrupt number. 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>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ce22cef..32a6f22 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_wake(irq);
+ disable_irq_nosync(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);
+
+/* 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 = irq_of_parse_and_map(dev->of_node, 0);
+ if (!irq) {
+ bt_dev_dbg(hdev, "%s: no oob wake 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,
+ IRQF_TRIGGER_LOW, "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);
@@ -3089,6 +3158,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) {
+ clear_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
+ enable_irq(data->oob_wake_irq);
+ enable_irq_wake(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 +3201,13 @@ static int btusb_resume(struct usb_interface *intf)
if (--data->suspend_count)
return 0;
+ /* Disable only if not already disabled (keep it balanced) */
+ if (data->oob_wake_irq &&
+ !test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
+ disable_irq_wake(data->oob_wake_irq);
+ disable_irq(data->oob_wake_irq);
+ }
+
if (!test_bit(HCI_RUNNING, &hdev->flags))
goto done;
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 1/3] Bluetooth: btusb: Use an error label for error paths
From: Rajat Jain @ 2016-12-14 19:12 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev, devicetree, linux-bluetooth, Brian Norris
Cc: Rajat Jain, rajatxjain
Use a label to remove the repetetive cleanup, for error cases.
(This label will also be used in subsequent patches).
Signed-off-by: Rajat Jain <rajatja@google.com>
---
drivers/bluetooth/btusb.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 2f633df..ce22cef 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2991,18 +2991,15 @@ static int btusb_probe(struct usb_interface *intf,
err = usb_set_interface(data->udev, 0, 0);
if (err < 0) {
BT_ERR("failed to set interface 0, alt 0 %d", err);
- hci_free_dev(hdev);
- return err;
+ goto out_free_dev;
}
}
if (data->isoc) {
err = usb_driver_claim_interface(&btusb_driver,
data->isoc, data);
- if (err < 0) {
- hci_free_dev(hdev);
- return err;
- }
+ if (err < 0)
+ goto out_free_dev;
}
#ifdef CONFIG_BT_HCIBTUSB_BCM
@@ -3016,14 +3013,16 @@ static int btusb_probe(struct usb_interface *intf,
#endif
err = hci_register_dev(hdev);
- if (err < 0) {
- hci_free_dev(hdev);
- return err;
- }
+ if (err < 0)
+ goto out_free_dev;
usb_set_intfdata(intf, data);
return 0;
+
+out_free_dev:
+ hci_free_dev(hdev);
+ return err;
}
static void btusb_disconnect(struct usb_interface *intf)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: clk: clk-mstp has never worked for RZ/A1
From: Geert Uytterhoeven @ 2016-12-14 18:57 UTC (permalink / raw)
To: Chris Brandt
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <SG2PR06MB11657308A9FA6EF71F5F89688A9A0-ESzmfEwOt/xoAsOJh7vwSm0DtJ1/0DrXvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Hi Chris,
On Wed, Dec 14, 2016 at 5:22 PM, Chris Brandt <Chris.Brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> On Dec 14, 2016, Geert Uytterhoeven wrote:
>> Another option is to let the driver bind against "renesas,r7s72100-mstp-
>> clocks", and switch to 8-bit access mode.
>>
>> CLK_OF_DECLARE(cpg_mstp_clks, "renesas,r7s72100-mstp-clocks",
>> cpg_mstp_clocks_init8);
>>
>> cpg_mstp_clocks_init8() can set a gloal flag, and call
>> cpg_mstp_clocks_init().
>>
>> The latter means no DT update is needed, and thus preserves compatibility
>> with old DTBs.
>
> I just coded that and it works good. Thank you.
I'm glad to hear that!
> Now, one more question before I submit a patch for review:
>
> I would like to add a "Fixes:" to the commit log so it can be considered for 4.9-stable (in reality it could go all the way back to when r7s72100 support was added)
>
> But, the current file path didn't exist until after commit b3a33077c0dd ("clk: renesas: move drivers to renesas directory") on 2016-03-02.
>
> So should I use that commit for my 'Fixes'?
Please use the original commit, as that's where the bug was introduced.
Git is quiet good in tracking renames, so cherry-picking it to v4.5 and older
kernels may just work ;-)
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Krzysztof Kozlowski @ 2016-12-14 18:20 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski, Kukjin Kim,
Rob Herring, Mark Rutland, Russell King, Doug Anderson,
Andreas Faerber, Thomas Abraham, Ben Gamari, linux-samsung-soc,
linux-arm-kernel, linux-pm, devicetree, linux-kernel
In-Reply-To: <26ffeee4-ff43-b3d3-3267-5fcbc50e2974@osg.samsung.com>
On Tue, Dec 13, 2016 at 04:18:05PM -0300, Javier Martinez Canillas wrote:
> Hello Bartlomiej,
>
> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> > Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> > (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> > cooling maps to account for new OPPs.
> >
> > Since new OPPs are not available on all Exynos5422/5800 boards modify
> > dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> > Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >
> > Tested on Odroid-XU3 and XU3 Lite.
> >
> > Cc: Doug Anderson <dianders@chromium.org>
> > Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> > Cc: Andreas Faerber <afaerber@suse.de>
> > Cc: Thomas Abraham <thomas.ab@samsung.com>
> > Cc: Ben Gamari <ben@smart-cactus.org>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > ---
> > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> > arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> > arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> > arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> > 4 files changed, 43 insertions(+), 7 deletions(-)
> >
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> > @@ -118,7 +118,7 @@
> > /*
> > * When reaching cpu_alert3, reduce CPU
> > * by 2 steps. On Exynos5422/5800 that would
> > - * be: 1600 MHz and 1100 MHz.
> > + * (usually) be: 1800 MHz and 1200 MHz.
> > */
> > map3 {
> > trip = <&cpu_alert3>;
> > @@ -131,16 +131,16 @@
> >
> > /*
> > * When reaching cpu_alert4, reduce CPU
> > - * further, down to 600 MHz (11 steps for big,
> > - * 7 steps for LITTLE).
> > + * further, down to 600 MHz (13 steps for big,
> > + * 8 steps for LITTLE).
> > */
> > - map5 {
> > + cooling_map5: map5 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu0 3 7>;
> > + cooling-device = <&cpu0 3 8>;
> > };
> > - map6 {
> > + cooling_map6: map6 {
> > trip = <&cpu_alert4>;
> > - cooling-device = <&cpu4 3 11>;
> > + cooling-device = <&cpu4 3 13>;
> > };
> > };
> > };
> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> > @@ -21,6 +21,23 @@
> > compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> > };
> >
> > +&cluster_a15_opp_table {
> > + /delete-node/opp@2000000000;
> > + /delete-node/opp@1900000000;
> > +};
> > +
> > +&cluster_a7_opp_table {
> > + /delete-node/opp@1400000000;
> > +};
> > +
>
> I think that a comment in the DTS why these operating points aren't available
> in this board will make more clear why the nodes are being deleted.
>
> > +&cooling_map5 {
> > + cooling-device = <&cpu0 3 7>;
> > +};
> > +
> > +&cooling_map6 {
> > + cooling-device = <&cpu4 3 11>;
> > +};
> > +
> > &pwm {
> > /*
> > * PWM 0 -- fan
> > Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> > @@ -146,6 +146,10 @@
> > vdd-supply = <&ldo9_reg>;
> > };
> >
> > +&cluster_a7_opp_table {
> > + /delete-property/opp@1400000000;
> > +};
> > +
> > &cpu0 {
> > cpu-supply = <&buck2_reg>;
> > };
> > Index: b/arch/arm/boot/dts/exynos5800.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> > @@ -24,6 +24,16 @@
> > };
> >
> > &cluster_a15_opp_table {
> > + opp@2000000000 {
> > + opp-hz = /bits/ 64 <2000000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > + opp@1900000000 {
> > + opp-hz = /bits/ 64 <1900000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > opp@1700000000 {
> > opp-microvolt = <1250000>;
> > };
> > @@ -85,6 +95,11 @@
> > };
> >
>
> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> INT rail would need to be scaled up as well since there's a maximum voltage
> difference between the ARM and INT rails before the system becomes unstable:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> https://lkml.org/lkml/2014/5/2/419
The choice of skipping > 1.8 GHz could be also made because of missing
ASV which is important to detect the BIN2 of Exynos5422. The BIN2 is
capped to 1.8/1.3.
Anyway this shouldn't be limiting us now because we have all data
statically coded in DTS - in mainline boards, only Odroid XU3-lite
uses BIN2.
Beside comments from Javier, I would be happy to see high frequencies
Tested-by on Peach Pi/Pit. AFAIR, we did not have these in SRPOL. :)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/2] drm/panel: simple: Add support BOE nv101wxmn51
From: Doug Anderson @ 2016-12-14 18:08 UTC (permalink / raw)
To: Caesar Wang
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, Rob Herring
In-Reply-To: <1481685596-15608-2-git-send-email-wxt@rock-chips.com>
Hi,
On Tue, Dec 13, 2016 at 7:19 PM, Caesar Wang <wxt@rock-chips.com> wrote:
> 10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
> TFT's as an active switching devices. It can be supported by the
> simple-panel driver.
>
> Read the panel default edid information:
>
> EDID MODE DETAILS
> name = <NULL>
> pixel_clock = 71900
> lvds_dual_channel = 0
> refresh = 0
> ha = 1280
> hbl = 160
> hso = 48
> hspw = 32
> hborder = 0
> va = 800
> vbl = 32
> vso = 3
> vspw = 5
> vborder = 0
> phsync = +
> pvsync = -
> x_mm = 0
> y_mm = 0
> drm_display_mode
> .hdisplay = 1280
> .hsync_start = 1328
> .hsync_end = 1360
> .htotal = 1440
> .vdisplay = 800
> .vsync_start = 803
> .vsync_end = 808
> .vtotal = 832
>
> There are two modes in the edid:
> Detailed mode1: Clock 71.900 MHz, 216 mm x 135 mm
> 1280 1328 1360 1440 hborder 0
> 800 803 808 832 vborder 0
> +hsync -vsync
> Detailed mode2: Clock 57.500 MHz, 216 mm x 135 mm
> 1280 1328 1360 1440 hborder 0
> 800 803 808 832 vborder 0
> +hsync -vsync
>
> Add the both edid to support more modes for BOE nv101wxmn51.
>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> ---
>
> Changes in v3:
> - As Stéphane commented on https://patchwork.kernel.org/patch/9465911,
> add downclock mode for edid.
>
> Changes in v2:
> - fix the vsync_start and vsync_end from the edid.
> - change the commit.
>
> drivers/gpu/drm/panel/panel-simple.c | 45 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
Seems sane to me.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 3/3] power: supply: bq24735-charger: allow chargers to share the ac-detect gpio
From: Peter Rosin @ 2016-12-14 17:41 UTC (permalink / raw)
To: Sebastian Reichel, Linus Walleij, Alexandre Courbot
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161214170114.ckozfple475kqajh@earth>
On 2016-12-14 18:01, Sebastian Reichel wrote:
> [of course I forgot to actually add gpio people, let's try again]
>
> On Wed, Dec 14, 2016 at 05:59:21PM +0100, Sebastian Reichel wrote:
>> Hi,
>>
>> On Wed, Dec 14, 2016 at 12:56:45AM +0100, Peter Rosin wrote:
>>> If several parallel bq24735 chargers have their ac-detect gpios wired
>>> together (or if only one of the parallel bq24735 chargers have its
>>> ac-detect pin wired to a gpio, and the others are assumed to react the
>>> same), then all driver instances need to check the same gpio. But the
>>> gpio subsystem does not allow sharing gpios, so handle that locally.
>>
>> Adding GPIO subsystem people to see if they can come up with
>> something in the gpiod API for this usecase.
Right, I don't like how my new code steps away from gpio descriptors.
>>> However, only do this for the polling case, sharing is not supported if
>>> the ac detection is handled with interrupts.
>>
>> Why? I guess you only added the gpio polling stuff for the shared
>> gpio feature, so we can skip the gpio polling if we add shared irq
>> support instead?
Nope, the hw really can't do interrupts on the gpio, it's just not wired
up for that. The gpio is on an expander, and the irq line from the expander
top the cpu is not there (due to a desire to minimize the number of
connections between two parts of the system). So I need both polling and
sharing.
Cheers,
peda
--
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 1/2] devicetree: power: add bindings for GPIO-driven power switches
From: Jonathan Cameron @ 2016-12-14 17:36 UTC (permalink / raw)
To: Bartosz Golaszewski, Rob Herring
Cc: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Mark Rutland, linux-iio, linux-devicetree,
LKML, Kevin Hilman, Patrick Titiano, Neil Armstrong,
Linus Walleij, Alexandre Courbot, linux-gpio, Sebastian Reichel,
linux-pm, Mark Brown, Liam Girdwood
In-Reply-To: <CAMpxmJWw3wCE4ch8TVik+2b3BC8Lvxbi13HGd9GxruSRLu95Mg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]
On 14 December 2016 16:58:21 GMT+00:00, Bartosz Golaszewski <bgolaszewski@baylibre.com> wrote:
>2016-12-13 20:27 GMT+01:00 Rob Herring <robh@kernel.org>:
>> On Sun, Dec 11, 2016 at 11:21:44PM +0100, Bartosz Golaszewski wrote:
>>> Some boards are equipped with simple, GPIO-driven power load
>switches.
>>> An example of such ICs is the TI tps229* series.
>>
>> How is this different than a GPIO regulator? The input and output
>> voltages just happen to be the same. I could be convinced this is
>> different enough to have a different compatible, but it somewhat
>seems
>> you want to use this for IIO, so you are creating a different binding
>> for that usecase.
>>
>
>It's more of a fixed regulator I suppose. Do you mean adding a new
>compatible to the fixed-regulator binding (e.g. "gpio-power-switch" or
>"simple-power-switch") and then providing an iio driver for toggling
>the switch?
I am rather torn on whether the IIO interface makes any sense beyond that of convenience.
A bridge to a regulator in general might make sense to cover the case of a reg effectively
acting as a DAC at the edge of the known hardware.
Lars' point about perhaps adding support for the new gpio userspace stuff to libiio would in
this case also be rather papering over the issue.
There is known hardware there so we should describe it!
I think we should be considering this as the general case of the Linux controlled power supply.
How do we want to represent that?
Ultimately does a general regulator userspace interface make sense?
Classic case of people cutting our hardware in half and making boundaries beyond which lie dragons.
I would love to see the general case covered.
Jonathan
>
>Thanks,
>Bartosz
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[-- Attachment #2: Type: text/html, Size: 2396 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-14 17:19 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Arjun K V, Krzysztof Kozlowski, Kukjin Kim, Rob Herring,
Mark Rutland, Russell King, Doug Anderson, Andreas Faerber,
Thomas Abraham, Ben Gamari, linux-samsung-soc, linux-arm-kernel,
linux-pm, devicetree, linux-kernel
In-Reply-To: <4861151.PfdUkXTZox@amdc3058>
Hello Bartlomiej,
On 12/14/2016 01:10 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote:
>> Hello Bartlomiej,
>>
>> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> Hi,
>>>
>>> On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>>>>
>>>> Hello Bartlomiej,
>>>>
>>>> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>
>>>>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>>>>>> Hello Bartlomiej,
>>>>>
>>>>> Hi,
>>>>>
>>>>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>>>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>>>>>> cooling maps to account for new OPPs.
>>>>>>>
>>>>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>>>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>>>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>>>>>
>>>>>>> Tested on Odroid-XU3 and XU3 Lite.
>>>>>>>
>>>>>>> Cc: Doug Anderson <dianders@chromium.org>
>>>>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>>>>>>> Cc: Andreas Faerber <afaerber@suse.de>
>>>>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
>>>>>>> Cc: Ben Gamari <ben@smart-cactus.org>
>>>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>>>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>>>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>>>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>>>>>
>>>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>>>>>> @@ -118,7 +118,7 @@
>>>>>>> /*
>>>>>>> * When reaching cpu_alert3, reduce CPU
>>>>>>> * by 2 steps. On Exynos5422/5800 that would
>>>>>>> - * be: 1600 MHz and 1100 MHz.
>>>>>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>>>>>> */
>>>>>>> map3 {
>>>>>>> trip = <&cpu_alert3>;
>>>>>>> @@ -131,16 +131,16 @@
>>>>>>>
>>>>>>> /*
>>>>>>> * When reaching cpu_alert4, reduce CPU
>>>>>>> - * further, down to 600 MHz (11 steps for big,
>>>>>>> - * 7 steps for LITTLE).
>>>>>>> + * further, down to 600 MHz (13 steps for big,
>>>>>>> + * 8 steps for LITTLE).
>>>>>>> */
>>>>>>> - map5 {
>>>>>>> + cooling_map5: map5 {
>>>>>>> trip = <&cpu_alert4>;
>>>>>>> - cooling-device = <&cpu0 3 7>;
>>>>>>> + cooling-device = <&cpu0 3 8>;
>>>>>>> };
>>>>>>> - map6 {
>>>>>>> + cooling_map6: map6 {
>>>>>>> trip = <&cpu_alert4>;
>>>>>>> - cooling-device = <&cpu4 3 11>;
>>>>>>> + cooling-device = <&cpu4 3 13>;
>>>>>>> };
>>>>>>> };
>>>>>>> };
>>>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>>>>>> @@ -21,6 +21,23 @@
>>>>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>>>>>> };
>>>>>>>
>>>>>>> +&cluster_a15_opp_table {
>>>>>>> + /delete-node/opp@2000000000;
>>>>>>> + /delete-node/opp@1900000000;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&cluster_a7_opp_table {
>>>>>>> + /delete-node/opp@1400000000;
>>>>>>> +};
>>>>>>> +
>>>>>>
>>>>>> I think that a comment in the DTS why these operating points aren't available
>>>>>> in this board will make more clear why the nodes are being deleted.
>>>>>
>>>>> Ok, I will add these comments in the next patch revision.
>>>>>
>>>>>>> +&cooling_map5 {
>>>>>>> + cooling-device = <&cpu0 3 7>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&cooling_map6 {
>>>>>>> + cooling-device = <&cpu4 3 11>;
>>>>>>> +};
>>>>>>> +
>>>>>>> &pwm {
>>>>>>> /*
>>>>>>> * PWM 0 -- fan
>>>>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> @@ -146,6 +146,10 @@
>>>>>>> vdd-supply = <&ldo9_reg>;
>>>>>>> };
>>>>>>>
>>>>>>> +&cluster_a7_opp_table {
>>>>>>> + /delete-property/opp@1400000000;
>>>>>>> +};
>>>>>>> +
>>>>>>> &cpu0 {
>>>>>>> cpu-supply = <&buck2_reg>;
>>>>>>> };
>>>>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> @@ -24,6 +24,16 @@
>>>>>>> };
>>>>>>>
>>>>>>> &cluster_a15_opp_table {
>>>>>>> + opp@2000000000 {
>>>>>>> + opp-hz = /bits/ 64 <2000000000>;
>>>>>>> + opp-microvolt = <1250000>;
>>>>>>> + clock-latency-ns = <140000>;
>>>>>>> + };
>>>>>>> + opp@1900000000 {
>>>>>>> + opp-hz = /bits/ 64 <1900000000>;
>>>>>>> + opp-microvolt = <1250000>;
>>>>>>> + clock-latency-ns = <140000>;
>>>>>>> + };
>>>>>>> opp@1700000000 {
>>>>>>> opp-microvolt = <1250000>;
>>>>>>> };
>>>>>>> @@ -85,6 +95,11 @@
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>>>>>> INT rail would need to be scaled up as well since there's a maximum voltage
>>>>>> difference between the ARM and INT rails before the system becomes unstable:
>>>>>>
>>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>>>>>> https://lkml.org/lkml/2014/5/2/419
>>>>>>
>>>>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>>>>>> the maximum voltage skew is between a limit. But that never made to mainline:
>>>>>>
>>>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>>>>>> https://lkml.org/lkml/2014/4/29/28
>>>>>>
>>>>>> Did that change and there's infrastructure in mainline now to cope with that?
>>>>>> If that's the case, I think it would be good to mention in the commit message.
>>>>>
>>>>> I was not aware of this limitation and AFAIK mainline has currently
>>>>> no code to handle it. I also cannot find any code to handle this in
>>>>
>>>> Yes, that's what I thought as well but maybe I was missing something.
>>>>
>>>>> Hardkernel's vendor kernel for Odroid-XU3 board.
>>>>>
>>>>> Do you know whether this problem exists also on Exynos5422/5800
>>>>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
>>>>> regulator code also on Exynos5800 SoC based Peach Pi board but was
>>>>> the problem actually present on this board?
>>>>>
>>>>
>>>> My understanding is that this problem is present in 5420/5422/5800
>>>> but I have no way to confirm this. I'm just guessing from the info
>>>> in the ChromiumOS vendor tree.
>>>>
>>>> If you look at the commit that added the regulator-locker driver,
>>>> the test says to be done in a Peach Pi so it seems the problem is
>>>> not restricted to only Exynos5420:
>>>>
>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>>>>
>>>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>>> (unfortunately Inderpal's email is no longer working). ]
>>>>>
>>>>
>>>> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
>>>
>>> Abhilash's email is also no longer valid.. :(
>>>
>>
>> Yes, I noticed that as well :(
>>
>>>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>>>> IOW if the problem exists it is already present in the mainline
>>>>> kernel.
>>>>>
>>>>
>>>> Ah, I only looked at your patch and I didn't compare the voltage levels
>>>> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>>>>
>>>> I wonder if the voltage levels in your patch are correct then, since the
>>>> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>>>>
>>>> /*
>>>> * Default ASV table
>>>> */
>>>> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
>>>> 1362500, /* L0 2100 */
>>>> 1312500, /* L1 2000 */
>>>> 1275000, /* L2 1900 */
>>>> 1225000, /* L3 1800 */
>>>> 1200000, /* L4 1700 */
>>>>
>>>> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
>>>
>>> I think that the above voltages are original ones for Exynos5420
>>> (not for Exynos5422/5800).
>>>
>>
>> In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
>> Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
>
> This seems suboptimal (or maybe even incorrect as Exynos5422/5800
> SoCs also use different clock divider values for clocks related to
> CPU clock than Exynos5420 SoC).
>
Yes, I know. There's lot of if (soc_is_exynos5420()) and if (soc_is_exynos5422())
checks in the driver though so I guess those differences are taken into account.
I haven't reviewed that driver in detail though so maybe something is missing.
> Anyway, I can drop Peach Pi support from my patch for now if you want.
>
I'm not against adding all the missing operating points btw, I'm just trying to
make sure that's safe to do so in mainline.
>>> The voltages in my patch were taken from Hardkernel's kernel for
>>> Odroid-XU3:
>>>
>>> /*
>>> * ASV group voltage table
>>> */
>>> static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
>>> ...
>>> 1250000, /* L4 2000 */
>>> 1250000, /* L5 1900 */
>>> 1250000, /* L6 1800 */
>>> ...
>>>
>>> https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
>>>
>>
>> In general I prefer to use the ChromiumOS tree as a reference instead of the
>> HardKernel one, since the former is in a much better shape IMHO.
>
> I generally agree, OTOH Hardkernel's tree is based on Samsung's
> vendor trees and additionally it contains all low-level hardware
> details for Odroid-XU3 board (not present in ChromiumOS tree).
>
Fair enough.
>> I think is worth to check in a kernel tree in http://opensource.samsung.com/
>> for a product that's Exynos5422/5800 based.
>
> I've just checked kernel from SM-G900H_LL_Opensource.zip (for Galaxy
> S5 which is Exynos5422 based) and it uses 50mV lower voltages for
> 1.6 GHz - 2.0 GHz OPPs, for the lower frequencies OPPs voltages are
> identical to the ones used by HardKernel's tree,
>
Interesting, thanks a lot for checking. So if the voltage levels for 1.9 GHz
and 2.0 GHz are the same than 1.8 GHz, then I agree with you that either is
safe to add these OPPs in mainline or the problem is already present there.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 2/2] xilinx_dma: Add reset support
From: Ramiro Oliveira @ 2016-12-14 17:18 UTC (permalink / raw)
To: dmaengine-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, michal.simek-gjFFaj9aHVfQT0dZR+AlfA,
soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA,
appana.durga.rao-gjFFaj9aHVfQT0dZR+AlfA,
anuragku-gjFFaj9aHVfQT0dZR+AlfA,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Ramiro Oliveira
In-Reply-To: <cover.1481735244.git.roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Add a DT property to control an optional external reset line
Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
---
drivers/dma/xilinx/xilinx_dma.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 5c9f11b..b845224 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -46,6 +46,7 @@
#include <linux/slab.h>
#include <linux/clk.h>
#include <linux/io-64-nonatomic-lo-hi.h>
+#include <linux/reset.h>
#include "../dmaengine.h"
@@ -409,6 +410,7 @@ struct xilinx_dma_device {
struct clk *rxs_clk;
u32 nr_channels;
u32 chan_id;
+ struct reset_control *rst;
};
/* Macros */
@@ -2543,6 +2545,27 @@ static int xilinx_dma_probe(struct platform_device *pdev)
if (IS_ERR(xdev->regs))
return PTR_ERR(xdev->regs);
+ xdev->rst = devm_reset_control_get_optional(&pdev->dev, "reset");
+ if (IS_ERR(xdev->rst)) {
+ err = PTR_ERR(xdev->rst);
+ switch (err) {
+ case -ENOENT:
+ case -ENOTSUPP:
+ xdev->rst = NULL;
+ break;
+ default:
+ dev_err(xdev->dev, "error getting reset %d\n", err);
+ return err;
+ }
+ } else {
+ err = reset_control_deassert(xdev->rst);
+ if (err) {
+ dev_err(xdev->dev, "failed to deassert reset: %d\n",
+ err);
+ return err;
+ }
+ }
+
/* Retrieve the DMA engine properties from the device tree */
xdev->has_sg = of_property_read_bool(node, "xlnx,include-sg");
if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA)
--
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
^ permalink raw reply related
* [PATCH 1/2] xilinx_dma: Edit device tree bindings documentation
From: Ramiro Oliveira @ 2016-12-14 17:18 UTC (permalink / raw)
To: dmaengine, devicetree, linux-arm-kernel, linux-kernel
Cc: vinod.koul, robh+dt, mark.rutland, michal.simek, soren.brinkmann,
appana.durga.rao, anuragku, dan.j.williams, laurent.pinchart,
CARLOS.PALMINHA, Ramiro Oliveira
In-Reply-To: <cover.1481735244.git.roliveir@synopsys.com>
Add reset property documentation for Xilinx DMA
Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
---
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index a2b8bfa..7ebce72 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -40,6 +40,10 @@ Required properties for VDMA:
Optional properties:
- xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
+- resets : Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+ - reset
Optional properties for AXI DMA:
- xlnx,mcdma: Tells whether configured for multi-channel mode in the hardware.
Optional properties for VDMA:
@@ -83,6 +87,8 @@ axi_vdma_0: axivdma@40030000 {
clocks = <&clk 0>, <&clk 1>, <&clk 2>, <&clk 3>, <&clk 4>;
clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk",
"m_axis_mm2s_aclk", "s_axis_s2mm_aclk";
+ resets = <&rst 2>;
+ reset-names = "reset";
dma-channel@40030000 {
compatible = "xlnx,axi-vdma-mm2s-channel";
interrupts = < 0 54 4 >;
--
2.10.2
^ permalink raw reply related
* [PATCH 0/2] xilinx_dma: Add external reset control
From: Ramiro Oliveira @ 2016-12-14 17:18 UTC (permalink / raw)
To: dmaengine-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, michal.simek-gjFFaj9aHVfQT0dZR+AlfA,
soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA,
appana.durga.rao-gjFFaj9aHVfQT0dZR+AlfA,
anuragku-gjFFaj9aHVfQT0dZR+AlfA,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Ramiro Oliveira
This patchset adds support for controlling an external reset line. Since
this reset line is optional it won't break compatibility.
Ramiro Oliveira (2):
xilinx_dma: Edit device tree bindings documentation
xilinx_dma: Add reset support
.../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6 ++++++
drivers/dma/xilinx/xilinx_dma.c | 23 ++++++++++++++++++++++
2 files changed, 29 insertions(+)
--
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
^ permalink raw reply
* Re: [PATCH v2 3/3] power: supply: bq24735-charger: allow chargers to share the ac-detect gpio
From: Sebastian Reichel @ 2016-12-14 17:01 UTC (permalink / raw)
To: Peter Rosin, Linus Walleij, Alexandre Courbot
Cc: linux-kernel, linux-pm, devicetree, linux-gpio
In-Reply-To: <20161214165921.jsatcznbljd7anqi@earth>
[-- Attachment #1: Type: text/plain, Size: 8056 bytes --]
[of course I forgot to actually add gpio people, let's try again]
On Wed, Dec 14, 2016 at 05:59:21PM +0100, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Dec 14, 2016 at 12:56:45AM +0100, Peter Rosin wrote:
> > If several parallel bq24735 chargers have their ac-detect gpios wired
> > together (or if only one of the parallel bq24735 chargers have its
> > ac-detect pin wired to a gpio, and the others are assumed to react the
> > same), then all driver instances need to check the same gpio. But the
> > gpio subsystem does not allow sharing gpios, so handle that locally.
>
> Adding GPIO subsystem people to see if they can come up with
> something in the gpiod API for this usecase.
>
> > However, only do this for the polling case, sharing is not supported if
> > the ac detection is handled with interrupts.
>
> Why? I guess you only added the gpio polling stuff for the shared
> gpio feature, so we can skip the gpio polling if we add shared irq
> support instead?
>
> > Signed-off-by: Peter Rosin <peda@axentia.se>
> > ---
> > drivers/power/supply/bq24735-charger.c | 111 +++++++++++++++++++++++++++++----
> > 1 file changed, 100 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/power/supply/bq24735-charger.c b/drivers/power/supply/bq24735-charger.c
> > index f45876927676..c2403c4d5ece 100644
> > --- a/drivers/power/supply/bq24735-charger.c
> > +++ b/drivers/power/supply/bq24735-charger.c
> > @@ -25,6 +25,7 @@
> > #include <linux/kernel.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > +#include <linux/of_gpio.h>
> > #include <linux/gpio/consumer.h>
> > #include <linux/power_supply.h>
> > #include <linux/slab.h>
> > @@ -43,12 +44,24 @@
> > #define BQ24735_MANUFACTURER_ID 0xfe
> > #define BQ24735_DEVICE_ID 0xff
> >
> > +struct bq24735;
> > +
> > +struct bq24735_shared {
> > + struct list_head list;
> > + struct bq24735 *owner;
> > + struct gpio_desc *status_gpio;
> > +};
> > +
> > +static DEFINE_MUTEX(shared_lock);
> > +static LIST_HEAD(shared_list);
> > +
> > struct bq24735 {
> > struct power_supply *charger;
> > struct power_supply_desc charger_desc;
> > struct i2c_client *client;
> > struct bq24735_platform *pdata;
> > struct mutex lock;
> > + struct bq24735_shared *shared;
> > struct gpio_desc *status_gpio;
> > struct delayed_work poll;
> > u32 poll_interval;
> > @@ -346,6 +359,75 @@ static struct bq24735_platform *bq24735_parse_dt_data(struct i2c_client *client)
> > return pdata;
> > }
> >
> > +static struct gpio_desc *bq24735_get_status_gpio(struct bq24735 *charger)
> > +{
> > + struct device *dev = &charger->client->dev;
> > + struct bq24735_shared *shared;
> > + int gpio;
> > + enum of_gpio_flags flags;
> > + int active_low;
> > + struct list_head *pos;
> > +
> > + if (of_property_read_bool(dev->of_node, "ti,ac-detect-gpios"))
> > + gpio = of_get_named_gpio_flags(dev->of_node,
> > + "ti,ac-detect-gpios", 0, &flags);
> > + else if (of_property_read_bool(dev->of_node, "ti,ac-detect-gpio"))
> > + gpio = of_get_named_gpio_flags(dev->of_node,
> > + "ti,ac-detect-gpio", 0, &flags);
> > + else
> > + return NULL;
> > +
> > + if (!gpio_is_valid(gpio))
> > + return ERR_PTR(gpio);
> > + active_low = flags & OF_GPIO_ACTIVE_LOW;
> > +
> > + mutex_lock(&shared_lock);
> > + list_for_each(pos, &shared_list) {
> > + shared = list_entry(pos, struct bq24735_shared, list);
> > + if (gpio != desc_to_gpio(shared->status_gpio))
> > + continue;
> > + if (!active_low ^ !gpiod_is_active_low(shared->status_gpio))
> > + continue;
> > +
> > + get_device(&shared->owner->client->dev);
> > + dev_dbg(dev, "sharing gpio with %s\n",
> > + shared->owner->pdata->name);
> > + charger->shared = shared;
> > + mutex_unlock(&shared_lock);
> > + return shared->status_gpio;
> > + }
> > +
> > + shared = devm_kzalloc(dev, sizeof(*shared), GFP_KERNEL);
> > + if (!shared) {
> > + mutex_unlock(&shared_lock);
> > + return ERR_PTR(-ENOMEM);
> > + }
> > + shared->owner = charger;
> > + shared->status_gpio = gpiod_get(dev, "ti,ac-detect", GPIOD_IN);
> > + if (!IS_ERR(shared->status_gpio)) {
> > + charger->shared = shared;
> > + list_add(&shared->list, &shared_list);
> > + }
> > + mutex_unlock(&shared_lock);
> > +
> > + return shared->status_gpio;
> > +}
> > +
> > +static void bq24735_put_status_gpio(struct bq24735 *charger)
> > +{
> > + if (!charger->shared)
> > + return;
> > +
> > + mutex_lock(&shared_lock);
> > + if (charger->shared->owner != charger) {
> > + put_device(&charger->shared->owner->client->dev);
> > + } else {
> > + list_del(&charger->shared->list);
> > + gpiod_put(charger->shared->status_gpio);
> > + }
> > + mutex_unlock(&shared_lock);
> > +}
> > +
> > static int bq24735_charger_probe(struct i2c_client *client,
> > const struct i2c_device_id *id)
> > {
> > @@ -402,9 +484,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> >
> > i2c_set_clientdata(client, charger);
> >
> > - charger->status_gpio = devm_gpiod_get_optional(&client->dev,
> > - "ti,ac-detect",
> > - GPIOD_IN);
> > + charger->status_gpio = bq24735_get_status_gpio(charger);
> > if (IS_ERR(charger->status_gpio)) {
> > ret = PTR_ERR(charger->status_gpio);
> > dev_err(&client->dev, "Getting gpio failed: %d\n", ret);
> > @@ -416,28 +496,30 @@ static int bq24735_charger_probe(struct i2c_client *client,
> > if (ret < 0) {
> > dev_err(&client->dev, "Failed to read manufacturer id : %d\n",
> > ret);
> > - return ret;
> > + goto out;
> > } else if (ret != 0x0040) {
> > dev_err(&client->dev,
> > "manufacturer id mismatch. 0x0040 != 0x%04x\n", ret);
> > - return -ENODEV;
> > + ret = -ENODEV;
> > + goto out;
> > }
> >
> > ret = bq24735_read_word(client, BQ24735_DEVICE_ID);
> > if (ret < 0) {
> > dev_err(&client->dev, "Failed to read device id : %d\n", ret);
> > - return ret;
> > + goto out;
> > } else if (ret != 0x000B) {
> > dev_err(&client->dev,
> > "device id mismatch. 0x000b != 0x%04x\n", ret);
> > - return -ENODEV;
> > + ret = -ENODEV;
> > + goto out;
> > }
> > }
> >
> > ret = bq24735_config_charger(charger);
> > if (ret < 0) {
> > dev_err(&client->dev, "failed in configuring charger");
> > - return ret;
> > + goto out;
> > }
> >
> > /* check for AC adapter presence */
> > @@ -445,7 +527,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> > ret = bq24735_enable_charging(charger);
> > if (ret < 0) {
> > dev_err(&client->dev, "Failed to enable charging\n");
> > - return ret;
> > + goto out;
> > }
> > }
> >
> > @@ -455,7 +537,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> > ret = PTR_ERR(charger->charger);
> > dev_err(&client->dev, "Failed to register power supply: %d\n",
> > ret);
> > - return ret;
> > + goto out;
> > }
> >
> > if (client->irq) {
> > @@ -470,7 +552,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> > dev_err(&client->dev,
> > "Unable to register IRQ %d err %d\n",
> > client->irq, ret);
> > - return ret;
> > + goto out;
> > }
> > } else if (charger->status_gpio) {
> > ret = of_property_read_u32(client->dev.of_node,
> > @@ -487,6 +569,11 @@ static int bq24735_charger_probe(struct i2c_client *client,
> > }
> >
> > return 0;
> > +
> > +out:
> > + bq24735_put_status_gpio(charger);
> > +
> > + return ret;
> > }
> >
> > static int bq24735_charger_remove(struct i2c_client *client)
> > @@ -496,6 +583,8 @@ static int bq24735_charger_remove(struct i2c_client *client)
> > if (charger->poll_interval)
> > cancel_delayed_work_sync(&charger->poll);
> >
> > + bq24735_put_status_gpio(charger);
> > +
> > return 0;
> > }
> >
> > --
> > 2.1.4
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] power: supply: bq24735-charger: allow chargers to share the ac-detect gpio
From: Sebastian Reichel @ 2016-12-14 16:59 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-kernel, Rob Herring, Mark Rutland, linux-pm, devicetree
In-Reply-To: <1481673405-4547-4-git-send-email-peda@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 7445 bytes --]
Hi,
On Wed, Dec 14, 2016 at 12:56:45AM +0100, Peter Rosin wrote:
> If several parallel bq24735 chargers have their ac-detect gpios wired
> together (or if only one of the parallel bq24735 chargers have its
> ac-detect pin wired to a gpio, and the others are assumed to react the
> same), then all driver instances need to check the same gpio. But the
> gpio subsystem does not allow sharing gpios, so handle that locally.
Adding GPIO subsystem people to see if they can come up with
something in the gpiod API for this usecase.
> However, only do this for the polling case, sharing is not supported if
> the ac detection is handled with interrupts.
Why? I guess you only added the gpio polling stuff for the shared
gpio feature, so we can skip the gpio polling if we add shared irq
support instead?
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> drivers/power/supply/bq24735-charger.c | 111 +++++++++++++++++++++++++++++----
> 1 file changed, 100 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/power/supply/bq24735-charger.c b/drivers/power/supply/bq24735-charger.c
> index f45876927676..c2403c4d5ece 100644
> --- a/drivers/power/supply/bq24735-charger.c
> +++ b/drivers/power/supply/bq24735-charger.c
> @@ -25,6 +25,7 @@
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_gpio.h>
> #include <linux/gpio/consumer.h>
> #include <linux/power_supply.h>
> #include <linux/slab.h>
> @@ -43,12 +44,24 @@
> #define BQ24735_MANUFACTURER_ID 0xfe
> #define BQ24735_DEVICE_ID 0xff
>
> +struct bq24735;
> +
> +struct bq24735_shared {
> + struct list_head list;
> + struct bq24735 *owner;
> + struct gpio_desc *status_gpio;
> +};
> +
> +static DEFINE_MUTEX(shared_lock);
> +static LIST_HEAD(shared_list);
> +
> struct bq24735 {
> struct power_supply *charger;
> struct power_supply_desc charger_desc;
> struct i2c_client *client;
> struct bq24735_platform *pdata;
> struct mutex lock;
> + struct bq24735_shared *shared;
> struct gpio_desc *status_gpio;
> struct delayed_work poll;
> u32 poll_interval;
> @@ -346,6 +359,75 @@ static struct bq24735_platform *bq24735_parse_dt_data(struct i2c_client *client)
> return pdata;
> }
>
> +static struct gpio_desc *bq24735_get_status_gpio(struct bq24735 *charger)
> +{
> + struct device *dev = &charger->client->dev;
> + struct bq24735_shared *shared;
> + int gpio;
> + enum of_gpio_flags flags;
> + int active_low;
> + struct list_head *pos;
> +
> + if (of_property_read_bool(dev->of_node, "ti,ac-detect-gpios"))
> + gpio = of_get_named_gpio_flags(dev->of_node,
> + "ti,ac-detect-gpios", 0, &flags);
> + else if (of_property_read_bool(dev->of_node, "ti,ac-detect-gpio"))
> + gpio = of_get_named_gpio_flags(dev->of_node,
> + "ti,ac-detect-gpio", 0, &flags);
> + else
> + return NULL;
> +
> + if (!gpio_is_valid(gpio))
> + return ERR_PTR(gpio);
> + active_low = flags & OF_GPIO_ACTIVE_LOW;
> +
> + mutex_lock(&shared_lock);
> + list_for_each(pos, &shared_list) {
> + shared = list_entry(pos, struct bq24735_shared, list);
> + if (gpio != desc_to_gpio(shared->status_gpio))
> + continue;
> + if (!active_low ^ !gpiod_is_active_low(shared->status_gpio))
> + continue;
> +
> + get_device(&shared->owner->client->dev);
> + dev_dbg(dev, "sharing gpio with %s\n",
> + shared->owner->pdata->name);
> + charger->shared = shared;
> + mutex_unlock(&shared_lock);
> + return shared->status_gpio;
> + }
> +
> + shared = devm_kzalloc(dev, sizeof(*shared), GFP_KERNEL);
> + if (!shared) {
> + mutex_unlock(&shared_lock);
> + return ERR_PTR(-ENOMEM);
> + }
> + shared->owner = charger;
> + shared->status_gpio = gpiod_get(dev, "ti,ac-detect", GPIOD_IN);
> + if (!IS_ERR(shared->status_gpio)) {
> + charger->shared = shared;
> + list_add(&shared->list, &shared_list);
> + }
> + mutex_unlock(&shared_lock);
> +
> + return shared->status_gpio;
> +}
> +
> +static void bq24735_put_status_gpio(struct bq24735 *charger)
> +{
> + if (!charger->shared)
> + return;
> +
> + mutex_lock(&shared_lock);
> + if (charger->shared->owner != charger) {
> + put_device(&charger->shared->owner->client->dev);
> + } else {
> + list_del(&charger->shared->list);
> + gpiod_put(charger->shared->status_gpio);
> + }
> + mutex_unlock(&shared_lock);
> +}
> +
> static int bq24735_charger_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -402,9 +484,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
>
> i2c_set_clientdata(client, charger);
>
> - charger->status_gpio = devm_gpiod_get_optional(&client->dev,
> - "ti,ac-detect",
> - GPIOD_IN);
> + charger->status_gpio = bq24735_get_status_gpio(charger);
> if (IS_ERR(charger->status_gpio)) {
> ret = PTR_ERR(charger->status_gpio);
> dev_err(&client->dev, "Getting gpio failed: %d\n", ret);
> @@ -416,28 +496,30 @@ static int bq24735_charger_probe(struct i2c_client *client,
> if (ret < 0) {
> dev_err(&client->dev, "Failed to read manufacturer id : %d\n",
> ret);
> - return ret;
> + goto out;
> } else if (ret != 0x0040) {
> dev_err(&client->dev,
> "manufacturer id mismatch. 0x0040 != 0x%04x\n", ret);
> - return -ENODEV;
> + ret = -ENODEV;
> + goto out;
> }
>
> ret = bq24735_read_word(client, BQ24735_DEVICE_ID);
> if (ret < 0) {
> dev_err(&client->dev, "Failed to read device id : %d\n", ret);
> - return ret;
> + goto out;
> } else if (ret != 0x000B) {
> dev_err(&client->dev,
> "device id mismatch. 0x000b != 0x%04x\n", ret);
> - return -ENODEV;
> + ret = -ENODEV;
> + goto out;
> }
> }
>
> ret = bq24735_config_charger(charger);
> if (ret < 0) {
> dev_err(&client->dev, "failed in configuring charger");
> - return ret;
> + goto out;
> }
>
> /* check for AC adapter presence */
> @@ -445,7 +527,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> ret = bq24735_enable_charging(charger);
> if (ret < 0) {
> dev_err(&client->dev, "Failed to enable charging\n");
> - return ret;
> + goto out;
> }
> }
>
> @@ -455,7 +537,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> ret = PTR_ERR(charger->charger);
> dev_err(&client->dev, "Failed to register power supply: %d\n",
> ret);
> - return ret;
> + goto out;
> }
>
> if (client->irq) {
> @@ -470,7 +552,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> dev_err(&client->dev,
> "Unable to register IRQ %d err %d\n",
> client->irq, ret);
> - return ret;
> + goto out;
> }
> } else if (charger->status_gpio) {
> ret = of_property_read_u32(client->dev.of_node,
> @@ -487,6 +569,11 @@ static int bq24735_charger_probe(struct i2c_client *client,
> }
>
> return 0;
> +
> +out:
> + bq24735_put_status_gpio(charger);
> +
> + return ret;
> }
>
> static int bq24735_charger_remove(struct i2c_client *client)
> @@ -496,6 +583,8 @@ static int bq24735_charger_remove(struct i2c_client *client)
> if (charger->poll_interval)
> cancel_delayed_work_sync(&charger->poll);
>
> + bq24735_put_status_gpio(charger);
> +
> return 0;
> }
>
> --
> 2.1.4
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches
From: Bartosz Golaszewski @ 2016-12-14 16:58 UTC (permalink / raw)
To: Rob Herring
Cc: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Mark Rutland, linux-iio, linux-devicetree,
LKML, Kevin Hilman, Patrick Titiano, Neil Armstrong,
Linus Walleij, Alexandre Courbot, linux-gpio, Sebastian Reichel,
linux-pm, Mark Brown, Liam Girdwood
In-Reply-To: <20161213192712.gbaw4t4awayybnta@rob-hp-laptop>
2016-12-13 20:27 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Sun, Dec 11, 2016 at 11:21:44PM +0100, Bartosz Golaszewski wrote:
>> Some boards are equipped with simple, GPIO-driven power load switches.
>> An example of such ICs is the TI tps229* series.
>
> How is this different than a GPIO regulator? The input and output
> voltages just happen to be the same. I could be convinced this is
> different enough to have a different compatible, but it somewhat seems
> you want to use this for IIO, so you are creating a different binding
> for that usecase.
>
It's more of a fixed regulator I suppose. Do you mean adding a new
compatible to the fixed-regulator binding (e.g. "gpio-power-switch" or
"simple-power-switch") and then providing an iio driver for toggling
the switch?
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH linux v1 0/4] Seven segment display support
From: Greg KH @ 2016-12-14 16:50 UTC (permalink / raw)
To: Neil Armstrong
Cc: Thomas Petazzoni, mark.rutland,
Jaghathiswari Rankappagounder Natarajan, arnd, devicetree,
openbmc, linux, linux-kernel, robh+dt, joel, linux-arm-kernel
In-Reply-To: <ac324946-41da-c090-a0ca-78155611bb7e@baylibre.com>
On Wed, Dec 14, 2016 at 02:12:41PM +0100, Neil Armstrong wrote:
> On 12/14/2016 01:56 PM, Greg KH wrote:
> > On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
> >> Hello,
> >>
> >> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
> >> Natarajan wrote:
> >>
> >>> Documentation for the binding which provides an interface for adding clock,
> >>> data and clear signal GPIO lines to control seven segment display.
> >>>
> >>> The platform device driver provides an API for displaying on two 7-segment
> >>> displays, and implements the required bit-banging. The hardware assumed is
> >>> 74HC164 wired to two 7-segment displays.
> >>>
> >>> The character device driver implements the user-space API for letting a user
> >>> write to two 7-segment displays including any conversion methods necessary
> >>> to map the user input to two 7-segment displays.
> >>>
> >>> Adding clock, data and clear signal GPIO lines in the devicetree to control
> >>> seven segment display on zaius platform.
> >>>
> >>> The platform driver matches on the device tree node; the platform driver also
> >>> initializes the character device.
> >>>
> >>> Tested that the seven segment display works properly by writing to the
> >>> character device file on a EVB AST2500 board which also has 74HC164 wired
> >>> to two 7-segment displays.
> >>
> >> FWIW, I proposed a driver for seven segment displays back in 2013:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
> >>
> >> And the feedback from Greg KH was: we don't need a driver for that, do
> >> it from userspace. See:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
> >>
> >> So: good luck :-)
> >
> > Did anyone ever write a library for this type of thing?
> >
> > Again, I don't want to see one-off drivers for random devices like this
> > that should be able to all be controlled from userspace in a common
> > manner. Much like we did for fingerprint readers a long long time
> > ago...
> >
> > thanks,
> >
> > greg k-h
>
> Hi Greg,
>
> Actually, it's more than a random interface, a lot of SoCs and boards actually have such displays
> and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly stuff to only print a few
> characters a simple and clean driver could achieve.
Great, then let's make an API that all devices of this type could use,
and not just take individual drivers that all have a custom char or
sysfs interface which requires custom userspace code to be able to drive
all of the different devices in a common way (i.e. a library would have
to be written anyways...)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] MIPS: NI 169445 board support
From: Rob Herring @ 2016-12-14 16:48 UTC (permalink / raw)
To: Nathan Sullivan
Cc: Ralf Baechle, Mark Rutland, Linux-MIPS,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20161214163253.GA25341@nathan3500-linux-VM>
On Wed, Dec 14, 2016 at 10:32 AM, Nathan Sullivan
<nathan.sullivan@ni.com> wrote:
> On Fri, Dec 09, 2016 at 03:18:28PM -0600, Rob Herring wrote:
>> On Fri, Dec 02, 2016 at 09:42:09AM -0600, Nathan Sullivan wrote:
>> > Support the National Instruments 169445 board.
>> >
>> > Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
>> > ---
>> > "gpio: mmio: add support for NI 169445 NAND GPIO" and
>> > "devicetree: add vendor prefix for National Instruments" are required for the
>> > NAND on this board to work.
>> > + ahb@0 {
>> > + compatible = "simple-bus";
>> > + #address-cells = <1>;
>> > + #size-cells = <1>;
>> > + ranges;
>>
>> If everything is under 0x1f3xxxxx, then add in the ranges here (and the
>> unit address).
>>
>
> I noticed that some systems call out their axi/ahb busses, some do not. Would
> you prefer that I remove the bus entirely?
Definitely not. IMO, not having a bus node is an error.
Rob
^ permalink raw reply
* Re: [PATCH v3 1/4] pinctrl: aspeed: Read and write bits in LPC and GFX controllers
From: Rob Herring @ 2016-12-14 16:46 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Linus Walleij, Mark Rutland, Joel Stanley,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1481609543.3112.34.camel@aj.id.au>
On Tue, Dec 13, 2016 at 12:12 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> On Mon, 2016-12-12 at 10:27 -0600, Rob Herring wrote:
>> On Tue, Dec 06, 2016 at 02:11:49PM +1100, Andrew Jeffery wrote:
>> > The System Control Unit IP block in the Aspeed SoCs is typically where
>> > the pinmux configuration is found, but not always. A number of pins
>> > depend on state in one of LPC Host Control (LHC) or SoC Display
>> > Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
>> > means to adjust these as necessary.
>> >
>> > We use syscon to cast a regmap over the GFX and LPC blocks, which is
>> > used as an arbitration layer between the relevant driver and the pinctrl
>> > subsystem. The regmaps are then exposed to the SoC-specific pinctrl
>> > drivers by phandles in the devicetree, and are selected during a mux
>> > request by querying a new 'ip' member in struct aspeed_sig_desc.
>> >
>> > > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
>> > ---
>> > .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 50 ++++++-
>> > drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 18 +--
>> > drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 48 ++++--
>> > drivers/pinctrl/aspeed/pinctrl-aspeed.c | 161 +++++++++++++--------
>> > drivers/pinctrl/aspeed/pinctrl-aspeed.h | 32 ++--
>> > 5 files changed, 214 insertions(+), 95 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
>> > index 2ad18c4ea55c..115b0cce6c1c 100644
>> > --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
>> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
>> > @@ -4,12 +4,19 @@ Aspeed Pin Controllers
>> > The Aspeed SoCs vary in functionality inside a generation but have a common mux
>> > device register layout.
>> >
>> > -Required properties:
>> > -- compatible : Should be any one of the following:
>> > > > - "aspeed,ast2400-pinctrl"
>> > > > - "aspeed,g4-pinctrl"
>> > > > - "aspeed,ast2500-pinctrl"
>> > > > - "aspeed,g5-pinctrl"
>> > +Required properties for g4:
>> > > > +- compatible : Should be any one of the following:
>> > > > + "aspeed,ast2400-pinctrl"
>> > > > + "aspeed,g4-pinctrl"
>> > +
>> > +Required properties for g5:
>> > > > +- compatible : Should be any one of the following:
>> > > > + "aspeed,ast2500-pinctrl"
>> > > > + "aspeed,g5-pinctrl"
>> > +
>> > > > +- aspeed,external-nodes: A cell of phandles to external controller nodes:
>> > > > + 0: compatible with "aspeed,ast2500-gfx", "syscon"
>> > > > + 1: compatible with "aspeed,ast2500-lpchc", "syscon"
>> >
>> > The pin controller node should be a child of a syscon node with the required
>> > property:
>> > @@ -47,7 +54,7 @@ RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU TIMER4 TIMER5 TIMER6
>> > TIMER7 TIMER8 VGABIOSROM
>> >
>> >
>> > -Examples:
>> > +g4 Example:
>> >
>> > > > syscon: scu@1e6e2000 {
>> > > > compatible = "syscon", "simple-mfd";
>> > > > @@ -63,5 +70,34 @@ syscon: scu@1e6e2000 {
>> > > > };
>> > };
>> >
>> > +g5 Example:
>> > +
>> > +apb {
>> > > > > > + gfx: display@1e6e6000 {
>> > > > + compatible = "aspeed,ast2500-gfx", "syscon";
>> > > > + reg = <0x1e6e6000 0x1000>;
>> > > > + };
>> > +
>> > > > > > + lpchc: lpchc@1e7890a0 {
>> > > > + compatible = "aspeed,ast2500-lpchc", "syscon";
>> > > > + reg = <0x1e7890a0 0xc4>;
>> > > > + };
>> > +
>> > > > > > + syscon: scu@1e6e2000 {
>> > + compatible = "syscon", "simple-mfd";
>>
>> I must have missed this the first time, but "syscon" should be used with
>> a specific compatible. Though, the scu binding does define one.
>
> Yes, the example should be fixed.
>
>>
>> > > > + reg = <0x1e6e2000 0x1a8>;
>> > +
>> > + pinctrl: pinctrl {
>>
>> Is this the only child?
>
> No. A incomplete list of other functions in the SCU includes:
>
> * An RNG
> * Power management
> * PCI configuration
> * System reset
> * Clock configuration
>
>>
>> > + compatible = "aspeed,g5-pinctrl";
>>
>> There's no register range for pinctrl?
>
> This may be a mistake on my part; when I wrote this I had no experience
> with writing devicetree bindings (and still don't have a lot).
>
> The SCU does have register regions for pinctrl but on reflection I feel
> neither the mfd nor syscon bindings describe how children's resources
> should be treated in general. The example in the mfd bindings is for
> hardware that is register-bit-led,compatible, whose bindings use the
> 'offset' property rather than 'reg', which still describes where, but
> not using the reg property. Given my uncertainty with reg in an mfd
> child, I wrote the pinctrl/pinmux driver using offsets from the base of
> the SCU's syscon rather than describing the exact region(s) of the
> syscon that should be used.
>
> The issue you raise here occurred to me when writing the LPC Host
> Controller bindings, but there I wasn't convinced using the ranges
> property to give offsets was the right thing to do either.
>
> Regardless, whilst there are two dedicated regions of pinmux registers,
> the mux state also depends on bits in SCU registers outside of these
> regions. Assuming we define an appropriate ranges property for the SCU
> syscon the pinctrl reg property would look like:
>
> reg = <0x2c 0x1>, <0x3c 0x1>, <0x48 0x1>, <0x70 0x1>, <0x7c 0x1>, <0x80 0x18>, <0xa0 0x10>, <0xd0 0x1>;
>
> This is the list of registers affecting the mux taken from the pinctrl-
> aspeed.h.
With other registers in the holes, right? If it is sparse like that,
then yes you probably just want to have reg in the parent for the
whole block.
> What action do you recommend here? The pinctrl dts patches for the
> Aspeed SoCs are yet to be applied, so changing the bindings to require
> a reg property can't break any existing in-tree users as there are
> none. The pinctrl driver can be patched to respect the reg property
> after the fact, though actually using the region descriptions might be
> interesting.
>
>>
>> > + aspeed,external-nodes = <&gfx, &lpchc>;
>
> Did you have feedback on this approach? I queried you about it in the
> previous revision, but never received a reply:
It seems okay. At least, I don't have a better suggestion.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/3] power: supply: bq24735-charger: simplify register update to stop charging
From: Sebastian Reichel @ 2016-12-14 16:41 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-kernel, Rob Herring, Mark Rutland, linux-pm, devicetree
In-Reply-To: <1481673405-4547-2-git-send-email-peda@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]
Hi,
On Wed, Dec 14, 2016 at 12:56:43AM +0100, Peter Rosin wrote:
> Providing value bits outside of the mask is pointless.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> drivers/power/supply/bq24735-charger.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/power/supply/bq24735-charger.c b/drivers/power/supply/bq24735-charger.c
> index eb7783b42e0a..1d5c9206e0ed 100644
> --- a/drivers/power/supply/bq24735-charger.c
> +++ b/drivers/power/supply/bq24735-charger.c
> @@ -111,8 +111,7 @@ static inline int bq24735_enable_charging(struct bq24735 *charger)
> return 0;
>
> return bq24735_update_word(charger->client, BQ24735_CHG_OPT,
> - BQ24735_CHG_OPT_CHARGE_DISABLE,
> - ~BQ24735_CHG_OPT_CHARGE_DISABLE);
> + BQ24735_CHG_OPT_CHARGE_DISABLE, 0);
> }
>
> static inline int bq24735_disable_charging(struct bq24735 *charger)
Thanks for your patch. We are currently in the merge
window and your patch will appear in linux-next once
4.10-rc1 has been tagged by Linus Torvalds.
Until then I queued it into this branch:
https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/log/?h=for-next-next
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] MIPS: NI 169445 board support
From: Nathan Sullivan @ 2016-12-14 16:32 UTC (permalink / raw)
To: Rob Herring
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, mark.rutland-5wv7dgnIgG8,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161209211828.dykl2l4kmthqgq6e@rob-hp-laptop>
On Fri, Dec 09, 2016 at 03:18:28PM -0600, Rob Herring wrote:
> On Fri, Dec 02, 2016 at 09:42:09AM -0600, Nathan Sullivan wrote:
> > Support the National Instruments 169445 board.
> >
> > Signed-off-by: Nathan Sullivan <nathan.sullivan-acOepvfBmUk@public.gmane.org>
> > ---
> > "gpio: mmio: add support for NI 169445 NAND GPIO" and
> > "devicetree: add vendor prefix for National Instruments" are required for the
> > NAND on this board to work.
>
> These should have been a series, but I already applied the first one.
>
> >
> > Documentation/devicetree/bindings/mips/ni.txt | 7 ++
> > arch/mips/Kbuild.platforms | 1 +
> > arch/mips/Kconfig | 26 ++++++
> > arch/mips/boot/dts/Makefile | 1 +
> > arch/mips/boot/dts/ni/169445.dts | 99 +++++++++++++++++++++
> > arch/mips/boot/dts/ni/Makefile | 9 ++
> > arch/mips/configs/ni169445_defconfig | 120 ++++++++++++++++++++++++++
> > arch/mips/ni169445/169445-console.c | 38 ++++++++
> > arch/mips/ni169445/169445-init.c | 39 +++++++++
> > arch/mips/ni169445/169445-int.c | 34 ++++++++
> > arch/mips/ni169445/169445-setup.c | 58 +++++++++++++
> > arch/mips/ni169445/169445-time.c | 35 ++++++++
> > arch/mips/ni169445/Makefile | 9 ++
> > arch/mips/ni169445/Platform | 6 ++
> > 14 files changed, 482 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mips/ni.txt
> > create mode 100644 arch/mips/boot/dts/ni/169445.dts
> > create mode 100644 arch/mips/boot/dts/ni/Makefile
> > create mode 100644 arch/mips/configs/ni169445_defconfig
> > create mode 100644 arch/mips/ni169445/169445-console.c
> > create mode 100644 arch/mips/ni169445/169445-init.c
> > create mode 100644 arch/mips/ni169445/169445-int.c
> > create mode 100644 arch/mips/ni169445/169445-setup.c
> > create mode 100644 arch/mips/ni169445/169445-time.c
> > create mode 100644 arch/mips/ni169445/Makefile
> > create mode 100644 arch/mips/ni169445/Platform
> >
> > diff --git a/Documentation/devicetree/bindings/mips/ni.txt b/Documentation/devicetree/bindings/mips/ni.txt
> > new file mode 100644
> > index 0000000..722bf2d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mips/ni.txt
> > @@ -0,0 +1,7 @@
> > +National Instruments MIPS platforms
> > +
> > +required root node properties:
> > + - compatible: must be "ni,169445"
> > +
> > +CPU Nodes
> > + - compatible: must be "mti,mips14KEc"
> > diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
> > index f5f1bdb..f2d7b5c 100644
> > --- a/arch/mips/Kbuild.platforms
> > +++ b/arch/mips/Kbuild.platforms
> > @@ -20,6 +20,7 @@ platforms += loongson32
> > platforms += loongson64
> > platforms += mti-malta
> > platforms += netlogic
> > +platforms += ni169445
> > platforms += paravirt
> > platforms += pic32
> > platforms += pistachio
> > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> > index b3c5bde..d24d11f 100644
> > --- a/arch/mips/Kconfig
> > +++ b/arch/mips/Kconfig
> > @@ -574,6 +574,32 @@ config NXP_STB225
> > help
> > Support for NXP Semiconductors STB225 Development Board.
> >
> > +config NI_169445
> > + bool "NI 169445 board"
> > + select ARCH_WANT_OPTIONAL_GPIOLIB
> > + select BOOT_ELF32
> > + select BOOT_RAW
> > + select BUILTIN_DTB
> > + select CEVT_R4K
> > + select CSRC_R4K
> > + select CPU_MIPSR2_IRQ_VI
> > + select CPU_MIPSR2_IRQ_EI
> > + select DMA_NONCOHERENT
> > + select IRQ_MIPS_CPU
> > + select LIBFDT
> > + select MIPS_MSC
> > + select SYS_HAS_CPU_MIPS32_R1
> > + select SYS_HAS_CPU_MIPS32_R2
> > + select SYS_HAS_EARLY_PRINTK
> > + select SYS_SUPPORTS_32BIT_KERNEL
> > + select SYS_SUPPORTS_LITTLE_ENDIAN
> > + select USE_OF
> > + select COMMON_CLK
> > + help
> > + This enables support for the National Instruments 169445A
> > + board.
> > +
> > +
> > config PMC_MSP
> > bool "PMC-Sierra MSP chipsets"
> > select CEVT_R4K
> > diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
> > index fc7a0a9..65a0ad8 100644
> > --- a/arch/mips/boot/dts/Makefile
> > +++ b/arch/mips/boot/dts/Makefile
> > @@ -3,6 +3,7 @@ dts-dirs += cavium-octeon
> > dts-dirs += ingenic
> > dts-dirs += lantiq
> > dts-dirs += mti
> > +dts-dirs += ni
> > dts-dirs += netlogic
> > dts-dirs += pic32
> > dts-dirs += qca
> > diff --git a/arch/mips/boot/dts/ni/169445.dts b/arch/mips/boot/dts/ni/169445.dts
> > new file mode 100644
> > index 0000000..a2b49f9
> > --- /dev/null
> > +++ b/arch/mips/boot/dts/ni/169445.dts
> > @@ -0,0 +1,99 @@
> > +/dts-v1/;
> > +
> > +/ {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "ni,169445";
> > +
> > + cpus {
> > + mips-hpt-frequency = <25000000>;
> > +
> > + cpu@0 {
> > + compatible = "mti,mips14KEc";
> > + };
> > + };
> > +
> > + memory {
>
> memory@0
>
> > + device_type = "memory";
> > + reg = <0x0 0x08000000>;
> > + };
> > +
> > + clocks {
> > + baseclk: baseclock {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <50000000>;
> > + };
> > + };
> > +
> > + cpu_intc: cpu_intc {
> > + #address-cells = <0>;
> > + compatible = "mti,cpu-interrupt-controller";
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + };
> > +
> > + ahb@0 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
>
> If everything is under 0x1f3xxxxx, then add in the ranges here (and the
> unit address).
>
I noticed that some systems call out their axi/ahb busses, some do not. Would
you prefer that I remove the bus entirely?
> > +
> > + gpio1: nand-gpio-out@1f300010 {
>
> As in the binding example: gpio-controller@...
>
> > + compatible = "ni,169445-nand-gpio";
> > + reg = <0x1f300010 0x4>;
> > + reg-names = "dat";
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + ngpios = <5>;
> > + };
> > +
> > + gpio2: nand-gpio-in@1f300014 {
>
> ditto
>
> > + compatible = "ni,169445-nand-gpio";
> > + reg = <0x1f300014 0x4>;
> > + reg-names = "dat";
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + ngpios = <1>;
> > + };
> > +
> > + nand@1f300000 {
> > + compatible = "gpio-control-nand";
> > + nand-on-flash-bbt;
> > + nand-ecc-mode = "soft_bch";
> > + nand-ecc-step-size = <512>;
> > + nand-ecc-strength = <4>;
> > + reg = <0x1f300000 4>;
> > + gpios = <&gpio2 0 0>, /* rdy */
> > + <&gpio1 1 0>, /* nce */
> > + <&gpio1 2 0>, /* ale */
> > + <&gpio1 3 0>, /* cle */
> > + <&gpio1 4 0>; /* nwp */
> > + };
> > +
> > + serial@1f380000 {
> > + compatible = "ns16550a";
> > + reg = <0x1f380000 0x1000>;
> > + interrupt-parent = <&cpu_intc>;
> > + interrupts = <6>;
> > + clocks = <&baseclk>;
> > + reg-shift = <0>;
> > + };
> > +
> > + ethernet@1f340000 {
> > + compatible = "snps,dwc-qos-ethernet-4.10";
> > + interrupt-parent = <&cpu_intc>;
> > + interrupts = <5>;
> > + reg = <0x1f340000 0x2000>;
> > + clock-names = "apb_pclk", "phy_ref_clk";
> > + clocks = <&baseclk>, <&baseclk>;
> > +
> > + phy-mode = "rgmii";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + };
> > + };
> > + };
> > +};
>
> [...]
>
> > diff --git a/arch/mips/ni169445/169445-setup.c b/arch/mips/ni169445/169445-setup.c
> > new file mode 100644
> > index 0000000..80a5c91
> > --- /dev/null
> > +++ b/arch/mips/ni169445/169445-setup.c
> > @@ -0,0 +1,58 @@
> > +/* Copyright 2016 National Instruments Corporation
> > + *
> > + * 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.
> > + */
> > +#include <linux/init.h>
> > +#include <linux/clk-provider.h>
> > +#include <linux/libfdt.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/of_fdt.h>
> > +
> > +#include <asm/prom.h>
> > +#include <asm/fw/fw.h>
> > +
> > +#include <asm/mips-boards/generic.h>
> > +
> > +const char *get_system_type(void)
> > +{
> > + return "NI 169445 FPGA";
>
> Perhaps this should come from model property. There's a patch in flight
> to add a function to get machine name.
>
> > +}
> > +
> > +void __init plat_mem_setup(void)
> > +{
> > + /*
> > + * Load the builtin devicetree. This causes the chosen node to be
> > + * parsed resulting in our memory appearing
> > + */
> > + __dt_setup_arch(__dtb_start);
> > +}
> > +
> > +void __init device_tree_init(void)
> > +{
> > + if (!initial_boot_params)
> > + return;
> > +
> > + unflatten_and_copy_device_tree();
> > +}
> > +
> > +static int __init customize_machine(void)
> > +{
> > + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>
> This should happen by default now.
>
> > + return 0;
> > +}
> > +arch_initcall(customize_machine);
Thank you for the feedback.
Nathan
--
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: clk: clk-mstp has never worked for RZ/A1
From: Chris Brandt @ 2016-12-14 16:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-renesas-soc@vger.kernel.org, geert+renesas@glider.be,
devicetree@vger.kernel.org
In-Reply-To: <CAMuHMdUJFSbX96pqY2Ogxztxz-SWCNfbe=d3eWKn+eWSdHLwfw@mail.gmail.com>
Hi Geert,
On Dec 14, 2016, Geert Uytterhoeven wrote:
> Another option is to let the driver bind against "renesas,r7s72100-mstp-
> clocks", and switch to 8-bit access mode.
>
> CLK_OF_DECLARE(cpg_mstp_clks, "renesas,r7s72100-mstp-clocks",
> cpg_mstp_clocks_init8);
>
> cpg_mstp_clocks_init8() can set a gloal flag, and call
> cpg_mstp_clocks_init().
>
> The latter means no DT update is needed, and thus preserves compatibility
> with old DTBs.
I just coded that and it works good. Thank you.
Now, one more question before I submit a patch for review:
I would like to add a "Fixes:" to the commit log so it can be considered for 4.9-stable (in reality it could go all the way back to when r7s72100 support was added)
But, the current file path didn't exist until after commit b3a33077c0dd ("clk: renesas: move drivers to renesas directory") on 2016-03-02.
So should I use that commit for my 'Fixes'?
Thanks,
Chris
^ permalink raw reply
* [PATCH v3 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
From: Andreas Klinger @ 2016-12-14 16:17 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, 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, ak-n176/SwNRljddJNmlsFzeA
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)
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-n176/SwNRljddJNmlsFzeA@public.gmane.org>
---
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
+
+ This driver uses two GPIOs, one for setting the clock and the other
+ one for getting the data
+
+ Currently the raw value is read from the chip and delivered.
+ For getting an actual weight one needs to subtract the
+ 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-n176/SwNRljddJNmlsFzeA@public.gmane.org>
+ *
+ * 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.
+ *
+ */
+#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);
+ 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 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);
+ 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,
+};
+
+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[] = {
+ { .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 (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);
+ 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-n176/SwNRljddJNmlsFzeA@public.gmane.org>");
+MODULE_DESCRIPTION("HX711 bitbanging driver - ADC for weight cells");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:hx711-gpio");
+
--
2.1.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 related
* [PATCH v3 1/2] iio: adc: hx711: Add DT binding for avia,hx711
From: Andreas Klinger @ 2016-12-14 16:16 UTC (permalink / raw)
To: devicetree, linux-iio
Cc: linux-kernel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, jic23, knaack.h, lars, pmeerw, ak
Add DT bindings for avia,hx711
Add vendor avia to vendor list
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
---
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
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
new file mode 100644
index 000000000000..27300b186cf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -0,0 +1,16 @@
+* AVIA HX711 ADC chip for weight cells
+ Bit-banging driver
+
+Required properties:
+ - compatible: Should be "avia,hx711"
+ - sck-gpios: Definition of the GPIO for the clock
+ - dout-gpios: Definition of the GPIO for data-out
+ See Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+weight@0 {
+ compatible = "avia,hx711";
+ sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
+ dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
+};
+
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 44ddc980b085..4696bb5c2198 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -32,6 +32,7 @@ atlas Atlas Scientific LLC
atmel Atmel Corporation
auo AU Optronics Corporation
avago Avago Technologies
+avia avia semiconductor
avic Shanghai AVIC Optoelectronics Co., Ltd.
axis Axis Communications AB
boe BOE Technology Group Co., Ltd.
--
2.1.4
^ permalink raw reply related
* [PATCH v3 0/2] iio: adc: hx711: Add IIO driver for AVIA HX711 ADC
From: Andreas Klinger @ 2016-12-14 16:16 UTC (permalink / raw)
To: devicetree, linux-iio
Cc: linux-kernel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, jic23, knaack.h, lars, pmeerw, ak
This series adds IIO driver support for the AVIA HX711 ADC which is
mostly used in weighting cells.
The first patch adds the new DT binding for which a new vendor avia
was also added.
The second patch is the simple IIO driver implemented as ADC.
The protocol is specific to this device and implemented using GPIO's.
Documentation of the chip can be found here:
https://cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf
Changes in v3:
moved gain from devicetree to sysfs, according to comment of Lars-Peter
Thanks for reviewing and giving suggestions
* Patch 1: "iio: adc: hx711: Add DT binding for avia,hx711"
- removed property gain
* Patch 2: "iio: adc: hx711: Add IIO driver for AVIA HX711"
- removed property gain from devicetree
- added device attribute (rw) for gain
- support reading from both channels now
Changes in v2:
Lots of updates thanks to Peters review.
* Patch 1: "iio: adc: hx711: Add DT binding for avia,hx711"
- typo
- removed unneded section
* Patch 2: "iio: adc: hx711: Add IIO driver for AVIA HX711"
- updated help text in Kconfig
- removed dead code
- removed unused power management
- reduced channel spec to what is actually used
- added error handling in case reset of chip not possible
Andreas Klinger (2):
iio: adc: hx711: Add DT binding for avia,hx711
iio: adc: hx711: Add IIO driver for AVIA HX711
.../devicetree/bindings/iio/adc/avia-hx711.txt | 16 ++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/iio/adc/Kconfig | 18 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/hx711.c | 292 +++++++++++++++++++++
5 files changed, 328 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
create mode 100644 drivers/iio/adc/hx711.c
--
2.1.4
^ 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