Introduce Allwinner A33 support

From: Vishnu Patekar <[email protected]>

Add machine support for the Allwinner A33 quad core cortex-a7 based SoC, which is similar to the A23 SoC.

Signed-off-by Vishnu Patekar <[email protected]>

Signed-off-by Hans de Goede <[email protected]>

From: Vishnu Patekar <[email protected]>

Rename sun8i-a23.dtsi to sun8i-a23-a33.dtsi as the base dtsi for the A33 is 99% the same and add a new sun8i-a23.dtsi including sun8i-a23-a33.dtsi and setting the few things not shared with the A33 (mbus-clk, pio compatible and interrupts).

Signed-off-by Vishnu Patekar <[email protected]>

Signed-off-by Hans de Goede <[email protected]>

Quoted 9 lines · Hans de Goede

From: Vishnu Patekar <[email protected]>

Rename sun8i-a23.dtsi to sun8i-a23-a33.dtsi as the base dtsi for the A33 is 99% the same and add a new sun8i-a23.dtsi including sun8i-a23-a33.dtsi and setting the few things not shared with the A33 (mbus-clk, pio compatible and interrupts).

Signed-off-by Vishnu Patekar <[email protected]>

Signed-off-by Hans de Goede <[email protected]>

Fixed the conflicts and applied.

Also judging from a quick look at the datasheet, the A33 doesn't seem to have that clock gates tree but rather one similar to the H3's. That will probably mean we'll have to move out the gates from this DTSI at some point.

Hi,

Quoted 11 lines · Maxime Ripard

Quoted 9 lines · Hans de Goede

From: Vishnu Patekar <[email protected]>

Rename sun8i-a23.dtsi to sun8i-a23-a33.dtsi as the base dtsi for the A33 is 99% the same and add a new sun8i-a23.dtsi including sun8i-a23-a33.dtsi and setting the few things not shared with the A33 (mbus-clk, pio compatible and interrupts).

Signed-off-by Vishnu Patekar <[email protected]>

Signed-off-by Hans de Goede <[email protected]>

Quoted 6 lines

Fixed the conflicts and applied.

Also judging from a quick look at the datasheet, the A33 doesn't seem to have that clock gates tree but rather one similar to the H3's. That will probably mean we'll have to move out the gates from this DTSI at some point.

Heuh...

Ok so I've done a full bit for bit comparison of the 2 datasheets for the clk gates, mostly they are mostly the same and the registers seem to just be renamed.

The only differences are:

01c200060 (AHB1 MODULE CLOCK GATING REGISTER 0 / Bus Clock Gating Register 0):

Only A33 has bit 5 SS gating

01c200064 (AHB1 MODULE CLOCK GATING REGISTER 1 / Bus Clock Gating Register 1):

Only A33 has bit 26 SAT gating, note that if we add support for this we must add it as a needed clock to the simplefb node

Only A33 has bit 21 MSGBOX_GATING

01c200068 (APB1 MODULE CLOCK GATING REGISTER / Bus Clock Gating Register 2):

No differences

01c20006c (APB2 MODULE CLOCK GATING REGISTER / Bus Clock Gating Register 3):

No differences

So you are right that in the near future we should add a separate compatible
+ clk driver or the ahb1_gates on the A33, but it does not seem that there is the issue of one gate register having multiple parents like on the H3. Or maybe the H3 does also not have that issue, and this is a misinterpretation of the H3 datasheet ?

Note I do not know what the actual parent clock for the new gates is, but it stands to reason that it is AHB1, I've been unable to find anything to confirm or deny this.

From: Vishnu Patekar <[email protected]>

Add a dtsi file for use with a33 based boards based on the new sun8i-a23-a33.dtsi file.

Signed-off-by Vishnu Patekar <[email protected]>

Signed-off-by Hans de Goede <[email protected]>

From: Vishnu Patekar <[email protected]>

ET-Q8_A33 is A33 based cheap tablet in common Q8 format.

It has 512MB RAM, 4GB Nand, 7" Display, RDA5900P wifi, GSL1680 touch, etc.

Signed-off-by Vishnu Patekar <[email protected]>

Signed-off-by Hans de Goede <[email protected]>

The Ippo-q8h is a tablet circuit board commonly found in cheap Android tablets. The v1.2 version can be used with either an A23 or A33 SoC.

This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600 LCD screen (most of these tablets have a 800x480 screen).

Quoted 5 lines · Hans de Goede

The Ippo-q8h is a tablet circuit board commonly found in cheap Android tablets. The v1.2 version can be used with either an A23 or A33 SoC.

This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600 LCD screen (most of these tablets have a 800x480 screen).

I think the difference between the resolution here is more of a case for the DT quirks interface:
https://lkml.org/lkml/2015/2/18/258

Do you know if there's some way to autodetect the two board versions (like a board id somewhere in an EEPROM)?

If not, then maybe u-boot can simply add that board compatible to the list, and we'll base our logic on that when we'll need it.

Hi,

Quoted 10 lines · Maxime Ripard

Quoted 5 lines · Hans de Goede

The Ippo-q8h is a tablet circuit board commonly found in cheap Android tablets. The v1.2 version can be used with either an A23 or A33 SoC.

This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600 LCD screen (most of these tablets have a 800x480 screen).

I think the difference between the resolution here is more of a case for the DT quirks interface:
https://lkml.org/lkml/2015/2/18/258

I would expect the only difference between the 2 dts files to be the node describing the lcd panel, so yes that makes somewhat sense.

Quoted 2 lines

Do you know if there's some way to autodetect the two board versions (like a board id somewhere in an EEPROM)?

No, AFAIK there is no way to tell the difference. There is no eeprom no the board, and we really cannot rely on the nand contents.

Quoted 2 lines

If not, then maybe u-boot can simply add that board compatible to the list, and we'll base our logic on that when we'll need it.

That means extra logic in u-boot, and on the kernel side, for what benefit exactly? Such logic would make sense if there was one u-boot image which runtime adjusted itself, but that is not an option.

And we can avoid copy and paste on the dts side by putting all the common stuff in a common file and including that, I believe that that is better (KISS = better) since we've no way to runtime do the right thing AFAICT.

Quoted 14 lines · Hans de Goede

Hi,

Quoted 10 lines · Maxime Ripard

Quoted 5 lines · Hans de Goede

The Ippo-q8h is a tablet circuit board commonly found in cheap Android tablets. The v1.2 version can be used with either an A23 or A33 SoC.

This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600 LCD screen (most of these tablets have a 800x480 screen).

I think the difference between the resolution here is more of a case for the DT quirks interface:
https://lkml.org/lkml/2015/2/18/258

Quoted 8 lines

I would expect the only difference between the 2 dts files to be the node describing the lcd panel, so yes that makes somewhat sense.

Quoted 2 lines

Do you know if there's some way to autodetect the two board versions (like a board id somewhere in an EEPROM)?

No, AFAIK there is no way to tell the difference. There is no eeprom no the board, and we really cannot rely on the nand contents.

Ok.

Quoted 6 lines

Quoted 2 lines

If not, then maybe u-boot can simply add that board compatible to the list, and we'll base our logic on that when we'll need it.

That means extra logic in u-boot, and on the kernel side, for what benefit exactly? Such logic would make sense if there was one u-boot image which runtime adjusted itself, but that is not an option.

For what benefit? One kernel image which runtime adjusts itself.

It's especially possible if u-boot's image is not, which seems to be what you're saying.

Quoted 4 lines

And we can avoid copy and paste on the dts side by putting all the common stuff in a common file and including that, I believe that that is better (KISS = better) since we've no way to runtime do the right thing AFAICT.

My concern is about the ever-growing number of DTS that just are small variations of one or the other. What about the time when we'll discover that this board has a variant that has an emmc, and some that don't have any button, or the i2c bus 2 not wired, and one other that doesn't have any HDMI?

Do we really want to have a dts called sun8i-a33-q8h-emmc-lcd800x600-nohdmi-noi2c2-nobuttons.dts?

Especially when we will have the one that we include here that will not have followed this convention because it was introduced before that, and that we have a way to deal with this nicely?

You chose to consider the DTS names an ABI, the best way to handle this is to have a DTS as generic as possible, and leave all these small variations outside of the name.

Hi,

Quoted 29 lines · Maxime Ripard

Quoted 14 lines · Hans de Goede

Hi,

Quoted 10 lines · Maxime Ripard

Quoted 5 lines · Hans de Goede

The Ippo-q8h is a tablet circuit board commonly found in cheap Android tablets. The v1.2 version can be used with either an A23 or A33 SoC.

This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600 LCD screen (most of these tablets have a 800x480 screen).

I think the difference between the resolution here is more of a case for the DT quirks interface:
https://lkml.org/lkml/2015/2/18/258

Quoted 8 lines

I would expect the only difference between the 2 dts files to be the node describing the lcd panel, so yes that makes somewhat sense.

Quoted 2 lines

Do you know if there's some way to autodetect the two board versions (like a board id somewhere in an EEPROM)?

No, AFAIK there is no way to tell the difference. There is no eeprom no the board, and we really cannot rely on the nand contents.

Ok.

Quoted 3 lines

Quoted 2 lines

If not, then maybe u-boot can simply add that board compatible to the list, and we'll base our logic on that when we'll need it.

Quoted 5 lines

Quoted 3 lines

That means extra logic in u-boot, and on the kernel side, for what benefit exactly? Such logic would make sense if there was one u-boot image which runtime adjusted itself, but that is not an option.

For what benefit? One kernel image which runtime adjusts itself.

You mean one dtb right, because the kernel itself already runtime adjusts itself.

Quoted 2 lines

It's especially possible if u-boot's image is not, which seems to be what you're saying.

But we will still need different configs in u-boot, and we need to add code + config to u-boot to plug in the extra compatibles to automatically select the right built-in overlays.

Quoted 14 lines

Quoted 4 lines

And we can avoid copy and paste on the dts side by putting all the common stuff in a common file and including that, I believe that that is better (KISS = better) since we've no way to runtime do the right thing AFAICT.

My concern is about the ever-growing number of DTS that just are small variations of one or the other. What about the time when we'll discover that this board has a variant that has an emmc, and some that don't have any button, or the i2c bus 2 not wired, and one other that doesn't have any HDMI?

Do we really want to have a dts called sun8i-a33-q8h-emmc-lcd800x600-nohdmi-noi2c2-nobuttons.dts?

Quoted 7 lines

Especially when we will have the one that we include here that will not have followed this convention because it was introduced before that, and that we have a way to deal with this nicely?

You chose to consider the DTS names an ABI, the best way to handle this is to have a DTS as generic as possible, and leave all these small variations outside of the name.

Ok, so for now this is not really an issue at all since the dts does not yet decribe the lcd at all. So can you merge this one renamed to a more generic name for 4.2?

That will work fine for now.

Then we can use the DT quirks interface to add different lcd nodes for different variants once we get lcd support in the kernel, and teach u-boot to add the extra board compatible to select the right lcd node at that time.

Hi,

Sorry for the late reply.

Quoted 32 lines · Hans de Goede

Hi,

Quoted 29 lines · Maxime Ripard

Quoted 14 lines · Hans de Goede

Hi,

Quoted 10 lines · Maxime Ripard

Quoted 5 lines · Hans de Goede

The Ippo-q8h is a tablet circuit board commonly found in cheap Android tablets. The v1.2 version can be used with either an A23 or A33 SoC.

This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600 LCD screen (most of these tablets have a 800x480 screen).

I think the difference between the resolution here is more of a case for the DT quirks interface:
https://lkml.org/lkml/2015/2/18/258

Quoted 8 lines

I would expect the only difference between the 2 dts files to be the node describing the lcd panel, so yes that makes somewhat sense.

Quoted 2 lines

Do you know if there's some way to autodetect the two board versions (like a board id somewhere in an EEPROM)?

No, AFAIK there is no way to tell the difference. There is no eeprom no the board, and we really cannot rely on the nand contents.

Ok.

Quoted 3 lines

Quoted 2 lines

If not, then maybe u-boot can simply add that board compatible to the list, and we'll base our logic on that when we'll need it.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

That means extra logic in u-boot, and on the kernel side, for what benefit exactly? Such logic would make sense if there was one u-boot image which runtime adjusted itself, but that is not an option.

For what benefit? One kernel image which runtime adjusts itself.

You mean one dtb right, because the kernel itself already runtime adjusts itself.

Well, the kernel will runtime adjust the DT, so, both, I'd say?

Quoted 6 lines

Quoted 2 lines

It's especially possible if u-boot's image is not, which seems to be what you're saying.

But we will still need different configs in u-boot, and we need to add code + config to u-boot to plug in the extra compatibles to automatically select the right built-in overlays.

You're going to have a different config anyway, but yeah, that's true.

Quoted 28 lines

Quoted 14 lines

Quoted 4 lines

And we can avoid copy and paste on the dts side by putting all the common stuff in a common file and including that, I believe that that is better (KISS = better) since we've no way to runtime do the right thing AFAICT.

My concern is about the ever-growing number of DTS that just are small variations of one or the other. What about the time when we'll discover that this board has a variant that has an emmc, and some that don't have any button, or the i2c bus 2 not wired, and one other that doesn't have any HDMI?

Do we really want to have a dts called sun8i-a33-q8h-emmc-lcd800x600-nohdmi-noi2c2-nobuttons.dts?

Quoted 7 lines

Especially when we will have the one that we include here that will not have followed this convention because it was introduced before that, and that we have a way to deal with this nicely?

You chose to consider the DTS names an ABI, the best way to handle this is to have a DTS as generic as possible, and leave all these small variations outside of the name.

Ok, so for now this is not really an issue at all since the dts does not yet decribe the lcd at all. So can you merge this one renamed to a more generic name for 4.2?

That will work fine for now.

Quoted 4 lines

Then we can use the DT quirks interface to add different lcd nodes for different variants once we get lcd support in the kernel, and teach u-boot to add the extra board compatible to select the right lcd node at that time.

I think we need to discuss this with Pantelis and what is his feeling about this.

Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment.

I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?)

Maxime

Quoted 12 lines

Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment.

Quoted 5 lines

I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?)

If we go with a separate dts file for each of the 800x480 and 1024x600 screens, I would greatly prefer to stick with the lcd1024x600 in the dts filename instead of using something like xga, the fact that you say:
"I guess" that my answer to that is: I dunno I would need to look this up in wikipedia or some such makes me think that using a qualifier like xga is not going the help end users decide which dts file to pick, it will just lead to them needing to go to wikipedia too. Also note that the advertising of these tablets on ebay / aliexpress almost always uses the resolution and not something like "xga".

So all in all if we do not decide to use quirks for this I would like to keep the filename as is.

Hi,

Quoted 28 lines · Hans de Goede

Quoted 12 lines

Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment.

Quoted 5 lines

I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?)

If we go with a separate dts file for each of the 800x480 and 1024x600 screens, I would greatly prefer to stick with the lcd1024x600 in the dts filename instead of using something like xga, the fact that you say:
"I guess" that my answer to that is: I dunno I would need to look this up in wikipedia or some such makes me think that using a qualifier like xga is not going the help end users decide which dts file to pick, it will just lead to them needing to go to wikipedia too. Also note that the advertising of these tablets on ebay / aliexpress almost always uses the resolution and not something like "xga".

Quoted 2 lines

So all in all if we do not decide to use quirks for this I would like to keep the filename as is.

Yeah, except that the display standard is also encoding the refresh rate and color depth

Hi,

Quoted 30 lines · Maxime Ripard

Hi,

Quoted 27 lines · Hans de Goede

Quoted 12 lines

Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment.

Quoted 5 lines

I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?)

If we go with a separate dts file for each of the 800x480 and 1024x600 screens, I would greatly prefer to stick with the lcd1024x600 in the dts filename instead of using something like xga, the fact that you say:
"I guess" that my answer to that is: I dunno I would need to look this up in wikipedia or some such makes me think that using a qualifier like xga is not going the help end users decide which dts file to pick, it will just lead to them needing to go to wikipedia too. Also note that the advertising of these tablets on ebay / aliexpress almost always uses the resolution and not something like "xga".

Quoted 5 lines

Quoted 2 lines

So all in all if we do not decide to use quirks for this I would like to keep the filename as is.

Yeah, except that the display standard is also encoding the refresh rate and color depth

Huh? No it does not, see e.g.:

https://en.wikipedia.org/wiki/Graphics_display_resolution

Note nothing about depth and refresh-rate there, and I've really never heard anyone use things like xga to refer to colordepth and/or refreshrate

Quoted 33 lines · Hans de Goede

Hi,

Quoted 30 lines · Maxime Ripard

Hi,

Quoted 27 lines · Hans de Goede

Quoted 12 lines

Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment.

Quoted 5 lines

I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?)

If we go with a separate dts file for each of the 800x480 and 1024x600 screens, I would greatly prefer to stick with the lcd1024x600 in the dts filename instead of using something like xga, the fact that you say:
"I guess" that my answer to that is: I dunno I would need to look this up in wikipedia or some such makes me think that using a qualifier like xga is not going the help end users decide which dts file to pick, it will just lead to them needing to go to wikipedia too. Also note that the advertising of these tablets on ebay / aliexpress almost always uses the resolution and not something like "xga".

<> >>

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

So all in all if we do not decide to use quirks for this I would like to keep the filename as is.

Yeah, except that the display standard is also encoding the refresh rate and color depth

Huh? No it does not, see e.g.:

Quoted 4 lines

https://en.wikipedia.org/wiki/Graphics_display_resolution

Note nothing about depth and refresh-rate there, and I've really never heard anyone use things like xga to refer to colordepth and/or refreshrate

I was somehow convinced it did, and

https://en.wikipedia.org/wiki/Computer_display_standard

Hi,

Sorry for the late reply.

Quoted 32 lines · Hans de Goede

Hi,

Quoted 29 lines · Maxime Ripard

Quoted 14 lines · Hans de Goede

Hi,

Quoted 10 lines · Maxime Ripard

Quoted 5 lines · Hans de Goede

The Ippo-q8h is a tablet circuit board commonly found in cheap Android tablets. The v1.2 version can be used with either an A23 or A33 SoC.

This adds a dts file for the v1.2 board with an A33 SoC and a 1024x600 LCD screen (most of these tablets have a 800x480 screen).

I think the difference between the resolution here is more of a case for the DT quirks interface:
https://lkml.org/lkml/2015/2/18/258

Quoted 8 lines

I would expect the only difference between the 2 dts files to be the node describing the lcd panel, so yes that makes somewhat sense.

Quoted 2 lines

Do you know if there's some way to autodetect the two board versions (like a board id somewhere in an EEPROM)?

No, AFAIK there is no way to tell the difference. There is no eeprom no the board, and we really cannot rely on the nand contents.

Ok.

Quoted 3 lines

Quoted 2 lines

If not, then maybe u-boot can simply add that board compatible to the list, and we'll base our logic on that when we'll need it.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

That means extra logic in u-boot, and on the kernel side, for what benefit exactly? Such logic would make sense if there was one u-boot image which runtime adjusted itself, but that is not an option.

For what benefit? One kernel image which runtime adjusts itself.

You mean one dtb right, because the kernel itself already runtime adjusts itself.

Well, the kernel will runtime adjust the DT, so, both, I'd say?

Quoted 6 lines

Quoted 2 lines

It's especially possible if u-boot's image is not, which seems to be what you're saying.

But we will still need different configs in u-boot, and we need to add code + config to u-boot to plug in the extra compatibles to automatically select the right built-in overlays.

You're going to have a different config anyway, but yeah, that's true.

Quoted 26 lines

Quoted 14 lines

Quoted 4 lines

And we can avoid copy and paste on the dts side by putting all the common stuff in a common file and including that, I believe that that is better (KISS = better) since we've no way to runtime do the right thing AFAICT.

My concern is about the ever-growing number of DTS that just are small variations of one or the other. What about the time when we'll discover that this board has a variant that has an emmc, and some that don't have any button, or the i2c bus 2 not wired, and one other that doesn't have any HDMI?

Do we really want to have a dts called sun8i-a33-q8h-emmc-lcd800x600-nohdmi-noi2c2-nobuttons.dts?

Quoted 7 lines

Especially when we will have the one that we include here that will not have followed this convention because it was introduced before that, and that we have a way to deal with this nicely?

You chose to consider the DTS names an ABI, the best way to handle this is to have a DTS as generic as possible, and leave all these small variations outside of the name.

Ok, so for now this is not really an issue at all since the dts does not yet decribe the lcd at all. So can you merge this one renamed to a more generic name for 4.2?

Quoted 6 lines

That will work fine for now.

Then we can use the DT quirks interface to add different lcd nodes for different variants once we get lcd support in the kernel, and teach u-boot to add the extra board compatible to select the right lcd node at that time.

I think we need to discuss this with Pantelis and what is his feeling about this.

Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment.

I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?)

Signature · 4 lines

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Quoted 15 lines

I think we need to discuss this with Pantelis and what is his feeling about this.

Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment.

Quoted 6 lines

I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?)

First of all, the quirks interface is at an RFC stage (new name suggested is ?variants?); getting that out of the way this seems like what it is designed to do.

The idea of the DT quirks is to drastically cut down on the number of different DTs required, each different for each board with minute differences from one another.

In your case you have boards that have no way to be probed about what they ?are?, but that?s no big problem. You can easily pass the board variant in the kernel command line and use that to select the quirk to apply.

In fact the original patchset does contain a command line quirk for enabling and disabling the onboard emmc & hdmi of the beaglebone black for capes that need to use those signals.

Saying that, if you?re in a hurry I?d say go with a different DTSs for now, since that?s going to go in a near kernel cycle; DT quirks will be discussed at plumber?s in a couple of months, and then we?ll if it will go in and in what form.

Hi Pantelis,

Quoted 26 lines · Pantelis Antoniou

Quoted 15 lines

I think we need to discuss this with Pantelis and what is his feeling about this.

Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment.

Quoted 6 lines

I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?)

First of all, the quirks interface is at an RFC stage (new name suggested is ?variants?); getting that out of the way this seems like what it is designed to do.

Quoted 3 lines

The idea of the DT quirks is to drastically cut down on the number of different DTs required, each different for each board with minute differences from one another.

We're on the same page then :)

Quoted 4 lines

In your case you have boards that have no way to be probed about what they ?are?, but that?s no big problem. You can easily pass the board variant in the kernel command line and use that to select the quirk to apply.

Hans actually pointed out that this would just move the logic somewhere else, but not remove it. In our case, that would mean U-Boot (Hans being the U-Boot maintainer for the SoCs that are used in this particular board).

That would still require us to have a different configuration and to add some logic to pass that extra parameter to the kernel. I'd be glad to have less stuff in the kernel, but I can understand that he doesn't want more stuff either.

Quoted 3 lines

In fact the original patchset does contain a command line quirk for enabling and disabling the onboard emmc & hdmi of the beaglebone black for capes that need to use those signals.

Ah. I somehow overlooked that when reading it.

Quoted 4 lines

Saying that, if you?re in a hurry I?d say go with a different DTSs for now, since that?s going to go in a near kernel cycle; DT quirks will be discussed at plumber?s in a couple of months, and then we?ll if it will go in and in what form.

Ok. I won't be here this year, but if you could raise the topic of how to handle "non-discoverable boards" then, it would be great.

Hans, I guess we can go for your suggestion then: apply a "generic" DT for the board right now, we're going to need it anyway. Then, when will have real display support, depending on the current state of the discussion for the quirks, we will either merge a different DT including the generic one, or if the quirks have something that work for both of us then, use the quirks. Sounds good?

Maxime

Signature · 3 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Hi Maxime,

Quoted 31 lines · Maxime Ripard

Hi Pantelis,

Quoted 26 lines · Pantelis Antoniou

Quoted 15 lines

I think we need to discuss this with Pantelis and what is his feeling about this.

Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment.

Quoted 6 lines

I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?)

First of all, the quirks interface is at an RFC stage (new name suggested is ?variants?); getting that out of the way this seems like what it is designed to do.

Quoted 6 lines

Quoted 3 lines

The idea of the DT quirks is to drastically cut down on the number of different DTs required, each different for each board with minute differences from one another.

We're on the same page then :)

Heh :)

Quoted 10 lines

Quoted 4 lines

In your case you have boards that have no way to be probed about what they ?are?, but that?s no big problem. You can easily pass the board variant in the kernel command line and use that to select the quirk to apply.

Hans actually pointed out that this would just move the logic somewhere else, but not remove it. In our case, that would mean U-Boot (Hans being the U-Boot maintainer for the SoCs that are used in this particular board).

Quoted 5 lines

That would still require us to have a different configuration and to add some logic to pass that extra parameter to the kernel. I'd be glad to have less stuff in the kernel, but I can understand that he doesn't want more stuff either.

Well, I don?t know the specifics of your board, but if you have a configuration subset that works for all the boards and makes it at least possible to load a kernel (i.e. ram, serial, storage) you can keep a single bootloader that?s not full featured, but at least can boot any kind of variant.

Afterwards you can just update the bootargs variable to the correct one for a given board.

Hi,

Quoted 63 lines · Pantelis Antoniou

Hi Maxime,

Quoted 31 lines · Maxime Ripard

Hi Pantelis,

Quoted 26 lines · Pantelis Antoniou

Quoted 15 lines

I think we need to discuss this with Pantelis and what is his feeling about this.

Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment.

Quoted 6 lines

I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?)

First of all, the quirks interface is at an RFC stage (new name suggested is ?variants?); getting that out of the way this seems like what it is designed to do.

Quoted 6 lines

Quoted 3 lines

The idea of the DT quirks is to drastically cut down on the number of different DTs required, each different for each board with minute differences from one another.

We're on the same page then :)

Heh :)

Quoted 10 lines

Quoted 4 lines

In your case you have boards that have no way to be probed about what they ?are?, but that?s no big problem. You can easily pass the board variant in the kernel command line and use that to select the quirk to apply.

Hans actually pointed out that this would just move the logic somewhere else, but not remove it. In our case, that would mean U-Boot (Hans being the U-Boot maintainer for the SoCs that are used in this particular board).

Quoted 5 lines

That would still require us to have a different configuration and to add some logic to pass that extra parameter to the kernel. I'd be glad to have less stuff in the kernel, but I can understand that he doesn't want more stuff either.

Well, I don?t know the specifics of your board, but if you have a configuration subset that works for all the boards and makes it at least possible to load a kernel (i.e. ram, serial, storage) you can keep a single bootloader that?s not full featured, but at least can boot any kind of variant.

Quoted 2 lines

Afterwards you can just update the bootargs variable to the correct one for a given board.

We're talking about tablets here and uboot supports the lcd, as that is the only way to show errors loading the kernel / show a boot menu, etc.

Show u-boot will know which lcd is present (by the user having flashed the right u-boot binary for his model or so we hope). So I really think that this is something which u-boot should pass along in our case.

Talking about how this will all work in the future would it be possible for u-boot to pass this info via devicetree rather then the kernel commandline?

In general we try not to mangle the cmdline in u-boot, while otoh we already patch plenty of stuff into the dtb like memory size and such :)

Regards,

Hans

Hi Pantelis,

Quoted 22 lines · Pantelis Antoniou

Quoted 15 lines

I think we need to discuss this with Pantelis and what is his feeling about this.

Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment.

Quoted 6 lines

I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?)

Quoted 7 lines

First of all, the quirks interface is at an RFC stage (new name suggested is ?variants?); getting that out of the way this seems like what it is designed to do.

The idea of the DT quirks is to drastically cut down on the number of different DTs required, each different for each board with minute differences from one another.

We're on the same page then :)

Quoted 4 lines

In your case you have boards that have no way to be probed about what they ?are?, but that?s no big problem. You can easily pass the board variant in the kernel command line and use that to select the quirk to apply.

Hans actually pointed out that this would just move the logic somewhere else, but not remove it. In our case, that would mean U-Boot (Hans being the U-Boot maintainer for the SoCs that are used in this particular board).

That would still require us to have a different configuration and to add some logic to pass that extra parameter to the kernel. I'd be glad to have less stuff in the kernel, but I can understand that he doesn't want more stuff either.

Quoted 3 lines

In fact the original patchset does contain a command line quirk for enabling and disabling the onboard emmc & hdmi of the beaglebone black for capes that need to use those signals.

Ah. I somehow overlooked that when reading it.

Quoted 4 lines

Saying that, if you?re in a hurry I?d say go with a different DTSs for now, since that?s going to go in a near kernel cycle; DT quirks will be discussed at plumber?s in a couple of months, and then we?ll if it will go in and in what form.

Ok. I won't be here this year, but if you could raise the topic of how to handle "non-discoverable boards" then, it would be great.

Hans, I guess we can go for your suggestion then: apply a "generic" DT for the board right now, we're going to need it anyway. Then, when will have real display support, depending on the current state of the discussion for the quirks, we will either merge a different DT including the generic one, or if the quirks have something that work for both of us then, use the quirks. Sounds good?

Hi,

Quoted 64 lines · Maxime Ripard

Hi Pantelis,

Quoted 22 lines · Pantelis Antoniou

Quoted 15 lines

I think we need to discuss this with Pantelis and what is his feeling about this.

Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment.

Quoted 6 lines

I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?)

Quoted 7 lines

First of all, the quirks interface is at an RFC stage (new name suggested is ?variants?); getting that out of the way this seems like what it is designed to do.

The idea of the DT quirks is to drastically cut down on the number of different DTs required, each different for each board with minute differences from one another.

We're on the same page then :)

Quoted 4 lines

In your case you have boards that have no way to be probed about what they ?are?, but that?s no big problem. You can easily pass the board variant in the kernel command line and use that to select the quirk to apply.

Hans actually pointed out that this would just move the logic somewhere else, but not remove it. In our case, that would mean U-Boot (Hans being the U-Boot maintainer for the SoCs that are used in this particular board).

That would still require us to have a different configuration and to add some logic to pass that extra parameter to the kernel. I'd be glad to have less stuff in the kernel, but I can understand that he doesn't want more stuff either.

Quoted 3 lines

In fact the original patchset does contain a command line quirk for enabling and disabling the onboard emmc & hdmi of the beaglebone black for capes that need to use those signals.

Ah. I somehow overlooked that when reading it.

Quoted 4 lines

Saying that, if you?re in a hurry I?d say go with a different DTSs for now, since that?s going to go in a near kernel cycle; DT quirks will be discussed at plumber?s in a couple of months, and then we?ll if it will go in and in what form.

Ok. I won't be here this year, but if you could raise the topic of how to handle "non-discoverable boards" then, it would be great.

Quoted 6 lines

Hans, I guess we can go for your suggestion then: apply a "generic" DT for the board right now, we're going to need it anyway. Then, when will have real display support, depending on the current state of the discussion for the quirks, we will either merge a different DT including the generic one, or if the quirks have something that work for both of us then, use the quirks. Sounds good?

Sounds good to me, will you make the changes while merging, or shall I do a new version of the patch ?

Hi Maxime,

Here is a cleaned up series of Vishnu Patekar's A33 support. This should address all concerns raised during the posting of v1.

I've tested that all peripherals declared in the shared sun8i-a23-a33.dtsi work on the A33 too, with the exception of the dma-controller. For the dma-controller I've compared the A23 vs A33 manual and the entire dma- controller description including the register description is bit for bit identical.

This has been tested on a 7" Ippo Q8H v1.2 A23 tablet, a 7" Ippo Q8H v1.2 A33 tablet and a 10" GA10H A33 tablet. The dts for the 10" tablet still needs some work wrt the lradc button voltages so that is not included in this set.

Regards,

Hans

--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/d/optout.

Hi Maxime,

Here is a cleaned up series of Vishnu Patekar's A33 support. This should address all concerns raised during the posting of v1.

I've tested that all peripherals declared in the shared sun8i-a23-a33.dtsi work on the A33 too, with the exception of the dma-controller. For the dma-controller I've compared the A23 vs A33 manual and the entire dma- controller description including the register description is bit for bit identical.

This has been tested on a 7" Ippo Q8H v1.2 A23 tablet, a 7" Ippo Q8H v1.2 A33 tablet and a 10" GA10H A33 tablet. The dts for the 10" tablet still needs some work wrt the lradc button voltages so that is not included in this set.

Hi Maxime,

Here is a cleaned up series of Vishnu Patekar's A33 support. This should address all concerns raised during the posting of v1.

I've tested that all peripherals declared in the shared sun8i-a23-a33.dtsi work on the A33 too, with the exception of the dma-controller. For the dma-controller I've compared the A23 vs A33 manual and the entire dma- controller description including the register description is bit for bit identical.

This has been tested on a 7" Ippo Q8H v1.2 A23 tablet, a 7" Ippo Q8H v1.2 A33 tablet and a 10" GA10H A33 tablet. The dts for the 10" tablet still needs some work wrt the lradc button voltages so that is not included in this set.

Regards,

Hans