Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH 2/3] Bluetooth: btusb: Add out-of-band wakeup support
From: Brian Norris @ 2016-12-15  3:21 UTC (permalink / raw)
  To: Rajat Jain
  Cc: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
	Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
	netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
	rajatxjain-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1481742779-15105-2-git-send-email-rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>

Hi,

On Wed, Dec 14, 2016 at 11:12:58AM -0800, Rajat Jain wrote:
> 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.

Might it be worthwhile to define an 'interrupt-names' property (e.g., =
"wakeup") to help future-proof this?

> +
> +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);

Better to use of_irq_get{,_byname}(), no?

> +	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);

You're assuming this is level-triggered, and active-low? Can't this just
be specified in the device tree and just pass 0 here?

Also, it seems like it would be a lot more convenient if we could treat
this as edge-triggered, so we don't have to do the set/clear flags,
disable IRQ, etc., dance. You'd just have to change the device tree
definition. Is there any downside to doing that?

It would also then be a better candidate for using something like
dev_pm_set_dedicated_wake_irq() (although last time I tried using that,
it didn't do so great if you don't have autosuspend enabled -- but I
think there are patches outstanding for that; so maybe not yet).

> +	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);

oob and bt are typically capitalized in strings. And maybe irq too.
Also, you declared irq as 'int', so %d instead of %u.

Brian

> +	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
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399
From: Brian Norris @ 2016-12-15  3:20 UTC (permalink / raw)
  To: Xing Zheng
  Cc: Doug Anderson, frank.wang-TNX95d0MmH7DzftRWevZcw,
	open list:ARM/Rockchip SoC..., Heiko Stübner, William wu,
	Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon,
	Caesar Wang, Shawn Lin, Jianqun Xu, Elaine Zhang, David Wu,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <5ce521da-119a-2de8-026c-5992fedfef43-TNX95d0MmH7DzftRWevZcw@public.gmane.org>

On Thu, Dec 15, 2016 at 10:41:04AM +0800, Xing Zheng wrote:
> // Frank
> 
> Hi Doug,  Brain,
>     Thanks for the reply.
>     Sorry I forgot these patches have been sent earlier, and Frank
> have some explained and discussed with Heiko.
> Please see https://patchwork.kernel.org/patch/9255245/
>     Perhaps we can move to that patch tree to continue the discussion.
> 
>     I think Frank and William will help us to continue checking these.

I only briefly read that discussion, but AFAICT it doesn't actually
address all the comments/quetions we had here. For instance, the
power_off() vs. delayed-work race in your USB2 PHY driver (is that
intentional?). Also, the question of why PHY (auto?)suspend is relevant.

I'll check again tomorrow.

Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399
From: Xing Zheng @ 2016-12-15  2:41 UTC (permalink / raw)
  To: Doug Anderson, Brian Norris, frank.wang-TNX95d0MmH7DzftRWevZcw
  Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Dmitry Torokhov, Heiko Stübner, Catalin Marinas, Shawn Lin,
	Elaine Zhang, Will Deacon,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	open list:ARM/Rockchip SoC..., Rob Herring, David Wu, William wu,
	Jianqun Xu,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Caesar Wang
In-Reply-To: <CAD=FV=UU4JdRjRgEvc_wxprvi6bo46+jd=x2m2QzOe4uJmuRPA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

// Frank

Hi Doug,  Brain,
     Thanks for the reply.
     Sorry I forgot these patches have been sent earlier, and Frank have 
some explained and discussed with Heiko.
Please see https://patchwork.kernel.org/patch/9255245/
     Perhaps we can move to that patch tree to continue the discussion.

     I think Frank and William will help us to continue checking these.

Thanks

在 2016年12月15日 08:10, Doug Anderson 写道:
> Hi,
>
> On Wed, Dec 14, 2016 at 2:11 AM, Xing Zheng <zhengxing@rock-chips.com> wrote:
>> From: William wu <wulf@rock-chips.com>
>>
>> We found that the suspend process was blocked when it run into
>> ehci/ohci module due to clk-480m of usb2-phy was disabled.
>>
>> The root cause is that usb2-phy suspended earlier than ehci/ohci
>> (usb2-phy will be auto suspended if no devices plug-in).
> This is really weird, but I can confirm it is true on my system too
> (kernel-4.4 based).  At least I see:
>
> [  208.012065] calling  usb1+ @ 4984, parent: fe380000.usb, cb: usb_dev_suspend
> [  208.569112] calling  ff770000.syscon:usb2-phy@e450+ @ 4983, parent:
> ff770000.syscon, cb: platform_pm_suspend
> [  208.569113] call ff770000.syscon:usb2-phy@e450+ returned 0 after 0 usecs
> [  208.569439] calling  fe380000.usb+ @ 4983, parent: platform, cb:
> platform_pm_suspend
> [  208.569444] call fe380000.usb+ returned 0 after 4 usecs
>
>
> In general I thought that suspend order was supposed to be related to
> probe order.  So if your probe order is A, B, C then your suspend
> order would be C, B, A.  ...and we know for sure that the USB PHY
> needs to probe _before_ the main USB controller.  If it didn't then
> you'd get an EPROBE_DEFER in the USB controller, right?  So that means
> that the USB controller should be suspending before its PHY.
>
> Any chance this is somehow related to async probe?  I'm not a huge
> expert on async probe but I guess I could imagine things getting
> confused if you had a sequence like this:
>
> 1. Start USB probe (async)
> 2. Start PHY probe
> 3. Finish PHY probe
> 4. In USB probe, ask for PHY--no problems since PHY probe finished
> 5. Finish USB probe
>
> The probe order would be USB before PHY even though the USB probe
> _depended_ on the PHY probe being finished...  :-/  Anyway, probably
> I'm just misunderstanding something and someone can tell me how dumb I
> am...
>
> I also notice that the ehci_platform_power_off() function we're
> actually making PHY commands right before the same commands that turn
> off our clocks.  Presumably those commands aren't really so good to do
> if the PHY has already been suspended?
>
> Actually, does the PHY suspend from platform_pm_suspend() actually
> even do anything?  It doesn't look like it.  It looks as if all the
> PHY cares about is init/exit and on/off...  ...and it looks as if the
> PHY should be turned off by the EHCI controller at about the same time
> it turns off its clocks...
>
> I haven't fully dug, but is there any chance that things are getting
> confused between the OTG PHY and the Host PHY?  Maybe when we turn off
> the OTG PHY it turns off something that the host PHY needs?
>
>
>> and the
>> clk-480m provided by it was disabled if no module used. However,
>> some suspend process related ehci/ohci are base on this clock,
>> so we should refer it into ehci/ohci driver to prevent this case.
> Though I don't actually have details about the internals of the chip,
> it does seem highly likely that the USB block actually uses this clock
> for some things, so it doesn't seem insane (to me) to have the USB
> controller request that the clock be on.  So, in general, I don't have
> lots of objections to including the USB PHY Clock here.
>
> ...but I think you have the wrong clock (please correct me if I'm
> wrong).  I think you really wanted your input clock to be
> "clk_usbphy0_480m", not "clk_usbphy0_480m_src".  Specifically I
> believe there is a gate between the clock outputted by the PHY and the
> USB Controller itself.  I'm guessing that the gate is only there
> between the PHY and the "clk_usbphy_480m" MUX.
>
> As evidence, I have a totally functioning system right now where
> "clk_usbphy0_480m_src" is currently gated.
>
> That means really you should be changing your clocks to this (untested):
>
>                 clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
>                          <&u2phy0>;
>
> ...and then you could drop the other two patches in this series.
>
> ===
>
> OK, I actually briefly tested my proposed change and it at least seems
> to build and boot OK.  You'd have to test it to make sure it makes
> your tests pass...
>
> ===
>
> So I guess to summarize all the above:
>
> * It seems to me like there's some deeper root cause and your patch
> will at most put a band-aid on it.  Seems like digging out the root
> cause is a good idea.
>
> * Though I don't believe it solves the root problem, the idea of the
> USB Controller holding onto the PHY clock doesn't seem wrong.
>
> * You're holding onto the wrong clock in your patch--you want the one
> before the gate (I think).
>
>
> -Doug
>
>
>


-- 
- Xing Zheng



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

^ permalink raw reply

* Re: [PATCH 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
From: hoegeun kwon @ 2016-12-15  1:53 UTC (permalink / raw)
  To: Andrzej Hajda, thierry.reding, kgene, krzk
  Cc: devicetree, linux-samsung-soc, Donghwa Lee, linux-kernel,
	dri-devel, 최찬우, Hyungwon Hwang, Hoegeun Kwon
In-Reply-To: <583d4da7-a3c5-f84f-ba11-1bb1e6890e9b@samsung.com>



On 12/14/2016 11:14 PM, Andrzej Hajda wrote:
> On 14.12.2016 07:04, Hoegeun Kwon wrote:
>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>> panel in the TM2 device.
>>
>> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
>> Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
>> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
> Hi Hoegeun Kwon,
>
> Is there a reason to upstream obsolete driver? Current version of the
> driver is available at [1]. It differs significantly and contains
> multiple fixes and improvements. I guess it still requires some
> polishing but it is better base for start.
>
> [1]:
> https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=blob;f=drivers/gpu/drm/panel/panel-s6e3ha2.c;hb=refs/heads/tizen
>
> Regards
> Andrzej

Hi Andrzej Hajda,

The current driver focus on basic functionality. Therefore, VR and HMT
modes in [1] have been removed from the patch. VR and HMT modes
are added after the basic functions are reflected.

Best Regards,
Hoegeun Kwon

> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [PATCH 4/4] mmc: pwrseq-simple: add disable-post-power-on option
From: Matt Ranostay @ 2016-12-15  1:46 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Rob Herring, devicetree@vger.kernel.org,
	linux-mmc@vger.kernel.org, Tony Lindgren, Liam Breck
In-Reply-To: <CAPDyKFp2L7x=dV6O5XrA53-OOXE0sf+P3tNH93XGyzNheX9vjQ@mail.gmail.com>

On Tue, Dec 13, 2016 at 12:01 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 9 December 2016 at 19:09, Rob Herring <robh@kernel.org> wrote:
>> On Fri, Dec 02, 2016 at 01:06:47AM -0800, Matt Ranostay wrote:
>>> On Fri, Dec 2, 2016 at 12:28 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>> > On 2 December 2016 at 08:22, Matt Ranostay <matt@ranostay.consulting> wrote:
>>> >>
>>> >>
>>> >>> On Dec 1, 2016, at 23:13, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>> >>>
>>> >>>> On 2 December 2016 at 07:17, Matt Ranostay <matt@ranostay.consulting> wrote:
>>> >>>> Add optional device-post-power-on parameters to disable post_power_on
>>> >>>> function from being called since this breaks some device.
>>> >>>>
>>> >>>> Cc: Tony Lindgren <tony@atomide.com>
>>> >>>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>>> >>>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
>>> >>>> ---
>>> >>>> Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 2 ++
>>> >>>> drivers/mmc/core/pwrseq_simple.c                            | 7 +++++++
>>> >>>> 2 files changed, 9 insertions(+)
>>> >>>>
>>> >>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>>> >>>> index bea306d772d1..09fa153f743e 100644
>>> >>>> --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>>> >>>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
>>> >>>> @@ -24,6 +24,8 @@ Optional properties:
>>> >>>>        de-asserting the reset-gpios (if any)
>>> >>>> - invert-off-state: Invert the power down state for the reset-gpios (if any)
>>> >>>>        and pwrdn-gpios (if any)
>>> >>>> +- disable-post-power-on : Avoid post_power_on function from being called since
>>> >>>> +       this breaks some devices
>>> >>>
>>> >>> This is a bit weird. I would like to avoid this, if possible.
>>> >>>
>>> >>> Perhaps if you simply describe the sequence in detail for your device
>>> >>> we can figure out the best option together.
>>> >>
>>> >> Yeah I know it is a bit weird but we need to keep that reset pin high for at least some time after pre power on.   So any case it would be another property
>>> >
>>> > This went offlist, please resend.
>>> >
>>> > Moreover, please try to describe the sequence you need in detail
>>> > according to your HW spec.
>>> >
>>>
>>> Yeah oops....
>>>
>>> So basically we need to drive the reset and powerdown lines high with
>>> a 300 milliseconds delay between both...
>>> can't have the reset line low with post power on (pretty sure but
>>> would need a delay anyway), and we need both reset + powerdown line
>>> set low on powerdown.
>>>
>>> So the power down sequence would need to be reversed for this
>>> application in pwrseq-simple.
>>
>> This sounds like you need a device specific sequence to me. Otherwise,
>> write a language to describe any power control waveforms rather than
>> trying to bolt on more and more properties. (Don't really go write a
>> language.)
>
> Actually this isn't so device specific. The cw1200 wifi chip which is
> being used with ux500 SoCs has a very similar sequence. Allow me to
> check the details and get back.

Ok. It would be good to have something common than a bunch of one-off
solutions for sure.

>
> Anyway, my point is that I think we can figure out a common sequence
> to support these kind required sequences. That is to me preferred over
> adding a new (two to support cw1200) device specific pwrseq driver.
>
> Kind regards
> Uffe

^ permalink raw reply

* Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399
From: Brian Norris @ 2016-12-15  1:18 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Elaine Zhang, Heiko Stübner, Xing Zheng, Catalin Marinas,
	Shawn Lin, Dmitry Torokhov, Will Deacon,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	open list:ARM/Rockchip SoC..., Rob Herring, David Wu, William wu,
	Jianqun Xu,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Caesar Wang
In-Reply-To: <20161215004737.GA32652-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>

On Wed, Dec 14, 2016 at 04:47:38PM -0800, Brian Norris wrote:
> On Wed, Dec 14, 2016 at 04:10:38PM -0800, Doug Anderson wrote:
> > On Wed, Dec 14, 2016 at 2:11 AM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> > > From: William wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> > >
> > > We found that the suspend process was blocked when it run into
> > > ehci/ohci module due to clk-480m of usb2-phy was disabled.

One more thing: why is the USB2 PHY relevant to the OHCI controller? And
if it is relevant, why isn't there a PHY phandle for it in
usb_host0_ohci and usb_host1_ohci in rk3399.dtsi? As it stands, your
patch is hacking in USB2 clock references for OHCI, but you're not
actually managing the PHY there at all. Seems like you'd want to do
all-or-nothing if there's a functional dependency between the OHCI
controllers and the USB2 PHYs.

Brian

^ permalink raw reply

* Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399
From: Brian Norris @ 2016-12-15  0:47 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Xing Zheng, open list:ARM/Rockchip SoC..., Heiko Stübner,
	William wu, Rob Herring, Mark Rutland, Catalin Marinas,
	Will Deacon, Caesar Wang, Shawn Lin, Jianqun Xu, Elaine Zhang,
	David Wu, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAD=FV=UU4JdRjRgEvc_wxprvi6bo46+jd=x2m2QzOe4uJmuRPA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi,

I think Doug is probably right on most accounts, and I haven't
thoroughly investigated all the claims. But a few thoughts:

On Wed, Dec 14, 2016 at 04:10:38PM -0800, Doug Anderson wrote:
> On Wed, Dec 14, 2016 at 2:11 AM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> > From: William wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >
> > We found that the suspend process was blocked when it run into
> > ehci/ohci module due to clk-480m of usb2-phy was disabled.
> >
> > The root cause is that usb2-phy suspended earlier than ehci/ohci
> > (usb2-phy will be auto suspended if no devices plug-in).

When you say "suspend" do you mean USB runtime suspend (i.e., auto
suspend) or do you mean system suspend (i.e., driver .suspend()
callbacks)? The latter are empty intentionally for PHY drivers, since
PHY state is managed by the consumer driver (i.e., the controller
driver). And the former doesn't actually disable any clocks AFAIK, so
that's a red herring IIUC.

> This is really weird, but I can confirm it is true on my system too
> (kernel-4.4 based).  At least I see:
> 
> [  208.012065] calling  usb1+ @ 4984, parent: fe380000.usb, cb: usb_dev_suspend
> [  208.569112] calling  ff770000.syscon:usb2-phy@e450+ @ 4983, parent:
> ff770000.syscon, cb: platform_pm_suspend
> [  208.569113] call ff770000.syscon:usb2-phy@e450+ returned 0 after 0 usecs
> [  208.569439] calling  fe380000.usb+ @ 4983, parent: platform, cb:
> platform_pm_suspend
> [  208.569444] call fe380000.usb+ returned 0 after 4 usecs
> 
> 
> In general I thought that suspend order was supposed to be related to
> probe order.  So if your probe order is A, B, C then your suspend
> order would be C, B, A.  ...and we know for sure that the USB PHY
> needs to probe _before_ the main USB controller.  If it didn't then
> you'd get an EPROBE_DEFER in the USB controller, right?  So that means
> that the USB controller should be suspending before its PHY.
> 
> Any chance this is somehow related to async probe?  I'm not a huge
> expert on async probe but I guess I could imagine things getting
> confused if you had a sequence like this:
> 
> 1. Start USB probe (async)
> 2. Start PHY probe
> 3. Finish PHY probe
> 4. In USB probe, ask for PHY--no problems since PHY probe finished
> 5. Finish USB probe
> 
> The probe order would be USB before PHY even though the USB probe
> _depended_ on the PHY probe being finished...  :-/  Anyway, probably
> I'm just misunderstanding something and someone can tell me how dumb I
> am...

That may well be true. There isn't a single defined probe order as soon
as you involve async probe, right? So things get a little fuzzier. Also,
I know if you're talking about async suspend/resume, the driver core
only (until quite recently? [1]) respects parent/child relationships.
But I'm not sure of all the async details right now, and async suspend
isn't typically used for the controllers AFAIK -- just for the
hubs/devices.

Anyway, I don't think that's relevant at all because:

> I also notice that the ehci_platform_power_off() function we're
> actually making PHY commands right before the same commands that turn
> off our clocks.  Presumably those commands aren't really so good to do
> if the PHY has already been suspended?
> 
> Actually, does the PHY suspend from platform_pm_suspend() actually
> even do anything?  It doesn't look like it.  It looks as if all the
> PHY cares about is init/exit and on/off...  ...and it looks as if the
> PHY should be turned off by the EHCI controller at about the same time
> it turns off its clocks...

Right, PHY drivers don't do anything at suspend/resume, since I guess
they presume the consuming driver (the controller) will handle state
transitions (power off, exit).

> I haven't fully dug, but is there any chance that things are getting
> confused between the OTG PHY and the Host PHY?  Maybe when we turn off
> the OTG PHY it turns off something that the host PHY needs?

Random thing I noticed: there seems to be a race in
phy-rockchip-inno-usb2.c, if we're worried about the 480M clock getting
disabled too early. See:

static int rockchip_usb2phy_power_off(struct phy *phy)
{
...
        clk_disable_unprepare(rphy->clk480m);
...
}

static int rockchip_usb2phy_exit(struct phy *phy)
{
        struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy);

        if (rport->port_id == USB2PHY_PORT_OTG &&
            rport->mode != USB_DR_MODE_HOST) {
                cancel_delayed_work_sync(&rport->otg_sm_work);
                cancel_delayed_work_sync(&rport->chg_work);
        } else if (rport->port_id == USB2PHY_PORT_HOST)
                cancel_delayed_work_sync(&rport->sm_work);

        return 0;
}

I believe that means any of those work handlers can still be running while
after power_off() -- and therefore can be running after we've disabled the
clock. Might this be your problem?

If so, you're papering that bug by keeping a clock reference in the
controller, which implicitly defers the *actual*
clock_disable_unprepare() until much later.

Brian

[1] commit 9ed9895370ae ("driver core: Functional dependencies tracking
support")
--
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/3] clk: rockchip: rk3399: add USBPHYx_480M_SRC clock IDs
From: Doug Anderson @ 2016-12-15  0:27 UTC (permalink / raw)
  To: Xing Zheng
  Cc: open list:ARM/Rockchip SoC..., Heiko Stübner, Rob Herring,
	Mark Rutland, Lin Huang, Chris Zhong, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <1481710301-1454-2-git-send-email-zhengxing@rock-chips.com>

Hi,

On Wed, Dec 14, 2016 at 2:11 AM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> This patch add two clock IDs for the usb phy 480m source clocks.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
>  include/dt-bindings/clock/rk3399-cru.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h
> index 220a60f..224daf7 100644
> --- a/include/dt-bindings/clock/rk3399-cru.h
> +++ b/include/dt-bindings/clock/rk3399-cru.h
> @@ -132,6 +132,8 @@
>  #define SCLK_RMII_SRC                  166
>  #define SCLK_PCIEPHY_REF100M           167
>  #define SCLK_DDRC                      168
> +#define SCLK_USBPHY0_480M_SRC          169
> +#define SCLK_USBPHY1_480M_SRC          170

As mentioned in the dts patch, I don't think you need these since I'm
under the impression that nobody gets this clock.  I think the USB
Controller get the ungated version of this clock.

-Doug

^ permalink raw reply

* Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399
From: Doug Anderson @ 2016-12-15  0:10 UTC (permalink / raw)
  To: Xing Zheng
  Cc: open list:ARM/Rockchip SoC..., Heiko Stübner, William wu,
	Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon,
	Caesar Wang, Brian Norris, Shawn Lin, Jianqun Xu, Elaine Zhang,
	David Wu, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1481710301-1454-4-git-send-email-zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>

Hi,

On Wed, Dec 14, 2016 at 2:11 AM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> From: William wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> We found that the suspend process was blocked when it run into
> ehci/ohci module due to clk-480m of usb2-phy was disabled.
>
> The root cause is that usb2-phy suspended earlier than ehci/ohci
> (usb2-phy will be auto suspended if no devices plug-in).

This is really weird, but I can confirm it is true on my system too
(kernel-4.4 based).  At least I see:

[  208.012065] calling  usb1+ @ 4984, parent: fe380000.usb, cb: usb_dev_suspend
[  208.569112] calling  ff770000.syscon:usb2-phy@e450+ @ 4983, parent:
ff770000.syscon, cb: platform_pm_suspend
[  208.569113] call ff770000.syscon:usb2-phy@e450+ returned 0 after 0 usecs
[  208.569439] calling  fe380000.usb+ @ 4983, parent: platform, cb:
platform_pm_suspend
[  208.569444] call fe380000.usb+ returned 0 after 4 usecs


In general I thought that suspend order was supposed to be related to
probe order.  So if your probe order is A, B, C then your suspend
order would be C, B, A.  ...and we know for sure that the USB PHY
needs to probe _before_ the main USB controller.  If it didn't then
you'd get an EPROBE_DEFER in the USB controller, right?  So that means
that the USB controller should be suspending before its PHY.

Any chance this is somehow related to async probe?  I'm not a huge
expert on async probe but I guess I could imagine things getting
confused if you had a sequence like this:

1. Start USB probe (async)
2. Start PHY probe
3. Finish PHY probe
4. In USB probe, ask for PHY--no problems since PHY probe finished
5. Finish USB probe

The probe order would be USB before PHY even though the USB probe
_depended_ on the PHY probe being finished...  :-/  Anyway, probably
I'm just misunderstanding something and someone can tell me how dumb I
am...

I also notice that the ehci_platform_power_off() function we're
actually making PHY commands right before the same commands that turn
off our clocks.  Presumably those commands aren't really so good to do
if the PHY has already been suspended?

Actually, does the PHY suspend from platform_pm_suspend() actually
even do anything?  It doesn't look like it.  It looks as if all the
PHY cares about is init/exit and on/off...  ...and it looks as if the
PHY should be turned off by the EHCI controller at about the same time
it turns off its clocks...

I haven't fully dug, but is there any chance that things are getting
confused between the OTG PHY and the Host PHY?  Maybe when we turn off
the OTG PHY it turns off something that the host PHY needs?


> and the
> clk-480m provided by it was disabled if no module used. However,
> some suspend process related ehci/ohci are base on this clock,
> so we should refer it into ehci/ohci driver to prevent this case.

Though I don't actually have details about the internals of the chip,
it does seem highly likely that the USB block actually uses this clock
for some things, so it doesn't seem insane (to me) to have the USB
controller request that the clock be on.  So, in general, I don't have
lots of objections to including the USB PHY Clock here.

...but I think you have the wrong clock (please correct me if I'm
wrong).  I think you really wanted your input clock to be
"clk_usbphy0_480m", not "clk_usbphy0_480m_src".  Specifically I
believe there is a gate between the clock outputted by the PHY and the
USB Controller itself.  I'm guessing that the gate is only there
between the PHY and the "clk_usbphy_480m" MUX.

As evidence, I have a totally functioning system right now where
"clk_usbphy0_480m_src" is currently gated.

That means really you should be changing your clocks to this (untested):

               clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
                        <&u2phy0>;

...and then you could drop the other two patches in this series.

===

OK, I actually briefly tested my proposed change and it at least seems
to build and boot OK.  You'd have to test it to make sure it makes
your tests pass...

===

So I guess to summarize all the above:

* It seems to me like there's some deeper root cause and your patch
will at most put a band-aid on it.  Seems like digging out the root
cause is a good idea.

* Though I don't believe it solves the root problem, the idea of the
USB Controller holding onto the PHY clock doesn't seem wrong.

* You're holding onto the wrong clock in your patch--you want the one
before the gate (I think).


-Doug
--
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 1/4] pinctrl: aspeed: Read and write bits in LPC and GFX controllers
From: Andrew Jeffery @ 2016-12-15  0:00 UTC (permalink / raw)
  To: Rob Herring
  Cc: Linus Walleij, Mark Rutland, Joel Stanley,
	linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqJvhxDSVqpAFCberferxCjvLPRTFXcgTafaPf1DwOa2Xw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]

On Wed, 2016-12-14 at 10:46 -0600, Rob Herring wrote:
> >> > +                   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? 

Yes.

> If it is sparse like that,
> then yes you probably just want to have reg in the parent for the
> whole block.

Alright, we will leave it as-is.

> 
> > 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.

Thanks.

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply

* [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, 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>

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@savoirfairelinux.com>
---
 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@savoirfairelinux.com>
+ *
+ * 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 = <&reg_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@savoirfairelinux.com>
+ *
+ * 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@savoirfairelinux.com>
+ *
+ * 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

^ permalink raw reply related

* [PATCH 6/6] watchdog: ts4600: add driver for TS-4600 watchdog
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>

This watchdog is instantiated in a FPGA and can only be access using a
GPIOs bit-banged bus, called the NBUS by Technologic Systems.
The watchdog is made of only one register, called the feed register.
Writing to this register will re-arm the watchdog for a given time (and
enable it if it was disable). It can be disabled by writing a special
value into it.

Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
---
 .../devicetree/bindings/watchdog/ts4600-wdt.txt    |  16 ++
 arch/arm/boot/dts/imx28-ts4600-common.dtsi         |   5 +
 drivers/watchdog/Kconfig                           |  10 +
 drivers/watchdog/Makefile                          |   1 +
 drivers/watchdog/ts4600_wdt.c                      | 213 +++++++++++++++++++++
 5 files changed, 245 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
 create mode 100644 drivers/watchdog/ts4600_wdt.c

diff --git a/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt b/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
new file mode 100644
index 0000000..61d620e
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
@@ -0,0 +1,16 @@
+TS-4600 Technologic Systems Watchdog
+
+Required properties:
+- compatible: must be "technologic,ts4600-wdt"
+- reg: offset to the FPGA's watchdog register
+
+Optional property:
+- timeout-sec: contains the watchdog timeout in seconds.
+
+Example:
+
+wdt {
+	compatible = "technologic,ts4600-wdt";
+	reg = <0x2a>;
+	timeout-sec = <10>;
+};
diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
index b668933..dd7318c 100644
--- a/arch/arm/boot/dts/imx28-ts4600-common.dtsi
+++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
@@ -116,6 +116,11 @@
 		strobe-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
 		ale-gpios    = <&gpio0 26 GPIO_ACTIVE_HIGH>;
 		rdy-gpios    = <&gpio0 21 GPIO_ACTIVE_HIGH>;
+
+		wdt@2a {
+			compatible = "technologic,ts4600-wdt";
+			reg = <0x2a>;
+		};
 	};
 
 };
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 3eb58cb..7a8e176 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -500,6 +500,16 @@ config NUC900_WATCHDOG
 	  To compile this driver as a module, choose M here: the
 	  module will be called nuc900_wdt.
 
+config TS4600_WATCHDOG
+	tristate "TS-4600 Watchdog"
+	depends on HAS_IOMEM && OF
+	depends on SOC_IMX28 || COMPILE_TEST
+	select WATCHDOG_CORE
+	help
+	  Technologic Systems TS-4600 has watchdog timer implemented in
+	  an external FPGA. Say Y here if you want to support for the
+	  watchdog timer on TS-4600 board.
+
 config TS4800_WATCHDOG
 	tristate "TS-4800 Watchdog"
 	depends on HAS_IOMEM && OF
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index caa9f4a..d4b4bd2 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_RN5T618_WATCHDOG) += rn5t618_wdt.o
 obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
 obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
 obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
+obj-$(CONFIG_TS4600_WATCHDOG) += ts4600_wdt.o
 obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
 obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
 obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
diff --git a/drivers/watchdog/ts4600_wdt.c b/drivers/watchdog/ts4600_wdt.c
new file mode 100644
index 0000000..db91b40
--- /dev/null
+++ b/drivers/watchdog/ts4600_wdt.c
@@ -0,0 +1,213 @@
+/*
+ * Watchdog driver for TS-4600 based boards
+ *
+ * Copyright (c) 2016 - Savoir-faire Linux
+ * Author: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
+ *
+ * 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.
+ *
+ * The watchdog on the TS-4600 based boards is in an FPGA and can only be
+ * accessed using a GPIO bit-banged bus called the NBUS by Technologic Systems.
+ * The logic for the watchdog is the same then for the TS-4800 SoM, only the way
+ * to access it change, therefore this driver is heavely based on the ts4800_wdt
+ * driver from Damien Riegel <damien.riegel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/ts-nbus.h>
+#include <linux/watchdog.h>
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout,
+	"Watchdog cannot be stopped once started (default="
+	__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+/* possible feed values */
+#define TS4600_WDT_FEED_2S       0x1
+#define TS4600_WDT_FEED_10S      0x2
+#define TS4600_WDT_DISABLE       0x3
+
+struct ts4600_wdt {
+	struct watchdog_device  wdd;
+	u32                     feed_offset;
+	u32                     feed_val;
+};
+
+/*
+ * TS-4600 supports the following timeout values:
+ *
+ *   value desc
+ *   ---------------------
+ *     0    feed for 338ms
+ *     1    feed for 2.706s
+ *     2    feed for 10.824s
+ *     3    disable watchdog
+ *
+ * Keep the regmap/timeout map ordered by timeout
+ */
+static const struct {
+	const int timeout;
+	const int regval;
+} ts4600_wdt_map[] = {
+	{ 2,  TS4600_WDT_FEED_2S },
+	{ 10, TS4600_WDT_FEED_10S },
+};
+
+#define MAX_TIMEOUT_INDEX       (ARRAY_SIZE(ts4600_wdt_map) - 1)
+
+static void ts4600_write_feed(struct ts4600_wdt *wdt, u32 val)
+{
+	ts_nbus_write(wdt->feed_offset, val);
+}
+
+static int ts4600_wdt_start(struct watchdog_device *wdd)
+{
+	struct ts4600_wdt *wdt = watchdog_get_drvdata(wdd);
+
+	ts4600_write_feed(wdt, wdt->feed_val);
+
+	return 0;
+}
+
+static int ts4600_wdt_stop(struct watchdog_device *wdd)
+{
+	struct ts4600_wdt *wdt = watchdog_get_drvdata(wdd);
+
+	ts4600_write_feed(wdt, TS4600_WDT_DISABLE);
+	return 0;
+}
+
+static int ts4600_wdt_set_timeout(struct watchdog_device *wdd,
+				  unsigned int timeout)
+{
+	struct ts4600_wdt *wdt = watchdog_get_drvdata(wdd);
+	int i;
+
+	for (i = 0; i < MAX_TIMEOUT_INDEX; i++) {
+		if (ts4600_wdt_map[i].timeout >= timeout)
+			break;
+	}
+
+	wdd->timeout = ts4600_wdt_map[i].timeout;
+	wdt->feed_val = ts4600_wdt_map[i].regval;
+
+	return 0;
+}
+
+static const struct watchdog_ops ts4600_wdt_ops = {
+	.owner = THIS_MODULE,
+	.start = ts4600_wdt_start,
+	.stop = ts4600_wdt_stop,
+	.set_timeout = ts4600_wdt_set_timeout,
+};
+
+static const struct watchdog_info ts4600_wdt_info = {
+	.options = WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING,
+	.identity = "TS-4600 Watchdog",
+};
+
+static int ts4600_wdt_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct watchdog_device *wdd;
+	struct ts4600_wdt *wdt;
+	u32 reg;
+	int ret;
+
+	ret = of_property_read_u32(np, "reg", &reg);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "missing reg property\n");
+		return ret;
+	}
+
+	/* check for the NBUS state and defer the probing if it is not ready */
+	if (!ts_nbus_is_ready())
+		return -EPROBE_DEFER;
+
+	/* allocate memory for watchdog struct */
+	wdt = devm_kzalloc(&pdev->dev, sizeof(*wdt), GFP_KERNEL);
+	if (!wdt)
+		return -ENOMEM;
+
+	/* set offset to know where to write */
+	wdt->feed_offset = reg;
+
+	/* Initialize struct watchdog_device */
+	wdd = &wdt->wdd;
+	wdd->parent = &pdev->dev;
+	wdd->info = &ts4600_wdt_info;
+	wdd->ops = &ts4600_wdt_ops;
+	wdd->min_timeout = ts4600_wdt_map[0].timeout;
+	wdd->max_timeout = ts4600_wdt_map[MAX_TIMEOUT_INDEX].timeout;
+
+	watchdog_set_drvdata(wdd, wdt);
+	watchdog_set_nowayout(wdd, nowayout);
+	watchdog_init_timeout(wdd, 0, &pdev->dev);
+
+	/*
+	 * As this watchdog supports only a few values, ts4600_wdt_set_timeout
+	 * must be called to initialize timeout and feed_val with valid values.
+	 * Default to maximum timeout if none, or an invalid one, is provided in
+	 * device tree.
+	 */
+	if (!wdd->timeout)
+		wdd->timeout = wdd->max_timeout;
+	ts4600_wdt_set_timeout(wdd, wdd->timeout);
+
+	/*
+	 * The feed register is write-only, so it is not possible to determine
+	 * watchdog's state. Disable it to be in a known state.
+	 */
+	ts4600_wdt_stop(wdd);
+
+	ret = watchdog_register_device(wdd);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"failed to register watchdog device\n");
+		return ret;
+	}
+
+	platform_set_drvdata(pdev, wdt);
+
+	dev_info(&pdev->dev,
+		 "initialized (timeout = %d sec, nowayout = %d)\n",
+		 wdd->timeout, nowayout);
+
+	return 0;
+}
+
+static int ts4600_wdt_remove(struct platform_device *pdev)
+{
+	struct ts4600_wdt *wdt = platform_get_drvdata(pdev);
+
+	watchdog_unregister_device(&wdt->wdd);
+
+	return 0;
+}
+
+static const struct of_device_id ts4600_wdt_of_match[] = {
+	{ .compatible = "technologic,ts4600-wdt", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, ts4600_wdt_of_match);
+
+static struct platform_driver ts4600_wdt_driver = {
+	.probe		= ts4600_wdt_probe,
+	.remove		= ts4600_wdt_remove,
+	.driver		= {
+		.name	= "ts4600_wdt",
+		.of_match_table = ts4600_wdt_of_match,
+	},
+};
+
+module_platform_driver(ts4600_wdt_driver);
+
+MODULE_AUTHOR("Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:ts4600_wdt");
-- 
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 5/6] ARM: dts: TS-4600: add NBUS support
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 commit enables the NBUS on the TS-4600, using the ts-nbus driver.

Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
---
 arch/arm/boot/dts/imx28-ts4600-common.dtsi | 43 ++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
index 04bd5a5..b668933 100644
--- a/arch/arm/boot/dts/imx28-ts4600-common.dtsi
+++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
@@ -44,6 +44,28 @@
 					fsl,pull-up = <MXS_PULL_DISABLE>;
 				};
 
+				nbus_pins: nbus_pins {
+					fsl,pinmux-ids = <
+						MX28_PAD_GPMI_D00__GPIO_0_0
+						MX28_PAD_GPMI_D01__GPIO_0_1
+						MX28_PAD_GPMI_D02__GPIO_0_2
+						MX28_PAD_GPMI_D03__GPIO_0_3
+						MX28_PAD_GPMI_D04__GPIO_0_4
+						MX28_PAD_GPMI_D05__GPIO_0_5
+						MX28_PAD_GPMI_D06__GPIO_0_6
+						MX28_PAD_GPMI_D07__GPIO_0_7
+						MX28_PAD_GPMI_CE0N__GPIO_0_16
+						MX28_PAD_GPMI_RDY1__GPIO_0_21
+						MX28_PAD_GPMI_RDN__GPIO_0_24
+						MX28_PAD_GPMI_WRN__GPIO_0_25
+						MX28_PAD_GPMI_ALE__GPIO_0_26
+					>;
+					fsl,drive-strength = <MXS_DRIVE_4mA>;
+					fsl,voltage = <MXS_VOLTAGE_HIGH>;
+					fsl,pull-up = <MXS_PULL_DISABLE>;
+
+				};
+
 			};
 		};
 
@@ -75,4 +97,25 @@
 		};
 	};
 
+	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>;
+	};
+
 };
-- 
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

* [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 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 = <&reg_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 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 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

* 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] 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: [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

* 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: [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 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

* [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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox