* Re: [PATCH 1/6] drivers: pinctrl: add driver for Allwinner H5 SoC
From: Linus Walleij @ 2017-01-09 14:47 UTC (permalink / raw)
To: Maxime Ripard
Cc: Icenowy Zheng, Chen-Yu Tsai, Rob Herring, Andre Przywara,
linux-sunxi, linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-clk
In-Reply-To: <20170105220823.5ai4yvcblmzmaey2@lukather>
On Thu, Jan 5, 2017 at 11:08 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Tue, Dec 27, 2016 at 12:25:13AM +0800, Icenowy Zheng wrote:
>> +builtin_platform_driver(sun50i_h5_pinctrl_driver);
>
> This also looks very much like the H3. I'll post a patchset during the
> weekend to avoid duplicating those drivers. This was initially done
> for the sun5i, but it very much applies here.
I have applied Maxime's patch set from today.
Icenowy, please investigate the direction taken by Maxime
here for future revisions if needed.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: stm32: Add ADC support to stm32f429
From: Alexandre Torgue @ 2017-01-09 14:46 UTC (permalink / raw)
To: Fabrice GASNIER, mcoquelin.stm32@gmail.com, linux@armlinux.org.uk,
mark.rutland@arm.com, robh+dt@kernel.org
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1480687022-12851-3-git-send-email-fabrice.gasnier@st.com>
Hi Fabrice
On 12/02/2016 02:57 PM, Fabrice GASNIER wrote:
> Add ADC support & pinctrl analog phandle (adc3_in8) to stm32f429.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 49 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index 3dd47eb..be1d970 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -172,6 +172,49 @@
> status = "disabled";
> };
>
> + adc: adc@40012000 {
> + compatible = "st,stm32f4-adc-core";
> + reg = <0x40012000 0x400>;
> + interrupts = <18>;
> + clocks = <&rcc 0 168>;
> + clock-names = "adc";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> +
> + adc1: adc@0 {
> + compatible = "st,stm32f4-adc";
> + #io-channel-cells = <1>;
> + reg = <0x0>;
> + clocks = <&rcc 0 168>;
> + interrupt-parent = <&adc>;
> + interrupts = <0>;
> + status = "disabled";
> + };
> +
> + adc2: adc@100 {
> + compatible = "st,stm32f4-adc";
> + #io-channel-cells = <1>;
> + reg = <0x100>;
> + clocks = <&rcc 0 169>;
> + interrupt-parent = <&adc>;
> + interrupts = <1>;
> + status = "disabled";
> + };
> +
> + adc3: adc@200 {
> + compatible = "st,stm32f4-adc";
> + #io-channel-cells = <1>;
> + reg = <0x200>;
> + clocks = <&rcc 0 170>;
> + interrupt-parent = <&adc>;
> + interrupts = <2>;
> + status = "disabled";
> + };
> + };
> +
> syscfg: system-config@40013800 {
> compatible = "syscon";
> reg = <0x40013800 0x400>;
> @@ -334,6 +377,12 @@
> slew-rate = <2>;
> };
> };
> +
> + adc3_in8_pin: adc@200 {
> + pins {
> + pinmux = <STM32F429_PF10_FUNC_ANALOG>;
> + };
> + };
> };
>
> rcc: rcc@40023810 {
>
Applied on stm32-dt-for-v4.11
Thanks
Alex
^ permalink raw reply
* Re: [PATCH 1/3] ARM: configs: stm32: enable ADC driver
From: Alexandre Torgue @ 2017-01-09 14:46 UTC (permalink / raw)
To: Fabrice GASNIER, mcoquelin.stm32@gmail.com, linux@armlinux.org.uk,
mark.rutland@arm.com, robh+dt@kernel.org
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1480687022-12851-2-git-send-email-fabrice.gasnier@st.com>
Hi Fabrice
On 12/02/2016 02:57 PM, Fabrice GASNIER wrote:
> ADC driver depends on REGULATOR and IIO that are not yet selected.
> Current hardware boards (like stm32f429i-eval) is using fixed
> regulators.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> arch/arm/configs/stm32_defconfig | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
> index a60b5cb..92ccc3c 100644
> --- a/arch/arm/configs/stm32_defconfig
> +++ b/arch/arm/configs/stm32_defconfig
> @@ -49,6 +49,8 @@ CONFIG_SERIAL_STM32=y
> CONFIG_SERIAL_STM32_CONSOLE=y
> # CONFIG_HW_RANDOM is not set
> # CONFIG_HWMON is not set
> +CONFIG_REGULATOR=y
> +CONFIG_REGULATOR_FIXED_VOLTAGE=y
> # CONFIG_USB_SUPPORT is not set
> CONFIG_NEW_LEDS=y
> CONFIG_LEDS_CLASS=y
> @@ -57,6 +59,9 @@ CONFIG_LEDS_TRIGGERS=y
> CONFIG_LEDS_TRIGGER_HEARTBEAT=y
> CONFIG_DMADEVICES=y
> CONFIG_STM32_DMA=y
> +CONFIG_IIO=y
> +CONFIG_STM32_ADC_CORE=y
> +CONFIG_STM32_ADC=y
> # CONFIG_FILE_LOCKING is not set
> # CONFIG_DNOTIFY is not set
> # CONFIG_INOTIFY_USER is not set
>
Applied on stm32-defconfig-for-v4.11
Thanks.
Alex
^ permalink raw reply
* RE: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding
From: Ramesh Shanmugasundaram @ 2017-01-09 14:42 UTC (permalink / raw)
To: Hans Verkuil, Geert Uytterhoeven, Laurent Pinchart
Cc: Rob Herring, Mark Rutland, Mauro Carvalho Chehab, Sakari Ailus,
Antti Palosaari, Chris Paterson, Geert Uytterhoeven,
Linux Media Mailing List, devicetree@vger.kernel.org,
Linux-Renesas
In-Reply-To: <cca1ade8-01ef-8eab-f4b1-7dd7f204fdea@xs4all.nl>
Hi Hans,
Thanks for the review.
> >>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote:
> >>>> Add binding documentation for Renesas R-Car Digital Radio Interface
> >>>> (DRIF) controller.
> >>>>
> >>>> Signed-off-by: Ramesh Shanmugasundaram
> >>>> <ramesh.shanmugasundaram@bp.renesas.com> ---
> >>>> .../devicetree/bindings/media/renesas,drif.txt | 202
> >> ++++++++++++++++++
> >>>> 1 file changed, 202 insertions(+)
> >>>> create mode 100644
> >>>> Documentation/devicetree/bindings/media/renesas,drif.txt
> >>>>
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/media/renesas,drif.txt
> >>>> b/Documentation/devicetree/bindings/media/renesas,drif.txt new file
> >>>> mode
> >>>> 100644
> >>>> index 0000000..1f3feaf
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> >>
> >>>> +Optional properties of an internal channel when:
> >>>> + - It is the only enabled channel of the bond (or)
> >>>> + - If it acts as primary among enabled bonds
> >>>> +--------------------------------------------------------
> >>>> +- renesas,syncmd : sync mode
> >>>> + 0 (Frame start sync pulse mode. 1-bit width
> >> pulse
> >>>> + indicates start of a frame)
> >>>> + 1 (L/R sync or I2S mode) (default)
> >>>> +- renesas,lsb-first : empty property indicates lsb bit is
> received
> >>>> first.
> >>>> + When not defined msb bit is received first
> >>>> +(default)
> >>>> +- renesas,syncac-active: Indicates sync signal polarity, 0/1 for
> >> low/high
>
> Shouldn't this be 'renesas,sync-active' instead of syncac-active?
>
> I'm not sure if syncac is intended or if it is a typo.
Yes, "syncac" is intended. I kept the same name as in h/w manual for easy reference. Same for other properties - syncmd, dtdl & syncdl.
>
> >>>> + respectively. The default is 1 (active high)
> >>>> +- renesas,dtdl : delay between sync signal and start of
> >> reception.
> >>>> + The possible values are represented in 0.5
> clock
> >>>> + cycle units and the range is 0 to 4. The
> default
> >>>> + value is 2 (i.e.) 1 clock cycle delay.
> >>>> +- renesas,syncdl : delay between end of reception and sync
> >> signal
> >>>> edge.
> >>>> + The possible values are represented in 0.5
> clock
> >>>> + cycle units and the range is 0 to 4 & 6. The
> >> default
> >>>> + value is 0 (i.e.) no delay.
> >>>
> >>> Most of these properties are pretty similar to the video bus
> >>> properties defined at the endpoint level in
> >>> Documentation/devicetree/bindings/media/video-interfaces.txt. I
> >>> believe it would make sense to use OF graph and try to standardize
> >>> these properties similarly.
>
> Other than sync-active, is there really anything else that is similar? And
> even the sync-active isn't a good fit since here there is only one sync
> signal instead of two for video (h and vsync).
>
> Regards,
>
> Hans
>
Thanks,
Ramesh
^ permalink raw reply
* Re: [PATCH 01/10] doc: DT: camss: Binding document for Qualcomm Camera subsystem driver
From: Todor Tomov @ 2017-01-09 14:33 UTC (permalink / raw)
To: Rob Herring
Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w,
javier-JPH+aEBZ4P+UEJcrhfAQsw, s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <20161130220350.q37rbo2biaeg2sad@rob-hp-laptop>
Hi Rob,
Happy new year,
And thank you for the review.
On 12/01/2016 12:03 AM, Rob Herring wrote:
> On Fri, Nov 25, 2016 at 04:56:53PM +0200, Todor Tomov wrote:
>> Add DT binding document for Qualcomm Camera subsystem driver.
>>
>> Signed-off-by: Todor Tomov <todor.tomov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> .../devicetree/bindings/media/qcom,camss.txt | 196 +++++++++++++++++++++
>> 1 file changed, 196 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/qcom,camss.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt b/Documentation/devicetree/bindings/media/qcom,camss.txt
>> new file mode 100644
>> index 0000000..76ad89a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/qcom,camss.txt
>> @@ -0,0 +1,196 @@
>> +Qualcomm Camera Subsystem
>> +
>> +* Properties
>> +
>> +- compatible:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Should contain:
>> + - "qcom,8x16-camss"
>
> Don't use wildcards in compatible strings. One string per SoC.
Ok, I'll fix this.
>
>> +- reg:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: Register ranges as listed in the reg-names property.
>> +- reg-names:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Should contain the following entries:
>> + - "csiphy0"
>> + - "csiphy0_clk_mux"
>> + - "csiphy1"
>> + - "csiphy1_clk_mux"
>> + - "csid0"
>> + - "csid1"
>> + - "ispif"
>> + - "csi_clk_mux"
>> + - "vfe0"
>
> Kind of looks like the phy's should be separate nodes since each phy has
> its own register range, irq, clocks, etc.
Yes, there are a lot of hardware resources here.
I have decided to keep everything into a single platform device as this
represents it better from system point of view.
>
>> +- interrupts:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: Interrupts as listed in the interrupt-names property.
>> +- interrupt-names:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Should contain the following entries:
>> + - "csiphy0"
>> + - "csiphy1"
>> + - "csid0"
>> + - "csid1"
>> + - "ispif"
>> + - "vfe0"
>> +- power-domains:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: A phandle and power domain specifier pairs to the
>> + power domain which is responsible for collapsing
>> + and restoring power to the peripheral.
>> +- clocks:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: A list of phandle and clock specifier pairs as listed
>> + in clock-names property.
>> +- clock-names:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Should contain the following entries:
>> + - "camss_top_ahb_clk"
>> + - "ispif_ahb_clk"
>> + - "csiphy0_timer_clk"
>> + - "csiphy1_timer_clk"
>> + - "csi0_ahb_clk"
>> + - "csi0_clk"
>> + - "csi0_phy_clk"
>> + - "csi0_pix_clk"
>> + - "csi0_rdi_clk"
>> + - "csi1_ahb_clk"
>> + - "csi1_clk"
>> + - "csi1_phy_clk"
>> + - "csi1_pix_clk"
>> + - "csi1_rdi_clk"
>> + - "camss_ahb_clk"
>> + - "camss_vfe_vfe_clk"
>> + - "camss_csi_vfe_clk"
>> + - "iface_clk"
>> + - "bus_clk"
>> +- vdda-supply:
>> + Usage: required
>> + Value type: <phandle>
>> + Definition: A phandle to voltage supply for CSI2.
>> +- iommus:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: A list of phandle and IOMMU specifier pairs.
>> +
>> +* Nodes
>> +
>> +- ports:
>> + Usage: required
>> + Definition: As described in video-interfaces.txt in same directory.
>> + Properties:
>> + - reg:
>> + Usage: required
>> + Value type: <u32>
>> + Definition: Selects CSI2 PHY interface - PHY0 or PHY1.
>> + Endpoint node properties:
>> + - clock-lanes:
>> + Usage: required
>> + Value type: <u32>
>> + Definition: The clock lane.
>> + - data-lanes:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: An array of data lanes.
>> + - qcom,settle-cnt:
>
> This should go in phy node ideally.
>
>> + Usage: required
>> + Value type: <u32>
>> + Definition: The settle count parameter for CSI PHY.
>> +
>> +* An Example
>> +
>> + camss: camss@1b00000 {
>> + compatible = "qcom,8x16-camss";
>> + reg = <0x1b0ac00 0x200>,
>> + <0x1b00030 0x4>,
>> + <0x1b0b000 0x200>,
>> + <0x1b00038 0x4>,
>> + <0x1b08000 0x100>,
>> + <0x1b08400 0x100>,
>> + <0x1b0a000 0x500>,
>> + <0x1b00020 0x10>,
>> + <0x1b10000 0x1000>;
>> + reg-names = "csiphy0",
>> + "csiphy0_clk_mux",
>> + "csiphy1",
>> + "csiphy1_clk_mux",
>> + "csid0",
>> + "csid1",
>> + "ispif",
>> + "csi_clk_mux",
>> + "vfe0";
>> + interrupts = <GIC_SPI 78 0>,
>> + <GIC_SPI 79 0>,
>> + <GIC_SPI 51 0>,
>> + <GIC_SPI 52 0>,
>> + <GIC_SPI 55 0>,
>> + <GIC_SPI 57 0>;
>> + interrupt-names = "csiphy0",
>> + "csiphy1",
>> + "csid0",
>> + "csid1",
>> + "ispif",
>> + "vfe0";
>> + power-domains = <&gcc VFE_GDSC>;
>> + clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
>> + <&gcc GCC_CAMSS_ISPIF_AHB_CLK>,
>> + <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
>> + <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
>> + <&gcc GCC_CAMSS_CSI0_AHB_CLK>,
>> + <&gcc GCC_CAMSS_CSI0_CLK>,
>> + <&gcc GCC_CAMSS_CSI0PHY_CLK>,
>> + <&gcc GCC_CAMSS_CSI0PIX_CLK>,
>> + <&gcc GCC_CAMSS_CSI0RDI_CLK>,
>> + <&gcc GCC_CAMSS_CSI1_AHB_CLK>,
>> + <&gcc GCC_CAMSS_CSI1_CLK>,
>> + <&gcc GCC_CAMSS_CSI1PHY_CLK>,
>> + <&gcc GCC_CAMSS_CSI1PIX_CLK>,
>> + <&gcc GCC_CAMSS_CSI1RDI_CLK>,
>> + <&gcc GCC_CAMSS_AHB_CLK>,
>> + <&gcc GCC_CAMSS_VFE0_CLK>,
>> + <&gcc GCC_CAMSS_CSI_VFE0_CLK>,
>> + <&gcc GCC_CAMSS_VFE_AHB_CLK>,
>> + <&gcc GCC_CAMSS_VFE_AXI_CLK>;
>> + clock-names = "camss_top_ahb_clk",
>> + "ispif_ahb_clk",
>> + "csiphy0_timer_clk",
>> + "csiphy1_timer_clk",
>> + "csi0_ahb_clk",
>> + "csi0_clk",
>> + "csi0_phy_clk",
>> + "csi0_pix_clk",
>> + "csi0_rdi_clk",
>> + "csi1_ahb_clk",
>> + "csi1_clk",
>> + "csi1_phy_clk",
>> + "csi1_pix_clk",
>> + "csi1_rdi_clk",
>> + "camss_ahb_clk",
>> + "camss_vfe_vfe_clk",
>> + "camss_csi_vfe_clk",
>> + "iface_clk",
>> + "bus_clk";
>> + vdda-supply = <&pm8916_l2>;
>> + iommus = <&apps_iommu 3>;
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + port@0 {
>> + reg = <0>;
>> + csiphy0_ep: endpoint {
>> + clock-lanes = <1>;
>> + data-lanes = <0 2>;
>> + qcom,settle-cnt = <0xe>;
>> + remote-endpoint = <&ov5645_ep>;
>> + };
>> + };
>> + };
>> + };
>> --
>> 1.9.1
>>
--
Best regards,
Todor Tomov
--
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 V2 4/5] PCI: exynos: support the using PHY generic framework
From: Alim Akhtar @ 2017-01-09 13:39 UTC (permalink / raw)
To: Jaehoon Chung, linux-pci
Cc: devicetree, linux-kernel, linux-samsung-soc, bhelgaas, robh+dt,
mark.rutland, kgene, krzk, kishon, jingoohan1, vivek.gautam,
pankaj.dubey, cpgs
In-Reply-To: <20170104123435.30740-5-jh80.chung@samsung.com>
Hi Jaehoon,
On 01/04/2017 06:04 PM, Jaehoon Chung wrote:
> This patch is for using PHY generic framework.
> To maintain backward compatibility, check whether phy is supported or
> not with 'using_phy'.
>
> And if someone use the old dt-file, display the "deprecated" message.
> But it's still working fine with it.
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> ---
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
> Changelog on V2:
> - This patch is split from previous PATCH[1/4]
> - Maintain the backward compatibility
> - Adds 'using_phy' for cheching whether phy framework is used or not
> - Adds 'DEPRECATED' message for old dt-binding way
>
> drivers/pci/host/pci-exynos.c | 61 +++++++++++++++++++++++++++++++++++--------
> 1 file changed, 50 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
> index feed0fd..34f2eed 100644
> --- a/drivers/pci/host/pci-exynos.c
> +++ b/drivers/pci/host/pci-exynos.c
> @@ -21,6 +21,7 @@
> #include <linux/of_gpio.h>
> #include <linux/pci.h>
> #include <linux/platform_device.h>
> +#include <linux/phy/phy.h>
> #include <linux/resource.h>
> #include <linux/signal.h>
> #include <linux/types.h>
> @@ -110,6 +111,10 @@ struct exynos_pcie {
> struct exynos_pcie_clk_res *clk_res;
> const struct exynos_pcie_ops *ops;
> int reset_gpio;
> +
> + /* For Generic PHY Framework */
> + bool using_phy;
> + struct phy *phy;
> };
>
> struct exynos_pcie_ops {
> @@ -135,6 +140,10 @@ static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
> if (IS_ERR(ep->mem_res->elbi_base))
> return PTR_ERR(ep->mem_res->elbi_base);
>
> + /* If using the PHY framework, doesn't need to get other resource */
> + if (ep->using_phy)
> + return 0;
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> ep->mem_res->phy_base = devm_ioremap_resource(dev, res);
> if (IS_ERR(ep->mem_res->phy_base))
> @@ -396,17 +405,28 @@ static int exynos_pcie_establish_link(struct exynos_pcie *exynos_pcie)
> }
>
> exynos_pcie_assert_core_reset(exynos_pcie);
> - exynos_pcie_assert_phy_reset(exynos_pcie);
> - exynos_pcie_deassert_phy_reset(exynos_pcie);
> - exynos_pcie_power_on_phy(exynos_pcie);
> - exynos_pcie_init_phy(exynos_pcie);
> -
> - /* pulse for common reset */
> - exynos_pcie_writel(exynos_pcie->mem_res->block_base, 1,
> - PCIE_PHY_COMMON_RESET);
> - udelay(500);
> - exynos_pcie_writel(exynos_pcie->mem_res->block_base, 0,
> - PCIE_PHY_COMMON_RESET);
> +
> + if (exynos_pcie->using_phy) {
> + phy_reset(exynos_pcie->phy);
> +
> + exynos_pcie_writel(exynos_pcie->mem_res->elbi_base, 1,
> + PCIE_PWR_RESET);
> +
> + phy_power_on(exynos_pcie->phy);
> + phy_init(exynos_pcie->phy);
> + } else {
> + exynos_pcie_assert_phy_reset(exynos_pcie);
> + exynos_pcie_deassert_phy_reset(exynos_pcie);
> + exynos_pcie_power_on_phy(exynos_pcie);
> + exynos_pcie_init_phy(exynos_pcie);
> +
> + /* pulse for common reset */
> + exynos_pcie_writel(exynos_pcie->mem_res->block_base, 1,
> + PCIE_PHY_COMMON_RESET);
> + udelay(500);
> + exynos_pcie_writel(exynos_pcie->mem_res->block_base, 0,
> + PCIE_PHY_COMMON_RESET);
> + }
>
> exynos_pcie_deassert_core_reset(exynos_pcie);
> dw_pcie_setup_rc(pp);
> @@ -420,6 +440,11 @@ static int exynos_pcie_establish_link(struct exynos_pcie *exynos_pcie)
> if (!dw_pcie_wait_for_link(pp))
> return 0;
>
> + if (exynos_pcie->using_phy) {
> + phy_power_off(exynos_pcie->phy);
> + return -ETIMEDOUT;
> + }
> +
> while (exynos_pcie_readl(exynos_pcie->mem_res->phy_base,
> PCIE_PHY_PLL_LOCKED) == 0) {
> val = exynos_pcie_readl(exynos_pcie->mem_res->block_base,
> @@ -633,6 +658,17 @@ static int __init exynos_pcie_probe(struct platform_device *pdev)
>
> exynos_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
>
> + /* Assume that controller doesn't use the PHY framework */
> + exynos_pcie->using_phy = false;
> +
> + exynos_pcie->phy = devm_of_phy_get(dev, np, NULL);
> + if (IS_ERR(exynos_pcie->phy)) {
> + if (PTR_ERR(exynos_pcie->phy) == -EPROBE_DEFER)
> + return PTR_ERR(exynos_pcie->phy);
> + dev_warn(dev, "Use the 'phy' property. Current DT of pci-exynos was deprecated!!\n");
> + } else
> + exynos_pcie->using_phy = true;
> +
> if (exynos_pcie->ops && exynos_pcie->ops->get_mem_resources) {
> ret = exynos_pcie->ops->get_mem_resources(pdev, exynos_pcie);
> if (ret)
> @@ -657,6 +693,9 @@ static int __init exynos_pcie_probe(struct platform_device *pdev)
> return 0;
>
> fail_probe:
> + if (exynos_pcie->using_phy)
> + phy_exit(exynos_pcie->phy);
> +
> if (exynos_pcie->ops && exynos_pcie->ops->deinit_clk_resources)
> exynos_pcie->ops->deinit_clk_resources(exynos_pcie);
> return ret;
>
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding
From: Hans Verkuil @ 2017-01-09 13:36 UTC (permalink / raw)
To: Ramesh Shanmugasundaram, Geert Uytterhoeven, Laurent Pinchart
Cc: Rob Herring, Mark Rutland, Mauro Carvalho Chehab, Sakari Ailus,
Antti Palosaari, Chris Paterson, Geert Uytterhoeven,
Linux Media Mailing List, devicetree@vger.kernel.org,
Linux-Renesas
In-Reply-To: <HK2PR06MB05453E11C8931F881E106939C36E0@HK2PR06MB0545.apcprd06.prod.outlook.com>
On 01/03/2017 04:20 PM, Ramesh Shanmugasundaram wrote:
> Hi Laurent, Geert,
>
> Thanks for the review comments.
>
>>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote:
>>>> Add binding documentation for Renesas R-Car Digital Radio Interface
>>>> (DRIF) controller.
>>>>
>>>> Signed-off-by: Ramesh Shanmugasundaram
>>>> <ramesh.shanmugasundaram@bp.renesas.com> ---
>>>> .../devicetree/bindings/media/renesas,drif.txt | 202
>> ++++++++++++++++++
>>>> 1 file changed, 202 insertions(+)
>>>> create mode 100644
>>>> Documentation/devicetree/bindings/media/renesas,drif.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
>>>> b/Documentation/devicetree/bindings/media/renesas,drif.txt new file
>>>> mode
>>>> 100644
>>>> index 0000000..1f3feaf
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>>
>>>> +Optional properties of an internal channel when:
>>>> + - It is the only enabled channel of the bond (or)
>>>> + - If it acts as primary among enabled bonds
>>>> +--------------------------------------------------------
>>>> +- renesas,syncmd : sync mode
>>>> + 0 (Frame start sync pulse mode. 1-bit width
>> pulse
>>>> + indicates start of a frame)
>>>> + 1 (L/R sync or I2S mode) (default)
>>>> +- renesas,lsb-first : empty property indicates lsb bit is received
>>>> first.
>>>> + When not defined msb bit is received first
>>>> +(default)
>>>> +- renesas,syncac-active: Indicates sync signal polarity, 0/1 for
>> low/high
Shouldn't this be 'renesas,sync-active' instead of syncac-active?
I'm not sure if syncac is intended or if it is a typo.
>>>> + respectively. The default is 1 (active high)
>>>> +- renesas,dtdl : delay between sync signal and start of
>> reception.
>>>> + The possible values are represented in 0.5 clock
>>>> + cycle units and the range is 0 to 4. The default
>>>> + value is 2 (i.e.) 1 clock cycle delay.
>>>> +- renesas,syncdl : delay between end of reception and sync
>> signal
>>>> edge.
>>>> + The possible values are represented in 0.5 clock
>>>> + cycle units and the range is 0 to 4 & 6. The
>> default
>>>> + value is 0 (i.e.) no delay.
>>>
>>> Most of these properties are pretty similar to the video bus
>>> properties defined at the endpoint level in
>>> Documentation/devicetree/bindings/media/video-interfaces.txt. I
>>> believe it would make sense to use OF graph and try to standardize
>>> these properties similarly.
Other than sync-active, is there really anything else that is similar? And
even the sync-active isn't a good fit since here there is only one sync
signal instead of two for video (h and vsync).
Regards,
Hans
>> Note that the last two properties match the those in
>> Documentation/devicetree/bindings/spi/sh-msiof.txt.
>> We may want to use one DRIF channel as a plain SPI slave with the
>> (modified) MSIOF driver in the future.
>
> Should I leave it as it is or modify these as in video-interfaces.txt? Shall we conclude on this please?
>
> Thanks,
> Ramesh
> N�����r��y���b�X��ǧv�^�){.n�+����{���bj)���w*\x1fjg���\x1e�����ݢj/���z�ޖ��2�ޙ���&�)ߡ�a��\x7f��\x1e�G���h�\x0f�j:+v���w�٥
>
^ permalink raw reply
* Re: [PATCH V2 3/5] Documetation: binding: modify the exynos5440 pcie binding
From: Alim Akhtar @ 2017-01-09 13:36 UTC (permalink / raw)
To: Jaehoon Chung, linux-pci
Cc: devicetree, linux-kernel, linux-samsung-soc, bhelgaas, robh+dt,
mark.rutland, kgene, krzk, kishon, jingoohan1, vivek.gautam,
pankaj.dubey, cpgs
In-Reply-To: <20170104123435.30740-4-jh80.chung@samsung.com>
Hi Jaehoon,
On 01/04/2017 06:04 PM, Jaehoon Chung wrote:
> According to using PHY framework, updates the exynos5440-pcie binding.
> For maintaining backward compatibility, leaves the current dt-binding.
> (It should be deprecated.)
>
> Recommends to use the Phy Framework and "config" property to follow
> the designware-pcie binding.
> If you use the old way, can see "mssing *config* reg space" message.
> Because the getting configuration space address from range is old way.
>
> NOTE: When use the "config" property, first name of 'reg-names' must be
> set to "elbi". Otherwise driver can't maintain the backward capability.
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> ---
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
> Changelog on V2:
> - Describes more commit message
> - Fixes the typos
> - Adds the new example for using PHY framework
> - Deprecated the old dt-binding description
> - Removes 'phy-names'
>
> .../bindings/pci/samsung,exynos5440-pcie.txt | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> index 4f9d23d..1d0af0e 100644
> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> @@ -7,8 +7,19 @@ Required properties:
> - compatible: "samsung,exynos5440-pcie"
> - reg: base addresses and lengths of the pcie controller,
> the phy controller, additional register for the phy controller.
> + (Registers for the phy controller are DEPRECATED.
> + Use the PHY framework.)
> +- reg-names : First name should be set to "elbi".
> + And use the "config" instead of getting the confgiruation address space
> + from "ranges".
> + NOTE: When use the "config" property, reg-names must be set.
> - interrupts: A list of interrupt outputs for level interrupt,
> pulse interrupt, special interrupt.
> +- phys: From PHY binding. Phandle for the Generic PHY.
> + Refer to Documentation/devicetree/bindings/phy/samsung-phy.txt
> +
> +Other common properties refer to
> + Documentation/devicetree/binding/pci/designware-pcie.txt
>
> Example:
>
> @@ -54,6 +65,24 @@ SoC specific DT Entry:
> num-lanes = <4>;
> };
>
> +With using PHY framework:
> + pcie_phy0: pcie-phy@270000 {
> + ...
> + reg = <0x270000 0x1000>, <0x271000 0x40>;
> + regn-names = "phy", "block";
> + ...
> + };
> +
> + pcie@290000 {
> + ...
> + reg = <0x290000 0x1000>, <0x40000000 0x1000>;
> + reg-names = "elbi", "config";
> + phys = <&pcie_phy0>;
> + ranges = <0x81000000 0 0 0x60001000 0 0x00010000
> + 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>;
> + ...
> + };
> +
> Board specific DT Entry:
>
> pcie@290000 {
>
^ permalink raw reply
* Re: [PATCH V2 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy
From: Alim Akhtar @ 2017-01-09 13:34 UTC (permalink / raw)
To: Jaehoon Chung, linux-pci
Cc: devicetree, linux-kernel, linux-samsung-soc, bhelgaas, robh+dt,
mark.rutland, kgene, krzk, kishon, jingoohan1, vivek.gautam,
pankaj.dubey, cpgs
In-Reply-To: <20170104123435.30740-3-jh80.chung@samsung.com>
Hi,
On 01/04/2017 06:04 PM, Jaehoon Chung wrote:
> This patch supports to use Generic Phy framework for Exynos PCIe phy.
> When Exynos that supported the pcie want to use the PCIe,
> it needs to control the phy resgister.
> But it should be more complex to control in their own PCIe device drivers.
>
> Currently, there is an exynos5440 case to support the pcie.
> So this driver is based on Exynos5440 PCIe.
> In future, will support the Other exynos SoCs likes exynos5433, exynos7.
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> ---
> Changelog on V2:
> - Not include the codes relevant to pci-exynos.
> - Remove the getting child node.
>
> drivers/phy/Kconfig | 9 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-exynos-pcie.c | 280 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 290 insertions(+)
> create mode 100644 drivers/phy/phy-exynos-pcie.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index e8eb7f2..2dddef4 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -331,6 +331,15 @@ config PHY_EXYNOS5_USBDRD
> This driver provides PHY interface for USB 3.0 DRD controller
> present on Exynos5 SoC series.
>
> +config PHY_EXYNOS_PCIE
> + bool "Exynos PCIe PHY driver"
> + depends on ARCH_EXYNOS && OF
Please add a depends on COMPILE_TEST as well.
Apart from this looks ok.
> + depends on PCI_EXYNOS
> + select GENERIC_PHY
> + help
> + Enable PCIe PHY support for Exynos SoC series.
> + This driver provides PHY interface for Exynos PCIe controller.
> +
> config PHY_PISTACHIO_USB
> tristate "IMG Pistachio USB2.0 PHY driver"
> depends on MACH_PISTACHIO
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 65eb2f4..081aeb4 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -37,6 +37,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
> phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
> phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) += phy-s5pv210-usb2.o
> obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
> +obj-$(CONFIG_PHY_EXYNOS_PCIE) += phy-exynos-pcie.o
> obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += phy-qcom-apq8064-sata.o
> obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2) += phy-rockchip-inno-usb2.o
> diff --git a/drivers/phy/phy-exynos-pcie.c b/drivers/phy/phy-exynos-pcie.c
> new file mode 100644
> index 0000000..b57f49b
> --- /dev/null
> +++ b/drivers/phy/phy-exynos-pcie.c
> @@ -0,0 +1,280 @@
> +/*
> + * Samsung EXYNOS SoC series PCIe PHY driver
> + *
> + * Phy provider for PCIe controller on Exynos SoC series
> + *
> + * Copyright (C) 2016 Samsung Electronics Co., Ltd.
> + * Jaehoon Chung <jh80.chung@samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/phy/phy.h>
> +#include <linux/regmap.h>
> +
> +/* PCIe Purple registers */
> +#define PCIE_PHY_GLOBAL_RESET 0x000
> +#define PCIE_PHY_COMMON_RESET 0x004
> +#define PCIE_PHY_CMN_REG 0x008
> +#define PCIE_PHY_MAC_RESET 0x00c
> +#define PCIE_PHY_PLL_LOCKED 0x010
> +#define PCIE_PHY_TRSVREG_RESET 0x020
> +#define PCIE_PHY_TRSV_RESET 0x024
> +
> +/* PCIe PHY registers */
> +#define PCIE_PHY_IMPEDANCE 0x004
> +#define PCIE_PHY_PLL_DIV_0 0x008
> +#define PCIE_PHY_PLL_BIAS 0x00c
> +#define PCIE_PHY_DCC_FEEDBACK 0x014
> +#define PCIE_PHY_PLL_DIV_1 0x05c
> +#define PCIE_PHY_COMMON_POWER 0x064
> +#define PCIE_PHY_COMMON_PD_CMN BIT(3)
> +#define PCIE_PHY_TRSV0_EMP_LVL 0x084
> +#define PCIE_PHY_TRSV0_DRV_LVL 0x088
> +#define PCIE_PHY_TRSV0_RXCDR 0x0ac
> +#define PCIE_PHY_TRSV0_POWER 0x0c4
> +#define PCIE_PHY_TRSV0_PD_TSV BIT(7)
> +#define PCIE_PHY_TRSV0_LVCC 0x0dc
> +#define PCIE_PHY_TRSV1_EMP_LVL 0x144
> +#define PCIE_PHY_TRSV1_RXCDR 0x16c
> +#define PCIE_PHY_TRSV1_POWER 0x184
> +#define PCIE_PHY_TRSV1_PD_TSV BIT(7)
> +#define PCIE_PHY_TRSV1_LVCC 0x19c
> +#define PCIE_PHY_TRSV2_EMP_LVL 0x204
> +#define PCIE_PHY_TRSV2_RXCDR 0x22c
> +#define PCIE_PHY_TRSV2_POWER 0x244
> +#define PCIE_PHY_TRSV2_PD_TSV BIT(7)
> +#define PCIE_PHY_TRSV2_LVCC 0x25c
> +#define PCIE_PHY_TRSV3_EMP_LVL 0x2c4
> +#define PCIE_PHY_TRSV3_RXCDR 0x2ec
> +#define PCIE_PHY_TRSV3_POWER 0x304
> +#define PCIE_PHY_TRSV3_PD_TSV BIT(7)
> +#define PCIE_PHY_TRSV3_LVCC 0x31c
> +
> +struct exynos_pcie_phy_data {
> + struct phy_ops *ops;
> +};
> +
> +/* For Exynos pcie phy */
> +struct exynos_pcie_phy {
> + const struct exynos_pcie_phy_data *drv_data;
> + void __iomem *phy_base;
> + void __iomem *blk_base; /* For exynos5440 */
> +};
> +
> +static void exynos_pcie_phy_writel(void __iomem *base, u32 val, u32 offset)
> +{
> + writel(val, base + offset);
> +}
> +
> +static u32 exynos_pcie_phy_readl(void __iomem *base, u32 offset)
> +{
> + return readl(base + offset);
> +}
> +
> +/* For Exynos5440 specific functions */
> +static int exynos5440_pcie_phy_init(struct phy *phy)
> +{
> + struct exynos_pcie_phy *ep = phy_get_drvdata(phy);
> +
> + /* DCC feedback control off */
> + exynos_pcie_phy_writel(ep->phy_base, 0x29, PCIE_PHY_DCC_FEEDBACK);
> +
> + /* set TX/RX impedance */
> + exynos_pcie_phy_writel(ep->phy_base, 0xd5, PCIE_PHY_IMPEDANCE);
> +
> + /* set 50Mhz PHY clock */
> + exynos_pcie_phy_writel(ep->phy_base, 0x14, PCIE_PHY_PLL_DIV_0);
> + exynos_pcie_phy_writel(ep->phy_base, 0x12, PCIE_PHY_PLL_DIV_1);
> +
> + /* set TX Differential output for lane 0 */
> + exynos_pcie_phy_writel(ep->phy_base, 0x7f, PCIE_PHY_TRSV0_DRV_LVL);
> +
> + /* set TX Pre-emphasis Level Control for lane 0 to minimum */
> + exynos_pcie_phy_writel(ep->phy_base, 0x0, PCIE_PHY_TRSV0_EMP_LVL);
> +
> + /* set RX clock and data recovery bandwidth */
> + exynos_pcie_phy_writel(ep->phy_base, 0xe7, PCIE_PHY_PLL_BIAS);
> + exynos_pcie_phy_writel(ep->phy_base, 0x82, PCIE_PHY_TRSV0_RXCDR);
> + exynos_pcie_phy_writel(ep->phy_base, 0x82, PCIE_PHY_TRSV1_RXCDR);
> + exynos_pcie_phy_writel(ep->phy_base, 0x82, PCIE_PHY_TRSV2_RXCDR);
> + exynos_pcie_phy_writel(ep->phy_base, 0x82, PCIE_PHY_TRSV3_RXCDR);
> +
> + /* change TX Pre-emphasis Level Control for lanes */
> + exynos_pcie_phy_writel(ep->phy_base, 0x39, PCIE_PHY_TRSV0_EMP_LVL);
> + exynos_pcie_phy_writel(ep->phy_base, 0x39, PCIE_PHY_TRSV1_EMP_LVL);
> + exynos_pcie_phy_writel(ep->phy_base, 0x39, PCIE_PHY_TRSV2_EMP_LVL);
> + exynos_pcie_phy_writel(ep->phy_base, 0x39, PCIE_PHY_TRSV3_EMP_LVL);
> +
> + /* set LVCC */
> + exynos_pcie_phy_writel(ep->phy_base, 0x20, PCIE_PHY_TRSV0_LVCC);
> + exynos_pcie_phy_writel(ep->phy_base, 0xa0, PCIE_PHY_TRSV1_LVCC);
> + exynos_pcie_phy_writel(ep->phy_base, 0xa0, PCIE_PHY_TRSV2_LVCC);
> + exynos_pcie_phy_writel(ep->phy_base, 0xa0, PCIE_PHY_TRSV3_LVCC);
> +
> + /* pulse for common reset */
> + exynos_pcie_phy_writel(ep->blk_base, 1, PCIE_PHY_COMMON_RESET);
> + udelay(500);
> + exynos_pcie_phy_writel(ep->blk_base, 0, PCIE_PHY_COMMON_RESET);
> +
> + return 0;
> +}
> +
> +static int exynos5440_pcie_phy_power_on(struct phy *phy)
> +{
> + struct exynos_pcie_phy *ep = phy_get_drvdata(phy);
> + u32 val;
> +
> + exynos_pcie_phy_writel(ep->blk_base, 0, PCIE_PHY_COMMON_RESET);
> + exynos_pcie_phy_writel(ep->blk_base, 0, PCIE_PHY_CMN_REG);
> + exynos_pcie_phy_writel(ep->blk_base, 0, PCIE_PHY_TRSVREG_RESET);
> + exynos_pcie_phy_writel(ep->blk_base, 0, PCIE_PHY_TRSV_RESET);
> +
> + val = exynos_pcie_phy_readl(ep->phy_base, PCIE_PHY_COMMON_POWER);
> + val &= ~PCIE_PHY_COMMON_PD_CMN;
> + exynos_pcie_phy_writel(ep->phy_base, val, PCIE_PHY_COMMON_POWER);
> +
> + val = exynos_pcie_phy_readl(ep->phy_base, PCIE_PHY_TRSV0_POWER);
> + val &= ~PCIE_PHY_TRSV0_PD_TSV;
> + exynos_pcie_phy_writel(ep->phy_base, val, PCIE_PHY_TRSV0_POWER);
> +
> + val = exynos_pcie_phy_readl(ep->phy_base, PCIE_PHY_TRSV1_POWER);
> + val &= ~PCIE_PHY_TRSV1_PD_TSV;
> + exynos_pcie_phy_writel(ep->phy_base, val, PCIE_PHY_TRSV1_POWER);
> +
> + val = exynos_pcie_phy_readl(ep->phy_base, PCIE_PHY_TRSV2_POWER);
> + val &= ~PCIE_PHY_TRSV2_PD_TSV;
> + exynos_pcie_phy_writel(ep->phy_base, val, PCIE_PHY_TRSV2_POWER);
> +
> + val = exynos_pcie_phy_readl(ep->phy_base, PCIE_PHY_TRSV3_POWER);
> + val &= ~PCIE_PHY_TRSV3_PD_TSV;
> + exynos_pcie_phy_writel(ep->phy_base, val, PCIE_PHY_TRSV3_POWER);
> +
> + return 0;
> +}
> +
> +static int exynos5440_pcie_phy_power_off(struct phy *phy)
> +{
> + struct exynos_pcie_phy *ep = phy_get_drvdata(phy);
> + u32 val;
> +
> + while (exynos_pcie_phy_readl(ep->phy_base,
> + PCIE_PHY_PLL_LOCKED) == 0) {
> + val = exynos_pcie_phy_readl(ep->blk_base,
> + PCIE_PHY_PLL_LOCKED);
> + dev_info(&phy->dev, "PLL Locked: 0x%x\n", val);
> + }
> +
> + val = exynos_pcie_phy_readl(ep->phy_base, PCIE_PHY_COMMON_POWER);
> + val |= PCIE_PHY_COMMON_PD_CMN;
> + exynos_pcie_phy_writel(ep->phy_base, val, PCIE_PHY_COMMON_POWER);
> +
> + val = exynos_pcie_phy_readl(ep->phy_base, PCIE_PHY_TRSV0_POWER);
> + val |= PCIE_PHY_TRSV0_PD_TSV;
> + exynos_pcie_phy_writel(ep->phy_base, val, PCIE_PHY_TRSV0_POWER);
> +
> + val = exynos_pcie_phy_readl(ep->phy_base, PCIE_PHY_TRSV1_POWER);
> + val |= PCIE_PHY_TRSV1_PD_TSV;
> + exynos_pcie_phy_writel(ep->phy_base, val, PCIE_PHY_TRSV1_POWER);
> +
> + val = exynos_pcie_phy_readl(ep->phy_base, PCIE_PHY_TRSV2_POWER);
> + val |= PCIE_PHY_TRSV2_PD_TSV;
> + exynos_pcie_phy_writel(ep->phy_base, val, PCIE_PHY_TRSV2_POWER);
> +
> + val = exynos_pcie_phy_readl(ep->phy_base, PCIE_PHY_TRSV3_POWER);
> + val |= PCIE_PHY_TRSV3_PD_TSV;
> + exynos_pcie_phy_writel(ep->phy_base, val, PCIE_PHY_TRSV3_POWER);
> +
> + return 0;
> +}
> +
> +static int exynos5440_pcie_phy_reset(struct phy *phy)
> +{
> + struct exynos_pcie_phy *ep = phy_get_drvdata(phy);
> +
> + exynos_pcie_phy_writel(ep->blk_base, 0, PCIE_PHY_MAC_RESET);
> + exynos_pcie_phy_writel(ep->blk_base, 1, PCIE_PHY_GLOBAL_RESET);
> + exynos_pcie_phy_writel(ep->blk_base, 0, PCIE_PHY_GLOBAL_RESET);
> +
> + return 0;
> +}
> +
> +static struct phy_ops exynos5440_phy_ops = {
> + .init = exynos5440_pcie_phy_init,
> + .power_on = exynos5440_pcie_phy_power_on,
> + .power_off = exynos5440_pcie_phy_power_off,
> + .reset = exynos5440_pcie_phy_reset,
> +};
> +
> +static const struct exynos_pcie_phy_data exynos5440_pcie_phy_data = {
> + .ops = &exynos5440_phy_ops,
> +};
> +
> +static const struct of_device_id exynos_pcie_phy_match[] = {
> + {
> + .compatible = "samsung,exynos5440-pcie-phy",
> + .data = &exynos5440_pcie_phy_data,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_pcie_phy_match);
> +
> +static int exynos_pcie_phy_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct exynos_pcie_phy *exynos_phy;
> + struct phy *generic_phy;
> + struct phy_provider *phy_provider;
> + struct resource *res;
> + const struct exynos_pcie_phy_data *drv_data;
> +
> + drv_data = of_device_get_match_data(dev);
> + if (!drv_data)
> + return -ENODEV;
> +
> + exynos_phy = devm_kzalloc(dev, sizeof(*exynos_phy), GFP_KERNEL);
> + if (!exynos_phy)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + exynos_phy->phy_base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(exynos_phy->phy_base))
> + return PTR_ERR(exynos_phy->phy_base);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + exynos_phy->blk_base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(exynos_phy->phy_base))
> + return PTR_ERR(exynos_phy->phy_base);
> +
> + exynos_phy->drv_data = drv_data;
> +
> + generic_phy = devm_phy_create(dev, dev->of_node, drv_data->ops);
> + if (IS_ERR(generic_phy)) {
> + dev_err(dev, "failed to create PHY\n");
> + return PTR_ERR(generic_phy);
> + }
> +
> + phy_set_drvdata(generic_phy, exynos_phy);
> + phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> +
> + return PTR_ERR_OR_ZERO(phy_provider);
> +}
> +
> +static struct platform_driver exynos_pcie_phy_driver = {
> + .probe = exynos_pcie_phy_probe,
> + .driver = {
> + .of_match_table = exynos_pcie_phy_match,
> + .name = "exynos_pcie_phy",
> + }
> +};
> +module_platform_driver(exynos_pcie_phy_driver);
>
^ permalink raw reply
* Re: Re: [PATCH 3/6] clk: sunxi-ng: Add H5 clocks
From: Icenowy Zheng @ 2017-01-09 13:13 UTC (permalink / raw)
To: Maxime Ripard
Cc: Rob Herring, Andre Przywara, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chen-Yu Tsai,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
2017年1月9日 下午7:01于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
>
> On Fri, Jan 06, 2017 at 06:48:31AM +0800, Icenowy Zheng wrote:
> >
> > 2017年1月6日 06:04于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> > >
> > > On Tue, Dec 27, 2016 at 12:25:15AM +0800, Icenowy Zheng wrote:
> > > > Add the H5 CCU clocks set based on the H3 one.
> > > >
> > > > Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> > >
> > > Is there any difference with H3's?
> >
> > One more Transport Stream controller, so one more bus gate and bus
> > reset for it.
>
> There's no need to duplicate more than 1000 lines of code just for
> that then. Just add a new compatible and reuse the clocks already
> defined.
How can I do this? Add them in ccu-sun8i-h3.c ?
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
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.
^ permalink raw reply
* Re: [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Young @ 2017-01-09 12:39 UTC (permalink / raw)
To: Sean Wang
Cc: mark.rutland, devicetree, ivo.g.dimitrov.75, keyhaede, mchehab,
linux-kernel, andi.shyti, hverkuil, hdegoede, robh+dt,
linux-mediatek, matthias.bgg, linux-media, linux-arm-kernel,
hkallweit1
In-Reply-To: <1483931601.16976.48.camel@mtkswgap22>
On Mon, Jan 09, 2017 at 11:13:21AM +0800, Sean Wang wrote:
> I had another question. I found multiple and same IR messages being
> received when using SONY remote controller. Should driver needs to
> report each message or only one of these to the upper layer ?
In general the driver shouldn't try to change any IR message, this should
be done in rc-core if necessary.
rc-core should handle this correctly. If the same key is received twice
within IR_KEYPRESS_TIMEOUT (250ms) then it not reported to the input
layer.
Thanks
Sean
^ permalink raw reply
* Re: [PATCH v2 3/5] ARM: davinci_all_defconfig: enable iio and ADS7950
From: Sekhar Nori @ 2017-01-09 12:29 UTC (permalink / raw)
To: David Lechner
Cc: Mark Rutland, devicetree, Kevin Hilman, linux-kernel, Rob Herring,
linux-arm-kernel
In-Reply-To: <1483677228-2325-4-git-send-email-david@lechnology.com>
On Friday 06 January 2017 10:03 AM, David Lechner wrote:
> This enables the iio subsystem and the TI ADS7950 driver. This is used by
> LEGO MINDSTORMS EV3, which has an ADS7957 chip.
Can you add your sign-off?
> ---
>
> The CONFIG_TI_ADS7950 driver is currently in iio/testing, so some coordination
> may be needed before picking up this patch.
>
> arch/arm/configs/davinci_all_defconfig | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
> index 2b1967a..a899876 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -200,6 +200,13 @@ CONFIG_TI_EDMA=y
> CONFIG_MEMORY=y
> CONFIG_TI_AEMIF=m
> CONFIG_DA8XX_DDRCTL=y
> +CONFIG_IIO=m
> +CONFIG_IIO_BUFFER_CB=m
> +CONFIG_IIO_SW_DEVICE=m
> +CONFIG_IIO_SW_TRIGGER=m
> +CONFIG_TI_ADS7950=m
Can you separate this from rest of the patch. I would like to enable
this option only after I can find the symbol in linux-next.
> +CONFIG_IIO_HRTIMER_TRIGGER=m
> +CONFIG_IIO_SYSFS_TRIGGER=m
Need CONFIG_IIO_TRIGGER=y also for these two options to take effect.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: dts: OMAP5 / DRA7: indicate that SATA port 0 is available.
From: Jean-Jacques Hiblot @ 2017-01-09 12:22 UTC (permalink / raw)
To: bcousson, tony, linux-omap, devicetree
Cc: rogerq, Jean-Jacques Hiblot, stable
AHCI provides the register PORTS_IMPL to let the software know which port
is supported. The register must be initialized by the bootloader. However
in some cases u-boot doesn't properly initialize this value (if it is not
compiled with SATA support for example or if the SATA initialization fails).
The DTS entry "ports-implemented" can be used to override the value in
PORTS_IMPL.
Adding this entry in the dts allows us no to worry about what is done by
the bootloader.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Cc: <stable@vger.kernel.org> # v4.6+
---
arch/arm/boot/dts/dra7.dtsi | 1 +
arch/arm/boot/dts/omap5.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1faf24a..5ba1616 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1378,6 +1378,7 @@
phy-names = "sata-phy";
clocks = <&sata_ref_clk>;
ti,hwmods = "sata";
+ ports-implemented = <0x1>;
};
rtc: rtc@48838000 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7cd92ba..0844737 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -988,6 +988,7 @@
phy-names = "sata-phy";
clocks = <&sata_ref_clk>;
ti,hwmods = "sata";
+ ports-implemented = <0x1>;
};
dss: dss@58000000 {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 2/5] ARM: davinci_all_defconfig: Enable PWM modules
From: Sekhar Nori @ 2017-01-09 12:18 UTC (permalink / raw)
To: David Lechner
Cc: Mark Rutland, devicetree, Kevin Hilman, linux-kernel, Rob Herring,
linux-arm-kernel
In-Reply-To: <1483677228-2325-3-git-send-email-david@lechnology.com>
On Friday 06 January 2017 10:03 AM, David Lechner wrote:
> This enables PWM and the TI ECAP and EHRWPM modules. These are used on LEGO
> MINDSTORMS EV3.
Here too. Please resend with sign-off.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v2 1/5] ARM: davinci_all_defconfig: enable DA8xx pinconf
From: Sekhar Nori @ 2017-01-09 12:18 UTC (permalink / raw)
To: David Lechner
Cc: Mark Rutland, devicetree, Kevin Hilman, linux-kernel, Rob Herring,
linux-arm-kernel
In-Reply-To: <1483677228-2325-2-git-send-email-david@lechnology.com>
On Friday 06 January 2017 10:03 AM, David Lechner wrote:
> This enables the DA8xx pinconf driver by default. It is needed by LEGO
> MINDSTORMS EV3.
Missing your sign-off. I cannot apply that myself. Please resend.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Hans Verkuil @ 2017-01-09 11:29 UTC (permalink / raw)
To: Rick Chang
Cc: Hans Verkuil, Laurent Pinchart, Mauro Carvalho Chehab,
Matthias Brugger, Rob Herring,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Minghsiu Tsai
In-Reply-To: <1483670099.18931.5.camel@mtksdaap41>
Hi Rick,
On 01/06/2017 03:34 AM, Rick Chang wrote:
> Hi Hans,
>
> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have
> any idea about this patch series? Should we wait for [2] or we could merge
> the source code and dt-binding first?
Looking at [2] I noticed that the last comment was July 4th. What is the reason
it hasn't been merged yet?
If I know [2] will be merged for 4.11, then I am fine with merging this media
patch series. The dependency of this patch on [2] is something Mauro can handle.
If [2] is not merged for 4.11, then I think it is better to wait until it is
merged.
Regards,
Hans
>
> Best Regards,
> Rick
>
> On Wed, 2016-11-23 at 17:43 +0800, Rick Chang wrote:
>> On Wed, 2016-11-23 at 09:54 +0800, Rick Chang wrote:
>>> Hi Hans,
>>>
>>> On Tue, 2016-11-22 at 13:43 +0100, Hans Verkuil wrote:
>>>> On 22/11/16 04:21, Rick Chang wrote:
>>>>> Hi Hans,
>>>>>
>>>>> On Mon, 2016-11-21 at 15:51 +0100, Hans Verkuil wrote:
>>>>>> On 17/11/16 04:38, Rick Chang wrote:
>>>>>>> Signed-off-by: Rick Chang <rick.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>>>> Signed-off-by: Minghsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>>>> ---
>>>>>>> This patch depends on:
>>>>>>> CCF "Add clock support for Mediatek MT2701"[1]
>>>>>>> iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]
>>>>>>>
>>>>>>> [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
>>>>>>> [2] https://patchwork.kernel.org/patch/9164013/
>>>>>>
>>>>>> I assume that 1 & 2 will appear in 4.10? So this patch needs to go in
>>>>>> after the
>>>>>> other two are merged in 4.10?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Hans
>>>>>
>>>>> [1] will appear in 4.10, but [2] will appear latter than 4.10.So this
>>>>> patch needs to go in after [1] & [2] will be merged in 4.11.
>>>>
>>>> So what should I do? Merge the driver for 4.11 and wait with this patch
>>>> until [2] is merged in 4.11? Does that sound reasonable?
>>>>
>>>> Regards,
>>>>
>>>> Hans
>>>
>>> What do you think about this? You merge the driver first and I send this
>>> patch again after [1] & [2] is merged.
>>
>> BTW, to prevent merging conflict, the dtsi should be merged by mediatek
>> SoC maintainer, Matthias.I think we can only take care on the driver
>> part at this moment.
>>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" 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 v2 9/9] ARM: sunxi: Convert pinctrl nodes to generic bindings
From: Maxime Ripard @ 2017-01-09 11:16 UTC (permalink / raw)
To: André Przywara
Cc: devicetree, Linus Walleij, linux-kernel,
linux-gpio@vger.kernel.org, Chen-Yu Tsai, linux-arm-kernel
In-Reply-To: <dfd7242d-6b16-6091-979f-0bff85a20806@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 3913 bytes --]
On Fri, Jan 06, 2017 at 01:17:21AM +0000, André Przywara wrote:
> > On Wed, Jan 04, 2017 at 02:16:23AM +0000, André Przywara wrote:
> >> So can I ask that we start taking this seriously and stop doing things
> >> which prevent Allwinner boards from being supported properly?
> >> Which would first involve dropping this very patch?
> >
> > The driver still supports the old binding.
>
> Yes, a _current_ version of the driver supports both bindings, but older
> versions *require* the older binding and bail out if various
> allwinner,xxx properties are missing - as in those proposed new DTs:
>
> 4.9 kernel with sunxi/for-next .dtb:
> sun8i-h3-pinctrl 1c20800.pinctrl: missing allwinner,function property in
> node uart0
> sun8i-h3-pinctrl 1c20800.pinctrl: missing allwinner,function property in
> node mmc0
> sunxi-mmc: probe of 1c0f000.mmc failed with error -22
This is seriously getting out of control. We already come to great
length (and sometimes a painful amount of hacks) to satisfy a few
individuals with a theorical interest in backward compatibility (and
apparently, we're even the only one doing so, even more platforms
choosing to not support that as we speak), there's seriously no reason
to support forward compatibility as well. This has *never* been a
thing, never has been documented nor advertised, I don't know why it
should be one more thing to carry on our shoulders.
Only maybe to slow us even more in the process, and effectively
prevent us from doing any actual work.
> >> Having done breakage in the past (with "allwinner,sun7i-a20-mmc", for
> >> instance) is no excuse for doing it again.
> >
> > I'm not sure which breakage we introduced with a new compatible: the
> > old compatible is working just like it used to, and the new one is
> > working like we need it to.
>
> But the new compatible is not recognized with older kernels, preventing
> people from using the newest DT with older kernels as well.
When do you draw the line exactly? You could have the same argument
for any feature that will be supported in the future... Do you also
want to backport any given driver for any kernel version?
This is ridiculous. 4.9 didn't have MMC support. Who cares about
whether MMC (or any other driver) works? This was never supposed to!
> I proposed to simply work around this by using the old compatible as a
> fallback: compatible="sun7i-a20-mmc", "sun5i-a13-mmc";
> Unfortunately this suggestion was not followed.
> So now we can't boot a 4.8 (or earlier) kernel with a .dtb from a 4.9 or
> later tree. Adding the extra string would fix this.
>
> Actually the recommended approach to avoid this situation in the first
> place is to always use compatible strings with the SoC-specific name as
> the first string, followed by the compatible string the driver works
> with. And this should be done upon introducing a new DT to the tree -
> even if at this point the driver doesn't deal with the new string.
> Unknown strings will just be skipped.
> So for instance the H5 DT should read: "sun50i-h5-mmc",
> "sun50i-a64-mmc", "sun5i-a13-mmc"; (with the last string possibly being
> optional). The current kernel driver will not match the h5 string, so it
> falls back to the a64 string and works. If we learn about a neat eMMC
> 5.1 feature (or any quirk the H5 can benefit from) somewhere in the
> future, we can add the code together with this h5 string to the driver
> and don't need to change the DT at all.
And what about the situation that you encountered last week too? IE
the compatibility was introduced because it was convenient, and it
turns out it's not working as expected?
We remove the bogus compatible from the list? But then, we can't boot
anymore on older kernels...
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [RFC PATCH] iommu/arm-smmu: Add global SMR masking property
From: Bharat Bhushan @ 2017-01-09 11:14 UTC (permalink / raw)
To: Nipun Gupta, Robin Murphy,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org, Stuart Yoder
In-Reply-To: <DB6PR0402MB2694957C2D7C648CC342627FE69F0-2mNvjAGDOPn2WJ5A9zev/o3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
Hi Robin,
> -----Original Message-----
> From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Nipun Gupta
> Sent: Sunday, December 18, 2016 2:37 AM
> To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> foundation.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org; will.deacon-5wv7dgnIgG8@public.gmane.org; Stuart Yoder
> <stuart.yoder-3arQi8VN3Tc@public.gmane.org>
> Subject: RE: [RFC PATCH] iommu/arm-smmu: Add global SMR masking
> property
>
>
>
> > -----Original Message-----
> > From: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org [mailto:iommu-
> > bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org] On Behalf Of Robin Murphy
> > Sent: Friday, December 16, 2016 18:49
> > To: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > linux-arm- kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org; will.deacon-5wv7dgnIgG8@public.gmane.org; Stuart Yoder
> > <stuart.yoder-3arQi8VN3Tc@public.gmane.org>
> > Subject: [RFC PATCH] iommu/arm-smmu: Add global SMR masking
> property
> >
> > The current SMR masking support using a 2-cell iommu-specifier is
> > primarily intended to handle individual masters with large and/or
> > complex Stream ID assignments; it quickly gets a bit clunky in other
> > SMR use-cases where we just want to consistently mask out the same
> > part of every Stream ID (e.g. for MMU-500 configurations where the
> > appended TBU number gets in the way unnecessarily). Let's add a new
> > property to allow a single global mask value to better fit the latter situation.
> >
> > CC: Stuart Yoder <stuart.yoder-3arQi8VN3Tc@public.gmane.org>
>
> Tested-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
We have verified this patches with PCI and FSL-MC bus devices.
I do not see any comment on this patch, I know there were holidays around, can we assume this as accepted and we can develop u-boot patches.
Thanks
-Bharat
>
> > Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> > ---
> >
> > Compile-tested only...
> >
> > Documentation/devicetree/bindings/iommu/arm,smmu.txt | 8 ++++++++
> > drivers/iommu/arm-smmu.c | 4 +++-
> > 2 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > index e862d1485205..98f5cbe5fdb4 100644
> > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > @@ -60,6 +60,14 @@ conditions.
> > aliases of secure registers have to be used during
> > SMMU configuration.
> >
> > +- stream-match-mask : Specifies a fixed SMR mask value to combine with
> > + the Stream ID value from every iommu-specifier. This
> > + may be used instead of an "#iommu-cells" value of 2
> > + when there is no need for per-master SMR masks, but
> > + it is still desired to mask some portion of every
> > + Stream ID (e.g. for certain MMU-500 configurations
> > + given globally unique external IDs).
> > +
> > ** Deprecated properties:
> >
> > - mmu-masters (deprecated in favour of the generic "iommus" binding) :
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index
> > 8f7281444551..f1abcb7dde36 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -1534,13 +1534,15 @@ static int arm_smmu_domain_set_attr(struct
> > iommu_domain *domain,
> >
> > static int arm_smmu_of_xlate(struct device *dev, struct
> > of_phandle_args *args) {
> > - u32 fwid = 0;
> > + u32 mask, fwid = 0;
> >
> > if (args->args_count > 0)
> > fwid |= (u16)args->args[0];
> >
> > if (args->args_count > 1)
> > fwid |= (u16)args->args[1] << SMR_MASK_SHIFT;
> > + else if (!of_property_read_u32(args->np, "stream-match-mask",
> > &mask))
> > + fwid |= (u16)mask << SMR_MASK_SHIFT;
> >
> > return iommu_fwspec_add_ids(dev, &fwid, 1); }
> > --
> > 2.10.2.dirty
> >
> > _______________________________________________
> > iommu mailing list
> > iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu
> _______________________________________________
> iommu mailing list
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Johannes Berg @ 2017-01-09 11:07 UTC (permalink / raw)
To: Arend Van Spriel, Rafał Miłecki
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rob Herring, Rafał Miłecki
In-Reply-To: <684d1aff-a9ce-ae42-0c11-5840d3a92daf-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Mon, 2017-01-09 at 12:02 +0100, Arend Van Spriel wrote:
> > However, with the OF, I argued (succesfully it seems :P) that the
> > sensible thing to do was to register with the DISABLED flag and
> > thereby
> > "permanently" disable the channels that OF didn't think were
> > usable,
> > but in this case now the driver has to adhere to the cfg80211 logic
> > of
> > preserving orig_flags forever.
>
> By adhere you mean we should not enable channes for which orig_flags
> indicate DISABLED?
Well, the regulatory code will "OR" in all the orig_flags after
modifications. If you don't use any of the others before registering,
and you don't use any other helpers other than the OF one that we know
sets only DISABLED, then keeping only the DISABLED flag would be OK -
however, it should *also* be OK to always keep *all* of the orig_flags,
just like the normal regulatory code would?
johannes
--
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 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Arend Van Spriel @ 2017-01-09 11:02 UTC (permalink / raw)
To: Johannes Berg, Rafał Miłecki
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rob Herring, Rafał Miłecki
In-Reply-To: <1483952320.17582.13.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
On 9-1-2017 9:58, Johannes Berg wrote:
> On Sat, 2017-01-07 at 13:58 +0100, Rafał Miłecki wrote:
>
>>> I indeed prefer to talk about the driver instead of we. Indeed it
>>> is true due to the orig_flags behavior although that only seems to
>>> involve regulatory code. Could it be that brcmfmac undo that
>>> through the notifier?
>>
>> I guess you could touch orig_flags, but I don't know if it's
>> preferred way. This is probably question to Johannes & cfg80211 guys.
>
> Right now - before the OF patch - there can't really be any orig_flags
> with DISABLED since the driver doesn't set flags to DISABLED before
> registering, does it? While registering, flags are copied to orig_flags
> so the driver can register with flags like DFS or NO_IR already enabled
> - say the firmware requires that - and they will never be overwritten
> by cfg80211.
Actually, in brcmfmac we do set channels to DISABLED before registering.
I was blissfully unaware of the orig_flags when I added the channel
setup in our probe sequence.
> Arguably, what the driver does today - before OF - isn't incorrect
> either, since it simply doesn't care about anything it registered with
> at all.
Given the statement above I think brcmfmac is incorrect.
> However, with the OF, I argued (succesfully it seems :P) that the
> sensible thing to do was to register with the DISABLED flag and thereby
> "permanently" disable the channels that OF didn't think were usable,
> but in this case now the driver has to adhere to the cfg80211 logic of
> preserving orig_flags forever.
By adhere you mean we should not enable channes for which orig_flags
indicate DISABLED?
Regards,
Arend
^ permalink raw reply
* Re: Re: [PATCH 3/6] clk: sunxi-ng: Add H5 clocks
From: Maxime Ripard @ 2017-01-09 11:01 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andre Przywara,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Chen-Yu Tsai
In-Reply-To: <20170106014959.nqPebrUB-V6dNpkQgAPs0PDqKvflMoHmW9unr2Ajn@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]
On Fri, Jan 06, 2017 at 06:48:31AM +0800, Icenowy Zheng wrote:
>
> 2017年1月6日 06:04于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> >
> > On Tue, Dec 27, 2016 at 12:25:15AM +0800, Icenowy Zheng wrote:
> > > Add the H5 CCU clocks set based on the H3 one.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> >
> > Is there any difference with H3's?
>
> One more Transport Stream controller, so one more bus gate and bus
> reset for it.
There's no need to duplicate more than 1000 lines of code just for
that then. Just add a new compatible and reuse the clocks already
defined.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] iio: misc: add a generic regulator driver
From: Linus Walleij @ 2017-01-09 10:49 UTC (permalink / raw)
To: Mark Brown
Cc: Geert Uytterhoeven, Lars-Peter Clausen, Bartosz Golaszewski,
Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler,
Rob Herring, Mark Rutland, linux-iio@vger.kernel.org,
linux-devicetree, LKML, Kevin Hilman, Patrick Titiano,
Neil Armstrong, Liam Girdwood
In-Reply-To: <20170105120027.4nftlpegln2se7bq@sirena.org.uk>
On Thu, Jan 5, 2017 at 1:00 PM, Mark Brown <broonie@kernel.org> wrote:
> The system itself is controlling
> a power line, it knows nothing about what's connected. It seems like
> this is coming up often enough that someone should probably just write
> an external system control binding, also tying in things like references
> to the console and so on.
That sounds pretty helpful for these usecases.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: exynos5433-tm2: enable HDMI/TV path
From: Andrzej Hajda @ 2017-01-09 10:40 UTC (permalink / raw)
To: linux-samsung-soc, Krzysztof Kozlowski
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
Inki Dae, Rob Herring, Mark Rutland, Javier Martinez Canillas,
devicetree, Andi Shyti, Chanwoo Choi
In-Reply-To: <1483958437-6572-1-git-send-email-a.hajda@samsung.com>
TV path consist of following interconnected components:
- DECON_TV - display controller,
- HDMI - video signal converter RGB / HDMI,
- MHL - video signal converter HDMI / MHL,
- DDC - i2c slave device for EDID reading (on hsi2c_11 bus).
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
v2:
- replaced magic numbers with macros,
- removed assigned-clock properties from sii8620 -
PMU clock is already confgured in PMU node
---
.../boot/dts/exynos/exynos5433-tm2-common.dtsi | 69 ++++++++++++++++++++++
1 file changed, 69 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 669bb1f..ca90e6a 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -281,6 +281,22 @@
};
};
+&decon_tv {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ tv_to_hdmi: endpoint {
+ remote-endpoint = <&hdmi_to_tv>;
+ };
+ };
+ };
+};
+
&dsi {
status = "okay";
vddcore-supply = <&ldo6_reg>;
@@ -304,6 +320,33 @@
};
};
+&hdmi {
+ hpd-gpios = <&gpa3 0 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+ vdd-supply = <&ldo6_reg>;
+ vdd_osc-supply = <&ldo7_reg>;
+ vdd_pll-supply = <&ldo6_reg>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ hdmi_to_tv: endpoint {
+ remote-endpoint = <&tv_to_hdmi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ hdmi_to_mhl: endpoint {
+ remote-endpoint = <&mhl_to_hdmi>;
+ };
+ };
+ };
+};
+
&hsi2c_0 {
status = "okay";
clock-frequency = <2500000>;
@@ -692,6 +735,28 @@
};
};
+&hsi2c_7 {
+ status = "okay";
+
+ sii8620@39 {
+ reg = <0x39>;
+ compatible = "sil,sii8620";
+ cvcc10-supply = <&ldo36_reg>;
+ iovcc18-supply = <&ldo34_reg>;
+ interrupt-parent = <&gpf0>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
+ reset-gpios = <&gpv7 0 GPIO_ACTIVE_LOW>;
+ clocks = <&pmu_system_controller 0>;
+ clock-names = "xtal";
+
+ port {
+ mhl_to_hdmi: endpoint {
+ remote-endpoint = <&hdmi_to_mhl>;
+ };
+ };
+ };
+};
+
&hsi2c_8 {
status = "okay";
@@ -735,6 +800,10 @@
};
};
+&hsi2c_11 {
+ status = "okay";
+};
+
&i2s0 {
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: exynos5433: add HDMI node
From: Andrzej Hajda @ 2017-01-09 10:40 UTC (permalink / raw)
To: linux-samsung-soc, Krzysztof Kozlowski
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
Inki Dae, Rob Herring, Mark Rutland, Javier Martinez Canillas,
devicetree, Andi Shyti, Chanwoo Choi
In-Reply-To: <1483958437-6572-1-git-send-email-a.hajda@samsung.com>
HDMI converts RGB/I80 signal from DECON_TV to HDMI/TMDS video stream.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
v2:
- replaced magic numbers with macros,
- removed power domains
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 5552f77..f82d26e 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -837,6 +837,35 @@
iommu-names = "m0", "m1";
};
+ hdmi: hdmi@13970000 {
+ compatible = "samsung,exynos5433-hdmi";
+ reg = <0x13970000 0x70000>;
+ interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu_disp CLK_PCLK_HDMI>,
+ <&cmu_disp CLK_PCLK_HDMIPHY>,
+ <&cmu_disp CLK_PHYCLK_HDMIPHY_TMDS_CLKO>,
+ <&cmu_disp CLK_PHYCLK_HDMI_PIXEL>,
+ <&cmu_disp CLK_PHYCLK_HDMIPHY_TMDS_CLKO_PHY>,
+ <&cmu_disp CLK_MOUT_PHYCLK_HDMIPHY_TMDS_CLKO_USER>,
+ <&cmu_disp CLK_PHYCLK_HDMIPHY_PIXEL_CLKO_PHY>,
+ <&cmu_disp CLK_MOUT_PHYCLK_HDMIPHY_PIXEL_CLKO_USER>,
+ <&xxti>, <&cmu_disp CLK_SCLK_HDMI_SPDIF>;
+ clock-names = "hdmi_pclk", "hdmi_i_pclk",
+ "i_tmds_clk", "i_pixel_clk",
+ "tmds_clko", "tmds_clko_user",
+ "pixel_clko", "pixel_clko_user",
+ "oscclk", "i_spdif_clk";
+ phy = <&hdmiphy>;
+ ddc = <&hsi2c_11>;
+ samsung,syscon-phandle = <&pmu_system_controller>;
+ samsung,sysreg-phandle = <&syscon_disp>;
+ status = "disabled";
+ };
+
+ hdmiphy: hdmiphy@13af0000 {
+ reg = <0x13af0000 0x80>;
+ };
+
syscon_disp: syscon@13b80000 {
compatible = "syscon";
reg = <0x13b80000 0x1010>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/3] arm64: dts: exynos5433: add DECON_TV node
From: Andrzej Hajda @ 2017-01-09 10:40 UTC (permalink / raw)
To: linux-samsung-soc, Krzysztof Kozlowski
Cc: Andrzej Hajda, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
Inki Dae, Rob Herring, Mark Rutland, Javier Martinez Canillas,
devicetree, Andi Shyti, Chanwoo Choi
In-Reply-To: <CGME20170109104054eucas1p258d1df5ecff1d8b8c9aa882d8c86d5df@eucas1p2.samsung.com>
DECON_TV is 2nd display controller on Exynos5433, used in HDMI path
or 2nd DSI path.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Hi Krzysztof,
These patches are based on latest patches separating tm2 and tm2e and
touchscreen patches. I hope this is good base.
Thanks all for quick response/review.
Regards
Andrzej
v2:
- replaced magic numbers with macros,
- removed power domains,
- removed 0x prefixes from node names
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 43 ++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 68f764e..5552f77 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -814,6 +814,29 @@
};
};
+ decon_tv: decon@13880000 {
+ compatible = "samsung,exynos5433-decon-tv";
+ reg = <0x13880000 0x20b8>;
+ clocks = <&cmu_disp CLK_PCLK_DECON_TV>,
+ <&cmu_disp CLK_ACLK_DECON_TV>,
+ <&cmu_disp CLK_ACLK_SMMU_TV0X>,
+ <&cmu_disp CLK_ACLK_XIU_TV0X>,
+ <&cmu_disp CLK_PCLK_SMMU_TV0X>,
+ <&cmu_disp CLK_SCLK_DECON_TV_VCLK>,
+ <&cmu_disp CLK_SCLK_DECON_TV_ECLK>;
+ clock-names = "pclk", "aclk_decon", "aclk_smmu_decon0x",
+ "aclk_xiu_decon0x", "pclk_smmu_decon0x",
+ "sclk_decon_vclk", "sclk_decon_eclk";
+ samsung,disp-sysreg = <&syscon_disp>;
+ interrupt-names = "fifo", "vsync", "lcd_sys";
+ interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ iommus = <&sysmmu_tv0x>, <&sysmmu_tv1x>;
+ iommu-names = "m0", "m1";
+ };
+
syscon_disp: syscon@13b80000 {
compatible = "syscon";
reg = <0x13b80000 0x1010>;
@@ -912,6 +935,26 @@
#iommu-cells = <0>;
};
+ sysmmu_tv0x: sysmmu@13a20000 {
+ compatible = "samsung,exynos-sysmmu";
+ reg = <0x13a20000 0x1000>;
+ interrupts = <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "pclk", "aclk";
+ clocks = <&cmu_disp CLK_PCLK_SMMU_TV0X>,
+ <&cmu_disp CLK_ACLK_SMMU_TV0X>;
+ #iommu-cells = <0>;
+ };
+
+ sysmmu_tv1x: sysmmu@13a30000 {
+ compatible = "samsung,exynos-sysmmu";
+ reg = <0x13a30000 0x1000>;
+ interrupts = <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "pclk", "aclk";
+ clocks = <&cmu_disp CLK_PCLK_SMMU_TV1X>,
+ <&cmu_disp CLK_ACLK_SMMU_TV1X>;
+ #iommu-cells = <0>;
+ };
+
sysmmu_gscl0: sysmmu@0x13C80000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x13C80000 0x1000>;
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox