* Re: [PATCH 2/2] serial: imx: fix endless loop during suspend
From: Fabio Estevam @ 2018-01-02 19:31 UTC (permalink / raw)
To: Martin Kaiser
Cc: Greg Kroah-Hartman, Jiri Slaby, Sascha Hauer, Philipp Zabel,
Shawn Guo, linux-serial, linux-kernel, stable
In-Reply-To: <20180102161555.GA4503@botnar.kaiser.cx>
Hi Martin,
On Tue, Jan 2, 2018 at 2:15 PM, Martin Kaiser <martin@kaiser.cx> wrote:
> Fabio, could you post the output of
>
> cat /sys/kernel/debug/suspend_stats
>
> after supend failed, to confirm that we're failing below
> device_suspend_noirq()?
Here it goes:
# cat /sys/kernel/debug/suspend_stats
success: 0
fail: 1
failed_freeze: 0
failed_prepare: 0
failed_suspend: 0
failed_suspend_late: 0
failed_suspend_noirq: 1
failed_resume: 0
failed_resume_early: 0
failed_resume_noirq: 0
failures:
last_failed_dev:
last_failed_errno: -16
0
last_failed_step: suspend_noirq
^ permalink raw reply
* Re: [PATCH 2/2] serial: imx: fix endless loop during suspend
From: Martin Kaiser @ 2018-01-02 16:15 UTC (permalink / raw)
To: Fabio Estevam
Cc: Greg Kroah-Hartman, Jiri Slaby, Sascha Hauer, Philipp Zabel,
Shawn Guo, linux-serial, linux-kernel, stable
In-Reply-To: <CAOMZO5AvFePCoKYQe7bt9bzFmdLYrgDyPLkepz99bJk7BTB0Lg@mail.gmail.com>
Hi Fabio,
thanks for testing my patch. Sorry for breaking suspend on your board.
Thus wrote Fabio Estevam (festevam@gmail.com):
> Which i.MX SoC did you use to test this patch?
I tested on an imx258.
> On a imx6q-cuboxi I am no longer able to enter in suspend with this
> path applied:
> # echo enabled > /sys/class/tty/ttymxc0/power/wakeup
> # echo mem > /sys/power/state
> [ 9.766903] PM: suspend entry (deep)
> [ 9.770658] PM: Syncing filesystems ... done.
> [ 9.815312] Freezing user space processes ... (elapsed 0.001 seconds) done.
> [ 9.824744] OOM killer disabled.
> [ 9.827998] Freezing remaining freezable tasks ... (elapsed 0.001
> seconds) done.
> [ 9.837351] Suspending console(s) (use no_console_suspend to debug)
> [ 9.915495] PM: suspend devices took 0.080 seconds
> [ 9.928746] PM: noirq suspend of devices failed
> [ 10.196232] mmc0: queuing unknown CIS tuple 0x80 (2 bytes)
> [ 10.198148] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
> [ 10.200042] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
> [ 10.203420] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> [ 10.206812] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
> [ 10.263097] PM: resume devices took 0.330 seconds
> [ 10.266639] ata1: SATA link down (SStatus 0 SControl 300)
> [ 10.310305] OOM killer enabled.
> [ 10.313458] Restarting tasks ... done.
> [ 10.319568] PM: suspend exit
> sh: write error: Device or resource busy
> Even if I do not press anything in the console the system gets out of
> suspend automatically.
So the suspend_noirq step failed with -EBUSY.
My guess is that the following code path is taken
suspend_devices_and_enter()
suspend_enter()
dpm_suspend_noirq()
dpm_noirq_suspend_devices()
device_suspend_noirq()
__device_suspend_noirq()
pm_wakeup_pending()
and pm_wakeup_pending() returns true. We'd then have an async_error
-EBUSY.
If that's the case, I don't understand why it happens for imx6q.
We should only have a pending wakeup event if wakeup_source_activate()
or ..._deactivate() has been called.
Seeing this kind of problem, I wonder if it's ok to move setting AWAKEN
from the suspend to the suspend_noirq step. The imx uart's interrupt is
now re-enabled and IRQD_WAKEUP_ARMED is set before we configure the uart
to generate such interrupts (by setting AWAKEN), whereas before, it was
the other way around. I'd be grateful if anyone could shed some light
on this. (Or more generally: When must the hardware be configured to
generate wakeup interrupts? Is it ok to do this in supend_noirq or must
it be done before?)
Fabio, could you post the output of
cat /sys/kernel/debug/suspend_stats
after supend failed, to confirm that we're failing below
device_suspend_noirq()?
Thanks,
Martin
^ permalink raw reply
* Re: [PATCH RFC 6/7] serial: Add device tree bindings for GENI based UART Controller
From: Rob Herring @ 2018-01-02 15:55 UTC (permalink / raw)
To: Karthikeyan Ramasubramanian
Cc: linux-arm-msm, linux-i2c, linux-serial, linux-doc, devicetree,
andy.gross, david.brown, mark.rutland, corbet, wsa, gregkh,
jslaby, Girish Mahadevan
In-Reply-To: <1514392046-30602-7-git-send-email-kramasub@codeaurora.org>
On Wed, Dec 27, 2017 at 09:27:25AM -0700, Karthikeyan Ramasubramanian wrote:
> Add device tree binding support for GENI based UART Controller in the
> QUP Wrapper.
>
> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
> Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
> ---
> .../devicetree/bindings/serial/qcom,geni-uart.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/serial/qcom,geni-uart.txt
>
> diff --git a/Documentation/devicetree/bindings/serial/qcom,geni-uart.txt b/Documentation/devicetree/bindings/serial/qcom,geni-uart.txt
> new file mode 100644
> index 0000000..e60ec6a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/qcom,geni-uart.txt
> @@ -0,0 +1,31 @@
> +Qualcomm Technologies Inc. GENI based Serial UART Controller driver
> +
> +This serial UART driver supports console use-cases. This driver is meant
> +only for Generic Interface (GENI) based Qualcomm Universal Peripheral (QUP)
> +cores and isn't backwards compatible.
> +
> +Required properties:
> +- compatible: should contain "qcom,geni-uart, qcom,geni-console"
Is console different programming model or just how you are using the
h/w? for the latter, drop it as we have stdout-path to select a console.
> +- reg: Should contain UART register location and length.
> +- interrupts: Should contain UART core interrupts.
> +- clocks: clocks needed for UART, includes the core and AHB clock.
> +- pinctrl-names/pinctrl-0/1: The GPIOs assigned to this core. The names
> + Should be "active" and "sleep" for the pin confuguration when core is active
> + or when entering sleep state.
> +- qcom,wrapper-core: Wrapper QUP core containing this UART controller.
> +
> +Example:
> +qup_uart11: qcom,qup_uart@0xa88000 {
Use generic node names and no '0x':
serial@a88000
> + compatible = "qcom,geni-uart";
> + reg = <0xa88000 0x7000>;
> + reg-names = "se_phys";
> + clock-names = "se-clk", "m-ahb", "s-ahb";
Not documented.
> + clocks = <&clock_gcc GCC_QUPV3_WRAP0_S0_CLK>,
> + <&clock_gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
> + <&clock_gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_1_uart_3_active>;
> + pinctrl-1 = <&qup_1_uart_3_sleep>;
> + interrupts = <0 355 0>;
> + qcom,wrapper-core = <&qup_0>;
> +};
> --
> Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* Re: [PATCH RFC 4/7] i2c: Add device tree bindings for GENI I2C Controller
From: Rob Herring @ 2018-01-02 15:51 UTC (permalink / raw)
To: Karthikeyan Ramasubramanian
Cc: linux-arm-msm, linux-i2c, linux-serial, linux-doc, devicetree,
andy.gross, david.brown, mark.rutland, corbet, wsa, gregkh,
jslaby, Sagar Dharia
In-Reply-To: <1514392046-30602-5-git-send-email-kramasub@codeaurora.org>
On Wed, Dec 27, 2017 at 09:27:23AM -0700, Karthikeyan Ramasubramanian wrote:
> Add device tree binding support for I2C Controller in GENI based
> QUP Wrapper.
>
> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
> ---
> .../devicetree/bindings/i2c/i2c-qcom-geni.txt | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-qcom-geni.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-qcom-geni.txt b/Documentation/devicetree/bindings/i2c/i2c-qcom-geni.txt
> new file mode 100644
> index 0000000..d2fa9ce
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-qcom-geni.txt
> @@ -0,0 +1,39 @@
> +Qualcomm Technologies Inc. GENI based I2C Controller driver
> +
> +Required properties:
> + - compatible: Should be:
> + * "qcom,i2c-geni.
Only 1 version?
> + - reg: Should contain QUP register address and length.
> + - interrupts: Should contain I2C interrupt.
> + - clocks: Serial engine core clock, and AHB clocks needed by the device.
Are there really clocks for a firmware based device or these are just
clocks in the parent serial engine?
> + - pinctrl-names/pinctrl-0/1: The GPIOs assigned to this core. The names
> + should be "active" and "sleep" for the pin confuguration when core is active
> + or when entering sleep state.
> + - #address-cells: Should be <1> Address cells for i2c device address
> + - #size-cells: Should be <0> as i2c addresses have no size component
> + - qcom,wrapper-core: Wrapper QUP core containing this I2C controller.
Probably these devices should be child nodes of the QUP core node.
> +
> +Optional property:
> + - qcom,clk-freq-out : Desired I2C bus clock frequency in Hz.
> + When missing default to 400000Hz.
There's a standard property for this.
> +
> +Child nodes should conform to i2c bus binding.
> +
> +Example:
> +
> +i2c@a94000 {
> + compatible = "qcom,i2c-geni";
> + reg = <0xa94000 0x4000>;
> + interrupts = <GIC_SPI 358 0>;
> + clock-names = "se-clk", "m-ahb", "s-ahb";
> + clocks = <&clock_gcc GCC_QUPV3_WRAP0_S5_CLK>,
> + <&clock_gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
> + <&clock_gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_1_i2c_5_active>;
> + pinctrl-1 = <&qup_1_i2c_5_sleep>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + qcom,wrapper-core = <&qup_0>;
> + qcom,clk-freq-out = <400000>;
> +};
> --
> Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* Re: [PATCH RFC 2/7] soc: qcom: Add device tree binding for GENI SE
From: Rob Herring @ 2018-01-02 15:47 UTC (permalink / raw)
To: Karthikeyan Ramasubramanian
Cc: linux-arm-msm, linux-i2c, linux-serial, linux-doc, devicetree,
andy.gross, david.brown, mark.rutland, corbet, wsa, gregkh,
jslaby
In-Reply-To: <1514392046-30602-3-git-send-email-kramasub@codeaurora.org>
On Wed, Dec 27, 2017 at 09:27:21AM -0700, Karthikeyan Ramasubramanian wrote:
> Add device tree binding support for the QCOM GENI SE driver.
Also, "dt-bindings: ..." is the preferred subject prefix. Same for the
rest of the series.
>
> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
> ---
> .../devicetree/bindings/soc/qcom/qcom,geni-se.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
^ permalink raw reply
* Re: [PATCH RFC 2/7] soc: qcom: Add device tree binding for GENI SE
From: Rob Herring @ 2018-01-02 15:46 UTC (permalink / raw)
To: Karthikeyan Ramasubramanian
Cc: linux-arm-msm, linux-i2c, linux-serial, linux-doc, devicetree,
andy.gross, david.brown, mark.rutland, corbet, wsa, gregkh,
jslaby
In-Reply-To: <1514392046-30602-3-git-send-email-kramasub@codeaurora.org>
On Wed, Dec 27, 2017 at 09:27:21AM -0700, Karthikeyan Ramasubramanian wrote:
> Add device tree binding support for the QCOM GENI SE driver.
>
> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
> ---
> .../devicetree/bindings/soc/qcom/qcom,geni-se.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
> new file mode 100644
> index 0000000..5108b62
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
> @@ -0,0 +1,15 @@
> +Qualcomm Technologies, Inc. GENI Serial Engine Driver
> +
> +GENI Serial Engine Driver manages the GENI firmware based Qualcomm Universal
> +Peripheral (QUP) Wrapper. GENI SE Driver also manages the common aspects of
> +individual Serial Engines that composes the QUP Wrapper.
Bindings describe h/w, not drivers.
> +
> +Required properties:
> +- compatible: Must be "qcom,geni-se-qup".
Only one version of the h/w?
> +- reg: Must contain QUP register address and length.
> +
> +Example:
> + qup_0: qcom,geni_se_qup_0@8c0000 {
Don't use '_' in node names.
> + compatible = "qcom,geni-se-qup";
> + reg = <0x8c0000 0x6000>;
> + }
> --
> Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* Re: [RFC v2 7/9] bluetooth: btrtl: load the config blob from devicetree when available
From: Marcel Holtmann @ 2018-01-02 11:38 UTC (permalink / raw)
To: Carlo Caione
Cc: Martin Blumenstingl, Rob Herring, devicetree,
open list:BLUETOOTH DRIVERS, linux-serial-u79uwXL29TY76Z2rM5mHXA,
Mark Rutland, Gustavo F. Padovan, Johan Hedberg,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, jslaby-IBi9RG/b67k,
johan-DgEjT+Ai2ygdnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ, Daniel Drake
In-Reply-To: <CAL9uMOH0N-4jgQncmPjK-KyU0vY9Q0ZnHYSAGgz3z3ywzc8Avw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Carlo,
>>>>> Some Realtek bluetooth devices need a "config" blob. The btrtl driver
>>>>> currently only allows loading this config blob via the request_firmware
>>>>> mechanism.
>>>>>
>>>>> The UART Bluetooth chips use this config blob to specify the baudrate,
>>>>> whether flow control is used and some other unknown bits. This means
>>>>> that the config blob is board-specific - thus loading it via
>>>>> request_firmware means that the rootfs is tied to a specific board.
>>>>>
>>>>> The UART Bluetooth chips are implemented through serdev. This means
>>>>> there is also a devicetree node which describes the Bluetooth chip.
>>>>> Thus we can also load the blob from the devicetree node to keep the
>>>>> filesystem independent of any board configuration data. In the future
>>>>> this could be extended to support ACPI as well (in case that's needed).
>>>>>
>>>>> Parse the devicetree node if it exists and obtain the config blob from
>>>>> there. Otherwise fall back to using the "old" request_firmware
>>>>> mechanism.
>>>>
>>>> where are these config blobs coming from? I think we also need to give people a helping hand on how to add them to DT. I still wonder if the only pieces we are using are the UART config, then maybe skipping the config blob and allowing for clear named values in DT might be better.
>>>
>>> What about x86 platforms where we do not have DT (I didn't check but I
>>> don't think that the UART config in that case is shipped in the ACPI
>>> tables)?
>>
>> if we have this hardware in x86 systems, then I would really like to see ACPI table dumps. Some pieces might need hardcoding based on ACPI ID.
>
> Yes, we have, especially on cherry-trail SoCs. In [0] the DSDT of a
> cherry-trail laptop shipping the rtl8723bs (device OBDA8723).
>
> [0] https://gist.github.com/carlocaione/82bff95ababb67dd33f52a86e94ce3ff
so the BTHx entries normally come at least with the UART configuration. It would be useful check if it is actually correct. And then I think similar handling like what is done in hci_bcm.c and hci_intel.c needs to happen here.
I think that we extended serdev to ACPI as well. Don’t recall of the top of my head if these patches were merged or not. But if they are then it is as simple as a serdev DT based driver. Just add the appropriate _HID and got from there.
However now I think that moving towards making hci_h5.c more like generic abstraction like hci_h4.c and having a hci_rtl.c be specific for Realtek chips seems a bit cleaner direction. Frankly only H:4 and H:5 plain protocols should be used by btattach. And all others should go via serdev.
Regards
Marcel
--
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: [RFC v2 7/9] bluetooth: btrtl: load the config blob from devicetree when available
From: Carlo Caione @ 2018-01-02 11:31 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Martin Blumenstingl, Rob Herring, devicetree,
open list:BLUETOOTH DRIVERS, linux-serial-u79uwXL29TY76Z2rM5mHXA,
Mark Rutland, Gustavo F. Padovan, Johan Hedberg,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, jslaby-IBi9RG/b67k,
johan-DgEjT+Ai2ygdnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ, Daniel Drake
In-Reply-To: <E8E39477-CF1A-4A3E-84C5-830E182C2266-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
On Tue, Jan 2, 2018 at 11:19 AM, Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org> wrote:
> Hi Carlo,
>
>>>> Some Realtek bluetooth devices need a "config" blob. The btrtl driver
>>>> currently only allows loading this config blob via the request_firmware
>>>> mechanism.
>>>>
>>>> The UART Bluetooth chips use this config blob to specify the baudrate,
>>>> whether flow control is used and some other unknown bits. This means
>>>> that the config blob is board-specific - thus loading it via
>>>> request_firmware means that the rootfs is tied to a specific board.
>>>>
>>>> The UART Bluetooth chips are implemented through serdev. This means
>>>> there is also a devicetree node which describes the Bluetooth chip.
>>>> Thus we can also load the blob from the devicetree node to keep the
>>>> filesystem independent of any board configuration data. In the future
>>>> this could be extended to support ACPI as well (in case that's needed).
>>>>
>>>> Parse the devicetree node if it exists and obtain the config blob from
>>>> there. Otherwise fall back to using the "old" request_firmware
>>>> mechanism.
>>>
>>> where are these config blobs coming from? I think we also need to give people a helping hand on how to add them to DT. I still wonder if the only pieces we are using are the UART config, then maybe skipping the config blob and allowing for clear named values in DT might be better.
>>
>> What about x86 platforms where we do not have DT (I didn't check but I
>> don't think that the UART config in that case is shipped in the ACPI
>> tables)?
>
> if we have this hardware in x86 systems, then I would really like to see ACPI table dumps. Some pieces might need hardcoding based on ACPI ID.
Yes, we have, especially on cherry-trail SoCs. In [0] the DSDT of a
cherry-trail laptop shipping the rtl8723bs (device OBDA8723).
[0] https://gist.github.com/carlocaione/82bff95ababb67dd33f52a86e94ce3ff
Cheers,
--
Carlo Caione | +44.7384.69.16.04 | Endless
^ permalink raw reply
* Re: [RFC v2 7/9] bluetooth: btrtl: load the config blob from devicetree when available
From: Marcel Holtmann @ 2018-01-02 11:19 UTC (permalink / raw)
To: Carlo Caione
Cc: Martin Blumenstingl, Rob Herring, devicetree,
open list:BLUETOOTH DRIVERS, linux-serial-u79uwXL29TY76Z2rM5mHXA,
Mark Rutland, Gustavo F. Padovan, Johan Hedberg,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, jslaby-IBi9RG/b67k,
johan-DgEjT+Ai2ygdnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ, Daniel Drake
In-Reply-To: <CAL9uMOEMDup4hRkxD-tM8R0YirGs5uQi31AjJUnFCPNMKUdRHg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Carlo,
>>> Some Realtek bluetooth devices need a "config" blob. The btrtl driver
>>> currently only allows loading this config blob via the request_firmware
>>> mechanism.
>>>
>>> The UART Bluetooth chips use this config blob to specify the baudrate,
>>> whether flow control is used and some other unknown bits. This means
>>> that the config blob is board-specific - thus loading it via
>>> request_firmware means that the rootfs is tied to a specific board.
>>>
>>> The UART Bluetooth chips are implemented through serdev. This means
>>> there is also a devicetree node which describes the Bluetooth chip.
>>> Thus we can also load the blob from the devicetree node to keep the
>>> filesystem independent of any board configuration data. In the future
>>> this could be extended to support ACPI as well (in case that's needed).
>>>
>>> Parse the devicetree node if it exists and obtain the config blob from
>>> there. Otherwise fall back to using the "old" request_firmware
>>> mechanism.
>>
>> where are these config blobs coming from? I think we also need to give people a helping hand on how to add them to DT. I still wonder if the only pieces we are using are the UART config, then maybe skipping the config blob and allowing for clear named values in DT might be better.
>
> What about x86 platforms where we do not have DT (I didn't check but I
> don't think that the UART config in that case is shipped in the ACPI
> tables)?
if we have this hardware in x86 systems, then I would really like to see ACPI table dumps. Some pieces might need hardcoding based on ACPI ID.
Regards
Marcel
^ permalink raw reply
* Re: [RFC v2 1/9] serdev: implement parity configuration
From: Marcel Holtmann @ 2018-01-02 11:16 UTC (permalink / raw)
To: Martin Blumenstingl, Rob Herring
Cc: devicetree, open list:BLUETOOTH DRIVERS,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
Gustavo F. Padovan, Johan Hedberg, Greg Kroah-Hartman, Jiri Slaby,
Johan Hovold, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Larry Finger, Carlo Caione, Daniel Drake
In-Reply-To: <20180101204217.26165-2-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Hi Martin,
> Some Bluetooth modules (for example the ones found in Realtek RTL8723BS
> and RTL8723DS) want to communicate with the host with even parity
> enabled.
> Add a new function and the corresponding internal callbacks so parity
> can be configured. This supports enabling and disabling parity as well
> as setting the type to odd or even.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> drivers/tty/serdev/core.c | 12 ++++++++++++
> drivers/tty/serdev/serdev-ttyport.c | 21 +++++++++++++++++++++
> include/linux/serdev.h | 5 +++++
> 3 files changed, 38 insertions(+)
>
> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> index 1bef39828ca7..d327b02980f5 100644
> --- a/drivers/tty/serdev/core.c
> +++ b/drivers/tty/serdev/core.c
> @@ -225,6 +225,18 @@ void serdev_device_set_flow_control(struct serdev_device *serdev, bool enable)
> }
> EXPORT_SYMBOL_GPL(serdev_device_set_flow_control);
>
> +void serdev_device_set_parity(struct serdev_device *serdev, bool enable,
> + bool odd)
> +{
> + struct serdev_controller *ctrl = serdev->ctrl;
> +
> + if (!ctrl || !ctrl->ops->set_parity)
> + return;
> +
> + ctrl->ops->set_parity(ctrl, enable, odd);
> +}
> +EXPORT_SYMBOL_GPL(serdev_device_set_parity);
> +
this really needs Rob’s ACK before I take the patch.
Regards
Marcel
^ permalink raw reply
* Re: [RFC v2 2/9] dt-bindings: net: bluetooth: add support for Realtek Bluetooth chips
From: Marcel Holtmann @ 2018-01-02 11:16 UTC (permalink / raw)
To: Martin Blumenstingl, Rob Herring
Cc: devicetree, open list:BLUETOOTH DRIVERS,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
Gustavo F. Padovan, Johan Hedberg, Greg Kroah-Hartman, Jiri Slaby,
Johan Hovold, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Larry Finger, Carlo Caione, Daniel Drake
In-Reply-To: <20180101204217.26165-3-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Hi Martin,
> This adds the documentation for Bluetooth functionality of the Realtek
> RTL8723BS and RTL8723DS.
> Both are SDIO wifi chips with an additional Bluetooth module which is
> connected via UART to the host.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> .../devicetree/bindings/net/realtek-bluetooth.txt | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/realtek-bluetooth.txt
>
> diff --git a/Documentation/devicetree/bindings/net/realtek-bluetooth.txt b/Documentation/devicetree/bindings/net/realtek-bluetooth.txt
> new file mode 100644
> index 000000000000..1491329c4cd1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek-bluetooth.txt
> @@ -0,0 +1,41 @@
> +Realtek Bluetooth Chips
> +-----------------------
> +
> +This documents the binding structure and common properties for serial
> +attached Realtek devices.
> +
> +Serial attached Realtek devices shall be a child node of the host UART
> +device the slave device is attached to. See ../serial/slave-device.txt
> +for more information
> +
> +Required properties:
> +- compatible: should contain one of the following:
> + * "realtek,rtl8723bs-bluetooth"
> + * "realtek,rtl8723ds-bluetooth"
> +
> +Optional properties:
> +- realtek,config-data: Bluetooth chipset configuration data which is
> + needed for communication (it typically contains
> + board specific settings like the baudrate and
> + whether flow-control is used).
> + This is an array of u8 values.
any chance we can at least include the basic format of these config blobs. And I prefer at least an ACK from Rob here.
> +- enable-gpios: GPIO specifier, used to enable/disable the BT module
> +- reset-gpios: GPIO specifier, used to reset the BT module
> +
> +
> +Example:
> +
> +&uart {
> + ...
> +
> + bluetooth {
> + compatible = "realtek,rtl8723bs-bluetooth";
> + enable-gpios = <&gpio 20 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio 11 GPIO_ACTIVE_HIGH>;
> + realtek,config-data = /bits/ 8 <
> + 0x55 0xab 0x23 0x87 0x29 0x00 0xf4 0x00 0x01 0x01 0xf6 0x00
> + 0x02 0x81 0x00 0xfa 0x00 0x02 0x12 0x80 0x0c 0x00 0x10 0x02
> + 0x80 0x92 0x04 0x50 0xc5 0xea 0x19 0xe1 0x1b 0xfd 0xaf 0x5f
> + 0x01 0xa4 0x0b 0xd9 0x00 0x01 0x0f 0xe4 0x00 0x01 0x08>;
> + };
> +};
Regards
Marcel
^ permalink raw reply
* Re: [RFC v2 7/9] bluetooth: btrtl: load the config blob from devicetree when available
From: Carlo Caione @ 2018-01-02 11:15 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Martin Blumenstingl, Rob Herring, devicetree,
open list:BLUETOOTH DRIVERS, linux-serial-u79uwXL29TY76Z2rM5mHXA,
Mark Rutland, Gustavo F. Padovan, Johan Hedberg,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, jslaby-IBi9RG/b67k,
johan-DgEjT+Ai2ygdnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ, Daniel Drake
In-Reply-To: <563D6F9F-8495-40D4-BE56-5338ED2B9B99-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
On Tue, Jan 2, 2018 at 11:11 AM, Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org> wrote:
> Hi Martin,
>
>> Some Realtek bluetooth devices need a "config" blob. The btrtl driver
>> currently only allows loading this config blob via the request_firmware
>> mechanism.
>>
>> The UART Bluetooth chips use this config blob to specify the baudrate,
>> whether flow control is used and some other unknown bits. This means
>> that the config blob is board-specific - thus loading it via
>> request_firmware means that the rootfs is tied to a specific board.
>>
>> The UART Bluetooth chips are implemented through serdev. This means
>> there is also a devicetree node which describes the Bluetooth chip.
>> Thus we can also load the blob from the devicetree node to keep the
>> filesystem independent of any board configuration data. In the future
>> this could be extended to support ACPI as well (in case that's needed).
>>
>> Parse the devicetree node if it exists and obtain the config blob from
>> there. Otherwise fall back to using the "old" request_firmware
>> mechanism.
>
> where are these config blobs coming from? I think we also need to give people a helping hand on how to add them to DT. I still wonder if the only pieces we are using are the UART config, then maybe skipping the config blob and allowing for clear named values in DT might be better.
What about x86 platforms where we do not have DT (I didn't check but I
don't think that the UART config in that case is shipped in the ACPI
tables)?
Cheers,
--
Carlo Caione | +44.7384.69.16.04 | Endless
--
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: [RFC v2 7/9] bluetooth: btrtl: load the config blob from devicetree when available
From: Marcel Holtmann @ 2018-01-02 11:11 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Rob Herring, devicetree, open list:BLUETOOTH DRIVERS,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
Gustavo F. Padovan, Johan Hedberg,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, jslaby-IBi9RG/b67k,
johan-DgEjT+Ai2ygdnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ, carlo-6IF/jdPJHihWk0Htik3J/w,
drake-6IF/jdPJHihWk0Htik3J/w
In-Reply-To: <20180101204217.26165-8-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Hi Martin,
> Some Realtek bluetooth devices need a "config" blob. The btrtl driver
> currently only allows loading this config blob via the request_firmware
> mechanism.
>
> The UART Bluetooth chips use this config blob to specify the baudrate,
> whether flow control is used and some other unknown bits. This means
> that the config blob is board-specific - thus loading it via
> request_firmware means that the rootfs is tied to a specific board.
>
> The UART Bluetooth chips are implemented through serdev. This means
> there is also a devicetree node which describes the Bluetooth chip.
> Thus we can also load the blob from the devicetree node to keep the
> filesystem independent of any board configuration data. In the future
> this could be extended to support ACPI as well (in case that's needed).
>
> Parse the devicetree node if it exists and obtain the config blob from
> there. Otherwise fall back to using the "old" request_firmware
> mechanism.
where are these config blobs coming from? I think we also need to give people a helping hand on how to add them to DT. I still wonder if the only pieces we are using are the UART config, then maybe skipping the config blob and allowing for clear named values in DT might be better.
I might have asked before, but can we get a userspace similar to nokfw included in bluez.git that can parse and maybe even create/modify these blobs.
Regards
Marcel
^ permalink raw reply
* Re: [RFC v2 9/9] Bluetooth: hci_h5: add support for Realtek UART Bluetooth modules
From: Marcel Holtmann @ 2018-01-02 11:11 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
Gustavo F. Padovan, Johan Hedberg,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, jslaby-IBi9RG/b67k,
johan-DgEjT+Ai2ygdnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ, carlo-6IF/jdPJHihWk0Htik3J/w,
drake-6IF/jdPJHihWk0Htik3J/w
In-Reply-To: <20180101204217.26165-10-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Hi Martin,
> Realtek RTL8723BS and RTL8723DS are SDIO wifi chips with an embedded
> Bluetooth controller which connects to the host via UART.
> The H5 protocol is used for communication between host and device.
>
> The Realtek "rtl8723bs_bt" and "rtl8723ds_bt" userspace Bluetooth UART
> initialization tools (rtk_hciattach) use the following sequence:
> 1) send H5 sync pattern (already supported by hci_h5)
> 2) get LMP version (already supported by btrtl)
> 3) get ROM version (already supported by btrtl)
> 4) load the firmware and config for the current chipset (already
> supported by btrtl)
> 5) read UART settings from the config blob (already supported by btrtl)
> 6) send UART settings via a vendor command to the device (which changes
> the baudrate of the device and enables or disables flow control
> depending on the config)
> 7) change the baudrate and flow control settings on the host
> 8) send the firmware and config blob to the device (already supported by
> btrtl)
>
> This uses the serdev library as well as the existing btrtl driver to
> initialize the Bluetooth functionality, which consists of:
> - identifying the device and loading the corresponding firmware and
> config blobs (steps #2, #3 and #4)
> - configuring the baudrate and flow control (steps #6 and #7)
> - uploading the firmware to the device (step #8)
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> drivers/bluetooth/Kconfig | 1 +
> drivers/bluetooth/hci_h5.c | 205 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 206 insertions(+)
>
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 60e1c7d6986d..3001f1200c72 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -146,6 +146,7 @@ config BT_HCIUART_LL
> config BT_HCIUART_3WIRE
> bool "Three-wire UART (H5) protocol support"
> depends on BT_HCIUART
> + select BT_RTL if SERIAL_DEV_BUS
> help
> The HCI Three-wire UART Transport Layer makes it possible to
> user the Bluetooth HCI over a serial port interface. The HCI
while this is fine initially, I think long term this is not sustainable. So we need to abstract the H:5 part and the vendor specific setup part so that you can have a hci_rtl.c that uses H:5 instead of H:4 and still is as tiny and simple as our H:4 drivers.
One other think I am not really happy about here is the Kconfig entry itself. You need to know that you need 3WIRE and SERDEV to magically enable RTL UART support. Maybe it would be better to just have a CONFIG_HCIUART_RTL and duplicate the config entry just specific to RTL. It then can select RTL, but in the Makefile it will result in using the same hci_h5.c file.
> diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
> index 6cfc2f276250..a03acc3b1b52 100644
> --- a/drivers/bluetooth/hci_h5.c
> +++ b/drivers/bluetooth/hci_h5.c
> @@ -28,7 +28,14 @@
> #include <net/bluetooth/bluetooth.h>
> #include <net/bluetooth/hci_core.h>
>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/serdev.h>
> +
> #include "hci_uart.h"
> +#include "btrtl.h"
>
> #define HCI_3WIRE_ACK_PKT 0
> #define HCI_3WIRE_LINK_PKT 15
> @@ -97,6 +104,13 @@ struct h5 {
> } sleep;
> };
>
> +struct h5_device {
> + struct hci_uart hu;
> + struct gpio_desc *enable_gpio;
> + struct gpio_desc *reset_gpio;
> + int (*vendor_setup)(struct h5_device *h5_dev);
> +};
> +
> static void h5_reset_rx(struct h5 *h5);
>
> static void h5_link_control(struct hci_uart *hu, const void *data, size_t len)
> @@ -190,6 +204,7 @@ static int h5_open(struct hci_uart *hu)
> {
> struct h5 *h5;
> const unsigned char sync[] = { 0x01, 0x7e };
> + int err;
>
> BT_DBG("hu %p", hu);
>
> @@ -210,6 +225,14 @@ static int h5_open(struct hci_uart *hu)
>
> h5->tx_win = H5_TX_WIN_MAX;
>
> + if (hu->serdev) {
> + err = serdev_device_open(hu->serdev);
> + if (err) {
> + bt_dev_err(hu->hdev, "failed to open serdev: %d", err);
> + return err;
> + }
> + }
> +
> /* Send initial sync request */
> h5_link_control(hu, sync, sizeof(sync));
> mod_timer(&h5->timer, jiffies + H5_SYNC_TIMEOUT);
> @@ -217,6 +240,25 @@ static int h5_open(struct hci_uart *hu)
> return 0;
> }
>
> +static int h5_setup(struct hci_uart *hu)
> +{
> + int err;
> + struct h5_device *h5_dev;
> +
> + if (!hu->serdev)
> + return 0;
> +
> + h5_dev = serdev_device_get_drvdata(hu->serdev);
> +
> + if (h5_dev->vendor_setup) {
> + err = h5_dev->vendor_setup(h5_dev);
> + if (err)
> + return err;
> + }
> +
> + return 0;
> +}
> +
> static int h5_close(struct hci_uart *hu)
> {
> struct h5 *h5 = hu->priv;
> @@ -227,6 +269,15 @@ static int h5_close(struct hci_uart *hu)
> skb_queue_purge(&h5->rel);
> skb_queue_purge(&h5->unrel);
>
> + if (hu->serdev) {
> + struct h5_device *h5_dev;
> +
> + h5_dev = serdev_device_get_drvdata(hu->serdev);
> + gpiod_set_value_cansleep(h5_dev->enable_gpio, 0);
> +
> + serdev_device_close(hu->serdev);
> + }
> +
> kfree(h5);
>
> return 0;
> @@ -736,10 +787,160 @@ static int h5_flush(struct hci_uart *hu)
> return 0;
> }
>
> +#if IS_ENABLED(CONFIG_SERIAL_DEV_BUS)
> +static int h5_setup_realtek(struct h5_device *h5_dev)
> +{
> + struct hci_uart *hu = &h5_dev->hu;
> + int err = 0, retry = 3;
> + struct sk_buff *skb;
> + struct btrtl_device_info *btrtl_dev;
> + __le32 baudrate_data;
> + u32 device_baudrate;
> + unsigned int controller_baudrate;
> + bool flow_control;
> +
> + /* devices always start with flow control disabled and even parity */
> + serdev_device_set_flow_control(hu->serdev, false);
> + serdev_device_set_parity(hu->serdev, true, false);
> +
> + do {
> + /* disable the device and put it into reset. some devices only
> + * have one of these lines, so we toggle both here to support
> + * all combinations.
> + */
> + gpiod_set_value_cansleep(h5_dev->reset_gpio, 1);
> + gpiod_set_value_cansleep(h5_dev->enable_gpio, 0);
> +
> + /* wait until the device is disabled and/or reset. 500ms are
> + * chosen by manually testing on a RTL8723BS. shorter wait
> + * times lead to a non-responding device.
> + */
> + msleep(500);
> +
> + /* take the device out of reset and enable it. */
> + gpiod_set_value_cansleep(h5_dev->reset_gpio, 0);
> + gpiod_set_value_cansleep(h5_dev->enable_gpio, 1);
> +
> + /* after that we need to wait 500ms, otherwise the device might
> + * not respond in all cases. this was determined by testing
> + * with a RTL8723BS.
> + */
> + msleep(500);
> +
> + btrtl_dev = btrtl_initialize(hu->hdev);
> + if (!IS_ERR(btrtl_dev))
> + break;
> +
> + /* Toggle the enable and reset pins above and try again */
> + } while (retry--);
> +
> + if (IS_ERR(btrtl_dev))
> + return PTR_ERR(btrtl_dev);
> +
> + err = btrtl_get_uart_settings(hu->hdev, btrtl_dev,
> + &controller_baudrate, &device_baudrate,
> + &flow_control);
> + if (err)
> + goto out_free;
> +
> + baudrate_data = cpu_to_le32(device_baudrate);
> + skb = __hci_cmd_sync(hu->hdev, 0xfc17, sizeof(baudrate_data),
> + &baudrate_data, HCI_INIT_TIMEOUT);
> + if (IS_ERR(skb)) {
> + bt_dev_err(hu->hdev, "set baud rate command failed");
> + err = -PTR_ERR(skb);
> + goto out_free;
> + } else {
> + kfree_skb(skb);
> + }
> +
> + serdev_device_set_baudrate(hu->serdev, controller_baudrate);
> + serdev_device_set_flow_control(hu->serdev, flow_control);
> +
> + err = btrtl_download_firmware(hu->hdev, btrtl_dev);
> +
> +out_free:
> + btrtl_free(btrtl_dev);
> +
> + return err;
> +}
> +
> +static const struct hci_uart_proto h5p;
> +
> +static int hci_h5_probe(struct serdev_device *serdev)
> +{
> + struct hci_uart *hu;
> + struct h5_device *h5_dev;
> +
> + h5_dev = devm_kzalloc(&serdev->dev, sizeof(*h5_dev), GFP_KERNEL);
> + if (!h5_dev)
> + return -ENOMEM;
> +
> + hu = &h5_dev->hu;
> + hu->serdev = serdev;
> +
> + serdev_device_set_drvdata(serdev, h5_dev);
> +
> + h5_dev->vendor_setup = of_device_get_match_data(&serdev->dev);
> +
> + h5_dev->enable_gpio = devm_gpiod_get_optional(&serdev->dev, "enable",
> + GPIOD_OUT_HIGH);
Indentation mistake.
> + if (IS_ERR(h5_dev->enable_gpio))
> + return PTR_ERR(h5_dev->enable_gpio);
> +
> + h5_dev->reset_gpio = devm_gpiod_get_optional(&serdev->dev, "reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(h5_dev->reset_gpio))
> + return PTR_ERR(h5_dev->reset_gpio);
> +
> + hci_uart_set_speeds(hu, 115200, 0);
> +
> + return hci_uart_register_device(hu, &h5p);
> +}
> +
> +static void hci_h5_remove(struct serdev_device *serdev)
> +{
> + struct h5_device *h5_dev = serdev_device_get_drvdata(serdev);
> + struct hci_uart *hu = &h5_dev->hu;
> + struct hci_dev *hdev = hu->hdev;
> +
> + cancel_work_sync(&hu->write_work);
> +
> + hci_unregister_dev(hdev);
> + hci_free_dev(hdev);
> + hu->proto->close(hu);
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id hci_h5_of_match[] = {
> + {
> + .compatible = "realtek,rtl8723bs-bluetooth",
> + .data = h5_setup_realtek
> + },
> + {
> + .compatible = "realtek,rtl8723ds-bluetooth",
> + .data = h5_setup_realtek
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, hci_h5_of_match);
> +#endif
> +
> +static struct serdev_device_driver hci_h5_drv = {
> + .driver = {
> + .name = "hci-h5",
> + .of_match_table = of_match_ptr(hci_h5_of_match),
> + },
> + .probe = hci_h5_probe,
> + .remove = hci_h5_remove,
> +};
> +#endif
> +
> static const struct hci_uart_proto h5p = {
> .id = HCI_UART_3WIRE,
> .name = "Three-wire (H5)",
> .open = h5_open,
> + .setup = h5_setup,
> .close = h5_close,
> .recv = h5_recv,
> .enqueue = h5_enqueue,
> @@ -749,10 +950,14 @@ static const struct hci_uart_proto h5p = {
>
> int __init h5_init(void)
> {
> + serdev_device_driver_register(&hci_h5_drv);
> +
> return hci_uart_register_proto(&h5p);
> }
>
> int __exit h5_deinit(void)
> {
> + serdev_device_driver_unregister(&hci_h5_drv);
> +
> return hci_uart_unregister_proto(&h5p);
> }
Regards
Marcel
--
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: [RFC v2 8/9] Bluetooth: drop HCI_UART_INIT_PENDING support
From: Marcel Holtmann @ 2018-01-02 11:04 UTC (permalink / raw)
To: Martin Blumenstingl, Johan Hedberg
Cc: Rob Herring, devicetree, open list:BLUETOOTH DRIVERS,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
Gustavo F. Padovan, Greg Kroah-Hartman, Jiri Slaby, Johan Hovold,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Larry Finger,
Carlo Caione, Daniel Drake
In-Reply-To: <20180101204217.26165-9-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Hi Martin,
> The three-wire (H5) protocol is the only protocol which uses
> HCI_UART_INIT_PENDING.
> Unfortunately the benefits of using this flag are currently unknown. It
> was added in commit 9f2aee848fe6 ("Bluetooth: Add delayed init sequence
> support for UART controllers"). In my experiments (with the
> "rtk_hciattach" tool - a customized version of hciattach for Realtek
> chipsets) I started the tool before and after this patch while the
> Bluetooth chipset was disabled (by pulling it's enable GPIO LOW). In
> both cases hci0 was not created - thus HCI_UART_INIT_PENDING is not
> required in that case.
>
> Removing this code also has another benefit: hci_serdev.c does not
> support the delayed initialization / registration. Thus the protocol
> implementation (hci_h5) never receives any data with this check still
> in place. For the H5 protocol this means that the initialization never
> completes (because the sync response never arrives). Even if the
> initialization would succeed later on the drivers would call
> hci_uart_init_ready() which schedules the registration which is
> currently not implemented by hci_serdev.c.
>
> Removing the HCI_UART_INIT_PENDING check makes the code easier to read
> and also fixes the initalization of devices (implemented with the serdev
> library) which use the H5 protocol.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
I really like Johan to ack this one, but generally I am fine with removing unneeded code.
We might also want to look at hciattach to btattach code and make sure it gets removed there as well. I am not even sure anybody used hciattach with H:5 ever.
> ---
> drivers/bluetooth/hci_h5.c | 3 ---
> drivers/bluetooth/hci_ldisc.c | 38 --------------------------------------
> drivers/bluetooth/hci_serdev.c | 3 ---
> drivers/bluetooth/hci_uart.h | 4 +---
> 4 files changed, 1 insertion(+), 47 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
> index 6a8d0d06aba7..6cfc2f276250 100644
> --- a/drivers/bluetooth/hci_h5.c
> +++ b/drivers/bluetooth/hci_h5.c
> @@ -210,8 +210,6 @@ static int h5_open(struct hci_uart *hu)
>
> h5->tx_win = H5_TX_WIN_MAX;
>
> - set_bit(HCI_UART_INIT_PENDING, &hu->hdev_flags);
> -
> /* Send initial sync request */
> h5_link_control(hu, sync, sizeof(sync));
> mod_timer(&h5->timer, jiffies + H5_SYNC_TIMEOUT);
> @@ -316,7 +314,6 @@ static void h5_handle_internal_rx(struct hci_uart *hu)
> h5->tx_win = (data[2] & 0x07);
> BT_DBG("Three-wire init complete. tx_win %u", h5->tx_win);
> h5->state = H5_ACTIVE;
> - hci_uart_init_ready(hu);
> return;
> } else if (memcmp(data, sleep_req, 2) == 0) {
> BT_DBG("Peer went to sleep");
> diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
> index c823914b3a80..5dd3e1bebfe4 100644
> --- a/drivers/bluetooth/hci_ldisc.c
> +++ b/drivers/bluetooth/hci_ldisc.c
> @@ -195,39 +195,6 @@ static void hci_uart_write_work(struct work_struct *work)
> clear_bit(HCI_UART_SENDING, &hu->tx_state);
> }
>
> -static void hci_uart_init_work(struct work_struct *work)
> -{
> - struct hci_uart *hu = container_of(work, struct hci_uart, init_ready);
> - int err;
> - struct hci_dev *hdev;
> -
> - if (!test_and_clear_bit(HCI_UART_INIT_PENDING, &hu->hdev_flags))
> - return;
> -
> - err = hci_register_dev(hu->hdev);
> - if (err < 0) {
> - BT_ERR("Can't register HCI device");
> - hdev = hu->hdev;
> - hu->hdev = NULL;
> - hci_free_dev(hdev);
> - clear_bit(HCI_UART_PROTO_READY, &hu->flags);
> - hu->proto->close(hu);
> - return;
> - }
> -
> - set_bit(HCI_UART_REGISTERED, &hu->flags);
> -}
> -
> -int hci_uart_init_ready(struct hci_uart *hu)
> -{
> - if (!test_bit(HCI_UART_INIT_PENDING, &hu->hdev_flags))
> - return -EALREADY;
> -
> - schedule_work(&hu->init_ready);
> -
> - return 0;
> -}
> -
> /* ------- Interface to HCI layer ------ */
> /* Initialize device */
> static int hci_uart_open(struct hci_dev *hdev)
> @@ -490,7 +457,6 @@ static int hci_uart_tty_open(struct tty_struct *tty)
> hu->alignment = 1;
> hu->padding = 0;
>
> - INIT_WORK(&hu->init_ready, hci_uart_init_work);
> INIT_WORK(&hu->write_work, hci_uart_write_work);
>
> percpu_init_rwsem(&hu->proto_lock);
> @@ -653,9 +619,6 @@ static int hci_uart_register_dev(struct hci_uart *hu)
> else
> hdev->dev_type = HCI_PRIMARY;
>
> - if (test_bit(HCI_UART_INIT_PENDING, &hu->hdev_flags))
> - return 0;
> -
> if (hci_register_dev(hdev) < 0) {
> BT_ERR("Can't register HCI device");
> hu->hdev = NULL;
> @@ -699,7 +662,6 @@ static int hci_uart_set_flags(struct hci_uart *hu, unsigned long flags)
> unsigned long valid_flags = BIT(HCI_UART_RAW_DEVICE) |
> BIT(HCI_UART_RESET_ON_INIT) |
> BIT(HCI_UART_CREATE_AMP) |
> - BIT(HCI_UART_INIT_PENDING) |
> BIT(HCI_UART_EXT_CONFIG) |
> BIT(HCI_UART_VND_DETECT);
>
> diff --git a/drivers/bluetooth/hci_serdev.c b/drivers/bluetooth/hci_serdev.c
> index e0e6461b9200..fe67eb6d4278 100644
> --- a/drivers/bluetooth/hci_serdev.c
> +++ b/drivers/bluetooth/hci_serdev.c
> @@ -333,9 +333,6 @@ int hci_uart_register_device(struct hci_uart *hu,
> else
> hdev->dev_type = HCI_PRIMARY;
>
> - if (test_bit(HCI_UART_INIT_PENDING, &hu->hdev_flags))
> - return 0;
> -
> if (hci_register_dev(hdev) < 0) {
> BT_ERR("Can't register HCI device");
> err = -ENODEV;
> diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
> index 66e8c68e4607..47e755ff4092 100644
> --- a/drivers/bluetooth/hci_uart.h
> +++ b/drivers/bluetooth/hci_uart.h
> @@ -53,7 +53,7 @@
> #define HCI_UART_RAW_DEVICE 0
> #define HCI_UART_RESET_ON_INIT 1
> #define HCI_UART_CREATE_AMP 2
> -#define HCI_UART_INIT_PENDING 3
> +/* 3 is unused - was HCI_UART_INIT_PENDING */
#define HCI_UART_INIT_PENDING 3 /* unused */
I prefer it this way since it is easier on the eyes.
> #define HCI_UART_EXT_CONFIG 4
> #define HCI_UART_VND_DETECT 5
>
> @@ -83,7 +83,6 @@ struct hci_uart {
> unsigned long flags;
> unsigned long hdev_flags;
>
> - struct work_struct init_ready;
> struct work_struct write_work;
>
> const struct hci_uart_proto *proto;
> @@ -115,7 +114,6 @@ int hci_uart_register_device(struct hci_uart *hu, const struct hci_uart_proto *p
> void hci_uart_unregister_device(struct hci_uart *hu);
>
> int hci_uart_tx_wakeup(struct hci_uart *hu);
> -int hci_uart_init_ready(struct hci_uart *hu);
> void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed);
> void hci_uart_set_flow_control(struct hci_uart *hu, bool enable);
> void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
Regards
Marcel
--
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 RFC 3/3] MIPS: AR7: ensure the port type's FCR value is used
From: James Hogan @ 2018-01-02 8:40 UTC (permalink / raw)
To: Jonas Gorski, Ralf Baechle
Cc: MIPS Mailing List, linux-serial, Greg Kroah-Hartman,
Yoshihiro YUNOMAE, Florian Fainelli, Nicolas Schichan
In-Reply-To: <CAOiHx==rL82D4NMz8t15jMr8m5oQmhkAzc+9r6qA0WMgbS-b9w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]
On Thu, Dec 28, 2017 at 04:38:29PM +0100, Jonas Gorski wrote:
> On 14 November 2017 at 12:02, James Hogan <james.hogan@mips.com> wrote:
> > On Sun, Oct 29, 2017 at 04:27:21PM +0100, Jonas Gorski wrote:
> >> Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt
> >> trigger I/F of FIFO buffers"), the port's default FCR value isn't used
> >> in serial8250_do_set_termios anymore, but copied over once in
> >> serial8250_config_port and then modified as needed.
> >>
> >> Unfortunately, serial8250_config_port will never be called if the port
> >> is shared between kernel and userspace, and the port's flag doesn't have
> >> UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well.
> >>
> >> This causes garbled output from userspace:
> >>
> >> [ 5.220000] random: procd urandom read with 49 bits of entropy available
> >> ers
> >> [kee
> >>
> >> Fix this by forcing it to be configured on boot, resulting in the
> >> expected output:
> >>
> >> [ 5.250000] random: procd urandom read with 50 bits of entropy available
> >> Press the [f] key and hit [enter] to enter failsafe mode
> >> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
> >>
> >> Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers")
> >> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
> >> ---
> >> I'm not sure if this is just AR7's issue, or if this points to a general
> >> issue for UARTs used as kernel console and login console with the "fixed"
> >> commit.
> >
> > Thanks. Given nobody seems to have objected, I've applied to my
> > mips-fixes branch, with stable tag for 3.17+.
>
> Hmm, I don't see it in
> https://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips.git/log/?h=mips-fixes
> - did you maybe forget to push?
Ralf reappeared so I delegated the patch to him in patchwork, and he has
apparently marked it as accepted.
But perhaps that only just happened and he hasn't pushed yet. Ralf?
Cheers
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v5 39/39] dt-bindings: timer: Add andestech atcpit100 timer binding doc
From: Greentime Hu @ 2018-01-02 8:25 UTC (permalink / raw)
To: greentime, linux-kernel, arnd, linux-arch, tglx, jason,
marc.zyngier, robh+dt, netdev, deanbo422, devicetree, viro,
dhowells, will.deacon, daniel.lezcano, linux-serial,
geert.uytterhoeven, linus.walleij, mark.rutland, greg, ren_guo,
rdunlap, davem, jonas, stefan.kristiansson, shorne
Cc: Rick Chen, green.hu
In-Reply-To: <cover.1514874857.git.green.hu@gmail.com>
From: Rick Chen <rickchen36@gmail.com>
Add a document to describe Andestech atcpit100 timer and
binding information.
Signed-off-by: Rick Chen <rickchen36@gmail.com>
Signed-off-by: Greentime Hu <green.hu@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/timer/andestech,atcpit100-timer.txt | 33 ++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
new file mode 100644
index 0000000..4c9ea59
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
@@ -0,0 +1,33 @@
+Andestech ATCPIT100 timer
+------------------------------------------------------------------
+ATCPIT100 is a generic IP block from Andes Technology, embedded in
+Andestech AE3XX platforms and other designs.
+
+This timer is a set of compact multi-function timers, which can be
+used as pulse width modulators (PWM) as well as simple timers.
+
+It supports up to 4 PIT channels. Each PIT channel is a
+multi-function timer and provide the following usage scenarios:
+One 32-bit timer
+Two 16-bit timers
+Four 8-bit timers
+One 16-bit PWM
+One 16-bit timer and one 8-bit PWM
+Two 8-bit timer and one 8-bit PWM
+
+Required properties:
+- compatible : Should be "andestech,atcpit100"
+- reg : Address and length of the register set
+- interrupts : Reference to the timer interrupt
+- clocks : a clock to provide the tick rate for "andestech,atcpit100"
+- clock-names : should be "PCLK" for the peripheral clock source.
+
+Examples:
+
+timer0: timer@f0400000 {
+ compatible = "andestech,atcpit100";
+ reg = <0xf0400000 0x1000>;
+ interrupts = <2>;
+ clocks = <&apb>;
+ clock-names = "PCLK";
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 38/39] clocksource/drivers/atcpit100: VDSO support
From: Greentime Hu @ 2018-01-02 8:25 UTC (permalink / raw)
To: greentime, linux-kernel, arnd, linux-arch, tglx, jason,
marc.zyngier, robh+dt, netdev, deanbo422, devicetree, viro,
dhowells, will.deacon, daniel.lezcano, linux-serial,
geert.uytterhoeven, linus.walleij, mark.rutland, greg, ren_guo,
rdunlap, davem, jonas, stefan.kristiansson, shorne
Cc: Rick Chen, green.hu, Vincent Chen
In-Reply-To: <cover.1514874857.git.green.hu@gmail.com>
From: Rick Chen <rickchen36@gmail.com>
VDSO needs real-time cycle count to ensure the time accuracy.
Unlike others, nds32 architecture does not define clock source,
hence VDSO needs atcpit100 offering real-time cycle count
to derive the correct time.
Signed-off-by: Vincent Chen <vincentc@andestech.com>
Signed-off-by: Rick Chen <rickchen36@gmail.com>
Signed-off-by: Greentime Hu <green.hu@gmail.com>
---
drivers/clocksource/timer-atcpit100.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/clocksource/timer-atcpit100.c b/drivers/clocksource/timer-atcpit100.c
index 0077fdb..9b2b628 100644
--- a/drivers/clocksource/timer-atcpit100.c
+++ b/drivers/clocksource/timer-atcpit100.c
@@ -29,6 +29,9 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include "timer-of.h"
+#ifdef CONFIG_NDS32
+#include <asm/vdso_timer_info.h>
+#endif
/*
* Definition of register offsets
@@ -211,6 +214,17 @@ static u64 notrace atcpit100_timer_sched_read(void)
return ~readl(timer_of_base(&to) + CH1_CNT);
}
+#ifdef CONFIG_NDS32
+static void fill_vdso_need_info(struct device_node *node)
+{
+ struct resource timer_res;
+ of_address_to_resource(node, 0, &timer_res);
+ timer_info.mapping_base = (unsigned long)timer_res.start;
+ timer_info.cycle_count_down = true;
+ timer_info.cycle_count_reg_offset = CH1_CNT;
+}
+#endif
+
static int __init atcpit100_timer_init(struct device_node *node)
{
int ret;
@@ -249,6 +263,10 @@ static int __init atcpit100_timer_init(struct device_node *node)
val = readl(base + INT_EN);
writel(val | CH0INT0EN, base + INT_EN);
+#ifdef CONFIG_NDS32
+ fill_vdso_need_info(node);
+#endif
+
return ret;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 37/39] clocksource/drivers/atcpit100: Add andestech atcpit100 timer
From: Greentime Hu @ 2018-01-02 8:25 UTC (permalink / raw)
To: greentime, linux-kernel, arnd, linux-arch, tglx, jason,
marc.zyngier, robh+dt, netdev, deanbo422, devicetree, viro,
dhowells, will.deacon, daniel.lezcano, linux-serial,
geert.uytterhoeven, linus.walleij, mark.rutland, greg, ren_guo,
rdunlap, davem, jonas, stefan.kristiansson, shorne
Cc: Rick Chen, green.hu
In-Reply-To: <cover.1514874857.git.green.hu@gmail.com>
From: Rick Chen <rickchen36@gmail.com>
ATCPIT100 is often used on the Andes architecture,
This timer provide 4 PIT channels. Each PIT channel is a
multi-function timer, can be configured as 32,16,8 bit timers
or PWM as well.
For system timer it will set channel 1 32-bit timer0 as clock
source and count downwards until underflow and restart again.
It also set channel 0 32-bit timer0 as clock event and count
downwards until condition match. It will generate an interrupt
for handling periodically.
Signed-off-by: Rick Chen <rickchen36@gmail.com>
Signed-off-by: Greentime Hu <green.hu@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/clocksource/Kconfig | 7 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-atcpit100.c | 255 +++++++++++++++++++++++++++++++++
3 files changed, 263 insertions(+)
create mode 100644 drivers/clocksource/timer-atcpit100.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index cc60620..5bdf92c 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -615,4 +615,11 @@ config CLKSRC_ST_LPC
Enable this option to use the Low Power controller timer
as clocksource.
+config TIMER_ATCPIT100
+ bool "Clocksource for AE3XX platform"
+ depends on NDS32 || COMPILE_TEST
+ depends on HAS_IOMEM
+ help
+ This option enables support for the Andestech AE3XX platform timers.
+
endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 72711f1..74efe5f 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -75,3 +75,4 @@ obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
obj-$(CONFIG_H8300_TPU) += h8300_tpu.o
obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o
obj-$(CONFIG_X86_NUMACHIP) += numachip.o
+obj-$(CONFIG_TIMER_ATCPIT100) += timer-atcpit100.o
diff --git a/drivers/clocksource/timer-atcpit100.c b/drivers/clocksource/timer-atcpit100.c
new file mode 100644
index 0000000..0077fdb
--- /dev/null
+++ b/drivers/clocksource/timer-atcpit100.c
@@ -0,0 +1,255 @@
+/*
+ * Andestech ATCPIT100 Timer Device Driver Implementation
+ *
+ * Copyright (C) 2017 Andes Technology Corporation
+ * Rick Chen, Andes Technology Corporation <rick@andestech.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ *
+ */
+
+#include <linux/irq.h>
+#include <linux/clocksource.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/ioport.h>
+#include <linux/cpufreq.h>
+#include <linux/sched.h>
+#include <linux/sched_clock.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include "timer-of.h"
+
+/*
+ * Definition of register offsets
+ */
+
+/* ID and Revision Register */
+#define ID_REV 0x0
+
+/* Configuration Register */
+#define CFG 0x10
+
+/* Interrupt Enable Register */
+#define INT_EN 0x14
+#define CH_INT_EN(c, i) ((1<<i)<<(4*c))
+#define CH0INT0EN 0x01
+
+/* Interrupt Status Register */
+#define INT_STA 0x18
+#define CH0INT0 0x01
+
+/* Channel Enable Register */
+#define CH_EN 0x1C
+#define CH0TMR0EN 0x1
+#define CH1TMR0EN 0x10
+
+/* Channel 0 , 1 Control Register */
+#define CH0_CTL (0x20)
+#define CH1_CTL (0x20 + 0x10)
+
+/* Channel clock source , bit 3 , 0:External clock , 1:APB clock */
+#define APB_CLK BIT(3)
+
+/* Channel mode , bit 0~2 */
+#define TMR_32 0x1
+#define TMR_16 0x2
+#define TMR_8 0x3
+
+/* Channel 0 , 1 Reload Register */
+#define CH0_REL (0x24)
+#define CH1_REL (0x24 + 0x10)
+
+/* Channel 0 , 1 Counter Register */
+#define CH0_CNT (0x28)
+#define CH1_CNT (0x28 + 0x10)
+
+#define TIMER_SYNC_TICKS 3
+
+static void atcpit100_ch1_tmr0_en(void __iomem *base)
+{
+ writel(~0, base + CH1_REL);
+ writel(APB_CLK|TMR_32, base + CH1_CTL);
+}
+
+static void atcpit100_ch0_tmr0_en(void __iomem *base)
+{
+ writel(APB_CLK|TMR_32, base + CH0_CTL);
+}
+
+static void atcpit100_clkevt_time_setup(void __iomem *base, unsigned long delay)
+{
+ writel(delay, base + CH0_CNT);
+ writel(delay, base + CH0_REL);
+}
+
+static void atcpit100_timer_clear_interrupt(void __iomem *base)
+{
+ u32 val;
+
+ val = readl(base + INT_STA);
+ writel(val | CH0INT0, base + INT_STA);
+}
+
+static void atcpit100_clocksource_start(void __iomem *base)
+{
+ u32 val;
+
+ val = readl(base + CH_EN);
+ writel(val | CH1TMR0EN, base + CH_EN);
+}
+
+static void atcpit100_clkevt_time_start(void __iomem *base)
+{
+ u32 val;
+
+ val = readl(base + CH_EN);
+ writel(val | CH0TMR0EN, base + CH_EN);
+}
+
+static void atcpit100_clkevt_time_stop(void __iomem *base)
+{
+ u32 val;
+
+ atcpit100_timer_clear_interrupt(base);
+ val = readl(base + CH_EN);
+ writel(val & ~CH0TMR0EN, base + CH_EN);
+}
+
+static int atcpit100_clkevt_next_event(unsigned long evt,
+ struct clock_event_device *clkevt)
+{
+ struct timer_of *to = to_timer_of(clkevt);
+
+ writel(evt, timer_of_base(to) + CH0_REL);
+
+ return 0;
+}
+
+static int atcpit100_clkevt_set_periodic(struct clock_event_device *evt)
+{
+ struct timer_of *to = to_timer_of(evt);
+
+ atcpit100_clkevt_time_setup(timer_of_base(to), timer_of_period(to));
+ atcpit100_clkevt_time_start(timer_of_base(to));
+
+ return 0;
+}
+static int atcpit100_clkevt_shutdown(struct clock_event_device *evt)
+{
+ struct timer_of *to = to_timer_of(evt);
+
+ atcpit100_clkevt_time_stop(timer_of_base(to));
+
+ return 0;
+}
+static int atcpit100_clkevt_set_oneshot(struct clock_event_device *evt)
+{
+ struct timer_of *to = to_timer_of(evt);
+ u32 val;
+
+ writel(~0x0, timer_of_base(to) + CH0_REL);
+ val = readl(timer_of_base(to) + CH_EN);
+ writel(val | CH0TMR0EN, timer_of_base(to) + CH_EN);
+
+ return 0;
+}
+
+static irqreturn_t atcpit100_timer_interrupt(int irq, void *dev_id)
+{
+ struct clock_event_device *evt = (struct clock_event_device *)dev_id;
+ struct timer_of *to = to_timer_of(evt);
+
+ atcpit100_timer_clear_interrupt(timer_of_base(to));
+
+ evt->event_handler(evt);
+
+ return IRQ_HANDLED;
+}
+
+static struct timer_of to = {
+ .flags = TIMER_OF_IRQ | TIMER_OF_CLOCK | TIMER_OF_BASE,
+
+ .clkevt = {
+ .name = "atcpit100_tick",
+ .rating = 300,
+ .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
+ .set_state_shutdown = atcpit100_clkevt_shutdown,
+ .set_state_periodic = atcpit100_clkevt_set_periodic,
+ .set_state_oneshot = atcpit100_clkevt_set_oneshot,
+ .tick_resume = atcpit100_clkevt_shutdown,
+ .set_next_event = atcpit100_clkevt_next_event,
+ .cpumask = cpu_all_mask,
+ },
+
+ .of_irq = {
+ .handler = atcpit100_timer_interrupt,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
+ },
+
+ /*
+ * FIXME: we currently only support clocking using PCLK
+ * and using EXTCLK is not supported in the driver.
+ */
+ .of_clk = {
+ .name = "PCLK",
+ }
+};
+
+static u64 notrace atcpit100_timer_sched_read(void)
+{
+ return ~readl(timer_of_base(&to) + CH1_CNT);
+}
+
+static int __init atcpit100_timer_init(struct device_node *node)
+{
+ int ret;
+ u32 val;
+ void __iomem *base;
+
+ ret = timer_of_init(node, &to);
+ if (ret)
+ return ret;
+
+ base = timer_of_base(&to);
+
+ sched_clock_register(atcpit100_timer_sched_read, 32,
+ timer_of_rate(&to));
+
+ ret = clocksource_mmio_init(base + CH1_CNT,
+ node->name, timer_of_rate(&to), 300, 32,
+ clocksource_mmio_readl_down);
+
+ if (ret) {
+ pr_err("Failed to register clocksource\n");
+ return ret;
+ }
+
+ /* clear channel 0 timer0 interrupt */
+ atcpit100_timer_clear_interrupt(base);
+
+ clockevents_config_and_register(&to.clkevt, timer_of_rate(&to),
+ TIMER_SYNC_TICKS, 0xffffffff);
+ atcpit100_ch0_tmr0_en(base);
+ atcpit100_ch1_tmr0_en(base);
+ atcpit100_clocksource_start(base);
+ atcpit100_clkevt_time_start(base);
+
+ /* Enable channel 0 timer0 interrupt */
+ val = readl(base + INT_EN);
+ writel(val | CH0INT0EN, base + INT_EN);
+
+ return ret;
+}
+
+TIMER_OF_DECLARE(atcpit100, "andestech,atcpit100", atcpit100_timer_init);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 36/39] net: faraday add nds32 support.
From: Greentime Hu @ 2018-01-02 8:25 UTC (permalink / raw)
To: greentime, linux-kernel, arnd, linux-arch, tglx, jason,
marc.zyngier, robh+dt, netdev, deanbo422, devicetree, viro,
dhowells, will.deacon, daniel.lezcano, linux-serial,
geert.uytterhoeven, linus.walleij, mark.rutland, greg, ren_guo,
rdunlap, davem, jonas, stefan.kristiansson, shorne
Cc: green.hu
In-Reply-To: <cover.1514874857.git.green.hu@gmail.com>
From: Greentime Hu <greentime@andestech.com>
This patch is used to support nds32 architecture to use these faraday
mac IP.
Signed-off-by: Greentime Hu <greentime@andestech.com>
---
drivers/net/ethernet/faraday/Kconfig | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/faraday/Kconfig b/drivers/net/ethernet/faraday/Kconfig
index 040c7f1..0fb8df6 100644
--- a/drivers/net/ethernet/faraday/Kconfig
+++ b/drivers/net/ethernet/faraday/Kconfig
@@ -5,7 +5,7 @@
config NET_VENDOR_FARADAY
bool "Faraday devices"
default y
- depends on ARM
+ depends on ARM || NDS32 || COMPILE_TEST
---help---
If you have a network (Ethernet) card belonging to this class, say Y.
@@ -18,7 +18,8 @@ if NET_VENDOR_FARADAY
config FTMAC100
tristate "Faraday FTMAC100 10/100 Ethernet support"
- depends on ARM
+ depends on ARM || NDS32 || COMPILE_TEST
+ depends on !64BIT || BROKEN
select MII
---help---
This driver supports the FTMAC100 10/100 Ethernet controller
@@ -27,7 +28,8 @@ config FTMAC100
config FTGMAC100
tristate "Faraday FTGMAC100 Gigabit Ethernet support"
- depends on ARM
+ depends on ARM || NDS32 || COMPILE_TEST
+ depends on !64BIT || BROKEN
select PHYLIB
---help---
This driver supports the FTGMAC100 Gigabit Ethernet controller
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 35/39] irqchip: Andestech Internal Vector Interrupt Controller driver
From: Greentime Hu @ 2018-01-02 8:25 UTC (permalink / raw)
To: greentime, linux-kernel, arnd, linux-arch, tglx, jason,
marc.zyngier, robh+dt, netdev, deanbo422, devicetree, viro,
dhowells, will.deacon, daniel.lezcano, linux-serial,
geert.uytterhoeven, linus.walleij, mark.rutland, greg, ren_guo,
rdunlap, davem, jonas, stefan.kristiansson, shorne
Cc: green.hu, Rick Chen
In-Reply-To: <cover.1514874857.git.green.hu@gmail.com>
From: Greentime Hu <greentime@andestech.com>
This patch adds the Andestech Internal Vector Interrupt Controller
driver. You can find the spec here. Ch4.9 of AndeStar SPA V3 Manual.
http://www.andestech.com/product.php?cls=9
Signed-off-by: Rick Chen <rick@andestech.com>
Signed-off-by: Greentime Hu <greentime@andestech.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-ativic32.c | 107 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 108 insertions(+)
create mode 100644 drivers/irqchip/irq-ativic32.c
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index b842dfd..201ca9f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -80,3 +80,4 @@ obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o irq-aspeed-i2c-ic.o
obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
obj-$(CONFIG_QCOM_IRQ_COMBINER) += qcom-irq-combiner.o
obj-$(CONFIG_IRQ_UNIPHIER_AIDET) += irq-uniphier-aidet.o
+obj-$(CONFIG_NDS32) += irq-ativic32.o
diff --git a/drivers/irqchip/irq-ativic32.c b/drivers/irqchip/irq-ativic32.c
new file mode 100644
index 0000000..f69a858
--- /dev/null
+++ b/drivers/irqchip/irq-ativic32.c
@@ -0,0 +1,107 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2005-2017 Andes Technology Corporation
+
+#include <linux/irq.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
+#include <linux/interrupt.h>
+#include <linux/irqdomain.h>
+#include <linux/irqchip.h>
+#include <nds32_intrinsic.h>
+
+static void ativic32_ack_irq(struct irq_data *data)
+{
+ __nds32__mtsr_dsb(BIT(data->hwirq), NDS32_SR_INT_PEND2);
+}
+
+static void ativic32_mask_irq(struct irq_data *data)
+{
+ unsigned long int_mask2 = __nds32__mfsr(NDS32_SR_INT_MASK2);
+ __nds32__mtsr_dsb(int_mask2 & (~(BIT(data->hwirq))), NDS32_SR_INT_MASK2);
+}
+
+static void ativic32_unmask_irq(struct irq_data *data)
+{
+ unsigned long int_mask2 = __nds32__mfsr(NDS32_SR_INT_MASK2);
+ __nds32__mtsr_dsb(int_mask2 | (BIT(data->hwirq)), NDS32_SR_INT_MASK2);
+}
+
+static struct irq_chip ativic32_chip = {
+ .name = "ativic32",
+ .irq_ack = ativic32_ack_irq,
+ .irq_mask = ativic32_mask_irq,
+ .irq_unmask = ativic32_unmask_irq,
+};
+
+static unsigned int __initdata nivic_map[6] = { 6, 2, 10, 16, 24, 32 };
+
+static struct irq_domain *root_domain;
+static int ativic32_irq_domain_map(struct irq_domain *id, unsigned int virq,
+ irq_hw_number_t hw)
+{
+
+ unsigned long int_trigger_type;
+ u32 type;
+ struct irq_data *irq_data;
+ int_trigger_type = __nds32__mfsr(NDS32_SR_INT_TRIGGER);
+ irq_data = irq_get_irq_data(virq);
+ if (!irq_data)
+ return -EINVAL;
+
+ if (int_trigger_type & (BIT(hw))) {
+ irq_set_chip_and_handler(virq, &ativic32_chip, handle_edge_irq);
+ type = IRQ_TYPE_EDGE_RISING;
+ } else {
+ irq_set_chip_and_handler(virq, &ativic32_chip, handle_level_irq);
+ type = IRQ_TYPE_LEVEL_HIGH;
+ }
+
+ irqd_set_trigger_type(irq_data, type);
+ return 0;
+}
+
+static struct irq_domain_ops ativic32_ops = {
+ .map = ativic32_irq_domain_map,
+ .xlate = irq_domain_xlate_onecell
+};
+
+static irq_hw_number_t get_intr_src(void)
+{
+ return ((__nds32__mfsr(NDS32_SR_ITYPE) & ITYPE_mskVECTOR) >> ITYPE_offVECTOR)
+ - NDS32_VECTOR_offINTERRUPT;
+}
+
+asmlinkage void asm_do_IRQ(struct pt_regs *regs)
+{
+ irq_hw_number_t hwirq = get_intr_src();
+ handle_domain_irq(root_domain, hwirq, regs);
+}
+
+int __init ativic32_init_irq(struct device_node *node, struct device_node *parent)
+{
+ unsigned long int_vec_base, nivic, nr_ints;
+
+ if (WARN(parent, "non-root ativic32 are not supported"))
+ return -EINVAL;
+
+ int_vec_base = __nds32__mfsr(NDS32_SR_IVB);
+
+ if (((int_vec_base & IVB_mskIVIC_VER) >> IVB_offIVIC_VER) == 0)
+ panic("Unable to use atcivic32 for this cpu.\n");
+
+ nivic = (int_vec_base & IVB_mskNIVIC) >> IVB_offNIVIC;
+ if (nivic >= ARRAY_SIZE(nivic_map))
+ panic("The number of input for ativic32 is not supported.\n");
+
+ nr_ints = nivic_map[nivic];
+
+ root_domain = irq_domain_add_linear(node, nr_ints,
+ &ativic32_ops, NULL);
+
+ if (!root_domain)
+ panic("%s: unable to create IRQ domain\n", node->full_name);
+
+ return 0;
+}
+IRQCHIP_DECLARE(ativic32, "andestech,ativic32", ativic32_init_irq);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 34/39] dt-bindings: interrupt-controller: Andestech Internal Vector Interrupt Controller
From: Greentime Hu @ 2018-01-02 8:25 UTC (permalink / raw)
To: greentime, linux-kernel, arnd, linux-arch, tglx, jason,
marc.zyngier, robh+dt, netdev, deanbo422, devicetree, viro,
dhowells, will.deacon, daniel.lezcano, linux-serial,
geert.uytterhoeven, linus.walleij, mark.rutland, greg, ren_guo,
rdunlap, davem, jonas, stefan.kristiansson, shorne
Cc: green.hu, Rick Chen
In-Reply-To: <cover.1514874857.git.green.hu@gmail.com>
From: Greentime Hu <greentime@andestech.com>
This patch adds an irqchip driver document for the Andestech Internal Vector
Interrupt Controller.
Signed-off-by: Rick Chen <rick@andestech.com>
Signed-off-by: Greentime Hu <greentime@andestech.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../interrupt-controller/andestech,ativic32.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt
diff --git a/Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt b/Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt
new file mode 100644
index 0000000..f4b4193
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt
@@ -0,0 +1,19 @@
+* Andestech Internal Vector Interrupt Controller
+
+The Internal Vector Interrupt Controller (IVIC) is a basic interrupt controller
+suitable for a simpler SoC platform not requiring a more sophisticated and
+bigger External Vector Interrupt Controller.
+
+
+Main node required properties:
+
+- compatible : should at least contain "andestech,ativic32".
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells: 1 cells and refer to interrupt-controller/interrupts
+
+Examples:
+ intc: interrupt-controller {
+ compatible = "andestech,ativic32";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ };
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 33/39] dt-bindings: nds32 SoC Bindings
From: Greentime Hu @ 2018-01-02 8:25 UTC (permalink / raw)
To: greentime, linux-kernel, arnd, linux-arch, tglx, jason,
marc.zyngier, robh+dt, netdev, deanbo422, devicetree, viro,
dhowells, will.deacon, daniel.lezcano, linux-serial,
geert.uytterhoeven, linus.walleij, mark.rutland, greg, ren_guo,
rdunlap, davem, jonas, stefan.kristiansson, shorne
Cc: green.hu
In-Reply-To: <cover.1514874857.git.green.hu@gmail.com>
From: Greentime Hu <greentime@andestech.com>
This patch adds nds32 SoC(AE3XX and AG101P) binding documents.
Signed-off-by: Greentime Hu <greentime@andestech.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/nds32/andestech-boards | 40 ++++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nds32/andestech-boards
diff --git a/Documentation/devicetree/bindings/nds32/andestech-boards b/Documentation/devicetree/bindings/nds32/andestech-boards
new file mode 100644
index 0000000..f5d7569
--- /dev/null
+++ b/Documentation/devicetree/bindings/nds32/andestech-boards
@@ -0,0 +1,40 @@
+Andestech(nds32) AE3XX Platform
+-----------------------------------------------------------------------------
+The AE3XX prototype demonstrates the AE3XX example platform on the FPGA. It
+is composed of one Andestech(nds32) processor and AE3XX.
+
+Required properties (in root node):
+- compatible = "andestech,ae3xx";
+
+Example:
+/dts-v1/;
+/ {
+ compatible = "andestech,ae3xx";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&intc>;
+};
+
+Andestech(nds32) AG101P Platform
+-----------------------------------------------------------------------------
+AG101P is a generic SoC Platform IP that works with any of Andestech(nds32)
+processors to provide a cost-effective and high performance solution for
+majority of embedded systems in variety of application domains. Users may
+simply attach their IP on one of the system buses together with certain glue
+logics to complete a SoC solution for a specific application. With
+comprehensive simulation and design environments, users may evaluate the
+system performance of their applications and track bugs of their designs
+efficiently. The optional hardware development platform further provides real
+system environment for early prototyping and software/hardware co-development.
+
+Required properties (in root node):
+ compatible = "andestech,ag101p";
+
+Example:
+/dts-v1/;
+/ {
+ compatible = "andestech,ag101p";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&intc>;
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 32/39] dt-bindings: nds32 L2 cache controller Bindings
From: Greentime Hu @ 2018-01-02 8:25 UTC (permalink / raw)
To: greentime, linux-kernel, arnd, linux-arch, tglx, jason,
marc.zyngier, robh+dt, netdev, deanbo422, devicetree, viro,
dhowells, will.deacon, daniel.lezcano, linux-serial,
geert.uytterhoeven, linus.walleij, mark.rutland, greg, ren_guo,
rdunlap, davem, jonas, stefan.kristiansson, shorne
Cc: green.hu
In-Reply-To: <cover.1514874857.git.green.hu@gmail.com>
From: Greentime Hu <greentime@andestech.com>
This patch adds nds32 L2 cache controller binding documents.
Signed-off-by: Greentime Hu <greentime@andestech.com>
---
Documentation/devicetree/bindings/nds32/atl2c.txt | 29 +++++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nds32/atl2c.txt
diff --git a/Documentation/devicetree/bindings/nds32/atl2c.txt b/Documentation/devicetree/bindings/nds32/atl2c.txt
new file mode 100644
index 0000000..db9f7ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/nds32/atl2c.txt
@@ -0,0 +1,29 @@
+* Andestech L2 cache Controller
+
+The level-2 cache controller plays an important role in reducing memory latency
+for high performance systems, such as thoese designs with AndesCore processors.
+Level-2 cache controller in general enhances overall system performance
+signigicantly and the system power consumption might be reduced as well by
+reducing DRAM accesses.
+
+This binding specifies what properties must be available in the device tree
+representation of an Andestech L2 cache controller.
+
+Required properties:
+ - compatible:
+ Usage: required
+ Value type: <string>
+ Definition: "andestech,atl2c"
+ - reg : Physical base address and size of cache controller's memory mapped
+ - cache-unified : Specifies the cache is a unified cache.
+ - cache-level : Should be set to 2 for a level 2 cache.
+
+* Example
+
+ L2: l2-cache@e0500000 {
+ compatible = "andestech,atl2c";
+ reg = <0xe0500000 0x1000>;
+ cache-unified;
+ cache-level = <2>;
+ };
+
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 31/39] dt-bindings: nds32 CPU Bindings
From: Greentime Hu @ 2018-01-02 8:25 UTC (permalink / raw)
To: greentime-MUIXKm3Oiri1Z/+hSey0Gg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
linux-arch-u79uwXL29TY76Z2rM5mHXA, tglx-hfZtesqFncYOwBW4kG4KsQ,
jason-NLaQJdtUoK4Be96aLqz0jA, marc.zyngier-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
deanbo422-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
dhowells-H+wXaHxf7aLQT0dZR+AlfA, will.deacon-5wv7dgnIgG8,
daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
geert.uytterhoeven-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
greg-U8xfFu+wG4EAvxtiuMwx3w, ren_guo-Y+KPrCd2zL4AvxtiuMwx3w,
rdunlap-wEGCiKHe2LqWVfeAwA7xHQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jonas-A9uVI2HLR7kOP4wsBPIw7w,
stefan.kristiansson-MbMCFXIvDHJFcC0YU169RA,
shorne-Re5JQEeQqe8AvxtiuMwx3w
Cc: green.hu-Re5JQEeQqe8AvxtiuMwx3w, Vincent Chen, Rick Chen, Zong Li
In-Reply-To: <cover.1514874857.git.green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
This patch adds nds32 CPU binding documents.
Signed-off-by: Vincent Chen <vincentc-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
Signed-off-by: Rick Chen <rick-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
Signed-off-by: Zong Li <zong-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
Signed-off-by: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/nds32/cpus.txt | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nds32/cpus.txt
diff --git a/Documentation/devicetree/bindings/nds32/cpus.txt b/Documentation/devicetree/bindings/nds32/cpus.txt
new file mode 100644
index 0000000..9a52937
--- /dev/null
+++ b/Documentation/devicetree/bindings/nds32/cpus.txt
@@ -0,0 +1,37 @@
+* Andestech Processor Binding
+
+This binding specifies what properties must be available in the device tree
+representation of a Andestech Processor Core, which is the root node in the
+tree.
+
+Required properties:
+
+ - compatible:
+ Usage: required
+ Value type: <string>
+ Definition: should be one of:
+ "andestech,n13"
+ "andestech,n15"
+ "andestech,d15"
+ "andestech,n10"
+ "andestech,d10"
+ "andestech,nds32v3"
+ - device_type
+ Usage: required
+ Value type: <string>
+ Definition: must be "cpu"
+ - reg: Contains CPU index.
+ - clock-frequency: Contains the clock frequency for CPU, in Hz.
+
+* Examples
+
+/ {
+ cpus {
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "andestech,n13", "andestech,nds32v3";
+ reg = <0x0>;
+ clock-frequency = <60000000>
+ };
+ };
+};
--
1.7.9.5
--
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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox