* Re: [PATCH v8 08/24] ASoC: qdsp6: q6core: Add q6core driver
From: Banajit Goswami @ 2018-05-15 7:44 UTC (permalink / raw)
To: Srinivas Kandagatla, andy.gross, broonie, linux-arm-msm,
alsa-devel, robh+dt
Cc: mark.rutland, devicetree, rohkumar, gregkh, plai, tiwai,
lgirdwood, david.brown, linux-arm-kernel, spatakok, linux-kernel
In-Reply-To: <20180509125635.5653-9-srinivas.kandagatla@linaro.org>
On 5/9/2018 5:56 AM, Srinivas Kandagatla wrote:
> This patch adds support to core apr service, which is used to query
> status of other static and dynamic services on the dsp.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Reviewed-and-tested-by: Rohit kumar <rohitkr@codeaurora.org>
> ---
> sound/soc/qcom/Kconfig | 4 +
> sound/soc/qcom/qdsp6/Makefile | 1 +
> sound/soc/qcom/qdsp6/q6core.c | 380 ++++++++++++++++++++++++++++++++++++++++++
> sound/soc/qcom/qdsp6/q6core.h | 15 ++
> 4 files changed, 400 insertions(+)
> create mode 100644 sound/soc/qcom/qdsp6/q6core.c
> create mode 100644 sound/soc/qcom/qdsp6/q6core.h
Acked-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 0/1] net: phy: micrel: add 125MHz reference clock workaround
From: Marco Felsch @ 2018-05-15 7:45 UTC (permalink / raw)
To: robh+dt, mark.rutland, andrew, f.fainelli
Cc: netdev, devicetree, kernel, niebelm
This patch adds the workaround for the errata#2. The KSZ9031 phy
125MHz reference clock jitter is to high if the phy is configured as
slave. This will cause errors if a application uses the clock as
MAC reference clock. The workaround is to configure the phy as master.
v2:
- add more code and dt-binding comments
- delete unnecessary local variables
- add error handling
v1:
- initial commit
Markus Niebel (1):
net: phy: micrel: add 125MHz reference clock workaround
.../bindings/net/micrel-ksz90x1.txt | 7 ++++
drivers/net/phy/micrel.c | 32 +++++++++++++++++++
2 files changed, 39 insertions(+)
--
2.17.0
^ permalink raw reply
* [PATCH v2 1/1] net: phy: micrel: add 125MHz reference clock workaround
From: Marco Felsch @ 2018-05-15 7:45 UTC (permalink / raw)
To: robh+dt, mark.rutland, andrew, f.fainelli
Cc: netdev, devicetree, kernel, niebelm
From: Markus Niebel <Markus.Niebel@tqs.de>
The micrel KSZ9031 phy has a optional clock pin (CLK125_NDO) which can be
used as reference clock for the MAC unit. The clock signal must meet the
RGMII requirements to ensure the correct data transmission between the
MAC and the PHY. The KSZ9031 phy does not fulfill the duty cycle
requirement if the phy is configured as slave. For a complete
describtion look at the errata sheets: DS80000691D or DS80000692D.
The errata sheet recommends to force the phy into master mode whenever
there is a 1000Base-T link-up as work around. Only set the
"micrel,force-master" property if you use the phy reference clock provided
by CLK125_NDO pin as MAC reference clock in your application.
Attenation, this workaround is only usable if the link partner can
be configured to slave mode for 1000Base-T.
Signed-off-by: Markus Niebel <Markus.Niebel@tqs.de>
[m.felsch@pengutronix.de: fix dt-binding documentation]
[m.felsch@pengutronix.de: use already existing result var for read/write]
[m.felsch@pengutronix.de: add error handling]
[m.felsch@pengutronix.de: add more comments]
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
.../bindings/net/micrel-ksz90x1.txt | 7 +++++
drivers/net/phy/micrel.c | 31 +++++++++++++++++++
2 files changed, 38 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
index 42a248301615..e22d8cfea687 100644
--- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
@@ -57,6 +57,13 @@ KSZ9031:
- txd2-skew-ps : Skew control of TX data 2 pad
- txd3-skew-ps : Skew control of TX data 3 pad
+ - micrel,force-master:
+ Boolean, force phy to master mode. Only set this option if the phy
+ reference clock provided at CLK125_NDO pin is used as MAC reference
+ clock because the clock jitter in slave mode is to high (errata#2).
+ Attention: The link partner must be configurable as slave otherwise
+ no link will be established.
+
Examples:
mdio {
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index f41b224a9cdb..ab195f0916d6 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -573,9 +573,40 @@ static int ksz9031_config_init(struct phy_device *phydev)
ksz9031_of_load_skew_values(phydev, of_node,
MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
tx_data_skews, 4);
+
+ /* Silicon Errata Sheet (DS80000691D or DS80000692D):
+ * When the device links in the 1000BASE-T slave mode only,
+ * the optional 125MHz reference output clock (CLK125_NDO)
+ * has wide duty cycle variation.
+ *
+ * The optional CLK125_NDO clock does not meet the RGMII
+ * 45/55 percent (min/max) duty cycle requirement and therefore
+ * cannot be used directly by the MAC side for clocking
+ * applications that have setup/hold time requirements on
+ * rising and falling clock edges.
+ *
+ * Workaround:
+ * Force the phy to be the master to receive a stable clock
+ * which meets the duty cycle requirement.
+ */
+ if (of_property_read_bool(of_node, "micrel,force-master")) {
+ result = phy_read(phydev, MII_CTRL1000);
+ if (result < 0)
+ goto err_force_master;
+
+ /* enable master mode, config & prefer master */
+ result |= CTL1000_ENABLE_MASTER | CTL1000_AS_MASTER;
+ result = phy_write(phydev, MII_CTRL1000, result);
+ if (result < 0)
+ goto err_force_master;
+ }
}
return ksz9031_center_flp_timing(phydev);
+
+err_force_master:
+ phydev_err(phydev, "failed to force the phy to master mode\n");
+ return result;
}
#define KSZ8873MLL_GLOBAL_CONTROL_4 0x06
--
2.17.0
^ permalink raw reply related
* [PATCH v2 1/1] net: phy: micrel: add 125MHz reference clock workaround
From: Marco Felsch @ 2018-05-15 7:47 UTC (permalink / raw)
To: robh+dt, mark.rutland, andrew, f.fainelli
Cc: netdev, devicetree, kernel, niebelm
From: Markus Niebel <Markus.Niebel@tqs.de>
The micrel KSZ9031 phy has a optional clock pin (CLK125_NDO) which can be
used as reference clock for the MAC unit. The clock signal must meet the
RGMII requirements to ensure the correct data transmission between the
MAC and the PHY. The KSZ9031 phy does not fulfill the duty cycle
requirement if the phy is configured as slave. For a complete
describtion look at the errata sheets: DS80000691D or DS80000692D.
The errata sheet recommends to force the phy into master mode whenever
there is a 1000Base-T link-up as work around. Only set the
"micrel,force-master" property if you use the phy reference clock provided
by CLK125_NDO pin as MAC reference clock in your application.
Attenation, this workaround is only usable if the link partner can
be configured to slave mode for 1000Base-T.
Signed-off-by: Markus Niebel <Markus.Niebel@tqs.de>
[m.felsch@pengutronix.de: fix dt-binding documentation]
[m.felsch@pengutronix.de: use already existing result var for read/write]
[m.felsch@pengutronix.de: add error handling]
[m.felsch@pengutronix.de: add more comments]
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
.../bindings/net/micrel-ksz90x1.txt | 7 +++++
drivers/net/phy/micrel.c | 31 +++++++++++++++++++
2 files changed, 38 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
index 42a248301615..e22d8cfea687 100644
--- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
@@ -57,6 +57,13 @@ KSZ9031:
- txd2-skew-ps : Skew control of TX data 2 pad
- txd3-skew-ps : Skew control of TX data 3 pad
+ - micrel,force-master:
+ Boolean, force phy to master mode. Only set this option if the phy
+ reference clock provided at CLK125_NDO pin is used as MAC reference
+ clock because the clock jitter in slave mode is to high (errata#2).
+ Attention: The link partner must be configurable as slave otherwise
+ no link will be established.
+
Examples:
mdio {
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index f41b224a9cdb..ab195f0916d6 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -573,9 +573,40 @@ static int ksz9031_config_init(struct phy_device *phydev)
ksz9031_of_load_skew_values(phydev, of_node,
MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
tx_data_skews, 4);
+
+ /* Silicon Errata Sheet (DS80000691D or DS80000692D):
+ * When the device links in the 1000BASE-T slave mode only,
+ * the optional 125MHz reference output clock (CLK125_NDO)
+ * has wide duty cycle variation.
+ *
+ * The optional CLK125_NDO clock does not meet the RGMII
+ * 45/55 percent (min/max) duty cycle requirement and therefore
+ * cannot be used directly by the MAC side for clocking
+ * applications that have setup/hold time requirements on
+ * rising and falling clock edges.
+ *
+ * Workaround:
+ * Force the phy to be the master to receive a stable clock
+ * which meets the duty cycle requirement.
+ */
+ if (of_property_read_bool(of_node, "micrel,force-master")) {
+ result = phy_read(phydev, MII_CTRL1000);
+ if (result < 0)
+ goto err_force_master;
+
+ /* enable master mode, config & prefer master */
+ result |= CTL1000_ENABLE_MASTER | CTL1000_AS_MASTER;
+ result = phy_write(phydev, MII_CTRL1000, result);
+ if (result < 0)
+ goto err_force_master;
+ }
}
return ksz9031_center_flp_timing(phydev);
+
+err_force_master:
+ phydev_err(phydev, "failed to force the phy to master mode\n");
+ return result;
}
#define KSZ8873MLL_GLOBAL_CONTROL_4 0x06
--
2.17.0
^ permalink raw reply related
* Re: [PATCH/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API
From: Simon Horman @ 2018-05-15 7:54 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: gregkh, robh+dt, mark.rutland, heikki.krogerus, hdegoede,
andy.shevchenko, linux-usb, linux-renesas-soc, devicetree
In-Reply-To: <1526289360-3997-4-git-send-email-yoshihiro.shimoda.uh@renesas.com>
On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:
> This patch uses usb role switch API if the register suceeeded.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> drivers/usb/gadget/udc/renesas_usb3.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c b/drivers/usb/gadget/udc/renesas_usb3.c
> index c878449..bfb5803 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -657,7 +657,11 @@ static void _usb3_set_mode(struct renesas_usb3 *usb3, bool host)
>
> static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> {
> - _usb3_set_mode(usb3, host);
> + if (usb3->role_sw)
> + usb_role_switch_set_role(usb3->role_sw, host ?
> + USB_ROLE_HOST : USB_ROLE_DEVICE);
> + else
> + _usb3_set_mode(usb3, host);
> }
>
> static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, bool host, bool a_dev)
> {
> unsigned long flags;
>
> - spin_lock_irqsave(&usb3->lock, flags);
> usb3_set_mode(usb3, host);
> + spin_lock_irqsave(&usb3->lock, flags);
Hi Shimoda-san,
could you clarify why moving this lock is safe?
> usb3_vbus_out(usb3, a_dev);
> /* for A-Peripheral or forced B-device mode */
> if ((!host && a_dev) ||
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v8 23/24] ASoC: qcom: apq8096: Add db820c machine driver
From: Banajit Goswami @ 2018-05-15 8:00 UTC (permalink / raw)
To: Srinivas Kandagatla, andy.gross, broonie, linux-arm-msm,
alsa-devel, robh+dt
Cc: mark.rutland, devicetree, rohkumar, gregkh, plai, tiwai,
lgirdwood, david.brown, linux-arm-kernel, spatakok, linux-kernel
In-Reply-To: <20180509125635.5653-24-srinivas.kandagatla@linaro.org>
On 5/9/2018 5:56 AM, Srinivas Kandagatla wrote:
> This patch adds support to DB820c machine driver.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> sound/soc/qcom/Kconfig | 9 ++
> sound/soc/qcom/Makefile | 2 +
> sound/soc/qcom/apq8096.c | 255 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 266 insertions(+)
> create mode 100644 sound/soc/qcom/apq8096.c
>
Acked-by: Banajit Goswami <bgoswami@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* RE: [PATCH/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API
From: Yoshihiro Shimoda @ 2018-05-15 8:02 UTC (permalink / raw)
To: Simon Horman
Cc: gregkh@linuxfoundation.org, robh+dt@kernel.org,
mark.rutland@arm.com, heikki.krogerus@linux.intel.com,
hdegoede@redhat.com, andy.shevchenko@gmail.com,
linux-usb@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <20180515075428.6fvkwv2tz6v7cnyj@verge.net.au>
Hi Simon-san,
Thank you for your review!
> From: Simon Horman, Sent: Tuesday, May 15, 2018 4:54 PM
> On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:
<snip>
> > static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> > {
> > - _usb3_set_mode(usb3, host);
> > + if (usb3->role_sw)
> > + usb_role_switch_set_role(usb3->role_sw, host ?
> > + USB_ROLE_HOST : USB_ROLE_DEVICE);
> > + else
> > + _usb3_set_mode(usb3, host);
> > }
> >
> > static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> > @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, bool host, bool a_dev)
> > {
> > unsigned long flags;
> >
> > - spin_lock_irqsave(&usb3->lock, flags);
> > usb3_set_mode(usb3, host);
> > + spin_lock_irqsave(&usb3->lock, flags);
>
> Hi Shimoda-san,
>
> could you clarify why moving this lock is safe?
The usb3_set_mode() is possible to call usb_role_switch_set_role() API
and usb_role_switch_set_role() calls mutex_lock().
So, this moving this lock (especially avoiding irqsave) needs.
Best regards,
Yoshihiro Shimoda
> > usb3_vbus_out(usb3, a_dev);
> > /* for A-Peripheral or forced B-device mode */
> > if ((!host && a_dev) ||
> > --
> > 1.9.1
> >
^ permalink raw reply
* Re: [PATCH/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API
From: Simon Horman @ 2018-05-15 8:03 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: gregkh@linuxfoundation.org, robh+dt@kernel.org,
mark.rutland@arm.com, heikki.krogerus@linux.intel.com,
hdegoede@redhat.com, andy.shevchenko@gmail.com,
linux-usb@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <OSBPR01MB2293EFC5FD518ECDD612ABDFD8930@OSBPR01MB2293.jpnprd01.prod.outlook.com>
On Tue, May 15, 2018 at 08:02:00AM +0000, Yoshihiro Shimoda wrote:
> Hi Simon-san,
>
> Thank you for your review!
>
> > From: Simon Horman, Sent: Tuesday, May 15, 2018 4:54 PM
> > On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:
> <snip>
> > > static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> > > {
> > > - _usb3_set_mode(usb3, host);
> > > + if (usb3->role_sw)
> > > + usb_role_switch_set_role(usb3->role_sw, host ?
> > > + USB_ROLE_HOST : USB_ROLE_DEVICE);
> > > + else
> > > + _usb3_set_mode(usb3, host);
> > > }
> > >
> > > static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> > > @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, bool host, bool a_dev)
> > > {
> > > unsigned long flags;
> > >
> > > - spin_lock_irqsave(&usb3->lock, flags);
> > > usb3_set_mode(usb3, host);
> > > + spin_lock_irqsave(&usb3->lock, flags);
> >
> > Hi Shimoda-san,
> >
> > could you clarify why moving this lock is safe?
>
> The usb3_set_mode() is possible to call usb_role_switch_set_role() API
> and usb_role_switch_set_role() calls mutex_lock().
> So, this moving this lock (especially avoiding irqsave) needs.
Thanks, that make sense.
But usb3_set_mode() may also call _usb3_set_mode().
It is safe to call _usb3_set_mode() without holding the lock?
> Best regards,
> Yoshihiro Shimoda
>
> > > usb3_vbus_out(usb3, a_dev);
> > > /* for A-Peripheral or forced B-device mode */
> > > if ((!host && a_dev) ||
> > > --
> > > 1.9.1
> > >
>
^ permalink raw reply
* Re: [PATCH v2 0/1] net: phy: micrel: add 125MHz reference clock workaround
From: Marco Felsch @ 2018-05-15 8:06 UTC (permalink / raw)
To: robh+dt, mark.rutland, andrew, f.fainelli
Cc: netdev, niebelm, kernel, devicetree
In-Reply-To: <20180515074527.22546-1-m.felsch@pengutronix.de>
I forgot to set the thread option. I will resend with thread option
enabled.
On 05/15/2018 09:45 AM, Marco Felsch wrote:
> This patch adds the workaround for the errata#2. The KSZ9031 phy
> 125MHz reference clock jitter is to high if the phy is configured as
> slave. This will cause errors if a application uses the clock as
> MAC reference clock. The workaround is to configure the phy as master.
>
> v2:
> - add more code and dt-binding comments
> - delete unnecessary local variables
> - add error handling
>
> v1:
> - initial commit
>
> Markus Niebel (1):
> net: phy: micrel: add 125MHz reference clock workaround
>
> .../bindings/net/micrel-ksz90x1.txt | 7 ++++
> drivers/net/phy/micrel.c | 32 +++++++++++++++++++
> 2 files changed, 39 insertions(+)
>
>
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: imx51-babbage: Fix USB PHY duplicate unit-address
From: Shawn Guo @ 2018-05-15 8:06 UTC (permalink / raw)
To: Fabio Estevam, robh+dt; +Cc: Fabio Estevam, devicetree, linux-arm-kernel
In-Reply-To: <1526322576-5838-1-git-send-email-festevam@gmail.com>
On Mon, May 14, 2018 at 03:29:35PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Currently the following DTC warning is seen with W=1:
>
> arch/arm/boot/dts/imx51-babbage.dtb: Warning (unique_unit_address): /usbphy/usbphy@0: duplicate unit-address (also used in node /usbphy/usbh1phy@0)
>
> Fix it by moving the USB PHY node outside of simple-bus and drop the
> unneeded unit-address.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> arch/arm/boot/dts/imx51-babbage.dts | 21 +++++++--------------
> 1 file changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
> index b8ca73d..de46906 100644
> --- a/arch/arm/boot/dts/imx51-babbage.dts
> +++ b/arch/arm/boot/dts/imx51-babbage.dts
> @@ -170,20 +170,13 @@
> mux-ext-port = <3>;
> };
>
> - usbphy {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - compatible = "simple-bus";
> -
> - usbh1phy: usbh1phy@0 {
> - compatible = "usb-nop-xceiv";
> - reg = <0>;
> - clocks = <&clk_usb>;
> - clock-names = "main_clk";
> - reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
> - vcc-supply = <&vusb_reg>;
> - #phy-cells = <0>;
> - };
> + usbh1phy: usbphy1 {
> + compatible = "usb-nop-xceiv";
> + clocks = <&clk_usb>;
> + clock-names = "main_clk";
> + reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
> + vcc-supply = <&vusb_reg>;
> + #phy-cells = <0>;
This should be considered as a whole together with usbphy in imx51.dtsi.
Also, I would like to get some input from DT folks on how we should name
the node uniquely. @Rob.
Shawn
> };
> };
>
> --
> 2.7.4
>
^ permalink raw reply
* [RESEND PATCH v2 0/1] net: phy: micrel: add 125MHz reference clock workaround
From: Marco Felsch @ 2018-05-15 8:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, andrew, f.fainelli
Cc: netdev, devicetree, kernel, niebelm
This patch adds the workaround for the errata#2. The KSZ9031 phy
125MHz reference clock jitter is to high if the phy is configured as
slave. This will cause errors if a application uses the clock as
MAC reference clock. The workaround is to configure the phy as master.
v2:
- add more code and dt-binding comments
- delete unnecessary local variables
- add error handling
v1:
- initial commit
Markus Niebel (1):
net: phy: micrel: add 125MHz reference clock workaround
.../bindings/net/micrel-ksz90x1.txt | 7 ++++
drivers/net/phy/micrel.c | 32 +++++++++++++++++++
2 files changed, 39 insertions(+)
--
2.17.0
^ permalink raw reply
* [RESEND PATCH v2 1/1] net: phy: micrel: add 125MHz reference clock workaround
From: Marco Felsch @ 2018-05-15 8:18 UTC (permalink / raw)
To: robh+dt, mark.rutland, andrew, f.fainelli
Cc: netdev, devicetree, kernel, niebelm
In-Reply-To: <20180515081856.23322-1-m.felsch@pengutronix.de>
From: Markus Niebel <Markus.Niebel@tqs.de>
The micrel KSZ9031 phy has a optional clock pin (CLK125_NDO) which can be
used as reference clock for the MAC unit. The clock signal must meet the
RGMII requirements to ensure the correct data transmission between the
MAC and the PHY. The KSZ9031 phy does not fulfill the duty cycle
requirement if the phy is configured as slave. For a complete
describtion look at the errata sheets: DS80000691D or DS80000692D.
The errata sheet recommends to force the phy into master mode whenever
there is a 1000Base-T link-up as work around. Only set the
"micrel,force-master" property if you use the phy reference clock provided
by CLK125_NDO pin as MAC reference clock in your application.
Attenation, this workaround is only usable if the link partner can
be configured to slave mode for 1000Base-T.
Signed-off-by: Markus Niebel <Markus.Niebel@tqs.de>
[m.felsch@pengutronix.de: fix dt-binding documentation]
[m.felsch@pengutronix.de: use already existing result var for read/write]
[m.felsch@pengutronix.de: add error handling]
[m.felsch@pengutronix.de: add more comments]
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
.../bindings/net/micrel-ksz90x1.txt | 7 +++++
drivers/net/phy/micrel.c | 31 +++++++++++++++++++
2 files changed, 38 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
index 42a248301615..e22d8cfea687 100644
--- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
@@ -57,6 +57,13 @@ KSZ9031:
- txd2-skew-ps : Skew control of TX data 2 pad
- txd3-skew-ps : Skew control of TX data 3 pad
+ - micrel,force-master:
+ Boolean, force phy to master mode. Only set this option if the phy
+ reference clock provided at CLK125_NDO pin is used as MAC reference
+ clock because the clock jitter in slave mode is to high (errata#2).
+ Attention: The link partner must be configurable as slave otherwise
+ no link will be established.
+
Examples:
mdio {
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index f41b224a9cdb..ab195f0916d6 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -573,9 +573,40 @@ static int ksz9031_config_init(struct phy_device *phydev)
ksz9031_of_load_skew_values(phydev, of_node,
MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
tx_data_skews, 4);
+
+ /* Silicon Errata Sheet (DS80000691D or DS80000692D):
+ * When the device links in the 1000BASE-T slave mode only,
+ * the optional 125MHz reference output clock (CLK125_NDO)
+ * has wide duty cycle variation.
+ *
+ * The optional CLK125_NDO clock does not meet the RGMII
+ * 45/55 percent (min/max) duty cycle requirement and therefore
+ * cannot be used directly by the MAC side for clocking
+ * applications that have setup/hold time requirements on
+ * rising and falling clock edges.
+ *
+ * Workaround:
+ * Force the phy to be the master to receive a stable clock
+ * which meets the duty cycle requirement.
+ */
+ if (of_property_read_bool(of_node, "micrel,force-master")) {
+ result = phy_read(phydev, MII_CTRL1000);
+ if (result < 0)
+ goto err_force_master;
+
+ /* enable master mode, config & prefer master */
+ result |= CTL1000_ENABLE_MASTER | CTL1000_AS_MASTER;
+ result = phy_write(phydev, MII_CTRL1000, result);
+ if (result < 0)
+ goto err_force_master;
+ }
}
return ksz9031_center_flp_timing(phydev);
+
+err_force_master:
+ phydev_err(phydev, "failed to force the phy to master mode\n");
+ return result;
}
#define KSZ8873MLL_GLOBAL_CONTROL_4 0x06
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v2 5/5] hisi: Consolidate the Kconfigs for the CLOCK_STUB and the MAILBOX
From: Wei Xu @ 2018-05-15 8:23 UTC (permalink / raw)
To: Leo Yan, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Jassi Brar, Arnd Bergmann, Olof Johansson,
Daniel Lezcano, linux-arm-kernel, devicetree, linux-kernel,
linux-clk
In-Reply-To: <1526352795-6991-6-git-send-email-leo.yan@linaro.org>
Hi Leo, Daniel,
On 2018/5/15 3:53, Leo Yan wrote:
> From: Daniel Lezcano <daniel.lezcano@linaro.org>
>
> The current defconfig is inconsistent as it selects the mailbox and
> the clock for the hi6220 and the hi3660 without having their Kconfigs
> making sure the dependencies are correct. It ends up when selecting
> different versions for the kernel (for example when git bisecting)
> those options disappear and they don't get back, leading to unexpected
> behaviors. In our case, the cpufreq driver does no longer work because
> the clock fails to initialize due to the clock stub and the mailbox
> missing.
>
> In order to have the dependencies correctly set when defaulting, let's
> do the same as commit 3a49afb84ca074e ("clk: enable hi655x common clk
> automatically") where we select automatically the driver when the
> parent driver is selected. With sensible defaults in place, we can leave
> other choices for EXPERT.
>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
> Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
> arch/arm64/configs/defconfig | 1 -
> drivers/clk/hisilicon/Kconfig | 13 ++++++++-----
> drivers/mailbox/Kconfig | 12 ++++++++----
> 3 files changed, 16 insertions(+), 10 deletions(-)
Could you separate this patch into clk, mailbox and defconfig 3 parts?
Thanks!
Best Regards,
Wei
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index ecf6137..1d9d8b9 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -549,7 +549,6 @@ CONFIG_HWSPINLOCK_QCOM=y
> CONFIG_ARM_MHU=y
> CONFIG_PLATFORM_MHU=y
> CONFIG_BCM2835_MBOX=y
> -CONFIG_HI6220_MBOX=y
> CONFIG_QCOM_APCS_IPC=y
> CONFIG_ROCKCHIP_IOMMU=y
> CONFIG_TEGRA_IOMMU_SMMU=y
> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
> index 1bd4355..becdb1d 100644
> --- a/drivers/clk/hisilicon/Kconfig
> +++ b/drivers/clk/hisilicon/Kconfig
> @@ -44,14 +44,17 @@ config RESET_HISI
> Build reset controller driver for HiSilicon device chipsets.
>
> config STUB_CLK_HI6220
> - bool "Hi6220 Stub Clock Driver"
> - depends on COMMON_CLK_HI6220 && MAILBOX
> - default ARCH_HISI
> + bool "Hi6220 Stub Clock Driver" if EXPERT
> + depends on (COMMON_CLK_HI6220 || COMPILE_TEST)
> + depends on MAILBOX
> + default COMMON_CLK_HI6220
> help
> Build the Hisilicon Hi6220 stub clock driver.
>
> config STUB_CLK_HI3660
> - bool "Hi3660 Stub Clock Driver"
> - depends on COMMON_CLK_HI3660 && MAILBOX
> + bool "Hi3660 Stub Clock Driver" if EXPERT
> + depends on (COMMON_CLK_HI3660 || COMPILE_TEST)
> + depends on MAILBOX
> + default COMMON_CLK_HI3660
> help
> Build the Hisilicon Hi3660 stub clock driver.
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index a2bb274..567cd02 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -109,16 +109,20 @@ config TI_MESSAGE_MANAGER
> platform has support for the hardware block.
>
> config HI3660_MBOX
> - tristate "Hi3660 Mailbox"
> - depends on ARCH_HISI && OF
> + tristate "Hi3660 Mailbox" if EXPERT
> + depends on (ARCH_HISI || COMPILE_TEST)
> + depends on OF
> + default ARCH_HISI
> help
> An implementation of the hi3660 mailbox. It is used to send message
> between application processors and other processors/MCU/DSP. Select
> Y here if you want to use Hi3660 mailbox controller.
>
> config HI6220_MBOX
> - tristate "Hi6220 Mailbox"
> - depends on ARCH_HISI
> + tristate "Hi6220 Mailbox" if EXPERT
> + depends on (ARCH_HISI || COMPILE_TEST)
> + depends on OF
> + default ARCH_HISI
> help
> An implementation of the hi6220 mailbox. It is used to send message
> between application processors and MCU. Say Y here if you want to
>
^ permalink raw reply
* Re: [PATCH/RFC v3 1/4] base: devcon: add a new API to find the graph
From: Heikki Krogerus @ 2018-05-15 8:29 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: gregkh@linuxfoundation.org, robh+dt@kernel.org,
mark.rutland@arm.com, hdegoede@redhat.com,
andy.shevchenko@gmail.com, linux-usb@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <OSBPR01MB22932EC3210BC8097E0B7F0FD8930@OSBPR01MB2293.jpnprd01.prod.outlook.com>
On Tue, May 15, 2018 at 02:19:14AM +0000, Yoshihiro Shimoda wrote:
> Hi Heikki,
>
> > From: Heikki Krogerus, Sent: Monday, May 14, 2018 10:28 PM
> >
> > On Mon, May 14, 2018 at 06:15:57PM +0900, Yoshihiro Shimoda wrote:
> <snip>
> > > diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
> > > index d427e80..5a0da33 100644
> > > --- a/drivers/base/devcon.c
> > > +++ b/drivers/base/devcon.c
> <snip>
> > > +static int generic_graph_match(struct device *dev, void *fwnode)
> > > +{
> > > + return dev->fwnode == fwnode;
> > > +}
> > > +
> > > +/**
> > > + * device_connection_find_by_graph - Find two devices connected together
> > > + * @dev: Device to find connected device
> > > + * @port: identifier of the @dev port node
> > > + * @endpoint: identifier of the @dev endpoint node
> > > + *
> > > + * Find a connection with @port and @endpoint by using graph between @dev and
> > > + * another device. On success returns handle to the device that is connected
> > > + * to @dev, with the reference count for the found device incremented. Returns
> > > + * NULL if no matching connection was found, or ERR_PTR(-EPROBE_DEFER) when
> > > + * a connection was found but the other device has not been enumerated yet.
> > > + */
> > > +struct device *device_connection_find_by_graph(struct device *dev, u32 port,
> > > + u32 endpoint)
> > > +{
> > > + struct bus_type *bus;
> > > + struct fwnode_handle *remote;
> > > + struct device *conn;
> > > +
> > > + remote = fwnode_graph_get_remote_node(dev_fwnode(dev), port, endpoint);
> > > + if (!remote)
> > > + return NULL;
> > > +
> > > + for (bus = generic_match_buses[0]; bus; bus++) {
> > > + conn = bus_find_device(bus, NULL, remote, generic_graph_match);
> > > + if (conn)
> > > + return conn;
> > > + }
> > > +
> > > + /*
> > > + * We only get called if a connection was found, tell the caller to
> > > + * wait for the other device to show up.
> > > + */
> > > + return ERR_PTR(-EPROBE_DEFER);
> > > +}
> > > +EXPORT_SYMBOL_GPL(device_connection_find_by_graph);
> >
> > Why do we need more API for walking through the graph?
>
> I thought there is difficult to find if a device has multiple ports or endpoints.
> So, I'd like to use port and endpoint number for finding a device.
>
> > I'm not sure exactly sure what is going on here, I'll try to study
> > your patches more when I have time, but the approach looks wrong. That
> > function looks like a helper, but just not that useful one.
> >
> > We really should be able to use the existing functions. In practice
> > device_connection_find_match() should eventually parse the graph, then
> > fallback to build-in connections if no graph is found. Otherwise
> > parsing graph here is not really useful at all.
>
> I think using device_connection_find_match() for finding the graph becomes complicated.
> The current arguments of the function is the below:
>
> void *device_connection_find_match(struct device *dev, const char *con_id,
> void *data,
> void *(*match)(struct device_connection *con,
> int ep, void *data))
>
> If finding the graph, the following arguments will be not used.
> - con_id
> - *con and ep of "match" arguments.
>
> This is because these arguments are for the build-in connections.
No they're not. You do realize that we can build a temporary struct
device_connection there and then (in stack) to be supplied for the
->match callback.
> So, should I modify the arguments of the function for finding both
> the graph and built-in connections somehow?
I don't see any need for that. We may need to modify struct
device_connection, but there should not be any need to touch the API.
Your plan to use port and endpoint number is wrong, as they are just
indexes, and therefore not reliable. Luckily it should be completely
unnecessary to use them.
The way I see this working is that we parse all the endpoints the
caller device has. If we can't take advantage of the con_id for
identification (though ideally we can), we just need to call ->match
with every one of them. The implementation for the ->match callback is
then responsible of figuring out if the endpoint is the one we are
looking for or not in that case.
The only problem I see with that is that we may not have a reliable
way to convert the fwnode pointing to the remote-endpoint parent into
struct device (if one has already been enumerated) in order to get the
device name and use it as the second endpoint name in struct
device_connection. To solve that, we could consider for example just
adding a new member, fwnode pointer perhaps, to the structure. Or
perhaps use the endpoint members for something else than device names
when graph is used, and add a member defining the type of match:
graph, build-in, etc. There are many things we can consider.
I don't know if I'm able to explain what I'm after with this, so if
you like, I can propose something for this myself. Though that will
have to wait for few weeks. Right now I'm too busy with other stuff.
Thanks,
--
heikki
^ permalink raw reply
* RE: [PATCH/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API
From: Yoshihiro Shimoda @ 2018-05-15 8:32 UTC (permalink / raw)
To: Simon Horman
Cc: gregkh@linuxfoundation.org, robh+dt@kernel.org,
mark.rutland@arm.com, heikki.krogerus@linux.intel.com,
hdegoede@redhat.com, andy.shevchenko@gmail.com,
linux-usb@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <20180515080342.wksfk5qpazv4l3rs@verge.net.au>
Hi Simon-san,
> From: Simon Horman, Sent: Tuesday, May 15, 2018 5:04 PM
>
> On Tue, May 15, 2018 at 08:02:00AM +0000, Yoshihiro Shimoda wrote:
> > Hi Simon-san,
> >
> > Thank you for your review!
> >
> > > From: Simon Horman, Sent: Tuesday, May 15, 2018 4:54 PM
> > > On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:
> > <snip>
> > > > static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> > > > {
> > > > - _usb3_set_mode(usb3, host);
> > > > + if (usb3->role_sw)
> > > > + usb_role_switch_set_role(usb3->role_sw, host ?
> > > > + USB_ROLE_HOST : USB_ROLE_DEVICE);
> > > > + else
> > > > + _usb3_set_mode(usb3, host);
> > > > }
> > > >
> > > > static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> > > > @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, bool host, bool a_dev)
> > > > {
> > > > unsigned long flags;
> > > >
> > > > - spin_lock_irqsave(&usb3->lock, flags);
> > > > usb3_set_mode(usb3, host);
> > > > + spin_lock_irqsave(&usb3->lock, flags);
> > >
> > > Hi Shimoda-san,
> > >
> > > could you clarify why moving this lock is safe?
> >
> > The usb3_set_mode() is possible to call usb_role_switch_set_role() API
> > and usb_role_switch_set_role() calls mutex_lock().
> > So, this moving this lock (especially avoiding irqsave) needs.
>
> Thanks, that make sense.
>
> But usb3_set_mode() may also call _usb3_set_mode().
> It is safe to call _usb3_set_mode() without holding the lock?
Thank you for the pointed out. I am thinking it is possible to be
unsafe without holding the lock. So, I'd like to improve this patch somehow
(for example: Add new usb role switch APIs without mutex).
Best regards,
Yoshihiro Shimoda
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: media: rcar-vin: Add R8A77995 support
From: jacopo mondi @ 2018-05-15 8:36 UTC (permalink / raw)
To: Simon Horman
Cc: Jacopo Mondi, niklas.soderlund, laurent.pinchart, geert,
magnus.damm, robh+dt, linux-renesas-soc, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20180511133513.25dldevvnlnxl7y6@verge.net.au>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
Hi Simon,
On Fri, May 11, 2018 at 03:35:14PM +0200, Simon Horman wrote:
> On Fri, May 11, 2018 at 12:00:00PM +0200, Jacopo Mondi wrote:
> > Add compatible string for R-Car D3 R8A7795 to list of SoCs supported by
> > rcar-vin driver.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
>
Does this goes in through your tree? I will send a v2, should I
include this one or you have collected it already?
Thanks
j
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile
From: Erin Lo @ 2018-05-15 8:39 UTC (permalink / raw)
To: Marc Zyngier
Cc: Matthias Brugger, Rob Herring, Mark Rutland, Thomas Gleixner,
Jason Cooper, Greg Kroah-Hartman, devicetree, srv_heupstream,
linux-kernel, linux-serial, linux-mediatek, linux-arm-kernel,
yingjoe.chen, mars.cheng, Ben Ho, Hailong Fan
In-Reply-To: <efa91778-e81f-9ba4-22a6-43ff0f94af4f@arm.com>
On Mon, 2018-05-14 at 11:35 +0100, Marc Zyngier wrote:
> On 14/05/18 11:22, Erin Lo wrote:
> > From: Ben Ho <Ben.Ho@mediatek.com>
> >
> > Add basic chip support for Mediatek 8183
> >
> > Signed-off-by: Ben Ho <Ben.Ho@mediatek.com>
> > Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> > ---
> > arch/arm64/boot/dts/mediatek/Makefile | 1 +
> > arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 31 +++++
> > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 178 ++++++++++++++++++++++++++++
> > 3 files changed, 210 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi
> >
>
> [...]
>
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > new file mode 100644
> > index 0000000..8564a26
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>
> [...]
>
> > + gic: interrupt-controller@0c000000 {
> > + compatible = "arm,gic-v3";
> > + #interrupt-cells = <3>;
> > + interrupt-parent = <&gic>;
> > + interrupt-controller;
> > + reg = <0 0x0c000000 0 0x40000>, // CID
> > + <0 0x0c100000 0 0x200000>; // CIR
>
> You're missing the GICV and GICH regions that are present on both A53
> and A73 at an offset from PERIPHBASE.
>
> > + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> > + };
>
> Thanks,
>
> M.
I will fill out the GICV and GICH in next round.
Thanks.
Regards,
Erin
^ permalink raw reply
* Re: [PATCH 3/6] pinctrl: sh-pfc: r8a77990: Add bias pinconf support
From: Geert Uytterhoeven @ 2018-05-15 8:40 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Laurent Pinchart, Geert Uytterhoeven, Linus Walleij, Rob Herring,
Mark Rutland, Linux-Renesas, open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Takeshi Kihara
In-Reply-To: <CAMuHMdWEzRic5dy_Daj-JDkwCjn7mPTmWbVb7zTPLbuxcQ22Fg@mail.gmail.com>
On Mon, May 14, 2018 at 10:13 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, May 11, 2018 at 5:22 AM, Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com> wrote:
>> From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>>
>> This patch implements control of pull-up and pull-down. On this SoC there
>> is no simple mapping of GP pins to bias register bits, so we need a table.
>>
>> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>
> Thanks for your patch!
>
>> --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
>> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
>
>> @@ -1227,10 +1248,55 @@ enum {
>>
>> PINMUX_IPSR_GPSR(IP15_31_28, USB30_OVC),
>> PINMUX_IPSR_MSEL(IP15_31_28, USB0_OVC_A, SEL_USB_20_CH0_0),
>> +
>> +/*
>> + * Static pins can not be muxed between different functions but
>> + * still needs a mark entry in the pinmux list. Add each static
>
> need mark entries
>
>> + * pin to the list without an associated function. The sh-pfc
>> + * core will do the right thing and skip trying to mux then pin
>
> mux the pin
>
>> + * while still applying configuration to it
>
> period
>
> I have just sent a patch to fix the other copies, in the hope these grammar
> atrocities will stop spreading ;-)
>
>> @@ -1708,8 +1774,263 @@ enum {
>> { },
>> };
>>
>> +static const struct pinmux_bias_reg pinmux_bias_regs[] = {
>
> The register definitions look OK to me.
> I'll review the actual pin mappings later.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in sh-pfc-for-v4.18 with the comments fixed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 09/12] platform/early: add an init section for early driver data
From: Bartosz Golaszewski @ 2018-05-15 8:41 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sekhar Nori, Kevin Hilman, David Lechner, Michael Turquette,
Stephen Boyd, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Yoshinori Sato, Rich Felker, Andy Shevchenko, Marc Zyngier,
Rafael J . Wysocki, Peter Rosin, Jiri Slaby, Thomas Gleixner,
Daniel Lezcano, Magnus Damm, Johan Hovold, Rob Herring, Frank
In-Reply-To: <CAMuHMdUnG0YLg=HXMrUVJ34sZEDuuZRYxnrPPC45-KpAkO3bcw@mail.gmail.com>
2018-05-14 23:29 GMT+02:00 Geert Uytterhoeven <geert@linux-m68k.org>:
> Hi Bartosz,
>
> On Fri, May 11, 2018 at 6:20 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> Provide a separate section in which pointers to early platform driver
>> structs will be stored.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Thanks for your patch!
>
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -214,6 +214,16 @@
>> #define CPU_METHOD_OF_TABLES() OF_TABLE(CONFIG_SMP, cpu_method)
>> #define CPUIDLE_METHOD_OF_TABLES() OF_TABLE(CONFIG_CPU_IDLE, cpuidle_method)
>>
>> +#ifdef CONFIG_EARLY_PLATFORM
>> +#define EARLY_PLATFORM_DRIVERS_TABLE() \
>> + . = ALIGN(8); \
>
> Should this use STRUCT_ALIGN() instead?
>
No, we're only using it to store pointers to structs, not the actual
struct early_platform_driver objects.
>> + VMLINUX_SYMBOL(__early_platform_drivers_table) = .; \
>> + KEEP(*(__early_platform_drivers_table)) \
>> + VMLINUX_SYMBOL(__early_platform_drivers_table_end) = .;
>> +#else
>> +#define EARLY_PLATFORM_DRIVERS_TABLE()
>> +#endif
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: ravb: Add support for r8a77990 SoC
From: Sergei Shtylyov @ 2018-05-15 8:43 UTC (permalink / raw)
To: Simon Horman, David Miller
Cc: yoshihiro.shimoda.uh, netdev, linux-renesas-soc, robh+dt,
mark.rutland, devicetree
In-Reply-To: <20180513075803.plrkbwmzksjnz45u@verge.net.au>
On 5/13/2018 10:58 AM, Simon Horman wrote:
>>> Add documentation for r8a77990 compatible string to renesas ravb device
>>> tree bindings documentation.
>>>
>>> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>>
>> I'm assuming this isn't targetted at one of my trees. Just FYI.
>
> Hi Dave,
>
> I think this is appropriate for net-next but if not I can take it.
There's also Rob, and IIRC he has taken alike patch recently...
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH] ARM: dts: imx51-zii-rdu1: limit usbh1 to full-speed
From: Nikita Yushchenko @ 2018-05-15 8:45 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Mark Rutland, Lucas Stach, Chris Healy,
Andrey Smirnov, Marco Franchi
Cc: linux-arm-kernel, devicetree, linux-kernel, Nikita Yushchenko
On RDU1, imx51 usbh1 interface is either not used, or used via external
block that breaks USB2 signalling.
To keep things working if high-speed device gets connected to that
block, use ChipIdea feature to limit port to full speed.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index 36a63ae52e48..c26f053f29b0 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -603,6 +603,7 @@
phy_type = "ulpi";
fsl,usbphy = <&usbh1phy>;
disable-over-current;
+ maximum-speed = "full-speed";
vbus-supply = <®_5p0v_main>;
status = "okay";
};
--
2.11.0
^ permalink raw reply related
* [PATCH v2 0/7] add support for Bluetooth on MT7622 SoC
From: sean.wang @ 2018-05-15 8:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, marcel, johan.hedberg
Cc: devicetree, linux-bluetooth, linux-arm-kernel, linux-mediatek,
linux-kernel, Sean Wang
From: Sean Wang <sean.wang@mediatek.com>
v2 and changes since v1
- Dropped patches already being applied
- Rewirte the whole driver using btuart [1], and add slight extension
of btuart to fit into btmtkuart driver. Beware that [1] is also pulled
into one part of the series for avoiding any breakage when the patchset
is being compiled.
[1] btuart
https://www.spinics.net/lists/linux-bluetooth/msg74918.html
v1:
Hi,
This patchset introduces built-in Bluetooth support on MT7622 SoC.
And, it should be simple to make an extension to support other
MediaTek SoCs with adjusting a few of changes on the initialization
sequence of the device.
Before the main driver is being introduced, a few of things about
power-domain management should be re-worked for serdev core and MediaTek
SCPSYS to allow the Bluetooth to properly power up.
Patch 2: add a generic way attaching power domain to serdev
Patch 3 and 4: add cleanups with reuse APIs from Linux core
Patch 5: fix a limitation about power enablement Bluetooth depends on
Patch 1, 6 and 7: the major part of adding Bluetooth support to MT7622
Sean
Marcel Holtmann (1):
Bluetooth: Add new serdev based driver for UART attached controllers
Sean Wang (6):
dt-bindings: net: bluetooth: Add mediatek-bluetooth
serdev: add dev_pm_domain_attach|detach()
Bluetooth: Add new quirk for non-persistent setup settings
Bluetooth: Extend btuart driver for join more vendor devices
Bluetooth: mediatek: Add protocol support for MediaTek serial devices
MAINTAINERS: add an entry for MediaTek Bluetooth driver
.../devicetree/bindings/net/mediatek-bluetooth.txt | 35 ++
MAINTAINERS | 8 +
drivers/bluetooth/Kconfig | 23 +
drivers/bluetooth/Makefile | 3 +
drivers/bluetooth/btmtkuart.c | 383 +++++++++++++++
drivers/bluetooth/btmtkuart.h | 119 +++++
drivers/bluetooth/btuart.c | 527 +++++++++++++++++++++
drivers/bluetooth/btuart.h | 30 ++
drivers/tty/serdev/core.c | 14 +-
include/net/bluetooth/hci.h | 9 +
net/bluetooth/hci_core.c | 3 +-
11 files changed, 1152 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
create mode 100644 drivers/bluetooth/btmtkuart.c
create mode 100644 drivers/bluetooth/btmtkuart.h
create mode 100644 drivers/bluetooth/btuart.c
create mode 100644 drivers/bluetooth/btuart.h
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/7] dt-bindings: net: bluetooth: Add mediatek-bluetooth
From: sean.wang-NuS5LvNUpcJWk0Htik3J/w @ 2018-05-15 8:52 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
marcel-kz+m5ild9QBg9hUCZPvPmw,
johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Sean Wang,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <cover.1526374087.git.sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Add binding document for a SoC built-in device using MediaTek protocol.
Which could be found on MT7622 SoC or other similar MediaTek SoCs.
Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/net/mediatek-bluetooth.txt | 35 ++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
diff --git a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
new file mode 100644
index 0000000..1335429
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
@@ -0,0 +1,35 @@
+MediaTek SoC built-in Bluetooth Devices
+==================================
+
+This device is a serial attached device to BTIF device and thus it must be a
+child node of the serial node with BTIF. The dt-bindings details for BTIF
+device can be known via Documentation/devicetree/bindings/serial/8250.txt.
+
+Required properties:
+
+- compatible: Must be one of
+ "mediatek,mt7622-bluetooth"": for MT7622 SoC
+- clocks: Should be the clock specifiers corresponding to the entry in
+ clock-names property.
+- clock-names: Should contain "ref" entries.
+- power-domains: Phandle to the power domain that the device is part of
+
+Example:
+
+ btif: serial@1100c000 {
+ compatible = "mediatek,mt7622-btif",
+ "mediatek,mtk-btif";
+ reg = <0 0x1100c000 0 0x1000>;
+ interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_BTIF_PD>;
+ clock-names = "main";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+
+ bluetooth {
+ compatible = "mediatek,mt7622-bluetooth";
+ power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>;
+ clocks = <&clk25m>;
+ clock-names = "ref";
+ };
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/7] serdev: add dev_pm_domain_attach|detach()
From: sean.wang @ 2018-05-15 8:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, marcel, johan.hedberg
Cc: devicetree, Ulf Hansson, Rob Herring, Greg Kroah-Hartman,
Sean Wang, linux-kernel, linux-bluetooth, linux-mediatek,
linux-serial, Jiri Slaby, linux-arm-kernel
In-Reply-To: <cover.1526374087.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
In order to open up the required power gate before any operation can be
effectively performed over the serial bus between CPU and serdev, it's
clearly essential to add common attach functions for PM domains to serdev
at the probe phase.
Similarly, the relevant dettach function for the PM domains should be
properly and reversely added at the remove phase.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-serial@vger.kernel.org
---
drivers/tty/serdev/core.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
index df93b72..c93d8ee 100644
--- a/drivers/tty/serdev/core.c
+++ b/drivers/tty/serdev/core.c
@@ -13,6 +13,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/pm_domain.h>
#include <linux/serdev.h>
#include <linux/slab.h>
@@ -330,8 +331,16 @@ EXPORT_SYMBOL_GPL(serdev_device_set_tiocm);
static int serdev_drv_probe(struct device *dev)
{
const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
+ int ret;
+
+ ret = dev_pm_domain_attach(dev, true);
+ if (ret != -EPROBE_DEFER) {
+ ret = sdrv->probe(to_serdev_device(dev));
+ if (ret)
+ dev_pm_domain_detach(dev, true);
+ }
- return sdrv->probe(to_serdev_device(dev));
+ return ret;
}
static int serdev_drv_remove(struct device *dev)
@@ -339,6 +348,9 @@ static int serdev_drv_remove(struct device *dev)
const struct serdev_device_driver *sdrv = to_serdev_device_driver(dev->driver);
if (sdrv->remove)
sdrv->remove(to_serdev_device(dev));
+
+ dev_pm_domain_detach(dev, true);
+
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/7] Bluetooth: Add new serdev based driver for UART attached controllers
From: sean.wang @ 2018-05-15 8:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, marcel, johan.hedberg
Cc: devicetree, linux-bluetooth, linux-arm-kernel, linux-mediatek,
linux-kernel
In-Reply-To: <cover.1526374087.git.sean.wang@mediatek.com>
From: Marcel Holtmann <marcel@holtmann.org>
This is a from scratch written driver to run H:4 on serdev based system
with a Bluetooth controller attached via an UART. It is currently tested
on RPi3 and it has Broadcom integration. It is DT only and is missing
GPIO and runtime power management integration. Also Apple or ACPI
support is currently not added.
To integrate with controllers from Intel and Qualcomm, similar handling
like with btusb.c has to be done. A simple abstraction for that has been
provided to make it similar to hci_uart.
The goal is to run individual drivers on serdev capable systems so that
we can retire hci_uart on these system and continue with a lot simpler
and easier to maintain driver. It seems that hci_uart has too many race
conditions due to handling TTY and line disciplines. And fixes for that
are not really related to serdev based drivers. In a serdev only world
it makes sense to remove any of the complex code.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
drivers/bluetooth/Kconfig | 11 +
drivers/bluetooth/Makefile | 1 +
drivers/bluetooth/btuart.c | 506 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 518 insertions(+)
create mode 100644 drivers/bluetooth/btuart.c
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 010f5f5..6d69ac2 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -74,6 +74,17 @@ config BT_HCIBTSDIO
Say Y here to compile support for Bluetooth SDIO devices into the
kernel or say M to compile it as module (btsdio).
+config BT_HCIBTUART
+ tristate "HCI UART driver"
+ depends on SERIAL_DEV_BUS
+ help
+ Bluetooth HCI UART driver.
+ This driver is required if you want to use Bluetooth device with
+ UART interface.
+
+ Say Y here to compile support for Bluetooth UART devices into the
+ kernel or say M to compile it as module (btuart).
+
config BT_HCIUART
tristate "HCI UART driver"
depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index ec16c55..60a19cb 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_BT_HCIBLUECARD) += bluecard_cs.o
obj-$(CONFIG_BT_HCIBTUSB) += btusb.o
obj-$(CONFIG_BT_HCIBTSDIO) += btsdio.o
+obj-$(CONFIG_BT_HCIBTUART) += btuart.o
obj-$(CONFIG_BT_INTEL) += btintel.o
obj-$(CONFIG_BT_ATH3K) += ath3k.o
diff --git a/drivers/bluetooth/btuart.c b/drivers/bluetooth/btuart.c
new file mode 100644
index 0000000..03e980f
--- /dev/null
+++ b/drivers/bluetooth/btuart.c
@@ -0,0 +1,506 @@
+/*
+ *
+ * Generic Bluetooth HCI UART driver
+ *
+ * Copyright (C) 2015-2018 Intel Corporation
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/skbuff.h>
+#include <linux/serdev.h>
+#include <linux/of.h>
+#include <linux/firmware.h>
+#include <asm/unaligned.h>
+
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+
+#include "h4_recv.h"
+#include "btbcm.h"
+
+#define VERSION "1.0"
+
+struct btuart_vnd {
+ const struct h4_recv_pkt *recv_pkts;
+ int recv_pkts_cnt;
+ unsigned int manufacturer;
+ int (*open)(struct hci_dev *hdev);
+ int (*close)(struct hci_dev *hdev);
+ int (*setup)(struct hci_dev *hdev);
+};
+
+struct btuart_dev {
+ struct hci_dev *hdev;
+ struct serdev_device *serdev;
+
+ struct work_struct tx_work;
+ unsigned long tx_state;
+ struct sk_buff_head txq;
+
+ struct sk_buff *rx_skb;
+
+ const struct btuart_vnd *vnd;
+};
+
+#define BTUART_TX_STATE_ACTIVE 1
+#define BTUART_TX_STATE_WAKEUP 2
+
+static void btuart_tx_work(struct work_struct *work)
+{
+ struct btuart_dev *bdev = container_of(work, struct btuart_dev,
+ tx_work);
+ struct serdev_device *serdev = bdev->serdev;
+ struct hci_dev *hdev = bdev->hdev;
+
+ while (1) {
+ clear_bit(BTUART_TX_STATE_WAKEUP, &bdev->tx_state);
+
+ while (1) {
+ struct sk_buff *skb = skb_dequeue(&bdev->txq);
+ int len;
+
+ if (!skb)
+ break;
+
+ len = serdev_device_write_buf(serdev, skb->data,
+ skb->len);
+ hdev->stat.byte_tx += len;
+
+ skb_pull(skb, len);
+ if (skb->len > 0) {
+ skb_queue_head(&bdev->txq, skb);
+ break;
+ }
+
+ switch (hci_skb_pkt_type(skb)) {
+ case HCI_COMMAND_PKT:
+ hdev->stat.cmd_tx++;
+ break;
+ case HCI_ACLDATA_PKT:
+ hdev->stat.acl_tx++;
+ break;
+ case HCI_SCODATA_PKT:
+ hdev->stat.sco_tx++;
+ break;
+ }
+
+ kfree_skb(skb);
+ }
+
+ if (!test_bit(BTUART_TX_STATE_WAKEUP, &bdev->tx_state))
+ break;
+ }
+
+ clear_bit(BTUART_TX_STATE_ACTIVE, &bdev->tx_state);
+}
+
+static int btuart_tx_wakeup(struct btuart_dev *bdev)
+{
+ if (test_and_set_bit(BTUART_TX_STATE_ACTIVE, &bdev->tx_state)) {
+ set_bit(BTUART_TX_STATE_WAKEUP, &bdev->tx_state);
+ return 0;
+ }
+
+ schedule_work(&bdev->tx_work);
+ return 0;
+}
+
+static int btuart_open(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+ int err;
+
+ err = serdev_device_open(bdev->serdev);
+ if (err) {
+ bt_dev_err(hdev, "Unable to open UART device %s",
+ dev_name(&bdev->serdev->dev));
+ return err;
+ }
+
+ if (bdev->vnd->open) {
+ err = bdev->vnd->open(hdev);
+ if (err) {
+ serdev_device_close(bdev->serdev);
+ return err;
+ }
+ }
+
+ return 0;
+}
+
+static int btuart_close(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+ int err;
+
+ if (bdev->vnd->close) {
+ err = bdev->vnd->close(hdev);
+ if (err)
+ return err;
+ }
+
+ serdev_device_close(bdev->serdev);
+
+ return 0;
+}
+
+static int btuart_flush(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+
+ /* Flush any pending characters */
+ serdev_device_write_flush(bdev->serdev);
+ skb_queue_purge(&bdev->txq);
+
+ cancel_work_sync(&bdev->tx_work);
+
+ kfree_skb(bdev->rx_skb);
+ bdev->rx_skb = NULL;
+
+ return 0;
+}
+
+static int btuart_setup(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+
+ if (bdev->vnd->setup)
+ return bdev->vnd->setup(hdev);
+
+ return 0;
+}
+
+static int btuart_send_frame(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+
+ /* Prepend skb with frame type */
+ memcpy(skb_push(skb, 1), &hci_skb_pkt_type(skb), 1);
+ skb_queue_tail(&bdev->txq, skb);
+
+ btuart_tx_wakeup(bdev);
+ return 0;
+}
+
+static int btuart_receive_buf(struct serdev_device *serdev, const u8 *data,
+ size_t count)
+{
+ struct btuart_dev *bdev = serdev_device_get_drvdata(serdev);
+ const struct btuart_vnd *vnd = bdev->vnd;
+
+ bdev->rx_skb = h4_recv_buf(bdev->hdev, bdev->rx_skb, data, count,
+ vnd->recv_pkts, vnd->recv_pkts_cnt);
+ if (IS_ERR(bdev->rx_skb)) {
+ int err = PTR_ERR(bdev->rx_skb);
+ bt_dev_err(bdev->hdev, "Frame reassembly failed (%d)", err);
+ bdev->rx_skb = NULL;
+ return err;
+ }
+
+ bdev->hdev->stat.byte_rx += count;
+
+ return count;
+}
+
+static void btuart_write_wakeup(struct serdev_device *serdev)
+{
+ struct btuart_dev *bdev = serdev_device_get_drvdata(serdev);
+
+ btuart_tx_wakeup(bdev);
+}
+
+static const struct serdev_device_ops btuart_client_ops = {
+ .receive_buf = btuart_receive_buf,
+ .write_wakeup = btuart_write_wakeup,
+};
+
+#define BCM_NULL_PKT 0x00
+#define BCM_NULL_SIZE 0
+
+#define BCM_LM_DIAG_PKT 0x07
+#define BCM_LM_DIAG_SIZE 63
+
+#define BCM_RECV_LM_DIAG \
+ .type = BCM_LM_DIAG_PKT, \
+ .hlen = BCM_LM_DIAG_SIZE, \
+ .loff = 0, \
+ .lsize = 0, \
+ .maxlen = BCM_LM_DIAG_SIZE
+
+#define BCM_RECV_NULL \
+ .type = BCM_NULL_PKT, \
+ .hlen = BCM_NULL_SIZE, \
+ .loff = 0, \
+ .lsize = 0, \
+ .maxlen = BCM_NULL_SIZE
+
+static int bcm_set_diag(struct hci_dev *hdev, bool enable)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+ struct sk_buff *skb;
+
+ if (!test_bit(HCI_RUNNING, &hdev->flags))
+ return -ENETDOWN;
+
+ skb = bt_skb_alloc(3, GFP_KERNEL);
+ if (!skb)
+ return -ENOMEM;
+
+ skb_put_u8(skb, BCM_LM_DIAG_PKT);
+ skb_put_u8(skb, 0xf0);
+ skb_put_u8(skb, enable);
+
+ skb_queue_tail(&bdev->txq, skb);
+ btuart_tx_wakeup(bdev);
+
+ return 0;
+}
+
+static int bcm_set_baudrate(struct btuart_dev *bdev, unsigned int speed)
+{
+ struct hci_dev *hdev = bdev->hdev;
+ struct sk_buff *skb;
+ struct bcm_update_uart_baud_rate param;
+
+ if (speed > 3000000) {
+ struct bcm_write_uart_clock_setting clock;
+
+ clock.type = BCM_UART_CLOCK_48MHZ;
+
+ bt_dev_dbg(hdev, "Set Controller clock (%d)", clock.type);
+
+ /* This Broadcom specific command changes the UART's controller
+ * clock for baud rate > 3000000.
+ */
+ skb = __hci_cmd_sync(hdev, 0xfc45, 1, &clock, HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ int err = PTR_ERR(skb);
+ bt_dev_err(hdev, "Failed to write clock (%d)", err);
+ return err;
+ }
+
+ kfree_skb(skb);
+ }
+
+ bt_dev_dbg(hdev, "Set Controller UART speed to %d bit/s", speed);
+
+ param.zero = cpu_to_le16(0);
+ param.baud_rate = cpu_to_le32(speed);
+
+ /* This Broadcom specific command changes the UART's controller baud
+ * rate.
+ */
+ skb = __hci_cmd_sync(hdev, 0xfc18, sizeof(param), ¶m,
+ HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ int err = PTR_ERR(skb);
+ bt_dev_err(hdev, "Failed to write update baudrate (%d)", err);
+ return err;
+ }
+
+ kfree_skb(skb);
+
+ return 0;
+}
+
+static int bcm_setup(struct hci_dev *hdev)
+{
+ struct btuart_dev *bdev = hci_get_drvdata(hdev);
+ char fw_name[64];
+ const struct firmware *fw;
+ unsigned int speed;
+ int err;
+
+ hdev->set_diag = bcm_set_diag;
+ hdev->set_bdaddr = btbcm_set_bdaddr;
+
+ /* Init speed if any */
+ speed = 115200;
+
+ if (speed)
+ serdev_device_set_baudrate(bdev->serdev, speed);
+
+ /* Operational speed if any */
+ speed = 115200;
+
+ if (speed) {
+ err = bcm_set_baudrate(bdev, speed);
+ if (err)
+ bt_dev_err(hdev, "Failed to set baudrate");
+ else
+ serdev_device_set_baudrate(bdev->serdev, speed);
+ }
+
+ err = btbcm_initialize(hdev, fw_name, sizeof(fw_name));
+ if (err)
+ return err;
+
+ err = request_firmware(&fw, fw_name, &hdev->dev);
+ if (err < 0) {
+ bt_dev_warn(hdev, "Patch %s not found", fw_name);
+ return 0;
+ }
+
+ err = btbcm_patchram(bdev->hdev, fw);
+ if (err) {
+ bt_dev_err(hdev, "Patching failed (%d)", err);
+ goto finalize;
+ }
+
+ /* Init speed if any */
+ speed = 115200;
+
+ if (speed)
+ serdev_device_set_baudrate(bdev->serdev, speed);
+
+ /* Operational speed if any */
+ speed = 115200;
+
+ if (speed) {
+ err = bcm_set_baudrate(bdev, speed);
+ if (!err)
+ serdev_device_set_baudrate(bdev->serdev, speed);
+ }
+
+finalize:
+ release_firmware(fw);
+
+ err = btbcm_finalize(hdev);
+ if (err)
+ return err;
+
+ return err;
+}
+
+static const struct h4_recv_pkt bcm_recv_pkts[] = {
+ { H4_RECV_ACL, .recv = hci_recv_frame },
+ { H4_RECV_SCO, .recv = hci_recv_frame },
+ { H4_RECV_EVENT, .recv = hci_recv_frame },
+ { BCM_RECV_LM_DIAG, .recv = hci_recv_diag },
+ { BCM_RECV_NULL, .recv = hci_recv_diag },
+};
+
+static const struct btuart_vnd bcm_vnd = {
+ .recv_pkts = bcm_recv_pkts,
+ .recv_pkts_cnt = ARRAY_SIZE(bcm_recv_pkts),
+ .manufacturer = 15,
+ .setup = bcm_setup,
+};
+
+static const struct h4_recv_pkt default_recv_pkts[] = {
+ { H4_RECV_ACL, .recv = hci_recv_frame },
+ { H4_RECV_SCO, .recv = hci_recv_frame },
+ { H4_RECV_EVENT, .recv = hci_recv_frame },
+};
+
+static const struct btuart_vnd default_vnd = {
+ .recv_pkts = default_recv_pkts,
+ .recv_pkts_cnt = ARRAY_SIZE(default_recv_pkts),
+};
+
+static int btuart_probe(struct serdev_device *serdev)
+{
+ struct btuart_dev *bdev;
+ struct hci_dev *hdev;
+
+ bdev = devm_kzalloc(&serdev->dev, sizeof(*bdev), GFP_KERNEL);
+ if (!bdev)
+ return -ENOMEM;
+
+ /* Request the vendor specific data and callbacks */
+ bdev->vnd = device_get_match_data(&serdev->dev);
+ if (!bdev->vnd)
+ bdev->vnd = &default_vnd;
+
+ bdev->serdev = serdev;
+ serdev_device_set_drvdata(serdev, bdev);
+
+ serdev_device_set_client_ops(serdev, &btuart_client_ops);
+
+ INIT_WORK(&bdev->tx_work, btuart_tx_work);
+ skb_queue_head_init(&bdev->txq);
+
+ /* Initialize and register HCI device */
+ hdev = hci_alloc_dev();
+ if (!hdev) {
+ dev_err(&serdev->dev, "Can't allocate HCI device\n");
+ return -ENOMEM;
+ }
+
+ bdev->hdev = hdev;
+
+ hdev->bus = HCI_UART;
+ hci_set_drvdata(hdev, bdev);
+
+ /* Only when vendor specific setup callback is provided, consider
+ * the manufacturer information valid. This avoids filling in the
+ * value for Ericsson when nothing is specified.
+ */
+ if (bdev->vnd->setup)
+ hdev->manufacturer = bdev->vnd->manufacturer;
+
+ hdev->open = btuart_open;
+ hdev->close = btuart_close;
+ hdev->flush = btuart_flush;
+ hdev->setup = btuart_setup;
+ hdev->send = btuart_send_frame;
+ SET_HCIDEV_DEV(hdev, &serdev->dev);
+
+ if (hci_register_dev(hdev) < 0) {
+ dev_err(&serdev->dev, "Can't register HCI device\n");
+ hci_free_dev(hdev);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void btuart_remove(struct serdev_device *serdev)
+{
+ struct btuart_dev *bdev = serdev_device_get_drvdata(serdev);
+ struct hci_dev *hdev = bdev->hdev;
+
+ hci_unregister_dev(hdev);
+ hci_free_dev(hdev);
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id btuart_of_match_table[] = {
+ { .compatible = "brcm,bcm43438-bt", .data = &bcm_vnd },
+ { }
+};
+MODULE_DEVICE_TABLE(of, btuart_of_match_table);
+#endif
+
+static struct serdev_device_driver btuart_driver = {
+ .probe = btuart_probe,
+ .remove = btuart_remove,
+ .driver = {
+ .name = "btuart",
+ .of_match_table = of_match_ptr(btuart_of_match_table),
+ },
+};
+
+module_serdev_device_driver(btuart_driver);
+
+MODULE_AUTHOR("Marcel Holtmann <marcel@holtmann.org>");
+MODULE_DESCRIPTION("Generic Bluetooth UART driver ver " VERSION);
+MODULE_VERSION(VERSION);
+MODULE_LICENSE("GPL");
--
2.7.4
^ 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