sunxi: video: Add support for TV (composite) output on H3/H5

In order to avoid future confusion with similary named files, rename tve.c to tve_common.c. New name better represents the fact that this file holds code which can be and will be shared between multiple drivers.

Signed-off-by Jernej Skrabec <[email protected]>

In order to avoid future confusion with similary named files, rename tve.c to tve_common.c. New name better represents the fact that this file holds code which can be and will be shared between multiple drivers.

Signed-off-by Jernej Skrabec <[email protected]>

---

 drivers/video/sunxi/Makefile                | 2 +-
 drivers/video/sunxi/{tve.c => tve_common.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/video/sunxi/{tve.c => tve_common.c} (100%)

In order to avoid future confusion with similary named files, rename tve.c to tve_common.c. New name better represents the fact that this file holds code which can be and will be shared between multiple drivers.

Signed-off-by Jernej Skrabec <[email protected]>

---

 drivers/video/sunxi/Makefile                | 2 +-
 drivers/video/sunxi/{tve.c => tve_common.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/video/sunxi/{tve.c => tve_common.c} (100%)

This commit adds TVE base address for Allwinner H3 and H5 SoCs.

Signed-off-by Jernej Skrabec <[email protected]>

This commit adds TVE base address for Allwinner H3 and H5 SoCs.

Signed-off-by Jernej Skrabec <[email protected]>

---

 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

Extend DE2 driver with support for TVE driver, which will be added in next commit. TVE unit expects data to be in YUV format, so CSC support is also added here.

Note that HDMI driver has higher priority, so TV out is not probed if HDMI monitor is detected.

Signed-off-by Jernej Skrabec <[email protected]>

Extend DE2 driver with support for TVE driver, which will be added in next commit. TVE unit expects data to be in YUV format, so CSC support is also added here.

Note that HDMI driver has higher priority, so TV out is not probed if HDMI monitor is detected.

Signed-off-by Jernej Skrabec <[email protected]>

---

 arch/arm/include/asm/arch-sunxi/display2.h | 17 +++++++++
 drivers/video/sunxi/sunxi_de2.c            | 60 ++++++++++++++++++++++++------
 2 files changed, 65 insertions(+), 12 deletions(-)

Extend DE2 driver with support for TVE driver, which will be added in next commit. TVE unit expects data to be in YUV format, so CSC support is also added here.

Note that HDMI driver has higher priority, so TV out is not probed if HDMI monitor is detected.

Signed-off-by Jernej Skrabec <[email protected]>

---

 arch/arm/include/asm/arch-sunxi/display2.h | 17 +++++++++
 drivers/video/sunxi/sunxi_de2.c            | 60 ++++++++++++++++++++++++------
 2 files changed, 65 insertions(+), 12 deletions(-)

This commit adds support for TV (composite) output.

Because there is no mechanism to select TV standard, PAL is hardcoded.

Quoted 4 lines

This commit adds support for TV (composite) output.

Because there is no mechanism to select TV standard, PAL is hardcoded.

I'd rather use a consistent mechanism with the old driver (even if we only support PAL right now and reject any other option), and using composite-pal as monitor.

Dne ponedeljek, 22. maj 2017 ob 09:35:56 CEST je Maxime Ripard napisal(a):

Quoted 10 lines · Jernej Skrabec

Quoted 4 lines

This commit adds support for TV (composite) output.

Because there is no mechanism to select TV standard, PAL is hardcoded.

I'd rather use a consistent mechanism with the old driver (even if we only support PAL right now and reject any other option), and using composite-pal as monitor.

I have few arguments against that:

1. Code for parsing that env variable is in videomodes.[c|h], which is clearly a part of an older video framework (ctfb). I didn't want to include any legacy code.

2. Even if this code is used for parsing, it would bring a lot of confusion. For now, we can say that docs/README.video does not apply to H3 and newer SoCs. If we implement this only partially, we would need to describe in details which of each setting is honored with the new driver and which not. Even then, a lot of users would skip that description and complain anyway.

3. If anything is done in this direction, I think that it is better to extend DM video framework so other drivers would benefit from that work too.

Hi Jernej,

Quoted 17 lines · Jernej Å krabec

Dne ponedeljek, 22. maj 2017 ob 09:35:56 CEST je Maxime Ripard napisal(a):

Quoted 9 lines · Jernej Skrabec

Quoted 4 lines

This commit adds support for TV (composite) output.

Because there is no mechanism to select TV standard, PAL is hardcoded.

I'd rather use a consistent mechanism with the old driver (even if we only support PAL right now and reject any other option), and using composite-pal as monitor.

I have few arguments against that:

1. Code for parsing that env variable is in videomodes.[c|h], which is clearly a part of an older video framework (ctfb). I didn't want to include any legacy code.

Quoted 6 lines

2. Even if this code is used for parsing, it would bring a lot of confusion. For now, we can say that docs/README.video does not apply to H3 and newer SoCs. If we implement this only partially, we would need to describe in details which of each setting is honored with the new driver and which not. Even then, a lot of users would skip that description and complain anyway.

The issue with this, and we've been bitten very hard on this one with the CHIP, is that you don't really have a clear majority on that one. If you support only PAL, half the world will be left out, and same thing with NTSC (for some reason, we never needed to support the less common ones like PAL-M or NTSC-J, but that just might be because it never really sold that well in those countries, I don't have any numbers on that).

The point is, if you just hardcode PAL for now, you will have half your users complain, and then, when we will introduce NTSC support eventually, we'll have to introduce some mechanism to switch between the two, then we'll probably break the behaviour our users relied on before, making the other half of our users pissed.

I'm not sure this is something we should just discard, or at least the second part. Having the selection mechanism in place, even if we don't support all the settings and just report an error in the logs in such a case address the latter issue.

You'll also need to address how to setup the overscan, since this is really something you want to have very quick.

Quoted 4 lines

3. If anything is done in this direction, I think that it is better to extend DM video framework so other drivers would benefit from that work too.

That makes sense, but again, this is a pre-requisite for me. And it's not that hard to support the video modelines with a device model driver, Linux does it, and you have a string identifier at the beginning of it. It just has to be deterministic, but I don't think this is an issue with U-Boot's DM.

Hi,

Dne torek, 23. maj 2017 ob 22:22:14 CEST je Maxime Ripard napisal(a):

Quoted 45 lines

Hi Jernej,

Quoted 17 lines · Jernej Škrabec

Dne ponedeljek, 22. maj 2017 ob 09:35:56 CEST je Maxime Ripard napisal(a):

Quoted 9 lines · Jernej Skrabec

Quoted 4 lines

This commit adds support for TV (composite) output.

Because there is no mechanism to select TV standard, PAL is hardcoded.

I'd rather use a consistent mechanism with the old driver (even if we only support PAL right now and reject any other option), and using composite-pal as monitor.

I have few arguments against that:

1. Code for parsing that env variable is in videomodes.[c|h], which is clearly a part of an older video framework (ctfb). I didn't want to include any legacy code.

Quoted 6 lines

2. Even if this code is used for parsing, it would bring a lot of confusion. For now, we can say that docs/README.video does not apply to H3 and newer SoCs. If we implement this only partially, we would need to describe in details which of each setting is honored with the new driver and which not. Even then, a lot of users would skip that description and complain anyway.

The issue with this, and we've been bitten very hard on this one with the CHIP, is that you don't really have a clear majority on that one. If you support only PAL, half the world will be left out, and same thing with NTSC (for some reason, we never needed to support the less common ones like PAL-M or NTSC-J, but that just might be because it never really sold that well in those countries, I don't have any numbers on that).

The point is, if you just hardcode PAL for now, you will have half your users complain, and then, when we will introduce NTSC support eventually, we'll have to introduce some mechanism to switch between the two, then we'll probably break the behaviour our users relied on before, making the other half of our users pissed.

I'm not sure this is something we should just discard, or at least the second part. Having the selection mechanism in place, even if we don't support all the settings and just report an error in the logs in such a case address the latter issue.

Quoted 2 lines

You'll also need to address how to setup the overscan, since this is really something you want to have very quick.

Ok, I'm prepared to tackle this. Do you think it is worth to delay driver merge?

Quoted 9 lines

Quoted 3 lines

3. If anything is done in this direction, I think that it is better to extend DM video framework so other drivers would benefit from that work too.

That makes sense, but again, this is a pre-requisite for me. And it's not that hard to support the video modelines with a device model driver, Linux does it, and you have a string identifier at the beginning of it. It just has to be deterministic, but I don't think this is an issue with U-Boot's DM.

Ok, so how do you think we should implement this? If only composite modes are supported in the string, someone might try to set hdmi monitor. Should we just ignore such settings and maybe print a warning?

Also the question for Simon, how should I merge code for parsing video string from drivers/video/videomodes.c to DM video in a way to be useful to most drivers?

I guess this is the first time to support analog video output in DM video driver and there are some things missing such as a way to select TV standard and define overscan.

Or alternatively, I could make just quick edit to sunxi_tve.c driver and directly use old functions as they are. That way we could get something working very quickly, but I don't like much such approach.

Quoted 48 lines · Jernej Škrabec

Hi,

Dne torek, 23. maj 2017 ob 22:22:14 CEST je Maxime Ripard napisal(a):

Quoted 45 lines

Hi Jernej,

Quoted 17 lines · Jernej Škrabec

Dne ponedeljek, 22. maj 2017 ob 09:35:56 CEST je Maxime Ripard napisal(a):

Quoted 9 lines · Jernej Skrabec

Quoted 4 lines

This commit adds support for TV (composite) output.

Because there is no mechanism to select TV standard, PAL is hardcoded.

I'd rather use a consistent mechanism with the old driver (even if we only support PAL right now and reject any other option), and using composite-pal as monitor.

I have few arguments against that:

1. Code for parsing that env variable is in videomodes.[c|h], which is clearly a part of an older video framework (ctfb). I didn't want to include any legacy code.

Quoted 6 lines

2. Even if this code is used for parsing, it would bring a lot of confusion. For now, we can say that docs/README.video does not apply to H3 and newer SoCs. If we implement this only partially, we would need to describe in details which of each setting is honored with the new driver and which not. Even then, a lot of users would skip that description and complain anyway.

The issue with this, and we've been bitten very hard on this one with the CHIP, is that you don't really have a clear majority on that one. If you support only PAL, half the world will be left out, and same thing with NTSC (for some reason, we never needed to support the less common ones like PAL-M or NTSC-J, but that just might be because it never really sold that well in those countries, I don't have any numbers on that).

The point is, if you just hardcode PAL for now, you will have half your users complain, and then, when we will introduce NTSC support eventually, we'll have to introduce some mechanism to switch between the two, then we'll probably break the behaviour our users relied on before, making the other half of our users pissed.

I'm not sure this is something we should just discard, or at least the second part. Having the selection mechanism in place, even if we don't support all the settings and just report an error in the logs in such a case address the latter issue.

Quoted 5 lines

Quoted 2 lines

You'll also need to address how to setup the overscan, since this is really something you want to have very quick.

Ok, I'm prepared to tackle this. Do you think it is worth to delay driver merge?

Not per se, but that should definitely be part of the same release, so if you can make it by then, then we can merge that right now, and merge the rest later. If you can't, then we'll have to postpone it a bit.

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

3. If anything is done in this direction, I think that it is better to extend DM video framework so other drivers would benefit from that work too.

That makes sense, but again, this is a pre-requisite for me. And it's not that hard to support the video modelines with a device model driver, Linux does it, and you have a string identifier at the beginning of it. It just has to be deterministic, but I don't think this is an issue with U-Boot's DM.

Quoted 4 lines

Ok, so how do you think we should implement this? If only composite modes are supported in the string, someone might try to set hdmi monitor. Should we just ignore such settings and maybe print a warning?

I'm not sure it was your question, but I would just reject any improper configuration, and not display anything in such a case.

Quoted 7 lines

Also the question for Simon, how should I merge code for parsing video string from drivers/video/videomodes.c to DM video in a way to be useful to most drivers?

I guess this is the first time to support analog video output in DM video driver and there are some things missing such as a way to select TV standard and define overscan.

I think it can be done in the same way linux does it here:
http://elixir.free-electrons.com/linux/latest/source/drivers/video/fbdev/core/fb_cmdline.c#L35

You basically check first that there is a string matching what your driver expects, and then get the options.

We could imagine having some extra function to parse that string and give back a structure filled with whatever was set in that command line. We could imagine having the common custom properties to be parsed at that same time.

Quoted 3 lines

Or alternatively, I could make just quick edit to sunxi_tve.c driver and directly use old functions as they are. That way we could get something working very quickly, but I don't like much such approach.

That's another approach, I'm fine with it as a temporary measure, but I'm not sure how Simon feels about it.

Maxime

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

Hi Maxime,

Quoted 101 lines · Maxime Ripard

Quoted 48 lines · Jernej Škrabec

Hi,

Dne torek, 23. maj 2017 ob 22:22:14 CEST je Maxime Ripard napisal(a):

Quoted 45 lines

Hi Jernej,

Quoted 17 lines · Jernej Škrabec

Dne ponedeljek, 22. maj 2017 ob 09:35:56 CEST je Maxime Ripard napisal(a):

Quoted 9 lines · Jernej Skrabec

Quoted 4 lines

This commit adds support for TV (composite) output.

Because there is no mechanism to select TV standard, PAL is hardcoded.

I'd rather use a consistent mechanism with the old driver (even if we only support PAL right now and reject any other option), and using composite-pal as monitor.

I have few arguments against that:

1. Code for parsing that env variable is in videomodes.[c|h], which is clearly a part of an older video framework (ctfb). I didn't want to include any legacy code.

Quoted 6 lines

2. Even if this code is used for parsing, it would bring a lot of confusion. For now, we can say that docs/README.video does not apply to H3 and newer SoCs. If we implement this only partially, we would need to describe in details which of each setting is honored with the new driver and which not. Even then, a lot of users would skip that description and complain anyway.

The issue with this, and we've been bitten very hard on this one with the CHIP, is that you don't really have a clear majority on that one. If you support only PAL, half the world will be left out, and same thing with NTSC (for some reason, we never needed to support the less common ones like PAL-M or NTSC-J, but that just might be because it never really sold that well in those countries, I don't have any numbers on that).

The point is, if you just hardcode PAL for now, you will have half your users complain, and then, when we will introduce NTSC support eventually, we'll have to introduce some mechanism to switch between the two, then we'll probably break the behaviour our users relied on before, making the other half of our users pissed.

I'm not sure this is something we should just discard, or at least the second part. Having the selection mechanism in place, even if we don't support all the settings and just report an error in the logs in such a case address the latter issue.

Quoted 5 lines

Quoted 2 lines

You'll also need to address how to setup the overscan, since this is really something you want to have very quick.

Ok, I'm prepared to tackle this. Do you think it is worth to delay driver merge?

Not per se, but that should definitely be part of the same release, so if you can make it by then, then we can merge that right now, and merge the rest later. If you can't, then we'll have to postpone it a bit.

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

3. If anything is done in this direction, I think that it is better to extend DM video framework so other drivers would benefit from that work too.

That makes sense, but again, this is a pre-requisite for me. And it's not that hard to support the video modelines with a device model driver, Linux does it, and you have a string identifier at the beginning of it. It just has to be deterministic, but I don't think this is an issue with U-Boot's DM.

Quoted 4 lines

Ok, so how do you think we should implement this? If only composite modes are supported in the string, someone might try to set hdmi monitor. Should we just ignore such settings and maybe print a warning?

I'm not sure it was your question, but I would just reject any improper configuration, and not display anything in such a case.

Quoted 7 lines

Also the question for Simon, how should I merge code for parsing video string from drivers/video/videomodes.c to DM video in a way to be useful to most drivers?

I guess this is the first time to support analog video output in DM video driver and there are some things missing such as a way to select TV standard and define overscan.

I think it can be done in the same way linux does it here:
http://elixir.free-electrons.com/linux/latest/source/drivers/video/fbdev/core/fb_cmdline.c#L35

You basically check first that there is a string matching what your driver expects, and then get the options.

We could imagine having some extra function to parse that string and give back a structure filled with whatever was set in that command line. We could imagine having the common custom properties to be parsed at that same time.

Quoted 3 lines

Or alternatively, I could make just quick edit to sunxi_tve.c driver and directly use old functions as they are. That way we could get something working very quickly, but I don't like much such approach.

Quoted 2 lines

That's another approach, I'm fine with it as a temporary measure, but I'm not sure how Simon feels about it.

Well how about a function that decodes the string into a struct? That function could be called by any drivers that need it.