* [PATCH v6 2/5] [media] davinci: vpif_capture: remove hard-coded I2C adapter id
From: Kevin Hilman @ 2016-12-07 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207183025.20684-1-khilman@baylibre.com>
Remove hard-coded I2C adapter in favor of getting the
ID from platform_data.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif_capture.c | 5 ++++-
include/media/davinci/vpif_types.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index 20c4344ed118..c24049acd40a 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1486,7 +1486,10 @@ static __init int vpif_probe(struct platform_device *pdev)
}
if (!vpif_obj.config->asd_sizes) {
- i2c_adap = i2c_get_adapter(1);
+ int i2c_id = vpif_obj.config->i2c_adapter_id;
+
+ i2c_adap = i2c_get_adapter(i2c_id);
+ WARN_ON(!i2c_adap);
for (i = 0; i < subdev_count; i++) {
subdevdata = &vpif_obj.config->subdev_info[i];
vpif_obj.sd[i] =
diff --git a/include/media/davinci/vpif_types.h b/include/media/davinci/vpif_types.h
index 3cb1704a0650..4282a7db99d4 100644
--- a/include/media/davinci/vpif_types.h
+++ b/include/media/davinci/vpif_types.h
@@ -82,6 +82,7 @@ struct vpif_capture_config {
struct vpif_capture_chan_config chan_config[VPIF_CAPTURE_MAX_CHANNELS];
struct vpif_subdev_info *subdev_info;
int subdev_count;
+ int i2c_adapter_id;
const char *card_name;
struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
int *asd_sizes; /* 0-terminated array of asd group sizes */
--
2.9.3
^ permalink raw reply related
* [PATCH v6 3/5] [media] davinci: vpif_capture: fix start/stop streaming locking
From: Kevin Hilman @ 2016-12-07 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207183025.20684-1-khilman@baylibre.com>
Video capture subdevs may be over I2C and may sleep during xfer, so we
cannot do IRQ-disabled locking when calling the subdev.
The IRQ-disabled locking is meant to protect the DMA queue list
throughout the rest of the driver, so update the locking in
[start|stop]_streaming to protect just this list, and update the irqlock
comment to reflect what it actually protects.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif_capture.c | 6 +++---
drivers/media/platform/davinci/vpif_capture.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index c24049acd40a..f72a719efb3d 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -179,8 +179,6 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count)
unsigned long addr, flags;
int ret;
- spin_lock_irqsave(&common->irqlock, flags);
-
/* Initialize field_id */
ch->field_id = 0;
@@ -211,6 +209,7 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count)
vpif_config_addr(ch, ret);
/* Get the next frame from the buffer queue */
+ spin_lock_irqsave(&common->irqlock, flags);
common->cur_frm = common->next_frm = list_entry(common->dma_queue.next,
struct vpif_cap_buffer, list);
/* Remove buffer from the buffer queue */
@@ -244,6 +243,7 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count)
return 0;
err:
+ spin_lock_irqsave(&common->irqlock, flags);
list_for_each_entry_safe(buf, tmp, &common->dma_queue, list) {
list_del(&buf->list);
vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_QUEUED);
@@ -287,7 +287,6 @@ static void vpif_stop_streaming(struct vb2_queue *vq)
vpif_dbg(1, debug, "stream off failed in subdev\n");
/* release all active buffers */
- spin_lock_irqsave(&common->irqlock, flags);
if (common->cur_frm == common->next_frm) {
vb2_buffer_done(&common->cur_frm->vb.vb2_buf,
VB2_BUF_STATE_ERROR);
@@ -300,6 +299,7 @@ static void vpif_stop_streaming(struct vb2_queue *vq)
VB2_BUF_STATE_ERROR);
}
+ spin_lock_irqsave(&common->irqlock, flags);
while (!list_empty(&common->dma_queue)) {
common->next_frm = list_entry(common->dma_queue.next,
struct vpif_cap_buffer, list);
diff --git a/drivers/media/platform/davinci/vpif_capture.h b/drivers/media/platform/davinci/vpif_capture.h
index 9e35b6771d22..1d2c052deedf 100644
--- a/drivers/media/platform/davinci/vpif_capture.h
+++ b/drivers/media/platform/davinci/vpif_capture.h
@@ -67,7 +67,7 @@ struct common_obj {
struct vb2_queue buffer_queue;
/* Queue of filled frames */
struct list_head dma_queue;
- /* Used in video-buf */
+ /* Protects the dma_queue field */
spinlock_t irqlock;
/* lock used to access this structure */
struct mutex lock;
--
2.9.3
^ permalink raw reply related
* [PATCH v6 4/5] [media] dt-bindings: add TI VPIF documentation
From: Kevin Hilman @ 2016-12-07 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207183025.20684-1-khilman@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
.../devicetree/bindings/media/ti,da850-vpif.txt | 83 ++++++++++++++++++++++
1 file changed, 83 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/ti,da850-vpif.txt
diff --git a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
new file mode 100644
index 000000000000..6d25d7f23d26
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
@@ -0,0 +1,83 @@
+Texas Instruments VPIF
+----------------------
+
+The TI Video Port InterFace (VPIF) is the primary component for video
+capture and display on the DA850/AM18x family of TI DaVinci/Sitara
+SoCs.
+
+TI Document reference: SPRUH82C, Chapter 35
+http://www.ti.com/lit/pdf/spruh82
+
+Required properties:
+- compatible: must be "ti,da850-vpif"
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain IRQ line for the VPIF
+
+Video Capture:
+
+VPIF has a 16-bit parallel bus input, supporting 2 8-bit channels or a
+single 16-bit channel. It should contain at least one port child node
+with child 'endpoint' node. Please refer to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example using 2 8-bit input channels, one of which is connected to an
+I2C-connected TVP5147 decoder:
+
+ vpif: vpif at 217000 {
+ compatible = "ti,da850-vpif";
+ reg = <0x217000 0x1000>;
+ interrupts = <92>;
+
+ port {
+ vpif_ch0: endpoint at 0 {
+ reg = <0>;
+ bus-width = <8>;
+ remote-endpoint = <&composite>;
+ };
+
+ vpif_ch1: endpoint at 1 {
+ reg = <1>;
+ bus-width = <8>;
+ data-shift = <8>;
+ };
+ };
+ };
+
+[ ... ]
+
+&i2c0 {
+
+ tvp5147 at 5d {
+ compatible = "ti,tvp5147";
+ reg = <0x5d>;
+ status = "okay";
+
+ port {
+ composite: endpoint {
+ hsync-active = <1>;
+ vsync-active = <1>;
+ pclk-sample = <0>;
+
+ /* VPIF channel 0 (lower 8-bits) */
+ remote-endpoint = <&vpif_ch0>;
+ bus-width = <8>;
+ };
+ };
+ };
+};
+
+
+Alternatively, an example when the bus is configured as a single
+16-bit input (e.g. for raw-capture mode):
+
+ vpif: vpif at 217000 {
+ compatible = "ti,da850-vpif";
+ reg = <0x217000 0x1000>;
+ interrupts = <92>;
+
+ port {
+ vpif_ch0: endpoint {
+ bus-width = <16>;
+ };
+ };
+ };
--
2.9.3
^ permalink raw reply related
* [PATCH v6 5/5] [media] davinci: VPIF: add basic support for DT init
From: Kevin Hilman @ 2016-12-07 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207183025.20684-1-khilman@baylibre.com>
Add basic support for initialization via DT
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index f50148dcba64..1b02a6363f77 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -467,8 +467,17 @@ static const struct dev_pm_ops vpif_pm = {
#define vpif_pm_ops NULL
#endif
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id vpif_of_match[] = {
+ { .compatible = "ti,da850-vpif", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, vpif_of_match);
+#endif
+
static struct platform_driver vpif_driver = {
.driver = {
+ .of_match_table = of_match_ptr(vpif_of_match),
.name = VPIF_DRIVER_NAME,
.pm = vpif_pm_ops,
},
--
2.9.3
^ permalink raw reply related
* [PATCH 3/8] rtc: add STM32 RTC driver
From: Alexandre Belloni @ 2016-12-07 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15bea9e9-adcc-edb0-1bd1-33d395c72eec@st.com>
On 05/12/2016 at 10:43:14 +0100, Amelie DELAUNAY wrote :
> >> +
> >> + device_init_wakeup(&pdev->dev, true);
> >
> > What happens if device_init_wakeup() returns an error?
> It means that RTC won't be able to wake up the board with RTC alarm. I can
> add a warning for the user in this case ?
> >
There is exactly one driver ever checking the return value of
device_init_wakeup(). It basically always succeeds.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] firmware: arm_scpi: fix reading sensor values on pre-1.0 SCPI firmwares
From: Sudeep Holla @ 2016-12-07 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124001845.20830-2-martin.blumenstingl@googlemail.com>
On 24/11/16 00:18, Martin Blumenstingl wrote:
> The pre-1.0 SCPI firmwares are using one __le32 as sensor value, while
> the 1.0 SCPI protocol uses two __le32 as sensor values (a total of
> 64bit, split into 32bit upper and 32bit lower value).
> Using an "struct sensor_value" to read the sensor value on a pre-1.0
> SCPI firmware gives garbage in the "hi_val" field. Introducing a
> separate function which handles scpi_ops.sensor_get_value for pre-1.0
> SCPI firmware implementations ensures that we do not read memory which
> was not written by the SCPI firmware (which fixes for example the
> temperature reported by scpi-hwmon).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> drivers/firmware/arm_scpi.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
> index 70e1323..19f750d 100644
> --- a/drivers/firmware/arm_scpi.c
> +++ b/drivers/firmware/arm_scpi.c
> @@ -728,6 +728,20 @@ static int scpi_sensor_get_value(u16 sensor, u64 *val)
> return ret;
> }
>
> +static int legacy_scpi_sensor_get_value(u16 sensor, u64 *val)
> +{
> + __le16 id = cpu_to_le16(sensor);
> + __le32 value;
> + int ret;
> +
> + ret = scpi_send_message(CMD_SENSOR_VALUE, &id, sizeof(id),
> + &value, sizeof(value));
> + if (!ret)
> + *val = le32_to_cpu(value);
> +
> + return ret;
> +}
Instead of duplicating the code so much, can we just manage something
like this. If more commands need Rx len, then we can think of adding
that. Even then reseting shared buffers is not good, we can clear the
buffers on the stack.
diff --git i/drivers/firmware/arm_scpi.c w/drivers/firmware/arm_scpi.c
index 70e13230d8db..04aa873205e9 100644
--- i/drivers/firmware/arm_scpi.c
+++ w/drivers/firmware/arm_scpi.c
@@ -721,11 +721,15 @@ static int scpi_sensor_get_value(u16 sensor, u64 *val)
ret = scpi_send_message(CMD_SENSOR_VALUE, &id, sizeof(id),
&buf, sizeof(buf));
- if (!ret)
+ if (ret)
+ return ret;
+
+ if (scpi_info->is_legacy) /* 32-bits supported, hi_val can be
junk */
+ *val = le32_to_cpu(buf.lo_val);
+ else
*val = (u64)le32_to_cpu(buf.hi_val) << 32 |
le32_to_cpu(buf.lo_val);
-
- return ret;
+ return 0;
}
static int scpi_device_get_power_state(u16 dev_id)
--
Regards,
Sudeep
^ permalink raw reply related
* [PATCH] Input: lpc32xx-keys - fix invalid error handling of a requested irq
From: Dmitry Torokhov @ 2016-12-07 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481134387.9248.8.camel@localhost>
On December 7, 2016 10:13:07 AM PST, Sylvain Lemieux <slemieux.tyco@gmail.com> wrote:
>On Mon, 2016-12-05 at 03:47 +0200, Vladimir Zapolskiy wrote:
>> Semantics of NR_IRQS is different on machines with SPARSE_IRQ option
>> disabled or enabled, in the latter case IRQs are allocated starting
>> at least from the value specified by NR_IRQS and going upwards, so
>> the check of (irq >= NR_IRQ) to decide about an error code returned
>by
>> platform_get_irq() is completely invalid, don't attempt to overrule
>> irq subsystem in the driver.
>>
>> The change fixes lpc32xx_keys driver initialization on boot:
>>
>> lpc32xx_keys 40050000.key: failed to get platform irq
>> lpc32xx_keys: probe of 40050000.key failed with error -22
>>
>> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
>> ---
>> drivers/input/keyboard/lpc32xx-keys.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>Cosmetic - please update the subject line when doing the commit:
>replace " -" by ":" after lpc32xx-keys
Why? The format on all input patches is "Input: <driver> - <subject>" and had been this for 10+ years.
Thanks.
--
Dmitry
^ permalink raw reply
* [RFC PATCH v3 07/11] arm64: compat: Add a 32-bit vDSO
From: Nathan Lynch @ 2016-12-07 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206160353.14581-8-kevin.brodsky@arm.com>
Hi Kevin,
Kevin Brodsky <kevin.brodsky@arm.com> writes:
> diff --git a/arch/arm64/kernel/vdso32/vgettimeofday.c b/arch/arm64/kernel/vdso32/vgettimeofday.c
> new file mode 100644
> index 000000000000..53c3d1f82b26
> --- /dev/null
> +++ b/arch/arm64/kernel/vdso32/vgettimeofday.c
As I said at LPC last month, I'm not excited to have arch/arm's
vgettimeofday.c copied into arch/arm64 and tweaked; I'd rather see this
part of the implementation shared between arch/arm and arch/arm64
somehow, even if there's not an elegant way to do so.
The situation which must be avoided is one where the arch/arm64 compat
VDSO incompatibly diverges from the arch/arm VDSO. That becomes much
less likely if there's only one copy of the userspace-exposed code to
maintain.
[...]
> +/*
> + * We use the hidden visibility to prevent the compiler from generating a GOT
> + * relocation. Not only is going through a GOT useless (the entry couldn't and
> + * musn't be overridden by another library), it does not even work: the linker
> + * cannot generate an absolute address to the data page.
> + *
> + * With the hidden visibility, the compiler simply generates a PC-relative
> + * relocation (R_ARM_REL32), and this is what we need.
> + */
> +extern const struct vdso_data _vdso_data __attribute__((visibility("hidden")));
> +
> +static inline const struct vdso_data *get_vdso_data(void)
> +{
> + const struct vdso_data *ret;
> + /*
> + * This simply puts &_vdso_data into ret. The reason why we don't use
> + * `ret = &_vdso_data` is that the compiler tends to optimise this in a
> + * very suboptimal way: instead of keeping &_vdso_data in a register,
> + * it goes through a relocation almost every time _vdso_data must be
> + * accessed (even in subfunctions). This is both time and space
> + * consuming: each relocation uses a word in the code section, and it
> + * has to be loaded at runtime.
> + *
> + * This trick hides the assignment from the compiler. Since it cannot
> + * track where the pointer comes from, it will only use one relocation
> + * where get_vdso_data() is called, and then keep the result in a
> + * register.
> + */
> + asm("mov %0, %1" : "=r"(ret) : "r"(&_vdso_data));
> + return ret;
> +}
I think this is an instructive case: this code looks like an improvement
over how the arch/arm VDSO accesses the data page. Enhancements like
this (not to mention fixes) shouldn't require a patch-per-architecture;
things inevitably get out of sync and it's more of a maintenance burden
in the long term.
^ permalink raw reply
* [PATCH] Input: lpc32xx-keys - fix invalid error handling of a requested irq
From: Sylvain Lemieux @ 2016-12-07 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7AAD38C5-E1CF-40EF-8E5B-8BCB9B5897C4@gmail.com>
On Wed, 2016-12-07 at 10:46 -0800, Dmitry Torokhov wrote:
> On December 7, 2016 10:13:07 AM PST, Sylvain Lemieux <slemieux.tyco@gmail.com> wrote:
> >On Mon, 2016-12-05 at 03:47 +0200, Vladimir Zapolskiy wrote:
> >> Semantics of NR_IRQS is different on machines with SPARSE_IRQ option
> >> disabled or enabled, in the latter case IRQs are allocated starting
> >> at least from the value specified by NR_IRQS and going upwards, so
> >> the check of (irq >= NR_IRQ) to decide about an error code returned
> >by
> >> platform_get_irq() is completely invalid, don't attempt to overrule
> >> irq subsystem in the driver.
> >>
> >> The change fixes lpc32xx_keys driver initialization on boot:
> >>
> >> lpc32xx_keys 40050000.key: failed to get platform irq
> >> lpc32xx_keys: probe of 40050000.key failed with error -22
> >>
> >> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> >> ---
> >> drivers/input/keyboard/lpc32xx-keys.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >Cosmetic - please update the subject line when doing the commit:
> >replace " -" by ":" after lpc32xx-keys
>
> Why? The format on all input patches is "Input: <driver> - <subject>" and had been this for 10+ years.
>
My mistake; did not look at the tree "subject line" commit log
You can dropped my comment.
Regards,
Sylvain
>
> Thanks.
>
^ permalink raw reply
* [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Shanker Donthineni @ 2016-12-07 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1899e46c-7b06-01d6-6cff-eb0985a4f11d@redhat.com>
Hi Eric,
Is there any reason why you are not supporting SMMUv3 driver? Qualcomm
hardware doesn't not support SMMUv2 hardware, please add support for
SMMUv3 in next patch set. I've ported ' RFC,v3,09/10] iommu/arm-smmu:
Implement reserved region get/put callbacks' to SMMUv3 driver and tested
device-pass-through feature on Qualcomm server platform without any issue.
Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
--
Shanker Donthineni
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399
From: Heiko Stuebner @ 2016-12-07 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207175208.GB87970@google.com>
Am Mittwoch, 7. Dezember 2016, 09:52:08 CET schrieb Brian Norris:
> Hi,
>
> On Wed, Dec 07, 2016 at 06:09:16PM +0100, Heiko Stuebner wrote:
> > Am Donnerstag, 1. Dezember 2016, 18:27:28 CET schrieb Brian Norris:
> > > Add the dwc3 usb needed node information for rk3399.
> > >
> > > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > > ---
> > > Somewhat rewritten from Caesar's reposting (v2) of my patch.
> > >
> > > Changes:
> > > * Include USB2 PHY (which is now in -next)
> > > * Don't include USB3 PHY, as extcon support is not ready yet
> > > * Drop non-upstream properties
> > > * Fixup whitespace a bit
> > >
> > > ---
> > >
> > > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 60
> > >
> > > ++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > > b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index
> > > 4ca8f9a7601c..1e97fb8c6415
> > > 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > > @@ -316,6 +316,66 @@
> > >
> > > };
> > >
> > > };
> > >
> > > + usbdrd3_0: usb at fe800000 {
> >
> > insert location above usb at fe380000 is sorted wrong
>
> So, *how* do you think things are sorted here? Alphabetical by label? Or
> by node name? Or by unit address? I guess I'm seeing you meant unit
> address.
correct. Per unit-address first, nodes without address alphabetical by node-
name (above nodes with addresses), never by label.
> But pcie at f8000000 is also out of order then. I guess maybe
> that's the only one then.
Yep, pcie is misplaced as sadly sometimes I miss those errors as well.
Heiko
> > > + compatible = "rockchip,rk3399-dwc3";
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > + clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
> > > + <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
> > > + <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
> > > + clock-names = "clk_usb3otg0_ref", "clk_usb3otg0_suspend",
> > > + "aclk_usb3otg0", "aclk_usb3_rksoc_axi_perf",
> > > + "aclk_usb3", "aclk_usb3_grf";
> >
> > clock-names do not match binding. The dwc3-of-simple does not care, as it
> > just enables all of them it seems, but binding doc states the clock names
> > as>
> > - clock-names: Should contain the following:
> > "ref_clk" Controller reference clk, have to be 24 MHz
> > "suspend_clk" Controller suspend clk, have to be 24 MHz or 32 KHz
> > "bus_clk" Master/Core clock, have to be >= 62.5 MHz for SS
> >
> > operation and >= 30MHz for HS operation
> >
> > "grf_clk" Controller grf clk
>
> Ah, sorry. I'll try to go with the rockchip,dwc3.txt names better.
>
> There are a few extra clocks here now, but I think those might only be
> for USB3 support, which isn't really working yet. I'll either document
> them or drop them.
>
> > > + resets = <&cru SRST_A_USB3_OTG0>;
> > > + reset-names = "usb3-otg";
> >
> > you could update the binding documentation to list this one.
>
> Similar story; this is only used for some of the hacky stuff Rockchip is
> doing for USB3/TypeC stuff out of tree. I'll either document it or drop
> it (as I'm not actually using it yet).
>
> Thanks,
> Brian
>
> > Heiko
> >
> > > + status = "disabled";
> > > +
> > > + usbdrd_dwc3_0: dwc3 {
> > > + compatible = "snps,dwc3";
> > > + reg = <0x0 0xfe800000 0x0 0x100000>;
> > > + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
> > > + dr_mode = "otg";
> > > + phys = <&u2phy0_otg>;
> > > + phy-names = "usb2-phy";
> > > + snps,dis_enblslpm_quirk;
> > > + snps,dis-u2-freeclk-exists-quirk;
> > > + snps,dis_u2_susphy_quirk;
> > > + snps,dis-del-phy-power-chg-quirk;
> > > + status = "disabled";
> > > + };
> > > + };
>
> [...]
^ permalink raw reply
* [PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399
From: Brian Norris @ 2016-12-07 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1972184.o3UeJg0tK9@phil>
On Wed, Dec 07, 2016 at 08:01:23PM +0100, Heiko Stuebner wrote:
> Am Mittwoch, 7. Dezember 2016, 09:52:08 CET schrieb Brian Norris:
> > But pcie at f8000000 is also out of order then. I guess maybe
> > that's the only one then.
>
> Yep, pcie is misplaced as sadly sometimes I miss those errors as well.
OK. Do you want me to patch that at the end of my series, or is that
unnecessary churn?
Brian
^ permalink raw reply
* [PATCH 3/8] rtc: add STM32 RTC driver
From: Alexandre Belloni @ 2016-12-07 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480687801-19525-5-git-send-email-amelie.delaunay@st.com>
Hi,
It seems mostly fine.
On 02/12/2016 at 15:09:56 +0100, Amelie Delaunay wrote :
> This patch adds support for the STM32 RTC.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> drivers/rtc/Kconfig | 10 +
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc-stm32.c | 777 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 788 insertions(+)
> create mode 100644 drivers/rtc/rtc-stm32.c
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index e859d14..dd8b218 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1706,6 +1706,16 @@ config RTC_DRV_PIC32
> This driver can also be built as a module. If so, the module
> will be called rtc-pic32
>
> +config RTC_DRV_STM32
> + tristate "STM32 On-Chip RTC"
> + depends on ARCH_STM32
Can you add COMPILE_TEST? Looking at it, nothing seemed to be
architecture specific and this nicely increases compile test coverage.
It should also probably select REGMAP_MMIO.
> diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
> new file mode 100644
> index 0000000..9e710ff
> --- /dev/null
> +++ b/drivers/rtc/rtc-stm32.c
> @@ -0,0 +1,777 @@
> +/*
> + * Copyright (C) Amelie Delaunay 2015
> + * Author: Amelie Delaunay <adelaunay.stm32@gmail.com>
This differs from your SoB. I don't really care but it seems odd.
> + * License terms: GNU General Public License (GPL), version 2
> + */
> +
> +#include <linux/bcd.h>
> +#include <linux/clk.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/ioport.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/rtc.h>
> +#include <linux/spinlock.h>
> +
I have the feeling that some of those headers are not necessary maybe
some cleanup should be done.
> +static struct regmap *dbp;
> +
> +struct stm32_rtc {
> + struct rtc_device *rtc_dev;
> + void __iomem *base;
> + struct clk *pclk;
> + struct clk *ck_rtc;
> + unsigned int clksrc;
> + spinlock_t lock; /* Protects registers accesses */
That comment makes checkpatch happy but is not super useful :) Anyway...
> +static irqreturn_t stm32_rtc_alarm_irq(int irq, void *dev_id)
> +{
...can you make that one a threaded IRQ? If that's the case, just take
the rtc_device mutex here and remove the spinlock. All the other
function are already protected.
> +static int stm32_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
> +{
> + struct stm32_rtc *rtc = dev_get_drvdata(dev);
> + struct rtc_time *tm = &alrm->time;
> + unsigned int alrmar, cr, isr;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&rtc->lock, irqflags);
> +
> + alrmar = stm32_rtc_readl(rtc, STM32_RTC_ALRMAR);
> + cr = stm32_rtc_readl(rtc, STM32_RTC_CR);
> + isr = stm32_rtc_readl(rtc, STM32_RTC_ISR);
> +
> + spin_unlock_irqrestore(&rtc->lock, irqflags);
> +
> + if (alrmar & STM32_RTC_ALRMXR_DATE_MASK) {
> + /*
> + * Date/day don't care in Alarm comparison so alarm triggers
I guess you meant "doesn't matter" (that is also valid for the other
usages of "don't care".
> + * every day
> + */
> + tm->tm_mday = -1;
> + tm->tm_wday = -1;
> + } else {
> + if (alrmar & STM32_RTC_ALRMXR_WDSEL) {
> + /* Alarm is set to a day of week */
> + tm->tm_mday = -1;
> + tm->tm_wday = (alrmar & STM32_RTC_ALRMXR_WDAY) >>
> + STM32_RTC_ALRMXR_WDAY_SHIFT;
> + tm->tm_wday %= 7;
> + } else {
> + /* Alarm is set to a day of month */
> + tm->tm_wday = -1;
> + tm->tm_mday = (alrmar & STM32_RTC_ALRMXR_DATE) >>
> + STM32_RTC_ALRMXR_DATE_SHIFT;
> + }
> + }
> +
> + if (alrmar & STM32_RTC_ALRMXR_HOUR_MASK) {
> + /* Hours don't care in Alarm comparison */
> + tm->tm_hour = -1;
> + } else {
> + tm->tm_hour = (alrmar & STM32_RTC_ALRMXR_HOUR) >>
> + STM32_RTC_ALRMXR_HOUR_SHIFT;
> + if (alrmar & STM32_RTC_ALRMXR_PM)
> + tm->tm_hour += 12;
> + }
> +
> + if (alrmar & STM32_RTC_ALRMXR_MIN_MASK) {
> + /* Minutes don't care in Alarm comparison */
> + tm->tm_min = -1;
> + } else {
> + tm->tm_min = (alrmar & STM32_RTC_ALRMXR_MIN) >>
> + STM32_RTC_ALRMXR_MIN_SHIFT;
> + }
> +
> + if (alrmar & STM32_RTC_ALRMXR_SEC_MASK) {
> + /* Seconds don't care in Alarm comparison */
> + tm->tm_sec = -1;
> + } else {
> + tm->tm_sec = (alrmar & STM32_RTC_ALRMXR_SEC) >>
> + STM32_RTC_ALRMXR_SEC_SHIFT;
> + }
> +
I'm not sure those multiple cases (including STM32_RTC_ALRMXR_WDSEL) are
useful because the core will always give you valid tm_sec, tm_min,
tm_hour and tm_mday (it is actually checked up to four times!) so you
should always end up in the same configuration.
If you think some code other than Linux may set an alarm (e.g. the
bootloader) then you may keep them in read_alarm but at least you can
remove them from set_alarm.
> +static int stm32_rtc_probe(struct platform_device *pdev)
> +{
> + struct stm32_rtc *rtc;
> + struct resource *res;
> + int ret;
> +
> + rtc = devm_kzalloc(&pdev->dev, sizeof(*rtc), GFP_KERNEL);
> + if (!rtc)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + rtc->base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(rtc->base))
> + return PTR_ERR(rtc->base);
> +
> + dbp = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "st,syscfg");
> + if (IS_ERR(dbp)) {
> + dev_err(&pdev->dev, "no st,syscfg\n");
> + return PTR_ERR(dbp);
> + }
> +
> + spin_lock_init(&rtc->lock);
> +
> + rtc->ck_rtc = devm_clk_get(&pdev->dev, "ck_rtc");
> + if (IS_ERR(rtc->ck_rtc)) {
> + dev_err(&pdev->dev, "no ck_rtc clock");
> + return PTR_ERR(rtc->ck_rtc);
> + }
> +
> + ret = clk_prepare_enable(rtc->ck_rtc);
> + if (ret)
> + return ret;
> +
> + if (dbp)
> + regmap_update_bits(dbp, PWR_CR, PWR_CR_DBP, PWR_CR_DBP);
> +
> + ret = stm32_rtc_init(pdev, rtc);
> + if (ret)
> + goto err;
> +
Isn't that RTC backuped in some way, do you really need to reinit it
each time the system reboots?
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399
From: Heiko Stuebner @ 2016-12-07 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207190301.GA107036@google.com>
Am Mittwoch, 7. Dezember 2016, 11:03:02 CET schrieb Brian Norris:
> On Wed, Dec 07, 2016 at 08:01:23PM +0100, Heiko Stuebner wrote:
> > Am Mittwoch, 7. Dezember 2016, 09:52:08 CET schrieb Brian Norris:
> > > But pcie at f8000000 is also out of order then. I guess maybe
> > > that's the only one then.
> >
> > Yep, pcie is misplaced as sadly sometimes I miss those errors as well.
>
> OK. Do you want me to patch that at the end of my series, or is that
> unnecessary churn?
I'm still pondering [and am investing way to much brain cells in trying to
decide this ;-) ], but tend to want to move it.
That way the dtsi gives the correct sorting impression for future dt-patches
of which I guess we'll see a lot in the time to come.
So yes, please move it as well.
Thanks
Heiko
^ permalink raw reply
* [PATCH 6/9] dt-bindings: Document rk3399 Gru/Kevin
From: Heiko Stuebner @ 2016-12-07 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207174139.GA87970@google.com>
Am Mittwoch, 7. Dezember 2016, 09:41:39 CET schrieb Brian Norris:
> On Wed, Dec 07, 2016 at 06:12:13PM +0100, Heiko Stuebner wrote:
> > Hi Brian,
> >
> > Am Donnerstag, 1. Dezember 2016, 18:27:30 CET schrieb Brian Norris:
> > > Gru is a base dev board for a family of devices, including Kevin. Both
> > > utilize Rockchip RK3399, and they share much of their design.
> > >
> > > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > > ---
> > >
> > > Documentation/devicetree/bindings/arm/rockchip.txt | 20
> > >
> > > ++++++++++++++++++++ 1 file changed, 20 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> > > b/Documentation/devicetree/bindings/arm/rockchip.txt index
> > > cc4ace6397ab..830e13f5890c 100644
> > > --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> > > +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> > > @@ -99,6 +99,26 @@ Rockchip platforms device tree bindings
> > >
> > > "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> > > "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> > >
> > > +- Google Gru (dev-board):
> > boards sorted alphabetically please
> >
> > Brian, Gru, Jaq, ... Kevin, ...
> >
> > While the sorting of old boards is not right yet, new boards should be
> > sorted.
> I got the idea that there was some attempt to group logically before
> alphabetically. Like keeping board/SoC families together. But maybe not.
>
> I can do as you suggested, if you don't care about keeping actual
> similar boards together (i.e., veyron/3288 vs gru/3399).
I'd prefer a simple alphabetical sorting.
I think people reading the document will know what device they have, but not
necessarily the actual soc in it. At least I would look for Google Kevin
primarily without thinking of the soc at first.
And in general, most Rockchip boards (maybe except Google-boards) tend to
follow the reference design quite closely, so it may become hard to decide
when one is similar to another :-) . So best to keep it simple.
^ permalink raw reply
* [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check
From: Eric Anholt @ 2016-12-07 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206172911.z6sbjzgqv3vfcrfh@lukather>
Maxime Ripard <maxime.ripard@free-electrons.com> writes:
> [ Unknown signature status ]
> On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
>> The panels shipped with Allwinner devices are very "generic", i.e.
>> they do not have model numbers or reliable sources of information
>> for the timings (that we know of) other than the fex files shipped
>> on them. The dot clock frequency provided in the fex files have all
>> been rounded to the nearest MHz, as that is the unit used in them.
>>
>> We were using the simple panel "urt,umsh-8596md-t" as a substitute
>> for the A13 Q8 tablets in the absence of a specific model for what
>> may be many different but otherwise timing compatible panels. This
>> was usable without any visual artifacts or side effects, until the
>> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
>> rgb: Validate the clock rate").
>>
>> The reason this check fails is because the dotclock frequency for
>> this model is 33.26 MHz, which is not achievable with our dot clock
>> hardware, and the rate returned by clk_round_rate deviates slightly,
>> causing the driver to reject the display mode.
>>
>> The LCD panels have some tolerance on the dot clock frequency, even
>> if it's not specified in their datasheets.
>>
>> This patch adds a 5% tolerence to the dot clock check.
>
> As we discussed already, I really believe this is just as arbitrary as
> the current behaviour.
>
> Some panels require an exact frequency, some have a minimal frequency
> but no maximum, some have a maximum frequency but no minimal, and I
> guess most of them deviates by how much exactly they can take (and
> possibly can take more easily a higher frequency, but are less
> tolerant if you take a frequency lower than the nominal.
>
> And we cannot remove that check entirely, since some bridges will
> report out of range frequencies for higher modes that we know we
> cannot reach.
>
> We could just try to see if the screen pixel clock frequency is out of
> the pixel clock range we can generate, but then we will loop back on
> how much out of range is it exactly, and is it within the screen
> tolerancy.
>
> We have an API to deal with the panel tolerancies in the DRM panel
> framework, we can (and should) use it.
>
> I'm not sure how others usually deal with this though. I think I
> remember Eric telling me that for the RPi they just adjusted the
> timings a bit, but they only really had a single panel to deal with.
For RPi, you just adjust the pixel clock of the panel's mode to be
whatever the platform can support, and expand the blanking intervals to
get the refresh rate back to desired. This is nothing like what the
datasheet says, but it's not important what the datasheet says, it's
important what makes the product work.
Our clock driver looks for the best matching clock that's not over the
target rate. This is somewhat unfortunate, as you end up slightly
inflating your requested clocks so that a possible clock lands under
that. I'd rather we chose the closest matching clock, but then people
get worried about what if selected clock rate is 1% higher than expected
(the answer is "nothing").
I think this patch is a fine solution, and the alternative would be to
just drop the mode high/low check and say that if you're pairing a panel
with some display hardware, it's up to you to make sure that the panel's
mode actually scans out successfully. Then, since compatible strings
are cheap, you can use a new one if necessary to attach better modes to
the panel for a particular clock driver by adjusting your timings to get
closer to the refresh rates you want.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161207/d2a9b314/attachment.sig>
^ permalink raw reply
* [RESEND PATCH v2 4/7] drm/vc4: Add support for the VEC (Video Encoder) IP
From: Eric Anholt @ 2016-12-07 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207161205.485a3046@bbrezillon>
Boris Brezillon <boris.brezillon@free-electrons.com> writes:
> On Mon, 5 Dec 2016 17:50:13 -0800
> Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>> On 12/02/2016 05:48 AM, Boris Brezillon wrote:
>> > The VEC IP is a TV DAC, providing support for PAL and NTSC standards.
>> >
>> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>> > ---
>>
>> > diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
>> > new file mode 100644
>> > index 000000000000..2d4256fcc6f2
>> > --- /dev/null
>> > +++ b/drivers/gpu/drm/vc4/vc4_vec.c
>> > @@ -0,0 +1,657 @@
>> > +/*
>> > + * Copyright (C) 2016 Broadcom Limited
>>
>> The standard copyright template post acquisition is just Broadcom, not
>> Broadcom Limited, nor Broadcom corporation. Can you audit your entire
>> submission and fix this up accordingly?
>
> This is the only patch adding a copyright header.
> Eric, can you fix that when applying the series or should I resend a
> new version?
I'll fix it when applying, that's fine. (I had in v1 and forgot to tell
you!)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161207/ac9e00a2/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/6] crypto: testmgr - avoid overlap in chunked tests
From: Eric Biggers @ 2016-12-07 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480963348-24203-2-git-send-email-ard.biesheuvel@linaro.org>
On Mon, Dec 05, 2016 at 06:42:23PM +0000, Ard Biesheuvel wrote:
> The IDXn offsets are chosen such that tap values (which may go up to
> 255) end up overlapping in the xbuf allocation. In particular, IDX1
> and IDX3 are too close together, so update IDX3 to avoid this issue.
>
Hi Ard,
This patch is causing the self-tests for "xts(ecb(aes-asm))" to fail.
This is on x86. Any idea why? Here's what I see in the log:
alg: skcipher: Chunk test 1 failed on encryption at page 0 for xts(ecb(aes-asm))
00000000: 1c 3b 3a 10 2f 77 03 86 e4 83 6c 99 e3 70 cf 9b
00000010: ea 00 80 3f 5e 48 23 57 a4 ae 12 d4 14 a3 e6 3b
00000020: 5d 31 e2 76 f8 fe 4a 8d 66 b3 17 f9 ac 68 3f 44
00000030: 68 0a 86 ac 35 ad fc 33 45 be fe cb 4b b1 88 fd
00000040: 57 76 92 6c 49 a3 09 5e b1 08 fd 10 98 ba ec 70
00000050: aa a6 69 99 a7 2a 82 f2 7d 84 8b 21 d4 a7 41 b0
00000060: c5 cd 4d 5f ff 9d ac 89 ae ba 12 29 61 d0 3a 75
00000070: 71 23 e9 87 0f 8a cf 10 00 02 08 87 89 14 29 ca
00000080: 2a 3e 7a 7d 7d f7 b1 03 55 16 5c 8b 9a 6d 0a 7d
00000090: e8 b0 62 c4 50 0d c4 cd 12 0c 0f 74 18 da e3 d0
000000a0: b5 78 1c 34 80 3f a7 54 21 c7 90 df e1 de 18 34
000000b0: f2 80 d7 66 7b 32 7f 6c 8c d7 55 7e 12 ac 3a 0f
000000c0: 93 ec 05 c5 2e 04 93 ef 31 a1 2d 3d 92 60 f7 9a
000000d0: 28 9d 6a 37 9b c7 0c 50 84 14 73 d1 a8 cc 81 ec
000000e0: 58 3e 96 45 e0 7b 8d 96 70 65 5b a5 bb cf ec c6
000000f0: dc 39 66 38 0a d8 fe cb 17 b6 ba 02 46 9a 02 0a
00000100: 84 e1 8e 8f 84 25 20 70 c1 3e 9f 1f 28 9b e5 4f
00000110: bc 48 14 57 77 8f 61 60 15 e1 32 7a 02 b1 40 f1
00000120: 50 5e b3 09 32 6d 68 37 8f 83 74 59 5c 84 9d 84
00000130: f4 c3 33 ec 44 23 88 51 43 cb 47 bd 71 c5 ed ae
00000140: 9b e6 9a 2f fe ce b1 be c9 de 24 4f be 15 99 2b
00000150: 11 b7 7c 04 0f 12 bd 8f 6a 97 5a 44 a0 f9 0c 29
00000160: a9 ab c3 d4 d8 93 92 72 84 c5 87 54 cc e2 94 52
00000170: 9f 86 14 dc d2 ab a9 91 92 5f ed c4 ae 74 ff ac
00000180: 6e 33 3b 93 eb 4a ff 04 79 da 9a 41 0e 44 50 e0
00000190: dd 7a e4 c6 e2 91 09 00 57 5d a4 01 fc 07 05 9f
000001a0: 64 5e 8b 7e 9b fd ef 33 94 30 54 ff 84 01 14 93
000001b0: c2 7b 34 29 ea ed b4 ed 53 76 44 1a 77 ed 43 85
000001c0: 1a d7 7f 16 f5 41 df d2 69 d5 0d 6a 5f 14 fb 0a
000001d0: 1e 2a 8f 42 61 9e 5e c2 59 bd 96 d0 e5 cc 23 1f
000001e0: fb 84 ed 15 a8 eb 66 07 31 6b f6 ef
Eric
^ permalink raw reply
* mmc: core: complete/wait_for_completion performance
From: Stefan Wahren @ 2016-12-07 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481095953.17027.0.camel@embedded.rocks>
Hi J?rg,
> J?rg Krause <joerg.krause@embedded.rocks> hat am 7. Dezember 2016 um 08:32
> geschrieben:
>
>
> Hit Stefan,
>
> On Sat, 2016-11-26 at 20:10 +0100, Stefan Wahren wrote:
> > Hi J?rg,
> >
> > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November 2016
> > > um 20:10
> > > geschrieben:
> > >
> > >
> > > On Sun, 2016-11-20 at 16:44 +0100, Stefan Wahren wrote:
> > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November
> > > > > 2016
> > > > > um 15:42
> > > > > geschrieben:
> > > > >
> > > > >
> > > > > Hi Stefan,
> > > > >
> > > > > On Sun, 2016-11-20 at 14:28 +0100, Stefan Wahren wrote:
> > > > > > Hi J?rg,
> > > > > >
> > > > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20.
> > > > > > > November
> > > > > > > 2016
> > > > > > > um 13:27
> > > > > > > geschrieben:
> > > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I started the discussion on this mailing list in another
> > > > > > > thread
> > > > > > > [1],
> > > > > > > but I'd like to move it to a new thread, because it might
> > > > > > > be
> > > > > > > mmc
> > > > > > > specific.
> > > > > > >
> > > > > > > The issue is that I am noticed low wifi network throughput
> > > > > > > on
> > > > > > > an
> > > > > > > i.MX28
> > > > > > > board with the mainline kernel (v4.7.10, about 6 Mbps)
> > > > > > > compared
> > > > > > > to
> > > > > > > the
> > > > > > > vendor kernel (Freescale v2.6.35.3, about 20 Mbps). The
> > > > > > > wifi
> > > > > > > chip
> > > > > > > is
> > > > > > > attached using the SDIO interface.
> > > > > > >
> > > > > > > I started investigation where the bottleneck in the
> > > > > > > mainline
> > > > > > > kernel?might come from. Therefore I checked that the
> > > > > > > configs
> > > > > > > and
> > > > > > > settings for the interfaces and drivers are the same. They
> > > > > > > are.
> > > > > >
> > > > > > so you're not using the mxs_defconfig settings anymore?
> > > > >
> > > > > No, I changed the settings.
> > > > >
> > > >
> > > > What happens to performance to if you change the following
> > > > settings
> > > > to the same
> > > > like in mxs_defconfig?
> > > >
> > > > CONFIG_PREEMPT_VOLUNTARY=y
> > > > CONFIG_DEFAULT_IOSCHED="noop"
> > >
> > > No much change at all. The time difference between complete() and
> > > wait_for_complete() decreases in best case to 110 us, but also
> > > varies
> > > to above 130 us.
> >
> > just a weird idea. Did you tried to add MMC_CAP_CMD23 into the caps
> > [1]?
> >
> > [1] - http://lxr.free-electrons.com/source/drivers/mmc/host/mxs-mmc.c
> > ?v=4.8#L642
>
> I tried, but it did not improved the timing or throughput. However,
> many thanks for the input.
>
> J?rg
did you try cyclictest [1]?
Beside the time for a request the amount of requests for the complete iperf test
would we interesting. Maybe there are retries.
I'm still interested in your PIO mode patches for mxs-mmc even without clean up.
[1] - https://git.kernel.org/cgit/utils/rt-tests/rt-tests.git/
^ permalink raw reply
* [PATCH V2 4/5] ARM: BCM5301X: Specify all RAM by including an extra block
From: Jon Mason @ 2016-12-07 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207075655.7396-4-zajec5@gmail.com>
On Wed, Dec 07, 2016 at 08:56:54AM +0100, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal@milecki.pl>
>
> The first 128 MiB of RAM can be accessed using an alias at address 0x0.
>
> In theory we could access whole RAM using 0x80000000 - 0xbfffffff range
> (up to 1 GiB) but it doesn't seem to work on Northstar. For some reason
> (hardware setup left by the bootloader maybe?) 0x80000000 - 0x87ffffff
> range can't be used. I reproduced this problem on:
> 1) Buffalo WZR-600DHP2 (BCM47081)
> 2) Netgear R6250 (BCM4708)
> 3) D-Link DIR-885L (BCM47094)
>
> So it seems we're forced to access first 128 MiB using alias at 0x0 and
> the rest using real base address + 128 MiB offset which is 0x88000000.
>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
Acked-by: Jon Mason <jon.mason@broadcom.com>
> ---
> V2: Updated commit message, thanks Jon!
> Included XWR-3100
> ---
> arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 3 ++-
> arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts | 3 ++-
> arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 3 ++-
> arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 3 ++-
> arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 3 ++-
> arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 3 ++-
> arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 3 ++-
> 16 files changed, 32 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> index 112a5a8..d241cee 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> index 3600f56..b0e6204 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> index d49afec0..c9ba6b9 100644
> --- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> +++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x18000000>;
> };
>
> spi {
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> index 8519548..b9f66c0 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> index 6229ef2..ae0199f 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> index 74cfcd3..36b628b1 100644
> --- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> +++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> index 71b98cf..db8608b 100644
> --- a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> +++ b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> index 2922536..d51586d 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> spi {
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> index 184fd92..de041b8 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> gpio-keys {
> diff --git a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> index eac0f52..eaca687 100644
> --- a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> +++ b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> index aab39c9..b32957c 100644
> --- a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> +++ b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x18000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> index 7ab1176..f459a98 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> index 56d38a3..cd13534 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> index 7fb9270..64ded76 100644
> --- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> +++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> nand: nand at 18028000 {
> diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> index 93cc91d..5cf4ab1 100644
> --- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> +++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> @@ -18,7 +18,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> index 7ecd57c..600795e 100644
> --- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> +++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> @@ -18,7 +18,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x18000000>;
> };
>
> leds {
> --
> 2.10.1
>
^ permalink raw reply
* [PATCH v2] ARM: dts: lpc32xx: add pwm-cells to base dts file
From: Sylvain Lemieux @ 2016-12-07 19:30 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylvain Lemieux <slemieux@tycoint.com>
There is no need to define the "pwm-cells" in the board
specific dts file; move the entry to the base dts file.
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
---
Changes in v2:
* Update the "pwm-cells" to be compatible with the latest
lpc32xx-pwm driver implementation.
Note:
* This patch have a dependency on the following patcheset:
"pwm: lpc32xx: switch driver to one phandle argument for PWM consumers"
http://www.spinics.net/lists/arm-kernel/msg547013.html
arch/arm/boot/dts/lpc32xx.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index 218d9fa..c031c94 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -472,6 +472,7 @@
assigned-clocks = <&clk LPC32XX_CLK_PWM1>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
status = "disabled";
+ #pwm-cells = <1>;
};
pwm2: pwm at 4005C004 {
@@ -481,6 +482,7 @@
assigned-clocks = <&clk LPC32XX_CLK_PWM2>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
status = "disabled";
+ #pwm-cells = <1>;
};
timer3: timer at 40060000 {
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 0/4] ARM: davinci: da850: add/enable video capture
From: Kevin Hilman @ 2016-12-07 19:31 UTC (permalink / raw)
To: linux-arm-kernel
Add support for VPIF video capture using DT (partially.)
The main VPIF device, and its pin muxing are using DT, but legacy
platform_data is still required for the vpif_capture driver. Passing
legacy platform_data is required until the V4L2 framework, and
subdevice drivers (such as the tvp514x) grow a way of selecting input
and output routing (c.f. V4L2 s_routing API)
Dependencies:
- VPIF driver changes:
[PATCH v6 0/5] davinci: VPIF: add DT support
https://marc.info/?l=linux-arm-kernel&m=148113556200610
Kevin Hilman (4):
ARM: dts: davinci: da850: VPIF: add node and muxing
ARM: davinci_all_defconfig: enable video capture as modules
ARM: davinci: da8xx: add pdata-quirks, use for VPIF capture
ARM: davinci: board-da850-evm: add I2C ID for VPIF
arch/arm/boot/dts/da850-evm.dts | 6 ++
arch/arm/boot/dts/da850-lcdk.dts | 6 ++
arch/arm/boot/dts/da850.dtsi | 38 ++++++-
arch/arm/configs/davinci_all_defconfig | 6 ++
arch/arm/mach-davinci/Makefile | 2 +-
arch/arm/mach-davinci/board-da850-evm.c | 1 +
arch/arm/mach-davinci/da8xx-dt.c | 2 +
arch/arm/mach-davinci/include/mach/common.h | 4 +
arch/arm/mach-davinci/pdata-quirks.c | 155 ++++++++++++++++++++++++++++
9 files changed, 218 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-davinci/pdata-quirks.c
--
2.9.3
^ permalink raw reply
* [PATCH v2 1/4] ARM: dts: davinci: da850: VPIF: add node and muxing
From: Kevin Hilman @ 2016-12-07 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207193137.27947-1-khilman@baylibre.com>
Add VPIF node an pins to da850 and enable on boards. VPIF has two input
channels described using the standard DT ports and enpoints.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/boot/dts/da850-evm.dts | 6 ++++++
arch/arm/boot/dts/da850-lcdk.dts | 6 ++++++
arch/arm/boot/dts/da850.dtsi | 38 +++++++++++++++++++++++++++++++++++++-
3 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 41de15fe15a2..212b50d4f84b 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -289,3 +289,9 @@
};
};
};
+
+&vpif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vpif_capture_pins>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21fed6c..67f846f5bb35 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -219,3 +219,9 @@
};
};
};
+
+&vpif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vpif_capture_pins>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b91c680..dd2a13ed106e 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -186,7 +186,18 @@
0xc 0x88888888 0xffffffff
>;
};
-
+ vpif_capture_pins: vpif_capture_pins {
+ pinctrl-single,bits = <
+ /* VP_DIN[2..7], VP_CLKIN1, VP_CLKIN0 */
+ 0x38 0x11111111 0xffffffff
+ /* VP_DIN[10..15,0..1] */
+ 0x3c 0x11111111 0xffffffff
+ /* VP_DIN[8..9] */
+ 0x40 0x00000011 0x000000ff
+ /* VP_CLKIN3, VP_CLKIN2 */
+ 0x4c 0x00010100 0x000f0f00
+ >;
+ };
};
edma0: edma at 0 {
compatible = "ti,edma3-tpcc";
@@ -399,7 +410,32 @@
<&edma0 0 1>;
dma-names = "tx", "rx";
};
+
+ vpif: video at 217000 {
+ compatible = "ti,da850-vpif";
+ reg = <0x217000 0x1000>;
+ interrupts = <92>;
+ status = "disabled";
+
+ /* VPIF capture: input channels */
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vpif_ch0: endpoint at 0 {
+ reg = <0>;
+ bus-width = <8>;
+ };
+
+ vpif_ch1: endpoint at 1 {
+ reg = <1>;
+ bus-width = <8>;
+ data-shift = <8>;
+ };
+ };
+ };
};
+
aemif: aemif at 68000000 {
compatible = "ti,da850-aemif";
#address-cells = <2>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/4] ARM: davinci_all_defconfig: enable video capture as modules
From: Kevin Hilman @ 2016-12-07 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207193137.27947-1-khilman@baylibre.com>
Enable media support and V4L2 capture, along with video decoders used
on da850 platforms.
Tested on da850-lcdk.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/configs/davinci_all_defconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 5e5dd6bc5ed9..fd05bc35fb36 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -123,6 +123,12 @@ CONFIG_TPS6507X=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_TPS6507X=y
+CONFIG_MEDIA_SUPPORT=m
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE=m
+# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
+CONFIG_VIDEO_TVP514X=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DA8XX=y
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/4] ARM: davinci: da8xx: add pdata-quirks, use for VPIF capture
From: Kevin Hilman @ 2016-12-07 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207193137.27947-1-khilman@baylibre.com>
Add pdata-quirks for da8xx DT platforms, which adds the legacy platform
data for vpif_capture driver.
Passing legacy platform_data is required until the V4L2 framework, and
subdevice drivers (such as the tvp514x) grow a way of selecting input
and output routing (c.f. V4L2 s_routing API)
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/mach-davinci/Makefile | 2 +-
arch/arm/mach-davinci/da8xx-dt.c | 2 +
arch/arm/mach-davinci/include/mach/common.h | 4 +
arch/arm/mach-davinci/pdata-quirks.c | 155 ++++++++++++++++++++++++++++
4 files changed, 162 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-davinci/pdata-quirks.c
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index da4c336b4637..90d2e6e4d913 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -21,7 +21,7 @@ obj-$(CONFIG_AINTC) += irq.o
obj-$(CONFIG_CP_INTC) += cp_intc.o
# Board specific
-obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o
+obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o pdata-quirks.o
obj-$(CONFIG_MACH_DAVINCI_EVM) += board-dm644x-evm.o
obj-$(CONFIG_MACH_SFFSDR) += board-sffsdr.o
obj-$(CONFIG_MACH_NEUROS_OSD2) += board-neuros-osd2.o
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index c9f7e9274aa8..69c8099de9f5 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -38,6 +38,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
NULL),
OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", NULL),
+ OF_DEV_AUXDATA("ti,da850-vpif", 0x01e17000, "vpif", NULL),
{}
};
@@ -46,6 +47,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
static void __init da850_init_machine(void)
{
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
+ pdata_quirks_init();
}
static const char *const da850_boards_compat[] __initconst = {
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 0b3c169758ed..1fd4cd2d1c23 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -102,6 +102,10 @@ int davinci_pm_init(void);
static inline int davinci_pm_init(void) { return 0; }
#endif
+#ifdef CONFIG_MACH_DA8XX_DT
+extern void __init pdata_quirks_init(void);
+#endif
+
#define SRAM_SIZE SZ_128K
#endif /* __ARCH_ARM_MACH_DAVINCI_COMMON_H */
diff --git a/arch/arm/mach-davinci/pdata-quirks.c b/arch/arm/mach-davinci/pdata-quirks.c
new file mode 100644
index 000000000000..a186513edf7e
--- /dev/null
+++ b/arch/arm/mach-davinci/pdata-quirks.c
@@ -0,0 +1,155 @@
+/*
+ * Legacy platform_data quirks
+ *
+ * Copyright (C) 2016 BayLibre, Inc
+ *
+ * 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/kernel.h>
+#include <linux/of_platform.h>
+
+#include <media/i2c/tvp514x.h>
+
+#include <mach/common.h>
+#include <mach/da8xx.h>
+#include <mach/mux.h>
+
+struct pdata_init {
+ const char *compatible;
+ void (*fn)(void);
+};
+
+#if IS_ENABLED(CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE)
+
+#define TVP5147_CH0 "tvp514x-0"
+#define TVP5147_CH1 "tvp514x-1"
+
+/* VPIF capture configuration */
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1,
+};
+
+#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+static const struct vpif_input da850_ch0_inputs[] = {
+ {
+ .input = {
+ .index = 0,
+ .name = "Composite",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .capabilities = V4L2_IN_CAP_STD,
+ .std = TVP514X_STD_ALL,
+ },
+ .input_route = INPUT_CVBS_VI2B,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ .subdev_name = TVP5147_CH0,
+ },
+};
+
+static const struct vpif_input da850_ch1_inputs[] = {
+ {
+ .input = {
+ .index = 0,
+ .name = "S-Video",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .capabilities = V4L2_IN_CAP_STD,
+ .std = TVP514X_STD_ALL,
+ },
+ .input_route = INPUT_SVIDEO_VI2C_VI1C,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ .subdev_name = TVP5147_CH1,
+ },
+};
+
+static struct vpif_subdev_info da850_vpif_capture_sdev_info[] = {
+ {
+ .name = TVP5147_CH0,
+ .board_info = {
+ I2C_BOARD_INFO("tvp5146", 0x5d),
+ .platform_data = &tvp5146_pdata,
+ },
+ },
+ {
+ .name = TVP5147_CH1,
+ .board_info = {
+ I2C_BOARD_INFO("tvp5146", 0x5c),
+ .platform_data = &tvp5146_pdata,
+ },
+ },
+};
+
+static struct vpif_capture_config da850_vpif_capture_config = {
+ .subdev_info = da850_vpif_capture_sdev_info,
+ .subdev_count = ARRAY_SIZE(da850_vpif_capture_sdev_info),
+ .chan_config[0] = {
+ .inputs = da850_ch0_inputs,
+ .input_count = ARRAY_SIZE(da850_ch0_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
+ },
+ .chan_config[1] = {
+ .inputs = da850_ch1_inputs,
+ .input_count = ARRAY_SIZE(da850_ch1_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
+ },
+ .card_name = "DA850/OMAP-L138 Video Capture",
+};
+
+static void __init da850_vpif_legacy_init(void)
+{
+ int ret;
+
+ /* LCDK doesn't have the 2nd TVP514x on CH1 */
+ if (of_machine_is_compatible("ti,da850-lcdk"))
+ da850_vpif_capture_config.subdev_count = 1;
+
+ /* EVM (UI card) uses i2c adapter 1 (not default: zero) */
+ if (of_machine_is_compatible("ti,da850-evm"))
+ da850_vpif_capture_config.i2c_adapter_id = 1;
+
+ ret = da850_register_vpif_capture(&da850_vpif_capture_config);
+ if (ret)
+ pr_warn("%s: VPIF capture setup failed: %d\n",
+ __func__, ret);
+}
+#endif
+
+static void pdata_quirks_check(struct pdata_init *quirks)
+{
+ while (quirks->compatible) {
+ if (of_machine_is_compatible(quirks->compatible)) {
+ if (quirks->fn)
+ quirks->fn();
+ break;
+ }
+ quirks++;
+ }
+}
+
+static struct pdata_init pdata_quirks[] __initdata = {
+#if IS_ENABLED(CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE)
+ { "ti,da850-lcdk", da850_vpif_legacy_init, },
+#if defined(CONFIG_DA850_UI_SD_VIDEO_PORT)
+ { "ti,da850-evm", da850_vpif_legacy_init, },
+#endif
+#endif
+ { /* sentinel */ },
+};
+
+void __init pdata_quirks_init(void)
+{
+ pdata_quirks_check(pdata_quirks);
+}
--
2.9.3
^ permalink raw reply related
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