| Message ID | 1424261894-24983-2-git-send-email-shobhit.kumar@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Feb 18, 2015 at 1:18 PM, Shobhit Kumar <shobhit.kumar@intel.com> wrote: > Export Panel BACKLIGHT_EN(offset 0x51) and PANEL_EN(offset 0x52) as two > additional GPIOs. Needed by display driver to enable the DSI panel on > BYT platform where the Panel EN/Disable and Backlight control are > routed thorugh CRC PMIC > > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Alexandre Courbot <gnurou@gmail.com> > Cc: Thierry Reding <thierry.reding@gmail.com> > Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> This seems very unintuitive. I have a hard time believeing this: > +#define GPIOPANELCTL 0x51 A special GPIO only designated to panel control? That is totally counter to the *meaning* of "general purpose input/output". It is not general purpose at all, it is special-purpose. If the data sheet says a special-purpose pin is a "GPIO" when it isn't the map of the world (the datasheet terminology) is wrong, not the world, the usage is dedicated for the panel. Look at the usecase, not the name. Obviously that line is only for controlling the backlight, and you should spin a new child device from the Inte SoC PMIC MFD hub and put a driver for it in drivers/video/backlight or wherever this goes. Lee: do you agree? Yours, Linus Walleij
On Fri, 2015-03-06 at 12:04 +0100, Linus Walleij wrote: > On Wed, Feb 18, 2015 at 1:18 PM, Shobhit Kumar <shobhit.kumar@intel.com> wrote: > > > Export Panel BACKLIGHT_EN(offset 0x51) and PANEL_EN(offset 0x52) as two > > additional GPIOs. Needed by display driver to enable the DSI panel on > > BYT platform where the Panel EN/Disable and Backlight control are > > routed thorugh CRC PMIC > > > > Cc: Linus Walleij <linus.walleij@linaro.org> > > Cc: Alexandre Courbot <gnurou@gmail.com> > > Cc: Thierry Reding <thierry.reding@gmail.com> > > Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> > > This seems very unintuitive. I have a hard time believeing this: > > > +#define GPIOPANELCTL 0x51 > > A special GPIO only designated to panel control? That is totally > counter to the *meaning* of "general purpose input/output". > It is not general purpose at all, it is special-purpose. > > If the data sheet says a special-purpose pin is a "GPIO" when > it isn't the map of the world (the datasheet terminology) is wrong, > not the world, the usage is dedicated for the panel. Look > at the usecase, not the name. > > Obviously that line is only for controlling the backlight, and you > should spin a new child device from the Inte SoC PMIC MFD hub > and put a driver for it in drivers/video/backlight or wherever this > goes. There are actually two lines for Panel Power control and Backlight enable/disable. I have already moved towards adding a new Cell device for PWM child device and a new pwm driver for the same. That will take care of backlight thingy. But for the Panel power control, I am at loss for how best to program that. It is not strictly a GPIO but behaves similarly and thought of simply extending existing gpio-crystalcove. My next implementation(not posted yet) is having that exported by adding a lookup table in PMIC MFD probe routine. Regards Shobhit > > Lee: do you agree? > > Yours, > Linus Walleij
On Fri, Mar 6, 2015 at 5:23 PM, Kumar, Shobhit <shobhit.kumar@intel.com> wrote: > There are actually two lines for Panel Power control and Backlight > enable/disable. I have already moved towards adding a new Cell device > for PWM child device and a new pwm driver for the same. That will take > care of backlight thingy. But for the Panel power control, I am at loss > for how best to program that. Isn't it just a very simple regulator (just on/off of fixed voltage) cell? Yours, Linus Walleij
On Mon, 2015-03-09 at 18:15 +0100, Linus Walleij wrote: > On Fri, Mar 6, 2015 at 5:23 PM, Kumar, Shobhit <shobhit.kumar@intel.com> wrote: > > > There are actually two lines for Panel Power control and Backlight > > enable/disable. I have already moved towards adding a new Cell device > > for PWM child device and a new pwm driver for the same. That will take > > care of backlight thingy. But for the Panel power control, I am at loss > > for how best to program that. > > Isn't it just a very simple regulator (just on/off of fixed voltage) cell? > It is just behaving as an output GPIO line and for that reason I feel that rather than adding a new regulator driver, it is better to augment the gpio-crystalcove driver. I am planning to export as GPIO from PMIC MFD driver by way of lookup table and use in display side. Will send RFC patch soon. Backlight control as I said is a new pwm cell. Regards Shobhit > Yours, > Linus Walleij
On Thu, Mar 12, 2015 at 4:06 PM, Kumar, Shobhit <shobhit.kumar@intel.com> wrote: > On Mon, 2015-03-09 at 18:15 +0100, Linus Walleij wrote: >> On Fri, Mar 6, 2015 at 5:23 PM, Kumar, Shobhit <shobhit.kumar@intel.com> wrote: >> >> > There are actually two lines for Panel Power control and Backlight >> > enable/disable. I have already moved towards adding a new Cell device >> > for PWM child device and a new pwm driver for the same. That will take >> > care of backlight thingy. But for the Panel power control, I am at loss >> > for how best to program that. >> >> Isn't it just a very simple regulator (just on/off of fixed voltage) cell? >> > > It is just behaving as an output GPIO line and for that reason I feel > that rather than adding a new regulator driver, I disagree. GPIO reads "general purpose input/output". This is not a GPIO, this is a special purpose thing and IMO it should be modeled directly as a regulator. Yours, Linus Walleij
On Wed, Mar 18, 2015 at 12:50:51PM +0100, Linus Walleij wrote: > On Thu, Mar 12, 2015 at 4:06 PM, Kumar, Shobhit <shobhit.kumar@intel.com> wrote: > > On Mon, 2015-03-09 at 18:15 +0100, Linus Walleij wrote: > >> On Fri, Mar 6, 2015 at 5:23 PM, Kumar, Shobhit <shobhit.kumar@intel.com> wrote: > >> > >> > There are actually two lines for Panel Power control and Backlight > >> > enable/disable. I have already moved towards adding a new Cell device > >> > for PWM child device and a new pwm driver for the same. That will take > >> > care of backlight thingy. But for the Panel power control, I am at loss > >> > for how best to program that. > >> > >> Isn't it just a very simple regulator (just on/off of fixed voltage) cell? > >> > > > > It is just behaving as an output GPIO line and for that reason I feel > > that rather than adding a new regulator driver, > > I disagree. GPIO reads "general purpose input/output". > > This is not a GPIO, this is a special purpose thing and IMO > it should be modeled directly as a regulator. The idea behind reusing gpio was that we can reuse the dynamic lookup stuff so that i915 can find the gpio. And it is a gpio (there's lots more on that chip), it's just that intel tends to hand you recommended board layouts. And there's different ones so only really i915.ko can tell you if it's indeed used to control the panel or not (after consulting a bunch of vbios tables). Regulator seems way too overkill for this, especially since it tends to be a lie on systems where the panel is not connected to that gpio line. And afaiui the point of the regulator subsystem is that you just ask for the regulator for your IP block and then magically get handed the right bit (or a dummy one). This is very much not the case, hw descriptions on x86 in this area are a kludge worse than board tables since we can't even fix up what the bios hands us anywhere. So for me plan B is to just handroll our own thing using the component framework when reusing gpios isn't acceptable. -Daniel
On Wed, Mar 18, 2015 at 2:27 PM, Daniel Vetter <daniel@ffwll.ch> wrote: > On Wed, Mar 18, 2015 at 12:50:51PM +0100, Linus Walleij wrote: >> This is not a GPIO, this is a special purpose thing and IMO >> it should be modeled directly as a regulator. > > The idea behind reusing gpio was that we can reuse the dynamic lookup > stuff so that i915 can find the gpio. (Fixed) regulators also have dynamic lookups so they provide the exact same mechanism of associating themselves to devices. > And it is a gpio (there's lots more > on that chip), Well the other GPIO registers seem to have 8 GPIOs each, so one register control 8 random lines. In this case they obviously put a single bit to control a line out of the PMIC. The register was intended to that purpose only, the register is named PANEL_EN/DISABLE in the refman (right?) and I bet a million to one that the pin on the PMIC and the rail connected to it is also named PANEL_EN/DISABLE or similar. So the hardware engineers had a special purpose in mind for this. Not general purpose (GPIO). > it's just that intel tends to hand you recommended board > layouts. And there's different ones so only really i915.ko can tell you if > it's indeed used to control the panel or not (after consulting a bunch of > vbios tables). What about the schematic or PMIC pinout. I suspect it tells you a lot about the intended usage by calling that pin PANEL_EN or so. I'm not saying other usecases are impossible, all Rube Goldberg machine variants are possible, but are other use cases really realistic amongst implementers? > Regulator seems way too overkill for this, especially since it tends to be > a lie on systems where the panel is not connected to that gpio line. And > afaiui the point of the regulator subsystem is that you just ask for the > regulator for your IP block and then magically get handed the right bit > (or a dummy one). This is very much not the case, hw descriptions on x86 > in this area are a kludge worse than board tables since we can't even fix > up what the bios hands us anywhere. Depends on the intended use case I would say. Regulator isn't overkill if it fits the use case better. And I think you have a power-on delay, typically so that the panel driver cannot immediately start transmitting data to the panel after driving this line high. Probably the panel needs to settle first. This is referred to as a power-on-delay and the regulator framework can handle it for you. I strongly suspect that you would be planting some delay code in the site enabling the GPIO instead maybe already now or when later running into this while enabling suspend/resume or similar power saving mechanisms. That is basically reimplementing some helpful stuff from the regulator framework. > So for me plan B is to just handroll our own thing using the component > framework when reusing gpios isn't acceptable. Let's just figure out if GPIO is the best fit first, or if you actually could be helped by fixed regulators. Yours, Linus Walleij
On Wed, Feb 18, 2015 at 1:18 PM, Shobhit Kumar <shobhit.kumar@intel.com> wrote: > Export Panel BACKLIGHT_EN(offset 0x51) and PANEL_EN(offset 0x52) as two > additional GPIOs. Needed by display driver to enable the DSI panel on > BYT platform where the Panel EN/Disable and Backlight control are > routed thorugh CRC PMIC > > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Alexandre Courbot <gnurou@gmail.com> > Cc: Thierry Reding <thierry.reding@gmail.com> > Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Patch applied, after Daniel convinced me that this is the lesser of several possible evils to the kernel code base. Yours, Linus Walleij
On Wed, 2015-03-25 at 13:27 +0100, Linus Walleij wrote: > On Wed, Feb 18, 2015 at 1:18 PM, Shobhit Kumar <shobhit.kumar@intel.com> wrote: > > > Export Panel BACKLIGHT_EN(offset 0x51) and PANEL_EN(offset 0x52) as two > > additional GPIOs. Needed by display driver to enable the DSI panel on > > BYT platform where the Panel EN/Disable and Backlight control are > > routed thorugh CRC PMIC > > > > Cc: Linus Walleij <linus.walleij@linaro.org> > > Cc: Alexandre Courbot <gnurou@gmail.com> > > Cc: Thierry Reding <thierry.reding@gmail.com> > > Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> > > Patch applied, after Daniel convinced me that this is the lesser > of several possible evils to the kernel code base. > Thanks, but I hope you pulled in the patch from the latest series which only exports one of them not both. Regards Shobhit
On Wed, Mar 25, 2015 at 3:15 PM, Kumar, Shobhit <shobhit.kumar@intel.com> wrote: > On Wed, 2015-03-25 at 13:27 +0100, Linus Walleij wrote: >> On Wed, Feb 18, 2015 at 1:18 PM, Shobhit Kumar <shobhit.kumar@intel.com> wrote: >> >> > Export Panel BACKLIGHT_EN(offset 0x51) and PANEL_EN(offset 0x52) as two >> > additional GPIOs. Needed by display driver to enable the DSI panel on >> > BYT platform where the Panel EN/Disable and Backlight control are >> > routed thorugh CRC PMIC >> > >> > Cc: Linus Walleij <linus.walleij@linaro.org> >> > Cc: Alexandre Courbot <gnurou@gmail.com> >> > Cc: Thierry Reding <thierry.reding@gmail.com> >> > Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> >> >> Patch applied, after Daniel convinced me that this is the lesser >> of several possible evils to the kernel code base. >> > > Thanks, but I hope you pulled in the patch from the latest series which > only exports one of them not both. Ummm I'll double-check. Yours, Linus Walleij
diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c index 3d9e08f..9e94dc64 100644 --- a/drivers/gpio/gpio-crystalcove.c +++ b/drivers/gpio/gpio-crystalcove.c @@ -24,7 +24,7 @@ #include <linux/mfd/intel_soc_pmic.h> #define CRYSTALCOVE_GPIO_NUM 16 -#define CRYSTALCOVE_VGPIO_NUM 94 +#define CRYSTALCOVE_VGPIO_NUM 96 #define UPDATE_IRQ_TYPE BIT(0) #define UPDATE_IRQ_MASK BIT(1) @@ -39,6 +39,7 @@ #define GPIO0P0CTLI 0x33 #define GPIO1P0CTLO 0x3b #define GPIO1P0CTLI 0x43 +#define GPIOPANELCTL 0x51 #define CTLI_INTCNT_DIS (0) #define CTLI_INTCNT_NE (1 << 1) @@ -93,6 +94,11 @@ static inline int to_reg(int gpio, enum ctrl_register reg_type) { int reg; + if (gpio >= 94) { + reg = GPIOPANELCTL + gpio - 94; + return reg; + } + if (reg_type == CTRL_IN) { if (gpio < 8) reg = GPIO0P0CTLI;
Export Panel BACKLIGHT_EN(offset 0x51) and PANEL_EN(offset 0x52) as two additional GPIOs. Needed by display driver to enable the DSI panel on BYT platform where the Panel EN/Disable and Backlight control are routed thorugh CRC PMIC Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> --- drivers/gpio/gpio-crystalcove.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)