Re: [PICKME 0/2] cpufreq: New ST driver

[Rafael J. Wysocki]

On Friday, December 11, 2015 07:05:32 AM Lee Jones wrote:
> On Fri, 11 Dec 2015, Viresh Kumar wrote:
> > On 10-12-15, 22:38, Rafael J. Wysocki wrote:
> > > Do they depend on anything special?
> > 
> > My opp-binding-parsing patches which you applied to bleeding-edge.
> 
> I thought these had already been applied.
> 
> > Yes, Lee should have mentioned that explicitly.
> 
> Aye, apologies for that.

No prob, applied now.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] extcon: add Maxim MAX3355 driver

[Greg KH]

On Tue, Dec 15, 2015 at 01:29:19AM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/15/2015 01:21 AM, Rob Herring wrote:
> 
> Maxim  Integrated MAX3355E chip integrates a  charge pump and comparators
> to
> enable a system with an integrated USB OTG dual-role transceiver to
> function
> as  an USB  OTG dual-role device.  In addition  to sensing/controlling
> Vbus,
> the chip also passes thru the ID signal  from the USB  OTG connector.
> On some Renesas boards,  this signal is  just fed into the SoC thru a
> GPIO
> pin --  there's no real  OTG controller, only host and gadget USB
> controllers
> sharing the same USB bus; however, we'd  like to allow host or gadget
> drivers
> to be loaded depending on the cable type,  hence the need for the MAX3355
> extcon driver. The Vbus status signals are also  wired to GPIOs (however,
> we
> aren't currently interested in them),  the OFFVBUS# signal is controlled
> by
> the host controllers, there's  also the SHDN# signal wired to a GPIO, it
> should be driven high for the  normal operation.
> >>>
> >>>
> >>>As multiple people have said, fix the spacing here.
> >>
> >>
> >>You are the first to complain abou _this_ patch. If you don't have other
> >>issues with this driver in which case you should have trimmed the reply at
> >>this point), I'd like to keep my spacing as is. Thank you.
> >
> >Your previous version was not "extcon-usb-gpio: add enable pin
> >support"[1] which has now been re-written to be max3355 specific?
> 
>No, the MAX3355 driver pre-dates that version. First there was a driver,
> then I tried to re-use the existing stuff (there was no extcon-usb-gpio at
> the time of writing my driver), then had to return to the separate driver
> idea...
> 
> >"So
> >what" and "I'd like to keep my spacing as is" aren't valid reasons.
> >Fix it, then I'll look at the rest again.
> 
>I'll consider doing that if you care to explain what's the problem with
> my spacing. TIA.

You are mixing 2 and 1 spaces between words, don't do that.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/8 v4] thermal: of-thermal: of_thermal_set_trip_temp() call thermal_zone_device_update()

[Kuninori Morimoto]

Hi Eduardo

> > From: Kuninori Morimoto 
> > 
> > of_thermal_set_trip_temp() updates trip temperature. It should call
> > thermal_zone_device_update() immediately.
> > 
> > Signed-off-by: Kuninori Morimoto 
> > ---
> > v3 -> v4
> > 
> >  - no change
> > 
> >  drivers/thermal/of-thermal.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> > index 42b7d42..a1dd7b1 100644
> > --- a/drivers/thermal/of-thermal.c
> > +++ b/drivers/thermal/of-thermal.c
> > @@ -334,6 +334,8 @@ static int of_thermal_set_trip_temp(struct 
> > thermal_zone_device *tz, int trip,
> > /* thermal framework should take care of data->mask & (1 << trip) */
> > data->trips[trip].temperature = temp;
> >  
> > +   thermal_zone_device_update(tz);
> > +
> 
> Although I understand the need for this, I would prefer you move this change
> to thermal_core.c. The reasoning is to keep the same behavior for
> thermal zones created over of thermal and regular thermal zones.

Indeed. will do in v5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 0/17] Add Analogix Core Display Port Driver

[Heiko Stübner]

Hi Yakir,

Am Montag, 7. Dezember 2015, 14:37:19 schrieb Yakir Yang:
>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM

so it looks like the hotplug works nicely now. I was able to test it 
sucessfully on both a Jerry and a Minnie device without needing to force 
hotplug :-) .

As I needed to adapt some patches when applying the lastest ones, I think it 
would be good for a full send of the latest version as v11.

When going over the patches before sending, please also fix the indentation 
issues in analogix_dp_core.h - both newly added elements to analogix_dp_device 
use spaces between type and name, where the rest uses tabs.
[This should of course be fixed in the patches adding these lines :-) ]


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/8 v4] thermal: rcar: retern error rcar_thermal_get_temp() if no ctemp update

[Kuninori Morimoto]

Hi Eduardo, again

> I believe the problem here is actually the lack of error
> handling/propagation. Are you sure you want to write to parameter
> in the fail path ?
> 
> rcar_thermal_update_temp already returns error code when it fails
> to read temperature. Don't you think it would make more sense to fix the
> places that call rcar_thermal_update_temp to properly handle its return
> value and propagate that error code when necessary?

Will update in v5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 3/5] memory: mediatek: Add SMI driver

[Yong Wu]

On Mon, 2015-12-14 at 19:18 +0100, Matthias Brugger wrote:
> On Tuesday 08 Dec 2015 17:49:11 Yong Wu wrote:
> > This patch add SMI(Smart Multimedia Interface) driver. This driver
> > is responsible to enable/disable iommu and control the power domain
> > and clocks of each local arbiter.
> > 
> > Signed-off-by: Yong Wu 
> > ---
> >   Currently SMI offer mtk_smi_larb_get/put to enable the power-domain
> > ,clocks and initialize the iommu configuration register for each a local
> > arbiter, The reason is:
> >   a) If a device would like to disable iommu, it also need call
> > mtk_smi_larb_get/put to enable its power and clocks.
> >   b) The iommu core don't support attach/detach a device within a
> > iommu-group. So we cann't use iommu_attach_device(iommu_detach_device)
> > instead
> > of mtk_smi_larb_get/put.
> > 
[..]
> > +static int
> > +mtk_smi_enable(struct device *dev, struct clk *apb, struct clk *smi)
> > +{
> > +   int ret;
> > +
> > +   ret = pm_runtime_get_sync(dev);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   ret = clk_prepare_enable(apb);
> > +   if (ret)
> > +   goto err_put_pm;
> > +
> > +   ret = clk_prepare_enable(smi);
> > +   if (ret)
> > +   goto err_disable_apb;
> > +
> > +   return 0;
> > +
> > +err_disable_apb:
> > +   clk_disable_unprepare(apb);
> > +err_put_pm:
> > +   pm_runtime_put_sync(dev);
> > +   return ret;
> > +}
> > +
> > +static void
> > +mtk_smi_disable(struct device *dev, struct clk *apb, struct clk *smi)
> > +{
> > +   clk_disable_unprepare(smi);
> > +   clk_disable_unprepare(apb);
> > +   pm_runtime_put_sync(dev);
> > +}
> > +
> > +static int mtk_smi_common_enable(struct mtk_smi_common *common)
> > +{
> > +   return mtk_smi_enable(common->dev, common->clk_apb, common->clk_smi);
> > +}
> > +
> > +static void mtk_smi_common_disable(struct mtk_smi_common *common)
> > +{
> > +   mtk_smi_disable(common->dev, common->clk_apb, common->clk_smi);
> > +}
> > +
> > +static int mtk_smi_larb_enable(struct mtk_smi_larb *larb)
> > +{
> > +   return mtk_smi_enable(larb->dev, larb->clk_apb, larb->clk_smi);
> > +}
> > +
> > +static void mtk_smi_larb_disable(struct mtk_smi_larb *larb)
> > +{
> > +   mtk_smi_disable(larb->dev, larb->clk_apb, larb->clk_smi);
> > +}
> > +
> 
> This is somehow over-engineered. Just use mtk_smi_enable and mtk_smi_disable 
> instead of adding an extra indirection.

I added this only for readable...then the code in mtk_smi_larb_get below
may looks simple and readable.

If I use mtk_smi_enable/disable directly, the code will be like our
v5[1], is it OK?
Maybe I don't need these help function here, and only add more comment
based on v5.

[1] 
http://lists.linuxfoundation.org/pipermail/iommu/2015-October/014590.html

> 
> > +int mtk_smi_larb_get(struct device *larbdev)
> > +{
> > +   struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
> > +   struct mtk_smi_common *common = dev_get_drvdata(larb->smi_common_dev);
> > +   int ret;
> > +
> > +   ret = mtk_smi_common_enable(common);
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = mtk_smi_larb_enable(larb);
> > +   if (ret)
> > +   goto err_put_smi;
> > +
> > +   /* Configure the iommu info */
> > +   writel_relaxed(larb->mmu, larb->base + SMI_LARB_MMU_EN);
> > +
> > +   return 0;
> > +
> > +err_put_smi:
> > +   mtk_smi_common_disable(common);
> > +   return ret;
> > +}
> > +
> > +void mtk_smi_larb_put(struct device *larbdev)
> > +{
> > +   struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
> > +   struct mtk_smi_common *common = dev_get_drvdata(larb->smi_common_dev);
> > +
> > +   writel_relaxed(0, larb->base + SMI_LARB_MMU_EN);
> > +   mtk_smi_larb_disable(larb);
> > +   mtk_smi_common_disable(common);
> > +}
> > +
> 
> Looks strange that you just disable all MMUs while you only enable some of 
> them at runtime. Unfortunately the datasheet I have lacks the SMI part, so I 
> can just guess how the HW is working.
> From the DTS it looks like as if a larb can be used by two different 
> components (e.g. larb0 from ovl0 and rdma0). Wouldn't that produce a conflict?

Thanks. It's really a problem.

There are OVL0 and MDP in larb0, Both will call mtk_smi_larb_get/put, we
cann't disable all the MMUs in whole the larb0 here.  This register
should be reset to zero while the larb power domain turning off(rely on
the power-domain ref count).
I will delete this(keep this in our V5.)

> 
> Regards,
> Matthias




--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: dts: modify rk3288 jaq backlight-level

[Caesar Wang]

Heiko,


在 2015年12月15日 05:46, Heiko Stübner 写道:

Hi Caesar,

Am Montag, 7. Dezember 2015, 21:11:08 schrieb Caesar Wang:

the panel which jaq use require the pwm duty cycle larger than 3%,
when the backlight status from power off to power on, otherwise the
backlight will flush, so we modify the second brightness-level to 8,
and when the backlight from power off to power on the pwm duty cycle
will larger than 3%.

Signed-off-by: Caesar Wang 

I've merged the two patches and included them in my series for the veyron edp
devicetree changes [0].


Heiko

[0] 
https://github.com/mmind/linux-rockchip/commit/45e3abed0a86c7ee5cea0b35492b65890b928175


Yep, that's more resonable since we need depend on this edp device node.

https://github.com/rockchip-linux/kernel/commit/6d1491faf1e5eee98dfcd9bb1ba1b7f866cd51ab



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/8 v5] thermal: rcar: check every rcar_thermal_update_temp() return value

[Kuninori Morimoto]

From: Kuninori Morimoto 

Every rcar_thermal_update_temp() return value will be checked.

And also, rcar_thermal_get_temp() always call
rcar_thermal_update_temp() by this patch.

Signed-off-by: Kuninori Morimoto 
---
v4 -> v5

 - rcar_thermal_get_temp() calls rcar_thermal_update_temp()
   without checking rcar_has_irq_support()

 drivers/thermal/rcar_thermal.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index ac8d1eb..0b19743 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -75,12 +75,6 @@ struct rcar_thermal_priv {
 #define rcar_has_irq_support(priv) ((priv)->common->base)
 #define rcar_id_to_shift(priv) ((priv)->id * 8)
 
-#ifdef DEBUG
-# define rcar_force_update_temp(priv)  1
-#else
-# define rcar_force_update_temp(priv)  0
-#endif
-
 static const struct of_device_id rcar_thermal_dt_ids[] = {
{ .compatible = "renesas,rcar-thermal", },
{},
@@ -209,9 +203,11 @@ err_out_unlock:
 static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
 {
struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
+   int ret;
 
-   if (!rcar_has_irq_support(priv) || rcar_force_update_temp(priv))
-   rcar_thermal_update_temp(priv);
+   ret = rcar_thermal_update_temp(priv);
+   if (ret < 0)
+   return ret;
 
mutex_lock(>lock);
*temp =  MCELSIUS((priv->ctemp * 5) - 65);
@@ -305,11 +301,15 @@ static void rcar_thermal_work(struct work_struct *work)
 {
struct rcar_thermal_priv *priv;
int cctemp, nctemp;
+   int ret;
 
priv = container_of(work, struct rcar_thermal_priv, work.work);
 
rcar_thermal_get_temp(priv->zone, );
-   rcar_thermal_update_temp(priv);
+   ret = rcar_thermal_update_temp(priv);
+   if (ret < 0)
+   return;
+
rcar_thermal_irq_enable(priv);
 
rcar_thermal_get_temp(priv->zone, );
@@ -427,7 +427,9 @@ static int rcar_thermal_probe(struct platform_device *pdev)
mutex_init(>lock);
INIT_LIST_HEAD(>list);
INIT_DELAYED_WORK(>work, rcar_thermal_work);
-   rcar_thermal_update_temp(priv);
+   ret = rcar_thermal_update_temp(priv);
+   if (ret < 0)
+   goto error_unregister;
 
priv->zone = thermal_zone_device_register("rcar_thermal",
1, 0, priv,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/8 v5] thermal: rcar: check irq possibility in rcar_thermal_irq_xxx()

[Kuninori Morimoto]

From: Kuninori Morimoto 

Current rcar thermal driver sometimes checks irq possibility when it
calls rcar_thermal_irq_enable/disable(), but sometimes not.
This patch checks it inside rcar_thermal_irq_enable/disable().

Signed-off-by: Kuninori Morimoto 
---
v4 -> v5

 - no change

 drivers/thermal/rcar_thermal.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 0b19743..e9e4e39 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -290,6 +290,9 @@ static void _rcar_thermal_irq_ctrl(struct rcar_thermal_priv 
*priv, int enable)
unsigned long flags;
u32 mask = 0x3 << rcar_id_to_shift(priv); /* enable Rising/Falling */
 
+   if (!rcar_has_irq_support(priv))
+   return;
+
spin_lock_irqsave(>lock, flags);
 
rcar_thermal_common_bset(common, INTMSK, mask, enable ? 0 : mask);
@@ -441,8 +444,7 @@ static int rcar_thermal_probe(struct platform_device *pdev)
goto error_unregister;
}
 
-   if (rcar_has_irq_support(priv))
-   rcar_thermal_irq_enable(priv);
+   rcar_thermal_irq_enable(priv);
 
list_move_tail(>list, >head);
 
@@ -488,8 +490,7 @@ static int rcar_thermal_remove(struct platform_device *pdev)
struct rcar_thermal_priv *priv;
 
rcar_thermal_for_each_priv(priv, common) {
-   if (rcar_has_irq_support(priv))
-   rcar_thermal_irq_disable(priv);
+   rcar_thermal_irq_disable(priv);
thermal_zone_device_unregister(priv->zone);
}
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/8 v5] thermal: rcar: move rcar_thermal_dt_ids to upside

[Kuninori Morimoto]

From: Kuninori Morimoto 

This patch is prepare for of-thermal support.

Signed-off-by: Kuninori Morimoto 
---
v4 -> v5

 - no change

 drivers/thermal/rcar_thermal.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 5d4ae7d..ac8d1eb 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -81,6 +81,12 @@ struct rcar_thermal_priv {
 # define rcar_force_update_temp(priv)  0
 #endif
 
+static const struct of_device_id rcar_thermal_dt_ids[] = {
+   { .compatible = "renesas,rcar-thermal", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, rcar_thermal_dt_ids);
+
 /*
  * basic functions
  */
@@ -491,12 +497,6 @@ static int rcar_thermal_remove(struct platform_device 
*pdev)
return 0;
 }
 
-static const struct of_device_id rcar_thermal_dt_ids[] = {
-   { .compatible = "renesas,rcar-thermal", },
-   {},
-};
-MODULE_DEVICE_TABLE(of, rcar_thermal_dt_ids);
-
 static struct platform_driver rcar_thermal_driver = {
.driver = {
.name   = "rcar_thermal",
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: emac: emac gigabit ethernet controller driver

[Florian Fainelli]

On 14/12/15 16:19, Gilad Avidov wrote:

[snip]

> + "sgmii_irq";
> + qcom,emac-gpio-mdc = < 123 0>;
> + qcom,emac-gpio-mdio = < 124 0>;
> + qcom,emac-tstamp-en;
> + qcom,emac-ptp-frac-ns-adj = <12500 1>;
> + phy-addr = <0>;

Please use the standard Ethernet PHY and MDIO device tree bindings to
describe your MAC to PHY connection here, that includes using a
phy-connection-type property to describe the (x)MII lanes.

[snip]

> +/* EMAC_MAC_CTRL */
> +#define SINGLE_PAUSE_MODE   0x1000
> +#define DEBUG_MODE   0x800
> +#define BROAD_EN 0x400
> +#define MULTI_ALL0x200
> +#define RX_CHKSUM_EN 0x100
> +#define HUGE  0x80
> +#define SPEED_BMSK0x30
> +#define SPEED_SHFT  20
> +#define SIMR   0x8
> +#define TPAUSE 0x1
> +#define PROM_MODE   0x8000
> +#define VLAN_STRIP  0x4000
> +#define PRLEN_BMSK  0x3c00
> +#define PRLEN_SHFT  10
> +#define HUGEN0x200
> +#define FLCHK0x100
> +#define PCRCE 0x80
> +#define CRCE  0x40
> +#define FULLD 0x20
> +#define MAC_LP_EN 0x10
> +#define RXFC   0x8
> +#define TXFC   0x4
> +#define RXEN   0x2
> +#define TXEN   0x1

BIT(x)? which would avoid making this reverse christmas tree, I know
this is the time of year though.

[snip]

> +/* DMA address */
> +#define DMA_ADDR_HI_MASK 0xULL
> +#define DMA_ADDR_LO_MASK 0xULL
> +
> +#define EMAC_DMA_ADDR_HI(_addr)  \
> + ((u32)(((u64)(_addr) & DMA_ADDR_HI_MASK) >> 32))
> +#define EMAC_DMA_ADDR_LO(_addr)  \
> + ((u32)((u64)(_addr) & DMA_ADDR_LO_MASK))

The kernel provides helpers for that: upper_32bits and lower_32bits().

[snip]

> +struct emac_skb_cb {
> + u32   tpd_idx;
> + unsigned long jiffies;
> +};
> +
> +struct emac_tx_ts_cb {
> + u32 sec;
> + u32 ns;
> +};
> +
> +#define EMAC_SKB_CB(skb) ((struct emac_skb_cb *)(skb)->cb)
> +#define EMAC_TX_TS_CB(skb)   ((struct emac_tx_ts_cb *)(skb)->cb)

Should not these two have different offsets within skb->cb in case they
both end-up being added to the same SKB?

[snip]

> +static void emac_mac_irq_enable(struct emac_adapter *adpt)
> +{
> + int i;
> +
> + for (i = 0; i < EMAC_NUM_CORE_IRQ; i++) {
> + struct emac_irq *irq = >irq[i];
> + const struct emac_irq_config*irq_cfg = _irq_cfg_tbl[i];
> +
> + writel_relaxed(~DIS_INT, adpt->base + irq_cfg->status_reg);
> + writel_relaxed(irq->mask, adpt->base + irq_cfg->mask_reg);
> + }
> +
> + wmb(); /* ensure that irq and ptp setting are flushed to HW */

Would not using writel() make the appropriate thing here instead of
using _relaxed which has no barrier?

[snip]

> + mta = readl_relaxed(adpt->base + EMAC_HASH_TAB_REG0 + (reg << 2));
> + mta |= (0x1 << bit);
> + writel_relaxed(mta, adpt->base + EMAC_HASH_TAB_REG0 + (reg << 2));
> + wmb(); /* ensure that the mac address is flushed to HW */

This is getting too much here, just use the correct I/O accessor for
your platform, period.

[snip]

> +
> + /* enable RX/TX Flow Control */
> + switch (phy->cur_fc_mode) {
> + case EMAC_FC_FULL:
> + mac |= (TXFC | RXFC);
> + break;
> + case EMAC_FC_RX_PAUSE:
> + mac |= RXFC;
> + break;
> + case EMAC_FC_TX_PAUSE:
> + mac |= TXFC;
> + break;
> + default:
> + break;
> + }
> +
> + /* setup link speed */
> + mac &= ~SPEED_BMSK;
> + switch (phy->link_speed) {
> + case EMAC_LINK_SPEED_1GB_FULL:
> + mac |= ((emac_mac_speed_1000 << SPEED_SHFT) & SPEED_BMSK);
> + csr1 |= FREQ_MODE;
> + 

Re: [PATCH v2 01/14] DEVICETREE: Add bindings for PIC32 interrupt controller

[Rob Herring]

On Mon, Dec 14, 2015 at 03:42:03PM -0700, Joshua Henderson wrote:
> From: Cristian Birsan 
> 
> Document the devicetree bindings for the interrupt controller on
> Microchip PIC32 class devices.
> 
> Signed-off-by: Cristian Birsan 
> Signed-off-by: Joshua Henderson 
> Cc: Ralf Baechle 

Acked-by: Rob Herring 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4 12/16] Documentation: DT: bindings: Add power domain info for NVIDIA PMC

[Kevin Hilman]

Jon Hunter  writes:

> On 09/12/15 12:23, Jon Hunter wrote:
>> 
>> On 08/12/15 19:07, Kevin Hilman wrote:
>>> Jon Hunter  writes:
>>>
 Add power-domain binding documentation for the NVIDIA PMC driver in
 order to support generic power-domains.

 Signed-off-by: Jon Hunter 

 ---

 Please note that I have been debating whether I add this
 "nvidia,powergate-clock-disable" property or just leave the clocks
 disabled by default. Some downstream kernels leave the clocks enabled
 for the audio power-domain because the clocks required for powering up
 the power-domain are needed by all modules within the power-domain.
 However are the same time there are other power-domains that may need
 to be on, but not always clocked and so having the ability to specify if
 the clocks should be disabled seems useful. However, I can also remove
 this and just have the appropriate devices turn on the clocks as well.
 ---
  .../bindings/arm/tegra/nvidia,tegra20-pmc.txt  | 61 
 ++
  1 file changed, 61 insertions(+)

 diff --git 
 a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt 
 b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
 index 838e1a69ec0a..8e4641db51a9 100644
 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
 +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
 @@ -1,5 +1,7 @@
  NVIDIA Tegra Power Management Controller (PMC)
  
 +== Power Management Controller Node ==
 +
  The PMC block interacts with an external Power Management Unit. The PMC
  mostly controls the entry and exit of the system from different sleep
  modes. It provides power-gating controllers for SoC and CPU power-islands.
 @@ -69,6 +71,10 @@ Optional properties for hardware-triggered thermal 
 reset (inside 'i2c-thermtrip'
   Defaults to 0. Valid values are described in section 
 12.5.2
   "Pinmux Support" of the Tegra4 Technical Reference 
 Manual.
  
 +Optional nodes:
 +- pm-domains : This node contains a hierarchy of PM domain nodes, which 
 should
 + match the power-domains on the Tegra SoC.
 +
  Example:
  
  / SoC dts including file
 @@ -114,3 +120,58 @@ pmc@7000f400 {
};
...
  };
 +
 +
 +== PM Domain Nodes ==
 +
 +Each of the PM domain nodes represents a power-domain on the Tegra SoC
 +that can be power-gated by the PMC and should be named appropriately.
 +
 +Required properties:
 +  - clocks: Must contain an entry for each clock required by the PMC for
 +controlling a power-gate. See ../clocks/clock-bindings.txt for 
 details.
>>>
>>> We've had this discussiona for a couple of other SoCs, so I need to
>>> ask...
>>>
>>> Presumably these are not device clocks that a runtime PM enabled driver
>>> should be managing for a device, right?  IOW, We want to make sure that the
>>> PM domain isn't managing clocks for drivers that should be doing it.
>>>
>>> I understand there are legitimate reasons for the PM domain to manage
>>> clocks in addition to device drivers (e.g. for synchronous reset), but
>>> just want to be sure it's not a shortcut for having a proper driver.
>> 
>> So some clocks may also be used by devices, but they are needed as part
>> of the power ungating/gating sequence. The general power-up sequence for
>> tegra is ...
>> 
>> 1. Enable the power-domain
>> 2. Enable the clock(s)
>> 3. Remove signal clamps
>> 4. De-assert reset(s)
>> 5. Disable clocks (optional)
>> 
>> You may say we should only handle #1 above for the powering up sequence,
>> but we can't do this. The reason is that there is one bit for each
>> power-domain that controls the signaling clamps and so we need to turn
>> on all the clocks specified in the TRM before we do this. Once we have
>> done this and released the reset(s), we can then disable the clocks
>> again (shown above an optional as it is not mandatory from a design
>> perspective) and then the devices in the power-domain should enable the
>> clocks they need as and when they want them.
>> 
>> Please note that I 100% agree that all clocks required by a device are
>> handled by the device and we do not implement any short-cuts here. The
>> only question I had was if there are clocks that may be bus clocks in
>> the power-domain that are required by all device in the power-domain.
>> However, may be this should be represented as a bus driver and all the
>> devices are children of it?
>
> Although the "nvidia,powergate-disable-clocks" optional property I had
> proposed could be seen as a bit of a short-cut, it is true :-)
> May be I should make the disabling of clocks again mandatory for the
> power-up sequence.

IIUC, that 

Re: [PATCH v6 4/5] iommu/mediatek: Add mt8173 IOMMU driver

[Yong Wu]

On Mon, 2015-12-14 at 19:19 +0100, Matthias Brugger wrote:
> 
> On 08/12/15 10:49, Yong Wu wrote:
> > This patch adds support for mediatek m4u (MultiMedia Memory Management
> > Unit).
> >
> > Signed-off-by: Yong Wu 
> > ---
[...]
> > +static void mtk_iommu_config(struct mtk_iommu_data *data,
> > +struct device *dev, bool enable)
> > +{
> > +   struct mtk_iommu_client_priv *head, *cur, *next;
> > +
> > +   head = dev->archdata.iommu;
> > +   list_for_each_entry_safe(cur, next, >client, client) {
> > +   mtk_smi_config_port(
> > +   data->larbdev[MTK_M4U_TO_LARB(cur->mtk_m4u_id)],
> > +   MTK_M4U_TO_PORT(cur->mtk_m4u_id), enable);
> 
> Use an extra variable for MTK_M4U_TO_LARB(cur->mtk-m4u_id), this makes 
> the code easier to read.

OK. Thanks.
I will fix it in next version.

> 
> Regards,
> Matthias
> 
> > +   }
> > +}
> > +
[...]


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3] cpufreq: qoriq: Register cooling device based on device tree

[Rafael J. Wysocki]

On Thursday, November 26, 2015 05:21:11 PM Jia Hongtao wrote:
> Register the qoriq cpufreq driver as a cooling device, based on the
> thermal device tree framework. When temperature crosses the passive trip
> point cpufreq is used to throttle CPUs.
> 
> Signed-off-by: Jia Hongtao 
> Reviewed-by: Viresh Kumar 

Applied, thanks!

Rafael

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] extcon: arizona: Add DT binding examples

[Chanwoo Choi]

On 2015년 12월 14일 19:37, Charles Keepax wrote:
> Add an example for all elements of the Arizona extcon device tree
> binding.
> 
> Signed-off-by: Charles Keepax 
> ---
>  .../devicetree/bindings/extcon/extcon-arizona.txt  | 26 
> ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt 
> b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> index fd9b898..e27341f 100644
> --- a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> +++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> @@ -47,3 +47,29 @@ Optional properties:
>  The third cell represents the value of the micd-pol-gpio pin.
>  
>- wlf,gpsw : Settings for the general purpose switch
> +
> +Example:
> +
> +codec: wm8280@0 {
> + compatible = "wlf,wm8280";
> + reg = <0>;
> + ...
> +
> + wlf,use-jd2;
> + wlf,use-jd2-nopull;
> + wlf,jd-invert;
> +
> + wlf,micd-software-compare;
> + wlf,micd-detect-debounce = <0>;
> + wlf,micd-pol-gpio = < 2 0>;
> + wlf,micd-rate = ;
> + wlf,micd-dbtime = <4>;
> + wlf,micd-timeout-ms = <100>;
> + wlf,micd-force-micbias;
> + wlf,micd-configs = <
> + 0 1 0 /* MICDET1 MICBIAS1 GPIO=low */
> + 1 2 1 /* MICDET2 MICBIAS2 GPIO=high */
> + >;
> +
> + wlf,gpsw = <0>;
> +};
> 

Looks good to me. Applied it.

Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] extcon: arizona: Add device bindings for the micd configurations

[Chanwoo Choi]

On 2015년 12월 14일 19:37, Charles Keepax wrote:
> Add device bindings to support configuring the jack detection
> configurations. Each configuration needs to specify the connection of
> the mic det pins, which micbias should be used and the value of the
> micd polarity GPIO required to activate that configuration.
> 
> Signed-off-by: Charles Keepax 
> Acked-by: Chanwoo Choi 
> ---
> 
> Changes since v1:
>  - Report error from arizona_extcon_get_micd_configs
> 
> Thanks,
> Charles
> 
>  drivers/extcon/extcon-arizona.c | 56 
> +++--
>  1 file changed, 54 insertions(+), 2 deletions(-)

Applied it.

Thanks,
Chanwoo Choi

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] extcon: arizona: Update device tree binding for mic detect configurations

[Chanwoo Choi]

On 2015년 12월 14일 19:37, Charles Keepax wrote:
> Update the device tree binding documentation to include documentation for
> the wlf,micd-configs property that is used to specify the configurations
> for headset polarity detection (CTIA / OTMP).
> 
> Signed-off-by: Charles Keepax 
> Acked-by: Rob Herring 
> ---
> 
> No changes since v1.
> 
> Thanks,
> Charles
> 
>  Documentation/devicetree/bindings/extcon/extcon-arizona.txt | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt 
> b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> index 238e10e..fd9b898 100644
> --- a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> +++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> @@ -37,5 +37,13 @@ Optional properties:
>  milliseconds.
>- wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
>  detection.
> +  - wlf,micd-configs : Headset polarity configurations (generally used for
> +detection of CTIA / OMTP headsets), the field can be of variable length
> +but should always be a multiple of 3 cells long, each three cell group
> +represents one polarity configuration.
> +The first cell defines the accessory detection pin, zero will use MICDET1
> +and all other values will use MICDET2.
> +The second cell represents the MICBIAS to be used.
> +The third cell represents the value of the micd-pol-gpio pin.
>  
>- wlf,gpsw : Settings for the general purpose switch
> 

Applied it.

Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] extcon: add Maxim MAX3355 driver

[Chanwoo Choi]

Hi Sergei,

On 2015년 12월 12일 08:22, Sergei Shtylyov wrote:
> Maxim  Integrated MAX3355E chip integrates a  charge pump and comparators to
   ^^ ^^ 
> enable a system with an integrated USB OTG dual-role transceiver to function
> as  an USB  OTG dual-role device.  In addition  to sensing/controlling Vbus,
^^  ^^ ^^   ^^
> the chip also passes thru the ID signal  from the USB  OTG connector.
 ^^
> On some Renesas boards,  this signal is  just fed into the SoC thru a GPIO
 ^^  ^^
> pin --  there's no real  OTG controller, only host and gadget USB controllers
^^   ^^
> sharing the same USB bus; however, we'd  like to allow host or gadget drivers
 ^^
> to be loaded depending on the cable type,  hence the need for the MAX3355
   ^^
> extcon driver. The Vbus status signals are also  wired to GPIOs (however, we
> aren't currently interested in them),  the OFFVBUS# signal is controlled  by
   ^^ ^^  
> the host controllers, there's  also the SHDN# signal wired to a GPIO, it
   ^^
> should be driven high for the  normal operation.
   ^^
As above '^' expression, you used the double space between words.
You should fix it.

Thanks,
Chanwoo Choi


> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
> 
> Changes in version 2:
> - added the USB gadget cable support;
> - added the remove() driver method which drives SHDN# GPIO low to save power;
> - dropped vendor prefix from the ID GPIO property name;
> - changed the GPIO property name suffix to "-gpios";
> - switched to usign extcon_set_cable_state_() API;
> - switched to using the gpiod/sleeping 'gpiolib' APIs;
> - addded error messages to max3355_probe();
> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
> - renamed 'ret' variable to 'err' in max3355_probe();
> - expanded the Kconfig entry help text;
> - added vendor name to the patch summary, the bindings document, the Kconfig
>   entry, the driver heading comment, the module description, and the change 
> log;
> - fixed up and reformatted the change log.
> 
>  Documentation/devicetree/bindings/extcon/extcon-max3355.txt |   21 +
>  drivers/extcon/Kconfig  |8 
>  drivers/extcon/Makefile |1 
>  drivers/extcon/extcon-max3355.c |  153 
> 
>  4 files changed, 183 insertions(+)
> 
> Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> ===
> --- /dev/null
> +++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> @@ -0,0 +1,21 @@
> +Maxim Integrated MAX3355 USB OTG chip
> +-
> +
> +MAX3355 integrates a charge pump and comparators to enable a system with an
> +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> +device.
> +
> +Required properties:
> +- compatible: should be "maxim,max3355";
> +- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO 
> pin
> +  connected to the MAX3355's SHDN# pin;
> +- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
> +  connected to the MAX3355's ID_OUT pin.
> +
> +Example (Koelsch board):
> +
> + usb-otg {
> + compatible = "maxim,max3355";
> + maxim,shdn-gpios = < 4 GPIO_ACTIVE_LOW>;
> + id-gpios = < 31 GPIO_ACTIVE_HIGH>;
> + };
> Index: extcon/drivers/extcon/Kconfig
> ===
> --- extcon.orig/drivers/extcon/Kconfig
> +++ extcon/drivers/extcon/Kconfig
> @@ -52,6 +52,14 @@ config EXTCON_MAX14577
> Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
> detector and switch.
>  
> +config EXTCON_MAX3355
> + tristate "Maxim MAX3355 USB OTG EXTCON Support"
> + help
> +   If you say yes here you get support for the USB OTG role detection by
> +   MAX3355. The MAX3355 chip integrates a charge pump and comparators to
> +   enable a system with an integrated USB OTG dual-role transceiver to
> +   function as an USB OTG dual-role device.
> +
>  config EXTCON_MAX77693
>   tristate "Maxim MAX77693 EXTCON Support"
>   depends on MFD_MAX77693 && INPUT
> Index: extcon/drivers/extcon/Makefile
> ===
> --- extcon.orig/drivers/extcon/Makefile
> +++ extcon/drivers/extcon/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)  += extcon-a
>  

[PATCH 8/8 v5] thermal: trip_point_temp_store() calls thermal_zone_device_update()

[Kuninori Morimoto]

From: Kuninori Morimoto 

trip_point_temp_store() updates trip temperature. It should call
thermal_zone_device_update() immediately.

Signed-off-by: Kuninori Morimoto 
---
v4 -> v5

 - implemented on thermal_core.c

 drivers/thermal/thermal_core.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index d9e525c..768fb10 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -676,8 +676,12 @@ trip_point_temp_store(struct device *dev, struct 
device_attribute *attr,
return -EINVAL;
 
ret = tz->ops->set_trip_temp(tz, trip, temperature);
+   if (ret)
+   return ret;
 
-   return ret ? ret : count;
+   thermal_zone_device_update(tz);
+
+   return count;
 }
 
 static ssize_t
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] p1010rdb:update dts for pcie interrupt-map

[Zhao Qiang]

p1010rdb use the irq[4:5] for inta and intb to pcie,
it is active-high, so set it.

Signed-off-by: Zhao Qiang 
---
 arch/powerpc/boot/dts/fsl/p1010rdb.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi 
b/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
index 0f0ced6..14b6295 100644
--- a/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
@@ -215,3 +215,19 @@
phy-connection-type = "sgmii";
};
 };
+
+ {
+   pcie@0 {
+   interrupt-map = <
+   /* IDSEL 0x0 */
+   /*
+*irq[4:5] are active-high
+*irq[6:7] are active-low
+*/
+    0x0 0x0 0x1  0x4 0x2 0x0 0x0
+    0x0 0x0 0x2  0x5 0x2 0x0 0x0
+    0x0 0x0 0x3  0x6 0x1 0x0 0x0
+    0x0 0x0 0x4  0x7 0x1 0x0 0x0
+   >;
+   };
+};
-- 
2.1.0.27.g96db324

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/8 v4] thermal: rcar: retern error rcar_thermal_get_temp() if no ctemp update

[Kuninori Morimoto]

Hi Eduardo

> > --- a/drivers/thermal/rcar_thermal.c
> > +++ b/drivers/thermal/rcar_thermal.c
> > @@ -199,9 +199,9 @@ static int rcar_thermal_update_temp(struct 
> > rcar_thermal_priv *priv)
> >  
> > dev_dbg(dev, "thermal%d  %d -> %d\n", priv->id, priv->ctemp, ctemp);
> >  
> > -   priv->ctemp = ctemp;
> > ret = 0;
> >  err_out_unlock:
> > +   priv->ctemp = ctemp;
> > mutex_unlock(>lock);
> > return ret;
> 
> I believe the problem here is actually the lack of error
> handling/propagation. Are you sure you want to write to parameter
> in the fail path ?
> 
> rcar_thermal_update_temp already returns error code when it fails
> to read temperature. Don't you think it would make more sense to fix the
> places that call rcar_thermal_update_temp to properly handle its return
> value and propagate that error code when necessary?

Thanks. But the logic is that
priv->ctemp will be 0 in error cases, and it will be reported as
dev_err() in rcar_thermal_get_current_temp()

The problem was that priv->ctemp will not be updated
in error case of rcar_thermal_update_temp().
but user can call get_temp (it doesn't call
rcar_thermal_update_temp() if interrupt was supported).
In such case, user will get old thermal.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/8 v5] thermal: rcar: rcar_thermal_get_temp() return error if strange temp

[Kuninori Morimoto]

From: Kuninori Morimoto 

Signed-off-by: Kuninori Morimoto 
---
v4 -> v5

 - rcar_thermal_update_temp() has no change
 - "retern" -> "return" on Subject

 drivers/thermal/rcar_thermal.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index e9e4e39..30602f2 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -203,6 +203,7 @@ err_out_unlock:
 static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
 {
struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
+   int tmp;
int ret;
 
ret = rcar_thermal_update_temp(priv);
@@ -210,9 +211,18 @@ static int rcar_thermal_get_temp(struct 
thermal_zone_device *zone, int *temp)
return ret;
 
mutex_lock(>lock);
-   *temp =  MCELSIUS((priv->ctemp * 5) - 65);
+   tmp =  MCELSIUS((priv->ctemp * 5) - 65);
mutex_unlock(>lock);
 
+   if ((tmp < MCELSIUS(-45)) || (tmp > MCELSIUS(125))) {
+   struct device *dev = rcar_priv_to_dev(priv);
+
+   dev_err(dev, "it couldn't measure temperature correctly\n");
+   return -EIO;
+   }
+
+   *temp = tmp;
+
return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/8 v5] ARM: shmobile: r8a7790: enable to use thermal-zone

[Kuninori Morimoto]

From: Kuninori Morimoto 

This patch enables to use thermal-zone on r8a7790.
This thermal sensor can measure temperature from -4 to 125000,
but over 117000 can be critical on this chip.
Thus, default critical temperature is now set as 115000 (this driver
is using 5000 steps) (Current critical temperature is using it as
9, but there is no big reason about it)

And it doesn't check thermal zone periodically (same as current
behavior). You can exchange it by modifying polling-delay[-passive]
property.

You can set trip temp if your kernel has CONFIG_THERMAL_WRITABLE_TRIPS,
but you need to take care to use it, since it will call
orderly_poweroff() it it reaches to the value.
echo $temp > /sys/class/thermal/thermal_zone0/trip_point_0_temp

Signed-off-by: Kuninori Morimoto 
---
v4 -> v5

 - no change

 arch/arm/boot/dts/r8a7790.dtsi | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 9f3036b..2203b97 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -112,6 +112,25 @@
};
};
 
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   polling-delay-passive   = <0>;
+   polling-delay   = <0>;
+
+   thermal-sensors = <>;
+
+   trips {
+   cpu-crit {
+   temperature = <115000>;
+   hysteresis  = <0>;
+   type= "critical";
+   };
+   };
+   cooling-maps {
+   };
+   };
+   };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
@@ -202,12 +221,15 @@
power-domains = <_clocks>;
};
 
-   thermal@e61f {
-   compatible = "renesas,thermal-r8a7790", "renesas,rcar-thermal";
+   thermal: thermal@e61f {
+   compatible ="renesas,thermal-r8a7790",
+   "renesas,rcar-gen2-thermal",
+   "renesas,rcar-thermal";
reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7790_CLK_THERMAL>;
power-domains = <_clocks>;
+   #thermal-sensor-cells = <0>;
};
 
timer {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/8 v5] thermal: rcar: enable to use thermal-zone on DT

[Kuninori Morimoto]

From: Kuninori Morimoto 

This patch enables to use thermal-zone on DT if it was call as
"renesas,rcar-thermal-gen2".
Previous style is still supported by "renesas,rcar-thermal".

Signed-off-by: Kuninori Morimoto 
---
v4 -> v5

 - "115" -> "115000" on rcar-thermal.txt


 .../devicetree/bindings/thermal/rcar-thermal.txt   | 37 +-
 drivers/thermal/rcar_thermal.c | 45 +++---
 2 files changed, 75 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt 
b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
index 332e625..e5ee3f1 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
@@ -1,8 +1,9 @@
 * Renesas R-Car Thermal
 
 Required properties:
-- compatible   : "renesas,thermal-", "renesas,rcar-thermal"
- as fallback.
+- compatible   : "renesas,thermal-",
+  "renesas,rcar-gen2-thermal" (with thermal-zone) or
+  "renesas,rcar-thermal" (without thermal-zone) as 
fallback.
  Examples with soctypes are:
- "renesas,thermal-r8a73a4" (R-Mobile APE6)
- "renesas,thermal-r8a7779" (R-Car H1)
@@ -36,3 +37,35 @@ thermal@e61f {
0xe61f0300 0x38>;
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
 };
+
+Example (with thermal-zone):
+
+thermal-zones {
+   cpu_thermal: cpu-thermal {
+   polling-delay-passive   = <1000>;
+   polling-delay   = <5000>;
+
+   thermal-sensors = <>;
+
+   trips {
+   cpu-crit {
+   temperature = <115000>;
+   hysteresis  = <0>;
+   type= "critical";
+   };
+   };
+   cooling-maps {
+   };
+   };
+};
+
+thermal: thermal@e61f {
+   compatible ="renesas,thermal-r8a7790",
+   "renesas,rcar-gen2-thermal",
+   "renesas,rcar-thermal";
+   reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
+   interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <_clks R8A7790_CLK_THERMAL>;
+   power-domains = <_clocks>;
+   #thermal-sensor-cells = <0>;
+};
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 30602f2..e92f29b 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -75,8 +76,10 @@ struct rcar_thermal_priv {
 #define rcar_has_irq_support(priv) ((priv)->common->base)
 #define rcar_id_to_shift(priv) ((priv)->id * 8)
 
+#define USE_OF_THERMAL 1
 static const struct of_device_id rcar_thermal_dt_ids[] = {
{ .compatible = "renesas,rcar-thermal", },
+   { .compatible = "renesas,rcar-gen2-thermal", .data = (void 
*)USE_OF_THERMAL },
{},
 };
 MODULE_DEVICE_TABLE(of, rcar_thermal_dt_ids);
@@ -200,9 +203,9 @@ err_out_unlock:
return ret;
 }
 
-static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
+static int rcar_thermal_get_current_temp(struct rcar_thermal_priv *priv,
+int *temp)
 {
-   struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
int tmp;
int ret;
 
@@ -226,6 +229,20 @@ static int rcar_thermal_get_temp(struct 
thermal_zone_device *zone, int *temp)
return 0;
 }
 
+static int rcar_thermal_of_get_temp(void *data, int *temp)
+{
+   struct rcar_thermal_priv *priv = data;
+
+   return rcar_thermal_get_current_temp(priv, temp);
+}
+
+static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
+{
+   struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
+
+   return rcar_thermal_get_current_temp(priv, temp);
+}
+
 static int rcar_thermal_get_trip_type(struct thermal_zone_device *zone,
  int trip, enum thermal_trip_type *type)
 {
@@ -282,6 +299,10 @@ static int rcar_thermal_notify(struct thermal_zone_device 
*zone,
return 0;
 }
 
+static const struct thermal_zone_of_device_ops rcar_thermal_zone_of_ops = {
+   .get_temp   = rcar_thermal_of_get_temp,
+};
+
 static struct thermal_zone_device_ops rcar_thermal_zone_ops = {
.get_temp   = rcar_thermal_get_temp,
.get_trip_type  = rcar_thermal_get_trip_type,
@@ -318,14 +339,20 @@ static void rcar_thermal_work(struct work_struct *work)
 
priv = container_of(work, struct rcar_thermal_priv, work.work);
 
-   rcar_thermal_get_temp(priv->zone, );
+   ret = rcar_thermal_get_current_temp(priv, );
+   if (ret < 0)
+   

[PATCH 7/8 v5] ARM: shmobile: r8a7791: enable to use thermal-zone

[Kuninori Morimoto]

From: Kuninori Morimoto 

This patch enables to use thermal-zone on r8a7791.
This thermal sensor can measure temperature from -4 to 125000,
but over 117000 can be critical on this chip.
Thus, default critical temperature is now set as 115000 (this driver
is using 5000 steps) (Current critical temperature is using it as
9, but there is no big reason about it)

And it doesn't check thermal zone periodically (same as current
behavior). You can exchange it by modifying polling-delay[-passive]
property.

You can set trip temp if your kernel has CONFIG_THERMAL_WRITABLE_TRIPS,
but you need to take care to use it, since it will call
orderly_poweroff() it it reaches to the value.
echo $temp > /sys/class/thermal/thermal_zone0/trip_point_0_temp

Signed-off-by: Kuninori Morimoto 
---
v4 -> v5

 - no change

 arch/arm/boot/dts/r8a7791.dtsi | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 3776974..9b37c80 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -69,6 +69,25 @@
};
};
 
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   polling-delay-passive   = <0>;
+   polling-delay   = <0>;
+
+   thermal-sensors = <>;
+
+   trips {
+   cpu-crit {
+   temperature = <115000>;
+   hysteresis  = <0>;
+   type= "critical";
+   };
+   };
+   cooling-maps {
+   };
+   };
+   };
+
gic: interrupt-controller@f1001000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
@@ -185,12 +204,15 @@
power-domains = <_clocks>;
};
 
-   thermal@e61f {
-   compatible = "renesas,thermal-r8a7791", "renesas,rcar-thermal";
+   thermal: thermal@e61f {
+   compatible ="renesas,thermal-r8a7791",
+   "renesas,rcar-gen2-thermal",
+   "renesas,rcar-thermal";
reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
clocks = <_clks R8A7791_CLK_THERMAL>;
power-domains = <_clocks>;
+   #thermal-sensor-cells = <0>;
};
 
timer {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] dts/ls2080a: Update PCIe compatible

[Scott Wood]

On Mon, 2015-12-14 at 20:01 -0600, Hu Mingkai-B21284 wrote:
> 
> > -Original Message-
> > From: Hu Mingkai-B21284
> > Sent: Monday, December 07, 2015 4:44 PM
> > To: 'Rob Herring'
> > Cc: a...@kernel.org; devicetree@vger.kernel.org; Li Yang-Leo-R58472;
> > linux-arm-ker...@lists.infradead.org; Lian Minghuan-B31939
> > Subject: RE: [PATCH v2] dts/ls2080a: Update PCIe compatible
> > 
> > 
> > 
> > > -Original Message-
> > > From: Rob Herring [mailto:r...@kernel.org]
> > > Sent: Saturday, December 05, 2015 12:23 AM
> > > To: Hu Mingkai-B21284
> > > Cc: a...@kernel.org; devicetree@vger.kernel.org; Li Yang-Leo-R58472;
> > > linux-arm-ker...@lists.infradead.org; Lian Minghuan-B31939
> > > Subject: Re: [PATCH v2] dts/ls2080a: Update PCIe compatible
> > > 
> > > On Fri, Dec 04, 2015 at 06:20:17PM +0800, Mingkai Hu wrote:
> > > > From: Minghuan Lian 
> > > > 
> > > > The patch adds LS2085a to PCIe compatible to fix the compatibility
> > > > issue when using firmware with LS2085a compatible property.
> > > > 
> > > > Signed-off-by: Minghuan Lian 
> > > > Signed-off-by: Mingkai Hu 
> > > > ---
> > > > v2 change:
> > > >  - Rebased to latest kernel base
> > > 
> > > How about implementing my comments on v1, too?
> > > 
> > 
> > Hi Rob,
> > 
> > Do you mean to change the combinations in layerscape-pci.txt as follows?
> > 
> > > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > @@ -15,6 +15,7 @@ Required properties:
> > >  - compatible: should contain the platform identifier such as:
> > >  "fsl,ls1021a-pcie", "snps,dw-pcie"
> > > -"fsl,ls2080a-pcie", "snps,dw-pcie"
> > > +"fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie"
> > 
> > 
> > And the ls2085a was released first, but the dts file is for ls2080a (fsl-
> > ls2080a.dtsi), So I prefer to put the ls2080a as the first compatible
> > string. How about your suggestion?
> > 
> 
> Hi Rob,
> 
> I will keep the "fsl,ls2085a-pcie" as the first compatible string as
> discussed.

Do you mean "fsl,ls2080a-pcie"?

-Scott

> And change the layerscape-pci.txt as follows:
> 
> > > -"fsl,ls2080a-pcie", "snps,dw-pcie"
> > > +"fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie"
> 
> What's your suggestion?

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 20/20] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3

[Krzysztof Kozlowski]

On 14.12.2015 15:38, Chanwoo Choi wrote:
> THis patch adds the bus device tree nodes for both MIF (Memory) and INT
> (Internal) block to enable the bus frequency.
> 
> The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
> bus is parent device in INT block using VDD_INT.
> 
> Signed-off-by: Chanwoo Choi 
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon 
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47 
> +
>  arch/arm/boot/dts/exynos4412-trats2.dts | 47 
> +
>  2 files changed, 94 insertions(+)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4 12/16] Documentation: DT: bindings: Add power domain info for NVIDIA PMC

[Kevin Hilman]

Jon Hunter  writes:

> On 08/12/15 19:07, Kevin Hilman wrote:
>> Jon Hunter  writes:
>> 
>>> Add power-domain binding documentation for the NVIDIA PMC driver in
>>> order to support generic power-domains.
>>>
>>> Signed-off-by: Jon Hunter 
>>>
>>> ---
>>>
>>> Please note that I have been debating whether I add this
>>> "nvidia,powergate-clock-disable" property or just leave the clocks
>>> disabled by default. Some downstream kernels leave the clocks enabled
>>> for the audio power-domain because the clocks required for powering up
>>> the power-domain are needed by all modules within the power-domain.
>>> However are the same time there are other power-domains that may need
>>> to be on, but not always clocked and so having the ability to specify if
>>> the clocks should be disabled seems useful. However, I can also remove
>>> this and just have the appropriate devices turn on the clocks as well.
>>> ---
>>>  .../bindings/arm/tegra/nvidia,tegra20-pmc.txt  | 61 
>>> ++
>>>  1 file changed, 61 insertions(+)
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt 
>>> b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>> index 838e1a69ec0a..8e4641db51a9 100644
>>> --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>> +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>> @@ -1,5 +1,7 @@
>>>  NVIDIA Tegra Power Management Controller (PMC)
>>>  
>>> +== Power Management Controller Node ==
>>> +
>>>  The PMC block interacts with an external Power Management Unit. The PMC
>>>  mostly controls the entry and exit of the system from different sleep
>>>  modes. It provides power-gating controllers for SoC and CPU power-islands.
>>> @@ -69,6 +71,10 @@ Optional properties for hardware-triggered thermal reset 
>>> (inside 'i2c-thermtrip'
>>>   Defaults to 0. Valid values are described in section 
>>> 12.5.2
>>>   "Pinmux Support" of the Tegra4 Technical Reference 
>>> Manual.
>>>  
>>> +Optional nodes:
>>> +- pm-domains : This node contains a hierarchy of PM domain nodes, which 
>>> should
>>> +  match the power-domains on the Tegra SoC.
>>> +
>>>  Example:
>>>  
>>>  / SoC dts including file
>>> @@ -114,3 +120,58 @@ pmc@7000f400 {
>>> };
>>> ...
>>>  };
>>> +
>>> +
>>> +== PM Domain Nodes ==
>>> +
>>> +Each of the PM domain nodes represents a power-domain on the Tegra SoC
>>> +that can be power-gated by the PMC and should be named appropriately.
>>> +
>>> +Required properties:
>>> +  - clocks: Must contain an entry for each clock required by the PMC for
>>> +controlling a power-gate. See ../clocks/clock-bindings.txt for details.
>> 
>> We've had this discussiona for a couple of other SoCs, so I need to
>> ask...
>> 
>> Presumably these are not device clocks that a runtime PM enabled driver
>> should be managing for a device, right?  IOW, We want to make sure that the
>> PM domain isn't managing clocks for drivers that should be doing it.
>> 
>> I understand there are legitimate reasons for the PM domain to manage
>> clocks in addition to device drivers (e.g. for synchronous reset), but
>> just want to be sure it's not a shortcut for having a proper driver.
>
> So some clocks may also be used by devices, but they are needed as part
> of the power ungating/gating sequence. The general power-up sequence for
> tegra is ...
>
> 1. Enable the power-domain
> 2. Enable the clock(s)
> 3. Remove signal clamps
> 4. De-assert reset(s)
> 5. Disable clocks (optional)
>
> You may say we should only handle #1 above for the powering up sequence,
> but we can't do this. The reason is that there is one bit for each
> power-domain that controls the signaling clamps and so we need to turn
> on all the clocks specified in the TRM before we do this. Once we have
> done this and released the reset(s), we can then disable the clocks
> again (shown above an optional as it is not mandatory from a design
> perspective) and then the devices in the power-domain should enable the
> clocks they need as and when they want them.

Thanks for the clarification, that's what I expected and similar to what
I've seen on other SoCs.  I just wanted to be sure that the power-domain
clk managent was "in addition" to the device drivers, not "instead of."

Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/8 v5] enable to use thermal-zone on r8a7790/1

[Kuninori Morimoto]

Hi

These are v5 of thermal-zone support for r8a7790/r8a7791.

Kuninori Morimoto (8):
  1) thermal: rcar: move rcar_thermal_dt_ids to upside
  2) thermal: rcar: check every rcar_thermal_update_temp() return value
  3) thermal: rcar: check irq possibility in rcar_thermal_irq_xxx()
  4) thermal: rcar: rcar_thermal_get_temp() return error if strange temp
  5) thermal: rcar: enable to use thermal-zone on DT
  6) ARM: shmobile: r8a7790: enable to use thermal-zone
  7) ARM: shmobile: r8a7791: enable to use thermal-zone
  8) thermal: of-thermal: of_thermal_set_trip_temp() call 
thermal_zone_device_update()

 Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 37 
+++--
 arch/arm/boot/dts/r8a7790.dtsi | 26 
--
 arch/arm/boot/dts/r8a7791.dtsi | 26 
--
 drivers/thermal/of-thermal.c   |  2 ++
 drivers/thermal/rcar_thermal.c | 96 
+++-
 5 files changed, 160 insertions(+), 27 deletions(-)

Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v14 0/7] fpga area and fpga bridge framework

[Alan Tull]

On Mon, Dec 14, 2015 at 11:16 AM, Moritz Fischer
 wrote:
> Hi Alan,
>
> On Thu, Dec 10, 2015 at 3:37 PM,   wrote:
>> From: Alan Tull 
>>
>> For v14 I'm dropping the concept of "simple-fpga-bus" for "fpga-area"
>> with reworked bindings.
>
> I had an offline discussion with Josh Cartwright about his concerns.
> He brought up a good
> point on w.r.t to the way FPGA Area (Bus) deals with things.
>
> Currently we only support complete status = "okay" vs "disabled" kind
> of overlays.
>
> If now you have say a UART in the FPGA that you don't want to go away
> and come back on reload,
> we don't have a good way of expressing this.

Maybe i don't understand what you are saying; could you write out a
sequence you want to be able to do?

If you want suspend/resume functionality that would reload the FPGA
after a suspend powers off the FPGA, that would be simple to add to
the FPGA area code and it wasn't a hack at all.

> Is there a good way to
> express non-mmio FPGA devices?

Is this a separate question/issue from the above?  Are you talking
about acceleration?

>
> I've been toying around with hacking up struct device to include a
> FPGA 'domain', and then, similar
> to power domains allow devices to register suspend() / resume() style
> callbacks (could call them pre_reload() or something like that ...)
>
> I haven't gotten around to think it through. At this point it's just
> an idea and I don't have real code to show.
>
> I realize the issue with that is we'd have to make changes to struct device.

That's interesting.  Usually a FPGA image has many devices in it, so
so way of making that dependency clear would be needed.  If any of the
devices involved are powered up, that FPGA image would need to be
loaded.

Currently I'm trying to get some bindings approved for doing device
tree control of loading the FPGA and probing the devices.  My idea is
that these bindings could be useful for some use cases where we are
loading hardware onto the FPGA that needs to show up in the device
tree. Some of Rob's feedback is that my proposal may be
Altera-specific. If the bindings that I am proposing are useful for at
least some uses with Xilinx parts, that would be valuable feedback at
this point.  If they are Altera-specific, then I may need to add
"altr," to some of the compatible strings like "altr,fpga-bus" and
"altr,fpga-area".  My original intent was to implement something that
you could use also, so I hope that's not the future here.

So my question for you is: is this stuff useful for you?

Alan Tull

>
> Cheers,
>
> Moritz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/4] ARM: dts: lpc18xx: add EEPROM memory node

[Srinivas Kandagatla]

Hi Joachim,

Could you take this DT patches via your tree, I picked up the nvmem patches.

thanks,
srini


On 17/11/15 20:02, Ariel D'Alessandro wrote:

Add node for the NXP LPC18xx EEPROM memory which can be found in
NXP LPC185x/3x and LPC435x/3x/2x/1x devices.

Signed-off-by: Ariel D'Alessandro 
---
  arch/arm/boot/dts/lpc18xx.dtsi | 12 
  1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 52591d8..43e99cf 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -166,6 +166,18 @@
status = "disabled";
};

+   eeprom: eeprom@4000e000 {
+   compatible = "nxp,lpc1857-eeprom";
+   reg =   <0x4000e000 0x1000>,
+   <0x2004 0x4000>;
+   reg-names = "reg", "mem";
+   clocks = < CLK_CPU_EEPROM>;
+   clock-names = "eeprom";
+   resets = < 27>;
+   interrupts = <4>;
+   status = "disabled";
+   };
+
mac: ethernet@4001 {
compatible = "nxp,lpc1850-dwmac", "snps,dwmac-3.611", 
"snps,dwmac";
reg = <0x4001 0x2000>;


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/7] mtd: partitions: add of_match_table support

[Geert Uytterhoeven]

Hi Brian,

On Sat, Dec 12, 2015 at 2:33 AM, Brian Norris
 wrote:
> On Fri, Dec 11, 2015 at 09:44:37AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Dec 10, 2015 at 9:54 PM, Brian Norris
>>  wrote:
>> > IOW, I wouldn't expect MBR or GPT to work well on large raw NAND flash,
>> > and so I don't plan to do that sort of work myself. If you can provide
>> > some better argument for it, and some nice maintainable code to go with
>> > it, then of course it could be considered :)
>>
>> There's also NOR FLASH (e.g. SPI-NOR), which is what most boards I'm
>> working on have.
>
> OK. But these flash are often used for the boot firmware, no? And then,
> does the boot code have to be provided at one end of the flash (e.g.,
> bottom)? If so, then something like MBR or GPT will likely not apply,
> since they reserve the first (and sometimes last) blocks of the medium.

If the boot firmware is in the first few blocks, Amiga RDB or BSD disklabel
come to the rescue...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/5] soc: rockchip: add reboot notifier driver

[Arnd Bergmann]

On Wednesday 18 November 2015 17:56:22 Andy Yan wrote:
> rockchip platform have a protocol to pass the kernel reboot
> mode to bootloader by some special registers when system reboot.
> By this way the bootloader can take different action according
> to the different kernel reboot mode, for example, command
> "reboot loader" will reboot the board to rockusb mode, this is
> a very convenient way to get the board enter download mode.
> 
> Signed-off-by: Andy Yan 

Adding John Stultz to Cc

I just saw this thread pop up again, and had to think of John's recent
patch to unify this across platforms.

John, can you have a look at this driver too, and see how it fits in?
I think this is yet another variant, using an MMIO register rather than
RAM (as HTC / NVIDIA does) or SRAM (as Qualcomm does), but otherwise
it conceptually fits in with what you had.

The driver goes through an existing syscon regmap as far as I can
tell, rather than a memory area or its own device.

Arnd

> ---
> 
> Changes in v3:
>  - move from mach-rockchip to drivers/soc/rockchip, as the tegra does
>  - use dts pass the related register
> 
> Changes in v2:
>   - check cpu dt node
>   - remove a unnecessary of_put_node in function rockchip_get_pmu_regmap
>   - fix a align issue
>   - use reboot_notifier instead of restart_handler
> 
>  drivers/soc/rockchip/Kconfig  |  7 
>  drivers/soc/rockchip/Makefile |  1 +
>  drivers/soc/rockchip/loader.h | 22 ++
>  drivers/soc/rockchip/reboot.c | 98 
> +++
>  4 files changed, 128 insertions(+)
>  create mode 100644 drivers/soc/rockchip/loader.h
>  create mode 100644 drivers/soc/rockchip/reboot.c
> 
> diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
> index 7140ff8..4edbc44 100644
> --- a/drivers/soc/rockchip/Kconfig
> +++ b/drivers/soc/rockchip/Kconfig
> @@ -15,4 +15,11 @@ config ROCKCHIP_PM_DOMAINS
>  
>If unsure, say N.
>  
> +config ROCKCHIP_REBOOT
> + bool "Rockchip reboot notifier driver"
> + help
> +   Say y here will enable reboot notifier support.
> +   This will get reboot mode arguments from userspace and
> +   store it in special register.
> +
>  endif
> diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
> index 3d73d06..9817496 100644
> --- a/drivers/soc/rockchip/Makefile
> +++ b/drivers/soc/rockchip/Makefile
> @@ -2,3 +2,4 @@
>  # Rockchip Soc drivers
>  #
>  obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o
> +obj-$(CONFIG_ROCKCHIP_REBOOT) += reboot.o
> diff --git a/drivers/soc/rockchip/loader.h b/drivers/soc/rockchip/loader.h
> new file mode 100644
> index 000..bf51baa
> --- /dev/null
> +++ b/drivers/soc/rockchip/loader.h
> @@ -0,0 +1,22 @@
> +#ifndef __MACH_ROCKCHIP_LOADER_H
> +#define __MACH_ROCKCHIP_LOADER_H
> +
> +/*high 24 bits is tag, low 8 bits is type*/
> +#define SYS_LOADER_REBOOT_FLAG   0x5242C300
> +
> +enum {
> + BOOT_NORMAL = 0, /* normal boot */
> + BOOT_LOADER, /* enter loader rockusb mode */
> + BOOT_MASKROM,/* enter maskrom rockusb mode (not support now) */
> + BOOT_RECOVER,/* enter recover */
> + BOOT_NORECOVER,  /* do not enter recover */
> + BOOT_SECONDOS,   /* boot second OS (not support now)*/
> + BOOT_WIPEDATA,   /* enter recover and wipe data. */
> + BOOT_WIPEALL,/* enter recover and wipe all data. */
> + BOOT_CHECKIMG,   /* check firmware img with backup part*/
> + BOOT_FASTBOOT,   /* enter fast boot mode */
> + BOOT_SECUREBOOT_DISABLE,
> + BOOT_CHARGING,   /* enter charge mode */
> + BOOT_MAX /* MAX VALID BOOT TYPE.*/
> +};
> +#endif
> diff --git a/drivers/soc/rockchip/reboot.c b/drivers/soc/rockchip/reboot.c
> new file mode 100644
> index 000..048aeb0b
> --- /dev/null
> +++ b/drivers/soc/rockchip/reboot.c
> @@ -0,0 +1,98 @@
> +/*
> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "loader.h"
> +
> +struct rockchip_reboot {
> + struct device *dev;
> + struct regmap *map;
> + u32 offset;
> + struct notifier_block reboot_notifier;
> +};
> +
> +static void rockchip_get_reboot_flag(const char *cmd, u32 *flag)
> +{
> + *flag = SYS_LOADER_REBOOT_FLAG + BOOT_NORMAL;
> +
> + if (cmd) {
> + if (!strcmp(cmd, "loader") || !strcmp(cmd, "bootloader"))
> + *flag = SYS_LOADER_REBOOT_FLAG + BOOT_LOADER;
> + else if (!strcmp(cmd, "recovery"))
> + *flag = SYS_LOADER_REBOOT_FLAG + BOOT_RECOVER;
> + else if (!strcmp(cmd, "charge"))

Re: [PATCH v2 0/7] Exynos: MFC driver: reserved memory cleanup and IOMMU support

[Marek Szyprowski]

Hello,

On 2015-12-13 20:52, Laurent Pinchart wrote:

Hi Marek,

Thank you for the patches.

On Wednesday 09 December 2015 14:58:15 Marek Szyprowski wrote:

Hello,

This patchset finally perform cleanup of custom code in s5p-mfc codec
driver. The first part is removal of custom, driver specific code for
intializing and handling of reserved memory. Instead, a generic code for
reserved memory regions is used.

Should you update the reserved memory bindings documentation
(Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) to
document usage of the memory-region-names property ?


Okay, I will update documentation as well.


Then, once it is done, the proper setup
of DMA parameters (max segment size) is applied for all multimedia
devices found on Exynos SoCs to let them properly handle shared buffers
mapped into contiguous DMA address space. The last patch adds support
for IOMMU to MFC driver. Some additional code is needed because of
specific requirements of MFC device firmware (see patch 7 for more
details). When no IOMMU is available, the code fallbacks to generic
reserved memory regions.

After applying this patchset, MFC device works correctly when IOMMU is
either enabled or disabled.

Patches have been tested on top of linux-next from 20151207. I would
prefer to merge patches 1-2 via Samsung tree and patches 3-7 via media
tree (there are no compile-time dependencies between patches 1-2 and
3-7). Patches have been tested on Odroid U3 (Exynos 4412 based) and
Odroid XU3 (Exynos 5422 based) boards.

Best regards
Marek Szyprowski
Samsung R Institute Poland


Changelog:
v2:
- reworked of_reserved_mem_init* functions on request from Rob Herring,
   added separate index and name based selection of reserved region
- adapted for of_reserved_mem_init* related changes

v1: https://www.mail-archive.com/linux-media@vger.kernel.org/msg94100.html
- initial version of another approach for this problem, rewrote driver code
   for new reserved memory bindings, which finally have been merged some
   time ago

v0:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/189259.ht
ml - old patchset solving the same problem, abandoned due to other tasks and
long time of merging reserved memory bindings and support code for it

Patch summary:

Marek Szyprowski (7):
   ARM: Exynos: convert MFC device to generic reserved memory bindings
   ARM: dts: exynos4412-odroid*: enable MFC device
   of: reserved_mem: add support for named reserved mem nodes
   media: vb2-dma-contig: add helper for setting dma max seg size
   media: set proper max seg size for devices on Exynos SoCs
   media: s5p-mfc: replace custom reserved memory init code with generic
 one
   media: s5p-mfc: add iommu support

  .../devicetree/bindings/media/s5p-mfc.txt  |  16 +--
  arch/arm/boot/dts/exynos4210-origen.dts|  22 ++-
  arch/arm/boot/dts/exynos4210-smdkv310.dts  |  22 ++-
  arch/arm/boot/dts/exynos4412-odroid-common.dtsi|  24 
  arch/arm/boot/dts/exynos4412-origen.dts|  22 ++-
  arch/arm/boot/dts/exynos4412-smdk4412.dts  |  22 ++-
  arch/arm/boot/dts/exynos5250-arndale.dts   |  22 ++-
  arch/arm/boot/dts/exynos5250-smdk5250.dts  |  22 ++-
  arch/arm/boot/dts/exynos5250-spring.dts|  22 ++-
  arch/arm/boot/dts/exynos5420-arndale-octa.dts  |  22 ++-
  arch/arm/boot/dts/exynos5420-smdk5420.dts  |  22 ++-
  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  22 ++-
  arch/arm/mach-exynos/Makefile  |   2 -
  arch/arm/mach-exynos/exynos.c  |  19 ---
  arch/arm/mach-exynos/mfc.h |  16 ---
  arch/arm/mach-exynos/s5p-dev-mfc.c |  94 -
  drivers/media/platform/exynos-gsc/gsc-core.c   |   1 +
  drivers/media/platform/exynos4-is/fimc-core.c  |   1 +
  drivers/media/platform/exynos4-is/fimc-is.c|   1 +
  drivers/media/platform/exynos4-is/fimc-lite.c  |   1 +
  drivers/media/platform/s5p-g2d/g2d.c   |   1 +
  drivers/media/platform/s5p-jpeg/jpeg-core.c|   1 +
  drivers/media/platform/s5p-mfc/s5p_mfc.c   | 153 ++
  drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h |  79 +++
  drivers/media/platform/s5p-tv/mixer_video.c|   1 +
  drivers/media/v4l2-core/videobuf2-dma-contig.c |  15 ++
  drivers/of/of_reserved_mem.c   | 104 +++---
  include/linux/of_reserved_mem.h|  31 -
  include/media/videobuf2-dma-contig.h   |   1 +
  29 files changed, 533 insertions(+), 248 deletions(-)
  delete mode 100644 arch/arm/mach-exynos/mfc.h
  delete mode 100644 arch/arm/mach-exynos/s5p-dev-mfc.c
  create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to 

Re: [PATCH v2 1/2] Documentation: DT: Add entry for ARM SP805-WDT

[Bhupesh SHARMA]

On Mon, Dec 14, 2015 at 6:36 AM, Rob Herring  wrote:
> On Fri, Dec 11, 2015 at 05:17:46PM +0530, Bhupesh Sharma wrote:
>> This patch adds a devicetree binding documentation for ARM's
>> SP805 WatchDog Timer.
>>
>> Signed-off-by: Bhupesh Sharma 
>> ---
>>  .../devicetree/bindings/watchdog/sp805-wdt.txt |   29 
>> 
>>  1 file changed, 29 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>
>> diff --git a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt 
>> b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>> new file mode 100644
>> index 000..45b5afc
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>> @@ -0,0 +1,29 @@
>> +* ARM SP805 Watchdog Timer (WDT) Controller
>> +
>> +SP805 WDT is a ARM Primecell Peripheral and has a standard-id register that
>> +can be used to identify the peripheral type, vendor, and revision.
>> +This value can be used for driver matching.
>> +
>> +As SP805 WDT is a primecell IP, it follows the base bindings specified in
>> +'arm/primecell.txt'
>> +
>> +Required properties:
>> +- compatible : Should be "arm,sp805-wdt", "arm,primecell"
>> +- reg : Base address and size of the watchdog timer registers.
>> +- clocks : From common clock binding.
>> +   First clock is PCLK and the second is WDOGCLK.
>> +   WDOGCLK can be equal to or be a sub-multiple of the PCLK 
>> frequency.
>> +- clock-names : From common clock binding. Shall be "apb_pclk" for first 
>> clock.
>
> And for the 2nd clock?

Right. Although the current amba driver framework and the sp805_wdt
driver doesn't handle
the 2nd clock correctly, the documentation should specify the 2nd
clock properly.
Does the name "wdog_clk" seems appropriate for the same?

>> +
>> +Optional properties:
>> +- interrupts : Should specify WDT interrupt number.
>> +
>> +Examples:
>> +
>> + cluster1_core0_watchdog: wdt@c00 {
>> + compatible = "arm,sp805-wdt", "arm,primecell";
>> + reg = <0x0 0xc00 0x0 0x1000>;
>> + clocks = < 4 3>, < 4 3>;
>> + clock-names = "apb_pclk", "wdog_clk";
>> + };
>> +
>> --
>> 1.7.9.5
>>
>>

Regards,
Bhupesh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/8] dt-bindings: Add a binding for Mediatek Video Encoder

[Matthias Brugger]

On 14/12/15 09:26, tiffany lin wrote:

On Fri, 2015-12-11 at 11:29 -0600, Rob Herring wrote:

On Fri, Dec 11, 2015 at 05:55:39PM +0800, Tiffany Lin wrote:

Add a DT binding documentation of Video Encoder for the
MT8173 SoC from Mediatek.

Signed-off-by: Tiffany Lin 


A question and minor issue below, otherwise:

Acked-by: Rob Herring 


---
  .../devicetree/bindings/media/mediatek-vcodec.txt  |   58 
  1 file changed, 58 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt 
b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
new file mode 100644
index 000..510cd81
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -0,0 +1,58 @@
+Mediatek Video Codec
+
+Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
+supports high resolution encoding functionalities.
+
+Required properties:
+- compatible : "mediatek,mt8173-vcodec-enc" for encoder
+- reg : Physical base address of the video codec registers and length of
+  memory mapped region.
+- interrupts : interrupt number to the cpu.
+- mediatek,larb : must contain the local arbiters in the current Socs.


This looks strange, shouldn't it be "larb" instead of "mediatek,larb".
At least the example does not use the mediatek prefix.


+- clocks : list of clock specifiers, corresponding to entries in
+  the clock-names property;
+- clock-names: must contain "vencpll", "venc_lt_sel", "vcodecpll_370p5_ck"
+- iommus : list of iommus specifiers should be enabled for hw encode.
+  There are 2 cells needed to enable/disable iommu.
+  The first one is local arbiter index(larbid), and the other is port
+  index(portid) within local arbiter. Specifies the larbid and portid
+  as defined in dt-binding/memory/mt8173-larb-port.h.
+- mediatek,vpu : the node of video processor unit


Same here.

Regards,
Matthias


+
+Example:
+vcodec_enc: vcodec@0x18002000 {
+compatible = "mediatek,mt8173-vcodec-enc";
+reg = <0 0x18002000 0 0x1000>,/*VENC_SYS*/
+  <0 0x19002000 0 0x1000>;/*VENC_LT_SYS*/
+interrupts = ,
+   ;
+larb = <>,
+   <>;
+iommus = < M4U_LARB3_ID M4U_PORT_VENC_RCPU>,


Is this the same iommu as the VPU? If so, you can't have a mixed number
of cells.

Yes, its same iommus as the VPU.
Now we use two parameters for iommus.
We will fix this in next version.


+ < M4U_LARB3_ID M4U_PORT_VENC_REC>,
+ < M4U_LARB3_ID M4U_PORT_VENC_BSDMA>,
+ < M4U_LARB3_ID M4U_PORT_VENC_SV_COMV>,
+ < M4U_LARB3_ID M4U_PORT_VENC_RD_COMV>,
+ < M4U_LARB3_ID M4U_PORT_VENC_CUR_LUMA>,
+ < M4U_LARB3_ID M4U_PORT_VENC_CUR_CHROMA>,
+ < M4U_LARB3_ID M4U_PORT_VENC_REF_LUMA>,
+ < M4U_LARB3_ID M4U_PORT_VENC_REF_CHROMA>,
+ < M4U_LARB3_ID M4U_PORT_VENC_NBM_RDMA>,
+ < M4U_LARB3_ID M4U_PORT_VENC_NBM_WDMA>,
+ < M4U_LARB5_ID M4U_PORT_VENC_RCPU_SET2>,
+ < M4U_LARB5_ID M4U_PORT_VENC_REC_FRM_SET2>,
+ < M4U_LARB5_ID M4U_PORT_VENC_BSDMA_SET2>,
+ < M4U_LARB5_ID M4U_PORT_VENC_SV_COMA_SET2>,
+ < M4U_LARB5_ID M4U_PORT_VENC_RD_COMA_SET2>,
+ < M4U_LARB5_ID M4U_PORT_VENC_CUR_LUMA_SET2>,
+ < M4U_LARB5_ID M4U_PORT_VENC_CUR_CHROMA_SET2>,
+ < M4U_LARB5_ID M4U_PORT_VENC_REF_LUMA_SET2>,
+ < M4U_LARB5_ID M4U_PORT_VENC_REC_CHROMA_SET2>;
+vpu = <>;


Need to update the example.

Sorry, I didn't get it.
Do you means update VPU binding document "media/mediatek-vpu.txt"?




+clocks = < CLK_APMIXED_VENCPLL>,
+ < CLK_TOP_VENC_LT_SEL>,
+ < CLK_TOP_VCODECPLL_370P5>;
+clock-names = "vencpll",
+  "venc_lt_sel",
+  "vcodecpll_370p5_ck";
+  };
--
1.7.9.5





--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] mfd: arizona: Update binding docs for selecting mono/stereo outputs

[Charles Keepax]

On Fri, Dec 11, 2015 at 11:33:53AM -0600, Rob Herring wrote:
> On Fri, Dec 11, 2015 at 10:28:23AM +, Charles Keepax wrote:
> > Update the device tree binding documentation to include the wlf,out-mono
> > property that is used to specify whether each output is a mono or stereo
> > output.
> 
> You just added this binding and updating it already? While we may like 
> kernel changes incremental, we don't like bindings evolving any more 
> than necessary.

The binding has been around for ages I have been working through
updating it to actually include more of the functionality of the
driver. The last set of changes where some initial work on the
jack detection, this is a fairly self contained update that
doesn't really relate to the jack detection.

Its a fairly complex part so there is going to be quite a lot to
the binding. I have basically been upstreaming them as much as
possible in groups of similar functionality, as I have time to
work on them.  I could try save the changes up out of tree and
collect together into much larger chains, if you felt strongly
about it? But I am not really clear that helps much. As I have to
hang on to much more out of tree code, people using the part have
to wait longer to have access to useful bindings in mainline and
it makes the CC lists much longer so everyone needs to look at
more email than they need to.

>  
> > Signed-off-by: Charles Keepax 
> > ---
> >  Documentation/devicetree/bindings/mfd/arizona.txt | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
> > b/Documentation/devicetree/bindings/mfd/arizona.txt
> > index 2b6ccdb..489dd07 100644
> > --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> > @@ -65,6 +65,10 @@ Optional properties:
> >  that have not been specified are set to 0 by default. Entries are:
> >   (wm5102, wm5110, wm8280, wm8997)
> >   (wm8998, wm1814)
> > +  - wlf,out-mono : A boolean indicating whether each output is mono or 
> > stereo.
> > +A non-zero value indicates a mono output. If present, the number of 
> > values
> > +should be less than or equal to the number of outputs, if less values 
> > are
> > +supplied the additional outputs will be treated as stereo.
> 
> How do you know which outputs are which with a variable number? 

Position in the array (ie. first entry is the first output, and
so on). I will respin to update the comment to make this more
clear.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 12/12] ARM: dts: imx6: add Vivante GPU nodes

[Lucas Stach]

Am Freitag, den 11.12.2015, 15:02 +0800 schrieb Shawn Guo:
> On Fri, Dec 04, 2015 at 03:00:04PM +0100, Lucas Stach wrote:
> > This adds the device nodes for 2D, 3D and VG GPU cores.
> > 
> > Signed-off-by: Russell King 
> > Signed-off-by: Lucas Stach 
> > ---
> >  arch/arm/boot/dts/imx6dl.dtsi  |  5 +
> >  arch/arm/boot/dts/imx6q.dtsi   | 15 +++
> >  arch/arm/boot/dts/imx6qdl.dtsi | 22 ++
> >  3 files changed, 42 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> > index 4b0ec0703825..51c517a5cafd 100644
> > --- a/arch/arm/boot/dts/imx6dl.dtsi
> > +++ b/arch/arm/boot/dts/imx6dl.dtsi
> > @@ -104,6 +104,11 @@
> > compatible = "fsl,imx-display-subsystem";
> > ports = <_di0>, <_di1>;
> > };
> > +
> > +   gpu-subsystem {
> > +   compatible = "fsl,imx-gpu-subsystem";
> > +   cores = <_2d>, <_3d>;
> > +   };
> >  };
> >  
> >   {
> > diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> > index 399103b8e2c9..77d618b2870c 100644
> > --- a/arch/arm/boot/dts/imx6q.dtsi
> > +++ b/arch/arm/boot/dts/imx6q.dtsi
> > @@ -153,6 +153,16 @@
> > status = "disabled";
> > };
> >  
> > +   gpu_vg: gpu@02204000 {
> > +   compatible = "vivante,gc";
> > +   reg = <0x02204000 0x4000>;
> > +   interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
> > +   clocks = < IMX6QDL_CLK_OPENVG_AXI>,
> > +< IMX6QDL_CLK_GPU2D_CORE>;
> > +   clock-names = "bus", "core";
> > +   power-domains = < 1>;
> 
> Shouldn't property 'power-domains' be mentioned a bit in bindings doc?
> 
Hm, it's a standard property, so I don't know if it's required. But OTOH
it doesn't hurt to have it, so will add that.

> > +   };
> > +
> > ipu2: ipu@0280 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > @@ -225,6 +235,11 @@
> > compatible = "fsl,imx-display-subsystem";
> > ports = <_di0>, <_di1>, <_di0>, <_di1>;
> > };
> > +
> > +   gpu-subsystem {
> > +   compatible = "fsl,imx-gpu-subsystem";
> > +   cores = <_2d>, <_3d>, <_vg>;
> > +   };
> >  };
> >  
> >   {
> > diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> > index 2b6cc8bf3c5c..018975b867e1 100644
> > --- a/arch/arm/boot/dts/imx6qdl.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> > @@ -119,6 +119,28 @@
> > status = "disabled";
> > };
> >  
> > +
> > +   gpu_2d: gpu@00134000 {
> > +   compatible = "vivante,gc";
> > +   reg = <0x00134000 0x4000>;
> > +   interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
> > +   clocks = < IMX6QDL_CLK_GPU2D_AXI>,
> > +< IMX6QDL_CLK_GPU2D_CORE>;
> > +   clock-names = "bus", "core";
> > +   power-domains = < 1>;
> > +   };
> > +
> > +   gpu_3d: gpu@0013 {
> > +   compatible = "vivante,gc";
> > +   reg = <0x0013 0x4000>;
> > +   interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
> > +   clocks = < IMX6QDL_CLK_GPU3D_AXI>,
> > +< IMX6QDL_CLK_GPU3D_CORE>,
> > +< IMX6QDL_CLK_GPU3D_SHADER>;
> > +   clock-names = "bus", "core", "shader";
> > +   power-domains = < 1>;
> > +   };
> > +
> 
> Please keep these added nodes sorted in unit-address.
> 
Urgh, right.

Are you okay with merging the DT changes through the DRM tree, or do you
want to pick them separate?

Regards,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

[Geert Uytterhoeven]

On Sat, Dec 12, 2015 at 6:51 AM, David Gibson
 wrote:
> On Thu, Dec 10, 2015 at 12:43:24PM -0800, Brian Norris wrote:
>> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
>> > On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
>> > > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
>> > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>> > > >  wrote:
>> > >
>> > > >> +
>> > > >> +Examples:
>> > > >> +
>> > > >> +flash@0 {
>> > > >> +   partitions {
>> > > >> +   compatible = "google,fmap";
>> > > >> +   };
>> > > >> +};
>> > > >
>> > > > I wonder if this wouldn't be better served in a separate binding doc
>> > > > with its compatible name as the filename, like we do with
>> > > > driver^Whardware blocks, especially if we want to add more parsers.
>> > >
>> > >
>> > > I find that *very* counter productive for bindings that go to the same
>> > > node. You have a description of a node, and then suddenly there you
>> > > have another file with another description of the same node. Totally
>> > > awesome.
>> >
>> > I can't actually work out from that if you're agreeing with the
>> > original post or the first reply.
>>
>> Perhaps I'm biased, but I think he was agreeing with the first reply.
>> (Particularly, "I find that *very* counter productive" uses the word
>> "that" to refer to "separate binding doc[s]".)
>>
>> > > Also how do you plan to write partitioning schemes with parameters
>> > > like with non-zero offset of the partition table.
>>
>> If you are directing this question at me: I don't have a specific plan
>> for it. MTD parsers don't currently take external input for this; many
>> scan the whole device, but some might also have conventions built into
>> the parser itself too, so this just gets hooked based on "compatible".
>> But if the need arose, I would hope we could work out a common binding.
>>
>> > Presumably with properties in the patitions node.  Not seeing the
>> > problem here.
>>
>> I believe Michal is bringing up the (important, IMO) point that if
>> distinct partition types are being described in the same node, then any
>> use of additional properties *must* be closely coordinated. We can't
>> have two parsers "foo" and "bar" defining conflicting uses of the same
>> property in the same node, like this:
>>
>>   partitions {
>>   compatible = "foo", "bar";
>>   property-baz = ...; // e.g., reg = <...>;
>>   };
>>
>> where if "foo" is not found, we fall back to "bar". But what if "foo"
>> and "bar" use "property-baz" differently?
>
> Ah.. that is an excellent point, and leads me to realise that using
> compatible in this way is wrong.  The whole point of compatible is
> that the node is, well, compatible with *all* the things in the list,
> and therefore the things in the list are compatible with each other.
>
> Using it for a list of entirely different things to attempt in order
> is not correct.

Isn't the idea behind a partition table that all partition information is
stored on the device in a well-known format, so you don't need additional
properties?

If the only property needed is the partition table offset, it can be encoded
in the unit-address, and the "reg" property:

partitions {

partition-table@ {
reg = <0 ...>;
...
};

...
};

If you do need additional properties, you'll have to add separate partition
table nodes.
Where? Outside the "partitions" subnode?
What with multiple partition tables
  - some needing properties (outside "partitions"),
  - others not (outside/inside "partitions"),
  - others needing the offset (inside "partitions"?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver

[Fabio Estevam]

Hi Peter,

On Mon, Dec 14, 2015 at 5:26 AM, Peter Chen  wrote:

> Hi all,
>
> There is a known issue that the USB code can't handle USB HUB's
> external pins well, in that case, it may cause some onboard
> USB HUBs can't work since their PHY's clock or reset pin needs to
> operate.
>
> The user reported this issue at below:
> http://www.spinics.net/lists/linux-usb/msg131502.html
>
> In this patch set, I add a generic onboard USB HUB driver to
> handle this problem, the external signals will be configured
> before usb controller's initialization, it much likes we did
> it at board code before.
>
> The user needs to add this generic hub node at dts to support it.
>
> @The udoo users, help to test please.

This is what I get with your series applied:

[2.288300] usb 1-1: device descriptor read/64, error -71
[2.518083] usb 1-1: new full-speed USB device number 3 using ci_hdrc
[2.738078] usb 1-1: device descriptor read/64, error -71
[3.058078] usb 1-1: device descriptor read/64, error -71
[3.288079] usb 1-1: new full-speed USB device number 4 using ci_hdrc
[3.768069] usb 1-1: device not accepting address 4, error -71
[3.888084] usb 1-1: new full-speed USB device number 5 using ci_hdrc
[4.368067] usb 1-1: device not accepting address 5, error -71
[4.374117] usb usb1-port1: unable to enumerate USB device
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 5/8] iio: adc: fsl,imx25-gcq driver

[Markus Pargmann]

Hi,

On Saturday 12 December 2015 17:14:24 Jonathan Cameron wrote:
> On 06/12/15 19:52, Markus Pargmann wrote:
> > This is a conversion queue driver for the mx25 SoC. It uses the central
> > ADC which is used by two seperate independent queues. This driver
> > prepares different conversion configurations for each possible input.
> > For a conversion it creates a conversionqueue of one item with the
> conversion queue
> > correct configuration for the chosen channel. It then executes the queue
> > once and disables the conversion queue afterwards.
> > 
> > The reference voltages are configurable through devicetree subnodes,
> > depending on the connections of the ADC inputs.
> > 
> > Signed-off-by: Markus Pargmann 
> > Signed-off-by: Denis Carikli 
> A couple of little bits inline.  Fix the return of 0 on fail in probe
> and you can add

Thanks, I fixed all your comments for the next version.

Best Regards,

Markus

> 
> Acked-by: Jonathan Cameron 
> > ---
> > 
> > Notes:
> > Changes in v7:
> >  - Remove separate functions mx25_gcq_disable/enable_eoq() as they were 
> > used at
> >only one position
> >  - Enforce an external reference regulator if one of the conversions 
> > uses it as
> >reference. The devm_regulator_get() call was moved into
> >mx25_gcq_setup_cfgs() to be able to acquire the reference regulator 
> > when
> >necessary.
> >  - Store indio_dev as platform driver data instead of the private data. 
> > This
> >was changed in probe() and remove().
> > 
> > Changes in v6:
> >  - Added defines for a complete list of references in the dt binding 
> > macros
> > 
> >  drivers/iio/adc/Kconfig |   7 +
> >  drivers/iio/adc/Makefile|   1 +
> >  drivers/iio/adc/fsl-imx25-gcq.c | 415 
> > 
> >  3 files changed, 423 insertions(+)
> >  create mode 100644 drivers/iio/adc/fsl-imx25-gcq.c
> > 
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 7868c744fd4b..73145c53ec2c 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -183,6 +183,13 @@ config EXYNOS_ADC
> >   To compile this driver as a module, choose M here: the module will be
> >   called exynos_adc.
> >  
> > +config FSL_MX25_ADC
> > +   tristate "Freescale MX25 ADC driver"
> > +   depends on MFD_MX25_TSADC
> > +   help
> > + Generic Conversion Queue driver used for general purpose ADC in the
> > + MX25. This driver supports single measurements using the MX25 ADC.
> > +
> >  config HI8435
> > tristate "Holt Integrated Circuits HI-8435 threshold detector"
> > select IIO_TRIGGERED_EVENT
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index 99b37a963a1e..2fe9b78e4b02 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -19,6 +19,7 @@ obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
> >  obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
> >  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
> >  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
> > +obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
> >  obj-$(CONFIG_HI8435) += hi8435.o
> >  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> >  obj-$(CONFIG_MAX1027) += max1027.o
> > diff --git a/drivers/iio/adc/fsl-imx25-gcq.c 
> > b/drivers/iio/adc/fsl-imx25-gcq.c
> > new file mode 100644
> > index ..eb9570876291
> > --- /dev/null
> > +++ b/drivers/iio/adc/fsl-imx25-gcq.c
> > @@ -0,0 +1,415 @@
> > +/*
> > + * Copyright (C) 2014-2015 Pengutronix, Markus Pargmann 
> > 
> > + *
> > + * This program is free software; you can redistribute it and/or modify it 
> > under
> > + * the terms of the GNU General Public License version 2 as published by 
> > the
> > + * Free Software Foundation.
> > + *
> > + * This is the driver for the imx25 GCQ (Generic Conversion Queue)
> > + * connected to the imx25 ADC.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define MX25_GCQ_TIMEOUT (msecs_to_jiffies(2000))
> > +
> > +static const char * const driver_name = "mx25-gcq";
> > +
> > +enum mx25_gcq_cfgs {
> > +   MX25_CFG_XP = 0,
> > +   MX25_CFG_YP,
> > +   MX25_CFG_XN,
> > +   MX25_CFG_YN,
> > +   MX25_CFG_WIPER,
> > +   MX25_CFG_INAUX0,
> > +   MX25_CFG_INAUX1,
> > +   MX25_CFG_INAUX2,
> > +   MX25_NUM_CFGS,
> > +};
> > +
> > +struct mx25_gcq_priv {
> > +   struct regmap *regs;
> > +   struct completion completed;
> > +   struct clk *clk;
> > +   int irq;
> > +   struct regulator *vref[4];
> > +   u32 channel_vref_mv[MX25_NUM_CFGS];
> > +};
> > +
> > +#define MX25_CQG_CHAN(chan, id) {\
> > +   .type = IIO_VOLTAGE,\
> > +   .indexed = 1,\
> > +   .channel = chan,\
> > +   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> > + BIT(IIO_CHAN_INFO_SCALE),\
> > +   

Re: [PATCH v4 05/20] PM / devfreq: Add new passive governor

[MyungJoo Ham]

>   
>  This patch adds the new passive governor for DEVFREQ framework. The following
> governors are already present and used for DVFS (Dynamic Voltage and Frequency
> Scaling) drivers. The following governors are independently used for one 
> device
> driver which don't give the influence to other device drviers and also don't
> receive the effect from other device drivers.
> - ondemand / performance / powersave / userspace
> 
> The passive governor depends on operation of parent driver with specific
> governos extremely and is not able to decide the new frequency by oneself.
> According to the decided new frequency of parent driver with governor,
> the passive governor uses it to decide the appropriate frequency for own
> device driver. The passive governor must need the following information
> from device tree:
> - the source clock and OPP tables
> - the instance of parent device
> 
> For exameple,
> there are one more devfreq device drivers which need to change their source
> clock according to their utilization on runtime. But, they share the same
> power line (e.g., regulator). So, specific device driver is operated as parent
> with ondemand governor and then the rest device driver with passive governor
> is influenced by parent device.
> 
> Suggested-by: Myungjoo Ham 
> Signed-off-by: Chanwoo Choi 
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon 
> ---
>  drivers/devfreq/Kconfig|   9 
>  drivers/devfreq/Makefile   |   1 +
>  drivers/devfreq/devfreq.c  |  47 
>  drivers/devfreq/governor_passive.c | 108 
> +
>  include/linux/devfreq.h|  15 ++
>  5 files changed, 180 insertions(+)
>  create mode 100644 drivers/devfreq/governor_passive.c
> 
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 55ec774f794c..d03f635a93e1 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -64,6 +64,15 @@ config DEVFREQ_GOV_USERSPACE
> Otherwise, the governor does not change the frequnecy
> given at the initialization.
>  
> +config DEVFREQ_GOV_PASSIVE
> + tristate "Passive"
> + help
> +   Sets the frequency by other governors (simple_ondemand, performance,
> +   powersave, usersapce) of a parent devfreq device. This governor
> +   always has the dependency on the chosen frequency from paired
> +   governor. This governor does not change the frequency by oneself
> +   through sysfs entry.

Sets the frequency based on the frequency of its parent devfreq
device. This governor does not change the frequency by itself
through sysfs entries.

> +
>  comment "DEVFREQ Drivers"
>  
>  config ARM_EXYNOS_BUS_DEVFREQ
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 375ebbb4fcfb..f81c313b4b79 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
[]
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 984c5e9e7bdd..15e58779e4c0 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -190,6 +190,31 @@ static struct devfreq_governor 
> *find_devfreq_governor(const char *name)
>  
>  /* Load monitoring helper functions for governors use */
>  
> +static int update_devfreq_passive(struct devfreq *devfreq, unsigned long 
> freq)
> +{
> + struct devfreq *passive;
> + unsigned long rate;
> + int ret;
> +
> + list_for_each_entry(passive, >passive_dev_list, passive_node) {
> + if (!passive->governor)
> + continue;
> + rate = freq;
> +
> + ret = passive->governor->get_target_freq(passive, );
> + if (ret)
> + return ret;
> +
> + ret = passive->profile->target(passive->dev.parent, , 0);
> + if (ret)
> + return ret;
> +
> + passive->previous_freq = rate;
> + }
> +
> + return 0;
> +}
> +
>  /**
>   * update_devfreq() - Reevaluate the device and configure frequency.
>   * @devfreq: the devfreq instance.
> @@ -233,10 +258,18 @@ int update_devfreq(struct devfreq *devfreq)
>   flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
>   }
>  
> + if (!list_empty(>passive_dev_list)
> + && devfreq->previous_freq > freq)
> + update_devfreq_passive(devfreq, freq);
> +

Could you please comment somewhere appropriate
that the dependent is going to be changed
before its parent if the frequency is going down.
(and after if going up)
And state why as well.

And, is this viable universally?

>   err = devfreq->profile->target(devfreq->dev.parent, , flags);
>   if (err)
>   return err;
>  
> + if (!list_empty(>passive_dev_list)
> + && devfreq->previous_freq < freq)
> + update_devfreq_passive(devfreq, freq);
> +
>   if 

Re: [PATCH v4 06/20] PM / devfreq: Add devfreq_get_devfreq_by_phandle()

[MyungJoo Ham]

>   
>  This patch adds the new devfreq_get_devfreq_by_phandle() OF helper function
> which can find the instance of devfreq device by using phandle ("devfreq").
> 
> Signed-off-by: Chanwoo Choi 
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon 

Signed-off-by: MyungJoo Ham 

> ---
>  drivers/devfreq/devfreq.c | 44 
>  include/linux/devfreq.h   |  9 +
>  2 files changed, 53 insertions(+)
> 

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

[Geert Uytterhoeven]

On Sat, Dec 12, 2015 at 6:51 AM, David Gibson
 wrote:
> On Thu, Dec 10, 2015 at 12:43:24PM -0800, Brian Norris wrote:
>> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
>> > On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
>> > > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
>> > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>> > > >  wrote:
>> > >
>> > > >> +
>> > > >> +Examples:
>> > > >> +
>> > > >> +flash@0 {
>> > > >> +   partitions {
>> > > >> +   compatible = "google,fmap";
>> > > >> +   };
>> > > >> +};
>> > > >
>> > > > I wonder if this wouldn't be better served in a separate binding doc
>> > > > with its compatible name as the filename, like we do with
>> > > > driver^Whardware blocks, especially if we want to add more parsers.
>> > >
>> > >
>> > > I find that *very* counter productive for bindings that go to the same
>> > > node. You have a description of a node, and then suddenly there you
>> > > have another file with another description of the same node. Totally
>> > > awesome.
>> >
>> > I can't actually work out from that if you're agreeing with the
>> > original post or the first reply.
>>
>> Perhaps I'm biased, but I think he was agreeing with the first reply.
>> (Particularly, "I find that *very* counter productive" uses the word
>> "that" to refer to "separate binding doc[s]".)
>>
>> > > Also how do you plan to write partitioning schemes with parameters
>> > > like with non-zero offset of the partition table.
>>
>> If you are directing this question at me: I don't have a specific plan
>> for it. MTD parsers don't currently take external input for this; many
>> scan the whole device, but some might also have conventions built into
>> the parser itself too, so this just gets hooked based on "compatible".
>> But if the need arose, I would hope we could work out a common binding.
>>
>> > Presumably with properties in the patitions node.  Not seeing the
>> > problem here.
>>
>> I believe Michal is bringing up the (important, IMO) point that if
>> distinct partition types are being described in the same node, then any
>> use of additional properties *must* be closely coordinated. We can't
>> have two parsers "foo" and "bar" defining conflicting uses of the same
>> property in the same node, like this:
>>
>>   partitions {
>>   compatible = "foo", "bar";
>>   property-baz = ...; // e.g., reg = <...>;
>>   };
>>
>> where if "foo" is not found, we fall back to "bar". But what if "foo"
>> and "bar" use "property-baz" differently?
>
> Ah.. that is an excellent point, and leads me to realise that using
> compatible in this way is wrong.  The whole point of compatible is
> that the node is, well, compatible with *all* the things in the list,
> and therefore the things in the list are compatible with each other.
>
> Using it for a list of entirely different things to attempt in order
> is not correct.

Isn't the idea behind a partition table that all partition information is
stored on the device in a well-known format, so you don't need additional
properties?

If the only property needed is the partition table offset, it can be encoded
in the unit-address, and the "reg" property:

partitions {

partition-table@ {
reg = <0 ...>;
...
};

...
};

If you do need additional properties, you'll have to add separate partition
table nodes.
Where? Outside the "partitions" subnode?
What with multiple partition tables
  - some needing properties (outside "partitions"),
  - others not (outside/inside "partitions"),
  - others needing the offset (inside "partitions"?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] extcon: arizona: Update device tree binding for mic detect configurations

[Charles Keepax]

Update the device tree binding documentation to include documentation for
the wlf,micd-configs property that is used to specify the configurations
for headset polarity detection (CTIA / OTMP).

Signed-off-by: Charles Keepax 
Acked-by: Rob Herring 
---

No changes since v1.

Thanks,
Charles

 Documentation/devicetree/bindings/extcon/extcon-arizona.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt 
b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
index 238e10e..fd9b898 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
@@ -37,5 +37,13 @@ Optional properties:
 milliseconds.
   - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
 detection.
+  - wlf,micd-configs : Headset polarity configurations (generally used for
+detection of CTIA / OMTP headsets), the field can be of variable length
+but should always be a multiple of 3 cells long, each three cell group
+represents one polarity configuration.
+The first cell defines the accessory detection pin, zero will use MICDET1
+and all other values will use MICDET2.
+The second cell represents the MICBIAS to be used.
+The third cell represents the value of the micd-pol-gpio pin.
 
   - wlf,gpsw : Settings for the general purpose switch
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] extcon: arizona: Add device bindings for the micd configurations

[Charles Keepax]

Add device bindings to support configuring the jack detection
configurations. Each configuration needs to specify the connection of
the mic det pins, which micbias should be used and the value of the
micd polarity GPIO required to activate that configuration.

Signed-off-by: Charles Keepax 
Acked-by: Chanwoo Choi 
---

Changes since v1:
 - Report error from arizona_extcon_get_micd_configs

Thanks,
Charles

 drivers/extcon/extcon-arizona.c | 56 +++--
 1 file changed, 54 insertions(+), 2 deletions(-)

diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 8647533..c121d01 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1201,10 +1201,58 @@ static void arizona_micd_set_level(struct arizona 
*arizona, int index,
regmap_update_bits(arizona->regmap, reg, mask, level);
 }
 
-static int arizona_extcon_device_get_pdata(struct arizona *arizona)
+static int arizona_extcon_get_micd_configs(struct device *dev,
+  struct arizona *arizona)
+{
+   const char * const prop = "wlf,micd-configs";
+   const int entries_per_config = 3;
+   struct arizona_micd_config *micd_configs;
+   int nconfs, ret;
+   int i, j;
+   u32 *vals;
+
+   nconfs = device_property_read_u32_array(arizona->dev, prop, NULL, 0);
+   if (nconfs <= 0)
+   return 0;
+
+   vals = kcalloc(nconfs, sizeof(u32), GFP_KERNEL);
+   if (!vals)
+   return -ENOMEM;
+
+   ret = device_property_read_u32_array(arizona->dev, prop, vals, nconfs);
+   if (ret < 0)
+   goto out;
+
+   nconfs /= entries_per_config;
+
+   micd_configs = devm_kzalloc(dev,
+   nconfs * sizeof(struct arizona_micd_range),
+   GFP_KERNEL);
+   if (!micd_configs) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   for (i = 0, j = 0; i < nconfs; ++i) {
+   micd_configs[i].src = vals[j++] ? ARIZONA_ACCDET_SRC : 0;
+   micd_configs[i].bias = vals[j++];
+   micd_configs[i].gpio = vals[j++];
+   }
+
+   arizona->pdata.micd_configs = micd_configs;
+   arizona->pdata.num_micd_configs = nconfs;
+
+out:
+   kfree(vals);
+   return ret;
+}
+
+static int arizona_extcon_device_get_pdata(struct device *dev,
+  struct arizona *arizona)
 {
struct arizona_pdata *pdata = >pdata;
unsigned int val = ARIZONA_ACCDET_MODE_HPL;
+   int ret;
 
device_property_read_u32(arizona->dev, "wlf,hpdet-channel", );
switch (val) {
@@ -1249,6 +1297,10 @@ static int arizona_extcon_device_get_pdata(struct 
arizona *arizona)
pdata->jd_gpio5_nopull = device_property_read_bool(arizona->dev,
"wlf,use-jd2-nopull");
 
+   ret = arizona_extcon_get_micd_configs(dev, arizona);
+   if (ret < 0)
+   dev_err(arizona->dev, "Failed to read micd configs: %d\n", ret);
+
return 0;
 }
 
@@ -1270,7 +1322,7 @@ static int arizona_extcon_probe(struct platform_device 
*pdev)
return -ENOMEM;
 
if (!dev_get_platdata(arizona->dev))
-   arizona_extcon_device_get_pdata(arizona);
+   arizona_extcon_device_get_pdata(>dev, arizona);
 
info->micvdd = devm_regulator_get(>dev, "MICVDD");
if (IS_ERR(info->micvdd)) {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] extcon: arizona: Add DT binding examples

[Charles Keepax]

Add an example for all elements of the Arizona extcon device tree
binding.

Signed-off-by: Charles Keepax 
---
 .../devicetree/bindings/extcon/extcon-arizona.txt  | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt 
b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
index fd9b898..e27341f 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
@@ -47,3 +47,29 @@ Optional properties:
 The third cell represents the value of the micd-pol-gpio pin.
 
   - wlf,gpsw : Settings for the general purpose switch
+
+Example:
+
+codec: wm8280@0 {
+   compatible = "wlf,wm8280";
+   reg = <0>;
+   ...
+
+   wlf,use-jd2;
+   wlf,use-jd2-nopull;
+   wlf,jd-invert;
+
+   wlf,micd-software-compare;
+   wlf,micd-detect-debounce = <0>;
+   wlf,micd-pol-gpio = < 2 0>;
+   wlf,micd-rate = ;
+   wlf,micd-dbtime = <4>;
+   wlf,micd-timeout-ms = <100>;
+   wlf,micd-force-micbias;
+   wlf,micd-configs = <
+   0 1 0 /* MICDET1 MICBIAS1 GPIO=low */
+   1 2 1 /* MICDET2 MICBIAS2 GPIO=high */
+   >;
+
+   wlf,gpsw = <0>;
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

[Michal Suchanek]

On 14 December 2015 at 11:22, Geert Uytterhoeven  wrote:
> On Sat, Dec 12, 2015 at 6:51 AM, David Gibson
>  wrote:
>> On Thu, Dec 10, 2015 at 12:43:24PM -0800, Brian Norris wrote:
>>> On Mon, Dec 07, 2015 at 12:36:28PM +1100, David Gibson wrote:
>>> > On Sat, Dec 05, 2015 at 10:33:30PM +0100, Michal Suchanek wrote:
>>> > > On 5 December 2015 at 12:39, Jonas Gorski  wrote:
>>> > > > On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
>>> > > >  wrote:
>>> > >
>>> > > >> +
>>> > > >> +Examples:
>>> > > >> +
>>> > > >> +flash@0 {
>>> > > >> +   partitions {
>>> > > >> +   compatible = "google,fmap";
>>> > > >> +   };
>>> > > >> +};
>>> > > >
>>> > > > I wonder if this wouldn't be better served in a separate binding doc
>>> > > > with its compatible name as the filename, like we do with
>>> > > > driver^Whardware blocks, especially if we want to add more parsers.
>>> > >
>>> > >
>>> > > I find that *very* counter productive for bindings that go to the same
>>> > > node. You have a description of a node, and then suddenly there you
>>> > > have another file with another description of the same node. Totally
>>> > > awesome.
>>> >
>>> > I can't actually work out from that if you're agreeing with the
>>> > original post or the first reply.
>>>
>>> Perhaps I'm biased, but I think he was agreeing with the first reply.
>>> (Particularly, "I find that *very* counter productive" uses the word
>>> "that" to refer to "separate binding doc[s]".)
>>>
>>> > > Also how do you plan to write partitioning schemes with parameters
>>> > > like with non-zero offset of the partition table.
>>>
>>> If you are directing this question at me: I don't have a specific plan
>>> for it. MTD parsers don't currently take external input for this; many
>>> scan the whole device, but some might also have conventions built into
>>> the parser itself too, so this just gets hooked based on "compatible".
>>> But if the need arose, I would hope we could work out a common binding.
>>>
>>> > Presumably with properties in the patitions node.  Not seeing the
>>> > problem here.
>>>
>>> I believe Michal is bringing up the (important, IMO) point that if
>>> distinct partition types are being described in the same node, then any
>>> use of additional properties *must* be closely coordinated. We can't
>>> have two parsers "foo" and "bar" defining conflicting uses of the same
>>> property in the same node, like this:
>>>
>>>   partitions {
>>>   compatible = "foo", "bar";
>>>   property-baz = ...; // e.g., reg = <...>;
>>>   };
>>>
>>> where if "foo" is not found, we fall back to "bar". But what if "foo"
>>> and "bar" use "property-baz" differently?
>>
>> Ah.. that is an excellent point, and leads me to realise that using
>> compatible in this way is wrong.  The whole point of compatible is
>> that the node is, well, compatible with *all* the things in the list,
>> and therefore the things in the list are compatible with each other.
>>
>> Using it for a list of entirely different things to attempt in order
>> is not correct.
>
> Isn't the idea behind a partition table that all partition information is
> stored on the device in a well-known format, so you don't need additional
> properties?
>
> If the only property needed is the partition table offset, it can be encoded
> in the unit-address, and the "reg" property:
>
> partitions {
>
> partition-table@ {
> reg = <0 ...>;
> ...
> };
>
> ...
> };
>
> If you do need additional properties, you'll have to add separate partition
> table nodes.
> Where? Outside the "partitions" subnode?
> What with multiple partition tables
>   - some needing properties (outside "partitions"),
>   - others not (outside/inside "partitions"),
>   - others needing the offset (inside "partitions"?

Hello,

IIRC there is RedBoot on-flash partition format support in kernel
which has the partition table offset as compile time configuration
parameter. Moving this to DT would make unified kernel for boards with
different RedBoot table offsets possible.

I don't use any board with RedBoot so I would not know if there is
other issue preventing such unified kernel.

It might be an actual use case for both the binding and the extra
argument with current partitioning scheme, though.

Thanks

Michal
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/7] media: vb2-dma-contig: add helper for setting dma max seg size

[Marek Szyprowski]

Hello,

On 2015-12-13 20:57, Laurent Pinchart wrote:

Hi Marek,

Thank you for the patch.

On Wednesday 09 December 2015 14:58:19 Marek Szyprowski wrote:

Add a helper function for device drivers to set DMA's max_seg_size.
Setting it to largest possible value lets DMA-mapping API always create
contiguous mappings in DMA address space. This is essential for all
devices, which use dma-contig videobuf2 memory allocator and shared
buffers.

Signed-off-by: Marek Szyprowski 
---
  drivers/media/v4l2-core/videobuf2-dma-contig.c | 15 +++
  include/media/videobuf2-dma-contig.h   |  1 +
  2 files changed, 16 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c index c331272..628518d
100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -742,6 +742,21 @@ void vb2_dma_contig_cleanup_ctx(void *alloc_ctx)
  }
  EXPORT_SYMBOL_GPL(vb2_dma_contig_cleanup_ctx);

+int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size)
+{
+   if (!dev->dma_parms) {

When can this function be called with dev->dma_parms not NULL ?


When one loads a module with multimedia driver (which calls this 
function), then

unloads and loads it again. It is rather safe to have this check.


+   dev->dma_parms = devm_kzalloc(dev, sizeof(dev->dma_parms),
+ GFP_KERNEL);
+   if (!dev->dma_parms)
+   return -ENOMEM;
+   }
+   if (dma_get_max_seg_size(dev) < size)
+   return dma_set_max_seg_size(dev, size);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(vb2_dma_contig_set_max_seg_size);
+
  MODULE_DESCRIPTION("DMA-contig memory handling routines for videobuf2");
  MODULE_AUTHOR("Pawel Osciak ");
  MODULE_LICENSE("GPL");
diff --git a/include/media/videobuf2-dma-contig.h
b/include/media/videobuf2-dma-contig.h index c33dfa6..0e6ba64 100644
--- a/include/media/videobuf2-dma-contig.h
+++ b/include/media/videobuf2-dma-contig.h
@@ -26,6 +26,7 @@ vb2_dma_contig_plane_dma_addr(struct vb2_buffer *vb,
unsigned int plane_no)

  void *vb2_dma_contig_init_ctx(struct device *dev);
  void vb2_dma_contig_cleanup_ctx(void *alloc_ctx);
+int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size);

  extern const struct vb2_mem_ops vb2_dma_contig_memops;


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 07/20] PM / devfreq: Show the related information according to governor type

[MyungJoo Ham]

>   
>  This patch modifies the following sysfs entry of DEVFREQ framework
> because the devfreq device using passive governor don't need the same
> information of the devfreq device using rest governor.
> - polling_interval: passive gov don't use the sampling rate.
> - available_governors : passive gov don't be changed on runtime in this 
> version.
> - trans_stat  : passive governor don't support trans_stat in this 
> version.
> 
> Signed-off-by: Chanwoo Choi 
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon 

You have a major update that is not mendtioned in the commit message.
(add governor "type")

> ---
>  drivers/devfreq/devfreq.c | 31 
> +--
>  drivers/devfreq/governor.h|  7 +++
>  drivers/devfreq/governor_passive.c|  1 +
>  drivers/devfreq/governor_performance.c|  1 +
>  drivers/devfreq/governor_powersave.c  |  1 +
>  drivers/devfreq/governor_simpleondemand.c |  1 +
>  drivers/devfreq/governor_userspace.c  |  1 +
>  include/linux/devfreq.h   |  2 ++
>  8 files changed, 39 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 78ea4cdaa82c..18ad956fec93 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -597,7 +597,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
>   goto err_init;
>   }
>  
> - if (!strncmp(devfreq->governor_name, "passive", 7)) {
> + if (devfreq->governor->type == DEVFREQ_GOV_PASSIVE) {
>   struct devfreq *parent_devfreq =
>   ((struct devfreq_passive_data *)data)->parent;

As mentioned in a previous reply, this code may be removed.

>  
> @@ -963,13 +963,23 @@ static ssize_t available_governors_show(struct device 
> *d,
>   struct device_attribute *attr,
>   char *buf)
>  {
> - struct devfreq_governor *tmp_governor;
> + struct devfreq *devfreq = to_devfreq(d);
>   ssize_t count = 0;
>  
>   mutex_lock(_list_lock);
> - list_for_each_entry(tmp_governor, _governor_list, node)
> + if (devfreq->governor->type == DEVFREQ_GOV_PASSIVE) {
>   count += scnprintf([count], (PAGE_SIZE - count - 2),
> -"%s ", tmp_governor->name);
> +"%s ", devfreq->governor->name);
> + } else {
> + struct devfreq_governor *tmp_governor;
> +
> + list_for_each_entry(tmp_governor, _governor_list, node) 
> {
> + if (tmp_governor->type == DEVFREQ_GOV_PASSIVE)
> + continue;
> + count += scnprintf([count], (PAGE_SIZE - count - 2),
> +"%s ", tmp_governor->name);
> + }
> + }

Uh no. As long as we do not have a list of all possible governors
for each device, let's stick with what we've defined in ABI documentation:
show all available governors "in the system".

You MAY have a device that may run both PASSIVE and USERSPACE.

>   mutex_unlock(_list_lock);
>  
>   /* Truncate the trailing space */
> @@ -1006,6 +1016,11 @@ static DEVICE_ATTR_RO(target_freq);
>  static ssize_t polling_interval_show(struct device *dev,
>struct device_attribute *attr, char *buf)
>  {
> + struct devfreq *df = to_devfreq(dev);
> +
> + if (df->governor->type == DEVFREQ_GOV_PASSIVE)
> + return sprintf(buf, "Not Supported.\n");
> +
>   return sprintf(buf, "%d\n", to_devfreq(dev)->profile->polling_ms);
>  }

When polling interval is irrlevent with the governor,
you don't need to print "Not Supported". Instead,
printing "0" is enough, (polling_ms=0 == no polling)
which is what devfreq is doing now.

>  
> @@ -1020,6 +1035,9 @@ static ssize_t polling_interval_store(struct device 
> *dev,
>   if (!df->governor)
>   return -EINVAL;
>  
> + if (df->governor->type == DEVFREQ_GOV_PASSIVE)
> + return -EINVAL;
> +

Please simply return -EINVAL with governor's event_handler with 
DEVFREQ_GOV_INTERVAL
(I see the return value checking is missing at df->governor->event_handler().
You may want to add return value checking there to properly handle what you 
want.)

>   ret = sscanf(buf, "%u", );
>   if (ret != 1)
>   return -EINVAL;
> @@ -1137,11 +1155,12 @@ static ssize_t trans_stat_show(struct device *dev,
>   int i, j;
>   unsigned int max_state = devfreq->profile->max_state;
>  
> + if (max_state == 0 || devfreq->governor->type == DEVFREQ_GOV_PASSIVE)
> + return sprintf(buf, "Not Supported.\n");
> +
>   if (!devfreq->stop_polling &&
>   devfreq_update_status(devfreq, devfreq->previous_freq))
>   return 0;
> - if (max_state == 0)
> -  

Re: [PATCH v3 0/5] Add reboot notifier driver for rockchip platform

[Andy Yan]

Hi John:

On 2015年12月12日 05:29, Heiko Stübner wrote:

Am Mittwoch, 18. November 2015, 17:47:24 schrieb Andy Yan:

rockchip platform have a protocol to pass the kernel reboot
mode to bootloader by some special registers when system reboot.
By this way the bootloader can take different action according
to the different kernel reboot mode, for example, command
"reboot loader" will reboot the board to rockusb mode, this is
a very convenient way to get the board enter download mode.
And Android system also use this protocol to pass "recovery"、
“fastboot” reboot mode to bootloader. In upstream land, We found
tegra platform also use this mechanism.

Before this version, I have sent two Series, which can be found
at [0] [1]
[0] https://patchwork.kernel.org/patch/7140751/
[1] https://patchwork.kernel.org/patch/7153531/

just so it doesn't get lost, this ties into a slightly more generic approach,
John Stultz is doing for the android reboot reasons:

http://thread.gmane.org/gmane.linux.kernel/2103447

The only difference is that we'd need to use the pmu syscon for it.


Very glad to see your work on this. And your work is more generic 
than my.
 So hope we can share the code. As you can see, the rockchip 
platform use
 a GRF or PMU register to store the reboot reason. So maybe we need 
a phandle

 in the DT node to describe it.

Changes in v3:
  - rename a pinctrl node in rk3288-veyron, the original name will be
used in the incoming reboot notifier driver
  - add dt binding
  - move from mach-rockchip to drivers/soc/rockchip, as the tegra does
  - use dts pass the related register
  - add DT node

Changes in v2:
   - check cpu dt node
   - remove a unnecessary of_put_node in function rockchip_get_pmu_regmap
   - fix a align issue
   - use reboot_notifier instead of restart_handler

Andy Yan (5):
   ARM: dts: rockchip: rk3288-veyron: rename pinctrl node reboot to reset
   dt-bindings: soc: add document for rockchip reboot notifier driver
   soc: rockchip: add reboot notifier driver
   ARM: dts: rockchip: add reboot node
   ARM64: dts: rockchip: add reboot node

  .../bindings/soc/rockchip/rockchip-reboot.txt  | 18 
  arch/arm/boot/dts/rk3288-veyron.dtsi   |  2 +-
  arch/arm/boot/dts/rk3288.dtsi  |  6 ++
  arch/arm/boot/dts/rk3xxx.dtsi  |  6 ++
  arch/arm64/boot/dts/rockchip/rk3368.dtsi   |  6 ++
  drivers/soc/rockchip/Kconfig   |  7 ++
  drivers/soc/rockchip/Makefile  |  1 +
  drivers/soc/rockchip/loader.h  | 22 +
  drivers/soc/rockchip/reboot.c  | 98
++ 9 files changed, 165 insertions(+), 1 deletion(-)
  create mode 100644
Documentation/devicetree/bindings/soc/rockchip/rockchip-reboot.txt create
mode 100644 drivers/soc/rockchip/loader.h
  create mode 100644 drivers/soc/rockchip/reboot.c


___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/4] ASoC: sun4i-codec: Rename codec dapm widgets and routes

[Maxime Ripard]

Hi,

On Fri, Dec 11, 2015 at 07:43:56PM +0100, Hans de Goede wrote:
> Rename the codec dapm widgets and routes with a _codec prefix. This is
> a preparation patch for adding card dapm widgets and routes.
> 
> Signed-off-by: Hans de Goede 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH 3/4] ARM: dts: rockchip: add eFuse node for rk3066a SoCs

[Srinivas Kandagatla]

Heiko,

Can you take the DT patches in this series via your tree.

I picked up nvmem patches from this series.

thanks,
srini

On 11/11/15 07:34, Caesar Wang wrote:

This patch add the eFuse dt node for rk3066a SoCs.

Signed-off-by: Caesar Wang 
---

  arch/arm/boot/dts/rk3066a.dtsi | 13 +
  1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 946f187..f61bb8a 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -153,6 +153,19 @@
clock-names = "timer", "pclk";
};

+   efuse: efuse@2001 {
+   compatible = "rockchip,rockchip-efuse";
+   reg = <0x2001 0x4000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   clocks = < PCLK_EFUSE>;
+   clock-names = "pclk_efuse";
+
+   cpu_leakage: cpu_leakage {
+   reg = <0x17 0x1>;
+   };
+   };
+
timer@20038000 {
compatible = "snps,dw-apb-timer-osc";
reg = <0x20038000 0x100>;


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] mfd: arizona: Add device tree binding to specify mono outputs

[Charles Keepax]

Add device tree bindings to support specifying outputs from the chip as
mono outputs. Whilst we are doing it change the out_mono pdata from a
bool to an int, because Sparse gets upset about using ARRAY_SIZE on
bools.

Signed-off-by: Charles Keepax 
---

No changes since v1.

Thanks,
Charles

 drivers/mfd/arizona-core.c| 10 ++
 include/linux/mfd/arizona/pdata.h |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index b9489a0..4bb4866 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -861,6 +861,16 @@ static int arizona_of_get_core_pdata(struct arizona 
*arizona)
count++;
}
 
+   count = 0;
+   of_property_for_each_u32(arizona->dev->of_node, "wlf,out-mono", prop,
+cur, val) {
+   if (count == ARRAY_SIZE(pdata->out_mono))
+   break;
+
+   pdata->out_mono[count] = !!val;
+   count++;
+   }
+
return 0;
 }
 
diff --git a/include/linux/mfd/arizona/pdata.h 
b/include/linux/mfd/arizona/pdata.h
index 57b45ca..64faeef 100644
--- a/include/linux/mfd/arizona/pdata.h
+++ b/include/linux/mfd/arizona/pdata.h
@@ -171,7 +171,7 @@ struct arizona_pdata {
int inmode[ARIZONA_MAX_INPUT];
 
/** Mode for outputs */
-   bool out_mono[ARIZONA_MAX_OUTPUT];
+   int out_mono[ARIZONA_MAX_OUTPUT];
 
/** PDM speaker mute setting */
unsigned int spk_mute[ARIZONA_MAX_PDM_SPK];
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] extcon: arizona: Update device tree binding for mic detect configurations

[Charles Keepax]

On Mon, Dec 14, 2015 at 11:03:58AM +0900, Chanwoo Choi wrote:
> Hi Charles,
> 
> On 2015년 12월 11일 02:08, Charles Keepax wrote:
> > Update the device tree binding documentation to include documentation for
> > the wlf,micd-configs property that is used to specify the configurations
> > for headset polarity detection (CTIA / OTMP).
> > 
> > Signed-off-by: Charles Keepax 
> > ---
> >  Documentation/devicetree/bindings/extcon/extcon-arizona.txt | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt 
> > b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> > index 238e10e..fd9b898 100644
> > --- a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> > +++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> > @@ -37,5 +37,13 @@ Optional properties:
> >  milliseconds.
> >- wlf,micd-force-micbias : Force MICBIAS continuously on during 
> > microphone
> >  detection.
> > +  - wlf,micd-configs : Headset polarity configurations (generally used for
> > +detection of CTIA / OMTP headsets), the field can be of variable length
> > +but should always be a multiple of 3 cells long, each three cell group
> > +represents one polarity configuration.
> > +The first cell defines the accessory detection pin, zero will use 
> > MICDET1
> > +and all other values will use MICDET2.
> > +The second cell represents the MICBIAS to be used.
> > +The third cell represents the value of the micd-pol-gpio pin.
> 
> I think that you better to add the example using the 'wlf,micd-configs'
> to improve the understanding of using this property.
> because the number of 'wlf,micd-configs' value is not fixed.
> 
> Also,
> How about do you add the real example for all arizona properties on separate 
> patch?

Yeah that seems sensible I will do a patch to add an example to
this file.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/5] power: domain: add pm_genpd_exit

[Ulf Hansson]

+Russell

[...]

>> >> +void pm_genpd_exit(struct generic_pm_domain *genpd)
>> >> +{
>> >> +  if (IS_ERR_OR_NULL(genpd))
>> >> +  return;
>> >> +
>> >> +  /* check if domain is still in registered inside the pm subsystem */
>> >> +  WARN_ON_ONCE(!list_empty(>master_links) ||
>> >> +   !list_empty(>slave_links) ||
>> >> +   !list_empty(>dev_list));
>> >> +
>> >
>> > Why not return an error here? Seems bad to remove it, if it could still
>> > be referenced by other domains.
>>
>> I had pointed this out as well in an earlier review.
>>
>
> I talked with Ulf Hansson about such handling and there exists currently
> no handling to remove the pm_genpd on error handling (what our use case
> is for RPi domains).
>
> The real solution would be a "pm_genpd_exit_recursive" functionality to
> remove subdomains, etc -> simple everything. Anway I am not a expert into
> power domain functionality and this simple approach was enough to him to
> add "something" which we have actually a lack of support.
>
>

[...]

Just to be clear on my view. I think Russell made a good summary of
how we should implement this API [1].
We should return an error, instead of WARN_ON_ONCE and continue.

Perhaps you can do both a WARN *and* return an error.

Regarding the similar patch from Jon Hunter, I would suggest we focus
on Alexander's $subject patch and try to it queued for 4.5. Please
send a new version.

Also, as other SoC genpd driver isn't using a "pm_genpd_exit()" API,
it shouldn't prevent neither Alexander/Eric or Jon from proceeding
with the RPI/Tegra genpd drivers. Once the new API is in place you can
update these drivers to properly deal with error handling and undo
things from pm_genpd_init().

Kind regards
Uffe

[1]
https://lkml.org/lkml/2015/12/9/308
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] spi: dts: sun4i: Add support for hardware-based wait time between words

[Mark Brown]

On Mon, Dec 14, 2015 at 12:23:29AM +0100, Marcus Weseloh wrote:

> Should I resend the patch?

No, it's OK.


signature.asc
Description: PGP signature

Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings

[Juri Lelli]

Hi Mark,

On 11/12/15 17:49, Mark Brown wrote:
> On Thu, Dec 10, 2015 at 05:58:20PM +, Juri Lelli wrote:
> > On 10/12/15 15:30, Mark Brown wrote:
> > > On Mon, Nov 23, 2015 at 08:06:31PM -0600, Rob Herring wrote:
> 
> > > > In other words, I want to see these numbers have a defined method 
> > > > of determining them and don't want to see random values from every 
> > > > vendor. ARM, Ltd. says core X has a value of Y would be good enough for 
> > > > me. Vendor X's A57 having a value of 2 and Vendor Y's A57 having a 
> > > > value of 1024 is not what I want to see. Of course things like cache 
> > > > sizes can vary the performance, but is a baseline value good enough? 
> 
> > > > However, no vendor will want to publish their values if these are 
> > > > absolute values relative to other vendors.
> 
> > > > If you expect these to need frequent tuning, then don't put them in DT.
> 
> > > I agree strongly.  Putting what are essentially tuning numbers for the
> > > system into the ABI is going to lead us into a mess long term since if
> > > we change anything related to the performance of the system the numbers
> > > may become invalid and we've no real way of recovering sensible
> > > information.
> 
> > I'm not entirely getting here why you consider capacity values to be
> > tunables. As part of the EAS effort, we are proposing ways in which users
> 
> The purpose of the capacity values is to influence the scheduler
> behaviour and hence performance.  Without a concrete definition they're
> just magic numbers which have meaining only in terms of their effect on
> the performance of the system.  That is a sufficiently complex outcome
> to ensure that there will be an element of taste in what the desired
> outcomes are.  Sounds like tuneables to me.
> 

Capacity values are meant to describe asymmetry (if any) of the system
CPUs to the scheduler. The scheduler can then use this additional bit of
information to try to do better scheduling decisions. Yes, having these
values available will end up giving you better performance, but I guess
this apply to any information we provide to the kernel (and scheduler);
the less dumb a subsystem is, the better we can make it work.

> > should be able to fine tune their system as needed, when required
> > (don't know if you had a chance to have a look at the SchedTune posting
> > back in August for example [1]). This patch tries to only standardize
> > where do we get default values from and how we specify them. I'm not
> > seeing them changing much after an initial benchmarking phase has been
> > done. Tuning should happen using different methods, not by changing
> > these values, IMHO.
> 
> If you are saying people should use other, more sensible, ways of
> specifying the final values that actually get used in production then
> why take the defaults from direct numbers DT in the first place?  If you
> are saying that people should tune and then put the values in here then
> that's problematic for the reasons I outlined.
> 

IMHO, people should come up with default values that describe
heterogeneity in their system. Then use other ways to tune the system at
run time (depending on the workload maybe).

As said, I understand your concerns; but, what I don't still get is
where CPU capacity values are so different from, say, idle states
min-residency-us. AFAIK there is a per-SoC benchmarking phase required
to come up with that values as well; you have to pick some benchmark
that stresses worst case entry/exit while measuring energy, then make
calculations that tells you when it is wise to enter a particular idle
state. Ideally we should derive min residency from specs, but I'm not
sure is how it works in practice.

> > > It would be better to have the DT describe concrete physical properties
> > > of the system which we can then map onto numbers we like, that way if we
> > > get better information in future or just decide that completely
> > > different metrics are appropriate for tuning we can just do that without
> > > having to worry about translating the old metrics into new ones.  We can
> > > then expose the tuning knobs to userspace for override if that's needed.
> > > If doing system specific tuning on vertically integrated systems really
> > > is terribly important it's not going to matter too much where the tuning
> > > is but we also have to consider more general purpose systems.
> 
> > As replied to Rob, I'm not sure it is so easy to find any physical
> > property that expresses what we essentially need (without maybe relying
> > on a complex mix of hardware details and a model to extract numbers from
> > them). Instead, we propose to have reasonable, per SoC, default numbers;
> > and then let users fine tune their platform afterwards, without changing
> > those default values.
> 
> If users are supposed to do fine tuning elsewhere after the fact why
> bother with this initial callibration?  Something that's ballpark good
> enough like just knowing the core 

Re: [PATCH v2 6/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

[Hans Verkuil]

Hi Tiffany,

My apologies for the long delay, but I finally have time to do a review of this
code.

On 12/11/2015 10:55 AM, Tiffany Lin wrote:
> From: Andrew-CT Chen 
> 
> Add v4l2 layer encoder driver for MT8173
> 
> Signed-off-by: Tiffany Lin 
> ---
>  drivers/media/platform/Kconfig |   11 +
>  drivers/media/platform/Makefile|2 +
>  drivers/media/platform/mtk-vcodec/Makefile |8 +
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  412 +
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1670 
> 
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h |   45 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  469 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  |  122 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.c|  102 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.h|   29 +
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h  |   26 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_util.c|  106 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_util.h|   85 +
>  drivers/media/platform/mtk-vcodec/venc_drv_base.h  |   62 +
>  drivers/media/platform/mtk-vcodec/venc_drv_if.c|  102 ++
>  drivers/media/platform/mtk-vcodec/venc_drv_if.h|  174 ++
>  drivers/media/platform/mtk-vcodec/venc_ipi_msg.h   |  212 +++
>  17 files changed, 3637 insertions(+)
>  create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h
> 



> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> new file mode 100644
> index 000..d59064d
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> @@ -0,0 +1,1670 @@
> +/*
> +* Copyright (c) 2015 MediaTek Inc.
> +* Author: PC Chen 
> +* Tiffany Lin 
> +*
> +* This program is free software; you can redistribute it and/or modify
> +* it under the terms of the GNU General Public License version 2 as
> +* published by the Free Software Foundation.
> +*
> +* This program 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.
> +*/
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "mtk_vcodec_drv.h"
> +#include "mtk_vcodec_enc.h"
> +#include "mtk_vcodec_intr.h"
> +#include "mtk_vcodec_util.h"
> +#include "venc_drv_if.h"
> +
> +static void mtk_venc_worker(struct work_struct *work);
> +
> +static struct mtk_video_fmt mtk_video_formats[] = {
> + {
> + .name   = "4:2:0 3 Planes Y/Cb/Cr",

Don't add the name. The v4l2 core will set that for you. This ensures that the 
name is
always the same for the format, instead of being driver dependent.

> + .fourcc = V4L2_PIX_FMT_YUV420,
> + .type   = MTK_FMT_FRAME,
> + .num_planes = 3,
> + },
> + {
> + .name   = "4:2:0 3 Planes Y/Cr/Cb",
> + .fourcc = V4L2_PIX_FMT_YVU420,
> + .type   = MTK_FMT_FRAME,
> + .num_planes = 3,
> + },
> + {
> + .name   = "4:2:0 2 Planes Y/CbCr",
> + .fourcc = V4L2_PIX_FMT_NV12,
> + .type   = MTK_FMT_FRAME,
> + .num_planes = 2,
> + },
> + {
> + .name   = "4:2:0 2 Planes Y/CrCb",
> + .fourcc = V4L2_PIX_FMT_NV21,
> + .type   = MTK_FMT_FRAME,
> + .num_planes = 2,
> + },
> + {
> + .name   = "4:2:0 3 none contiguous Planes Y/Cb/Cr",
> + .fourcc = V4L2_PIX_FMT_YUV420M,
> + .type   = MTK_FMT_FRAME,
> + .num_planes 

Re: [PATCH v6 0/4] stmmac: create of compatible mdio bus for stmacc driver

[David Miller]

From: Phil Reid 
Date: Mon, 14 Dec 2015 11:31:58 +0800

> Provide ability to specify a fixed phy in the device tree and
> retain the mdio bus if no phy is found. This is needed where 
> a dsa is connected via a fixed phy and uses the mdio bus for config.
> Fixed ptp ref clock calculatins for the stmmac when ptp ref clock
> is running at <= 50Mhz. Also add device tree setting to config
> ptp clk source on socfpga platforms.

Series applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/5] clk: imx: Add clock support for imx6qp

[Bai Ping]

most of the clock tree structures on i.MX6QP are same as
on i.MX6Q. there still some difference between these two
SOCs. Compared to the i.MX6Q, the differences of clocks on
i.MX6QP is mainly on:

1. UART clk root
2. IPG_PER clk,
3. ENFC
4. ECSPI
5. CAN_SEL
6. CSCMR1 register fixup issue
7. LDB clock
8. GPU2D clock
9 MMDC_CH1_AXI gate ...

Signed-off-by: Bai Ping 
---
 drivers/clk/imx/clk-imx6q.c | 132 +++-
 1 file changed, 105 insertions(+), 27 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index f0efc6f..02e1818 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -34,7 +34,9 @@ static const char *periph2_sels[] = { "periph2_pre", 
"periph2_clk2", };
 static const char *axi_sels[]  = { "periph", "pll2_pfd2_396m", 
"periph", "pll3_pfd1_540m", };
 static const char *audio_sels[]= { "pll4_audio_div", "pll3_pfd2_508m", 
"pll3_pfd3_454m", "pll3_usb_otg", };
 static const char *gpu_axi_sels[]  = { "axi", "ahb", };
+static const char *pre_axi_sels[]  = { "axi", "ahb", };
 static const char *gpu2d_core_sels[]   = { "axi", "pll3_usb_otg", 
"pll2_pfd0_352m", "pll2_pfd2_396m", };
+static const char *gpu2d_core_sels_2[] = { "mmdc_ch0_axi", "pll3_usb_otg", 
"pll2_pfd1_594m", "pll3_pfd0_720m",};
 static const char *gpu3d_core_sels[]   = { "mmdc_ch0_axi", "pll3_usb_otg", 
"pll2_pfd1_594m", "pll2_pfd2_396m", };
 static const char *gpu3d_shader_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg", 
"pll2_pfd1_594m", "pll3_pfd0_720m", };
 static const char *ipu_sels[]  = { "mmdc_ch0_axi", "pll2_pfd2_396m", 
"pll3_120m", "pll3_pfd1_540m", };
@@ -44,15 +46,24 @@ static const char *ipu1_di0_sels[]  = { "ipu1_di0_pre", 
"dummy", "dummy", "ldb_di
 static const char *ipu1_di1_sels[] = { "ipu1_di1_pre", "dummy", "dummy", 
"ldb_di0", "ldb_di1", };
 static const char *ipu2_di0_sels[] = { "ipu2_di0_pre", "dummy", "dummy", 
"ldb_di0", "ldb_di1", };
 static const char *ipu2_di1_sels[] = { "ipu2_di1_pre", "dummy", "dummy", 
"ldb_di0", "ldb_di1", };
+static const char *ipu1_di0_sels_2[]   = { "ipu1_di0_pre", "dummy", "dummy", 
"ldb_di0_podf", "ldb_di1_podf", };
+static const char *ipu1_di1_sels_2[]   = { "ipu1_di1_pre", "dummy", "dummy", 
"ldb_di0_podf", "ldb_di1_podf", };
+static const char *ipu2_di0_sels_2[]   = { "ipu2_di0_pre", "dummy", "dummy", 
"ldb_di0_podf", "ldb_di1_podf", };
+static const char *ipu2_di1_sels_2[]   = { "ipu2_di1_pre", "dummy", "dummy", 
"ldb_di0_podf", "ldb_di1_podf", };
 static const char *hsi_tx_sels[]   = { "pll3_120m", "pll2_pfd2_396m", };
 static const char *pcie_axi_sels[] = { "axi", "ahb", };
 static const char *ssi_sels[]  = { "pll3_pfd2_508m", "pll3_pfd3_454m", 
"pll4_audio_div", };
 static const char *usdhc_sels[]= { "pll2_pfd2_396m", "pll2_pfd0_352m", 
};
 static const char *enfc_sels[] = { "pll2_pfd0_352m", "pll2_bus", 
"pll3_usb_otg", "pll2_pfd2_396m", };
+static const char *enfc_sels_2[] = {"pll2_pfd0_352m", "pll2_bus", 
"pll3_usb_otg", "pll2_pfd2_396m", "pll3_pfd3_454m", "dummy", };
 static const char *eim_sels[]  = { "pll2_pfd2_396m", "pll3_usb_otg", 
"axi", "pll2_pfd0_352m", };
 static const char *eim_slow_sels[]  = { "axi", "pll3_usb_otg", 
"pll2_pfd2_396m", "pll2_pfd0_352m", };
 static const char *vdo_axi_sels[]  = { "axi", "ahb", };
 static const char *vpu_axi_sels[]  = { "axi", "pll2_pfd2_396m", 
"pll2_pfd0_352m", };
+static const char *uart_sels[] = { "pll3_80m", "osc", };
+static const char *ipg_per_sels[] = { "ipg", "osc", };
+static const char *ecspi_sels[] = { "pll3_60m", "osc", };
+static const char *can_sels[] = { "pll3_60m", "osc", "pll3_80m", };
 static const char *cko1_sels[] = { "pll3_usb_otg", "pll2_bus", "pll1_sys", 
"pll5_video_div",
"dummy", "axi", "enfc", "ipu1_di0", 
"ipu1_di1", "ipu2_di0",
"ipu2_di1", "ahb", "ipg", "ipg_per", 
"ckil", "pll4_audio_div", };
@@ -121,12 +132,19 @@ static unsigned int share_count_ssi2;
 static unsigned int share_count_ssi3;
 static unsigned int share_count_mipi_core_cfg;
 static unsigned int share_count_spdif;
+static unsigned int share_count_prg0;
+static unsigned int share_count_prg1;
 
 static inline int clk_on_imx6q(void)
 {
return of_machine_is_compatible("fsl,imx6q");
 }
 
+static inline int clk_on_imx6qp(void)
+{
+   return of_machine_is_compatible("fsl,imx6qp");
+}
+
 static inline int clk_on_imx6dl(void)
 {
return of_machine_is_compatible("fsl,imx6dl");
@@ -265,7 +283,7 @@ static void __init imx6q_clocks_init(struct device_node 
*ccm_node)
clk[IMX6QDL_CLK_TWD]   = imx_clk_fixed_factor("twd",   "arm",   
 1, 2);
clk[IMX6QDL_CLK_GPT_3M]= imx_clk_fixed_factor("gpt_3m","osc",   
 1, 8);
clk[IMX6QDL_CLK_VIDEO_27M] = imx_clk_fixed_factor("video_27m", 
"pll3_pfd1_540m", 1, 20);
-   if 

[PATCH v2 2/5] ARM: dts: imx: Add basic dts support for imx6qp-sabresd

[Bai Ping]

The patch adds dts file for imx6qp-sabresd board.

Signed-off-by: Bai Ping 
---
 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi |  1 +
 arch/arm/boot/dts/imx6qp-sabresd.dts   | 59 ++
 3 files changed, 61 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6qp-sabresd.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 36d8133..dfba765 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -302,6 +302,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-sabreauto.dtb \
imx6dl-sabrelite.dtb \
imx6dl-sabresd.dtb \
+   imx6qp-sabresd.dtb \
imx6dl-tx6dl-comtft.dtb \
imx6dl-tx6u-801x.dtb \
imx6dl-tx6u-811x.dtb \
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index a6d445c..f65f57b 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -238,6 +238,7 @@
regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
+   regulator-ramp-delay = <6250>;
};
 
sw3a_reg: sw3a {
diff --git a/arch/arm/boot/dts/imx6qp-sabresd.dts 
b/arch/arm/boot/dts/imx6qp-sabresd.dts
new file mode 100644
index 000..c3ab2b6
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qp-sabresd.dts
@@ -0,0 +1,59 @@
+/*
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "imx6q-sabresd.dts"
+#include "imx6qp.dtsi"
+
+/ {
+   model = "Freescale i.MX6 Quad Plus SABRE Smart Device Board";
+   compatible = "fsl,imx6qp-sabresd", "fsl,imx6qp";
+};
+
+ {
+   arm-supply = <_reg>;
+};
+
+ {
+   imx6qdl-sabresd {
+   pinctrl_usdhc2: usdhc2grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
+   MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10071
+   MX6QDL_PAD_SD2_DAT0__SD2_DATA0  0x17059
+   MX6QDL_PAD_SD2_DAT1__SD2_DATA1  0x17059
+   MX6QDL_PAD_SD2_DAT2__SD2_DATA2  0x17059
+   MX6QDL_PAD_SD2_DAT3__SD2_DATA3  0x17059
+   MX6QDL_PAD_NANDF_D4__SD2_DATA4  0x17059
+   MX6QDL_PAD_NANDF_D5__SD2_DATA5  0x17059
+   MX6QDL_PAD_NANDF_D6__SD2_DATA6  0x17059
+   MX6QDL_PAD_NANDF_D7__SD2_DATA7  0x17059
+   >;
+   };
+
+   pinctrl_usdhc3: usdhc3grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+   MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10071
+   MX6QDL_PAD_SD3_DAT0__SD3_DATA0  0x17059
+   MX6QDL_PAD_SD3_DAT1__SD3_DATA1  0x17059
+   MX6QDL_PAD_SD3_DAT2__SD3_DATA2  0x17059
+   MX6QDL_PAD_SD3_DAT3__SD3_DATA3  0x17059
+   MX6QDL_PAD_SD3_DAT4__SD3_DATA4  0x17059
+   MX6QDL_PAD_SD3_DAT5__SD3_DATA5  0x17059
+   MX6QDL_PAD_SD3_DAT6__SD3_DATA6  0x17059
+   MX6QDL_PAD_SD3_DAT7__SD3_DATA7  0x17059
+   >;
+   };
+   };
+};
+
+ {
+   power-on-gpio = < 19 0>;
+   reset-gpio = < 12 0>;
+   status = "okay";
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/5] ARM: imx: Add msl code support for imx6qp

[Bai Ping]

The i.MX6QP is a different SOC, but internally we treate
it as i.MX6Q Rev_2.0 to maximum the code reusability. The chip
silicon number we read from the ANADIG_DIGPROG is 0x630100. This
patch add code to identify it as i.MX6QP Rev_1.0 when print out the
silicon version.

Signed-off-by: Bai Ping 
---
 arch/arm/mach-imx/anatop.c | 5 -
 arch/arm/mach-imx/mach-imx6q.c | 8 ++--
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/anatop.c b/arch/arm/mach-imx/anatop.c
index 231bb25..9622763 100644
--- a/arch/arm/mach-imx/anatop.c
+++ b/arch/arm/mach-imx/anatop.c
@@ -129,7 +129,10 @@ void __init imx_init_revision_from_anatop(void)
 
switch (digprog & 0xff) {
case 0:
-   revision = IMX_CHIP_REVISION_1_0;
+   if (digprog >> 8 & 0x01)
+   revision = IMX_CHIP_REVISION_2_0;
+   else
+   revision = IMX_CHIP_REVISION_1_0;
break;
case 1:
revision = IMX_CHIP_REVISION_1_1;
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 3878494b..cb27d56 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -266,8 +266,11 @@ static void __init imx6q_init_machine(void)
 {
struct device *parent;
 
-   imx_print_silicon_rev(cpu_is_imx6dl() ? "i.MX6DL" : "i.MX6Q",
- imx_get_soc_revision());
+   if (cpu_is_imx6q() && imx_get_soc_revision() == IMX_CHIP_REVISION_2_0)
+   imx_print_silicon_rev("i.MX6QP", IMX_CHIP_REVISION_1_0);
+   else
+   imx_print_silicon_rev(cpu_is_imx6dl() ? "i.MX6DL" : "i.MX6Q",
+   imx_get_soc_revision());
 
parent = imx_soc_device_init();
if (parent == NULL)
@@ -399,6 +402,7 @@ static void __init imx6q_init_irq(void)
 static const char * const imx6q_dt_compat[] __initconst = {
"fsl,imx6dl",
"fsl,imx6q",
+   "fsl,imx6qp",
NULL,
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/5] ARM: dts: imx: Add basic dts support for imx6qp SOC

[Bai Ping]

The i.MX6Quad Plus processor is an high performance SOC of i.MX6 family.
It has enhanced graphics performance and increased overall memory bandwidth
compared to i.MX6Q. Most of the design are same as i.MX6Quad/Dual, so code
for i.MX6Quad can be resued by this chip. The revision number is identied as
i.MX6Q Rev2.0, but actually it is a new chip, as we did many change to the
overall architecture.

This patch adds basic dtsi file support for the new i.MX6Quad Plus processor.

Signed-off-by: Bai Ping 
---
 arch/arm/boot/dts/imx6q.dtsi  |   2 +-
 arch/arm/boot/dts/imx6qp.dtsi | 157 ++
 include/dt-bindings/clock/imx6qdl-clock.h |  16 ++-
 3 files changed, 173 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6qp.dtsi

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index a266a56..e26d0fd 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -22,7 +22,7 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   cpu@0 {
+   cpu0: cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
diff --git a/arch/arm/boot/dts/imx6qp.dtsi b/arch/arm/boot/dts/imx6qp.dtsi
new file mode 100644
index 000..e43751f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qp.dtsi
@@ -0,0 +1,157 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+/ {
+   aliases {
+   pre0 = 
+   pre1 = 
+   pre2 = 
+   pre3 = 
+   prg0 = 
+   prg1 = 
+   };
+
+   soc {
+   ocram_2: sram@0094 {
+   compatible = "mmio-sram";
+   reg = <0x0094 0x2>;
+   clocks = < IMX6QDL_CLK_OCRAM>;
+   };
+
+   ocram_3: sram@0096 {
+   compatible = "mmio-sram";
+   reg = <0x0096 0x2>;
+   clocks = < IMX6QDL_CLK_OCRAM>;
+   };
+
+   pcie: pcie@0x0100 {
+   compatible = "fsl,imx6qp-pcie", "snps,dw-pcie";
+   reg = <0x01ffc000 0x4000>, <0x01f0 0x8>;
+   reg-names = "dbi", "config";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   ranges = <0x8100 0 0  0x01f8 0 
0x0001 /* downstream I/O */
+ 0x8200 0 0x0100 0x0100 0 
0x00f0>; /* non-prefetchable memory */
+   num-lanes = <1>;
+   interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1  0 123 
IRQ_TYPE_LEVEL_HIGH>,
+   <0 0 0 2  0 122 
IRQ_TYPE_LEVEL_HIGH>,
+   <0 0 0 3  0 121 
IRQ_TYPE_LEVEL_HIGH>,
+   <0 0 0 4  0 120 
IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < IMX6QDL_CLK_PCIE_REF_125M>,
+< IMX6QDL_CLK_SATA_REF_100M>,
+< IMX6QDL_CLK_LVDS1_GATE>, < 
IMX6QDL_CLK_PCIE_AXI>;
+   clock-names = "pcie_phy", "ref_100m", "pcie_bus", 
"pcie";
+   status = "disabled";
+   };
+
+   aips-bus@0210 { /* AIPS2 */
+   pre1: pre@021c8000 {
+   compatible = "fsl,imx6q-pre";
+   reg = <0x021c8000 0x1000>;
+   clocks = < IMX6QDL_CLK_PRE0>;
+   interrupts = <0 90 IRQ_TYPE_EDGE_RISING>;
+   ocram = <_2>;
+   status = "disabled";
+   };
+
+   pre2: pre@021c9000 {
+   compatible = "fsl,imx6q-pre";
+   reg = <0x021c9000 0x1000>;
+   clocks = < IMX6QDL_CLK_PRE1>;
+   interrupts = <0 97 IRQ_TYPE_EDGE_RISING>;
+   ocram = <_2>;
+   status = "disabled";
+   };
+
+   pre3: pre@021ca000 {
+   compatible = "fsl,imx6q-pre";
+   reg = <0x021ca000 0x1000>;
+   clocks = < 

[PATCH v2 0/5] Add support for imx6qp

[Bai Ping]

This patchset add basic support for i.MX6Quad Plus SOC.

change for v2:
 -- address commnet from Fabio Estevam, split the dts
into three patch:
dts for imx6qp soc; dts for imx6qp-sabresd
and dts for imx6qp-sabreauto
 -- fix a typo in commit, the chip name should be i.MX6Quad Plus 

Bai Ping (5):
  ARM: dts: imx: Add basic dts support for imx6qp SOC
  ARM: dts: imx: Add basic dts support for imx6qp-sabresd
  ARM: dts: imx: Add basic dts support for imx6qp-sabreauto
  clk: imx: Add clock support for imx6qp
  ARM: imx: Add msl code support for imx6qp

 arch/arm/boot/dts/Makefile|   2 +
 arch/arm/boot/dts/imx6q.dtsi  |   2 +-
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi|   1 +
 arch/arm/boot/dts/imx6qp-sabreauto.dts|  67 +
 arch/arm/boot/dts/imx6qp-sabresd.dts  |  59 +++
 arch/arm/boot/dts/imx6qp.dtsi | 157 ++
 arch/arm/mach-imx/anatop.c|   5 +-
 arch/arm/mach-imx/mach-imx6q.c|   8 +-
 drivers/clk/imx/clk-imx6q.c   | 132 -
 include/dt-bindings/clock/imx6qdl-clock.h |  16 ++-
 10 files changed, 417 insertions(+), 32 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6qp-sabreauto.dts
 create mode 100644 arch/arm/boot/dts/imx6qp-sabresd.dts
 create mode 100644 arch/arm/boot/dts/imx6qp.dtsi

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/5] ARM: dts: imx: Add basic dts support for imx6qp-sabreauto

[Bai Ping]

This patch adds basic dts file for imx6qp-sabreauto board.

Signed-off-by: Bai Ping 
---
 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/imx6qp-sabreauto.dts | 67 ++
 2 files changed, 68 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6qp-sabreauto.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index dfba765..7996a51 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -329,6 +329,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-phytec-pbab01.dtb \
imx6q-rex-pro.dtb \
imx6q-sabreauto.dtb \
+   imx6qp-sabreauto.dtb \
imx6q-sabrelite.dtb \
imx6q-sabresd.dtb \
imx6q-sbc6x.dtb \
diff --git a/arch/arm/boot/dts/imx6qp-sabreauto.dts 
b/arch/arm/boot/dts/imx6qp-sabreauto.dts
new file mode 100644
index 000..b24aae6
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qp-sabreauto.dts
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "imx6q-sabreauto.dts"
+#include "imx6qp.dtsi"
+
+/ {
+   model = "Freescale i.MX6 Quad Plus SABRE Automotive Board";
+   compatible = "fsl,imx6qp-sabreauto", "fsl,imx6qp";
+};
+
+
+ {
+   pinctrl-assert-gpios = < 0 GPIO_ACTIVE_HIGH>;
+};
+
+ {
+   max7322: gpio@68 {
+   compatible = "maxim,max7322";
+   reg = <0x68>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+};
+
+ {
+   imx6qdl-sabreauto {
+   pinctrl_enet: enetgrp {
+   fsl,pins = <
+   MX6QDL_PAD_KEY_COL1__ENET_MDIO  0x1b0b0
+   MX6QDL_PAD_KEY_COL2__ENET_MDC   0x1b0b0
+   MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b018
+   MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b018
+   MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b018
+   MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b018
+   MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b018
+   MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL   0x1b018
+   MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b018
+   MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b018
+   MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b018
+   MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b018
+   MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b018
+   MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL   0x1b018
+   MX6QDL_PAD_GPIO_16__ENET_REF_CLK
0x4001b0a8
+   MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
+   >;
+   };
+   };
+};
+
+ {
+   reset-gpio = <_c 5 GPIO_ACTIVE_LOW>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_reg {
+   regulator-always-on;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver

[Peter Chen]

On Mon, Dec 14, 2015 at 09:26:55AM -0200, Fabio Estevam wrote:
> Hi Peter,
> 
> On Mon, Dec 14, 2015 at 5:26 AM, Peter Chen  wrote:
> 
> > Hi all,
> >
> > There is a known issue that the USB code can't handle USB HUB's
> > external pins well, in that case, it may cause some onboard
> > USB HUBs can't work since their PHY's clock or reset pin needs to
> > operate.
> >
> > The user reported this issue at below:
> > http://www.spinics.net/lists/linux-usb/msg131502.html
> >
> > In this patch set, I add a generic onboard USB HUB driver to
> > handle this problem, the external signals will be configured
> > before usb controller's initialization, it much likes we did
> > it at board code before.
> >
> > The user needs to add this generic hub node at dts to support it.
> >
> > @The udoo users, help to test please.
> 
> This is what I get with your series applied:
> 
> [2.288300] usb 1-1: device descriptor read/64, error -71
> [2.518083] usb 1-1: new full-speed USB device number 3 using ci_hdrc
> [2.738078] usb 1-1: device descriptor read/64, error -71
> [3.058078] usb 1-1: device descriptor read/64, error -71
> [3.288079] usb 1-1: new full-speed USB device number 4 using ci_hdrc
> [3.768069] usb 1-1: device not accepting address 4, error -71
> [3.888084] usb 1-1: new full-speed USB device number 5 using ci_hdrc
> [4.368067] usb 1-1: device not accepting address 5, error -71
> [4.374117] usb usb1-port1: unable to enumerate USB device

Thanks, Fabio.

I am afraid I forget to set gpio as output, would you please apply
below patch against my original ones:

diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi 
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index 64eabe2..34b0708 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -24,7 +24,7 @@
compatible = "generic-onboard-hub";
clocks = < IMX6QDL_CLK_CKO>;
reset-gpios = < 12 GPIO_ACTIVE_LOW>;
-   reset-duration-us = <2>;
+   reset-duration-us = <10>;
};
 };
 
diff --git a/drivers/usb/misc/generic_onboard_hub.c 
b/drivers/usb/misc/generic_onboard_hub.c
index 7db5b78..2f0afa7 100644
--- a/drivers/usb/misc/generic_onboard_hub.c
+++ b/drivers/usb/misc/generic_onboard_hub.c
@@ -89,6 +89,8 @@ static int usb_hub_generic_probe(struct platform_device *pdev)
of_property_read_u32(node, "reset-duration-us", _us);
 
if (gpiod_reset) {
+   gpiod_direction_output(gpiod_reset, 1);
+
gpiod_set_value(gpiod_reset, 1);
usleep_range(duration_us, duration_us + 10);
gpiod_set_value(gpiod_reset, 0);

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Daniel Kurtz]

On Tue, Dec 15, 2015 at 11:30 AM, Jitao Shi  wrote:
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>
> Signed-off-by: Jitao Shi 
> ---
> Changes since v5
> -fix compile errors when CONFIG_GPIOLIB=n
> ---
>  drivers/gpu/drm/bridge/Kconfig |   10 +
>  drivers/gpu/drm/bridge/Makefile|1 +
>  drivers/gpu/drm/bridge/parade-ps8640.c |  472 
> 
>  3 files changed, 483 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 639..dcfdbc9 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -41,4 +41,14 @@ config DRM_PARADE_PS8622
> ---help---
>   Parade eDP-LVDS bridge chip driver.
>
> +config DRM_PARADE_PS8640
> +   tristate "Parade PS8640 MIPI DSI to eDP Converter"
> +   depends on OF
> +   select DRM_KMS_HELPER
> +   select DRM_PANEL
> +   ---help---
> + Choose this option if you have PS8640 for display
> + The PS8640 is a high-performance and low-power
> + MIPI DSI to eDP converter
> +
>  endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index d4e28be..272e3c01 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> new file mode 100644
> index 000..bf0c3c37
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -0,0 +1,472 @@
> +/*
> + * Copyright (c) 2014 MediaTek Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PAGE2_GPIO_L   0xa6
> +#define PAGE2_GPIO_H   0xa7
> +#define PS_GPIO9   BIT(1)
> +#define PAGE2_I2C_BYPASS   0xea
> +#define I2C_BYPASS_EN  0xd0
> +
> +#define PAGE3_SET_ADD  0xfe
> +#define PAGE3_SET_VAL  0xff
> +#define VDO_CTL_ADD0x13
> +#define VDO_DIS0x18
> +#define VDO_EN 0x1c
> +
> +#define PAGE4_REV_L0xf0
> +#define PAGE4_REV_H0xf1
> +#define PAGE4_CHIP_L   0xf2
> +#define PAGE4_CHIP_H   0xf3
> +
> +#define bridge_to_ps8640(e)container_of(e, struct ps8640, bridge)
> +#define connector_to_ps8640(e) container_of(e, struct ps8640, connector)
> +
> +struct ps8640 {
> +   struct drm_connector connector;
> +   struct drm_bridge bridge;
> +   struct i2c_client *page[6];
> +   struct ps8640_driver_data *driver_data;
> +   struct regulator *pwr_1v2_supply;
> +   struct regulator *pwr_3v3_supply;
> +   struct drm_panel *panel;
> +   struct gpio_desc *gpio_rst_n;
> +   struct gpio_desc *gpio_slp_n;
> +   struct gpio_desc *gpio_mode_sel_n;
> +   bool enabled;
> +};
> +
> +static int ps8640_regr(struct i2c_client *client, u8 reg, u8 *value)
> +{
> +   int ret;
> +
> +   ret = i2c_master_send(client, , 1);
> +   if (ret <= 0) {
> +   dev_err(>dev, "Failed to send i2c command, ret=%d\n",
> +   ret);
> +   return ret;
> +   }
> +
> +   ret = i2c_master_recv(client, value, 1);
> +   if (ret <= 0) {
> +   dev_err(>dev, "Failed to recv i2c data, ret=%d\n", 
> ret);
> +   return ret;
> +   }

i2c_transfer should be a bit more efficient for reading one byte.

> +
> +   return 0;
> +}
> +
> +static int ps8640_regw(struct i2c_client *client, u8 reg, u8 value)
> +{
> +   int ret;
> +   char buf[2];
> +
> +   buf[0] = reg;
> +   buf[1] = value;
> +   ret = i2c_master_send(client, buf, ARRAY_SIZE(buf));
> +   if (ret <= 0) {
> +   dev_err(>dev, "Failed to send i2c command, ret=%d\n",
> +   ret);
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> +
> +static bool ps8640_check_valid_id(struct ps8640 *ps_bridge)
> +{
> 

[PATCH v4] ARM: dts: ls1021a: add sata node to dts

[Yuantian.Tang]

From: Tang Yuantian 

Added sata node to ls1021aqds and ls1021atwr board to support
sata function.

Signed-off-by: Tang Yuantian 
---
v4:
- sorted the node alphabetically
v3:
- refine the title and commit message
- added a status property so that sata can be controlled
by board specific dts.
v2:
- put reg-names right after reg property

 arch/arm/boot/dts/ls1021a-qds.dts |  4 
 arch/arm/boot/dts/ls1021a-twr.dts |  4 
 arch/arm/boot/dts/ls1021a.dtsi| 11 +++
 3 files changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a-qds.dts 
b/arch/arm/boot/dts/ls1021a-qds.dts
index 0521e68..9408753 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -320,6 +320,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts 
b/arch/arm/boot/dts/ls1021a-twr.dts
index fbb89d1..d44f4d5 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -212,6 +212,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 9430a99..da9bd7e 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -143,6 +143,17 @@
status = "disabled";
};
 
+   sata: sata@320 {
+   compatible = "fsl,ls1021a-ahci";
+   reg = <0x0 0x320 0x0 0x1>,
+ <0x0 0x20220520 0x0 0x4>;
+   reg-names = "ahci", "sata-ecc";
+   interrupts = ;
+   clocks = <_clk 1>;
+   dma-coherent;
+   status = "disabled";
+   };
+
scfg: scfg@157 {
compatible = "fsl,ls1021a-scfg", "syscon";
reg = <0x0 0x157 0x0 0x1>;
-- 
2.1.0.27.g96db324

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants

[Philipp Zabel]

Hi Hans,

Am Freitag, den 11.12.2015, 19:21 +0100 schrieb Hans de Goede:
[...]
> >> @@ -119,13 +134,55 @@ EXPORT_SYMBOL_GPL(reset_control_assert);
> >>   int reset_control_deassert(struct reset_control *rstc)
> >>   {
> >
> > Maybe WARN_ON(rstc->line->refcnt > 1) ?
> 
> I assume you mean deasser_cnt ? Seems reasonable with that change.

I meant refcnt. Currently drivers sharing reset lines (refcnt > 1)
and then using the non-shared reset control functions are bound to cause
unexpected behaviour. Now we can detect this for the first time.

> >>if (rstc->rcdev->ops->deassert)
> >> -  return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->id);
> >> +  return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->line->id);
> >>
> >>return -ENOTSUPP;
> >>   }
> >>   EXPORT_SYMBOL_GPL(reset_control_deassert);
> >>
> >>   /**
> >> + * reset_control_assert_shared - asserts a shared reset line
> >> + * @rstc: reset controller
> >> + *
> >> + * Assert a shared reset line, this functions decreases the deassert count
> >> + * of the line by one and asserts it if, and only if, the deassert count
> >> + * reaches 0.
> >
> > "After calling this function the shared reset line may be asserted, or
> >   it may still be deasserted, as long as other users keep it so."
> 
> I take it this is to replace the text about "deassert count" ?

I thought you might append something like it. I just imagine that when
reading the documentation it might be helpful to also see the intended
effect described, especially given that a call to an _assert_ function
might leave the reset line in deasserted state, depending on the
refcount.

> >> + */
> >> +int reset_control_assert_shared(struct reset_control *rstc)
> >> +{
> >> +  if (!rstc->rcdev->ops->assert)
> >> +  return -ENOTSUPP;
> >
> > WARN_ON(rstc->line->deassert_cnt == 0)
> >
> > Actually, what to do in this case? Assume ops->assert was called, or do
> > it again to be sure? Certainly we don't want to wrap deassert_cnt, or
> > the next deassert_shared will do nothing.
> >
> >> +  rstc->line->deassert_cnt--;
> >> +  if (rstc->line->deassert_cnt)
> >
> > deassert_cnt isn't protected by any lock.
> 
> Right, good catch. I believe the best way to fix this is to change 
> deassert_cnt
> into an atomic_t and use atomic_dec_return / atomic_int_return,

Yes, that would work.

> Downside of using an atomic_t is that doing the WARN_ON you are asking for 
> above
> will not be race free, then, but since it is a should never happen scenario I
> guess we do not care about the check not being 100% race free. Or we can even
> just leave out the check ?

Since this is only a warning to notify driver developers we don't
support shared resets (apart from the clock-like use)

Not if we warn about refcnt instead of deassert_cnt above.

[...]
> >> + * of the line by one and deasserts the reset line (if it was not already
> >> + * deasserted).
> >
> > "After calling this function, the shared reset line is guaranteed to be
> >   deasserted."
> 
> Same question as above.

Same imprecise answer. I'd like to see the expected state after calling
this function in the description, in addition to the mechanism. This is
more important for the assert function. After calling deassert, the
reset line is deasserted, no reason to be surprised about that.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants

[Maxime Ripard]

Hi,

On Fri, Dec 11, 2015 at 04:41:58PM +0100, Hans de Goede wrote:
> diff --git a/include/linux/reset.h b/include/linux/reset.h
> index c4c097d..1cca8ce 100644
> --- a/include/linux/reset.h
> +++ b/include/linux/reset.h
> @@ -11,6 +11,8 @@ int reset_control_reset(struct reset_control *rstc);
>  int reset_control_assert(struct reset_control *rstc);
>  int reset_control_deassert(struct reset_control *rstc);
>  int reset_control_status(struct reset_control *rstc);
> +int reset_control_assert_shared(struct reset_control *rstc);
> +int reset_control_deassert_shared(struct reset_control *rstc);

Shouldn't that be handled in reset_control_get directly?

That would allow to share more code between the implementations, since
it would just be a flag to test in the get and not duplicate the
function definitions, and we could simply rely on the refcount to know
if we have to actually assert / deassert the device, in all the cases
(shared or not).

That would also allow us to catch easily if we're going to be able a
shared reset line or not, with the regular reset_control_get being
exclusive, and reset_control_get_shared or reset_control_get(..,
RESET_SHARED) being shared.

It would also avoid ending up with the shared variant used in every
generic driver eventually. We could just use the variant to see if we
have to use the shared get or not, and the rest of the driver is left
untouched, which is way less intrusive.

Moreover, it's also pretty much the pattern used everywhere else
(irqs, regulator, clocks, etc.), so it's going to be easier to review
as well.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [RFC][PATCH] misc: Introduce reboot_reason driver

[Rob Herring]

On Thu, Dec 10, 2015 at 4:11 PM, Arnd Bergmann  wrote:
> On Thursday 10 December 2015 13:43:16 John Stultz wrote:
>> On Thu, Dec 10, 2015 at 12:24 PM, Rob Herring  wrote:
>> > The fact that we are using notifiers for reset reason and triggering
>> > is probably some indication that some infrastructure is needed. But I
>> > don't think you need to do that here as long as it is all kernel
>> > internals. We'll make the 2nd guy do it.
>>
>>
>>
>> Though, just so I understand better, what is problematic w/ the reset
>> notifiers? They provide the reboot command argument, which is the core
>> of what is needed. It actually seemed like it was almost designed with
>> this problem in mind.
>
> Notifiers in general are a bit of a kludge. We often use them in places
> that have not been abstracted well enough yet, and they make it
> less obvious what is actually going on when something happens, or
> in what order things are called.

Exactly.

> I'm actually less worried about the notifier side here than about
> the general problem of the communication channel. The reboot reason
> is only one of a number of things that the kernel needs to communicate
> to the boot loader. Other things may include:

If only there was a standard interface for firmware variable storage...

> - boot device
> - location of the kernel
> - command line
> - properties of the /chosen DT node in general
> - boot scripts
> - ethernet MAC addresses
> - bootloader console configuration

A major distinction here is many of these would be persistent (i.e. in
flash). As much of this goes into to the DT anyway, a standard way for
userspace to update the DT could solve this. That would not really
work for handling a one time case unless you supported boot with an
alternate DT.

I've also seen storing of SD tuning parameters to avoid tuning at boot
up. Although, the tuning doesn't add that much to the boot time
relative to Android boot, so I don't really see the point.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Device tree binding documentation for gpio-switch

[Rob Herring]

On Mon, Dec 14, 2015 at 8:28 AM, Linus Walleij  wrote:
> On Fri, Dec 11, 2015 at 3:06 PM, Rob Herring  wrote:
>> On Fri, Dec 11, 2015 at 6:39 AM, Linus Walleij  
>> wrote:
>>> On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch
>>>  wrote:

[...]

>>> Markus Pargmann also did a series that add initial values to
>>> hogs, which is the inverse usecase of this, where you want to
>>> *output* something by default, then maybe also make it available
>>> to userspace.
>>>
>>> So what we need to see here is a patch series that does all of these
>>> things:
>>>
>>> - Name lines
>>>
>>> - Sets them to initial values
>>>
>>> - Mark them as read-only
>>>
>>> - Mark them as "not used by the operating system" so that they
>>>   can be default-exported to userspace.
>>
>> No! This should not be a DT property.
>>
>> Whether I want to control a GPIO in the kernel or userspace is not
>> known and can change over time. It could simply depend on kernel
>> config. There is also the case that a GPIO has no connection or kernel
>> driver until some time later when a DT overlay for an expansion board
>> is applied.
>
> That's correct. So from a DT point of view, what really matters is
> to give things a name, and the hogs and initvals syntax already
> has a structure for this that is in use
> (from Documentation/devicetree/bindings/gpio/gpio.txt):
>
> qe_pio_a: gpio-controller@1400 {
> compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
> reg = <0x1400 0x18>;
> gpio-controller;
> #gpio-cells = <2>;
>
> line_b {
> gpio-hog;
> gpios = <6 0>;
> output-low;
> line-name = "foo-bar-gpio";
> };
> };
>
> Markus use this also for initial values. That could easily be used in
> a budget version like this:
>
> line_b {
> /* Just naming */
> gpios = <6 0>;
> line-name = "foo-bar-gpio";
> };
>
> That could grow kind of big though. Or maybe not? How many
> GPIO lines are actually properly named in a typical system?

We should limit it to GPIOs with no connection to another node. For
example, I don't want to see a SD card detect in the list as that
should be in the SD host node. However, that is hard to enforce and
can change over time. Removing it would break userspace potentially.
Of course if the kernel starts own a signal that userspace used, then
that potentially breaks userspace regardless of the DT changing. OTOH,
using GPIOs in userspace is kind of use at your own risk.

The only real differences between this and Martyn's proposal are the
location of the nodes and having a compatible string. A compatible
string may be good to have. It indicates type of signal, but not
specific use. Similar to how gpio-key compatible defines the function,
but not what key code, or gpio-led does not say what color LED. A
compatible here could cover switches, mode/id/revision strapping
signals, jumpers, presence detect, etc.

> The problem is that naming is usually imposed by consumers (they
> are the ones who know how the line is used).
>
> And then I do not mean naming it after the pin on the capsule
> where it comes out as per the datasheet, but
> naming it after the actual use.

Right. We need a way to query "I need the GPIO that does X" which
works across boards.

> Naming it after the hardware specs is something the operating
> system can do, in Linux' case by the array char *names; inside the
> struct gpio_chip and should not be part of the bindings IMO.

Agreed. That just came up with STM32 gpio bindings[1].

> I would rather imagine this is something used in a top-level board
> file naming it: "header-2-22" for the 22nd pin on some second header
> on my BeagleBone Black or something like that. And those may not
> be so vast in numbers so they could be named using this pattern.

Exactly. This is one of the cases I care about. However, this is not
really a function, but it is SOC independent at least.

We also have to consider how to handle add-on boards. We probably need
a connector node which can remap connector signals to host signals in
order to have overlays independent of the host board DT. For GPIOs
this is probably a gpio-map property similar to interrupt-map. The
complicated part will be connectors that require pinmux setup of the
host.

Rob

[1] https://lkml.org/lkml/2015/12/11/600
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/7] media: vb2-dma-contig: add helper for setting dma max seg size

[Laurent Pinchart]

Hi Marek,

On Monday 14 December 2015 10:20:22 Marek Szyprowski wrote:
> On 2015-12-13 20:57, Laurent Pinchart wrote:
> > On Wednesday 09 December 2015 14:58:19 Marek Szyprowski wrote:
> >> Add a helper function for device drivers to set DMA's max_seg_size.
> >> Setting it to largest possible value lets DMA-mapping API always create
> >> contiguous mappings in DMA address space. This is essential for all
> >> devices, which use dma-contig videobuf2 memory allocator and shared
> >> buffers.
> >> 
> >> Signed-off-by: Marek Szyprowski 
> >> ---
> >> 
> >>   drivers/media/v4l2-core/videobuf2-dma-contig.c | 15 +++
> >>   include/media/videobuf2-dma-contig.h   |  1 +
> >>   2 files changed, 16 insertions(+)
> >> 
> >> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >> b/drivers/media/v4l2-core/videobuf2-dma-contig.c index c331272..628518d
> >> 100644
> >> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >> @@ -742,6 +742,21 @@ void vb2_dma_contig_cleanup_ctx(void *alloc_ctx)
> >> 
> >>   }
> >>   EXPORT_SYMBOL_GPL(vb2_dma_contig_cleanup_ctx);
> >> 
> >> +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int
> >> size)
> >> +{
> >> +  if (!dev->dma_parms) {
> > 
> > When can this function be called with dev->dma_parms not NULL ?
> 
> When one loads a module with multimedia driver (which calls this
> function), then unloads and loads it again. It is rather safe to have this
> check.

Don't you have a much bigger problem in that case ? When you unload the module 
the device will be unbound from the driver, causing the memory allocated by 
devm_kzalloc to be freed. dev->dma_parms will then point to freed memory, 
which will get reused by all subsequent calls to dma_get_max_seg_size(), 
dma_get_max_seg_size() & co (including the ones in this function).

> >> +  dev->dma_parms = devm_kzalloc(dev, sizeof(dev->dma_parms),
> >> +GFP_KERNEL);
> >> +  if (!dev->dma_parms)
> >> +  return -ENOMEM;
> >> +  }
> >> +  if (dma_get_max_seg_size(dev) < size)
> >> +  return dma_set_max_seg_size(dev, size);
> >> +
> >> +  return 0;
> >> +}
> >> +EXPORT_SYMBOL_GPL(vb2_dma_contig_set_max_seg_size);
> >> +
> >>   MODULE_DESCRIPTION("DMA-contig memory handling routines for
> >>   videobuf2");
> >>   MODULE_AUTHOR("Pawel Osciak ");
> >>   MODULE_LICENSE("GPL");
> >> diff --git a/include/media/videobuf2-dma-contig.h
> >> b/include/media/videobuf2-dma-contig.h index c33dfa6..0e6ba64 100644
> >> --- a/include/media/videobuf2-dma-contig.h
> >> +++ b/include/media/videobuf2-dma-contig.h
> >> @@ -26,6 +26,7 @@ vb2_dma_contig_plane_dma_addr(struct vb2_buffer *vb,
> >> unsigned int plane_no)
> >>  void *vb2_dma_contig_init_ctx(struct device *dev);
> >>  void vb2_dma_contig_cleanup_ctx(void *alloc_ctx);
> >> +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int
> >> size);
> >>  extern const struct vb2_mem_ops vb2_dma_contig_memops;

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/4] ASoC: sun4i-codec: Add support for PA gpio pin

[Maxime Ripard]

Hi,

On Fri, Dec 11, 2015 at 07:43:57PM +0100, Hans de Goede wrote:
> Add support for PA gpio pin for controlling an external amplifier as used
> on some Allwinner boards.
> 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Use a dapm speaker widget (SND_SOC_DAPM_SPK) to control the gpio
> -Rename gpio in devicetree from pa-gpios to allwinner,pa-gpios
> ---
>  .../devicetree/bindings/sound/sun4i-codec.txt  |  3 ++
>  sound/soc/sunxi/sun4i-codec.c  | 35 
> ++
>  2 files changed, 38 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt 
> b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
> index c92966b..0dce690 100644
> --- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
> +++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
> @@ -14,6 +14,9 @@ Required properties:
> - "apb": the parent APB clock for this controller
> - "codec": the parent module clock
>  
> +Optional properties:
> +- allwinner,pa-gpios: gpio to enable external amplifier
> +
>  Example:
>  codec: codec@01c22c00 {
>   #sound-dai-cells = <0>;
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 519ccb3..e6cc6a1 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -103,6 +104,7 @@ struct sun4i_codec {
>   struct regmap   *regmap;
>   struct clk  *clk_apb;
>   struct clk  *clk_module;
> + struct gpio_desc *gpio_pa;
>  
>   struct snd_dmaengine_dai_dma_data   capture_dma_data;
>   struct snd_dmaengine_dai_dma_data   playback_dma_data;
> @@ -709,6 +711,26 @@ static struct snd_soc_dai_link 
> *sun4i_codec_create_link(struct device *dev,
>   return link;
>  };
>  
> +static int sun4i_codec_spk_event(struct snd_soc_dapm_widget *w,
> +  struct snd_kcontrol *k, int event)
> +{
> + struct sun4i_codec *scodec = snd_soc_card_get_drvdata(w->dapm->card);
> +
> + if (scodec->gpio_pa)
> + gpiod_set_value_cansleep(scodec->gpio_pa,
> +  !!SND_SOC_DAPM_EVENT_ON(event));
> +
> + return 0;
> +}
> +
> +static const struct snd_soc_dapm_widget sun4i_codec_card_dapm_widgets[] = {
> + SND_SOC_DAPM_SPK("Speaker", sun4i_codec_spk_event),
> +};
> +
> +static const struct snd_soc_dapm_route sun4i_codec_card_dapm_routes[] = {
> + { "Speaker", NULL, "Power Amplifier" },
> +};

Shouldn't it be tied to the HP outputs instead?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [linux-sunxi] Re: [PATCH v2 2/4] ASoC: sun4i-codec: Add support for PA gpio pin

[Hans de Goede]

Hi,

On 14-12-15 16:56, Maxime Ripard wrote:

Hi,

On Fri, Dec 11, 2015 at 07:43:57PM +0100, Hans de Goede wrote:

Add support for PA gpio pin for controlling an external amplifier as used
on some Allwinner boards.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Use a dapm speaker widget (SND_SOC_DAPM_SPK) to control the gpio
-Rename gpio in devicetree from pa-gpios to allwinner,pa-gpios
---
  .../devicetree/bindings/sound/sun4i-codec.txt  |  3 ++
  sound/soc/sunxi/sun4i-codec.c  | 35 ++
  2 files changed, 38 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt 
b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index c92966b..0dce690 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -14,6 +14,9 @@ Required properties:
 - "apb": the parent APB clock for this controller
 - "codec": the parent module clock

+Optional properties:
+- allwinner,pa-gpios: gpio to enable external amplifier
+
  Example:
  codec: codec@01c22c00 {
#sound-dai-cells = <0>;
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 519ccb3..e6cc6a1 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -28,6 +28,7 @@
  #include 
  #include 
  #include 
+#include 

  #include 
  #include 
@@ -103,6 +104,7 @@ struct sun4i_codec {
struct regmap   *regmap;
struct clk  *clk_apb;
struct clk  *clk_module;
+   struct gpio_desc *gpio_pa;

struct snd_dmaengine_dai_dma_data   capture_dma_data;
struct snd_dmaengine_dai_dma_data   playback_dma_data;
@@ -709,6 +711,26 @@ static struct snd_soc_dai_link 
*sun4i_codec_create_link(struct device *dev,
return link;
  };

+static int sun4i_codec_spk_event(struct snd_soc_dapm_widget *w,
+struct snd_kcontrol *k, int event)
+{
+   struct sun4i_codec *scodec = snd_soc_card_get_drvdata(w->dapm->card);
+
+   if (scodec->gpio_pa)
+   gpiod_set_value_cansleep(scodec->gpio_pa,
+!!SND_SOC_DAPM_EVENT_ON(event));
+
+   return 0;
+}
+
+static const struct snd_soc_dapm_widget sun4i_codec_card_dapm_widgets[] = {
+   SND_SOC_DAPM_SPK("Speaker", sun4i_codec_spk_event),
+};
+
+static const struct snd_soc_dapm_route sun4i_codec_card_dapm_routes[] = {
+   { "Speaker", NULL, "Power Amplifier" },
+};


Shouldn't it be tied to the HP outputs instead?


You're right, the HP outputs are the final outputs, and since this is
for enabling an external amplifier you're right. Since Mark has already
merged this patch I will do a follow up patch to fix this.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] arm64: dts: r8a7795: Add Cortex-A57 CPU cores

[Dirk Behme]

On 15.12.2015 06:12, Simon Horman wrote:

On Sat, Dec 12, 2015 at 08:07:51AM +0900, Simon Horman wrote:

On Fri, Dec 04, 2015 at 02:38:52PM +0100, Dirk Behme wrote:

From: Gaku Inami 

Add Cortex-A57 CPU cores to r8a7795 SoC for a total of 4 x Cortex-A57.

Signed-off-by: Gaku Inami 
Signed-off-by: Takeshi Kihara 
Sigend-off-by: Dirk Behme 


Thanks, I have queued this up for v4.5.


I meant to test this earlier but somehow it slopped my mind.

With this patch applied I still only see one CPU brought up
whereas I was expecting 4. Are more patches needed in order to
get more CPUs operating?



Hmm, I don't think so (?).

I tested this with

https://github.com/dirkbehme/linux-renesas-rcar-gen3/commits/dirk/gen3-latest-update

and got (including the A53 patch)

...
ASID allocator initialised with 65536 entries

Detected PIPT I-cache on CPU1

CPU1: Booted secondary processor [411fd073]

Detected PIPT I-cache on CPU2

CPU2: Booted secondary processor [411fd073]

Detected PIPT I-cache on CPU3

CPU3: Booted secondary processor [411fd073]

Detected VIPT I-cache on CPU4

CPU features: enabling workaround for ARM erratum 845719

CPU4: Booted secondary processor [410fd034]

Detected VIPT I-cache on CPU5

CPU5: Booted secondary processor [410fd034]

Detected VIPT I-cache on CPU6

CPU6: Booted secondary processor [410fd034]

Detected VIPT I-cache on CPU7

CPU7: Booted secondary processor [410fd034]

Brought up 8 CPUs

SMP: Total of 8 processors activated.

CPU: All CPU(s) started at EL1
...

This is based on last weeks renesas-drivers-2015-12-08-v4.4-rc4 and 
besides the patches for SDHI/eMMC I don't think it contains anything 
additional regarding the number of CPU cores.


Best regards

Dirk

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 4/5] iommu/mediatek: Add mt8173 IOMMU driver

[Yong Wu]

On Mon, 2015-12-14 at 15:16 +0100, Joerg Roedel wrote:
> On Tue, Dec 08, 2015 at 05:49:12PM +0800, Yong Wu wrote:
> > +static int mtk_iommu_attach_device(struct iommu_domain *domain,
> > +  struct device *dev)
> > +{
> > +   struct mtk_iommu_domain *dom = to_mtk_domain(domain);
> > +   struct mtk_iommu_client_priv *priv = dev->archdata.iommu;
> > +   struct mtk_iommu_data *data;
> > +   int ret;
> > +
> > +   if (!priv)
> > +   return -ENODEV;
> > +
> > +   data = dev_get_drvdata(priv->m4udev);
> > +   if (!data) {
> > +   /*
> > +* The DMA core will run earlier than this probe, and it will
> > +* create a default iommu domain for each a iommu device.
> > +* But here there is only one domain called the m4u domain
> > +* which all the multimedia HW share.
> > +* The default domain isn't needed here.
> > +*/
> 
> The iommu core creates one domain per iommu-group. In your case this
> means one default domain per iommu in the system.

Yes. The iommu core will create one domain per iommu-group.
see the next "if" here.

But the domain here is created by the current DMA64. It's from this
function do_iommu_attach which will be called too early and will help
create a default domain for each a iommu device.(my codebase is
v4.4-rc1).


//=the next "if"===
} else if (!data->m4u_dom) {
/*
 * While a device is added into a iommu group, the iommu core
 * will create a default domain for each a iommu group.
 * This default domain is reserved as the m4u domain and is
 * initiated here.
 */
data->m4u_dom = dom;
if (domain->type == IOMMU_DOMAIN_DMA) {
ret = iommu_dma_init_domain(domain, 0,
DMA_BIT_MASK(32));
if (ret)
goto err_uninit_dom;
}

ret = mtk_iommu_domain_finalise(data);
if (ret)
goto err_uninit_dom;
} 
//==

> 
> > +   iommu_domain_free(domain);
> 
> This function is not supposed to free the domain passed to it.

As above this domain is created in the do_iommu_attach which will help
create a default domain for each a iommu device.
We don't need this default domain!

If we don't free it here, there will be a memory leak.

>From Robin's comment, He will improve the sequence of the
__iommu_setup_dma_ops in the future.

/*
 * TODO: Right now __iommu_setup_dma_ops() gets called too early to do
 * everything it needs to - the device is only partially created and the
 * IOMMU driver hasn't seen it yet, so it can't have a group. Thus we
 * need this delayed attachment dance. Once IOMMU probe ordering is
sorted
 * to move the arch_setup_dma_ops() call later, all the notifier bits
below
 * become unnecessary, and will go away.
 */

/*
 * Best case: The device is either part of a group which was
 * already attached to a domain in a previous call, or it's
 * been put in a default DMA domain by the IOMMU core.
 */

   But there is no this patch currently, so I add iommu_domain_free
here.
 
   "free the domain" here looks really not good. Then I delete the
iommu_domain_free here(allow this memory leak right now), is it ok?
(It will also works after Robin's change in the future.)

> 
> > +static int mtk_iommu_add_device(struct device *dev)
> > +{
> > +   struct iommu_group *group;
> > +
> > +   if (!dev->archdata.iommu) /* Not a iommu client device */
> > +   return -ENODEV;
> > +
> > +   group = iommu_group_get_for_dev(dev);
> > +   if (IS_ERR(group))
> > +   return PTR_ERR(group);
> > +
> > +   iommu_group_put(group);
> > +   return 0;
> > +}
> 
> [...]
> 
> > +static struct iommu_group *mtk_iommu_device_group(struct device *dev)
> > +{
> > +   struct mtk_iommu_data *data;
> > +   struct mtk_iommu_client_priv *priv;
> > +
> > +   priv = dev->archdata.iommu;
> > +   if (!priv)
> > +   return ERR_PTR(-ENODEV);
> > +
> > +   /* All the client devices are in the same m4u iommu-group */
> > +   data = dev_get_drvdata(priv->m4udev);
> > +   if (!data->m4u_group) {
> > +   data->m4u_group = iommu_group_alloc();
> > +   if (IS_ERR(data->m4u_group))
> > +   dev_err(dev, "Failed to allocate M4U IOMMU group\n");
> > +   }
> > +   return data->m4u_group;
> > +}
> 
> This looks much better than before, thanks.

Thanks.

> 


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] net/macb: add support for resetting PHY using GPIO

[Florian Fainelli]

On December 14, 2015 2:56:34 PM PST, Rob Herring  wrote:
>On Fri, Dec 11, 2015 at 11:34:53AM +0100, Gregory CLEMENT wrote:
>> With device tree it is no more possible to reset the PHY at board
>> level. Furthermore, doing in the driver allow to power down the PHY
>when
>> the network interface is no more used.
>> 
>> This reset can't be done at the PHY driver level. The PHY must be
>able to
>> answer the to the mii bus scan to let the kernel creating a PHY
>device.
>> 
>> The patch introduces a new optional property "phy-reset-gpios"
>inspired
>> from the one use for the FEC.
>> 
>> Signed-off-by: Gregory CLEMENT 
>> ---
>> 
>> Since the v1, I used the gpiod functions. It allows to simplify the
>> code and to not introduce any #ifdef.
>> 
>> I also rename the property in phy-reset-gpios, even if actually the
>> gpiod will match both phy-reset-gpios and phy-reset-gpio.
>> 
>> 
>>  Documentation/devicetree/bindings/net/macb.txt | 3 +++
>>  drivers/net/ethernet/cadence/macb.c| 8 
>>  drivers/net/ethernet/cadence/macb.h| 1 +
>>  3 files changed, 12 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/net/macb.txt
>b/Documentation/devicetree/bindings/net/macb.txt
>> index b5d7976..4a7fb6c 100644
>> --- a/Documentation/devicetree/bindings/net/macb.txt
>> +++ b/Documentation/devicetree/bindings/net/macb.txt
>> @@ -19,6 +19,9 @@ Required properties:
>>  Optional elements: 'tx_clk'
>>  - clocks: Phandles to input clocks.
>>  
>> +Optional properties:
>> +- phy-reset-gpios : Should specify the gpio for phy reset
>> +
>
>This alone is simple enough, but I worry that this doesn't really
>scale. 
>What if you need to enable clocks or regulators for the same reason?
>The 
>mmc folks did a pwrseq binding for similar reasons. I don't think I'd 
>recommend that here as I think it is kind of ugly. We really need a 
>pre-probe/scan hook for drivers. This is also needed for USB devices 
>mounted on boards.

In this particular case, the way Ethernet MAC drivers register their MDIO buses 
and therefore PHYs, there is always a good way to deassert the PHY GPIO line 
without requiring major core device driver changes. Worst case, there is the 
MDIO bus reset callback which could used for that matter.

In the case of PCI, USB etc. I do agree having a way to twiddle things before 
scanning/probing would be awesome. I have some boards here which have GPIO 
controlled regulator and hacking the RC driver to deal with that is 
suboptimal... 

>
>But I'm not going to hold up something simple to do all that, so:
>
>Acked-by: Rob Herring 
>
>___
>linux-arm-kernel mailing list
>linux-arm-ker...@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver

[Krzysztof Kozlowski]

On 14.12.2015 15:38, Chanwoo Choi wrote:
> This patch adds the generic exynos bus frequency driver for AMBA AXI bus
> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
> have the common architecture for bus between DRAM and sub-blocks in SoC.
> This driver can support the generic bus frequency driver for Exynos SoCs.
> 
> In devicetree, Each bus block has a bus clock, regulator, operation-point
> and devfreq-event devices which measure the utilization of each bus block.
> 
> Signed-off-by: Chanwoo Choi 
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon 
> ---
>  drivers/devfreq/Kconfig |  15 ++
>  drivers/devfreq/Makefile|   1 +
>  drivers/devfreq/exynos/Makefile |   1 +
>  drivers/devfreq/exynos/exynos-bus.c | 449 
> 
>  4 files changed, 466 insertions(+)
>  create mode 100644 drivers/devfreq/exynos/exynos-bus.c
> 
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 64281bb2f650..55ec774f794c 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -66,6 +66,21 @@ config DEVFREQ_GOV_USERSPACE
>  
>  comment "DEVFREQ Drivers"
>  
> +config ARM_EXYNOS_BUS_DEVFREQ
> + bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
> + depends on ARCH_EXYNOS
> + select DEVFREQ_GOV_SIMPLE_ONDEMAND
> + select DEVFREQ_EVENT_EXYNOS_PPMU
> + select PM_DEVFREQ_EVENT
> + select PM_OPP
> + help
> +   This adds the common DEVFREQ driver for Exynos Memory bus. Exynos
> +   Memory bus has one more group of memory bus (e.g, MIF and INT block).
> +   Each memory bus group could contain many memoby bus block. It reads
> +   PPMU counters of memory controllers by using DEVFREQ-event device
> +   and adjusts the operating frequencies and voltages with OPP support.
> +   This does not yet operate with optimal voltages.
> +
>  config ARM_EXYNOS4_BUS_DEVFREQ
>   bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
>   depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) && 
> !ARCH_MULTIPLATFORM
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 5134f9ee983d..375ebbb4fcfb 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE)   += governor_powersave.o
>  obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)  += governor_userspace.o
>  
>  # DEVFREQ Drivers
> +obj-$(CONFIG_ARCH_EXYNOS)+= exynos/

Why limiting it to ARCH_EXYNOS? Are there real dependencies on exynos
mach code? Or on ARM code?

If not, then this probably should be obj-y to allow compile testing.
Particular objects would be selected by ARM_EXYNOS_BUS_DEVFREQ.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] arm64: dts: r8a7795: Add Cortex-A57 CPU cores

[Simon Horman]

On Sat, Dec 12, 2015 at 08:07:51AM +0900, Simon Horman wrote:
> On Fri, Dec 04, 2015 at 02:38:52PM +0100, Dirk Behme wrote:
> > From: Gaku Inami <gaku.inami...@bp.renesas.com>
> > 
> > Add Cortex-A57 CPU cores to r8a7795 SoC for a total of 4 x Cortex-A57.
> > 
> > Signed-off-by: Gaku Inami <gaku.inami...@bp.renesas.com>
> > Signed-off-by: Takeshi Kihara <takeshi.kihara...@renesas.com>
> > Sigend-off-by: Dirk Behme <dirk.be...@gmail.com>
> 
> Thanks, I have queued this up for v4.5.

I meant to test this earlier but somehow it slopped my mind.

With this patch applied I still only see one CPU brought up
whereas I was expecting 4. Are more patches needed in order to
get more CPUs operating?

I am using renesas-devel-20151214-v4.4-rc5 + the cpg-mmsr driver (v6).
I built the kernel using the defconfig.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 3/5] memory: mediatek: Add SMI driver

[Daniel Kurtz]

Hi Yong,

On Tue, Dec 15, 2015 at 10:38 AM, Yong Wu  wrote:
> On Mon, 2015-12-14 at 19:18 +0100, Matthias Brugger wrote:
>> On Tuesday 08 Dec 2015 17:49:11 Yong Wu wrote:
>> > This patch add SMI(Smart Multimedia Interface) driver. This driver
>> > is responsible to enable/disable iommu and control the power domain
>> > and clocks of each local arbiter.
>> >
>> > Signed-off-by: Yong Wu 
>> > ---
>> >   Currently SMI offer mtk_smi_larb_get/put to enable the power-domain
>> > ,clocks and initialize the iommu configuration register for each a local
>> > arbiter, The reason is:
>> >   a) If a device would like to disable iommu, it also need call
>> > mtk_smi_larb_get/put to enable its power and clocks.
>> >   b) The iommu core don't support attach/detach a device within a
>> > iommu-group. So we cann't use iommu_attach_device(iommu_detach_device)
>> > instead
>> > of mtk_smi_larb_get/put.
>> >
> [..]
>> > +static int
>> > +mtk_smi_enable(struct device *dev, struct clk *apb, struct clk *smi)
>> > +{
>> > +   int ret;
>> > +
>> > +   ret = pm_runtime_get_sync(dev);
>> > +   if (ret < 0)
>> > +   return ret;
>> > +
>> > +   ret = clk_prepare_enable(apb);
>> > +   if (ret)
>> > +   goto err_put_pm;
>> > +
>> > +   ret = clk_prepare_enable(smi);
>> > +   if (ret)
>> > +   goto err_disable_apb;
>> > +
>> > +   return 0;
>> > +
>> > +err_disable_apb:
>> > +   clk_disable_unprepare(apb);
>> > +err_put_pm:
>> > +   pm_runtime_put_sync(dev);
>> > +   return ret;
>> > +}
>> > +
>> > +static void
>> > +mtk_smi_disable(struct device *dev, struct clk *apb, struct clk *smi)
>> > +{
>> > +   clk_disable_unprepare(smi);
>> > +   clk_disable_unprepare(apb);
>> > +   pm_runtime_put_sync(dev);
>> > +}
>> > +
>> > +static int mtk_smi_common_enable(struct mtk_smi_common *common)
>> > +{
>> > +   return mtk_smi_enable(common->dev, common->clk_apb, common->clk_smi);
>> > +}
>> > +
>> > +static void mtk_smi_common_disable(struct mtk_smi_common *common)
>> > +{
>> > +   mtk_smi_disable(common->dev, common->clk_apb, common->clk_smi);
>> > +}
>> > +
>> > +static int mtk_smi_larb_enable(struct mtk_smi_larb *larb)
>> > +{
>> > +   return mtk_smi_enable(larb->dev, larb->clk_apb, larb->clk_smi);
>> > +}
>> > +
>> > +static void mtk_smi_larb_disable(struct mtk_smi_larb *larb)
>> > +{
>> > +   mtk_smi_disable(larb->dev, larb->clk_apb, larb->clk_smi);
>> > +}
>> > +
>>
>> This is somehow over-engineered. Just use mtk_smi_enable and mtk_smi_disable
>> instead of adding an extra indirection.
>
> I added this only for readable...then the code in mtk_smi_larb_get below
> may looks simple and readable.
>
> If I use mtk_smi_enable/disable directly, the code will be like our
> v5[1], is it OK?
> Maybe I don't need these help function here, and only add more comment
> based on v5.
>
> [1]
> http://lists.linuxfoundation.org/pipermail/iommu/2015-October/014590.html

bike-shedding...

I like the fact that Yong is trying to make his helpers more type-safe.
But, perhaps we can rename "struct mtk_smi_common" as "struct
mtk_smi", and then make "struct mtk_smi_larb" contain a "struct
mtk_smi":

struct mtk_smi {
  struct device *dev;
  struct clk *clk_apb, *clk_smi;
}

struct mtk_smi_larb {
  struct mtk_smi;
  ...
}


Then, have:

int mtk_smi_enable(struct mtk_smi *smi)
{
  clk_enable(smi->clk_apb);
  ...
}

int mtk_smi_disable(struct mtk_smi *smi)
{
}

int mtk_smi_larb_get(struct device *larbdev)
{
  struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
  struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);

  mtk_smi_enable(common);
  mtk_smi_enable(>smi);
  ...
}

>>
>> > +int mtk_smi_larb_get(struct device *larbdev)
>> > +{
>> > +   struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
>> > +   struct mtk_smi_common *common = dev_get_drvdata(larb->smi_common_dev);
>> > +   int ret;
>> > +
>> > +   ret = mtk_smi_common_enable(common);
>> > +   if (ret)
>> > +   return ret;
>> > +
>> > +   ret = mtk_smi_larb_enable(larb);
>> > +   if (ret)
>> > +   goto err_put_smi;
>> > +
>> > +   /* Configure the iommu info */
>> > +   writel_relaxed(larb->mmu, larb->base + SMI_LARB_MMU_EN);

I think this should probably be writel() not writel_relaxed, since you
really do want the barrier to ensure all other register accesses have
completed before enabling the MMU.

>> > +
>> > +   return 0;
>> > +
>> > +err_put_smi:
>> > +   mtk_smi_common_disable(common);
>> > +   return ret;
>> > +}
>> > +
>> > +void mtk_smi_larb_put(struct device *larbdev)
>> > +{
>> > +   struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
>> > +   struct mtk_smi_common *common = dev_get_drvdata(larb->smi_common_dev);
>> > +
>> > +   writel_relaxed(0, larb->base + SMI_LARB_MMU_EN);
>> > +   mtk_smi_larb_disable(larb);
>> > +   mtk_smi_common_disable(common);
>> > +}
>> > +
>>
>> Looks strange that you just disable all MMUs while you only enable some of
>> them at runtime. Unfortunately the datasheet I have 

Re: [PATCH v3 2/3] usb: renesas_usbhs: add fallback compatibility strings

[Simon Horman]

On Fri, Dec 11, 2015 at 03:24:27PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/11/2015 5:12 AM, Simon Horman wrote:
> 
> >Add fallback compatibility strings for R-Car Gen2 and Gen3.
> >This is in keeping with the fallback scheme being adopted wherever
> >appropriate for drivers for Renesas SoCs.
> >
> >Signed-off-by: Simon Horman 
> >---
> >v3
> >* Moved documentation of SoC names to a separate patch
> >* Use correct fallback compatibility string in example
> >
> >v2
> >* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
> >   a single compatibility string for all of R-Car.
> >---
> >  Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 10 +-
> >  drivers/usb/renesas_usbhs/common.c  |  9 +
> >  2 files changed, 18 insertions(+), 1 deletion(-)
> >
> >diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
> >b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> >index a14c0bb561d5..c55cf77006d0 100644
> >--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> >+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> >@@ -2,10 +2,18 @@ Renesas Electronics USBHS driver
> >
> >  Required properties:
> >- compatible: Must contain one of the following:
> 
>Really?

Would "...one or more of the following" help?

> >+
> > - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
> > - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
> > - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
> > - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
> >+- "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
> >+- "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
> >+
> >+When compatible with the generic version, nodes must list the
> >+SoC-specific version corresponding to the platform first followed
> >+by the generic version.
> >+
> 
>This kinda contradicts the above claim.
> 
> [...]
> 
> MBR, Sergei
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller

[Yoshihiro Shimoda]

R-Car H3 has USB3.0 peripheral controllers. This controller's has the
following features:
 - Supports super, high and full speed
 - Contains 30 pipes for bulk or interrupt transfer
 - Contains dedicated DMA controller

This driver doesn't support the dedicated DMAC for now.

Signed-off-by: Yoshihiro Shimoda 
---
 This patch is based on the latest Felipe's usb.git / testing/next branch.
 (commit id = e9284de9fae69f1d5e57a4817bfc36dc5f3adf71)

 .../devicetree/bindings/usb/renesas_usb3.txt   |   23 +
 drivers/usb/gadget/udc/Kconfig |   11 +
 drivers/usb/gadget/udc/Makefile|1 +
 drivers/usb/gadget/udc/renesas_usb3.c  | 1720 
 drivers/usb/gadget/udc/renesas_usb3.h  |  284 
 5 files changed, 2039 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/renesas_usb3.txt
 create mode 100644 drivers/usb/gadget/udc/renesas_usb3.c
 create mode 100644 drivers/usb/gadget/udc/renesas_usb3.h

diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt 
b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
new file mode 100644
index 000..215eee7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
@@ -0,0 +1,23 @@
+Renesas Electronics USB3.0 Peripheral driver
+
+Required properties:
+  - compatible: Must contain one of the following:
+   - "renesas,usb3-peri-r8a7795"
+  - reg: Base address and length of the register for the USB3.0 Peripheral
+  - interrupts: Interrupt specifier for the USB3.0 Peripheral
+  - clocks: A list of phandle + clock specifier pairs
+
+Example:
+   usb3_peri0: usb@ee02 {
+   compatible = "renesas,usb3-peri-r8a7795";
+   reg = <0 0xee02 0 0x400>;
+   interrupts = ;
+   clocks = < CPG_MOD 328>;
+   };
+
+   usb3_peri1: usb@ee06 {
+   compatible = "renesas,usb3-peri-r8a7795";
+   reg = <0 0xee06 0 0x400>;
+   interrupts = ;
+   clocks = < CPG_MOD 327>;
+   };
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index cdbff54..753c29b 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -174,6 +174,17 @@ config USB_RENESAS_USBHS_UDC
   dynamically linked module called "renesas_usbhs" and force all
   gadget drivers to also be dynamically linked.
 
+config USB_RENESAS_USB3
+   tristate 'Renesas USB3.0 Peripheral controller'
+   depends on ARCH_SHMOBILE || COMPILE_TEST
+   help
+  Renesas USB3.0 Peripheral controller is a USB peripheral controller
+  that supports super, high, and full speed USB 3.0 data transfers.
+
+  Say "y" to link the driver statically, or "m" to build a
+  dynamically linked module called "renesas_usb3" and force all
+  gadget drivers to also be dynamically linked.
+
 config USB_PXA27X
tristate "PXA 27x"
help
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index fba2049..dfee534 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -19,6 +19,7 @@ fsl_usb2_udc-y:= fsl_udc_core.o
 fsl_usb2_udc-$(CONFIG_ARCH_MXC)+= fsl_mxc_udc.o
 obj-$(CONFIG_USB_M66592)   += m66592-udc.o
 obj-$(CONFIG_USB_R8A66597) += r8a66597-udc.o
+obj-$(CONFIG_USB_RENESAS_USB3) += renesas_usb3.o
 obj-$(CONFIG_USB_FSL_QE)   += fsl_qe_udc.o
 obj-$(CONFIG_USB_S3C_HSUDC)+= s3c-hsudc.o
 obj-$(CONFIG_USB_LPC32XX)  += lpc32xx_udc.o
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
new file mode 100644
index 000..f302c89
--- /dev/null
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -0,0 +1,1720 @@
+/*
+ * Renesas USB3.0 Peripheral driver (USB gadget)
+ *
+ * Copyright (C) 2015  Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "renesas_usb3.h"
+
+static const char udc_name[] = "renesas_usb3";
+
+static int renesas_usb3_ep_queue(struct usb_ep *_ep, struct usb_request *_req,
+gfp_t gfp_flags);
+static void usb3_start_pipen(struct renesas_usb3_ep *usb3_ep,
+struct renesas_usb3_request *usb3_req);
+
+static void usb3_write(struct renesas_usb3 *usb3, u32 data, u32 offs)
+{
+   iowrite32(data, usb3->reg + offs);
+}
+
+static u32 usb3_read(struct renesas_usb3 *usb3, u32 offs)
+{
+   return ioread32(usb3->reg + offs);
+}
+
+static void usb3_set_bit(struct renesas_usb3 *usb3, u32 bits, u32 offs)
+{
+   u32 val = usb3_read(usb3, 

[PATCH v6 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Jitao Shi]

This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi 
---
Changes since v5
-fix compile errors when CONFIG_GPIOLIB=n
---
 drivers/gpu/drm/bridge/Kconfig |   10 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/parade-ps8640.c |  472 
 3 files changed, 483 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 639..dcfdbc9 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -41,4 +41,14 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.
 
+config DRM_PARADE_PS8640
+   tristate "Parade PS8640 MIPI DSI to eDP Converter"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
+ Choose this option if you have PS8640 for display
+ The PS8640 is a high-performance and low-power
+ MIPI DSI to eDP converter
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d4e28be..272e3c01 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 000..bf0c3c37
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,472 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PAGE2_GPIO_L   0xa6
+#define PAGE2_GPIO_H   0xa7
+#define PS_GPIO9   BIT(1)
+#define PAGE2_I2C_BYPASS   0xea
+#define I2C_BYPASS_EN  0xd0
+
+#define PAGE3_SET_ADD  0xfe
+#define PAGE3_SET_VAL  0xff
+#define VDO_CTL_ADD0x13
+#define VDO_DIS0x18
+#define VDO_EN 0x1c
+
+#define PAGE4_REV_L0xf0
+#define PAGE4_REV_H0xf1
+#define PAGE4_CHIP_L   0xf2
+#define PAGE4_CHIP_H   0xf3
+
+#define bridge_to_ps8640(e)container_of(e, struct ps8640, bridge)
+#define connector_to_ps8640(e) container_of(e, struct ps8640, connector)
+
+struct ps8640 {
+   struct drm_connector connector;
+   struct drm_bridge bridge;
+   struct i2c_client *page[6];
+   struct ps8640_driver_data *driver_data;
+   struct regulator *pwr_1v2_supply;
+   struct regulator *pwr_3v3_supply;
+   struct drm_panel *panel;
+   struct gpio_desc *gpio_rst_n;
+   struct gpio_desc *gpio_slp_n;
+   struct gpio_desc *gpio_mode_sel_n;
+   bool enabled;
+};
+
+static int ps8640_regr(struct i2c_client *client, u8 reg, u8 *value)
+{
+   int ret;
+
+   ret = i2c_master_send(client, , 1);
+   if (ret <= 0) {
+   dev_err(>dev, "Failed to send i2c command, ret=%d\n",
+   ret);
+   return ret;
+   }
+
+   ret = i2c_master_recv(client, value, 1);
+   if (ret <= 0) {
+   dev_err(>dev, "Failed to recv i2c data, ret=%d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int ps8640_regw(struct i2c_client *client, u8 reg, u8 value)
+{
+   int ret;
+   char buf[2];
+
+   buf[0] = reg;
+   buf[1] = value;
+   ret = i2c_master_send(client, buf, ARRAY_SIZE(buf));
+   if (ret <= 0) {
+   dev_err(>dev, "Failed to send i2c command, ret=%d\n",
+   ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static bool ps8640_check_valid_id(struct ps8640 *ps_bridge)
+{
+   struct i2c_client *client = ps_bridge->page[4];
+   u8 rev_id_low, rev_id_high, chip_id_low, chip_id_high;
+   int retry_cnt = 0;
+
+   do {
+   ps8640_regr(client, PAGE4_CHIP_H, _id_high);
+   if (chip_id_high != 0x30)
+   dev_info(>dev, "chip_id_high = 0x%x\n",
+chip_id_high);
+   } while ((retry_cnt++ < 2) && (chip_id_high != 0x30));
+
+   

[PATCH v6 1/2] Documentation: bridge: Add documentation for ps8640 DT properties

[Jitao Shi]

Add documentation for DT properties supported by
ps8640 DSI-eDP converter.

Signed-off-by: Jitao Shi 
Acked-by: Rob Herring 
Reviewed-by: Philipp Zabel 
---
Changes since v5
-no changes
---
 .../devicetree/bindings/display/bridge/ps8640.txt  |   43 
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.txt 
b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
new file mode 100644
index 000..a3e0971
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
@@ -0,0 +1,43 @@
+ps8640-bridge bindings
+
+Required properties:
+   - compatible: "parade,ps8640"
+   - reg: first page address of the bridge.
+   - sleep-gpios: OF device-tree gpio specification for PD_ pin.
+   - reset-gpios: OF device-tree gpio specification for reset pin.
+   - mode-sel-gpios: OF device-tree gpio specification for mode-sel pin.
+   - vdd12-supply: OF device-tree regulator specification for 1.2V power.
+   - vdd33-supply: OF device-tree regulator specification for 3.3V power.
+   - ports: The device node can contain video interface port nodes per
+the video-interfaces bind[1]. For port@0,set the reg = <0> as
+ps8640 dsi in and port@1,set the reg = <1> as ps8640 eDP out.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   edp-bridge@18 {
+   compatible = "parade,ps8640";
+   reg = <0x18>;
+   sleep-gpios = < 116 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 115 GPIO_ACTIVE_HIGH>;
+   mode-sel-gpios = < 92 GPIO_ACTIVE_HIGH>;
+   vdd12-supply = <_fixed_1v2>;
+   vdd33-supply = <_vgp2_reg>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   ps8640_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   ps8640_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver

[Chanwoo Choi]

On 2015년 12월 14일 17:28, MyungJoo Ham wrote:
>>   
>>  This patch adds the generic exynos bus frequency driver for AMBA AXI bus
>> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
>> have the common architecture for bus between DRAM and sub-blocks in SoC.
>> This driver can support the generic bus frequency driver for Exynos SoCs.
>>
>> In devicetree, Each bus block has a bus clock, regulator, operation-point
>> and devfreq-event devices which measure the utilization of each bus block.
>>
>> Signed-off-by: Chanwoo Choi 
>> [linux.amoon: Tested on Odroid U3]
>> Tested-by: Anand Moon 
>>
> 
> Chanwoo, could you please show me testing this set of patches in your site?
> Please let me know when is ok to visit you.
> (I do not have exynos machines right now.)
> 
>> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
>> index 5134f9ee983d..375ebbb4fcfb 100644
>> --- a/drivers/devfreq/Makefile
>> +++ b/drivers/devfreq/Makefile
>> @@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE)  += governor_powersave.o
>>  obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o
>>  
>>  # DEVFREQ Drivers
>> +obj-$(CONFIG_ARCH_EXYNOS)   += exynos/
>>  obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)   += exynos/
>>  obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)   += exynos/
> 
> CONFIG_ARCH_EXYNOS is true if
>   CONFIG_ARM_EXYNOS4_BUS_DEVFREQ is true 
>   or
>   CONFIG_ARM_EXYNOS5_BUS_DEVFREQ is true
> Thus, the two lines after you've added have become useless. (dead code)
> 
> Please delete them.

In this series, patch11 deletes all of both exynos4_bus.c and exynos5_bus.c.

> 
> []
>> --- /dev/null
>> +++ b/drivers/devfreq/exynos/exynos-bus.c
> []
>> +static int exynos_bus_target(struct device *dev, unsigned long *freq, u32 
>> flags)
>> +{
>> +struct exynos_bus *bus = dev_get_drvdata(dev);
>> +struct dev_pm_opp *new_opp;
>> +unsigned long old_freq, new_freq, old_volt, new_volt;
>> +int ret = 0;
>> +
>> +/* Get new opp-bus instance according to new bus clock */
>> +rcu_read_lock();
>> +new_opp = devfreq_recommended_opp(dev, freq, flags);
>> +if (IS_ERR_OR_NULL(new_opp)) {
>> +dev_err(dev, "failed to get recommed opp instance\n");
>> +rcu_read_unlock();
>> +return PTR_ERR(new_opp);
>> +}
>> +
>> +new_freq = dev_pm_opp_get_freq(new_opp);
>> +new_volt = dev_pm_opp_get_voltage(new_opp);
>> +old_freq = dev_pm_opp_get_freq(bus->curr_opp);
>> +old_volt = dev_pm_opp_get_voltage(bus->curr_opp);
>> +rcu_read_unlock();
>> +
>> +if (old_freq == new_freq)
>> +return 0;
>> +
>> +/* Change voltage and frequency according to new OPP level */
>> +mutex_lock(>lock);
>> +
>> +if (old_freq < new_freq) {
>> +ret = regulator_set_voltage(bus->regulator, new_volt, new_volt);
> 
> Setting the maximum volt same as the minimum volt is not recommended.
> Especially for any DVFS mechanisms, I recommend to set values as:
> min_volt = minimum voltage that does not harm the stability
> max_volt = maximum voltage that does not break the circuit
> 
> Please refer to /include/linux/regulator/driver.h
> "@set_voltage" comments.
> 
> For the rest of regulator_set_voltage usages, I'd say the same.

OK.
I'll add the 'voltage-tolerance' property as cpufreq-dt.c driver.
The cpufreq-dt.c get the percentage value by using 'voltage-tolerance'
devicetree property.

For example,
if (of_property_read_u32(np, "exynos,voltage-tolerance",
>voltage_tolerance))
bus->voltage_tolerance = DEFAULT_VOLTAGE_TOLERANCE;

tol = new_volt * bus->voltage_tolerance / 100;
regulator_set_voltage_tol(regulator, new_volt, tol);

> 
> []
>> +static int exynos_bus_get_dev_status(struct device *dev,
>> + struct devfreq_dev_status *stat)
>> +{
>> +struct exynos_bus *bus = dev_get_drvdata(dev);
>> +struct devfreq_event_data edata;
>> +int ret;
>> +
>> +rcu_read_lock();
>> +stat->current_frequency = dev_pm_opp_get_freq(bus->curr_opp);
>> +rcu_read_unlock();
>> +
>> +ret = exynos_bus_get_event(bus, );
>> +if (ret < 0) {
>> +stat->total_time = stat->busy_time = 0;
>> +goto err;
>> +}
>> +
>> +stat->busy_time = (edata.load_count * 100) / bus->ratio;
>> +stat->total_time = edata.total_count;
>> +
>> +dev_dbg(dev, "Usage of devfreq-event : %ld/%ld\n", stat->busy_time,
>> +stat->total_time);
> 
> These two values are unsigned long.

OK. I'll modify it (%ld -> %lu)

> 
> []
>> +static int exynos_bus_parse_of(struct device_node *np,
>> +  struct exynos_bus *bus)
>> +{
>> +struct device *dev = bus->dev;
>> +unsigned long rate;
>> +int i, ret, count, size;
>> +
>> +/* Get the clock to provide each bus with source clock */
>> +

Re: [PATCH v6 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Archit Taneja]

Hi,

On 12/15/2015 09:00 AM, Jitao Shi wrote:

This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi 
---
Changes since v5
-fix compile errors when CONFIG_GPIOLIB=n
---
  drivers/gpu/drm/bridge/Kconfig |   10 +
  drivers/gpu/drm/bridge/Makefile|1 +
  drivers/gpu/drm/bridge/parade-ps8640.c |  472 
  3 files changed, 483 insertions(+)
  create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 639..dcfdbc9 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -41,4 +41,14 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_PARADE_PS8640
+   tristate "Parade PS8640 MIPI DSI to eDP Converter"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
+ Choose this option if you have PS8640 for display
+ The PS8640 is a high-performance and low-power
+ MIPI DSI to eDP converter
+
  endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d4e28be..272e3c01 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 000..bf0c3c37
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,472 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 


This doesn't seem to be used at the moment.




+
+static int ps8640_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct device *dev = >dev;
+   struct ps8640 *ps_bridge;
+   struct device_node *np = dev->of_node;
+   struct device_node *port, *out_ep;
+   struct device_node *panel_node = NULL;
+   int i, ret;
+
+   ps_bridge = devm_kzalloc(dev, sizeof(*ps_bridge), GFP_KERNEL);
+   if (!ps_bridge)
+   return -ENOMEM;
+
+   /* port@1 is ps8640 output port */
+   port = of_graph_get_port_by_id(np, 1);
+   if (port) {
+   out_ep = of_get_child_by_name(port, "endpoint");
+   of_node_put(port);
+   if (out_ep) {
+   panel_node = of_graph_get_remote_port_parent(out_ep);
+   of_node_put(out_ep);
+   }
+   }
+   if (panel_node) {
+   ps_bridge->panel = of_drm_find_panel(panel_node);
+   of_node_put(panel_node);
+   if (!ps_bridge->panel)
+   return -EPROBE_DEFER;
+   }


The driver retrieves the panel from the output port via DT, but doesn't
retrieve the DSI host from the input port?

Wouldn't this driver need to call a "mipi_dsi_attach" at some point to
link with the DSI host (and pass parameters like number of lanes, color
format etc)?

I've been working on a patchset[1] which lets i2c drivers create mipi
dsi devices. I think this would be needed for the ps8640 driver too.

[1] https://lkml.org/lkml/2015/12/10/283

Archit


+
+   ps_bridge->page[0] = client;
+   for (i = 1; i < 6; i++)
+   ps_bridge->page[i] = i2c_new_dummy(client->adapter,
+  client->addr + i);
+
+   ps_bridge->pwr_3v3_supply = devm_regulator_get(dev, "vdd33");
+   if (IS_ERR(ps_bridge->pwr_3v3_supply)) {
+   ret = PTR_ERR(ps_bridge->pwr_3v3_supply);
+   dev_err(dev, "cannot get vdd33 supply: %d\n", ret);
+   return ret;
+   }
+
+   ps_bridge->pwr_1v2_supply = devm_regulator_get(dev, "vdd12");
+   if (IS_ERR(ps_bridge->pwr_1v2_supply)) {
+   ret = PTR_ERR(ps_bridge->pwr_1v2_supply);
+   dev_err(dev, "cannot get vdd12 supply: %d\n", ret);
+   return ret;
+   }
+
+   ps_bridge->gpio_mode_sel_n = devm_gpiod_get(>dev, "mode-sel",
+   

Re: [PATCH 0/8 v5] enable to use thermal-zone on r8a7790/1

[Simon Horman]

On Tue, Dec 15, 2015 at 01:16:20AM +, Kuninori Morimoto wrote:
> 
> Hi
> 
> These are v5 of thermal-zone support for r8a7790/r8a7791.
> 
> Kuninori Morimoto (8):
>   1) thermal: rcar: move rcar_thermal_dt_ids to upside
>   2) thermal: rcar: check every rcar_thermal_update_temp() return value
>   3) thermal: rcar: check irq possibility in rcar_thermal_irq_xxx()
>   4) thermal: rcar: rcar_thermal_get_temp() return error if strange temp
>   5) thermal: rcar: enable to use thermal-zone on DT
>   6) ARM: shmobile: r8a7790: enable to use thermal-zone
>   7) ARM: shmobile: r8a7791: enable to use thermal-zone
>   8) thermal: of-thermal: of_thermal_set_trip_temp() call 
> thermal_zone_device_update()

I have marked patches 6 and 7 as deferred pending acceptance of the driver
changes.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] ARM: dts: rockchip: add eFuse node for rk3066a SoCs

[Heiko Stübner]

Hi srini,

Am Montag, 14. Dezember 2015, 09:57:02 schrieb Srinivas Kandagatla:
> Heiko,
> 
> Can you take the DT patches in this series via your tree.
> 
> I picked up nvmem patches from this series.

yep that was my plan ... just needed to wait for the nvmem parts to be picked.


Thanks for the notifying me :-)
Heiko


> 
> thanks,
> srini
> 
> On 11/11/15 07:34, Caesar Wang wrote:
> > This patch add the eFuse dt node for rk3066a SoCs.
> > 
> > Signed-off-by: Caesar Wang 
> > ---
> > 
> >   arch/arm/boot/dts/rk3066a.dtsi | 13 +
> >   1 file changed, 13 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/rk3066a.dtsi
> > b/arch/arm/boot/dts/rk3066a.dtsi index 946f187..f61bb8a 100644
> > --- a/arch/arm/boot/dts/rk3066a.dtsi
> > +++ b/arch/arm/boot/dts/rk3066a.dtsi
> > @@ -153,6 +153,19 @@
> > 
> > clock-names = "timer", "pclk";
> > 
> > };
> > 
> > +   efuse: efuse@2001 {
> > +   compatible = "rockchip,rockchip-efuse";
> > +   reg = <0x2001 0x4000>;
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   clocks = < PCLK_EFUSE>;
> > +   clock-names = "pclk_efuse";
> > +
> > +   cpu_leakage: cpu_leakage {
> > +   reg = <0x17 0x1>;
> > +   };
> > +   };
> > +
> > 
> > timer@20038000 {
> > 
> > compatible = "snps,dw-apb-timer-osc";
> > reg = <0x20038000 0x100>;

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 13/14] ARM: dts: dove: add DT GPU support

[Gregory CLEMENT]

Hi Lucas,
 
 On lun., déc. 14 2015, Lucas Stach  wrote:

> Dove maintainers,
>
> can you please tell me if you prefer the DT changes to go along with the
> rest of the etnaviv series through the DRM tree, or plan on picking this
> separate?

I prefer to take the DT change in the mvebu tree. I was waiting for
acknowledgment on this series from the DRM maintainers to be sure that
the binding was OK. However, the fact that Rob Herring already acked the
binding is a good point for me.

Gregory


>
> Regards,
> Lucas
>
> Am Mittwoch, den 09.12.2015, 12:48 +0100 schrieb Lucas Stach:
>> From: Russell King 
>> 
>> Add DT support for the Vivante GC600 GPU on Marvell Dove platforms.
>> These nodes default to being disabled unless a platform decides they
>> should be enabled.
>> 
>> Signed-off-by: Russell King 
>> Signed-off-by: Lucas Stach 
>> ---
>>  arch/arm/boot/dts/dove.dtsi | 16 
>>  1 file changed, 16 insertions(+)
>> 
>> diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
>> index cd58c2e62757..ea1d999ca7a7 100644
>> --- a/arch/arm/boot/dts/dove.dtsi
>> +++ b/arch/arm/boot/dts/dove.dtsi
>> @@ -33,6 +33,12 @@
>>  marvell,tauros2-cache-features = <0>;
>>  };
>>  
>> +gpu-subsystem {
>> +compatible = "marvell,dove-gpu-subsystem";
>> +cores = <>;
>> +status = "disabled";
>> +};
>> +
>>  i2c-mux {
>>  compatible = "i2c-mux-pinctrl";
>>  #address-cells = <1>;
>> @@ -776,6 +782,16 @@
>>  #address-cells = <1>;
>>  #size-cells = <1>;
>>  };
>> +
>> +gpu: gpu@84 {
>> +clocks = <_clk 1>;
>> +clock-names = "core";
>> +compatible = "vivante,gc";
>> +interrupts = <48>;
>> +power-domains = <_domain>;
>> +reg = <0x84 0x4000>;
>> +status = "disabled";
>> +};
>>  };
>>  };
>>  };
>
> -- 
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions   | http://www.pengutronix.de/  |
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 3/8] ARM: dt: Binding documentation for imx25 touchscreen controller

[Markus Pargmann]

This is the touchscreen conversion queue binding documentation. It uses
the shared imx25 ADC.

Signed-off-by: Markus Pargmann 
---

Notes:
Changes in v9:
 - Updated binding descriptions

Changes in v5:
 - Fix signed/unsigned comparison
 - Fix unused variable settling_time by putting it in the correct argument 
list
 - Use continous conversion queue with the repeat feature and a proper
   repeat-wait. Previously the touchscreen caused massive number of 
interrupts.

 .../bindings/input/touchscreen/fsl-mx25-tcq.txt| 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt

diff --git 
a/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt 
b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
new file mode 100644
index ..cdf05f9b2329
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
@@ -0,0 +1,35 @@
+Freescale mx25 TS conversion queue module
+
+mx25 touchscreen conversion queue module which controls the ADC unit of the
+mx25 for attached touchscreens.
+
+Required properties:
+ - compatible: Should be "fsl,imx25-tcq".
+ - reg: Memory range of the device.
+ - interrupts: Should be the interrupt number associated with this module 
within
+   the tscadc unit (<0>).
+ - interrupt-parent: Should be a phandle to the tscadc unit.
+ - fsl,wires: Should be '<4>' or '<5>'
+
+Optional properties:
+ - fsl,pen-debounce-ns: Pen debounce time in nanoseconds.
+ - fsl,pen-threshold: Pen-down threshold for the touchscreen. This is a value
+   between 1 and 4096. It is the ratio between the internal reference voltage
+   and the measured voltage after the plate was precharged. Resistence between
+   plates and therefore the voltage decreases with pressure so that a smaller
+   value is equivalent to a higher pressure.
+ - fsl,settling-time-ns: Settling time in nanoseconds. The settling time is 
before
+   the actual touch detection to wait for an even charge distribution in the
+   plate.
+
+This device includes two conversion queues which can be added as subnodes.
+The first queue is for the touchscreen, the second for general purpose ADC.
+
+Example:
+   tsc: tcq@50030400 {
+   compatible = "fsl,imx25-tcq";
+   reg = <0x50030400 0x60>;
+   interrupt-parent = <>;
+   interrupts = <0>;
+   fsl,wires = <4>;
+   };
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 4/8] mfd: fsl imx25 Touchscreen ADC driver

[Markus Pargmann]

This is the core driver for imx25 touchscreen/adc driver. The module
has one shared ADC and two different conversion queues which use the
ADC. The two queues are identical. Both can be used for general purpose
ADC but one is meant to be used for touchscreens.

This driver is the core which manages the central components and
registers of the TSC/ADC unit. It manages the IRQs and forwards them to
the correct components.

Signed-off-by: Markus Pargmann 
Signed-off-by: Denis Carikli 

[ensure correct ADC clock depending on the IPG clock]
Signed-off-by: Juergen Borleis 
Acked-by: Jonathan Cameron 
---

Notes:
Changes in v7:
 - Cleanup bit defines in header files to be more readable
 - Fix irq check to return with an error for irq <= 0
 - Add COMPILE_TEST in Kconfig file

Changes in v5:
 - Remove ifdef CONFIG_OF as this driver is only for DT usage
 - Remove module owner
 - Add Kconfig dependencies ARCH_MX25 and OF

 drivers/mfd/Kconfig |   9 ++
 drivers/mfd/Makefile|   2 +
 drivers/mfd/fsl-imx25-tsadc.c   | 203 
 include/linux/mfd/imx25-tsadc.h | 140 +++
 4 files changed, 354 insertions(+)
 create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
 create mode 100644 include/linux/mfd/imx25-tsadc.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4d92df6ef9fe..4222e202ad2b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -271,6 +271,15 @@ config MFD_MC13XXX_I2C
help
  Select this if your MC13xxx is connected via an I2C bus.
 
+config MFD_MX25_TSADC
+   tristate "Freescale i.MX25 integrated Touchscreen and ADC unit"
+   select REGMAP_MMIO
+   depends on (SOC_IMX25 && OF) || COMPILE_TEST
+   help
+ Enable support for the integrated Touchscreen and ADC unit of the
+ i.MX25 processors. They consist of a conversion queue for general
+ purpose ADC and a queue for Touchscreens.
+
 config MFD_HI6421_PMIC
tristate "HiSilicon Hi6421 PMU/Codec IC"
depends on OF
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a8b76b81b467..5741be88c173 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -81,6 +81,8 @@ obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
 obj-$(CONFIG_MFD_TWL4030_AUDIO)+= twl4030-audio.o
 obj-$(CONFIG_TWL6040_CORE) += twl6040.o
 
+obj-$(CONFIG_MFD_MX25_TSADC)   += fsl-imx25-tsadc.o
+
 obj-$(CONFIG_MFD_MC13XXX)  += mc13xxx-core.o
 obj-$(CONFIG_MFD_MC13XXX_SPI)  += mc13xxx-spi.o
 obj-$(CONFIG_MFD_MC13XXX_I2C)  += mc13xxx-i2c.o
diff --git a/drivers/mfd/fsl-imx25-tsadc.c b/drivers/mfd/fsl-imx25-tsadc.c
new file mode 100644
index ..77b2675cf8f5
--- /dev/null
+++ b/drivers/mfd/fsl-imx25-tsadc.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (C) 2014-2015 Pengutronix, Markus Pargmann 
+ *
+ * This program is free software; you can redistribute it and/or modify it 
under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct regmap_config mx25_tsadc_regmap_config = {
+   .fast_io = true,
+   .max_register = 8,
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4,
+};
+
+static void mx25_tsadc_irq_handler(struct irq_desc *desc)
+{
+   struct mx25_tsadc *tsadc = irq_desc_get_handler_data(desc);
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   u32 status;
+
+   chained_irq_enter(chip, desc);
+
+   regmap_read(tsadc->regs, MX25_TSC_TGSR, );
+
+   if (status & MX25_TGSR_GCQ_INT)
+   generic_handle_irq(irq_find_mapping(tsadc->domain, 1));
+
+   if (status & MX25_TGSR_TCQ_INT)
+   generic_handle_irq(irq_find_mapping(tsadc->domain, 0));
+
+   chained_irq_exit(chip, desc);
+}
+
+static int mx25_tsadc_domain_map(struct irq_domain *d, unsigned int irq,
+irq_hw_number_t hwirq)
+{
+   struct mx25_tsadc *tsadc = d->host_data;
+
+   irq_set_chip_data(irq, tsadc);
+   irq_set_chip_and_handler(irq, _irq_chip,
+handle_level_irq);
+   irq_modify_status(irq, IRQ_NOREQUEST, IRQ_NOPROBE);
+
+   return 0;
+}
+
+static struct irq_domain_ops mx25_tsadc_domain_ops = {
+   .map = mx25_tsadc_domain_map,
+   .xlate = irq_domain_xlate_onecell,
+};
+
+static int mx25_tsadc_setup_irq(struct platform_device *pdev,
+   struct mx25_tsadc *tsadc)
+{
+   struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
+   int irq;
+
+   irq = platform_get_irq(pdev, 0);
+   if (irq <= 0) {
+   dev_err(dev, "Failed to get irq\n");
+   return irq;

[PATCH v10 2/8] ARM: dt: Binding documentation for imx25 GCQ

[Markus Pargmann]

The documentation describes the bindings for the imx25 GCQ unit which is
essentially a generic conversion queue using the imx25 ADC.

Signed-off-by: Markus Pargmann 
Acked-by: Rob Herring 
Acked-by: Jonathan Cameron 
---

Notes:
Changes in v9:
 - Added the dt-bindings header to this patch instead of the driver

Changes in v6:
 - Changed bindings to use adc-refp and adc-refn. Also a bit of cleanup in 
the
   setup routine.

Changes in v5:
 - Fixed locking
 - Removed module owner

 .../devicetree/bindings/iio/adc/fsl,imx25-gcq.txt  | 58 ++
 include/dt-bindings/iio/adc/fsl-imx25-gcq.h| 18 +++
 2 files changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
 create mode 100644 include/dt-bindings/iio/adc/fsl-imx25-gcq.h

diff --git a/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt 
b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
new file mode 100644
index ..b0866d36a307
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
@@ -0,0 +1,58 @@
+Freescale i.MX25 ADC GCQ device
+
+This is a generic conversion queue device that can convert any of the
+analog inputs using the ADC unit of the i.MX25.
+
+Required properties:
+ - compatible: Should be "fsl,imx25-gcq".
+ - reg: Should be the register range of the module.
+ - interrupts: Should be the interrupt number of the module.
+   Typically this is <1>.
+ - interrupt-parent: phandle to the tsadc module of the i.MX25.
+ - #address-cells: Should be <1> (setting for the subnodes)
+ - #size-cells: Should be <0> (setting for the subnodes)
+
+Optional properties:
+ - vref-ext-supply: The regulator supplying the ADC reference voltage.
+   Required when at least one subnode uses the this reference.
+ - vref-xp-supply: The regulator supplying the ADC reference voltage on pin XP.
+   Required when at least one subnode uses this reference.
+ - vref-yp-supply: The regulator supplying the ADC reference voltage on pin YP.
+   Required when at least one subnode uses this reference.
+
+Sub-nodes:
+Optionally you can define subnodes which define the reference voltage
+for the analog inputs.
+
+Required properties for subnodes:
+ - reg: Should be the number of the analog input.
+ 0: xp
+ 1: yp
+ 2: xn
+ 3: yn
+ 4: wiper
+ 5: inaux0
+ 6: inaux1
+ 7: inaux2
+Optional properties for subnodes:
+ - fsl,adc-refp: specifies the positive reference input as defined in
+ 
+ - fsl,adc-refn: specifies the negative reference input as defined in
+ 
+
+Example:
+
+   adc: adc@50030800 {
+   compatible = "fsl,imx25-gcq";
+   reg = <0x50030800 0x60>;
+   interrupt-parent = <>;
+   interrupts = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   inaux@5 {
+   reg = <5>;
+   fsl,adc-refp = ;
+   fsl,adc-refn = ;
+   };
+   };
diff --git a/include/dt-bindings/iio/adc/fsl-imx25-gcq.h 
b/include/dt-bindings/iio/adc/fsl-imx25-gcq.h
new file mode 100644
index ..87abdd4a7674
--- /dev/null
+++ b/include/dt-bindings/iio/adc/fsl-imx25-gcq.h
@@ -0,0 +1,18 @@
+/*
+ * This header provides constants for configuring the I.MX25 ADC
+ */
+
+#ifndef _DT_BINDINGS_IIO_ADC_FS_IMX25_GCQ_H
+#define _DT_BINDINGS_IIO_ADC_FS_IMX25_GCQ_H
+
+#define MX25_ADC_REFP_YP   0 /* YP voltage reference */
+#define MX25_ADC_REFP_XP   1 /* XP voltage reference */
+#define MX25_ADC_REFP_EXT  2 /* External voltage reference */
+#define MX25_ADC_REFP_INT  3 /* Internal voltage reference */
+
+#define MX25_ADC_REFN_XN   0 /* XN ground reference */
+#define MX25_ADC_REFN_YN   1 /* YN ground reference */
+#define MX25_ADC_REFN_NGND 2 /* Internal ground reference */
+#define MX25_ADC_REFN_NGND23 /* External ground reference */
+
+#endif
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 0/8] imx25 adc and touchscreen driver

[Markus Pargmann]

Hi,

v10 includes minor fixes in the gcq driver code and the renamed two DT
properties for the touchscreen which now include the units in the name.

Best Regards,

Markus


Denis Carikli (2):
  ARM: dts: imx25: Add TSC and ADC support
  ARM: imx_v4_v5_defconfig: Add I.MX25 Touchscreen controller and ADC
support.

Markus Pargmann (6):
  ARM: dt: Binding documentation for imx25 ADC/TSC
  ARM: dt: Binding documentation for imx25 GCQ
  ARM: dt: Binding documentation for imx25 touchscreen controller
  mfd: fsl imx25 Touchscreen ADC driver
  iio: adc: fsl,imx25-gcq driver
  input: touchscreen: imx25 tcq driver

 .../devicetree/bindings/iio/adc/fsl,imx25-gcq.txt  |  58 ++
 .../bindings/input/touchscreen/fsl-mx25-tcq.txt|  35 ++
 .../devicetree/bindings/mfd/fsl-imx25-tsadc.txt|  47 ++
 arch/arm/boot/dts/imx25.dtsi   |  29 +-
 arch/arm/configs/imx_v4_v5_defconfig   |   4 +
 drivers/iio/adc/Kconfig|   7 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/fsl-imx25-gcq.c| 417 ++
 drivers/input/touchscreen/Kconfig  |   9 +
 drivers/input/touchscreen/Makefile |   1 +
 drivers/input/touchscreen/fsl-imx25-tcq.c  | 596 +
 drivers/mfd/Kconfig|   9 +
 drivers/mfd/Makefile   |   2 +
 drivers/mfd/fsl-imx25-tsadc.c  | 203 +++
 include/dt-bindings/iio/adc/fsl-imx25-gcq.h|  18 +
 include/linux/mfd/imx25-tsadc.h| 140 +
 16 files changed, 1573 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
 create mode 100644 drivers/iio/adc/fsl-imx25-gcq.c
 create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c
 create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
 create mode 100644 include/dt-bindings/iio/adc/fsl-imx25-gcq.h
 create mode 100644 include/linux/mfd/imx25-tsadc.h

-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 8/8] ARM: imx_v4_v5_defconfig: Add I.MX25 Touchscreen controller and ADC support.

[Markus Pargmann]

From: Denis Carikli 

Signed-off-by: Denis Carikli 
Signed-off-by: Markus Pargmann 
---
 arch/arm/configs/imx_v4_v5_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/imx_v4_v5_defconfig 
b/arch/arm/configs/imx_v4_v5_defconfig
index d3a8018639de..d6754ac47788 100644
--- a/arch/arm/configs/imx_v4_v5_defconfig
+++ b/arch/arm/configs/imx_v4_v5_defconfig
@@ -88,6 +88,7 @@ CONFIG_KEYBOARD_IMX=y
 # CONFIG_INPUT_MOUSE is not set
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_TOUCHSCREEN_ADS7846=m
+CONFIG_TOUCHSCREEN_MX25=y
 CONFIG_TOUCHSCREEN_MC13783=y
 # CONFIG_LEGACY_PTYS is not set
 CONFIG_SERIAL_8250=m
@@ -107,6 +108,7 @@ CONFIG_HWMON=m
 CONFIG_SENSORS_MC13783_ADC=m
 CONFIG_WATCHDOG=y
 CONFIG_IMX2_WDT=y
+CONFIG_MFD_MX25_TSADC=y
 CONFIG_MFD_MC13XXX_SPI=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
@@ -172,6 +174,8 @@ CONFIG_DMADEVICES=y
 CONFIG_IMX_SDMA=y
 CONFIG_IMX_DMA=y
 # CONFIG_IOMMU_SUPPORT is not set
+CONFIG_IIO=y
+CONFIG_FSL_MX25_ADC=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 CONFIG_EXT4_FS=y
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-4.4 2/2] doc: dt: mtd: partitions: add compatible property to "partitions" node

[Geert Uytterhoeven]

Hi Brian,

On Wed, Dec 9, 2015 at 2:12 AM, Brian Norris
 wrote:
> On Mon, Dec 07, 2015 at 09:58:35AM -0800, Brian Norris wrote:
>> On Sat, Dec 05, 2015 at 12:45:36PM +0100, Jonas Gorski wrote:
>> > On Fri, Dec 4, 2015 at 3:02 AM, Brian Norris
>> >  wrote:
>> > > // proposed
>> > > partitions {
>> > > compatible = "partitions";
>> >
>> > "partitions" sounds mode like a device_type thing than a compatible
>> > name, maybe "fixed-partitions"? IMHO that would describe better what
>> > these are, and doesn't invite to think using compatible =
>> > "arm,arm-flash-structure", "partitions"; is a good idea.
>>
>> "fixed-partitions" sounds OK to me. If no objections, I'll apply these
>> patches, with (approximately) a:
>>
>> s/"partitions"/"fixed-partitions"/
>
> Pushed to linux-mtd.git with the above change.

Aarghl, hadn't seen this patch before.

This breaks the users that have already added the partitions subnodes
(armada-xp-lenovo-ix4-300d.dts and a few shmobile).

Will send patches to fix it...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 13/14] ARM: dts: dove: add DT GPU support

[Lucas Stach]

Dove maintainers,

can you please tell me if you prefer the DT changes to go along with the
rest of the etnaviv series through the DRM tree, or plan on picking this
separate?

Regards,
Lucas

Am Mittwoch, den 09.12.2015, 12:48 +0100 schrieb Lucas Stach:
> From: Russell King 
> 
> Add DT support for the Vivante GC600 GPU on Marvell Dove platforms.
> These nodes default to being disabled unless a platform decides they
> should be enabled.
> 
> Signed-off-by: Russell King 
> Signed-off-by: Lucas Stach 
> ---
>  arch/arm/boot/dts/dove.dtsi | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
> index cd58c2e62757..ea1d999ca7a7 100644
> --- a/arch/arm/boot/dts/dove.dtsi
> +++ b/arch/arm/boot/dts/dove.dtsi
> @@ -33,6 +33,12 @@
>   marvell,tauros2-cache-features = <0>;
>   };
>  
> + gpu-subsystem {
> + compatible = "marvell,dove-gpu-subsystem";
> + cores = <>;
> + status = "disabled";
> + };
> +
>   i2c-mux {
>   compatible = "i2c-mux-pinctrl";
>   #address-cells = <1>;
> @@ -776,6 +782,16 @@
>   #address-cells = <1>;
>   #size-cells = <1>;
>   };
> +
> + gpu: gpu@84 {
> + clocks = <_clk 1>;
> + clock-names = "core";
> + compatible = "vivante,gc";
> + interrupts = <48>;
> + power-domains = <_domain>;
> + reg = <0x84 0x4000>;
> + status = "disabled";
> + };
>   };
>   };
>  };

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 02/10] clockevents/drivers: add MPS2 Timer driver

[Daniel Lezcano]

On 12/02/2015 10:33 AM, Vladimir Murzin wrote:

MPS2 platform has simple 32 bits general purpose countdown timers.

The driver uses the first detected timer as a clocksource and the rest
of the timers as a clockevent

Signed-off-by: Vladimir Murzin 
---


[ ... ]


+static void clockevent_mps2_writel(u32 val, struct clock_event_device *c, u32 
offset)
+{
+   writel(val, to_mps2_clkevt(c)->reg + offset);
+}


Is it possible to use writel_relaxed here ?

[ ... ]


+static int mps2_timer_set_periodic(struct clock_event_device *ce)
+{
+   u32 clock_count_per_tick = to_mps2_clkevt(ce)->clock_count_per_tick;
+
+   clockevent_mps2_writel(clock_count_per_tick, ce, TIMER_RELOAD);
+   clockevent_mps2_writel(clock_count_per_tick, ce, TIMER_VALUE);
+   clockevent_mps2_writel(TIMER_CTRL_IE | TIMER_CTRL_ENABLE, ce, 
TIMER_CTRL);
+
+   return 0;
+}
+
+static irqreturn_t mps2_timer_interrupt(int irq, void *dev_id)
+{
+   struct clockevent_mps2 *ce = dev_id;
+   u32 status = readl(ce->reg + TIMER_INT);
+
+   if (!status) {
+   pr_warn("spuirous interrupt\n");


typo: 'spurious'

[ ... ]


+   ce = kzalloc(sizeof(struct clockevent_mps2), GFP_KERNEL);
+   if (!ce) {
+   ret = -ENOMEM;
+   pr_err("failed to allocate clockevent: %d\n", ret);


There is already a stack trace in the kernel when an allocation fails.

With the above fixed:

Acked-by: Daniel Lezcano 


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html