* Re: [PATCH 2/2] pinctrl: Introduce TI IOdelay configuration driver
From: Linus Walleij @ 2017-01-09 18:46 UTC (permalink / raw)
To: Tony Lindgren
Cc: Gary Bisson, Grygorii Strashko, Mark Rutland, Nishanth Menon,
Rob Herring, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, Linux-OMAP, Lokesh Vutla
In-Reply-To: <20170105185414.27247-3-tony@atomide.com>
On Thu, Jan 5, 2017 at 7:54 PM, Tony Lindgren <tony@atomide.com> wrote:
> From: Nishanth Menon <nm@ti.com>
>
> SoC family such as DRA7 family of processors have, in addition
> to the regular muxing of pins (as done by pinctrl-single), a separate
> hardware module called IODelay which is also expected to be configured.
> The "IODelay" module has it's own register space that is independent
> of the control module and the padconf register area.
>
> With recent changes to the pinctrl framework, we can now support
> this hardware with a reasonably minimal driver by using #pinctrl-cells,
> GENERIC_PINCTRL_GROUPS and GENERIC_PINMUX_FUNCTIONS.
>
> It is advocated strongly in TI's official documentation considering
> the existing design of the DRA7 family of processors during mux or
> IODelay reconfiguration, there is a potential for a significant glitch
> which may cause functional impairment to certain hardware. It is
> hence recommended to do as little of muxing as absolutely necessary
> without I/O isolation (which can only be done in initial stages of
> bootloader).
>
> NOTE: with the system wide I/O isolation scheme present in DRA7 SoC
> family, it is not reasonable to do stop all I/O operations for every
> such pad configuration scheme. So, we will let it glitch when used in
> this mode.
>
> Even with the above limitation, certain functionality such as MMC has
> mandatory need for IODelay reconfiguration requirements, depending on
> speed of transfer. In these cases, with careful examination of usecase
> involved, the expected glitch can be controlled such that it does not
> impact functionality.
>
> In short, IODelay module support as a padconf driver being introduced
> here is not expected to do SoC wide I/O Isolation and is meant for
> a limited subset of IODelay configuration requirements that need to
> be dynamic and whose glitchy behavior will not cause functionality
> failure for that interface.
>
> IMPORTANT NOTE: we take the approach of keeping LOCK_BITs cleared
> to 0x0 at all times, even when configuring Manual IO Timing Modes.
> This is done by eliminating the LOCK_BIT=1 setting from Step
> of the Manual IO timing Mode configuration procedure. This option
> leaves the CFG_* registers unprotected from unintended writes to the
> CTRL_CORE_PAD_* registers while Manual IO Timing Modes are configured.
>
> This approach is taken to allow for a generic driver to exist in kernel
> world that has to be used carefully in required usecases.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> [tony@atomide.com: updated to use generic pinctrl functions, added
> binding documentation, updated comments]
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Oh what a hardware mess. But very nicely isolated now.
Patch applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Matthias Brugger @ 2017-01-09 18:45 UTC (permalink / raw)
To: Hans Verkuil, Rick Chang
Cc: Hans Verkuil, Laurent Pinchart, Mauro Carvalho Chehab,
Rob Herring, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Minghsiu Tsai, James Liao
In-Reply-To: <974d20f3-5133-0869-2a35-c1617bec5d6e-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
On 09/01/17 12:29, Hans Verkuil wrote:
> Hi Rick,
>
> On 01/06/2017 03:34 AM, Rick Chang wrote:
>> Hi Hans,
>>
>> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have
>> any idea about this patch series? Should we wait for [2] or we could merge
>> the source code and dt-binding first?
>
> Looking at [2] I noticed that the last comment was July 4th. What is the reason
> it hasn't been merged yet?
>
> If I know [2] will be merged for 4.11, then I am fine with merging this media
> patch series. The dependency of this patch on [2] is something Mauro can handle.
>
> If [2] is not merged for 4.11, then I think it is better to wait until it is
> merged.
>
I can't take [2] because there is no scpsys in the dts present. It seems
that it got never posted.
Rick can you please follow-up with James and provide a patch which adds
a scpsys node to the mt2701.dtsi?
Thanks,
Matthias
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] doc: binding: add new compatible for SDRAM/DDR Controller
From: Rob Herring @ 2017-01-09 18:45 UTC (permalink / raw)
To: Wenyou Yang
Cc: Alexandre Belloni, Russell King, Nicolas Ferre, Mark Rutland,
linux-kernel, Wenyou Yang, devicetree, linux-arm-kernel
In-Reply-To: <20170106065947.30631-3-wenyou.yang@atmel.com>
On Fri, Jan 06, 2017 at 02:59:46PM +0800, Wenyou Yang wrote:
> Add the new compatible "atmel,sama5d4-ddramc" for the SDRAM/DDR
> Controller.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
>
> Documentation/devicetree/bindings/arm/atmel-at91.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCHv3 4/5] arm: mvebu: Add device tree for 98DX3236 SoCs
From: Rob Herring @ 2017-01-09 18:44 UTC (permalink / raw)
To: Chris Packham
Cc: linux-arm-kernel, Mark Rutland, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Russell King, devicetree,
linux-kernel, netdev
In-Reply-To: <20170106041517.9589-5-chris.packham@alliedtelesis.co.nz>
On Fri, Jan 06, 2017 at 05:15:01PM +1300, Chris Packham wrote:
> The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
> with integrated CPUs. They are similar to the Armada XP SoCs but have
> different I/O interfaces.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> Changes in v2:
> - Update devicetree binding documentation to reflect that 98DX3336 and
> 984251 are supersets of 98DX3236.
> - disable crypto block
> - disable sdio for 98DX3236, enable for 98DX4251
> Changes in v3:
> - fix typo 4521 -> 4251
> - document prestera bindings
> - rework corediv-clock binding
> - add label to packet processor node
> - add new compativle string for DFX server
>
> .../devicetree/bindings/arm/marvell/98dx3236.txt | 23 ++
> .../devicetree/bindings/net/marvell,prestera.txt | 50 ++++
> arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 254 +++++++++++++++++++++
> arch/arm/boot/dts/armada-xp-98dx3336.dtsi | 76 ++++++
> arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 90 ++++++++
> 5 files changed, 493 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
> create mode 100644 Documentation/devicetree/bindings/net/marvell,prestera.txt
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx3336.dtsi
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx4251.dtsi
Acked-by: Rob Herring <robh@kernel.org>
^ 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
* 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: [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 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 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: [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: [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: [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 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 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 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/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] [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 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] 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 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 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 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 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 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 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
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