On 19-04-18, 16:06, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested only. buildbot is happy. Please apply
On 19-04-18, 16:05, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested only. buildbot is happy. Please apply
On Thu, Apr 19, 2018 at 04:06:10PM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
It is indeed, thanks.
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested
On Wed 2018-04-18 15:00:41, Mark Brown wrote:
> On Wed, Apr 18, 2018 at 03:29:36PM +0200, Geert Uytterhoeven wrote:
>
> > Any comments/suggestions?
>
> > In case you lost the patches from the thread:
> > https://www.spinics.net/lists/linux-renesas-soc/msg24955.html
>
> Please don't send content
On Thu, Apr 19, 2018 at 11:07:44PM +0300, Sergei Shtylyov wrote:
> I've successfully tested eMMC on R8A77980/Condor. R8A77980 has a single
> SDHI core anyway, so can't be a subject of the known RX DMA errata...
Lucky you ;)
> Signed-off-by: Sergei Shtylyov
I've successfully tested eMMC on R8A77980/Condor. R8A77980 has a single
SDHI core anyway, so can't be a subject of the known RX DMA errata...
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'next' branch of Ulf Hansson's 'mmc.git' repo.
On Thu, Apr 19, 2018 at 04:06:29PM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Guenter Roeck
>
I've included the pin I/O voltage control into the R8A77970 PFC driver but
it was incomplete because:
- SH_PFC_PIN_CFG_IO_VOLTAGE pin flags weren't set properly;
- sh_pfc_soc_info::ioctrl_regs wasn't set at all...
Fixes: b92ac66a1819 ("pinctrl: sh-pfc: Add R8A77970 PFC support")
Signed-off-by:
Add the pin I/O voltage level control support to the R8A77980 PFC driver.
Loosely based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov
Signed-off-by: Sergei Shtylyov
Reviewed-by:
Hello Wolfram,
On Thu, Apr 19, 2018 at 04:06:23PM +0200, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested only.
Hello!
On 04/19/2018 05:05 PM, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
Note that the name of the field in the 'struct device' is driver_data,
not drvdata. Otherwise the patch looks good.
> platform_device is an unneeded step back and forth.
>
>
On 04/19/2018 04:06 PM, Geert Uytterhoeven wrote:
>> I've included the pin I/O voltage control into the R8A77970 PFC driver but
>> it was incomplete because:
>> - SH_PFC_PIN_CFG_IO_VOLTAGE pin flags weren't set properly;
>> - sh_pfc_soc_info::ioctrl_regs wasn't set at all...
>
> Thanks for your
On 04/19/2018 04:06 PM, Geert Uytterhoeven wrote:
>> I've included the pin I/O voltage control into the R8A77970 PFC driver but
>> it was incomplete because:
>> - SH_PFC_PIN_CFG_IO_VOLTAGE pin flags weren't set properly;
>> - sh_pfc_soc_info::ioctrl_regs wasn't set at all...
>
> Thanks for your
On 4/19/2018 10:05 AM, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested only. buildbot is happy. Please apply
On 04/19/2018 09:05 AM, Wolfram Sang wrote:
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
On 04/19/2018 09:06 AM, Wolfram Sang wrote:
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
[CC'ing Linus W.]
On Thu, Apr 19, 2018 at 4:05 PM, Wolfram Sang
wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
Seems
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
arch/arm/plat-samsung/adc.c | 3 +--
1 file
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/ata/pata_samsung_cf.c | 8 +++-
1
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/auxdisplay/arm-charlcd.c | 6 ++
1
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/crypto/exynos-rng.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/clk/samsung/clk-s3c2410-dclk.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/dma/at_hdmac.c | 9 +++--
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/dma/qcom/hidma.c | 3 +--
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/dma/dw/platform.c | 6 ++
1 file
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/bus/brcmstb_gisb.c | 12
1
I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/gpu/drm/msm/msm_drv.c | 3 +--
1 file
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/gpu/drm/msm/adreno/adreno_device.c | 6
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/gpio/gpio-dwapb.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/gpu/drm/msm/dsi/dsi_host.c | 6 ++
1
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c |
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 6
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/input/keyboard/ep93xx_keypad.c | 10
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/gpu/drm/vc4/vc4_drv.c | 3 +--
1 file
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/input/misc/max77693-haptic.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/iommu/qcom_iommu.c | 6 ++
1 file
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/media/platform/am437x/am437x-vpfe.c | 6
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/hid/hid-sensor-custom.c | 12
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/mmc/host/davinci_mmc.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/media/platform/exynos4-is/media-dev.c | 6
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/media/platform/s5p-mfc/s5p_mfc.c | 6
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/mtd/devices/docg3.c | 3 +--
1 file
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/mtd/nand/onenand/samsung.c | 6 ++
1
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/input/mouse/navpoint.c | 6 ++
1 file
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/net/dsa/bcm_sf2.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/input/touchscreen/imx6ul_tsc.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/net/ethernet/cadence/macb_main.c | 6
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/net/ethernet/davicom/dm9000.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/net/ethernet/smsc/smc91x.c | 3 +--
1
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/net/ethernet/ti/cpsw.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/net/ethernet/wiznet/w5300.c | 6 ++
1
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/pinctrl/pinctrl-amd.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/perf/arm_spe_pmu.c | 6 ++
1 file
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/pinctrl/intel/pinctrl-baytrail.c | 6
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/platform/x86/asus-laptop.c| 3 +--
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/power/supply/gpio-charger.c | 3 +--
1
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/ptp/ptp_dte.c | 6 ++
1 file changed,
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/staging/greybus/arche-platform.c | 3 +--
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/rtc/rtc-bq4802.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/spi/spi-cadence.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/slimbus/qcom-ctrl.c | 6 ++
1 file
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/pwm/pwm-atmel-tcb.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/staging/iio/adc/ad7606_par.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/staging/nvec/nvec.c | 6 ++
1 file
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/thermal/int340x_thermal/int3400_thermal.c
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/thermal/st/st_thermal.c | 6 ++
1
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/thermal/rockchip_thermal.c | 8 +++-
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/uio/uio_fsl_elbc_gpcm.c | 6 ++
1
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/video/fbdev/auo_k190x.c| 12
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/tty/serial/imx.c | 18
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/watchdog/cadence_wdt.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
net/dsa/legacy.c | 6 ++
1 file changed, 2
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
sound/soc/atmel/atmel_ssc_dai.c | 6 ++
1
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/usb/mtu3/mtu3_plat.c | 6 ++
1 file
Hi Biju,
On Thu, Apr 19, 2018 at 3:48 PM, Biju Das wrote:
>> On Tue, Apr 17, 2018 at 11:07 AM, Biju Das
>> wrote:
>> >> Subject: Re: [PATCH v2 1/2] pinctrl: sh-pfc: Add r8a77470 PFC support
>> >> On Wed, Apr 4, 2018 at 5:22 PM, Biju Das
Hi Geert,
Thanks for the comment.
> Subject: Re: [PATCH v2 1/2] pinctrl: sh-pfc: Add r8a77470 PFC support
>
> Hi Biju,
>
> + Sergei
>
> On Tue, Apr 17, 2018 at 11:07 AM, Biju Das
> wrote:
> >> Subject: Re: [PATCH v2 1/2] pinctrl: sh-pfc: Add r8a77470 PFC support
> >> On
On 18 April 2018 at 20:20, Wolfram Sang
wrote:
> I have collected the patches floating around for renesas_sdhi_internal_dmac
> and
> grouped them to avoid dependency issues.
>
> Regarding stable: I think patch 1 is clearly for stable. Patch 3 maybe, but it
>
On 16 April 2018 at 20:30, Sergei Shtylyov
wrote:
> Document the R-Car V3H (R8A77980) SoC in the Renesas SDHI bindings.
>
> Signed-off-by: Sergei Shtylyov
Thanks, applied for next!
Kind regards
Uffe
>
> ---
> This patch
Hi Sergei,
On Wed, Apr 18, 2018 at 10:26 PM, Sergei Shtylyov
wrote:
> I've included the pin I/O voltage control into the R8A77970 PFC driver but
> it was incomplete because:
> - SH_PFC_PIN_CFG_IO_VOLTAGE pin flags weren't set properly;
> -
Hi Sergei,
On Fri, Apr 13, 2018 at 8:29 PM, Sergei Shtylyov
wrote:
> Add the pin I/O voltage level control to the R8A77980 PFC driver.
>
> Loosely based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov
Hi Vladimir,
On Thu, Apr 19, 2018 at 02:18:30PM +0300, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
> > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> > output converter.
> >
> > Signed-off-by: Jacopo Mondi
Hi Jacopo,
On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output converter.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Niklas Söderlund
On Thu, Apr 19, 2018 at 12:44:32PM +0300, Vladimir Zapolskiy wrote:
Hi Vladimir,
> Hi Jacopo, Laurent,
>
> On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >
> > Signed-off-by: Jacopo Mondi
> >
Hi Jacopo,
On 04/19/2018 12:48 PM, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 04/19/2018 12:44 PM, Vladimir Zapolskiy wrote:
>> Hi Jacopo, Laurent,
>>
>> On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>>
>>> Signed-off-by:
Hi Hoan
On 18 April 2018 08:03 Hoan Tran wrote:
> On Fri, Apr 13, 2018 at 9:47 AM, Phil Edworthy wrote:
> > On 13 April 2018 17:37 Hoan Tran wrote:
> >> On Fri, Apr 13, 2018 at 1:51 AM, Phil Edworthy wrote:
> >> > The DesignWare GPIO IP can be configured for either 1 interrupt or
> >> > 1 per
Hi Marek,
On Tue, Apr 10, 2018 at 6:17 PM, Marek Vasut wrote:
> On 04/10/2018 05:28 PM, Geert Uytterhoeven wrote:
> The pairing looks as follows:
>
> .- rcar_pcie_parse_request_of_pci_ranges()
> | (pm_runtime_enable is here)
> | .-
Hi Jacopo,
On 04/19/2018 12:44 PM, Vladimir Zapolskiy wrote:
> Hi Jacopo, Laurent,
>
> On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>
>> Signed-off-by: Jacopo Mondi
>> Reviewed-by: Andrzej Hajda
Hi Jacopo, Laurent,
On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Niklas Söderlund
Hello DRM list,
cc media-list for the mbus format extension
cc renesas-soc and devicetree for Eagle DTS patch
This series adds support for static image formats to DRM bridges, mimicking
what display_info.bus_formats represents for DRM connectors.
The main use case of this series is the R-Car
Add LVDS map mode description property to THC63LVD1024 LVDS decoder in
R-Car V3M-Eagle board device tree.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 1 +
1 file changed, 1 insertion(+)
diff --git
Add support for storing image format information in DRM bridges with
associated helper function.
This patch replicates for bridges what 'drm_display_info_set_bus_formats()'
is for connectors.
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/drm_bridge.c | 30
The THC63LVD1024 LVDS to RGB bridge supports two different input mapping
modes, selectable by means of an external pin.
Describe the LVDS mode map through a newly defined mandatory property in
device tree bindings.
Signed-off-by: Jacopo Mondi
---
The THC63LVD1024 LVDS to RGB bridge supports two different LVDS mapping
modes, selectable by means of an external pin.
Add support for configurable LVDS input mapping modes, using the newly
introduced support for bridge input image formats.
Signed-off-by: Jacopo Mondi
With the introduction of static input image format enumeration in DRM
bridges, add support to retrieve the format in rcar-lvds LVDS encoder
from both panel or bridge, to set the desired LVDS mode.
Do not rely on 'DRM_BUS_FLAG_DATA_LSB_TO_MSB' flag to mirror the LVDS
format, as it is only defined
Some LVDS controller can output swapped versions of LVDS RGB formats.
Define and document them in the list of supported media bus formats
Signed-off-by: Jacopo Mondi
---
Documentation/media/uapi/v4l/subdev-formats.rst | 174
As now both bridges and panels report supported image formats,
use the newly introduced _LE version of LVDS media bus formats in place
of the DRM_BUS_FLAG_DATA_ flags defined in drm_connector.h
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/panel/panel-lvds.c | 21
1 - 100 of 104 matches
Mail list logo