* [PATCH 0/5] Meson GXL and GXM USB support
From: Rob Herring @ 2016-11-30 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCAA_JEtr_0Ze0thoRaEKMnWQMKcPxJ8y88zkWAAhuxsMw@mail.gmail.com>
On Sun, Nov 27, 2016 at 11:42:02PM +0100, Martin Blumenstingl wrote:
> Hello Kishon,
>
> On Sat, Nov 26, 2016 at 3:56 PM, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> wrote:
> > USB support on GXL and GXM differs a lot from Meson8b and GXBB:
> > The most obvious change is that GXL and GXM now have one dwc3
> > controller and one dwc2 controller (instead of two dwc2 controllers).
> > With that there are also new USB PHYs.
> >
> > Due to lack of hardware I was only able to test this on a board with
> > GXM, but as far as I understand the hardware my preparations should be
> > correct (so it should also work on GXL).
> >
> > dwc2 will probably stay unused on most GXM devices since it's limited
> > to device mode via some dwc2 hardware configuration register.
> >
> > dwc3 is probably used on all devices, even if there is more than just
> > one USB port. dwc3 has a built-in USB2 hub - on GXL this hub has two
> > ports enabled, while on GXM there are three ports enabled (see below
This hub is an actual USB hub? If so, then you should probably model the
USB bus topology (which we have a binding definition for).
> > for lsusb output). There are no USB3 ports enabled in the dwc3 hardware
> > configuration, meaning that the SoC is limited to high-speed mode.
> > On my GXM device the dwc3 hardware configuration forces it into "host
> > only" mode.
> >
> > The SoCs contain two PHY blocks: one USB3 PHY and up to four USB2 PHYs
> > (on GXM there are only three enabled, but the registers should support
> > up to four).
> > The USB3 PHY also handles the OTG interrupts, but since dwc3's hardware
> > configuration enforces "host only" mode I was not able to test this. It
> > simply takes care of an interrupt and then notifies all related PHYs
> > about the new mode.
> > The USB2 PHY block is a bit different: I created one PHY driver which
> > spans all "PHY ports" because the handling is a bit tricky. It turns
> > out that for each available USB port in dwc3's hub the corresponding
> > PHY must be enabled (even if there is no physical port - in my case
> > port 3 is not connected to anything, but disabling the PHY breaks
> > ports 1 and 2 as well).
> > I decided not not pass the USB2 PHYs directly to dwc3 due to three
> > reasons: 1. the USB3 PHY (which holds a reference to all relevant
> > USB2 PHY ports) controls the mode of the USB2 PHY ports (since both
> > are used with the same controller and thus it makes sense to keep the
> > mode consistent across all ports) 2. the dwc3 driver does not support
> > passing multiple USB2 PHYs (only one USB2 and one USB3 PHY can be
> > passed to it) 3. it is similar to how the vendor reference driver
> > manages the PHYs. Please note that this coupling is not a fixed, this
> > is all configurable via devicetree (so if the third USB2 PHY has to
> > be passed two the dwc2 controller then this is still possible by
> > just moving on PHY reference in the .dts).
> after not staring at my own code for 24 hours I realized this:
> (I went through quite a few iterations before getting these drivers to work)
> I'm basically re-modelling an "USB PHY hub" with my USB3 PHY driver
> (there's one "upstream" PHY interface which is passed to dwc3 and
> multiple downstream PHYs, each for one port on dwc3's internal hub).
> With this approach I could split each of the the USB2s into separate
> nodes again (instead of one devicetree node with #phy-cells = <1>) as
> the USB3 PHY is taking care of that special "we have to enable all
> ports or no port will be usable".
>
> We could go even one step further: why implement this in the Meson GXL
> specific PHY driver - why not implement a generic "phy-hub" driver
> (which would be valid whenever the PHY controller has to manage
> multiple PHYs at once, but wants to keep them all in a consistent
> state).
> The devicetree could look like this:
> usb2_phy_hub: phy at 0 {
> compatible = "phy-hub";
> phys = <&other_phy1>, <&other_phy 2>;
> };
>
> &dwc3 {
> phys = <&usb2_phy_hub>, <&usb3_phy0>;
> phy-names = "usb2-phy", "usb3-phy";
> };
I'm okay with a hub if it is modeled as a USB hub. Here though, it
looks like you are just trying to group things which doesn't need to be
in DT.
>
> The generic phy-hub driver would then implement all phy_ops callbacks
> and pass then to each of it's downstream PHYs.
You can have generic drivers without a generic binding.
> That's just what came into my head - please let me know what you think
> of this or share your ideas on how to approach this!
>
> > The coupling of the USB2 and USB3 PHYs is the reason why I sent the
> > two drivers in one patch, even though they are handling different IP
> > blocks (different registers, etc.).
> >
> > Unfortunately there are no datasheets available for any of these PHYs.
> > Both drivers were written by reading the reference drivers provided by
> > Amlogic and analyzing the registers on the kernel that was shipped with
> > my board.
> >
> > As a last note: the dwc3 driver currently only explicitly enables the
> > first USB port "DWC3_GUSB2PHYCFG(0)" in the internal hub. The hardware
> > seems to enable the other two (DWC3_GUSB2PHYCFG(1) and
> > DWC3_GUSB2PHYCFG(2)) automatically. I will ask the dwc3 maintainers if
> > changes to dwc3 are desired any how these should look like, but for now
> > it's working fine even without changes there.
> >
> > lsusb output on GXM for the dwc3 hub:
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > ...
> > Hub Port Status:
> > Port 1: 0000.0100 power
> > Port 2: 0000.0100 power
> > Port 3: 0000.0100 power
> >
> > NOTE: The devicetree changes depend on my previous series:
> > "[PATCH 0/2] minor GXL and GXM improvements" - see [0]
> >
> > NOTE2: This series depends on an upstream dwc3/xhci-plat DMA fix
> > (special thanks to Arnd Bergmann and Sriram Dash for fixing that):
> > "[PATCH v5 0/6] inherit dma configuration from parent dev" - see [1]
> >
> > I have a tree with all dependencies applied available at [2] if
> > someone wants a quick way to test this (I don't take any responsibility
> > if anything explodes though).
> >
> > [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001665.html
> > [1] http://marc.info/?l=linux-usb&m=147938307209685&w=2
> > [2] https://github.com/xdarklight/linux/commits/meson-gx-integration-4.10-20161126
> >
> > Martin Blumenstingl (5):
> > Documentation: dt-bindings: Add documentation for Meson GXL USB2/3
> > PHYs
> > phy: meson: add USB2 and USB3 PHY support for Meson GXL
> > arm64: dts: meson-gxl: add USB support
> > ARM64: dts: meson-gxm: add GXM specific USB configuration
> > ARM64: dts: meson-gx-p23x-q20x: enable USB on P23x and Q20x boards
> >
> > .../devicetree/bindings/phy/meson-gxl-usb2-phy.txt | 25 ++
> > .../devicetree/bindings/phy/meson-gxl-usb3-phy.txt | 27 ++
> > .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 12 +
> > arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 49 +++
> > .../arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 17 +
> > arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 10 +
> > drivers/phy/Kconfig | 13 +
> > drivers/phy/Makefile | 2 +
> > drivers/phy/phy-meson-gxl-usb2.c | 374 ++++++++++++++++++++
> > drivers/phy/phy-meson-gxl-usb3.c | 377 +++++++++++++++++++++
> > 10 files changed, 906 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt
> > create mode 100644 Documentation/devicetree/bindings/phy/meson-gxl-usb3-phy.txt
> > create mode 100644 drivers/phy/phy-meson-gxl-usb2.c
> > create mode 100644 drivers/phy/phy-meson-gxl-usb3.c
> >
> > --
> > 2.10.2
> >
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT changes for v4.10, round 2, v2
From: Arnd Bergmann @ 2016-11-30 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hwpfnz7l1.fsf@baylibre.com>
On Monday, November 28, 2016 12:13:14 PM CET Kevin Hilman wrote:
> Amlogic 64-bit DT updates for v4.10, round 2
> - new SoC support: S912/GXM series (8x A53)
> - new boards: Nexbox A1 (S912), Nexbox A95X (S905X)
> - resets for 2nd USB PHY
> - update SCPI compatible for pre-v1.0 devices
>
Pulled into next/dt64, thanks!
Arnd
^ permalink raw reply
* [PATCH v3 0/2] Support for Axentia TSE-850
From: Arnd Bergmann @ 2016-11-30 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480510102-24587-1-git-send-email-peda@axentia.se>
On Wednesday, November 30, 2016 1:48:20 PM CET Peter Rosin wrote:
> Hi!
>
> changes v2 -> v3
> - document the new compatible strings prefixed with "axentia,".
>
> changes v1 -> v2
> - squash the fixup into the correct patch, sorry for the noise.
>
> After finally having all essintial drivers upstreamed (the
> last ones are currently in -next) I would like to have the
> dts and the defconfig also upstreamed.
>
> Cheers,
> Peter
>
> Peter Rosin (2):
> ARM: dts: add devicetree for the Axentia TSE-850
> ARM: tse850_defconfig: add Axentia TSE-850
>
> Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
> MAINTAINERS | 8 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/axentia-linea.dtsi | 53 +++++
> arch/arm/boot/dts/axentia-tse850-3.dts | 276 ++++++++++++++++++++++
> arch/arm/configs/tse850_defconfig | 223 +++++++++++++++++
> 6 files changed, 580 insertions(+)
Hi Peter,
I'm a bit confused. Are these just boards using the sama5d31 SoC,
or something else?
Normally, dts files are picked up by the SoC platform maintainers
and named with a prefix for that soc.
Also, we don't normally add a defconfig file for a specific
machine, just add the options you want to sama5_defconfig
and multi_v7_defconfig, and send all patches to the
at91 maitainers.
Arnd
^ permalink raw reply
* [GIT PULL] STi defconfig updates for v4.10 round 3
From: Arnd Bergmann @ 2016-11-30 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2956a25a-ef39-842a-d0cd-baf4a01f7a2c@st.com>
On Monday, November 28, 2016 1:37:00 PM CET Patrice Chotard wrote:
>
> STi defconfig fix:
>
> Enable HVA (Hardware Video Accelerator) video encoder
> driver for STMicroelectronics SoC.
>
>
Pulled into next/defconfig, thanks!
Arnd
[I had to take kernel at stlinux.com from the Cc list, the address bounces]
^ permalink raw reply
* [PATCH v2 8/9] arm64: dts: rockchip: support dwc3 USB for rk3399
From: Brian Norris @ 2016-11-30 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-9-git-send-email-wxt@rock-chips.com>
+ Felipe, Arnd, others
Hi Caesar,
On Wed, Nov 09, 2016 at 09:22:00PM +0800, Caesar Wang wrote:
> From: Brian Norris <briannorris@chromium.org>
>
> Add the dwc3 usb needed node information for rk3399.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Note that none of this can work yet (at least for host mode, which I've
been testing), because DWC3 still hasn't been patched for ARM64 support.
It's been 7+ months and multiple people have tried to patch the issue,
but nothing has been merged.
See for instance:
usb: dwc3: host: inherit dma configuration from parent dev
https://lkml.org/lkml/2016/4/25/813
https://lkml.org/lkml/2016/5/5/391
Thread was resurrected in September:
https://lkml.org/lkml/2016/9/1/715
but there's still no end in sight. Maybe the following is the latest
incarnation?
[PATCH v2 0/6] inherit dma configuration from parent dev
https://www.mail-archive.com/linux-usb at vger.kernel.org/msg82369.html
I guess nothing prevents a valid device tree being merged here, but it's
severely limited by the above bug still, so I just wanted to call
attention to it.
(Let me guess: you've still been testing an internal non-upstream tree
that has this patched already, Caesar?)
> ---
>
> Changes in v2:
> - the original patches from brian posting on
> https://chromium-review.googlesource.com/343603
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 54 ++++++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 09ebf4e..3659c56 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -353,6 +353,60 @@
> status = "disabled";
> };
>
> + usbdrd3_0: usb at fe800000 {
> + compatible = "rockchip,rk3399-dwc3";
> + clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
> + <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
> + clock-names = "ref_clk", "suspend_clk",
> + "bus_clk", "grf_clk";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + status = "disabled";
> + usbdrd_dwc3_0: dwc3 at fe800000 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0xfe800000 0x0 0x100000>;
> + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
> + dr_mode = "otg";
> + phys = <&tcphy0_usb3>;
> + phy-names = "usb3-phy";
The USB3/TypeC PHY won't probe without extcon support, and no rk3399
platforms have proper extcon support upstream AFAIK, right? Seems like
it'd be better to leave this phy property off for now, with the hope of
at least getting USB2 working. We can add it later once somebody proves
USB3 support upstream.
> + phy_type = "utmi_wide";
> + snps,dis_enblslpm_quirk;
> + snps,dis-u2-freeclk-exists-quirk;
> + snps,dis_u2_susphy_quirk;
> + snps,dis-del-phy-power-chg-quirk;
> + snps,xhci-slow-suspend-quirk;
This property isn't supported upstream. Seems like we should drop it for
now.
Same comments on the other DWC3 instance below, of course.
Brian
> + status = "disabled";
> + };
> + };
> +
> + usbdrd3_1: usb at fe900000 {
> + compatible = "rockchip,rk3399-dwc3";
> + clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
> + <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_GRF>;
> + clock-names = "ref_clk", "suspend_clk",
> + "bus_clk", "grf_clk";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + status = "disabled";
> + usbdrd_dwc3_1: dwc3 at fe900000 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0xfe900000 0x0 0x100000>;
> + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
> + dr_mode = "host";
> + phys = <&tcphy1_usb3>;
> + phy-names = "usb3-phy";
> + phy_type = "utmi_wide";
> + snps,dis_enblslpm_quirk;
> + snps,dis-u2-freeclk-exists-quirk;
> + snps,dis_u2_susphy_quirk;
> + snps,dis-del-phy-power-chg-quirk;
> + snps,xhci-slow-suspend-quirk;
> + status = "disabled";
> + };
> + };
> +
> gic: interrupt-controller at fee00000 {
> compatible = "arm,gic-v3";
> #interrupt-cells = <4>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 1/2] bus: vexpress-config: fix device reference leak
From: Arnd Bergmann @ 2016-11-30 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479317491-7435-1-git-send-email-sudeep.holla@arm.com>
On Wednesday, November 16, 2016 5:31:30 PM CET Sudeep Holla wrote:
> From: Johan Hovold <johan@kernel.org>
>
> Make sure to drop the reference to the parent device taken by
> class_find_device() after populating the bus.
>
> Fixes: 3b9334ac835b ("mfd: vexpress: Convert custom func API to regmap")
> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> drivers/bus/vexpress-config.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> Hi ARM-SoC team,
>
> I am not sure if these couple of patches can be considered as fixes for
> v4.9. I will leave that to you guys.
>
> Can you pick these couple of patches directly either for v4.9 or v4.10 ?
> I am trying to avoid single patch pull requests here. Let me know if
> you prefer PR instead.
>
Sorry for the delay. I think it's find to wait till 4.10, so
I've applied it to next/fixes-non-critical.
Arnd
^ permalink raw reply
* [PATCH v2 1/7] net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
From: Martin Blumenstingl @ 2016-11-30 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130214429.albylffpoumbeugi@rob-hp-laptop>
On Wed, Nov 30, 2016 at 10:44 PM, Rob Herring <robh@kernel.org> wrote:
> On Fri, Nov 25, 2016 at 02:01:50PM +0100, Martin Blumenstingl wrote:
>> This allows configuring the RGMII TX clock delay. The RGMII clock is
>> generated by underlying hardware of the the Meson 8b / GXBB DWMAC glue.
>> The configuration depends on the actual hardware (no delay may be
>> needed due to the design of the actual circuit, the PHY might add this
>> delay, etc.).
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> ---
>> Documentation/devicetree/bindings/net/meson-dwmac.txt | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
>> index 89e62dd..f8bc540 100644
>> --- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
>> +++ b/Documentation/devicetree/bindings/net/meson-dwmac.txt
>> @@ -25,6 +25,20 @@ Required properties on Meson8b and newer:
>> - "clkin0" - first parent clock of the internal mux
>> - "clkin1" - second parent clock of the internal mux
>>
>> +Optional properties on Meson8b and newer:
>> +- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
>> + by this driver) in nanoseconds. Allowed values
>> + are: 0ns, 2ns, 4ns, 6ns.
>> + This must be configured when the phy-mode is
>> + "rgmii" (typically a value of 2ns is used in
>> + this case).
>> + When phy-mode is set to "rgmii-id" or
>> + "rgmii-txid" the TX clock delay is already
>> + provided by the PHY. In that case this
>> + property should be set to 0ns (which disables
>> + the TX clock delay in the MAC to prevent the
>> + clock from going off because both PHY and MAC
>> + are adding a delay).
>
> What's the default? Why can't no property mean 0ns delay?
This value (2ns) was previously hardcoded. Having a default of 0ns
means that patch 7 ("ARM64: dts: amlogic: add the ethernet TX delay
configuration") becomes mandatory (otherwise we'll have broken Gbit
ethernet again because the TX delay is now disabled in the PHY when
phy-mode is "rgmii" and additionally we don't apply the 2ns TX delay
on the MAC side when the property is missing).
I'm fine with either way though - just let me know so I can adjust the
code accordingly.
^ permalink raw reply
* [GIT PULL 3/3] Rockchip dts32 changes for 4.10
From: Arnd Bergmann @ 2016-11-30 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1575955.EYn93JYaxe@phil>
On Thursday, November 24, 2016 4:43:16 PM CET Heiko Stuebner wrote:
> A bit of attention for the rk3066, fixed tsadc reset node
> as well as enabling the dma for uart and mmc controllers.
>
> And one new soc, the rk1108 combining a single-core Cortex-A7
> with a separate DSP core.
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: berlin: DT changes for v4.10
From: Arnd Bergmann @ 2016-11-30 22:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125175005.7b9f8396@xhacker>
On Friday, November 25, 2016 5:50:05 PM CET Jisheng Zhang wrote:
> Berlin DT changes for v4.10
>
> - fix DTC compiler warning
> - fix typo in chosen node
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt for v4.10 (#2)
From: Arnd Bergmann @ 2016-11-30 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87k2bqink1.fsf@free-electrons.com>
On Saturday, November 26, 2016 10:43:26 AM CET Gregory CLEMENT wrote:
> Here is the second (and late) pull request for dt for mvebu for v4.10.
> It only contains the support for the Turris Omnia.
>
> It is a little late but quoting Uwe Kleine-K?nig: "can we still get it
> into 4.10? This would help me to put this in the Debian kernel for the
> next release."
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: keystone: add TI SCI protocol support for v4.10
From: santosh.shilimkar at oracle.com @ 2016-11-30 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5602219.0b9asep0uZ@wuerfel>
On 11/30/16 1:09 PM, Arnd Bergmann wrote:
> On Wednesday, November 30, 2016 7:59:26 PM CET Tero Kristo wrote:
>>
>> Thanks Arnd, that looks good to me.
>>
>> I'll figure out how to add branch description next time when I am going
>> to be sending a pull-request directly to you guys.
>>
>>
>
> You should get a prompt when you sign the tag.
>
> Actually my preference would be for you to forward this to Santosh:
> There are a lot of little details to know about the submission
> process to for arm-soc, and it's easier for us if fewer people
> have to be aware of them.
>
I can queue this up Arnd from next merge window onwards.
Regards,
Santosh
^ permalink raw reply
* [PATCH 0/5] Meson GXL and GXM USB support
From: Martin Blumenstingl @ 2016-11-30 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130222228.zu6ampaajg3gkdz4@rob-hp-laptop>
On Wed, Nov 30, 2016 at 11:22 PM, Rob Herring <robh@kernel.org> wrote:
> On Sun, Nov 27, 2016 at 11:42:02PM +0100, Martin Blumenstingl wrote:
>> Hello Kishon,
>>
>> On Sat, Nov 26, 2016 at 3:56 PM, Martin Blumenstingl
>> <martin.blumenstingl@googlemail.com> wrote:
>> > USB support on GXL and GXM differs a lot from Meson8b and GXBB:
>> > The most obvious change is that GXL and GXM now have one dwc3
>> > controller and one dwc2 controller (instead of two dwc2 controllers).
>> > With that there are also new USB PHYs.
>> >
>> > Due to lack of hardware I was only able to test this on a board with
>> > GXM, but as far as I understand the hardware my preparations should be
>> > correct (so it should also work on GXL).
>> >
>> > dwc2 will probably stay unused on most GXM devices since it's limited
>> > to device mode via some dwc2 hardware configuration register.
>> >
>> > dwc3 is probably used on all devices, even if there is more than just
>> > one USB port. dwc3 has a built-in USB2 hub - on GXL this hub has two
>> > ports enabled, while on GXM there are three ports enabled (see below
>
> This hub is an actual USB hub? If so, then you should probably model the
> USB bus topology (which we have a binding definition for).
(the following explanation is based on a) what I found is going on in
the hardware registers b) reading the vendor drivers - unfortunately
there are no datasheets available which could give more details).
lsusb on my GXM gives:
...
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
The layout looks like this:
dwc3 provides a USB hub with 2 (on GXL) or 3 (on GXM) USB ports.
Each of the port is driven by a PHY (port 1 = abp at 0x78000, port2 =
abp at 0x78020, etc...).
On GXM USB2 PHY port 3 = abp at 0x78040 is connected to the third dwc3 hub port.
On GXL PHY port 3 = abp at 0x78040 is connected to the dwc2 (I could not
prove this yet as I don't have access to any GXL hardware).
So the answer is: we don't have an actual USB hub here (as this hub is
provided by dwc3), but rather a set of PHYs which is assigned to
dwc3's hub (if we don't configure *all* PHYs then none of the USB
ports provided by the dwc3 hub works).
Could you please point me to the USB bus topology binding (is it the
one described in usb-device.txt)?
>> > for lsusb output). There are no USB3 ports enabled in the dwc3 hardware
>> > configuration, meaning that the SoC is limited to high-speed mode.
>> > On my GXM device the dwc3 hardware configuration forces it into "host
>> > only" mode.
>> >
>> > The SoCs contain two PHY blocks: one USB3 PHY and up to four USB2 PHYs
>> > (on GXM there are only three enabled, but the registers should support
>> > up to four).
>> > The USB3 PHY also handles the OTG interrupts, but since dwc3's hardware
>> > configuration enforces "host only" mode I was not able to test this. It
>> > simply takes care of an interrupt and then notifies all related PHYs
>> > about the new mode.
>> > The USB2 PHY block is a bit different: I created one PHY driver which
>> > spans all "PHY ports" because the handling is a bit tricky. It turns
>> > out that for each available USB port in dwc3's hub the corresponding
>> > PHY must be enabled (even if there is no physical port - in my case
>> > port 3 is not connected to anything, but disabling the PHY breaks
>> > ports 1 and 2 as well).
>> > I decided not not pass the USB2 PHYs directly to dwc3 due to three
>> > reasons: 1. the USB3 PHY (which holds a reference to all relevant
>> > USB2 PHY ports) controls the mode of the USB2 PHY ports (since both
>> > are used with the same controller and thus it makes sense to keep the
>> > mode consistent across all ports) 2. the dwc3 driver does not support
>> > passing multiple USB2 PHYs (only one USB2 and one USB3 PHY can be
>> > passed to it) 3. it is similar to how the vendor reference driver
>> > manages the PHYs. Please note that this coupling is not a fixed, this
>> > is all configurable via devicetree (so if the third USB2 PHY has to
>> > be passed two the dwc2 controller then this is still possible by
>> > just moving on PHY reference in the .dts).
>> after not staring at my own code for 24 hours I realized this:
>> (I went through quite a few iterations before getting these drivers to work)
>> I'm basically re-modelling an "USB PHY hub" with my USB3 PHY driver
>> (there's one "upstream" PHY interface which is passed to dwc3 and
>> multiple downstream PHYs, each for one port on dwc3's internal hub).
>> With this approach I could split each of the the USB2s into separate
>> nodes again (instead of one devicetree node with #phy-cells = <1>) as
>> the USB3 PHY is taking care of that special "we have to enable all
>> ports or no port will be usable".
>>
>> We could go even one step further: why implement this in the Meson GXL
>> specific PHY driver - why not implement a generic "phy-hub" driver
>> (which would be valid whenever the PHY controller has to manage
>> multiple PHYs at once, but wants to keep them all in a consistent
>> state).
>> The devicetree could look like this:
>> usb2_phy_hub: phy at 0 {
>> compatible = "phy-hub";
>> phys = <&other_phy1>, <&other_phy 2>;
>> };
>>
>> &dwc3 {
>> phys = <&usb2_phy_hub>, <&usb3_phy0>;
>> phy-names = "usb2-phy", "usb3-phy";
>> };
>
> I'm okay with a hub if it is modeled as a USB hub. Here though, it
> looks like you are just trying to group things which doesn't need to be
> in DT.
I hope my answer above makes things more clear
>> The generic phy-hub driver would then implement all phy_ops callbacks
>> and pass then to each of it's downstream PHYs.
>
> You can have generic drivers without a generic binding.
So you'd rather implement a generic driver which would provide
functions like of_create_grouped_phy(struct device_node *np) which
would implement the grouping logic as described (but has no binding
itself, but rather relies on the actual platform driver taking care of
creating that binding and re-using generic code)?
>> That's just what came into my head - please let me know what you think
>> of this or share your ideas on how to approach this!
>>
>> > The coupling of the USB2 and USB3 PHYs is the reason why I sent the
>> > two drivers in one patch, even though they are handling different IP
>> > blocks (different registers, etc.).
>> >
>> > Unfortunately there are no datasheets available for any of these PHYs.
>> > Both drivers were written by reading the reference drivers provided by
>> > Amlogic and analyzing the registers on the kernel that was shipped with
>> > my board.
>> >
>> > As a last note: the dwc3 driver currently only explicitly enables the
>> > first USB port "DWC3_GUSB2PHYCFG(0)" in the internal hub. The hardware
>> > seems to enable the other two (DWC3_GUSB2PHYCFG(1) and
>> > DWC3_GUSB2PHYCFG(2)) automatically. I will ask the dwc3 maintainers if
>> > changes to dwc3 are desired any how these should look like, but for now
>> > it's working fine even without changes there.
>> >
>> > lsusb output on GXM for the dwc3 hub:
>> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> > ...
>> > Hub Port Status:
>> > Port 1: 0000.0100 power
>> > Port 2: 0000.0100 power
>> > Port 3: 0000.0100 power
>> >
>> > NOTE: The devicetree changes depend on my previous series:
>> > "[PATCH 0/2] minor GXL and GXM improvements" - see [0]
>> >
>> > NOTE2: This series depends on an upstream dwc3/xhci-plat DMA fix
>> > (special thanks to Arnd Bergmann and Sriram Dash for fixing that):
>> > "[PATCH v5 0/6] inherit dma configuration from parent dev" - see [1]
>> >
>> > I have a tree with all dependencies applied available at [2] if
>> > someone wants a quick way to test this (I don't take any responsibility
>> > if anything explodes though).
>> >
>> > [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001665.html
>> > [1] http://marc.info/?l=linux-usb&m=147938307209685&w=2
>> > [2] https://github.com/xdarklight/linux/commits/meson-gx-integration-4.10-20161126
>> >
>> > Martin Blumenstingl (5):
>> > Documentation: dt-bindings: Add documentation for Meson GXL USB2/3
>> > PHYs
>> > phy: meson: add USB2 and USB3 PHY support for Meson GXL
>> > arm64: dts: meson-gxl: add USB support
>> > ARM64: dts: meson-gxm: add GXM specific USB configuration
>> > ARM64: dts: meson-gx-p23x-q20x: enable USB on P23x and Q20x boards
>> >
>> > .../devicetree/bindings/phy/meson-gxl-usb2-phy.txt | 25 ++
>> > .../devicetree/bindings/phy/meson-gxl-usb3-phy.txt | 27 ++
>> > .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 12 +
>> > arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 49 +++
>> > .../arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 17 +
>> > arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 10 +
>> > drivers/phy/Kconfig | 13 +
>> > drivers/phy/Makefile | 2 +
>> > drivers/phy/phy-meson-gxl-usb2.c | 374 ++++++++++++++++++++
>> > drivers/phy/phy-meson-gxl-usb3.c | 377 +++++++++++++++++++++
>> > 10 files changed, 906 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt
>> > create mode 100644 Documentation/devicetree/bindings/phy/meson-gxl-usb3-phy.txt
>> > create mode 100644 drivers/phy/phy-meson-gxl-usb2.c
>> > create mode 100644 drivers/phy/phy-meson-gxl-usb3.c
>> >
>> > --
>> > 2.10.2
>> >
^ permalink raw reply
* [PATCH] arm64: dts: juno: Correct PCI IO window
From: Arnd Bergmann @ 2016-11-30 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <92ac8013-b88e-2f74-9a49-7d5f38a4e7a5@arm.com>
On Wednesday, November 30, 2016 4:29:35 PM CET Sudeep Holla wrote:
> Hi Jeremy,
>
> On 29/11/16 20:45, Jeremy Linton wrote:
> > The PCIe root complex on Juno translates the MMIO mapped
> > at 0x5f800000 to the PIO address range starting at 0
> > (which is common because PIO addresses are generally < 64k).
> > Correct the DT to reflect this.
> >
>
> I have another DT fix that I have asked ARM-SoC guys to pick up directly
> from the list. If that doesn't happen, I will send PR including both.
>
> If that happens then we need to send this to them to be picked directly.
> At this point I want to wait for couple of days to avoid confusion.
I ended up taking the other one for v4.10, but this one seems more
important so I applied it for v4.9.
Let me know if you disagree with the priorities, as I plan to send out
the last 4.9 fixes pull request to Linus tomorrow.
Arnd
^ permalink raw reply
* [PATCH 1/3] of: Support parsing phandle argument lists through a nexus node
From: Rob Herring @ 2016-11-30 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124102529.20212-2-stephen.boyd@linaro.org>
On Thu, Nov 24, 2016 at 4:25 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> Platforms like 96boards have a standardized connector/expansion
> slot that exposes signals like GPIOs to expansion boards in an
> SoC agnostic way. We'd like the DT overlays for the expansion
> boards to be written once without knowledge of the SoC on the
> other side of the connector. This avoids the unscalable
> combinatorial explosion of a different DT overlay for each
> expansion board and SoC pair.
>
> We need a way to describe the GPIOs routed through the connector
> in an SoC agnostic way. Let's introduce nexus property parsing
> into the OF core to do this. This is largely based on the
> interrupt nexus support we already have. This allows us to remap
> a phandle list in a consumer node (e.g. reset-gpios) through a
> connector in a generic way (e.g. via gpio-map). Do this in a
> generic routine so that we can remap any sort of variable length
> phandle list.
>
> Taking GPIOs as an example, the connector would be a GPIO nexus,
> supporting the remapping of a GPIO specifier space to multiple
> GPIO providers on the SoC. DT would look as shown below, where
> 'soc_gpio1' and 'soc_gpio2' are inside the SoC, 'connector' is an
> expansion port where boards can be plugged in, and
> 'expansion_device' is a device on the expansion board.
>
> soc {
> soc_gpio1: gpio-controller1 {
> #gpio-cells = <2>;
> };
>
> soc_gpio2: gpio-controller2 {
> #gpio-cells = <2>;
> };
> };
>
> connector: connector {
> #gpio-cells = <2>;
> gpio-map = <0 GPIO_ACTIVE_LOW &soc_gpio1 1 GPIO_ACTIVE_LOW>,
> <1 GPIO_ACTIVE_LOW &soc_gpio2 4 GPIO_ACTIVE_LOW>,
> <2 GPIO_ACTIVE_LOW &soc_gpio1 3 GPIO_ACTIVE_LOW>,
> <3 GPIO_ACTIVE_LOW &soc_gpio2 2 GPIO_ACTIVE_LOW>;
> gpio-map-mask = <0xf 0x1>;
I think the common case is something more like this:
gpio-map = <0 0 &soc_gpio1 1 0>,
<1 0 &soc_gpio2 4 0>,
<2 0 &soc_gpio1 3 0>,
<3 0 &soc_gpio2 2 0>;
gpio-map-mask = <0xf 0>;
where we want to pass the 2nd cell of the consumer (e.g. reset-gpios)
thru. So here the GPIO_ACTIVE_LOW flag below needs to pass thru to
&soc_gpio1. Otherwise, the gpio-map is has to enumerate every possible
combination or it will be specific to the daughterboard's usage.
Also, GPIO cells are pretty well standardized, but some cases may need
a translation function which I guess would be part of a connector
driver. I don't think that affects the binding nor needs to be solved
now, but just want to raise that possibility.
> };
>
> expansion_device {
> reset-gpios = <&connector 2 GPIO_ACTIVE_LOW>;
> };
>
> The GPIO core would use of_parse_phandle_with_args_map() instead
> of of_parse_phandle_with_args() and arrive at the same type of
> result, a phandle and argument list. The difference is that the
> phandle and arguments will be remapped through the nexus node to
> the underlying SoC GPIO controller node. In the example above,
> we would remap 'reset-gpios' from <&connector 2 GPIO_ACTIVE_LOW>
> to <&soc_gpio1 3 GPIO_ACTIVE_LOW>.
GPIOs also are interrupts frequently, so we need to make sure
interrupt translation works too. It's a bit tricky as interrupt-map
depends on #address-cells and #interrupt-cells. I think we just set
the #address-cells to 0 on the connector node and it will be fine. We
may need the same pass thru of flags though.
>
> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Mark Brown <broonie@kernel.org>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> ---
> drivers/of/base.c | 146 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/of.h | 14 +++++
> 2 files changed, 160 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d687e6de24a0..693b73f33675 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1772,6 +1772,152 @@ int of_parse_phandle_with_args(const struct device_node *np, const char *list_na
> EXPORT_SYMBOL(of_parse_phandle_with_args);
>
> /**
> + * of_parse_phandle_with_args_map() - Find a node pointed by phandle in a list and remap it
> + * @np: pointer to a device tree node containing a list
> + * @list_name: property name that contains a list
> + * @cells_name: property name that specifies phandles' arguments count
> + * @index: index of a phandle to parse out
> + * @out_args: optional pointer to output arguments structure (will be filled)
> + *
> + * This function is useful to parse lists of phandles and their arguments.
> + * Returns 0 on success and fills out_args, on error returns appropriate
> + * errno value.
> + *
> + * Caller is responsible to call of_node_put() on the returned out_args->np
> + * pointer.
> + *
> + * Example:
> + *
> + * phandle1: node1 {
> + * #list-cells = <2>;
> + * }
> + *
> + * phandle2: node2 {
> + * #list-cells = <1>;
> + * }
> + *
> + * phandle3: node3 {
> + * #list-cells = <1>;
> + * list-map = <0 &phandle2 3>,
> + * <1 &phandle2 2>,
> + * <2 &phandle1 5 1>;
> + * list-map-mask = <0x3>;
> + * };
> + *
> + * node4 {
> + * list = <&phandle1 1 2 &phandle3 0>;
> + * }
> + *
> + * To get a device_node of the `node2' node you may call this:
> + * of_parse_phandle_with_args(node4, "list", "#list-cells", "list-map",
> + * "list-map-mask", 1, &args);
> + */
> +int of_parse_phandle_with_args_map(const struct device_node *np,
> + const char *list_name,
> + const char *cells_name,
> + const char *map_name,
> + const char *mask_name,
Perhaps these 3 could be just a single base name (e.g. "gpio")?
Doesn't really buy much other than enforce we don't mix 'gpios' and
'gpio'. That could never happen. ;)
> + int index, struct of_phandle_args *out_args)
> +{
Rob
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Duc Dang @ 2016-11-30 23:42 UTC (permalink / raw)
To: linux-arm-kernel
PCIe controllers in X-Gene SoCs is not ECAM compliant: software
needs to configure additional controller's register to address
device at bus:dev:function.
The quirk will only be applied for X-Gene PCIe MCFG table with
OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
The quirk declares the X-Gene PCIe controller register space as 64KB
fixed memory resource with name "PCIe CSR". This name will be showed
next to the resource range in the output of "cat /proc/iomem".
Signed-off-by: Duc Dang <dhdang@apm.com>
---
v3:
- Rebase on top of pci/ecam-v6 tree.
- Use DEFINE_RES_MEM_NAMED to declare controller register space
with name "PCIe CSR"
v2:
RFC v2: https://patchwork.ozlabs.org/patch/686846/
v1:
RFC v1: https://patchwork.kernel.org/patch/9337115/
drivers/acpi/pci_mcfg.c | 31 ++++++++
drivers/pci/host/pci-xgene.c | 165 ++++++++++++++++++++++++++++++++++++++++++-
include/linux/pci-ecam.h | 7 ++
3 files changed, 200 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index ac21db3..eb6125b 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -57,6 +57,37 @@ struct mcfg_fixup {
{ "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops },
{ "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops },
{ "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops },
+
+#ifdef CONFIG_PCI_XGENE
+#define XGENE_V1_ECAM_MCFG(rev, seg) \
+ {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \
+ &xgene_v1_pcie_ecam_ops }
+#define XGENE_V2_1_ECAM_MCFG(rev, seg) \
+ {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \
+ &xgene_v2_1_pcie_ecam_ops }
+#define XGENE_V2_2_ECAM_MCFG(rev, seg) \
+ {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \
+ &xgene_v2_2_pcie_ecam_ops }
+
+ /* X-Gene SoC with v1 PCIe controller */
+ XGENE_V1_ECAM_MCFG(1, 0),
+ XGENE_V1_ECAM_MCFG(1, 1),
+ XGENE_V1_ECAM_MCFG(1, 2),
+ XGENE_V1_ECAM_MCFG(1, 3),
+ XGENE_V1_ECAM_MCFG(1, 4),
+ XGENE_V1_ECAM_MCFG(2, 0),
+ XGENE_V1_ECAM_MCFG(2, 1),
+ XGENE_V1_ECAM_MCFG(2, 2),
+ XGENE_V1_ECAM_MCFG(2, 3),
+ XGENE_V1_ECAM_MCFG(2, 4),
+ /* X-Gene SoC with v2.1 PCIe controller */
+ XGENE_V2_1_ECAM_MCFG(3, 0),
+ XGENE_V2_1_ECAM_MCFG(3, 1),
+ /* X-Gene SoC with v2.2 PCIe controller */
+ XGENE_V2_2_ECAM_MCFG(4, 0),
+ XGENE_V2_2_ECAM_MCFG(4, 1),
+ XGENE_V2_2_ECAM_MCFG(4, 2),
+#endif
};
static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index 1de23d7..43d7c69 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -27,6 +27,8 @@
#include <linux/of_irq.h>
#include <linux/of_pci.h>
#include <linux/pci.h>
+#include <linux/pci-acpi.h>
+#include <linux/pci-ecam.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
@@ -64,6 +66,7 @@
/* PCIe IP version */
#define XGENE_PCIE_IP_VER_UNKN 0
#define XGENE_PCIE_IP_VER_1 1
+#define XGENE_PCIE_IP_VER_2 2
struct xgene_pcie_port {
struct device_node *node;
@@ -97,7 +100,15 @@ static inline u32 pcie_bar_low_val(u32 addr, u32 flags)
*/
static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
{
- struct xgene_pcie_port *port = bus->sysdata;
+ struct pci_config_window *cfg;
+ struct xgene_pcie_port *port;
+
+ if (acpi_disabled)
+ port = bus->sysdata;
+ else {
+ cfg = bus->sysdata;
+ port = cfg->priv;
+ }
if (bus->number >= (bus->primary + 1))
return port->cfg_base + AXI_EP_CFG_ACCESS;
@@ -111,10 +122,18 @@ static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
*/
static void xgene_pcie_set_rtdid_reg(struct pci_bus *bus, uint devfn)
{
- struct xgene_pcie_port *port = bus->sysdata;
+ struct pci_config_window *cfg;
+ struct xgene_pcie_port *port;
unsigned int b, d, f;
u32 rtdid_val = 0;
+ if (acpi_disabled)
+ port = bus->sysdata;
+ else {
+ cfg = bus->sysdata;
+ port = cfg->priv;
+ }
+
b = bus->number;
d = PCI_SLOT(devfn);
f = PCI_FUNC(devfn);
@@ -158,7 +177,15 @@ static void __iomem *xgene_pcie_map_bus(struct pci_bus *bus, unsigned int devfn,
static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
{
- struct xgene_pcie_port *port = bus->sysdata;
+ struct pci_config_window *cfg;
+ struct xgene_pcie_port *port;
+
+ if (acpi_disabled)
+ port = bus->sysdata;
+ else {
+ cfg = bus->sysdata;
+ port = cfg->priv;
+ }
if (pci_generic_config_read32(bus, devfn, where & ~0x3, 4, val) !=
PCIBIOS_SUCCESSFUL)
@@ -189,6 +216,138 @@ static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
.write = pci_generic_config_write32,
};
+#ifdef CONFIG_ACPI
+static struct resource xgene_v1_csr_res[] = {
+ [0] = DEFINE_RES_MEM_NAMED(0x1f2b0000UL, SZ_64K, "PCIe CSR"),
+ [1] = DEFINE_RES_MEM_NAMED(0x1f2c0000UL, SZ_64K, "PCIe CSR"),
+ [2] = DEFINE_RES_MEM_NAMED(0x1f2d0000UL, SZ_64K, "PCIe CSR"),
+ [3] = DEFINE_RES_MEM_NAMED(0x1f500000UL, SZ_64K, "PCIe CSR"),
+ [4] = DEFINE_RES_MEM_NAMED(0x1f510000UL, SZ_64K, "PCIe CSR"),
+};
+
+static int xgene_v1_pcie_ecam_init(struct pci_config_window *cfg)
+{
+ struct acpi_device *adev = to_acpi_device(cfg->parent);
+ struct acpi_pci_root *root = acpi_driver_data(adev);
+ struct device *dev = cfg->parent;
+ struct xgene_pcie_port *port;
+ struct resource *csr;
+
+ port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
+ if (!port)
+ return -ENOMEM;
+
+ csr = &xgene_v1_csr_res[root->segment];
+ port->csr_base = devm_ioremap_resource(dev, csr);
+ if (IS_ERR(port->csr_base)) {
+ kfree(port);
+ return -ENOMEM;
+ }
+
+ port->cfg_base = cfg->win;
+ port->version = XGENE_PCIE_IP_VER_1;
+
+ cfg->priv = port;
+
+ return 0;
+}
+
+struct pci_ecam_ops xgene_v1_pcie_ecam_ops = {
+ .bus_shift = 16,
+ .init = xgene_v1_pcie_ecam_init,
+ .pci_ops = {
+ .map_bus = xgene_pcie_map_bus,
+ .read = xgene_pcie_config_read32,
+ .write = pci_generic_config_write,
+ }
+};
+
+static struct resource xgene_v2_1_csr_res[] = {
+ [0] = DEFINE_RES_MEM_NAMED(0x1f2b0000UL, SZ_64K, "PCIe CSR"),
+ [1] = DEFINE_RES_MEM_NAMED(0x1f2c0000UL, SZ_64K, "PCIe CSR"),
+};
+
+static int xgene_v2_1_pcie_ecam_init(struct pci_config_window *cfg)
+{
+ struct acpi_device *adev = to_acpi_device(cfg->parent);
+ struct acpi_pci_root *root = acpi_driver_data(adev);
+ struct device *dev = cfg->parent;
+ struct xgene_pcie_port *port;
+ struct resource *csr;
+
+ port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
+ if (!port)
+ return -ENOMEM;
+
+ csr = &xgene_v2_1_csr_res[root->segment];
+ port->csr_base = devm_ioremap_resource(dev, csr);
+ if (IS_ERR(port->csr_base)) {
+ kfree(port);
+ return -ENOMEM;
+ }
+
+ port->cfg_base = cfg->win;
+ port->version = XGENE_PCIE_IP_VER_2;
+
+ cfg->priv = port;
+
+ return 0;
+}
+
+struct pci_ecam_ops xgene_v2_1_pcie_ecam_ops = {
+ .bus_shift = 16,
+ .init = xgene_v2_1_pcie_ecam_init,
+ .pci_ops = {
+ .map_bus = xgene_pcie_map_bus,
+ .read = xgene_pcie_config_read32,
+ .write = pci_generic_config_write,
+ }
+};
+
+static struct resource xgene_v2_2_csr_res[] = {
+ [0] = DEFINE_RES_MEM_NAMED(0x1f2b0000UL, SZ_64K, "PCIe CSR"),
+ [1] = DEFINE_RES_MEM_NAMED(0x1f500000UL, SZ_64K, "PCIe CSR"),
+ [2] = DEFINE_RES_MEM_NAMED(0x1f2d0000UL, SZ_64K, "PCIe CSR"),
+};
+
+static int xgene_v2_2_pcie_ecam_init(struct pci_config_window *cfg)
+{
+ struct acpi_device *adev = to_acpi_device(cfg->parent);
+ struct acpi_pci_root *root = acpi_driver_data(adev);
+ struct device *dev = cfg->parent;
+ struct xgene_pcie_port *port;
+ struct resource *csr;
+
+ port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
+ if (!port)
+ return -ENOMEM;
+
+ csr = &xgene_v2_2_csr_res[root->segment];
+ port->csr_base = devm_ioremap_resource(dev, csr);
+ if (IS_ERR(port->csr_base)) {
+ kfree(port);
+ return -ENOMEM;
+ }
+
+ port->cfg_base = cfg->win;
+ port->version = XGENE_PCIE_IP_VER_2;
+
+ cfg->priv = port;
+
+ return 0;
+}
+
+struct pci_ecam_ops xgene_v2_2_pcie_ecam_ops = {
+ .bus_shift = 16,
+ .init = xgene_v2_2_pcie_ecam_init,
+ .pci_ops = {
+ .map_bus = xgene_pcie_map_bus,
+ .read = xgene_pcie_config_read32,
+ .write = pci_generic_config_write,
+ }
+};
+#endif
+
static u64 xgene_pcie_set_ib_mask(struct xgene_pcie_port *port, u32 addr,
u32 flags, u64 size)
{
diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
index f5740b7..47ab947 100644
--- a/include/linux/pci-ecam.h
+++ b/include/linux/pci-ecam.h
@@ -62,6 +62,13 @@ void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
/* ops for buggy ECAM that supports only 32-bit accesses */
extern struct pci_ecam_ops pci_32b_ops;
+/* ECAM ops for known quirks */
+#ifdef CONFIG_PCI_XGENE
+extern struct pci_ecam_ops xgene_v1_pcie_ecam_ops;
+extern struct pci_ecam_ops xgene_v2_1_pcie_ecam_ops;
+extern struct pci_ecam_ops xgene_v2_2_pcie_ecam_ops;
+#endif
+
#ifdef CONFIG_PCI_HOST_GENERIC
/* for DT-based PCI controllers that support ECAM */
int pci_host_common_probe(struct platform_device *pdev,
--
1.9.1
^ permalink raw reply related
* [PATCH] crypto: arm/aesbs - Select SIMD in Kconfig
From: Arnd Bergmann @ 2016-11-30 23:47 UTC (permalink / raw)
To: linux-arm-kernel
Commit 585b5fa63da9 ("crypto: arm/aes - Select SIMD in Kconfig") added
the dependency for CRYPTO_AES_ARM_CE, but missed the same change
for CRYPTO_AES_ARM_BS:
arch/arm/crypto/aes-arm-bs.o: In function `aesbs_mod_init':
aesbs-glue.c:(.init.text+0x38): undefined reference to `simd_skcipher_create_compat'
Fixes: 211f41af534a ("crypto: aesbs - Convert to skcipher")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/crypto/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 81348883450d..3251d385fddb 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -91,6 +91,7 @@ config CRYPTO_AES_ARM_BS
select CRYPTO_ALGAPI
select CRYPTO_AES_ARM
select CRYPTO_ABLK_HELPER
+ select CRYPTO_SIMD
help
Use a faster and more secure NEON based implementation of AES in CBC,
CTR and XTS modes
--
2.9.0
^ permalink raw reply related
* [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Bjorn Helgaas @ 2016-12-01 0:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479201298-25494-2-git-send-email-tn@semihalf.com>
Hi Tomasz,
On Tue, Nov 15, 2016 at 10:14:57AM +0100, Tomasz Nowicki wrote:
> ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
> compliant with ECAM standard. It uses non-standard configuration space
> accessors (see pci_thunder_pem_ops) and custom configuration space granulation
> (see bus_shift = 24). In order to access configuration space and
> probe PEM as ACPI based PCI host controller we need to add MCFG quirk
> infrastructure. This involves:
> 1. thunder_pem_init() ACPI extension so that we can probe PEM-specific
> register ranges analogously to DT
> 2. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
> code.
> 3. New quirk entries for each PEM segment. Each contains platform IDs,
> mentioned pci_thunder_pem_ops and CFG resources.
>
> Quirk is considered for ThunderX silicon pass2.x only which is identified
> via MCFG revision 1.
>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> ---
> drivers/acpi/pci_mcfg.c | 20 +++++++
> drivers/pci/host/pci-thunder-pem.c | 107 ++++++++++++++++++++++++++++++++-----
> include/linux/pci-ecam.h | 4 ++
> 3 files changed, 117 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index ac21db3..e4e2b9b 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -57,6 +57,26 @@ static struct mcfg_fixup mcfg_quirks[] = {
> { "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops },
> { "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops },
> { "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops },
> +#ifdef CONFIG_PCI_HOST_THUNDER_PEM
> +#define THUNDER_MCFG_RES(addr, node) \
> + DEFINE_RES_MEM(addr + (node << 44), 0x39 * SZ_16M)
> +#define THUNDER_MCFG_QUIRK(rev, node) \
> + { "CAVIUM", "THUNDERX", rev, 4 + (10 * node), MCFG_BUS_ANY, \
> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88001f000000UL, node) }, \
> + { "CAVIUM", "THUNDERX", rev, 5 + (10 * node), MCFG_BUS_ANY, \
> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x884057000000UL, node) }, \
> + { "CAVIUM", "THUNDERX", rev, 6 + (10 * node), MCFG_BUS_ANY, \
> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88808f000000UL, node) }, \
> + { "CAVIUM", "THUNDERX", rev, 7 + (10 * node), MCFG_BUS_ANY, \
> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89001f000000UL, node) }, \
> + { "CAVIUM", "THUNDERX", rev, 8 + (10 * node), MCFG_BUS_ANY, \
> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x894057000000UL, node) }, \
> + { "CAVIUM", "THUNDERX", rev, 9 + (10 * node), MCFG_BUS_ANY, \
> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89808f000000UL, node) }
> + /* SoC pass2.x */
> + THUNDER_MCFG_QUIRK(1, 0UL),
> + THUNDER_MCFG_QUIRK(1, 1UL),
> +#endif
I want all these quirks to work without having to enable
device-specific config options like CONFIG_PCI_HOST_THUNDER_PEM.
I tweaked the preceding MCFG quirk support to wrap it in
CONFIG_PCI_QUIRKS. I also tweaked the qualcomm and hisi patches to
move the meat of them to pci/quirks.c. My work-in-progress is on
pci/ecam, but I can't easily build for arm64, so there are likely some
issues to be resolved.
I'm hoping to end up with something like this:
https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=51ad4df79a9b7f2a66b346a46b21a785a2937469
The problem with ThunderX is that the config accessors are much bigger
and I don't really want to duplicate them in both pci/quirks.c and
pci-thunder-pem.c.
Actually, that raises a question for qualcomm and hisi: in the DT
model, we use non-ECAM config accessors in the driver, but in the ACPI
model, we use ECAM accessors. It seems like the accessors should be
the same regardless of whether we discover the bridge via DT or ACPI.
Anyway, it's almost like we want to build pci-thunder-pem.o if
CONFIG_PCI_HOST_THUNDER_PEM || (CONFIG_PCI_QUIRKS && CONFIG_ARM64).
I don't know how to express that nicely.
I was trying to avoid adding an ecam-quirks.c, but maybe we need to
add it and collect all the different accessors there and add #ifdefs
inside.
Sorry, this is only half-baked, but I just wanted to throw this out in
case you have any ideas.
> };
>
> static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
> diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
> index 6abaf80..7bdc4cd 100644
> --- a/drivers/pci/host/pci-thunder-pem.c
> +++ b/drivers/pci/host/pci-thunder-pem.c
> @@ -18,6 +18,7 @@
> #include <linux/init.h>
> #include <linux/of_address.h>
> #include <linux/of_pci.h>
> +#include <linux/pci-acpi.h>
> #include <linux/pci-ecam.h>
> #include <linux/platform_device.h>
>
> @@ -284,6 +285,84 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
> return pci_generic_config_write(bus, devfn, where, size, val);
> }
>
> +#ifdef CONFIG_ACPI
> +
> +/*
> + * Retrieve PEM bridge register base and size from PNP0C02 sub-device under
> + * the RC.
> + *
> + * Device (RES0)
> + * {
> + * Name (_HID, "THRX0002")
> + * Name (_CID, "PNP0C02")
> + * Name (_CRS, ResourceTemplate () {
> + * // Device specific registers range
> + * QWordMemory(ResourceConsumer, PosDecode, MinFixed,
> + * MaxFixed, Cacheable, ReadWrite, 0,
> + * 0x87e0c2000000, 0x87E0C2FFFFFF, 0, 0x1000000)
> + * })
> + * }
> + */
> +
> +static const struct acpi_device_id thunder_pem_reg_ids[] = {
> + {"THRX0002", 0},
> + {"", 0},
> +};
> +
> +static struct resource *thunder_pem_acpi_res(struct pci_config_window *cfg)
> +{
> + struct device *dev = cfg->parent;
> + struct acpi_device *adev = to_acpi_device(dev);
> + struct acpi_device *child_adev;
> + struct resource *res_pem;
> +
> + res_pem = devm_kzalloc(dev, sizeof(*res_pem), GFP_KERNEL);
> + if (!res_pem) {
> + dev_err(dev, "failed to allocate PEM resource\n");
> + return NULL;
> + }
> +
> + list_for_each_entry(child_adev, &adev->children, node) {
> + struct resource_entry *entry;
> + struct list_head list;
> + unsigned long flags;
> + int ret;
> +
> + ret = acpi_match_device_ids(child_adev, thunder_pem_reg_ids);
> + if (ret)
> + continue;
> +
> + INIT_LIST_HEAD(&list);
> + flags = IORESOURCE_MEM;
> + ret = acpi_dev_get_resources(child_adev, &list,
> + acpi_dev_filter_resource_type_cb,
> + (void *)flags);
> + if (ret < 0) {
> + dev_err(&child_adev->dev,
> + "failed to parse _CRS method, error code %d\n",
> + ret);
> + return NULL;
> + } else if (ret == 0) {
> + dev_err(&child_adev->dev,
> + "no memory resources present in _CRS\n");
> + return NULL;
> + }
> +
> + entry = list_first_entry(&list, struct resource_entry, node);
> + *res_pem = *entry->res;
> + acpi_dev_free_resource_list(&list);
> + return res_pem;
> + }
> +
> + return NULL;
> +}
> +#else
> +static struct resource *thunder_pem_acpi_res(struct pci_config_window *cfg)
> +{
> + return NULL;
> +}
> +#endif
> +
> static int thunder_pem_init(struct pci_config_window *cfg)
> {
> struct device *dev = cfg->parent;
> @@ -292,24 +371,24 @@ static int thunder_pem_init(struct pci_config_window *cfg)
> struct thunder_pem_pci *pem_pci;
> struct platform_device *pdev;
>
> - /* Only OF support for now */
> - if (!dev->of_node)
> - return -EINVAL;
> -
> pem_pci = devm_kzalloc(dev, sizeof(*pem_pci), GFP_KERNEL);
> if (!pem_pci)
> return -ENOMEM;
>
> - pdev = to_platform_device(dev);
> -
> - /*
> - * The second register range is the PEM bridge to the PCIe
> - * bus. It has a different config access method than those
> - * devices behind the bridge.
> - */
> - res_pem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (acpi_disabled) {
> + pdev = to_platform_device(dev);
> +
> + /*
> + * The second register range is the PEM bridge to the PCIe
> + * bus. It has a different config access method than those
> + * devices behind the bridge.
> + */
> + res_pem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + } else {
> + res_pem = thunder_pem_acpi_res(cfg);
> + }
> if (!res_pem) {
> - dev_err(dev, "missing \"reg[1]\"property\n");
> + dev_err(dev, "missing configuration region\n");
> return -EINVAL;
> }
>
> @@ -332,7 +411,7 @@ static int thunder_pem_init(struct pci_config_window *cfg)
> return 0;
> }
>
> -static struct pci_ecam_ops pci_thunder_pem_ops = {
> +struct pci_ecam_ops pci_thunder_pem_ops = {
> .bus_shift = 24,
> .init = thunder_pem_init,
> .pci_ops = {
> diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
> index f5740b7..3f2a98f 100644
> --- a/include/linux/pci-ecam.h
> +++ b/include/linux/pci-ecam.h
> @@ -58,6 +58,10 @@ void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
> int where);
> /* default ECAM ops */
> extern struct pci_ecam_ops pci_generic_ecam_ops;
> +/* ECAM ops for known quirks */
> +#ifdef CONFIG_PCI_HOST_THUNDER_PEM
> +extern struct pci_ecam_ops pci_thunder_pem_ops;
> +#endif
>
> /* ops for buggy ECAM that supports only 32-bit accesses */
> extern struct pci_ecam_ops pci_32b_ops;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode
From: Hongzhou Yang @ 2016-12-01 0:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <42f5df18-2edd-08f2-a833-9c92ac85e87c@gmail.com>
On Wed, 2016-11-23 at 19:32 +0100, Matthias Brugger wrote:
> Hi Hongzhou,
>
> On 12/05/16 04:55, Hongzhou Yang wrote:
> > On Wed, 2016-05-11 at 19:09 -0700, Hongzhou Yang wrote:
> >> On Thu, 2016-05-12 at 09:41 +0800, chunfeng yun wrote:
> >>> Hi,
> >>>
> >>> On Wed, 2016-05-11 at 11:32 -0700, Hongzhou Yang wrote:
> >>>> On Wed, 2016-05-11 at 13:56 +0200, Linus Walleij wrote:
> >>>>> On Tue, May 10, 2016 at 10:23 AM, Chunfeng Yun
> >>>>> <chunfeng.yun@mediatek.com> wrote:
> >>>>>
> >>>>>> the default mode of GPIO16 pin is gpio, when set EINT16 to
> >>>>>> IRQ_TYPE_LEVEL_HIGH, no interrupt is triggered, it can be
> >>>>>> fixed when set its default mode as usb iddig.
> >>>>>>
> >>>>>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> >>>>>
> >>>>
> >>>> Chunfeng, GPIO16 can be used as EINT16 mode, but the pinmux should be 0.
> >>>> If you want to set its default mode to iddig, you should set it in dts.
> >>>>
> >>> I set it in DTS, but it didn't work, because when usb driver requested
> >>> IRQ, pinmux was switched back to default mode set by
> >>> MTK_EINT_FUNCTION().
> >>>
> >>
> >> After confirmed, there are something wrong with data sheet and pinmux
> >> table, and GPIO16 can only receive interrupt by mode 1. So
> >>
> >> Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
> >>
> >
> > Linus,
> >
> > We find there are some other pins still have the same problem, so please
> > hold on it. Sorry for so much noise.
> >
>
> Did you made any progress on this? I didn't see any patch on the mailing
> list.
>
> Regards,
> Matthias
Hi Matthias,
Sorry for the late reply.
I have double confirmed with HW designer, other special EINTs are
built-in and they are using internal signal, they are not triggered
by GPIO, only GPIO16 should set to mode 1.
And, Chunfeng already re-sent this patch.
Thank you very much.
Yours,
Hongzhou
^ permalink raw reply
* [RESEND PATCH] pinctrl: mt8173: set GPIO16 to usb iddig mode
From: Hongzhou Yang @ 2016-12-01 0:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480472491-4644-1-git-send-email-chunfeng.yun@mediatek.com>
On Wed, 2016-11-30 at 10:21 +0800, Chunfeng Yun wrote:
> the default mode of GPIO16 pin is gpio, when set EINT16 to
> IRQ_TYPE_LEVEL_HIGH, no interrupt is triggered, it can be
> fixed when set its default mode as usb iddig.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-mt8173.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-mt8173.h b/drivers/pinctrl/mediatek/pinctrl-mtk-mt8173.h
> index 13e5b68..9b018fd 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-mt8173.h
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-mt8173.h
> @@ -201,7 +201,7 @@
> MTK_PIN(
> PINCTRL_PIN(16, "IDDIG"),
> NULL, "mt8173",
> - MTK_EINT_FUNCTION(0, 16),
> + MTK_EINT_FUNCTION(1, 16),
> MTK_FUNCTION(0, "GPIO16"),
> MTK_FUNCTION(1, "IDDIG"),
> MTK_FUNCTION(2, "CMFLASH"),
Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
Thanks,
Hongzhou
^ permalink raw reply
* [resend V2:PATCH 0/2] add reset-hi3660
From: Zhangfei Gao @ 2016-12-01 0:48 UTC (permalink / raw)
To: linux-arm-kernel
Considering Arnd and Philipp suggestions,
move reset register to dts as table instead of dts header in case of ABI issue
Zhangfei Gao (2):
dt-bindings: Document the hi3660 reset bindings
reset: hisilicon: add reset-hi3660
.../bindings/reset/hisilicon,hi3660-reset.txt | 51 ++++++++
drivers/reset/hisilicon/Kconfig | 7 +
drivers/reset/hisilicon/Makefile | 1 +
drivers/reset/hisilicon/reset-hi3660.c | 144 +++++++++++++++++++++
4 files changed, 203 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
create mode 100644 drivers/reset/hisilicon/reset-hi3660.c
--
2.7.4
^ permalink raw reply
* [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Zhangfei Gao @ 2016-12-01 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480553321-17400-1-git-send-email-zhangfei.gao@linaro.org>
Add DT bindings documentation for hi3660 SoC reset controller.
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
---
.../bindings/reset/hisilicon,hi3660-reset.txt | 51 ++++++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
new file mode 100644
index 0000000..250daf2
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
@@ -0,0 +1,51 @@
+Hisilicon System Reset Controller
+======================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+The reset controller registers are part of the system-ctl block on
+hi3660 SoC.
+
+Required properties:
+- compatible: should be
+ "hisilicon,hi3660-reset"
+- #reset-cells: 1, see below
+- hisi,rst-syscon: phandle of the reset's syscon.
+- hisi,reset-bits: Contains the reset control register information
+ Should contain 2 cells for each reset exposed to
+ consumers, defined as:
+ Cell #1 : offset from the syscon register base
+ Cell #2 : bits position of the control register
+
+Example:
+ iomcu: iomcu at ffd7e000 {
+ compatible = "hisilicon,hi3660-iomcu", "syscon";
+ reg = <0x0 0xffd7e000 0x0 0x1000>;
+ };
+
+ iomcu_rst: iomcu_rst_controller {
+ compatible = "hisilicon,hi3660-reset";
+ #reset-cells = <1>;
+ hisi,rst-syscon = <&iomcu>;
+ hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
+ 0x20 0x10 /* 1: i2c1 */
+ 0x20 0x20 /* 2: i2c2 */
+ 0x20 0x8000000>; /* 3: i2c6 */
+ };
+
+Specifying reset lines connected to IP modules
+==============================================
+example:
+
+ i2c0: i2c at ..... {
+ ...
+ resets = <&iomcu_rst 0>;
+ ...
+ };
+
+ i2c1: i2c at ..... {
+ ...
+ resets = <&iomcu_rst 1>;
+ ...
+ };
--
2.7.4
^ permalink raw reply related
* [resend V2: PATCH 2/2] reset: hisilicon: add reset-hi3660
From: Zhangfei Gao @ 2016-12-01 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480553321-17400-1-git-send-email-zhangfei.gao@linaro.org>
Add hi3660 reset driver
Reset offset & bits should be listed in dts
Like:
iomcu_rst: iomcu_rst_controller {
compatible = "hisilicon,hi3660-reset";
#reset-cells = <1>;
hisi,rst-syscon = <&iomcu>;
hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
0x20 0x10 /* 1: i2c1 */
0x20 0x20 /* 2: i2c2 */
0x20 0x8000000>; /* 3: i2c6 */
};
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
---
drivers/reset/hisilicon/Kconfig | 7 ++
drivers/reset/hisilicon/Makefile | 1 +
drivers/reset/hisilicon/reset-hi3660.c | 144 +++++++++++++++++++++++++++++++++
3 files changed, 152 insertions(+)
create mode 100644 drivers/reset/hisilicon/reset-hi3660.c
diff --git a/drivers/reset/hisilicon/Kconfig b/drivers/reset/hisilicon/Kconfig
index 1ff8b0c..10134dc 100644
--- a/drivers/reset/hisilicon/Kconfig
+++ b/drivers/reset/hisilicon/Kconfig
@@ -1,3 +1,10 @@
+config COMMON_RESET_HI3660
+ tristate "Hi3660 Reset Driver"
+ depends on ARCH_HISI || COMPILE_TEST
+ default ARCH_HISI
+ help
+ Build the Hisilicon Hi3660 reset driver.
+
config COMMON_RESET_HI6220
tristate "Hi6220 Reset Driver"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/reset/hisilicon/Makefile b/drivers/reset/hisilicon/Makefile
index c932f86..ab8a7bf 100644
--- a/drivers/reset/hisilicon/Makefile
+++ b/drivers/reset/hisilicon/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_COMMON_RESET_HI6220) += hi6220_reset.o
+obj-$(CONFIG_COMMON_RESET_HI3660) += reset-hi3660.o
diff --git a/drivers/reset/hisilicon/reset-hi3660.c b/drivers/reset/hisilicon/reset-hi3660.c
new file mode 100644
index 0000000..3307252
--- /dev/null
+++ b/drivers/reset/hisilicon/reset-hi3660.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (c) 2016-2017 Linaro Ltd.
+ * Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd.
+ *
+ * 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/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>
+
+struct hi3660_reset_data {
+ unsigned int off;
+ unsigned int bits;
+};
+
+struct hi3660_reset_controller {
+ struct reset_controller_dev rst;
+ struct regmap *map;
+ const struct hi3660_reset_data *datas;
+};
+
+#define to_hi3660_reset_controller(_rst) \
+ container_of(_rst, struct hi3660_reset_controller, rst)
+
+static int hi3660_reset_program_hw(struct reset_controller_dev *rcdev,
+ unsigned long idx, bool assert)
+{
+ struct hi3660_reset_controller *rc = to_hi3660_reset_controller(rcdev);
+ const struct hi3660_reset_data *d;
+
+ if (idx >= rcdev->nr_resets)
+ return -EINVAL;
+
+ d = &rc->datas[idx];
+
+ if (assert)
+ return regmap_write(rc->map, d->off, d->bits);
+ else
+ return regmap_write(rc->map, d->off + 4, d->bits);
+}
+
+static int hi3660_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ return hi3660_reset_program_hw(rcdev, idx, true);
+}
+
+static int hi3660_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ return hi3660_reset_program_hw(rcdev, idx, false);
+}
+
+static int hi3660_reset_dev(struct reset_controller_dev *rcdev,
+ unsigned long idx)
+{
+ int err;
+
+ err = hi3660_reset_assert(rcdev, idx);
+ if (err)
+ return err;
+
+ return hi3660_reset_deassert(rcdev, idx);
+}
+
+static struct reset_control_ops hi3660_reset_ops = {
+ .reset = hi3660_reset_dev,
+ .assert = hi3660_reset_assert,
+ .deassert = hi3660_reset_deassert,
+};
+
+static int hi3660_reset_probe(struct platform_device *pdev)
+{
+ struct hi3660_reset_controller *rc;
+ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct hi3660_reset_data *datas;
+ const __be32 *list;
+ int size, nr, i;
+
+ rc = devm_kzalloc(dev, sizeof(*rc), GFP_KERNEL);
+ if (!rc)
+ return -ENOMEM;
+
+ rc->map = syscon_regmap_lookup_by_phandle(np, "hisi,rst-syscon");
+ if (IS_ERR(rc->map)) {
+ dev_err(dev, "failed to get hi3660,rst-syscon\n");
+ return PTR_ERR(rc->map);
+ }
+
+ list = of_get_property(np, "hisi,reset-bits", &size);
+ if (!list || (size / sizeof(*list)) % 2 != 0) {
+ dev_err(dev, "invalid DT reset description\n");
+ return -EINVAL;
+ }
+
+ nr = (size / sizeof(*list)) / 2;
+ datas = devm_kzalloc(dev, nr * sizeof(*datas), GFP_KERNEL);
+ if (!datas)
+ return -ENOMEM;
+
+ for (i = 0; i < nr; i++) {
+ datas[i].off = be32_to_cpup(list++);
+ datas[i].bits = be32_to_cpup(list++);
+ }
+
+ rc->rst.ops = &hi3660_reset_ops,
+ rc->rst.of_node = np;
+ rc->rst.nr_resets = nr;
+ rc->datas = datas;
+
+ return reset_controller_register(&rc->rst);
+}
+
+static const struct of_device_id hi3660_reset_match[] = {
+ { .compatible = "hisilicon,hi3660-reset", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, hi3660_reset_match);
+
+static struct platform_driver hi3660_reset_driver = {
+ .probe = hi3660_reset_probe,
+ .driver = {
+ .name = "hi3660-reset",
+ .of_match_table = hi3660_reset_match,
+ },
+};
+
+static int __init hi3660_reset_init(void)
+{
+ return platform_driver_register(&hi3660_reset_driver);
+}
+arch_initcall(hi3660_reset_init);
+
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:hi3660-reset");
+MODULE_DESCRIPTION("HiSilicon Hi3660 Reset Driver");
--
2.7.4
^ permalink raw reply related
* [rtc-linux] Re: [RFC PATCH 2/3] rtc: Add Amlogic Virtual Wake RTC
From: Alexandre Belloni @ 2016-12-01 0:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103153647.GD25852@remoulade>
On 03/11/2016 at 15:36:48 +0000, Mark Rutland wrote :
> > In order to be able to reuse the RTC wakealarm feature, this
> > driver implements a fake RTC device which uses the system time
> > to deduce a suspend delay.
>
> This sounds like an always-on oneshot timer device, not an RTC.
>
> > +static int meson_vrtc_read_time(struct device *dev, struct rtc_time *tm)
> > +{
> > + unsigned long local_time;
> > + struct timeval time;
> > +
> > + do_gettimeofday(&time);
> > + local_time = time.tv_sec - (sys_tz.tz_minuteswest * 60);
> > + rtc_time_to_tm(local_time, tm);
> > +
> > + return 0;
> > +}
>
> ... if this were a timer, you wouldn't need this hack.
>
The main issue I think is that the clockevents are not able to wakeup a
platform so it doesn't really fit as a timer inside the kernel.
I think it may be fine to handle that in the RTC subsystem for now.
The same issue can be seen with the flextimer on LS1021A:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/365597.html
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Sinan Kaya @ 2016-12-01 1:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201002812.GB9409@bhelgaas-glaptop.roam.corp.google.com>
Hi Bjorn,
On 11/30/2016 7:28 PM, Bjorn Helgaas wrote:
> Actually, that raises a question for qualcomm and hisi: in the DT
> model, we use non-ECAM config accessors in the driver, but in the ACPI
> model, we use ECAM accessors. It seems like the accessors should be
> the same regardless of whether we discover the bridge via DT or ACPI.
For servers, we are only setting up the PCIe controller in ECAM mode in FW.
If somebody wants to use DT with QCOM Server (unsupported but possible),
they need to use pci-host-ecam-generic driver.
Here is an example:
pcie3 {
compatible = "pci-host-ecam-generic";
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
bus-range = <0x0 0xff>;
linux,pci-domain = <3>;
// CPU_PHYSICAL(2) SIZE(2)
reg = <0xC00 0x00000000 0x0 0x10000000>;
...
}
I think you are referring to this driver here.
obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
This driver is only in use by the mobile products.
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v10 10/13] drm/mediatek: add dsi ulp mode control
From: CK Hu @ 2016-12-01 1:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480070076-6196-11-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> modify dsi enter ultra low power mode method
>
This looks like a power-saving patch. I think without this, MT2701 could
still work correctly. The commit message is too simple, please describe
why this patch is related to MT2701. If it is not related to MT2701,
move this patch out of MT2701 series and send it independently.
Regards,
CK
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index d03a0f1..01df829 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -289,7 +289,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
> {
> mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
> - mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
> + mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, LC_ULPM_EN);
> }
>
> static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
> @@ -302,7 +302,7 @@ static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
> static void mtk_dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
> {
> mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_HS_TX_EN, 0);
> - mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
> + mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, LD0_ULPM_EN);
> }
>
> static void mtk_dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
^ 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