* 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
* [PATCH] of: unittest, fix possible use of unitialized variable
From: frowand.list-Re5JQEeQqe8AvxtiuMwx3w @ 2017-04-28 4:31 UTC (permalink / raw)
To: Rob Herring, stephen.boyd-QSEj5FYQhm4dnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
From: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
Fix problem reported in the linux-next build. last_sibling may be
unitialized in of_unittest() if the device tree is empty.
Signed-off-by: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
---
drivers/of/unittest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 12597ff8cfb0..8f14a43f48e5 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -2119,7 +2119,7 @@ static int __init overlay_data_add(int onum)
*/
static __init void of_unittest_overlay_high_level(void)
{
- struct device_node *last_sibling;
+ struct device_node *last_sibling = NULL;
struct device_node *np;
struct device_node *of_symbols;
struct device_node *overlay_base_symbols;
--
Frank Rowand <frank.rowand-7U/KSKJipcs@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 related
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-28 5:00 UTC (permalink / raw)
To: Sudeep Holla, Rajendra Nayak
Cc: Mark Brown, Rafael Wysocki, ulf.hansson, Kevin Hilman,
Viresh Kumar, Nishanth Menon, Stephen Boyd, linaro-kernel,
linux-pm, linux-kernel, Vincent Guittot, robh+dt, lina.iyer,
devicetree
In-Reply-To: <9019aebe-95ba-b1b8-65a9-5be927934218@codeaurora.org>
On 27-04-17, 16:20, Rajendra Nayak wrote:
>
> On 04/27/2017 03:12 PM, Sudeep Holla wrote:
> []..
>
> >>
> >>> At qualcomm, we have an external M3 core (running its own firmware) which controls
> >>> a few voltage rails (including AVS on those). The devices vote for the voltage levels
> >
> > Thanks for explicitly mentioning this, but ...
> >
> >>> (or performance levels) they need by passing an integer value to the M3 (not actual
> >
> > you contradict here, is it just voltage or performance(i.e. frequency)
> > or both ? We need clarity there to choose the right representation.
>
> Its just voltage.
Right. Its just voltage in this case, but we can't speak of future
platforms here and we have to consider this thing as an operating
performance point only. I still think that this thread is moving in
the right direction, specially after V6 which looks much better.
If we have anything strong against the way V6 is trying to solve it, I
want to talk about it right now and get inputs from all the parties
involved. Scrapping all this work is fine, but I would like to do it
ASAP in that case :)
--
viresh
^ permalink raw reply
* Re: [PATCH v2] arm: dts: sun7i-a20-bananapi: name the GPIO lines
From: Oleksij Rempel @ 2017-04-28 5:11 UTC (permalink / raw)
To: Linus Walleij
Cc: devicetree@vger.kernel.org, Chen-Yu Tsai, Oleksij Rempel,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACRpkdZn7-SL5kmGn7Pysz=QiQFBEm8+c6bw=hE5F0CV4ct0RQ@mail.gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 1137 bytes --]
Am 08.08.2016 um 19:51 schrieb Linus Walleij:
> On Fri, Aug 5, 2016 at 10:06 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>
>> This names the GPIO lines on the Banana Pi board in accordance with
>> the A20_Banana_Pi v1.4 Specification.
>>
>> This will make these line names reflect through to userspace
>> so that they can easily be identified and used with the new
>> character device ABI.
>>
>> Some care has been taken to name all lines, not just those used
>> by the external connectors, also lines that are muxed into some
>> other function than GPIO: these are named "[FOO]" so that users
>> can see with lsgpio what all lines are used for.
>>
>> Ps: most of the text was taken from Linus Wallej patch.
>>
>> Cc: devicetree@vger.kernel.org
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: Chen-Yu Tsai <wens@csie.org>
>> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Yours,
> Linus Walleij
Hm... i assume this patch was lost. Should i resend it?
--
Regards,
Oleksij
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 05/10] arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
From: Simon Horman @ 2017-04-28 5:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jacopo Mondi, Linus Walleij, Geert Uytterhoeven, Laurent Pinchart,
Chris Brandt, Rob Herring, Mark Rutland, Russell King,
Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdWwT6et+vRzeY1GiGYW-hS4w4ukWK8bUL+w-npMmdPkag@mail.gmail.com>
On Thu, Apr 27, 2017 at 10:38:39AM +0200, Geert Uytterhoeven wrote:
> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:
> > Add dt-bindings for Renesas r7s72100 pin controller header file.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, I have queued this up.
^ permalink raw reply
* Re: [PATCH v5 07/10] arm: dts: genmai: Add SCIF2 pin group
From: Simon Horman @ 2017-04-28 5:21 UTC (permalink / raw)
To: Jacopo Mondi
Cc: linus.walleij, geert+renesas, laurent.pinchart, chris.brandt,
robh+dt, mark.rutland, linux, linux-renesas-soc, linux-gpio,
devicetree, linux-kernel
In-Reply-To: <1493281194-5200-8-git-send-email-jacopo+renesas@jmondi.org>
On Thu, Apr 27, 2017 at 10:19:51AM +0200, Jacopo Mondi wrote:
> Add pin configuration subnode for SCIF2 serial debug interface.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
As the dt-bindings (documentation) has been acked by Geert I'd be happy
to queue up this and other "arm: dts: genmai" DT patches in this series
which do not have any outstanding review comments. Is it safe to do so
without the PFC driver patches in place?
> ---
> arch/arm/boot/dts/r7s72100-genmai.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts b/arch/arm/boot/dts/r7s72100-genmai.dts
> index 118a8e2..c28d74b 100644
> --- a/arch/arm/boot/dts/r7s72100-genmai.dts
> +++ b/arch/arm/boot/dts/r7s72100-genmai.dts
> @@ -11,6 +11,7 @@
>
> /dts-v1/;
> #include "r7s72100.dtsi"
> +#include <dt-bindings/pinctrl/r7s72100-pinctrl.h>
>
> / {
> model = "Genmai";
> @@ -36,6 +37,14 @@
> };
> };
>
> +&pinctrl {
> +
> + scif2_pins: serial2 {
> + /* P3_0 as TxD2; P3_2 as RxD2 */
> + pinmux = <RZA1_PINMUX(3, 0, 6)>, <RZA1_PINMUX(3, 2, 4)>;
> + };
> +};
> +
> &extal_clk {
> clock-frequency = <13330000>;
> };
> @@ -60,6 +69,9 @@
> };
>
> &scif2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&scif2_pins>;
> +
> status = "okay";
> };
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group
From: Simon Horman @ 2017-04-28 5:22 UTC (permalink / raw)
To: Chris Brandt
Cc: Geert Uytterhoeven, Jacopo Mondi, Linus Walleij,
Geert Uytterhoeven, Laurent Pinchart, Rob Herring, Mark Rutland,
Russell King, Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <SG2PR06MB1165D46E83254B1757C790498A100@SG2PR06MB1165.apcprd06.prod.outlook.com>
On Thu, Apr 27, 2017 at 10:48:45AM +0000, Chris Brandt wrote:
> Hi Geert,
>
> On Thursday, April 27, 2017, Geert Uytterhoeven wrote:
> > > +ðer {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <ðer_pins>;
> > > +
> > > + status = "okay";
> > > +
> > > + renesas,no-ether-link;
> > > + phy-handle = <&phy0>;
> > > + phy0: ethernet-phy@0 {
> > > + reg = <0>;
> >
> > Shouldn't the interrupt (connected to P1_15) be described?
>
>
> That interrupt pin from the PHY is not used. It did not need to be connected.
So things are fine as above or should I expect to see v6?
^ permalink raw reply
* Re: [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller
From: Simon Horman @ 2017-04-28 5:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jacopo Mondi, Linus Walleij, Geert Uytterhoeven, Laurent Pinchart,
Chris Brandt, Rob Herring, Mark Rutland, Russell King,
Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdWw1JpFLT0QY4yQK6VH0oSeQOHUWMuKFSj6b6vrhHPCdA@mail.gmail.com>
On Thu, Apr 27, 2017 at 10:42:02AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:
> > this is 5th round of gpio/pincontroller for RZ/A1 devices.
> >
> > I have updated the pin controller driver to use the newly introduced
> > "pinctrl_enable()" function.
> > This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt,
> > the pin controller does not start.
> >
> > I have incorporated your comments on the device tree bindings documentation,
> > and added to pinctrl-generic.h header file two macros to unpack generic
> > properties and their arguments.
> >
> > Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.
>
> Thanks for the update!
>
> > Jacopo Mondi (10):
> > pinctrl: generic: Add bi-directional and output-enable
>
> Already applied by LinusW.
>
> > pinctrl: generic: Add macros to unpack properties
>
> LinusW: do you want me to queue this together with the driver for v4.13,
> or will you take this single patch for v4.12?
>
> > pinctrl: Renesas RZ/A1 pin and gpio controller
> > dt-bindings: pinctrl: Add RZ/A1 bindings doc
>
> Will queue in sh-pfc-for-v4.13.
>
> > arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
> > arm: dts: r7s72100: Add pin controller node
> > arm: dts: genmai: Add SCIF2 pin group
> > arm: dts: genmai: Add RIIC2 pin group
> > arm: dts: genmai: Add user led device nodes
> > arm: dts: genmai: Add ethernet pin group
>
> These are for Simon.
>
> Does applying the DTS changes before the driver introduce regressions?
> If no, Simon can queue them for v4.13.
> If yes, they'll have to wait for v4.14.
That is my question too.
^ permalink raw reply
* Re: [PATCH/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Simon Horman @ 2017-04-28 7:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Magnus Damm, Kuninori Morimoto,
Yoshihiro Shimoda, Rob Herring, Mark Rutland, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Vladimir Barinov
In-Reply-To: <CAMuHMdV1SQoeEACaNLZbByRLbosMj5oxEysNDVevYgxqStDaug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 27, 2017 at 03:32:49PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Wed, Apr 26, 2017 at 10:11 AM, Geert Uytterhoeven
> <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> > CC Vladimir (which I forgot to CC initially, sorry for that)
> >
> > On Wed, Apr 26, 2017 at 10:06 AM, Simon Horman <horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> >> On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
> >>> The Renesas Salvator-X and ULCB development board can be equipped with
> >>> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
> >>> use separate DTBs, but currently there's no sharing of board-specific
> >>> devices in DTS.
> >>>
> >>> This series reduces duplication by extracting common board support into
> >>> their own .dtsi files. As the level of support varies across boards and
> >>> SoCs, this requires the addition of a few external clocks and
> >>> placeholder devices on R-Car M3-W, so the common board support DTS can
> >>> refer to them.
> >>>
> >>> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
> >>> M3-W, which are present in r8a7795.dtsi, and used in
> >>> r8a7795-salvator-x.dts,
> >>> - RFC patch 3 adds placeholders for devices that are not yet supported
> >>> and/or tested on R-Car M3-W, but used on R-Car H3,
> >>> - RFC patch 4 extracts common Salvator-X board support,
> >>> - RFC patch 5 extracts common ULCB board support.
> >>>
> >>> For R-Car H3 based boards, there are no functional changes.
> >>> For R-Car M3-W based boards, some new devices are now described in DT.
> >>>
> >>> Dependencies:
> >>> - renesas-devel-20170420-v4.11-rc7,
> >>> - Patches 1 and 2 can be applied as-is,
> >>> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
> >>> out R-Car H3 and M3-W SiP"
> >>> (http://www.spinics.net/lists/devicetree/msg173820.html).
> >>>
> >>> DTB changes have been inspected using scripts/dtc/dtx_diff.
> >>> This has been tested on Salvator-X (both H3 and M3-W).
> >>> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
> >>>
> >>> Thanks for your comments!
> >>
> >> Thanks for tackling this important problem. I have looked over the changes
> >> and they seem nice to me. I would, however, be more comfortable applying
> >> them if they were rested on the ULCB boards.
> >
> > tested?
> >
> > I've pushed a branch for testing to topic/rcar3-dtsi-sharing in
> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
>
> I managed to test it on the new H3ULCB and M3ULCB baords in Magnus' farm.
> No issues detected.
Great! Any objections to me queuing this up?
--
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/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Geert Uytterhoeven @ 2017-04-28 7:11 UTC (permalink / raw)
To: Simon Horman
Cc: Geert Uytterhoeven, Magnus Damm, Kuninori Morimoto,
Yoshihiro Shimoda, Rob Herring, Mark Rutland, Linux-Renesas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Vladimir Barinov
In-Reply-To: <20170428070458.GB10196@verge.net.au>
Hi SImon,
On Fri, Apr 28, 2017 at 9:04 AM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Apr 27, 2017 at 03:32:49PM +0200, Geert Uytterhoeven wrote:
>> On Wed, Apr 26, 2017 at 10:11 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> > CC Vladimir (which I forgot to CC initially, sorry for that)
>> >
>> > On Wed, Apr 26, 2017 at 10:06 AM, Simon Horman <horms@verge.net.au> wrote:
>> >> On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
>> >>> The Renesas Salvator-X and ULCB development board can be equipped with
>> >>> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
>> >>> use separate DTBs, but currently there's no sharing of board-specific
>> >>> devices in DTS.
>> >>>
>> >>> This series reduces duplication by extracting common board support into
>> >>> their own .dtsi files. As the level of support varies across boards and
>> >>> SoCs, this requires the addition of a few external clocks and
>> >>> placeholder devices on R-Car M3-W, so the common board support DTS can
>> >>> refer to them.
>> >>>
>> >>> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
>> >>> M3-W, which are present in r8a7795.dtsi, and used in
>> >>> r8a7795-salvator-x.dts,
>> >>> - RFC patch 3 adds placeholders for devices that are not yet supported
>> >>> and/or tested on R-Car M3-W, but used on R-Car H3,
>> >>> - RFC patch 4 extracts common Salvator-X board support,
>> >>> - RFC patch 5 extracts common ULCB board support.
>> >>>
>> >>> For R-Car H3 based boards, there are no functional changes.
>> >>> For R-Car M3-W based boards, some new devices are now described in DT.
>> >>>
>> >>> Dependencies:
>> >>> - renesas-devel-20170420-v4.11-rc7,
>> >>> - Patches 1 and 2 can be applied as-is,
>> >>> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
>> >>> out R-Car H3 and M3-W SiP"
>> >>> (http://www.spinics.net/lists/devicetree/msg173820.html).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >>> DTB changes have been inspected using scripts/dtc/dtx_diff.
>> >>> This has been tested on Salvator-X (both H3 and M3-W).
>> >>> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
>> >>>
>> >>> Thanks for your comments!
>> >>
>> >> Thanks for tackling this important problem. I have looked over the changes
>> >> and they seem nice to me. I would, however, be more comfortable applying
>> >> them if they were rested on the ULCB boards.
>> >
>> > tested?
>> >
>> > I've pushed a branch for testing to topic/rcar3-dtsi-sharing in
>> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
>>
>> I managed to test it on the new H3ULCB and M3ULCB baords in Magnus' farm.
>> No issues detected.
>
> Great! Any objections to me queuing this up?
The dependency above (no feedback about the SiP types yet).
I can respin without that dependency, if that is preferred...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group
From: Geert Uytterhoeven @ 2017-04-28 7:18 UTC (permalink / raw)
To: Chris Brandt
Cc: Jacopo Mondi, Linus Walleij, Geert Uytterhoeven, Laurent Pinchart,
Rob Herring, Mark Rutland, Russell King, Linux-Renesas,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <SG2PR06MB1165D46E83254B1757C790498A100@SG2PR06MB1165.apcprd06.prod.outlook.com>
Hi Chris,
On Thu, Apr 27, 2017 at 12:48 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Thursday, April 27, 2017, Geert Uytterhoeven wrote:
>> > +ðer {
>> > + pinctrl-names = "default";
>> > + pinctrl-0 = <ðer_pins>;
>> > +
>> > + status = "okay";
>> > +
>> > + renesas,no-ether-link;
>> > + phy-handle = <&phy0>;
>> > + phy0: ethernet-phy@0 {
>> > + reg = <0>;
>>
>> Shouldn't the interrupt (connected to P1_15) be described?
>
> That interrupt pin from the PHY is not used. It did not need to be connected.
But it is connected, according to the schematics.
DT describes hardware, not software limitations.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [PATCH] arm64: dts: freescale: ls2081ardb: Add DTS support for NXP LS2081ARDB
From: Priyanka Jain @ 2017-04-28 7:20 UTC (permalink / raw)
To: Yang Li
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Mark Rutland, Shawn Guo,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Leo Li
In-Reply-To: <CADRPPNRM9Orc=RtRJstA-qpCcdCvrgab0n3d=CC7i6O7ua8nNg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 7895 bytes --]
> -----Original Message-----
> From: Yang Li [mailto:pku.leo@gmail.com]
> Sent: Monday, April 24, 2017 10:51 PM
> To: Priyanka Jain <priyanka.jain@nxp.com>
> Cc: devicetree@vger.kernel.org; Rob Herring <robh@kernel.org>; Mark Rutland
> <mark.rutland@arm.com>; Shawn Guo <shawnguo@kernel.org>; linux-arm-
> kernel@lists.infradead.org; Leo Li <leoyang.li@nxp.com>
> Subject: Re: [PATCH] arm64: dts: freescale: ls2081ardb: Add DTS support for NXP
> LS2081ARDB
>
> We probably should rename the freescale folder to nxp with a separate patch,
> but it is better to stop using the name in the patch title right now.
>
OK, I will correct this
> On Wed, Apr 19, 2017 at 11:37 PM, Priyanka Jain <priyanka.jain@nxp.com>
> wrote:
> > This patch add support for NXP LS2081ARDB board which has LS2081A SoC.
> >
> > LS2081A SoC is 40-pin derivative of LS2088A SoC So, from functional
> > perspective both are same.
> > Hence,ls2088a SoC dtsi files are included from ls2081ARDB dts
> >
> > Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> > ---
> > arch/arm64/boot/dts/freescale/Makefile | 1 +
> > arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts | 139
> > +++++++++++++++++++++
> > 2 files changed, 140 insertions(+), 0 deletions(-) create mode
> > 100755 arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
> >
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile
> > b/arch/arm64/boot/dts/freescale/Makefile
> > index 72c4b52..58b80de 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-qds.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-rdb.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-qds.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
> > +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2081a-rdb.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
> > dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb diff --git
> > a/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
> > new file mode 100444
> > index 0000000..7ae408e
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls2081a-rdb.dts
> > @@ -0,0 +1,139 @@
> > +/*
> > + * Device Tree file for NXP LS2081A RDB Board.
> > + *
> > + * Copyright (C) 2017, NXP Semiconductors
>
> The formal copyright claim formal should be Copyright 2017 NXP
>
OK, I will correct this
Priyanka
> > + *
> > + * Priyanka Jain <priyanka.jain@nxp.com>
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPLv2 or the X11 license, at your option. Note that this
> > + dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + * a) This library is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of the
> > + * License, or (at your option) any later version.
> > + *
> > + * This library is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * Or, alternatively,
> > + *
> > + * b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated documentation
> > + * files (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use,
> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following
> > + * conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > + * included in all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND,
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
> WARRANTIES
> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
> COPYRIGHT
> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
> OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "fsl-ls2088a.dtsi"
> > +
> > +/ {
> > + model = "NXP Layerscape 2081A RDB Board";
> > + compatible = "fsl,ls2081a-rdb", "fsl,ls2081a";
> > +
> > + aliases {
> > + serial0 = &serial0;
> > + serial1 = &serial1;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial1:115200n8";
> > + };
> > +};
> > +
> > +&esdhc {
> > + status = "okay";
> > +};
> > +
> > +&ifc {
> > + status = "disabled";
> > +};
> > +
> > +&i2c0 {
> > + status = "okay";
> > + pca9547@75 {
> > + compatible = "nxp,pca9547";
> > + reg = <0x75>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + i2c@1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x01>;
> > + rtc@51 {
> > + compatible = "nxp,pcf2129";
> > + reg = <0x51>;
> > + };
> > + };
> > +
> > + i2c@3 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x3>;
> > +
> > + adt7481@4c {
> > + compatible = "adi,adt7461";
> > + reg = <0x4c>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&dspi {
> > + status = "okay";
> > + dflash0: n25q512a {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "st,m25p80";
> > + spi-max-frequency = <3000000>;
> > + reg = <0>;
> > + };
> > +};
> > +
> > +
> > +&qspi {
> > + status = "okay";
> > + flash0: n25q512a@0 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "st,m25p80";
> > + spi-max-frequency = <20000000>;
> > + reg = <0>;
> > + };
> > + flash1: n25q512a@1 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "st,m25p80";
> > + spi-max-frequency = <20000000>;
> > + reg = <0>;
> > + };
> > +};
> > +
> > +&usb0 {
> > + status = "okay";
> > +};
> > +
> > +&usb1 {
> > + status = "okay";
> > +};
> > --
> > 1.7.4.1
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree"
> > in the body of a message to majordomo@vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> - Leo
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
* Re: [PATCH] ARM: dts: r7s72100: add usb clocks to device tree
From: Simon Horman @ 2017-04-28 7:24 UTC (permalink / raw)
To: Chris Brandt
Cc: Geert Uytterhoeven, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170427191045.21199-1-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Thu, Apr 27, 2017 at 12:10:45PM -0700, Chris Brandt wrote:
> 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(-)
Hi Chris,
could you break the .h patch out into a separate patch so that I can apply
it to my dt-bindings branch? The reason for that branch is to allow better
management of dependencies; something I got burnt by a few releases back.
>
> 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";
The above looks fine to me although I was unable to find the USB parent
clock in the documentation I have available.
> };
>
> 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
The above also looks fine to me.
--
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 00/10] Renesas RZ/A1 pin and gpio controller
From: jmondi @ 2017-04-28 7:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jacopo Mondi, Linus Walleij, Geert Uytterhoeven, Laurent Pinchart,
Chris Brandt, Rob Herring, Mark Rutland, Russell King,
Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdWw1JpFLT0QY4yQK6VH0oSeQOHUWMuKFSj6b6vrhHPCdA@mail.gmail.com>
Hi Geert, Simon,
On Thu, Apr 27, 2017 at 10:42:02AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:
> > this is 5th round of gpio/pincontroller for RZ/A1 devices.
> >
> > I have updated the pin controller driver to use the newly introduced
> > "pinctrl_enable()" function.
> > This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt,
> > the pin controller does not start.
> >
> > I have incorporated your comments on the device tree bindings documentation,
> > and added to pinctrl-generic.h header file two macros to unpack generic
> > properties and their arguments.
> >
> > Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.
>
> Thanks for the update!
>
> > Jacopo Mondi (10):
> > pinctrl: generic: Add bi-directional and output-enable
>
> Already applied by LinusW.
>
> > pinctrl: generic: Add macros to unpack properties
>
> LinusW: do you want me to queue this together with the driver for v4.13,
> or will you take this single patch for v4.12?
>
> > pinctrl: Renesas RZ/A1 pin and gpio controller
> > dt-bindings: pinctrl: Add RZ/A1 bindings doc
>
> Will queue in sh-pfc-for-v4.13.
>
> > arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
> > arm: dts: r7s72100: Add pin controller node
> > arm: dts: genmai: Add SCIF2 pin group
> > arm: dts: genmai: Add RIIC2 pin group
> > arm: dts: genmai: Add user led device nodes
> > arm: dts: genmai: Add ethernet pin group
>
> These are for Simon.
>
> Does applying the DTS changes before the driver introduce regressions?
> If no, Simon can queue them for v4.13.
> If yes, they'll have to wait for v4.14.
>
I tried reverting patch [03/10] which introduces the driver, and I
lose serial output on Genmai. So I guess the dts patches have to be
taken after the driver has been merged.
One question: why can't they be taken at the same time? (eg. for
v4.13?)
Thanks
j
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller
From: Geert Uytterhoeven @ 2017-04-28 7:30 UTC (permalink / raw)
To: jmondi
Cc: Jacopo Mondi, Linus Walleij, Geert Uytterhoeven, Laurent Pinchart,
Chris Brandt, Rob Herring, Mark Rutland, Russell King,
Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20170428072457.GA4911@w540>
Hi Jacopo,
On Fri, Apr 28, 2017 at 9:24 AM, jmondi <jacopo@jmondi.org> wrote:
> On Thu, Apr 27, 2017 at 10:42:02AM +0200, Geert Uytterhoeven wrote:
>> On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
>> <jacopo+renesas@jmondi.org> wrote:
>> > this is 5th round of gpio/pincontroller for RZ/A1 devices.
>> >
>> > I have updated the pin controller driver to use the newly introduced
>> > "pinctrl_enable()" function.
>> > This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt,
>> > the pin controller does not start.
>> >
>> > I have incorporated your comments on the device tree bindings documentation,
>> > and added to pinctrl-generic.h header file two macros to unpack generic
>> > properties and their arguments.
>> >
>> > Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.
>>
>> Thanks for the update!
>>
>> > Jacopo Mondi (10):
>> > pinctrl: generic: Add bi-directional and output-enable
>>
>> Already applied by LinusW.
>>
>> > pinctrl: generic: Add macros to unpack properties
>>
>> LinusW: do you want me to queue this together with the driver for v4.13,
>> or will you take this single patch for v4.12?
>>
>> > pinctrl: Renesas RZ/A1 pin and gpio controller
>> > dt-bindings: pinctrl: Add RZ/A1 bindings doc
>>
>> Will queue in sh-pfc-for-v4.13.
>>
>> > arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
>> > arm: dts: r7s72100: Add pin controller node
>> > arm: dts: genmai: Add SCIF2 pin group
>> > arm: dts: genmai: Add RIIC2 pin group
>> > arm: dts: genmai: Add user led device nodes
>> > arm: dts: genmai: Add ethernet pin group
>>
>> These are for Simon.
>>
>> Does applying the DTS changes before the driver introduce regressions?
>> If no, Simon can queue them for v4.13.
>> If yes, they'll have to wait for v4.14.
>>
>
> I tried reverting patch [03/10] which introduces the driver, and I
> lose serial output on Genmai. So I guess the dts patches have to be
> taken after the driver has been merged.
>
> One question: why can't they be taken at the same time? (eg. for
> v4.13?)
Because the driver goes in through me and LinusW, while the DTS goes in
through Simon and arm-soc.
If Simon applies the DTS patches, it will regress genmai in renesas-devel
until the release of v4.13-rc1.
An immutable branch would solve that, but for adding PFC we usuable just
postpone the DT part by one cycle.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller
From: Simon Horman @ 2017-04-28 7:31 UTC (permalink / raw)
To: jmondi
Cc: Geert Uytterhoeven, Jacopo Mondi, Linus Walleij,
Geert Uytterhoeven, Laurent Pinchart, Chris Brandt, Rob Herring,
Mark Rutland, Russell King, Linux-Renesas,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20170428072457.GA4911@w540>
On Fri, Apr 28, 2017 at 09:24:57AM +0200, jmondi wrote:
> Hi Geert, Simon,
>
> On Thu, Apr 27, 2017 at 10:42:02AM +0200, Geert Uytterhoeven wrote:
> > Hi Jacopo,
> >
> > On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi
> > <jacopo+renesas@jmondi.org> wrote:
> > > this is 5th round of gpio/pincontroller for RZ/A1 devices.
> > >
> > > I have updated the pin controller driver to use the newly introduced
> > > "pinctrl_enable()" function.
> > > This is required since v4.11-rc7 as otherwise, as reported by Chris Brandt,
> > > the pin controller does not start.
> > >
> > > I have incorporated your comments on the device tree bindings documentation,
> > > and added to pinctrl-generic.h header file two macros to unpack generic
> > > properties and their arguments.
> > >
> > > Tested with SCIF, RIIC, ETHER and gpio-leds on Genmai board.
> >
> > Thanks for the update!
> >
> > > Jacopo Mondi (10):
> > > pinctrl: generic: Add bi-directional and output-enable
> >
> > Already applied by LinusW.
> >
> > > pinctrl: generic: Add macros to unpack properties
> >
> > LinusW: do you want me to queue this together with the driver for v4.13,
> > or will you take this single patch for v4.12?
> >
> > > pinctrl: Renesas RZ/A1 pin and gpio controller
> > > dt-bindings: pinctrl: Add RZ/A1 bindings doc
> >
> > Will queue in sh-pfc-for-v4.13.
> >
> > > arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header
> > > arm: dts: r7s72100: Add pin controller node
> > > arm: dts: genmai: Add SCIF2 pin group
> > > arm: dts: genmai: Add RIIC2 pin group
> > > arm: dts: genmai: Add user led device nodes
> > > arm: dts: genmai: Add ethernet pin group
> >
> > These are for Simon.
> >
> > Does applying the DTS changes before the driver introduce regressions?
> > If no, Simon can queue them for v4.13.
> > If yes, they'll have to wait for v4.14.
> >
>
> I tried reverting patch [03/10] which introduces the driver, and I
> lose serial output on Genmai. So I guess the dts patches have to be
> taken after the driver has been merged.
>
> One question: why can't they be taken at the same time? (eg. for
> v4.13?)
The problem is that the changes go through different trees. It may,
however, be possible to arrange for both sets of changes to go into v4.13
by negotiating with the ARM-SoC maintainers.
^ permalink raw reply
* Re: [PATCH/RFC 0/5] arm64: dts: renesas: Break out common board support
From: Simon Horman @ 2017-04-28 7:32 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Geert Uytterhoeven, Magnus Damm, Kuninori Morimoto,
Yoshihiro Shimoda, Rob Herring, Mark Rutland, Linux-Renesas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Vladimir Barinov
In-Reply-To: <CAMuHMdVypXM59rk50Guc90ktD2PKHsVHgXyN34Cz3EC1hMTs8g@mail.gmail.com>
On Fri, Apr 28, 2017 at 09:11:36AM +0200, Geert Uytterhoeven wrote:
> Hi SImon,
>
> On Fri, Apr 28, 2017 at 9:04 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, Apr 27, 2017 at 03:32:49PM +0200, Geert Uytterhoeven wrote:
> >> On Wed, Apr 26, 2017 at 10:11 AM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >> > CC Vladimir (which I forgot to CC initially, sorry for that)
> >> >
> >> > On Wed, Apr 26, 2017 at 10:06 AM, Simon Horman <horms@verge.net.au> wrote:
> >> >> On Fri, Apr 21, 2017 at 02:55:16PM +0200, Geert Uytterhoeven wrote:
> >> >>> The Renesas Salvator-X and ULCB development board can be equipped with
> >> >>> either an R-Car H3 or M3-W SiP, which are pin-compatible. All boards
> >> >>> use separate DTBs, but currently there's no sharing of board-specific
> >> >>> devices in DTS.
> >> >>>
> >> >>> This series reduces duplication by extracting common board support into
> >> >>> their own .dtsi files. As the level of support varies across boards and
> >> >>> SoCs, this requires the addition of a few external clocks and
> >> >>> placeholder devices on R-Car M3-W, so the common board support DTS can
> >> >>> refer to them.
> >> >>>
> >> >>> - Patches 1 and 2 add the external audio and PCIe bus clocks on R-Car
> >> >>> M3-W, which are present in r8a7795.dtsi, and used in
> >> >>> r8a7795-salvator-x.dts,
> >> >>> - RFC patch 3 adds placeholders for devices that are not yet supported
> >> >>> and/or tested on R-Car M3-W, but used on R-Car H3,
> >> >>> - RFC patch 4 extracts common Salvator-X board support,
> >> >>> - RFC patch 5 extracts common ULCB board support.
> >> >>>
> >> >>> For R-Car H3 based boards, there are no functional changes.
> >> >>> For R-Car M3-W based boards, some new devices are now described in DT.
> >> >>>
> >> >>> Dependencies:
> >> >>> - renesas-devel-20170420-v4.11-rc7,
> >> >>> - Patches 1 and 2 can be applied as-is,
> >> >>> - Patches 4 and 5 depend on "[PATCH 0/8] arm64: dts: renesas: Break
> >> >>> out R-Car H3 and M3-W SiP"
> >> >>> (http://www.spinics.net/lists/devicetree/msg173820.html).
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> >> >>> DTB changes have been inspected using scripts/dtc/dtx_diff.
> >> >>> This has been tested on Salvator-X (both H3 and M3-W).
> >> >>> This has not been tested on H3ULCB and M3ULCB due to lack of hardware.
> >> >>>
> >> >>> Thanks for your comments!
> >> >>
> >> >> Thanks for tackling this important problem. I have looked over the changes
> >> >> and they seem nice to me. I would, however, be more comfortable applying
> >> >> them if they were rested on the ULCB boards.
> >> >
> >> > tested?
> >> >
> >> > I've pushed a branch for testing to topic/rcar3-dtsi-sharing in
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
> >>
> >> I managed to test it on the new H3ULCB and M3ULCB baords in Magnus' farm.
> >> No issues detected.
> >
> > Great! Any objections to me queuing this up?
>
> The dependency above (no feedback about the SiP types yet).
>
> I can respin without that dependency, if that is preferred...
It seems to me that it would be nice to get these in sooner than later - in
particular earlier rather than later in the (v4.13) development cycle. But
I defer to your judgement on what is best.
^ permalink raw reply
* Re: [PATCH] ARM: dts: r7s72100: add usb clocks to device tree
From: Geert Uytterhoeven @ 2017-04-28 7:34 UTC (permalink / raw)
To: Chris Brandt
Cc: Simon Horman, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <20170427191045.21199-1-chris.brandt@renesas.com>
On Thu, Apr 27, 2017 at 9:10 PM, Chris Brandt <chris.brandt@renesas.com> wrote:
> This adds the USB0 and USB1 clocks to the device tree.
>
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Simon: see Section 29.3.2 (BUSWAIT) for the reference to the P1 clock.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 10/18] pinctrl: madera: Add driver for Cirrus Logic Madera codecs
From: Linus Walleij @ 2017-04-28 7:39 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: Alexandre Courbot, alsa-devel@alsa-project.org, Jason Cooper,
devicetree@vger.kernel.org,
open list:WOLFSON MICROELECTRONICS DRIVERS,
linux-kernel@vger.kernel.org, Rob Herring,
linux-gpio@vger.kernel.org, Mark Brown, Thomas Gleixner,
Lee Jones
In-Reply-To: <1493050124-5970-11-git-send-email-rf@opensource.wolfsonmicro.com>
On Mon, Apr 24, 2017 at 6:08 PM, Richard Fitzgerald
<rf@opensource.wolfsonmicro.com> wrote:
> These codecs have a variable number of I/O lines each of which
> is individually selectable to a wide range of possible functions.
>
> The functionality is slightly different from the traditional muxed
> GPIO since most of the functions can be mapped to any pin (and even
> the same function to multiple pins). Most pins have a dedicated
> "alternate" function that is only available on that pin. The
> alternate functions are usually a group of signals, though it is
> not always necessary to enable the full group, depending on the
> alternate function and how it is to be used. The mapping between
> alternate functions and GPIO pins varies between codecs depending
> on the number of alternate functions and available pins.
>
> Note on the Kconfig options:
> The formula "default y if..." is used for PINCTRL_MADERA so that its
> select options will be processed, allowing us to group selects for
> pinctrl into the pinctrl Kconfig where they logically belong instead
> of accumulating under the parent MFD Kconfig.
>
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> ---
> Changes since V1:
> - dt binding moved to separate patch
> - moved all source into a subdirectory drivers/pinctrl/cirrus
> - split chip-specific tables into separate files
> - codec-specific build options are now selected from MFD
> - print useful information from madera_pin_dbg_show()
> - added gpio_set_direciton / gpio_request_enable / gpio_disable_free functions
> - added strict mode so GPIO and other functions are exclusive
> - replace #ifdefs with if (IS_ENABLED(...)) in probe
> - fixed bug reading registers in madera_pin_conf_get()
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
I guess you will apply this through MFD, so waiting for Lee to
pick it up. Alternatively I can apply it after the MFD core parts
are upstream.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 12/18] gpio: madera: Support Cirrus Logic Madera class codecs
From: Linus Walleij @ 2017-04-28 7:44 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: Alexandre Courbot, alsa-devel@alsa-project.org, Jason Cooper,
devicetree@vger.kernel.org,
open list:WOLFSON MICROELECTRONICS DRIVERS,
linux-kernel@vger.kernel.org, Rob Herring,
linux-gpio@vger.kernel.org, Mark Brown, Thomas Gleixner,
Lee Jones
In-Reply-To: <1493050124-5970-13-git-send-email-rf@opensource.wolfsonmicro.com>
On Mon, Apr 24, 2017 at 6:08 PM, Richard Fitzgerald
<rf@opensource.wolfsonmicro.com> wrote:
> This adds support for the GPIOs on Cirrus Logic Madera class codecs.
> Any pins not used for special functions (see the pinctrl driver) can be
> used as general single-bit input or output lines. The number of available
> GPIOs varies between codecs.
>
> Signed-off-by: Nariman Poushin <nariman@opensource.wolfsonmicro.com>
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> ---
> Changes from V1:
> - dt bindings moved to a separate patch
> - dependent on pinctrl driver instead of parent MFD
> - added get_direction function
> - added .request / .free / .set_config to work with pinctrl driver
> - register range with pinctrl driver
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ 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