* Re: [PATCH v5 01/10] arm64: allwinner: a64: enable RSB on A64
From: icenowy-h8G6r0blFSE @ 2017-04-27 18:14 UTC (permalink / raw)
To: Maxime Ripard
Cc: Thomas Gleixner, Rob Herring, Chen-Yu Tsai, Lee Jones,
Liam Girdwood, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-owner-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170427132805.izv6xfktlhfc4yty@lukather>
在 2017-04-27 21:28，Maxime Ripard 写道：
> On Wed, Apr 26, 2017 at 11:20:14PM +0800, Icenowy Zheng wrote:
>> Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
>>
>> Add it and its pinmux.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> ---
>> Changes in v2:
>> - Removed bonus properties in pio node.
>> - Added Chen-Yu's ACK.
>>
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 19
>> +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index c7f669f5884f..05ec9fc5e81f 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -422,6 +422,25 @@
>> #gpio-cells = <3>;
>> interrupt-controller;
>> #interrupt-cells = <3>;
>> +
>> + r_rsb_pins: rsb@0 {
>> + pins = "PL0", "PL1";
>> + function = "s_rsb";
>> + };
>> + };
>> +
>> + r_rsb: rsb@1f03400 {
>> + compatible = "allwinner,sun8i-a23-rsb";
>> + reg = <0x01f03400 0x400>;
>> + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&r_ccu 6>;
>
> Please use the defines here..
Linux-4.12 doesn't yet enter rc1, and the defines are still not in
Linus's tree.
Please note that I have already mentioned that this patch is necessary
to be merged into 4.12, otherwise poweroff won't work properly at 4.12 .
So I think it shouldn't still use defines.
I will fix here after 4.12-rc1 is out, along with other r_ccu
usages.
>
>> + clock-frequency = <3000000>;
>> + resets = <&r_ccu 2>;
>
> And here.
>
> Thanks!
> Maxime
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors
From: Markus Mayer @ 2017-04-27 18:28 UTC (permalink / raw)
To: Rob Herring
Cc: Jean Delvare, Guenter Roeck, Mark Rutland, Florian Fainelli,
Broadcom Kernel List, Linux HWMON List, Device Tree List,
ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <CAGt4E5susQWWNZPbNh8AoWtK-4yu50VL=GqOw+_2w_FA+2V68Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 25 April 2017 at 12:29, Markus Mayer <markus.mayer-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> Hi Rob,
>
> On 18 April 2017 at 13:17, Markus Mayer <code-7CzEARzsJhSsTnJN9+BGXg@public.gmane.org> wrote:
>> From: Markus Mayer <mmayer-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>
>> Provide bindings for the Broadcom STB DDR PHY Front End (DPFE).
>
> Would you be able to have a look at this binding? The driver won't be
> upstreamed as hwmon driver (as per Guenter's comments). I am currently
> converting the driver to a "soc" driver instead, but the proposed
> binding remains unchanged.
>
> If you have comments or suggestions, I would like to incorporate them
> with the new series I will be sending out.
To explain a bit more what we are looking for: we had a internal
discussions how to structure this binding and are looking for some
guidance.
Should we create three different nodes for the three different memory
areas (dpfe-cpu@..., dpfe-dmem@..., dpfe-imem@...), each with a single
"reg" property (which is the proposal below) or should this be one
single property with 3 "reg" cells, i.e. something like this:
dpfe-cpu@f1132000 {
...
reg = <0xf1132000 0x180 /* register space */
0xf1134000 0x1000 /* data memory */
0xf1138000 0x4000>; /* instruction memory */
...
};
Regards,
-Markus
>> Signed-off-by: Markus Mayer <mmayer-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>> ---
>> .../devicetree/bindings/hwmon/brcmstb-dpfe.txt | 68 ++++++++++++++++++++++
>> 1 file changed, 68 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt b/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
>> new file mode 100644
>> index 0000000..3519197
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
>> @@ -0,0 +1,68 @@
>> +DDR PHY Front End (DPFE) for Broadcom STB
>> +=========================================
>> +
>> +DPFE and the DPFE firmware provide an interface for the host CPU to
>> +communicate with the DCPU, which resides inside the DDR PHY.
>> +
>> +There are three memory regions for interacting with the DCPU.
>> +
>> +The DCPU Register Space
>> +-----------------------
>> +
>> +Required properties:
>> + - compatible: must be one of brcm,bcm7271-dpfe-cpu, brcm,dpfe-cpu-v12.0.0.0
>> + or brcm,dpfe-cpu
>> + - reg: must reference the start address and length of the DCPU register
>> + space
>> +
>> +Optional properties:
>> + - cell-index: the index of the DPFE instance; will default to 0 if not set
>> +
>> +Example:
>> + dpfe_cpu0: dpfe-cpu@f1132000 {
>> + compatible = "brcm,bcm7271-dpfe-cpu",
>> + "brcm,dpfe-cpu-v12.0.0.0",
>> + "brcm,dpfe-cpu";
>> + reg = <0xf1132000 0x180>;
>> + cell-index = <0>;
>> + };
>> +
>> +The DCPU Data Memory Space
>> +--------------------------
>> +
>> +Required properties:
>> + - compatible: must be one of brcm,bcm7271-dpfe-dmem, brcm,dpfe-dmem-v12.0.0.0
>> + or brcm,dpfe-dmem
>> + - reg: must reference the start address and length of the DCPU DMEM space
>> +
>> +Optional properties:
>> + - cell-index: the index of the DPFE instance; will default to 0 if not set
>> +
>> +Example:
>> + dpfe_dmem0: dpfe-dmem@f1134000 {
>> + compatible = "brcm,bcm7271-dpfe-dmem",
>> + "brcm,dpfe-dmem-v12.0.0.0",
>> + "brcm,dpfe-dmem";
>> + reg = <0xf1134000 0x1000>;
>> + cell-index = <0>;
>> + };
>> +
>> +The DCPU Instruction Memory Space
>> +---------------------------------
>> +
>> +Required properties:
>> + - compatible: must be one of brcm,bcm7271-dpfe-imem, brcm,dpfe-imem-v12.0.0.0
>> + or brcm,dpfe-imem
>> + - reg: must reference the start address and length of the DCPU IMEM space
>> +
>> +Optional properties:
>> + - cell-index: the index of the DPFE instance; will default to 0 if not set
>> +
>> +Example:
>> + dpfe_imem0: dpfe-imem@f1138000 {
>> + compatible = "brcm,bcm7271-dpfe-imem",
>> + "brcm,dpfe-imem-v12.0.0.0",
>> + "brcm,dpfe-imem";
>> + reg = <0xf1138000 0x4000>;
>> + cell-index = <0>;
>> + };
>> --
>> 2.7.4
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback
From: Jose Abreu @ 2017-04-27 18:42 UTC (permalink / raw)
To: Vineet Gupta,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: Carlos Palminha, Alexey Brodkin, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <ae3f1150-f8da-9a34-d929-6964f91c06ae-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Hi Vineet,
On 27-04-2017 00:31, Vineet Gupta wrote:
> On 04/26/2017 01:55 AM, Jose Abreu wrote:
>> Hi Vineet,
>>
>>
>> On 24-04-2017 18:36, Vineet Gupta wrote:
>>> On 04/21/2017 03:15 AM, Jose Abreu wrote:
>>>> This patch adds the necessary DT bindings to get HDMI audio
>>>> output in ARC AXS10x SDP. The bindings for I2S controller were
>>>> added as well as the bindings for simple audio card.
>>> Are these waiting on Rob or is it OK for me to pick these up for 4.12 ?
>> Yes, I was waiting for Rob ack but he has been silent. It would
>> be nice if these went for 4.12.
> Ok lets wait another couple of days before I pick those up.
> In the mean time, can you please restest the series against 4.11-rcX and report
> here that patches are still valid and do as intended !
I tested based on drm-next of today (which is based on 4.11-rc7)
and the patches work okay.
Best regards,
Jose Miguel Abreu
>
> Thx,
> -Vineet
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] PCI: mediatek: Add Mediatek PCIe host controller support
From: Arnd Bergmann @ 2017-04-27 18:55 UTC (permalink / raw)
To: Ryder Lee
Cc: devicetree, linux-pci, Linux Kernel Mailing List, Rob Herring,
linux-mediatek, Bjorn Helgaas, Linux ARM
In-Reply-To: <1493194200.27023.79.camel@mtkswgap22>
On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> On Tue, 2017-04-25 at 14:38 +0200, Arnd Bergmann wrote:
>> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
>> > +static int mtk_pcie_enable_ports(struct mtk_pcie *pcie)
>> > +{
>> > + struct device *dev = pcie->dev;
>> > + struct mtk_pcie_port *port, *tmp;
>> > + int err, linkup = 0;
>> > +
>> > + list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
>> > + err = clk_prepare_enable(port->sys_ck);
>> > + if (err) {
>> > + dev_err(dev, "failed to enable port%d clock\n",
>> > + port->index);
>> > + continue;
>> > + }
>> > +
>> > + /* assert RC */
>> > + reset_control_assert(port->reset);
>> > + /* de-assert RC */
>> > + reset_control_deassert(port->reset);
>> > +
>> > + /* power on PHY */
>> > + err = phy_power_on(port->phy);
>> > + if (err) {
>> > + dev_err(dev, "failed to power on port%d phy\n",
>> > + port->index);
>> > + goto err_phy_on;
>> > + }
>> > +
>> > + mtk_pcie_assert_ports(port);
>> > +
>>
>> Similar to the comment I had for the binding, I wonder if it would be
>> better to keep all the information about the ports in one place and
>> then just deal with it at the root level.
>>
>> Alternatively, we could decide to standardize on the properties
>> you have added to the pcie port node, but then I would handle
>> them in the pcieport driver rather than in the host bridge driver.
>
> Sorry, I'm not sure what you want me to do here.
>
> I could move all clock operation in root level. But we need to keep the
> reset and PHY operation sequence in the loop, In addition, we could
> easily free resources if ports link fail.
>
> How about moving this function to mtk_pcie_parse_and_add_res()?
That could work, please try it out and see if the code gets better or
worse. This may depend on what we end up doing with the DT
properties.
>> > +/*
>> > + * This IP lacks interrupt status register to check or map INTx from
>> > + * different devices at the same time.
>> > + */
>> > +static int __init mtk_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
>> > +{
>> > + struct mtk_pcie *pcie = dev->bus->sysdata;
>> > + struct mtk_pcie_port *port;
>> > +
>> > + list_for_each_entry(port, &pcie->ports, list)
>> > + if (port->index == slot)
>> > + return port->irq;
>> > +
>> > + return -1;
>> > +}
>>
>> This looks odd, what is it needed for specifically? It looks like
>> it's broken for devices behind bridges, and the interrupt mapping
>> should normally come from the interrupt-map property, without
>> the need for a driver specific map_irq override.
>
> Our hardware just has a GIC for each port and lacks interrupt status for
> host driver to distinguish INTx. So I return port IRQ here.
You should still be able to express this with standard interrupt-map
DT property, without having to resort to your own map_irq
callback handler.
In the interrupt-map-mask, you can ignore the interrupt line
only list the devfn of the root ports for each entry.
>> > +static int mtk_pcie_register_ports(struct mtk_pcie *pcie)
>> > +{
>> > + struct pci_bus *bus, *child;
>> > +
>> > + bus = pci_scan_root_bus(pcie->dev, 0, &mtk_pcie_ops, pcie,
>> > + &pcie->resources);
>>
>> Can you use the new pci_register_host_bridge() method instead of
>> pci_scan_root_bus() here?
>
> May I know what's difference between pci_scan_root_bus() and using
> pci_register_host_bridge() directly? What situation should we use it?
> It seems that just tegra use this new method currently.
We introduced the new function for tegra for now, in the long run
I would hope we can convert all other drivers to it as well, to make it
easier to add further parameters.
The new function also has a cleaner way of dealing with the memory
allocations, similar to how other subsystems work.
Arnd
^ permalink raw reply
* Re: [PATCH v2] leds-pca963x: add bindings to invert polarity
From: Jacek Anaszewski @ 2017-04-27 19:01 UTC (permalink / raw)
To: Anders Darander, pavel, robh+dt, mark.rutland, linux-leds,
devicetree, linux-kernel
Cc: rpurdie
In-Reply-To: <20170427063733.32323-1-anders@chargestorm.se>
Hi Anders,
On 04/27/2017 08:37 AM, Anders Darander wrote:
> Add a new DT property, nxp,inverted-out, to invert the polarity of the output.
>
> Tested on PCA9634.
>
> Signed-off-by: Anders Darander <anders@chargestorm.se>
> ---
> Documentation/devicetree/bindings/leds/pca963x.txt | 1 +
> drivers/leds/leds-pca963x.c | 17 +++++++++++++++--
> include/linux/platform_data/leds-pca963x.h | 6 ++++++
> 3 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/pca963x.txt b/Documentation/devicetree/bindings/leds/pca963x.txt
> index dfbdb123a9bf..4eee41482041 100644
> --- a/Documentation/devicetree/bindings/leds/pca963x.txt
> +++ b/Documentation/devicetree/bindings/leds/pca963x.txt
> @@ -10,6 +10,7 @@ Optional properties:
> - nxp,period-scale : In some configurations, the chip blinks faster than expected.
> This parameter provides a scaling ratio (fixed point, decimal divided
> by 1000) to compensate, e.g. 1300=1.3x and 750=0.75x.
> +- nxp,inverted-out: invert the polarity of the generated PWM
>
> Each led is represented as a sub-node of the nxp,pca963x device.
>
> diff --git a/drivers/leds/leds-pca963x.c b/drivers/leds/leds-pca963x.c
> index ded1e4dac36a..3bf9a1271819 100644
> --- a/drivers/leds/leds-pca963x.c
> +++ b/drivers/leds/leds-pca963x.c
> @@ -342,6 +342,12 @@ pca963x_dt_init(struct i2c_client *client, struct pca963x_chipdef *chip)
> if (of_property_read_u32(np, "nxp,period-scale", &chip->scaling))
> chip->scaling = 1000;
>
> + /* default to non-inverted output, unless inverted is specified */
> + if (of_property_read_bool(np, "nxp,inverted-out"))
> + pdata->dir = PCA963X_INVERTED;
> + else
> + pdata->dir = PCA963X_NORMAL;
> +
> return pdata;
> }
>
> @@ -452,11 +458,18 @@ static int pca963x_probe(struct i2c_client *client,
> i2c_smbus_write_byte_data(client, PCA963X_MODE1, BIT(4));
>
> if (pdata) {
> + u8 mode2 = i2c_smbus_read_byte_data(pca963x->chip->client,
> + PCA963X_MODE2);
> /* Configure output: open-drain or totem pole (push-pull) */
> if (pdata->outdrv == PCA963X_OPEN_DRAIN)
> - i2c_smbus_write_byte_data(client, PCA963X_MODE2, 0x01);
> + mode2 |= 0x01;
> else
> - i2c_smbus_write_byte_data(client, PCA963X_MODE2, 0x05);
> + mode2 |= 0x05;
> + /* Configure direction: normal or inverted */
> + if (pdata->dir == PCA963X_INVERTED)
> + mode2 |= 0x10;
> + i2c_smbus_write_byte_data(pca963x->chip->client, PCA963X_MODE2,
> + mode2);
> }
>
> return 0;
> diff --git a/include/linux/platform_data/leds-pca963x.h b/include/linux/platform_data/leds-pca963x.h
> index e731f0036329..54e845ffb5ed 100644
> --- a/include/linux/platform_data/leds-pca963x.h
> +++ b/include/linux/platform_data/leds-pca963x.h
> @@ -33,10 +33,16 @@ enum pca963x_blink_type {
> PCA963X_HW_BLINK,
> };
>
> +enum pca963x_direction {
> + PCA963X_NORMAL,
> + PCA963X_INVERTED,
> +};
> +
> struct pca963x_platform_data {
> struct led_platform_data leds;
> enum pca963x_outdrv outdrv;
> enum pca963x_blink_type blink_type;
> + enum pca963x_direction dir;
> };
>
> #endif /* __LINUX_PCA963X_H*/
>
Thanks for the patch.
Applied to the for-4.13 branch of linux-leds.git.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [SPAM]Re: [PATCH 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
From: Arnd Bergmann @ 2017-04-27 19:06 UTC (permalink / raw)
To: Ryder Lee
Cc: devicetree, linux-pci, Linux Kernel Mailing List, Rob Herring,
linux-mediatek, Bjorn Helgaas, Linux ARM
In-Reply-To: <1493194205.27023.80.camel@mtkswgap22>
On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> Hi
>
> On Tue, 2017-04-25 at 14:18 +0200, Arnd Bergmann wrote:
>> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
>> > Add documentation for PCIe host driver available in MT7623
>> > series SoCs.
>> >
>> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
>> > ---
>> > .../bindings/pci/mediatek,mt7623-pcie.txt | 153 +++++++++++++++++++++
>> > 1 file changed, 153 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
>> > new file mode 100644
>> > index 0000000..ee93ba2
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
>> > @@ -0,0 +1,153 @@
>> > +Mediatek MT7623 PCIe controller
>> > +
>> > +Required properties:
>> > +- compatible: Should contain "mediatek,mt7623-pcie".
>>
>> Did mediatek license the IP block from someone else or was it
>> developed in-house? Is there a name and/or version identifier
>> for the block itself other than identifying it as the one in mt7623?
>
> Originally, it license from synopsys. Our designer add a wrapper to hide
> the DBI detail so that we cannot use them directly. Perhaps I can call
> it "mediatek,gen2v1-pcie", because we have a plan to upstream a in-house
> Gen2 IP in the future.
Ok, so this is the same hardware that drivers/pci/dwc/ handles, but
it needs a separate driver because the wrapper that was added uses
a completely different register layout, right?
Are any of the registers the same at all, e.g. for MSI handling?
>> > +Required properties:
>> > +- device_type: Must be "pci"
>> > +- assigned-addresses: Address and size of the port configuration registers
>> > +- reg: Only the first four bytes are used to refer to the correct bus number
>> > + and device number.
>> > +- #address-cells: Must be 3
>> > +- #size-cells: Must be 2
>> > +- ranges: Sub-ranges distributed from the PCIe controller node. An empty
>> > + property is sufficient.
>> > +- clocks: Must contain an entry for each entry in clock-names.
>> > + See ../clocks/clock-bindings.txt for details.
>> > +- clock-names: Must include the following entries:
>> > + - sys_ck
>> > +- resets: Must contain an entry for each entry in reset-names.
>> > + See ../reset/reset.txt for details.
>>
>> This seems odd: you have a device that is simply identified as "pci"
>> without any more specific ID, but you require additional properties
>> (clocks, reset, ...) that are not part of the standard PCI binding.
>>
>> Can you clarify how the port devices related to the root device in
>> this hardware design?
>
> I will write clarify like this:
>
> PCIe subsys includes one Host/PCI bridge and 3 PCIe MAC port. There
> are 3 bus master for data access and 1 slave for configuration and
> status register access. Each port has PIPE interface to PHY and
If I understand this right, then each of the ports in your hardware
is what we normally drive using the drivers/pci/dwc/ driver framework,
but your implementation actually made it more PCI standard compliant
by implementing the normal PCIe host bridge registers for all ports
combined, something that most others don't.
>> Have you considered moving the nonstandard properties into the host
>> bridge node and having that device deal with setting up the links
>> to the other drivers? That way we could use the regular pcie
>> port driver for the children.
>>
>
> OK, but I still want to use port->reset to catch reset properties in
> driver.
Do you mean in drivers/pci/pcie/portdrv_pci.c? I see that it
has a function called pcie_portdrv_slot_reset(), but I don't see
how that relates to your reset line at the moment. Is this
something you have submitted in a different series?
Or do you mean in this host driver? The problem I see with
that approach is that the port device is owned by portdrv_pci,
so the host bridge driver should not look at the properties of
the port.
>> > +- reset-names: Must include the following entries:
>> > + - pcie-reset
>> > +- num-lanes: Number of lanes to use for this port.
>> > +- phys: Must contain an entry for each entry in phy-names.
>> > +- phy-names: Must include an entry for each sub node. Entries are of the form
>> > + "pcie-phyN": where N ranges from 0 to the value specified for port number.
>> > + See ../phy/phy-mt7623-pcie.txt for details.
>>
>> I think the name should not include the number of the port but rather
>> be always the same here.
>>
>
> Hmm, I think it's better to keep the name here. It's more readable for
> user to understand the relationship between port0 and phy0.
No, I would argue that it's confusing for the reader because it
is different from how most other DT bindings work: In each device
node, you tend to have a set of properties with well-known names
that are documented. When your reference is called "pcie-phy1"
in one node and "pcie-phy2", I would interpret that as both ports
having two phys each, but only one of them being used.
Arnd
^ permalink raw reply
* [PATCH] ARM: dts: r7s72100: add usb clocks to device tree
From: Chris Brandt @ 2017-04-27 19:10 UTC (permalink / raw)
To: Simon Horman, Geert Uytterhoeven, Rob Herring, Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Chris Brandt
This adds the USB0 and USB1 clocks to the device tree.
Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/r7s72100.dtsi | 6 +++---
include/dt-bindings/clock/r7s72100-clock.h | 2 ++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index fb54cb5d3fad..4ed12a4d9d51 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -144,9 +144,9 @@
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks";
reg = <0xfcfe0430 4>;
- clocks = <&b_clk>;
- clock-indices = <R7S72100_CLK_ETHER>;
- clock-output-names = "ether";
+ clocks = <&b_clk>, <&p1_clk>, <&p1_clk>;
+ clock-indices = <R7S72100_CLK_ETHER R7S72100_CLK_USB0 R7S72100_CLK_USB1>;
+ clock-output-names = "ether", "usb0", "usb1";
};
mstp8_clks: mstp8_clks@fcfe0434 {
diff --git a/include/dt-bindings/clock/r7s72100-clock.h b/include/dt-bindings/clock/r7s72100-clock.h
index bc256d31099a..dcd2072151fc 100644
--- a/include/dt-bindings/clock/r7s72100-clock.h
+++ b/include/dt-bindings/clock/r7s72100-clock.h
@@ -34,6 +34,8 @@
/* MSTP7 */
#define R7S72100_CLK_ETHER 4
+#define R7S72100_CLK_USB0 1
+#define R7S72100_CLK_USB1 0
/* MSTP8 */
#define R7S72100_CLK_MMCIF 4
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RESEND PATCH 1/2] arc: axs10x: Add DT bindings for I2S audio playback
From: Vineet Gupta @ 2017-04-27 19:13 UTC (permalink / raw)
To: Jose Abreu,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: Carlos Palminha, Alexey Brodkin, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <f1e3621d-3dbd-116d-d9c1-3aeb9bd40c2a-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On 04/27/2017 11:42 AM, Jose Abreu wrote:
> Hi Vineet,
>
>
> On 27-04-2017 00:31, Vineet Gupta wrote:
>> On 04/26/2017 01:55 AM, Jose Abreu wrote:
>>> Hi Vineet,
>>>
>>>
>>> On 24-04-2017 18:36, Vineet Gupta wrote:
>>>> On 04/21/2017 03:15 AM, Jose Abreu wrote:
>>>>> This patch adds the necessary DT bindings to get HDMI audio
>>>>> output in ARC AXS10x SDP. The bindings for I2S controller were
>>>>> added as well as the bindings for simple audio card.
>>>> Are these waiting on Rob or is it OK for me to pick these up for 4.12 ?
>>> Yes, I was waiting for Rob ack but he has been silent. It would
>>> be nice if these went for 4.12.
>> Ok lets wait another couple of days before I pick those up.
>> In the mean time, can you please restest the series against 4.11-rcX and report
>> here that patches are still valid and do as intended !
> I tested based on drm-next of today (which is based on 4.11-rc7)
> and the patches work okay.
Pushed to for-curr for 4.12 !
Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G
From: Arnd Bergmann @ 2017-04-27 19:56 UTC (permalink / raw)
To: Chunyan Zhang
Cc: arm-soc, Mathieu Poirier, Orson Zhai (翟京),
Linux Kernel Mailing List, devicetree-u79uwXL29TY76Z2rM5mHXA,
Linux ARM, zhang.lyra-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1492746440-11071-1-git-send-email-chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
On Fri, Apr 21, 2017 at 5:47 AM, Chunyan Zhang
<chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org> wrote:
> From: Orson Zhai <orson.zhai-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
>
> SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.
>
> According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
> peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
> and sp9860g dts is for the board level.
>
> Signed-off-by: Orson Zhai <orson.zhai-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> Signed-off-by: Chunyan Zhang <chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>
> Reviewed-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Applied to next/dt64 now, thanks!
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
* [PATCH v2 0/3] thermal: broadcom: Add NSP Thermal Support
From: Jon Mason @ 2017-04-27 21:23 UTC (permalink / raw)
To: Florian Fainelli, Zhang Rui, Eduardo Valentin, Rob Herring,
Mark Rutland
Cc: bcm-kernel-feedback-list, linux-arm-kernel, linux-kernel,
linux-pm, devicetree
Changes in v2:
* Split SoC enablement into a separate patch (per Eduardo Valentin)
* Added Eduardo Valentin's Acked-by to the DTS patch
This adds support for NSP to the existing Northstar thermal driver.
This code is based on patches currently in the Linux SoC Thermal git
tree. Specfically,
https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=linus&id=a94cb7eeecc4104a6874339f90c5d0647359c102
Jon Mason (3):
ARM: BCM: Enable thermal support for iProc SoCs
thermal: broadcom: ns-thermal: default on iProc SoCs
ARM: dts: NSP: Add Thermal Support
arch/arm/boot/dts/bcm-nsp.dtsi | 26 ++++++++++++++++++++++++++
arch/arm/mach-bcm/Kconfig | 2 ++
drivers/thermal/broadcom/Kconfig | 9 +++++----
3 files changed, 33 insertions(+), 4 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/3] ARM: BCM: Enable thermal support for iProc SoCs
From: Jon Mason @ 2017-04-27 21:23 UTC (permalink / raw)
To: Florian Fainelli, Zhang Rui, Eduardo Valentin, Rob Herring,
Mark Rutland
Cc: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493328194-1766-1-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows
the ns-thermal driver to be selected via menuconfig.
Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
arch/arm/mach-bcm/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index a0e66d8..da2bfeb 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -19,6 +19,8 @@ config ARCH_BCM_IPROC
select GPIOLIB
select ARM_AMBA
select PINCTRL
+ select THERMAL
+ select THERMAL_OF
help
This enables support for systems based on Broadcom IPROC architected SoCs.
The IPROC complex contains one or more ARM CPUs along with common
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 2/3] thermal: broadcom: ns-thermal: default on iProc SoCs
From: Jon Mason @ 2017-04-27 21:23 UTC (permalink / raw)
To: Florian Fainelli, Zhang Rui, Eduardo Valentin, Rob Herring,
Mark Rutland
Cc: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493328194-1766-1-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Tweak the Kconfig description to mention support for NSP and make the
default on for iProc based platforms.
Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
drivers/thermal/broadcom/Kconfig | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
index f0dea8a..26d706c 100644
--- a/drivers/thermal/broadcom/Kconfig
+++ b/drivers/thermal/broadcom/Kconfig
@@ -1,8 +1,9 @@
config BCM_NS_THERMAL
tristate "Northstar thermal driver"
depends on ARCH_BCM_IPROC || COMPILE_TEST
+ default ARCH_BCM_IPROC
help
- Northstar is a family of SoCs that includes e.g. BCM4708, BCM47081,
- BCM4709 and BCM47094. It contains DMU (Device Management Unit) block
- with a thermal sensor that allows checking CPU temperature. This
- driver provides support for it.
+ Support for the Northstar and Northstar Plus family of SoCs (e.g.
+ BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU (Device
+ Management Unit) block with a thermal sensor that allows checking CPU
+ temperature.
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 3/3] ARM: dts: NSP: Add Thermal Support
From: Jon Mason @ 2017-04-27 21:23 UTC (permalink / raw)
To: Florian Fainelli, Zhang Rui, Eduardo Valentin, Rob Herring,
Mark Rutland
Cc: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493328194-1766-1-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Add thermal support via the ns-thermal driver and create a single
thermal zone for the entire SoC.
Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Acked-by: Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 832795b..be6fcfb 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -383,6 +383,12 @@
<0x3f408 0x04>;
};
+ thermal: thermal@3f2c0 {
+ compatible = "brcm,ns-thermal";
+ reg = <0x3f2c0 0x10>;
+ #thermal-sensor-cells = <0>;
+ };
+
sata_phy: sata_phy@40100 {
compatible = "brcm,iproc-nsp-sata-phy";
reg = <0x40100 0x340>;
@@ -533,4 +539,24 @@
brcm,pcie-msi-inten;
};
};
+
+ thermal-zones {
+ cpu-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <1000>;
+ coefficients = <(-556) 418000>;
+ thermal-sensors = <&thermal>;
+
+ trips {
+ cpu-crit {
+ temperature = <125000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ };
+ };
+ };
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4] NFC: trf7970a: Correct register settings for 27MHz clock
From: Geoff Lansberry @ 2017-04-27 21:28 UTC (permalink / raw)
To: linux-wireless, sameo
Cc: kernel-janitors, linux-kernel, linux-nfc, devicetree, mgreer,
justin, colin.king, wharms, Geoff Lansberry
In prior commits the selected clock frequency does not propagate
correctly to what is written to the TRF7970A_MODULATOR_SYS_CLK_CTRL
register.
Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
---
drivers/nfc/trf7970a.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 6ed5d7e..f7fee7d 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -2067,6 +2067,13 @@ static int trf7970a_probe(struct spi_device *spi)
return -EINVAL;
}
+ if (clk_freq == TRF7970A_27MHZ_CLOCK_FREQUENCY) {
+ trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_27MHZ;
+ dev_dbg(trf->dev, "trf7970a configured for 27MHz crystal\n");
+ } else {
+ trf->modulator_sys_clk_ctrl = 0;
+ }
+
ret = devm_request_threaded_irq(trf->dev, spi->irq, NULL,
trf7970a_irq,
IRQF_TRIGGER_RISING | IRQF_ONESHOT,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors
From: Rob Herring @ 2017-04-27 21:57 UTC (permalink / raw)
To: Markus Mayer
Cc: Jean Delvare, Guenter Roeck, Mark Rutland, Florian Fainelli,
Broadcom Kernel List, Linux HWMON List, Device Tree List,
ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <CAGt4E5uu1Ty0ReaiBZ0kcR_-jnqJQL8vgU4Y9mL64FP7f+=T7Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 27, 2017 at 11:28:37AM -0700, Markus Mayer wrote:
> On 25 April 2017 at 12:29, Markus Mayer <markus.mayer-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> > Hi Rob,
> >
> > On 18 April 2017 at 13:17, Markus Mayer <code-7CzEARzsJhSsTnJN9+BGXg@public.gmane.org> wrote:
> >> From: Markus Mayer <mmayer-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> >>
> >> Provide bindings for the Broadcom STB DDR PHY Front End (DPFE).
> >
> > Would you be able to have a look at this binding? The driver won't be
> > upstreamed as hwmon driver (as per Guenter's comments). I am currently
> > converting the driver to a "soc" driver instead, but the proposed
> > binding remains unchanged.
> >
> > If you have comments or suggestions, I would like to incorporate them
> > with the new series I will be sending out.
>
> To explain a bit more what we are looking for: we had a internal
> discussions how to structure this binding and are looking for some
> guidance.
>
> Should we create three different nodes for the three different memory
> areas (dpfe-cpu@..., dpfe-dmem@..., dpfe-imem@...), each with a single
> "reg" property (which is the proposal below) or should this be one
> single property with 3 "reg" cells, i.e. something like this:
Either way could be okay. It is conceptually 1 thing or 3?
>
> dpfe-cpu@f1132000 {
> ...
> reg = <0xf1132000 0x180 /* register space */
> 0xf1134000 0x1000 /* data memory */
> 0xf1138000 0x4000>; /* instruction memory */
> ...
> };
>
> Regards,
> -Markus
>
> >> Signed-off-by: Markus Mayer <mmayer-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> >> ---
> >> .../devicetree/bindings/hwmon/brcmstb-dpfe.txt | 68 ++++++++++++++++++++++
> >> 1 file changed, 68 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt b/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
> >> new file mode 100644
> >> index 0000000..3519197
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
> >> @@ -0,0 +1,68 @@
> >> +DDR PHY Front End (DPFE) for Broadcom STB
> >> +=========================================
> >> +
> >> +DPFE and the DPFE firmware provide an interface for the host CPU to
> >> +communicate with the DCPU, which resides inside the DDR PHY.
> >> +
> >> +There are three memory regions for interacting with the DCPU.
> >> +
> >> +The DCPU Register Space
> >> +-----------------------
> >> +
> >> +Required properties:
> >> + - compatible: must be one of brcm,bcm7271-dpfe-cpu, brcm,dpfe-cpu-v12.0.0.0
> >> + or brcm,dpfe-cpu
3 compatibles is a bit excessive. You can always use
brcm,bcm7271-dpfe-cpu as a fallback for other chips. I wouldn't expect a
DDR phy to be around a long time without changes given process and DDR
technology changes.
> >> + - reg: must reference the start address and length of the DCPU register
> >> + space
> >> +
> >> +Optional properties:
> >> + - cell-index: the index of the DPFE instance; will default to 0 if not set
Don't use cell-index. It's not a valid property for FDT (only real
OpenFirmware).
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors
From: Florian Fainelli @ 2017-04-27 22:00 UTC (permalink / raw)
To: Rob Herring, Markus Mayer
Cc: Jean Delvare, Guenter Roeck, Mark Rutland, Broadcom Kernel List,
Linux HWMON List, Device Tree List, ARM Kernel List,
Linux Kernel Mailing List
In-Reply-To: <20170427215737.dmnj4u2e4tfc6vfv@rob-hp-laptop>
On 04/27/2017 02:57 PM, Rob Herring wrote:
>>>> + - reg: must reference the start address and length of the DCPU register
>>>> + space
>>>> +
>>>> +Optional properties:
>>>> + - cell-index: the index of the DPFE instance; will default to 0 if not set
>
> Don't use cell-index. It's not a valid property for FDT (only real
> OpenFirmware).
My bad, I was advising Markus to use this property since it was largely
used throughout Documentation/devicetree/bindings/. What would be a more
appropriate way to have the same information? Aliases?
--
Florian
^ permalink raw reply
* Re: [PATCH v4 1/2] of: per-file dtc compiler flags
From: Rob Herring @ 2017-04-27 22:25 UTC (permalink / raw)
To: frowand.list; +Cc: stephen.boyd, mmarek, devicetree, linux-kernel, linux-kbuild
In-Reply-To: <1493165394-29367-2-git-send-email-frowand.list@gmail.com>
On Tue, Apr 25, 2017 at 05:09:53PM -0700, frowand.list@gmail.com wrote:
> From: Frank Rowand <frank.rowand@sony.com>
>
> The dtc compiler version that adds initial support was available
> in 4.11-rc1. Add the ability to set an additional dtc compiler
> flag is needed by overlays.
>
> Signed-off-by: Frank Rowand <frank.rowand@sony.com>
> ---
> scripts/Makefile.lib | 2 ++
> 1 file changed, 2 insertions(+)
Applied.
^ permalink raw reply
* Re: [PATCH v4 2/2] of: Add unit tests for applying overlays
From: Rob Herring @ 2017-04-27 22:26 UTC (permalink / raw)
To: frowand.list; +Cc: stephen.boyd, mmarek, devicetree, linux-kernel, linux-kbuild
In-Reply-To: <1493165394-29367-3-git-send-email-frowand.list@gmail.com>
On Tue, Apr 25, 2017 at 05:09:54PM -0700, frowand.list@gmail.com wrote:
> From: Frank Rowand <frank.rowand@sony.com>
>
> Existing overlay unit tests examine individual pieces of the overlay
> code. The new tests target the entire process of applying an overlay.
>
> Signed-off-by: Frank Rowand <frank.rowand@sony.com>
> ---
>
> There are checkpatch warnings. I have reviewed them and feel they
> can be ignored.
>
> drivers/of/fdt.c | 14 +-
> drivers/of/of_private.h | 12 +
> drivers/of/unittest-data/Makefile | 17 +-
> drivers/of/unittest-data/overlay.dts | 53 ++++
> drivers/of/unittest-data/overlay_bad_phandle.dts | 20 ++
> drivers/of/unittest-data/overlay_base.dts | 80 ++++++
> drivers/of/unittest.c | 317 +++++++++++++++++++++++
> 7 files changed, 505 insertions(+), 8 deletions(-)
> create mode 100644 drivers/of/unittest-data/overlay.dts
> create mode 100644 drivers/of/unittest-data/overlay_bad_phandle.dts
> create mode 100644 drivers/of/unittest-data/overlay_base.dts
Applied.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/3] ARM: BCM: Enable thermal support for iProc SoCs
From: Scott Branden @ 2017-04-27 23:10 UTC (permalink / raw)
To: Jon Mason, Florian Fainelli, Zhang Rui, Eduardo Valentin,
Rob Herring, Mark Rutland
Cc: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493328194-1766-2-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 17-04-27 02:23 PM, Jon Mason wrote:
> Change the iProc Kconfig to select THERMAL and THERMAL_OF, which allows
> the ns-thermal driver to be selected via menuconfig.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> arch/arm/mach-bcm/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index a0e66d8..da2bfeb 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -19,6 +19,8 @@ config ARCH_BCM_IPROC
> select GPIOLIB
> select ARM_AMBA
> select PINCTRL
> + select THERMAL
> + select THERMAL_OF
This is NSP specific at this point. Also, If it increases code size in
any way it shouldn't be selected for all IPROC SoCS. I'd rather this
was just selected via defconfig
> help
> This enables support for systems based on Broadcom IPROC architected SoCs.
> The IPROC complex contains one or more ARM CPUs along with common
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen
From: Andi Shyti @ 2017-04-27 23:41 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Andrzej Hajda, Chanwoo Choi, linux-input, devicetree,
linux-kernel, Andi Shyti, javier, Andi Shyti
In-Reply-To: <20170427003918.GA1236@dtor-glaptop>
Hi Dmitry,
On Wed, Apr 26, 2017 at 05:39:18PM -0700, Dmitry Torokhov wrote:
>
> On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi Shyti wrote:
> > +static irqreturn_t stmfts_irq_handler(int irq, void *dev)
> > +{
> > + struct stmfts_data *sdata = dev;
> > + int ret;
> > +
> > + mutex_lock(&sdata->mutex);
> > + ret = i2c_smbus_read_i2c_block_data(sdata->client,
> > + STMFTS_READ_ONE_EVENT,
> > + STMFTS_EVENT_SIZE, sdata->data);
> > +
> > + if (ret < 0 || ret != STMFTS_EVENT_SIZE)
> > + goto exit;
>
> Why do we split read into 2 chunks? Can we issue STMFTS_READ_ALL_EVENT
> right away instead of reading first event, analyzing it, and then (maybe)
> fetching the rest?
The reason is that I don't need to read all the events at once
anytime, for example debug events or confirmation events normally
occur with a single event in the fifo. In this case I would read
only 32bytes instead of 256bytes.
Unfortunately there are no other ways to know how many events are
in the queue beforehand.
There are some "magic" commands to figure that out, but this is
specific to the Samsung's version of the stmfts and I don't want
to push it to everyone else.
The difference between this version of the driver and the
previous one is that in this one if I stress-use of the
touchscreen, the throughput is optimised (e.g. if I use more
fingers).
Before I was reading single events at time, establishing for each
read an i2c "handshake", this was de-synchronizing the protocol.
> Also, why do we use smbus protocol for the first event and i2c for the
> rest?
Standing to the datasheet, the device is smbus compatible and it
should use smbus all the time. The problem is that here the
protocol is broken in case I want to read out the full FIFO,
which has a total of 256bytes and I have to force the read by
using the function "stmfts_read_i2c_block_data()".
Personally I don't like these kind of i2c reads, because they
duplicate code, the SMBUS does that already, this is why in the
previous version I was reading the events one by one.
Do you think it is better to make a single read of all the fifo?
Andi
^ permalink raw reply
* Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen
From: Dmitry Torokhov @ 2017-04-27 23:56 UTC (permalink / raw)
To: Andi Shyti
Cc: Rob Herring, Andrzej Hajda, Chanwoo Choi, linux-input, devicetree,
linux-kernel, Andi Shyti, javier
In-Reply-To: <20170427234156.glh2lchwr57fllmo@gangnam.samsung>
On Fri, Apr 28, 2017 at 08:41:56AM +0900, Andi Shyti wrote:
> Hi Dmitry,
>
> On Wed, Apr 26, 2017 at 05:39:18PM -0700, Dmitry Torokhov wrote:
> >
> > On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi Shyti wrote:
> > > +static irqreturn_t stmfts_irq_handler(int irq, void *dev)
> > > +{
> > > + struct stmfts_data *sdata = dev;
> > > + int ret;
> > > +
> > > + mutex_lock(&sdata->mutex);
> > > + ret = i2c_smbus_read_i2c_block_data(sdata->client,
> > > + STMFTS_READ_ONE_EVENT,
> > > + STMFTS_EVENT_SIZE, sdata->data);
> > > +
> > > + if (ret < 0 || ret != STMFTS_EVENT_SIZE)
> > > + goto exit;
> >
> > Why do we split read into 2 chunks? Can we issue STMFTS_READ_ALL_EVENT
> > right away instead of reading first event, analyzing it, and then (maybe)
> > fetching the rest?
>
> The reason is that I don't need to read all the events at once
> anytime, for example debug events or confirmation events normally
> occur with a single event in the fifo. In this case I would read
> only 32bytes instead of 256bytes.
>
> Unfortunately there are no other ways to know how many events are
> in the queue beforehand.
>
> There are some "magic" commands to figure that out, but this is
> specific to the Samsung's version of the stmfts and I don't want
> to push it to everyone else.
>
> The difference between this version of the driver and the
> previous one is that in this one if I stress-use of the
> touchscreen, the throughput is optimised (e.g. if I use more
> fingers).
> Before I was reading single events at time, establishing for each
> read an i2c "handshake", this was de-synchronizing the protocol.
>
> > Also, why do we use smbus protocol for the first event and i2c for the
> > rest?
>
> Standing to the datasheet, the device is smbus compatible and it
> should use smbus all the time. The problem is that here the
> protocol is broken in case I want to read out the full FIFO,
> which has a total of 256bytes and I have to force the read by
> using the function "stmfts_read_i2c_block_data()".
>
> Personally I don't like these kind of i2c reads, because they
> duplicate code, the SMBUS does that already, this is why in the
> previous version I was reading the events one by one.
>
> Do you think it is better to make a single read of all the fifo?
It depends on what the common case is. It looks like for touch data you
always do 2 i2c transactions per interrupt. I wonder if doing it once
and paying the price of overhead for debug a nd confirmation events is
not worth it.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 2/2] Input: add support for the STMicroelectronics FingerTip touchscreen
From: Andi Shyti @ 2017-04-28 0:07 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Andrzej Hajda, Chanwoo Choi, linux-input, devicetree,
linux-kernel, Andi Shyti, javier
In-Reply-To: <20170427235645.GB33675@dtor-ws>
Hi Dmitry,
On Thu, Apr 27, 2017 at 04:56:45PM -0700, Dmitry Torokhov wrote:
> On Fri, Apr 28, 2017 at 08:41:56AM +0900, Andi Shyti wrote:
> > On Wed, Apr 26, 2017 at 05:39:18PM -0700, Dmitry Torokhov wrote:
> > > On Mon, Mar 27, 2017 at 10:07:43PM +0900, Andi Shyti wrote:
> > > > +static irqreturn_t stmfts_irq_handler(int irq, void *dev)
> > > > +{
> > > > + struct stmfts_data *sdata = dev;
> > > > + int ret;
> > > > +
> > > > + mutex_lock(&sdata->mutex);
> > > > + ret = i2c_smbus_read_i2c_block_data(sdata->client,
> > > > + STMFTS_READ_ONE_EVENT,
> > > > + STMFTS_EVENT_SIZE, sdata->data);
> > > > +
> > > > + if (ret < 0 || ret != STMFTS_EVENT_SIZE)
> > > > + goto exit;
> > >
> > > Why do we split read into 2 chunks? Can we issue STMFTS_READ_ALL_EVENT
> > > right away instead of reading first event, analyzing it, and then (maybe)
> > > fetching the rest?
> >
> > The reason is that I don't need to read all the events at once
> > anytime, for example debug events or confirmation events normally
> > occur with a single event in the fifo. In this case I would read
> > only 32bytes instead of 256bytes.
> >
> > Unfortunately there are no other ways to know how many events are
> > in the queue beforehand.
> >
> > There are some "magic" commands to figure that out, but this is
> > specific to the Samsung's version of the stmfts and I don't want
> > to push it to everyone else.
> >
> > The difference between this version of the driver and the
> > previous one is that in this one if I stress-use of the
> > touchscreen, the throughput is optimised (e.g. if I use more
> > fingers).
> > Before I was reading single events at time, establishing for each
> > read an i2c "handshake", this was de-synchronizing the protocol.
> >
> > > Also, why do we use smbus protocol for the first event and i2c for the
> > > rest?
> >
> > Standing to the datasheet, the device is smbus compatible and it
> > should use smbus all the time. The problem is that here the
> > protocol is broken in case I want to read out the full FIFO,
> > which has a total of 256bytes and I have to force the read by
> > using the function "stmfts_read_i2c_block_data()".
> >
> > Personally I don't like these kind of i2c reads, because they
> > duplicate code, the SMBUS does that already, this is why in the
> > previous version I was reading the events one by one.
> >
> > Do you think it is better to make a single read of all the fifo?
>
> It depends on what the common case is. It looks like for touch data you
> always do 2 i2c transactions per interrupt. I wonder if doing it once
> and paying the price of overhead for debug a nd confirmation events is
> not worth it.
makes sense, indeed, because I do it all the time when for touch
events (which are the most) not only when the FIFO is not full.
I will do it this way, then... Thanks!
Andi
^ permalink raw reply
* Re: [PATCH v4] NFC: trf7970a: Correct register settings for 27MHz clock
From: Mark Greer @ 2017-04-28 0:28 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
sameo-VuQAYsv1563Yd54FQh9/CA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfc-hn68Rpc1hR1g9hUCZPvPmw,
devicetree-u79uwXL29TY76Z2rM5mHXA, mgreer-luAo+O/VEmrlveNOaEYElw,
justin-R+k406RtEhcAvxtiuMwx3w, colin.king-Z7WLFzj8eWMS+FvcfC7Uqw,
wharms-fPG8STNUNVg
In-Reply-To: <1493328526-28395-1-git-send-email-geoff-R+k406RtEhcAvxtiuMwx3w@public.gmane.org>
On Thu, Apr 27, 2017 at 05:28:46PM -0400, Geoff Lansberry wrote:
> In prior commits the selected clock frequency does not propagate
> correctly to what is written to the TRF7970A_MODULATOR_SYS_CLK_CTRL
> register.
>
> Signed-off-by: Geoff Lansberry <geoff-R+k406RtEhcAvxtiuMwx3w@public.gmane.org>
> ---
Acked-by: Mark Greer <mgreer-luAo+O/VEmrlveNOaEYElw@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
From: Ryder Lee @ 2017-04-28 2:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-pci,
Linux Kernel Mailing List, Rob Herring,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Bjorn Helgaas,
Linux ARM
In-Reply-To: <CAK8P3a0vD8s_3R+jS=JdUXX3X05SkCk-mipMA6UxWYQZe6vLUQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 2017-04-27 at 21:06 +0200, Arnd Bergmann wrote:
> On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> > Hi
> >
> > On Tue, 2017-04-25 at 14:18 +0200, Arnd Bergmann wrote:
> >> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> >> > Add documentation for PCIe host driver available in MT7623
> >> > series SoCs.
> >> >
> >> > Signed-off-by: Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >> > ---
> >> > .../bindings/pci/mediatek,mt7623-pcie.txt | 153 +++++++++++++++++++++
> >> > 1 file changed, 153 insertions(+)
> >> > create mode 100644 Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> >> > new file mode 100644
> >> > index 0000000..ee93ba2
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> >> > @@ -0,0 +1,153 @@
> >> > +Mediatek MT7623 PCIe controller
> >> > +
> >> > +Required properties:
> >> > +- compatible: Should contain "mediatek,mt7623-pcie".
> >>
> >> Did mediatek license the IP block from someone else or was it
> >> developed in-house? Is there a name and/or version identifier
> >> for the block itself other than identifying it as the one in mt7623?
> >
> > Originally, it license from synopsys. Our designer add a wrapper to hide
> > the DBI detail so that we cannot use them directly. Perhaps I can call
> > it "mediatek,gen2v1-pcie", because we have a plan to upstream a in-house
> > Gen2 IP in the future.
>
> Ok, so this is the same hardware that drivers/pci/dwc/ handles, but
> it needs a separate driver because the wrapper that was added uses
> a completely different register layout, right?
Yes, that's what I mean. At first, I really want to base on
drivers/pci/dwc/ to implement this driver. Eventually I found it hard to
go on, like what I said before.
> Are any of the registers the same at all, e.g. for MSI handling?
No, It doesn't support MSI. All I can do is using the registers that designer provide
to me. The others are inviable for software. So I treat it as different hardware.
Furthermore, we hope that we can put all mediatek drivers together
regardless of in-house IP or lincense IP
We have no particular IP name but just use chip name to call it. So I
will temporarily use "mediatek,gen2v1-pcie" in patch v1.
> >> > +Required properties:
> >> > +- device_type: Must be "pci"
> >> > +- assigned-addresses: Address and size of the port configuration registers
> >> > +- reg: Only the first four bytes are used to refer to the correct bus number
> >> > + and device number.
> >> > +- #address-cells: Must be 3
> >> > +- #size-cells: Must be 2
> >> > +- ranges: Sub-ranges distributed from the PCIe controller node. An empty
> >> > + property is sufficient.
> >> > +- clocks: Must contain an entry for each entry in clock-names.
> >> > + See ../clocks/clock-bindings.txt for details.
> >> > +- clock-names: Must include the following entries:
> >> > + - sys_ck
> >> > +- resets: Must contain an entry for each entry in reset-names.
> >> > + See ../reset/reset.txt for details.
> >>
> >> This seems odd: you have a device that is simply identified as "pci"
> >> without any more specific ID, but you require additional properties
> >> (clocks, reset, ...) that are not part of the standard PCI binding.
> >>
> >> Can you clarify how the port devices related to the root device in
> >> this hardware design?
> >
> > I will write clarify like this:
> >
> > PCIe subsys includes one Host/PCI bridge and 3 PCIe MAC port. There
> > are 3 bus master for data access and 1 slave for configuration and
> > status register access. Each port has PIPE interface to PHY and
>
> If I understand this right, then each of the ports in your hardware
> is what we normally drive using the drivers/pci/dwc/ driver framework,
> but your implementation actually made it more PCI standard compliant
> by implementing the normal PCIe host bridge registers for all ports
> combined, something that most others don't.
In my view, it's correct to implement our driver in this way. But I
don't really understand the details about other platforms.
> >> Have you considered moving the nonstandard properties into the host
> >> bridge node and having that device deal with setting up the links
> >> to the other drivers? That way we could use the regular pcie
> >> port driver for the children.
> >>
> >
> > OK, but I still want to use port->reset to catch reset properties in
> > driver.
>
> Do you mean in drivers/pci/pcie/portdrv_pci.c? I see that it
> has a function called pcie_portdrv_slot_reset(), but I don't see
> how that relates to your reset line at the moment. Is this
> something you have submitted in a different series?
>
> Or do you mean in this host driver? The problem I see with
> that approach is that the port device is owned by portdrv_pci,
> so the host bridge driver should not look at the properties of
> the port.
hifsys: syscon@1a000000 {
compatible = "mediatek,mt7623-hifsys", "syscon";
reg = <0 0x1a000000 0 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};
We have a reset controller(hifsys) in our platform. We can just use
devm_reset_control_get() to catch it in the host driver to control port reset.
After much consideration, I will move all nonstandard properties to root
node, let child node cleanable.
> >> > +- reset-names: Must include the following entries:
> >> > + - pcie-reset
> >> > +- num-lanes: Number of lanes to use for this port.
> >> > +- phys: Must contain an entry for each entry in phy-names.
> >> > +- phy-names: Must include an entry for each sub node. Entries are of the form
> >> > + "pcie-phyN": where N ranges from 0 to the value specified for port number.
> >> > + See ../phy/phy-mt7623-pcie.txt for details.
> >>
> >> I think the name should not include the number of the port but rather
> >> be always the same here.
> >>
> >
> > Hmm, I think it's better to keep the name here. It's more readable for
> > user to understand the relationship between port0 and phy0.
>
> No, I would argue that it's confusing for the reader because it
> is different from how most other DT bindings work: In each device
> node, you tend to have a set of properties with well-known names
> that are documented. When your reference is called "pcie-phy1"
> in one node and "pcie-phy2", I would interpret that as both ports
> having two phys each, but only one of them being used.
Okay I will write it more clearly
- phys: list of PHY specifiers (used by generic PHY framework)
- phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on
the number of PHYs as specified in *phys* property.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] PCI: mediatek: Add Mediatek PCIe host controller support
From: Ryder Lee @ 2017-04-28 2:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree, linux-pci, Linux Kernel Mailing List, Rob Herring,
linux-mediatek, Bjorn Helgaas, Linux ARM
In-Reply-To: <CAK8P3a0DjPL8uWuXfCmEwt05SCPJ0yEQTAJmZAPtFDEfsn4a1Q@mail.gmail.com>
Hi,
On Thu, 2017-04-27 at 20:55 +0200, Arnd Bergmann wrote:
> On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> > On Tue, 2017-04-25 at 14:38 +0200, Arnd Bergmann wrote:
> >> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
>
> >> > +static int mtk_pcie_enable_ports(struct mtk_pcie *pcie)
> >> > +{
> >> > + struct device *dev = pcie->dev;
> >> > + struct mtk_pcie_port *port, *tmp;
> >> > + int err, linkup = 0;
> >> > +
> >> > + list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
> >> > + err = clk_prepare_enable(port->sys_ck);
> >> > + if (err) {
> >> > + dev_err(dev, "failed to enable port%d clock\n",
> >> > + port->index);
> >> > + continue;
> >> > + }
> >> > +
> >> > + /* assert RC */
> >> > + reset_control_assert(port->reset);
> >> > + /* de-assert RC */
> >> > + reset_control_deassert(port->reset);
> >> > +
> >> > + /* power on PHY */
> >> > + err = phy_power_on(port->phy);
> >> > + if (err) {
> >> > + dev_err(dev, "failed to power on port%d phy\n",
> >> > + port->index);
> >> > + goto err_phy_on;
> >> > + }
> >> > +
> >> > + mtk_pcie_assert_ports(port);
> >> > +
> >>
> >> Similar to the comment I had for the binding, I wonder if it would be
> >> better to keep all the information about the ports in one place and
> >> then just deal with it at the root level.
> >>
> >> Alternatively, we could decide to standardize on the properties
> >> you have added to the pcie port node, but then I would handle
> >> them in the pcieport driver rather than in the host bridge driver.
> >
> > Sorry, I'm not sure what you want me to do here.
> >
> > I could move all clock operation in root level. But we need to keep the
> > reset and PHY operation sequence in the loop, In addition, we could
> > easily free resources if ports link fail.
> >
> > How about moving this function to mtk_pcie_parse_and_add_res()?
>
> That could work, please try it out and see if the code gets better or
> worse. This may depend on what we end up doing with the DT
> properties.
I will try it on next version, and we can continue our discussion on
that series.
> >> > +/*
> >> > + * This IP lacks interrupt status register to check or map INTx from
> >> > + * different devices at the same time.
> >> > + */
> >> > +static int __init mtk_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
> >> > +{
> >> > + struct mtk_pcie *pcie = dev->bus->sysdata;
> >> > + struct mtk_pcie_port *port;
> >> > +
> >> > + list_for_each_entry(port, &pcie->ports, list)
> >> > + if (port->index == slot)
> >> > + return port->irq;
> >> > +
> >> > + return -1;
> >> > +}
> >>
> >> This looks odd, what is it needed for specifically? It looks like
> >> it's broken for devices behind bridges, and the interrupt mapping
> >> should normally come from the interrupt-map property, without
> >> the need for a driver specific map_irq override.
> >
> > Our hardware just has a GIC for each port and lacks interrupt status for
> > host driver to distinguish INTx. So I return port IRQ here.
>
> You should still be able to express this with standard interrupt-map
> DT property, without having to resort to your own map_irq
> callback handler.
>
> In the interrupt-map-mask, you can ignore the interrupt line
> only list the devfn of the root ports for each entry.
Okay, I will fix it.
> >> > +static int mtk_pcie_register_ports(struct mtk_pcie *pcie)
> >> > +{
> >> > + struct pci_bus *bus, *child;
> >> > +
> >> > + bus = pci_scan_root_bus(pcie->dev, 0, &mtk_pcie_ops, pcie,
> >> > + &pcie->resources);
> >>
> >> Can you use the new pci_register_host_bridge() method instead of
> >> pci_scan_root_bus() here?
> >
> > May I know what's difference between pci_scan_root_bus() and using
> > pci_register_host_bridge() directly? What situation should we use it?
> > It seems that just tegra use this new method currently.
>
> We introduced the new function for tegra for now, in the long run
> I would hope we can convert all other drivers to it as well, to make it
> easier to add further parameters.
>
> The new function also has a cleaner way of dealing with the memory
> allocations, similar to how other subsystems work.
Sounds good. I will change to use that.
Thanks!
^ 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