* Re: [PATCH v3] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: David Lechner @ 2017-01-13 18:16 UTC (permalink / raw)
To: Sekhar Nori, devicetree, linux-arm-kernel
Cc: Kevin Hilman, Rob Herring, Mark Rutland, linux-kernel
In-Reply-To: <3066d614-0676-319a-6149-6d723e1cf35f@ti.com>
On 01/13/2017 06:04 AM, Sekhar Nori wrote:
> On Friday 13 January 2017 02:02 AM, David Lechner wrote:
>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>>
...
>
> There are couple of checkpatch errors that show up. The compatible
> "lego,ev3" needs to be documented in
> Documentation/devicetree/bindings/arm/davinci.txt
>
> "at24,24c128" is undocumented. Is that an atmel chip on the EV3? If the
> manufacturer name is not clear,
> Documentation/devicetree/bindings/eeprom/eeprom.txt advises using just
> "24c128"
The mfg is microchip, so I guess I will just go with "24c128"
>
> Finally, lego needs to be added to
> Documentation/devicetree/bindings/vendor-prefixes.txt
>
> Can you please submit the documentation portions as separate patches in
> a series along with this patch.
Yes.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* Re: [PATCH v3] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: David Lechner @ 2017-01-13 18:20 UTC (permalink / raw)
To: Sekhar Nori, devicetree, linux-arm-kernel
Cc: Kevin Hilman, Rob Herring, Mark Rutland, linux-kernel
In-Reply-To: <0d69ff4b-c3a6-5126-2590-2268d3b25f92@lechnology.com>
On 01/13/2017 12:16 PM, David Lechner wrote:
> On 01/13/2017 06:04 AM, Sekhar Nori wrote:
>> On Friday 13 January 2017 02:02 AM, David Lechner wrote:
>>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>>>
> ...
>>
>> There are couple of checkpatch errors that show up. The compatible
>> "lego,ev3" needs to be documented in
>> Documentation/devicetree/bindings/arm/davinci.txt
>>
>> "at24,24c128" is undocumented. Is that an atmel chip on the EV3? If the
>> manufacturer name is not clear,
>> Documentation/devicetree/bindings/eeprom/eeprom.txt advises using just
>> "24c128"
>
> The mfg is microchip, so I guess I will just go with "24c128"
I think I have let the device tree bindings doc confuse me. On second
though, I think the correct thing is to included the manufacturer.
>
>>
>> Finally, lego needs to be added to
>> Documentation/devicetree/bindings/vendor-prefixes.txt
>>
>> Can you please submit the documentation portions as separate patches in
>> a series along with this patch.
>
> Yes.
>
>>
>> Thanks,
>> Sekhar
>>
>
^ permalink raw reply
* Re: [PATCH v3 1/7] devicetree: power: add battery state machine documentation
From: Sebastian Reichel @ 2017-01-13 18:33 UTC (permalink / raw)
To: Matt Ranostay, Rob Herring; +Cc: linux-pm, devicetree, tony
In-Reply-To: <20170111062003.10110-2-matt@ranostay.consulting>
[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]
Hi,
On Tue, Jan 10, 2017 at 10:19:57PM -0800, Matt Ranostay wrote:
> Documentation on battery properties that can be defined for
> fine tuning fuel gauge state machines.
>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
> ---
> .../devicetree/bindings/power/supply/battery.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/battery.txt
>
> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
> new file mode 100644
> index 000000000000..a6ca761e0a29
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
> @@ -0,0 +1,20 @@
> +Battery State Machine Support
Let's also add a mandatory compatible string. This binding
is only relevant for dumb batteries, since other ones can
self-identify. I suggest
compatible = "fixed-battery"
> +Optional Properties
> + - nominal-microvolt: dead battery voltage in microvolts
> + - design-microwatt-hours: battery design mWh in microwatts
> + - design-microamp-hours: battery design mAh in microamps
I think we should mandate the property name of the phandle in the
generic binding instead of each potential fuel-gauge/charger.
Maybe something like the following paragraph:
Batteries are supposed to be referenced by chargers and/or
fuel-gauges using a phandle. The phandle's property should
be named "monitored-battery".
> +Example:
> +
> + bat: battery@0 {
> + nominal-microvolt = <3700000>;
> + design-microwatt-hours = <5290000>;
> + design-microamp-hours = <1430000>;
> + };
> +
> + charger: charger@0 {
> + ...
> + monitored-battery = <&bat>;
> + ...
> + };
Let's also add a fuel-gauge to the example to avoid any confusion
between fuel-gauge and battery.
fuel_gauge: fuel-gauge {
...
monitored-battery = <&bat>;
...
};
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] mtd: spi-nor: don't claim mr25h40 to be JEDEC compatible
From: Geert Uytterhoeven @ 2017-01-13 18:42 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Masahiko Iwamoto, Jagan Teki, Marek Vasut, Cyrille Pitchen,
MTD Maling List, Sascha Hauer,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170113093509.25737-1-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hi Uwe,
CC devicetree
On Fri, Jan 13, 2017 at 10:35 AM, Uwe Kleine-König
<u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> Commit edd0c8f4932d ("mtd: spi-nor: Add support for mr25h40") made it
> possible to use a mr25h40 by writing
>
> compatible = "mr25h40", "jedec,spi-nor";
No vendor prefix?
>
> in a device tree. This chip however isn't JEDEC compatible however, so
> change the chip string and add a compatible entry to bless
>
> compatible = "mr25h40-nonjedec";
>
> as the right way.
This whole "-nonjedec" business looks wrong to me.
If the device is called "mr25h40", its compatible value should be
"everspin,mr25h40". Adding some (in)compatibility indicator violates the
spirit of compatible values, IMHO.
> Fixes: edd0c8f4932d ("mtd: spi-nor: Add support for mr25h40")
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> drivers/mtd/devices/m25p80.c | 1 +
> drivers/mtd/spi-nor/spi-nor.c | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 9cf7fcd28034..bd0c335692d2 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -304,6 +304,7 @@ static const struct spi_device_id m25p_ids[] = {
> {"m25p05-nonjedec"}, {"m25p10-nonjedec"}, {"m25p20-nonjedec"},
> {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
> {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
> + {"mr25h40-nonjedec"},
>
> { },
> };
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index bbdbbd763c9d..3a8042fe44f0 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -825,7 +825,7 @@ static const struct flash_info spi_nor_ids[] = {
> /* Everspin */
> { "mr25h256", CAT25_INFO( 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
> { "mr25h10", CAT25_INFO(128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
> - { "mr25h40", CAT25_INFO(512 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
> + { "mr25h40-nonjedec", CAT25_INFO(512 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
>
> /* Fujitsu */
> { "mb85rs1mt", INFO(0x047f27, 0, 128 * 1024, 1, SPI_NOR_NO_ERASE) },
> --
> 2.11.0
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 v3 3/5] i2c: mux: pca954x: Add interrupt controller support
From: Wolfram Sang @ 2017-01-13 18:54 UTC (permalink / raw)
To: Phil Reid
Cc: Peter Rosin, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1284b1c8-bb90-fbd9-53a2-0c36f2597b29-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
> >BTW, what does client->irq == 0 represent?
>
> This one I'm fairly confident on. Initially I had "client->irq < 0"
> Which caused problems with an i2c mux that doesn't have irq's defined in the dt.
>
> This commit seems to confirm that.
> commit dab472eb931b ("i2c / ACPI: Use 0 to indicate that device does not have interrupt assigned")
In the Linux Kernel, 0 means no irq so one can write:
if (!irq) ...
There used to be NO_IRQ per arch but this is converted over, although it
takes a lot of time... If there is a HW IRQ0, it needs to be remapped.
But since we rely on irq_desc these days and not irq numbers, this is
easy.
At least this was the transition a few years ago, but I don't think
something essential has changed. Please enlighten me, if so.
Regards,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: marvell: add generic-ahci compatibles for CP110 ahci
From: Russell King @ 2017-01-13 18:57 UTC (permalink / raw)
To: Gregory Clement
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Testing with an Armada 8040 board shows that adding the generic-ahci
compatible to the CP110 AHCI nodes gets us working AHCI on the board.
A previous patch series posted by Thomas Petazzoni was retracted when
it was realised that the IP was supposed to be, and is, compatible
with the standard register layout.
Add this compatible.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 3 ++-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index 464b491c7291..65ad781d7910 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -128,7 +128,8 @@
};
cpm_sata0: sata@540000 {
- compatible = "marvell,armada-8k-ahci";
+ compatible = "marvell,armada-8k-ahci",
+ "generic-ahci";
reg = <0x540000 0x30000>;
interrupts = <ICU_GRP_NSR 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpm_syscon0 1 15>;
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index b10f4781d8fb..168d667d50a3 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -128,7 +128,8 @@
};
cps_sata0: sata@540000 {
- compatible = "marvell,armada-8k-ahci";
+ compatible = "marvell,armada-8k-ahci",
+ "generic-ahci";
reg = <0x540000 0x30000>;
interrupts = <ICU_GRP_NSR 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cps_syscon0 1 15>;
--
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 related
* Re: [PATCH v3 01/24] [media] dt-bindings: Add bindings for i.MX media driver
From: Steve Longerbeam @ 2017-01-13 19:03 UTC (permalink / raw)
To: Philipp Zabel
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
fabio.estevam-3arQi8VN3Tc, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
nick-gcszYUEDH4VrovVCs/uTlw, markus.heiser-O6JHGLzbNUwb1SvskN2V4Q,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
bparrot-l0cyMroinI0, geert-Td1EMuHUCqxL1ZNQvxDV9g,
arnd-r2nGTMty4D4, sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
jean-christophe.trotin-qxv4g6HH51o,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw,
robert.jarzmik-GANU6spQydw, songjun.wu-UWL1GkI3JZL3oGB3hsPCZA,
andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, Steve Longerbeam
In-Reply-To: <1484308551.31475.23.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 01/13/2017 03:55 AM, Philipp Zabel wrote:
> Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
>> Add bindings documentation for the i.MX media driver.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/media/imx.txt | 57 +++++++++++++++++++++++++
>> 1 file changed, 57 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/imx.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/imx.txt b/Documentation/devicetree/bindings/media/imx.txt
>> new file mode 100644
>> index 0000000..254b64a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/imx.txt
>> @@ -0,0 +1,57 @@
>> +Freescale i.MX Media Video Devices
>> +
>> +Video Media Controller node
>> +---------------------------
>> +
>> +This is the parent media controller node for video capture support.
>> +
>> +Required properties:
>> +- compatible : "fsl,imx-media";
> Would you be opposed to calling this "capture-subsystem" instead of
> "imx-media"? We already use "fsl,imx-display-subsystem" and
> "fsl,imx-gpu-subsystem" for the display and GPU compound devices.
sure. Some pie-in-the-sky day when DRM and media are unified,
there could be a single device that handles them all, but for now
I'm fine with "fsl,capture-subsystem".
>> +- ports : Should contain a list of phandles pointing to camera
>> + sensor interface ports of IPU devices
>> +
>> +
>> +fim child node
>> +--------------
>> +
>> +This is an optional child node of the ipu_csi port nodes. If present and
>> +available, it enables the Frame Interval Monitor. Its properties can be
>> +used to modify the method in which the FIM measures frame intervals.
>> +Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
>> +Frame Interval Monitor.
>> +
>> +Optional properties:
>> +- fsl,input-capture-channel: an input capture channel and channel flags,
>> + specified as <chan flags>. The channel number
>> + must be 0 or 1. The flags can be
>> + IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
>> + IRQ_TYPE_EDGE_BOTH, and specify which input
>> + capture signal edge will trigger the input
>> + capture event. If an input capture channel is
>> + specified, the FIM will use this method to
>> + measure frame intervals instead of via the EOF
>> + interrupt. The input capture method is much
>> + preferred over EOF as it is not subject to
>> + interrupt latency errors. However it requires
>> + routing the VSYNC or FIELD output signals of
>> + the camera sensor to one of the i.MX input
>> + capture pads (SD1_DAT0, SD1_DAT1), which also
>> + gives up support for SD1.
> This is a clever method to get better frame timestamps. Too bad about
> the routing requirements. Can this be used on Nitrogen6X?
Absolutely, this support just needs use of the input-capture channels in the
imx GPT. I still need to submit the patch to the imx-gpt driver that adds an
input capture API, so at this point fsl,input-capture-channel has no effect,
but it does work (tested on SabreAuto).
>
>> +
>> +mipi_csi2 node
>> +--------------
>> +
>> +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
>> +CSI-2 sensors.
>> +
>> +Required properties:
>> +- compatible : "fsl,imx6-mipi-csi2";
> I think this should get an additional "snps,dw-mipi-csi2" compatible,
> since the only i.MX6 specific part is the bolted-on IPU2CSI gasket.
right, minus the gasket it's a Synopsys core. I'll add that compatible flag.
Or should wait until the day this subdev is exported for general use, after
pulling out the gasket specifics?
>
>> +- reg : physical base address and length of the register set;
>> +- clocks : the MIPI CSI-2 receiver requires three clocks: hsi_tx
>> + (the DPHY clock), video_27m, and eim_sel;
> Note that hsi_tx is incorrectly named. CCGR3[CG8] just happens to be the
> shared gate bit that gates the HSI clocks as well as the MIPI
> "ac_clk_125m", "cfg_clk", "ips_clk", and "pll_refclk" inputs to the mipi
> csi-2 core, but we are missing shared gate clocks in the clock tree for
> these.
Yes, so many clocks for the MIPI core. Why so many? I would think
there would need to be at most three: a clock for the MIPI CSI-2 core
and HSI core, and a clock for the D-PHY (oh and maybe a clock for an
M-PHY if there is one). I have no clue what all these other clocks are.
But anyway, a single gating bit, CCGR3[CG8], seems to enable them all.
> Both cfg_clk and pll_refclk are sourced from video_27m, so "cfg" ->
> video_27m seems fine.
> But I don't get "dphy".
I presume it's the clock for the D-PHY.
> Which input clock would that correspond to?
> "pll_refclk?"
the mux at CDCDR says it comes from PLL3_120M, or PLL2_PFD2.
> Also the pixel clock input is a gate after aclk_podf (which we call
> eim_podf), not aclk_sel (eim_sel).
ok, I'll switch to eim_podf for the pixel clock.
Steve
>
>> +- clock-names : must contain "dphy", "cfg", "pix";
>> +
>> +Optional properties:
>> +- interrupts : must contain two level-triggered interrupts,
>> + in order: 100 and 101;
> regards
> Philipp
>
--
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
* [PATCH v4 0/4] Support for LEGO MINDSTORMS EV3
From: David Lechner @ 2017-01-13 19:03 UTC (permalink / raw)
To: devicetree, linux-arm-kernel
Cc: David Lechner, Sekhar Nori, Kevin Hilman, Rob Herring,
Mark Rutland, linux-kernel
This patch series adds support for LEGO MINDSTORMS EV3. This is a TI AM1808
based board.
v4 changes:
* New patches for device tree bindings specifications
* Fixed vendor on eeprom device node
v3 changes:
* required defconfig patches have been picked up in linux-davinci tree, so this
is the only patch left in the series
* Added aliases node for consistent naming of serial ports
* Added memory node
* Removed nodes that are not finalized yet
* Renamed button labels to match EV3 users manual
v2 changes:
* Dropped defconfig patches that have already been pick up
* Added some new defconfig patches
* Updated device tree file based on feedback and new available bindings
* Renamed file to include da850- prefix
* Changed button labels
* Fixed LED names
* Added beeper device for sound
* Added regulators for USB and A/DC
* Removed unused pinmux nodes
* Added pinconf for buttons
* Enabled pwms
* Used preferred bindings for flash partitions
* Added A/DC spi device
* Enabled USB
David Lechner (4):
dt-bindings: Add vendor prefix for LEGO
dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
dt-bindings: add "microchip,24c128" compatible string
ARM: dts: Add LEGO MINDSTORMS EV3 dts
Documentation/devicetree/bindings/arm/davinci.txt | 4 +
.../devicetree/bindings/eeprom/eeprom.txt | 2 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/da850-lego-ev3.dts | 313 +++++++++++++++++++++
5 files changed, 322 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/da850-lego-ev3.dts
--
2.7.4
^ permalink raw reply
* [PATCH v4 1/4] dt-bindings: Add vendor prefix for LEGO
From: David Lechner @ 2017-01-13 19:03 UTC (permalink / raw)
To: devicetree, linux-arm-kernel
Cc: David Lechner, Sekhar Nori, Kevin Hilman, Rob Herring,
Mark Rutland, linux-kernel
In-Reply-To: <1484334222-14223-1-git-send-email-david@lechnology.com>
Add a vendor prefix for LEGO Systems A/S
Signed-off-by: David Lechner <david@lechnology.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 61cb272..c1ccfd4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -159,6 +159,7 @@ kosagi Sutajio Ko-Usagi PTE Ltd.
kyo Kyocera Corporation
lacie LaCie
lantiq Lantiq Semiconductor
+lego LEGO Systems A/S
lenovo Lenovo Group Ltd.
lg LG Corporation
licheepi Lichee Pi
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/4] dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification
From: David Lechner @ 2017-01-13 19:03 UTC (permalink / raw)
To: devicetree, linux-arm-kernel
Cc: David Lechner, Sekhar Nori, Kevin Hilman, Rob Herring,
Mark Rutland, linux-kernel
In-Reply-To: <1484334222-14223-1-git-send-email-david@lechnology.com>
This adds the board level device tree specification for LEGO MINDSTORMS EV3
Signed-off-by: David Lechner <david@lechnology.com>
---
Documentation/devicetree/bindings/arm/davinci.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/davinci.txt b/Documentation/devicetree/bindings/arm/davinci.txt
index f0841ce..715622c 100644
--- a/Documentation/devicetree/bindings/arm/davinci.txt
+++ b/Documentation/devicetree/bindings/arm/davinci.txt
@@ -13,6 +13,10 @@ EnBW AM1808 based CMC board
Required root node properties:
- compatible = "enbw,cmc", "ti,da850;
+LEGO MINDSTORMS EV3 (AM1808 based)
+Required root node properties:
+ - compatible = "lego,ev3", "ti,da850";
+
Generic DaVinci Boards
----------------------
--
2.7.4
^ permalink raw reply related
* [PATCH v4 3/4] dt-bindings: add "microchip,24c128" compatible string
From: David Lechner @ 2017-01-13 19:03 UTC (permalink / raw)
To: devicetree, linux-arm-kernel
Cc: David Lechner, Sekhar Nori, Kevin Hilman, Rob Herring,
Mark Rutland, linux-kernel
In-Reply-To: <1484334222-14223-1-git-send-email-david@lechnology.com>
This adds "microchip,24c128" to the list of compatible strings for i2c
eeproms.
Signed-off-by: David Lechner <david@lechnology.com>
---
Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
index 735bc94..5696eb5 100644
--- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -10,6 +10,8 @@ Required properties:
"catalyst,24c32"
+ "microchip,24c128"
+
"ramtron,24c64"
"renesas,r1ex24002"
--
2.7.4
^ permalink raw reply related
* [PATCH v4 4/4] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: David Lechner @ 2017-01-13 19:03 UTC (permalink / raw)
To: devicetree, linux-arm-kernel
Cc: David Lechner, Sekhar Nori, Kevin Hilman, Rob Herring,
Mark Rutland, linux-kernel
In-Reply-To: <1484334222-14223-1-git-send-email-david@lechnology.com>
This adds a device tree definition file for LEGO MINDSTORMS EV3.
What is working:
* Pin muxing
* Pinconf
* GPIOs
* MicroSD card reader
* UART on input port 1
* Buttons
* LEDs
* Poweroff/reset
* Flash memory
* EEPROM
* USB host port
* USB peripheral port
What is not working/to be added later:
* Speaker - have patch submitted to get pwm-beeper working - maybe someday
it will have a real sound driver that uses PRU
* A/DC chip - have driver submitted and accepted - waiting for ack on
device tree bindings
* Display - waiting for "simple DRM" to be mainlined
* Bluetooth - needs new driver for sequencing power/enable/clock
* Input and output ports - need some sort of new phy or extcon driver as
well as PRU UART and PRU I2C drivers
* Battery indication - needs new power supply driver
Note on flash partitions:
These partitions are based on the official EV3 firmware from LEGO. It is
expected that most users of the mainline kernel on EV3 will be booting from
an SD card while retaining the official firmware in the flash memory.
Furthermore, the official firmware uses an ancient U-Boot (2009) that has
no device tree support. So, it makes sense to have this partition table in
the EV3 device tree file. In the unlikely case that anyone does create
their own firmware image with different partitioning, they can use a modern
U-Boot in their own firmware image that modifies the device tree with the
custom partitions.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/da850-lego-ev3.dts | 313 +++++++++++++++++++++++++++++++++++
2 files changed, 315 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/da850-lego-ev3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 78a94b7..1a19e7a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -130,7 +130,8 @@ dtb-$(CONFIG_ARCH_CLPS711X) += \
dtb-$(CONFIG_ARCH_DAVINCI) += \
da850-lcdk.dtb \
da850-enbw-cmc.dtb \
- da850-evm.dtb
+ da850-evm.dtb \
+ da850-lego-ev3.dtb
dtb-$(CONFIG_ARCH_DIGICOLOR) += \
cx92755_equinox.dtb
dtb-$(CONFIG_ARCH_EFM32) += \
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts b/arch/arm/boot/dts/da850-lego-ev3.dts
new file mode 100644
index 0000000..112ec92
--- /dev/null
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -0,0 +1,313 @@
+/*
+ * Device tree for LEGO MINDSTORMS EV3
+ *
+ * Copyright (C) 2017 David Lechner <david@lechnology.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation, version 2.
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+
+#include "da850.dtsi"
+
+/ {
+ compatible = "lego,ev3", "ti,da850";
+ model = "LEGO MINDSTORMS EV3";
+
+ aliases {
+ serial1 = &serial1;
+ };
+
+ memory@c0000000 {
+ device_type = "memory";
+ reg = <0xc0000000 0x04000000>;
+ };
+
+ /*
+ * The buttons on the EV3 are mapped to keyboard keys.
+ */
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ label = "EV3 Brick Buttons";
+ pinctrl-names = "default";
+ pinctrl-0 = <&button_pins>, <&button_bias>;
+
+ center {
+ label = "Center";
+ linux,code = <KEY_ENTER>;
+ gpios = <&gpio 29 GPIO_ACTIVE_HIGH>;
+ };
+
+ left {
+ label = "Left";
+ linux,code = <KEY_LEFT>;
+ gpios = <&gpio 102 GPIO_ACTIVE_HIGH>;
+ };
+
+ back {
+ label = "Back";
+ linux,code = <KEY_BACKSPACE>;
+ gpios = <&gpio 106 GPIO_ACTIVE_HIGH>;
+ };
+
+ right {
+ label = "Right";
+ linux,code = <KEY_RIGHT>;
+ gpios = <&gpio 124 GPIO_ACTIVE_HIGH>;
+ };
+
+ down {
+ label = "Down";
+ linux,code = <KEY_DOWN>;
+ gpios = <&gpio 126 GPIO_ACTIVE_HIGH>;
+ };
+
+ up {
+ label = "Up";
+ linux,code = <KEY_UP>;
+ gpios = <&gpio 127 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ /*
+ * The EV3 has two built-in bi-color LEDs behind the buttons.
+ */
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins>;
+
+ left_green {
+ label = "led0:green:brick-status";
+ /* GP6[13] */
+ gpios = <&gpio 103 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ right_red {
+ label = "led1:red:brick-status";
+ /* GP6[7] */
+ gpios = <&gpio 108 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ left_red {
+ label = "led0:red:brick-status";
+ /* GP6[12] */
+ gpios = <&gpio 109 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ right_green {
+ label = "led1:green:brick-status";
+ /* GP6[14] */
+ gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ };
+
+ /*
+ * The EV3 is powered down by turning off the main 5V supply.
+ */
+ gpio-poweroff {
+ compatible = "gpio-poweroff";
+ gpios = <&gpio 107 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&system_power_pin>;
+ };
+
+ /*
+ * This is a 5V current limiting regulator that is shared by USB,
+ * the sensor (input) ports, the motor (output) ports and the A/DC.
+ */
+ vcc5v: regulator1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v_pins>;
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio 101 0>;
+ over-current-gpios = <&gpio 99 GPIO_ACTIVE_LOW>;
+ enable-active-high;
+ regulator-boot-on;
+ };
+};
+
+&pmx_core {
+ status = "okay";
+
+ spi0_cs3_pin: pinmux_spi0_cs3_pin {
+ pinctrl-single,bits = <
+ /* CS3 */
+ 0xc 0x01000000 0x0f000000
+ >;
+ };
+
+ mmc0_cd_pin: pinmux_mmc0_cd {
+ pinctrl-single,bits = <
+ /* GP5[14] */
+ 0x2C 0x00000080 0x000000f0
+ >;
+ };
+
+ button_pins: pinmux_button_pins {
+ pinctrl-single,bits = <
+ /* GP1[13] */
+ 0x8 0x00000800 0x00000f00
+ /* GP6[10] */
+ 0x34 0x00800000 0x00f00000
+ /* GP6[6] */
+ 0x38 0x00000080 0x000000f0
+ /* GP7[12], GP7[14], GP7[15] */
+ 0x40 0x00808800 0x00f0ff00
+ >;
+ };
+
+ led_pins: pinmux_led_pins {
+ pinctrl-single,bits = <
+ /* GP6[12], GP6[13], GP6[14] */
+ 0x34 0x00008880 0x0000fff0
+ /* GP6[7] */
+ 0x38 0x00000008 0x0000000f
+ >;
+ };
+
+ system_power_pin: pinmux_system_power {
+ pinctrl-single,bits = <
+ /* GP6[11] */
+ 0x34 0x00080000 0x000f0000
+ >;
+ };
+
+ vcc5v_pins: pinmux_vcc5v {
+ pinctrl-single,bits = <
+ /* GP6[5] */
+ 0x40 0x00000080 0x000000f0
+ /* GP6[3] */
+ 0x4c 0x00008000 0x0000f000
+ >;
+ };
+};
+
+&pinconf {
+ status = "okay";
+
+ /* Buttons have external pulldown resistors */
+ button_bias: button-bias-groups {
+ disable {
+ groups = "cp5", "cp24", "cp25", "cp28";
+ bias-disable;
+ };
+ };
+};
+
+/* Input port 1 */
+&serial1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&serial1_rxtx_pins>;
+};
+
+&rtc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+
+ /*
+ * EEPROM contains the first stage bootloader, HW ID and Bluetooth MAC.
+ */
+ eeprom@50 {
+ compatible = "microchip,24c128";
+ pagesize = <64>;
+ read-only;
+ reg = <0x50>;
+ };
+};
+
+&wdt {
+ status = "okay";
+};
+
+&mmc0 {
+ status = "okay";
+ max-frequency = <50000000>;
+ bus-width = <4>;
+ cd-gpios = <&gpio 94 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin>;
+};
+
+&spi0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
+
+ flash@0 {
+ compatible = "n25q128a13", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ ti,spi-wdelay = <8>;
+
+ /* Partitions are based on the official firmware from LEGO */
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "U-Boot";
+ reg = <0 0x40000>;
+ };
+
+ partition@40000 {
+ label = "U-Boot Env";
+ reg = <0x40000 0x10000>;
+ };
+
+ partition@50000 {
+ label = "Kernel";
+ reg = <0x50000 0x200000>;
+ };
+
+ partition@250000 {
+ label = "Filesystem";
+ reg = <0x250000 0xa50000>;
+ };
+
+ partition@cb0000 {
+ label = "Storage";
+ reg = <0xcb0000 0x2f0000>;
+ };
+ };
+ };
+};
+
+&gpio {
+ status = "okay";
+};
+
+&usb_phy {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+ vbus-supply = <&vcc5v>;
+};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4 0/2] Add support rockchip,grf property for RK3399 PMU/GRU
From: Heiko Stuebner @ 2017-01-13 19:10 UTC (permalink / raw)
To: Xing Zheng
Cc: dianders, linux-rockchip, Douglas Anderson, David Wu, Jianqun Xu,
devicetree, Stephen Boyd, Elaine Zhang, Brian Norris,
Michael Turquette, linux-kernel, linux-clk, Shawn Lin,
Rob Herring, Will Deacon, Mark Rutland, Caesar Wang,
Catalin Marinas, linux-arm-kernel
In-Reply-To: <1484028930-20305-1-git-send-email-zhengxing@rock-chips.com>
Am Dienstag, 10. Januar 2017, 14:15:28 CET schrieb Xing Zheng:
> Hi,
> The structure rockchip_clk_provider needs to refer the GRF regmap
> in somewhere, if the CRU node has not "rockchip,grf" property,
> calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> regmap, and the MUXGRF type clock will be not supported.
>
> Therefore, we need to add them.
>
> Thanks.
applied both for 4.11
binding-change is in my clock-branch (so that dt-binding doc changes stay
together) and the dts change is of course in the dts64 branch.
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH 03/10] devicetree: bindings: add bindings for ahci-da850
From: David Lechner @ 2017-01-13 19:25 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Sekhar Nori, Patrick Titiano,
Michael Turquette, Tejun Heo, Rob Herring, Mark Rutland,
Russell King
Cc: linux-ide-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484311084-31547-4-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 01/13/2017 06:37 AM, Bartosz Golaszewski wrote:
> Add DT bindings for the TI DA850 AHCI SATA controller.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/ata/ahci-da850.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
>
> diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt b/Documentation/devicetree/bindings/ata/ahci-da850.txt
> new file mode 100644
> index 0000000..d07c241
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ata/ahci-da850.txt
> @@ -0,0 +1,21 @@
> +Device tree binding for the TI DA850 AHCI SATA Controller
> +---------------------------------------------------------
> +
> +Required properties:
> + - compatible: must be "ti,da850-ahci"
> + - reg: physical base addresses and sizes of the controller's register areas
> + - interrupts: interrupt specifier (refer to the interrupt binding)
> +
> +Optional properties:
> + - clocks: clock specifier (refer to the common clock binding)
> + - da850,clk_multiplier: the multiplier for the reference clock needed
> + for 1.5GHz PLL output
A clock multiplier property seems redundant if you are specifying a
clock. It should be possible to get the rate from the clock to determine
which multiplier is needed.
> +
> +Example:
> +
> + sata: ahci@0x218000 {
> + compatible = "ti,da850-ahci";
> + reg = <0x218000 0x2000>, <0x22c018 0x4>;
> + interrupts = <67>;
> + da850,clk_multiplier = <7>;
> + };
>
--
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 v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Rob Herring @ 2017-01-13 19:25 UTC (permalink / raw)
To: Dave Gerlach
Cc: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, Nishanth Menon, Keerthy, Russell King,
Tero Kristo, Sudeep Holla, Santosh Shilimkar, Lokesh Vutla
In-Reply-To: <3bb89649-fd2a-acc6-6968-e54a00842ce2@ti.com>
On Thu, Jan 12, 2017 at 9:27 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
> Rob,
>
> On 01/11/2017 03:34 PM, Rob Herring wrote:
>>
>> On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>>
>>> Rob,
>>>
>>> On 01/09/2017 11:50 AM, Rob Herring wrote:
>>>>
>>>>
>>>> On Wed, Jan 04, 2017 at 02:55:34PM -0600, Dave Gerlach wrote:
>>>>>
>>>>>
>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>>> control device power states.
>>>>>
>>>>> Also, provide macros representing each device index as understood
>>>>> by TI SCI to be used in the device node power-domain references.
>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>
>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>> ---
>>>>> v2->v3:
>>>>> Update k2g_pds node docs to show it should be a child of pmmc
>>>>> node.
>>>>> In early versions a phandle was used to point to pmmc and docs
>>>>> still
>>>>> incorrectly showed this.
>>>>>
>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59 ++++++++++++++
>>>>> MAINTAINERS | 2 +
>>>>> include/dt-bindings/genpd/k2g.h | 90
>>>>> ++++++++++++++++++++++
>>>>> 3 files changed, 151 insertions(+)
>>>>> create mode 100644
>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>> new file mode 100644
>>>>> index 000000000000..4c9064e512cb
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>> @@ -0,0 +1,59 @@
>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>> +---------------------------------------------
>>>>> +
>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that
>>>>> is
>>>>> +responsible for controlling the state of the IPs that are present.
>>>>> +Communication between the host processor running an OS and the system
>>>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>>>> domain
>>>>> +implementation plugs into the generic pm domain framework and makes
>>>>> use
>>>>> of
>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>> +
>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>> +
>>>>> +PM Domain Node
>>>>> +==============
>>>>> +The PM domain node represents the global PM domain managed by the
>>>>> PMMC,
>>>>> +which in this case is the single implementation as documented by the
>>>>> generic
>>>>> +PM domain bindings in
>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>> +Because this relies on the TI SCI protocol to communicate with the
>>>>> PMMC
>>>>> it
>>>>> +must be a child of the pmmc node.
>>>>> +
>>>>> +Required Properties:
>>>>> +--------------------
>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>> +- #power-domain-cells: Must be 0.
>>>>> +
>>>>> +Example (K2G):
>>>>> +-------------
>>>>> + pmmc: pmmc {
>>>>> + compatible = "ti,k2g-sci";
>>>>> + ...
>>>>> +
>>>>> + k2g_pds: k2g_pds {
>>>>> + compatible = "ti,sci-pm-domain";
>>>>> + #power-domain-cells = <0>;
>>>>> + };
>>>>> + };
>>>>> +
>>>>> +PM Domain Consumers
>>>>> +===================
>>>>> +Hardware blocks that require SCI control over their state must provide
>>>>> +a reference to the sci-pm-domain they are part of and a unique device
>>>>> +specific ID that identifies the device.
>>>>> +
>>>>> +Required Properties:
>>>>> +--------------------
>>>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>>>> + be used for device control.
>>>>
>>>>
>>>>
>>>> As I've already stated before, this goes in power-domain cells. When you
>>>> have a single thing (i.e. node) that controls multiple things, then you
>>>> you need to specify the ID for each of them in phandle args. This is how
>>>> irqs, gpio, clocks, *everything* in DT works.
>>>
>>>
>>>
>>> You think the reasoning for doing it this way provided by both Ulf and
>>> myself on v2 [1] is not valid then?
>>>
>>> From Ulf:
>>>
>>> To me, the TI SCI ID, is similar to a "conid" for any another "device
>>> resource" (like clock, pinctrl, regulator etc) which we can describe
>>> in DT and assign to a device node. The only difference here, is that
>>> we don't have common API to fetch the resource (like clk_get(),
>>> regulator_get()), but instead we fetches the device's resource from
>>> SoC specific code, via genpd's device ->attach() callback.
>>
>>
>> Sorry, but that sounds like a kernel problem to me and has nothing to
>> do with DT bindings.
>>
>>> From me:
>>>
>>> Yes, you've pretty much hit it on the head. It is not an index into a
>>> list
>>> of genpds but rather identifies the device *within* a single genpd. It is
>>> a
>>> property specific to each device that resides in a ti-sci-genpd, not a
>>> mapping describing which genpd the device belongs to. The generic power
>>> domain binding is concerned with mapping the device to a specific genpd,
>>> which is does fine for us, but we have a sub mapping for devices that
>>> exist
>>> inside a genpd which, we must describe as well, hence the ti,sci-id.
>>>
>>>
>>> So to summarize, the genpd framework does interpret the phandle arg as an
>>> index into multiple genpds, just as you've said other frameworks do, but
>>> this is not what I am trying to do, we have multiple devices within this
>>> *single* genpd, hence the need for the ti,sci-id property.
>>
>>
>> Fix the genpd framework rather than work around it in DT.
>
>
> I still disagree that this has nothing to do with DT bindings, as the
> current DT binding represents something different already. I am trying to
> extend it to give me additional information needed for our platforms. Are
> you saying that we should break what the current DT binding already
> represents to mean something else?
No idea because what's the current binding? From the patch, looks like
a new binding to me.
Rob
^ permalink raw reply
* Re: [PATCH 07/10] sata: ahci_da850: add support for the da850,clk_multiplier DT property
From: David Lechner @ 2017-01-13 19:29 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Sekhar Nori, Patrick Titiano,
Michael Turquette, Tejun Heo, Rob Herring, Mark Rutland,
Russell King
Cc: linux-ide, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <1484311084-31547-8-git-send-email-bgolaszewski@baylibre.com>
On 01/13/2017 06:38 AM, Bartosz Golaszewski wrote:
> Currently the clock multiplier is hardcoded in the driver for
> the da850-evm board. Make it configurable over DT, but keep the
> previous value as default in case the property is missing.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> drivers/ata/ahci_da850.c | 83 +++++++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 75 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
> index bb9eb4c..cd04caf 100644
> --- a/drivers/ata/ahci_da850.c
> +++ b/drivers/ata/ahci_da850.c
> @@ -28,17 +28,70 @@
> #define SATA_PHY_TXSWING(x) ((x) << 19)
> #define SATA_PHY_ENPLL(x) ((x) << 31)
>
> +struct da850_sata_mpy_mapping {
> + unsigned int multiplier;
> + unsigned int regval;
> +};
> +
> +static const struct da850_sata_mpy_mapping da850_sata_mpy_table[] = {
> + {
> + .multiplier = 5,
> + .regval = 0x01,
> + },
> + {
> + .multiplier = 6,
> + .regval = 0x02,
> + },
> + {
> + .multiplier = 8,
> + .regval = 0x04,
> + },
> + {
> + .multiplier = 10,
> + .regval = 0x05,
> + },
> + {
> + .multiplier = 12,
> + .regval = 0x06,
> + },
> + /* TODO Add 12.5 multiplier. */
Looks like you should be using an enum here for the multiplier field.
> + {
> + .multiplier = 15,
> + .regval = 0x08,
> + },
> + {
> + .multiplier = 20,
> + .regval = 0x09,
> + },
> + {
> + .multiplier = 25,
> + .regval = 0x0a,
> + }
> +};
> +
> +static const struct da850_sata_mpy_mapping *
> +da850_sata_get_mpy(unsigned int multiplier)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(da850_sata_mpy_table); i++)
> + if (da850_sata_mpy_table[i].multiplier == multiplier)
> + return &da850_sata_mpy_table[i];
> +
> + return NULL;
> +}
> +
> /*
> * The multiplier needed for 1.5GHz PLL output.
> *
> - * NOTE: This is currently hardcoded to be suitable for 100MHz crystal
> - * frequency (which is used by DA850 EVM board) and may need to be changed
> - * if you would like to use this driver on some other board.
> + * This is the default value suitable for the 100MHz crystal frequency
> + * used by DA850 EVM board, which doesn't use DT.
As I said in a reply on another patch, it seems like it would be better
to use a clock that represents the crystal and use clk_get_rate() and
calculate the multiplier from that.
For example, we have done something like this in
usb20_phy_clk_set_parent() in arch/arm/mach-davinci/usb-da8xx.c.
> */
> -#define DA850_SATA_CLK_MULTIPLIER 7
> +#define DA850_SATA_CLK_MULTIPLIER_DEFAULT 15
>
> static void da850_sata_init(struct device *dev, void __iomem *pwrdn_reg,
> - void __iomem *ahci_base)
> + void __iomem *ahci_base,
> + const struct da850_sata_mpy_mapping *mpy)
> {
> unsigned int val;
>
> @@ -47,7 +100,7 @@ static void da850_sata_init(struct device *dev, void __iomem *pwrdn_reg,
> val &= ~BIT(0);
> writel(val, pwrdn_reg);
>
> - val = SATA_PHY_MPY(DA850_SATA_CLK_MULTIPLIER + 1) | SATA_PHY_LOS(1) |
> + val = SATA_PHY_MPY(mpy->regval) | SATA_PHY_LOS(1) |
> SATA_PHY_RXCDR(4) | SATA_PHY_RXEQ(1) | SATA_PHY_TXSWING(3) |
> SATA_PHY_ENPLL(1);
>
> @@ -87,10 +140,12 @@ static struct scsi_host_template ahci_platform_sht = {
>
> static int ahci_da850_probe(struct platform_device *pdev)
> {
> + const struct da850_sata_mpy_mapping *mpy;
> struct device *dev = &pdev->dev;
> struct ahci_host_priv *hpriv;
> - struct resource *res;
> + unsigned int multiplier;
> void __iomem *pwrdn_reg;
> + struct resource *res;
> int rc;
>
> hpriv = ahci_platform_get_resources(pdev);
> @@ -109,7 +164,19 @@ static int ahci_da850_probe(struct platform_device *pdev)
> if (!pwrdn_reg)
> goto disable_resources;
>
> - da850_sata_init(dev, pwrdn_reg, hpriv->mmio);
> + rc = of_property_read_u32(dev->of_node,
> + "da850,clk_multiplier", &multiplier);
> + if (rc)
> + multiplier = DA850_SATA_CLK_MULTIPLIER_DEFAULT;
> +
> + mpy = da850_sata_get_mpy(multiplier);
> + if (!mpy) {
> + dev_err(dev, "invalid multiplier value: %u\n", multiplier);
> + rc = -EINVAL;
> + goto disable_resources;
> + }
> +
> + da850_sata_init(dev, pwrdn_reg, hpriv->mmio, mpy);
>
> rc = ahci_platform_init_host(pdev, hpriv, &ahci_da850_port_info,
> &ahci_platform_sht);
>
^ permalink raw reply
* Re: [PATCH 09/10] ARM: dts: da850: add the SATA node
From: David Lechner @ 2017-01-13 19:36 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Sekhar Nori, Patrick Titiano,
Michael Turquette, Tejun Heo, Rob Herring, Mark Rutland,
Russell King
Cc: linux-ide, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1484311084-31547-10-git-send-email-bgolaszewski@baylibre.com>
On 01/13/2017 06:38 AM, Bartosz Golaszewski wrote:
> Add the SATA node to the da850 device tree.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 1f6a47d..f5086b1 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -427,6 +427,12 @@
> phy-names = "usb-phy";
> status = "disabled";
> };
> + sata: ahci@0x218000 {
0x needs to be omitted.
sata: ahci@218000 {
> + compatible = "ti,da850-ahci";
> + reg = <0x218000 0x2000>, <0x22c018 0x4>;
> + interrupts = <67>;
> + status = "disabled";
> + };
> mdio: mdio@224000 {
> compatible = "ti,davinci_mdio";
> #address-cells = <1>;
>
^ permalink raw reply
* Re: [PATCH] mtd: spi-nor: don't claim mr25h40 to be JEDEC compatible
From: Mark Rutland @ 2017-01-13 19:42 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Uwe Kleine-König, Masahiko Iwamoto, Jagan Teki, Marek Vasut,
Cyrille Pitchen, MTD Maling List, Sascha Hauer,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdXJi9hJrY0ZV37gejp2XC6fkuLF7i7BqX4CUYTB7j_q1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Jan 13, 2017 at 07:42:34PM +0100, Geert Uytterhoeven wrote:
> Hi Uwe,
>
> CC devicetree
>
> On Fri, Jan 13, 2017 at 10:35 AM, Uwe Kleine-König
> <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> > Commit edd0c8f4932d ("mtd: spi-nor: Add support for mr25h40") made it
> > possible to use a mr25h40 by writing
> >
> > compatible = "mr25h40", "jedec,spi-nor";
>
> No vendor prefix?
>
> >
> > in a device tree. This chip however isn't JEDEC compatible however, so
> > change the chip string and add a compatible entry to bless
> >
> > compatible = "mr25h40-nonjedec";
> >
> > as the right way.
>
> This whole "-nonjedec" business looks wrong to me.
> If the device is called "mr25h40", its compatible value should be
> "everspin,mr25h40". Adding some (in)compatibility indicator violates the
> spirit of compatible values, IMHO.
Agreed on all counts.
The compatible string should specify the vendor and device, any
compliance details should either be known for that string or derived
from other properties.
IIUC this is following an existing pattern, which we should deprecate
(retaining support for those strings so old DTBs work).
Thanks,
Mark.
>
> > Fixes: edd0c8f4932d ("mtd: spi-nor: Add support for mr25h40")
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > ---
> > drivers/mtd/devices/m25p80.c | 1 +
> > drivers/mtd/spi-nor/spi-nor.c | 2 +-
> > 2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> > index 9cf7fcd28034..bd0c335692d2 100644
> > --- a/drivers/mtd/devices/m25p80.c
> > +++ b/drivers/mtd/devices/m25p80.c
> > @@ -304,6 +304,7 @@ static const struct spi_device_id m25p_ids[] = {
> > {"m25p05-nonjedec"}, {"m25p10-nonjedec"}, {"m25p20-nonjedec"},
> > {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
> > {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
> > + {"mr25h40-nonjedec"},
> >
> > { },
> > };
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> > index bbdbbd763c9d..3a8042fe44f0 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -825,7 +825,7 @@ static const struct flash_info spi_nor_ids[] = {
> > /* Everspin */
> > { "mr25h256", CAT25_INFO( 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
> > { "mr25h10", CAT25_INFO(128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
> > - { "mr25h40", CAT25_INFO(512 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
> > + { "mr25h40-nonjedec", CAT25_INFO(512 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
> >
> > /* Fujitsu */
> > { "mb85rs1mt", INFO(0x047f27, 0, 128 * 1024, 1, SPI_NOR_NO_ERASE) },
> > --
> > 2.11.0
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
> --
> 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
--
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 2/3] can: ti_hecc: Add TI HECC DT binding documentation
From: Rob Herring @ 2017-01-13 19:56 UTC (permalink / raw)
To: yegorslists-gM/Ye1E23mwN+BqQ9rBEUg
Cc: linux-can-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
jean-michel.hautbois-B+Q8N6RmIDZBDgjK7y7TUQ,
andrej.skvortzov-Re5JQEeQqe8AvxtiuMwx3w, hs-ynQEQJNshbs,
Anton Glukhov
In-Reply-To: <1484143521-4898-3-git-send-email-yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On Wed, Jan 11, 2017 at 03:05:20PM +0100, yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org wrote:
> From: Anton Glukhov <anton.a.glukhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> DT binding documentation for TI High End CAN Controller
>
> Signed-off-by: Anton Glukhov <anton.a.glukhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> Changes v1 -> v2:
> change compatible to "ti,am3505"
>
> .../devicetree/bindings/net/can/ti_hecc.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/can/ti_hecc.txt
>
> diff --git a/Documentation/devicetree/bindings/net/can/ti_hecc.txt b/Documentation/devicetree/bindings/net/can/ti_hecc.txt
> new file mode 100644
> index 0000000..ce015cf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/can/ti_hecc.txt
> @@ -0,0 +1,31 @@
> +* Texas Instruments High End CAN Controller (HECC)
> +
> +This file provides information, what the device node
> +for the hecc interface contains.
> +
> +Required properties:
> +- compatible: "ti,am3505"
> +- reg: offset and length of the register set for the device
> +- interrupts: interrupt mapping for the hecc interrupts sources
> +- clocks: clock phandles (see clock bindings for details)
> +- ti,scc-ram-offset: offset to scc module ram
> +- ti,hecc-ram-offset: offset to hecc module ram
> +- ti,mbx-offset: offset to mailbox ram
Is there not a common case that would be the default?
> +
> +Optional properties:
> +- ti,int-line: interrupt line
Needs a better description. What are valid values? This is some internal
setting about which pin to route the interrupt output to I'm guessing.
> +
> +Example:
> +
> +For am3517evm board:
> + hecc: can@0x5c050000 {
> + compatible = "ti,am3505";
> + status = "disabled";
> + reg = <0x5c050000 0x4000>;
> + interrupts = <24>;
> + clocks = <&hecc_ck>;
> + ti,scc-ram-offset = <0x3000>;
> + ti,hecc-ram-offset = <0x3000>;
> + ti,mbx-offset = <0x2000>;
> + ti,int-line = <0>;
> + };
> --
> 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] Documentation: dt: dwc3: add reference to the usb-xhci properties
From: Rob Herring @ 2017-01-13 19:58 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, mark.rutland-5wv7dgnIgG8
In-Reply-To: <20170111145942.19744-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On Wed, Jan 11, 2017 at 03:59:42PM +0100, Martin Blumenstingl wrote:
> dwc3 internally creates a usb-xhci device which means that all
> properties documented in usb-xhci.txt are supported as well.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/dwc3.txt | 4 ++++
> 1 file changed, 4 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe 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/5] ARM: davinci_all_defconfig: enable iio and ADS7950
From: David Lechner @ 2017-01-13 20:02 UTC (permalink / raw)
To: Sekhar Nori
Cc: Mark Rutland, devicetree, Kevin Hilman, linux-kernel, Rob Herring,
linux-arm-kernel
In-Reply-To: <3c4f8952-0a64-fc49-bd87-452dbbf7a946@ti.com>
On 01/13/2017 06:24 AM, Sekhar Nori wrote:
> On Wednesday 11 January 2017 01:53 PM, Sekhar Nori wrote:
>> I do remember I did not see these two modules did not get enabled in
>> .config after 'make davinci_all_defconfig'. Will check what I may have
>> missed.
>
> So IIO_TRIGGERED_BUFFER is not selected in my tree because I dont have
> the ADS7950 driver enabled. Same thing with IIO_BUFFER.
>
> Can you try this patch over my tree?
I've got it sorted now and I have sent a new patch.
^ permalink raw reply
* Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Kevin Hilman @ 2017-01-13 20:03 UTC (permalink / raw)
To: Neil Armstrong
Cc: xypron.glpk, carlo, linux-amlogic, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <1484129414-23325-1-git-send-email-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
> this patch adds this reserved zone and redefines the usable memory range.
>
> The memory node is also moved from the dtsi files into the proper dts files
> to handle variants memory sizes.
>
> This patch also fixes the memory sizes for the following platforms :
> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Queued for v4.10-rc.
Kevin
^ permalink raw reply
* Re: [RFC PATCH 1/2] usb: host: add a generic platform USB roothub driver
From: Rob Herring @ 2017-01-13 20:08 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA, mark.rutland-5wv7dgnIgG8,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
vegard.nossum-QHcLZuEGTsvQT0dZR+AlfA,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
treding-DDmLM1+adcrQT0dZR+AlfA, geert-Td1EMuHUCqxL1ZNQvxDV9g,
manjunath.goudar-QSEj5FYQhm4dnm+yROfE0A, arnd-r2nGTMty4D4,
tony-4v6yS6AI5VpBDgjK7y7TUQ, ahaslam-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <20170111152947.27088-2-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On Wed, Jan 11, 2017 at 04:29:46PM +0100, Martin Blumenstingl wrote:
> Many SoC platforms have separate devices for the USB PHY which are
> registered through the generic PHY framework. These PHYs have to be
> enabled to make the USB controller actually work. They also have to be
> disabled again on shutdown/suspend.
>
> Currently (at least) the following HCI platform drivers are using custom
> code to obtain all PHYs via devicetree for the roothub/controller and
> disable/enable them when required:
> - ehci-platform.c has ehci_platform_power_{on,off}
> - xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}
> - ohci-platform.c has ohci_platform_power_{on,off}
>
> These drivers are not using the generic devicetree USB device bindings
> yet which were only introduced recently (documentation is available in
> devicetree/bindings/usb/usb-device.txt).
> With this new driver the usb2-phy and usb3-phy can be specified directly
> in the child-node of the corresponding port of the roothub via
> devicetree. This can be extended by not just parsing PHYs (some of the
> other drivers listed above are for example also parsing a list of clocks
> as well) when required.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> .../devicetree/bindings/usb/usb-roothub.txt | 41 ++++++
> drivers/usb/host/Kconfig | 3 +
> drivers/usb/host/Makefile | 2 +
> drivers/usb/host/platform-roothub.c | 146 +++++++++++++++++++++
> drivers/usb/host/platform-roothub.h | 14 ++
> 5 files changed, 206 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/usb-roothub.txt
> create mode 100644 drivers/usb/host/platform-roothub.c
> create mode 100644 drivers/usb/host/platform-roothub.h
>
> diff --git a/Documentation/devicetree/bindings/usb/usb-roothub.txt b/Documentation/devicetree/bindings/usb/usb-roothub.txt
> new file mode 100644
> index 000000000000..96e152d3901c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usb-roothub.txt
> @@ -0,0 +1,41 @@
> +Generic USB root-hub Properties
> +
> +similar to the USB device bindings (documented in usb-device.txt from the
> +current directory) this provides support for configuring the root-hub.
> +
> +Required properties:
> +- compatible: should be at least one of "usb1d6b,3", "usb1d6b,2"
> +- reg: must be 0.
> +- address-cells: must be 1
> +- size-cells: must be 0
> +- a sub-node per port supports the following properties:
Make this another section with required and optional sections.
> + - reg: the port number on the root-hub (mandatory)
> + - phys: optional, from the *Generic PHY* bindings (mandatory needed when
> + phy-names is given)
> + - phy-names: optional, from the *Generic PHY* bindings; supported names
> + are "usb2-phy" or "usb3-phy"
> +
> +Example:
> + &usb1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + roothub@0 {
> + compatible = "usb1d6b,3", "usb1d6b,2";
Is this discoverable? IIRC, we had decided that ports on the root hub
are just children of the USB controller node (rather than
grandchildren). Why does that not work?
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + port@1 {
Wouldn't this normally be 0 and 1. This should probably be usb-port
rather than port to avoid OF graph overlap.
> + reg = <1>;
> + usb-phy = <&usb2_phy1>, <&usb3_phy1>;
s/usb-phy/phys/
> + phy-names = "usb2-phy", "usb3-phy";
> + };
> +
> + port@2 {
> + reg = <2>;
> + usb-phy = <&usb2_phy2>, <&usb3_phy2>;
> + phy-names = "usb2-phy", "usb3-phy";
> + };
> + };
> + }
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 05/12] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Rob Herring @ 2017-01-13 20:16 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Ulf Hansson, Adrian Hunter, linux-mmc, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni, linux-arm-kernel,
Mike Turquette, Stephen Boyd, linux-clk, linux-kernel, devicetree,
Ziji Hu, Jimmy Xu, Jisheng Zhang, Nadav Haklai, Ryan Gao,
Doug Jones, Victor Gu, Wei(SOCP) Liu, Wilson Ding
In-Reply-To: <89c95d0084da6ad7132caa54ca66eb619d8a5090.1484154449.git-series.gregory.clement@free-electrons.com>
On Wed, Jan 11, 2017 at 06:19:08PM +0100, Gregory CLEMENT wrote:
> From: Hu Ziji <huziji@marvell.com>
>
> Marvell Xenon SDHC can support eMMC/SD/SDIO.
> Add Xenon-specific properties.
> Also add properties for Xenon PHY setting.
>
> Signed-off-by: Hu Ziji <huziji@marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 197 +++++++-
> 1 file changed, 197 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> new file mode 100644
> index 000000000000..a3876d2cc616
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
> @@ -0,0 +1,197 @@
> +Marvell Xenon SDHCI Controller device tree bindings
> +This file documents differences between the core mmc properties
> +described by mmc.txt and the properties used by the Xenon implementation.
> +
> +Multiple SDHCs might be put into a single Xenon IP, to save size and cost.
> +Each SDHC is independent and owns independent resources, such as register sets,
> +clock and PHY.
> +Each SDHC should have an independent device tree node.
> +
> +Required Properties:
> +- compatible: should be one of the following
> + - "marvell,armada-3700-sdhci": For controllers on Armada-3700 SoC.
> + Must provide a second register area and marvell,pad-type.
> + - "marvell,armada-8k-sdhci": For controllers on Armada 7K/8K SoC
> +
> +- clocks:
> + Array of clocks required for SDHC.
> + Require at least input clock for Xenon IP core.
> +
> +- clock-names:
> + Array of names corresponding to clocks property.
> + The input clock for Xenon IP core should be named as "core".
> +
> +- reg:
> + * For "marvell,armada-3700-sdhci", two register areas.
> + The first one for Xenon IP register. The second one for the Armada 3700 SoC
> + PHY PAD Voltage Control register.
> + Please follow the examples with compatible "marvell,armada-3700-sdhci"
> + in below.
> + Please also check property marvell,pad-type in below.
> +
> + * For other compatible strings, one register area for Xenon IP.
> +
> +Optional Properties:
> +- mmccard:
> + mmccard child node must be provided when current SDHC is for eMMC.
> + Xenon SDHC often can support both SD and eMMC. This child node indicates that
> + current SDHC is for eMMC card. Thus Xenon eMMC specific configuration and
> + operations can be enabled prior to eMMC init sequence.
> + Please refer to Documentation/devicetree/bindings/mmc/mmc-card.txt.
> + This child node should not be set if current Xenon SDHC is for SD/SDIO.
> +
> +- bus-width:
> + When 8-bit data bus width is in use for eMMC, this property should be
> + explicitly provided and set as 8.
> + It is optional when data bus width is 4-bit or 1-bit.
> +
> +- mmc-ddr-1_8v:
> + Select this property when eMMC HS DDR is supported on SDHC side.
> +
> +- mmc-hs400-1_8v:
> + Select this property when eMMC HS400 is supported on SDHC side.
> +
> +- no-1-8-v:
> + Select this property when 1.8V signaling voltage supply is unavailable.
> + When this property is enabled, both mmc-ddr-1_8v and mmc-hs400-1_8v should be
> + cleared.
> +
> +- marvell,xenon-sdhc-id:
> + Indicate the corresponding bit index of current SDHC in
> + SDHC System Operation Control Register Bit[7:0].
> + Set/clear the corresponding bit to enable/disable current SDHC.
> + If Xenon IP contains only one SDHC, this property is optional.
> +
> +- marvell,xenon-phy-type:
> + Xenon support mutilple types of PHYs.
> + To select eMMC 5.1 PHY, set:
> + marvell,xenon-phy-type = "emmc 5.1 phy"
> + eMMC 5.1 PHY is the default choice if this property is not provided.
> + To select eMMC 5.0 PHY, set:
> + marvell,xenon-phy-type = "emmc 5.0 phy"
> +
> + All those types of PHYs can support eMMC, SD and SDIO.
> + Please note that this property only presents the type of PHY.
> + It doesn't stand for the entire SDHC type or property.
> + For example, "emmc 5.1 phy" doesn't mean that this Xenon SDHC only supports
> + eMMC 5.1.
> +
> +- marvell,xenon-phy-znr:
> + Set PHY ZNR value.
> + Only available for eMMC PHY 5.1 and eMMC PHY 5.0.
> + Valid range = [0:0x1F].
> + ZNR is set as 0xF by default if this property is not provided.
> +
> +- marvell,xenon-phy-zpr:
> + Set PHY ZPR value.
> + Only available for eMMC PHY 5.1 and eMMC PHY 5.0.
> + Valid range = [0:0x1F].
> + ZPR is set as 0xF by default if this property is not provided.
> +
> +- marvell,xenon-phy-nr-success-tun:
> + Set the number of required consecutive successful sampling points used to
> + identify a valid sampling window, in tuning process.
> + Valid range = [1:7].
> + Set as 0x4 by default if this property is not provided.
> +
> +- marvell,xenon-phy-tun-step-divider:
> + Set the divider for calculating TUN_STEP.
> + Set as 64 by default if this property is not provided.
> +
> +- marvell,xenon-phy-slow-mode:
> + If this property is selected, transfers will bypass PHY.
> + Only available when bus frequency lower than 55MHz in SDR mde.
> + Disabled by default. Please only try this property if timing issues always
> + occur with PHY enabled in eMMC HS SDR, SD SDR12, SD SDR25, SD SDR50 mode.
> +
> +- marvell,xenon-tun-count:
> + Xenon SDHC SoC usually doesn't provide re-tuning counter in
> + Capabilities Register 3 Bit[11:8].
> + This property provides the re-tuning counter.
> + If this property is not set, default re-tuning counter will
> + be set as 0x9 in driver.
> +
> +- marvell,pad-type:
> + Type of Armada 3700 SoC PHY PAD Voltage Controller register.
> + Only valid when "marvell,armada-3700-sdhci" is selected.
> + Two types: "sd" and "fixed-1-8v".
> + If "sd" is slected, SoC PHY PAD is set as 3.3V at the beginning and is
> + switched to 1.8V when SD in UHS-I.
> + If "fixed-1-8v" is slected, SoC PHY PAD is fixed 1.8V, such as for eMMC.
> + Please follow the examples with compatible "marvell,armada-3700-sdhci"
> + in below.
> +
> +Example:
> +- For eMMC:
> +
> + sdhci@aa0000 {
> + compatible = "marvell,armada-8k-sdhci";
> + reg = <0xaa0000 0x1000>;
> + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>
> + clocks = <&emmc_clk>;
> + clock-names = "core";
> + bus-width = <8>;
> + mmc-ddr-1_8v;
> + mmc-hs400-1_8v;
> + marvell,xenon-sdhc-id = <0>;
Should be dropped? With that,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH 1/2] usb: host: add a generic platform USB roothub driver
From: Martin Blumenstingl @ 2017-01-13 20:21 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA, mark.rutland-5wv7dgnIgG8,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
vegard.nossum-QHcLZuEGTsvQT0dZR+AlfA,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
treding-DDmLM1+adcrQT0dZR+AlfA, geert-Td1EMuHUCqxL1ZNQvxDV9g,
manjunath.goudar-QSEj5FYQhm4dnm+yROfE0A, arnd-r2nGTMty4D4,
tony-4v6yS6AI5VpBDgjK7y7TUQ, ahaslam-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <20170113200850.6z3i3b762pkjwlcc@rob-hp-laptop>
Hi Rob,
On Fri, Jan 13, 2017 at 9:08 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Jan 11, 2017 at 04:29:46PM +0100, Martin Blumenstingl wrote:
>> Many SoC platforms have separate devices for the USB PHY which are
>> registered through the generic PHY framework. These PHYs have to be
>> enabled to make the USB controller actually work. They also have to be
>> disabled again on shutdown/suspend.
>>
>> Currently (at least) the following HCI platform drivers are using custom
>> code to obtain all PHYs via devicetree for the roothub/controller and
>> disable/enable them when required:
>> - ehci-platform.c has ehci_platform_power_{on,off}
>> - xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}
>> - ohci-platform.c has ohci_platform_power_{on,off}
>>
>> These drivers are not using the generic devicetree USB device bindings
>> yet which were only introduced recently (documentation is available in
>> devicetree/bindings/usb/usb-device.txt).
>> With this new driver the usb2-phy and usb3-phy can be specified directly
>> in the child-node of the corresponding port of the roothub via
>> devicetree. This can be extended by not just parsing PHYs (some of the
>> other drivers listed above are for example also parsing a list of clocks
>> as well) when required.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>> ---
>> .../devicetree/bindings/usb/usb-roothub.txt | 41 ++++++
>> drivers/usb/host/Kconfig | 3 +
>> drivers/usb/host/Makefile | 2 +
>> drivers/usb/host/platform-roothub.c | 146 +++++++++++++++++++++
>> drivers/usb/host/platform-roothub.h | 14 ++
>> 5 files changed, 206 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/usb/usb-roothub.txt
>> create mode 100644 drivers/usb/host/platform-roothub.c
>> create mode 100644 drivers/usb/host/platform-roothub.h
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-roothub.txt b/Documentation/devicetree/bindings/usb/usb-roothub.txt
>> new file mode 100644
>> index 000000000000..96e152d3901c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/usb-roothub.txt
>> @@ -0,0 +1,41 @@
>> +Generic USB root-hub Properties
>> +
>> +similar to the USB device bindings (documented in usb-device.txt from the
>> +current directory) this provides support for configuring the root-hub.
>> +
>> +Required properties:
>> +- compatible: should be at least one of "usb1d6b,3", "usb1d6b,2"
>> +- reg: must be 0.
>> +- address-cells: must be 1
>> +- size-cells: must be 0
>
>> +- a sub-node per port supports the following properties:
>
> Make this another section with required and optional sections.
I can do that, but let's wait for the results if we want the PHYs to
be specified at the grand-child or child level
>> + - reg: the port number on the root-hub (mandatory)
>> + - phys: optional, from the *Generic PHY* bindings (mandatory needed when
>> + phy-names is given)
>> + - phy-names: optional, from the *Generic PHY* bindings; supported names
>> + are "usb2-phy" or "usb3-phy"
>> +
>> +Example:
>> + &usb1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + roothub@0 {
>> + compatible = "usb1d6b,3", "usb1d6b,2";
>
> Is this discoverable? IIRC, we had decided that ports on the root hub
> are just children of the USB controller node (rather than
> grandchildren). Why does that not work?
if I understand you correctly you are thinking of something like this:
&usb1 {
...cells...
port@1 {
reg = <1>;
phys = <&phy2>
}
port@2 {
reg = <2>;
phys = <&phy2>
}
}
in that case we need a way to differentiate between "actual device at
port 1" and "configuration for root-hub port 1".
in that example I also cannot specify a compatible string since I
don't know which device might be plugged into that port.
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0>;
>> +
>> + port@1 {
>
> Wouldn't this normally be 0 and 1. This should probably be usb-port
> rather than port to avoid OF graph overlap.
the USB subsystem starts counting at 1, there can never be a "device
with device-number 0" - so I think we should stay with 1 and 2 for a
2-port roothub.
I'm fine with changing the name to "usb-port" though
>> + reg = <1>;
>> + usb-phy = <&usb2_phy1>, <&usb3_phy1>;
>
> s/usb-phy/phys/
thanks for spotting this
>> + phy-names = "usb2-phy", "usb3-phy";
>> + };
>> +
>> + port@2 {
>> + reg = <2>;
>> + usb-phy = <&usb2_phy2>, <&usb3_phy2>;
>> + phy-names = "usb2-phy", "usb3-phy";
>> + };
>> + };
>> + }
--
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
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