1)Add G12A SoC i2c compatible string in dt-bindings.
2)Add compatible and data for G12A I2C controller driver.
Jian Hu (2):
dt-bindings: i2c: meson: add Meson G12A SoC i2c compatible string
i2c: meson: add support for Meson G12A SoC I2C controller
Documentation/devicetree/bindings/i2c/i2c-meson.txt | 1 +
drivers/i2c/busses/i2c-meson.c | 5 +++++
2 files changed, 6 insertions(+)
--
1.9.1
Add compatible and data for G12A I2C controller.
Signed-off-by: Jian Hu <[email protected]>
---
drivers/i2c/busses/i2c-meson.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/i2c/busses/i2c-meson.c b/drivers/i2c/busses/i2c-meson.c
index 90f5d04..b86eed7 100644
--- a/drivers/i2c/busses/i2c-meson.c
+++ b/drivers/i2c/busses/i2c-meson.c
@@ -462,10 +462,15 @@ static int meson_i2c_remove(struct platform_device *pdev)
.div_factor = 3,
};
+static const struct meson_i2c_data i2c_g12a_data = {
+ .div_factor = 3,
+};
+
static const struct of_device_id meson_i2c_match[] = {
{ .compatible = "amlogic,meson6-i2c", .data = &i2c_meson6_data },
{ .compatible = "amlogic,meson-gxbb-i2c", .data = &i2c_gxbb_data },
{ .compatible = "amlogic,meson-axg-i2c", .data = &i2c_axg_data },
+ { .compatible = "amlogic,meson-g12a-i2c", .data = &i2c_g12a_data },
{},
};
--
1.9.1
Add Meson G12A SoC i2c controller compatible string
Signed-off-by: Jian Hu <[email protected]>
---
Documentation/devicetree/bindings/i2c/i2c-meson.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-meson.txt b/Documentation/devicetree/bindings/i2c/i2c-meson.txt
index 13d410d..795bc12 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-meson.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-meson.txt
@@ -5,6 +5,7 @@ Required properties:
"amlogic,meson6-i2c" for Meson8 and compatible SoCs
"amlogic,meson-gxbb-i2c" for GXBB and compatible SoCs
"amlogic,meson-axg-i2c"for AXG and compatible SoCs
+ "amlogic,meson-g12a-i2c" for G12A and compatible SoCs
- reg: physical address and length of the device registers
- interrupts: a single interrupt specifier
--
1.9.1
On Thu, 2018-11-29 at 18:59 +0800, Jian Hu wrote:
> 1)Add G12A SoC i2c compatible string in dt-bindings.
> 2)Add compatible and data for G12A I2C controller driver.
>
> Jian Hu (2):
> dt-bindings: i2c: meson: add Meson G12A SoC i2c compatible string
> i2c: meson: add support for Meson G12A SoC I2C controller
Looks to me that the g12a is compatible with the axg. What is the point of
adding this new compatible string ?
>
> Documentation/devicetree/bindings/i2c/i2c-meson.txt | 1 +
> drivers/i2c/busses/i2c-meson.c | 5 +++++
> 2 files changed, 6 insertions(+)
>
On 29/11/2018 11:59, Jian Hu wrote:
> Add compatible and data for G12A I2C controller.
>
> Signed-off-by: Jian Hu <[email protected]>
> ---
> drivers/i2c/busses/i2c-meson.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-meson.c b/drivers/i2c/busses/i2c-meson.c
> index 90f5d04..b86eed7 100644
> --- a/drivers/i2c/busses/i2c-meson.c
> +++ b/drivers/i2c/busses/i2c-meson.c
> @@ -462,10 +462,15 @@ static int meson_i2c_remove(struct platform_device *pdev)
> .div_factor = 3,
> };
>
> +static const struct meson_i2c_data i2c_g12a_data = {
> + .div_factor = 3,
Especially if the div_factor is the same as AXG.
If you have some other fixes for G12a in the pipe, you will add the new compatible and meson_i2c_data later,
for the div_factor, simply use the axg struct and compatible.
Neil
> +};
> +
> static const struct of_device_id meson_i2c_match[] = {
> { .compatible = "amlogic,meson6-i2c", .data = &i2c_meson6_data },
> { .compatible = "amlogic,meson-gxbb-i2c", .data = &i2c_gxbb_data },
> { .compatible = "amlogic,meson-axg-i2c", .data = &i2c_axg_data },
> + { .compatible = "amlogic,meson-g12a-i2c", .data = &i2c_g12a_data },
> {},
> };
>
>
On 2018/11/29 19:02, Jerome Brunet wrote:
> On Thu, 2018-11-29 at 18:59 +0800, Jian Hu wrote:
>> 1)Add G12A SoC i2c compatible string in dt-bindings.
>> 2)Add compatible and data for G12A I2C controller driver.
>>
>> Jian Hu (2):
>> dt-bindings: i2c: meson: add Meson G12A SoC i2c compatible string
>> i2c: meson: add support for Meson G12A SoC I2C controller
>
> Looks to me that the g12a is compatible with the axg. What is the point of
> adding this new compatible string ?
>
I am okay if it is reasonable below in file
arch/arm64/boot/dts/amlogic/meson-g12a.dtsi. I2c controller node just
uses axg's compatible.
i2c0: i2c@1f000 {
compatible = "amlogic,meson-axg-i2c";
reg = <0x0 0x1f000 0x0 0x20>;
interrupts = <GIC_SPI 21 IRQ_TYPE_EDGE_RISING>;
clocks = <&clkc CLKID_I2C>;
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
};
If it is, I just submit the i2c controller node in meson-g12a.dtsi.
>>
>> Documentation/devicetree/bindings/i2c/i2c-meson.txt | 1 +
>> drivers/i2c/busses/i2c-meson.c | 5 +++++
>> 2 files changed, 6 insertions(+)
>>
>
>
> .
>
Hi Neil,
On 2018/11/29 19:26, Neil Armstrong wrote:
> On 29/11/2018 11:59, Jian Hu wrote:
>> Add compatible and data for G12A I2C controller.
>>
>> Signed-off-by: Jian Hu <[email protected]>
>> ---
>> drivers/i2c/busses/i2c-meson.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/i2c/busses/i2c-meson.c b/drivers/i2c/busses/i2c-meson.c
>> index 90f5d04..b86eed7 100644
>> --- a/drivers/i2c/busses/i2c-meson.c
>> +++ b/drivers/i2c/busses/i2c-meson.c
>> @@ -462,10 +462,15 @@ static int meson_i2c_remove(struct platform_device *pdev)
>> .div_factor = 3,
>> };
>>
>> +static const struct meson_i2c_data i2c_g12a_data = {
>> + .div_factor = 3,
>
> Especially if the div_factor is the same as AXG.
>
> If you have some other fixes for G12a in the pipe, you will add the new compatible and meson_i2c_data later,
> for the div_factor, simply use the axg struct and compatible.
>
> Neil
>
For axg and g12a SoC, the div_factor is the same, and I have confirmed
that they share the same IP. I prefer g12a uses axg's compatible and
data if it is reasonable. I will just submit the i2c controller node in
meson-g12a.dtsi.
>> +};
>> +
>> static const struct of_device_id meson_i2c_match[] = {
>> { .compatible = "amlogic,meson6-i2c", .data = &i2c_meson6_data },
>> { .compatible = "amlogic,meson-gxbb-i2c", .data = &i2c_gxbb_data },
>> { .compatible = "amlogic,meson-axg-i2c", .data = &i2c_axg_data },
>> + { .compatible = "amlogic,meson-g12a-i2c", .data = &i2c_g12a_data },
>> {},
>> };
>>
>>
>
> .
>
> I am okay if it is reasonable below in file
> arch/arm64/boot/dts/amlogic/meson-g12a.dtsi. I2c controller node just uses
> axg's compatible.
>
> i2c0: i2c@1f000 {
> compatible = "amlogic,meson-axg-i2c";
Actually, you should have
compatible = "amlogic,meson-g12a-i2c", "amlogic,meson-axg-i2c";
in the DT to have support for future SoC specific additions. And then,
patch 1 is needed.
Or do you handle this differently? I'd think this is DT standard.
Wolfram Sang <[email protected]> writes:
>> I am okay if it is reasonable below in file
>> arch/arm64/boot/dts/amlogic/meson-g12a.dtsi. I2c controller node just uses
>> axg's compatible.
>>
>> i2c0: i2c@1f000 {
>> compatible = "amlogic,meson-axg-i2c";
>
> Actually, you should have
>
> compatible = "amlogic,meson-g12a-i2c", "amlogic,meson-axg-i2c";
>
> in the DT to have support for future SoC specific additions. And then,
> patch 1 is needed.
>
> Or do you handle this differently? I'd think this is DT standard.
It's a DT standard *if* there are actual hardware differences. In this
case, the IP block is identical, so there are no driver changes.
We prefer to add a new compatible if and when there are actual
driver/hardware changes.
Kevin
> >> I am okay if it is reasonable below in file
> >> arch/arm64/boot/dts/amlogic/meson-g12a.dtsi. I2c controller node just uses
> >> axg's compatible.
> >>
> >> i2c0: i2c@1f000 {
> >> compatible = "amlogic,meson-axg-i2c";
> >
> > Actually, you should have
> >
> > compatible = "amlogic,meson-g12a-i2c", "amlogic,meson-axg-i2c";
> >
> > in the DT to have support for future SoC specific additions. And then,
> > patch 1 is needed.
> >
> > Or do you handle this differently? I'd think this is DT standard.
>
> It's a DT standard *if* there are actual hardware differences. In this
> case, the IP block is identical, so there are no driver changes.
>
> We prefer to add a new compatible if and when there are actual
> driver/hardware changes.
OK, fine with me. I just hope for you guys that there really is no
change in the IP block, otherwise you need to update DTs later.