* Re: [PATCH v1 1/7] dt-bindings: display: add STM32 LTDC driver
From: Yannick FERTRE @ 2017-01-19 16:16 UTC (permalink / raw)
To: Laurent Pinchart, dri-devel@lists.freedesktop.org
Cc: Mark Rutland, devicetree@vger.kernel.org, Alexandre TORGUE,
Arnd Bergmann, Russell King, Rob Herring, Philippe CORNU,
Maxime Coquelin, Mickael REULIER, Gabriel FERNANDEZ,
linux-arm-kernel@lists.infradead.org, kernel@stlinux.com
In-Reply-To: <2080174.sm3cyM9MmB@avalon>
On 01/16/2017 09:30 PM, Laurent Pinchart wrote:
> Hi Yannick,
>
> Thank you for the patch.
>
> On Monday 16 Jan 2017 14:28:58 Yannick Fertre wrote:
>> Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
>> ---
>> .../devicetree/bindings/display/st,ltdc.txt | 57 ++++++++++++++++++
>> 1 file changed, 57 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/display/st,ltdc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/display/st,ltdc.txt
>> b/Documentation/devicetree/bindings/display/st,ltdc.txt new file mode
>> 100644
>> index 0000000..20e89da
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/st,ltdc.txt
>> @@ -0,0 +1,57 @@
>> +* STMicroelectronics STM32 lcd-tft display controller
>> +
>> +- st-display-subsystem: Master device for DRM sub-components
>> + This device must be the parent of all the sub-components and is
>> responsible
>> + of bind them.
>
> Why do you need this ? At a quick glance the ltdc node should be enough.
Hi Laurent,
To prepare next device upstream of dsi, we need a master node
"st-display-subsystem" and a sub node "st,ltdc". It's the same kind of
node than st,stih4xx.
>
>> + Required properties:
>> + - compatible: "st,display-subsystem"
>> + - ranges: to allow probing of subdevices
>> +
>> +- ltdc_host: lcd-tft display controller host
>> + must be a sub-node of st-display-subsystem
>> + Required properties:
>> + - compatible: "st,ltdc"
>> + - reg: Physical base address of the IP registers and length of memory
>> mapped region.
>> + - clocks: from common clock binding: handle hardware IP needed clocks,
>> the
>> + number of clocks may depend of the SoC type.
>> + See ../clocks/clock-bindings.txt for details.
>> + - clock-names: names of the clocks listed in clocks property in the same
>> + order.
>
> You need to define the required/optional clocks with their names here. If they
> vary depending on the SoC, the DT bindings document need to list them for each
> SoC.
>
Ok, I'll push news bindings with pack V2.
>> + - resets: resets to be used by the device
>> + See ../reset/reset.txt for details.
>> + - reset-names: names of the resets listed in resets property in the same
>> + order.
>> + Required nodes:
>> + - Video port for RGB output.
>> +
>> +Example:
>> +
>> +/ {
>> + ...
>> + soc {
>> + ...
>> + st-display-subsystem {
>> + compatible = "st,display-subsystem";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> + dma-ranges;
>> +
>> + ltdc_host: stm32-ltdc@40016800 {
>> + compatible = "st,ltdc";
>> + reg = <0x40016800 0x200>;
>> + interrupts = <88>, <89>;
>> + resets = <&rcc 314>;
>> + clocks = <&rcc 1 8>;
>> + clock-names = "clk-lcd";
>> + status = "disabled";
>> +
>> + port {
>> + ltdc_out_rgb: endpoint {
>> + };
>> + };
>> + };
>> + };
>> + ...
>> + };
>> +};
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: gpu: Add Mali Utgard bindings
From: Rob Herring @ 2017-01-19 16:16 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Heiko Stuebner,
Javier Martinez Canillas, Kevin Hilman, Linus Walleij,
Krzysztof Kozlowski, Matthias Brugger, Chen-Yu Tsai, Kukjin Kim,
Alexandre Belloni, Boris Brezillon, Antoine Ténart,
Carlo Caione, Thomas Petazzoni, linux-arm-kernel
In-Reply-To: <20170116132424.7038-1-maxime.ripard@free-electrons.com>
On Mon, Jan 16, 2017 at 02:24:23PM +0100, Maxime Ripard wrote:
> The ARM Mali Utgard GPU family is embedded into a number of SoCs from
> Allwinner, Amlogic, Mediatek or Rockchip.
>
> Add a binding for the GPU of that family.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> .../devicetree/bindings/gpu/arm,mali-utgard.txt | 76 ++++++++++++++++++++++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> new file mode 100644
> index 000000000000..df05ba0ec357
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> @@ -0,0 +1,76 @@
> +ARM Mali Utgard GPU
> +===================
> +
> +Required properties:
> + - compatible:
> + * "arm,mali-utgard" and one of the following:
Drop this. It's meaningless and 3 compatibles to match is the kernel is
not a big deal.
> + + "arm,mali-300"
> + + "arm,mali-400"
> + + "arm,mali-450"
> +
> + - reg: Physical base address and length of the GPU registers
> +
> + - interrupts: an entry for each entry in interrupt-names.
> + See ../interrupt-controller/interrupts.txt for details.
> +
> + - interrupt-names:
> + * ppX: Pixel Processor X interrupt (X from 0 to 7)
> + * ppmmuX: Pixel Processor X MMU interrupt (X from 0 to 7)
Is the number of pixel processors probe-able? If not, then it needs to
be implied by the vendor compatible string or a property.
> + * pp: Pixel Processor broadcast interrupt (mali-450 only)
> + * gp: Geometry Processor interrupt
> + * gpmmu: Geometry Processor MMU interrupt
That's a lot of interrupts. Was going to ask about combining, but
I see Linus raised that.
> +
> +
> +Optional properties:
> + - interrupt-names:
> + * pmu: Power Management Unit interrupt, if implemented in hardware
> +
> +Vendor-specific bindings
> +------------------------
> +
> +The Mali GPU is integrated very differently from one SoC to
> +another. In order to accommodate those differences, you have the option
> +to specify one more vendor-specific compatible, among:
> +
> + - allwinner,sun4i-a10-mali
List this with the compatible strings. I assume one of the arm,mali-???
strings applies too.
> + Required properties:
> + * clocks: an entry for each entry in clock-names
> + * clock-names:
> + + bus: bus clock for the GPU
> + + core: clock driving the GPU itself
This should be in the core binding. The number of clocks should not
vary. We often get this wrong because the IP blocks get integrated and
connected to the same clock source. But this should be equal to the
number of clock inputs.
> + * resets: phandle to the reset line for the GPU
> +
> + - allwinner,sun7i-a20-mali
> + Required properties:
> + * clocks: an entry for each entry in clock-names
> + * clock-names:
> + + bus: bus clock for the GPU
> + + core: clock driving the GPU itself
> + * resets: phandle to the reset line for the GPU
> +
> +Example:
> +
> +mali: gpu@01c40000 {
> + compatible = "allwinner,sun7i-a20-mali", "arm,mali-400",
> + "arm,mali-utgard";
> + reg = <0x01c40000 0x10000>;
> + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "gp",
> + "gpmmu",
> + "pp0",
> + "ppmmu0",
> + "pp1",
> + "ppmmu1",
> + "pmu";
> + clocks = <&ccu CLK_BUS_GPU>, <&ccu CLK_GPU>;
> + clock-names = "bus", "core";
> + resets = <&ccu RST_BUS_GPU>;
> +};
> +
> +
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH v2 4/5] fbdev/ssd1307fb: add support to enable VBAT
From: Rob Herring @ 2017-01-19 16:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jyri Sarha, linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Bartlomiej Zolnierkiewicz, Maxime Ripard, Benoit Cousson
In-Reply-To: <c0372d48-b538-64ce-f187-0502a9a4a00e-l0cyMroinI0@public.gmane.org>
On Thu, Jan 19, 2017 at 9:08 AM, Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org> wrote:
> On 19/01/17 17:03, Rob Herring wrote:
>
>>>> According to the datasheet, SSD1307 has 2 supplies: Vdd and Vcc
>>>>
>>>> I don't see any mention of a charge pump, so that must be an external
>>>> component.
>>>
>>> VBAT is for SSD1306. Perhaps the DT doc should mention it.
>>
>> Datasheet says VBAT is reserved, connect to Vdd. I would just describe
>> Vdd and Vcc in that case.
>
> I'm no HW guy, but as far as I understand, you can wire it up two ways.
> One has VBAT connected to VDD. The other one has VBAT connected to
> external supply. See "Figure 1 : Application Example of SSD1306Z with
> charge bump".
I should have kept reading...
So either Vdd and Vbat supplies or Vdd and Vcc supplies are valid and
the former only applies to 1306.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/5] Add TV Encoder support for ZTE DRM driver
From: Shawn Guo @ 2017-01-19 16:24 UTC (permalink / raw)
To: dri-devel
Cc: Mark Rutland, devicetree, Daniel Vetter, Baoyou Xie, Rob Herring,
Jun Nie
From: Shawn Guo <shawn.guo@linaro.org>
The series updates zx_vou driver a bit as the preparation of adding
TVENC output device, and then adds the device driver.
Shawn Guo (5):
drm: zte: add interlace mode support
drm: zte: move struct vou_inf into zx_vou driver
drm: zte: add function to configure vou_ctrl dividers
dt: add bindings for ZTE tvenc device
drm: zte: add tvenc driver support
.../devicetree/bindings/display/zte,vou.txt | 15 +
drivers/gpu/drm/zte/Makefile | 1 +
drivers/gpu/drm/zte/zx_drm_drv.c | 1 +
drivers/gpu/drm/zte/zx_drm_drv.h | 1 +
drivers/gpu/drm/zte/zx_hdmi.c | 12 +-
drivers/gpu/drm/zte/zx_tvenc.c | 416 +++++++++++++++++++++
drivers/gpu/drm/zte/zx_tvenc_regs.h | 31 ++
drivers/gpu/drm/zte/zx_vou.c | 168 ++++++++-
drivers/gpu/drm/zte/zx_vou.h | 32 +-
drivers/gpu/drm/zte/zx_vou_regs.h | 31 ++
10 files changed, 682 insertions(+), 26 deletions(-)
create mode 100644 drivers/gpu/drm/zte/zx_tvenc.c
create mode 100644 drivers/gpu/drm/zte/zx_tvenc_regs.h
--
1.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 1/5] drm: zte: add interlace mode support
From: Shawn Guo @ 2017-01-19 16:24 UTC (permalink / raw)
To: dri-devel
Cc: Mark Rutland, devicetree, Daniel Vetter, Baoyou Xie, Rob Herring,
Jun Nie
In-Reply-To: <1484843100-16284-1-git-send-email-shawnguo@kernel.org>
From: Shawn Guo <shawn.guo@linaro.org>
It adds interlace mode support in VOU TIMING_CTRL and channel control
block, so that VOU driver gets ready to support output device in
interlace mode like TV Encoder.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/gpu/drm/zte/zx_vou.c | 53 +++++++++++++++++++++++++++++++++++++--
drivers/gpu/drm/zte/zx_vou_regs.h | 15 +++++++++++
2 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 3056b41df518..8c4f0e2885f3 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -40,6 +40,7 @@ struct zx_crtc_regs {
u32 fir_active;
u32 fir_htiming;
u32 fir_vtiming;
+ u32 sec_vtiming;
u32 timing_shift;
u32 timing_pi_shift;
};
@@ -48,6 +49,7 @@ struct zx_crtc_regs {
.fir_active = FIR_MAIN_ACTIVE,
.fir_htiming = FIR_MAIN_H_TIMING,
.fir_vtiming = FIR_MAIN_V_TIMING,
+ .sec_vtiming = SEC_MAIN_V_TIMING,
.timing_shift = TIMING_MAIN_SHIFT,
.timing_pi_shift = TIMING_MAIN_PI_SHIFT,
};
@@ -56,6 +58,7 @@ struct zx_crtc_regs {
.fir_active = FIR_AUX_ACTIVE,
.fir_htiming = FIR_AUX_H_TIMING,
.fir_vtiming = FIR_AUX_V_TIMING,
+ .sec_vtiming = SEC_AUX_V_TIMING,
.timing_shift = TIMING_AUX_SHIFT,
.timing_pi_shift = TIMING_AUX_PI_SHIFT,
};
@@ -65,6 +68,10 @@ struct zx_crtc_bits {
u32 polarity_shift;
u32 int_frame_mask;
u32 tc_enable;
+ u32 sec_vactive_shift;
+ u32 sec_vactive_mask;
+ u32 interlace_select;
+ u32 pi_enable;
};
static const struct zx_crtc_bits main_crtc_bits = {
@@ -72,6 +79,10 @@ struct zx_crtc_bits {
.polarity_shift = MAIN_POL_SHIFT,
.int_frame_mask = TIMING_INT_MAIN_FRAME,
.tc_enable = MAIN_TC_EN,
+ .sec_vactive_shift = SEC_VACT_MAIN_SHIFT,
+ .sec_vactive_mask = SEC_VACT_MAIN_MASK,
+ .interlace_select = MAIN_INTERLACE_SEL,
+ .pi_enable = MAIN_PI_EN,
};
static const struct zx_crtc_bits aux_crtc_bits = {
@@ -79,6 +90,10 @@ struct zx_crtc_bits {
.polarity_shift = AUX_POL_SHIFT,
.int_frame_mask = TIMING_INT_AUX_FRAME,
.tc_enable = AUX_TC_EN,
+ .sec_vactive_shift = SEC_VACT_AUX_SHIFT,
+ .sec_vactive_mask = SEC_VACT_AUX_MASK,
+ .interlace_select = AUX_INTERLACE_SEL,
+ .pi_enable = AUX_PI_EN,
};
struct zx_crtc {
@@ -196,19 +211,26 @@ static inline void vou_chn_set_update(struct zx_crtc *zcrtc)
static void zx_crtc_enable(struct drm_crtc *crtc)
{
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
+ bool interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
struct zx_crtc *zcrtc = to_zx_crtc(crtc);
struct zx_vou_hw *vou = zcrtc->vou;
const struct zx_crtc_regs *regs = zcrtc->regs;
const struct zx_crtc_bits *bits = zcrtc->bits;
struct videomode vm;
+ u32 vactive;
u32 pol = 0;
u32 val;
+ u32 mask;
int ret;
drm_display_mode_to_videomode(mode, &vm);
/* Set up timing parameters */
- val = V_ACTIVE(vm.vactive - 1);
+ vactive = vm.vactive;
+ if (interlaced)
+ vactive /= 2;
+
+ val = V_ACTIVE(vactive - 1);
val |= H_ACTIVE(vm.hactive - 1);
zx_writel(vou->timing + regs->fir_active, val);
@@ -222,6 +244,22 @@ static void zx_crtc_enable(struct drm_crtc *crtc)
val |= FRONT_PORCH(vm.vfront_porch - 1);
zx_writel(vou->timing + regs->fir_vtiming, val);
+ if (interlaced) {
+ u32 shift = bits->sec_vactive_shift;
+ u32 mask = bits->sec_vactive_mask;
+
+ val = zx_readl(vou->timing + SEC_V_ACTIVE);
+ val &= ~mask;
+ val |= ((vactive - 1) << shift) & mask;
+ zx_writel(vou->timing + SEC_V_ACTIVE, val);
+
+ val = SYNC_WIDE(vm.vsync_len - 1);
+ /* sec_vbp = fir_vbp + 1 */
+ val |= BACK_PORCH(vm.vback_porch);
+ val |= FRONT_PORCH(vm.vfront_porch - 1);
+ zx_writel(vou->timing + regs->sec_vtiming, val);
+ }
+
/* Set up polarities */
if (vm.flags & DISPLAY_FLAGS_VSYNC_LOW)
pol |= 1 << POL_VSYNC_SHIFT;
@@ -232,9 +270,16 @@ static void zx_crtc_enable(struct drm_crtc *crtc)
pol << bits->polarity_shift);
/* Setup SHIFT register by following what ZTE BSP does */
- zx_writel(vou->timing + regs->timing_shift, H_SHIFT_VAL);
+ val = H_SHIFT_VAL;
+ if (interlaced)
+ val |= V_SHIFT_VAL << 16;
+ zx_writel(vou->timing + regs->timing_shift, val);
zx_writel(vou->timing + regs->timing_pi_shift, H_PI_SHIFT_VAL);
+ /* Progressive or interlace scan select */
+ mask = bits->interlace_select | bits->pi_enable;
+ zx_writel_mask(vou->timing + SCAN_CTRL, mask, interlaced ? mask : 0);
+
/* Enable TIMING_CTRL */
zx_writel_mask(vou->timing + TIMING_TC_ENABLE, bits->tc_enable,
bits->tc_enable);
@@ -245,6 +290,10 @@ static void zx_crtc_enable(struct drm_crtc *crtc)
zx_writel_mask(zcrtc->chnreg + CHN_CTRL1, CHN_SCREEN_H_MASK,
vm.vactive << CHN_SCREEN_H_SHIFT);
+ /* Configure channel interlace buffer control */
+ zx_writel_mask(zcrtc->chnreg + CHN_INTERLACE_BUF_CTRL, CHN_INTERLACE_EN,
+ interlaced ? CHN_INTERLACE_EN : 0);
+
/* Update channel */
vou_chn_set_update(zcrtc);
diff --git a/drivers/gpu/drm/zte/zx_vou_regs.h b/drivers/gpu/drm/zte/zx_vou_regs.h
index 193c1ce01fe7..e6ed844e068a 100644
--- a/drivers/gpu/drm/zte/zx_vou_regs.h
+++ b/drivers/gpu/drm/zte/zx_vou_regs.h
@@ -75,6 +75,8 @@
#define CHN_SCREEN_H_SHIFT 5
#define CHN_SCREEN_H_MASK (0x1fff << CHN_SCREEN_H_SHIFT)
#define CHN_UPDATE 0x08
+#define CHN_INTERLACE_BUF_CTRL 0x24
+#define CHN_INTERLACE_EN BIT(2)
/* TIMING_CTRL registers */
#define TIMING_TC_ENABLE 0x04
@@ -117,6 +119,19 @@
#define TIMING_MAIN_SHIFT 0x2c
#define TIMING_AUX_SHIFT 0x30
#define H_SHIFT_VAL 0x0048
+#define V_SHIFT_VAL 0x0001
+#define SCAN_CTRL 0x34
+#define AUX_PI_EN BIT(19)
+#define MAIN_PI_EN BIT(18)
+#define AUX_INTERLACE_SEL BIT(1)
+#define MAIN_INTERLACE_SEL BIT(0)
+#define SEC_V_ACTIVE 0x38
+#define SEC_VACT_MAIN_SHIFT 0
+#define SEC_VACT_MAIN_MASK (0xffff << SEC_VACT_MAIN_SHIFT)
+#define SEC_VACT_AUX_SHIFT 16
+#define SEC_VACT_AUX_MASK (0xffff << SEC_VACT_AUX_SHIFT)
+#define SEC_MAIN_V_TIMING 0x3c
+#define SEC_AUX_V_TIMING 0x40
#define TIMING_MAIN_PI_SHIFT 0x68
#define TIMING_AUX_PI_SHIFT 0x6c
#define H_PI_SHIFT_VAL 0x000f
--
1.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 2/5] drm: zte: move struct vou_inf into zx_vou driver
From: Shawn Guo @ 2017-01-19 16:24 UTC (permalink / raw)
To: dri-devel
Cc: Mark Rutland, devicetree, Daniel Vetter, Baoyou Xie, Rob Herring,
Jun Nie
In-Reply-To: <1484843100-16284-1-git-send-email-shawnguo@kernel.org>
From: Shawn Guo <shawn.guo@linaro.org>
Although data in struct vou_inf is defined per output device, it doesn't
belong to the device itself but VOU control module. All these data can
just be defined in VOU driver, and output device driver only needs to
invoke VOU driver function with device ID to enable/disable specific
output device.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/gpu/drm/zte/zx_hdmi.c | 12 ++----------
drivers/gpu/drm/zte/zx_vou.c | 31 ++++++++++++++++++++++++-------
drivers/gpu/drm/zte/zx_vou.h | 11 ++---------
3 files changed, 28 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c
index 6bf6c364811e..2f1e278ab50e 100644
--- a/drivers/gpu/drm/zte/zx_hdmi.c
+++ b/drivers/gpu/drm/zte/zx_hdmi.c
@@ -53,13 +53,6 @@ struct zx_hdmi {
#define to_zx_hdmi(x) container_of(x, struct zx_hdmi, x)
-static const struct vou_inf vou_inf_hdmi = {
- .id = VOU_HDMI,
- .data_sel = VOU_YUV444,
- .clocks_en_bits = BIT(24) | BIT(18) | BIT(6),
- .clocks_sel_bits = BIT(13) | BIT(2),
-};
-
static inline u8 hdmi_readb(struct zx_hdmi *hdmi, u16 offset)
{
return readl_relaxed(hdmi->mmio + offset * 4);
@@ -238,14 +231,14 @@ static void zx_hdmi_encoder_enable(struct drm_encoder *encoder)
zx_hdmi_hw_enable(hdmi);
- vou_inf_enable(hdmi->inf, encoder->crtc);
+ vou_inf_enable(VOU_HDMI, encoder->crtc);
}
static void zx_hdmi_encoder_disable(struct drm_encoder *encoder)
{
struct zx_hdmi *hdmi = to_zx_hdmi(encoder);
- vou_inf_disable(hdmi->inf, encoder->crtc);
+ vou_inf_disable(VOU_HDMI, encoder->crtc);
zx_hdmi_hw_disable(hdmi);
@@ -523,7 +516,6 @@ static int zx_hdmi_bind(struct device *dev, struct device *master, void *data)
hdmi->dev = dev;
hdmi->drm = drm;
- hdmi->inf = &vou_inf_hdmi;
dev_set_drvdata(dev, hdmi);
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 8c4f0e2885f3..c48704b4425a 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -158,6 +158,21 @@ struct zx_vou_hw {
struct zx_crtc *aux_crtc;
};
+struct vou_inf {
+ enum vou_inf_id id;
+ enum vou_inf_data_sel data_sel;
+ u32 clocks_en_bits;
+ u32 clocks_sel_bits;
+};
+
+static struct vou_inf vou_infs[] = {
+ [VOU_HDMI] = {
+ .data_sel = VOU_YUV444,
+ .clocks_en_bits = BIT(24) | BIT(18) | BIT(6),
+ .clocks_sel_bits = BIT(13) | BIT(2),
+ },
+};
+
static inline struct zx_vou_hw *crtc_to_vou(struct drm_crtc *crtc)
{
struct zx_crtc *zcrtc = to_zx_crtc(crtc);
@@ -165,20 +180,21 @@ static inline struct zx_vou_hw *crtc_to_vou(struct drm_crtc *crtc)
return zcrtc->vou;
}
-void vou_inf_enable(const struct vou_inf *inf, struct drm_crtc *crtc)
+void vou_inf_enable(enum vou_inf_id id, struct drm_crtc *crtc)
{
struct zx_crtc *zcrtc = to_zx_crtc(crtc);
struct zx_vou_hw *vou = zcrtc->vou;
+ struct vou_inf *inf = &vou_infs[id];
bool is_main = zcrtc->chn_type == VOU_CHN_MAIN;
- u32 data_sel_shift = inf->id << 1;
+ u32 data_sel_shift = id << 1;
/* Select data format */
zx_writel_mask(vou->vouctl + VOU_INF_DATA_SEL, 0x3 << data_sel_shift,
inf->data_sel << data_sel_shift);
/* Select channel */
- zx_writel_mask(vou->vouctl + VOU_INF_CH_SEL, 0x1 << inf->id,
- zcrtc->chn_type << inf->id);
+ zx_writel_mask(vou->vouctl + VOU_INF_CH_SEL, 0x1 << id,
+ zcrtc->chn_type << id);
/* Select interface clocks */
zx_writel_mask(vou->vouctl + VOU_CLK_SEL, inf->clocks_sel_bits,
@@ -189,15 +205,16 @@ void vou_inf_enable(const struct vou_inf *inf, struct drm_crtc *crtc)
inf->clocks_en_bits);
/* Enable the device */
- zx_writel_mask(vou->vouctl + VOU_INF_EN, 1 << inf->id, 1 << inf->id);
+ zx_writel_mask(vou->vouctl + VOU_INF_EN, 1 << id, 1 << id);
}
-void vou_inf_disable(const struct vou_inf *inf, struct drm_crtc *crtc)
+void vou_inf_disable(enum vou_inf_id id, struct drm_crtc *crtc)
{
struct zx_vou_hw *vou = crtc_to_vou(crtc);
+ struct vou_inf *inf = &vou_infs[id];
/* Disable the device */
- zx_writel_mask(vou->vouctl + VOU_INF_EN, 1 << inf->id, 0);
+ zx_writel_mask(vou->vouctl + VOU_INF_EN, 1 << id, 0);
/* Disable interface clocks */
zx_writel_mask(vou->vouctl + VOU_CLK_EN, inf->clocks_en_bits, 0);
diff --git a/drivers/gpu/drm/zte/zx_vou.h b/drivers/gpu/drm/zte/zx_vou.h
index 4b4339be641b..a41a0ad49857 100644
--- a/drivers/gpu/drm/zte/zx_vou.h
+++ b/drivers/gpu/drm/zte/zx_vou.h
@@ -30,15 +30,8 @@ enum vou_inf_data_sel {
VOU_RGB_666 = 3,
};
-struct vou_inf {
- enum vou_inf_id id;
- enum vou_inf_data_sel data_sel;
- u32 clocks_en_bits;
- u32 clocks_sel_bits;
-};
-
-void vou_inf_enable(const struct vou_inf *inf, struct drm_crtc *crtc);
-void vou_inf_disable(const struct vou_inf *inf, struct drm_crtc *crtc);
+void vou_inf_enable(enum vou_inf_id id, struct drm_crtc *crtc);
+void vou_inf_disable(enum vou_inf_id id, struct drm_crtc *crtc);
int zx_vou_enable_vblank(struct drm_device *drm, unsigned int pipe);
void zx_vou_disable_vblank(struct drm_device *drm, unsigned int pipe);
--
1.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 3/5] drm: zte: add function to configure vou_ctrl dividers
From: Shawn Guo @ 2017-01-19 16:24 UTC (permalink / raw)
To: dri-devel
Cc: Mark Rutland, devicetree, Daniel Vetter, Baoyou Xie, Rob Herring,
Jun Nie
In-Reply-To: <1484843100-16284-1-git-send-email-shawnguo@kernel.org>
From: Shawn Guo <shawn.guo@linaro.org>
The clock control module (CRM) cannot always provide desired frequency
for all VOU output devices. That's why VOU integrates a few dividers
to further divide the clocks from CRM. Let's add an interface for
configuring these dividers.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/gpu/drm/zte/zx_vou.c | 79 +++++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/zte/zx_vou.h | 25 +++++++++++++
drivers/gpu/drm/zte/zx_vou_regs.h | 16 ++++++++
3 files changed, 120 insertions(+)
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index c48704b4425a..98f0f51f9748 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -72,6 +72,13 @@ struct zx_crtc_bits {
u32 sec_vactive_mask;
u32 interlace_select;
u32 pi_enable;
+ u32 div_vga_shift;
+ u32 div_pic_shift;
+ u32 div_tvenc_shift;
+ u32 div_hdmi_pnx_shift;
+ u32 div_hdmi_shift;
+ u32 div_inf_shift;
+ u32 div_layer_shift;
};
static const struct zx_crtc_bits main_crtc_bits = {
@@ -83,6 +90,13 @@ struct zx_crtc_bits {
.sec_vactive_mask = SEC_VACT_MAIN_MASK,
.interlace_select = MAIN_INTERLACE_SEL,
.pi_enable = MAIN_PI_EN,
+ .div_vga_shift = VGA_MAIN_DIV_SHIFT,
+ .div_pic_shift = PIC_MAIN_DIV_SHIFT,
+ .div_tvenc_shift = TVENC_MAIN_DIV_SHIFT,
+ .div_hdmi_pnx_shift = HDMI_MAIN_PNX_DIV_SHIFT,
+ .div_hdmi_shift = HDMI_MAIN_DIV_SHIFT,
+ .div_inf_shift = INF_MAIN_DIV_SHIFT,
+ .div_layer_shift = LAYER_MAIN_DIV_SHIFT,
};
static const struct zx_crtc_bits aux_crtc_bits = {
@@ -94,6 +108,13 @@ struct zx_crtc_bits {
.sec_vactive_mask = SEC_VACT_AUX_MASK,
.interlace_select = AUX_INTERLACE_SEL,
.pi_enable = AUX_PI_EN,
+ .div_vga_shift = VGA_AUX_DIV_SHIFT,
+ .div_pic_shift = PIC_AUX_DIV_SHIFT,
+ .div_tvenc_shift = TVENC_AUX_DIV_SHIFT,
+ .div_hdmi_pnx_shift = HDMI_AUX_PNX_DIV_SHIFT,
+ .div_hdmi_shift = HDMI_AUX_DIV_SHIFT,
+ .div_inf_shift = INF_AUX_DIV_SHIFT,
+ .div_layer_shift = LAYER_AUX_DIV_SHIFT,
};
struct zx_crtc {
@@ -220,6 +241,64 @@ void vou_inf_disable(enum vou_inf_id id, struct drm_crtc *crtc)
zx_writel_mask(vou->vouctl + VOU_CLK_EN, inf->clocks_en_bits, 0);
}
+void zx_vou_config_dividers(struct drm_crtc *crtc,
+ struct vou_div_config *configs, int num)
+{
+ struct zx_crtc *zcrtc = to_zx_crtc(crtc);
+ struct zx_vou_hw *vou = zcrtc->vou;
+ const struct zx_crtc_bits *bits = zcrtc->bits;
+ int i;
+
+ /* Clear update flag bit */
+ zx_writel_mask(vou->vouctl + VOU_DIV_PARA, DIV_PARA_UPDATE, 0);
+
+ for (i = 0; i < num; i++) {
+ struct vou_div_config *cfg = configs + i;
+ u32 reg, shift;
+
+ switch (cfg->id) {
+ case VOU_DIV_VGA:
+ reg = VOU_CLK_SEL;
+ shift = bits->div_vga_shift;
+ break;
+ case VOU_DIV_PIC:
+ reg = VOU_CLK_SEL;
+ shift = bits->div_pic_shift;
+ break;
+ case VOU_DIV_TVENC:
+ reg = VOU_DIV_PARA;
+ shift = bits->div_tvenc_shift;
+ break;
+ case VOU_DIV_HDMI_PNX:
+ reg = VOU_DIV_PARA;
+ shift = bits->div_hdmi_pnx_shift;
+ break;
+ case VOU_DIV_HDMI:
+ reg = VOU_DIV_PARA;
+ shift = bits->div_hdmi_shift;
+ break;
+ case VOU_DIV_INF:
+ reg = VOU_DIV_PARA;
+ shift = bits->div_inf_shift;
+ break;
+ case VOU_DIV_LAYER:
+ reg = VOU_DIV_PARA;
+ shift = bits->div_layer_shift;
+ break;
+ default:
+ continue;
+ }
+
+ /* Each divider occupies 3 bits */
+ zx_writel_mask(vou->vouctl + reg, 0x7 << shift,
+ cfg->val << shift);
+ }
+
+ /* Set update flag bit to get dividers effected */
+ zx_writel_mask(vou->vouctl + VOU_DIV_PARA, DIV_PARA_UPDATE,
+ DIV_PARA_UPDATE);
+}
+
static inline void vou_chn_set_update(struct zx_crtc *zcrtc)
{
zx_writel(zcrtc->chnreg + CHN_UPDATE, 1);
diff --git a/drivers/gpu/drm/zte/zx_vou.h b/drivers/gpu/drm/zte/zx_vou.h
index a41a0ad49857..0dae4faefac4 100644
--- a/drivers/gpu/drm/zte/zx_vou.h
+++ b/drivers/gpu/drm/zte/zx_vou.h
@@ -33,6 +33,31 @@ enum vou_inf_data_sel {
void vou_inf_enable(enum vou_inf_id id, struct drm_crtc *crtc);
void vou_inf_disable(enum vou_inf_id id, struct drm_crtc *crtc);
+enum vou_div_id {
+ VOU_DIV_VGA,
+ VOU_DIV_PIC,
+ VOU_DIV_TVENC,
+ VOU_DIV_HDMI_PNX,
+ VOU_DIV_HDMI,
+ VOU_DIV_INF,
+ VOU_DIV_LAYER,
+};
+
+enum vou_div_val {
+ VOU_DIV_1 = 0,
+ VOU_DIV_2 = 1,
+ VOU_DIV_4 = 3,
+ VOU_DIV_8 = 7,
+};
+
+struct vou_div_config {
+ enum vou_div_id id;
+ enum vou_div_val val;
+};
+
+void zx_vou_config_dividers(struct drm_crtc *crtc,
+ struct vou_div_config *configs, int num);
+
int zx_vou_enable_vblank(struct drm_device *drm, unsigned int pipe);
void zx_vou_disable_vblank(struct drm_device *drm, unsigned int pipe);
diff --git a/drivers/gpu/drm/zte/zx_vou_regs.h b/drivers/gpu/drm/zte/zx_vou_regs.h
index e6ed844e068a..552772137cf0 100644
--- a/drivers/gpu/drm/zte/zx_vou_regs.h
+++ b/drivers/gpu/drm/zte/zx_vou_regs.h
@@ -176,11 +176,27 @@
#define VOU_INF_DATA_SEL 0x08
#define VOU_SOFT_RST 0x14
#define VOU_CLK_SEL 0x18
+#define VGA_AUX_DIV_SHIFT 29
+#define VGA_MAIN_DIV_SHIFT 26
+#define PIC_MAIN_DIV_SHIFT 23
+#define PIC_AUX_DIV_SHIFT 20
#define VOU_CLK_VL2_SEL BIT(8)
#define VOU_CLK_VL1_SEL BIT(7)
#define VOU_CLK_VL0_SEL BIT(6)
#define VOU_CLK_GL1_SEL BIT(5)
#define VOU_CLK_GL0_SEL BIT(4)
+#define VOU_DIV_PARA 0x1c
+#define DIV_PARA_UPDATE BIT(31)
+#define TVENC_AUX_DIV_SHIFT 28
+#define HDMI_AUX_PNX_DIV_SHIFT 25
+#define HDMI_MAIN_PNX_DIV_SHIFT 22
+#define HDMI_AUX_DIV_SHIFT 19
+#define HDMI_MAIN_DIV_SHIFT 16
+#define TVENC_MAIN_DIV_SHIFT 13
+#define INF_AUX_DIV_SHIFT 9
+#define INF_MAIN_DIV_SHIFT 6
+#define LAYER_AUX_DIV_SHIFT 3
+#define LAYER_MAIN_DIV_SHIFT 0
#define VOU_CLK_REQEN 0x20
#define VOU_CLK_EN 0x24
--
1.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 4/5] dt: add bindings for ZTE tvenc device
From: Shawn Guo @ 2017-01-19 16:24 UTC (permalink / raw)
To: dri-devel
Cc: Mark Rutland, devicetree, Daniel Vetter, Baoyou Xie, Rob Herring,
Jun Nie
In-Reply-To: <1484843100-16284-1-git-send-email-shawnguo@kernel.org>
From: Shawn Guo <shawn.guo@linaro.org>
It adds bindings doc for ZTE VOU TV Encoder device.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
Documentation/devicetree/bindings/display/zte,vou.txt | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt b/Documentation/devicetree/bindings/display/zte,vou.txt
index 740e5bd2e4f7..9c356284232b 100644
--- a/Documentation/devicetree/bindings/display/zte,vou.txt
+++ b/Documentation/devicetree/bindings/display/zte,vou.txt
@@ -49,6 +49,15 @@ Required properties:
"osc_clk"
"xclk"
+* TV Encoder output device
+
+Required properties:
+ - compatible: should be "zte,zx296718-tvenc"
+ - reg: Physical base address and length of the TVENC device IO region
+ - zte,tvenc-power-control: the phandle to SYSCTRL block followed by two
+ integer cells. The first cell is the offset of SYSCTRL register used
+ to control TV Encoder DAC power, and the second cell is the bit mask.
+
Example:
vou: vou@1440000 {
@@ -81,4 +90,10 @@ vou: vou@1440000 {
<&topcrm HDMI_XCLK>;
clock-names = "osc_cec", "osc_clk", "xclk";
};
+
+ tvenc: tvenc@2000 {
+ compatible = "zte,zx296718-tvenc";
+ reg = <0x2000 0x1000>;
+ zte,tvenc-power-control = <&sysctrl 0x170 0x10>;
+ };
};
--
1.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 5/5] drm: zte: add tvenc driver support
From: Shawn Guo @ 2017-01-19 16:25 UTC (permalink / raw)
To: dri-devel
Cc: Mark Rutland, devicetree, Daniel Vetter, Baoyou Xie, Rob Herring,
Jun Nie
In-Reply-To: <1484843100-16284-1-git-send-email-shawnguo@kernel.org>
From: Shawn Guo <shawn.guo@linaro.org>
It adds the TV Encoder driver to support video output in PAL and NTSC
format. The driver uses syscon/regmap interface to configure register
bit sitting in SYSCTRL module for DAC power control.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/gpu/drm/zte/Makefile | 1 +
drivers/gpu/drm/zte/zx_drm_drv.c | 1 +
drivers/gpu/drm/zte/zx_drm_drv.h | 1 +
drivers/gpu/drm/zte/zx_tvenc.c | 416 ++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/zte/zx_tvenc_regs.h | 31 +++
drivers/gpu/drm/zte/zx_vou.c | 5 +
6 files changed, 455 insertions(+)
create mode 100644 drivers/gpu/drm/zte/zx_tvenc.c
create mode 100644 drivers/gpu/drm/zte/zx_tvenc_regs.h
diff --git a/drivers/gpu/drm/zte/Makefile b/drivers/gpu/drm/zte/Makefile
index 699180bfd57c..01352b56c418 100644
--- a/drivers/gpu/drm/zte/Makefile
+++ b/drivers/gpu/drm/zte/Makefile
@@ -2,6 +2,7 @@ zxdrm-y := \
zx_drm_drv.o \
zx_hdmi.o \
zx_plane.o \
+ zx_tvenc.o \
zx_vou.o
obj-$(CONFIG_DRM_ZTE) += zxdrm.o
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index 3e76f72c92ff..13081fed902d 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -247,6 +247,7 @@ static int zx_drm_remove(struct platform_device *pdev)
static struct platform_driver *drivers[] = {
&zx_crtc_driver,
&zx_hdmi_driver,
+ &zx_tvenc_driver,
&zx_drm_platform_driver,
};
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.h b/drivers/gpu/drm/zte/zx_drm_drv.h
index e65cd18a6cba..5ca035b079c7 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.h
+++ b/drivers/gpu/drm/zte/zx_drm_drv.h
@@ -13,6 +13,7 @@
extern struct platform_driver zx_crtc_driver;
extern struct platform_driver zx_hdmi_driver;
+extern struct platform_driver zx_tvenc_driver;
static inline u32 zx_readl(void __iomem *reg)
{
diff --git a/drivers/gpu/drm/zte/zx_tvenc.c b/drivers/gpu/drm/zte/zx_tvenc.c
new file mode 100644
index 000000000000..5a6cff1ff8a8
--- /dev/null
+++ b/drivers/gpu/drm/zte/zx_tvenc.c
@@ -0,0 +1,416 @@
+/*
+ * Copyright 2017 Linaro Ltd.
+ * Copyright 2017 ZTE Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/component.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drmP.h>
+
+#include "zx_drm_drv.h"
+#include "zx_tvenc_regs.h"
+#include "zx_vou.h"
+
+struct zx_tvenc_pwrctrl {
+ struct regmap *regmap;
+ u32 reg;
+ u32 mask;
+};
+
+struct zx_tvenc {
+ struct drm_connector connector;
+ struct drm_encoder encoder;
+ struct device *dev;
+ void __iomem *mmio;
+ const struct vou_inf *inf;
+ struct zx_tvenc_pwrctrl pwrctrl;
+};
+
+#define to_zx_tvenc(x) container_of(x, struct zx_tvenc, x)
+
+struct zx_tvenc_mode {
+ char *name;
+ u32 hdisplay;
+ u32 vdisplay;
+ u32 hfp;
+ u32 hbp;
+ u32 hsw;
+ u32 vfp;
+ u32 vbp;
+ u32 vsw;
+ u32 video_info;
+ u32 video_res;
+ u32 field1_param;
+ u32 field2_param;
+ u32 burst_line_odd1;
+ u32 burst_line_even1;
+ u32 burst_line_odd2;
+ u32 burst_line_even2;
+ u32 line_timing_param;
+ u32 weight_value;
+ u32 blank_black_level;
+ u32 burst_level;
+ u32 control_param;
+ u32 sub_carrier_phase1;
+ u32 phase_line_incr_cvbs;
+};
+
+static const struct zx_tvenc_mode tvenc_modes[] = {
+ {
+ .name = "PAL",
+ .hdisplay = 720,
+ .vdisplay = 576,
+ .hfp = 12,
+ .hbp = 130,
+ .hsw = 2,
+ .vfp = 2,
+ .vbp = 20,
+ .vsw = 2,
+ .video_info = 0x00040040,
+ .video_res = 0x05a9c760,
+ .field1_param = 0x0004d416,
+ .field2_param = 0x0009b94f,
+ .burst_line_odd1 = 0x0004d406,
+ .burst_line_even1 = 0x0009b53e,
+ .burst_line_odd2 = 0x0004d805,
+ .burst_line_even2 = 0x0009b93f,
+ .line_timing_param = 0x06a96fdf,
+ .weight_value = 0x00c188a0,
+ .blank_black_level = 0x0000fcfc,
+ .burst_level = 0x00001595,
+ .control_param = 0x00000001,
+ .sub_carrier_phase1 = 0x1504c566,
+ .phase_line_incr_cvbs = 0xc068db8c,
+ }, {
+ .name = "NTSC",
+ .hdisplay = 720,
+ .vdisplay = 480,
+ .hfp = 16,
+ .hbp = 120,
+ .hsw = 2,
+ .vfp = 3,
+ .vbp = 17,
+ .vsw = 2,
+ .video_info = 0x00040080,
+ .video_res = 0x05a8375a,
+ .field1_param = 0x00041817,
+ .field2_param = 0x0008351e,
+ .burst_line_odd1 = 0x00041006,
+ .burst_line_even1 = 0x0008290d,
+ .burst_line_odd2 = 0x00000000,
+ .burst_line_even2 = 0x00000000,
+ .line_timing_param = 0x06a8ef9e,
+ .weight_value = 0x00b68197,
+ .blank_black_level = 0x0000f0f0,
+ .burst_level = 0x0000009c,
+ .control_param = 0x00000001,
+ .sub_carrier_phase1 = 0x10f83e10,
+ .phase_line_incr_cvbs = 0x80000000,
+ },
+};
+
+static const struct zx_tvenc_mode *
+zx_tvenc_find_zmode(struct drm_display_mode *mode)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(tvenc_modes); i++) {
+ const struct zx_tvenc_mode *zmode = &tvenc_modes[i];
+
+ if (!strcmp(mode->name, zmode->name))
+ return zmode;
+ }
+
+ return NULL;
+}
+
+static void zx_tvenc_encoder_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adj_mode)
+{
+ struct zx_tvenc *tvenc = to_zx_tvenc(encoder);
+ const struct zx_tvenc_mode *zmode;
+ struct vou_div_config configs[] = {
+ { VOU_DIV_INF, VOU_DIV_4 },
+ { VOU_DIV_TVENC, VOU_DIV_1 },
+ { VOU_DIV_LAYER, VOU_DIV_2 },
+ };
+
+ zx_vou_config_dividers(encoder->crtc, configs, ARRAY_SIZE(configs));
+
+ zmode = zx_tvenc_find_zmode(mode);
+ if (!zmode) {
+ DRM_DEV_ERROR(tvenc->dev, "failed to find zmode\n");
+ return;
+ }
+
+ zx_writel(tvenc->mmio + VENC_VIDEO_INFO, zmode->video_info);
+ zx_writel(tvenc->mmio + VENC_VIDEO_RES, zmode->video_res);
+ zx_writel(tvenc->mmio + VENC_FIELD1_PARAM, zmode->field1_param);
+ zx_writel(tvenc->mmio + VENC_FIELD2_PARAM, zmode->field2_param);
+ zx_writel(tvenc->mmio + VENC_LINE_O_1, zmode->burst_line_odd1);
+ zx_writel(tvenc->mmio + VENC_LINE_E_1, zmode->burst_line_even1);
+ zx_writel(tvenc->mmio + VENC_LINE_O_2, zmode->burst_line_odd2);
+ zx_writel(tvenc->mmio + VENC_LINE_E_2, zmode->burst_line_even2);
+ zx_writel(tvenc->mmio + VENC_LINE_TIMING_PARAM,
+ zmode->line_timing_param);
+ zx_writel(tvenc->mmio + VENC_WEIGHT_VALUE, zmode->weight_value);
+ zx_writel(tvenc->mmio + VENC_BLANK_BLACK_LEVEL,
+ zmode->blank_black_level);
+ zx_writel(tvenc->mmio + VENC_BURST_LEVEL, zmode->burst_level);
+ zx_writel(tvenc->mmio + VENC_CONTROL_PARAM, zmode->control_param);
+ zx_writel(tvenc->mmio + VENC_SUB_CARRIER_PHASE1,
+ zmode->sub_carrier_phase1);
+ zx_writel(tvenc->mmio + VENC_PHASE_LINE_INCR_CVBS,
+ zmode->phase_line_incr_cvbs);
+}
+
+static void zx_tvenc_encoder_enable(struct drm_encoder *encoder)
+{
+ struct zx_tvenc *tvenc = to_zx_tvenc(encoder);
+ struct zx_tvenc_pwrctrl *pwrctrl = &tvenc->pwrctrl;
+
+ /* Set bit to power up TVENC DAC */
+ regmap_update_bits(pwrctrl->regmap, pwrctrl->reg, pwrctrl->mask,
+ pwrctrl->mask);
+
+ vou_inf_enable(VOU_TV_ENC, encoder->crtc);
+
+ zx_writel(tvenc->mmio + VENC_ENABLE, 1);
+}
+
+static void zx_tvenc_encoder_disable(struct drm_encoder *encoder)
+{
+ struct zx_tvenc *tvenc = to_zx_tvenc(encoder);
+ struct zx_tvenc_pwrctrl *pwrctrl = &tvenc->pwrctrl;
+
+ zx_writel(tvenc->mmio + VENC_ENABLE, 0);
+
+ vou_inf_disable(VOU_TV_ENC, encoder->crtc);
+
+ /* Clear bit to power down TVENC DAC */
+ regmap_update_bits(pwrctrl->regmap, pwrctrl->reg, pwrctrl->mask, 0);
+}
+
+static const struct drm_encoder_helper_funcs zx_tvenc_encoder_helper_funcs = {
+ .enable = zx_tvenc_encoder_enable,
+ .disable = zx_tvenc_encoder_disable,
+ .mode_set = zx_tvenc_encoder_mode_set,
+};
+
+static const struct drm_encoder_funcs zx_tvenc_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
+static void zx_tvenc_mode_to_drm_mode(const struct zx_tvenc_mode *zmode,
+ struct drm_display_mode *mode)
+{
+ strcpy(mode->name, zmode->name);
+
+ mode->type = DRM_MODE_TYPE_DRIVER;
+ mode->flags = DRM_MODE_FLAG_INTERLACE;
+ mode->flags |= DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC;
+
+ /*
+ * The CRM cannot directly provide such a low rate, and we have to
+ * ask a multiflied rate from CRM and use the divider in VOU to get
+ * the disired one.
+ */
+ mode->clock = 13500 * 4;
+
+ mode->hdisplay = zmode->hdisplay;
+ mode->hsync_start = mode->hdisplay + zmode->hfp;
+ mode->hsync_end = mode->hsync_start + zmode->hsw;
+ mode->htotal = mode->hsync_end + zmode->hbp;
+
+ mode->vdisplay = zmode->vdisplay;
+ mode->vsync_start = mode->vdisplay + zmode->vfp;
+ mode->vsync_end = mode->vsync_start + zmode->vsw;
+ mode->vtotal = mode->vsync_end + zmode->vbp;
+}
+
+static int zx_tvenc_connector_get_modes(struct drm_connector *connector)
+{
+ struct zx_tvenc *tvenc = to_zx_tvenc(connector);
+ struct device *dev = tvenc->dev;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(tvenc_modes); i++) {
+ struct drm_display_mode *mode;
+ const struct zx_tvenc_mode *zmode = &tvenc_modes[i];
+
+ mode = drm_mode_create(connector->dev);
+ if (!mode) {
+ DRM_DEV_ERROR(dev, "failed to create drm mode\n");
+ return 0;
+ }
+
+ zx_tvenc_mode_to_drm_mode(zmode, mode);
+ drm_mode_probed_add(connector, mode);
+ }
+
+ return i;
+}
+
+static enum drm_mode_status
+zx_tvenc_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+ return MODE_OK;
+}
+
+static struct drm_connector_helper_funcs zx_tvenc_connector_helper_funcs = {
+ .get_modes = zx_tvenc_connector_get_modes,
+ .mode_valid = zx_tvenc_connector_mode_valid,
+};
+
+static const struct drm_connector_funcs zx_tvenc_connector_funcs = {
+ .dpms = drm_atomic_helper_connector_dpms,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = drm_connector_cleanup,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int zx_tvenc_register(struct drm_device *drm, struct zx_tvenc *tvenc)
+{
+ struct drm_encoder *encoder = &tvenc->encoder;
+ struct drm_connector *connector = &tvenc->connector;
+
+ /*
+ * The tvenc is designed to use aux channel, as there is a deflicker
+ * block for the channel.
+ */
+ encoder->possible_crtcs = BIT(1);
+
+ drm_encoder_init(drm, encoder, &zx_tvenc_encoder_funcs,
+ DRM_MODE_ENCODER_TVDAC, NULL);
+ drm_encoder_helper_add(encoder, &zx_tvenc_encoder_helper_funcs);
+
+ connector->interlace_allowed = true;
+
+ drm_connector_init(drm, connector, &zx_tvenc_connector_funcs,
+ DRM_MODE_CONNECTOR_Composite);
+ drm_connector_helper_add(connector, &zx_tvenc_connector_helper_funcs);
+
+ drm_mode_connector_attach_encoder(connector, encoder);
+
+ return 0;
+}
+
+static int zx_tvenc_pwrctrl_init(struct zx_tvenc *tvenc)
+{
+ struct zx_tvenc_pwrctrl *pwrctrl = &tvenc->pwrctrl;
+ struct device *dev = tvenc->dev;
+ struct of_phandle_args out_args;
+ struct regmap *regmap;
+ int ret;
+
+ ret = of_parse_phandle_with_fixed_args(dev->of_node,
+ "zte,tvenc-power-control", 2, 0, &out_args);
+ if (ret)
+ return ret;
+
+ regmap = syscon_node_to_regmap(out_args.np);
+ if (IS_ERR(regmap)) {
+ ret = PTR_ERR(regmap);
+ goto out;
+ }
+
+ pwrctrl->regmap = regmap;
+ pwrctrl->reg = out_args.args[0];
+ pwrctrl->mask = out_args.args[1];
+
+out:
+ of_node_put(out_args.np);
+ return ret;
+}
+
+static int zx_tvenc_bind(struct device *dev, struct device *master, void *data)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct drm_device *drm = data;
+ struct resource *res;
+ struct zx_tvenc *tvenc;
+ int ret;
+
+ tvenc = devm_kzalloc(dev, sizeof(*tvenc), GFP_KERNEL);
+ if (!tvenc)
+ return -ENOMEM;
+
+ tvenc->dev = dev;
+ dev_set_drvdata(dev, tvenc);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ tvenc->mmio = devm_ioremap_resource(dev, res);
+ if (IS_ERR(tvenc->mmio)) {
+ ret = PTR_ERR(tvenc->mmio);
+ DRM_DEV_ERROR(dev, "failed to remap tvenc region: %d\n", ret);
+ return ret;
+ }
+
+ ret = zx_tvenc_pwrctrl_init(tvenc);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "failed to init power control: %d\n", ret);
+ return ret;
+ }
+
+ ret = zx_tvenc_register(drm, tvenc);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "failed to register tvenc: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void zx_tvenc_unbind(struct device *dev, struct device *master,
+ void *data)
+{
+ struct zx_tvenc *tvenc = dev_get_drvdata(dev);
+
+ tvenc->connector.funcs->destroy(&tvenc->connector);
+ tvenc->encoder.funcs->destroy(&tvenc->encoder);
+}
+
+static const struct component_ops zx_tvenc_component_ops = {
+ .bind = zx_tvenc_bind,
+ .unbind = zx_tvenc_unbind,
+};
+
+static int zx_tvenc_probe(struct platform_device *pdev)
+{
+ return component_add(&pdev->dev, &zx_tvenc_component_ops);
+}
+
+static int zx_tvenc_remove(struct platform_device *pdev)
+{
+ component_del(&pdev->dev, &zx_tvenc_component_ops);
+ return 0;
+}
+
+static const struct of_device_id zx_tvenc_of_match[] = {
+ { .compatible = "zte,zx296718-tvenc", },
+ { /* end */ },
+};
+MODULE_DEVICE_TABLE(of, zx_tvenc_of_match);
+
+struct platform_driver zx_tvenc_driver = {
+ .probe = zx_tvenc_probe,
+ .remove = zx_tvenc_remove,
+ .driver = {
+ .name = "zx-tvenc",
+ .of_match_table = zx_tvenc_of_match,
+ },
+};
diff --git a/drivers/gpu/drm/zte/zx_tvenc_regs.h b/drivers/gpu/drm/zte/zx_tvenc_regs.h
new file mode 100644
index 000000000000..bd91f5dcc1f3
--- /dev/null
+++ b/drivers/gpu/drm/zte/zx_tvenc_regs.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright 2017 Linaro Ltd.
+ * Copyright 2017 ZTE Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#ifndef __ZX_TVENC_REGS_H__
+#define __ZX_TVENC_REGS_H__
+
+#define VENC_VIDEO_INFO 0x04
+#define VENC_VIDEO_RES 0x08
+#define VENC_FIELD1_PARAM 0x10
+#define VENC_FIELD2_PARAM 0x14
+#define VENC_LINE_O_1 0x18
+#define VENC_LINE_E_1 0x1c
+#define VENC_LINE_O_2 0x20
+#define VENC_LINE_E_2 0x24
+#define VENC_LINE_TIMING_PARAM 0x28
+#define VENC_WEIGHT_VALUE 0x2c
+#define VENC_BLANK_BLACK_LEVEL 0x30
+#define VENC_BURST_LEVEL 0x34
+#define VENC_CONTROL_PARAM 0x3c
+#define VENC_SUB_CARRIER_PHASE1 0x40
+#define VENC_PHASE_LINE_INCR_CVBS 0x48
+#define VENC_ENABLE 0xa8
+
+#endif /* __ZX_TVENC_REGS_H__ */
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 98f0f51f9748..61d4ff709d83 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -192,6 +192,11 @@ struct vou_inf {
.clocks_en_bits = BIT(24) | BIT(18) | BIT(6),
.clocks_sel_bits = BIT(13) | BIT(2),
},
+ [VOU_TV_ENC] = {
+ .data_sel = VOU_YUV444,
+ .clocks_en_bits = BIT(15),
+ .clocks_sel_bits = BIT(11) | BIT(0),
+ },
};
static inline struct zx_vou_hw *crtc_to_vou(struct drm_crtc *crtc)
--
1.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: Initializing MAC address at run-time
From: Uwe Kleine-König @ 2017-01-19 16:26 UTC (permalink / raw)
To: Mason
Cc: Mark Rutland, DT, Arnd Bergmann, Kevin Hilman, netdev,
Thibaud Cornic, Linux ARM
In-Reply-To: <79fef293-74ec-dece-1941-747cd55f1ca2@free.fr>
Hello,
On Thu, Jan 19, 2017 at 04:31:56PM +0100, Mason wrote:
> Do you agree that such boot loader would execute code that is roughly
> identical to the one posted for illustration purposes?
> 1. find the MAC address to use for eth0
> 2. find the eth0 node in the DT
> 3. insert the right prop in the eth0 node
yes.
> In which case, it seems a waste to add the DT library to the boot
> loader, when the operation can be done in Linux, which requires the
> DT library anyway. (Additionally, adding DT support to some custom
> legacy boot loader might be a complex task.)
With this reasoning you can discuss away the bootloader. Linux relies on
a bootloader for a reason. It's there to initialize RAM and some further
things that Linux might not be able to and provide a machine description
to Linux (either in form of a dtb or an ATAG list) such that Linux
doesn't need to fiddle with machine specific stuff in early init code.
> > c) Adapt the dtb before it is written to the boot medium.
>
> This is not applicable, as the DTB is not written to the board.
Ah, then adapt the dtb before it is put into the tftp folder.
> > d) Let the bootloader configure the device and teach the driver to pick
> > up the mac from the device's address space.
>
> I'm not sure what you call "the device" ?
The network device. IIRC the fec driver checks if there is something
configured in the two registers configuring the MAC before falling back
to a random MAC.
> > e) Accept that the mac address is random during development, and make
> > Userspace configure the MAC address, which is early enough for
> > production use.
>
> During development, some devs configure the DHCP server to provide
> a specific uImage and/or rootfs to their board, based on the MAC
> address. This scheme would fall apart with a random MAC.
>
> > Not sure d) is considered ok today, but some drivers have this feature.
> > I'd say b) is the best choice.
>
> In my mind, doing it early in Linux is similar in spirit to doing it
> at the boot loader stage, in that it's neatly separated from the rest
> of the setup.
Sure you can do this. But it won't be accepted mainline for sure.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v1 1/7] dt-bindings: display: add STM32 LTDC driver
From: Rob Herring @ 2017-01-19 16:29 UTC (permalink / raw)
To: Yannick Fertre
Cc: Alexandre TORGUE, Thierry Reding, David Airlie, Maxime Coquelin,
Russell King, Mark Rutland, Arnd Bergmann, Philippe Cornu,
Mickael Reulier, Gabriel FERNANDEZ, kernel-F5mvAk5X5gdBDgjK7y7TUQ,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484573344-11609-2-git-send-email-yannick.fertre-qxv4g6HH51o@public.gmane.org>
On Mon, Jan 16, 2017 at 02:28:58PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre <yannick.fertre-qxv4g6HH51o@public.gmane.org>
Changelog?
> ---
> .../devicetree/bindings/display/st,ltdc.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/st,ltdc.txt
>
> diff --git a/Documentation/devicetree/bindings/display/st,ltdc.txt b/Documentation/devicetree/bindings/display/st,ltdc.txt
> new file mode 100644
> index 0000000..20e89da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/st,ltdc.txt
> @@ -0,0 +1,57 @@
> +* STMicroelectronics STM32 lcd-tft display controller
> +
> +- st-display-subsystem: Master device for DRM sub-components
> + This device must be the parent of all the sub-components and is responsible
> + of bind them.
> + Required properties:
> + - compatible: "st,display-subsystem"
> + - ranges: to allow probing of subdevices
You have a single sub device. There is no need for this node.
> +- ltdc_host: lcd-tft display controller host
> + must be a sub-node of st-display-subsystem
> + Required properties:
> + - compatible: "st,ltdc"
Too generic. Needs to be SoC specific.
> + - reg: Physical base address of the IP registers and length of memory mapped region.
> + - clocks: from common clock binding: handle hardware IP needed clocks, the
> + number of clocks may depend of the SoC type.
No. You must be explicit on how many clocks and their order.
> + See ../clocks/clock-bindings.txt for details.
> + - clock-names: names of the clocks listed in clocks property in the same
> + order.
> + - resets: resets to be used by the device
ditto.
> + See ../reset/reset.txt for details.
> + - reset-names: names of the resets listed in resets property in the same
> + order.
You are missing this in the example. However, for a single entry, -names
is pointless.
> + Required nodes:
> + - Video port for RGB output.
> +
> +Example:
> +
> +/ {
> + ...
> + soc {
> + ...
> + st-display-subsystem {
> + compatible = "st,display-subsystem";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + dma-ranges;
> +
> + ltdc_host: stm32-ltdc@40016800 {
> + compatible = "st,ltdc";
> + reg = <0x40016800 0x200>;
> + interrupts = <88>, <89>;
> + resets = <&rcc 314>;
> + clocks = <&rcc 1 8>;
> + clock-names = "clk-lcd";
The 'clk-' part is redundant.
> + status = "disabled";
> +
> + port {
> + ltdc_out_rgb: endpoint {
> + };
> + };
> + };
> + };
> + ...
> + };
> +};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 1/7] dt-bindings: display: add STM32 LTDC driver
From: Rob Herring @ 2017-01-19 16:31 UTC (permalink / raw)
To: Yannick FERTRE
Cc: Mark Rutland, devicetree@vger.kernel.org, Alexandre TORGUE,
Arnd Bergmann, Russell King, dri-devel@lists.freedesktop.org,
Philippe CORNU, Laurent Pinchart, Maxime Coquelin,
Mickael REULIER, Gabriel FERNANDEZ,
linux-arm-kernel@lists.infradead.org, kernel@stlinux.com
In-Reply-To: <dfb3192a-d5b6-029e-b8cb-65a628a0c30b@st.com>
On Thu, Jan 19, 2017 at 04:16:01PM +0000, Yannick FERTRE wrote:
> On 01/16/2017 09:30 PM, Laurent Pinchart wrote:
> > Hi Yannick,
> >
> > Thank you for the patch.
> >
> > On Monday 16 Jan 2017 14:28:58 Yannick Fertre wrote:
> >> Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
> >> ---
> >> .../devicetree/bindings/display/st,ltdc.txt | 57 ++++++++++++++++++
> >> 1 file changed, 57 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/display/st,ltdc.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/display/st,ltdc.txt
> >> b/Documentation/devicetree/bindings/display/st,ltdc.txt new file mode
> >> 100644
> >> index 0000000..20e89da
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/st,ltdc.txt
> >> @@ -0,0 +1,57 @@
> >> +* STMicroelectronics STM32 lcd-tft display controller
> >> +
> >> +- st-display-subsystem: Master device for DRM sub-components
> >> + This device must be the parent of all the sub-components and is
> >> responsible
> >> + of bind them.
> >
> > Why do you need this ? At a quick glance the ltdc node should be enough.
> Hi Laurent,
> To prepare next device upstream of dsi, we need a master node
> "st-display-subsystem" and a sub node "st,ltdc". It's the same kind of
> node than st,stih4xx.
No, you don't. That's what OF graph is for. The DRM driver binds to the
LCD controller node and walks the graph to find the DSI node and then
the panel.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v1 3/7] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel
From: Rob Herring @ 2017-01-19 16:32 UTC (permalink / raw)
To: Yannick Fertre
Cc: Mark Rutland, devicetree, Alexandre TORGUE, Arnd Bergmann,
Russell King, dri-devel, Philippe Cornu, Maxime Coquelin,
Mickael Reulier, Gabriel FERNANDEZ, linux-arm-kernel, kernel
In-Reply-To: <1484573344-11609-4-git-send-email-yannick.fertre@st.com>
On Mon, Jan 16, 2017 at 02:29:00PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
> ---
> .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> new file mode 100644
> index 0000000..f59e3c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> @@ -0,0 +1,7 @@
> +Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "ampire,am-480272h3tmqw-t01h"
No GPIOs or power supply?
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> --
> 1.9.1
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 3/3] PCI: imx6: Add code to support i.MX7D
From: Andrey Smirnov @ 2017-01-19 16:36 UTC (permalink / raw)
To: linux-pci
Cc: Mark Rutland, devicetree, Richard Zhu, Andrey Smirnov, Shawn Guo,
linux-kernel, Rob Herring, Bjorn Helgaas, Lee Jones, yurovsky,
Fabio Estevam, linux-arm-kernel, Lucas Stach
In-Reply-To: <20170119163631.10668-1-andrew.smirnov@gmail.com>
Add various bits of code needed to support i.MX7D variant of the IP.
Cc: yurovsky@gmail.com
Cc: Richard Zhu <hongxing.zhu@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
.../devicetree/bindings/pci/fsl,imx6q-pcie.txt | 6 +-
drivers/pci/host/pci-imx6.c | 188 ++++++++++++++++++---
include/linux/mfd/syscon/imx7-gpc.h | 18 ++
include/linux/mfd/syscon/imx7-iomuxc-gpr.h | 4 +
include/linux/mfd/syscon/imx7-src.h | 18 ++
5 files changed, 208 insertions(+), 26 deletions(-)
create mode 100644 include/linux/mfd/syscon/imx7-gpc.h
create mode 100644 include/linux/mfd/syscon/imx7-src.h
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
index 83aeb1f..20b9382 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
@@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
and thus inherits all the common properties defined in designware-pcie.txt.
Required properties:
-- compatible: "fsl,imx6q-pcie", "fsl,imx6sx-pcie", "fsl,imx6qp-pcie"
+- compatible: "fsl,imx6q-pcie", "fsl,imx6sx-pcie",
+ "fsl,imx6qp-pcie", "fsl,imx7d-pcie"
- reg: base address and length of the PCIe controller
- interrupts: A list of interrupt outputs of the controller. Must contain an
entry for each entry in the interrupt-names property.
@@ -34,6 +35,9 @@ Additional required properties for imx6sx-pcie:
- clock names: Must include the following additional entries:
- "pcie_inbound_axi"
+Additional required properties for imx7d-pcie:
+- pcie-phy-supply: Should specify the regulator supplying PCIe PHY
+
Example:
pcie@0x01000000 {
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 574f026..f29148e 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -17,6 +17,9 @@
#include <linux/kernel.h>
#include <linux/mfd/syscon.h>
#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
+#include <linux/mfd/syscon/imx7-iomuxc-gpr.h>
+#include <linux/mfd/syscon/imx7-src.h>
+#include <linux/mfd/syscon/imx7-gpc.h>
#include <linux/module.h>
#include <linux/of_gpio.h>
#include <linux/of_device.h>
@@ -27,6 +30,7 @@
#include <linux/signal.h>
#include <linux/types.h>
#include <linux/interrupt.h>
+#include <linux/regulator/consumer.h>
#include "pcie-designware.h"
@@ -36,6 +40,7 @@ enum imx6_pcie_variants {
IMX6Q,
IMX6SX,
IMX6QP,
+ IMX7D,
};
struct imx6_pcie {
@@ -47,6 +52,8 @@ struct imx6_pcie {
struct clk *pcie_inbound_axi;
struct clk *pcie;
struct regmap *iomuxc_gpr;
+ struct regmap *src;
+ struct regmap *gpc;
enum imx6_pcie_variants variant;
u32 tx_deemph_gen1;
u32 tx_deemph_gen2_3p5db;
@@ -54,8 +61,14 @@ struct imx6_pcie {
u32 tx_swing_full;
u32 tx_swing_low;
int link_gen;
+ struct regulator *pcie_phy_regulator;
};
+/* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */
+#define PHY_PLL_LOCK_WAIT_MAX_RETRIES 2000
+#define PHY_PLL_LOCK_WAIT_USLEEP_MIN 50
+#define PHY_PLL_LOCK_WAIT_USLEEP_MAX 200
+
/* PCIe Root Complex registers (memory-mapped) */
#define PCIE_RC_LCR 0x7c
#define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN1 0x1
@@ -251,6 +264,16 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
u32 val, gpr1, gpr12;
switch (imx6_pcie->variant) {
+ case IMX7D:
+ regmap_update_bits(imx6_pcie->src,
+ SRC_PCIEPHY_RCR,
+ IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_G_RST,
+ IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_G_RST);
+ regmap_update_bits(imx6_pcie->src,
+ SRC_PCIEPHY_RCR,
+ IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_BTN,
+ IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_BTN);
+ break;
case IMX6SX:
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
IMX6SX_GPR12_PCIE_TEST_POWERDOWN,
@@ -333,11 +356,33 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
break;
+ case IMX7D:
+ break;
}
return ret;
}
+static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
+{
+ u32 val;
+ unsigned int retries;
+ struct pcie_port *pp = &imx6_pcie->pp;
+ struct device *dev = pp->dev;
+
+ for (retries = 0; retries < PHY_PLL_LOCK_WAIT_MAX_RETRIES; retries++) {
+ regmap_read(imx6_pcie->iomuxc_gpr, IOMUXC_GPR22, &val);
+
+ if (val & IMX7D_GPR22_PCIE_PHY_PLL_LOCKED)
+ return;
+
+ usleep_range(PHY_PLL_LOCK_WAIT_USLEEP_MIN,
+ PHY_PLL_LOCK_WAIT_USLEEP_MAX);
+ }
+
+ dev_err(dev, "PCIe PLL lock timeout\n");
+}
+
static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
{
struct pcie_port *pp = &imx6_pcie->pp;
@@ -381,6 +426,21 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
}
switch (imx6_pcie->variant) {
+ case IMX7D:
+ /* wait for more than 10us to release phy g_rst and btnrst */
+ udelay(10);
+ regmap_update_bits(imx6_pcie->src,
+ SRC_PCIEPHY_RCR,
+ IMX7D_SRC_PCIEPHY_RCR_PCIE_CTRL_APPS_EN, 0);
+ regmap_update_bits(imx6_pcie->src,
+ SRC_PCIEPHY_RCR,
+ IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_G_RST, 0);
+ regmap_update_bits(imx6_pcie->src,
+ SRC_PCIEPHY_RCR,
+ IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_BTN, 0);
+
+ imx7d_pcie_wait_for_phy_pll_lock(imx6_pcie);
+ break;
case IMX6SX:
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR5,
IMX6SX_GPR5_PCIE_BTNRST_RESET, 0);
@@ -407,35 +467,80 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
{
- if (imx6_pcie->variant == IMX6SX)
+ switch (imx6_pcie->variant) {
+ case IMX7D: {
+ int ret;
+ unsigned int reg, mapping;
+ struct pcie_port *pp = &imx6_pcie->pp;
+ struct device *dev = pp->dev;
+
+ regulator_set_voltage(imx6_pcie->pcie_phy_regulator,
+ 1000000, 1000000);
+ ret = regulator_enable(imx6_pcie->pcie_phy_regulator);
+ if (ret) {
+ dev_err(dev, "failed to enable pcie regulator.\n");
+ return;
+ }
+
+ /*
+ * Now that PHY regulator is enabled, do sofware
+ * power-up request by mapping PHY in A7 domain and
+ * setting power-up request bit
+ */
+ regmap_read(imx6_pcie->gpc, GPC_PGC_CPU_MAPPING, &mapping);
+ regmap_write(imx6_pcie->gpc, GPC_PGC_CPU_MAPPING,
+ mapping | IMX7D_PCIE_PHY_A7_DOMAIN);
+
+ regmap_update_bits(imx6_pcie->gpc, GPC_PU_PGC_SW_PUP_REQ,
+ IMX7D_PCIE_PHY_SW_PUP_REQ,
+ IMX7D_PCIE_PHY_SW_PUP_REQ);
+ /*
+ * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
+ * for PUP_REQ bit to be cleared
+ */
+ while (!regmap_read(imx6_pcie->gpc,
+ GPC_PU_PGC_SW_PUP_REQ, ®) &&
+ reg & IMX7D_PCIE_PHY_SW_PUP_REQ)
+ ;
+ regmap_write(imx6_pcie->gpc, GPC_PGC_CPU_MAPPING, mapping);
+
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
+ break;
+ }
+ case IMX6SX:
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
IMX6SX_GPR12_PCIE_RX_EQ_MASK,
IMX6SX_GPR12_PCIE_RX_EQ_2);
+ /* FALLTHROUGH */
+ default:
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
- regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
- IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
+ /* configure constant input signal to the pcie ctrl and phy */
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
+
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_DEEMPH_GEN1,
+ imx6_pcie->tx_deemph_gen1 << 0);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
+ imx6_pcie->tx_deemph_gen2_3p5db << 6);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
+ imx6_pcie->tx_deemph_gen2_6db << 12);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_SWING_FULL,
+ imx6_pcie->tx_swing_full << 18);
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
+ IMX6Q_GPR8_TX_SWING_LOW,
+ imx6_pcie->tx_swing_low << 25);
+ break;
+ }
- /* configure constant input signal to the pcie ctrl and phy */
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
IMX6Q_GPR12_DEVICE_TYPE, PCI_EXP_TYPE_ROOT_PORT << 12);
- regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
- IMX6Q_GPR12_LOS_LEVEL, 9 << 4);
-
- regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
- IMX6Q_GPR8_TX_DEEMPH_GEN1,
- imx6_pcie->tx_deemph_gen1 << 0);
- regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
- IMX6Q_GPR8_TX_DEEMPH_GEN2_3P5DB,
- imx6_pcie->tx_deemph_gen2_3p5db << 6);
- regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
- IMX6Q_GPR8_TX_DEEMPH_GEN2_6DB,
- imx6_pcie->tx_deemph_gen2_6db << 12);
- regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
- IMX6Q_GPR8_TX_SWING_FULL,
- imx6_pcie->tx_swing_full << 18);
- regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR8,
- IMX6Q_GPR8_TX_SWING_LOW,
- imx6_pcie->tx_swing_low << 25);
}
static int imx6_pcie_wait_for_link(struct imx6_pcie *imx6_pcie)
@@ -498,8 +603,14 @@ static int imx6_pcie_establish_link(struct imx6_pcie *imx6_pcie)
dw_pcie_writel_rc(pp, PCIE_RC_LCR, tmp);
/* Start LTSSM. */
- regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
- IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
+ if (imx6_pcie->variant == IMX7D)
+ regmap_update_bits(imx6_pcie->src,
+ SRC_PCIEPHY_RCR,
+ IMX7D_SRC_PCIEPHY_RCR_PCIE_CTRL_APPS_EN,
+ IMX7D_SRC_PCIEPHY_RCR_PCIE_CTRL_APPS_EN);
+ else
+ regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+ IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
ret = imx6_pcie_wait_for_link(imx6_pcie);
if (ret) {
@@ -677,13 +788,39 @@ static int __init imx6_pcie_probe(struct platform_device *pdev)
return PTR_ERR(imx6_pcie->pcie);
}
- if (imx6_pcie->variant == IMX6SX) {
+ switch (imx6_pcie->variant) {
+ case IMX6SX:
imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
"pcie_inbound_axi");
if (IS_ERR(imx6_pcie->pcie_inbound_axi)) {
dev_err(dev, "pcie_inbound_axi clock missing or invalid\n");
return PTR_ERR(imx6_pcie->pcie_inbound_axi);
}
+ break;
+ case IMX7D:
+ imx6_pcie->src =
+ syscon_regmap_lookup_by_compatible("fsl,imx7d-src");
+ if (IS_ERR(imx6_pcie->src)) {
+ dev_err(dev, "imx7d pcie phy src missing or invalid\n");
+ return PTR_ERR(imx6_pcie->src);
+ }
+
+ imx6_pcie->gpc =
+ syscon_regmap_lookup_by_compatible("fsl,imx7d-gpc");
+ if (IS_ERR(imx6_pcie->gpc)) {
+ dev_err(dev, "unable to find gpc registers\n");
+ return PTR_ERR(imx6_pcie->gpc);
+ }
+
+ imx6_pcie->pcie_phy_regulator = devm_regulator_get(pp->dev,
+ "pcie-phy");
+ if (IS_ERR(imx6_pcie->pcie_phy_regulator)) {
+ dev_err(dev, "imx7d pcie phy src missing or invalid\n");
+ return PTR_ERR(imx6_pcie->pcie_phy_regulator);
+ }
+ break;
+ default:
+ break;
}
/* Grab GPR config register range */
@@ -741,6 +878,7 @@ static const struct of_device_id imx6_pcie_of_match[] = {
{ .compatible = "fsl,imx6q-pcie", .data = (void *)IMX6Q, },
{ .compatible = "fsl,imx6sx-pcie", .data = (void *)IMX6SX, },
{ .compatible = "fsl,imx6qp-pcie", .data = (void *)IMX6QP, },
+ { .compatible = "fsl,imx7d-pcie", .data = (void *)IMX7D, },
{},
};
diff --git a/include/linux/mfd/syscon/imx7-gpc.h b/include/linux/mfd/syscon/imx7-gpc.h
new file mode 100644
index 0000000..38e1c9a9
--- /dev/null
+++ b/include/linux/mfd/syscon/imx7-gpc.h
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2017 Impinj
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __LINUX_IMX7_GPC_H
+#define __LINUX_IMX7_GPC_H
+
+#define GPC_PGC_CPU_MAPPING 0xec
+#define GPC_PU_PGC_SW_PUP_REQ 0xf8
+
+#define IMX7D_PCIE_PHY_A7_DOMAIN BIT(3)
+#define IMX7D_PCIE_PHY_SW_PUP_REQ BIT(1)
+
+#endif
diff --git a/include/linux/mfd/syscon/imx7-iomuxc-gpr.h b/include/linux/mfd/syscon/imx7-iomuxc-gpr.h
index 4585d61..abbd524 100644
--- a/include/linux/mfd/syscon/imx7-iomuxc-gpr.h
+++ b/include/linux/mfd/syscon/imx7-iomuxc-gpr.h
@@ -44,4 +44,8 @@
#define IMX7D_GPR5_CSI_MUX_CONTROL_MIPI (0x1 << 4)
+#define IMX7D_GPR12_PCIE_PHY_REFCLK_SEL BIT(5)
+
+#define IMX7D_GPR22_PCIE_PHY_PLL_LOCKED BIT(31)
+
#endif /* __LINUX_IMX7_IOMUXC_GPR_H */
diff --git a/include/linux/mfd/syscon/imx7-src.h b/include/linux/mfd/syscon/imx7-src.h
new file mode 100644
index 0000000..fdc4806
--- /dev/null
+++ b/include/linux/mfd/syscon/imx7-src.h
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2017 Impinj
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __LINUX_IMX7_SRC_H
+#define __LINUX_IMX7_SRC_H
+
+#define SRC_PCIEPHY_RCR 0x2c
+
+#define IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_G_RST BIT(1)
+#define IMX7D_SRC_PCIEPHY_RCR_PCIEPHY_BTN BIT(2)
+#define IMX7D_SRC_PCIEPHY_RCR_PCIE_CTRL_APPS_EN BIT(6)
+
+#endif /* __LINUX_IMX7_IOMUXC_GPR_H */
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v2 2/3] dt-bindings: mtd: add a common label property to all mtd devices
From: Rob Herring @ 2017-01-19 16:42 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Marek Vasut, linux-mtd, Cyrille Pitchen, Brian Norris,
David Woodhouse
In-Reply-To: <1484578600-25994-1-git-send-email-clg@kaod.org>
On Mon, Jan 16, 2017 at 03:56:40PM +0100, Cédric Le Goater wrote:
> This can be used to easily identify a specific chip on a system with
> multiple chips.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Documentation/devicetree/bindings/mtd/common.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/common.txt
Acked-by: Rob Herring <robh@kernel.org>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v13 2/5] tee: generic TEE subsystem
From: Jens Wiklander @ 2017-01-19 16:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: valentin.manea, devicetree, javier, emmanuel.michel,
Greg Kroah-Hartman, Mark Rutland, Will Deacon, linux-kernel,
Wei Xu, Nishanth Menon, Jason Gunthorpe, Rob Herring, broonie,
Al Viro, Andrew F. Davis, Olof Johansson, Andrew Morton,
jean-michel.delorme, Michal Simek, linux-arm-kernel
In-Reply-To: <5825882.vZRDMrBMkW@wuerfel>
Hi Arnd,
This is the old v13 patch set you're commenting, but it doesn't matter
it's essentially identical to v14 in this patch.
On Wed, Jan 18, 2017 at 09:19:25PM +0100, Arnd Bergmann wrote:
> On Friday, November 18, 2016 3:51:37 PM CET Jens Wiklander wrote:
> > Initial patch for generic TEE subsystem.
> > This subsystem provides:
> > * Registration/un-registration of TEE drivers.
> > * Shared memory between normal world and secure world.
> > * Ioctl interface for interaction with user space.
> > * Sysfs implementation_id of TEE driver
> >
> > A TEE (Trusted Execution Environment) driver is a driver that interfaces
> > with a trusted OS running in some secure environment, for example,
> > TrustZone on ARM cpus, or a separate secure co-processor etc.
> >
> > The TEE subsystem can serve a TEE driver for a Global Platform compliant
> > TEE, but it's not limited to only Global Platform TEEs.
> >
> > This patch builds on other similar implementations trying to solve
> > the same problem:
> > * "optee_linuxdriver" by among others
> > Jean-michel DELORME<jean-michel.delorme@st.com> and
> > Emmanuel MICHEL <emmanuel.michel@st.com>
> > * "Generic TrustZone Driver" by Javier González <javier@javigon.com>
>
> Can you give an example for a system that would contain more than one
> TEE? I see that you support dynamic registration, and it's clear that
> there can be more than one type of TEE, but why would one have more
> than one at a time, and why not more than 32?
I know that ST has systems where there's one TEE in TrustZone and
another TEE on a separate secure co-processor. If you have several TEEs
it's probably because they have different capabilities (performance
versus level of security). Just going beyond two or three different
levels of security with different TEEs sounds a bit extreme, so a
maximum of 32 or 16 should be fairly safe. If it turns out I'm wrong in
this assumption it's not that hard to correct it.
>
> > +static int tee_ioctl_invoke(struct tee_context *ctx,
> > + struct tee_ioctl_buf_data __user *ubuf)
> > +{
> > + int rc;
> > + size_t n;
> > + struct tee_ioctl_buf_data buf;
> > + struct tee_ioctl_invoke_arg __user *uarg;
> > + struct tee_ioctl_invoke_arg arg;
> > + struct tee_ioctl_param __user *uparams = NULL;
> > + struct tee_param *params = NULL;
> > +
> > + if (!ctx->teedev->desc->ops->invoke_func)
> > + return -EINVAL;
> > +
> > + if (copy_from_user(&buf, ubuf, sizeof(buf)))
> > + return -EFAULT;
> > +
> > + if (buf.buf_len > TEE_MAX_ARG_SIZE ||
> > + buf.buf_len < sizeof(struct tee_ioctl_invoke_arg))
> > + return -EINVAL;
> > +
> > + uarg = (struct tee_ioctl_invoke_arg __user *)(unsigned long)buf.buf_ptr;
>
> u64_to_user_ptr()
Thanks, that's convenient.
>
> > + if (copy_from_user(&arg, uarg, sizeof(arg)))
> > + return -EFAULT;
> > +
> > + if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len)
> > + return -EINVAL;
> > +
> > + if (arg.num_params) {
> > + params = kcalloc(arg.num_params, sizeof(struct tee_param),
> > + GFP_KERNEL);
> > + if (!params)
> > + return -ENOMEM;
>
> It would be good to have an upper bound on the number of parameters
> to limit the size of the memory allocation here.
This is already limited due to:
The test with: buf.buf_len > TEE_MAX_ARG_SIZE
And then another test that the number of parameters matches the buffer size
with: sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len
>
> > +int tee_device_register(struct tee_device *teedev)
> > +{
> > + int rc;
> > +
> > + /*
> > + * If the teedev already is registered, don't do it again. It's
> > + * obviously an error to try to register twice, but if we return
> > + * an error we'll force the driver to remove the teedev.
> > + */
> > + if (teedev->flags & TEE_DEVICE_FLAG_REGISTERED) {
> > + dev_err(&teedev->dev, "attempt to register twice\n");
> > + return 0;
> > + }
>
> I don't understand what you are protecting against here.
> How would we get to this function twice for the same device?
>
> Could you change the caller so it doesn't happen?
Yes the caller can be changed, I'll return an error instead (and remove
the comment).
>
> > +/**
> > + * struct tee_ioctl_param - parameter
> > + * @attr: attributes
> > + * @memref: a memory reference
> > + * @value: a value
> > + *
> > + * @attr & TEE_PARAM_ATTR_TYPE_MASK indicates if memref or value is used in
> > + * the union. TEE_PARAM_ATTR_TYPE_VALUE_* indicates value and
> > + * TEE_PARAM_ATTR_TYPE_MEMREF_* indicates memref. TEE_PARAM_ATTR_TYPE_NONE
> > + * indicates that none of the members are used.
> > + */
> > +struct tee_ioctl_param {
> > + __u64 attr;
> > + union {
> > + struct tee_ioctl_param_memref memref;
> > + struct tee_ioctl_param_value value;
> > + } u;
> > +};
> > +
> > +#define TEE_IOCTL_UUID_LEN 16
> > +
>
> Having a union in an ioctl argument seems odd. Have you considered
> using two different ioctl command numbers depending on the type?
struct tee_ioctl_param is used as an array and some parameters can be
memrefs while other are values.
>
> > +/**
> > + * struct tee_iocl_supp_send_arg - Send a response to a received request
> > + * @ret: [out] return value
> > + * @num_params [in] number of parameters following this struct
> > + */
> > +struct tee_iocl_supp_send_arg {
> > + __u32 ret;
> > + __u32 num_params;
> > + /*
> > + * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
> > + * which follows requires 8 byte alignment.
> > + *
> > + * Commented out element used to visualize the layout dynamic part
> > + * of the struct. This field is not available at all if
> > + * num_params == 0.
> > + *
> > + * struct tee_ioctl_param params[num_params];
> > + */
> > +} __aligned(8);
>
> I'd make that
>
> struct tee_ioctl_param params[0];
>
> as wel here, as I also commented in patch 3 that has a similar structure.
I'm concerned that this may cause warnings when compiling for user space
depending on compiler and options. Am I too cautious here?
Thanks,
Jens
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] PCI: imx6: Add code to support i.MX7D
From: Lucas Stach @ 2017-01-19 16:52 UTC (permalink / raw)
To: Andrey Smirnov
Cc: linux-pci, yurovsky, Richard Zhu, Bjorn Helgaas, Fabio Estevam,
Shawn Guo, Rob Herring, Mark Rutland, Lee Jones, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20170119163631.10668-4-andrew.smirnov@gmail.com>
Am Donnerstag, den 19.01.2017, 08:36 -0800 schrieb Andrey Smirnov:
> Add various bits of code needed to support i.MX7D variant of the IP.
>
> Cc: yurovsky@gmail.com
> Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
> .../devicetree/bindings/pci/fsl,imx6q-pcie.txt | 6 +-
> drivers/pci/host/pci-imx6.c | 188 ++++++++++++++++++---
> include/linux/mfd/syscon/imx7-gpc.h | 18 ++
> include/linux/mfd/syscon/imx7-iomuxc-gpr.h | 4 +
> include/linux/mfd/syscon/imx7-src.h | 18 ++
> 5 files changed, 208 insertions(+), 26 deletions(-)
> create mode 100644 include/linux/mfd/syscon/imx7-gpc.h
> create mode 100644 include/linux/mfd/syscon/imx7-src.h
>
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> index 83aeb1f..20b9382 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
> and thus inherits all the common properties defined in designware-pcie.txt.
>
> Required properties:
> -- compatible: "fsl,imx6q-pcie", "fsl,imx6sx-pcie", "fsl,imx6qp-pcie"
> +- compatible: "fsl,imx6q-pcie", "fsl,imx6sx-pcie",
> + "fsl,imx6qp-pcie", "fsl,imx7d-pcie"
> - reg: base address and length of the PCIe controller
> - interrupts: A list of interrupt outputs of the controller. Must contain an
> entry for each entry in the interrupt-names property.
> @@ -34,6 +35,9 @@ Additional required properties for imx6sx-pcie:
> - clock names: Must include the following additional entries:
> - "pcie_inbound_axi"
>
> +Additional required properties for imx7d-pcie:
> +- pcie-phy-supply: Should specify the regulator supplying PCIe PHY
> +
This isn't a PHY regulator, but a regulator powering the GPC domain
where the PHY is located. This should not be handled in the PCIe driver.
See the previous discussion with i.MX6SX, that is in the same boat.
[...]
> static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
> {
> - if (imx6_pcie->variant == IMX6SX)
> + switch (imx6_pcie->variant) {
> + case IMX7D: {
> + int ret;
> + unsigned int reg, mapping;
> + struct pcie_port *pp = &imx6_pcie->pp;
> + struct device *dev = pp->dev;
> +
> + regulator_set_voltage(imx6_pcie->pcie_phy_regulator,
> + 1000000, 1000000);
> + ret = regulator_enable(imx6_pcie->pcie_phy_regulator);
> + if (ret) {
> + dev_err(dev, "failed to enable pcie regulator.\n");
> + return;
> + }
> +
> + /*
> + * Now that PHY regulator is enabled, do sofware
> + * power-up request by mapping PHY in A7 domain and
> + * setting power-up request bit
> + */
> + regmap_read(imx6_pcie->gpc, GPC_PGC_CPU_MAPPING, &mapping);
> + regmap_write(imx6_pcie->gpc, GPC_PGC_CPU_MAPPING,
> + mapping | IMX7D_PCIE_PHY_A7_DOMAIN);
> +
> + regmap_update_bits(imx6_pcie->gpc, GPC_PU_PGC_SW_PUP_REQ,
> + IMX7D_PCIE_PHY_SW_PUP_REQ,
> + IMX7D_PCIE_PHY_SW_PUP_REQ);
> + /*
> + * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
> + * for PUP_REQ bit to be cleared
> + */
> + while (!regmap_read(imx6_pcie->gpc,
> + GPC_PU_PGC_SW_PUP_REQ, ®) &&
> + reg & IMX7D_PCIE_PHY_SW_PUP_REQ)
> + ;
> + regmap_write(imx6_pcie->gpc, GPC_PGC_CPU_MAPPING, mapping);
I won't allow code touching the GPC registers to sneak into the PCIe
driver. I know this is the downstream solution, but this really needs a
proper GPC power domain driver, instead of this hack.
Regards,
Lucas
^ permalink raw reply
* [RESENT PATCH] ARM: bcm2835: Add devicetree for the Raspberry Pi 3, for arm (32)
From: Gerd Hoffmann @ 2017-01-19 17:04 UTC (permalink / raw)
To: linux-rpi-kernel
Cc: Gerd Hoffmann, Rob Herring, Mark Rutland, Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM PORT, open list
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
arch/arm/boot/dts/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7327250..82a760d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -70,7 +70,8 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
bcm2835-rpi-b-plus.dtb \
bcm2835-rpi-a-plus.dtb \
bcm2836-rpi-2-b.dtb \
- bcm2835-rpi-zero.dtb
+ bcm2835-rpi-zero.dtb \
+ ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb
dtb-$(CONFIG_ARCH_BCM_5301X) += \
bcm4708-asus-rt-ac56u.dtb \
bcm4708-asus-rt-ac68u.dtb \
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 0/2] ARM: DTS: Fix broken GICv2 register maps
From: Tony Lindgren @ 2017-01-19 17:08 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, Heiko Stuebner, Magnus Damm, Russell King,
Krzysztof Kozlowski, Javier Martinez Canillas, Chen-Yu Tsai, arm,
Tsahee Zidenberg, devicetree, Jason Cooper, Arnd Bergmann,
Simon Horman, Santosh Shilimkar, Matthias Brugger,
Benoît Cousson, Thomas Gleixner, linux-arm-kernel,
Antoine Tenart, linux-kernel, Rob Herring, Kukjin Kim,
Sascha Hauer
In-Reply-To: <16613dbe-08b9-98d8-c747-a977e78601b1@arm.com>
* Marc Zyngier <marc.zyngier@arm.com> [170118 05:09]:
> On 18/01/17 12:34, Arnd Bergmann wrote:
> > On Wednesday, January 18, 2017 10:53:29 AM CET Marc Zyngier wrote:
> >> For a GICv2 (which happens to be virtualization capable), the
> >> architecture mandates the following regions:
> >>
> >> GICD: 4kB
> >> GICC: 8kB
> >> GICH: 8kB
> >> GICV: 8kB
> >>
> >> Unfortunately, I made a mistake in one of the examples contained in
> >> the DT binding document, and everyone duplicated that same mistake all
> >> over the map.
> >>
> >> This small series fixes the DT binding, and hopefully updates all the
> >> offending DTs to be compliant with the architecture.
> >>
> >
> > Looks good to me, can you send this as a pull request to arm@kernel.org
> > once you have collected a reasonable number of Acks?
>
> Sure, will do.
>
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
Here's yet another ack to paste for both patches:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 4/5] dt: add bindings for ZTE tvenc device
From: Lucas Stach @ 2017-01-19 17:11 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, devicetree, Daniel Vetter, Baoyou Xie, dri-devel,
Rob Herring, Jun Nie
In-Reply-To: <1484843100-16284-5-git-send-email-shawnguo@kernel.org>
Am Freitag, den 20.01.2017, 00:24 +0800 schrieb Shawn Guo:
> From: Shawn Guo <shawn.guo@linaro.org>
>
> It adds bindings doc for ZTE VOU TV Encoder device.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> Documentation/devicetree/bindings/display/zte,vou.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt b/Documentation/devicetree/bindings/display/zte,vou.txt
> index 740e5bd2e4f7..9c356284232b 100644
> --- a/Documentation/devicetree/bindings/display/zte,vou.txt
> +++ b/Documentation/devicetree/bindings/display/zte,vou.txt
> @@ -49,6 +49,15 @@ Required properties:
> "osc_clk"
> "xclk"
>
> +* TV Encoder output device
> +
> +Required properties:
> + - compatible: should be "zte,zx296718-tvenc"
> + - reg: Physical base address and length of the TVENC device IO region
> + - zte,tvenc-power-control: the phandle to SYSCTRL block followed by two
> + integer cells. The first cell is the offset of SYSCTRL register used
> + to control TV Encoder DAC power, and the second cell is the bit mask.
I don't know much about this platform, but shouldn't this be handled
with a proper power domain driver, rather than bashing bits directly?
Regards,
Lucas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH linux v3 5/6] hwmon: occ: Add hwmon implementation for the P8 OCC
From: Rob Herring @ 2017-01-19 17:12 UTC (permalink / raw)
To: eajames.ibm
Cc: linux, devicetree, linux-kernel, linux-hwmon, linux-doc, jdelvare,
corbet, mark.rutland, wsa, andrew, joel, benh, Edward A. James
In-Reply-To: <1484601219-30196-6-git-send-email-eajames.ibm@gmail.com>
On Mon, Jan 16, 2017 at 03:13:38PM -0600, eajames.ibm@gmail.com wrote:
> From: "Edward A. James" <eajames@us.ibm.com>
>
> Add code to tie the hwmon sysfs code and the POWER8 OCC code together, as
> well as probe the entire driver from the I2C bus. I2C is the communication
> method between the BMC and the P8 OCC.
>
> Signed-off-by: Edward A. James <eajames@us.ibm.com>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/hwmon/occ.txt | 13 +++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/hwmon/occ/Kconfig | 14 ++++
> drivers/hwmon/occ/Makefile | 1 +
> drivers/hwmon/occ/p8_occ_i2c.c | 104 ++++++++++++++++++++++++
> 4 files changed, 132 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/occ.txt
> create mode 100644 drivers/hwmon/occ/p8_occ_i2c.c
^ permalink raw reply
* Re: [PATCH V2 3/4] arm64: dts: Enable SDHCI for Nexus 5X (msm8992)
From: Rob Herring @ 2017-01-19 17:21 UTC (permalink / raw)
To: Jeremy McNicoll
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
arnd-r2nGTMty4D4, bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
riteshh-sgV2jX0FEOL9JmXXK+q4OQ, git-LJ92rlH3Dns,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
jszhang-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <1484614729-26751-4-git-send-email-jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Mon, Jan 16, 2017 at 04:58:48PM -0800, Jeremy McNicoll wrote:
> Add Nexus 5X (msm8992) SDHCI support, including initial regulator
> entries to support enabling the main SDHCI/MMC.
>
> The RPM is common between 8992 & 8994 simply reflect reality with
> a shared DT entry.
>
> The msm8994 RPM regulator talks over SMD to the APPS processor.
>
> Signed-off-by: Jeremy McNicoll <jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>
> Dropped RobH's ACK explicitly after addressing all feedback.
> The reason is that msm8994-smd-rpm.dtsi was created to allow
> for sharing between 8992 & 8994 as the RPM is common between
> the two.
>
> .../bindings/regulator/qcom,smd-rpm-regulator.txt | 40 +++
> .../boot/dts/qcom/msm8992-bullhead-rev-101.dts | 2 +
> arch/arm64/boot/dts/qcom/msm8992-pins.dtsi | 82 ++++++
> arch/arm64/boot/dts/qcom/msm8992.dtsi | 153 ++++++++++++
> arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi | 276 +++++++++++++++++++++
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/regulator/qcom_smd-regulator.c | 49 ++++
> 6 files changed, 602 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 4/4] dts: doc: rename rpm_requests to respect DT naming conventions
From: Rob Herring @ 2017-01-19 17:22 UTC (permalink / raw)
To: Jeremy McNicoll
Cc: linux-arm-msm, linux-soc, devicetree, linux-mmc, andy.gross,
sboyd, arnd, bjorn.andersson, riteshh, git, ulf.hansson, jszhang
In-Reply-To: <1484614729-26751-5-git-send-email-jeremymc@redhat.com>
On Mon, Jan 16, 2017 at 04:58:49PM -0800, Jeremy McNicoll wrote:
> Node names cannot have an underscore '_' in the name.
> Simply rename 'rpm_request' nodes to 'rpm-request'.
>
> Signed-off-by: Jeremy McNicoll <jeremymc@redhat.com>
> ---
> Documentation/devicetree/bindings/clock/qcom,rpmcc.txt | 2 +-
> .../devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt | 2 +-
> Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt | 6 +++---
> Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt | 2 +-
> arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 2 +-
> arch/arm/boot/dts/qcom-apq8084.dtsi | 2 +-
> arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts | 2 +-
> arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts | 2 +-
> arch/arm/boot/dts/qcom-msm8974.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/msm8994-smd-rpm.dtsi | 2 +-
> 11 files changed, 13 insertions(+), 13 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 1/3] dt: bindings: add documentation for zx2967 family reset controller
From: Rob Herring @ 2017-01-19 17:27 UTC (permalink / raw)
To: Baoyou Xie
Cc: jun.nie-QSEj5FYQhm4dnm+yROfE0A, p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
In-Reply-To: <1484623377-16208-1-git-send-email-baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue, Jan 17, 2017 at 11:22:55AM +0800, Baoyou Xie wrote:
> This patch adds dt-binding documentation for zx2967 family
> reset controller.
>
> Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Reviewed-by: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/reset/zte,zx2967-reset.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC v2 4/5] DT bindings documentation for Synopsys UDC platform driver
From: Rob Herring @ 2017-01-19 17:36 UTC (permalink / raw)
To: Raviteja Garimella
Cc: Mark Rutland, Greg Kroah-Hartman, Felipe Balbi,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484640308-25976-5-git-send-email-raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, Jan 17, 2017 at 01:35:07PM +0530, Raviteja Garimella wrote:
> This patch adds device tree bindings documentation for Synopsys
> USB device controller platform driver.
Bindings describe h/w, not drivers.
>
> Signed-off-by: Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/usb/snps,dw-ahb-udc.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> new file mode 100644
> index 0000000..0c18327
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> @@ -0,0 +1,27 @@
> +Synopsys USB Device controller.
> +
> +The device node is used for Synopsys Designware Cores AHB
> +Subsystem Device Controller (UDC).
> +
> +This device node is used by UDCs integrated it Broadcom's
> +Northstar2 and Cygnus SoC's.
You need compatible strings for these in addition.
> +
> +Required properties:
> + - compatible: should be "snps,dw-ahb-udc"
This is a different IP than DWC2?
> + - reg: Offset and length of UDC register set
> + - interrupts: description of interrupt line
> + - phys: phandle to phy node.
> + - extcon: phandle to the extcon device. This is optional and
> + not required for those that don't require extcon support.
> + Extcon support will be required if the UDC is connected to
> + a Dual Role Device Phy that supports both Host and Device
> + mode based on the external cable.
Drop this. It should be a part of the phy. Also, I don't care to see new
users of extcon binding because it needs redoing.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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