Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Hi Tomi, Am 18.11.2013 um 14:29 schrieb Tomi Valkeinen: > On 2013-11-11 16:30, Dr. H. Nikolaus Schaller wrote: > >> Maybe it looks as if it is an unsolvable problem. The OPA works only if >> acbias >> and bypass are enabled, but is not allowed to tell that it is there. > > That's why the board file or dts file is there, to have "glue" data to > make different pieces work together. Our implementation idea was that this makes the board file developer to specify knowlegde that the drivers already could have and to reduce the risk of misconfiguration. So we tried to model the invert property of the connector which is also backpropagated to VENC. But of course there are different ways of doing it and different priorities of contradicting requirements. > > The perfect (?) solution would be a CDF like data. The idea would be > that in the board file, you would describe configuration options for > VENC and for OPA. In this particular case, you'd tell VENC that it needs > to enable acbias and bypass when OPA is to be connected to VENC. Then > there could be more entries for VENC, saying disable acbias and bypass > when BAR is to be connected to VENC. > > However, we don't have such support (yet). > > For now, I hope it's enough if we handle VENC in a "single > configuration" manner, i.e. you'll tell VENC to enable acbias and bypass > when VENC is enabled. This means you can't have board setups where you'd > change the VENC->OPA connection to some other analog tv output at > runtime. I hope that's the case (i.e. OPA is always in use on that board). I also don't think that there is a need for runtime modifications, so your proposal looks ok. > If so, then I think you can just pass the acbias and bypass > configuration values via omapdss platform data. And VENC driver will use > them to configure those. OPA doesn't know anything about this at all. We will change it that way. Do you see a chance to get it into the merge window of 3.13? BR, Nikolaus-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
On 2013-11-11 16:30, Dr. H. Nikolaus Schaller wrote: > Maybe it looks as if it is an unsolvable problem. The OPA works only if acbias > and bypass are enabled, but is not allowed to tell that it is there. That's why the board file or dts file is there, to have "glue" data to make different pieces work together. The perfect (?) solution would be a CDF like data. The idea would be that in the board file, you would describe configuration options for VENC and for OPA. In this particular case, you'd tell VENC that it needs to enable acbias and bypass when OPA is to be connected to VENC. Then there could be more entries for VENC, saying disable acbias and bypass when BAR is to be connected to VENC. However, we don't have such support (yet). For now, I hope it's enough if we handle VENC in a "single configuration" manner, i.e. you'll tell VENC to enable acbias and bypass when VENC is enabled. This means you can't have board setups where you'd change the VENC->OPA connection to some other analog tv output at runtime. I hope that's the case (i.e. OPA is always in use on that board). If so, then I think you can just pass the acbias and bypass configuration values via omapdss platform data. And VENC driver will use them to configure those. OPA doesn't know anything about this at all. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
On 2013-11-11 16:30, Dr. H. Nikolaus Schaller wrote: Maybe it looks as if it is an unsolvable problem. The OPA works only if acbias and bypass are enabled, but is not allowed to tell that it is there. That's why the board file or dts file is there, to have glue data to make different pieces work together. The perfect (?) solution would be a CDF like data. The idea would be that in the board file, you would describe configuration options for VENC and for OPA. In this particular case, you'd tell VENC that it needs to enable acbias and bypass when OPA is to be connected to VENC. Then there could be more entries for VENC, saying disable acbias and bypass when BAR is to be connected to VENC. However, we don't have such support (yet). For now, I hope it's enough if we handle VENC in a single configuration manner, i.e. you'll tell VENC to enable acbias and bypass when VENC is enabled. This means you can't have board setups where you'd change the VENC-OPA connection to some other analog tv output at runtime. I hope that's the case (i.e. OPA is always in use on that board). If so, then I think you can just pass the acbias and bypass configuration values via omapdss platform data. And VENC driver will use them to configure those. OPA doesn't know anything about this at all. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Hi Tomi, Am 18.11.2013 um 14:29 schrieb Tomi Valkeinen: On 2013-11-11 16:30, Dr. H. Nikolaus Schaller wrote: Maybe it looks as if it is an unsolvable problem. The OPA works only if acbias and bypass are enabled, but is not allowed to tell that it is there. That's why the board file or dts file is there, to have glue data to make different pieces work together. Our implementation idea was that this makes the board file developer to specify knowlegde that the drivers already could have and to reduce the risk of misconfiguration. So we tried to model the invert property of the connector which is also backpropagated to VENC. But of course there are different ways of doing it and different priorities of contradicting requirements. The perfect (?) solution would be a CDF like data. The idea would be that in the board file, you would describe configuration options for VENC and for OPA. In this particular case, you'd tell VENC that it needs to enable acbias and bypass when OPA is to be connected to VENC. Then there could be more entries for VENC, saying disable acbias and bypass when BAR is to be connected to VENC. However, we don't have such support (yet). For now, I hope it's enough if we handle VENC in a single configuration manner, i.e. you'll tell VENC to enable acbias and bypass when VENC is enabled. This means you can't have board setups where you'd change the VENC-OPA connection to some other analog tv output at runtime. I hope that's the case (i.e. OPA is always in use on that board). I also don't think that there is a need for runtime modifications, so your proposal looks ok. If so, then I think you can just pass the acbias and bypass configuration values via omapdss platform data. And VENC driver will use them to configure those. OPA doesn't know anything about this at all. We will change it that way. Do you see a chance to get it into the merge window of 3.13? BR, Nikolaus-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
* Dr. H. Nikolaus Schaller [13 06:30]: > Am 11.11.2013 um 15:13 schrieb Tomi Valkeinen: > > On 2013-11-11 15:57, Dr. H. Nikolaus Schaller wrote: > > > > The display.c file is not strictly DSS stuff, but DSS related "glue" for > > the SoC. For example, the muxing of the DSI pads is also done on the > > CONTROL module, and it's also in display.c. > > > > The file is getting a bit large, so I'm not against splitting it. But I > > don't think there's point to add omap3-tvout.c file, which most likely > > will ever contain only that one function. > > Yes that is very likely true. > > The problem is that there is no other official API to modify the DEFCONF1 > register. Therefore we introduced this (propsal). > > Our first idea was a readDEFCONF1() and writeDEFCONF1() and use the > constants (bit patterns) you suggested below. I posted something about accessing the ctrl module regs to the first patch in the series. It's best to set it up as a separate driver for now and then maybe handle it with pinctrl-single,bits when DSS is device tree enabled. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Am 11.11.2013 um 15:13 schrieb Tomi Valkeinen: > On 2013-11-11 15:57, Dr. H. Nikolaus Schaller wrote: >> Hi Tomi, >> >> Am 11.11.2013 um 14:29 schrieb Tomi Valkeinen: >> >>> Hi, >>> >>> On 2013-11-05 09:24, Belisko Marek wrote: Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko wrote: > This patches is adding bypass and acbias functionality to omapdss venc > driver. > In first patch we export updatin bypass and acbias in devconf1 register. > Next patch > add handling for updating in venc driver and last patch add driver for > opa362 which > is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. >>> >>> Sorry, I haven't had time to do much reviewing. >>> >>> The code in omap3-tvout.c should be included in the display.c file, >>> which already contains some things like muxing. >> >> Ok, that might be better - but we were not sure where to place code to >> modify the DEVCONF1 registers. It is not directly DSS related but a special >> control of the OMAP3 SoC. Therefore we think it is better located in >> omap3-tvout.c > > The display.c file is not strictly DSS stuff, but DSS related "glue" for > the SoC. For example, the muxing of the DSI pads is also done on the > CONTROL module, and it's also in display.c. > > The file is getting a bit large, so I'm not against splitting it. But I > don't think there's point to add omap3-tvout.c file, which most likely > will ever contain only that one function. > >>> Also, func(bool, bool) >>> style functions are rather confusing to read. Maybe an enum would be >>> better, so you'd instead have something like: >>> >>> func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) >> >> We have no special preference on that. > > It's just about readability. Which one tells you better what the code does: > > func(true, true); > > or > > func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN); > >>> But the main issue is: while this series probably works well, I really >>> don't like it that the OPA driver needs to pass bypass and acbias. It >>> shouldn't know anything about such things. I'm just not certain how to >>> implement that with the current omapdss driver. >> >> Well, it must know bypass and acbias because it requires the OMAP >> CPU to be configured accordingly. I.e. it is the one who pushes the >> button. Or we get a problem that people might misconfigure it. > > While the omapdss display drivers are currently OMAP specific, I want to > (or at least try to) keep them platform independent. Afaik, acbias and > bypass are OMAP VENC specific things, not something that every SoC with > an analog TV-out have. Thus, the OPA driver should not know about them, > and it should be something that only the DSS glue code in mach-omap2/ > and the venc driver know about. What about calling it prepare_venc_for_external_amplifier (or similar). Then, venc.c can hide that really has to be done and call whatever SoC API is needed to program DEFCONF1? > >> I would see it similar as a driver must be able to control power. Here >> it must be able to control bypass and acbias in a special way that it works. > > The difference is that on all possible SoCs where you could add OPA > chip, you'll need to manage the power for OPA, and it's done in a common > way. Whereas the bypass and acbias are OMAP specific things. > >>> I'll try to find time to think about this more, but I don't think I can >>> merge this for 3.13. >> >> Please take your time. >> >> And please also consider the approach to merge it into 3.13 as it is >> and we can then fix it in the weeks while release candidates are pushed. > > If it was purely omapdss code, I could possibly take it. But it contains > arch/arm code also, and I don't want to cause needless changes on code > that I do not maintain. > > Tomi > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Am 11.11.2013 um 15:13 schrieb Tomi Valkeinen: > On 2013-11-11 15:57, Dr. H. Nikolaus Schaller wrote: >> Hi Tomi, >> >> Am 11.11.2013 um 14:29 schrieb Tomi Valkeinen: >> >>> Hi, >>> >>> On 2013-11-05 09:24, Belisko Marek wrote: Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko wrote: > This patches is adding bypass and acbias functionality to omapdss venc > driver. > In first patch we export updatin bypass and acbias in devconf1 register. > Next patch > add handling for updating in venc driver and last patch add driver for > opa362 which > is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. >>> >>> Sorry, I haven't had time to do much reviewing. >>> >>> The code in omap3-tvout.c should be included in the display.c file, >>> which already contains some things like muxing. >> >> Ok, that might be better - but we were not sure where to place code to >> modify the DEVCONF1 registers. It is not directly DSS related but a special >> control of the OMAP3 SoC. Therefore we think it is better located in >> omap3-tvout.c > > The display.c file is not strictly DSS stuff, but DSS related "glue" for > the SoC. For example, the muxing of the DSI pads is also done on the > CONTROL module, and it's also in display.c. > > The file is getting a bit large, so I'm not against splitting it. But I > don't think there's point to add omap3-tvout.c file, which most likely > will ever contain only that one function. Yes that is very likely true. The problem is that there is no other official API to modify the DEFCONF1 register. Therefore we introduced this (propsal). Our first idea was a readDEFCONF1() and writeDEFCONF1() and use the constants (bit patterns) you suggested below. But we thought that it is not robust enough because a VENC driver or other one could then change bits it is not responsible for. > >>> Also, func(bool, bool) >>> style functions are rather confusing to read. Maybe an enum would be >>> better, so you'd instead have something like: >>> >>> func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) >> >> We have no special preference on that. > > It's just about readability. Which one tells you better what the code does: > > func(true, true); > > or > > func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN); Hm. Depends on. If the func is explaining enough it is clear. Or if I have access to some header file. If I don't, the enum values are probably more readable. > >>> But the main issue is: while this series probably works well, I really >>> don't like it that the OPA driver needs to pass bypass and acbias. It >>> shouldn't know anything about such things. I'm just not certain how to >>> implement that with the current omapdss driver. >> >> Well, it must know bypass and acbias because it requires the OMAP >> CPU to be configured accordingly. I.e. it is the one who pushes the >> button. Or we get a problem that people might misconfigure it. > > While the omapdss display drivers are currently OMAP specific, I want to > (or at least try to) keep them platform independent. Afaik, acbias and > bypass are OMAP VENC specific things, not something that every SoC with > an analog TV-out have. Thus, the OPA driver should not know about them, > and it should be something that only the DSS glue code in mach-omap2/ > and the venc driver know about. Well, there must be a method how the OPA can tell the VENC that it exists and the VENC can tell the SoC DEFCONF1 to enable bias and bypass. > >> I would see it similar as a driver must be able to control power. Here >> it must be able to control bypass and acbias in a special way that it works. > > The difference is that on all possible SoCs where you could add OPA > chip, you'll need to manage the power for OPA, and it's done in a common > way. Whereas the bypass and acbias are OMAP specific things. Maybe it looks as if it is an unsolvable problem. The OPA works only if acbias and bypass are enabled, but is not allowed to tell that it is there. > >>> I'll try to find time to think about this more, but I don't think I can >>> merge this for 3.13. >> >> Please take your time. >> >> And please also consider the approach to merge it into 3.13 as it is >> and we can then fix it in the weeks while release candidates are pushed. > > If it was purely omapdss code, I could possibly take it. But it contains > arch/arm code also, because we think that it is unavoidable (no API to control the DEFCONF1 register exists yet). Maybe one of the omap3 core maintainers can comment as well? > and I don't want to cause needless changes on code > that I do not maintain. Yes, this should be avoided of course. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
On 2013-11-11 15:57, Dr. H. Nikolaus Schaller wrote: > Hi Tomi, > > Am 11.11.2013 um 14:29 schrieb Tomi Valkeinen: > >> Hi, >> >> On 2013-11-05 09:24, Belisko Marek wrote: >>> Hi, >>> >>> ping. >>> >>> On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko wrote: This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. >>> Is there a chance to get this series to 3.13? Thanks. >> >> Sorry, I haven't had time to do much reviewing. >> >> The code in omap3-tvout.c should be included in the display.c file, >> which already contains some things like muxing. > > Ok, that might be better - but we were not sure where to place code to > modify the DEVCONF1 registers. It is not directly DSS related but a special > control of the OMAP3 SoC. Therefore we think it is better located in > omap3-tvout.c The display.c file is not strictly DSS stuff, but DSS related "glue" for the SoC. For example, the muxing of the DSI pads is also done on the CONTROL module, and it's also in display.c. The file is getting a bit large, so I'm not against splitting it. But I don't think there's point to add omap3-tvout.c file, which most likely will ever contain only that one function. >> Also, func(bool, bool) >> style functions are rather confusing to read. Maybe an enum would be >> better, so you'd instead have something like: >> >> func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) > > We have no special preference on that. It's just about readability. Which one tells you better what the code does: func(true, true); or func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN); >> But the main issue is: while this series probably works well, I really >> don't like it that the OPA driver needs to pass bypass and acbias. It >> shouldn't know anything about such things. I'm just not certain how to >> implement that with the current omapdss driver. > > Well, it must know bypass and acbias because it requires the OMAP > CPU to be configured accordingly. I.e. it is the one who pushes the > button. Or we get a problem that people might misconfigure it. While the omapdss display drivers are currently OMAP specific, I want to (or at least try to) keep them platform independent. Afaik, acbias and bypass are OMAP VENC specific things, not something that every SoC with an analog TV-out have. Thus, the OPA driver should not know about them, and it should be something that only the DSS glue code in mach-omap2/ and the venc driver know about. > I would see it similar as a driver must be able to control power. Here > it must be able to control bypass and acbias in a special way that it works. The difference is that on all possible SoCs where you could add OPA chip, you'll need to manage the power for OPA, and it's done in a common way. Whereas the bypass and acbias are OMAP specific things. >> I'll try to find time to think about this more, but I don't think I can >> merge this for 3.13. > > Please take your time. > > And please also consider the approach to merge it into 3.13 as it is > and we can then fix it in the weeks while release candidates are pushed. If it was purely omapdss code, I could possibly take it. But it contains arch/arm code also, and I don't want to cause needless changes on code that I do not maintain. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Hi Tomi, Am 11.11.2013 um 14:29 schrieb Tomi Valkeinen: > Hi, > > On 2013-11-05 09:24, Belisko Marek wrote: >> Hi, >> >> ping. >> >> On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko wrote: >>> This patches is adding bypass and acbias functionality to omapdss venc >>> driver. >>> In first patch we export updatin bypass and acbias in devconf1 register. >>> Next patch >>> add handling for updating in venc driver and last patch add driver for >>> opa362 which >>> is used on gta04 board and set bypass + acbias. >> Is there a chance to get this series to 3.13? Thanks. > > Sorry, I haven't had time to do much reviewing. > > The code in omap3-tvout.c should be included in the display.c file, > which already contains some things like muxing. Ok, that might be better - but we were not sure where to place code to modify the DEVCONF1 registers. It is not directly DSS related but a special control of the OMAP3 SoC. Therefore we think it is better located in omap3-tvout.c > Also, func(bool, bool) > style functions are rather confusing to read. Maybe an enum would be > better, so you'd instead have something like: > > func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) We have no special preference on that. > > But the main issue is: while this series probably works well, I really > don't like it that the OPA driver needs to pass bypass and acbias. It > shouldn't know anything about such things. I'm just not certain how to > implement that with the current omapdss driver. Well, it must know bypass and acbias because it requires the OMAP CPU to be configured accordingly. I.e. it is the one who pushes the button. Or we get a problem that people might misconfigure it. I would see it similar as a driver must be able to control power. Here it must be able to control bypass and acbias in a special way that it works. > I'll try to find time to think about this more, but I don't think I can > merge this for 3.13. Please take your time. And please also consider the approach to merge it into 3.13 as it is and we can then fix it in the weeks while release candidates are pushed. But that is your decision. BR and thanks, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Hi, On 2013-11-05 09:24, Belisko Marek wrote: > Hi, > > ping. > > On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko wrote: >> This patches is adding bypass and acbias functionality to omapdss venc >> driver. >> In first patch we export updatin bypass and acbias in devconf1 register. >> Next patch >> add handling for updating in venc driver and last patch add driver for >> opa362 which >> is used on gta04 board and set bypass + acbias. > Is there a chance to get this series to 3.13? Thanks. Sorry, I haven't had time to do much reviewing. The code in omap3-tvout.c should be included in the display.c file, which already contains some things like muxing. Also, func(bool, bool) style functions are rather confusing to read. Maybe an enum would be better, so you'd instead have something like: func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) But the main issue is: while this series probably works well, I really don't like it that the OPA driver needs to pass bypass and acbias. It shouldn't know anything about such things. I'm just not certain how to implement that with the current omapdss driver. I'll try to find time to think about this more, but I don't think I can merge this for 3.13. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Hi, On 2013-11-05 09:24, Belisko Marek wrote: Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko ma...@goldelico.com wrote: This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. Sorry, I haven't had time to do much reviewing. The code in omap3-tvout.c should be included in the display.c file, which already contains some things like muxing. Also, func(bool, bool) style functions are rather confusing to read. Maybe an enum would be better, so you'd instead have something like: func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) But the main issue is: while this series probably works well, I really don't like it that the OPA driver needs to pass bypass and acbias. It shouldn't know anything about such things. I'm just not certain how to implement that with the current omapdss driver. I'll try to find time to think about this more, but I don't think I can merge this for 3.13. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Hi Tomi, Am 11.11.2013 um 14:29 schrieb Tomi Valkeinen: Hi, On 2013-11-05 09:24, Belisko Marek wrote: Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko ma...@goldelico.com wrote: This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. Sorry, I haven't had time to do much reviewing. The code in omap3-tvout.c should be included in the display.c file, which already contains some things like muxing. Ok, that might be better - but we were not sure where to place code to modify the DEVCONF1 registers. It is not directly DSS related but a special control of the OMAP3 SoC. Therefore we think it is better located in omap3-tvout.c Also, func(bool, bool) style functions are rather confusing to read. Maybe an enum would be better, so you'd instead have something like: func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) We have no special preference on that. But the main issue is: while this series probably works well, I really don't like it that the OPA driver needs to pass bypass and acbias. It shouldn't know anything about such things. I'm just not certain how to implement that with the current omapdss driver. Well, it must know bypass and acbias because it requires the OMAP CPU to be configured accordingly. I.e. it is the one who pushes the button. Or we get a problem that people might misconfigure it. I would see it similar as a driver must be able to control power. Here it must be able to control bypass and acbias in a special way that it works. I'll try to find time to think about this more, but I don't think I can merge this for 3.13. Please take your time. And please also consider the approach to merge it into 3.13 as it is and we can then fix it in the weeks while release candidates are pushed. But that is your decision. BR and thanks, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
On 2013-11-11 15:57, Dr. H. Nikolaus Schaller wrote: Hi Tomi, Am 11.11.2013 um 14:29 schrieb Tomi Valkeinen: Hi, On 2013-11-05 09:24, Belisko Marek wrote: Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko ma...@goldelico.com wrote: This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. Sorry, I haven't had time to do much reviewing. The code in omap3-tvout.c should be included in the display.c file, which already contains some things like muxing. Ok, that might be better - but we were not sure where to place code to modify the DEVCONF1 registers. It is not directly DSS related but a special control of the OMAP3 SoC. Therefore we think it is better located in omap3-tvout.c The display.c file is not strictly DSS stuff, but DSS related glue for the SoC. For example, the muxing of the DSI pads is also done on the CONTROL module, and it's also in display.c. The file is getting a bit large, so I'm not against splitting it. But I don't think there's point to add omap3-tvout.c file, which most likely will ever contain only that one function. Also, func(bool, bool) style functions are rather confusing to read. Maybe an enum would be better, so you'd instead have something like: func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) We have no special preference on that. It's just about readability. Which one tells you better what the code does: func(true, true); or func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN); But the main issue is: while this series probably works well, I really don't like it that the OPA driver needs to pass bypass and acbias. It shouldn't know anything about such things. I'm just not certain how to implement that with the current omapdss driver. Well, it must know bypass and acbias because it requires the OMAP CPU to be configured accordingly. I.e. it is the one who pushes the button. Or we get a problem that people might misconfigure it. While the omapdss display drivers are currently OMAP specific, I want to (or at least try to) keep them platform independent. Afaik, acbias and bypass are OMAP VENC specific things, not something that every SoC with an analog TV-out have. Thus, the OPA driver should not know about them, and it should be something that only the DSS glue code in mach-omap2/ and the venc driver know about. I would see it similar as a driver must be able to control power. Here it must be able to control bypass and acbias in a special way that it works. The difference is that on all possible SoCs where you could add OPA chip, you'll need to manage the power for OPA, and it's done in a common way. Whereas the bypass and acbias are OMAP specific things. I'll try to find time to think about this more, but I don't think I can merge this for 3.13. Please take your time. And please also consider the approach to merge it into 3.13 as it is and we can then fix it in the weeks while release candidates are pushed. If it was purely omapdss code, I could possibly take it. But it contains arch/arm code also, and I don't want to cause needless changes on code that I do not maintain. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Am 11.11.2013 um 15:13 schrieb Tomi Valkeinen: On 2013-11-11 15:57, Dr. H. Nikolaus Schaller wrote: Hi Tomi, Am 11.11.2013 um 14:29 schrieb Tomi Valkeinen: Hi, On 2013-11-05 09:24, Belisko Marek wrote: Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko ma...@goldelico.com wrote: This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. Sorry, I haven't had time to do much reviewing. The code in omap3-tvout.c should be included in the display.c file, which already contains some things like muxing. Ok, that might be better - but we were not sure where to place code to modify the DEVCONF1 registers. It is not directly DSS related but a special control of the OMAP3 SoC. Therefore we think it is better located in omap3-tvout.c The display.c file is not strictly DSS stuff, but DSS related glue for the SoC. For example, the muxing of the DSI pads is also done on the CONTROL module, and it's also in display.c. The file is getting a bit large, so I'm not against splitting it. But I don't think there's point to add omap3-tvout.c file, which most likely will ever contain only that one function. Yes that is very likely true. The problem is that there is no other official API to modify the DEFCONF1 register. Therefore we introduced this (propsal). Our first idea was a readDEFCONF1() and writeDEFCONF1() and use the constants (bit patterns) you suggested below. But we thought that it is not robust enough because a VENC driver or other one could then change bits it is not responsible for. Also, func(bool, bool) style functions are rather confusing to read. Maybe an enum would be better, so you'd instead have something like: func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) We have no special preference on that. It's just about readability. Which one tells you better what the code does: func(true, true); or func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN); Hm. Depends on. If the func is explaining enough it is clear. Or if I have access to some header file. If I don't, the enum values are probably more readable. But the main issue is: while this series probably works well, I really don't like it that the OPA driver needs to pass bypass and acbias. It shouldn't know anything about such things. I'm just not certain how to implement that with the current omapdss driver. Well, it must know bypass and acbias because it requires the OMAP CPU to be configured accordingly. I.e. it is the one who pushes the button. Or we get a problem that people might misconfigure it. While the omapdss display drivers are currently OMAP specific, I want to (or at least try to) keep them platform independent. Afaik, acbias and bypass are OMAP VENC specific things, not something that every SoC with an analog TV-out have. Thus, the OPA driver should not know about them, and it should be something that only the DSS glue code in mach-omap2/ and the venc driver know about. Well, there must be a method how the OPA can tell the VENC that it exists and the VENC can tell the SoC DEFCONF1 to enable bias and bypass. I would see it similar as a driver must be able to control power. Here it must be able to control bypass and acbias in a special way that it works. The difference is that on all possible SoCs where you could add OPA chip, you'll need to manage the power for OPA, and it's done in a common way. Whereas the bypass and acbias are OMAP specific things. Maybe it looks as if it is an unsolvable problem. The OPA works only if acbias and bypass are enabled, but is not allowed to tell that it is there. I'll try to find time to think about this more, but I don't think I can merge this for 3.13. Please take your time. And please also consider the approach to merge it into 3.13 as it is and we can then fix it in the weeks while release candidates are pushed. If it was purely omapdss code, I could possibly take it. But it contains arch/arm code also, because we think that it is unavoidable (no API to control the DEFCONF1 register exists yet). Maybe one of the omap3 core maintainers can comment as well? and I don't want to cause needless changes on code that I do not maintain. Yes, this should be avoided of course. BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Am 11.11.2013 um 15:13 schrieb Tomi Valkeinen: On 2013-11-11 15:57, Dr. H. Nikolaus Schaller wrote: Hi Tomi, Am 11.11.2013 um 14:29 schrieb Tomi Valkeinen: Hi, On 2013-11-05 09:24, Belisko Marek wrote: Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko ma...@goldelico.com wrote: This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. Sorry, I haven't had time to do much reviewing. The code in omap3-tvout.c should be included in the display.c file, which already contains some things like muxing. Ok, that might be better - but we were not sure where to place code to modify the DEVCONF1 registers. It is not directly DSS related but a special control of the OMAP3 SoC. Therefore we think it is better located in omap3-tvout.c The display.c file is not strictly DSS stuff, but DSS related glue for the SoC. For example, the muxing of the DSI pads is also done on the CONTROL module, and it's also in display.c. The file is getting a bit large, so I'm not against splitting it. But I don't think there's point to add omap3-tvout.c file, which most likely will ever contain only that one function. Also, func(bool, bool) style functions are rather confusing to read. Maybe an enum would be better, so you'd instead have something like: func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN) We have no special preference on that. It's just about readability. Which one tells you better what the code does: func(true, true); or func(OMAP_VENC_TVOUTBYPASS | OMAP_VENC_TVACEN); But the main issue is: while this series probably works well, I really don't like it that the OPA driver needs to pass bypass and acbias. It shouldn't know anything about such things. I'm just not certain how to implement that with the current omapdss driver. Well, it must know bypass and acbias because it requires the OMAP CPU to be configured accordingly. I.e. it is the one who pushes the button. Or we get a problem that people might misconfigure it. While the omapdss display drivers are currently OMAP specific, I want to (or at least try to) keep them platform independent. Afaik, acbias and bypass are OMAP VENC specific things, not something that every SoC with an analog TV-out have. Thus, the OPA driver should not know about them, and it should be something that only the DSS glue code in mach-omap2/ and the venc driver know about. What about calling it prepare_venc_for_external_amplifier (or similar). Then, venc.c can hide that really has to be done and call whatever SoC API is needed to program DEFCONF1? I would see it similar as a driver must be able to control power. Here it must be able to control bypass and acbias in a special way that it works. The difference is that on all possible SoCs where you could add OPA chip, you'll need to manage the power for OPA, and it's done in a common way. Whereas the bypass and acbias are OMAP specific things. I'll try to find time to think about this more, but I don't think I can merge this for 3.13. Please take your time. And please also consider the approach to merge it into 3.13 as it is and we can then fix it in the weeks while release candidates are pushed. If it was purely omapdss code, I could possibly take it. But it contains arch/arm code also, and I don't want to cause needless changes on code that I do not maintain. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
* Dr. H. Nikolaus Schaller h...@goldelico.com [13 06:30]: Am 11.11.2013 um 15:13 schrieb Tomi Valkeinen: On 2013-11-11 15:57, Dr. H. Nikolaus Schaller wrote: The display.c file is not strictly DSS stuff, but DSS related glue for the SoC. For example, the muxing of the DSI pads is also done on the CONTROL module, and it's also in display.c. The file is getting a bit large, so I'm not against splitting it. But I don't think there's point to add omap3-tvout.c file, which most likely will ever contain only that one function. Yes that is very likely true. The problem is that there is no other official API to modify the DEFCONF1 register. Therefore we introduced this (propsal). Our first idea was a readDEFCONF1() and writeDEFCONF1() and use the constants (bit patterns) you suggested below. I posted something about accessing the ctrl module regs to the first patch in the series. It's best to set it up as a separate driver for now and then maybe handle it with pinctrl-single,bits when DSS is device tree enabled. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko wrote: > This patches is adding bypass and acbias functionality to omapdss venc driver. > In first patch we export updatin bypass and acbias in devconf1 register. Next > patch > add handling for updating in venc driver and last patch add driver for opa362 > which > is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. > > Marek Belisko (3): > arm: omap2: Export devconf1 bypass and acbias. > video: venc: Add new callback and handling for bypass and acbias > setup. > omapdss: Add OPA362 analog video amplifier driver. > > arch/arm/mach-omap2/Makefile | 2 + > arch/arm/mach-omap2/control.h | 2 + > arch/arm/mach-omap2/omap3-tvout.c | 36 +++ > drivers/video/omap2/displays-new/Kconfig | 6 + > drivers/video/omap2/displays-new/Makefile | 1 + > .../video/omap2/displays-new/amplifier-opa362.c| 294 > + > drivers/video/omap2/dss/venc.c | 21 ++ > include/linux/omap-tvout.h | 14 + > include/video/omap-panel-data.h| 17 ++ > include/video/omapdss.h| 2 + > 10 files changed, 395 insertions(+) > create mode 100644 arch/arm/mach-omap2/omap3-tvout.c > create mode 100644 drivers/video/omap2/displays-new/amplifier-opa362.c > create mode 100644 include/linux/omap-tvout.h > > -- > 1.8.1.2 > Marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
Hi, ping. On Mon, Oct 14, 2013 at 11:02 PM, Marek Belisko ma...@goldelico.com wrote: This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. Is there a chance to get this series to 3.13? Thanks. Marek Belisko (3): arm: omap2: Export devconf1 bypass and acbias. video: venc: Add new callback and handling for bypass and acbias setup. omapdss: Add OPA362 analog video amplifier driver. arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/control.h | 2 + arch/arm/mach-omap2/omap3-tvout.c | 36 +++ drivers/video/omap2/displays-new/Kconfig | 6 + drivers/video/omap2/displays-new/Makefile | 1 + .../video/omap2/displays-new/amplifier-opa362.c| 294 + drivers/video/omap2/dss/venc.c | 21 ++ include/linux/omap-tvout.h | 14 + include/video/omap-panel-data.h| 17 ++ include/video/omapdss.h| 2 + 10 files changed, 395 insertions(+) create mode 100644 arch/arm/mach-omap2/omap3-tvout.c create mode 100644 drivers/video/omap2/displays-new/amplifier-opa362.c create mode 100644 include/linux/omap-tvout.h -- 1.8.1.2 Marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. Marek Belisko (3): arm: omap2: Export devconf1 bypass and acbias. video: venc: Add new callback and handling for bypass and acbias setup. omapdss: Add OPA362 analog video amplifier driver. arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/control.h | 2 + arch/arm/mach-omap2/omap3-tvout.c | 36 +++ drivers/video/omap2/displays-new/Kconfig | 6 + drivers/video/omap2/displays-new/Makefile | 1 + .../video/omap2/displays-new/amplifier-opa362.c| 294 + drivers/video/omap2/dss/venc.c | 21 ++ include/linux/omap-tvout.h | 14 + include/video/omap-panel-data.h| 17 ++ include/video/omapdss.h| 2 + 10 files changed, 395 insertions(+) create mode 100644 arch/arm/mach-omap2/omap3-tvout.c create mode 100644 drivers/video/omap2/displays-new/amplifier-opa362.c create mode 100644 include/linux/omap-tvout.h -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] omapdss: venc: Add support for bypass and acbias.
This patches is adding bypass and acbias functionality to omapdss venc driver. In first patch we export updatin bypass and acbias in devconf1 register. Next patch add handling for updating in venc driver and last patch add driver for opa362 which is used on gta04 board and set bypass + acbias. Marek Belisko (3): arm: omap2: Export devconf1 bypass and acbias. video: venc: Add new callback and handling for bypass and acbias setup. omapdss: Add OPA362 analog video amplifier driver. arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/control.h | 2 + arch/arm/mach-omap2/omap3-tvout.c | 36 +++ drivers/video/omap2/displays-new/Kconfig | 6 + drivers/video/omap2/displays-new/Makefile | 1 + .../video/omap2/displays-new/amplifier-opa362.c| 294 + drivers/video/omap2/dss/venc.c | 21 ++ include/linux/omap-tvout.h | 14 + include/video/omap-panel-data.h| 17 ++ include/video/omapdss.h| 2 + 10 files changed, 395 insertions(+) create mode 100644 arch/arm/mach-omap2/omap3-tvout.c create mode 100644 drivers/video/omap2/displays-new/amplifier-opa362.c create mode 100644 include/linux/omap-tvout.h -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
