On Thu, Nov 17, 2016 at 4:09 PM, Niklas Söderlund
wrote:
> These patches add drive strength and bias support for both GPIO and none
> GPIO pins to r8a7796. Similar to the none GPIO pins for r8a7795 the
> system to derive unique pin numbers are the R-Car M3SiP pin layout.
>
> Tested on M3-W and the
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi
---
drivers/usb/dwc3/dwc3-omap.c | 20 +++-
1 file changed, 7 insertio
This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()
Cc: Kishon Vijay Abraham I
Cc: Maxime Ripard
Cc: Chen-Yu Tsai
Signed-off-by: Chanwoo Choi
---
drivers/phy/phy-sun4i-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi
---
drivers/usb/phy/phy-msm-usb.c | 33 +++--
1 file chang
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi
---
drivers/usb/phy/phy-qcom-8x16-usb.c | 13 -
1 file changed, 4 insertio
This patch replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi
---
drivers/usb/renesas_usbhs/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/r
This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()
Signed-off-by: Chanwoo Choi
---
drivers/power/supply/qcom_smbb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/supply/qcom_smbb.c b/drivers/power
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi
---
drivers/usb/phy/phy-omap-otg.c | 24 ++--
1 file changed, 6 in
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi
---
drivers/usb/chipidea/core.c | 30 ++
1 file changed, 6
This patch just uses the resource-managed extcon API when registering
the extcon notifier.
Signed-off-by: Chanwoo Choi
---
drivers/usb/musb/sunxi.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 1408245be
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi
---
drivers/power/supply/axp288_charger.c | 51 +--
1
This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()
Signed-off-by: Chanwoo Choi
---
drivers/usb/phy/phy-tahvo.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/
This patches just replace the deprecated extcon API without any change
of extcon operation and use the resource-managed function for
extcon_register_notifier().
The new extcon API instead of deprecated API.
- extcon_set_cable_state_() -> extcon_set_state_sync();
- extcon_get_cable_state_() -> extc
This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()
Signed-off-by: Chanwoo Choi
---
drivers/phy/phy-rcar-gen3-usb2.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drive
Hey,
On Tue, Nov 29, 2016 at 09:32:42AM +0100, Wolfram Sang wrote:
> Hi Eduardo,
>
> > No commit message ? :-( generally speaking here, it is a good practice
> > to describe what you are doing, what you have considered, and what you
> > have tested, just for the sake of code history/documentation
On 11/29/2016 11:27 PM, Laurent Pinchart wrote:
Hi Archit,
On Tuesday 29 Nov 2016 15:57:06 Archit Taneja wrote:
On 11/29/2016 02:34 PM, Laurent Pinchart wrote:
Instead of linking encoders and bridges in every driver (and getting it
wrong half of the time, as many drivers forget to set the dr
From: Johan Hovold
Date: Mon, 28 Nov 2016 19:24:53 +0100
> This series fixes failures to deregister and free fixed-link phydevs
> that have been registered using the of_phy_register_fixed_link()
> interface.
>
> All but two drivers currently fail to do this and this series fixes most
> of them w
From: Geert Uytterhoeven
Date: Mon, 28 Nov 2016 15:18:31 +0100
> If device_release_driver(&phydev->mdio.dev) is called, it releases all
> resources belonging to the PHY device. Hence the subsequent call to
> phy_led_triggers_unregister() will access already freed memory when
> unregistering the L
Hi Daniel,
On Tuesday 29 Nov 2016 21:25:27 Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 07:49:22PM +0200, Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 11:27:20 Daniel Vetter wrote:
> >> On Tue, Nov 29, 2016 at 11:58:44AM +0200, Laurent Pinchart wrote:
> >>> On Tuesday 29 Nov 2016 10:56:53
Hi Laurent,
On Tue, Nov 29, 2016 at 8:30 PM, Laurent Pinchart
wrote:
> On Tuesday 29 Nov 2016 10:11:56 Jacopo Mondi wrote:
>> Add pin configuration support for Gyro-ADC, named ADI on r8a7791 SoC.
>>
>> The Gyro-ADC supports three different configurations:
>> a single ADC (adi and adi_b groups), 2
Hi Daniel,
On Tuesday 29 Nov 2016 10:54:09 Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:04:36AM +0200, Laurent Pinchart wrote:
> > The LVDS encoder driver is a DRM bridge driver that supports the
> > parallel to LVDS encoders that don't require any configuration. The
> > driver thus doesn't i
On Tue, Nov 29, 2016 at 07:49:22PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tuesday 29 Nov 2016 11:27:20 Daniel Vetter wrote:
> > On Tue, Nov 29, 2016 at 11:58:44AM +0200, Laurent Pinchart wrote:
> > > On Tuesday 29 Nov 2016 10:56:53 Daniel Vetter wrote:
> > >> On Tue, Nov 29, 2016 at 11
On Tue, Nov 29, 2016 at 08:56:44PM +0200, Laurent Pinchart wrote:
> Hi Archit,
>
> On Tuesday 29 Nov 2016 16:04:08 Archit Taneja wrote:
> > On 11/29/2016 02:34 PM, Laurent Pinchart wrote:
> > > Most drivers that use bridges forgot to detach them at cleanup time.
> > > Instead of fixing them one by
On Tue, 29 Nov 2016 11:04:33 +0200
Laurent Pinchart wrote:
> Instead of linking encoders and bridges in every driver (and getting it
> wrong half of the time, as many drivers forget to set the drm_bridge
> encoder pointer), do so in core code. The drm_bridge_attach() function
> needs the encoder
Hi Jacopo,
Thank you for the patch.
On Tuesday 29 Nov 2016 10:11:56 Jacopo Mondi wrote:
> Add pin configuration support for Gyro-ADC, named ADI on r8a7791 SoC.
>
> The Gyro-ADC supports three different configurations:
> a single ADC (adi and adi_b groups), 2 ADCs selectable through a single
> ch
Hi Daniel,
On Tuesday 29 Nov 2016 10:48:21 Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:04:34AM +0200, Laurent Pinchart wrote:
> > Most drivers that use bridges forgot to detach them at cleanup time.
> > Instead of fixing them one by one, detach the bridge in the core
> > drm_encoder_cleanup(
Hi Archit,
On Tuesday 29 Nov 2016 16:04:08 Archit Taneja wrote:
> On 11/29/2016 02:34 PM, Laurent Pinchart wrote:
> > Most drivers that use bridges forgot to detach them at cleanup time.
> > Instead of fixing them one by one, detach the bridge in the core
> > drm_encoder_cleanup() function.
> >
>
Hi Geert,
thanks for the prompt review!
> > +/* Structure for thermal temperature calculation */
> > +struct equation_coefs {
> > + long a1;
> > + long b1;
> > + long a2;
> > + long b2;
>
> Why long? Long has a different size for 32-bit and 64-bit platforms.
> I know this
Hi Daniel,
On Tuesday 29 Nov 2016 20:02:01 Laurent Pinchart wrote:
> On Tuesday 29 Nov 2016 11:05:27 Daniel Vetter wrote:
> > On Tue, Nov 29, 2016 at 11:43:19AM +0200, Laurent Pinchart wrote:
> >> On Tuesday 29 Nov 2016 10:35:24 Daniel Vetter wrote:
> >>> On Tue, Nov 29, 2016 at 11:04:33AM +0200,
Hi Rob,
On Tuesday 29 Nov 2016 09:14:09 Rob Herring wrote:
> On Tue, Nov 29, 2016 at 2:27 AM, Laurent Pinchart wrote:
> > On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote:
> >> On Monday 21 Nov 2016 10:48:15 Rob Herring wrote:
> >>> On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart
Hi Daniel,
On Tuesday 29 Nov 2016 11:05:27 Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:43:19AM +0200, Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 10:35:24 Daniel Vetter wrote:
> >> On Tue, Nov 29, 2016 at 11:04:33AM +0200, Laurent Pinchart wrote:
> >>> Instead of linking encoders and
Hi Archit,
On Tuesday 29 Nov 2016 15:57:06 Archit Taneja wrote:
> On 11/29/2016 02:34 PM, Laurent Pinchart wrote:
> > Instead of linking encoders and bridges in every driver (and getting it
> > wrong half of the time, as many drivers forget to set the drm_bridge
> > encoder pointer), do so in core
Hi Daniel,
On Tuesday 29 Nov 2016 11:27:20 Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:58:44AM +0200, Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 10:56:53 Daniel Vetter wrote:
> >> On Tue, Nov 29, 2016 at 11:04:39AM +0200, Laurent Pinchart wrote:
> >>> The drm_bridge object models on-
On Tue, Nov 29, 2016 at 06:23:38PM +0100, Geert Uytterhoeven wrote:
> Hi Rich,
>
> On Tue, Nov 29, 2016 at 6:09 PM, Rich Felker wrote:
> > On Fri, Nov 25, 2016 at 08:33:01AM +0100, Simon Horman wrote:
> >> Commit edf4100906044225 ("ARM: shmobile: sh7372 dtsi: Remove Legacy file")
> >> removed the
Hi Rich,
On Tue, Nov 29, 2016 at 6:09 PM, Rich Felker wrote:
> On Fri, Nov 25, 2016 at 08:33:01AM +0100, Simon Horman wrote:
>> Commit edf4100906044225 ("ARM: shmobile: sh7372 dtsi: Remove Legacy file")
>> removed the sh7272 SoC from the kernel in v4.1.
>>
>> This patch removes support for the sh
On Fri, Nov 25, 2016 at 08:33:01AM +0100, Simon Horman wrote:
> Commit edf4100906044225 ("ARM: shmobile: sh7372 dtsi: Remove Legacy file")
> removed the sh7272 SoC from the kernel in v4.1.
>
> This patch removes support for the sh7272 SoC from the sh_flctl driver.
> As that SoC was the only user o
On 2016-11-29 01:04, Laurent Pinchart wrote:
> Instead of linking encoders and bridges in every driver (and getting it
> wrong half of the time, as many drivers forget to set the drm_bridge
> encoder pointer), do so in core code. The drm_bridge_attach() function
> needs the encoder and optional pre
On Tue, Nov 29, 2016 at 2:27 AM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote:
>> On Monday 21 Nov 2016 10:48:15 Rob Herring wrote:
>> > On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote:
>> >> Document properties common to several dis
On Tue, Nov 29, 2016 at 02:39:20PM +0100, Geert Uytterhoeven wrote:
> > Not understanding, why would a user ever need it? The platform knows if
> > its has funny boot image size limits, no?
>
> The boot loader does not come with the kernel, so the platform cannot
> know for sure.
Why would anybo
Hi Peter,
On Tue, Nov 29, 2016 at 2:31 PM, Peter Zijlstra wrote:
> On Tue, Nov 29, 2016 at 02:26:47PM +0100, Geert Uytterhoeven wrote:
>> On Tue, Nov 29, 2016 at 1:29 PM, Peter Zijlstra wrote:
>> > On Tue, Nov 29, 2016 at 12:52:04PM +0100, Geert Uytterhoeven wrote:
>
>> >> Not because of platfor
On Tue, Nov 29, 2016 at 02:26:47PM +0100, Geert Uytterhoeven wrote:
> On Tue, Nov 29, 2016 at 1:29 PM, Peter Zijlstra wrote:
> > On Tue, Nov 29, 2016 at 12:52:04PM +0100, Geert Uytterhoeven wrote:
> >> Not because of platforms with not limited memory, but because of platforms
> >> with boot loade
I have pushed renesas-drivers-2016-11-29-v4.9-rc7 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git
This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging branches with driver code
submitted or planned for submi
On Tue, Nov 29, 2016 at 1:29 PM, Peter Zijlstra wrote:
> On Tue, Nov 29, 2016 at 12:52:04PM +0100, Geert Uytterhoeven wrote:
>> > Nah, users don't need more senseless options. This is really only useful
>> > for dinky platforms or platforms with limited static image size (like
>> > sparc64).
>> >
Add pin configuration support for Gyro-ADC, named ADI on r8a7791 SoC.
The Gyro-ADC supports three different configurations:
a single ADC (adi and adi_b groups), 2 ADCs selectable through a single
channel select signal (adi_chsel1 and adi_chsel1_b groups), up to 4 ADCs
through 2 channel select sign
On Tue, Nov 29, 2016 at 01:29:07PM +0100, Peter Zijlstra wrote:
> > BTW, is there any particular reason these huge arrays are in BSS, and not
> > allocated dynamically? That would solve my problems as well...
>
> Is there a memory allocator available before _any_ locks are used, and
> that itself
On Tue, Nov 29, 2016 at 12:52:04PM +0100, Geert Uytterhoeven wrote:
> > Nah, users don't need more senseless options. This is really only useful
> > for dinky platforms or platforms with limited static image size (like
> > sparc64).
> >
> > If you make this user selectable, someone will do, and the
Hi Peter,
On Tue, Nov 29, 2016 at 12:41 PM, Peter Zijlstra wrote:
> On Tue, Nov 29, 2016 at 12:14:48PM +0100, Geert Uytterhoeven wrote:
>> CC linux-renesas-soc
>>
>> On Tue, Sep 27, 2016 at 9:33 PM, Babu Moger wrote:
>> > These patches limit the static allocations for lockdep data structures
>>
On Tue, Nov 29, 2016 at 12:14:48PM +0100, Geert Uytterhoeven wrote:
> CC linux-renesas-soc
>
> On Tue, Sep 27, 2016 at 9:33 PM, Babu Moger wrote:
> > These patches limit the static allocations for lockdep data structures
> > used for debugging locking correctness. For sparc, all the kernel's code
CC linux-renesas-soc
On Tue, Sep 27, 2016 at 9:33 PM, Babu Moger wrote:
> These patches limit the static allocations for lockdep data structures
> used for debugging locking correctness. For sparc, all the kernel's code,
> data, and bss, must have locked translations in the TLB so that we don't
>
On 11/29/2016 02:34 PM, Laurent Pinchart wrote:
Most drivers that use bridges forgot to detach them at cleanup time.
Instead of fixing them one by one, detach the bridge in the core
drm_encoder_cleanup() function.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_encoder.c | 3 +++
1 f
On Tue, Nov 29, 2016 at 11:58:44AM +0200, Laurent Pinchart wrote:
> On Tuesday 29 Nov 2016 10:56:53 Daniel Vetter wrote:
> > On Tue, Nov 29, 2016 at 11:04:39AM +0200, Laurent Pinchart wrote:
> > > The drm_bridge object models on- or off-chip hardware encoders and
> > > provide an abstract control A
On 11/29/2016 02:34 PM, Laurent Pinchart wrote:
Instead of linking encoders and bridges in every driver (and getting it
wrong half of the time, as many drivers forget to set the drm_bridge
encoder pointer), do so in core code. The drm_bridge_attach() function
needs the encoder and optional prev
On Tue, Nov 29, 2016 at 07:02:23PM +0900, Chanwoo Choi wrote:
> This patchs split out the extcon APIs of extcon provider driver in order to
> prevent the direct access of struct extcon_dev by extcon consumer driver.
> The extcon consumer driver don't need to handle the extcon provider APIs.
>
> Th
On Tue, Nov 29, 2016 at 11:43:19AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tuesday 29 Nov 2016 10:35:24 Daniel Vetter wrote:
> > On Tue, Nov 29, 2016 at 11:04:33AM +0200, Laurent Pinchart wrote:
> > > Instead of linking encoders and bridges in every driver (and getting it
> > > wrong ha
This patchs split out the extcon APIs of extcon provider driver in order to
prevent the direct access of struct extcon_dev by extcon consumer driver.
The extcon consumer driver don't need to handle the extcon provider APIs.
The extcon subsystem has two type of extcon drivers as following:
- extcon
On Tuesday 29 Nov 2016 10:56:53 Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:04:39AM +0200, Laurent Pinchart wrote:
> > The drm_bridge object models on- or off-chip hardware encoders and
> > provide an abstract control API to display drivers. In order to help
> > display drivers creating the r
On Tue, Nov 29, 2016 at 11:04:39AM +0200, Laurent Pinchart wrote:
> The drm_bridge object models on- or off-chip hardware encoders and
> provide an abstract control API to display drivers. In order to help
> display drivers creating the right kind of drm_encoder object, expose
> the type of the har
On Tue, Nov 29, 2016 at 11:04:36AM +0200, Laurent Pinchart wrote:
> The LVDS encoder driver is a DRM bridge driver that supports the
> parallel to LVDS encoders that don't require any configuration. The
> driver thus doesn't interact with the device, but creates an LVDS
> connector for the panel an
On Tue, Nov 29, 2016 at 11:04:37AM +0200, Laurent Pinchart wrote:
> The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be
> controlled through a power save pin, and requires a power supply.
> However, on most boards where the device is used neither the power save
> signal nor the pow
On Tue, Nov 29, 2016 at 11:04:34AM +0200, Laurent Pinchart wrote:
> Most drivers that use bridges forgot to detach them at cleanup time.
> Instead of fixing them one by one, detach the bridge in the core
> drm_encoder_cleanup() function.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/dr
On Wed, Nov 23, 2016 at 3:40 PM, Magnus Damm wrote:
> From: Magnus Damm
>
> Update the IPMMU DT binding documentation to include the r8a7796 compat
> string for R-Car M3-W.
>
> Signed-off-by: Magnus Damm
> Acked-by: Laurent Pinchart
> Acked-by: Rob Herring
> Acked-by: Simon Horman
Acked-by:
On Thu, Nov 17, 2016 at 4:26 PM, Niklas Söderlund
wrote:
> There are pins on the r8a7795 which are not part of a GPIO bank nor
> can be muxed between different functions. They do however allow for the
> bias to be configured. Add those pins to the list of pins and
> to the bias configuration array
Hi Daniel,
On Tuesday 29 Nov 2016 10:35:24 Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:04:33AM +0200, Laurent Pinchart wrote:
> > Instead of linking encoders and bridges in every driver (and getting it
> > wrong half of the time, as many drivers forget to set the drm_bridge
> > encoder point
Hi Daniel,
On Tuesday 29 Nov 2016 10:30:36 Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:04:31AM +0200, Laurent Pinchart wrote:
> > used to define most of the in-kernel KMS API. It has
> > now been split into separate files for each object type, but still
> > includes most other KMS headers t
On Tue, Nov 29, 2016 at 11:04:33AM +0200, Laurent Pinchart wrote:
> Instead of linking encoders and bridges in every driver (and getting it
> wrong half of the time, as many drivers forget to set the drm_bridge
> encoder pointer), do so in core code. The drm_bridge_attach() function
> needs the enc
On Tue, Nov 29, 2016 at 11:04:32AM +0200, Laurent Pinchart wrote:
> The drm_crtc_mask() function used in is a static
> inline defined in . If the first header is included in a
> compilation unit without the second one, the following compilation
> warning will be issued.
>
> In file included from
On Tue, Nov 29, 2016 at 11:04:31AM +0200, Laurent Pinchart wrote:
> used to define most of the in-kernel KMS API. It has
> now been split into separate files for each object type, but still
> includes most other KMS headers to avoid breaking driver compilation.
>
> As a step towards fixing that p
The rcar-du driver contains a manual implementation of HDMI and VGA
bridges. Use DRM bridges to replace it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 6 --
drivers/gpu/drm/rcar-du/Makefile | 5 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 104
The drm_bridge object models on- or off-chip hardware encoders and
provide an abstract control API to display drivers. In order to help
display drivers creating the right kind of drm_encoder object, expose
the type of the hardware encoder associated with each bridge.
Signed-off-by: Laurent Pinchar
Set the type of the DRM encoder that models the hardware encoders
(bridges) chain based on the type of the last bridge in the chain
instead of hardcoding encoder compatible strings in the display driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 17 ++---
Initialize the new drm_bridge::encoder_type field to the right value for
all external bridge drivers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 +
drivers/gpu/drm/bridge/analogix-anx78xx.c | 1 +
drivers/gpu/drm/bridge/analogix/analogix_d
Most drivers that use bridges forgot to detach them at cleanup time.
Instead of fixing them one by one, detach the bridge in the core
drm_encoder_cleanup() function.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_encoder.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/g
The THC63LVDM83D is a transparent LVDS encoder. Unlike dumb LVDS
encoders it can be controlled through a few pins (power down, LVDS
swing, clock edge selection) and requires power supplies. However, on
several boards where the device is used neither the control pins nor the
power supply are control
Initialize the new drm_bridge::encoder_type field to the right value for
all bridges that model on-SoC IP cores.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 ++
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 ++
drivers/gpu/drm/sti/sti_dvo.c | 2 ++
3 f
The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be
controlled through a power save pin, and requires a power supply.
However, on most boards where the device is used neither the power save
signal nor the power supply are controllable.
To avoid developing a separate device-specifi
The LVDS encoder driver is a DRM bridge driver that supports the
parallel to LVDS encoders that don't require any configuration. The
driver thus doesn't interact with the device, but creates an LVDS
connector for the panel and exposes its size and timing based on
information retrieved from DT.
Sig
The DT bindings support parallel to LVDS encoders that don't require any
configuration, similarly to the dumb VGA DAC DT bindings.
Signed-off-by: Laurent Pinchart
Acked-by: Rob Herring
---
.../bindings/display/bridge/lvds-transmitter.txt | 64 ++
1 file changed, 64 inserti
Instead of linking encoders and bridges in every driver (and getting it
wrong half of the time, as many drivers forget to set the drm_bridge
encoder pointer), do so in core code. The drm_bridge_attach() function
needs the encoder and optional previous bridge to perform that task,
update all the cal
Hello,
This patch series replaces the custom external encoders support implementation
in the R-Car DU driver with code based on the DRM bridge API.
While the overall diffstat isn't impressive, the rcar-du-drm driver gets
notably thinner in the process:
9 files changed, 64 insertions(+),
used to define most of the in-kernel KMS API. It has
now been split into separate files for each object type, but still
includes most other KMS headers to avoid breaking driver compilation.
As a step towards fixing that problem, remove the inclusion of
from and include it instead where
appropri
The drm_crtc_mask() function used in is a static
inline defined in . If the first header is included in a
compilation unit without the second one, the following compilation
warning will be issued.
In file included from /drivers/gpu/drm/drm_bridge.c:29:0:
/include/drm/drm_encoder.h:192:95: warning
Hi Wolfram,
On Mon, Nov 28, 2016 at 10:09 PM, Wolfram Sang
wrote:
> --- /dev/null
> +++ b/drivers/thermal/rcar_gen3_thermal.c
> +/* Structure for thermal temperature calculation */
> +struct equation_coefs {
> + long a1;
> + long b1;
> + long a2;
> + long b2;
Why long? L
Hi Eduardo,
> No commit message ? :-( generally speaking here, it is a good practice
> to describe what you are doing, what you have considered, and what you
> have tested, just for the sake of code history/documentation.
OK, can do.
> > + spin_lock_irqsave(&tsc->lock, flags);
>
> Why do you
Hi Rob,
On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote:
> On Monday 21 Nov 2016 10:48:15 Rob Herring wrote:
> > On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote:
> >> Document properties common to several display panels in a central
> >> location that can be referenced by t
84 matches
Mail list logo