Re: [PATCH v1 2/8] spi: dw: Add device tree properties for fields in CTRL0
On 3/22/20 4:33 AM, Sean Anderson wrote: > On 3/21/20 11:13 PM, Marek Vasut wrote: >> On 3/22/20 4:08 AM, Sean Anderson wrote: >>> On 3/21/20 11:04 PM, Marek Vasut wrote: Could be a different revision of the IP. This is usually handled by using SoC-specific compatible strings, see e.g. Linux Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml You don't want to encode register layout in the DT. >>> >>> Ok, then I think adding compatible strings would be the cleanest. >>> > It is possible to > add several compatible strings like "kendryte,k210-spi3". Why ? >>> >>> See below. >>> > I chose this > method because the bitfields are different for spi0 and spi1, spi2, and > spi3. If there are other incompatibilities discovered, then it may make > more sense to use different strings. Another option could have been to > use the DW_SPI_VERSION field to detect different controllers, but it is > the same among all the controllers on the K210. The controllers on the same SoC have different register layout ? >>> >>> Yup! >>> >>> Don't ask me why. >> >> Now that is truly an odd design. Is there a datasheet for this SoC ? > > Nope. Everything has been done referencing their sdk. > > In hindsight, porting this board was a poor decision because of all the > hoops I've had to jump through due to the absence of documentation. > Unfortunately, it's probably the only budget risc-v board with S-mode > until the end of the year or so. > >> You might be able to somehow enumerate those controllers in DT and >> derive their layout from that enumeration or somesuch I think. > > So like derive it from the sequence number? I'd rather do this in a more > standard way, if possible. I would rather like to know why do the controllers have different register layout.
Re: [PATCH v8 00/12] Actions S700 SoC support
Hi Andre, On 22 March 2020 5:31:11 AM IST, "André Przywara" wrote: >On 21/03/2020 17:30, Amit Singh Tomar wrote: > >Hi Mani, > >> This adds Cubieboard7[1] support based on Action Semi's S700 SoC[2], >It's Quad-core ARMv8 SoC >> with Cortex-A53 cores. Peripheral like UART seems to be compatible >with S900 SoC(basic support >> for it is alreay present in u-boot). > >I reviewed the series and am now happy with it - I added the missing >review tags for patch 1 and 9. >I find the instructions in the final patch quite convoluted and >somewhat >cumbersome, but I guess this is more due to the vendor boot process >being somewhat closed down. > >I have neither hardware, so can't test anything, but at least I compile >tested every patch with bubblegum_96_defconfig, and the final patch >with >cubieboard7_defconfig. I hope that I didn't miss anything that would >break the Bubblegum board, but please test it if you have the hardware. > I've been shadowing this series due to not getting enough time for reviewing/testing. I hope to spend time next week on this. Thanks Amit for your patience and updates. Regards, Mani >Amit, thanks for your continued work on this and the prompt replies! > >Cheers, >Andre > >> >> This series(v8) removes the SoC specific include instead just uses >owl-common. For this >> patch 01/12 and 09/12 changes a bit. >> >> Previous series(v7) fixes a serious Bug that breaks S900, it was >there since v5.Thanks to Andre >> for pointing it out. >> >> Series(v6)[3] does following changes: >> >> * [PATCH v5 06/11] becomes [PATCH v6 03/11] >> * [PATCH v5 03/11] becomes [PATCH v6 04/11] >> * Introduce a new patch to move defconfig options to Kconfig which is >[PATCH v6 10/12] >> >> Series(v5)[4] just re-orders the patches so that U-BOOT(with >bubblegum96_defconfig) builds >> after every patch of the series(suggested by Andre). >> >> S700 support is tested[5] on Cubieboard7 board and S900 support is >just compiled tested. >> >> This patch series can be tested using below tree: >> https://github.com/Atomar25/u-boot/commits/s700_v8 >> >> [1]: http://www.cubietech.com/product-detail/cubieboard7/ >> [2]: http://www.actions-semi.com/en/productview.aspx?id=225 >> [3]: >http://u-boot.10912.n7.nabble.com/PATCH-v6-00-12-Actions-S700-SoC-support-td403562.html#a403567 >> [4]: >http://u-boot.10912.n7.nabble.com/PATCH-v5-00-11-Actions-S700-SoC-support-td402752.html#a402762 >> [5]: https://paste.ubuntu.com/p/xGYVbSytRS/ >> >> Amit Singh Tomar (12): >> arm: actions: Add common framework for Actions Owl Semi SoCs >> arm: actions: rename sysmap-s900 to sysmap-owl >> serial: actions: add compatible string >> arm: dts: sync dts for Action Semi S900 >> arm: dts: actions: s900: add u-boot specific dtsi file >> clk: actions: Add common clock driver >> arm: actions: add S700 SoC device tree >> arm: dts: actions: s700: add u-boot specific dtsi file >> arm: add support Actions Semi S700 >> actions: Move defconfig options to Kconfig >> arm: add Cubieboard7 board support >> doc: boards: add Cubieboard7 documentation >> >> MAINTAINERS| 2 + >> arch/arm/Kconfig | 5 +- >> arch/arm/dts/Makefile | 6 +- >> arch/arm/dts/s700-cubieboard7.dts | 92 +++ >> arch/arm/dts/s700-u-boot.dtsi | 18 ++ >> arch/arm/dts/s700.dtsi | 248 >+++ >> arch/arm/dts/s900-u-boot.dtsi | 17 ++ >> arch/arm/dts/s900.dtsi | 322 >+++-- >> arch/arm/include/asm/arch-owl/clk_s900.h | 57 - >> arch/arm/include/asm/arch-owl/regs_s700.h | 56 + >> arch/arm/mach-owl/Kconfig | 50 ++-- >> arch/arm/mach-owl/Makefile | 3 +- >> arch/arm/mach-owl/soc.c| 57 + >> arch/arm/mach-owl/sysmap-owl.c | 32 +++ >> arch/arm/mach-owl/sysmap-s900.c| 32 --- >> board/ucRobotics/bubblegum_96/Kconfig | 15 -- >> board/ucRobotics/bubblegum_96/MAINTAINERS | 6 - >> board/ucRobotics/bubblegum_96/Makefile | 3 - >> board/ucRobotics/bubblegum_96/bubblegum_96.c | 57 - >> configs/bubblegum_96_defconfig | 12 +- >> configs/cubieboard7_defconfig | 9 + >> doc/board/actions/cubieboard7.rst | 115 + >> doc/board/actions/index.rst| 10 + >> doc/board/index.rst| 1 + >> drivers/clk/owl/Kconfig| 8 +- >> drivers/clk/owl/Makefile | 2 +- >> drivers/clk/owl/clk_owl.c | 153 >> drivers/clk/owl/clk_owl.h | 65 + >> drivers/clk/owl/clk_s900.c | 137 --- >> drivers/serial/serial_owl.c| 2 +- >>
Re: [PATCH v1 5/8] spi: dw: Speed up transfer loops
On 3/21/20 9:49 PM, Marek Vasut wrote:
> On 3/5/20 8:19 PM, Sean Anderson wrote:
>> The transfer loops are very tight on some platforms (especially on higher
>> speeds). If we don't read/write fast enough we can run into over-/under-
>> flow problems. This patch removes several divisions and log statements,
>> and simplifies the read logic.
>>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> drivers/spi/designware_spi.c | 29 +
>> 1 file changed, 9 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
>> index 38c24fe550..613eb0d0e6 100644
>> --- a/drivers/spi/designware_spi.c
>> +++ b/drivers/spi/designware_spi.c
>> @@ -304,7 +304,7 @@ static inline u32 tx_max(struct dw_spi_priv *priv)
>> {
>> u32 tx_left, tx_room, rxtx_gap;
>>
>> -tx_left = (priv->tx_end - priv->tx) / (priv->bits_per_word >> 3);
>> +tx_left = priv->tx_end - priv->tx;
>> tx_room = priv->fifo_len - dw_read(priv, DW_SPI_TXFLR);
>>
>> /*
>> @@ -315,8 +315,7 @@ static inline u32 tx_max(struct dw_spi_priv *priv)
>> * shift registers. So a control from sw point of
>> * view is taken.
>> */
>> -rxtx_gap = ((priv->rx_end - priv->rx) - (priv->tx_end - priv->tx)) /
>> -(priv->bits_per_word >> 3);
>> +rxtx_gap = ((priv->rx_end - priv->rx) - (priv->tx_end - priv->tx));
>>
>> return min3(tx_left, tx_room, (u32)(priv->fifo_len - rxtx_gap));
>> }
>> @@ -324,7 +323,7 @@ static inline u32 tx_max(struct dw_spi_priv *priv)
>> /* Return the max entries we should read out of rx fifo */
>> static inline u32 rx_max(struct dw_spi_priv *priv)
>> {
>> -u32 rx_left = (priv->rx_end - priv->rx) / (priv->bits_per_word >> 3);
>> +u32 rx_left = priv->rx_end - priv->rx;
>>
>> return min_t(u32, rx_left, dw_read(priv, DW_SPI_RXFLR));
>> }
>> @@ -336,15 +335,10 @@ static void dw_writer(struct dw_spi_priv *priv)
>>
>> while (max--) {
>> /* Set the tx word if the transfer's original "tx" is not null
>> */
>> -if (priv->tx_end - priv->len) {
>> -if (priv->bits_per_word == 8)
>> -txw = *(u8 *)(priv->tx);
>> -else
>> -txw = *(u16 *)(priv->tx);
>> -}
>> +if (priv->tx_end - priv->len)
>> +txw = *(u8 *)(priv->tx);
>> dw_write(priv, DW_SPI_DR, txw);
>> -debug("%s: tx=0x%02x\n", __func__, txw);
>> -priv->tx += priv->bits_per_word >> 3;
>> +priv->tx++;
>
> This breaks 16 bits per word transfers, NAK.
>
> The compiler should be able to figure out the rest of the optimizations
> in this patch.
>
Hm, I will try with just the debug symbols removed.
--Sean
Re: [PATCH v1 2/8] spi: dw: Add device tree properties for fields in CTRL0
On 3/21/20 11:13 PM, Marek Vasut wrote: > On 3/22/20 4:08 AM, Sean Anderson wrote: >> On 3/21/20 11:04 PM, Marek Vasut wrote: >>> Could be a different revision of the IP. This is usually handled by >>> using SoC-specific compatible strings, see e.g. Linux >>> Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml >>> >>> You don't want to encode register layout in the DT. >> >> Ok, then I think adding compatible strings would be the cleanest. >> >>> It is possible to add several compatible strings like "kendryte,k210-spi3". >>> >>> Why ? >> >> See below. >> >>> I chose this method because the bitfields are different for spi0 and spi1, spi2, and spi3. If there are other incompatibilities discovered, then it may make more sense to use different strings. Another option could have been to use the DW_SPI_VERSION field to detect different controllers, but it is the same among all the controllers on the K210. >>> >>> The controllers on the same SoC have different register layout ? >>> >> >> Yup! >> >> Don't ask me why. > > Now that is truly an odd design. Is there a datasheet for this SoC ? Nope. Everything has been done referencing their sdk. In hindsight, porting this board was a poor decision because of all the hoops I've had to jump through due to the absence of documentation. Unfortunately, it's probably the only budget risc-v board with S-mode until the end of the year or so. > You might be able to somehow enumerate those controllers in DT and > derive their layout from that enumeration or somesuch I think. So like derive it from the sequence number? I'd rather do this in a more standard way, if possible. --Sean
Re: [PATCH v1 2/8] spi: dw: Add device tree properties for fields in CTRL0
On 3/22/20 4:08 AM, Sean Anderson wrote: > On 3/21/20 11:04 PM, Marek Vasut wrote: >> On 3/22/20 3:36 AM, Sean Anderson wrote: >>> On 3/21/20 9:51 PM, Marek Vasut wrote: On 3/5/20 8:19 PM, Sean Anderson wrote: > Some devices have different layouts for the fields in CTRL0 (e.g. the > Kendryte K210). Allow this layout to be configurable from the device tree. > The documentation has been taken from Linux. > > Signed-off-by: Sean Anderson > Reviewed-by: Simon Glass Can't you just have different compatible string for each SoC and derive the various fields based on that compatible string, instead of describing all the register bitfields in DT ? What does Linux do ? >>> >>> Linux only supports socfpga boards. I don't know if there is any >>> rhyme/reason to the shifting around of these fields. >> >> Could be a different revision of the IP. This is usually handled by >> using SoC-specific compatible strings, see e.g. Linux >> Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml >> >> You don't want to encode register layout in the DT. > > Ok, then I think adding compatible strings would be the cleanest. > >> >>> It is possible to >>> add several compatible strings like "kendryte,k210-spi3". >> >> Why ? > > See below. > >> >>> I chose this >>> method because the bitfields are different for spi0 and spi1, spi2, and >>> spi3. If there are other incompatibilities discovered, then it may make >>> more sense to use different strings. Another option could have been to >>> use the DW_SPI_VERSION field to detect different controllers, but it is >>> the same among all the controllers on the K210. >> >> The controllers on the same SoC have different register layout ? >> > > Yup! > > Don't ask me why. Now that is truly an odd design. Is there a datasheet for this SoC ? You might be able to somehow enumerate those controllers in DT and derive their layout from that enumeration or somesuch I think.
Re: [PATCH v1 2/8] spi: dw: Add device tree properties for fields in CTRL0
On 3/21/20 11:04 PM, Marek Vasut wrote: > On 3/22/20 3:36 AM, Sean Anderson wrote: >> On 3/21/20 9:51 PM, Marek Vasut wrote: >>> On 3/5/20 8:19 PM, Sean Anderson wrote: Some devices have different layouts for the fields in CTRL0 (e.g. the Kendryte K210). Allow this layout to be configurable from the device tree. The documentation has been taken from Linux. Signed-off-by: Sean Anderson Reviewed-by: Simon Glass >>> >>> Can't you just have different compatible string for each SoC and derive >>> the various fields based on that compatible string, instead of >>> describing all the register bitfields in DT ? >>> >>> What does Linux do ? >>> >> >> Linux only supports socfpga boards. I don't know if there is any >> rhyme/reason to the shifting around of these fields. > > Could be a different revision of the IP. This is usually handled by > using SoC-specific compatible strings, see e.g. Linux > Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml > > You don't want to encode register layout in the DT. Ok, then I think adding compatible strings would be the cleanest. > >> It is possible to >> add several compatible strings like "kendryte,k210-spi3". > > Why ? See below. > >> I chose this >> method because the bitfields are different for spi0 and spi1, spi2, and >> spi3. If there are other incompatibilities discovered, then it may make >> more sense to use different strings. Another option could have been to >> use the DW_SPI_VERSION field to detect different controllers, but it is >> the same among all the controllers on the K210. > > The controllers on the same SoC have different register layout ? > Yup! Don't ask me why. --Sean
Re: [PATCH v1 2/8] spi: dw: Add device tree properties for fields in CTRL0
On 3/22/20 3:36 AM, Sean Anderson wrote: > On 3/21/20 9:51 PM, Marek Vasut wrote: >> On 3/5/20 8:19 PM, Sean Anderson wrote: >>> Some devices have different layouts for the fields in CTRL0 (e.g. the >>> Kendryte K210). Allow this layout to be configurable from the device tree. >>> The documentation has been taken from Linux. >>> >>> Signed-off-by: Sean Anderson >>> Reviewed-by: Simon Glass >> >> Can't you just have different compatible string for each SoC and derive >> the various fields based on that compatible string, instead of >> describing all the register bitfields in DT ? >> >> What does Linux do ? >> > > Linux only supports socfpga boards. I don't know if there is any > rhyme/reason to the shifting around of these fields. Could be a different revision of the IP. This is usually handled by using SoC-specific compatible strings, see e.g. Linux Documentation/devicetree/bindings/usb/renesas,usb3-peri.yaml You don't want to encode register layout in the DT. > It is possible to > add several compatible strings like "kendryte,k210-spi3". Why ? > I chose this > method because the bitfields are different for spi0 and spi1, spi2, and > spi3. If there are other incompatibilities discovered, then it may make > more sense to use different strings. Another option could have been to > use the DW_SPI_VERSION field to detect different controllers, but it is > the same among all the controllers on the K210. The controllers on the same SoC have different register layout ? -- Best regards, Marek Vasut
Re: [PATCH v1 7/8] riscv: Add device tree bindings for SPI
On 3/21/20 9:55 PM, Marek Vasut wrote:
> On 3/5/20 8:19 PM, Sean Anderson wrote:
>> This patch adds bindings for the MMC slot and SPI flash on the Sipeed Maix
>> Bit.
>
> The mail subject should say this is for specific SoC
Oh, whoops. This will be fixed in the next revision.
> [...]
>
>> + {
>> +status = "okay";
>> };
>
> This shouldn't be here I guess ?
Yeah, this was meant to be added in a separate series for the wdt.
>
> You should split this into the .dtsi addition for SoC and board specific
> patch.
Ok.
--Sean
Re: [PATCH v1 2/8] spi: dw: Add device tree properties for fields in CTRL0
On 3/21/20 9:51 PM, Marek Vasut wrote: > On 3/5/20 8:19 PM, Sean Anderson wrote: >> Some devices have different layouts for the fields in CTRL0 (e.g. the >> Kendryte K210). Allow this layout to be configurable from the device tree. >> The documentation has been taken from Linux. >> >> Signed-off-by: Sean Anderson >> Reviewed-by: Simon Glass > > Can't you just have different compatible string for each SoC and derive > the various fields based on that compatible string, instead of > describing all the register bitfields in DT ? > > What does Linux do ? > Linux only supports socfpga boards. I don't know if there is any rhyme/reason to the shifting around of these fields. It is possible to add several compatible strings like "kendryte,k210-spi3". I chose this method because the bitfields are different for spi0 and spi1, spi2, and spi3. If there are other incompatibilities discovered, then it may make more sense to use different strings. Another option could have been to use the DW_SPI_VERSION field to detect different controllers, but it is the same among all the controllers on the K210. --Sean
Re: [PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller
On 3/22/20 3:08 AM, Simon Glass wrote: > Hi Marek, Hi, > I think at this point we've covered all the ground and mentioned the > pros and cons of each method, so I'll leave the discussion where it > is. Great, so let's remove the struct-based access from the driver and use regular #define REGISTER 0xoffset. Thank you.
Re: [PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller
Hi Marek, I think at this point we've covered all the ground and mentioned the pros and cons of each method, so I'll leave the discussion where it is. [..] Regards, Simon
Re: [PATCH v1 7/8] riscv: Add device tree bindings for SPI
On 3/5/20 8:19 PM, Sean Anderson wrote:
> This patch adds bindings for the MMC slot and SPI flash on the Sipeed Maix
> Bit.
The mail subject should say this is for specific SoC.
[...]
> + {
> + status = "okay";
> };
This shouldn't be here I guess ?
You should split this into the .dtsi addition for SoC and board specific
patch.
Re: [PATCH v1 1/8] doc: Fix typo in FIT documentation
On 3/5/20 8:19 PM, Sean Anderson wrote: > u_boot should be u-boot > > Signed-off-by: Sean Anderson > Reviewed-by: Bin Meng > --- > > doc/uImage.FIT/source_file_format.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/uImage.FIT/source_file_format.txt > b/doc/uImage.FIT/source_file_format.txt > index 18d2aedcb7..00c4dc337c 100644 > --- a/doc/uImage.FIT/source_file_format.txt > +++ b/doc/uImage.FIT/source_file_format.txt > @@ -172,7 +172,7 @@ the '/images' node should have the following layout: >- os : OS name, mandatory for types "kernel" and "ramdisk". Valid OS names > are: "openbsd", "netbsd", "freebsd", "4_4bsd", "linux", "svr4", "esix", > "solaris", "irix", "sco", "dell", "ncr", "lynxos", "vxworks", "psos", > "qnx", > -"u_boot", "rtems", "unity", "integrity". > +"u-boot", "rtems", "unity", "integrity". I wonder why 4_4bsd in that list is also spelled with an underscore ?
Re: [PATCH v1 2/8] spi: dw: Add device tree properties for fields in CTRL0
On 3/5/20 8:19 PM, Sean Anderson wrote: > Some devices have different layouts for the fields in CTRL0 (e.g. the > Kendryte K210). Allow this layout to be configurable from the device tree. > The documentation has been taken from Linux. > > Signed-off-by: Sean Anderson > Reviewed-by: Simon Glass Can't you just have different compatible string for each SoC and derive the various fields based on that compatible string, instead of describing all the register bitfields in DT ? What does Linux do ?
Re: [PATCH v1 5/8] spi: dw: Speed up transfer loops
On 3/5/20 8:19 PM, Sean Anderson wrote:
> The transfer loops are very tight on some platforms (especially on higher
> speeds). If we don't read/write fast enough we can run into over-/under-
> flow problems. This patch removes several divisions and log statements,
> and simplifies the read logic.
>
> Signed-off-by: Sean Anderson
> ---
>
> drivers/spi/designware_spi.c | 29 +
> 1 file changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
> index 38c24fe550..613eb0d0e6 100644
> --- a/drivers/spi/designware_spi.c
> +++ b/drivers/spi/designware_spi.c
> @@ -304,7 +304,7 @@ static inline u32 tx_max(struct dw_spi_priv *priv)
> {
> u32 tx_left, tx_room, rxtx_gap;
>
> - tx_left = (priv->tx_end - priv->tx) / (priv->bits_per_word >> 3);
> + tx_left = priv->tx_end - priv->tx;
> tx_room = priv->fifo_len - dw_read(priv, DW_SPI_TXFLR);
>
> /*
> @@ -315,8 +315,7 @@ static inline u32 tx_max(struct dw_spi_priv *priv)
>* shift registers. So a control from sw point of
>* view is taken.
>*/
> - rxtx_gap = ((priv->rx_end - priv->rx) - (priv->tx_end - priv->tx)) /
> - (priv->bits_per_word >> 3);
> + rxtx_gap = ((priv->rx_end - priv->rx) - (priv->tx_end - priv->tx));
>
> return min3(tx_left, tx_room, (u32)(priv->fifo_len - rxtx_gap));
> }
> @@ -324,7 +323,7 @@ static inline u32 tx_max(struct dw_spi_priv *priv)
> /* Return the max entries we should read out of rx fifo */
> static inline u32 rx_max(struct dw_spi_priv *priv)
> {
> - u32 rx_left = (priv->rx_end - priv->rx) / (priv->bits_per_word >> 3);
> + u32 rx_left = priv->rx_end - priv->rx;
>
> return min_t(u32, rx_left, dw_read(priv, DW_SPI_RXFLR));
> }
> @@ -336,15 +335,10 @@ static void dw_writer(struct dw_spi_priv *priv)
>
> while (max--) {
> /* Set the tx word if the transfer's original "tx" is not null
> */
> - if (priv->tx_end - priv->len) {
> - if (priv->bits_per_word == 8)
> - txw = *(u8 *)(priv->tx);
> - else
> - txw = *(u16 *)(priv->tx);
> - }
> + if (priv->tx_end - priv->len)
> + txw = *(u8 *)(priv->tx);
> dw_write(priv, DW_SPI_DR, txw);
> - debug("%s: tx=0x%02x\n", __func__, txw);
> - priv->tx += priv->bits_per_word >> 3;
> + priv->tx++;
This breaks 16 bits per word transfers, NAK.
The compiler should be able to figure out the rest of the optimizations
in this patch.
Re: [PATCH v8 00/12] Actions S700 SoC support
On 21/03/2020 17:30, Amit Singh Tomar wrote: Hi Mani, > This adds Cubieboard7[1] support based on Action Semi's S700 SoC[2], It's > Quad-core ARMv8 SoC > with Cortex-A53 cores. Peripheral like UART seems to be compatible with S900 > SoC(basic support > for it is alreay present in u-boot). I reviewed the series and am now happy with it - I added the missing review tags for patch 1 and 9. I find the instructions in the final patch quite convoluted and somewhat cumbersome, but I guess this is more due to the vendor boot process being somewhat closed down. I have neither hardware, so can't test anything, but at least I compile tested every patch with bubblegum_96_defconfig, and the final patch with cubieboard7_defconfig. I hope that I didn't miss anything that would break the Bubblegum board, but please test it if you have the hardware. Amit, thanks for your continued work on this and the prompt replies! Cheers, Andre > > This series(v8) removes the SoC specific include instead just uses > owl-common. For this > patch 01/12 and 09/12 changes a bit. > > Previous series(v7) fixes a serious Bug that breaks S900, it was there since > v5.Thanks to Andre > for pointing it out. > > Series(v6)[3] does following changes: > > * [PATCH v5 06/11] becomes [PATCH v6 03/11] > * [PATCH v5 03/11] becomes [PATCH v6 04/11] > * Introduce a new patch to move defconfig options to Kconfig which is [PATCH > v6 10/12] > > Series(v5)[4] just re-orders the patches so that U-BOOT(with > bubblegum96_defconfig) builds > after every patch of the series(suggested by Andre). > > S700 support is tested[5] on Cubieboard7 board and S900 support is just > compiled tested. > > This patch series can be tested using below tree: > https://github.com/Atomar25/u-boot/commits/s700_v8 > > [1]: http://www.cubietech.com/product-detail/cubieboard7/ > [2]: http://www.actions-semi.com/en/productview.aspx?id=225 > [3]: > http://u-boot.10912.n7.nabble.com/PATCH-v6-00-12-Actions-S700-SoC-support-td403562.html#a403567 > [4]: > http://u-boot.10912.n7.nabble.com/PATCH-v5-00-11-Actions-S700-SoC-support-td402752.html#a402762 > [5]: https://paste.ubuntu.com/p/xGYVbSytRS/ > > Amit Singh Tomar (12): > arm: actions: Add common framework for Actions Owl Semi SoCs > arm: actions: rename sysmap-s900 to sysmap-owl > serial: actions: add compatible string > arm: dts: sync dts for Action Semi S900 > arm: dts: actions: s900: add u-boot specific dtsi file > clk: actions: Add common clock driver > arm: actions: add S700 SoC device tree > arm: dts: actions: s700: add u-boot specific dtsi file > arm: add support Actions Semi S700 > actions: Move defconfig options to Kconfig > arm: add Cubieboard7 board support > doc: boards: add Cubieboard7 documentation > > MAINTAINERS| 2 + > arch/arm/Kconfig | 5 +- > arch/arm/dts/Makefile | 6 +- > arch/arm/dts/s700-cubieboard7.dts | 92 +++ > arch/arm/dts/s700-u-boot.dtsi | 18 ++ > arch/arm/dts/s700.dtsi | 248 +++ > arch/arm/dts/s900-u-boot.dtsi | 17 ++ > arch/arm/dts/s900.dtsi | 322 > +++-- > arch/arm/include/asm/arch-owl/clk_s900.h | 57 - > arch/arm/include/asm/arch-owl/regs_s700.h | 56 + > arch/arm/mach-owl/Kconfig | 50 ++-- > arch/arm/mach-owl/Makefile | 3 +- > arch/arm/mach-owl/soc.c| 57 + > arch/arm/mach-owl/sysmap-owl.c | 32 +++ > arch/arm/mach-owl/sysmap-s900.c| 32 --- > board/ucRobotics/bubblegum_96/Kconfig | 15 -- > board/ucRobotics/bubblegum_96/MAINTAINERS | 6 - > board/ucRobotics/bubblegum_96/Makefile | 3 - > board/ucRobotics/bubblegum_96/bubblegum_96.c | 57 - > configs/bubblegum_96_defconfig | 12 +- > configs/cubieboard7_defconfig | 9 + > doc/board/actions/cubieboard7.rst | 115 + > doc/board/actions/index.rst| 10 + > doc/board/index.rst| 1 + > drivers/clk/owl/Kconfig| 8 +- > drivers/clk/owl/Makefile | 2 +- > drivers/clk/owl/clk_owl.c | 153 > drivers/clk/owl/clk_owl.h | 65 + > drivers/clk/owl/clk_s900.c | 137 --- > drivers/serial/serial_owl.c| 2 +- > include/configs/bubblegum_96.h | 40 --- > include/configs/owl-common.h | 40 +++ > include/configs/s700.h | 13 + > include/configs/s900.h | 16 ++ > include/dt-bindings/clock/actions,s700-cmu.h | 118 + > include/dt-bindings/clock/actions,s900-cmu.h | 129
Re: [PATCH v8 01/12] arm: actions: Add common framework for Actions Owl Semi SoCs
On 21/03/2020 17:30, Amit Singh Tomar wrote: > This commit adds common arch support for Actions Semi Owl > series SoCs and removes the Bubblegum96 board files. > > Signed-off-by: Amit Singh Tomar Reviewed-by: Andre Przywara Cheers, Andre > --- > Changes since v7: > * Removed S900 specific include file. > * Removed the file list entry in MAINTAINERS file. > Changes since v6: > * No change. > Changes since v5: > * No change. > Changes since v4: > * No change. > Changes since v3: > * Corrected the file list entry in MAINTAINERS file. > Changes since v2: > * Moved the file list details to root MAINTAINERS file. > * Updated the commit message as suggested by Mani. > * Used the "Owl" keyword to describe SoC family. > Changes since v1: > * Moved S700 specific changes to patch 4 of 9. > * Moved couple of symbols from defconfig to arch/arm/Kconfig > and platform owl Kconfig. > --- > MAINTAINERS | 3 +- > arch/arm/Kconfig | 3 +- > arch/arm/mach-owl/Kconfig| 29 ++ > arch/arm/mach-owl/Makefile | 1 + > arch/arm/mach-owl/soc.c | 57 > > board/ucRobotics/bubblegum_96/Kconfig| 15 > board/ucRobotics/bubblegum_96/MAINTAINERS| 6 --- > board/ucRobotics/bubblegum_96/Makefile | 3 -- > board/ucRobotics/bubblegum_96/bubblegum_96.c | 57 > > configs/bubblegum_96_defconfig | 4 +- > include/configs/bubblegum_96.h | 40 --- > include/configs/owl-common.h | 40 +++ > 12 files changed, 114 insertions(+), 144 deletions(-) > create mode 100644 arch/arm/mach-owl/soc.c > delete mode 100644 board/ucRobotics/bubblegum_96/Kconfig > delete mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS > delete mode 100644 board/ucRobotics/bubblegum_96/Makefile > delete mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c > delete mode 100644 include/configs/bubblegum_96.h > create mode 100644 include/configs/owl-common.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 92dda40..73ee1ac 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -272,9 +272,10 @@ M: Manivannan Sadhasivam > > S: Maintained > F: arch/arm/include/asm/arch-owl/ > F: arch/arm/mach-owl/ > -F: board/ucRobotics/ > F: drivers/clk/owl/ > F: drivers/serial/serial_owl.c > +F: include/configs/owl-common.h > +F: configs/bubblegum_96_defconfig > > ARM RENESAS RMOBILE/R-CAR > M: Nobuhiro Iwamatsu > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 5d36788..1cfdcb6 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -873,9 +873,9 @@ config ARCH_MX5 > > config ARCH_OWL > bool "Actions Semi OWL SoCs" > - select ARM64 > select DM > select DM_SERIAL > + select OWL_SERIAL > select OF_CONTROL > imply CMD_DM > > @@ -1865,7 +1865,6 @@ source "board/spear/spear600/Kconfig" > source "board/spear/x600/Kconfig" > source "board/st/stv0991/Kconfig" > source "board/tcl/sl50/Kconfig" > -source "board/ucRobotics/bubblegum_96/Kconfig" > source "board/birdland/bav335x/Kconfig" > source "board/toradex/colibri_pxa270/Kconfig" > source "board/variscite/dart_6ul/Kconfig" > diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig > index 199e772..28984c1 100644 > --- a/arch/arm/mach-owl/Kconfig > +++ b/arch/arm/mach-owl/Kconfig > @@ -1,27 +1,22 @@ > if ARCH_OWL > > -config SYS_SOC > - default "owl" > - > choice > -prompt "Actions Semi OWL SoCs board select" > +prompt "Actions Semi Owl SoC Variant" > optional > > -config TARGET_BUBBLEGUM_96 > - bool "96Boards Bubblegum-96" > - help > - Support for 96Boards Bubblegum-96. This board complies with > - 96Board Consumer Edition Specification. Features: > - - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU) > - - 2GiB RAM > - - 8GiB eMMC, uSD slot > - - WiFi, Bluetooth and GPS module > - - 2x Host, 1x Device USB port > - - HDMI > - - 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons > +config MACH_S900 > +bool "Actions Semi S900 SoC" > +select ARM64 > > endchoice > > -source "board/ucRobotics/bubblegum_96/Kconfig" > +config SYS_TEXT_BASE > +default 0x1100 > + > +config SYS_CONFIG_NAME > +default "owl-common" > + > +config SYS_SOC > +default "s900" if MACH_S900 > > endif > diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile > index 1b43dc2..0b181c6 100644 > --- a/arch/arm/mach-owl/Makefile > +++ b/arch/arm/mach-owl/Makefile > @@ -1,3 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0+ > > +obj-y += soc.o > obj-y += sysmap-s900.o > diff --git
Re: [PATCH v8 09/12] arm: add support Actions Semi S700
On 21/03/2020 17:30, Amit Singh Tomar wrote: > This patch adds basic support for Actions Semi based S700 > SoC, which is driven by common owl framework. > > Signed-off-by: Amit Singh Tomar Reviewed-by: Andre Przywara Cheers, Andre > --- > Changes since v7: > * Removed S700 include file. > Changes since v6: > * No changes. > Changes since v5: > * Added reviewed-by tag. > Changes since v4: > * Moved it to 09/11 to 04/11. > Changes since v3: > * Added "SoC" keyword to Actions Semi S700. > Changes since v2: > * Fixed the commit message. > * Checked for the clk->id. > * Added a .data member with SoC type. > * Removed #ifdefs from few places. > Changes since v1: > * Moved CLK and CLK_OWL symbols from defconfig to arch/arm/Kconfig. > --- > arch/arm/mach-owl/Kconfig | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig > index 28984c1..cde2ade 100644 > --- a/arch/arm/mach-owl/Kconfig > +++ b/arch/arm/mach-owl/Kconfig > @@ -8,6 +8,10 @@ config MACH_S900 > bool "Actions Semi S900 SoC" > select ARM64 > > +config MACH_S700 > +bool "Actions Semi S700 SoC" > +select ARM64 > + > endchoice > > config SYS_TEXT_BASE > @@ -18,5 +22,6 @@ config SYS_CONFIG_NAME > > config SYS_SOC > default "s900" if MACH_S900 > +default "s700" if MACH_S700 > > endif >
Re: [PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller
On 3/21/20 8:34 PM, Simon Glass wrote:
> Hi Marek,
Hi,
> On Sat, 21 Mar 2020 at 13:01, Marek Vasut wrote:
>>
>> On 3/21/20 7:41 PM, Simon Glass wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> On Sat, 21 Mar 2020 at 11:00, Marek Vasut wrote:
On 3/21/20 5:42 PM, Simon Glass wrote:
> Hi Marek,
Hi,
> On Sat, 21 Mar 2020 at 09:09, Marek Vasut wrote:
>>
>> On 3/21/20 3:12 PM, Simon Glass wrote:
>>> Hi Marek,
>>>
>>> On Wed, 11 Mar 2020 at 01:11, Marek Vasut wrote:
On 3/11/20 7:50 AM, Chunfeng Yun wrote:
[...]
> + * @u3_ctrl_p[x]: ip usb3 port x control register, only low 4bytes
> are used
> + * @u2_ctrl_p[x]: ip usb2 port x control register, only low 4bytes
> are used
> + * @u2_phy_pll: usb2 phy pll control register
> + */
> +struct mtk_ippc_regs {
> + __le32 ip_pw_ctr0;
> + __le32 ip_pw_ctr1;
> + __le32 ip_pw_ctr2;
Please define the registers with #define macros , this struct-based
approach doesn't scale.
>>>
>>> What does this mean? I much prefer the struct approach, unless the
>>> registers move around in future generations.
>>
>> This means I want to see #define MTK_XHCI_ 0xf00
>>
>> The struct based approach doesn't scale and on e.g. altera is causing us
>> a massive amount of problems now. It looked like a good idea back then,
>> but now it's a massive burden, so I don't want that to proliferate. And
>> here I would expect the registers to move around, just like everywhere
>> else.
>
> That sounds like something that is easily avoided. For example,
> Designware doesn't seem to move things around.
>
> Perhaps MediaTek has a policy of not doing this either?
Such policies change as the hardware evolves. I got burned by this
struct-based approach more often then it was beneficial, if it ever
really was beneficial, hence I don't want to see it used.
>>>
>>> Some benefits:
>>> - using C struct instead of 'assembler-like' addition is less error-prone
>>
>> In my experience, this is exactly the opposite. If I have a long
>> structure describing some register set and I have to count lines to
>> figure out which register it is at offset e.g. 0x124 , then I am very
>> likely to make a mistake. However, if I have a macro which looks like
>> #define REG_FOO 0x124 , I see it right away.
>
> See check_member() though.
This only adds duplication and more complexity. With this, not only do
you have a structure which is difficult and error-prone to work with,
but you also have a macro which defines the offset, but only for the
purpose of preventing errors originally induced by the complexity of
working with the structure.
So this is complexity on top of complexity.
> How do you know it is as offset 0x124?
I see this offset in the datasheet of the IP/SoC/whatever and/or I can
simply git grep for this value in the sources. And since this value is
there verbatim, I see #define REG_FOO 0x124, simple.
With the complexity presented above, this no longer works. I have to
comb through structures (possibly embedded in other structures)
manually, I cannot directly grep for the register offsets, and it's
complicated, cumbersome and massively error prone.
>> And I am not even talking about modifying such structures, where one has
>> to over and over recount and verify that nothing got padded the wrong
>> way. Worse yet, that the structure might just be embedded in some other
>> super-structure, in which case the superstructure gets padded
>> differently if the sub-structure changes in size.
>
> You always have the choice. You are over-dramatising the difference by
> coming up with cases where 'struct' doesn't work.
I am coming up with real world experience I have, which tells me that
this does not work in the long run in vast majority of cases and/or is a
massive pain to work with.
Obviously, I come up with cases where this struct based approach fails
and/or displays it's shortcomings, where else would I demonstrate all
the problems with this ?
> I'm not suggesting
> struct should be used always, but to me it has clear benefits in many
> drivers in terms of readability and maintainability. We have both
> written and maintained a lot of drivers. Also see
> ich_init_controller() for a hybrid approach.
Sorry, I just don't see the clear benefit.
Originally I thought this struct-based approach was a good idea too,
which is why I was pushing for it a lot back then, but now I think it
was a big mistake.
>> Let alone the problematic fact that you might have multiple versions of
>> the same IP in the system, with just slightly different register
>> layouts, at which point the structures become ridden with unions {} and
>> it becomes a total hell.
>
> I don't think structs should be used in that situation though, unless
> it is just for a few
Re: [PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller
Hi Marek,
On Sat, 21 Mar 2020 at 13:01, Marek Vasut wrote:
>
> On 3/21/20 7:41 PM, Simon Glass wrote:
> > Hi Marek,
>
> Hi,
>
> > On Sat, 21 Mar 2020 at 11:00, Marek Vasut wrote:
> >>
> >> On 3/21/20 5:42 PM, Simon Glass wrote:
> >>> Hi Marek,
> >>
> >> Hi,
> >>
> >>> On Sat, 21 Mar 2020 at 09:09, Marek Vasut wrote:
>
> On 3/21/20 3:12 PM, Simon Glass wrote:
> > Hi Marek,
> >
> > On Wed, 11 Mar 2020 at 01:11, Marek Vasut wrote:
> >>
> >> On 3/11/20 7:50 AM, Chunfeng Yun wrote:
> >> [...]
> >>> + * @u3_ctrl_p[x]: ip usb3 port x control register, only low 4bytes
> >>> are used
> >>> + * @u2_ctrl_p[x]: ip usb2 port x control register, only low 4bytes
> >>> are used
> >>> + * @u2_phy_pll: usb2 phy pll control register
> >>> + */
> >>> +struct mtk_ippc_regs {
> >>> + __le32 ip_pw_ctr0;
> >>> + __le32 ip_pw_ctr1;
> >>> + __le32 ip_pw_ctr2;
> >>
> >> Please define the registers with #define macros , this struct-based
> >> approach doesn't scale.
> >>
> >
> > What does this mean? I much prefer the struct approach, unless the
> > registers move around in future generations.
>
> This means I want to see #define MTK_XHCI_ 0xf00
>
> The struct based approach doesn't scale and on e.g. altera is causing us
> a massive amount of problems now. It looked like a good idea back then,
> but now it's a massive burden, so I don't want that to proliferate. And
> here I would expect the registers to move around, just like everywhere
> else.
> >>>
> >>> That sounds like something that is easily avoided. For example,
> >>> Designware doesn't seem to move things around.
> >>>
> >>> Perhaps MediaTek has a policy of not doing this either?
> >>
> >> Such policies change as the hardware evolves. I got burned by this
> >> struct-based approach more often then it was beneficial, if it ever
> >> really was beneficial, hence I don't want to see it used.
> >
> > Some benefits:
> > - using C struct instead of 'assembler-like' addition is less error-prone
>
> In my experience, this is exactly the opposite. If I have a long
> structure describing some register set and I have to count lines to
> figure out which register it is at offset e.g. 0x124 , then I am very
> likely to make a mistake. However, if I have a macro which looks like
> #define REG_FOO 0x124 , I see it right away.
See check_member() though. How do you know it is as offset 0x124?
>
> And I am not even talking about modifying such structures, where one has
> to over and over recount and verify that nothing got padded the wrong
> way. Worse yet, that the structure might just be embedded in some other
> super-structure, in which case the superstructure gets padded
> differently if the sub-structure changes in size.
You always have the choice. You are over-dramatising the difference by
coming up with cases where 'struct' doesn't work. I'm not suggesting
struct should be used always, but to me it has clear benefits in many
drivers in terms of readability and maintainability. We have both
written and maintained a lot of drivers. Also see
ich_init_controller() for a hybrid approach.
>
> Let alone the problematic fact that you might have multiple versions of
> the same IP in the system, with just slightly different register
> layouts, at which point the structures become ridden with unions {} and
> it becomes a total hell.
I don't think structs should be used in that situation though, unless
it is just for a few fields.
>
> So no, this argument I am not buying, sorry.
>
> Also, how is C preprocessor macro assembler like ?
Well in assembler we used to have [BASE + REG_TX], [BASE + REG_RX].
That is what structs are for, so not using them is ignoring a useful
feature of the C language.
>
> > - you can pass the regs struct around between functions in the driver,
> > particularly helpful in large drivers
>
> You can pass base addresses around too.
Untyped though. Then you need casts and defeat the type system, etc.
For example in one driver there are two different register sets and it
is nice to pass just the pointer you need without any ambiguity.
>
> > - lower-case letters are reasier to read
>
> That's a matter of taste.
>
> I find it much easier to identify register offsets (and other macros)
> among functions if the offsets are written in uppercase while functions
> in lowercase.
OK
>
> > - you can specify the data size and endianness in the struct using C types
>
> Yes, you can, which is not a benefit but another problem, esp. if that
> structure gets used on systems where CPU and bus endianness can differ.
> (take a look e.g. at the macro monstrosity that is NS16550)
This is a good example of a driver which should be split out, rather
than cramming all the the little tweaks into ifdefs, etc. Also see
serial_out_dynamic() which heads in that direction. Anyway ns16550 has
to deal with registers being of different
Re: [PATCH 1/2] patman: Add option to suppress empty changelog entries
On 3/21/20 3:17 PM, Simon Glass wrote: > Hi Sean, > > On Sat, 21 Mar 2020 at 12:44, Sean Anderson wrote: >> >> On 3/21/20 10:42 AM, Simon Glass wrote: >>> Hi Sean, >>> >>> I can see the value here, particularly for the 'new' case. But I >>> actually appreciate the positive confirmation that nothing changed. >>> Sometimes people send patches and fail to add a change log. >> >> Hm, I don't know if this patch would affect that. If there are no >> "Series-changes" tags, we just get nothing (vs. a bunch of "None"s). >> >>> What happens if a patch has no changes at all since v1? Do you think >>> we should always report 'None' for the last version? >> >> In my opinion, I think we should report nothing. Of course, this patch >> is entirely for aesthetics. It's perfectly valid to do one thing or >> another. In my patches, I like to emulate what I would write if I was >> doing it by hand. > > But as a reviewer, for a v2...n patchset I really do want to see a > change log. If nothing has changed I want to know that, and the > absence of a change log is not enough to convince me that there are no > changes. > > While you have structured your patch as an option, it would be better > to make it the default, so long as we can avoid confusion. > > Perhaps we should have something like '(no changes since v1)' added in > this case? > > Regards, > Simon > That sounds good. --Sean
Re: [PATCH 1/2] patman: Add option to suppress empty changelog entries
Hi Sean, On Sat, 21 Mar 2020 at 12:44, Sean Anderson wrote: > > On 3/21/20 10:42 AM, Simon Glass wrote: > > Hi Sean, > > > > I can see the value here, particularly for the 'new' case. But I > > actually appreciate the positive confirmation that nothing changed. > > Sometimes people send patches and fail to add a change log. > > Hm, I don't know if this patch would affect that. If there are no > "Series-changes" tags, we just get nothing (vs. a bunch of "None"s). > > > What happens if a patch has no changes at all since v1? Do you think > > we should always report 'None' for the last version? > > In my opinion, I think we should report nothing. Of course, this patch > is entirely for aesthetics. It's perfectly valid to do one thing or > another. In my patches, I like to emulate what I would write if I was > doing it by hand. But as a reviewer, for a v2...n patchset I really do want to see a change log. If nothing has changed I want to know that, and the absence of a change log is not enough to convince me that there are no changes. While you have structured your patch as an option, it would be better to make it the default, so long as we can avoid confusion. Perhaps we should have something like '(no changes since v1)' added in this case? Regards, Simon
Re: [PATCH 2/2] patman: Add option to disable combined changelogs
Hi Sean,
On Sat, 21 Mar 2020 at 12:57, Sean Anderson wrote:
>
> On 3/21/20 10:43 AM, Simon Glass wrote:
> > Hi Sean,
> >
> > On Thu, 19 Mar 2020 at 23:37, Sean Anderson wrote:
> >>
> >> By default patman generates a combined changelog for the cover letter. This
> >> may not always be desireable.
> >>
> >> Many patches may have the same changes. These can be coalesced with
> >> "Series-process-log: uniq", but this is imperfect. First, this cannot be
> >> used when there are multi-line changes. In addition, similar changes like
> >
> > We could perhaps support this if we used indentation to indicate multiple
> > lines
> >
> > - line 1 of a multi-line message
> > line 2 here
> > - this is line 1 of a single-line message
>
> That is probably the best solution in general.
OK then let's do that.
>
> >> "Move foo to patch 7" will not be merged with the similar "Move foo to this
> >> patch from patch 6".
> >>
> >> Changes may not make sens outside of the patch they are written for. For
> >
> > sense
> >
> >> example, a change line of "Add check for bar" does not make sense outside
> >> of the context in which bar might be checked for. Some changes like "New"
> >> or "Lint" may be repeated many times throughout different change logs, but
> >> carry no useful information in a summary.
> >>
> >> Lastly, I like to summarize the broad strokes of the changes I have made in
> >> the cover letter, while documenting all the details in the appropriate
> >> patches. I think this make it easier to get a good feel for what has
> >> changed, without making it difficult to wade through every change in the
> >> whole series.
> >>
> >> For these reasons, this patch adds an option to disable the automatic
> >> changelog.
> >>
> >> Signed-off-by: Sean Anderson
> >> ---
> >>
> >> tools/patman/func_test.py | 2 +-
> >> tools/patman/patchstream.py | 7 ---
> >> tools/patman/patman.py | 6 +-
> >> 3 files changed, 10 insertions(+), 5 deletions(-)
> >
> > Thanks for the great explanations on your patches.
> >
> > In the case where there is no automatic change log on the cover
> > letter, do you use 'Series-notes' instead? I'd like to enforce some
> > sort of change log in the cover letter.
>
> That could work, but it doesn't really support combining changes from
> multiple patches. I've been doing it manually, but some automation would
> definitely be better. One idea would be to do something like
It does collate the notes and put it in the cover letter, or at least it should.
>
> Series-changes 12:
> * Summary of the below changes
> - Small change
> - Move foo to bar.c
> - Reformat code to do baz
> * Fix bug where device caught fire
>
> Where only lines beginning with '*' would be included in the combined
> changelog. The character could be configurable. Another option could be
> to do something like
>
> Series-changes 12:
> - Summary of the below changes
> - Small change
> - Move foo to bar.c
> - Reformat code to do baz
> - Fix bug where device caught fire
>
> This is nicer aesthetically, but would make any future multi-line
> treatment of series-changes more difficult.
Perhaps the clearest thing is to have:
Series-changes: (behaviour as now)
Commit-changes: (change log just in the commit/patch, not repeated in
the cover letter)
Cover-changes: (change log just in the cover letter)
This should minimise duplication and makes the scheme optional.
>
> One last option could be to do something like
>
> Summary-changes 12:
> - Summary of below changes
> - Fix bug where device caught fire
>
> Where those changes would be included in the cover letter, but not
> Series-changes. This is probably the easiest to implement, but risks
> adding duplication and making commits more verbose.
>
> > I also think this would be better as a tag in a commit, like
> > 'Series-no-change-log: yes'. That way you set it up when you create
> > the patches, and it persists without needing to add the options each
> > time.
>
> That's probably the best approach.
>
> Should I rebase this series on top of the patch you cc-d me on ("patman:
> Update to use absolute imports")?
Can we hold off until we figure out what we definitely want?
Regards,
Simon
Re: [U-Boot] Sharing a hardware lab
Hi Harald, On Mon, 24 Feb 2020 at 06:27, Harald Seiler wrote: > > Hello Simon, > > On Sun, 2020-02-23 at 19:34 -0700, Simon Glass wrote: > > Hi Heiko, > > > > Thanks for the hints! I pushed your things here: > > > > https://github.com/sglass68/tbot/tree/simon > > > > Then I try: > > tbot -l kea.py -b pcduino3.py uboot_build > > > > and get an error: > > > > tbot starting ... > > type > > ├─Calling uboot_build ... > > │ └─Fail. (0.000s) > > ├─Exception: > > │ Traceback (most recent call last): > > │ File > > "/home/sglass/.local/lib/python3.6/site-packages/tbot-0.8.0-py3.6.egg/tbot/main.py", > > line 318, in main > > │ func(**params) > > │ File > > "/home/sglass/.local/lib/python3.6/site-packages/tbot-0.8.0-py3.6.egg/tbot/decorators.py", > > line 103, in wrapped > > │ result = tc(*args, **kwargs) > > │ File > > "/home/sglass/.local/lib/python3.6/site-packages/tbot-0.8.0-py3.6.egg/tbot/tc/uboot/build.py", > > line 271, in _build > > │ builder = UBootBuilder._get_selected_builder() > > │ File > > "/home/sglass/.local/lib/python3.6/site-packages/tbot-0.8.0-py3.6.egg/tbot/tc/uboot/build.py", > > line 160, in _get_selected_builder > > │ builder = getattr(tbot.selectable.UBootMachine, "build") > > │ AttributeError: type object 'UBootMachine' has no attribute 'build' > > > > I'm a bit lost in all the classes and functions. A working example or > > a patch would be great! > > > > I've pushed all my scripts here: > > > > https://github.com/sglass68/ubtest > > > > The top commit is your patches. > > I think you mixed a few things up while adding Heiko's stuff. Instead > of your last commit, attempt the attached patch. It is untested of > course but should point you in the right direction; here is a short > summary of what it adds: > > 1. Your `kea` lab needs to be marked as a build-host. This means it >needs the `toolchains` property which returns what toolchains are >available. I added a dummy armv7-a toolchain which might need >a bit more adjustment to work for you. > > 2. I created a UBootBuilder for pcduino3. This builder just >specifies what defconfig to build and what toolchain to use (need >to be defined in the selected lab). > >Heiko's builder config is a bit more elaborate and also does some >patching after applying the defconfig. This is of course also >possible if you want to. > > 3. I added a U-Boot config for your board which is needed because >its `build` property specifies which U-Boot builder to use. This >will make the `uboot_build` testcase work properly. Later you >might want to adjust this U-Boot config to actually work so you >can make use of it for flashing the new U-Boot binary. > > Some more links to documentation: > > - Build-host config: https://tbot.tools/modules/machine_linux.html#builder > - UBootBuilder class: > https://tbot.tools/modules/tc.html#tbot.tc.uboot.UBootBuilder > > Hope this helps! Yes it helps a lot, thank you. I now have it building U-Boot: tbot -l kea.py -b pcduino3.py -p clean=False uboot_build interactive_uboot I sent a tiny patch to tbot to fix an error I had, and I made a few minor changes to what you sent. https://github.com/sglass68/ubtest/commit/7da7a3794d505e970e0e21a9b6ed3a7e5f2f2190 So my next question is how to load U-Boot onto the board. I can see methods for poweron/poweroff but not for actually writing to the board. Is there a built-in structure for this? I cannot find it. I am hoping that the Pcduino3 class can define a method like 'load_uboot()' to write U-Boot to the board? Regards, Simon [..]
Re: [PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller
On 3/21/20 7:41 PM, Simon Glass wrote:
> Hi Marek,
Hi,
> On Sat, 21 Mar 2020 at 11:00, Marek Vasut wrote:
>>
>> On 3/21/20 5:42 PM, Simon Glass wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> On Sat, 21 Mar 2020 at 09:09, Marek Vasut wrote:
On 3/21/20 3:12 PM, Simon Glass wrote:
> Hi Marek,
>
> On Wed, 11 Mar 2020 at 01:11, Marek Vasut wrote:
>>
>> On 3/11/20 7:50 AM, Chunfeng Yun wrote:
>> [...]
>>> + * @u3_ctrl_p[x]: ip usb3 port x control register, only low 4bytes are
>>> used
>>> + * @u2_ctrl_p[x]: ip usb2 port x control register, only low 4bytes are
>>> used
>>> + * @u2_phy_pll: usb2 phy pll control register
>>> + */
>>> +struct mtk_ippc_regs {
>>> + __le32 ip_pw_ctr0;
>>> + __le32 ip_pw_ctr1;
>>> + __le32 ip_pw_ctr2;
>>
>> Please define the registers with #define macros , this struct-based
>> approach doesn't scale.
>>
>
> What does this mean? I much prefer the struct approach, unless the
> registers move around in future generations.
This means I want to see #define MTK_XHCI_ 0xf00
The struct based approach doesn't scale and on e.g. altera is causing us
a massive amount of problems now. It looked like a good idea back then,
but now it's a massive burden, so I don't want that to proliferate. And
here I would expect the registers to move around, just like everywhere
else.
>>>
>>> That sounds like something that is easily avoided. For example,
>>> Designware doesn't seem to move things around.
>>>
>>> Perhaps MediaTek has a policy of not doing this either?
>>
>> Such policies change as the hardware evolves. I got burned by this
>> struct-based approach more often then it was beneficial, if it ever
>> really was beneficial, hence I don't want to see it used.
>
> Some benefits:
> - using C struct instead of 'assembler-like' addition is less error-prone
In my experience, this is exactly the opposite. If I have a long
structure describing some register set and I have to count lines to
figure out which register it is at offset e.g. 0x124 , then I am very
likely to make a mistake. However, if I have a macro which looks like
#define REG_FOO 0x124 , I see it right away.
And I am not even talking about modifying such structures, where one has
to over and over recount and verify that nothing got padded the wrong
way. Worse yet, that the structure might just be embedded in some other
super-structure, in which case the superstructure gets padded
differently if the sub-structure changes in size.
Let alone the problematic fact that you might have multiple versions of
the same IP in the system, with just slightly different register
layouts, at which point the structures become ridden with unions {} and
it becomes a total hell.
So no, this argument I am not buying, sorry.
Also, how is C preprocessor macro assembler like ?
> - you can pass the regs struct around between functions in the driver,
> particularly helpful in large drivers
You can pass base addresses around too.
> - lower-case letters are reasier to read
That's a matter of taste.
I find it much easier to identify register offsets (and other macros)
among functions if the offsets are written in uppercase while functions
in lowercase.
> - you can specify the data size and endianness in the struct using C types
Yes, you can, which is not a benefit but another problem, esp. if that
structure gets used on systems where CPU and bus endianness can differ.
(take a look e.g. at the macro monstrosity that is NS16550)
> If the hardware changes enough, then you need a new driver anyway, or
> perhaps separate C implementations of the low-level register access if
> the high-level flow is similar.
Not really, there is a lot of hardware where registers just move around,
but existing driver can very well handle all such instances.
> In general you can't always determine
> this sort of thing at compile time since the version of the hardware
> may not be apparent until run-time. You end up with variables holding
> the offset of each register.
You can use some/any sort of register abstraction to do the remapping.
This is completely independent of how you represent the register offsets.
> Sometimes is it better to have an umbrella driver with a common core.
>
> So I would push back against a move in this direction in general. It
> depends on the circumstances, and anyway, converting from struct to
> offsets if desirable later is not that hard.
NAK, I am opposed to the struct based access, sorry.
We had massive problems moving toward it in multiple areas (socfpga was
hit very bad and I regret it to this day), only to move back from it
these days because it is borderline impossible to accommodate newly
emerging hardware and we suffered problems outlined above often.
If you want one more argument, then Linux is not using this anywhere and
it has much larger driver base. One might expect Linux to be somewhat
Re: [PATCH 2/2] patman: Add option to disable combined changelogs
On 3/21/20 10:43 AM, Simon Glass wrote:
> Hi Sean,
>
> On Thu, 19 Mar 2020 at 23:37, Sean Anderson wrote:
>>
>> By default patman generates a combined changelog for the cover letter. This
>> may not always be desireable.
>>
>> Many patches may have the same changes. These can be coalesced with
>> "Series-process-log: uniq", but this is imperfect. First, this cannot be
>> used when there are multi-line changes. In addition, similar changes like
>
> We could perhaps support this if we used indentation to indicate multiple
> lines
>
> - line 1 of a multi-line message
> line 2 here
> - this is line 1 of a single-line message
That is probably the best solution in general.
>> "Move foo to patch 7" will not be merged with the similar "Move foo to this
>> patch from patch 6".
>>
>> Changes may not make sens outside of the patch they are written for. For
>
> sense
>
>> example, a change line of "Add check for bar" does not make sense outside
>> of the context in which bar might be checked for. Some changes like "New"
>> or "Lint" may be repeated many times throughout different change logs, but
>> carry no useful information in a summary.
>>
>> Lastly, I like to summarize the broad strokes of the changes I have made in
>> the cover letter, while documenting all the details in the appropriate
>> patches. I think this make it easier to get a good feel for what has
>> changed, without making it difficult to wade through every change in the
>> whole series.
>>
>> For these reasons, this patch adds an option to disable the automatic
>> changelog.
>>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> tools/patman/func_test.py | 2 +-
>> tools/patman/patchstream.py | 7 ---
>> tools/patman/patman.py | 6 +-
>> 3 files changed, 10 insertions(+), 5 deletions(-)
>
> Thanks for the great explanations on your patches.
>
> In the case where there is no automatic change log on the cover
> letter, do you use 'Series-notes' instead? I'd like to enforce some
> sort of change log in the cover letter.
That could work, but it doesn't really support combining changes from
multiple patches. I've been doing it manually, but some automation would
definitely be better. One idea would be to do something like
Series-changes 12:
* Summary of the below changes
- Small change
- Move foo to bar.c
- Reformat code to do baz
* Fix bug where device caught fire
Where only lines beginning with '*' would be included in the combined
changelog. The character could be configurable. Another option could be
to do something like
Series-changes 12:
- Summary of the below changes
- Small change
- Move foo to bar.c
- Reformat code to do baz
- Fix bug where device caught fire
This is nicer aesthetically, but would make any future multi-line
treatment of series-changes more difficult.
One last option could be to do something like
Summary-changes 12:
- Summary of below changes
- Fix bug where device caught fire
Where those changes would be included in the cover letter, but not
Series-changes. This is probably the easiest to implement, but risks
adding duplication and making commits more verbose.
> I also think this would be better as a tag in a commit, like
> 'Series-no-change-log: yes'. That way you set it up when you create
> the patches, and it persists without needing to add the options each
> time.
That's probably the best approach.
Should I rebase this series on top of the patch you cc-d me on ("patman:
Update to use absolute imports")?
--Sean
Re: [PATCH 1/2] patman: Add option to suppress empty changelog entries
On 3/21/20 10:42 AM, Simon Glass wrote: > Hi Sean, > > I can see the value here, particularly for the 'new' case. But I > actually appreciate the positive confirmation that nothing changed. > Sometimes people send patches and fail to add a change log. Hm, I don't know if this patch would affect that. If there are no "Series-changes" tags, we just get nothing (vs. a bunch of "None"s). > What happens if a patch has no changes at all since v1? Do you think > we should always report 'None' for the last version? In my opinion, I think we should report nothing. Of course, this patch is entirely for aesthetics. It's perfectly valid to do one thing or another. In my patches, I like to emulate what I would write if I was doing it by hand. --Sean
Re: [PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller
Hi Marek,
On Sat, 21 Mar 2020 at 11:00, Marek Vasut wrote:
>
> On 3/21/20 5:42 PM, Simon Glass wrote:
> > Hi Marek,
>
> Hi,
>
> > On Sat, 21 Mar 2020 at 09:09, Marek Vasut wrote:
> >>
> >> On 3/21/20 3:12 PM, Simon Glass wrote:
> >>> Hi Marek,
> >>>
> >>> On Wed, 11 Mar 2020 at 01:11, Marek Vasut wrote:
>
> On 3/11/20 7:50 AM, Chunfeng Yun wrote:
> [...]
> > + * @u3_ctrl_p[x]: ip usb3 port x control register, only low 4bytes are
> > used
> > + * @u2_ctrl_p[x]: ip usb2 port x control register, only low 4bytes are
> > used
> > + * @u2_phy_pll: usb2 phy pll control register
> > + */
> > +struct mtk_ippc_regs {
> > + __le32 ip_pw_ctr0;
> > + __le32 ip_pw_ctr1;
> > + __le32 ip_pw_ctr2;
>
> Please define the registers with #define macros , this struct-based
> approach doesn't scale.
>
> >>>
> >>> What does this mean? I much prefer the struct approach, unless the
> >>> registers move around in future generations.
> >>
> >> This means I want to see #define MTK_XHCI_ 0xf00
> >>
> >> The struct based approach doesn't scale and on e.g. altera is causing us
> >> a massive amount of problems now. It looked like a good idea back then,
> >> but now it's a massive burden, so I don't want that to proliferate. And
> >> here I would expect the registers to move around, just like everywhere
> >> else.
> >
> > That sounds like something that is easily avoided. For example,
> > Designware doesn't seem to move things around.
> >
> > Perhaps MediaTek has a policy of not doing this either?
>
> Such policies change as the hardware evolves. I got burned by this
> struct-based approach more often then it was beneficial, if it ever
> really was beneficial, hence I don't want to see it used.
Some benefits:
- using C struct instead of 'assembler-like' addition is less error-prone
- you can pass the regs struct around between functions in the driver,
particularly helpful in large drivers
- lower-case letters are reasier to read
- you can specify the data size and endianness in the struct using C types
If the hardware changes enough, then you need a new driver anyway, or
perhaps separate C implementations of the low-level register access if
the high-level flow is similar. In general you can't always determine
this sort of thing at compile time since the version of the hardware
may not be apparent until run-time. You end up with variables holding
the offset of each register.
Sometimes is it better to have an umbrella driver with a common core.
So I would push back against a move in this direction in general. It
depends on the circumstances, and anyway, converting from struct to
offsets if desirable later is not that hard.
Regards,
Simon
[PATCH v8 12/12] doc: boards: add Cubieboard7 documentation
This adds build and flash steps for Actions S700 based Cubieboard7 board. Signed-off-by: Amit Singh Tomar --- Changes since v7: * No changes. Changes since v6: * No changes. Changes since v5: * No changes. Changes since v4: * No changes. Changes since v3: * Convert plain text documentation to reStructuredText format. Changes since v2: * No Change. Changes since v1: * No Change. --- doc/board/actions/cubieboard7.rst | 115 ++ doc/board/actions/index.rst | 10 doc/board/index.rst | 1 + 3 files changed, 126 insertions(+) create mode 100644 doc/board/actions/cubieboard7.rst create mode 100644 doc/board/actions/index.rst diff --git a/doc/board/actions/cubieboard7.rst b/doc/board/actions/cubieboard7.rst new file mode 100644 index 000..ce39e6b --- /dev/null +++ b/doc/board/actions/cubieboard7.rst @@ -0,0 +1,115 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (C) 2020 Amit Singh Tomar + +ACTIONS + + +About this +-- + +This document describes build and flash steps for Actions S700 SoC based Cubieboard7 +board. + +Cubieboard7 initial configuration +- + +Default Cubieboard7 comes with pre-installed Android where U-Boot is configured with +a bootdelay of 0, entering a prompt by pressing keys does not seem to work. + +Though, one can enter ADFU mode and flash debian image(from host machine) where +getting into u-boot prompt is easy. + +Enter ADFU Mode + + +Before write the firmware, let the development board entering the ADFU mode: insert +one end of the USB cable to the PC, press and hold the ADFU button, and then connect +the other end of the USB cable to the Mini USB port of the development board, release +the ADFU button, after connecting it will enter the ADFU mode. + +Check whether entered ADFU Mode + + +The user needs to run the following command on the PC side to check if the ADFU +device is detected. ID realted to "Actions Semiconductor Co., Ltd" means that +the PC side has been correctly detected ADFU device, the development board +also enter into the ADFU mode. + +.. code-block:: none + + $ lsusb + Bus 001 Device 005: ID 04f2:b2eb Chicony Electronics Co., Ltd + Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad] + Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver + Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub + Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub + Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub + Bus 003 Device 013: ID 10d6:10d6 Actions Semiconductor Co., Ltd + Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub + +Flashing debian image +- + +.. code-block:: none + + $ sudo ./ActionsFWU.py --fw=debian-stretch-desktop-cb7-emmc-v2.0.fw + ActionsFWU.py : 1.0.150828.0830 + libScript.so: 2.3.150825.0951 + libFileSystem.so: 2.3.150825.0952 + libProduction.so: 2.3.150915.1527 + =burn all partition + FW_VER: 3.10.37.180608 + 3% DOWNLOAD ADFUDEC ... + 5% DOWNLOAD BOOT PARA ... + 7% SWITCH ADFUDEC ... + 12% DOWNLOAD BL31 ... + 13% DOWNLOAD BL32 ... + 15% DOWNLOAD VMLINUX ... + 20% DOWNLOAD INITRD ... + 24% DOWNLOAD FDT ... + 27% DOWNLOAD ADFUS ... + 30% SWITCH ADFUS ... + 32% DOWNLOAD MBR ... + 35% DOWNLOAD PARTITIONS ... + WRITE_MBRC_PARTITION + 35% write p0 size = 2048 : ok + WRITE_BOOT_PARTITION + 35% write p1 size = 2048 : ok + WRITE_MISC_PARTITION + 36% write p2 size = 98304 : ok + WRITE_SYSTEM_PARTITION + 94% write p3 size = 4608000 : ok + FORMAT_SWAP_PARTITION + 94% write p4 size = 20480 : ok + 95% TRANSFER OVER ... + Firmware upgrade successfully! + +Debian image can be downloaded from here[1]. + +Once debian image is flashed, one can get into u-boot prompt by pressing any key and from +there run ums command(make sure, usb cable is connected between host and target): + +.. code-block:: none + + owl> ums 0 mmc 1 + +Above command would mount debian image partition on host machine. + +Building U-BOOT proper image + + +.. code-block:: none + + $ make clean + $ export CROSS_COMPILE=aarch64-linux-gnu- + $ make ARCH=arm cubieboard7_defconfig + $ make -j16 + $ mkimage -A arm -T firmware -C none -O u-boot -a 0x1100 -e 0x1100 -d u-boot-dtb.bin u-boot-dtb.img >/dev/null + +u-boot-dtb.img can now be flashed to debian image partition mounted on host machine. + +.. code-block:: none + + $ sudo dd if=u-boot-dtb.img of=/dev/sdb bs=1024 seek=3072 + +[1]: https://pan.baidu.com/s/1uawPr0Jao2HgWFLZCLzHAg#list/path=%2FCubieBoard_Download%2FBoard%2FCubieBoard7%2F%E6%96%B9%E7%B3%96%E6%96%B9%E6%A1%88%E5%BC%80%E5%8F%91%E8%B5%84%E6%96%99%2FImage%2FDebian%2FV2.1-test=%2F diff --git
[PATCH v8 11/12] arm: add Cubieboard7 board support
The Cubieboard is a single board computer containing a
Actions S700 SoC(with 4 ARMv8 Cortex-A53 cores).
This patch adds respective defconfig alongwith .dts(copied
from Linux v5.5-rc6 with hash "b3a987b0264d").
Reviewed-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v7:
* No changes.
Changes since v6:
* Added Reviewed-by tag.
Changes since v5:
* Trimmed of the cubieboard7_defconfig.
Changes since v4:
* No changes.
Changes since v3:
* added reviewed-by: tag.
Changes since v2:
* No changes.
Changes since v1:
* No changes.
---
arch/arm/dts/s700-cubieboard7.dts | 92 +++
configs/cubieboard7_defconfig | 9
2 files changed, 101 insertions(+)
create mode 100644 arch/arm/dts/s700-cubieboard7.dts
create mode 100644 configs/cubieboard7_defconfig
diff --git a/arch/arm/dts/s700-cubieboard7.dts
b/arch/arm/dts/s700-cubieboard7.dts
new file mode 100644
index 000..63e375c
--- /dev/null
+++ b/arch/arm/dts/s700-cubieboard7.dts
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ */
+
+/dts-v1/;
+
+#include "s700.dtsi"
+
+/ {
+ compatible = "cubietech,cubieboard7", "actions,s700";
+ model = "CubieBoard7";
+
+ aliases {
+ serial3 =
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x8000>;
+ };
+
+ memory@1,e000 {
+ device_type = "memory";
+ reg = <0x1 0xe000 0x0 0x0>;
+ };
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+};
+
+ {
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+};
+
+ {
+ i2c0_default: i2c0_default {
+ pinmux {
+ groups = "i2c0_mfp";
+ function = "i2c0";
+ };
+ pinconf {
+ pins = "i2c0_sclk", "i2c0_sdata";
+ bias-pull-up;
+ };
+ };
+
+ i2c1_default: i2c1_default {
+ pinmux {
+ groups = "i2c1_dummy";
+ function = "i2c1";
+ };
+ pinconf {
+ pins = "i2c1_sclk", "i2c1_sdata";
+ bias-pull-up;
+ };
+ };
+
+ i2c2_default: i2c2_default {
+ pinmux {
+ groups = "i2c2_dummy";
+ function = "i2c2";
+ };
+ pinconf {
+ pins = "i2c2_sclk", "i2c2_sdata";
+ bias-pull-up;
+ };
+ };
+};
+
+ {
+ clocks = <>;
+};
+
+ {
+ status = "okay";
+};
diff --git a/configs/cubieboard7_defconfig b/configs/cubieboard7_defconfig
new file mode 100644
index 000..d12c293
--- /dev/null
+++ b/configs/cubieboard7_defconfig
@@ -0,0 +1,9 @@
+CONFIG_ARM=y
+CONFIG_ARCH_OWL=y
+CONFIG_MACH_S700=y
+CONFIG_IDENT_STRING="\ncubieboard7"
+CONFIG_BOOTDELAY=5
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyOWL3,115200n8"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DEFAULT_DEVICE_TREE="s700-cubieboard7"
--
2.7.4
[PATCH v8 07/12] arm: actions: add S700 SoC device tree
This patch adds .dtsi file(sync with Linux 5.5-rc6 with hash "b3a987b0264d")
and required binding for S700 SoC that is a 64-bit Quad-core ARM
Cortex-A53 cores.
It also provisions dts file to be built based on selected
platform(CONFIG_MACH_S900/S700).
Reviewed-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v7:
* No changes.
Changes since v6:
* No changes.
Changes since v5:
* Added reviwed-by tag.
Changes since v4:
* Move it to 07/11 from 05/11.
Changes since v3:
* Updated commit message to the Linux tag to
which the dtsi file is synced.
Changes since v2:
* Synced DTS bindings with Linux 5.5.
Changes since v1:
* Moved the u-boot specific changes to s700-u-boot.dtsi, now
s700.dtsi is in complete sync with Linux 4.20.
---
arch/arm/dts/Makefile | 6 +-
arch/arm/dts/s700.dtsi | 248 +
include/dt-bindings/clock/actions,s700-cmu.h | 118
include/dt-bindings/reset/actions,s700-reset.h | 34
4 files changed, 404 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/s700.dtsi
create mode 100644 include/dt-bindings/clock/actions,s700-cmu.h
create mode 100644 include/dt-bindings/reset/actions,s700-reset.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9c593b2..308c76b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -64,8 +64,10 @@ dtb-$(CONFIG_KIRKWOOD) += \
kirkwood-pogo_e02.dtb \
kirkwood-sheevaplug.dtb
-dtb-$(CONFIG_ARCH_OWL) += \
- bubblegum_96.dtb
+dtb-$(CONFIG_MACH_S900) += \
+bubblegum_96.dtb
+dtb-$(CONFIG_MACH_S700) += \
+s700-cubieboard7.dtb
dtb-$(CONFIG_ROCKCHIP_PX30) += \
px30-evb.dtb \
diff --git a/arch/arm/dts/s700.dtsi b/arch/arm/dts/s700.dtsi
new file mode 100644
index 000..2006ad5
--- /dev/null
+++ b/arch/arm/dts/s700.dtsi
@@ -0,0 +1,248 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ */
+
+#include
+#include
+#include
+
+/ {
+ compatible = "actions,s700";
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secmon@1f00 {
+ reg = <0x0 0x1f00 0x0 0x100>;
+ no-map;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ arm-pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = ,
+,
+,
+;
+ interrupt-affinity = <>, <>, <>, <>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ hosc: hosc {
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ #clock-cells = <0>;
+ };
+
+ losc: losc {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ #clock-cells = <0>;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gic: interrupt-controller@e00f1000 {
+ compatible = "arm,gic-400";
+ reg = <0x0 0xe00f1000 0x0 0x1000>,
+ <0x0 0xe00f2000 0x0 0x2000>,
+ <0x0 0xe00f4000 0x0 0x2000>,
+ <0x0 0xe00f6000 0x0 0x2000>;
+ interrupts =
[PATCH v8 04/12] arm: dts: sync dts for Action Semi S900
Synchronize device tree bindings with v5.5-rc6 tag with commit id
"b3a987b0264d".
Also, it removes older clock binding defined for S900 along with undocumented
compatible string "actions,s900-serial" from serial driver and adapts clock
driver to cater to new bindings.
Reviewed-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v7:
* No changes.
Changes since v6:
* Added Reviewed-by tag.
Changes since v5:
* Moved it 04/11 from 03/11.
* removed the undocumented compatible string "actions,s900-serial".
* removed the reviewed-by tag.
Changes since v4:
* This patch is re-ordered, moved from 07/11 to 03/11.
* Used the commit-id(12 chars long) in commit message.
Changes since v3:
* Added Reviewed-by: tag.
Changes since v2:
* Newly added patch, not there in v2/v1.
---
arch/arm/dts/s900.dtsi | 322 +++--
drivers/clk/owl/clk_s900.c | 6 +-
drivers/serial/serial_owl.c| 1 -
include/dt-bindings/clock/actions,s900-cmu.h | 129 ++
include/dt-bindings/clock/s900_cmu.h | 77 --
include/dt-bindings/reset/actions,s900-reset.h | 65 +
6 files changed, 498 insertions(+), 102 deletions(-)
create mode 100644 include/dt-bindings/clock/actions,s900-cmu.h
delete mode 100644 include/dt-bindings/clock/s900_cmu.h
create mode 100644 include/dt-bindings/reset/actions,s900-reset.h
diff --git a/arch/arm/dts/s900.dtsi b/arch/arm/dts/s900.dtsi
index 2bbb30a..eb35cf7 100644
--- a/arch/arm/dts/s900.dtsi
+++ b/arch/arm/dts/s900.dtsi
@@ -1,17 +1,94 @@
-// SPDX-License-Identifier: GPL-2.0+
-//
-// Device Tree Source for Actions Semi S900 SoC
-//
-// Copyright (C) 2015 Actions Semi Co., Ltd.
-// Copyright (C) 2018 Manivannan Sadhasivam
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ */
-/dts-v1/;
-#include
+#include
+#include
+#include
+#include
/ {
compatible = "actions,s900";
- #address-cells = <0x2>;
- #size-cells = <0x2>;
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secmon@1f00 {
+ reg = <0x0 0x1f00 0x0 0x100>;
+ no-map;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ arm-pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = ,
+,
+,
+;
+ interrupt-affinity = <>, <>, <>, <>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ hosc: hosc {
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ #clock-cells = <0>;
+ };
losc: losc {
compatible = "fixed-clock";
@@ -26,28 +103,231 @@
};
soc {
- u-boot,dm-pre-reloc;
compatible = "simple-bus";
- #address-cells = <0x2>;
- #size-cells = <0x2>;
+ #address-cells = <2>;
+ #size-cells = <2>;
ranges;
+ gic: interrupt-controller@e00f1000 {
+ compatible = "arm,gic-400";
+ reg = <0x0 0xe00f1000 0x0 0x1000>,
+ <0x0 0xe00f2000 0x0 0x2000>,
+ <0x0 0xe00f4000 0x0 0x2000>,
+ <0x0 0xe00f6000 0x0 0x2000>;
+
[PATCH v8 10/12] actions: Move defconfig options to Kconfig
This patch moves some of the config options from bubblegum_96_defconfig to platform specific Kconfig file. Reviewed-by: Andre Przywara Signed-off-by: Amit Singh Tomar --- Changes since v7: * No changes. Changes since v6: * remove unnecessary string from SYS_PROMPT. Changes since v5: * Newly added patch, was not there in earlier versions. --- arch/arm/mach-owl/Kconfig | 15 +++ configs/bubblegum_96_defconfig | 5 - 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig index 1d59d8f..8344081 100644 --- a/arch/arm/mach-owl/Kconfig +++ b/arch/arm/mach-owl/Kconfig @@ -25,4 +25,19 @@ config SYS_SOC default "s900" if MACH_S900 default "s700" if MACH_S700 +config DISTRO_DEFAULTS + default y + +config NR_DRAM_BANKS + default 1 + +config SYS_RELOC_GD_ENV_ADDR + default y + +config SYS_PROMPT + default "U-Boot => " + +config DISPLAY_BOARDINFO + default n + endif diff --git a/configs/bubblegum_96_defconfig b/configs/bubblegum_96_defconfig index e76e9a2..0883167 100644 --- a/configs/bubblegum_96_defconfig +++ b/configs/bubblegum_96_defconfig @@ -1,19 +1,14 @@ CONFIG_ARM=y CONFIG_ARCH_OWL=y CONFIG_ENV_SIZE=0x2000 -CONFIG_NR_DRAM_BANKS=1 CONFIG_MACH_S900=y CONFIG_IDENT_STRING="\nBubblegum-96" -CONFIG_DISTRO_DEFAULTS=y CONFIG_BOOTDELAY=5 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyOWL5,115200n8" # CONFIG_DISPLAY_CPUINFO is not set -# CONFIG_DISPLAY_BOARDINFO is not set -CONFIG_SYS_PROMPT="U-Boot => " CONFIG_CMD_MD5SUM=y CONFIG_CMD_MEMINFO=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIMER=y CONFIG_DEFAULT_DEVICE_TREE="bubblegum_96" -CONFIG_SYS_RELOC_GD_ENV_ADDR=y -- 2.7.4
[PATCH v8 09/12] arm: add support Actions Semi S700
This patch adds basic support for Actions Semi based S700 SoC, which is driven by common owl framework. Signed-off-by: Amit Singh Tomar --- Changes since v7: * Removed S700 include file. Changes since v6: * No changes. Changes since v5: * Added reviewed-by tag. Changes since v4: * Moved it to 09/11 to 04/11. Changes since v3: * Added "SoC" keyword to Actions Semi S700. Changes since v2: * Fixed the commit message. * Checked for the clk->id. * Added a .data member with SoC type. * Removed #ifdefs from few places. Changes since v1: * Moved CLK and CLK_OWL symbols from defconfig to arch/arm/Kconfig. --- arch/arm/mach-owl/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig index 28984c1..cde2ade 100644 --- a/arch/arm/mach-owl/Kconfig +++ b/arch/arm/mach-owl/Kconfig @@ -8,6 +8,10 @@ config MACH_S900 bool "Actions Semi S900 SoC" select ARM64 +config MACH_S700 +bool "Actions Semi S700 SoC" +select ARM64 + endchoice config SYS_TEXT_BASE @@ -18,5 +22,6 @@ config SYS_CONFIG_NAME config SYS_SOC default "s900" if MACH_S900 +default "s700" if MACH_S700 endif -- 2.7.4
[PATCH v8 08/12] arm: dts: actions: s700: add u-boot specific dtsi file
Devices like uart and clk are needed to be enabled before relocation.
this patch adds u-boot.dtsi file that mark these device as dm-pre-reloc.
Reviewed-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v7:
* No changes.
Changes since v6:
* No changes.
Changes since v5:
* Added reviwed-by tag.
Changes since v4:
* Moved it to 08/11 to 06/11.
Changes since v3:
* Replaced dtsi with dts in subject line along with arm:dts:
to the prefix.
Changes since v2:
* Added License.
Changes since v1:
* This is newly added file that was *not* present in v1 and
contains u-boot specific changes.
---
arch/arm/dts/s700-u-boot.dtsi | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 arch/arm/dts/s700-u-boot.dtsi
diff --git a/arch/arm/dts/s700-u-boot.dtsi b/arch/arm/dts/s700-u-boot.dtsi
new file mode 100644
index 000..a527ccc
--- /dev/null
+++ b/arch/arm/dts/s700-u-boot.dtsi
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Amit Singh Tomar
+ */
+
+/{
+ soc {
+ u-boot,dm-pre-reloc;
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
--
2.7.4
[PATCH v8 06/12] clk: actions: Add common clock driver
This patch converts S900 clock driver to something common that can
be used for other SoCs, for instance S700(few of clk registers are same).
Reviewed-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v7:
* No changes.
Changes since v6:
* Fixed the bug that breaks S900(missing break in switch statement).
Changes since v5:
* No changes.
Changes since v4:
* This patch is re-ordered, moved from 08/11 to 04/11.
Changes since v3:
* Replaced dtsi with dts in subject line along with arm:dts:
to the prefix.
* Added reviewed-by tag.
Changes since v2:
* Newly added patch, not there in v2/v1.
---
arch/arm/Kconfig | 2 +
arch/arm/include/asm/arch-owl/clk_s900.h | 57 ---
arch/arm/include/asm/arch-owl/regs_s700.h | 56 +++
configs/bubblegum_96_defconfig| 3 -
drivers/clk/owl/Kconfig | 8 +-
drivers/clk/owl/Makefile | 2 +-
drivers/clk/owl/clk_owl.c | 153 ++
drivers/clk/owl/clk_owl.h | 65 +
drivers/clk/owl/clk_s900.c| 137 --
9 files changed, 279 insertions(+), 204 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h
create mode 100644 arch/arm/include/asm/arch-owl/regs_s700.h
create mode 100644 drivers/clk/owl/clk_owl.c
create mode 100644 drivers/clk/owl/clk_owl.h
delete mode 100644 drivers/clk/owl/clk_s900.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1cfdcb6..dba4d8c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -876,6 +876,8 @@ config ARCH_OWL
select DM
select DM_SERIAL
select OWL_SERIAL
+ select CLK
+ select CLK_OWL
select OF_CONTROL
imply CMD_DM
diff --git a/arch/arm/include/asm/arch-owl/clk_s900.h
b/arch/arm/include/asm/arch-owl/clk_s900.h
deleted file mode 100644
index 88e88f7..000
--- a/arch/arm/include/asm/arch-owl/clk_s900.h
+++ /dev/null
@@ -1,57 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Actions Semi S900 Clock Definitions
- *
- * Copyright (C) 2015 Actions Semi Co., Ltd.
- * Copyright (C) 2018 Manivannan Sadhasivam
- *
- */
-
-#ifndef _OWL_CLK_S900_H_
-#define _OWL_CLK_S900_H_
-
-#include
-
-struct owl_clk_priv {
- phys_addr_t base;
-};
-
-/* BUSCLK register definitions */
-#define CMU_PDBGDIV_8 7
-#define CMU_PDBGDIV_SHIFT 26
-#define CMU_PDBGDIV_DIV(CMU_PDBGDIV_8 << CMU_PDBGDIV_SHIFT)
-#define CMU_PERDIV_8 7
-#define CMU_PERDIV_SHIFT 20
-#define CMU_PERDIV_DIV (CMU_PERDIV_8 << CMU_PERDIV_SHIFT)
-#define CMU_NOCDIV_2 1
-#define CMU_NOCDIV_SHIFT 19
-#define CMU_NOCDIV_DIV (CMU_NOCDIV_2 << CMU_NOCDIV_SHIFT)
-#define CMU_DMMCLK_SRC_APLL2
-#define CMU_DMMCLK_SRC_SHIFT 10
-#define CMU_DMMCLK_SRC (CMU_DMMCLK_SRC_APLL << CMU_DMMCLK_SRC_SHIFT)
-#define CMU_APBCLK_DIV BIT(8)
-#define CMU_NOCCLK_SRC BIT(7)
-#define CMU_AHBCLK_DIV BIT(4)
-#define CMU_CORECLK_MASK 3
-#define CMU_CORECLK_CPLL BIT(1)
-#define CMU_CORECLK_HOSC BIT(0)
-
-/* COREPLL register definitions */
-#define CMU_COREPLL_EN BIT(9)
-#define CMU_COREPLL_HOSC_ENBIT(8)
-#define CMU_COREPLL_OUT(1104 / 24)
-
-/* DEVPLL register definitions */
-#define CMU_DEVPLL_CLK BIT(12)
-#define CMU_DEVPLL_EN BIT(8)
-#define CMU_DEVPLL_OUT (660 / 6)
-
-/* UARTCLK register definitions */
-#define CMU_UARTCLK_SRC_DEVPLL BIT(16)
-
-/* DEVCLKEN1 register definitions */
-#define CMU_DEVCLKEN1_UART5BIT(21)
-
-#define PLL_STABILITY_WAIT_US 50
-
-#endif
diff --git a/arch/arm/include/asm/arch-owl/regs_s700.h
b/arch/arm/include/asm/arch-owl/regs_s700.h
new file mode 100644
index 000..2f21c15
--- /dev/null
+++ b/arch/arm/include/asm/arch-owl/regs_s700.h
@@ -0,0 +1,56 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Actions Semi S700 Register Definitions
+ *
+ */
+
+#ifndef _OWL_REGS_S700_H_
+#define _OWL_REGS_S700_H_
+
+#define CMU_COREPLL0x
+#define CMU_DEVPLL 0x0004
+#define CMU_DDRPLL 0x0008
+#define CMU_NANDPLL0x000C
+#define CMU_DISPLAYPLL 0x0010
+#define CMU_AUDIOPLL 0x0014
+#define CMU_TVOUTPLL 0x0018
+#define CMU_BUSCLK 0x001C
+#define CMU_SENSORCLK 0x0020
+#define CMU_LCDCLK 0x0024
+#define CMU_DSIPLLCLK 0x0028
+#define CMU_CSICLK 0x002C
+#define CMU_DECLK 0x0030
+#define CMU_SICLK 0x0034
+#define CMU_BUSCLK10x0038
+#define CMU_HDECLK 0x003C
+#define CMU_VDECLK 0x0040
+#define CMU_VCECLK 0x0044
+#define CMU_NANDCCLK 0x004C
+#define CMU_SD0CLK 0x0050
+#define CMU_SD1CLK 0x0054
+#define CMU_SD2CLK 0x0058
[PATCH v8 02/12] arm: actions: rename sysmap-s900 to sysmap-owl
Now that memory maps(for both S700 and S900 SoCs) can be managed using
a common file, rename sysmap-s900 to sysmap-owl to reflect the same.
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Amit Singh Tomar
---
Changes since v7:
* No changes.
Changes since v6:
* No changes.
Changes since v5:
* No changes.
Changes since v4:
* No changes.
Changes since v3:
* Added reviewed-by tag.
Changes since v2:
* Fixed the commit message and header.
Changes since v1:
* compile sysmap-owl.c against CONFIG_ARM64 now.
---
arch/arm/mach-owl/Makefile | 2 +-
arch/arm/mach-owl/sysmap-owl.c | 32
arch/arm/mach-owl/sysmap-s900.c | 32
3 files changed, 33 insertions(+), 33 deletions(-)
create mode 100644 arch/arm/mach-owl/sysmap-owl.c
delete mode 100644 arch/arm/mach-owl/sysmap-s900.c
diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile
index 0b181c6..f3a69eb 100644
--- a/arch/arm/mach-owl/Makefile
+++ b/arch/arm/mach-owl/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0+
obj-y += soc.o
-obj-y += sysmap-s900.o
+obj-$(CONFIG_ARM64) += sysmap-owl.o
diff --git a/arch/arm/mach-owl/sysmap-owl.c b/arch/arm/mach-owl/sysmap-owl.c
new file mode 100644
index 000..81f6ca2
--- /dev/null
+++ b/arch/arm/mach-owl/sysmap-owl.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Memory map for Actions Semi Owl series SoCs.
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam
+ */
+
+#include
+#include
+
+static struct mm_region owl_mem_map[] = {
+ {
+ .virt = 0x0UL, /* DDR */
+ .phys = 0x0UL, /* DDR */
+ .size = 0x8000UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+ }, {
+ .virt = 0xE000UL, /* Peripheral block */
+ .phys = 0xE000UL, /* Peripheral block */
+ .size = 0x0800UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* List terminator */
+ 0,
+ }
+};
+
+struct mm_region *mem_map = owl_mem_map;
diff --git a/arch/arm/mach-owl/sysmap-s900.c b/arch/arm/mach-owl/sysmap-s900.c
deleted file mode 100644
index f78b639..000
--- a/arch/arm/mach-owl/sysmap-s900.c
+++ /dev/null
@@ -1,32 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Actions Semi S900 Memory map
- *
- * Copyright (C) 2015 Actions Semi Co., Ltd.
- * Copyright (C) 2018 Manivannan Sadhasivam
- */
-
-#include
-#include
-
-static struct mm_region s900_mem_map[] = {
- {
- .virt = 0x0UL, /* DDR */
- .phys = 0x0UL, /* DDR */
- .size = 0x8000UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
- }, {
- .virt = 0xE000UL, /* Peripheral block */
- .phys = 0xE000UL, /* Peripheral block */
- .size = 0x0800UL,
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
- }, {
- /* List terminator */
- 0,
- }
-};
-
-struct mm_region *mem_map = s900_mem_map;
--
2.7.4
[PATCH v8 01/12] arm: actions: Add common framework for Actions Owl Semi SoCs
This commit adds common arch support for Actions Semi Owl series SoCs and removes the Bubblegum96 board files. Signed-off-by: Amit Singh Tomar --- Changes since v7: * Removed S900 specific include file. * Removed the file list entry in MAINTAINERS file. Changes since v6: * No change. Changes since v5: * No change. Changes since v4: * No change. Changes since v3: * Corrected the file list entry in MAINTAINERS file. Changes since v2: * Moved the file list details to root MAINTAINERS file. * Updated the commit message as suggested by Mani. * Used the "Owl" keyword to describe SoC family. Changes since v1: * Moved S700 specific changes to patch 4 of 9. * Moved couple of symbols from defconfig to arch/arm/Kconfig and platform owl Kconfig. --- MAINTAINERS | 3 +- arch/arm/Kconfig | 3 +- arch/arm/mach-owl/Kconfig| 29 ++ arch/arm/mach-owl/Makefile | 1 + arch/arm/mach-owl/soc.c | 57 board/ucRobotics/bubblegum_96/Kconfig| 15 board/ucRobotics/bubblegum_96/MAINTAINERS| 6 --- board/ucRobotics/bubblegum_96/Makefile | 3 -- board/ucRobotics/bubblegum_96/bubblegum_96.c | 57 configs/bubblegum_96_defconfig | 4 +- include/configs/bubblegum_96.h | 40 --- include/configs/owl-common.h | 40 +++ 12 files changed, 114 insertions(+), 144 deletions(-) create mode 100644 arch/arm/mach-owl/soc.c delete mode 100644 board/ucRobotics/bubblegum_96/Kconfig delete mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS delete mode 100644 board/ucRobotics/bubblegum_96/Makefile delete mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c delete mode 100644 include/configs/bubblegum_96.h create mode 100644 include/configs/owl-common.h diff --git a/MAINTAINERS b/MAINTAINERS index 92dda40..73ee1ac 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -272,9 +272,10 @@ M: Manivannan Sadhasivam S: Maintained F: arch/arm/include/asm/arch-owl/ F: arch/arm/mach-owl/ -F: board/ucRobotics/ F: drivers/clk/owl/ F: drivers/serial/serial_owl.c +F: include/configs/owl-common.h +F: configs/bubblegum_96_defconfig ARM RENESAS RMOBILE/R-CAR M: Nobuhiro Iwamatsu diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 5d36788..1cfdcb6 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -873,9 +873,9 @@ config ARCH_MX5 config ARCH_OWL bool "Actions Semi OWL SoCs" - select ARM64 select DM select DM_SERIAL + select OWL_SERIAL select OF_CONTROL imply CMD_DM @@ -1865,7 +1865,6 @@ source "board/spear/spear600/Kconfig" source "board/spear/x600/Kconfig" source "board/st/stv0991/Kconfig" source "board/tcl/sl50/Kconfig" -source "board/ucRobotics/bubblegum_96/Kconfig" source "board/birdland/bav335x/Kconfig" source "board/toradex/colibri_pxa270/Kconfig" source "board/variscite/dart_6ul/Kconfig" diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig index 199e772..28984c1 100644 --- a/arch/arm/mach-owl/Kconfig +++ b/arch/arm/mach-owl/Kconfig @@ -1,27 +1,22 @@ if ARCH_OWL -config SYS_SOC - default "owl" - choice -prompt "Actions Semi OWL SoCs board select" +prompt "Actions Semi Owl SoC Variant" optional -config TARGET_BUBBLEGUM_96 - bool "96Boards Bubblegum-96" - help - Support for 96Boards Bubblegum-96. This board complies with - 96Board Consumer Edition Specification. Features: - - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU) - - 2GiB RAM - - 8GiB eMMC, uSD slot - - WiFi, Bluetooth and GPS module - - 2x Host, 1x Device USB port - - HDMI - - 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons +config MACH_S900 +bool "Actions Semi S900 SoC" +select ARM64 endchoice -source "board/ucRobotics/bubblegum_96/Kconfig" +config SYS_TEXT_BASE +default 0x1100 + +config SYS_CONFIG_NAME +default "owl-common" + +config SYS_SOC +default "s900" if MACH_S900 endif diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile index 1b43dc2..0b181c6 100644 --- a/arch/arm/mach-owl/Makefile +++ b/arch/arm/mach-owl/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0+ +obj-y += soc.o obj-y += sysmap-s900.o diff --git a/arch/arm/mach-owl/soc.c b/arch/arm/mach-owl/soc.c new file mode 100644 index 000..409cbd3 --- /dev/null +++ b/arch/arm/mach-owl/soc.c @@ -0,0 +1,57 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Actions Semi Owl SoCs platform support. + * + * Copyright (C) 2018 Manivannan Sadhasivam + */ + +#include +#include +#include +#include
[PATCH v8 03/12] serial: actions: add compatible string
This patch adds "actions,owl-uart" string to the owl uart driver. It
is also defined in Linux kernel.
Reviewed-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v7:
* No changes.
Changes since v6:
* Added Reviewd-by tag.
Changes since v5:
* Moved it to from 06/11 to 03/11.
* Used appropriate commit message.
* Removed the reviwed-by tag.
Changes since v4:
* Moved it to from 09/11 to 06/11.
Changes since v3:
* Used only owl-uart for compatible string.
Changes since v2:
* No changes.
Changes since v1:
* No changes.
---
drivers/serial/serial_owl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/serial/serial_owl.c b/drivers/serial/serial_owl.c
index 7ead73e..539acdc 100644
--- a/drivers/serial/serial_owl.c
+++ b/drivers/serial/serial_owl.c
@@ -121,6 +121,7 @@ static const struct dm_serial_ops owl_serial_ops = {
static const struct udevice_id owl_serial_ids[] = {
{ .compatible = "actions,s900-serial" },
+ { .compatible = "actions,owl-uart" },
{ }
};
--
2.7.4
[PATCH v8 00/12] Actions S700 SoC support
This adds Cubieboard7[1] support based on Action Semi's S700 SoC[2], It's Quad-core ARMv8 SoC with Cortex-A53 cores. Peripheral like UART seems to be compatible with S900 SoC(basic support for it is alreay present in u-boot). This series(v8) removes the SoC specific include instead just uses owl-common. For this patch 01/12 and 09/12 changes a bit. Previous series(v7) fixes a serious Bug that breaks S900, it was there since v5.Thanks to Andre for pointing it out. Series(v6)[3] does following changes: * [PATCH v5 06/11] becomes [PATCH v6 03/11] * [PATCH v5 03/11] becomes [PATCH v6 04/11] * Introduce a new patch to move defconfig options to Kconfig which is [PATCH v6 10/12] Series(v5)[4] just re-orders the patches so that U-BOOT(with bubblegum96_defconfig) builds after every patch of the series(suggested by Andre). S700 support is tested[5] on Cubieboard7 board and S900 support is just compiled tested. This patch series can be tested using below tree: https://github.com/Atomar25/u-boot/commits/s700_v8 [1]: http://www.cubietech.com/product-detail/cubieboard7/ [2]: http://www.actions-semi.com/en/productview.aspx?id=225 [3]: http://u-boot.10912.n7.nabble.com/PATCH-v6-00-12-Actions-S700-SoC-support-td403562.html#a403567 [4]: http://u-boot.10912.n7.nabble.com/PATCH-v5-00-11-Actions-S700-SoC-support-td402752.html#a402762 [5]: https://paste.ubuntu.com/p/xGYVbSytRS/ Amit Singh Tomar (12): arm: actions: Add common framework for Actions Owl Semi SoCs arm: actions: rename sysmap-s900 to sysmap-owl serial: actions: add compatible string arm: dts: sync dts for Action Semi S900 arm: dts: actions: s900: add u-boot specific dtsi file clk: actions: Add common clock driver arm: actions: add S700 SoC device tree arm: dts: actions: s700: add u-boot specific dtsi file arm: add support Actions Semi S700 actions: Move defconfig options to Kconfig arm: add Cubieboard7 board support doc: boards: add Cubieboard7 documentation MAINTAINERS| 2 + arch/arm/Kconfig | 5 +- arch/arm/dts/Makefile | 6 +- arch/arm/dts/s700-cubieboard7.dts | 92 +++ arch/arm/dts/s700-u-boot.dtsi | 18 ++ arch/arm/dts/s700.dtsi | 248 +++ arch/arm/dts/s900-u-boot.dtsi | 17 ++ arch/arm/dts/s900.dtsi | 322 +++-- arch/arm/include/asm/arch-owl/clk_s900.h | 57 - arch/arm/include/asm/arch-owl/regs_s700.h | 56 + arch/arm/mach-owl/Kconfig | 50 ++-- arch/arm/mach-owl/Makefile | 3 +- arch/arm/mach-owl/soc.c| 57 + arch/arm/mach-owl/sysmap-owl.c | 32 +++ arch/arm/mach-owl/sysmap-s900.c| 32 --- board/ucRobotics/bubblegum_96/Kconfig | 15 -- board/ucRobotics/bubblegum_96/MAINTAINERS | 6 - board/ucRobotics/bubblegum_96/Makefile | 3 - board/ucRobotics/bubblegum_96/bubblegum_96.c | 57 - configs/bubblegum_96_defconfig | 12 +- configs/cubieboard7_defconfig | 9 + doc/board/actions/cubieboard7.rst | 115 + doc/board/actions/index.rst| 10 + doc/board/index.rst| 1 + drivers/clk/owl/Kconfig| 8 +- drivers/clk/owl/Makefile | 2 +- drivers/clk/owl/clk_owl.c | 153 drivers/clk/owl/clk_owl.h | 65 + drivers/clk/owl/clk_s900.c | 137 --- drivers/serial/serial_owl.c| 2 +- include/configs/bubblegum_96.h | 40 --- include/configs/owl-common.h | 40 +++ include/configs/s700.h | 13 + include/configs/s900.h | 16 ++ include/dt-bindings/clock/actions,s700-cmu.h | 118 + include/dt-bindings/clock/actions,s900-cmu.h | 129 ++ include/dt-bindings/clock/s900_cmu.h | 77 -- include/dt-bindings/reset/actions,s700-reset.h | 34 +++ include/dt-bindings/reset/actions,s900-reset.h | 65 + 39 files changed, 1638 insertions(+), 486 deletions(-) create mode 100644 arch/arm/dts/s700-cubieboard7.dts create mode 100644 arch/arm/dts/s700-u-boot.dtsi create mode 100644 arch/arm/dts/s700.dtsi create mode 100644 arch/arm/dts/s900-u-boot.dtsi delete mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h create mode 100644 arch/arm/include/asm/arch-owl/regs_s700.h create mode 100644 arch/arm/mach-owl/soc.c create mode 100644 arch/arm/mach-owl/sysmap-owl.c delete mode 100644 arch/arm/mach-owl/sysmap-s900.c delete mode 100644 board/ucRobotics/bubblegum_96/Kconfig delete mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS delete mode 100644
[PATCH v8 05/12] arm: dts: actions: s900: add u-boot specific dtsi file
Devices like uart and clk are needed to be enabled before relocation.
This patch adds u-boot.dtsi file that mark these device as dm-pre-reloc.
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Amit Singh Tomar
---
Changes since v7:
* No changes.
Changes since v6:
* No changes.
Changes since v5:
* No changes.
Changes since v4:
* This patch is re-ordered, moved from 08/11 to 04/11.
Changes since v3:
* Replaced dtsi with dts in subject line along with arm:dts:
to the prefix.
* Added reviewed-by tag.
Changes since v2:
* Newly added patch, not there in v2/v1.
---
arch/arm/dts/s900-u-boot.dtsi | 17 +
1 file changed, 17 insertions(+)
create mode 100644 arch/arm/dts/s900-u-boot.dtsi
diff --git a/arch/arm/dts/s900-u-boot.dtsi b/arch/arm/dts/s900-u-boot.dtsi
new file mode 100644
index 000..a95f2cc
--- /dev/null
+++ b/arch/arm/dts/s900-u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ */
+
+/{
+ soc {
+ u-boot,dm-pre-reloc;
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
--
2.7.4
[PATCH V2 13/13] net: smc911x: Add DM support
Add support for U-Boot DM and DT probing. Furthermore, build the
SMC911x standalone EEPROM example only for the non-DM case, as it
is not converted yet.
Signed-off-by: Marek Vasut
Cc: Joe Hershberger
Cc: Masahiro Yamada
---
V2: Drop the board-specific bits
Hide SMC911X_BASE from Kconfig if DM_ETH
---
drivers/net/Kconfig | 2 +
drivers/net/smc911x.c| 114 +++
examples/standalone/Makefile | 5 +-
3 files changed, 120 insertions(+), 1 deletion(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 4d1013c984..095395813a 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -388,11 +388,13 @@ config SMC911X
if SMC911X
+if !DM_ETH
config SMC911X_BASE
hex "SMC911X Base Address"
help
Define this to hold the physical address
of the device (I/O space)
+endif #DM_ETH
choice
prompt "SMC911X bus width"
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index c5bc3a67d7..ff1f5b3b61 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -21,7 +21,9 @@ struct chip_id {
};
struct smc911x_priv {
+#ifndef CONFIG_DM_ETH
struct eth_device dev;
+#endif
phys_addr_t iobase;
const struct chip_id*chipid;
unsigned char enetaddr[6];
@@ -370,6 +372,8 @@ static int smc911x_recv_common(struct smc911x_priv *priv,
u32 *data)
return pktlen;
}
+#ifndef CONFIG_DM_ETH
+
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
/* wrapper for smc911x_eth_phy_read */
static int smc911x_miiphy_read(struct mii_dev *bus, int phy, int devad,
@@ -516,3 +520,113 @@ err_detect:
free(priv);
return ret;
}
+
+#else /* ifdef CONFIG_DM_ETH */
+
+static int smc911x_start(struct udevice *dev)
+{
+ struct eth_pdata *plat = dev_get_platdata(dev);
+ struct smc911x_priv *priv = dev_get_priv(dev);
+
+ memcpy(priv->enetaddr, plat->enetaddr, sizeof(plat->enetaddr));
+
+ return smc911x_init_common(priv);
+}
+
+static void smc911x_stop(struct udevice *dev)
+{
+ struct smc911x_priv *priv = dev_get_priv(dev);
+
+ smc911x_halt_common(priv);
+}
+
+static int smc911x_send(struct udevice *dev, void *packet, int length)
+{
+ struct smc911x_priv *priv = dev_get_priv(dev);
+ int ret;
+
+ ret = smc911x_send_common(priv, packet, length);
+
+ return ret ? 0 : -ETIMEDOUT;
+}
+
+static int smc911x_recv(struct udevice *dev, int flags, uchar **packetp)
+{
+ struct smc911x_priv *priv = dev_get_priv(dev);
+ u32 *data = (u32 *)net_rx_packets[0];
+ int ret;
+
+ ret = smc911x_recv_common(priv, data);
+ if (ret)
+ *packetp = (void *)data;
+
+ return ret ? ret : -EAGAIN;
+}
+
+static int smc911x_bind(struct udevice *dev)
+{
+ return device_set_name(dev, dev->name);
+}
+
+static int smc911x_probe(struct udevice *dev)
+{
+ struct smc911x_priv *priv = dev_get_priv(dev);
+ unsigned long addrh, addrl;
+ int ret;
+
+ /* Try to detect chip. Will fail if not present. */
+ ret = smc911x_detect_chip(priv);
+ if (ret)
+ return ret;
+
+ addrh = smc911x_get_mac_csr(priv, ADDRH);
+ addrl = smc911x_get_mac_csr(priv, ADDRL);
+ if (!(addrl == 0x && addrh == 0x)) {
+ /* address is obtained from optional eeprom */
+ priv->enetaddr[0] = addrl;
+ priv->enetaddr[1] = addrl >> 8;
+ priv->enetaddr[2] = addrl >> 16;
+ priv->enetaddr[3] = addrl >> 24;
+ priv->enetaddr[4] = addrh;
+ priv->enetaddr[5] = addrh >> 8;
+ }
+
+ return 0;
+}
+
+static int smc911x_ofdata_to_platdata(struct udevice *dev)
+{
+ struct smc911x_priv *priv = dev_get_priv(dev);
+ struct eth_pdata *pdata = dev_get_platdata(dev);
+
+ pdata->iobase = devfdt_get_addr(dev);
+ priv->iobase = pdata->iobase;
+
+ return 0;
+}
+
+static const struct eth_ops smc911x_ops = {
+ .start = smc911x_start,
+ .send = smc911x_send,
+ .recv = smc911x_recv,
+ .stop = smc911x_stop,
+};
+
+static const struct udevice_id smc911x_ids[] = {
+ { .compatible = "smsc,lan9115" },
+ { }
+};
+
+U_BOOT_DRIVER(smc911x) = {
+ .name = "eth_smc911x",
+ .id = UCLASS_ETH,
+ .of_match = smc911x_ids,
+ .bind = smc911x_bind,
+ .ofdata_to_platdata = smc911x_ofdata_to_platdata,
+ .probe = smc911x_probe,
+ .ops= _ops,
+ .priv_auto_alloc_size = sizeof(struct smc911x_priv),
+ .platdata_auto_alloc_size = sizeof(struct eth_pdata),
+ .flags = DM_FLAG_ALLOC_PRIV_DMA,
+};
+#endif
diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile
index 0b17a91804..6b061bac69 100644
--- a/examples/standalone/Makefile
+++
[PATCH V2 11/13] net: smc911x: Clean up the status handling in smc911x_recv()
Invert the status handling logic in smc911x_recv(), to make the
function easier to read, no functional change.
Signed-off-by: Marek Vasut
Cc: Joe Hershberger
Cc: Masahiro Yamada
---
V2: Simplify RX_FIFO_INF_RXSUSED mask handling
s@Invest@Invert@
---
drivers/net/smc911x.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index e93011f2db..00b152d07f 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -352,23 +352,25 @@ static int smc911x_recv(struct eth_device *dev)
u32 pktlen, tmplen;
u32 status;
- if ((smc911x_reg_read(priv, RX_FIFO_INF) & RX_FIFO_INF_RXSUSED) >> 16) {
- status = smc911x_reg_read(priv, RX_STATUS_FIFO);
- pktlen = (status & RX_STS_PKT_LEN) >> 16;
+ status = smc911x_reg_read(priv, RX_FIFO_INF);
+ if (!(status & RX_FIFO_INF_RXSUSED))
+ return 0;
- smc911x_reg_write(priv, RX_CFG, 0);
+ status = smc911x_reg_read(priv, RX_STATUS_FIFO);
+ pktlen = (status & RX_STS_PKT_LEN) >> 16;
- tmplen = (pktlen + 3) / 4;
- while (tmplen--)
- *data++ = smc911x_reg_read(priv, RX_DATA_FIFO);
+ smc911x_reg_write(priv, RX_CFG, 0);
- if (status & RX_STS_ES)
- printf(DRIVERNAME
- ": dropped bad packet. Status: 0x%08x\n",
- status);
- else
- net_process_received_packet(net_rx_packets[0], pktlen);
- }
+ tmplen = (pktlen + 3) / 4;
+ while (tmplen--)
+ *data++ = smc911x_reg_read(priv, RX_DATA_FIFO);
+
+ if (status & RX_STS_ES)
+ printf(DRIVERNAME
+ ": dropped bad packet. Status: 0x%08x\n",
+ status);
+ else
+ net_process_received_packet(net_rx_packets[0], pktlen);
return 0;
}
--
2.25.1
[PATCH V2 12/13] net: smc911x: Split non-DM specific bits from common code
Split network handling functions into non-DM specific parts and
common code in preparation for conversion to DM.
Signed-off-by: Marek Vasut
Cc: Joe Hershberger
Cc: Masahiro Yamada
Acked-by: Joe Hershberger
---
V2: Add AB from Joe
---
drivers/net/smc911x.c | 57 ---
1 file changed, 43 insertions(+), 14 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 00b152d07f..c5bc3a67d7 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -277,9 +277,8 @@ static void smc911x_enable(struct smc911x_priv *priv)
MAC_CR_HBDIS);
}
-static int smc911x_init(struct eth_device *dev, bd_t * bd)
+static int smc911x_init_common(struct smc911x_priv *priv)
{
- struct smc911x_priv *priv = container_of(dev, struct smc911x_priv, dev);
const struct chip_id *id = priv->chipid;
printf(DRIVERNAME ": detected %s controller\n", id->name);
@@ -297,9 +296,9 @@ static int smc911x_init(struct eth_device *dev, bd_t * bd)
return 0;
}
-static int smc911x_send(struct eth_device *dev, void *packet, int length)
+static int smc911x_send_common(struct smc911x_priv *priv,
+ void *packet, int length)
{
- struct smc911x_priv *priv = container_of(dev, struct smc911x_priv, dev);
u32 *data = (u32*)packet;
u32 tmplen;
u32 status;
@@ -337,18 +336,14 @@ static int smc911x_send(struct eth_device *dev, void
*packet, int length)
return -1;
}
-static void smc911x_halt(struct eth_device *dev)
+static void smc911x_halt_common(struct smc911x_priv *priv)
{
- struct smc911x_priv *priv = container_of(dev, struct smc911x_priv, dev);
-
smc911x_reset(priv);
smc911x_handle_mac_address(priv);
}
-static int smc911x_recv(struct eth_device *dev)
+static int smc911x_recv_common(struct smc911x_priv *priv, u32 *data)
{
- struct smc911x_priv *priv = container_of(dev, struct smc911x_priv, dev);
- u32 *data = (u32 *)net_rx_packets[0];
u32 pktlen, tmplen;
u32 status;
@@ -365,14 +360,14 @@ static int smc911x_recv(struct eth_device *dev)
while (tmplen--)
*data++ = smc911x_reg_read(priv, RX_DATA_FIFO);
- if (status & RX_STS_ES)
+ if (status & RX_STS_ES) {
printf(DRIVERNAME
": dropped bad packet. Status: 0x%08x\n",
status);
- else
- net_process_received_packet(net_rx_packets[0], pktlen);
+ return 0;
+ }
- return 0;
+ return pktlen;
}
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
@@ -435,6 +430,40 @@ static int smc911x_initialize_mii(struct smc911x_priv
*priv)
}
#endif
+static int smc911x_init(struct eth_device *dev, bd_t *bd)
+{
+ struct smc911x_priv *priv = container_of(dev, struct smc911x_priv, dev);
+
+ return smc911x_init_common(priv);
+}
+
+static void smc911x_halt(struct eth_device *dev)
+{
+ struct smc911x_priv *priv = container_of(dev, struct smc911x_priv, dev);
+
+ smc911x_halt_common(priv);
+}
+
+static int smc911x_send(struct eth_device *dev, void *packet, int length)
+{
+ struct smc911x_priv *priv = container_of(dev, struct smc911x_priv, dev);
+
+ return smc911x_send_common(priv, packet, length);
+}
+
+static int smc911x_recv(struct eth_device *dev)
+{
+ struct smc911x_priv *priv = container_of(dev, struct smc911x_priv, dev);
+ u32 *data = (u32 *)net_rx_packets[0];
+ int ret;
+
+ ret = smc911x_recv_common(priv, data);
+ if (ret)
+ net_process_received_packet(net_rx_packets[0], ret);
+
+ return ret;
+}
+
int smc911x_initialize(u8 dev_num, int base_addr)
{
unsigned long addrl, addrh;
--
2.25.1
[PATCH V2 10/13] net: smc911x: Pass around driver private data
Introduce a private data structure for this driver with embedded
struct eth_device and pass it around. This prepares the driver to
work with both DM and non-DM systems.
Signed-off-by: Marek Vasut
Cc: Joe Hershberger
Cc: Masahiro Yamada
---
V2: No change
---
drivers/net/smc911x.c | 230 ++
1 file changed, 123 insertions(+), 107 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index d672f02782..e93011f2db 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -20,6 +20,13 @@ struct chip_id {
char *name;
};
+struct smc911x_priv {
+ struct eth_device dev;
+ phys_addr_t iobase;
+ const struct chip_id*chipid;
+ unsigned char enetaddr[6];
+};
+
static const struct chip_id chip_ids[] = {
{ CHIP_89218, "LAN89218" },
{ CHIP_9115, "LAN9115" },
@@ -45,57 +52,57 @@ static const struct chip_id chip_ids[] = {
#endif
#if defined (CONFIG_SMC911X_32_BIT)
-static u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
+static u32 smc911x_reg_read(struct smc911x_priv *priv, u32 offset)
{
- return readl(dev->iobase + offset);
+ return readl(priv->iobase + offset);
}
-static void smc911x_reg_write(struct eth_device *dev, u32 offset, u32 val)
+static void smc911x_reg_write(struct smc911x_priv *priv, u32 offset, u32 val)
{
- writel(val, dev->iobase + offset);
+ writel(val, priv->iobase + offset);
}
#elif defined (CONFIG_SMC911X_16_BIT)
-static u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
+static u32 smc911x_reg_read(struct smc911x_priv *priv, u32 offset)
{
- return (readw(dev->iobase + offset) & 0x) |
- (readw(dev->iobase + offset + 2) << 16);
+ return (readw(priv->iobase + offset) & 0x) |
+ (readw(priv->iobase + offset + 2) << 16);
}
-static void smc911x_reg_write(struct eth_device *dev, u32 offset, u32 val)
+static void smc911x_reg_write(struct smc911x_priv *priv, u32 offset, u32 val)
{
- writew(val & 0x, dev->iobase + offset);
- writew(val >> 16, dev->iobase + offset + 2);
+ writew(val & 0x, priv->iobase + offset);
+ writew(val >> 16, priv->iobase + offset + 2);
}
#else
#error "SMC911X: undefined bus width"
#endif /* CONFIG_SMC911X_16_BIT */
-static u32 smc911x_get_mac_csr(struct eth_device *dev, u8 reg)
+static u32 smc911x_get_mac_csr(struct smc911x_priv *priv, u8 reg)
{
- while (smc911x_reg_read(dev, MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
+ while (smc911x_reg_read(priv, MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
;
- smc911x_reg_write(dev, MAC_CSR_CMD,
+ smc911x_reg_write(priv, MAC_CSR_CMD,
MAC_CSR_CMD_CSR_BUSY | MAC_CSR_CMD_R_NOT_W | reg);
- while (smc911x_reg_read(dev, MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
+ while (smc911x_reg_read(priv, MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
;
- return smc911x_reg_read(dev, MAC_CSR_DATA);
+ return smc911x_reg_read(priv, MAC_CSR_DATA);
}
-static void smc911x_set_mac_csr(struct eth_device *dev, u8 reg, u32 data)
+static void smc911x_set_mac_csr(struct smc911x_priv *priv, u8 reg, u32 data)
{
- while (smc911x_reg_read(dev, MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
+ while (smc911x_reg_read(priv, MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
;
- smc911x_reg_write(dev, MAC_CSR_DATA, data);
- smc911x_reg_write(dev, MAC_CSR_CMD, MAC_CSR_CMD_CSR_BUSY | reg);
- while (smc911x_reg_read(dev, MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
+ smc911x_reg_write(priv, MAC_CSR_DATA, data);
+ smc911x_reg_write(priv, MAC_CSR_CMD, MAC_CSR_CMD_CSR_BUSY | reg);
+ while (smc911x_reg_read(priv, MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
;
}
-static int smc911x_detect_chip(struct eth_device *dev)
+static int smc911x_detect_chip(struct smc911x_priv *priv)
{
unsigned long val, i;
- val = smc911x_reg_read(dev, BYTE_TEST);
+ val = smc911x_reg_read(priv, BYTE_TEST);
if (val == 0x) {
/* Special case -- no chip present */
return -1;
@@ -104,7 +111,7 @@ static int smc911x_detect_chip(struct eth_device *dev)
return -1;
}
- val = smc911x_reg_read(dev, ID_REV) >> 16;
+ val = smc911x_reg_read(priv, ID_REV) >> 16;
for (i = 0; chip_ids[i].id != 0; i++) {
if (chip_ids[i].id == val) break;
}
@@ -113,12 +120,12 @@ static int smc911x_detect_chip(struct eth_device *dev)
return -1;
}
- dev->priv = (void *)_ids[i];
+ priv->chipid = _ids[i];
return 0;
}
-static void smc911x_reset(struct eth_device *dev)
+static void smc911x_reset(struct smc911x_priv *priv)
{
int timeout;
@@ -126,14 +133,14 @@ static void smc911x_reset(struct eth_device *dev)
* Take out of PM setting first
[PATCH V2 09/13] net: smc911x: Convert IO accessors to {read, write}{w, l}()
Convert the IO accessors to standard ones instead of using volatile
void pointers, as those do not cover all the bus access details.
Signed-off-by: Marek Vasut
Cc: Joe Hershberger
Cc: Masahiro Yamada
---
V2: No change
---
drivers/net/smc911x.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 10970b1499..d672f02782 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include "smc911x.h"
@@ -46,23 +47,23 @@ static const struct chip_id chip_ids[] = {
#if defined (CONFIG_SMC911X_32_BIT)
static u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
{
- return *(volatile u32*)(dev->iobase + offset);
+ return readl(dev->iobase + offset);
}
static void smc911x_reg_write(struct eth_device *dev, u32 offset, u32 val)
{
- *(volatile u32*)(dev->iobase + offset) = val;
+ writel(val, dev->iobase + offset);
}
#elif defined (CONFIG_SMC911X_16_BIT)
static u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
{
- volatile u16 *addr_16 = (u16 *)(dev->iobase + offset);
- return ((*addr_16 & 0x) | (*(addr_16 + 1) << 16));
+ return (readw(dev->iobase + offset) & 0x) |
+ (readw(dev->iobase + offset + 2) << 16);
}
static void smc911x_reg_write(struct eth_device *dev, u32 offset, u32 val)
{
- *(volatile u16 *)(dev->iobase + offset) = (u16)val;
- *(volatile u16 *)(dev->iobase + offset + 2) = (u16)(val >> 16);
+ writew(val & 0x, dev->iobase + offset);
+ writew(val >> 16, dev->iobase + offset + 2);
}
#else
#error "SMC911X: undefined bus width"
--
2.25.1
[PATCH V2 07/13] net: smc911x: Inline all functions from header file
Inline all the functions from the header file, as they are not used
outside of the driver or the standalone EEPROM example.
Note that this does introduce considerable amount of duplication in
the standalone EEPROM example, however that one has to be rewritten
anyway, roughly such that the SMC911x driver would expose DM EEPROM
interface and the standalone example would use that.
Signed-off-by: Marek Vasut
Cc: Joe Hershberger
Cc: Masahiro Yamada
---
V2: No change
---
drivers/net/smc911x.c| 157 ++-
drivers/net/smc911x.h| 157 ---
examples/standalone/smc911x_eeprom.c | 156 ++
3 files changed, 312 insertions(+), 158 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index ee16eae203..583afa6347 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -10,9 +10,165 @@
#include
#include
#include
+#include
#include "smc911x.h"
+struct chip_id {
+ u16 id;
+ char *name;
+};
+
+static const struct chip_id chip_ids[] = {
+ { CHIP_89218, "LAN89218" },
+ { CHIP_9115, "LAN9115" },
+ { CHIP_9116, "LAN9116" },
+ { CHIP_9117, "LAN9117" },
+ { CHIP_9118, "LAN9118" },
+ { CHIP_9211, "LAN9211" },
+ { CHIP_9215, "LAN9215" },
+ { CHIP_9216, "LAN9216" },
+ { CHIP_9217, "LAN9217" },
+ { CHIP_9218, "LAN9218" },
+ { CHIP_9220, "LAN9220" },
+ { CHIP_9221, "LAN9221" },
+ { 0, NULL },
+};
+
+#define DRIVERNAME "smc911x"
+
+#if defined (CONFIG_SMC911X_32_BIT) && \
+ defined (CONFIG_SMC911X_16_BIT)
+#error "SMC911X: Only one of CONFIG_SMC911X_32_BIT and \
+ CONFIG_SMC911X_16_BIT shall be set"
+#endif
+
+#if defined (CONFIG_SMC911X_32_BIT)
+static inline u32 __smc911x_reg_read(struct eth_device *dev, u32 offset)
+{
+ return *(volatile u32*)(dev->iobase + offset);
+}
+u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
+ __attribute__((weak, alias("__smc911x_reg_read")));
+
+static inline void __smc911x_reg_write(struct eth_device *dev,
+ u32 offset, u32 val)
+{
+ *(volatile u32*)(dev->iobase + offset) = val;
+}
+void smc911x_reg_write(struct eth_device *dev, u32 offset, u32 val)
+ __attribute__((weak, alias("__smc911x_reg_write")));
+#elif defined (CONFIG_SMC911X_16_BIT)
+static inline u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
+{
+ volatile u16 *addr_16 = (u16 *)(dev->iobase + offset);
+ return ((*addr_16 & 0x) | (*(addr_16 + 1) << 16));
+}
+static inline void smc911x_reg_write(struct eth_device *dev,
+ u32 offset, u32 val)
+{
+ *(volatile u16 *)(dev->iobase + offset) = (u16)val;
+ *(volatile u16 *)(dev->iobase + offset + 2) = (u16)(val >> 16);
+}
+#else
+#error "SMC911X: undefined bus width"
+#endif /* CONFIG_SMC911X_16_BIT */
+
+static u32 smc911x_get_mac_csr(struct eth_device *dev, u8 reg)
+{
+ while (smc911x_reg_read(dev, MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
+ ;
+ smc911x_reg_write(dev, MAC_CSR_CMD,
+ MAC_CSR_CMD_CSR_BUSY | MAC_CSR_CMD_R_NOT_W | reg);
+ while (smc911x_reg_read(dev, MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
+ ;
+
+ return smc911x_reg_read(dev, MAC_CSR_DATA);
+}
+
+static void smc911x_set_mac_csr(struct eth_device *dev, u8 reg, u32 data)
+{
+ while (smc911x_reg_read(dev, MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
+ ;
+ smc911x_reg_write(dev, MAC_CSR_DATA, data);
+ smc911x_reg_write(dev, MAC_CSR_CMD, MAC_CSR_CMD_CSR_BUSY | reg);
+ while (smc911x_reg_read(dev, MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
+ ;
+}
+
+static int smc911x_detect_chip(struct eth_device *dev)
+{
+ unsigned long val, i;
+
+ val = smc911x_reg_read(dev, BYTE_TEST);
+ if (val == 0x) {
+ /* Special case -- no chip present */
+ return -1;
+ } else if (val != 0x87654321) {
+ printf(DRIVERNAME ": Invalid chip endian 0x%08lx\n", val);
+ return -1;
+ }
+
+ val = smc911x_reg_read(dev, ID_REV) >> 16;
+ for (i = 0; chip_ids[i].id != 0; i++) {
+ if (chip_ids[i].id == val) break;
+ }
+ if (!chip_ids[i].id) {
+ printf(DRIVERNAME ": Unknown chip ID %04lx\n", val);
+ return -1;
+ }
+
+ dev->priv = (void *)_ids[i];
+
+ return 0;
+}
+
+static void smc911x_reset(struct eth_device *dev)
+{
+ int timeout;
+
+ /*
+* Take out of PM setting first
+* Device is already wake up if PMT_CTRL_READY bit is set
+*/
+ if ((smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) == 0) {
+ /* Write to the bytetest will take out of powerdown */
+ smc911x_reg_write(dev, BYTE_TEST, 0x0);
+
+ timeout = 10;
+
+
[PATCH V2 06/13] net: smc911x: Pull MII registration into separate function
Pull the MII interface registration into separate function to avoid the
ifdeffery in smc911x_initialize(). Moreover, adjust the fail path such
that we use goto labels.
Signed-off-by: Marek Vasut
Cc: Joe Hershberger
Cc: Masahiro Yamada
---
V2: New patch
---
drivers/net/smc911x.c | 64 +++
1 file changed, 40 insertions(+), 24 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 4eebf51b36..ee16eae203 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -240,12 +240,39 @@ static int smc911x_miiphy_write(struct mii_dev *bus, int
phy, int devad,
return smc911x_eth_phy_write(dev, phy, reg, val);
}
+
+static int smc911x_initialize_mii(struct eth_device *dev)
+{
+ struct mii_dev *mdiodev = mdio_alloc();
+ int ret;
+
+ if (!mdiodev)
+ return -ENOMEM;
+
+ strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
+ mdiodev->read = smc911x_miiphy_read;
+ mdiodev->write = smc911x_miiphy_write;
+
+ ret = mdio_register(mdiodev);
+ if (ret < 0) {
+ mdio_free(mdiodev);
+ return ret;
+ }
+
+ return 0;
+}
+#else
+static int smc911x_initialize_mii(struct eth_device *dev)
+{
+ return 0;
+}
#endif
int smc911x_initialize(u8 dev_num, int base_addr)
{
unsigned long addrl, addrh;
struct eth_device *dev;
+ int ret;
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (!dev)
@@ -254,9 +281,10 @@ int smc911x_initialize(u8 dev_num, int base_addr)
dev->iobase = base_addr;
/* Try to detect chip. Will fail if not present. */
- if (smc911x_detect_chip(dev)) {
- free(dev);
- return 0;
+ ret = smc911x_detect_chip(dev);
+ if (ret) {
+ ret = 0;/* Card not detected is not an error */
+ goto err_detect;
}
addrh = smc911x_get_mac_csr(dev, ADDRH);
@@ -279,27 +307,15 @@ int smc911x_initialize(u8 dev_num, int base_addr)
eth_register(dev);
-#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
- int retval;
- struct mii_dev *mdiodev = mdio_alloc();
- if (!mdiodev) {
- eth_unregister(dev);
- free(dev);
- return -ENOMEM;
- }
-
- strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
- mdiodev->read = smc911x_miiphy_read;
- mdiodev->write = smc911x_miiphy_write;
-
- retval = mdio_register(mdiodev);
- if (retval < 0) {
- mdio_free(mdiodev);
- eth_unregister(dev);
- free(dev);
- return retval;
- }
-#endif
+ ret = smc911x_initialize_mii(dev);
+ if (ret)
+ goto err_mii;
return 1;
+
+err_mii:
+ eth_unregister(dev);
+err_detect:
+ free(dev);
+ return ret;
}
--
2.25.1
[PATCH V2 08/13] net: smc911x: Drop weak alias from 32bit accessors
These accessors are not overridden by any board, and even if they were,
this is something which should be handled via DM now, so remove the
weak alias option. Moreover, drop the inline keyword, as the compiler
can decide better.
Signed-off-by: Marek Vasut
Cc: Joe Hershberger
Cc: Masahiro Yamada
---
V2: s@overriden@overridden@
---
drivers/net/smc911x.c| 14 --
examples/standalone/smc911x_eeprom.c | 16 +---
2 files changed, 9 insertions(+), 21 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 583afa6347..10970b1499 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -44,28 +44,22 @@ static const struct chip_id chip_ids[] = {
#endif
#if defined (CONFIG_SMC911X_32_BIT)
-static inline u32 __smc911x_reg_read(struct eth_device *dev, u32 offset)
+static u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
{
return *(volatile u32*)(dev->iobase + offset);
}
-u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
- __attribute__((weak, alias("__smc911x_reg_read")));
-static inline void __smc911x_reg_write(struct eth_device *dev,
- u32 offset, u32 val)
+static void smc911x_reg_write(struct eth_device *dev, u32 offset, u32 val)
{
*(volatile u32*)(dev->iobase + offset) = val;
}
-void smc911x_reg_write(struct eth_device *dev, u32 offset, u32 val)
- __attribute__((weak, alias("__smc911x_reg_write")));
#elif defined (CONFIG_SMC911X_16_BIT)
-static inline u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
+static u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
{
volatile u16 *addr_16 = (u16 *)(dev->iobase + offset);
return ((*addr_16 & 0x) | (*(addr_16 + 1) << 16));
}
-static inline void smc911x_reg_write(struct eth_device *dev,
- u32 offset, u32 val)
+static void smc911x_reg_write(struct eth_device *dev, u32 offset, u32 val)
{
*(volatile u16 *)(dev->iobase + offset) = (u16)val;
*(volatile u16 *)(dev->iobase + offset + 2) = (u16)(val >> 16);
diff --git a/examples/standalone/smc911x_eeprom.c
b/examples/standalone/smc911x_eeprom.c
index 19ad9e6297..270588bcf5 100644
--- a/examples/standalone/smc911x_eeprom.c
+++ b/examples/standalone/smc911x_eeprom.c
@@ -51,28 +51,22 @@ static const struct chip_id chip_ids[] = {
};
#if defined (CONFIG_SMC911X_32_BIT)
-static inline u32 __smc911x_reg_read(struct eth_device *dev, u32 offset)
+static u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
{
return *(volatile u32*)(dev->iobase + offset);
}
-u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
- __attribute__((weak, alias("__smc911x_reg_read")));
-static inline void __smc911x_reg_write(struct eth_device *dev,
- u32 offset, u32 val)
+static void smc911x_reg_write(struct eth_device *dev, u32 offset, u32 val)
{
*(volatile u32*)(dev->iobase + offset) = val;
}
-void smc911x_reg_write(struct eth_device *dev, u32 offset, u32 val)
- __attribute__((weak, alias("__smc911x_reg_write")));
#elif defined (CONFIG_SMC911X_16_BIT)
-static inline u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
+static u32 smc911x_reg_read(struct eth_device *dev, u32 offset)
{
volatile u16 *addr_16 = (u16 *)(dev->iobase + offset);
- return ((*addr_16 & 0x) | (*(addr_16 + 1) << 16));
+ return (*addr_16 & 0x) | (*(addr_16 + 1) << 16);
}
-static inline void smc911x_reg_write(struct eth_device *dev,
- u32 offset, u32 val)
+static void smc911x_reg_write(struct eth_device *dev, u32 offset, u32 val)
{
*(volatile u16 *)(dev->iobase + offset) = (u16)val;
*(volatile u16 *)(dev->iobase + offset + 2) = (u16)(val >> 16);
--
2.25.1
[PATCH V2 03/13] net: smc911x: Rename smc911x_rx() to smc911x_recv()
Rename the function to keep the naming scheme consistent,
no functional change.
Signed-off-by: Marek Vasut
Cc: Joe Hershberger
Cc: Masahiro Yamada
---
V2: No change
---
drivers/net/smc911x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 9a2a0f4435..cbd6cb800a 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -184,7 +184,7 @@ static void smc911x_halt(struct eth_device *dev)
smc911x_handle_mac_address(dev);
}
-static int smc911x_rx(struct eth_device *dev)
+static int smc911x_recv(struct eth_device *dev)
{
u32 *data = (u32 *)net_rx_packets[0];
u32 pktlen, tmplen;
@@ -269,7 +269,7 @@ int smc911x_initialize(u8 dev_num, int base_addr)
dev->init = smc911x_init;
dev->halt = smc911x_halt;
dev->send = smc911x_send;
- dev->recv = smc911x_rx;
+ dev->recv = smc911x_recv;
sprintf(dev->name, "%s-%hu", DRIVERNAME, dev_num);
eth_register(dev);
--
2.25.1
[PATCH V2 02/13] net: smc911x: Replace malloc()+memset() with calloc()
Replace combination of malloc()+memset() with calloc() as the behavior
is exactly the same and the amount of code is reduced.
Signed-off-by: Marek Vasut
Cc: Joe Hershberger
Cc: Masahiro Yamada
---
V2: - Use kzalloc()
- Return -ENOMEM on alloc fail
---
drivers/net/smc911x.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 24b4eaeb3f..9a2a0f4435 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -242,11 +242,9 @@ int smc911x_initialize(u8 dev_num, int base_addr)
unsigned long addrl, addrh;
struct eth_device *dev;
- dev = malloc(sizeof(*dev));
- if (!dev) {
- return -1;
- }
- memset(dev, 0, sizeof(*dev));
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return -ENOMEM;
dev->iobase = base_addr;
--
2.25.1
[PATCH V2 04/13] net: smc911x: Invert the logic in smc911x_miiphy_{read, write}()
Invert the logic in the aforementioned functions to reduce indent,
no functional change.
Signed-off-by: Marek Vasut
Cc: Joe Hershberger
Cc: Masahiro Yamada
---
V2: No change
---
drivers/net/smc911x.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index cbd6cb800a..01358a3878 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -216,24 +216,29 @@ static int smc911x_recv(struct eth_device *dev)
static int smc911x_miiphy_read(struct mii_dev *bus, int phy, int devad,
int reg)
{
- u16 val = 0;
struct eth_device *dev = eth_get_dev_by_name(bus->name);
- if (dev) {
- int retval = smc911x_eth_phy_read(dev, phy, reg, );
- if (retval < 0)
- return retval;
- return val;
- }
- return -ENODEV;
+ u16 val = 0;
+ int ret;
+
+ if (!dev)
+ return -ENODEV;
+
+ ret = smc911x_eth_phy_read(dev, phy, reg, );
+ if (ret < 0)
+ return ret;
+
+ return val;
}
/* wrapper for smc911x_eth_phy_write */
static int smc911x_miiphy_write(struct mii_dev *bus, int phy, int devad,
int reg, u16 val)
{
struct eth_device *dev = eth_get_dev_by_name(bus->name);
- if (dev)
- return smc911x_eth_phy_write(dev, phy, reg, val);
- return -ENODEV;
+
+ if (!dev)
+ return -ENODEV;
+
+ return smc911x_eth_phy_write(dev, phy, reg, val);
}
#endif
--
2.25.1
[PATCH V2 00/13] net: smc911x: Convert to DM
Perform DM conversion of the SMC911x driver.
Note that the DT compatible is set only for 9115 , so this might need
to be changed.
Marek Vasut (13):
net: smc911x: Remove pkt_data_{push,pull}
net: smc911x: Replace malloc()+memset() with calloc()
net: smc911x: Rename smc911x_rx() to smc911x_recv()
net: smc911x: Invert the logic in smc911x_miiphy_{read,write}()
net: smc911x: Fix potential memleak() in init fail path
net: smc911x: Pull MII registration into separate function
net: smc911x: Inline all functions from header file
net: smc911x: Drop weak alias from 32bit accessors
net: smc911x: Convert IO accessors to {read,write}{w,l}()
net: smc911x: Pass around driver private data
net: smc911x: Clean up the status handling in smc911x_recv()
net: smc911x: Split non-DM specific bits from common code
net: smc911x: Add DM support
drivers/net/Kconfig | 2 +
drivers/net/smc911x.c| 559 +--
drivers/net/smc911x.h| 157
examples/standalone/Makefile | 5 +-
examples/standalone/smc911x_eeprom.c | 150 +++
5 files changed, 602 insertions(+), 271 deletions(-)
Cc: Joe Hershberger
Cc: Masahiro Yamada
--
2.25.1
[PATCH V2 05/13] net: smc911x: Fix potential memleak() in init fail path
Fix memleak in the init fail path, where if allocation or registration
of MDIO bus fails, then ethernet interface is not unregistered and the
private data are not freed, yet the probe function reports a failure.
Signed-off-by: Marek Vasut
Cc: Joe Hershberger
Cc: Masahiro Yamada
---
V2: No change
---
drivers/net/smc911x.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 01358a3878..4eebf51b36 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -282,15 +282,23 @@ int smc911x_initialize(u8 dev_num, int base_addr)
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
int retval;
struct mii_dev *mdiodev = mdio_alloc();
- if (!mdiodev)
+ if (!mdiodev) {
+ eth_unregister(dev);
+ free(dev);
return -ENOMEM;
+ }
+
strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
mdiodev->read = smc911x_miiphy_read;
mdiodev->write = smc911x_miiphy_write;
retval = mdio_register(mdiodev);
- if (retval < 0)
+ if (retval < 0) {
+ mdio_free(mdiodev);
+ eth_unregister(dev);
+ free(dev);
return retval;
+ }
#endif
return 1;
--
2.25.1
[PATCH V2 01/13] net: smc911x: Remove pkt_data_{push,pull}
These functions are never used and are likely a pre-DM remnant
from times long past, just remove them.
Signed-off-by: Marek Vasut
Cc: Joe Hershberger
Cc: Masahiro Yamada
---
V2: No change
---
drivers/net/smc911x.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 257b0385c2..24b4eaeb3f 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -13,11 +13,6 @@
#include "smc911x.h"
-u32 pkt_data_pull(struct eth_device *dev, u32 addr) \
- __attribute__ ((weak, alias ("smc911x_reg_read")));
-void pkt_data_push(struct eth_device *dev, u32 addr, u32 val) \
- __attribute__ ((weak, alias ("smc911x_reg_write")));
-
static void smc911x_handle_mac_address(struct eth_device *dev)
{
unsigned long addrh, addrl;
@@ -157,7 +152,7 @@ static int smc911x_send(struct eth_device *dev, void
*packet, int length)
tmplen = (length + 3) / 4;
while (tmplen--)
- pkt_data_push(dev, TX_DATA_FIFO, *data++);
+ smc911x_reg_write(dev, TX_DATA_FIFO, *data++);
/* wait for transmission */
while (!((smc911x_reg_read(dev, TX_FIFO_INF) &
@@ -203,7 +198,7 @@ static int smc911x_rx(struct eth_device *dev)
tmplen = (pktlen + 3) / 4;
while (tmplen--)
- *data++ = pkt_data_pull(dev, RX_DATA_FIFO);
+ *data++ = smc911x_reg_read(dev, RX_DATA_FIFO);
if (status & RX_STS_ES)
printf(DRIVERNAME
--
2.25.1
Re: [PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller
On 3/21/20 5:42 PM, Simon Glass wrote:
> Hi Marek,
Hi,
> On Sat, 21 Mar 2020 at 09:09, Marek Vasut wrote:
>>
>> On 3/21/20 3:12 PM, Simon Glass wrote:
>>> Hi Marek,
>>>
>>> On Wed, 11 Mar 2020 at 01:11, Marek Vasut wrote:
On 3/11/20 7:50 AM, Chunfeng Yun wrote:
[...]
> + * @u3_ctrl_p[x]: ip usb3 port x control register, only low 4bytes are
> used
> + * @u2_ctrl_p[x]: ip usb2 port x control register, only low 4bytes are
> used
> + * @u2_phy_pll: usb2 phy pll control register
> + */
> +struct mtk_ippc_regs {
> + __le32 ip_pw_ctr0;
> + __le32 ip_pw_ctr1;
> + __le32 ip_pw_ctr2;
Please define the registers with #define macros , this struct-based
approach doesn't scale.
>>>
>>> What does this mean? I much prefer the struct approach, unless the
>>> registers move around in future generations.
>>
>> This means I want to see #define MTK_XHCI_ 0xf00
>>
>> The struct based approach doesn't scale and on e.g. altera is causing us
>> a massive amount of problems now. It looked like a good idea back then,
>> but now it's a massive burden, so I don't want that to proliferate. And
>> here I would expect the registers to move around, just like everywhere else.
>
> That sounds like something that is easily avoided. For example,
> Designware doesn't seem to move things around.
>
> Perhaps MediaTek has a policy of not doing this either?
Such policies change as the hardware evolves. I got burned by this
struct-based approach more often then it was beneficial, if it ever
really was beneficial, hence I don't want to see it used.
Re: [PATCH 12/12] net: smc911x: Add DM support
On 3/17/20 7:55 AM, Masahiro Yamada wrote: > On Mon, Mar 16, 2020 at 2:01 AM Marek Vasut wrote: >> >> Add support for U-Boot DM and DT probing. Furthermore, build the >> SMC911x standalone EEPROM example only for the non-DM case, as it >> is not converted yet. >> >> Signed-off-by: Marek Vasut >> Cc: Joe Hershberger >> Cc: Masahiro Yamada >> --- >> board/renesas/blanche/blanche.c | 2 + > > > Do you need to touch this board in the same commit? > It is unclear to me why. Nope, that should be separate. > One more thing, CONFIG_SMC911X_BASE is only used for > non DM_ETH case. > > So, can you hide this config option? > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > index 4d1013c98466..dcda139156f0 100644 > --- a/drivers/net/Kconfig > +++ b/drivers/net/Kconfig > @@ -390,6 +390,7 @@ if SMC911X > > config SMC911X_BASE > hex "SMC911X Base Address" > + depends on !DM_ETH > help > Define this to hold the physical address > of the device (I/O space) > > > Lastly, mismatch between From: and Signed-off-by. > > Without "+renesas" in From, > With "+renesas" in Signed-off-by. Do you have a git config to handle that correctly with gmail ? -- Best regards, Marek Vasut
Re: [PATCH 05/12] net: smc911x: Fix potential memleak() in init fail path
On 3/17/20 7:21 AM, Masahiro Yamada wrote:
[...]
>> @@ -283,15 +283,23 @@ int smc911x_initialize(u8 dev_num, int base_addr)
>> #if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
>> int retval;
>> struct mii_dev *mdiodev = mdio_alloc();
>> - if (!mdiodev)
>> + if (!mdiodev) {
>> + eth_unregister(dev);
>> + free(dev);
>> return -ENOMEM;
>> + }
>> +
>> strncpy(mdiodev->name, dev->name, MDIO_NAME_LEN);
>> mdiodev->read = smc911x_miiphy_read;
>> mdiodev->write = smc911x_miiphy_write;
>>
>> retval = mdio_register(mdiodev);
>> - if (retval < 0)
>> + if (retval < 0) {
>> + mdio_free(mdiodev);
>> + eth_unregister(dev);
>> + free(dev);
>> return retval;
>
>
> Using "goto " is a general tip to
> simplify the failure path.
It's even better to pull the entire MII registration into a separate
function to avoid all the ifdeffery, so I'll rather do that in a
separate patch. And then it's possible to use the goto labels without it
looking ugly.
--
Best regards,
Marek Vasut
Re: [PATCH 00/12] net: smc911x: Convert to DM
On 3/17/20 7:17 AM, Masahiro Yamada wrote: > Hi Marek, Hi, > On Mon, Mar 16, 2020 at 1:59 AM Marek Vasut wrote: >> >> Perform DM conversion of the SMC911x driver. Note that as I do not have >> any hardware with this chip, I only compile-tested this conversion. But >> it seems Yamada-san has one, so please test. > > With a quick test on my board, it worked for me. > > I will leave comments to each patch, but > they are mostly nit-picking. > > Thanks for the cleanups and the conversion. I fixed most of those, thanks for testing. I also got access to the V2H blanche and there it works too, so maybe some future revision of this could be queued up for next. -- Best regards, Marek Vasut
[PATCH] ARM: rmobile: Only register ethernet on V2H Blanche if not DM_ETH
If the DM_ETH is enabled, the board-specific ethernet registeration
should be disabled, make it so.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
board/renesas/blanche/blanche.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/board/renesas/blanche/blanche.c b/board/renesas/blanche/blanche.c
index 0807967d6e..d2059b 100644
--- a/board/renesas/blanche/blanche.c
+++ b/board/renesas/blanche/blanche.c
@@ -313,6 +313,7 @@ int board_init(void)
}
/* Added for BLANCHE(R-CarV2H board) */
+#ifndef CONFIG_DM_ETH
int board_eth_init(bd_t *bis)
{
int rc = 0;
@@ -337,6 +338,7 @@ int board_eth_init(bd_t *bis)
return rc;
}
+#endif
int dram_init(void)
{
--
2.25.1
Re: [PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller
Hi Marek,
On Sat, 21 Mar 2020 at 09:09, Marek Vasut wrote:
>
> On 3/21/20 3:12 PM, Simon Glass wrote:
> > Hi Marek,
> >
> > On Wed, 11 Mar 2020 at 01:11, Marek Vasut wrote:
> >>
> >> On 3/11/20 7:50 AM, Chunfeng Yun wrote:
> >> [...]
> >>> + * @u3_ctrl_p[x]: ip usb3 port x control register, only low 4bytes are
> >>> used
> >>> + * @u2_ctrl_p[x]: ip usb2 port x control register, only low 4bytes are
> >>> used
> >>> + * @u2_phy_pll: usb2 phy pll control register
> >>> + */
> >>> +struct mtk_ippc_regs {
> >>> + __le32 ip_pw_ctr0;
> >>> + __le32 ip_pw_ctr1;
> >>> + __le32 ip_pw_ctr2;
> >>
> >> Please define the registers with #define macros , this struct-based
> >> approach doesn't scale.
> >>
> >
> > What does this mean? I much prefer the struct approach, unless the
> > registers move around in future generations.
>
> This means I want to see #define MTK_XHCI_ 0xf00
>
> The struct based approach doesn't scale and on e.g. altera is causing us
> a massive amount of problems now. It looked like a good idea back then,
> but now it's a massive burden, so I don't want that to proliferate. And
> here I would expect the registers to move around, just like everywhere else.
That sounds like something that is easily avoided. For example,
Designware doesn't seem to move things around.
Perhaps MediaTek has a policy of not doing this either?
Regards,
Simon
[PATCH 1/3] ARM: dts: rmobile: Add IIC3 node on Gen2 R8A7792 V2H
Add IIC3 node from mainline Linux DT. This will be further updated in
subsequent DT sync, however adding this node for now is sufficient and
minimal change.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
arch/arm/dts/r8a7792.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/dts/r8a7792.dtsi b/arch/arm/dts/r8a7792.dtsi
index 8e9eb4b704..6fd80e3541 100644
--- a/arch/arm/dts/r8a7792.dtsi
+++ b/arch/arm/dts/r8a7792.dtsi
@@ -444,6 +444,23 @@
status = "disabled";
};
+ iic3: i2c@e60b {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,iic-r8a7792",
+"renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
+ reg = <0 0xe60b 0 0x425>;
+ interrupts = ;
+ clocks = < CPG_MOD 926>;
+ dmas = < 0x77>, < 0x78>,
+ < 0x77>, < 0x78>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = < R8A7792_PD_ALWAYS_ON>;
+ resets = < 926>;
+ status = "disabled";
+ };
+
dmac0: dma-controller@e670 {
compatible = "renesas,dmac-r8a7792",
"renesas,rcar-dmac";
--
2.25.1
[PATCH 3/3] ARM: rmobile: Implement PMIC reset on V2H Blanche
Add code to reset the board through PMIC, by writing the required
PMIC registers in the CPU reset handler.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
board/renesas/blanche/blanche.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/board/renesas/blanche/blanche.c b/board/renesas/blanche/blanche.c
index 7232370d6f..0807967d6e 100644
--- a/board/renesas/blanche/blanche.c
+++ b/board/renesas/blanche/blanche.c
@@ -355,4 +355,23 @@ int dram_init_banksize(void)
void reset_cpu(ulong addr)
{
+ struct udevice *dev;
+ const u8 pmic_bus = 6;
+ const u8 pmic_addr = 0x58;
+ u8 data;
+ int ret;
+
+ ret = i2c_get_chip_for_busnum(pmic_bus, pmic_addr, 1, );
+ if (ret)
+ hang();
+
+ ret = dm_i2c_read(dev, 0x13, , 1);
+ if (ret)
+ hang();
+
+ data |= BIT(1);
+
+ ret = dm_i2c_write(dev, 0x13, , 1);
+ if (ret)
+ hang();
}
--
2.25.1
[PATCH 2/3] ARM: dts: rmobile: Enable IIC3 on V2H Blanche
Enable IIC3 to permit access to the PMIC.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
arch/arm/dts/r8a7792-blanche-u-boot.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/r8a7792-blanche-u-boot.dts
b/arch/arm/dts/r8a7792-blanche-u-boot.dts
index 3555663d64..30b27040f5 100644
--- a/arch/arm/dts/r8a7792-blanche-u-boot.dts
+++ b/arch/arm/dts/r8a7792-blanche-u-boot.dts
@@ -8,6 +8,10 @@
#include "r8a7792-blanche.dts"
#include "r8a7792-u-boot.dtsi"
+ {
+ status = "okay";
+};
+
{
u-boot,dm-pre-reloc;
};
--
2.25.1
[PATCH] clk: renesas: Switch to fdtdec_get_addr_size_auto_noparent() on Gen2
The fdtdec_get_addr() does not take into account values set in #address-cells and #size-cells , but assumes them to be 1 for 32bit systems and 2 for 64bit systems. This is true for most DTs, however there are exceptions. Switch to fdtdec_get_addr_size_auto_noparent(), which takes the #address/size-cells values into consideration, otherwise the reset controller node register offset is incorrectly parsed. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- drivers/clk/renesas/clk-rcar-gen2.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/clk/renesas/clk-rcar-gen2.c b/drivers/clk/renesas/clk-rcar-gen2.c index 13111b341a..bfd7620dae 100644 --- a/drivers/clk/renesas/clk-rcar-gen2.c +++ b/drivers/clk/renesas/clk-rcar-gen2.c @@ -291,7 +291,8 @@ int gen2_clk_probe(struct udevice *dev) if (ret < 0) return ret; - rst_base = fdtdec_get_addr(gd->fdt_blob, ret, "reg"); + rst_base = fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, ret, "reg", + 0, NULL, false); if (rst_base == FDT_ADDR_T_NONE) return -EINVAL; -- 2.25.1
Re: [RFC PATCH 6/9] mkimage_fit_atf.sh: produce working binaries by default
Michal Simek [2020-03-20 11:20:17]: > I think instead of fixing it on several places we should merge things > together and fix this issue there. What do you mean exactly? Checking for the deps one layer up, like this for example in sunxi? diff --git a/Makefile b/Makefile index 44776b8efcc4..1f4bff4374cf 100644 --- a/Makefile +++ b/Makefile @@ -1276,6 +1276,19 @@ ifndef CONFIG_SYS_UBOOT_START CONFIG_SYS_UBOOT_START := $(CONFIG_SYS_TEXT_BASE) endif +define check_its_dep + @if ! test -f "$(1)"; then \ + if test "$(CONFIG_BUILDBOT_BROKEN_BINARIES)" = "y"; then \ + touch "$(1)"; \ + else \ + echo "ERROR: $(2) file $(1) NOT found. If you want to build without " >&2; \ + echo "a $(2) file (creating a NON-FUNCTIONAL binary), then enable" >&2; \ + echo "config option CONFIG_BUILDBOT_BROKEN_BINARIES." >&2; \ + false; \ + fi \ + fi +endef + # Boards with more complex image requirements can provide an .its source file # or a generator script ifneq ($(CONFIG_SPL_FIT_SOURCE),"") @@ -1289,6 +1302,13 @@ endif ifeq ($(CONFIG_SPL_FIT_GENERATOR),"arch/arm/mach-rockchip/make_fit_atf.py") U_BOOT_ITS_DEPS += u-boot endif +ifeq ($(CONFIG_SPL_FIT_GENERATOR),"board/sunxi/mksunxi_fit_atf.sh") +BL31 := $(CURDIR)/bl31.bin +export BL31 +$(BL31): + $(call check_its_dep,$@,BL31) +U_BOOT_ITS_DEPS += $(BL31) +endif $(U_BOOT_ITS): $(U_BOOT_ITS_DEPS) FORCE $(srctree)/$(CONFIG_SPL_FIT_GENERATOR) \ $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > $@ diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh index 88ad71974706..1b0e5ee7a77a 100755 --- a/board/sunxi/mksunxi_fit_atf.sh +++ b/board/sunxi/mksunxi_fit_atf.sh @@ -5,14 +5,6 @@ # # usage: $0 [ [&2 - echo "Please read the section on ARM Trusted Firmware (ATF) in board/sunxi/README.sunxi64" >&2 - BL31=/dev/null -fi - if grep -q "^CONFIG_MACH_SUN50I_H6=y" .config; then BL31_ADDR=0x104000 else > Take a look at thread where we discussed it with Tom. > https://lists.denx.de/pipermail/u-boot/2019-December/393556.html Ok, but that N'th variation was merged anyway. So whats the plan? It's not clear from that discussion or I don't get it. -- ynezz
Re: [PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller
On 3/21/20 3:12 PM, Simon Glass wrote:
> Hi Marek,
>
> On Wed, 11 Mar 2020 at 01:11, Marek Vasut wrote:
>>
>> On 3/11/20 7:50 AM, Chunfeng Yun wrote:
>> [...]
>>> + * @u3_ctrl_p[x]: ip usb3 port x control register, only low 4bytes are used
>>> + * @u2_ctrl_p[x]: ip usb2 port x control register, only low 4bytes are used
>>> + * @u2_phy_pll: usb2 phy pll control register
>>> + */
>>> +struct mtk_ippc_regs {
>>> + __le32 ip_pw_ctr0;
>>> + __le32 ip_pw_ctr1;
>>> + __le32 ip_pw_ctr2;
>>
>> Please define the registers with #define macros , this struct-based
>> approach doesn't scale.
>>
>
> What does this mean? I much prefer the struct approach, unless the
> registers move around in future generations.
This means I want to see #define MTK_XHCI_ 0xf00
The struct based approach doesn't scale and on e.g. altera is causing us
a massive amount of problems now. It looked like a good idea back then,
but now it's a massive burden, so I don't want that to proliferate. And
here I would expect the registers to move around, just like everywhere else.
Re: [PATCH 2/2] patman: Add option to disable combined changelogs
Hi Sean, On Thu, 19 Mar 2020 at 23:37, Sean Anderson wrote: > > By default patman generates a combined changelog for the cover letter. This > may not always be desireable. > > Many patches may have the same changes. These can be coalesced with > "Series-process-log: uniq", but this is imperfect. First, this cannot be > used when there are multi-line changes. In addition, similar changes like We could perhaps support this if we used indentation to indicate multiple lines - line 1 of a multi-line message line 2 here - this is line 1 of a single-line message > "Move foo to patch 7" will not be merged with the similar "Move foo to this > patch from patch 6". > > Changes may not make sens outside of the patch they are written for. For sense > example, a change line of "Add check for bar" does not make sense outside > of the context in which bar might be checked for. Some changes like "New" > or "Lint" may be repeated many times throughout different change logs, but > carry no useful information in a summary. > > Lastly, I like to summarize the broad strokes of the changes I have made in > the cover letter, while documenting all the details in the appropriate > patches. I think this make it easier to get a good feel for what has > changed, without making it difficult to wade through every change in the > whole series. > > For these reasons, this patch adds an option to disable the automatic > changelog. > > Signed-off-by: Sean Anderson > --- > > tools/patman/func_test.py | 2 +- > tools/patman/patchstream.py | 7 --- > tools/patman/patman.py | 6 +- > 3 files changed, 10 insertions(+), 5 deletions(-) Thanks for the great explanations on your patches. In the case where there is no automatic change log on the cover letter, do you use 'Series-notes' instead? I'd like to enforce some sort of change log in the cover letter. I also think this would be better as a tag in a commit, like 'Series-no-change-log: yes'. That way you set it up when you create the patches, and it persists without needing to add the options each time. Regards, Simon
Re: [PATCH 1/2] patman: Add option to suppress empty changelog entries
Hi Sean, On Thu, 19 Mar 2020 at 23:37, Sean Anderson wrote: > > By default, patman outputs a line for every edition of the series in every > patch, regardless of whether any changes were made. This can result in many > redundant lines in patch changelogs, especially when a patch did not exist > before a certain revision. For example, the default behaviour could result > in a changelog of > > Changes in v6: > - Make a change > > Changes in v5: None > > Changes in v4: > - New > > Changes in v3: None > Changes in v2: None > Changes in v1: None > > With this patch applied and with --no-empty-changes, the same patch would > look like > > Changes in v6: > - Make a change > > Changes in v4: > - New > > This is entirely aesthetic, but I think it reduces clutter, especially for > patches added later on in a series. > > Signed-off-by: Sean Anderson > --- > > tools/patman/func_test.py | 2 +- > tools/patman/patchstream.py | 15 --- > tools/patman/patman.py | 7 +-- > tools/patman/series.py | 12 +++- > tools/patman/test.py| 2 +- > 5 files changed, 22 insertions(+), 16 deletions(-) I can see the value here, particularly for the 'new' case. But I actually appreciate the positive confirmation that nothing changed. Sometimes people send patches and fail to add a change log. What happens if a patch has no changes at all since v1? Do you think we should always report 'None' for the last version? Regards, Simon
[PATCH] patman: Update to use absolute imports
Use absolute imports in patman so that installing patman is easier and it
can run with its modules being in the 'patman' subdirectory.
Rename patman.py since Python does not like the Python module name being
the same as the module directory.
Add the required path to sys.path() so that running patman locally works.
Signed-off-by: Simon Glass
Reviewed-by: Mike Frysinger
---
tools/patman/checkpatch.py | 8 +---
tools/patman/command.py | 5 +++--
tools/patman/func_test.py | 8
tools/patman/get_maintainer.py | 5 +++--
tools/patman/gitutil.py | 12 ++--
tools/patman/{patman.py => main.py} | 27 ++-
tools/patman/patchstream.py | 8
tools/patman/patman | 2 +-
tools/patman/project.py | 2 +-
tools/patman/series.py | 10 +-
tools/patman/settings.py| 6 +++---
tools/patman/test.py| 10 +-
tools/patman/tools.py | 4 ++--
tools/patman/tout.py| 2 +-
14 files changed, 57 insertions(+), 52 deletions(-)
rename tools/patman/{patman.py => main.py} (93%)
diff --git a/tools/patman/checkpatch.py b/tools/patman/checkpatch.py
index d47ea438b7..795b519314 100644
--- a/tools/patman/checkpatch.py
+++ b/tools/patman/checkpatch.py
@@ -3,12 +3,14 @@
#
import collections
-import command
-import gitutil
import os
import re
import sys
-import terminal
+
+from patman import command
+from patman import gitutil
+from patman import terminal
+from patman import tools
def FindCheckPatch():
top_level = gitutil.GetTopLevel()
diff --git a/tools/patman/command.py b/tools/patman/command.py
index 5fbd2c4a3e..e67ac159e5 100644
--- a/tools/patman/command.py
+++ b/tools/patman/command.py
@@ -3,8 +3,9 @@
#
import os
-import cros_subprocess
-import tools
+
+from patman import cros_subprocess
+from patman import tools
"""Shell command ease-ups for Python."""
diff --git a/tools/patman/func_test.py b/tools/patman/func_test.py
index 76319fff37..b8dee18725 100644
--- a/tools/patman/func_test.py
+++ b/tools/patman/func_test.py
@@ -17,10 +17,10 @@ try:
except ImportError:
from io import StringIO
-import gitutil
-import patchstream
-import settings
-import tools
+from patman import gitutil
+from patman import patchstream
+from patman import settings
+from patman import tools
@contextlib.contextmanager
diff --git a/tools/patman/get_maintainer.py b/tools/patman/get_maintainer.py
index 0ffb55a821..473f0feebf 100644
--- a/tools/patman/get_maintainer.py
+++ b/tools/patman/get_maintainer.py
@@ -2,10 +2,11 @@
# Copyright (c) 2012 The Chromium OS Authors.
#
-import command
-import gitutil
import os
+from patman import command
+from patman import gitutil
+
def FindGetMaintainer():
"""Look for the get_maintainer.pl script.
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index a2a225c6b9..770a051014 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -2,17 +2,17 @@
# Copyright (c) 2011 The Chromium OS Authors.
#
-import command
import re
import os
-import series
import subprocess
import sys
-import terminal
-import checkpatch
-import settings
-import tools
+from patman import checkpatch
+from patman import command
+from patman import series
+from patman import settings
+from patman import terminal
+from patman import tools
# True to use --no-decorate - we check this in Setup()
use_no_decorate = True
diff --git a/tools/patman/patman.py b/tools/patman/main.py
similarity index 93%
rename from tools/patman/patman.py
rename to tools/patman/main.py
index cf53e532dd..8cce567c6e 100755
--- a/tools/patman/patman.py
+++ b/tools/patman/main.py
@@ -12,19 +12,20 @@ import re
import sys
import unittest
+if __name__ == "__main__":
+# Allow 'from patman import xxx to work'
+our_path = os.path.dirname(os.path.realpath(__file__))
+sys.path.append(os.path.join(our_path, '..'))
+
# Our modules
-try:
-from patman import checkpatch, command, gitutil, patchstream, \
-project, settings, terminal, test
-except ImportError:
-import checkpatch
-import command
-import gitutil
-import patchstream
-import project
-import settings
-import terminal
-import test
+from patman import checkpatch
+from patman import command
+from patman import gitutil
+from patman import patchstream
+from patman import project
+from patman import settings
+from patman import terminal
+from patman import test
parser = OptionParser()
@@ -85,7 +86,7 @@ if __name__ != "__main__":
# Run our meagre tests
elif options.test:
import doctest
-import func_test
+from patman import func_test
sys.argv = [sys.argv[0]]
result = unittest.TestResult()
diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index df3eb7483b..405297505c 100644
--- a/tools/patman/patchstream.py
+++
Re: [PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller
Hi Marek,
On Wed, 11 Mar 2020 at 01:11, Marek Vasut wrote:
>
> On 3/11/20 7:50 AM, Chunfeng Yun wrote:
> [...]
> > + * @u3_ctrl_p[x]: ip usb3 port x control register, only low 4bytes are used
> > + * @u2_ctrl_p[x]: ip usb2 port x control register, only low 4bytes are used
> > + * @u2_phy_pll: usb2 phy pll control register
> > + */
> > +struct mtk_ippc_regs {
> > + __le32 ip_pw_ctr0;
> > + __le32 ip_pw_ctr1;
> > + __le32 ip_pw_ctr2;
>
> Please define the registers with #define macros , this struct-based
> approach doesn't scale.
>
What does this mean? I much prefer the struct approach, unless the
registers move around in future generations.
Regards,
Simon
Re: [PATCH 1/1] arm: mvebu: dts: Sort Armada series dts alphabetically
On 20.03.20 20:44, luka.kova...@sartura.hr wrote: From: Josip Kelečić Sort the Armada series dts in the Makefile alphabetically prior to adding new board support. Signed-off-by: Josip Kelečić Reviewed-by: Luka Kovacic Cc: Luka Perkov Reviewed-by: Stefan Roese Thanks, Stefan
Re: [PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller
On Wed, 2020-03-11 at 08:11 +0100, Marek Vasut wrote:
> On 3/11/20 7:50 AM, Chunfeng Yun wrote:
> [...]
> > + * @u3_ctrl_p[x]: ip usb3 port x control register, only low 4bytes are used
> > + * @u2_ctrl_p[x]: ip usb2 port x control register, only low 4bytes are used
> > + * @u2_phy_pll: usb2 phy pll control register
> > + */
> > +struct mtk_ippc_regs {
> > + __le32 ip_pw_ctr0;
> > + __le32 ip_pw_ctr1;
> > + __le32 ip_pw_ctr2;
>
> Please define the registers with #define macros , this struct-based
> approach doesn't scale.
When I prepare for v2, and find that if define registers as macros, it do not
keep
the same style with the xhci core, so I leave it unchanged in v2, if you
still suggest to avoid struct-based approach, I will change it in v3
version, thanks
> [..]
>
[PATCH v2 08/10] arm: dts: mt7629: add usb related nodes
Add usb, phy and clock nodes
Signed-off-by: Chunfeng Yun
---
v2:
1. remove fixed clock clk20m
---
arch/arm/dts/mt7629-rfb.dts | 8
arch/arm/dts/mt7629.dtsi| 41 +
2 files changed, 49 insertions(+)
diff --git a/arch/arm/dts/mt7629-rfb.dts b/arch/arm/dts/mt7629-rfb.dts
index 687fe1c029..bf84f76344 100644
--- a/arch/arm/dts/mt7629-rfb.dts
+++ b/arch/arm/dts/mt7629-rfb.dts
@@ -82,6 +82,14 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/dts/mt7629.dtsi b/arch/arm/dts/mt7629.dtsi
index a33a74a556..d1c99c5d6a 100644
--- a/arch/arm/dts/mt7629.dtsi
+++ b/arch/arm/dts/mt7629.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "skeleton.dtsi"
/ {
@@ -222,6 +223,46 @@
#size-cells = <0>;
};
+ ssusbsys: ssusbsys@1a00 {
+ compatible = "mediatek,mt7629-ssusbsys", "syscon";
+ reg = <0x1a00 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ xhci: usb@1a0c {
+ compatible = "mediatek,mt7629-xhci", "mediatek,mtk-xhci";
+ reg = <0x1a0c 0x1000>, <0x1a0c3e00 0x0100>;
+ reg-names = "mac", "ippc";
+ power-domains = < MT7629_POWER_DOMAIN_HIF1>;
+ clocks = < CLK_SSUSB_SYS_EN>,
+< CLK_SSUSB_REF_EN>,
+< CLK_SSUSB_MCU_EN>,
+< CLK_SSUSB_DMA_EN>;
+ clock-names = "sys_ck", "ref_ck", "mcu_ck", "dma_ck";
+ phys = < PHY_TYPE_USB2>, < PHY_TYPE_USB3>;
+ status = "disabled";
+ };
+
+ u3phy: usb-phy@1a0c4000 {
+ compatible = "mediatek,mt7629-tphy", "mediatek,generic-tphy-v2";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x1a0c4000 0x1000>;
+ status = "disabled";
+
+ u2port0: usb-phy@0 {
+ reg = <0x0 0x0700>;
+ #phy-cells = <1>;
+ clocks = < CLK_SSUSB_U2_PHY_EN>;
+ clock-names = "ref";
+ };
+
+ u3port0: usb-phy@700 {
+ reg = <0x0700 0x0700>;
+ #phy-cells = <1>;
+ };
+ };
+
ethsys: syscon@1b00 {
compatible = "mediatek,mt7629-ethsys", "syscon";
reg = <0x1b00 0x1000>;
--
2.25.1
[PATCH v2 10/10] dt-bindings: usb: mtk-xhci: Add binding for MediaTek xHCI host controller
Add dt-binding for MediaTek xHCI host controller
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
.../usb/mediatek,mtk-xhci.txt | 40 +++
1 file changed, 40 insertions(+)
create mode 100644 doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt
diff --git a/doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt
b/doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt
new file mode 100644
index 00..0447468a2d
--- /dev/null
+++ b/doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt
@@ -0,0 +1,40 @@
+MediaTek xHCI
+
+The device node for USB3 host controller on MediaTek SoCs.
+
+Required properties:
+ - compatible : should be "mediatek,mtk-xhci"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
+ - power-domains : a phandle to USB power domain node to control USB's
+ MTCMOS
+ - vusb33-supply : regulator of USB avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain
+ "sys_ck": controller clock used by normal mode,
+ the following ones are optional:
+ "ref_ck": reference clock used by low power mode etc,
+ "mcu_ck": mcu_bus clock for register access,
+ "dma_ck": dma_bus clock for data transfer by DMA,
+ "xhci_ck": controller clock
+
+ - phys : list of all the USB PHYs on this HCD
+ - phy-names: name specifier for the USB PHY
+
+Optional properties:
+ - vbus-supply : reference to the VBUS regulator;
+
+Example:
+xhci: usb@1a0c {
+ compatible = "mediatek,mt7629-xhci", "mediatek,mtk-xhci";
+ reg = <0x1a0c 0x1000>, <0x1a0c3e00 0x0100>;
+ reg-names = "mac", "ippc";
+ power-domains = < MT7629_POWER_DOMAIN_HIF1>;
+ clocks = < CLK_SSUSB_SYS_EN>, < CLK_SSUSB_REF_EN>,
+< CLK_SSUSB_MCU_EN>, < CLK_SSUSB_DMA_EN>;
+ clock-names = "sys_ck", "ref_ck", "mcu_ck", "dma_ck";
+ phys = < PHY_TYPE_USB2>, < PHY_TYPE_USB3>;
+ status = "disabled";
+};
--
2.25.1
[PATCH v2 07/10] xhci: mediatek: Add support for MTK xHCI host controller
This patch is used to support the on-chip xHCI controller on
MediaTek SoCs, currently only control/bulk transfers are
supported.
Signed-off-by: Chunfeng Yun
---
v2:
1. use clk_bulk to get clocks suggested by Marek
2. use clrsetbits_le32() etc suggeseted by Marek
---
drivers/usb/host/Kconfig| 6 +
drivers/usb/host/Makefile | 1 +
drivers/usb/host/xhci-mtk.c | 402
3 files changed, 409 insertions(+)
create mode 100644 drivers/usb/host/xhci-mtk.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 0987ff25b1..931af268f4 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -30,6 +30,12 @@ config USB_XHCI_DWC3_OF_SIMPLE
Support USB2/3 functionality in simple SoC integrations with
USB controller based on the DesignWare USB3 IP Core.
+config USB_XHCI_MTK
+ bool "Support for MediaTek on-chip xHCI USB controller"
+ depends on ARCH_MEDIATEK
+ help
+ Enables support for the on-chip xHCI controller on MediaTek SoCs.
+
config USB_XHCI_MVEBU
bool "MVEBU USB 3.0 support"
default y
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 7feeff679c..104821f188 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_USB_XHCI_DWC3_OF_SIMPLE) += dwc3-of-simple.o
obj-$(CONFIG_USB_XHCI_ROCKCHIP) += xhci-rockchip.o
obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o
obj-$(CONFIG_USB_XHCI_FSL) += xhci-fsl.o
+obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
obj-$(CONFIG_USB_XHCI_MVEBU) += xhci-mvebu.o
obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o
obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
new file mode 100644
index 00..d59911a34e
--- /dev/null
+++ b/drivers/usb/host/xhci-mtk.c
@@ -0,0 +1,402 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 MediaTek, Inc.
+ * Authors: Chunfeng Yun
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define MU3C_U3_PORT_MAX 4
+#define MU3C_U2_PORT_MAX 5
+
+/**
+ * struct mtk_ippc_regs: MTK ssusb ip port control registers
+ * @ip_pw_ctr0~3: ip power and clock control registers
+ * @ip_pw_sts1~2: ip power and clock status registers
+ * @ip_xhci_cap: ip xHCI capability register
+ * @u3_ctrl_p[x]: ip usb3 port x control register, only low 4bytes are used
+ * @u2_ctrl_p[x]: ip usb2 port x control register, only low 4bytes are used
+ * @u2_phy_pll: usb2 phy pll control register
+ */
+struct mtk_ippc_regs {
+ __le32 ip_pw_ctr0;
+ __le32 ip_pw_ctr1;
+ __le32 ip_pw_ctr2;
+ __le32 ip_pw_ctr3;
+ __le32 ip_pw_sts1;
+ __le32 ip_pw_sts2;
+ __le32 reserved0[3];
+ __le32 ip_xhci_cap;
+ __le32 reserved1[2];
+ __le64 u3_ctrl_p[MU3C_U3_PORT_MAX];
+ __le64 u2_ctrl_p[MU3C_U2_PORT_MAX];
+ __le32 reserved2;
+ __le32 u2_phy_pll;
+ __le32 reserved3[33]; /* 0x80 ~ 0xff */
+};
+
+/* ip_pw_ctrl0 register */
+#define CTRL0_IP_SW_RSTBIT(0)
+
+/* ip_pw_ctrl1 register */
+#define CTRL1_IP_HOST_PDN BIT(0)
+
+/* ip_pw_ctrl2 register */
+#define CTRL2_IP_DEV_PDN BIT(0)
+
+/* ip_pw_sts1 register */
+#define STS1_IP_SLEEP_STS BIT(30)
+#define STS1_U3_MAC_RSTBIT(16)
+#define STS1_XHCI_RST BIT(11)
+#define STS1_SYS125_RSTBIT(10)
+#define STS1_REF_RST BIT(8)
+#define STS1_SYSPLL_STABLE BIT(0)
+
+/* ip_xhci_cap register */
+#define CAP_U3_PORT_NUM(p) ((p) & 0xff)
+#define CAP_U2_PORT_NUM(p) (((p) >> 8) & 0xff)
+
+/* u3_ctrl_p register */
+#define CTRL_U3_PORT_HOST_SEL BIT(2)
+#define CTRL_U3_PORT_PDN BIT(1)
+#define CTRL_U3_PORT_DIS BIT(0)
+
+/* u2_ctrl_p register */
+#define CTRL_U2_PORT_HOST_SEL BIT(2)
+#define CTRL_U2_PORT_PDN BIT(1)
+#define CTRL_U2_PORT_DIS BIT(0)
+
+struct mtk_xhci {
+ struct xhci_ctrl ctrl; /* Needs to come first in this struct! */
+ struct xhci_hccr *hcd;
+ struct mtk_ippc_regs *ippc;
+ struct udevice *dev;
+ struct udevice *vusb33_supply;
+ struct udevice *vbus_supply;
+ struct clk_bulk clks;
+ int num_u2_ports;
+ int num_u3_ports;
+ struct phy *phys;
+ int num_phys;
+};
+
+static int xhci_mtk_host_enable(struct mtk_xhci *mtk)
+{
+ struct mtk_ippc_regs *ippc = mtk->ippc;
+ u32 value, check_val;
+ int ret;
+ int i;
+
+ /* power on host ip */
+ clrbits_le32(>ip_pw_ctr1, CTRL1_IP_HOST_PDN);
+
+ /* power on and enable all u3 ports */
+ for (i = 0; i < mtk->num_u3_ports; i++) {
+ clrsetbits_le32(>u3_ctrl_p[i],
+ CTRL_U3_PORT_PDN
[PATCH v2 03/10] sandbox: dts: test: add a node for ofnode_get_child_count()
Add a node to test ofnode_get_child_count()
Signed-off-by: Chunfeng Yun
---
v2:
a new patch to test ofnode_get_child_count() suggested by Simon
---
arch/sandbox/dts/test.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 4a277934a7..09e69a9d33 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -202,6 +202,24 @@
compatible = "denx,u-boot-fdt-test1";
};
+ i-test {
+ compatible = "mediatek,u-boot-fdt-test";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ subnode0 {
+ reg = <0>;
+ };
+
+ subnode1 {
+ reg = <1>;
+ };
+
+ subnode2 {
+ reg = <2>;
+ };
+ };
+
devres-test {
compatible = "denx,u-boot-devres-test";
};
--
2.25.1
[PATCH v2 04/10] phy: phy-mtk-tphy: add support USB phys
Support USB2 and USB3 PHY with shared banks when support multi-phys Signed-off-by: Chunfeng Yun --- v2: 1. get the count of phys by dev_get_child_count() --- drivers/phy/phy-mtk-tphy.c | 227 +++-- 1 file changed, 218 insertions(+), 9 deletions(-) diff --git a/drivers/phy/phy-mtk-tphy.c b/drivers/phy/phy-mtk-tphy.c index bd089b7a43..71bc706c6e 100644 --- a/drivers/phy/phy-mtk-tphy.c +++ b/drivers/phy/phy-mtk-tphy.c @@ -20,11 +20,66 @@ /* version V1 sub-banks offset base address */ /* banks shared by multiple phys */ #define SSUSB_SIFSLV_V1_SPLLC 0x000 /* shared by u3 phys */ +#define SSUSB_SIFSLV_V1_U2FREQ 0x100 /* shared by u2 phys */ #define SSUSB_SIFSLV_V1_CHIP 0x300 /* shared by u3 phys */ +/* u2 phy bank */ +#define SSUSB_SIFSLV_V1_U2PHY_COM 0x000 /* u3/pcie/sata phy banks */ #define SSUSB_SIFSLV_V1_U3PHYD 0x000 #define SSUSB_SIFSLV_V1_U3PHYA 0x200 +#define U3P_USBPHYACR0 0x000 +#define PA0_RG_U2PLL_FORCE_ON BIT(15) +#define PA0_RG_USB20_INTR_EN BIT(5) + +#define U3P_USBPHYACR5 0x014 +#define PA5_RG_U2_HSTX_SRCAL_ENBIT(15) +#define PA5_RG_U2_HSTX_SRCTRL GENMASK(14, 12) +#define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12) +#define PA5_RG_U2_HS_100U_U3_ENBIT(11) + +#define U3P_USBPHYACR6 0x018 +#define PA6_RG_U2_BC11_SW_EN BIT(23) +#define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20) +#define PA6_RG_U2_SQTH GENMASK(3, 0) +#define PA6_RG_U2_SQTH_VAL(x) (0xf & (x)) + +#define U3P_U2PHYACR4 0x020 +#define P2C_RG_USB20_GPIO_CTL BIT(9) +#define P2C_USB20_GPIO_MODEBIT(8) +#define P2C_U2_GPIO_CTR_MSK\ + (P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE) + +#define U3P_U2PHYDTM0 0x068 +#define P2C_FORCE_UART_EN BIT(26) +#define P2C_FORCE_DATAIN BIT(23) +#define P2C_FORCE_DM_PULLDOWN BIT(21) +#define P2C_FORCE_DP_PULLDOWN BIT(20) +#define P2C_FORCE_XCVRSEL BIT(19) +#define P2C_FORCE_SUSPENDM BIT(18) +#define P2C_FORCE_TERMSEL BIT(17) +#define P2C_RG_DATAIN GENMASK(13, 10) +#define P2C_RG_DATAIN_VAL(x) ((0xf & (x)) << 10) +#define P2C_RG_DMPULLDOWN BIT(7) +#define P2C_RG_DPPULLDOWN BIT(6) +#define P2C_RG_XCVRSEL GENMASK(5, 4) +#define P2C_RG_XCVRSEL_VAL(x) ((0x3 & (x)) << 4) +#define P2C_RG_SUSPENDMBIT(3) +#define P2C_RG_TERMSEL BIT(2) +#define P2C_DTM0_PART_MASK \ + (P2C_FORCE_DATAIN | P2C_FORCE_DM_PULLDOWN | \ + P2C_FORCE_DP_PULLDOWN | P2C_FORCE_XCVRSEL | \ + P2C_FORCE_TERMSEL | P2C_RG_DMPULLDOWN | \ + P2C_RG_DPPULLDOWN | P2C_RG_TERMSEL) + +#define U3P_U2PHYDTM1 0x06C +#define P2C_RG_UART_EN BIT(16) +#define P2C_FORCE_IDDIGBIT(9) +#define P2C_RG_VBUSVALID BIT(5) +#define P2C_RG_SESSEND BIT(4) +#define P2C_RG_AVALID BIT(2) +#define P2C_RG_IDDIG BIT(1) + #define U3P_U3_CHIP_GPIO_CTLD 0x0c #define P3C_REG_IP_SW_RST BIT(31) #define P3C_MCU_BUS_CK_GATE_EN BIT(30) @@ -42,6 +97,14 @@ #define P3A_RG_CLKDRV_AMP GENMASK(31, 29) #define P3A_RG_CLKDRV_AMP_VAL(x) ((0x7 & (x)) << 29) +#define U3P_U3_PHYA_REG6 0x018 +#define P3A_RG_TX_EIDLE_CM GENMASK(31, 28) +#define P3A_RG_TX_EIDLE_CM_VAL(x) ((0xf & (x)) << 28) + +#define U3P_U3_PHYA_REG9 0x024 +#define P3A_RG_RX_DAC_MUX GENMASK(5, 1) +#define P3A_RG_RX_DAC_MUX_VAL(x) ((0x1f & (x)) << 1) + #define U3P_U3_PHYA_DA_REG00x100 #define P3A_RG_XTAL_EXT_PE2H GENMASK(17, 16) #define P3A_RG_XTAL_EXT_PE2H_VAL(x)((0x3 & (x)) << 16) @@ -77,6 +140,16 @@ #define P3A_RG_PLL_DELTA_PE2H GENMASK(15, 0) #define P3A_RG_PLL_DELTA_PE2H_VAL(x) (0x & (x)) +#define U3P_U3_PHYD_LFPS1 0x00c +#define P3D_RG_FWAKE_THGENMASK(21, 16) +#define P3D_RG_FWAKE_TH_VAL(x) ((0x3f & (x)) << 16) + +#define U3P_U3_PHYD_CDR1 0x05c +#define P3D_RG_CDR_BIR_LTD1GENMASK(28, 24) +#define P3D_RG_CDR_BIR_LTD1_VAL(x) ((0x1f & (x)) << 24) +#define P3D_RG_CDR_BIR_LTD0GENMASK(12, 8) +#define P3D_RG_CDR_BIR_LTD0_VAL(x) ((0x1f & (x)) << 8) + #define U3P_U3_PHYD_RXDET1 0x128 #define P3D_RG_RXDET_STB2_SET GENMASK(17, 9) #define P3D_RG_RXDET_STB2_SET_VAL(x) ((0x1ff & (x)) << 9) @@ -85,6 +158,16 @@ #define P3D_RG_RXDET_STB2_SET_P3 GENMASK(8, 0) #define P3D_RG_RXDET_STB2_SET_P3_VAL(x)(0x1ff & (x)) +#define U3P_SPLLC_XTALCTL3 0x018 +#define
[PATCH v2 05/10] phy: phy-mtk-tphy: add support new version
The new version removes all shared banks between multi-phys
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/phy/phy-mtk-tphy.c | 68 +++---
1 file changed, 63 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/phy-mtk-tphy.c b/drivers/phy/phy-mtk-tphy.c
index 71bc706c6e..20167fe7cb 100644
--- a/drivers/phy/phy-mtk-tphy.c
+++ b/drivers/phy/phy-mtk-tphy.c
@@ -28,6 +28,17 @@
#define SSUSB_SIFSLV_V1_U3PHYD 0x000
#define SSUSB_SIFSLV_V1_U3PHYA 0x200
+/* version V2 sub-banks offset base address */
+/* u2 phy banks */
+#define SSUSB_SIFSLV_V2_MISC 0x000
+#define SSUSB_SIFSLV_V2_U2FREQ 0x100
+#define SSUSB_SIFSLV_V2_U2PHY_COM 0x300
+/* u3/pcie/sata phy banks */
+#define SSUSB_SIFSLV_V2_SPLLC 0x000
+#define SSUSB_SIFSLV_V2_CHIP 0x100
+#define SSUSB_SIFSLV_V2_U3PHYD 0x200
+#define SSUSB_SIFSLV_V2_U3PHYA 0x400
+
#define U3P_USBPHYACR0 0x000
#define PA0_RG_U2PLL_FORCE_ON BIT(15)
#define PA0_RG_USB20_INTR_EN BIT(5)
@@ -162,6 +173,11 @@
#define XC3_RG_U3_XTAL_RX_PWD BIT(9)
#define XC3_RG_U3_FRC_XTAL_RX_PWD BIT(8)
+enum mtk_phy_version {
+ MTK_TPHY_V1 = 1,
+ MTK_TPHY_V2,
+};
+
struct u2phy_banks {
void __iomem *misc;
void __iomem *fmreg;
@@ -192,6 +208,7 @@ struct mtk_phy_instance {
struct mtk_tphy {
struct udevice *dev;
void __iomem *sif_base;
+ enum mtk_phy_version version;
struct mtk_phy_instance **phys;
int nphys;
};
@@ -304,6 +321,9 @@ static void pcie_phy_instance_init(struct mtk_tphy *tphy,
{
struct u3phy_banks *u3_banks = >u3_banks;
+ if (tphy->version != MTK_TPHY_V1)
+ return;
+
clrsetbits_le32(u3_banks->phya + U3P_U3_PHYA_DA_REG0,
P3A_RG_XTAL_EXT_PE1H | P3A_RG_XTAL_EXT_PE2H,
P3A_RG_XTAL_EXT_PE1H_VAL(0x2) |
@@ -398,6 +418,31 @@ static void phy_v1_banks_init(struct mtk_tphy *tphy,
}
}
+static void phy_v2_banks_init(struct mtk_tphy *tphy,
+ struct mtk_phy_instance *instance)
+{
+ struct u2phy_banks *u2_banks = >u2_banks;
+ struct u3phy_banks *u3_banks = >u3_banks;
+
+ switch (instance->type) {
+ case PHY_TYPE_USB2:
+ u2_banks->misc = instance->port_base + SSUSB_SIFSLV_V2_MISC;
+ u2_banks->fmreg = instance->port_base + SSUSB_SIFSLV_V2_U2FREQ;
+ u2_banks->com = instance->port_base + SSUSB_SIFSLV_V2_U2PHY_COM;
+ break;
+ case PHY_TYPE_USB3:
+ case PHY_TYPE_PCIE:
+ u3_banks->spllc = instance->port_base + SSUSB_SIFSLV_V2_SPLLC;
+ u3_banks->chip = instance->port_base + SSUSB_SIFSLV_V2_CHIP;
+ u3_banks->phyd = instance->port_base + SSUSB_SIFSLV_V2_U3PHYD;
+ u3_banks->phya = instance->port_base + SSUSB_SIFSLV_V2_U3PHYA;
+ break;
+ default:
+ dev_err(tphy->dev, "incompatible PHY type\n");
+ return;
+ }
+}
+
static int mtk_phy_init(struct phy *phy)
{
struct mtk_tphy *tphy = dev_get_priv(phy->dev);
@@ -500,7 +545,14 @@ static int mtk_phy_xlate(struct phy *phy,
return -EINVAL;
}
- phy_v1_banks_init(tphy, instance);
+ if (tphy->version == MTK_TPHY_V1) {
+ phy_v1_banks_init(tphy, instance);
+ } else if (tphy->version == MTK_TPHY_V2) {
+ phy_v2_banks_init(tphy, instance);
+ } else {
+ dev_err(phy->dev, "phy version is not supported\n");
+ return -EINVAL;
+ }
return 0;
}
@@ -527,9 +579,14 @@ static int mtk_tphy_probe(struct udevice *dev)
return -ENOMEM;
tphy->dev = dev;
- tphy->sif_base = dev_read_addr_ptr(dev);
- if (!tphy->sif_base)
- return -ENOENT;
+ tphy->version = dev_get_driver_data(dev);
+
+ /* v1 has shared banks */
+ if (tphy->version == MTK_TPHY_V1) {
+ tphy->sif_base = dev_read_addr_ptr(dev);
+ if (!tphy->sif_base)
+ return -ENOENT;
+ }
dev_for_each_subnode(subnode, dev) {
struct mtk_phy_instance *instance;
@@ -560,7 +617,8 @@ static int mtk_tphy_probe(struct udevice *dev)
}
static const struct udevice_id mtk_tphy_id_table[] = {
- { .compatible = "mediatek,generic-tphy-v1", },
+ { .compatible = "mediatek,generic-tphy-v1", .data = MTK_TPHY_V1, },
+ { .compatible = "mediatek,generic-tphy-v2", .data = MTK_TPHY_V2, },
{ }
};
--
2.25.1
[PATCH v2 09/10] dt-bindings: phy-mtk-tphy: add properties of address mapping and clocks
1. add the address mapping related properties;
2. make "ref" clock optional, and add optional clock "da_ref";
3. add the banks layout of TPHY V1 and V2;
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
doc/device-tree-bindings/phy/phy-mtk-tphy.txt | 78 ---
1 file changed, 68 insertions(+), 10 deletions(-)
diff --git a/doc/device-tree-bindings/phy/phy-mtk-tphy.txt
b/doc/device-tree-bindings/phy/phy-mtk-tphy.txt
index 037c5a4be5..8cd23d8c0b 100644
--- a/doc/device-tree-bindings/phy/phy-mtk-tphy.txt
+++ b/doc/device-tree-bindings/phy/phy-mtk-tphy.txt
@@ -7,10 +7,17 @@ controllers on MediaTek SoCs, such as, USB2.0, USB3.0, PCIe,
and SATA.
Required properties (controller (parent) node):
- compatible : should be one of
"mediatek,generic-tphy-v1"
- - clocks : (deprecated, use port's clocks instead) a list of phandle +
- clock-specifier pairs, one for each entry in clock-names
- - clock-names : (deprecated, use port's one instead) must contain
- "u3phya_ref": for reference clock of usb3.0 analog phy.
+ "mediatek,generic-tphy-v2"
+
+- #address-cells: the number of cells used to represent physical
+ base addresses.
+- #size-cells: the number of cells used to represent the size of an address.
+- ranges: the address mapping relationship to the parent, defined with
+ - empty value: if optional 'reg' is used.
+ - non-empty value: if optional 'reg' is not used. should set
+ the child's base address to 0, the physical address
+ within parent's address space, and the length of
+ the address map.
Required nodes : a sub-node is required for each port the controller
provides. Address range information including the usual
@@ -27,12 +34,6 @@ Optional properties (controller (parent) node):
Required properties (port (child) node):
- reg : address and length of the register set for the port.
-- clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock-names
-- clock-names : must contain
- "ref": 48M reference clock for HighSpeed analog phy; and 26M
- reference clock for SuperSpeed analog phy, sometimes is
- 24M, 25M or 27M, depended on platform.
- #phy-cells : should be 1 (See second example)
cell after port phandle is phy type from:
- PHY_TYPE_USB2
@@ -40,6 +41,17 @@ Required properties (port (child) node):
- PHY_TYPE_PCIE
- PHY_TYPE_SATA
+Optional properties (port (child) node):
+- clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+- clock-names : may contain
+ "ref": 48M reference clock for HighSpeed (digital) phy; and
26M
+ reference clock for SuperSpeed (digital) phy, sometimes
is
+ 24M, 25M or 27M, depended on platform.
+ "da_ref": the reference clock of analog phy, used if the
clocks
+ of analog and digital phys are separated, otherwise uses
+ "ref" clock only if needed.
+
Example:
u3phy2: usb-phy@1a244000 {
@@ -84,3 +96,49 @@ usb30: usb@1127 {
phy-names = "usb2-0", "usb3-0";
...
};
+
+Layout differences of banks between TPHY V1 and V2
+-
+IP V1:
+portoffsetbank
+shared 0xSPLLC
+0x0100FMREG
+u2 port00x0800U2PHY_COM
+u3 port00x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000U2PHY_COM
+u3 port10x1100U3PHYD
+0x1200U3PHYD_BANK2
+0x1300U3PHYA
+0x1400U3PHYA_DA
+u2 port20x1800U2PHY_COM
+...
+
+IP V2:
+portoffsetbank
+u2 port00xMISC
+0x0100FMREG
+0x0300U2PHY_COM
+u3 port00x0700SPLLC
+0x0800CHIP
+0x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000MISC
+0x1100FMREG
+0x1300U2PHY_COM
+u3 port10x1700SPLLC
+0x1800CHIP
+0x1900U3PHYD
+0x1a00U3PHYD_BANK2
+0x1b00U3PHYA
+0x1c00U3PHYA_DA
+u2 port20x2000MISC
+...
+
+SPLLC shared by u3 ports and FMREG shared by u2 ports on
+TPHY V1 are put back into each port; a new bank MISC for
+u2 ports and CHIP for u3 ports are added on TPHY V2.
--
2.25.1
[PATCH v2 00/10] Add support for MediaTek xHCI host controller
The series of patches are used to support xHCI host controller on MediaTek SoCs which has a glue layer IPPC (IP Port Control), and add USB function on T-PHY including T-PHY V1 and V2; Finally add USB related nodes for MT7629 platform. The files of xhci-mtk.* and phy-mtk-tphy.* are ported from Linux Kenrel 5.6-rc1 v2 changes: 1. move ofnode_get_child_count() into ofnode.c suggested by Simon 2. add a test item for ofnode_get_child_count() suggested by Simon 3. use clk_bulk to get clocks suggested by Marek 4. use clrsetbits_le32() etc suggeseted by Marek 5. get the count of phys by dev_get_child_count() 6. drop reference to fixed clock clk20m Chunfeng Yun (10): dm: core: Add function to get child count of ofnode or device test: dm: add test item for ofnode_get_child_count() sandbox: dts: test: add a node for ofnode_get_child_count() phy: phy-mtk-tphy: add support USB phys phy: phy-mtk-tphy: add support new version phy: phy-mtk-tphy: add a new reference clock xhci: mediatek: Add support for MTK xHCI host controller arm: dts: mt7629: add usb related nodes dt-bindings: phy-mtk-tphy: add properties of address mapping and clocks dt-bindings: usb: mtk-xhci: Add binding for MediaTek xHCI host controller arch/arm/dts/mt7629-rfb.dts | 8 + arch/arm/dts/mt7629.dtsi | 41 ++ arch/sandbox/dts/test.dts | 18 + doc/device-tree-bindings/phy/phy-mtk-tphy.txt | 78 +++- .../usb/mediatek,mtk-xhci.txt | 40 ++ drivers/core/ofnode.c | 11 + drivers/phy/phy-mtk-tphy.c| 316 +- drivers/usb/host/Kconfig | 6 + drivers/usb/host/Makefile | 1 + drivers/usb/host/xhci-mtk.c | 402 ++ include/dm/ofnode.h | 8 + include/dm/read.h | 9 + test/dm/ofnode.c | 21 + 13 files changed, 932 insertions(+), 27 deletions(-) create mode 100644 doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt create mode 100644 drivers/usb/host/xhci-mtk.c -- 2.25.1
[PATCH v2 06/10] phy: phy-mtk-tphy: add a new reference clock
Usually the digital and analog phys use the same reference clock,
but some platforms have two separate reference clocks for each of
them, so add another optional clock to support them.
In order to keep the clock names consistent with PHY IP's, change
the da_ref for analog phy and ref clock for digital phy.
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/phy/phy-mtk-tphy.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/phy-mtk-tphy.c b/drivers/phy/phy-mtk-tphy.c
index 20167fe7cb..81525a48b7 100644
--- a/drivers/phy/phy-mtk-tphy.c
+++ b/drivers/phy/phy-mtk-tphy.c
@@ -199,8 +199,8 @@ struct mtk_phy_instance {
struct u3phy_banks u3_banks;
};
- /* reference clock of anolog phy */
- struct clk ref_clk;
+ struct clk ref_clk; /* reference clock of (digital) phy */
+ struct clk da_ref_clk; /* reference clock of analog phy */
u32 index;
u32 type;
};
@@ -450,8 +450,17 @@ static int mtk_phy_init(struct phy *phy)
int ret;
ret = clk_enable(>ref_clk);
- if (ret)
+ if (ret < 0) {
+ dev_err(tphy->dev, "failed to enable ref_clk\n");
return ret;
+ }
+
+ ret = clk_enable(>da_ref_clk);
+ if (ret < 0) {
+ dev_err(tphy->dev, "failed to enable da_ref_clk %d\n", ret);
+ clk_disable(>ref_clk);
+ return ret;
+ }
switch (instance->type) {
case PHY_TYPE_USB2:
@@ -502,6 +511,7 @@ static int mtk_phy_exit(struct phy *phy)
struct mtk_tphy *tphy = dev_get_priv(phy->dev);
struct mtk_phy_instance *instance = tphy->phys[phy->id];
+ clk_disable(>da_ref_clk);
clk_disable(>ref_clk);
return 0;
@@ -611,6 +621,11 @@ static int mtk_tphy_probe(struct udevice *dev)
>ref_clk);
if (err)
return err;
+
+ err = clk_get_optional_nodev(subnode, "da_ref",
+>da_ref_clk);
+ if (err)
+ return err;
}
return 0;
--
2.25.1
[PATCH v2 01/10] dm: core: Add function to get child count of ofnode or device
This patch add function used to get the child count of
a ofnode or a device
Signed-off-by: Chunfeng Yun
---
v2:
1. move ofnode_get_child_count() into ofnode.c suggested by Simon
2. add a new macro dev_get_child_count()
---
drivers/core/ofnode.c | 11 +++
include/dm/ofnode.h | 8
include/dm/read.h | 9 +
3 files changed, 28 insertions(+)
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 96a5dd20bd..6f4eb422a4 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -453,6 +453,17 @@ ofnode ofnode_get_chosen_node(const char *name)
return ofnode_path(prop);
}
+int ofnode_get_child_count(ofnode parent)
+{
+ ofnode child;
+ int num = 0;
+
+ ofnode_for_each_subnode(child, parent)
+ num++;
+
+ return num;
+}
+
static int decode_timing_property(ofnode node, const char *name,
struct timing_entry *result)
{
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index b5a50e8849..3fe8fcdc5d 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -793,6 +793,14 @@ ofnode ofnode_by_prop_value(ofnode from, const char
*propname,
ofnode_valid(node); \
node = ofnode_next_subnode(node))
+/**
+ * ofnode_get_child_count() - get the child count of a ofnode
+ *
+ * @node: valid node ot get its child count
+ * @return the count of child subnode
+ */
+int ofnode_get_child_count(ofnode parent);
+
/**
* ofnode_translate_address() - Translate a device-tree address
*
diff --git a/include/dm/read.h b/include/dm/read.h
index da8c7f25e7..0b7dec4c83 100644
--- a/include/dm/read.h
+++ b/include/dm/read.h
@@ -901,4 +901,13 @@ static inline int dev_read_alias_highest_id(const char
*stem)
ofnode_valid(subnode); \
subnode = ofnode_next_subnode(subnode))
+/**
+ * dev_get_child_count() - get the child count of a device
+ *
+ * @dev: device to use for interation (struct udevice *)
+ * @return the count of child subnode
+ */
+#define dev_get_child_count(dev) \
+ ofnode_get_child_count(dev_ofnode(dev))
+
#endif
--
2.25.1
[PATCH v2 02/10] test: dm: add test item for ofnode_get_child_count()
Add a test item for ofnode_get_child_count()
Signed-off-by: Chunfeng Yun
---
v2:
a new patch to test ofnode_get_child_count() suggested by Simon
---
test/dm/ofnode.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/test/dm/ofnode.c b/test/dm/ofnode.c
index 1c49eaf38b..07d5c7d7a6 100644
--- a/test/dm/ofnode.c
+++ b/test/dm/ofnode.c
@@ -113,3 +113,24 @@ static int dm_test_ofnode_read_chosen(struct
unit_test_state *uts)
return 0;
}
DM_TEST(dm_test_ofnode_read_chosen, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+static int dm_test_ofnode_get_child_count(struct unit_test_state *uts)
+{
+ ofnode node, child_node;
+ u32 val;
+
+ node = ofnode_path("/i-test");
+ ut_assert(ofnode_valid(node));
+
+ val = ofnode_get_child_count(node);
+ ut_asserteq(3, val);
+
+ child_node = ofnode_first_subnode(node);
+ ut_assert(ofnode_valid(child_node));
+ val = ofnode_get_child_count(child_node);
+ ut_asserteq(0, val);
+
+ return 0;
+}
+DM_TEST(dm_test_ofnode_get_child_count,
+ DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
--
2.25.1
