Re: [PATCH v2 0/8] i2c mux cleanup and locking update

[Peter Rosin]

Hi Antti,

On 2016-01-06 18:17, Antti Palosaari wrote:
> On 01/05/2016 05:57 PM, Peter Rosin wrote:
>> From: Peter Rosin 
>>
>> Hi!
>>
>> I have a pair of boards with this i2c topology:
>>
>> GPIO ---|  -- BAT1
>>  |  v /
>> I2C  -+--B---+ MUX
>>   |   \
>> EEPROM -- BAT2
>>
>> (B denotes the boundary between the boards)
> 
> Handling of I2C muxes that close channel automatically, after the first I2C 
> stop (P) is seen?
> 
> For example channel is selected to BAT1 => there is EEPROM write => mux 
> closes channel BAT1 => access to BAT1 will fail.

The proposed locking changes affect gpio- and pinctrl-controlled muxes
only, and I can't see one of those actually know anything about the
i2c-signals that they mux. Such muxes certainly has to obey the pins
that control them, no?

That fact that other muxes might piggy-back and also use the new
i2c-controlled flag is a different question, and it may indeed not be
safe to declare a mux "i2c-controlled" just to avoid the locking, if
the locking is in fact required. Maybe the name "i2c-controlled" is
poor?

> Is it possible to lock whole adapter, but allow only traffic to i2c mux 
> client?

This is basically what is there today, and which does not work for the
above i2c topology. So maybe you need to expand on what you meant?



There is no neat way for the i2c mux code to dip its fingers into all
relevant i2c-accesses to categorize them as "mux updates" or "mux slave
side accesses", when they come from generic subsystems such as gpio
och pinctrl.

The only thing I have been able to think of in that area is to add i2c
devices that are used to change the mux to a virtual slave adapter of
the mux, so that the mux can identify those accesses and bypass the
locking. But that isn't generic enough to cover the case where one
device is used to control more than one mux (since it needs to sit on
more than one adapter in that case), so I scrapped that idea pretty
early. But I also find that I have to scrap it again and again, since
everything else I cook up usually ends up being some variant of the
virtual slave adapter when I think some more about it. Maybe it *is*
possible to have the same device in different places in the adapter
tree (if all those places have a common ancestor)? But I don't think
so...

That does not address your concerns about extra accesses creeping
in between the mux select and the mux slave side access for auto-
closing muxes (or arbitrators), but I never pretended that there would
be protection from that. If there are such requirements you basically
have to lock the root adapter to prevent i2c "noise".

I can't see recursive locks helping either, because that would need
lock ownership to be propagated into gpio/pinctrl, and that is again
too ugly.

Cheers,
Peter

> regards
> Antti
> 
>>
>> The problem with this is that the GPIO controller sits on the same i2c bus
>> that it MUXes. For pca954x devices this is worked around by using unlocked
>> transfers when updating the MUX. I have no such luck as the GPIO is a general
>> purpose IO expander and the MUX is just a random bidirectional MUX, unaware
>> of the fact that it is muxing an i2c bus, and extending unlocked transfers
>> into the GPIO subsystem is too ugly to even think about. But the general hw
>> approach is sane in my opinion, with the number of connections between the
>> two boards minimized. To put is plainly, I need support for it.
>>
>> So, I observe that while it is needed to have the i2c bus locked during the
>> actual MUX update in order to avoid random garbage on the slave side, it
>> is not strictly a must to have it locked over the whole sequence of a full
>> select-transfer-deselect operation. The MUX itself needs to be locked, so
>> transfers to clients behind the mux are serialized, and the MUX needs to be
>> stable during all i2c traffic (otherwise individual mux slave segments
>> might see garbage).
>>
>> This series accomplishes this by adding a dt property to i2c-mux-gpio and
>> i2c-mux-pinctrl that can be used to state that the mux is updated by means
>> of the muxed master bus, and that the select-transfer-deselect operations
>> should be locked individually. When this holds, the i2c bus *is* locked
>> during muxing, since the muxing happens as part of i2c transfers. This
>> is true even if the MUX is updated with several transfers to the GPIO (at
>> least as long as *all* MUX changes are using the i2s master bus). A lock
>> is added to the mux so that transfers through the mux are serialized.
>>
>> Concerns:
>> - The locking is perhaps too complex?
>> - I worry about the priority inheritance aspect of the adapter lock. When
>>the transfers behind the mux are divided into select-transfer-deselect all
>>locked individually, low priority transfers get more chances to interfere
>>with high priority transfers.

[RFC PATCH v2 1/4] drm: dw-hdmi: make it easy to recovery the platform data for platform driver

[Yakir Yang]

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 drivers/gpu/drm/imx/dw_hdmi-imx.c   | 7 ---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 7 ---
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 063825f..0968610 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -26,6 +26,7 @@ struct imx_hdmi {
struct device *dev;
struct drm_encoder encoder;
struct regmap *regmap;
+   struct dw_hdmi_plat_data plat_data;
 };
 
 static const struct dw_hdmi_mpll_config imx_mpll_cfg[] = {
@@ -204,7 +205,6 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
-   const struct dw_hdmi_plat_data *plat_data;
const struct of_device_id *match;
struct drm_device *drm = data;
struct drm_encoder *encoder;
@@ -221,7 +221,7 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
return -ENOMEM;
 
match = of_match_node(dw_hdmi_imx_dt_ids, pdev->dev.of_node);
-   plat_data = match->data;
+   hdmi->plat_data = *(const struct dw_hdmi_plat_data *)match->data;
hdmi->dev = >dev;
encoder = >encoder;
 
@@ -253,7 +253,8 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
drm_encoder_init(drm, encoder, _hdmi_imx_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);
 
-   return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+   return dw_hdmi_bind(dev, master, data, encoder, iores, irq,
+   >plat_data);
 }
 
 static void dw_hdmi_imx_unbind(struct device *dev, struct device *master,
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index c65ce8c..d5816b3 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -28,6 +28,7 @@ struct rockchip_hdmi {
struct device *dev;
struct regmap *regmap;
struct drm_encoder encoder;
+   struct dw_hdmi_plat_data plat_data;
 };
 
 #define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
@@ -242,7 +243,6 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
 void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
-   const struct dw_hdmi_plat_data *plat_data;
const struct of_device_id *match;
struct drm_device *drm = data;
struct drm_encoder *encoder;
@@ -259,7 +259,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
return -ENOMEM;
 
match = of_match_node(dw_hdmi_rockchip_dt_ids, pdev->dev.of_node);
-   plat_data = match->data;
+   hdmi->plat_data = *(const struct dw_hdmi_plat_data *)match->data;
hdmi->dev = >dev;
encoder = >encoder;
 
@@ -293,7 +293,8 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
drm_encoder_init(drm, encoder, _hdmi_rockchip_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);
 
-   return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+   return dw_hdmi_bind(dev, master, data, encoder, iores, irq,
+   >plat_data);
 }
 
 static void dw_hdmi_rockchip_unbind(struct device *dev, struct device *master,
-- 
2.1.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: [RFC PATCH v2 3/4] drm: rockchip: hdmi: add RK3229 HDMI support

[Philipp Zabel]

Am Donnerstag, den 07.01.2016, 17:02 +0800 schrieb Yakir Yang:
> RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy,
> the max output resolution is 4K.
> 
> Signed-off-by: Yakir Yang 

It sounds like the INNO HDMI2.0 phy is not necessarily specific to
RK3229 but might also appear in other SoCs? If so, I think this should
be implemented in a separate phy driver and be used by dw_hdmi-rockchip.

regards
Philipp

> ---
> Changes in v2:
> - Split some dw-hdmi driver changes into separate patches [01/04] & [02/04]
> 
>  drivers/gpu/drm/bridge/dw-hdmi.c|  27 +-
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 367 
> ++--
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h | 137 +++
>  include/drm/bridge/dw_hdmi.h|   3 +
>  4 files changed, 507 insertions(+), 27 deletions(-)
>  create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 5ad72ec..5e03d83 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -735,10 +735,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
> unsigned char prep,
>  {
>   unsigned res_idx;
>   u8 val, msec;
> + int ret;
>   const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
>   const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
>   const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
>   const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
> + int mpixelclock = hdmi->hdmi_data.video_mode.mpixelclock;
>  
>   if (prep)
>   return -EINVAL;
> @@ -758,27 +760,38 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
> unsigned char prep,
>   return -EINVAL;
>   }
>  
> + if (hdmi->plat_data->extphy_config) {
> + /* gen2 tx power off */
> + dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> + dw_hdmi_phy_gen2_pddq(hdmi, 1);
> +
> + ret = hdmi->plat_data->extphy_config(hdmi->plat_data, res_idx,
> +  mpixelclock);
> + /* gen2 tx power on */
> + dw_hdmi_phy_gen2_txpwron(hdmi, 1);
> + dw_hdmi_phy_gen2_pddq(hdmi, 0);
> +
> + return ret;
> + }
> +
>   /* PLL/MPLL Cfg - always match on final entry */
>   for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - mpll_config->mpixelclock)
> + if (mpixelclock <= mpll_config->mpixelclock)
>   break;
>  
>   for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - curr_ctrl->mpixelclock)
> + if (mpixelclock <= curr_ctrl->mpixelclock)
>   break;
>  
>   for (; phy_config->mpixelclock != ~0UL; phy_config++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - phy_config->mpixelclock)
> + if (mpixelclock <= phy_config->mpixelclock)
>   break;
>  
>   if (mpll_config->mpixelclock == ~0UL ||
>   curr_ctrl->mpixelclock == ~0UL ||
>   phy_config->mpixelclock == ~0UL) {
>   dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
> - hdmi->hdmi_data.video_mode.mpixelclock);
> + mpixelclock);
>   return -EINVAL;
>   }
>  
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index 8164823..24fffaa 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -7,6 +7,7 @@
>   * (at your option) any later version.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -21,18 +22,134 @@
>  #include "rockchip_drm_drv.h"
>  #include "rockchip_drm_vop.h"
>  
> -#define GRF_SOC_CON60x025c
> -#define HDMI_SEL_VOP_LIT(1 << 4)
> +#include "dw_hdmi-rockchip.h"
>  
>  struct rockchip_hdmi {
>   struct device *dev;
>   struct regmap *regmap;
>   struct drm_encoder encoder;
>   struct dw_hdmi_plat_data plat_data;
> +
> + void __iomem *extphy_regbase;
> + struct clk *extphy_pclk;
>  };
>  
>  #define to_rockchip_hdmi(x)  container_of(x, struct rockchip_hdmi, x)
>  
> +static const struct extphy_config_tab rockchip_extphy_cfg[] = {
> + { .mpixelclock = 16500,
> +   .pre_emphasis = 0, .slopeboost = 0, .clk_level = 4,
> +   .data0_level = 4, 4, 4,
> + },
> +
> + { .mpixelclock = 22500,
> +   .pre_emphasis = 0, .slopeboost = 0, .clk_level = 6,
> +   .data0_level = 6, 6, 6,
> + },
> +
> + { .mpixelclock = 34000,
> +   .pre_emphasis = 1, .slopeboost = 0, .clk_level = 6,
> +   

[PATCH 2/2] ARM: dts: mt2701: enable basic SMP bringup for mt2701

[Louis Yu]

Add enable method to support SMP.

Signed-off-by: Louis Yu 
---
 arch/arm/boot/dts/mt2701.dtsi |   12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 69f240f..1d72d82 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -23,6 +23,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+   enable-method = "mediatek,mt81xx-tz-smp";
 
cpu@0 {
device_type = "cpu";
@@ -46,6 +47,17 @@
};
};
 
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   trustzone-bootinfo@80002000 {
+   compatible = "mediatek,trustzone-bootinfo";
+   reg = <0 0x80002000 0 0x1000>;
+   };
+   };
+
system_clk: dummy13m {
compatible = "fixed-clock";
clock-frequency = <1300>;
-- 
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

[PATCH v2 02/12] ARM: dts: rockchip: add the sound codec for kylin board

[Caesar Wang]

Support the rt5616 codec for kylin board, but we need
enable the i2s firstly.
Also, this patch adds the CPU/CODEC information for simple card
to make the happy work.

Signed-off-by: Caesar Wang 

---

Changes in v2:
- fix the mclk-fs as the 256.

 arch/arm/boot/dts/rk3036-kylin.dts | 33 +
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/rk3036-kylin.dts 
b/arch/arm/boot/dts/rk3036-kylin.dts
index 992f9ca..27b6326 100644
--- a/arch/arm/boot/dts/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -46,6 +46,28 @@
model = "Rockchip RK3036 KylinBoard";
compatible = "rockchip,rk3036-kylin", "rockchip,rk3036";
 
+   sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,name = "rockchip,rt5616-codec";
+   simple-audio-card,mclk-fs = <256>;
+   simple-audio-card,widgets =
+   "Microphone", "Microphone Jack",
+   "Headphone", "Headphone Jack";
+   simple-audio-card,routing =
+   "MIC1", "Microphone Jack",
+   "MIC2", "Microphone Jack",
+   "Microphone Jack", "micbias1",
+   "Headphone Jack", "HPOL",
+   "Headphone Jack", "HPOR";
+   simple-audio-card,cpu {
+   sound-dai = <>;
+   };
+   simple-audio-card,codec {
+   sound-dai = <>;
+   };
+   };
+
vcc_sys: vsys-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
@@ -257,6 +279,17 @@
 
  {
status = "okay";
+
+   rt5616: rt5616@1b {
+   #sound-dai-cells = <0>;
+   compatible = "rt5616";
+   reg = <0x1b>;
+   };
+};
+
+ {
+   #sound-dai-cells = <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 03/12] ARM: dts: rockchip: override the clocks in i2s for kylin board

[Caesar Wang]

The sysclk seems be incorrect since we use the simple card for kylin
board.

The simple card call:

asoc_simple_card_probe ->
 asoc_simple_card_dai_link_of ->
  asoc_simple_card_sub_parse_of ->
...
clk = of_clk_get(args.np, 0);
if (!IS_ERR(clk))
dai->sysclk = clk_get_rate(clk);

The sysclk come from the first clock, then first clock is hclk_i2s
in i2s for rk3036 dtsi.
So, we can override the clocks to fit the simple card in here.

Signed-off-by: Caesar Wang 
---

Changes in v2: None

 arch/arm/boot/dts/rk3036-kylin.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/rk3036-kylin.dts 
b/arch/arm/boot/dts/rk3036-kylin.dts
index 27b6326..b642369 100644
--- a/arch/arm/boot/dts/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -288,6 +288,13 @@
 };
 
  {
+   /**
+* We should override the clocks since sysclk from the first clock
+* in simple card.
+*/
+   clock-names = "i2s_clk", "i2s_hclk";
+   clocks = < SCLK_I2S>, < HCLK_I2S>;
+
#sound-dai-cells = <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 12/12] ARM: dts: Add pl330-broken-no-flushp quirk for rk3036 SoCs

[Caesar Wang]

Pl330 integrated in rk3036platform doesn't support
DMAFLUSHP function. So we add arm,pl330-broken-no-flushp quirk
for it.

Signed-off-by: Caesar Wang 
---

Changes in v2: None

 arch/arm/boot/dts/rk3036.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 6ff03e3..0168817 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -102,6 +102,7 @@
pdma: pdma@20078000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x20078000 0x4000>;
+   arm,pl330-broken-no-flushp;
interrupts = ,
 ;
#dma-cells = <1>;
-- 
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 07/12] ARM: dts: rockchip: enable the high speed on sdio for kylin board

[Caesar Wang]

We want to the higher speed for wifi module working.

Bootup kernel log:
...
mmc_host mmc0: Bus speed (slot 0) = 37125000Hz (slot req 3750Hz,
actual 37125000HZ div = 0)

or run 'cat /sys/kernel/debug/clk/clk_summary |grep phase -C 1' to check
Otherwise, the mmc0 will run 400khz defalult value to work.

Signed-off-by: Caesar Wang 
---

Changes in v2: None

 arch/arm/boot/dts/rk3036-kylin.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/rk3036-kylin.dts 
b/arch/arm/boot/dts/rk3036-kylin.dts
index b642369..b2e5f5d 100644
--- a/arch/arm/boot/dts/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -304,6 +304,11 @@
 
broken-cd;
bus-width = <4>;
+   cap-sd-highspeed;
+   sd-uhs-sdr12;
+   sd-uhs-sdr25;
+   sd-uhs-sdr50;
+   sd-uhs-sdr104;
cap-sdio-irq;
default-sample-phase = <90>;
keep-power-in-suspend;
-- 
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

[RFC PATCH v2 3/4] drm: rockchip: hdmi: add RK3229 HDMI support

[Yakir Yang]

RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy,
the max output resolution is 4K.

Signed-off-by: Yakir Yang 
---
Changes in v2:
- Split some dw-hdmi driver changes into separate patches [01/04] & [02/04]

 drivers/gpu/drm/bridge/dw-hdmi.c|  27 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 367 ++--
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h | 137 +++
 include/drm/bridge/dw_hdmi.h|   3 +
 4 files changed, 507 insertions(+), 27 deletions(-)
 create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 5ad72ec..5e03d83 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -735,10 +735,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
 {
unsigned res_idx;
u8 val, msec;
+   int ret;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
+   int mpixelclock = hdmi->hdmi_data.video_mode.mpixelclock;
 
if (prep)
return -EINVAL;
@@ -758,27 +760,38 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
return -EINVAL;
}
 
+   if (hdmi->plat_data->extphy_config) {
+   /* gen2 tx power off */
+   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
+   dw_hdmi_phy_gen2_pddq(hdmi, 1);
+
+   ret = hdmi->plat_data->extphy_config(hdmi->plat_data, res_idx,
+mpixelclock);
+   /* gen2 tx power on */
+   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
+   dw_hdmi_phy_gen2_pddq(hdmi, 0);
+
+   return ret;
+   }
+
/* PLL/MPLL Cfg - always match on final entry */
for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   mpll_config->mpixelclock)
+   if (mpixelclock <= mpll_config->mpixelclock)
break;
 
for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   curr_ctrl->mpixelclock)
+   if (mpixelclock <= curr_ctrl->mpixelclock)
break;
 
for (; phy_config->mpixelclock != ~0UL; phy_config++)
-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   phy_config->mpixelclock)
+   if (mpixelclock <= phy_config->mpixelclock)
break;
 
if (mpll_config->mpixelclock == ~0UL ||
curr_ctrl->mpixelclock == ~0UL ||
phy_config->mpixelclock == ~0UL) {
dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
-   hdmi->hdmi_data.video_mode.mpixelclock);
+   mpixelclock);
return -EINVAL;
}
 
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 8164823..24fffaa 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -7,6 +7,7 @@
  * (at your option) any later version.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -21,18 +22,134 @@
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_vop.h"
 
-#define GRF_SOC_CON60x025c
-#define HDMI_SEL_VOP_LIT(1 << 4)
+#include "dw_hdmi-rockchip.h"
 
 struct rockchip_hdmi {
struct device *dev;
struct regmap *regmap;
struct drm_encoder encoder;
struct dw_hdmi_plat_data plat_data;
+
+   void __iomem *extphy_regbase;
+   struct clk *extphy_pclk;
 };
 
 #define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
 
+static const struct extphy_config_tab rockchip_extphy_cfg[] = {
+   { .mpixelclock = 16500,
+ .pre_emphasis = 0, .slopeboost = 0, .clk_level = 4,
+ .data0_level = 4, 4, 4,
+   },
+
+   { .mpixelclock = 22500,
+ .pre_emphasis = 0, .slopeboost = 0, .clk_level = 6,
+ .data0_level = 6, 6, 6,
+   },
+
+   { .mpixelclock = 34000,
+ .pre_emphasis = 1, .slopeboost = 0, .clk_level = 6,
+ .data0_level = 10, 10, 10,
+   },
+
+   { .mpixelclock = 59400,
+ .pre_emphasis = 1, .slopeboost = 0, .clk_level = 7,
+ .data0_level = 10, 10, 10,
+   },
+
+   { .mpixelclock = ~0UL},
+};
+
+static const struct extphy_pll_config_tab rockchip_extphy_pll_cfg[] = {
+   {
+   .mpixelclock = 2700, .param = {
+   { .pll_nd = 1, .pll_nf = 45,
+   

Re: [PATCH v4 3/3] wlcore/wl12xx: spi: add wifi support to cm-t335

[Kalle Valo]

Uri Mashiach  writes:

> Device tree modifications:
> - Pinmux for SPI0 and WiFi GPIOs.
> - SPI0 node with wlcore as a child node.
>
> Cc: Tony Lindgren 
> Signed-off-by: Uri Mashiach 
> ---
> v1 -> v2: Replace interrupts and interrupt-parent with interrupts-extended.
> v2 -> v3: Move the pinctrl-0 = <_pins> to the wlcore node.
> v3 -> v4: replace interrupts-extended with interrupts and interrupt-parent. 
> (revert v2 modification).
>   According to Rob Herring and 
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt,
> interrupts-extended should only be used when a device has multiple 
> interrupt parents.
>
>  arch/arm/boot/dts/am335x-cm-t335.dts | 55 
> 
>  1 file changed, 55 insertions(+)

To what tree should this patch go? My wireless-drivers-next tree doesn't
even have this file.

https://patchwork.kernel.org/patch/7933441/

-- 
Kalle Valo
--
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 00/12] Add the family patches to support for kylin board

[Caesar Wang]

Hi all,

Happy new year! :)
Let's go on working for happy.

This series patches are based on kernel version 4.4.0-rc8+
(Linux version 4.4.0-rc8+ (wxt@ubuntu)...#142 SMP Thu Jan 7 12:38:40 CST 2016)

This series pacthes are verified on the following github:
https://github.com/Caesar-github/rockchip/commits/kylin-develop4.4

This series has 12 patches: (12--->1)
bbd1a01 ARM: dts: Add pl330-broken-no-flushp quirk for rk3036 SoCs
fb8c1fd ARM: dts: rockchip: add the lcdc and hdmi node for rk3036
1aeb49d ARM: dts: rockchip: add the sdmmc for kylin board
3e19128 ARM: dts: rockchip: enable the uart0 for kylin board
e7de154 ARM: dts: rockchip: add the wifi/bt regulator for kylin board
8699698 ARM: dts: rockchip: enable the high speed on sdio for kylin board
21eded4 mmc: pwrseq: add support for power-on sequencing through DT
cdf3a7e mmc: pwrseq: Document optional exteral vcc for the simple power sequence
131c249 clk: rockchip: rk3036: enable the CLK_IGNORE_UNUSED flag for 
sclk_i2s_out
b7ff8e1 ARM: dts: rockchip: override the clocks in i2s for kylin board
5f56af4 ARM: dts: rockchip: add the sound codec for kylin board
914d9c0 ARM: dts: rockchip: set the pinctrl default setting for rk3036 i2s
..

This series patches have the following decriptions:

PATCH[1/12-4/12]:> Support rt5616 codec for kylin board
914d9c0 ARM: dts: rockchip: set the pinctrl default setting for rk3036 i2s
5f56af4 ARM: dts: rockchip: add the sound codec for kylin board
b7ff8e1 ARM: dts: rockchip: override the clocks in i2s for kylin board
131c249 clk: rockchip: rk3036: enable the CLK_IGNORE_UNUSED flag for 
sclk_i2s_out

This patches is working for codec rt5616 on kylin board. (RK3036 SoCs)

That's needed the following rt5616 driver from Mark Brown Branch.
(cherry picked from git.kernel.org broonie/sound.git for-next)

cf94b7a UPSTREAM: ASoC: rt5616: rename some alsa control names
86f561d UPSTREAM: ASoC: rt5616: add devicetree document for rt5616
0e0f5f8 UPSTREAM: ASoC: rt5616: add an of_match table
263a330 UPSTREAM: ASoC: rt5616: Return error if device ID mismatch
0094139 UPSTREAM: ASoC: rt5616: add rt5616 codec driver

Notes:
I'm run it with the ubuntu 15.04 to set the configure.
./amixer "HP Playback Switch" 1
./amixer "HP Playback Volume" 20
./amixer "HPO MIX DAC1 Switch" 1
./amixer "OUT MIXR DAC R1 Switch" 1
./amixer "OUT MIXL DAC L1 Switch" 1
./amixer "Stereo DAC MIXR DAC R1 Switch" 1
./amixer "Stereo DAC MIXL DAC L1 Switch" 1

root@linaro-alip:/media/aplay# ./aplay pcm.wav
Playing sample: 2 ch, 48000 hz, 16 bit
..
That can be normal playing the music.


PATCH[5/12-9/12]: > Support wifi/bt module for kylin board
cdf3a7e mmc: pwrseq: Document optional exteral vcc for the simple power sequence
21eded4 mmc: pwrseq: add support for power-on sequencing through DT
8699698 ARM: dts: rockchip: enable the high speed on sdio for kylin board
e7de154 ARM: dts: rockchip: add the wifi/bt regulator for kylin board
3e19128 ARM: dts: rockchip: enable the uart0 for kylin board

The wifi/bt driver hasn't land in mainline, the driver is in here:
https://github.com/Caesar-github/rockchip/commit/1912ef4c0e358677904b0a0bbb83f9745066f0ec

wpa_supplicant -Dnl80211 -c /etc/wifi/wpa_supplicant.conf -i wlan0 -B
wpa_cli add_network
wpa_cli set_network 1 ssid \"wxt\"
wpa_cli set_network 1 psk \"123456789\"
wpa_cli select_network 1
wpa_cli save_config

ifconfig wlan0 192.168.1.105
route add default gw 192.168.1.1

root@linaro-alip:/# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=6.83 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=184 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=9.21 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=6.84 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=11.2 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=9.24 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=12.9 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=7.02 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=24.3 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=13.6 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=3.87 m
...

The wifi throughput:

iperf -s -i 1
...
[  4] 116.0-117.0 sec  2.88 MBytes  24.1 Mbits/sec
[  4] 117.0-118.0 sec  2.99 MBytes  25.0 Mbits/sec
[  4] 118.0-119.0 sec  3.01 MBytes  25.2 Mbits/sec
[  4] 119.0-120.0 sec  2.89 MBytes  24.2 Mbits/sec
[  4]  0.0-120.4 sec   332 MBytes  23.1 Mbits/sec


PATCH[10/12]: > sdmmc patch for kylin board
ARM: dts: rockchip: add the sdmmc for kylin board

You should mark it "oaky" if you want to use the sdmmc.
This patch default is disabing the sdmmc since the sdmmc and
uart2(debug port) is reusing pin.


PATCH[11/12]: > hdmi/lcdc diaply patch for rk3036 dts
ARM: dts: rockchip: add the lcdc and hdmi node for rk3036

We can add this patch to support it since the Mark Yao has land
your vop support.
https://github.com/markyzq/kernel-drm-rockchip/commits/drm-rockchip-next-2015-12-28

[PATCH v2 2/2] dt-bindings: add document for Innosilicon HDMI on Rockchip platform

[Yakir Yang]

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
---
Changes in v2:
- Correct the misspell "rk3036-dw-hdmi" (Heiko)

 .../display/rockchip/inno_hdmi-rockchip.txt| 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
new file mode 100644
index 000..8096a29
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
@@ -0,0 +1,50 @@
+Rockchip specific extensions to the Innosilicon HDMI
+
+
+Required properties:
+- compatible:
+   "rockchip,rk3036-inno-hdmi";
+- reg:
+   Physical base address and length of the controller's registers.
+- clocks, clock-names:
+   Phandle to hdmi controller clock, name should be "pclk"
+- interrupts:
+   HDMI interrupt number
+- ports:
+   Contain one port node with endpoint definitions as defined in
+   Documentation/devicetree/bindings/graph.txt.
+- pinctrl-0, pinctrl-name:
+   Switch the iomux of HPD/CEC pins to HDMI function.
+
+Example:
+hdmi: hdmi@20034000 {
+   compatible = "rockchip,rk3036-inno-hdmi";
+   reg = <0x20034000 0x4000>;
+   interrupts = ;
+   clocks = <  PCLK_HDMI>;
+   clock-names = "pclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ctl>;
+   status = "disabled";
+
+   hdmi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in_lcdc: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   };
+};
+
+ {
+   hdmi {
+   hdmi_ctl: hdmi-ctl {
+   rockchip,pins = <1 8  RK_FUNC_1 _pull_none>,
+   <1 9  RK_FUNC_1 _pull_none>,
+   <1 10 RK_FUNC_1 _pull_none>,
+   <1 11 RK_FUNC_1 _pull_none>;
+   };
+   };
+
+};
-- 
2.1.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 v3 2/5] dt-bindings: mediatek: Modify pinctrl bindings for mt2701

[Linus Walleij]

On Mon, Dec 28, 2015 at 8:09 AM, Biao Huang  wrote:

> Signed-off-by: Biao Huang 

Patch applied with the ACKs.

Yours,
Linus Walleij
--
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] arm64/dts: Add missing DMA Abort interrupt to Juno

[Robin Murphy]

The DMA-330 has an "irq_abort" interrupt line on which it signals faults
separately from the "irq[n:0]" channel interrupts. On Juno, this is
wired up to SPI 92; add it to the DT so that DMAC faults are correctly
reported for the driver to reset the thing, rather than leaving it
locked up and waiting to time out.

CC: Liviu Dudau 
CC: Sudeep Holla 
CC: Lorenzo Pieralisi 
Signed-off-by: Robin Murphy 
---
 arch/arm64/boot/dts/arm/juno-base.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi 
b/arch/arm64/boot/dts/arm/juno-base.dtsi
index dd5158e..e5b59ca 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -115,6 +115,7 @@
 ,
 ,
 ,
+,
 ,
 ,
 ,
-- 
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

[RFC PATCH v2 4/4] dt-bindings: add document for rk3229-hdmi

[Yakir Yang]

Signed-off-by: Yakir Yang 
---
Changes in v2: None

 .../devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 668091f..1cdc627 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -2,7 +2,7 @@ Rockchip specific extensions to the Synopsys Designware HDMI
 
 
 Required properties:
-- compatible: "rockchip,rk3288-dw-hdmi";
+- compatible: "rockchip,rk3288-dw-hdmi", "rockchip,rk3229-dw-hdmi";
 - reg: Physical base address and length of the controller's registers.
 - clocks: phandle to hdmi iahb and isfr clocks.
 - clock-names: should be "iahb" "isfr"
@@ -15,8 +15,10 @@ Required properties:
   rk3288 platform
 
 Optional properties
+- reg: Physical base address and length of the external HDMI PHY's registers.
 - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
 - clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
+  phandle to the external HDMI PHY clock, name should be 
"extphy"
 
 Example:
 hdmi: hdmi@ff98 {
-- 
2.1.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] phy: rcar-gen3-usb2: remove HSUSB registers handling

[Yoshihiro Shimoda]

Since the related driver (CPG/MSSR driver) only manages the first module
clock, this driver should not handle the HSUSB registers. So, this patch
removes the HSUSB registers handling.

Signed-off-by: Yoshihiro Shimoda 
---
 This patch is based on the linux-phy / next branch.
 (commit id = 9955a7835bf376e12482583958b2661f501b868b)

 .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 15 ++--
 drivers/phy/phy-rcar-gen3-usb2.c   | 83 +++---
 2 files changed, 15 insertions(+), 83 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt 
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
index 2390e4e..eaf7e9b 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -7,33 +7,26 @@ Required properties:
 - compatible: "renesas,usb2-phy-r8a7795" if the device is a part of an R8A7795
  SoC.
 - reg: offset and length of the partial USB 2.0 Host register block.
-- reg-names: must be "usb2_host".
 - clocks: clock phandle and specifier pair(s).
 - #phy-cells: see phy-bindings.txt in the same directory, must be <0>.
 
 Optional properties:
 To use a USB channel where USB 2.0 Host and HSUSB (USB 2.0 Peripheral) are
-combined, the device tree node should set HSUSB properties to reg and reg-names
-properties. This is because HSUSB has registers to select USB 2.0 host or
-peripheral at that channel:
-- reg: offset and length of the partial HSUSB register block.
-- reg-names: must be "hsusb".
+combined, the device tree node should set interrupt properties to use the
+channel as USB OTG:
 - interrupts: interrupt specifier for the PHY.
 
 Example (R-Car H3):
 
usb-phy@ee080200 {
compatible = "renesas,usb2-phy-r8a7795";
-   reg = <0 0xee080200 0 0x700>, <0 0xe6590100 0 0x100>;
-   reg-names = "usb2_host", "hsusb";
+   reg = <0 0xee080200 0 0x700>;
interrupts = ;
-   clocks = <_clks R8A7795_CLK_EHCI0>,
-<_clks R8A7795_CLK_HSUSB>;
+   clocks = <_clks R8A7795_CLK_EHCI0>;
};
 
usb-phy@ee0a0200 {
compatible = "renesas,usb2-phy-r8a7795";
reg = <0 0xee0a0200 0 0x700>;
-   reg-names = "usb2_host";
clocks = <_clks R8A7795_CLK_EHCI0>;
};
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index ef332ef..bc4f7dd 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -74,20 +74,6 @@
 #define USB2_ADPCTRL_IDPULLUP  BIT(5)  /* 1 = ID sampling is enabled */
 #define USB2_ADPCTRL_DRVVBUS   BIT(4)
 
-/*** HSUSB registers (original offset is +0x100) ***/
-#define HSUSB_LPSTS0x02
-#define HSUSB_UGCTRL2  0x84
-
-/* Low Power Status register (LPSTS) */
-#define HSUSB_LPSTS_SUSPM  0x4000
-
-/* USB General control register 2 (UGCTRL2) */
-#define HSUSB_UGCTRL2_MASK 0x0031 /* bit[31:6] should be 0 */
-#define HSUSB_UGCTRL2_USB0SEL  0x0030
-#define HSUSB_UGCTRL2_USB0SEL_HOST 0x0010
-#define HSUSB_UGCTRL2_USB0SEL_HS_USB   0x0020
-#define HSUSB_UGCTRL2_USB0SEL_OTG  0x0030
-
 struct rcar_gen3_data {
void __iomem *base;
struct clk *clk;
@@ -95,8 +81,8 @@ struct rcar_gen3_data {
 
 struct rcar_gen3_chan {
struct rcar_gen3_data usb2;
-   struct rcar_gen3_data hsusb;
struct phy *phy;
+   bool has_otg;
 };
 
 static void rcar_gen3_set_host_mode(struct rcar_gen3_chan *ch, int host)
@@ -202,24 +188,15 @@ static int rcar_gen3_phy_usb2_init(struct phy *p)
 {
struct rcar_gen3_chan *channel = phy_get_drvdata(p);
void __iomem *usb2_base = channel->usb2.base;
-   void __iomem *hsusb_base = channel->hsusb.base;
-   u32 val;
 
/* Initialize USB2 part */
writel(USB2_INT_ENABLE_INIT, usb2_base + USB2_INT_ENABLE);
writel(USB2_SPD_RSM_TIMSET_INIT, usb2_base + USB2_SPD_RSM_TIMSET);
writel(USB2_OC_TIMSET_INIT, usb2_base + USB2_OC_TIMSET);
 
-   /* Initialize HSUSB part */
-   if (hsusb_base) {
-   val = readl(hsusb_base + HSUSB_UGCTRL2);
-   val = (val & ~HSUSB_UGCTRL2_USB0SEL) |
- HSUSB_UGCTRL2_USB0SEL_OTG;
-   writel(val & HSUSB_UGCTRL2_MASK, hsusb_base + HSUSB_UGCTRL2);
-
-   /* Initialize otg part */
+   /* Initialize otg part */
+   if (channel->has_otg)
rcar_gen3_init_otg(channel);
-   }
 
return 0;
 }
@@ -237,7 +214,6 @@ static int rcar_gen3_phy_usb2_power_on(struct phy *p)
 {
struct rcar_gen3_chan *channel = phy_get_drvdata(p);
void __iomem *usb2_base = channel->usb2.base;
-   void __iomem *hsusb_base = channel->hsusb.base;
u32 val;
 
val = 

[PATCH v2 1/2] drm: rockchip/hdmi: add Innosilicon HDMI support

[Yakir Yang]

The Innosilicon HDMI is a low power HDMI 1.4 transmitter
IP, and it have been integrated on some rockchip CPUs
(like RK3036, RK312x).

Signed-off-by: Yakir Yang 
---
Changes in v2:
- Using DRM atomic helper functions for connector init (Mark)
- Remove "hdmi->connector.encoder = encoder;" (Mark)

 drivers/gpu/drm/rockchip/Kconfig |8 +
 drivers/gpu/drm/rockchip/Makefile|1 +
 drivers/gpu/drm/rockchip/inno_hdmi.c | 1010 ++
 drivers/gpu/drm/rockchip/inno_hdmi.h |  364 
 4 files changed, 1383 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
 create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..a5014e0 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,11 @@ config ROCKCHIP_DW_HDMI
  for the Synopsys DesignWare HDMI driver. If you want to
  enable HDMI on RK3288 based SoC, you should selet this
  option.
+
+config ROCKCHIP_INNO_HDMI
+   tristate "Rockchip specific extensions for Innosilicon HDMI"
+depends on DRM_ROCKCHIP
+help
+ This selects support for Rockchip SoC specific extensions
+ for the Innosilicon HDMI driver. If you want to enable
+ HDMI on RK3036 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index a9d380f..da2bf76 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,6 +6,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o 
rockchip_drm_fbdev.o \
rockchip_drm_gem.o
 
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o \
rockchip_vop_reg.o
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
b/drivers/gpu/drm/rockchip/inno_hdmi.c
new file mode 100644
index 000..9327617
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -0,0 +1,1010 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ *Zheng Yang 
+ *Yakir Yang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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 "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#include "inno_hdmi.h"
+
+#define to_inno_hdmi(x)container_of(x, struct inno_hdmi, x)
+
+struct hdmi_data_info {
+   int vic;
+   bool sink_is_hdmi;
+   bool sink_has_audio;
+   unsigned int enc_in_format;
+   unsigned int enc_out_format;
+   unsigned int colorimetry;
+};
+
+struct inno_hdmi_i2c {
+   struct i2c_adapter adap;
+
+   u8 ddc_addr;
+   u8 segment_addr;
+
+   struct mutex lock;
+   struct completion cmp;
+};
+
+struct inno_hdmi {
+   struct device *dev;
+   struct drm_device *drm_dev;
+
+   int irq;
+   struct clk *pclk;
+   void __iomem *regs;
+
+   struct drm_connectorconnector;
+   struct drm_encoder  encoder;
+
+   struct inno_hdmi_i2c *i2c;
+   struct i2c_adapter *ddc;
+
+   int dpms_mode;
+   unsigned int tmds_rate;
+
+   struct hdmi_data_info   hdmi_data;
+   struct drm_display_mode previous_mode;
+};
+
+enum {
+   CSC_ITU601_16_235_TO_RGB_0_255_8BIT,
+   CSC_ITU601_0_255_TO_RGB_0_255_8BIT,
+   CSC_ITU709_16_235_TO_RGB_0_255_8BIT,
+   CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
+   CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
+   CSC_RGB_0_255_TO_RGB_16_235_8BIT,
+};
+
+static const char coeff_csc[][24] = {
+   /*
+* YUV2RGB:601 SD mode(Y[16:235], UV[16:240], RGB[0:255]):
+*   R = 1.164*Y + 1.596*V - 204
+*   G = 1.164*Y - 0.391*U - 0.813*V + 154
+*   B = 1.164*Y + 2.018*U - 258
+*/
+   {
+   0x04, 0xa7, 0x00, 0x00, 0x06, 0x62, 0x02, 0xcc,
+   0x04, 0xa7, 0x11, 0x90, 0x13, 0x40, 0x00, 0x9a,
+   0x04, 0xa7, 0x08, 0x12, 0x00, 0x00, 0x03, 0x02
+   },
+   /*
+* YUV2RGB:601 SD mode(YUV[0:255],RGB[0:255]):
+*   R = Y + 1.402*V - 248
+*   G = Y - 0.344*U - 0.714*V + 135
+*   B = Y + 1.772*U - 227
+*/
+   {
+   0x04, 0x00, 0x00, 0x00, 0x05, 0x9b, 0x02, 

Re: [PATCH v2 00/12] Add the family patches to support for kylin board

[Heiko Stuebner]

Hi Caesar,

Am Donnerstag, 7. Januar 2016, 16:25:43 schrieb Caesar Wang:
> Hi all,
> 
> Happy new year! :)
> Let's go on working for happy.

please make sure to split your patch-series at appropriate points for future 
versions to only address relevant people. For example I don't think Ulf 
really cares about getting the audio-related or general devicetree patches.


Heiko

> This series patches are based on kernel version 4.4.0-rc8+
> (Linux version 4.4.0-rc8+ (wxt@ubuntu)...#142 SMP Thu Jan 7 12:38:40 CST
> 2016)
> 
> This series pacthes are verified on the following github:
> https://github.com/Caesar-github/rockchip/commits/kylin-develop4.4
> 
> This series has 12 patches: (12--->1)
> bbd1a01 ARM: dts: Add pl330-broken-no-flushp quirk for rk3036 SoCs
> fb8c1fd ARM: dts: rockchip: add the lcdc and hdmi node for rk3036
> 1aeb49d ARM: dts: rockchip: add the sdmmc for kylin board
> 3e19128 ARM: dts: rockchip: enable the uart0 for kylin board
> e7de154 ARM: dts: rockchip: add the wifi/bt regulator for kylin board
> 8699698 ARM: dts: rockchip: enable the high speed on sdio for kylin board
> 21eded4 mmc: pwrseq: add support for power-on sequencing through DT
> cdf3a7e mmc: pwrseq: Document optional exteral vcc for the simple power
> sequence 131c249 clk: rockchip: rk3036: enable the CLK_IGNORE_UNUSED flag
> for sclk_i2s_out b7ff8e1 ARM: dts: rockchip: override the clocks in i2s
> for kylin board 5f56af4 ARM: dts: rockchip: add the sound codec for kylin
> board
> 914d9c0 ARM: dts: rockchip: set the pinctrl default setting for rk3036 i2s
> ..
> 
> This series patches have the following decriptions:
> 
> PATCH[1/12-4/12]:> Support rt5616 codec for kylin board
> 914d9c0 ARM: dts: rockchip: set the pinctrl default setting for rk3036 i2s
> 5f56af4 ARM: dts: rockchip: add the sound codec for kylin board
> b7ff8e1 ARM: dts: rockchip: override the clocks in i2s for kylin board
> 131c249 clk: rockchip: rk3036: enable the CLK_IGNORE_UNUSED flag for
> sclk_i2s_out
> 
> This patches is working for codec rt5616 on kylin board. (RK3036 SoCs)
> 
> That's needed the following rt5616 driver from Mark Brown Branch.
> (cherry picked from git.kernel.org broonie/sound.git for-next)
> 
> cf94b7a UPSTREAM: ASoC: rt5616: rename some alsa control names
> 86f561d UPSTREAM: ASoC: rt5616: add devicetree document for rt5616
> 0e0f5f8 UPSTREAM: ASoC: rt5616: add an of_match table
> 263a330 UPSTREAM: ASoC: rt5616: Return error if device ID mismatch
> 0094139 UPSTREAM: ASoC: rt5616: add rt5616 codec driver
> 
> Notes:
> I'm run it with the ubuntu 15.04 to set the configure.
> ./amixer "HP Playback Switch" 1
> ./amixer "HP Playback Volume" 20
> ./amixer "HPO MIX DAC1 Switch" 1
> ./amixer "OUT MIXR DAC R1 Switch" 1
> ./amixer "OUT MIXL DAC L1 Switch" 1
> ./amixer "Stereo DAC MIXR DAC R1 Switch" 1
> ./amixer "Stereo DAC MIXL DAC L1 Switch" 1
> 
> root@linaro-alip:/media/aplay# ./aplay pcm.wav
> Playing sample: 2 ch, 48000 hz, 16 bit
> ..
> That can be normal playing the music.
> 
> 
> PATCH[5/12-9/12]: > Support wifi/bt module for kylin board
> cdf3a7e mmc: pwrseq: Document optional exteral vcc for the simple power
> sequence 21eded4 mmc: pwrseq: add support for power-on sequencing through
> DT 8699698 ARM: dts: rockchip: enable the high speed on sdio for kylin
> board e7de154 ARM: dts: rockchip: add the wifi/bt regulator for kylin
> board 3e19128 ARM: dts: rockchip: enable the uart0 for kylin board
> 
> The wifi/bt driver hasn't land in mainline, the driver is in here:
> https://github.com/Caesar-github/rockchip/commit/1912ef4c0e358677904b0a0bb
> b83f9745066f0ec
> 
> wpa_supplicant -Dnl80211 -c /etc/wifi/wpa_supplicant.conf -i wlan0 -B
> wpa_cli add_network
> wpa_cli set_network 1 ssid \"wxt\"
> wpa_cli set_network 1 psk \"123456789\"
> wpa_cli select_network 1
> wpa_cli save_config
> 
> ifconfig wlan0 192.168.1.105
> route add default gw 192.168.1.1
> 
> root@linaro-alip:/# ping 192.168.1.1
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=6.83 ms
> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=184 ms
> 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=9.21 ms
> 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=6.84 ms
> 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=11.2 ms
> 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=9.24 ms
> 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=12.9 ms
> 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=7.02 ms
> 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=24.3 ms
> 64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=13.6 ms
> 64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=3.87 m
> ...
> 
> The wifi throughput:
> 
> iperf -s -i 1
> ...
> [  4] 116.0-117.0 sec  2.88 MBytes  24.1 Mbits/sec
> [  4] 117.0-118.0 sec  2.99 MBytes  25.0 Mbits/sec
> [  4] 118.0-119.0 sec  3.01 MBytes  25.2 Mbits/sec
> [  4] 119.0-120.0 sec  2.89 MBytes  24.2 Mbits/sec
> [  4]  0.0-120.4 sec   332 MBytes  23.1 Mbits/sec
> 
> 
> 

Re: [PATCH v2 1/2] drm: bridge: sil902x

[Boris Brezillon]

Hi Archit,

On Thu, 7 Jan 2016 11:12:47 +0530
Archit Taneja  wrote:

> 
> 
> On 01/06/2016 05:55 PM, Boris Brezillon wrote:
> > Add basic support for the sil902x RGB -> HDMI bridge.
> > This driver does not support audio output yet.
> >
> > Signed-off-by: Boris Brezillon 
> > ---
> > Hello,
> >
> > This patch is only adding basic support for the sil9022 chip.
> > As stated in the commit log, there's no audio support, but the
> > driver also hardcodes a lot of things (like the RGB input format to
> > use).
> > There are two reasons for this:
> > 1/ the DRM framework does not allow for advanced link description
> > between an encoder and a bridge (that's for the RGB format
> > limitation). Any idea how this should be described?
> 
> The adv7511 driver uses a DT param "input_colorspace" to chose between
> RGB or YUV. I don't think DT is the best idea, but I don't know of a
> better way either.

Yes, maybe not the best place, but I must admit that's a convenient way
to set the link format.

> 
> The connector's display_info.color_formats field gives us some info
> about the color formats supported by the monitor, but I guess that
> isn't sufficient data to know what format the encoder is pushing out.

I created the ->bus_formats field in drm_display_info exactly for this
purpose (it's used to detect the appropriate output format when
connecting panels), but as you said, this is only describing the link
between the connector and the display, not the link between the encoder
and the bridge.
I'm currently abusing this field (setting bus_formats to RGB888 in the
sii902x driver), but that would be better to have this description at
the encoder/bridge level.

> 
> We get around this problem in case the case of DSI encoders by using
> the mipi_dsi_device api, where a DSI based bridge or panel can pass
> color format/lane info to the DSI host (i.e, encoder) by using
> mipi_dsi_attach().

Yep, that's also an approach I considered a while ago: creating a DPI
bus layer (not sure DPI is the correct name here), and implementing a
DPI driver in atmel_hlcdc drivers and using DPI APIs on the slave side
(panels and bridges/encoders). But I never had any feedback.

> 
> 
> >
> > 2/ I don't have the datasheet of this HDMI encoder, and all logic
> > has been extracted from those two drivers [1][2], which means
> > I may miss some important things in my encoder setup.
> >
> > Another thing I find weird in the drm_bridge interface is the fact
> > that we have a ->attach() method, but no ->detach(), which can be
> > a problem if we allow drm bridges and KMS drivers to be compiled as
> > modules. Any reason for that?
> 
> I guess the drm_bridge_add/remove ops make can ensure that the bridge
> driver itself can be compiled as a module. However, you're right that
> we would need a bridge detach op that the kms driver should call
> before it is removed (to unregister the connector we created).
> 
> Someone would still need to make sure about the order in which the
> modules are removed. If the bridge driver is removed first, then
> it would really mess up the kms driver using the bridge.

Yes, the remove order is another problem we have to deal with

> 
> 
> Would the kms driver using this chip really have an encoder?

No, I have to create an encoder of type NONE to make everybody happy
(we need an encoder + a connector to attach to a panel), but as I
understand, when the KMS device outputs the pixel stream in raw RGB it's
not considered as an encoder (which IMO is not such a good idea,
because I have no way to represent my raw RGB connector :-/).

> Since the chip takes in RGB input, I'm assuming that the encoder in
> the kms driver would more or less be nop funcs, giving their way to
> bridge ops.

Exactly, that's a nop unless you have a panel connected to it. In the
case it calls the drm_panel_xxx() functions.

> 
> In such cases, I think the bridge still doesn't fit in so well. The
> best fit here is how the current tda998x driver is modeled. It adds
> itself as a component that creates both an encoder and connector,
> which the kms driver can use directly. This approach, of course,
> prevents us using tda998x in kms drivers that don't accept any
> encoders that it didn't create itself.

Actually that's what I did first [1], but I asked for some advice to
other DRM developers, and they suggested to expose it as a drm_bridge.

Now, I don't know what's the best option: I heard that some work was
being done to merge the encoder slave and bridge concepts. I just
thought external encoders were falling in that case too.
And BTW, the different between all those components is still obscure to
me.

Thanks for the suggestions.

Best Regards,

Boris

[1]https://github.com/linux4sam/linux-at91/blob/linux-3.18-at91/drivers/gpu/drm/i2c/sil902x.c


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from 

Re: [RFC PATCH v2 3/4] drm: rockchip: hdmi: add RK3229 HDMI support

[Yakir Yang]

Hi Philipp,

Thanks for your fast respond :)

On 01/07/2016 06:04 PM, Philipp Zabel wrote:

Am Donnerstag, den 07.01.2016, 17:02 +0800 schrieb Yakir Yang:

RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy,
the max output resolution is 4K.

Signed-off-by: Yakir Yang 

It sounds like the INNO HDMI2.0 phy is not necessarily specific to
RK3229 but might also appear in other SoCs? If so, I think this should
be implemented in a separate phy driver and be used by dw_hdmi-rockchip.


Do you mean I should create a new phy driver that place in "driver/phy" 
directly ?


I have think about this idea, and it would make things much clean. But 
INNO PHY
driver need the target pixel clock in drm_display_mode, I didn't find a 
good way

to pass this variable to separate phy driver. Do you have some idea ?

Thanks,
- Yakir


regards
Philipp


---
Changes in v2:
- Split some dw-hdmi driver changes into separate patches [01/04] & [02/04]

  drivers/gpu/drm/bridge/dw-hdmi.c|  27 +-
  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 367 ++--
  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h | 137 +++
  include/drm/bridge/dw_hdmi.h|   3 +
  4 files changed, 507 insertions(+), 27 deletions(-)
  create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 5ad72ec..5e03d83 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -735,10 +735,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
  {
unsigned res_idx;
u8 val, msec;
+   int ret;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
+   int mpixelclock = hdmi->hdmi_data.video_mode.mpixelclock;
  
  	if (prep)

return -EINVAL;
@@ -758,27 +760,38 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
return -EINVAL;
}
  
+	if (hdmi->plat_data->extphy_config) {

+   /* gen2 tx power off */
+   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
+   dw_hdmi_phy_gen2_pddq(hdmi, 1);
+
+   ret = hdmi->plat_data->extphy_config(hdmi->plat_data, res_idx,
+mpixelclock);
+   /* gen2 tx power on */
+   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
+   dw_hdmi_phy_gen2_pddq(hdmi, 0);
+
+   return ret;
+   }
+
/* PLL/MPLL Cfg - always match on final entry */
for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   mpll_config->mpixelclock)
+   if (mpixelclock <= mpll_config->mpixelclock)
break;
  
  	for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)

-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   curr_ctrl->mpixelclock)
+   if (mpixelclock <= curr_ctrl->mpixelclock)
break;
  
  	for (; phy_config->mpixelclock != ~0UL; phy_config++)

-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   phy_config->mpixelclock)
+   if (mpixelclock <= phy_config->mpixelclock)
break;
  
  	if (mpll_config->mpixelclock == ~0UL ||

curr_ctrl->mpixelclock == ~0UL ||
phy_config->mpixelclock == ~0UL) {
dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
-   hdmi->hdmi_data.video_mode.mpixelclock);
+   mpixelclock);
return -EINVAL;
}
  
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c

index 8164823..24fffaa 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -7,6 +7,7 @@
   * (at your option) any later version.
   */
  
+#include 

  #include 
  #include 
  #include 
@@ -21,18 +22,134 @@
  #include "rockchip_drm_drv.h"
  #include "rockchip_drm_vop.h"
  
-#define GRF_SOC_CON60x025c

-#define HDMI_SEL_VOP_LIT(1 << 4)
+#include "dw_hdmi-rockchip.h"
  
  struct rockchip_hdmi {

struct device *dev;
struct regmap *regmap;
struct drm_encoder encoder;
struct dw_hdmi_plat_data plat_data;
+
+   void __iomem *extphy_regbase;
+   struct clk *extphy_pclk;
  };
  
  #define to_rockchip_hdmi(x)	container_of(x, struct rockchip_hdmi, x)
  
+static const struct extphy_config_tab rockchip_extphy_cfg[] = {

+   { .mpixelclock = 16500,
+ .pre_emphasis = 0, .slopeboost = 0, 

Re: [PATCH v3 5/5] arm: dts: Add pinctrl/GPIO/EINT node for mt2701

[Linus Walleij]

On Thu, Dec 31, 2015 at 12:23 PM, Matthias Brugger
 wrote:
> On 28/12/15 08:09, Biao Huang wrote:
>>
>> Add pinctrl and GPIO node to mt2701.dtsi
>>
>> Signed-off-by: Biao Huang 
>> Acked-by: Linus Walleij 
>> ---
>>   arch/arm/boot/dts/mt2701.dtsi |   19 +++
>>   1 file changed, 19 insertions(+)
>>
>
> Signed-off-by: Matthias Brugger 
>
> Linus, will you take this patch through your branch?

No I prefer anything in arch/arm/boot/dts/* to go in through
the ARM SoC tree.

It can usually be merged orthogonally anyways.

I take Documenation/devicetree/bindings/* and patches
to the driver itself in drivers/pinctrl/*

Yours,
Linus Walleij
--
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 0/5] fix some clock configuration for the RK3036 platform

[Xing Zheng]

Hi:
  In the development work, we found that some of the previous
incorrect clock configuration on the RK3036 platform, we should
fix them.



Xing Zheng (5):
  clk: rockchip: rk3036: fix the FLAGs for clock mux
  clk: rockchip: rk3036: fix uarts clock error
  clk: rockchip: rk3036: fix the div offset for emac clock
  clk: rockchip: rk3036: rename emac ext source clock
  clk: rockchip: rk3036: add HCLK_MAC id for emac

 drivers/clk/rockchip/clk-rk3036.c  |   28 ++--
 include/dt-bindings/clock/rk3036-cru.h |1 +
 2 files changed, 15 insertions(+), 14 deletions(-)

-- 
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] mmc: host: arasan: sdhci-of-arasan: Remove no-hispd and no-cmd23 quirks for sdhci-arasan4.9a

[Rameshwar Sahu]

Hi Jaehoon,

On Thu, Jan 7, 2016 at 7:03 AM, Jaehoon Chung  wrote:
> Hi,
>
> On 01/05/2016 07:25 PM, Rameshwar Sahu wrote:
>> Hi Ulf,
>>
>> On Wed, Dec 23, 2015 at 6:59 PM, Rameshswar Prasad Sahu  
>> wrote:
>>> From: Rameshwar Prasad Sahu 
>>>
>>> The Arason SD host controller supports set block count command (cmd23)
>>> and high speed mode. This patch re-enable both of these features that
>>> was disabled. For device that doesn't support high speed, it should
>>> configure its capability register accordingly instead disables it
>>> explicitly.
>>>
>>> Signed-off-by: Rameshwar Prasad Sahu 
>>> ---
>>>  drivers/mmc/host/sdhci-of-arasan.c |5 -
>>>  1 files changed, 0 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
>>> b/drivers/mmc/host/sdhci-of-arasan.c
>>> index 75379cb..5d9fdb3 100644
>>> --- a/drivers/mmc/host/sdhci-of-arasan.c
>>> +++ b/drivers/mmc/host/sdhci-of-arasan.c
>>> @@ -172,11 +172,6 @@ static int sdhci_arasan_probe(struct platform_device 
>>> *pdev)
>>> goto clk_disable_all;
>>> }
>>>
>>> -   if (of_device_is_compatible(pdev->dev.of_node, 
>>> "arasan,sdhci-4.9a")) {
>>> -   host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
>>> -   host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
>
> I'm not sure what's correct since i didn't have any information for arasan.
> But in case of exynos, SDHCI_QUIRK_NO_HISPD_BIT is used because that bit is 
> used as other purpose.
> If your SoC is not used anymore, i think this patch looks good.

Our SoC doesn't need that bit, that's why we are going to remove it.

>
> Best Regards,
> Jaehoon Chung
>
>>> -   }
>>> -
>>> sdhci_get_of_property(pdev);
>>> pltfm_host = sdhci_priv(host);
>>> pltfm_host->priv = sdhci_arasan;
>>> --
>>> 1.7.1
>>>
>>
>> Any comment on this patch ??
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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

[PATCH v2 08/10] [media] tvp5150: Add OF match table

[Javier Martinez Canillas]

From: Eduard Gavin 

The Documentation/devicetree/bindings/media/i2c/tvp5150.txt DT binding doc
lists "ti,tvp5150" as the device compatible string but the driver does not
have an OF match table. Add the table to the driver so the I2C core can do
an OF style match.

Signed-off-by: Eduard Gavin 
Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Laurent Pinchart 

---

Changes in v2:
- Add Reviewed-by tag from Laurent Pinchart to patch 8/10.

 drivers/media/i2c/tvp5150.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 105bd1c6b17f..caac96a577f8 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1295,8 +1295,17 @@ static const struct i2c_device_id tvp5150_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, tvp5150_id);
 
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id tvp5150_of_match[] = {
+   { .compatible = "ti,tvp5150", },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, tvp5150_of_match);
+#endif
+
 static struct i2c_driver tvp5150_driver = {
.driver = {
+   .of_match_table = of_match_ptr(tvp5150_of_match),
.name   = "tvp5150",
},
.probe  = tvp5150_probe,
-- 
2.4.3

--
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 05/10] [media] tvp5150: Add s_stream subdev operation support

[Javier Martinez Canillas]

From: Laurent Pinchart 

This patch adds the .s_stream subdev operation to the driver.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Javier Martinez Canillas 
---

Changes in v2: None

 drivers/media/i2c/tvp5150.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 71473cec236a..fb7a4ddff1fe 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -973,6 +973,21 @@ static int tvp5150_enum_frame_size(struct v4l2_subdev *sd,
I2C Command
  /
 
+static int tvp5150_s_stream(struct v4l2_subdev *sd, int enable)
+{
+   /* Initializes TVP5150 to its default values */
+   /* # set PCLK (27MHz) */
+   tvp5150_write(sd, TVP5150_CONF_SHARED_PIN, 0x00);
+
+   /* Output format: 8-bit ITU-R BT.656 with embedded syncs */
+   if (enable)
+   tvp5150_write(sd, TVP5150_MISC_CTL, 0x09);
+   else
+   tvp5150_write(sd, TVP5150_MISC_CTL, 0x00);
+
+   return 0;
+}
+
 static int tvp5150_s_routing(struct v4l2_subdev *sd,
 u32 input, u32 output, u32 config)
 {
@@ -1094,6 +1109,7 @@ static const struct v4l2_subdev_tuner_ops 
tvp5150_tuner_ops = {
 
 static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
.s_std = tvp5150_s_std,
+   .s_stream = tvp5150_s_stream,
.s_routing = tvp5150_s_routing,
.s_crop = tvp5150_s_crop,
.g_crop = tvp5150_g_crop,
-- 
2.4.3

--
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 07/10] [media] tvp5150: Add device tree binding document

[Javier Martinez Canillas]

Add a Device Tree binding document for the TVP5150 video decoder.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Laurent Pinchart 

---

Changes in v2:
- Fix indentation of the DTS example. Suggested by Rob Herring.
- Rename powerdown-gpios to pdn-gpios to match the pin name in
  the datasheet. Suggested by Laurent Pinchart.
- Add optional properties for the video endpoint and list the supported
  values. Suggested by Laurent Pinchart.

 .../devicetree/bindings/media/i2c/tvp5150.txt  | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp5150.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt 
b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
new file mode 100644
index ..8c0fc1a26bf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
@@ -0,0 +1,45 @@
+* Texas Instruments TVP5150 and TVP5151 video decoders
+
+The TVP5150 and TVP5151 are video decoders that convert baseband NTSC and PAL
+(and also SECAM in the TVP5151 case) video signals to either 8-bit 4:2:2 YUV
+with discrete syncs or 8-bit ITU-R BT.656 with embedded syncs output formats.
+
+Required Properties:
+- compatible: value must be "ti,tvp5150"
+- reg: I2C slave address
+
+Optional Properties:
+- pdn-gpios: phandle for the GPIO connected to the PDN pin, if any.
+- reset-gpios: phandle for the GPIO connected to the RESETB pin, if any.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Required Endpoint Properties for parallel synchronization:
+
+- hsync-active: active state of the HSYNC signal. Must be <1> (HIGH).
+- vsync-active: active state of the VSYNC signal. Must be <1> (HIGH).
+- field-even-active: field signal level during the even field data
+  transmission. Must be <0>.
+
+If none of hsync-active, vsync-active and field-even-active is specified,
+the endpoint is assumed to use embedded BT.656 synchronization.
+
+Example:
+
+ {
+   ...
+   tvp5150@5c {
+   compatible = "ti,tvp5150";
+   reg = <0x5c>;
+   pdn-gpios = < 30 GPIO_ACTIVE_LOW>;
+   reset-gpios = < 7 GPIO_ACTIVE_LOW>;
+
+   port {
+   tvp5150_1: endpoint {
+   remote-endpoint = <_ep>;
+   };
+   };
+   };
+};
-- 
2.4.3

--
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 04/10] [media] tvp5150: Add pixel rate control support

[Javier Martinez Canillas]

From: Laurent Pinchart 

This patch adds support for the V4L2_CID_PIXEL_RATE control.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Javier Martinez Canillas 
---

Changes in v2: None

 drivers/media/i2c/tvp5150.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 82fba9d46f30..71473cec236a 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1204,7 +1204,7 @@ static int tvp5150_probe(struct i2c_client *c,
core->input = TVP5150_COMPOSITE1;
core->enable = 1;
 
-   v4l2_ctrl_handler_init(>hdl, 4);
+   v4l2_ctrl_handler_init(>hdl, 5);
v4l2_ctrl_new_std(>hdl, _ctrl_ops,
V4L2_CID_BRIGHTNESS, 0, 255, 1, 128);
v4l2_ctrl_new_std(>hdl, _ctrl_ops,
@@ -1213,6 +1213,9 @@ static int tvp5150_probe(struct i2c_client *c,
V4L2_CID_SATURATION, 0, 255, 1, 128);
v4l2_ctrl_new_std(>hdl, _ctrl_ops,
V4L2_CID_HUE, -128, 127, 1, 0);
+   v4l2_ctrl_new_std(>hdl, _ctrl_ops,
+   V4L2_CID_PIXEL_RATE, 2700,
+   2700, 1, 2700);
sd->ctrl_handler = >hdl;
if (core->hdl.error) {
res = core->hdl.error;
-- 
2.4.3

--
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] arm64/dts: Add missing DMA Abort interrupt to Juno

[Arnd Bergmann]

On Thursday 07 January 2016 12:01:59 Robin Murphy wrote:
> The DMA-330 has an "irq_abort" interrupt line on which it signals faults
> separately from the "irq[n:0]" channel interrupts. On Juno, this is
> wired up to SPI 92; add it to the DT so that DMAC faults are correctly
> reported for the driver to reset the thing, rather than leaving it
> locked up and waiting to time out.
> 
> CC: Liviu Dudau 
> CC: Sudeep Holla 
> CC: Lorenzo Pieralisi 
> Signed-off-by: Robin Murphy 
> 

Nothing wrong with the patch, but could you please come up with
a more structured way to get patches for Juno into the kernel?

You have addressed the patch "to:" the arm-soc maintainers, but
you are not listed in the maintainers file for the directory, so
it's not clear what you expect to happen here.

Ideally, we'd get patches from just one of the people listed
in the MAINTAINERS file normally, and let us know if the
primary maintainer changes, or if one of the others sends a
patch because that person is unavailable.

Arnd
--
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] arm: dts: bcm5301x: Add syscon based reboot in DT

[Arnd Bergmann]

On Tuesday 05 January 2016 17:26:06 Jon Mason wrote:
> On Fri, Dec 18, 2015 at 10:44:28PM +0100, Arnd Bergmann wrote:
> > On Friday 18 December 2015 16:37:56 Jon Mason wrote:
> > > +   cru: cru@1800c184 {
> > > +   compatible = "syscon";
> > > +   reg = <0x1800c184 0xc>;
> > > +   };
> > 
> > It's unusual for a device to start at such an odd address. Are you sure
> > it's not a larger device starting at 0x1800c000 or 0x1800?
> 
> The CRU (Clock and Reset Unit) starts at 0x1800c100, with the
> following layout:
> 
> CRU Clock Management at 0x1800c100-0x1800c180
> CRU Reset at 0x1800c184
> CRU Period Sample Clock at 0x1800c188
> CRU Interrupt register at 0x1800c18c
> CRU MDIO Control at 0x1800c190
> CRU GPIO at 0x1800c1c0-0x1800c1e0
> CRU SDIO 0x1800c200-0x1800c214
> CRU RoboSW Interrupt at 0x1800c280
> CRU Straps Control at 0x1800c2a0
> 
> The clock driver is already referencing the registers between
> 0x1800c100-0x1800c180, and the GPIO driver is referencing registers
> between 0x1800c1c0-0x1800c1e0.
> 
> The reset part of the syscon seems to be the only useful thing in this
> block.  Am I approaching this incorrectly?

I think the problem is how the gpio controller has a device node
that overlaps with one of the devices of the chip.

If the data sheet lists a "Clock and Reset Unit" at those addresses,
that is a strong indication that this is actually a specific
piece of hardware, and it should be represented as one device node
in DT, with the sub-registers being exposed by that driver in
some way. A typical way would be to have a syscon node like

cru: syscon@1800c100 {
compatible = "brcm,bcm53010-clock-reset-unit", "syscon";
reg = <0x1800c100 100>;
};

that represents the entire unit. You can then have syscon references
in each driver that uses it, and/or create a high-level driver that
binds to the "brcm,bcm53010-clock-reset-unit" compatible string and that
exports a set of functions for other drivers to be used if you prefer
to do this as functional abstraction rather than register based.

> > Also, please provide a more specific compatible string based on the
> > name of the device in the data sheet. The node name in contrast should
> > be more generic, e.g.
> > 
> > cru: system-controller@1800c000 {
> > compatible = "brcm,bcm53010-cru", "syscon";
> 
> This is very similar between the NS and NSP (and NS2) platforms.  I'll
> verify the layout and see if this can't be "brcm,iproc-cru" or
> something similar.

If it's only "very similar" but not identical, don't use the same compatible
string, at least not as the only one. You should be able to identify the
specific device by looking at its compatible string in case you want to
write a high-level driver that knows about the differences later (the driver
should not need to inquire the chip name, it should only look at one device
node).

Arnd
--
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: [GIT PULL 3/9] ARM64: EXYNOS: clk: Clock dependency for ARM64 for v4.5

[Olof Johansson]

Hi,

Sorry for the slow reply, holidays and vacation and all that.

On Wed, Dec 23, 2015 at 07:44:32PM +0900, Krzysztof Kozlowski wrote:
> W dniu 22.12.2015 o 13:46, Olof Johansson pisze:
> > On Wed, Dec 02, 2015 at 10:39:40AM +0900, Krzysztof Kozlowski wrote:
> >> Hi Kukjin,
> >>
> >> Dependency for soc64 changes.
> >>
> >> Best regards,
> >> Krzysztof
> >>
> >>
> >> The following changes since commit 
> >> 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> >>
> >>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> >>
> >> are available in the git repository at:
> >>
> >>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> >> tags/samsung-clk-arm64-symbols-4.5
> >>
> >> for you to fetch changes up to 8c2a90ed18a74e8b9cdbba679403faa44d6024fc:
> >>
> >>   clk: samsung: Don't build ARMv8 clock drivers on ARMv7 (2015-11-22 
> >> 19:25:29 +0900)
> > 
> > Hi,
> > 
> > Looks like this lacks ack from any of the clock maintainers.
> 
> It got the ack from Sylwester and Tomasz - Samsung clock maintainers. If
> it is not sufficient... then let's wait with it for v4.6. I am on
> holidays now so I cannot really do anything meaningful with it.

Ok -- even though we have per-driver maintainers, we still look for acks from
the overall subsystem maintainers on these drivers. 

> > Given that EXYNOS_ARM64_COMMON_CLK is not yet introduced, this will cause
> > a breakage in bisectability on some of these platforms as well.
> 
> The patch introduces EXYNOS_ARM64_COMMON_CLK which will be enabled by
> default on our platforms. What kind of breakage do you have in mind?

Ah, I probably missed that.


-Olof
--
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 01/10] [media] tvp5150: Restructure version detection

[Javier Martinez Canillas]

From: Laurent Pinchart 

Move the version detection code to a separate function and restructure
it to prepare for TVP5151 support.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Javier Martinez Canillas 
---

Changes in v2: None

 drivers/media/i2c/tvp5150.c | 79 ++---
 1 file changed, 45 insertions(+), 34 deletions(-)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index dda8b3c000cc..9e953e5a7ec9 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1105,13 +1105,53 @@ static const struct v4l2_subdev_ops tvp5150_ops = {
I2C Client & Driver
  /
 
+static int tvp5150_detect_version(struct tvp5150 *core)
+{
+   struct v4l2_subdev *sd = >sd;
+   struct i2c_client *c = v4l2_get_subdevdata(sd);
+   unsigned int i;
+   u16 dev_id;
+   u16 rom_ver;
+   u8 regs[4];
+   int res;
+
+   /*
+* Read consequent registers - TVP5150_MSB_DEV_ID, TVP5150_LSB_DEV_ID,
+* TVP5150_ROM_MAJOR_VER, TVP5150_ROM_MINOR_VER
+*/
+   for (i = 0; i < 4; i++) {
+   res = tvp5150_read(sd, TVP5150_MSB_DEV_ID + i);
+   if (res < 0)
+   return res;
+   regs[i] = res;
+   }
+
+   dev_id = (regs[0] << 8) | regs[1];
+   rom_ver = (regs[2] << 8) | regs[3];
+
+   v4l2_info(sd, "tvp%04x (%u.%u) chip found @ 0x%02x (%s)\n",
+ dev_id, regs[2], regs[3], c->addr << 1, c->adapter->name);
+
+   if (dev_id == 0x5150 && rom_ver == 0x0321) { /* TVP51510A */
+   v4l2_info(sd, "tvp5150a detected.\n");
+   } else if (dev_id == 0x5150 && rom_ver == 0x0400) { /* TVP5150AM1 */
+   v4l2_info(sd, "tvp5150am1 detected.\n");
+
+   /* ITU-T BT.656.4 timing */
+   tvp5150_write(sd, TVP5150_REV_SELECT, 0);
+   } else {
+   v4l2_info(sd, "*** unknown tvp%04x chip detected.\n", dev_id);
+   }
+
+   return 0;
+}
+
 static int tvp5150_probe(struct i2c_client *c,
 const struct i2c_device_id *id)
 {
struct tvp5150 *core;
struct v4l2_subdev *sd;
-   int tvp5150_id[4];
-   int i, res;
+   int res;
 
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(c->adapter,
@@ -1124,38 +1164,9 @@ static int tvp5150_probe(struct i2c_client *c,
sd = >sd;
v4l2_i2c_subdev_init(sd, c, _ops);
 
-   /* 
-* Read consequent registers - TVP5150_MSB_DEV_ID, TVP5150_LSB_DEV_ID,
-* TVP5150_ROM_MAJOR_VER, TVP5150_ROM_MINOR_VER 
-*/
-   for (i = 0; i < 4; i++) {
-   res = tvp5150_read(sd, TVP5150_MSB_DEV_ID + i);
-   if (res < 0)
-   return res;
-   tvp5150_id[i] = res;
-   }
-
-   v4l_info(c, "chip found @ 0x%02x (%s)\n",
-c->addr << 1, c->adapter->name);
-
-   if (tvp5150_id[2] == 4 && tvp5150_id[3] == 0) { /* Is TVP5150AM1 */
-   v4l2_info(sd, "tvp%02x%02xam1 detected.\n",
- tvp5150_id[0], tvp5150_id[1]);
-
-   /* ITU-T BT.656.4 timing */
-   tvp5150_write(sd, TVP5150_REV_SELECT, 0);
-   } else {
-   /* Is TVP5150A */
-   if (tvp5150_id[2] == 3 || tvp5150_id[3] == 0x21) {
-   v4l2_info(sd, "tvp%02x%02xa detected.\n",
- tvp5150_id[0], tvp5150_id[1]);
-   } else {
-   v4l2_info(sd, "*** unknown tvp%02x%02x chip 
detected.\n",
- tvp5150_id[0], tvp5150_id[1]);
-   v4l2_info(sd, "*** Rom ver is %d.%d\n",
- tvp5150_id[2], tvp5150_id[3]);
-   }
-   }
+   res = tvp5150_detect_version(core);
+   if (res < 0)
+   return res;
 
core->norm = V4L2_STD_ALL;  /* Default is autodetect */
core->input = TVP5150_COMPOSITE1;
-- 
2.4.3

--
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 03/10] [media] tvp5150: Add pad-level subdev operations

[Javier Martinez Canillas]

From: Laurent Pinchart 

This patch enables the tvp5150 decoder driver to be used with the media
controller framework by adding pad-level subdev operations and init the
media entity pad.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Javier Martinez Canillas 
---

Changes in v2: None

 drivers/media/i2c/tvp5150.c | 60 +
 1 file changed, 45 insertions(+), 15 deletions(-)

diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index b3b34e24db13..82fba9d46f30 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -35,6 +35,7 @@ MODULE_PARM_DESC(debug, "Debug level (0-2)");
 
 struct tvp5150 {
struct v4l2_subdev sd;
+   struct media_pad pad;
struct v4l2_ctrl_handler hdl;
struct v4l2_rect rect;
 
@@ -818,17 +819,6 @@ static v4l2_std_id tvp5150_read_std(struct v4l2_subdev *sd)
}
 }
 
-static int tvp5150_enum_mbus_code(struct v4l2_subdev *sd,
-   struct v4l2_subdev_pad_config *cfg,
-   struct v4l2_subdev_mbus_code_enum *code)
-{
-   if (code->pad || code->index)
-   return -EINVAL;
-
-   code->code = MEDIA_BUS_FMT_UYVY8_2X8;
-   return 0;
-}
-
 static int tvp5150_fill_fmt(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_format *format)
@@ -841,13 +831,11 @@ static int tvp5150_fill_fmt(struct v4l2_subdev *sd,
 
f = >format;
 
-   tvp5150_reset(sd, 0);
-
f->width = decoder->rect.width;
-   f->height = decoder->rect.height;
+   f->height = decoder->rect.height / 2;
 
f->code = MEDIA_BUS_FMT_UYVY8_2X8;
-   f->field = V4L2_FIELD_SEQ_TB;
+   f->field = V4L2_FIELD_ALTERNATE;
f->colorspace = V4L2_COLORSPACE_SMPTE170M;
 
v4l2_dbg(1, debug, sd, "width = %d, height = %d\n", f->width,
@@ -948,6 +936,39 @@ static int tvp5150_cropcap(struct v4l2_subdev *sd, struct 
v4l2_cropcap *a)
return 0;
 }
 
+ /
+   V4L2 subdev pad ops
+ /
+
+static int tvp5150_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+   if (code->index)
+   return -EINVAL;
+
+   code->code = MEDIA_BUS_FMT_UYVY8_2X8;
+   return 0;
+}
+
+static int tvp5150_enum_frame_size(struct v4l2_subdev *sd,
+  struct v4l2_subdev_pad_config *cfg,
+  struct v4l2_subdev_frame_size_enum *fse)
+{
+   struct tvp5150 *decoder = to_tvp5150(sd);
+
+   if (fse->index >= 8 || fse->code != MEDIA_BUS_FMT_UYVY8_2X8)
+   return -EINVAL;
+
+   fse->code = MEDIA_BUS_FMT_UYVY8_2X8;
+   fse->min_width = decoder->rect.width;
+   fse->max_width = decoder->rect.width;
+   fse->min_height = decoder->rect.height / 2;
+   fse->max_height = decoder->rect.height / 2;
+
+   return 0;
+}
+
 /
I2C Command
  /
@@ -1088,6 +1109,7 @@ static const struct v4l2_subdev_vbi_ops tvp5150_vbi_ops = 
{
 
 static const struct v4l2_subdev_pad_ops tvp5150_pad_ops = {
.enum_mbus_code = tvp5150_enum_mbus_code,
+   .enum_frame_size = tvp5150_enum_frame_size,
.set_fmt = tvp5150_fill_fmt,
.get_fmt = tvp5150_fill_fmt,
 };
@@ -1165,6 +1187,14 @@ static int tvp5150_probe(struct i2c_client *c,
return -ENOMEM;
sd = >sd;
v4l2_i2c_subdev_init(sd, c, _ops);
+   sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+
+#if defined(CONFIG_MEDIA_CONTROLLER)
+   core->pad.flags = MEDIA_PAD_FL_SOURCE;
+   res = media_entity_pads_init(>entity, 1, >pad);
+   if (res < 0)
+   return res;
+#endif
 
res = tvp5150_detect_version(core);
if (res < 0)
-- 
2.4.3

--
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: [GIT PULL 6/9] ARM: EXYNOS: clk: Another clock dependency, ARMv7, for v4.5

[Olof Johansson]

On Wed, Dec 23, 2015 at 07:55:11PM +0900, Krzysztof Kozlowski wrote:
> W dniu 22.12.2015 o 13:51, Olof Johansson pisze:
> > On Wed, Dec 02, 2015 at 10:39:43AM +0900, Krzysztof Kozlowski wrote:
> >> Hi Kukjin,
> >>
> >> This is also clock dependency. I put it in separate tag in case clock
> >> folks want to pull it also.
> >>
> >> Best regards,
> >> Krzysztof
> >>
> >>
> >> The following changes since commit 
> >> 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> >>
> >>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> >>
> >> are available in the git repository at:
> >>
> >>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> >> tags/samsung-clk-exynos4-4.5
> >>
> >> for you to fetch changes up to 94af7a3c310f5877dc6f756179b92f24f89a9b08:
> >>
> >>   clk: samsung: exynos4: Add SSS gate clock (2015-11-18 22:02:02 +0900)
> > 
> > Again, this should probably go through the clk maintainer (or have an ack).
> > It's just two one-line changes though, so if they're slow to respond we can
> > take it as a fallback. Resend if that's the case.
> > 
> 
> Wait, I am missing something. This contains only one patch which has the
> Stephen's Boyd ack:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/379230.html
> (this is in commit message already)
> 
> What kind of ack do you expect here? Ack for pull-request?

Yeah, looks good. I likely mixed up branch contents when I replied to this one.

I'll merge it into drivers. Still, for patches that only touches clock
subsystem, the default of merging through those subsystem maintainers is
preferred. Complications, of course, are when there's dependencies.


-Olof
--
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] clk: rockchip: rk3036: add HCLK_MAC id for emac

[Xing Zheng]

We need to add HCLK_MAC id explicitly because that it is referred
by hclk in the emac driver.

Signed-off-by: Xing Zheng 
---

 drivers/clk/rockchip/clk-rk3036.c  |2 +-
 include/dt-bindings/clock/rk3036-cru.h |1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3036.c 
b/drivers/clk/rockchip/clk-rk3036.c
index bc7fbac..15cd29a 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -404,7 +404,7 @@ static struct rockchip_clk_branch rk3036_clk_branches[] 
__initdata = {
GATE(HCLK_OTG1, "hclk_otg1", "hclk_peri", CLK_IGNORE_UNUSED, 
RK2928_CLKGATE_CON(7), 3, GFLAGS),
GATE(HCLK_I2S, "hclk_i2s", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 2, 
GFLAGS),
GATE(0, "hclk_sfc", "hclk_peri", CLK_IGNORE_UNUSED, 
RK2928_CLKGATE_CON(3), 14, GFLAGS),
-   GATE(0, "hclk_mac", "hclk_peri", CLK_IGNORE_UNUSED, 
RK2928_CLKGATE_CON(3), 15, GFLAGS),
+   GATE(HCLK_MAC, "hclk_mac", "hclk_peri", CLK_IGNORE_UNUSED, 
RK2928_CLKGATE_CON(3), 15, GFLAGS),
 
/* pclk_peri gates */
GATE(0, "pclk_peri_matrix", "pclk_peri", CLK_IGNORE_UNUSED, 
RK2928_CLKGATE_CON(4), 1, GFLAGS),
diff --git a/include/dt-bindings/clock/rk3036-cru.h 
b/include/dt-bindings/clock/rk3036-cru.h
index ebc7a7b..3396591 100644
--- a/include/dt-bindings/clock/rk3036-cru.h
+++ b/include/dt-bindings/clock/rk3036-cru.h
@@ -92,6 +92,7 @@
 #define HCLK_SDMMC 456
 #define HCLK_SDIO  457
 #define HCLK_EMMC  459
+#define HCLK_MAC   460
 #define HCLK_I2S   462
 #define HCLK_LCDC  465
 #define HCLK_ROM   467
-- 
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

[PATCH v2 00/10] [media] tvp5150: add MC and DT support

[Javier Martinez Canillas]

Hello,

One of my testing platforms for the MC next gen [0] work has been an OMAP3
board (IGEPv2) with a tvp5151 video decoder attached to the OMAP3ISP block.

I've been using some patches from Laurent Pinchart that adds MC support to
the tvp5150 driver. The patches were never posted to the list and it seems
he doesn't have time to continue working on this so I have taken them from
his personal tree [1] and submitting now for review.

The series also contains patches that adds DT support to the driver so it
can be used in DT based platforms.

This is the second version of the series that fixes issues addressed by
Rob Herring and Laurent Pinchart. The first patch-set version was [2].

To test, the following media pipeline was used:

$ media-ctl -r -l '"tvp5150 1-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP 
CCDC":1->"OMAP3 ISP CCDC output":0[1]'
$ media-ctl -v --set-format '"OMAP3 ISP CCDC":0 [UYVY2X8 720x240 
field:alternate]'
$ media-ctl -v --set-format '"OMAP3 ISP CCDC":1 [UYVY2X8 720x240 
field:interlaced-tb]'

And frames captured with the yavta tool:

$ yavta -f UYVY -s 720x480 -n 1 --field interlaced-tb --capture=1 -F /dev/video2
$ raw2rgbpnm -f UYVY -s 720x480 frame-00.bin frame-00.pnm

The patches are on top of [0] not because is a depedency but just to avoid
merge conflicts and I don't expect them to be picked before that anyways.

Best regards,
Javier

[0]: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/367109.html
[1]: http://git.linuxtv.org/pinchartl/media.git/log/?h=omap3isp/tvp5151
[2]: https://lkml.org/lkml/2016/1/4/216

Changes in v2:
- Fix indentation of the DTS example. Suggested by Rob Herring.
- Rename powerdown-gpios to pdn-gpios to match the pin name in
  the datasheet. Suggested by Laurent Pinchart.
- Add optional properties for the video endpoint and list the supported
  values. Suggested by Laurent Pinchart.
- Add Reviewed-by tag from Laurent Pinchart to patch 8/10.
- Include missing linux/gpio/consumer.h header. Reported by kbuild test robot.
- Keep the headers sorted alphabetically. Suggested by Laurent Pinchart.
- Rename powerdown to pdn to match datasheet pin. Suggested by Laurent Pinchart.
- Embed mbus_type into struct tvp5150. Suggested by Laurent Pinchart.
- Remove platform data support. Suggested by Laurent Pinchart.
- Check if the hsync, vsync and field even active properties are correct.
  Suggested by Laurent Pinchart.

Eduard Gavin (1):
  [media] tvp5150: Add OF match table

Javier Martinez Canillas (3):
  [media] tvp5150: Add device tree binding document
  [media] tvp5150: Initialize the chip on probe
  [media] tvp5150: Configure data interface via DT

Laurent Pinchart (6):
  [media] tvp5150: Restructure version detection
  [media] tvp5150: Add tvp5151 support
  [media] tvp5150: Add pad-level subdev operations
  [media] tvp5150: Add pixel rate control support
  [media] tvp5150: Add s_stream subdev operation support
  [media] tvp5150: Add g_mbus_config subdev operation support

 .../devicetree/bindings/media/i2c/tvp5150.txt  |  45 
 drivers/media/i2c/tvp5150.c| 269 +
 2 files changed, 268 insertions(+), 46 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp5150.txt

-- 
2.4.3

--
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] ARM64: tegra: Add support for Google Pixel C

[Arnd Bergmann]

On Thursday 07 January 2016 13:19:44 Jon Hunter wrote:
> 
> Adding Arnd.
> 
> Hmmm ... well apparently stdout-path does not work for tegra and in
> order to make this work I had to do the following ...
> 
> 
> [PATCH] serial: 8250: of: Add earlycon support for Tegra
> 
> Currently, early console support only works for Tegra when the serial
> port information is passed via the earlycon boot parameter. If the
> serial port information is specified via device-tree using the
> "stdout-path" then the early console does not work because:
> 
> 1. The tegra serial ports compatibility parameter does not match any
>of the supported serial drivers for early console.
> 2. The of_setup_earlycon() function assumes that serial port registers
>are byte aligned and for tegra they are 32-bit aligned.
> 
> Add an early console setup function for tegra so that the early console
> can be specified via the device-tree "stdout-path" variable.
> 
> Signed-off-by: Jon Hunter 
> ---
>  drivers/tty/serial/8250/8250_of.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/tty/serial/8250/8250_of.c 
> b/drivers/tty/serial/8250/8250_of.c
> index 33021c1f7d55..98adf83e83c2 100644
> --- a/drivers/tty/serial/8250/8250_of.c
> +++ b/drivers/tty/serial/8250/8250_of.c
> @@ -44,6 +44,16 @@ void tegra_serial_handle_break(struct uart_port *p)
> udelay(1);
> } while (1);
>  }
> +
> +int __init tegra_earlycon_setup(struct earlycon_device *device,
> +   const char *options)
> +{
> +   device->port.iotype = UPIO_MEM32;
> +   device->port.regshift = 2;
> +
> +   return early_serial8250_setup(device, options);
> +}
> +OF_EARLYCON_DECLARE(tegra20_uart, "nvidia,tegra20-uart", 
> tegra_earlycon_setup);
>  #else
>  static inline void tegra_serial_handle_break(struct uart_port *port)
>  {
> 
> 
> Arnd, does the above look ok, or should there be a generic
> early_serial8250x32_setup() somewhere?

I think it would be better to put it into 8250_early.c rather than 
8250_of.c, as there are already some other definitions in there,
and the #ifdef CONFIG_TEGRA in 8250_of.c is for some other workaround.

Would it be possible to handle the "reg-io-width" parsing in
early_serial8250_setup instead of keying it off the string?

Arnd
--
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/6] Add support for MAXIM MAX77620/MAX20024 PMIC

[Laxman Dewangan]

Add SW support for MAXIM Semiconductor's Power Management
IC (PMIC) MAX77620/MAX20024. This PMIC supports DC-DC/LDOS, GPIOs,
RTC, watchdog, clocks etc.

This series add respective driver for each of sub-modules.

Laxman Dewangan (6):
  DT: mfd: add device-tree binding doc fro PMIC max77620/max20024
  mfd: max77620: add core driver for MAX77620/MAX20024
  pinctrl: max77620: add pincontrol driver for MAX77620/MAX20024
  gpio: max77620: add gpio driver for MAX77620/MAX20024
  rtc: max77620: add support for max77620/max20024 RTC driver
  regulator: max77620: add regulator driver for max77620/max20024

 Documentation/devicetree/bindings/mfd/max77620.txt |  383 +++
 drivers/gpio/Kconfig   |9 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-max77620.c   |  330 ++
 drivers/mfd/Kconfig|   15 +
 drivers/mfd/Makefile   |1 +
 drivers/mfd/max77620.c |  926 +
 drivers/pinctrl/Kconfig|   10 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-max77620.c |  700 +
 drivers/regulator/Kconfig  |9 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/max77620-regulator.c | 1062 
 drivers/rtc/Kconfig|9 +
 drivers/rtc/Makefile   |1 +
 drivers/rtc/rtc-max77620.c |  574 +++
 include/dt-bindings/mfd/max77620.h |   38 +
 include/linux/mfd/max77620.h   |  503 +
 18 files changed, 4573 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/max77620.txt
 create mode 100644 drivers/gpio/gpio-max77620.c
 create mode 100644 drivers/mfd/max77620.c
 create mode 100644 drivers/pinctrl/pinctrl-max77620.c
 create mode 100644 drivers/regulator/max77620-regulator.c
 create mode 100644 drivers/rtc/rtc-max77620.c
 create mode 100644 include/dt-bindings/mfd/max77620.h
 create mode 100644 include/linux/mfd/max77620.h

-- 
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 v3 1/3] spi: atmel: add support for the internal chip-select of the spi controller

[Måns Rullgård]

Mark Brown  writes:

> On Tue, Jan 05, 2016 at 09:50:54PM +, Måns Rullgård wrote:
>> Cyrille Pitchen  writes:
>
>> > +  as->use_cs_gpios = true;
>> > +  if (atmel_spi_is_v2(as) &&
>> > +  !of_get_property(pdev->dev.of_node, "cs-gpios", NULL)) {
>> > +  as->use_cs_gpios = false;
>> > +  master->num_chipselect = 4;
>> > +  }
>
>> This part breaks the AVR32 boards and probably anything else that
>> doesn't use devicetree but does use GPIOs for chip select.
>
> Shouldn't this just be setting defaults for the case where nothing is
> provided?

Traditionally the platform data included a GPIO number to use and that
was that.  At some point DT support was added wherein the platform data
is overridden by cs_gpio from struct spi_device if this is valid (it is
set to a negative value by default).  Thus far all was well.  Then came
this patch.  It assumes that everybody uses DT and treats a missing
cs-gpios property as indication that the controller's own pins should be
used.  It also assumes that if any device uses GPIO for CS all of them
do, even though the SPI core driver might provide a partial list
(probably since many boards don't use all the available chip selects,
but it doesn't prevent someone abusing this).

To work correctly in call cases, this driver should use, for each
peripheral, the following priority:

- spi->cs_gpio (filled from DT or -ENOENT)
- GPIO from platform data
- controller chip select pin

The trouble is that there is no way to reliably tell a valid GPIO number
of zero in the platform data from an unset value.  In practice, I
believe existing old boards using this driver all use a non-zero GPIO
(the AVR32 platform code requires this), so checking for a non-zero
number is probably sufficient.  I'll cook up a patch for this unless
someone objects.

-- 
Måns Rullgård
--
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 v2 3/4] drm: rockchip: hdmi: add RK3229 HDMI support

[Philipp Zabel]

Hi Yakir,

Am Donnerstag, den 07.01.2016, 18:15 +0800 schrieb Yakir Yang:
> Hi Philipp,
> 
> Thanks for your fast respond :)
> 
> On 01/07/2016 06:04 PM, Philipp Zabel wrote:
> > Am Donnerstag, den 07.01.2016, 17:02 +0800 schrieb Yakir Yang:
> >> RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 
> >> phy,
> >> the max output resolution is 4K.
> >>
> >> Signed-off-by: Yakir Yang 
> > It sounds like the INNO HDMI2.0 phy is not necessarily specific to
> > RK3229 but might also appear in other SoCs? If so, I think this should
> > be implemented in a separate phy driver and be used by dw_hdmi-rockchip.
> 
> Do you mean I should create a new phy driver that place in "driver/phy" 
> directly ?

Possibly, yes. The exynos video phys are already there. I have kept the
mediatek dsi/hdmi phys together with the DRM driver, but I suppose I
could move them there, too.

> I have think about this idea, and it would make things much clean. But 
> INNO PHY
> driver need the target pixel clock in drm_display_mode, I didn't find a 
> good way
> to pass this variable to separate phy driver. Do you have some idea ?

We'd need to extend the PHY API for this. For the mediatek phys we have
side-stepped the issue by wiring up the PLL output to the common clock
framework.
I expect besides the pixel clock frequency, it might also be necessary
to inform the PHY about cycles per pixel for deep color modes.

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] ARM64: tegra: Add support for Google Pixel C

[Rob Herring]

On Thu, Jan 7, 2016 at 10:53 AM, Jon Hunter  wrote:
>
> On 07/01/16 14:11, Arnd Bergmann wrote:
>> On Thursday 07 January 2016 13:19:44 Jon Hunter wrote:

[...]

> Ok so something like this ...
>
> diff --git a/drivers/tty/serial/8250/8250_early.c
> b/drivers/tty/serial/8250/8250_early.c
> index af62131af21e..4ce6e2b57534 100644
> --- a/drivers/tty/serial/8250/8250_early.c
> +++ b/drivers/tty/serial/8250/8250_early.c
> @@ -141,7 +141,18 @@ int __init early_serial8250_setup(struct
> earlycon_device *device,
> device->con->write = early_serial8250_write;
> return 0;
>  }
> +
> +int __init early_serial8250_mem32_setup(struct earlycon_device *device,
> +   const char *options)
> +{
> +   device->port.iotype = UPIO_MEM32;
> +   device->port.regshift = 2;
> +
> +   return early_serial8250_setup(device, options);
> +}
>  EARLYCON_DECLARE(uart8250, early_serial8250_setup);
>  EARLYCON_DECLARE(uart, early_serial8250_setup);
>  OF_EARLYCON_DECLARE(ns16550, "ns16550", early_serial8250_setup);
>  OF_EARLYCON_DECLARE(ns16550a, "ns16550a", early_serial8250_setup);
> +OF_EARLYCON_DECLARE(tegra20_uart, "nvidia,tegra20-uart",
> +   early_serial8250_mem32_setup);
>
>> Would it be possible to handle the "reg-io-width" parsing in
>> early_serial8250_setup instead of keying it off the string?
>
> Good point. I spent a bit of time looking at this, but I cannot see an
> easy way to do this unless we check for "reg-io-width" and "reg-shift"
> in early_init_dt_scan_chosen_serial() and pass to of_setup_earlycon(),
> however, I am guessing that this would not be ideal as this would happen
> for non-8250 devices. May be that would be ok, but I am not sure.

There's been one attempt[1] already. It had a few issues easily
solved, but I haven't seen a follow-up.

Rob

[1] https://lkml.org/lkml/2015/11/30/513
--
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] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag

[Thomas Gleixner]

On Wed, 6 Jan 2016, Vinod Koul wrote:
> On Wed, Jan 06, 2016 at 02:51:07PM +0530, Rameshwar Sahu wrote:
> > >> @@ -1610,6 +1611,7 @@ static int xgene_dma_request_irqs(struct xgene_dma 
> > >> *pdma)
> > >>   /* Register DMA channel rx irq */
> > >>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
> > >>   chan = >chan[i];
> > >> + irq_set_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);
> > >
> > > Why not use irq_settings_disable_unlazy(), at least read the reference you
> > > pointed out!
> > 
> > irq_settings_disable_unlazy() is helper function to test
> > IRQ_DISABLE_UNLAZY flag is set or not, it's not for setting this flag.
> > FYI...
> > +static inline bool irq_settings_disable_unlazy(struct irq_desc *desc)
> > +{
> > + return desc->status_use_accessors & _IRQ_DISABLE_UNLAZY;
> > +}
> 
> Ah yes, I saw clear API and assumed there would be set. Then I think we
> should add a set helper as well as the usage is intended for drivers to
> set this flag
> 
> Thomas,
> 
> Any reason why you didn't add a set helper, only test and clear?

Why would I? Those helpers are core internal and not usable in random drivers.

Drivers have irq_set_status_flags()/irq_clear_status_flags() ...

Thanks,

tglx
--
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] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag

[Vinod Koul]

On Wed, Jan 06, 2016 at 02:51:07PM +0530, Rameshwar Sahu wrote:
> Hi Vinod,
> 
> On Wed, Jan 6, 2016 at 2:43 PM, Vinod Koul  wrote:
> > On Wed, Dec 23, 2015 at 06:28:15PM +0530, Rameshswar Prasad Sahu wrote:
> >> From: Rameshwar Prasad Sahu 
> >>
> >> For interrupt controller that doesn't support irq_disable and hardware
> >> with level interrupt, an extra interrupt can be pending. This patch fixes
> >> the issue by setting IRQ_DISABLE_UNLAZY flag for the interrupt line.
> >>
> >> Reference: 
> >> http://git.kernel.org/tip/e9849777d0e27cdd2902805be51da73e7c79578c
> >
> > I seem to have got this patch thrice :(
> Due to mail failure (some issue was in my email client) to some
> email-id it was multiple times,

git send-email ?

> >
> >>
> >> Signed-off-by: Rameshwar Prasad Sahu 
> >> ---
> >>  drivers/dma/xgene-dma.c |4 
> >>  1 files changed, 4 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> >> index 9dfa2b0..6363e84 100644
> >> --- a/drivers/dma/xgene-dma.c
> >> +++ b/drivers/dma/xgene-dma.c
> >> @@ -29,6 +29,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>
> >> @@ -1610,6 +1611,7 @@ static int xgene_dma_request_irqs(struct xgene_dma 
> >> *pdma)
> >>   /* Register DMA channel rx irq */
> >>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
> >>   chan = >chan[i];
> >> + irq_set_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);
> >
> > Why not use irq_settings_disable_unlazy(), at least read the reference you
> > pointed out!
> 
> irq_settings_disable_unlazy() is helper function to test
> IRQ_DISABLE_UNLAZY flag is set or not, it's not for setting this flag.
> FYI...
> +static inline bool irq_settings_disable_unlazy(struct irq_desc *desc)
> +{
> + return desc->status_use_accessors & _IRQ_DISABLE_UNLAZY;
> +}

Ah yes, I saw clear API and assumed there would be set. Then I think we
should add a set helper as well as the usage is intended for drivers to
set this flag

Thomas,

Any reason why you didn't add a set helper, only test and clear?

-- 
~Vinod
--
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/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM

[Marcel Ziswiler]

Hi Petr

On Wed, 2016-01-06 at 09:03 +0100, Petr Štetiar wrote:
> Marcel Ziswiler  [2016-01-05 17:39:01]:
> 
> Hi Marcel,
> 
> thanks for taking care of this, I'm quite busy with other tasks :(

You're welcome. I know that feeling.

> > - integrated review feedback from Lucas
> 
> You've probably missed few of them :) See my nitpicks bellow.

I don't think so but we don't necessarily agree with all of Lucas'
findings plus the discussion about some of the stuff hasn't really
concluded.

> > - left and even added some more comments as I don't see why putting
> > any
> >   explanatory comments in dts' should be such a bad thing to do

> You've marked this as v2

Well, as Stefan pointed out we at Toradex are/were working on this as
well and we discussed whether we should just ignore whatever you have
done or not done and post our own stuff but decided to rather join
efforts now as you already jumped ahead.

>  so I think, that you should only work on the
> feedback. Ideally you shouldn't add any new stuff if it wasn't
> requested
> otherwise you're wasting reviewer time.

I don't think so. What is important is that any changes are clearly
declared which we did.

> > - completely got rid of the memory node as that is something
> > typically filled
> >   in by the boot loader e.g. U-Boot
> 
> If I'm not mistaken, it wasn't requested by the reviewer.

Lucas was actually nitpicking about the location thereof and rather
than moving it we decided to just get rid of it as it does not only not
add any value but is simply wrong on most of the modules featuring
different amount of memory.

> > - without the regulators simple-bus it no longer boots
> 
> It works for me on 4.4.0-rc3 with following DTS[1]. BTW, this DTS is
> my
> preparation for v2 patch series.

I only tried with -next stuff so it might be something is just broken
there I guess.

> > - fixed Ethernet PHY reset & interrupt (requires Micrel PHY driver
> > to be
> >   enabled)
> 
> Great!

Yeah, that one took us a day to figure it all out. At the end we
actually stumbled over your PCIe reset patch inverting the meaning of
active-low vs. active-high (;-p).

> > + * This file is dual-licensed: you can use it either under the
> > terms
> > + * of the GPL or the X11 license, at your option. Note that this
> > dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> 
> Hope you've some kind of ACK from FSL and Linaro :)

Well, all new DTS' are now dual-licensed including several i.MX 6
related ones so we are not doing anything special there really.

> > +   reg_usb_otg_vbus: usb_otg_vbus {
> > +   compatible = "regulator-fixed";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 =
> > <_regulator_usbotg_pwr>;
> > +   regulator-name = "usb_otg_vbus";
> > +   regulator-min-microvolt = <500>;
> > +   regulator-max-microvolt = <500>;
> > +   gpio = < 22 GPIO_ACTIVE_HIGH>;
> > +   enable-active-high;
> > +   status = "disabled";
> > +   };
> 
> I'm not sure, but it seems to me, that we should move this regulator
> into the
> carrier board DTS. On our custom carrier board we've this regulator
> always on
> and we use this GPIO for heartbeat LED, so I've this in our carrier
> board
> DTS[2]:

Yes, you are absolutely right and e.g. on Apalis T30 [1] that is
exactly how we did it.

>   reg_usb_otg_vbus: usb_otg_vbus {
>   /* Regulator is always on, and we use GPIO for
> heartbeat LED */
>   pinctrl-0 = <>;
>   gpio = <>;
> 
>   compatible = "regulator-fixed";
>   regulator-name = "usb_otg_vbus";
>   regulator-min-microvolt = <500>;
>   regulator-max-microvolt = <500>;
>   regulator-always-on;
>   };
> 
>   ...
> 
>   usbotg {
>   /* GPIO3_IO22 is Heartbeat LED */
>   pinctrl_regulator_usbotg_pwr: gpio_regulator_usbotg_pwr
> {
>   };
>   };
> 
> > +/* PAD Ctrl values for common settings */
> > +/*
> > + * (PAD_CTL_HYS | PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | PAD_CTL_PKE
> > |
> > + *  PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm)
> > + */
> > +#define PAD_CTRL_HYS_PU 0x1b0b0
> 
> This was requested to be reworked. I've simply replaced all the
> macros with
> hex values.

I don't think the reviewers really concluded on the action to be taken
on here and just using hex values is probably the most stupid solution.

> > +   pinctrl_usdhc3_100mhz: usdhc3grp-100mhz { /*
> > 100Mhz */
> > +   fsl,pins = <
> > +   MX6QDL_PAD_SD3_CMD__SD3_CMD
> > 0x170B9
> 
> As per review comments, all hex values should be lowercase.

Yes, we probably missed that one.

> 1. https://github.com/ynezz/linux-2.6/blob/b27de46e67605fe1a8e386b065
> 

[PATCH 0/2] DRA72/DRA74: Add 2 lane support

[Kishon Vijay Abraham I]

Add driver modifications in pci-dra7xx to get x2 mode working in
DRA72 and DRA74. Certain modifications is needed in PHY driver also
which will be sent as a separate series.

Certain board modifications has to be done in order to test
x2 mode in dra72-evm.

These patches were created on pci next.

Changes from RFC:
*) .b1co_mode_sel_mask is now set with the correct value.
*) cleanup the patch

Kishon Vijay Abraham I (2):
  pci: host: pci-dra7xx: use "num-lanes" property to find phy count
  pci: host: pci-dra7xx: Enable x2 mode support

 Documentation/devicetree/bindings/pci/ti-pci.txt |8 +-
 drivers/pci/host/pci-dra7xx.c|  104 +++---
 2 files changed, 97 insertions(+), 15 deletions(-)

-- 
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

[PATCH 0/2] dra72: add support for PCIE 2 lane mode

[Kishon Vijay Abraham I]

dra72 reuse the USB PHY for the PCIe 2n lane. So in order for PCIe x2 mode
to work in dra72, certain special configuration has to be made in
USB PHY. This patch series adds those configurations.

In order to enable PCIe x2 mode in DRA72, USB should be disabled.

Certain board modifications has to be done in order to test
x2 mode in dra72-evm.

Patch series is rebased on top of linux-phy next

Kishon Vijay Abraham I (2):
  phy: ti-pipe3: get tx and rx MEM resource
  phy: ti-pipe3: configure usb3 phy to be used as pcie phy

 Documentation/devicetree/bindings/phy/ti-phy.txt |2 +
 drivers/phy/phy-ti-pipe3.c   |   57 +-
 2 files changed, 58 insertions(+), 1 deletion(-)

-- 
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 09/10] [media] tvp5150: Initialize the chip on probe

[Laurent Pinchart]

Hi Javier,

Thankk you for the patch.

On Monday 04 January 2016 09:25:31 Javier Martinez Canillas wrote:
> After power-up, the tvp5150 decoder is in a unknown state until the
> RESETB pin is driven LOW which reset all the registers and restarts
> the chip's internal state machine.
> 
> The init sequence has some timing constraints and the RESETB signal
> can only be used if the PDN (Power-down) pin is first released.
> 
> So, the initialization sequence is as follows:
> 
> 1- PDN (active-low) is driven HIGH so the chip is power-up
> 2- A 20 ms delay is needed before sending a RESETB (active-low) signal.
> 3- The RESETB pulse duration is 500 ns.
> 4- A 200 us delay is needed for the I2C client to be active after reset.
> 
> This patch used as a reference the logic in the IGEPv2 board file from
> the ISEE 2.6.37 vendor tree.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
>  drivers/media/i2c/tvp5150.c | 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index caac96a577f8..fed89a811ab7 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -5,6 +5,7 @@
>   * This code is placed under the terms of the GNU General Public License v2
> */
> 
> +#include 

Let's keep the headers sorted alphabetically if you don't mind :-)

>  #include 
>  #include 
>  #include 
> @@ -1197,6 +1198,36 @@ static int tvp5150_detect_version(struct tvp5150
> *core) return 0;
>  }
> 
> +static inline int tvp5150_init(struct i2c_client *c)
> +{
> + struct gpio_desc *pdn_gpio;
> + struct gpio_desc *reset_gpio;
> +
> + pdn_gpio = devm_gpiod_get_optional(>dev, "powerdown", 
> GPIOD_OUT_HIGH);
> + if (IS_ERR(pdn_gpio))
> + return PTR_ERR(pdn_gpio);
> +
> + if (pdn_gpio) {
> + gpiod_set_value_cansleep(pdn_gpio, 0);
> + /* Delay time between power supplies active and reset */
> + msleep(20);

How about usleep_range() instead ?

> + }
> +
> + reset_gpio = devm_gpiod_get_optional(>dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(reset_gpio))
> + return PTR_ERR(reset_gpio);
> +
> + if (reset_gpio) {
> + /* RESETB pulse duration */
> + ndelay(500);

Is the timing so sensitive that we need a delay, or could we use 
usleep_range() ?

> + gpiod_set_value_cansleep(reset_gpio, 0);
> + /* Delay time between end of reset to I2C active */
> + usleep_range(200, 250);
> + }
> +
> + return 0;
> +}
> +
>  static int tvp5150_probe(struct i2c_client *c,
>const struct i2c_device_id *id)
>  {
> @@ -1209,6 +1240,10 @@ static int tvp5150_probe(struct i2c_client *c,
>I2C_FUNC_SMBUS_READ_BYTE | I2C_FUNC_SMBUS_WRITE_BYTE_DATA))
>   return -EIO;
> 
> + res = tvp5150_init(c);
> + if (res)
> + return res;
> +
>   core = devm_kzalloc(>dev, sizeof(*core), GFP_KERNEL);
>   if (!core)
>   return -ENOMEM;

-- 
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 09/10] [media] tvp5150: Initialize the chip on probe

[Javier Martinez Canillas]

Hello Laurent,

On 01/06/2016 07:59 AM, Laurent Pinchart wrote:
> Hi Javier,
> 
> Thankk you for the patch.
>

Thanks a lot for your feedback.
 
> On Monday 04 January 2016 09:25:31 Javier Martinez Canillas wrote:
>> After power-up, the tvp5150 decoder is in a unknown state until the
>> RESETB pin is driven LOW which reset all the registers and restarts
>> the chip's internal state machine.
>>
>> The init sequence has some timing constraints and the RESETB signal
>> can only be used if the PDN (Power-down) pin is first released.
>>
>> So, the initialization sequence is as follows:
>>
>> 1- PDN (active-low) is driven HIGH so the chip is power-up
>> 2- A 20 ms delay is needed before sending a RESETB (active-low) signal.
>> 3- The RESETB pulse duration is 500 ns.
>> 4- A 200 us delay is needed for the I2C client to be active after reset.
>>
>> This patch used as a reference the logic in the IGEPv2 board file from
>> the ISEE 2.6.37 vendor tree.
>>
>> Signed-off-by: Javier Martinez Canillas 
>> ---
>>
>>  drivers/media/i2c/tvp5150.c | 35 +++
>>  1 file changed, 35 insertions(+)
>>
>> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
>> index caac96a577f8..fed89a811ab7 100644
>> --- a/drivers/media/i2c/tvp5150.c
>> +++ b/drivers/media/i2c/tvp5150.c
>> @@ -5,6 +5,7 @@
>>   * This code is placed under the terms of the GNU General Public License v2
>> */
>>
>> +#include 
> 
> Let's keep the headers sorted alphabetically if you don't mind :-)
>

Right, sorry about that.
 
>>  #include 
>>  #include 
>>  #include 
>> @@ -1197,6 +1198,36 @@ static int tvp5150_detect_version(struct tvp5150
>> *core) return 0;
>>  }
>>
>> +static inline int tvp5150_init(struct i2c_client *c)
>> +{
>> +struct gpio_desc *pdn_gpio;
>> +struct gpio_desc *reset_gpio;
>> +
>> +pdn_gpio = devm_gpiod_get_optional(>dev, "powerdown", 
>> GPIOD_OUT_HIGH);
>> +if (IS_ERR(pdn_gpio))
>> +return PTR_ERR(pdn_gpio);
>> +
>> +if (pdn_gpio) {
>> +gpiod_set_value_cansleep(pdn_gpio, 0);
>> +/* Delay time between power supplies active and reset */
>> +msleep(20);
> 
> How about usleep_range() instead ?
>

Documentation/timers/timers-howto.txt says that usleep_range() should be
used for 1ms - 20ms and msleep() for 20ms+ so since this was a boundary
value, I chose for msleep() but I can use usleep_range() if you want.

I've no strong opinion on this.

>> +}
>> +
>> +reset_gpio = devm_gpiod_get_optional(>dev, "reset", GPIOD_OUT_HIGH);
>> +if (IS_ERR(reset_gpio))
>> +return PTR_ERR(reset_gpio);
>> +
>> +if (reset_gpio) {
>> +/* RESETB pulse duration */
>> +ndelay(500);
> 
> Is the timing so sensitive that we need a delay, or could we use 
> usleep_range() ?
>

According to my tests, it is a minimum value but I chose to do a delay since
the time is very short and also Documentation/timers/timers-howto.txt says
that using usleep for very short periods may not be worth it due the overhead
of setting up the hrtimers for usleep.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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/2] phy: ti-pipe3: configure usb3 phy to be used as pcie phy

[Kishon Vijay Abraham I]

DRA72 uses USB3 PHY for the 2nd lane of PCIE. The configuration
required to make USB3 PHY used for the 2nd lane of PCIe is done
here.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
 drivers/phy/phy-ti-pipe3.c   |   30 +-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index a3b3945..6a7de94 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -91,6 +91,8 @@ Optional properties:
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
  - syscon-pcs : phandle/offset pair. Phandle to the system control module and 
the
register offset to write the PCS delay value.
+ - "ti,configure-as-pcie" : property to indicate if the PHY should be
+   configured as PCIE PHY.
 
 Deprecated properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 7d83d2b..793185e 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -56,6 +56,12 @@
 
 #define SATA_PLL_SOFT_RESETBIT(18)
 
+#define PHY_RX_ANA_PRGRAMMABILITY_REG  0xC
+#define MEM_EN_PLLBYP  BIT(7)
+
+#define PHY_TX_TEST_CONFIG 0x2C
+#define MEM_ENTESTCLK  BIT(31)
+
 #define PIPE3_PHY_PWRCTL_CLK_CMD_MASK  0x003FC000
 #define PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT 14
 
@@ -68,6 +74,10 @@
 #define PCIE_PCS_MASK  0xFF
 #define PCIE_PCS_DELAY_COUNT_SHIFT 0x10
 
+#define PIPE3_PHY_DISABLE_SYNC_POWER   BIT(4)
+
+#define CONFIGURE_AS_PCIE  BIT(0)
+
 /*
  * This is an Empirical value that works, need to confirm the actual
  * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
@@ -90,6 +100,7 @@ struct pipe3_dpll_map {
 };
 
 struct ti_pipe3 {
+   u32 flags;
void __iomem*pll_ctrl_base;
void __iomem*phy_rx;
void __iomem*phy_tx;
@@ -270,6 +281,19 @@ static int ti_pipe3_init(struct phy *x)
int ret = 0;
 
ti_pipe3_enable_clocks(phy);
+
+   if (phy->flags & CONFIGURE_AS_PCIE) {
+   val = ti_pipe3_readl(phy->phy_rx,
+PHY_RX_ANA_PRGRAMMABILITY_REG);
+   val |= MEM_EN_PLLBYP;
+   ti_pipe3_writel(phy->phy_rx, PHY_RX_ANA_PRGRAMMABILITY_REG,
+   val);
+   val = ti_pipe3_readl(phy->phy_tx, PHY_TX_TEST_CONFIG);
+   val |= MEM_ENTESTCLK;
+   ti_pipe3_writel(phy->phy_tx, PHY_TX_TEST_CONFIG, val);
+   return 0;
+   }
+
/*
 * Set pcie_pcs register to 0x96 for proper functioning of phy
 * as recommended in AM572x TRM SPRUHZ6, section 18.5.2.2, table
@@ -318,7 +342,8 @@ static int ti_pipe3_exit(struct phy *x)
return 0;
 
/* PCIe doesn't have internal DPLL */
-   if (!of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie")) {
+   if (!of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie") &&
+   !(phy->flags & CONFIGURE_AS_PCIE)) {
/* Put DPLL in IDLE mode */
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
val |= PLL_IDLE;
@@ -590,6 +615,9 @@ static int ti_pipe3_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   if (of_property_read_bool(node, "ti,configure-as-pcie"))
+   phy->flags |= CONFIGURE_AS_PCIE;
+
platform_set_drvdata(pdev, phy);
pm_runtime_enable(dev);
 
-- 
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

[PATCH 1/2] phy: ti-pipe3: get tx and rx MEM resource

[Kishon Vijay Abraham I]

get tx and rx MEM resource since this has to be used to configure
for DRA72x to work in X2 mode.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/phy/phy-ti-pipe3.c |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 0a477d2..7d83d2b 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -91,6 +91,8 @@ struct pipe3_dpll_map {
 
 struct ti_pipe3 {
void __iomem*pll_ctrl_base;
+   void __iomem*phy_rx;
+   void __iomem*phy_tx;
struct device   *dev;
struct device   *control_dev;
struct clk  *wkupclk;
@@ -536,6 +538,27 @@ static int ti_pipe3_get_pll_base(struct ti_pipe3 *phy)
return 0;
 }
 
+static int ti_pipe3_get_rx_tx_base(struct ti_pipe3 *phy)
+{
+   struct resource *res;
+   struct device *dev = phy->dev;
+   struct platform_device *pdev = to_platform_device(dev);
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+  "phy_rx");
+   phy->phy_rx = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(phy->phy_rx))
+   return PTR_ERR(phy->phy_rx);
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+  "phy_tx");
+   phy->phy_tx = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(phy->phy_tx))
+   return PTR_ERR(phy->phy_tx);
+
+   return 0;
+}
+
 static int ti_pipe3_probe(struct platform_device *pdev)
 {
struct ti_pipe3 *phy;
@@ -555,6 +578,10 @@ static int ti_pipe3_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   ret = ti_pipe3_get_rx_tx_base(phy);
+   if (ret)
+   return ret;
+
ret = ti_pipe3_get_sysctrl(phy);
if (ret)
return ret;
-- 
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 07/10] [media] tvp5150: Add device tree binding document

[Laurent Pinchart]

On Wednesday 06 January 2016 07:46:35 Javier Martinez Canillas wrote:
> On 01/06/2016 07:39 AM, Laurent Pinchart wrote:
> > Hi Javier,
> > 
> > Thank you for the patch.
> 
> Thanks a lot for your feedback.
> 
> [snip]
> 
> >> +
> >> +Optional Properties:
> >> +- powerdown-gpios: phandle for the GPIO connected to the PDN pin, if
> >> any.
> > 
> > The signal is called PDN in the datasheet, so it might make sense to call
> > this pdn-gpios. I have no strong opinion on this, I'll let you decide
> > what you think is best.
> 
> Yes, I wondered if the convention was to use a descriptive name or the one
> used in the datasheet but Documentation/devicetree/bindings/gpio/gpio.txt
> says nothing about it.

The device tree maintainers might want to comment on that :-)

> I'll change it to pdn-gpios since it could be easier to match with the doc.

-- 
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 3/4] mfd: arizona: Switch to using clock driver for 32k clock

[Charles Keepax]

On Wed, Jan 06, 2016 at 12:19:56AM +0800, kbuild test robot wrote:
> Hi Charles,
> 
> [auto build test WARNING on clk/clk-next]
> [also build test WARNING on v4.4-rc8 next-20160105]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improving the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Charles-Keepax/extcon-arizona-Remove-enable-disable-of-32k-clock/20160105-234658
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
> config: x86_64-randconfig-x013-01041832 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All warnings (new ones prefixed by >>):
> 
> warning: (MFD_ARIZONA) selects COMMON_CLK_ARIZONA which has unmet direct 
> dependencies (COMMON_CLK && MFD_ARIZONA)

Apologies this is caused by the select I put in the MFD Kconfig,
since it doesn't really make much sense to build the MFD without
the clock driver.

But I think probably the simplest solution is just to drop that,
otherwise we start kicking off all sorts of exciting circular
dependencies that Kconfig doesn't like. Its not necessarily a
sensible config to use but at least it will all build fine.

I will send a version 2 with the other small comment fixed up
as well.

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

[PATCH 2/2] pci: host: pci-dra7xx: Enable x2 mode support

[Kishon Vijay Abraham I]

Perform syscon configurations to get x2 mode to working in DRA74x and
DRA72x. Also add a new compatible string to dfferentiate
DRA72x and DRA74x, since b1c0 mask is different for both these platforms.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/pci/ti-pci.txt |8 ++-
 drivers/pci/host/pci-dra7xx.c|   81 +-
 2 files changed, 86 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 60e2516..0b10e84 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -1,7 +1,9 @@
 TI PCI Controllers
 
 PCIe Designware Controller
- - compatible: Should be "ti,dra7-pcie""
+ - compatible: "ti,dra7-pcie" is deprecated
+  Should be "ti,dra746-pcie" for DRA74x
+  Should be "ti,dra726-pcie" for DRA72x
  - reg : Two register ranges as listed in the reg-names property
  - reg-names : The first entry must be "ti-conf" for the TI specific registers
   The second entry must be "rc-dbics" for the designware pcie
@@ -14,6 +16,10 @@ PCIe Designware Controller
   where  is the instance number of the pcie from the HW spec.
  - interrupts : Two interrupt entries must be specified. The first one is for
main interrupt line and the second for MSI interrupt line.
+ - syscon-lane-conf : phandle/offset pair. Phandle to the system control 
module and the
+   register offset to specify 1 lane or 2 lane.
+ - syscon-lane-sel : phandle/offset pair. Phandle to the system control module 
and the
+   register offset to specify lane selection.
  - #address-cells,
#size-cells,
#interrupt-cells,
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 05bbeee..dac216f 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -22,9 +22,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
+#include 
+#include 
 
 #include 
 
@@ -67,14 +69,22 @@
 #defineLINK_UP BIT(16)
 #defineDRA7XX_CPU_TO_BUS_ADDR  0x0FFF
 
+#define PCIE_1LANE_2LANE_SELECTION BIT(13)
+#define PCIE_B1C0_MODE_SEL BIT(2)
+
 struct dra7xx_pcie {
void __iomem*base;
+   u32 *b1c0_mask;
struct phy  **phy;
int lanes;
struct device   *dev;
struct pcie_portpp;
 };
 
+struct dra7xx_pcie_data {
+   u32 b1co_mode_sel_mask;
+};
+
 #define to_dra7xx_pcie(x)  container_of((x), struct dra7xx_pcie, pp)
 
 static inline u32 dra7xx_pcie_readl(struct dra7xx_pcie *pcie, u32 offset)
@@ -358,6 +368,57 @@ static int dra7xx_pcie_reset(struct platform_device *pdev)
return 0;
 }
 
+static const struct of_device_id of_dra7xx_pcie_match[];
+
+static int dra7xx_pcie_configure_two_lane(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct regmap *pcie_syscon;
+   unsigned int pcie_reg;
+   struct dra7xx_pcie_data *data;
+   const struct of_device_id *match;
+
+   match = of_match_device(of_dra7xx_pcie_match, dev);
+   if (!match)
+   return -EINVAL;
+
+   data = (struct dra7xx_pcie_data *)match->data;
+   if (!data) {
+   dev_err(dev, "no b1c0 mask data\n");
+   return -EINVAL;
+   }
+
+   pcie_syscon = syscon_regmap_lookup_by_phandle(np, "syscon-lane-conf");
+   if (IS_ERR(pcie_syscon)) {
+   dev_err(dev, "unable to get syscon-lane-conf\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32_index(np, "syscon-lane-conf", 1, _reg)) {
+   dev_err(dev, "couldn't get lane configuration reg offset\n");
+   return -EINVAL;
+   }
+
+   regmap_update_bits(pcie_syscon, pcie_reg, PCIE_1LANE_2LANE_SELECTION,
+  PCIE_1LANE_2LANE_SELECTION);
+
+   pcie_syscon = syscon_regmap_lookup_by_phandle(np, "syscon-lane-sel");
+   if (IS_ERR(pcie_syscon)) {
+   dev_err(dev, "unable to get syscon-lane-sel\n");
+   return -EINVAL;
+   }
+
+   if (of_property_read_u32_index(np, "syscon-lane-sel", 1, _reg)) {
+   dev_err(dev, "couldn't get lane selection reg offset\n");
+   return -EINVAL;
+   }
+
+   regmap_update_bits(pcie_syscon, pcie_reg, data->b1co_mode_sel_mask,
+  PCIE_B1C0_MODE_SEL);
+
+   return 0;
+}
+
 static int __init dra7xx_pcie_probe(struct platform_device *pdev)
 {
u32 reg;
@@ -428,6 +489,12 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
}
}
 
+   if (lanes == 2) {
+   ret = 

[PATCH 1/2] pci: host: pci-dra7xx: use "num-lanes" property to find phy count

[Kishon Vijay Abraham I]

use "num-lanes" property to find phy count instead of the number
phy-names property.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/pci/host/pci-dra7xx.c |   23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 5963adc..05bbeee 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -70,7 +70,7 @@
 struct dra7xx_pcie {
void __iomem*base;
struct phy  **phy;
-   int phy_count;
+   int lanes;
struct device   *dev;
struct pcie_portpp;
 };
@@ -364,7 +364,7 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
int ret;
int irq;
int i;
-   int phy_count;
+   u32 lanes;
struct phy **phy;
void __iomem *base;
struct resource *res;
@@ -402,17 +402,16 @@ static int __init dra7xx_pcie_probe(struct 
platform_device *pdev)
if (!base)
return -ENOMEM;
 
-   phy_count = of_property_count_strings(np, "phy-names");
-   if (phy_count < 0) {
-   dev_err(dev, "unable to find the strings\n");
-   return phy_count;
+   if (of_property_read_u32(np, "num-lanes", )) {
+   dev_err(dev, "Failed to parse the number of lanes\n");
+   return -EINVAL;
}
 
-   phy = devm_kzalloc(dev, sizeof(*phy) * phy_count, GFP_KERNEL);
+   phy = devm_kzalloc(dev, sizeof(*phy) * lanes, GFP_KERNEL);
if (!phy)
return -ENOMEM;
 
-   for (i = 0; i < phy_count; i++) {
+   for (i = 0; i < lanes; i++) {
snprintf(name, sizeof(name), "pcie-phy%d", i);
phy[i] = devm_phy_get(dev, name);
if (IS_ERR(phy[i]))
@@ -432,7 +431,7 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
dra7xx->base = base;
dra7xx->phy = phy;
dra7xx->dev = dev;
-   dra7xx->phy_count = phy_count;
+   dra7xx->lanes = lanes;
 
pm_runtime_enable(dev);
ret = pm_runtime_get_sync(dev);
@@ -489,7 +488,7 @@ static int __exit dra7xx_pcie_remove(struct platform_device 
*pdev)
struct dra7xx_pcie *dra7xx = platform_get_drvdata(pdev);
struct pcie_port *pp = >pp;
struct device *dev = >dev;
-   int count = dra7xx->phy_count;
+   int count = dra7xx->lanes;
 
if (pp->irq_domain)
irq_domain_remove(pp->irq_domain);
@@ -535,7 +534,7 @@ static int dra7xx_pcie_resume(struct device *dev)
 static int dra7xx_pcie_suspend_noirq(struct device *dev)
 {
struct dra7xx_pcie *dra7xx = dev_get_drvdata(dev);
-   int count = dra7xx->phy_count;
+   int count = dra7xx->lanes;
 
while (count--) {
phy_power_off(dra7xx->phy[count]);
@@ -548,7 +547,7 @@ static int dra7xx_pcie_suspend_noirq(struct device *dev)
 static int dra7xx_pcie_resume_noirq(struct device *dev)
 {
struct dra7xx_pcie *dra7xx = dev_get_drvdata(dev);
-   int phy_count = dra7xx->phy_count;
+   int phy_count = dra7xx->lanes;
int ret;
int i;
 
-- 
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 10/10] [media] tvp5150: Configure data interface via pdata or DT

[Laurent Pinchart]

Hi Javier,

Thank you for the patch.

On Monday 04 January 2016 09:25:32 Javier Martinez Canillas wrote:
> The video decoder supports either 8-bit 4:2:2 YUV with discrete syncs
> or 8-bit ITU-R BT.656 with embedded syncs output format but currently
> BT.656 it's always reported. Allow to configure the format to use via
> either platform data or a device tree definition.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
>  drivers/media/i2c/tvp5150.c | 61 --
>  include/media/i2c/tvp5150.h |  5 
>  2 files changed, 64 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index fed89a811ab7..8bce45a6e264 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -6,6 +6,7 @@
>   */
> 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -15,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "tvp5150_reg.h"
> 
> @@ -39,6 +41,7 @@ struct tvp5150 {
>   struct media_pad pad;
>   struct v4l2_ctrl_handler hdl;
>   struct v4l2_rect rect;
> + struct tvp5150_platform_data *pdata;

How about embedding tvp5150_platform_data instead of pointing to it ? It would 
save an allocation and you could get rid of the pdata != NULL checks.

>   v4l2_std_id norm;   /* Current set standard */
>   u32 input;
> @@ -757,6 +760,7 @@ static int tvp5150_s_std(struct v4l2_subdev *sd,
> v4l2_std_id std) static int tvp5150_reset(struct v4l2_subdev *sd, u32 val)
>  {
>   struct tvp5150 *decoder = to_tvp5150(sd);
> + struct tvp5150_platform_data *pdata = decoder->pdata;
> 
>   /* Initializes TVP5150 to its default values */
>   tvp5150_write_inittab(sd, tvp5150_init_default);
> @@ -774,6 +778,10 @@ static int tvp5150_reset(struct v4l2_subdev *sd, u32
> val) v4l2_ctrl_handler_setup(>hdl);
> 
>   tvp5150_set_std(sd, decoder->norm);
> +
> + if (pdata && pdata->bus_type == V4L2_MBUS_PARALLEL)
> + tvp5150_write(sd, TVP5150_DATA_RATE_SEL, 0x40);
> +
>   return 0;
>  };
> 
> @@ -940,6 +948,16 @@ static int tvp5150_cropcap(struct v4l2_subdev *sd,
> struct v4l2_cropcap *a) static int tvp5150_g_mbus_config(struct v4l2_subdev
> *sd,
>struct v4l2_mbus_config *cfg)
>  {
> + struct tvp5150_platform_data *pdata = to_tvp5150(sd)->pdata;
> +
> + if (pdata) {
> + cfg->type = pdata->bus_type;
> + cfg->flags = pdata->parallel_flags;

The clock and sync signals polarity don't seem configurable, shouldn't they 
just be hardcoded as currently done ?

> + return 0;
> + }
> +
> + /* Default values if no platform data was provided */
>   cfg->type = V4L2_MBUS_BT656;
>   cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING
> 
>  | V4L2_MBUS_FIELD_EVEN_LOW | V4L2_MBUS_DATA_ACTIVE_HIGH;
> 
> @@ -986,13 +1004,20 @@ static int tvp5150_enum_frame_size(struct v4l2_subdev
> *sd,
> 
>  static int tvp5150_s_stream(struct v4l2_subdev *sd, int enable)
>  {
> + struct tvp5150_platform_data *pdata = to_tvp5150(sd)->pdata;
> + /* Output format: 8-bit ITU-R BT.656 with embedded syncs */
> + int val = 0x09;
> +
> + /* Output format: 8-bit 4:2:2 YUV with discrete sync */
> + if (pdata && pdata->bus_type == V4L2_MBUS_PARALLEL)
> + val = 0x0d;
> +
>   /* Initializes TVP5150 to its default values */
>   /* # set PCLK (27MHz) */
>   tvp5150_write(sd, TVP5150_CONF_SHARED_PIN, 0x00);
> 
> - /* Output format: 8-bit ITU-R BT.656 with embedded syncs */
>   if (enable)
> - tvp5150_write(sd, TVP5150_MISC_CTL, 0x09);
> + tvp5150_write(sd, TVP5150_MISC_CTL, val);
>   else
>   tvp5150_write(sd, TVP5150_MISC_CTL, 0x00);
> 
> @@ -1228,11 +1253,42 @@ static inline int tvp5150_init(struct i2c_client *c)
> return 0;
>  }
> 
> +static struct tvp5150_platform_data *tvp5150_get_pdata(struct device *dev)
> +{
> + struct tvp5150_platform_data *pdata = dev_get_platdata(dev);
> + struct v4l2_of_endpoint bus_cfg;
> + struct device_node *ep;
> +
> + if (pdata)
> + return pdata;

Nobody uses platform data today, I wonder whether we shouldn't postpone adding 
support for it until we have a use case. Embedded systems (at least the ARM-
based ones) should use DT.

> + if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return NULL;
> +
> + ep = of_graph_get_next_endpoint(dev->of_node, NULL);
> + if (!ep)
> + return NULL;
> +
> + v4l2_of_parse_endpoint(ep, _cfg);

Shouldn't you check the return value of the function ?

> +
> + pdata->bus_type = bus_cfg.bus_type;
> + pdata->parallel_flags = bus_cfg.bus.parallel.flags;

The 

[PATCH 1/2] drm: bridge: sil902x

[Boris Brezillon]

Add basic support for the sil902x RGB -> HDMI bridge.
This driver does not support audio output yet.

Signed-off-by: Boris Brezillon 
---
Hello,

This patch is only adding basic support for the sil9022 chip.
As stated in the commit log, there's no audio support, but the
driver also hardcodes a lot of things (like the RGB input format to
use).
There are two reasons for this:
1/ the DRM framework does not allow for advanced link description
   between an encoder and a bridge (that's for the RGB format
   limitation). Any idea how this should be described?

2/ I don't have the datasheet of this HDMI encoder, and all logic
   has been extracted from those two drivers [1][2], which means
   I may miss some important things in my encoder setup.

Another thing I find weird in the drm_bridge interface is the fact
that we have a ->attach() method, but no ->detach(), which can be
a problem if we allow drm bridges and KMS drivers to be compiled as
modules. Any reason for that?

That's all for the questions part :-).

Best Regards,

Boris
---
 drivers/gpu/drm/bridge/Kconfig   |   8 +
 drivers/gpu/drm/bridge/Makefile  |   1 +
 drivers/gpu/drm/bridge/sil902x.c | 491 +++
 3 files changed, 500 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/sil902x.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..9701fd2 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,12 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.
 
+config DRM_SIL902X
+   tristate "Silicon Image sil902x RGB/HDMI bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   ---help---
+ Silicon Image sil902x bridge chip driver.
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..a689aad 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_SIL902X) += sil902x.o
diff --git a/drivers/gpu/drm/bridge/sil902x.c b/drivers/gpu/drm/bridge/sil902x.c
new file mode 100644
index 000..230732d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sil902x.c
@@ -0,0 +1,491 @@
+/*
+ * Copyright (C) 2014 Atmel
+ *   Bo Shen 
+ *
+ * Authors:  Bo Shen 
+ *   Boris Brezillon 
+ *   Wu, Songjun 
+ *
+ *
+ * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * 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.
+ *
+ * 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 
+
+#define SIL902X_TPI_VIDEO_DATA 0x0
+
+#define SIL902X_TPI_PIXEL_REPETITION   0x8
+#define SIL902X_TPI_AVI_PIXEL_REP_BUS_24BIT BIT(5)
+#define SIL902X_TPI_AVI_PIXEL_REP_RISING_EDGE   BIT(4)
+#define SIL902X_TPI_AVI_PIXEL_REP_4X   3
+#define SIL902X_TPI_AVI_PIXEL_REP_2X   1
+#define SIL902X_TPI_AVI_PIXEL_REP_NONE 0
+#define SIL902X_TPI_CLK_RATIO_HALF (0 << 6)
+#define SIL902X_TPI_CLK_RATIO_1X   (1 << 6)
+#define SIL902X_TPI_CLK_RATIO_2X   (2 << 6)
+#define SIL902X_TPI_CLK_RATIO_4X   (3 << 6)
+
+#define SIL902X_TPI_AVI_IN_FORMAT  0x9
+#define SIL902X_TPI_AVI_INPUT_BITMODE_12BITBIT(7)
+#define SIL902X_TPI_AVI_INPUT_DITHER   BIT(6)
+#define SIL902X_TPI_AVI_INPUT_RANGE_LIMITED(2 << 2)
+#define SIL902X_TPI_AVI_INPUT_RANGE_FULL   (1 << 2)
+#define SIL902X_TPI_AVI_INPUT_RANGE_AUTO   (0 << 2)
+#define SIL902X_TPI_AVI_INPUT_COLORSPACE_BLACK (3 << 0)
+#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV422(2 << 0)
+#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV444(1 << 0)
+#define SIL902X_TPI_AVI_INPUT_COLORSPACE_RGB   (0 << 0)
+
+#define SIL902X_TPI_AVI_INFOFRAME  0x0c
+
+#define SIL902X_SYS_CTRL_DATA  0x1a
+#define SIL902X_SYS_CTRL_PWR_DWN   BIT(4)
+#define SIL902X_SYS_CTRL_AV_MUTE   BIT(3)
+#define SIL902X_SYS_CTRL_DDC_BUS_REQ   BIT(2)
+#define 

[PATCH 2/2] drm: bridge: add sil902x DT bindings doc

[Boris Brezillon]

Add Sil9022 DT bindings description.

Signed-off-by: Boris Brezillon 
---
 .../devicetree/bindings/display/bridge/sil902x.txt | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/sil902x.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/sil902x.txt 
b/Documentation/devicetree/bindings/display/bridge/sil902x.txt
new file mode 100644
index 000..7f1339f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sil902x.txt
@@ -0,0 +1,31 @@
+sil902x HDMI bridge bindings
+
+Required properties:
+   - compatible: "sil,sil9022"
+   - reg: i2c address of the bridge
+   - reset-gpios: OF device-tree gpio specification for RST_N pin.
+
+Optional properties:
+   - interrupts-extended or interrupt-parent + interrupts: describe
+ the interrupt line used to inform the host about hotplug events.
+
+Optional subnodes:
+   - video input: Device node can contain video input port node to
+ connect the bridge to a display controller output (See this
+ documentation [1]).
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   hdmi-bridge@39 {
+   compatible = "sil,sil9022";
+   reg = <0x39>;
+   reset-gpios = < 5 1 0 0>;
+   ports {
+   port@0 {
+   bridge_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
-- 
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 10/10] [media] tvp5150: Configure data interface via pdata or DT

[Javier Martinez Canillas]

Hello Laurent,

Thanks a lot for your feedback.

On 01/06/2016 07:56 AM, Laurent Pinchart wrote:
> Hi Javier,
> 
> Thank you for the patch.
> 
> On Monday 04 January 2016 09:25:32 Javier Martinez Canillas wrote:
>> The video decoder supports either 8-bit 4:2:2 YUV with discrete syncs
>> or 8-bit ITU-R BT.656 with embedded syncs output format but currently
>> BT.656 it's always reported. Allow to configure the format to use via
>> either platform data or a device tree definition.
>>
>> Signed-off-by: Javier Martinez Canillas 
>> ---
>>  drivers/media/i2c/tvp5150.c | 61 --
>>  include/media/i2c/tvp5150.h |  5 
>>  2 files changed, 64 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
>> index fed89a811ab7..8bce45a6e264 100644
>> --- a/drivers/media/i2c/tvp5150.c
>> +++ b/drivers/media/i2c/tvp5150.c
>> @@ -6,6 +6,7 @@
>>   */
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -15,6 +16,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include "tvp5150_reg.h"
>>
>> @@ -39,6 +41,7 @@ struct tvp5150 {
>>  struct media_pad pad;
>>  struct v4l2_ctrl_handler hdl;
>>  struct v4l2_rect rect;
>> +struct tvp5150_platform_data *pdata;
> 
> How about embedding tvp5150_platform_data instead of pointing to it ? It 
> would 
> save an allocation and you could get rid of the pdata != NULL checks.
>

Agreed.
 
>>  v4l2_std_id norm;   /* Current set standard */
>>  u32 input;
>> @@ -757,6 +760,7 @@ static int tvp5150_s_std(struct v4l2_subdev *sd,
>> v4l2_std_id std) static int tvp5150_reset(struct v4l2_subdev *sd, u32 val)
>>  {
>>  struct tvp5150 *decoder = to_tvp5150(sd);
>> +struct tvp5150_platform_data *pdata = decoder->pdata;
>>
>>  /* Initializes TVP5150 to its default values */
>>  tvp5150_write_inittab(sd, tvp5150_init_default);
>> @@ -774,6 +778,10 @@ static int tvp5150_reset(struct v4l2_subdev *sd, u32
>> val) v4l2_ctrl_handler_setup(>hdl);
>>
>>  tvp5150_set_std(sd, decoder->norm);
>> +
>> +if (pdata && pdata->bus_type == V4L2_MBUS_PARALLEL)
>> +tvp5150_write(sd, TVP5150_DATA_RATE_SEL, 0x40);
>> +
>>  return 0;
>>  };
>>
>> @@ -940,6 +948,16 @@ static int tvp5150_cropcap(struct v4l2_subdev *sd,
>> struct v4l2_cropcap *a) static int tvp5150_g_mbus_config(struct v4l2_subdev
>> *sd,
>>   struct v4l2_mbus_config *cfg)
>>  {
>> +struct tvp5150_platform_data *pdata = to_tvp5150(sd)->pdata;
>> +
>> +if (pdata) {
>> +cfg->type = pdata->bus_type;
>> +cfg->flags = pdata->parallel_flags;
> 
> The clock and sync signals polarity don't seem configurable, shouldn't they 
> just be hardcoded as currently done ?
>

That's a very good question, I added the flags because according to
Documentation/devicetree/bindings/media/video-interfaces.txt, the way
to define that the output format will be BT.656 is to avoid defining
{hsync,vsync,field-even}-active properties.

IOW, if parallel sync is used, then these properties have to be defined
and it felt strange to not use in the driver what is defined in the DT.

>> +return 0;
>> +}
>> +
>> +/* Default values if no platform data was provided */
>>  cfg->type = V4L2_MBUS_BT656;
>>  cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING
>>
>> | V4L2_MBUS_FIELD_EVEN_LOW | V4L2_MBUS_DATA_ACTIVE_HIGH;
>>
>> @@ -986,13 +1004,20 @@ static int tvp5150_enum_frame_size(struct v4l2_subdev
>> *sd,
>>
>>  static int tvp5150_s_stream(struct v4l2_subdev *sd, int enable)
>>  {
>> +struct tvp5150_platform_data *pdata = to_tvp5150(sd)->pdata;
>> +/* Output format: 8-bit ITU-R BT.656 with embedded syncs */
>> +int val = 0x09;
>> +
>> +/* Output format: 8-bit 4:2:2 YUV with discrete sync */
>> +if (pdata && pdata->bus_type == V4L2_MBUS_PARALLEL)
>> +val = 0x0d;
>> +
>>  /* Initializes TVP5150 to its default values */
>>  /* # set PCLK (27MHz) */
>>  tvp5150_write(sd, TVP5150_CONF_SHARED_PIN, 0x00);
>>
>> -/* Output format: 8-bit ITU-R BT.656 with embedded syncs */
>>  if (enable)
>> -tvp5150_write(sd, TVP5150_MISC_CTL, 0x09);
>> +tvp5150_write(sd, TVP5150_MISC_CTL, val);
>>  else
>>  tvp5150_write(sd, TVP5150_MISC_CTL, 0x00);
>>
>> @@ -1228,11 +1253,42 @@ static inline int tvp5150_init(struct i2c_client *c)
>> return 0;
>>  }
>>
>> +static struct tvp5150_platform_data *tvp5150_get_pdata(struct device *dev)
>> +{
>> +struct tvp5150_platform_data *pdata = dev_get_platdata(dev);
>> +struct v4l2_of_endpoint bus_cfg;
>> +struct device_node *ep;
>> +
>> +if (pdata)
>> +return pdata;
> 
> Nobody uses platform data today, I wonder whether we shouldn't postpone 
> adding 
> support for it until we have a use case. Embedded systems (at least the ARM-
> based 

Re: [PATCH v7 0/5] Add mipi dsi support for rk3288

[Mark yao]

On 2016年01月06日 12:03, Chris Zhong wrote:

The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
IP. This series adds support for a Synopsys DesignWare MIPI DSI host
controller DRM driver.

The MIPI DSI feature is tested on rk3288 evb board, backport them to
chrome os kernel chrome_v3.14, and it can display normally.

This patchset is base on the patchset from ying@freescale.com.


According to the suggestion from Thierry, I have get rid of the bridge,
and register the encoder & connecter in drm/rockchip/dw-mipi-dsi.c.

After backport below patches from linux-next, I can merge this serial into
Dave's drm-next branch.

94d5d6a0fbf3 clk: rockchip: add an id for rk3288 crypto clk
c6d49fbcfcc4 clk: rockchip: add id for mipidsi sclk on rk3288
a2f4c560f18e clk: rockchip: add mipidsi clock on rk3288
69c923743640 ARM: dts: rockchip: correct the name of REG8 for rk3288-evb-act8846
662513a14c9d ARM: dts: rockchip: add 2 regulators for rk3288-evb-act8846
b04061e6599b ARM: dts: rockchip: move the public part to rk3288-evb common




Hi Chris

I had picked following three patches and send a pull-request to Dave
  [PATCH v7 1/5] drm/rockchip: return a true clock rate to 
adjusted_mode
  [PATCH v7 2/5] Documentation: dt-bindings: Add bindings for 
rk3288 DW MIPI DSI driver

  [PATCH v7.2 3/5] drm: rockchip: Support Synopsys DW MIPI DSI

Thanks.

--
Ｍark Yao


--
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] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag

[Vinod Koul]

On Wed, Dec 23, 2015 at 06:28:15PM +0530, Rameshswar Prasad Sahu wrote:
> From: Rameshwar Prasad Sahu 
> 
> For interrupt controller that doesn't support irq_disable and hardware
> with level interrupt, an extra interrupt can be pending. This patch fixes
> the issue by setting IRQ_DISABLE_UNLAZY flag for the interrupt line.
> 
> Reference: http://git.kernel.org/tip/e9849777d0e27cdd2902805be51da73e7c79578c

I seem to have got this patch thrice :(

> 
> Signed-off-by: Rameshwar Prasad Sahu 
> ---
>  drivers/dma/xgene-dma.c |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
> index 9dfa2b0..6363e84 100644
> --- a/drivers/dma/xgene-dma.c
> +++ b/drivers/dma/xgene-dma.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> 
> @@ -1610,6 +1611,7 @@ static int xgene_dma_request_irqs(struct xgene_dma 
> *pdma)
>   /* Register DMA channel rx irq */
>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>   chan = >chan[i];
> + irq_set_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);

Why not use irq_settings_disable_unlazy(), at least read the reference you
pointed out!

>   ret = devm_request_irq(chan->dev, chan->rx_irq,
>  xgene_dma_chan_ring_isr,
>  0, chan->name, chan);
> @@ -1620,6 +1622,7 @@ static int xgene_dma_request_irqs(struct xgene_dma 
> *pdma)
> 
>   for (j = 0; j < i; j++) {
>   chan = >chan[i];
> + irq_clear_status_flags(chan->rx_irq, 
> IRQ_DISABLE_UNLAZY);
>   devm_free_irq(chan->dev, chan->rx_irq, chan);
>   }
> 
> @@ -1640,6 +1643,7 @@ static void xgene_dma_free_irqs(struct xgene_dma *pdma)
> 
>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>   chan = >chan[i];
> + irq_clear_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);
>   devm_free_irq(chan->dev, chan->rx_irq, chan);
>   }
>  }
> --
> 1.7.1

-- 
~Vinod
--
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] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag

[Rameshwar Sahu]

On Wed, Jan 6, 2016 at 3:01 PM, Vinod Koul  wrote:
> On Wed, Jan 06, 2016 at 02:51:07PM +0530, Rameshwar Sahu wrote:
>> Hi Vinod,
>>
>> On Wed, Jan 6, 2016 at 2:43 PM, Vinod Koul  wrote:
>> > On Wed, Dec 23, 2015 at 06:28:15PM +0530, Rameshswar Prasad Sahu wrote:
>> >> From: Rameshwar Prasad Sahu 
>> >>
>> >> For interrupt controller that doesn't support irq_disable and hardware
>> >> with level interrupt, an extra interrupt can be pending. This patch fixes
>> >> the issue by setting IRQ_DISABLE_UNLAZY flag for the interrupt line.
>> >>
>> >> Reference: 
>> >> http://git.kernel.org/tip/e9849777d0e27cdd2902805be51da73e7c79578c
>> >
>> > I seem to have got this patch thrice :(
>> Due to mail failure (some issue was in my email client) to some
>> email-id it was multiple times,
>
> git send-email ?
Yes, was not able to send Arnd Bergmann.
>
>> >
>> >>
>> >> Signed-off-by: Rameshwar Prasad Sahu 
>> >> ---
>> >>  drivers/dma/xgene-dma.c |4 
>> >>  1 files changed, 4 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> >> index 9dfa2b0..6363e84 100644
>> >> --- a/drivers/dma/xgene-dma.c
>> >> +++ b/drivers/dma/xgene-dma.c
>> >> @@ -29,6 +29,7 @@
>> >>  #include 
>> >>  #include 
>> >>  #include 
>> >> +#include 
>> >>  #include 
>> >>  #include 
>> >>
>> >> @@ -1610,6 +1611,7 @@ static int xgene_dma_request_irqs(struct xgene_dma 
>> >> *pdma)
>> >>   /* Register DMA channel rx irq */
>> >>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>> >>   chan = >chan[i];
>> >> + irq_set_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);
>> >
>> > Why not use irq_settings_disable_unlazy(), at least read the reference you
>> > pointed out!
>>
>> irq_settings_disable_unlazy() is helper function to test
>> IRQ_DISABLE_UNLAZY flag is set or not, it's not for setting this flag.
>> FYI...
>> +static inline bool irq_settings_disable_unlazy(struct irq_desc *desc)
>> +{
>> + return desc->status_use_accessors & _IRQ_DISABLE_UNLAZY;
>> +}
>
> Ah yes, I saw clear API and assumed there would be set. Then I think we
> should add a set helper as well as the usage is intended for drivers to
> set this flag
>
> Thomas,
>
> Any reason why you didn't add a set helper, only test and clear?
>
> --
> ~Vinod
--
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] ARM64: tegra: Add support for Google Pixel C

[Jon Hunter]

Add initial device-tree support for Google Pixel C (a.k.a. Smaug) based
upon Tegra210 SoC with 3 GiB of LPDDR4 RAM.

Signed-off-by: Jon Hunter 
---
 arch/arm64/boot/dts/nvidia/Makefile   |  1 +
 arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 42 +++
 2 files changed, 43 insertions(+)
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra210-smaug.dts

diff --git a/arch/arm64/boot/dts/nvidia/Makefile 
b/arch/arm64/boot/dts/nvidia/Makefile
index a7e865da1005..0f7cdf3e05c1 100644
--- a/arch/arm64/boot/dts/nvidia/Makefile
+++ b/arch/arm64/boot/dts/nvidia/Makefile
@@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra132-norrin.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-2180.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2571.dtb
+dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-smaug.dtb
 
 always := $(dtb-y)
 clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts 
b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
new file mode 100644
index ..a7474f5fcbcc
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
@@ -0,0 +1,42 @@
+/dts-v1/;
+
+#include "tegra210.dtsi"
+
+/ {
+   model = "Google Pixel C";
+   compatible = "google,smaug-rev8", "google,smaug-rev7",
+"google,smaug-rev6", "google,smaug-rev5",
+"google,smaug-rev4", "google,smaug-rev3",
+"google,smaug-rev1", "google,smaug", "nvidia,tegra210";
+
+   chosen {
+   bootargs = "console=ttyS0,115200n8 
earlycon=uart8250,mmio32,0x70006000";
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x0 0x8000 0x0 0xc000>;
+   };
+
+   serial@0,70006000 {
+   status = "okay";
+   };
+
+   pmc@0,7000e400 {
+   nvidia,invert-interrupt;
+   nvidia,suspend-mode = <0>;
+   nvidia,cpu-pwr-good-time = <0>;
+   nvidia,cpu-pwr-off-time = <0>;
+   nvidia,core-pwr-good-time = <12000 6000>;
+   nvidia,core-pwr-off-time = <39053>;
+   nvidia,core-power-req-active-high;
+   nvidia,sys-clock-req-active-high;
+   status = "okay";
+   };
+
+   sdhci@0,700b0600 {
+   bus-width = <8>;
+   non-removable;
+   status = "okay";
+   };
+};
-- 
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] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag

[Thomas Gleixner]

On Wed, 6 Jan 2016, Suman Tripathi wrote:
> On Wed, Jan 6, 2016 at 3:35 PM, Thomas Gleixner  wrote:
> > Why would I? Those helpers are core internal and not usable in random
> > drivers.
> >
> 
> i think the problem is the name of the function. It should be something
> 
> irq_check_settings_disable_unlazy

And why is that relevant to a driver? Again, those helpers are core internal
and well understood.

Thanks,

tglx
--
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] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag

[Suman Tripathi]

On Wed, Jan 6, 2016 at 3:40 PM, Suman Tripathi  wrote:
>
>
> On Wed, Jan 6, 2016 at 3:35 PM, Thomas Gleixner  wrote:
>>
>> On Wed, 6 Jan 2016, Vinod Koul wrote:
>> > On Wed, Jan 06, 2016 at 02:51:07PM +0530, Rameshwar Sahu wrote:
>> > > >> @@ -1610,6 +1611,7 @@ static int xgene_dma_request_irqs(struct
>> > > >> xgene_dma *pdma)
>> > > >>   /* Register DMA channel rx irq */
>> > > >>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>> > > >>   chan = >chan[i];
>> > > >> + irq_set_status_flags(chan->rx_irq,
>> > > >> IRQ_DISABLE_UNLAZY);
>> > > >
>> > > > Why not use irq_settings_disable_unlazy(), at least read the
>> > > > reference you
>> > > > pointed out!
>> > >
>> > > irq_settings_disable_unlazy() is helper function to test
>> > > IRQ_DISABLE_UNLAZY flag is set or not, it's not for setting this flag.
>> > > FYI...
>> > > +static inline bool irq_settings_disable_unlazy(struct irq_desc *desc)
>> > > +{
>> > > + return desc->status_use_accessors & _IRQ_DISABLE_UNLAZY;
>> > > +}
>> >
>> > Ah yes, I saw clear API and assumed there would be set. Then I think we
>> > should add a set helper as well as the usage is intended for drivers to
>> > set this flag
>> >
>> > Thomas,
>> >
>> > Any reason why you didn't add a set helper, only test and clear?
>>
>> Why would I? Those helpers are core internal and not usable in random
>> drivers.
>
>
> i think the problem is the name of the function. It should be something
>
> irq_check_settings_disable_unlazy

resending in plain text mode. Sorry for this.

I think the problem is the name of the function. It should be something

irq_check_settings_disable_unlazy

>>
>>
>> Drivers have irq_set_status_flags()/irq_clear_status_flags() ...
>>
>> Thanks,
>>
>> tglx
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
>
> --
> Thanks,
> with regards,
> Suman Tripathi



-- 
Thanks,
with regards,
Suman Tripathi
--
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 07/10] [media] tvp5150: Add device tree binding document

[Javier Martinez Canillas]

Hello Laurent,

On 01/06/2016 07:39 AM, Laurent Pinchart wrote:
> Hi Javier,
> 
> Thank you for the patch.
>

Thanks a lot for your feedback.

[snip]

>> +
>> +Optional Properties:
>> +- powerdown-gpios: phandle for the GPIO connected to the PDN pin, if any.
> 
> The signal is called PDN in the datasheet, so it might make sense to call 
> this 
> pdn-gpios. I have no strong opinion on this, I'll let you decide what you 
> think is best.
>

Yes, I wondered if the convention was to use a descriptive name or the one
used in the datasheet but Documentation/devicetree/bindings/gpio/gpio.txt
says nothing about it.

I'll change it to pdn-gpios since it could be easier to match with the doc.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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] DT: i2c: Update vendor prefix for 24c00

[Wolfram Sang]

On Mon, Jan 04, 2016 at 08:22:33PM +0200, Andy Shevchenko wrote:
> On Sat, Jan 2, 2016 at 11:21 PM, Wolfram Sang  wrote:
> > On Sun, Dec 27, 2015 at 04:57:48PM +0200, Andy Shevchenko wrote:
> >> On Wed, Dec 23, 2015 at 9:18 PM, Akshay Bhat  
> >> wrote:
> >> > "at" is not a valid vendor prefix, correcting the same to "atmel"
> >> >
> >>
> >> I'm afraid you can't just do this change alone as it's used in some
> >> DTS. Though you may deprecated it along with update of current users.
> >
> > Well, in Linux, I2C core currently strips the vendor anyhow. This will
> > probably be changed somewhen (tm), but for now, the impact for Linux
> > should be extremly close to 0.
> 
> Okay, no objections to the original patch then.

Heh, I just go reminded that eeproms already have a seperate binding
description (Documentation/devicetree/bindings/eeprom/eeprom.txt).

I will update the eeprom bindings and remove the entries from trivial
devices.



signature.asc
Description: Digital signature

Re: [PATCH] dmaengine: xgene-dma: Fix double IRQ issue by setting IRQ_DISABLE_UNLAZY flag

[Rameshwar Sahu]

Hi Vinod,

On Wed, Jan 6, 2016 at 2:43 PM, Vinod Koul  wrote:
> On Wed, Dec 23, 2015 at 06:28:15PM +0530, Rameshswar Prasad Sahu wrote:
>> From: Rameshwar Prasad Sahu 
>>
>> For interrupt controller that doesn't support irq_disable and hardware
>> with level interrupt, an extra interrupt can be pending. This patch fixes
>> the issue by setting IRQ_DISABLE_UNLAZY flag for the interrupt line.
>>
>> Reference: http://git.kernel.org/tip/e9849777d0e27cdd2902805be51da73e7c79578c
>
> I seem to have got this patch thrice :(
Due to mail failure (some issue was in my email client) to some
email-id it was multiple times,
>
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>> ---
>>  drivers/dma/xgene-dma.c |4 
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> index 9dfa2b0..6363e84 100644
>> --- a/drivers/dma/xgene-dma.c
>> +++ b/drivers/dma/xgene-dma.c
>> @@ -29,6 +29,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> @@ -1610,6 +1611,7 @@ static int xgene_dma_request_irqs(struct xgene_dma 
>> *pdma)
>>   /* Register DMA channel rx irq */
>>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>>   chan = >chan[i];
>> + irq_set_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);
>
> Why not use irq_settings_disable_unlazy(), at least read the reference you
> pointed out!

irq_settings_disable_unlazy() is helper function to test
IRQ_DISABLE_UNLAZY flag is set or not, it's not for setting this flag.
FYI...
+static inline bool irq_settings_disable_unlazy(struct irq_desc *desc)
+{
+ return desc->status_use_accessors & _IRQ_DISABLE_UNLAZY;
+}
>
>>   ret = devm_request_irq(chan->dev, chan->rx_irq,
>>  xgene_dma_chan_ring_isr,
>>  0, chan->name, chan);
>> @@ -1620,6 +1622,7 @@ static int xgene_dma_request_irqs(struct xgene_dma 
>> *pdma)
>>
>>   for (j = 0; j < i; j++) {
>>   chan = >chan[i];
>> + irq_clear_status_flags(chan->rx_irq, 
>> IRQ_DISABLE_UNLAZY);
>>   devm_free_irq(chan->dev, chan->rx_irq, chan);
>>   }
>>
>> @@ -1640,6 +1643,7 @@ static void xgene_dma_free_irqs(struct xgene_dma *pdma)
>>
>>   for (i = 0; i < XGENE_DMA_MAX_CHANNEL; i++) {
>>   chan = >chan[i];
>> + irq_clear_status_flags(chan->rx_irq, IRQ_DISABLE_UNLAZY);
>>   devm_free_irq(chan->dev, chan->rx_irq, chan);
>>   }
>>  }
>> --
>> 1.7.1
>
> --
> ~Vinod
--
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] ARM64: tegra: Add support for Google Pixel C

[Mark Rutland]

Hi,

On Wed, Jan 06, 2016 at 09:40:22AM +, Jon Hunter wrote:
> Add initial device-tree support for Google Pixel C (a.k.a. Smaug) based
> upon Tegra210 SoC with 3 GiB of LPDDR4 RAM.
> 
> Signed-off-by: Jon Hunter 
> ---
>  arch/arm64/boot/dts/nvidia/Makefile   |  1 +
>  arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 42 
> +++
>  2 files changed, 43 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> 
> diff --git a/arch/arm64/boot/dts/nvidia/Makefile 
> b/arch/arm64/boot/dts/nvidia/Makefile
> index a7e865da1005..0f7cdf3e05c1 100644
> --- a/arch/arm64/boot/dts/nvidia/Makefile
> +++ b/arch/arm64/boot/dts/nvidia/Makefile
> @@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra132-norrin.dtb
>  dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-.dtb
>  dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-2180.dtb
>  dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2571.dtb
> +dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-smaug.dtb
>  
>  always   := $(dtb-y)
>  clean-files  := *.dtb
> diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts 
> b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> new file mode 100644
> index ..a7474f5fcbcc
> --- /dev/null
> +++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> @@ -0,0 +1,42 @@
> +/dts-v1/;
> +
> +#include "tegra210.dtsi"
> +
> +/ {
> + model = "Google Pixel C";
> + compatible = "google,smaug-rev8", "google,smaug-rev7",
> +  "google,smaug-rev6", "google,smaug-rev5",
> +  "google,smaug-rev4", "google,smaug-rev3",
> +  "google,smaug-rev1", "google,smaug", "nvidia,tegra210";

This looks a little funky. Is each revision a strict superset of the
previous version?

> +
> + chosen {
> + bootargs = "console=ttyS0,115200n8 
> earlycon=uart8250,mmio32,0x70006000";
> + };

Use stdout-path.

Otherwise this looks ok.

Thanks,
Mark.
--
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 08/10] [media] tvp5150: Add OF match table

[Laurent Pinchart]

Hi Javier,

Thank you for the patch.

On Monday 04 January 2016 09:25:30 Javier Martinez Canillas wrote:
> From: Eduard Gavin 
> 
> The Documentation/devicetree/bindings/media/i2c/tvp5150.txt DT binding doc
> lists "ti,tvp5150" as the device compatible string but the driver does not
> have an OF match table. Add the table to the driver so the I2C core can do
> an OF style match.
> 
> Signed-off-by: Eduard Gavin 
> Signed-off-by: Javier Martinez Canillas 

Reviewed-by: Laurent Pinchart 

> ---
> 
>  drivers/media/i2c/tvp5150.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index 105bd1c6b17f..caac96a577f8 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -1295,8 +1295,17 @@ static const struct i2c_device_id tvp5150_id[] = {
>  };
>  MODULE_DEVICE_TABLE(i2c, tvp5150_id);
> 
> +#if IS_ENABLED(CONFIG_OF)
> +static const struct of_device_id tvp5150_of_match[] = {
> + { .compatible = "ti,tvp5150", },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, tvp5150_of_match);
> +#endif
> +
>  static struct i2c_driver tvp5150_driver = {
>   .driver = {
> + .of_match_table = of_match_ptr(tvp5150_of_match),
>   .name   = "tvp5150",
>   },
>   .probe  = tvp5150_probe,

-- 
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 07/10] [media] tvp5150: Add device tree binding document

[Laurent Pinchart]

Hi Javier,

Thank you for the patch.

On Monday 04 January 2016 09:25:29 Javier Martinez Canillas wrote:
> Add a Device Tree binding document for the TVP5150 video decoder.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
>  .../devicetree/bindings/media/i2c/tvp5150.txt  | 35 +++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp5150.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
> b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt new file mode
> 100644
> index ..bf0b3f3128ce
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
> @@ -0,0 +1,35 @@
> +* Texas Instruments TVP5150 and TVP5151 video decoders
> +
> +The TVP5150 and TVP5151 are video decoders that convert baseband NTSC and
> PAL
> +(and also SECAM in the TVP5151 case) video signals to either 8-bit 4:2:2
> YUV
> +with discrete syncs or 8-bit ITU-R BT.656 with embedded syncs output
> formats.
> +
> +Required Properties:
> +- compatible: value must be "ti,tvp5150"
> +- reg: I2C slave address
> +
> +Optional Properties:
> +- powerdown-gpios: phandle for the GPIO connected to the PDN pin, if any.

The signal is called PDN in the datasheet, so it might make sense to call this 
pdn-gpios. I have no strong opinion on this, I'll let you decide what you 
think is best.

Apart from that (and the indentation issue pointed out by Rob),

Reviewed-by: Laurent Pinchart 

> +- reset-gpios: phandle for the GPIO connected to the RESETB pin, if any.
> +
> +The device node must contain one 'port' child node for its digital output
> +video port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +
> + {
> + ...
> + tvp5150@5c {
> + compatible = "ti,tvp5150";
> + reg = <0x5c>;
> + powerdown-gpios = < 30 GPIO_ACTIVE_LOW>;
> + reset-gpios = < 7 GPIO_ACTIVE_LOW>;
> +
> + port {
> + tvp5150_1: endpoint {
> + remote-endpoint = <_ep>;
> + };
> + };
> + };
> +};

-- 
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 1/2] drm: bridge: sil902x

[kbuild test robot]

Hi Boris,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.4-rc8 next-20160106]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Boris-Brezillon/drm-bridge-sil902x/20160106-192921
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: powerpc-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu/drm/bridge/sil902x.c:31:0:
   drivers/gpu/drm/bridge/sil902x.c: In function 'sil902x_bridge_mode_set':
>> drivers/gpu/drm/bridge/sil902x.c:300:13: warning: format '%zd' expects 
>> argument of type 'signed size_t', but argument 2 has type 'int' [-Wformat=]
  DRM_ERROR("failed to pack AVI infoframe: %zd\n", ret);
^
   include/drm/drmP.h:168:10: note: in definition of macro 'DRM_ERROR'
 drm_err(fmt, ##__VA_ARGS__)
 ^
   drivers/gpu/drm/bridge/sil902x.c: In function 'sil902x_probe':
   drivers/gpu/drm/bridge/sil902x.c:401:16: warning: format '%d' expects 
argument of type 'int', but argument 3 has type 'long int' [-Wformat=]
  dev_err(dev, "Failed to retrieve/request reset gpio: %d\n",
   ^

vim +300 drivers/gpu/drm/bridge/sil902x.c

   284   SIL902X_TPI_AVI_PIXEL_REP_BUS_24BIT;
   285  buf[9] = SIL902X_TPI_AVI_INPUT_RANGE_AUTO |
   286   SIL902X_TPI_AVI_INPUT_COLORSPACE_RGB;
   287  
   288  ret = regmap_bulk_write(regmap, SIL902X_TPI_VIDEO_DATA, buf, 
10);
   289  if (ret)
   290  return;
   291  
   292  ret = drm_hdmi_avi_infoframe_from_display_mode(, adj);
   293  if (ret < 0) {
   294  DRM_ERROR("couldn't fill AVI infoframe\n");
   295  return;
   296  }
   297  
   298  ret = hdmi_avi_infoframe_pack(, buf, sizeof(buf));
   299  if (ret < 0) {
 > 300  DRM_ERROR("failed to pack AVI infoframe: %zd\n", ret);
   301  return;
   302  }
   303  
   304  /* Do not send the infoframe header, but keep the CRC field. */
   305  regmap_bulk_write(regmap, SIL902X_TPI_AVI_INFOFRAME,
   306buf + HDMI_INFOFRAME_HEADER_SIZE - 1,
   307HDMI_AVI_INFOFRAME_SIZE + 1);
   308  }

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [RESEND PATCH v1 4/4] clk: rockchip: rk3036: fix and add node id for emac clock

[Xing Zheng]

Hi Heiko,

On 2016年01月02日 10:34, Xing Zheng wrote:
> Hi Heiko,
> Thank you for your patch, I will apply and test it later.
>
> Thanks.
>
>> 在 2016年1月2日，06:10，Heiko Stübner  写道：
>>
>> Hi Xing,
>>
>> Am Dienstag, 29. Dezember 2015, 10:34:09 schrieb Xing Zheng:
>>> On 2015年12月29日 09:59, Yakir Yang wrote:
 On 12/28/2015 08:41 PM, Heiko Stübner wrote:
> Am Montag, 28. Dezember 2015, 17:03:53 schrieb Xing Zheng:
>> Due to referred old version TRM, there is incorrect emac clock node,
>> we should fix it. The SEL_21_9 is the parent of SEL_21_4.
>>
>> In the emac driver, we need to refer HCLK_MAC, and because There are
>> only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
>> GPLL, and it is unable to provide the accurate rate for mac_ref which
>> need to 50MHz probability, we should let it under the APLL and are
>> able to set the freq which integer multiples of 50MHz, so we add these
>> emac node for reference.
> I don't really follow here. While I do understand that the emac needs
> 50MHz, I
> don't think using the APLL as source is helpful.
>
> The APLL is the main clocksource for the cpu-cores, including frequency
> scaling, and while it currently only lists 816MHz as sole frequency,
> you're
> pretty much guaranteed to not get your correct multiple of 50MHz from
> there
> either. And limiting the cpu to just do 600MHz to get the mac working
> sounds
> pretty bad ;-) .
>
>
> In the rk3036 cru-node the gpll gets set to 594MHz. Is there a
> special reason
> why it needs to be 594MHz and cannot be a round 600MHz? Because that
> would
> also provide your 50MHz-multiple nicely.
 Yes, this magic 594MHz would help to support the standard HDMI
 resolutions, here are the math:

 1920x1080-60Hz DCLK = 148.5MHz = 594MHz / 4
 1280x720-60Hz DCLK = 74.25MHz = 594MHz / 8
 720x480-60Hz DCLK = 27MHz = 594MHz / 22

 Thanks,
 - Yakir
>>> Thanks Yakir.
>>>
>>> Hi Heiko,
>>> From the above, do you have better idea for the RK3036's emac without
>>> ext-oscillator?
>> During the last days I did play a bit with the clock framework. As I don't 
>> have a Kylin (or any rk3036) board, I did build a test-case with pclk_cpu on 
>> the rk3188 (which can be affected by the armclk if not reparented to the 
>> gpll), which got sucessfully adapted to get back to (or near) the originally 
>> requested frequency.
>>
>> So ideally you could roll back your mux/div split here and try the attached 
>> diff. In theory it should help :-) .
>> As can be seen by the FIXMEs, not fully finished, but I'd like to determine 
>> if 
>> it fixes the issue at least.
>>
>>
>> Heiko
>> 

I tested your patch just now, it seems to work well. I will do more tests.

Thank you. :-)

--
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

[RFC v2 1/4] of: make of_mutex public

[Wolfram Sang]

From: Wolfram Sang 

If we want to use OF_DYNAMIC features outside the of framework, we need
to access this lock.

Signed-off-by: Wolfram Sang 
---
 drivers/of/of_private.h | 1 -
 include/linux/of.h  | 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 8e882e706cd8c6..f92ec41efb5dfd 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -31,7 +31,6 @@ struct alias_prop {
char stem[0];
 };
 
-extern struct mutex of_mutex;
 extern struct list_head aliases_lookup;
 extern struct kset *of_kset;
 
diff --git a/include/linux/of.h b/include/linux/of.h
index dd10626a615fb1..acac979063f067 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -32,6 +32,8 @@
 typedef u32 phandle;
 typedef u32 ihandle;
 
+extern struct mutex of_mutex;
+
 struct property {
char*name;
int length;
-- 
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 1/1] regulator: max8973: add support for junction thermal warning

[Mark Brown]

On Wed, Jan 06, 2016 at 05:49:22PM +0530, Laxman Dewangan wrote:
> On Wednesday 06 January 2016 05:48 PM, Mark Brown wrote:
> >* PGP Signed by an unknown key

> >On Wed, Jan 06, 2016 at 11:45:22AM +0530, Laxman Dewangan wrote:

> >>  Enhanced transient response (ETR) will affect the configuration of CKADV.
> >>+-maxim,junction-temp-warning: Junction temp warning on which device 
> >>generates
> >>+   warning interrupts.
> >This needs to specify what the values are - it looks like it's raw
> >register values but I'd have expected from this that it'd be an actual
> >temperature.

> I tried to roundoff to the next higher threshold when supported value (120
> or 140 degC) is not provided in driver. But it is fine to me to specify the
> possible value setting here and DT binding doc. Will do on next patch.

I don't really mind which you use so long as the documentation is clear.

> >>+-interrupt-flags: Interrupt flags for registering interrupt which can not 
> >>be
> >>+   passed via interrupt properties.

> >Why is this being specified and what are the values?  Most devices don't
> >have this...

> I have two different design with this device:
> In both design, I have main PMIC like MAX77620 and two MAX77621.

> In one of design, interrupt from MAX77620, and alert from both MAX77621
> shorted and going to Arm GIC controller. On this case, I need to register
> the interrupt as SHARED interrupt. This property can not be passed via
> "interrupt" properties from DT.
> That's why this flag is added to support this.

If the driver supports shared interrupts it should just register as a
shared interrupt all the time, there is nothing about shared interrupts
which requires that the pin actually be shared.

> Now, by default, if I register the interrupt as SHARED in driver then it
> failed on second design as GPIO does not offer to register as SHARED
> interrupt.

What makes you say that this would fail?


signature.asc
Description: PGP signature

Re: [PATCH 2/2] drm: bridge: add sil902x DT bindings doc

[Rob Herring]

On Wed, Jan 06, 2016 at 12:25:51PM +0100, Boris Brezillon wrote:
> Add Sil9022 DT bindings description.
> 
> Signed-off-by: Boris Brezillon 
> ---
>  .../devicetree/bindings/display/bridge/sil902x.txt | 31 
> ++
>  1 file changed, 31 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/sil902x.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/sil902x.txt 
> b/Documentation/devicetree/bindings/display/bridge/sil902x.txt
> new file mode 100644
> index 000..7f1339f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/sil902x.txt
> @@ -0,0 +1,31 @@
> +sil902x HDMI bridge bindings
> +
> +Required properties:
> + - compatible: "sil,sil9022"
> + - reg: i2c address of the bridge
> + - reset-gpios: OF device-tree gpio specification for RST_N pin.
> +
> +Optional properties:
> + - interrupts-extended or interrupt-parent + interrupts: describe
> +   the interrupt line used to inform the host about hotplug events.
> +
> +Optional subnodes:
> + - video input: Device node can contain video input port node to
> +   connect the bridge to a display controller output (See this
> +   documentation [1]).
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> + hdmi-bridge@39 {
> + compatible = "sil,sil9022";
> + reg = <0x39>;
> + reset-gpios = < 5 1 0 0>;

4 GPIO cells? Valid, but unusual.

> + ports {
> + port@0 {

Either need a reg property here or drop the unit address. You could 
remove ports as well.

> + bridge_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> -- 
> 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] phy: ti-pipe3: configure usb3 phy to be used as pcie phy

[Rob Herring]

On Wed, Jan 06, 2016 at 04:29:08PM +0530, Kishon Vijay Abraham I wrote:
> DRA72 uses USB3 PHY for the 2nd lane of PCIE. The configuration
> required to make USB3 PHY used for the 2nd lane of PCIe is done
> here.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  Documentation/devicetree/bindings/phy/ti-phy.txt |2 ++
>  drivers/phy/phy-ti-pipe3.c   |   30 
> +-
>  2 files changed, 31 insertions(+), 1 deletion(-)

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 10/10] [media] tvp5150: Configure data interface via pdata or DT

[Laurent Pinchart]

Hi Javier,

On Wednesday 06 January 2016 08:27:26 Javier Martinez Canillas wrote:
> On 01/06/2016 07:56 AM, Laurent Pinchart wrote:
> > On Monday 04 January 2016 09:25:32 Javier Martinez Canillas wrote:
> >> The video decoder supports either 8-bit 4:2:2 YUV with discrete syncs
> >> or 8-bit ITU-R BT.656 with embedded syncs output format but currently
> >> BT.656 it's always reported. Allow to configure the format to use via
> >> either platform data or a device tree definition.
> >> 
> >> Signed-off-by: Javier Martinez Canillas 
> >> ---
> >> 
> >>  drivers/media/i2c/tvp5150.c | 61 +--
> >>  include/media/i2c/tvp5150.h |  5 
> >>  2 files changed, 64 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> >> index fed89a811ab7..8bce45a6e264 100644
> >> --- a/drivers/media/i2c/tvp5150.c
> >> +++ b/drivers/media/i2c/tvp5150.c

[snip]

> >> @@ -940,6 +948,16 @@ static int tvp5150_cropcap(struct v4l2_subdev *sd,
> >> struct v4l2_cropcap *a)
> >>  static int tvp5150_g_mbus_config(struct v4l2_subdev *sd,
> >> struct v4l2_mbus_config *cfg)
> >>  {
> >> +  struct tvp5150_platform_data *pdata = to_tvp5150(sd)->pdata;
> >> +
> >> +  if (pdata) {
> >> +  cfg->type = pdata->bus_type;
> >> +  cfg->flags = pdata->parallel_flags;
> > 
> > The clock and sync signals polarity don't seem configurable, shouldn't
> > they just be hardcoded as currently done ?
> 
> That's a very good question, I added the flags because according to
> Documentation/devicetree/bindings/media/video-interfaces.txt, the way
> to define that the output format will be BT.656 is to avoid defining
> {hsync,vsync,field-even}-active properties.
> 
> IOW, if parallel sync is used, then these properties have to be defined
> and it felt strange to not use in the driver what is defined in the DT.

In that case we should restrict the values of the properties to what the 
hardware actually supports. I would hardcode the flags here, and check them 
when parsing the endpoint to make sure they're valid.

If you find a register I have missed in the documentation with which 
polarities could be configured then please also feel free to prove me wrong 
:-)

> >> +  return 0;
> >> +  }
> >> +
> >> +  /* Default values if no platform data was provided */
> >>cfg->type = V4L2_MBUS_BT656;
> >>cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING
> >>   | V4L2_MBUS_FIELD_EVEN_LOW | V4L2_MBUS_DATA_ACTIVE_HIGH;

[snip]

> >> @@ -1228,11 +1253,42 @@ static inline int tvp5150_init(struct i2c_client
> >> *c) return 0;
> >> 
> >>  }
> >> 
> >> +static struct tvp5150_platform_data *tvp5150_get_pdata(struct device
> >> *dev)
> >> +{
> >> +  struct tvp5150_platform_data *pdata = dev_get_platdata(dev);
> >> +  struct v4l2_of_endpoint bus_cfg;
> >> +  struct device_node *ep;
> >> +
> >> +  if (pdata)
> >> +  return pdata;
> > 
> > Nobody uses platform data today, I wonder whether we shouldn't postpone
> > adding support for it until we have a use case. Embedded systems (at
> > least the ARM- based ones) should use DT.
> 
> Yes, I just added it for completeness since in other subsystems I've been
> yelled in the past that not all the world is DT and that I needed a pdata :)
> 
> But I'll gladly remove it since it means less code which is always good.
> 
> >> +  if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> >> +  pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> >> +  if (!pdata)
> >> +  return NULL;
> >> +
> >> +  ep = of_graph_get_next_endpoint(dev->of_node, NULL);
> >> +  if (!ep)
> >> +  return NULL;
> >> +
> >> +  v4l2_of_parse_endpoint(ep, _cfg);
> > 
> > Shouldn't you check the return value of the function ?
> 
> Right, the v4l2_of_parse_endpoint() kernel doc says "Return: 0." and most
> drivers are not checking the return value so I thought that it couldn't
> fail. But now looking at the implementation I see that's not true so I'll
> add a check in v2.
> 
> I'll also post patches to update v4l2_of_parse_endpoint() kernel-doc and
> the drivers that are not currently checking for this return value.

Thank you for that.

> >> +
> >> +  pdata->bus_type = bus_cfg.bus_type;
> >> +  pdata->parallel_flags = bus_cfg.bus.parallel.flags;
> > 
> > The V4L2_MBUS_DATA_ACTIVE_HIGH flags set returned by
> > tvp5150_g_mbus_config() when pdata is NULL is never set by
> > v4l2_of_parse_endpoint(), should you add it unconditionally ?
> 
> But v4l2_of_parse_endpoint() calls v4l2_of_parse_parallel_bus() which does
> it or did I read the code incorrectly?

No, you're right, I had overlooked the V4L2_MBUS_DATA_ACTIVE_HIGH flag when 
reading v4l2_of_parse_parallel_bus(), probably a typo when searching. Please 
ignore that comment.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send 

Re: [PATCH 1/2] drm: bridge: sil902x

[Sascha Hauer]

Hi Boris,

On Wed, Jan 06, 2016 at 12:25:50PM +0100, Boris Brezillon wrote:
> Add basic support for the sil902x RGB -> HDMI bridge.
> This driver does not support audio output yet.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Hello,
> 
> This patch is only adding basic support for the sil9022 chip.

This thing is a SiI9022 for camel case "Silicon Image" with a capital 'I',
not a small 'l'.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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] drm: bridge: sil902x

[Boris Brezillon]

Add basic support for the sil902x RGB -> HDMI bridge.
This driver does not support audio output yet.

Signed-off-by: Boris Brezillon 
---
Hello,

This patch is only adding basic support for the sil9022 chip.
As stated in the commit log, there's no audio support, but the
driver also hardcodes a lot of things (like the RGB input format to
use).
There are two reasons for this:
1/ the DRM framework does not allow for advanced link description
   between an encoder and a bridge (that's for the RGB format
   limitation). Any idea how this should be described?

2/ I don't have the datasheet of this HDMI encoder, and all logic
   has been extracted from those two drivers [1][2], which means
   I may miss some important things in my encoder setup.

Another thing I find weird in the drm_bridge interface is the fact
that we have a ->attach() method, but no ->detach(), which can be
a problem if we allow drm bridges and KMS drivers to be compiled as
modules. Any reason for that?

That's all for the questions part :-).

Best Regards,

Boris

Changes in v2:
- fix errors reported by kbuild test robot

---
 drivers/gpu/drm/bridge/Kconfig   |   8 +
 drivers/gpu/drm/bridge/Makefile  |   1 +
 drivers/gpu/drm/bridge/sil902x.c | 491 +++
 3 files changed, 500 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/sil902x.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..9701fd2 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,12 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.
 
+config DRM_SIL902X
+   tristate "Silicon Image sil902x RGB/HDMI bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   ---help---
+ Silicon Image sil902x bridge chip driver.
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..a689aad 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_SIL902X) += sil902x.o
diff --git a/drivers/gpu/drm/bridge/sil902x.c b/drivers/gpu/drm/bridge/sil902x.c
new file mode 100644
index 000..2657031
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sil902x.c
@@ -0,0 +1,491 @@
+/*
+ * Copyright (C) 2014 Atmel
+ *   Bo Shen 
+ *
+ * Authors:  Bo Shen 
+ *   Boris Brezillon 
+ *   Wu, Songjun 
+ *
+ *
+ * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * 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.
+ *
+ * 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 
+
+#define SIL902X_TPI_VIDEO_DATA 0x0
+
+#define SIL902X_TPI_PIXEL_REPETITION   0x8
+#define SIL902X_TPI_AVI_PIXEL_REP_BUS_24BIT BIT(5)
+#define SIL902X_TPI_AVI_PIXEL_REP_RISING_EDGE   BIT(4)
+#define SIL902X_TPI_AVI_PIXEL_REP_4X   3
+#define SIL902X_TPI_AVI_PIXEL_REP_2X   1
+#define SIL902X_TPI_AVI_PIXEL_REP_NONE 0
+#define SIL902X_TPI_CLK_RATIO_HALF (0 << 6)
+#define SIL902X_TPI_CLK_RATIO_1X   (1 << 6)
+#define SIL902X_TPI_CLK_RATIO_2X   (2 << 6)
+#define SIL902X_TPI_CLK_RATIO_4X   (3 << 6)
+
+#define SIL902X_TPI_AVI_IN_FORMAT  0x9
+#define SIL902X_TPI_AVI_INPUT_BITMODE_12BITBIT(7)
+#define SIL902X_TPI_AVI_INPUT_DITHER   BIT(6)
+#define SIL902X_TPI_AVI_INPUT_RANGE_LIMITED(2 << 2)
+#define SIL902X_TPI_AVI_INPUT_RANGE_FULL   (1 << 2)
+#define SIL902X_TPI_AVI_INPUT_RANGE_AUTO   (0 << 2)
+#define SIL902X_TPI_AVI_INPUT_COLORSPACE_BLACK (3 << 0)
+#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV422(2 << 0)
+#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV444(1 << 0)
+#define SIL902X_TPI_AVI_INPUT_COLORSPACE_RGB   (0 << 0)
+
+#define SIL902X_TPI_AVI_INFOFRAME  0x0c
+
+#define SIL902X_SYS_CTRL_DATA  0x1a
+#define SIL902X_SYS_CTRL_PWR_DWN   BIT(4)
+#define SIL902X_SYS_CTRL_AV_MUTE   BIT(3)
+#define 

Re: [PATCH 1/1] regulator: max8973: add support for junction thermal warning

[Laxman Dewangan]

On Wednesday 06 January 2016 05:48 PM, Mark Brown wrote:

* PGP Signed by an unknown key

On Wed, Jan 06, 2016 at 11:45:22AM +0530, Laxman Dewangan wrote:


  Enhanced transient response (ETR) will affect the configuration of CKADV.
+-maxim,junction-temp-warning: Junction temp warning on which device generates
+   warning interrupts.

This needs to specify what the values are - it looks like it's raw
register values but I'd have expected from this that it'd be an actual
temperature.


I tried to roundoff to the next higher threshold when supported value 
(120 or 140 degC) is not provided in driver. But it is fine to me to 
specify the possible value setting here and DT binding doc. Will do on 
next patch.




+-interrupt-flags: Interrupt flags for registering interrupt which can not be
+   passed via interrupt properties.

Why is this being specified and what are the values?  Most devices don't
have this...



I have two different design with this device:
In both design, I have main PMIC like MAX77620 and two MAX77621.

In one of design, interrupt from MAX77620, and alert from both MAX77621 
shorted and going to Arm GIC controller. On this case, I need to 
register the interrupt as SHARED interrupt. This property can not be 
passed via "interrupt" properties from DT.

That's why this flag is added to support this.

On other design, interrupt from all devices are going to different pins, 
MAX77620 to ARM GIC and MAX77621 to different gpio pins. On this case, 
interrupt are not SHARED.


Now, by default, if I register the interrupt as SHARED in driver then it 
failed on second design as GPIO does not offer to register as SHARED 
interrupt.


To support both design, I have added flag properties and passed from DT.




--
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] drm: bridge: add sil902x DT bindings doc

[Boris Brezillon]

Hi Rob,

On Wed, 6 Jan 2016 07:19:59 -0600
Rob Herring  wrote:

> On Wed, Jan 06, 2016 at 12:25:51PM +0100, Boris Brezillon wrote:
> > Add Sil9022 DT bindings description.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  .../devicetree/bindings/display/bridge/sil902x.txt | 31 
> > ++
> >  1 file changed, 31 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/bridge/sil902x.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/display/bridge/sil902x.txt 
> > b/Documentation/devicetree/bindings/display/bridge/sil902x.txt
> > new file mode 100644
> > index 000..7f1339f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/sil902x.txt
> > @@ -0,0 +1,31 @@
> > +sil902x HDMI bridge bindings
> > +
> > +Required properties:
> > +   - compatible: "sil,sil9022"
> > +   - reg: i2c address of the bridge
> > +   - reset-gpios: OF device-tree gpio specification for RST_N pin.
> > +
> > +Optional properties:
> > +   - interrupts-extended or interrupt-parent + interrupts: describe
> > + the interrupt line used to inform the host about hotplug events.
> > +
> > +Optional subnodes:
> > +   - video input: Device node can contain video input port node to
> > + connect the bridge to a display controller output (See this
> > + documentation [1]).
> > +
> > +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> > +
> > +Example:
> > +   hdmi-bridge@39 {
> > +   compatible = "sil,sil9022";
> > +   reg = <0x39>;
> > +   reset-gpios = < 5 1 0 0>;
> 
> 4 GPIO cells? Valid, but unusual.

Hehe, I blindly copied nxp,ptn3460 doc, which is defining such GPIO
descriptors :-). I can change that if you want.

> 
> > +   ports {
> > +   port@0 {
> 
> Either need a reg property here or drop the unit address. You could 
> remove ports as well.

Actually we'll likely define a 2nd port for the audio input, so I'd
prefer keeping the ports and @0 suffix and adding a reg property rather
than just defining port { ... };

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
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

Re: [PATCH v4 2/3] ARM: dts: sun8i: Add Allwinner A83T dtsi

[Mark Rutland]

Hi,

> + chosen {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + };

What is the ranges property doing here?

[...]

> + clocks {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + osc24M: osc24M_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <2400>;
> + clock-output-names = "osc24M";
> + };
> +
> + osc32k: osc32k_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "osc32k";
> + };
> + };

Just put the clocks under the root node. 'clocks' is not a special node.

Thanks,
Mark.
--
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 0/2] ata: Introduce the AHCI_HFLAG_EDGE_IRQ_BROKEN in libahci and enabling it for ahci_xgene driver.

[Suman Tripathi]

Happy new  year !!

Any comments on this patchset ?

On Thu, Dec 24, 2015 at 1:01 PM, Suman Tripathi  wrote:
> This patch set implements a workaround for an errate in the APM
> X-Gene SATA host controller with edge interrupt. The HOST_IRQ_STAT
> misses the edge interrupt from the PORT_IRQ_STAT when clearing the
> HOST_IRQ_STAT and reporting the PORT_IRQ_STAT happens in same clock
> cycle.
>
> Signed-off-by: Suman Tripathi 
>
> Suman Tripathi (2):
>   libahci: Implement the workaround to fix the missing of edge
> interrupt for HOST_IRQ_STAT
>   ahci_xgene: Enable AHCI_HFLAG_EDGE_IRQ_BROKEN for APM X-Gen2 SATA
> host controller
>
>  drivers/ata/ahci.h   |2 ++
>  drivers/ata/ahci_xgene.c |3 ++-
>  drivers/ata/libahci.c|   45 +
>  3 files changed, 49 insertions(+), 1 deletions(-)
>



-- 
Thanks,
with regards,
Suman Tripathi
--
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] pci: host: pci-dra7xx: Enable x2 mode support

[Rob Herring]

On Wed, Jan 06, 2016 at 04:19:53PM +0530, Kishon Vijay Abraham I wrote:
> Perform syscon configurations to get x2 mode to working in DRA74x and
> DRA72x. Also add a new compatible string to dfferentiate
> DRA72x and DRA74x, since b1c0 mask is different for both these platforms.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  Documentation/devicetree/bindings/pci/ti-pci.txt |8 ++-
>  drivers/pci/host/pci-dra7xx.c|   81 
> +-
>  2 files changed, 86 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
> b/Documentation/devicetree/bindings/pci/ti-pci.txt
> index 60e2516..0b10e84 100644
> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
> @@ -1,7 +1,9 @@
>  TI PCI Controllers
>  
>  PCIe Designware Controller
> - - compatible: Should be "ti,dra7-pcie""
> + - compatible: "ti,dra7-pcie" is deprecated
> +Should be "ti,dra746-pcie" for DRA74x
> +Should be "ti,dra726-pcie" for DRA72x
>   - reg : Two register ranges as listed in the reg-names property
>   - reg-names : The first entry must be "ti-conf" for the TI specific 
> registers
>  The second entry must be "rc-dbics" for the designware pcie
> @@ -14,6 +16,10 @@ PCIe Designware Controller
>  where  is the instance number of the pcie from the HW spec.
>   - interrupts : Two interrupt entries must be specified. The first one is for
>   main interrupt line and the second for MSI interrupt line.
> + - syscon-lane-conf : phandle/offset pair. Phandle to the system control 
> module and the
> +   register offset to specify 1 lane or 2 lane.
> + - syscon-lane-sel : phandle/offset pair. Phandle to the system control 
> module and the
> +   register offset to specify lane selection.

These should have a ti prefix.

>   - #address-cells,
> #size-cells,
> #interrupt-cells,
--
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/1] regulator: max8973: add support for junction thermal warning

[Laxman Dewangan]

On Wednesday 06 January 2016 07:55 PM, Rob Herring wrote:

On Wed, Jan 06, 2016 at 12:37:35PM +, Mark Brown wrote:

On Wed, Jan 06, 2016 at 05:49:22PM +0530, Laxman Dewangan wrote:

On Wednesday 06 January 2016 05:48 PM, Mark Brown wrote:

* PGP Signed by an unknown key
On Wed, Jan 06, 2016 at 11:45:22AM +0530, Laxman Dewangan wrote:

  Enhanced transient response (ETR) will affect the configuration of CKADV.
+-maxim,junction-temp-warning: Junction temp warning on which device generates
+   warning interrupts.

This needs to specify what the values are - it looks like it's raw
register values but I'd have expected from this that it'd be an actual
temperature.

I tried to roundoff to the next higher threshold when supported value (120
or 140 degC) is not provided in driver. But it is fine to me to specify the
possible value setting here and DT binding doc. Will do on next patch.

I don't really mind which you use so long as the documentation is clear.

I prefer that degrees are used rather than register values.

From DT/platform, any values can be passed. Driver will round off to 
next higher side.

The document details will only provide what is supported by the PMIC device.
E.g. It can pass to ,<=120C and driver will set nearest threshold which 
is 120C.

If it is >120C then it will set to 140C.


--
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 v2 2/4] dt-bindings: i2c: mux: demux-pinctrl: add bindings

[Geert Uytterhoeven]

Hi Wolfram,

On Wed, Jan 6, 2016 at 2:51 PM, Wolfram Sang  wrote:
> These bindings allow an I2C bus to switch between multiple masters. This
> is not hot-swichting because connected I2C slaves will be
> re-instantiated. It is meant to select the best I2C core at runtime once
> the task is known. Example: Prefer i2c-gpio over another I2C core
> because of HW errata affetcing your use case.

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
> @@ -0,0 +1,155 @@

> +Here is a snipplet for a bus to be demuxed. It contains various i2c clients 
> for

snippet

> +HDMI, so the bus is named "i2c-hdmi":
> +
> +   i2chdmi: i2c@8 {

Would it make sense to call the node "i2c-bus@8"?
> +
> +   compatible = "i2c-demux-pinctrl";
> +   i2c-parent = <>, <>, <>;

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 1/4] extcon: arizona: Remove enable/disable of 32k clock

[Charles Keepax]

The 32k clock is unconditionally enabled by the MFD core so there is no
need to control it from the extcon device, so this patch removes the
control of the 32k clock.

Signed-off-by: Charles Keepax 
---

No changes since v1.

Thanks,
Charles

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

diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index e4890dd..52d041f 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1571,7 +1571,6 @@ static int arizona_extcon_probe(struct platform_device 
*pdev)
goto err_micdet;
}
 
-   arizona_clk32k_enable(arizona);
regmap_update_bits(arizona->regmap, ARIZONA_JACK_DETECT_DEBOUNCE,
   ARIZONA_JD1_DB, ARIZONA_JD1_DB);
regmap_update_bits(arizona->regmap, ARIZONA_JACK_DETECT_ANALOGUE,
@@ -1642,7 +1641,6 @@ static int arizona_extcon_remove(struct platform_device 
*pdev)
cancel_delayed_work_sync(>hpdet_work);
regmap_update_bits(arizona->regmap, ARIZONA_JACK_DETECT_ANALOGUE,
   ARIZONA_JD1_ENA, 0);
-   arizona_clk32k_disable(arizona);
 
return 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

[PATCH v2 3/4] mfd: arizona: Switch to using clock driver for 32k clock

[Charles Keepax]

Now we have a clock driver that can control the 32k clock use this
rather than directly controlling the 32k clock from the MFD device.

Signed-off-by: Charles Keepax 
---

Changes since v1:
 - No long select COMMON_CLK_ARIZONA from the MFD, this can lead
   to a situation where we are building COMMON_CLK_ARIZONA but
   not COMMON_CLK which leads to many build errors. Furthermore
   most other routes to resolve the issue result in a circular
   dependency. Simplest solution is just to not do the select.

Thanks,
Charles

 drivers/mfd/arizona-core.c   | 104 +--
 include/linux/mfd/arizona/core.h |   7 +--
 2 files changed, 25 insertions(+), 86 deletions(-)

diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index d474732..5a55dd6 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -36,63 +36,6 @@ static const char * const wm5102_core_supplies[] = {
"DBVDD1",
 };
 
-int arizona_clk32k_enable(struct arizona *arizona)
-{
-   int ret = 0;
-
-   mutex_lock(>clk_lock);
-
-   arizona->clk32k_ref++;
-
-   if (arizona->clk32k_ref == 1) {
-   switch (arizona->pdata.clk32k_src) {
-   case ARIZONA_32KZ_MCLK1:
-   ret = pm_runtime_get_sync(arizona->dev);
-   if (ret != 0)
-   goto out;
-   break;
-   }
-
-   ret = regmap_update_bits(arizona->regmap, ARIZONA_CLOCK_32K_1,
-ARIZONA_CLK_32K_ENA,
-ARIZONA_CLK_32K_ENA);
-   }
-
-out:
-   if (ret != 0)
-   arizona->clk32k_ref--;
-
-   mutex_unlock(>clk_lock);
-
-   return ret;
-}
-EXPORT_SYMBOL_GPL(arizona_clk32k_enable);
-
-int arizona_clk32k_disable(struct arizona *arizona)
-{
-   mutex_lock(>clk_lock);
-
-   BUG_ON(arizona->clk32k_ref <= 0);
-
-   arizona->clk32k_ref--;
-
-   if (arizona->clk32k_ref == 0) {
-   regmap_update_bits(arizona->regmap, ARIZONA_CLOCK_32K_1,
-  ARIZONA_CLK_32K_ENA, 0);
-
-   switch (arizona->pdata.clk32k_src) {
-   case ARIZONA_32KZ_MCLK1:
-   pm_runtime_put_sync(arizona->dev);
-   break;
-   }
-   }
-
-   mutex_unlock(>clk_lock);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(arizona_clk32k_disable);
-
 static irqreturn_t arizona_clkgen_err(int irq, void *data)
 {
struct arizona *arizona = data;
@@ -874,6 +817,7 @@ static inline int arizona_of_get_core_pdata(struct arizona 
*arizona)
 
 static const struct mfd_cell early_devs[] = {
{ .name = "arizona-ldo1" },
+   { .name = "arizona-clk" },
 };
 
 static const char * const wm5102_supplies[] = {
@@ -970,7 +914,6 @@ int arizona_dev_init(struct arizona *arizona)
int n_subdevs, ret, i;
 
dev_set_drvdata(arizona->dev, arizona);
-   mutex_init(>clk_lock);
 
if (dev_get_platdata(arizona->dev))
memcpy(>pdata, dev_get_platdata(arizona->dev),
@@ -1261,28 +1204,6 @@ int arizona_dev_init(struct arizona *arizona)
}
 
/* Chip default */
-   if (!arizona->pdata.clk32k_src)
-   arizona->pdata.clk32k_src = ARIZONA_32KZ_MCLK2;
-
-   switch (arizona->pdata.clk32k_src) {
-   case ARIZONA_32KZ_MCLK1:
-   case ARIZONA_32KZ_MCLK2:
-   regmap_update_bits(arizona->regmap, ARIZONA_CLOCK_32K_1,
-  ARIZONA_CLK_32K_SRC_MASK,
-  arizona->pdata.clk32k_src - 1);
-   arizona_clk32k_enable(arizona);
-   break;
-   case ARIZONA_32KZ_NONE:
-   regmap_update_bits(arizona->regmap, ARIZONA_CLOCK_32K_1,
-  ARIZONA_CLK_32K_SRC_MASK, 2);
-   break;
-   default:
-   dev_err(arizona->dev, "Invalid 32kHz clock source: %d\n",
-   arizona->pdata.clk32k_src);
-   ret = -EINVAL;
-   goto err_reset;
-   }
-
for (i = 0; i < ARIZONA_MAX_MICBIAS; i++) {
if (!arizona->pdata.micbias[i].mV &&
!arizona->pdata.micbias[i].bypass)
@@ -1387,10 +1308,25 @@ int arizona_dev_init(struct arizona *arizona)
pm_runtime_set_active(arizona->dev);
pm_runtime_enable(arizona->dev);
 
+   arizona->clk32k = devm_clk_get(arizona->dev, "arizona-32k");
+   if (IS_ERR(arizona->clk32k)) {
+   ret = PTR_ERR(arizona->clk32k);
+   if (ret == -ENOENT)
+   ret = -EPROBE_DEFER;
+   dev_err(arizona->dev, "Failed to get 32k clock: %d\n", ret);
+   goto err_pm;
+   }
+
+   ret = clk_prepare_enable(arizona->clk32k);
+   if (ret < 0) {
+   dev_err(arizona->dev, "Failed to enable 32k clock: 

[PATCH v2 4/4] mfd: arizona: Add device tree binding documentation for new clock driver

[Charles Keepax]

Specify the device tree binding for the input clocks to Arizona devices.

Signed-off-by: Charles Keepax 
---

No changes since v1.

Thanks,
Charles

 Documentation/devicetree/bindings/mfd/arizona.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
b/Documentation/devicetree/bindings/mfd/arizona.txt
index 18be0cb..39f76f8 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -45,6 +45,13 @@ Optional properties:
 
   - wlf,reset : GPIO specifier for the GPIO controlling /RESET
 
+  - clocks: Should reference the clocks supplied on MCLK1 and MCLK2
+  - clock-names: Should contains two strings:
+  "mclk1" for the clock supplied on MCLK1, recommended to be a high
+  quality audio reference clock
+  "mclk2" for the clock supplied on MCLK2, recommended to be an always on
+  32k clock
+
   - wlf,gpio-defaults : A list of GPIO configuration register values. Defines
 for the appropriate values can found in . If
 absent, no configuration of these registers is performed. If any entry has
-- 
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 v1 3/3] ARM64 LPC: update binding doc

[Rongrong Zou]

在 2016/1/5 20:19, Arnd Bergmann 写道:

On Tuesday 05 January 2016 19:59:49 Rongrong Zou wrote:

在 2016/1/5 0:34, Arnd Bergmann 写道:

On Tuesday 05 January 2016 00:04:19 Rongrong Zou wrote:

在 2016/1/4 19:13, Arnd Bergmann 写道:

On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote:

在 2015/12/31 23:00, Rongrong Zou 写道:

Ranges property can set empty, but this means 1:1 translation. the I/O
port range is translated to MMIO address 0x0001  to
0x0001 0004, it looks wrong else. I wonder if anyone get legacy
I/O port resource from dts.


As I said, nothing should really require the ranges property here, unless
you have a valid IORESOURCE_MEM translation. The code that requires
the ranges to be present is wrong.



I think the openfirmware(DT) do not support for those unmapped I/O ports, 
because I
must get resource by calling of_address_to_resource(), which have to call
pci_address_to_pio() when resource type is IORESOURCE_IO. I'm sorry I have no
better idea for this now. Maybe liviu can give me some opinions.


I think on x86 it works (or used to work, few people use open firmware on
x86 these days, and it may be broken), and the pci_address_to_pio() call
behaves differently when PCI_IOBASE is set. x86 never maps I/O ports into
memory mapped I/O addresses, they have their own way of accessing them
just like your platform.


/**
   * of_address_to_resource - Translate device tree address and return as 
resource
   *
   * Note that if your address is a PIO address, the conversion will fail if
   * the physical address can't be internally converted to an IO token with
   * pci_address_to_pio(), that is because it's either called to early or it
   * can't be matched to any host bridge IO space
   */
int of_address_to_resource(struct device_node *dev, int index,
   struct resource *r)


The problem here seems to be that the code assumes that either the I/O ports
are always mapped or they are never mapped (no PCI_IOBASE). We need to extend
it because now we can have the combination of the two.



I am considering the following solution:

Adding unmapped isa io functions in

drivers/of/address.c,

static LIST_HEAD(legacy_io_range_list);
int isa_register_io_range(phys_addr_t addr, resource_size_t size);

/* before I call isa(LPC) bus driver, the input I/O port must be translated to 
phys_addr_t
(the least 16bit means port addr on bus, the second 16bit means bus id)*/

phys_addr_t isa_pio_to_bus_addr(unsigned long pio);

/* the returned PIO do not conflict with PIO get from pci_address_to_pio*/
unsigned long isa_bus_addr_to_pio(phys_addr_t address);

drivers/bus/lpc.c

lpc_bus_probe()
{
isa_register_io_range(phys_addr_t addr, resource_size_t size);
}

inb(unsigned long port)
{
unsigned short bus;
phys_addr_t addr;
/*hit isa port range*/
if(addr = isa_pio_to_bus_addr(port))
{
bus = (addr >> 16) & 0x;

call lpc driver with addr;
return lpc_read_byte(bus, addr);
}
else /*not hit*/
{
return readb(PCI_IOBASE + port);
}
}






For ipmi driver, I can get I/O port resource by DMI rather than dts.


No, the ipmi driver uses the resource that belongs to the platform
device already, you can't rely on DMI data to be present there.


Ipmi has a lot of way to be discovered(ACPI, DMI, hardcoded, hot-add,
openfirmware and a few other), I think we just use one of them, not all of them.
It depend on vendor's hardware solution actually.


I don't think we should mix multiple methods here: if the bus is described
in DT, all its children should be there as well. Otherwise you get into problems
e.g. if you have multiple instances of the LPC bus and the Linux I/O addresses
for one or more of them have an offset to the bus specific addresses.

The bus probe code decides what the Linux I/O port numbers are, but DMI
and other methods have no idea of the mapping. As long as there is only
one instance, using the first 0x1000 addresses with a 1:1 mapping saves
us a bit of trouble, but I'd be worried about relying on that assumption
too much.

Arnd


.



Thanks,

Rongrong

--
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

[RFC v2 3/4] i2c: mux: demux-pinctrl: add driver

[Wolfram Sang]

From: Wolfram Sang 

This driver allows an I2C bus to switch between multiple masters. This
is not hot-swichting because connected I2C slaves will be
re-instantiated. It is meant to select the best I2C core at runtime once
the task is known. Example: Prefer i2c-gpio over another I2C core
because of HW errata affetcing your use case.

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/muxes/Kconfig |   9 ++
 drivers/i2c/muxes/Makefile|   2 +
 drivers/i2c/muxes/i2c-demux-pinctrl.c | 276 ++
 3 files changed, 287 insertions(+)
 create mode 100644 drivers/i2c/muxes/i2c-demux-pinctrl.c

diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index f06b0e24673b87..7b5da5ff7b16f9 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -72,4 +72,13 @@ config I2C_MUX_REG
  This driver can also be built as a module.  If so, the module
  will be called i2c-mux-reg.
 
+config I2C_DEMUX_PINCTRL
+   tristate "pinctrl-based I2C demultiplexer"
+   depends on PINCTRL
+   select OF_DYNAMIC
+   help
+ If you say yes to this option, support will be included for an I2C
+ demultiplexer that uses the pinctrl subsystem. This is useful if you
+ want to change the I2C master at run-time depending on features.
+
 endmenu
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index e89799b76a9280..7c267c29b19196 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -3,6 +3,8 @@
 
 obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE)   += i2c-arb-gpio-challenge.o
 
+obj-$(CONFIG_I2C_DEMUX_PINCTRL)+= i2c-demux-pinctrl.o
+
 obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
 obj-$(CONFIG_I2C_MUX_PCA9541)  += i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)  += i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-demux-pinctrl.c 
b/drivers/i2c/muxes/i2c-demux-pinctrl.c
new file mode 100644
index 00..5ec2779b176432
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-demux-pinctrl.c
@@ -0,0 +1,276 @@
+/*
+ * Pinctrl based I2C DeMultiplexer
+ *
+ * Copyright (C) 2015-16 by Wolfram Sang, Sang Engineering 

+ * Copyright (C) 2015-16 by 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.
+ *
+ * See the bindings doc for DTS setup.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct i2c_demux_pinctrl_chan {
+   struct device_node *parent_np;
+   struct i2c_adapter *parent_adap;
+   struct of_changeset chgset;
+};
+
+struct i2c_demux_pinctrl_priv {
+   int cur_chan;
+   int num_chan;
+   struct device *dev;
+   const char *bus_name;
+   struct i2c_adapter cur_adap;
+   struct i2c_algorithm algo;
+   struct i2c_demux_pinctrl_chan chan[];
+};
+
+static struct property status_okay = { .name = "status", .length = 3, .value = 
"ok" };
+
+static int i2c_demux_master_xfer(struct i2c_adapter *adap, struct i2c_msg 
msgs[], int num)
+{
+   struct i2c_demux_pinctrl_priv *priv = adap->algo_data;
+   struct i2c_adapter *parent = priv->chan[priv->cur_chan].parent_adap;
+
+   return __i2c_transfer(parent, msgs, num);
+}
+
+static u32 i2c_demux_functionality(struct i2c_adapter *adap)
+{
+   struct i2c_demux_pinctrl_priv *priv = adap->algo_data;
+   struct i2c_adapter *parent = priv->chan[priv->cur_chan].parent_adap;
+
+   return parent->algo->functionality(parent);
+}
+
+static int i2c_demux_activate_master(struct i2c_demux_pinctrl_priv *priv, u32 
new_chan)
+{
+   struct i2c_adapter *adap;
+   struct pinctrl *p;
+   int ret;
+
+   mutex_lock(_mutex);
+   ret = of_changeset_apply(>chan[new_chan].chgset);
+   mutex_unlock(_mutex);
+   if (ret)
+   goto err;
+
+   adap = of_find_i2c_adapter_by_node(priv->chan[new_chan].parent_np);
+   if (!adap) {
+   ret = -ENODEV;
+   goto err;
+   }
+
+   p = devm_pinctrl_get_select(adap->dev.parent, priv->bus_name);
+   if (IS_ERR(p)) {
+   ret = PTR_ERR(p);
+   goto err_with_put;
+   }
+
+   priv->chan[new_chan].parent_adap = adap;
+   priv->cur_chan = new_chan;
+
+   /* Now fill out current adapter structure. cur_chan must be up to date 
*/
+   priv->algo.master_xfer = i2c_demux_master_xfer;
+   priv->algo.functionality = i2c_demux_functionality;
+
+   snprintf(priv->cur_adap.name, sizeof(priv->cur_adap.name),
+"i2c-demux (master i2c-%d)", i2c_adapter_id(adap));
+   priv->cur_adap.owner = THIS_MODULE;
+   priv->cur_adap.algo = >algo;
+   priv->cur_adap.algo_data = priv;
+   

Re: [PATCH v4 2/3] ARM: dts: sun8i: Add Allwinner A83T dtsi

[Maxime Ripard]

Hi Mark,

On Wed, Jan 06, 2016 at 01:25:05PM +, Mark Rutland wrote:
> > +   clocks {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   ranges;
> > +
> > +   osc24M: osc24M_clk {
> > +   #clock-cells = <0>;
> > +   compatible = "fixed-clock";
> > +   clock-frequency = <2400>;
> > +   clock-output-names = "osc24M";
> > +   };
> > +
> > +   osc32k: osc32k_clk {
> > +   #clock-cells = <0>;
> > +   compatible = "fixed-clock";
> > +   clock-frequency = <32768>;
> > +   clock-output-names = "osc32k";
> > +   };
> > +   };
> 
> Just put the clocks under the root node. 'clocks' is not a special
> node.

No, it's not a special node, but it's a very convenient one. It avoids
"crippling" the main SoC definition with all the clocks definition,
and keep the noise relatively low.

And a bunch of other maintainers seem to agree:
$ git grep "clocks {"  -- arch/arm/boot/dts/ arch/arm64/boot/dts/ | wc -l
271

Maxime

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


signature.asc
Description: Digital signature

Re: [RFC v2 3/4] i2c: mux: demux-pinctrl: add driver

[Geert Uytterhoeven]

Hi Wolfram,

On Wed, Jan 6, 2016 at 2:51 PM, Wolfram Sang  wrote:
> From: Wolfram Sang 
>
> This driver allows an I2C bus to switch between multiple masters. This
> is not hot-swichting because connected I2C slaves will be

switching

> re-instantiated. It is meant to select the best I2C core at runtime once
> the task is known. Example: Prefer i2c-gpio over another I2C core
> because of HW errata affetcing your use case.

affecting

> --- /dev/null
> +++ b/drivers/i2c/muxes/i2c-demux-pinctrl.c
> @@ -0,0 +1,276 @@
> +/*
> + * Pinctrl based I2C DeMultiplexer
> + *
> + * Copyright (C) 2015-16 by Wolfram Sang, Sang Engineering 
> 
> + * Copyright (C) 2015-16 by 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.
> + *
> + * See the bindings doc for DTS setup.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct i2c_demux_pinctrl_chan {
> +   struct device_node *parent_np;
> +   struct i2c_adapter *parent_adap;
> +   struct of_changeset chgset;
> +};
> +
> +struct i2c_demux_pinctrl_priv {
> +   int cur_chan;
> +   int num_chan;

This is always positive, so you can make num_chan and a few loop counters
unsigned.

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 1/1] regulator: max8973: add support for junction thermal warning

[Rob Herring]

On Wed, Jan 06, 2016 at 12:37:35PM +, Mark Brown wrote:
> On Wed, Jan 06, 2016 at 05:49:22PM +0530, Laxman Dewangan wrote:
> > On Wednesday 06 January 2016 05:48 PM, Mark Brown wrote:
> > >* PGP Signed by an unknown key
> 
> > >On Wed, Jan 06, 2016 at 11:45:22AM +0530, Laxman Dewangan wrote:
> 
> > >>  Enhanced transient response (ETR) will affect the configuration of 
> > >> CKADV.
> > >>+-maxim,junction-temp-warning: Junction temp warning on which device 
> > >>generates
> > >>+ warning interrupts.
> > >This needs to specify what the values are - it looks like it's raw
> > >register values but I'd have expected from this that it'd be an actual
> > >temperature.
> 
> > I tried to roundoff to the next higher threshold when supported value (120
> > or 140 degC) is not provided in driver. But it is fine to me to specify the
> > possible value setting here and DT binding doc. Will do on next patch.
> 
> I don't really mind which you use so long as the documentation is clear.

I prefer that degrees are used rather than register values.

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/1] regulator: max8973: add support for junction thermal warning

[Mark Brown]

On Wed, Jan 06, 2016 at 11:45:22AM +0530, Laxman Dewangan wrote:

>  Enhanced transient response (ETR) will affect the configuration of CKADV.
> +-maxim,junction-temp-warning: Junction temp warning on which device generates
> + warning interrupts.

This needs to specify what the values are - it looks like it's raw
register values but I'd have expected from this that it'd be an actual
temperature.

> +-interrupt-flags: Interrupt flags for registering interrupt which can not be
> + passed via interrupt properties.

Why is this being specified and what are the values?  Most devices don't
have this...


signature.asc
Description: PGP signature

[PATCH v4 3/3] ARM: dts: sun8i: Add A83T HomletV2 Board by Allwinner

[Vishnu Patekar]

H8Homlet Proto v2.0 Board is A83T Dev Board by Allwinner.
It has UART, ethernet, USB, HDMI, etc ports on it.

A83T patches are tested on this board.
It has UART, ethernet, USB, HDMI, etc ports on it.

For FEL mode it needs USB A-A(Male) cable. I used uart0 which
is multiplexed to microsd pins PF2 and PF4.

Enabled UART0 Header(PB9, PB10 pins).

Signed-off-by: Vishnu Patekar 
---
 arch/arm/boot/dts/Makefile |  1 +
 .../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts  | 64 ++
 2 files changed, 65 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cc7309b..0f81c58 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -662,6 +662,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-ippo-q8h-v1.2.dtb \
sun8i-a33-q8-tablet.dtb \
sun8i-a33-sinlinx-sina33.dtb \
+   sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-h3-orangepi-plus.dtb
 dtb-$(CONFIG_MACH_SUN9I) += \
sun9i-a80-optimus.dtb \
diff --git a/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts 
b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
new file mode 100644
index 000..342e1d3
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
@@ -0,0 +1,64 @@
+/*
+ * Copyright 2015 Vishnu Patekar
+ * Vishnu Patekar 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a83t.dtsi"
+
+/ {
+   model = "Allwinner A83T H8Homlet Proto Dev Board v2.0";
+   compatible = "allwinner,h8homlet-v2", "allwinner,sun8i-a83t";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_b>;
+   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 v4 1/3] ARM: sunxi: Introduce Allwinner for A83T support

[Vishnu Patekar]

Allwinner A83T is octa-core cortex-a7 based SoC.
It's clock control unit and prcm, pinmux are different from previous sun8i
series.
Its processor cores are arragned in two clusters 4 cores each,
similar to A80.

Signed-off-by: Vishnu Patekar 
Acked-by: Rob Herring 
Acked-by: Chen-Yu Tsai 
---
 Documentation/arm/sunxi/README  | 1 -
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 arch/arm/mach-sunxi/sunxi.c | 1 +
 drivers/clk/sunxi/clk-sunxi.c   | 6 ++
 4 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index 430d279..e5a115f 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -72,6 +72,5 @@ SunXi family
 
 * Octa ARM Cortex-A7 based SoCs
   - Allwinner A83T
-+ Not Supported
 + Datasheet
   http://dl.linux-sunxi.org/A83T/A83T_datasheet_Revision_1.1.pdf
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt
index bb9b0faa..7e79fcc 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -11,5 +11,6 @@ using one of the following compatible strings:
   allwinner,sun7i-a20
   allwinner,sun8i-a23
   allwinner,sun8i-a33
+  allwinner,sun8i-a83t
   allwinner,sun8i-h3
   allwinner,sun9i-a80
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index c2be98f..3c15619 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -69,6 +69,7 @@ MACHINE_END
 static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-a23",
"allwinner,sun8i-a33",
+   "allwinner,sun8i-a83t",
"allwinner,sun8i-h3",
NULL,
 };
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 5ba2188..0d45253 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -1219,6 +1219,12 @@ CLK_OF_DECLARE(sun8i_a23_clk_init, 
"allwinner,sun8i-a23", sun6i_init_clocks);
 CLK_OF_DECLARE(sun8i_a33_clk_init, "allwinner,sun8i-a33", sun6i_init_clocks);
 CLK_OF_DECLARE(sun8i_h3_clk_init, "allwinner,sun8i-h3", sun6i_init_clocks);
 
+static void __init sun8i_a83t_init_clocks(struct device_node *node)
+{
+   sunxi_init_clocks(NULL, 0);
+}
+CLK_OF_DECLARE(sun8i_a83t_clk_init, "allwinner,sun8i-a83t", 
sun8i_a83t_init_clocks);
+
 static void __init sun9i_init_clocks(struct device_node *node)
 {
sunxi_init_clocks(NULL, 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 v4 2/3] ARM: dts: sun8i: Add Allwinner A83T dtsi

[Vishnu Patekar]

Allwinner A83T is new octa-core cortex-a7 SOC.
This adds the basic dtsi, the clocks differs from
earlier sun8i SOCs.

Signed-off-by: Vishnu Patekar 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 204 ++
 1 file changed, 204 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-a83t.dtsi

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
new file mode 100644
index 000..90cc09b
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -0,0 +1,204 @@
+/*
+ * Copyright 2015 Vishnu Patekar
+ *
+ * Vishnu Patekar 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+
+ */
+
+#include "skeleton.dtsi"
+
+#include 
+
+#include 
+
+/ {
+   interrupt-parent = <>;
+
+   chosen {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <0>;
+   };
+
+   cpu@1 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <1>;
+   };
+
+   cpu@2 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <2>;
+   };
+
+   cpu@3 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <3>;
+   };
+
+   cpu@100 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <0x100>;
+   };
+
+   cpu@101 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <0x101>;
+   };
+
+   cpu@102 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <0x102>;
+   };
+
+   cpu@103 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <0x103>;
+   };
+   };
+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupts = ,
+,
+,
+;
+   };
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   osc24M: osc24M_clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   clock-output-names = "osc24M";
+   };
+
+   osc32k: 

Re: [PATCH v2 0/8] i2c mux cleanup and locking update

[Crt Mori]

Hi Wolfram and Peter,
I will give my opinion about the path chosen although it should be
taken lightly.

I can see that hardware guys missed the software guys again on the
development path, but since this happens more often than not, I would
say it seems OK to have support for this as long as it does not make
more complex (longer) standard i2c transfers. I would support to have
additional mutex before mux as that will make less chance that someone
forgets to lock mutex before mux and proposed solution seems valid.

Regards,
Crt

On 5 January 2016 at 19:48, Wolfram Sang  wrote:
> Peter,
>
>> PS. needs a bunch of testing, I do not have access to all the involved hw
>
> First of all, thanks for diving into this topic and the huge effort you
> apparently have put into it.
>
> It is obviously a quite intrusive series, so it needs careful review.
> TBH, I can't really tell when I have the bandwidth to do that, so I hope
> other people will step up. And yes, it needs serious testing.
>
> To all: Although I appreciate any review support, I'd think the first
> thing to be done should be a very high level review - is this series
> worth the huge update? Is the path chosen proper? Stuff like this. I'd
> appreciate Acks or Revs for that. Stuff like fixing checkpatch warnings
> and other minor stuff should come later.
>
> Thanks,
>
>Wolfram
>
--
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

[RFC v2 4/4] ARM: shmobile: r8a7790: rework dts to use i2c demuxer

[Wolfram Sang]

From: Wolfram Sang 

Create a seperate bus for HDMI related I2C slaves and assign it
to a i2c-gpio master. It can be switched to the i2c-rcar or
i2c-sh_mobile core at runtime.

Signed-off-by: Wolfram Sang 
---
 arch/arm/boot/dts/r8a7790-lager.dts | 141 ++--
 1 file changed, 88 insertions(+), 53 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index c553abd711eeb3..d8f0ca8e094dad 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -49,6 +49,8 @@
aliases {
serial0 = 
serial1 = 
+   i2c8 = 
+   i2c9 = 
};
 
chosen {
@@ -252,6 +254,79 @@
#clock-cells = <0>;
clock-frequency = <14850>;
};
+
+
+   gpioi2c: i2c@9 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "i2c-gpio";
+   status = "disabled";
+   gpios = < 6 GPIO_ACTIVE_HIGH /* sda */
+ 5 GPIO_ACTIVE_HIGH /* scl */
+   >;
+   i2c-gpio,delay-us = <5>;
+   };
+
+   i2chdmi: i2c@8 {
+
+   compatible = "i2c-demux-pinctrl";
+   i2c-parent = <>, <>, <>;
+   i2c-bus-name = "i2c-hdmi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ak4643: sound-codec@12 {
+   compatible = "asahi-kasei,ak4643";
+
+   #sound-dai-cells = <0>;
+   reg = <0x12>;
+   };
+
+   composite-in@20 {
+   compatible = "adi,adv7180";
+   reg = <0x20>;
+   remote = <>;
+
+   port {
+   adv7180: endpoint {
+   bus-width = <8>;
+   remote-endpoint = <>;
+   };
+   };
+   };
+
+   hdmi@39 {
+   compatible = "adi,adv7511w";
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+   adi,input-style = <1>;
+   adi,input-justification = "evenly";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   adv7511_in: endpoint {
+   remote-endpoint = 
<_out_lvds0>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   adv7511_out: endpoint {
+   remote-endpoint = <_con>;
+   };
+   };
+   };
+   };
+   };
 };
 
  {
@@ -352,6 +427,11 @@
renesas,function = "iic1";
};
 
+   i2c2_pins: i2c2 {
+   renesas,groups = "i2c2";
+   renesas,function = "i2c2";
+   };
+
iic2_pins: iic2 {
renesas,groups = "iic2";
renesas,function = "iic2";
@@ -532,63 +612,18 @@
pinctrl-names = "default";
 };
 
-  {
-   status = "okay";
-   pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+  {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "i2c-hdmi";
 
clock-frequency = <10>;
+};
 
-   ak4643: codec@12 {
-   compatible = "asahi-kasei,ak4643";
-   #sound-dai-cells = <0>;
-   reg = <0x12>;
-   };
-
-   composite-in@20 {
-   compatible = "adi,adv7180";
-   reg = <0x20>;
-   remote = <>;
-
-   port {
-   adv7180: endpoint {
-   bus-width = <8>;
-   remote-endpoint = <>;
-   };
-   };
-   };
-
-   hdmi@39 {
-   compatible = "adi,adv7511w";
-   reg = <0x39>;
-   interrupt-parent = <>;
-   interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
-
-   adi,input-depth = <8>;
-   adi,input-colorspace = "rgb";
-   adi,input-clock = "1x";
-   adi,input-style = <1>;
-   adi,input-justification = "evenly";
-
- 

[RFC v2 2/4] dt-bindings: i2c: mux: demux-pinctrl: add bindings

[Wolfram Sang]

From: Wolfram Sang 

These bindings allow an I2C bus to switch between multiple masters. This
is not hot-swichting because connected I2C slaves will be
re-instantiated. It is meant to select the best I2C core at runtime once
the task is known. Example: Prefer i2c-gpio over another I2C core
because of HW errata affetcing your use case.

Signed-off-by: Wolfram Sang 
---
 .../devicetree/bindings/i2c/i2c-demux-pinctrl.txt  | 155 +
 1 file changed, 155 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt 
b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
new file mode 100644
index 00..de571be68f4754
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
@@ -0,0 +1,155 @@
+Pinctrl-based I2C Bus DeMux
+
+This binding describes an I2C bus demultiplexer that uses pin multiplexing to
+route the I2C signals, and represents the pin multiplexing configuration using
+the pinctrl device tree bindings. This may be used to select one I2C IP core at
+runtime which may have a better feature set for a given task than another I2C
+IP core on the SoC. The most simple example is to fall back to GPIO bitbanging
+if your current runtime configuration hits an errata of the internal IP core.
+
++---+
+| SoC   |
+|   |   +-+  +-+
+|   ++  |   | dev |  | dev |
+|   |I2C IP Core1|--\   |   +-+  +-+
+|   ++   \---+  |  ||
+||Pinctrl|--|--++
+|   ++   +---+  |
+|   |I2C IP Core2|--/   |
+|   ++  |
+|   |
++---+
+
+Required properties:
+- compatible: "i2c-demux-pinctrl"
+- i2c-parent: List of phandles of I2C masters available for selection. The 
first
+ one will be used as default.
+- i2c-bus-name: The name of this bus. Also needed as pinctrl-name for the I2C
+   parents.
+
+Furthermore, I2C mux properties and child nodes. See mux.txt in this directory.
+
+Example:
+
+Here is a snipplet for a bus to be demuxed. It contains various i2c clients for
+HDMI, so the bus is named "i2c-hdmi":
+
+   i2chdmi: i2c@8 {
+
+   compatible = "i2c-demux-pinctrl";
+   i2c-parent = <>, <>, <>;
+   i2c-bus-name = "i2c-hdmi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ak4643: sound-codec@12 {
+   compatible = "asahi-kasei,ak4643";
+
+   #sound-dai-cells = <0>;
+   reg = <0x12>;
+   };
+
+   composite-in@20 {
+   compatible = "adi,adv7180";
+   reg = <0x20>;
+   remote = <>;
+
+   port {
+   adv7180: endpoint {
+   bus-width = <8>;
+   remote-endpoint = <>;
+   };
+   };
+   };
+
+   hdmi@39 {
+   compatible = "adi,adv7511w";
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+   adi,input-style = <1>;
+   adi,input-justification = "evenly";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   adv7511_in: endpoint {
+   remote-endpoint = 
<_out_lvds0>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   adv7511_out: endpoint {
+   remote-endpoint = <_con>;
+   };
+   };
+   };
+   };
+   };
+
+And for clarification, here are the snipplets for the i2c-parents:
+
+   gpioi2c: i2c@9 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "i2c-gpio";
+   status = "disabled";
+   gpios = < 6 GPIO_ACTIVE_HIGH /*