Hi,
I see a bunch of vendor (or SoC) names in
Documentation/device/bindings/arm/
./Documentation/devicetree/bindings/arm/altera
./Documentation/devicetree/bindings/arm/amlogic
./Documentation/devicetree/bindings/arm/apm
./Documentation/devicetree/bindings/arm/bcm
./Documentation/devicetree/bindings/arm/calxeda
./Documentation/devicetree/bindings/arm/freescale
./Documentation/devicetree/bindings/arm/hisilicon
./Documentation/devicetree/bindings/arm/keystone
./Documentation/devicetree/bindings/arm/marvell
./Documentation/devicetree/bindings/arm/mediatek
./Documentation/devicetree/bindings/arm/mrvl
./Documentation/devicetree/bindings/arm/msm
./Documentation/devicetree/bindings/arm/npcm
./Documentation/devicetree/bindings/arm/nxp
./Documentation/devicetree/bindings/arm/omap
./Documentation/devicetree/bindings/arm/rockchip
./Documentation/devicetree/bindings/arm/samsung
./Documentation/devicetree/bindings/arm/stm32
./Documentation/devicetree/bindings/arm/sunxi
./Documentation/devicetree/bindings/arm/tegra
./Documentation/devicetree/bindings/arm/ti
./Documentation/devicetree/bindings/arm/uniphier
./Documentation/devicetree/bindings/arm/ux500
./Documentation/devicetree/bindings/arm/vt8500
I also see some vendor names in
Documentation/device/bindings/soc/
./Documentation/devicetree/bindings/soc/bcm
./Documentation/devicetree/bindings/soc/dove
./Documentation/devicetree/bindings/soc/fsl
./Documentation/devicetree/bindings/soc/mediatek
./Documentation/devicetree/bindings/soc/qcom
./Documentation/devicetree/bindings/soc/rockchip
./Documentation/devicetree/bindings/soc/ti
./Documentation/devicetree/bindings/soc/xilinx
./Documentation/devicetree/bindings/soc/zte
Confusingly, I see bcm, mediatek, rockchip
in both locations.
Is there any rule to choose one than the other?
--
Best Regards
Masahiro Yamada
On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
<[email protected]> wrote:
>
> Hi,
>
>
> I see a bunch of vendor (or SoC) names in
> Documentation/device/bindings/arm/
>
> ./Documentation/devicetree/bindings/arm/altera
> ./Documentation/devicetree/bindings/arm/amlogic
Yeah, it's kind of a mixture of board/soc bindings mostly with some
ARM architecture, ARM, Ltd. IP, and SoC system reg bindings.
Eventually, I'd like to not split board bindings by arch and maybe we
should move all the system/misc reg bindings out.
[,,,]
> I also see some vendor names in
> Documentation/device/bindings/soc/
>
> ./Documentation/devicetree/bindings/soc/bcm
> ./Documentation/devicetree/bindings/soc/dove
> ./Documentation/devicetree/bindings/soc/fsl
> ./Documentation/devicetree/bindings/soc/mediatek
> ./Documentation/devicetree/bindings/soc/qcom
> ./Documentation/devicetree/bindings/soc/rockchip
> ./Documentation/devicetree/bindings/soc/ti
> ./Documentation/devicetree/bindings/soc/xilinx
> ./Documentation/devicetree/bindings/soc/zte
This I believe is mostly SoC system reg bindings though there's
probably a few other things.
> Confusingly, I see bcm, mediatek, rockchip
> in both locations.
>
> Is there any rule to choose one than the other?
Top-level SoC/board bindings in arm/ and anything else elsewhere ideally.
Rob
Hi,
Am 10.10.2018 um 13:19 schrieb Rob Herring:
> On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
> <[email protected]> wrote:
>> Hi,
>>
>>
>> I see a bunch of vendor (or SoC) names in
>> Documentation/device/bindings/arm/
>>
>> ./Documentation/devicetree/bindings/arm/altera
>> ./Documentation/devicetree/bindings/arm/amlogic
> Yeah, it's kind of a mixture of board/soc bindings mostly with some
> ARM architecture, ARM, Ltd. IP, and SoC system reg bindings.
>
> Eventually, I'd like to not split board bindings by arch and maybe we
> should move all the system/misc reg bindings out.
>
> [,,,]
>
>> I also see some vendor names in
>> Documentation/device/bindings/soc/
>>
>> ./Documentation/devicetree/bindings/soc/bcm
>> ./Documentation/devicetree/bindings/soc/dove
>> ./Documentation/devicetree/bindings/soc/fsl
>> ./Documentation/devicetree/bindings/soc/mediatek
>> ./Documentation/devicetree/bindings/soc/qcom
>> ./Documentation/devicetree/bindings/soc/rockchip
>> ./Documentation/devicetree/bindings/soc/ti
>> ./Documentation/devicetree/bindings/soc/xilinx
>> ./Documentation/devicetree/bindings/soc/zte
> This I believe is mostly SoC system reg bindings though there's
> probably a few other things.
>
>> Confusingly, I see bcm, mediatek, rockchip
>> in both locations.
>>
>> Is there any rule to choose one than the other?
> Top-level SoC/board bindings in arm/ and anything else elsewhere ideally.
in case of Documentation/devicetree/bindings/soc/bcm the directory
contains SoC / board bindings, cpu-enable and a firmware binding.
Is there any action required?
Btw the Broadcom SoC / boards from this directory has been left out for
the yaml conversion [1] was this intended?
[1] - https://lwn.net/Articles/767723/
>
> Rob
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Oct 10, 2018 at 08:07:52PM +0900, Masahiro Yamada wrote:
> Hi,
>
>
> I see a bunch of vendor (or SoC) names in
> Documentation/device/bindings/arm/
>
> ./Documentation/devicetree/bindings/arm/altera
> ./Documentation/devicetree/bindings/arm/amlogic
> ./Documentation/devicetree/bindings/arm/apm
> ./Documentation/devicetree/bindings/arm/bcm
> ./Documentation/devicetree/bindings/arm/calxeda
> ./Documentation/devicetree/bindings/arm/freescale
> ./Documentation/devicetree/bindings/arm/hisilicon
> ./Documentation/devicetree/bindings/arm/keystone
> ./Documentation/devicetree/bindings/arm/marvell
> ./Documentation/devicetree/bindings/arm/mediatek
> ./Documentation/devicetree/bindings/arm/mrvl
> ./Documentation/devicetree/bindings/arm/msm
> ./Documentation/devicetree/bindings/arm/npcm
> ./Documentation/devicetree/bindings/arm/nxp
> ./Documentation/devicetree/bindings/arm/omap
> ./Documentation/devicetree/bindings/arm/rockchip
> ./Documentation/devicetree/bindings/arm/samsung
> ./Documentation/devicetree/bindings/arm/stm32
> ./Documentation/devicetree/bindings/arm/sunxi
> ./Documentation/devicetree/bindings/arm/tegra
> ./Documentation/devicetree/bindings/arm/ti
> ./Documentation/devicetree/bindings/arm/uniphier
> ./Documentation/devicetree/bindings/arm/ux500
> ./Documentation/devicetree/bindings/arm/vt8500
These are for arch/arm/mach-* and are the DT root descriptions for the
various boards and SoCs.
> I also see some vendor names in
> Documentation/device/bindings/soc/
>
> ./Documentation/devicetree/bindings/soc/bcm
> ./Documentation/devicetree/bindings/soc/dove
> ./Documentation/devicetree/bindings/soc/fsl
> ./Documentation/devicetree/bindings/soc/mediatek
> ./Documentation/devicetree/bindings/soc/qcom
> ./Documentation/devicetree/bindings/soc/rockchip
> ./Documentation/devicetree/bindings/soc/ti
> ./Documentation/devicetree/bindings/soc/xilinx
> ./Documentation/devicetree/bindings/soc/zte
These are for individual drivers in drivers/soc/
> Confusingly, I see bcm, mediatek, rockchip
> in both locations.
Correct, because one is for the SoC and board as a whole, the other is
for some subset of the SoC handled via drivers/soc - for example, with
Broadcom, there's a Raspberry PI power domain driver in drivers/soc,
which is described by
Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt
whereas
Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt
describes the bindings for the root DT node BCM2835 as used on the
Raspberry Pi amongst other boards.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
On Wed, Oct 10, 2018 at 02:04:14PM +0200, Stefan Wahren wrote:
> Hi,
>
> Am 10.10.2018 um 13:19 schrieb Rob Herring:
> > On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
> > <[email protected]> wrote:
> >> Hi,
> >>
> >>
> >> I see a bunch of vendor (or SoC) names in
> >> Documentation/device/bindings/arm/
> >>
> >> ./Documentation/devicetree/bindings/arm/altera
> >> ./Documentation/devicetree/bindings/arm/amlogic
> > Yeah, it's kind of a mixture of board/soc bindings mostly with some
> > ARM architecture, ARM, Ltd. IP, and SoC system reg bindings.
> >
> > Eventually, I'd like to not split board bindings by arch and maybe we
> > should move all the system/misc reg bindings out.
> >
> > [,,,]
> >
> >> I also see some vendor names in
> >> Documentation/device/bindings/soc/
> >>
> >> ./Documentation/devicetree/bindings/soc/bcm
> >> ./Documentation/devicetree/bindings/soc/dove
> >> ./Documentation/devicetree/bindings/soc/fsl
> >> ./Documentation/devicetree/bindings/soc/mediatek
> >> ./Documentation/devicetree/bindings/soc/qcom
> >> ./Documentation/devicetree/bindings/soc/rockchip
> >> ./Documentation/devicetree/bindings/soc/ti
> >> ./Documentation/devicetree/bindings/soc/xilinx
> >> ./Documentation/devicetree/bindings/soc/zte
> > This I believe is mostly SoC system reg bindings though there's
> > probably a few other things.
> >
> >> Confusingly, I see bcm, mediatek, rockchip
> >> in both locations.
> >>
> >> Is there any rule to choose one than the other?
> > Top-level SoC/board bindings in arm/ and anything else elsewhere ideally.
>
> in case of Documentation/devicetree/bindings/soc/bcm the directory
> contains SoC / board bindings, cpu-enable and a firmware binding.
I think you're confused there...
$ ls -1 Documentation/devicetree/bindings/soc/bcm/
brcm,bcm2835-vchiq.txt
raspberrypi,bcm2835-power.txt
Doesn't look like SoC/board bindings to me...
whereas:
$ ls -1 Documentation/devicetree/bindings/arm/bcm/
brcm,bcm11351-cpu-method.txt
brcm,bcm11351.txt
brcm,bcm21664.txt
brcm,bcm23550-cpu-method.txt
brcm,bcm23550.txt
brcm,bcm2835.txt
brcm,bcm4708.txt
brcm,bcm63138.txt
brcm,brcmstb.txt
brcm,cygnus.txt
brcm,hr2.txt
brcm,ns2.txt
brcm,nsp-cpu-method.txt
brcm,nsp.txt
brcm,stingray.txt
brcm,vulcan-soc.txt
raspberrypi,bcm2835-firmware.txt
does fit with your description, except for the directory path...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Am 10.10.2018 um 14:09 schrieb Russell King - ARM Linux:
> On Wed, Oct 10, 2018 at 02:04:14PM +0200, Stefan Wahren wrote:
>> Hi,
>>
>> Am 10.10.2018 um 13:19 schrieb Rob Herring:
>>> On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
>>> <[email protected]> wrote:
>>>> Hi,
>>>>
>>>>
>>>> I see a bunch of vendor (or SoC) names in
>>>> Documentation/device/bindings/arm/
>>>>
>>>> ./Documentation/devicetree/bindings/arm/altera
>>>> ./Documentation/devicetree/bindings/arm/amlogic
>>> Yeah, it's kind of a mixture of board/soc bindings mostly with some
>>> ARM architecture, ARM, Ltd. IP, and SoC system reg bindings.
>>>
>>> Eventually, I'd like to not split board bindings by arch and maybe we
>>> should move all the system/misc reg bindings out.
>>>
>>> [,,,]
>>>
>>>> I also see some vendor names in
>>>> Documentation/device/bindings/soc/
>>>>
>>>> ./Documentation/devicetree/bindings/soc/bcm
>>>> ./Documentation/devicetree/bindings/soc/dove
>>>> ./Documentation/devicetree/bindings/soc/fsl
>>>> ./Documentation/devicetree/bindings/soc/mediatek
>>>> ./Documentation/devicetree/bindings/soc/qcom
>>>> ./Documentation/devicetree/bindings/soc/rockchip
>>>> ./Documentation/devicetree/bindings/soc/ti
>>>> ./Documentation/devicetree/bindings/soc/xilinx
>>>> ./Documentation/devicetree/bindings/soc/zte
>>> This I believe is mostly SoC system reg bindings though there's
>>> probably a few other things.
>>>
>>>> Confusingly, I see bcm, mediatek, rockchip
>>>> in both locations.
>>>>
>>>> Is there any rule to choose one than the other?
>>> Top-level SoC/board bindings in arm/ and anything else elsewhere ideally.
>> in case of Documentation/devicetree/bindings/soc/bcm the directory
>> contains SoC / board bindings, cpu-enable and a firmware binding.
> I think you're confused there...
>
> $ ls -1 Documentation/devicetree/bindings/soc/bcm/
> brcm,bcm2835-vchiq.txt
> raspberrypi,bcm2835-power.txt
>
> Doesn't look like SoC/board bindings to me...
>
> whereas:
>
> $ ls -1 Documentation/devicetree/bindings/arm/bcm/
> brcm,bcm11351-cpu-method.txt
> brcm,bcm11351.txt
> brcm,bcm21664.txt
> brcm,bcm23550-cpu-method.txt
> brcm,bcm23550.txt
> brcm,bcm2835.txt
> brcm,bcm4708.txt
> brcm,bcm63138.txt
> brcm,brcmstb.txt
> brcm,cygnus.txt
> brcm,hr2.txt
> brcm,ns2.txt
> brcm,nsp-cpu-method.txt
> brcm,nsp.txt
> brcm,stingray.txt
> brcm,vulcan-soc.txt
> raspberrypi,bcm2835-firmware.txt
>
> does fit with your description, except for the directory path...
sorry, my fault i copied the wrong path. I actually thought of
Documentation/devicetree/bindings/arm/bcm/
Thanks for pointing out
On Wed, Oct 10, 2018 at 9:09 PM Russell King - ARM Linux
<[email protected]> wrote:
>
> On Wed, Oct 10, 2018 at 08:07:52PM +0900, Masahiro Yamada wrote:
> > Hi,
> >
> >
> > I see a bunch of vendor (or SoC) names in
> > Documentation/device/bindings/arm/
> >
> > ./Documentation/devicetree/bindings/arm/altera
> > ./Documentation/devicetree/bindings/arm/amlogic
> > ./Documentation/devicetree/bindings/arm/apm
> > ./Documentation/devicetree/bindings/arm/bcm
> > ./Documentation/devicetree/bindings/arm/calxeda
> > ./Documentation/devicetree/bindings/arm/freescale
> > ./Documentation/devicetree/bindings/arm/hisilicon
> > ./Documentation/devicetree/bindings/arm/keystone
> > ./Documentation/devicetree/bindings/arm/marvell
> > ./Documentation/devicetree/bindings/arm/mediatek
> > ./Documentation/devicetree/bindings/arm/mrvl
> > ./Documentation/devicetree/bindings/arm/msm
> > ./Documentation/devicetree/bindings/arm/npcm
> > ./Documentation/devicetree/bindings/arm/nxp
> > ./Documentation/devicetree/bindings/arm/omap
> > ./Documentation/devicetree/bindings/arm/rockchip
> > ./Documentation/devicetree/bindings/arm/samsung
> > ./Documentation/devicetree/bindings/arm/stm32
> > ./Documentation/devicetree/bindings/arm/sunxi
> > ./Documentation/devicetree/bindings/arm/tegra
> > ./Documentation/devicetree/bindings/arm/ti
> > ./Documentation/devicetree/bindings/arm/uniphier
> > ./Documentation/devicetree/bindings/arm/ux500
> > ./Documentation/devicetree/bindings/arm/vt8500
>
> These are for arch/arm/mach-* and are the DT root descriptions for the
> various boards and SoCs.
>
> > I also see some vendor names in
> > Documentation/device/bindings/soc/
> >
> > ./Documentation/devicetree/bindings/soc/bcm
> > ./Documentation/devicetree/bindings/soc/dove
> > ./Documentation/devicetree/bindings/soc/fsl
> > ./Documentation/devicetree/bindings/soc/mediatek
> > ./Documentation/devicetree/bindings/soc/qcom
> > ./Documentation/devicetree/bindings/soc/rockchip
> > ./Documentation/devicetree/bindings/soc/ti
> > ./Documentation/devicetree/bindings/soc/xilinx
> > ./Documentation/devicetree/bindings/soc/zte
>
> These are for individual drivers in drivers/soc/
I see.
Thanks for helpful info!
--
Best Regards
Masahiro Yamada
On Wed, Oct 10, 2018 at 7:04 AM Stefan Wahren <[email protected]> wrote:
>
> Hi,
>
> Am 10.10.2018 um 13:19 schrieb Rob Herring:
> > On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
> > <[email protected]> wrote:
> >> Hi,
> >>
> >>
> >> I see a bunch of vendor (or SoC) names in
> >> Documentation/device/bindings/arm/
> >>
> >> ./Documentation/devicetree/bindings/arm/altera
> >> ./Documentation/devicetree/bindings/arm/amlogic
> > Yeah, it's kind of a mixture of board/soc bindings mostly with some
> > ARM architecture, ARM, Ltd. IP, and SoC system reg bindings.
> >
> > Eventually, I'd like to not split board bindings by arch and maybe we
> > should move all the system/misc reg bindings out.
> >
> > [,,,]
> >
> >> I also see some vendor names in
> >> Documentation/device/bindings/soc/
> >>
> >> ./Documentation/devicetree/bindings/soc/bcm
> >> ./Documentation/devicetree/bindings/soc/dove
> >> ./Documentation/devicetree/bindings/soc/fsl
> >> ./Documentation/devicetree/bindings/soc/mediatek
> >> ./Documentation/devicetree/bindings/soc/qcom
> >> ./Documentation/devicetree/bindings/soc/rockchip
> >> ./Documentation/devicetree/bindings/soc/ti
> >> ./Documentation/devicetree/bindings/soc/xilinx
> >> ./Documentation/devicetree/bindings/soc/zte
> > This I believe is mostly SoC system reg bindings though there's
> > probably a few other things.
> >
> >> Confusingly, I see bcm, mediatek, rockchip
> >> in both locations.
> >>
> >> Is there any rule to choose one than the other?
> > Top-level SoC/board bindings in arm/ and anything else elsewhere ideally.
>
> in case of Documentation/devicetree/bindings/soc/bcm the directory
> contains SoC / board bindings, cpu-enable and a firmware binding.
>
> Is there any action required?
If there's a better location based on class/function, then moving them
would be nice.
> Btw the Broadcom SoC / boards from this directory has been left out for
> the yaml conversion [1] was this intended?
Yes, I'm not planning to convert all bindings for everyone myself.
Rob