* Re: [PATCH 3/4] dt-bindings: Update domain-idle-state binding to use correct compatibles
From: Sudeep Holla @ 2016-10-26 8:57 UTC (permalink / raw)
To: Kevin Hilman, Lina Iyer
Cc: devicetree, ulf.hansson, lorenzo.pieralisi, Juri.Lelli, linux-pm,
sboyd, linux-arm-msm, rjw, brendan.jackman, Sudeep Holla,
andy.gross, linux-arm-kernel
In-Reply-To: <7hh980taqp.fsf@baylibre.com>
On 25/10/16 21:49, Kevin Hilman wrote:
> Lina Iyer <lina.iyer@linaro.org> writes:
>
>> Update domain-idle-state binding to use "domain-idle-state" compatible
>> from Documentation/devicetree/bindings/arm/idle-states.txt.
>>
>> Cc: <devicetree@vger.kernel.org>
>> Cc: Rob Herring <robh@kernel.org>
>> Suggested-by: Sudeep Holla <sudeep.holla@arm.com>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> ---
>> Documentation/devicetree/bindings/power/power_domain.txt | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> With no current users for this, I don't see the point of adding a
> compatible now.
>
> IMO, this should wait and be added with the identified user we can
> discuss it then.
>
No, IMO it needs to be used for the proposed SoC idle/genpd solution.
I understand the nodes that are "arm,idle-state" compatible can be used
for this new SoC hierarchical idle management, but it was never defined
for that use originally. So this new feature must be advertised by the
firmware with the presence of "domain-idle-state".
Yes we might have other ways to detect that but I have already seen that
broken on the reference platform, so we need alternate/DT way to specify
that.
Not all existing "arm,idle-state" compatible nodes will be capable of
supporting this new SoC idle feature. It's just better and safer for a
new feature getting added that relies on DT to have a new compatible.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v3] drm/mediatek: fixed the calc method of data rate per lane
From: Jitao Shi @ 2016-10-26 8:59 UTC (permalink / raw)
To: Philipp Zabel, ck.hu, Matthias Brugger
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Jitao Shi, Ajay Kumar, Inki Dae, Rahul Sharma, Sean Paul,
Vincent Palatin, Andy Yan, Russell King, devicetree, linux-kernel,
dri-devel, linux-arm-kernel, linux-mediatek, srv_heupstream,
Sascha Hauer, yingjoe.chen
Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
signal will cause h-time larger than normal and reduce FPS.
Need to multiply a coefficient to offset the extra signal's effect.
coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
Ths_exit)/(htotal*bpp/lane_number))
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
Change since v2:
- move phy timing back to dsi_phy_timconfig.
Change since v1:
- phy_timing2 and phy_timing3 refer clock cycle time.
- define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 74 +++++++++++++++++++++++++-----------
1 file changed, 51 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 28b2044..8b3b38a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -85,16 +85,16 @@
#define LD0_WAKEUP_EN BIT(2)
#define DSI_PHY_TIMECON0 0x110
-#define LPX (0xff << 0)
-#define HS_PRPR (0xff << 8)
-#define HS_ZERO (0xff << 16)
-#define HS_TRAIL (0xff << 24)
+#define LPX (5 << 0)
+#define HS_PRPR (6 << 8)
+#define HS_ZERO (10 << 16)
+#define HS_TRAIL (8 << 24)
#define DSI_PHY_TIMECON1 0x114
-#define TA_GO (0xff << 0)
-#define TA_SURE (0xff << 8)
-#define TA_GET (0xff << 16)
-#define DA_HS_EXIT (0xff << 24)
+#define TA_GO (20 << 0)
+#define TA_SURE (7 << 8)
+#define TA_GET (25 << 16)
+#define DA_HS_EXIT (7 << 24)
#define DSI_PHY_TIMECON2 0x118
#define CONT_DET (0xff << 0)
@@ -161,20 +161,18 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, u32 mask, u32 data)
static void dsi_phy_timconfig(struct mtk_dsi *dsi)
{
u32 timcon0, timcon1, timcon2, timcon3;
- unsigned int ui, cycle_time;
- unsigned int lpx;
+ u32 ui, cycle_time;
ui = 1000 / dsi->data_rate + 0x01;
cycle_time = 8000 / dsi->data_rate + 0x01;
- lpx = 5;
- timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
- timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
- (4 * lpx);
+ timcon0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
+ timcon1 = 4 * LPX | (3 * LPX / 2) << 8 | 5 * LPX << 16 | DA_HS_EXIT;
timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
- (NS_TO_CYCLE(0x150, cycle_time) << 16);
- timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
- NS_TO_CYCLE(0x40, cycle_time);
+ (NS_TO_CYCLE(0x150, cycle_time) << 16);
+ timcon3 = (2 * LPX) << 16 |
+ NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
+ NS_TO_CYCLE(0x40, cycle_time);
writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
@@ -202,19 +200,49 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
{
struct device *dev = dsi->dev;
int ret;
+ u64 bit_clock, total_bits;
+ u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
if (++dsi->refcount != 1)
return 0;
+ switch (dsi->format) {
+ case MIPI_DSI_FMT_RGB565:
+ bit_per_pixel = 16;
+ break;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ bit_per_pixel = 18;
+ break;
+ case MIPI_DSI_FMT_RGB666:
+ case MIPI_DSI_FMT_RGB888:
+ default:
+ bit_per_pixel = 24;
+ break;
+ }
/**
- * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
- * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
- * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
- * we set mipi_ratio is 1.05.
+ * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
+ * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
+ * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
+ * + Thstrail + Ths_exit + Ths_zero) /
+ * (htotal * byte_per_pixel /lane_number)
*/
- dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
+ bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
+ htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
+ dsi->vm.hsync_len;
+ htotal_bits = htotal * bit_per_pixel;
+
+ /**
+ * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
+ */
+ overhead_cycles = LPX + (HS_PRPR >> 8) + (HS_ZERO >> 16) +
+ (HS_TRAIL >> 24) + (DA_HS_EXIT >> 24);
+ overhead_bits = overhead_cycles * dsi->lanes * 8;
+ total_bits = htotal_bits + overhead_bits;
+
+ dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
+ htotal_bits * dsi->lanes);
- ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
+ ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
if (ret < 0) {
dev_err(dev, "Failed to set data rate: %d\n", ret);
goto err_refcount;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2] drm/mediatek: fixed the calc method of data rate per lane
From: Jitao Shi @ 2016-10-26 9:07 UTC (permalink / raw)
To: CK Hu
Cc: Mark Rutland, stonea168, dri-devel, Andy Yan, Ajay Kumar,
Vincent Palatin, cawa.cheng, Russell King, devicetree, Pawel Moll,
Ian Campbell, Rob Herring, linux-mediatek, yingjoe.chen,
Matthias Brugger, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Kumar Gala
In-Reply-To: <1477464081.17405.2.camel@mtksdaap41>
On Wed, 2016-10-26 at 14:41 +0800, CK Hu wrote:
> Hi, Jitao:
>
> On Tue, 2016-10-25 at 13:40 +0800, Jitao Shi wrote:
> > Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
> > Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
> > signal will cause h-time larger than normal and reduce FPS.
> > Need to multiply a coefficient to offset the extra signal's effect.
> > coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
> > Ths_exit)/(htotal*bpp/lane_number))
> >
> > Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> > ---
> > Change since v1:
> > - phy_timing2 and phy_timing3 refer clock cycle time.
> > - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT
> > ---
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 103 +++++++++++++++++++++++-------------
> > 1 file changed, 67 insertions(+), 36 deletions(-)
> >
>
> [snip...]
>
> >
> > -static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> > +static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
> > + u32 phy_timing1, u32 phy_timing2,
> > + u32 phy_timing3)
> > {
> > - u32 timcon0, timcon1, timcon2, timcon3;
> > - unsigned int ui, cycle_time;
> > - unsigned int lpx;
> > -
> > - ui = 1000 / dsi->data_rate + 0x01;
> > - cycle_time = 8000 / dsi->data_rate + 0x01;
> > - lpx = 5;
> > -
> > - timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
> > - timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
> > - (4 * lpx);
> > - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> > - (NS_TO_CYCLE(0x150, cycle_time) << 16);
> > - timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> > - NS_TO_CYCLE(0x40, cycle_time);
> > -
> > - writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> > - writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> > - writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
> > - writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
>
> Why do you move these calculation to mtk_dsi_poweron()? You can keep
> calculation here and just do some modification.
>
> Regards,
> CK
Thanks for your review. I'll fix it in next patchset.
Best Regards
jitao
>
> > + writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
> > + writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
> > + writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
> > + writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
> > }
> >
> > static void mtk_dsi_enable(struct mtk_dsi *dsi)
> > @@ -202,19 +188,51 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> > {
> > struct device *dev = dsi->dev;
> > int ret;
> > + u64 bit_clock, total_bits;
> > + u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
> > + u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;
> > + u32 ui, cycle_time;
> >
> > if (++dsi->refcount != 1)
> > return 0;
> >
> > + switch (dsi->format) {
> > + case MIPI_DSI_FMT_RGB565:
> > + bit_per_pixel = 16;
> > + break;
> > + case MIPI_DSI_FMT_RGB666_PACKED:
> > + bit_per_pixel = 18;
> > + break;
> > + case MIPI_DSI_FMT_RGB666:
> > + case MIPI_DSI_FMT_RGB888:
> > + default:
> > + bit_per_pixel = 24;
> > + break;
> > + }
> > + /**
> > + * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
> > + * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
> > + * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
> > + * + Thstrail + Ths_exit + Ths_zero) /
> > + * (htotal * byte_per_pixel /lane_number)
> > + */
> > + bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
> > + htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
> > + dsi->vm.hsync_len;
> > + htotal_bits = htotal * bit_per_pixel;
> > +
> > /**
> > - * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
> > - * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
> > - * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> > - * we set mipi_ratio is 1.05.
> > + * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
> > */
> > - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> > + overhead_cycles = LPX + (HS_PRPR >> 8) + (HS_ZERO >> 16) +
> > + (HS_TRAIL >> 24) + (DA_HS_EXIT >> 24);
> > + overhead_bits = overhead_cycles * dsi->lanes * 8;
> > + total_bits = htotal_bits + overhead_bits;
> >
> > - ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> > + dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
> > + htotal_bits * dsi->lanes);
> > +
> > + ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
> > if (ret < 0) {
> > dev_err(dev, "Failed to set data rate: %d\n", ret);
> > goto err_refcount;
> > @@ -236,7 +254,20 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> >
> > mtk_dsi_enable(dsi);
> > mtk_dsi_reset(dsi);
> > - dsi_phy_timconfig(dsi);
> > +
> > + ui = 1000 / dsi->data_rate + 0x01;
> > + cycle_time = 8000 / dsi->data_rate + 0x01;
> > +
> > + phy_timing0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
> > + phy_timing1 = TA_GO | TA_SURE | TA_GET | DA_HS_EXIT;
> > + phy_timing2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> > + (NS_TO_CYCLE(0x150, cycle_time) << 16);
> > + phy_timing3 = (2 * LPX) << 16 |
> > + NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> > + NS_TO_CYCLE(0x40, cycle_time);
> > +
> > + dsi_phy_timconfig(dsi, phy_timing0, phy_timing1, phy_timing2,
> > + phy_timing3);
> >
> > return 0;
> >
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] ARM: DT: stm32: move dma translation to board files
From: Alexandre Torgue @ 2016-10-26 9:09 UTC (permalink / raw)
To: Bruno Herrera
Cc: Maxime Coquelin, arnd-r2nGTMty4D4, >, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, >,
lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAF3+Tqd2MGmz+8XhLXhaZiEc78QOwHSpVrQA65-p1AcfT+_xgg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Bruno,
On 10/25/2016 11:06 PM, Bruno Herrera wrote:
> Hi Alexandre,
>
>>
>> stm32f469-disco and stm32f429-eval boards use SDRAM start address remapping
>> (to @0) to boost performances. A DMA translation through "dma-ranges"
>> property was needed for other masters than the M4 CPU.
>> stm32f429-disco doesn't use remapping so doesn't need this DMA translation.
>> This patches moves this DMA translation definition from stm32f429 soc file
>> to board files.
>>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
>>
>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
>> index 13c7cd2..a763c15 100644
>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> @@ -82,6 +82,10 @@
>> };
>> };
>>
>> + soc {
>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
>> + };
>> +
>> usbotg_hs_phy: usbphy {
>> #phy-cells = <0>;
>> compatible = "usb-nop-xceiv";
>
> Shouldn't also the peripheral dma-ranges property move to board specific too?
> I had this patch for while but I didn't had the time to submit:
Well spot I forgot it. Actually, discussing with Arnd ysterday on IIRC,
empty dma-ranges is not needed. Can you test on your side by removing
dma-ranges in usb node please ?
I will push a v2 by removing empty dma-ranges if tests are ok in your side.
Thanks in advance
Alex
>
> Author: Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Sun Oct 16 14:50:00 2016 -0200
>
> ARM: DT: STM32: Use dma-ranges property per board not at dtsi file
>
> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
> b/arch/arm/boot/dts/stm32429i-eval.dts
> index 6bfc595..2a22a82 100644
> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> @@ -52,6 +52,10 @@
> model = "STMicroelectronics STM32429i-EVAL board";
> compatible = "st,stm32429i-eval", "st,stm32f429";
>
> + soc {
> + dma-ranges = <0xC0000000 0x0 0x10000000>;
> + };
> +
> chosen {
> bootargs = "root=/dev/ram rdinit=/linuxrc";
> stdout-path = "serial0:115200n8";
> @@ -96,6 +100,7 @@
>
> ðernet0 {
> status = "okay";
> + dma-ranges;
> pinctrl-0 = <ðernet0_mii>;
> pinctrl-names = "default";
> phy-mode = "mii-id";
> @@ -116,6 +121,7 @@
> };
>
> &usbotg_hs {
> + dma-ranges;
> dr_mode = "host";
> phys = <&usbotg_hs_phy>;
> phy-names = "usb2-phy";
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index 7d624a2..697a133 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -59,7 +59,6 @@
> };
>
> soc {
> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>
> timer2: timer@40000000 {
> compatible = "st,stm32-timer";
> @@ -472,13 +471,11 @@
> st,syscon = <&syscfg 0x4>;
> snps,pbl = <8>;
> snps,mixed-burst;
> - dma-ranges;
> status = "disabled";
> };
>
> usbotg_hs: usb@40040000 {
> compatible = "snps,dwc2";
> - dma-ranges;
> reg = <0x40040000 0x40000>;
> interrupts = <77>;
> clocks = <&rcc 0 29>;
>
>
>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
>> index 0596d60..3a1cfdd 100644
>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> @@ -59,8 +59,6 @@
>> };
>>
>> soc {
>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>> -
>> timer2: timer@40000000 {
>> compatible = "st,stm32-timer";
>> reg = <0x40000000 0x400>;
>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
>> index 9e73656..c2213c0 100644
>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>> @@ -64,6 +64,10 @@
>> aliases {
>> serial0 = &usart3;
>> };
>> +
>> + soc {
>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
>> + };
>> };
>>
>> &clk_hse {
>> --
>
>
> Br.,
> Bruno
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 1/2] Documentation: tpm: add the IBM Virtual TPM device tree binding documentation
From: Nayna Jain @ 2016-10-26 9:21 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cc: mark.rutland-5wv7dgnIgG8, robh-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
wsa-z923LK4zBo2bacvFa/9K2g,
honclo-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, galak-sgV2jX0FEOL9JmXXK+q4OQ,
cclaudio-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
Virtual TPM, which is being used on IBM POWER7+ and POWER8 systems running
POWERVM, is currently supported by tpm device driver but lacks the
documentation. This patch adds the missing documentation for the existing
support.
Suggested-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Signed-off-by: Nayna Jain <nayna-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
---
Changelog v3:
- No changes done.
Changelog v2:
- New Patch.
.../devicetree/bindings/security/tpm/ibmvtpm.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt
diff --git a/Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt b/Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt
new file mode 100644
index 0000000..d89f999
--- /dev/null
+++ b/Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt
@@ -0,0 +1,41 @@
+* Device Tree Bindings for IBM Virtual Trusted Platform Module(vtpm)
+
+Required properties:
+
+- compatible : property name that conveys the platform architecture
+ identifiers, as 'IBM,vtpm'
+- device_type : specifies type of virtual device
+- interrupts : property specifying the interrupt source number and
+ sense code associated with this virtual I/O Adapters
+- ibm,my-drc-index : integer index for the connector between the device
+ and its parent - present only if Dynamic
+ Reconfiguration(DR) Connector is enabled
+- ibm,#dma-address-cells: specifies the number of cells that are used to
+ encode the physical address field of dma-window
+ properties
+- ibm,#dma-size-cells : specifies the number of cells that are used to
+ encode the size field of dma-window properties
+- ibm,my-dma-window : specifies DMA window associated with this virtual
+ IOA
+- ibm,loc-code : specifies the unique and persistent location code
+ associated with this virtual I/O Adapters
+- linux,sml-base : 64-bit base address of the reserved memory allocated
+ for the firmware event log
+- linux,sml-size : size of the memory allocated for the firmware event log
+
+Example (IBM Virtual Trusted Platform Module)
+---------------------------------------------
+
+ vtpm@30000003 {
+ ibm,#dma-size-cells = <0x2>;
+ compatible = "IBM,vtpm";
+ device_type = "IBM,vtpm";
+ ibm,my-drc-index = <0x30000003>;
+ ibm,#dma-address-cells = <0x2>;
+ linux,sml-base = <0xc60e 0x0>;
+ interrupts = <0xa0003 0x0>;
+ ibm,my-dma-window = <0x10000003 0x0 0x0 0x0 0x10000000>;
+ ibm,loc-code = "U8286.41A.10082DV-V3-C3";
+ reg = <0x30000003>;
+ linux,sml-size = <0xbce10200>;
+ };
--
2.5.0
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
^ permalink raw reply related
* [PATCH v3 2/2] Documentation: tpm: add the Physical TPM device tree binding documentation
From: Nayna Jain @ 2016-10-26 9:21 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cc: mark.rutland-5wv7dgnIgG8, robh-DgEjT+Ai2ygdnm+yROfE0A,
pawel.moll-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
wsa-z923LK4zBo2bacvFa/9K2g,
honclo-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, galak-sgV2jX0FEOL9JmXXK+q4OQ,
cclaudio-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <1477473705-12746-1-git-send-email-nayna-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Newly added support of TPM 2.0 eventlog securityfs pseudo files in tpm
device driver consumes device tree bindings representing I2C based
Physical TPM. This patch adds the documentation for corresponding device
tree bindings of I2C based Physical TPM. These bindings are similar to
vtpm device tree bindings being used on IBM Power7+ and Power8 Systems
running PowerVM.
Suggested-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Signed-off-by: Nayna Jain <nayna-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
---
Changelog v3:
- Added documentation for "label" property.
Changelog v2:
- Include review feedbacks.
- Move the doc within bindings/security/tpm.
- Add example for compatible property in description.
- Delete implicit properties like status, label from description.
- Redefine linux,sml-base description.
.../devicetree/bindings/security/tpm/tpm-i2c.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt
diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt b/Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt
new file mode 100644
index 0000000..8cb638b
--- /dev/null
+++ b/Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt
@@ -0,0 +1,21 @@
+* Device Tree Bindings for I2C based Trusted Platform Module(TPM)
+
+Required properties:
+
+- compatible : 'manufacturer,model', eg. nuvoton,npct650
+- label : human readable string describing the device, eg. "tpm"
+- linux,sml-base : 64-bit base address of the reserved memory allocated for
+ the firmware event log
+- linux,sml-size : size of the memory allocated for the firmware event log
+
+Example (for OpenPower Systems with Nuvoton TPM 2.0 on I2C)
+----------------------------------------------------------
+
+tpm@57 {
+ reg = <0x57>;
+ label = "tpm";
+ compatible = "nuvoton,npct650", "nuvoton,npct601";
+ linux,sml-base = <0x7f 0xfd450000>;
+ linux,sml-size = <0x10000>;
+ status = "okay";
+};
--
2.5.0
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
^ permalink raw reply related
* Re: [PATCH v6 1/5] ARM: davinci: da8xx: add usb phy clocks
From: Sekhar Nori @ 2016-10-26 9:24 UTC (permalink / raw)
To: David Lechner, Kevin Hilman, Rob Herring, Mark Rutland
Cc: linux-arm-kernel, devicetree, Sergei Shtylyov, Axel Haslam,
linux-kernel
In-Reply-To: <1477451211-31979-2-git-send-email-david@lechnology.com>
On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:
> diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
> index f141f51..71a6d85 100644
> --- a/arch/arm/mach-davinci/usb-da8xx.c
> +++ b/arch/arm/mach-davinci/usb-da8xx.c
> @@ -1,20 +1,248 @@
> /*
> * DA8xx USB
> */
> -#include <linux/dma-mapping.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> #include <linux/init.h>
> #include <linux/platform_data/usb-davinci.h>
> #include <linux/platform_device.h>
> +#include <linux/mfd/da8xx-cfgchip.h>
> #include <linux/usb/musb.h>
>
> +#include <mach/clock.h>
> #include <mach/common.h>
> #include <mach/cputype.h>
> #include <mach/da8xx.h>
> -#include <mach/irqs.h>
Looks like you have cleaned up some unneeded includes. Thats fine, just
mention it in the commit description too, so its clear that it is intended.
Also, when adding new include files, please do it in alphabetical order.
> +static struct clk usb_refclkin = {
> + .name = "usb_refclkin",
> + .set_rate = davinci_simple_set_rate,
> +};
> +
> +static struct clk_lookup usb_refclkin_lookup =
> + CLK(NULL, "usb_refclkin", &usb_refclkin);
> +
> +static struct clk usb20_phy_clk = {
> + .name = "usb20_phy",
> + .clk_enable = usb20_phy_clk_enable,
> + .clk_disable = usb20_phy_clk_disable,
> + .set_parent = usb20_phy_clk_set_parent,
> +};
> +
> +static struct clk_lookup usb20_phy_clk_lookup =
> + CLK(NULL, "usb20_phy", &usb20_phy_clk);
NULL device name here is wrong. There is a PHY device that gets added
3/5. The name of that device should appear here. Since that phy device
is the consumer of this clock. You can change the order of patches so
the device appears before the associated clocks.
> +static struct clk usb11_phy_clk = {
> + .name = "usb11_phy",
> + .set_parent = usb11_phy_clk_set_parent,
> +};
> +
> +static struct clk_lookup usb11_phy_clk_lookup =
> + CLK(NULL, "usb11_phy", &usb11_phy_clk);
here too, please have the phy device name as the consumer of this clock.
It is okay to have NULL device name for the usb_refclkin since that is a
root clock not associated with any device.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH 1/1] power: axp20x_ac: Add support for ac power-supply on axp20x and axp22x pmics
From: Lee Jones @ 2016-10-26 9:27 UTC (permalink / raw)
To: Lawrence Yu
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
hdegoede-H+wXaHxf7aLQT0dZR+AlfA, wens-jdAy2FN1RRM,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
sre-DgEjT+Ai2ygdnm+yROfE0A, dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy
In-Reply-To: <1474129243-10873-1-git-send-email-lyu-U6IdCoVonM7QT0dZR+AlfA@public.gmane.org>
On Sat, 17 Sep 2016, Lawrence Yu wrote:
> Add support for monitoring of ac power supply input. axp22x is the same
> as axp20x except it can not monitor voltage or current, only presence of
> power.
>
> This is mainly a copy of the existing axp20x_usb_power driver modified to
> use the ac power supply registers instead of the usb registers.
>
> axp20x tested on a generic A20 tablet.
> axp22x tested on an a33 ga10h-v1.1 tablet.
>
> Signed-off-by: Lawrence Yu <lyu-U6IdCoVonM7QT0dZR+AlfA@public.gmane.org>
> ---
> .../bindings/power_supply/axp20x_ac_power.txt | 35 ++++
> arch/arm/boot/dts/axp209.dtsi | 5 +
> arch/arm/boot/dts/axp22x.dtsi | 5 +
> drivers/mfd/axp20x.c | 11 ++
> drivers/power/Makefile | 1 +
> drivers/power/axp20x_ac_power.c | 219 +++++++++++++++++++++
Please split this patch up per-subsystem.
> 6 files changed, 276 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
> create mode 100644 drivers/power/axp20x_ac_power.c
>
> diff --git a/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
> new file mode 100644
> index 0000000..d751cdc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
> @@ -0,0 +1,35 @@
> +AXP20x AC power supply
> +
> +Required Properties:
> +-compatible: One of: "x-powers,axp202-ac-power-supply"
> + "x-powers,axp221-ac-power-supply"
> +
> +This node is a subnode of the axp20x PMIC.
> +
> +Example:
> +
> +axp209: pmic@34 {
> + compatible = "x-powers,axp209";
> + reg = <0x34>;
> + interrupt-parent = <&nmi_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + regulators {
> + x-powers,dcdc-freq = <1500>;
> +
> + vdd_cpu: dcdc2 {
> + regulator-always-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1450000>;
> + regulator-name = "vdd-cpu";
> + };
> +
> + ...
> + };
> +
> + ac-power-supply: ac-power-supply {
> + compatible = "x-powers,axp202-ac-power-supply";
> + };
> +};
> diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
> index 675bb0f..54e23c6 100644
> --- a/arch/arm/boot/dts/axp209.dtsi
> +++ b/arch/arm/boot/dts/axp209.dtsi
> @@ -97,6 +97,11 @@
> };
> };
>
> + ac_power_supply: ac_power_supply {
> + compatible = "x-powers,axp202-ac-power-supply";
> + status = "disabled";
> + };
> +
> usb_power_supply: usb_power_supply {
> compatible = "x-powers,axp202-usb-power-supply";
> status = "disabled";
> diff --git a/arch/arm/boot/dts/axp22x.dtsi b/arch/arm/boot/dts/axp22x.dtsi
> index 458b668..cdd5d4f 100644
> --- a/arch/arm/boot/dts/axp22x.dtsi
> +++ b/arch/arm/boot/dts/axp22x.dtsi
> @@ -148,6 +148,11 @@
> };
> };
>
> + ac_power_supply: ac_power_supply {
> + compatible = "x-powers,axp221-ac-power-supply";
> + status = "disabled";
> + };
> +
> usb_power_supply: usb_power_supply {
> compatible = "x-powers,axp221-usb-power-supply";
> status = "disabled";
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index ba130be..450d1a0 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -162,6 +162,12 @@ static struct resource axp20x_ac_power_supply_resources[] = {
> DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_OVER_V, "ACIN_OVER_V"),
> };
>
> +static struct resource axp22x_ac_power_supply_resources[] = {
> + DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_PLUGIN, "ACIN_PLUGIN"),
> + DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_REMOVAL, "ACIN_REMOVAL"),
> + DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_OVER_V, "ACIN_OVER_V"),
> +};
> +
> static struct resource axp20x_pek_resources[] = {
> {
> .name = "PEK_DBR",
> @@ -595,6 +601,11 @@ static struct mfd_cell axp22x_cells[] = {
> }, {
> .name = "axp20x-regulator",
> }, {
> + .name = "axp20x-ac-power-supply",
> + .of_compatible = "x-powers,axp221-ac-power-supply",
> + .num_resources = ARRAY_SIZE(axp22x_ac_power_supply_resources),
> + .resources = axp22x_ac_power_supply_resources,
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp221-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index e46b75d..295ec0f 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
>
> obj-$(CONFIG_PDA_POWER) += pda_power.o
> obj-$(CONFIG_APM_POWER) += apm_power.o
> +obj-$(CONFIG_AXP20X_POWER) += axp20x_ac_power.o
> obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o
> obj-$(CONFIG_MAX8925_POWER) += max8925_power.o
> obj-$(CONFIG_WM831X_BACKUP) += wm831x_backup.o
> diff --git a/drivers/power/axp20x_ac_power.c b/drivers/power/axp20x_ac_power.c
> new file mode 100644
> index 0000000..13bb093
> --- /dev/null
> +++ b/drivers/power/axp20x_ac_power.c
> @@ -0,0 +1,219 @@
> +/*
> + * AXP20x PMIC AC power supply status driver
> + *
> + * Copyright (C) 2015 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> + * Copyright (C) 2014 Bruno Prémont <bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/axp20x.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/power_supply.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +#define DRVNAME "axp20x-ac-power-supply"
> +
> +#define AXP20X_PWR_STATUS_ACIN_PRESENT BIT(7)
> +#define AXP20X_PWR_STATUS_ACIN_USED BIT(6)
> +#define AXP20X_ADC_EN1_ACIN_CURR BIT(4)
> +#define AXP20X_ADC_EN1_ACIN_VOLT BIT(5)
> +
> +struct axp20x_ac_power {
> + struct device_node *np;
> + struct regmap *regmap;
> + struct power_supply *supply;
> +};
> +
> +static irqreturn_t axp20x_ac_power_irq(int irq, void *devid)
> +{
> + struct axp20x_ac_power *power = devid;
> +
> + power_supply_changed(power->supply);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int axp20x_ac_power_get_property(struct power_supply *psy,
> + enum power_supply_property psp, union power_supply_propval *val)
> +{
> + struct axp20x_ac_power *power = power_supply_get_drvdata(psy);
> + unsigned int input;
> + int ret;
> +
> + switch (psp) {
> + case POWER_SUPPLY_PROP_VOLTAGE_NOW:
> + ret = axp20x_read_variable_width(power->regmap,
> + AXP20X_ACIN_V_ADC_H, 12);
> + if (ret < 0)
> + return ret;
> +
> + val->intval = ret * 1700; /* 1 step = 1.7 mV */
> + return 0;
> + case POWER_SUPPLY_PROP_CURRENT_NOW:
> + ret = axp20x_read_variable_width(power->regmap,
> + AXP20X_ACIN_I_ADC_H, 12);
> + if (ret < 0)
> + return ret;
> +
> + val->intval = ret * 625; /* 1 step = 0.375 mA */
> + return 0;
> + default:
> + break;
> + }
> +
> + /* All the properties below need the input-status reg value */
> + ret = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, &input);
> + if (ret)
> + return ret;
> +
> + switch (psp) {
> + case POWER_SUPPLY_PROP_PRESENT:
> + val->intval = !!(input & AXP20X_PWR_STATUS_ACIN_PRESENT);
> + break;
> + case POWER_SUPPLY_PROP_ONLINE:
> + val->intval = !!(input & AXP20X_PWR_STATUS_ACIN_USED);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static enum power_supply_property axp20x_ac_power_properties[] = {
> + POWER_SUPPLY_PROP_PRESENT,
> + POWER_SUPPLY_PROP_ONLINE,
> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
> + POWER_SUPPLY_PROP_CURRENT_NOW,
> +};
> +
> +static enum power_supply_property axp22x_ac_power_properties[] = {
> + POWER_SUPPLY_PROP_PRESENT,
> + POWER_SUPPLY_PROP_ONLINE,
> +};
> +
> +static const struct power_supply_desc axp20x_ac_power_desc = {
> + .name = "axp20x-ac",
> + .type = POWER_SUPPLY_TYPE_MAINS,
> + .properties = axp20x_ac_power_properties,
> + .num_properties = ARRAY_SIZE(axp20x_ac_power_properties),
> + .get_property = axp20x_ac_power_get_property,
> +};
> +
> +static const struct power_supply_desc axp22x_ac_power_desc = {
> + .name = "axp20x-ac",
> + .type = POWER_SUPPLY_TYPE_MAINS,
> + .properties = axp22x_ac_power_properties,
> + .num_properties = ARRAY_SIZE(axp22x_ac_power_properties),
> + .get_property = axp20x_ac_power_get_property,
> +};
> +
> +static int axp20x_ac_power_probe(struct platform_device *pdev)
> +{
> + struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> + struct power_supply_config psy_cfg = {};
> + struct axp20x_ac_power *power;
> + static const char * const axp20x_irq_names[] = {
> + "ACIN_PLUGIN", "ACIN_REMOVAL", NULL };
> + static const char * const axp22x_irq_names[] = {
> + "ACIN_PLUGIN", "ACIN_REMOVAL", NULL };
> + static const char * const *irq_names;
> + const struct power_supply_desc *ac_power_desc;
> + int i, irq, ret;
> +
> + if (!of_device_is_available(pdev->dev.of_node))
> + return -ENODEV;
> +
> + if (!axp20x) {
> + dev_err(&pdev->dev, "Parent drvdata not set\n");
> + return -EINVAL;
> + }
> +
> + power = devm_kzalloc(&pdev->dev, sizeof(*power), GFP_KERNEL);
> + if (!power)
> + return -ENOMEM;
> +
> + power->np = pdev->dev.of_node;
> + power->regmap = axp20x->regmap;
> +
> + if (of_device_is_compatible(power->np,
> + "x-powers,axp202-ac-power-supply")) {
> +
> + /* Enable acin voltage and current measurement */
> + ret = regmap_update_bits(power->regmap, AXP20X_ADC_EN1,
> + AXP20X_ADC_EN1_ACIN_CURR | AXP20X_ADC_EN1_ACIN_VOLT,
> + AXP20X_ADC_EN1_ACIN_CURR | AXP20X_ADC_EN1_ACIN_VOLT);
> + if (ret)
> + return ret;
> +
> + ac_power_desc = &axp20x_ac_power_desc;
> + irq_names = axp20x_irq_names;
> + } else if (of_device_is_compatible(power->np,
> + "x-powers,axp221-ac-power-supply")) {
> + ac_power_desc = &axp22x_ac_power_desc;
> + irq_names = axp22x_irq_names;
> + } else {
> + dev_err(&pdev->dev, "Unsupported AXP variant: %ld\n",
> + axp20x->variant);
> + return -EINVAL;
> + }
> +
> + psy_cfg.of_node = pdev->dev.of_node;
> + psy_cfg.drv_data = power;
> +
> + power->supply = devm_power_supply_register(&pdev->dev, ac_power_desc,
> + &psy_cfg);
> + if (IS_ERR(power->supply))
> + return PTR_ERR(power->supply);
> +
> + /* Request irqs after registering, as irqs may trigger immediately */
> + for (i = 0; irq_names[i]; i++) {
> + irq = platform_get_irq_byname(pdev, irq_names[i]);
> + if (irq < 0) {
> + dev_warn(&pdev->dev, "No IRQ for %s: %d\n",
> + irq_names[i], irq);
> + continue;
> + }
> + irq = regmap_irq_get_virq(axp20x->regmap_irqc, irq);
> + ret = devm_request_any_context_irq(&pdev->dev, irq,
> + axp20x_ac_power_irq, 0, DRVNAME, power);
> + if (ret < 0)
> + dev_warn(&pdev->dev, "Error requesting %s IRQ: %d\n",
> + irq_names[i], ret);
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id axp20x_ac_power_match[] = {
> + { .compatible = "x-powers,axp202-ac-power-supply" },
> + { .compatible = "x-powers,axp221-ac-power-supply" },
> + { }
> +};
> +
> +MODULE_DEVICE_TABLE(of, axp20x_ac_power_match);
> +
> +static struct platform_driver axp20x_ac_power_driver = {
> + .probe = axp20x_ac_power_probe,
> + .driver = {
> + .name = DRVNAME,
> + .of_match_table = axp20x_ac_power_match,
> + },
> +};
> +
> +module_platform_driver(axp20x_ac_power_driver);
> +
> +MODULE_AUTHOR("Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>");
> +MODULE_DESCRIPTION("AXP20x PMIC AC power supply status driver");
> +MODULE_LICENSE("GPL");
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH/RFT v2 07/17] ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable
From: Sekhar Nori @ 2016-10-26 9:30 UTC (permalink / raw)
To: David Lechner, ahaslam, gregkh, johan, robh+dt, stern, khilman,
sshtylyov, manjunath.goudar, broonie, abailon
Cc: linux-usb, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <5abddbfe-0338-6406-9299-1d2d3fb957a3@lechnology.com>
On Tuesday 25 October 2016 09:35 PM, David Lechner wrote:
> On 10/25/2016 05:12 AM, Sekhar Nori wrote:
>> On Monday 24 October 2016 10:16 PM, ahaslam@baylibre.com wrote:
>>> diff --git a/arch/arm/mach-davinci/usb-da8xx.c
>>> b/arch/arm/mach-davinci/usb-da8xx.c
>>> index 9e41a7f..982e105 100644
>>> --- a/arch/arm/mach-davinci/usb-da8xx.c
>>> +++ b/arch/arm/mach-davinci/usb-da8xx.c
>>> @@ -53,11 +53,19 @@ int __init da8xx_register_usb_refclkin(int rate)
>>>
>>> static void usb20_phy_clk_enable(struct clk *clk)
>>> {
>>> + struct clk *usb20_clk;
>>> u32 val;
>>> u32 timeout = 500000; /* 500 msec */
>>>
>>> val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
>>>
>>> + usb20_clk = clk_get(NULL, "usb20");
>>
>> We should not be using a NULL device pointer here. Can you pass the musb
>> device pointer available in the same file? Also, da850_clks[] in da850.c
>> needs to be fixed to add the matching device name.
>
> This clock can be used for usb 1.1 PHY even when musb is not being used,
> so I don't think we can depend on having a musb device here.
Replied to this against the same question in v6 patch series you posted.
> Also, in a previous review, it was decided that the usb clocks should
> *not* be added to da850_clks[] [1]. Instead, they are dynamically
> registered elsewhere.
Thats only the USB phy clocks since there is associated
enable()/disable()/set_parent() code which is better kept outside of
da850.c for readability. No other reason. Lookup for the USB 2.0 module
clock is already present in da850.c
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH 3/4] usb: musb: da8xx: Add DT support for the DA8xx driver
From: Alexandre Bailon @ 2016-10-26 9:31 UTC (permalink / raw)
To: Sergei Shtylyov, khilman, robh+dt, b-liu
Cc: linux-kernel, linux-usb, devicetree, linux-arm-kernel,
Petr Kulhavy
In-Reply-To: <82a39c63-8486-de00-3a0f-8d9d267b6404@cogentembedded.com>
On 10/25/2016 07:38 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 10/25/2016 05:39 PM, Alexandre Bailon wrote:
>
>> From: Petr Kulhavy <petr@barix.com>
>>
>> This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
>>
>> Signed-off-by: Petr Kulhavy <petr@barix.com>
>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>> ---
>> drivers/usb/musb/da8xx.c | 76
>> ++++++++++++++++++++++++++++++++++++++++++------
>> 1 file changed, 67 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
>> index 210b7e4..d465087 100644
>> --- a/drivers/usb/musb/da8xx.c
>> +++ b/drivers/usb/musb/da8xx.c
>> @@ -6,6 +6,9 @@
>> * Based on the DaVinci "glue layer" code.
>> * Copyright (C) 2005-2006 by Texas Instruments
>> *
>> + * DT support
>> + * Copyright (c) 2016 Petr Kulhavy <petr@barix.com>
>> + *
>> * This file is part of the Inventra Controller Driver for Linux.
>> *
>> * The Inventra Controller Driver for Linux is free software; you
> [...]
>> @@ -499,15 +537,21 @@ static int da8xx_probe(struct platform_device
>> *pdev)
>> memset(musb_resources, 0x00, sizeof(*musb_resources) *
>> ARRAY_SIZE(musb_resources));
>>
>> - musb_resources[0].name = pdev->resource[0].name;
>> - musb_resources[0].start = pdev->resource[0].start;
>> - musb_resources[0].end = pdev->resource[0].end;
>> - musb_resources[0].flags = pdev->resource[0].flags;
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res) {
>> + dev_err(&pdev->dev, "failed to get memory.\n");
>> + ret = -EINVAL;
>> + goto err_unregister_usb_phy;
>> + }
>> + musb_resources[0] = *res;
>
> What does this change have to do with the DT conversion?
Nothing. I will remove it.
>
>>
>> - musb_resources[1].name = pdev->resource[1].name;
>> - musb_resources[1].start = pdev->resource[1].start;
>> - musb_resources[1].end = pdev->resource[1].end;
>> - musb_resources[1].flags = pdev->resource[1].flags;
>> + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> + if (!res) {
>> + dev_err(&pdev->dev, "failed to get irq.\n");
>> + ret = -EINVAL;
>> + goto err_unregister_usb_phy;
>> + }
>> + musb_resources[1] = *res;
>
> And this?
> I'm also concerned that you'd copy the resource linkage fields which
> the existing code avoids...
>
> [...]
>
> MBR, Sergei
>
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD, GPIO, Input and Regulator due for the v4.10 merge window
From: Lee Jones @ 2016-10-26 9:34 UTC (permalink / raw)
To: Keerthy
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, t-kristo-l0cyMroinI0,
tony-4v6yS6AI5VpBDgjK7y7TUQ,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
broonie-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1474270746-11568-1-git-send-email-j-keerthy-l0cyMroinI0@public.gmane.org>
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-gpio-input-regulator-v4.10
for you to fetch changes up to 2dc4940360d4c0c38aa9275532c7c0d7542f6258:
regulator: tps65218: Remove all the compatibles (2016-10-26 10:30:39 +0100)
----------------------------------------------------------------
Immutable branch between MFD, GPIO, Input and Regulator due for the v4.10 merge window
----------------------------------------------------------------
Keerthy (5):
mfd: tps65218: Remove redundant read wrapper
Documentation: regulator: tps65218: Update examples
input: tps65218-pwrbutton: Add platform_device_id table
mfd: tps65218: Use mfd_add_devices instead of of_platform_populate
regulator: tps65218: Remove all the compatibles
.../devicetree/bindings/regulator/tps65218.txt | 87 +++++++++---
drivers/gpio/gpio-tps65218.c | 3 +-
drivers/input/misc/tps65218-pwrbutton.c | 8 ++
drivers/mfd/tps65218.c | 34 ++---
drivers/regulator/tps65218-regulator.c | 153 ++++++++-------------
include/linux/mfd/tps65218.h | 3 +-
6 files changed, 157 insertions(+), 131 deletions(-)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] drm/mediatek: fixed the calc method of data rate per lane
From: CK Hu @ 2016-10-26 9:37 UTC (permalink / raw)
To: Jitao Shi
Cc: Mark Rutland, stonea168, dri-devel, Andy Yan, Ajay Kumar,
Vincent Palatin, cawa.cheng, Russell King, devicetree, Pawel Moll,
Ian Campbell, Rob Herring, linux-mediatek, yingjoe.chen,
Matthias Brugger, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Kumar Gala
In-Reply-To: <1477472395-6451-1-git-send-email-jitao.shi@mediatek.com>
Hi, Jitao:
On Wed, 2016-10-26 at 16:59 +0800, Jitao Shi wrote:
> Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
> Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
> signal will cause h-time larger than normal and reduce FPS.
> Need to multiply a coefficient to offset the extra signal's effect.
> coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
> Ths_exit)/(htotal*bpp/lane_number))
>
One check-patch warning in commit message:
WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#7:
Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e.
Tlpx,
> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> ---
> Change since v2:
> - move phy timing back to dsi_phy_timconfig.
>
> Change since v1:
> - phy_timing2 and phy_timing3 refer clock cycle time.
> - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 74 +++++++++++++++++++++++++-----------
> 1 file changed, 51 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 28b2044..8b3b38a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -85,16 +85,16 @@
> #define LD0_WAKEUP_EN BIT(2)
>
> #define DSI_PHY_TIMECON0 0x110
> -#define LPX (0xff << 0)
> -#define HS_PRPR (0xff << 8)
> -#define HS_ZERO (0xff << 16)
> -#define HS_TRAIL (0xff << 24)
> +#define LPX (5 << 0)
> +#define HS_PRPR (6 << 8)
> +#define HS_ZERO (10 << 16)
> +#define HS_TRAIL (8 << 24)
>
> #define DSI_PHY_TIMECON1 0x114
> -#define TA_GO (0xff << 0)
> -#define TA_SURE (0xff << 8)
> -#define TA_GET (0xff << 16)
> -#define DA_HS_EXIT (0xff << 24)
> +#define TA_GO (20 << 0)
> +#define TA_SURE (7 << 8)
> +#define TA_GET (25 << 16)
> +#define DA_HS_EXIT (7 << 24)
>
> #define DSI_PHY_TIMECON2 0x118
> #define CONT_DET (0xff << 0)
> @@ -161,20 +161,18 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, u32 mask, u32 data)
> static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> {
> u32 timcon0, timcon1, timcon2, timcon3;
> - unsigned int ui, cycle_time;
> - unsigned int lpx;
> + u32 ui, cycle_time;
>
> ui = 1000 / dsi->data_rate + 0x01;
> cycle_time = 8000 / dsi->data_rate + 0x01;
> - lpx = 5;
>
> - timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
> - timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
> - (4 * lpx);
> + timcon0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
> + timcon1 = 4 * LPX | (3 * LPX / 2) << 8 | 5 * LPX << 16 | DA_HS_EXIT;
> timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> - (NS_TO_CYCLE(0x150, cycle_time) << 16);
> - timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> - NS_TO_CYCLE(0x40, cycle_time);
> + (NS_TO_CYCLE(0x150, cycle_time) << 16);
I think this line may align to '(' in the right of '='.
> + timcon3 = (2 * LPX) << 16 |
> + NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> + NS_TO_CYCLE(0x40, cycle_time);
I think these two lines may align to '(' in the right of '='.
Regards,
CK
I.
>
> writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> @@ -202,19 +200,49 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> {
> struct device *dev = dsi->dev;
> int ret;
> + u64 bit_clock, total_bits;
> + u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
>
> if (++dsi->refcount != 1)
> return 0;
>
> + switch (dsi->format) {
> + case MIPI_DSI_FMT_RGB565:
> + bit_per_pixel = 16;
> + break;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + bit_per_pixel = 18;
> + break;
> + case MIPI_DSI_FMT_RGB666:
> + case MIPI_DSI_FMT_RGB888:
> + default:
> + bit_per_pixel = 24;
> + break;
> + }
> /**
> - * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
> - * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
> - * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> - * we set mipi_ratio is 1.05.
> + * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
> + * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
> + * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
> + * + Thstrail + Ths_exit + Ths_zero) /
> + * (htotal * byte_per_pixel /lane_number)
> */
> - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> + bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
> + htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
> + dsi->vm.hsync_len;
> + htotal_bits = htotal * bit_per_pixel;
> +
> + /**
> + * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
> + */
> + overhead_cycles = LPX + (HS_PRPR >> 8) + (HS_ZERO >> 16) +
> + (HS_TRAIL >> 24) + (DA_HS_EXIT >> 24);
> + overhead_bits = overhead_cycles * dsi->lanes * 8;
> + total_bits = htotal_bits + overhead_bits;
> +
> + dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
> + htotal_bits * dsi->lanes);
>
> - ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> + ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
> if (ret < 0) {
> dev_err(dev, "Failed to set data rate: %d\n", ret);
> goto err_refcount;
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v6 2/5] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.
From: Sekhar Nori @ 2016-10-26 9:58 UTC (permalink / raw)
To: David Lechner, Kevin Hilman, Rob Herring, Mark Rutland
Cc: Axel Haslam, Sergei Shtylyov, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477451211-31979-3-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:
> The CFGCHIP registers are used by a number of devices, so using a syscon
> device to share them. The first consumer of this will by the phy-da8xx-usb
"will be the .."
Also, in subject line, "platform device" instead of "platform
declaration". Also lose the period at at the end of subject line
> driver.
>
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
Applied to v4.10/soc. Here is the final commit text.
---
ARM: davinci: da8xx: Add CFGCHIP syscon platform device
The CFGCHIP registers are used by a number of devices, so use a syscon
device to share them. The first consumer of this will by the phy-da8xx-usb
driver.
Add the syscon device and register it.
Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
[nsekhar-l0cyMroinI0@public.gmane.org: minor commit message fixes]
Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
---
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] gpio: mcp23s08: Add option to configure pullups.
From: Enric Balletbo Serra @ 2016-10-26 9:59 UTC (permalink / raw)
To: Alexander Stein
Cc: Linus Walleij, Enric Balletbo i Serra,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring
In-Reply-To: <11644726.TmP4uu3h4l@ws-stein>
Hi Linus,
2016-10-24 8:13 GMT+02:00 Alexander Stein
<alexander.stein-93q1YBGzJSMe9JSWTWOYM3xStJ4P+DSV@public.gmane.org>:
> On Monday 24 October 2016 02:53:31, Linus Walleij wrote:
>> On Fri, Oct 21, 2016 at 5:00 PM, Enric Balletbo i Serra
>>
>> <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> wrote:
>> > Default is without pullups, but if property is specified in DT and the bit
>> > is set, set a pullup on GPIO-n.
>> >
>> > Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>>
>> I don't generally like this.
>>
I tried to use the same approach as used in gpio-twl4030.c because is
what I knew before. Maybe you can point me to a better approach?
>> In device tree it is the consumer that specifies how the line is used,
>> not the producer (gpiochip).
>>
>> We currently only specify polarity, open drain and open source
>> for consumers though.
>>
>> And the entire pin control system came into being *exactly* because
>> Grant didn't like me adding these things to the GPIO drivers.
>>
>> So how many other things does the MCP support? Drive strength?
>> Schmitt trigger? Is there a datasheet?
>
> Some unsupported features (AFAIK):
> * Input polarity (IPOL register)
> * open-drain interrupt pin
> * pullup on pins (proposed patch)
>
> Datasheet is here: http://ww1.microchip.com/downloads/en/DeviceDoc/21919e.pdf
>
> Best regards,
> Alexander
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: dts: imx: Fix "ERROR: code indent should use tabs where possible"
From: Jagan Teki @ 2016-10-26 10:01 UTC (permalink / raw)
To: Shawn Guo
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jagan Teki
Fixed code indent tabs in respetcive imx23, imx51, imx53, imx6dl, imx6q
and imx6sx dtsi and dts files.
Signed-off-by: Jagan Teki <jagan-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org>
---
arch/arm/boot/dts/imx23.dtsi | 2 +-
arch/arm/boot/dts/imx50.dtsi | 44 +++++++++---------
arch/arm/boot/dts/imx51.dtsi | 44 +++++++++---------
arch/arm/boot/dts/imx53.dtsi | 68 ++++++++++++++--------------
arch/arm/boot/dts/imx6dl-riotboard.dts | 2 +-
arch/arm/boot/dts/imx6dl-tx6dl-comtft.dts | 2 +-
arch/arm/boot/dts/imx6dl-tx6u-801x.dts | 2 +-
arch/arm/boot/dts/imx6q-phytec-pbab01.dts | 2 +-
arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts | 2 +-
arch/arm/boot/dts/imx6q-tx6q-1010.dts | 2 +-
arch/arm/boot/dts/imx6q-tx6q-1020-comtft.dts | 2 +-
arch/arm/boot/dts/imx6q-tx6q-1020.dts | 2 +-
arch/arm/boot/dts/imx6sx-sdb.dtsi | 8 ++--
arch/arm/boot/dts/imx6sx.dtsi | 6 +--
14 files changed, 94 insertions(+), 94 deletions(-)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 440ee9a..8e1543f 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -464,7 +464,7 @@
reg = <0x80038000 0x2000>;
status = "disabled";
};
- };
+ };
apbx@80040000 {
compatible = "simple-bus";
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index 8fe8bee..92a03bc 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -103,8 +103,8 @@
reg = <0x50004000 0x4000>;
interrupts = <1>;
clocks = <&clks IMX5_CLK_ESDHC1_IPG_GATE>,
- <&clks IMX5_CLK_DUMMY>,
- <&clks IMX5_CLK_ESDHC1_PER_GATE>;
+ <&clks IMX5_CLK_DUMMY>,
+ <&clks IMX5_CLK_ESDHC1_PER_GATE>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
status = "disabled";
@@ -115,8 +115,8 @@
reg = <0x50008000 0x4000>;
interrupts = <2>;
clocks = <&clks IMX5_CLK_ESDHC2_IPG_GATE>,
- <&clks IMX5_CLK_DUMMY>,
- <&clks IMX5_CLK_ESDHC2_PER_GATE>;
+ <&clks IMX5_CLK_DUMMY>,
+ <&clks IMX5_CLK_ESDHC2_PER_GATE>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
status = "disabled";
@@ -127,7 +127,7 @@
reg = <0x5000c000 0x4000>;
interrupts = <33>;
clocks = <&clks IMX5_CLK_UART3_IPG_GATE>,
- <&clks IMX5_CLK_UART3_PER_GATE>;
+ <&clks IMX5_CLK_UART3_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -139,7 +139,7 @@
reg = <0x50010000 0x4000>;
interrupts = <36>;
clocks = <&clks IMX5_CLK_ECSPI1_IPG_GATE>,
- <&clks IMX5_CLK_ECSPI1_PER_GATE>;
+ <&clks IMX5_CLK_ECSPI1_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -164,8 +164,8 @@
reg = <0x50020000 0x4000>;
interrupts = <3>;
clocks = <&clks IMX5_CLK_ESDHC3_IPG_GATE>,
- <&clks IMX5_CLK_DUMMY>,
- <&clks IMX5_CLK_ESDHC3_PER_GATE>;
+ <&clks IMX5_CLK_DUMMY>,
+ <&clks IMX5_CLK_ESDHC3_PER_GATE>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
status = "disabled";
@@ -176,8 +176,8 @@
reg = <0x50024000 0x4000>;
interrupts = <4>;
clocks = <&clks IMX5_CLK_ESDHC4_IPG_GATE>,
- <&clks IMX5_CLK_DUMMY>,
- <&clks IMX5_CLK_ESDHC4_PER_GATE>;
+ <&clks IMX5_CLK_DUMMY>,
+ <&clks IMX5_CLK_ESDHC4_PER_GATE>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
status = "disabled";
@@ -279,7 +279,7 @@
reg = <0x53fa0000 0x4000>;
interrupts = <39>;
clocks = <&clks IMX5_CLK_GPT_IPG_GATE>,
- <&clks IMX5_CLK_GPT_HF_GATE>;
+ <&clks IMX5_CLK_GPT_HF_GATE>;
clock-names = "ipg", "per";
};
@@ -298,7 +298,7 @@
compatible = "fsl,imx50-pwm", "fsl,imx27-pwm";
reg = <0x53fb4000 0x4000>;
clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>,
- <&clks IMX5_CLK_PWM1_HF_GATE>;
+ <&clks IMX5_CLK_PWM1_HF_GATE>;
clock-names = "ipg", "per";
interrupts = <61>;
};
@@ -308,7 +308,7 @@
compatible = "fsl,imx50-pwm", "fsl,imx27-pwm";
reg = <0x53fb8000 0x4000>;
clocks = <&clks IMX5_CLK_PWM2_IPG_GATE>,
- <&clks IMX5_CLK_PWM2_HF_GATE>;
+ <&clks IMX5_CLK_PWM2_HF_GATE>;
clock-names = "ipg", "per";
interrupts = <94>;
};
@@ -318,7 +318,7 @@
reg = <0x53fbc000 0x4000>;
interrupts = <31>;
clocks = <&clks IMX5_CLK_UART1_IPG_GATE>,
- <&clks IMX5_CLK_UART1_PER_GATE>;
+ <&clks IMX5_CLK_UART1_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -328,7 +328,7 @@
reg = <0x53fc0000 0x4000>;
interrupts = <32>;
clocks = <&clks IMX5_CLK_UART2_IPG_GATE>,
- <&clks IMX5_CLK_UART2_PER_GATE>;
+ <&clks IMX5_CLK_UART2_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -383,7 +383,7 @@
reg = <0x53ff0000 0x4000>;
interrupts = <13>;
clocks = <&clks IMX5_CLK_UART4_IPG_GATE>,
- <&clks IMX5_CLK_UART4_PER_GATE>;
+ <&clks IMX5_CLK_UART4_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -401,7 +401,7 @@
reg = <0x63f90000 0x4000>;
interrupts = <86>;
clocks = <&clks IMX5_CLK_UART5_IPG_GATE>,
- <&clks IMX5_CLK_UART5_PER_GATE>;
+ <&clks IMX5_CLK_UART5_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -420,7 +420,7 @@
reg = <0x63fac000 0x4000>;
interrupts = <37>;
clocks = <&clks IMX5_CLK_ECSPI2_IPG_GATE>,
- <&clks IMX5_CLK_ECSPI2_PER_GATE>;
+ <&clks IMX5_CLK_ECSPI2_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -430,7 +430,7 @@
reg = <0x63fb0000 0x4000>;
interrupts = <6>;
clocks = <&clks IMX5_CLK_SDMA_GATE>,
- <&clks IMX5_CLK_SDMA_GATE>;
+ <&clks IMX5_CLK_SDMA_GATE>;
clock-names = "ipg", "ahb";
fsl,sdma-ram-script-name = "imx/sdma/sdma-imx50.bin";
};
@@ -442,7 +442,7 @@
reg = <0x63fc0000 0x4000>;
interrupts = <38>;
clocks = <&clks IMX5_CLK_CSPI_IPG_GATE>,
- <&clks IMX5_CLK_CSPI_IPG_GATE>;
+ <&clks IMX5_CLK_CSPI_IPG_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -492,8 +492,8 @@
reg = <0x63fec000 0x4000>;
interrupts = <87>;
clocks = <&clks IMX5_CLK_FEC_GATE>,
- <&clks IMX5_CLK_FEC_GATE>,
- <&clks IMX5_CLK_FEC_GATE>;
+ <&clks IMX5_CLK_FEC_GATE>,
+ <&clks IMX5_CLK_FEC_GATE>;
clock-names = "ipg", "ahb", "ptp";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index f46fe9b..d8efdab 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -130,8 +130,8 @@
reg = <0x40000000 0x20000000>;
interrupts = <11 10>;
clocks = <&clks IMX5_CLK_IPU_GATE>,
- <&clks IMX5_CLK_IPU_DI0_GATE>,
- <&clks IMX5_CLK_IPU_DI1_GATE>;
+ <&clks IMX5_CLK_IPU_DI0_GATE>,
+ <&clks IMX5_CLK_IPU_DI1_GATE>;
clock-names = "bus", "di0", "di1";
resets = <&src 2>;
@@ -169,8 +169,8 @@
reg = <0x70004000 0x4000>;
interrupts = <1>;
clocks = <&clks IMX5_CLK_ESDHC1_IPG_GATE>,
- <&clks IMX5_CLK_DUMMY>,
- <&clks IMX5_CLK_ESDHC1_PER_GATE>;
+ <&clks IMX5_CLK_DUMMY>,
+ <&clks IMX5_CLK_ESDHC1_PER_GATE>;
clock-names = "ipg", "ahb", "per";
status = "disabled";
};
@@ -180,8 +180,8 @@
reg = <0x70008000 0x4000>;
interrupts = <2>;
clocks = <&clks IMX5_CLK_ESDHC2_IPG_GATE>,
- <&clks IMX5_CLK_DUMMY>,
- <&clks IMX5_CLK_ESDHC2_PER_GATE>;
+ <&clks IMX5_CLK_DUMMY>,
+ <&clks IMX5_CLK_ESDHC2_PER_GATE>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
status = "disabled";
@@ -192,7 +192,7 @@
reg = <0x7000c000 0x4000>;
interrupts = <33>;
clocks = <&clks IMX5_CLK_UART3_IPG_GATE>,
- <&clks IMX5_CLK_UART3_PER_GATE>;
+ <&clks IMX5_CLK_UART3_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -204,7 +204,7 @@
reg = <0x70010000 0x4000>;
interrupts = <36>;
clocks = <&clks IMX5_CLK_ECSPI1_IPG_GATE>,
- <&clks IMX5_CLK_ECSPI1_PER_GATE>;
+ <&clks IMX5_CLK_ECSPI1_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -229,8 +229,8 @@
reg = <0x70020000 0x4000>;
interrupts = <3>;
clocks = <&clks IMX5_CLK_ESDHC3_IPG_GATE>,
- <&clks IMX5_CLK_DUMMY>,
- <&clks IMX5_CLK_ESDHC3_PER_GATE>;
+ <&clks IMX5_CLK_DUMMY>,
+ <&clks IMX5_CLK_ESDHC3_PER_GATE>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
status = "disabled";
@@ -241,8 +241,8 @@
reg = <0x70024000 0x4000>;
interrupts = <4>;
clocks = <&clks IMX5_CLK_ESDHC4_IPG_GATE>,
- <&clks IMX5_CLK_DUMMY>,
- <&clks IMX5_CLK_ESDHC4_PER_GATE>;
+ <&clks IMX5_CLK_DUMMY>,
+ <&clks IMX5_CLK_ESDHC4_PER_GATE>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
status = "disabled";
@@ -364,7 +364,7 @@
reg = <0x73fa0000 0x4000>;
interrupts = <39>;
clocks = <&clks IMX5_CLK_GPT_IPG_GATE>,
- <&clks IMX5_CLK_GPT_HF_GATE>;
+ <&clks IMX5_CLK_GPT_HF_GATE>;
clock-names = "ipg", "per";
};
@@ -378,7 +378,7 @@
compatible = "fsl,imx51-pwm", "fsl,imx27-pwm";
reg = <0x73fb4000 0x4000>;
clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>,
- <&clks IMX5_CLK_PWM1_HF_GATE>;
+ <&clks IMX5_CLK_PWM1_HF_GATE>;
clock-names = "ipg", "per";
interrupts = <61>;
};
@@ -388,7 +388,7 @@
compatible = "fsl,imx51-pwm", "fsl,imx27-pwm";
reg = <0x73fb8000 0x4000>;
clocks = <&clks IMX5_CLK_PWM2_IPG_GATE>,
- <&clks IMX5_CLK_PWM2_HF_GATE>;
+ <&clks IMX5_CLK_PWM2_HF_GATE>;
clock-names = "ipg", "per";
interrupts = <94>;
};
@@ -398,7 +398,7 @@
reg = <0x73fbc000 0x4000>;
interrupts = <31>;
clocks = <&clks IMX5_CLK_UART1_IPG_GATE>,
- <&clks IMX5_CLK_UART1_PER_GATE>;
+ <&clks IMX5_CLK_UART1_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -408,7 +408,7 @@
reg = <0x73fc0000 0x4000>;
interrupts = <32>;
clocks = <&clks IMX5_CLK_UART2_IPG_GATE>,
- <&clks IMX5_CLK_UART2_PER_GATE>;
+ <&clks IMX5_CLK_UART2_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -456,7 +456,7 @@
reg = <0x83fac000 0x4000>;
interrupts = <37>;
clocks = <&clks IMX5_CLK_ECSPI2_IPG_GATE>,
- <&clks IMX5_CLK_ECSPI2_PER_GATE>;
+ <&clks IMX5_CLK_ECSPI2_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -466,7 +466,7 @@
reg = <0x83fb0000 0x4000>;
interrupts = <6>;
clocks = <&clks IMX5_CLK_SDMA_GATE>,
- <&clks IMX5_CLK_SDMA_GATE>;
+ <&clks IMX5_CLK_SDMA_GATE>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
fsl,sdma-ram-script-name = "imx/sdma/sdma-imx51.bin";
@@ -479,7 +479,7 @@
reg = <0x83fc0000 0x4000>;
interrupts = <38>;
clocks = <&clks IMX5_CLK_CSPI_IPG_GATE>,
- <&clks IMX5_CLK_CSPI_IPG_GATE>;
+ <&clks IMX5_CLK_CSPI_IPG_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -582,8 +582,8 @@
reg = <0x83fec000 0x4000>;
interrupts = <87>;
clocks = <&clks IMX5_CLK_FEC_GATE>,
- <&clks IMX5_CLK_FEC_GATE>,
- <&clks IMX5_CLK_FEC_GATE>;
+ <&clks IMX5_CLK_FEC_GATE>,
+ <&clks IMX5_CLK_FEC_GATE>;
clock-names = "ipg", "ahb", "ptp";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 0777b41..88f9e09e 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -131,8 +131,8 @@
reg = <0x18000000 0x08000000>;
interrupts = <11 10>;
clocks = <&clks IMX5_CLK_IPU_GATE>,
- <&clks IMX5_CLK_IPU_DI0_GATE>,
- <&clks IMX5_CLK_IPU_DI1_GATE>;
+ <&clks IMX5_CLK_IPU_DI0_GATE>,
+ <&clks IMX5_CLK_IPU_DI1_GATE>;
clock-names = "bus", "di0", "di1";
resets = <&src 2>;
@@ -199,8 +199,8 @@
reg = <0x50004000 0x4000>;
interrupts = <1>;
clocks = <&clks IMX5_CLK_ESDHC1_IPG_GATE>,
- <&clks IMX5_CLK_DUMMY>,
- <&clks IMX5_CLK_ESDHC1_PER_GATE>;
+ <&clks IMX5_CLK_DUMMY>,
+ <&clks IMX5_CLK_ESDHC1_PER_GATE>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
status = "disabled";
@@ -211,8 +211,8 @@
reg = <0x50008000 0x4000>;
interrupts = <2>;
clocks = <&clks IMX5_CLK_ESDHC2_IPG_GATE>,
- <&clks IMX5_CLK_DUMMY>,
- <&clks IMX5_CLK_ESDHC2_PER_GATE>;
+ <&clks IMX5_CLK_DUMMY>,
+ <&clks IMX5_CLK_ESDHC2_PER_GATE>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
status = "disabled";
@@ -223,7 +223,7 @@
reg = <0x5000c000 0x4000>;
interrupts = <33>;
clocks = <&clks IMX5_CLK_UART3_IPG_GATE>,
- <&clks IMX5_CLK_UART3_PER_GATE>;
+ <&clks IMX5_CLK_UART3_PER_GATE>;
clock-names = "ipg", "per";
dmas = <&sdma 42 4 0>, <&sdma 43 4 0>;
dma-names = "rx", "tx";
@@ -237,7 +237,7 @@
reg = <0x50010000 0x4000>;
interrupts = <36>;
clocks = <&clks IMX5_CLK_ECSPI1_IPG_GATE>,
- <&clks IMX5_CLK_ECSPI1_PER_GATE>;
+ <&clks IMX5_CLK_ECSPI1_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -264,8 +264,8 @@
reg = <0x50020000 0x4000>;
interrupts = <3>;
clocks = <&clks IMX5_CLK_ESDHC3_IPG_GATE>,
- <&clks IMX5_CLK_DUMMY>,
- <&clks IMX5_CLK_ESDHC3_PER_GATE>;
+ <&clks IMX5_CLK_DUMMY>,
+ <&clks IMX5_CLK_ESDHC3_PER_GATE>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
status = "disabled";
@@ -276,8 +276,8 @@
reg = <0x50024000 0x4000>;
interrupts = <4>;
clocks = <&clks IMX5_CLK_ESDHC4_IPG_GATE>,
- <&clks IMX5_CLK_DUMMY>,
- <&clks IMX5_CLK_ESDHC4_PER_GATE>;
+ <&clks IMX5_CLK_DUMMY>,
+ <&clks IMX5_CLK_ESDHC4_PER_GATE>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
status = "disabled";
@@ -419,7 +419,7 @@
reg = <0x53fa0000 0x4000>;
interrupts = <39>;
clocks = <&clks IMX5_CLK_GPT_IPG_GATE>,
- <&clks IMX5_CLK_GPT_HF_GATE>;
+ <&clks IMX5_CLK_GPT_HF_GATE>;
clock-names = "ipg", "per";
};
@@ -440,11 +440,11 @@
reg = <0x53fa8008 0x4>;
gpr = <&gpr>;
clocks = <&clks IMX5_CLK_LDB_DI0_SEL>,
- <&clks IMX5_CLK_LDB_DI1_SEL>,
- <&clks IMX5_CLK_IPU_DI0_SEL>,
- <&clks IMX5_CLK_IPU_DI1_SEL>,
- <&clks IMX5_CLK_LDB_DI0_GATE>,
- <&clks IMX5_CLK_LDB_DI1_GATE>;
+ <&clks IMX5_CLK_LDB_DI1_SEL>,
+ <&clks IMX5_CLK_IPU_DI0_SEL>,
+ <&clks IMX5_CLK_IPU_DI1_SEL>,
+ <&clks IMX5_CLK_LDB_DI0_GATE>,
+ <&clks IMX5_CLK_LDB_DI1_GATE>;
clock-names = "di0_pll", "di1_pll",
"di0_sel", "di1_sel",
"di0", "di1";
@@ -486,7 +486,7 @@
compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
reg = <0x53fb4000 0x4000>;
clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>,
- <&clks IMX5_CLK_PWM1_HF_GATE>;
+ <&clks IMX5_CLK_PWM1_HF_GATE>;
clock-names = "ipg", "per";
interrupts = <61>;
};
@@ -496,7 +496,7 @@
compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
reg = <0x53fb8000 0x4000>;
clocks = <&clks IMX5_CLK_PWM2_IPG_GATE>,
- <&clks IMX5_CLK_PWM2_HF_GATE>;
+ <&clks IMX5_CLK_PWM2_HF_GATE>;
clock-names = "ipg", "per";
interrupts = <94>;
};
@@ -506,7 +506,7 @@
reg = <0x53fbc000 0x4000>;
interrupts = <31>;
clocks = <&clks IMX5_CLK_UART1_IPG_GATE>,
- <&clks IMX5_CLK_UART1_PER_GATE>;
+ <&clks IMX5_CLK_UART1_PER_GATE>;
clock-names = "ipg", "per";
dmas = <&sdma 18 4 0>, <&sdma 19 4 0>;
dma-names = "rx", "tx";
@@ -518,7 +518,7 @@
reg = <0x53fc0000 0x4000>;
interrupts = <32>;
clocks = <&clks IMX5_CLK_UART2_IPG_GATE>,
- <&clks IMX5_CLK_UART2_PER_GATE>;
+ <&clks IMX5_CLK_UART2_PER_GATE>;
clock-names = "ipg", "per";
dmas = <&sdma 12 4 0>, <&sdma 13 4 0>;
dma-names = "rx", "tx";
@@ -530,7 +530,7 @@
reg = <0x53fc8000 0x4000>;
interrupts = <82>;
clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>,
- <&clks IMX5_CLK_CAN1_SERIAL_GATE>;
+ <&clks IMX5_CLK_CAN1_SERIAL_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -540,7 +540,7 @@
reg = <0x53fcc000 0x4000>;
interrupts = <83>;
clocks = <&clks IMX5_CLK_CAN2_IPG_GATE>,
- <&clks IMX5_CLK_CAN2_SERIAL_GATE>;
+ <&clks IMX5_CLK_CAN2_SERIAL_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -603,7 +603,7 @@
reg = <0x53ff0000 0x4000>;
interrupts = <13>;
clocks = <&clks IMX5_CLK_UART4_IPG_GATE>,
- <&clks IMX5_CLK_UART4_PER_GATE>;
+ <&clks IMX5_CLK_UART4_PER_GATE>;
clock-names = "ipg", "per";
dmas = <&sdma 2 4 0>, <&sdma 3 4 0>;
dma-names = "rx", "tx";
@@ -635,7 +635,7 @@
reg = <0x63f90000 0x4000>;
interrupts = <86>;
clocks = <&clks IMX5_CLK_UART5_IPG_GATE>,
- <&clks IMX5_CLK_UART5_PER_GATE>;
+ <&clks IMX5_CLK_UART5_PER_GATE>;
clock-names = "ipg", "per";
dmas = <&sdma 16 4 0>, <&sdma 17 4 0>;
dma-names = "rx", "tx";
@@ -656,7 +656,7 @@
reg = <0x63fac000 0x4000>;
interrupts = <37>;
clocks = <&clks IMX5_CLK_ECSPI2_IPG_GATE>,
- <&clks IMX5_CLK_ECSPI2_PER_GATE>;
+ <&clks IMX5_CLK_ECSPI2_PER_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -666,7 +666,7 @@
reg = <0x63fb0000 0x4000>;
interrupts = <6>;
clocks = <&clks IMX5_CLK_SDMA_GATE>,
- <&clks IMX5_CLK_SDMA_GATE>;
+ <&clks IMX5_CLK_SDMA_GATE>;
clock-names = "ipg", "ahb";
#dma-cells = <3>;
fsl,sdma-ram-script-name = "imx/sdma/sdma-imx53.bin";
@@ -679,7 +679,7 @@
reg = <0x63fc0000 0x4000>;
interrupts = <38>;
clocks = <&clks IMX5_CLK_CSPI_IPG_GATE>,
- <&clks IMX5_CLK_CSPI_IPG_GATE>;
+ <&clks IMX5_CLK_CSPI_IPG_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};
@@ -755,8 +755,8 @@
reg = <0x63fec000 0x4000>;
interrupts = <87>;
clocks = <&clks IMX5_CLK_FEC_GATE>,
- <&clks IMX5_CLK_FEC_GATE>,
- <&clks IMX5_CLK_FEC_GATE>;
+ <&clks IMX5_CLK_FEC_GATE>,
+ <&clks IMX5_CLK_FEC_GATE>;
clock-names = "ipg", "ahb", "ptp";
status = "disabled";
};
@@ -766,7 +766,7 @@
reg = <0x63ff0000 0x1000>;
interrupts = <92>;
clocks = <&clks IMX5_CLK_TVE_GATE>,
- <&clks IMX5_CLK_IPU_DI1_SEL>;
+ <&clks IMX5_CLK_IPU_DI1_SEL>;
clock-names = "tve", "di_sel";
status = "disabled";
@@ -782,7 +782,7 @@
reg = <0x63ff4000 0x1000>;
interrupts = <9>;
clocks = <&clks IMX5_CLK_VPU_REFERENCE_GATE>,
- <&clks IMX5_CLK_VPU_GATE>;
+ <&clks IMX5_CLK_VPU_GATE>;
clock-names = "per", "ahb";
resets = <&src 1>;
iram = <&ocram>;
@@ -793,7 +793,7 @@
reg = <0x63ff8000 0x4000>;
interrupts = <19 20>;
clocks = <&clks IMX5_CLK_SAHARA_IPG_GATE>,
- <&clks IMX5_CLK_SAHARA_IPG_GATE>;
+ <&clks IMX5_CLK_SAHARA_IPG_GATE>;
clock-names = "ipg", "ahb";
};
};
diff --git a/arch/arm/boot/dts/imx6dl-riotboard.dts b/arch/arm/boot/dts/imx6dl-riotboard.dts
index 75d7343..2cb7282 100644
--- a/arch/arm/boot/dts/imx6dl-riotboard.dts
+++ b/arch/arm/boot/dts/imx6dl-riotboard.dts
@@ -390,7 +390,7 @@
MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b030 /* AR8035 pin strapping: MODE#3: pull up */
MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x130b0 /* AR8035 pin strapping: MODE#0: pull down */
MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8 /* GPIO16 -> AR8035 25MHz */
- MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x130b0 /* RGMII_nRST */
+ MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x130b0 /* RGMII_nRST */
MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28 0x180b0 /* AR8035 interrupt */
MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
>;
diff --git a/arch/arm/boot/dts/imx6dl-tx6dl-comtft.dts b/arch/arm/boot/dts/imx6dl-tx6dl-comtft.dts
index 063fe75..aac42ac 100644
--- a/arch/arm/boot/dts/imx6dl-tx6dl-comtft.dts
+++ b/arch/arm/boot/dts/imx6dl-tx6dl-comtft.dts
@@ -105,7 +105,7 @@
pixelclk-active = <1>;
};
};
- };
+ };
};
&can1 {
diff --git a/arch/arm/boot/dts/imx6dl-tx6u-801x.dts b/arch/arm/boot/dts/imx6dl-tx6u-801x.dts
index b7a7284..d1f1298 100644
--- a/arch/arm/boot/dts/imx6dl-tx6u-801x.dts
+++ b/arch/arm/boot/dts/imx6dl-tx6u-801x.dts
@@ -199,7 +199,7 @@
pixelclk-active = <0>;
};
};
- };
+ };
};
&ipu1_di0_disp0 {
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index c139ac0..1f47713 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -23,5 +23,5 @@
};
&sata {
- status = "okay";
+ status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts b/arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts
index 65e95ae..71746ed 100644
--- a/arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts
+++ b/arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts
@@ -105,7 +105,7 @@
pixelclk-active = <1>;
};
};
- };
+ };
};
&can1 {
diff --git a/arch/arm/boot/dts/imx6q-tx6q-1010.dts b/arch/arm/boot/dts/imx6q-tx6q-1010.dts
index 20cd0e7..f9cd21a 100644
--- a/arch/arm/boot/dts/imx6q-tx6q-1010.dts
+++ b/arch/arm/boot/dts/imx6q-tx6q-1010.dts
@@ -199,7 +199,7 @@
pixelclk-active = <0>;
};
};
- };
+ };
};
&ipu1_di0_disp0 {
diff --git a/arch/arm/boot/dts/imx6q-tx6q-1020-comtft.dts b/arch/arm/boot/dts/imx6q-tx6q-1020-comtft.dts
index 9ed243b..959ff3fb 100644
--- a/arch/arm/boot/dts/imx6q-tx6q-1020-comtft.dts
+++ b/arch/arm/boot/dts/imx6q-tx6q-1020-comtft.dts
@@ -105,7 +105,7 @@
pixelclk-active = <1>;
};
};
- };
+ };
};
&can1 {
diff --git a/arch/arm/boot/dts/imx6q-tx6q-1020.dts b/arch/arm/boot/dts/imx6q-tx6q-1020.dts
index 347b531..b49133d 100644
--- a/arch/arm/boot/dts/imx6q-tx6q-1020.dts
+++ b/arch/arm/boot/dts/imx6q-tx6q-1020.dts
@@ -199,7 +199,7 @@
pixelclk-active = <0>;
};
};
- };
+ };
};
&ds1339 {
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dtsi b/arch/arm/boot/dts/imx6sx-sdb.dtsi
index 9d70cfd..7327bcd 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dtsi
+++ b/arch/arm/boot/dts/imx6sx-sdb.dtsi
@@ -192,10 +192,10 @@
};
&i2c4 {
- clock-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c4>;
- status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ status = "okay";
codec: wm8962@1a {
compatible = "wlf,wm8962";
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 9526c38..bd9fe67 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -858,7 +858,7 @@
fsl,num-tx-queues=<3>;
fsl,num-rx-queues=<3>;
status = "disabled";
- };
+ };
mlb: mlb@0218c000 {
reg = <0x0218c000 0x4000>;
@@ -1181,7 +1181,7 @@
fsl,adck-max-frequency = <30000000>, <40000000>,
<20000000>;
status = "disabled";
- };
+ };
adc2: adc@02284000 {
compatible = "fsl,imx6sx-adc", "fsl,vf610-adc";
@@ -1192,7 +1192,7 @@
fsl,adck-max-frequency = <30000000>, <40000000>,
<20000000>;
status = "disabled";
- };
+ };
wdog3: wdog@02288000 {
compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH RESEND 1/2] dt: bindings: add allwinner,otg-routed property for phy-sun4i-usb
From: Hans de Goede @ 2016-10-26 10:14 UTC (permalink / raw)
To: Icenowy Zheng, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Kishon Vijay Abraham I
Cc: Mark Rutland, Reinder de Haan,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
In-Reply-To: <4534561477471963-MkNZHmQ5vhFuio3avFS2gg@public.gmane.org>
Hi,
On 26-10-16 10:52, Icenowy Zheng wrote:
>
>
> 26.10.2016, 16:28, "Hans de Goede" <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>:
>> Hi,
>>
>> On 25-10-16 06:11, Icenowy Zheng wrote:
>>> On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
>>> the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
>>> (which is a Host-only controller, but more stable and easy to implement).
>>>
>>> This property marks whether on a certain board which controller should be
>>> attached to the PHY.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>
>> Icenowy, I appreciate your work on this, but we really need full otg
>> support with dynamic switching rather then hardwiring the routing, so
>> this cannot go in as is.
>
> Now I have both PHY0 controllers' drivers.
>
> In the tree of https://github.com/Icenowy/linux/tree/ice-a64-v6.1 , I have already
> enabled MUSB controller.
>
> And this patchset is for those prefer a stable USB host implement to dual-role
> implementation. MUSB is a good UDC, but not a good host controller. My USB
> sound card cannot work on MUSB on A33. Even connecting a R8's MUSB (Serial
> Gadget) to an A33's MUSB cannot work.
The idea is for dual-role setups to used the MUSB in gadget mode and the EHCI/OHCI
pair when in host mode. So for otg setups you would runtime change the mux
from one controller to the other based on the id pin value.
Take a look at drivers/phy/phy-sun4i-usb.c, around line 512:
if (id_det != data->id_det) {
...
}
This deals with id_det changes (including the initial id_det "change"
for hardwired host-only ports). This currently assumes that the musb
will be used for host mode too, we will want to change this to
something like this:
if (id_det != data->id_det) {
if (data->cfg->separate_phy0_host_controller) {
if (id_det) {
/* Change to gadget mode (id_det == 1), switch phy mux to musb */
actual code to switch phy mux to musb...
} else {
/* Change to host mode (id_det == 0), switch phy mux to ehci/ohci */
actual code to switch phy mux to ehci/ohci...
}
}
/* old code */
}
Note this will then still rely on the musb code to actually turn
the regulator on, so you do need to have the musb driver build and
loaded. This can be fixed but lets start with the above.
If you combine this with dr_mode = "host"; in the dts, then
sun4i_usb_phy0_get_id_det() will return 0 so on its first run
sun4i_usb_phy0_id_vbus_det_scan() will throw the mux to the ehci/ohci
and everything should work as you want without needing the custom
"allwinner,otg-routed" property, and we should be more or less
ready to support full otg on other boards.
Regards,
Hans
>
> See the IRC log between Andre and me,
> https://irclog.whitequark.org/linux-sunxi/2016-10-24#18012695; .
>
>>
>> NACK.
>>
>> Regards,
>>
>> Hans
>>
>>> ---
>>> Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>>> index 287150d..a63c766 100644
>>> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>>> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>>> @@ -36,6 +36,12 @@ Optional properties:
>>> - usb1_vbus-supply : regulator phandle for controller usb1 vbus
>>> - usb2_vbus-supply : regulator phandle for controller usb2 vbus
>>>
>>> +Optional properties for H3 or A64 SoCs:
>>> +- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
>>> + MUSB. (boolean, if this property is set, the OHCI/EHCI
>>> + controllers at PHY0 should be enabled and the MUSB
>>> + controller must *NOT* be enabled)
>>> +
>>> Example:
>>> usbphy: phy@0x01c13400 {
>>> #phy-cells = <1>;
^ permalink raw reply
* Re: [PATCH v6 4/5] ARM: DTS: da850: Add cfgchip syscon node
From: Sekhar Nori @ 2016-10-26 10:19 UTC (permalink / raw)
To: David Lechner, Kevin Hilman, Rob Herring, Mark Rutland
Cc: Axel Haslam, Sergei Shtylyov, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477451211-31979-5-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:
> Add a syscon node for the SoC CFGCHIPn registers. This is needed for
> the new usb phy driver.
>
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
Applied to v4.10/dt. Changed "DTS" in subject line to small case. ARM
device-tree patches have been following that.
Thanks
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/6] Documentation: devicetree: dwc3: Add interrupt moderation
From: Sergei Shtylyov @ 2016-10-26 10:21 UTC (permalink / raw)
To: John Youn, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland
In-Reply-To: <e7a864e5a2af12d5a8d97f2591065f4aa85f86cb.1477424426.git.johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Hello.
On 10/25/2016 10:42 PM, John Youn wrote:
> Add interrupt moderation interval binding for dwc3.
>
> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/dwc3.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
> index e3e6983..17de9fc 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -53,6 +53,7 @@ Optional properties:
> - snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ
> register for post-silicon frame length adjustment when the
> fladj_30mhz_sdbnd signal is invalid or incorrect.
> + - snps,imod_interval: the interrupt moderation interval.
Hyphens are preferred in the DT node/prop names.
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG MSI
From: Mark Rutland @ 2016-10-26 10:22 UTC (permalink / raw)
To: M.H. Lian
Cc: Robin Murphy, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Marc Zyngier, Stuart Yoder, Scott Wood, Leo Li, Shawn Guo,
Mingkai Hu
In-Reply-To: <VI1PR04MB161582C628C5EA4CD08B15C6E8AB0@VI1PR04MB1615.eurprd04.prod.outlook.com>
On Wed, Oct 26, 2016 at 06:55:22AM +0000, M.H. Lian wrote:
> Hi Robin,
>
> Please see my comments inline.
>
> Thanks,
> Minghuan
>
> > -----Original Message-----
> > From: Robin Murphy [mailto:robin.murphy@arm.com]
> > Sent: Tuesday, October 25, 2016 9:01 PM
> > To: M.H. Lian <minghuan.lian@nxp.com>; linux-arm-
> > kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> > devicetree@vger.kernel.org
> > Cc: Marc Zyngier <marc.zyngier@arm.com>; Stuart Yoder
> > <stuart.yoder@nxp.com>; Leo Li <leoyang.li@nxp.com>; Scott Wood
> > <scott.wood@nxp.com>; Shawn Guo <shawnguo@kernel.org>; Mingkai Hu
> > <mingkai.hu@nxp.com>
> > Subject: Re: [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG
> > MSI
> >
> > On 25/10/16 13:35, Minghuan Lian wrote:
> > > 1. The different version of a SoC may have different MSI
> > > implementation. But compatible "fsl,<soc-name>-msi" can not describe
> > > the SoC version.
> >
> > Can't it?
> >
> > compatible = "fsl-ls1043a-rev11-msi";
> >
> > Oh, I guess it can!
> >
> > Joking aside, if there are multiple versions of a piece of hardware which
> > require *different* treatment by drivers, then it is obviously wrong to use
> > the same compatible string because *they are not compatible*.
> >
> [Minghuan Lian] Yes, but Rev1.0 and Rev1.1 SoC will use the same dts files.
> We cannot create different dts files for each revision of the same kind of SoC.
... why?
The DT should describe the hardware; if hardware differs then it should
have a different DT.
> It means that there are different variants in the different versions
> of the same SoC that will use the same compatible string.
Why can you not add a string for each variant, in addition to the SoC
string? We do that elsewhere.
> So I have to use SoC match interface to get the versions.
>
> I'm too radical. I do not want to first check SoC family via
> compatible string and then check revision via SoC match or SVR.
You can have *both* in the the compatible string list, e.g. at the top
level:
compatible = "vendor,soc-rev", "vendor-soc";
For devices which differ, this can be encoded similarly in the device
compatible string list.
> I selected the "SoC match" like the following to get the related information at only one place.
>
> static struct soc_device_attribute soc_msi_matches[] = {
> { .family = "QorIQ LS1021A",
> .data = &ls1021_msi_cfg },
> { .family = "QorIQ LS1012A",
> .data = &ls1021_msi_cfg },
> { .family = "QorIQ LS1043A", .revision = "1.0",
> .data = &ls1021_msi_cfg },
> { .family = "QorIQ LS1043A", .revision = "1.1",
> .data = &ls1043_rev11_msi_cfg },
> { .family = "QorIQ LS1046A",
> .data = &ls1046_msi_cfg },
> { },
> };
>
> I will remain the SoC related compatible and try to describe the
> difference via some kind of the property.
As commented on the driver side, this should be described with DT
properties on the devices.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v6 5/5] ARM: DTS: da850: Add usb phy node
From: Sekhar Nori @ 2016-10-26 10:26 UTC (permalink / raw)
To: David Lechner, Kevin Hilman, Rob Herring, Mark Rutland
Cc: linux-arm-kernel, devicetree, Sergei Shtylyov, Axel Haslam,
linux-kernel
In-Reply-To: <1477451211-31979-6-git-send-email-david@lechnology.com>
On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:
> Add a node for the new usb phy driver.
changed this to:
Add a node for usb phy device. This device
controls both the USB 1.1 and USB 2.0 PHYs.
mainly because the node is for the device, not the driver.
>
> Signed-off-by: David Lechner <david@lechnology.com>
Applied to v4.10/dt
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v3 01/12] dt: arm: shmobile: add H3ULCB board DT bindings
From: Vladimir Barinov @ 2016-10-26 10:27 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, Linux-Renesas, Yusuke Goda
In-Reply-To: <83a48012-888e-3f86-c9a0-8cddb05ee2fe@cogentembedded.com>
Hi Geert,
I've got this message from Renesas:
"
Please use H3ULCB/M3ULCB in upstream.
# I got an agreement among parties.
Board name in community: ULCB (= development code name)
Official name (product/brand name): Starter Kit Pro/Premier
"
Renaming H3ULCB -> H3SK is not desired for Renesas.
What do you think to append the product/brand name only? :
- H3ULCB (RTP0RC7795SKB00010S)
+ H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKB00010S)
compatible = "renesas,h3ulcb", "renesas,r8a7795";
Regards,
Vladimir
On 25.10.2016 18:06, Vladimir Barinov wrote:
> Hi Geert,
>
> On 25.10.2016 15:48, Geert Uytterhoeven wrote:
>> Hi Vladimir,
>>
>> On Wed, Aug 31, 2016 at 12:02 PM, Vladimir Barinov
>> <vladimir.barinov@cogentembedded.com> wrote:
>>> Add H3ULCB Device tree bindings Documentation, listing it as a
>>> supported
>>> board.
>>>
>>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>>> Acked-by: Rob Herring <robh@kernel.org>
>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>> ---
>>> Changes in version 2:
>>> - none
>>> Changes in version 3:
>>> - none
>>>
>>> Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt
>>> b/Documentation/devicetree/bindings/arm/shmobile.txt
>>> index 5484c31d..2f0b716 100644
>>> --- a/Documentation/devicetree/bindings/arm/shmobile.txt
>>> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt
>>> @@ -49,6 +49,8 @@ Boards:
>>> compatible = "renesas,genmai", "renesas,r7s72100"
>>> - Gose
>>> compatible = "renesas,gose", "renesas,r8a7793"
>>> + - H3ULCB (RTP0RC7795SKB00010S)
>>> + compatible = "renesas,h3ulcb", "renesas,r8a7795";
>> Should this have been
>>
>> H3SK (R-Car Starter Kit Premier, RTP0RC7795SKB00010S)
>> compatible = "renesas,h3sk", "renesas,r8a7795";
>>
>> instead?
> Actually you are right, since Renesas naming policy changed:
> originally the assigned name was H3ULCB and all boards that I have
> labled as ULCB.
> Now the official name is "R-Car Starter Kit Premier" and "R-Car
> Starter Kit Pro" for H3/M3 respectively.
>
> I've got this message from Renesas:
> "
>
> 1. Official name for Gen3 low cost board
>
> R-Car Starter Kit Premier (We called "H3ULCB")
> R-Car Starter Kit Pro (We called "M3ULCB")
>
> 1-1. Please change the "M3ULCB/H3ULCB" to
> "R-Car Starter Kit Pro/Premier" on elinux.
> 1-2. You DON'T have to change in source code.
> You can use ULCB in Kernel, u-boot, Yocto recipe.
> 1-3. Please explain relations of "ULCB" and "Starter Kit" on elinux.
> Ex) R-Car Starter Kit Premier = H3ULCB
> "
>
>
> What do think about changing only first line and leave "compatible" as
> is, since h3ulcb have been using a while by different customers and
> renaming of the board name will confuse? (If we change it to
> "renesas,h3sk " then probably we need to rename the dts file
> r8a7795-h3ulcb.dts and its content)
>
> - - H3ULCB (RTP0RC7795SKB00010S)
> + - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKB00010S)
>
>
> And would be the best for M3 Starter Kit?
> The M3 Starter Kit board labeled as "M3 StarterKit", bit it is the
> same board with different SiP.
>
> Should it look like:
>
> M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKB00010S)
> compatible = "renesas,m3ulcb", "renesas,r8a7796";
>
> or
>
> M3SK (R-Car Starter Kit Pro, RTP0RC7796SKB00010S)
> compatible = "renesas,m3sk", "renesas,r8a7796";
>
>
> Regards,
> Vladimir
>>
>> Gr{oetje,eeting}s,
>>
>> Geert
>>
>> --
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
>> geert@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a
>> hacker. But
>> when I'm talking to journalists I just say "programmer" or something
>> like that.
>> -- Linus Torvalds
>
>
^ permalink raw reply
* Re: [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG MSI
From: Mark Rutland @ 2016-10-26 10:31 UTC (permalink / raw)
To: Minghuan Lian
Cc: linux-arm-kernel, linux-kernel, devicetree, Marc Zyngier,
Stuart Yoder, Yang-Leo Li, Scott Wood, Shawn Guo, Mingkai Hu
In-Reply-To: <1477398945-22774-1-git-send-email-Minghuan.Lian@nxp.com>
On Tue, Oct 25, 2016 at 08:35:40PM +0800, Minghuan Lian wrote:
> 1. The different version of a SoC may have different MSI
> implementation. But compatible "fsl,<soc-name>-msi" can not describe
> the SoC version.
Surely, "fsl,<soc-name>-<rev>-msi" can describe this?
If the hardware differs, it needs a new compatible string.
If there's some configuration value that varies across revisions (e.g.
number of slots), you can add a proeprty to describe that explciitly.
> The MSI driver will use SoC match interface to get
> SoC type and version instead of compatible string. So all MSI node
> can use the common compatible "fsl,ls-scfg-msi" and the original
> compatible is unnecessary.
>
> 2. Layerscape SoCs may have one or several MSI controllers.
> In order to increase MSI interrupt number of a PCIe, the patch
> moves all MSI node into the parent node "msi-controller". So a
> PCIe can request MSI from all the MSI controllers.
This is not necessary, and does not represent a real block of hardware.
So NAK for this approach.
The msi-parent property can contain a list of MSI controllers. See the
examples in
Documentation/devicetree/bindings/interrupt-controller/msi.txt.
Likewise, the msi-map property can map to a number of MSI controllers.
If the core code can only consider one at a time, then that's an issue
to be addressed in core code, not one to be bodged around in bindings.
>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
> ---
> .../interrupt-controller/fsl,ls-scfg-msi.txt | 57 +++++++++++++++++++---
> 1 file changed, 49 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
> index 9e38949..29f95fd 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
> @@ -1,18 +1,28 @@
> * Freescale Layerscape SCFG PCIe MSI controller
>
> +Layerscape SoCs may have one or multiple MSI controllers.
> +Each MSI controller must be showed as a child node.
> +
> Required properties:
>
> -- compatible: should be "fsl,<soc-name>-msi" to identify
> - Layerscape PCIe MSI controller block such as:
> - "fsl,1s1021a-msi"
> - "fsl,1s1043a-msi"
> +- compatible: should be "fsl,ls-scfg-msi"
This breaks old DTBs, and throws away information which you describe
above as valuable. So another NAK for that.
> +- #address-cells: must be 2
> +- #size-cells: must be 2
> +- ranges: allows valid 1:1 translation between child's address space and
> + parent's address space
> - msi-controller: indicates that this is a PCIe MSI controller node
> +
> +Required child node:
> +A child node must exist to represent the MSI controller.
> +The following are properties specific to those nodes:
Also, as above, the approach of gathering MSI controllers in this manner
is wrong.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH 3/6] arm64: dts: ls1043a: update MSI and PCIe node
From: Mark Rutland @ 2016-10-26 10:33 UTC (permalink / raw)
To: Minghuan Lian
Cc: linux-arm-kernel, linux-kernel, devicetree, Marc Zyngier,
Stuart Yoder, Yang-Leo Li, Scott Wood, Shawn Guo, Mingkai Hu
In-Reply-To: <1477398945-22774-3-git-send-email-Minghuan.Lian@nxp.com>
On Tue, Oct 25, 2016 at 08:35:42PM +0800, Minghuan Lian wrote:
> 3. The rev1.1 of LS1043a moves PCIe INTB/C/D interrupts to MSI controller.
[...]
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> index 41e5dc1..5295bb9 100644
> - interrupt-map = <0000 0 0 1 &gic 0 110 0x4>,
> - <0000 0 0 2 &gic 0 111 0x4>,
> - <0000 0 0 3 &gic 0 112 0x4>,
> - <0000 0 0 4 &gic 0 113 0x4>;
> + interrupt-map = <0000 0 0 1 &gic 0 110 0x4>;
[...]
> - interrupt-map = <0000 0 0 1 &gic 0 120 0x4>,
> - <0000 0 0 2 &gic 0 121 0x4>,
> - <0000 0 0 3 &gic 0 122 0x4>,
> - <0000 0 0 4 &gic 0 123 0x4>;
> + interrupt-map = <0000 0 0 1 &gic 0 120 0x4>;
> };
[...]
> - interrupt-map = <0000 0 0 1 &gic 0 154 0x4>,
> - <0000 0 0 2 &gic 0 155 0x4>,
> - <0000 0 0 3 &gic 0 156 0x4>,
> - <0000 0 0 4 &gic 0 157 0x4>;
> + interrupt-map = <0000 0 0 1 &gic 0 154 0x4>;
Per the description above, this breaks revisions prior to 1.1.
Please, split the rev 1.1 changes into a new DTS. Share the common parts
in a common dtsi.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH 5/6] arm64: dts: ls1043a: update gic dts node
From: Mark Rutland @ 2016-10-26 10:35 UTC (permalink / raw)
To: Minghuan Lian
Cc: linux-arm-kernel, linux-kernel, devicetree, Marc Zyngier,
Stuart Yoder, Yang-Leo Li, Gong Qianyu, Scott Wood, Shawn Guo,
Mingkai Hu
In-Reply-To: <1477398945-22774-5-git-send-email-Minghuan.Lian@nxp.com>
On Tue, Oct 25, 2016 at 08:35:44PM +0800, Minghuan Lian wrote:
> From: Gong Qianyu <Qianyu.Gong@nxp.com>
>
> In order to support kvm, rev1.1 LS1043a GIC register has been
> changed to align as 64K. The patch updates GIC node according to
> the rev1.1 hardware.
>
> Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> index 5295bb9..da1809d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> @@ -144,10 +144,10 @@
> compatible = "arm,gic-400";
> #interrupt-cells = <3>;
> interrupt-controller;
> - reg = <0x0 0x1401000 0 0x1000>, /* GICD */
> - <0x0 0x1402000 0 0x2000>, /* GICC */
> - <0x0 0x1404000 0 0x2000>, /* GICH */
> - <0x0 0x1406000 0 0x2000>; /* GICV */
> + reg = <0x0 0x1410000 0 0x10000>, /* GICD */
> + <0x0 0x1420000 0 0x20000>, /* GICC */
> + <0x0 0x1440000 0 0x20000>, /* GICH */
> + <0x0 0x1460000 0 0x20000>; /* GICV */
... this breaks HW prior to rev1.1, then.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v4 4/5] mm: make processing of movable_node arch-specific
From: Michael Ellerman @ 2016-10-26 10:52 UTC (permalink / raw)
To: Reza Arbab, Balbir Singh
Cc: Benjamin Herrenschmidt, Paul Mackerras, Rob Herring, Frank Rowand,
Andrew Morton, Bharata B Rao, Nathan Fontenot, Stewart Smith,
Alistair Popple, Aneesh Kumar K.V, Tang Chen, linux-kernel,
linuxppc-dev, devicetree, linux-mm
In-Reply-To: <20161026004929.h6v54dhehk4yvmwm@arbab-vm>
Reza Arbab <arbab@linux.vnet.ibm.com> writes:
> On Wed, Oct 26, 2016 at 09:34:18AM +1100, Balbir Singh wrote:
>>I still believe we need your changes, I was wondering if we've tested
>>it against normal memory nodes and checked if any memblock
>>allocations end up there. Michael showed me some memblock
>>allocations on node 1 of a two node machine with movable_node
>
> The movable_node option is x86-only. Both of those nodes contain normal
> memory, so allocations on both are allowed.
>
>>> Longer; if you use "movable_node", x86 can identify these nodes at
>>> boot. They call memblock_mark_hotplug() while parsing the SRAT. Then,
>>> when the zones are initialized, those markings are used to determine
>>> ZONE_MOVABLE.
>>>
>>> We have no analog of this SRAT information, so our movable nodes can
>>> only be created post boot, by hotplugging and explicitly onlining
>>> with online_movable.
>>
>>Is this true for all of system memory as well or only for nodes
>>hotplugged later?
>
> As far as I know, power has nothing like the SRAT that tells us, at
> boot, which memory is hotpluggable.
On pseries we have the ibm,dynamic-memory device tree property, which
can contain ranges of memory that are not yet "assigned to the
partition" - ie. can be hotplugged later.
So in general that statement is not true.
But I think you're focused on bare-metal, in which case you might be
right. But that doesn't mean we couldn't have a similar property, if
skiboot/hostboot knew what the ranges of memory were going to be.
cheers
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox