* RE: [PATCH v2] arm64: dts: ls1088a: Add USB support
From: Yinbo Zhu @ 2017-12-07 7:33 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Mark Rutland, Catalin Marinas ), Will Deacon ),
Harninder Rai, Raghav Dogra, Ashish Kumar, Andy Tang,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
open list
In-Reply-To: <VI1PR04MB1262DD3C6A18257DEE2E907DE9200-mr6QIVyDiCGbtYzA8xQqo89NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Hi shawn guo,
If my patch has no other issue,
Can you help me push it to upstream.
Thanks.
BRs.
-----Original Message-----
From: Yinbo Zhu
Sent: Wednesday, November 22, 2017 9:32 AM
To: 'Shawn Guo' <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: 'Rob Herring' <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; 'Mark Rutland' <mark.rutland-AbSShOkvfpQ@public.gmane.orgm>; 'Catalin Marinas )' <catalin.marinas-5wv7dgnIgG8@public.gmane.org>; 'Will Deacon )' <will.deacon-5wv7dgnIgG8@public.gmane.org>; Harninder Rai <harninder.rai-3arQi8VN3Tc@public.gmane.org>; 'Raghav Dogra' <raghav.dogra-3arQi8VN3Tc@public.gmane.org>; Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>; Andy Tang <andy.tang@nxp.com>; 'open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS' <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; 'linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org' <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>; 'open list' <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: RE: [PATCH v2] arm64: dts: ls1088a: Add USB support
Hi
-----Original Message-----
From: Yinbo Zhu
Sent: Tuesday, November 14, 2017 4:00 PM
To: 'Shawn Guo' <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: 'Rob Herring' <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; 'Mark Rutland' <mark.rutland-AbSShOkvfpQ@public.gmane.orgm>; 'Catalin Marinas )' <catalin.marinas-5wv7dgnIgG8@public.gmane.org>; 'Will Deacon )' <will.deacon-5wv7dgnIgG8@public.gmane.org>; Harninder Rai <harninder.rai-3arQi8VN3Tc@public.gmane.org>; 'Raghav Dogra' <raghav.dogra-3arQi8VN3Tc@public.gmane.org>; Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>; Andy Tang <andy.tang@nxp.com>; 'open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS' <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; 'linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org' <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>; 'open list' <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: RE: [PATCH v2] arm64: dts: ls1088a: Add USB support
-----Original Message-----
From: Yinbo Zhu
Sent: Tuesday, October 24, 2017 5:15 PM
To: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>; Catalin Marinas ) <catalin.marinas-5wv7dgnIgG8@public.gmane.org>; Will Deacon ) <will.deacon@arm.com>; Harninder Rai <harninder.rai-3arQi8VN3Tc@public.gmane.org>; Raghav Dogra <raghav.dogra@nxp.com>; Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>; Andy Tang <andy.tang-3arQi8VN3Tc@public.gmane.org>; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; open list <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2] arm64: dts: ls1088a: Add USB support
-----Original Message-----
From: Shawn Guo [mailto:shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
Sent: Friday, September 22, 2017 2:55 PM
To: Yinbo Zhu <yinbo.zhu-3arQi8VN3Tc@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>; Catalin Marinas ) <catalin.marinas-5wv7dgnIgG8@public.gmane.org>; Will Deacon ) <will.deacon@arm.com>; Harninder Rai <harninder.rai-3arQi8VN3Tc@public.gmane.org>; Raghav Dogra <raghav.dogra@nxp.com>; Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>; Andy Tang <andy.tang-3arQi8VN3Tc@public.gmane.org>; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] arm64: dts: ls1088a: Add USB support
On Wed, Sep 13, 2017 at 05:10:09PM +0800, yinbo.zhu-3arQi8VN3Tc@public.gmane.org wrote:
> From: "yinbo.zhu" <yinbo.zhu-3arQi8VN3Tc@public.gmane.org>
>
> Fix the issue that usb is not detected on ls1088ardb
>It's not really about fixing issue but adding support.
The patch had been tested on upstream 4.14 code, it can fix the issue.
>
> Signed-off-by: yinbo.zhu <yinbo.zhu-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Ran Wang <ran.wang_1-3arQi8VN3Tc@public.gmane.org>
> ---
>You should better have a version history here to tell what's changed between version.
>I will add a version history on next v3 patch
Hi,
I had modified the code as v4 version,
https://patchwork.kernel.org/patch/10027393/
please check.
Thanks,
BRs
> arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 8 ++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 20 ++++++++++++++++++++
> 2 files changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> index 213abb72de93..6c3c3bc4b681 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> @@ -118,6 +118,14 @@
> status = "okay";
> };
>
> +&usb0 {
> + status = "okay";
> +};
> +
> +&usb1 {
> + status = "okay";
> +};
> +
> &esdhc {
>Please sort these labeled nodes alphabetically.
>Shawn
> status = "okay";
> };
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index c144d06a6e33..c23fede8cf5d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -359,6 +359,26 @@
> status = "disabled";
> };
>
> + usb0: usb3@3100000 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x3100000 0x0 0x10000>;
> + interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
> + dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,dis_rxdet_inp3_quirk;
> + status = "disabled";
> + };
> +
> + usb1: usb3@3110000 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x3110000 0x0 0x10000>;
> + interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
> + dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,dis_rxdet_inp3_quirk;
> + status = "disabled";
> + };
> +
> sata: sata@3200000 {
> compatible = "fsl,ls1088a-ahci";
> reg = <0x0 0x3200000 0x0 0x10000>,
> --
> 2.14.1
>
--
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 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg
From: Jagan Teki @ 2017-12-07 7:10 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Icenowy Zheng, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Michael Trimarchi, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi, Jagan Teki
In-Reply-To: <CAGb2v65OcqHSDyRowK7UKUpav_CbNtRm9DSs+_uLaZcbu6b7fg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Dec 7, 2017 at 12:31 PM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> On Thu, Dec 7, 2017 at 2:54 PM, Jagan Teki <jagannadh.teki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Thu, Dec 7, 2017 at 11:56 AM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
>>> On Thu, Dec 7, 2017 at 2:18 PM, Jagan Teki <jagannadh.teki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> On Thu, Dec 7, 2017 at 8:54 AM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
>>>>> On Thu, Dec 7, 2017 at 1:51 AM, Jagan Teki <jagannadh.teki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>> usb otg on bananapi-m64 has configured with USB-ID with PH9
>>>>>> and USB-DRVVBUS attached with dcdc1 regulatort.
>>>>>
>>>>> That is not how you read the schematic...
>>>>>
>>>>> Intersecting lines that are tied together will have a dot representing
>>>>> the connection. The DCDC1 line is a pull-up for the ID pin. This is very
>>>>> clear because it has a resistor connected in series.
>>>>>
>>>>> VBUS for OTG is controlled by the IC displayed to the right in the
>>>>> schematic, which is powered from 5V, and controlled by the DRVVBUS
>>>>> pin from the PMIC. Please take a look at how the A31/A33/A83T board
>>>>> dts files represent this.
>>>>
>>>> This is where I confused, USB-DRVVBUS is connected to pin 51 of PMIC
>>>> if we add 5v regulator how can configure gpio number for this? I saw
>>>
>>> From the axp20x bindings:
>>>
>>> - x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
>>> used as an output pin to control an external
>>> regulator to drive the OTG VBus, rather then
>>> as an input pin which signals whether the
>>> board is driving OTG VBus or not.
>>> (axp221 / axp223 / axp813 only)
>>>
>>> Setting this allows you to use the "drivevbus" regulator under the PMIC.
>>> As I said, look at how other boards are doing it.
>>>
>>>> sun8i-a33-olinuxino.dts which is also similar but it has gpio = <&pio
>>>> 1 9 GPIO_ACTIVE_HIGH>;
>>>
>>> I have no idea where you saw this. It does not exist in my tree.
>>>
>>> Why don't you just trace backwards from the usb0_vbus-supply property
>>> under the usbphy node, and see where it all leads.
>>
>> This what exactly I did, usb0_vbus-supply = <®_drivevbus>; on
>
> This is not what you did in your patch.
>
>> sun8i-a33-olinuxino.dts is using usb0-vbus from
>> sunxi-common-regulators.dtsi. reg_usb0_vbus regulator using gpio9
>> which I couldn't find it on schematics.
>
> And I'm telling you that in mainline a33-olinuxino.dts it is:
>
> usb0_vbus-supply = <®_drivevbus>;
>
> It has been that way since the initial commit adding the file.
> What tree are you looking at exactly? Take a good look at everything,
> including your patch, and stop arguing.
Sorry, you miss understand. I've seen a33-olinuxino and bananapi-m64
has similar connection in otg. Just trying to compare both and
understand what I did different in my patch. Anyway thanks for your
time I will send next version it will be worth discussing the same
there.
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* Re: [PATCH v3 2/3] clk: hisilicon: Add support for Hi3660 stub clocks
From: Stephen Boyd @ 2017-12-07 7:05 UTC (permalink / raw)
To: Xu YiPing
Cc: mturquette, robh+dt, mark.rutland, xuwei5, catalin.marinas,
will.deacon, xuejiancheng, wenpan, leo.yan, zhangfei.gao,
guodong.xu, zhongkaihua, chenjun14, linux-clk, devicetree,
linux-kernel, linux-arm-kernel, suzhuangluan, xuezhiliang,
kevin.wangtao
In-Reply-To: <1510910852-2175-3-git-send-email-xuyiping@hisilicon.com>
On 11/17, Xu YiPing wrote:
> From: Kaihua Zhong <zhongkaihua@huawei.com>
> +
> +static struct clk_hw *hi3660_stub_clk_hw_get(struct of_phandle_args *clkspec,
> + void *data)
> +{
> + unsigned int idx = clkspec->args[0];
> +
> + if (idx > HI3660_CLK_STUB_NUM) {
This should be >=
> + }
> +
> + return &hi3660_stub_clks[idx].hw;
> +}
> +
> +static int hi3660_stub_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + unsigned int i;
> + int ret;
> +
> + /* Use mailbox client without blocking */
> + stub_clk_chan.cl.dev = dev;
> + stub_clk_chan.cl.tx_done = NULL;
> + stub_clk_chan.cl.tx_block = false;
> + stub_clk_chan.cl.knows_txdone = false;
> +
> + /* Allocate mailbox channel */
> + stub_clk_chan.mbox = mbox_request_channel(&stub_clk_chan.cl, 0);
> + if (IS_ERR(stub_clk_chan.mbox))
> + return PTR_ERR(stub_clk_chan.mbox);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + freq_reg = devm_ioremap(dev, res->start, resource_size(res));
> + if (IS_ERR(freq_reg))
Pretty sure this returns NULL on failure, not an error pointer.
> + return -ENOMEM;
> +
> + freq_reg += HI3660_STUB_CLOCK_DATA;
> +
> + for (i = 0; i < HI3660_CLK_STUB_NUM; i++) {
> + ret = devm_clk_hw_register(&pdev->dev, &hi3660_stub_clks[i].hw);
> + if (ret)
> + return ret;
> + }
> +
> + ret = of_clk_add_hw_provider(pdev->dev.of_node, hi3660_stub_clk_hw_get,
> + hi3660_stub_clks);
This can use devm
> + return ret;
> +}
> +
I fixed it all and merged into clk-next.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg
From: Chen-Yu Tsai @ 2017-12-07 7:01 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Maxime Ripard, Icenowy Zheng, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, Michael Trimarchi,
linux-arm-kernel, devicetree, linux-kernel, linux-sunxi,
Jagan Teki
In-Reply-To: <CAD6G_RR-L1RH899peZgWdapyrENJC7b9-H0pNPu9+Ji93JnQ=w@mail.gmail.com>
On Thu, Dec 7, 2017 at 2:54 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> On Thu, Dec 7, 2017 at 11:56 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Thu, Dec 7, 2017 at 2:18 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> On Thu, Dec 7, 2017 at 8:54 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>>>> On Thu, Dec 7, 2017 at 1:51 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>> usb otg on bananapi-m64 has configured with USB-ID with PH9
>>>>> and USB-DRVVBUS attached with dcdc1 regulatort.
>>>>
>>>> That is not how you read the schematic...
>>>>
>>>> Intersecting lines that are tied together will have a dot representing
>>>> the connection. The DCDC1 line is a pull-up for the ID pin. This is very
>>>> clear because it has a resistor connected in series.
>>>>
>>>> VBUS for OTG is controlled by the IC displayed to the right in the
>>>> schematic, which is powered from 5V, and controlled by the DRVVBUS
>>>> pin from the PMIC. Please take a look at how the A31/A33/A83T board
>>>> dts files represent this.
>>>
>>> This is where I confused, USB-DRVVBUS is connected to pin 51 of PMIC
>>> if we add 5v regulator how can configure gpio number for this? I saw
>>
>> From the axp20x bindings:
>>
>> - x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
>> used as an output pin to control an external
>> regulator to drive the OTG VBus, rather then
>> as an input pin which signals whether the
>> board is driving OTG VBus or not.
>> (axp221 / axp223 / axp813 only)
>>
>> Setting this allows you to use the "drivevbus" regulator under the PMIC.
>> As I said, look at how other boards are doing it.
>>
>>> sun8i-a33-olinuxino.dts which is also similar but it has gpio = <&pio
>>> 1 9 GPIO_ACTIVE_HIGH>;
>>
>> I have no idea where you saw this. It does not exist in my tree.
>>
>> Why don't you just trace backwards from the usb0_vbus-supply property
>> under the usbphy node, and see where it all leads.
>
> This what exactly I did, usb0_vbus-supply = <®_drivevbus>; on
This is not what you did in your patch.
> sun8i-a33-olinuxino.dts is using usb0-vbus from
> sunxi-common-regulators.dtsi. reg_usb0_vbus regulator using gpio9
> which I couldn't find it on schematics.
And I'm telling you that in mainline a33-olinuxino.dts it is:
usb0_vbus-supply = <®_drivevbus>;
It has been that way since the initial commit adding the file.
What tree are you looking at exactly? Take a good look at everything,
including your patch, and stop arguing.
ChenYu
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clk: Hi3660: Document stub clock
From: Stephen Boyd @ 2017-12-07 7:00 UTC (permalink / raw)
To: Xu YiPing
Cc: mturquette, robh+dt, mark.rutland, xuwei5, catalin.marinas,
will.deacon, xuejiancheng, wenpan, leo.yan, zhangfei.gao,
guodong.xu, zhongkaihua, chenjun14, linux-clk, devicetree,
linux-kernel, linux-arm-kernel, suzhuangluan, xuezhiliang,
kevin.wangtao
In-Reply-To: <1510910852-2175-2-git-send-email-xuyiping@hisilicon.com>
On 11/17, Xu YiPing wrote:
> From: Leo Yan <leo.yan@linaro.org>
>
> Document the DT binding for stub clock which is used for CPU,
> GPU and DDR frequency scaling.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] usb: xhci: fix TDS for MTK xHCI1.1
From: Mathias Nyman @ 2017-12-07 6:55 UTC (permalink / raw)
To: Chunfeng Yun, Mathias Nyman
Cc: Greg Kroah-Hartman, Matthias Brugger, Felipe Balbi, linux-kernel,
linux-arm-kernel, linux-usb, linux-mediatek, devicetree
In-Reply-To: <035626be9cb863b145b02369fe517d1c80335398.1512542108.git.chunfeng.yun@mediatek.com>
On 06.12.2017 08:42, Chunfeng Yun wrote:
> For MTK's xHCI 1.0 or latter, TD size is the number of max
> packet sized packets remaining in the TD, not including
> this TRB (following spec).
>
> For MTK's xHCI 0.96 and older, TD size is the number of max
> packet sized packets remaining in the TD, including this TRB
> (not following spec).
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> drivers/usb/host/xhci-ring.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index c239c68..0619869 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -3108,7 +3108,7 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, int transferred,
> {
> u32 maxp, total_packet_count;
>
> - /* MTK xHCI is mostly 0.97 but contains some features from 1.0 */
> + /* MTK xHCI 0.96 contains some features from 1.0 */
> if (xhci->hci_version < 0x100 && !(xhci->quirks & XHCI_MTK_HOST))
> return ((td_total_len - transferred) >> 10);
>
> @@ -3117,8 +3117,8 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, int transferred,
> trb_buff_len == td_total_len)
> return 0;
>
> - /* for MTK xHCI, TD size doesn't include this TRB */
> - if (xhci->quirks & XHCI_MTK_HOST)
> + /* for MTK xHCI 0.96, TD size include this TRB, but not in 1.x */
> + if ((xhci->quirks & XHCI_MTK_HOST) && (xhci->hci_version < 0x100))
> trb_buff_len = 0;
>
> maxp = usb_endpoint_maxp(&urb->ep->desc);
>
Thanks, adding.
Adding stable tag as well
-Mathias
^ permalink raw reply
* Re: [PATCH 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg
From: Jagan Teki @ 2017-12-07 6:54 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Icenowy Zheng, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Michael Trimarchi, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi, Jagan Teki
In-Reply-To: <CAGb2v67dh=dfPKdDOwfj8m7qmUk-=s4kXS3FvZLczskrjbr7eQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]
On Thu, Dec 7, 2017 at 11:56 AM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> On Thu, Dec 7, 2017 at 2:18 PM, Jagan Teki <jagannadh.teki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Thu, Dec 7, 2017 at 8:54 AM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
>>> On Thu, Dec 7, 2017 at 1:51 AM, Jagan Teki <jagannadh.teki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> usb otg on bananapi-m64 has configured with USB-ID with PH9
>>>> and USB-DRVVBUS attached with dcdc1 regulatort.
>>>
>>> That is not how you read the schematic...
>>>
>>> Intersecting lines that are tied together will have a dot representing
>>> the connection. The DCDC1 line is a pull-up for the ID pin. This is very
>>> clear because it has a resistor connected in series.
>>>
>>> VBUS for OTG is controlled by the IC displayed to the right in the
>>> schematic, which is powered from 5V, and controlled by the DRVVBUS
>>> pin from the PMIC. Please take a look at how the A31/A33/A83T board
>>> dts files represent this.
>>
>> This is where I confused, USB-DRVVBUS is connected to pin 51 of PMIC
>> if we add 5v regulator how can configure gpio number for this? I saw
>
> From the axp20x bindings:
>
> - x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
> used as an output pin to control an external
> regulator to drive the OTG VBus, rather then
> as an input pin which signals whether the
> board is driving OTG VBus or not.
> (axp221 / axp223 / axp813 only)
>
> Setting this allows you to use the "drivevbus" regulator under the PMIC.
> As I said, look at how other boards are doing it.
>
>> sun8i-a33-olinuxino.dts which is also similar but it has gpio = <&pio
>> 1 9 GPIO_ACTIVE_HIGH>;
>
> I have no idea where you saw this. It does not exist in my tree.
>
> Why don't you just trace backwards from the usb0_vbus-supply property
> under the usbphy node, and see where it all leads.
This what exactly I did, usb0_vbus-supply = <®_drivevbus>; on
sun8i-a33-olinuxino.dts is using usb0-vbus from
sunxi-common-regulators.dtsi. reg_usb0_vbus regulator using gpio9
which I couldn't find it on schematics.
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: A33-OLinuXino_Rev_B1.pdf --]
[-- Type: application/pdf, Size: 134086 bytes --]
^ permalink raw reply
* Re: [PATCH V6 02/12] clk: sprd: Add common infrastructure
From: Stephen Boyd @ 2017-12-07 6:50 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk, linux-kernel, devicetree,
linux-arm-kernel, Arnd Bergmann, Mark Brown, Xiaolong Zhang,
Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171127100115.20655-3-chunyan.zhang@spreadtrum.com>
On 11/27, Chunyan Zhang wrote:
> +
> + sprd_clk_set_regmap(desc, regmap);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(sprd_clk_regmap_init);
> +
> +int sprd_clk_probe(struct device *dev, struct clk_hw_onecell_data *clkhw)
> +{
> + int i, ret = 0;
ret shouldn't need to be initialized here.
> + struct clk_hw *hw;
> +
> + for (i = 0; i < clkhw->num; i++) {
> +
> + hw = clkhw->hws[i];
> +
> + if (!hw)
> + continue;
> +
> + ret = devm_clk_hw_register(dev, hw);
> + if (ret) {
> + dev_err(dev, "Couldn't register clock %d - %s\n",
> + i, hw->init->name);
> + return ret;
> + }
> + }
> +
> + ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get,
> + clkhw);
You can use devm_ now for this.
> + if (ret)
> + dev_err(dev, "Failed to add clock provider.\n");
Please remove the full stop on error messages.
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(sprd_clk_probe);
> +
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/clk/sprd/common.h b/drivers/clk/sprd/common.h
> new file mode 100644
> index 0000000..8cd774e
> --- /dev/null
> +++ b/drivers/clk/sprd/common.h
> @@ -0,0 +1,52 @@
> +/*
> + * Spreadtrum clock infrastructure
> + *
> + * Copyright (C) 2017 Spreadtrum, Inc.
> + * Author: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
> +#ifndef _SPRD_CLK_COMMON_H_
> +#define _SPRD_CLK_COMMON_H_
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of_platform.h>
> +#include <linux/regmap.h>
> +
> +#include "../clk_common.h"
> +
> +struct device_node;
> +
> +struct sprd_clk_common {
> + struct regmap *regmap;
> + u32 reg;
> + struct clk_hw hw;
> +};
> +
> +struct sprd_clk_desc {
> + struct sprd_clk_common **clk_clks;
> + unsigned long num_clk_clks;
> + struct clk_hw_onecell_data *hw_clks;
> +};
> +
> +#define sprd_regmap_read(map, reg, val) \
> +({ \
> + (map) ? regmap_read((map), (reg), (val)) : (-EINVAL); \
Do we sometimes not have a map? This seems overly cautious.
> +})
> +
> +#define sprd_regmap_write(map, reg, val) \
> +({ \
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V6 01/12] drivers: move clock common macros out from vendor directories
From: Stephen Boyd @ 2017-12-07 6:47 UTC (permalink / raw)
To: Chunyan Zhang
Cc: Michael Turquette, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-clk, linux-kernel, devicetree,
linux-arm-kernel, Arnd Bergmann, Mark Brown, Xiaolong Zhang,
Ben Li, Orson Zhai, Chunyan Zhang
In-Reply-To: <20171127100115.20655-2-chunyan.zhang@spreadtrum.com>
On 11/27, Chunyan Zhang wrote:
> These macros are used by more than one SoC vendor platforms, avoid to
> have many copies of these code, this patch moves them to the common
> clock directory which every clock drivers can access to.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
> drivers/clk/clk_common.h | 60 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 60 insertions(+)
> create mode 100644 drivers/clk/clk_common.h
>
> diff --git a/drivers/clk/clk_common.h b/drivers/clk/clk_common.h
> new file mode 100644
> index 0000000..21e93d2
> --- /dev/null
> +++ b/drivers/clk/clk_common.h
> @@ -0,0 +1,60 @@
> +/*
> + * drivers/clk/clk_common.h
We don't need this in the file too. Please remove this line.
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
> +#ifndef _CLK_COMMON_H_
> +#define _CLK_COMMON_H_
> +
> +#include <linux/clk-provider.h>
Maybe these macros should just go into clk-provider.h?
> +
> +#define CLK_HW_INIT(_name, _parent, _ops, _flags) \
> + (&(struct clk_init_data) { \
> + .flags = _flags, \
> + .name = _name, \
> + .parent_names = (const char *[]) { _parent }, \
> + .num_parents = 1, \
> + .ops = _ops, \
> + })
Hopefully we don't extend the init structure anymore to have
something else. I guess we'll do something if that happens.
> +
> +#define CLK_HW_INIT_PARENTS(_name, _parents, _ops, _flags) \
> + (&(struct clk_init_data) { \
> + .flags = _flags, \
> + .name = _name, \
> + .parent_names = _parents, \
> + .num_parents = ARRAY_SIZE(_parents), \
> + .ops = _ops, \
> + })
> +
> +#define CLK_HW_INIT_NO_PARENT(_name, _ops, _flags) \
> + (&(struct clk_init_data) { \
> + .flags = _flags, \
> + .name = _name, \
> + .parent_names = NULL, \
> + .num_parents = 0, \
> + .ops = _ops, \
> + })
> +
> +#define CLK_FIXED_FACTOR(_struct, _name, _parent, \
> + _div, _mult, _flags) \
> + struct clk_fixed_factor _struct = { \
> + .div = _div, \
> + .mult = _mult, \
> + .hw.init = CLK_HW_INIT(_name, \
> + _parent, \
> + &clk_fixed_factor_ops, \
> + _flags), \
> + }
> +
> +#define CLK_FIXED_RATE(_struct, _name, _flags, \
> + _fixed_rate, _fixed_accuracy) \
> + struct clk_fixed_rate _struct = { \
> + .fixed_rate = _fixed_rate, \
> + .fixed_accuracy = _fixed_accuracy, \
> + .hw.init = CLK_HW_INIT_NO_PARENT(_name, \
> + &clk_fixed_rate_ops, \
> + _flags), \
> + }
Maybe don't add this one? Usually fixed rate clks come from DT.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 3/3] arm: dts: mt7623: fix card detection issue on bananapi-r2
From: sean.wang @ 2017-12-07 6:43 UTC (permalink / raw)
To: robh+dt, matthias.bgg, mark.rutland, devicetree, linux-mediatek
Cc: linux-arm-kernel, linux-kernel, Sean Wang, stable
In-Reply-To: <cover.1512628593.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Fix that bananapi-r2 booting from SD-card would fail since incorrect
polarity is applied to the previous setup with GPIO_ACTIVE_HIGH.
Cc: stable@vger.kernel.org
Fixes: 0eed8d097612 ("arm: dts: mt7623: Add SD-card and EMMC to bananapi-r2")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Tested-by: Matthias Brugger <matthias.bgg@gmail.com>
---
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 688a863..7bf5aa2 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -204,7 +204,7 @@
bus-width = <4>;
max-frequency = <50000000>;
cap-sd-highspeed;
- cd-gpios = <&pio 261 0>;
+ cd-gpios = <&pio 261 GPIO_ACTIVE_LOW>;
vmmc-supply = <&mt6323_vmch_reg>;
vqmmc-supply = <&mt6323_vio18_reg>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] arm: dts: mt7623: update mmc related nodes with the appropriate fallback
From: sean.wang @ 2017-12-07 6:43 UTC (permalink / raw)
To: robh+dt, matthias.bgg, mark.rutland, devicetree, linux-mediatek
Cc: linux-arm-kernel, linux-kernel, Sean Wang
In-Reply-To: <cover.1512628593.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
The current mmc related nodes should be falling back to MT2701
as the dt-binding defines and which has more appropriate setup
for MT7623.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
arch/arm/boot/dts/mt7623.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 0640fb7..343d3b1 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -641,7 +641,7 @@
mmc0: mmc@11230000 {
compatible = "mediatek,mt7623-mmc",
- "mediatek,mt8135-mmc";
+ "mediatek,mt2701-mmc";
reg = <0 0x11230000 0 0x1000>;
interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_LOW>;
clocks = <&pericfg CLK_PERI_MSDC30_0>,
@@ -652,7 +652,7 @@
mmc1: mmc@11240000 {
compatible = "mediatek,mt7623-mmc",
- "mediatek,mt8135-mmc";
+ "mediatek,mt2701-mmc";
reg = <0 0x11240000 0 0x1000>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_LOW>;
clocks = <&pericfg CLK_PERI_MSDC30_1>,
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/3] mmc: dt-bindings: add mmc support to MT7623 SoC
From: sean.wang @ 2017-12-07 6:43 UTC (permalink / raw)
To: robh+dt, matthias.bgg, mark.rutland, devicetree, linux-mediatek
Cc: linux-arm-kernel, linux-kernel, Sean Wang
In-Reply-To: <cover.1512628593.git.sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Add the devicetree binding for MT7623 SoC using MT2701 as the fallback.
Cc: devicetree@vger.kernel.org
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/mmc/mtk-sd.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index 72d2a73..9b80176 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -12,6 +12,8 @@ Required properties:
"mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
"mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
"mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
+ "mediatek,mt7623-mmc", "mediatek,mt2701-mmc": for MT7623 SoC
+
- reg: physical base address of the controller and length
- interrupts: Should contain MSDC interrupt number
- clocks: Should contain phandle for the clock feeding the MMC controller
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/3] Misc fixes up for MT7623 mmc
From: sean.wang @ 2017-12-07 6:43 UTC (permalink / raw)
To: robh+dt, matthias.bgg, mark.rutland, devicetree, linux-mediatek
Cc: linux-arm-kernel, linux-kernel, Sean Wang
From: Sean Wang <sean.wang@mediatek.com>
Changes since v1:
- add tag from the feedback of v1
- enhance dt-binding documentation
Just add some fixes up for the current MT7623 support
Patch 1) complement the missing dt-bindings definitions
Patch 2) pick up the proper falling back as patch 1 defines.
Patch 3) SD-card detection issue caused by the wrong polarity is being fixed up
Sean Wang (3):
mmc: dt-bindings: add mmc support to MT7623 SoC
arm: dts: mt7623: update mmc related nodes with the appropriate
fallback
arm: dts: mt7623: fix card detection issue on bananapi-r2
Documentation/devicetree/bindings/mmc/mtk-sd.txt | 2 ++
arch/arm/boot/dts/mt7623.dtsi | 4 ++--
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH V7 1/2] clk: qcom: Add spmi_pmic clock divider support
From: Stephen Boyd @ 2017-12-07 6:32 UTC (permalink / raw)
To: Tirupathi Reddy
Cc: robh+dt, mturquette, mark.rutland, andy.gross, david.brown,
linux-clk, devicetree, linux-kernel, linux-arm-msm, linux-soc
In-Reply-To: <1511255465-3984-2-git-send-email-tirupath@codeaurora.org>
On 11/21, Tirupathi Reddy wrote:
> Clkdiv module provides a clock output on the PMIC with CXO as
> the source. This clock can be routed through PMIC GPIOs. Add
> a device driver to configure this clkdiv module.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V7 2/2] dt-bindings: Add qcom spmi_pmic clock divider bindings
From: Stephen Boyd @ 2017-12-07 6:32 UTC (permalink / raw)
To: Tirupathi Reddy
Cc: robh+dt, mturquette, mark.rutland, andy.gross, david.brown,
linux-clk, devicetree, linux-kernel, linux-arm-msm, linux-soc
In-Reply-To: <1511255465-3984-3-git-send-email-tirupath@codeaurora.org>
On 11/21, Tirupathi Reddy wrote:
> This patch adds device tree bindings for Qualcomm SPMI PMIC
> clock divider module.
>
> Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V7 2/2] dt-bindings: Add qcom spmi_pmic clock divider bindings
From: Stephen Boyd @ 2017-12-07 6:28 UTC (permalink / raw)
To: Rob Herring
Cc: Tirupathi Reddy, mturquette, mark.rutland, andy.gross,
david.brown, linux-clk, devicetree, linux-kernel, linux-arm-msm,
linux-soc
In-Reply-To: <20171204202959.6gxmy7jdt7gwspuh@rob-hp-laptop>
On 12/04, Rob Herring wrote:
> On Tue, Nov 21, 2017 at 02:41:05PM +0530, Tirupathi Reddy wrote:
> > This patch adds device tree bindings for Qualcomm SPMI PMIC
> > clock divider module.
> >
> > Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
> > ---
> > .../bindings/clock/qcom,spmi-pmic-div.txt | 59 ++++++++++++++++++++++
>
> Didn't Stephen say to move this somewhere else?
yeah I'll move it to qcom,spmi-clkdiv.txt
> > +
> > +- clock-cells:
>
> #clock-cells
>
And fix this. Thanks.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg
From: Chen-Yu Tsai @ 2017-12-07 6:26 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Maxime Ripard, Icenowy Zheng, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, Michael Trimarchi,
linux-arm-kernel, devicetree, linux-kernel, linux-sunxi,
Jagan Teki
In-Reply-To: <CAD6G_RR-VccHjdrXs55=C50OvDEr96c7axtbR0eKp2THFNx6sg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Dec 7, 2017 at 2:18 PM, Jagan Teki <jagannadh.teki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Dec 7, 2017 at 8:54 AM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
>> On Thu, Dec 7, 2017 at 1:51 AM, Jagan Teki <jagannadh.teki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> usb otg on bananapi-m64 has configured with USB-ID with PH9
>>> and USB-DRVVBUS attached with dcdc1 regulatort.
>>
>> That is not how you read the schematic...
>>
>> Intersecting lines that are tied together will have a dot representing
>> the connection. The DCDC1 line is a pull-up for the ID pin. This is very
>> clear because it has a resistor connected in series.
>>
>> VBUS for OTG is controlled by the IC displayed to the right in the
>> schematic, which is powered from 5V, and controlled by the DRVVBUS
>> pin from the PMIC. Please take a look at how the A31/A33/A83T board
>> dts files represent this.
>
> This is where I confused, USB-DRVVBUS is connected to pin 51 of PMIC
> if we add 5v regulator how can configure gpio number for this? I saw
>From the axp20x bindings:
- x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
used as an output pin to control an external
regulator to drive the OTG VBus, rather then
as an input pin which signals whether the
board is driving OTG VBus or not.
(axp221 / axp223 / axp813 only)
Setting this allows you to use the "drivevbus" regulator under the PMIC.
As I said, look at how other boards are doing it.
> sun8i-a33-olinuxino.dts which is also similar but it has gpio = <&pio
> 1 9 GPIO_ACTIVE_HIGH>;
I have no idea where you saw this. It does not exist in my tree.
Why don't you just trace backwards from the usb0_vbus-supply property
under the usbphy node, and see where it all leads.
ChenYu
^ permalink raw reply
* Re: [PATCH 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg
From: Jagan Teki @ 2017-12-07 6:18 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Icenowy Zheng, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Michael Trimarchi, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi, Jagan Teki
In-Reply-To: <CAGb2v67uFnV+m1Ub7rFVGhkv0HKD4ukpQFtJ1pqRi2vf4F=tFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Dec 7, 2017 at 8:54 AM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> On Thu, Dec 7, 2017 at 1:51 AM, Jagan Teki <jagannadh.teki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> usb otg on bananapi-m64 has configured with USB-ID with PH9
>> and USB-DRVVBUS attached with dcdc1 regulatort.
>
> That is not how you read the schematic...
>
> Intersecting lines that are tied together will have a dot representing
> the connection. The DCDC1 line is a pull-up for the ID pin. This is very
> clear because it has a resistor connected in series.
>
> VBUS for OTG is controlled by the IC displayed to the right in the
> schematic, which is powered from 5V, and controlled by the DRVVBUS
> pin from the PMIC. Please take a look at how the A31/A33/A83T board
> dts files represent this.
This is where I confused, USB-DRVVBUS is connected to pin 51 of PMIC
if we add 5v regulator how can configure gpio number for this? I saw
sun8i-a33-olinuxino.dts which is also similar but it has gpio = <&pio
1 9 GPIO_ACTIVE_HIGH>;
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* Re: [PATCH v3 08/15] drm/sun4i: Add LVDS support
From: Chen-Yu Tsai @ 2017-12-07 6:05 UTC (permalink / raw)
To: Maxime Ripard
Cc: Daniel Vetter, David Airlie, Chen-Yu Tsai, dri-devel,
linux-kernel, Mark Rutland, Rob Herring, linux-arm-kernel,
Priit Laes, Icenowy Zheng, Thomas Petazzoni, Jernej Skrabec,
devicetree
In-Reply-To: <b900e5963180c94ca02bde178b6674622a127787.1512486553.git-series.maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Dec 5, 2017 at 11:10 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> The TCON supports the LVDS interface to output to a panel or a bridge.
> Let's add support for it.
>
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> drivers/gpu/drm/sun4i/Makefile | 1 +-
> drivers/gpu/drm/sun4i/sun4i_lvds.c | 183 +++++++++++++++++++++++-
> drivers/gpu/drm/sun4i/sun4i_lvds.h | 18 ++-
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 238 +++++++++++++++++++++++++++++-
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 29 ++++-
> 5 files changed, 467 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h
>
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 82a6ac57fbe3..2b37a6abbb1d 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -15,6 +15,7 @@ sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
>
> sun4i-tcon-y += sun4i_crtc.o
> sun4i-tcon-y += sun4i_dotclock.o
> +sun4i-tcon-y += sun4i_lvds.o
> sun4i-tcon-y += sun4i_tcon.o
> sun4i-tcon-y += sun4i_rgb.o
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> new file mode 100644
> index 000000000000..635a3f505ecb
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright (C) 2015 NextThing Co
> + * Copyright (C) 2015-2017 Free Electrons
> + *
> + * Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include <linux/clk.h>
> +
> +#include <drm/drmP.h>
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_of.h>
> +#include <drm/drm_panel.h>
> +
> +#include "sun4i_crtc.h"
> +#include "sun4i_tcon.h"
> +#include "sun4i_lvds.h"
> +
> +struct sun4i_lvds {
> + struct drm_connector connector;
> + struct drm_encoder encoder;
> +
> + struct sun4i_tcon *tcon;
> +};
> +
> +static inline struct sun4i_lvds *
> +drm_connector_to_sun4i_lvds(struct drm_connector *connector)
> +{
> + return container_of(connector, struct sun4i_lvds,
> + connector);
> +}
> +
> +static inline struct sun4i_lvds *
> +drm_encoder_to_sun4i_lvds(struct drm_encoder *encoder)
> +{
> + return container_of(encoder, struct sun4i_lvds,
> + encoder);
> +}
> +
> +static int sun4i_lvds_get_modes(struct drm_connector *connector)
> +{
> + struct sun4i_lvds *lvds =
> + drm_connector_to_sun4i_lvds(connector);
> + struct sun4i_tcon *tcon = lvds->tcon;
> +
> + return drm_panel_get_modes(tcon->panel);
> +}
> +
> +static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
> + .get_modes = sun4i_lvds_get_modes,
> +};
> +
> +static void
> +sun4i_lvds_connector_destroy(struct drm_connector *connector)
> +{
> + struct sun4i_lvds *lvds = drm_connector_to_sun4i_lvds(connector);
> + struct sun4i_tcon *tcon = lvds->tcon;
> +
> + drm_panel_detach(tcon->panel);
> + drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs sun4i_lvds_con_funcs = {
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy = sun4i_lvds_connector_destroy,
> + .reset = drm_atomic_helper_connector_reset,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static void sun4i_lvds_encoder_enable(struct drm_encoder *encoder)
> +{
> + struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
> + struct sun4i_tcon *tcon = lvds->tcon;
> +
> + DRM_DEBUG_DRIVER("Enabling LVDS output\n");
> +
> + if (!IS_ERR(tcon->panel)) {
> + drm_panel_prepare(tcon->panel);
> + drm_panel_enable(tcon->panel);
> + }
> +}
> +
> +static void sun4i_lvds_encoder_disable(struct drm_encoder *encoder)
> +{
> + struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
> + struct sun4i_tcon *tcon = lvds->tcon;
> +
> + DRM_DEBUG_DRIVER("Disabling LVDS output\n");
> +
> + if (!IS_ERR(tcon->panel)) {
> + drm_panel_disable(tcon->panel);
> + drm_panel_unprepare(tcon->panel);
> + }
> +}
> +
> +static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
> + .disable = sun4i_lvds_encoder_disable,
> + .enable = sun4i_lvds_encoder_enable,
> +};
> +
> +static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
> + .destroy = drm_encoder_cleanup,
> +};
> +
> +int sun4i_lvds_init(struct drm_device *drm, struct sun4i_tcon *tcon)
> +{
> + struct drm_encoder *encoder;
> + struct drm_bridge *bridge;
> + struct sun4i_lvds *lvds;
> + int ret;
> +
> + lvds = devm_kzalloc(drm->dev, sizeof(*lvds), GFP_KERNEL);
> + if (!lvds)
> + return -ENOMEM;
> + lvds->tcon = tcon;
> + encoder = &lvds->encoder;
> +
> + ret = drm_of_find_panel_or_bridge(tcon->dev->of_node, 1, 0,
> + &tcon->panel, &bridge);
> + if (ret) {
> + dev_info(drm->dev, "No panel or bridge found... LVDS output disabled\n");
> + return 0;
> + }
> +
> + drm_encoder_helper_add(&lvds->encoder,
> + &sun4i_lvds_enc_helper_funcs);
> + ret = drm_encoder_init(drm,
> + &lvds->encoder,
> + &sun4i_lvds_enc_funcs,
> + DRM_MODE_ENCODER_LVDS,
> + NULL);
> + if (ret) {
> + dev_err(drm->dev, "Couldn't initialise the lvds encoder\n");
> + goto err_out;
> + }
> +
> + /* The LVDS encoder can only work with the TCON channel 0 */
> + lvds->encoder.possible_crtcs = BIT(drm_crtc_index(&tcon->crtc->crtc));
> +
> + if (tcon->panel) {
> + drm_connector_helper_add(&lvds->connector,
> + &sun4i_lvds_con_helper_funcs);
> + ret = drm_connector_init(drm, &lvds->connector,
> + &sun4i_lvds_con_funcs,
> + DRM_MODE_CONNECTOR_LVDS);
> + if (ret) {
> + dev_err(drm->dev, "Couldn't initialise the lvds connector\n");
> + goto err_cleanup_connector;
> + }
> +
> + drm_mode_connector_attach_encoder(&lvds->connector,
> + &lvds->encoder);
> +
> + ret = drm_panel_attach(tcon->panel, &lvds->connector);
> + if (ret) {
> + dev_err(drm->dev, "Couldn't attach our panel\n");
> + goto err_cleanup_connector;
> + }
> + }
> +
> + if (bridge) {
> + ret = drm_bridge_attach(encoder, bridge, NULL);
> + if (ret) {
> + dev_err(drm->dev, "Couldn't attach our bridge\n");
> + goto err_cleanup_connector;
> + }
> + }
> +
> + return 0;
> +
> +err_cleanup_connector:
> + drm_encoder_cleanup(&lvds->encoder);
> +err_out:
> + return ret;
> +}
> +EXPORT_SYMBOL(sun4i_lvds_init);
> diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.h b/drivers/gpu/drm/sun4i/sun4i_lvds.h
> new file mode 100644
> index 000000000000..1b8fad4b82c3
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.h
> @@ -0,0 +1,18 @@
> +/*
> + * Copyright (C) 2015 NextThing Co
> + * Copyright (C) 2015-2017 Free Electrons
> + *
> + * Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#ifndef _SUN4I_LVDS_H_
> +#define _SUN4I_LVDS_H_
> +
> +int sun4i_lvds_init(struct drm_device *drm, struct sun4i_tcon *tcon);
> +
> +#endif /* _SUN4I_LVDS_H_ */
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 46e28ca1f676..92f4738101e6 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -31,10 +31,52 @@
> #include "sun4i_crtc.h"
> #include "sun4i_dotclock.h"
> #include "sun4i_drv.h"
> +#include "sun4i_lvds.h"
> #include "sun4i_rgb.h"
> #include "sun4i_tcon.h"
> #include "sunxi_engine.h"
>
> +static struct drm_connector *sun4i_tcon_get_connector(const struct drm_encoder *encoder)
> +{
> + struct drm_connector *connector;
> + struct drm_connector_list_iter iter;
> +
> + drm_connector_list_iter_begin(encoder->dev, &iter);
> + drm_for_each_connector_iter(connector, &iter)
> + if (connector->encoder == encoder) {
> + drm_connector_list_iter_end(&iter);
> + return connector;
> + }
> + drm_connector_list_iter_end(&iter);
> +
> + return NULL;
> +}
> +
> +static int sun4i_tcon_get_pixel_depth(const struct drm_encoder *encoder)
> +{
> + struct drm_connector *connector;
> + struct drm_display_info *info;
> +
> + connector = sun4i_tcon_get_connector(encoder);
> + if (!connector)
> + return -EINVAL;
> +
> + info = &connector->display_info;
> + if (info->num_bus_formats != 1)
> + return -EINVAL;
> +
> + switch (info->bus_formats[0]) {
> + case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
> + return 18;
> +
> + case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
> + case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
> + return 24;
> + }
> +
> + return -EINVAL;
> +}
> +
> static void sun4i_tcon_channel_set_status(struct sun4i_tcon *tcon, int channel,
> bool enabled)
> {
> @@ -65,13 +107,58 @@ static void sun4i_tcon_channel_set_status(struct sun4i_tcon *tcon, int channel,
> clk_disable_unprepare(clk);
> }
>
> +static void sun4i_tcon_lvds_set_status(struct sun4i_tcon *tcon,
> + const struct drm_encoder *encoder,
> + bool enabled)
> +{
> + if (enabled) {
> + u8 val;
> +
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_IF_REG,
> + SUN4I_TCON0_LVDS_IF_EN,
> + SUN4I_TCON0_LVDS_IF_EN);
> +
> + regmap_write(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
> + SUN4I_TCON0_LVDS_ANA0_C(2) |
> + SUN4I_TCON0_LVDS_ANA0_V(3) |
> + SUN4I_TCON0_LVDS_ANA0_PD(2) |
> + SUN4I_TCON0_LVDS_ANA0_EN_LDO);
> + udelay(2);
> +
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
> + SUN4I_TCON0_LVDS_ANA0_EN_MB,
> + SUN4I_TCON0_LVDS_ANA0_EN_MB);
> + udelay(2);
> +
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
> + SUN4I_TCON0_LVDS_ANA0_EN_DRVC,
> + SUN4I_TCON0_LVDS_ANA0_EN_DRVC);
> +
> + if (sun4i_tcon_get_pixel_depth(encoder) == 18)
> + val = 7;
> + else
> + val = 0xf;
> +
> + regmap_write_bits(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
> + SUN4I_TCON0_LVDS_ANA0_EN_DRVD(0xf),
> + SUN4I_TCON0_LVDS_ANA0_EN_DRVD(val));
I suggest changing the prefix of the macros of the analog bits to
SUN6I_TCON0_*. The register definitions and sequence do not apply
to the A10/A20. Furthermore you should add a comment saying this
doesn't apply to the A10/A20. In the future we might want to move
this part into a separate function, referenced by a function pointer
from the quirks structure.
> + } else {
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_IF_REG,
> + SUN4I_TCON0_LVDS_IF_EN, 0);
> + }
> +}
> +
> void sun4i_tcon_set_status(struct sun4i_tcon *tcon,
> const struct drm_encoder *encoder,
> bool enabled)
> {
> + bool is_lvds = false;
> int channel;
>
> switch (encoder->encoder_type) {
> + case DRM_MODE_ENCODER_LVDS:
> + is_lvds = true;
> + /* Fallthrough */
> case DRM_MODE_ENCODER_NONE:
> channel = 0;
> break;
> @@ -84,10 +171,16 @@ void sun4i_tcon_set_status(struct sun4i_tcon *tcon,
> return;
> }
>
> + if (is_lvds && !enabled)
> + sun4i_tcon_lvds_set_status(tcon, encoder, false);
> +
> regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
> SUN4I_TCON_GCTL_TCON_ENABLE,
> enabled ? SUN4I_TCON_GCTL_TCON_ENABLE : 0);
>
> + if (is_lvds && enabled)
> + sun4i_tcon_lvds_set_status(tcon, encoder, true);
> +
> sun4i_tcon_channel_set_status(tcon, channel, enabled);
> }
>
> @@ -170,6 +263,78 @@ static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
> }
>
> +static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon *tcon,
> + const struct drm_encoder *encoder,
> + const struct drm_display_mode *mode)
> +{
> + unsigned int bp;
> + u8 clk_delay;
> + u32 reg, val = 0;
> +
> + tcon->dclk_min_div = 7;
> + tcon->dclk_max_div = 7;
> + sun4i_tcon0_mode_set_common(tcon, mode);
> +
> + /* Adjust clock delay */
> + clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
> + SUN4I_TCON0_CTL_CLK_DELAY_MASK,
> + SUN4I_TCON0_CTL_CLK_DELAY(clk_delay));
> +
> + /*
> + * This is called a backporch in the register documentation,
> + * but it really is the back porch + hsync
> + */
> + bp = mode->crtc_htotal - mode->crtc_hsync_start;
> + DRM_DEBUG_DRIVER("Setting horizontal total %d, backporch %d\n",
> + mode->crtc_htotal, bp);
> +
> + /* Set horizontal display timings */
> + regmap_write(tcon->regs, SUN4I_TCON0_BASIC1_REG,
> + SUN4I_TCON0_BASIC1_H_TOTAL(mode->htotal) |
> + SUN4I_TCON0_BASIC1_H_BACKPORCH(bp));
> +
> + /*
> + * This is called a backporch in the register documentation,
> + * but it really is the back porch + hsync
> + */
> + bp = mode->crtc_vtotal - mode->crtc_vsync_start;
> + DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
> + mode->crtc_vtotal, bp);
> +
> + /* Set vertical display timings */
> + regmap_write(tcon->regs, SUN4I_TCON0_BASIC2_REG,
> + SUN4I_TCON0_BASIC2_V_TOTAL(mode->crtc_vtotal * 2) |
> + SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
> +
Can we move the above to a common function?
> + reg = SUN4I_TCON0_LVDS_IF_CLK_SEL_TCON0 |
> + SUN4I_TCON0_LVDS_IF_DATA_POL_NORMAL |
> + SUN4I_TCON0_LVDS_IF_CLK_POL_NORMAL;
> + if (sun4i_tcon_get_pixel_depth(encoder) == 24)
> + reg |= SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS;
> + else
> + reg |= SUN4I_TCON0_LVDS_IF_BITWIDTH_18BITS;
> +
> + regmap_write(tcon->regs, SUN4I_TCON0_LVDS_IF_REG, reg);
> +
> + /* Setup the polarity of the various signals */
> + if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
> + val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> +
> + if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
> + val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> +
> + regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG, val);
> +
> + /* Map output pins to channel 0 */
> + regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
> + SUN4I_TCON_GCTL_IOMAP_MASK,
> + SUN4I_TCON_GCTL_IOMAP_TCON0);
> +
> + /* Enable the output on the pins */
> + regmap_write(tcon->regs, SUN4I_TCON0_IO_TRI_REG, 0xe0000000);
Is this still needed? You are no longer using the TCON LCD pins
with LVDS.
> +}
> +
> static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
> const struct drm_display_mode *mode)
> {
> @@ -336,6 +501,9 @@ void sun4i_tcon_mode_set(struct sun4i_tcon *tcon,
> const struct drm_display_mode *mode)
> {
> switch (encoder->encoder_type) {
> + case DRM_MODE_ENCODER_LVDS:
> + sun4i_tcon0_mode_set_lvds(tcon, encoder, mode);
> + break;
> case DRM_MODE_ENCODER_NONE:
> sun4i_tcon0_mode_set_rgb(tcon, mode);
> sun4i_tcon_set_mux(tcon, 0, encoder);
> @@ -667,7 +835,9 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
> struct drm_device *drm = data;
> struct sun4i_drv *drv = drm->dev_private;
> struct sunxi_engine *engine;
> + struct device_node *remote;
> struct sun4i_tcon *tcon;
> + bool has_lvds_rst, has_lvds_pll, can_lvds;
> int ret;
>
> engine = sun4i_tcon_find_engine(drv, dev->of_node);
> @@ -698,6 +868,54 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
> return ret;
> }
>
> + /*
> + * This can only be made optional since we've had DT nodes
> + * without the LVDS reset properties.
> + *
> + * If the property is missing, just disable LVDS, and print a
> + * warning.
> + */
> + tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
> + if (IS_ERR(tcon->lvds_rst)) {
> + dev_err(dev, "Couldn't get our reset line\n");
> + return PTR_ERR(tcon->lvds_rst);
> + } else if (tcon->lvds_rst) {
> + has_lvds_rst = true;
> + reset_control_reset(tcon->lvds_rst);
> + } else {
> + has_lvds_rst = false;
> + }
> +
> + /*
> + * This can only be made optional since we've had DT nodes
> + * without the LVDS reset properties.
> + *
> + * If the property is missing, just disable LVDS, and print a
> + * warning.
> + */
> + if (tcon->quirks->has_lvds_pll) {
> + tcon->lvds_pll = devm_clk_get(dev, "pll-lvds");
> + if (IS_ERR(tcon->lvds_pll)) {
> + if (PTR_ERR(tcon->lvds_pll) == -ENOENT) {
> + has_lvds_pll = false;
> + } else {
> + dev_err(dev, "Couldn't get the LVDS PLL\n");
> + return PTR_ERR(tcon->lvds_rst);
> + }
> + } else {
> + has_lvds_pll = true;
> + }
> + }
> +
> + if (!has_lvds_rst || (tcon->quirks->has_lvds_pll && !has_lvds_pll)) {
> + dev_warn(dev,
> + "Missing LVDS properties, Please upgrade your DT\n");
> + dev_warn(dev, "LVDS output disabled\n");
> + can_lvds = false;
> + } else {
> + can_lvds = true;
> + }
> +
> ret = sun4i_tcon_init_clocks(dev, tcon);
> if (ret) {
> dev_err(dev, "Couldn't init our TCON clocks\n");
> @@ -729,7 +947,21 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
> goto err_free_dotclock;
> }
>
> - ret = sun4i_rgb_init(drm, tcon);
> + /*
> + * If we have an LVDS panel connected to the TCON, we should
> + * just probe the LVDS connector. Otherwise, just probe RGB as
> + * we used to.
> + */
> + remote = of_graph_get_remote_node(dev->of_node, 1, 0);
> + if (of_device_is_compatible(remote, "panel-lvds"))
> + if (can_lvds)
> + ret = sun4i_lvds_init(drm, tcon);
> + else
> + ret = -EINVAL;
> + else
> + ret = sun4i_rgb_init(drm, tcon);
> + of_node_put(remote);
> +
> if (ret < 0)
> goto err_free_dotclock;
>
> @@ -879,12 +1111,14 @@ static const struct sun4i_tcon_quirks sun5i_a13_quirks = {
>
> static const struct sun4i_tcon_quirks sun6i_a31_quirks = {
> .has_channel_1 = true,
> + .has_lvds_pll = true,
> .needs_de_be_mux = true,
> .set_mux = sun6i_tcon_set_mux,
> };
>
> static const struct sun4i_tcon_quirks sun6i_a31s_quirks = {
> .has_channel_1 = true,
> + .has_lvds_pll = true,
The A31s does not have MIPI.
> .needs_de_be_mux = true,
> };
>
> @@ -895,7 +1129,7 @@ static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
> };
>
> static const struct sun4i_tcon_quirks sun8i_a33_quirks = {
> - /* nothing is supported */
> + .has_lvds_pll = true,
> };
>
> static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index bd3ad7684870..6e801a6325a1 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -70,7 +70,21 @@
> #define SUN4I_TCON0_TTL2_REG 0x78
> #define SUN4I_TCON0_TTL3_REG 0x7c
> #define SUN4I_TCON0_TTL4_REG 0x80
> +
> #define SUN4I_TCON0_LVDS_IF_REG 0x84
> +#define SUN4I_TCON0_LVDS_IF_EN BIT(31)
> +#define SUN4I_TCON0_LVDS_IF_BITWIDTH_MASK BIT(26)
> +#define SUN4I_TCON0_LVDS_IF_BITWIDTH_18BITS (1 << 26)
> +#define SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS (0 << 26)
> +#define SUN4I_TCON0_LVDS_IF_CLK_SEL_MASK BIT(20)
> +#define SUN4I_TCON0_LVDS_IF_CLK_SEL_TCON0 (1 << 20)
> +#define SUN4I_TCON0_LVDS_IF_CLK_POL_MASK BIT(4)
> +#define SUN4I_TCON0_LVDS_IF_CLK_POL_NORMAL (1 << 4)
> +#define SUN4I_TCON0_LVDS_IF_CLK_POL_INV (0 << 4)
> +#define SUN4I_TCON0_LVDS_IF_DATA_POL_MASK GENMASK(3, 0)
> +#define SUN4I_TCON0_LVDS_IF_DATA_POL_NORMAL (0xf)
> +#define SUN4I_TCON0_LVDS_IF_DATA_POL_INV (0)
> +
> #define SUN4I_TCON0_IO_POL_REG 0x88
> #define SUN4I_TCON0_IO_POL_DCLK_PHASE(phase) ((phase & 3) << 28)
> #define SUN4I_TCON0_IO_POL_HSYNC_POSITIVE BIT(25)
> @@ -131,6 +145,16 @@
> #define SUN4I_TCON_CEU_RANGE_G_REG 0x144
> #define SUN4I_TCON_CEU_RANGE_B_REG 0x148
> #define SUN4I_TCON_MUX_CTRL_REG 0x200
> +
> +#define SUN4I_TCON0_LVDS_ANA0_REG 0x220
> +#define SUN4I_TCON0_LVDS_ANA0_EN_MB BIT(31)
> +#define SUN4I_TCON0_LVDS_ANA0_EN_LDO BIT(30)
> +#define SUN4I_TCON0_LVDS_ANA0_EN_DRVC BIT(24)
> +#define SUN4I_TCON0_LVDS_ANA0_EN_DRVD(x) (((x) & 0xf) << 20)
> +#define SUN4I_TCON0_LVDS_ANA0_C(x) (((x) & 3) << 17)
> +#define SUN4I_TCON0_LVDS_ANA0_V(x) (((x) & 3) << 8)
> +#define SUN4I_TCON0_LVDS_ANA0_PD(x) (((x) & 3) << 4)
See above about the analog bits.
ChenYu
> +
> #define SUN4I_TCON1_FILL_CTL_REG 0x300
> #define SUN4I_TCON1_FILL_BEG0_REG 0x304
> #define SUN4I_TCON1_FILL_END0_REG 0x308
> @@ -149,6 +173,7 @@ struct sun4i_tcon;
>
> struct sun4i_tcon_quirks {
> bool has_channel_1; /* a33 does not have channel 1 */
> + bool has_lvds_pll; /* Can we mux the LVDS clock to a PLL? */
> bool needs_de_be_mux; /* sun6i needs mux to select backend */
>
> /* callback to handle tcon muxing options */
> @@ -167,6 +192,9 @@ struct sun4i_tcon {
> struct clk *sclk0;
> struct clk *sclk1;
>
> + /* Possible mux for the LVDS clock */
> + struct clk *lvds_pll;
> +
> /* Pixel clock */
> struct clk *dclk;
> u8 dclk_max_div;
> @@ -174,6 +202,7 @@ struct sun4i_tcon {
>
> /* Reset control */
> struct reset_control *lcd_rst;
> + struct reset_control *lvds_rst;
>
> struct drm_panel *panel;
>
> --
> git-series 0.9.1
--
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 v6 3/6] kernel/reboot.c: export pm_power_off_prepare
From: Oleksij Rempel @ 2017-12-07 5:36 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Mark Rutland, devicetree, Liam Girdwood, Shawn Guo,
Michael Turquette, Stephen Boyd, Russell King, linux-kernel,
Rob Herring, Mark Brown, kernel, Fabio Estevam, Andrew Morton,
Leonard Crestez, Linus Torvalds, linux-clk, linux-arm-kernel
In-Reply-To: <20171206231130.GA6235@infradead.org>
On 07.12.2017 00:11, Christoph Hellwig wrote:
>> void (*pm_power_off_prepare)(void);
>> +EXPORT_SYMBOL(pm_power_off_prepare);
>
> EXPORT_SYMBOL_GPL for something this deeply internal, please.
Ok,
probably all other symbols should be converted in this file in to
EXPORT_SYMBOL_GPL as well?
grep EXPORT_SYMBOL kernel/reboot.c
EXPORT_SYMBOL(cad_pid);
EXPORT_SYMBOL(pm_power_off_prepare);
EXPORT_SYMBOL_GPL(emergency_restart);
EXPORT_SYMBOL(register_reboot_notifier);
EXPORT_SYMBOL(unregister_reboot_notifier);
EXPORT_SYMBOL(devm_register_reboot_notifier);
EXPORT_SYMBOL(register_restart_handler);
EXPORT_SYMBOL(unregister_restart_handler);
EXPORT_SYMBOL_GPL(kernel_restart);
EXPORT_SYMBOL_GPL(kernel_halt);
EXPORT_SYMBOL_GPL(kernel_power_off);
EXPORT_SYMBOL_GPL(orderly_poweroff);
EXPORT_SYMBOL_GPL(orderly_reboot);
^ permalink raw reply
* Re: [PATCH v3 10/15] ARM: dts: sun8i: a83t: Add display pipeline
From: Chen-Yu Tsai @ 2017-12-07 4:02 UTC (permalink / raw)
To: Maxime Ripard
Cc: Daniel Vetter, David Airlie, Chen-Yu Tsai, dri-devel,
linux-kernel, Mark Rutland, Rob Herring, linux-arm-kernel,
Priit Laes, Icenowy Zheng, Thomas Petazzoni, Jernej Skrabec,
devicetree
In-Reply-To: <97d3cee9d0d7a92893f646d72643bac520de5f05.1512486553.git-series.maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Dec 5, 2017 at 11:10 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> The display pipeline on the A83T is mainly composed of the mixers and
> TCONs, plus various encoders.
>
> Let's add the first mixer and TCON to the DTSI since the only board I have
> can use only the LVDS output on the first TCON. The other parts will be
> added eventually.
>
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 03/15] dt-bindings: display: sun4i-drm: Add LVDS properties
From: Chen-Yu Tsai @ 2017-12-07 3:57 UTC (permalink / raw)
To: Maxime Ripard
Cc: Daniel Vetter, David Airlie, Chen-Yu Tsai, dri-devel,
linux-kernel, Mark Rutland, Rob Herring, linux-arm-kernel,
Priit Laes, Icenowy Zheng, Thomas Petazzoni, Jernej Skrabec,
devicetree
In-Reply-To: <17851ba6277b69aa9cd81de5eead62bfed271661.1512486553.git-series.maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Dec 5, 2017 at 11:10 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Some clocks and resets supposed to drive the LVDS logic in the display
> engine have been overlooked when the driver was first introduced.
>
> Add those additional resources to the binding, and we'll deal with the ABI
> stability in the code.
>
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 8 +++++++-
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index 50cc72ee1168..d4259a4f5171 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -121,6 +121,14 @@ Required properties:
> On SoCs other than the A33 and V3s, there is one more clock required:
> - 'tcon-ch1': The clock driving the TCON channel 1
>
> +On SoCs that support LVDS (all SoCs but the A13, H3, H5 and V3s), you
> +need one more reset line:
> + - 'lvds': The reset line driving the LVDS logic
> +
> +And on the SoCs newer than the A31 (sun6i and sun8i families), you
> +need one more clock line:
> + - 'lvds-pll': The PLL that can be used to drive the LVDS clock
Is this referring to TCON0_LVDS_Clk_Sel, which can use the MIPI PLL
on the A33? Maybe the description should be more clear, like:
- 'lvds-alt': An alternative clock separate from the TCON
that can be used to drive the LVDS clock.
ChenYu
> +
> DRC
> ---
>
> --
> git-series 0.9.1
--
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] [linux][master][v1] devicetree: misc: Add binding for logicoreIP xlnx,vcu
From: Dhaval Rajeshbhai Shah @ 2017-12-07 3:42 UTC (permalink / raw)
To: 'Rob Herring'
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org, Hyun Kwon
In-Reply-To: <20171206214909.jr2x6cdzs2577aee@rob-hp-laptop>
> -----Original Message-----
> From: Rob Herring [mailto:robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> Sent: Wednesday, December 06, 2017 1:49 PM
> To: Dhaval Rajeshbhai Shah <DSHAH-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
> Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org; Hyun Kwon
> <hyunk-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>; Dhaval Rajeshbhai Shah <DSHAH-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
> Subject: Re: [PATCH] [linux][master][v1] devicetree: misc: Add binding for
> logicoreIP xlnx,vcu
>
> On Tue, Dec 05, 2017 at 03:07:03AM -0800, Dhaval Shah wrote:
> > From: Dhaval Shah <dhaval.shah-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
> >
> > Added the txt file which contain the xlnx,vcu DT node properties
> > information. This also provides the information of it's child node as
> > well.
> >
> > Signed-off-by: Dhaval Shah <dshah-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
> > ---
> > .../devicetree/bindings/misc/xlnx,vcu.txt | 59
> ++++++++++++++++++++++
> > 1 file changed, 59 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/misc/xlnx,vcu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/misc/xlnx,vcu.txt
> > b/Documentation/devicetree/bindings/misc/xlnx,vcu.txt
> > new file mode 100644
> > index 0000000..e722ff3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/misc/xlnx,vcu.txt
> > @@ -0,0 +1,59 @@
> > +Xilinx VCU init Driver
>
> Bindings don't describe drivers. Describe the h/w.
I will take care of this.
>
> > +-----------------------------
> > +
> > +General concept
> > +---------------
> > +
> > +Xilinx VCU init driver is developed to handle the LogiCore related
> > +new implementation. In this directory, The DT node of the Xilinx VCU
> > +init driver represents as a top level node.
> > +
> > +Required properties:
> > +- compatible: Must be "xlnx,vcu".
>
> Needs to be more specific.
I will resolve this.
>
> > +- reg, reg-names: There are two sets of registers need to provide.
> > + 1. vcu slcr
> > + 2. Logicore
> > + reg-names should contain name for the each register sequence.
> > +- clocks: phandle for aclk and pll_ref clocksource
> > +- clock-names: The identification string, "aclk", is always required for
> > + the axi clock. "pll_ref" is required for pll.
> > +- ranges
> > +- VCU Init driver node define the following child nodes:
> > + * Allegro encoder driver node
>
> encoder of what?
I have to remove this encoder and decoder nodes. Other team is working on that. They will extend this once they are done with encoder and decoder.
>
> > + - compatible: Must be "al,al5e"
> > + - reg: There is a one set of register.
>
>
> > + - interrupts: interrupt number to the cpu.
> > + - interrupt-parent: the phandle for the interrupt controller
> > + that services interrupts for this device.
> > + * Allegro decoder driver node
> > + - compatible: Must be "al,al5d"
> > + - reg: There is a one set of register.
> > + - interrupts: interrupt number to the cpu.
> > + - interrupt-parent: the phandle for the interrupt controller
> > + that services interrupts for this device.
> > +Example:
> > +
> > + xlnx_vcu: vcu@a0040000 {
> > + compatible = "xlnx,vcu";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
>
> There's no reason the child nodes need 64 bits of address or size. Use ranges.
I will take care of this.
>
> > + reg = <0x0 0xa0040000 0x0 0x1000>,
> > + <0x0 0xa0041000 0x0 0x1000>;
> > + reg-names = "vcu_slcr", "logicore";
> > + clocks = <&si570_1>, <&clkc 71>;
> > + clock-names = "pll_ref", "aclk";
> > + ranges;
> > + encoder: al5e@a0000000 {
> > + compatible = "al,al5e";
> > + reg = <0x0 0xa0000000 0x0 0x10000>;
> > + interrupts = <0 89 4>;
> > + interrupt-parent = <&gic>;
> > + };
> > +
> > + decoder: al5d@a0020000 {
> > + compatible = "al,al5d";
> > + reg = <0x0 0xa0020000 0x0 0x10000>;
> > + interrupts = <0 89 4>;
>
> A shared interrupt? Are these really separate blocks? Seems like this could all
> be a single node.
Based on the discussion in the misc/drivers forum, I will remove this encoder and decoder node which is of some other team working on. They will extend this once they are done with there work.
>
> > + interrupt-parent = <&gic>;
> > + };
> > + };
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree"
> > in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More
> majordomo
> > info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 04/15] dt-bindings: display: sun4i-drm: Add A83T pipeline
From: Chen-Yu Tsai @ 2017-12-07 3:37 UTC (permalink / raw)
To: Rob Herring
Cc: Maxime Ripard, Daniel Vetter, David Airlie, Chen-Yu Tsai,
dri-devel, linux-kernel, Mark Rutland, linux-arm-kernel,
Priit Laes, Icenowy Zheng, Thomas Petazzoni, Jernej Skrabec,
devicetree
In-Reply-To: <20171206215922.vtsa4xqa2e5xz7cp@rob-hp-laptop>
On Thu, Dec 7, 2017 at 5:59 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Dec 05, 2017 at 04:10:16PM +0100, Maxime Ripard wrote:
>> The A83T has two video pipelines in parallel that looks quite similar to
>> the other SoCs.
>>
>> The video planes are handled through a controller called the mixer, and the
>> video signal is then passed to the timing controller (TCON).
>>
>> And while there is two instances of the mixers and TCONs, they have a
>> significant number of differences. The TCONs are quite easy to deal with,
>> one is supposed to generate TV (in the broader term, so including things
>> like HDMI) signals, the other one LCD (so RGB, LVDS, DSI) signals. And
>> while they are called TCON0 and TCON1 in the A83t datasheet, newer SoCs
>> call them TCON-TV and TCON-LCD, which seems more appropriate.
>>
>> However, the mixers differ mostly by their capabilities, with some features
>> being available only in the first one, or the number of planes they expose,
>> but also through their register layout. And while the capabilities could be
>> represented as properties, the register layout differences would need to
>> express all the registers offsets as properties, which is usually quite
>> bad. Especially since documentation on that hardware block is close to
>> non-existant and we don't even have the list of all those registers in the
>> first place.
>>
>> So let's call them mixer 0 and 1 in our compatibles, even though the name
>> is pretty bad...
>>
>> At the moment, we only have tested the code on a board that has a single
>> display output, so we're leaving the tcon-tv and mixer1 out.
>>
>> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>
> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 14/15] ARM: dts: sun8i: a711: Reinstate the PMIC compatible
From: Chen-Yu Tsai @ 2017-12-07 3:34 UTC (permalink / raw)
To: Maxime Ripard
Cc: Daniel Vetter, David Airlie, Chen-Yu Tsai, dri-devel,
linux-kernel, Mark Rutland, Rob Herring, linux-arm-kernel,
Priit Laes, Icenowy Zheng, Thomas Petazzoni, Jernej Skrabec,
devicetree
In-Reply-To: <25b482f19587ff195582995c11ee9d07f5bf42d2.1512486553.git-series.maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Dec 5, 2017 at 11:10 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> When we added the regulator support in commit 90c5d7cdae64 ("ARM: dts:
> sun8i: a711: Add regulator support"), we also dropped the PMIC's
> compatible. Since it's not in the PMIC DTSI, unlike most other PMIC
> DTSI, it obviously wasn't probing anymore.
>
> Re-add it so that everything works again.
>
> Fixes: 90c5d7cdae64 ("ARM: dts: sun8i: a711: Add regulator support")
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
--
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
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