* 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 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 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] 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: 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
* [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
* [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 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
* 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
* Re: [PATCH linux v1 0/4] Seven segment display support
From: David Daney @ 2016-12-14 20:05 UTC (permalink / raw)
To: Arnd Bergmann, Neil Armstrong
Cc: Thomas Petazzoni, mark.rutland,
Jaghathiswari Rankappagounder Natarajan, devicetree, Greg KH,
openbmc, linux, linux-kernel, robh+dt, joel, linux-arm-kernel
In-Reply-To: <2512681.Wh85HyB8FH@wuerfel>
On 12/14/2016 06:15 AM, Arnd Bergmann wrote:
> On Wednesday, December 14, 2016 2:12:41 PM CET 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...
>>>
>
>> 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.
>> Some very well known SoCs even have integrated registers to lower the BOM and bypass the need for
>> a 74HC164 like component and avoid gpio bit banging.
>>
>> My personal concern is that you could also need to drive more segments, thus 7-segments
>> is too restrictive.
>>
>> But this driver is well structured, the gpio-bitbanging sub-driver is welcome.
>
> Maybe we can find a way to fit this into the existing drivers/leds/ subsystem?
>
> That already supports blinking, brightness and colour attributes of LEDs,
> so could this be extended to support (one of) digit, number, character
> or string with a common sysfs attribute and a way to hook up a led driver
> to that?
We have a lot of boards with an 8-cell dot matrix LED. Each cell is
programmed with an 8-bit value. The mapping of these values to the dots
defaults to ASCII character rendering, but there is the facility to
install other bitmaps as well.
Really I view these things not as part of the LED subsystem, but more as
a very small frame buffer.
We like to display entire words, and the most useful interface from a
user point of view is something that consumes entire strings rather than
having to manage each cell independently.
You could imagine that if the text to be displayed were longer than the
display, that the driver would make it continuously scroll. I would
like to see a framework where a simple character device were exposed,
and from userspace you could do: "echo message > /dev/small-display" and
get something sensible.
>
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Re: [PATCH 2/2] xilinx_dma: Add reset support
From: Laurent Pinchart @ 2016-12-14 20:16 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: <4220c66c29d83bec1ded798ee383b5460c162cfc.1481735244.git.roliveir@synopsys.com>
Hi Ramiro,
Thank you for the patch.
On Wednesday 14 Dec 2016 17:18:24 Ramiro Oliveira wrote:
> Add a DT property to control an optional external reset line
>
> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> ---
> 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>
I had neatly sorted the header alphabetically until someone added clk.h and
io-64-nonatomic-lo-hi.h :-( Could you please move reset.h just before slab.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");
devm_reset_control_get_optional() is deprecated as explained in linux/reset.h,
you should use devm_reset_control_get_optional_exclusive() or
devm_reset_control_get_optional_shared() instead, as applicable.
This being said, I'm wondering why the optional versions of those functions
exist, as they do exactly the same as the non-optional versions. The API feels
wrong, it should have been modelled like the GPIO API. Feel free to fix it if
you want :-) But that's out of scope for this patch.
> + if (IS_ERR(xdev->rst)) {
> + err = PTR_ERR(xdev->rst);
> + switch (err) {
> + case -ENOENT:
If you drop the name as proposed in the review of patch 1/2 you don't have to
check for -ENOENT.
> + case -ENOTSUPP:
> + xdev->rst = NULL;
> + break;
Wrong indentation.
You need to handle -EPROBE_DEFER and defer probing of the xilinx_dma device.
> + default:
> + dev_err(xdev->dev, "error getting reset %d\n", err);
> + return err;
Wrong indentation.
> + }
> + } else {
> + err = reset_control_deassert(xdev->rst);
> + if (err) {
> + dev_err(xdev->dev, "failed to deassert reset: %d\n",
> + err);
Wrong indentation.
> + 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)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/1] of: of_reserved_mem: Ensure cma reserved region not cross the low/high memory
From: Rob Herring @ 2016-12-14 20:45 UTC (permalink / raw)
To: Jason Liu
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Laura Abbott, Frank Rowand
In-Reply-To: <1479901021-25064-1-git-send-email-jason.hui.liu-3arQi8VN3Tc@public.gmane.org>
On Wed, Nov 23, 2016 at 5:37 AM, Jason Liu <jason.hui.liu-3arQi8VN3Tc@public.gmane.org> wrote:
> Need ensure the cma reserved region not cross the low/high memory boundary
> when using the dynamic allocation methond through device-tree, otherwise,
> kernel will fail to boot up when cma reserved region cross how/high mem.
The kernel command line code setting CMA already deals with this. Why
don't we just call the CMA code (cma_declare_contiguous) to deal with
this?
Rob
--
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] of/platform: depopulate devices in the reverse order of creation
From: Rob Herring @ 2016-12-14 20:54 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Frank Rowand, Pawel Moll, Grant Likely,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161212183905.GA30702-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Mon, Dec 12, 2016 at 12:39 PM, Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> If the DT has inter-dependencies, then the devices need to be removed
> in the right order to avoid removal problems.
>
> Assuming the DT is constructed so that EPROBE_DEFER doesn't happen
> during creating then a good way to avoid removal problems is reversing
> the order during depopulation.
I assume you mean by sorting the nodes to get lucky with the init
order. Not sure I want any patches that help that. I'm tempted to
randomize the device creation order instead.
> Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> ---
> drivers/of/platform.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> In my specific case I have a gpio driver, followed by a i2c bitbang
> using that driver. So gpiolib prints an error if it the gpio driver is
> removed before the gpio client..
Good news, functional dependencies are going into 4.10. Let's fix GPIO
and use that.
Rob
--
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
* [PATCH] ARM: dts: n900: Mark eMMC slot with no-sdio and no-sd flags
From: Pali Rohár @ 2016-12-14 21:29 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Rob Herring, Mark Rutland,
Russell King, Aaro Koskinen, Chris Ball, Ulf Hansson,
Pavel Machek, Ivaylo Dimitrov, Sebastian Reichel
Cc: linux-omap, devicetree, linux-arm-kernel, linux-kernel, linux-mmc,
Pali Rohár
Trying to initialize eMMC slot as SDIO or SD cause failure in n900 port of
qemu. eMMC itself is not detected and is not working.
Real Nokia N900 harware does not have this problem. As eMMC is really not
SDIO or SD based such change is harmless and will fix support for qemu.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
arch/arm/boot/dts/omap3-n900.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index bc8d6be..345a940 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -770,6 +770,8 @@
vmmc_aux-supply = <&vsim>;
bus-width = <8>;
non-removable;
+ no-sdio;
+ no-sd;
};
&mmc3 {
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 00/26] drm/omap: Convert to use videomode from omap_video_timings
From: Laurent Pinchart @ 2016-12-14 21:32 UTC (permalink / raw)
To: dri-devel
Cc: Peter Ujfalusi, thierry.reding, airlied, tomi.valkeinen,
Mark Rutland, devicetree, daniel.vetter, linux-kernel,
Rob Herring
In-Reply-To: <20160901112320.15246-1-peter.ujfalusi@ti.com>
Hi Peter,
On Thursday 01 Sep 2016 14:22:54 Peter Ujfalusi wrote:
> Hi,
>
> The following series will convert the omapdrm stack to use the generic
> videmode instead of the private omap_video_timings struct for the panel
> information.
>
> Since we have several panels under omapdrm/displays/ where the data drive
> edge is set to be different then the sync drive edge, the first three patch
> will add support to select the sync drive edge via DT.
> I was not able to locate the datasheet for all the panels and because the
> different edge was used in omapdrm and omapfb for a long time without
> complains from users - and they were written this way - I think it is a
> valid that we can have panels requiring different edge for data and sync to
> be driven.
That's very peculiar. Have you been able to locate at least one panel
datasheet that documents this requirement ?
> The rest of the patches are most mechanical ones. I have decided to split it
> up to small chunks and did one change at the time to finally remove the
> omap_video_timings from omapdrm.
>
>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Mark Rutland <mark.rutland@arm.com>
> CC: devicetree@vger.kernel.org
>
> Regards,
> Peter
> ---
> Peter Ujfalusi (26):
> dt-bindings: display: display-timing: Add property to configure sync
> drive edge
> video: display_timing: Add flags to select the edge when the sync is
> driven
> video: of: display_timing: Add support for syncclk-active property
> drm/omap: omap_display_timings: rename x_res to hactive
> drm/omap: omap_display_timings: rename y_res to vactive
> drm/omap: omap_display_timings: rename hsw to hsync_len
> drm/omap: omap_display_timings: rename hfp to hfront_porch
> drm/omap: omap_display_timings: rename hbp to hback_porch
> drm/omap: omap_display_timings: rename vsw to vsync_len
> drm/omap: omap_display_timings: rename vfp to vfront_porch
> drm/omap: omap_display_timings: rename vbp to vback_porch
> drm/omap: HDMI5: Use pointer to cfg->v_fc_config.timings in
> hdmi_core_video_config
> drm/omap: omap_display_timings: Use display_flags for interlace mode
> drm/omap: dispc: Simplify _dispc_mgr_set_lcd_timings() parameters
> drm/omap: omap_display_timings: Use display_flags for h/vsync level
> drm/omap: omap_display_timings: Use display_flags for DE level
> drm/omap: omap_display_timings: Use display_flags for double_pixel
> mode
> drm/omap: omap_display_timings: Use display_flags for pixel data edge
> drm/omap: omap_display_timings: Use display_flags for sync edge
> drm/omap: Change the types of struct omap_video_timings members
> drm/omap: Replace struct omap_video_timings with videomode
> drm/omap: Use consistent name for struct videomode
> drm/omap: panel-tpo-td043mtea1: Add note for incorrect sync drive edge
> drm/omap: panel-tpo-td028ttec1: Add note for incorrect sync drive edge
> drm/omap: panel-sharp-ls037v7dw01: Add note for incorrect data drive
> edge
> drm/omap: panel-lgphilips-lb035q02: Add note for incorrect data drive
> edge and DE level
>
> .../bindings/display/panel/display-timing.txt | 6 +
> .../gpu/drm/omapdrm/displays/connector-analog-tv.c | 47 ++---
> drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 50 +++--
> drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 49 +++--
> drivers/gpu/drm/omapdrm/displays/encoder-opa362.c | 20 +-
> drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 31 ++-
> .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 20 +-
> drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 30 ++-
> drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 25 ++-
> .../omapdrm/displays/panel-lgphilips-lb035q02.c | 59 +++---
> .../drm/omapdrm/displays/panel-nec-nl8048hl11.c | 52 +++--
> .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 58 +++---
> .../drm/omapdrm/displays/panel-sony-acx565akm.c | 53 +++--
> .../drm/omapdrm/displays/panel-tpo-td028ttec1.c | 57 +++---
> .../drm/omapdrm/displays/panel-tpo-td043mtea1.c | 54 ++---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 222 ++++++++----------
> drivers/gpu/drm/omapdrm/dss/display.c | 78 +-------
> drivers/gpu/drm/omapdrm/dss/dpi.c | 40 ++--
> drivers/gpu/drm/omapdrm/dss/dsi.c | 156 ++++++++-------
> drivers/gpu/drm/omapdrm/dss/dss.h | 5 +-
> drivers/gpu/drm/omapdrm/dss/hdmi.h | 8 +-
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 31 +--
> drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 8 +-
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 31 +--
> drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 85 ++++----
> drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 73 ++++---
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 98 +++------
> drivers/gpu/drm/omapdrm/dss/output.c | 5 +-
> drivers/gpu/drm/omapdrm/dss/rfbi.c | 49 +++--
> drivers/gpu/drm/omapdrm/dss/sdi.c | 33 ++-
> drivers/gpu/drm/omapdrm/dss/venc.c | 97 +++++----
> drivers/gpu/drm/omapdrm/omap_connector.c | 87 +-------
> drivers/gpu/drm/omapdrm/omap_crtc.c | 17 +-
> drivers/gpu/drm/omapdrm/omap_drv.h | 7 +-
> drivers/gpu/drm/omapdrm/omap_encoder.c | 10 +-
> drivers/video/of_display_timing.c | 9 +
> include/video/display_timing.h | 4 +
> 37 files changed, 778 insertions(+), 986 deletions(-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] ARM: dts: n900: Mark eMMC slot with no-sdio and no-sd flags
From: Pavel Machek @ 2016-12-14 21:34 UTC (permalink / raw)
To: Pali Rohár
Cc: Benoît Cousson, Tony Lindgren, Rob Herring, Mark Rutland,
Russell King, Aaro Koskinen, Chris Ball, Ulf Hansson,
Ivaylo Dimitrov, Sebastian Reichel,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481750984-11239-1-git-send-email-pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 630 bytes --]
On Wed 2016-12-14 22:29:44, Pali Rohár wrote:
> Trying to initialize eMMC slot as SDIO or SD cause failure in n900 port of
> qemu. eMMC itself is not detected and is not working.
>
> Real Nokia N900 harware does not have this problem. As eMMC is really not
> SDIO or SD based such change is harmless and will fix support for qemu.
>
> Signed-off-by: Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] of/platform: depopulate devices in the reverse order of creation
From: Jason Gunthorpe @ 2016-12-14 21:40 UTC (permalink / raw)
To: Rob Herring
Cc: Frank Rowand, Pawel Moll, Grant Likely,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_Jsq+JdmKj88Tp=N+V781qj+muEB6nuGpjDCgiPsrzB9tWMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Dec 14, 2016 at 02:54:02PM -0600, Rob Herring wrote:
> On Mon, Dec 12, 2016 at 12:39 PM, Jason Gunthorpe
> <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> > If the DT has inter-dependencies, then the devices need to be removed
> > in the right order to avoid removal problems.
> >
> > Assuming the DT is constructed so that EPROBE_DEFER doesn't happen
> > during creating then a good way to avoid removal problems is reversing
> > the order during depopulation.
>
> I assume you mean by sorting the nodes to get lucky with the init
> order.
Not quite, the init order doesn't matter, just that the device list/DT
is ordered topologically. The driver bind order can still be
randomized. No luck needed.
> > In my specific case I have a gpio driver, followed by a i2c bitbang
> > using that driver. So gpiolib prints an error if it the gpio driver is
> > removed before the gpio client..
>
> Good news, functional dependencies are going into 4.10. Let's fix GPIO
> and use that.
Sure, but it will be some time until that is used everwhere..
You don't think there is some value in 'hiding' the problem with
ordering until that work is done? IIRC that was essentially how
EPROBE_DEFER was introduced?
Jason
--
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: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
From: Heinrich Schuchardt @ 2016-12-14 21:44 UTC (permalink / raw)
To: Neil Armstrong, khilman, carlo
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <56869b90-6bee-f6ae-a7b1-884b4c0d72c0@baylibre.com>
On 12/14/2016 10:52 AM, Neil Armstrong wrote:
> On 12/12/2016 10:22 PM, Heinrich Schuchardt wrote:
>> On 12/12/2016 11:18 AM, Neil Armstrong wrote:
>>> The Amlogic Meson GXBB secure monitor uses part of the memory space, this
>>> patch adds these reserved zones and redefines the usable memory range for
>>> each boards.
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>> ---
>>> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
>>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 21 +++++++++++++++++++++
>>> .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +-
>>> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
>>> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
>>> .../boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +-
>>> .../boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 2 +-
>>> .../boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +-
>>> .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +-
>>> .../arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +-
>>> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +-
>>> 11 files changed, 31 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>>> index 7a078be..ac40b2d 100644
>>> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>>> @@ -56,7 +56,7 @@
>>>
>>> memory@0 {
>>> device_type = "memory";
>>> - reg = <0x0 0x0 0x0 0x80000000>;
>>> + reg = <0x0 0x1000000 0x0 0x7f000000>;
>>> };
>>>
>>> vddio_boot: regulator-vddio_boot {
>>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> index fc033c0..e085588 100644
>>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> @@ -55,6 +55,27 @@
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>>
>>> + reserved-memory {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + ranges;
>>> +
>>> + secos: secos {
>>> + reg = <0x0 0x05300000 0x0 0x2000000>;
>>> + no-map;
>>> + };
>>
>> Hello Neil,
>>
>> In
>> https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/meson64_odroidc2.dts
>> the secos region does not exist. In linux-next I find no reference to
>> the secos label. Where is the consumer of the region defined?
>>
>>> +
>>> + pstore: pstore {
>>> + reg = <0x0 0x07300000 0x0 0x100000>;
>>> + no-map;
>>> + };
>>
>> In
>> https://github.com/hardkernel/linux/blob/odroidc2-3.14.y/arch/arm64/boot/dts/amlogic/gxbb_skt.dts
>> and other files pstore uses a different position
>> (reg = <0x0 0x20000000 0x0 0x100000>;).
>> Why are we moving this?
>> Should this region be marked
>> compatible = "ramoops"; ?
>> Cf. Documentation/devicetree/bindings/reserved-memory/ramoops.txt.
>>
>> It would be nice if you could add a short description of each reserved
>> area to the commit message.
>>
>> Regards
>>
>> Heinrich Schuchardt
>>
>>> +
>>> + secmon: secmon {
>>> + reg = <0x0 0x10000000 0x0 0x200000>;
>>> + no-map;
>>> + };
>>> + };
>>> +
>>> cpus {
>>> #address-cells = <0x2>;
>>> #size-cells = <0x0>;
>>
>>
>
> Hi Heinrich,
>
> Thanks for testing and for the report,
> we are still struggling into finding what are these zones and how to label them correctly.
>
> We need to identify the zones on all boards, the patch I provided works on a non-odroid-c2 and gxm and gxl boards.
>
> Neil
>
Hi Neil,
the 3.14 Ubuntu kernel provided by Hardkernel for Odroid C2 has no fixed
address reserved-memory inside the first 2GB and does not show the
problem I have been observing with the linux-next kernel.
Many zones for interfacing different peripherals are defined but these
are all above 2GB.
For small loads I never saw any oops. So I recommend that on the boards
which you think are working, make a full linux-next git checkout and try
to build the kernel natively for the respective board.
Best regards
Heinrich Schuchardt
^ permalink raw reply
* [PATCH] ARM: dts: r8a7791: link DU to VSPDs
From: Sergei Shtylyov @ 2016-12-14 22:07 UTC (permalink / raw)
To: horms-/R6kz+dDXgpPR4JQBCEnsQ,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: magnus.damm-Re5JQEeQqe8AvxtiuMwx3w, linux-lFZ/pmaqli7XmaaqVzeoHQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1529351.Fac5N2tKoF-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
Add the "vsps" property to the DU device node in order to link this node to
the VSPD nodes.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
---
This patch is against the 'renesas-devel-20161212-v4.9' of Simon Horman's
'renesas.git' repo. It's only meaningful if the DU driver patch I've just
posted is applied.
arch/arm/boot/dts/r8a7791.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
+++ renesas/arch/arm/boot/dts/r8a7791.dtsi
@@ -989,7 +989,7 @@
power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
};
- vsp1@fe930000 {
+ vspd0: vsp1@fe930000 {
compatible = "renesas,vsp1";
reg = <0 0xfe930000 0 0x8000>;
interrupts = <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>;
@@ -997,7 +997,7 @@
power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
};
- vsp1@fe938000 {
+ vspd1: vsp1@fe938000 {
compatible = "renesas,vsp1";
reg = <0 0xfe938000 0 0x8000>;
interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>;
@@ -1016,6 +1016,7 @@
<&mstp7_clks R8A7791_CLK_DU1>,
<&mstp7_clks R8A7791_CLK_LVDS0>;
clock-names = "du.0", "du.1", "lvds.0";
+ vsps = <&vspd0 &vspd1>;
status = "disabled";
ports {
--
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/1] of: of_reserved_mem: Ensure cma reserved region not cross the low/high memory
From: Laura Abbott @ 2016-12-14 22:21 UTC (permalink / raw)
To: Rob Herring, Jason Liu
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Frank Rowand
In-Reply-To: <CAL_JsqLHh96D0VULuYfYC1P5K_Bbz6iRjizuYP3Mb6bdERbDnA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/14/2016 12:45 PM, Rob Herring wrote:
> On Wed, Nov 23, 2016 at 5:37 AM, Jason Liu <jason.hui.liu-3arQi8VN3Tc@public.gmane.org> wrote:
>> Need ensure the cma reserved region not cross the low/high memory boundary
>> when using the dynamic allocation methond through device-tree, otherwise,
>> kernel will fail to boot up when cma reserved region cross how/high mem.
>
> The kernel command line code setting CMA already deals with this. Why
> don't we just call the CMA code (cma_declare_contiguous) to deal with
> this?
>
> Rob
>
That was proposed in the first version[1] but I think this is a generic
problem not specific to CMA. Even non-CMA reservations trying to span
zones could cause problems so the devicetree allocation code should
restrict reservations to a single zone.
Thanks,
Laura
[1] https://marc.info/?l=linux-kernel&m=147928325113103&w=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
* [PATCH 0/6] Add board support for TS-4600
From: Sebastien Bourdelin @ 2016-12-14 23:12 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
kernel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/
Cc: mark-L1vi/lXTdtvnC/t2CciAbw, kris-L1vi/lXTdtvnC/t2CciAbw,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
treding-DDmLM1+adcrQT0dZR+AlfA, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, fabio.estevam-3arQi8VN3Tc,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-0h96xk9xTtrk1uMJSBkQmQ,
wim-IQzOog9fTRqzQB+pC5nmwQ, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
damien.riegel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
lucile.quirion-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
olof-nZhT3qVonbNeoWH0uzbU5w, arnd-r2nGTMty4D4,
suzuki.poulose-5wv7dgnIgG8, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
will.deacon-5wv7dgnIgG8, yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
Sebastien Bourdelin
This patch serie adds support for the TS-4600 boards rev A and B. These
boards, manufactured by Technologic Systems, are based on an i.MX28.
This serie include the support for the watchdog which could be enable
at Linux boot time depending on the bootloader.
The watchdog and few peripherals are implemented in a FPGA, and can
only be access using a custom GPIOs bit-banged bus which is called the
NBUS by Technologic Systems.
A driver for this bus is also included and used by the watchdog.
Sebastien Bourdelin (6):
of: documentation: add bindings documentation for TS-4600
ARM: dts: TS-4600: add basic device tree
dt-bindings: bus: Add documentation for the Technologic Systems NBUS
bus: add driver for the Technologic Systems NBUS
ARM: dts: TS-4600: add NBUS support
watchdog: ts4600: add driver for TS-4600 watchdog
.../devicetree/bindings/arm/technologic.txt | 5 +
Documentation/devicetree/bindings/bus/ts-nbus.txt | 50 +++
.../devicetree/bindings/watchdog/ts4600-wdt.txt | 16 +
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx28-ts4600-common.dtsi | 126 ++++++
arch/arm/boot/dts/imx28-ts4600-rev-a.dts | 22 +
arch/arm/boot/dts/imx28-ts4600-rev-b.dts | 22 +
drivers/bus/Kconfig | 9 +
drivers/bus/Makefile | 1 +
drivers/bus/ts-nbus.c | 451 +++++++++++++++++++++
drivers/watchdog/Kconfig | 10 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/ts4600_wdt.c | 213 ++++++++++
include/linux/ts-nbus.h | 17 +
14 files changed, 945 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/ts-nbus.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
create mode 100644 arch/arm/boot/dts/imx28-ts4600-common.dtsi
create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-a.dts
create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-b.dts
create mode 100644 drivers/bus/ts-nbus.c
create mode 100644 drivers/watchdog/ts4600_wdt.c
create mode 100644 include/linux/ts-nbus.h
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/6] of: documentation: add bindings documentation for TS-4600
From: Sebastien Bourdelin @ 2016-12-14 23:12 UTC (permalink / raw)
To: linux-kernel, linux-watchdog, linux-arm-kernel, devicetree,
kernel
Cc: mark, kris, horms+renesas, treding, jonathanh, f.fainelli,
fabio.estevam, kernel, shawnguo, linux, linux, wim, mark.rutland,
robh+dt, damien.riegel, lucile.quirion, olof, arnd,
suzuki.poulose, linus.walleij, will.deacon, yamada.masahiro,
Sebastien Bourdelin
In-Reply-To: <20161214231237.17496-1-sebastien.bourdelin@savoirfairelinux.com>
This adds the documentation for the TS-4600 by Technologic Systems.
Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
---
Documentation/devicetree/bindings/arm/technologic.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/technologic.txt b/Documentation/devicetree/bindings/arm/technologic.txt
index 33797ac..e9d6d65 100644
--- a/Documentation/devicetree/bindings/arm/technologic.txt
+++ b/Documentation/devicetree/bindings/arm/technologic.txt
@@ -1,6 +1,11 @@
Technologic Systems Platforms Device Tree Bindings
--------------------------------------------------
+TS-4600 is a System-on-Module based on the Freescale i.MX28 System-on-Chip.
+It can be mounted on a carrier board providing additional peripheral connectors.
+Required root node properties:
+ - compatible = "technologic,imx28-ts4600", "fsl,imx28"
+
TS-4800 board
Required root node properties:
- compatible = "technologic,imx51-ts4800", "fsl,imx51";
--
2.10.2
^ permalink raw reply related
* [PATCH 2/6] ARM: dts: TS-4600: add basic device tree
From: Sebastien Bourdelin @ 2016-12-14 23:12 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
kernel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/
Cc: mark-L1vi/lXTdtvnC/t2CciAbw, kris-L1vi/lXTdtvnC/t2CciAbw,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
treding-DDmLM1+adcrQT0dZR+AlfA, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, fabio.estevam-3arQi8VN3Tc,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-0h96xk9xTtrk1uMJSBkQmQ,
wim-IQzOog9fTRqzQB+pC5nmwQ, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
damien.riegel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
lucile.quirion-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
olof-nZhT3qVonbNeoWH0uzbU5w, arnd-r2nGTMty4D4,
suzuki.poulose-5wv7dgnIgG8, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
will.deacon-5wv7dgnIgG8, yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
Sebastien Bourdelin
In-Reply-To: <20161214231237.17496-1-sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
These device trees add support for the TS-4600 by Technologic Systems.
More details here:
http://wiki.embeddedarm.com/wiki/TS-4600
Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx28-ts4600-common.dtsi | 78 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx28-ts4600-rev-a.dts | 22 +++++++++
arch/arm/boot/dts/imx28-ts4600-rev-b.dts | 22 +++++++++
4 files changed, 124 insertions(+)
create mode 100644 arch/arm/boot/dts/imx28-ts4600-common.dtsi
create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-a.dts
create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-b.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c558ba7..5a79fab 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -466,6 +466,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
imx28-m28cu3.dtb \
imx28-m28evk.dtb \
imx28-sps1.dtb \
+ imx28-ts4600-rev-a.dtb \
+ imx28-ts4600-rev-b.dtb \
imx28-tx28.dtb
dtb-$(CONFIG_ARCH_NOMADIK) += \
ste-nomadik-s8815.dtb \
diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
new file mode 100644
index 0000000..04bd5a5
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
@@ -0,0 +1,78 @@
+/*
+ * Copyright (C) 2016 Savoir-Faire Linux
+ * Author: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "imx28.dtsi"
+#include "dt-bindings/gpio/gpio.h"
+
+/ {
+
+ compatible = "technologic,imx28-ts4600", "fsl,imx28";
+
+ apb@80000000 {
+ apbh@80000000 {
+ ssp0: ssp@80010000 {
+ compatible = "fsl,imx28-mmc";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_4bit_pins_a
+ &mmc0_sck_cfg
+ &en_sd_pwr>;
+ broken-cd = <1>;
+ bus-width = <4>;
+ vmmc-supply = <®_vddio_sd0>;
+ status = "okay";
+ };
+
+ pinctrl@80018000 {
+ pinctrl-names = "default";
+
+ en_sd_pwr: en_sd_pwr {
+ fsl,pinmux-ids = <
+ MX28_PAD_PWM3__GPIO_3_28
+ >;
+ fsl,drive-strength = <MXS_DRIVE_4mA>;
+ fsl,voltage = <MXS_VOLTAGE_HIGH>;
+ fsl,pull-up = <MXS_PULL_DISABLE>;
+ };
+
+ };
+ };
+
+ apbx@80040000 {
+ pwm: pwm@80064000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm2_pins_a>;
+ status = "okay";
+ };
+
+ duart: serial@80074000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&duart_pins_a>;
+ status = "okay";
+ };
+ };
+ };
+
+ regulators {
+ compatible = "simple-bus";
+
+ reg_vddio_sd0: vddio-sd0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vddio-sd0";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ gpio = <&gpio3 28 0>;
+ };
+ };
+
+};
diff --git a/arch/arm/boot/dts/imx28-ts4600-rev-a.dts b/arch/arm/boot/dts/imx28-ts4600-rev-a.dts
new file mode 100644
index 0000000..e8cb729
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-ts4600-rev-a.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2016 Savoir-Faire Linux
+ * Author: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx28-ts4600-common.dtsi"
+
+/ {
+ model = "Technologic Systems i.MX28 TS-4600 Rev A";
+
+ memory {
+ reg = <0x40000000 0x08000000>; /* 128MB */
+ };
+
+};
diff --git a/arch/arm/boot/dts/imx28-ts4600-rev-b.dts b/arch/arm/boot/dts/imx28-ts4600-rev-b.dts
new file mode 100644
index 0000000..a115f83
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-ts4600-rev-b.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2016 Savoir-Faire Linux
+ * Author: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx28-ts4600-common.dtsi"
+
+/ {
+ model = "Technologic Systems i.MX28 TS-4600 Rev B";
+
+ memory {
+ reg = <0x40000000 0x10000000>; /* 256MB */
+ };
+
+};
--
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 3/6] dt-bindings: bus: Add documentation for the Technologic Systems NBUS
From: Sebastien Bourdelin @ 2016-12-14 23:12 UTC (permalink / raw)
To: linux-kernel, linux-watchdog, linux-arm-kernel, devicetree,
kernel
Cc: mark.rutland, linus.walleij, will.deacon, kris, yamada.masahiro,
wim, f.fainelli, damien.riegel, linux, jonathanh, treding, linux,
arnd, suzuki.poulose, lucile.quirion, fabio.estevam, robh+dt,
horms+renesas, Sebastien Bourdelin, mark, kernel, olof, shawnguo
In-Reply-To: <20161214231237.17496-1-sebastien.bourdelin@savoirfairelinux.com>
Add binding documentation for the Technologic Systems NBUS that is used
to interface with peripherals in the FPGA of the TS-4600 SoM.
Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
---
Documentation/devicetree/bindings/bus/ts-nbus.txt | 50 +++++++++++++++++++++++
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/ts-nbus.txt
diff --git a/Documentation/devicetree/bindings/bus/ts-nbus.txt b/Documentation/devicetree/bindings/bus/ts-nbus.txt
new file mode 100644
index 0000000..2f777ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ts-nbus.txt
@@ -0,0 +1,50 @@
+Technologic Systems NBUS
+
+The NBUS is a bus used to interface with peripherals in the Technologic
+Systems FPGA on the TS-4600 SoM.
+
+Required properties :
+ - compatible : "technologic,ts-nbus", "simple-bus"
+ - #address-cells : must be 1
+ - #size-cells : must be 0
+ - pws : The PWM pin connected to the clock line on the FPGA
+ - data-gpios : The GPIO pin connected to the data line on the FPGA
+ - csn-gpios : The GPIO pin connected to the csn line on the FPGA
+ - txrx-gpios : The GPIO pin connected to the txrx line on the FPGA
+ - strobe-gpios : The GPIO pin connected to the stobe line on the FPGA
+ - ale-gpios : The GPIO pin connected to the ale line on the FPGA
+ - rdy-gpios : The GPIO pin connected to the rdy line on the FPGA
+
+Child nodes:
+
+The NBUS node can contain zero or more child nodes representing peripherals
+on the bus.
+
+Example:
+
+ nbus {
+ compatible = "technologic,ts-nbus", "simple-bus";
+ pinctrl-0 = <&nbus_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pwms = <&pwm 2 83>;
+ data-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH
+ &gpio0 1 GPIO_ACTIVE_HIGH
+ &gpio0 2 GPIO_ACTIVE_HIGH
+ &gpio0 3 GPIO_ACTIVE_HIGH
+ &gpio0 4 GPIO_ACTIVE_HIGH
+ &gpio0 5 GPIO_ACTIVE_HIGH
+ &gpio0 6 GPIO_ACTIVE_HIGH
+ &gpio0 7 GPIO_ACTIVE_HIGH>;
+ csn-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
+ txrx-gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
+ strobe-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
+ ale-gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
+ rdy-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
+
+ wdt@2a {
+ compatible = "...";
+
+ /* ... */
+ };
+ };
--
2.10.2
^ permalink raw reply related
* [PATCH 4/6] bus: add driver for the Technologic Systems NBUS
From: Sebastien Bourdelin @ 2016-12-14 23:12 UTC (permalink / raw)
To: linux-kernel, linux-watchdog, linux-arm-kernel, devicetree,
kernel
Cc: mark, kris, horms+renesas, treding, jonathanh, f.fainelli,
fabio.estevam, kernel, shawnguo, linux, linux, wim, mark.rutland,
robh+dt, damien.riegel, lucile.quirion, olof, arnd,
suzuki.poulose, linus.walleij, will.deacon, yamada.masahiro,
Sebastien Bourdelin
In-Reply-To: <20161214231237.17496-1-sebastien.bourdelin@savoirfairelinux.com>
This driver implements a GPIOs bit-banged bus, called the NBUS by
Technologic Systems. It is used to communicate with the peripherals in
the FPGA on the TS-4600 SoM.
Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
---
drivers/bus/Kconfig | 9 +
drivers/bus/Makefile | 1 +
drivers/bus/ts-nbus.c | 451 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/ts-nbus.h | 17 ++
4 files changed, 478 insertions(+)
create mode 100644 drivers/bus/ts-nbus.c
create mode 100644 include/linux/ts-nbus.h
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 7875105..74e72b3 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -150,6 +150,15 @@ config TEGRA_ACONNECT
Driver for the Tegra ACONNECT bus which is used to interface with
the devices inside the Audio Processing Engine (APE) for Tegra210.
+config TS_NBUS
+ tristate "Technologic Systems NBUS Driver"
+ default y
+ depends on SOC_IMX28
+ depends on OF_GPIO && PWM
+ help
+ Driver for the Technologic Systems NBUS which is used to interface
+ with the peripherals in the FPGA of the TS-4600 SoM.
+
config UNIPHIER_SYSTEM_BUS
tristate "UniPhier System Bus driver"
depends on ARCH_UNIPHIER && OF
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index c6cfa6b..83f874a 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -19,5 +19,6 @@ obj-$(CONFIG_QCOM_EBI2) += qcom-ebi2.o
obj-$(CONFIG_SUNXI_RSB) += sunxi-rsb.o
obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o
obj-$(CONFIG_TEGRA_ACONNECT) += tegra-aconnect.o
+obj-$(CONFIG_TS_NBUS) += ts-nbus.o
obj-$(CONFIG_UNIPHIER_SYSTEM_BUS) += uniphier-system-bus.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
diff --git a/drivers/bus/ts-nbus.c b/drivers/bus/ts-nbus.c
new file mode 100644
index 0000000..44fc89d
--- /dev/null
+++ b/drivers/bus/ts-nbus.c
@@ -0,0 +1,451 @@
+/*
+ * NBUS driver for TS-4600 based boards
+ *
+ * Copyright (c) 2016 - Savoir-faire Linux
+ * Author: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * This driver implements a GPIOs bit-banged bus, called the NBUS by Technologic
+ * Systems. It is used to communicate with the peripherals in the FPGA on the
+ * TS-4600 SoM.
+ */
+
+#include <linux/gpio.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+
+static DEFINE_MUTEX(ts_nbus_lock);
+static bool ts_nbus_ready;
+
+#define TS_NBUS_READ_MODE 0
+#define TS_NBUS_WRITE_MODE 1
+#define TS_NBUS_DIRECTION_IN 0
+#define TS_NBUS_DIRECTION_OUT 1
+#define TS_NBUS_WRITE_ADR 0
+#define TS_NBUS_WRITE_VAL 1
+
+struct ts_nbus {
+ struct pwm_device *pwm;
+ int num_data;
+ int *data;
+ int csn;
+ int txrx;
+ int strobe;
+ int ale;
+ int rdy;
+};
+
+static struct ts_nbus *ts_nbus;
+
+/*
+ * request all gpios required by the bus.
+ */
+static int ts_nbus_init(struct platform_device *pdev)
+{
+ int err;
+ int i;
+
+ for (i = 0; i < ts_nbus->num_data; i++) {
+ err = devm_gpio_request_one(&pdev->dev, ts_nbus->data[i],
+ GPIOF_OUT_INIT_HIGH,
+ "TS NBUS data");
+ if (err)
+ return err;
+ }
+
+ err = devm_gpio_request_one(&pdev->dev, ts_nbus->csn,
+ GPIOF_OUT_INIT_HIGH,
+ "TS NBUS csn");
+ if (err)
+ return err;
+
+ err = devm_gpio_request_one(&pdev->dev, ts_nbus->txrx,
+ GPIOF_OUT_INIT_HIGH,
+ "TS NBUS txrx");
+ if (err)
+ return err;
+
+ err = devm_gpio_request_one(&pdev->dev, ts_nbus->strobe,
+ GPIOF_OUT_INIT_HIGH,
+ "TS NBUS strobe");
+ if (err)
+ return err;
+
+ err = devm_gpio_request_one(&pdev->dev, ts_nbus->ale,
+ GPIOF_OUT_INIT_HIGH,
+ "TS NBUS ale");
+ if (err)
+ return err;
+
+ err = devm_gpio_request_one(&pdev->dev, ts_nbus->rdy,
+ GPIOF_IN,
+ "TS NBUS rdy");
+ if (err)
+ return err;
+
+ return 0;
+}
+
+/*
+ * retrieve all gpios used by the bus from the device tree.
+ */
+static int ts_nbus_get_of_pdata(struct device *dev, struct device_node *np)
+{
+ int num_data;
+ int *data;
+ int ret;
+ int i;
+
+ ret = of_gpio_named_count(np, "data-gpios");
+ if (ret < 0) {
+ dev_err(dev,
+ "failed to count GPIOs in DT property data-gpios\n");
+ return ret;
+ }
+ num_data = ret;
+ data = devm_kzalloc(dev, num_data * sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ for (i = 0; i < num_data; i++) {
+ ret = of_get_named_gpio(np, "data-gpios", i);
+ if (ret < 0) {
+ dev_err(dev, "failed to retrieve data-gpio from dts\n");
+ return ret;
+ }
+ data[i] = ret;
+ }
+ ts_nbus->num_data = num_data;
+ ts_nbus->data = data;
+
+ ret = of_get_named_gpio(np, "csn-gpios", 0);
+ if (ret < 0) {
+ dev_err(dev, "failed to retrieve csn-gpio from dts\n");
+ return ret;
+ }
+ ts_nbus->csn = ret;
+
+ ret = of_get_named_gpio(np, "txrx-gpios", 0);
+ if (ret < 0) {
+ dev_err(dev, "failed to retrieve txrx-gpio from dts\n");
+ return ret;
+ }
+ ts_nbus->txrx = ret;
+
+ ret = of_get_named_gpio(np, "strobe-gpios", 0);
+ if (ret < 0) {
+ dev_err(dev, "failed to retrieve strobe-gpio from dts\n");
+ return ret;
+ }
+ ts_nbus->strobe = ret;
+
+ ret = of_get_named_gpio(np, "ale-gpios", 0);
+ if (ret < 0) {
+ dev_err(dev, "failed to retrieve ale-gpio from dts\n");
+ return ret;
+ }
+ ts_nbus->ale = ret;
+
+ ret = of_get_named_gpio(np, "rdy-gpios", 0);
+ if (ret < 0) {
+ dev_err(dev, "failed to retrieve rdy-gpio from dts\n");
+ return ret;
+ }
+ ts_nbus->rdy = ret;
+
+ return 0;
+}
+
+/*
+ * the txrx gpio is used by the FPGA to know if the following transactions
+ * should be handled to read or write a value.
+ */
+static inline void ts_nbus_set_mode(int mode)
+{
+ if (mode == TS_NBUS_READ_MODE)
+ gpio_set_value(ts_nbus->txrx, 0);
+ else
+ gpio_set_value(ts_nbus->txrx, 1);
+}
+
+/*
+ * the data gpios are used for reading and writing values, their directions
+ * should be adjusted accordingly.
+ */
+static inline void ts_nbus_set_direction(int direction)
+{
+ int i;
+
+ for (i = 0; i < ts_nbus->num_data; i++) {
+ if (direction == TS_NBUS_DIRECTION_IN)
+ gpio_direction_input(ts_nbus->data[i]);
+ else
+ gpio_direction_output(ts_nbus->data[i], 1);
+ }
+}
+
+/*
+ * reset the bus in its initial state.
+ */
+static inline void ts_nbus_reset_bus(void)
+{
+ int i;
+
+ for (i = 0; i < ts_nbus->num_data; i++)
+ gpio_set_value(ts_nbus->data[i], 0);
+
+ gpio_set_value(ts_nbus->csn, 0);
+ gpio_set_value(ts_nbus->strobe, 0);
+ gpio_set_value(ts_nbus->ale, 0);
+}
+
+/*
+ * let the FPGA knows it can process.
+ */
+static inline void ts_nbus_start_transaction(void)
+{
+ gpio_set_value(ts_nbus->strobe, 1);
+}
+
+/*
+ * return the byte value read from the data gpios.
+ */
+static inline u8 ts_nbus_read_byte(void)
+{
+ int i;
+ u8 value = 0;
+
+ for (i = 0; i < ts_nbus->num_data; i++)
+ if (ts_nbus->data[i])
+ value |= 1 << i;
+
+ return value;
+}
+
+/*
+ * set the data gpios accordingly to the byte value.
+ */
+static inline void ts_nbus_write_byte(u8 byte)
+{
+ int i;
+
+ for (i = 0; i < ts_nbus->num_data; i++)
+ if (byte & (1 << i))
+ gpio_set_value(ts_nbus->data[i], 1);
+}
+
+/*
+ * reading the bus consists of resetting the bus, then notifying the FPGA to
+ * send the data in the data gpios and return the read value.
+ */
+static inline u8 ts_nbus_read_bus(void)
+{
+ ts_nbus_reset_bus();
+ ts_nbus_start_transaction();
+
+ return ts_nbus_read_byte();
+}
+
+/*
+ * writing to the bus consists of resetting the bus, then define the type of
+ * command (address/value), write the data and notify the FPGA to retrieve the
+ * value in the data gpios.
+ */
+static inline void ts_nbus_write_bus(int cmd, u8 value)
+{
+ ts_nbus_reset_bus();
+
+ if (cmd == TS_NBUS_WRITE_ADR)
+ gpio_set_value(ts_nbus->ale, 1);
+
+ ts_nbus_write_byte(value);
+ ts_nbus_start_transaction();
+}
+
+/*
+ * read the value in the FPGA register at the given address.
+ */
+u16 ts_nbus_read(u8 adr)
+{
+ int i;
+ u16 val;
+
+ /* bus access must be atomic */
+ mutex_lock(&ts_nbus_lock);
+
+ /* set the bus in read mode */
+ ts_nbus_set_mode(TS_NBUS_READ_MODE);
+
+ /* write address */
+ ts_nbus_write_bus(TS_NBUS_WRITE_ADR, adr);
+
+ /* set the data gpios direction as input before reading */
+ ts_nbus_set_direction(TS_NBUS_DIRECTION_IN);
+
+ /* reading value MSB first */
+ do {
+ val = 0;
+ for (i = 1; i >= 0; i--)
+ val |= (ts_nbus_read_bus() << (i * 8));
+ gpio_set_value(ts_nbus->csn, 1);
+ } while (gpio_get_value(ts_nbus->rdy));
+
+ /* restore the data gpios direction as output after reading */
+ ts_nbus_set_direction(TS_NBUS_DIRECTION_OUT);
+
+ mutex_unlock(&ts_nbus_lock);
+
+ return val;
+}
+EXPORT_SYMBOL_GPL(ts_nbus_read);
+
+/*
+ * write the desired value in the FPGA register at the given address.
+ */
+int ts_nbus_write(u8 adr, u16 value)
+{
+ int i;
+
+ /* bus access must be atomic */
+ mutex_lock(&ts_nbus_lock);
+
+ /* set the bus in write mode */
+ ts_nbus_set_mode(TS_NBUS_WRITE_MODE);
+
+ /* write address */
+ ts_nbus_write_bus(TS_NBUS_WRITE_ADR, adr);
+
+ /* writing value MSB first */
+ for (i = 1; i >= 0; i--)
+ ts_nbus_write_bus(TS_NBUS_WRITE_VAL, (u8)(value >> (i * 8)));
+
+ /* wait for completion */
+ gpio_set_value(ts_nbus->csn, 1);
+ while (gpio_get_value(ts_nbus->rdy) != 0) {
+ gpio_set_value(ts_nbus->csn, 0);
+ gpio_set_value(ts_nbus->csn, 1);
+ }
+
+ mutex_unlock(&ts_nbus_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ts_nbus_write);
+
+/*
+ * helper function to know the state of the bus.
+ * this function is useful to let peripherals defer their probing while the bus
+ * is not ready.
+ */
+bool ts_nbus_is_ready(void)
+{
+ bool nbus_state;
+
+ mutex_lock(&ts_nbus_lock);
+ nbus_state = ts_nbus_ready;
+ mutex_unlock(&ts_nbus_lock);
+
+ return nbus_state;
+}
+EXPORT_SYMBOL_GPL(ts_nbus_is_ready);
+
+static int ts_nbus_probe(struct platform_device *pdev)
+{
+ struct pwm_device *pwm;
+ struct pwm_args pargs;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ int ret;
+
+ ts_nbus = devm_kzalloc(dev, sizeof(*ts_nbus), GFP_KERNEL);
+ if (!ts_nbus)
+ return -ENOMEM;
+
+ ret = ts_nbus_get_of_pdata(dev, np);
+ if (ret)
+ return ret;
+ ret = ts_nbus_init(pdev);
+ if (ret < 0)
+ return ret;
+
+ pwm = devm_pwm_get(dev, NULL);
+ if (IS_ERR(pwm)) {
+ ret = PTR_ERR(pwm);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "unable to request PWM\n");
+ return ret;
+ }
+
+ pwm_get_args(pwm, &pargs);
+ if (!pargs.period) {
+ dev_err(&pdev->dev, "invalid PWM period\n");
+ return -EINVAL;
+ }
+
+ /*
+ * FIXME: pwm_apply_args() should be removed when switching to
+ * the atomic PWM API.
+ */
+ pwm_apply_args(pwm);
+ ret = pwm_config(pwm, pargs.period, pargs.period);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * we can now start the FPGA and let the peripherals knows the bus is
+ * ready.
+ */
+ pwm_enable(pwm);
+ ts_nbus->pwm = pwm;
+
+ mutex_lock(&ts_nbus_lock);
+ ts_nbus_ready = true;
+ mutex_unlock(&ts_nbus_lock);
+
+ dev_info(dev, "initialized\n");
+
+ return 0;
+}
+
+static int ts_nbus_remove(struct platform_device *pdev)
+{
+ /* disable bus access */
+ mutex_lock(&ts_nbus_lock);
+ ts_nbus_ready = false;
+ mutex_unlock(&ts_nbus_lock);
+
+ /* shutdown the FPGA */
+ pwm_disable(ts_nbus->pwm);
+
+ return 0;
+}
+
+static const struct of_device_id ts_nbus_of_match[] = {
+ { .compatible = "technologic,ts-nbus", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, ts_nbus_of_match);
+
+static struct platform_driver ts_nbus_driver = {
+ .probe = ts_nbus_probe,
+ .remove = ts_nbus_remove,
+ .driver = {
+ .name = "ts_nbus",
+ .of_match_table = ts_nbus_of_match,
+ },
+};
+
+module_platform_driver(ts_nbus_driver);
+
+MODULE_ALIAS("platform:ts_nbus");
+MODULE_AUTHOR("Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>");
+MODULE_DESCRIPTION("Technologic Systems NBUS");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/ts-nbus.h b/include/linux/ts-nbus.h
new file mode 100644
index 0000000..5fcdb96
--- /dev/null
+++ b/include/linux/ts-nbus.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (c) 2016 - Savoir-faire Linux
+ * Author: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _TS_NBUS_H
+#define _TS_NBUS_H
+
+extern u16 ts_nbus_read(u8 adr);
+extern int ts_nbus_write(u8 adr, u16 value);
+extern bool ts_nbus_is_ready(void);
+
+#endif /* _TS_NBUS_H */
--
2.10.2
^ permalink raw reply related
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