* [PATCH v3 0/3] Remove clocks dependency from SCM driver
From: Sarangdhar Joshi @ 2016-11-16 1:19 UTC (permalink / raw)
To: Andy Gross, David Brown, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Bjorn Andersson
Cc: Sarangdhar Joshi, linux-arm-msm, linux-soc, devicetree,
linux-arm-kernel, linux-kernel, Stephen Boyd, Trilok Soni
On earlier chiptsets (APQ8064, MSM8660, MSM8690, MSM8916,
APQ8084, MSM8974) crypto operations of TZ were depends on crypto
clocks controlled by users/clients. However on MSM8996 crypto clocks
control is handled internally in TZ itself. The current series of
patches handle this clock dependency in SCM driver.
Changes since v2:
- Use typecast of 'unsigned long' for pointer (Stephen)
Changes since v1:
- Added Rob's Acked-by
- Removed of_device_is_compatible check from probe (Stephen)
- Modified typecast to take care of 32-bit pointer
Sarangdhar Joshi (3):
dt-bindings: firmware: scm: Add MSM8996 DT bindings
firmware: qcom: scm: Remove core, iface and bus clocks dependency
firmware: qcom: scm: Return PTR_ERR when devm_clk_get fails
.../devicetree/bindings/firmware/qcom,scm.txt | 2 +
drivers/firmware/qcom_scm.c | 49 ++++++++++++++++------
2 files changed, 39 insertions(+), 12 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [RESEND PATCH 2/2] PCI: rockchip: Add quirk to disable RC's ASPM L0s
From: Shawn Lin @ 2016-11-16 0:52 UTC (permalink / raw)
To: Rob Herring
Cc: Shawn Lin, Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wenrui Li,
Brian Norris, Jeffy Chen, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161115222649.uymslcg2fyfwtxpd@rob-hp-laptop>
Hi Rob,
On 2016/11/16 6:26, Rob Herring wrote:
> On Mon, Nov 14, 2016 at 12:11:06PM +0800, Shawn Lin wrote:
>> Rockchip's RC outputs 100MHz reference clock but there are
>> two methods for PHY to generate it.
>>
>> (1)One of them is to use system PLL to generate 100MHz clock and
>> the PHY will relock it and filter signal noise then outputs the
>> reference clock.
>>
>> (2)Another way is to share Soc's 24MHZ crystal oscillator with
>> PHY and force PHY's DLL to generate 100MHz internally.
>>
>> When using case(2), the exit from L0s doesn't work fine occasionally
>> due to the broken design of RC receiver's logical circuit. So even if
>> we use extended-synch, it still fails for PHY to relock the bits from
>> FTS sometimes. This will hang the system.
>>
>> Maybe we could argue that why not use case(1) to avoid it? The reason
>> is that as we could see the reference clock is derived from system PLL
>> and the path from it to PHY isn't so clean which means there are some
>> noise introduced by power-domain and other buses can't be filterd out
>> by PHY and we could see noise from the frequency spectrum by oscilloscope.
>> This makes the TX compatibility test a little difficult to pass the spec.
>> So case(1) and case(2) are both used indeed now. If using case(2), we
>> should disable RC's L0s support, and that is why we need this property to
>> indicate this quirk.
>
> Doesn't the driver know which case it is using? I don't see why you need
> the quirk property.
Unfortunately it doesn't. This is one of the pre-input clock for PHY but
doesn't get any indication from the register of both PHY and controller.
So assigning a quirk seems quite straightforward.
>>
>> Also after checking quirk.c, I noticed there is already a quirk for
>> disabling L0s unconditionally, quirk_disable_aspm_l0s. But obviously we
>> shouldn't do that as mentioned above that case(1) could still works fine
>> with L0s.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best Regards
Shawn Lin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 02/10] dt-bindings: add documentation for rk1108 cru
From: Shawn Lin @ 2016-11-16 0:44 UTC (permalink / raw)
To: Heiko Stuebner, Andy Yan
Cc: shawn.lin, mark.rutland, devicetree, sboyd, linux-kernel,
linux-rockchip, robh+dt, mturquette
In-Reply-To: <2131710.LesyKkLYAr@phil>
On 2016/11/15 17:35, Heiko Stuebner wrote:
> Hi Andy,
>
> Am Montag, 14. November 2016, 20:03:01 CET schrieb Andy Yan:
>> From: Shawn Lin <shawn.lin@rock-chips.com>
>>
>> This adds the dt-binding documentation for the clock and reset unit
>> found on Rockchip rk1108 SoCs.
>>
>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
>> ---
>>
>> Changes in v2: None
>>
>> .../bindings/clock/rockchip,rk1108-cru.txt | 60
>> ++++++++++++++++++++++ 1 file changed, 60 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
>>
>> diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
>> b/Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt new file
>> mode 100644
>> index 0000000..4d2356b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
>> @@ -0,0 +1,60 @@
>> +* Rockchip RK1108 Clock and Reset Unit
>> +
>> +The RK1108 clock controller generates and supplies clock to various
>> +controllers within the SoC and also implements a reset controller for SoC
>> +peripherals.
>> +
>> +Required Properties:
>> +
>> +- compatible: should be "rockchip,rk1108-cru"
>> +- reg: physical base address of the controller and length of memory mapped
>> + region.
>> +- #clock-cells: should be 1.
>> +- #reset-cells: should be 1.
>> +
>> +Optional Properties:
>> +
>> +- rockchip,grf: phandle to the syscon managing the "general register files"
>> + If missing pll rates are not changeable, due to the missing pll lock
>> status. +
>> +Each clock is assigned an identifier and client nodes can use this
>> identifier +to specify the clock which they consume. All available clocks
>> are defined as +preprocessor macros in the dt-bindings/clock/rk1108-cru.h
>> headers and can be +used in device tree sources. Similar macros exist for
>> the reset sources in +these files.
>> +
>> +External clocks:
>> +
>> +There are several clocks that are generated outside the SoC. It is expected
>> +that they are defined using standard clock bindings with following
>> +clock-output-names:
>> + - "xin24m" - crystal input - required,
>> + - "cif_clkout" - output clock for the cif - optional
>> + - "mipi_csi_clkout" - output clock for the mipi csi - optional
>> + - "pclkin_vip" - external VIP clock - optional
>> + - "ext_i2s" - external I2S clock - optional
>> + - "ext_gmac" - external GMAC clock - optional
>> + - "mac_ref_clkout" - output clock of the pll in the mac phy
>
> we really only want to list the actual input clocks here, not outputs.
>
> Also, the list of actual input clocks seems incomplete (hdmiphy, usbphy) and
> some clocks listed here do not match the clock controller 2 patches later
> (pclkin_vip, ext_gmac [rk1108 only has 10/100], ext_i2s, ...)
>
yup, I was just listing the basic clock for Andy to bring up rk1108
board, so some of them was missing here. I will fix them here as well
as adding all of the input clocks in the clock driver. :)
>
> Heiko
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* Re: [PATCH v2 03/10] clk: rockchip: add dt-binding header for rk1108
From: Shawn Lin @ 2016-11-16 0:40 UTC (permalink / raw)
To: Heiko Stuebner, Andy Yan
Cc: shawn.lin-TNX95d0MmH7DzftRWevZcw, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <4684383.I4rhnr9WVC@phil>
On 2016/11/15 17:41, Heiko Stuebner wrote:
> Am Montag, 14. November 2016, 20:04:52 CET schrieb Andy Yan:
>> From: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>>
>> Add the dt-bindings header for the rk1108, that gets shared
>> between the clock controller and the clock references in the dts.
>>
>> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>> Signed-off-by: Andy Yan <andy.yan-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>> ---
>>
>> Changes in v2:
>> - split dt-binding header from clk driver
>>
>> include/dt-bindings/clock/rk1108-cru.h | 270
>> +++++++++++++++++++++++++++++++++ 1 file changed, 270 insertions(+)
>> create mode 100644 include/dt-bindings/clock/rk1108-cru.h
>>
>> diff --git a/include/dt-bindings/clock/rk1108-cru.h
>> b/include/dt-bindings/clock/rk1108-cru.h new file mode 100644
>> index 0000000..6f30008
>> --- /dev/null
>> +++ b/include/dt-bindings/clock/rk1108-cru.h
>> @@ -0,0 +1,270 @@
>> +/*
>> + * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
>> + * Author: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK1108_H
>> +#define _DT_BINDINGS_CLK_ROCKCHIP_RK1108_H
>> +
>> +/* pll id */
>> +#define RK1108_APLL_ID 0
>> +#define RK1108_DPLL_ID 1
>> +#define RK1108_GPLL_ID 2
>> +#define RK1108_ARMCLK 3
>
> any particular reason for diverging from namings set in the other binding
> headers (PLL_APLL, ARMCLK, ...)?
>
nope, will make it consistent with others. :)
>
>> +
>> +/* sclk gates (special clocks) */
>> +#define SCLK_SPI0 65
>> +#define SCLK_NANDC 67
>> +#define SCLK_SDMMC 68
>> +#define SCLK_SDIO 69
>> +#define SCLK_EMMC 71
>> +#define SCLK_UART0 72
>> +#define SCLK_UART1 73
>> +#define SCLK_UART2 74
>> +#define SCLK_I2S0 75
>> +#define SCLK_I2S1 76
>> +#define SCLK_I2S2 77
>> +#define SCLK_TIMER0 78
>> +#define SCLK_TIMER1 79
>> +#define SCLK_SFC 80
>> +#define SCLK_SDMMC_DRV 81
>> +#define SCLK_SDIO_DRV 82
>> +#define SCLK_EMMC_DRV 83
>> +#define SCLK_SDMMC_SAMPLE 84
>> +#define SCLK_SDIO_SAMPLE 85
>> +#define SCLK_EMMC_SAMPLE 86
>
> the rk1108 seems to have a pretty small clock tree, so maybe you can reduce
> the gap here a bit, like starting at 128 or 192 for the ACLKs and move
> everything up a bit?
>
okay.
> That way you save a bit of space, as we're allocation CLK_NR_CLKS entries or
> the lookup array when probing the clock driver.
>
>
> Heiko
>
>> +/* aclk gates */
>> +#define ACLK_DMAC 251
>> +#define ACLK_PRE 252
>> +#define ACLK_CORE 253
>> +#define ACLK_ENMCORE 254
>> +
>> +/* pclk gates */
>> +#define PCLK_GPIO1 321
>> +#define PCLK_GPIO2 322
>> +#define PCLK_GPIO3 323
>> +#define PCLK_GRF 329
>> +#define PCLK_I2C1 333
>> +#define PCLK_I2C2 334
>> +#define PCLK_I2C3 335
>> +#define PCLK_SPI 338
>> +#define PCLK_SFC 339
>> +#define PCLK_UART0 341
>> +#define PCLK_UART1 342
>> +#define PCLK_UART2 343
>> +#define PCLK_TSADC 344
>> +#define PCLK_PWM 350
>> +#define PCLK_TIMER 353
>> +#define PCLK_PERI 363
>> +
>> +/* hclk gates */
>> +#define HCLK_I2S0_8CH 442
>> +#define HCLK_I2S1_8CH 443
>> +#define HCLK_I2S2_2CH 444
>> +#define HCLK_NANDC 453
>> +#define HCLK_SDMMC 456
>> +#define HCLK_SDIO 457
>> +#define HCLK_EMMC 459
>> +#define HCLK_PERI 478
>> +#define HCLK_SFC 479
>> +
>> +#define CLK_NR_CLKS (HCLK_SFC + 1)
>> +
>> +/* reset id */
>> +#define SRST_CORE_PO_AD 0
>> +#define SRST_CORE_AD 1
>> +#define SRST_L2_AD 2
>> +#define SRST_CPU_NIU_AD 3
>> +#define SRST_CORE_PO 4
>> +#define SRST_CORE 5
>> +#define SRST_L2 6
>> +#define SRST_CORE_DBG 8
>> +#define PRST_DBG 9
>> +#define RST_DAP 10
>> +#define PRST_DBG_NIU 11
>> +#define ARST_STRC_SYS_AD 15
>> +
>> +#define SRST_DDRPHY_CLKDIV 16
>> +#define SRST_DDRPHY 17
>> +#define PRST_DDRPHY 18
>> +#define PRST_HDMIPHY 19
>> +#define PRST_VDACPHY 20
>> +#define PRST_VADCPHY 21
>> +#define PRST_MIPI_CSI_PHY 22
>> +#define PRST_MIPI_DSI_PHY 23
>> +#define PRST_ACODEC 24
>> +#define ARST_BUS_NIU 25
>> +#define PRST_TOP_NIU 26
>> +#define ARST_INTMEM 27
>> +#define HRST_ROM 28
>> +#define ARST_DMAC 29
>> +#define SRST_MSCH_NIU 30
>> +#define PRST_MSCH_NIU 31
>> +
>> +#define PRST_DDRUPCTL 32
>> +#define NRST_DDRUPCTL 33
>> +#define PRST_DDRMON 34
>> +#define HRST_I2S0_8CH 35
>> +#define MRST_I2S0_8CH 36
>> +#define HRST_I2S1_2CH 37
>> +#define MRST_IS21_2CH 38
>> +#define HRST_I2S2_2CH 39
>> +#define MRST_I2S2_2CH 40
>> +#define HRST_CRYPTO 41
>> +#define SRST_CRYPTO 42
>> +#define PRST_SPI 43
>> +#define SRST_SPI 44
>> +#define PRST_UART0 45
>> +#define PRST_UART1 46
>> +#define PRST_UART2 47
>> +
>> +#define SRST_UART0 48
>> +#define SRST_UART1 49
>> +#define SRST_UART2 50
>> +#define PRST_I2C1 51
>> +#define PRST_I2C2 52
>> +#define PRST_I2C3 53
>> +#define SRST_I2C1 54
>> +#define SRST_I2C2 55
>> +#define SRST_I2C3 56
>> +#define PRST_PWM1 58
>> +#define SRST_PWM1 60
>> +#define PRST_WDT 61
>> +#define PRST_GPIO1 62
>> +#define PRST_GPIO2 63
>> +
>> +#define PRST_GPIO3 64
>> +#define PRST_GRF 65
>> +#define PRST_EFUSE 66
>> +#define PRST_EFUSE512 67
>> +#define PRST_TIMER0 68
>> +#define SRST_TIMER0 69
>> +#define SRST_TIMER1 70
>> +#define PRST_TSADC 71
>> +#define SRST_TSADC 72
>> +#define PRST_SARADC 73
>> +#define SRST_SARADC 74
>> +#define HRST_SYSBUS 75
>> +#define PRST_USBGRF 76
>> +
>> +#define ARST_PERIPH_NIU 80
>> +#define HRST_PERIPH_NIU 81
>> +#define PRST_PERIPH_NIU 82
>> +#define HRST_PERIPH 83
>> +#define HRST_SDMMC 84
>> +#define HRST_SDIO 85
>> +#define HRST_EMMC 86
>> +#define HRST_NANDC 87
>> +#define NRST_NANDC 88
>> +#define HRST_SFC 89
>> +#define SRST_SFC 90
>> +#define ARST_GMAC 91
>> +#define HRST_OTG 92
>> +#define SRST_OTG 93
>> +#define SRST_OTG_ADP 94
>> +#define HRST_HOST0 95
>> +
>> +#define HRST_HOST0_AUX 96
>> +#define HRST_HOST0_ARB 97
>> +#define SRST_HOST0_EHCIPHY 98
>> +#define SRST_HOST0_UTMI 99
>> +#define SRST_USBPOR 100
>> +#define SRST_UTMI0 101
>> +#define SRST_UTMI1 102
>> +
>> +#define ARST_VIO0_NIU 102
>> +#define ARST_VIO1_NIU 103
>> +#define HRST_VIO_NIU 104
>> +#define PRST_VIO_NIU 105
>> +#define ARST_VOP 106
>> +#define HRST_VOP 107
>> +#define DRST_VOP 108
>> +#define ARST_IEP 109
>> +#define HRST_IEP 110
>> +#define ARST_RGA 111
>> +#define HRST_RGA 112
>> +#define SRST_RGA 113
>> +#define PRST_CVBS 114
>> +#define PRST_HDMI 115
>> +#define SRST_HDMI 116
>> +#define PRST_MIPI_DSI 117
>> +
>> +#define ARST_ISP_NIU 118
>> +#define HRST_ISP_NIU 119
>> +#define HRST_ISP 120
>> +#define SRST_ISP 121
>> +#define ARST_VIP0 122
>> +#define HRST_VIP0 123
>> +#define PRST_VIP0 124
>> +#define ARST_VIP1 125
>> +#define HRST_VIP1 126
>> +#define PRST_VIP1 127
>> +#define ARST_VIP2 128
>> +#define HRST_VIP2 129
>> +#define PRST_VIP2 120
>> +#define ARST_VIP3 121
>> +#define HRST_VIP3 122
>> +#define PRST_VIP4 123
>> +
>> +#define PRST_CIF1TO4 124
>> +#define SRST_CVBS_CLK 125
>> +#define HRST_CVBS 126
>> +
>> +#define ARST_VPU_NIU 140
>> +#define HRST_VPU_NIU 141
>> +#define ARST_VPU 142
>> +#define HRST_VPU 143
>> +#define ARST_RKVDEC_NIU 144
>> +#define HRST_RKVDEC_NIU 145
>> +#define ARST_RKVDEC 146
>> +#define HRST_RKVDEC 147
>> +#define SRST_RKVDEC_CABAC 148
>> +#define SRST_RKVDEC_CORE 149
>> +#define ARST_RKVENC_NIU 150
>> +#define HRST_RKVENC_NIU 151
>> +#define ARST_RKVENC 152
>> +#define HRST_RKVENC 153
>> +#define SRST_RKVENC_CORE 154
>> +
>> +#define SRST_DSP_CORE 156
>> +#define SRST_DSP_SYS 157
>> +#define SRST_DSP_GLOBAL 158
>> +#define SRST_DSP_OECM 159
>> +#define PRST_DSP_IOP_NIU 160
>> +#define ARST_DSP_EPP_NIU 161
>> +#define ARST_DSP_EDP_NIU 162
>> +#define PRST_DSP_DBG_NIU 163
>> +#define PRST_DSP_CFG_NIU 164
>> +#define PRST_DSP_GRF 165
>> +#define PRST_DSP_MAILBOX 166
>> +#define PRST_DSP_INTC 167
>> +#define PRST_DSP_PFM_MON 169
>> +#define SRST_DSP_PFM_MON 170
>> +#define ARST_DSP_EDAP_NIU 171
>> +
>> +#define SRST_PMU 172
>> +#define SRST_PMU_I2C0 173
>> +#define PRST_PMU_I2C0 174
>> +#define PRST_PMU_GPIO0 175
>> +#define PRST_PMU_INTMEM 176
>> +#define PRST_PMU_PWM0 177
>> +#define SRST_PMU_PWM0 178
>> +#define PRST_PMU_GRF 179
>> +#define SRST_PMU_NIU 180
>> +#define SRST_PMU_PVTM 181
>> +#define ARST_DSP_EDP_PERF 184
>> +#define ARST_DSP_EPP_PERF 185
>> +
>> +#endif /* _DT_BINDINGS_CLK_ROCKCHIP_RK1108_H */
>> +
>
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
--
Best Regards
Shawn Lin
--
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 2/4] usb: dwc2: Add binding for AHB burst
From: John Youn @ 2016-11-16 0:36 UTC (permalink / raw)
To: John Youn, Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland
Cc: Christian Lamparter, Stefan Wahren
In-Reply-To: <cover.1479256193.git.johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Add the "snps,ahb-burst" binding and read it in.
This property controls which burst type to perform on the AHB bus as a
master in internal DMA mode. This overrides the legacy param value,
which we need to keep around for now since several platforms use it.
Some platforms may see better or worse performance based on this
value. The HAPS platform is one example where all INCRx have worse
performance than INCR.
Other platforms (such as the Canyonlands board) report that the default
value causes system hangs.
Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Cc: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
Documentation/devicetree/bindings/usb/dwc2.txt | 2 +
drivers/usb/dwc2/core.h | 9 +++++
drivers/usb/dwc2/params.c | 56 ++++++++++++++++++++++++++
3 files changed, 67 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
index 6c7c2bce..9e7b4b4 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -26,6 +26,8 @@ Optional properties:
Refer to phy/phy-bindings.txt for generic phy consumer properties
- dr_mode: shall be one of "host", "peripheral" and "otg"
Refer to usb/generic.txt
+- snps,ahb-burst: specifies the ahb burst length. Valid arguments are:
+ "SINGLE", "INCR", "INCR4", "INCR8", "INCR16". Defaults to "INCR4".
- g-rx-fifo-size: size of rx fifo size in gadget mode.
- g-np-tx-fifo-size: size of non-periodic tx fifo size in gadget mode.
- g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0) in gadget mode.
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9548d3e..75c238c 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -430,6 +430,12 @@ enum dwc2_ep0_state {
* needed.
* 0 - No (default)
* 1 - Yes
+ * @ahb_burst: Specifies the AHB burst.
+ * 0 - Single
+ * 1 - INCR
+ * 3 - INCR4 (default)
+ * 5 - INCR8
+ * 7 - INCR16
* @g_dma: Enables gadget dma usage (default: autodetect).
* @g_dma_desc: Enables gadget descriptor DMA (default: autodetect).
* @g_rx_fifo_size: The periodic rx fifo size for the device, in
@@ -507,6 +513,9 @@ struct dwc2_core_params {
* properties and cannot be set directly in this structure.
*/
+ /* Global parameters */
+ u8 ahb_burst;
+
/* Host parameters */
bool host_dma;
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 96387de..20f2697 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -1091,6 +1091,60 @@ static void dwc2_set_param_tx_fifo_sizes(struct dwc2_hsotg *hsotg)
}
}
+static const char *const ahb_bursts[] = {
+ [GAHBCFG_HBSTLEN_SINGLE] = "SINGLE",
+ [GAHBCFG_HBSTLEN_INCR] = "INCR",
+ [GAHBCFG_HBSTLEN_INCR4] = "INCR4",
+ [GAHBCFG_HBSTLEN_INCR8] = "INCR8",
+ [GAHBCFG_HBSTLEN_INCR16] = "INCR16",
+};
+
+static int dwc2_get_property_ahb_burst(struct dwc2_hsotg *hsotg)
+{
+ const char *str = NULL;
+ int burst;
+ int ret;
+
+ ret = device_property_read_string(hsotg->dev,
+ "snps,ahb-burst", &str);
+ if (ret < 0)
+ return ret;
+
+ burst = match_string(ahb_bursts,
+ ARRAY_SIZE(ahb_bursts), str);
+ if (burst < 0) {
+ dev_err(hsotg->dev,
+ "Invalid parameter '%s' for ahb-burst\n", str);
+ }
+
+ return burst;
+}
+
+static void dwc2_set_ahb_burst(struct dwc2_hsotg *hsotg)
+{
+ struct dwc2_core_params *p = &hsotg->params;
+ int burst;
+ int ret;
+
+ /* Default burst value */
+ burst = GAHBCFG_HBSTLEN_INCR4;
+
+ /* Get the legacy param value, if set. */
+ if (p->ahbcfg != -1) {
+ burst = (p->ahbcfg & GAHBCFG_HBSTLEN_MASK) >>
+ GAHBCFG_HBSTLEN_SHIFT;
+ }
+
+ /* Override it from devicetree, if set. */
+ ret = dwc2_get_property_ahb_burst(hsotg);
+ if (ret >= 0)
+ burst = ret;
+
+ /* Set the parameter */
+ p->ahb_burst = (u8)burst;
+ dev_dbg(hsotg->dev, "Setting ahb-burst to %d\n", burst);
+}
+
static void dwc2_set_gadget_dma(struct dwc2_hsotg *hsotg)
{
struct dwc2_hw_params *hw = &hsotg->hw_params;
@@ -1171,6 +1225,8 @@ static void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
dwc2_set_param_external_id_pin_ctl(hsotg, params->external_id_pin_ctl);
dwc2_set_param_hibernation(hsotg, params->hibernation);
+ dwc2_set_ahb_burst(hsotg);
+
/*
* Set devicetree-only parameters. These parameters do not
* take any values from @params.
--
2.10.0
--
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 related
* [PATCH 0/4] usb: dwc2: Add AHB burst configuration
From: John Youn @ 2016-11-16 0:36 UTC (permalink / raw)
To: John Youn, Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland
Cc: Christian Lamparter, Stefan Wahren
This series adds a binding for AHB burst, reads it in, and configures
the controller for the specified burst type.
Tested on HAPS platform with DWC_hsotg IP version 3.30a.
John Youn (4):
usb: dwc2: Fix AHB burst type for bcm2835
usb: dwc2: Add binding for AHB burst
usb: dwc2: Use the ahb_burst param
usb: dwc2: pci: Add AHB burst property for HAPS
Documentation/devicetree/bindings/usb/dwc2.txt | 2 +
drivers/usb/dwc2/core.h | 9 ++++
drivers/usb/dwc2/gadget.c | 2 +-
drivers/usb/dwc2/hcd.c | 8 ++-
drivers/usb/dwc2/params.c | 68 +++++++++++++++++++++-----
drivers/usb/dwc2/pci.c | 1 +
6 files changed, 73 insertions(+), 17 deletions(-)
--
2.10.0
--
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
* [PATCH 0/4] usb: dwc2: Add AHB burst configuration
From: John Youn @ 2016-11-16 0:36 UTC (permalink / raw)
To: John Youn, Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland
Cc: Christian Lamparter, Stefan Wahren
This series adds a binding for AHB burst, reads it in, and configures
the controller for the specified burst type.
Tested on HAPS platform with DWC_hsotg IP version 3.30a.
John Youn (4):
usb: dwc2: Fix AHB burst type for bcm2835
usb: dwc2: Add binding for AHB burst
usb: dwc2: Use the ahb_burst param
usb: dwc2: pci: Add AHB burst property for HAPS
Documentation/devicetree/bindings/usb/dwc2.txt | 2 +
drivers/usb/dwc2/core.h | 9 ++++
drivers/usb/dwc2/gadget.c | 2 +-
drivers/usb/dwc2/hcd.c | 8 ++-
drivers/usb/dwc2/params.c | 68 +++++++++++++++++++++-----
drivers/usb/dwc2/pci.c | 1 +
6 files changed, 73 insertions(+), 17 deletions(-)
--
2.10.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: specifying order of /dev/mmcblk devices via device-tree?
From: Fabio Estevam @ 2016-11-16 0:33 UTC (permalink / raw)
To: Russell King - ARM Linux, Masahiro Yamada, Michael Turquette
Cc: Tim Harvey, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Ulf Hansson,
Fabio Estevam, Javier Martinez Canillas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20161115235503.GC1041-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
[Adding Masahiro and Michael]
On Tue, Nov 15, 2016 at 9:55 PM, Russell King - ARM Linux
<linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
> On Tue, Nov 15, 2016 at 10:10:02PM +0000, Russell King - ARM Linux wrote:
>> On Tue, Nov 15, 2016 at 01:39:42PM -0800, Tim Harvey wrote:
>> > On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux
>> > <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
>> > > On Tue, Nov 15, 2016 at 12:27:53PM -0800, Tim Harvey wrote:
>> > >> On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
>> > >> <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
>> > >> > So, someone merged a patch which makes mmcblk devices follow the
>> > >> > host controller numbering.
>> > >> >
>> > >> > Now my cubox-i fails to boot correctly because the SD card in the
>> > >> > _only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
>> > >> >
>> > >> > USDHC1 is wired to the on-microsom WiFi, and never has anything
>> > >> > remotely near a SD card or eMMC present. So, this change is
>> > >> > confusing on these platforms.
>> > >> >
>> > >> > Moreover, this is _going_ to break SolidRun distros if people upgrade
>> > >> > their kernels.
>> > >> >
>> > >> > It may be appropriate for eMMC, but it's not appropriate everywhere.
>> > >> >
>> > >> > This is a user visible _regression_ in 4.9-rc. Whoever did this,
>> > >> > please revert whatever change caused this, and next time limit it
>> > >> > to only eMMC.
>> > >> >
>> > >> > Thanks.
>> > >>
>> > >> I see the same thing on newer kernels, which is why I asked the
>> > >> question. I didn't expect (or even want honestly) a non mmcblk0 boot
>> > >> device and was looking for a way to control that via dt. Now I'm
>> > >> understanding that to avoid this kind of bootloader/kernel dependence
>> > >> issue I should be using UUID's to identify the boot device.
>> > >>
>> > >> >From my testing it looks like the change your looking for occurred
>> > >> some time ago and is somewhere between 4.5 and 4.6 and not a 4.9
>> > >> regression specifically.
>> > >
>> > > That depends how you look at it. Yes, there's a change in 4.5 to 4.6
>> > > which ties the block device number to the host device index, but that's
>> > > really only part of the story here.
>> > >
>> > > 4.8 definitely identifies the SD card in iMX6 usdhc2 as "mmcblk0".
>> > > 4.9-rc identifies the SD card as "mmcblk1". This makes it a 4.9 change
>> > > of behaviour - there can be no argument about that.
>> > >
>> > > Now, digging further into this today, it appears that:
>> > >
>> > > v4.8: usdhc2 was probed first, and is given mmc0.
>> > > usdhc1 is probed second, and is given mmc1.
>> > >
>> > > v4.9-rc: usdhc1 is probed first, and is given mmc0.
>> > > usdhc2 is probed second, and is given mmc1.
>> > >
>> > > I haven't yet been able to figure out why there's been this change
>> > > of probe order. There's no change that I can see in the iMX6 DT
>> > > files that would account for this.
>> > >
>> >
>> > I bisected it and the commit your looking for is
>> > 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d
>>
>> No it's not.
>>
>> Let me try and put it plainer:
>>
>> * Commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d ties the mmc block
>> device number (mmcblkN) to the mmc host interface number (mmcN).
>> This change happened between 4.5 and 4.6.
>>
>> * The change I'm seeing happened between 4.8 and 4.9-rc. I'm not
>> seeing a change of behaviour between 4.5 and 4.6.
>>
>> * The change I'm seeing changes the order of the physical device
>> associated with the hosts named mmc0 and mmc1 in the kernel.
>>
>> * Because physical devices associated with the mmc0 and mmc1 hosts
>> swap over, the mmcblkN number changes due to the commit you point
>> out.
>>
>> * So, the change that I'm seeing between 4.8 and 4.9-rc is not caused
>> by commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d, but by something
>> else changing the order in which the two usdhc physical hardware
>> blocks get probed.
>>
>> Does this make it clearer?
>
> It turns out to be this commit:
>
> commit 6eb1c9496b81680f2cd2e0eda06c531317e2e28d
> Author: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> Date: Mon Sep 19 01:16:44 2016 +0900
>
> clk: probe common clock drivers earlier
>
> Several SoCs implement platform drivers for clocks rather than
> CLK_OF_DECLARE(). Clocks should come earlier because they are
> prerequisites for many of other drivers. It will help to mitigate
> EPROBE_DEFER issues.
>
> Also, drop the comment since it does not carry much value.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> Acked-by: Michael Turquette <mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
>
> which changes the init order. In 4.8, we get:
>
> calling mmc_pwrseq_simple_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device usdhc1_pwrseq with driver pwrseq_simple
> bus: 'platform': really_probe: probing driver pwrseq_simple with device usdhc1_pwrseq
> platform usdhc1_pwrseq: Driver pwrseq_simple requests probe deferral
> platform usdhc1_pwrseq: Added to deferred list
> initcall mmc_pwrseq_simple_driver_init+0x0/0x20 returned 0 after 737 usecs
>
> which then goes on to cause:
>
> calling sdhci_esdhc_imx_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device 2190000.usdhc with driver sdhci-esdhc-imx
> bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2190000.usdhc
> platform 2190000.usdhc: Driver sdhci-esdhc-imx requests probe deferral
> platform 2190000.usdhc: Added to deferred list
>
> followed by:
>
> bus: 'platform': driver_probe_device: matched device 2194000.usdhc with driver sdhci-esdhc-imx
> bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2194000.usdhc
> sdhci-esdhc-imx 2194000.usdhc: Got CD GPIO
> driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2194000.usdhc'
> bus: 'platform': really_probe: bound device 2194000.usdhc to driver sdhci-esdhc-imx
> initcall sdhci_esdhc_imx_driver_init+0x0/0x20 returned 0 after 58205 usecs
>
> and eventually:
>
> mmc0: host does not support reading read-only switch, assuming write-enable
> mmc0: new ultra high speed SDR104 SDHC card at address 0001
> mmcblk0: mmc0:0001 00000 14.9 GiB
> mmcblk0: p1 p2
>
> In 4.9-rc5, we instead get:
>
> calling gpio_clk_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device sdio-clock with driver gpio-clk
> bus: 'platform': really_probe: probing driver gpio-clk with device sdio-clock
> driver: 'gpio-clk': driver_bound: bound to device 'sdio-clock'
> bus: 'platform': really_probe: bound device sdio-clock to driver gpio-clk
> ...
> calling mmc_pwrseq_simple_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device usdhc1_pwrseq with driver pwrseq_simple
> bus: 'platform': really_probe: probing driver pwrseq_simple with device usdhc1_pwrseq
> driver: 'pwrseq_simple': driver_bound: bound to device 'usdhc1_pwrseq'
> bus: 'platform': really_probe: bound device usdhc1_pwrseq to driver pwrseq_simple
> initcall mmc_pwrseq_simple_driver_init+0x0/0x20 returned 0 after 876 usecs
> ...
> calling sdhci_esdhc_imx_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device 2190000.usdhc with driver sdhci-esdhc-imx
> bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2190000.usdhc
> sdhci-esdhc-imx 2190000.usdhc: allocated mmc-pwrseq
> driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2190000.usdhc'
> bus: 'platform': really_probe: bound device 2190000.usdhc to driver sdhci-esdhc-imx
> bus: 'platform': driver_probe_device: matched device 2194000.usdhc with driver sdhci-esdhc-imx
> bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2194000.usdhc
> driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2194000.usdhc'
> bus: 'platform': really_probe: bound device 2194000.usdhc to driver sdhci-esdhc-imx
> initcall sdhci_esdhc_imx_driver_init+0x0/0x20 returned 0 after 384864 usecs
> ...
> mmc1: host does not support reading read-only switch, assuming write-enable
> mmc1: new ultra high speed SDR104 SDHC card at address 0001
> mmcblk1: mmc1:0001 00000 14.9 GiB
> mmcblk1: p1 p2
>
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> --
> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 2/3] dt-bindings: mxsfb: Add new bindings for the MXSFB driver
From: Rob Herring @ 2016-11-16 0:24 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree, Daniel Vetter, dri-devel, Fabio Estevam, Shawn Guo
In-Reply-To: <20161114101036.3505-2-marex@denx.de>
On Mon, Nov 14, 2016 at 11:10:35AM +0100, Marek Vasut wrote:
> Add new DT bindings for new MXSFB driver that is using the
> OF graph to parse the video output structure instead of
> hard-coding the display properties into the MXSFB node.
> The old MXSFB fbdev driver bindings are preserved in the
> same file in the "Old bindings" section.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: devicetree@vger.kernel.org
> --
> V2: - Merge the new bindings into mxsfb.txt file instead of keeping
> them in separate mxsfb-drm.txt file.
> - Add dedicated compatible for i.MX6SX
> - Drop all references to DRM/KMS
> - Repair the required bits in clock node
> ---
> .../devicetree/bindings/display/mxsfb.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt
> index a4431f2..6e92593 100644
> --- a/Documentation/devicetree/bindings/display/mxsfb.txt
> +++ b/Documentation/devicetree/bindings/display/mxsfb.txt
> @@ -1,5 +1,42 @@
> * Freescale MXS LCD Interface (LCDIF)
>
> +New bindings:
> +=============
> +Required properties:
> +- compatible: Should be "fsl,imx23-lcdif" for i.MX23.
> + Should be "fsl,imx28-lcdif" for i.MX28.
> + Should be "fsl,imx6sx-lcdif" for i.MX6SX.
> +- reg: Address and length of the register set for lcdif
s/lcdif/LCDIF/
> +- interrupts: Should contain lcdif interrupts
How many?
> +- clocks: A list of phandle + clock-specifier pairs, one for each
> + entry in 'clock-names'.
> +- clock-names: A list of clock names. For MXSFB it should contain:
> + - "pix" for the MXSFB block clock
MXSFB is not a h/w block. LCDIF is the name.
> + - (MX6SX-only) "axi", "disp_axi" for the bus interface clock
> +
> +Required sub-nodes:
> + - port: The connection to an encoder chip.
> +
> +Example:
> +
> + lcdif1: lcdif@02220000 {
display-controller@...
Drop the leading 0 too.
> + compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
I'm not sure compatibility with mx28 is appropriate since you have the
extra clocks. I guess if they don't need to be managed then it's okay.
> + reg = <0x02220000 0x4000>;
> + interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
> + <&clks IMX6SX_CLK_LCDIF_APB>,
> + <&clks IMX6SX_CLK_DISPLAY_AXI>;
> + clock-names = "pix", "axi", "disp_axi";
> +
> + port {
> + parallel_out: endpoint {
> + remote-endpoint = <&panel_in_parallel>;
> + };
> + };
> + };
> +
> +Old bindings:
s/Old/Deprecated/
> +=============
> Required properties:
> - compatible: Should be "fsl,imx23-lcdif" for i.MX23.
> Should be "fsl,imx28-lcdif" for i.MX28.
> --
> 2.10.2
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: mxsfb: Indentation cleanup
From: Rob Herring @ 2016-11-16 0:16 UTC (permalink / raw)
To: Marek Vasut
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Lucas Stach,
Fabio Estevam, Shawn Guo, Daniel Vetter,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161114101036.3505-1-marex-ynQEQJNshbs@public.gmane.org>
On Mon, Nov 14, 2016 at 11:10:34AM +0100, Marek Vasut wrote:
> Clean up the ad-hoc indentation in the documentation, no functional change.
>
> Signed-off-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Daniel Vetter <daniel.vetter-/w4YWyX8dFk@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> Documentation/devicetree/bindings/display/mxsfb.txt | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH] ARM64: dts: Add support for Meson GXM
From: Rob Herring @ 2016-11-16 0:13 UTC (permalink / raw)
To: Neil Armstrong
Cc: khilman, carlo, linux-amlogic, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <20161114094411.30199-1-narmstrong@baylibre.com>
On Mon, Nov 14, 2016 at 10:44:11AM +0100, Neil Armstrong wrote:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> Simply add a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.txt | 6 +
> arch/arm64/boot/dts/amlogic/Makefile | 2 +
> .../arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 76 +++++++++
> .../arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 57 +++++++
> .../boot/dts/amlogic/meson-gxm-s912-q20x.dtsi | 188 +++++++++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 114 +++++++++++++
> 6 files changed, 443 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q20x.dtsi
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
From: Rob Herring @ 2016-11-16 0:07 UTC (permalink / raw)
To: Sriram Dash
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
mark.rutland-5wv7dgnIgG8, kishon-l0cyMroinI0,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
pku.leo-Re5JQEeQqe8AvxtiuMwx3w,
mathias.nyman-ral2JQCrhuEAvxtiuMwx3w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, suresh.gupta-3arQi8VN3Tc,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA
In-Reply-To: <1479101215-26954-2-git-send-email-sriram.dash-3arQi8VN3Tc@public.gmane.org>
On Mon, Nov 14, 2016 at 10:56:54AM +0530, Sriram Dash wrote:
> Adds qoriq usb 3.0 phy driver support for LS1043A platform.
> Describes the qoriq usb 2.0 phy driver binding, currently used
> for LS1043A platform.
>
> Signed-off-by: Sriram Dash <sriram.dash-3arQi8VN3Tc@public.gmane.org>
> ---
> .../devicetree/bindings/phy/phy-qoriq-usb3.txt | 36 ++++
> drivers/phy/Kconfig | 8 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-qoriq-usb3.c | 202 +++++++++++++++++++++
> 4 files changed, 247 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> create mode 100644 drivers/phy/phy-qoriq-usb3.c
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> new file mode 100644
> index 0000000..d934c80
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> @@ -0,0 +1,36 @@
> +Driver for Freescale USB 3.0 PHY
> +
> +Required properties:
> +
> +- compatible : fsl,qoriq-usb3-phy
> +- reg : register mappings for Parameter Configuration Register
> + and Phy base offset.
> +- reg-names : "param_ctrl" and "phy_base"
> +- phy_type : For multi port host USB controllers, should be one of
> + "ulpi", or "serial". For dual role USB controllers,
> + should be one of "ulpi", "utmi", "utmi_wide", or "serial".
Do any of these really apply to a USB3 PHY?
Rob
> +
> +Example:
> + usbphy0: usb3-phy@084F0000 {
usb-phy@...
> + compatible = "fsl,qoriq-usb3-phy";
> + reg = <0x0 0x01570070 0x0 0xC>, <0x0 0x084F0000 0x0 0x5000>;
> + reg-names = "param_ctrl", "phy_base";
> + #phy-cells = <0>;
> + phy_type = "utmi";
> + };
> +
> + usbphy1: usb3-phy@08500000 {
> + compatible = "fsl,qoriq-usb3-phy";
> + reg = <0x0 0x0157007C 0x0 0xC>, <0x0 0x08500000 0x0 0x5000>;
> + reg-names = "param_ctrl", "phy_base";
> + #phy-cells = <0>;
> + phy_type = "utmi";
> + };
> +
> + usbphy2: usb3-phy@08510000 {
> + compatible = "fsl,qoriq-usb3-phy";
> + reg = <0x0 0x01570088 0x0 0xC>, <0x0 0x08510000 0x0 0x5000>;
> + reg-names = "param_ctrl", "phy_base";
> + #phy-cells = <0>;
> + phy_type = "utmi";
> + };
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: specifying order of /dev/mmcblk devices via device-tree?
From: Russell King - ARM Linux @ 2016-11-15 23:55 UTC (permalink / raw)
To: Tim Harvey
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ulf Hansson, Fabio Estevam, Javier Martinez Canillas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20161115221002.GA1041-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
On Tue, Nov 15, 2016 at 10:10:02PM +0000, Russell King - ARM Linux wrote:
> On Tue, Nov 15, 2016 at 01:39:42PM -0800, Tim Harvey wrote:
> > On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux
> > <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
> > > On Tue, Nov 15, 2016 at 12:27:53PM -0800, Tim Harvey wrote:
> > >> On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
> > >> <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
> > >> > So, someone merged a patch which makes mmcblk devices follow the
> > >> > host controller numbering.
> > >> >
> > >> > Now my cubox-i fails to boot correctly because the SD card in the
> > >> > _only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
> > >> >
> > >> > USDHC1 is wired to the on-microsom WiFi, and never has anything
> > >> > remotely near a SD card or eMMC present. So, this change is
> > >> > confusing on these platforms.
> > >> >
> > >> > Moreover, this is _going_ to break SolidRun distros if people upgrade
> > >> > their kernels.
> > >> >
> > >> > It may be appropriate for eMMC, but it's not appropriate everywhere.
> > >> >
> > >> > This is a user visible _regression_ in 4.9-rc. Whoever did this,
> > >> > please revert whatever change caused this, and next time limit it
> > >> > to only eMMC.
> > >> >
> > >> > Thanks.
> > >>
> > >> I see the same thing on newer kernels, which is why I asked the
> > >> question. I didn't expect (or even want honestly) a non mmcblk0 boot
> > >> device and was looking for a way to control that via dt. Now I'm
> > >> understanding that to avoid this kind of bootloader/kernel dependence
> > >> issue I should be using UUID's to identify the boot device.
> > >>
> > >> >From my testing it looks like the change your looking for occurred
> > >> some time ago and is somewhere between 4.5 and 4.6 and not a 4.9
> > >> regression specifically.
> > >
> > > That depends how you look at it. Yes, there's a change in 4.5 to 4.6
> > > which ties the block device number to the host device index, but that's
> > > really only part of the story here.
> > >
> > > 4.8 definitely identifies the SD card in iMX6 usdhc2 as "mmcblk0".
> > > 4.9-rc identifies the SD card as "mmcblk1". This makes it a 4.9 change
> > > of behaviour - there can be no argument about that.
> > >
> > > Now, digging further into this today, it appears that:
> > >
> > > v4.8: usdhc2 was probed first, and is given mmc0.
> > > usdhc1 is probed second, and is given mmc1.
> > >
> > > v4.9-rc: usdhc1 is probed first, and is given mmc0.
> > > usdhc2 is probed second, and is given mmc1.
> > >
> > > I haven't yet been able to figure out why there's been this change
> > > of probe order. There's no change that I can see in the iMX6 DT
> > > files that would account for this.
> > >
> >
> > I bisected it and the commit your looking for is
> > 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d
>
> No it's not.
>
> Let me try and put it plainer:
>
> * Commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d ties the mmc block
> device number (mmcblkN) to the mmc host interface number (mmcN).
> This change happened between 4.5 and 4.6.
>
> * The change I'm seeing happened between 4.8 and 4.9-rc. I'm not
> seeing a change of behaviour between 4.5 and 4.6.
>
> * The change I'm seeing changes the order of the physical device
> associated with the hosts named mmc0 and mmc1 in the kernel.
>
> * Because physical devices associated with the mmc0 and mmc1 hosts
> swap over, the mmcblkN number changes due to the commit you point
> out.
>
> * So, the change that I'm seeing between 4.8 and 4.9-rc is not caused
> by commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d, but by something
> else changing the order in which the two usdhc physical hardware
> blocks get probed.
>
> Does this make it clearer?
It turns out to be this commit:
commit 6eb1c9496b81680f2cd2e0eda06c531317e2e28d
Author: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Date: Mon Sep 19 01:16:44 2016 +0900
clk: probe common clock drivers earlier
Several SoCs implement platform drivers for clocks rather than
CLK_OF_DECLARE(). Clocks should come earlier because they are
prerequisites for many of other drivers. It will help to mitigate
EPROBE_DEFER issues.
Also, drop the comment since it does not carry much value.
Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Acked-by: Michael Turquette <mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Signed-off-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
which changes the init order. In 4.8, we get:
calling mmc_pwrseq_simple_driver_init+0x0/0x20 @ 1
bus: 'platform': driver_probe_device: matched device usdhc1_pwrseq with driver pwrseq_simple
bus: 'platform': really_probe: probing driver pwrseq_simple with device usdhc1_pwrseq
platform usdhc1_pwrseq: Driver pwrseq_simple requests probe deferral
platform usdhc1_pwrseq: Added to deferred list
initcall mmc_pwrseq_simple_driver_init+0x0/0x20 returned 0 after 737 usecs
which then goes on to cause:
calling sdhci_esdhc_imx_driver_init+0x0/0x20 @ 1
bus: 'platform': driver_probe_device: matched device 2190000.usdhc with driver sdhci-esdhc-imx
bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2190000.usdhc
platform 2190000.usdhc: Driver sdhci-esdhc-imx requests probe deferral
platform 2190000.usdhc: Added to deferred list
followed by:
bus: 'platform': driver_probe_device: matched device 2194000.usdhc with driver sdhci-esdhc-imx
bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2194000.usdhc
sdhci-esdhc-imx 2194000.usdhc: Got CD GPIO
driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2194000.usdhc'
bus: 'platform': really_probe: bound device 2194000.usdhc to driver sdhci-esdhc-imx
initcall sdhci_esdhc_imx_driver_init+0x0/0x20 returned 0 after 58205 usecs
and eventually:
mmc0: host does not support reading read-only switch, assuming write-enable
mmc0: new ultra high speed SDR104 SDHC card at address 0001
mmcblk0: mmc0:0001 00000 14.9 GiB
mmcblk0: p1 p2
In 4.9-rc5, we instead get:
calling gpio_clk_driver_init+0x0/0x20 @ 1
bus: 'platform': driver_probe_device: matched device sdio-clock with driver gpio-clk
bus: 'platform': really_probe: probing driver gpio-clk with device sdio-clock
driver: 'gpio-clk': driver_bound: bound to device 'sdio-clock'
bus: 'platform': really_probe: bound device sdio-clock to driver gpio-clk
...
calling mmc_pwrseq_simple_driver_init+0x0/0x20 @ 1
bus: 'platform': driver_probe_device: matched device usdhc1_pwrseq with driver pwrseq_simple
bus: 'platform': really_probe: probing driver pwrseq_simple with device usdhc1_pwrseq
driver: 'pwrseq_simple': driver_bound: bound to device 'usdhc1_pwrseq'
bus: 'platform': really_probe: bound device usdhc1_pwrseq to driver pwrseq_simple
initcall mmc_pwrseq_simple_driver_init+0x0/0x20 returned 0 after 876 usecs
...
calling sdhci_esdhc_imx_driver_init+0x0/0x20 @ 1
bus: 'platform': driver_probe_device: matched device 2190000.usdhc with driver sdhci-esdhc-imx
bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2190000.usdhc
sdhci-esdhc-imx 2190000.usdhc: allocated mmc-pwrseq
driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2190000.usdhc'
bus: 'platform': really_probe: bound device 2190000.usdhc to driver sdhci-esdhc-imx
bus: 'platform': driver_probe_device: matched device 2194000.usdhc with driver sdhci-esdhc-imx
bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2194000.usdhc
driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2194000.usdhc'
bus: 'platform': really_probe: bound device 2194000.usdhc to driver sdhci-esdhc-imx
initcall sdhci_esdhc_imx_driver_init+0x0/0x20 returned 0 after 384864 usecs
...
mmc1: host does not support reading read-only switch, assuming write-enable
mmc1: new ultra high speed SDR104 SDHC card at address 0001
mmcblk1: mmc1:0001 00000 14.9 GiB
mmcblk1: p1 p2
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] usb: dwc2: add amcc,dwc-otg support
From: John Youn @ 2016-11-15 23:03 UTC (permalink / raw)
To: Felipe Balbi
Cc: Mark Rutland, devicetree, John Youn, Greg Kroah-Hartman,
linux-usb, linux-kernel, Rob Herring, Christian Lamparter,
linuxppc-dev
From: Christian Lamparter <chunkeey@googlemail.com>
This patch adds support for the "amcc,usb-otg" device
which is found in the PowerPC Canyonlands' dts.
The device definition was added by:
commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands
board")
but without any driver support as the dwc2 driver wasn't available at
that time.
Note: The system can't use the generic "snps,dwc2" compatible
because of the special ahbcfg configuration. The default
GAHBCFG_HBSTLEN_INCR4 of snps,dwc2 can cause a system hang
when the USB and SATA is used concurrently.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
---
Sorry, the previous one broke compilation. This fixes it.
Regards,
John
v3 [johnyoun]:
* Fixed compilation issue
v2 [johnyoun]:
* Removed params struct
* Minor commit message formatting
Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
drivers/usb/dwc2/params.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
index ad8f7ff..6c7c2bce 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -12,6 +12,7 @@ Required properties:
- "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs;
- "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs;
- "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs;
+ - "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX SoCs;
- snps,dwc2: A generic DWC2 USB controller with default parameters.
- reg : Should contain 1 register range (address and length)
- interrupts : Should contain 1 interrupt
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 513556a..a786256 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -239,6 +239,7 @@ const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "samsung,s3c6400-hsotg", .data = NULL},
{ .compatible = "amlogic,meson8b-usb", .data = ¶ms_amlogic },
{ .compatible = "amlogic,meson-gxbb-usb", .data = ¶ms_amlogic },
+ { .compatible = "amcc,dwc-otg", .data = NULL },
{},
};
MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
--
2.10.0
^ permalink raw reply related
* [PATCH v3] usb: dwc2: add amcc,dwc-otg support
From: John Youn @ 2016-11-15 23:03 UTC (permalink / raw)
To: Felipe Balbi
Cc: Mark Rutland, devicetree, John Youn, Greg Kroah-Hartman,
linux-usb, linux-kernel, Rob Herring, Christian Lamparter,
linuxppc-dev
From: Christian Lamparter <chunkeey@googlemail.com>
This patch adds support for the "amcc,usb-otg" device
which is found in the PowerPC Canyonlands' dts.
The device definition was added by:
commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands
board")
but without any driver support as the dwc2 driver wasn't available at
that time.
Note: The system can't use the generic "snps,dwc2" compatible
because of the special ahbcfg configuration. The default
GAHBCFG_HBSTLEN_INCR4 of snps,dwc2 can cause a system hang
when the USB and SATA is used concurrently.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
---
Sorry, the previous one broke compilation. This fixes it.
Regards,
John
v3 [johnyoun]:
* Fixed compilation issue
v2 [johnyoun]:
* Removed params struct
* Minor commit message formatting
Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
drivers/usb/dwc2/params.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
index ad8f7ff..6c7c2bce 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -12,6 +12,7 @@ Required properties:
- "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs;
- "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs;
- "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs;
+ - "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX SoCs;
- snps,dwc2: A generic DWC2 USB controller with default parameters.
- reg : Should contain 1 register range (address and length)
- interrupts : Should contain 1 interrupt
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 513556a..a786256 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -239,6 +239,7 @@ const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "samsung,s3c6400-hsotg", .data = NULL},
{ .compatible = "amlogic,meson8b-usb", .data = ¶ms_amlogic },
{ .compatible = "amlogic,meson-gxbb-usb", .data = ¶ms_amlogic },
+ { .compatible = "amcc,dwc-otg", .data = NULL },
{},
};
MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
--
2.10.0
^ permalink raw reply related
* [PATCH v3] usb: dwc2: add amcc,dwc-otg support
From: John Youn @ 2016-11-15 23:03 UTC (permalink / raw)
To: Felipe Balbi
Cc: Christian Lamparter, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, Mark Rutland, Rob Herring,
Greg Kroah-Hartman, John Youn
From: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
This patch adds support for the "amcc,usb-otg" device
which is found in the PowerPC Canyonlands' dts.
The device definition was added by:
commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands
board")
but without any driver support as the dwc2 driver wasn't available at
that time.
Note: The system can't use the generic "snps,dwc2" compatible
because of the special ahbcfg configuration. The default
GAHBCFG_HBSTLEN_INCR4 of snps,dwc2 can cause a system hang
when the USB and SATA is used concurrently.
Signed-off-by: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
---
Sorry, the previous one broke compilation. This fixes it.
Regards,
John
v3 [johnyoun]:
* Fixed compilation issue
v2 [johnyoun]:
* Removed params struct
* Minor commit message formatting
Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
drivers/usb/dwc2/params.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
index ad8f7ff..6c7c2bce 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -12,6 +12,7 @@ Required properties:
- "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs;
- "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs;
- "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs;
+ - "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX SoCs;
- snps,dwc2: A generic DWC2 USB controller with default parameters.
- reg : Should contain 1 register range (address and length)
- interrupts : Should contain 1 interrupt
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 513556a..a786256 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -239,6 +239,7 @@ const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "samsung,s3c6400-hsotg", .data = NULL},
{ .compatible = "amlogic,meson8b-usb", .data = ¶ms_amlogic },
{ .compatible = "amlogic,meson-gxbb-usb", .data = ¶ms_amlogic },
+ { .compatible = "amcc,dwc-otg", .data = NULL },
{},
};
MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
--
2.10.0
--
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 related
* [PATCH v3] usb: dwc2: add amcc,dwc-otg support
From: John Youn @ 2016-11-15 23:03 UTC (permalink / raw)
To: Felipe Balbi
Cc: Christian Lamparter, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, Mark Rutland, Rob Herring,
Greg Kroah-Hartman, John Youn
From: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
This patch adds support for the "amcc,usb-otg" device
which is found in the PowerPC Canyonlands' dts.
The device definition was added by:
commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands
board")
but without any driver support as the dwc2 driver wasn't available at
that time.
Note: The system can't use the generic "snps,dwc2" compatible
because of the special ahbcfg configuration. The default
GAHBCFG_HBSTLEN_INCR4 of snps,dwc2 can cause a system hang
when the USB and SATA is used concurrently.
Signed-off-by: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
---
Sorry, the previous one broke compilation. This fixes it.
Regards,
John
v3 [johnyoun]:
* Fixed compilation issue
v2 [johnyoun]:
* Removed params struct
* Minor commit message formatting
Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
drivers/usb/dwc2/params.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
index ad8f7ff..6c7c2bce 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -12,6 +12,7 @@ Required properties:
- "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs;
- "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs;
- "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs;
+ - "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX SoCs;
- snps,dwc2: A generic DWC2 USB controller with default parameters.
- reg : Should contain 1 register range (address and length)
- interrupts : Should contain 1 interrupt
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 513556a..a786256 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -239,6 +239,7 @@ const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "samsung,s3c6400-hsotg", .data = NULL},
{ .compatible = "amlogic,meson8b-usb", .data = ¶ms_amlogic },
{ .compatible = "amlogic,meson-gxbb-usb", .data = ¶ms_amlogic },
+ { .compatible = "amcc,dwc-otg", .data = NULL },
{},
};
MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
--
2.10.0
--
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: [RESEND PATCH 2/2] PCI: rockchip: Add quirk to disable RC's ASPM L0s
From: Rob Herring @ 2016-11-15 22:26 UTC (permalink / raw)
To: Shawn Lin
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Wenrui Li,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Jeffy Chen, Brian Norris,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Bjorn Helgaas
In-Reply-To: <1479096666-112668-2-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Mon, Nov 14, 2016 at 12:11:06PM +0800, Shawn Lin wrote:
> Rockchip's RC outputs 100MHz reference clock but there are
> two methods for PHY to generate it.
>
> (1)One of them is to use system PLL to generate 100MHz clock and
> the PHY will relock it and filter signal noise then outputs the
> reference clock.
>
> (2)Another way is to share Soc's 24MHZ crystal oscillator with
> PHY and force PHY's DLL to generate 100MHz internally.
>
> When using case(2), the exit from L0s doesn't work fine occasionally
> due to the broken design of RC receiver's logical circuit. So even if
> we use extended-synch, it still fails for PHY to relock the bits from
> FTS sometimes. This will hang the system.
>
> Maybe we could argue that why not use case(1) to avoid it? The reason
> is that as we could see the reference clock is derived from system PLL
> and the path from it to PHY isn't so clean which means there are some
> noise introduced by power-domain and other buses can't be filterd out
> by PHY and we could see noise from the frequency spectrum by oscilloscope.
> This makes the TX compatibility test a little difficult to pass the spec.
> So case(1) and case(2) are both used indeed now. If using case(2), we
> should disable RC's L0s support, and that is why we need this property to
> indicate this quirk.
Doesn't the driver know which case it is using? I don't see why you need
the quirk property.
>
> Also after checking quirk.c, I noticed there is already a quirk for
> disabling L0s unconditionally, quirk_disable_aspm_l0s. But obviously we
> shouldn't do that as mentioned above that case(1) could still works fine
> with L0s.
^ permalink raw reply
* Re: [PATCH 08/10] ASoC: sun4i-codec: Add support for H3 codec
From: Rob Herring @ 2016-11-15 22:23 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Liam Girdwood, Mark Brown, Maxime Ripard, Lee Jones, Mark Rutland,
alsa-devel, linux-arm-kernel, linux-kernel, devicetree,
Mylene Josserand
In-Reply-To: <20161112064648.26779-9-wens@csie.org>
On Sat, Nov 12, 2016 at 02:46:46PM +0800, Chen-Yu Tsai wrote:
> The codec on the H3 is similar to the one found on the A31. One key
> difference is the analog path controls are routed through the PRCM
> block. This is supported by the sun8i-codec-analog driver, and tied
> into this codec driver with the audio card's aux_dev.
>
> In addition, the H3 has no HP (headphone) and HBIAS support, and no
> MIC3 input. The FIFO related registers are slightly rearranged.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> .../devicetree/bindings/sound/sun4i-codec.txt | 3 +
Acked-by: Rob Herring <robh@kernel.org>
> sound/soc/sunxi/sun4i-codec.c | 71 ++++++++++++++++++++++
> 2 files changed, 74 insertions(+)
^ permalink raw reply
* Re: [PATCH 04/10] ASoC: sun4i-codec: Add support for A23 codec
From: Rob Herring @ 2016-11-15 22:23 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Liam Girdwood, Mark Brown, Maxime Ripard, Lee Jones, Mark Rutland,
alsa-devel, linux-arm-kernel, linux-kernel, devicetree,
Mylene Josserand
In-Reply-To: <20161112064648.26779-5-wens@csie.org>
On Sat, Nov 12, 2016 at 02:46:42PM +0800, Chen-Yu Tsai wrote:
> The codec in the A23 is similar to the one found on the A31. One key
> difference is the analog path controls are routed through the PRCM
> block. This is supported by the sun8i-codec-analog driver, and tied
> into this codec driver with the audio card's aux_dev.
>
> In addition, the A23 does not have LINEOUT, and it does not support
> headset jack detection or buttons.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> .../devicetree/bindings/sound/sun4i-codec.txt | 11 ++-
Acked-by: Rob Herring <robh@kernel.org>
> sound/soc/sunxi/sun4i-codec.c | 108 +++++++++++++++++++++
> 2 files changed, 117 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH 01/10] ASoC: sunxi: Add bindings for A23/A33/H3 codec's analog path controls
From: Rob Herring @ 2016-11-15 22:22 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Liam Girdwood, Mark Brown, Maxime Ripard, Lee Jones, Mark Rutland,
alsa-devel, linux-arm-kernel, linux-kernel, devicetree,
Mylene Josserand
In-Reply-To: <20161112064648.26779-2-wens@csie.org>
On Sat, Nov 12, 2016 at 02:46:39PM +0800, Chen-Yu Tsai wrote:
> The internal codec on A23/A33/H3 is split into 2 parts. The
> analog path controls are routed through an embedded custom register
> bus accessed through the PRCM block.
>
> The SoCs share a common set of inputs, outputs, and audio paths.
> The following table lists the differences.
>
> ----------------------------------------
> | Feature \ SoC | A23 | A33 | H3 |
> ----------------------------------------
> | Headphone | v | v | |
> ----------------------------------------
> | Line Out | | | v |
> ----------------------------------------
> | Phone In/Out | v | v | |
> ----------------------------------------
>
> Add a binding for this hardware.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> .../devicetree/bindings/sound/sun8i-codec-analog.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v7 7/9] dt-bindings: input: move ads7846 bindings to touchscreen subdirectory
From: Rob Herring @ 2016-11-15 22:16 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Arnd Bergmann,
Michael Welling, Mika Penttilä, Javier Martinez Canillas,
Igor Grinberg, Andrew F. Davis, Mark Brown, Jonathan Cameron,
linux-input, devicetree, linux-kernel, linux-omap, letux-kernel,
linux-iio, kernel
In-Reply-To: <3a0b4f67ae4a40b6fea2f61089ef03cc88f29294.1478890925.git.hns@goldelico.com>
On Fri, Nov 11, 2016 at 08:02:04PM +0100, H. Nikolaus Schaller wrote:
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/devicetree/bindings/input/{ => touchscreen}/ads7846.txt (100%)
>
> diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/input/ads7846.txt
> rename to Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
> --
> 2.7.3
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH V3 1/9] PM / OPP: Reword binding supporting multiple regulators per device
From: Dave Gerlach @ 2016-11-15 22:11 UTC (permalink / raw)
To: Stephen Boyd, Viresh Kumar
Cc: Rob Herring, Mark Brown, Rafael Wysocki, nm, Viresh Kumar,
linaro-kernel, linux-pm, linux-kernel, Vincent Guittot,
devicetree
In-Reply-To: <20161115185645.GA25626@codeaurora.org>
Hi,
On 11/15/2016 12:56 PM, Stephen Boyd wrote:
> On 11/15, Viresh Kumar wrote:
>> On 14-11-16, 18:13, Stephen Boyd wrote:
>>> On 11/14, Rob Herring wrote:
>>>> On Fri, Nov 11, 2016 at 08:41:20AM +0530, Viresh Kumar wrote:
>>>>> On 10-11-16, 14:51, Stephen Boyd wrote:
>>>>>>
>>>>>> No. The supply names (and also clock names/index) should be left
>>>>>> up to the consumer of the OPP table. We don't want to encode any
>>>>>> sort of details like this between the OPP table and the consumer
>>>>>> of it in DT because then it seriously couples the OPP table to
>>>>>> the consumer device. "The binding" in this case that needs to be
>>>>>> updated is the consumer binding, to indicate that it correlated
>>>>>> foo-supply and bar-supply to index 0 and 1 of the OPP table
>>>>>> voltages.
>>>>>
>>>>> Are you saying that we shall have a property like this then?
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
>>>>> index ee91cbdd95ee..733946df2fb8 100644
>>>>> --- a/Documentation/devicetree/bindings/opp/opp.txt
>>>>> +++ b/Documentation/devicetree/bindings/opp/opp.txt
>>>>> @@ -389,7 +389,10 @@ Example 4: Handling multiple regulators
>>>>> compatible = "arm,cortex-a7";
>>>>> ...
>>>>>
>>>>> - cpu-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>;
>>>>> + vcc0-supply = <&cpu_supply0>;
>>>>> + vcc1-supply = <&cpu_supply1>;
>>>>> + vcc2-supply = <&cpu_supply2>;
>>>>> + opp-supply-names = "vcc0", "vcc1", "vcc2";
>>>>
>>>> Uh, no. You already have the names in the *-supply properties. Yes, they
>>>> are a PIA to retrieve compared to a *-names property, but that is the
>>>> nature of this style of binding.
>>
>> Its not just PIA, but impossible AFAICT.
>>
>> There are two important pieces of information we need for multiple
>> regulator support:
>> - Which regulator in the consumer node corresponds to which entry in
>> the OPP table. As Mark mentioned earlier, DT should be able to get
>> us this.
>
> This is also possible from C code though. Or is there some case
> where it isn't possible if we're sharing the same table with two
> devices? I'm lost on when this would ever happen.
>
> It feels like trying to keep the OPP table agnostic of the
> consuming device and the device's binding is more trouble than
> it's worth. Especially considering we have opp-shared and *-name
> now.
I agree with this, I do not like having to pass a list of regulator
names to the opp core that I *hope* the device I am controlling has
provided. The intent seems to be to use the cpufreq-dt driver as is and
not pass any cpu-supply anymore so the cpufreq-dt driver has no
knowledge of what regulators are present (it operates as it would today
on a system with no regulator required). But as is it will move forward
regardless of whether or not we actually intended to provide a multi
regulator set up or platform set_opp helper, and this probably isn't
ideal. I would think cpufreq-dt/opp core should be have knowledge of
what regulators are needed to achieve these opp transitions and make
sure everything is in place before moving ahead.
>
>> - The order in which the supplies need to be programmed. We have all
>> agreed to do this in code instead of inferring it from DT and this
>> patch series already does that.
>
> Agreed. Encoding a sequence into DT doesn't sound very feasible.
> How is this going to be handled though? I don't see any users of
> the code we're reviewing here, so it's hard to grasp how things
> will work. It would be really useful if we had some user of the
> code included in the patch series to get the big picture.
I have sent a patch in reply to the cover letter of this series showing
the driver that I used to test multi regulator on TI am57x platform and
wrote as much detail as I could on how I used what Viresh has provided.
Perhaps that will show how this can be used and help to see what's
missing from the core implementation here.
Previous discussions drove me to pass regulators and necessary values in
the DT but do all sequencing from the driver from fixed code without
inferring anything from the device tree.
Regards,
Dave
>
>>
>> I want to solve the first problem here and I don't see how it can be
>> solved using such entries:
>>
>> cpus {
>> cpu@0 {
>> compatible = "arm,cortex-a7";
>> ...
>>
>> vcc0-supply = <&cpu_supply0>;
>> vcc1-supply = <&cpu_supply1>;
>> vcc2-supply = <&cpu_supply2>;
>> operating-points-v2 = <&cpu0_opp_table>;
>> };
>> };
>>
>> cpu0_opp_table: opp_table0 {
>> compatible = "operating-points-v2";
>> opp-shared;
>>
>> opp@1000000000 {
>> opp-hz = /bits/ 64 <1000000000>;
>> opp-microvolt = <970000>, /* Supply 0 */
>> <960000>, /* Supply 1 */
>> <960000>; /* Supply 2 */
>> };
>> };
>>
>> The code can't figure out which of vcc0, vcc1, vcc2 is added first in
>> the CPU node and so we need to get the order somehow. A separate
>> binding as I mentioned earlier is a probably (ugly) solution.
>>
>>> I think the problem is that Viresh wants the binding to be "self
>>> describing" so that the OPP can be used without a driver knowing
>>> that a supply corresponds to a particular column in the voltage
>>> table.
>>
>> Right, and that's what Mark suggested as well.
>>
>>> I don't understand that though. Can't we set the supply
>>> names from C code somewhere based on the consumer of the OPPs?
>>
>> That's what this patch series is doing right now.
>>
>> So, are you saying that the way this patchset does it is fine with you
>> ?
>
> That's just to handle the ordering of operations? I need to take
> a minute and understand what's changing. You may have spent
> plenty of time developing/updating, but I haven't spent near
> enough time understanding what's going on in these patches to
> give a thorough review.
>
^ permalink raw reply
* Re: specifying order of /dev/mmcblk devices via device-tree?
From: Russell King - ARM Linux @ 2016-11-15 22:10 UTC (permalink / raw)
To: Tim Harvey
Cc: Ulf Hansson, Mark Rutland, Javier Martinez Canillas,
Fabio Estevam, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAJ+vNU2t5f=HQ94_GW-cry7DV3FsR9Vx-ck_E-eNuDk5vd-eaw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Nov 15, 2016 at 01:39:42PM -0800, Tim Harvey wrote:
> On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux
> <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
> > On Tue, Nov 15, 2016 at 12:27:53PM -0800, Tim Harvey wrote:
> >> On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
> >> <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
> >> > So, someone merged a patch which makes mmcblk devices follow the
> >> > host controller numbering.
> >> >
> >> > Now my cubox-i fails to boot correctly because the SD card in the
> >> > _only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
> >> >
> >> > USDHC1 is wired to the on-microsom WiFi, and never has anything
> >> > remotely near a SD card or eMMC present. So, this change is
> >> > confusing on these platforms.
> >> >
> >> > Moreover, this is _going_ to break SolidRun distros if people upgrade
> >> > their kernels.
> >> >
> >> > It may be appropriate for eMMC, but it's not appropriate everywhere.
> >> >
> >> > This is a user visible _regression_ in 4.9-rc. Whoever did this,
> >> > please revert whatever change caused this, and next time limit it
> >> > to only eMMC.
> >> >
> >> > Thanks.
> >>
> >> I see the same thing on newer kernels, which is why I asked the
> >> question. I didn't expect (or even want honestly) a non mmcblk0 boot
> >> device and was looking for a way to control that via dt. Now I'm
> >> understanding that to avoid this kind of bootloader/kernel dependence
> >> issue I should be using UUID's to identify the boot device.
> >>
> >> >From my testing it looks like the change your looking for occurred
> >> some time ago and is somewhere between 4.5 and 4.6 and not a 4.9
> >> regression specifically.
> >
> > That depends how you look at it. Yes, there's a change in 4.5 to 4.6
> > which ties the block device number to the host device index, but that's
> > really only part of the story here.
> >
> > 4.8 definitely identifies the SD card in iMX6 usdhc2 as "mmcblk0".
> > 4.9-rc identifies the SD card as "mmcblk1". This makes it a 4.9 change
> > of behaviour - there can be no argument about that.
> >
> > Now, digging further into this today, it appears that:
> >
> > v4.8: usdhc2 was probed first, and is given mmc0.
> > usdhc1 is probed second, and is given mmc1.
> >
> > v4.9-rc: usdhc1 is probed first, and is given mmc0.
> > usdhc2 is probed second, and is given mmc1.
> >
> > I haven't yet been able to figure out why there's been this change
> > of probe order. There's no change that I can see in the iMX6 DT
> > files that would account for this.
> >
>
> I bisected it and the commit your looking for is
> 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d
No it's not.
Let me try and put it plainer:
* Commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d ties the mmc block
device number (mmcblkN) to the mmc host interface number (mmcN).
This change happened between 4.5 and 4.6.
* The change I'm seeing happened between 4.8 and 4.9-rc. I'm not
seeing a change of behaviour between 4.5 and 4.6.
* The change I'm seeing changes the order of the physical device
associated with the hosts named mmc0 and mmc1 in the kernel.
* Because physical devices associated with the mmc0 and mmc1 hosts
swap over, the mmcblkN number changes due to the commit you point
out.
* So, the change that I'm seeing between 4.8 and 4.9-rc is not caused
by commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d, but by something
else changing the order in which the two usdhc physical hardware
blocks get probed.
Does this make it clearer?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] dt-binding: remoteproc: Introduce ADSP loader binding
From: Rob Herring @ 2016-11-15 22:08 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Ohad Ben-Cohen, Mark Rutland,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Sarangdhar Joshi
In-Reply-To: <1478757009-11522-1-git-send-email-bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Wed, Nov 09, 2016 at 09:50:09PM -0800, Bjorn Andersson wrote:
> This document defines the binding for a component that loads firmware
> and control the life cycle of the Qualcomm ADSP Hexagon core.
>
> Cc: Sarangdhar Joshi <spjoshi-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>
> Changes since v2:
> - Added the required "xo" clock, from Sarangdhar
> - Added smd-edge node
> - Corrected example
>
> Changes since v1:
> - Added platform names to compatible
>
> .../devicetree/bindings/remoteproc/qcom,adsp.txt | 98 ++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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