* Re: [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains
From: Santosh Shilimkar @ 2017-01-19 19:04 UTC (permalink / raw)
To: Dave Gerlach, Ulf Hansson, Rafael J . Wysocki, Kevin Hilman,
Rob Herring
Cc: Nishanth Menon, devicetree, linux-pm, Lokesh Vutla, Keerthy,
Santosh Shilimkar, linux-kernel, Tero Kristo, Russell King,
Sudeep Holla, linux-arm-kernel
In-Reply-To: <7e87e4cd-d859-b941-8cb8-118a8b0d2690@ti.com>
On 1/19/2017 10:59 AM, Dave Gerlach wrote:
> Santosh,
> On 01/19/2017 11:51 AM, santosh.shilimkar@oracle.com wrote:
>> On 1/4/17 2:06 PM, Dave Gerlach wrote:
[...]
>> Am going to send pull request over weekend, so if you would like
>> me take the series via arm-soc tree, please get Rafaels, ack and
>> let me know.
>
> Thanks for letting me know, unfortunately we have not yet reached
> alignment on the binding so I do not believe we will be ready for merge
> in time.
>
Thanks for clarification.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH v3 2/4] clk: gxbb: add the SAR ADC clocks and expose them
From: Stephen Boyd @ 2017-01-19 19:13 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
khilman-rdvid1DuHRBWk0Htik3J/w, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-clk-u79uwXL29TY76Z2rM5mHXA, carlo-KA+7E9HrN00dnm+yROfE0A,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
mturquette-rdvid1DuHRBWk0Htik3J/w,
narmstrong-rdvid1DuHRBWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170119145822.26239-3-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On 01/19, Martin Blumenstingl wrote:
> The HHI_SAR_CLK_CNTL contains three SAR ADC specific clocks:
> - a mux clock to choose between different ADC reference clocks (this is
> 2-bit wide, but the datasheet only lists the parents for the first
> bit)
> - a divider for the input/reference clock
> - a gate which enables the ADC clock
>
> Additionally this exposes the ADC core clock (CLKID_SAR_ADC) and
> CLKID_SANA (which seems to enable the analog inputs, but unfortunately
> there is no documentation for this - we just mimic what the vendor
> driver does).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Tested-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
Acked-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
This should go through arm-soc along with the other patch to dts.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 1/3 v3] iio: adc: add device tree bindings for Qualcomm PM8xxx ADCs
From: Rob Herring @ 2017-01-19 19:16 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Ivan T . Ivanov, Andy Gross,
Bjorn Andersson, Stephen Boyd, Srinivas Kandagatla,
Rama Krishna Phani A
In-Reply-To: <20170117142515.10578-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue, Jan 17, 2017 at 03:25:13PM +0100, Linus Walleij wrote:
> This adds the device tree bindings for the Qualcomm PM8xxx
> ADCs. This is based on the existing DT bindings for the
> SPMI ADC so there are hopefully no controversial features.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Ivan T. Ivanov <iivanov.xz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Andy Gross <andy.gross-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Rama Krishna Phani A <rphani-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> ChangeLog v2->v3:
> - Collapse the ratiometric property into one that enables and
> selects a ratiometric reference in one go.
> - Use foo: adc-channel@X notation consequently
> - Document that the reference voltage is compulsory.
> ChangeLog v1->v2:
> - Spelling fixes
> ---
> .../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 149 +++++++++++++++++++++
> 1 file changed, 149 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v3 5/5] dt-bindings: Document the STM32 USB OTG DWC2 core binding
From: Rob Herring @ 2017-01-19 19:24 UTC (permalink / raw)
To: Bruno Herrera
Cc: mark.rutland-5wv7dgnIgG8, mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o, johnyoun-HKixBCOQz3hWk0Htik3J/w,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170117161237.3802-6-bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Jan 17, 2017 at 02:12:37PM -0200, Bruno Herrera wrote:
> This patch adds the documentation for STM32F4x9 USB OTG FS/HS compatible strings.
>
> Signed-off-by: Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 4 ++++
> 1 file changed, 4 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 1/2] dt-bindings: gpu: Add Mali Utgard bindings
From: John Stultz @ 2017-01-19 19:24 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, Thomas Petazzoni, Heiko Stuebner,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Kevin Hilman, Linus Walleij, John Reitan, Krzysztof Kozlowski,
Javier Martinez Canillas, Chen-Yu Tsai, Rob Herring,
Alexandre Belloni, Kukjin Kim, Antoine Ténart,
Matthias Brugger, Boris Brezillon, Carlo Caione,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170116132424.7038-1-maxime.ripard@free-electrons.com>
On Mon, Jan 16, 2017 at 5:24 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The ARM Mali Utgard GPU family is embedded into a number of SoCs from
> Allwinner, Amlogic, Mediatek or Rockchip.
>
> Add a binding for the GPU of that family.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> .../devicetree/bindings/gpu/arm,mali-utgard.txt | 76 ++++++++++++++++++++++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> new file mode 100644
> index 000000000000..df05ba0ec357
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> @@ -0,0 +1,76 @@
> +ARM Mali Utgard GPU
> +===================
> +
> +Required properties:
> + - compatible:
> + * "arm,mali-utgard" and one of the following:
> + + "arm,mali-300"
> + + "arm,mali-400"
> + + "arm,mali-450"
> +
> + - reg: Physical base address and length of the GPU registers
> +
> + - interrupts: an entry for each entry in interrupt-names.
> + See ../interrupt-controller/interrupts.txt for details.
> +
> + - interrupt-names:
> + * ppX: Pixel Processor X interrupt (X from 0 to 7)
> + * ppmmuX: Pixel Processor X MMU interrupt (X from 0 to 7)
> + * pp: Pixel Processor broadcast interrupt (mali-450 only)
> + * gp: Geometry Processor interrupt
> + * gpmmu: Geometry Processor MMU interrupt
> +
> +
> +Optional properties:
> + - interrupt-names:
> + * pmu: Power Management Unit interrupt, if implemented in hardware
> +
> +Vendor-specific bindings
> +------------------------
> +
> +The Mali GPU is integrated very differently from one SoC to
> +another. In order to accommodate those differences, you have the option
> +to specify one more vendor-specific compatible, among:
> +
> + - allwinner,sun4i-a10-mali
> + Required properties:
> + * clocks: an entry for each entry in clock-names
> + * clock-names:
> + + bus: bus clock for the GPU
> + + core: clock driving the GPU itself
> + * resets: phandle to the reset line for the GPU
> +
> + - allwinner,sun7i-a20-mali
> + Required properties:
> + * clocks: an entry for each entry in clock-names
> + * clock-names:
> + + bus: bus clock for the GPU
> + + core: clock driving the GPU itself
> + * resets: phandle to the reset line for the GPU
> +
> +Example:
> +
> +mali: gpu@01c40000 {
> + compatible = "allwinner,sun7i-a20-mali", "arm,mali-400",
> + "arm,mali-utgard";
> + reg = <0x01c40000 0x10000>;
> + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "gp",
> + "gpmmu",
> + "pp0",
> + "ppmmu0",
> + "pp1",
> + "ppmmu1",
> + "pmu";
> + clocks = <&ccu CLK_BUS_GPU>, <&ccu CLK_GPU>;
> + clock-names = "bus", "core";
> + resets = <&ccu RST_BUS_GPU>;
> +};
> +
> +
Having a mali utgard binding upstream would be great. However I'm a
little worried that the mali driver I've used sort of only half way
uses DT, and still requires a custom built in platform driver to setup
numerous other things. Curious if you have a pointer to the kernel
driver you've been using with the vendor specific bindings above? I'd
like to try to adapt what we have to your method to validate the above
as generic.
And, just for context, here's the node we've been using with hikey:
mali:mali@f4080000 {
compatible = "arm,mali-450", "arm,mali-utgard";
reg = <0x0 0x3f100000 0x0 0x00708000>;
clocks = <&media_ctrl HI6220_G3D_CLK>,
<&media_ctrl HI6220_G3D_PCLK>;
clock-names = "clk_g3d", "pclk_g3d";
mali_def_freq = <500>;
pclk_freq = <144>;
dfs_steps = <2>;
dfs_lockprf = <1>;
dfs_limit_max_prf = <1>;
dfs_profile_num = <2>;
dfs_profiles = <250 3 0>, <500 1 0>;
mali_type = <2>;
interrupt-parent = <&gic>;
interrupts = <1 126 4>, /*gp*/
<1 126 4>, /*gp mmu*/
<1 126 4>, /*pp bc*/
<1 126 4>, /*pmu*/
<1 126 4>, /*pp0*/
<1 126 4>,
<1 126 4>, /*pp1*/
<1 126 4>,
<1 126 4>, /*pp2*/
<1 126 4>,
<1 126 4>, /*pp4*/
<1 126 4>,
<1 126 4>, /*pp5*/
<1 126 4>,
<1 126 4>, /*pp6*/
<1 126 4>;
interrupt-names = "IRQGP", "IRQGPMMU",
"IRQPP", "IRQPMU",
"IRQPP0", "IRQPPMMU0",
"IRQPP1", "IRQPPMMU1",
"IRQPP2",
"IRQPPMMU2","IRQPP4", "IRQPPMMU4",
"IRQPP5", "IRQPPMMU5",
"IRQPP6", "IRQPPMMU6";
};
thanks
-john
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: phy: Add documentation for NSP USB3 PHY
From: Rob Herring @ 2017-01-19 19:26 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy
Cc: Mark Rutland, devicetree, Florian Fainelli, Scott Branden,
Jon Mason, Ray Jui, Russell King, Kishon Vijay Abraham I,
bcm-kernel-feedback-list, linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <1484669670-4201-2-git-send-email-yendapally.reddy@broadcom.com>
On Tue, Jan 17, 2017 at 11:14:27AM -0500, Yendapally Reddy Dhananjaya Reddy wrote:
> Add documentation for USB3 PHY available in Northstar plus SoC
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
> ---
> .../devicetree/bindings/phy/brcm,nsp-usb3-phy.txt | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/4] net: phy: Initialize mdio clock at probe function
From: Florian Fainelli @ 2017-01-19 19:26 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy, Rob Herring, Mark Rutland,
Russell King, Ray Jui, Scott Branden, Jon Mason, Florian Fainelli,
Kishon Vijay Abraham I
Cc: devicetree, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel, netdev
In-Reply-To: <1484669670-4201-3-git-send-email-yendapally.reddy@broadcom.com>
On 01/17/2017 08:14 AM, Yendapally Reddy Dhananjaya Reddy wrote:
> Initialize mdio clock divisor in probe function. The ext bus
> bit available in the same register will be used by mdio mux
> to enable external mdio.
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCHv2] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
From: Rob Herring @ 2017-01-19 19:28 UTC (permalink / raw)
To: Tony Lindgren
Cc: Michael Turquette, Stephen Boyd, Tero Kristo, devicetree,
linux-clk, linux-omap, Paul Walmsley
In-Reply-To: <20170117225302.10844-1-tony@atomide.com>
On Tue, Jan 17, 2017 at 02:53:02PM -0800, Tony Lindgren wrote:
> Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
> clock controller instance for each interconnect target module. The clkctrl
> controls functional and interface clocks for the module.
>
> The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
> With this binding and a related clock device driver we can start moving the
> clkctrl clock handling to live in drivers/clk/ti.
>
> Note that this binding allows keeping the clockdomain related parts out of
> drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
> a separate driver in drivers/soc/ti and genpd. If the clockdomain driver
> needs to know it's clocks, we can just set the the clkctrl device
> instances to be children of the related clockdomain device.
>
> Each clkctrl clock can have multiple optional gate clocks, and multiple
> optional mux clocks. To represent this in device tree, it seems that
> it is best done using four clock cells #clock-cells = <4> property.
>
> The reasons for using #clock-cells = <4> are:
>
> 1. We need to specify the clkctrl offset from the instance base. Otherwise
> we end up with a large number of device tree nodes that need to be
> patched when new clocks are discovered in a clkctrl clock with minor
> hardware revision changes for example
>
> 2. On omap5 CM_L3INIT_USB_HOST_HS_CLKCTRL has ten OPTFCLKEN bits. So we
> need to use a separate cell for optional gate clocks to avoid address
> space conflicts
>
> 3. Some clkctrl instances can also also optional mux clocks. To address
> them properly we need also a separate cell for the optional mux
> clock index
>
> 4. The modulemode clock needs a flag passed to it for hardware or
> software controlled mode
>
> There is probably no need to list input clocks for each clkctrl clock
> instance in the binding. If we want to add them, the standard clocks
> binding can be used for that.
>
> For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
> Mapping Summary" for example. It shows one instance of a clkctrl clock
> controller with multiple clkctrl registers.
>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>
> Changes from v1:
>
> - Use #clock-cells to avoid address space conflicts
>
> - Consider also optional mux clocks as pointed out by Tero
>
> ---
> .../devicetree/bindings/clock/ti-clkctrl.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/ti-clkctrl.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [RFC v2 1/5] UDC: Split the driver into amd (pci) and Synopsys core driver
From: Florian Fainelli @ 2017-01-19 19:28 UTC (permalink / raw)
To: Raviteja Garimella, Florian Fainelli
Cc: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Felipe Balbi,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, BCM Kernel Feedback,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAEHZuqO2x8FYW6AWbS5KshMt9UG7R4gWTfG_VaT+rNcAZ5d4Lg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/19/2017 02:44 AM, Raviteja Garimella wrote:
> Hi,
>
> On Thu, Jan 19, 2017 at 12:15 AM, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 01/17/2017 12:05 AM, Raviteja Garimella wrote:
>>> This patch splits the amd5536udc driver into two -- one that does
>>> pci device registration and the other file that does the rest of
>>> the driver tasks like the gadget/ep ops etc for Synopsys UDC.
>>>
>>> This way of splitting helps in exporting core driver symbols which
>>> can be used by any other platform/pci driver that is written for
>>> the same Synopsys USB device controller.
>>>
>>> The current patch also includes a change in the Kconfig and Makefile.
>>> A new config option USB_SNP_CORE will be selected automatically when
>>> any one of the platform or pci driver for the same UDC is selected.
>>>
>>> Signed-off-by: Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>
>> Although the changes you have done make sense and it is most certainly a
>> good idea to split udc core from bus specific glue logic, it is really
>> hard to review the changes per-se because of the file rename, could that
>> happen at a later time?
>
> If you start looking at this specific patch from the header file (amd5536udc.h),
> the additions in there comprise of:
> - 9 function declarations
> - some module parameter variable declarations that's moved out from the older
> common file amd5536udc.c
> - 2 #includes that are needed by all files.
Well, I don't really question the changes themselves, rather how this is
presented as a patch series to reviewers.
What I would do, to help introduce both the rename, and the splitting of
core vs. bus-glue specific changes is:
- have an initial patch which extracts the core functionality of the
driver and the PCI bus glue logic into adm5536udc_pci.c and left
adm5536udc.c intact (that would be a small delta to review)
- have a second patch that performs the file rename from adm5536udc.c
into snps_udc_core.c and updates adm5536udc_pci.c eventually as a result
of that, then again, a reviewer can ignore the rename part (don't format
to generate your patches with git format-patch -M in that case) and just
focus on the conversion part for adm5536udc_pci.c
>
> So, basically what's done for this split is that:
> 1. the static keyword is removed from those 9 functions in the new file
> snps_udc_core.c and are exported.
> 2. The module parameters declarations (since they are used in both core
> and pci file) are moved to the header file now.
These should really be part of the commit messages for each commit doing
the changes, this is meant to help a reviewer understand what you are
doing, and to some degree, will help him/her make an educated decision
as to what part of the code the focus should be put on.
Thanks
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC v2 4/5] DT bindings documentation for Synopsys UDC platform driver
From: Scott Branden @ 2017-01-19 19:30 UTC (permalink / raw)
To: Rob Herring, Raviteja Garimella
Cc: Mark Rutland, Greg Kroah-Hartman, Felipe Balbi, devicetree,
linux-kernel, bcm-kernel-feedback-list, linux-usb
In-Reply-To: <20170119173659.jeao5pqtlepmidek@rob-hp-laptop>
Hi Rob,
On 17-01-19 09:36 AM, Rob Herring wrote:
> On Tue, Jan 17, 2017 at 01:35:07PM +0530, Raviteja Garimella wrote:
>> This patch adds device tree bindings documentation for Synopsys
>> USB device controller platform driver.
>
> Bindings describe h/w, not drivers.
>>
>> Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
>> ---
>> .../devicetree/bindings/usb/snps,dw-ahb-udc.txt | 27 ++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>> new file mode 100644
>> index 0000000..0c18327
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>> @@ -0,0 +1,27 @@
>> +Synopsys USB Device controller.
>> +
>> +The device node is used for Synopsys Designware Cores AHB
>> +Subsystem Device Controller (UDC).
>> +
>> +This device node is used by UDCs integrated it Broadcom's
>> +Northstar2 and Cygnus SoC's.
>
> You need compatible strings for these in addition.
>
We don't need compatibility strings when an IP block is integrated into
an SoC. Otherwise each time we add the IP block to a new SoC we would
need to update ever linux driver that supports that SoC. That doesn't
make sense?
Cygnus and Northstar2 use existing drivers for such block as UARTs, SPI
controllers, NAND controllers, etc, etc. We haven't added compatibility
strings for those drivers and won't be.
Perhaps comment above can be:
This device node is used by UDCs integrated it such as Broadcom's
Northstar2 and Cygnus SoC's.
>> +
>> +Required properties:
>> + - compatible: should be "snps,dw-ahb-udc"
>
> This is a different IP than DWC2?
>
>> + - reg: Offset and length of UDC register set
>> + - interrupts: description of interrupt line
>> + - phys: phandle to phy node.
>> + - extcon: phandle to the extcon device. This is optional and
>> + not required for those that don't require extcon support.
>> + Extcon support will be required if the UDC is connected to
>> + a Dual Role Device Phy that supports both Host and Device
>> + mode based on the external cable.
>
> Drop this. It should be a part of the phy. Also, I don't care to see new
> users of extcon binding because it needs redoing.
>
We may need extcon support to support DRD Phy though. We have to work
within the framework that exists in linux today. If modified in the
future adapt to it as needed?
Regards,
Scott
^ permalink raw reply
* Re: [PATCH v8 5/8] IIO: add bindings for STM32 timer trigger driver
From: Rob Herring @ 2017-01-19 19:31 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
fabrice.gasnier-qxv4g6HH51o, gerald.baeza-qxv4g6HH51o,
arnaud.pouliquen-qxv4g6HH51o,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Benjamin Gaignard
In-Reply-To: <1484749251-14445-6-git-send-email-benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
On Wed, Jan 18, 2017 at 03:20:48PM +0100, Benjamin Gaignard wrote:
> Define bindings for STM32 timer trigger
>
> version 8:
> - reword "reg" parameter description
>
> version 4:
> - remove triggers enumeration from DT
> - add reg parameter
>
> version 3:
> - change file name
> - add cross reference with mfd bindings
>
> version 2:
> - only keep one compatible
> - add DT parameters to set lists of the triggers:
> one list describe the triggers created by the device
> another one give the triggers accepted by the device
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
> Acked-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> .../bindings/iio/timer/stm32-timer-trigger.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v3] iio: max5481: Add support for Maxim digital potentiometers
From: Slawomir Stepien @ 2017-01-19 19:35 UTC (permalink / raw)
To: Rob Herring
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
matthew.weber-lFk7bPDcGtkY5TsXZYaR1UEOCMrvLtNR,
maury.anderson-lFk7bPDcGtkY5TsXZYaR1UEOCMrvLtNR,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland
In-Reply-To: <20170119130923.zaro5vgl7l7kidr6@rob-hp-laptop>
On Jan 19, 2017 07:09, Rob Herring wrote:
> > .../bindings/iio/potentiometer/max5481.txt | 23 +++
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thank you Rob!
--
Slawomir Stepien
^ permalink raw reply
* Re: [PATCH v8 0/8] Add PWM and IIO timer drivers for STM32
From: Rob Herring @ 2017-01-19 19:35 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: Lee Jones, Mark Rutland, Alexandre Torgue, devicetree,
Linux Kernel Mailing List, Thierry Reding, Linux PWM List,
Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, linux-iio, linux-arm-kernel,
Fabrice Gasnier, Gerald Baeza, Arnaud Pouliquen,
Linaro Kernel Mailman List, Benjamin Gaignard
In-Reply-To: <CA+M3ks7UchJ3QdQrHO6rSsc4YNhNEmLejoeRBVNhn=2biSn=cQ@mail.gmail.com>
On Thu, Jan 19, 2017 at 05:02:11PM +0100, Benjamin Gaignard wrote:
> 2017-01-19 9:43 GMT+01:00 Lee Jones <lee.jones@linaro.org>:
> > On Wed, 18 Jan 2017, Benjamin Gaignard wrote:
> >
> >> Benjamin Gaignard (8):
> >> MFD: add bindings for STM32 Timers driver
> >> MFD: add STM32 Timers driver
> >> PWM: add pwm-stm32 DT bindings
> >> PWM: add PWM driver for STM32 plaftorm
> >> IIO: add bindings for STM32 timer trigger driver
> >> IIO: add STM32 timer trigger driver
> >> ARM: dts: stm32: add Timers driver for stm32f429 MCU
> >> ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco
> >>
> >> .../ABI/testing/sysfs-bus-iio-timer-stm32 | 29 ++
> >> .../bindings/iio/timer/stm32-timer-trigger.txt | 23 ++
> >> .../devicetree/bindings/mfd/stm32-timers.txt | 46 +++
> >> .../devicetree/bindings/pwm/pwm-stm32.txt | 35 ++
> >> arch/arm/boot/dts/stm32f429.dtsi | 275 ++++++++++++++
> >> arch/arm/boot/dts/stm32f469-disco.dts | 28 ++
> >> drivers/iio/trigger/Kconfig | 9 +
> >> drivers/iio/trigger/Makefile | 1 +
> >> drivers/iio/trigger/stm32-timer-trigger.c | 342 ++++++++++++++++++
> >> drivers/mfd/Kconfig | 11 +
> >> drivers/mfd/Makefile | 2 +
> >> drivers/mfd/stm32-timers.c | 80 +++++
> >> drivers/pwm/Kconfig | 9 +
> >> drivers/pwm/Makefile | 1 +
> >> drivers/pwm/pwm-stm32.c | 398 +++++++++++++++++++++
> >> include/linux/iio/timer/stm32-timer-trigger.h | 62 ++++
> >> include/linux/mfd/stm32-timers.h | 71 ++++
> >> 17 files changed, 1422 insertions(+)
> >> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> >> create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
> >> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
> >> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >> create mode 100644 drivers/iio/trigger/stm32-timer-trigger.c
> >> create mode 100644 drivers/mfd/stm32-timers.c
> >> create mode 100644 drivers/pwm/pwm-stm32.c
> >> create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
> >> create mode 100644 include/linux/mfd/stm32-timers.h
> >
> > Let me know when you have all your Acks.
> >
> > I would be happy to take this through the MFD tree.
>
> Some Acks are still missing on DT patches, I hope that Rob could find
> to review them
> after that it will ok :-)
I've acked all the bindings. stm32 maintainer needs to ack the dts
files.
Rob
^ permalink raw reply
* Re: [PATCH 3/4] phy: qcom-ufs: Remove -always-on property
From: Vivek Gautam @ 2017-01-19 19:39 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Kishon Vijay Abraham I, linux-kernel@vger.kernel.org,
linux-arm-msm, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, Subhash Jadavani
In-Reply-To: <20170119104739.4376-3-bjorn.andersson@linaro.org>
On Thu, Jan 19, 2017 at 4:17 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> The fact that a regulator is always-on is a property of the regulator,
> not a specific consumer. Implementing this in the driver leads to a
> system behaviour that is dependent on if the Qualcomm UFS PHY was ever
> (partially) probed.
>
> If the specific regulator should be always on in a particular device,
> mark it so by specifying "regulator-always-on" in the regulator node.
>
> Cc: Subhash Jadavani <subhashj@codeaurora.org>
> Cc: Vivek Gautam <vivek.gautam@codeaurora.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
Looks good.
Reviewed-by: Vivek Gautam <vivek.gautam@codeaurora.org>
Regards
Vivek
> Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 1 -
> drivers/phy/phy-qcom-ufs-i.h | 1 -
> drivers/phy/phy-qcom-ufs.c | 5 +----
> 3 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt
> index b6b5130e5f65..1f69ee1a61ea 100644
> --- a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt
> +++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt
> @@ -29,7 +29,6 @@ Optional properties:
> - vdda-pll-max-microamp : specifies max. load that can be drawn from pll supply
> - vddp-ref-clk-supply : phandle to UFS device ref_clk pad power supply
> - vddp-ref-clk-max-microamp : specifies max. load that can be drawn from this supply
> -- vddp-ref-clk-always-on : specifies if this supply needs to be kept always on
>
> Example:
>
> diff --git a/drivers/phy/phy-qcom-ufs-i.h b/drivers/phy/phy-qcom-ufs-i.h
> index d505d98cf5f8..13b02b7de30b 100644
> --- a/drivers/phy/phy-qcom-ufs-i.h
> +++ b/drivers/phy/phy-qcom-ufs-i.h
> @@ -77,7 +77,6 @@ struct ufs_qcom_phy_vreg {
> int min_uV;
> int max_uV;
> bool enabled;
> - bool is_always_on;
> };
>
> struct ufs_qcom_phy {
> diff --git a/drivers/phy/phy-qcom-ufs.c b/drivers/phy/phy-qcom-ufs.c
> index bbd317158084..c145fa6e824c 100644
> --- a/drivers/phy/phy-qcom-ufs.c
> +++ b/drivers/phy/phy-qcom-ufs.c
> @@ -242,9 +242,6 @@ static int ufs_qcom_phy_init_vreg(struct device *dev,
> }
> err = 0;
> }
> - snprintf(prop_name, MAX_PROP_NAME, "%s-always-on", name);
> - vreg->is_always_on = of_property_read_bool(dev->of_node,
> - prop_name);
> }
>
> if (!strcmp(name, "vdda-pll")) {
> @@ -402,7 +399,7 @@ static int ufs_qcom_phy_disable_vreg(struct device *dev,
> {
> int ret = 0;
>
> - if (!vreg || !vreg->enabled || vreg->is_always_on)
> + if (!vreg || !vreg->enabled)
> goto out;
>
> ret = regulator_disable(vreg->reg);
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [RFC v2 4/5] DT bindings documentation for Synopsys UDC platform driver
From: Florian Fainelli @ 2017-01-19 19:40 UTC (permalink / raw)
To: Scott Branden, Rob Herring, Raviteja Garimella
Cc: Mark Rutland, Greg Kroah-Hartman, Felipe Balbi, devicetree,
linux-kernel, bcm-kernel-feedback-list, linux-usb
In-Reply-To: <f86f32cd-8fed-c30f-d647-8f7992013458@broadcom.com>
On 01/19/2017 11:30 AM, Scott Branden wrote:
> Hi Rob,
>
> On 17-01-19 09:36 AM, Rob Herring wrote:
>> On Tue, Jan 17, 2017 at 01:35:07PM +0530, Raviteja Garimella wrote:
>>> This patch adds device tree bindings documentation for Synopsys
>>> USB device controller platform driver.
>>
>> Bindings describe h/w, not drivers.
>>>
>>> Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
>>> ---
>>> .../devicetree/bindings/usb/snps,dw-ahb-udc.txt | 27
>>> ++++++++++++++++++++++
>>> 1 file changed, 27 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>> b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>> new file mode 100644
>>> index 0000000..0c18327
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>> @@ -0,0 +1,27 @@
>>> +Synopsys USB Device controller.
>>> +
>>> +The device node is used for Synopsys Designware Cores AHB
>>> +Subsystem Device Controller (UDC).
>>> +
>>> +This device node is used by UDCs integrated it Broadcom's
>>> +Northstar2 and Cygnus SoC's.
>>
>> You need compatible strings for these in addition.
>>
> We don't need compatibility strings when an IP block is integrated into
> an SoC. Otherwise each time we add the IP block to a new SoC we would
> need to update ever linux driver that supports that SoC. That doesn't
> make sense?
You probably do need such a thing, here is how the compatible strings
for IP blocks integrated into SoCs could be used:
- provide a compatible strings which describes exactly the integration
of this peripheral into a given SoC, e.g: brcm,udc-ns2, the reason for
that is that you want to be able to capture the specific IP block
integration into a specific SoC and all its quirks
- if the block has its own revision scheme (and it can be relied on),
provide it: brcm,udc-v1.2 and that is probably the most meaningful
compatible string for a client program here
- have a some kind of fallback/catchall compatible string that describes
the block: brcm,udc which may also work just fine, although is not preferred
Defining compatible strings is meant to avoid making (possibly
incompatible) Device Tree binding changes in the future, and you always
have the liberty as a client program (OS, bootloader) to match only the
compatible strings you care about, from the most specific (which
includes the exact SoC) to the least specific.
The key thing is that, if the full set of compatible strings are present
and available, you can retroactively fix your driver to be more
specific, very much less so your Device Tree blob (although there is
disagreement).
--
Florian
^ permalink raw reply
* [PATCH] usb: dwc3: add quirk to handle DWC_USB3_NUM == DWC_USB3_NUM_IN_EPS
From: Bryan O'Donoghue @ 2017-01-19 19:58 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
balbi-DgEjT+Ai2ygdnm+yROfE0A, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Bryan O'Donoghue
- DWC_USB3_NUM indicates the number of Device mode single directional
endpoints, including OUT and IN endpoint 0.
- DWC_USB3_NUM_IN_EPS indicates the maximum number of Device mode IN
endpoints active at any time, including control endpoint 0.
It's possible to configure RTL such that DWC_USB3_NUM_EPS is equal to
DWC_USB3_NUM_IN_EPS.
dwc3-core calculates the number of OUT endpoints as DWC_USB3_NUM minus
DWC_USB3_NUM_IN_EPS. If RTL has been configured with DWC_USB3_NUM_IN_EPS
equal to DWC_USB3_NUM then dwc3-core will calculate the number of OUT
endpoints as zero.
For example a from dwc3_core_num_eps() shows:
[ 1.565000] /usb0@f01d0000: found 8 IN and 0 OUT endpoints
This patch fixes this case by adding a snps,num_in_eps quirk and an
over-ride value for DWC_USB3_NUM_IN_EPS snps,num_in_eps_override. When the
quirk is declared then snps,num_in_eps_override will be used instead of
DWC_USB3_NUM_IN_EPS as the value of the number active IN endpoints.
The minimum value specified for DWC_USB3_NUM_IN_EPS in the Designware
data-book is two, if snps,num_in_eps_quirk is declared but
snps,num_in_eps_override is omitted, then the minimum value will be used as
the default.
Signed-off-by: Bryan O'Donoghue <pure.logic-SyKdqv6vbfZdzvEItQ6vdLNAH6kLmebB@public.gmane.org>
---
Documentation/devicetree/bindings/usb/dwc3.txt | 3 +++
drivers/usb/dwc3/core.c | 11 +++++++++++
drivers/usb/dwc3/core.h | 6 ++++++
3 files changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
index e3e6983..bb383bf 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -55,6 +55,9 @@ Optional properties:
fladj_30mhz_sdbnd signal is invalid or incorrect.
- <DEPRECATED> tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - snps,num_in_eps_quirk: when set core will over-ride the num_in_eps value.
+ - snps,num_in_eps_override: the value that will be used for num_in_eps when
+ num_in_eps_quirk is true
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 369bab1..d5e472a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -398,6 +398,8 @@ static void dwc3_core_num_eps(struct dwc3 *dwc)
struct dwc3_hwparams *parms = &dwc->hwparams;
dwc->num_in_eps = DWC3_NUM_IN_EPS(parms);
+ if (dwc->num_in_eps_quirk)
+ dwc->num_in_eps = dwc->num_in_eps_override;
dwc->num_out_eps = DWC3_NUM_EPS(parms) - dwc->num_in_eps;
}
@@ -908,6 +910,7 @@ static void dwc3_get_properties(struct dwc3 *dwc)
struct device *dev = dwc->dev;
u8 lpm_nyet_threshold;
u8 tx_de_emphasis;
+ u8 num_in_eps_override;
u8 hird_threshold;
/* default to highest possible threshold */
@@ -922,6 +925,9 @@ static void dwc3_get_properties(struct dwc3 *dwc)
*/
hird_threshold = 12;
+ /* default value of 2 is the minimum RTL parameter value */
+ num_in_eps_override = 2;
+
dwc->maximum_speed = usb_get_maximum_speed(dev);
dwc->dr_mode = usb_get_dr_mode(dev);
dwc->hsphy_mode = of_usb_get_phy_mode(dev->of_node);
@@ -981,9 +987,14 @@ static void dwc3_get_properties(struct dwc3 *dwc)
&dwc->hsphy_interface);
device_property_read_u32(dev, "snps,quirk-frame-length-adjustment",
&dwc->fladj);
+ dwc->num_in_eps_quirk = device_property_read_bool(dev,
+ "snps,num_in_eps_quirk");
+ device_property_read_u8(dev, "snps,num_in_eps_override",
+ &num_in_eps_override);
dwc->lpm_nyet_threshold = lpm_nyet_threshold;
dwc->tx_de_emphasis = tx_de_emphasis;
+ dwc->num_in_eps_override = num_in_eps_override;
dwc->hird_threshold = hird_threshold
| (dwc->is_utmi_l1_suspend << 4);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 14b7602..3fe6dfc 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -853,6 +853,9 @@ struct dwc3_scratchpad_array {
* 3 - Reserved
* @imod_interval: set the interrupt moderation interval in 250ns
* increments or 0 to disable.
+ * @num_in_eps_quirk: set if silicon reports number of device-mode IN endpoints
+ * as equal to equal to the total number of endpoints.
+ * @num_in_eps_override: The value to set the number of IN endpoints to.
*/
struct dwc3 {
struct usb_ctrlrequest *ctrl_req;
@@ -1003,6 +1006,9 @@ struct dwc3 {
unsigned tx_de_emphasis:2;
u16 imod_interval;
+
+ unsigned num_in_eps_quirk:1;
+ unsigned num_in_eps_override:6;
};
/* -------------------------------------------------------------------------- */
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC v2 4/5] DT bindings documentation for Synopsys UDC platform driver
From: Scott Branden @ 2017-01-19 20:07 UTC (permalink / raw)
To: Florian Fainelli, Rob Herring, Raviteja Garimella
Cc: Mark Rutland, Greg Kroah-Hartman, Felipe Balbi,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <95544a16-08aa-f983-465c-e557b4d3785e-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Florian,
On 17-01-19 11:40 AM, Florian Fainelli wrote:
> On 01/19/2017 11:30 AM, Scott Branden wrote:
>> Hi Rob,
>>
>> On 17-01-19 09:36 AM, Rob Herring wrote:
>>> On Tue, Jan 17, 2017 at 01:35:07PM +0530, Raviteja Garimella wrote:
>>>> This patch adds device tree bindings documentation for Synopsys
>>>> USB device controller platform driver.
>>>
>>> Bindings describe h/w, not drivers.
>>>>
>>>> Signed-off-by: Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>>> ---
>>>> .../devicetree/bindings/usb/snps,dw-ahb-udc.txt | 27
>>>> ++++++++++++++++++++++
>>>> 1 file changed, 27 insertions(+)
>>>> create mode 100644
>>>> Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>> b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>> new file mode 100644
>>>> index 0000000..0c18327
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>> @@ -0,0 +1,27 @@
>>>> +Synopsys USB Device controller.
>>>> +
>>>> +The device node is used for Synopsys Designware Cores AHB
>>>> +Subsystem Device Controller (UDC).
>>>> +
>>>> +This device node is used by UDCs integrated it Broadcom's
>>>> +Northstar2 and Cygnus SoC's.
>>>
>>> You need compatible strings for these in addition.
>>>
>> We don't need compatibility strings when an IP block is integrated into
>> an SoC. Otherwise each time we add the IP block to a new SoC we would
>> need to update ever linux driver that supports that SoC. That doesn't
>> make sense?
>
> You probably do need such a thing, here is how the compatible strings
> for IP blocks integrated into SoCs could be used:
>
> - provide a compatible strings which describes exactly the integration
> of this peripheral into a given SoC, e.g: brcm,udc-ns2, the reason for
> that is that you want to be able to capture the specific IP block
> integration into a specific SoC and all its quirks
>
> - if the block has its own revision scheme (and it can be relied on),
> provide it: brcm,udc-v1.2 and that is probably the most meaningful
> compatible string for a client program here
>
> - have a some kind of fallback/catchall compatible string that describes
> the block: brcm,udc which may also work just fine, although is not preferred
>
> Defining compatible strings is meant to avoid making (possibly
> incompatible) Device Tree binding changes in the future, and you always
> have the liberty as a client program (OS, bootloader) to match only the
> compatible strings you care about, from the most specific (which
> includes the exact SoC) to the least specific.
>
> The key thing is that, if the full set of compatible strings are present
> and available, you can retroactively fix your driver to be more
> specific, very much less so your Device Tree blob (although there is
> disagreement).
>
The driver stands alone from the SoC and does not need compatibility
strings per SoC. New SoCs will use the exact same block.
We don't add compatibility strings to any other drivers when we add the
same block to a new SoC.
Yes, if the version of the IP changes then a version or feature
compatibility string is added to the driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Kalle Valo @ 2017-01-19 20:10 UTC (permalink / raw)
To: Ulf Hansson
Cc: Matt Ranostay, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, Tony Lindgren, Shawn Lin
In-Reply-To: <CAPDyKFpcKuybQmhqCkaAkOM5d+ubU8O8=adLm+PXwc=+N87vng@mail.gmail.com>
Ulf Hansson <ulf.hansson@linaro.org> writes:
> Twisting my head around how this could be integrated smoothly into
> pwrseq simple. No, I just can find a good way forward without messing
> up pwrseq simple itself.
>
> So, for now I decided (once more :-), that let's keep this as separate driver!
>
> Perhaps, following device specific mmc pwrseq drivers will needs
> something similar, but in such case we can look into that then.
> Thinking about cw1200 for example.
>
> Let's get Rob's ack for the DT bindings, seems almost there, then I
> will queue this.
Just to confirm, you will take the whole set (including the bindings
patch)?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v7 3/3] arm64: dts: exynos: Add tm2 touchkey node
From: Krzysztof Kozlowski @ 2017-01-19 20:10 UTC (permalink / raw)
To: Jaechul Lee
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Andi Shyti, Chanwoo Choi,
beomho.seo-Sze3O3UU22JBDgjK7y7TUQ,
galaxyra-Re5JQEeQqe8AvxtiuMwx3w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484632479-3111-4-git-send-email-jcsing.lee-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Tue, Jan 17, 2017 at 02:54:39PM +0900, Jaechul Lee wrote:
> Add DT node support for TM2 touchkey device.
>
> Signed-off-by: Beomho Seo <beomho.seo-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Jaechul Lee <jcsing.lee-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Reviewed-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
--
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] usb: dwc3: add quirk to handle DWC_USB3_NUM == DWC_USB3_NUM_IN_EPS
From: Felipe Balbi @ 2017-01-19 20:16 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, John Youn
Cc: Bryan O'Donoghue
In-Reply-To: <1484855882-4936-1-git-send-email-pure.logic-SyKdqv6vbfZdzvEItQ6vdLNAH6kLmebB@public.gmane.org>
Hi,
Bryan O'Donoghue <pure.logic-SyKdqv6vbfZdzvEItQ6vdLNAH6kLmebB@public.gmane.org> writes:
> - DWC_USB3_NUM indicates the number of Device mode single directional
> endpoints, including OUT and IN endpoint 0.
>
> - DWC_USB3_NUM_IN_EPS indicates the maximum number of Device mode IN
> endpoints active at any time, including control endpoint 0.
>
> It's possible to configure RTL such that DWC_USB3_NUM_EPS is equal to
> DWC_USB3_NUM_IN_EPS.
in that case, isn't it so you really don't have OUT eps? Why was your HW
configured like this? Is this is silicon already or in FPGA or something
early development-only part?
> dwc3-core calculates the number of OUT endpoints as DWC_USB3_NUM minus
> DWC_USB3_NUM_IN_EPS. If RTL has been configured with DWC_USB3_NUM_IN_EPS
correctly so.
> equal to DWC_USB3_NUM then dwc3-core will calculate the number of OUT
> endpoints as zero.
right
> For example a from dwc3_core_num_eps() shows:
> [ 1.565000] /usb0@f01d0000: found 8 IN and 0 OUT endpoints
>
> This patch fixes this case by adding a snps,num_in_eps quirk and an
"This patch works around this case" would've been better here.
> over-ride value for DWC_USB3_NUM_IN_EPS snps,num_in_eps_override. When the
> quirk is declared then snps,num_in_eps_override will be used instead of
> DWC_USB3_NUM_IN_EPS as the value of the number active IN endpoints.
you don't need two values. A read of a non-existing property will return
0, IIRC.
> The minimum value specified for DWC_USB3_NUM_IN_EPS in the Designware
> data-book is two, if snps,num_in_eps_quirk is declared but
> snps,num_in_eps_override is omitted, then the minimum value will be used as
> the default.
>
> Signed-off-by: Bryan O'Donoghue <pure.logic-SyKdqv6vbfZdzvEItQ6vdLNAH6kLmebB@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/dwc3.txt | 3 +++
> drivers/usb/dwc3/core.c | 11 +++++++++++
> drivers/usb/dwc3/core.h | 6 ++++++
> 3 files changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
> index e3e6983..bb383bf 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -55,6 +55,9 @@ Optional properties:
> fladj_30mhz_sdbnd signal is invalid or incorrect.
>
> - <DEPRECATED> tx-fifo-resize: determines if the FIFO *has* to be reallocated.
> + - snps,num_in_eps_quirk: when set core will over-ride the num_in_eps value.
> + - snps,num_in_eps_override: the value that will be used for num_in_eps when
> + num_in_eps_quirk is true
please declare these on the section above. Not below the one deprecated
property.
And as I said, you only need one property.
> This is usually a subnode to DWC3 glue to which it is connected.
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 369bab1..d5e472a 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -398,6 +398,8 @@ static void dwc3_core_num_eps(struct dwc3 *dwc)
> struct dwc3_hwparams *parms = &dwc->hwparams;
>
> dwc->num_in_eps = DWC3_NUM_IN_EPS(parms);
> + if (dwc->num_in_eps_quirk)
> + dwc->num_in_eps = dwc->num_in_eps_override;
> dwc->num_out_eps = DWC3_NUM_EPS(parms) - dwc->num_in_eps;
> }
>
> @@ -908,6 +910,7 @@ static void dwc3_get_properties(struct dwc3 *dwc)
> struct device *dev = dwc->dev;
> u8 lpm_nyet_threshold;
> u8 tx_de_emphasis;
> + u8 num_in_eps_override;
> u8 hird_threshold;
>
> /* default to highest possible threshold */
> @@ -922,6 +925,9 @@ static void dwc3_get_properties(struct dwc3 *dwc)
> */
> hird_threshold = 12;
>
> + /* default value of 2 is the minimum RTL parameter value */
> + num_in_eps_override = 2;
> +
> dwc->maximum_speed = usb_get_maximum_speed(dev);
> dwc->dr_mode = usb_get_dr_mode(dev);
> dwc->hsphy_mode = of_usb_get_phy_mode(dev->of_node);
> @@ -981,9 +987,14 @@ static void dwc3_get_properties(struct dwc3 *dwc)
> &dwc->hsphy_interface);
> device_property_read_u32(dev, "snps,quirk-frame-length-adjustment",
> &dwc->fladj);
> + dwc->num_in_eps_quirk = device_property_read_bool(dev,
> + "snps,num_in_eps_quirk");
> + device_property_read_u8(dev, "snps,num_in_eps_override",
> + &num_in_eps_override);
avoid the quirk flag and try like this:
device_property_read_u8(...);
num_in_eps = NUM_IN_EPS();
num_out_eps = total - num_in_eps;
if (num_out_eps == 0) {
num_in_eps = dwc->override;
num_out_eps = total - num_in_eps;
}
John, does this look correct to you, btw? I don't have my documentation
right now (@home)
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC v2 4/5] DT bindings documentation for Synopsys UDC platform driver
From: Florian Fainelli @ 2017-01-19 20:17 UTC (permalink / raw)
To: Scott Branden, Florian Fainelli, Rob Herring, Raviteja Garimella
Cc: Mark Rutland, Greg Kroah-Hartman, Felipe Balbi, devicetree,
linux-kernel, bcm-kernel-feedback-list, linux-usb
In-Reply-To: <dce7e46f-66f7-7c8d-182d-ba8347082b52@broadcom.com>
On 01/19/2017 12:07 PM, Scott Branden wrote:
> Hi Florian,
>
> On 17-01-19 11:40 AM, Florian Fainelli wrote:
>> On 01/19/2017 11:30 AM, Scott Branden wrote:
>>> Hi Rob,
>>>
>>> On 17-01-19 09:36 AM, Rob Herring wrote:
>>>> On Tue, Jan 17, 2017 at 01:35:07PM +0530, Raviteja Garimella wrote:
>>>>> This patch adds device tree bindings documentation for Synopsys
>>>>> USB device controller platform driver.
>>>>
>>>> Bindings describe h/w, not drivers.
>>>>>
>>>>> Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
>>>>> ---
>>>>> .../devicetree/bindings/usb/snps,dw-ahb-udc.txt | 27
>>>>> ++++++++++++++++++++++
>>>>> 1 file changed, 27 insertions(+)
>>>>> create mode 100644
>>>>> Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>>>
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>>> b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>>> new file mode 100644
>>>>> index 0000000..0c18327
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>>> @@ -0,0 +1,27 @@
>>>>> +Synopsys USB Device controller.
>>>>> +
>>>>> +The device node is used for Synopsys Designware Cores AHB
>>>>> +Subsystem Device Controller (UDC).
>>>>> +
>>>>> +This device node is used by UDCs integrated it Broadcom's
>>>>> +Northstar2 and Cygnus SoC's.
>>>>
>>>> You need compatible strings for these in addition.
>>>>
>>> We don't need compatibility strings when an IP block is integrated into
>>> an SoC. Otherwise each time we add the IP block to a new SoC we would
>>> need to update ever linux driver that supports that SoC. That doesn't
>>> make sense?
>>
>> You probably do need such a thing, here is how the compatible strings
>> for IP blocks integrated into SoCs could be used:
>>
>> - provide a compatible strings which describes exactly the integration
>> of this peripheral into a given SoC, e.g: brcm,udc-ns2, the reason for
>> that is that you want to be able to capture the specific IP block
>> integration into a specific SoC and all its quirks
>>
>> - if the block has its own revision scheme (and it can be relied on),
>> provide it: brcm,udc-v1.2 and that is probably the most meaningful
>> compatible string for a client program here
>>
>> - have a some kind of fallback/catchall compatible string that describes
>> the block: brcm,udc which may also work just fine, although is not
>> preferred
>>
>> Defining compatible strings is meant to avoid making (possibly
>> incompatible) Device Tree binding changes in the future, and you always
>> have the liberty as a client program (OS, bootloader) to match only the
>> compatible strings you care about, from the most specific (which
>> includes the exact SoC) to the least specific.
>>
>> The key thing is that, if the full set of compatible strings are present
>> and available, you can retroactively fix your driver to be more
>> specific, very much less so your Device Tree blob (although there is
>> disagreement).
>>
> The driver stands alone from the SoC and does not need compatibility
> strings per SoC. New SoCs will use the exact same block.
Even if you take the exact same block and put it in a different SoC,
that's still an integration work that 99% of the time goes just fine
because the validation worked great, and the 1% of the time where you
need to capture an integration bug, you are glad this SoC-specific
compatible string exists such that you can work around it in the driver.
One way to solve that is to use SoC specific compatible strings because
that presents itself as a self-contained and standardized way, or you
can have your driver call into a piece of code that reads the SoC
type/revision, but AFAICT this seems to be frowned upon because it
presents some kind of layering violation.
>
> We don't add compatibility strings to any other drivers when we add the
> same block to a new SoC.
Ideally we would define new compatible strings for each new SoC we tape
out, yet don't necessarily match them in client programs, but just
define them as a safeguard in case something went wrong at the
integration stage that is discovered after the fact.
--
Florian
^ permalink raw reply
* Re: Re: [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode
From: Karsten Merker @ 2017-01-19 20:27 UTC (permalink / raw)
To: Icenowy Zheng, Hans de Goede
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Bin Liu,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
In-Reply-To: <1682741484838608-kYtBYcqtKoJuio3avFS2gg@public.gmane.org>
On Thu, Jan 19, 2017 at 11:10:08PM +0800, Icenowy Zheng wrote:
> 19.01.2017, 22:34, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
> > On Wed, Jan 18, 2017 at 04:09:32AM +0800, Chen-Yu Tsai wrote:
> >> On Wed, Jan 18, 2017 at 4:06 AM, Maxime Ripard
> >> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> >> > On Wed, Jan 18, 2017 at 12:57:08AM +0800, Icenowy Zheng wrote:
> >> >> 17.01.2017, 16:06, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> >> >> > On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote:
> >> >> >> The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
> >> >> >> controller.
> >> >> >>
> >> >> >> The original driver wired it to OHCI/EHCI controller; however, as the
> >> >> >> code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
> >> >> >> unusable.
> >> >> >>
> >> >> >> Rename the register (according to its function and the name in BSP
> >> >> >> driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
> >> >> >> can support both peripheral and host mode (although the host mode of
> >> >> >> MUSB is buggy).
> >> >> >
> >> >> > Can you elaborate on that? What's wrong with it?
> >> >>
> >> >> The configuration is at bit 0 of register 0x20 in PHY.
> >> >>
> >> >> When the PHY is reseted, it defaults as MUSB mode.
> >> >>
> >> >> However, the original author of the H3 PHY code seems to be lack of
> >> >> this knowledge (He named it PHY_UNK_H3), and changed the PHY to HCI
> >> >> mode.
> >> >>
> >> >> I just removed the code that wires it to HCI mode, thus it will work
> >> >> in MUSB mode, with my sun8i-h3-musb patch.
> >> >
> >> > I have no idea what you mean by MUSB mode.
> >> >
> >> > Do you mean that the previous code was only working in host mode, and
> >> > now it only works in peripheral?
> >>
> >> From what I understand, with the H3, Allwinner has put a mux
> >> in front of the MUSB controller. The mux can send the USB data
> >> to/from the MUSB controller, or a standard EHCI/OHCI pair.
> >> This register controls said mux.
> >>
> >> This means we can use a proper USB host for host mode,
> >> instead of the limited support in MUSB.
> >
> > But musb can still operate as a host, right?
>
> Yes!
Hello,
I don't know how the MUSB implementation in the H3 behaves as I
don't have any H3-based systems, but if it should happen to be
similar to the one in the A31s, it probably isn't a full-fledged
alternative to using an OHCI/EHCI controller.
>From my practical experiments with the MUSB in the A31s in host
mode I can report that I hadn't been able to get multiple HIDs
(in my case keyboard and mouse) working at the same time. The
keyboard alone worked without problems, the mouse alone worked
without problems, but when both were connected, only one of them
worked.
I had at that time talked to Hans de Goede about the problem and
if I remenber correctly, he had mentioned that the MUSB has
problems servicing more than one device that does interrupt
transfers (as HIDs do).
Hans, can you perhaps shed some light on this?
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
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 v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Ulf Hansson @ 2017-01-19 20:30 UTC (permalink / raw)
To: Kalle Valo
Cc: Matt Ranostay, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
devicetree@vger.kernel.org, Tony Lindgren, Shawn Lin
In-Reply-To: <87efzyhkup.fsf@purkki.adurom.net>
On 19 January 2017 at 21:10, Kalle Valo <kvalo@codeaurora.org> wrote:
> Ulf Hansson <ulf.hansson@linaro.org> writes:
>
>> Twisting my head around how this could be integrated smoothly into
>> pwrseq simple. No, I just can find a good way forward without messing
>> up pwrseq simple itself.
>>
>> So, for now I decided (once more :-), that let's keep this as separate driver!
>>
>> Perhaps, following device specific mmc pwrseq drivers will needs
>> something similar, but in such case we can look into that then.
>> Thinking about cw1200 for example.
>>
>> Let's get Rob's ack for the DT bindings, seems almost there, then I
>> will queue this.
>
> Just to confirm, you will take the whole set (including the bindings
> patch)?
Yes, correct.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Chris Packham @ 2017-01-19 21:10 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-arm-kernel@lists.infradead.org, Mark Rutland,
Thomas Petazzoni, linux-gpio@vger.kernel.org, Linus Walleij,
linux-kernel@vger.kernel.org, Rob Herring, Kalyan Kinthada,
devicetree@vger.kernel.org, Laxman Dewangan,
Sebastian Hesselbarth
In-Reply-To: <20170119100244.GX27312@n2100.armlinux.org.uk>
On 19/01/17 23:03, Russell King - ARM Linux wrote:
> On Fri, Jan 13, 2017 at 10:12:18PM +1300, Chris Packham wrote:
>> +static struct mvebu_mpp_ctrl mv98dx3236_mpp_controls[] = {
>> + MPP_FUNC_CTRL(0, 32, NULL, armada_xp_mpp_ctrl),
>> +};
>
> As Linus has taken my mvebu pinctrl series, this will need to be
> changed to "mvebu_mmio_mpp_ctrl" rather than "armada_xp_mpp_ctrl"
> when it's merged.
>
OK I was thinking about rebasing my series so maybe it's time.
^ permalink raw reply
* Re: [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Chris Packham @ 2017-01-19 21:12 UTC (permalink / raw)
To: Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: Kalyan Kinthada, Linus Walleij, Rob Herring, Mark Rutland,
Thomas Petazzoni, Laxman Dewangan,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <9996b6a215f944e1a47fa6239d8de21f@svr-chch-ex1.atlnz.lc>
On 14/01/17 20:50, Chris Packham wrote:
> On 13/01/17 22:54, Sebastian Hesselbarth wrote:
>> On 13.01.2017 10:12, Chris Packham wrote:
>>> From: Kalyan Kinthada <kalyan.kinthada-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
>>>
>>> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
>>> from Marvell.
>>>
>>> Signed-off-by: Kalyan Kinthada <kalyan.kinthada-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
>>> Signed-off-by: Chris Packham <chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> ---
>>>
>>> Notes:
>>> Changes in v2:
>>> - include sdio support for the 98DX4251
>>> Changes in v3:
>>> - None
>>> Changes in v4:
>>> - Correct some discrepencies between binding and driver.
>>
>> Well, unfortunately I still see differences between the "gpio" in
>> the binding and "gpo" in the driver.
>>
>> Please go back to that list I sent you yesterday and fix them all.
>>
>
> I think you may have missed my initial reply [1]. Or I have missed your
> response to it. Long story short "gpo" is intentional because some of
> those pins can't be used as inputs. But if you still want me to change
> it I will.
>
> [1] - https://lkml.org/lkml/2017/1/12/117
>
Hi Sebastian,
Did you get a chance to consider this. Do you still want me to change
gpo -> gpio given the information above?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox