Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Rob Herring @ 2018-05-31 14:20 UTC (permalink / raw)
  To: Codrin Ciubotariu
  Cc: devicetree, Linux-ALSA, Alexandre Belloni, Nicolas Ferre,
	linux-kernel@vger.kernel.org, Boris Brezillon, Mark Brown,
	Cristian.Birsan, linux-clk,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <4f2e6e6a-df3a-b645-093c-b4467b3aa843@microchip.com>

On Thu, May 31, 2018 at 5:25 AM, Codrin Ciubotariu
<codrin.ciubotariu@microchip.com> wrote:
> On 31.05.2018 03:58, Rob Herring wrote:
>>
>> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
>>>
>>> The I2S mux clock can be used to select the I2S input clock. The
>>> available parents are the peripheral and the generated clocks.
>>>
>>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
>>> ---
>>>   .../devicetree/bindings/clock/at91-clock.txt       | 34
>>> ++++++++++++++++++++++
>>>   1 file changed, 34 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> b/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> index 51c259a..1c46b3c 100644
>>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> @@ -90,6 +90,8 @@ Required properties:
>>>         "atmel,sama5d2-clk-audio-pll-pmc"
>>>                 at91 audio pll output on AUDIOPLLCLK that feeds the PMC
>>>                 and can be used by peripheral clock or generic clock
>>> +       "atmel,sama5d2-clk-i2s-mux":
>>> +               at91 I2S clock source selection
>>
>>
>> Is this boolean or takes some values. If latter, what are valid values?
>
>
> This is the compatible string of the clock driver.

Ah, now I remember. AT91 uses fine grained clock nodes in DT. Is there
still a plan to fix this?

>>>     Required properties for SCKC node:
>>>   - reg : defines the IO memory reserved for the SCKC.
>>> @@ -507,3 +509,35 @@ For example:
>>>                         atmel,clk-output-range = <0 83000000>;
>>>                 };
>>>         };
>>> +
>>> +Required properties for I2S mux clocks:
>>> +- #size-cells : shall be 0 (reg is used to encode I2S bus id).
>>> +- #address-cells : shall be 1 (reg is used to encode I2S bus id).
>>> +- name: device tree node describing a specific mux clock.
>>> +       * #clock-cells : from common clock binding; shall be set to 0.
>>> +       * clocks : shall be the mux clock parent phandles; shall be 2
>>> phandles:
>>> +         peripheral and generated clock; the first phandle shall belong
>>> to the
>>> +         peripheral clock and the second one shall belong to the
>>> generated
>>> +         clock; "clock-indices" property can be user to specify
>>> +         the correct order.
>>> +       * reg: I2S bus id of the corresponding mux clock.
>>> +         e.g. reg = <0>; for i2s0, reg = <1>; for i2s1
>>> +
>>> +For example:
>>> +       i2s_clkmux {
>>
>>
>> What is this a child of?
>
>
> It is a child of PMC node, since both parent clocks are generated by PMC.
>
>>
>>> +               compatible = "atmel,sama5d2-clk-i2s-mux";
>>> +               #address-cells = <1>;
>>> +               #size-cells = <0>;
>>
>>
>> How do you address this block? My guess is you don't because it is just
>> part of some other block and you are just creating this node to
>> instantiate a driver. Just make the node for the actual h/w block a
>> clock provider and define the clock ids (0 and 1).
>
>
> This block is not addressed, but its children are. The register we access in
> this driver is not part of other block. It's a SFR register, accessed
> through syscon and it has nothing to do with the I2S IP (see SAMA5D2 DS,
> page 1256, fig. 44-1: I2SC Block Diagram) that is the consumer of this
> clock. Adding a clock-id property in the I2S node would be just like v3 of
> this series, with the difference that we use clock-id instead of alias id to
> set the clock parent, which is not how you suggested back then.

I wasn't suggesting a clock-id property, but a clock specifier (i.e.
make #clock-cells 1).

But AT91 clocks are all a mess, so I don't know what to tell you.

Rob

^ permalink raw reply

* Re: [PATCH v7 3/7] drivers/i2c: Add port structure to FSI algorithm
From: Eddie James @ 2018-05-31 14:18 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Andy Shevchenko
  Cc: linux-i2c, Linux Kernel Mailing List, devicetree, Wolfram Sang,
	Rob Herring, Joel Stanley, Mark Rutland, Greg Kroah-Hartman,
	Edward A. James
In-Reply-To: <8aaa7fa9874bf140354964535ce5cf023012c3f4.camel@kernel.crashing.org>



On 05/30/2018 04:16 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2018-05-30 at 10:47 -0500, Eddie James wrote:
>>>> +       if (!list_empty(&i2c->ports)) {
>>> My gosh, this is done already in list_for_each*()
>> No, list_for_each_entry does NOT check if the list is empty or if the
>> first entry is NULL.
> NULL is never valid for a list. It does however check for an empty list
>
> It does it implicitely in the test part of the for () statement,
> checking if the next pointer points back to the head.

Thanks Ben. My mistake on this one; I misread the macro. I will remove 
the check in v9... going to wait a little for any further comments now.

Thanks,
Eddie

>
> Cheers,
> Ben.
>
>

^ permalink raw reply

* Re: [PATCH 00/12] introduce support for early platform drivers
From: Tony Lindgren @ 2018-05-31 14:16 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Rob Herring, Mark Rutland, Rich Felker, Michael Turquette,
	Sekhar Nori, Frank Rowand,
	open list:GENERIC INCLUDE/ASM HEADER FILES, Yoshinori Sato,
	Kevin Hilman, Bartosz Golaszewski, Rafael J . Wysocki,
	Magnus Damm, Andy Shevchenko, Jiri Slaby, devicetree,
	David Lechner, Arnd Bergmann, Marc Zyngier, Johan Hovold
In-Reply-To: <CAMuHMdUY+-_72DHg9Tim2d4E24k5KskQxm52bHSyrSYLbZDr2g@mail.gmail.com>

* Geert Uytterhoeven <geert@linux-m68k.org> [180531 06:45]:
> Yes, they should all be drivers.
> 
> Assuming clocksources, clockevents, or primary interrupt controllers are
> special, and thus forcing everyone to use OF_DECLARE for the whole
> subsystem, doesn't fly everywhere.
> 
> Clockevents and interrupt controllers can have a module clock.
> All three can be part of a PM Domain, which requires a struct device to
> be handled properly.

I agree it sure would be nice to have all these as drivers. I believe
SoC specific clockevent using SoC specific clocks is the reason why some
clocks cannot currently be drivers.

Regards,

Tony

^ permalink raw reply

* Re: [PATCH v4 2/6] mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Rob Herring @ 2018-05-31 14:07 UTC (permalink / raw)
  To: Matti Vaittinen
  Cc: Matti Vaittinen, Michael Turquette, Stephen Boyd, Mark Rutland,
	Lee Jones, Liam Girdwood, Mark Brown, linux-clk, devicetree,
	linux-kernel@vger.kernel.org, mikko.mutanen, heikki.haikola
In-Reply-To: <20180531102315.GA5150@localhost.localdomain>

On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen
<mazziesaccount@gmail.com> wrote:
> On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote:
>> Hello Rob,
>>
>> Thanks for the review!
>>
>> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote:
>> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote:
>> > > Document devicetree bindings for ROHM BD71837 PMIC MFD.
>> > > + - interrupts            : The interrupt line the device is connected to.
>> > > + - interrupt-controller  : Marks the device node as an interrupt controller.
>> >
>> > What sub blocks have interrupts?
>>
>> The PMIC can generate interrupts from events which cause it to reset.
>> Eg, irq from watchdog line change, power button pushes, reset request
>> via register interface etc. I don't know any generic handling for these
>> interrupts. In "normal" use-case this PMIC is powering the processor
>> where driver is running and I do not see reasonable handling because
>> power-reset is going to follow the irq.
>>
>
> Oh, but when reading this I understand that the interrupt-controller
> property should at least be optional.

I don't think it should. The h/w either has an interrupt controller or
it doesn't. My concern is you added it but nothing uses it which tells
me your binding is incomplete. I'd rather see complete bindings even
if you don't have drivers. For example, as-is, there's not really any
need for the clocks child node. You can just make the parent a clock
provider. But we need a complete picture of the h/w to make that
determination.

Rob

^ permalink raw reply

* Re: [PATCH v4 3/6] regulator: bd71837: Devicetree bindings for BD71837 regulators
From: Rob Herring @ 2018-05-31 14:00 UTC (permalink / raw)
  To: Matti Vaittinen
  Cc: Matti Vaittinen, Michael Turquette, Stephen Boyd, Mark Rutland,
	Lee Jones, Liam Girdwood, Mark Brown, linux-clk, devicetree,
	linux-kernel@vger.kernel.org, mikko.mutanen, heikki.haikola
In-Reply-To: <20180531072145.GH13528@localhost.localdomain>

On Thu, May 31, 2018 at 2:21 AM, Matti Vaittinen
<mazziesaccount@gmail.com> wrote:
> On Wed, May 30, 2018 at 10:04:36PM -0500, Rob Herring wrote:
>> On Wed, May 30, 2018 at 11:42:32AM +0300, Matti Vaittinen wrote:
>> > Document devicetree bindings for ROHM BD71837 PMIC regulators.
>> > +ROHM BD71837 Power Management Integrated Circuit (PMIC) regulator bindings
>> > +
>> > +BD71837MWV is a programmable Power Management
>> > +IC (PMIC) for powering single-core, dual-core, and
>> > +quad-core SoC’s such as NXP-i.MX 8M. It is optimized
>> > +for low BOM cost and compact solution footprint. It
>> > +integrates 8 Buck regulators and 7 LDO’s to provide all
>> > +the power rails required by the SoC and the commonly
>> > +used peripherals.
>>
>> Why duplicate this from the core binding?
>
> I can remove this. I just thought it is nice to see what this chip is
> doing even without opening the MFD binding doc. Just same question as in
> the other patch - how should I deliver the change? This was already
> applied to Mark's tree - should I do new patch on top of the Mark's tree
> - or do patch against tree which does not yet contain this change? If I
>   do it on top of Mark's tree then Mark should apply it, right? If I do
>  it against some other three, thene there will be merge conflict with
>  Mark, right?

I thought he only applied the regulator driver part. If not, then
don't worry about it. (But the right answer would be to do an
incremental patch on top of his tree).

Rob

^ permalink raw reply

* Re: [PATCH v2 4/8] dt-bindings: gnss: add u-blox binding
From: Rob Herring @ 2018-05-31 13:55 UTC (permalink / raw)
  To: Johan Hovold
  Cc: Greg Kroah-Hartman, Mark Rutland, Andreas Kemnade, Arnd Bergmann,
	H . Nikolaus Schaller, Pavel Machek, Marcel Holtmann,
	Sebastian Reichel, Tony Lindgren, linux-kernel@vger.kernel.org,
	devicetree
In-Reply-To: <20180531082241.GD3259@localhost>

On Thu, May 31, 2018 at 3:22 AM, Johan Hovold <johan@kernel.org> wrote:
> On Wed, May 30, 2018 at 10:58:05PM -0500, Rob Herring wrote:
>> On Wed, May 30, 2018 at 12:32:38PM +0200, Johan Hovold wrote:
>> > Add binding for u-blox GNSS receivers.
>> >
>> > Note that the u-blox product names encodes form factor (e.g. "neo"),
>> > chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and
>> > chipset is used for the compatible strings (for now).
>> >
>> > Signed-off-by: Johan Hovold <johan@kernel.org>
>> > ---
>> >  .../devicetree/bindings/gnss/u-blox.txt       | 44 +++++++++++++++++++
>> >  .../devicetree/bindings/vendor-prefixes.txt   |  1 +
>> >  2 files changed, 45 insertions(+)
>> >  create mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/gnss/u-blox.txt b/Documentation/devicetree/bindings/gnss/u-blox.txt
>> > new file mode 100644
>> > index 000000000000..caef9ace0b0c
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/gnss/u-blox.txt
>> > @@ -0,0 +1,44 @@
>> > +u-blox GNSS Receiver DT binding
>> > +
>> > +The u-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
>> > +
>> > +Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic
>> > +properties.
>> > +
>> > +Required properties:
>> > +
>> > +- compatible       : Must be one of
>>
>> mixture of space and tab here.
>
> Oops. Same single space character before the tab here in all three
> binding docs (and in the in-tree slave_devices.txt which I think I used
> as a template).

Who wrote that crap? ;)

> Do you want me to fix this even if this turns out to be the only thing
> that needs to be addressed in a v3?

No

>
>> > +
>> > +                   "u-blox,neo-8"
>> > +                   "u-blox,neo-m8"
>> > +
>> > +- vcc-supply       : Main voltage regulator
>> > +
>> > +Required properties (DDC):
>> > +- reg              : DDC (I2C) slave address
>> > +
>> > +Required properties (SPI):
>> > +- reg              : SPI chip select address
>> > +
>> > +Required properties (USB):
>> > +- reg              : Number of the USB hub port or the USB host-controller port
>> > +                  to which this device is attached
>> > +
>> > +Optional properties:
>> > +
>> > +- timepulse-gpios  : Time pulse GPIO
>> > +- u-blox,extint-gpios      : External interrupt GPIO
>>
>> This should be interrupts property instead of a gpio.
>
> Contrary to what the name may suggest, this pin is actually an input
> which can be used to control active power or to provide time or
> frequency aiding data to the receiver (see section 1.13 in [1]).
>
> I only added it for completeness as the driver does not use it
> currently. Remove, leave as is, or add "input" to the description as in:
>
>         - u-blox,extint-gpios   : External interrupt input GPIO

Yes. You should also define the active level.

Rob

^ permalink raw reply

* Re: [PATCH v2 4/6] bus: ti-sysc: Add support for using ti-sysc for MCAN on dra76x
From: Tony Lindgren @ 2018-05-31 13:50 UTC (permalink / raw)
  To: Faiz Abbas
  Cc: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk,
	robh+dt, bcousson, paul, t-kristo
In-Reply-To: <0b627ab6-59f1-4a4f-42d2-5d6846adfe0b@ti.com>

* Faiz Abbas <faiz_abbas@ti.com> [180531 10:17]:
> Hi,
> 
> On Wednesday 30 May 2018 08:27 PM, Tony Lindgren wrote:
> > * Faiz Abbas <faiz_abbas@ti.com> [180530 14:12]:
> >> The dra76x MCAN generic interconnect module has a its own
> >> format for the bits in the control registers.
> ...
> >>  static int sysc_init_pdata(struct sysc *ddata)
> >>  {
> >>  	struct ti_sysc_platform_data *pdata = dev_get_platdata(ddata->dev);
> >> @@ -1441,6 +1457,7 @@ static const struct of_device_id sysc_match[] = {
> >>  	{ .compatible = "ti,sysc-mcasp", .data = &sysc_omap4_mcasp, },
> >>  	{ .compatible = "ti,sysc-usb-host-fs",
> >>  	  .data = &sysc_omap4_usb_host_fs, },
> >> +	{ .compatible = "ti,sysc-dra7-mcan", .data = &sysc_dra7_mcan, },
> >>  	{  },
> >>  };
> > 
> > Looks good to me. And presumably you checked that no other dra7 modules
> > use sysconfig register bit layout like this?
> > 
> 
> As far as I could see, Yes.

OK thanks for checking it.

Regards,

Tony

^ permalink raw reply

* Re: [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Tony Lindgren @ 2018-05-31 13:45 UTC (permalink / raw)
  To: Faiz Abbas
  Cc: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk,
	robh+dt, bcousson, paul, t-kristo
In-Reply-To: <2361da91-659d-1aaa-0ab8-d1473bc3a71a@ti.com>

* Faiz Abbas <faiz_abbas@ti.com> [180531 10:22]:
> On Wednesday 30 May 2018 08:34 PM, Tony Lindgren wrote:
> > Looks good to me except I think the reset won't do anything currently
> > with ti-sysc.c unless you specfify also "ti,hwmods" for the module?
> > 
> > Can you please check? It might be worth adding the reset function to
> > ti-sysc.c for non "ti,hwmods" case and that just might remove the
> > need for any hwmod code for this module.
> > 
> 
> If I understand correctly, this involves adding a (*reset_module) in
> ti_sysc_platform_data and defining a ti_sysc_reset_module() in ti-sysc.c
> similar to ti_sysc_idle_module(). Right?

Well try moving "ti,hwmods" to the module level first. Then reset will
happen with enable.

Then for simple cases we can add reset directly to ti-sysc.c without
pdata callbacks and and drop "ti,hwmods". For more complex cases we
need to use reset-simple for the RSTCTRL registers.

Regards,

Tony

^ permalink raw reply

* Re: [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Tony Lindgren @ 2018-05-31 13:41 UTC (permalink / raw)
  To: Faiz Abbas
  Cc: Rob Herring, linux-kernel, devicetree, linux-omap,
	linux-arm-kernel, linux-clk, bcousson, paul, t-kristo
In-Reply-To: <be0fd711-c44b-dbe2-648f-08aa88c7aec4@ti.com>

* Faiz Abbas <faiz_abbas@ti.com> [180531 11:27]:
> On Thursday 31 May 2018 09:36 AM, Rob Herring wrote:
> > On Wed, May 30, 2018 at 07:41:32PM +0530, Faiz Abbas wrote:
> >> --- a/arch/arm/boot/dts/dra76x.dtsi
> >> +++ b/arch/arm/boot/dts/dra76x.dtsi
> >> @@ -11,6 +11,25 @@
> >>  / {
> >>  	compatible = "ti,dra762", "ti,dra7";
> >>  
> >> +	ocp {
> >> +
> >> +		target-module@0x42c00000 {
> > 
> > Build your dtb with W=1 and fix warnings you add (drop '0x').
> 
> Sure, Will fix this.
> > 
> > This is a CAN bus controller? If so, then use 'can' for node name.
> 
> Yes but I am using m_can along the lines of dcan in other boards (For
> example, see arch/arm/boot/dts/am33xx.dtsi:1046). Are you saying all CAN
> controllers should only be called can?

The module should be target-module@42c00000 and the child(ren)
can@1a00 or mcan@1a00 if mcan is different from can.

Regards,

Tony

^ permalink raw reply

* [PATCH v2 3/3] MAINTAINERS: add subfolders for nuvoton *npcm*
From: avifishman70 @ 2018-05-31 13:40 UTC (permalink / raw)
  To: gregkh, stern
  Cc: avifishman70, tmaimon77, venture, yuenn, brendanhiggins,
	mathias.nyman, bjorn.andersson, jhogan, albeu, chunfeng.yun, tony,
	baolu.lu, elder, digetx, kstewart, hdegoede, linux-kernel,
	linux-usb, openbmc, robh+dt, mark.rutland, devicetree,
	Avi Fishman
In-Reply-To: <1527774046-7952-1-git-send-email-avifishman70@gmail.com>

From: Avi Fishman <AviFishman70@gmail.com>

Signed-off-by: Avi Fishman <AviFishman70@gmail.com>
---
 MAINTAINERS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e0ce3c5f32e5..23c450adad44 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1727,7 +1727,10 @@ F:	arch/arm/mach-npcm/
 F:	arch/arm/boot/dts/nuvoton-npcm*
 F:	include/dt-bindings/clock/nuvoton,npcm7xx-clks.h
 F:	drivers/*/*npcm*
+F:	drivers/*/*/*npcm*
 F:	Documentation/*/*npcm*
+F:	Documentation/*/*/*npcm*
+F:	Documentation/*/*/*/*npcm*
 
 ARM/NUVOTON W90X900 ARM ARCHITECTURE
 M:	Wan ZongShun <mcuos.com@gmail.com>
-- 
2.14.1

^ permalink raw reply related

* [PATCH v2 2/3] USB: DT probing support to ehci-npcm7xx
From: avifishman70 @ 2018-05-31 13:40 UTC (permalink / raw)
  To: gregkh, stern
  Cc: avifishman70, tmaimon77, venture, yuenn, brendanhiggins,
	mathias.nyman, bjorn.andersson, jhogan, albeu, chunfeng.yun, tony,
	baolu.lu, elder, digetx, kstewart, hdegoede, linux-kernel,
	linux-usb, openbmc, robh+dt, mark.rutland, devicetree,
	Avi Fishman
In-Reply-To: <1527774046-7952-1-git-send-email-avifishman70@gmail.com>

From: Avi Fishman <AviFishman70@gmail.com>

Device Tree documentation for Nuvoton npcm7xx EHCI.

Signed-off-by: Avi Fishman <AviFishman70@gmail.com>
---
 Documentation/devicetree/bindings/usb/npcm7xx-usb.txt | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/npcm7xx-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt b/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
new file mode 100644
index 000000000000..dec67d4d4c30
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
@@ -0,0 +1,17 @@
+Nuvoton NPCM7XX SoC USB controllers:
+-----------------------------
+
+EHCI:
+-----
+
+Required properties:
+- compatible: "nuvoton,npcm750-ehci"
+- interrupts: Should contain the EHCI interrupt
+
+Example:
+
+	ehci@e1800000 {
+		compatible = "nuvoton,npcm750-ehci";
+		reg = <0xf0806000 0x1000>;
+		interrupts = <0 61 4>;
+	};
-- 
2.14.1

^ permalink raw reply related

* [PATCH v2 1/3] USB host: Add USB ehci support for nuvoton npcm7xx platform
From: avifishman70 @ 2018-05-31 13:40 UTC (permalink / raw)
  To: gregkh, stern
  Cc: avifishman70, tmaimon77, venture, yuenn, brendanhiggins,
	mathias.nyman, bjorn.andersson, jhogan, albeu, chunfeng.yun, tony,
	baolu.lu, elder, digetx, kstewart, hdegoede, linux-kernel,
	linux-usb, openbmc, robh+dt, mark.rutland, devicetree,
	Avi Fishman
In-Reply-To: <1527774046-7952-1-git-send-email-avifishman70@gmail.com>

From: Avi Fishman <AviFishman70@gmail.com>

This patch adds support for ehci controller for the Nuvoton
npcm7xx platform.
Most of the code was taken from ehci-spear.c + specific initialization
code

Signed-off-by: Avi Fishman <AviFishman70@gmail.com>
---
 drivers/usb/host/Kconfig        |   8 ++
 drivers/usb/host/Makefile       |   1 +
 drivers/usb/host/ehci-npcm7xx.c | 212 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 221 insertions(+)
 create mode 100644 drivers/usb/host/ehci-npcm7xx.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 9f0aeb068acb..e3100b249f0f 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -185,6 +185,14 @@ config USB_EHCI_MXC
 	---help---
 	  Variation of ARC USB block used in some Freescale chips.
 
+config USB_EHCI_HCD_NPCM7XX
+	tristate "Support for Nuvoton NPCM7XX on-chip EHCI USB controller"
+	depends on (USB_EHCI_HCD && ARCH_NPCM7XX) || COMPILE_TEST
+	default y
+	help
+	  Enables support for the on-chip EHCI controller on
+	  Nuvoton NPCM7XX chips.
+
 config USB_EHCI_HCD_OMAP
 	tristate "EHCI support for OMAP3 and later chips"
 	depends on ARCH_OMAP
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 8a8cffe0b445..fcf5dab5efa4 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_USB_EHCI_HCD)	+= ehci-hcd.o
 obj-$(CONFIG_USB_EHCI_PCI)	+= ehci-pci.o
 obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)	+= ehci-platform.o
 obj-$(CONFIG_USB_EHCI_MXC)	+= ehci-mxc.o
+obj-$(CONFIG_USB_EHCI_HCD_NPCM7XX)	+= ehci-npcm7xx.o
 obj-$(CONFIG_USB_EHCI_HCD_OMAP)	+= ehci-omap.o
 obj-$(CONFIG_USB_EHCI_HCD_ORION)	+= ehci-orion.o
 obj-$(CONFIG_USB_EHCI_HCD_SPEAR)	+= ehci-spear.o
diff --git a/drivers/usb/host/ehci-npcm7xx.c b/drivers/usb/host/ehci-npcm7xx.c
new file mode 100644
index 000000000000..c80a8792d3b0
--- /dev/null
+++ b/drivers/usb/host/ehci-npcm7xx.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Nuvoton NPCM7xx driver for EHCI HCD
+ *
+ * Copyright (C) 2018 Nuvoton Technologies,
+ * Avi Fishman <avi.fishman@nuvoton.com> <avifishman70@gmail.com>
+ * Tomer Maimon <tomer.maimon@nuvoton.com> <tmaimon77@gmail.com>
+ *
+ * Based on various ehci-spear.c driver
+ */
+
+
+#include <linux/dma-mapping.h>
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+#include "ehci.h"
+
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+
+#define DRIVER_DESC "EHCI npcm7xx driver"
+
+static const char hcd_name[] = "npcm7xx-ehci";
+
+#define  USB2PHYCTL_OFFSET 0x144
+
+#define  IPSRST2_OFFSET 0x24
+#define  IPSRST3_OFFSET 0x34
+
+
+static struct hc_driver __read_mostly ehci_npcm7xx_hc_driver;
+
+#ifdef CONFIG_PM_SLEEP
+static int ehci_npcm7xx_drv_suspend(struct device *dev)
+{
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
+	bool do_wakeup = device_may_wakeup(dev);
+
+	return ehci_suspend(hcd, do_wakeup);
+}
+
+static int ehci_npcm7xx_drv_resume(struct device *dev)
+{
+	struct usb_hcd *hcd = dev_get_drvdata(dev);
+
+	ehci_resume(hcd, false);
+	return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static SIMPLE_DEV_PM_OPS(ehci_npcm7xx_pm_ops, ehci_npcm7xx_drv_suspend,
+		ehci_npcm7xx_drv_resume);
+
+static int npcm7xx_ehci_hcd_drv_probe(struct platform_device *pdev)
+{
+	struct usb_hcd *hcd;
+	struct resource *res;
+	struct regmap *gcr_regmap;
+	struct regmap *rst_regmap;
+	const struct hc_driver *driver = &ehci_npcm7xx_hc_driver;
+	int irq;
+	int retval;
+
+	dev_dbg(&pdev->dev,	"initializing npcm7xx ehci USB Controller\n");
+
+	gcr_regmap = syscon_regmap_lookup_by_compatible("nuvoton,npcm750-gcr");
+	if (IS_ERR(gcr_regmap)) {
+		dev_err(&pdev->dev, "%s: failed to find nuvoton,npcm750-gcr\n",
+			__func__);
+		return IS_ERR(gcr_regmap);
+	}
+
+	rst_regmap = syscon_regmap_lookup_by_compatible("nuvoton,npcm750-rst");
+	if (IS_ERR(rst_regmap)) {
+		dev_err(&pdev->dev, "%s: failed to find nuvoton,npcm750-rst\n",
+			__func__);
+		return IS_ERR(rst_regmap);
+	}
+
+	/********* phy init  ******/
+	// reset usb host
+	regmap_update_bits(rst_regmap, IPSRST2_OFFSET,
+			(0x1 << 26), (0x1 << 26));
+	regmap_update_bits(rst_regmap, IPSRST3_OFFSET,
+			(0x1 << 25), (0x1 << 25));
+	regmap_update_bits(gcr_regmap, USB2PHYCTL_OFFSET,
+			(0x1 << 28), 0);
+
+	udelay(1);
+
+	// enable phy
+	regmap_update_bits(rst_regmap, IPSRST3_OFFSET,
+			(0x1 << 25), 0);
+
+	udelay(50); // enable phy
+
+	regmap_update_bits(gcr_regmap, USB2PHYCTL_OFFSET,
+			(0x1 << 28), (0x1 << 28));
+
+	// enable host
+	regmap_update_bits(rst_regmap, IPSRST2_OFFSET,
+			(0x1 << 26), 0);
+
+	if (usb_disabled())
+		return -ENODEV;
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		retval = irq;
+		goto fail;
+	}
+
+	/*
+	 * Right now device-tree probed devices don't get dma_mask set.
+	 * Since shared usb code relies on it, set it here for now.
+	 * Once we have dma capability bindings this can go away.
+	 */
+	retval = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+	if (retval)
+		goto fail;
+
+	hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
+	if (!hcd) {
+		retval = -ENOMEM;
+		goto fail;
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	hcd->regs = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(hcd->regs)) {
+		retval = PTR_ERR(hcd->regs);
+		goto err_put_hcd;
+	}
+	hcd->rsrc_start = res->start;
+	hcd->rsrc_len = resource_size(res);
+
+	/* registers start at offset 0x0 */
+	hcd_to_ehci(hcd)->caps = hcd->regs;
+
+	retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
+	if (retval)
+		goto err_put_hcd;
+
+	device_wakeup_enable(hcd->self.controller);
+	return retval;
+
+err_put_hcd:
+	usb_put_hcd(hcd);
+fail:
+	dev_err(&pdev->dev, "init fail, %d\n", retval);
+
+	return retval;
+}
+
+static int npcm7xx_ehci_hcd_drv_remove(struct platform_device *pdev)
+{
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
+
+	usb_remove_hcd(hcd);
+
+	usb_put_hcd(hcd);
+
+	return 0;
+}
+
+static const struct of_device_id npcm7xx_ehci_id_table[] = {
+	{ .compatible = "nuvoton,npcm750-ehci" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, npcm7xx_ehci_id_table);
+
+static struct platform_driver npcm7xx_ehci_hcd_driver = {
+	.probe		= npcm7xx_ehci_hcd_drv_probe,
+	.remove		= npcm7xx_ehci_hcd_drv_remove,
+	.shutdown	= usb_hcd_platform_shutdown,
+	.driver		= {
+		.name = "npcm7xx-ehci",
+		.bus = &platform_bus_type,
+		.pm = &ehci_npcm7xx_pm_ops,
+		.of_match_table = npcm7xx_ehci_id_table,
+	}
+};
+
+static int __init ehci_npcm7xx_init(void)
+{
+	if (usb_disabled())
+		return -ENODEV;
+
+	pr_info("%s: " DRIVER_DESC "\n", hcd_name);
+
+	ehci_init_driver(&ehci_npcm7xx_hc_driver, NULL);
+	return platform_driver_register(&npcm7xx_ehci_hcd_driver);
+}
+module_init(ehci_npcm7xx_init);
+
+static void __exit ehci_npcm7xx_cleanup(void)
+{
+	platform_driver_unregister(&npcm7xx_ehci_hcd_driver);
+}
+module_exit(ehci_npcm7xx_cleanup);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_ALIAS("platform:npcm7xx-ehci");
+MODULE_AUTHOR("Avi Fishman");
+MODULE_LICENSE("GPL v2");
-- 
2.14.1

^ permalink raw reply related

* [PATCH v2 0/3] USB host: Add USB ehci support for nuvoton npcm7xx
From: avifishman70 @ 2018-05-31 13:40 UTC (permalink / raw)
  To: gregkh, stern
  Cc: avifishman70, tmaimon77, venture, yuenn, brendanhiggins,
	mathias.nyman, bjorn.andersson, jhogan, albeu, chunfeng.yun, tony,
	baolu.lu, elder, digetx, kstewart, hdegoede, linux-kernel,
	linux-usb, openbmc, robh+dt, mark.rutland, devicetree,
	Avi Fishman

From: Avi Fishman <AviFishman70@gmail.com>

Changes since version 1:
- Follow Rob comments in device tree documentation
- minor log error fix in ehci-npcm7xx.c
   
This patch adds support for ehci controller for the Nuvoton npcm7xx platform.
Most of the code was taken from ehci-spear.c + specific initialization code

Avi Fishman (3):
  USB host: Add USB ehci support for nuvoton npcm7xx platform
  USB: DT probing support to ehci-npcm7xx
  MAINTAINERS: add subfolders for nuvoton *npcm*

 .../devicetree/bindings/usb/npcm7xx-usb.txt        |  17 ++
 MAINTAINERS                                        |   3 +
 drivers/usb/host/Kconfig                           |   8 +
 drivers/usb/host/Makefile                          |   1 +
 drivers/usb/host/ehci-npcm7xx.c                    | 212 +++++++++++++++++++++
 5 files changed, 241 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
 create mode 100644 drivers/usb/host/ehci-npcm7xx.c

-- 
2.14.1

^ permalink raw reply

* Re: [PATCH v2 0/8] gnss: add new GNSS subsystem
From: Johan Hovold @ 2018-05-31 13:37 UTC (permalink / raw)
  To: H. Nikolaus Schaller
  Cc: Johan Hovold, Richard Cochran, Greg Kroah-Hartman, Rob Herring,
	Mark Rutland, Andreas Kemnade, Arnd Bergmann, Pavel Machek,
	Marcel Holtmann, Sebastian Reichel, Tony Lindgren, linux-kernel,
	devicetree
In-Reply-To: <598825FD-67A5-4016-BCE8-A50517472B8F@goldelico.com>

On Thu, May 31, 2018 at 03:33:41PM +0200, H. Nikolaus Schaller wrote:
> > Am 31.05.2018 um 13:47 schrieb Johan Hovold <johan@kernel.org>:

> > Using pps-gpio would not allow you to describe the hardware properly,
> > something which, for example, may be needed for power management (e.g.
> > to power on the GNSS receiver when the pps device is being accessed).
> 
> Yes, that is indeed a very valid reason to do it that way as the pps-gpio
> seems to assume an always-on impulse source.
> 
> On the other hand it looks as if the pps framework can't tell the
> source when to power on/off because it does not notify when it
> is being accessed or not:
> 
> https://elixir.bootlin.com/linux/v4.17-rc7/source/drivers/pps/pps.c#L305

Yeah, we may need to address that when/if we get there.

Thanks,
Johan

^ permalink raw reply

* Re: [PATCH v2 0/8] gnss: add new GNSS subsystem
From: H. Nikolaus Schaller @ 2018-05-31 13:33 UTC (permalink / raw)
  To: Johan Hovold
  Cc: Richard Cochran, Greg Kroah-Hartman, Rob Herring, Mark Rutland,
	Andreas Kemnade, Arnd Bergmann, Pavel Machek, Marcel Holtmann,
	Sebastian Reichel, Tony Lindgren, linux-kernel, devicetree
In-Reply-To: <20180531114743.GG3259@localhost>


> Am 31.05.2018 um 13:47 schrieb Johan Hovold <johan@kernel.org>:
> 
> On Thu, May 31, 2018 at 11:52:18AM +0200, H. Nikolaus Schaller wrote:
>> 
>>> Am 31.05.2018 um 10:52 schrieb Johan Hovold <johan@kernel.org>:
>>> 
>>> On Wed, May 30, 2018 at 07:38:22AM -0700, Richard Cochran wrote:
>>>> On Wed, May 30, 2018 at 12:32:34PM +0200, Johan Hovold wrote:
>>>>> Another possible extension is to add generic 1PPS support.
>>>> 
>>>> There are two possibilities to consider.
>>>> 
>>>> 1. If the PPS causes an interrupt, then it should hook into the PPS
>>>>  subsystem.
>>> 
>>> Registering a PPS child device is what I had in mind for this.
>> 
>> This seems to be duplicating functionality that is already solved by
>> 
>> https://elixir.bootlin.com/linux/v4.17-rc7/source/Documentation/devicetree/bindings/pps/pps-gpio.txt
>> 
>> and
>> 
>> https://elixir.bootlin.com/linux/v4.17-rc7/source/drivers/pps/clients/pps-gpio.c
>> 
>> Or what is bad with just using that?
> 
> Using pps-gpio would not allow you to describe the hardware properly,
> something which, for example, may be needed for power management (e.g.
> to power on the GNSS receiver when the pps device is being accessed).

Yes, that is indeed a very valid reason to do it that way as the pps-gpio
seems to assume an always-on impulse source.

On the other hand it looks as if the pps framework can't tell the
source when to power on/off because it does not notify when it
is being accessed or not:

https://elixir.bootlin.com/linux/v4.17-rc7/source/drivers/pps/pps.c#L305

BR,
Nikolaus

^ permalink raw reply

* Re: [PATCH v2 0/3] USB host: Add USB ehci support for nuvoton npcm7xx
From: Avi Fishman @ 2018-05-31 13:31 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Alan Stern
  Cc: Avi Fishman, Tomer Maimon, Patrick Venture, Nancy Yuen,
	Brendan Higgins, mathias.nyman, bjorn.andersson, jhogan, albeu,
	chunfeng.yun, Tony Lindgren, baolu.lu, Alex Elder,
	Dmitry Osipenko, Kate Stewart, hdegoede,
	Linux Kernel Mailing List, linux-usb, OpenBMC Maillist,
	Rob Herring, Mark Rutland, devicetree, davem
In-Reply-To: <CAKKbWA6CF3M7+ohT5dsrmQbR_S1om+zQVgakAsYb165PBctadA@mail.gmail.com>

Changes since version 1:
- Follow Rob comments in device tree documentation
- minor log error fix in ehci-npcm7xx.c

This patch adds support for ehci controller for the Nuvoton npcm7xx platform.
Most of the code was taken from ehci-spear.c + specific initialization code

Avi Fishman (3):
  USB host: Add USB ehci support for nuvoton npcm7xx platform
  USB: DT probing support to ehci-npcm7xx
  MAINTAINERS: add subfolders for nuvoton *npcm*

 .../devicetree/bindings/usb/npcm7xx-usb.txt        |  17 ++
 MAINTAINERS                                        |   3 +
 drivers/usb/host/Kconfig                           |   8 +
 drivers/usb/host/Makefile                          |   1 +
 drivers/usb/host/ehci-npcm7xx.c                    | 212 +++++++++++++++++++++
 5 files changed, 241 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
 create mode 100644 drivers/usb/host/ehci-npcm7xx.c


-- 
2.14.1

^ permalink raw reply

* Re: [PATCH v2 3/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
From: Tero Kristo @ 2018-05-31 13:29 UTC (permalink / raw)
  To: Faiz Abbas, Rob Herring
  Cc: devicetree, paul, tony, linux-kernel, bcousson, linux-omap,
	linux-clk, linux-arm-kernel
In-Reply-To: <e7e3ade1-76b7-f216-ece5-bd64a55cede6@ti.com>

On 31/05/18 13:14, Faiz Abbas wrote:
> Hi,
> 
> On Thursday 31 May 2018 09:33 AM, Rob Herring wrote:
>> On Wed, May 30, 2018 at 07:41:30PM +0530, Faiz Abbas wrote:
>>> Add clkctrl data for the m_can clocks and register it within the
> ...
>>>   
>>> diff --git a/include/dt-bindings/clock/dra7.h b/include/dt-bindings/clock/dra7.h
>>> index 5e1061b15aed..d7549c57cac3 100644
>>> --- a/include/dt-bindings/clock/dra7.h
>>> +++ b/include/dt-bindings/clock/dra7.h
>>> @@ -168,5 +168,6 @@
>>>   #define DRA7_COUNTER_32K_CLKCTRL	DRA7_CLKCTRL_INDEX(0x50)
>>>   #define DRA7_UART10_CLKCTRL	DRA7_CLKCTRL_INDEX(0x80)
>>>   #define DRA7_DCAN1_CLKCTRL	DRA7_CLKCTRL_INDEX(0x88)
>>> +#define DRA7_ADC_CLKCTRL	DRA7_CLKCTRL_INDEX(0xa0)
>>
>> ADC and mcan are the same thing?
>>
> 
> The register to control MCAN clocks is called ADC_CLKCTRL, Yes.

Is there any reason for this or is that just a documentation bug?

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply

* Re: [RESEND PATCH 2/4] PCI: cadence: Add generic PHY support to host and EP drivers
From: Kishon Vijay Abraham I @ 2018-05-31 13:26 UTC (permalink / raw)
  To: Alan Douglas, bhelgaas, lorenzo.pieralisi, linux-pci
  Cc: devicetree, linux-kernel, cyrille.pitchen
In-Reply-To: <1526995626-9333-1-git-send-email-adouglas@cadence.com>

Hi,

On Tuesday 22 May 2018 06:57 PM, Alan Douglas wrote:
> If PHYs are present, they will be initialized and enabled in driver probe,
> and disabled in driver shutdown.
> 
> Signed-off-by: Alan Douglas <adouglas@cadence.com>
> ---
>  drivers/pci/cadence/pcie-cadence-ep.c   | 14 ++++-
>  drivers/pci/cadence/pcie-cadence-host.c | 31 +++++++++++
>  drivers/pci/cadence/pcie-cadence.c      | 93 +++++++++++++++++++++++++++++++++
>  drivers/pci/cadence/pcie-cadence.h      |  7 +++
>  4 files changed, 144 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/cadence/pcie-cadence-ep.c b/drivers/pci/cadence/pcie-cadence-ep.c
> index 3d8283e..2581caf 100644
> --- a/drivers/pci/cadence/pcie-cadence-ep.c
> +++ b/drivers/pci/cadence/pcie-cadence-ep.c
> @@ -439,6 +439,7 @@ static int cdns_pcie_ep_probe(struct platform_device *pdev)
>  	struct pci_epc *epc;
>  	struct resource *res;
>  	int ret;
> +	int phy_count;
>  
>  	ep = devm_kzalloc(dev, sizeof(*ep), GFP_KERNEL);
>  	if (!ep)
> @@ -472,6 +473,12 @@ static int cdns_pcie_ep_probe(struct platform_device *pdev)
>  	if (!ep->ob_addr)
>  		return -ENOMEM;
>  
> +	ret = cdns_pcie_init_phy(dev, pcie);
> +	if (ret) {
> +		dev_err(dev, "failed to init phy\n");
> +		return ret;
> +	}
> +	platform_set_drvdata(pdev, pcie);
>  	pm_runtime_enable(dev);
>  	ret = pm_runtime_get_sync(dev);
>  	if (ret < 0) {
> @@ -520,6 +527,10 @@ static int cdns_pcie_ep_probe(struct platform_device *pdev)
>  
>   err_get_sync:
>  	pm_runtime_disable(dev);
> +	cdns_pcie_disable_phy(pcie);
> +	phy_count = pcie->phy_count;
> +	while (phy_count--)
> +		device_link_del(pcie->link[phy_count]);
>  
>  	return ret;
>  }
> @@ -527,6 +538,7 @@ static int cdns_pcie_ep_probe(struct platform_device *pdev)
>  static void cdns_pcie_ep_shutdown(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> +	struct cdns_pcie *pcie = dev_get_drvdata(dev);
>  	int ret;
>  
>  	ret = pm_runtime_put_sync(dev);
> @@ -535,7 +547,7 @@ static void cdns_pcie_ep_shutdown(struct platform_device *pdev)
>  
>  	pm_runtime_disable(dev);
>  
> -	/* The PCIe controller can't be disabled. */
> +	cdns_pcie_disable_phy(pcie);
>  }
>  
>  static struct platform_driver cdns_pcie_ep_driver = {
> diff --git a/drivers/pci/cadence/pcie-cadence-host.c b/drivers/pci/cadence/pcie-cadence-host.c
> index a4ebbd3..7536926a 100644
> --- a/drivers/pci/cadence/pcie-cadence-host.c
> +++ b/drivers/pci/cadence/pcie-cadence-host.c
> @@ -58,6 +58,9 @@ static void __iomem *cdns_pci_map_bus(struct pci_bus *bus, unsigned int devfn,
>  
>  		return pcie->reg_base + (where & 0xfff);
>  	}
> +	/* Check that the link is up */
> +	if (!(cdns_pcie_readl(pcie, CDNS_PCIE_LM_BASE) & 0x1))
> +		return NULL;
>  
>  	/* Update Output registers for AXI region 0. */
>  	addr0 = CDNS_PCIE_AT_OB_REGION_PCI_ADDR0_NBITS(12) |
> @@ -239,6 +242,7 @@ static int cdns_pcie_host_probe(struct platform_device *pdev)
>  	struct cdns_pcie *pcie;
>  	struct resource *res;
>  	int ret;
> +	int phy_count;
>  
>  	bridge = devm_pci_alloc_host_bridge(dev, sizeof(*rc));
>  	if (!bridge)
> @@ -290,6 +294,13 @@ static int cdns_pcie_host_probe(struct platform_device *pdev)
>  	}
>  	pcie->mem_res = res;
>  
> +	ret = cdns_pcie_init_phy(dev, pcie);
> +	if (ret) {
> +		dev_err(dev, "failed to init phy\n");
> +		return ret;
> +	}
> +	platform_set_drvdata(pdev, pcie);
> +
>  	pm_runtime_enable(dev);
>  	ret = pm_runtime_get_sync(dev);
>  	if (ret < 0) {
> @@ -322,15 +333,35 @@ static int cdns_pcie_host_probe(struct platform_device *pdev)
>  
>   err_get_sync:
>  	pm_runtime_disable(dev);
> +	cdns_pcie_disable_phy(pcie);
> +	phy_count = pcie->phy_count;
> +	while (phy_count--)
> +		device_link_del(pcie->link[phy_count]);
>  
>  	return ret;
>  }
>  
> +static void cdns_pcie_shutdown(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct cdns_pcie *pcie = dev_get_drvdata(dev);
> +	int ret;
> +
> +	ret = pm_runtime_put_sync(dev);
> +	if (ret < 0)
> +		dev_dbg(dev, "pm_runtime_put_sync failed\n");
> +
> +	pm_runtime_disable(dev);
> +	cdns_pcie_disable_phy(pcie);
> +}

shutdown callback can be added in a separate patch.

> +
> +
spurious blank line.
>  static struct platform_driver cdns_pcie_host_driver = {
>  	.driver = {
>  		.name = "cdns-pcie-host",
>  		.of_match_table = cdns_pcie_host_of_match,
>  	},
>  	.probe = cdns_pcie_host_probe,
> +	.shutdown = cdns_pcie_shutdown,
>  };
>  builtin_platform_driver(cdns_pcie_host_driver);
> diff --git a/drivers/pci/cadence/pcie-cadence.c b/drivers/pci/cadence/pcie-cadence.c
> index 138d113..681609a 100644
> --- a/drivers/pci/cadence/pcie-cadence.c
> +++ b/drivers/pci/cadence/pcie-cadence.c
> @@ -124,3 +124,96 @@ void cdns_pcie_reset_outbound_region(struct cdns_pcie *pcie, u32 r)
>  	cdns_pcie_writel(pcie, CDNS_PCIE_AT_OB_REGION_CPU_ADDR0(r), 0);
>  	cdns_pcie_writel(pcie, CDNS_PCIE_AT_OB_REGION_CPU_ADDR1(r), 0);
>  }
> +
> +void cdns_pcie_disable_phy(struct cdns_pcie *pcie)
> +{
> +	int i = pcie->phy_count;
> +
> +	while (i--) {
> +		phy_power_off(pcie->phy[i]);
> +		phy_exit(pcie->phy[i]);
> +	}
> +}
> +
> +int cdns_pcie_enable_phy(struct cdns_pcie *pcie)
> +{
> +	int ret;
> +	int i;
> +
> +	for (i = 0; i < pcie->phy_count; i++) {
> +		ret = phy_init(pcie->phy[i]);
> +		if (ret < 0)
> +			goto err_phy;
> +
> +		ret = phy_power_on(pcie->phy[i]);
> +		if (ret < 0) {
> +			phy_exit(pcie->phy[i]);
> +			goto err_phy;
> +		}
> +	}
> +
> +	return 0;
> +
> +err_phy:
> +	while (--i >= 0) {
> +		phy_power_off(pcie->phy[i]);
> +		phy_exit(pcie->phy[i]);
> +	}
> +
> +	return ret;
> +}
> +
> +int cdns_pcie_init_phy(struct device *dev, struct cdns_pcie *pcie)
> +{
> +	struct device_node *np = dev->of_node;
> +	int phy_count;
> +	struct phy **phy;
> +	struct device_link **link;
> +	int i;
> +	int ret;
> +	const char *name;
> +
> +	phy_count = of_property_count_strings(np, "phy-names");

It's preferable to have num-lanes property, which can be used to configure the
number of lanes supported in a platform even if it doesn't populate PHYs property.
> +	if (phy_count < 1) {
> +		dev_err(dev, "no phy-names.  PHY will not be initialized\n");
> +		pcie->phy_count = 0;
> +		return 0;
> +	}
> +
> +	phy = devm_kzalloc(dev, sizeof(*phy) * phy_count, GFP_KERNEL);
> +	if (!phy)
> +		return -ENOMEM;
> +
> +	link = devm_kzalloc(dev, sizeof(*link) * phy_count, GFP_KERNEL);
> +	if (!link)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < phy_count; i++) {
> +		of_property_read_string_index(np, "phy-names", i, &name);
> +		phy[i] = devm_phy_get(dev, name);

For optional PHYs, devm_phy_optional_get() should be used.

Thanks
Kishon

^ permalink raw reply

* Re: [PATCH v1 2/2] hwmon: npcm-pwm: add NPCM7xx PWM driver
From: Guenter Roeck @ 2018-05-31 13:14 UTC (permalink / raw)
  To: kbuild test robot, Tomer Maimon
  Cc: kbuild-all, robh+dt, mark.rutland, jdelvare, avifishman70, yuenn,
	brendanhiggins, venture, joel, devicetree, linux-kernel,
	linux-hwmon, openbmc
In-Reply-To: <201805311515.VL3llohd%fengguang.wu@intel.com>

On 05/31/2018 12:16 AM, kbuild test robot wrote:
> Hi Tomer,
> 
> I love your patch! Perhaps something to improve:
> 
> [auto build test WARNING on hwmon/hwmon-next]
> [also build test WARNING on v4.17-rc7]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> 
> url:    https://github.com/0day-ci/linux/commits/Tomer-Maimon/dt-binding-hwmon-Add-NPCM7xx-PWM-documentation/20180531-034040
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-next
> config: x86_64-allmodconfig
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
>          make ARCH=x86_64  allmodconfig
>          make ARCH=x86_64
> 
> All warnings (new ones prefixed by >>):
> 
> 
> vim +277 drivers/hwmon/npcm7xx-pwm.c
> 
>     250	
>     251	static int npcm7xx_pwm_probe(struct platform_device *pdev)
>     252	{
>     253		struct device *dev = &pdev->dev;
>     254		struct npcm7xx_pwm_data *data;
>     255		struct resource res[NPCM7XX_PWM_MAX_MODULES];
>     256		struct device *hwmon;
>     257		struct clk *clk;
>     258		int m, ch, res_cnt, ret;
>     259		u32 Prescale_val, output_freq;
>     260	
>     261		data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>     262		if (!data)
>     263			return -ENOMEM;
>     264	
>     265		for (res_cnt = 0; res_cnt < NPCM7XX_PWM_MAX_MODULES  ; res_cnt++) {
>     266			ret = of_address_to_resource(dev->of_node, res_cnt,
>     267						     &res[res_cnt]);
>     268			if (ret) {
>     269				pr_err("PWM of_address_to_resource fail ret %d\n",
>     270				       ret);
>     271				return -EINVAL;
>     272			}
>     273	
>     274			data->pwm_base[res_cnt] =
>     275				devm_ioremap_resource(dev, &(res[res_cnt]));
>   > 276			pr_debug("pwm%d base is 0x%08X, res.start 0x%08X , size 0x%08X\n",
>   > 277				 res_cnt, (u32)data->pwm_base[res_cnt],
>     278				 res[res_cnt].start, resource_size(&(res[res_cnt])));
>     279

No idea what the tool is complaining about, but the messages should use dev_ functions.

>     280			if (!data->pwm_base[res_cnt]) {
>     281				pr_err("pwm probe failed: can't read pwm base address for resource %d.\n",
>     282				       res_cnt);
>     283				return -ENOMEM;
>     284			}
>     285	
>     286			mutex_init(&data->npcm7xx_pwm_lock[res_cnt]);
>     287		}
>     288	
>     289		clk = devm_clk_get(dev, NULL);
>     290		if (IS_ERR(clk))
>     291			return -ENODEV;
>     292	
>     293		data->clk_freq = clk_get_rate(clk);
>     294	
>     295		/* Adjust NPCM7xx PWMs output frequency to ~25Khz */
>     296		output_freq = data->clk_freq / PWN_CNT_DEFAULT;
>     297		Prescale_val = DIV_ROUND_CLOSEST(output_freq, PWM_OUTPUT_FREQ_25KHZ);
>     298	
>     299		/* If Prescale_val = 0, then the prescale output clock is stopped */
>     300		if (Prescale_val < MIN_PRESCALE1)
>     301			Prescale_val = MIN_PRESCALE1;
>     302		/*
>     303		 * Prescale_val need to decrement in one because in the PWM Prescale
>     304		 * register the Prescale value increment by one
>     305		 */
>     306		Prescale_val--;
>     307	
>     308		/* Setting PWM Prescale Register value register to both modules */
>     309		Prescale_val |= (Prescale_val << NPCM7XX_PWM_PRESCALE_SHIFT_CH01);
>     310	
>     311		for (m = 0; m < NPCM7XX_PWM_MAX_MODULES  ; m++) {
>     312			iowrite32(Prescale_val,
>     313				  data->pwm_base[m] + NPCM7XX_PWM_REG_PR);
>     314			iowrite32(NPCM7XX_PWM_PRESCALE2_DEFALUT,
>     315				  data->pwm_base[m] + NPCM7XX_PWM_REG_CSR);
>     316			iowrite32(NPCM7XX_PWM_CTRL_MODE_DEFALUT,
>     317				  data->pwm_base[m] + NPCM7XX_PWM_REG_CR);
>     318	
>     319			for (ch = 0; ch < NPCM7XX_PWM_MAX_CHN_NUM; ch++) {
>     320				iowrite32(NPCM7XX_PWM_COUNTER_DEFALUT_NUM,
>     321					  data->pwm_base[m] + NPCM7XX_PWM_REG_CNRx(ch));
>     322				iowrite32(NPCM7XX_PWM_COMPARATOR_DEFALUT_NUM,
>     323					  data->pwm_base[m] + NPCM7XX_PWM_REG_CMRx(ch));
>     324			}
>     325	
>     326			iowrite32(NPCM7XX_PWM_CTRL_MODE_DEFALUT |
>     327				  NPCM7XX_PWM_CTRL_EN_DEFALUT,
>     328				  data->pwm_base[m] + NPCM7XX_PWM_REG_CR);
>     329		}
>     330	
>     331		hwmon = devm_hwmon_device_register_with_info(dev, "npcm7xx_pwm", data,
>     332							     &npcm7xx_chip_info, NULL);
>     333	
>     334		if (IS_ERR(hwmon)) {
>     335			pr_err("PWM Driver failed - devm_hwmon_device_register_with_groups failed\n");
>     336			return PTR_ERR(hwmon);
>     337		}
>     338	
>     339		pr_info("NPCM7XX PWM Driver probed, PWM output Freq %dHz\n",
>     340			output_freq / ((Prescale_val & 0xf) + 1));
>     341	
>     342		return 0;
>     343	}
>     344	
> 
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply

* Re: [PATCH 0/7] sunxi: Add DT representation for the MBUS controller
From: Maxime Ripard @ 2018-05-31 12:52 UTC (permalink / raw)
  To: Rob Herring
  Cc: Mark Rutland, devicetree, Thomas Petazzoni, Arnd Bergmann,
	Robin Murphy, dri-devel, Paul Kocialkowski, Chen-Yu Tsai,
	Yong Deng, Frank Rowand, Dave Martin,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20180409092229.ljcnsqgv7wh2s4op@flea>


[-- Attachment #1.1: Type: text/plain, Size: 2336 bytes --]

On Mon, Apr 09, 2018 at 11:22:29AM +0200, Maxime Ripard wrote:
> Hi Rob,
> 
> On Tue, Apr 03, 2018 at 11:03:30AM -0500, Rob Herring wrote:
> > On Tue, Apr 3, 2018 at 8:29 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > Hi,
> > >
> > > We've had for quite some time to hack around in our drivers to take into
> > > account the fact that our DMA accesses are not done through the parent
> > > node, but through another bus with a different mapping than the CPU for the
> > > RAM (0 instead of 0x40000000 for most SoCs).
> > >
> > > After some discussion after the submission of a camera device suffering of
> > > the same hacks, I've decided to put together a serie that introduce a
> > > property called dma-parent that allows to express the DMA relationship
> > > between a master and its bus, even if they are not direct parents in the DT.
> > 
> > Reading thru v6 of the camera driver, it seems like having
> > intermediate buses would solve the problem in your case?
> 
> I guess it would yes, but I guess it wouldn't model the hardware
> properly since this seems to be really a bus only meant to do DMA, and
> you're not accessing the registers of the device through that bus.
> 
> And as far as I know, the DT implies that the topology is the one of
> the "control" side of the devices.
> 
> We'll also need eventually to have retrieve the MBUS endpoints ID to
> be able to support perf and PM QoS properly.
> 
> > As Arnd mentioned in that thread, something new needs to address all
> > the deficiencies with dma-ranges and describing DMA bus topologies.
> > This doesn't address the needs of describing bus interconnects.
> > There's been some efforts by the QCom folks with an interconnect
> > binding. They've mostly punted (for now at least) to not describing
> > the whole interconnect in DT and keeping the details in a driver.
> 
> Is it that patch serie? https://lkml.org/lkml/2018/3/9/856
> 
> > On the flip side, this does mirror the established pattern used by
> > interrupts, so maybe it's okay on it's own. I'll wait for others to
> > comment.
> 
> We'll see how it turns out then :)

Ping?

How should we move forward on this?

Maxime


-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* [RFC PATCH 6/6] ARM: dts: keystone-k2g-evm: add LCD and HDMI displays
From: Tomi Valkeinen @ 2018-05-31 12:41 UTC (permalink / raw)
  To: dri-devel, linux-omap, Laurent Pinchart, Peter Ujfalusi,
	Jyri Sarha, Benoit Parrot
  Cc: devicetree, Tomi Valkeinen
In-Reply-To: <20180531124109.3209-1-tomi.valkeinen@ti.com>

K2G EVM has an SiI902x HDMI encoder on the board, and a separately
purchasable LCD which can be attached to the board. Only one of these
displays can be used at a time, and two dip-switches need to be changed
when switching to another display.

The HDMI support is added to the base k2g-evm.dts file, and the LCD
support is added as a separate k2g-evm-lcd.dts file. The user must
choose one of the dtbs, depending on which display he wants to use.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: devicetree@vger.kernel.org
---
 arch/arm/boot/dts/Makefile                 |  1 +
 arch/arm/boot/dts/keystone-k2g-evm-lcd.dts | 80 +++++++++++++++++++
 arch/arm/boot/dts/keystone-k2g-evm.dts     | 91 ++++++++++++++++++++++
 3 files changed, 172 insertions(+)
 create mode 100644 arch/arm/boot/dts/keystone-k2g-evm-lcd.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..11bb3ba22bdf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -222,6 +222,7 @@ dtb-$(CONFIG_ARCH_KEYSTONE) += \
 	keystone-k2l-evm.dtb \
 	keystone-k2e-evm.dtb \
 	keystone-k2g-evm.dtb \
+	keystone-k2g-evm-lcd.dtb \
 	keystone-k2g-ice.dtb
 dtb-$(CONFIG_MACH_KIRKWOOD) += \
 	kirkwood-b3.dtb \
diff --git a/arch/arm/boot/dts/keystone-k2g-evm-lcd.dts b/arch/arm/boot/dts/keystone-k2g-evm-lcd.dts
new file mode 100644
index 000000000000..be0498010e71
--- /dev/null
+++ b/arch/arm/boot/dts/keystone-k2g-evm-lcd.dts
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for K2G EVM with LCD Display
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include "keystone-k2g-evm.dts"
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+	lcd0: display {
+		compatible = "newhaven,nhd-4.3-480272ef-atxl", "panel-dpi";
+		label = "lcd";
+
+		backlight = <&lcd_bl>;
+
+		panel-timing {
+			clock-frequency = <9000000>;
+			hactive = <480>;
+			vactive = <272>;
+			hfront-porch = <2>;
+			hback-porch = <2>;
+			hsync-len = <41>;
+			vfront-porch = <2>;
+			vback-porch = <2>;
+			vsync-len = <10>;
+			hsync-active = <0>;
+			vsync-active = <0>;
+			de-active = <1>;
+			pixelclk-active = <1>;
+		};
+
+		port {
+			lcd_in: endpoint {
+				remote-endpoint = <&dpi_out>;
+			};
+		};
+	};
+
+	lcd_bl: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&ecap0 0 50000 PWM_POLARITY_INVERTED>;
+		brightness-levels = <0 32 64 96 128 160 192 224 255>;
+		default-brightness-level = <8>;
+	};
+};
+
+&i2c1 {
+	edt-ft5306@38 {
+		status = "okay";
+		compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
+		reg = <0x38>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&edt_ft5306_ts_pins>;
+
+		interrupt-parent = <&gpio1>;
+		interrupts = <42 IRQ_TYPE_EDGE_FALLING>;
+
+		touchscreen-size-x = <480>;
+		touchscreen-size-y = <272>;
+	};
+};
+
+&k2g_pinctrl {
+	edt_ft5306_ts_pins: edt_ft5306_ts_pins {
+		pinctrl-single,pins = <
+			K2G_CORE_IOPAD(0x1364) (BUFFER_CLASS_B | PIN_PULLDOWN | MUX_MODE3)	/* pr1_pru1_gpo16.gpio1_42 */
+		>;
+	};
+};
+
+&dpi_out {
+	remote-endpoint = <&lcd_in>;
+};
+
+&sii9022 {
+	status = "disabled";
+};
diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 6a4657799b99..e94be4a1bbd3 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -81,6 +81,13 @@
 		>;
 	};
 
+	i2c1_pins: pinmux_i2c1_pins {
+		pinctrl-single,pins = <
+			K2G_CORE_IOPAD(0x1384) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)	/* i2c1_scl.i2c1_scl */
+			K2G_CORE_IOPAD(0x1388) (BUFFER_CLASS_B | PIN_PULLUP | MUX_MODE0)	/* i2c1_sda.i2c1_sda */
+		>;
+	};
+
 	ecap0_pins: ecap0_pins {
 		pinctrl-single,pins = <
 			K2G_CORE_IOPAD(0x1374) (BUFFER_CLASS_B | MUX_MODE4)	/* pr1_mdio_data.ecap0_in_apwm0_out */
@@ -114,6 +121,46 @@
 			K2G_CORE_IOPAD(0x11f0) (BUFFER_CLASS_B | PIN_PULLDOWN | MUX_MODE0)      /* uart2_txd.uart2_txd */
 		>;
 	};
+
+	vout_pins: pinmux_vout_pins {
+		pinctrl-single,pins = <
+			K2G_CORE_IOPAD(0x1078) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata23.dssdata23 */
+			K2G_CORE_IOPAD(0x107c) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata22.dssdata22 */
+			K2G_CORE_IOPAD(0x1080) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata21.dssdata21 */
+			K2G_CORE_IOPAD(0x1084) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata20.dssdata20 */
+			K2G_CORE_IOPAD(0x1088) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata19.dssdata19 */
+			K2G_CORE_IOPAD(0x108c) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata18.dssdata18 */
+			K2G_CORE_IOPAD(0x1090) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata17.dssdata17 */
+			K2G_CORE_IOPAD(0x1094) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata16.dssdata16 */
+			K2G_CORE_IOPAD(0x1098) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata15.dssdata15 */
+			K2G_CORE_IOPAD(0x109c) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata14.dssdata14 */
+			K2G_CORE_IOPAD(0x10a0) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata13.dssdata13 */
+			K2G_CORE_IOPAD(0x10a4) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata12.dssdata12 */
+			K2G_CORE_IOPAD(0x10a8) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata11.dssdata11 */
+			K2G_CORE_IOPAD(0x10ac) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata10.dssdata10 */
+			K2G_CORE_IOPAD(0x10b0) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata9.dssdata9 */
+			K2G_CORE_IOPAD(0x10b4) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata8.dssdata8 */
+			K2G_CORE_IOPAD(0x10b8) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata7.dssdata7 */
+			K2G_CORE_IOPAD(0x10bc) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata6.dssdata6 */
+			K2G_CORE_IOPAD(0x10c0) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata5.dssdata5 */
+			K2G_CORE_IOPAD(0x10c4) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata4.dssdata4 */
+			K2G_CORE_IOPAD(0x10c8) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata3.dssdata3 */
+			K2G_CORE_IOPAD(0x10cc) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata2.dssdata2 */
+			K2G_CORE_IOPAD(0x10d0) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata1.dssdata1 */
+			K2G_CORE_IOPAD(0x10d4) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssdata0.dssdata0 */
+			K2G_CORE_IOPAD(0x10d8) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssvsync.dssvsync */
+			K2G_CORE_IOPAD(0x10dc) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dsshsync.dsshsync */
+			K2G_CORE_IOPAD(0x10e0) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dsspclk.dsspclk */
+			K2G_CORE_IOPAD(0x10e4) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssde.dssde */
+			K2G_CORE_IOPAD(0x10e8) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE0) /* dssfid.dssfid */
+		>;
+	};
+
+	sii9022_pins: sii9022_pins {
+		pinctrl-single,pins = <
+			K2G_CORE_IOPAD(0x1338) (BUFFER_CLASS_B | PULL_DISABLE | MUX_MODE3)      /* pr1_pru1_gpo5.gpio1_31 */
+		>;
+	};
 };
 
 &uart0 {
@@ -268,3 +315,47 @@
 	pinctrl-0 = <&uart2_pins>;
 	status = "okay";
 };
+
+&dss {
+	pinctrl-names = "default";
+	pinctrl-0 = <&vout_pins>;
+	status = "ok";
+
+	port {
+		dpi_out: endpoint {
+			remote-endpoint = <&sii9022_in>;
+		};
+	};
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
+	status = "okay";
+	clock-frequency = <400000>;
+
+	sii9022: sii9022@3b {
+		compatible = "sil,sii9022";
+		reg = <0x3b>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&sii9022_pins>;
+
+		/* Should be IRQ_TYPE_LEVEL_LOW, but k2g does not support it */
+		interrupt-parent = <&gpio1>;
+		interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+
+				sii9022_in: endpoint {
+					remote-endpoint = <&dpi_out>;
+				};
+			};
+		};
+	};
+};
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related

* [RFC PATCH 5/6] ARM: dts: keystone-k2g: add DSS node
From: Tomi Valkeinen @ 2018-05-31 12:41 UTC (permalink / raw)
  To: dri-devel, linux-omap, Laurent Pinchart, Peter Ujfalusi,
	Jyri Sarha, Benoit Parrot
  Cc: devicetree, Tomi Valkeinen
In-Reply-To: <20180531124109.3209-1-tomi.valkeinen@ti.com>

Add DSS node to k2g.dtsi.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: devicetree@vger.kernel.org
---
 arch/arm/boot/dts/keystone-k2g.dtsi | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index da78c0034427..d761fe7d46e7 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -609,5 +609,26 @@
 			reg = <0x21010000 0x200>;
 			interrupts = <GIC_SPI 123 IRQ_TYPE_EDGE_RISING>;
 		};
+
+		dss: dss@02540000 {
+			compatible = "ti,k2g-dss";
+
+			reg = <0x02540000 0x400>,
+			      <0x02550000 0x1000>,
+			      <0x02557000 0x1000>,
+			      <0x0255a800 0x100>,
+			      <0x0255ac00 0x100>;
+
+			reg-names = "cfg", "common", "vid1", "ovr1", "vp1";
+
+			clocks = <&k2g_clks 0x2 0>, <&k2g_clks 0x2 1>;
+			clock-names = "fck", "vp1";
+
+			power-domains = <&k2g_pds 0x2>;
+
+			interrupts = <GIC_SPI 247 IRQ_TYPE_EDGE_RISING>;
+
+			status = "disabled";
+		};
 	};
 };
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related

* [RFC PATCH 2/6] dt-bindings: display/ti: add k2g-dss bindings
From: Tomi Valkeinen @ 2018-05-31 12:41 UTC (permalink / raw)
  To: dri-devel, linux-omap, Laurent Pinchart, Peter Ujfalusi,
	Jyri Sarha, Benoit Parrot
  Cc: devicetree, Tomi Valkeinen
In-Reply-To: <20180531124109.3209-1-tomi.valkeinen@ti.com>

Add DT bindings for Texas Instruments K2G SoC Display Subsystem. The DSS
is quite simple, with a single plane and a single output.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: devicetree@vger.kernel.org
---
 .../devicetree/bindings/display/ti/ti,k2g-dss.txt | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt

diff --git a/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt
new file mode 100644
index 000000000000..1af11425eda3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt
@@ -0,0 +1,15 @@
+Texas Instruments K2G Display Subsystem
+=======================================
+
+Required properties:
+- compatible: "ti,k2g-dss"
+- reg: address and length of the register spaces for DSS submodules
+- reg-names: "cfg", "common", "vid1", "ovr1", "vp1"
+- clocks: phandle to fclk and vp1 clocks
+- clock-names: "fck", "vp1"
+- interrupts: phandle to the DISPC interrupt
+
+The DSS outputs are described using the device graphs as documented in
+Documentation/devicetree/bindings/graph.txt. K2G DSS has a single DPI output as
+port 0.
+
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related

* Re: [PATCH v1 2/2] hwmon: npcm-pwm: add NPCM7xx PWM driver
From: Tomer Maimon @ 2018-05-31 12:32 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Rob Herring, Mark Rutland, jdelvare, Avi Fishman, Nancy Yuen,
	Brendan Higgins, Patrick Venture, Joel Stanley, devicetree,
	Linux Kernel Mailing List, linux-hwmon, OpenBMC Maillist,
	linux-pwm, Thierry Reding, eyal.cohen
In-Reply-To: <20180530164604.GB8270@roeck-us.net>

[-- Attachment #1: Type: text/plain, Size: 3844 bytes --]

Hi Guenter,

Thanks for the prompt and detailed reply,

On 30 May 2018 at 19:46, Guenter Roeck <linux@roeck-us.net> wrote:

> On Wed, May 30, 2018 at 06:44:58PM +0300, Tomer Maimon wrote:
> > Hi  Guenter,
> >
> > Thanks for your prompt reply!
> >
> >
> > On 29 May 2018 at 19:56, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > > On Tue, May 29, 2018 at 01:02:21PM +0300, Tomer Maimon wrote:
> > > > Add Nuvoton BMC NPCM7xx Pulse Width Modulation (PWM) driver.
> > > >
> > > > The Nuvoton BMC NPCM7xx has two identical PWM controller modules,
> > > > each module has four PWM controller outputs.
> > > >
> > >
> > > I don't see it guaranteed that all future NPCM7xx devices will be PWM
> > > controllers, much less that they will be compatible to the chip really
> > >
> >
> > Actually all NPCM7xx family have PWM and FAN modules support,
> >
> >
> > > supported here. NPCM750, I presume ? I would suggest name the driver
> > > accordingly.
> > >
> >
> > The compatible name can not be a family name like nuvoton,npcm7xx-pwm,
> only
> > a specific chip name. (in our case the NPCM750 is the full modules SOC)
> > still you think i should change the driver name? (note: all of our
> NPCM7xx
> > unique modules drivers are named npcm7xx-*.c or *-npcm7xx.c)
> >
>
> drivers/watchdog/npcm_wdt.c contradicts that statement.
>
> Please discuss with the pwm maintainer. In hwmon, wildcards in driver file
> names are discouraged and will not be accepted. Our recommendation is to
> pick
> one chip from the family and use it as part of the file name.
>

Thanks for the clarification, we will name the driver according your
recommendation.

>
> >
> > > As a generic pwm driver, not specifically tied to a fan controller,
> > > this driver does not belong into hwmon. It should be added to the pwm
> > > subsystem. Copying the maintainer and mailing list.
> > >
> > > In the NPCM7xx we have PWM and FAN controller modules,  usually in the
> > aspect of our BMC clients the two module
> > are used together to control the fans.
> >
> > But because in the NPCM7xx the PWM and the FAN controller are separate
> > modules we
> > thought to do two separate drivers in the hwmon
> > is it possible? or you think it is better to do one hwmon driver for the
> > PWM and the FAN controller.
> >
> That depends on how closely the two modules are intertwined. If the pwm
> module
> is generic, it belongs into the pwm subsystem. It only belongs into hwmon
> if it can _only_ be used for fan control, eg if the data reported by the
> fan
> module is used by the hardware to control the pwm output based on some
> fan speed <-> pw value mapping which is programmed into the chip, and/or
> if the pwm output can only connect to a fan and nothing else, and if the
> relationship between pwm output and fan input is well defined.
>
>
Again thank you for your clarification, our PWM module was designed to work
with fan devices and for fan control.
i.e. on all server boards the pwm output is only connect to a fan device.


> If both end up in hwmon, I don't see the benefit of having two separate
> drivers. That means two hwmon devices for the same fan or set of fans,
> one being all but useless in respect to output from the 'sensors'
> command. You'll have to convince me why that would make sense; I just
> don't see the point.  In that case, I would also not see the point of
> having two separate devicetree nodes; to me, that would be similar
> to having two interfaces for a single serial line, one for receive
> and one for transmit.


Since our PWM and FAN are made only for handling the fans we will use them
in a single hwmon driver as you recommended

> note that we were going to submit soon also the FAN controller driver
> under
> > hwmon.
> >
> No problem with that as long as there are no wildcards in the file name.
>
> Guenter
>

Thanks,

Tomer

[-- Attachment #2: Type: text/html, Size: 8427 bytes --]

^ permalink raw reply

* Re: [PATCH v2 5/5] arm64: dts: renesas: r8a7795: add ccree binding
From: Gilad Ben-Yossef @ 2018-05-31 11:55 UTC (permalink / raw)
  To: Simon Horman
  Cc: Magnus Damm, Rob Herring, Mark Rutland, Catalin Marinas,
	Will Deacon, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
	Herbert Xu, David S. Miller, Ofir Drang, Linux-Renesas,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Linux ARM, Linux kernel mailing list, linux-clk,
	Linux Crypto Mailing List
In-Reply-To: <20180529161936.prhp4oikzamr6u3n@verge.net.au>

On Tue, May 29, 2018 at 7:19 PM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, May 24, 2018 at 03:19:10PM +0100, Gilad Ben-Yossef wrote:
>> Add bindings for CryptoCell instance in the SoC.
>>
>> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>
> In so far as I can review the details of this (which is not much) this
> looks fine to me. I am, however, a little unclear in when it should be
> accepted.

Since Herbert Xu ACKed the driver changes, I would say the only gating
commit is Geert's CR clock patch.
If that one is in, than I would say this one should go in as well.

Thanks,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

^ 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