* Re: [PATCH net-next v2 07/10] net: bcmgenet: add MDIO routines
From: Mark Rutland @ 2014-02-13 11:50 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, davem@davemloft.net, cernekee@gmail.com,
devicetree@vger.kernel.org
In-Reply-To: <1392269395-23513-8-git-send-email-f.fainelli@gmail.com>
On Thu, Feb 13, 2014 at 05:29:52AM +0000, Florian Fainelli wrote:
> This patch adds support for configuring the port multiplexer hardware
> which resides in front of the GENET Ethernet MAC controller. This allows
> us to support:
>
> - internal PHYs (using drivers/net/phy/bcm7xxx.c)
> - MoCA PHYs which are an entirely separate hardware block not covered
> here
> - external PHYs and switches
>
> Note that MoCA and switches are currently supported using the emulated
> "fixed PHY" driver.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Changes since v1:
> - fixed MDIO crash/warning when Device Tree probing fails
> - removed the use of priv->phy_type and use priv->phy_interface
> directly
>
> drivers/net/ethernet/broadcom/genet/bcmmii.c | 481 +++++++++++++++++++++++++++
> 1 file changed, 481 insertions(+)
> create mode 100644 drivers/net/ethernet/broadcom/genet/bcmmii.c
[...]
> +static int bcmgenet_mii_of_init(struct bcmgenet_priv *priv)
> +{
> + struct device_node *dn = priv->pdev->dev.of_node;
> + struct device *kdev = &priv->pdev->dev;
> + struct device_node *mdio_dn;
> + const __be32 *fixed_link;
This looks a bit odd. Could we not have a common parser for fixed-link
properties?
> + u32 propval;
> + int ret, sz;
> +
> + mdio_dn = of_get_next_child(dn, NULL);
> + if (!mdio_dn) {
> + dev_err(kdev, "unable to find MDIO bus node\n");
> + return -ENODEV;
> + }
Could you please check that this is the node you expect (by looking at
the compatible string list).
> +
> + ret = of_mdiobus_register(priv->mii_bus, mdio_dn);
> + if (ret) {
> + dev_err(kdev, "failed to register MDIO bus\n");
> + return ret;
> + }
> +
> + /* Check if we have an internal or external PHY */
> + priv->phy_dn = of_parse_phandle(dn, "phy-handle", 0);
> + if (priv->phy_dn) {
> + if (!of_property_read_u32(priv->phy_dn, "max-speed", &propval))
> + priv->phy_speed = propval;
Is there no way to find this out without reading values directly off of
the PHY? It seems like something we should have an abstraction for.
> + } else {
> + /* Read the link speed from the fixed-link property */
> + fixed_link = of_get_property(dn, "fixed-link", &sz);
> + if (!fixed_link || sz < sizeof(*fixed_link)) {
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + priv->phy_speed = be32_to_cpu(fixed_link[2]);
Similarly can we not have a common fixed-link parser? Or abstraction
such that you query the phy regardless of what it is and how its binding
represents this?
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH] pci: Add support for creating a generic host_bridge from device tree
From: Russell King - ARM Linux @ 2014-02-13 11:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linaro-kernel, devicetree, 'linux-pci', Jingoo Han,
'LKML', 'Tanmay Inamdar',
'Catalin Marinas', 'Bjorn Helgaas',
'LAKML'
In-Reply-To: <3204351.WykFFcX4zJ@wuerfel>
On Thu, Feb 13, 2014 at 12:27:05PM +0100, Arnd Bergmann wrote:
> I would rather get rid of struct hw_pci for architecture independent
> drivers and add a different registration method on arm32 that is
> compatible with what we come up with on arm64. The main purpose of
> hw_pci is to allow multiple PCI controllers to be initialized at
> once, but we don't actually need that for any of the "modern" platforms
> where we already have a probe function that gets called once for
> each controller.
No. The main purpose of hw_pci is as a container to support multiple
different platform specific PCI implementations in one kernel. It's
exactly what you need for single zImage.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* Re: [RFC] dt: bindings: add bindings for Broadcom bcm43xx sdio devices
From: Arend van Spriel @ 2014-02-13 12:07 UTC (permalink / raw)
To: Tomasz Figa, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <52FC8CB3.4090305-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 02/13/2014 10:13 AM, Tomasz Figa wrote:
> Hi Arend,
>
> On 10.02.2014 20:17, Arend van Spriel wrote:
>> The Broadcom bcm43xx sdio devices are fullmac devices that may be
>> integrated in ARM platforms. Currently, the brcmfmac driver for
>> these devices support use of platform data. This patch specifies
>> the bindings that allow this platform data to be expressed in the
>> devicetree.
>>
>> Cc: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> Cc: Tomasz Figa <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Reviewed-by: Hante Meuleman <meuleman-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>> Reviewed-by: Pieter-Paul Giesberts <pieterpg-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>> Signed-off-by: Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>> ---
>> This devicetree binding proposal is intended for platforms with
>> Broadcom wireless device in MMC sdio slot. These devices may
>> have their own interrupt and power line. Also the SDIO drive
>> strength is often hardware dependent and expressed in this
>> binding.
>>
>> Not sure if this should go in staging or not. Feel free to
>> comment on this proposal.
>>
>> Regards,
>> Arend
>> ---
>> .../staging/net/wireless/brcm,bcm43xx-fmac.txt | 37
>> ++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/staging/net/wireless/brcm,bcm43xx-fmac.txt
>>
>>
>> diff --git
>> a/Documentation/devicetree/bindings/staging/net/wireless/brcm,bcm43xx-fmac.txt
>> b/Documentation/devicetree/bindings/staging/net/wireless/brcm,bcm43xx-fmac.txt
>>
>> new file mode 100644
>> index 0000000..535f343
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/staging/net/wireless/brcm,bcm43xx-fmac.txt
>>
>> @@ -0,0 +1,37 @@
>> +Broadcom BCM43xx Fullmac wireless SDIO devices
>> +
>> +This node provides properties for controlling the Broadcom wireless
>> device. The
>> +node is expected to be specified as a child node to the MMC
>> controller that
>> +connects the device to the system.
>> +
>> +Required properties:
>> +
>> + - compatible : Should be "brcm,bcm43xx-fmac".
>> + - wlan-supply : phandle for fixed regulator used to control power for
>> + the device/module.
>
> The BCM43xx WLAN chips I used to work always have been controlled by a
> simple power enable GPIO of the chip itself. Has this changed in newer
> chips?
>
> If you need to simply toggle a GPIO to control the power, you don't need
> to use the regulator API at all, controlling the GPIO directly.
Not sure I understand. Do you really mean 'chip' or 'wifi module' here.
The chip needs to be powered and for that it is hooked up to a
host/module provided GPIO (at least that is my understanding).
>> +
>> +Optional properties:
>> + - drive-strength : drive strength used for SDIO pins on device
>> (default = 6mA).
>
> This should be a part of the MMC binding, I think. Probably also moved
> under MMC controller's node, since it's a board-specific property
> altering the parameters of the MMC controller, not the WLAN chip.
It is an electrical interfacing parameter between MMC controller and the
device. The specified drive-strength here is used to configure the PMU
on the chip so it is really related to the the chip.
>> + - interrupt-parent : the phandle for the interrupt controller to
>> which the
>> + device interrupt (HOST_WAKE) is connected.
>> + - interrupts : interrupt specifier encoded according the interrupt
>> controller
>> + specified by interrupt-parent property.
>
> I would also add a clock here, since the BCM43xx chips usually need a
> 32k clock to operate (or at least the ones I used to work with did). It
> can be optional, as not all systems can control this clock.
>
>> +
>> +Example:
>> +
>> +mmc3: mmc@01c20000 {
>> + pinctrl-0 = <&mmc3_pins>;
>> + pinctrl-1 = <&wifi_host_wake>;
>
> WLAN_HOST_WAKE pin (aka the OOB interrupt) is specific to the WLAN chip,
> so this should be rather configured in a pinctrl state of the WLAN chip
> itself.
You mean that pinctrl-1 should move inside the "brcm,bcm43xx-fmac" node,
right?
>> + vmmc-supply = <&mmc3_supply>;
>> + bus-width = <4>;
>> +
>> + bcm4335: bcm4335@0 {
>
> nit: Why @0, if there is no reg property under this node?
I am not fluent with devicetree specifications (yet) nor know all the
conventions.
> Best regards,
> Tomasz
Thanks,
Arend
>> + compatible = "brcm,bcm43xx-fmac";
>> + wlan-supply = <&wlan-reg>;
>> + drive-strength = <4>;
>> + interrupt-parent = <&gpx2>;
>> + interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "HOST_WAKE";
>> + };
>> +};
>> +
>>
--
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] pci: Add support for creating a generic host_bridge from device tree
From: Arnd Bergmann @ 2014-02-13 12:15 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
devicetree-u79uwXL29TY76Z2rM5mHXA, 'linux-pci',
Jingoo Han, 'LKML', 'Tanmay Inamdar',
'Catalin Marinas', 'Bjorn Helgaas',
'LAKML'
In-Reply-To: <20140213115327.GV26684-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
On Thursday 13 February 2014 11:53:27 Russell King - ARM Linux wrote:
> On Thu, Feb 13, 2014 at 12:27:05PM +0100, Arnd Bergmann wrote:
> > I would rather get rid of struct hw_pci for architecture independent
> > drivers and add a different registration method on arm32 that is
> > compatible with what we come up with on arm64. The main purpose of
> > hw_pci is to allow multiple PCI controllers to be initialized at
> > once, but we don't actually need that for any of the "modern" platforms
> > where we already have a probe function that gets called once for
> > each controller.
>
> No. The main purpose of hw_pci is as a container to support multiple
> different platform specific PCI implementations in one kernel. It's
> exactly what you need for single zImage.
Well, we definitely need something to manage the assignment of domains,
bus numbers and I/O space windows, but the main issue I see with existing
hw_pci container is that it assumes that you can pass give it all
host bridges for a given domain at once. The problem with this is
that the pci host bridge drivers don't interact with one another, so
a system that needs two different PCI host drivers can't use hw_pci
to register them both, unless we come up with some extra
infrastructure.
Also, the calling conventions for pci_common_init_dev() mean that
it's hard to propagate -EPROBE_DEFER errors back to the driver
probe function, so it seems easier to come up with something new
that deals with all issues at once and that is outside of architecture
specific code.
Arnd
--
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] pci: Add support for creating a generic host_bridge from device tree
From: Liviu Dudau @ 2014-02-13 12:20 UTC (permalink / raw)
To: Jingoo Han
Cc: 'Tanmay Inamdar', 'Arnd Bergmann',
devicetree@vger.kernel.org, 'linaro-kernel',
'linux-pci', Will Deacon, 'LKML', Catalin Marinas,
'Bjorn Helgaas', 'LAKML'
In-Reply-To: <000001cf2899$a6eb75b0$f4c26110$%han@samsung.com>
On Thu, Feb 13, 2014 at 08:57:41AM +0000, Jingoo Han wrote:
>
>
> > -----Original Message-----
> > From: Tanmay Inamdar [mailto:tinamdar@apm.com]
> > Sent: Thursday, February 13, 2014 5:37 PM
> > To: Jingoo Han
> > Cc: Liviu Dudau; Arnd Bergmann; devicetree@vger.kernel.org; linaro-kernel; linux-pci; Will Deacon;
> > LKML; Catalin Marinas; Bjorn Helgaas; LAKML
> > Subject: Re: [PATCH] pci: Add support for creating a generic host_bridge from device tree
> >
> > On Thu, Feb 13, 2014 at 12:10 AM, Jingoo Han <jg1.han@samsung.com> wrote:
> > > On Thursday, February 06, 2014 7:18 PM, Liviu Dudau wrote:
> > >> On Wed, Feb 05, 2014 at 10:26:27PM +0000, Tanmay Inamdar wrote:
> > >> > Hello Liviu,
> > >> >
> > >> > I did not get the first email of this particular patch on any of
> > >> > subscribed mailing lists (don't know why), hence replying here.
> > >>
> > >> Strange, it shows in the MARC and GMANE archive for linux-pci, probably
> > >> a hickup on your receiving side?
> > >>
> > >> >
> > >> > +struct pci_host_bridge *
> > >> > +pci_host_bridge_of_init(struct device *parent, int busno, struct pci_ops *ops,
> > >> > + void *host_data, struct list_head *resources)
> > >> > +{
> > >> > + struct pci_bus *root_bus;
> > >> > + struct pci_host_bridge *bridge;
> > >> > +
> > >> > + /* first parse the host bridge bus ranges */
> > >> > + if (pci_host_bridge_of_get_ranges(parent->of_node, resources))
> > >> > + return NULL;
> > >> > +
> > >> > + /* then create the root bus */
> > >> > + root_bus = pci_create_root_bus(parent, busno, ops, host_data, resources);
> > >> > + if (!root_bus)
> > >> > + return NULL;
> > >> > +
> > >> > + bridge = to_pci_host_bridge(root_bus->bridge);
> > >> > +
> > >> > + return bridge;
> > >> > +}
> > >> >
> > >> > You are keeping the domain_nr inside pci_host_bridge structure. In
> > >> > above API, domain_nr is required in 'pci_find_bus' function called
> > >> > from 'pci_create_root_bus'. Since the bridge is allocated after
> > >> > creating root bus, 'pci_find_bus' always gets domain_nr as 0. This
> > >> > will cause problem for scanning multiple domains.
> > >>
> > >> Good catch. I was switching between creating a pci_controller in arch/arm64 and
> > >> adding the needed bits in pci_host_bridge. After internal review I've decided to
> > >> add the domain_nr to pci_host_bridge, but forgot to update the code everywhere.
> > >
> > > Hi Liviu Dudau,
> > >
> > > One more thing,
> > > I am reviewing and compiling your patch.
> > > Would you consider adding 'struct pci_sys_data' and 'struct hw_pci'?
> > >
> > > Currently, 4 PCIe Host drivers (pci-mvebu.c, pci-tegra.c,
> > > pci-rcar-gen2.c, pcie-designware.c) are using 'struct pci_sys_data'
> > > and 'struct hw_pci' in their drivers. Without this, it makes build
> > > errors.
> > >
> > > In arm32, 'struct pci_sys_data' and 'struct hw_pci' is defined
> > > in "arch/arm/include/asm/mach/pci.h".
> > >
> > > Tanmay Inamdar,
> > > Your 'APM X-Gene PCIe' patch also needs 'struct pci_sys_data' and
> > > 'struct hw_pci'. With Liviu Dudau's patch, it will make build
> > > errors. Would you check this?
> >
> > X-Gene PCIe host driver is dependent on arm64 PCI patch. My previous
> > approach was based on 32bit arm PCI support. With Liviu's approach, I
> > will have to make changes in host driver to get rid of hw_pci and
> > pci_sys_data which are no longer required.
>
> I want to use 'drivers/pci/host/pcie-designware.c' for both arm32
> and arm64, without any code changes. However, it looks impossible.
>
> I made 'drivers/pci/host/pcie-designware.c' based on 32bit arm PCI
> support. Then, with Liviu's patch, do I have to make new code for arm64,
> even though the same HW PCIe IP is used?
Hi Jingoo,
Arnd has asked about the transition path for 32bit arm PCI host bridges
and I don't think we came up with a solution yet. My preferred solution
would be to modify the arch/arm API to be more in line with the generic
code and not have to use hw_pci and pci_sys_data anymore. That should
fix your problem of having a single code base for your host controller.
If you look at the pci_sys_data and hw_pci structures, you can see that
there is a bit of duplication between the two and also that some of the
data contained in that structure is generic enough to be contained in
the PCI infrastructure code rather than down in the arch-dependent code.
I confess that I have no in-depth knowledge of the reasons why the arm
code looks like this and if it is still required with the current
infrastructure code. Russell can provide us with entertaining stories here,
I'm sure, on why the code looks like it does.
I have not done any work in this area yet, but if I were to update the
generic arm code I would try to make the code use the pci_host_bridge
structure rather than pci_sys_data. The hw_pci will disappear with the new
APIs.
>
> - For arm32
> drivers/pci/host/pcie-designware.c
>
> - For arm64
> drivers/pci/host/pcie-designware-arm64.c
>
>
> >
> > IMO it should not cause build errors for PCI host drivers dependent on
> > architectures other than arm64. Can you post the error?
> >
>
> I post the build errors.
IMHO it is not worth trying to have the host bridge code cope with two APIs.
It's going to lead to problems no matter what.
Best regards,
Liviu
>
> CC drivers/pci/host/pcie-designware.o
> CHK kernel/config_data.h
> drivers/pci/host/pcie-designware.c:72:52: warning: 'struct pci_sys_data' declared inside parameter list [enabled by default]
> static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys)
> ^
> drivers/pci/host/pcie-designware.c:72:52: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> drivers/pci/host/pcie-designware.c: In function 'sys_to_pcie'
> drivers/pci/host/pcie-designware.c:74:12: error: dereferencing pointer to incomplete type
> return sys->private_data;
> ^
> drivers/pci/host/pcie-designware.c: In function 'dw_pcie_msi_map'
> drivers/pci/host/pcie-designware.c:384:2: error: implicit declaration of function 'set_irq_flags' [-Werror=implicit-function-declaration]
> set_irq_flags(irq, IRQF_VALID);
> ^
> drivers/pci/host/pcie-designware.c:384:21: error: 'IRQF_VALID??undeclared (first use in this function)
> set_irq_flags(irq, IRQF_VALID);
> ^
> drivers/pci/host/pcie-designware.c:384:21: note: each undeclared identifier is reported only once for each function it appears in
> drivers/pci/host/pcie-designware.c: In function 'dw_pcie_host_init'
> drivers/pci/host/pcie-designware.c:492:2: error: invalid use of undefined type 'struct hw_pci'
> dw_pci.nr_controllers = 1;
> ^
> drivers/pci/host/pcie-designware.c:493:2: error: invalid use of undefined type 'struct hw_pci'
> dw_pci.private_data = (void **)&pp;
> ^
> drivers/pci/host/pcie-designware.c:495:2: error: implicit declaration of function 'pci_common_init' [-Werror=implicit-function-declaration]
> pci_common_init(&dw_pci);
> ^
> drivers/pci/host/pcie-designware.c:498:2: error: invalid use of undefined type 'struct hw_pci'
> dw_pci.domain++;
> ^
> drivers/pci/host/pcie-designware.c: At top level:
> drivers/pci/host/pcie-designware.c:698:41: warning: 'struct pci_sys_data??declared inside parameter list [enabled by default]
> static int dw_pcie_setup(int nr, struct pci_sys_data *sys)
> ^
> drivers/pci/host/pcie-designware.c: In function 'dw_pcie_setup'
> drivers/pci/host/pcie-designware.c:702:2: warning: passing argument 1 of 'sys_to_pcie' from incompatible pointer type [enabled by default]
> pp = sys_to_pcie(sys);
> ^
> drivers/pci/host/pcie-designware.c:72:33: note: expected 'struct pci_sys_data *' but argument is of type 'struct pci_sys_data *'
> static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys)
> ^
> drivers/pci/host/pcie-designware.c:708:6: error: dereferencing pointer to incomplete type
> sys->io_offset = global_io_offset - pp->config.io_bus_addr;
> ^
> drivers/pci/host/pcie-designware.c:711:31: error: dereferencing pointer to incomplete type
> pci_add_resource_offset(&sys->resources, &pp->io,
> ^
> drivers/pci/host/pcie-designware.c:712:9: error: dereferencing pointer to incomplete type
> sys->io_offset);
> ^
> drivers/pci/host/pcie-designware.c:715:5: error: dereferencing pointer to incomplete type
> sys->mem_offset = pp->mem.start - pp->config.mem_bus_addr;
> ^
> drivers/pci/host/pcie-designware.c:716:30: error: dereferencing pointer to incomplete type
> pci_add_resource_offset(&sys->resources, &pp->mem, sys->mem_offset);
> ^
> drivers/pci/host/pcie-designware.c:716:56: error: dereferencing pointer to incomplete type
> pci_add_resource_offset(&sys->resources, &pp->mem, sys->mem_offset);
> ^
> drivers/pci/host/pcie-designware.c: At top level:
> drivers/pci/host/pcie-designware.c:721:56: warning: 'struct pci_sys_data' declared inside parameter list [enabled by default]
> static struct pci_bus *dw_pcie_scan_bus(int nr, struct pci_sys_data *sys)
> ^
> drivers/pci/host/pcie-designware.c: In function 'dw_pcie_scan_bus'
> drivers/pci/host/pcie-designware.c:724:9: warning: passing argument 1 of 'sys_to_pcie' from incompatible pointer type [enabled by default]
> struct pcie_port *pp = sys_to_pcie(sys);
> ^
> drivers/pci/host/pcie-designware.c:72:33: note: expected 'struct pci_sys_data *' but argument is of type 'sruct pci_sys_data *'
> static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys)
> ^
> drivers/pci/host/pcie-designware.c:727:24: error: dereferencing pointer to incomplete type
> pp->root_bus_nr = sys->busnr;
> ^
> drivers/pci/host/pcie-designware.c:728:36: error: dereferencing pointer to incomplete type
> bus = pci_scan_root_bus(NULL, sys->busnr, &dw_pcie_ops,
> ^
> drivers/pci/host/pcie-designware.c:729:15: error: dereferencing pointer to incomplete type
> sys, &sys->resources);
> ^
> drivers/pci/host/pcie-designware.c: At top level:
> drivers/pci/host/pcie-designware.c:755:15: error: variable 'dw_pci' has initializer but incomplete type
> static struct hw_pci dw_pci = {
> ^
> drivers/pci/host/pcie-designware.c:756:2: error: unknown field 'setup' specified in initializer
> .setup = dw_pcie_setup,
> ^
> drivers/pci/host/pcie-designware.c:756:2: warning: excess elements in struct initializer [enabled by default]
> drivers/pci/host/pcie-designware.c:756:2: warning: (near initialization for 'dw_pci' [enabled by default]
> drivers/pci/host/pcie-designware.c:757:2: error: unknown field 'scan' specified in initializer
> .scan = dw_pcie_scan_bus,
> ^
> drivers/pci/host/pcie-designware.c:757:2: warning: excess elements in struct initializer [enabled by default]
> drivers/pci/host/pcie-designware.c:757:2: warning: (near initialization for 'dw_pci' [enabled by default]
> drivers/pci/host/pcie-designware.c:758:2: error: unknown field 'map_irq' specified in initializer
> .map_irq = dw_pcie_map_irq,
> ^
> drivers/pci/host/pcie-designware.c:758:2: warning: excess elements in struct initializer [enabled by default]
> drivers/pci/host/pcie-designware.c:758:2: warning: (near initialization for 'dw_pci' [enabled by default]
> drivers/pci/host/pcie-designware.c:759:2: error: unknown field 'add_bus' specified in initializer
> .add_bus = dw_pcie_add_bus,
> ^
> drivers/pci/host/pcie-designware.c:759:2: warning: excess elements in struct initializer [enabled by default]
> drivers/pci/host/pcie-designware.c:759:2: warning: (near initialization for 'dw_pci' [enabled by default]
> cc1: some warnings being treated as errors
> make[3]: *** [drivers/pci/host/pcie-designware.o] Error 1
>
>
> > >
> > >>
> > >> Thanks for reviewing this, will fix in v2.
> > >>
> > >> Do you find porting to the new API straight forward?
> > >>
> > >
>
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
From: Mark Rutland @ 2014-02-13 12:23 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
alexandre.torgue-qxv4g6HH51o@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Srinivas Kandagatla
In-Reply-To: <20140213110314.GH32508@lee--X1>
On Thu, Feb 13, 2014 at 11:03:14AM +0000, Lee Jones wrote:
> > > The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
> > > devices. It has 2 ports which it can use for either; both SATA, both
> > > PCIe or one of each in any configuration.
> > >
> > > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > Cc: Srinivas Kandagatla <srinivas.kandagatla-qxv4g6HH51o@public.gmane.org>
> > > Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > > ---
> > > .../devicetree/bindings/phy/phy-miphy365x.txt | 43 ++++++++++++++++++++++
> > > 1 file changed, 43 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > > new file mode 100644
> > > index 0000000..fdfa7ca
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> > > @@ -0,0 +1,43 @@
> > > +STMicroelectronics STi MIPHY365x PHY binding
> > > +============================================
> > > +
> > > +This binding describes a miphy device that is used to control PHY hardware
> > > +for SATA and PCIe.
> > > +
> > > +Required properties:
> > > +- compatible: Should be "st,miphy365x-phy"
> > > +- #phy-cells: Should be 2 (See example)
> >
> > The first example has #phy-cells = <1>.
>
> Right, will fix. Should be 2.
>
> > What do the cells mean? What are the expected values?
>
> http://www.spinics.net/lists/arm-kernel/msg307209.html
Ok. Could that be mentioned in the binding document then?
Cheers,
Mark.
--
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 0/9] OMAP DSS DT bindings documentation
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
Hi,
Here is DT binding documentation for OMAP Display Subsystem. I've sent these
earlier as part of the whole DSS DT series, but I'm now sending them separately
to get comments for them.
These patches are essentially the same as what I already sent earlier. The only
difference is that I added clock information for omap3 and omap4 platforms.
Tomi
Tomi Valkeinen (9):
Doc/DT: Add OMAP DSS DT Bindings
Doc/DT: Add DT binding documentation for Analog TV Connector
Doc/DT: Add DT binding documentation for DVI Connector
Doc/DT: Add DT binding documentation for HDMI Connector
Doc/DT: Add DT binding documentation for MIPI DPI Panel
Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
Doc/DT: Add DT binding documentation for Sony acx565akm panel
Doc/DT: Add DT binding documentation for TFP410 encoder
Doc/DT: Add DT binding documentation for tpd12s015 encoder
.../bindings/video/analog-tv-connector.txt | 23 +++
.../devicetree/bindings/video/dvi-connector.txt | 26 +++
.../devicetree/bindings/video/hdmi-connector.txt | 23 +++
.../devicetree/bindings/video/panel-dpi.txt | 43 +++++
.../devicetree/bindings/video/panel-dsi-cm.txt | 26 +++
.../devicetree/bindings/video/sony,acx565akm.txt | 28 +++
.../devicetree/bindings/video/ti,omap-dss.txt | 203 +++++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 ++++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 83 +++++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 111 +++++++++++
.../devicetree/bindings/video/ti,tfp410.txt | 41 +++++
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 +++++
.../devicetree/bindings/video/video-ports.txt | 22 +++
13 files changed, 727 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt
create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
create mode 100644 Documentation/devicetree/bindings/video/video-ports.txt
--
1.8.3.2
--
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 1/9] Doc/DT: Add OMAP DSS DT Bindings
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add device tree bindings for OMAP Display Subsystem for the following
SoCs: OMAP2, OMAP3, OMAP4.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
.../devicetree/bindings/video/ti,omap-dss.txt | 203 +++++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 ++++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 83 +++++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 111 +++++++++++
.../devicetree/bindings/video/video-ports.txt | 22 +++
5 files changed, 473 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/video-ports.txt
diff --git a/Documentation/devicetree/bindings/video/ti,omap-dss.txt b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
new file mode 100644
index 000000000000..928d3dc6f8dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
@@ -0,0 +1,203 @@
+Texas Instruments OMAP Display Subsystem
+========================================
+
+Generic Description
+-------------------
+
+This document is a generic description of the OMAP Display Subsystem bindings.
+Binding details for each OMAP SoC version are described in respective binding
+documentation.
+
+The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and
+a number of encoder modules. All DSS versions contain DSS Core and DISPC, but
+the encoder modules vary.
+
+The DSS Core is the parent of the other DSS modules, and manages clock routing,
+integration to the SoC, etc.
+
+DISPC is the display controller, which reads pixels from the memory and outputs
+a RGB pixel stream to encoders.
+
+The encoder modules encode the received RGB pixel stream to a video output like
+HDMI, MIPI DPI, etc.
+
+Video Ports
+-----------
+
+The DSS Core and the encoders have video port outputs. The structure of the
+video ports is described in Documentation/devicetree/bindings/video/video-
+ports.txt, and the properties for the ports and endpoints for each encoder are
+described in the SoC's DSS binding documentation.
+
+The video ports are used to describe the connections to external hardware, like
+panels or external encoders.
+
+Aliases
+-------
+
+The board dts file may define aliases for displays to assign "displayX" style
+name for each display. If no aliases are defined, a semi-random number is used
+for the display.
+
+Example
+-------
+
+A shortened example of the DSS description for OMAP4, with non-relevant parts
+removed, defined in omap4.dtsi:
+
+dss: dss@58000000 {
+ compatible = "ti,omap4-dss", "simple-bus";
+ reg = <0x58000000 0x80>;
+ status = "disabled";
+ ti,hwmods = "dss_core";
+ clocks = <&dss_dss_clk>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc@58001000 {
+ compatible = "ti,omap4-dispc";
+ reg = <0x58001000 0x1000>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ ti,hwmods = "dss_dispc";
+ clocks = <&dss_dss_clk>;
+ clock-names = "fck";
+ };
+
+ hdmi: encoder@58006000 {
+ compatible = "ti,omap4-hdmi";
+ reg = <0x58006000 0x200>,
+ <0x58006200 0x100>,
+ <0x58006300 0x100>,
+ <0x58006400 0x1000>;
+ reg-names = "wp", "pll", "phy", "core";
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ ti,hwmods = "dss_hdmi";
+ clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
+ clock-names = "fck", "sys_clk";
+ };
+};
+
+A shortened example of the board description for OMAP4 Panda board, defined in
+omap4-panda.dts.
+
+The Panda board has a DVI and a HDMI connector, and the board contains a TFP410
+chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level
+shifter). The video pipelines for the connectors are formed as follows:
+
+DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector
+OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI COnnector
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ display1 = &hdmi0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; /* 0, power-down */
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tfp410_pins>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@0 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = "dvi-connector";
+ label = "dvi";
+
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+
+ tpd12s015: encoder@1 {
+ compatible = "ti,tpd12s015";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tpd12s015_pins>;
+
+ gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */
+ <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */
+ <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint@0 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@1 {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_dpi_pins>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+};
+
+&hdmi {
+ status = "ok";
+ vdda-supply = <&vdac>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_hdmi_pins>;
+
+ hdmi_out: endpoint {
+ remote-endpoint = <&tpd12s015_in>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/video/ti,omap2-dss.txt b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
new file mode 100644
index 000000000000..fa8bb2ed1170
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
@@ -0,0 +1,54 @@
+Texas Instruments OMAP2 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap2-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+
+Optional nodes:
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap2-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap2-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap2-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+
+VENC Endpoint required properties:
+
+Required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
diff --git a/Documentation/devicetree/bindings/video/ti,omap3-dss.txt b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
new file mode 100644
index 000000000000..0023fa4b1328
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
@@ -0,0 +1,83 @@
+Texas Instruments OMAP3 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap3-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video ports:
+ - Port 0: DPI output
+ - Port 1: SDI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+SDI Endpoint required properties:
+- datapairs: number of datapairs used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap3-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap3-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap3-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap3-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
new file mode 100644
index 000000000000..f85d6fcfa705
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
@@ -0,0 +1,111 @@
+Texas Instruments OMAP4 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap4-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Required nodes:
+- DISPC
+
+Optional nodes:
+- DSS Submodules: RFBI, VENC, DSI, HDMI
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap4-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap4-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+Optional nodes:
+- Video port for RFBI output
+- RFBI controlled peripherals
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap4-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video port for VENC output
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap4-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1" or "dss_dsi2"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for DSI output
+- DSI controlled peripherals
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
+
+
+HDMI
+----
+
+Required properties:
+- compatible: "ti,omap4-hdmi"
+- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy',
+ 'core'
+- reg-names: "wp", "pll", "phy", "core"
+- interrupts: the HDMI interrupt line
+- ti,hwmods: "dss_hdmi"
+- vdda-supply: vdda power supply
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for HDMI output
diff --git a/Documentation/devicetree/bindings/video/video-ports.txt b/Documentation/devicetree/bindings/video/video-ports.txt
new file mode 100644
index 000000000000..dad4c436caae
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/video-ports.txt
@@ -0,0 +1,22 @@
+Video Ports
+===========
+
+The video port bindings used for display devices is a superset of the v4l2 video
+ports described here:
+
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+The only difference is a more compact way to describe devices with only one
+endpoint. In cases like that, the 'ports' and 'port' nodes are not needed. For
+example, a DPI panel with a single input endpoint:
+
+lcd0: display@0 {
+ compatible = "samsung,lte430wq-f0c", "panel-dpi";
+
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+};
+
+The rest of the bindings are the same as in v4l2 video port bindings and not
+described here.
--
1.8.3.2
--
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
* [PATCH 2/9] Doc/DT: Add DT binding documentation for Analog TV Connector
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for Analog TV Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
.../bindings/video/analog-tv-connector.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
new file mode 100644
index 000000000000..d6be373d8705
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
@@ -0,0 +1,23 @@
+Analog TV Connector
+===================
+
+Required properties:
+- compatible: "composite-connector" or "svideo-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+
+Required nodes:
+- Video port for TV input
+
+Example
+-------
+
+tv: connector {
+ compatible = "composite-connector";
+ label = "tv";
+
+ tv_connector_in: endpoint {
+ remote-endpoint = <&venc_out>;
+ };
+};
--
1.8.3.2
--
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
* [PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for DVI Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
.../devicetree/bindings/video/dvi-connector.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt b/Documentation/devicetree/bindings/video/dvi-connector.txt
new file mode 100644
index 000000000000..6a0aff866c78
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/dvi-connector.txt
@@ -0,0 +1,26 @@
+DVI Connector
+==============
+
+Required properties:
+- compatible: "dvi-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
+
+Required nodes:
+- Video port for DVI input
+
+Example
+-------
+
+dvi0: connector@0 {
+ compatible = "dvi-connector";
+ label = "dvi";
+
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+};
--
1.8.3.2
--
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
* [PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for HDMI Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
.../devicetree/bindings/video/hdmi-connector.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt
new file mode 100644
index 000000000000..5d25f6a432bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
@@ -0,0 +1,23 @@
+HDMI Connector
+==============
+
+Required properties:
+- compatible: "hdmi-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+
+Required nodes:
+- Video port for HDMI input
+
+Example
+-------
+
+hdmi0: connector@1 {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+};
--
1.8.3.2
--
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
* [PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for MIPI DPI Panel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
.../devicetree/bindings/video/panel-dpi.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt
diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt b/Documentation/devicetree/bindings/video/panel-dpi.txt
new file mode 100644
index 000000000000..72636c6f1c67
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
@@ -0,0 +1,43 @@
+Generic MIPI DPI Panel
+======================
+
+Required properties:
+- compatible: "panel-dpi"
+
+Optional properties:
+- label: a symbolic name for the panel
+- gpios: panel enable gpio and backlight enable gpio
+
+Required nodes:
+- "panel-timing" containing video timings
+ (Documentation/devicetree/bindings/video/display-timing.txt)
+- Video port for DPI input
+
+Example
+-------
+
+lcd0: display@0 {
+ compatible = "samsung,lte430wq-f0c", "panel-dpi";
+ label = "lcd";
+
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+
+ panel-timing {
+ clock-frequency = <9200000>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <8>;
+ hback-porch = <4>;
+ hsync-len = <41>;
+ vback-porch = <2>;
+ vfront-porch = <4>;
+ vsync-len = <10>;
+
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+};
--
1.8.3.2
--
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
* [PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for MIPI DSI Command Mode Panel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
.../devicetree/bindings/video/panel-dsi-cm.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
diff --git a/Documentation/devicetree/bindings/video/panel-dsi-cm.txt b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
new file mode 100644
index 000000000000..73f422556d4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
@@ -0,0 +1,26 @@
+Generic MIPI DSI Command Mode Panel
+===================================
+
+Required properties:
+- compatible: "panel-dsi-cm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- gpios: panel reset gpio and TE gpio
+
+Required nodes:
+- Video port for DSI input
+
+Example
+-------
+
+lcd0: display {
+ compatible = "tpo,taal", "panel-dsi-cm";
+ label = "lcd0";
+
+ gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */
+
+ lcd0_in: endpoint {
+ remote-endpoint = <&dsi1_out_ep>;
+ };
+};
--
1.8.3.2
--
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
* [PATCH 7/9] Doc/DT: Add DT binding documentation for Sony acx565akm panel
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for Sony acx565akm panel
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Reviewed-by: Sebastian Reichel <sre-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/video/sony,acx565akm.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
diff --git a/Documentation/devicetree/bindings/video/sony,acx565akm.txt b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
new file mode 100644
index 000000000000..cd9cfdf7e3fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
@@ -0,0 +1,28 @@
+Sony ACX565AKM SDI Panel
+========================
+
+Required properties:
+- compatible: "sony,acx565akm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- gpios: panel reset gpio
+
+Required nodes:
+- Video port for SDI input
+
+Example
+-------
+
+acx565akm@2 {
+ compatible = "sony,acx565akm";
+ spi-max-frequency = <6000000>;
+ reg = <2>;
+
+ label = "lcd";
+ gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */
+
+ lcd_in: endpoint {
+ remote-endpoint = <&sdi_out>;
+ };
+};
--
1.8.3.2
--
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
* [PATCH 8/9] Doc/DT: Add DT binding documentation for TFP410 encoder
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for TFP410 encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
.../devicetree/bindings/video/ti,tfp410.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
diff --git a/Documentation/devicetree/bindings/video/ti,tfp410.txt b/Documentation/devicetree/bindings/video/ti,tfp410.txt
new file mode 100644
index 000000000000..6a5a04627584
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,tfp410.txt
@@ -0,0 +1,41 @@
+TFP410 DPI to DVI encoder
+=========================
+
+Required properties:
+- compatible: "ti,tfp410"
+
+Optional properties:
+- gpios: power-down gpio
+
+Required nodes:
+- Video port 0 for DPI input
+- Video port 1 for DVI output
+
+Example
+-------
+
+tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@0 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+};
--
1.8.3.2
--
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
* [PATCH 9/9] Doc/DT: Add DT binding documentation for tpd12s015 encoder
From: Tomi Valkeinen @ 2014-02-13 12:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Tomi Valkeinen
In-Reply-To: <1392294752-18762-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Add DT binding documentation for tpd12s015 encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
---
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 ++++++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
diff --git a/Documentation/devicetree/bindings/video/ti,tpd12s015.txt b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
new file mode 100644
index 000000000000..26e6d32e3f20
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
@@ -0,0 +1,44 @@
+TPD12S015 HDMI level shifter and ESD protection chip
+====================================================
+
+Required properties:
+- compatible: "ti,tpd12s015"
+
+Optional properties:
+- gpios: CT CP HPD, LS OE and HPD gpios
+
+Required nodes:
+- Video port 0 for HDMI input
+- Video port 1 for HDMI output
+
+Example
+-------
+
+tpd12s015: encoder@1 {
+ compatible = "ti,tpd12s015";
+
+ gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */
+ <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */
+ <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint@0 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+};
--
1.8.3.2
--
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: [RFC] dt: bindings: add bindings for Broadcom bcm43xx sdio devices
From: Tomasz Figa @ 2014-02-13 12:35 UTC (permalink / raw)
To: Arend van Spriel, Tomasz Figa, Rob Herring
Cc: devicetree, linux-kernel, Chen-Yu Tsai, Mark Brown
In-Reply-To: <52FCB571.4020904@broadcom.com>
On 13.02.2014 13:07, Arend van Spriel wrote:
> On 02/13/2014 10:13 AM, Tomasz Figa wrote:
>> Hi Arend,
>>
>> On 10.02.2014 20:17, Arend van Spriel wrote:
>>> The Broadcom bcm43xx sdio devices are fullmac devices that may be
>>> integrated in ARM platforms. Currently, the brcmfmac driver for
>>> these devices support use of platform data. This patch specifies
>>> the bindings that allow this platform data to be expressed in the
>>> devicetree.
>>>
>>> Cc: Chen-Yu Tsai <wens@csie.org>
>>> Cc: Tomasz Figa <tomasz.figa@gmail.com>
>>> Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
>>> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
>>> Signed-off-by: Arend van Spriel <arend@broadcom.com>
>>> ---
>>> This devicetree binding proposal is intended for platforms with
>>> Broadcom wireless device in MMC sdio slot. These devices may
>>> have their own interrupt and power line. Also the SDIO drive
>>> strength is often hardware dependent and expressed in this
>>> binding.
>>>
>>> Not sure if this should go in staging or not. Feel free to
>>> comment on this proposal.
>>>
>>> Regards,
>>> Arend
>>> ---
>>> .../staging/net/wireless/brcm,bcm43xx-fmac.txt | 37
>>> ++++++++++++++++++++
>>> 1 file changed, 37 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/staging/net/wireless/brcm,bcm43xx-fmac.txt
>>>
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/staging/net/wireless/brcm,bcm43xx-fmac.txt
>>> b/Documentation/devicetree/bindings/staging/net/wireless/brcm,bcm43xx-fmac.txt
>>>
>>> new file mode 100644
>>> index 0000000..535f343
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/staging/net/wireless/brcm,bcm43xx-fmac.txt
>>>
>>> @@ -0,0 +1,37 @@
>>> +Broadcom BCM43xx Fullmac wireless SDIO devices
>>> +
>>> +This node provides properties for controlling the Broadcom wireless
>>> device. The
>>> +node is expected to be specified as a child node to the MMC
>>> controller that
>>> +connects the device to the system.
>>> +
>>> +Required properties:
>>> +
>>> + - compatible : Should be "brcm,bcm43xx-fmac".
>>> + - wlan-supply : phandle for fixed regulator used to control power for
>>> + the device/module.
>>
>> The BCM43xx WLAN chips I used to work always have been controlled by a
>> simple power enable GPIO of the chip itself. Has this changed in newer
>> chips?
>>
>> If you need to simply toggle a GPIO to control the power, you don't need
>> to use the regulator API at all, controlling the GPIO directly.
>
> Not sure I understand. Do you really mean 'chip' or 'wifi module' here.
> The chip needs to be powered and for that it is hooked up to a
> host/module provided GPIO (at least that is my understanding).
Your binding asks for a regulator, not a simple GPIO, which is all I
believe you need for BCM43xx power handling.
Mark (added to Cc), could we get your opinion on this?
>
>>> +
>>> +Optional properties:
>>> + - drive-strength : drive strength used for SDIO pins on device
>>> (default = 6mA).
>>
>> This should be a part of the MMC binding, I think. Probably also moved
>> under MMC controller's node, since it's a board-specific property
>> altering the parameters of the MMC controller, not the WLAN chip.
>
> It is an electrical interfacing parameter between MMC controller and the
> device. The specified drive-strength here is used to configure the PMU
> on the chip so it is really related to the the chip.
>
Aha, so I misunderstood the description. Anyway, if it's a
device-specific property, it should have vendor prefix ("brcm,").
>>> + - interrupt-parent : the phandle for the interrupt controller to
>>> which the
>>> + device interrupt (HOST_WAKE) is connected.
>>> + - interrupts : interrupt specifier encoded according the interrupt
>>> controller
>>> + specified by interrupt-parent property.
>>
>> I would also add a clock here, since the BCM43xx chips usually need a
>> 32k clock to operate (or at least the ones I used to work with did). It
>> can be optional, as not all systems can control this clock.
>>
>>> +
>>> +Example:
>>> +
>>> +mmc3: mmc@01c20000 {
>>> + pinctrl-0 = <&mmc3_pins>;
>>> + pinctrl-1 = <&wifi_host_wake>;
>>
>> WLAN_HOST_WAKE pin (aka the OOB interrupt) is specific to the WLAN chip,
>> so this should be rather configured in a pinctrl state of the WLAN chip
>> itself.
>
> You mean that pinctrl-1 should move inside the "brcm,bcm43xx-fmac" node,
> right?
Yes.
By the way, if not moved to device node, shouldn't it rather be just
another entry of pinctrl-0? Also isn't pinctrl-names property missing here?
>
>>> + vmmc-supply = <&mmc3_supply>;
>>> + bus-width = <4>;
>>> +
>>> + bcm4335: bcm4335@0 {
>>
>> nit: Why @0, if there is no reg property under this node?
>
> I am not fluent with devicetree specifications (yet) nor know all the
> conventions.
The "@" suffix is reserved for bus constructs, where the unit-address
value after "@" corresponds to first address in reg property of the
node. Here you could just simply use "bcm4335" or if you somehow manage
to have two such chips (which I don't think is likely to happen) then
you could use "bcm4335-1".
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH RFC v3 3/3] Documentation: arm: define DT idle states bindings
From: Lorenzo Pieralisi @ 2014-02-13 12:47 UTC (permalink / raw)
To: Sebastian Capella
Cc: Mark Rutland, Mike Turquette, Tomasz Figa, Mark Hambleton,
Russell King, Nicolas Pitre, Daniel Lezcano,
linux-arm-kernel@lists.infradead.org, grant.likely@linaro.org,
Dave P Martin, Charles Garcia-Tobin, devicetree@vger.kernel.org,
Kevin Hilman, linux-pm@vger.kernel.org, Kumar Gala, Rob Herring,
Vincent Guittot, Antti Miettinen, pveerapa@broadcom.com,
Peter De Schrijver
In-Reply-To: <20140213013153.18853.21632@capellas-linux>
Hi Sebastian,
thanks for having a look.
On Thu, Feb 13, 2014 at 01:31:53AM +0000, Sebastian Capella wrote:
> Quoting Lorenzo Pieralisi (2014-02-11 06:17:53)
> > + - cpu-idle-states
> > + Usage: Optional
> > + Value type: <prop-encoded-array>
> > + Definition:
> > + # List of phandles to cpu idle state nodes supported
> > + by this cpu [1].
> > +
>
> Should cpu idle be hyphenated in the definition like:
> "List of phandles to cpu-idle state nodes supported"
No, because it is not meant to be tied to the kernel CPU idle framework.
It is meant to be "List of phandles to idle state nodes supported by this cpu"
and that's what I will do.
On a side note, that's why I was reluctant to call them idle states, for
the records.
> Is anything implied in the ordering of this list?
> Or is this a non-ordered array of phandles?
Non-ordered.
> Would it be a good idea to select a different name for this property vs.
> the node? It seems to get confusing sometimes.
Such as ? "idle-states" ?
> > +According to the Server Base System Architecture document (SBSA, [3]), the
> > +power states an ARM CPU can be put into are identified by the following list:
> > +
> > +1 - Running
> > +2 - Idle_standby
> > +3 - Idle_retention
> > +4 - Sleep
> > +5 - Off
>
> Are these states used in the state->index value?
> Might it be helpful to number these starting with 0?
No, I will remove the numbers.
> > +ARM platforms implement the power states specified in the SBSA through power
> > +management schemes that allow an OS PM implementation to put the processor in
> > +different idle states (which include states 1 to 4 above; "off" state is not
> > +an idle state since it does not have wake-up capabilities, hence it is not
> > +considered in this document).
>
> Might an implementation have both sleep and off states where they have
> different latencies in the case a cpu can wake itself vs. a coprocessor
> waking the cpu?
Yes, but not in SBSA nomenclature. off as in SBSA is not an idle state,
since it does not require IRQ wake up capabilities.
An idle state requires IRQ wake-up capabilities (either through return
from wfi or reset from coprocessor), how it is implemented it does not
matter.
> > +
> > +Idle state parameters (eg entry latency) are platform specific and need to be
> > +characterized with bindings that provide the required information to OSPM
> > +code so that it can build the required tables and use them at runtime.
> > +
> > +The device tree binding definition for ARM idle states is the subject of this
> > +document.
>
> During last connect, we'd discussed that the small set of
> states here could apply to a single node, which can represent a cpu, a
> cluster with cache etc. Then the complexities of the system power state
> would be represented using a heirarchy, with each node in the
> tree having its own state from the list above. This would allow
> a fairly rich system state while having just a few power states defined
> at each level. Is this how you're intending these bindings to go?
Yes, CPUs point at states that can be reached by that CPU (eg a CPU core
gating state is represented by a single node pointed at by all CPUs in the
system - it the same state data, different power domains though).
States are hierarchical, which means that a parent state implies entry on all
substates that's how cluster states are defined.
> > +===========================================
> > +2 - state node
> > +===========================================
>
> should the section numbering be incremented here? Or is this a
> subsection? 2.1?
Yes.
> Also, would it be nice to have a name field for each state?
There is:
"The state node name shall be "stateN", where N = {0, 1, ...} is
the node number; state nodes which are siblings within a single
common parent node must be given a unique and sequential N value,
starting from 0."
I can remove the rule and allow people to call states as they wish
since they already have a compatible property to match them.
Actually, states can be called with any name, provided it is unique.
> > + A state node can contain state child nodes. A state node with
> > + children represents a hierarchical state, which is a superset of
> > + the child states. Hierarchical states require all CPUs on which
> > + they are valid to request the state in order for it to be entered.
>
> Is it possible for a cpu to request a deeper state and unblock other cpus
> from entering this state?
That's not DT bindings business, hierarchical states define states that
require all CPUs on which they are valid to enter that state for it to
be considered "enabled".
It is a hard nut to crack. In x86 this stuff does not exist and it is
managed in HW, basically an idle state is always per-cpu (but it might
end up becoming a package state when all CPUs in a package enter that
state). On ARM, we want to define hierarchical states explicitly to
link resources (ie caches) to them.
CPUs are not prevented from requesting a hierarchical state, but the
state only becomes "enabled" when all CPUs on which it is valid request
it.
I cannot think of any other way of to express this properly but still in
a compact way.
> "all CPUs on which they are valid" is this determined by seeing which
> state's phandle is in each cpu->cpu-idle-states?
Yes, does it make sense ?
> > +
> > + A state node defines the following properties:
> ...
> > + - index
> > + Usage: Required
> > + Value type: <u32>
> > + Definition: It represents an idle state index, starting from 2.
> > + Index 0 represents the processor state "running"
> > + and index 1 represents processor mode
> > + "idle_standby", entered by executing a wfi
> > + instruction (SBSA,[3]); indexes 0 and 1 are
> > + standard ARM states that need not be described.
>
> Do you think maybe something like this might be clearer?
Yes it is.
> Definition: It represents an idle state index.
>
> Index 0 and 1 shall not be specified and are reserved for ARM
> states where index 0 is running, and index 1 is idle_standby
> entered by executing a wfi instruction (SBSA,[3])
>
> What mechanism is used to order the power states WRT power consumption?
I think we should use index for that. The higher the index the lower the
power consumption.
> > + - entry-method
> > + Usage: Required
> > + Value type: <stringlist>
> > + Definition: Describes the method by which a CPU enters the
> > + idle state. This property is required and must be
> > + one of:
> > +
> > + - "arm,psci-cpu-suspend"
> > + ARM PSCI firmware interface, CPU suspend
> > + method[2].
>
> Can psci-cpu-suspend be assumed if entry-method is omitted?
No.
> Can this field be used to combine both psci and non-psci states in any order?
No. I will enforce a unique entry method.
> > + - power-state
> > + Usage: See definition.
> > + Value type: <u32>
> > + Definition: Depends on the entry-method property value.
> > + If entry-method is "arm,psci-cpu-suspend":
> > + # Property is required and represents
> > + psci-power-state parameter. Please refer to
> > + [2] for PSCI bindings definition.
>
> Examples use psci-power-state..
Typo, sorry, it is not C unfortunately...
> If we call this something like entry-method-param rather than power-state,
> would this allow the field to be more flexible? Is flexibility here a goal?
Yes, I can call it like that.
> - power-state
> Usage: See definition.
> Value type: <u32>
> Definition: Parameter to pass to the entry method when
> this state is being entered.
> If entry-method is "arm,psci-cpu-suspend",
> this parameter represents the psci-power-state
> parameter. Please refer to [2] for PSCI bindings
> definition.
>
> > + - power-domains
> > + Usage: Optional
> > + Value type: <prop-encoded-array>
> > + Definition: List of power domain specifiers ([1]) describing
> > + the power domains that are affected by the idle
> > + state entry.
>
> How do you expect this information should be used?
This defines all power domains that are affected by the state entry.
It allows us to understand what caches, devices, whatnots have to be
acted upon state entry.
> I assume psci will be turning off the powerdomains not Linux right?
This is not a PSCI only document, and even if it was, we still need to deal
with devices. Which means we need to know what we have to save/restore (PMU,
arch timer, GIC), and power domains help us detect that.
> If so, is the structure above helpful for psci to associate the cpu
> requesting a state to the specific power domain in the power-domains list?
> Or is this all encoded in the parameter to PSCI suspend? In that case,
> what is the utility?
See above.
> > + - cache-state-retained
> > + Usage: See definition
> > + Value type: <none>
> > + Definition: if present cache memory is retained on power down,
> > + otherwise it is lost.
> > +
> > + - processor-state-retained
> > + Usage: See definition
> > + Value type: <none>
> > + Definition: if present CPU processor logic is retained on
> > + power down, otherwise it is lost.
>
> I don't see a good example of these two retained state properties.
> Isn't this the purpose of idle_retained state? In the explanations, is
> the term 'power down' the same as sleep or off?
Ok, I will remove "power down" and replace it with "state entry".
> > +
> > +cpus {
> > + #size-cells = <0>;
> > + #address-cells = <2>;
> > +
> > + cpu-idle-states {
> > +
> > + STATE0: state0 {
> > + compatible = "arm,cpu-idle-state";
> > + index = <3>;
>
> Are the index fields of nested states independent of each other or
> sequential?
>
> ie:
> - does index=3 here mean pd_cluster is sleep state, and index=2
> below mean the cpu cluster is idle_retention? (both SBSA states)
> - Or does index=3 here mean this state is the next cpu-idle state after
> STATE0_1 below, which has index=2? In this case, are the indexes
> implied to be increasing in order of most power savings?
Forget index as a link to SBSA states indexes above I should have never listed
them as numbers. I understand index is misleading and either I remove it, or I
leave it there to define power savings scale as you mentioned.
> > + entry-method = "arm,psci-cpu-suspend";
> > + psci-power-state = <0x1010000>;
> > + entry-latency = <500>;
> > + exit-latency = <1000>;
> > + min-residency = <2500>;
> > + power-domains = <&pd_clusters 0>;
> > + STATE0_1: state0 {
>
> Should this be STATE0_0?
Well, yes, it is a tag though so it can be whatever we want as long as
it is unique.
> > + compatible = "arm,cpu-idle-state";
> > + index = <2>;
> > + entry-method = "arm,psci-cpu-suspend";
> > + psci-power-state = <0x0010000>;
> > + entry-latency = <200>;
> > + exit-latency = <400>;
> > + min-residency = <300>;
> > + power-domains = <&pd_cores 0>,
> > + <&pd_cores 1>,
> ...
> > + <&pd_cores 7>;
> > + };
> > + };
>
> Would it be possible to add an example illustrating more
> complex cluster/cpu power states? Maybe where both the cpus and
> cluster have multiple states (sleep/retention)?
>
> The current example seems to show just the cpu idle_retention state,
> and the cluster off state.
>
> Maybe an example of how you'd represent something like this with the new
> bindings:
>
> (in increasing order of power saving)
> +-----------------+--------------------+-----------------------------------+
> | cpu | cluster | Notes
> +-----------------+--------------------+-----------------------------------+
> | running | running | not specified running
> | idle_standby | running | not specified WFI
> | idle_retention | running |
> | idle_retention | idle_retention |
> | sleep | idle_retention |
> | sleep | sleep |
> +-----------------|--------------------+-----------------------------------+
>
> The CPU has 4 states: running, idle standby, idle_retention and sleep.
> the first two are not specified per the instructions.
>
> Then the cluster has 3 states: running, retention and sleep.
>
> Maybe a complex case like this would be helpful to understand how the
> bindings should be used.
Ok, I will do that and rework the bindings accordingly.
Thanks,
Lorenzo
^ permalink raw reply
* Re: [PATCH] bus: imx-weim: support weim-cs-gpr for imx6q-weim
From: Shawn Guo @ 2014-02-13 12:47 UTC (permalink / raw)
To: Philippe De Muyter
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Huang Shijie,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140212164304.GA20251-NqYOdiUDesgPnqCj3zZnUQ@public.gmane.org>
On Wed, Feb 12, 2014 at 05:43:04PM +0100, Philippe De Muyter wrote:
> Thanks Shawn.
>
> On Tue, Feb 11, 2014 at 10:50:11AM +0800, Shawn Guo wrote:
> > For imx6q-weim type of device, there might a WEIM CS space configuration
> > register in General Purpose Register controller, e.g. IOMUXC_GPR1 on
> > i.MX6Q.
> >
> > Depending on which configuration of the following 4 is chosen for given
> > system, IOMUXC_GPR1[11:0] should be set up as 0x5, 0x1b, 0x4b or 0x249
>
> As the bits are actually grouped by 3, one could write:
> ... as 05, 033, 0113, or 01111
Indeed, it's easier to read. Will change.
> > correspondingly.
> >
> > CS0(128M) CS1(0M) CS2(0M) CS3(0M)
> > CS0(64M) CS1(64M) CS2(0M) CS3(0M)
> > CS0(64M) CS1(32M) CS2(32M) CS3(0M)
> > CS0(32M) CS1(32M) CS2(32M) CS3(32M)
> >
> > The patch creates a table in the driver for above configurations, and
> > detects which one is being used for the booting system by looking at
> > 'ranges' property of WEIM node. Thus the WEIM CS GPR can be set up
> > automatically at boot time.
> >
> > Signed-off-by: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/bus/imx-weim.txt | 6 ++
> > drivers/bus/imx-weim.c | 83 ++++++++++++++++++++
> > 2 files changed, 89 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt
> > index 0fd76c4..d114460f 100644
> > --- a/Documentation/devicetree/bindings/bus/imx-weim.txt
> > +++ b/Documentation/devicetree/bindings/bus/imx-weim.txt
> > @@ -19,6 +19,12 @@ Required properties:
> >
> > <cs-number> 0 <physical address of mapping> <size>
> >
> > +Optional properties:
> > +
> > + - fsl,weim-cs-gpr: Should be the phandle to the General Purpose Register
> > + controller that contains WEIM CS GPR register, e.g.
> > + IOMUXC_GPR1 on i.MX6Q.
> > +
>
> Why require that new property ? It makes things harder to use.
I was originally thinking that it may help if some day we get an
imx6q-weim type of device integrated on an new IMX SoC where the WEIM
CS GPR is defined in other block other than IOMUXC. But, yes, it's
unnecessary today, and we can add it when necessary. I will drop it
in v2.
>
> And you could add the body of your commit log here.
>
> > Timing property for child nodes. It is mandatory, not optional.
> >
> > - fsl,weim-cs-timing: The timing array, contains timing values for the
> > diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
> > index 3ef58c8..9c8a522 100644
> > --- a/drivers/bus/imx-weim.c
> > +++ b/drivers/bus/imx-weim.c
> > @@ -11,6 +11,9 @@
> > #include <linux/clk.h>
> > #include <linux/io.h>
> > #include <linux/of_device.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
> > +#include <linux/regmap.h>
> >
> > struct imx_weim_devtype {
> > unsigned int cs_count;
> > @@ -56,6 +59,83 @@ static const struct of_device_id weim_id_table[] = {
> > };
> > MODULE_DEVICE_TABLE(of, weim_id_table);
> >
> > +struct imx6q_weim_gpr {
> > + u32 cssize[4];
> > + u32 gprval;
> > +};
> > +
> > +static const struct imx6q_weim_gpr imx6q_weim_gpr_data[] __initconst = {
> > + {
> > + /* CS0(128M) CS1(0M) CS2(0M) CS3(0M) */
> > + .cssize = { 128, 0, 0, 0 },
> > + .gprval = 0x5,
> 05
> > + }, {
> > + /* CS0(64M) CS1(64M) CS2(0M) CS3(0M) */
> > + .cssize = { 64, 64, 0, 0 },
> > + .gprval = 0x1b,
> 033
> > + }, {
> > + /* CS0(64M) CS1(32M) CS2(32M) CS3(0M) */
> > + .cssize = { 64, 32, 32, 0 },
> > + .gprval = 0x4b,
> 0113
> > + }, {
> > + /* CS0(64M) CS1(32M) CS2(32M) CS3(0M) */
> /* CS0(32M) CS1(32M) CS2(32M) CS3(32M) */
> > + .cssize = { 32, 32, 32, 32 },
> > + .gprval = 0x249,
> 01111
> > + },
> > +};
> > +
> > +static int __init imx6q_weim_gpr_setup(struct platform_device *pdev)
> > +{
> > + struct device_node *np = pdev->dev.of_node;
> > + const struct property *prop;
> > + struct regmap *gpr;
> > + u32 cssize[4] = { 0, 0, 0, 0 };
> > + int len;
> > + int ret;
> > + int i;
> > +
> > + gpr = syscon_regmap_lookup_by_phandle(np, "fsl,weim-cs-gpr");
>
> gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
>
> > + if (IS_ERR(gpr)) {
> > + dev_dbg(&pdev->dev, "No weim-cs-gpr to set up\n");
> > + return 0;
> > + }
> > +
> > + prop = of_find_property(np, "ranges", &len);
> > + if (prop == NULL)
> > + return -ENOENT;
> > + if (len % (sizeof(u32) * 4))
> > + return -EINVAL;
> > +
> > + for (i = 0; i < len / (sizeof(u32) * 4); i++) {
> > + int cs;
> > + /* read cs index */
> > + ret = of_property_read_u32_index(np, "ranges", i * 4, &cs);
> > + if (ret)
> > + return ret;
> > + /* read cs size */
> > + ret = of_property_read_u32_index(np, "ranges", i * 4 + 3,
> > + &cssize[cs]);
> > + if (ret)
> > + return ret;
> > + /* turn to MB */
> > + cssize[cs] >>= 20;
> > + }
> > +
> > + for (i = 0; i < ARRAY_SIZE(imx6q_weim_gpr_data); i++) {
> > + ret = memcmp(cssize, imx6q_weim_gpr_data[i].cssize,
> > + sizeof(cssize));
> > + if (ret == 0) {
> > + /* Find it. Set up IOMUXC_GPR1[11:0] with the gprval. */
>
> Found it
Right.
>
> > + regmap_update_bits(gpr, IOMUXC_GPR1, 0xfff,
> > + imx6q_weim_gpr_data[i].gprval);
> > + return 0;
> > + }
> > + }
> > +
> > + dev_err(&pdev->dev, "Invalid 'ranges' configuration\n");
> > + return -EINVAL;
> > +}
> > +
> > /* Parse and set the timing for this device. */
> > static int __init weim_timing_setup(struct device_node *np, void __iomem *base,
> > const struct imx_weim_devtype *devtype)
> > @@ -92,6 +172,9 @@ static int __init weim_parse_dt(struct platform_device *pdev,
> > struct device_node *child;
> > int ret;
> >
> > + if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx6q-weim"))
> > + imx6q_weim_gpr_setup(pdev);
> > +
> > for_each_child_of_node(pdev->dev.of_node, child) {
> > if (!child->name)
> > continue;
> > --
> > 1.7.9.5
> >
>
> Now the most important : it works. I have tested it successfully for the
> 4 combinations.
>
> Code could probably be made shorter by using 'of_prop_next_u32' and building
> the gprval incrementally, then checking it against the four possible values,
> though.
Point taken. See it in v2.
Thanks for the review comments.
Shawn
--
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/3] mmc: add support for power-on sequencing through DT
From: Arnd Bergmann @ 2014-02-13 12:48 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Russell King - ARM Linux, mark.rutland, devicetree, Ulf Hansson,
Pawel Moll, Ian Campbell, Tomasz Figa, linux-mmc, Tomasz Figa,
Chris Ball, robh+dt, Kumar Gala, Olof Johansson, Fabio Estevam,
Sascha Hauer
In-Reply-To: <20140213104248.GU26684@n2100.arm.linux.org.uk>
On Thursday 13 February 2014 10:42:48 Russell King - ARM Linux wrote:
>
> What if we have a platform where things subtly change, like for instance,
> the wiring on the SD slot to fix a problem with UHS-1 cards, which means
> you don't have UHS-1 support for some platforms but do for others.
>
> What if you have a platform which uses a brcm4329 chip for Wifi, but then
> later in the production run switch to using a different Wifi chipset?
As far as I can tell, the power sequencing is normally really
dependent on the device. If someone has an on-board brcm4329
that requires a specific set of clocks, resets, voltages etc
to be routed to the chip and enabled in the correct order to
allow probing, it seems unlikely that changing the wifi chipset
to something else would keep the exact same requirements.
> With this information encoded into DT, the number of DT files quickly
> increases, and then this presents its own problem - how do users get to
> know which DT file should be used for their platform when all they see
> externally is "a product of type A"?
I haven't seen a suggestion that would not encode this in DT. The
difference between Olof's original suggestion and mine is that he
proposed to put the data into the existing node of the host controller,
while my approach would be to add a node for each function with
these requirements and modify the sdio code so that we can deal
with it in the function driver. The data that would get passed
however is almost the same.
Arnd
^ permalink raw reply
* Re: [PATCH 3/7] Documentation: devicetree: fix up pl022 clocks
From: Linus Walleij @ 2014-02-13 12:55 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, Pawel Moll, Mark Brown, Arnd Bergmann
In-Reply-To: <1392118632-11312-4-git-send-email-mark.rutland-5wv7dgnIgG8@public.gmane.org>
On Tue, Feb 11, 2014 at 12:37 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> Currently the pl022 driver expects clocks, and dts provide them, yet the
> binding does not mention clocks at all.
>
> This patch adds a description of the clocks, "apb_pclk" (as required by
> the primecell binding) and "sspclk" for the pl022 itself. The "sspclk"
> name was chosen to match the official documentation, as currently a
> variety of names are used in its place; it is expected that any
> operating system supporting these can continue to do so in the absence
> of an "sspclk" entry.
>
> Signed-off-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Reviewed-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] bus: imx-weim: support CS GPR config for imx6q-weim
From: Shawn Guo @ 2014-02-13 12:59 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Philippe De Muyter, Huang Shijie, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
devicetree-u79uwXL29TY76Z2rM5mHXA, Shawn Guo
For imx6q-weim type of device, there might a WEIM CS space configuration
register in General Purpose Register controller, e.g. IOMUXC_GPR1 on
i.MX6Q.
Depending on which configuration of the following 4 is chosen for given
system, IOMUXC_GPR1[11:0] should be set up as 05, 033, 0113 or 01111
correspondingly.
CS0(128M) CS1(0M) CS2(0M) CS3(0M)
CS0(64M) CS1(64M) CS2(0M) CS3(0M)
CS0(64M) CS1(32M) CS2(32M) CS3(0M)
CS0(32M) CS1(32M) CS2(32M) CS3(32M)
The patch creates a function for imx6q-weim type of device, which scans
'ranges' property of WEIM node and build the GPR value incrementally.
Thus the WEIM CS GPR can be set up automatically at boot time.
Signed-off-by: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Changes since v1:
- Drop device tree property fsl,weim-cs-gpr
- Use octal value for IOMUXC_GPR1[11:0] bit field
- Use of_property_for_each_u32() to build gprval incrementally
drivers/bus/imx-weim.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index 3ef58c8..a120c93 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -11,6 +11,9 @@
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/of_device.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
+#include <linux/regmap.h>
struct imx_weim_devtype {
unsigned int cs_count;
@@ -56,6 +59,59 @@ static const struct of_device_id weim_id_table[] = {
};
MODULE_DEVICE_TABLE(of, weim_id_table);
+static int __init imx6q_weim_gpr_setup(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct property *prop;
+ const __be32 *p;
+ struct regmap *gpr;
+ u32 gprvals[4] = {
+ 05, /* CS0(128M) CS1(0M) CS2(0M) CS3(0M) */
+ 033, /* CS0(64M) CS1(64M) CS2(0M) CS3(0M) */
+ 0113, /* CS0(64M) CS1(32M) CS2(32M) CS3(0M) */
+ 0111, /* CS0(64M) CS1(32M) CS2(32M) CS3(0M) */
+ };
+ u32 gprval = 0;
+ u32 val;
+ int len;
+ int cs = 0;
+ int i = 0;
+
+ gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
+ if (IS_ERR(gpr)) {
+ dev_err(&pdev->dev, "failed to find fsl,imx6q-iomuxc-gpr\n");
+ return -ENOENT;
+ }
+
+ prop = of_find_property(np, "ranges", &len);
+ if (prop == NULL)
+ return -ENOENT;
+ if (len % (sizeof(u32) * 4))
+ return -EINVAL;
+
+ of_property_for_each_u32(np, "ranges", prop, p, val) {
+ if (i % 4 == 0) {
+ cs = val;
+ } else if (i % 4 == 3 && val) {
+ val /= SZ_64M;
+ val = (val << 1) | 1;
+ gprval |= val << cs * 3;
+ }
+ i++;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(gprvals); i++) {
+ if (gprval == gprvals[i]) {
+ /* Found it. Set up IOMUXC_GPR1[11:0] with it. */
+ regmap_update_bits(gpr, IOMUXC_GPR1, 0xfff, gprval);
+ return 0;
+ }
+ }
+
+ dev_err(&pdev->dev, "Invalid 'ranges' configuration\n");
+ return -EINVAL;
+}
+
/* Parse and set the timing for this device. */
static int __init weim_timing_setup(struct device_node *np, void __iomem *base,
const struct imx_weim_devtype *devtype)
@@ -92,6 +148,9 @@ static int __init weim_parse_dt(struct platform_device *pdev,
struct device_node *child;
int ret;
+ if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx6q-weim"))
+ imx6q_weim_gpr_setup(pdev);
+
for_each_child_of_node(pdev->dev.of_node, child) {
if (!child->name)
continue;
--
1.7.9.5
--
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
* [PATCH] gpu:drm:tilcdc: backlight node never found
From: Heiko Schocher @ 2014-02-13 13:47 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Heiko Schocher, Anatolij Gustschin, Benoit Parrot, Rob Clark,
David Airlie, Grant Likely, Rob Herring, Tomi Valkeinen,
Sachin Kamat, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In panel_probe() the backlight node is never found, correct this.
Signed-off-by: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
Cc: Anatolij Gustschin <agust-ynQEQJNshbs@public.gmane.org>
Cc: Benoit Parrot <bparrot-l0cyMroinI0@public.gmane.org>
Cc: Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: David Airlie <airlied-cv59FeDIM0c@public.gmane.org>
Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Cc: Sachin Kamat <sachin.kamat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 86c6732..0b97cf4 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -356,6 +356,7 @@ static struct of_device_id panel_of_match[];
static int panel_probe(struct platform_device *pdev)
{
struct device_node *node = pdev->dev.of_node;
+ struct device_node *backlight_node;
struct panel_module *panel_mod;
struct tilcdc_module *mod;
struct pinctrl *pinctrl;
@@ -395,9 +396,15 @@ static int panel_probe(struct platform_device *pdev)
mod->preferred_bpp = panel_mod->info->bpp;
- panel_mod->backlight = of_find_backlight_by_node(node);
- if (panel_mod->backlight)
- dev_info(&pdev->dev, "found backlight\n");
+ backlight_node = of_parse_phandle(pdev->dev.of_node, "backlight", 0);
+ if (backlight_node) {
+ panel_mod->backlight =
+ of_find_backlight_by_node(backlight_node);
+ if (panel_mod->backlight)
+ dev_info(&pdev->dev, "found backlight\n");
+ } else {
+ dev_warn(&pdev->dev, "backlight node missing...\n");
+ }
return 0;
--
1.8.3.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 1/2] dp83640: Support a configurable number of periodic outputs
From: Stefan Sørensen @ 2014-02-13 14:21 UTC (permalink / raw)
To: Richard Cochran
Cc: grant.likely, robh+dt, mark.rutland, netdev, linux-kernel,
devicetree
In-Reply-To: <20140211200922.GA4254@netboy>
On Tue, 2014-02-11 at 21:09 +0100, Richard Cochran wrote:
> > -#define EXT_EVENT 1
>
> Regarding this EXT_EVENT thing ...
>
> > @@ -430,12 +419,12 @@ static int ptp_dp83640_enable(struct ptp_clock_info *ptp,
> > switch (rq->type) {
> > case PTP_CLK_REQ_EXTTS:
> > index = rq->extts.index;
> > - if (index < 0 || index >= N_EXT_TS)
> > + if (index < 0 || index >= n_ext_ts)
> > return -EINVAL;
> > - event_num = EXT_EVENT + index;
> > + event_num = index;
>
> there was a mapping between the "event numbers" and the external time
> stamp channels. I don't remember off the top of my head why this these
> two differ by one, but there was a good reason.
I haven't seen anything in the documentation regarding this, output
triggers 0 and 1 are special, but the events should all behave the same.
Could be be a mixup between events and pins? Pin0 means disable the
event.
> Are you sure this is still working with this change?
It has been running with event 0 in one of our products for at least the
last 3 months....
> I am especially wondering about the event decoding here:
>
> > @@ -642,7 +631,7 @@ static void recalibrate(struct dp83640_clock *clock)
> >
> > static inline u16 exts_chan_to_edata(int ch)
> > {
> > - return 1 << ((ch + EXT_EVENT) * 2);
> > + return 1 << ((ch) * 2);
> > }
>
> Maybe I am just paranoid, but can you remind me how these event
> numbers are supposed to work, before and after the change?
The mapping was hardcoded to map events 0-5 to event channels 1-6, the
periodic output trigger at channel 6 and the calibration event+trigger
both at channel 7.
The patch will (at least in v3 that I will post shortly) change both the
event and trigger mapping to a direct mapping and keep the calibration
at channel 7.
Stefan
^ permalink raw reply
* Re: [PATCH v2 2/2] dp83640: Get pin and master/slave configuration from DT
From: Stefan Sørensen @ 2014-02-13 14:23 UTC (permalink / raw)
To: Richard Cochran
Cc: grant.likely, robh+dt, mark.rutland, netdev, linux-kernel,
devicetree
In-Reply-To: <20140211201917.GB4254@netboy>
On Tue, 2014-02-11 at 21:19 +0100, Richard Cochran wrote:
> > +- dp83640,slave: If present, this phy will be slave to another dp83640
> > + on the same mdio bus.
>
> Wouldn't it be more natural to have one "dp83640,master" property
> rather than multiple slave properties?
I wanted to keep the common case of a single phy simple, i.e. no need to
specify any master/slave properties.
> Most of these pr_err lines are a bit _way_ too long for coding style.
I will fix that in the next version.
Stefan
^ 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