* Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Andrew Lunn @ 2016-11-16 15:06 UTC (permalink / raw)
To: Jerome Brunet
Cc: Florian Fainelli, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Carlo Caione, Kevin Hilman,
Giuseppe Cavallaro, Alexandre TORGUE, Martin Blumenstingl,
Andre Roth, Neil Armstrong,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479307890.17538.40.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Wed, Nov 16, 2016 at 03:51:30PM +0100, Jerome Brunet wrote:
> On Wed, 2016-11-16 at 14:23 +0100, Andrew Lunn wrote:
> > >
> > > There two kind of PHYs supporting eee, the one advertising eee by
> > > default (like realtek) and the one not advertising it (like
> > > micrel).
>
> This is just the default register value.
>
> >
> > I don't know too much about EEE. So maybe a dumb question. Does the
> > MAC need to be involved? Or is it just the PHY?
> >
> > If the MAC needs to be involved, the PHY should not be advertising
> > EEE
> > unless the MAC asks for it by calling phy_init_eee(). If this is
> > true,
> > maybe we need to change the realtek driver, and others in that class.
>
> As far I understand, the advertised capabilities are exchanged during
> the auto-negotiation.
>
> At this stage, if the advertisement is disabled (regarless of the
> actual support) on either side of the link, there will be no low power
> idle state on the Tx nor the Rx path.
>
> If the advertisement is enabled on both side but we don't call
> phy_init_eee, I suppose Tx won't enter LPI, but Rx could.
What i was trying to find out is, if the MAC needs to support EEE as
well as the PHY, what happens when the MAC does not support EEE, but
the PHYs do negotiate EEE? Does it break?
Andrew
--
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 net 1/3] net: phy: realtek: add eee advertisement disable options
From: Jerome Brunet @ 2016-11-16 14:51 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Carlo Caione, Kevin Hilman,
Giuseppe Cavallaro, Alexandre TORGUE, Martin Blumenstingl,
Andre Roth, Neil Armstrong,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161116132337.GD19962-g2DYL2Zd6BY@public.gmane.org>
On Wed, 2016-11-16 at 14:23 +0100, Andrew Lunn wrote:
> >
> > There two kind of PHYs supporting eee, the one advertising eee by
> > default (like realtek) and the one not advertising it (like
> > micrel).
This is just the default register value.
>
> I don't know too much about EEE. So maybe a dumb question. Does the
> MAC need to be involved? Or is it just the PHY?
>
> If the MAC needs to be involved, the PHY should not be advertising
> EEE
> unless the MAC asks for it by calling phy_init_eee(). If this is
> true,
> maybe we need to change the realtek driver, and others in that class.
As far I understand, the advertised capabilities are exchanged during
the auto-negotiation.
At this stage, if the advertisement is disabled (regarless of the
actual support) on either side of the link, there will be no low power
idle state on the Tx nor the Rx path.
If the advertisement is enabled on both side but we don't call
phy_init_eee, I suppose Tx won't enter LPI, but Rx could.
>
> Andrew
--
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: specifying order of /dev/mmcblk devices via device-tree?
From: Ulf Hansson @ 2016-11-16 14:45 UTC (permalink / raw)
To: Mark Rutland
Cc: Tim Harvey, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20161028153755.GL5806@leverpostej>
On 28 October 2016 at 17:37, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote:
>> Greetings,
>>
>> I have an IMX6 board that has the following:
>> sdhc1: mmc0: sdio radio
>> sdhc2: mmc1: /dev/mmcblk1: microSD connector
>> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
>>
>> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
>> registered as /dev/mmcblk1 so that permanent storage is the first
>> mmcblk device as I think this is more intuitive however currently
>> these get instanced in the order they appear in the imx6qdl.dtsi
>> device-tree configuration and are not able to be mapped the way I want
>> them in my dts file.
>>
>> Is there a way, or if not is there a desire for a way, to specify the
>> order of /dev/mmcblk devices via device-tree?
>
> As with many other devices, there is no standard way of controlling the
> Linux enumeration (and given the ID space is shared with other dynamic
> devices it's not something that could generally work).
>
> These should be refererd to by UUID if possible.
>
> If not, we could cosider adding a by-dt-path or something like that.
So does that mean you think using "DT aliases" would be okay? As
Javier pointed out, there have been some attempts [1] for that, but
they didn't make it.
Perhaps we need to re-consider, and if so please re-review the DT
bindings patch from that series.
Kind regards
Uffe
[1]
https://lkml.org/lkml/2016/4/29/610 or
http://www.spinics.net/lists/linux-mmc/msg36701.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
From: Jyri Sarha @ 2016-11-16 14:39 UTC (permalink / raw)
To: Rob Herring
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, airlied-cv59FeDIM0c,
daniel-/w4YWyX8dFk, tomi.valkeinen-l0cyMroinI0,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
robdclark-Re5JQEeQqe8AvxtiuMwx3w,
bgolaszewski-rdvid1DuHRBWk0Htik3J/w,
khilman-rdvid1DuHRBWk0Htik3J/w, bcousson-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <20161116133331.miem6us563uu62t7@rob-hp-laptop>
On 11/16/16 15:33, Rob Herring wrote:
>> +Optional properties
>> > + - reg: I2C address. If and only if present the driver node
>> > + should be placed into the i2c controller node where the
>> > + tfp410 i2c is connected to (the current implementation does
>> > + not yet support this).
> So this chip can work without programming I guess?
>
Yes. Just powering it up is enough for most application.
> reg should only be not present if I2C is not connected in the design. It
> can't be a function of what the driver supports. In otherwords, you
> can't be moving this node around based on when you add I2C control.
>
Ok, I'll try to implement a dummy i2c driver at the same time too. I can
not test anything related to it because I do not have a piece of HW with
tfp410 i2c wires connected, but it should not matter as long as I am
able to probe it as a i2c client.
Thanks,
Jyri
--
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] net: ethernet: faraday: To support device tree usage.
From: Andrew Lunn @ 2016-11-16 14:37 UTC (permalink / raw)
To: Greentime Hu; +Cc: netdev, devicetree
In-Reply-To: <CAEbi=3esyRi4cnUNf4uPKCQtyRekBRo81Frd=BSJy8qf=3uc+A@mail.gmail.com>
On Wed, Nov 16, 2016 at 10:26:52PM +0800, Greentime Hu wrote:
> On Wed, Nov 16, 2016 at 9:47 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Wed, Nov 16, 2016 at 04:43:15PM +0800, Greentime Hu wrote:
> >> To support device tree usage for ftmac100.
> >>
> >> Signed-off-by: Greentime Hu <green.hu@gmail.com>
> >> ---
> >> drivers/net/ethernet/faraday/ftmac100.c | 7 +++++++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/drivers/net/ethernet/faraday/ftmac100.c b/drivers/net/ethernet/faraday/ftmac100.c
> >> index dce5f7b..81dd9e1 100644
> >> --- a/drivers/net/ethernet/faraday/ftmac100.c
> >> +++ b/drivers/net/ethernet/faraday/ftmac100.c
> >> @@ -1172,11 +1172,17 @@ static int __exit ftmac100_remove(struct platform_device *pdev)
> >> return 0;
> >> }
> >>
> >> +static const struct of_device_id mac_of_ids[] = {
> >> + { .compatible = "andestech,atmac100" },
> >> + { }
> >
> > andestech is not in
> > Documentation/devicetree/bindings/vendor-prefixes.txt Please provide a
> > separate patch adding it.
> OK. I will provide another patch to add andestech.
>
> > Humm, why andestech? Why not something based around faraday
> > technology?
> It is because we use the same ftmac100 IP provided from faraday
> technology but I am now using it in andestech SoC.
Please make sure you get an acked-by: from the device tree
maintainers. They might want you to use faraday, since that is the
original IP provider. For example, all Synopsys licensed IP uses
"snps,XXX", not the SoC vendor with the license.
Andrew
^ permalink raw reply
* Re: [PATCH v2 1/3] remoteproc: qcom: Encapsulate pvt data structure for q6v56 hexagon.
From: Avaneesh Kumar Dwivedi @ 2016-11-16 14:02 UTC (permalink / raw)
To: Rob Herring
Cc: bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A, Ohad Ben-Cohen,
Mark Rutland, open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20161110203013.fphvzd4df3zvjdfi@rob-hp-laptop>
On 11/11/2016 2:00 AM, Rob Herring wrote:
> On Fri, Nov 04, 2016 at 07:30:54PM +0530, Avaneesh Kumar Dwivedi wrote:
>> Encapsulate resources specific to each version of hexagon chip to
>> device node to avoid conditional check for manipulation of those
>> resources in driver code.
>>
>> Signed-off-by: Avaneesh Kumar Dwivedi <akdwived-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>> .../devicetree/bindings/remoteproc/qcom,q6v5.txt | 1 +
>> drivers/remoteproc/qcom_q6v5_pil.c | 137 ++++++++++++++++++---
>> 2 files changed, 120 insertions(+), 18 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
>> index 57cb49e..cbc165c 100644
>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
>> @@ -8,6 +8,7 @@ on the Qualcomm Hexagon core.
>> Value type: <string>
>> Definition: must be one of:
>> "qcom,q6v5-pil"
>> + "qcom,q6v56-pil"
> Perhaps some explanation in the commit message about what these magic
> numbers mean?
"v56" represent class of hexagon chip, which again is
differentiated based on version number. Two
different MSM SOC may use same class of hexagon chip. example is as
below.
msm8974 q6v5 version 5.0.0
msm8916 q6v5 version 5.1.1
>
> 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
* [PATCH 4/4] Update device tree Synopsys DW DMAC documentation
From: Eugeniy Paltsev @ 2016-11-16 13:56 UTC (permalink / raw)
To: devicetree
Cc: robh+dt, mark.rutland, linux-kernel, andriy.shevchenko, vireshk,
dan.j.williams, vinod.koul, dmaengine, linux-snps-arc,
Eugeniy Paltsev
In-Reply-To: <1479304615-11360-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
* Rename is_private to is-private as ordered by DT policy.
The change leaves the support for the old format.
* Add is-memcpu property, so it is possible to
enable memory-to-memory transfers support via DT.
* Add hw-llp property, so it is possible to enable
hardware multi block transfers support via DT.
Fix white spaces.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
Documentation/devicetree/bindings/dma/snps-dma.txt | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 0f55832..d41d960 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -20,13 +20,19 @@ Required properties:
Deprecated properties:
- data_width: Maximum data width supported by hardware per AHB master
(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
+- is_private: The device channels should be marked as private and not for by the
+ general purpose DMA channel allocator. False if not passed.
Optional properties:
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
-- is_private: The device channels should be marked as private and not for by the
+- is-private: The device channels should be marked as private and not for by the
general purpose DMA channel allocator. False if not passed.
+- is-memcpu: The device channels do support memory-to-memory transfers. False
+ if not passed.
+- hw-llp: Multi block transfers supported by hardware per AHB master.
+ 0 (default): not supported, 1: supported.
Example:
@@ -56,7 +62,7 @@ The four cells in order are:
4. Peripheral master for transfers on allocated channel
Example:
-
+
serial@e0000000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0xe0000000 0x1000>;
--
2.5.5
^ permalink raw reply related
* [PATCH 3/4] DW DMAC: add hw-llp property to device tree
From: Eugeniy Paltsev @ 2016-11-16 13:56 UTC (permalink / raw)
To: devicetree
Cc: robh+dt, mark.rutland, linux-kernel, andriy.shevchenko, vireshk,
dan.j.williams, vinod.koul, dmaengine, linux-snps-arc,
Eugeniy Paltsev
In-Reply-To: <1479304615-11360-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Several versions of DW DMAC have multi block transfers hardware
support. Hardware support of multi block transfers is disabled
by default if we use DT to configure DMAC and software emulation
of multi block transfers used instead.
Add hw-llp property, so it is possible to enable hardware
multi block transfers (if present) via DT.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 5 +++++
include/linux/platform_data/dma-dw.h | 4 ++--
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index c2c0a61..e3ff4ea 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1569,7 +1569,7 @@ int dw_dma_probe(struct dw_dma_chip *chip)
(dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0;
} else {
dwc->block_size = pdata->block_size;
- dwc->nollp = pdata->is_nollp;
+ dwc->nollp = pdata->hw_llp[i];
}
}
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index daeceac..2722e60 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -151,6 +151,11 @@ dw_dma_parse_dt(struct platform_device *pdev)
pdata->data_width[tmp] = BIT(arr[tmp] & 0x07);
}
+ if (!of_property_read_u32_array(np, "hw-llp", arr, nr_masters)) {
+ for (tmp = 0; tmp < nr_masters; tmp++)
+ pdata->hw_llp[tmp] = arr[tmp];
+ }
+
return pdata;
}
#else
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index 5f0e11e..5bc8124 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -40,19 +40,18 @@ struct dw_dma_slave {
* @is_private: The device channels should be marked as private and not for
* by the general purpose DMA channel allocator.
* @is_memcpy: The device channels do support memory-to-memory transfers.
- * @is_nollp: The device channels does not support multi block transfers.
* @chan_allocation_order: Allocate channels starting from 0 or 7
* @chan_priority: Set channel priority increasing from 0 to 7 or 7 to 0.
* @block_size: Maximum block size supported by the controller
* @nr_masters: Number of AHB masters supported by the controller
* @data_width: Maximum data width supported by hardware per AHB master
* (in bytes, power of 2)
+ * @hw_llp: Multi block transfers supported by hardware per AHB master.
*/
struct dw_dma_platform_data {
unsigned int nr_channels;
bool is_private;
bool is_memcpy;
- bool is_nollp;
#define CHAN_ALLOCATION_ASCENDING 0 /* zero to seven */
#define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero */
unsigned char chan_allocation_order;
@@ -62,6 +61,7 @@ struct dw_dma_platform_data {
unsigned int block_size;
unsigned char nr_masters;
unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
+ unsigned char hw_llp[DW_DMA_MAX_NR_MASTERS];
};
#endif /* _PLATFORM_DATA_DMA_DW_H */
--
2.5.5
^ permalink raw reply related
* [PATCH 2/4] DW DMAC: add is-memcpu property to device tree
From: Eugeniy Paltsev @ 2016-11-16 13:56 UTC (permalink / raw)
To: devicetree
Cc: robh+dt, mark.rutland, linux-kernel, andriy.shevchenko, vireshk,
dan.j.williams, vinod.koul, dmaengine, linux-snps-arc,
Eugeniy Paltsev
In-Reply-To: <1479304615-11360-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Memory-to-memory dma transfers were disabled by default if we
used DT to cofigure DMAC.
Add is-memcpu property, so it became possible to enable
memory-to-memory transfers support via DT.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
drivers/dma/dw/platform.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 4103f1d..daeceac 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -131,6 +131,9 @@ dw_dma_parse_dt(struct platform_device *pdev)
else if (of_property_read_bool(np, "is-private"))
pdata->is_private = true;
+ if (of_property_read_bool(np, "is-memcpu"))
+ pdata->is_memcpy = true;
+
if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
pdata->chan_allocation_order = (unsigned char)tmp;
--
2.5.5
^ permalink raw reply related
* [PATCH 1/4] DW DMAC: rename is_private property as ordered by DT policy
From: Eugeniy Paltsev @ 2016-11-16 13:56 UTC (permalink / raw)
To: devicetree
Cc: robh+dt, mark.rutland, linux-kernel, andriy.shevchenko, vireshk,
dan.j.williams, vinod.koul, dmaengine, linux-snps-arc,
Eugeniy Paltsev
In-Reply-To: <1479304615-11360-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Rename is_private to is-private as ordered by DT policy.
The change leaves the support for the old format.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
drivers/dma/dw/platform.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 5bda0eb..4103f1d 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -128,6 +128,8 @@ dw_dma_parse_dt(struct platform_device *pdev)
if (of_property_read_bool(np, "is_private"))
pdata->is_private = true;
+ else if (of_property_read_bool(np, "is-private"))
+ pdata->is_private = true;
if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
pdata->chan_allocation_order = (unsigned char)tmp;
--
2.5.5
^ permalink raw reply related
* [PATCH 0/4] DW DMAC: update device tree
From: Eugeniy Paltsev @ 2016-11-16 13:56 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Eugeniy Paltsev
It wasn't possible to enable some features like
memory-to-memory transfers or multi block transfers via DT.
It is fixed by these patches.
* Rename is_private to is-private as ordered by DT policy.
(just for cleanup) The change leaves the support for the
old format.
* Add is-memcpu property, so it is possible to
enable memory-to-memory transfers support via DT.
* Add hw-llp property, so it is possible to enable
hardware multi block transfers support via DT.
* Update DW DMAC device tree documentation.
Eugeniy Paltsev (4):
DW DMAC: rename is_private property as ordered by DT policy
DW DMAC: add is-memcpu property to device tree
DW DMAC: add hw-llp property to device tree
Update device tree Synopsys DW DMAC documentation
Documentation/devicetree/bindings/dma/snps-dma.txt | 10 ++++++++--
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 10 ++++++++++
include/linux/platform_data/dma-dw.h | 4 ++--
4 files changed, 21 insertions(+), 5 deletions(-)
--
2.5.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH v4] pwm: add pwm driver for HiSilicon BVT SOCs
From: Rob Herring @ 2016-11-16 13:48 UTC (permalink / raw)
To: Jian Yuan
Cc: thierry.reding, mark.rutland, linux-pwm, devicetree, linux-kernel,
xuejiancheng, kevin.lixu, jalen.hsu
In-Reply-To: <1479213692-223477-1-git-send-email-yuanjian12@hisilicon.com>
On Tue, Nov 15, 2016 at 08:41:32PM +0800, Jian Yuan wrote:
> From: yuanjian <yuanjian12@hisilicon.com>
>
> Add PWM driver for the PWM controller found on HiSilicon BVT SOCs, like Hi3519V100, Hi3516CV300, etc.
Wrap your lines at ~72 chars.
> The PWM controller is primarily in charge of controlling P-Iris lens.
>
> Reviewed-by: Jiancheng Xue <xuejiancheng@hisilicon.com>
> Signed-off-by: Jian Yuan <yuanjian12@hisilicon.com>
> ---
> Change Log:
> v4:
> Add #pwm-cells in the bindings document.
> v3:
> fixed issues pointed by thierry.
> Add PWM compatible string for Hi3519V100.
> Implement .apply() function which support atomic, instead of .enable()/.disable()/.config().
> v2:
> The number of PWMs is change to be probeable based on the compatible string.
>
> .../devicetree/bindings/pwm/pwm-hibvt.txt | 23 ++
> drivers/pwm/Kconfig | 9 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-hibvt.c | 270 +++++++++++++++++++++
> 4 files changed, 303 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
> create mode 100644 drivers/pwm/pwm-hibvt.c
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt b/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
> new file mode 100644
> index 0000000..609284f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
> @@ -0,0 +1,23 @@
> +Hisilicon PWM controller
> +
> +Required properties:
> +-compatible: should contain one SoC specific compatible string and one generic compatible
ditto
> +string "hisilicon, hibvt-pwm". The SoC specific strings supported including:
> + "hisilicon,hi3516cv300-pwm"
> + "hisilicon,hi3519v100-pwm"
> +- reg: physical base address and length of the controller's registers.
> +- clocks: phandle and clock specifier of the PWM reference clock.
> +- resets: phandle and reset specifier for the PWM controller reset.
> +- #pwm-cells: Should be 2. See pwm.txt in this directory for a description of
> + the cells format.
> +
> +Example:
> + pwm: pwm@12130000 {
> +
> + compatible = "hisilicon,hi3516cv300-pwm", "hisilicon,hibvt-pwm";
> + compatible = "hisilicon,hi3519v100-pwm", "hisilicon,hibvt-pwm";
??
> + reg = <0x12130000 0x10000>;
> + clocks = <&crg_ctrl HI3516CV300_PWM_CLK>;
> + resets = <&crg_ctrl 0x38 0>;
> + #pwm-cells = <2>;
> + };
^ permalink raw reply
* Re: [PATCHv2 09/10] mmc: dw_mmc: The "clock-freq-min-max" property was deprecated
From: Rob Herring @ 2016-11-16 13:45 UTC (permalink / raw)
To: Jaehoon Chung; +Cc: linux-mmc, devicetree, ulf.hansson, heiko, shawn.lin
In-Reply-To: <20161115101232.3854-10-jh80.chung@samsung.com>
On Tue, Nov 15, 2016 at 07:12:31PM +0900, Jaehoon Chung wrote:
> The "clock-freq-min-max" property was deprecated.
> There is "max-frequency" property in drivers/mmc/core/host.c
> "max-frequency" can be replaced with "clock-freq-min-max".
> Minimum clock value might be set to 100K by default.
> Then MMC core should try to find the correct value from 400K to 100K.
> So it just needs to set Maximum clock value.
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> ---
> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 3 ++-
> drivers/mmc/host/dw_mmc.c | 2 ++
> 2 files changed, 4 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v7 3/3] clocksource: Add clockevent support to NPS400 driver
From: Rob Herring @ 2016-11-16 13:44 UTC (permalink / raw)
To: Noam Camus
Cc: mark.rutland-5wv7dgnIgG8, daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
tglx-hfZtesqFncYOwBW4kG4KsQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479199859-980-4-git-send-email-noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
On Tue, Nov 15, 2016 at 10:50:59AM +0200, Noam Camus wrote:
> From: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> Till now we used clockevent from generic ARC driver.
> This was enough as long as we worked with simple multicore SoC.
> When we are working with multithread SoC each HW thread can be
> scheduled to receive timer interrupt using timer mask register.
> This patch will provide a way to control clock events per HW thread.
>
> The design idea is that for each core there is dedicated register
> (TSI) serving all 16 HW threads.
> The register is a bitmask with one bit for each HW thread.
> When HW thread wants that next expiration of timer interrupt will
> hit it then the proper bit should be set in this dedicated register.
> When timer expires all HW threads within this core which their bit
> is set at the TSI register will be interrupted.
>
> Driver can be used from device tree by:
> compatible = "ezchip,nps400-timer0" <-- for clocksource
> compatible = "ezchip,nps400-timer1" <-- for clockevent
>
> Note that name convention for timer0/timer1 was taken from legacy
> ARC design. This design is our base before adding HW threads.
> For backward compatibility we keep "ezchip,nps400-timer" for clocksource
>
> Signed-off-by: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> ---
> .../bindings/timer/ezchip,nps400-timer.txt | 15 --
> .../bindings/timer/ezchip,nps400-timer0.txt | 17 ++
> .../bindings/timer/ezchip,nps400-timer1.txt | 15 ++
Please add acks when reposting.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/clocksource/timer-nps.c | 170 ++++++++++++++++++++
> 4 files changed, 202 insertions(+), 15 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
--
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] [media] ir-hix5hd2: make hisilicon,power-syscon property deprecated
From: Rob Herring @ 2016-11-16 13:37 UTC (permalink / raw)
To: Jiancheng Xue
Cc: mark.rutland-5wv7dgnIgG8, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
yanhaifeng-C8/M+/jPZTeaMJb+Lgu22Q,
hermit.wangheming-C8/M+/jPZTeaMJb+Lgu22Q,
elder-QSEj5FYQhm4dnm+yROfE0A, bin.chen-QSEj5FYQhm4dnm+yROfE0A,
Ruqiang Ju
In-Reply-To: <1479195092-20090-1-git-send-email-xuejiancheng-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
On Tue, Nov 15, 2016 at 03:31:32PM +0800, Jiancheng Xue wrote:
> From: Ruqiang Ju <juruqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>
> The clock of IR can be provided by the clock provider and controlled
> by common clock framework APIs.
>
> Signed-off-by: Ruqiang Ju <juruqiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Jiancheng Xue <xuejiancheng-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
> ---
> .../devicetree/bindings/media/hix5hd2-ir.txt | 6 +++---
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/media/rc/ir-hix5hd2.c | 25 ++++++++++++++--------
> 2 files changed, 19 insertions(+), 12 deletions(-)
--
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] clk: qcom: smd-rpm: Add msm8974 clocks
From: Rob Herring @ 2016-11-16 13:36 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Michael Turquette, Stephen Boyd, linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479192844-1281-1-git-send-email-bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, Nov 14, 2016 at 10:54:04PM -0800, Bjorn Andersson wrote:
> This adds all RPM based clocks for msm8974 except cxo and gfx3d_clk_src.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/clock/qcom,rpmcc.txt | 1 +
> drivers/clk/qcom/clk-smd-rpm.c | 71 ++++++++++++++++++++++
> include/dt-bindings/clock/qcom,rpmcc.h | 40 +++++++++++-
> 3 files changed, 110 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] can: holt_hi311x: document device tree bindings
From: Rob Herring @ 2016-11-16 13:34 UTC (permalink / raw)
To: Akshay Bhat
Cc: wg, mkl, mark.rutland, linux-can, netdev, devicetree,
linux-kernel, Akshay Bhat
In-Reply-To: <1479146144-29143-1-git-send-email-akshay.bhat@timesys.com>
On Mon, Nov 14, 2016 at 12:55:43PM -0500, Akshay Bhat wrote:
> Document the HOLT HI-311x CAN device tree bindings.
>
> Signed-off-by: Akshay Bhat <nodeax@gmail.com>
> ---
> .../devicetree/bindings/net/can/holt_hi311x.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/can/holt_hi311x.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
From: Rob Herring @ 2016-11-16 13:33 UTC (permalink / raw)
To: Jyri Sarha
Cc: devicetree, bcousson, khilman, dri-devel, bgolaszewski,
tomi.valkeinen, laurent.pinchart
In-Reply-To: <b4589c6a3275c0c7c8e3c379faedba3ce1423c5a.1479142062.git.jsarha@ti.com>
On Mon, Nov 14, 2016 at 06:54:17PM +0200, Jyri Sarha wrote:
> Add very basic ti-ftp410 DVI transmitter driver. The only feature
> separating this from a completely dummy bridge is the EDID read
> support trough DDC I2C. Even that functionality should be in a
> separate generic connector driver. However, because of missing DRM
> infrastructure support the connector is implemented within the bridge
> driver. Some tfp410 HW specific features may be added later if needed,
> because there is a set of registers behind i2c if it is connected.
>
> This implementations is tested against my new tilcdc bridge support
> and it works with BeagleBone DVI-D Cape Rev A3. A DT binding document
> is also added.
>
> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> ---
> .../bindings/display/bridge/ti,tfp410.txt | 41 ++++
> drivers/gpu/drm/bridge/Kconfig | 7 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/ti-tfp410.c | 223 +++++++++++++++++++++
> 4 files changed, 272 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> new file mode 100644
> index 0000000..7446b2b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> @@ -0,0 +1,41 @@
> +TFP410 DVI bridge bindings
> +
> +Required properties:
> + - compatible: "ti,tfp410"
> +
> +Optional properties
> + - reg: I2C address. If and only if present the driver node
> + should be placed into the i2c controller node where the
> + tfp410 i2c is connected to (the current implementation does
> + not yet support this).
So this chip can work without programming I guess?
reg should only be not present if I2C is not connected in the design. It
can't be a function of what the driver supports. In otherwords, you
can't be moving this node around based on when you add I2C control.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCHv0 1/1] fbdev: add Intel FPGA FRAME BUFFER driver
From: kbuild test robot @ 2016-11-16 13:33 UTC (permalink / raw)
Cc: kbuild-all, Tomi Valkeinen, devicetree, linux-kernel, linux-fbdev,
Ong Hean Loong
In-Reply-To: <1479287278-5192-1-git-send-email-hean.loong.ong@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]
Hi Ong,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.9-rc5 next-20161116]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ong-Hean-Loong/fbdev-add-Intel-FPGA-FRAME-BUFFER-driver/20161116-173833
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390
All warnings (new ones prefixed by >>):
warning: (DRM_KMS_FB_HELPER && FB_INTEL_FPGA_VIP) selects FRAMEBUFFER_CONSOLE which has unmet direct dependencies (HAS_IOMEM && VT && FB && !UML)
warning: (DRM_KMS_FB_HELPER && FB_INTEL_FPGA_VIP) selects FRAMEBUFFER_CONSOLE_DETECT_PRIMARY which has unmet direct dependencies (HAS_IOMEM && VT && FRAMEBUFFER_CONSOLE)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 43320 bytes --]
^ permalink raw reply
* Re: [PATCH v5 4/5] USB: ohci: da8xx: Add devicetree bindings
From: Rob Herring @ 2016-11-16 13:26 UTC (permalink / raw)
To: Axel Haslam
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
khilman-DgEjT+Ai2ygdnm+yROfE0A, kishon-l0cyMroinI0,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161114144103.12120-5-ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Mon, Nov 14, 2016 at 03:41:02PM +0100, Axel Haslam wrote:
> This patch documents the device tree bindings required for
> the ohci controller found in TI da8xx family of SoC's
>
> Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
> Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Axel Haslam <ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/usb/ohci-da8xx.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/ohci-da8xx.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Andrew Lunn @ 2016-11-16 13:23 UTC (permalink / raw)
To: Jerome Brunet
Cc: Florian Fainelli, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Carlo Caione, Kevin Hilman,
Giuseppe Cavallaro, Alexandre TORGUE, Martin Blumenstingl,
Andre Roth, Neil Armstrong,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479290189.17538.25.camel-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> There two kind of PHYs supporting eee, the one advertising eee by
> default (like realtek) and the one not advertising it (like micrel).
I don't know too much about EEE. So maybe a dumb question. Does the
MAC need to be involved? Or is it just the PHY?
If the MAC needs to be involved, the PHY should not be advertising EEE
unless the MAC asks for it by calling phy_init_eee(). If this is true,
maybe we need to change the realtek driver, and others in that class.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/2] Add OV5647 device tree documentation
From: Rob Herring @ 2016-11-16 13:21 UTC (permalink / raw)
To: Ramiro Oliveira
Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
dheitmueller-eb9eJ82Ua7k9XoPSrs7Ehg,
slongerbeam-Re5JQEeQqe8AvxtiuMwx3w, lars-Qo5EllUWu/uELgA04lAiVw,
robert.jarzmik-GANU6spQydw, pavel-+ZI9xUNit7I,
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA, mark.rutland-5wv7dgnIgG8,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <4b22cb1d055cdcae5cff1dd86672b6dc6a8726ce.1479129004.git.roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Mon, Nov 14, 2016 at 01:46:32PM +0000, Ramiro Oliveira wrote:
> Add device tree documentation.
>
> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/media/i2c/ov5647.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Hans de Goede @ 2016-11-16 13:15 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
Hans de Goede
Just like on sun8i all sun5i tablets use the same interrupt and power
gpios for their touchscreens. I've checked all known a13 fex files and
only the UTOO P66 uses a different gpio for the interrupt.
Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
fills in the necessary gpios to avoid duplication in the tablet dts files,
just like we do in sun8i-reference-design-tablet.dtsi.
This will make future patches adding touchscreen nodes to a13 tablets
simpler.
Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
Changes in v2:
-Use generic pin mux properties "pins", "function", "drive-strength" and
"bias-disable"
---
arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
.../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
2 files changed, 39 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
index a8b0bcc..3d7ff10 100644
--- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
+++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
@@ -83,22 +83,6 @@
allwinner,pins = "PG3";
};
-&i2c1 {
- icn8318: touchscreen@40 {
- compatible = "chipone,icn8318";
- reg = <0x40>;
- interrupt-parent = <&pio>;
- interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
- pinctrl-names = "default";
- pinctrl-0 = <&ts_wake_pin_p66>;
- wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
- touchscreen-size-x = <800>;
- touchscreen-size-y = <480>;
- touchscreen-inverted-x;
- touchscreen-swapped-x-y;
- };
-};
-
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins_a>;
@@ -121,20 +105,26 @@
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
};
-
- ts_wake_pin_p66: ts_wake_pin@0 {
- allwinner,pins = "PB3";
- allwinner,function = "gpio_out";
- allwinner,drive = <SUN4I_PINCTRL_10_MA>;
- allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
- };
-
};
®_usb0_vbus {
gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
};
+&touchscreen {
+ compatible = "chipone,icn8318";
+ reg = <0x40>;
+ /* The P66 uses a different EINT then the reference design */
+ interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
+ /* The icn8318 binding expects wake-gpios instead of power-gpios */
+ wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-inverted-x;
+ touchscreen-swapped-x-y;
+ status = "okay";
+};
+
&uart1 {
/* The P66 uses the uart pins as gpios */
status = "disabled";
diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
index 20cc940..82f87cd 100644
--- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
@@ -41,6 +41,7 @@
*/
#include "sunxi-reference-design-tablet.dtsi"
+#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/pwm/pwm.h>
/ {
@@ -84,6 +85,23 @@
};
&i2c1 {
+ /*
+ * The gsl1680 is rated at 400KHz and it will not work reliable at
+ * 100KHz, this has been confirmed on multiple different q8 tablets.
+ * All other devices on this bus are also rated for 400KHz.
+ */
+ clock-frequency = <400000>;
+
+ touchscreen: touchscreen {
+ interrupt-parent = <&pio>;
+ interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
+ pinctrl-names = "default";
+ pinctrl-0 = <&ts_power_pin>;
+ power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
+ /* Tablet dts must provide reg and compatible */
+ status = "disabled";
+ };
+
pcf8563: rtc@51 {
compatible = "nxp,pcf8563";
reg = <0x51>;
@@ -125,6 +143,13 @@
allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
};
+ ts_power_pin: ts_power_pin {
+ pins = "PB3";
+ function = "gpio_out";
+ drive-strength = <10>;
+ bias-disable;
+ };
+
usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
allwinner,pins = "PG1";
allwinner,function = "gpio_in";
--
2.9.3
--
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: [PATCHv0 1/1] fbdev: add Intel FPGA FRAME BUFFER driver
From: kbuild test robot @ 2016-11-16 12:45 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, Tomi Valkeinen,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Ong Hean Loong
In-Reply-To: <1479287278-5192-1-git-send-email-hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5143 bytes --]
Hi Ong,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc5 next-20161116]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ong-Hean-Loong/fbdev-add-Intel-FPGA-FRAME-BUFFER-driver/20161116-173833
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All errors (new ones prefixed by >>):
mm/compaction.c: In function 'isolate_migratepages_block':
>> mm/compaction.c:821:9: error: implicit declaration of function 'isolate_movable_page' [-Werror=implicit-function-declaration]
if (isolate_movable_page(page, isolate_mode))
^~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from mm/cma.c:28:0:
>> include/linux/memblock.h:425:15: error: unknown type name 'phys_addr_t'
static inline phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align)
^~~~~~~~~~~
include/linux/memblock.h:425:42: error: unknown type name 'phys_addr_t'
static inline phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align)
^~~~~~~~~~~
include/linux/memblock.h:425:60: error: unknown type name 'phys_addr_t'
static inline phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align)
^~~~~~~~~~~
mm/cma.c: In function 'cma_init_reserved_mem':
>> mm/cma.c:182:16: error: implicit declaration of function 'memblock_is_region_reserved' [-Werror=implicit-function-declaration]
if (!size || !memblock_is_region_reserved(base, size))
^~~~~~~~~~~~~~~~~~~~~~~~~~~
mm/cma.c: In function 'cma_declare_contiguous':
>> mm/cma.c:234:29: error: implicit declaration of function 'memblock_end_of_DRAM' [-Werror=implicit-function-declaration]
phys_addr_t memblock_end = memblock_end_of_DRAM();
^~~~~~~~~~~~~~~~~~~~
>> mm/cma.c:305:7: error: implicit declaration of function 'memblock_reserve' [-Werror=implicit-function-declaration]
memblock_reserve(base, size) < 0) {
^~~~~~~~~~~~~~~~
>> mm/cma.c:319:11: error: implicit declaration of function 'memblock_alloc_range' [-Werror=implicit-function-declaration]
addr = memblock_alloc_range(size, alignment,
^~~~~~~~~~~~~~~~~~~~
>> mm/cma.c:321:11: error: 'MEMBLOCK_NONE' undeclared (first use in this function)
MEMBLOCK_NONE);
^~~~~~~~~~~~~
mm/cma.c:321:11: note: each undeclared identifier is reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +/isolate_movable_page +821 mm/compaction.c
bda807d4 Minchan Kim 2016-07-26 805 * It's possible to migrate LRU and non-lru movable pages.
bda807d4 Minchan Kim 2016-07-26 806 * Skip any other type of page
bda807d4 Minchan Kim 2016-07-26 807 */
bda807d4 Minchan Kim 2016-07-26 808 if (!PageLRU(page)) {
bda807d4 Minchan Kim 2016-07-26 809 /*
bda807d4 Minchan Kim 2016-07-26 810 * __PageMovable can return false positive so we need
bda807d4 Minchan Kim 2016-07-26 811 * to verify it under page_lock.
bda807d4 Minchan Kim 2016-07-26 812 */
bda807d4 Minchan Kim 2016-07-26 813 if (unlikely(__PageMovable(page)) &&
bda807d4 Minchan Kim 2016-07-26 814 !PageIsolated(page)) {
bda807d4 Minchan Kim 2016-07-26 815 if (locked) {
a52633d8 Mel Gorman 2016-07-28 816 spin_unlock_irqrestore(zone_lru_lock(zone),
bda807d4 Minchan Kim 2016-07-26 817 flags);
bda807d4 Minchan Kim 2016-07-26 818 locked = false;
bda807d4 Minchan Kim 2016-07-26 819 }
bda807d4 Minchan Kim 2016-07-26 820
bda807d4 Minchan Kim 2016-07-26 @821 if (isolate_movable_page(page, isolate_mode))
bda807d4 Minchan Kim 2016-07-26 822 goto isolate_success;
bda807d4 Minchan Kim 2016-07-26 823 }
bda807d4 Minchan Kim 2016-07-26 824
fdd048e1 Vlastimil Babka 2016-05-19 825 goto isolate_fail;
bda807d4 Minchan Kim 2016-07-26 826 }
29c0dde8 Vlastimil Babka 2015-09-08 827
119d6d59 David Rientjes 2014-04-03 828 /*
119d6d59 David Rientjes 2014-04-03 829 * Migration will fail if an anonymous page is pinned in memory,
:::::: The code at line 821 was first introduced by commit
:::::: bda807d4445414e8e77da704f116bb0880fe0c76 mm: migrate: support non-lru movable page migration
:::::: TO: Minchan Kim <minchan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
:::::: CC: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 42055 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/3] dt-bindings: mxsfb: Add new bindings for the MXSFB driver
From: Marek Vasut @ 2016-11-16 12:16 UTC (permalink / raw)
To: Rob Herring
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Lucas Stach,
Fabio Estevam, Shawn Guo, Daniel Vetter,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161116002407.i4hnexjqzrxmn52g@rob-hp-laptop>
On 11/16/2016 01:24 AM, Rob Herring wrote:
> On Mon, Nov 14, 2016 at 11:10:35AM +0100, Marek Vasut wrote:
>> Add new DT bindings for new MXSFB driver that is using the
>> OF graph to parse the video output structure instead of
>> hard-coding the display properties into the MXSFB node.
>> The old MXSFB fbdev driver bindings are preserved in the
>> same file in the "Old bindings" section.
>>
>> Signed-off-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
>> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>> Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Daniel Vetter <daniel.vetter-/w4YWyX8dFk@public.gmane.org>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> --
>> V2: - Merge the new bindings into mxsfb.txt file instead of keeping
>> them in separate mxsfb-drm.txt file.
>> - Add dedicated compatible for i.MX6SX
>> - Drop all references to DRM/KMS
>> - Repair the required bits in clock node
>> ---
>> .../devicetree/bindings/display/mxsfb.txt | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt
>> index a4431f2..6e92593 100644
>> --- a/Documentation/devicetree/bindings/display/mxsfb.txt
>> +++ b/Documentation/devicetree/bindings/display/mxsfb.txt
>> @@ -1,5 +1,42 @@
>> * Freescale MXS LCD Interface (LCDIF)
>>
>> +New bindings:
>> +=============
>> +Required properties:
>> +- compatible: Should be "fsl,imx23-lcdif" for i.MX23.
>> + Should be "fsl,imx28-lcdif" for i.MX28.
>> + Should be "fsl,imx6sx-lcdif" for i.MX6SX.
>> +- reg: Address and length of the register set for lcdif
>
> s/lcdif/LCDIF/
>
>> +- interrupts: Should contain lcdif interrupts
>
> How many?
>
>> +- clocks: A list of phandle + clock-specifier pairs, one for each
>> + entry in 'clock-names'.
>> +- clock-names: A list of clock names. For MXSFB it should contain:
>> + - "pix" for the MXSFB block clock
>
> MXSFB is not a h/w block. LCDIF is the name.
>
>> + - (MX6SX-only) "axi", "disp_axi" for the bus interface clock
>> +
>> +Required sub-nodes:
>> + - port: The connection to an encoder chip.
>> +
>> +Example:
>> +
>> + lcdif1: lcdif@02220000 {
>
> display-controller@...
>
> Drop the leading 0 too.
Fixed all
>> + compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
>
> I'm not sure compatibility with mx28 is appropriate since you have the
> extra clocks. I guess if they don't need to be managed then it's okay.
The other two clock are optional
>> + reg = <0x02220000 0x4000>;
>> + interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
>> + <&clks IMX6SX_CLK_LCDIF_APB>,
>> + <&clks IMX6SX_CLK_DISPLAY_AXI>;
>> + clock-names = "pix", "axi", "disp_axi";
>> +
>> + port {
>> + parallel_out: endpoint {
>> + remote-endpoint = <&panel_in_parallel>;
>> + };
>> + };
>> + };
>> +
>> +Old bindings:
>
> s/Old/Deprecated/
Fixed
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox