Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v2] i2c: do not enable fall back to Host Notify by default
From: Rob Herring @ 2017-01-09 17:56 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Wolfram Sang, Benjamin Tissoires, Pali Rohár,
	Michał Kępień, Jean Delvare, Takashi Iwai,
	linux-i2c, devicetree, linux-kernel
In-Reply-To: <20170105045722.GA17958@dtor-ws>

On Wed, Jan 04, 2017 at 08:57:22PM -0800, Dmitry Torokhov wrote:
> Falling back unconditionally to HostNotify as primary client's interrupt
> breaks some drivers which alter their functionality depending on whether
> interrupt is present or not, so let's introduce a board flag telling I2C
> core explicitly if we want wired interrupt or HostNotify-based one:
> I2C_CLIENT_HOST_NOTIFY.
> 
> For DT-based systems we introduce "host-notify" property that we convert
> to I2C_CLIENT_HOST_NOTIFY board flag.
> 
> Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> 
> v1->v2:
> 
> - of_read_property_bool -> of_property_read_bool
> - did not change binding wording to avoit mentioning I2C core because we
>   use the same wording (mentioning I2C core) for wired interrupts
> 
>  Documentation/devicetree/bindings/i2c/i2c.txt |  8 ++++++++

Acked-by: Rob Herring <robh@kernel.org>

>  drivers/i2c/i2c-core.c                        | 17 ++++++++---------
>  include/linux/i2c.h                           |  1 +
>  3 files changed, 17 insertions(+), 9 deletions(-)

^ permalink raw reply

* Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2017-01-09 17:57 UTC (permalink / raw)
  To: Rob Herring
  Cc: Nishanth Menon, devicetree, Ulf Hansson, Santosh Shilimkar,
	linux-pm, Lokesh Vutla, Keerthy, Kevin Hilman, Rafael J . Wysocki,
	linux-kernel, Tero Kristo, Russell King, Sudeep Holla,
	linux-arm-kernel
In-Reply-To: <20170109175012.sg7eze7llqq7qevd@rob-hp-laptop>

Rob,
On 01/09/2017 11:50 AM, Rob Herring wrote:
> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>> Add a generic power domain implementation, TI SCI PM Domains, that
>> will hook into the genpd framework and allow the TI SCI protocol to
>> control device power states.
>>
>> Also, provide macros representing each device index as understood
>> by TI SCI to be used in the device node power-domain references.
>> These are identifiers for the K2G devices managed by the PMMC.
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>> v2->v3:
>> 	Update k2g_pds node docs to show it should be a child of pmmc node.
>> 	In early versions a phandle was used to point to pmmc and docs still
>> 	incorrectly showed this.
>>
>>  .../devicetree/bindings/soc/ti/sci-pm-domain.txt   | 59 ++++++++++++++
>>  MAINTAINERS                                        |  2 +
>>  include/dt-bindings/genpd/k2g.h                    | 90 ++++++++++++++++++++++
>>  3 files changed, 151 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>  create mode 100644 include/dt-bindings/genpd/k2g.h
>>
>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>> new file mode 100644
>> index 000000000000..4c9064e512cb
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>> @@ -0,0 +1,59 @@
>> +Texas Instruments TI-SCI Generic Power Domain
>> +---------------------------------------------
>> +
>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>> +responsible for controlling the state of the IPs that are present.
>> +Communication between the host processor running an OS and the system
>> +controller happens through a protocol known as TI-SCI [1]. This pm domain
>> +implementation plugs into the generic pm domain framework and makes use of
>> +the TI SCI protocol power on and off each device when needed.
>> +
>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>> +
>> +PM Domain Node
>> +==============
>> +The PM domain node represents the global PM domain managed by the PMMC,
>> +which in this case is the single implementation as documented by the generic
>> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
>> +Because this relies on the TI SCI protocol to communicate with the PMMC it
>> +must be a child of the pmmc node.
>> +
>> +Required Properties:
>> +--------------------
>> +- compatible: should be "ti,sci-pm-domain"
>> +- #power-domain-cells: Must be 0.
>> +
>> +Example (K2G):
>> +-------------
>> +	pmmc: pmmc {
>> +		compatible = "ti,k2g-sci";
>> +		...
>> +
>> +		k2g_pds: k2g_pds {
>> +			compatible = "ti,sci-pm-domain";
>> +			#power-domain-cells = <0>;
>> +		};
>> +	};
>> +
>> +PM Domain Consumers
>> +===================
>> +Hardware blocks that require SCI control over their state must provide
>> +a reference to the sci-pm-domain they are part of and a unique device
>> +specific ID that identifies the device.
>> +
>> +Required Properties:
>> +--------------------
>> +- power-domains: phandle pointing to the corresponding PM domain node.
>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>> +	     be used for device control.
>
> As I've already stated before, this goes in power-domain cells. When you
> have a single thing (i.e. node) that controls multiple things, then you
> you need to specify the ID for each of them in phandle args. This is how
> irqs, gpio, clocks, *everything* in DT works.

You think the reasoning for doing it this way provided by both Ulf and 
myself on v2 [1] is not valid then?

 From Ulf:

To me, the TI SCI ID, is similar to a "conid" for any another "device
resource" (like clock, pinctrl, regulator etc) which we can describe
in DT and assign to a device node. The only difference here, is that
we don't have common API to fetch the resource (like clk_get(),
regulator_get()), but instead we fetches the device's resource from
SoC specific code, via genpd's device ->attach() callback.

 From me:

Yes, you've pretty much hit it on the head. It is not an index into a 
list of genpds but rather identifies the device *within* a single genpd. 
It is a property specific to each device that resides in a ti-sci-genpd, 
not a mapping describing which genpd the device belongs to. The generic 
power domain binding is concerned with mapping the device to a specific 
genpd, which is does fine for us, but we have a sub mapping for devices 
that exist inside a genpd which, we must describe as well, hence the 
ti,sci-id.


So to summarize, the genpd framework does interpret the phandle arg as 
an index into multiple genpds, just as you've said other frameworks do, 
but this is not what I am trying to do, we have multiple devices within 
this *single* genpd, hence the need for the ti,sci-id property.

Regards,
Dave

[1] https://patchwork.kernel.org/patch/9385371/

>
> Rob
>

^ permalink raw reply

* Re: [PATCH 1/1] iio: adc: tlc4541: add support for TI tlc4541 adc
From: Rob Herring @ 2017-01-09 17:58 UTC (permalink / raw)
  To: Phil Reid
  Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
	lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
	mark.rutland-5wv7dgnIgG8, linux-iio-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483606546-13629-1-git-send-email-preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>

On Thu, Jan 05, 2017 at 04:55:46PM +0800, Phil Reid wrote:
> This adds TI's tlc4541 16-bit ADC driver. Which is a single channel
> ADC. Supports raw and trigger buffer access.
> 
> Signed-off-by: Phil Reid <preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
> ---
>  .../devicetree/bindings/iio/adc/ti-tlc4541.txt     |  16 ++

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

>  drivers/iio/adc/Kconfig                            |  11 +
>  drivers/iio/adc/Makefile                           |   1 +
>  drivers/iio/adc/ti-tlc4541.c                       | 266 +++++++++++++++++++++
>  4 files changed, 294 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/ti-tlc4541.txt
>  create mode 100644 drivers/iio/adc/ti-tlc4541.c

^ permalink raw reply

* Re: [PATCH v7 1/8] MFD: add bindings for STM32 Timers driver
From: Rob Herring @ 2017-01-09 17:59 UTC (permalink / raw)
  To: Benjamin Gaignard
  Cc: mark.rutland, devicetree, lars, alexandre.torgue, linux-pwm,
	linux-iio, linus.walleij, arnaud.pouliquen, linux-kernel,
	thierry.reding, linux-arm-kernel, pmeerw, knaack.h, gerald.baeza,
	fabrice.gasnier, lee.jones, linaro-kernel, jic23,
	Benjamin Gaignard
In-Reply-To: <1483608344-9012-2-git-send-email-benjamin.gaignard@st.com>

On Thu, Jan 05, 2017 at 10:25:37AM +0100, Benjamin Gaignard wrote:
> Add bindings information for STM32 Timers
> 
> version 6:
> - rename stm32-gtimer to stm32-timers
> - change compatible
> - add description about the IPs
> 
> version 2:
> - rename stm32-mfd-timer to stm32-gptimer
> - only keep one compatible string
> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
>  .../devicetree/bindings/mfd/stm32-timers.txt       | 46 ++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v7 2/8] MFD: add STM32 Timers driver
From: Rob Herring @ 2017-01-09 18:00 UTC (permalink / raw)
  To: Benjamin Gaignard
  Cc: lee.jones, mark.rutland, alexandre.torgue, devicetree,
	linux-kernel, thierry.reding, linux-pwm, jic23, knaack.h, lars,
	pmeerw, linux-iio, linux-arm-kernel, fabrice.gasnier,
	gerald.baeza, arnaud.pouliquen, linus.walleij, linaro-kernel,
	Benjamin Gaignard
In-Reply-To: <1483608344-9012-3-git-send-email-benjamin.gaignard@st.com>

On Thu, Jan 05, 2017 at 10:25:38AM +0100, Benjamin Gaignard wrote:
> This hardware block could at used at same time for PWM generation
> and IIO timers.
> PWM and IIO timer configuration are mixed in the same registers
> so we need a multi fonction driver to be able to share those registers.
> 
> version 7:
> - rebase on v4.10-rc2
> 
> version 6:
> - rename files to stm32-timers
> - rename functions to stm32_timers_xxx
> 
> version 5:
> - fix Lee comments about detect function
> - add missing dependency on REGMAP_MMIO
> 
> version 4:
> - add a function to detect Auto Reload Register (ARR) size
> - rename the structure shared with other drivers
> 
> version 2:
> - rename driver "stm32-gptimer" to be align with SoC documentation
> - only keep one compatible
> - use of_platform_populate() instead of devm_mfd_add_devices()
> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
>  .../devicetree/bindings/mfd/stm32-timers.txt       |  2 +-
>  drivers/mfd/Kconfig                                | 11 +++
>  drivers/mfd/Makefile                               |  2 +
>  drivers/mfd/stm32-timers.c                         | 80 ++++++++++++++++++++++
>  include/linux/mfd/stm32-timers.h                   | 71 +++++++++++++++++++
>  5 files changed, 165 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/mfd/stm32-timers.c
>  create mode 100644 include/linux/mfd/stm32-timers.h
> 
> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> index a73301d..897e7c2 100644
> --- a/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> @@ -12,7 +12,7 @@ Required parameters:
>  
>  - reg:			Physical base address and length of the controller's
>  			registers.
> -- clock-names: 		Set to "int".
> +- clock-names:		Set to "int".

This hunk should be dropped or moved to previous patch.

>  - clocks: 		Phandle to the clock used by the timer module.
>  			For Clk properties, please refer to ../clock/clock-bindings.txt
>  

^ permalink raw reply

* Re: [PATCH v7 3/8] PWM: add pwm-stm32 DT bindings
From: Rob Herring @ 2017-01-09 18:01 UTC (permalink / raw)
  To: Benjamin Gaignard
  Cc: lee.jones, mark.rutland, alexandre.torgue, devicetree,
	linux-kernel, thierry.reding, linux-pwm, jic23, knaack.h, lars,
	pmeerw, linux-iio, linux-arm-kernel, fabrice.gasnier,
	gerald.baeza, arnaud.pouliquen, linus.walleij, linaro-kernel,
	Benjamin Gaignard
In-Reply-To: <1483608344-9012-4-git-send-email-benjamin.gaignard@st.com>

On Thu, Jan 05, 2017 at 10:25:39AM +0100, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
> 
> version 6:
> - change st,breakinput parameter format to make it usuable on stm32f7 too.
> 
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
>  .../devicetree/bindings/pwm/pwm-stm32.txt          | 33 ++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v7 5/8] IIO: add bindings for STM32 timer trigger driver
From: Rob Herring @ 2017-01-09 18:04 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,
	linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
	linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Benjamin Gaignard
In-Reply-To: <1483608344-9012-6-git-send-email-benjamin.gaignard-qxv4g6HH51o@public.gmane.org>

On Thu, Jan 05, 2017 at 10:25:41AM +0100, Benjamin Gaignard wrote:
> Define bindings for STM32 timer trigger
> 
> 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>
> ---
>  .../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
> 
> diff --git a/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt b/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
> new file mode 100644
> index 0000000..36a6c4a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
> @@ -0,0 +1,23 @@
> +STMicroelectronics STM32 Timers IIO timer bindings
> +
> +Must be a sub-node of an STM32 Timers device tree node.
> +See ../mfd/stm32-timers.txt for details about the parent node.
> +
> +Required parameters:
> +- compatible:	Must be "st,stm32-timer-trigger".
> +- reg:		Define triggers configuration of the hardware IP.

Valid values? Not sure this makes sense for use of reg. reg should be 
how you address or id a device.

> +
> +Example:
> +	timers@40010000 {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "st,stm32-timers";
> +		reg = <0x40010000 0x400>;
> +		clocks = <&rcc 0 160>;
> +		clock-names = "clk_int";
> +
> +		timer {

This would also need an unit address.

> +			compatible = "st,stm32-timer-trigger";
> +			reg = <0>;
> +		};
> +	};
> -- 
> 1.9.1
> 

^ permalink raw reply

* Re: [PATCH 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
From: Anand Moon @ 2017-01-09 18:04 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Kukjin Kim, Javier Martinez Canillas, devicetree,
	linux-arm-kernel,
	linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux Kernel, Marek Szyprowski, Sylwester Nawrocki, Peter Chen,
	Greg Kroah-Hartman, Alan Stern, Ulf Hansson, Mark Brown,
	sre-DgEjT+Ai2ygdnm+yROfE0A, Rob Herring, Linux USB Mailing List,
	Linux PM list, hverkuil-qWit8jRvyhVmR6Xm/wNWPw, Markus
In-Reply-To: <20170107085203.4431-1-krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Hi Krzysztof,

On 7 January 2017 at 14:21, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Hi,
>
> Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter
> Chen, we got a power sequence generic library which solves my long
> standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader.
>
> My previous attempts for this can be found here [0].
>
> This patchset is based on Peter's v11 of power sequence [1].
> Patchset is available also on my Github [2].
>
> More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix
> LAN9730 on Odroid U3 after tftpboot").
>
>

[snip]

On which u-boot should this be tested.

On HK u-boot tftp boot is not supported.
----------------------------------------------------------
U-Boot 2010.12-00000-g9777ca6-dirty (Nov 26 2015 - 10:10:11) for Exynox4412


CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
APLL = 1000MHz, MPLL = 800MHz
DRAM:  2 GiB

PMIC VERSION : 0x00, CHIP REV : 2
TrustZone Enabled BSP
BL1 version: 20121128


Checking Boot Mode ... SDMMC
MMC Device 0: 14804 MB
MMC Device 1 not found
*** Warning - using default environment

USB3503 NINT = OUTPUT LOW!
ModeKey Check... run normal_boot
No ethernet found.
Hit any key to stop autoboot:  0
Exynos4412 #
Exynos4412 #
Exynos4412 #
Exynos4412 # usb start
(Re)start USB...
USB0:   Exynos4412-ehci: init hccr 12580000 and hcor 12580010 hc_length 16
usb: usb_refclk_enable is active low: NO
ProTIP: If usb doesn't work - try playing with 'usb_invert_clken' environment
USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
EHCI fail timeout STS_ASS set

      USB device not accepting new address (error=80000000)
EHCI fail timeout STS_ASS set
1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
       scanning usb for ethernet devices... 0 Ethernet Device(s) found
Exynos4412 #

Best Regards
-Anand
--
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/2] Documentation: phy: introduce new optional property to specify drive impedance
From: Rob Herring @ 2017-01-09 18:06 UTC (permalink / raw)
  To: Shawn Lin
  Cc: Kishon Vijay Abraham I, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Heiko Stuebner,
	Douglas Anderson, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483608682-226716-1-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>

On Thu, Jan 05, 2017 at 05:31:21PM +0800, Shawn Lin wrote:
> We need to modify the drive impedance according to the
> different hardware condition. So let's expose this to
> the DT.
> 
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> 
>  Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> index e3ea557..731aeb9 100644
> --- a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> @@ -14,6 +14,11 @@ specified by name:
>  		access to it), it is strongly suggested.
>   - clocks: Should have a phandle to the card clock exported by the SDHCI driver.
>  
> +Optional Properties:
> +- drive_impedance: Must be one of 33, 40, 50, 66, 100. This property allows
> +	different boards to specify their own drive impedance depending on the
> +	hardware condition.

Needs a vendor prefix. Don't use '_'. And needs unit suffix (-ohms).

> +
>  Example:
>  
>  
> -- 
> 1.9.1
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 08/11] dmaengine: cppi41: Implement the glue for da8xx
From: Grygorii Strashko @ 2017-01-09 18:08 UTC (permalink / raw)
  To: Alexandre Bailon, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
  Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
	khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
	tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	b-liu-l0cyMroinI0
In-Reply-To: <20170109160656.3470-9-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>



On 01/09/2017 10:06 AM, Alexandre Bailon wrote:
> The da8xx has a cppi41 dma controller.
> This is add the glue layer required to make it work on da8xx,
> as well some changes in driver (e.g to manage clock).
> 
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
>  drivers/dma/cppi41.c | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 95 insertions(+)
> 
> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
> index 939398e..4318e53 100644
> --- a/drivers/dma/cppi41.c
> +++ b/drivers/dma/cppi41.c
> @@ -1,3 +1,4 @@
> +#include <linux/clk.h>
>  #include <linux/delay.h>
>  #include <linux/dmaengine.h>
>  #include <linux/dma-mapping.h>
> @@ -86,10 +87,19 @@
>  
>  #define USBSS_IRQ_PD_COMP	(1 <<  2)
>  
> +/* USB DA8XX */
> +#define DA8XX_INTR_SRC_MASKED	0x38
> +#define DA8XX_END_OF_INTR	0x3c
> +
> +#define DA8XX_QMGR_PENDING_MASK	(0xf << 24)
> +
> +
> +
>  /* Packet Descriptor */
>  #define PD2_ZERO_LENGTH		(1 << 19)
>  
>  #define AM335X_CPPI41		0
> +#define DA8XX_CPPI41		1
>  
>  struct cppi41_channel {
>  	struct dma_chan chan;
> @@ -158,6 +168,9 @@ struct cppi41_dd {
>  
>  	/* context for suspend/resume */
>  	unsigned int dma_tdfdq;
> +
> +	/* da8xx clock */
> +	struct clk *clk;
>  };
>  
>  static struct chan_queues am335x_usb_queues_tx[] = {
> @@ -232,6 +245,20 @@ static const struct chan_queues am335x_usb_queues_rx[] = {
>  	[29] = { .submit = 30, .complete = 155},
>  };
>  
> +static const struct chan_queues da8xx_usb_queues_tx[] = {
> +	[0] = { .submit =  16, .complete = 24},
> +	[1] = { .submit =  18, .complete = 24},
> +	[2] = { .submit =  20, .complete = 24},
> +	[3] = { .submit =  22, .complete = 24},
> +};
> +
> +static const struct chan_queues da8xx_usb_queues_rx[] = {
> +	[0] = { .submit =  1, .complete = 26},
> +	[1] = { .submit =  3, .complete = 26},
> +	[2] = { .submit =  5, .complete = 26},
> +	[3] = { .submit =  7, .complete = 26},
> +};
> +
>  struct cppi_glue_infos {
>  	irqreturn_t (*isr)(int irq, void *data);
>  	const struct chan_queues *queues_rx;
> @@ -366,6 +393,26 @@ static irqreturn_t am335x_cppi41_irq(int irq, void *data)
>  	return cppi41_irq(cdd);
>  }
>  
> +static irqreturn_t da8xx_cppi41_irq(int irq, void *data)
> +{
> +	struct cppi41_dd *cdd = data;
> +	u32 status;
> +	u32 usbss_status;
> +
> +	status = cppi_readl(cdd->qmgr_mem + QMGR_PEND(0));
> +	if (status & DA8XX_QMGR_PENDING_MASK)
> +		cppi41_irq(cdd);
> +	else
> +		return IRQ_NONE;
> +
> +	/* Re-assert IRQ if there no usb core interrupts pending */
> +	usbss_status = cppi_readl(cdd->usbss_mem + DA8XX_INTR_SRC_MASKED);
> +	if (!usbss_status)
> +		cppi_writel(0, cdd->usbss_mem + DA8XX_END_OF_INTR);
> +
> +	return IRQ_HANDLED;
> +}
> +
>  static dma_cookie_t cppi41_tx_submit(struct dma_async_tx_descriptor *tx)
>  {
>  	dma_cookie_t cookie;
> @@ -972,8 +1019,19 @@ static const struct cppi_glue_infos am335x_usb_infos = {
>  	.platform = AM335X_CPPI41,
>  };
>  
> +static const struct cppi_glue_infos da8xx_usb_infos = {
> +	.isr = da8xx_cppi41_irq,
> +	.queues_rx = da8xx_usb_queues_rx,
> +	.queues_tx = da8xx_usb_queues_tx,
> +	.td_queue = { .submit = 31, .complete = 0 },
> +	.first_completion_queue = 24,
> +	.qmgr_num_pend = 2,
> +	.platform = DA8XX_CPPI41,
> +};
> +
>  static const struct of_device_id cppi41_dma_ids[] = {
>  	{ .compatible = "ti,am3359-cppi41", .data = &am335x_usb_infos},
> +	{ .compatible = "ti,da8xx-cppi41", .data = &da8xx_usb_infos},
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, cppi41_dma_ids);
> @@ -995,6 +1053,13 @@ static int is_am335x_cppi41(struct device *dev)
>  	return cdd->platform == AM335X_CPPI41;
>  }
>  
> +static int is_da8xx_cppi41(struct device *dev)
> +{
> +	struct cppi41_dd *cdd = dev_get_drvdata(dev);
> +
> +	return cdd->platform == DA8XX_CPPI41;
> +}
> +
>  #define CPPI41_DMA_BUSWIDTHS	(BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
>  				BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
>  				BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
> @@ -1058,6 +1123,21 @@ static int cppi41_dma_probe(struct platform_device *pdev)
>  	cdd->first_completion_queue = glue_info->first_completion_queue;
>  	cdd->platform = glue_info->platform;
>  
> +	if (is_da8xx_cppi41(dev)) {
> +		cdd->clk = devm_clk_get(&pdev->dev, "usb20");
> +		ret = PTR_ERR_OR_ZERO(cdd->clk);
> +		if (ret) {
> +			dev_err(&pdev->dev, "failed to get clock\n");
> +			goto err_clk_en;
> +		}
> +
> +		ret = clk_prepare_enable(cdd->clk);
> +		if (ret) {
> +			dev_err(dev, "failed to enable clock\n");
> +			goto err_clk_en;
> +		}
> +	}

if this is functional clock then why not to use ./arch/arm/mach-davinci/pm_domain.c ?
wouldn't it work for use if you will just rename "usb20" -> "fck" -
so PM runtime should manage this clock for you?

> +
>  	ret = of_property_read_u32(dev->of_node,
>  				   "#dma-channels", &cdd->n_chans);
>  	if (ret)
> @@ -1112,6 +1192,9 @@ static int cppi41_dma_probe(struct platform_device *pdev)
>  err_init_cppi:
>  	pm_runtime_dont_use_autosuspend(dev);
>  err_get_n_chans:
> +	if (is_da8xx_cppi41(dev))
> +		clk_disable_unprepare(cdd->clk);
> +err_clk_en:
>  err_get_sync:
>  	pm_runtime_put_sync(dev);
>  	pm_runtime_disable(dev);
> @@ -1146,6 +1229,8 @@ static int cppi41_dma_remove(struct platform_device *pdev)
>  	pm_runtime_dont_use_autosuspend(&pdev->dev);
>  	pm_runtime_put_sync(&pdev->dev);
>  	pm_runtime_disable(&pdev->dev);
> +	if (is_da8xx_cppi41(&pdev->dev))
> +		clk_disable_unprepare(cdd->clk);
>  	return 0;
>  }
>  
> @@ -1158,6 +1243,9 @@ static int __maybe_unused cppi41_suspend(struct device *dev)
>  		cppi_writel(0, cdd->usbss_mem + USBSS_IRQ_CLEARR);
>  	disable_sched(cdd);
>  
> +	if (is_da8xx_cppi41(dev))
> +		clk_disable_unprepare(cdd->clk);
> +
>  	return 0;
>  }
>  
> @@ -1165,8 +1253,15 @@ static int __maybe_unused cppi41_resume(struct device *dev)
>  {
>  	struct cppi41_dd *cdd = dev_get_drvdata(dev);
>  	struct cppi41_channel *c;
> +	int ret;
>  	int i;
>  
> +	if (is_da8xx_cppi41(dev)) {
> +		ret = clk_prepare_enable(cdd->clk);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	for (i = 0; i < DESCS_AREAS; i++)
>  		cppi_writel(cdd->descs_phys, cdd->qmgr_mem + QMGR_MEMBASE(i));
>  
> 

-- 
regards,
-grygorii
--
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] iio: accel: st_accel: handle deprecated bindings
From: Rob Herring @ 2017-01-09 18:16 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170105133233.24237-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

On Thu, Jan 05, 2017 at 02:32:33PM +0100, Linus Walleij wrote:
> The earlier deployed LIS3LV02DL driver had already defined a few
> DT bindings that need to be supported by the new more generic
> driver and listed as compatible but deprecated bindings in the
> documentation.
> 
> After this we can start to activate the new driver with the old
> systems where applicable.
> 
> As part of this enablement: make us depend on the old drivers
> not being in use so we don't get a kernel with two competing
> drivers.
> 
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/iio/accel/lis302.txt | 2 +-
>  Documentation/devicetree/bindings/iio/st-sensors.txt   | 2 ++

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

>  drivers/iio/accel/Kconfig                              | 2 ++
>  drivers/iio/accel/st_accel_i2c.c                       | 5 +++++
>  drivers/iio/accel/st_accel_spi.c                       | 9 +++++++++
>  5 files changed, 19 insertions(+), 1 deletion(-)

^ permalink raw reply

* Re: [PATCH 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
From: Krzysztof Kozlowski @ 2017-01-09 18:17 UTC (permalink / raw)
  To: Anand Moon
  Cc: Krzysztof Kozlowski, Kukjin Kim, Javier Martinez Canillas,
	devicetree, linux-arm-kernel,
	linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux Kernel, Marek Szyprowski, Sylwester Nawrocki, Peter Chen,
	Greg Kroah-Hartman, Alan Stern, Ulf Hansson, Mark Brown,
	sre-DgEjT+Ai2ygdnm+yROfE0A, Rob Herring, Linux USB Mailing List,
	Linux PM list
In-Reply-To: <CANAwSgSEZvxHje65Kk13fvD9NZGB+iHCJtoGJdQrUdS42ei_WA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Mon, Jan 09, 2017 at 11:34:48PM +0530, Anand Moon wrote:
> Hi Krzysztof,
> 
> On 7 January 2017 at 14:21, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > Hi,
> >
> > Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter
> > Chen, we got a power sequence generic library which solves my long
> > standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader.
> >
> > My previous attempts for this can be found here [0].
> >
> > This patchset is based on Peter's v11 of power sequence [1].
> > Patchset is available also on my Github [2].
> >
> > More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix
> > LAN9730 on Odroid U3 after tftpboot").
> >
> >
> 
> [snip]
> 
> On which u-boot should this be tested.
> 
> On HK u-boot tftp boot is not supported.

... so you gave an answer: you cannot test it on HK. How many other
U-Boot flavors you know? :)

Best regards,
Krzysztof


> ----------------------------------------------------------
> U-Boot 2010.12-00000-g9777ca6-dirty (Nov 26 2015 - 10:10:11) for Exynox4412
> 
> 
> CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
> APLL = 1000MHz, MPLL = 800MHz
> DRAM:  2 GiB
> 
> PMIC VERSION : 0x00, CHIP REV : 2
> TrustZone Enabled BSP
> BL1 version: 20121128
> 
> 
> Checking Boot Mode ... SDMMC
> MMC Device 0: 14804 MB
> MMC Device 1 not found
> *** Warning - using default environment
> 
> USB3503 NINT = OUTPUT LOW!
> ModeKey Check... run normal_boot
> No ethernet found.
> Hit any key to stop autoboot:  0
> Exynos4412 #
> Exynos4412 #
> Exynos4412 #
> Exynos4412 # usb start
> (Re)start USB...
> USB0:   Exynos4412-ehci: init hccr 12580000 and hcor 12580010 hc_length 16
> usb: usb_refclk_enable is active low: NO
> ProTIP: If usb doesn't work - try playing with 'usb_invert_clken' environment
> USB EHCI 1.00
> scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
> EHCI fail timeout STS_ASS set
> 
>       USB device not accepting new address (error=80000000)
> EHCI fail timeout STS_ASS set
> 1 USB Device(s) found
>        scanning usb for storage devices... 0 Storage Device(s) found
>        scanning usb for ethernet devices... 0 Ethernet Device(s) found
> Exynos4412 #
> 
> Best Regards
> -Anand
--
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] [linux-next] bus:qcom : Fix typo in qcom,ebi2.txt
From: Rob Herring @ 2017-01-09 18:19 UTC (permalink / raw)
  To: Masanari Iida; +Cc: linux-kernel, devicetree, linus.walleij
In-Reply-To: <20170105144307.21871-1-standby24x7@gmail.com>

On Thu, Jan 05, 2017 at 11:43:07PM +0900, Masanari Iida wrote:
> This patch fix 2 spelling typos found in qcom,ebi2.txt
> 
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
> ---
>  Documentation/devicetree/bindings/bus/qcom,ebi2.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Applied, thanks.

Rob

^ permalink raw reply

* Re: [PATCH 1/3] ARM: dts: da850: Add the cppi41 dma node
From: Sergei Shtylyov @ 2017-01-09 18:26 UTC (permalink / raw)
  To: Alexandre Bailon, nsekhar-l0cyMroinI0,
	khilman-rdvid1DuHRBWk0Htik3J/w
  Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, ptitiano-rdvid1DuHRBWk0Htik3J/w,
	tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	b-liu-l0cyMroinI0, david-nq/r/kbU++upp/zk7JDF2g
In-Reply-To: <20170109162449.5012-2-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

Hello.

On 01/09/2017 07:24 PM, Alexandre Bailon wrote:

> This adds the device tree node for the cppi41 dma
> used by the usb otg controller present in the da850 family of SoC's.
>
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
>  arch/arm/boot/dts/da850.dtsi | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 104155d..d6b406a 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -403,6 +403,22 @@
>  			phy-names = "usb-phy";
>  			status = "disabled";
>  		};
> +		cppi41dma: dma-controller@201000 {
> +			compatible = "ti,da8xx-cppi41";
> +			reg =  <0x200000 0x1000

    I don't remember any DA8xx glue regs having to do with the CPPI 4.1...

> +				0x201000 0x1000
> +				0x202000 0x1000
> +				0x204000 0x4000>;
> +			reg-names = "glue", "controller",
> +				    "scheduler", "queuemgr";
> +			interrupts = <58>;
> +			interrupt-names = "glue";
> +			#dma-cells = <2>;
> +			#dma-channels = <4>;
> +			#dma-requests = <256>;
> +			status = "disabled";

    Why disabled? It doesn't use any external pins...

[...]

MBR, Sergei

--
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 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
From: Anand Moon @ 2017-01-09 18:26 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Kukjin Kim, Javier Martinez Canillas, devicetree,
	linux-arm-kernel, linux-samsung-soc@vger.kernel.org, Linux Kernel,
	Marek Szyprowski, Sylwester Nawrocki, Peter Chen,
	Greg Kroah-Hartman, Alan Stern, Ulf Hansson, Mark Brown, sre,
	Rob Herring, Linux USB Mailing List, Linux PM list, hverkuil,
	Markus
In-Reply-To: <20170109181703.436gv7bq76xuv35q@kozik-lap>

Hi Krzysztof,

On 9 January 2017 at 23:47, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, Jan 09, 2017 at 11:34:48PM +0530, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 7 January 2017 at 14:21, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> > Hi,
>> >
>> > Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter
>> > Chen, we got a power sequence generic library which solves my long
>> > standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader.
>> >
>> > My previous attempts for this can be found here [0].
>> >
>> > This patchset is based on Peter's v11 of power sequence [1].
>> > Patchset is available also on my Github [2].
>> >
>> > More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix
>> > LAN9730 on Odroid U3 after tftpboot").
>> >
>> >
>>
>> [snip]
>>
>> On which u-boot should this be tested.
>>
>> On HK u-boot tftp boot is not supported.
>
> ... so you gave an answer: you cannot test it on HK. How many other
> U-Boot flavors you know? :)
>

u-boot mainline have tftp support enable, so I will try to test on this u-boot.

Best Regards
-Anand

> Best regards,
> Krzysztof
>
>
>> ----------------------------------------------------------
>> U-Boot 2010.12-00000-g9777ca6-dirty (Nov 26 2015 - 10:10:11) for Exynox4412
>>
>>
>> CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
>> APLL = 1000MHz, MPLL = 800MHz
>> DRAM:  2 GiB
>>
>> PMIC VERSION : 0x00, CHIP REV : 2
>> TrustZone Enabled BSP
>> BL1 version: 20121128
>>
>>
>> Checking Boot Mode ... SDMMC
>> MMC Device 0: 14804 MB
>> MMC Device 1 not found
>> *** Warning - using default environment
>>
>> USB3503 NINT = OUTPUT LOW!
>> ModeKey Check... run normal_boot
>> No ethernet found.
>> Hit any key to stop autoboot:  0
>> Exynos4412 #
>> Exynos4412 #
>> Exynos4412 #
>> Exynos4412 # usb start
>> (Re)start USB...
>> USB0:   Exynos4412-ehci: init hccr 12580000 and hcor 12580010 hc_length 16
>> usb: usb_refclk_enable is active low: NO
>> ProTIP: If usb doesn't work - try playing with 'usb_invert_clken' environment
>> USB EHCI 1.00
>> scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
>> EHCI fail timeout STS_ASS set
>>
>>       USB device not accepting new address (error=80000000)
>> EHCI fail timeout STS_ASS set
>> 1 USB Device(s) found
>>        scanning usb for storage devices... 0 Storage Device(s) found
>>        scanning usb for ethernet devices... 0 Ethernet Device(s) found
>> Exynos4412 #
>>
>> Best Regards
>> -Anand

^ permalink raw reply

* Re: [PATCH 1/4] usb: musb: da8xx: Use the right dma controller
From: Sergei Shtylyov @ 2017-01-09 18:30 UTC (permalink / raw)
  To: Alexandre Bailon, b-liu-l0cyMroinI0
  Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
	khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
	tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	david-nq/r/kbU++upp/zk7JDF2g
In-Reply-To: <20170109163902.5268-2-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

Hello!

On 01/09/2017 07:38 PM, Alexandre Bailon wrote:

> da8xx driver is registering and using the cppi dma controller but actually,
> the da8xx has a cppi41 dma controller.
> Update the driver to register and use the cppi41 dma controller.
>
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
>  drivers/usb/musb/da8xx.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
> index e89708d..74dcc07 100644
> --- a/drivers/usb/musb/da8xx.c
> +++ b/drivers/usb/musb/da8xx.c
> @@ -458,14 +458,14 @@ static inline u8 get_vbus_power(struct device *dev)
>  }
>
>  static const struct musb_platform_ops da8xx_ops = {
> -	.quirks		= MUSB_DMA_CPPI | MUSB_INDEXED_EP,

    Grr, MUSB_DMA_CPPI is certainly wrong! There's no CPPI 3.0 support for 
DA8xx. Where have this come from?

> +	.quirks		= MUSB_DMA_CPPI41 | MUSB_INDEXED_EP,
>  	.init		= da8xx_musb_init,
>  	.exit		= da8xx_musb_exit,
>
>  	.fifo_mode	= 2,
> -#ifdef CONFIG_USB_TI_CPPI_DMA
> -	.dma_init	= cppi_dma_controller_create,
> -	.dma_exit	= cppi_dma_controller_destroy,

    Likewise, WTF?
    I suggest that you fix this crap in a separate commit, to be backported to 
-stable if needed.

[...]

MBR, Sergei

--
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/2] Documentation: devicetree: Add document bindings for mtk-cir
From: Rob Herring @ 2017-01-09 18:32 UTC (permalink / raw)
  To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
  Cc: mchehab-JPH+aEBZ4P+UEJcrhfAQsw, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
	hkallweit1-Re5JQEeQqe8AvxtiuMwx3w, mark.rutland-5wv7dgnIgG8,
	matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
	andi.shyti-Sze3O3UU22JBDgjK7y7TUQ,
	hverkuil-qWit8jRvyhVmR6Xm/wNWPw, sean-hENCXIMQXOg,
	ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
	linux-media-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	keyhaede-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1483632384-8107-2-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

On Fri, Jan 06, 2017 at 12:06:23AM +0800, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> 
> This patch adds documentation for devicetree bindings for
> Mediatek IR controller.
> 
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
>  .../devicetree/bindings/media/mtk-cir.txt          | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
>  create mode 100644 linux-4.8.rc1_p0/Documentation/devicetree/bindings/media/mtk-cir.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt b/Documentation/devicetree/bindings/media/mtk-cir.txt
> new file mode 100644
> index 0000000..bbedd71
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
> @@ -0,0 +1,23 @@
> +Device-Tree bindings for Mediatek IR controller found in Mediatek SoC family
> +
> +Required properties:
> +- compatible	    : "mediatek,mt7623-ir"
> +- clocks	    : list of clock specifiers, corresponding to
> +		      entries in clock-names property;
> +- clock-names	    : should contain "clk" entries;
> +- interrupts	    : should contain IR IRQ number;
> +- reg		    : should contain IO map address for IR.
> +
> +Optional properties:
> +- linux,rc-map-name : Remote control map name.

Would 'label' be appropriate here instead? If not, this needs to be 
documented in a common location and explained better.

> +
> +Example:
> +
> +cir: cir@0x10013000 {

Drop the '0x'.

> +	compatible = "mediatek,mt7623-ir";
> +	reg = <0 0x10013000 0 0x1000>;
> +	interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
> +	clocks = <&infracfg CLK_INFRA_IRRX>;
> +	clock-names = "clk";
> +	linux,rc-map-name = "rc-rc6-mce";
> +};
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 4/4] usb: musb: musb_cppi41: Workaround dma stall issue during teardown
From: Sergei Shtylyov @ 2017-01-09 18:34 UTC (permalink / raw)
  To: Alexandre Bailon, b-liu-l0cyMroinI0
  Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
	khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
	tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	david-nq/r/kbU++upp/zk7JDF2g
In-Reply-To: <20170109163902.5268-5-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

Hello!

On 01/09/2017 07:39 PM, Alexandre Bailon wrote:

> The dma may hung up if a teardown is initiated while an endpoint is still

    The DMA may hang up...

> active (Advisory 2.3.27 of da8xx errata).
> To workaround this issue, add a delay before to initiate the teardown.
>
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
[...]
> diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
> index 1636385..8fdbc17 100644
> --- a/drivers/usb/musb/musb_cppi41.c
> +++ b/drivers/usb/musb/musb_cppi41.c
> @@ -547,6 +547,10 @@ static int cppi41_dma_channel_abort(struct dma_channel *channel)
>  		}
>  	}
>
> +	/* DA8xx Advisory 2.3.27: wait 250 ms before to start the teardown */
> +	if (musb->io.quirks & MUSB_DA8XX)
> +		mdelay(250);

    This is a horrible workaround, not even msleep()...

[...]

MBR, Sergei

--
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 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
From: Krzysztof Kozlowski @ 2017-01-09 18:35 UTC (permalink / raw)
  To: Anand Moon
  Cc: Krzysztof Kozlowski, Kukjin Kim, Javier Martinez Canillas,
	devicetree, linux-arm-kernel, linux-samsung-soc@vger.kernel.org,
	Linux Kernel, Marek Szyprowski, Sylwester Nawrocki, Peter Chen,
	Greg Kroah-Hartman, Alan Stern, Ulf Hansson, Mark Brown, sre,
	Rob Herring, Linux USB Mailing List, Linux PM list
In-Reply-To: <CANAwSgR7=cELNK9of5ngFTdhcxWn2KXL=R8tMsTKD7gecBcMYw@mail.gmail.com>

On Mon, Jan 09, 2017 at 11:56:41PM +0530, Anand Moon wrote:
> Hi Krzysztof,
> 
> On 9 January 2017 at 23:47, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Mon, Jan 09, 2017 at 11:34:48PM +0530, Anand Moon wrote:
> >> Hi Krzysztof,
> >>
> >> On 7 January 2017 at 14:21, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> > Hi,
> >> >
> >> > Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter
> >> > Chen, we got a power sequence generic library which solves my long
> >> > standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader.
> >> >
> >> > My previous attempts for this can be found here [0].
> >> >
> >> > This patchset is based on Peter's v11 of power sequence [1].
> >> > Patchset is available also on my Github [2].
> >> >
> >> > More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix
> >> > LAN9730 on Odroid U3 after tftpboot").
> >> >
> >> >
> >>
> >> [snip]
> >>
> >> On which u-boot should this be tested.
> >>
> >> On HK u-boot tftp boot is not supported.
> >
> > ... so you gave an answer: you cannot test it on HK. How many other
> > U-Boot flavors you know? :)
> >
> 
> u-boot mainline have tftp support enable, so I will try to test on this u-boot.

Yes, please try it. Some time ago I was using v2016.03-rc3 and now
recent (~40 commits after v2017.01-rc2). Both are working fine however
the configuration (partitions, default env settings etc) differs from HK
so migration was not straightforward.

Best regards,
Krzysztof

^ permalink raw reply

* Re: [PATCHv3 1/5] clk: mvebu: support for 98DX3236 SoC
From: Rob Herring @ 2017-01-09 18:39 UTC (permalink / raw)
  To: Chris Packham
  Cc: linux-arm-kernel, Michael Turquette, Stephen Boyd, Mark Rutland,
	linux-clk, devicetree, linux-kernel
In-Reply-To: <20170106041517.9589-2-chris.packham@alliedtelesis.co.nz>

On Fri, Jan 06, 2017 at 05:14:58PM +1300, Chris Packham wrote:
> The 98DX3236, 98DX3336, 98DX4521 and variants have a different TCLK from
> the Armada XP (200MHz vs 250MHz). The CPU core clock is fixed at 800MHz.
> 
> The clock gating options are a subset of those on the Armada XP.
> 
> The core clock divider is different to the Armada XP also.
> 
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
>     Changes in v2:
>     - Update devicetree binding documentation for new compatible string
>     
>     Changes in v3:
>     - Add 98dx3236 support to mvebu/clk-corediv.c rather than creating a new
>       driver.
>     - Document mv98dx3236-corediv-clock binding
> 
>  .../bindings/clock/mvebu-corediv-clock.txt         |  1 +
>  .../devicetree/bindings/clock/mvebu-cpu-clock.txt  |  1 +

Acked-by: Rob Herring <robh@kernel.org>

>  drivers/clk/mvebu/armada-xp.c                      | 42 ++++++++++++++++++++++
>  drivers/clk/mvebu/clk-corediv.c                    | 23 ++++++++++++
>  drivers/clk/mvebu/clk-cpu.c                        | 31 ++++++++++++++--
>  5 files changed, 96 insertions(+), 2 deletions(-)

^ permalink raw reply

* Re: [PATCHv3 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Rob Herring @ 2017-01-09 18:40 UTC (permalink / raw)
  To: Chris Packham
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
	Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Russell King, Chris Brand, Florian Fainelli, Geert Uytterhoeven,
	Lorenzo Pieralisi, Jayachandran C, Juri Lelli, Magnus Damm,
	Stephen Boyd, Thierry Reding, Sudeep Holla,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170106041517.9589-3-chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>

On Fri, Jan 06, 2017 at 05:14:59PM +1300, Chris Packham wrote:
> Compared to the armada-xp the 98DX3336 uses different registers to set
> the boot address for the secondary CPU so a new enable-method is needed.
> This will only work if the machine definition doesn't define an overall
> smp_ops because there is not currently a way of overriding this from the
> device tree if it is set in the machine definition.
> 
> Signed-off-by: Chris Packham <chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
> ---
>     Changes in v2:
>     - Document new enable-method value
>     - Correct some references from 98DX4521 to 98DX3236
>     
>     Changes in v3:
>     - Simplify mv98dx3236_resume_init by using of_io_request_and_map()
> 
>  Documentation/devicetree/bindings/arm/cpus.txt     |  1 +
>  .../bindings/arm/marvell/98dx3236-resume-ctrl.txt  | 18 ++++++++

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

>  arch/arm/mach-mvebu/Makefile                       |  1 +
>  arch/arm/mach-mvebu/common.h                       |  1 +
>  arch/arm/mach-mvebu/platsmp.c                      | 43 ++++++++++++++++++
>  arch/arm/mach-mvebu/pmsu-98dx3236.c                | 52 ++++++++++++++++++++++
>  6 files changed, 116 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt
>  create mode 100644 arch/arm/mach-mvebu/pmsu-98dx3236.c
--
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 07/11] dt/bindings: da8xx-usb: Add binding for the cppi41 dma controller
From: Sergei Shtylyov @ 2017-01-09 18:41 UTC (permalink / raw)
  To: Alexandre Bailon, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
  Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
	khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
	tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	b-liu-l0cyMroinI0
In-Reply-To: <20170109160656.3470-8-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

Hello!

On 01/09/2017 07:06 PM, Alexandre Bailon wrote:

> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx cppi41 dma controller.

    It's called CPPI 4.1, not cppi41.
    Let me introduce myself: I was the author of the 1st CPPI 4.1 drivers 
(never merged).

> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
>  .../devicetree/bindings/usb/da8xx-usb.txt          | 39 ++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
> index ccb844a..2a4d737 100644
> --- a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
> @@ -18,10 +18,26 @@ Required properties:
[...]
>  Optional properties:
>  ~~~~~~~~~~~~~~~~~~~~
>   - vbus-supply: Phandle to a regulator providing the USB bus power.
>
> +DMA
> +~~~
> +- compatible: ti,da8xx-cppi41
> +- reg: offset and length of the following register spaces: USBSS, USB

    I don't understand what you mean by USBSS and how it's related to CPPI 4.1.

> +  CPPI DMA Controller, USB CPPI DMA Scheduler, USB Queue Manager

    I'd drop "USB" everywhere, the DMAC scheduler and queue manager are not a 
part of any USB logic.

> +- reg-names: glue, controller, scheduler, queuemgr

    Quoted, maybe?

> +- #dma-cells: should be set to 2. The first number represents the
> +  endpoint number (0 … 3 for endpoints 1 … 4).

    Not sure why you need EPs here. Is that required by the DMA driver?
The DMA controller operates with channels...

[...]

MBR, Sergei

--
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: [PATCHv3 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Rob Herring @ 2017-01-09 18:41 UTC (permalink / raw)
  To: Chris Packham
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Kalyan Kinthada, Linus Walleij, Mark Rutland, Thomas Petazzoni,
	Laxman Dewangan, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170106041517.9589-4-chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>

On Fri, Jan 06, 2017 at 05:15:00PM +1300, 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>
> ---
>     Changes in v2:
>     - include sdio support for the 98DX4251
>     Changes in v3:
>     - None
> 
>  .../pinctrl/marvell,armada-98dx3236-pinctrl.txt    |  46 ++++++

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

>  drivers/pinctrl/mvebu/pinctrl-armada-xp.c          | 155 +++++++++++++++++++++
>  2 files changed, 201 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
--
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/2] pinctrl: core: Make dt_free_map optional
From: Linus Walleij @ 2017-01-09 18:41 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Gary Bisson, Grygorii Strashko, Mark Rutland, Nishanth Menon,
	Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <20161230183732.5595-2-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

On Fri, Dec 30, 2016 at 7:37 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:

> If the pin controller driver is using devm_kzalloc, there may not be
> anything to do for dt_free_map. Let's make it optional to avoid
> unncessary boilerplate code.
>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

Patch applied.

Yours,
Linus Walleij
--
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/4] usb: musb: da8xx: Use the right dma controller
From: Tony Lindgren @ 2017-01-09 18:43 UTC (permalink / raw)
  To: Sergei Shtylyov
  Cc: Alexandre Bailon, b-liu-l0cyMroinI0,
	vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
	dmaengine-u79uwXL29TY76Z2rM5mHXA,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
	khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	david-nq/r/kbU++upp/zk7JDF2g
In-Reply-To: <7dcfe848-a421-d409-0e9a-659c095e4e31-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>

* Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> [170109 10:30]:
> Hello!
> 
> On 01/09/2017 07:38 PM, Alexandre Bailon wrote:
> 
> > da8xx driver is registering and using the cppi dma controller but actually,
> > the da8xx has a cppi41 dma controller.
> > Update the driver to register and use the cppi41 dma controller.
> > 
> > Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> > ---
> >  drivers/usb/musb/da8xx.c | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
> > index e89708d..74dcc07 100644
> > --- a/drivers/usb/musb/da8xx.c
> > +++ b/drivers/usb/musb/da8xx.c
> > @@ -458,14 +458,14 @@ static inline u8 get_vbus_power(struct device *dev)
> >  }
> > 
> >  static const struct musb_platform_ops da8xx_ops = {
> > -	.quirks		= MUSB_DMA_CPPI | MUSB_INDEXED_EP,
> 
>    Grr, MUSB_DMA_CPPI is certainly wrong! There's no CPPI 3.0 support for
> DA8xx. Where have this come from?
> 
> > +	.quirks		= MUSB_DMA_CPPI41 | MUSB_INDEXED_EP,
> >  	.init		= da8xx_musb_init,
> >  	.exit		= da8xx_musb_exit,
> > 
> >  	.fifo_mode	= 2,
> > -#ifdef CONFIG_USB_TI_CPPI_DMA
> > -	.dma_init	= cppi_dma_controller_create,
> > -	.dma_exit	= cppi_dma_controller_destroy,
> 
>    Likewise, WTF?
>    I suggest that you fix this crap in a separate commit, to be backported
> to -stable if needed.

Probably came from my DMA patch 7f6283ed6fe8 ("usb: musb: Set up function
pointers for DMA"). At that point I thought da8xxx.c and davinci.c are just
separate attempts of the same driver.. Sorry the number of musb glue layers
is just too confusing.

Tony
--
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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox