* [PATCH v5 02/46] backlight: pwm_bl: remove useless call to pwm_set_period()
From: Boris Brezillon @ 2016-03-30 20:03 UTC (permalink / raw)
To: Thierry Reding, linux-pwm
Cc: Milo Kim, Kamil Debski, Heiko Stuebner, linux-doc, David Airlie,
Mike Turquette, linux-fbdev, dri-devel, linux-kernel, linux-sunxi,
Alexandre Belloni, Daniel Vetter, Lee Jones, linux-clk,
linux-leds, Boris Brezillon, Krzysztof Kozlowski,
linux-samsung-soc, Alexander Shiyan, Jonathan Corbet,
Robert Jarzmik, lm-sensors, linux-rockchip, Chen-Yu Tsai,
Tomi Valkeinen <tomi.valkeinen@
In-Reply-To: <1459368249-13241-1-git-send-email-boris.brezillon@free-electrons.com>
The PWM period will be set when calling pwm_config. Remove this useless
call to pwm_set_period(), which might mess up with the internal PWM state.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
drivers/video/backlight/pwm_bl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 64f9e1b..a33a290 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -313,10 +313,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
* via the PWM lookup table.
*/
pb->period = pwm_get_period(pb->pwm);
- if (!pb->period && (data->pwm_period_ns > 0)) {
+ if (!pb->period && (data->pwm_period_ns > 0))
pb->period = data->pwm_period_ns;
- pwm_set_period(pb->pwm, data->pwm_period_ns);
- }
pb->lth_brightness = data->lth_brightness * (pb->period / pb->scale);
--
2.5.0
^ permalink raw reply related
* [PATCH v5 01/46] pwm: rcar: make use of pwm_is_enabled()
From: Boris Brezillon @ 2016-03-30 20:03 UTC (permalink / raw)
To: Thierry Reding, linux-pwm-u79uwXL29TY76Z2rM5mHXA
Cc: Mike Turquette, Stephen Boyd, linux-clk-u79uwXL29TY76Z2rM5mHXA,
Mark Brown, Liam Girdwood, Kamil Debski,
lm-sensors-GZX6beZjE8VD60Wz+7aTrA, Jean Delvare, Guenter Roeck,
Dmitry Torokhov, linux-input-u79uwXL29TY76Z2rM5mHXA, Bryan Wu,
Richard Purdie, Jacek Anaszewski,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Maxime Ripard, Chen-Yu Tsai,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Joachim Eastwood,
Thomas Petazzoni, Heiko Stuebner,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jingoo Han,
Lee Jones
In-Reply-To: <1459368249-13241-1-git-send-email-boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Commit 5c31252c4a86 ("pwm: Add the pwm_is_enabled() helper") introduced a
new function to test whether a PWM device is enabled or not without
manipulating PWM internal fields.
Hiding this is necessary if we want to smoothly move to the atomic PWM
config approach without impacting PWM drivers.
Fix this driver to use pwm_is_enabled() instead of directly accessing the
->flags field.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
drivers/pwm/pwm-rcar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index 7b8ac06..1c85ecc 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -157,7 +157,7 @@ static int rcar_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
return div;
/* Let the core driver set pwm->period if disabled and duty_ns = 0 */
- if (!test_bit(PWMF_ENABLED, &pwm->flags) && !duty_ns)
+ if (!pwm_is_enabled(pwm) && !duty_ns)
return 0;
rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
--
2.5.0
^ permalink raw reply related
* [PATCH v5 00/46] pwm: add support for atomic update
From: Boris Brezillon @ 2016-03-30 20:03 UTC (permalink / raw)
To: Thierry Reding, linux-pwm
Cc: Milo Kim, Kamil Debski, Heiko Stuebner, linux-doc, David Airlie,
Mike Turquette, linux-fbdev, dri-devel, linux-kernel, linux-sunxi,
Alexandre Belloni, Daniel Vetter, Lee Jones, linux-clk,
linux-leds, Boris Brezillon, Krzysztof Kozlowski,
linux-samsung-soc, Alexander Shiyan, Jonathan Corbet,
Robert Jarzmik, lm-sensors, linux-rockchip, Chen-Yu Tsai,
Tomi Valkeinen <tomi.valkeinen@
Hello,
This series adds support for atomic PWM update, or IOW, the capability
to update all the parameters of a PWM device (enabled/disabled, period,
duty and polarity) in one go.
It also adds support for initial PWM state retrieval (or hardware readout),
which should allow smooth handover between the bootloader and Linux. For
example, critical PWM users (like critical regulators controlled by a PWM)
can query the current PWM state, and adapt the PWM config without having
to disable/enable the PWM, or abruptly change the period/dutycyle/polarity
config.
Thierry, I hope this version meets your expectations, if that's not the
case, could you let me know quickly so I can adjust the implementation
accordingly (I'd really like to get most of those changes in 4.7).
Best Regards,
Boris
Changes since v4:
- introduce pwm_args to expose per-board/platform config
- deprecate non-atomic APIs
- implement non-atomic functions as wrappers around atomic ones
- patch all PWM users to use the atomic API
- rename the ->reset_state() hook into ->get_state()
- drop most acks
- rework PWM config in the pwm-regulator driver
- patch sun4i and sti PWM drivers to support HW readout
Changes since v3:
- rebased on pwm/for-next after pulling 4.4-rc1
- replace direct access to pwm fields by pwm_get/set_xxx() helpers, thus
fixing some build errors
- split changes to allow each maintainer to review/ack or take the
modification through its subsystem
Changes since v2:
- rebased on top of 4.3-rc2
- reintroduced pwm-regulator patches
Changes since v1:
- dropped applied patches
- squashed Heiko's fixes into the rockchip driver changes
- made a few cosmetic changes
- added kerneldoc comments
- added Heiko's patch to display more information in debugfs
- dropped pwm-regulator patches (should be submitted separately)
*** BLURB HERE ***
Boris Brezillon (45):
pwm: rcar: make use of pwm_is_enabled()
backlight: pwm_bl: remove useless call to pwm_set_period()
backlight: lm3630a_bl: stop messing with the pwm->period field
pwm: get rid of pwm->lock
pwm: introduce the pwm_args concept
pwm: use pwm_get/set_xxx() helpers where appropriate
clk: pwm: use pwm_get_args() where appropriate
hwmon: pwm-fan: use pwm_get_args() where appropriate
misc: max77693-haptic: use pwm_get_args() where appropriate
leds: pwm: use pwm_get_args() where appropriate
regulator: pwm: use pwm_get_args() where appropriate
fbdev: ssd1307fb: use pwm_get_args() where appropriate
backlight: pwm_bl: use pwm_get_args() where appropriate
pwm: keep PWM state in sync with hardware state
pwm: introduce the pwm_state concept
pwm: move the enabled/disabled info into pwm_state
pwm: add the PWM initial state retrieval infra
pwm: add the core infrastructure to allow atomic update
pwm: switch to the atomic API
pwm: rockchip: add initial state retrieval
pwm: rockchip: avoid glitches on already running PWMs
pwm: rockchip: add support for atomic update
pwm: sti: add support for initial state retrieval
pwm: sti: avoid glitches on already running PWMs
pwm: sun4i: implement hardware readout
regulator: pwm: adjust PWM config at probe time
regulator: pwm: swith to the atomic PWM API
regulator: pwm: properly initialize the ->state field
regulator: pwm: retrieve correct voltage
pwm: update documentation
pwm: deprecate pwm_config(), pwm_enable() and pwm_disable()
pwm: replace pwm_disable() by pwm_apply_state()
clk: pwm: switch to the atomic API
hwmon: pwm-fan: switch to the atomic API
input: misc: max77693: switch to the atomic API
input: misc: max8997: switch to the atomic PWM API
input: misc: pwm-beeper: switch to the atomic PWM API
leds: pwm: switch to the atomic PWM API
backlight: lm3630a: switch to the atomic PWM API
backlight: lp855x: switch to the atomic PWM API
backlight: lp8788: switch to the atomic PWM API
backlight: pwm_bl: switch to the atomic PWM API
video: ssd1307fb: switch to the atomic PWM API
drm: i915: switch to the atomic PWM API
ARM: s3c24xx: rx1950: switch to the atomic PWM API
Heiko Stübner (1):
pwm: add information about polarity, duty cycle and period to debugfs
Documentation/pwm.txt | 27 +++-
arch/arm/mach-s3c24xx/mach-rx1950.c | 17 +-
drivers/clk/clk-pwm.c | 36 ++++-
drivers/gpu/drm/i915/intel_panel.c | 39 +++--
drivers/hwmon/pwm-fan.c | 88 ++++++----
drivers/input/misc/max77693-haptic.c | 28 +++-
drivers/input/misc/max8997_haptic.c | 23 ++-
drivers/input/misc/pwm-beeper.c | 46 ++++--
drivers/leds/leds-pwm.c | 15 +-
drivers/pwm/core.c | 186 ++++++++++-----------
drivers/pwm/pwm-clps711x.c | 2 +-
drivers/pwm/pwm-crc.c | 2 +-
drivers/pwm/pwm-lpc18xx-sct.c | 9 +-
drivers/pwm/pwm-lpc32xx.c | 9 +-
drivers/pwm/pwm-omap-dmtimer.c | 2 +-
drivers/pwm/pwm-pxa.c | 2 +-
drivers/pwm/pwm-rcar.c | 2 +-
drivers/pwm/pwm-rockchip.c | 156 +++++++++++++++---
drivers/pwm/pwm-spear.c | 9 +-
drivers/pwm/pwm-sti.c | 67 +++++++-
drivers/pwm/pwm-sun4i.c | 73 ++++++---
drivers/pwm/sysfs.c | 98 ++++++++---
drivers/regulator/pwm-regulator.c | 151 ++++++++++++++---
drivers/video/backlight/lm3630a_bl.c | 15 +-
drivers/video/backlight/lp855x_bl.c | 15 +-
drivers/video/backlight/lp8788_bl.c | 17 +-
drivers/video/backlight/pwm_bl.c | 51 +++---
drivers/video/fbdev/ssd1307fb.c | 28 +++-
include/linux/pwm.h | 303 ++++++++++++++++++++++++++---------
29 files changed, 1096 insertions(+), 420 deletions(-)
--
2.5.0
^ permalink raw reply
* [PATCH] omapfb: Fix regulator API abuse in dss.c and hdmi4.c
From: Mark Brown @ 2016-03-30 16:29 UTC (permalink / raw)
To: linux-fbdev
The voltage changing code in this driver is broken and should be
removed. The driver sets a single, exact voltage on probe. Unless
there is a very good reason for this (which should be documented in
comments) constraints like this need to be set via the machine
constraints, voltage setting in a driver is expected to be used in cases
where the voltage varies at runtime.
In addition client drivers should almost never be calling
regulator_can_set_voltage(), if the device needs to set a voltage it
needs to set the voltage and the regulator core will handle the case
where the regulator is fixed voltage. If the driver can skip setting
the voltage it should just never set the voltage.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 9 ---------
drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 9 ---------
2 files changed, 18 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
index 0eec073b3919..cfd0e3d5f36a 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
@@ -1180,15 +1180,6 @@ static int dsi_regulator_init(struct platform_device *dsidev)
return PTR_ERR(vdds_dsi);
}
- if (regulator_can_change_voltage(vdds_dsi)) {
- r = regulator_set_voltage(vdds_dsi, 1800000, 1800000);
- if (r) {
- devm_regulator_put(vdds_dsi);
- DSSERR("can't set the DSI regulator voltage\n");
- return r;
- }
- }
-
dsi->vdds_dsi_reg = vdds_dsi;
return 0;
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
index 7103c659a534..68b5ce1610ea 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
@@ -114,15 +114,6 @@ static int hdmi_init_regulator(void)
return PTR_ERR(reg);
}
- if (regulator_can_change_voltage(reg)) {
- r = regulator_set_voltage(reg, 1800000, 1800000);
- if (r) {
- devm_regulator_put(reg);
- DSSWARN("can't set the regulator voltage\n");
- return r;
- }
- }
-
hdmi.vdda_reg = reg;
return 0;
--
2.8.0.rc3
^ permalink raw reply related
* [PATCH] staging: sm750fb: initialize max_d to maximum D value of 6
From: Colin King @ 2016-03-29 16:53 UTC (permalink / raw)
To: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman, linux-fbdev,
devel
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
max_d is not initialized and should be set to the largest D
value of 6.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/staging/sm750fb/ddk750_chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/sm750fb/ddk750_chip.c b/drivers/staging/sm750fb/ddk750_chip.c
index 95f7cae..f80ee77 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -306,7 +306,7 @@ unsigned int calcPllValue(unsigned int request_orig, pll_value_t *pll)
unsigned int input, request;
unsigned int tmpClock, ret;
const int max_OD = 3;
- int max_d;
+ int max_d = 6;
if (getChipType() = SM750LE) {
/* SM750LE don't have prgrammable PLL and M/N values to work on.
--
2.7.4
^ permalink raw reply related
* Re: [Intel-gfx] [PATCH 1/5] drm: Add new DCS commands in the enum list
From: Jani Nikula @ 2016-03-29 12:43 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel, dri-devel,
intel-gfx
Cc: Deepak M, Daniel Vetter, Andrzej Hajda
In-Reply-To: <1459157327-2443-1-git-send-email-m.deepak@intel.com>
On Mon, 28 Mar 2016, Deepak M <m.deepak@intel.com> wrote:
> Adding new DCS commands which are specified in the
> DCS 1.3 spec related to CABC.
>
> v2: Sorted the Macro`s by value (Andrzej)
Yeah, well, the *new* ones are now sorted, but I'm pretty sure Andrzej
did mean to keep the whole enum sorted.
While at it, the comment could be /* MIPI DCS 1.3 */ to be specific and
useful.
>
> Cc: Andrzej Hajda <a.hajda@samsung.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Suggested-by: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Deepak M <m.deepak@intel.com>
> ---
> include/video/mipi_display.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
> index ddcc8ca..6831c84 100644
> --- a/include/video/mipi_display.h
> +++ b/include/video/mipi_display.h
> @@ -117,6 +117,14 @@ enum {
> MIPI_DCS_GET_SCANLINE = 0x45,
> MIPI_DCS_READ_DDB_START = 0xA1,
> MIPI_DCS_READ_DDB_CONTINUE = 0xA8,
> + MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51, /*Spec 1.3*/
> + MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52, /*Spec 1.3*/
> + MIPI_DCS_WRITE_CONTROL_DISPLAY = 0x53, /*Spec 1.3*/
> + MIPI_DCS_GET_CONTROL_DISPLAY = 0x54, /*Spec 1.3*/
> + MIPI_DCS_WRITE_POWER_SAVE = 0x55, /*Spec 1.3*/
> + MIPI_DCS_GET_POWER_SAVE = 0x56, /*Spec 1.3*/
> + MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E, /*Spec 1.3*/
> + MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F, /*Spec 1.3*/
> };
>
> /* MIPI DCS pixel formats */
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* [PATCH 1/5] drm: Add new DCS commands in the enum list
From: Deepak M @ 2016-03-28 9:40 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel, dri-devel,
intel-gfx
Cc: Deepak M, Andrzej Hajda, Thierry Reding, David Airlie,
Ville Syrjälä, Daniel Vetter
Adding new DCS commands which are specified in the
DCS 1.3 spec related to CABC.
v2: Sorted the Macro`s by value (Andrzej)
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Deepak M <m.deepak@intel.com>
---
include/video/mipi_display.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
index ddcc8ca..6831c84 100644
--- a/include/video/mipi_display.h
+++ b/include/video/mipi_display.h
@@ -117,6 +117,14 @@ enum {
MIPI_DCS_GET_SCANLINE = 0x45,
MIPI_DCS_READ_DDB_START = 0xA1,
MIPI_DCS_READ_DDB_CONTINUE = 0xA8,
+ MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51, /*Spec 1.3*/
+ MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52, /*Spec 1.3*/
+ MIPI_DCS_WRITE_CONTROL_DISPLAY = 0x53, /*Spec 1.3*/
+ MIPI_DCS_GET_CONTROL_DISPLAY = 0x54, /*Spec 1.3*/
+ MIPI_DCS_WRITE_POWER_SAVE = 0x55, /*Spec 1.3*/
+ MIPI_DCS_GET_POWER_SAVE = 0x56, /*Spec 1.3*/
+ MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E, /*Spec 1.3*/
+ MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F, /*Spec 1.3*/
};
/* MIPI DCS pixel formats */
--
1.9.1
^ permalink raw reply related
* [PATCH 5/5] drm/i915: Add support for new aspect ratios
From: Shashank Sharma @ 2016-03-25 8:29 UTC (permalink / raw)
To: dri-devel, airlied, linux-fbdev; +Cc: daniel.vetter, intel-gfx, plagnioj
In-Reply-To: <1458893855-3930-1-git-send-email-shashank.sharma@intel.com>
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds support for these aspect ratios in
I915 driver, at various places.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
drivers/gpu/drm/drm_modes.c | 12 ++++++++++++
drivers/gpu/drm/i915/intel_hdmi.c | 6 ++++++
drivers/gpu/drm/i915/intel_sdvo.c | 6 ++++++
3 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 6e66136..11f219a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1482,6 +1482,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PAR16_9;
break;
+ case HDMI_PICTURE_ASPECT_64_27:
+ out->flags |= DRM_MODE_FLAG_PAR64_27;
+ break;
+ case DRM_MODE_PICTURE_ASPECT_256_135:
+ out->flags |= DRM_MODE_FLAG_PAR256_135;
+ break;
case HDMI_PICTURE_ASPECT_NONE:
case HDMI_PICTURE_ASPECT_RESERVED:
default:
@@ -1544,6 +1550,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PAR16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+ case DRM_MODE_FLAG_PAR64_27:
+ out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+ break;
+ case DRM_MODE_FLAG_PAR256_135:
+ out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+ break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
}
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index e2dab48..bc8e2c8 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1545,6 +1545,12 @@ intel_hdmi_set_property(struct drm_connector *connector,
case DRM_MODE_PICTURE_ASPECT_16_9:
intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
break;
+ case DRM_MODE_PICTURE_ASPECT_64_27:
+ intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_64_27;
+ break;
+ case DRM_MODE_PICTURE_ASPECT_256_135:
+ intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_256_135;
+ break;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c
index fae64bc..370e4f9 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -2071,6 +2071,12 @@ intel_sdvo_set_property(struct drm_connector *connector,
case DRM_MODE_PICTURE_ASPECT_16_9:
intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
break;
+ case DRM_MODE_PICTURE_ASPECT_64_27:
+ intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_64_27;
+ break;
+ case DRM_MODE_PICTURE_ASPECT_256_135:
+ intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_256_135;
+ break;
default:
return -EINVAL;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 4/5] drm: Add flags for new aspect ratios
From: Shashank Sharma @ 2016-03-25 8:29 UTC (permalink / raw)
To: dri-devel, airlied, linux-fbdev; +Cc: daniel.vetter, intel-gfx, plagnioj
In-Reply-To: <1458893855-3930-1-git-send-email-shashank.sharma@intel.com>
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds DRM flags for the new aspect ratios
in the existing aspect ratio flags.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
include/uapi/drm/drm_mode.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 0dc9f6b..05a808d 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -77,6 +77,8 @@
#define DRM_MODE_PICTURE_ASPECT_NONE 0
#define DRM_MODE_PICTURE_ASPECT_4_3 1
#define DRM_MODE_PICTURE_ASPECT_16_9 2
+#define DRM_MODE_PICTURE_ASPECT_64_27 3
+#define DRM_MODE_PICTURE_ASPECT_256_135 4
/* Aspect ratio flag bitmask (4 bits 21:19) */
#define DRM_MODE_FLAG_PARMASK (0x0F<<19)
@@ -86,6 +88,10 @@
(DRM_MODE_PICTURE_ASPECT_4_3 << 19)
#define DRM_MODE_FLAG_PAR16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9 << 19)
+#define DRM_MODE_FLAG_PAR64_27 \
+ (DRM_MODE_PICTURE_ASPECT_64_27 << 19)
+#define DRM_MODE_FLAG_PAR256_135 \
+ (DRM_MODE_PICTURE_ASPECT_256_135 << 19)
/* DPMS flags */
/* bit compatible with the xorg definitions. */
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] video: Add new aspect ratios for HDMI 2.0
From: Shashank Sharma @ 2016-03-25 8:29 UTC (permalink / raw)
To: dri-devel, airlied, linux-fbdev; +Cc: daniel.vetter, intel-gfx, plagnioj
In-Reply-To: <1458893855-3930-1-git-send-email-shashank.sharma@intel.com>
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
drivers/video/hdmi.c | 4 ++++
include/linux/hdmi.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..1cf907e 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect picture_aspect)
return "4:3";
case HDMI_PICTURE_ASPECT_16_9:
return "16:9";
+ case HDMI_PICTURE_ASPECT_64_27:
+ return "64:27";
+ case HDMI_PICTURE_ASPECT_256_135:
+ return "256:135";
case HDMI_PICTURE_ASPECT_RESERVED:
return "Reserved";
}
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..edbb4fc 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
HDMI_PICTURE_ASPECT_NONE,
HDMI_PICTURE_ASPECT_4_3,
HDMI_PICTURE_ASPECT_16_9,
+ HDMI_PICTURE_ASPECT_64_27,
+ HDMI_PICTURE_ASPECT_256_135,
HDMI_PICTURE_ASPECT_RESERVED,
};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/5] drm: Add aspect ratio parsing in DRM layer
From: Shashank Sharma @ 2016-03-25 8:29 UTC (permalink / raw)
To: dri-devel, airlied, linux-fbdev; +Cc: daniel.vetter, intel-gfx, plagnioj
In-Reply-To: <1458893855-3930-1-git-send-email-shashank.sharma@intel.com>
Current DRM layer functions dont parse aspect ratio information
while converting a user mode->kernel mode or viceversa. This
causes modeset to pick mode with wrong aspect ratio, eventually
cauing failures in HDMI compliance test cases, due to wrong VIC.
This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Lin, Jia <lin.a.jia@intel.com>
Signed-off-by: Akashdeep Sharma <akashdeep.sharma@intel.com>
---
drivers/gpu/drm/drm_modes.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f7448a5..6e66136 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -939,6 +939,9 @@ bool drm_mode_equal_no_clocks(const struct drm_display_mode *mode1, const struct
(mode2->flags & DRM_MODE_FLAG_3D_MASK))
return false;
+ if (mode1->picture_aspect_ratio != mode2->picture_aspect_ratio)
+ return false;
+
return drm_mode_equal_no_clocks_no_stereo(mode1, mode2);
}
EXPORT_SYMBOL(drm_mode_equal_no_clocks);
@@ -967,6 +970,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode *mode1,
mode1->vsync_end = mode2->vsync_end &&
mode1->vtotal = mode2->vtotal &&
mode1->vscan = mode2->vscan &&
+ mode1->picture_aspect_ratio = mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) =
(mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1469,6 +1473,22 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+ out->flags &= ~DRM_MODE_FLAG_PARMASK;
+
+ switch (in->picture_aspect_ratio) {
+ case HDMI_PICTURE_ASPECT_4_3:
+ out->flags |= DRM_MODE_FLAG_PAR4_3;
+ break;
+ case HDMI_PICTURE_ASPECT_16_9:
+ out->flags |= DRM_MODE_FLAG_PAR16_9;
+ break;
+ case HDMI_PICTURE_ASPECT_NONE:
+ case HDMI_PICTURE_ASPECT_RESERVED:
+ default:
+ out->flags |= DRM_MODE_FLAG_PARNONE;
+ break;
+ }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
}
@@ -1514,6 +1534,20 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
+ /* Clearing picture aspect ratio bits from out flags */
+ out->flags &= ~DRM_MODE_FLAG_PARMASK;
+
+ switch (in->flags & DRM_MODE_FLAG_PARMASK) {
+ case DRM_MODE_FLAG_PAR4_3:
+ out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+ break;
+ case DRM_MODE_FLAG_PAR16_9:
+ out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+ break;
+ default:
+ out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+ }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/5] drm: add picture aspect ratio flags
From: Shashank Sharma @ 2016-03-25 8:29 UTC (permalink / raw)
To: dri-devel, airlied, linux-fbdev; +Cc: daniel.vetter, intel-gfx, plagnioj
In-Reply-To: <1458893855-3930-1-git-send-email-shashank.sharma@intel.com>
This patch adds drm flag bits for aspect ratio information
Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
include/uapi/drm/drm_mode.h | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index c021743..0dc9f6b 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -73,6 +73,19 @@
#define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14)
#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (8<<14)
+/* Picture aspect ratio options */
+#define DRM_MODE_PICTURE_ASPECT_NONE 0
+#define DRM_MODE_PICTURE_ASPECT_4_3 1
+#define DRM_MODE_PICTURE_ASPECT_16_9 2
+
+/* Aspect ratio flag bitmask (4 bits 21:19) */
+#define DRM_MODE_FLAG_PARMASK (0x0F<<19)
+#define DRM_MODE_FLAG_PARNONE \
+ (DRM_MODE_PICTURE_ASPECT_NONE << 19)
+#define DRM_MODE_FLAG_PAR4_3 \
+ (DRM_MODE_PICTURE_ASPECT_4_3 << 19)
+#define DRM_MODE_FLAG_PAR16_9 \
+ (DRM_MODE_PICTURE_ASPECT_16_9 << 19)
/* DPMS flags */
/* bit compatible with the xorg definitions. */
@@ -88,11 +101,6 @@
#define DRM_MODE_SCALE_CENTER 2 /* Centered, no scaling */
#define DRM_MODE_SCALE_ASPECT 3 /* Full screen, preserve aspect */
-/* Picture aspect ratio options */
-#define DRM_MODE_PICTURE_ASPECT_NONE 0
-#define DRM_MODE_PICTURE_ASPECT_4_3 1
-#define DRM_MODE_PICTURE_ASPECT_16_9 2
-
/* Dithering mode options */
#define DRM_MODE_DITHERING_OFF 0
#define DRM_MODE_DITHERING_ON 1
--
1.9.1
^ permalink raw reply related
* [PATCH 0/5] Add aspect ratio parsing
From: Shashank Sharma @ 2016-03-25 8:29 UTC (permalink / raw)
To: dri-devel, airlied, linux-fbdev; +Cc: daniel.vetter, intel-gfx, plagnioj
Currently DRM framework doesn't parse aspect ratio of a videomode
while converting it from a umode->kmode or viceversa. This causes
modeset of CEA modes with incorrect aspect ratio.
While running HDMI complaince, tests (like 7-27) expect the DUT
to apply the mode as per the VIC, but as driver does not consider
the aspect ratio part while searching a mode from modedb, we end
up setting mode with a wrong VIC, causing the test to fail.
What this patch set does:
Patch 1-2
- Adds aspect ratio flags in the DRM layer, in form of flags.
- Adds parsing of aspect ratio, during conversion of a umode->kmode
and viceversa.
- Adds aspect ratio check while finding a mode, during modeset.
Patch 3-5
- Adds some new aspect ratio defined in CEA-861-F specs to
support HDMI 2.0 displays, in DRM and I915 layer.
Shashank Sharma (5):
drm: add picture aspect ratio flags
drm: Add aspect ratio parsing in DRM layer
video: Add new aspect ratios for HDMI 2.0
drm: Add flags for new aspect ratios
drm/i915: Add support for new aspect ratios
drivers/gpu/drm/drm_modes.c | 46 +++++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/intel_hdmi.c | 6 +++++
drivers/gpu/drm/i915/intel_sdvo.c | 6 +++++
drivers/video/hdmi.c | 4 ++++
include/linux/hdmi.h | 2 ++
include/uapi/drm/drm_mode.h | 24 +++++++++++++++-----
6 files changed, 83 insertions(+), 5 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCHv2] fbdev: ssd1307fb: Fix charge pump setting
From: Julian Scheel @ 2016-03-24 21:14 UTC (permalink / raw)
To: linux-fbdev
Make sure bit 4 is set for the charge pump setting. It is required according
to SSD1306 App Note.
Signed-off-by: Julian Scheel <julian@jusst.de>
---
Changes in v2:
- Simplify commit message
- Use BIT macros to increase readability
---
drivers/video/fbdev/ssd1307fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 1611215..3b9ee0c 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -389,7 +389,7 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
return ret;
ret = ssd1307fb_write_cmd(par->client,
- (par->device_info->need_chargepump & 0x1 << 2) & 0x14);
+ BIT(4) | (par->device_info->need_chargepump ? BIT(2) : 0));
if (ret < 0)
return ret;
--
2.7.0
^ permalink raw reply related
* Re: [Intel-gfx] [PATCH 1/3] drm: Add new DCS commands in the enum list
From: Jani Nikula @ 2016-03-24 10:34 UTC (permalink / raw)
To: intel-gfx
Cc: linux-fbdev, Deepak M, dri-devel, David Airlie, Tomi Valkeinen,
Thierry Reding, Daniel Vetter, Jean-Christophe Plagniol-Villard
In-Reply-To: <1458813835-7626-1-git-send-email-m.deepak@intel.com>
On Thu, 24 Mar 2016, Deepak M <m.deepak@intel.com> wrote:
> Adding new DCS commands which are specified in the
> DCS 1.3 spec related to CABC.
>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Suggested-by: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Deepak M <m.deepak@intel.com>
Deepak, for future reference, please use scripts/get_maintainer.pl to
see whom you should include for patches touching code outside of i915.
The commands added match the MIPI DCS 1.3 spec,
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Jean-Christophe, Tomi, may I have your acks for merging this via
drm/i915 tree?
BR,
Jani.
> ---
> include/video/mipi_display.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
> index ddcc8ca..bb8195b 100644
> --- a/include/video/mipi_display.h
> +++ b/include/video/mipi_display.h
> @@ -117,6 +117,14 @@ enum {
> MIPI_DCS_GET_SCANLINE = 0x45,
> MIPI_DCS_READ_DDB_START = 0xA1,
> MIPI_DCS_READ_DDB_CONTINUE = 0xA8,
> + MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52,
> + MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F,
> + MIPI_DCS_GET_POWER_SAVE = 0x56,
> + MIPI_DCS_GET_CONTROL_DISPLAY = 0x54,
> + MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51,
> + MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E,
> + MIPI_DCS_WRITE_POWER_SAVE = 0x55,
> + MIPI_DCS_WRITE_CONTROL_DISPLAY = 0x53,
> };
>
> /* MIPI DCS pixel formats */
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* Problems using fb_deferred_io with drm_fb_cma_helper
From: Noralf Trønnes @ 2016-03-23 15:25 UTC (permalink / raw)
To: linux-fbdev
I'm trying to add deferred io support to
drivers/gpu/drm/drm_gem_cma_helper.c.
This is a fbdev helper for DRM.
The first problem is that fb_deferred_io_page() requires either a vmalloc
address or a physical address:
if (is_vmalloc_addr(screen_base + offs))
page = vmalloc_to_page(screen_base + offs);
else
page = pfn_to_page((info->fix.smem_start + offs) >>
PAGE_SHIFT);
However drm_fb_cma_helper allocates memory this way:
cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
&cma_obj->paddr, GFP_KERNEL | __GFP_NOWARN);
The name paddr is somewhat misleading here since this is the device address
which isn't always the same as the physical address (Raspberry Pi). Is
there a way to turn the virtual address into a physical one which will work
on all architectures?
I use __va() now, but that is marked as not for use by drivers in
arch/arm/include/asm/memory.h (the same goes for virt_to_phys).
Maybe this is valid for all? page_to_phys(virt_to_page(x))
I have looked at all the users of fb_deferred_io_init() and found only
3 drivers that doesn't use a vmalloc screen buffer:
drivers/gpu/drm/udl/udl_fb.c:
obj->vmapping = vmap(obj->pages, page_count, 0, PAGE_KERNEL);
info->screen_base = ufbdev->ufb.obj->vmapping;
info->fix.smem_start = (unsigned long)ufbdev->ufb.obj->vmapping;
Since it uses vmap() I guess it is_vmalloc_addr().
drivers/video/fbdev/sh_mobile_lcdcfb.c:
ch->fb_mem = dma_alloc_coherent(dev, ch->fb_size, &ch->dma_handle,
GFP_KERNEL);
info->screen_base = ch->fb_mem;
info->fix.smem_start = ch->dma_handle;
It uses dma_mmap_coherent() in it's fb_mmap function, but nothing special
with it's deferred_io use.
drivers/video/fbdev/ssd1307fb.c:
vmem = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
get_order(vmem_size));
info->screen_base = (u8 __force __iomem *)vmem;
info->fix.smem_start = __pa(vmem);
So maybe this could be possible:
static struct page *fb_deferred_io_page(struct fb_info *info, unsigned
long offs)
{
void *screen_base = (void __force *) info->screen_base;
struct page *page;
if (is_vmalloc_addr(screen_base + offs))
page = vmalloc_to_page(screen_base + offs);
else
- page = pfn_to_page((info->fix.smem_start + offs) >> PAGE_SHIFT);
+ page = virt_to_page(screen_base + offs);
return page;
}
The second problem I'm facing is that I get short horizontal lines that have
old pixels. My problem goes away if I add this to fb_deferred_io_mmap():
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
Is there a way to add this to fb_deferred_io_mmap() with some kind of if
statement, or perhaps export the function so I can use it like this:
static int drm_fbdev_cma_defio_mmap(struct fb_info *info,
struct vm_area_struct *vma)
{
fb_deferred_io_mmap(info, vma);
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
return 0;
}
Thanks,
Noralf Trønnes
^ permalink raw reply
* [PATCH] omapfb: panel-sharp-ls037v7dw01: fix check of gpio_to_desc() return value
From: Vladimir Zapolskiy @ 2016-03-22 22:51 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard
Cc: linux-omap, linux-fbdev, linux-kernel
The change fixes a check of gpio_to_desc() return value, the function
returns either a valid pointer to struct gpio_desc or NULL, this makes
IS_ERR() check invalid and may lead to a NULL pointer dereference in
runtime.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
.../fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c b/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c
index abfd1f6..1954ec9 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c
@@ -200,20 +200,16 @@ static struct omap_dss_driver sharp_ls_ops = {
static int sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long flags,
char *desc, struct gpio_desc **gpiod)
{
- struct gpio_desc *gd;
int r;
- *gpiod = NULL;
-
r = devm_gpio_request_one(dev, gpio, flags, desc);
- if (r)
+ if (r) {
+ *gpiod = NULL;
return r = -ENOENT ? 0 : r;
+ }
- gd = gpio_to_desc(gpio);
- if (IS_ERR(gd))
- return PTR_ERR(gd) = -ENOENT ? 0 : PTR_ERR(gd);
+ *gpiod = gpio_to_desc(gpio);
- *gpiod = gd;
return 0;
}
--
2.1.4
^ permalink raw reply related
* RE: RE
From: Robert @ 2016-03-19 10:06 UTC (permalink / raw)
To: linux-fbdev
Please confirm receipt of my previous mail..When can i call you
^ permalink raw reply
* Re: [PATCH v2 1/2] video: goldfishfb: add devicetree bindings
From: Rob Herring @ 2016-03-18 16:23 UTC (permalink / raw)
To: Alan
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, tomi.valkeinen-l0cyMroinI0,
plagnioj-sclMFOaUSTBWk0Htik3J/w
In-Reply-To: <20160310153845.8996.17736.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Thu, Mar 10, 2016 at 03:39:00PM +0000, Alan wrote:
> From: Greg Hackmann <ghackmann@google.com>
>
> Add device tree bindings to the Goldfish frame buffer interface.
>
> Signed-off-by: Greg Hackmann <ghackmann@google.com>
> Signed-off-by: Jin Qian <jinqian@android.com>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> ---
[...]
> diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
> index 7f6c9e6..f0e651b 100644
> --- a/drivers/video/fbdev/goldfishfb.c
> +++ b/drivers/video/fbdev/goldfishfb.c
> @@ -304,12 +304,19 @@ static int goldfish_fb_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct of_device_id goldfish_fb_of_match[] = {
> + { .compatible = "google,goldfish-fb", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, goldfish_fb_of_match);
>
> static struct platform_driver goldfish_fb_driver = {
> .probe = goldfish_fb_probe,
> .remove = goldfish_fb_remove,
> .driver = {
> - .name = "goldfish_fb"
> + .name = "goldfish_fb",
> + .owner = THIS_MODULE,
This can be dropped. Otherwise,
Acked-by: Rob Herring <robh@kernel.org>
> + .of_match_table = goldfish_fb_of_match,
> }
> };
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 01/24] pwm: rcar: make use of pwm_is_enabled()
From: Boris Brezillon @ 2016-03-16 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1447664207-24370-2-git-send-email-boris.brezillon@free-electrons.com>
Hi Thierry,
Can you please apply this patch?
It's completely independent from the rest of the series.
Thanks,
Boris
On Mon, 16 Nov 2015 09:56:24 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> Commit 5c31252c4a86 ("pwm: Add the pwm_is_enabled() helper") introduced a
> new function to test whether a PWM device is enabled or not without
> manipulating PWM internal fields.
> Hiding this is necessary if we want to smoothly move to the atomic PWM
> config approach without impacting PWM drivers.
> Fix this driver to use pwm_is_enabled() instead of directly accessing the
> ->flags field.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> drivers/pwm/pwm-rcar.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
> index 6e99a63..70899c9 100644
> --- a/drivers/pwm/pwm-rcar.c
> +++ b/drivers/pwm/pwm-rcar.c
> @@ -157,7 +157,7 @@ static int rcar_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> return div;
>
> /* Let the core driver set pwm->period if disabled and duty_ns = 0 */
> - if (!test_bit(PWMF_ENABLED, &pwm->flags) && !duty_ns)
> + if (!pwm_is_enabled(pwm) && !duty_ns)
> return 0;
>
> rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/2] fbdev: sh_mobile_meram: use ARCH_RENESAS
From: Magnus Damm @ 2016-03-16 6:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1457663298-31973-2-git-send-email-horms+renesas@verge.net.au>
Hi Simon,
On Mon, Mar 14, 2016 at 9:13 AM, Simon Horman <horms@verge.net.au> wrote:
> On Fri, Mar 11, 2016 at 08:55:36AM +0100, Geert Uytterhoeven wrote:
>> Hi Simon,
>>
>> On Fri, Mar 11, 2016 at 3:28 AM, Simon Horman
>> <horms+renesas@verge.net.au> wrote:
>> > Use ARCH_RENESAS in place of ARCH_SHMOBILE.
>> > Also remove spurious ().
>> >
>> > This is part of an ongoing process to migrate from ARCH_SHMOBILE to
>> > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
>> > appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
>> >
>> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>> > ---
>> > drivers/video/fbdev/Kconfig | 4 ++--
>> > 1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>> > index 8ea45a5cd806..71294f595f61 100644
>> > --- a/drivers/video/fbdev/Kconfig
>> > +++ b/drivers/video/fbdev/Kconfig
>> > @@ -1985,7 +1985,7 @@ config FB_W100
>> >
>> > config FB_SH_MOBILE_LCDC
>> > tristate "SuperH Mobile LCDC framebuffer support"
>> > - depends on FB && (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
>> > + depends on FB && (SUPERH || ARCH_RENESAS) && HAVE_CLK
>>
>> I would replace SUPERH by ARCH_RENESAS, and thus keep ARCH_SHMOBILE.
>>
>> "sh_mobile_lcdc_fb" is used on SH_AP325RXA, SH_ECOVEC, SH_KFR2R09, SH_MIGOR,
>> and SH_7724_SOLUTION_ENGINE, which depend on either CPU_SUBTYPE_SH7722,
>> CPU_SUBTYPE_SH7723, or CPU_SUBTYPE_SH7724, and all three select ARCH_SHMOBILE.
>>
>> In addition, it's used on r8a7740/armadillo800eva, which is covered by
>> ARCH_RENESAS.
>>
>> > depends on FB_SH_MOBILE_MERAM || !FB_SH_MOBILE_MERAM
>> > select FB_SYS_FILLRECT
>> > select FB_SYS_COPYAREA
>> > @@ -2450,7 +2450,7 @@ source "drivers/video/fbdev/mmp/Kconfig"
>> >
>> > config FB_SH_MOBILE_MERAM
>> > tristate "SuperH Mobile MERAM read ahead support"
>> > - depends on (SUPERH || ARCH_SHMOBILE)
>> > + depends on SUPERH || ARCH_RENESAS
>> > select GENERIC_ALLOCATOR
>> > ---help---
>> > Enable MERAM support for the SuperH controller.
>>
>> As Laurent already pointed out, that one is currently unused.
>>
>> It could be used on sh73a0, r8a7740, and some SuperH SH-Mobile SoCs, though.
>
> I'm inclined to remove the driver if its unused (I assume that has
> been the case for quite some time).
Before removing perhaps it makes sense to ask the original author of
the MERAM code about integration status? It may be as simple as
revoking a couple of commits.
/ magnus
^ permalink raw reply
* Re: [PATCH 1/2] fbdev: sh_mobile_meram: use ARCH_RENESAS
From: Laurent Pinchart @ 2016-03-16 5:26 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1457663298-31973-2-git-send-email-horms+renesas@verge.net.au>
Hi Simon,
On Tuesday 15 March 2016 10:25:30 Simon Horman wrote:
> On Fri, Mar 11, 2016 at 09:22:08AM +0200, Laurent Pinchart wrote:
> > On Friday 11 March 2016 09:14:46 Laurent Pinchart wrote:
> > > On Friday 11 March 2016 11:28:17 Simon Horman wrote:
> > > > Use ARCH_RENESAS in place of ARCH_SHMOBILE.
> > > > Also remove spurious ().
> > > >
> > > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> > > > ARCH_RENESAS the motivation for which being that RENESAS seems to be a
> > > > more appropriate name than SHMOBILE for the majority of Renesas ARM
> > > > based SoCs.
> > > >
> > > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > > > ---
> > > >
> > > > drivers/video/fbdev/Kconfig | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > > > index 8ea45a5cd806..71294f595f61 100644
> > > > --- a/drivers/video/fbdev/Kconfig
> > > > +++ b/drivers/video/fbdev/Kconfig
> > > > @@ -1985,7 +1985,7 @@ config FB_W100
> > > >
> > > > config FB_SH_MOBILE_LCDC
> > > >
> > > > tristate "SuperH Mobile LCDC framebuffer support"
> > > >
> > > > - depends on FB && (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
> > > > + depends on FB && (SUPERH || ARCH_RENESAS) && HAVE_CLK
> > > >
> > > > depends on FB_SH_MOBILE_MERAM || !FB_SH_MOBILE_MERAM
> > > > select FB_SYS_FILLRECT
> > > > select FB_SYS_COPYAREA
> > > >
> > > > @@ -2450,7 +2450,7 @@ source "drivers/video/fbdev/mmp/Kconfig"
> > > >
> > > > config FB_SH_MOBILE_MERAM
> > > >
> > > > tristate "SuperH Mobile MERAM read ahead support"
> > > >
> > > > - depends on (SUPERH || ARCH_SHMOBILE)
> > > > + depends on SUPERH || ARCH_RENESAS
> > >
> > > The MERAM driver isn't used by any ARM platform, you can just drop
> > > ARCH_SHMOBILE completely.
> >
> > Actually, upon closer inspection, the MERAM driver isn't used by any
> > platform.
>
> If its not used then I think we should consider removing it.
>
> However, it seems to me that its used in the following:
>
> drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> drivers/gpu/drm/shmobile/shmob_drm_kms.c
> drivers/gpu/drm/shmobile/shmob_drm_plane.c
> drivers/video/fbdev/sh_mobile_lcdcfb.c
>
> It seems to me that we would need to either remove usage in the above
> files or remove the above files before removing the MERAM driver.
That's correct, those drivers need to be fixed or removed.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"
From: Luis R. Rodriguez @ 2016-03-15 22:24 UTC (permalink / raw)
To: Ingo Molnar
Cc: Luis R. Rodriguez, paulmck, bp, tglx, hpa, toshi.kani, airlied,
benh, mst, vinod.koul, jgross, daniel.vetter, luto, davem, ben,
benjamin.poirier, linux-fbdev, linux-arch, linux-kernel, x86,
linux-doc, corbet
In-Reply-To: <20160305115255.GA11846@gmail.com>
On Sat, Mar 05, 2016 at 12:52:55PM +0100, Ingo Molnar wrote:
>
> * Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>
> > The current documentation refers to using set_memory_wc() as a
> > possible hole strategy when you have overlapping ioremap() regions,
>
> The whole explanation should talk about virtual aliases over the same physical
> address, not some 'overlapping regions'.
>
> I see where this talk about 'overlap' comes: the memtype rbtree in
> arch/x86/mm/pat_rbtree.c indeed has memtype ranges that may overlap on the
> physical side. But it is highly confusing to call this 'overlapping' on the driver
> API documentation level without making it really clear what it's about.
Alright thanks, I think I'll just stick to aliasing. I'll go over the
threads and pick out only what is relevant.
Luis
^ permalink raw reply
* Re: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"
From: Luis R. Rodriguez @ 2016-03-15 22:21 UTC (permalink / raw)
To: Elliott, Robert (Persistent Memory)
Cc: Luis R. Rodriguez, paulmck@linux.vnet.ibm.com, bp@alien8.de,
mingo@kernel.org, tglx@linutronix.de, hpa@zytor.com,
toshi.kani@hp.com, airlied@redhat.com, benh@kernel.crashing.org,
mst@redhat.com, vinod.koul@intel.com, jgross@suse.com,
daniel.vetter@ffwll.ch, luto@amacapital.net, davem@davemloft.net,
ben@decadent.org.uk, benjamin.poirier@gmail.com,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org, linux-k
In-Reply-To: <94D0CD8314A33A4D9D801C0FE68B40295C350C7C@G9W0745.americas.hpqcorp.net>
On Sat, Mar 05, 2016 at 04:39:58AM +0000, Elliott, Robert (Persistent Memory) wrote:
> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> > owner@vger.kernel.org] On Behalf Of Luis R. Rodriguez
> > Sent: Friday, March 04, 2016 4:45 PM
> > Subject: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on
> > PAT / non-PAT systems"
> ...
> > +MMIO and another PCI BAR for write-combing, if needed.
>
> typo: combining
Amended, thanks.
Luis
^ permalink raw reply
* [GIT PULL] fbdev changes for 4.6
From: Tomi Valkeinen @ 2016-03-15 12:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-fbdev, linux-kernel@vger.kernel.org
[-- Attachment #1.1: Type: text/plain, Size: 3472 bytes --]
Hi Linus,
The following changes since commit 18558cae0272f8fd9647e69d3fec1565a7949865:
Linux 4.5-rc4 (2016-02-14 13:05:20 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-4.6
for you to fetch changes up to 13aa38e291bdd4e4018f40dd2f75e464814dcbf3:
xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND" (2016-03-11 13:37:02 +0200)
----------------------------------------------------------------
fbdev changes for 4.6
* Miscallaneous small fixes to various fbdev drivers
* Remove fb_rotate, which was never used
* pmag fb improvements
----------------------------------------------------------------
Andrzej Hajda (1):
fbdev: exynos: fix IS_ERR_VALUE usage
Arnd Bergmann (2):
video: exynos: fix modular build
xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND"
Dan Carpenter (1):
video: fbdev: metronomefb: two harmless off by one bugs
Daniel Wagner (1):
video: Use bool instead int pointer for get_opt_bool() argument
Maciej W. Rozycki (8):
video: fbdev: pmag-ba-fb: Fix the lower margin size
video: fbdev: pmag-aa-fb: Adapt to current APIs
video: fbdev: pmag-aa-fb: Enable building as a module
video: fbdev: pmag-aa-fb: Report video timings
video: fbdev: bt455: Remove unneeded colormap helpers for cursor support
video: fbdev: pmag-ba-fb: Fix and rework Bt455 colormap handling
video: fbdev: pmag-ba-fb: Optimize Bt455 colormap addressing
video: fbdev: bt431: Correct cursor format control macro
Paul Gortmaker (3):
drivers/video: make fbdev/sunxvr500.c explicitly non-modular
drivers/video: make fbdev/sunxvr1000.c explicitly non-modular
drivers/video: make fbdev/sunxvr2500.c explicitly non-modular
Rasmus Villemoes (1):
fbdev: kill fb_rotate
Simon Horman (1):
fbdev: sh_mobile_lcdc: Use ARCH_RENESAS
Sudip Mukherjee (2):
fbdev: n411: check return value
video: fbdev: sis: remove unused variable
Sushaanth Srirangapathi (1):
fbdev: da8xx-fb: fix videomodes of lcd panels
drivers/video/fbdev/Kconfig | 7 +-
drivers/video/fbdev/atafb.c | 3 -
drivers/video/fbdev/au1100fb.c | 22 -
drivers/video/fbdev/bf537-lq035.c | 23 -
drivers/video/fbdev/bt431.h | 43 +-
drivers/video/fbdev/bt455.h | 68 ++-
drivers/video/fbdev/da8xx-fb.c | 7 +-
drivers/video/fbdev/exynos/Kconfig | 6 +-
drivers/video/fbdev/exynos/Makefile | 6 +-
drivers/video/fbdev/exynos/exynos_mipi_dsi.c | 7 +-
drivers/video/fbdev/intelfb/intelfbdrv.c | 2 +-
drivers/video/fbdev/metronomefb.c | 6 +-
drivers/video/fbdev/n411.c | 12 +-
drivers/video/fbdev/omap/omapfb_main.c | 22 -
drivers/video/fbdev/pmag-aa-fb.c | 602 +++++++++------------------
drivers/video/fbdev/pmag-ba-fb.c | 2 +-
drivers/video/fbdev/sis/init301.c | 10 +-
drivers/video/fbdev/skeletonfb.c | 17 -
drivers/video/fbdev/sunxvr1000.c | 42 +-
drivers/video/fbdev/sunxvr2500.c | 39 +-
drivers/video/fbdev/sunxvr500.c | 42 +-
include/linux/fb.h | 3 -
22 files changed, 310 insertions(+), 681 deletions(-)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox