* [RFC PATCH v2 0/7] mux controller abstraction and iio/i2c muxes
From: Peter Rosin @ 2016-11-17 21:48 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Wolfram Sang, Rob Herring, Mark Rutland,
Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Arnd Bergmann, Greg Kroah-Hartman,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA
Hi!
This is work in progress, I'm asking for early feedback.
The code depends on the _available work in iio which can
be found in linux-next.
v1 -> v2 changes
- fixup export of mux_control_put reported by kbuild
- drop devicetree iio-ext-info property as noted by Lars-Peter,
and replace the functionality by exposing all ext_info
attributes of the parent channel for each of the muxed
channels. A cache on top of that and each muxed channel
gets its own view of the ext_info of the parent channel.
- implement idle-state for muxes
- clear out the cache on failure in order to force a mux
update on the following use
- cleanup the probe of i2c-mux-simple driver
- fix a bug in the i2c-mux-simple driver, where failure in
the selection of the mux caused a deadlock when the mux
was later unconditionally deselected.
I have a piece of hardware that is using the same 3 GPIO pins
to control four 8-way muxes. Three of them control ADC lines
to an ADS1015 chip with an iio driver, and the last one
controls the SDA line of an i2c bus. We have some deployed
code to handle this, but you do not want to see it or ever
hear about it. I'm not sure why I even mention it. Anyway,
the situation has nagged me to no end for quite some time.
So, after first getting more intimate with the i2c muxing code
and later discovering the drivers/iio/inkern.c file and
writing a couple of drivers making use of it, I came up with
what I think is an acceptable solution; add a generic mux
controller driver that is shared between all instances, and
combine that with an iio mux driver and a new generic i2c mux
driver. The new i2c mux I called "simple" since it is only
hooking the i2c muxing and the new mux controller (much like
the alsa simple card driver does for ASoC).
My initial (private) version didn't add "mux" as a new bus,
but I couldn't get decent type-checking and nice devicetree
integration with that. It does however feel a bit rich to
add a new bus for something as small as mux controllers?
One thing that I would like to do, but don't see a solution
for, is to move the mux control code that is present in
various drivers in drivers/i2c/muxes to this new minimalistic
muxing subsystem, thus converting all present i2c muxes (but
perhaps not gates and arbitrators) to be i2c-mux-simple muxes.
I'm using an rwsem to lock a mux, but that isn't really a
perfect fit. Is there a better locking primitive that I don't
know about that fits better? I had a mutex at one point, but
that didn't allow any concurrent accesses at all. At least
the rwsem allows concurrent access as long as all users
agree on the mux state, but I suspect that the rwsem will
degrade to the mutex situation pretty quickly if there is
any contention.
Also, the "mux" name feels a bit ambitious, there are many muxes
in the world, and this tiny bit of code is probably not good
enough to be a nice fit for all...
This is all very fresh code and only lightly tested, but it
feels very promising! Now, go ahead and rip this to pieces...
Cheers,
Peter
Peter Rosin (7):
dt-bindings: document devicetree bindings for mux-gpio
misc: minimal mux subsystem and gpio-based mux controller
iio: inkern: api for manipulating ext_info of iio channels
dt-bindings: iio: iio-mux: document iio-mux bindings
iio: multiplexer: new iio category and iio-mux driver
dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings
i2c: i2c-mux-simple: new driver
.../devicetree/bindings/i2c/i2c-mux-simple.txt | 91 +++++
.../bindings/iio/multiplexer/iio-mux.txt | 49 +++
.../devicetree/bindings/misc/mux-gpio.txt | 79 ++++
drivers/i2c/muxes/Kconfig | 12 +
drivers/i2c/muxes/Makefile | 1 +
drivers/i2c/muxes/i2c-mux-simple.c | 168 ++++++++
drivers/iio/Kconfig | 1 +
drivers/iio/Makefile | 1 +
drivers/iio/inkern.c | 55 +++
drivers/iio/multiplexer/Kconfig | 17 +
drivers/iio/multiplexer/Makefile | 6 +
drivers/iio/multiplexer/iio-mux.c | 444 +++++++++++++++++++++
drivers/misc/Kconfig | 6 +
drivers/misc/Makefile | 2 +
drivers/misc/mux-core.c | 299 ++++++++++++++
drivers/misc/mux-gpio.c | 115 ++++++
include/linux/iio/consumer.h | 6 +
include/linux/mux.h | 53 +++
18 files changed, 1405 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt
create mode 100644 Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
create mode 100644 Documentation/devicetree/bindings/misc/mux-gpio.txt
create mode 100644 drivers/i2c/muxes/i2c-mux-simple.c
create mode 100644 drivers/iio/multiplexer/Kconfig
create mode 100644 drivers/iio/multiplexer/Makefile
create mode 100644 drivers/iio/multiplexer/iio-mux.c
create mode 100644 drivers/misc/mux-core.c
create mode 100644 drivers/misc/mux-gpio.c
create mode 100644 include/linux/mux.h
--
2.1.4
--
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] devicetree/bindings: display: Add bindings for LVDS panels
From: Laurent Pinchart @ 2016-11-17 21:41 UTC (permalink / raw)
To: dri-devel
Cc: Rob Herring, devicetree@vger.kernel.org, Laurent Pinchart,
open list:MEDIA DRIVERS FOR RENESAS - FCP, Tomi Valkeinen,
linux-media@vger.kernel.org
In-Reply-To: <CAL_JsqKPWifCvwSxOa-m7WB-f13Y4n96Q895fDMx78YhBxWo_g@mail.gmail.com>
Hi Rob,
On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
> On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchartwrote:
> > On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
> >> On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
> >>> LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> >>> Multiple incompatible data link layers have been used over time to
> >>> transmit image data to LVDS panels. This binding supports display
> >>> panels compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
> >>> specifications.
> >>>
> >>> Signed-off-by: Laurent Pinchart
> >>> <laurent.pinchart+renesas@ideasonboard.com>
> >>> ---
> >>>
> >>> .../bindings/display/panel/panel-lvds.txt | 119 +++++++++++++
> >>> 1 file changed, 119 insertions(+)
> >>> create mode 100644
> >>> Documentation/devicetree/bindings/display/panel/panel-lvds.txt>
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> >>> b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt new
> >>> file
> >>> mode 100644
> >>> index 000000000000..250861f2673e
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> >>> @@ -0,0 +1,119 @@
> >>> +Generic LVDS Panel
> >>> +==================
> >>> +
> >>> +LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> >>> Multiple
> >>> +incompatible data link layers have been used over time to transmit
> >>> image data
> >>> +to LVDS panels. This bindings supports display panels compatible with
> >>> the
> >>> +following specifications.
> >>> +
> >>> +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
> >>> February
> >>> +1999 (Version 1.0), Japan Electronic Industry Development Association
> >>> (JEIDA)
> >>> +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
> >>> +Semiconductor
> >>> +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0),
> >>> Video
> >>> +Electronics Standards Association (VESA)
> >>> +
> >>> +Device compatible with those specifications have been marketed under
> >>> the
> >>> +FPD-Link and FlatLink brands.
> >>> +
> >>> +
> >>> +Required properties:
> >>> +- compatible: shall contain "panel-lvds"
> >>
> >> Maybe as a fallback, but on its own, no way.
> >
> > Which brings an interesting question: when designing generic DT bindings,
> > what's the rule regarding
>
> Call it "simple" so I can easily NAK it. :)
>
> Define a generic structure, not a single binding trying to serve all.
>
> >>> +- width-mm: panel display width in millimeters
> >>> +- height-mm: panel display height in millimeters
> >>
> >> This is already documented for all panels IIRC.
> >
> > Note that this DT binding has nothing to do with the simple-panel binding.
> > It is instead similar to the panel-dpi and panel-dsi-cm bindings (which
> > currently don't but should specify the panel size in DT). The LVDS panel
> > driver will *not* include any panel-specific information such as size or
> > timings, these are specified in DT.
>
> The panel bindings aren't really different. The biggest difference was
> location in the tree, but we now generally allow panels to be either a
> child of the LCD controller or connected with OF graph. We probably
> need to work on restructuring the panel bindings a bit. We should have
> an inheritance with a base panel binding of things like size, label,
> graph, backlight, etc, then perhaps an interface specific bindings for
> LVDS, DSI, and parallel, then a panel specific binding. With this the
> panel specific binding is typically just a compatible string and which
> inherited properties apply to it.
>
> >>> +- data-mapping: the color signals mapping order, "jeida-18",
> >>> "jeida-24"
> >>> + or "vesa-24"
> >>
> >> Maybe this should be part of the compatible.
> >
> > I've thought about it, but given that some panels support selecting
> > between multiple modes (through a mode pin that is usually hardwired), I
> > believe a separate DT property makes sense.
>
> Okay.
>
> > Furthermore, LVDS data organization is controlled by the combination of
> > both data-mapping and data-mirror. It makes little sense from my point of
> > view to handle one as part of the compatible string and the other one as
> > a separate property.
> >
> >>> +Optional properties:
> >>> +- label: a symbolic name for the panel
> >>
> >> Could be for any panel or display connector.
> >
> > Yes, but I'm not sure to understand how that's relevant :-)
>
> Meaning it should be a common property.
>
> >>> +- avdd-supply: reference to the regulator that powers the panel
> >>> analog supply
> >>> +- dvdd-supply: reference to the regulator that powers the panel
> >>> digital supply
> >>
> >> Which one has to be powered on first, what voltage, and with what time
> >> in between? This is why "generic" or "simple" bindings don't work.
> >
> > The above-mentioned specifications also define connectors, pinouts and
> > power supplies, but many LVDS panels compatible with the LVDS physical
> > and data layers use a different connector with small differences in power
> > supplies.
> >
> > I believe the voltage is irrelevant here, it doesn't need to be controlled
> > by the operating system. Power supplies order and timing is relevant,
> > I'll investigate the level of differences between panels. I'm also fine
> > with dropping those properties for now.
>
> Whether you have control of the supplies is dependent on the board.
> Dropping them is just puts us in the simple binding trap. The simple
> bindings start out that way and then people keep adding to them.
>
> >>> +- data-mirror: if set, reverse the bit order on all data lanes (6 to 0
> >>> instead
> >>> + of 0 to 6)
>
> On this one, make the name describe the order. "mirror" requires that
> I know what is normal ordering. Perhaps "data-msb-first".
The normal order is defined just below in the same document, and actually
transmits bits with MSB first (roughly). The bit ordering in LVDS is a bit
messed up, I've tried to follow the specs as much as possible for these
bindings. Data mirroring isn't defined in any spec I've found but is
implemented by some devices that got the spec wrong :-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/2] of: base: add support to get machine model name
From: Frank Rowand @ 2016-11-17 21:00 UTC (permalink / raw)
To: Sudeep Holla, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479396775-32033-1-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
On 11/17/16 07:32, Sudeep Holla wrote:
> Currently platforms/drivers needing to get the machine model name are
> replicating the same snippet of code. In some case, the OF reference
> counting is either missing or incorrect.
>
> This patch adds support to read the machine model name either using
> the "model" or the "compatible" property in the device tree root node
> to the core OF/DT code.
>
> This can be used to remove all the duplicate code snippets doing exactly
> same thing later.
I find five instances of reading only property "model":
arch/arm/mach-imx/cpu.c
arch/arm/mach-mxs/mach-mxs.c
arch/c6x/kernel/setup.c
arch/mips/cavium-octeon/setup.c
arch/sh/boards/of-generic.c
I find one instance of reading property "model", then if
that does not exist, property "compatible":
arch/mips/generic/proc.c
The proposed patch matches the code used in one place, and thus
current usage does not match the patch description.
Is my search bad? Are you planning to add additional instances
of reading "model" then "compatible"?
-Frank
>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> ---
> drivers/of/base.c | 32 ++++++++++++++++++++++++++++++++
> include/linux/of.h | 6 ++++++
> 2 files changed, 38 insertions(+)
>
> Hi Rob,
>
> It would be good if we can target this for v4.10, so that we have no
> dependencies to push PATCH 2/2 in v4.11
>
> Regards,
> Sudeep
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index a0bccb54a9bd..0810c5ecf1aa 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -546,6 +546,38 @@ int of_machine_is_compatible(const char *compat)
> EXPORT_SYMBOL(of_machine_is_compatible);
>
> /**
> + * of_machine_get_model_name - Find and read the model name or the compatible
> + * value for the machine.
> + * @model: pointer to null terminated return string, modified only if
> + * return value is 0.
> + *
> + * Returns a string containing either the model name or the compatible value
> + * of the machine if found, else return error.
> + *
> + * Search for a machine model name or the compatible if model name is missing
> + * in a device tree node and retrieve a null terminated string value (pointer
> + * to data, not a copy). Returns 0 on success, -EINVAL if root of the device
> + * tree is not found and other error returned by of_property_read_string on
> + * failure.
> + */
> +int of_machine_get_model_name(const char **model)
> +{
> + int error;
> +
> + if (!of_node_get(of_root))
> + return -EINVAL;
> +
> + error = of_property_read_string(of_root, "model", model);
> + if (error)
> + error = of_property_read_string_index(of_root, "compatible",
> + 0, model);
> + of_node_put(of_root);
> +
> + return error;
> +}
> +EXPORT_SYMBOL(of_machine_get_model_name);
> +
> +/**
> * __of_device_is_available - check if a device is available for use
> *
> * @device: Node to check for availability, with locks already held
> diff --git a/include/linux/of.h b/include/linux/of.h
> index d72f01009297..13fc66531f1b 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -367,6 +367,7 @@ extern int of_alias_get_id(struct device_node *np, const char *stem);
> extern int of_alias_get_highest_id(const char *stem);
>
> extern int of_machine_is_compatible(const char *compat);
> +extern int of_machine_get_model_name(const char **model);
>
> extern int of_add_property(struct device_node *np, struct property *prop);
> extern int of_remove_property(struct device_node *np, struct property *prop);
> @@ -788,6 +789,11 @@ static inline int of_machine_is_compatible(const char *compat)
> return 0;
> }
>
> +static inline int of_machine_get_model_name(const char **model)
> +{
> + return -EINVAL;
> +}
> +
> static inline bool of_console_check(const struct device_node *dn, const char *name, int index)
> {
> return false;
> --
> 2.7.4
>
>
--
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] ARM: dts: sunxi: Explicitly enable pull-ups for MMC pins
From: klaus.goger @ 2016-11-17 20:57 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: devicetree, Linus Walleij, linux-kernel, linux-sunxi,
Maxime Ripard, linux-arm-kernel
In-Reply-To: <20161117093438.17988-1-wens@csie.org>
On 2016-11-17 10:34, Chen-Yu Tsai wrote:
> Given that MMC starts in open-drain mode and the pull-ups are required,
> it's best to enable it for all the pin settings.
It's even more complicated than that with MMC. It starts in open-drain
mode for
CMD during initialization but changes to push-pull afterwards. The card
has
internal pull-ups to prevent bus floating during setup and will disable
them
after switching to 4bit mode (or 8bit for eMMC when available).
But even after switching to push-pull drivers there are states the bus
would
float and pull ups have to ensure a high level on the bus.
See JESD84-A441 chapter 7.15 ff as reference.
The difference between the P-bit and Z-bit is that a P-bit is actively
driven
to HIGH by the card respectively host output driver, while Z-bit is
driven to
(respectively kept) HIGH by the pull-up resistors Rcmd respectively
Rdat.
Enabling the pull ups on the CPU would be the right choice considering
that
most boards will not have external pull-ups. Even if they would have
one,
adding the internal in parallel would work in almost all cases and the
increase in power consumption would be negligible.
Cheers,
Klaus
^ permalink raw reply
* [PATCH v3 1/4] Documentation: devictree: dwc2: Add AHB burst binding
From: John Youn @ 2016-11-17 20:52 UTC (permalink / raw)
To: John Youn, Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland
Cc: Christian Lamparter, Stefan Wahren
In-Reply-To: <cover.1479415762.git.johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Add the "snps,ahb-burst" property which controls the burst type to
perform on the AHB bus as a master in internal DMA mode.
Some platforms may see better or worse performance based on this
value. The HAPS platform is one example where all INCRx have worse
performance than INCR.
Other platforms (such as the Canyonlands board) report that the default
value causes system hangs.
Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Cc: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
Documentation/devicetree/bindings/usb/dwc2.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
index 6c7c2bce..9e7b4b4 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -26,6 +26,8 @@ Optional properties:
Refer to phy/phy-bindings.txt for generic phy consumer properties
- dr_mode: shall be one of "host", "peripheral" and "otg"
Refer to usb/generic.txt
+- snps,ahb-burst: specifies the ahb burst length. Valid arguments are:
+ "SINGLE", "INCR", "INCR4", "INCR8", "INCR16". Defaults to "INCR4".
- g-rx-fifo-size: size of rx fifo size in gadget mode.
- g-np-tx-fifo-size: size of non-periodic tx fifo size in gadget mode.
- g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0) in gadget mode.
--
2.10.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 0/4] usb: dwc2: Add AHB burst configuration
From: John Youn @ 2016-11-17 20:52 UTC (permalink / raw)
To: John Youn, Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland
Cc: Christian Lamparter, Stefan Wahren
This series adds a binding for AHB burst, reads it in, and configures
the controller for the specified burst type.
Tested on HAPS platform with DWC_hsotg IP version 3.30a.
v3:
* Split out binding documentation
* Squash bcm2835 comment with binding implementation
* Add warning for bcm2835
v2:
* Don't remove the bcm2835 ahbcfg param and document why.
John Youn (4):
Documentation: devictree: dwc2: Add AHB burst binding
usb: dwc2: Read in the AHB burst property
usb: dwc2: Use the ahb_burst param
usb: dwc2: pci: Add AHB burst property for HAPS
Documentation/devicetree/bindings/usb/dwc2.txt | 2 +
drivers/usb/dwc2/core.h | 9 +++
drivers/usb/dwc2/gadget.c | 2 +-
drivers/usb/dwc2/hcd.c | 8 +--
drivers/usb/dwc2/params.c | 79 ++++++++++++++++++++++----
drivers/usb/dwc2/pci.c | 1 +
6 files changed, 85 insertions(+), 16 deletions(-)
--
2.10.0
--
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
* [PATCH v3 0/4] usb: dwc2: Add AHB burst configuration
From: John Youn @ 2016-11-17 20:52 UTC (permalink / raw)
To: John Youn, Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland
Cc: Christian Lamparter, Stefan Wahren
This series adds a binding for AHB burst, reads it in, and configures
the controller for the specified burst type.
Tested on HAPS platform with DWC_hsotg IP version 3.30a.
v3:
* Split out binding documentation
* Squash bcm2835 comment with binding implementation
* Add warning for bcm2835
v2:
* Don't remove the bcm2835 ahbcfg param and document why.
John Youn (4):
Documentation: devictree: dwc2: Add AHB burst binding
usb: dwc2: Read in the AHB burst property
usb: dwc2: Use the ahb_burst param
usb: dwc2: pci: Add AHB burst property for HAPS
Documentation/devicetree/bindings/usb/dwc2.txt | 2 +
drivers/usb/dwc2/core.h | 9 +++
drivers/usb/dwc2/gadget.c | 2 +-
drivers/usb/dwc2/hcd.c | 8 +--
drivers/usb/dwc2/params.c | 79 ++++++++++++++++++++++----
drivers/usb/dwc2/pci.c | 1 +
6 files changed, 85 insertions(+), 16 deletions(-)
--
2.10.0
--
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] ARM: dts: sunxi: Explicitly enable pull-ups for MMC pins
From: Maxime Ripard @ 2016-11-17 20:40 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Linus Walleij, Klaus Goger, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161117093438.17988-1-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 810 bytes --]
On Thu, Nov 17, 2016 at 05:34:38PM +0800, Chen-Yu Tsai wrote:
> In the past, all the MMC pins had
>
> allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>
> which was actually a no-op. We were relying on U-boot to set the bias
> pull up for us. These properties were removed as part of the fix up to
> actually support no bias on the pins. During the transition some boards
> experienced regular MMC time-outs during normal operation, while others
> completely failed to initialize the SD card.
>
> Given that MMC starts in open-drain mode and the pull-ups are required,
> it's best to enable it for all the pin settings.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Applied, thanks.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v4 2/2] ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA bridge
From: Maxime Ripard @ 2016-11-17 20:27 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: David Airlie, Archit Taneja,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161116154232.872-3-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
On Wed, Nov 16, 2016 at 11:42:32PM +0800, Chen-Yu Tsai wrote:
> The Hummingbird A31 board has a VGA DAC which converts RGB output
> from the LCD interface to VGA analog signals.
>
> Add nodes for the VGA DAC, its power supply, and enable this part
> of the display pipeline.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Maxime Ripard @ 2016-11-17 20:24 UTC (permalink / raw)
To: Hans de Goede
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree
In-Reply-To: <20161116131508.12541-1-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 792 bytes --]
On Wed, Nov 16, 2016 at 02:15:08PM +0100, Hans de Goede wrote:
> Just like on sun8i all sun5i tablets use the same interrupt and power
> gpios for their touchscreens. I've checked all known a13 fex files and
> only the UTOO P66 uses a different gpio for the interrupt.
>
> Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
> fills in the necessary gpios to avoid duplication in the tablet dts files,
> just like we do in sun8i-reference-design-tablet.dtsi.
>
> This will make future patches adding touchscreen nodes to a13 tablets
> simpler.
>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
From: Jyri Sarha @ 2016-11-17 20:16 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, bcousson, khilman, dri-devel, bgolaszewski,
tomi.valkeinen
In-Reply-To: <12647548.AgjiIO6s4p@avalon>
On 11/17/16 19:20, Laurent Pinchart wrote:
>> > Oops, forgot to handle the return values. This is how I fixed it:
>> > static int __init tfp410_module_init(void)
>> > {
>> > int ret;
>> >
>> > ret = i2c_add_driver(&tfp410_i2c_driver);
>> > if (ret)
>> > return ret;
>> >
>> > ret = platform_driver_register(&tfp410_platform_driver);
>> > if (ret)
>> > i2c_del_driver(&tfp410_i2c_driver);
>> >
>> > return ret;
>> > }
> If registration of one of the two drivers fail, wouldn't it make sense to
> still continue (probably with an error message) to avoid breaking the other
> one ?
>
Oh, good point. I fix that too. Anything else about this series? I'd
like to send a pull request for 4.10 soon.
>>> > > +
>>> > > + return 0;
>>> > > +}
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH] ARM: dts: am335x-boneblack: Add blue-and-red-wiring -property to LCDC node
From: Jyri Sarha @ 2016-11-17 20:13 UTC (permalink / raw)
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, tony-4v6yS6AI5VpBDgjK7y7TUQ
Cc: tomi.valkeinen-l0cyMroinI0, Jyri Sarha
Add blue-and-red-wiring -property to LCDC node. Also adds comments on
how to get support 24 bit RGB mode. After this patch am335x-boneblack
support RGB565, BGR888, and XBGR8888 color formats. See details in
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt.
The BBB has straight color wiring from am335x to tda19988, however the
tda19988 can be configured to cross the blue and red wires. The
comments show how to do that with video-ports property of tda19988
node and how to tell LCDC that blue and red wires are crossed, with
blue-and-red-wiring LCDC node property. This changes supported color
formats from 16 bit RGB and 24 bit BGR to 16 bit BGR and 24 bit RGB.
Signed-off-by: Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
Hi Tony,
Could you pick this for 4.10. We left it out form 4.9 to avoid
conflict with beaglebone-back hdmi audio dts patches that slipped in
trough drm branch.
Cheers,
Jyri
arch/arm/boot/dts/am335x-boneblack.dts | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
index 6bbb1fe..db00d8e 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -79,6 +79,14 @@
&lcdc {
status = "okay";
+
+ /* If you want to get 24 bit RGB and 16 BGR mode instead of
+ * current 16 bit RGB and 24 BGR modes, set the propety
+ * below to "crossed" and uncomment the video-ports -property
+ * in tda19988 node.
+ */
+ blue-and-red-wiring = "straight";
+
port {
lcdc_0: endpoint@0 {
remote-endpoint = <&hdmi_0>;
@@ -95,6 +103,9 @@
pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
+ /* Convert 24bit BGR to RGB, e.g. cross red and blue wiring */
+ /* video-ports = <0x234501>; */
+
#sound-dai-cells = <0>;
audio-ports = < TDA998x_I2S 0x03>;
--
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 related
* Re: [PATCH v2 3/3] hwmon: ltc2990: support all measurement modes
From: Mike Looijmans @ 2016-11-17 19:52 UTC (permalink / raw)
To: Guenter Roeck
Cc: Tom Levens, jdelvare, robh+dt, mark.rutland, linux-kernel,
linux-hwmon, devicetree
In-Reply-To: <20161117185654.GA19338@roeck-us.net>
On 17-11-2016 19:56, Guenter Roeck wrote:
> On Thu, Nov 17, 2016 at 06:40:17PM +0100, Mike Looijmans wrote:
>> On 17-11-16 17:56, Guenter Roeck wrote:
>>> On 11/17/2016 04:10 AM, Tom Levens wrote:
>>>> Updated version of the ltc2990 driver which supports all measurement
>>>> modes available in the chip. The mode can be set through a devicetree
>>>> attribute.
>>>
> [ ... ]
>
>>>>
>>>> static int ltc2990_i2c_probe(struct i2c_client *i2c,
>>>> const struct i2c_device_id *id)
>>>> {
>>>> int ret;
>>>> struct device *hwmon_dev;
>>>> + struct ltc2990_data *data;
>>>> + struct device_node *of_node = i2c->dev.of_node;
>>>>
>>>> if (!i2c_check_functionality(i2c->adapter,
>>>> I2C_FUNC_SMBUS_BYTE_DATA |
>>>> I2C_FUNC_SMBUS_WORD_DATA))
>>>> return -ENODEV;
>>>>
>>>> - /* Setup continuous mode, current monitor */
>>>> + data = devm_kzalloc(&i2c->dev, sizeof(struct ltc2990_data),
>>>> GFP_KERNEL);
>>>> + if (unlikely(!data))
>>>> + return -ENOMEM;
>>>> + data->i2c = i2c;
>>>> +
>>>> + if (!of_node || of_property_read_u32(of_node, "lltc,mode",
>>>> &data->mode))
>>>> + data->mode = LTC2990_CONTROL_MODE_DEFAULT;
>>>
>>> Iam arguing with myself if we should still do this or if we should read
>>> the mode
>> >from the chip instead if it isn't provided (after all, it may have been
>>> initialized
>>> by the BIOS/ROMMON).
>>
>> I think the mode should be explicitly set, without default. There's no way
>> to tell whether the BIOS or bootloader has really set it up or whether the
>> chip is just reporting whatever it happened to default to. And given the
>> chip's function, it's unlikely a bootloader would want to initialize it.
>>
> Unlikely but possible. Even if we all agree that the chip should be configured
> by the driver, I don't like imposing that view on everyone else.
>
>> My advice would be to make it a required property. If not set, display an
>> error and bail out.
>>
> It is not that easy, unfortunately. It also has to work on a non-devicetree
> system. I would not object to making the property mandatory, but we would
> still need to provide non-DT support.
>
> My "use case" for taking the current mode from the chip if not specified
> is that it would enable me to run a module test with all modes. I consider
> this extremely valuable.
Good point.
The chip defaults to measuring internal temperature only, and the mode
defaults to "0".
Choosing a mode that doesn't match the actual circuitry could be bad for
the chip or the board (though unlikely, it'll probably just be useless)
since it will actively drive some of the inputs in the temperature modes
(which is default for V3/V4 pins).
Instead of failing, one could choose to set the default mode to "7",
which just measures the 4 voltages, which would be a harmless mode in
all cases.
As a way to let a bootloader set things up, I think it would be a good
check to see if CONTROL register bits 4:3 are set. If "00", the chip is
not acquiring data at all, and probably needs configuration still. In
that case, the mode must be provided by the devicetree (or the default "7").
If bits 4:3 are "11", it has already been set up to measure its inputs,
and it's okay to continue doing just that and use the current value of
2:0 register as default mode (if the devicetree didn't specify any mode
at all).
The reason I wanted the property to be mandatory is to trigger users
like me (probably I'm the only other user so far) to update their
devicetree. But I'd notice quickly enough if it defaults to something
else. So that's not very compelling.
>>> Mike, would that break your application, or can you specify the mode in
>>> devicetree ?
>>
>> I'm fine with specifying this in the devicetree. It will break things for
>> me, but I've been warned and willing to bow for the greater good :)
>>
> I should have asked if your system uses devicetree. If it does, the problem
> should be easy to fix for you. If not, we'll need to find a solution
> for your use case.
I'm using devicetree. I planned to 'mainline' the boards some time this
year...
>
> Thanks,
> Guenter
>
--
Mike Looijmans
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
^ permalink raw reply
* Re: [PATCH] ARM: dts: qcom: Add apq8064 CoreSight components
From: Mathieu Poirier @ 2016-11-17 19:04 UTC (permalink / raw)
To: Georgi Djakov
Cc: andy.gross-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A,
iivanov.xz-Re5JQEeQqe8AvxtiuMwx3w,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161117153609.11705-1-georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Nov 17, 2016 at 05:36:09PM +0200, Georgi Djakov wrote:
> From: "Ivan T. Ivanov" <ivan.ivanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> Add initial set of CoreSight components found on Qualcomm's
> 8064 chipset.
>
> Signed-off-by: Ivan T. Ivanov <ivan.ivanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Georgi Djakov <georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> arch/arm/boot/dts/qcom-apq8064-coresight.dtsi | 196 ++++++++++++++++++++++++++
> arch/arm/boot/dts/qcom-apq8064.dtsi | 11 +-
> 2 files changed, 203 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm/boot/dts/qcom-apq8064-coresight.dtsi
>
> diff --git a/arch/arm/boot/dts/qcom-apq8064-coresight.dtsi b/arch/arm/boot/dts/qcom-apq8064-coresight.dtsi
> new file mode 100644
> index 000000000000..9395fddb1bf0
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-apq8064-coresight.dtsi
> @@ -0,0 +1,196 @@
> +/*
> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +&soc {
> +
> + etb@1a01000 {
> + compatible = "coresight-etb10", "arm,primecell";
> + reg = <0x1a01000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + port {
> + etb_in: endpoint {
> + slave-mode;
> + remote-endpoint = <&replicator_out0>;
> + };
> + };
> + };
> +
> + tpiu@1a03000 {
> + compatible = "arm,coresight-tpiu", "arm,primecell";
> + reg = <0x1a03000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + port {
> + tpiu_in: endpoint {
> + slave-mode;
> + remote-endpoint = <&replicator_out1>;
> + };
> + };
> + };
> +
> + replicator {
> + compatible = "arm,coresight-replicator";
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + replicator_out0: endpoint {
> + remote-endpoint = <&etb_in>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + replicator_out1: endpoint {
> + remote-endpoint = <&tpiu_in>;
> + };
> + };
> + port@2 {
> + reg = <0>;
> + replicator_in: endpoint {
> + slave-mode;
> + remote-endpoint = <&funnel_out>;
> + };
> + };
> + };
> + };
> +
> + funnel@1a04000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0x1a04000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /*
> + * Not described input ports:
> + * 2 - connected to STM component
> + * 3 - not-connected
> + * 6 - not-connected
> + * 7 - not-connected
> + */
> + port@0 {
> + reg = <0>;
> + funnel_in0: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm0_out>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + funnel_in1: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm1_out>;
> + };
> + };
> + port@4 {
> + reg = <4>;
> + funnel_in4: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm2_out>;
> + };
> + };
> + port@5 {
> + reg = <5>;
> + funnel_in5: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm3_out>;
> + };
> + };
> + port@8 {
> + reg = <0>;
> + funnel_out: endpoint {
> + remote-endpoint = <&replicator_in>;
> + };
> + };
> + };
> + };
> +
> + etm@1a1c000 {
> + compatible = "arm,coresight-etm3x", "arm,primecell";
> + reg = <0x1a1c000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&CPU0>;
> +
> + port {
> + etm0_out: endpoint {
> + remote-endpoint = <&funnel_in0>;
> + };
> + };
> + };
> +
> + etm@1a1d000 {
> + compatible = "arm,coresight-etm3x", "arm,primecell";
> + reg = <0x1a1d000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&CPU1>;
> +
> + port {
> + etm1_out: endpoint {
> + remote-endpoint = <&funnel_in1>;
> + };
> + };
> + };
> +
> + etm@1a1e000 {
> + compatible = "arm,coresight-etm3x", "arm,primecell";
> + reg = <0x1a1e000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&CPU2>;
> +
> + port {
> + etm2_out: endpoint {
> + remote-endpoint = <&funnel_in4>;
> + };
> + };
> + };
> +
> + etm@1a1f000 {
> + compatible = "arm,coresight-etm3x", "arm,primecell";
> + reg = <0x1a1f000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>;
> + clock-names = "apb_pclk";
> +
> + cpu = <&CPU3>;
> +
> + port {
> + etm3_out: endpoint {
> + remote-endpoint = <&funnel_in5>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 268bd470c865..18469c632e2f 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -4,6 +4,7 @@
> #include <dt-bindings/clock/qcom,gcc-msm8960.h>
> #include <dt-bindings/reset/qcom,gcc-msm8960.h>
> #include <dt-bindings/clock/qcom,mmcc-msm8960.h>
> +#include <dt-bindings/clock/qcom,rpmcc.h>
> #include <dt-bindings/soc/qcom,gsbi.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> @@ -27,7 +28,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> - cpu@0 {
> + CPU0: cpu@0 {
> compatible = "qcom,krait";
> enable-method = "qcom,kpss-acc-v1";
> device_type = "cpu";
> @@ -38,7 +39,7 @@
> cpu-idle-states = <&CPU_SPC>;
> };
>
> - cpu@1 {
> + CPU1: cpu@1 {
> compatible = "qcom,krait";
> enable-method = "qcom,kpss-acc-v1";
> device_type = "cpu";
> @@ -49,7 +50,7 @@
> cpu-idle-states = <&CPU_SPC>;
> };
>
> - cpu@2 {
> + CPU2: cpu@2 {
> compatible = "qcom,krait";
> enable-method = "qcom,kpss-acc-v1";
> device_type = "cpu";
> @@ -60,7 +61,7 @@
> cpu-idle-states = <&CPU_SPC>;
> };
>
> - cpu@3 {
> + CPU3: cpu@3 {
> compatible = "qcom,krait";
> enable-method = "qcom,kpss-acc-v1";
> device_type = "cpu";
> @@ -1418,4 +1419,6 @@
> };
> };
> };
> +
> +#include "qcom-apq8064-coresight.dtsi"
> #include "qcom-apq8064-pins.dtsi"
Acked-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
--
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 v4] arm64: dts: qcom: Add msm8916 CoreSight components
From: Mathieu Poirier @ 2016-11-17 18:59 UTC (permalink / raw)
To: Georgi Djakov
Cc: andy.gross-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A,
iivanov.xz-Re5JQEeQqe8AvxtiuMwx3w,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161117153522.11630-1-georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Nov 17, 2016 at 05:35:22PM +0200, Georgi Djakov wrote:
> From: "Ivan T. Ivanov" <ivan.ivanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> Add initial set of CoreSight components found on Qualcomm's 8x16 chipset.
Hello Georgi,
Could you add a better desccription for the SoC? To me "8x16" doesn't
say much.
With that change:
Acked-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> Signed-off-by: Ivan T. Ivanov <ivan.ivanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Georgi Djakov <georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>
> This patch was on hold for some time, as it has a dependency on RPM clocks,
> which is now merged into clk-next.
>
> Changes since v3: (https://lkml.org/lkml/2015/5/11/134)
> * Include msm8916-coresight.dtsi into msm8916.dtsi
>
> Changes since v2: (https://lkml.org/lkml/2015/4/29/242)
> * Added "1x" to "qcom,coresight-replicator" compatible string, to match what
> devicetree bindings documentations says.
>
>
> arch/arm64/boot/dts/qcom/msm8916-coresight.dtsi | 254 ++++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +
> 2 files changed, 256 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/msm8916-coresight.dtsi
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-coresight.dtsi b/arch/arm64/boot/dts/qcom/msm8916-coresight.dtsi
> new file mode 100644
> index 000000000000..900f1f484a0a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8916-coresight.dtsi
> @@ -0,0 +1,254 @@
> +/*
> + * Copyright (c) 2013 - 2015, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +&soc {
> +
> + tpiu@820000 {
> + compatible = "arm,coresight-tpiu", "arm,primecell";
> + reg = <0x820000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + port {
> + tpiu_in: endpoint {
> + slave-mode;
> + remote-endpoint = <&replicator_out1>;
> + };
> + };
> + };
> +
> + funnel@821000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0x821000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /*
> + * Not described input ports:
> + * 0 - connected to Resource and Power Manger CPU ETM
> + * 1 - not-connected
> + * 2 - connected to Modem CPU ETM
> + * 3 - not-connected
> + * 5 - not-connected
> + * 6 - connected trought funnel to Wireless CPU ETM
> + * 7 - connected to STM component
> + */
> + port@4 {
> + reg = <4>;
> + funnel0_in4: endpoint {
> + slave-mode;
> + remote-endpoint = <&funnel1_out>;
> + };
> + };
> + port@8 {
> + reg = <0>;
> + funnel0_out: endpoint {
> + remote-endpoint = <&etf_in>;
> + };
> + };
> + };
> + };
> +
> + replicator@824000 {
> + compatible = "qcom,coresight-replicator1x", "arm,primecell";
> + reg = <0x824000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + replicator_out0: endpoint {
> + remote-endpoint = <&etr_in>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + replicator_out1: endpoint {
> + remote-endpoint = <&tpiu_in>;
> + };
> + };
> + port@2 {
> + reg = <0>;
> + replicator_in: endpoint {
> + slave-mode;
> + remote-endpoint = <&etf_out>;
> + };
> + };
> + };
> + };
> +
> + etf@825000 {
> + compatible = "arm,coresight-tmc", "arm,primecell";
> + reg = <0x825000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + etf_out: endpoint {
> + slave-mode;
> + remote-endpoint = <&funnel0_out>;
> + };
> + };
> + port@1 {
> + reg = <0>;
> + etf_in: endpoint {
> + remote-endpoint = <&replicator_in>;
> + };
> + };
> + };
> + };
> +
> + etr@826000 {
> + compatible = "arm,coresight-tmc", "arm,primecell";
> + reg = <0x826000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + port {
> + etr_in: endpoint {
> + slave-mode;
> + remote-endpoint = <&replicator_out0>;
> + };
> + };
> + };
> +
> + funnel@841000 { /* APSS funnel only 4 inputs are used */
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0x841000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + funnel1_in0: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm0_out>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + funnel1_in1: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm1_out>;
> + };
> + };
> + port@2 {
> + reg = <2>;
> + funnel1_in2: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm2_out>;
> + };
> + };
> + port@3 {
> + reg = <3>;
> + funnel1_in3: endpoint {
> + slave-mode;
> + remote-endpoint = <&etm3_out>;
> + };
> + };
> + port@4 {
> + reg = <0>;
> + funnel1_out: endpoint {
> + remote-endpoint = <&funnel0_in4>;
> + };
> + };
> + };
> + };
> +
> + etm@85c000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0x85c000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + cpu = <&CPU0>;
> +
> + port {
> + etm0_out: endpoint {
> + remote-endpoint = <&funnel1_in0>;
> + };
> + };
> + };
> +
> + etm@85d000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0x85d000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + cpu = <&CPU1>;
> +
> + port {
> + etm1_out: endpoint {
> + remote-endpoint = <&funnel1_in1>;
> + };
> + };
> + };
> +
> + etm@85e000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0x85e000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + cpu = <&CPU2>;
> +
> + port {
> + etm2_out: endpoint {
> + remote-endpoint = <&funnel1_in2>;
> + };
> + };
> + };
> +
> + etm@85f000 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0x85f000 0x1000>;
> +
> + clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + cpu = <&CPU3>;
> +
> + port {
> + etm3_out: endpoint {
> + remote-endpoint = <&funnel1_in3>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 4221b7d2c0ce..bfaeb9364190 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -14,6 +14,7 @@
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/clock/qcom,gcc-msm8916.h>
> #include <dt-bindings/reset/qcom,gcc-msm8916.h>
> +#include <dt-bindings/clock/qcom,rpmcc.h>
>
> / {
> model = "Qualcomm Technologies, Inc. MSM8916";
> @@ -993,4 +994,5 @@
> };
> };
>
> +#include "msm8916-coresight.dtsi"
> #include "msm8916-pins.dtsi"
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/3] hwmon: ltc2990: support all measurement modes
From: Guenter Roeck @ 2016-11-17 18:56 UTC (permalink / raw)
To: Mike Looijmans
Cc: Tom Levens, jdelvare, robh+dt, mark.rutland, linux-kernel,
linux-hwmon, devicetree
In-Reply-To: <582DEB81.6050806@topic.nl>
On Thu, Nov 17, 2016 at 06:40:17PM +0100, Mike Looijmans wrote:
> On 17-11-16 17:56, Guenter Roeck wrote:
> >On 11/17/2016 04:10 AM, Tom Levens wrote:
> >>Updated version of the ltc2990 driver which supports all measurement
> >>modes available in the chip. The mode can be set through a devicetree
> >>attribute.
> >
[ ... ]
> >>
> >> static int ltc2990_i2c_probe(struct i2c_client *i2c,
> >> const struct i2c_device_id *id)
> >> {
> >> int ret;
> >> struct device *hwmon_dev;
> >>+ struct ltc2990_data *data;
> >>+ struct device_node *of_node = i2c->dev.of_node;
> >>
> >> if (!i2c_check_functionality(i2c->adapter,
> >>I2C_FUNC_SMBUS_BYTE_DATA |
> >> I2C_FUNC_SMBUS_WORD_DATA))
> >> return -ENODEV;
> >>
> >>- /* Setup continuous mode, current monitor */
> >>+ data = devm_kzalloc(&i2c->dev, sizeof(struct ltc2990_data),
> >>GFP_KERNEL);
> >>+ if (unlikely(!data))
> >>+ return -ENOMEM;
> >>+ data->i2c = i2c;
> >>+
> >>+ if (!of_node || of_property_read_u32(of_node, "lltc,mode",
> >>&data->mode))
> >>+ data->mode = LTC2990_CONTROL_MODE_DEFAULT;
> >
> >Iam arguing with myself if we should still do this or if we should read
> >the mode
> >from the chip instead if it isn't provided (after all, it may have been
> >initialized
> >by the BIOS/ROMMON).
>
> I think the mode should be explicitly set, without default. There's no way
> to tell whether the BIOS or bootloader has really set it up or whether the
> chip is just reporting whatever it happened to default to. And given the
> chip's function, it's unlikely a bootloader would want to initialize it.
>
Unlikely but possible. Even if we all agree that the chip should be configured
by the driver, I don't like imposing that view on everyone else.
> My advice would be to make it a required property. If not set, display an
> error and bail out.
>
It is not that easy, unfortunately. It also has to work on a non-devicetree
system. I would not object to making the property mandatory, but we would
still need to provide non-DT support.
My "use case" for taking the current mode from the chip if not specified
is that it would enable me to run a module test with all modes. I consider
this extremely valuable.
> >Mike, would that break your application, or can you specify the mode in
> >devicetree ?
>
> I'm fine with specifying this in the devicetree. It will break things for
> me, but I've been warned and willing to bow for the greater good :)
>
I should have asked if your system uses devicetree. If it does, the problem
should be easy to fix for you. If not, we'll need to find a solution
for your use case.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v2 2/4] usb: dwc2: Add binding for AHB burst
From: John Youn @ 2016-11-17 18:54 UTC (permalink / raw)
To: Felipe Balbi, John Youn, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland
Cc: Christian Lamparter, Stefan Wahren
In-Reply-To: <874m36tkgz.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 11/17/2016 3:28 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
>> Add the "snps,ahb-burst" binding and read it in.
>>
>> This property controls which burst type to perform on the AHB bus as a
>> master in internal DMA mode. This overrides the legacy param value,
>> which we need to keep around for now since several platforms use it.
>>
>> Some platforms may see better or worse performance based on this
>> value. The HAPS platform is one example where all INCRx have worse
>> performance than INCR.
>>
>> Other platforms (such as the Canyonlands board) report that the default
>> value causes system hangs.
>>
>> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> Cc: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>
> it's getting rather late for this merge window. I still need an ack by
> Rob or any of the devicetree folks.
>
Sure, no problem if it doesn't make it.
Regards,
John
--
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] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Hans de Goede @ 2016-11-17 18:52 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree
In-Reply-To: <20161117183520.vpyw72mchynpqx7d@lukather>
Hi,
On 17-11-16 19:35, Maxime Ripard wrote:
> Hi Hans,
>
> On Tue, Nov 15, 2016 at 11:12:35AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 14-11-16 21:08, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Sun, Nov 13, 2016 at 08:22:02PM +0100, Hans de Goede wrote:
>>>> Just like on sun8i all sun5i tablets use the same interrupt and power
>>>> gpios for their touchscreens. I've checked all known a13 fex files and
>>>> only the UTOO P66 uses a different gpio for the interrupt.
>>>>
>>>> Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
>>>> fills in the necessary gpios to avoid duplication in the tablet dts files,
>>>> just like we do in sun8i-reference-design-tablet.dtsi.
>>>>
>>>> This will make future patches adding touchscreen nodes to a13 tablets
>>>> simpler.
>>>>
>>>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>> ---
>>>> arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
>>>> .../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
>>>> 2 files changed, 39 insertions(+), 24 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
>>>> index a8b0bcc..3d7ff10 100644
>>>> --- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
>>>> +++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
>>>> @@ -83,22 +83,6 @@
>>>> allwinner,pins = "PG3";
>>>> };
>>>>
>>>> -&i2c1 {
>>>> - icn8318: touchscreen@40 {
>>>> - compatible = "chipone,icn8318";
>>>> - reg = <0x40>;
>>>> - interrupt-parent = <&pio>;
>>>> - interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
>>>> - pinctrl-names = "default";
>>>> - pinctrl-0 = <&ts_wake_pin_p66>;
>>>> - wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
>>>> - touchscreen-size-x = <800>;
>>>> - touchscreen-size-y = <480>;
>>>> - touchscreen-inverted-x;
>>>> - touchscreen-swapped-x-y;
>>>> - };
>>>> -};
>>>> -
>>>> &mmc2 {
>>>> pinctrl-names = "default";
>>>> pinctrl-0 = <&mmc2_pins_a>;
>>>> @@ -121,20 +105,26 @@
>>>> allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>>> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>>>> };
>>>> -
>>>> - ts_wake_pin_p66: ts_wake_pin@0 {
>>>> - allwinner,pins = "PB3";
>>>> - allwinner,function = "gpio_out";
>>>> - allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>>> - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>>> - };
>>>> -
>>>> };
>>>>
>>>> ®_usb0_vbus {
>>>> gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
>>>> };
>>>>
>>>> +&touchscreen {
>>>> + compatible = "chipone,icn8318";
>>>> + reg = <0x40>;
>>>> + /* The P66 uses a different EINT then the reference design */
>>>> + interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
>>>> + /* The icn8318 binding expects wake-gpios instead of power-gpios */
>>>> + wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
>>>> + touchscreen-size-x = <800>;
>>>> + touchscreen-size-y = <480>;
>>>> + touchscreen-inverted-x;
>>>> + touchscreen-swapped-x-y;
>>>> + status = "okay";
>>>> +};
>>>> +
>>>> &uart1 {
>>>> /* The P66 uses the uart pins as gpios */
>>>> status = "disabled";
>>>> diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
>>>> index 20cc940..7af488a 100644
>>>> --- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
>>>> +++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
>>>> @@ -41,6 +41,7 @@
>>>> */
>>>> #include "sunxi-reference-design-tablet.dtsi"
>>>>
>>>> +#include <dt-bindings/interrupt-controller/irq.h>
>>>> #include <dt-bindings/pwm/pwm.h>
>>>>
>>>> / {
>>>> @@ -84,6 +85,23 @@
>>>> };
>>>>
>>>> &i2c1 {
>>>> + /*
>>>> + * The gsl1680 is rated at 400KHz and it will not work reliable at
>>>> + * 100KHz, this has been confirmed on multiple different q8 tablets.
>>>> + * All other devices on this bus are also rated for 400KHz.
>>>> + */
>>>> + clock-frequency = <400000>;
>>>> +
>>>> + touchscreen: touchscreen {
>>>> + interrupt-parent = <&pio>;
>>>> + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&ts_power_pin>;
>>>> + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
>>>> + /* Tablet dts must provide reg and compatible */
>>>> + status = "disabled";
>>>> + };
>>>> +
>>>> pcf8563: rtc@51 {
>>>> compatible = "nxp,pcf8563";
>>>> reg = <0x51>;
>>>> @@ -125,6 +143,13 @@
>>>> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>>>> };
>>>>
>>>> + ts_power_pin: ts_power_pin {
>>>> + allwinner,pins = "PB3";
>>>> + allwinner,function = "gpio_out";
>>>> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>>> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>>> + };
>>>> +
>>>
>>> For the next release, we'll switch to the generic pin mux properties
>>> ("pins" and "function"), and we actually implemented the fact that the
>>> drive and pull properties are optional, so you can drop them both.
>>>
>>> You'll need next + http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/467123.html
>>
>> Ok, before I send a v2 first a question about this, for the touchscreen
>> case I actually need:
>>
>> allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>
>> Because otherwise when the touchscreen controller is powered by a separate
>> regulator and that regulator is off, then it may draw just enough current
>> from its enable pin to be sort-of listening to the i2c bus and mess up
>> that bus.
>>
>> So is this the default, or do we get the power-on default when not
>> specifying these? If it is the power-on default then we do need to
>> specify these, because AFAICT the power-on drive strength typically
>> is 20 mA.
>
> Leaving them out will keep whatever state has been programmed. Putting
> them in the DT will force them to whatever value has been set.
Thanks for the answer, in the mean time I've send a v2 which leaves
them in using the new names (which according to your answer seems to
be the right thing to do).
Regards,
Hans
--
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] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Maxime Ripard @ 2016-11-17 18:35 UTC (permalink / raw)
To: Hans de Goede
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree
In-Reply-To: <0c3a9e9c-d310-c6c3-ae10-1ae9e520963e-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 6182 bytes --]
Hi Hans,
On Tue, Nov 15, 2016 at 11:12:35AM +0100, Hans de Goede wrote:
> Hi,
>
> On 14-11-16 21:08, Maxime Ripard wrote:
> > Hi,
> >
> > On Sun, Nov 13, 2016 at 08:22:02PM +0100, Hans de Goede wrote:
> > > Just like on sun8i all sun5i tablets use the same interrupt and power
> > > gpios for their touchscreens. I've checked all known a13 fex files and
> > > only the UTOO P66 uses a different gpio for the interrupt.
> > >
> > > Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
> > > fills in the necessary gpios to avoid duplication in the tablet dts files,
> > > just like we do in sun8i-reference-design-tablet.dtsi.
> > >
> > > This will make future patches adding touchscreen nodes to a13 tablets
> > > simpler.
> > >
> > > Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > ---
> > > arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
> > > .../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
> > > 2 files changed, 39 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> > > index a8b0bcc..3d7ff10 100644
> > > --- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> > > +++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> > > @@ -83,22 +83,6 @@
> > > allwinner,pins = "PG3";
> > > };
> > >
> > > -&i2c1 {
> > > - icn8318: touchscreen@40 {
> > > - compatible = "chipone,icn8318";
> > > - reg = <0x40>;
> > > - interrupt-parent = <&pio>;
> > > - interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> > > - pinctrl-names = "default";
> > > - pinctrl-0 = <&ts_wake_pin_p66>;
> > > - wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> > > - touchscreen-size-x = <800>;
> > > - touchscreen-size-y = <480>;
> > > - touchscreen-inverted-x;
> > > - touchscreen-swapped-x-y;
> > > - };
> > > -};
> > > -
> > > &mmc2 {
> > > pinctrl-names = "default";
> > > pinctrl-0 = <&mmc2_pins_a>;
> > > @@ -121,20 +105,26 @@
> > > allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> > > allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> > > };
> > > -
> > > - ts_wake_pin_p66: ts_wake_pin@0 {
> > > - allwinner,pins = "PB3";
> > > - allwinner,function = "gpio_out";
> > > - allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> > > - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> > > - };
> > > -
> > > };
> > >
> > > ®_usb0_vbus {
> > > gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
> > > };
> > >
> > > +&touchscreen {
> > > + compatible = "chipone,icn8318";
> > > + reg = <0x40>;
> > > + /* The P66 uses a different EINT then the reference design */
> > > + interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> > > + /* The icn8318 binding expects wake-gpios instead of power-gpios */
> > > + wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> > > + touchscreen-size-x = <800>;
> > > + touchscreen-size-y = <480>;
> > > + touchscreen-inverted-x;
> > > + touchscreen-swapped-x-y;
> > > + status = "okay";
> > > +};
> > > +
> > > &uart1 {
> > > /* The P66 uses the uart pins as gpios */
> > > status = "disabled";
> > > diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> > > index 20cc940..7af488a 100644
> > > --- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> > > +++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> > > @@ -41,6 +41,7 @@
> > > */
> > > #include "sunxi-reference-design-tablet.dtsi"
> > >
> > > +#include <dt-bindings/interrupt-controller/irq.h>
> > > #include <dt-bindings/pwm/pwm.h>
> > >
> > > / {
> > > @@ -84,6 +85,23 @@
> > > };
> > >
> > > &i2c1 {
> > > + /*
> > > + * The gsl1680 is rated at 400KHz and it will not work reliable at
> > > + * 100KHz, this has been confirmed on multiple different q8 tablets.
> > > + * All other devices on this bus are also rated for 400KHz.
> > > + */
> > > + clock-frequency = <400000>;
> > > +
> > > + touchscreen: touchscreen {
> > > + interrupt-parent = <&pio>;
> > > + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&ts_power_pin>;
> > > + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> > > + /* Tablet dts must provide reg and compatible */
> > > + status = "disabled";
> > > + };
> > > +
> > > pcf8563: rtc@51 {
> > > compatible = "nxp,pcf8563";
> > > reg = <0x51>;
> > > @@ -125,6 +143,13 @@
> > > allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> > > };
> > >
> > > + ts_power_pin: ts_power_pin {
> > > + allwinner,pins = "PB3";
> > > + allwinner,function = "gpio_out";
> > > + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> > > + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> > > + };
> > > +
> >
> > For the next release, we'll switch to the generic pin mux properties
> > ("pins" and "function"), and we actually implemented the fact that the
> > drive and pull properties are optional, so you can drop them both.
> >
> > You'll need next + http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/467123.html
>
> Ok, before I send a v2 first a question about this, for the touchscreen
> case I actually need:
>
> allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>
> Because otherwise when the touchscreen controller is powered by a separate
> regulator and that regulator is off, then it may draw just enough current
> from its enable pin to be sort-of listening to the i2c bus and mess up
> that bus.
>
> So is this the default, or do we get the power-on default when not
> specifying these? If it is the power-on default then we do need to
> specify these, because AFAICT the power-on drive strength typically
> is 20 mA.
Leaving them out will keep whatever state has been programmed. Putting
them in the DT will force them to whatever value has been set.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Anand Moon @ 2016-11-17 18:00 UTC (permalink / raw)
To: Jerome Brunet
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree, Florian Fainelli,
Alexandre TORGUE, Neil Armstrong, Martin Blumenstingl,
Kevin Hilman, Linux Kernel, Andre Roth,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Carlo Caione,
Giuseppe Cavallaro, linux-arm-kernel
In-Reply-To: <1479378055.17538.57.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Jerone,
On 17 November 2016 at 15:50, Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> On Wed, 2016-11-16 at 22:36 +0530, Anand Moon wrote:
>> Hi Jerome.
>>
>> On 15 November 2016 at 19:59, Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> wrote:
>> >
>> > On some platforms, energy efficient ethernet with rtl8211 devices
>> > is
>> > causing issue, like throughput drop or broken link.
>> >
>> > This was reported on the OdroidC2 (DWMAC + RTL8211F). While the
>> > issue root
>> > cause is not fully understood yet, disabling EEE advertisement
>> > prevent auto
>> > negotiation from enabling EEE.
>> >
>> > This patch provides options to disable 1000T and 100TX EEE
>> > advertisement
>> > individually for the realtek phys supporting this feature.
>> >
>> > Reported-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23myhRSP0FMvGiw@public.gmane.org
>> > m>
>> > Cc: Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>
>> > Cc: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
>> > Signed-off-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> > Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> > Tested-by: Andre Roth <neolynx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> > ---
>> > drivers/net/phy/realtek.c | 65
>> > ++++++++++++++++++++++++++++++++++++++++++++++-
>> > 1 file changed, 64 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
>> > index aadd6e9f54ad..77235fd5faaf 100644
>> > --- a/drivers/net/phy/realtek.c
>> > +++ b/drivers/net/phy/realtek.c
>> > @@ -15,6 +15,12 @@
>> > */
>> > #include <linux/phy.h>
>> > #include <linux/module.h>
>> > +#include <linux/of.h>
>> > +
>> > +struct rtl8211x_phy_priv {
>> > + bool eee_1000t_disable;
>> > + bool eee_100tx_disable;
>> > +};
>> >
>> > #define RTL821x_PHYSR 0x11
>> > #define RTL821x_PHYSR_DUPLEX 0x2000
>> > @@ -93,12 +99,44 @@ static int rtl8211f_config_intr(struct
>> > phy_device *phydev)
>> > return err;
>> > }
>> >
>> > +static void rtl8211x_clear_eee_adv(struct phy_device *phydev)
>> > +{
>> > + struct rtl8211x_phy_priv *priv = phydev->priv;
>> > + u16 val;
>> > +
>> > + if (priv->eee_1000t_disable || priv->eee_100tx_disable) {
>> > + val = phy_read_mmd_indirect(phydev,
>> > MDIO_AN_EEE_ADV,
>> > + MDIO_MMD_AN);
>> > +
>> > + if (priv->eee_1000t_disable)
>> > + val &= ~MDIO_AN_EEE_ADV_1000T;
>> > + if (priv->eee_100tx_disable)
>> > + val &= ~MDIO_AN_EEE_ADV_100TX;
>> > +
>> > + phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV,
>> > + MDIO_MMD_AN, val);
>> > + }
>> > +}
>> > +
>> > +static int rtl8211x_config_init(struct phy_device *phydev)
>> > +{
>> > + int ret;
>> > +
>> > + ret = genphy_config_init(phydev);
>> > + if (ret < 0)
>> > + return ret;
>> > +
>> > + rtl8211x_clear_eee_adv(phydev);
>> > +
>> > + return 0;
>> > +}
>> > +
>> > static int rtl8211f_config_init(struct phy_device *phydev)
>> > {
>> > int ret;
>> > u16 reg;
>> >
>> > - ret = genphy_config_init(phydev);
>> > + ret = rtl8211x_config_init(phydev);
>> > if (ret < 0)
>> > return ret;
>> >
>> > @@ -115,6 +153,26 @@ static int rtl8211f_config_init(struct
>> > phy_device *phydev)
>> > return 0;
>> > }
>> >
>> > +static int rtl8211x_phy_probe(struct phy_device *phydev)
>> > +{
>> > + struct device *dev = &phydev->mdio.dev;
>> > + struct device_node *of_node = dev->of_node;
>> > + struct rtl8211x_phy_priv *priv;
>> > +
>> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>> > + if (!priv)
>> > + return -ENOMEM;
>> > +
>> > + priv->eee_1000t_disable =
>> > + of_property_read_bool(of_node, "realtek,disable-
>> > eee-1000t");
>> > + priv->eee_100tx_disable =
>> > + of_property_read_bool(of_node, "realtek,disable-
>> > eee-100tx");
>> > +
>> > + phydev->priv = priv;
>> > +
>> > + return 0;
>> > +}
>> > +
>> > static struct phy_driver realtek_drvs[] = {
>> > {
>> > .phy_id = 0x00008201,
>> > @@ -140,7 +198,9 @@ static struct phy_driver realtek_drvs[] = {
>> > .phy_id_mask = 0x001fffff,
>> > .features = PHY_GBIT_FEATURES,
>> > .flags = PHY_HAS_INTERRUPT,
>> > + .probe = &rtl8211x_phy_probe,
>> > .config_aneg = genphy_config_aneg,
>> > + .config_init = &rtl8211x_config_init,
>> > .read_status = genphy_read_status,
>> > .ack_interrupt = rtl821x_ack_interrupt,
>> > .config_intr = rtl8211e_config_intr,
>> > @@ -152,7 +212,9 @@ static struct phy_driver realtek_drvs[] = {
>> > .phy_id_mask = 0x001fffff,
>> > .features = PHY_GBIT_FEATURES,
>> > .flags = PHY_HAS_INTERRUPT,
>> > + .probe = &rtl8211x_phy_probe,
>> > .config_aneg = &genphy_config_aneg,
>> > + .config_init = &rtl8211x_config_init,
>> > .read_status = &genphy_read_status,
>> > .ack_interrupt = &rtl821x_ack_interrupt,
>> > .config_intr = &rtl8211e_config_intr,
>> > @@ -164,6 +226,7 @@ static struct phy_driver realtek_drvs[] = {
>> > .phy_id_mask = 0x001fffff,
>> > .features = PHY_GBIT_FEATURES,
>> > .flags = PHY_HAS_INTERRUPT,
>> > + .probe = &rtl8211x_phy_probe,
>> > .config_aneg = &genphy_config_aneg,
>> > .config_init = &rtl8211f_config_init,
>> > .read_status = &genphy_read_status,
>> > --
>> > 2.7.4
>> >
>>
>> How about adding callback functionality for .soft_reset to handle
>> BMCR
>> where we update the Auto-Negotiation for the phy,
>> as per the datasheet of the rtl8211f.
>
> I'm not sure I understand how this would help with our issue (and EEE).
> Am I missing something or is it something unrelated that you would like
> to see happening on this driver ?
>
[snip]
I was just tying other phy module to understand the feature.
But in order to improve the throughput I tried to integrate blow u-boot commit.
commit 3d6af748ebd831524cb22a29433e9092af469ec7
Author: Shengzhou Liu <Shengzhou.Liu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Date: Thu Mar 12 18:54:59 2015 +0800
net/phy: Add support for realtek RTL8211F
RTL8211F has different registers from RTL8211E.
This patch adds support for RTL8211F PHY which
can be found on Freescale's T1023 RDB board.
And added the similar functionality to .config_aneg = &rtl8211f_config_aneg,
And I seem to have better results in through put with periodic drop
but it recovers.
-----
odroid@odroid64:~$ iperf3 -c 10.0.0.102 -p 2006 -i 1 -t 100 -V
iperf 3.0.11
Linux odroid64 4.9.0-rc5-xc2ml #18 SMP PREEMPT Thu Nov 17 22:56:00 IST
2016 aarch64 aarch64 aarch64 GNU/Linux
Time: Thu, 17 Nov 2016 17:35:25 GMT
Connecting to host 10.0.0.102, port 2006
Cookie: odroid64.1479404125.404729.3b45146e7
TCP MSS: 1448 (default)
[ 4] local 10.0.0.105 port 40238 connected to 10.0.0.102 port 2006
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting
0 seconds, 100 second test
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 114 MBytes 952 Mbits/sec 0 368 KBytes
[ 4] 1.00-2.00 sec 112 MBytes 937 Mbits/sec 0 368 KBytes
[ 4] 2.00-3.00 sec 111 MBytes 935 Mbits/sec 0 368 KBytes
[ 4] 3.00-4.00 sec 112 MBytes 936 Mbits/sec 0 368 KBytes
[ 4] 4.00-5.00 sec 112 MBytes 939 Mbits/sec 0 368 KBytes
[ 4] 5.00-6.00 sec 112 MBytes 936 Mbits/sec 0 368 KBytes
[ 4] 6.00-7.00 sec 111 MBytes 933 Mbits/sec 0 368 KBytes
[ 4] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 0 368 KBytes
[ 4] 8.00-9.00 sec 111 MBytes 935 Mbits/sec 0 368 KBytes
[ 4] 9.00-10.00 sec 111 MBytes 932 Mbits/sec 0 368 KBytes
[ 4] 10.00-11.00 sec 112 MBytes 937 Mbits/sec 0 368 KBytes
[ 4] 11.00-12.00 sec 111 MBytes 935 Mbits/sec 0 368 KBytes
[ 4] 12.00-13.00 sec 112 MBytes 938 Mbits/sec 0 368 KBytes
[ 4] 13.00-14.00 sec 112 MBytes 940 Mbits/sec 0 368 KBytes
[ 4] 14.00-15.00 sec 111 MBytes 934 Mbits/sec 0 368 KBytes
[ 4] 15.00-16.00 sec 111 MBytes 935 Mbits/sec 0 368 KBytes
[ 4] 16.00-17.00 sec 112 MBytes 939 Mbits/sec 0 368 KBytes
[ 4] 17.00-18.00 sec 112 MBytes 936 Mbits/sec 0 368 KBytes
[ 4] 18.00-19.00 sec 111 MBytes 934 Mbits/sec 0 368 KBytes
[ 4] 19.00-20.00 sec 112 MBytes 940 Mbits/sec 0 368 KBytes
[ 4] 20.00-21.00 sec 111 MBytes 933 Mbits/sec 0 368 KBytes
[ 4] 21.00-22.00 sec 112 MBytes 941 Mbits/sec 0 368 KBytes
[ 4] 22.00-23.00 sec 111 MBytes 931 Mbits/sec 0 368 KBytes
[ 4] 23.00-24.00 sec 112 MBytes 938 Mbits/sec 0 368 KBytes
[ 4] 24.00-25.00 sec 112 MBytes 938 Mbits/sec 0 368 KBytes
[ 4] 25.00-26.00 sec 111 MBytes 934 Mbits/sec 0 368 KBytes
[ 4] 26.00-27.00 sec 112 MBytes 940 Mbits/sec 0 368 KBytes
[ 4] 27.00-28.00 sec 112 MBytes 936 Mbits/sec 0 368 KBytes
[ 4] 28.00-29.00 sec 111 MBytes 934 Mbits/sec 0 368 KBytes
[ 4] 29.00-30.00 sec 112 MBytes 937 Mbits/sec 0 368 KBytes
[ 4] 30.00-31.00 sec 111 MBytes 934 Mbits/sec 0 368 KBytes
[ 4] 31.00-32.00 sec 112 MBytes 942 Mbits/sec 0 368 KBytes
[ 4] 32.00-33.00 sec 111 MBytes 933 Mbits/sec 0 368 KBytes
[ 4] 33.00-34.00 sec 111 MBytes 935 Mbits/sec 0 368 KBytes
[ 4] 34.00-35.00 sec 112 MBytes 941 Mbits/sec 0 368 KBytes
[ 4] 35.00-36.00 sec 107 MBytes 896 Mbits/sec 0 368 KBytes
[ 4] 36.00-37.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes
[ 4] 37.00-38.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 4] 38.00-39.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 39.00-40.00 sec 38.0 MBytes 319 Mbits/sec 1 385 KBytes
[ 4] 40.00-41.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 41.00-42.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 42.00-43.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 43.00-44.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 44.00-45.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 45.00-46.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 46.00-47.00 sec 111 MBytes 931 Mbits/sec 0 385 KBytes
[ 4] 47.00-48.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 48.00-49.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 49.00-50.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 50.00-51.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 51.00-52.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 52.00-53.00 sec 112 MBytes 941 Mbits/sec 0 385 KBytes
[ 4] 53.00-54.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 54.00-55.00 sec 111 MBytes 930 Mbits/sec 0 385 KBytes
[ 4] 55.00-56.00 sec 112 MBytes 941 Mbits/sec 0 385 KBytes
[ 4] 56.00-57.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 57.00-58.00 sec 111 MBytes 933 Mbits/sec 0 385 KBytes
[ 4] 58.00-59.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 59.00-60.00 sec 112 MBytes 940 Mbits/sec 0 385 KBytes
[ 4] 60.00-61.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 61.00-62.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 62.00-63.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 63.00-64.00 sec 112 MBytes 938 Mbits/sec 0 385 KBytes
[ 4] 64.00-65.00 sec 111 MBytes 932 Mbits/sec 0 385 KBytes
[ 4] 65.00-66.00 sec 112 MBytes 940 Mbits/sec 0 385 KBytes
[ 4] 66.00-67.00 sec 112 MBytes 938 Mbits/sec 0 385 KBytes
[ 4] 67.00-68.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 68.00-69.00 sec 111 MBytes 933 Mbits/sec 0 385 KBytes
[ 4] 69.00-70.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 70.00-71.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 71.00-72.00 sec 112 MBytes 941 Mbits/sec 0 385 KBytes
[ 4] 72.00-73.00 sec 111 MBytes 933 Mbits/sec 0 385 KBytes
[ 4] 73.00-74.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 74.00-75.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 75.00-76.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 76.00-77.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 77.00-78.00 sec 112 MBytes 938 Mbits/sec 0 385 KBytes
[ 4] 78.00-79.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 79.00-80.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 80.00-81.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 81.00-82.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 82.00-83.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 83.00-84.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 84.00-85.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 85.00-86.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 86.00-87.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 87.00-88.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 88.00-89.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 89.00-90.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 90.00-91.00 sec 112 MBytes 937 Mbits/sec 0 385 KBytes
[ 4] 91.00-92.00 sec 111 MBytes 934 Mbits/sec 0 385 KBytes
[ 4] 92.00-93.00 sec 112 MBytes 939 Mbits/sec 0 385 KBytes
[ 4] 93.00-94.00 sec 111 MBytes 935 Mbits/sec 0 385 KBytes
[ 4] 94.00-95.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 95.00-96.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 96.00-97.00 sec 112 MBytes 936 Mbits/sec 0 385 KBytes
[ 4] 97.00-98.00 sec 113 MBytes 945 Mbits/sec 0 559 KBytes
[ 4] 98.00-99.00 sec 112 MBytes 937 Mbits/sec 0 559 KBytes
[ 4] 99.00-100.00 sec 111 MBytes 928 Mbits/sec 0 559 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-100.00 sec 10.5 GBytes 902 Mbits/sec 4 sender
[ 4] 0.00-100.00 sec 10.5 GBytes 902 Mbits/sec receiver
CPU Utilization: local/sender 5.6% (0.2%u/5.4%s), remote/receiver
17.1% (1.2%u/15.9%s)
Can your confirm this at your end.
Once confirm I will try to send this as a fix for this issue.
-Best Regards
Anand Moon
--
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] soc/tegra: Implement Tegra186 PMC support
From: Sudeep Holla @ 2016-11-17 17:55 UTC (permalink / raw)
To: Thierry Reding
Cc: Sudeep Holla, Rob Herring, Mark Rutland, Stephen Warren,
Alexandre Courbot, Jon Hunter, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161117175218.GA7751-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org>
On 17/11/16 17:52, Thierry Reding wrote:
> On Thu, Nov 17, 2016 at 05:40:35PM +0000, Sudeep Holla wrote:
>>
>>
>> On 17/11/16 17:31, Thierry Reding wrote:
[...]
>>> would be nice to still be able to reboot via the PMC code above.
>>
>> I assume it's only for development purposes as you won't have much CPU
>> power management support without PSCI.
>
> This is what I had primarily in mind. Sometimes it might be useful to
> boot without PSCI at all (as a poor man's way of disable SMP), in which
> case this driver can still be used for reboot into the bootloader or
> recovery mode.
>
Thanks for clarification.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2 2/2] dt-bindings: max77620: add documentation for MPOK property
From: Venkat Reddy Talla @ 2016-11-17 17:54 UTC (permalink / raw)
To: lee.jones, lgirdwood, broonie, robh+dt, mark.rutland, devicetree,
linux-kernel
Cc: ldewangan, svelpula, vreddytalla
In-Reply-To: <1479405276-26452-1-git-send-email-vreddytalla@nvidia.com>
Adding documentation for maxim,power-ok-control dts property
Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
---
Changes from V1:
None
---
Documentation/devicetree/bindings/mfd/max77620.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/max77620.txt b/Documentation/devicetree/bindings/mfd/max77620.txt
index 2ad44f7..9c16d51 100644
--- a/Documentation/devicetree/bindings/mfd/max77620.txt
+++ b/Documentation/devicetree/bindings/mfd/max77620.txt
@@ -106,6 +106,18 @@ Here supported time periods by device in microseconds are as follows:
MAX77620 supports 40, 80, 160, 320, 640, 1280, 2560 and 5120 microseconds.
MAX20024 supports 20, 40, 80, 160, 320, 640, 1280 and 2540 microseconds.
+-maxim,power-ok-control: configure map power ok bit
+ 1: Enables POK(Power OK) to control nRST_IO and GPIO1
+ POK function.
+ 0: Disables POK control.
+ if property missing, do not configure MPOK bit.
+ If POK mapping is enabled for GPIO1/nRST_IO then,
+ GPIO1/nRST_IO pins are HIGH only if all rails
+ that have POK control enabled are HIGH.
+ If any of the rails goes down(which are enabled for POK
+ control) then, GPIO1/nRST_IO goes LOW.
+ this property is valid for max20024 only.
+
For DT binding details of different sub modules like GPIO, pincontrol,
regulator, power, please refer respective device-tree binding document
under their respective sub-system directories.
--
2.1.4
^ permalink raw reply related
* [PATCH v2 1/2] regulator: max77620: add support to configure MPOK
From: Venkat Reddy Talla @ 2016-11-17 17:54 UTC (permalink / raw)
To: lee.jones, lgirdwood, broonie, robh+dt, mark.rutland, devicetree,
linux-kernel
Cc: ldewangan, svelpula, vreddytalla
Adding support to configure regulator POK mapping bit
to control nRST_IO and GPIO1 POK function.
In tegra based platform which uses MAX20024 pmic, when
some of regulators are configured FPS_NONE(flexible power sequencer)
causes PMIC GPIO1 to go low which lead to various other rails turning off,
to avoid this MPOK bit of those regulators need to be set to 0
so that PMIC GPIO1 will not go low.
Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
---
changes in v2:
- updated commit message for the patch
- address review comments
---
drivers/regulator/max77620-regulator.c | 46 ++++++++++++++++++++++++++++++++++
include/linux/mfd/max77620.h | 2 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/regulator/max77620-regulator.c b/drivers/regulator/max77620-regulator.c
index a1b49a6..850b14c 100644
--- a/drivers/regulator/max77620-regulator.c
+++ b/drivers/regulator/max77620-regulator.c
@@ -81,6 +81,7 @@ struct max77620_regulator_pdata {
int suspend_fps_pd_slot;
int suspend_fps_pu_slot;
int current_mode;
+ int power_ok;
int ramp_rate_setting;
};
@@ -351,11 +352,48 @@ static int max77620_set_slew_rate(struct max77620_regulator *pmic, int id,
return 0;
}
+static int max77620_config_power_ok(struct max77620_regulator *pmic, int id)
+{
+ struct max77620_regulator_pdata *rpdata = &pmic->reg_pdata[id];
+ struct max77620_regulator_info *rinfo = pmic->rinfo[id];
+ struct max77620_chip *chip = dev_get_drvdata(pmic->dev->parent);
+ u8 val, mask;
+ int ret;
+
+ switch (chip->chip_id) {
+ case MAX20024:
+ if (rpdata->power_ok >= 0) {
+ if (rinfo->type == MAX77620_REGULATOR_TYPE_SD)
+ mask = MAX20024_SD_CFG1_MPOK_MASK;
+ else
+ mask = MAX20024_LDO_CFG2_MPOK_MASK;
+
+ val = rpdata->power_ok ? mask : 0;
+
+ ret = regmap_update_bits(pmic->rmap, rinfo->cfg_addr,
+ mask, val);
+ if (ret < 0) {
+ dev_err(pmic->dev, "Reg 0x%02x update failed %d\n",
+ rinfo->cfg_addr, ret);
+ return ret;
+ }
+ }
+ break;
+
+ default:
+ break;
+ }
+
+ return 0;
+}
+
static int max77620_init_pmic(struct max77620_regulator *pmic, int id)
{
struct max77620_regulator_pdata *rpdata = &pmic->reg_pdata[id];
int ret;
+ max77620_config_power_ok(pmic, id);
+
/* Update power mode */
ret = max77620_regulator_get_power_mode(pmic, id);
if (ret < 0)
@@ -595,6 +633,12 @@ static int max77620_of_parse_cb(struct device_node *np,
np, "maxim,suspend-fps-power-down-slot", &pval);
rpdata->suspend_fps_pd_slot = (!ret) ? pval : -1;
+ ret = of_property_read_u32(np, "maxim,power-ok-control", &pval);
+ if (!ret)
+ rpdata->power_ok = pval;
+ else
+ rpdata->power_ok = -1;
+
ret = of_property_read_u32(np, "maxim,ramp-rate-setting", &pval);
rpdata->ramp_rate_setting = (!ret) ? pval : 0;
@@ -807,6 +851,8 @@ static int max77620_regulator_resume(struct device *dev)
for (id = 0; id < MAX77620_NUM_REGS; id++) {
reg_pdata = &pmic->reg_pdata[id];
+ max77620_config_power_ok(pmic, id);
+
max77620_regulator_set_fps_slots(pmic, id, false);
if (reg_pdata->active_fps_src < 0)
continue;
diff --git a/include/linux/mfd/max77620.h b/include/linux/mfd/max77620.h
index 3ca0af07..ad2a9a8 100644
--- a/include/linux/mfd/max77620.h
+++ b/include/linux/mfd/max77620.h
@@ -180,6 +180,7 @@
#define MAX77620_SD_CFG1_FPWM_SD_MASK BIT(2)
#define MAX77620_SD_CFG1_FPWM_SD_SKIP 0
#define MAX77620_SD_CFG1_FPWM_SD_FPWM BIT(2)
+#define MAX20024_SD_CFG1_MPOK_MASK BIT(1)
#define MAX77620_SD_CFG1_FSRADE_SD_MASK BIT(0)
#define MAX77620_SD_CFG1_FSRADE_SD_DISABLE 0
#define MAX77620_SD_CFG1_FSRADE_SD_ENABLE BIT(0)
@@ -187,6 +188,7 @@
/* LDO_CNFG2 */
#define MAX77620_LDO_POWER_MODE_MASK 0xC0
#define MAX77620_LDO_POWER_MODE_SHIFT 6
+#define MAX20024_LDO_CFG2_MPOK_MASK BIT(2)
#define MAX77620_LDO_CFG2_ADE_MASK BIT(1)
#define MAX77620_LDO_CFG2_ADE_DISABLE 0
#define MAX77620_LDO_CFG2_ADE_ENABLE BIT(1)
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] soc/tegra: Implement Tegra186 PMC support
From: Thierry Reding @ 2016-11-17 17:52 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rob Herring, Mark Rutland, Stephen Warren, Alexandre Courbot,
Jon Hunter, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <efb274c8-d361-f4d1-95aa-547b9e941d68-5wv7dgnIgG8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]
On Thu, Nov 17, 2016 at 05:40:35PM +0000, Sudeep Holla wrote:
>
>
> On 17/11/16 17:31, Thierry Reding wrote:
> > On Thu, Nov 17, 2016 at 05:28:53PM +0000, Sudeep Holla wrote:
> > >
> > >
> > > On 17/11/16 17:16, Thierry Reding wrote:
> > > > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > > >
> > > > The power management controller on Tegra186 has changed in backwards-
> > > > incompatible ways with respect to earlier generations. This implements a
> > > > new driver that supports inversion of the PMU interrupt as well as the
> > > > "recovery", "bootloader" and "forced-recovery" reboot commands.
> > > >
> > > > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > > > ---
> > > > .../bindings/arm/tegra/nvidia,tegra186-pmc.txt | 34 +++++
> > > > drivers/soc/tegra/Makefile | 2 +-
> > > > drivers/soc/tegra/pmc-tegra186.c | 169 +++++++++++++++++++++
> > > > 3 files changed, 204 insertions(+), 1 deletion(-)
> > > > create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt
> > > > create mode 100644 drivers/soc/tegra/pmc-tegra186.c
> > > >
> > >
> > > [...]
> > >
> > > > diff --git a/drivers/soc/tegra/pmc-tegra186.c b/drivers/soc/tegra/pmc-tegra186.c
> > > > new file mode 100644
> > > > index 000000000000..ee28eddd8e3c
> > > > --- /dev/null
> > > > +++ b/drivers/soc/tegra/pmc-tegra186.c
> > >
> > > [...]
> > >
> > > > +
> > > > + /*
> > > > + * If available, call the system restart implementation that was
> > > > + * registered earlier (typically PSCI).
> > > > + */
> > > > + if (pmc->system_restart) {
> > > > + pmc->system_restart(reboot_mode, cmd);
> > > > + return NOTIFY_DONE;
> > > > + }
> > > > +
> > >
> > > IIUC, Tegra186 implements PSCI v1.0 and it always takes above path.
> > > So what other platforms does this driver support ? The name is
> > > pmc-tegra186.c, hence the confusion.
> >
> > It's technically possible to run Tegra186 without PSCI enabled, or even
> > boot it with firmware that doesn't implement PSCI. In such cases it
>
> OK, with enable-method as "spin-table" I suppose ?
Yes, that would probably be the other choice for SMP.
> > would be nice to still be able to reboot via the PMC code above.
>
> I assume it's only for development purposes as you won't have much CPU
> power management support without PSCI.
This is what I had primarily in mind. Sometimes it might be useful to
boot without PSCI at all (as a poor man's way of disable SMP), in which
case this driver can still be used for reboot into the bootloader or
recovery mode.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RESEND PATCH v7 0/3] Add clockevent for timer-nps driver to NPS400 SoC
From: Vineet Gupta @ 2016-11-17 17:50 UTC (permalink / raw)
To: Noam Camus, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A
Cc: tglx-hfZtesqFncYOwBW4kG4KsQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Alexey.Brodkin-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <1479277873-18994-1-git-send-email-noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
On 11/15/2016 10:31 PM, Noam Camus wrote:
> From: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> Change log
> ---
> V6 --> V7
> Apply several comments made by Daniel Lezcano:
> 1) Remove CLOCK_EVT_FEAT_PERIODIC support. This way it is
> pure oneshot driver. This simplifies driver so that:
> nps_clkevent_add_thread()
> nps_clkevent_rm_thread()
> are more clearer without any vague logic if to change
> TSI bit of current HW thread or not.
> 2) tick_resume is also calls nps_clkevent_rm_thread()
> 3) Few (hopefully last) typo fixes.
>
> V5 --> V6
> Apply several comments made by Daniel Lezcano:
> 1) nps_get_timer_clk() - use clk_put() on error scenario
> 2) nps_get_timer_clk() - return EINVAL and not plain 1
> 3) Fix typos in log (double checked with spell checker)
>
> V4 --> V5
> Apply several comments made by Daniel Lezcano:
> 1) Add __init attribute to nps_get_timer_clk()
> 2) Fix return value of nps_get_timer_clk()
> when failing to get clk rate
> 3) Change clocksource rate from 301 -> 300
>
> V3 --> V4
> Main changes are [Thanks for the review]:
> Fix many typos at log [Daniel]
> Add handling for bad return values [Daniel and Thomas]
> Replace use of internal irqchip pointers with existing IRQ API [Thomas]
> Provide interrupt handler (percpu) with dev_id equal to evt [Thomas]
> Fix passing *clk by reference to nps_get_timer_clk() [Daniel]
>
> V2 --> V3
> Apply Rob Herring comment about backword compatibility
>
> V1 --> V2
> Apply Daniel Lezcano comments:
> CLOCKSOURCE_OF_DECLARE return value
> update hotplug callbacks usage
> squash of 2 first commits.
> In this version I created new commit to serve as preperation for adding clockevents.
> This way the last patch is more readable with clockevent content.
> ---
>
> In first version of this driver we supported clocksource for the NPS400.
> The support for clockevent was taken from Synopsys ARC timer driver.
> This was good for working with our simulator of NPS400.
> However in NPS400 ASIC the timers behave differently than simulation.
> The timers in ASIC are shared between all threads whithin a core
> and hence need different driver to support this behaviour.
>
> The idea of this design is that we got 16 HW threads per core
> each represented at bimask in a shared register in this core.
> So when thread wants that next clockevent expiration will produce
> timer interrupt to itself the correspondance bit in this register
> should be set.
> So theoretically if all 16 bits are set then all HW threads will get
> timer interrupt on next expiration of timer 0.
>
> Note that we use Synopsys ARC design naming convention for the timers
> where:
> timer0 is used for clockevents
> timer1 is used for clocksource.
>
> Noam Camus (3):
> soc: Support for NPS HW scheduling
> clocksource: update "fn" at CLOCKSOURCE_OF_DECLARE() of nps400 timer
> clocksource: Add clockevent support to NPS400 driver
>
> .../bindings/timer/ezchip,nps400-timer.txt | 15 --
> .../bindings/timer/ezchip,nps400-timer0.txt | 17 ++
> .../bindings/timer/ezchip,nps400-timer1.txt | 15 ++
> arch/arc/plat-eznps/include/plat/ctop.h | 2 -
> drivers/clocksource/timer-nps.c | 223 ++++++++++++++++++--
> include/soc/nps/mtm.h | 59 +++++
> 6 files changed, 294 insertions(+), 37 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
> create mode 100644 include/soc/nps/mtm.h
Added to ARC for-next !
Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox